The WMS Go Live: There is a Better Way!

By Josh Owen, CEO and Co-founder

“That was awful!”, “We barely survived!”, and “Never again!” are just a few of the many phrases I’ve heard uttered at the end of “successful” WMS Go Lives. A “Go Live” is the action of operationalizing changes to production systems and/or processes, often after months if not years of preparation and work. Arguably, the WMS Go Live is one of the more complex projects to execute successfully. Unfortunately, success is often measured in degrees of painfulness.

I’ve been on-site, and a critical player on many WMS Go Lives over the past 15 years. Some were better than others, but there are a rare few which I look back on with fond memories. Even in my early years deploying these complex systems, it felt like there must be a better way.

For years I watched and participated as we worked tirelessly, for hundreds of hours per week, to deploy more and more advanced and modern solutions using the same old processes and tools. The juxtaposition of deploying expensive and modern solutions with Perl scripts, Excel files, and little to no testing from end users has always seemed strange to me.

Our implementation practices must continually be evaluated and changed in accordance with the solutions we support and deploy.

Don’t get me wrong, execution systems are certainly big and complex. But, companies like Netflix, Amazon, and even Walmart are making unbelievable strides towards automating and accelerating enterprise deployments and proving this can be done. According to a TechBeacon article, Amazon deploys code every 11.7 seconds, on average.

Let’s admit there is a problem so we can get on with the business of solving it.

Now, there is no silver bullet, but I’m convinced that collectively as an industry we can achieve comparable deployment goals if we can admit there is a problem and we can get on with the business of solving it. Like any problem, there are stages of acceptance.

Using this diagram from Andy Grove’s High Output Management, I would make the case that as an industry we are collectively stuck in the “Blame others” stage. There certainly isn’t any ignoring the pain of these large scale projects – that’s not possible. And I also haven’t met anyone who is willing to deny the existence of these challenges. However, there are many organizations and individuals who are collectively willing to put the blame on everyone else.

Let’s talk for a minute about assuming responsibility. For the supply chain execution (SCE) space, there isn’t a singular party “at fault.” But collectively, as an industry, we must accept that this process is broken and all parties play a critical role in fixing it.

The proper balance of people, process, and technology is needed to create and drive meaningful action in the direction of improvement.

People

Large enterprise systems are built, configured/modified, deployed, and supported by a team. Sometimes that team comprises many organizations — from the original equipment manufacturers (OEMs) who developed the system, to third-party implementors, and including the customers who own the business processes which are managed by these systems.

All too often misunderstandings, unclear requirements, and poor communication result in “bugs,” “defects,” or “issues” — call them whatever you want. Poor communication can occur in every phase of a deployment cycle, starting with how a solution is pitched and including challenges in how the OEM developers explain intent or how the third-party implementors understand and configure the system to satisfy the business request.

Like a software defect, the earlier on in a project a miscommunication can be identified and clarified, the less expensive a miscommunication is. Miscommunications can be ironed out by improving some of our upstream processes for identifying business requirements.

But sometimes identifying a miscommunication takes putting the change into practice, that is — putting the change in the hands of the real business users as quickly as possible. Collect feedback, and iterate.

Traditional deployment processes often leave valuable testing as the last phase of the project, at which point any savings potentially achieved by identifying miscommunications earlier in the process have been minimized, if not lost.

Process

Call it whatever you want – waterfall, scrum, agile, kanban, or somewhere in between. The world doesn’t stop while these large projects are being conducted and the more time elapses between starting a project and getting changes into production, the higher the risk that the system has changed, that more requirements will be introduced, and that we’re working on broken assumptions and miscommunications.

We must improve our processes — and focus on a set of principles that can be applied in various contexts. We must leverage modern tools and focus on smaller increments with shorter lead times so our assumptions can be tested, so feedback can be collected, and so iterations can hone our solutions based on real-world usage.

This requires us to rethink how we budget for, plan for, and execute these projects.

Technology

Cycling through the phases of a project in smaller, faster increments allows us to focus on getting results in users’ hands faster for feedback, and saves time spent working with assumptions that will prove to be wrong once deployed. However, adding cycles through the project flow means phases like testing will be a bottleneck if automation isn’t introduced. No matter how well-intentioned an organization is, relying on manual testing alone will limit our ability to capitalize on the opportunity to iterate quickly, with consistency.

A test strategy leveraging test automation empowers organizations to optimize resource allocation and ensures consistency in testing approach, coverage, and repeatability. It ensures you have repeatable coverage and frees up the valuable time of your team to focus on the highest value operations.

Takeaways

It takes all of us — every role in our industry — to admit that it is time to change. The good news for us, is that the problem has already been solved. Other industries are proving it. If we can all collectively assume responsibility we can begin the hard work of implementing the solution and implement a better WMS Go Live.

Continuing to do things the same way, while hoping for different results rarely ends well.

The world has changed a lot in the 15 years I’ve been deploying SCE systems. We have tools available now that make this process easier, and that allows us to do things only dreamed about 15 years ago. If we combine test automation with associated toolsets like continuous integration (CI) / continuous delivery (CD) pipelines, containers, modern deployment methodologies, — and most importantly — modern mindsets, we can achieve new heights.

There really is no excuse for not improving. Make time for this change. It’s important to your industry, to your coworkers, vendors, partners, and most importantly, yourself.

There is a better way; but, you already know that. Maybe you don’t know what it takes to get started. Perhaps the journey seems too overwhelming, and the goal is too far away, or too complicated. But the thing about valuable goals is that they aren’t accomplished in a single day! The only way you’re going to accomplish something really big, something really ambitious — the kind of goal that is going to transform your business forever — is by taking that first, small step. Your industry and your team will thank you.

A Message from Our CEO

Are you interested in learning more about implementing test automation in your warehouse system? Check out our success stories, our blogs, or learn more about the Cycle platform.