A Quick Analysis of Business Intelligence Planning

August 17, 2009 Dan Burger

Dave Hatch is a vice president and group director of technology research at Aberdeen Group. His team of researchers create and publish reports on business intelligence, a technology that has grown to include many technologies, processes, and disciplines. The reports are not specific to the IBM AS/400 and its progeny, but much of the information pertains to any platform and encompasses most business plans. A strategy for BI on the AS/400 can start right here.

Business intelligence describes the capability to create reports from data captured in a computer system. At least that’s how it used to be. It was simply a process of getting value from information contained within any organization’s transactional systems. That description remains the core of BI, but it has expanded to include many levels of analysis. It begins with simple query and reporting, which is asking a question and getting an answer to make a business decision, but it goes to areas such as predictive analytics and running high volumes of data through complex models to help predict the future or provide better service to customers.

Adding to the complexity are many variations and alterations of the description I just provided. And there are many toolsets that can be considered. For most people, the first idea that pops into their minds is the everything-at-your-fingertips vision of executive dashboards. In more cases than not, this is an unattainable, dream-come-true, graphical display of key performance metrics for every aspect of a business all on one screen.

The reality is that the capabilities of most executive dashboards are far more limited than the visions dancing in the minds of most executives.

But don’t confuse the limitations of typical executive dashboards with the capabilities of business intelligence. BI most definitely is being used to predict future actions that can factor into planning and forecasting business strategy and provide visibility into such things as departmental budget planning.

The starting point for a well-designed business intelligence project is an understanding of what it takes to make BI accessible and useful throughout the organization and to manage the total cost of ownership of such a project.

“Organizational capabilities, process management capabilities, and the technology management and performance management capabilities need to be in place to meet overall strategies,” Hatch says.

Aberdeen’s research papers are built around what “best in class” organizations have accomplished and how that compares with the struggles of companies in the “laggard” category. The majority of surveyed organizations fall somewhere in the middle. Examples of what the studies reveal include items such as best in class organizations gaining greater benefits from BI implementations due to organizational approaches such as developing cross-functional teams of IT and line of business individuals that are involved in the selection and implementation of ERP and BI modules that sit on top of the ERP system. The organizational approaches become formalized and repeatable and they avoid treating BI as a tool selected by IT, implemented, and then informing users at the point where they are being trained in the new technology.

What are the actual capabilities needed to achieve the performance promised?

“It has less to do with the vendor and its product than with the organization and how it manages itself and prioritizes its actions,” Hatch says.

Since April, Hatch has published numerous business intelligence reports including Managing the Total Cost of Ownership of Business Intelligence, Pervasive Business Intelligence: Six Steps to Enterprise-Wide Business Intelligence, and The ERP/BI Connection.

Even though organizational management has a major impact on the success of BI implementations (and all software implementations for that matter), there are important technology issues that can’t be ignored.

For the AS/400 shop, running BI applications native on the AS/400 (iSeries, System i, or IBM i) or on another platform (Windows, Linux, or Unix) with integration to the DB2 database is a consideration that can go either way.

Running an application on the AS/400 means the data extraction from DB2 and the subsequent building of the BI data model uses the same processor, which can be good or bad, Hatch says.

“The positive approach to staying outside the system is that once you’ve done the data extract, the incremental extracts, from that point forward, aren’t going to tax the system. If the AS/400 is supporting a lot of users across a lot of applications, that is a pretty good approach,” he says. “Because BI can be a very processor-intensive activity, depending how complex the calculations are in the data models that are being built. If you run on the AS/400 system, that system does a good job of parsing processes across a multiprocessor environment. It also does a good job of spreading user workloads if there are a lot of users across the applications. That’s a reason companies that use the AS/400 fall in love with it and stick with it. It is a workhorse that can handle high volume transactions.”

“You can also produce updates to the data model much faster using the AS/400,” Hatch says. “An operational BI environment (that depends on information in the DB2 database) is much faster because of instant access on the system to refresh data models,” he says. “This doesn’t matter in some businesses where the rate of business doesn’t change that fast. But in the wholesale distribution environment, for instance, one of the big pressures is change orders. When you have a lot of products that are distributed to a lot of customers and customers are changing orders, that effects business. It effects how you load a truck and change a delivery in the middle of a route. Having the capability to do that is paramount in some businesses.”

“So whether your BI is on the AS/400 or another platform comes down to how are you driving your reports? It becomes a strategy decision. If you have core systems set up on the AS/400, it makes sense to add BI to that system. If you don’t have reports coming from the AS/400, it doesn’t matter what approach you take.”

Another technology-related topic that affects BI is the persistent problem of data integration. In almost every BI scenario there will be more than one data source type. Getting multiple data sources to “talk to” one another continues to plague business intelligence and IT in general. The real value of BI is the capability to bring in a second (or third or fourth) data source.

“A good BI will integrate sources,” Hatch says. “When you are building the multidimensional database outside the raw data source system, you are normalizing two disparate systems that provide a view of business that was not possible before. As more disparate sources are brought together, it becomes a multiplier on the value of the BI system.”

An example of how things can get tangled is Salesforce.com. A lot of companies have marketing and customer service tied to it and they benefit from a more well-rounded view of their customers. This solves a business need. You can easily find all kinds of BI tools that attach to Salesforce.com. There’s a thriving ecosystem. However, it’s also common, Hatch says, for important sales-related info to be kept in a different database. Sales quotas, for instance, are hidden away in another application. They often end up on a spreadsheet.

In almost every case, there is important data that relates to the Salesforce.com data being kept in general ledger and accounting systems. Along with spreadsheets, this results in multiple data sources, and management may want to have info from all three systems. If the BI is set up correctly and the databases are integrated, it is possible to get real business intelligence. In most cases, it won’t be integrated, however. This is a universal problem and not something unique to AS/400 shops.

With this example and many others a BI project plan needs to consider whether it is easier to integrate info from three disparate sources into a BI system or easier to integrate it all into DB2 and get the BI from one data source. There are arguments to be made on both sides.

As you make your BI plan, Hatch advises organizations to challenge the technology providers to prove they can do what they say. From his research he knows that best in class companies are much more likely to demand a proof of concept before purchase of a software solution.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search