A Study of the Patterns for Reducing Exceptions and Improving Business Process Flexibility

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

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

3. 1. Background1.1 Exception • 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

4. 1.2 Starting from Exception Handling • 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 improvementandtrigger business process oriented innovation.

5. 1.3 Research Problem and Question Exceptions are difficult to analyze How can exception be analyzed and handled in conceptual level? • 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: [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)

6. 2. DEMO for Exception Handling Initiator Transaction Executor Actor Who take which responsibility for what? • 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)

7. 3. Hypotheses • 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

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

9. 3.1 Hypothesis 1 (2) Hypothesis 1 is logically derived and MECE (Mutually Exclusive and Collectively Exhaustive)

10. 3.2 Hypothesis 2 Action Rule of A02 changed Actor plays more role Change the responsibility an actor take • 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

11. 3.3 Hypothesis 3 Change how to do it. Hypothesis 3: Ensuring complete information share among shareholders mightreduce exceptions.

12. 4. Research Method—Case Study • 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

13. 5. Case Study- Sangikyo • 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

14. 5.1 TRT of Sangikyo

15. 5.2 ATD Model of Sangikyo

16. 5.3 Cases • Each case represent a type of exception

17. 5.4 Case 1 (H2(b),H1(b)) A 13 Production manager T16 R&D A 14 Researcher S1 S2 • 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)

18. 5.5 Case 2 H2(a) • 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) CA 01 A 01 A 02 T 01 T 02 Order Completer Customer Designer 10,000 S5

19. 5.7 Case 3 (H3) • 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 S6

20. 5.8 Case and Hypotheses Mapping 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.

21. 6. Discussion • 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

22. 7. Conclusion • 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.

23. 8. Limitations and Future Work • 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.