Upgrading a WMS
Colin Burrow, CIO at logistics company Fliway, confirms the value proposition laid out by Masters. He says the company sought an upgrade to its warehouse management solution (WMS) owing to the passage of time and the inevitable arrival of obsolescence for this component of its application set. “While it was fit for purpose for a good period, the Exceed WMS had reached the end of its life. Complexity had evolved, so the old system wasn’t meeting our business requirements and was lacking in key functionality.”
Like many enterprise applications, the ageing Exceed WMS was comprised of multiple layers: the application, the operating system and database.
All these elements, Burrow notes, were at end-of-life, so the transition would require a complete replacement of the entire stack. “It might sound straightforward, but this was the better part of a two-year project; we were staying with the same application vendor, but upgrading to the latest generation of the WMS which offered all the functionality and performance required by the business.”
Burrow confirms, however, that any change is difficult, even when sticking with the same vendor. “There were some other complications. We were also moving from Unix to Windows for the operating system, and from Oracle to SQL Server for the database. These factors all influence the work involved in upgrading a system which is pretty fundamental to the successful operation of our company.”
The ace that Fliway had up its sleeve is that the WMS was integrated into the company’s other systems (and the systems of its key customers) with Flow Software. “What this meant in practice was that the WMS was effectively isolated from the other applications. With all the integration in one place – the Flow middleware layer – it meant we could replace the old WMS and minimise the customer impact because we only needed to change the Fliway side of the transaction.”
This, he explains, is a far less disruptive situation than may have arisen had there been bespoke integrations between each application and the WMS. “It makes integration a whole lot easier when it is all in one place. In practice, it meant we could just replicate the messaging and there was very little change required from the perspective of our customers, unless we collectively agreed to take opportunities to deliver new functionality. We knew what to expect in terms of scope and detail of the messaging exchange, so our upgrade for them was really low touch.”
A similar ace was apparent when construction company Stevenson upgraded its ERP from a legacy JD Edwards system to Microsoft Dynamics NAV (NAV). Again, an existing hub and spoke integration model made for a smooth switchover from the old to the new.
Anthony Bitossi, Chief Information Officer says the architecture of the original integration was a major advantage for the upgrade project. “When we were putting in a new CRM system and new software for our weighbridge, we recognised that putting middleware in would allow us to smoothly implement a new ERP in due course,” he explains.
“These systems were then integrated into our outgoing JD Edwards system on a ‘hub and spoke’ architecture. As a result, when we implemented the new NAV system, it wasn’t a matter of redoing all the integrations, but rather a matter of connecting the new system to the hub.”
And, at European Motor Distributors, the use of middleware has enabled it to upgrade its Incadea ERP systems without losing focus on the business itself. Matt Tohill, EMD’s General Manager IT & Digital, says the distributor integrates with multiple dealer management systems (DMS), and so an upgrade potentially impacts on companies the length and breadth of New Zealand. Not so with middleware: “With Flow, we pump data out from a single source, Flow manipulates it into the format required by each of the different DMSs. That’s relevant, because at the time of the ERP upgrade, it again meant that we only had to deal with one solution – our Incadea which we were upgrading – rather than having to interfere with the integrations across our supply chain.”
A solid middleware infrastructure doesn’t just take care of immediate needs, it also provides for the inevitability of change. That’s confirmed by Bitossi, who says that if any other applications need to be swapped out in future, much of the integration is already done. “We don’t have to touch [our middleware] as it connects to NAV; it means we only have to deal with the side that connects to whatever other applications we might introduce. For example, when we upgrade Command, we can do that and run User Acceptance Testing, without needing to reengineer the connection to NAV.”
Bitossi says choosing an integration platform has proven ‘a good decision to make’. “It is hard to compare what we have done with any alternative and certainly the transitions from one ERP solution to another hasn’t been without its hiccups. But I’ve worked with a lot of different IT vendors and Flow has to be right up there if not tops in terms of service delivery.”
For EMD’s Tohill, he says at the time of the ERP upgrade, middleware enabled his team to focus efforts where the results can be found. “Not having to deal with multiple integrations across teams not directly under our management has meant a substantially easier project. Flow’s people worked with us on a case to case basis with an integration map and user acceptance testing to make sure that all the points that we touch worked suitably well. That made life a lot easier, rather than having to go to a bunch of organisations, vendors and partners; working with one piece of middleware meant that at our end, we migrated to the new ERP effectively.”
And asked how important integration is to a project like his, Burrow is unequivocal. “It’s a big part of it. We use Flow for all the integrations between our business and our customers and the successful operation of the WMS isn’t possible without it. And being a Kiwi company not only means direct access to the people, it also means a shared ethos of getting things done.”