Continuity in BI Solutions – the User Perspective Revisited

Ever so often in BI development one must go a fair distance from A to B and has to draw up a roadmap for doing so. That plan should be agreed upon between Business and IT – between users and developers. And there are several pitfalls in the process.
Here I will discuss the case of continuity as experienced from a user perspective. In some cases it is evident that continuity must be preserved when moving from the old BI solution, A, to the new BI solution, B: continuity of the collected data, historical and new, - and continuity of presentation in that calculated KPI’s remain intact with effectively identical business definitions.
In other cases disenchantment with the existing, old solution may be such that it may be tempting to opt for a “revolutionary” new solution without regard for real cross-solution continuity. From an IT perspective this may seem the more attractive and easier way to go, and Business may be persuaded to go along. Or so it may seem. According to my experience, things are rarely as simple as that.
The problems are that initially Business may not fully comprehend and understand the scope of a new BI solution, and that the Business representatives at the defining stage may not really be representative of all Business users.
As an IT person one should ask the right questions and those questions are not always just the simple and direct questions. In this case it is important to know what triggered the need to go from A to B. Are we looking at a native and immediate desire for a new BI solution, or are we really handling a spinoff project from a change of ERP system, a merger or acquisition, or a high level policy change in the company? In any of the latter cases, even if Business superficially agrees to a whole new BI solution one should be quite wary of possible complications. After all, the existing solution has been and still is supporting business needs in the short term. Any excitement about a new solution may quickly disappear when faced with the challenges of implementing it. How deeply rooted is dissatisfaction with the current solution? It may actually prove quite shallow!The solution then, I propose to be, that IT should really probe the level of user dissatisfaction with the current solution before settling for taking off with both legs to leap into the future and construct an entirely new BI solution to replace the existing one. And unless completely satisfied that the old solution will be missed be no-one, the prudent thing to do is to dissect the old solution and to document any changes, especially where features may be discontinued. It may seem tedious at times, but it actually has a number of advantages for IT too. Any such documentation and understanding is useful as part of the specification of the new solution. It also helps to clearly define and emphasize what is actually new features in the solution to be. And eventually, any difference in data presentation between the old and the new solution is just a potential error as long as it remains unexplained, - once understood and explained it becomes an improvement and an extra feature! - Last, but not least, a thorough understanding of the old solution is an immense help when constructing and implementing the new. Contrary to the leap into the future described above, it is like a long walk where one foot always remain in contact with the ground. And after all, when literally going somewhere, I – as most people – do tend to arrive faster and in better shape after a steady walk than after a series of leaps and jumps. Agree? - Stay tuned here at morlin’s BI blog for more deliberations on both technical and organisational aspects of BI!