BeyeBLOGS | BeyeBLOGS Home | Get Your Own Blog

September 9, 2010

KPI Identification made Easy

If you are a member of the "Maintaining the Mystic of Business Intelligence for Money" ... this article is not for you....because I am here to demystify the magic behind KPIs (Key Performance Indexes).

1) Identify the top 5-8 processes necessary to run your your business.
Example: Develop a Product > Market the Product > Sell the Product > Manage Personnel to run the Business > Manage Assets to run the Business > Manage Funds for Profit

2) Prioritize each of the 5-8 processes in terms of how you perceive that managing their KPIs could improve your bottom line.

3) For each of the processes, determine which numbers (amounts, times, quantities, etc) would have to be reported at the corporate level today, that make you change the way you were doing business if those numbers were off from what is expected (each is a KPI...but do not publish the numbers if you are not expecting someone to change the way they are doing business). EXAMPLE: Yes you could publish # of products produced today...that it interesting, and may be cool reading...but it is not something you will take action on, UNLESS that number is below the number you expected. When that number is below your expectations...THAT is the number that is the KPI.

4) After determining your KPIs...The rest is just IT mechanics: Ensure data availability (I think you will be shocked to find out the basic data gaps you have to report what executives identify as KPIs), Ensure data quality, Ensure publication expectations (email? dashboard? Intranet Home Page?, Red Lettering or Blue?), Publish.

5) Rollout with Fanfare. If you want to really see change, ensure everyone is involved in making that happen.

and finally,...

6) Enjoy the benefits of your visionary ways

Posted by DataGoddess at 6:30 AM | Comments (0)

January 11, 2010

The Integrated Marriage: Modeling and Profiling

For the road weary integration warrior, the announcement of the union of data modeling and data profiling is no CNN late breaking news update.

Most integration projects understand the need to map all data sources to a data model which later (or concurrently) is mapped to the target data source.

Unfortunately, the data modelers (or ETL designers) are usually working without a net. They either interview system experts for the definitions of the source columns to get 'memory recollection of data content'..or they complete one off queries (read as: time consuming, inefficient task) to check the values of a data source.

Identify a scope of work on the project,
complete data VALUE profiling for all of the data source objects for that scope of work
sort the data sources at two levels:
= on whether the data source table/file is References Data, Transaction Data, or Summary data
= on the data values found during profiling
Most profiling tools can find Char(3) matches to Char(3) but they can NOT find Char(3) and Integer matches when the values of each are 1 - 999.
It is only at this point when you really understand what you have. NOW the data modeling / data mapping work should begin.

Throwing data modelers and data profilers at an integration project is not wedded bliss unless your data profiler courts the project appropriately and presents VALUES to the betrothed data model. But done right...your integration project can result into the long term relationship you always dreamed about!

Posted by DataGoddess at 6:15 AM | Comments (0)

March 2, 2006

Donít Shoot the Report Writer

It thought he had it!!!

Mike Garrett's March 2, 2006 publication of "Don't Shoot the Report Writer" grabbed my attention!

I was expecting him to finally publish the truth! That all the hoopla about BI tools only made it harder on the report developers! And I guess he inferred it....but let me append!

Mike is right. The devil is in the details and the top folks do want the detail. The gap in the story is the level of effort to get you there.

There is a disconnect of expectations. The BI tool sales folks tell upper management how quickly you can create cubes and reports. They don't tell upper management how long it is going to take to educate your information users in order to develop the kind of reports and cubes that will transform the way they do their business.

So...the report developers walk in...are told to transform all of the old reports into the new tool (by the end of the week)...The users are not wowed....and then they hate the tool.

Is there a way around this issue? Sure is.
You have to have a strong BI reporting Development management team that supports a solid development process.
You have to educate the business users into thinking a different way about seeing their business .
And you have to get them to help show you when aggregations are useful, and when they just clunk up the operations.

When the process is done is a beautiful experience. When it's not...they'll be shooting at your Report Writers!

Posted by DataGoddess at 9:45 AM | Comments (0) | TrackBack (0)