The Factory Process is that set of activities that define the essence of the business in which the Enterprise is engaged. It is the path most transactions and activities should travel.
Since this is the path taken by most of the business’ activity, it should be created as a highly automated, well-oiled machine. It is the process where the transactions have the highest velocity. It is the process with the lowest costs per transaction. These factors require that the Factory Process be protected at all costs. This protection is provided by the Safeguard processes. We’ll discuss those in a later post.
If the Factory Process is working correctly, there will be few, if any, exceptions. But exceptions will arise for many reasons, some preventable, some not. Those that are not preventable will flow into the predefined Exception Processes. Costs go up significantly when these Exception Processes are employed mostly due to the need for manual intervention. We’ll investigate these issues in another post.
What about those exceptions that arise even though they were preventable? These are generally caused by human error somewhere in the process. It may be a worker on the line (whatever the line may be in the Factory Process) who is performing their duties incorrectly. It may be a defect in the computer program that automates one of the Factory activities. Such a defect points to human error in the development, testing, or deployment of that program.
The Factory Process needs two attributes to combat these exceptions. These are a Feedback Loop and Good Supervision.
A Feedback Loop provides information about the the process. This feedback should be descriptive and as close to real time as possible. The description would ideally provide the outcome of an individual process step for an individual item or transaction matched against a list of expected outcomes. These expected outcomes would be those outcomes that can continue to be handled by the Factory Process. The near real-time nature of the Feedback Loop means that these outcomes are available to managers who can adjust the process as soon after the transaction step was completed as possible and that it is presented in a way that makes anomalies easy to spot. Most people think of dashboards and the metaphorical presentations used by them.
Nothing beats good supervision when combating problems in the process. Supervisors are the absolute front fine of management and should not only know what a process does but also why it does it that way. Having spotted a high level of exceptions originating from the area they supervise, the Supervisor should work to find the cause and escalate to find a remedy. Supervisors should be rated based on their ability to minimize the number of preventable exceptions incurred under their spans of control.
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.