Drowning in manual work?
Excel templates crashing?
Human errors plaguing planning decisions?
It might sound like something out of a horror movie to project planners, but this is what a poor system implementation can cause.
On the other hand, an effective planning solution can drastically optimize operations and supply chain planning.
Over the course of my career focusing on system implementation, I have seen what works and what doesn’t, and I’d like to share a few lessons learned the hard way with you.
1. DO Include all Business Functions in Discovery.
Discovery—or scoping phase—is a process of collecting and analyzing requirements about the project. It allows for a deep understanding of the goals, scope, and limitations of the project.
If critical business functions are excluded, you can have gaping holes in the system requirements. For example, not including the finance team in the discovery phase could lead to a significant amount of work on the backend post-go-live to get correct customer pricing into the system for accurate revenue conversions. Similarly, planning without manufacturing and logistics consultation will inevitably fall short of getting the complete picture, so the name of the game has to be “end-to-end.”
2. DON’T Underestimate the Importance of Master Data.
Proper master data management is the genesis of any world-class system implementation. Item level flags, forecasted/non-forecasted, inventory policies, stock types, and bill of materials are just a few of the critical inputs to a well-run planning system/material requirements planning (MRP).
If these are mismanaged, don’t exist, or exist but somebody from the master data team is not included in the design and testing as a key user, you may experience pain points down the road that could have been avoided.
3. DO Include Key Stakeholders in the Pilot Program.
Proper socialization of the new system/process can be the difference between getting cross-functional buy-in and fighting resistance. Including key stakeholders from sales, finance, accounting, and other relevant teams ensures that all of the influencers in each department feel they are a part of the process, their voices are heard, and that they will communicate to their direct reports the effectiveness of the system and how it will address their needs individually.
4. Live in the Goldilocks Zone.
Companies want the minimum cost, maximum result. Paradoxically, this can be a more expensive approach in the long run. Need I bring up the old adage, “you get what you pay for”? Conversely, you get what you pay for can also mean you are paying for too much functionality.
Decreased, non-existent, or partial functionality can lead to process bottlenecks and increased manual work for individuals that the implementation was intended to alleviate. Ultimately, this can lead to increased employee turnover, additional expenses for custom builds, or even the cost of scrapping and starting with a whole new implementation.
Additionally, the most expensive system with all the bells and whistles won’t automatically be the best solution. You may be paying for a vast suite of tools you won’t ever end up using. If I am forecasting a portfolio with one warehouse, 30 SKUs, and no seasonality, it may not warrant all of the extra costs associated with artificial intelligence, machine learning, and advanced algorithms.
Perhaps you need a system that can manage scenario planning, great, but do you also need a node that is running 1,000,000 different scenarios and using historical weather patterns to predict consumer buying behavior when the average annual temperature increases 3%? Probably not.
Live instead in the Goldilocks zone, meaning find what’s “just right.”
5. DO Test All Scenarios.
It may be faster to only test present scenarios, but it’s important to also test future scenarios factoring in growth. Testing and designing with only the current state in mind can lead to huge roadblocks for future growth.
Designing a current state versus future state roadmap can help to ensure that system design and requirements are tailored to potential future scenarios. For example, what would happen if you moved products from one warehouse to three, or launched the ecommerce component? How would that change other factors?
6. DON’T Lose Sight of End-to-End Functionality and Get Lax on Retesting Anything That Failed in IAT/UAT.
If you think about a planning system as an interconnected set of processes that all harmonize together to generate an expected outcome, then you are only as good as your weakest link. IAT/UAT don’t guarantee operational success but rather provides a framework for testing the end-to-end solutions. IAT/UAT is designed to be an end-to-end simulation or trial run for the new system and should be treated as such.
When testing scripts fail in user acceptance testing, it is critical that all the scripts that failed are reviewed, understood, corrected, and retested. Many times, the testing scripts may be related to something that would necessarily impact the actual planning objectives, such as the exception report not generating with correct descriptions.
Likely, issues like this will be put into the parking lot and a go/no-go decision will be made simply on all the critical scripts passing. If the parking lot gets too large, it may become unmanageable and therefore, rationalized.
7. DO Include All Critical Planners in the Design and Development Phase as Key Users.
Specifically, as it relates to the design of the planning functionality, always include the planners and key users in the design process. The planners always have a detailed granular level view of the current process and are immensely helpful in identifying showstoppers that may not be on the radar of anybody else, even at the higher levels.
8. DON’T Allow Exceptions to the New Process Immediately After it’s Implemented.
New process implementation can be painful in the beginning until everyone has mastered it. When the new process has been rolled out but there is something that arises “that is critical to support or else we risk losing the customer and we HAVE to have a response in the next 15 minutes,” it’s vital to not revert to old ways and do something outside the new process to support.
Yes, it takes more effort to not fall back on old habits, but doing so instills new, better ones.
For example, let’s say assessing promotional volume is performed within a certain module and entered by the sales team. Once they enter that promotion, it flows into MRP for planners to assess whether they can support it. In order for that to happen, MRP has to run and that won’t happen until tomorrow.
Reverting to the old faithful spreadsheet and running a manual MRP to give a quick answer outside of the system is something that is tempting…but should be avoided at all costs.
9. DO Create a Time Buffer at Every Checkpoint.
This is a critical piece of the implementation process. When very important testing phases are rushed because go-live is approaching, it’s easy to miss important details. For example, add a one-week buffer for each phase of the system testing to allow for audibles, retesting, or redesign. If there are no time buffers, it will squeeze the amount of time left prior to go-live and you can overlook critical checkpoints.
The reality is, this is a framework that exists and is deployed across many organizations. It’s not rocket science. Where it gets complicated is when the framework and the recommendations at each checkpoint are not followed.
The good news, however, is that if the framework for agile system implementation is followed, the correct people are involved, the process is adhered to, and old ways are not resurrected, then your implementation should go smoothly, fingers crossed!
I once read a quote by computational data scientist, Donald Knuth, who said, “Computers are great at following instructions, not reading your mind.”
Why is this relevant, you might ask?
People.
A system is only as good as the people who operate within it and a process is only as good as those adhering to it. A successful planning system implementation is every bit as reliant upon people as it is technology. It’s the intersection of the two where all of the dos and don’ts of system implementations come alive.
Share: