enterprise software

From time to time, I review academic literature about the application of technology and offer my experience-based perspective. A while back, I was reviewing one of these studies, which was about . In this study, the authors made a key clarification. They recognized two types of implementations: problem based (i.e. address your “pain points”) or based.

Their suggestion was that some elements of both would be present on any large-scale IT project, but each type of application presented its own special set of challenges.

=================

Throughout the study (linked to at the end), the authors clarified key points to make them easier 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), such as turning into a technology project rather than a change lever for advancing corporate strategy. Losing sight of the purpose of the technology being applied is sadly common. The study authors' description provides great insight around enterprise applications. Read carefully how they describe . Substitute your favorite SAP application, whether it is ERP (ECC), HCM, SRM, SCM, APO, BI/BW, or any other product for their description of , 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. is not easy and the evidence suggests that many companies are struggling with their efforts (Peppard and Ward, pg. 54).

The case study noted one problem was that at a retail bank, they wanted inconsistent goals for their CRM system. I into these mutually exclusive requirements frequently.

The case study stated that 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 — 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 the 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 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 in this post is critical. Frequently, companies purchasing enterprise software solutions such as SAP are not aware of the capabilities or how to apply them. Only after some period of time, or a shakeout period, do 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.

The study I referenced is well written and easy to understand. The authors offer tremendous insights into the world of Enterprise business applications, which are important for every customer and consultant. I have included the link below and encourage you to read it.

==================

Peppard, J. and Ward, J. “Unlocking Sustained Business Value from IT Investments,” California Management Review, vol. 48, 2005, pp. 52-70.