a study of the patterns for reducing exceptions and improving business process flexibility
Skip this Video
Download Presentation
A Study of the Patterns for Reducing Exceptions and Improving Business Process Flexibility

Loading in 2 Seconds...

play fullscreen
1 / 24

A Study of the Patterns for Reducing Exceptions and Improving Business Process Flexibility - PowerPoint PPT Presentation

  • Uploaded on

A Study of the Patterns for Reducing Exceptions and Improving Business Process Flexibility . EEWC 2012 07th, May, 2012. Sanetake Nagayoshi 1 , Yang Liu 1 , Junichi Iijima 1. Content. 1. Background 2. DEMO for exception handling 3. Hypotheses 4. Research Method 5. Case Study

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'A Study of the Patterns for Reducing Exceptions and Improving Business Process Flexibility' - vince

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
a study of the patterns for reducing exceptions and improving business process flexibility

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,


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
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

1 2 starting from exception handling
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.
1 3 research problem and question
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)

2 demo for e xception handling
2. DEMO for Exception Handling





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)
3 hypotheses
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
3 1 hypothesis1 1
3.1 Hypothesis1 (1)




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

3 1 hypothesis 1 2
3.1 Hypothesis 1 (2)

Hypothesis 1 is logically derived and MECE

(Mutually Exclusive and Collectively Exhaustive)

3 2 hypothesis 2
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
3 3 hypothesis 3
3.3 Hypothesis 3

Change how to do it.

Hypothesis 3: Ensuring complete information share among shareholders mightreduce exceptions.

4 research method case study
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
5 case study sangikyo
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
5 3 cases
5.3 Cases
  • Each case represent a type of exception
5 4 case 1 h2 b h1 b
5.4 Case 1 (H2(b),H1(b))












  • 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)
5 5 case 2 h2 a
5.5 Case 2 H2(a)
  • Problem:
    • Sometimes order completer will decline customer’s requirement because designer will decline.


    • 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
5.7 Case 3 (H3)
  • Problem:
    • constructor sometimes can not afford sangikyo’s specificity, which leads to sangikyo’s delayed- deliver


    • 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 h ypotheses mapping
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.

6 discussion
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
7 conclusion
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.
8 limitations and future work
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.