The problem with writing and publishing from a stream of consciousness is that sometimes you say things you might want to reconsider.  I have been thinking about my statement in the last post that exceptions to exceptions are illogical.  Consider the following…

An enterprise decides that its factory process is that it will conduct its business with its customers electronically.  Say the enterprise is a utility company.  It emails the monthly bills to every customer and includes a link to its electronic payment website.  This makes it simple for the customers to comply with the utility’s wishes.  Or does it?

Assume that every customer can receive the bill.  That doesn’t mean that every customer has the ability to pay electronically because not every customer may have a bank account or payment card.  Then there is that group of unruly customers who just refuse to make electronic payments.  Assume that these groups comprise a number large enough that failure to accommodate their needs will severely hamper collections of revenue necessary to keep the enterprise going.

The enterprise now has an exception process that must process old-fashioned payments where the customer returns a coupon or remittance advice with a paper check.  Since the volume is significant, the utility must have a reasonably efficient process to minimize costs.  So a factory process is set up to efficiently process paper coupons and checks.  It starts with the utility including a remittance coupon that the customer can print and return with his check.

The rest of the process can be built either by investing in the process or outsourcing to a lockbox operation.  The factory-compliant transaction is where the coupon and check arrive together and the check amount matches the amount that was billed.  These transactions flow right through the new factory process for the exception process.  The output from this process should resemble an electronic payment so that it can be submitted to the enterprise factory process immediately upon completion.

What can go wrong now?  We now have the following three exceptions to the exception:

• Only the check arrives
• Only the coupon arrives
• The amount on the check doesn’t match the amount on the billing coupon

So what’s the lesson here?  It is that there should exist factory processes within exception processes where the incidence of exception is going to be very high and the enterprise has little way to control customer behavior.  These factory processes should be managed just like the enterprise factory process in order to maximize efficiency and minimize costs.  The output from this exception process should reenter the enterprise factory process as quickly as possible.  But there are also exceptions to be encountered that the exception factory process can’t handle.  These should be managed at the department level just like exceptions to the enterprise factory process are managed at the enterprise level.

Processes are sets of activities that have some level of definition and standardization about them.  The Enterprise runs using three types of processes.  These are Factory, Safeguard, and Exception.

The Factory Process is that process that implements the essence of the business. These activities are the “right” things to be doing.  We have previously referred to them as the “things we’re supposed to do”.  It is the core competency and operates at the highest efficiency and velocity.  Every step of the Factory Process is standard and should be automated to the highest extent possible. The Enterprise wants to push all transaction activity through it. This is the path for transactions from Customers who “play by the rules” of the game as the Enterprise wants it played.  This should encompass the majority of the transactions processed by the Enterprise.

The Factory Process must be protected by Safeguard processes to ensure it is not being abused.  These activities ensure that you are doing the “right” things right.  The high velocity of the transactions flowing through the Factory Process means that problem transactions can be completed before it is known that they are problems.  (e.g. Processing fraudulent transactions can cause money to leave the Enterprise with no hope of recovering it.)  Business-driven Enterprise Architecture and Internal Audit are examples of Safeguard processes.

Transactions that don’t conform to the Factory Process are Exceptions and run through Exception Processes.  In many cases, these are the activities that we have labeled the “things we really do”. Exceptions should only spawn from unruly Customer behavior.  If behavior within the Enterprise dictates a change, adjust the Factory Process or change the behavior back to that which conforms to the existing Factory Process.   The degree of automation for Exception Processes is thus dictated by the Enterprise’s ability to control or influence this unruly Customer behavior.  (e.g. Most Customers will need Customer Service at some point in your relationship to them and unless you are in the Customer Servicing business, it is an Exception Process.  There is always some level of Customer Service that can be automated and some level that shouldn’t be.  Perhaps the former set of activities should be considered Safeguard processes because they help the Customer play the game correctly.  The latter set is for those Customers who just demand more attention.  Understand the difference.)

The goal should always be to correct the exceptional nature of the transaction and then get it back into the Factory Process.  The idea of running a parallel process that handles the exception differently all the way through its lifecycle is both inefficient and ineffective.

The idea of an Exception to an Exception is illogical.  It is just another more obscure exception that has many of the same traits as some other exception.