There are many reasons for a failed implementation and today’s blog post will highlight a few lessons learned from not doing a proper software evaluation. A methodology that is clear, concise, systematic and provides qualitative results are the starting point to avoid these mishaps during a software implementation – after all it starts with an evaluation leading towards software selection. This article will outline 4 mistakes made when selecting enterprise system software an include an example of a mid-sized healthcare facility that made all four of these mistakes during their evaluation process.
Lessons learned from not placing the correct importance on this step have far reaching and sometimes detrimental effects if not done properly. A few lessons learned from our past experiences on not using a methodology for selecting software and some of the consequences are listed below.
- Strategic Fit: A company that had just engaged us in an evaluation. It turns out the company’s CEO was coming back from a business trip and as luck would have it he was sitting next to an SAP account executive. After several hours of speaking with SAP it was decided by the CEO that this was the system that they selected and the evaluation process was subsequently scrapped. This was a mid-sized company and they were sold the Enterprise Business Suite. After implementation was completed a follow up with company revealed that the system was too large for their capacity. The external scope creep, clouding of objectives, management of the project (both internal and externally), budget over-runs, time delays and administration proved to be problematic in this installation. It turned out that SAP was too much of a resource drain on this particular company for financial resources, people and essentially paying for what was not used. The lesson here strategic vendor fit, and software fit are crucial when selecting enterprise software.
- Wrong system type: We had a customer contact us about how slow their ERP system was. We had tried some database tuning techniques to speed up the system. This proved this was a slow and costly process as outside programming help was needed to tune the proprietary database. This however did speed up their ERP but that still was not the problem. After speaking with the company in more detail we discovered they were sold a discrete ERP type system and they were indeed a contract manufacturer as their core business. The ERP they had selected was not the correct fit for what they had set out to accomplish originally. The lesson here is don’t let scope creep or a fancy vendor demo win you over, stick to your guns.
- Unnecessary vendor disqualification: A lesson learned from doing a proper software evaluation is that do not withhold information on how you run your business to vendors. After all vendors are future business partners not just suppliers. The vendor would also like for you to be a customer who is truly happy with their software purchase and can be used a reference site. When organizations hold back information and see if the vendor can fill in the blanks within their industry and own company can disqualify a very capable vendor. A best practice here is to fully disclose what your needs are so that the vendor can guide you as well as put forth their best effort to solve what you are looking for.
- Previous selection experience becomes the method for evaluation: A common mistake made by organizations is that people who have been through a software selection at previous companies become the subject matter expert for the software evaluation. Often a familiarity will introduce biases (political, organizational, technical) in the evaluation process. An evaluation procedure is a procedure that precedes the implementation. This is a certain set of skills validated with a proven method that drives consistent results to finding the right software for your company. While someone with previous experience is a valuable tool it should be added in conjunction with a proper systematic method of software selection. If also that person were to leave for another company as is now quite common you may be stuck with system that does not have full support and does not meet the original intended requirements. The lesson here is take under advisement the previous experience and add that to the methodology of software selection to create a full functional roadmap for the selection process.
A situation where a specific healthcare organization committed all four of the previous errors occurred. The healthcare facility was looking for a system to manage patient care records, handle procurement for the facility, administration of medication if possible, billing for client care, employee tracking (human capital management)and patient check-in were the major requirements that this organization needed.
From the onset of the project when the project team was assembled any employees that had previously experienced a full lifecycle implementation of major software was automatically elected to the project team. While these employees can offer valuable insight to the selection process they often do not follow a methodology for software selection. These employees automatically became the subject matter experts on evaluation, which is incorrect.
The method used for checking – in patients at the front desk was focused upon as the main requirement causing this team to just start to evaluate CRM systems, the wrong system type. This was mainly where they thought the type of data entry that the system will accommodate and where the data is actually entered determined the system type required. Due to the leaders insisting they needed a CRM it wasn’t much disputed however, the lack of consideration to the other requirements and deficient prioritization of required functionality further clouded the evaluation process further. Because of the familiarity of the popular systems such as Oracle, SAP, MS etc. vendors were automatically selected that were way too big for the facility to implement. The strategic fit for scope of the software in terms of features, resources required to implement (both internal commitments and external consulting, budget and needs were misunderstood) and of the vendors fed into to this misconception.
It turns out that this organization committed all four errors when selecting their software. After several months of being victimized by scope creep, endless vendor demos , cost overruns on consulting and not getting any results Eval-Source entered to straighten out the selection process. After speaking with the staff through interviews and requirements gathering and reassigned what was actually needed we applied our Tru-Eval methodology to their selection process. We refocused the needs for the system, helped them prioritize their needs and introduced the correct way to select software. Once we determined that an ERP for service based business was required with a healthcare vertical focus which included strong content management for the PACS requirements and the other requirements were easily taken care of by offering the right functionality to the facility which they ended up selecting the correct software to match their business needs
As can be seen there are many reasons why companies struggle with software selection but hopefully these lessons learned can help mitigate some of your own dilemmas and make you more successful at selecting the correct enterprise software for your business.