Report Design Rules of thumb

Stating the purpose
What is the overall purpose of the report?
Who is going to read the report?

Determining the layout of the report
What is the report title going to be?
What identifying information is needed in the header and footer?

Finding the data
What data do you want to use in the report?
What specific data should appear in the body of the report?
Does the data exist or does it need to be calculated?
What types of fields contain data?

Manipulating the data
Do you want the data organized into groups?
Do you want the data sorted based on record or group values?
Do you want the report to contain only specific records or groups?
Do you want to summarize the data?
What information should be flagged on the report?
How do you want information flagged?

Determining printing area characteristics
In what order will the areas print on the report?
How often do report objects print?

Developing a prototype on paper

ITIL in BI

When I attended the ITIL Foundation V3, the first question I asked was how practical is ITIL in practise for Business Intelligence in a corporate organization.

In my opinion, in BI we can first zoom into these 3 areas - Change Management, Problem Management and Project Delivery. When we start to identify the essence of these areas, we are nominating ownership for each employee in the division. Without a sense of ownership, an organization may end up creating an unhealthy culture whether there will be one or two 'star employee' who holds all the important information without needing to share any of it to the peers or everyone is doing everything in a messy way based on adhoc instructions. 

What makes me want to look into these 3 areas are based on some idealogy as below. 

Change is the only thing that is constant. Hence change is our business as usual. BI change management has to take place in parallel with the business change. The execution of change management in BI is the result of impact asessment and this exercise take place at 2 main trigger points: 

1) when there is a new initiative. This can be:

- new products or service line

- groupwide consolidation

- new kpi or division

2) when there is a change in core functions. This can be:

- restructuring of organization

- change in service line and product offerings

- change in business operations

A good system and design has to take account into potential changes. Project Delivery should also take into the account of balancing the deliverables on time based on current requirements and scopes as well as to include the requirement and effort required to ensure system scalability in terms of business change. A smart angle to control the project from budget and business needs perspectives are to manage the later point through new phases or enhancement.

Problem is the only thing we see things we fail to see at the initial stage.In BI problem management or commonly known as Support, it is the execution of the result of root cause analysis.Root cause analysis reveals a lot about the reasons for data discrepencies or system flaws that goes all the way back to business requirements, data cleaniless, governance practices and best design practices.

Both of these fundamental ITIL procesess - Change Management and Problem Management tie back to the initial stage of the solution proposal stage in Project Delivery because from the root cause we can propose better solution based on lesson learnt and with impact asessment we see what need to take into account to avoid impacts on other areas such as data accuracy in reports or system downtime when there are new changes introduced. In a layman way of saying, Problem Management takes place after bad things had happened , Change Management takes place as a precaution measure before bad things happen.

Hence Project Delivery , Change Management and Problem Management are tightly coupled functions that need to co-exist and integrate well to ensure the success of any Analytical or BI operations in a large organization.

Tackling Master Data for New & Old Infoobjects

Master data in a global environment is controlled by one source to ensure the single version of truth. BI and ERP system has to share the same type of master data as it is only appropriate that the master data comes from the r/3 system and BI extract from there. In some cases where the master data is not in r/3 system, the BI extract it from the global master data database.

Scenario 1
In BI reporting, the version of master data reported depend on the period selection. If material group in year 2009 month 12 is reported as Semi Finish Good and in year 2010 month 1 is reported as Finish Good, how does BI actually cater for this scenario?

Scenario 2
If the material classification in R/3 takes from GS_XXX and now it's replaced by GS_YYY, how does BI changed according to the material attributes extraction?

In scenario across BI landscapes eg in different regions and one global BI instance in which all the regional master data flows up to global level, the master data has to be compounded with source system as the object might have the same name, eg. same material code may exist in two different regions, an error stack may have te same technical name in two or more BI instances.