Front-line operations costs are often an issue for IT organizations. In this chapter, Bill explores options with the Operations manager.

***

Larry Evans-the manager of front-line operations at Bill's organization-approached Bill, the TBM Guy. "Hey, Bill. I've got a question for you. What's happening with my front-line operations costs? As you know, we look after the most critical IT Service Management processes. These activities include handling of major incidents (SEV1/2 tickets with recorded service impact) and change management for major tickets. For really serious stuff we run the Incident Response Team (IRT), together with key support functions. Where are those costs ending up, please?"
 

"Sure, Larry. Right now, the IT organisation keeps all those costs, we are not allocating it to the business."

 
"But that's surely wrong, Bill: incident and change management are services that IT offers to the business, we don't do it for their own sake… How did the situation end up like that?"

 
"Well, with the last big reconfiguration of the financial sources there were some discussions as to whether we should handle those costs like other ITSM processes like Capacity or Configuration Management, that are clearly internal to IT."

"That may be so, but incidents affect the BU's customers and we take the heat for them. Also, R&D organizations drive many changes on behalf of the business too."

 
"I agree, Larry. We in the TBM Office have created a prototype that will improve the current situation. Let's start by looking at the cost drivers. We have identified the following Service Orders (SOs) in our time reporting system as related to Incident and Change Management." Bill showed Larry a table with the data related to front-line operations SOs:

Service Order Name	YTD
Incident Management - Run & Grow	$N1
Change Management - Run & Grow	$N2
Time reporting: major incidents	$N3
Stability IRT - Initiatives	$N4
Stability IRT - Incident Response	$N5
Change Management - Stability phase	$N6
Total:	$SUM

Table 1 - ITSM-related front-line operations YTD costs by Service Order

 
"Bill, you're saying these costs stay with IT. What's that proposal of yours?"

 
"We propose to link the Incident and Change management costs to the business services affected or related to them. This appears to us as most fair. It would work like this." Bill showed a small diagram:

Figure 2 - Allocation strategy for labor costs related to tickets

The labor costs related to the Service Orders we mentioned go to the "End User" IT Resource Tower. There are no other charges going to that ITRT, so we are safe. Then we ship those costs from Towers to the Tickets object. From there, they go to Business Services and they end with the BUs that own those."
 

"Sounds reasonable, Bill. And how are you doing that? Are you using every single ticket we handle?"

 
"There're thousands of tickets every day, Larry. We have no means of relating most of them to applications or business services. Also, you guys close many of them in large batches, so we couldn't go by duration. This would make sense to gauge the effort you spent on them."
 

"Yeah, I know what you mean. Automated tickets help, but yet again, there's nothing like a free lunch, is there? There's always a price to pay…"

 
"That's why we focus on major tickets, Larry. Your people and the support functions are very thorough with recording incident impact."

 
"You bet. Our backside is on the line if we don't record service disruptions accurately: when the impact started, how severe it was-outage or degradation-and what customers suffered from the incident or change."

 
"Well, we upload that data from the ticket system and there we find the list of customer services each action affected. We have designed an algorithm that considers the length (duration), the breadth (how many customer services) and the depth (outage or degradation). With those values, we calculate a weighting and allocate your costs accordingly."

 
"How often do you update the ticket data, Bill?"

 
"Once a month is enough, Larry. During the month-end-closing process, we load what Controlling calls the technical data. As part of that process, we upload the ticket information."

 
"Can I see the cumulative costs by business service, Bill?" 

 
Bill keyed some commands, and the system displayed the following table:

TOP 10 Business Services	YTD FLO Costs
Business Service 1	$N1'
Business Service 2	$N2'
Business Service 3	$N3'
Business Service 4	$N4'
Business Service 5	$N5'
Business Service 6	$N6'
Business Service 7	$N7'
Business Service 8	$N8'
Business Service 9	$N9'
Business Service 10	$N10'
Grand Total	$SUM'

Table 3 - Front-line costs by Business Service (TOP 10)

 
Bill said: "The table displays the top 10 business services in this FY, accounting for 94% of your total ITSM labor costs."

 
"When will this be available, Bill? It makes sense to me."

 
"Since this is just a proposal, we cannot move it to Production just like that. We'll share the model with the stakeholder community and see what the reaction is."

 
"One last question: what happens if there are no incidents or major changes, Bill?"

 
"Excellent question, Larry. First, we'd expect to see less time allocated to these activities."

 
"That stands to reason."

 
"To prevent fallout, we have added an artificial record linked to an IT-owned business service. Thus, if there are no other incidents, all your costs would stay with us."

 
"Anything else you'd like to add, Bill?"

 
"Related to the last point, we might want to consider something that we could call a unit-of-impact rate. This would make sure that we charge BUs the same amount, regardless of how many other impacts have happened. It's an option we might want to consider during implementation."

  #tickets

​​​​​

#ApptioforAll

This is perfect - exactly what we're working on with cleaning up services, helping service owners identify their services, etc.  We're also wanting a direct vs. indirect view.  Direct meaning the dollars came from that service owner's cost center and indirect meaning the shared expenses from other areas.  Thanks for another excellent read!  @Guillermo Cuadrado :-)
​

Thanks for the feedback, @Jenny Franklin. Always on the ball. Happy new 2021!
P.S. I added a missing picture, somehow lost in the copy & paste action. Worked with the spacing to make it more readable too.​

Looks great!  Happy New Year!  :-)


Original Message:
Sent: 01-03-2021 02:04
From: Guillermo Cuadrado
Subject: Bill and Front-Line Operations

Thanks for the feedback, @Jenny Franklin. Always on the ball. Happy new 2021!
P.S. I added a missing picture, somehow lost in the copy & paste action. Worked with the spacing to make it more readable too.​

#ApptioforAll

@Jenny Franklin I've seen a number of definitions of Direct and Indirect over the years, and I now try to avoid using either term because of the possibility of misunderstanding. You may want to look at the new definitions of them in v4.0 of the TBM Taxonomy, although I'm not sure that they will be useful to you as they will require you to change the way your organisation already understands and uses them. Interestingly, the definitions I've found online for Indirect in Activity Based Costing are closer to the new TBM Taxonomy definition, but that means the main purpose of a TBM Cost Model is to avoid Indirect (spread) costs.

The problem I have is that one person's "Direct" cost is someone else's "Indirect" cost (using your descriptions). You can't easily identify in a system whether a cost is Direct or Indirect as it will change according to who is looking and where it is in the model.

My preferred approach is to use alternative names such as Owned/Received, Primary/Secondary, or Managed/Provided. There's more aboutavoiding re-use of common terms in the chapter called "Don't do it" in Practical Technology Business Management.
Original Message:
Sent: 01-02-2021 17:34
From: Jenny Franklin
Subject: Bill and Front-Line Operations

This is perfect - exactly what we're working on with cleaning up services, helping service owners identify their services, etc.  We're also wanting a direct vs. indirect view.  Direct meaning the dollars came from that service owner's cost center and indirect meaning the shared expenses from other areas.  Thanks for another excellent read!  @Guillermo Cuadrado :-)
​

Another high voltage topic: direct & indirect, might probably warrant a new story ;-)
 
I used to like the R11 concept: with direct and indirect allocations to Business Units. True, that was v1 probably, but it was easy to explain, and nobody ever challenged that. Under indirect we had things that were either purely IT (admin. overhead, technical support = technology trials, etc.), or difficult to allocate in a fair manner (most ITSM-process-related costs, including security management and monitoring and automation). We used to allocate these proportionally to the respective BU bottom lines.
 
We associated Direct costs to business services owned by the business, with some additions, e.g. for WAN costs, etc.
 
We are now in what we have called Direct and Shared, probably because of semantic discussions, and different interpretations with Finance.
They now have a budget connotation, i.e. BUs fund and budget Direct costs, and we allocate the rest via the regular ATUM model. I still have my reservations about this approach.
 
Cost Centers (and Accounts) don't play a big role with us, mostly, and only Finance look at them.

Great piece @Guillermo Cuadrado

I'm interested in the the last section, where Larry's asking what you do with his costs if there are no incidents or major changes. His costs don't actually reduce, so you've added them in to an IT-owned business service.

There are a couple of extra questions I'd ask here; What happens if there's just one ticket in a month, and what is Larry's focus on cost?

For the first one, the same issue applies whenever volumes drop and you're using any sort of averaging to spread the cost. Simple modelling doesn't really account for low numbers like this, so you need to be very careful if it can happen. I'm not suggesting that there's a price per ticket, or an internal charging mechanism like that, but if the numbers are low enough that this is a relevant question you may be better moving all of those costs to the IT-owned business service on a regular basis.

My thought on the second question is that Larry's activity and behaviour is not driven by cost, and nor is his customers. If there is a major incident, the customer will not be asking how much Larry charged, but whether his response was adequate. Similarly for a major change, the question is more about whether it was successful or not. The question from Larry at the beginning, "Where are [my] costs ending up?" is not necessarily about accuracy but more about fairness, and it may not even be his own question but one that his customers have asked him. His team are available for all major applications, whether they fail or not, so maybe that's an alternative way to model his costs.

Thank you, @Jon Sober.
You bring up a very important topic that I had only brushed upon when writing the story.
 
In designing the system I had wanted to prevent fallout, but there is more to it than that. What are the Front-Line people doing when they're not handling major incidents or changes?

Similarly (maybe), what are SWAT teams doing when they're not in action? Probably training, preparing equipment, etc. like we see in the various series about fire brigades, but it's essentially idle time.

As I hint at in the story, Front-line teams have to deal with a lot of what we might call "ITSM white noise", i.e. lots of tickets opened by some automation when it detects something not being right. Who's supposed to be accountable (=chargeable) for that?

That's what brought me to the concept of a rate, i.e. having a fixed amount per "impact unit". As I described, this is not necessarily unidirectional, e.g. impact length, but we could combine it with other factors, such as number of customers/markets affected, and severity.
 
With such a concept, we'd probably be more fair in the cost allocation.