ERP & Related Technologies

ERP AND RELATED TECHNOLOGIES
--Saurabh Shukla
Objective
In this unit, we shall cover the following topics in detail:
a)      Concept of Business Process Reengineering
b)      Role of information technology & Impact of BPR on organizational performance
c)      Tools to support BPR & Benefits to Business organization
d)     Meaning of 'Management Information Systems (MIS) & Risks Associated With MIS
e)      MIS reviews
f)       Decision Support System (DSS) and its applications
g)      Taxonomies & History of DSS
h)      Architecture of DSS
i)        Characteristics and Capabilities of DSS
j)        Meaning & scope of Executive Information System
k)      Contents of EIS
l)        Characteristics of Successful EIS Implementations
m)     Information Sharing Vs Information Hoarding
n)      EIS Design, Prototyping & Evaluation
o)      Advantages and disadvantages of EIS
p)      Data warehousing and its applications
q)      Data Warehouse Design and Creation
r)       Multi-dimensional Analysis Tools
s)       History of data warehousing
t)       Advantages of data warehousing & its limitations
u)      Concept of DATA MINING and its applications
v)       Technological infrastructure required for Data Mining
w)     Meaning of OLAP, MOLAP, HOLAP and its advantages
Business Process Reengineering
Davenport & Short (1990) define business process as "a set of logically related tasks performed to achieve a defined business outcome." A process is "a structured, measured set of activities designed to produce a specified output for a particular customer or market. It implies a strong emphasis on how work is done within an organization" (Davenport 1993). In their view processes have two important characteristics: (i) They have customers (internal or external), (ii) They cross organizational boundaries, i.e., they occur across or between organizational subunits. One technique for identifying business processes in an organization is the value chain method proposed by Porter and Millar (1985).
Processes are generally identified in terms of beginning and end points, interfaces, and organization units involved, particularly the customer unit. High Impact processes should have process owners. Examples of processes include: developing a new product; ordering goods from a supplier; creating a marketing plan; processing and paying an insurance claim; etc.
Business process reengineering (often referred to by the acronym BPR) is the main way in which organizations become more efficient and modernize. Business process reengineering transforms an organization in ways that directly affect performance
Business process reengineering (BPR) is the analysis and redesign of workflow within and between enterprises. BPR reached its heyday in the early 1990's when Michael Hammer and James Champy published their best-selling book, "Reengineering the Corporation". The authors promoted the idea that sometimes radical redesign and reorganization of an enterprise (wiping the slate clean) was necessary to lower costs and increase quality of service and that information technology was the key enabler for that radical change. Hammer and Champy felt that the design of workflow in most large corporations was based on assumptions about technology, people, and organizational goals that were no longer valid. They suggested seven principles of reengineering to streamline the work process and thereby achieve significant levels of improvement in quality, time management, and cost:
1. Organize around outcomes, not tasks.
2. Identify all the processes in an organization and prioritize them in order of redesign urgency.
3. Integrate information processing work into the real work that produces the information.
4. Treat geographically dispersed resources as though they were centralized.
5. Link parallel activities in the workflow instead of just integrating their results.
6. Put the decision point where the work is performed, and build control into the process.
7. Capture information once and at the source.
Role of information technology
Information technology (IT) has historically played an important role in the reengineering concept. It is considered by some as a major enabler for new forms of working and collaborating within an organization and across organizational borders.
The early BPR literature, e.g. Hammer & Champy (1993), identified several so called disruptive technologies that were supposed to challenge traditional wisdom about how work should be performed.
1. Shared databases, making information available at many places
2. Expert systems, allowing generalists to perform specialist tasks
3. Telecommunication networks, allowing organizations to be centralized and decentralized at the same time
4. Decision-support tools, allowing decision-making to be a part of everybody's job
5. Wireless data communication and portable computers, allowing field personnel to work office independent
6. Interactive videodisk, to get in immediate contact with potential buyers
7. Automatic identification and tracking, allowing things to tell where they are, instead of requiring to be found
8. High performance computing, allowing on-the-fly planning and revisioning
In the mid 1990s, especially workflow management systems were considered as a significant contributor to improved process efficiency. Also ERP (Enterprise Resource Planning) vendors, such as SAP, positioned their solutions as vehicles for business process redesign and improvement.
Impact of BPR on organizational performance
The two cornerstones of any organization are the people and the processes. If individuals are motivated and working hard, yet the business processes are cumbersome and non-essential activities remain, organizational performance will be poor. Business Process Reengineering is the key to transforming how people work. What appear to be minor changes in processes can have dramatic effects on cash flow, service delivery and customer satisfaction. Even the act of documenting business processes alone will typically improve organizational efficiency by 10%.
Tips for Implementation of BPR project
The best way to map and improve the organization's procedures is to take a top down approach, and not undertake a project in isolation. That means:
• Starting with mission statements that define the purpose of the organization and describe what sets it apart from others in its sector or industry.
• Producing vision statements which define where the organization is going, to provide a clear picture of the desired future position.
• Build these into a clear business strategy thereby deriving the project objectives.
• Defining behaviours that will enable the organization to achieve its' aims.
• Producing key performance measures to track progress.
• Relating efficiency improvements to the culture of the organization
• Identifying initiatives that will improve performance.
Once these building blocks in place, the BPR exercise can begin
Methodology
Although the labels and steps differ slightly, the early methodologies that were rooted in IT-centric BPR solutions share many of the same basic principles and elements. The following outline is one such model, based on the PRLC (Process Reengineering Life Cycle) approach. A more detailed description of this model is described here:
Simplified schematic outline of using a business process approach, exemplified for pharmaceutical R&D:
1.         Envision new processes
1.         Secure management support
2.         Identify reengineering opportunities
3.         Identify enabling technologies
4.         Align with corporate strategy

2.         Initiating change
1.         Set up reengineering team
2.         Outline performance goals
3.         Process diagnosis
1.         Describe existing processes
2.         Uncover pathologies in existing processes
4.         Process redesign
1.         Develop alternative process scenarios
2.         Develop new process design
3.         Design HR architecture
4.         Select IT platform
5.         Develop overall blueprint and gather feedback
5.         Reconstruction
1.         Develop/install IT solution
2.         Establish process changes
6.         Process monitoring
1.         Performance measurement, including time, quality, cost, IT performance
2.         Link to continuous improvement
Loop-back to diagnosis
Benefiting from lessons learned from the early adopters, some BPR practitioners advocated a change in emphasis to a customer-centric, as opposed to an IT-centric, methodology. One such methodology, that also incorporated a Risk and Impact Assessment to account for the impact that BPR can have on jobs and operations, was described by Lon Roberts (1994). Roberts also stressed the use of change management tools to proactively address resistance to change—a factor linked to the demise of many reengineering initiatives that looked good on the drawing board.
Also within the management consulting industry, a significant number of methodological approaches have been developed
Tools to support BPR
When a BPR project is undertaken across the organization, it can require managing a massive amount of information about the processes, data and systems. If you don't have an excellent tool to support BPR, the management of this information can become an impossible task. The use of a good BPR/documentation tool is vital in any BPR project.
The types of attributes you should look for in BPR software are:
• Graphical interface for fast documentation
• "Object oriented" technology, so that changes to data (eg: job titles) only need to be made in one place, and the change automatically appears throughout all the organization's procedures and documentation.
• Drag and drop facility so you can easily relate organizational and data objects to each step in the process
• Customizable meta data fields, so that you can include information relating to your industry, business sector or organization in your documentation
• Analysis, such as swim-lanes to show visually how responsibilities in a process are transferred between different roles, or where data items or computer applications are used.
• Support for Value Stream mapping.
• CRUD or RACI reports, to provide evidence for process improvement.
• The ability to assess the processes against agreed international standards
• Simulation software to support 'what-if' analyses during the design phase of the project to develop LEAN processes
• The production of word documents or web site versions of the procedures at the touch of a single button, so that the information can be easily maintained and updated.
The software we use by choice is Protos, a very comprehensive Dutch system that has been translated into English. Protos meets all the above requirements, and many more, and is better than any system originated in English that we have seen.
Benefits to Business organization
BPR, if implemented properly, can give huge returns. BPR has helped giants like Procter and Gamble Corporation and General Motors Corporation succeed after financial drawbacks due to competition. It helped American Airlines somewhat get back on track from the bad debt that is currently haunting their business practice. BPR is about the proper method of implementation.
General Motors Corporation implemented a 3-year plan to consolidate their multiple desktop systems into one. It is known internally as "Consistent Office Environment" (Booker). This reengineering process involved replacing the numerous brands of desktop systems, network operating systems and application development tools into a more manageable number of vendors and technology platforms. According to Donald G. Hedeen, director of desktops and deployment at GM and manager of the upgrade program, he says that the process "lays the foundation for the implementation of a common business communication strategy across General Motors." (Booker). Lotus Development Corporation and Hewlett-Packard Development Company, formerly Compaq Computer Corporation, received the single largest non-government sales ever from General Motors Corporation. GM also planned to use Novell NetWare as a security client, Microsoft Office and Hewlett-Packard printers. According to Donald G. Hedeen, this saved GM 10% to 25% on support costs, 3% to 5% on hardware, 40% to 60% on software licensing fees, and increased efficiency by overcoming incompatibility issues by using just one platform across the entire company.
Southwest Airlines offers another successful example of reengineering their company and using Information Technology the way it was meant to be implemented. In 1992, Southwest Airlines had a revenue of $1.7 billion and an after-tax profit of $91 million. American Airlines, the largest U.S. carrier, on the other hand had a revenue of $14.4 billion dollars but lost $475 million and has not made a profit since 1989 (Furey and Diorio, 1994). Companies like Southwest Airlines know that their formula for success is easy to copy by new start-ups like Morris, Reno, and Kiwi Airlines. In order to stay in the game of competitive advantage, they have to continuously reengineer their strategy. BPR helps them be original.
Michael Dell is the founder and CEO of DELL Incorporated, which has been in business since 1983 and has been the world's fastest growing major PC Company. Michael Dell's idea of a successful business is to keep the smallest inventory possible by having a direct link with the manufacturer. When a customer places an order, the custom parts requested by the customer are automatically sent to the manufacturer for shipment. This reduces the cost for inventory tracking and massive warehouse maintenance. Dell's website is noted for bringing in nearly "$10 million each day in sales."(Smith, 1999). Michael Dell mentions: "If you have a good strategy with sound economics, the real challenge is to get people excited about what you're doing. A lot of businesses get off track because they don't communicate an excitement about being part of a winning team that can achieve big goals. If a company can't motivate its people and it doesn't have a clear compass, it will drift." (Smith, 1999) Dell's stocks have been ranked as the top stock for the decade of the 1990s, when it had a return of 57,282% (Knestout and Ramage, 1999). Michael Dell is now concentrating more on customer service than selling computers since the PC market price has pretty much equalized. Michael Dell notes: "The new frontier in our industry is service, which is a much greater differentiator when price has been equalized. In our industry, there's been a pretty huge gap between what customers want in service and what they can get, so they've come to expect mediocre service. We may be the best in this area, but we can still improve quite a bit—in the quality of the product, the availability of parts, service and delivery time." (Smith, 1999) Michael Dell understands the concept of BPR and really recognizes where and when to reengineer his business.
Ford reengineered their business and manufacturing process from just manufacturing cars to manufacturing quality cars, where the number one goal is quality. This helped Ford save millions on recalls and warranty repairs. Ford has accomplished this goal by incorporating barcodes on all their parts and scanners to scan for any missing parts in a completed car coming off of the assembly line. This helped them guarantee a safe and quality car. They have also implemented Voice-over-IP (VoIP) to reduce the cost of having meetings between the branches.
A multi-billion dollar corporation like Procter and Gamble Corporation, which carries 300 brands and growing really has a strong grasp in re-engineering. Procter and Gamble Corporation's chief technology officer, G. Gil Cloyd, explains how a company which carry multiple brands has to contend with the "classic innovator's dilemma — most innovations fail, but companies that don't innovate die. His solution, innovating innovation..." (Teresko, 2004). Cloyd has helped a company like Procter and Gamble grow to $5.1 billion by the fiscal year of 2004. According to Cloyd's scorecard, he was able to raise the volume by 17%, the organic volume by 10%, sales are at $51.4 billion up by 19%, with organic sales up 8%, earnings are at $6.5 billion up 25% and share earnings up 25%. Procter and Gamble also has a free cash flow of $7.3 billion or 113% of earnings, dividends up 13% annually with a total shareholder return of 24%. Cloyd states: "The challenge we face is the competitive need for a very rapid pace of innovation. In the consumer products world, we estimate that the required pace of innovation has double in the last three years. Digital technology is very important in helping us to learn faster." (Teresko, 2004) G. Gil Cloyd also predicts, in the near future, "as much as 90% of P&G's R&D will be done in a virtual world with the remainder being physical validation of results and options." (Teresko, 2004).
Management Information Systems (MIS)
A management information system (MIS) is a system or process that provides the information necessary to manage an organization effectively. MIS and the information it generates are generally considered essential components of  prudent and reasonable business decisions.
The importance of maintaining a consistent approach to the development, use, and review of MIS systems within the institution must be an ongoing concern of both bank management and OCC examiners. MIS should have a clearly defined framework of guidelines, policies or practices, standards, and procedures for the organization. These should be followed throughout the institution in the development, maintenance, and use of all MIS.
MIS is viewed and used at many levels by management. It should be supportive of the institution's longer term strategic goals and objectives. To the other extreme it is also those everyday financial accounting systems that are used to ensure basic control is maintained over financial recordkeeping activities.

Financial accounting systems and subsystems are just one type of institutional
MIS. Financial accounting systems are an important functional element or part of the total MIS structure. However, they are more narrowly focused on the internal balancing of an institution's books to the general ledger and other financial accounting subsystems. For example, accrual adjustments, reconciling and correcting entries used to reconcile the financial systems to the general ledger are not always immediately entered into other MIS systems.
Accordingly, although MIS and accounting reconcilement totals for related listings and activities should be similar, they may not necessarily balance. An institution's MIS should be designed to achieve the following goals:
a)      Enhance communication among employees.
b)      Deliver complex material throughout the institution.
c)      Provide an objective system for recording and aggregating information.
d)     Reduce expenses related to labor-intensive manual activities.
e)      Support the organization's strategic goals and direction.
Because MIS supplies decision makers with facts, it supports and enhances the overall decision making process. MIS also enhances job performance throughout an institution. At the most senior levels, it provides the data and information to help the board and management make strategic decisions. At other levels, MIS provides the means through which the institution's activities are monitored and information is distributed to management, employees, and customers.
Effective MIS should ensure the appropriate presentation formats and time frames required by operations and senior management are met. MIS can be maintained and developed by either manual or automated systems or a combination of both. It should always be sufficient to meet an institution's unique business goals and objectives. The effective deliveries of an institution's products and services are supported by the MIS. These systems should be accessible and useable at all appropriate levels of the organization.
MIS is a critical component of the institution's overall risk management strategy. MIS supports management's ability to perform such reviews. MIS should be used to recognize, monitor, measure, limit, and manage risks. Risk management involves four main elements:
a)      Policies or practices.
b)      Operational processes.
c)      Staff and management.
d)     Feedback devices.
Frequently, operational processes and feedback devices are intertwined and cannot easily be viewed separately. The most efficient and useable MIS should be both operational and informational. As such, management can use MIS to measure performance, manage resources, and help an institution comply with regulatory requirements. One example of this would be the managing and reporting of loans to insiders. MIS can also be used by management to provide feedback on the effectiveness of risk controls.
Controls are developed to support the proper management of risk through the institution's policies or practices, operational processes, and the assignment of duties and responsibilities to staff and managers.
Definition : ''Management Information Systems (MIS) is a general name for the academic discipline covering the application of people, technologies, and procedures — collectively called information systems — to solve business problems. MIS are distinct from regular information systems in that they are used to analyze other information systems applied in operational activities in the organization. Academically, the term is commonly used to refer to the group of information management methods tied to the automation or support of human decision making, e.g. Decision Support Systems, Expert systems, and Executive information systems.
It includes manual and automated systems designed to provide management with timely and relevant information that is necessary to successfully manage the business or department.
Risks Associated With MIS
Risk reflects the potential, the likelihood, or the expectation of events that could adversely affect earnings or capital. Management uses MIS to help in the assessment of risk within an institution. Management decisions based upon ineffective, inaccurate, or incomplete MIS may increase risk in a number of areas such as credit quality, liquidity, market/pricing, interest rate, or foreign currency. A flawed MIS causes operational risks and can adversely affect an organization's monitoring of its fiduciary, consumer, fair lending, Bank Secrecy Act, or other compliance-related activities.
Since management requires information to assess and monitor performance at all levels of the organization, MIS risk can extend to all levels of the operations. Additionally, poorly programmed or non-secure systems in which data can be manipulated and/or systems requiring ongoing repairs can easily disrupt routine work flow and can lead to incorrect decisions or impaired planning.
Assessing Vulnerability To MIS Risk
To function effectively as an interacting, interrelated, and interdependent feedback tool for management and staff, MIS must be "useable." The five elements of a useable MIS system are: timeliness, accuracy, consistency, completeness, and relevance. The usefulness of MIS is hindered whenever one or more of these elements is compromised.

Timeliness
To simplify prompt decision making, an institution's MIS should be capable of providing and distributing current information to appropriate users. Information systems should be designed to expedite reporting of information. The system should be able to quickly collect and edit data, summarize results, and be able to adjust and correct errors promptly.

Accuracy
A sound system of automated and manual internal controls must exist throughout all information systems processing activities. Information should receive appropriate editing, balancing, and internal control checks. A comprehensive internal and external audit program should be employed to ensure the adequacy of internal controls.

Consistency
To be reliable, data should be processed and compiled consistently and uniformly. Variations in how data is collected and reported can distort information and trend analysis. In addition, because data collection and reporting processes will change over time, management must establish sound procedures to allow for systems changes. These procedures should be well defined and documented, clearly communicated to appropriate employees, and should include an effective monitoring system.

Completeness
Decision makers need complete and pertinent information in a summarized form. Reports should be designed to eliminate clutter and voluminous detail, thereby avoiding "information overload."

Relevance
Information provided to management must be relevant. Information that is inappropriate, unnecessary, or too detailed for effective decision making has no value. MIS must be appropriate to support the management level using it. The relevance and level of detail provided through MIS systems directly correlate to what is needed by the board of directors, executive management, departmental or area mid-level managers, etc. in the performance of their jobs.

Achieving Sound MIS
The development of sound MIS is the result of the development and enforcement of a culture of system ownership. An "owner" is a system user who knows current customer and constituent needs and also has budget authority to fund new projects. Building "ownership" promotes pride in institution processes and helps ensure accountability.
Although MIS does not necessarily reduce expenses, the development of meaningful systems, and their proper use, will lessen the probability that erroneous decisions will be made because of inaccurate or untimely information. Erroneous decisions invariably misallocate and/or waste resources. This may result in an adverse impact on earnings and/or capital. MIS which meets the five elements of useability is a critical ingredient to an institution's short- and long-range planning efforts. To achieve sound MIS, the organization's planning process should include consideration of MIS needs at both the tactical and strategic levels. For example, at a tactical level MIS systems and report output should support the annual operating plan and budgetary processes. They should also be used in support of the long term strategic MIS and business planning initiatives. Without the development of an effective MIS, it is more difficult for management to measure and monitor the success of new initiatives and the progress of ongoing projects. Two common examples of this would be the management of mergers and acquisitions or the continuing development and the introduction of new products and services.
Management needs to ensure that MIS systems are developed according to a sound methodology that encompasses the following phases:
a)      Appropriate analysis of system alternatives, approval points as the system is developed or acquired, and task organization.
b)      Program development and negotiation of contracts with equipment and software vendors.
c)      Development of user instructions, training, and testing of the system.
d)     Installation and maintenance of the system.
Management should also consider use of "project management techniques" to monitor progress as the MIS system is being developed. Internal controls must be woven into the processes and periodically reviewed by auditors.
Management also should ensure that managers and staff receive initial and ongoing training in MIS. In addition, user manuals should be available and provide the following information:
        i.            A brief description of the application or system.
      ii.            Input instructions, including collection points and times to send updated information.
    iii.            Balancing and reconciliation procedures.
    iv.            A complete listing of output reports, including samples.
Depending on the size and complexity of its MIS system, an institution may need to use different manuals for different users such as first-level users, unit managers, and programmers.
MIS Reviews
By its very nature, management information is designed to meet the unique needs of individual institutions. As a result, MIS requirements will vary depending on the size and complexity of the operations. For example, systems suitable for community sized institutions will not necessarily be adequate for larger institutions. However, basic information needs or requirements are similar in all financial institutions regardless of size. The complexity of the operations and/or activities, together with institution size, point to the need for MIS of varying degrees of complexity to support the decision-making processes. Examiners should base MIS reviews on an evaluation of whether the system(s) provide management and directors with the information necessary to guide operations, support timely decision making, and help management monitor progress toward reaching institutional goals and objectives. Although examiners should  encourage management to develop sound information systems, they also should be reasonable in their expectations about what constitutes suitable MIS.
Examiner MIS reviews are normally focused on a specific area of activity, on a clearly identifiable departmental or functional basis, or as a part of the activity being examined within a larger department. During the examination, the MIS review should occur at both a macro (big picture) level and also at the micro (functional/product oriented view of the business) level. The examiner-in-charge of the MIS-review program should look at the useability and effectiveness of the corporate-wide MIS structure.
The examiner should also collect MIS related observations and information from the examiners-in-charge of the other areas under review. It would be very difficult for one examiner to attempt to perform a detailed MIS review for all of an organization's functional and operational areas of activity. It is practical and reasonable, however, to have this lead examiner coordinate and consolidate the MIS reviews from the other examination areas. The MIS related feedback received from other area examiners provides important and practical input to the MIS review examiner. The consolidation, coordination, and analysis of this MIS feedback can be used to reach supportable macrolevel conclusions and recommendations for corporate-wide MIS activities. MIS reviews in the functional or product review areas generally should be performed by an examiner who is considered to be a subject matter expert (SME) in the area of activities or operations that are being supported by the MIS systems or processes under review. The SME must have a thorough and complete understanding of the baseline "business" supported by the MIS system(s) under review. A solid understanding of the business is fundamental to the completion of a meaningful MIS review. The decision regarding the overall quality and effectiveness of MIS generally should be made by the SME for the area under review. The SME for each area where MIS is under review must subsequently communicate MIS related findings, conclusions, and opinions to the examiner charged with the responsibility for the complete MIS review work program at that examination. This is clearly a collaborative effort among area SMEs and the examiner charged with the responsibility for this area of review.
The examiner coordinating the overall MIS review program should be a commercial examiner with broad experience and understanding which covers many areas of organizational operations and activity. Alternatively, a bank information systems (BIS) examiner could serve in this capacity. BIS examiners should be consulted whenever there are questions, issues, or concerns surrounding the use of information systems (IS) or electronic data processing (EDP) technology or the effectiveness of MIS-related internal controls in any automated area of the organization's activities.
When performing MIS reviews, examiners should use the guidelines in this booklet to determine if management has:
        i.            Identified the institution's specific information requirements— Examiners can focus on specific information needs related to issues such as asset quality, interest rate risk, regulatory reporting, and compliance. If possible, the MIS review should be concurrent with examinations of the commercial, consumer, fiduciary, and BIS activities. This would enhance interaction and communication among examiners.
      ii.            Established effective reporting mechanisms to guide decisions— This process includes reviewing controls that ensure that information is reliable, timely, accurate, and confidential.
Decision Support System
Decision Support Systems (DSS) are a specific class of computerized information system that supports business and organizational decision-making activities. A properly designed DSS is an interactive software-based system intended to help decision makers compile useful information from raw data, documents, personal knowledge, and/or business models to identify and solve problems and make decisions.
1.      Typical information that a decision support application might gather and present would be.
2.      Accessing all of your current information assets, including legacy and relational data sources, cubes, data warehouses, and data marts
3.      Comparative sales figures between one week and the next
4.      Projected revenue figures based on new product sales assumptions
5.      The consequences of different decision alternatives, given past experience in a context that is described
Definition: DSS, refers to an interactive computerized system that gathers and presents data from a wide range of sources, typically for business purposes. DSS applications are systems and subsystems that help people make decisions based on data that is culled from a wide range of sources
For example: a national on-line book seller wants to begin selling its products internationally but first needs to determine if that will be a wise business decision. The vendor can use a DSS to gather information from its own resources (using a tool such as OLAP) to determine if the company has the ability or potential ability to expand its business and also from external resources, such as industry data, to determine if there is indeed a demand to meet. The DSS will collect and analyze the data and then present it in a way that can be interpreted by humans. Some decision support systems come very close to acting as artificial intelligence agents.
DSS applications are not single information resources, such as a database or a program that graphically represents sales figures, but the combination of integrated resources working together.
Information Builders like WebFOCUS reporting software is ideally suited for building decision support systems due to its wide reach of data, interactive facilities, ad hoc reporting capabilities, quick development times, and simple Web-based deployment.

The best decision support systems include high-level summary reports or charts and allow the user to drill down for more detailed information.
Decision support system (DSS) can be defined as a computer program application that analyzes business data and presents it so that users can make business decisions more easily. It is an "informational application" (to distinguish it from an "operational application" that collects the data in the course of normal business operation).Typical information that a decision support application might gather and present would be:
a)      Comparative sales figures between one week and the next
b)      Projected revenue figures based on new product sales assumptions
c)      The consequences of different decision alternatives, given past experience in a context that is described
A decision support system may present information graphically and may include an expert system or artificial intelligence (AI). It may be aimed at business executives or some other group of knowledge workers
Taxonomies of DSS
As with the definition, there is no universally accepted taxonomy of DSS either. Different authors propose different classifications. Using the relationship with the user as the criterion, Haettenschwiler differentiates passive, active, and cooperative DSS. A passive DSS is a system that aids the process of decision making, but that cannot bring out explicit decision suggestions or solutions. An active DSS can bring out such decision suggestions or solutions. A cooperative DSS allows the decision maker (or its advisor) to modify, complete, or refine the decision suggestions provided by the system, before sending them back to the system for validation. The system again improves, completes, and refines the suggestions of the decision maker and sends them back to her for validation. The whole process then starts again, until a consolidated solution is generated.
Using the mode of assistance as the criterion, Power differentiates communication-driven DSS, data-driven DSS, document-driven DSS, knowledge-driven DSS, and model-driven DSS.
Model-driven DSS :   A model-driven DSS emphasizes access to and manipulation of a statistical, financial, optimization, or simulation model. Model-driven DSS use data and parameters provided by users to assist decision makers in analyzing a situation; they are not necessarily data intensive. Dicodess is an example of an open source model-driven DSS generator. Early versions of model-driven DSS were called model-oriented DSS by Alter (1980), computationally oriented DSS by Bonczek, Holsapple and Whinston (1981) and later spreadsheet-oriented and solver-oriented DSS by Holsapple and Whinston (1996).
The first commercial tool for building model-driven DSS using financial and quantitative models was called IFPS, an acronym for interactive financial planning system. It was developed in the late 1970's by Gerald R. Wagner and his students at the University of Texas. Wagner’s company, EXECUCOM Systems, marketed IFPS until the mid 1990s. Gray’s Guide to IFPS (1983) promoted the use of the system in business schools. Another DSS generator for building specific systems based upon the Analytic Hierarchy Process (Saaty, 1982), called Expert Choice, was released in 1983. Expert Choice supports personal or group decision making. Ernest Forman worked closely with Thomas Saaty to design Expert Choice.
In 1978, Dan Bricklin and Bob Frankston co-invented the software program VisiCalc (Visible Calculator). VisiCalc provided managers the opportunity for hands-on computer-based analysis and decision support at a reasonably low cost.  VisiCalc was the first "killer" application for personal computers and made possible development of many model-oriented, personal DSS for use by managers. The history of microcomputer spreadsheets is described in Power (2000). In 1987, Frontline Systems founded by Dan Fylstra marketed the first optimization solver add-in for Microsoft Excel.
Communication -driven DSS:          Communications-driven DSS use network and communications technologies to facilitate decision-relevant collaboration and communication. In these systems, communication technologies are the dominant architectural component. Tools used include groupware, video conferencing and computer-based bulletin boards (Power, 2002).
In the early 1980s, academic researchers developed a new category of software to support group decision-making called Group Decision Support Systems abbreviated GDSS  (cf., Gray, 1981; Huber, 1982; Turoff and Hiltz, 1982). Mindsight from Execucom Systems, GroupSystems developed at the University of Arizona and the SAMM system developed by University of Minnesota researchers were early Group DSS. Eventually GroupSystems matured into a commercial product.
Generally, groupware, bulletin boards, audio and videoconferencing are the primary technologies for communications-driven decision support. In the past few years, voice and video delivered using the Internet protocol have greatly expanded the possibilities for synchronous communications-driven DSS.
Data-driven DSS:      a data-driven DSS emphasizes access to and manipulation of a time-series of internal company data and sometimes external and real-time data. Simple file systems accessed by query and retrieval tools provide the most elementary level of functionality. Data warehouse systems that allow the manipulation of data by computerized tools tailored to a specific task and setting or by more general tools and operators provide additional functionality. Data-Driven DSS with On-line Analytical Processing (cf., Codd et al., 1993) provide the highest level of functionality and decision support that is linked to analysis of large collections of historical data. Executive Information Systems are examples of data-driven DSS (Power, 2002). Initial examples of these systems were called data-oriented DSS, Analysis Information Systems (Alter, 1980) and retrieval-only DSS by Bonczek, Holsapple and Whinston (1981).
One of the first data-driven DSS was built using an APL-based software package called AAIMS, An Analytical Information Management System. It was developed from 1970-1974 by Richard Klaas and Charles Weiss at American Airlines (cf. Alter, 1980).
Document-driven DSS: A document-driven DSS uses computer storage and processing technologies to provide document retrieval and analysis. Large document databases may include scanned documents, hypertext documents, images, sounds and video. Examples of documents that might be accessed by a document-driven DSS are policies and procedures, product specifications, catalogs, and corporate historical documents, including minutes of meetings and correspondence. A search engine is a primary decision-aiding tool associated with a document-driven DSS (Power, 2002). These systems have also been called text-oriented DSS (Holsapple and Whinston,1996).
Text and document management emerged in the 1970s and 1980s as an important, widely used computerized means for representing and processing pieces of text (Holsapple and Whinston, 1996). The first scholarly article for this category of DSS was written by Swanson and Culnan (1978). They reviewed document-based systems for management planning and control. Until the mid-1990s little progress was made in helping managers find documents to support their decision making. Fedorowicz (1993, 1996) helped define the need for such systems. She estimated in her 1996 article that only 5 to 10 percent of stored business documents are available to managers for use in decision making. The World-wide web technologies significantly increased the availability of documents and facilitated the development of document-driven DSS..
Knowledge-driven DSS:       Knowledge-driven DSS can suggest or recommend actions to managers. These DSS are person-computer systems with specialized problem-solving expertise. The "expertise" consists of knowledge about a particular domain, understanding of problems within that domain, and "skill" at solving some of these problems (Power, 2002). These systems have been called suggestion DSS (Alter, 1980) and knowledge-based DSS (Klein & Methlie, 1995). Goul, Henderson, and Tonge (1992) examined Artificial Intelligence (AI)  contributions to DSS.
In 1965, a Stanford University research team led by Edward Feigenbaum created the DENDRAL expert system. DENDRAL led to the development of other rule-based reasoning programs including MYCIN, which helped physicians diagnose blood diseases based on sets of clinical symptoms. The MYCIN project resulted in development of the first expert-system shell (Buchanan and Shortliffe, 1984).
Bonczek, Holsapple and Whinston’s (1981) book created interest in using these technologies for DSS. In 1983, Dustin Huntington established EXSYS. That company and product made it practical to use PC based tools to develop expert systems. By 1992, some 11 shell programs were available for the MacIntosh platform, 29 for IBM-DOS platforms, 4 for Unix platforms, and 12 for dedicated mainframe applications (National Research Council, 1999). Artificial Intelligence systems have been developed to detect fraud and expedite financial transactions, many additional medical diagnostic systems have been based on AI, expert systems have been used for scheduling in manufacturing operation and web-based advisory systems. In recent years, connecting expert systems technologies to relational databases with web-based front ends has broadened the deployment and use of knowledge-driven DSS.
Web-based DSS: Power defined a Web-based decision support system as a computerized system that delivers decision support information or decision support tools to a manager or business analyst using a "thin-client" Web browser like Netscape Navigator or Internet Explorer. The computer server that is hosting the DSS application is linked to the user's computer by a network with the TCP/IP protocol.
Beginning in approximately 1995, the World-wide Web and global Internet provided a technology platform for further extending the capabilities and deployment of computerized decision support. The release of the HTML 2.0 specifications with form tags and tables was a turning point in the development of web-based DSS. In 1995, a number of papers were presented on using the Web and Internet for decision support at the 3rd International Conference of the International Society for Decision Support Systems (ISDSS). In addition to Web-based, model-driven DSS, researchers were reporting Web access to data warehouses. DSS Research Resources was started as a web-based collection of bookmarks. By 1995, the World-Wide Web (Berners-Lee, 1996) was recognized by a number of software developers and academics as a serious platform for implementing all types of Decision Support Systems (cf., Bhargava & Power, 2001).
In November 1995, Power, Bhargava and Quek submitted the Decision Support Systems Research page for inclusion inISWorld. The goal was to provide a useful starting point for accessing Web-based material related to the design, development, evaluation, and implementation of Decision Support Systems.
In 1996-97, corporate intranets were developed to support information exchange and knowledge management. The primary decision support tools included ad hoc query and reporting tools, optimization and simulation models, online analytical processing (OLAP), data mining and data visualization. Enterprise-wide DSS using database technologies were especially popular in Fortune 2000 companies. Bhargava, Krishnan and Müller (1997) continued to discuss and experiment with electronic markets for decision technologies.
In 1999, vendors introduced new Web-based analytical applications. Many DBMS vendors shifted their focus to Web-based analytical applications and business intelligence solutions. In 2000, application service providers (ASPs) began hosting the application software and technical infrastructure for decision support capabilities. 2000 was also the year of the portal. More sophisticated "enterprise knowledge portals" were introduced by vendors that combined information portals, knowledge management, business intelligence, and communications-driven DSS in an integrated Web environment.
History of Decision Support Systems
Computerized decision support systems became practical with the development of minicomputers, timeshare operating systems and distributed computing. The history of the implementation of such systems begins in the mid-1960s. In a technology field as diverse as DSS, chronicling history is neither neat nor linear. Different people perceive the field of Decision Support Systems from various vantage points and report different accounts of what happened and what was important (cf., Arnott & Pervan, 2005; Eom & Lee, 1990b; McCosh & Correa-Perez, 2006; Power, 2003; Power, 2004a; Silver, 1991). As technology evolved new computerized decision support applications were developed and studied. Researchers used multiple frameworks to help build and understand these systems. Today one can organize the history of DSS into the five broad DSS categories explained in Power (2001; 2002; 2004b), including: communications-driven, data-driven, document driven, knowledge-driven and model-driven decision support systems.
This hypertext document is a starting point in explaining the origins of the various technology threads that are converging to provide integrated support for managers working alone, in teams and in organization hierarchies to manage organizations and make more rational decisions. History is both a guide to future activity in this field and a record of the ideas and actions of those who have helped advance our thinking and practice. Historical facts can be sorted out and better understood, but more information gathering is necessary. This web page is a starting point in collecting more first hand accounts and in building a more complete mosaic of what was occurring in universities, software companies and in organizations to build and use DSS.
This document traces decision support applications and research studies related to model and data-oriented systems, management expert systems, multidimensional data analysis, query and reporting tools, online analytical processing (OLAP), Business Intelligence, group DSS, conferencing and groupware, document management, spatial DSS and Executive Information Systems as the technologies emerge, converge and diverge. All of these technologies have been used to support decision making. A timeline of major historical milestones relevant to DSS is included in Appendix I.
The study of decision support systems is an applied discipline that uses knowledge and especially theory from other disciplines. For this reason, many DSS research questions have been examined because they were of concern to people who were building and using specific DSS. Hence much of the broad DSS knowledge base provides generalizations and directions for building more effective DSS (cf., Baskerville & Myers, 2002; Keen, 1980).
The next section describes the origins of the field of decision support systems. Section 3 discusses the decision support systems theory development that occurred in the late 1970s and early 1980s. Section 4 discusses important developments to communications-driven , data-driven, document driven, knowledge-driven and model-driven DSS (cf., Power, 2002). The final section briefly discusses how DSS practice, research and technology is continuing to evolve.
Origin of Decision Support Systems
In the 1960s, researchers began systematically studying the use of computerized quantitative models to assist in decision making and planning (Raymond, 1966; Turban, 1967; Urban, 1967, Holt and Huber, 1969). Ferguson and Jones (1969) reported the first experimental study using a computer aided decision system. They investigated a production scheduling application running on an IBM 7094. In retrospect, a major historical turning point was Michael S. Scott Morton's (1967) dissertation field research at Harvard University.
Scott Morton’s study involved building, implementing and then testing an interactive, model-driven management decision system. Fellow Harvard Ph.D. student Andrew McCosh asserts that the “concept of decision support systems was first articulated by Scott Morton in February 1964 in a basement office in Sherman Hall, Harvard Business School” (McCosh email, 2002) in a discussion they had about Scott Morton’s dissertation. During 1966, Scott Morton (1971) studied how computers and analytical models could help managers make a recurring key business planning decision. He conducted an experiment in which managers actually used a Management Decision System (MDS). Marketing and production managers used an MDS to coordinate production planning for laundry equipment. The MDS ran on an IDI 21 inch CRT with a light pen connected using a 2400 bps modem to a pair of Univac 494 systems.
The pioneering work of George Dantzig, Douglas Engelbart and Jay Forrester likely influenced the feasibility of building computerized decision support systems. In 1952, Dantzig became a research mathematician at the Rand Corporation, where he began implementing linear programming on its experimental computers. In the mid-1960s, Engelbart and colleagues developed the first hypermedia—groupware system called NLS (oNLine System). NLS facilitated the creation of digital libraries and the storage and retrieval of electronic documents using hypertext. NLS also provided for on-screen video teleconferencing and was a forerunner to group decision support systems. Forrester was involved in building the SAGE (Semi-Automatic Ground Environment) air defense system for North America completed in 1962. SAGE is probably the first computerized data-driven DSS. Also, Professor Forrester started the System Dynamics Group at the Massachusetts Institute of Technology Sloan School. His work on corporate modeling led to programming DYNAMO, a general simulation compiler.
In 1960, J.C.R. Licklider published his ideas about the future role of multiaccess interactive computing in a paper titled “Man-Computer Symbiosis.” He saw man-computer interaction as enhancing both the quality and efficiency of human problem solving and his paper provided a guide for decades of computer research to follow. Licklider was the architect of Project MAC at MIT that furthered the study of interactive computing.
By April 1964, the development of the IBM System 360 and other more powerful mainframe systems made it practical and cost-effective to develop Management Information Systems (MIS) for large companies (cf., Davis, 1974). These early MIS focused on providing managers with structured, periodic reports and the information was primarily from accounting and transaction processing systems, but the systems did not provide interactive support to assist managers in decision making.
Around 1970 business journals started to publish articles on management decision systems, strategic planning systems and decision support systems (cf.,  Sprague and Watson 1979).. For example, Scott Morton and colleagues McCosh and Stephens published decision support related articles in 1968. The first use of the term decision support system was in Gorry and Scott-Morton’s (1971) Sloan Management Review article. They argued that Management Information Systems primarily focused on structured decisions and suggested that the supporting information systems for semi-structured and unstructured decisions should be termed “Decision Support Systems”.
T.P. Gerrity, Jr. focused on Decision Support Systems design issues in his 1971 Sloan Management Review article titled "The Design of Man-Machine Decision Systems: An Application to Portfolio Management". The article was based on his MIT Ph.D. dissertation. His system was designed to support investment managers in their daily administration of a clients' stock portfolio.
John D.C. Little, also at Massachusetts Institute of Technology, was studying DSS for marketing. Little and Lodish (1969) reported research on MEDIAC, a media planning support system. Also, Little (1970) identified criteria for designing models and systems to support management decision-making. His four criteria included: robustness, ease of control, simplicity, and completeness of relevant detail. All four criteria remain relevant in evaluating modern Decision Support Systems. By 1975, Little was expanding the frontiers of computer-supported modeling. His DSS called Brandaid was designed to support product, promotion, pricing and advertising decisions. Little also helped develop the financial and marketing modeling language known as EXPRESS.
In 1974, Gordon Davis, a Professor at the University of Minnesota, published his influential text on Management Information Systems. He defined a Management Information System as "an integrated, man/machine system for providing information to support the operations, management, and decision-making functions in an organization. (p. 5)." Davis's Chapter 12 was titled "Information System Support for Decision Making" and Chapter 13 was titled "Information System Support for Planning and Control". Davis’s framework incorporated computerized decision support systems into the emerging field of management information systems.
Peter Keen and Charles Stabell claim the concept of decision support systems evolved from "the theoretical studies of organizational decisionmaking done at the Carnegie Institute of Technology during the late 1950s and early '60s and the technical work on interactive computer systems, mainly carried out at the Massachusetts Institute of Technology in the 1960s. (Keen and Scott Morton, 1978)". Herbert Simon’s books (1947, 1960) and articles provide a context for understanding and supporting decision making.
In 1995, Hans Klein and Leif Methlie noted “A study of the origin of DSS has still to be written. It seems that the first DSS papers were published by PhD students or professors in business schools, who had access to the first time-sharing computer system: Project MAC at the Sloan School, the Dartmouth Time Sharing Systems at the Tuck School. In France, HEC was the first French business school to have a time-sharing system (installed in 1967), and the first DSS papers were published by professors of the School in 1970. (p. 112).”
Theory Development
In the mid- to late 1970s, both practice and theory issues related to DSS were discussed at academic conferences including the American Institute for Decision Sciences meetings and the ACM SIGBDP Conference on Decision Support Systems in San Jose, CA in January 1977 (the proceeding were included in the journal Database). The first International Conference on Decision Support Systems was held in Atlanta, Georgia in 1981. Academic conferences provided forums for idea sharing, theory discussions and information exchange.
At about this same time, Keen and Scott Morton’s DSS textbook (1978) provided the first broad behavioral orientation to decision support system analysis, design, implementation, evaluation and development. This influential text provided a framework for teaching DSS in business schools. McCosh and Scott-Morton’s (1978) DSS book was more influential in Europe.
In 1980, Steven Alter published his MIT doctoral dissertation results in an influential book. Alter's research and papers (1975; 1977) expanded the framework for thinking about business and management DSS. Also, his case studies provided a firm descriptive foundation of decision support system examples. A number of other MIT dissertations completed in the late 1970s also dealt with issues related to using models for decision support.
Alter concluded from his research (1980) that decision support systems could be categorized in terms of the generic operations that can be performed by such systems. These generic operations extend along a single dimension, ranging from extremely data-oriented to extremely model-oriented. Alter conducted a field study of 56 DSS that he categorized into seven distinct types of DSS. His seven types include:
a)      File drawer systems that provide access to data items.
b)      Data analysis systems that support the manipulation of data by computerized tools tailored to a specific task and setting or by more general tools and operators.
c)      Analysis information systems that provide access to a series of decision-oriented databases and small models.
d)     Accounting and financial models that calculate the consequences of possible actions.
e)      Representational models that estimate the consequences of actions on the basis of simulation models.
f)       Optimization models that provide guidelines for action by generating an optimal solution consistent with a series of constraints.
g)      Suggestion models that perform the logical processing leading to a specific suggested decision for a fairly structured or well-understood task.
Donovan and Madnick (1977) classified DSS as institutional or ad hoc. Institutional DSS support decisions that are recurring. An ad hoc DSS supports querying data for one time requests. Hackathorn and Keen (1981) identified DSS in three distinct yet interrelated categories: Personal DSS, Group DSS and Organizational DSS.
In 1979, John Rockart of the Harvard Business School published a ground breaking article that led to the development of executive information systems (EISs) or executive support systems (ESS). Rockart developed the concept of using information systems to display critical success metrics for managers.
Robert Bonczek, Clyde Holsapple, and Andrew Whinston (1981) explained a theoretical framework for understanding the issues associated with designing knowledge-oriented Decision Support Systems. They identified four essential "aspects" or general components that were common to all DSS: 1. A language system (LS) that specifies all messages a specific DSS can accept; 2. A presentation system (PS) for all messages a DSS can emit; 3. A knowledge system (KS) for all knowledge a DSS has; and 4. A problem-processing system (PPS) that is the "software engine" that tries to recognize and solve problems during the use of a specific DSS. Their book explained how Artificial Intelligence and Expert Systems technologies were relevant to developing DSS.
Finally, Ralph Sprague and Eric Carlson’s (1982) book Building Effective Decision Support Systems was an important milestone. Much of the book further explained the Sprague (1980) DSS framework of data base, model base and dialog generation and management software. Also, it provided a practical, and understandable overview of how organizations could and should build DSS.  Sprague and Carlson (1982) defined DSS as "a class of information system that draws on transaction processing systems and interacts with the other parts of the overall information system to support the decision-making activities of managers and other knowledge workers in organizations.
Architecture of DSS
Decision support system primarily consists of the following :
The Database
The database contains information about internal data and external data that will contribute to the decision making process. This data is in most cases more extensive than traditional relational models
The Model Base
This module contains a set of algorithms that makes decisions based on the information in the database. This information is then summarized and displayed as tables or graphs.
The Interface
This is what the user will use to interface with the system. This is complimented with an interactive help and navigation screen.
Framework
DSS systems are not entirely different to other systems and require a structured approach. A framework was provided by Sprague and Watson (1993). The framework has three main levels. 1. Technology levels 2. People involved 3. The developmental approach
1.Technology Levels
Sprague has suggested that there are three levels of hardware and software that has been proposed for DSS.
a) Level 1 – Specific DSS
This is the actual application that will be used to by the user. This is the part of the application that allows the decision maker to make decisions in a particular problem area.the use can act upon that particular problem.
b) Level 2 – DSS Generator
This level contains Hardware/software environment that allows people to easily develop specific DSS applications. This level makes use of case tools or systems like Crystal
c) Level 3 – DSS Tools
Contains lower level hardware/software. DSS generators including special languages, function libraries and linking modules
2. People Involved
Sprague suggests there are 5 roles involved in a typical DSS development cycle.
a) The end user.
b) An intermediary.
c) DSS developer
d) Technical supporter
e) Systems Expert
3. Developmental
The developmental approach for a DSS system should be strongly iterative. This will allow for the application to be changed and redesigned at various intervals. The initial problem is used to design the system on and then tested and revised to ensure the desired outcome is achieved
Applications of DSS
DSS is extensively used in business and management. Executive dashboard and other business performance software allow faster decision making, identification of negative trends, and better allocation of business resources.
A growing area of DSS application, concepts, principles, and techniques is in agricultural production, marketing for sustainable development. For example, the DSSAT4 package, developed through financial support of USAID during the 80's and 90's, has allowed rapid assessment of several agricultural production systems around the world to facilitate decision-making at the farm and policy levels. There are, however, many constraints to the successful adoption on DSS in agriculture.
A specific example concerns the Canadian National Railway system, which tests its equipment on a regular basis using a decision support system. A problem faced by any railroad is worn-out or defective rails, which can result in hundreds of derailments per year. Under a DSS, CN managed to decrease the incidence of derailments at the same time other companies were experiencing an increase.
DSS has many applications that have already been spoken about. However, it can be used in any field where organization is necessary. Additionally, a DSS can be designed to help make decisions on the stock market, or deciding which area or segment to market a product toward.
Characteristics and Capabilities of DSS
Because there is no exact definition of DSS, there is obviously no agreement on the standard characteristics and capabilities of DSS. Turban, E.,Aronson, and J.E. constitute an ideal set of characteristics and capabilities of DSS. The key DSS characteristics and capabilities are as follows:
a.       Support for decision makers in semi-structured and unstructured problems.
b.      Support managers at all levels.
c.       Support individuals and groups.
d.      Support for interdependent or sequential decisions.
e.       Support intelligence, design, choice, and implementation.
f.       Support variety of decision processes and styles.
g.      DSS should be adaptable and flexible.
h.      DSS should be interactive and provide ease of use.
i.        Effectiveness balanced with efficiency (benefit must exceed cost).
j.        Complete control by decision-makers.
k.      Ease of development by (modification to suit needs and changing environment) end users.
l.        Support modeling and analysis.
m.    Data access.
n.      Standalone, integration and Web-based.

Benefits of DSS
a.       Improving Personal Efficiency
b.      Expediting Problem Solving
c.       Facilitating Interpersonal Communication
d.      Promoting Learning or Training
e.       Increasing Organizational Control
Executive Information System
An information system that consolidates and summarizes ongoing transactions within the organization. It provides top management with all the information it requires at all times from internal and external sources.

An Executive Information System (EIS) is a type of management information system intended to facilitate and support the information and decision making needs of senior executives by providing easy access to both internal and external information relevant to meeting the strategic goals of the organization. It is commonly considered as a specialized form of a Decision Support System (DSS).
The emphasis of EIS is on graphical displays and easy-to-use user interfaces. They offer strong reporting and drill-down capabilities. In general, EIS are enterprise-wide DSS that help top-level executives analyze, compare, and highlight trends in important variables so that they can monitor performance and identify opportunities and problems. EIS and data warehousing technologies are converging in the marketplace.
In recent years, the term EIS has lost popularity in favour of Business Intelligence (with the sub areas of reporting, analytics, and digital dashboards).
Introduction
Many senior managers find that direct on-line access to organizational data is helpful. For example, Paul Frech, president of Lockheed-Georgia, monitors employee contributions to company-sponsored programs (United Way, blood drives) as a surrogate measure of employee morale (Houdeshel and Watson 1987). C. Robert Kidder, CEO of Duracell, found that productivity problems were due to salespeople in Germany wasting time calling on small stores and took corrective action (Main 1989).
Information systems have long been used to gather and store information, to produce specific reports for workers, and to produce aggregate reports for managers. However, senior managers rarely use these systems directly, and often find the aggregate information to be of little use without the ability to explore underlying details (Watson & Rainer 1991, Crockett 1992).
An Executive Information System (EIS) is a tool that provides direct on-line access to relevant information in a useful and navigable format. Relevant information is timely, accurate, and actionable information about aspects of a business that are of particular interest to the senior manager. The useful and navigable format of the system means that it is specifically designed to be used by individuals with limited time, limited keyboarding skills, and little direct experience with computers. An EIS is easy to navigate so that managers can identify broad strategic issues, and then explore the information to find the root causes of those issues.
Executive Information Systems differ from traditional information systems in the following ways:
·         are specifically tailored to executive's information needs
·         are able to access data about specific issues and problems as well as aggregate reports
·         provide extensive on-line analysis tools including trend analysis, exception reporting & "drill-down" capability
·         access a broad range of internal and external data
·         are particularly easy to use (typically mouse or touchscreen driven)
·         are used directly by executives without assistance
·         present information in a graphical form
Purpose of EIS
The primary purpose of an Executive Information System is to support managerial learning about an organization, its work processes, and its interaction with the external environment. Informed managers can ask better questions and make better decisions. Vandenbosch and Huff (1992) from the University of Western Ontario found that Canadian firms using an EIS achieved better business results if their EIS promoted managerial learning. Firms with an EIS designed to maintain managers' "mental models" were less effective than firms with an EIS designed to build or enhance managers' knowledge.
This distinction is supported by Peter Senge in The Fifth Dimension. He illustrates the benefits of learning about the behaviour of systems versus simply learning more about their states. Learning more about the state of a system leads to reactive management fixes. Typically these reactions feed into the underlying system behaviour and contribute to a downward spiral. Learning more about system behaviour and how various system inputs and actions interrelate will allow managers to make more proactive changes to create long-term improvement.
A secondary purpose for an EIS is to allow timely access to information. All of the information contained in an EIS can typically be obtained by a manager through traditional methods. However, the resources and time required to manually compile information in a wide variety of formats, and in response to ever changing and ever more specific questions usually inhibit managers from obtaining this information. Often, by the time a useful report can be compiled, the strategic issues facing the manager have changed, and the report is never fully utilized.
Timely access also influences learning. When a manager obtains the answer to a question, that answer typically sparks other related questions in the manager's mind. If those questions can be posed immediately, and the next answer retrieved, the learning cycle continues unbroken. Using traditional methods, by the time the answer is produced, the context of the question may be lost, and the learning cycle will not continue. An executive in Rockart & Treacy's 1982 study noted that:
Your staff really can't help you think. The problem with giving a question to the staff is that they provide you with the answer. You learn the nature of the real question you should have asked when you muck around in the data (p. 9).
A third purpose of an EIS is commonly misperceived. An EIS has a powerful ability to direct management attention to specific areas of the organization or specific business problems. Some managers see this as an opportunity to discipline subordinates. Some subordinates fear the directive nature of the system and spend a great deal of time trying to outwit or discredit it. Neither of these behaviours is appropriate or productive. Rather, managers and subordinates can work together to determine the root causes of issues highlighted by the EIS.
The powerful focus of an EIS is due to the maxim "what gets measured gets done." Managers are particularly attentive to concrete information about their performance when it is available to their superiors. This focus is very valuable to an organization if the information reported is actually important and represents a balanced view of the organization's objectives.
Misaligned reporting systems can result in inordinate management attention to things that are not important or to things which are important but to the exclusion of other equally important things. For example, a production reporting system might lead managers to emphasize volume of work done rather than quality of work. Worse yet, productivity might have little to do with the organization's overriding customer service objectives.
Contents of EIS
A general answer to the question of what data is appropriate for inclusion in an Executive Information System is "whatever is interesting to executives." While this advice is rather simplistic, it does reflect the variety of systems currently in use. Executive Information Systems in government have been constructed to track data about Ministerial correspondence, case management, worker productivity, finances, and human resources to name only a few. Other sectors use EIS implementations to monitor information about competitors in the news media and databases of public information in addition to the traditional revenue, cost, volume, sales, market share and quality applications.
Frequently, EIS implementations begin with just a few measures that are clearly of interest to senior managers, and then expand in response to questions asked by those managers as they use the system. Over time, the presentation of this information becomes stale, and the information diverges from what is strategically important for the organization. A "Critical Success Factors" approach is recommended by many management theorists (Daniel, 1961, Crockett, 1992, Watson and Frolick, 1992). Practitioners such as Vandenbosch (1993) found that:
While our efforts usually met with initial success, we often found that after six months to a year, executives were almost as bored with the new information as they had been with the old. A strategy we developed to rectify this problem required organizations to create a report of the month. That is, in addition to the regular information provided for management committee meetings, the CEO was charged with selecting a different indicator to focus on each month (Vandenbosch, 1993, pp. 8-9).
While the above indicates that selection of data for inclusion in an EIS is difficult, there are several guidelines that help to make that assessment. A practical set of principles to guide the design of measures and indicators to be included in an EIS is presented below (Kelly, 1992b). For a more detailed discussion of methods for selecting measures that reflect organizational objectives, see the section "EIS and Organizational Objectives."
1.      EIS measures must be easy to understand and collect. Wherever possible, data should be collected naturally as part of the process of work. An EIS should not add substantially to the workload of managers or staff.
2.      EIS measures must be based on a balanced view of the organization's objective. Data in the system should reflect the objectives of the organization in the areas of productivity, resource management, quality and customer service.
3.      Performance indicators in an EIS must reflect everyone's contribution in a fair and consistent manner. Indicators should be as independent as possible from variables outside the control of managers.
4.      EIS measures must encourage management and staff to share ownership of the organization's objectives. Performance indicators must promote both team-work and friendly competition. Measures will be meaningful for all staff; people must feel that they, as individuals, can contribute to improving the performance of the organization.
5.      EIS information must be available to everyone in the organization. The objective is to provide everyone with useful information about the organization's performance. Information that must remain confidential should not be part of the EIS or the management system of the organization.
6.      EIS measures must evolve to meet the changing needs of the organization.
Barriers to Effectiveness
There are many ways in which an EIS can fail. Dozens of high profile, high cost EIS projects have been cancelled, implemented and rarely used, or implemented and used with negative results. An EIS is a high risk project precisely because it is intended for use by the most powerful people in an organization. Senior managers can easily misuse the information in the system with strongly detrimental effects on the organization. Senior managers can refuse to use a system if it does not respond to their immediate personal needs or is too difficult to learn and use.
Unproductive Organizational Behaviour Norms
Issues of organizational behaviour and culture are perhaps the most deadly barriers to effective Executive Information Systems. Because an EIS is typically positioned at the top of an organization, it can create powerful learning experiences and lead to drastic changes in organizational direction. However, there is also great potential for misuse of the information. Green, Higgins and Irving (1988) found that performance monitoring can promote bureaucratic and unproductive behaviour, can unduly focus organizational attention to the point where other important aspects are ignored, and can have a strongly negative impact on morale.
The key barrier to EIS effectiveness, therefore, is the way in which the organization uses the information in the system. Managers must be aware of the dangers of statistical data, and be skilled at interpreting and using data in an effective way. Even more important is the manager's ability to communicate with others about statistical data in a non-defensive, trustworthy, and constructive manner. Argyris (1991) suggests a universal human tendency towards strategies that avoid embarrassment or threat, and towards feelings of vulnerability or incompetence. These strategies include:
·         stating criticism of others in a way that you feel is valid but also in a way that prevents others from deciding for themselves
·         failing to include any data that others could use to objectively evaluate your criticism
·         stating your conclusions in ways that disguise their logical implications and denying those implications if they are suggested
To make effective use of an EIS, mangers must have the self-confidence to accept negative results and focus on the resolution of problems rather than on denial and blame. Since organizations with limited exposure to planning and targeting, data-based decision-making, statistical process control, and team-based work models may not have dealt with these behavioral issues in the past, they are more likely to react defensively and reject an EIS.
Technical Excellence
An interesting result from the Vandenbosch & Huff (1988) study was that the technical excellence of an EIS has an inverse relationship with effectiveness. Systems that are technical masterpieces tend to be inflexible, and thus discourage innovation, experimentation and mental model development.
Flexibility is important because an EIS has such a powerful ability to direct attention to specific issues in an organization. A technical masterpiece may accurately direct management attention when the system is first implemented, but continue to direct attention to issues that were important a year ago on its first anniversary. There is substantial danger that the exploration of issues necessary for managerial learning will be limited to those subjects that were important when the EIS was first developed. Managers must understand that as the organization and its work changes, an EIS must continually be updated to address the strategic issues of the day.
A number of explanations as to why technical masterpieces tend to be less flexible are possible. Developers who create a masterpiece EIS may become attached to the system and consciously or unconsciously dissuade managers from asking for changes. Managers who are uncertain that the benefits outweigh the initial cost of a masterpiece EIS may not want to spend more on system maintenance and improvements. The time required to create a masterpiece EIS may mean that it is outdated before it is implemented.
While usability and response time are important factors in determining whether executives will use a system, cost and flexibility are paramount. A senior manager will be more accepting of an inexpensive system that provides 20% of the needed information within a month or two than with an expensive system that provides 80% of the needed information after a year of development. The manager may also find that the inexpensive system is easier to change and adapt to the evolving needs of the business. Changing a large system would involve throwing away parts of a substantial investment. Changing the inexpensive system means losing a few weeks of work. As a result, fast, cheap, incremental approaches to developing an EIS increase the chance of success.
Technical Problems
Paradoxically, technical problems are also frequently reported as a significant barrier to EIS success. The most difficult technical problem -- that of integrating data from a wide range of data sources both inside and outside the organization -- is also one of the most critical issues for EIS users. A marketing vice-president, who had spent several hundred thousand dollars on an EIS, attended a final briefing on the system. The technical experts demonstrated the many graphs and charts of sales results, market share and profitability. However, when the vice-president asked for a graph of market share and advertising expense over the past ten years, the system was unable to access historical data. The project was cancelled in that meeting.
The ability to integrate data from many different systems is important because it allows managerial learning that is unavailable in other ways. The president of a manufacturing company can easily get information about sales and manufacturing from the relevant VPs. Unfortunately, the information the president receives will likely be incompatible, and learning about the ways in which sales and manufacturing processes influence each other will not be easy. An EIS will be particularly effective if it can overcome this challenge, allowing executives to learn about business processes that cross organizational boundaries and to compare business results in disparate functions.
Another technical problem that can kill EIS projects is usability. Senior managers simply have the choice to stop using a system if they find it too difficult to learn or use. They have very little time to invest in learning the system, a low tolerance for errors, and initially may have very little incentive to use it. Even if the information in the system is useful, a difficult interface will quickly result in the manager assigning an analyst to manipulate the system and print out the required reports. This is counter-productive because managerial learning is enhanced by the immediacy of the question - answer learning cycle provided by an EIS. If an analyst is interacting with the system, the analyst will acquire more learning than the manager, but will not be in a position to put that learning to its most effective use.
Usability of Executive Information Systems can be enhanced through the use of prototyping and usability evaluation methods. These methods ensure that clear communication occurs between the developers of the system and its users. Managers have an opportunity to interact with systems that closely resemble the functionality of the final system and thus can offer more constructive criticism than they might be able to after reading an abstract specification document. Systems developers also are in a position to listen more openly to criticisms of a system since a prototype is expected to be disposable. Several evaluation protocols are available including observation and monitoring, software logging, experiments and benchmarking, etc. (Preece et al, 1994). The most appropriate methods for EIS design are those with an ethnographic flavour because the experience base of system developers is typically so different from that of their user population (senior executives).
Misalignment Between Objectives & EIS
A final barrier to EIS effectiveness was mentioned earlier in the section on purpose. As noted there, the powerful ability of an EIS to direct organizational attention can be destructive if the system directs attention to the wrong variables. There are many examples of this sort of destructive reporting. Grant, Higgins and Irving (1988) report the account of an employee working under a misaligned reporting system.
I like the challenge of solving customer problems, but they get in the way of hitting my quota. I'd like to get rid of the telephone work. If (the company) thought dealing with customers was important, I'd keep it; but if it's just going to be production that matters, I'd gladly give all the calls to somebody else.
Traditional cost accounting systems are also often misaligned with organizational objectives, and placing these measures in an EIS will continue to draw attention to the wrong things. Cost accounting allocates overhead costs to direct labour hours. In some cases the overhead burden on each direct labour hour is as much as 1000%. A manager operating under this system might decide to sub-contract 100 hours of direct labor at $20 per hour. On the books, this $2,000 saving is accompanied by $20,000 of savings in overhead. If the sub-contractor charges $5,000 for the work, the book savings are $2,000 + $20,000 - $5,000 = $17,000. In reality, however, the overhead costs for an idle machine in a factory do not go down much at all. The sub-contract actually ends up costing $5,000 - $2,000 = $3,000. (Peters, 1987)
Characteristics of Successful EIS Implementations
Find an Appropriate Executive Champion
EIS projects that succeed do so because at least one member of the senior management team agrees to champion the project. The executive champion need not fully understand the technical issues, but must be a person who works closely with all of the senior management team and understands their needs, work styles and their current methods of obtaining organizational information. The champion's commitment must include a willingness to set aside time for reviewing prototypes and implementation plans, influencing and coaching other members of the senior management team, and suggesting modifications and enhancements to the system.
Deliver a Simple Prototype Quickly
Executives judge a new EIS on the basis of how easy it is to use and how relevant the information in the system is to the current strategic issues in the organization. As a result, the best EIS projects begin as a simple prototype, delivered quickly, that provides data about at least one critical issue. If the information delivered is worth the hassle of learning the system, a flurry of requirements will shortly be generated by executives who like what they see, but want more. These requests are the best way to plan an EIS that truly supports the organization, and are more valuable than months of planning by a consultant or analyst.
One caveat concerning the simple prototype approach is that executive requests will quickly scatter to questions of curiosity rather than strategy in an organization where strategic direction and objectives are not clearly defined. A number of methods are available to support executives in defining business objectives and linking them to performance monitors in an EIS. These are discussed further in the section on EIS and Organizational Objectives below.
Involve Your Information Systems Department
In some organizations, the motivation for an EIS project arises in the business units quite apart from the traditional information systems (IS) organization. Consultants may be called in, or managers and analysts in the business units may take the project on without consulting or involving IS. This is a serious mistake. Executive Information Systems rely entirely on the information contained in the systems created and maintained by this department. IS professionals know best what information is available in an organization's systems and how to get it. They must be involved in the team. Involvement in such a project can also be beneficial to IS by giving them a more strategic perspective on how their work influences the organization.
Communicate & Train to Overcome Resistance
A final characteristic of successful EIS implementations is that of communication. Executive Information Systems have the potential to drastically alter the prevailing patterns of organizational communication and thus will typically be met with resistance. Some of this resistance is simply a matter of a lack of knowledge. Training on how to use statistics and performance measures can help. However, resistance can also be rooted in the feelings of fear, insecurity and cynicism experienced by individuals throughout the organization. These attitudes can only be influenced by a strong and vocal executive champion who consistently reinforces the purpose of the system and directs the attention of the executive group away from unproductive and punitive behaviours.
EIS and Organizational Culture
Henry Mintzberg (1972) has argued that impersonal statistical data is irrelevant to managers. John Dearden (1966) argued that the promise of real-time management information systems was a myth and would never be of use to top managers. Grant, Higgins, and Irving (1988) argue that computerized performance monitors undermine trust, reduce autonomy and fail to illuminate the most important issues.
Many of these arguments against EISs have objective merit. Manager's really do value the tangible tidbits of detail they encounter in their daily interactions more highly than abstract numerical reports. Rumours suggest a future, while numbers describe a past. Conversations are rich in detail and continuously probe the reasons for the situation, while statistics are vague approximations of reality. When these vague approximations are used to intimidate or control behavior rather than to guide learning, they really do have a negative impact on the organization.
Yet both of these objections point to a deeper set of problems -- the assumptions, beliefs, values and behaviors that people in the organization hold and use to respond to their environment. Perhaps senior managers find statistical data to be irrelevant because they have found too many errors in previous reports?  Perhaps people in the organization prefer to assign blame rather than discover the true root cause of problems.  The culture of an organization can have a dramatic influence on the adoption and use of an Executive Information System.  The following cultural characteristics will contribute directly to the success or failure of an EIS project.
Learning Vs Blaming
A learning organization is one that seeks first to understand why a problem occurred, and not who is to blame. It is a common and natural response for managers to try to deflect responsibility for a problem on to someone else. An EIS can help to do this by indicating very specifically who failed to meet a statistical target, and by how much. A senior manager, armed with EIS data, can intimidate and blame the appropriate person. The blamed person can respond by questioning the integrity of the system, blaming someone else, or even reacting in frustration by slowing work down further.
In a learning organization, any unusual result is seen as an opportunity to learn more about the business and its processes. Managers who find an unusual statistic explore it further, breaking it down to understand its components and comparing it with other numbers to establish cause and effect relationships. Together as a team, management uses numerical results to focus learning and improve business processes across the organization. An EIS facilitates this approach by allowing instant exploration of a number, its components and its relationship to other numbers.
Continuous Improvement Vs Crisis Management
Some organizations find themselves constantly reacting to crises, with little time for any proactive measures. Others have managed to respond to each individual crisis with an approach that prevents other similar problems in the future. They are engaged in a continual cycle of improving business practices and finding ways to avoid crisis.
Crises in government are frequently caused by questions about organizational performance raised by an auditor, the Minister, or members of the Opposition. An EIS can be helpful in responding to this sort of crisis by providing instant data about the actual facts of the situation. However, this use of the EIS does little to prevent future crises.
An organizational culture in which continual improvement is the norm can use the EIS as an early warning system pointing to issues that have not yet reached the crisis point, but are perhaps the most important areas on which to focus management attention and learning. Organizations with a culture of continuous improvement already have an appetite for the sort of data an EIS can provide, and thus will exhibit less resistance.
Team Work Vs Hierarchy
An EIS has the potential to substantially disrupt an organization that relies upon adherence to a strict chain of command. The EIS provides senior managers with the ability to micro-manage details at the lowest levels in the organization. A senior manger with an EIS report who is surprised at the individual results of a front-line worker might call that person directly to understand why the result is unusual. This could be very threatening for the managers between the senior manager and the front-line worker. An EIS can also provide lower level managers with access to information about peer performance and even the performance of their superiors.
Organizations that are familiar with work teams, matrix managed projects and other forms of interaction outside the chain of command will find an EIS less disruptive. Senior managers in these organizations have learned when micro-management is appropriate and when it is not. Middle managers have learned that most interactions between their superiors and their staff are not threatening to their position. Workers are more comfortable interacting with senior managers when the need arises, and know what their supervisor expects from them in such an interaction.
Data-based Decisions Vs Decisions in a Vacuum
The total quality movement, popular in many organizations today, emphasizes a set of tools referred to as Statistical Process Control (SPC). These analytical tools provide managers and workers with methods of understanding a problem and finding solutions rather than allocating blame and passing the buck. Organizations with training and exposure to SPC and analytical tools will be more open to an EIS than those who are suspicious of numerical measures and the motives of those who use them.
It should be noted that data-based decision making does not deny the role of intuition, experience, or negotiation amongst a group. Rather, it encourages decision-makers to probe the facts of a situation further before coming to a decision. Even if the final decision contradicts the data, chances are that an exploration of the data will help the decision-maker to understand the situation better before a decision is reached. An EIS can help with this decision-making process.
Information Sharing Vs Information Hoarding
Information is power in many organizations, and managers are motivated to hoard information rather than to share it widely. For example, managers may hide information about their own organizational performance, but jump at any chance to see information about performance of their peers.
A properly designed EIS promotes information sharing throughout the organization. Peers have access to information about each other's domain; junior managers have information about how their performance contributes to overall organizational performance. An organization that is comfortable with information sharing will have developed a set of "good manners" for dealing with this broad access to information. These behavioral norms are keys to the success of an EIS.
Specific Objectives Vs Vague Directions
An organization that has experience developing and working toward Specific, Measurable, and Achievable and Consistent (SMAC) objectives will also find an EIS to be less threatening. Many organizations are uncomfortable with specific performance measures and targets because they believe their work to be too specialized or unpredictable. Managers in these organizations tend to adopt vague generalizations and statements of the exceedingly obvious in place of SMAC objectives that actually focus and direct organizational performance. In a few cases, it may actually be true that numerical measures are completely inappropriate for a few aspects of the business. In most cases, managers with this attitude have a poor understanding of the purpose of objective and target-setting exercises. Some business processes are more difficult to measure and set targets for than others. Yet almost all business processes have at least a few characteristics that can be measured and improved through conscientious objective setting. (See the following section on EIS and Organizational Objectives.)
EIS and Organizational Objectives
A number of writers have discovered that one of the major difficulties with EIS implementations is that the information contained in the EIS either does not meet executive requirements, or meets executive requirements, but fails to guide the organization towards its objectives. As discussed earlier, organizations that are comfortable in establishing and working towards Specific, Measurable, Achievable, and Consistent (SMAC) objectives will find it easier to create an EIS that actually drives organizational performance. Yet even these organizations may have difficulty because their stated objectives do not represent all of the things that are important.
Crockett (1992) suggests a four step process for developing EIS information requirements based on a broader understanding of organizational objectives. The steps are: (1) identify critical success factors and stakeholder expectations, (2) document performance measures that monitor the critical success factors and stakeholder expectations, (3) determine reporting formats and frequency, and (4) outline information flows and how information can be used. Crockett begins with stakeholders to ensure that all relevant objectives and critical success factors are reflected in the EIS.
Kaplan and Norton (1992) suggest that goals and measures need to be developed from each of four perspectives: financial, customer, internal business, and innovation and learning. These perspectives help managers to achieve a balance in setting objectives, and presenting them in a unified report exposes the tough tradeoffs in any management system. An EIS built on this basis will not promote productivity while ignoring quality, or customer satisfaction while ignoring cost.
Meyer (1994) raises several questions that should be asked about measurement systems for teams. Four are appropriate for evaluating objectives and measures represented in an EIS. They are:
·         Are all critical organizational outcomes tracked?
·         Are all "out-of-bounds" conditions tracked? (Conditions those are serious enough to trigger a management review.)
·         Are all the critical variables required to reach each outcome tracked?
·         Is there any measure that would not cause the organization to change its behavior?
In summary, proper definition of organizational objectives and measures is a helpful precondition for reducing organizational resistance to an EIS and is the root of effective EIS use. The benefits of an EIS will be fully realized only when it helps to focus management attention on issues of true importance to the organization.
Methodology
Implementation of an effective EIS requires clear consensus on the objectives and measures to be monitored in the system and a plan for obtaining the data on which those measures are based. The sections below outline a methodology for achieving these two results. As noted earlier, successful EIS implementations generally begin with a simple prototype rather than a detailed planning process. For that reason, the proposed planning methodologies are as simple and scope-limited as possible.
EIS Project Team
The process of establishing organizational objectives and measures is intimately linked with the task of locating relevant data in existing computer systems to support those measures. Objectives must be specific and measurable, and data availability is critical to measuring progress against objectives.
Since there is little use in defining measures for which data is not available, it is recommended that an EIS project team including technical staff be established at the outset. This cross-functional team can provide early warning if data is not available to support objectives or if senior manager's expectations for the system are impractical.
A preliminary EIS project team might consist of as few as three people. An EIS Project Leader organizes and directs the project. An Executive Sponsor promotes the project in the organization, contributes senior management requirements on behalf of the senior management team, and reviews project progress regularly. A Technical Leader participates in requirements gathering, reviewing plans, and ensuring technical feasibility of all proposals during EIS definition.
As the focus of the project becomes more technical, the EIS project team may be complemented by additional technical staff who will be directly involved in extracting data from legacy systems and constructing the EIS data repository and user interface.
Establishing Measures & EIS Requirements
Most organizations have a number of high-level objectives and direction statements that help to shape organizational behavior and priorities. In many cases, however, these direction statements have not yet been linked to performance measures and targets. As well, senior managers may have other critical information requirements that would not be reflected in a simple analysis of existing direction statements. Therefore it is essential that EIS requirements be derived directly from interaction with the senior managers who will use the systems. It is also essential that practical measures of progress towards organizational objectives be established during these interactions.
Measures and EIS requirements are best established through a three-stage process. First, the EIS team solicits the input of the most senior executives in the organization in order to establish a broad, top-down perspective on EIS requirements. Second, interviews are conducted with the managers who will be most directly involved in the collection, analysis, and monitoring of data in the system to assess bottom-up requirements. Third, a summary of results and recommendations is presented to senior executives and operational managers in a workshop where final decisions are made.
Interview Format
The focus of the interviews would be to establish all of the measures managers require in the EIS. Questions would include the following:
1.      What are the five most important pieces of information you need to do your job?
2.      What expectations does the Board of Directors have for you?
3.      What results do you think the general public expects you to accomplish?
4.      On what basis would consumers and customers judge your effectiveness?
5.      What expectations do other stakeholders impose on you?
6.      What is it that you have to accomplish in your current position?
Senior Management Workshop
Since considerable variability is expected in the results of these interviews, analysis and synthesis are required to identify recurring themes and important differences of opinion. This information is brought forward to a senior management workshop.
The purpose of the senior management workshop is twofold. First, the workshop will be an opportunity to educate senior management on appropriate use of Executive Information Systems, to address some of the cultural issues raised earlier and to deal directly with resistance to the system. Second, managers at the workshop will be asked to reach agreement on an initial set of measures to be included in the EIS. The education component of the workshop is most effective if integrated with the work of creating measures.
The initial set of measures will be established within a framework derived from the interview process. Three to five categories of measures will be established prior to the workshop, and managers will be asked to select or create three to five technically feasible measures for each category. Each of the proposed measures will be subjected to the questions proposed by Meyer (see EIS and Organizational Objectives above) to determine if they are appropriate.
Technical staff will attend to respond to feasibility questions as they arise, and to improve their understanding of the EIS requirements.
Obtaining Critical Data Linking EIS Measures to Data Sources
Data to support the information requirements of senior managers will likely be dispersed across the organization's information systems and external sources. Some data may not be currently available at all, and collection mechanisms will have to be constructed.
The EIS project team, augmented by technical experts, and working from the requirements established in the senior management workshop will develop a list of required data elements and link them with appropriate data sources. The team will then establish requirements for data extraction from each of these systems and spin off appropriate systems development projects.
EIS Design, Prototyping & Evaluation
After information sources have been established, and projects are underway to permit ongoing extraction of that information, attention will turn to the design of the EIS itself. There are several components to consider.


Hardware
First, an inventory of computers used by executives must be taken to determine what upgrades are necessary and what hardware limitations will be imposed on the EIS design. Included in this inventory will be an assessment of network storage and communication facilities.
Data Repository
The second component is the design of the data repository in which summary data from all sources will be stored. The design of this repository is critical because it must allow managers to easily extract and explore data along numerous dimensions. Standard relational designs may not be sufficient or practical for this application.
EIS Interface Prototype
A third component is the design of the actual EIS interface that senior managers will interact with. Screens and commands must be exceedingly obvious and easy to use so that senior managers can quickly access the benefits of the system without wasting a lot of time learning how to use it. Ease of use can be ensured by developing a prototype system with "sample" data, and watching senior managers as they interact with the prototype. Two to three iterations of prototype redesign and testing with four senior managers would be sufficient to ensure that the system is easy to use.
Advantages of EIS
a.       Easy for upper-level executives to use, extensive computer experience is not required in operations
b.      Provides timely delivery of company summary information
c.       Information that is provided is better understood
d.      Filters data for management
e.       Improves to tracking information
f.       Offers efficiency to decision makers
Disadvantages of EIS
a.       Functions are limited, cannot perform complex calculations
b.      Hard to quantify benefits and to justify implementation of an EIS
c.       Executives may encounter information overload
d.      System may become slow, large, and hard to manage
e.       Difficult to keep current data
f.       May lead to less reliable and insecure data
g.      Small companies may encounter excessive costs for implementation
h.      Highly skilled personnel requirement can not be fulfilled by the small business

Future Scope of EIS
The future of executive info systems will not be bound by mainframe computer systems. This trend allows executives escaping from learning different computer operating systems and substantially decreases the implementation costs for companies. Because utilizing existing software applications lies in this trend, executives will also eliminate the need to learn a new or special language for the EIS package. Future executive information systems will not only provide a system that supports senior executives, but also contain the information needs for middle managers. The future executive information systems will become diverse because of integrating potential new applications and technology into the systems, such as incorporating artificial intelligence (AI) and integrating multimedia characteristics and ISDN technology into an EIS.
DATA WAREHOUSING
The data warehousing market consists of tools, technologies, and methodologies that allow for the construction, usage, management, and maintenance of the hardware and software used for a data warehouse, as well as the actual data itself. Surveys indicate Data Warehousing will be the single largest IT initiative after completion of Y2K efforts. Data warehousing is currently a $28 Billion market (Source: Data Warehousing Institute) and we estimate 20% growth per annum through at least 2002.Two of the pioneers in the field were Ralph Kimball and Bill Inmon. Biographies of these two individuals have been provided, since many of the terms discussed in this paper were coined and concepts defined by them.
Data warehousing is combining data from multiple and usually varied sources into one comprehensive and easily manipulated database. Common accessing systems of data warehousing include queries, analysis and reporting. Because data warehousing creates one database in the end, the number of sources can be anything you want it to be, provided that the system can handle the volume, of course. The final result, however, is homogeneous data, which can be more easily manipulated.
Data warehousing is commonly used by companies to analyze trends over time. In other words, companies may very well use data warehousing to view day-to-day operations, but its primary function is facilitating strategic planning resulting from long-term data overviews. From such overviews, business models, forecasts, and other reports and projections can be made. Routinely, because the data stored in data warehouses is intended to provide more overview-like reporting, the data is read-only. If you want to update the data stored via data warehousing, you'll need to build a new query when you're done.
This is not to say that data warehousing involves data that is never updated. On the contrary, the data stored in data warehouses is updated all the time. It's the reporting and the analysis that take more of a long-term view.
Data warehousing is not the be-all and end-all for storing all of a company's data. Rather, data warehousing is used to house the necessary data for specific analysis. More comprehensive data storage requires different capacities that are more static and less easily manipulated than those used for data warehousing.
Data warehousing is typically used by larger companies analyzing larger sets of data for enterprise purposes. Smaller companies wishing to analyze just one subject, for example, usually access data marts, which are much more specific and targeted in their storage and reporting. Data warehousing often includes smaller amounts of data grouped into data marts. In this way, a larger company might have at its disposal both data warehousing and data marts, allowing users to choose the source and functionality depending on current needs.
In order to clear up some of the confusion that is rampant in the market, here are some definitions:
Definition of Data Warehouse:
The term Data Warehouse was coined by Bill Inmon in 1990, which he defined in the following way: "A warehouse is a subject-oriented, integrated, time-variant and non-volatile collection of data in support of management's decision making process". He defined the terms in the sentence as follows:
Subject Oriented
Data that gives information about a particular subject instead of about a company's ongoing operations.
Integrated
Data that is gathered into the data warehouse from a variety of sources and merged into a coherent whole.
Time-variant
All data in the data warehouse is identified with a particular time period.
Non-volatile
Data is stable in a data warehouse. More data is added but data is never removed. This enables management to gain a consistent picture of the business.

 (Source: "What is a Data Warehouse?" W.H. Inmon, Prism, Volume 1, Number 1, 1995).
Data warehousing is essentially what you need to do in order to create a data warehouse, and what you do with it. It is the process of creating, populating, and then querying a data warehouse and can involve a number of discrete technologies such as:
Source System Identification
Source System Identification: In order to build the data warehouse, the appropriate data must be located. Typically, this will involve both the current OLTP (On-Line Transaction Processing) system where the "day-to-day" information about the business resides, and historical data for prior periods, which may be contained in some form of "legacy" system. Often these legacy systems are not relational databases, so much effort is required to extract the appropriate data.
Data Warehouse Design and Creation
This describes the process of designing the warehouse, with care taken to ensure that the design supports the types of queries the warehouse will be used for. This is an involved effort that requires both an understanding of the database schema to be created, and a great deal of interaction with the user community. The design is often an iterative process and it must be modified a number of times before the model can be stabilized. Great care must be taken at this stage, because once the model is populated with large amounts of data, some of which may be very difficult to recreate, the model can not easily be changed.
Data Acquisition
This is the process of moving company data from the source systems into the warehouse. It is often the most time-consuming and costly effort in the data warehousing project, and is performed with software products known as ETL (Extract/Transform/Load) tools. There are currently over 50 ETL tools on the market. The data acquisition phase can cost millions of dollars and take months or even years to complete. Data acquisition is then an ongoing, scheduled process, which is executed to keep the warehouse current to a pre-determined period in time, (i.e. the warehouse is refreshed monthly).
Changed Data Capture
The periodic update of the warehouse from the transactional system(s) is complicated by the difficulty of identifying which records in the source have changed since the last update. This effort is referred to as "changed data capture". Changed data capture is a field of endeavor in itself, and many products are on the market to address it. Some of the technologies that are used in this area are Replication servers, Publish/Subscribe, Triggers and Stored Procedures, and Database Log Analysis.
Data Cleansing
This is typically performed in conjunction with data acquisition (it can be part of the "T" in "ETL"). A data warehouse that contains incorrect data is not only useless, but also very dangerous. The whole idea behind a data warehouse is to enable decision-making. If a high level decision is made based on incorrect data in the warehouse, the company could suffer severe consequences, or even complete failure. Data cleansing is a complicated process that validates and, if necessary, corrects the data before it is inserted into the warehouse. For example, the company could have three "Customer Name" entries in its various source systems, one entered as "IBM", one as "I.B.M.", and one as "International Business Machines". Obviously, these are all the same customer. Someone in the organization must make a decision as to which is correct, and then the data cleansing tool will change the others to match the rule. This process is also referred to as "data scrubbing" or "data quality assurance". It can be an extremely complex process, especially if some of the warehouse inputs are from older mainframe file systems (commonly referred to as "flat files" or "sequential files").
Data Aggregation
This process is often performed during the "T" phase of ETL, if it is performed at all. Data warehouses can be designed to store data at the detail level (each individual transaction), at some aggregate level (summary data), or a combination of both. The advantage of summarized data is that typical queries against the warehouse run faster. The disadvantage is that information, which may be needed to answer a query, is lost during aggregation. The tradeoff must be carefully weighed, because the decision can not be undone without rebuilding and repopulating the warehouse. The safest decision is to build the warehouse with a high level of detail, but the cost in storage can be extreme.
Now that the warehouse has been built and populated, it becomes possible to extract meaningful information from it that will provide a competitive advantage and a return on investment. This is done with tools that fall within the general rubric of "Business Intelligence".
Business Intelligence (BI)
A very broad field indeed, it contains technologies such as Decision Support Systems (DSS), Executive Information Systems (EIS), On-Line Analytical Processing (OLAP), Relational OLAP (ROLAP), Multi-Dimensional OLAP (MOLAP), Hybrid OLAP (HOLAP, a combination of MOLAP and ROLAP), and more. BI can be broken down into four broad fields:
Multi-dimensional Analysis Tools
Tools that allow the user to look at the data from a number of different "angles" are called Multi-dimensional Analysis tools. These tools often use a multi-dimensional database referred to as a "cube".
Query tools
Tools that allow the user to issue SQL (Structured Query Language) queries against the warehouse and get a result set back.
Data Mining Tools
Tool that automatically searches for patterns in data is called data mining Tools. These tools are usually driven by complex statistical formulas. The easiest way to distinguish data mining from the various forms of OLAP is that OLAP can only answer questions you know to ask, data mining answers questions you didn't necessarily know to ask.
Data Visualization Tools
Tools that show graphical representations of data, including complex three-dimensional data pictures is called Data Visualization tools. The theory is that the user can "see" trends more effectively in this manner than when looking at complex statistical graphs. Some vendors are making progress in this area using the Virtual Reality Modeling Language (VRML).
Metadata Management
Throughout the entire process of identifying, acquiring, and querying the data, metadata management takes place. Metadata is defined as "data about data". An example is a column in a table. The data type (for instance a string or integer) of the column is one piece of metadata. The name of the column is another. The actual value in the column for a particular row is not metadata - it is data. Metadata is stored in a Metadata Repository and provides extremely useful information to all of the tools mentioned previously. Metadata management has developed into an exacting science that can provide huge returns to an organization. It can assist companies in analyzing the impact of changes to database tables, tracking owners of individual data elements ("data stewards"), and much more. It is also required to build the warehouse, since the ETL tool needs to know the metadata attributes of the sources and targets in order to "map" the data properly. The BI tools need the metadata for similar reasons.
Data Warehousing is a complex field, with many vendors vying for market awareness. The complexity of the technology and the interactions between the various tools, and the high price points for the products require companies to perform careful technology evaluation before embarking on a warehousing project. However, the potential for enormous returns on investment and competitive advantage make data warehousing difficult to ignore
History of Data warehousing
Data Warehouses are a distinct type of computer database that were first developed during the late 1980s and early 1990s. They were developed to meet a growing demand for management information and analysis that could not be met by operational systems. Operational systems were unable to meet this need for a range of reasons:
a)      The processing load of reporting reduced the response time of the operational systems
b)      The database designs of operational systems were not optimized for information analysis and reporting
c)      Most organizations had more than one operational system, so company-wide reporting could not be supported from a single system
d)     Development of reports in operational systems often required writing specific computer programs which was slow and expensive
As a result, separate computer databases began to be built that were specifically designed to support management information and analysis purposes. These data warehouses were able to bring in data from a range of different data sources, such as mainframe computers, minicomputers, as well as personal computers and office automation software such as spreadsheet, and integrate this information in a single place. This capability, coupled with user-friendly reporting tools and freedom from operational impacts, has led to a growth of this type of computer system.
As technology improved (lower cost for more performance) and user requirements increased (faster data load cycle times and more features), data warehouses have evolved through several fundamental stages:
Off line Operational Databases 
Data warehouses in this initial stage are developed by simply copying the database of an operational system to an off-line server where the processing load of reporting does not impact on the operational system's performance.
Off line Data Warehouse 
Data warehouses in this stage of evolution are updated on a regular time cycle (usually daily, weekly or monthly) from the operational systems and the data is stored in an integrated reporting-oriented data structure.


Real Time Data Warehouse 
Data warehouses at this stage are updated on a transaction or event basis, every time an operational system performs a transaction (e.g. an order or a delivery or a booking etc.)
Integrated Data Warehouse 
Data warehouses at this stage are used to generate activity or transactions that are passed back into the operational systems for use in the daily activity of the organization.
The Data Warehouse Architecture
The data warehouse architecture consists of various interconnected elements which are:
 1) Operational and external database layer: the source data for the data warehouse.
2) Informational access layer: the tools, the end user access to extract and analyze the data.
3) Data Access Layer: the interface between the operational and informational access layer.
4) Metadata Layer: The data directory or repository of metadata information.
The concept of "data warehousing" dates back at least to the mid-1980s, and possibly earlier. In essence, it was intended to provide an architectural model for the flow of data from operational systems to decision support environments. It attempted to address the various problems associated with this flow, and the high costs associated with it. In the absence of such an architecture, there usually existed an enormous amount of redundancy in the delivery of management information. In larger corporations it was typical for multiple decision support projects to operate independently, each serving different users but often requiring much of the same data. The process of gathering, cleaning and integrating data from various sources, often legacy systems, was typically replicated for each project. Moreover, legacy systems were frequently being revisited as new requirements emerged, each requiring a subtly different view of the legacy data.
Based on analogies with real-life warehouses, data warehouses were intended as large-scale collection/storage/staging areas for corporate data. From here data could be distributed to "retail stores" or "data marts" which were tailored for access by decision support users (or "consumers"). While the data warehouse was designed to manage the bulk supply of data from its suppliers (e.g. operational systems), and to handle the organization and storage of this data, the "retail stores" or "data marts" could be focused on packaging and presenting selections of the data to end-users, to meet specific management information needs.
Somewhere along the way this analogy and architectural vision was lost, as some vendors and industry speakers redefined the data warehouse as simply a management reporting database. This is a subtle but important deviation from the original vision of the data warehouse as the hub of a management information architecture, where the decision support systems were actually the data marts or "retail stores".
Advantages
There are many advantages to using a data warehouse, some of them are:
        i.            Data warehouses enhance end-user access to a wide variety of data.
      ii.            Decision support system users can obtain specified trend reports, e.g. the item with the most sales in a particular area within the last two years.
    iii.            Data warehouses can be a significant enabler of commercial business applications, particularly customer relationship management (CRM) systems.
Limitations
a)      Extracting, transforming and loading data consumes a lot of time and computational resources.
b)      Data warehousing project scope must be actively managed to deliver a release of defined content and value.
c)      Compatibility problems with systems already in place.
d)     Security could develop into a serious issue, especially if the data warehouse is web accessible.
e)      Data Storage design controversy warrants careful consideration and perhaps prototyping of the data warehouse solution for each project's environments.
DATA MINING
Overview
Generally, data mining (sometimes called data or knowledge discovery) is the process of analyzing data from different perspectives and summarizing it into useful information - information that can be used to increase revenue, cuts costs, or both. Data mining software is one of a number of analytical tools for analyzing data. It allows users to analyze data from many different dimensions or angles, categorize it, and summarize the relationships identified. Technically, data mining is the process of finding correlations or patterns among dozens of fields in large relational databases.
a)      Data mining parameters include:
b)      Association - looking for patterns where one event is connected to another event
c)      Sequence or path analysis - looking for patterns where one event leads to another later event
d)     Classification - looking for new patterns (May result in a change in the way the data is organized but that's ok)
e)      Clustering - finding and visually documenting groups of facts not previously known
f)       Forecasting - discovering patterns in data that can lead to reasonable predictions about the future (This area of data mining is known as predictive analytics.)
Data mining techniques are used in a many research areas, including mathematics, cybernetics, and genetics. Web mining, a type of data mining used in customer relationship management (CRM), takes advantage of the huge amount of information gathered by a Web site to look for patterns in user behavior. A data miner is a program that collects such information, often without the user's knowledge, as spyware.
Data mining is a class of database applications that look for hidden patterns in a group of data that can be used to predict future behavior. For example, data mining software can help retail companies find customers with common interests. The term is commonly misused to describe software that presents data in new ways. True data mining software doesn't just change the presentation, but actually discovers previously unknown relationships among the data.
Continuous Innovation
Although data mining is a relatively new term, the technology is not. Companies have used powerful computers to sift through volumes of supermarket scanner data and analyze market research reports for years. However, continuous innovations in computer processing power, disk storage, and statistical software are dramatically increasing the accuracy of analysis while driving down the cost.
Example
For example, one Midwest grocery chain used the data mining capacity of Oracle software to analyze local buying patterns. They discovered that when men bought diapers on Thursdays and Saturdays, they also tended to buy beer. Further analysis showed that these shoppers typically did their weekly grocery shopping on Saturdays. On Thursdays, however, they only bought a few items. The retailer concluded that they purchased the beer to have it available for the upcoming weekend. The grocery chain could use this newly discovered information in various ways to increase revenue. For example, they could move the beer display closer to the diaper display. And, they could make sure beer and diapers were sold at full price on Thursdays.
Before taking data mining in detail lets understand some of these basic terms again:
Data, Information, and Knowledge
Data
Data are any facts, numbers, or text that can be processed by a computer. Today, organizations are accumulating vast and growing amounts of data in different formats and different databases. This includes:
• Operational or transactional data such as, sales, cost, inventory, payroll, and accounting
• Non-operational data, such as industry sales, forecast data, and macro economic data
• Meta data - data about the data itself, such as logical database design or data dictionary definitions
Information
The patterns, associations, or relationships among all this data can provide information. For example, analysis of retail point of sale transaction data can yield information on which products are selling and when.
Knowledge
Information can be converted into knowledge about historical patterns and future trends. For example, summary information on retail supermarket sales can be analyzed in light of promotional efforts to provide knowledge of consumer buying behavior. Thus, a manufacturer or retailer could determine which items are most susceptible to promotional efforts.
Data Warehouses
Dramatic advances in data capture, processing power, data transmission, and storage capabilities are enabling organizations to integrate their various databases into data warehouses. Data warehousing is defined as a process of centralized data management and retrieval. Data warehousing, like data mining, is a relatively new term although the concept itself has been around for years. Data warehousing represents an ideal vision of maintaining a central repository of all organizational data. Centralization of data is needed to maximize user access and analysis. Dramatic technological advances are making this vision a reality for many companies. And, equally dramatic advances in data analysis software are allowing users to access this data freely. The data analysis software is what supports data mining.
Application of Data mining
Data mining is primarily used today by companies with a strong consumer focus - retail, financial, communication, and marketing organizations. It enables these companies to determine relationships among "internal" factors such as price, product positioning, or staff skills, and "external" factors such as economic indicators, competition, and customer demographics. And, it enables them to determine the impact on sales, customer satisfaction, and corporate profits. Finally, it enables them to "drill down" into summary information to view detail transactional data.
With data mining, a retailer could use point-of-sale records of customer purchases to send targeted promotions based on an individual's purchase history. By mining demographic data from comment or warranty cards, the retailer could develop products and promotions to appeal to specific customer segments.
For example, Blockbuster Entertainment mines its video rental history database to recommend rentals to individual customers. American Express can suggest products to its cardholders based on analysis of their monthly expenditures.
WalMart is pioneering massive data mining to transform its supplier relationships. WalMart captures point-of-sale transactions from over 2,900 stores in 6 countries and continuously transmits this data to its massive 7.5 terabyte Teradata data warehouse. WalMart allows more than 3,500 suppliers, to access data on their products and perform data analyses. These suppliers use this data to identify customer buying patterns at the store display level. They use this information to manage local store inventory and identify new merchandising opportunities. In 1995, WalMart computers processed over 1 million complex data queries.
The National Basketball Association (NBA) is exploring a data mining application that can be used in conjunction with image recordings of basketball games. The Advanced Scout software analyzes the movements of players to help coaches orchestrate plays and strategies. For example, an analysis of the play-by-play sheet of the game played between the New York Knicks and the Cleveland Cavaliers on January 6, 1995 reveals that when Mark Price played the Guard position, John Williams attempted four jump shots and made each one! Advanced Scout not only finds this pattern, but explains that it is interesting because it differs considerably from the average shooting percentage of 49.30% for the Cavaliers during that game.
By using the NBA universal clock, a coach can automatically bring up the video clips showing each of the jump shots attempted by Williams with Price on the floor, without needing to comb through hours of video footage. Those clips show a very successful pick-and-roll play in which Price draws the Knick's defense and then finds Williams for an open jump shot.
Process of data mining
While large-scale information technology has been evolving separate transaction and analytical systems, data mining provides the link between the two. Data mining software analyzes relationships and patterns in stored transaction data based on open-ended user queries. Several types of analytical software are available: statistical, machine learning, and neural networks. Generally, any of four types of relationships are sought:
Classes: Stored data is used to locate data in predetermined groups. For example, a restaurant chain could mine customer purchase data to determine when customers visit and what they typically order. This information could be used to increase traffic by having daily specials.
Clusters: Data items are grouped according to logical relationships or consumer preferences. For example, data can be mined to identify market segments or consumer affinities.
Associations: Data can be mined to identify associations. The beer-diaper example is an example of associative mining.
Sequential patterns: Data is mined to anticipate behavior patterns and trends. For example, an outdoor equipment retailer could predict the likelihood of a backpack being purchased based on a consumer's purchase of sleeping bags and hiking shoes.
Data mining consists of five major elements:
1.      Extract, transform, and load transaction data onto the data warehouse system.
2.      Store and manage the data in a multidimensional database system.
3.      Provide data access to business analysts and information technology professionals.
4.      Analyze the data by application software.
5.      Present the data in a useful format, such as a graph or table.
Different levels of analysis are available:
a)      Artificial neural networks: Non-l   inear predictive models that learn through training and resemble biological neural networks in structure.
b)      Genetic algorithms: Optimization techniques that use processes such as genetic combination, mutation, and natural selection in a design based on the concepts of natural evolution.
c)      Decision trees: Tree-shaped structures that represent sets of decisions. These decisions generate rules for the classification of a dataset. Specific decision tree methods include Classification and Regression Trees (CART) and Chi Square Automatic Interaction Detection (CHAID) . CART and CHAID are decision tree techniques used for classification of a dataset. They provide a set of rules that you can apply to a new (unclassified) dataset to predict which records will have a given outcome. CART segments a dataset by creating 2-way splits while CHAID segments using chi square tests to create multi-way splits. CART typically requires less data preparation than CHAID.
d)     Nearest neighbor method: A technique that classifies each record in a dataset based on a combination of the classes of the k record(s) most similar to it in a historical dataset (where k 1). Sometimes called the k-nearest neighbor technique.
e)      Rule induction: The extraction of useful if-then rules from data based on statistical significance.
f)       Data visualization: The visual interpretation of complex relationships in multidimensional data. Graphics tools are used to illustrate data relationships.
Technological infrastructure required for Data Mining
Today, data mining applications are available on all size systems for mainframe, client/server, and PC platforms. System prices range from several thousand dollars for the smallest applications up to $1 million a terabyte for the largest. Enterprise-wide applications generally range in size from 10 gigabytes to over 11 terabytes. NCR has the capacity to deliver applications exceeding 100 terabytes. There are two critical technological drivers:
Size of the database: the more data being processed and maintained, the more powerful the system required.
Query complexity: the more complex the queries and the greater the number of queries being processed, the more powerful the system required.
Relational database storage and management technology is adequate for many data mining applications less than 50 gigabytes. However, this infrastructure needs to be significantly enhanced to support larger applications. Some vendors have added extensive indexing capabilities to improve query performance. Others use new hardware architectures such as Massively Parallel Processors (MPP) to achieve order-of-magnitude improvements in query time. For example, MPP systems from NCR link hundreds of high-speed Pentium processors to achieve performance levels exceeding those of the largest supercomputers.
Applications of Data Mining
Data mining has been cited as the method by which the U.S. Army unit Able Danger supposedly had identified the September 11, 2001 attacks leader, Mohamed Atta, and three other 9/11 hijackers as possible members of an al Qaeda cell operating in the U.S. more than a year before the attack
Data Mining is most frequently used for Customer Relationship Management applications. Common goals are to predict which people are most likely to: a) Be Acquired b) Be Cross-Sold or Up-Sold c) Leave \ Churn d) Be Retained, Saved, or Won back
These applications can contribute significantly to the bottom line. Rather than contacting a prospect or customer through a call center or sending mail, only prospects that are predicted to have a high likelihood of responding to an offer are contacted.
More sophisticated methods may be used to optimize across campaigns so that we can predict which channel and which offer an individual is most likely to respond to - across all potential offers.
Finally, in cases where many people will take an action without an offer, uplift modeling can be used to determine which people will have the greatest increase in responding if given an offer.
Business employing data mining quickly see a return on investment, but also they recognize that the number of predictive models can quickly become very large. Rather than 1 model to predict which customers will churn, we could build a separate model for each region and customer type. Then instead of sending an offer to all people that are likely to churn, we may only want to send offers to customers that will likely take to offer. And finally, we may also want to determine which customers are going to be profitable over a window of time and only send the offers to those that are likely to be profitable. In order to maintain this quantity of models, they need to 1) Manage model versions 2) Move to "Automated Data Mining."
Another example of data mining, often called the Market Basket Analysis, relates to its use in retail sales. If a clothing store records the purchases of customers, a data mining system could identify those customers who favour silk shirts over cotton ones. Although some explanations of relationships may be difficult, taking advantage of it is easier. The example deals with association rules within transaction-based data. Not all data are transaction based and logical or inexact rules may also be present within a database. In a manufacturing application, an inexact rule may state that 73% of products which have a specific defect or problem, will develop a secondary problem within the next 6 months.
OLAP
OLAP stands for On-Line Analytical Processing. The first attempt to provide a definition to OLAP was by Dr. Codd, who proposed 12 rules for OLAP. Later, it was discovered that this particular white paper was sponsored by one of the OLAP tool vendors, thus causing it to lose objectivity. The OLAP Report has proposed the FASMI test, Fast Analysis of Shared Multidimensional Information. For a more detailed description of both Dr. Codd's rules and the FASMI test, please visit The OLAP Report.
For people on the business side, the key feature out of the above list is "Multidimensional." In other words, the ability to analyze metrics in different dimensions such as time, geography, gender, product, etc. For example, sales for the company is up. What region is most responsible for this increase? Which store in this region is most responsible for the increase? What particular product category or categories contributed the most to the increase? Answering these types of questions in order means that you are performing an OLAP analysis.
Depending on the underlying technology used, OLAP can be braodly divided into two different camps: MOLAP and ROLAP.
In the OLAP world, there are mainly two different types: Multidimensional OLAP (MOLAP) and Relational OLAP (ROLAP). Hybrid OLAP (HOLAP) refers to technologies that combine MOLAP and ROLAP.
MOLAP
This is the more traditional way of OLAP analysis. In MOLAP, data is stored in a multidimensional cube. The storage is not in the relational database, but in proprietary formats.
Advantages:
a)      Excellent performance: MOLAP cubes are built for fast data retrieval, and is optimal for slicing and dicing operations.
b)      Can perform complex calculations: All calculations have been pre-generated when the cube is created. Hence, complex calculations are not only doable, but they return quickly.
Disadvantages:
a)      Limited in the amount of data it can handle: Because all calculations are performed when the cube is built, it is not possible to include a large amount of data in the cube itself. This is not to say that the data in the cube cannot be derived from a large amount of data. Indeed, this is possible. But in this case, only summary-level information will be included in the cube itself.
b)      Requires additional investment: Cube technology are often proprietary and do not already exist in the organization. Therefore, to adopt MOLAP technology, chances are additional investments in human and capital resources are needed.



ROLAP
This methodology relies on manipulating the data stored in the relational database to give the appearance of traditional OLAP's slicing and dicing functionality. In essence, each action of slicing and dicing is equivalent to adding a "WHERE" clause in the SQL statement.
Advantages:
a)      Can handle large amounts of data: The data size limitation of ROLAP technology is the limitation on data size of the underlying relational database. In other words, ROLAP itself places no limitation on data amount.
b)      Can leverage functionalities inherent in the relational database: Often, relational database already comes with a host of functionalities. ROLAP technologies, since they sit on top of the relational database, can therefore leverage these functionalities.
Disadvantages:
a)      Performance can be slow: Because each ROLAP report is essentially a SQL query (or multiple SQL queries) in the relational database, the query time can be long if the underlying data size is large.
b)      Limited by SQL functionalities: Because ROLAP technology mainly relies on generating SQL statements to query the relational database, and SQL statements do not fit all needs (for example, it is difficult to perform complex calculations using SQL), ROLAP technologies are therefore traditionally limited by what SQL can do. ROLAP vendors have mitigated this risk by building into the tool out-of-the-box complex functions as well as the ability to allow users to define their own functions.
HOLAP
HOLAP technologies attempt to combine the advantages of MOLAP and ROLAP. For summary-type information, HOLAP leverages cube technology for faster performance. When detail information is needed, HOLAP can "drill through" from the cube into the underlying relational data.
Questions / Answers
  1. What is Business Process Reengineering? Explain the Role of information technology & Impact of BPR on organizational performance
  2. List different Tools to support BPR & Benefits to Business organization
  3. Explain the Meaning of 'Management Information Systems (MIS) & different Risks Associated With MIS
  4. What is Decision Support System (DSS) and Explain few of its applications
  5. Explain the different Taxonomies of DSS
  6. Explain the Architecture of DSS and Characteristics & Capabilities of DSS
  7. Explain the Meaning & scope of Executive Information System
  8. What are the Characteristics of Successful EIS Implementations?
  9. Compare Information Sharing vs Information Hoarding
  10. Explain the EIS Design, Prototyping & Evaluation
  11. What are the Advantages and disadvantages of EIS
  12. Explain the meaning Data warehousing and its applications
  13. Explain different Multi-dimensional Analysis Tools OLAP, MOLAP, HOLAP with their advantages and disadvantages