One common issue, often discovered just before go-live, is an expanding set of needs or other requirements that surprise the team. This may be a sign of resistance to change, but if the requirements are valid, a solution may be hidden in plain sight. Too often, users need more time to approve a design or a process
Approving an ERP design process does not have to feel like buying a timeshare. Years ago, I was offered a free week’s stay at a vacation property if I agreed to a two-hour tour and an explanation of how the timeshare worked. I agreed, took the tour, and then was offered the opportunity to buy into the timeshare.
I believe that “offered the opportunity” is a generous description. I felt pressured to make a decision that I was uncomfortable with, and I had to make it then, or the offer would never be repeated.
Approving an ERP design should feel better. Business process owners should only be put in the position of approving a design change once they understand how well the process will work, how often they will use it, what the alternatives are, or the work involved in using the design or building it.
That might seem obvious enough, but I have been involved in design sessions where requirements are discussed, and a design is documented, primarily in text. A signoff is requested so that development can begin, and before fully understanding what they’re getting into, a business process owner has committed to a decision they later regret. The project schedule may be used as a hostage in this process.
The way it should work, and the way the Ascendex methodology works, is that we begin with enough training to ensure that users fully understand how the system would work for them out of the box. Training is hands-on to provide a clear understanding of how it will feel to use the system. Any necessary changes are fully explored to ensure that the best solutions are considered, and designs are prototyped to create a thorough understanding of the proposed change. Once complete, the design is tested for usability, with an opportunity to make appropriate changes.
Minor design changes may not be worth belaboring. But even design changes that seem minor at the time might cause inefficiencies that add up to hundreds of hours over time. It is better to take the time to ensure the design is right during the implementation process than to live with substandard software because someone was trying to meet a deadline.
