strategy

The cost of capabilities…

Do you understand the true cost of your capabilities?

The topic of this post first appeared in the comments section of a post by Gene Hughson and Gene latched on to my thoughts and posted a great follow-up of his own here. As the topic reappeared in some discussions at work over the last few weeks, I figured now was the time to write it up as a separate post here also 🙂

Imagine you buy a car and each month you pay off the loan/lease and the cost of running the car in full. When after 10 years of running the car and paying off every penny of buying and keeping it, it finally dies, you would think that you would be in the clear, right? You could now make a decision on whether to buy a new car based on the current cost of buying and maintaining a new car just as you did the first time. Well, if you are like most people you will have built you life around having the car and so you don’t really have a choice but to replace the old car when it’s finally dead – that’s the hidden cost of capabilities.

That cost of sustaining your capabilities also very much applies to IT-systems (you couldn’t really live without that CRM-system now, could you? 😀 ) but it is something that most organisations seem to overlook – and don’t think about until it is too late. It goes both for the “core” enterprise systems (ERP, CRM, SCM, PLM etc.) where it is probably mostly the cost of upgrades and patching rather than the cost of replacements that aren’t properly factored in, but still.

Where I would imagine it applies even more is when you delve into the more fast-paced layer of customer/consumer-facing applications in mobile etc. If you want to offer your customers a mobile application you have to consider the cost of updating it as new OS’es and new hardware comes along. Eventually, some of your underlying platform technologies may also die, but you still want to have the mobile app and so the cost of porting/converting/rebuilding it on to another technology stack comes on top.

This (hopefully) isn’t exactly rocket surgery, but as mentioned it does seemed to be overlooked quite often and it is also hard to predict what the real future costs are.

So, what to do about it? Well, if you can’t predict it, you have to find ways to minimise the impact when it does hit and so your two best friends are now architecture and strategy. Architecture to ensure that what is built will continue to be fit-for-purpose for as long as possible, and strategy to ensure that the new capabilities you add will be capabilities you need, and not just capabilities you want.

This way, there should be strategic support for continuing to invest in these capabilities and there should equally be an understanding (for management) that increasing your capability footprint will inevitably lead to an increase in your baseline cost.

Advertisements

To centralise or not – that is the question…

(…with all due apologies to Shakespeare and Hamlet)

Have been involved in a few of these discussions lately and many people seem to present the opinion that centralisation is the best, if not only, way to achieve order, efficiency and effectiveness. Consequently, if you are against centralisation you must by definition (almost at least…) be an anarchist or even a saboteur – because who else would be against efficiency and effectiveness?

However, in my experience (and at least at the process level where I do most of my work) the truth isn’t quite so black and white. My theory is that there is a rough normal distribution of a company’s processes, where both tails should definitely be either central or decentral, but also the majority is somewhere in the middle. In this middle band, you can pursue both strategies with almost equal chance of success, as long as you actually follow through on the decision. By ‘follow through’ I mean that you deal with the inevitable downsides of your decision, meaning:

  • Want to do central data creation and maintenance with a CoE-type setup? Well, you get central knowledge and you get the opportunity to leverage scale and over time build a real center of excellence to improve your business,. However, do your current processes support getting information from the people ‘on the coal face’ to the central team that executes changes – and do people feel a sense of shared responsibility and urgency? If you haven’t specifically addressed this and taken steps to analyse, influence and monitor, then the answer is likely to be a no.
  • Want to do decentral invoice approval? Great, you get a chance to promote accountability in the organisation and a very good chance to influence unfortunate spending habits where it really makes a difference (with the individual and/or department) – but you need to deal with training, turnover, more training, continuous policy enforcement, even more training for new joiners and so on.

So, the discussion on centralisation is now a strategy vs. execution discussion, where it isn’t what you decide that wins, but instead what you actually act on afterwards that matters. And, as Peter Drucker observed; “Culture eats strategy for breakfast!”, meaning that to strategise is comparatively easy, whereas influencing habits is usually very hard.

So, the next time you are in a room with someone discussing the benefits of centralisation, start probing them on whether they are aware of the consequences of the decision and if they are ready to follow through when it matters…