With the rapid increase in reporting requirements from the likes of CMS and state organizations, along with the increase in value-based contracts full of performance measures, making business intelligence (BI) solutions available to customers in a timely manner has never been more important. In this brief blog series, I’ll discuss why having BI development occur in the business (as opposed to in IT) is a better approach despite some common objections, and I’ll also give some tips for success in a “business” BI development shop.
BI Development done outside of IT?
Here are some common objections from IT folks when they hear this idea: “there are too many things that can go wrong”, “it isn’t considered production quality if it’s developed outside of IT”, or “they [the business] don’t know the data”. Generally, the thought is that if it didn’t go through the right processes followed by IT, then it isn’t considered “production quality” and there are too many risks of things breaking or inaccurate data. Some typical IT processes include: requirements gathering, design, technical and functional specification creation, development, unit testing, QA testing, system testing, integration testing, change control management, move to production forms, move to production approval and so on.
There are definitely good reasons IT follows strict processes and controls when it comes to mission-critical systems such as the electronic medical record (EMR) or other patient care systems since the risks associated with those systems are higher—the EMR contains critical patient information that care team members need readily available to care for patients. However the risk of harm being caused by problems with reports and dashboards is far less than for an EMR. Any changes to the EMR need to be implemented with a controlled process so as to not cause any disruptions in providing care to patients. If use of a dashboard or report, on the other hand, were to be impacted in such a way as to not be available to users for a few hours or even a few days, it might delay analysis and decisions and cause frustration, but it will not cause harm.
In order for a report or dashboard to be production quality, it doesn’t have to go through the traditional IT process. Don’t get me wrong, there still needs to be a standard process that is consistently followed to ensure quality and create trust from customers, but streamlining that process when it comes to lower-risk development results in greater speed and efficiency without compromising quality. For example, dashboards and reports don’t need to go through the four traditional testing phases (unit, QA, system, integration) to ensure accuracy. Going through unit testing by the developer and then QA testing conducted by a business user that knows the data, understands the workflow, and what the expected data should be can ensure that the data is accurate and will be used appropriately.
Another common objection to why development should reside in IT is that business users don’t know the data. However I have found the opposite to be true: the business users actually know the data better than IT developers because they work with the data subject matter every day, they understand the workflows for how the data is processed and used, they know the metric definitions, and they know how to reconcile the results to the source of the data. If business users are given good metadata tools for data definitions and what tables the data resides in, they can be extremely effective in figuring out where they need to pull the data from in order to build outcomes that will drive decision-making.
In the next blog I’ll continue discussing reasons why BI development works better in the business, along with some tips for success.
