Invisible Intelligence
One of the core gating factors in deploying a Business Intelligence application is its overall effect on production workflow for the company in question. Over the years I’ve worked with companies who went through a Six Sigma process; they were all big (Fortune 1000) companies, with lots of infrastructure and process methodologies already in place, as well as a surplus of people who seemed to have the bandwidth to take on an additional large, complex project. Even within the context of these types of companies, implementing a structured, rigorous process for quality improvement was disruptive (“gee Dan, I know you have a sales meeting in Europe next week, but we really need you here for the Six Sigma meeting”). It’s possible to get away with this sort of thing at a large company (primarily due to excess bandwidth), but it becomes a much greater challenge when you’re dealing with a small or medium sized business where every single person is critical to keeping the machine moving forward.
In order for BI to have the desired effect on the quality of an organization’s information process flow, the deployment of the application has to integrate into the existing workflow without being disruptive. I’m not suggesting that business intelligence should be applied to what is potentially a faulty process, what I’m saying it that these companies can’t be turned on a dime. An increase in focus on quality does not just affect internal processes, it also affects customers, channel partners, customer support, etc (implementing any type of change across a company always slows processes down before speeding them up, and customers may not understand and appreciate the slow down). In an ideal world, the application of BI to an aggregate process flow would be nearly invisible; most interactions within and between systems are transactional anyway, so an incremental transactional improvement would be less disruptive, and because the effect on the workflow (and those responsible) is incremental on a transactional level, it is less likely to be disruptive, and more likely to begin to effect the desired change. Which is to say, the development of process rigor should be an integral and evolutionary part of a BI introduction, rather than a precedent.