Alright, after determining the people needed to maintain performance analytics, we ended our last discussion referencing indicators, their sources, and figuring out how to we can have more a useful re-usable (read: fewer) number of them. We've talked about how the indicator itself and its structure solve this conundrum. Yet, sometimes it is unclear when we need another indicator and when we can just re-use what we have by enhancing it with a breakdown. So, for the uninitiated, what's a breakdown?
Remember in grade school when your teacher walked around the room giving everyone a number, say 1-4? Upon finishing, your teacher would say something like: "All the 1's in this corner, 2's work together by the fish tank, 3's near the window…". This is how breakdowns work. Your teacher had defined a set of potential values (a Breakdown Source) and then instructed her class to group together based on those values (the Breakdown itself).
Taking it back to the platform, in Performance Analytics we determine our values by writing a condition for a table — like the set of Active Assignment Groups. No partnering with the kid who was always picking his nose, just a filter. This is the Breakdown Source, which our data (say, Incidents) uses to determine what part of the classroom to stand in. Or, well, what "bucket" to belong to.
To get a little bit more technical with this, the breakdown source is the set of potential values for a field. For example, not ALL CIs are Business Services, so you wouldn't make your breakdown source for Business Service every CI type in your CMDB. If you're breaking down your requested item data by assignment group, you probably want to filter it by "Procurement" type groups, or "Fulfillment" groups. This concept is essentially the same as defining a reference qualifier for a field — even choice lists.
If that is still confusing, don't worry. There's a wizard to generate new breakdowns on your indicators — which takes care of most of the thinking at this phase. All you have to do is imagine "What separates my records from other records in the same table? Is this separation important to me?" If you answered yes to that second question, you probably should be off making a breakdown right now!
So we've spend some time on the Breakdown Source, so why do we have this extra Breakdown layer? Well, The Breakdown is how we can re-use our breakdown source for multiple different tables. Ever want to see all your Incidents, Problems, Changes, Requests, Projects, Financials, and Outages for the same service or assignment group all at once? That's made possible in the platform because of the Breakdown record. To make it happen, once you have your source, you just tell the breakdown where to get it's matching value from.
Right, so we understand breakdowns a bit better now. How can they reduce the number of indicators and indicator sources we need to manager? Well, if your idea for a new indicator ends up just specifying a value for a field, you're probably better off creating a breakdown instead. Number of new incidents coming from email? Breakdown on "Contact Type". Number of projects in my HR portfolio? Breakdown on "Portfolio". Number of outages for services in the marketing department? Breakdown on "Department".
Better examples of indicators change what the underlying data "means" or is used for. Number of changes closed past the planned end date? New indicator. Number of open problems not related to changes? New indicator. HR cases from executives? New indicator.
Remember, these implementation advice blogs aren't meant as the "one way to do everything". Its merely my thoughts from having to make these kinds of decisions very often when I create new configurations or review existing implementations. Please let me know if you've found them helpful — and feel free to suggest a topic.
Enjoy telling stories with your data!
1 Comment
