This website covers knowledge management, personal effectiveness, theory of constraints, amongst other topics. Opinions expressed here are strictly those of the owner, Jack Vinson, and those of the commenters.

Reaching the Goal

I was given a complimentary copy of Reaching The Goal: How Managers Improve a Services Business Using Goldratt's Theory of Constraints by John Ricketts.  I am always interested in learning how people are applying TOC beyond the manufacturing sector, where it started.  I suspect TOC aficionados will enjoy this book for the use of familiar TOC language in a new arena.  Ricketts does a nice job of giving an overview of TOC, but people new to TOC will likely be overwhelmed with the new ways in which TOC looks at the world.  And any reader might get overwhelmed by the preponderance of abbreviations and subscripts.

The book organization is fairly standard.  Ricketts provides background on Theory of Constraints and on Services.  He describes each of the core TOC applications as they are traditionally defined.  (And he does a good job of describing them in about five pages each.)  Then he goes through each of the TOC applications and describes how they can be applied to a services business: why there are differences and how the applications can be adjusted.  This is the core part of the book.  Then he spends a couple chapters discussing implementation, including the kind of technology that would be appropriate to support a TOC for Services implementation.  Ricketts provides a number of examples where the TOC applications are played out in more detail.  Sometimes these contain too much information, but it is helpful to see the ideas built into these examples.

The main idea behind the book is to apply Theory of Constraints to the Professional, Scientific and Technical Services businesses, which is about as far removed from TOC's manufacturing origins as possible.  My reading of the book leads me to believe that the key difference with services businesses is that the constraint really is the people who provide the services.  It is not machines or the distribution system or project sequencing.  As a result, the TOC applications need to be modified to take this into account.

The biggest change has to do with the definition of "services" as being those that customers typically want immediately and can frequently get from competing businesses.  In other words IBM's mantra: services on demand.  Where TOC traditionally looks at capacity being relatively fixed and delivery times being negotiable, TOC for Services (on Demand) changes the equation to flexible capacity a delivery as required by the customer.  This is my biggest quibble (or misunderstanding) with the book.  My understanding of the TOC approach is to do everything to make it possible to deliver to the customer within their "tolerance time" (the time they are willing to wait for a product or service).  All of the operational improvement efforts in TOC are geared around reducing cycle time and speeding delivery.  TOC for Services does this too, but Ricketts takes it another step further with the On Demand viewpoint.

This creates the other big change: since the "product" service businesses supplies (expertise) isn't consumed at the end of the job, it returns to the business ready to work on the next assignment.  As a result, TOC guidelines that are based upon consumption and replenishment need to be modified to account for the return of resources. 

Here is my attempt at describing how each of the TOC applications changes.

Application Traditional TOC TOC for Services
Replenishment Used to replenish supply chains through distribution networks.  The main idea is to shift from push to pull to aggregate variation in a central location. Replenishment for people resources needs to account for the fact that people come back from their assignments, so the mechanisms around replenishment need to buffer around demand for given roles.  Ricketts introduces the idea of buffers which can be approached from two directions, rather than just one, which I find intriguing.
Critical Chain Project management.  Protects the entire project by moving task-level slack into a project buffer. To offer projects on demand, this must be integrated with the replenishment solution.  Otherwise, Critical Chain operates essentially the same.
Drum-Buffer-Rope Used in manufacturing to pace the flow of work through the system, based on the capacity of the constraint.  When there isn't an internal constraint (because the market demand is lower than what the facility can produce), DBR is still used to provide a due-date quoting mechanism and to monitor capacity. Used to manage service contracts, such as for operating a call center or being the IT support function for a company.  The difference here has to do with metrics around service levels and how that ties back to the TOC metrics.
Throughput Accounting Beyond the basic measures for Throughput, Operating Expense and Investment, Throughput Accounting gives a number of calculations and recommendations for decision-making with TOC in mind. Ricketts keeps most of the Throughput Accounting concepts, but makes a big change with the concept of Resource Dollar Days to be used as the key effectiveness measure (parallel to Throughput Dollar Days).  I don't fully understand RDD, but it keeps bothering me that it can be greater than zero where a non-zero TDD signals that something is going wrong.
Sales and Marketing It seemed like the solutions here were very similar between traditional and services-based TOC.  In both cases, it is important to use a pull methodology, rather than push.  With services, you have to be more cognizant of the resources constraint, but good TOC sales & marketing approaches are always built with the constraint in mind.
Strategy and Change This is another area that feels similar to standard TOC.  Strategy is set at a high enough level, that I don't see why there should be a significant difference between the traditional TOC targets and service-based businesses.

Along with the changes to the specific applications, the other thing that becomes clear is that to get the most benefit out of TOC for Services, it makes sense to implement all of these applications of TOC.  Traditional TOC, at least non-strategic implementations, are just fine with implementing one of the applications areas.  Strategic TOC implements the core applications, which usually encompasses almost all of the TOC applications.

I also love this catch in the Implementation and Technology chapter (p. 274):

TOC also supports an empirical approach to identifying best practices....  Best practices are activities that enable the enterprise as a whole to reach its goal via continuous improvement at constraints.  It can't be a best practice if it doesn't move the needle.

One expert, good; two experts, not so much

This is collaboration?