Companies have employed many methods of selecting software packages, in particularly for IT systems, from the most rigorous at one extreme to selection at the other extreme based on prior experience of a key executive, with no discovery or extensive consideration of how a product satisfies real requirements.
Care should be taken by a company in such matters to apply appropriate rigor to the process, for the following reasons:
- Acquisition and implementation of packages, particularly complex suites of applications such as Network Monitoring, System Logging, ERPs, SCMs, and CRMs, constitute a costly initiative, often requiring an outlay of millions of dollars.
- It is a risky proposition. As much as 85% of such initiatives fail, when the definition of failure includes the inability to satisfy expectations -the project took too long, cost too much, did not deliver what was promised. And, in a significant number of instances, the pain becomes so high that the project is scrapped and the investment written off. Once in production, the failure can have disastrous consequences if the software fails to operate as intended, including dramatic involuntary reductions in shipments, inaccurate inventory accounting, pricing, and invoicing.
- It is a highly disruptive process, especially when implementing new IT systems (including Syslog & Patch Management). It requires active and dedicated participation by key personnel over extended periods of time, just the people who are most needed elsewhere.
- Due to the high cost of acquisition and implementation, most companies will need to live with and use the software for years before they can afford to replace it with something else.
For these reasons, selecting products is a process that should be done once and done right. However, the needs of companies in this regard differ. In determining real needs, a judgment balancing cost with risk needs to be developed.
Due to the high risk and substantial expense related to sophisticated package software selection, it is also in a company’s interest to prepare extensively and early for both selection and eventual implementation of the products. One of the most important ways of doing this is to consider Business Process Management (BPM, also known as Business Process Engineering Reengineering).
Business process analysis of some sort is inevitable in such implementations.
The flexibility of current product offerings provides the opportunity to optimize business processes across the enterprise. On the other hand, remaining constraints in software’s ability to support process variations can force companies to decide, even when they had not anticipated the need or desired it, to modify either a business process or the software itself.
Each option has significant costs, which need to be understood for actual costs to be fully understood. Accordingly, a company should prepare for a selection by identifying process areas where improvement is desired and quantifying the likely time and capital required to improve them. Such an exercise also paints a more realistic picture of the process requirements candidate products need to satisfy.
There are three major approaches to selecting package software, which are:
- The Classical Approach, which offers the most rigorous
- The Intermediate Approach, which offers less rigor but
also less cost, and
- The Proof of Concept Approach, increasingly popular,
which is likely to require the least cost but provide the greatest
The Classical Approach
This approach is called classical because it is the the approach used for many years, primarily by consultants, to apply a high degree of rigor to the selection process It consists of the following major activities:
- Initial, high-level analysis of the company’s supply chain and other business processes, transaction processing, and information requirements; determination of the company’s primary process and other objectives; identification of no more than seven, preferably no more than five candidate vendors who are most likely to satisfy needs
- A comprehensive definition of business process, transaction processing, and information requirements, as well as a technology infrastructure requirements, including facilities, equipment, and telecommunications needs.
- Development of vendor-related materials, including a Request For Proposal (RFP) document that formalizes business and other requirements The RFP is used by the identified vendors as a turnaround document to identify the degree to which their products satisfy requirements, more due diligence might follow to determine the degree to which vendors’ responses conform to reality.
Vendor-related materials also include transaction mapping and scripting of important end-to-end transaction streams, such as the order-to-cash cycle. Such scripts are used as the basis for a sen’ es of high-level and perhaps more detailed structured demonstrations of the candidate product sets by the vendors, attended and scored by internal company personnel.
- Based on the RFP responses and the scores obtained during the product demonstrations, the field then is narrowed to no more than three candidates, preferably two.
- During this time, preliminary negotiations with the vendor candidates take place over software license and annual maintenance fees, and over cost of services, such as training, and preliminary results are included in candidate scoring Integrator (a consulting firm which specializes in implementing specific software products into existing business environments) candidates also are identified at this time (or a vendor might strongly recommend one), and investigations of and preliminary negotiations with these candidates also take place.
- Based on the scoring, a final selection takes place; final negotiations with the selected vendor and integrator(s) then take place for license and maintenance fees and for the cost and availability of services In some cases such final negotiation takes place with more than one vendor, and more than one integrator, in order to provide a competitive atmosphere that the client company may exploit.
- The selected and acquired products are then implemented by prototyping them. During this process, internal company personnel, usually assisted by integrator consultants, model existing business processes, or create new policies, procedures, and measurement criteria for operations, for the software, and specify and implement transactional, reporting and query requirements.
Decisions also are made to modify current processes or to modify the software to accommodate existing processes. Changes are effected, training takes place, historical data is converted, and the final prototype is rolled out to the organization after thorough testing.
Some companies, usually very large ones desirous of minimizing the risk associated with selecting software, might defer a final decision pending concurrent detailed prototyping of multiple products, choosing the set that more quickly or otherwise better conforms to current business processes or anticipated future needs