So you have been tasked with finding a new software, be it ERP, CRM, SCM, HRMS or whatever you may need or want. For some, this is an exciting challenge that has been discussed and planned, and for others, it’s the last thing you want to do but needs to be addressed. There are general best practice steps in evaluating software, such as documenting requirements, evaluating long and short-lists, preparing for demonstrations, etc., and then there are the “gotchas” that are often overlooked. Here are a few of the “gotchas” that often creep up:
Before embarking into the assessment of available software packages, make certain you know what you are actually looking for. Having a roadmap that includes current and future state, budgets and timelines for IT changes will better help with any current assessment. We frequently walk into organizations that have wide ranges of disparate systems, some integrated, some not, where departments have simply purchased software for their needs at the time. Before long, the company has overlapping functionality and a range of systems, data issues and extraneous costs. Before evaluating any individual “system”, we recommend looking holistically at the entire platform of systems in place.
Anyone who has ever talked to a software provider has heard the term “best-practice”. How is it that every single software on the market has “best practices” already programmed in their system? Essentially, every software available has some general functionality that fits common practices for a particular industry or functional area. Some larger solutions may even offer “best practices” for a wide range of industries. Here’s the catch: There are multiple “best-practices” for any industry or functional process, and it is up to you to evaluate which will best fit your business model. What a software vendor states as “best practice” may not, in fact, be best practice for your company, it is simply the best practice for what that particular software offers. We still find companies that state they will simply adopt to the “best-practices” available in the new software they purchase, and this can be a very dangerous road.
When asked if they see a need for and support change, most people will assertively state “yes”. When asked if they, themselves will change, we often get a less positive response. As stated earlier, system changes generally require process changes across a business in addition to simply learning to use a new system. This requires people to change what they do, which requires training, communication, top-down and bottom-up alignment and a plan for addressing potential resistance to change. No matter how perfectly a software matches your business needs, unless users are prepared and willing to adopt to the change, the implementation will fail. Before jumping into a software implementation, be sure to consider some form of readiness assessment on who will be affected, how they will be affected, and how willing they are to adapt to the change.
Download "The Beginner's Guide To Creating An IT Business Strategy"
It’s common knowledge that software implementation costs more than just the software itself. Implementation services and maintenance are often considered in cost planning, but there are additional internal and external cost considerations, as well. These can include items such as integration costs with existing systems, hardware and infrastructure upgrades (servers, PCs, database, scan guns, printers, etc.), business processes reengineering, organizational change management, program and project management, consultant or project team travel and contingency, etc. It’s easy to assume that any additional “work” will be handled internally, but then backfilling and internal costs and capabilities will need to be evaluated. Simply put, make sure a Total Cost of Ownership “TCO” analysis has been run before signing up for a software implementation.