ERP: Force Jumping to Unification Stage 3

The deeper insights from our course continue to clarify how Enterprise Architecture is the embodiment of business strategy with a technology execution. Once defined, and portfolio of initiatives sorted, EA is supposed to execute on strategy through vehicles popularly known as projects. The following is based on a true story and is a retake from another case analysis I worked on recently, and now with an EA perspective. This blog is an attempt to see the EA principles at work in this company's transformation via an ERP implementation.

Hello Growth, My Name is Change.

In early 1993, ABC was a $500 million company. ($830 million in 2015 dollars). The business wanted to grow towards the $5 billion mark, and needed a better IT system to help them achieve the goal. Similar to how most of the ABC organization was managed, IT and its systems were centralized, and used a Unix-based solution to support its core processes to service Financials, Manufacturing, and Order Entry (Sales). At that point, the system had become too customized and was in "spaghetti" state, and ABC wanted a better system which has more redundancy (fault-tolerance), is more reliable, and is easier to maintain. ABC felt that they have outgrown the capacities of their then current vendor, and rather than get an upgrade, The CIO wanted a new solution and support from a larger vendor.

Moving Out of a Conflicted Operating Model.

The CIO's management preference was to let each functional area make its own decision regarding budget and expense schedules for their own applications, as long as these are within the IT framework of standards and common architecture that he has provided for the organization. If I read the ABC context correctly, I think the CIO wants to focus decisions on technology requirements for IT's policies, standards, and architectures, but would rather push budgetary decisions on IT expenditures to the respective functional areas. A model mixed between standardization and diversification - a limbo of sorts. However, this approach was not compatible with the nature of an ERP implementation. Such implementations demand an integrated, holistic approach which requires functional areas to coordinate tightly in order to arrive at a truly integrated solution. This would also mean that such coordination required that budget and implementation decisions need to be made collectively, from a systemic enterprise-wide perspective, rather than from disjointed autonomous functional areas.

This conflicted view of the landscape produced inertia at ABC. On one hand, The CIO had an initial inclination to avoid an ERP solution, which is understandable, because of valid concerns that such solutions can become runaways and turn into costly "mega-projects". On the other hand, The CIO's management approach of a distributed autonomy, to my mind, would also raise concerns within the organization because the functional areas can easily run towards going their own ways, and build disconnected systems which fail to integrate and fail to communicate with each other. Thus, these two conflicting sentiments can become circular dilemmas which could be enough to feed the organizational inertia towards an ERP solution.

The Engagement Model. Breaking Inertia with Governance-PM Alignment.

From a reactive disposition, there's no better way to really kick start an organization from inertia than having a real palpable threat of an imminent massive system failure -- partly this was so at ABC. But general wisdom tells us that proactive measures supersede those which are reactive. To set things in motion, and achieve the required organizational velocity, ABC did  two things proactively: 1.) They assessed their Enterprise Architecture, IT Governance, and Project Management processes to develop and apply best practices in order to increase the chances for success of a true ERP implementation. 2.) They combined the best practice methods for cost and value management; with best practice methods for risk management i.e. risk identification, assessment, and response formulation. All together, building these first-order capabilities enabled the ABC organization to identify and plan for viable options. More important, these capabilities enabled the organization to make well-informed decisions for choosing and implementing the best-fitting approach, and the most effective solutions that will achieve their strategic objectives.

EA Initiatives - Preparing for Transformation. 

ABC understood from the get go, that this is not called "transformation" for nothing. This is a big deal, and they went through steps that could teach us well.

#1. ABC's decision to understand the ERP implementation's impact to overall business strategy and vision was critical in providing first-order capabilities and facilitated downstream enablers to make the organization overcome the challenges ahead. This allowed so-called "sense-making" to happen, particularly in the organization's leadership, and clarified the high priority that the implementation project deserves. It is the commitment from senior management which facilitates buy-in to happen across all levels of the organization. Thus, such depth of understanding helps the organization plan for, and manage the enterprise-wide changes that is about to unfold, and keeps all areas and levels of the organization steadfast when push comes shove, during the most trying and stressful phases of implementation. We catch an insight of this depth of understanding and strategic vision, when the CIO said "Cost avoidance [at this point] is not an appropriate way to look at the choice of a solution".

#2. ABC assembled a great implementation team for the project. For the internal project team itself, they hand-picked the best and brightest business analysts, even if this means that they will be taken away from the functional area. Clearly, ABC has achieved the project-oriented mindset. ABC chose the right vendors at the right time as part of the project team, with Oracle poised to bring its ERP solution commitment, and the expertise and advisory of KPMG for its end-to-end implementation. KPMG had the depth of understanding of ABC's needs, and were the architectural technologists who provided the integration guidance to make the solutions all work together. Moreover, ABC understood the demands of projects and installed effective IT governance mechanisms to provide oversight and control of the project. Their choice of leadership for the Executive Steering committee provided high level sponsorship, effective project visibility, and sustained motivations for the project organization. It is particularly noteworthy the way they deliberately made use of steering committee meetings mainly as an event for celebrations, rather than the typical checkpoint sessions. This again indicates the advanced mindset and level of maturity of ABC as an organization which sets them apart from others.

#3. ABC formulated an aggressive project strategy, and delivered with determined execution. The project contract strategy of "buying the capability" -- versus buying hardware and software from vendors, proved to be a lifesaver for the project when capacities where not performing to expectations prior to go-live. This was brilliant. Often, less astute organizations will contractually formulate acquisitions based on delivered software, hardware, and customizations without clearly defined and effective parameters for SLA's. Every organization should learn how to effectively embed guarantees in their contractual agreements. Moreover, there's the implicit wisdom of buying critical ERP components from one vendor - in this case Oracle. Many times project management is caught in the middle of the cross-fire between the software vendor and the database vendor pointing fingers when it comes to system performance failure. Although not exactly applied in this case, the notion of prime contractors to handle such conflicts is an important strategy to consider.

Unchartered Waters - Risky business even for a smart company.

This was one of the earliest major ERP implementations in the U.S., and many things were done which most likely increased the risks for the project, and perhaps indicates that risk management could have been done better by the organization.  On hindsight, they did two major risky moves:

#1. Going with the Big-Bang approach. Although they had an idea of the extent of change impact on various areas of the organization, I think they still underestimated the effort, perhaps influenced by their desire to pursue aggressive schedules.  It was only later, through the due-diligence phase reviews, did they began to realize that their core systems need to be changed, and an overhaul was needed to get it right. Changes were done to the extent of renumbered customers and renumbered products, and thus imply fundamental changes to master data, a large effort for conversions, and overhaul of data structures. As Ross warns us - Don't skip stages -- it can be very risky.

#2. Trying to meet aggressive schedules at the risk of quality and completeness. Indications of risky short-circuiting of process by forcing people "to nod" and say yes, even if the functional areas are not completely convinced that they are ready to say so. There were partial system tests, and water-downed due diligence, all to keep up with target deadlines, while increasing the potential risks when systems go live. ABC took the odds, and decided to go live on both the ERP system and the "bolt-on" package -- on the same day. This again was aggressive, and could have been a very messy and costly affair.

I myself have worked in quite bold project environments, with very aggressive and ambitious project targets and deadlines. Often we see these as a result of the demands of business pressure and the extreme competitive nature of the client organization. It would not be an overstatement to say that ABC embodies such a competitive posture. This is not necessarily bad, but we do need to consider caveats.

Conclusion - Organizational maturity saves the day.

ABC eventually was a successful ERP implementation, four years from concept phase. They did a lot of smart things. And although the risky things were few, they were significant enough to potentially flip the implementation into a costly disaster for the company. Thus, ABC as an organization was, and is, incredibly smart; but at the same time, was incredibly lucky to have pulled off the ERP implementation of 1995. ABC was both smart and lucky i.e. if we subscribe to the notion that luck is not 100% random.

To explain, we go back to ABC's organizational maturity, and project-readiness.  I use the term "organizational maturity" not in a loose way, but different from the maturity of architectural stages that we are studying. I actually think that ABC was not completely Stage 2 mature before they jumped to Stage 3 with the ERP implementation, and perhaps accelerated pursuit of Stage 4. Organizational maturity and project-readiness simply speaks of certain capabilities that the organization has achieved that enables the organization to address the challenges of IT initiatives such as an ERP implementation - their cultural readiness for change. There are simply projects that are "age-appropriate" if you will allow the metaphor, and an ERP implementation requires "age-appropriate" handling. I'll write about the change management and culture in my future blogs.

The key illustration that smarts and luck were at play was in the partnership of ABC and Oracle in order to accomplish the feat that they did on this project. ABC was smart in their strategies, one among which was that of procurement which we refer to as "Buying Capability" only possible because they shrewdly understood Oracle's own motivations for wanting to be part of the high-profile project - Oracle was hungry for a win for their new ERP product.

In the final assessment, we applaud ABC for all the smart moves they made, as well as for the gutsy decisions they called, in order to reinforce their competitive position in the market. However, we do need to place the strong caveat, that some of the things they did are not for all other organizations to attempt. I believe the ABC organization was able to overcome the risks because they had the sufficient maturity of capabilities, and the readiness for the challenges of an ERP implementation project, as they did. After all, this is ABC - a legendary company known for its smarts and good fortune. It is not surprising that they now enjoy a market cap of almost $112 billion, and reporting $12.6 billion in revenues in 2015.

That's it for now. Next week I'll reflect on my own experience with a large global ERP implementation.

Cheers always. Keep it light.

/