There's a school of thought which advocates that Business Intelligence
work should lag behind the other pieces of a larger project and that one should
never attempt to undertake business intelligence (BI) activities in parallel
with the other "core" activities of the project. The line goes
something like this: you can't undertake a major project, say the
implementation of a new ERP system, and design and implement BI over that
system at the same time; the BI components have to happen 6 months or so later,
they can't be designed and built as part of the main project because they are dependent
on the main project items being in place first. Those espousing this popular
line would have us believe that one can't build BI until the system is up and
running, there's a good volume of data available and the business users have
worked out what reports they really want and need. Anyway, there's no rush -
reports and other BI items are only an output after all!
I disagree. Business intelligence items are as much an input as an
output. Yes, they draw upon data in the system, but, compliance reports aside,
the information they present should be used as part of a decision making
process which then causes some course of action to be taken in a larger
process. If this isn't the case then I'd argue that the report in question adds
no value. It may just as well not be there!
Look at the idea of doing the BI components at a lag behind the main
project through another lens. What this is really saying is one of a few things:
- We don't need the information we'd get from the reports to base decisions upon;
- We’re happy coming up with and using a range of time consuming workarounds;
- We’ve got a good gut feel for the business. We can get by making guesses for a while; or
- We can get by not doing some of the things that we used to do before we put this new system in place. This could be anything from something as simple as not providing team managers with trend reports of absenteeism through to things with much more potential for a financial sting in the tail such as not re-forecasting project budgets after the initial baseline as been set.
Also take some
time to think about the resultant behaviors that may arise from not having
reporting and analytic capability available early in the life of your new system. People in your
business need to make choices and they need information to do so. If they can’t
get it from BI, from the right channels, then they’ll find and develop a myriad
of workarounds in attempts to continue to do their jobs. Wait too long to bring
BI to the party and chances are a good number of those workarounds will persist
in various pockets throughout your business.
So I’d suggest a
pause for reflection before rushing to adopt the common [BI] scheduling wisdom. Put
it in the above terms, mull over it, have the leaders in your business consider
it too and then see if there’s still the same appetite to defer that BI work
for six months. Yes, bringing the BI work in to the main project isn’t easy, challenges
abound, at times it feels like you’re building on shifting sands but the pain
of not doing it may be much worse.
Posts
