Theory of Constraints Handbook - James Cox Iii [575]
The prevailing PSTS strategy outlined above thus may have made sense when professions were sparsely populated, science was in its heyday, and technology was a novelty. However, with professionals, scientists, and technologists facing competition as never before, an undifferentiated strategy is a huge exposure.
The question then becomes, “Does TOCS enable service providers to change the game in any way besides shifting from labor-based to asset-based services?” The answer, as we shall see, is yes.
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.