The Exception-Tolerant Organization – Part 1

As explained in my introductory post on the Exception-Tolerant Organization (ETO), ETO’s can embrace change and uncertainty while systematically executing their business. There are two keys here to making this a practicality:

- Being able to systematically execute the business

- Having an entry point in each business process for welcoming the change and uncertainty once an exception event occurs

First, ETO’s are able to systematically execute their business. There is a system for each business process that the ETO’s people follow to execute, manage, and report on their business. This is not as complicated as it sounds, as there are systems everywhere in business: accounts payable, software development, computer machine and image preparation, accounting. And when the ETO’s people understand that the systems exist to support the major ideas and goals of the organization, no system is considered too mundane to be ignored, improved, allowed to decay, or allowed to bloat in size. There are many books and references on the web related to understanding the importance of systems and business processes, so I will not expand further here.

If your organization is not systematically executing your business, but rather executing in an ad-hoc and undisciplined fashion, it can be difficult to embrace any changes or external events. Your organization is already dealing with so much noise and individual solutions to regular business issues ---that it will not be able to differentiate an exception event from a regular business event. Note that this can be an advantage when looking to create a system, in that your best ad-hoc process may work just as well for handling an exception event as it does for conducting your regular business. If you find your organization in this situation, use your best ad-hoc process as a starting point for implementing a system that can be executed repeatedly without fail.

Second, each one of an ETO’s systems and business processes has at least one entry point for addressing an exception or a change. Organizations need a way for someone to bring an event warranting change or representing uncertainty to the business’ attention. As an example, Toyota production workers are able to stop the line when they see a problem during the production process. Stopping the line is their entry point.

Entry points for processes that must be executed daily and on-time can be more difficult to see with the naked eye. As an example, an investment portfolio that must be valued on a daily basis - one or two issues with the price of an investment can make the portfolio's reported value wildly inaccurate, and become grossly misleading to a fund manager's investors. The system of valuating the portfolio must have an entry point where exceptions with prices can be raised, diagnosed, and handled. The identifying and handling of these exceptions is a systematic process itself, often assisted by robust technology. The entry point can be an automated review of the portfolio, followed by an exception reporting tool with a pricing exception report as a backup.

An entry point for an organization experiencing a problem with internally-developed software is a help desk department, which has rules and procedures around when it is available to take calls, and its expected turnaround time when responding to issues and exceptions. In other words, it is a system. Other organizations may have a developer, system administrator, DBA, infrastructure engineer, or manager as the entry point for problems. All of these technologists have different schedules and structures to their day, and can serve as an effective entry point - when they are available. Business principals may even feel more comfortable going to them directly, as they feel that the technologists are closer to the solutions than the help desk professionals.

This often ends up being more effective from time to time, but less systematic. Technologists are often steered away from their scheduled and time-sensitive work to handle exceptions, particularly after-hours and overnight. But here is a situation that calls out for leveraging a system so that effectiveness can be assured every single time the entry point is used. Being exception-tolerant allows us to handle these exceptions without negatively impacting regular business. This will be continued in Part 2.