Enterprise Modeling for Strategic Support

61-04-62 Enterprise Modeling for Strategic Support Michael E. Whitman Michael L. Gibson SUCCESSFUL STRATEGIC BUSINESS ENGINEERING, whether a reactiv...
Author: Piers Hampton
1 downloads 0 Views 467KB Size

Enterprise Modeling for Strategic Support Michael E. Whitman Michael L. Gibson

SUCCESSFUL STRATEGIC BUSINESS ENGINEERING, whether a reactive effort to gain competitive advantage or a proactive effort to maintain and improve performance, depends on an organization’s ability to accurately and methodically analyze its internal and external environments, people, processes, organizational structure, information uses, and technology. Enterprise modeling (EM) greatly enhances strategic business engineering by providing a structured, diagrammatic framework for depicting the myriad interconnected and changing components addressed in large-scale change. Its representative models of the organization serve as baseline against which all subsequent change is measured and provide a basis for strategic planning. Using EM as a forecasting tool fosters a more effective and efficient planning process that dramatically increases the probabilities of success. IS professionals are uniquely situated to apply enterprise modeling technology to overall business change. Enterprise modeling originated in data processing departments as a software development tool and plays a critical role in computeraided systems engineering, allowing systems designers to map current and proposed information systems as a predecessor to development. IS professionals have direct access to the organizational information and the discipline necessary to support information flow. It is, therefore, a logical extension for the IS function to aid business engineering strategists achieve the revisions inherent in strategic business engineering. ENTERPRISE MODELING Enterprise modeling has been described by E. Aranow as “a combination of diagrammatic, tabular, or other visual structures, which represent the key components of the business that need to be understood.” More simply put, enterprise modeling consists of representing complex objects in easy-tounderstanding diagram. Complex modeling tools facilitate EM, but the basis for understanding a large, complex organization relates to the ability

to represent it in a series of elementary graphs that allow modelers to view components individually without losing the contextual overview of the entire organization. Enterprise modeling is referred to as one of many qualitative models that can be used to represent quantitative measures of particular facets of an organization in a higher level of abstraction the represents the organization in a more holistic manner. Qualitative modeling allows the modelers to view the organization synergistic existence as a whole entity vs. the sum of its parts, in supporting the organizational mission, objectives, and functions. This systems view provides critical analysis of the organization as a preparation for strategic business engineering, as organizational modelers must encapsulate the interaction of the components of the organization depicted as part of the conceptual view of the organization. The enterprise model itself can be decomposed into two functional models, a business model and a systems, or information, model (Exhibit 1). The business model depicts business functions, events, and activities, and organizational structures, geographic locations, and interrelationships. The information systems model comprises the information needed, produced, and used by business functions. Enterprise Modeling Constructs Business models are concerned with what processes are needed to run a selected business area, how processes interact, and what data are needed. Systems models present a high-level overview on the enterpriseits functions, data and information needs. Whereas the business models represents a view of the entire business, the information systems model represents that portion of the business targeted for computer support. Modeling an organization begins at the strategic or corporate level and progresses through decomposition of corporate-level objects, activities, and associations down to the tactical and operational levels. Objects (business) are those things internal and external to the business for which it is important that the business retain information. Activities (enterprise) represent what the enterprise does in terms of major functions, processes, and procedures. Associations are relationships, dependencies, shared characteristics, or other connections between organizational objects and activities. As shown in Exhibit 2, a top-down, comprehensive approach to modeling the business divides the conceptual (i.e., strategic objects, activities, and associations into greater and greater detail. In the intermediate levels, these objects, activities, and associations are logical (i.e., functional), at the lowest level they are physical (i.e., operational). This process spans the business life cycle, continuing down through the layers of organization

Exhibit 1.

Functional models of the enterprise model.

until they are at a primitive level and need no further decomposition to be clearly understood. At this lowest level, the objects, activities, and associations inform and are used by employees (who are also some of the business objects) in conducting the daily activities of the business. The concept of organizational analysis resembles the business evaluation techniques presented in most current management literature. Just as a formalized structure for collecting and representing environmental scanning data; in organizational analysis, modeling methodologists responsible for modeling the enterprise must use a structured framework to facilitate accurate and precise analysis. The resulting models should accurately represent what the business is, does, and uses, and with whom it interacts. A CASE tool that has high degrees of graphic and text (dictionary and repository) support often helps the modeler show how things are related (associated). A good CASE tool should have some type of intelligence. Modeling with case tools imposes formality on all phases of the methodology and provides repositories and extensive capabilities for cross-checking and storing data.

Exhibit 2.

Enterprise modeling paradigm.

The Enterprise Modeling Methodologist As the CIO of a large oil company has said, “The business line managers within the organization must be the individuals responsible for any change effort, and for reengineering specifically.” For any intervention strategy to succeed, the managers and employees within an organization targeted for strategic business engineering must become an integral part of the effort and continually be informed and educated regarding the process. In fact, for a successful strategic business engineering (SBE) effort, managers and employees must be the individuals actually performing the change, empowered by their supervisor to use their personal innovation and ingenuity to achieve desired improvements. The complexity of EM, however, necessitates that a methodologist trained in EM techniques instruct managers and employees in the EM process, if not to actually conduct the modeling. Using a methodologist does not detract power or responsibility from the business personnel for the end project; it provides them with an experienced knowledge base from which to draw ideas and suggestions on overall design improvements.

Exhibit 3.

Contextual paradigm of strategic business engineering.

Enterprise Modeling in SBE As depicted in a contextual SBE model (Exhibit 3), enterprise modeling plays a significant role in supporting the various processes of a typical engineering effort. The model begins with the strategic planner’s mental model of the organization: a conceptual image of what the organization is, how it operates, and how it interacts with its environment. The mental models of executives are ever-striving attempts to match the physical with the logical that drives the organizational restructuring and change management evident in today’s organization. • Environmental scanning. Selectively retrieving information from the organization’s internal and external environments to support the development of an organization’s strategy. • Enterprise modeling. Accurately reflecting the current processes and information usage within an organization and mapping out the desired end result of the SBE effort. • Evaluation and reevaluation of the enterprise model. Developing a blueprint of the organization as it currently exists to allow strategic planners

to compare the model of what the organization is to their conceptual models. • Blueprinting the new and improved organization. Creating a revised organizational design that models what should be instead of what currently exists. The final stages of the SBE paradigm involve implementing the revised enterprise model and continuously monitoring and revising the previous processes. The central controlling factor of the entire SBE process embodies the structured change management principles that lie in the center of the model. Current practices in organizational development and organizational behavior theory are extremely useful in SBE. In fact, some projects undertaken by IS professionals fail because due attention is not given to the change intervention strategies proposed by organizational development professionals. Once the first iteration of the engineering process is completed, the next one begins. As an organization becomes committed to the kinds or revolutionary changes and improvements resulting from successful SBE, it must continue to practice the constructs and lessons learned, or else again begin to stagnate and fall behind in the competitive race. ENTERPRISE MODELING, REENGINEERING, AND STRATEGIC PLANNING The true value of an enterprise model lies in its ability to support a conceptual understanding of the present situation of an enterprise and to aid in mapping out a strtegy for the future developments. Enterprise modeling is thus a dynamic strategic tool that allows strategic planner to assess the organization’s position before establishing the means to accomplish organizational goals and objectives. A strategic planning life cycle that incorporates enterprise modeling and strategic business engineering encompasses the following several steps: Goal Development. Directly related to the business profile analysis is the identification and evaluation of business opportunities and threats present in the company’s external environments. These opportunities and threats help develop strategic goals and objectives. Business engineering, as a logical extension of the change process, should be a cornerstone for strategy development. The enterprise models created should be used to supplement the goals developed within this process. Strategy Formulation. The second step in a typical strategic planning life cycle is the development of specific strategies for the organization, as well as a single context-level strategy that addresses the focus and mission of the organization. As strategy emerges, a key component is the continuous

process of evaluation and engineering. Again, enterprise modeling provides a useful tool in evaluating the organization to determine the feasibility of the various alternative strategies. Strategy Implementation. The next phase of the strategy life cycle involves implementing the developed strategy, focusing on achieving results, and relying heavily on change management, organizational behavior analysis, and performance measures. SBE during implementation concentrates on organizational structure, relationships, and processes, and on the behavior of the firm’s top leadership. Modeling the structures and associations within the organization coupled with an aggressive implementation strategy provides a fundamental blueprint for a successful implementation. Strategy Assessment. During the implementation stage, the simultaneous evaluation of strategy development and strategy implementation directly affect final strategies. The engineering phase of implementation and reorganization is ideally suited to support the integration of the strategy into the business environment. As the strategy is implemented, the engineering constructs are regained in the process, creating an atmosphere conducive to the ongoing change that characterizes reengineering and strategy implementation. Strategy Control and Maintenance. Success in strategic planning is a relative concept. Reengineering does not ensure the success or failure of a strategy; rather it serves to report the state of the organization as it responds to the planning process. Strategy maintenance is a continuous looping process whereby the organization continues existing strategies and develops new ones throughout the strategy life cycle. The continuing analysis, design, and implementation steps in enterprise modeling and engineering facilitate strategy maintenance. The relationship between SBE and strategic planning is symbiotic-the constructs behind each support the other.

The following example illustrates the application of enterprise modeling. Enterprise Modeling at State University State University (a pseudonym) is a major public university in the southeast with an enrollment of approximately 25,000 students. As a land grant university, State pursues its charter missions of research, instruction, and extension. The university currently manages it financial operations through a single functional division, known as the Business and Finance Division. The department within the business office primarily responsible for the information systems and financial reporting procedures supporting the university is known as Financial Information Systems (FIS). The director of FIS contacted an enterprise modeling group to develop a series of

models of FIS operations in preparation for business process redesign efforts. History of Computing in the Business Office. The administrative computing function at State University was originally part of the Business Office (now known as the Business and Finance Division). In the mid 1970s, administrative computing was supported by an IBM 370 mainframe located in the basement of the administration building. Around the same time, the Division of University Computing (DUC) was formed and the function of administrative computing support was moved to it. The office of Financial Information Systems was formed primarily as the Business Office’s central data entry office.

After the departure of the administrative computing function from the university’s administration building, the Division of University computing set up a remote batch station to handle the transmission of the data that was key punched by FIS. The remote batch station also printed output generated by administrative mainframe. At the time, FIS consisted of four dataentry clerks, a production supervisor, and the director. The responsibility for the remote batch station was taken over by FIS in 1981. The batch station operator was then transferred to FIS. In 1982, FIS purchased an IBM System/38 to meet the growing demand for business office computing support. Within two years the network grew to over 150 users, requiring that FIS upgrade the System/38 to the most current and largest model available. From 1981 to 1986, the director handled all mainframe ad hoc programming requests. The director also handled the coordination of projects involving the installation and upgrade of mainframe-based systems used by the Business Office. In 1988 the System/38 was replaced by an IBM AS/400 B60, which in turn was replaced by an AS/400 model E60 providing 120 megabytes of main memory and approximately 20 gigabytes of directaccess storage devices. At the time of the study, FIS offered administrative support computing services on the IBM AS/400. The system supports two high-speed printers and more that 260 local and remote terminals, personal computers, and printers located in administrative offices around campus. The primary operations of FIS are presented in Exhibit 4; an organizational chart is presented in Exhibit 5. Existing Strategic Plans. The existing plan of FIS centered around directives from the Office of the Vice-President of Business and Finance that attempted to integrate the university’s long-range goals with this office. The strategic planning and implementation process was, at best, ad-hoc and informal. At the time of the study, the university and the business office were undergoing a change in administration and organizational structure, which resulted in less emphasis on long-range planning in the area of information.

1. Provide computing and technical support to the various departments within the Business Office. 2. Act as computing liaison between the Business Office and the Division of University Computing for mainframe computer application problems. 3. Coordinate the purchase of computing equipment and software. 4. Coordinate the maintenance and repair of computer equipment. 5. Maintain computer data communications network between offices within the Business Office and between the AS/400 and the campus network. 6. Coordinate the installation of new mainframe-based systems or upgrades of existing systems. 7. Coordinate the scheduling of all production program runs. 8. Print and distribute reports generated by production systems. 9. Provide training to end users of new systems or applications. 10. Coordinate the requesting of new reports or applications with DUC; this includes establishing programming priorities for all outstanding requests at DUC that belong to the Business Office. 11. Develop new department AS/400-based applications when requested by departments. Exhibit 4.

FIS operations.

Objective of the Enterprise Model. Creating an enterprise model for FIS and the university’s central computer center would allow the university to formulate a long-term plan for decentralizing the activities that FIS currently performs and making constituent groups self-sufficient. This includes examining activities and replacing them with AS/400 applications and client/server processing, integrated with PC networks. Modeling FIS supported a structure analysis of the functions and processes that can be redesigned with an overall IT focus. The underlying objective of this goal set was to lessen the load on FIS to create a more efficient operation that still meets the financial reporting needs of the constituent groups.

The FIS director and his staff would use the enterprise model for the long-term strategic planning process and as a blueprint for processes redesign. By shedding additional light on the operations and expertise of FIS, the models would also allow the Office of Business and Finance and the Office of the Vice-President of Academic Affairs to support their long-range planning. The various constituency groups served by FIS are also affected by the project. These include the bursar’s office, the bookstore, the police depart-

Exhibit 5.

Organizational chart for FIS.

ment, risk management and insurance functions, and property control functions of the university. Methodology. The first step in developing the model was to delineate the scope of the study. FIS has three primary functions:

• To provide computer support to various other departments of the university. • To provide mail services within the university. • To administer the department. Clearly, the main focus of FIS is in the provision of computing support. The development team was fortunate to have the director of FIS as a member of the team. As director for more than ten years, he was intimately acquainted with operations and organization. His input was invaluable in accurately modeling this portion of the enterprise. The enterprise modeling itself was performed an a PC running Knowledgeware’s Information Engineering Workbench (IEW), a planning worksta-

tion software formulated on James Martin’s Information engineering modeling methodologies. Although the IEW software is no longer available other software packages and CASE tools are fully capable of performing similar functions. Knowledgeware itself has evolved into a tool called ADW; other possibilities for developing the requisite diagrams, matrices, and charts include Systems Architect, Oracle CASE/Designer 2000, and even the graphic program Visio. The tools used simply serve to reinforce the methodology applied without which any application will fail to deliver the desired outcome. Procedure. Four aspects of FIS were entered into the project encyclopedia and decomposed in diagrams. These were organizational units, functions, goals, and critical success factors. Decomposition proceeded in a top-down fashion. Units were decomposed into subunits and in some cases, into individual employees. Functions were decomposed into subfunctions down to the highest level of processes. Goals were decomposed into subgoals. Through an iterative sequence of interviews, the top two goals and their corresponding subgoals were identified (Exhibit 6).

1. Goal: To Increase Computing Self-Sufficiency Subgoals: • Maximize end-user services. • Decentralize computing on the State University campus. • Improve operational quality. 2. Goal: To shift all users on the campus away from mainframe computing toward computing on mini- and microcomputers Subgoals: • Install additional microcomputers where appropriate. • Increase promotional materials for user of micromachines. • Enforce a policy to promote the use of microcomputers. • Provide application training for all related computer areas. • Outsource training for all related computer areas. • Decrease dependence on the mainframe by — Shifting toward mini applications from mainframe applications where feasible. — Streamlining ad hoc reporting. — Streamlining output generation. • Decrease dependence on minicomputers by — Increasing dependence on network usage across campus. — Reviewing minicomputer use. Exhibit 6.

FIS goals and subgoals.

The functional decomposition was examined for responsibility and correspondence with the organizational goals. Then the corresponding subfunctions were identified and their subfunctions, and so on down the line until major processes were identified. Exhibit 7 presents one path of the provide-computer-support function.

Exhibit 7.

FIS functional decomposition diagram.

Once the functions and goals were identified, the critical success factors (CSFs) were identified and associated with functions and goals. Examples of CSFs for FIS are presented in Exhibit 8. Next association matrices were created. These matrices relate three aspects to one another: functions to organizational units, goals to organizational units, and functions to goals. The purpose of doing this is to see which organizational units and subunits and which functions and subfunctions support which goals. At this point, factor critical to the success (CSFs) of FIS entered into a series of matrices to determine which activities of FIS supported the achievement of success for the department. Data model (entity-relationship) diagrams were created for each subfunction. Theses depict the various entities tracked by the organization, and the relationship between them. Thus, for example, the first diagram clearly shows what entities are involved in establishing priorities to guide the installation of applications on the university’s mainframe computer.

1. 2. 3. 4. 5. 6. 7.

Attract, train, and retain high-quality IS personnel. Communicate service quality and reliability to top management. Continually align IS priorities with university goals. Deliver reliable, high-quality IS service. Effectively use current technology. Maintain professional IS operating performance. Maintain close contact with all users, especially those in top management. 8. Maintain effective IS planning and leadership. Exhibit 8.

Critical success factors for FIS.

Also shown on this diagram are the ways in which the entities relate to one another in the course of establishing these priorities. The encyclopedia tracks these relationships to facilitate analysis of which entities support which subfunctions and processes of FIS. The resulting matrix of entities and business functions was augmented by showing the involvement of the entities that have responsibilities for the functions. The classification included: direct management responsibility, executive or policy-making authority, functional involvement, technical expertise, and actual execution of the work. The association matrices resulted in the following comparisons (the order of mention is vertical axis, then horizontal axis): • • • • • • • •

Subject area supports goal. Goal is cited by organizational unit. Entity type is responsibility of organizational unit. Function is responsibility of organizational unit. Function supports goal. Critical success factor is cited by organizational unit. Function supports critical success factor. Goal is affected by critical success factor.

Following the creation of these matrices, a collection of property matrices was developed based on the entity type (either fundamental, associative or attributive); organizational units; critical success factors; and goals. Through the modeling process, several interactive sessions were conducted to integrate the director of FIS and selected staff into the development of the models. The director acknowledged that he really hadn’t comprehended the department’s complexity until it was laid out in the models. Integrating various members of the modeling team and end users resulted in a much more comprehensive analysis of the business opera-

tions. These interactive sessions are better known as joint strategic planning (JSP) sessions. Joint Strategic Planning JSP sessions involve end users in collaborative strategy development and planning sessions. IE methodology is used to provide an overview enterprise model of the organization, including its strategies and plans. CASE systems, particularly an upper-case system, may be used to support interactive and more productive sessions. During these sessions, executive and top-level systems personnel interact to develop or modify strategies and plans and subsequently develop the enterprise model for the functional activities of the organization. These sessions can also be used to determine how to use information technology strategically. The earlier stages (statement of objectives, development of user requirements, and logical design) of the traditional systems development life cycle are the most important for user participation. From the IE perspective, these stages correspond roughly to the strategy, planning, analysis, and design stages. There are three compelling reasons for stressing user participation during these phase/stages. First, when CASE is employed, the use of JSP sessions followed by joint application development sessions permits strategic specifications to be integrated with analysis and design specifications. Second, during the early stages, the users’ experience and contributions are strongest and the IS professionals’ are weakest. Third, the potential cost associated with detecting and correcting errors in the later stages of the systems development of complete and accurate user requirements. JSP may require many participants. To be most effective, each participant (both user and IS professional) must have the authority to make decisions concerning user requirements that will not later be overruled by high-level management. For this reason, it is important that participants be experts in the areas they represent. During sessions with the modeling team, the director of FIS helped evaluate and define the functional relationships incorporated into the CASEdriven enterprise model. The JSP sessions employed by this project enabled the business modeler to fully and quickly engage the director in the accurate description and subsequent modeling of the business. As the director of FIS was able to see the model being built interactively, he was able to suggest changes from previous sessions, thus deriving a better model in the earlier stages. The Information Engineering Workbench (IEW) software enabled interactive changes to be made in the model that automatically made subsequent changes in all related parts of the model. Use of JSP

improves requirements analysis and subsequent results in more effective systems that enable and enact the strategic plans of the organization. CONCLUSION The ideals of enterprise modeling as an integrated component of strategic business engineering provide a competitive alternative to the continual decline of businesses and organizations. Organizations continually focus their attention on reducing existing cost structures and resources in a vain attempt to counteract the increasing gap between mature organizations and newer, more innovative organizations. Only by fundamentally changing not only how business is performed, but also how business is defined, can businesses expect to survive and adapt in the new information age. Since this study was completed, FIS has implemented many of the proposed changes. It has completed consolidation of university financial applications into the AS/400 environment allowing increased centralized control, code standardization, and security. The results of the study were incorporated into the strategic planning for FIS, the Division of University Computing, and the university as a whole. The changes presented stabilized, allowing additional emphasis on integrating IT strategic planning with overall strategy and an improved focus on technology. The university has made the advancement and development of technology one of its strategic goals, to support administrative and academic computing and has begun a university-wide enterprise modeling project. The results of this subsequent analysis should serve to provide the basis for requests for additional funding for technology and technology-related materials and personnel. The president of the university is optimistic about the implementation of new technologies that will provide increased quality in education, both locally and through distributed education programs.

Suggest Documents