A Study of the Patterns for Reducing Exceptions and Improving Business Process Flexibility Sanetake Nagayoshi 1, Yang Liu 1, Junichi Iijima 1 EEWC th, May, 2012 [1] Department of Industrial Engineering and Management, Graduate School of Decision Science and Technology, Tokyo Insutitute of Technology,

Content 2 1. Background 2. DEMO for exception handling 3. Hypotheses 4. Research Method 5. Case Study 6. Discussion 7. Conclusion 8. Limitation and Future Work

1. Background 1.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 3 rd edition (2008). [2]

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 (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) 8 Change what to do (a) (b) (c)

3.1 Hypothesis 1 (2) 9 InitiatorExecutor Executor AssertionInitiator Assertion Add to Executor Add to Initiator Add to Executor Add to Initiator External Actor Internal Actor H 1(b) Supportive n/a H 1(c) New service Internal Actor External Actor n/a H 1(a) Pre-decision/ Management n/a Internal Actor Internal Actor H 1(b) Supportive H 1(a) Pre-decision/ Management 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

5.3 Cases 16 Decline Reject Internal Initiator External Initiator Internal Initiator External Initiator Internal Executor Case 2 (Designer decline order completer) Case 1 (Order completer decline customer) Case 5 (order completer reject designer) Case 4 (customer reject order completer) External Executor 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) T16 R&D Researcher 14A Production manager 1313A S2 S1

5.5 Case 1 H1 (c) 18 T 17 verify Temp servicer A12 S3 Problem: Order completer will decline customer order because he is not sure whether servicer have the capability to fulfill it. Exception: Internal Executor (IE)declines External Initiator (EI) Solution: S3: provides service to encourage customer (CA01) verify a temporary servicer by themselves. Result: S3 proves H1 (c)

5.5 Case 2 H2(a) 19 Customer 01CA 01T Order Completer 01A 02T 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 6 (H1(a)) 21 A05 Purchaser 0606T Const ructor CA02 T 22 Work plan Work planer A19 Problem: Sangikyo will reject constructor due to the mismatch of the deliverables with the initial contract Exception: External Executor(EE) rejects Internal Initiator(II) Solution: S12: 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 Result: S12 proves H1(a)

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.  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. CaseH1: Ontological level changeH2: Actor H3:Imple mentation H1(a)H1(b)H1(c)H2 (a)H2 (b)H3 Case 1 (EI IE) S1 S2 S3 Case 2 (II IE) S4 S5 Case 3 (II EE) S6 S7 S8 Case 4 (EI IE) S9 Case 5 (II IE) S10 S11 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