It might be interesting to view Systems Integration work through the lens of organizational behavior. A typical vendor-client relationship between two firms is pretty unambiguous, easy to operationalize. A client organization engages a vendor for either upstream or downstream work; the vendor does it in its own setup and delivers to the client organization. The client organization evaluates the performance of the vendor, at times providing an incentive, and this easily fits into the overall supply chain with few adjustments on either side (vendor or client). Neither party is threatened in this setup.
A Systems Integrator’s (SI) entry fundamentally changes this equation because the SI delivers the service in the client ecosystem by being very much part of it. The SI’s work involves interacting intensively with multiple entities within the client organization. This brings up the internal dynamics and power play of the different sub-groups within the client organization. The SI itself becomes an important entity, which needs social and cultural integration as well – it can’t be clubbed under stakeholder management. If the SI work is large, it needs adjustment on the client side too by way of organizational adaptations.
A large client is never a homogenous group within. It consists of multiple sub-companies and entities divided by work, functions, geographies, offices etc. Though all these entities are aligned in the overall mission, sometimes they also compete with each other. A large SI’s entry into the client system changes the equilibrium as it shows up with substantial overlap. An SI’s mandated work can overlap with that of some entities within the client organization. It becomes a threat to some. This poses the first challenge in the SI’s integration with the client organization.
SIs are the specialists in execution; the ones with the industry standards and time tested processes and methodologies. The client organizations (large ones) also have their own processes, which have some maturity and have been proven in their context. This is the first conflict in defining and institutionalizing the processes. The SI, as a specialist organization, can do the work at lower cost and higher quality but needs to tweak it for the client’s acceptance.
For the program objectives to be met successfully, the SI needs to manage and assert itself within the client organization. The SI is responsible for managing and driving the client organization that in turn evaluates its performance and remunerates it. It is a cyclical process, which is inherently ridden with conflict. In a complex matrix setup it can take a lot of time to divide the right level of authority and responsibility between the SI and the client.
I think a large SI program should be looked at through the prism of M&A, cultural integration included. As in any M&A, the key success factor is to set up the right operating model with a clear definition (and more importantly acceptance) of the roles and responsibilities in the team. In large programs the team gets mixed up, at times part of the client team executes the program and sometimes parts of the program team perform the client functions. The model should clearly segregate the “delivery entities” and “client entities” when it comes to activities and deliverables. The primary function of the delivery entity is to create the output, which the client entity accepts and signs-off as in a traditional supplier-customer relationship. Program success depends on “one-team” effort, irrespective of organizational boundaries.
Sunil has over 15 years of experience in consulting, system integration and product development roles with Infosys, Accenture, McKinsey, Oracle and Tata Steel. He can be contacted at firstname.lastname@example.org