I agree that this is a reasonable approach, but I would step back and look at what the alternatives might be.
I am a proponent of properly defining one or more Service Catalogues to show what it is that your IT department is delivering. Some of the relevant definitions are included in the TBM Taxonomy, but it's most important for the TBMO that the consumers of each Service can see what it includes, excludes, and its cost or charge.
While you are allocating costs within your own organisation, the cost base and Service cost may change monthly. Ensuring 0% fallout may engender trust, but you can also achieve this by setting a price at the start of the year and then showing your improved efficiency with the a price reduction in the next period. When you start to charge other agencies you may need to move to a specified monthly charge and full SLO/SLA anyway, so this can also be useful.
My recommendation would be to draw a line between IT cost modelling (up to IT Infrastructure level), and charging (of IT Infrastructure to Business Services and customers). This can be done both internally and for external agency relationships, and is easier if it's done consistently rather than cost for internal use and charge for external.
I'll blow my own trumpet, this time, and say that you can read more about these thoughts in Practical Technology Business Management (paperback available on Amazon).
------------------------------
Jon Sober
TBM Consultant
Astute IT Limited - UK
London
+44 (0) 7711 148 621
------------------------------
Original Message:
Sent: 01-13-2021 04:34
From: Gunnar Durén
Subject: Would you recommend a Services within services TBM architecture?
Thanks @Bill Kasenchar and @Jon Sober for your insightful replies,
Up to now we have used CMDB information to allocate costs from the Server, Database and Middleware Sub Towers by application and thereby getting a relevant and transparent (Tower) view of the costs in these areas for each Application Service.
At the TBM Office we prefer having a 0 % fallout Services layer rather than repackaging these costs as Infrastructure or Platform Services and not being completely able to derive all costs (=explain over-allocation). We think that being able to account for all costs contributes a great deal to the trust and transparency of the TBM model in our organization.
Internally at Skatteverket (Swedish Tax Agency) all IT costs are attributed to the applications of our different business areas. However, in some cases IT may start providing services to other government agencies at the level of IaaS or PaaS. I guess in these cases we would be allocating costs to such services?
Delivery and Security & Compliance Tower costs are a different story. In general, they cannot be assigned to specific applications, so they are allocated proportionately to the application services on basis of the size of their general IT consumption.
Does this sound reasonable? Any objections to our assumptions above?
------------------------------
Gunnar Durén
TBMA
Skatteverket
46702026732
Original Message:
Sent: 01-12-2021 17:40
From: Jon Sober
Subject: Would you recommend a Services within services TBM architecture?
Hi @Gunnar Durén
Once you're reaching the level of putting cost to Business Services and on to their users, I think you either need to consolidate the Infrastructure Services cost into the Business Services, or charge them directly to the customers. I would definitely recommend the first of those, which is also more in line with the TBM Taxonomy.
It shouldn't be difficult to avoid over-allocation, once you have identified the inventory and drivers of Infrastructure Services cost to Business Services. It's best if you ensure that inventory or driver information exists, for how each Infrastructure Service will align its cost to the relevant Business Services. If not, you will need to choose or create some tactical equivalent, but that isn't always acceptable as people do not like a 'tax' for infrastructure that they don't use. (I realise I'm writing to someone in the Tax Agency :-) )
There is actually a more complex challenge where you need to enable Infrastructure Services to Infrastructure Services cost allocation, before allocating cost to Business Services, although that can be worked around too. Except where you're bringing in precalculated Infrastructure Services cost, like IaaS or PaaS from the Cloud, I've only seen that done on a custom basis, not as a generally available pattern.
------------------------------
Jon Sober
TBM Consultant
Astute IT Limited - UK
London
+44 (0) 7711 148 621
Original Message:
Sent: 01-11-2021 08:05
From: Gunnar Durén
Subject: Would you recommend a Services within services TBM architecture?
Dear fellow experts,
Would you recommend a services within services architecture? For example an Infrastructure Service as part of a Business service?
My understanding is that a drawback to services within services is that it leads to over-allocation within the Services layer. Do you agree? What is your opinion?
Our IT department tends to describe most of or all of their business in terms of services (Infrastructure, Platform, Delivery).
Best regards,
/Gunnar
Gunnar Durén
TBMA
Swedish Tax Agency
ESA, Enheten för finansiering och redovisning
Tel: +46 10 57 502 16
gunnar.duren@skatteverket.se
www.skatteverket.se