An overseas company around 2003, in search of business vertical integration and willing to enter the metal building industry in the USA, bought a very well known Kansas City MO, manufacturing business. Later on 2008, it also bought one of the main competitors in another state attempting to get a bigger market share.

The two American companies had very different cultures but somehow similar technologies; they both were supposed to keep their brands. The merging process started by attempting to put together the engineering and IT teams, unfortunately this process really became a tag of war, lasted more than six years and cost more millions than expected.

Common story? Merger and Acquisition (M&A) literature is vast and spans for more than half a century, but still many of these cases are excessively painful and costly.

Both manufacturers were well recognized in their markets, had good engineering teams; but they lacked good costs and processes control.

During 2003, the new owner; to achieve automation of their core business processes and to modernize the operations started implementing an ERP system. When the second acquisition came, it was already running, even though with too many customizations that later impede system upgrades and did not help the merging as envisaged.

Defining an Operating model as explained in (Ross, Weill, & Robertson, 2006) Chapter 2; could have been useful in this case?

Definitively, yes.

Defining an operating model may have provided the necessary levels of business process integration and standardization for product, services delivery and for the merging.

Looking at the four operating model examples (Ross, Weill, & Robertson, 2006):

• Coordination
• Diversification
• Replication
• Unification

Management, (knowingly or not) tried to apply a Unification model. This could have worked before the merging, but when bringing the new organization on board a little switch toward a Coordination model and a broader consideration of the human factor (Fusco, 2016) may have saved time and money.

Handling the intricacies of a merge and/or an EA implementation, may become overwhelming, as mentioned in (Wierda, 2015), considering these principles will provide the means to fight complexity:

• Scenario planning (forecasting and back-casting)
• Requirements over principles
• Collaboration over division of labor
• Design skills over design principles
• Structure documentation (models) at the core
• Risk based abstractions
• Check and balances at the governance architecture level.

References

Fusco, D. (2016, January 21). Launching EA Initiatives. Pennsylvania.

Ross, J. W., Weill, P., & Robertson, D. C. (2006). Enterprise Architecture as Strategy. Boston, Massachusetts: Harvard Business School Press.

Wierda, G. (2015). Chess and the art of Enterprise Architecture. The Netherlands: R&A.