Challenge
Many of you have probably been through a major software implementation, such as ERP. You know the drill; knowledgeable employees are asked to create their wish list to share with the software vendors.
I have several concerns with this simplistic approach, but in my opinion, the biggest issue is that the onus is all on the technology. In other words, the software will be challenged on its ability to meet all the requirements, but the organization is not challenged on its own ability to meet the requirement from a process and data accuracy standpoint.
For example, statistical forecasting is a very popular capability that many organizations want to include in Phase 1 of an ERP implementation project. While statistical forecasting has its benefits it could hardly be described as critical, especially since Excel can do the basic job reasonably well. On the other hand, statistical forecasting will require lots of effort. Historical shipment data must be cleansed, planners must be trained, cross-functional policies must not only be developed, but also adhered to.
Some organizations do try to at least prioritize requirements, which is better, but I have yet to see a company evaluate requirements based upon their complexity level. The risk is that the ERP initiative “bites off more than it can chew” and the project is severely delayed, or worse still, fails completely.
Solution
Before you start your next large software implementation project, review your software requirements for impact and effort. First define the criteria, and then rate each requirement on a scale of 1-5 on both axis and plot them on the chart below.
Criteria could include:
Impact
- Compliance
- Customer service
- Cost
- Employee satisfaction
Effort
- Resources
- Data complexity
- Process complexity
- Cross-functional alignment
Don’t spend too much time developing these criteria, but time spent here will pay large dividends later.
In Phase 1, only include requirements that will have a high impact. Obviously, those requirements that have both high impact and low effort (quick wins), should be included in the first phase. However, if a requirement has high impact and high effort (projects), then you need to be realistic about what can be accomplished in Phase 1.
Results
We recently managed a supply chain planning software assessment initiative for a medical device company. Rather than “recreate the wheel”, we start with an initial list of ~150 requirements tailored to life science companies, based upon our experience.
Firstly, we defined the “impact” criteria. Since the fundamental purpose of any supply chain planning software is to accurately suggest to the Planner how much to order and when, we decided that the primary criterion was impact on “planned order accuracy”.
For the “effort” criteria we focused on process and data complexity. This was a new organization, so the initial maturity level was low, so we did not advocate for over-engineering the solution in Phase 1.
From this analysis we were able to reduce this long list to 11 requirements for Phase 1. Below are a few examples:
All these requirements were critical to generate accurate MRP messaged, and none required a high level of process or data maturity, which helped the planning software to be implemented on-time and on-budget.
