From time to time I review academic literature about the application of technology and offer my SAP experience based perspective. Recently I was reviewing one of these studies from a few years ago when the authors made a key clarification: they recognized two types of implementations which are problem-based (i.e. address your “pain points”) or innovation based.
Their suggestion was that some elements of both would be present on any large scale IT project, like an SAP implementation for example, but each type of application presented its own special set of challenges.
Throughout the study (linked to at the end) the authors managed to clarify key points so they are easy to understand. I have always considered the hallmark of genius the ability to take the complex and make it simple.
There are many situations where a strong business case has been made for an investment together with a well-considered ROI calculation, yet the business benefits sought never actually materialized, despite the fact that the project was delivered on time, within budget, and met the technical specification.
The benefits to an organization from IT-enabled change essentially emerge from three causes: either stopping doing activities, doing what [was] always being done but better (i.e., cheaper and/or faster), or doing completely new things. If organizations are to increase the likelihood of success from their IT investments, they must separate out the different sources of the benefits before developing an implementation plan. (Peppard and Ward, pg. 53).
They warn against one of the most common hidden pitfalls of Enterprise Software (ES) like SAP turning into a technology project rather than a change lever for advancing corporate strategy. It is sadly very common to lose sight of the purpose of the technology being applied. The study authors’ description provides great insight around enterprise applications. Read carefully how they describe CRM. Substitute your favorite SAP application, whether it is ERP (ECC), HCM, SRM, SCM, APO, BI/BW, or any other product for their description of CRM and the message is the same.
CRM is not a product that can be purchased; it is a discipline, a framework, [an] integrated approach to managing relationships with customers that requires continuous improvement. It is a strategy, not a tactic; and although supported by IT, it involves considerable organizational re-design, often changing the focus and culture of the organization. CRM implementation is not easy and the evidence suggests that many companies are struggling with their efforts. (Peppard and Ward, pg. 54).
One of the problems they noted with the case study they used was at a retail bank they wanted inconsistent goals for their CRM system. I run into these frequently and call them “mutually exclusive requirements.” Or, as some say, they “want their cake untouched and want to eat it too.”
The case study noted the company wanted to implement a CRM system for better customer management and servicing but at the same time wanted a quick payback. The whole idea of developing customer relationships–, through gaining intelligence, aggregating customer data, and analyzing customer interactions so you can manage and service customers better takes time. Not only that, one of the key goals of the initiative was to deepen customer relationships to reduce their servicing costs while selling them better products and services. If they had that level of awareness of their customers to do this within a short payback time period they wouldn’t have been looking at the CRM project. The company had set themselves up for failure by insisting that a business approach which naturally takes time should have an immediate payback.
Attempting to resolve the current and future business models often highlight a major disconnect between the strategic intent of implementing the system and the resulting actions that must be completed. One UK bank had difficulty in getting branch staff involved in defining requirements during their CRM project. Senior management’s vision of the project was built around customer retention and cross-selling. Branch staff, on the other hand, just wanted a system to process transactions speedily and to get the customer out of the branches as quickly as possible. Getting appropriate engagement and buy-in proved difficult and progress was laborious at times. Yet, after the system had been up and running for a year, staff began to see what was possible and became very active in making suggestions for further development. (Peppard and Ward, pg. 59).
This point where I will leave off this week is critical. Frequently companies purchasing enterprise software solutions like SAP are not aware of the capabilities or how to apply them. Only after some period of time, or a shakeout period, users begin to see and understand how the functionality and information can help achieve strategic business goals. That is generally when the second phase of implementation, or new functionality, or new enhancements, or even a reimplementation begin to gain consideration.
This study was really well written and easy to understand. The authors offered tremendous insights into the world of Enterprise business applications which are important for every business software customer and consultant. I’ve included a link below and it really is worth taking the time to read through.
Peppard, J. and Ward, J. “Unlocking Sustained Business Value from IT Investments,” California Management Review, vol. 48, 2005, pp. 52-70.