Sunday, March 8, 2009

Executive Information System (EIS)

(This article is one of a series published in Business Solutions magazine.)


What an EIS Lets You Do

Most managers have a concept of how their business works, they have a feel for what is important, and they know what to look at to see how well or how badly the business is going. An EIS is a computer-based working model used to express, to quantify and to analyse those business concepts.

The EIS acts as a 'dashboard' on the business, alerting managers when KPI's indicate that action needs to be taken (the 'Big Board' screen in Figure 1 is an example of this).

Specifically, an EIS is a mechanism for tracking key performance indicators ("KPI's"). For example, a business might need certain a sales volumes to be viable: the critical sales-oriented KPI's to watch might be numbers and average sizes of sales, by product line, by distribution channel, by region etc.

Additionally, EIS' usually empower online analysis of business perormance: the EIS holds and shows the critical data describing a business' performance, and it usually incorporates a range of tools for viewing and analysing that data.

The Structure of an EIS

An EIS can take many forms, but the conceptual shape illustrated in Figure 2 is reasonably representative.

Data Sources The raw data used in an EIS is usually sourced from the various, disparate operational systems that a business alreadys runs. Sometimes data is also sourced from outside the business (eg from an industry-wide database, from newspaper sources, from Internet sources etc). The only common factor is that the nature, format, environment and content of data sources varies widely and wildly from one business to another.

Front-End What the user sees has to mean something. The figures and graphics shown need to be able to be interpreted by the user in business terms (for example, the chart in Figure 3 effectively communicates the age, sex and income strata in an organisation's customer case). And because EIS users are not always strong computer users, the front-end also needs to be especially easy to navigate (big icons, buttons etc).

Information (or Data) Warehouse EIS data usually needs to be stored somewhere, in transit from the data sources to the front-end; and it frequently needs to be massaged into a more amenable structure or format, for the front-end to display. The information warehouse might be incorporated in an EIS tool which combines the warehouse and front-end capabilities; or the warehouse could a separate database of some sort. The critical requirement is accessibility: the fundamental purpose of the information warehouse is to make data easily and quickly available to the end-user.

Passing Data Around

Data can be passed between EIS components in all sorts of ways. It always depends on how the source data is already being managed, the sort of LAN infrstaructure in place, and (probably most importantly) what other data management infrastructure is already in place in the organisation (most importantly, any other relational database management system, RDBMS, that might already be used by the oraganisation).

The front-end will almost certainly end up being linked to a relational database, or to an EIS-specific multi-dimensional database, through SQL-oriented methods (ODBC drivers are a godsend here).

In the happy - but uncommon - event that the source data is already maintained in reasonably accessible database environments, then it is possible to cut out the data warehouse piece altogether: link the front-end screens directly to SQL-defined views on the data sources.

What EIS Tools Do

As we discussed last month, the EIS should be distinguished from the EIS Tool. The EIS itself is the whole system for presenting information used by managers to support the running of their businesses (and that can take a wide range of forms, from paper-based reporting systems; to spreadsheet statistical analyses; to sophisticated data selection, extraction and analysis systems, underpinned by one of the commercially-available EIS software packages).

A wide range of EIS Tools, small to big, usually PC-based, is available for building EIS' (see the box insert listing some of the EIS vendors active in Australia). The EIS packages typically count, summarise and categorise data, separately by a range of nominated measures and categories; then the packages typically provide a range of tools and mechanisms for presenting updatable views of that categorised data.

Multi-dimensional Databases Most of the EIS tools hold data in some sort of multi-dimensional database. This works like a giant multi-dimensional matrix, pre-populated with figures for all of the possible cross-tabulations, ready to be called up instantaneously if the user wants to see figures for any particular combination of categories. (We'll describe these data management structures in detail in a future issue.)

Data Mining Most of the EIS tools are pretty good at taking slabs of raw data, and digging out many of the possible relationships and measures that might be useful for the particular business enterprise being modelled. This function is often a good start on building the EIS, but invariably needs to be supplemented with genuine knowledge and understanding of the real nature of the enterprise.

Front-end Presentational Tools Most of the EIS packages contain powerful Windows- or GUI-based presentational facilities: graphs for showing trends and relationships, buttons and icons for easy navigation, slideshow and workbook forms for collating and presenting the 'story' that the figures are telling.

Analysis Capabilities The EIS tools all support online analysis of the data being presented. They are generally very good at letting user 'slice-and-dice': pick and choose particular data sets and subsets for the user to look at. Generally, once a set of data has been selected using the EIS package, it can be viewed in tabular, spreadsheet-like form; or in any type of graph the heart desires; or it can be passed to another software package. The powerful idea here, well-delivered by most of the EIS tools, is that the user sits and thinks and explores, analysing and examining the various factors impacting on the business enterprise, and hence gaining additional insights that will assist in managing the business.

But always keep in mind that the tool itself is not the EIS: the tool just helps you build (and maintain) the EIS.

EIS Package Costs

Package costs vary widely, from around $500 per copy for PC-based packages - right up to corporate licences around $150,000 plus for the more powerful mid-range and mainframe-based systems.

It's All About Data

An EIS is only as good as the data sources underpinning it. The EIS is not a mind-reader - the raw data has to actually exist somewhere, and the right raw data has to be used.

The data needs to be accurate. Incorrect data invalidates the views presented by the EIS. Ironically, an EIS project often uncovers data quality problems in data sources.

The data needs to be the right data. Someone needs to know that particular data sources exist; and someone needs to know just how data fields are actually being used. The big corporate systems used as data sources are likely to be well-understood and documented, but still some critical data may exist on individuals' personal PC files.

Timeliness of data is an issue, but in our view that issue can be overplayed. One extreme approach would be prevent users viewing any EIS screens containing (then) incomplete data sources. But our view is that, subject to data accuracy, and as long as the user understands the actual timeframes of the data being viewed, then any data is better than no data, even if the data used is a little out-of-date.

Data Refreshing

A critical burden of any EIS is the need for periodic refreshing of data extracted from the data sources.

This periodic updating activity should be incorporated as early as possible into the organisation's regular processing diaries.

This is important: an EIS is not a one-time build, rolled-out and left to run along under its own steam. Data passing needs to be managed as an ongoing process.

The EIS Project

In typical project to build and implement an EIS, these steps would probably appear in one form or another:

  • design and define the business model
  • design and prototype the front-end, representing and illustrating that business model
  • identify and catalogue data sources
  • plan data handling (how data is to be passed, from and to where)
  • develop the data serving strategy (will additional hardware be needed to hold the data warehouse?)
  • develop the data refreshing strategy (how will the periodic updating be handled, and by whom?)
  • build and implement the data handling routines
  • hook up the data to the front-end
  • document, test, train etc
  • roll it out to the users
  • plug into the Operations diary for data refreshes
  • plan the ongoing maintenance

Testing and Prototyping

More than almost any other type of system, an EIS is only a success if people use it, and use it often.

When building an EIS you must have a real, live user to work with (preferably several). Watch how they use the components as you build them. Push and pull the EIS until your users actually use it, and smile a lot. You are trying to build a system that forms part of every working day's routine. Your EIS needs to be as compelling to its users as Winston Churchill's map room was to him.

You should also review how the EIS is working, after a few months of live use. How do the users see it, and what do they actually do with it? How is it running, from a technical perspective (for example does the data handling need tuning)?

Typical EIS Project Costs

How long is your piece of string? It depends on the size and complexity of the enterprise being modelled, and on the technical approach being adopted, on the EIS tools to be used, and on the data server hardware that is to be acquired.

A Little EIS Say you ran a small consulting practice, and you planned an EIS that would track you new business proposals, and would monitor your earnings from time-and-cost work. You could do this on a spreadsheet, so the software package cost would trivial. The real investment is your own time: thinking time, pushing and pulling formats and outputs.

A Bigger EIS Say you wanted to build a logistics monitoring application for a medium-sized business: to monitor stock flows and inventory. You might build this using one of the PC-based EIS tools, so package costs and numbers of users directly affect your costs. You would use a lot of internal resource, particularly chase and retrieve data. You may also use external logistics or EIS specialist consultants, for their expert knowledge in these processes.

Depending on numbers of users (allow about $1,000 per user), your external costs could total anywhere from $20-100K for consulting, multi-user package costs, a data server (maybe), database drivers and so on. For example, a possible budget might be:

  • 20 users at $600 per EIS tool licence ($12,000), plus
  • a dedicated PC to be used as a data server, with a large fast hard disk, attached to the LAN, for holding the EIS data (maybe $10,000 say)
  • 15 days' consulting time at $1,500 per day, say ($18,000), plus
  • about one man-month of internal IS staff resource, plus
  • 5 days' specialist training for end-user trainers, also at $1,500 per day, say ($6,000).

A Much Bigger EIS Say you have a small to medium-sized life insurance company.

First up, you probably have some old, complex, not-so-good data structures, maybe COBOL VSAM-based; so you are thinking about establishing an information warehouse. And you may or may not have good data dictionary documentation. So plan on a serious infrastructural project here (probably several mon-months of internal IS resource, plus the licence costs of an RDBMS if you don't already have one).

Next the front end design will be an internal workshopping type of activity - mainly internally-resourced, but possibly assisted by EIS or business consultants.

Then you have an implementation job, to connect the information warehouse to the front-end (probably a few more man-months, by the time a prototype is and built and tested).

And lastly you have the training, roll-out and integration into the operational cycles (more man-months, and possibly some external costs).

Software licence costs depend on the tools and RDBMS that need to be acquired, and in large sites these could run up to several hundred thousand dollars.

The added-value benefits of an information warehouse, especially in the various reporting requirements of an organisation, should be part of the cost-justification exercise for such a project. Business Process Re-engineering initiatives may also be well-supported by better data handling infrastructure.

No comments: