Enabling Operational Excellence
<

COMPANY | Overview

X
>
Upcoming Events
Enabling Operational Excellence
<

SERVICES | Overview

X
>
Upcoming Events
Enabling Operational Excellence
<

WHO WE HELP | Corporations & Government

X
>
Upcoming Events
Enabling Operational Excellence
<

LEADERSHIP | Overview

X
>
Upcoming Events

TURNING OPERATIONAL KNOWLEDGE & COMPLIANCE INTO A COMPETITIVE EDGE

We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

To-Do Items, Checklists and Out-of-Tolerance Business Events … Business Process Problems?

Written by Ronald G. Ross on . Posted in Business Processes

Does a to-do item constitute a business process? No. Does a checklist constitute a business process? No. Does an out-of tolerance event constitute a business process? No. Analysis of the following case study illustrates. The take-away: “Process” shouldn’t be force-fit to every aspect of business operations. That kind of ‘Big-P process’ perspective as I frequently call it puts blinders on you. Case Study: An organization runs public conferences. In reaching an agreement with a hotel, it must commit to a room block of a certain size. If the conference does not fill the room block, it must compensate the hotel. The amount of the compensation is roughly equivalent to the cost of the number of room nights not filled. So it’s prudent to always guesstimate on the low side. Sometimes conference attendance exceeds expectations. If the hotel is already heavily booked for the conference dates (e.g., for other conferences), attendees will not be able to secure a hotel reservation. Not having a hotel room may naturally discourage them from coming. So it’s wise to constantly monitor the number of hotel reservations vs. the size of the room block. Once exceeded, provisions should be made immediately to secure more hotel rooms for attendees, often at a nearby hotel. Analysis: Business process problem? No. This is really an operational business event – in particular, a spontaneous event.
  • The operational business event is when hotel room block is exceeded. 
  • A business rule could be specified defining the appropriate conditions producing the operational business event. 
  • An appropriate response to the operational business event might be Notify conference organizer.
If detecting the spontaneous event via testing of the business rule and notifying the conference organizer can all be automated, fine. If not, monitoring the hotel room block should be assigned as a job responsibility for staff, possibly just one of many ‘checklist’ items to perform daily. Does a to-do item constitute a business process? No. A to-do item – or even a whole checklist – is not a business process! Each item is what it is, simply a job responsibility. Simply notifying the conference organizer is not a business process either. A business process needs to be something more substantial, like Secure additional hotel rooms. Tip for Business Analysts: To be a business process it’s not enough for someone to be informed, something must be transformed. After-the-Fact Settlement: What happens if the hotel registration overflow is not detected in real time? Nothing good! Suppose the hotel continues to accept reservations knowing they can be accommodated at near-by hotels. Now you need an additional business process: Handle hotel registration overflow. It’s a business process you’d rather not have(!). Transferring registrations to other hotels entails significant work and communication, leaving some registrants inevitably unhappy. Clearly you need a ‘fairness’ rule for who gets transferred – probably first-come, first-serve. The bottom line: Failure to detect operational business events in real time can result in highly undesirable ‘settlement’ problems downstream. Use business rules in real time to detect out-of-tolerance business transactions whenever you can. Tip for Business Analysts: Stay alert for business processes involving after-the-fact settlements. Could real-time reaction to operational business events eliminate them? ~~~~~~~~~~~~~~ This post excerpted from our new book Building Business Solutions: Business Analysis with Business Rules. See: http://www.brsolutions.com/b_building_business_solutions.php

Tags: , , , , , ,

Ronald G. Ross

Ron Ross, Principal and Co-Founder of Business Rules Solutions, LLC, is internationally acknowledged as the “father of business rules.” Recognizing early on the importance of independently managed business rules for business operations and architecture, he has pioneered innovative techniques and standards since the mid-1980s. He wrote the industry’s first book on business rules in 1994.

Comments (1)

  • Avatar

    Ed Johnson

    |

    Gosh, so much to respond to.

    Yes, “failure to detect operational business events in real time can result in highly undesirable ‘settlement’ problems downstream.”

    However, more importantly, failure to plan to detect operational business events can, and do, result in highly undesirable ‘settlement’ problems downstream. Implicit in the Case Study, just for the sake of argument it seems, is a failure to so plan, as the agreement between the hotel and the conference organizers might reflect by omission.

    In my experience, such failure to plan stems from over idealizing business processes, trying to force fit them into an IT- or BPM-style algorithm to execute a predictable activity sequence, starting from a neat “begin process” point through to a neat “end process” point. Such failure to plan also stems from not understanding that every process, business and otherwise, generates some manner of waste with respect to process aim(s) or purpose(s). Compounding the matter is arbitrarily ascribing significance to perceived process size or scale, when, in reality, nothing that happens isn’t a process – stated positively, everything that happens is a process. And every process, by definition, makes some manner of transformation. A transformation may be of form, state, time, place, or a combination of these, of course. Thus “process flow” is a process, too.

    Now, to Ron’s questions with respect to the Case Study…

    “Does a To-Do item constitute a business process?” Of course not. A To-Do item is a thing – more specifically, one among possibly several instances of a kind of thing output from a process that will activate upon detecting the presence of a particular kind of waste that has appeared within the hotel’s corpus.

    “Does a Checklist constitute a business process?” Of course not. A Checklist is also a thing. In fact, a Checklist may be just a stock (accumulation) of To-Do items, depending of the meaning Checklist.

    “Does an out-of tolerance event constitute a business process?” Of course not. Such an event is also thing, although intangible. The event comes, or emerges, from a process to signal the process has experienced a change in wellness of state with respect to operational limits, such that now the process has started generating waste in an extreme kind of way, again, with respect to process aim or purpose.

    A point in all of this is that analysis is, by definition, a reductive activity – meaning, when a system or process is analyzed (taken apart), the system or process loses its essential properties, and so do the parts of the system or process. That is, system or process parts have meaning within context. This extends from understanding that every process simultaneously comprises smaller processes and is a part of a bigger process, and that process behavior can play out in fascinating ways ranging in degree of predictability, from totally predictable to totally unpredictable.

    In short, analysis forces out and otherwise disrupts or destroys process dynamics. Of course, analysis is necessary for designing solutions meant for implementation using IT. And that’s why it is important to not mix up modeling a business process itself with modeling a design of a BPM or IT solution meant to facilitate performing the business process. Modeling a technology solution design very often ends up masking real reasons a process generates wastes in the extreme.

    For example, in an engagement with the HR Corporate Offices of an executive branch federal entity, the HR business folk (25 HR Specialists, five senior HR managers, and one HR VP in the background) had assumed they needed an IT solution to improve the quality of applicants wanted. However, out of engaging them in using IDEF0 to model their “Hire Process,” including the waste the process generated, emerged their realization the problem was the HR culture and not the absence of any IT solution. They then went about planning – yup, using IDEF0 – and transforming the HR culture and eventually started getting the quality of applicants wanted.

Comments are closed