Multi-site WMS rollout: life after site one | Socius24

Multi-site WMS rollout: what happens after site one

Most multi-site WMS rollouts get off to a pretty good start. And that’s because site number one has most likely imported the company’s best people from all of the other sites, head office is watching proceedings very closely, and by the time it goes live there’s usually a fair bit of relief (and possibly cake) around the place.

But then site two comes along, which is when you start to find out what you’ve actually done.

Whether you’re running one warehouse and planning to add more, or you’re on site six and wondering why no two of them ever seem to work in quite the same way, multi-site WMS rollouts tend to follow a fairly predictable pattern. Most of the bumps (if you get them) turn up in the same places, too. So, today, we thought we’d walk through them, one site at a time.

Site one: the template trap

Whatever the plan says, site one usually ends up as the template for the rest of them. It’s the first one that was built, it works, so when site two comes along, copying it feels like a completely reasonable thing to do.

The problem is that site one is full of things that feel perfectly normal to the people who work at site one.

Perhaps it’s the way the team names its locations. Maybe it’s the shift pattern. Could be the workaround that somebody built for one particularly awkward client, three years ago. Or maybe, it’s the way that a particular supervisor likes her pick lists sorted. And all of these little specific quirks add up to being site one’s way of doing things, which is absolutely fine (for site one), but it’s about to be rolled out everywhere as “the standard”.

So, while you’re building site one, it helps to keep asking a slightly annoying question: is this how the business works, or is this how this site works? Write the answers down as you go. Dispatcher WMS lets you handle a lot of this through configuration, site by site. And that does make life much easier. But somebody still needs to decide, early on, which things belong in the business template, and which belong to the site, and the earlier that happens, the better for everyone.

Site two: the moment of truth

Site two is where you find out which of those ‘things’ were local rather than global to the business. Maybe site two’s building is a totally different shape, and it’s three times bigger, spread over multiple floors. The racking’s totally different. The team might be bigger, or smaller, or it might have been doing things its own way for the last fifteen years and would quite like to carry on in the same vein, thank you very much. The clients will have slightly different requirements, and at least one of them will want something that nobody (maybe not even us) has ever seen before.

There are two tempting mistakes that you can make at this point. The first is to force site two to work exactly like site one, whatever site management or the warehouse team happen to think about it. Which usually goes down about as well as you’d expect.

And when it does, new workarounds will start on day one.

The other mistake is giving in and changing everything to suit site two and then continuing on down that path until you’ve got two quite different systems that just happen to share the same WMS name.

What you actually want to do is to land somewhere in the middle. A handful of small, sensible changes for site two is a good sign, and a few of those might even be worth feeding back into the template. Dozens of changes usually means that the template was just pure site one.

Crossing a border

And then things get more interesting again, because at some point one of the sites might be in a different country.

Language differences are the obvious change here. The handhelds, the labels, the reports and the training all need to work for the people using them every day, and “they’ll just pick up the English” is a plan that has ruined more than one go-live. You might even need to make sure, before you start with site one, that your system can deal with languages that read right to left, rather than left to right.

Regulations can also change the moment that you cross a border, with customs, bonded stock, VAT, labelling rules and hazardous goods all working a little bit (or a lot) differently. Maybe you’ll have to deal with tariffs, who knows? Because moving goods across borders brings all kinds of shenanigans along with it. And then, as well, local carriers are usually a whole new group of businesses that you’ll have to work with, each with its own integrations, label formats and strong opinions about cut-off times.

And then there’s the calendar.

Head office tends to plan go-lives around its own peak, and it can come as a bit of a surprise that other countries have peaks of their own. Singles’ Day, Chinese New Year and Ramadan can all reshape a local operation for weeks.

And a go-live that lands on top of one of those will be remembered for a very long time, by everybody involved, and rarely fondly.

Time zones can catch people out as well. When something goes wrong at a site that’s eight hours ahead of IT support, the phone rings at somebody’s two am, so it’s worth agreeing who that somebody is before it happens. (I promise, they’ll appreciate the notice.)

The good news here is that Dispatcher WMS is already running in more than 60 countries around the world. So, whatever mix of languages, regulations and local quirks you’re dealing with, there’s a decent chance that somebody else has been through something very similar, already.

Sites three onwards: finding a rhythm

By site three, what you want is to have established a rhythm: a standard playbook for each rollout, and a sensible gap between go-lives, as well as an effective way of passing what you’ve learned on from one site to the next. The alternative is flying the same head office team around the world indefinitely. Do that, and they’ll be running on fumes by site five, with their own day jobs piling up at home since site two.

Local super users can make a huge difference here.

The people from site two have just been through it, so they remember exactly what was confusing. This means that they’re often the best people to help site three. Over time each site can help the next, and the whole thing will start to become faster, and probably a good deal smoother.

It also helps to leave some breathing room between go-lives. Every site needs a few weeks to bed in afterwards, and if the support team has already moved on to the next one, the previous sites’ problems might develop a habit of following them to the next one.

Year two: keeping everyone in lock step

Once everything’s live, a subtler problem can start to creep in. Perhaps each site begins to make small changes to suit itself: a rule tweaked here, a new process there, a workaround for a new client. Each one of the changes makes perfect sense at the time. Give it a year or two, though, and you can end up with twelve slightly different versions of the same system, with nobody being entirely sure which one is the template anymore.

It’s the same configuration drift that affects single sites, but exponentially multiplied.

And it can become a real problem when head office wants to compare their sites like for like, because that only works if every site is measuring the same things in the same way.

The fix for this is fairly unglamorous (as these things so often are). Somebody needs to own and maintain the template. Changes get looked at with every site in mind, including the sites that didn’t ask for them. And every so often, somebody sits down and compares what each site is actually doing vs what it’s supposed to be doing. Because that is how you keep a network of warehouses feeling and acting like one operation.

If you’re still on one site

If you’re running one warehouse now but expecting to add more, the most useful thing that you can do today is to start thinking about that template question. Which parts of how you work belong to the business, and which of them belong to this particular building or site? Answering this now is a lot cheaper than untangling it at site four.

This is just the way we work

At Socius24 Limited, we operate a “No Surprises” policy, and multi-site WMS rollouts are exactly where surprises can have a nasty habit of multiplying like rabbits. Dispatcher WMS is currently running in more than 60 countries around the world, and our case studies (along with a bit more about us on our about page) include plenty of operations that outgrew a single site a long time ago.

If you’re planning a rollout, or if you’re partway through one and site two is turning out a little too different from site one, we’re always happy to have a no-obligation chat.

You can get in touch with us here.