When Change is Relished

There is a huge literature about change management, but the bulk of that is assuming that change is hard to accept and it is being opposed. When change is embraced with too much enthusiasm is a hardly covered issue, but it may cause some headaches as well. Let's try to partially fill the gap for BI.

Business is not always opposing change, sometimes it relishes it. When the business relish change too much, then this is an issue that must be addressed. Some would think that a business eager to embrace the changes brought along by a new BI system would be a favorable condition for a project but, indeed, this may create issues as nasty as those generated by an impenetrable audience.

These issues fall mainly under three possible categories.

Inflated or unrealistic expectations

If the business expects that the system will cover more areas than anticipated, or they expect that it will fix more issues than those it is designed to fix, even a perfectly working and well performing system won't match their expectations. This will start conversations on the effective ROI of the initiative and, potentially, it will lead to cuts or cancellations.

An example is a sales datamart that is expected to cover also marketing but it does not contain typical marketing information like customer segmentation or demographic data. In this case it was not made clear what was covered into the datamart and how/when the marketing issues are going to be covered.

To avoid this kind of issues, it is necessary to:

  • Clearly communicate the project planned progression, possibly with planned delivery dates. Make clear that the delivery date is not going to be a big-bang but just the start of a process that will take to the point when the old practices are no longer required.
  • Illustrate the reasons why some areas are covered before others. This decision is generally taken while setting up the project and must be well motivated and shared. There must be an owner for this decision, who can decide to vary this progression upon different business conditions as priorities shifts.
  • Give a real look and feel of how the system will look like when the new information will be made available. Continuing on the previous example, marketing will be shown where the new customer data will come up and how they are going to use them ("look, your customer segments will appear among these other attributes and you will be able to slice/dice/filter/group etc. like you do now with other attributes")

Improper system use

There are various possible improper use you can make of a BI system. Basically for every improper use you may try to list, enthusiast users are going to find a new one that was never thought of before! At the root, however, there is often a misunderstanding about the information being provided.


BI data may be used to validate transactional system data.
Example: finance is getting sales data from BI and from accounting systems. They find differences and they try to judge the accuracy of one of the two from the other. While a well designed system has known rules to identify the transformation required to move from one to another, these may not be well known to the users or they are too technical to be actually available in the front-end applications.


BI data used to feed transactional data.

While the data warehouse may be the place where some data exclusively live (example, market data acquired from a third party), in general it is not to be used to complement missing transactional data. Example: clients are up sold from a channel to another and different CRM system is used for this channel. Demographic customer data should be acquired again and eventually updated in the DW rather than being copied from the DW to fill a mandatory field into the CRM system. Do the other way around, and you end up with no clear authority among the systems.

Real Life. the author has been involved in setting up the budgeting/planning process in a large company in the food sector. One of the planned measures was the returns value. Unluckily, for a poorly coordinated IT decision, returns value, in a form suitable for planning, turned out to be unavailable in some source systems. The decision was to use the budget to fill the missing actual. After that, everybody was happy about having met the budget so precisely ...


BI system features misused or ignored.

When the advantages of the new system become evident, some users may set out themselves to replace advanced features not yet known or implemented.
Example: in an environment where Excel report files used to be e-mailed manually to recipients, the same thing is done by saving the new system reports in Excel instead of using a proper scheduling/broadcasting feature.


All these cases produce inefficiencies and potential errors. These may affect the trust in the new system, even though they are, ultimately, user mistakes. They are often difficult to track and fix because they are not surfaced by the users. Part of the activities required to assist the start-up must be aimed at verifying that there are no misunderstandings on how to use the systems and that the context in which the information provided is valid and well known. 

When one of these occurrences is spotted, unluckily there is no alternative to a painful direct correction of the issue.

Disconnected initiatives

On the wings of the enthusiasm for the new system, groups of users who have been kept at the side  of the process may spawn personal initiatives that may potentially jeopardize the long term progress of the larger BI initiative. If the entire information flow within the company has been designed upfront, and the design is appropriate, then excessive activism from the users may introduce some sub processes that are not going to be well integrated in the wider landscape.

The increasingly powerful BI clients put the users in the condition of "running ahead", anticipating future implementations. For example   it is tempting to cluster your customers on the client side, and make it the official clustering document, just to discover that clusters can't be turned to attributes available to others.
Another classic case is the warehouse who is given access to the tools just to discover that one nightly load is not adequate for them and they need real-time access to their stock.

Depending on the initiative being taken, a direct correction may be required. However some of these initiatives may be leveraged to anticipate some analysis and feedback. They are actually a good example of what the users want on the subject.

I briefly covered this subject, according to my experience. I am sure that there is a lot more to be said. Please let me know about your thoughts and your experience!

Have fun.