Organizations decide to select new Enterprise Software packages for a variety of reasons. Business growth may lead to the need for a more robust solution with wider functionality and the ability to deal with multi-site, multi-country operations. Legacy systems may be regarded as old-fashioned and lacking in up to date functionality. The corporate acquisition may lead to the need for systems harmonization across a group and a new group-wide strategy may be called for resulting in the need for a new system.
Once the decision has been made to proceed, then the selection process should aim to identify a product that will provide easy to use functionality, efficient business processes, will have management approval, user acceptance and a positive return on investment for shareholders/stakeholders. In today’s challenging economic environment, investment in a new system can help an organization move ahead of the competition and although the implementation process may prove costly in terms of time and resources, the long-term productivity and efficiency gains for the business can be significant.
Package selection is never risk-free
Selecting a new Enterprise Software system can be difficult and time-consuming. Due to organizations of Enterprise Software products available in spite of recent vendor consolidation it is not unusual for organisations to select a system that may not completely meet their needs. This may result in a more costly and lengthy implementation and extra post-implementation costs. It is estimated that almost 90% of Enterprise Software implementations run over time and budget, usually due to poor planning and the underestimation of time and resources required for specific tasks such as data migration. Project milestones can be overly ambitious, aimed at satisfying the needs of senior management who will have high, not always realistic expectations. It pays to be cautious and realistic with these goals during the planning phase to avoid the risk of having to explain later why deadlines have not been achieved and the system is not immediately able to provide the expected benefits.
Software deployment projects have great potential for error but once the process has been started it is advisable to allow them to run their course despite any problems encountered. It is not uncommon during a selection process for senior management to delay decision-making or the implementation, as during the process it will quickly become evident how much time will be required and how much the project will cost. This may make senior staff reluctant to proceed even if a clear business case has been established. Cost-benefit analysis can be carried out during the decision-making process to establish the savings to be gained from the new system and the longer a deployment is delayed the greater the loss to the business in terms of the savings which would be made by using the new system.
With the right team in place and the correct deployment strategy, the organization can ensure they make the correct choice for long term business and user benefit and ensure that the new system is implemented efficiently, on time and to budget. Selecting the right software is the first step in a lengthy process and will help prevent implementation problems, surprise costs and should mean that teething problems are reduced once the system is operational and should lead to high levels of user satisfaction.
The following 10 step guide outlines the process required to successfully select a new system and if followed will ensure the organization selects the Enterprise Software product they need to meet their specific business requirements.
1. The selection team
First-class project management is the key to success for any major Enterprise Software change project and the participation of experienced, appropriately qualified change consultants with the appropriate mix of technical and soft skills and ability to work effectively with users and the business is a pre-requisite. A team should be assembled to conduct the project once the business case has been established and the decision made to select a new system.
The selection team should be familiar with the process including gathering user requirements, identifying potential vendors, liaising with vendors, attending product demonstrations and obtaining customer references. The team should include an influential sponsor from the organization’s executive management team who will ideally report directly to the CEO and will have support from fellow Senior Directors and other top managers in the affected business areas.
The Project Manager should coordinate the internal needs assessment for the business, draw together a team from the business to assist with the selection process, liaise with software vendors and manage the evaluation process. Changing Enterprise Software is a business decision and not purely about technology. The selection Project Manager will often be the Finance Systems Manager or a member of the Finance team, however, some organizations hire externally for this role so the selection process is carried out impartially. A Consultant with a broad range of systems and selection experience may also be engaged to provide specific product advice. If a third party is used to run the selection process an in-house Project Manager will still be required to oversee progress and ensure the needs of all parts of the business are addressed during the selection process. Although using this approach is less disruptive in terms of the use of internal time and resources, many organizations prefer to keep the selection in the house and oversee the process themselves. It is important to ensure that the external party is completely impartial and has no connection with the software vendors and it is advisable to seek references.
The selection team should include individuals from all functional areas of the business affected by the proposed software change. They should be positive about the process and have a clear understanding of the needs of their specific functional area. These individuals should be champions of the new system, have good relationships with departmental colleagues and be able to gather information effectively to help the process and pass on knowledge to colleagues and keep them informed about the selection process. Employee input is critical in any large system change project, as employees who will use the new system daily will play a vital part in identifying current processes that are inefficient or ineffective and will be able to suggest functionality that will benefit their day to day working lives. Securing user buy-in for the change process and ensuring they are receptive to the new system is essential. People are naturally conservative and suspicious of change and may reject it if the process is not handled well, therefore ensuring user involvement in the process from the start means that they will be more likely to be supportive and helpful throughout, will wish to participate in the change process and be positive about the new system once operational.
It must, however, be remembered that users involved in the selection and subsequent implementation process will need a reduced “day job” workload during this period and additional resources may be required to cover some day to day activities otherwise multiple demands may have a detrimental effect on the change program and may result in bad feeling which can put the project at risk.
2. Needs analysis/requirements gathering
It is important to define early on what the business aims to achieve by introducing a new system as critical success factors will not only help determine business needs but will help keep the project on track and focused on the most crucial business objectives. If the business does not know exactly what it wishes to achieve in terms of cost saving, time-saving, streamlined processes, additional functionality and improved reporting processes then it is unlikely to select the most appropriate system. It can be hard to identify all the features and functions required from a new system, so it is normally advisable to review current system functionality, what is used, what isn’t and discuss with users their likes and where improvements can be made. It is also important to look at the organization’s future plans to ensure that the new system is appropriate for these needs.
It is possible to obtain a list of key features provided by software vendors,, however, at this stage, it is more important to focus on business process rather than be distracted by features which may not be relevant to the business. Situations where users spend most time or have the most difficulty searching for or adjusting data are typically the areas of functionality which require an overhaul and will need further investigation. The business must also ensure that these requirements are totally unambiguous and not open to misinterpretation as vendors respond to requirements in the same way and can be compared ‘like-for-like’ without further need for information requests. It is important also to establish which success factors really are critical for the project and which are simply ‘nice to have’ if costs and functionality allow, and these factors should be listed in order of priority. Essential functions such as ease of integration with current systems which will be maintained or the ability of the software to run on current hardware (if the business is unable to replace it) should be looked at first as these factors can instantly disqualify certain vendors. Differentiating standard or basic functionality available in all software packages from requirements that are unique to the business is also important as this will separate one vendor from another. Introducing new software should provide the opportunity to overhaul and improve business processes rather than simply provide new software to replicate previous processes. Rather than simply introducing a new system running legacy processes, the business should look to make improvements across all relevant areas so the new system can take advantage of streamlined, more efficient working practices. Finally, the software chosen should offer value for money and a positive return on investment so that in the long term the change will positive effect the bottom line and will not be so expensive that it creates significant short-term problems for the business.
3. Long list of possible software products
There are various ways to obtain the initial long list of potential vendors and most finance systems professionals will be aware of the established software vendors and are likely to have worked with a number of systems themselves previously. But however knowledgeable the Project Manager, it is important to conduct a proper market review prior to selection to ensure every option is considered and none are discounted for evaluation. The selection team may be surprised by the service and functionality offered by the smaller or less well-known vendors and should not automatically opt for the more established well known brands. At this, stage it is also important not to discount software resellers who may offer their own in-house developed functionality and workarounds, more competitive pricing structures and perhaps a more personal approach to account management and support. Sources of vendors and resellers available can be found using internet search, industry publications, colleagues, consultants, other industry contacts, conferences and seminars. Remember that at this and every stage of the process people are vital and communication should be as open as possible to obtain information from as many sources as is feasible.
4. Contacting potential vendors with requests for proposal (RFP)
Once a long list of resellers and vendors has been identified and system requirements defined and prioritised, these requirements should be clearly communicated to the vendors in order to allow them to decide whether their software offerings meet the requirements. A Request for Proposal (RFP) should be sent to each potential vendor asking them to respond if their software is able to meet the needs of the business. Vendors should be challenged with questions related to the defined critical success factors such as cost, functionality, customisation potential, technology, implementation, support and licensing. It is important that questions are clear and unambiguous in order to get a consistent response. Where possible vendors should respond to each requirement with a number relating to its availability and this can be used to give each vendor a score based on the ‘fit’ of their software to the business, although of, course this will not always be possible with all responses. It may also be beneficial at this stage to send an RFP to the businesses current software vendor for comparison, and it should not be discounted as by adding some additional modules, functionality or an upgrade it may be the case that the current software product may be the best fit for the business saving an expensive and lengthy implementation process. Evaluating the responses to a number of RFP’s can be a very time-consuming and in-depth process, if the long list is too long, it may be more practical initially to send out a shorter list of key questions to vendors generally referred to as a Request for Information (RFI) covering only essential features and major requirements, to reduce numbers prior to sending out full RFP’s.
5. Initial evaluation and short-listing
The responses obtained from the RFP’s can be used to score vendors on the suitability of their products and how closely they fit the business requirements and this should help reduce the list of potential vendors to no more than 4 which can go forward for further evaluation. RFP’s should be assessed quantitatively with a grading system weighted towards the most critical business requirements and scoring algorithms can be used for assessment. The scoring and weighting system and any criteria used in the initial selection should be pre-determined during the requirements gathering phase so that evaluation is objective and avoids any bias. The lack of basic features such as critical functionality, the ability of a system that interfaces with legacy systems or databases may mean that some systems are instantly discounted; other evaluation processes may be more complex.