An important element that was not present in BI Governance before was the Enterprise Architecture representative; it is the responsibility of the Enterprise Architect to define how the BI architecture will fit within the Enterprise. These decisions might materially impact the cost and performance of BI initiatives; furthermore if the Enterprise Architect is not aligned he/she can delay the implementation of a project to the point of affecting the business value of the project.
Training is another key role that traditionally has been bounced between IT and the Business, in the past nobody wanted to take ownership of training as it implied a significant invest in time to prepare the material and probably even more to teach it. As the organization evolves, developing the training material and training the trainer is starting to become IT’s responsibility, while the business areas provide end trainers who then train the end users.
IMPLEMENTING BI GOVERNANCE, WHAT ARE THE FIRST STEPS?
Implementing BI Governance can be related to writing an article, in both writing the first sentence or giving the first step is always the toughest one. The first step sets the direction of the whole program; it will tell the people in your organization how you are conceptualizing the whole process to work. It is this author’s recommendation that the first is to get executive sponsorship, preferably from straight from the CFO. The path to implementation for BI Governance will not be without challenges, just getting the people together will a daunting task by itself. It is extremely important to identify who the business stakeholders are in the organization, communicate them the benefits that BI governance can bring to their areas and discuss their specific BI pain areas / opportunities for improvement. Outlining how the BI Governance process can help them attenuate / solve their situations will give them a compelling reason to support the initiative. Next, the stakeholders in IT will have to be identified. Furthermore, the responsibilities among Data Modeling, Data Sourcing and BI Front-end will have to be clearly defined. Also, support will have to be rallied from the Architecture and Project Management Offices.
Once the stakeholders are identified and executive sponsorship is present it will be the time to bring the people together. A mission statement and specific strategies/goals will have to be crafted and approved during the first session. During this meeting sub-committees might be defined to discuss specific topics that do not require getting the whole group together. If possible, it is also suggested to schedule at least the next four meetings of the group so everyone knows the dates and commits to them.
REFERENCES
1. The Data Warehouse Lifecycle Toolkit: Expert Methods for Designing, Developing, and Deploying Data, Ralph Kimball, John Wiley & Sons, 1998.
2. Building the Data Warehouse, W. H. Inmon, John Wiley & Sons, 2002
About the Author
Noe A. Gutierrez is a veteran in the Business Intelligence industry. He joined Microstrategy in April 1998 as an international associate. He occupied different leadership positions within Tech Support, Technology and Consulting. He left Microstrategy to lead the development team of pricedrive.com. He was invited by Microstrategy to lead the office in Northern Mexico where he grew the region into a multimillion dollar operation. He returned to the US to lead the development of HEB’s next generation Data Warehouse. Most recently Noe joined Infosys, where he has helped other organizations to fulfill the potential of their Data Warehouse.
0 comments: