Clinovera
First Line Software is a premier provider of software engineering, software enablement, and digital transformation services. Headquartered in Cambridge, Massachusetts, the global staff of 450 technical experts serve clients across North America, Europe, Asia, and Australia.
Most of you will be familiar with the term “30,000 ft. view” when describing a business concept that looks through a wider lens at the bigger picture. This is usually where we want to begin when starting our research on a particular topic that we’re still learning about. However, after taking in that sweeping vista from your business-class window seat for a while, you’d like to get on the ground and see what you’ve been looking at in more detail. The view today will be from ground level looking at a few specific examples of WMS integration and the how’s and why’s of successful implementations, and some issues that could have been avoided in others.
Hopefully, by seeing what works and learning from what others should have done, you can get a better view regarding what’s needed to get your own Warehouse Management Solution off the ground.
Let’s begin with a couple of WMS integration missteps, and how they could have been avoided.
Losing Focus
Story 1. What is desired is not always what is possible
Company X has a complex warehousing system where goods are continually moved from one storage facility to another. A technical brief was written up by Company X on how it wanted to implement automation for a more efficient flow of its goods within the system. As part of the brief, a simulation was created that (in part) identified where their product was at various given points throughout the journey between the facilities.
It should be noted here that creating virtual simulations that actually prove how existing hardware, new equipment, and software can work together with a relatively high degree of accuracy is extremely complex and time-consuming. The simple term for any realistic simulation is: Very Expensive. However, it’s very useful as it’s far cheaper than buying and putting all of the actual hardware and software together, and finding out your multi-million-euro investment does not work as it’s supposed to.
Here, Company X did the right thing and created the model. But, as the entire technical brief was reviewed by the vendors implementing the project, it became clear the model was not realistic for executing in the real world. The simulation was based not on what was possible for goods movement within the warehouse system, but on what was desired. The desired process should have been tried manually several times to see if it was viable before spending time and money running a costly simulation in the technical brief. As the saying goes, “To properly landscape a garden, you must first walk the garden – only then, can you lay a path”.
Story 2. Not as simple as “cut-and-paste”
Company Y is an international organization that has warehouses in Europe and North America.
An automated WMS was already implemented and up and running in Europe. Company Y wanted to duplicate that successful warehouse in North America. It was thought that much of the development costs have already been absorbed in Europe and that a “cut-and-paste” approach might save money when applying it to the warehouse being updated in North America.
This strategy would prove somewhat costly, as the WMS integration in North America should have been treated as an entirely separate project from Europe (or any other location for that matter). The majority of the technical brief was carried over to the West from the East and much of the development process was assumed to be relatively simple since it had already been done before.
Subsequently, the customer did not pay as close attention during the pre-production process to various decisions being made as it should have. The vendor ordered and implemented the systems and interfaces as were specified in the technical brief. As can be imagined, during the testing phase (not long before the updated warehouse was to go live) one of several problems became apparent; one of which was the system’s graphic interfaces did not make sense to the North American site. Various costly decisions had to be made on the fly before everything could work together as it should have.
Lessons Learned
There are a couple of points to be learned from these companies’ missteps. Specific to Company Y’s case, you need to know the equipment standards that are applicable in a given geographic area or country. Even equipment from the same manufacturer can be location-specific, and in some cases may not be compatible with your existing hardware or location.
Ultimately, the most important lesson to be learned by Company X and Y is this: You, the customer, need to control what is a very complex development process at all stages, and review your requirements as early and as often as possible. Close cooperation with the implementing vendor is key (preferably there is one vendor for both software and hardware). Both of you need to agree on the specifications of all the systems.
Ideally, you will have no middlemen in the process. Direct communication between you and your software/hardware implementer will ensure the least number of problems before a successful WMS integration and launch.
The next two companies faced some very challenging situations. Here’s how they dealt with them…
Hyper-Focused
A major international automobile manufacturer needed to update its legacy analog-to-digital data systems, and integrate new hardware with existing equipment in one of its central warehouses. As previously mentioned, simulators are invaluable here so they can imitate the legacy hardware to make sure it can integrate smoothly with the newly updated hardware and software choices. However, in this case, acquiring the raw data to feed into the simulator to make it as realistic as possible was a major challenge.
Observation and analysis of the system’s prior network traffic, data exchanges, and equipment movements were the first steps. Unfortunately, in this first step, there was a notable lack of existing documentation. It became necessary to create some of the raw data from scratch before a simulator could be developed.
Everything from highly sophisticated Programmable Logic Controllers to reams of paper media was examined to understand the complex data streams from different systems. Web cameras were set up to monitor and record what was happening in the warehouse in real-time. This was a huge amount of effort to simply understand how the customer’s system processes its data before it could be used to create simulators.
All of this work had to be done just to determine the feasibility of integrating the desired new systems with the legacy systems. In the end, all of the front-end toils paid off as the legacy systems were smoothly integrated with the new, and the customer was extremely pleased with a modern, updated central warehouse.
Lastly, we’ll look at a heavy-equipment engineering company headquartered in Europe. Large equipment production is carried out at its 850,000 sq m plant. There was no dedicated storage area at its facility – the parts, from small items to giant assemblies weighing several tonnes, were manufactured in various workshops and then stored throughout the plant.
Therein lay the complexity of automating such a hybrid facility, as company representatives explained. Prior to the project, the stored parts were inventoried “on paper”. As a result, company management decided to automate the storage area of the plant by combining disparate storage racks into the general warehouse environment and automating the loading and shipping processes.
The German group viastore WMS SYSTEMS Gmbh, with viastore WMS was chosen as the supplier. The set-up and customization work was carried out by First Line Software, the official partner of viastore WMS SYSTEMS. Project realization took six months. During this time, the viastore WMS system was deployed on-location and integrated with the company’s own infrastructure. The project allowed the plant to get rid of paper records and streamline the process of unloading while solving the problem of temporary storage.
The whole system is integrated so that the delivery of parts to the assembly shop originates from one place. What makes this successful WMS project so unique is the fact that it’s not strictly speaking a warehouse. The automation here is integrated into an incredibly dynamic, heavy manufacturing, and assembly environment.
The Take-Away
How do a major automobile manufacturer and a heavy-equipment company’s success stories apply to your future WMS integration needs? You may see two companies with large budgets that will allow them to overcome any obstacle when automating their respective processes. However, the underlying strategies to achieve their goals are relevant to you and your own WMS plans.
In the case of the automotive company, it did not skip any preliminary steps and was actively collaborating with the vendor to ensure absolute accuracy in the data it was collecting. This active communication allowed for an incredibly detailed Technical Brief to be created, which in turn made the actual hardware and software installation go smoothly.
The definitive smart play by the heavy-equipment engineering company was to utilize the “one-vendor” concept. This ensured smooth automation integration, and easier future updating and servicing of both software and hardware installations.
Not every WMS developer vendor can claim experience in these processes. Take your time in looking for a vendor with a similar attitude towards business and corporate culture as your own.
Perhaps there are greater lessons to be learned by making mistakes. But when it comes to bringing a Warehouse Management Solution to your business, take the right steps and allow your company to be a class example in how to do it right the first time.