One of the things I struggle with is change management for business intelligence. One of the toughest things to explain to non-BI people, whether they are in QA/QC or general IT areas is that BI is not a transactional system or IT application, so traditional change management process doesn’t really fit the mold.
One of the things I struggle with is change management for business intelligence. One of the toughest things to explain to non-BI people, whether they are in QA/QC or general IT areas is that BI is not a transactional system or IT application, so traditional change management process doesn’t really fit the mold. In some regards the pace of change in mature BI implementations can be a day or even a few hours for some aspects like reports or dashboards, were on the other hand your database schemas, aggregate tables and cubes change at a slower pace. The challenge comes from trying to fit one change management structure on to this processes that spin at different rates and responsive needs.
The first thing we should address is the name, because we are not managing change in a typical application development situation, we are managing extension or addition. Rarely do we “change” anything in a traditional sense. We are developing new ways of looking at the data and throwing out the outdated parts. We are creating new views of the data or incorporating additional data into our warehouses.
Secondly, I think it makes sense to break the deliverables from a BI project in to 6 pieces, because these pieces have different churn rates. From a high level those 6 pieces are Staging, Stars, Aggregates, Cubes, Semantic Layers and Reporting/Dashboards/Visualizations.
If you are familiar with the Gartner Pace Layer Applications Strategy, you will understand when I say that the Staging and Stars are “Systems of Record” and you wouldn’t want these things changing at a rapid pace because of the impacts that it could cause downstream. These systems should follow a rigid process for object promotion because of the potential implications. Your aggregates and cubes are more like a “System of Differentiation” where you will see more frequent changes than the staging and star schemas, so there needs to be more flexibility in how you manage object “promotion through your development, quality and production environments. Finally, the semantic layers and reports can be viewed as a “System of Innovation” where you are constantly experimenting with the data, developing new analytics and mining the data for new predictors and indicators for business performance. These items have the potential to change daily, and if you have followed a rigid process for the ”system of record” and painstakingly tested the code for validity and reliability then you should have the confidence that the reporting will be correct based on the requests and whims of the business users.
As an aside, you have to take your project management method into consideration. If you are working in an Agile fashion you obviously can’t work on a monthly promotion cycle because by the time your last minimal marketable feature moves in to production, you’ve completed the next sprint and you will always be playing catch up from a change management perspective. If you are still working in a “traditional waterfall” you have a bit more room to plan for those production moves.
Lastly, consider what the business truly needs and place your organization on the Business Intelligence Maturity Model before deciding what change management strategy is right. If you do not work for an analytic minded company, then your initial BI offerings aren’t going to be used as a system of innovation, you are going to be replacing reporting that exist from legacy systems and pushing towards the next level of maturity. As your BI program matures, you need to reassess you change management needs to fit the companies level of maturity and look at your business users current needs. These practices and procedures should be reassessed every 6 to 12 months depending on the speed of development within the BI program.
