Takt Time Business Cases

		If you have any questions concerning our article concerning Takt time business cases, or wish to make any comments, please feel free to send a message to us at quality@artige.com.
		If on the other hand you wish to engage our services and would like to apply these principles and our experience to helping your firm increase its profits, then please send a message to sales@artige.com or call us at (1) 717-354-5541, and one of our representatives will be happy to discuss your needs.

	Available on this page:		Overview		Bus Line		Call Center		Conclusion
	Plus Questions on:		Takt Time Clock		Learning Curve

Overview		A recurrent inquiry comes to us along the lines of how one can apply "Takt time" to solve an operational problem, and in recent times the affected operation is more often than not classified as a service industry participant. We have a standard case that we use to explain Takt time usage in the service industry. It is based upon a bus line operation, and we have recently extended this standard case to cover a call center operation, to show that the approach to deploying Takt time is similar regardless of industry or product. We are confident that your case can be mapped in a similar technique, otherwise you can contact us if you wish to have some advice in your particular situation.
		We like our standard pair of cases of bus line and call center operations, as they represent examples of a push and a pull system. Typically the bus line schedule is set by the bus operators to meet expected demand (pushing busses that will be filled and emptied based on projections and near term information), while a call center needs to react to changing demand as it occurs (customers are pulling you with their demand). This way we can show how Takt Time can be used in either demand instance. We should point out that Takt time per se would not solve any particular problem. Rather, we can use it as a guide to diagnose and mitigate operational challenges for any business activity.
		When considering an operational problem, Takt time is used along with Layers and Levels of Granularity. When reasoning service vs. manufacturing cases, the Layers determine whether we can use Takt to drive all of production as is typical in manufacturing, in that both the layers of rate of cycles and the cycles themselves are under our control as we are pushing demand. This is compared to the service industry problem, where we can drive only a single layer of the production cycle, but we suffer under the whim of the customer as for when the next cycle will occur. The astute reader will recognize that we have presupposed Manufacturing with Push and Service with Pull, and that is how the above statement should have been reworded. Except that this traditional usage is pretty much what we still see everyday, so we fall back on the traditional usage as it is common usage that most people can relate to. In addition, the only reason that pull is considered more popular than push is that it is by definition less wasteful. But that is only true if your operation is capable of handling demand on a pull basis, not all operations are amenable to this (yet). No matter what, the process designer is still obligated to devise the lowest cost operation, unless it is mandated otherwise by criteria. If those criteria force a high cost approach, then a higher-level process will hopefully kick in and sort that out.
Bus Line		We happen to like to use the bus analogy when discussing Takt time, as most people are personally familiar with busses and oftentimes we can map out many cyclic processes to a public bus operation.
		A major point that needs to be considered is that our bus company will have collected statistics over time as to an expected load, both typical and disruptive. To be successful, we must know how many people need to take the bus at what time of day, and from which bus stops. Additionally, over time statistics will have been accumulated on holiday traffic and frequency of breakdowns, rush hour traffic jams, and how often disruptive activities occur. In any process investigation and improvement, statistics are critical to the diagnosis and subsequent monitoring of improvements and continued successful operation. Then we follow on that the statistics are just a guide, and that factors may come into play that could alter expected loads and typical number of disruptions.
		Having these statistics in hand, the bus company provides for buses to be dispatched at appropriate times, in order to meet demand of the public, while maximizing profits to bus company owners, or in the case of a government operation, minimize costs. The operations manager can deploy Takt time in dispatching the busses. In this case Takt time is providing a mechanism of averaging. Say a bus line expects to pick up 1000 people an hour during the daylight hours. You have a bus that can hold 75 people. So simple math says you should run a bus every 1000/75 = 13.3; 60/13.3 = 4.5 ~= 5 times an hour. This would be the minimum rate, with little or no slack.
		Another level of granularity for Takt time would be the operation of the bus itself. The bus driver will have tasks on board, such as collecting fares, starting and stopping the bus, negotiating traffic, taking the bus to the depot for maintenance. Takt time can be deployed to handle some of these tasks too.
		Focusing on the dispatch rate, we can now play the operations management game, where the dispatcher and the owner battle it out for resources vs. profits / least costs. This is also where we take into account the things that can go wrong. As was mentioned in the above example, running a bus 5 times an hour during the 1000 people/hour demand slot will leave little slack. If we operated at that optimal rate, should a bus break down in this interval, unhappy customers will be the result, as we cannot meet the unexpected resource reduction. Same situation if there was a surge of people at a bus stop. Potentially, customers down stream from the affected bus stop will be unhappy if there is no place on the overloaded bus for them.
		So what can go wrong in this scenario? Since the bus company collected statistics and anecdotal history, they know that their three biggest problems would be unexpected load (too many people), external conditions (traffic), and resource problems (broken busses and drivers failing to show up for work). The operations manager will need a plan in place for such situations. In your instance, it will be important to know what the regular demand rates will be, say rate per hour at each hour you operate. It is also necessary to recognize what your disruptions are, so you can plan ahead to reconcile them.
		The bus dispatcher will have some tools at his disposal, which I must point out, were worked out ahead of time. There are possibilities like extra busses, different size busses, tracking software, direct communications to the fleet on the road, drivers on call and the like. A combination of these extra resources, which have been negotiated with the ownership / government team for the capital and operational costs, allow the dispatcher to operate the bus line in a manner that satisfies most customers and owners. Takt time will be only one of the tools used to reach the team's goals.
Call Center		Now we start to map out the bus analogy to a call center. Before we proceed with this case, we will need to consider what our goals are. Running a bus line has simple goals, make sure all customers get a ride in a timely manner. When one is running a call center, the goals can be ill-defined. While answering the phone or replying to every email can be a goal, the response can be highly variable, so quality will play highly into this discussion. A bus line is physical, the person is transported between two points, and if they are not taken to their destination, then the service has failed. One can meet a call center obligation of replying to every email or answering every call with a robot application that responds to queries with a fixed message and leave it at that. That call center operator is not going to get a renewed contract though.
		Seems that call centers work from goals such as "weekly targets", and failures measured by "we miss numbers". So we will assume that in addition to avoiding dropped calls and rejected emails that untimely delivery of responses is measured. Then there is the "quality" consideration of the deliverable. We will assume in this case that we are performing a customer service function, handing inquiries that requires research (look up), resolution processing (find an answer), and then crafting a response (reply). Using this generalized terminology will help out a bit in the narrative and hopefully your situation is similar.
		As a refresher, we will want to be reminded about the Takt Time definition (as detailed in our Cycle Time vs Takt Time article) in this case before we proceed. Takt time is the natural rate that a periodic cycle can be executed to produce maximum product with minimal waste. Consistency is what makes this natural, but must be discovered, not forced down on the process. Typically the focus is to minimize cycle overlap, as that is naturally disruptive and eventually ruinous if not mitigated. There is some concern on the other end of the spectrum, too much lag time between cycles, especially if people are heavily involved in the process (such as in a call center), as there may be a preliminary / rousing / trigger tasks that are reintroduced each cycle if the lag becomes too long.
		As implied above, busses are rather binary, they are there or they are not, but a call center is not as binary, so we have some levels of quality that we can call upon to assist us. When Takt time comes into mind, we are intuitively thinking about Load leveling. It should be inherent that a business can come up with a process that will satisfy one customer in a single cycle. Now when we have many customers to simultaneously accommodate (as is the case in the service industry) we have little control over their demand, so we do not know when the cycles need to be launched. The problem is that we need a supervisory business process insure the individual business processes can accommodate all of the customers as they make their demand. We wish to avoid having the cycles overlap per employee, so the Load leveling will need to be a process of its own, and is a dynamic process.
		So looking to a call center, we can work our way through the demand. Say we have 1000 callers per hour, the easiest approach would be to allot one call per worker, which results in fantastic satisfaction to customer, while the owners throw a fit. So, we need to use more metrics here. Say we can find out what the maximum number of simultaneous callers is, taking into account call duration. For this case, say it was 100 simultaneous calls. We can staff 100 employees to meet that rate and will still maintain great satisfaction to customer. Owners are no longer throwing a fit, but wonders why workers are idle at other times, seeing money evaporating before their eyes. The owners wish it were possible for the workers to be occupied more often, reducing lag and waste.
		This is where Load leveling comes into play. One method of meeting the owner's desire to occupy workers more often is to have the workers perform smaller tasks (shorter in duration) but more often. This is where calculus comes to our assistance, in our quest to knock down the peaks and fill in the valleys of demand. Calculus is where we take a function and break it down into ever-smaller pieces and sum them up to get a more accurate total. In our case, we are depending upon the greater quantity, but smaller tasks, as a tool to redistribute demand. So we look upon the business process owners to devise different processes that can look at the existing processes in order to break them apart. This redesign process needs accurate metrics and know-how, in order to insure that customer satisfaction is maintained, while new ways to create the product and satisfactory end results are achieved.
		For the case of a call center, is it possible to break down processes by splitting apart tasks and allocating them to specialized workers? The latter requires categorizing workers by length of time they can perform specific task types, and then workflow management where the work is segregated by task type and routed to specialists by type of task. There is a natural breakdown of work in the call center, where the research, resolution processing and response steps can be broken apart and handled by separate workers. Then there is the quality regulator method. In this case, one determines whether there is a iterative process that can be used as a business process. In this case we are breaking the process apart into smaller steps with interim responses sent and creating lag time between the iterative steps. This method would be invoked during heavy demand periods, but provides a mechanism to provide interaction with the customer while you are working out the heavy demand.
		We are sure you can find other methods for breaking the processes apart. Takt time requires one to have a constant natural flow of work. This is always better accomplished with smaller tasks. If you stick to relying upon all workers as generalists, there is the traditional categorization of workers by effectiveness (faster workers), and possible routing more difficult cases to them. It is important to recognize that you cannot dictate Takt time. Each process has its own cycle time. If it is unsatisfactory to you, you must find another process, or modify the existing process, until you find one that is satisfactory.
		Another Load leveling method is attempting to control the demand. For a call center, this is typically accomplished by working from a queue. This method has obvious limitations, especially with live callers. However, one can use automated systems to preprocess the demand, and sort requests by skill required. On the other hand, if all the requests are the same and you are unable to meet demand, then this is a sign that you are short of resources, which can be mitigated through additional personnel or perhaps training.
		We hope this explanation of where one can use Takt time to design call center operation processes was helpful. As you can see, Takt time is just a tool, it is not a panacea, rather one of many in the operation researcher's toolkit.
Conclusion		This article provided a pair of cases explaining how one can deploy Takt time when designing business processes. The two cases were both in the service industry, with one case in a push demand environment and the other case in a pull demand environment. While the push environment was readily conducive to deploying Takt time by allowing a process to achieve a natural cycle time, the pull environment presented a situation where Takt time alone could not handle the variable load. In this matter we rely upon load leveling to assist in the process design, and offer a flexible method to react to changes in load that is promised to us in the pull environment. The greatest impact on changing cycle times is gained by modifying the process, not by trying to speed it up. That is naturally accomplished by the learning curve. Pushing a process beyond its natural constraints will guarantee an eventual failure, even though there may be near term benefits experienced.
Questions		1- How would you deploy a Takt Time Clock?
		Might as well let you know up front that we look down upon Takt Time Clocks. A quote from the sixth Harry Potter book comes to mind when someone brings up the subject of Takt Time Clocks:

"'Of the Horcrux, wickedest of magical inventions, we shall not speak nor give direction...', I mean why mention it then?"

		Maybe not quite as evil as Horcruxes, but Takt Time Clocks can be grouped in there with the rack and whip, and we will mention them here. Actually, we refer to these clocks as cycle clocks, as we wish to have no association between Takt Time and the use of these clocks. Our definition of a cycle clock refers to clocks that are publicly presented time intervals, often staged as a stand alone large one line display, sometime incorporated into a larger "stadium" style board display. The time interval is automatically calculated from some cyclical operation and used as a feedback device. Using a cycle clock to drive behavior undoes the natural and beneficial effect of Takt Time. This needs to be clarified, as we are serious proponents of measuring process parameters and outcomes. The person responsible for designing and driving the business process will want to know how long each cycle is taking, and needs to be measuring Takt time.
		What is unnecessary, and we feel harmful, is reporting each cycle time to the personnel assigned to execute the manual portions of the cycle. There are two points to consider here. One is that it takes time to read the clock, which removes focus from the task. We have never seen any legitimate business task that involved reading a clock to complete the task, so this is a waste of resources.
		Second, we see the clock used as a tool to drive performance. Why is the employee required to look at the clock? To see that they have failed by not meeting the target cycle time. Not only will this person be expected to hurry up in an effort to reacquire the target cycle time, they will need to exceed the target in an effort to regain the lost time. This is a recipe for turmoil, where undesired and unplanned short cuts will be taken, causing quality to decrease, which in the end will break the Takt time cycle (if one is already in place). Having a clock announce cycle time is declaring that here is a minimum cycle time and that it must be met. Takt time never claims any such thing, there is no minimum, rather the natural cycle must be discovered, plus on top of it, the cycle is not constant, so Takt time is elusive. It would be silly to announce a cycle time if it will not stand still.
		We have found that proponents of Takt Time Clocks are many times sports fans, and liken the clocks to those found at sporting events. Running a business is not like playing a [American-style] football game. Particularly, if your business relies upon last minute Hail Mary passes to be successful, then you have bigger problems. Ask yourself, how did you get into that mess in the first place, where you need the equivalent of a miracle to succeed? Also, business operation is seen as a continuum, not a series of disparate scrimmages. If your business is disparate and your operation is not conducive to repetitive cycles, then Takt time will be of little use. Takt time is a tool for working with repetitive operations, using history of previous cycles to improve future cycles (or do away with the process entirely).
		Takt time will consistently deliver designed performance. We see driven performance as a one-shot effort, the occasional miracle of the Hail Mary pass. One cannot design a successful business process around such a philosophy. The businesses that rely upon this philosophy tend to be looked upon as running a sweatshop environment, where employees are driven and improvement occurs at a snail's pace, if ever, resulting in irregular quality products. We have a colloquial saying concerning the use of Takt Time clocks, "Nothing like telling workers they are too slow when there is nothing they can do about it". We take this a step further, and claim that any excursion of cycle time targets is a direct reflection of the management, who failed to design a successful process and / or scrimped on resources.
		So, if working faster and harder does not consistently deliver desired and even improved results, what should we do instead? The answer depends if you are operating in a push or pull demand system. Reason we divide our effort such, is that the push environment is predictable and more amenable to operating under Takt time, while a pull environment presents challenges and requires more effort. The successful process design person will be ahead of the game and have more than one process ready, plus will always be experimenting and searching, in an attempt to uncover new methods that can create the desired product in less time and using fewer resources.
		For the push environment, one can count on stability, where processes are left to run for long periods of time, allowing one to gain greater amounts of experience and learning over time, which is then applied back into the process design. When a new method is discovered, then it is deployed, measured and determined whether to adopt it or not. If adopted, the process is left to run and the Takt time measured, so one has a base line in which to operate under, to see how process changes and learning affects the new process over time.
		The same concept goes for the pull environment, but one will want to have more than one way to perform the tasks, to deal with varying levels of demand. We have observed over time that there is more than one way to perform a business task, and there seems to be a trade off between process rate, quality, disruption, and therefore risk. Essentially it is these last factors in the pull environment that are not nearly as present in the push environment. The idea is to run your processes in the least disruptive, most predictable manner. When demand rates increase, then one will want to be in a position to change processes in response. This was shown in the call center case during heavy load periods, where work can be broken up into smaller steps and assigned to different personnel in process sequence, calls routed to subject matter experts, callers put on hold, leading up to short responses (reduction in quality), requests to call back later (or have your own people do the call backs), and finally to dropping and refusing calls.
		In all of these scenarios, there was no broadcasting of the cycle time through clocks. Rather, managers or team leaders would be monitoring the load and setting into play the appropriate process types in response to load changes. In every case, the individual task would still have a cycle that should express itself naturally through its Takt time. The individual tasks should not themselves be disruptive, but the splitting up of tasks may require additional coordination to move work between a greater number of tasks that may not otherwise need to be handled during low demand periods, which may require dedicated personnel or software to supervise.
		As you can see from above, what we want is to know is that demand has changed, and only need to deploy a more disruptive and riskier process as demand increases. If we can control demand rate (as in the push environment), then we have the ability to rely upon less riskier processes. So the answer to using a Takt Time Clock is to manage your processes smarter and drop the idea. Also, improvement will come about naturally, mainly from the learning curve, which we detail in next question below).
		2- How is Takt time impacted by the learning curve?
		In our articles on Takt time, we have mentioned that a repetitive task has a natural rate of operation we call the Takt time, and it is up to the process designer to discover this rate. However, we also need to point out that this rate is not fixed, and most often than not, the Takt time will decrease over time, in a deliberate but appreciable rate. This phenomenon is a direct cause of the learning curve.
		We will not delve into the details of the learning curve here. Suffice it to say that it is the recognition that any repetitive task that people are involved with, both directly with manual labor and indirectly in running automated processes, can be executed faster over subsequent cycles. The idea here is that through experience and observation of outcomes, feedback can be applied to the process in order to facilitate a more efficient execution in the future. The learning curve is also a beneficiary of the 80/20 rule, which is why the cycle times right after the change can improve faster then cycles executed further away from the change implementation.
		An important point about the leaning curve is that its benefits are not automatic, the task operators and designers must be willing to use experience to improve the process, and then recognize the individual points of improvement that can be made, finally deploying the effective changes. The learning curve can be stymied, which is typically a management endeavor. Obviously, we promote the use of the learning curve, as a method of reducing waste and creating a leaner process.
		The point we make here concerning the use of the learning curve with Takt time, is that this is the only method we promote for improving Takt time rate. Otherwise, if the process rate for a given task does not meet your needs, then the task will need to be redesigned. Takt time will improve slowly through the learning curve, and should never be counted upon as the sole mechanism of improving process operation. Rather, these rate gains should be looked upon as a windfall and taken when offered. We frown upon forcing rate improvements by speeding up the steps within a task without redesigning the task. Especially, if the task is manual, you are asking for difficulties that can easily escalate to a crisis when pursuing speed-up as your only process improvement methodology.
		Another point about the effects of the learning curve on Takt time is that you will always need to monitor your entire operation as an integrated entity. This is required since the learning curve will improve operations unevenly, causing conflicts to arise that need to be mediated, since various tasks can speed up at various times, to the point that process lags have shifted and new deadlocks appearing, causing new production dilemmas. Use constant vigilance!

		Return to Cycle vs. Takt Time page	Navigate to home page

All rights reserved.

All site content copyright © 1997-2010 Artige Company      Legal       Privacy Policy

Last updated: 23-March-2010 21:48z