Popular in Course
verified elite notetaker
Popular in none
This 17 page Document was uploaded by an elite notetaker on Monday December 21, 2015. The Document belongs to a course at a university taught by a professor in Fall. Since its upload, it has received 8 views.
Reviews for Methodology-and-Technology-Services
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 12/21/15
Paper: Clive Finkelstein - "Business Re-Engineering: Three Steps to Succ ess" Methodology and Technology Services www.ies.aust. Web com | Home | Courses | Certification | Projects | Papers | EA Blog | Online Store | Contact Us | Home Courses Certification Projects BUSINESS RE-ENGINEERING: Papers THREE STEPS TO SUCCESS TEN Archive EA Blog Printable PDF Version Contact Us Search By Clive Finkelstein, Managing Director Links Copyright © 1993-1996 Information Engineering Services Pty Ltd. Online Store Contents Clive Finkelstein - "Business Re-Engineering: Three Steps to Success" ● Synopsis ● Introduction ● Business Re-Engineering from Business Plans ● Business Re-Engineering from Business Processes ● Business Re-Engineering from Business Information ● Identifying Cross-Functional Business Processes ● Conclusion ● References ● More Information ● Note: An updated version of this paper, titled: "Business Re-Engineering and the Internet: Transforming Business for a Connected World" is also available to be read online from your browser, or it can be downloaded as a Word 6.0 document. Synopsis Organizations are rushing into Business Processes Re-engineering (BPR) to improve organizational effectiveness and efficiency, and achieve competitive advantage. But to improve processes without first knowing which business plans are addressed by the processes, and what in formation is needed to support those plans, may prove to be an exercise in futility. Processes are only one aspect of the business: business plans and business information are the other two esse ntial components. Understanding the data and information resources of a business is essent ial. If copies of the same data http://www.ies.aust.com/papers/brepaper.htm (1 of 17)04-Sep-06 2:17:51 PM Paper: Clive Finkelstein - "Business Re-Engineering: Three Steps to Succ ess" exist redundantly in the organization, many business processes are neede d to keep redundant data versions up-to-date and synchronized. In contrast, Business Re-Engineering (BRE) addresses all three areas: business plans, business processes and business information. These three areas must all fully sup port each other if success in re- engineering is to be realised. If redundant data versions are integrated so that each authorized area of the business can share the same data, new business processes emerge. The se re-engineered processes are able to cross previous functional boundaries, bringing not only impr ovements in business efficiency and effectiveness but in many cases also competitive advantage. This pap er shows how this can be achieved through Business-Driven Information Engineering. Back to Contents. Introduction Organizations are today faced with unprecedented competition on a global basis. To compete effectively, they must change: those that fail to see the need for change will not su rvive. This change, in most cases, involves re-engineering the business. In fact, the top two issues for ma nagers in 1993 were found to be re- engineering the business through IT, and aligning IS and corporate goals . By setting a focus on business re-engineering, and on development of information systems that directly support strategic business plans, managers can take control and turn today's chaotic envir onment to their competitive advantage. To compete, organizations are downsizing. According to Drucker: "We are entering a period of change: a shift from command and control organizations to information-based organi zations of knowledge specialists. The typical large business 20 years hence will have fewer t han half the levels of management of its counterpart today, and no more than one third the managers" . While computer power has increased 350 times in the twenty years from 19 72 - 1992, the cost of that power has fallen by a factor of 60. But over this period the productivit y of systems development has hardly moved [ 3]. The challenges of systems development are now greater than ever befor e. Legacy systems (computer systems introduced 10 or 20 years ago) are complex, and difficult to change. The development of new systems is also slow, and error-prone. These two fact ors have now become the major inhibitors to organizational change. Consider the following ... Today, in many organizations, the average development backlog (before c omputer applications are built and can be used) is now 3 years, while the average development time is 2 years, the average delivery behind schedule is 1 year, and the average budget overspend is double! A nd the proportion of the data processing budget that is spent on maintenance (correcting or changing existing application systems) is 60% - but 60% of that is expended in the first six months: fixing errors in applications that should initially have been delivered correct. And the proportion of completed application systems that are delivered, but never used (because they failed to address the businesses' true needs) is 47% [ 4]! This is indeed a sorry indictment of systems development technology, but the problems are not u nique to the Information Technology industry. To succeed in today's environment an organization must focus first on cu stomers and markets, rather than on products and production. But customers today are often unable, o r unwilling, to specify the characteristics or features of a product or service until they are ready to take delivery. To compete in this market environment, flexibility is key: the time to market has to go to virtual zero [ This suggests a strategy of Assemble-to-Order: of products, custom-built from standard components, and uniquely tailored to each customer's specific needs. http://www.ies.aust.com/papers/brepaper.htm (2 of 17)04-Sep-06 2:17:51 PM Paper: Clive Finkelstein - "Business Re-Engineering: Three Steps to Succ ess" An assemble-to-order strategy applies not only to manufacturing and asse mbly, but to most service industries as well: such as through custom-tailored banking or insurance products, or government services. It also applies to systems development. Fortunately the soluti ons are known. They involve the integration of business and IT: integration on the business side of stra tegic business planning and business re-engineering; and on the IT side of client-server systems and object-oriented development. Consider a typical business that accepts orders from their Sales Dept, t hat have been placed by customers. These orders are processed first by the Order Entry Dept, and then by the Credit Dept. Each department needs details of the customer, such as name and address, and account balance, and details of the order. These are saved in customer files and order files, held an d maintained by each department as shown in Figure 1. In satisfying these orders, items used from inventory must eventually be replaced. These are ordered by the Purchasing Dept from suppliers, and are then later paid by the Accou nts Payable section of the Accounts Dept. Details of name and address, and the account balance due to the supplier, are also saved in supplier files and creditor files. These are held redundantly a nd are maintained separately by each department as also shown in Figure 1. To ensure these redundant data versions are kept current and up-to-date and all versions consistently refer to the same information, any change to one data version must be im mediately made to all other affected versions. For example, a customer notifies Sales of a change of address. That address change must be made not only in the Sales Dept customer file, but also in the c ustomer file maintained by the Order Entry Dept. The same customer details are held and maintained redu ndantly by the Credit Dept in their client file, and by the Invoicing Section of the Accounts Dept in their debtor file. And if the customer also does business with the organization as a suppli er, that change of address must also be made to the supplier file maintained by Purchasing and to the cr editor file maintained by Accounts Payable in Accounts. The address change must be made to every redundant data version, so that all information about the customer is correct and is consistent across the o rganization. Figure 1: The same data often exists redundantly in an organization. Each redundan t data version must be maintained current, and up-to-date. This invariably leads to the evol ution of redundant processes. http://www.ies.aust.com/papers/brepaper.htm (3 of 17)04-Sep-06 2:17:51 PM Paper: Clive Finkelstein - "Business Re-Engineering: Three Steps to Succ ess" This is not a computer problem: it is an organization problem! But its resolution o ver the years has defined the manual procedures and the organization structures adopted by countless organizations. In our earlier example, procedures are defined to capture the details of cu stomers and make changes to those details when needed later, as in the change of customer address. M any of these procedures are also redundant, but are necessary to maintain the data versions all up-t o-date. Redundant data thus leads to redundant processes. And of course, people have to be allocated to carry out these redundant processes in each department. This staffing is unproductive and adds nothing to the bottom line: in fa ct, it reduces profitability. It introduces unnecessary delays in serving the customer, so reducing custo mer service - leading often to competitive disadvantage. In the 1980s office automation was introduced to solve the problem. But this focused on the symptom: the time that the Address Change Form took to reach each affected department . It did not address the true problem, the redundant data - it only sped up the paper! To resolve the problem common data (name and address in our example) when identified should be stored once only, so all areas of the business that are authorized to access it can share the same data version. This is illustr ated in Figure 2. Figure 2: Common data can be shared as one data version, and made available to all authorized to use it. Specific data is then managed by each area that needs it. While name and address is common to many areas, there is also data neede d only by certain areas. An organization may have more than one role in its business dealings with u s, shown by Organization Role in Figure 2: one role may be as a customer and another role as a supplie r. For example, Order Entry must ensure that the value of the current order, when added to the outst anding debtor balance still to be paid (maintained by Accounting) does not exceed the customer's credit limit (maintained by the Credit Dept). Similarly Accounting must be aware of the creditor balances due to be paid to organizations that we deal with as suppliers. While this data is specific to each of these areas, the name and address of an http://www.ies.aust.com/papers/brepaper.htm (4 of 17)04-Sep-06 2:17:51 PM Paper: Clive Finkelstein - "Business Re-Engineering: Three Steps to Succ ess" organization may be common - regardless of its role as a customer, or as a supplier - and is shared by all. It is in the identification of common data that the greatest impact can be made on the efficiency and responsiveness of organizations to change. Once applied, changes made to common data are immediately available to all areas that need that data to be current. An d because common data is stored only once, redundant procedures that maintained redundant data are also no longer needed. Business processes that evolved over many years to ensure all areas had access to needed data (by each department maintaining its own data version) now share common data and are immediately aware of any changes. The way in which an organization structures itself today, when common da ta is readily available and can be easily shared is quite different from the way it had to be organized when that data was difficult to obtain. New business processes emerge that often cross previous function al boundaries. This leads to business re-engineering. The strong interest today in business process re-engineering addresses only a subset of the broader subject of business re-engineering. Organizations which approach business process re-engineering without rec ognizing and correcting the redundancy problems of organizational evolution discussed above, are inv iting trouble. For example, in examining Baxter Travenol after their takeover of American Hospital Supp ly Co, Short and Venkatraman  comment that: "... although many business process redesign initiatives start out amid great fanfare and bold predictions of state-of-the-art performance improvements, lurking b eneath the glare are often quite modest attempts to reduce operational cost in a single functional area, to improve product quality in a single product line, or to downsize the business to reduce the firm's co st structure." They go on to say: "... the danger is simply that business process redesign may have little or no measurable impact on the firm's external market performance" (their emphasis). "To the extent that many companies still tend to use IT to automate existing processes rathe r than redesign them, investments in IT have yielded disappointing results." We are now seeing the emergence of the "New Corporation", defined by Tapscott and Caston [ 7] as "the fundamental restructuring and transformation of enterprises, which in tu rn cascades across enterprises to create the extended enterprise and the recasting of relationships betwee n suppliers, customers, affinity groups and competitors." In their book  they discuss that organizations today are now moving from the first era of Information Technology, to the second IT era. They categorize the first era of IT by the traditional system islands bu ilt for established organization structures, using computers for the management and control of physical a ssets and facilities, for the management and support of the human resource, and for financial manageme nt and control systems. Computers have automated the existing procedures used by an organization , replicating redundant data and manual procedures with redundant computer files or data bases, and r edundant computer processing. But these automated systems are far more resistant to change than the manual systems they replace, as discussed earlier in the Gartner Group survey. Organizations have buried themselves in concrete that has now set hard: computer systems introduced to improve o rganizational responsiveness now inhibit the very business changes needed to survive! One of the original roles of middle managers was to implement internal p rocedures and systems that reflected directions and controls set by senior management. Their other role was to extract specific information, needed by senior management for decision-making, from under lying data at the operational levels of the organization. However the organizations that downsize by o nly eliminating middle managers are vulnerable. But the elimination of redundant data and redundant proc esses, as well, leads to dramatic cost reductions - while also ensuring that accurate information is avail able. It is true that with accurate, up-to-date information available electron ically and instantly, many management layers of the first IT era are no longer needed. But if this accurate information is not available, organizations invite disaster if they do not first implement effective systems to provide that http://www.ies.aust.com/papers/brepaper.htm (5 of 17)04-Sep-06 2:17:51 PM Paper: Clive Finkelstein - "Business Re-Engineering: Three Steps to Succ ess" information before removing these managers. Only when the earlier proble ms of redundant data and redundant processes are resolved can downsizing truly be effective. Then decision-making can be faster, when access to accurate, up-to-date information is available corporate-w ide. Tapscott and Caston next describe the second era of IT as that which sup ports open, networked enterprises. These new corporations move beyond the constraints of the o rganizational hierarchy. In this second era, re-engineered processes and systems in the new corporation n ot only cross previous functional boundaries. They move beyond the organizational hierarchy - w ith computer systems that can directly link suppliers and customers. For example, insurance companies link directly with agents who sell their products: insurance policies that are uniquely tailored to satisfy their customers' exact insurance needs. Similarly airlines link with travel agents and convention organizers. Th e services they provide are not only booked airline flights, but also accommodation, car rental, and business meetings or holidays tailored uniquely to each customer's needs. In addition: banks provide direct onl ine account access for their customers; manufacturers link to terminals in the trucks of their suppli ers for just-in-time delivery; and governments provide information kiosks for public access, so that people can obtain the specific information they need. These are all examples of business re-engineering , in the spirit so memorably encapsulated in the title of Michael Hammer's landmark paper, "Reengineering Work: Don't Automate, Obliterate" . The important point to recognize with business re-engineering, and its s ubset business process re- engineering, is their vital link with the development of computer applic ation systems. But systems development has also seen dramatic change in recent years. New methods a nd software - called CASE (Computer-Aided Software Engineering) tools and methodologies - are no w available that automate most of the manual, error-prone tasks of traditional systems development. The se result in rapid development of high quality systems that can be changed easily, and fast, addressing ma ny of the problems discussed earlier. A detailed understanding of computer technology was a prerequisite of th e traditional systems development methods, and it was therefore difficult for business manager s to participate effectively. The new generation of CASE tools, such as used with business-driven Information Engineering , requires a detailed knowledge of the business. This knowledge is held by business managers and staff, not by computer analysts. When these business experts can use business-driven I E to apply their knowledge in a design partnership with computer experts, redundant data and processes are readily identified. Using the knowledge of business experts across different areas that shar e common data, integrated data bases that eliminate redundant data and redundant processes are defined using business-driven IE CASE tools . Automatic analysis of this common data by these CASE tools identifies new business processes that may cross functional boundaries, and where appropriate al so cross enterprise boundaries as discussed later. These processes are automatically derived and can su ggest common procedures. These can be identified and implemented across an organization, for impr oved efficiency and effectiveness. Business process re-engineering opportunities thus emerge . The data bases and systems which are designed are of high business quali ty, able to be implemented by computer experts using the most appropriate computer technology for the business: decentralized in a client-server environment, or instead centralized. Data bases can be aut omatically generated for any SQL- dialect RDBMS, such as IBM DB2, ASK Ingres, Sybase, MS SQL Server, Oracl e and other RDBMS products. These systems can be built using a wide variety of computer la nguages or development tools, as object-oriented systems that share common data and common logic. This enables systems to be built rapidly and changed easily. The CASE tools discussed earlier automatical ly derive object-oriented logic from the integrated data that is identified by the business experts. The result is a dramatic gain in systems development and maintenance pro ductivity and quality. Systems can now be built rapidly to meet the changing business requirements impo sed by the intense competitive http://www.ies.aust.com/papers/brepaper.htm (6 of 17)04-Sep-06 2:17:52 PM Paper: Clive Finkelstein - "Business Re-Engineering: Three Steps to Succ ess" environment of today. These systems then become competitive weapons that achieve success: not just by eliminating redundant data and processes, and duplicated staffing, so leading to huge cost savings. They also provide management with accurate, up-to-date, consistent infor mation that was difficult, if not impossible, to obtain with confidence before. In this way, IT achieves i ts true potential, as corporations move to the second era of Information Technology. The remainder of this paper illustrates how this can be achieved. As discussed above, we need to consider not only redundant data versions , but also the redundant processes which have evolved to keep redundant data versions up-to-date. Integrated data models not only eliminate redundant data versions, but also eliminate the redundant processes. Data and processes represent Business Information and Business Processes which both must support the Business Plans defined by management, shown in Figure 3. Figure 3: Business Re-Engineering improves all three areas essential to business e ffectiveness: Business Plans, Business Processes and Business Information. Back to Contents. 1. Business Re-Engineering from Business Plans Business plans represent the ideal starting point for Business Re-Engine ering, as they apply at all management levels. When defined explicitly by senior managers they are c alled strategic plans; when defined by middle managers they are called business plans. At lower mana gement levels they are defined implicitly as part of the manager's job description. We will use the generic term Business Plan to refer to all of these. Business plans define the directions set by management for each business area or organ ization unit. They indicate the mission of the area and its defined policies, critical success factors, goals, objectives, strategies and tactics. They are catalysts for definition of business pr ocesses, business events and business information as follows. Policies are qualitative guidelines that define boundaries of responsibility. In a data model, policies are represented by related groups of data entities . The data entities defined within a business area thus together represent the policies that apply to the management and operati on of that area. A policy also establishes boundaries for business processes that are carried out by on e business area, and processes that relate to other business areas. An example of a policy is: http://www.ies.aust.com/papers/brepaper.htm (7 of 17)04-Sep-06 2:17:52 PM Paper: Clive Finkelstein - "Business Re-Engineering: Three Steps to Succ ess" ● Employment Policy: We only hire qualified employees. Critical Success Factors (CSFs) - also called Key Performance Indicators (KPIs) or Key Result Areas (KRAs) - define a focus or emphasis that achieves a desired result. Th ey lead to the definition of goals and objectives. Goals and objectives are quantitative targets for achievement. Goals are long-term; objectives are short-term. They indicate WHAT is to be achieved, and have the quantitative characteristics of measure, level and time. The measure is represented by data attribute(s) within entities . The level is the value to be achieved within an indicated time for the goal or objective. These attributes represent management information, and are generally derived f rom detailed attributes by processes at the operational level. They provide information that manage rs need for decision-making. An example of a measurable objective is: ● Hiring Objective: To be eligible, an applicant must exceed a score of 70% on our Skills Assessment Test at the first attempt. There are many alternative strategies that managers may use to obtain the information they need. Strategies may contain more detailed tactics. Strategies and tactics define HOW the information is provided, and HOW it is derived. Together they lead to the definition of business process es. Examples of a strategy and business process are: ● Assessment Strategy: Interview each applicant and match to position criteria, then administe r the relevant Skills Assessment Test. ● Evaluation Process: 1. Review the completed Application Form to ensure all questions have be en satisfactorily completed. 2. Check that required references have been provided. 3. Select and administer relevant Skills Assessment Test. 4. Note total time taken to complete all questions. 5. Mark responses and calculate overall score. 6. Write score and completion time on Application Form. A strategy is initiated by a Business Event, which in turn invokes a business process. Without a business event, nothing happens: business plans, policies, goals, objectives, str ategies and processes are merely passive statements. A business event initiates a business activity or ac tivities - ie. business process(es). A business event example is: ● Interview Event: Schedule an interview date with the applicant. Documented planning statements of mission, critical success factors, pol icies, goals, objectives, strategies, tactics and business events are allocated to the business ar ea(s) or organization unit(s) involved in, or responsible for, those statements: in a Statement - Business Area Matrix or Statement - Organization Unit Matrix. This enables the subset of planning statements for each area or unit t o be clearly identified. Strategic plans that define future directions to be taken by an organiza tion represent the most effective starting point for Business Re-Engineering. But in many organizations to day the plans are obsolete, incomplete, or worse, non-existent. In these cases, another apex of the triangle in Figure 3 can be used as the starting point for Business Re-Engineering: either business proce sses, or business information. Back to Contents. http://www.ies.aust.com/papers/brepaper.htm (8 of 17)04-Sep-06 2:17:52 PM Paper: Clive Finkelstein - "Business Re-Engineering: Three Steps to Succ ess" 2. Business Re-Engineering from Business Processes Existing business processes, reviewed and documented by narrative descri ption and/or DFD's show how each process is carried out today. Business areas or organization units that are involved in, or responsible for, a process are identified and documented in a Process - Business Area Matrix or a Process - Organization Unit Matrix. A business event is the essential link between a business plan and a bus iness process. In the plan, an event is defined as a narrative statement. It can be a physical transact ion that invokes a business process. Or it may represent a change of state. The strategy or tactic t hat the event initiates is documented in an Event - Strategy Matrix. This link must be clearly shown. The process invoked by each event should also be clearly indicated: documented in an Event - Process Matrix. Without links to the plan, the business reason(s) why the process exis ts is not clear. It may be carried out only because "we have always done it that way." If the process cannot be seen to support or implement part of the plan, or provide information needed for decision-making, the n it has no reason to remain. As the past fades into history, it too can be discarded as a relic of anoth er time. To re-engineer these processes without first determining whether they are relevant also for t he future is an exercise in futility. But if the process is essential, then the strategies implemented by the process must be clearly defined. Associated goals or objectives must be quantified for those strategies. And relevant policies that define boundaries of responsibility for the process and its planning statements must be clarified. Thus missing components of the business plan are completed, so providing clear manage ment direction for the process. The third apex of Figure 3 is an alternative starting point for Business Re-Engineering. In fact, business information is a far more powerful catalyst for re-engineering than busi ness processes, as we will soon see. Back to Contents. 3. Business Re-Engineering from Business Information Data models developed for business areas or organization units should id eally be based on the directions set by management for the future. These are defined in business plans. W here business plans are not available, or are out-of-date, or the reasons why business processes exi st today are lost in the dark recesses of history, data models of business information provide clear i nsight into future needs. Data models can be developed from any statement, whether it be a narrati ve description of a process, or a statement of a policy, goal, objective or strategy. The redundant data versions that have evolved over time (see Figure 1) are represented as data models, consolidated into integrated data models. Data versions from different business areas are integrated so that any common data can be shared by all areas that need access to it. Regardless of whichever area updates the c ommon data, that updated data is then available to all other areas that are authorized to see it. With this integration, redundant business processes - earlier needed to ensure that each redundant data version is maintained up-to-date - are no longer required. Instead, new processes are needed. As common data is integrated across parts of the business, data that previo usly flowed to keep the redundant data versions up-to-date no longer flows. With integrated data models, implemented as integrated data bases, data still flows to and from the outside world - but little data flows inside the organization. The original processes that assumed data existed redundant ly may no longer work in an integrated environment. New, integrated, cross-functional processes are required. But how can cross- functional processes be identified? Data Flow Diagrams provide little gu idance in this situation. http://www.ies.aust.com/papers/brepaper.htm (9 of 17)04-Sep-06 2:17:52 PM Paper: Clive Finkelstein - "Business Re-Engineering: Three Steps to Succ ess" Affinity Analysis provides little help either. This technique is widely used by the DP-dr iven variant of Information Engineering to group related entities into business areas or subject areas [ 14]. But it is now recognised as being highly subjective. It depends on the knowledge that the data modeler has of the business; of data modeling; and the thresholds that are set. As a techni que, it is not repeatable. It is potentially dangerous, as indicated next. Where allowance is made for its subjectivity, affinity analysis can be s till be useful. But when its results are accepted blindly, without question, the end result can be disaster. It lacks rigor and objectivity. It can lead to the grouping of more data in a subject area than is needed to de liver priority systems. This will require more resources to develop those systems; they will take longer a nd cost more. This is merely embarrassing, as in: "the IS department has overrun its budget on yet another system." But the real danger is that essential, related data may not be included in the subject area. This related data may indicate inter-dependent processes that are essential for the c orrect functioning of the processes represented by the priority systems. The end result? When deli vered, the systems may not support all business rules that are essential for correct functioning of the business process. The systems may be useless: developed at great cost, but unable to be used. This sit uation is not merely embarrassing: it is disastrous! At best, it represents wasted developmen t time and cost. At worst, it can affect an organization's ability to change rapidly, to survive in today' s competitive climate. Related data that indicates existence of inter-dependent processes leads to the definition of cross- functional processes. These may suggest re-engineered business processes . Identifying Cross-Functional Business Processes Cross-functional processes can be identified from an analysis of the dat a model, based on the concepts of data dependency. This is an objective technique, described in detail in my recent book [ 15]. Its significance was acknowledged in a recent article in Database Newsletter [ 16]. Data dependency is rigorous and repeatable: it can be applied manually, or can be fully aut omated. When used to analyse a specific data model, the same result will always be obtained - regardless of whether the analysis is done by man or machine. Data dependency automatically identifies all of the data entities that a specific proce ss is dependent upon, for referential integrity or data integrity reasons. It will autom atically identify inter-dependent processes, and indicate cross-functional processes. It uncovers and prov ides insight into business re- engineering opportunities. Consider the following example, based on the analysis of a data model de veloped for XYZ Corporation: involved in Sales and Distribution from inventory. Figure 4 shows an int egrated data model that consolidates the previously separate functions of Order Entry, Purchasin g, Accounts Receivable and Accounts Payable. http://www.ies.aust.com/papers/brepaper.htm (10 of 17)04-Sep-06 2:17:5 2 PM Paper: Clive Finkelstein - "Business Re-Engineering: Three Steps to Succ ess" Key to Association Symbols and Meaning The data entity at the other end of the association must The data entity at the other end of the association may be ----|- be associated with one and only one occurrence of the ----0< associated with zero, one or many occurrences of the entity at this end. entity at this end. The data entity at the other end of the association must The data entity at the other end of the association will ----|< be associated with at least one or many occurrences of ----0|- eventually be associated with one and only one the entity at this end. occurrence of the entity at this end. The data entity at the other end of the association may be The data entity at the other end of the association will ----0- associated with one and only one occurrence of the enti----0|< eventually be associated with at least one or many at this end. occurrences of the entity at this end. Figure 4: Sales and Distribution data map showing the integration of Order Entry, Purchasing, Accounts Receivable and Accounts Payable functions. Each ORGANIZATION that XYZ deals with may have different roles, as a CUS TOMER or a SUPPLIER [both shown as secondary (sub-type) entities of ORGANIZATION ROLE]. An ORDER placed for a specific role thus will be either a CUSTOMER ORDER (taken by Order Entr y from customers), or a PURCHASE ORDER (placed by Purchasing with suppliers). Each ORDER conta ins one or many PRODUCT(s); a PRODUCT is requested in one or many ORDER(s). The intersecting (associative) entity ORDER PRODUCT has been formed by decomposing the many to many association. This represents both the Order Processing function and also the Purchasing function. Thi s introduces an important principle of the business-driven variant of Information Engineering used in this paper: Intersecting entities in a data model represent functions, processes and /or systems. This principle can lead to the identification of cross-functional proces ses that arise from integration of the Order Entry and Purchasing functions as we shall shortly see. Referring again to Figure 4, each ORDER PRODUCT may be a SHIPPED PRODUCT or a BACKORDER PRODUCT (for customer orders), or may be a CONFIRMED PRODUCT (for sup plier purchase orders), for the PRODUCT associated with ORDER PRODUCT. http://www.ies.aust.com/papers/brepaper.htm (11 of 17)04-Sep-06 2:17:5 2 PM Paper: Clive Finkelstein - "Business Re-Engineering: Three Steps to Succ ess" We also see that a PRODUCT has one or many SUPPLIER(s), but at least one (shown by mandatory many at SUPPLIER PRODUCT), and that a SUPPLIER provides one or many PRODUCT(s). The intersecting entity SUPPLIER PRODUCT clearly represents the Product Supp ly process of the Purchasing function. Similarly, an ORGANIZATION ROLE has many INVOICE(s) for PRODUCT(s), which may either be CUSTOMER INVOICE(s) or SUPPLIER INVOICE(s). The intersecting entity INVOICE PRODUCT thus represents the Accounts Receivable and Accounts Payable functions. It ma y comprise a SHIPPED INV PRODUCT or BACKORDER INV PRODUCT (for customer invoices) or an ON-TIME INV PRODUCT or LATE INV PRODUCT (for supplier invoices). This can lead to the identif ication of cross-functional processes for Accounts Receivable and Accounts Payable. The data model in Figure 4 is common to many organizations and industrie s. I have used it deliberately to illustrate fundamental principles. For example, by inspection we can alr eady see re-engineering opportunities to integrate some functions based on our understanding of the business. But what of other business areas where mandatory rules have been defined that we are not a ware of? How can we ensure that these mandatory rules are correctly applied in our area of interest ? The complexity of even this simple data model demands automated data dependency analysis. This analysis was carried out by Visible Advantage , a third generation CASE tool that fully automates data dependency analysis for Business Re-Engineering. The results are sh own in Figure 5. It represents an extract from an analysis of the complete XYZ Corporation data model, only a subset of which is shown in Figure 4. Each potential function, process or system represented by an intersectin g entity is called a Cluster. Each cluster is numbered and named, and contains all data and processes requi red for its correct operation. A cluster is thus self-contained: it requires no other mandatory reference to data or processes outside it. Common, inter-dependent, or instead mandatory, data and processes are au tomatically included within it to ensure its correct operation. Figure 5 shows Cluster 32, representing the Order Processing function. It has been automatically derived from the data model by Visible Advantage and is one cluster of 65 separate clusters derived from the complete XYZ data model used for this example. Each of these clusters is a potential sub-project; common data and processes appear in all clusters that depend on the data or process. The intersecting entity that is the focus of a cluster appears on the last line. XYZ Strategic Model Cluster Report The Entire Model Dec 20 15:49:30 2005 Page 11 ------------------------------------------------------------------ 32. ORDER PROCESSING FUNCTION (designated) 1)ORDER TYPE 1)ORGANIZATION TYPE 2)ORGANIZATION 1)NEED 2)MARKET NEED (MARKET NEEDS ANALYSIS PROCESS) 1)MARKET 1)ORGANIZATION ROLE TYPE 1)PERIOD TYPE 2)PERIOD 1)FINANCIAL STATEMENT TYPE 1)FINANCIAL POSITION TYPE 3)FINANCIAL POSITION http://www.ies.aust.com/papers/brepaper.htm (12 of 17)04-Sep-06 2:17:5 2 PM Paper: Clive Finkelstein - "Business Re-Engineering: Three Steps to Succ ess" 4)FINANCIAL STATEMENT 1)FINANCIAL ACCOUNT TYPE 5)FINANCIAL ACCOUNT 6)ORG ROLE FINANCIAL ACTIVITY (ORG ROLE FINANCIAL MGT FUNCTION) 3)ORGANIZATION ROLE 4)ORDER 1)ORDER PRODUCT TYPE 2)PRODUCT NEED (PRODUCT DEVELOPMENT PROCESS) 4)SUPPLIER (SUPPLIER DATA BASE) 5)SUPPLIER PRODUCT (PRODUCT SUPPLY PROCESS) 1)PRODUCT 5)ORDER PRODUCT (ORDER PROCESSING FUNCTION) ------------------------------------------------------------------ Figure 5: Data Dependency analysis of integrated Sales and Distribution data model from Figure 4, showing inter-dependent processes in the Order Processing function. An intersecting entity on the last cluster line (ORDER PRODUCT in Figur e 5) is directly dependent on all entities listed above it that are in bold; it is inter-dependent on those entities above it that are not in bold. Inter-dependent entities represent common data and processes that are al so shared by many other clusters. An intersecting entity indicates an inter-dependent function o r process; the name of that process or function is shown in italicised brackets after the entity name. Thus we can see that the Order Processing function and the Product Supply, Product Development and Mark et Needs Analysis processes are all inter-dependent. They are also important to the Org Ro le Financial Mgt function. Why are these processes all included in this cluster? We saw in Figure 4 that a PRODUCT must have at least one SUPPLIER. Figur e 5 thus includes the Product Supply process to ensure that we are aware of alternative suppli ers for each product. But where did the Product Development and Market Needs Analysis processes come fro m? Separate from the data model for Order Processing in Figure 4, the data model for the Product Development function follows the business rule that each PRODUCT we offe r must address at least one NEED relating to our core business. Similarly the data model for the Mar ket Research function follows the rule that each MARKET must have at least one core business NEED. Thus th e Product Development and Market Needs Analysis processes have been included as inter-dependent pr ocesses in Figure 5. We can now see some of the power of data dependency analysis: it uses th e business rules defined across the entire enterprise. It acts as a business expert: aware of all relevant business facts. It determines if other business areas should be made aware of relevant busi ness rules, data and processes. So what do these inter-dependent processes suggest? They indicate that these functions and processes are all cross-functiona l; that potential re-engineering opportunities exist. These separate processes can be integrated. Conside r the following scenario - before re-engineering: http://www.ies.aust.com/papers/brepaper.htm (13 of 17)04-Sep-06 2:17:5 2 PM Paper: Clive Finkelstein - "Business Re-Engineering: Three Steps to Succ ess" Customer: "Customer 165 here. I would like to order 36 units of Product X." Order Clerk: "Certainly, Sir. ... Oh, I see we are out of Product X at the moment. I' ll check with the Warehouse. I will call you back within the hour to let you know when we can expect more of Product X into stock." Customer: "No don't bother, I need to know now. Please cancel the order." Now consider the same scenario - after re-engineering: Customer: "Customer 165 here. I would like to order 36 units of Product X." Order Clerk: "Certainly, Sir. ... Oh, I see we are out of Product X at the moment. On e moment while I check with our suppliers. ... Yes, we can deliver 36 units of Product X to you on Wednesday." "By the way, do you know about Product Y. It allows you to use Product X in half the time. I can send you 36 units of Y as well for only 20% more than your original order. If you agree, we can deliver both to you on Wednesday." Customer: "OK. Thanks for that suggestion, and Wednesday is fine. I look forward t o receiving 36 units each of Products X and Y on that day." Order Clerk: "We find that customers using Product X also enjoy Product Z. Have you us ed this? It has the characteristics of ... ... and costs only ... ... Can I include 36 u nits of Product Z as well in our Wednesday delivery?" Customer: "Yes. Thanks again. I confirm that my order is now for 36 units each of Products X, Y and Z - all to be delivered on Wednesday." What has happened in this second scenario? X was out of stock, so the Pr oduct Supply process automatically displayed all suppliers of Product X. The Purchasing funct ion has been re-engineered so that the Order Clerk can link directly into each supplier's inventory sy stem to check the availability and cost of X for each alternative source of supply. For the selected suppli er, the Clerk placed a purchase order for immediate shipment and so could confirm the Wednesday delivery date with the customer. Next, the Product Development process displayed related products that me t the same needs addressed by Product X. This suggested that Product Y may be of interest. An order for Y, based on the current order for X, was automatically prepared and priced - and Y was in stock. This extension to the order only needed the customer's approval for its inclusion in the delivery. Finally, the Market Needs Analysis process knew that customers in the sa me market as Customer 165, who also used Products X and Y, had other needs that were addressed by P roduct Z. A further extension to include Z in the order was automatically prepared and priced. Z was a lso in stock and was able to be included in the delivery, if agreed. Instead of waiting for stock availability from the Warehouse in the firs t scenario based on separate, non- integrated processes for each function, the re-engineered scenario let t he Clerk place a purchase order directly with a selected supplier so that the customer's order could be satisfied. And the Product Development and Market Needs Analysis processes then suggested cross-sel ling opportunities based first on related products, and then on related needs in the customer's m arket. http://www.ies.aust.com/papers/brepaper.htm (14 of 17)04-Sep-06 2:17:5 2 PM Paper: Clive Finkelstein - "Business Re-Engineering: Three Steps to Succ ess" Of course, this example does not illustrate a new approach to re-enginee ring. It is used every day in the travel industry. Any travel agent, after a flight is confirmed, will cro ss-sell accommodation, car rental and perhaps tours of the destination: as the confirmed travel booking indica tes possible related needs. However data dependency ensures that re-engineering opportunities from i nter-dependent processes are not overlooked. Let us look further at the benefits of data dependency a nalysis. Some entities in Figure 5 represent existing data bases that do not need to be changed; these can be used in their present form by interfacing to them in the Order Processin g function. Other entities are data bases that may need to be changed: for example, to include additional at tributes or associations, or to be migrated to other hardware or software platforms. Still other entities m ay represent data that does not exist today. These new data bases must be defined and implemented. The bracketed numbers preceding each entity listed in Figure 5 show the project phase in which that entity should be defined in greater detail. We see here another benefit of data dependency: it results in the automatic derivation of project plans. Each entity with a higher phase number is indented one further position to the right. The cluster appears in outline form, and can be r ead as a conceptual Gantt Chart. It can also provide input to any Project Management package for more detail ed project planning. A cluster in outline form can be used to display a data map automaticall y. For example, vertically aligning each entity by phase, from left to right, shows the data map in Pert Cha rt format. Or instead entities can be horizontally displayed by phase, from top to bottom, in an Organizati on Chart format. An entity name is displayed in an entity box; the attribute names may also be displayed in the entity box, together with details such as create, read, update, or delete responsibility, if requi red. And because the data map is generated automatically, it can be displayed using different data modeli ng conventions: such as IE notation, or instead IDEF1X. This ability to automatically generate data maps in different formats is a characteristic of third generation CASE tools: data maps can be displayed from clusters. They do not have t o be manually drawn; they can be automatically generated. When new entities are added, or associations changed, affected data maps are not changed manually: they are automatically regenerated. Similarly, process maps can be generated from data models. For example, data access processes (Create, Read, Upd ate, Delete), that operate against entities as reusable methods, can be automatically generated as object-oriented process maps by such third generation CASE tools. Re-engineered, cross-functional processes identified using data dependen cy analysis can also suggest reorganization opportunities. For example, inter-dependent processes may all be brought together in a new organization unit. Or they may remain in their present organization structure, but can be integrated automatically by the computer only when needed - as in the re-engineered scenario discussed above. Back to Contents. Conclusion To re-engineer only by improving processes using Business Process Re-eng ineering (BPR) is like closing the barn door after the horse has bolted! Existing processes must be rel ated back to business plans. Only those processes that support plans relevant to the future should be cons idered for re-engineering. If a process is important and there are no plans today to guide the process, then plans must be defined that will provide the needed process guidance for the future. If this is not done, then BPR has the same long term impact on an organization's competitiveness as rearranging the deck chairs had on the survival of the Titanic. Business plans include policies, goals, objectives, strategies and tacti cs. They may need information for decision-making that is not presently available in the enterprise. This information may be derived from http://www.ies.aust.com/papers/brepaper.htm (15 of 17)04-Sep-06 2:17:5 2 PM Paper: Clive Finkelstein - "Business Re-Engineering: Three Steps to Succ ess" data that does not exist today. Thus no functions or processes will pres ently exist that provide the information, or that maintain non-existent data up-to-date. By looking a t processes only, BPR may never have seen the need for this new information, data, functions and process es. However the business plans provide a catalyst for definition of data and information in data models defined at each relevant management level. These data models are analyse d automatically by data dependency to determine inter-dependent processes. In turn, these sugges t cross-functional re- engineered processes. Data dependency analysis derives the project plans automatically to implement the data bases and systems needed by these re-engineered processes. Only when all three apexes are addressed in the BRE triangle of Figure 3 can Business Re-Engineering fully consider the needs of the business for the future. These are the t hree steps to success in BRE. Only then can re-engineered organizations be built that are effective, effici ent, best-of-breed, and able to compete aggressively in the future. Back to Contents. References 1. CSC Index, "Top IS Management Issues", CSC Index, Cambridge: MA (1992) 2. Peter Drucker, "The Coming of the New Organization", Harvard Business Re view, Cambridge: MA, (Jan-Feb 1988) 3. Amdahl Australia, Amdahl Executive Institute Report, Sydney: NSW (1992) 4. Gartner Group, "US Federal Survey", Sentry Market Research, Boston: MA (1992) 5. John Zachman, "Framework for Information Systems Architecture", Zachman International, Los Angeles: CA (1992) 6. Short and Venkatraman, "Beyond Business Process Redesign: Redefining Baxter's Business Network", Sloan Management Review (Fall 1992) 7. D. Tapscott and A. Caston, "Paradigm Shift: Interview with Tapscott and Caston", Information Week (Oct 5, 1992) 8. D. Tapscott and A. Caston, "Paradigm Shift: The New Promise of Information Technology", McGraw-Hill, New York: NY (1993) 9. Michael Hammer, "Reengineering Work: Don't Automate, Obliterate", Harvard Business Review, Cambridge: MA (Jul-Aug 1990) 10. Information Engineering (IE) - first developed in Australia and New Zealand in the late 1970s by the Information Engineering Services companies, and supported in the USA by Visible Systems Corporation - is now the dominant systems development methodology world- wide. Business-driven IE, developed for the 1990s by the same group of companies, is the next IE generation and addresses the business problems described in this paper. 11. These software products are Visible Advantage (a third generation CASE tool that automates business-driven IE) and Visible Advisor (a hypermedia methodology reference product for business- driven IE). They run under Windows 3.1, Windows 95 or Windows NT on IBM -compatible PCs and can be used to design and build systems for any hardware or software pla tform environment. Both products were developed in the USA by VisibleSystems Corporation (Visible) in Washington, DC. 12. A data entity represents data that is stored for later reference. It is a logical representation of data, implemented physically as a Table in a relational data base environment. 13. Data attributes provide information about the data entity in which they reside. Attributes are physically implemented as Columns in a Table. 14. Many CASE tools supporting DP-driven IE (developed in the 70s to suppor t the 80s) still use Affinity Analysis. These CASE tools include IEW and ADW (by KnowledgeWa re, purchased by Sterling Software), IEF (TI), and others. Affinity Analysis does not provide the analytical rigour that is needed to identify cross-functional processes, which are vital for su ccess with Business Re- Engineering in the 90s. http://www.ies.aust.com/papers/brepaper.htm (16 of 17)04-Sep-06 2:17:5 2 PM Paper: Clive Finkelstein - "Business Re-Engineering: Three Steps to Succ ess" 15. Clive Finkelstein, "Information Engineering: Strategic Systems Development", Addison-Wesley, Reading: MA (1992). 16. Stephen McClure, "Information Engineering for Client/Server Architectures", Data Base Newsletter, Boston: MA (Jul-Aug 1993). 17. Visible Advantage is a third generation CASE tool that runs under Windows 3.1, Windows 95 or Windows NT. It automatically uses data dependency to analyse data models , identify cross- functional process opportunities for business re-engineering, and derive project plans from da
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'