The Data quality reports provide a view of dropout for the current month over serval objects (possibly only standard ones?). While this is useful,  when I am working on a project I usually create a fallout report. This report is based upon two calculated metrics I create  that are:

Cost Fallout = Cost - .Assigned Cost

Cost Fallout FY = Annual(Cost Fallout)

Don't forget the "." before Assigned Cost. This Hidden metric is the secret sauce to the report.

This is what the whole report looks like. 

At the top of the report I put KPIs for the Cost FY at key areas of the model, one at Cost Source (what is going into the model), one at Business Units (what is making it out). The difference is what is lost in the model. If you are using the Sink design pattern then I will put this in too.  In this case we have two Sink categories, things that are ok to sink and things that need fixing. The difference between In and out is OUT = IN - (Sink + Fallout)

After that, I put a KPI and a table in for each model object. As there are many I will group them into tabs by model area. As this report will touch every object in the model it can be a slow report to load, but it is worth the wait. Each object looks like this:

You can create a KPI that shows the FY Fallout and the Cost FY for each object. This is the KPI configuration. You can copy and paste this for each object, just change the selected object in the KPI Configuation window, making it is a very quick report to build:

The important factor for looking at the fallout over the entire year helps alleviate the fact that TBM Studio is always zoomed in to the current month. Report KPIs that cover a 12 month period will help you to quickly find problems hiding in other months. Having the Cost FY helps me to understand the scale of the problem.  In the example, 1.6k on 30m is probably not going to significantly impact anything.  so maybe I will come back to this later.

Next to the KPIs, I  create a table that shows the cost vs fallout for each month over the entire year. Having that month by month view means that I can see systematic, cyclic and spot fallout in one place. Fixing systematic fallout will reduce other months without having to look at them so starting with the highest is likely to show you most of the cases. Once I get all of this down to 0 (or as good as), I know the model is good for that object over the entire year. Then I move onto the next object.

This is the configuration of the table element, again you can Copy and Paste for each object.

This report is my go-to report for seeing the general model "heath". If I make a change, I will check this to see if I have broken something. When we load monthly data we check this to see if it is in line with previous months and look for problem spots.

When prioritizing addressing the fallout, which you can take in two different methods. You could start from the bottom of the model and work your way up, "ironing" out the problems. Fixing fallout in one object may cause fallout further up the model - maybe the case wasn't considered because it never got that far - the advantage of this approach is that each item you fix can only create issues above and not below. The disadvantage is that you do not necessarily address the biggest fallouts first. I use this approach when I am starting to fix an existing model and I want to fix it systematically. 

The second approach is that you look at the highest fallout in terms of value and address those first. Prioritizing the high value items means you get to your showback numbers (with a margin of error) as quickly as possible and can leave the small differences to later. Look for a high percentage too. An object might be managing a small amount of money, but if suddenly it is all falling out that usually means either bad data or something that has changed in the config.    I generally use this when the model is mostly ok and we are reviewing the impact of monthly uploads.

What fallout looks like.

In this example, we have 10M of fallout, mainly concentrated in the first 3 months in 3.3m of what looks like common fallout, then 2k of of common fallout.  After that nothing. If I just looked at any month after July I would say there is no fallout and loose 10M a year. So, now we have identified there is a problem, we need to choose which month to start with. Jan to Mar have very similar numbers so any of these but maybe the 2k in Apr-Jun is also present in Mar so I will concentrate my investigations there. Once I have fixed Mar, I will check this report again to see if that has fixed the other months going forward and backwards. I will also look at Business Units and other downstream objects to see if I have fixed the problem or just moved it on to the next object.

#DesignPattern