Separating Shared Service Center and IT Implementations

One noticeable impact from the current economic climate is the reluctance of business to commit funding to major improvement programmes. The desire to transform internal performance apparently remains, with a strong number of shared services programmes in their early stages of development, but very few are meeting the criteria to ensure immediate sign-off and the green light to proceed. In the short term, could this spell an end to substantial new combined ERP and shared services programmes that seek to transform whole global organisations in one fell swoop?

We all probably know of shared services and IT programmes that started with apparently realistic planned timescales but stretched to several times the expected length - or even rumble on to this day without a clear end in sight. How do we avoid this, get sign-off, deliver real benefits and retain the compelling case for shared services?

A vision of the perfect shared services would no doubt include end-to-end processes interlinked by seamless IT systems, interfaced to both internal and external clients, collecting data at source and returning documentation, financial reporting and critical business information to wherever they are needed. Sounds simple in this technology age. Why not go even further and imagine those end-to-end processes happening automatically without the need for human intervention at a shared service center or anywhere outside the client, the front office and the computer centre?

The technology exists but, in any existing environment, the key is to appreciate the upheaval necessary for even the smallest change and to focus on two things: the necessary, and the do-able. This isn’t to say we should lower our sights and accept the sub-standard, just that we should find a solution that produces a result (and delivers timely benefits) and demonstrates the value to support ongoing development and improvement programmes.

So, should major IT implementations and the development of shared services be joined together as one programme or run separately, either consecutively or concurrently?

Assuming a starting point of a distributed multi-site operation without entirely common end-to-end processes, the natural inclination seems to be to try to cure all ills in one go with a combined programme to implement a seamless ERP and build a shared service center. Both no doubt are equally necessary and worthy endeavours. There is an obvious level of impact within the same user community and it’s fairly straightforward to establish a case for interdependent benefits. At a decision-making level, nobody should have any difficulty understanding that design, testing and roll-out of a new IT system should be much simpler if dealing with just one main group of users (an SSC), that it should be much easier to service a multi-site operation from an SSC enabled by one single standard system linking the whole organisation with common processes, and that it should be much easier to deploy one programme/project team to achieve this. So, one programme it is then, case closed... or is it?

Separate programmes may be harder to visualise but, with cost constraints pushing against the strategic agenda there may be a case for establishing shared services with the absolute minimum IT enablement. 

Some fundamental differences between the creation of shared services and the design and build of IT systems may support the concept of separation anyway. Interlinking any two projects can only be successful if both can have timescales that work together and can be maintained (or moved) together. Are there more likely to be delays in one than the other? Are delays in one manageable in the other?

A shared service center project requires fairly considerable planning, stakeholder management and coordination. Once plans are in place, timescales become seriously linked to cost and risk as investment in premises and infrastructure move forward, and changing the whole shape of the organization (recruitment, terminations, retention) becomes an irrevocable (well, at least inflexible) commitment. The good news is that most of the detailed timetable can be fairly accurately established in advance and should not have to be delayed for its own sake (assuming some good-quality, comprehensive up-front planning).

Somewhat strangely, considering its technical nature, the IT plan is far more likely to have to rely initially on assumptions and estimates. In consequence, it is only as the work unfolds that the relative complexity or simplicity of each step may become clear. To be fair to the IT folk there is also a big reliance on the user community and business management as requirements, processes and specifications that have not been previously defined become critical to progress. In day-to-day activities, most organizations have few, if any, subject and process specialists who can visualize the best possible process steps first time and/or translate them into something the systems specialists can reasonably be expected to deliver.

Delays in definition of detailed requirements and multiple configuration attempts are common in such a programme and will either delay readiness for implementation or reduce deliverable scope, diluting the potential success. When the organization that would usually be expected to provide the process visualization is itself undergoing massive and turbulent change, the opportunity for error and/or delay increases. 

If SSC programmes and major IT implementations may not be the most compatible projects to couple together perhaps we should concentrate first on establishing the SSC. It is possible to avoid lengthy delays and spiralling costs by building a shared service center on time and in budget with bare minimum upfront IT spend. When followed by process refinement and visualization, subsequent ERP implementation can be targeted, controlled and delivered with precision planning, on time, in budget! The potential to deliver two programmes in minimum time and tightly held to budget starts to appeal.

Shared services needs IT, but how much IT? Clearly specified system adjustments and a simple workflow tool may be all that’s needed to start realising shared services benefits (rather than taking workflow out of scope it can be built very economically outside an ERP environment).

Does the existing organization have sufficiently similar and/or adaptable process and IT set up and is the infrastructure in place to adopt or modify to one common standard? Are the best of the existing processes and systems able to be replicated for all? The best of existing performance in a multi-site operation could be very attractive if achieved for all in an SSC. The concept of replicating the performance of the current best across the whole organization should be a reasonable sanity check for potential efficiency savings in any business case. Its value alone may support the SSC case.

Allowing for the minimum IT enhancements, is there a clear business case for the SSC alone? With very limited opportunity for delays, a relatively low investment and short payback period (from some labor cost arbitrage and efficiencies from consistently achieving internal best practices) could come desired improvements in quality, control, compliance, visibility and operational simplicity, even in the current economic climate. A reasonable, determinable cost twelve-month programme with tangible benefits and a relatively short-term return on investment may still be approvable. A substantial two-to-three year programme that could stretch to five with consequent cost and instability implications and five-year post-implementation payback period may not!

In a couple of years' time it will be interesting to compare results of programmes that start now with the intention of building an SSC to establish the first steps towards efficiency against those that are on the long haul towards only fully enabled perfection (and those that remain on the drawing board).

About the Author

Jim Whitworth cut his shared services teeth in the late '90s, building an EMEA SSC for one of the world’s largest software companies. He has subsequently developed shared service strategies worldwide and, working more recently as an independent consultant, has provided hands-on management support for shared services programmes in both the technology and manufacturing sectors. Jim has worked on programmes located in Western and Eastern Europe, separate from and inextricably linked to ERP implementation.  Email: jim@hwml.fsnet.co.uk.