Getting the Most from Your Planning Implementation

Most planning implementations succeed at installing software and stop there. The tool goes live, the licence is paid, and eighteen months later the planners are still running the decisions in a spreadsheet beside it. The difference between those outcomes is rarely the technology chosen. It is how the change was designed.

## The project is the easy part A go-live is a date. A capability is a habit. Between them sits the part of the work that is hardest to schedule: helping a planning team stop doing something the old way, trusting a number they did not build themselves, and being accountable for an output they can now see. Projects that plan for the system and hope for the behaviour usually get the system.

## Decide what you are actually changing Before configuration begins, be explicit about the decisions that will move. Not the reports that will be available, the decisions:

• Which planning decisions currently made in spreadsheets move into the system, and in which week
• Which meetings change their input, their agenda or their purpose
• Which measures stop being reported, because they reward the old behaviour
• Which roles lose a task and which gain one, named by team
• What the business will stop doing entirely at go-live, rather than in a later phase

## Data quality is the critical path Planning projects are usually late because of master data, not code. Item masters with duplicates and dead items, lead times that nobody has reviewed since the last supplier change, customer hierarchies that no longer match the commercial structure, and units of measure that differ between systems. None of this is glamorous and all of it gates the plan. Start the cleanse in the first month, not the month before go-live, and give it an owner on the business side.

## Design for the planner, not the demo Configuration choices made to look good in a workshop often produce a system that is slow to use on a busy Tuesday. Test with real volumes, real hierarchies and real exception rates. If reviewing the forecast takes a planner four hours instead of forty minutes, they will stop reviewing it, and the process will quietly return to the spreadsheet.

## Adoption is a design decision Adoption follows from three things: the new way must be visibly faster for the person doing it, the exception must be easy to raise, and the consequences of ignoring it must be real. Training matters far less than whether the planner's week gets better. Where a parallel spreadsheet is tolerated after go-live, the old process wins by default, because it is the one people already know.

## The first ninety days Plan the post-go-live period as carefully as the project. Weekly reviews of what is still happening outside the system, a fast route for fixing configuration, and a named owner for each measure. Most of the value is created in those ninety days, and most of it is lost if attention moves to the next project on day two.

Explore our implementation service, data management and training, or book a demo to discuss a phased rollout.