Kanban and visual management really helps make explicit the work that is goign on. Plus, shared services are only evil in agile and optimised worlds, where the fitness of a company is ingrained in a company's need to adapt and deliver at a fast pace. They form bottlenecks and hence constraints in traditional systems, even if they themselves deliver things quickly (i.e. they are suboptimal). The focus of the last blog was on these systemic issues, not on the individual services and I assumed that the shared services were in themselves optimised. Don't forget, constraints are a natural and expected concept in Systems Thinking and indeed, form a critical concept in the Theory of Constrains. When systemic problems they bring are solved, they are something I and anyone else working in business optimisation positions should be aware of and then look around to see where the constraint has moved to, because they will.
Revisiting Shared Services
Shared services are a stand alone service in a company. They may or may not have budgetary and reporting functions, may have all the elements to deliver a service end-to-end in their arena or perhaps most optimally, deliver business features to other services. They are often characterised as having one accounting cost centre, even if they cut across multiple skill-sets.For example, in one company, an IT shared service may not have budgetary and HR control consist of:
- Distinct Tech Support teams - With management
- Testing teams - With management
- Software Development teams - With management
- System Operations/Technical/Network services teams - With management
- Overall departmental/service management
In another company, their IT service may consist of:
- Distinct Tech Support teams - With management
- Software Development teams consisting of DevOps, BAs, QAs/testers - With team leads
- System Operations/Technical/Network services teams - With management
And management of each team has budgetary responsibility etc.
And indeed, it could be fairly mature and have teams that delivers end-to-end ad support the application.
Getting teams to be more effective inside the bounds of a shared service is a noble goal, but the problem is the constraint then shifts to being a systemic problem, which is what I illustrated last time.
Is Optimising Shared Services Useless?
Not really. If you are moving from a traditionally hierarchical organisation to a flatter, leaner more agile one, it can be a very useful first step and indeed, almost always is. Just getting everyone in the same team who is responsible for delivery in that shared service ad visualising the work they are each contended for is an incredibly useful way to see how they are being pulled from pillar to post.
However, further down the line, this ceases to yield any significant improvements in value delivery, simply because of the contention on the service as a whole.
If I had to provide my top-4 tips on how to transition from traditional shared services to lean, multifunctional teams, they would have to be:
1. Pick a Stakeholder's Departmental Concern
Start with the needs of a stakeholder and map the flow of their end-to-end tasks through the entire organisation, noting the departments and functions it touches.
This often manifests as perhaps a customer entity which starts as a form on a web page, then becomes a record in the DB, then becomes a task for an engineer to come out and do and a conversation that a customer has with a call centre representative when they register an account once the work is completed etc.
To illustrate this through a well known medium, in IT, this can often manifest as the ALM process, for example:
 |
| Mapping a sample software ALM to departmental functions |
Once you have that list of departments for each individual journey, get everyone in that journey into one team. That way they are all aligned to that one value chain. Note the responsibilit numbers above and the team members below:
 |
| Collating members of the value chain into one team |
2. Map & Optimise Implicit factors & Visualise EVERYTHING!
These are often 'invisible' supporting functions, such as internal technical support, network services, software licensing, recruitment of team members, capital expenditure for servers etc. These have an impact on the performance of the team, especially in delivery.
Perhaps the most famous of these is the move to DevOps from SysOps, especially when capital expenditure for servers has traditionally taken a long period of time. First the server is specified, then it is requested by tech services, finance have to approve it, tech services have to build it, SysOps have to provision it on the network, then the system is deployed on to it before going live. Each of those context switches (which is effectively what it is for the server being switched) takes a significant period of time.
Changing Capex to OpEx (e.g. by using PAYG Cloud Services) especially those coming in under delegated departmental financial authority (especially with the team accountant now being on board) then removes the need for the finance context switch and authorisation to occur, reducing the amount of items in the finance 'to do' list at the same time. This then means that SysOps/Tech services can provision services without the need to get finance authorisation, which is a significant enough saving, as it in turn reduces the lead time but also, if the SysOps staff members are then brought into the development team, this means the development team can then take the technical parts of some feature from inception to live without having to go outside the team, reducing the number of blockers they can't solve.
This can also be applied to HR, facilities, engineering etc. as long as the value chain make sense and the majority of their individual contribution is to this value chain and not some other.
3. The Value Chain is your alignment!
Overlay the journey in tip 1 onto your value chain. Make sure they match and identify and integrate where they don't. The actual journey is what you deliver, not the slide deck the value chain is present in, so that is your starting point and takes precedence. This gives you an aligned enterprise architecture baseline.
After that, look to transition to what your value chain 'vision' looks like on the slide deck, because I bet they don't match :) If you are lucky enough that they already do, or you've done the transition, make sure you're delivering the best value you can. That means revisiting the value metrics and seeing if there is a way to improve them. Chances are just aligning everyone will deliver improvements in itself, but there is always room for more :)
For example, delivering faster improves financial metrics such as ROR, IRR and NPV which also improves ROI indirectly. Delivering predictably, reliably and with high quality reduces the need for contingency and some BAU processes.
4. Munge Carefully, one change at a time!
When absorbing functions into teams, make the changes gradually. As usual, smaller changes are easier to integrate than larger ones ad this goes for people too. Smashing two tribes together only ever causes fights, so it is useful to be mindful of the psychology of folk. Indeed, in a lot of cases, most people take to the idea of being an team's authority really very well, even if they are reticent to leave the department they started in.
Conclusion
Creating Shared services which are fully self contained and are aligned to business value are the first step in what could be a long journey for some companies. It also has a very short shelf life, since they will get split and amalgamated into thinner verticals. As you can see fro the diagrammed example, we didn't map every single type of task each department had to do, just the ones that started a vertical and then overlaid the extraneous tasks over the top through implicit tasks which appeared as we looked at each journey.
There are many more tools and techniques which can be used to decipher the actual value chains, including some that can apply here. However, for brevity, hopefully this provides a reasonable start. Also, look into mapping the systemic flow of tasks, but do so for all tasks in the system. If you are looking for a reasonable primer on Systemic Flows, see Ian Carroll's blog for a really good start and primer in synergistic fluency.
