Tag: RFP


Successful Enterprise Software Deployment

March 30, 2017

Software

Comments Off on Successful Enterprise Software Deployment


Organisations 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. Corporate acquisition may lead to the need for systems harmonisation 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 organisation 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 the large number 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 organisation 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 organisation 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 he 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 organisation’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 co-ordinate 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 organisations 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 organisations prefer to keep selection in 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 affect 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 focussed 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 organisation’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.

6. Attending software demonstrations and calling references

Inviting about 4 or 5 vendors to provide an initial pre-sales demonstration is a good start to the selection process. Vendors will want to spend as much time with prospective clients as possible at this stage as they wish to establish a relationship but it is probably best to limit these initial sales demonstrations to no more than 2 hours and ensure that vendors focus on the most important business issues and do not simply focus on demonstrating the features of the product they wish to sell. It is advisable to ensure that focus concentrates on the most business critical requirements and unique customisations or functionality. It may reduce time to look at initial demonstrations over the internet rather than visiting the vendor or inviting the vendor on site, although this may not be as sufficiently customised to specific business needs and there may be less opportunity to ask questions.

Although attending software demonstrations is critical to the process more can be learnt from companies who have already implemented the system than from software vendor sales demonstrations trying to gain buy-in. Vendors should be asked for relevant reference contacts so the selection team can discuss the process they went through and the difficulties they encountered during the implementation process and they can provide feedback on post go-live system performance. Preparation is essential when speaking with references and a list of critical questions should be produced although one should be aware that these organisations are vendor ‘success stories’ who can be expected to provide a positive response. It is essential to ask difficult questions about any challenges they faced, any issues they had with the vendor and any outstanding system problems. Contact should also be made with similar companies that use the software being considered and it is worth obtaining informal “off the record” references as these will not have been selected by the vendor. It is also important to ensure that references are obtained from organistions in the same or a similar industry to the business who will have similar business processes, numbers of system users and transaction volumes.

7. Total cost of system ownership

It is essential that before a final selection is made the total cost of ownership of the system is fully understood. Licence fees, implementation and support costs can be obtained from the vendor or reseller, but it should be borne in mind that there may be less costly alternatives for implementation, training and support including independent Consultancies, new in-house staff already familiar with the proposed system or by using the existing in-house team. Other considerations when calculating total cost are man hours, networking, hardware costs and communications and these should also be considered when calculating the budget. Often the hardware used to support the existing system will need to be replaced or upgraded, the extent to which this will be needed should be investigated and added to the cost as it can require significant investment that is frequently overlooked. All direct and indirect costs need to be investigated in great detail, it is poor practice to be surprised part way through an implementation project and software implementation projects are notorious for exceeding initial budgets. Internal as well as external costs should be considered including the time spent by internal staff on the project, distracting them from their usual daily responsibilities is often disregarded but additional resources may be required to maintain basic business functions during busy project periods. It is also important to look at the cost of typical product upgrades post implementation. Most vendors issue regular service packs bug fixes to add minor functional improvements which may not incur additional cost but if in the long-term the company can expect regular upgrades then this may lead to additional costs in terms of licensing, plus time and resources. Companies may choose not to accept all available upgrades immediately but the business needs to ensure that they will not be penalised in terms of missing functionality and support. Future running costs need to be carefully reviewed together with the immediate implementation and licensing cost as systems which are initially cheap to install may require higher running costs in the long term. Additional licence costs may also need to be considered if headcount is expected to increase and pricing structures for different concurrent user numbers can vary significantly.

8. Prototyping, testing and visiting reference sites

It is important to ensure that any necessary customisation will operate effectively and creating a prototype or boardroom pilot for testing is a worthwhile way of firstly ensuring that they work and secondly deciding whether all customisation is required. Workarounds may be adequate in certain instances and the less customised a system, the easier it will be to troubleshoot problems and train staff. It is also simpler to upgrade a standard vanilla system as customisation will not need to be repeated. Vendors will need to be paid for their prototyping activity but it is a valuable investment as many companies have discovered at this stage that the software which was previously top of the selection list does not effectively meet their requirements or do not stand up to rigorous testing. This is also the time to view more in-depth demonstrations from a more limited number of vendors, inviting them on-site for as much as a day so that they properly go through all aspects of the system tailored to requirements. This also gives the business an opportunity to spend more time with the vendor and establish whether their company outlook and practices fits with the business. When implementing a new software system it is not simply a question of buying a new system but also establishing a partnership with the software vendor and a good working relationship is vital for success. As well as obtaining references it is important to visit at least one company currently using the systems being considered for selection, this provides visibility of system operation in a live environment. Talking with the finance systems team about their experiences with the vendor during implementation and post go-live and most importantly speaking to the users operating the system on a daily basis, many of whom will have gone through extensive training and had to adjust to new working practices. Although reference sites are likely to be the vendors most satisfied customers this should provide the opportunity to talk frankly about the software, its benefits and drawbacks.

9. Product selection

The choice of vendor should have become clear during the selection process as perhaps some vendors were simply unable to fulfill specific business needs or back-up their sales demonstrations with live sites and client references. If a single vendor at this stage has not become an obvious choice there are many factors to consider in the final decision, such as the vendors reputation and track record, functionality, customisation of the software to satisfy unique requirements, total cost of implementation and ownership, ease and timescales of implementation, ability to keep up with technology changes and support services available. The final decisions may in the end come down to the relationship built up with the vendor during the selection process, if other factors such as functionality and cost are roughly equivalent. Not every vendor is equally attentive during the sales process and long term it will not be the sales team which manages the account and provides support, however the way the vendor’s sales team behaves and their willingness and openness to provide client references and information is likely to be a good indication of their service levels moving forward. At this stage it is also important to consider all factors and remember not just to automatically go for the ‘safe’ option, the phrase “no-one has ever been fired for implementing SAP” is one often heard, despite the complexity of these projects meaning that they frequently over-run and go over budget. It may not be the best decision to choose the largest or most well known vendor over one that may provide a better business fit and service levels at a lower cost. It is important that the team contributes to the final selection to avoid bias from individuals who may have a preference towards a certain system due to company reputation, previous experience, or their own desire to work with a particular product. The final decision should involve all members of the team in particular those who will be implementing the system and using it post go-live. It is advisable to consider the organisations future plans for growth and development so that if the organisation has significant growth plans then these should be factored into the decision so that the chosen product is scalable, able to accommodate this growth and it won’t lead to any unplanned additional cost. If the organisation is acquisitive it needs to be determined how easily new companies can be assimilated using the new product. Flexibility of the solution is also important so that if the organisation changes then the new system should be able to adapt or there may be a need to change the system once more to accommodate new working practices.

10. Evaluation, end user feedback and possible modifications

When the new system has been selected and fully implemented it is advisable to review the selection and implementation process as there will always be room for improvement and it is important to learn from past mistakes. Rarely will everything operate completely as planned following a software implementation and teething problems are to be expected. It is important to obtain feedback from users regarding system performance and it is likely that some changes will be needed. If the most appropriate product and software vendor has been selected then the organisation should receive effective support to resolve any initial teething problems and the expected business benefits should soon become apparent.