In an informal survey with our customers we recently found that many business analysts are often working on requirements to enhance COTS applications. ERP and CRM processes have been commoditized for a number of years and have been implemented in many diverse organizations with interesting results. Examples of some well-known COTS packages are SAP, PeopleSoft, Seibel. Tibco, Onyx, Amdocs, Goldmine and SalesForce.com. There are many others.
Organizations often prefer COTS applications because of a belief that these applications can be implemented faster out of the box than homegrown systems with very little custom development or ongoing IT maintenance. One mistake companies make is choosing a vendor or package before thoroughly analyzing their business requirements. Just like any other project the business drivers, the core business processes, the data, business rules, the users and external interface requirements need to be defined and understood before a solution is selected. Once the requirements are defined, performing a gap analysis with each of the COTS applications under consideration is recommended.
Whatever selection process is used, it’s my experience and many of our customers’ that COTS applications still require costly ongoing customization. Having worked in many large organizations that implemented different COTS products, I have a negative bias as I can’t recall too many success stories with COTS implementations or cost effective maintenance. I remember one example of a huge company where I worked that implemented a variety of well-established COTS packages. Following a merger with several other companies (who had their own COTS applications) and an analysis of the COTS maintenance costs, a new strategic direction was formulated which eliminated almost all the COTS applications. Future development efforts would be handled in-house. The main drivers for the change were across the board cost savings, business process differentiation and timely change management. In the past vendor maintenance costs continued to escalate as more and more customizations or features were needed to keep up with changing business requirements. As new requirements surfaced it was difficult finding developers with the right expertise. Additionally the vendor consultants, who really knew the underpinnings of the COTS design, were very expensive, not always available and did not always understand our business requirements. With customizations implemented, future upgrades to the product became very complex and risky. Lastly, some requirements were flat out rejected because they were in conflict with the COTS design or base product. Luckily today’s COTS applications are designed to be much more modular and scalable then some of the products in the past.
Let’s start a discussion about your experience with COTS implementations and customizations. Please feel free to vent and share any challenges you have experienced with COTS implementations or maintenance. Please share your lessons learned and what steps you take to work best with COTS selections and enhancements.
- Being part of the solution - May 1, 2012
- What’s the difference between ordinary and extraordinary… - March 14, 2011
- Lots of resources to learn about agile - May 10, 2010
- Agile and the BA – Part 1 - March 23, 2010
- Is It Really Tyranny of Best Practices? - February 20, 2010
- BAs are Bridge-Builders Instead of Bridges - January 25, 2010
- James Bond and Business Analysis - January 18, 2010
- Should the BA scribe at a team meeting? - August 4, 2009
- Why do we need detailed business requirements? - July 28, 2009
- Updated CBAP® Handbook now available for download - July 14, 2009