Now Agile BI is not strictly about reporting. It’s about other things. It’s about analyzing. I think that’s a key point because there are several things going on. I mean reporting in the middle is about statically presenting collected data. It’s critical. It’s essential, and it answers the ‘what happened’ question. It’s usually from a single system. It can be printed.
Its accuracy is aimed at senior management and generally at that level. There is also the need to actually get data out which is part of the Agile BI environment. At some point you actually need the list of the 30,000 people to do the mailing so that’s not a report that’s an export.
Or you’re setting up a meeting for some people if you are on the sale side in San Francisco. You want the highest rated prospects who have not been met in this certain period. That’s a list of 30 people. So there is a whole another part of BI that’s not reporting, it’s slicing and dicing and exploring data.
And then there’s analytics. Essentially the middle level staff is trying to interactively evaluate and explore data. They need to answer those questions why did something happen? They may need to blend data from multiple systems. You know having just the transaction data may not be enough, and you may need some profile data from the healthcare center.
They might not just need the clinical data. They might need some of the financial data and so forth. And this is about seeing the data and discovering the stories. The data has stories in it, and if this Agile BI movement can get to the point where the staff is making decisions. They can do easy analytics to see the stories in the data. They’re going to get better decisions.
The precision needed in this type of analysis is tolerable versus the reporting accuracies needed for accounting reports. The combination of data discovery and visualization enables a form of Agile BI. You can uncover hidden relationships you didn’t know existed. I’ll often hear ‘why didn’t we have this data before.’ In fact, they did. It was in a report they just didn’t see it, and they did have the discovery tools to get down in it to really take action on it.
I get this question a lot from people interested in setting up a successful BI strategy in an organization. What are the key success factors necessary for this?
View a 2-minute demonstration
of InetSoft's easy, agile, and robust BI software.
Now let’s talk about the end user side. From what we have read and seen and studied and heard from our clients is that understanding the problem being solved is really critical. BI can be distributed in an enterprise fashion, but it’s especially important as you get to the tactical staff who are doing the analytics in order to solve problems. You need to understand the problems that these types of users have. They have questions, and I think number one is, understanding what questions need to be answered?
What are the business people actually trying to do and how can data help them answer those questions? Then who needs to answer the questions? Some people need a richer set of information and can handle that. Others need something really simple, and so if you’re giving this BI tool to sales people, then it ought to be really simple.
If you’re giving it to a marketing analyst, it should be pretty rich. The same data is answering different questions depending on who it is. Their tools need to have a different look and feel to them. When and where are they going to this answer these questions?
This gets into the whole mobile BI story. If they’re walking around with a tablet PC, that dashboarding tool ought to work on tablet PCs. If they’re sitting in the office, then a client server arrangement works. So when and where they’re actually trying to answer these questions is important.