Embed Size (px)
Citation preview
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)
