Avoiding catastrophe

News coverage of the July incident where warehouse management system (WMS) implementation glitches triggered booze shortages in some Ontario liquor stores served as a sober reminder of how dependent logistics operations are on their information management systems, and just how visible the effects can be when things go wrong.

The challenge for retailers like the Liquor Control Board of Ontario (LCBO), which declined to comment for this story, is that when users discover that logistics information systems aren’t performing exactly to spec, it may already be too late to avoid disruptions to the business.

Havoc

It doesn’t take a catastrophic system outage to visibly affect the movement of goods – slow response or a partial malfunction can wreak havoc on a busy summer weekend. “It affects the business immediately,” says John McKenna, president of Mississauga-based 3PL McKenna Logistics Centres. “It’s like a car accident – a pile-up on the highway. Nothing can flow.”

A malfunctioning system often leads to a vicious circle where harassed employees resort to workarounds, causing the situation to deteriorate further. “You cover things up just to get the goods flowing,” says McKenna, “so it gets really, really messy. Now you don’t know where you put the product, or if the order went out. You’ve got customers calling you saying ‘what’s my status, what’s going on here?’ All that information is in the computer, but you can’t get that information. It’s not fun.”

Supply chain partner IT systems can also be affected, further escalating the situation. “They [the partners] don’t know if their inventory records are accurate, because you’re all interlinked,” he says.

Occasionally, of course, there are incidents that make LCBO’s recent woes look like a walk in the park. This past summer, British apparel provider Asos experienced major difficulties with a warehousing technology upgrade, causing inventory shortages, delayed shipments, cancelled orders, and unanticipated costs due to workarounds and severe discounting to maintain customer loyalty.

“We did have ambitious plans for landing this change, and it’s been a lot bumpier and taken a lot longer than we initially planned,” said Asos CEO Nick Beighton on the company’s July 18 quarterly earnings update conference call. The total hit to the bottom line, the company reports, will exceed US$25 million, and the damage to the brand will take many months to repair.

Assessing the vulnerabilities

The interconnected systems that define the supply chain have many possible failure points, making any software implementation a demanding task. Arif Mohammed, vice-president of professional services delivery at Ottawa-based logistics software vendor Kinaxis, cites four categories which he finds are behind the vast majority of project failures.

1. Misalignment between what users expect and what the system can deliver.
2. Performance issues – a system might work well with 10,000 orders, but fail at 30,000.
3. Inadequate user interfaces that cause difficulties or extra work for front-line staff.
4. Data quality problems, such as errors, gaps, or formatting incompatibilities.

“Logistics is critical to what any business does,” says Mohammed, “so when a logistics team embarks on a project, they have to show that they have a very methodical approach to ensuring the project becomes successful.”

It’s not about IT

While any kind of malfunction connected with a system might look superficially like an IT problem, blaming IT for a failed system rollout or upgrade is unlikely to be productive, nor will it prevent problems in the future. What’s needed, invariably, is cross-functional teamwork led by senior management.

“Failures come back to a series of basic steps that are all about execution,” says Doug Harrison, a Toronto-based corporate board member and advisor and former CEO of Versacold Logistics Services. “Execution is always the most difficult part.”

“IT provides the infrastructure that the database is running on, but it is the business side that is inputting that data that sits in a file on the database,” says Warren Shiau, research vice-president at Toronto-based research firm IDC Canada.

“IT’s responsibility is to make the infrastructure and the database run so that there’s no downtime on it, and it’s the responsibility of the business to take care of the data and make sure it’s accurate.”

McKenna concurs that management should have a dominant role. “The most valuable part of an IT implementation is the planning part – scoping out the work, understanding what data you need, how it’s going to be used, etc.,” he says.

“IT people should be in that discussion, but their role is mainly coding to the business needs. So I think you’ll find that a lot of issues go back to management.”

According to Harrison, management should not only be involved, but give these projects top priority. “Technology in general has now gotten to the point where its so critical to so many companies – and can be so positive or so disruptive in a company – that boards of directors are getting actively involved in large scale technology implementations,” he says.

Finding the right vendor

The strategic nature of logistics applications in particular means vendor selection is of utmost importance. Companies should be aware that they’re not just acquiring IT functionality – they’re adopting a business process.

The mistake many companies make at this point is assuming that they can always customize where necessary. Customization, however, poses a number of difficulties. Custom code has to be maintained, and then updated whenever changes occur in the IT infrastructure. A customization in a warehouse management system, for example, could require rework to accommodate an upgrade to a point of sale system. The result could be a growing patchwork of customizations that gets more and more costly to maintain.

“Software companies have expertise in business process,” says Harrison, “and they might have thousands of companies using their processes. So pick the right vendor and the right partners to begin with. We might think we’re better, but we don’t know as much as a thousand firms.”

Of course, the conversation needs to be a two-way street. “The vendor is selling the way the software handles the process,” says Shiau, “so the vendor needs to understand what the client is doing.” Shiau notes a recent trend among Canadian vendor offices to be hiring people with industry process expertise.

The level of dialogue needed here can be easily discouraged in a competitive bidding process that’s not managed properly. For example, it’s common for vendors to minimize customization requirements, or to claim that a feature is “in the next release”.

As well, if the RFP has left out a key requirement, there may actually be a disincentive for the vendor to mention it. “Let’s get the business first, and we’ll worry about that later,” is a typical attitude among some vendors.

For these reasons, it’s essential to see the software that’s under consideration in a live environment – checking references isn’t sufficient. “You can’t see a system running as a whole in a meeting room,” says McKenna. “You actually have to go see it running. And that’s the responsibility of the executive sponsor.”

Avoiding ‘hope creep’

Optimism is a positive attribute in business, but excessive optimism can set the stage for project failures later on. The now legendary demise of Target Canada in 2014 is a case in point – expectations were that the phenomenally successful retailer could quickly implement a Canadian clone of its business model. Empty shelves, caused in part by faulty information systems implemented under externally dictated time constraints, were cited as the key culprit.

With technology moving as rapidly as it is, it’s tempting to get overambitious. “There’s a tendency to hurry up,” says McKenna. “You think, ‘this is going to solve so many of my problems, let’s hurry up and get it in.’ So you get impatient. The term I’ve heard is ‘hope creep’. You start to project these great things without verifying.”

As Mohammed points out, it’s common for companies to press hard for a fixed completion date, or to insist on relatively trivial features that aren’t essential to the business. “I would urge customers to think more pragmatically,” he says.

Security awareness is also essential to keeping expectations in line. “Security is a bigger issue than it ever was before,” says Toronto-based IT consultant Don Sheppard, “and everybody has to be more sensitive. What you need is security by design and privacy by design, where you design features into the system, as opposed to adding them after the fact.”

Upgrades to existing systems are a special case in that implementation glitches can take people by surprise. “An upgrade could be just underpinnings, or the look and feel to the user,” says Sheppard. “In both cases, you’re assuming people know and understand things. Often the upgrade is driven by the vendor, and the decision is now or wait. So not as much attention gets put on these projects.”

McKenna warns against complacency here. “An upgrade should be treated like a full implementation, with proper testing,” he says.

Dealing with sins of the past

Project teams often have to deal with hidden problems before moving forward. One of the most common, as Mohammed noted above, is that the quality of the data may not be adequate for the new project. Problems could be related to data formats, database compatibility issues, varying information standards, or incomplete files.

In a supply chain scenario, the scope could include the company’s data, and in addition, data from suppliers and customers.

“It’s always advisable to have a data assessment,” says Mohammed, “sometimes in the earlier phase of the project, to ensure that we do not get surprised by this aspect of the project.”

“If you have bad data, the supply chain groups are the ones that are going to feel it the most,” says Harrison. “They won’t have inventory, or inventory will be in the wrong place at the wrong volumes, etc. Then business points to the supply chain and says, ‘Why are you guys so bad?’”

Discovery of data problems can sometimes lead to finger pointing. “One of the biggest problems with data and quality of data is that people expect the IT department to handle that,” says Shiau.

“But in 95 percent of Canadian businesses with traditional IT organizations, it’s not actually IT’s responsibility to look after data quality. Their metrics are not based on that.”

According to Harrison, today’s supply chain professionals understand this. “Supply chain and logistics today is as much about the data as it is about the physical goods,” he says. “I think supply chain professionals really get the importance of the technology.”

The other potential trouble area is that past customizations might be complex and difficult to replicate in a new system project. When custom code isn’t documented properly, it can take considerable time and resources to sort out the details.

“When your documentation isn’t complete, it’s almost like re-inventing the customization, because you have to discover what’s been done,” says Shiau.

Of course, then there’s the classic case where “the only person who knew how the system worked retired last year.”

Breaking down silos

Because logistics operations touch on so many functional areas in the organization and in addition, suppliers and customers, software projects invariably involve bringing diverse groups of people together.

Organizations are getting better at this. Rigid project plans with firmly established roles and fixed completion dates have evolved to a more collaborative approach. The DevOps movement, which breaks down barriers between system developers and the people who operate the systems, is a trend towards a less siloed approach. However, it does not provide all of the answers.

“DevOps may make a better connection between development people and operations people,” Sheppard says, “but I’m not sure they make a better connection to the actual end user. In most organizations, there is some kind of wall between one group and some other group as far as developing and implementing IT.”

One problem, according to Mohammed, is that user input is often filtered through a layer of management. “I always get my team members to get input from the actual end users of the system as early in the project as possible so they can have a voice in how we design the business processes – the look and feel of the system – so that we are safe from a surprise at ‘go live’. I cannot tell you how many times I’ve heard users say, ‘this is too complex’.”

Projects can also tire people out. “The longer it takes, the more at risk the project gets,” says Harrison. “Employees get tired by the implementation because it’s absolutely painful for everyone. So you’re at risk of losing talent and having churn.”

What’s the maximum? “I used to have a CIO that said anything over a year is high risk,” Harrison notes. “Longer, you do in phases.”