Discuss business intelligence, integration, compliance and a host of other SAP-related topics – implementation, best practices and resources to negotiate the world of SAP better!

« Positioning of SAP's EIM components gets clearer at SAPPHIRENOW Madrid 2012 | Main | Is RDS the answer for all SAP solution implementations? »

Integrating Shared Services

The perspective on shared services as a concept has really evolved in the last decade. Close to 80% of the Global 2000 companies have tried to bundle their back-office processes to be operated under a common umbrella of a Shared Service Organization (SSO). The targeted benefits have been immense in terms of cost savings and process harmonization. The organizational investments in processes become easier and focused as opposed to investments in disparate local departments and business units. There is a significant improvement in performance metrics and the organization works with defined SLAs and KPIs which increases transparency. A year on year productivity growth has also been one of the secular trends established by most SSOs


It is being increasingly seen that SSO's are moving up the value chain, from handling pure play accounting and HR processes to more support functions for Purchasing, sales and marketing. However, it can be argued that a majority of all shared service organizations have been established in the last 4 years and many of them support only single process areas like accounting. The way in which the evolution of an SSO takes place within an organization is very important.

Challenges on the way

    i.    The scale of operations: During the formative phase of a SSO, scale / volume of transactions is of utmost importance. The viability of the SSO rests on how rapidly the targeted number of transactions is brought within the fold. The catchment of business units and process areas which is defined in the overall strategic blueprint of the SSO has to be catered within a span of 12 to 18 months. 
    ii.    Lift and shift approach: In the pursuit of scale, a lot of localized processes from the various business units are added to the SSO without process alignments. In the medium term, operating similar processes in different ways for different entities results in inefficiencies and spiraling costs / activity. It is highly likely, that business entities who outsource some of their processes to the SSO experience discomfort and a sense of discomfort with the whole set-up. Typically, the business entity may experience a worsening of their critical metrics like time to pay invoices; interest accrued due to non-payment of invoices on time, slip in targeted SLA levels etc. The planned FTE rationalization or re-deployment within the business unit would also be impacted since the anticipated stability in operations has not been reached.
    iii.    Knowledge and people management: Due to the disparate nature of local processes, the SSOs have to invest in specific knowledge and teams to service these processes. Any transitions in the team are difficult to support. SSO's would also typically experience higher rates of attrition for the same skill-sets as in business units due to the inherent nature of the industry. In addition, attrition rates would be relatively high initially since people management practices are still in the process of getting refined. The effect of transitions and attritions further amplifies the inability of the SSO to meet its SLAs as committed to the business unit.
    iv.    Disruption in process chains: The process chain has to be re-built post transition to the SSO. The SSO typically takes over only a specific area of the entire process. E.g. in Procure to pay processes, only the accounts payables is shifted to the SSO. A completely new set of people will take over invoice processing and payment runs and due to a change in location; the accountants would be remotely connected with the buyers or the requistioners in other business units. This implies that the process maturity built up over many years in process chains before the transition to the SSO has to be built up from scratch. During the formative phase of the SSO, this would definitely impact performance.
     v.    Technology misalignments: Along with disparate processes, there is a high likelihood that disparate technological platforms are also inherited. E.g. if different optical archiving systems are used in different business units and there is an insufficient time for migration to a central optical archiving platform in the pursuit of scale, it can be seen that the SSO will be soon struggling with a multitude of archiving systems making an integration strategy even more cumbersome.
    vi.    Responsiveness to process changes: In a competitive environment, business processes provide a cutting edge in cost savings, customer acquisitions and customer retention. When process changes are triggered cutting across the organization with the requisite drive from the leadership, a high velocity of change is the first expectation. Unless the SSO operates with harmonized processes, it can prove to be a bottleneck and a risk to the whole change management initiative. The SSO will take ages to tweak all the localized processes which it has inherited in its pursuit of scale.

A Life-cycle approach to SSOs

The evolution of SSOs can be planned from a life-cycle point of view. The imperatives of scale should be as important as the attainment of SLAs, reduction in cost and process quality. These factors need to be considered in devising the growth stages for an SSO.
      i.    Formative phase: The pursuit of scale has for a viable business volume is important but has to be tempered with considerations of common technology platforms, process continuity and targeted SLAs.  A simple lift and shift approach has to be substituted with a carefully calibrated approach which includes:
a.    a move to a commonly defined technological platform e.g. SAP
b.    defined roles and responsibilities between the business unit and the SSO
c.    defined workflows between the different stakeholders throughout the entire process chain
d.    defined workarounds for exceptions in processes 
e.    communication framework to steer governance
The formative phase defines a major shift in terms of change management between the business unit and the SSO. Both the entities have to feel reassured about the model and should respect each other's roles and responsibilities. The future evolution of the SSO depends on the success of this phase. By the end of this phase, a significant percentage of the catchment business transactions would have shifted to the SSO.
    ii.    Harmonization phase: With scale attained in the formative phase, the SSO must ready itself for a scalable model which is based on a defined template of business processes which are acceptable to all business units involved. In case the SSO supports business units which run on a common IT template e.g. a SAP based financial template, the task becomes easier. Most of the business processes would already be harmonized but have to be re-aligned simultaneously with respect to the SSO. In general, this phase would involve:
a.    Learning from the experience of running multiple processes and defining common processes derived from best practices
b.    Putting in place a change management framework in order to transition to the To-Be processes
c.    Defining clear value and a sound business case to justify the movement to the new processes
d.    Deriving efficiencies, transactional cost reduction and process simplification as compared to As-Is scenario, thus also reducing knowledge management and people transition risks
The harmonization phase enables the organization to focus investments on entities like SSO and derive cascading benefits in multiple business units simultaneously in terms of responsiveness to change, compliance and costs.
    iii.    Expansion phase: With the required template of processes, the SSO is now also geared up to expand its foot-print to new business units and also to new process areas. By this time, the model and business case would already have been proven across the length and breadth of the organization. Business units (BU) would now carry mandates from the leadership to join or involve the SSO in some way or another. The expansion of the SSO would typically entail rollouts of the existing template processes and reducing as much as possible, the scope of localized processes, except for extraordinary reasons like legal or statutory reasons. 
    iv.    Continuous improvement phase: With new ways of doing business continuously emerging, the SSO will be challenged forever to adapt itself for new changes in business processes. There could be template changes, local changes and efficiency drives depending on business cycle. One such event could be outsourcing with the SSO. By now the SSO would have been able to calibrate its operations and activities in terms of complexity, costs and value. Process leaders within the SSO would focus on more on process design, monitoring and control and providing the crucial interface to the business units which are their internal customers. However, there would be a scope of many transactional activities which could be outsourced further to a third party provider. In case the third party provider is established in an offshore location then a new kind of integration framework will be needed which connects the business units, SSO and the third party provider.

IT needs for SSO integration

The key technological components needed for SSO integration are as follows:
      i.    Authorization framework: Defined roles and responsibilities are the bedrock of a successful BU-SSO relationship. Segregation of duties and four eye principles are the guiding consideration for creating authorization profiles which prevent any overlap of tasks between the BU and the SSO. When similar processes are being executed at the BU as well as the SSO, there is a high chance of incorrect transactions and duplication. Transactions which need approvals should not be allowed to be posted without requisite approvals. There is a distinct change in working model. When all processes were in the BU, some of the checks could be ensured offline. However, when processes also involve the SSO which has a separate location, such checks have to be mandatorily ensured in the system to be audit compliant. This topic is particularly important where payables are involved. When Third Parties are involved in SSO outsourcing, the authorization profiles becomes even more complex as external teams may be needed to have display or edit rights in the system.
    ii.    Workflows: The traditional role of workflows is limited to messaging, alerts and prompts. However, with SSO in picture, workflows can assume a whole new meaning. They can be leveraged to run the entire process blue-print involving activities which start in BU, travel through the SSO and land up with the business partners. Workflows are now instrumental in routing processes as per compliance standards and automating transactions to such an extent that manual intervention is requested only when an exception is identified. A successful workflow implementation ensures that an SSO is able to meet its SLAs and KPIs productively. The workflows enable rapid rollouts to new business units if existing processes are involved. When Third Party service providers get involved, then workflows will need to be enhanced for compliance and efficiency.
   iii.    Reporting: With a transfer of processes to SSO and then to Third Party service providers, effective reporting is necessary to track the transaction statuses. Since disparate parties are involved and connected by workflow, it is highly probable that the process will complete correctly without exceptions. However, workflows may be stuck while they are waiting for an event which is dependent on a user action and the process may be delayed. Reporting would be needed identify delays, bottlenecks, number of exceptions in the process and how the exceptions are being handled.
   iv.    Enhancements: Typically external documentation to business partners like purchase orders, dunning letters, remittance advises, invoice documents, proformas, terms and conditions etc would undergo basic changes. This is particularly relevant if the front desk and business partner communication is shifted to the SSO. Additionally, interfacing and enhancements may have to be changed to reflect new business rules, validations and increased automation.


Shared service organizations are becoming the backbone of transaction processing in large businesses. They are gaining critical mass, entering new processes and increasing their footprint across the length and breadth of the organization. An effective SSO allows the business unit to focus on their core activities, reduce process costs, increase process quality and service levels as well as bring agility for process changes. However, there are many crucial lessons learnt for the evolution of SSOs so far which can definitely enable new initiatives in this direction to fast track their return on investment and provide an all round satisfactory working model.

IT can play a crucial role in enabling the SSO initiative meet its targeted objectives and provide a launch pad for its rapid expansion within the organization. A well defined IT architecture goes hand in hand with the SSO life-cycle. IT enabled solutions can provide answers to problems arising out of process deadlocks, responsibility and role conflicts and above all achieve compliance without sacrificing on efficiency, achieving scale without foregoing process standardization.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter