Large Customers Need Chargeback Models

I’ve been lucky enough to be a part of projects with a significant number of customers that have really really large systems.  At the same time, I’ve been just as lucky to be a part of projects with small systems.  There is a consistent theme in either, though.  Someone has to cough up the cash to fund that system and generally speaking, one organization gets left holding the check because of a lack of ability to define a chargeback model for the use of SAP BusinessObjects in a shared services model.  In this installment, I’m hoping to draw you to some conclusions to demonstrate that with the help of Sherlock, we can not only define a chargeback model, but with it, we can systematically assign utilization and ownership percentages to individual applications consuming resources in an SAP BusinessObjects environment.

The first part, and actually the hardest part, is determining what attributes of your organization’s BI footprint can be attributed to measuring usage and thus, the chargeback model.  The easy part is really getting the data.  That’s Sherlock’s job. Get data, load data, and use SAP BusinessObjects itself to…well…analyze itself.  Let’s walk through some scenarios in which Sherlock can help you to define building blocks that attribute cost to an application.

Organization of Content
In any decentralized, or even non-decentralized deployment, organization of content most commonly happens at a root folder or a root group.  What do I mean?  Let’s take an example set of structures:

chargeback_beer_groups chargeback_beer_folders

This is the first attribute in a series of attributes that allow me at a very minimum to assign ownership of a report, a folder of reports, sub-folders of reports, and instances of those reports into buckets.  Enter the Group Root Node and Folder Root Node:



Well ok.  The Beer Distribution group is really quite busy.  There are a bunch of sub groups and for all I know layers upon layers of users and folders under there.  But, if they exist within my application as a silo that I can attribute cost to, the Sherlock Group Root Node and Folder Root Node are my keys to success.  I can roll up all of their report, storage, mass creation, etc. and pin it on them.

Let’s review how this works in a little more detail.


In this first sample, my brewery has a bunch of Web Intelligence reports carefully organized by subject area.  Nice.  But that makes it hard for me to chargeback with all of that nested stuff in the Beer Distribution folder.  Let’s see how Sherlock makes it easy to roll that up.


Look at that.  Using the Group Root Node object, I was able to collapse all of the reports in any nested folder under Beer Distribution for easier reporting.  Even further, with Sherlock Audit KPI, we can not only attribute utilization, but we can also assess the degree in which content by an application is consumed in terms of report refresh activity, views, how this content is being scheduled, and more.

Sherlock provides an intuitive way to easily organize and classify content to more accurately determine cost.

Leave a Reply