A Study of the Patterns for Reducing Exceptions and

Improving Business Process Flexibility

Sanetake Nagayoshi1,

Yang Liu1,

Junichi Iijima1

EEWC 2012

07th, May, 2012

[1] Department of Industrial Engineering and Management , Graduate School of Decision Science and Technology, Tokyo Insutitute of

Technology,

Content

2

1. Background2. DEMO for exception handling3. Hypotheses4. Research Method5. Case Study6. Discussion7. Conclusion8. Limitation and Future Work

1. Background1.1 Exception

3

Dictionary: Exception is “Someone or

something that does not behave in the expected way”. [2]

Java Programming: An exception is an event, which

occurs during the execution of a program, that disrupts the normal flow of the program's instructions.[3]

Exception: Events that prevent business

process from moving forward smoothly until they are handled. exceptions include:

Decline of request Rejection of statement

[1] Cambridge advanced learner`s dictionary 3rd edition (2008).[2]

http://docs.oracle.com/javase/tutorial/essential/exceptions/definition.html

1.2 Starting from Exception Handling

4

Exception leads to: Reduced organization efficiency (negotiation

and rework time and cost waste); Lost opportunity (if customer quit or cancel

request); Decreased customer satisfaction level

Starting from handling exception, we can…… Discover immature business process that can

not fulfill customer’s requirement. Find opportunities for business process

oriented improvement and trigger business process oriented innovation.

1.3 Research Problem and Question

5

Existing Problems: Existing papers for exception handling are strongly

related with flexibility, from workflow viewpoint [4].

However the deliverables based on workflow are too complex to be understood and difficult to used in practice

Our objective is to find easier way to analyze and handle exception without getting into details.

Research Question:How can exception be analyzed and handled in conceptual level?

[2] Bentellis, and Boufaïda, “Conceptual Method for Flexible Business Process Modeling”, Proceedings of World Academy of Science, Engineering and Technology, Vol.27, pp.302-306(2008)

Exceptions are difficult to analyze

2. DEMO for Exception Handling

6

DEMO can be used for exception handling, because it has: Complexity reducing capability; Human central specification; Communication loop based construction.

Some key concepts in DEMO for exception handling

Actor Role: operating unit of an enterprise (responsibility)

Actor : authorized to fulfill actor role (who) Transaction: a sequence of c-act and p-act between two

actor roles (what)

TransactionInitiator

Actor

Executor

Who take which responsibility for what?

3. Hypotheses

7

How can exception be handle on conceptual level?

We have three meta hypotheses and 6 sub-hypotheses Hypothesis 1-- Change what to do

Sub-hypothesis 1 (a) Sub-hypothesis 1 (b) Sub-hypothesis 1 (c)

Hypothesis 2-- Change who do it Sub-hypothesis 2 (a) Sub-hypothesis 2 (b)

Hypothesis 3 -- Change how to do it

H 1. Involve new transactions and corresponding actor roles in ontological level may reduce exception.

H1 (a) Pre-decision/management Transaction Add to initiator of transaction

H1 (b) Supportive Transaction Add to executor of transaction

H1 (c) New Service Transaction Add boundary transaction

3.1 Hypothesis1 (1)

8Change what to do

(a)

(b)

(c)

3.1 Hypothesis 1 (2)

9

Initiator ExecutorExecutor Assertion Initiator Assertion

Add toExecutor

Add toInitiator

Add toExecutor

Add toInitiator

ExternalActor

InternalActor

H 1(b)Supportive

n/a n/aH 1(c)

New service

InternalActor

ExternalActor

n/aH 1(a)

Pre-decision/Management

n/a n/a

InternalActor

InternalActor

H 1(b)Supportive

H 1(a)Pre-decision/Management

n/a n/a

Hypothesis 1 is logically derived and MECE(Mutually Exclusive and Collectively Exhaustive)

3.2 Hypothesis 2

10

Verify the actor’s responsibility may reduce exceptions.

H2 (a): indeed authority expansion of actor role on ontological level

H2 (b): no indeed authority expansion of actor role on ontological level, but one actor play more actor roles in operational level

Change the responsibility an actor take

Action Rule of A02 changed

Actor plays more role

3.3 Hypothesis 3

11

Hypothesis 3: Ensuring complete information share among shareholders might reduce exceptions.

Change how to do it.

4. Research Method—Case Study

12

Interview from May 2011 to June 2011 Interview five officers Second hand data: fifty-two pages of workflow

diagram Reanalyze the case using DEMO ATD and TRT Reanalyze the solution of improvement to

verify our hypotheses

5. Case Study- Sangikyo

13

Three types of business construction by contract. on-site delivery supplying temporary service

provider Problems before re-design

Increasing declines to customers’ requirement

The risks of promising to a request Quality of their production and/or

services

5.1 TRT of Sangikyo

14

5.2 ATD Model of Sangikyo

15

Sangikyo Corporation

Customer

01CA

OrderCompletion

01T OrderCompleter

01A

Design

02TDesigner

02A

Work Plan

03T WorkController

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

13T MaterialManager

11A

Vendor Payment

T14

Sub-Construct

or

02CA

Vendor

03CA

dispatched

15T TempServicer

12A

5.3 Cases

16

Decline Reject

Internal Initiator

External Initiator

Internal Initiator

External Initiator

InternalExecutor

Case 2(Designer

decline order completer)

Case 1(Order

completer decline

customer)

Case 5 (order completer reject designer)

Case 4(customer

reject order completer)

ExternalExecutor

Case 3(constructor

decline purchaser)n/a

Case 6(purchaser

reject constructor)n/a

Each case represent a type of exception

5.4 Case 1 (H2(b),H1(b))

17

Problem:When customer requires for new service never provided, Sangikyo will decline because they do not have such experience.

Exception: Internal Executor (IE)declines

External Initiator(EI)

Solution: S1:manager+sales S2: new transaction

R&D Result:

S1 prove H2(b) S2 prove H1(b)

T16R&D

Researcher

14A

Production manager

13A

S2

S1

5.5 Case 2 H2(a)

19

Customer

01CA 01T

OrderCompleter

01A02T

Designer

02A

S5

10,000

Problem:Sometimes order completer will decline customer’s requirement because designer will decline.

Exception: Internal Executor (IE) declines Internal Initiator (II)

Solution:S5: When order >10,000, board will decide whether they should accept.

Result: S5 proves H2 (a)

5.7 Case 3 (H3)

20

S6

Problem:constructor sometimes can not afford sangikyo’s specificity, which leads to sangikyo’s delayed- deliver

Exception: External Executor (EE) declines Internal Initiator (II)

Solution:S8: a purchaser (A05) in Sangikyo asks the constructor for a feasible proposal to fulfill the specialty.

Result: S8 proves H3

5.8 Case and Hypotheses Mapping

22

Each case (e.g. Case 1) represents a type of exception (e.g. External Initiator declines Internal Executor(EI IE))

All the hypotheses are verified by solutions of cases.

Case H1: Ontological level change H2: Actor

H3:Implementation

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

Case 1(EI IE)

S1S2

S3

Case 2(II IE)

S4S5

Case 3(II EE)

S6S7S8

Case 4(EI IE) S9

Case 5(II IE)

S10S11

Case 6(II EE) S12

6. Discussion

23

Coping exception might lead to strategy transformation. For example: From production central to customer central Mindset change (from positive to active)

from “selling products for completing the order from customers”

to “selling products and providing possible services for fulfilling the requirements of customers”

Coping exception might trigger ontological level change; Construction change Rule of actor role change

Coping exception might drive operational level change Actor responsibility change (actor plays more roles) More effective and efficient information sharing

7. Conclusion

24

This paper proposed “six exception reducing patterns” by applying DEMO Six hypotheses are assumed for reducing

exception; These six hypotheses are examined by

Sangikyo`s cases; So we call these six hypotheses “exception

reducing patterns”; This paper also mentioned how coping with

exception trigger business process improvement and innovation in discussion part.

8. Limitations and Future Work

25

Limitations: Only six cases are examined and they all from one

company. More case studies should be performed to assess the quality of proposed patterns

It is still necessary to prove whether proposed patterns are complete set or not.

Future Work: More case studies for testing our proposed patterns. Research on how business improvement and

innovation can be connected with coping exceptions and how ontological model can support in analyzing hence changing process.

Find out ways to simulate and reason exception handing.

26