A Study of the Patterns for Reducing Exceptions and

Improving Business Process Flexibility

Sanetake Nagayoshi1, Yang Liu

1 and Junichi Iijima

1 Tokyo Insutitute of Technology, Graduate School of Decision Science and Technology

Department of Industrial Engineering and Management

2-12-1, Ookayama, Meguro-ku, Tokyo, Japan

{nagayoshi.s.aa, liu.y.af, iijima.j.aa }@m. titech. ac. jp

Abstract. Exceptions are the events or situations that prevent business

processes from completing normally. When exceptions such as cancellation of

customer order occur, additional time and resources are often needed to resolve

them. It is important for enterprise to pay attention to exceptions, for reducing

exceptions efficiently and effectively may trace business process oriented

improvement or innovation. In this study, a conceptual level pattern for

reducing exceptions is proposed and discussed. This study contributes to

research by 1) understanding how DEMO can help to reduce exceptions and

improve business process flexibility through a case study of a Japanese

company; 2) discussing suggestions for reducing exceptions and improving

business process flexibility in general, 3) analyzing reasons of exceptions

generating in the context of business model change from production centered to

customer-centered, and how DEMO could help to enhance this change.

Keywords: Business Process Re-design, Exception, Process Flexibility, DEMO,

Customer-centered Business Process

1 Introduction

In computer science, an exception is an event that disrupts the normal flow of a

computer program‟s execution. In general, when a program encounters a situation that

it cannot effectively resolve, an exception will be raised. An exception must be

handled immediately or the computer program will be terminated.

In the business world, exceptions also exist. Events such as cancellation of order

and termination of contract are exceptions that prevent business processes from

completing normally. For example, a salesperson would decline an order from a

customer because his or her company does not offer the requested products and/or

services. A customer might reject delivered products and/or services because the

customer is not satisfied with the quality of the products and/or services. DEMO [1], a

business process modeling methodology based on the Language Action Perspective

(LAP) theory [2], defined exceptions as “decline of request”, “rejection of statement”

and “cancellation of commitment” from communication theory perspective. Such

exceptions prevent business processes from moving forward (e.g. entering into

negotiation mode or finish mode) until they are handled.

Handling exceptions incur extra time, managerial effort, and costs. For example,

when a customer rejects delivered products and/or services, the salesperson in charge

and his or her manager may need to take time to negotiate with the customer until an

agreement is reached. Prior studies [3] also suggest that handling exceptions always

increases time and cost incurred and reduces the efficiency of an organization. If

exceptions are not handled effectively, the level of customer satisfaction might

decrease.

The causes of exceptions could be considered as for example: Reason (1) Lack of

business capability to handle the request; Reason (2) Incomplete or inflexible business

processes; Reason (3) Incomplete information sharing and communication; Reason

(4) Improvable business processes. Although modifying or improving business

processes cannot handle exceptions related to Reason (1), exceptions related to

Reason (2), (3) and (4) can do be reduced. It is important to note that exceptions is

still worth being specially focused, although they are sometimes regarded as normal

parts of business process such as declining customer‟s order. Because efforts on

reducing exceptions might provide opportunities for improving the business process,

furthermore triggering business process oriented innovation.

Despite the importance of understanding exceptions, there is a lack of research on

this topic. This study proposes an alternative methodology for analyzing and reducing

exceptions based on DEMO [1].

Authors want to answer research questions like: How can we reduce exceptions

from conceptual level modeling?

The remainder of the paper is organized as follows: First, we review related

researches in chapter 2. Then, authors generate hypotheses for reducing exceptions in

chapter 3. Next, our study‟s design and method are outlined in chapter 4. Analysis of

case study based on DEMO and validation of our hypotheses is presented in chapter 5.

Some additional findings are discussed in chapter 6. Finally, the limitations of this

study and implications for future research are described in chapter 7.

2 Literature Review

2.1 Related Studies

The capture and management of information about exceptions are described in David

[3]. The study provided an idea of control organization by including the generation

and operationalization of organizational artifact to solve dysfunctions. The study

focuses on handling dysfunctions, which are automatically detected and addressed.

Our study differs from David [3] in the point that we include exceptions that may not

be automatically detected, such as a salesperson declining customer requests. We also

try to identify some general patterns for reducing such exceptions to encourage

process-oriented improvement as well as facilitating innovation.

The few studies on the topic related with business process flexibility and adopt the

workflow perspective [4], [5], [6], [7]. Flexibility is defined as the ability of business

processes to respond to changes in their operating environment without necessitating

a complete redesign of the underlying process definition [4].In most of these studies,

business processes are realized by runtime-bounded activities [8]. Nataliya [4]

described flexibility in terms of four aspects: flexibility by design, flexibility under

specification, flexibility by deviation, and flexibility by change. Among them,

flexibility by design refers to “the ability to incorporate alternative execution paths

within a process definition at design time allowing for selection of the most

appropriate execution path to be made at runtime for each process instance depending

on the circumstances encountered [4].” The other three studies related to business

process instance run time bounding issues, will be omitted in this research since they

are out of our scope. Expected exceptions can be handled easily when processes have

high flexibility. However, authors argue that it is difficult to analyze exceptions from

the workflow perspective because:

(1) Workflow is an implementation level method, which is difficult to provide a

complete view for analyzing the causes of exception.

(2) Communication features such as commitment and feedback loop (e.g.,

decline, reject, cancel) are omitted in workflow perspective..

2.2 Ontological Model-DEMO

Ontological model is a model of system‟s construction that is completely independent

of the way in which it is realized and implemented. Implementation model is an

implementation of ontological model by engineering process, which is not a matter of

creativity but of craftsmanship.

Figure 1.The role of ontology in the construction of a system

Unwanted exceptions are implementation level issues. However, it will be helpful

for further understanding the reason of exceptions to find proven solutions by

identifying whether it is an engineering oriented problem in implementation level or a

construction-oriented problem on ontological level. DEMO [1] is an ontological

model abstracted from all realization and implementation issues to show only the

essence of the operation in an enterprise. It analyzes an enterprise as social entity that

constructed of cooperate and responsible actor roles, as well as communicate and

produce action sequences between the actor roles. Some key concepts in DEMO are

specified as follows:

Transactions: Transaction is defined in DEMO as a sequence of coordination acts

and production acts between two actor roles that aimed at achieving a well-defined

result.

Actor role: Actor role represents the operating unit of an organization, specified by

its rule base. Actor roles are the initiators and executors of transactions.

Actor: Actor is the active element of an enterprise. Actor is authorized to fulfill

actor role/roles by taking actor role‟s responsibility and competence.

Action rules: Action rule is defined in Action Model in DEMO to guide the actors

in dealing with their agenda.

Authors argue that DEMO can become a good methodology because of its

complexity reducing ability and human central specification, to analyze exceptions if

it can be somehow extended an specified in implementation level as well. In practice,

when exceptions happen, the actors who play the actor roles often have different

authorities and follow different rules. At the same time, other actor roles may be

involved in coping with or preventing from exceptions. Even if the transactions are

not changed on ontological level, some changes might still occur: action rules might

be modified; the authorities of actors who play the actor roles may change. Authors

want to identify these changes in different model and examine how these changes can

reduce exceptions in this research.

3 Hypotheses for Reducing Exceptions

Based upon our pre-research and amount of case investigation, authors generate three

main hypotheses for reducing exceptions.

Hypothesis1. Involve new transactions and corresponding actor roles in ontological

level may reduce exception.

Some exceptions are generated because the construction method of enterprise

could not support the changing requirement in implementation level. Therefore, it

may be useful to add new transactions into the current structure. We classify

transactions into three types according to their functional difference, as follows:

(1) Pre-decision/management Transaction: Internal transaction, which is somehow

linked to the internal initiator of problem transaction to prevent from

exceptions by pre-decision or management method.

(2) Supportive Transaction: Internal transaction, which is added to the internal

executor of problem transaction to prevent from exceptions by supportive

functions.

(3) New Service Transaction: Boundary transaction, which is added to the external

initiators as some provided services. Internal transaction is moved to the

boundary to provide additional services to the external parties. This is also a

methodology for reducing exceptions by providing more services to the

stakeholders.

Based on the classification, authors generate three sub-hypotheses (shown in

Table 1.) from above mentioned perspective:

Hypothesis1 (a). When initiator of transaction is inside boundary, add pre-

decision/management type transaction inside boundary might reduce exceptions.

Hypothesis1 (b). When executor of transaction is inside boundary, add supportive

type transaction to the executor of transaction might reduce exceptions.

Hypothesis1 (c). Provide additional service to outsiders as a boundary transaction

might reduce exceptions.

Table1. Hypothesis 1: involve new transactions and actor roles to reduce transaction

Initiator Executor

Executor Assertion Initiator Assertion

Add to

Executor

Add to

Initiator

Add to

Executor

Add to

Initiator

External

Actor

Internal

Actor

H 1(a)

Supportive n/a1 n/a2 H 1(c)

New service

Internal

Actor

External

Actor n/a3

H 1(b)

Pre-decision/

Management n/a4 n/a5

Internal

Actor

Internal

Actor

H 1(a)

Supportive

H 1(b)

Pre-decision/

Management n/a6 n/a

2

Hypothesis2. Verify the actor‟s responsibility in implementation level may reduce

exceptions.

An actor role represents the execution unit of a transaction, as well as the initiation

unit of sub-transactions from the ontological level. However, actors who play the

actor role in implementation level will bring different capabilities, accessible

resources, and authorities into the practical process. This suggests that different actors

who play the same role may reach different results even in the same ontological

construction. Thus, authors generate two sub-hypotheses as follows:

Hypothesis2 (a). If there is an indeed authority expansion of the role with new

action rules and increased responsibilities on ontological level, with which the

previous actor could not fulfill. Then the adjustment and/or expansion of actors who

play the role with adjusted and/or expanded authority may reduce exceptions.

Hypothesis2 (b). If there is no indeed authority expansion of the actor role on

ontological level, the implementation level adjustment of actors who play the role

may also reduce exceptions if the actor takes helpful authority of the other actor role

at the same time.

For example, when a salesperson plays the actor role of order completer, he or she

is more likely to decline an order when new products and/or services not offered by

the company is requested because he or she only has the authority to sell existing

goods and services. However, when a manager plays the role, since he or she can also

1 DEMO is focusing on inside boundary transactions. So we omit add executor to external

actor roles. 2 An elementary actor does not allow being an executor of more than two transactions. 3 DEMO is focusing on inside boundary transactions. So we omit add executor to external

actor roles. 4 No such case can be assumed. 5 An elementary actor does not allow being only an initiator. 6 It is assumed „self-initiate‟ type of transaction, however it is not assumed that this type of

transaction exists regarding the characteristic of exceptional transaction.

play another actor role as production manager, he or she therefore has the authority to

ask the developer to develop new products and/or services to reduce declines.

Hypothesis3. Ensuring complete information in communication loop on

implementation level might reduce exceptions.

Exceptions often occur when information is not effectively shared among the right

stakeholders or information used in communication loop is incomplete. Incomplete

information for making the decision will make the commitment of communication

loop invalid and causes exceptions. To ensure information completeness, it is

important to clarify who will use what information at what time in the communication

loop. However, the complementation is on implementation level, hence without any

change on ontological level.

4 Research Design and Method

We employed the case study method [9], [10] and studied a single case. The unit of

analysis consisted of a whole business process of a Japanese company named

Sangikyo Corporation before and after business process redesign. We collected data

through interviews of five representative officers and secondary data such as fifty two

pages workflow diagrams from May 2011 to June 2011.

The collected data were analyzed mainly by creating Actor Transaction Diagram

(ATD). ATD is one of the six DEMO diagrams, which provides a method for

analyzing the transactions in a company through abstraction and by reducing

complexity. We analyzed the solutions of redesign one by one to justify our

hypotheses for reducing exceptions. The analyses were validated in review meetings

with the executives of the company.

5 Case Study

5.1 Company Description

Sangikyo Corporation was founded in 1965 as a company that deals with engineering

services and/or goods for communication maintenance. Sangikyo Corporation has

managed many large IT infrastructure projects for several major Japanese

telecommunication carriers [11]. It currently has about 1,100 employees. The high-

speed expansion led problems, such as more and more customers cannot be satisfied

for their special requirement. To solve the problem, company shifted from product-

centered to customer-centered to provide customized services in the business model.

Some exceptions occur because product-centered business processes are not suitable

and flexible enough to support customer-centered business model.

Processes. Sangikyo Corporation operates three types of businesses. First type is

related to “construction by contract.” When Sangikyo Corporation receives an order

from customers, the company will design, construct, and purchase necessary materials

and/or services from external constructors and/or vendors. These activities are usually

carried out on the site of Sangikyo Corporation. After the construction is completed,

the company requests the customer to inspect and accept the deliverables. When the

customer accepts the deliverables, an invoice will be issued and payment will be

requested.

Second type is “on-site delivery.” This is different from the previous type in the

point that tasks are carried out on the site of the customer.

Third type is “supplying temporary service provider.” In this type of business,

Sangikyo Corporation supplies the employees with specific skills and/or general skills

for supporting customers‟ activities. Customers who do not have enough or necessary

staff to complete their activities will request Sangikyo Corporation for support.

Problems before re-design. While Sangikyo Corporation is expanding, the following

problems have been hindering their growth:

Increasing declines to customers‟ requirement decreases customer satisfaction as well

as company income: In a traditional production centered business process, a

salesperson has the authority to focus on selling only existing products and/or services.

When a new product and/or service is ordered, they often decline the order. A

salesperson sometimes may ask the designers in the organization about the possibility

of fulfilling the order. If the designer declines the request, the company will decline

the customer. Occasionally, a salesperson may decline a customer‟s order due their

inability to understand the specification. For example, a salesperson may decline an

order when he or she is not sure whether the skill of its dispatched workers can fulfill

the request from customer.

The company cannot detect the risks of promising to a request and it is important

to avoid unnecessary risks: Traditional processes require project managers to depend

on their personal knowledge. Without fully control the statue of its downstream, it

may be risky to promise to a request if its stakeholders cannot fulfill the order in time.

Managers need to control the issues and risks from multiple viewpoints, such as

corporate management, operations, and project management.

Meanwhile, the company needs to ensure high quality of their production and/or

services.

5.2 Re-Analyzing by DEMO ATD

Based on the data collected in our interviews, authors model the business processes in

Sangikyo Corporation using ATD as shown in figure 2. Corresponding transaction

result table is shown in table 2.

Their problems are also analyzed with the ATD model and be concluded into six

cases. All the cases have practical solutions, developed by their redesign process. We

will re-consider these solutions from DEMO perspective to verify our hypotheses.

The cases are classified by whether it is decline or rejection of a transaction.

Figure 2. Comprehensive business processes of Sangikyo Corporation using ATD

Table 2. TRT table in Sangikyo Corporation

5.3 Solutions for Reducing Exceptions Based on ATD

Reducing Declines in Sangikyo Corporation. Case1 stands for internal executor‟s

decline in a transaction between an external actor and an internal actor: the initiator is

an external actor and the executor is an internal actor. When a customer requests for a

new product and/or service, which Sangikyo Corporation has never provided, or a

product and/or service that include specifications that are difficult to fulfill, the

salesperson usually declines the order because the request is a kind of exception. In

addition, when the salesperson is not sure whether the skills of the temporary servicer

who will be assigned to complete the order can fulfill the specification, the

salesperson also usually declines the order to avoid trouble resulting from the

mismatch with the specification later. To reduce such declines, Sangikyo Corporation

Sangikyo Corporation

Customer

01CA

OrderCompletion

01TOrder

Completer

01A

Design

02TDesigner

02A

Work Plan

03TWork

Controller

03A

Work

04TWorker

04A

Construction Machine Delivery

08TMachineDeliverer

07A

MaterialsOrder

09T

MaterialController

08A

Material Shipment

11TWarehouse

09A

Sub-Construction

Order

05T PurchaserFor

Construction

05A

Sub-Construction

06T

Sub-constructor Payment

07TConstruction

Manager

06A

Material Delivery

10T

Material SupplyOrder

12T

CustomerSupplyOderer

10A

Customer Supply

13TMaterialManager

11A

Vendor Payment

T14

Sub-Construct

or

02CA

Vendor

03CA

dispatched

15TTemp

Servicer

12A

carried out the following solutions:

Solution1: Instead of allowing a salesperson to play the actor role (A01) and sell

only existing products and/or services, a sales manager can propose what Sangikyo

Corporation is capable of doing based on the request for proposal (RFP) from a

customer plays the actor role.

Solution2: A sales manager asks a developer to develop the new product the

customer requested.

Analysis: Two of our hypotheses H1(b) and H2(b) are included. Firstly H1(b): a

new transaction “T11”, initiated by actor role (A13) “production manager” for

developing new products, is added on ontological level to prevent from declining

customer order when ordered products do not exist. Secondly H2(b):when a

salesperson plays the actor role of order completer, he or she is more likely to decline

an order when new products and/or services not offered by the company is requested

because he or she only has the authority to sell existing goods and services. However,

when a manager plays the role, he or she at the same time plays another actor role as

“production manager”, has the authority to ask for the development of new products

and/or services and these solutions may therefore reduce declines on implementation

level.

Solution3: Especially in case of providing temporary servicer (A11), a customer

(CA01) verifies a temporary servicer to check whether they can fulfill their

requirements.

Analysis: An internal actor role (A12) is linked with customer for providing a new

service to customer. Internal transaction is moved to the boundary to provide

additional services to the external parties. This is also a methodology for reducing

exceptions by providing more services to the stakeholders.

Table 3 shows Case 1 and solutions.

Table 3. Case 1 and solutions

H1(a) H1(b) H1(c) H2(a) H2(b) H3

Case 1 n/a

S2

S3

n/a

S1: Actor

who plays

role “order

completer”

also plays

another role

as

“production

manager”.

n/a

Result n/a R16: New production P is

developed.

R17: Temp Servicer

TS is verified by

customer.

n/a n/a n/a

Case2 stands for internal executor‟s decline in a transaction within the

organizational boundary. When a customer (CA01) requests an order with a

specification that is difficult to fulfill, the order completer (A01) usually declines the

order because the designer (A02) is likely to decline in T02. However, the following

Customer

01CA01T

OrderCompleter

01A

ProductManager

13A

BasicDesign

Developer

14A

solutions for reducing the decline of the order from A02 are observed to be done in

Sangikyo Corporation.

Solution4: The order completer (A01) asks a basic designer (A15) to do basic

design and estimate the feasibility of the order before the designer (A02) make

promise or decline for the order.

Analysis: a pre-decision/management transaction (T18) is added to initiator of

transaction T02, to prevent actor role A02 from generating exception (decline an

order).

Solution5: An order completer (A01) requests for approval of the board to prevent

the designer (A02) from declining a strategic deal. Some of the orders, for example

larger than $10,000, could not be easily declined even if it is difficult for designer. In

such situation, the board of committee in Sangikyo Corporation will decides whether

the request from customers is acceptable or not, according to the basic designer‟s

estimation of the cost and feasibility for such orders.

Analysis: Authors consider this solution as H2 (a), the expansion of actor role

(A01) “order completer,” from {salesperson} to {salesperson, board}. It is an indeed

expand of actor authority which change the responsibility of actor role A01.

Table 4. Case 2 and solutions

H1(a) H1(b) H1(c) H2(a) H2(b) H3

Case 2 n/a n/a

S4

S5: From

{salesperson} to {salesperson, board}

Rule change: if the

order> $10,000 then

it could not be

declined by designer

but promised or declined by board.

n/a n/a

Result n/a n/a R18. Feasibility of order O is

established. n/a n/a n/a

Case3 stands for external executor decline a transaction: In case that initiator is

internal actor and executor is external actor. A constructor (CA02) is required to

construct by Sangikyo Corporation, but the constructor cannot always afford to fulfill

the specificity, which may lead delayed-delivery to the customer.

Solution6: A constructor (CA02) asks detail information of the task and/or

negotiates due date with Sangikyo Corporation in advance.

Analysis: It is an implementation level complication of information in

communication loop for transaction T06, in its order phase. Action rule and

information requirement are specified in ontological level, however not implemented

correctly. The information for making the promise is incomplete in the process before

improvement. This incompleteness not only makes the commitment of

communication loop invalid, but also causes exceptions. To ensure information

completeness, it is important to clarify who will use what information at what time in

the communication loop.

Solution7: A purchaser (A05) in Sangikyo makes an arrangement to share the

tasks with another division inside Sangikyo Corporation.

Analysis: It is an implementation level change, by which the information can be

shared among necessary actors. This change is caused by an implementation choice,

namely that one actor role is implemented by a collective of subjects (two divisions in

the company, in this case)

Solution8: A purchaser (A05) in Sangikyo asks the constructor for a feasible

proposal to fulfill the specificity.

Analysis: This is also an information level complication of communication loop

for transaction 06, in order phase. Action rule and information requirement are

specified, however not implemented correctly. The information for making the

promise is incomplete in the process before improvement.

Table 5 shows Case 3 and solutions.

Table 5. Case 3 and solutions

H1(a) H1(b) H1(c) H2(a) H2(b) H3

Case 3 n/a n/a n/a n/a n/a S6/S7/S8

Result n/a n/a n/a n/a n/a n/a

Reducing Rejections in Sangikyo Corporation. Case4 stands for external initiator’s

reject in a transaction between internal actor and external actor: initiator is external

actor and executor is internal actor. A customer (CA01) rejects the state from

Sangikyo Corporation due to the mismatch of the deliverables with the initial contract.

The reason why such mismatch would often occur is that it is almost impossible to

define the detail tasks, scope and schedule in advance, as one of the characteristics of

the transaction between Sangikyo Coporation and the customers. Hence, the

following solutions for reducing reject are observed to solve these issues between

Sangikyo Corporation and the customers.

Solution9: Sales manager asks an internal auditor to ensure the quality to reduce

the rejection from customer.

Analysis: A supportive transaction (T19) is added to executor of transaction T01 to

prevent from exceptions. A sales manager plays both “order completer” and “quality

manager” in this case to ensure the quality of the order delivery. Table 6 shows Case4

and solutions.

Case5 stands for an internal initiator’s reject in a transaction inside the boundary.

An order completer (A01) recognized that the deliverables would not fulfill the

specification from the customer (CA01), the order completer (A01) usually rejects

state from the designer (A02). However, the solutions for reducing the reject of the

state are observed to be done in Sangikyo Corporation.

Solution10: A designer (A02) requests a proven and/or experienced designer to

help improving the quality to fulfilling the specificity of the customer (CA01).

Analysis: A supportive type transaction is added to designer (A02) to prevent from

exceptions.

Solution11: A process manager is asked to do process improvement to ensure the

design quality.

Analysis: A pre-decision/management type transaction is added to prevent from

exceptions.

Table 7 shows Case 5 and solutions.

Table 6. Case 4 and solutions

H1(a) H1(b) H1(c) H2(a) H2(b) H3

Case4 n/a

S9

n/a n/a n/a n/a

Result n/a R19. Quality of order O is audted. n/a n/a n/a n/a

Table 7. Case 5 and solutions

H1(a)

H1

(b)

H1

(c)

H2

(a) H2(b) H3

Case5

S11

n/a n/a n/a

S10

n/a

Result R21: Design Process PRO of Order

O is improved. n/a n/a n/a

R20: Design D for order O is

improved. n/a

Case6 stands for an internal initiator’s reject in the transaction between internal

actor and external actor: initiator is internal actor and executor is external actor. A

purchaser for construction (A05) rejects the states from the constructor (CA02) due to

the mismatch of the deliverables with the initial contract. As mentioned in case 4, the

reason why these mismatch would often occur is that it is almost impossible to define

the detail tasks, scope and schedule in advance, as one of the characteristics of the

transaction between Sangikyo Corporation and the constructors. Hence, the following

solutions for reducing the reject are observed to solve these issues between Sangikyo

Corporation and the constructors.

Solution12: A purchaser (A05) requests the work planner to narrow the scope,

reducing the price of the contractor (CA02) and/or change the task of the constructor

(CA02) according to the ability.

Analysis: A pre-decision/management type transaction T22 is added to purchaser

(A05) to prevent from exceptions.

Table 8. Case 6 and solutions

H1(a) H1(b) H1(c) H2(a) H2(b) H3

Case6

S12

n/a n/a n/a n/a n/a

Result R22. Contract CT is planned. n/a n/a n/a n/a n/a

Through investigating the case study, we found that 1) Three of the exceptions is

solved in implementation level by complementation of information in communication

loop (S6, S7, S8), 2) Two of the exceptions are solved by expanding or verifying

actor of actor role (S1, S5), 3) Seven of the exceptions are solved in ontological level

by verifying the construction (S2, S3, S4, S9, S10, S11, S12). In these solutions, pre-

decision and/or management transactions are always added to the initiator of the

problem transaction to prevent from exceptions. In addition, supportive transactions

are accessed with the executor of problem transaction to expand existing solutions to

prevent from exceptions. The result somehow proved that our hypotheses could be

useful to analyze the exceptions by using DEMO methodology.

5.4 Efficiency of using DEMO ATD

The workflow diagram of Sangikyo Corporation was described in fifty-two pages. For

example T01: order was three pages, T02: design was two pages and T06:

construction order was two pages. After applying ATD, a comprehensive description

of the business process becomes only one page. ATD reduces by almost 90%.

6 Discussion

6.1 Business model

A business model describes how a business positions itself within the value chain of

its industry and how it intends to sustain itself, which is to generate revenue [12]. It

includes strategy model, value model, revenue model, resource model in most of

related researches [12].

As authors mentioned before, Sangikyo is shifting in the business model to obtain

more revenue from providing customized service, which need organizational principle,

structure and process new to product centered model. By analyzing the ATD of

Sangikyo Corporation, we recognize that the responsibility of a salesperson (who

plays the actor role A01 as the executor of transaction T01) before the improvement

was only selling existing product. He or she only provided or received information

from other related actor roles to complete the order.

When a business model changes from production-centered to customer-centered,

the actor role of A01 also changes from a task executor to a service provider. The

biggest difference between these two is that a task executor needs to finish his or her

assigned task passively while a service provider need to coordinate all the resources in

order to provide the service actively. Although the name of actor role A01, “order

completer” remains the same, the responsibility of A01 expanded from “selling

products for completing the order from customers” to “selling products and providing

possible services for fulfilling the requirements of customers”. Correspondingly, it

required the actor who play the role owns more authority and better ability to

coordinate more resources to actively provide services.

6.2 DEMO and Flexibility

DEMO defined construction of system in ontological level. Business process

flexibility is an implementation level concept, and the ability of business processes to

respond to changes without necessitating a complete redesign of the underlying. This

can also be expressed with ontological model and implementation model. Flexibility

can be realized if implementation model can be linked with ontological model.

When an actor plays the actor role, he or she will bring his or her own resources,

authorities and processes into the whole process defined as the ability of business

processes to respond to changes in their operating environment without necessitating

a complete redesign of the underlying. This may provide a bridge between ontological

model and implementation model, hence realize business process flexibility.

7 Conclusion and Future Research

This paper explained how the DEMO methodology could be used for reducing

exceptions in a company. Authors proposed three hypotheses and verified by 6 cases

from the case study on a traditional Japanese company. Therefore, authors would like

to call these hypotheses “patterns for reducing exceptions”. By re-analyzing the whole

business process, problems, and solutions from the DEMO perspective, we identified

that the three patterns could be helpful for reducing exception.

Limitation of this research is that only six cases in one company are examined.

Therefore, more researches should be performed to assess the quality of proposed

patterns. Meanwhile, the patterns need to be assessed in more cases to address that the

patterns are common reoccurring problems.

Furthermore, authors analyzed why exceptions might occur. Specifically, we

identified business model change from production-centered to customer-centered by

analyzing actor change in implementation level and structure change in ATD in

ontological level. Such changes may be an interesting research topic for future work.

For example, “How will the ontological model and implementation model change

when business model change?” We will examine these questions in future research.

Acknowledgement

The authors thank Sangikyo staff who kindly dedicated to our research works.

References

1. Jan L. G. Dietz: “Enterprise Ontology: Theory and Methodology”, New York:

Springer-Verlag New York Inc(2006)

2. Terry Winograd, “A Language Action Perspective on the Design of Cooperative

Work”, Proceedings of the 1986 ACM Conference on Computer-Supported

Cooperative Work, Austin, Texas: pp. 203. 220 (1986)

3. David Sardinha Andrade de Aveiro, “G. O. D. (Generation, Operationalization &

Discontinuation) and Control (sub) organizations: a DEMO-based approach for

continuous real-time management of organizational change caused by exceptions,

Doctoral Dissertation: Department of Computer Science and Engineering,

Instituto Superior Técnico, Technical University of Lisbon, Portugal (2010)

4. Nataliya Mulyar, et al “Process Flexibility Patterns” Technische Universiteit

Eindhoven(2008)

5. Adla Bentellis, and Zizette Boufaïda, “Conceptual Method for Flexible Business

Process Modeling, ” Proceedings of World Academy of Science, Engineering and

Technology, Vol. 27, pp. 302-306(2008)

6. Peter G. W. Keen, “The Process Edge – Creating Values Where It Counts”, New

York, Boston: Harvard Business Press(1997)

7. G. Regev and A. Wegmann. “A regulation-based view on business process and

supporting system flexibility. In Workshop on Business Process Modeling,

Design and Support (BPMDS05), ” Proceedings of CAiSE05 Workshops, pp. 35–

42(2005)

8. F. Daoudi and S. Nurcan, “A benchmarking framework for methods to design

flexible business processes, „software Process Improvement and Practice, Vol.

12, pp. 51–63(2007)

9. Eisenhardt, K. M. . Building Theories from Case Study Research. Academy of

Management Review, 14(4), pp. 532-550 (1989)

10. Yin, R. K. Case study research: Design and methods (2nd ed. ). Sage

Publications (1994).

11. Sangikyo Corporation Website; http://www. sangikyo. com/ (Nov 20th

, 2011)

12. Rogelio O. and Robert K. `Managing the transition from products to service.

International Journal of Service Management, vol. 14, No. 2, pp.160-172 (2003)