What to Change to

Let's get the obvious question out of the way first: Why can't you just apply traditional TOC to services? The good news is you can, if the services are repeatable enough. For instance, some technical services consist of authorization, delivery or drop-off or dispatch, diagnosis, repair or replacement, shipment or pick-up, and billing. Somewhere among those activities is the constraint, and it can be managed with virtually the same TOC methods used to manage a factory, even if the service provider maintains no parts inventory.

When the services in question do have physical inventory, however, the fit with TOC is even better. For example, food services have to manage not only raw stores, but also work-in-process (WIP) in the kitchen, and finished goods on the warming table, in the display case, or on the shelf. Moreover, in some services, things that wouldn't ordinarily be considered inventory can be treated that way for management purposes. For instance, some health services view hospital beds or operating rooms as finite yet perishable inventory, and manage their processes with TOC. Other health services view each patient's treatment as a project to be completed within a specified duration (Umble and Umble, 2006).

So if traditional TOC works on some services, why not in PSTS? With a few exceptions, such as the repair service described previously, the services provided by PSTS are not sufficiently repeatable, and inventory is typically a minor consideration. When clients engage lawyers, they want them to win their case. When clients engage scientists, they want them to study their problem. When clients engage technicians, they want them to fix their technology. Case law, published research, and technical manuals are useful references, but they are not inventory for purposes of applying TOC to PSTS.

Furthermore, services in PSTS are typically customized for individual clients. Even when the service provider has a standard methodology, the services actually delivered have to be tailored to unique customer requirements. For example, when implementing a standard enterprise software package, it has to be configured for the client's information technology environment (servers, storage, communications, firewalls, authentication, etc.), it has to be integrated with the client's other software applications, it has to be loaded with appropriate data files, it has to be tested, and it has to be made usable via demonstrations and training. Although the software itself may be standard, hardly any of the implementation service is actually transferrable between clients.

Consequently, TOCS is harder than TOCG for several reasons.

It can be hard to find the services constraint when there are no piles of inventory to signal where the constraint might be. When services are delivered at client sites or from multiple service centers, you can't just walk around and find the constraint.

Once the constraint is found, it can be hard to keep the constraint from floating because demand for resources is driven by client engagements. One month the service provider may be short on auditors, the next month short on tax specialists, and the following month short on management accountants.

Clients are often coproducers of services. Outside legal counsel typically works with inside legal staff. Outside consultants work with company management. Outside technical specialists work with inside technical staff. Thus, the constraint on services isn't always within the service provider; it can just as easily be within the client's organization.

There are many sources of variability in services that cannot be buffered with inventory. If the service provider doesn't have sufficient capacity to deliver services on demand, and its clients are unwilling to accept services as available, those clients may choose to do without the service, find another service provider, or do it themselves (Ricketts, 2008, Chapter 4).

Service providers may be bound by Service Level Agreements (SLAs) that impose penalties on the provider for noncompliance, and may offer bonuses for extraordinary performance. However, if demand for service is outside the service provider's control, such as when the client's customers call contact centers operated by the service provider on the client's behalf, the provider cannot unilaterally deny or delay service without missing the SLA, as traditional TOC applications might dictate.

Despite these difficulties, every one of the applications from TOCG has been adapted for TOCS, as will be seen next. Hence, for PSTS the short answer to the question, "What to change to?" is TOCS.

Replenishment for Services

Replenishment for Goods (RG) is the traditional TOC application for distribution. Briefly, RG establishes inventory buffers that cover total consumption of inventory during the time needed to resupply, taking variability into account. Those inventory buffers are located at a central warehouse rather than retail locations because aggregated demand varies less.

Thus, if it typically takes three to five days to get more of a particular inventory item, and a distributor typically ships 25 units per day, that distributor might size its inventory buffer at 100 units-or 25 units per day times four days. Ideally, this buffer prevents the distributor from running out of that item because the buffer is replenished based on actual consumption. On those rare occasions when the buffer nears depletion, the distributor expedites the active order with its supplier.

Aligning buffer size with consumption and resupply time thus optimizes inventory, so whenever those parameters change, the buffer is resized accordingly. This is a radical departure from conventional wisdom, which says inventory levels ought to be dictated by demand forecasts and infrequent shipments of large, economic order quantities.

Replenishment for Services (RS) is the TOC application for resource management in services. In general terms, resources are anything a service provider needs to deliver a service, but in labor-based services the term "resources" is virtually synonymous with "people."

In a services context, resources are not consumed in the same sense as inventory is consumed by distribution. Once shipped, inventory typically does not come back. Once assigned, resources naturally come back for more work. Therefore, RG is based on total consumption, while RS is based on net consumption, which is the difference between resources going out on assignment minus those coming back. Net consumption for a given period can therefore be positive, negative, or zero.

Briefly, RS establishes resource buffers that cover net consumption of resources during the time needed to change supply, considering variability. In addition, those resource buffers are located in skill groups that serve the enterprise rather than individual projects, because aggregated demand varies less.

Thus, if it typically takes 60 to 90 days to complete the hiring process and get a new employee on board, and the service provider typically needs one additional employee per month in a particular skill group, that service provider might size its resource buffer at two or three resources. Whether it would be two or three depends on whether that particular skill group is the constraint.

No forecasts are needed for RS, which is a radical departure from conventional wisdom. Thus, RS is an alternative to hire-to-plan, which begins hiring independent of whatever deals are in the sales pipeline. Likewise, RS is an alternative to hire-to-deal, which doesn't even start the hiring process until a new engagement is imminent.

Hence, RG and RS are based on the same principles, but they operate in different contexts. Furthermore, within services enterprises, RS supports both projects and processes, which are two different ways to deliver services. They are discussed next.

Critical Chain for Services

Critical Chain for Goods (CCG) is the traditional TOC application for project management. It's a radical alternative to Critical Path Method (CPM) and Project Evaluation and Review Technique (PERT), the dominant project management methods.

Briefly, CCG changes how projects are estimated, planned, performed, and tracked. Those changes lead to better on-time completion as well as shorter projects, which defies the conventional wisdom that says there is an immutable trade-off between those outcomes.

CCG employs task estimates at the 50 percent confidence level rather than at the 80 percent level because task-level contingency does not really protect on-time task completion, let alone on-time project completion. CCG instead starts with non-buffered task estimates, then consolidates contingency into a project time buffer, which protects the project as a whole.

CCG eliminates resource contention because overloaded resources cannot complete tasks on time. CCG instead adds resources or shifts selected tasks earlier in the schedule, which is called resource leveling. The longest path through the project plan after resource leveling is known as the critical chain. Even for projects with equivalent deliverables and scope, the critical chain and critical path are always different because the task durations are different. However, the set of tasks comprising the critical chain and critical path can be different, as well.

CCG applies different work rules because projects are best performed like a relay race. That is, each task starts as soon as its predecessors are done, even if that means an early start. Early task starts thus compensate for late finishes elsewhere in the project, which is not something that conventional project management does. Indeed, conventional projects are often late precisely because late task completions are cumulative.

CCG tracks projects differently because only a subset of tasks actually determines whether the project as a whole will be completed on time. CCG measures progress by how much of the project buffer has been depleted by late task completions. If buffer depletion is in proportion to the amount of the project completed (or less), the project as a whole is on track for on-time completion. This contrasts with conventional project management, which credits every task completion, regardless of whether those tasks actually determine whether the project will be late.

CCG was invented for engineering projects in a manufacturing context, but it works just fine on individual services projects, too. However, the traditional approach to Critical Chain Multiple Projects (CCMP) does not work as well in PSTS enterprises.

CCMP assumes that resources are essentially fixed and that multiple projects must be staggered based on their use of the constrained resource. For instance, if the constrained resource is an aircraft maintenance hangar that holds just one plane at a time, multiple aircraft maintenance projects are constrained by availability of the hangar. The resulting multi-project schedule forms a stair-step pattern based on when each project has an aircraft in the hangar. The same scheduling logic holds, however, if the constrained resource is a person or persons with a particular skill in short supply.

Thus, traditional multi-project critical chain presumes there is an internal constraint. As a result, clients must be willing to accept services as available. However, services clients nowadays are less willing to wait for service. They want services on demand. In addition, some service providers, particularly in the PSTS sector, are anxious to accommodate clients by acquiring additional resources as needed. This changes the multi-project problem to one where there is an external constraint: Either clients will not buy all the services the provider has to offer or the job market cannot supply all the skilled resources the provider needs to meet client demand.

TOC for Services solves the latter problem by combining replenishment with critical chain. That is, Critical Chain for Services (CCS) uses RS to provide resources to multiple projects being managed with critical chain. For example, resources on the bench waiting for project assignments-the resource buffer-should be sufficient to meet most demand for resources from multiple projects, even when that demand is unpredictable. Whenever the resource buffer drops below the target size, RS automatically replenishes it because the resource buffer is there to protect on-time project delivery and the revenue it produces.

By mitigating, if not breaking, the resource constraint, multiple services projects can be scheduled concurrently with CCS in order to meet the needs of various clients. A stair-step pattern between the projects is therefore not required.

Drum-Buffer-Rope for Services

Drum-Buffer-Rope for Goods (DBRG) is the traditional TOC application for operations management. Briefly, DBRG wrings maximum productivity out of manufacturing operations with an internal constraint by ensuring that the constraint, and only the constraint, sets the pace. Indeed, the "drum" in DBRG refers specifically to this pace setting.

The "buffer" in DBRG refers to WIP deliberately queued ahead of the constraint. This buffer ensures that the constraint has work to do even when there are disruptions upstream.

As noted earlier, keeping the constraint supplied with work is vital because utilization of the constraint governs what the factory produces overall. Non-constraints therefore must do whatever is required to keep the constraint fully utilized-and no more. That means that non-constraints upstream from the constraint typically have less than full utilization so that they won't overwhelm the constraint with excess WIP. Likewise, non-constraints downstream from the constraint typically have less than full utilization because they can only do as much work as is passed to them through the constraint.

Late delivery of raw materials, equipment breakdowns, worker absences, unexpected scrap rates, change orders-even the weather-may disrupt the production schedule. Therefore, upstream non-constraints sometimes have to sprint in order to keep the constraint busy when holes appear in the buffer. Likewise, downstream non-constraints sometimes have to sprint in order to complete late jobs on time. Nevertheless, contrary to conventional wisdom, it's normal for non-constraints to be idle occasionally. Indeed, it's necessary for them to be idle at times.

Rather than pushing work into the factory for utilization, DBRG starts jobs at just the right time and relies on due dates to pull those jobs through the factory in the right order. Thus, the "rope" in DBRG refers to the information systems used to start jobs at the right time and subsequently ensure that the constraint is working on the right jobs based on current due dates.

Having previously established that PSTS are highly customized and rely little on inventory, how DBR might apply can be a mystery. Nevertheless, it's a mystery that is easily solved.

When PSTS services are highly customized, the customized processes may nonetheless be highly repeatable. That is, when a service provider uses a shared service center to perform processes for multiple clients, each client's customized process may be performed millions of times. Think of paychecks. Due to organizational structures and compensation plans, no clients' payroll processes are identical, but the same process is performed for every client's employees every pay period.

Services WIP is often intangible, but it does exist, on paper or in computers. Although such WIP is not exactly inventory, it may nevertheless be managed with similar methods. For instance, service center managers can monitor work queues and completion of service requests. Likewise, research laboratory managers can monitor experiments and completion of milestones.

Briefly, Drum-Buffer-Rope for Services (DBRS) wrings maximum productivity out of service processes with an internal constraint by ensuring that the constraint, and only the constraint, sets the pace. The work buffer ahead of the constraint ensures that the constraint has work to do.

Based on the description of DBRS thus far, it may seem that DBRG and DBRS are indistinguishable, but that is not the case. There is one profound difference: In DBRG, the manufacturer modulates the work released into the factory in order to keep the constraint busy, while in DBRS, the service provider cannot control the inputs to the service process. Service requests come from the clients' customers, employees, suppliers, shareholders, or any other group that the client deems eligible for service. The arrival of service requests is not something the service provider can predict with accuracy, let alone control.

If the service provider cannot control inputs to the process, yet is bound by an SLA to deliver service within specified parameters, the process itself cannot have fixed capacity. Hence, the buffer and rope work differently in DBRS. When the buffer grows beyond its upper threshold, the rope triggers an increase in capacity that eventually brings the buffer level back down into the normal range. When the buffer shrinks beneath its lower threshold, the rope triggers a decrease in capacity that eventually brings the buffer back up into the normal range.

Thus, DBRG does buffer management of operations with fixed capacity, while DBRS does capacity management of processes with variable capacity. DBRG and DBRS are based on the same principles, but they work differently and are used in different contexts.

Throughput Accounting for Services

Throughput Accounting for Goods (TAG) is the traditional TOC application for measurement. It's an alternative to cost accounting, the dominant measurement method.

Briefly, TAG changes financial measures-and therefore other measures derived from them-plus it changes management priorities. One of the financial measures, Throughput, was mentioned earlier. The other financial measures are Investment and Operating Expense (Corbett, 1998).

Throughput (T) is cash from sales minus truly variable cost. Thus, it's revenue minus cost for materials and parts from which each item is built.

Investment (I) is all money invested in things for sale. Plants and inventory are included.

Operating Expense (OE) is all money spent turning I into T. Direct labor, rent, and selling, general and administrative (SG&A) costs are included.

There is no product cost construct in TA. OE is simply summed. It's not allocated to products. This avoids the distortions that make some products appear profitable when they are not.

The financial goal for a profit-making enterprise is to maximize net profit (NP), which is T minus OE. To accomplish that, enterprises have to create products that generate T, make judicious decisions about I, and manage OE in light of T.

Furthermore, the priorities have to be T, I, OE because that fosters growth. This is the opposite of typical management priorities, which focus relentlessly on cost reduction and thereby hinder growth.

In addition to financial measures with conventional names, TAG has control measures with unconventional names. Throughput Dollar Days (TDD) indicates whether work is being shipped on time. Inventory Dollar Days (IDD) indicates whether excess inventory is accumulating. TDD and IDD thus steer the manufacturer toward its goal.

At the highest level, Throughput Accounting for Services (TAS) is virtually identical to TAG. That is, TAS changes financial measures, and all measures derived from them, plus it changes management priorities. Where TAG and TAS differ is in the details because PSTS are the services least like manufacturing.

Rather than generating T from products, PSTS enterprises generate T from project deliverables and process service levels. Truly variable costs are for things consumed in the production of a service, such as parts used for repairs.

Rather than investing in plants and materials, PSTS enterprises invest more in skills, intellectual capital, assets, and service production systems. Furthermore, bids and proposals are significant investments.

Rather than including factory labor in OE, PSTS enterprises use labor from professionals, scientists, and technicians. SG&A costs include labor from partners and principals, whose job it is to sell services engagements.

Just as there is no product cost construct in TAG, there is no service cost construct in TAS. OE is simply summed. It's not allocated to services. This avoids the distortions that make some services appear profitable when they are not.

TAS also has its own control measures with unconventional names. Project or Process Dollars per Day (PDD) indicates whether engagements are being completed on time. Resource Dollars per Day (RDD) indicates whether excess resources are present. PDD and RDD thus steer the service provider toward its goal.

TAS creates several benefits for service providers. Management priorities are realigned for profitable growth. Service mix decisions are not distorted by cost allocation. Control measures steer the enterprise toward its goal. Finally, optimization is achieved globally-across the enterprise-rather than locally within a single department or business unit.

Nonstandard TOC Applications

Standard TOC applications are largely consistent across enterprises within a given sector. They include the R, CC, DBR, and TA applications just seen.

In contrast, nonstandard TOC applications vary across enterprises because they have unique requirements. Nevertheless, the underlying TOC principles are still the same, even for nonstandard applications.

Marketing creates compelling offers.

Sales then close deals with customers.

By creating offers that address customers' core problems, TOC offers business value that can be much higher than conventional offers heavily based on price.

Strategy defines the way an enterprise pursues its goal.

Change then realigns marketing, sales, and production to carry out that strategy.

By creating holistic solutions targeted at constraints, TOC uses leverage to generate large benefits from modest investments.

Implementation puts TOC applications into practice.

Technology is a necessary enabler.1 By using a specific set of steps to achieve adoption and by applying technology prudently, TOC addresses the biggest impediments to implementation.

These nonstandard TOC applications are just as relevant in services enterprises, of course. Details are beyond the scope of what can be covered here, however. See Ricketts (2008, Chapters 810) for more information.