Theory of Constraints Implementation

How We Implement Theory of Constraints

There is no “standard” Theory of Constraints implementation

Each Theory of Constraints implementation is customized to suit the client, in terms of:

  • The TOC applications involved.
  • The specific set of tasks associated with implementing each application, which depends on the client’s current environment.
  • The division of work between the client and Synchronix.

For example, even with the focus on the Synchronous Manufacturing application there can be three “big picture” scenarios:

  1.  The sales people can sell the improvements in lead time and on-time delivery without doing anything different. Typically, in our Assessment, sales people can even name the exact accounts they’ll go after when armed with the new performance. The implementation requires only Synchronous Manufacturing and Throughput Accounting.
  2.  While the improvements can be sold conventionally, the existing sales set-up needs to be the focus of some improvements internally in order to make the additional sales needed for the profit boost. The implementation requires Synchronous Manufacturing, Throughput Accounting and elements of the Theory of Constraints solution for sales.
  3.  A “Mafia Offer” will have to be developed in order to convert the improvements into the scale of sales growth needed to hit company targets. The implementation requires Synchronous Manufacturing, Throughput Accounting, the Marketing Offer and the TOC solution for sales; the Mafia Offer might call for the Distribution and Supply Chain solution to be implemented in support, in one shape or another.

And, the allocation of tasks between the client and Synchronix can vary to a large degree in each of the above scenarios. For example, some clients provide the resources to perform the majority of the implementation work and Rod and I can work at the highest level only, while in other companies (typically the smallest) almost no project-related work will get done unless Rod and I do it ourselves … so, we do.

Nevertheless, the general shape of an implementation can be described:

  • TOC-focused Assessment.
  • Education needed for systems design. (Includes application knowledge plus some Thinking Process training to help with planning, analysis and communication).
  • Systems design.
  • Data capture or conversion, where necessary; often simultaneous with Systems Design.
  • Selection of software, or else spreadsheet-based systems development for the DBR and Replenishment applications; includes, any integration or interfaces with current IT systems.
  • Implementation planning.
  • Education and training in support of implementation.
  • Boardroom Pilot.
  • Go-Live.
  • Ongoing support (on-site hand-holding) following the Go-Live.
  • System refinement and “tweaking.”
  • Periodic system and execution audits.

It is common for the Go-Live to be within 90 – 120 days from the project start-up; with the ongoing aspects of the implementation continuing for an additional 60 – 90 days. However, on occasions we’ve been able to expose 25% capacity within 7 days, and have a Drum-Buffer-Rope system in place within 30 days.

Typically, the only time an implementation is subject to significant delays is when a small company is using a computer system but key individuals have left the company and today, no-one in the company has any knowledge whatsoever of the system beyond their daily routine, and no knowledge whatsoever of the data that exists or where it’s stored.

When the data is clearly going to be of use to the Synchronous Manufacturing project, we are compelled to learn the system sufficiently well simply to know what does and does not exist for our use – and this can take time.

Even so, this is a just delaying issue, not a show-stopper.