When Nietzsche declared in 1882 that “God is dead,” I’ll bet he had no idea that ERP system vendors were already queuing up to fill the gap.
He just wasn’t the practical, forward-thinking kind, that was his problem (Nietzsche, I mean, not God).
Now, in heaven, they take the long view. So when they started casting around for a replacement to their legacy system, they took the time to conduct a thorough software evaluation process.
Which meant, of course, defining their objectives first. I imagine the boardroom conversation went something like this:
“Lessee, now, we’ll be needing a strong CRM component—those help desk requests are really starting to clog up the system… and to be honest, our field reps could use some tighter linkage with head office, know what I’m sayin’?
“And as for accounting functionality, OK, now here’s the thing. Forecasting numbers are a little unreliable since the Big Unplug… plus, you should see some of the inventory management headaches we’re getting into—transubstantiation, schmansubstantiation, you ever try reconciling a holy trinity when one of ‘em’s dead, fer cryin’ out loud? And anyway we’re thinking of rebranding our bread product line. ‘Bi-weekly bread’, now that’s got more of a ring to it, don’t you think?
“Oh, and we’ll need some sort of RFID mechanism for the new soul transportation system—ha ha ha, remember that guy who smudged his bar code on the way up?”
Enough. For those of you who aren’t dead, I offer this roadmap to follow for software selection. It’s part of a best-practice software selection manual we’re publishing in the months ahead, and I invite you to share your thoughts—leave your comments below!
Phase One: Research
Define your objectives
Develop your business case
Identify your stakeholders
Interview your stakeholders
Select your project team leaders
Select your project champions
Select your subject-matter experts
Achieve consensus and develop your list of requirements
Create your long list of vendors
Disqualify unsuitable vendors and handle disputes
Send letters of continuation to selected vendors
Phase Two: Evaluation
Structure and prioritize your list of requirements
Finalize your list of requirements
Translate requirements into a decision model
Export your decision model to your RFI
Send your RFI
Create rules for extensions
Collect RFI responses
Incorporate vendor responses into decision model
Analyze, rationalize, assess, and rank the data
Validate and verify the data
Develop a working list of vendors
Create a ranked shortlist
Notify rejected vendors
Phase Three: Selection
Select a shortlist of three vendors
Develop a demo script
Invite vendors to conduct demos
Invite vendors on-site to show them your environment
Perform reference checks
Issue an RFP to your shortlist
Analyze RFP responses
Conduct product demos
Perform user trials
Assess implementation proposal
Conduct a TCO analysis (pricing)
Analyze market data
Visit reference company sites
Quantify the subjective assessment
Revisit your analysis
Make your selection
Phase Four: Post-selection
Negotiate the contract
Obtain executive approval
Notify rejected vendors
Notify the winning vendor
Sign the contract
Plan for implementation
Conduct installation and configuration (or migration)
Perform user testing
Develop due diligence report/audit
Again, your thoughts are welcome… leave a comment below!
Well done! The steps listed are true to life high level sequences. How about some more.
Great overview of the selection process, but the implementation steps are oversimplified. There are at least a few dozen major activities that need to take place during a successul implementation. You may want to check out our PERFECT Path implementation framework on our web site for ideas.
Thanks very much for commenting on my post. You’re absolutely right to say the software selection process is a complex beast—indeed, the steps I refer to above are simply the highest-level overview of the roadmap. This was brought home to me when I started working on the definitive manual itself, as I saw section headings balloon to textbooks in themselves, plus appendices… Needless to say, selecting enterprise software can quickly turn into a financial and logistical nightmare if you’re not covering all the bases…
I think it is also important to definea set of criteria to be used in Phase 2 and Phase 3. These should be discussed with the Steering Committee and get their final approval. This away personal bias is removed from the entire process.
Also some where early in the whole process it will be important to establish a Steering Committee to get visibility of the entire effort and managment support.
I think it really important for use software selection process
Ifyou achieve the following
1 Requirements 100% correct
2 Fit(available in market) 80%
3 Implementation success 80%
4 Change managementsuccess 80 %
5 Daily Usage 80%
the persentage sum 100*80*80*80*80 = 41% effective ???
Enjoyed the post. As Eric pointed out, implementation is a book unto itself, but this wasn’t really aimed at implementation. let’s take a crack at that one!
I like the frequently overlooked mentions of “handling disputes”. This springs from actual experience!
This is typical of most selection processes … 95% focus is on the software when in actual fact 95% focus should be on the team who are going to support the client. Today, most ERP packages cover the all the basics, so as long as you select one with a background in your industry, country and size you are probably fine. It has been proved time and time again that average software with a good implementation team will go far. Great software with a poor team will fail. Check the sales team, check the implementation team, check the support team and dont forget to check the management as they are the guys to bring it back on track if the project starts to waiver. If they have all been there - got the tee shirt you are well on the way to having a successful project.
It is very useful information , every on must know in the industry.
Great post with some very good follow up comments. In particular I like Terry Wilcox’s comments. Even the best package cannot succeed unless a solid team is in support of the launch.
Great overview of the selection process.What I can share is: after 3 MRPs implementaion,where most of the gaps started “customizing” the software (very wrong in my vision today);the ERP project was conducted using “best practice selection”.
From what I can recall,a team with IT and global key users (from logistics,supply,demand,item master…) built up the RFI questions which at the end generated a Balanced Score Card that helped the organization decide the best solution for the organization.
I think following questions with regard to product selection is pertinent.Please review
1 What services are offered by the product?
2 To whom the services are offered to?
3 How is the internal and external market places developed?
4 How is the value created to the client by using the product?
5 “how robust business cases will be created to secure strategic investment in
service assets and service management capabilities”
6 “how the allocation of available resources will be tuned to optimal effect
across the portfolio of services”
7 how service performance will be measured.
II Competition and market space
1 Who are competitors of the product?
2 How the product is differs(Extra or no value add) when compared to the competitors
III Understand the 4 Ps of the strategy of the product
Perspective:What is the distinctive vision and direction of the product?
Position: The basis on which the provider will compete
Plan:How the service provider achieve the vision?
Pattern: What is the distinctive patterns in decisions and actions of the service provider?
IV Service value
Service utility :What does the customer gets in terms of outcomes supported or constraints removed?
V Service management
What capabilities does the product operations required in terms of
What resources are required for implementation of product
Vi What are critical success factors to identify , measure and periodic review after implementation?
VII Can the product be used as managed service, shared service , utility service?
VIII Organisation design and development
On implementation of the product is there any requirement for organisation structure changes?
Souring Strategy: Internal services, shared services, full service outsourcing , prime consortimum or selective outsourcing
Service Analytics: How the service performance be evaluated using the technology?
Lost in the high level line items is the question of deployment and licensing. Too many leave the question of SaaS or on-premise to the end, saying they could go either way. IT and Finance should make that call at the beginning so the selection team isn’t short listing vendors that will ultimately be rejected.