Dearest TBM Community,

I'm wondering how you all are dealing with fallout at the IT Tower level. For example, you have a server. You know that in theory this server should support an application but you don't know what application. This is due to either poor data/no data. Obviously, this is something you want to bring to someone's attention. How do you do it? 

Specifically, I am interested in:

1. At which level in the model are you reporting this issue? Do you have reports at the IT Towers' level showing this issue. If so, how do you the highlight the potential impact this has further up the model? 

2. Or, are you packaging up all this 'unknown' cost and sending to, for example, applications because you know it goes there. Then how are you explaining the 'unknown' further up the model? And what are you doing with those costs? Spreading like a PB&J? 

Oh, and by the way, for the purposes of this example you have ~30,000 servers not only 1 (forgot to mention). Show me what you got. 

Thanks,

Devon

ps. You also already know about zombie server insights but you want more!  

Hi, @Devon Bilsing.  In my company's model, we have the cost in the compute IT resource towers being allocated across servers, which are then mapped to applications.  So for us, the fallout is not at IT resource towers.  Instead, the fallout occurs between servers and applications.  We could have chosen to spread the fallout across all applications like a PB&J, but we instead chose to let it fall out so that people can see the data gap.  I hope this helps.  Best wishes to you.

Angela

@Angela Chapman-Welch Thanks for the response. After you allow the fallout to happen, how do you show people that data gap? And how do you explain its impacting things further up? 

@Devon Bilsing, when we review Application Total Cost of Ownership with IT leadership and IT application owners, we make them aware of the percentage of servers that are not mapped to applications.  Fortunately, the percentage has been low (between 3% and 7%).  And when we review the TCO for each application with the IT app owners, we ask them if there are any applications hosted on-prem that are not showing a server count and server cost.  A couple of the owners who  pointed out such an issue were able to provide us with data to fill the gaps on their particular applications, thereby reducing the number of servers not mapped to applications.  

Hey, Devon!

This is an issue we struggled with a lot while building our models out, and it's something we still struggle with to a lesser extent. The best process we found has two steps...

1. We just let that cost fall out of the model. Whether it falls out at ITRT or Cost Source, or Servers, etc., we just let it fall out. The numbers on the reports farther up the model end up either incorrect, or some reports don't work at all. When one of the users sees this on a report, they contact us to say something's wrong. At this point, we tell them that the number is wrong (or a report isn't working) because we weren't provided with the data we asked for. Usually this is enough to prod the person into providing the data. We've found that about 50% of the time when someone says they "don't have" the data you asked for, they really do have it, but they just don't want to do a little extra work to get it.
2. We created a set of reports that alert us (the TBMAs) to cost that is falling out of the model. They also tell us either what's causing the fallout (missing/incorrect data) or where the fallout is occuring, so we can more easily track it down. If the fallout is caused by something other than incorrect/missing data, then we fix it, and promote the fix according to the update schedule. If the fallout is due to incorrect/missing data, we approach the responsible person to request/correct the data (again). This way, when someone says a report is showing incorrect numbers, we can say that we've requested and not received the necessary data multiple times.

I hope this helps! 

Thanks! This is helpful. I think this part is key: 

"If the fallout is due to incorrect/missing data, we approach the responsible person to request/correct the data (again). This way, when someone says a report is showing incorrect numbers, we can say that we've requested and not received the necessary data multiple times."

haha

We do the same thing.

My recommendation is to allocate it to an "Unknown" application record. Periodically review these records with your partners to make sure there is enough data fidelity to ensure it's properly allocated. Unknown applications can be allocated onto a "Unknown" service and either allocated to an "Unknown" Business unit or spread across all Business Units. These flags help to keep people accountable to make sure data is clean.

Thanks @Richard Coronado. When using this method in the model, do you do anything differently with reports that are customer facing? Do you mind if "Unknown" is showing in detail tables, bar charts, etc? 

@Devon Bilsing Yes, there is a huge benefit in calling it out because it helps to keep people accountable. BUT...make sure you have an action plan to correct them and how progress. Set expectations that as costs are identifies total costs will shift with accuracy. 

You can use a specific allocation line with "Remainder". 

We created an object called "Fallout Collector" that was supposed to get all the misconfigured stuff so that we can either address it to the relevant teams (e.g. CMDB or server owner) or handle it in Apptio.

BEWARE: sometimes it does not work properly and we eventually disabled this allocation line. We now manually check underallocations prior to closing the month.
 

For unknown/undetermined stuff we often use a special application (TECSUP - for Technical Support) that goes to a similarly named business service. Then we have the choice of keeping it in IT or forwarding it as an indirect cost to the business units.

We have to live with the quality of the data we feed into Apptio and we cannot afford to have any fallout prior to closing every month.

Thanks @Guillermo Cuadrado ! I had someone also send me this link which seems similar, but at the reporting level: Create a Model Fallout Report for Unallocated Cost in R12 ...do you have a customer facing report to share information from this object?

No, we don't expose this to our users. It's just for us TBMAs prior to closing the month.

We have created a number of "Orphaned" services that these costs are allocated to and then onward allocated to all our customers based on their consumed technology costs - these services are for managed test servers and infrastructure (storage & servers). Creating these services allowed us to be transparent and trigger a decommissioning project

Infrastructure is the only level we would tolerate fall out, the rest of the model is required to be 100% allocated. To do this we push the issues back to the data owners to ensure we have the correct information to ensure 100% allocation.

Thank @Julie Batty, do you mind saying more about this "then onward allocated to all our customers based on their consumed technology cost" -- based on percentages? Or what? 

Its a mix, we are given consumption data for managed test and the orphaned infrastructure is based on the costs already allocated to the business unit (the cost driver)

How I've previously handled this is to create a model object for "unknown servers" which receives all of the falling server cost and then allocate it all to Applications by weighting by the existing cost from the driver from servers to applications. Typically <10% of our servers were unmapped in our case.

We found this to be more agreeable for our stakeholders since it burdened the server-consuming apps by proportion rather than PB-spreading it. (We were still able to push for improved data though, which definitely helps most in the long run. )