As discussed in my previous entries, I have presented four key change characteristics that must be considered for a SAP program to be successful in a client company. Remember that this construct is an arbitrary one, designed to talk about the relationships between the quadrants and business performance. They are:
1) Business Process Design
2) Cultural Barriers and Enablers
3) Dynamics of IT Strategy
4) Workforce Education
IT Strategy - a story of failure
Today, I will talk about the role that IT Strategy Development plays in determining how effective continuous improvement programs can be in a business that uses ERP platforms, and particularly SAP. Like nearly all staff functions in a business, IT tends to be seen as a support function, with internally focused sets of goals and objectives, rather than a function that operates at the execution layer of all other functions. Typically, they are seen as an unfortunate cost to the organization who, when they do significant projects, cause a lot of pain and are something to be endured. I will recount an incident that happened to me some years ago that emphasizes this point.
I was asked, as a consulting executive, to visit with the CIO and two IT Directors of a major corporation, and I was asked to visit by myself to help them think through possibilities for their SAP systems. Upon arrival, I was ushered into an office where the three executives sat and it was obvious from the start that they were not happy and that my visit was not their idea. They started the conversation by stating for the record that their corporate revenue was $1.1B and that they had the lowest IT spend as an percent of revenue in their industry at 1.1% of revenue which would be approximately $12.1M. This seemed to be the criteria against which they were judged and compensated. My question was whether they thought that they should be proud or embarrassed by that number, which you can imagine was not well received. My point was (and is) that this IT department was custodian of one of the most expensive and powerful assets in the corporation, with great potential to be leveraged to produce improved business results. Obviously, in order to accomplish that, several things would have to happen (and to the best of my knowledge never did with that group). The ones I would like to discuss today are:
1) Stop viewing SAP as purely a cost center rather than an asset
2) Start viewing SAP as a tool that should produce continuous business benefits (ROI)
3) Eliminate the "Cool Tools" approaches to technology tools
Stop viewing SAP as purely a cost center rather than an asset
At times it seems that organizations can be so intent on reducing costs that they fail to view the IT applications as an opportunity to invest based on ROI expectations. There are any number of reasons for this, most notably the failure of earlier projects to achieve the predicted results. Often times this can be attributed to failure to properly establish the base case (how can you known how far you have come if you don't know where you started), failure to consider other programs that are established that may also have been based upon the same savings (you can't pick low-hanging-fruit if you have already eaten it), or have not established the measurement systems that can transcend time and provide an accurate accounting. I am sure that there are more, but these are typical ones.
Based upon that, organizations will fail to see the differences between IT Operations (where data centers may be able to operate more cost effectively) and IT Applications, where the applications define and support the business processes that determine business results. If an organization can view IT Applications as the underlying technology that enables and institutionalizes business processes, then a natural conclusion ought to be that the business and IT functions should operate on a strategic relationship where business opportunities are identified and IT solutions are developed, all measured by business contribution - to reduce cost of operations, to increase revenue or to improve corporate governance (cost avoidance). This requires that the IT community learns more about how their applications drive business results and it also requires that the business community understand their responsibility for the definition and execution of their business processes. IT may "own" the applications platform, but the business surely must own their business processes and the results.
All of this then should be managed on an ROI basis, which doesn't mean every dollar spent is recovered, but means that the expectation is that IT applications spend will be included in other improvement initiatives as a partner and the business held to the results.
Start viewing SAP as a tool that should produce continuous business benefits (ROI)
When viewed as an unfortunate cost to the organization, measures are created to avoid as much of this cost for as long as possible. Upgrades tend to be done on an infrequent basis, and then done as "get it in" types of projects that are rarely either based upon ROI or designed to use the new software versions productively. They tend to be to avoid increased maintenance costs as software versions become obsolete. Many times this is seen as necessity due to heavy modifications that have been done in earlier projects, which creates on-going costs until they are removed and replaced by other approaches (conversion to native SAP business processes, or SOA integration with proprietary software development).
I am proposing a whole different mindset that is more appropriate for the technology age we live in. Going back to Deming and even further, organizations have tried to identify areas where opportunities for improvement exist, which can be costs like inventory or purchase prices, or revenue like backorder reduction to improve market perception (and a myriad of others). Organizations who know what these are generally tend to be healthy organizations who understand that their ability to significantly change their business results must be accomplished by changing a business process. Since IT Applications define the business process at the transaction level as well as the cross-functional integration, the IT function should be part of all of these improvement programs. As projects are identified and defined, use of SAP to enable these improvements can be incorporated into business planning and all of the potential benefits can be used to drive the projects. The next step is to flatten the IT investment curve to make these continuing investments part of operating the business day to day, and avoiding the larger, periodic programs that inevitably become so complex that the return is lost in the rush to get it done.
Elininate the "Cool Tools" approaches to technology tools
The third area that I would like to cover is what I call a "Cool Tools" approach to the development of IT Applications. It is the life-mission of SAP to continue to support and develop their tools so that organizations can create more value from their investments. This does not mean, however, that client organizations should become enamored with all of these developments except for where they make sense and can provide tangible business benefits to the organization. A corrolary of this is that the business organization needs to define more discretely what their true needs are. This comes from understanding their current business process and results, understanding what new or different applications they can use to change the current state and finally be able to communicate these needs to the IT community who can design IT applications solutions to meet legitmate business needs. A good example of this is the whole area of reporting in SAP. Internal clients compain that reporting is poor and IT proposes to implement BW/BI/BOBJ or whatever, but they take the approach of implementing it and encouraging the user community to figure out how to use it. Why not figure out exactly what the reporting/analytical needs are at the business performance level (a business function, not IT) and with this functional specification allow the IT group to do what they do best - design a solution to meet a detailed need.
The Point
It is time to stop legitimizing the dichotomy between IT and Business and develop the partnerships that will allow for flatter investment curves with much more of the investment based upon detailed ROI, where current states, means of measurement and setting of expectations becomes the norm. Let's stop treating IT applications like some mysterious lifeform that has descended upon us and start to treat it like all of the other tools that we use to design and operate the enterprise. This is going to require not only a different mindset on the part of business executives, but also a different level of understanding among the mid-levels of management in client organizations. How a company addresses this need for more education across functions and how they create a continuous learning environment is not as important as it is that they address this issue. There are many tools in the educational environment to address these needs, from under and post graduate education, to seminars and TERP 10 certifications that all make sense for members of leadership teams. The world we live in and lead businesses in has changed beyond our imagination over the past 25 years and our ability to keep up has been challenged for sure. My first user experience on a desktop computer in a business was in 1984 and most business leaders grew up in my world without this technology. We didn't have televisions or microwaves when I was growing up either, but we learned how to use them. This is the same idea, just much more complex, but also much more powerful to drive business benefits.
