Warning: Creating default object from empty value in /home/johnnz/public_html/wp-content/themes/simplicity/functions/admin-hooks.php on line 160

Procedure Modelling eBook

New eBook on Business Procedure Modelling

I am just starting to write Procedure Modelling, the fifth book in the series for the Integrated Modelling Method and would welcome your input.

I have included an outline of the proposed contents of the book below and would appreciate your feedback on it.

Is there any element of Procedure Modelling that you think I have missed and that you would like to see included in the book?

Have you got any special “tricks” that you have learned about Procedure Modelling that you would like to share with others? All original ideas that are included in the book will be fully attributed.

Leave a comment in the box at the bottom of this post or e-mail me at john@johnowensblog.com

Purpose of Procedure Modeling eBook

The purpose of this book is to:

  • Define Business Procedure Modelling and how it differs from Business Process Modelling
  • Define the elements of a Business Procedure:
    • Triggers and Outcomes
    • Controls
    • Method
    • Knowledge & Skills
    • Resources
    • Evidence
  • Aligning Procedure Triggers & Outcomes and to Process Triggers & Outcomes
  • Decomposing Procedure Triggers & Outcomes
  • Aligning Procedure Triggers to Mechanisms (Mechanisms are the HOW for Business Functions)
  • .
    decomposed-triggers

  • Business Procedure controls, including:
    • The standards to be used when executing the step.
    • The risk associated with step and the necessary mitigation.
    • The authorities required to execute the step.

Business Procedure Modelling: The Method

The overall method for Business Procedure Modelling entails defining:

  • The valid mechanism(s) for each step in the process.
  • The Function logic for each step. (This may be further defined by a Work Instruction).
  • The responsibilities for the execution of each step.
  • The valid outcomes for the Procedure.
  • For each Procedure Step:
    • The Knowledge, Skills and Competencies required.
    • Resources required, including:
      • Plant or equipment
      • Tools
      • Hardware
      • Applications
      • Technology
    • Evidence to:
      • Ensure that the step is being properly executed.
      • Be able to demonstrate that it has been properly executed at any later date.

Diagramming the Business Procedure

This will cover defining:

  • The elements of the Procedure diagram
  • Tuning the Procedure using the diagram
  • The use of Swim Lanes for roles, locations, technology, etc.
  • Beyond Procedure

    Once a procedure has been mapped the enterprise can the define:

    • Work instructions
    • Workflow

    Is there any element of Procedure Modelling that you think I have missed that you would like to see included in the book?

    Have you got any special “tricks” that you have learned about procedure modelling that you would like to share with others? All original ideas that are included in the book will be fully attributed.

    Return to Integrated Modelling Method Home Page

    Please enter any suggestions you have in the comments box below.  I look forward to hearing from you.

    Tags:

    7 Responses to “Procedure Modelling eBook”

    1. Adolfo Casari February 28, 2011 12:52 pm #

      Hi John,

      Is this ebook available?

      • john February 28, 2011 7:34 pm #

        Hi Adolfo

        Procedure modelling is not yet available. Working on the best format in which to publish it.

        Regards
        John

    2. Stuart Scott September 4, 2010 8:44 am #

      Hi John,

      I’m wondering how you distinguish procedures from processes, and why. Over the last 20 years, I’ve seen a lot of efforts to distinguish higher-level abstractions of work from lower-level, more discrete tasks. For me, what matters is choosing an appropriate tool to express the “how” of a unit of work. Sometimes a simple context diagram with descriptive text is enough. In other cases, a detailed expression of every action and every decision is appropriate.

      In summary, I’m glad to see you undertaking this project, and I hope to learn more about how you would like book to be used.

      • John Owens September 5, 2010 6:01 pm #

        Hi Stuart

        There is a distinct difference between Process and Procedure (other than the level of detail) and it is vital to be able to make this distinction. Sadly, most of the “process” modelling software in the market place is actually only suitable for modelling Procedure. Also, many BPM practitioners are not aware of the difference and model the wrong thing.

        So what is this difference? It all starts with Business Functions, which are the core activities of ALL businesses. Business Functions are WHAT the business OUGHT to be doing independently of how it does it or the order in which it does it.

        The means by which a Business Function is executed is called a Mechanism. Mechanisms are the HOW. Let’s take the Business Function “Accept Customer Order” as an example. This can be done by several mechanims, for example, over the phone, by fax, by e-mail or as an on-line web transaction.

        Now lets go to a Business Process. This is the definition of the sequence in which Business Functions must be carried out in response to a Trigger in order to arrive at a Preferred Outcome.

        As Mechanisms are the HOW for Function, so Procedure is the HOW for Process.

        This is merely a summary of the essential differences. All of them, and how to manage them, are defined in full detail in the Function Modelling eBook and the Process Modelling eBook.

        I hope that this helps. Please do not hesitate to contact me if you have any further questions.

        Regards
        John

      • Daveigh July 6, 2011 4:20 pm #

        Never would have thunk I would find this so iidnspnesable.

    3. Robert Starinsky September 2, 2010 1:52 am #

      John:

      You’ve developed a robust table of contents. Several suggestions to consider in your manuscript development efforts include:

      The use of the ‘playscript’ format in procedure wrting.

      The struturing of procedures using short, action oriented sentences.

      The relationship between business rules and procedures.

      How to spot a good/bad procedure.

      How to troubleshoot an errant procedure – i.e. a process fails when a procedure is not followed – so how do you determine the root cause of a procedure’s failure.

      The role of checklists in procedures.

      Warmest Regards,

      Bob

    4. Andrew Warner September 2, 2010 12:57 am #

      Hi John,
      it looks comprehensive, well done. The number of process models that are just boxes and lines with no detail and none of the myriad other elements that make up work is astounding.

      One thing, perhaps in the weeds, is dealing with changes in multiplicity. For example, imagine a distribution step where work is balanced across several “workers” by a front of line sorter. It might flow on to the work done by the individual worker on a single item. Then it might be batched again for distribution or archiving etc.

      The only notation I’ve seen that handles this nicely is the detail process charting of the Ben Graham corp. There main web site is http://www.worksimp.com/

      Kind Regards,
      Andrew.

    Leave a Reply