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.
2 Comments
This post was apparently written from the perspective of a class of business analyst that I call “captive”, that is, whose job is to be the advocate for a single group of SMEs called “co-workers.” There is another class of business analysts, sometimes called “product managers”, which advocates for a much larger class of users, called “customers.”
Product managers are the people who work with their own designers and engineers to craft the COTS products. Having worked on that side of the COTS business, I can appreciate the frustration of trying to create a product that meets the needs of all the people in their customer base. Also having worked on that side for many years, I have witnessed a number of times that customers really didn’t understand what they wanted. Many times I watched people from the same company on the other side of the table from me argue amongst themselves which implementation of a particular feature was correct or right for their company.
So…how does this impact the COTS debate? My answer is this:
There is no substitute for good business analysis on both sides of the COTS negotiation table.
You are absolutely right, Angie.
My experience is that companies often jump on technologies or methodologies that sell the idea of faster development.
Years ago I was involved in a project where the customer chose the company I worked for to provide a solution but the customer’s IT Director had read that Object Orientation was the way to go and insisted that my company adopt the methodology. Unfortunately, my company had no experience of OO and much heartache was the result all round. I have witnessed similar problems with RUP and Agile.
Another problem is that sales reps for various technology companies get introduced to businesses through their networks and they extol the cost saving benefits of their particular product and the fact that it “can do anything you need it to do”. In other words, customers sometimes buy technologies, not based on the needs of the business, but based on who played golf with whom.
Yet another problem is that, in my experience, companies are not good at recognising the need for business analysis before defining the requirements or choosing the technology, with the result that it is not done, or it is not done well. In my experience, when they actually do business analysis, they get their own SMEs (untrained in the techniques of structured analysis) to do it or they hire a consultancy who use senior people to bid for the contract but then send graduate trainees in to do the work.
And yet another is people’s misconception of what a COTS product is. Customisable Off the Shelf should mean that you can install it “out of the box” and it will work straight away, although you can configure it to suits some of your specific needs. An example would be an internet security suite. Some so-called COTS products are no such thing – they are in fact development tools with customisable, re-usable components already built. But you cannot install them and have some end use immediately.
Regards,
Declan