Business Processes and Design

8/21/2019 Business Processes and Design

1/28

1

BPTrends ▪ Ma 2007 Business Processes Architecture and Desi n

Copyright © 2007 Oscar Barros. All Rights Reserved. www.bptrends.com

BUSINESS PROCESSESARCHITECTURE AND DESIGN

Oscar BarrosIndustrial Engineering Department

Facultad de Ciencias Físicas y MatemáticasUniversity of Chile

1. Introduction

The architecture of the Business Processes (BP) of an enterprise is defined as the type ofprocesses it contains and the relationships among them. We may define an architecture for thewhole of an enterprise of for some portion thereof.

The problem of interest to us is how to design such structure, with a particular approach inmind: to start with a general normative structure that gives a pattern from which to derive a

design. This idea is related to several proposals for frameworks that enterprises have used toguide architecture design, such as Zachman’s framework [13, 25]. But we depart from suchproposals in that our intent is to make use of specific business knowledge which allows us topropose more precise and detailed patterns to support design. Our first proposal for suchpatterns was made in 1998 [4], based on the experience derived from a large number of BPdesign projects. In summary, we proposed four major grouping of processes, valid for anyenterprise, that we called macroprocesses. They are Macro1, the Value Chain; Macro2, forNew Capabilities Development –new products, infrastructure, etc.–; Macro3, for BusinessPlanning; and Macro4, for Support Resource –human, financial, etc.– Management. Then, ageneral architecture was developed which included the relationships among thesemacroprocesses. The general architecture was detailed by giving, by mean of what we calledBusiness Process Pattern (BPP), the component processes of each macroprocess and therelationships among them by means of flows.

In the next sections we will present in some detail the architecture of macroprocesses andthe corresponding BPP.

Our macroprocesses are similar to the ones recently proposed by HP and APQC. HPproposed, along the lines of a SCOR [21] generalization, five major grouping of processes(see Figure 5); Business Development, which correspond to our macroprocess BusinessPlanning; Design Chain, which is part of our New Capabilities Development; EnablingProcesses, our Support Resource Management; and Customer Chain and Supply Chain,which together are equivalent to our Value Chain. On the other hand, APQC [1] definesDesign and Develop Products and Services, part of our New Capabilities Development;Develop Vision and Strategy, part of our Business Planning; Market and Sell Products andServices, Deliver Products and Services and Manage Customer Service, which together areequivalent to Value Chain; and Management and Support Services that are closely related to ourSupport Resource Management.

The coincidences above partly validate our intent of having a general structure ofprocesses for an enterprise. In connection with the similar proposals above, we posit thatour general structure gives more useful details for design than such proposals, particularlyin the explicit relationships it proposes to consider among macroprocesses.

Our BPP have also some features in common with approaches such as SCOR [21], VCOR[24], APQC [1], eTOM [23] and FEA [25], which were also developed after ours. Inparticular, they provide a process classification structure down to the level of activities,plus, in some cases, metrics for performance, best practices and some information about


2/28

2



relationships [10]. Our BPP do all this, but additionally, for all the possible processes in anenterprise, they state the normative relationships that should exist among them, by meansof information and other types of flows, in order to have the required coordination tofunction as a system and optimize overall performance. Also BPP show the explicit ITapplication support processes should have.

Our general macroprocesses structure and BPP have been used in more than one hundredprojects to guide architecture and process design. In the next sections we will presentsome cases that show how our proposal facilitates design.

2. A General BP Architecture

2.1. A BP Ontology

In order to give a more solid basis for our architecture proposal, we have built a BP Ontology,based on the ideas of Artificial Intelligence [17, 32]. We will not give the technical details here,but present the final result of our effort in the form of a UML class diagram that details thestructure of the BP of an enterprise. The resulting class diagram is shown in Figure 1, whichwill explain below.

We start by defining the macroprocesses that, according to our empirical base of projects,covers all the processes an enterprise needs to perform in a coordinated way. They are, asshown in Figure 1:

Macroprocess1 (Macro1): Value Chain or the group of processes that execute theproduction of the goods and services which define the purpose of a business; it coversall activities from client requests to satisfactory delivery.

Macroprocess2 (Macro2): Group of processes that a business performs to develop newcapabilities that are required to enhance its competitiveness, such as new products,new infrastructure and new processes.

Macroprocess3 (Macro3): Business Planning or the group of processes that define thefuture of a business in the form of strategies, plans and programs.

Macroprocess4 (Macro4): Group of processes that manage the resources needed byother functions: financial, human, infrastructure and others.

The Ontology also shows that Macro2 and Macro3 have specializations for particularcases.

The structure of processes is recursive, as shown by the relationship Implements in Figure 1,in that the macroprocess BP Development generates the BP Architecture. This means thatsuch architecture changes in time to adapt to the environment by means of new processcapabilities.


3/28

3



Contains

Composed of

Implements

Uses

Uses

Supports

Uses

Regulates

Directs

Produced by

Updates

Uses

Manages

Input/Output of

Composed of

Uses

Composed of

MACRO1: VALUE CHAIN

MACRO2: NEW CAPABILI-TIES DEVELOPMENT

MACRO3: BUSINESSPLANNING

MACRO4: SUPPORTRESOURCE MANAGEMENT

PRODUCT

DEVELOPMENT

INFRASTRUCTUREDEVELOPMENT

BP DEVELOPMENT

HUMAN RESOURCEMANAGEMENT

MACROPROCESSARCHITECTURE

PROCESS

RELATION

FINANCIAL RESOURCE

MANAGEMENT

INFRASTRUCTUREMANAGEMENT

OTHER RESOURCESMANAGEMENT

MANAGEMENT

PROCESS

EXECUTION

PROCESS

STATE STATUSPROCESS

SUBPROCESS

Composed of

Uses

ACTIVITY

I/O INFORMATION

CONTROL

INFORMATIONFLOW

PHYSICAL FLOW

STATE STATUS

INFORMATION

BUSINESSPRACTICE

BUSINESS LOGIC

AND RULES

PHYSICAL I/O

RESOURCE

INPUT

PRODUCT

ENTERPRISEARCHITECTURE

Figure 1. Business Processes Ontology

Now each macroprocess has an internal structure, also discovered by analyzing many realredesign projects and founded on regulation concepts [2,3,4], which is shown in Figure 1 by

means of the types of processes it contains; they are:Execution: Set of subprocesses and activities that transform certain physical inputs,such as raw materials, documents, components, etc., into a “product”. This can be aphysical product, such as a cardboard product, which is generated from pulp andchemicals, or a service, like a loan which is generated form documents that specifysubject and conditions for it.

Management: Set of subprocesses and activities that gather customer’s requirementsand direct Execution –by means of objective setting, plans, programs, resource


4/28

4



assignment and the like–to produce what is required.

State Status: Set of IT subprocesses and activities that gather transactions occurring inExecution and Management, update the state of such processes and feed it back tothem, in order that all the activities in a macroprocess always know its overall status.

This definition can also be represented by means of a flow diagram, shown in Figure 2,where we make explicit the relationships specified in the Ontology in Figure 1. Theapplication of the model in such figure is obvious in physical production of goods andservices oriented to final customers, such as manufactured goods or health and educationservices. So we will give an example of an internal customer service, which is the case of thegeneration of a business plan. Execution in this case is the “production” of such plan having asphysical inputs various documents, such as market studies, government regulations,intelligence information and the like. Management includes to act by request of a top levelexecutive on the assignment of people to a team that will develop the plan, the generation of awork program and the follow up that assures its completion. State Status facilitates the digitalstorage and management of all the documents involved and the updating and reporting of thestatus of the work program.

Figure 2. Types of processes in a macroprocess and their relationships

Now coming back to the Ontology, Processes are composed of Subprocesses and these of Activities.

Subprocesses are sets of activities of a process that produce a well defined result that isrequired within it. For example, in the process of Execution that develops a new product, we

need a subprocess for the generation of a prototype or model to scale. Activities are the mostdisaggregated elements of the macroprocesses and they execute Business Practices thatcontain Business Logic and Rules. Business logic is defined as complex computer runalgorithms or human performed procedures that specify the way a business is run; for examplea complex algorithm for risk assessment based on mathematical modeling or a complexmedical procedure (protocol) to treat a certain illness. Business logic and rules may containformal rules, which are specific decision criteria for a well defined situation; for example, do notgive a loan to somebody who has issued bad checks. Macroprocesses, Processes, and Activities,use several instances of a Relation to perform their duties. A Relation can be an Information


5/28

5



Flow or a Physical Flow. The latter are the Physical I/O –Input or Product– or a Resource that areneeded for Execution: raw materials, components, documents, machinery, computers and thelike. An Information Flow exists to convey what is needed to communicate with external partiesand to coordinate processes or activities in a macroprocess: requirements from customers,specifications of products or services, sales forecasts, production or operation plans, materialsrequirements, delivery schedules, etc. In Figure 2, there are several examples of these flows and

of how they allow coordination. An Information Flow can be an I/O Information, a Control or aState Status Information*. I/O Information is the one that is consumed in the execution of theinternal business logic of an activity and is also the product of such logic. Control are the policies,regulations and instructions that guide the behavior of the activity. And State Status Information isthe set of data coming from the State Status Process, also needed to execute the business logic.Examples of all these type of flows are given in Figure 3.

Our Ontology has some features in common with the OMG´s Business Motivation Model [19], butour proposal is more specific in terms of business process structure.

Figure 3. Examples of Information Flows

2.2. The BP Architecture

Based on the BP Ontology of the previous section, we define a general architecture by firstestablishing the information flow relationships there should be among Macroprocesses in orderfor them to perform in a coordinated way. Such relationships are shown in Figure 4, where we

follow the conventions established in the Ontology for the different types of flows. They couldhave been included in the Ontology but we decided not to do so in order to simplify itspresentation.

Relationships are generic and not exhaustive; the idea is only to provide a guide to identifyspecific flows in particular cases, by specialization.

* This definition is consistent with the IDEF0 notation supported by tools like BPWin


6/28

6



Figure 4. BP General Architecture

This architecture can be compared with the ones proposed by HP and APQC [1], which havethe same purpose. These proposals are shown in Figures 5 and 6 together with theequivalences, mentioned in the Introduction, with our macroprocesses. As it was stated before,ours is a development independent from HP and APQC, it is more general and has moredetails than such proposals.


7/28

7



PlanPlanPlan Plan

Resources

Organization

DesignChain

BusinessDevelopment

Enabling Processes

R3.1

Receive,Validate & Approve

R3.2

Assign Account

Team

R3.4

ObtainCustomer

Needs

R3.5

EstablishCustomer

Profile

AmendResearch

AssistSource

Make

Deliver

Return

SupplyChain

Process

Design Sell

Customers

Level 3 Subprocesses in Relate to Named Account

Level 1 Processes

Level 4

Activities Specific to Particular

process and company

R3.3

DefineEngagement

Model

Tables for Each Process and

Subprocess

Information on specific metricsand best practices to implement

this subprocess

Customer Chain

ReviseAnalyze

Develop

Level 2 Processes: Made to

Stock, Made to Order,Engineered to Order

Level 2 Processes: Relate to

Intermediary, Relate to GroupedAccount, Relate to Named Account

Level 2 Processes:

Expansion, Extension, andCreation

Level 2 Processes:

New Technology, NewProduct, Product

Revision

R3.6

PublishBusiness

Rules

R3.7

Release to Sell

Relate

Level 0.

Organization

Divided into 4 Major

Domains

Level 2

Variations

Level 3

Subprocesses

Metrics and Best Practices for

Subprocesses

Integrate Market Contact

MACRO 1MACRO 2 MACRO 3

MACRO 4

Figure 5. HP Macroprocesses*

* Taken from a presentation by P. Harmon at the University of Chile BPM Workshop, Santiago, Chile,

2005


8/28

8



MACRO 1MACRO 3 MACRO 2

Figure 6. APQC macroprocesses

We illustrate the use of the BP Architecture with examples taken from real cases, where we alsoshow how the architecture is used to guide design. We present cases where the scope of theproblem implies that only some of the macroprocesses of the architecture are relevant. Of course,the general problem is to identify all the macroprocesse an enterprise needs, but to show howthis is done is beyond the possibilities of this paper.

First case is strategic planning for an IT services firm*. In principle, then, the relevantmacroprocess is Business Planning , but the general architecture of Figure 4 shows that there isa relationship by means of Plans and Ideas & results with Value Chain and New CapabilitiesDevelopment . So we have to determine the relevance of these macroprocesses by looking atthe purpose the enterprise has in doing strategic planning. In this case the objective is toassure that strategic ends, measured by specific KPI’s, are met by the Value Chain and, if thisis not possible, to improve such macroprocess to make it happen. This means that the Value Chain is involved and also New Capabilities Development , since to improve the former, itsredesign should be carried out by the macroprocess BP Development . So the situation can besummarized as in Figure 7. This figure shows an additional relationship among Value Chain and Strategic Planning , which is that the actual values of the KPI’s are calculated withinformation generated in the former and fed back to the latter. The main idea here is that plans

* This is based on a project developed by M. Donoso at the Master in Business Engineering (MBE) of

the University of Chile


9/28

9



should be monitored by means of calculated KPI’s and from this, ideas for processimprovement may appear, which makes necessary BP Development .

Figure 7. Macroprocess architecture for strategic planning

Another case is operational risk management in a bank**. This risk appears in the execution ofthe Value Chain, where risk events, such as errors and thefts, occur that produce economicloss for the enterprise. Then Value Chain is relevant, but since these events depend on thequality of the process, BP Development should also participate to analyze data about

risk events and determine necessary process improvements to reduce risk. Also FinancialResource Management should be involved, since the final impact of risk events is in thefinancial statements of the enterprise. All this can be summarized as shown in Figure 8.

** This is based on a real project developed by H. Mora at the Master in Business Engineering (MBE)

of the University of Chile


10/28

10



Figure 8. Macroprocess architecture for operational risk management

The third and last case is development and marketing of new products in a telecommunicationscompany*. The main idea in this case is to be able to do a precise costing of the new productsin order to provide a good basis for marketing decisions. Since costing depends on the use ofresources in the Value Chain, the only possibility for precise estimation is to simulate thismacroprocess. For this we need an executable model of the Value Chain and hence themacroprocess BP Development should be involved. Then costing based on such models wouldallow marketing people in the Value Chain to decide whether to introduce the product in themarket and if yes, at what price. This situation is modeled in Figure 9. Notice that in this casewe have two instances of New Capability Development .

* This is based on a project developed by M. Awad y A. Caprile at the Master in Business Engineering

(MBE) of the University of Chile.


11/28

11



Figure 9. Architecture for telecommunications product development

3. BPP for the BP Architecture

The BP Architecture previously presented can be detailed by giving, besides the generalstructure presented in Figure 2, the specific general processes that conform eachmacroprocesses. We have done this by means of Business Process Patterns (BPP), alsoproposed in 1998 [4], for each of the macroprocesses. The macroprocesses include bestbusiness practices reported en the literature [11,12,14,15] and validated by our experience. Wesummarize such BPP in what follows.

3.1. Value Chain Macroprocess

This structure, which is a model of the Value Chain or Macro1, shown in Figure 10, includes theprocesses of Customer relationship management , Supplier relationship management ,Production and delivery management , Production and delivery product or service and StateStatus. It also shows the necessary relationships among such processes by means ofinformation and physical flows, such as supplies and products.

Customer relationship management includes the analysis and marketing activities neededto induce and guide sales; the actual sales and service contact with customers; and theprocessing of orders, including the decisions about the feasibility and convenience ofaccepting them.

Supplier relationship management has to do with determining supply requirements; finding

adequate suppliers for each of them; planning and scheduling delivery of supplies, includinginventory management; and controlling that requirements are rightly satisfied.

Production and delivery management performs the required planning and scheduling of theproduction and delivery of goods or services, including demand analysis, capacity planning andlogistic decisions.

Production and delivery of products or services implements the plans and schedules producedby Production and delivery management .

The structure of this BPP is clearly the one specified in Figure 2, where Production & delivery


12/28

12



product or service is an Execution Process; Production & delivery management, Supplierrelationship management and Customer relationship management are instances of aManagement Process; and State Status is obviously a State Status Process.

Figure 10. Business Process Pattern Macro1

We detail a BP pattern by partitioning each of its processes, as it is shown in Figure 11 forCustomer relationship management

* . We give further details by partitioning the subprocess

Marketing and customer analysis of Figure 11, which is shown in Figure 11(b)

In Figure 11(b) we concentrate on Customer and sales behavior analysis. For such asubprocess, which is further decomposed in Figure 11(c), we can specify a best practicebusiness logic, which would involve the use of Business Intelligence, e.g Data Mining, over aDatamart with the required information. Business logic, which guides the action in an activity,determines the exact information flows that are required and that are produced, including theupdating of the process changes in State Status of Figure 11 and the state information thisgenerates, shown below each activity, which is necessary for its performance.

The pattern includes decomposition for all the activities in Figure 11. To further illustrate suchtask, we decompose Production and delivery management , which is shown in Figure 12,

Now a key and unique feature of our approach is to make explicit how the different activities ofa pattern interact to produce coordinated actions. This is done by means of the informationflows that activities interchange and the business logic that each of them executes to processsuch flows. For example, in the case of applying the previous pattern to production to stock,

such type of relationship is the one between Forecast model development of Figure 11(c),Sales Planning of Figure 11(b), Scheduling of Figure 12(b) and Supplier relationshipmanagement of Figure 10. Clearly, forecast models produced by the first activity will be used togenerate a sales forecast and sales plan, in the second, which will then trigger production lotsthat will be sequenced by Scheduling . The production schedule will, in turn, be used by the lastactivity to generate orders to suppliers. We present this coordination chain as a sub pattern in

* These process decompositions are supported by old modeling tools such as BPWin, based on IDEF0, and

new ones as those based on BPMN [18].


13/28

13



Figure 13, where we show a “horizontal” process view mixing activities from several “vertical”hierarchical decomposition views, including the explicit role of State status

* . In such chain each

activity executes a business logic that is designed to generate the required performance: toproduce what is needed according to the forecast, assuring the required supplies andminimizing production costs.

Figure 11. Decomposition of Customer relationship management

* This view is given to facilitate the understanding of the coordination issues; experienced modelers can

gather the same information from the “vertical” views in Figures 10, 11 and 12. Of course, there are many

other sub patterns that can be derived from such views


14/28

14



Figure 12. Decomposition of Production and delivery management


15/28

15



Figure 13. Coordination sub pattern

We have illustrated the concept of BPP with just one process pattern for a very general domain.Other BPP have been developed for particular cases or specializations of the general domain,such as situations in which there is not production and sale of products and services is madefrom stock bought from others, manufacturers that sells their own products, and hospital orfinancial services [5,6,7,8,9].

3.2. Support Resource Management Macroprocess

Following the same general structure of Figure 2, we present Macro4 in Figure 14, where theprocess Resource input, application and transfer is an Execution Process; Obtain resource,Decide resource application and Decide resource transfer are instances of a ManagementProcess; and State Status is an State Status Process.

Macro4 applies to any resource and a different instance for each of them can be developed; wegive examples of these instances and explain the macroprocess below.


16/28

16



Figure 14. Support Resource Management Macroprocess

Obtain resource has to do with determining needs and executing actions to obtain resourcessuch as people, machines, money, spare parts, office supplies etc.; so its purpose is to assurethat any need the enterprise has for such resources is provided by deciding, for example, tohire people, to request loans, to buy new equipment and to outsource office supplies.

Decide resource application is the process that assigns available resources to requirementscoming from other macroprocesses, such as new recruits to business units; computers topeople who need them; office space to new business; and budget to business units. It alsoincludes deciding about actions on resources that improve their capabilities, such as peopletraining, equipment maintenance, money investment, etc.

Decide resource transfer determines what to do with the resources that should be sent to otherenterprises or markets, such as obsolete equipment, money to be paid to suppliers, moneyinvested, fired employees, surplus supplies, etc.

Resources input, application and transfer executes the physical manipulation of resources,such as inputting them to the enterprise by, for example, hiring people, receiving equipmentand supplies and warehousing them, and receiving money from customers; applying theresources to different uses by, for example, putting people to work in a business unit, trainpeople, maintain an equipment, invest money and give computers assigned to people; andtransferring resources outside the business by, for example, selling surplus and obsoleteequipment, paying suppliers, investing money and firing people.

Macro4 has several more levels of detail that show the subprocesses and activities thatconform the processes and their relationship; such details are given in [5].

We remark again that what makes our BPP special is the specification of the relationships thatshould exist among processes. In the case of Macro4 it is clear that the control flows Resourceavailability message, Resource assignment message and Instructions provide the necessarycoordination among processes. This is further supported by the Resources state change thatupdates resources in State status, which in turn feeds back the state of resources to eachprocess. It is also clear that there are flows that coordinate Macro4 with other processes, such


17/28

17



as Resource needs from other processes and Plans and Resources to other processes

3.3. New Capabilities Development Macroprocess

The structure of Macro2, which is shown in Figure 15, follows the same pattern of Figure2,where Design and build new capability is an Execution Process; New capability needevaluation and Manage new capability design and built are instances of a ManagementProcess; and State status is a State Status Process.

Since new capability development is done through projects, Macro2 has the typical processesneeded for project management and execution plus the support of State status to update andcommunicate the situation of the activities in the project.

Figure 15. New Capabilities Development Macroprocess

Hence, New capability need evaluation is basically analysis of information that motivate andsupport the project and its formal economic evaluation to decide its implementation. Forexample, perform a market study and calculate a rate of return on the investment needed for anew product; analyze performance indicators of the Value Chain processes to determinenecessary redesign and calculate economic indicators that justify such redesign; and evaluateproposals for new infrastructure to determine its operational and economic feasibility.

Manage new capability design and built performs the subprocesses and activities necessary todetermine the resources needed by the project, obtain and assign such resources and producea plan for it. For example, to determine that, for the development of a new product, a prototypeshould be built and assign people with the required abilities to a team to do it, together with atimetable; and determine required professionals and assign them to do a process redesign plus

a schedule for it.Design and build new capability executes the assignments and plans of the managementprocess by carrying out the necessary activities. For example, actually design and built aprototype of a new product according to plan; do the redesign of a process according a giventimetable, and design and built new infrastructure according to plan.

The processes of Macro2 can also be decomposed as explained for Macro1, going down to alevel of detail where best practices can be recommended for the last level activities; forexample, project evaluation, planning and scheduling practices.


18/28

18



3.4. Business Planning Macroprocess

Macro 3 or Business Planning is decomposed in Figure 16. It also follows the pattern in Figure2, where Strategy development is an Execution process; Manage strategy development andDefine business concept and vision are instances of a Management Process; and State Statusis a State Status Process.

Define business concept and vision is the process that, based on information about politicalissues, economic trends, technological developments, regulation factors, and the like, definesthe vision for the enterprise, set goals and objectives (desired results) and develops anevaluation model to measure such results with suitable metrics.

Manage strategy development has two main sub processes: one which produces Strategydevelopment plans and another that evaluates Strategy proposals produced by Strategydevelopment and actual performance of strategies that have been implemented. Strategydevelopment plans include the assignment of human, financial and other resources needed forstrategy development or adjustment; and schedules for the completion of the job. Evaluation ofStrategy Proposals has as a purpose to assure that such proposals are aligned with theenterprise vision and that adequate metrics are defined to measure their performance. Actualperformance of strategies is measured by calculating the current values of the performance

metrics and comparing them with goals. Of course these evaluations may result in improvedstrategy development plans to guide the work of Strategy development .

Figure 16. Business Planning macroprocess

Strategy development has, among other tasks, to define the enterprise mission that makesoperative the vision; to generate and evaluate strategic options for new and currentbusinesses; to define organizational structure, needs for new or redesigned processes, and the

introduction of new technology; to transform strategies and other courses of action into detailedplans, including budgets, schedules and performance metrics, to be executed by othermacroprocesses; and adjust strategies under Manage strategy development guidance. One ofthe most important tasks in this list is the generation and evaluation of strategic options, since itis here where an enterprise can produce competitive advantage. Ideas such as Porter’scompetitive strategy [20] can be of value when implementing this task.

The coordination among processes of Macro3 is clearly executed with the flows in Figure 16,as we have exemplified in the explanation of such processes. There are also flows forcoordination with other macroprocesses. One is Strategic Plans, which is the one that makes


19/28

19



strategies operative in order to be executed by Macro1, Macro2 and Macro4; another isBusiness performance that feeds State Status with the information that allows to calculatestrategy performance metrics; and also we have Ideas from other processes coming from othermacroprocesses.

Macro3 can also be decomposed into sub processes and activities as it was outlined in the

presentation of this macroprocess.4. Architecture and BP Design

We emphasize that the final objective of the general BP architecture and BPP presented in theprevious section is to guide design. Hence we aim for a methodology on how to do architectureand BP designs. In what follows, we outline such a methodology and give real life cases of itsuse.

4.1. Architecture Design

As it was outlined in Section 2.2., the starting point for BP architecture design is the generalarchitecture of Figure 4. Such architecture tells us the types of macroprocesses that should bepresent in any design. Then, according to the scope of the design project, one should selectthe specific macroprocesses that need to be present in the architecture. The largest scope is to

build an architecture for the whole of an enterprise. In such a case, the approach is basically toinstantiate each of the type of macroprocess, determing all the grouping of processes that arerelevant in the case at hand. For example, several instances of Macro1 could exist if theenterprise has several value chains that function in an independent way, such as a retailbusiness that has the regular logistic chain for the products it sells but also a service chain forits own credit cards, which are used for customer purchases. Of course these different valuechains interact and their relationships are part of the architecture. In some cases therelationships are so intense that the architecture design problem includes the trade off amongintegrating value chains in just one macroprocess or keeping them separate but with commonparts which means close relationships among the value chains. This is the case of banks whereseveral value chains for different products, such us bank accounts, loans, credit cards and thelike, share common parts of the chain, such as customer sales and back office operations. Aninteresting architecture design problem here is to determine what is more cost effective: fullindependence or share of processes by means of relationships. This is a particular case of themore general problem of compartmentalization of enterprises, for which there are economicanalysis that can be made [16].

The more common case of scope one finds in practice is to design the architecture of a part ofan enterprise, such as one particular value chain, or a group of macroprocesses that arerelevant to accomplish a given purpose. As an example of this situation, consider thetelecommunication case we presented in Figure 9. This case was simplified in Section 2.2.,since the true purpose of the required BP architecture was to support a new business modeland not just allow costing of products. The new model considers that the physical production oftelecommunication services will perform as a “factory”, from which the business units willdemand services, paying for them. So the factory will be a profit center and not just a costcenter. So, in this case, the costing of products and services is the basis for the factory to bidand charge for products. This new situation is represented in Figure 17.


20/28

20



Figure 17. Telecommunications case architecture

In Figure 17 there are relationships for different purposes that take place in differenttimeframes. First, we have the relationships for new product development, which waspresented in Figure 9 and explained in Section 2.2., which occurs occasionally. Secondly,these are yearly planning relationships where Customer products and services chain provides aDemand forecast and request for bid in order for Factory products and service operation to planits production and calculate and update the Products and services catalog , SLA’s and costs,using the Process and costing models, which is the basis for eventual negotiations of SLA’sand particularly of costs, between the two macroprocesses, in order to provide competitivepricing to customers. Finally, we have a day to day relationship where Orders for products andservices are requested to the factory, which, based on the accorded SLA’s, delivers the actual

Products and services to customers.

Now we present another real case, which is close to considering the full architecture of anenterprise. It deals with a major TV Channel, which produces an important part of itsprogramming content*. So the Value chain or Macro1 covers, in this case, from the selling ofthe channel programming, with estimated ratings, to the actual production, where the cannedproducts are bought and shown, and the local products are developed and transmitted alive orgiven in prerecorded format. But for Macro1 to perform well we need at least two othermacroprocesses: one of the Macro2 type that defines all the new programming, either bystudying the market of canned products or doing market research to define the types ofprograms that should be produced locally; and another of the Macro4 type to obtain the talentsor faces the new programs need to be successful. These relationships can be modeled asshown in Figure 18. The dynamics of such relationships in this case is very intense, since, dueto the characteristics of the business, New programming development has a high level ofactivity and it is constantly interacting with the Value chain to adapt the programming to thecompetition, considering its actual rating. The same is true for Talent management that shouldrespond quickly to Value chain frequent and changing demands and also New program development needs for information about talents.

* This is based on a project developed by C. Salvatore at the Master in Business Engineering (MBE) of

the University of Chile


21/28

21



Figure 18. TV Channel case architecture

We remark that the architecture design cases presented clearly show how a particular way ofstructuring business activities works. They include many design options in terms of activitiesand processes grouping, interactions and coordination by means of relationships, andrequirements for the detail design of each of the macroprocesses. In the next section we willshow how such requirements are converted into a design with the help of the BPP.

4.2. BP Design

The basic methodology for BP design is to start with the requirements established in the BParchitecture for a given macroprocess and use the corresponding BPP to derive a design. Thisis done, in the more usual case where there is a current process, by comparing the “as is”situation with what the BPP states it should be. Then the design decision is how close to the“should be” to move and what specific practices, including the business logic, to implement foreach activity in the processes of the macroprocess under study. In the case where these is nocurrent situation, the decision is similar in terms of determining how much of the BPPrecommendations to follow.

In deciding how close to move to BPP recommendations, there is always an economic trade offthat depends on the particular business for which processes are being designed. This isbasically that improved processes generate quantifiable benefits, but they also need aninvestment in the design effort and associated implementation, including IT investments, andadditional recurring operational costs. Of course, the balance of benefits and costs, measuredby an appropriate economic indicator, should be positive for the design to be justified. Thereare many economic ideas that can be used in this analysis, which are presented in [5].

In what follows we present two cases of application of the above methodology, which use

different BPP.

The first case is operational risk management, presented in Section 2.2., for which we willdesign the BP Development macroprocess of Figure 8. For this we will use the NewCapabilities Development BPP of Figure 15.

From Figure 9, the basic requirement for BP Development is to generate New processes andRisk management design based on Financial data for risk events and Operations data for riskevents. The first process involved is New capability need evaluation, which, in this case,specializes to New process need evaluation. In this process, the requirement is to determine


22/28

22



which current processes operating in the Value chain of Figure 8, should be redesigned. Thisimplies two design decisions: what data about Value chain operation should be collected andwhat analysis to do with it. Here we should consider what data is currently available and whatnew data should be collected. We will give below the decision about this design issue, whichinvolves mainly a formalization of data collection and performing new statistical analysis todiscover the opportunities of process improvement.

Once opportunities for redesign are discovered, redesign projects should be organized andplans for their development made. This is done by the process Manage redesign andimplementation project, which is an specialization of Manage new capability design and built ofFigure 15.

Then another process should carry out the redesign and implementation project, which isRedesign and implement new value chain process, an specialization of Design and build newcapability of Figure 15.

Finally we have the typical State Status process, which keeps the situation of the differentprocesses up to date, such as operational risk data, operational risk analysis results, redesignprojects under development, and project plans and performance.

The processes above, together with the relationship flows, form the first redesign model, which

is shown in Figure 19, where we have also specialized the flows in Figure 15.

Figure 19. BP Development model for operational risk management

Now we will give more design details about New process need evaluation. Basically, as we saidbefore, we need to specify the Analysis data and the internal logic that will manipulate suchdata to produce a recommendation for value chain process redesign. There are other

procedures and design details that we avoid to simplify presentation. The Analysis data is thecurrently collected data for some value chain processes, which will be extended for all suchprocesses. It consists of financial operation loss for particular risk events that occur in a valuechain process. For example, loss due to the wrong closing of accounts in the checkingaccounts business process. The idea is to have data of this type for all the risk events thatoccur along each of the value chain processes.

Then, the analysis consists of determining the loss probability distribution for each of theseevents and the distribution of the yearly frequency of such events. Combining both distributionsby means of a Monte Carlo simulation, an empirical distribution can be built to calculate the


23/28

23



VAR, which is a yearly loss quantity that will not be exceeded with a given probability. Forexample a loss of US$ 3.5 million per year that will not be exceeded with a probability of 0.95.

Given these VAR’s for each risk event of a value chain process, it is clear that the appropriatebusiness logic is to rank them from high to low VAR for the same probability. Obviously, thelargest VAR presents the best opportunity for redesign, since if we improve the corresponding

process and reduce the VAR in a given percent, the reduction of loss would be larger. Thismakes possible to select good value chain processes candidates for redesign.

Now the other output of this process, Risk management design, is a direct consequence of theVAR analysis, since funds provisions to cover operational risks, which are required by bankregulations, can be calculated with precision: provision a quantity that covers risk with a givenprobability.

The second case of BP design we will present is the one related to the TV Channel architectureof Figure 18. Here we will consider the value chain macroprocess, which is the one thatperforms the actual emission of the TV Channel programs. Hence the BPP that applies isMacro1, shown in Figures 10 to 12. We start by specializing the first level model of Figure 10,for which it is relatively direct the mapping of the processes of the TV Channel onto it. Suchmapping is shown in Figure 20, where the model in it is the general design that comes directly

out of Macro1. We give a brief explanation of its more relevant ideas.Programming production and logistics is the process where, following Production and logistics

plans, the content of the programming is developed and emitted. This includes the productionand recording of the local series, using the available Talents, the production of live programsand its emission and also of the bought canned programs

Figure 20. TV Channel value chain model

Production and logistics management is the process that assigns resources, schedule activitiesand, in general, make sure that Programming schedule, which includes all the programs to beemitted with dates and hours, is implemented with the adequate quality and at a minimum cost.

Marketing and sales management has as a main purpose to produce and sell a Programmingschedule that maximizes the value for the channel in terms of rating and advertising income.


24/28

24



Suppliers management is the process that makes sure that all the resources —except forTalents— needed for implementing the Programming schedule are available.

Finally State status keeps up to date and provides all the information that processes need toperform their tasks, such as ratings, customer requests, schedule, resource availability andanalysis results.

We remark that the coordination flows among processes assure that the completemacroprocess operates in a systemic way.

Figure 21. Marketing and sales management modelNow we give more design details of Marketing and sales management , by using thecorresponding BPP in Figure 11a. Mapping of the TV Channel situation onto the pattern is alsostraightforward and it is shown in Figure 21. In this figure we will concentrate on Marketanalysis and planning , for which we can also apply the pattern in Figure 11b, resulting in themodel in Figure 22. Here we will detail the design of Customer and sales behavior analysis,which produces an important result that determines the Programming schedule, which is thebasis for the whole macroprocess. This activity has a purpose to produce a Rating and salesforecast for a given mix of TV programs (schedule) based on historical rating data, advertisingand sales data and other information on TV audience characteristics. Such forecast estimatesthe value for the channel of a given Programming schedule and it is the main support in tryingto define a programming that maximizes such value.


25/28

25



Figure 22. Marketing analysis and planning model

In generating the forecast above, we need a predictive model that is able to forecast thenumber of TV sets that will be turned on at a given time, and the share a given program willhave at such time in different segments of the viewing population. This is complexmathematical problem and it is beyond the scope of this paper to explain its solution. But wecan report that, in the actual case where this design was implemented, it was possible todevelop a predictive model that forecasted ratings for programs with an accuracy of more than90% and, in some cases, close a 100%.

In the cases above, we have presented the integration of architecture and process design. Inparticular, we have used the same types of models at different abstraction levels to representarchitecture and process details. Decomposition of macroprocesses of the architecture andthen of their component processes has allowed us to show design details in a controlled wayand avoid too complex representations. In the last levels of design details we have presentedbusiness logic in an informal way but, following the same idea of decomposition, proceduralmodels of the BPMN type [18] can be used to formalize such logic. As an example of formalbusiness logic we give, in Figure 23, the BPMN model that presents the logic that allowssimulating the value chain for the costing of a particular product in the telecommunicationscase of Figure 17.


26/28

26



Figure 23. BPMN model for the telecommunications case

All this shows that it is possible to integrate in the same representation the different levels ofdesign one finds in BPM: from architecture to business logic. This is an advantage inconnection to current methods used by leading companies to represent different levels ofdesign, where various approaches are used to model at such levels. For example, in a recentBPM seminar *, British Telecom, Intel and Bank of America reported using different types ofmodels for architecture, general process design and detail process design. Typically anexecutive level Zachman type [25] representation is used for architecture, an informal but moredetailed representation oriented to users is selected for general process design and a formal,usually a proprietary representation associated to a BP process modeling tool, is used for detailprocess design. This methodology has as a disadvantage the need of mapping onerepresentation onto another, which is prone to omissions and mistakes and does not allow for

traceability.

Our proposal, which allow appropriate representation at the different detail levels, does notneed mapping and has full traceability.

* DCI/Shared Insight BPM Conference, Phoenix, Arizona, May 2006


27/28

27



5. Extensions

The methodology we have presented allows integrated design from architecture to businesslogic but it is not yet formally integrated to BP support applications design. What we currentlydo is to derive requirements from the detail process models, where application support isexplicitly modeled, and map such requirements onto UML models. From these UML models,

applications are actually built.But the ultimate integration would be to have executable BP detail design models, so that themapping above could be avoided. This is the main extension of our ideas that we are currentlyworking. What we are attempting to do is to formalize all the business logic we can in BPMNmodels at the last level of design, as exemplified in Figure 23. Then we convert these BPMNmodel to BPEL and execute them with appropriate software. The problem is that, due to currentlimitations of BPMN and BPEL, this is not possible for complex logic and for man-machineinteraction within the process. The approach we are testing to solve this problem is to developweb services for the requirements that cannot be modeled adequately with BPMN/BPEL andinsert them in the orchestration one can do with the BPEL representation.

References

[1] APQC, http://www.apqc.org/portal/apqc/site[2] Barros, O. Modeling and Evaluation of Alternatives in Information Systems. Information

Systems 16, p.137. Pergamon, 1991[3] Barros, O. Object-Oriented Case-Supported Development of Information Systems. Journal of

Systems and Software 24, p. 95. Elsevier Science, 1994.[4] Barros, O. Modelamiento Unificado de Negocios y TI: Ingeniería de Negocios,

Working paper CEGES 5, 1998, Industrial Engineering Department, University ofChile.

[5] Barros, O. Rediseño de Procesos de Negocios Mediante el Uso de Patrones. Dolmen2000.

[6] Barros, O. Ingeniería e-Business: Ingeniería de Negocios para la Economía Digital . J.C. Sáez Editor, 2004

[7] Barros, O., S. Varas, Frameworks Derived from Business Process Patterns. Workingpaper 56, 2004, Industrial Engineering Department, University of Chile. Availablewww.obarros.cl.

[8] Barros, O. A Novel Approach to Joint Business and Information System Design, Journal of ComputerInformation Systems, XLV, 3, p 96. Spring 2005.

[9] Barros, O. Business Process Patterns and Frameworks: Reusing Knowledge in ProcessInnovation, Business Process Management Journal, January 2007

[10] Davenport, T.M. The Coming Commoditization of Processes Harvard Business Review ,June 2005.

[11] DMOS, Benchmarking and Best Practices[12] DTI, Best Practice, http://www.dti.gov.uk/bestpractice/[13] Harmon, P. Enterprise Architectures, BP Trends, January 2004. Available www.bptrends.com.[14] Hiebeler, R., T.B. Kelly y Ch. Ketterman. Best Practices. Simon & Schuster, 1998.[15] http://dmoz.org/Business/Management/Benchmarking_and_Best_Practices/

[16] Malone, Th. W. and K. Crowston. The Interdisciplinary Study of Coordination. ACMComputing Surveys, 26, p. 87, 1994

[17] Noy, N. F., D. L. McGuinness, Ontology Development 101: A Guide to Creating Your FirstOntology, http://ksl.stanford.edu/people/dlm/papers/ontology

[18] OMG,BPMN, http://www.bpmn.org/Documents/OMG%20Final%20Adopted%20BPMN%201-0%20Spec% [19] OMG, Business Motivation Model, www.omg.org/mda [20] Porter, M. E. What is Strategy? Harvard Business Review, November-December 1996.

[21] Supply Chain Council, Supply-Chain Operations Reference Model,


28/28


http://www.supplychain.org/page.ww?name=Home&section=root[22] Swartout, W., A. Tate. Ontologies, IEEE Intelligent Systems, January-February 1999.[23] Telemanagement Forum, Enhanced Telecommunication Map (eTOM),

http://www.telemanagementforum.com/[24] VCOR, http://www.value-chain.org[25] White House E-Gov, Federal Enterprise Architecture, http://www.whitehouse.gov/omb/egov/a-

1-fea.html[26] Zachman, J. A., www.sifa.com