Two approaches to data import from the current operational system to the Key Indicators data warehouse were proposed:

Import of data into KI DW from the structure which corresponds to the internal structure of the warehouse’s facts

Import of data into KI DW from structures which are unique for different key indicators

In the first case, the algorithm of data import from the side of KI DW is universal and does not depend on the number of key indicators. However, it requires that the lower-level system has data export tools of the structure described below (see Integration specifications).

Structure of metadata

In the second case, the algorithm of data import from KI DW is not universal: integration modules should be developed for virtually every specific indicator. This approach will not require that lower-level system develop complicated tools for data import in metastructure. However, at the meta-level of KI DW one will have to introduce additional tables to synchronise the data from the two systems.

As the remedy for the situation in question, an expedient, combined solution can be proposed. Here, integration for the majority of key indicators will be done via the metastructure of KI DW and in exceptional cases – via an integration scheme which is unique for every specific indicator.

Using internal MS Access abilities to create links with tables from almost any DB, we established links with tables from the Key Indicators data warehouse and with tables designated for export of data on average price per product from the lower-level system. This approach allows using MS Access data base as a meta-level for integration of data on key indicators and developing applications which are practically independent of the physical level of data storage. The software «Key Indicators» was tested under SQL Server 7.0, Oracle 8i and in a single-user version (warehouse data kept in Access DB).

Microsoft Access 2000 is an ideal tool for developing simple applications to work with DBs. Using wizards and constructors for developing screen forms and queries and Microsoft Visual Basic for Application, TACIS IT experts developed 30 screen forms and more than 20 queries to enter and edit dimensions and their groups (key indicators, clients, regions, goods, subdivisions, currencies, units of measure), to enter and edit key indicators and limits for them and to import data on average price per product from the current operational system.

When developing screen forms of Key Indicators, experts used following the ActiveX components:

MSComctlLib.TreeCtrl.2 (to switch between tree-like and list presentation of Key Indicators)

MSFlexGridLib.MSFlexGrid.1 (to display key indicators within selected time interval; to “colour” values of a key indicator).

You can display Key Indicators in two ways:

As a tree (you will see a tree-like structure of key indicators and value of indicators which are located in the selected and “expanded” branch of the tree)

As a list (you will see the complete list of key indicators together with their values for the selected time interval)

When working on the Panel of Key Indicators ADO technology was also employed to handle queries to data warehouse.

The so-called ”Drill-in” procedure for a key indicator, which means disaggregating of this indicator into its organic dimensions, was developed with Microsoft OLAP Cube technology.

This procedure, initiated by a user, builds a local OLAP Cube using data of the Key Indicators data warehouse. Afterwards, it is transferred to Microsoft Excel 2000 via technology OLE, MS Excel 2000 macros and Microsoft Visual Basic for Application. In Microsoft Excel 2000, the OLAP Cube is presented via pivot tables.

The body of a query on building OLAP Cube is transferred to a separate MS Access table that enables altering of the level of drilling in key indicators regardless of application. So, to add or change the list of key indicators one should not break into the source code of an application, minimal modification of the query’s body will be enough.

Pivot tables in Microsoft Excel 2000 allow not only automatic summation of values in columns and lines and their groups but also to simultaneously change the graph which corresponds to the respective table. Easy and flexible work with tables will enable managers to regulate the level of data aggregation by year, quarter, day, tree of indicators, client, region, product and subdivision.

More information on the software «Key Indictors» can be found in KI _User manual and KI _Programmer manual.

CA-Clipper, CA-OpenIngres, DB2 for MVS and DB2 for OS/390, DB2/400, dBASE, FoxPro, HiRDB, Informix, InterBase, Microsoft Access, Microsoft SQL Server, Oracle, Paradox, Rdb, Red Brick Warehouse, SAS, SQL Anywhere, SQLBase, Sybase and Teradata.

Data storage topology “Snow Flake” was used during creation of the structure of the data warehouse for key indicators.

The data warehouse structure for Key Indicators was created and tested at two physical levels:

- Microsoft SQL Server;

- Oracle.

Two files are attached to this document. To open them you, will have to install PLATINUM ERwin 3.5.2):

These files contain comments on tables, fields and other remarks.

More information on the structure of the data warehouse for Key Indicators can be found in KI DB structure.

Graphs on the next pages explicitly illustrate the relational interdependence between tables of the data warehouse.

Main dimensions of the Key Indicators’ data warehouse

Accounting dimensions of the Key Indicators’ data warehouse

Dimensions “key indicators” of the Key Indicators’ data warehouse

Accounting postings

Meanings of indicators’ value

It is worth mentioning that the warehouse structure enables:

Change, addition, replacement and deletion of any key indicator and their groups (all tables D_xxxxx and D_xxxxx_Unions, S_Units) as frequently as required

Keeping or changing of the tree-like structure for all dimensions (up to the fifth sublevel in the “Snow Flake” topology and unlimited number of sublevels when using reference to parent via Parent_Id in every dimension table)

Setting of limits for key indicators for every specific date

Analysis of key indicators in terms of the following dimensions:

Time

Key indicator

Region

Client

Product

And with the following attributes:

Quantity

Amount

Value

Automatic provision of integrity of data in the Key Indicators data warehouse.

In the structure of the Key Indicators data warehouse, the following facilities are reserved:

Dimensions and groups in the accounting sphere:

Chart of Accounts

Subjects of analytical accounting.

Financial postings as a basis for calculating most non-production key indicators in terms of the following dimensions:

Time

Debtors

Five subjects for analysis on debit side

Creditors

Five subjects for analysis on credit side

Currency of transaction

And with the following attributes:

Amount

Quotation of a transaction currency.

TACIS IT experts installed Microsoft SQLServer 7.0 + ServicePack 3.0 and Personal Oracle 8i on a computer provided by the company. Using this SQL server, IT experts from TACIS created a Key Indicator data warehouse.

The list of key indicators is a hierarchy where information is aggregated from the lower level of detail into a limited number of general aggregated key indicators.

Hierarchy of key indicators

The example below shows the hierarchy of the key indicator «Marketing».

When defining a list of Key Indicators two conditions should be met:

the number of key indicators should be visually graspable. At the same time a user should have the opportunity to drill down into detail to see information which stands behind every indicator at a lower level.

Key indicators should be easy to calculate as frequently as required (for some indicators it is desirable to have a daily update) to provide managers with the opportunity for timely reaction to on-going events.

A general approach to definition of Key Indicators would typically include the following steps:

1. Select the most important global Key Indicators

2. Break them down by sub-indicators

3. Define the calculation rules

The table below shows a list of possible Key Indicators.

It is worth mentioning that the software tool ‘Key Indicators’ should allow change, addition and deletion of indicators. The list presented above can be changed according to the requirements of the company.

1.5 Limits for key indicators

To interpret correctly the meaning of an indicator, one should know whether the value of the indicator falls within set limits or whether it has positive or negative trends. For these purposes, three intervals for every indicator were defined:

Green interval («excellent»). If an indicator falls within this interval – it means that its actual value deviates positively.

Yellow interval («satisfactory»). If an indicator is within this interval – it means that its actual value is within the planned level.

Red interval («dangerous»). Should an indicator happen to be in this interval – it means a negative deviation of a parameter from its planned value.

Thus, an indicator is coloured with one of these colours (green, yellow or red) depending on the interval it falls in.

The system of limits defined in the software should be quite complicated. More detailed information on a system of limits for Key Indicators can be found in Key Indicator limit types.

The detailed budget of a company can be the ideal case to describe the limits of financial Key Indicators. A detailed budget should consist of:

a) Sales budget

b) Schedule of anticipated incoming cash flows from sales

c) Budget for sales expenses

d) Production budget

e) Production stock budget

f) Direct materials budget

g) Schedule of payments for purchased materials

h) Direct labour budget

i) Schedule of payments for direct labour

j) Budget for general production expenses

k) Budget for administrative costs

l) Forecast Profit and Loss Statement

m) Forecast Balance Sheet

n) Forecast Cash Flow Statement

Management Information Warehouse

Development of a logical physical structure of data in the central database and data in “portions” transmitted from subsidiaries. To ensure flexibility in changes and correct documenting of the integration process, it is recommended to use tools supporting database design (e.g. ERWin, SilverRun etc.). For example, structure of data for cash flow analysis can have the following look if presented as an ER-diagram.

Choice of DBMS for the central database and formats of the transmitted data. Potential future volumes of data should be assessed and decision as for DBMS should be taken on the basis of “price-productivity” criterion. It should be kept in mind that the target system should be productive, integrated and safe.

Development of organizational mechanisms for regular or non-stop integration, which determines how integration process will function:

- Who and when starts internal mechanisms?

- How do we ensure consistency of reference and normative data?

- Which data and at what intervals) should be transmitted from subsidiaries?

An informational and logical scheme describing supplies data can look like the following:

- required views of information,

- comprehensiveness of the information, level of details,

- divisibility,

- timeliness,

- accuracy.

Analysis of capabilities of integration should analyze to what extent current information systems can present the information required by company management. This analysis includes:

- assessment of capabilities of physical access to data;

- assessment of presence of required data in currently used systems;

- assessment of data accuracy and ability to extract required data correctly;

- assessment and selection of methods for physical transmission of data from subsidiaries;

- formalization of requirements as to accuracy and comprehensiveness of data in subsidiary information systems.

When integrating information systems one should bear in mind physical and logical integration as separate parts. Physical includes transformation of different data formats, transmission of data via network, merging of received data into a central database. Logical integration means data consistency, scalability, merge of elements common by nature etc.

Companies also underestimate the volume of work which needs to be done by the management team. Often there is a perception that an integrated system would act simply as “plug-and-play” software.

A typical attitude is to opt for “big bang” implementation. Other mistakes include making no provision for simultaneous use of the old and new system, not providing enough training for new users, choosing a period of high business activity for implementation and deciding to implement several crucial business modules at once. All these risky decisions result from a lack of experience with integrated systems.

Sometimes companies opt for “in-house” development of software for a fully integrated system. This is perceived as a cheaper solution. Risks associated with such an option are the same with additional problems associated with insufficient coordination between software programmers and IT-specialists, on one side, and the management team on the other.

Implementation of an ERP system implies a need to reengineer business processes, document flow and management processes in a short time. This task is not always addressed.

Step by step improvement of current MIS & EIS

Considering the similarities in the companies and bearing in mind the high cost, risks and duration of implementation of integrated MIS software, the Project team developed a specific approach. We believe this approach to be relevant for most large Ukrainian companies.

The central focus of our approach consists of providing quick solutions for MIS needs of the company- solutions which have potential for future development. These solutions add new functionality to existing information systems and give companies an understanding of the potential role of an integrated MIS in business management.

Progressive step-by-step implementation

Speedy implementation of management tools has several important and positive impacts on the company and provides the following results:

- Managers better understand and develop their needs for information and techniques;

- It further develops management skills;

- It creates understanding of the role of MIS in enterprise management and, thus, forms a basis for any future ERP system;

- It gives fast and tangible results with limited cost;

- It improves the skills of IT staff and their understanding of management needs.

The core of our approach is a step-by-step introduction of management solutions which have potential for future development.

Tools for top management

The Project developed the following solutions aimed at improving information for top management:

- Panel of Key Indicators;

- Budgeting Tool;

- Order Tracing Tool;

- Quotation Tool.

Any other tool that is important for a company may be implemented similarly.

Some support on operational level

In order to implement the management tools, it is quite often necessary to improve the systems at operational level. This is in order to automate the use of these tools as much as possible.

This support may cover several areas:

- Hardware, networking and systems architecture;

- Basis accounting system with implementation of a popular 1C software;

- Integration of different information systems within the company;

- Document flows and workgroup management on the basis of Intranet technology etc.

Benefits of the proposed approach

- Implementation of management tools is not expensive. The company improves it’s current system and uses previous investments in IT effectively;

- Managers achieve their expectation from MIS, as they receive important for decision making information in proper time;

-Staff get better understanding of MIS benefits;

- Company may move to new ERP system without losing management.

The functioning of order progress control in using the proposed system is illustrated in the following using fictitious order data until delivery, displayed as picture 1 on page 7. The direct cost data are taken from the first order (xxxxx8500) on page 6.

The subject order has been started in week 2, 4, 6 for the manufacturing of the subassemblies 1 and 2, the housing, and the external component respectively. Completion was programmed for week 14. The actual execution of the order differed from the plan as follows (see table “Order tracking data total”):

• the subassembly 1 was started in week 3 instead of week 2; it was completed in week 7 instead of week 6;
• the subassembly 2 was started as planned in week 2, but finished one week early (week 5 instead of week 6);
• the housing was started as planned in week 4, and finished one week late (week 7 instead of week 6);
• the assembly 1 was started one week late in week 7 and delivered one week early in week 9;
• the external component was started as planned in week 6, end delivered 2 weeks early in week 8;
• the final assembling/testing started one week early in week 9; the delivery took place one week late in week 15.

On the basis of this performance data and the direct cost data stored in the system, the management information for this order as of week 9 and 14 would display the following information.

Order tracking reports

To illustrate the functioning of the system, fictitious management reports demonstrating the interactions between delivery performance and the cost involved have been compiled for the weeks 9 and 14.

In the report for week 9, all events after this point in time are not taken into account. The final assembling activity/testing having started one week early, all direct materials are already in final assembling/testing (184 i.e. the total direct material cost of the transformer of the orderxxxxx8500).

According to plan, at this point in time, they should still stand in assembling 1 (134) to be transferred to final assembling in week 10, and in the external component activity (20) to be transferred in week 10. The only material cost planned to be in final assembling/testing in week 9 is the direct material cost for the housing (20)- because the housing was planned to be completed week 6, with the housing at this point in time being transferred to final assembling. The total costs engaged in week 9 are 10 higher than planned because final assembling/testing (engaging direct material cost of 10) has started to work one week early. This advanced cost engagement would have been compensated if the finished product would have been delivered one week early because the total direct material cost of 184 would have left work-in-progress one week earlier than planned.

This, however, has not happened. The advantage achieved in the previous production stages (final assembling/testing could be launched one week early) was lost during final assembling (delivery one week late).