TIME-BASED, DEMAND-PULL PRODUCTION

BACKGROUND

[0001] Since the early 1980's, the benefits of producing a given production volume throughput with the minimum amount of inventory have been well

documented. Beginning with the Just-in-Time methodologies, using Kanban cards for inventory replenishment, to Demand Flow methodologies, like that posited by Suri (Paired-cell Overlapping Loops of Cards with Authorization, or POLCA) of the Quick Response Manufacturing Institute in 1998, and that patented by Costanza (US 6,594,535) in 1999, and more recently J DA Software's patents of 2009 (US

8,989,879) and 2015 (US 8,965,539). See also R. Suri, "QRM and POLCA: A

Winning Combination for Manufacturing Enterprises in the 21 ^st Century," Technical Report, Center for Quick Response Manufacturing, May 2003.

[0002] A goal of production businesses is a high return on investment. Thus, if the same throughput (return) can be achieved with a smaller investment (inventory), methods of reducing inventory for a given throughput provide businesses with a competitive advantage.

[0003] The use of Kanban scheduling was championed early by Toyota Motor Company in its high volume, low variety automobile factories. Kanban cards were assigned to batches of inventory and when consumed at a production operation, they were sent back to be replenished at an upstream operation. Using this

"demand-pull" method, production at an operation would only take place with an authorizing Kanban, and this resulted in:

1 . Limiting the amount of inventory in a factory to that determined by the

number of Kanbans issued; and

2. Stopping manufacturing at upstream operations if production was

stopped at some stage of manufacturing. This is because the

Kanbans would stop flowing upstream. This synchronized production and enhanced quality, and reduced cost, because if a defect was found at one stage upstream, production would be automatically stopped until the problem was solved.

[0004] Suri recognized in his 1998 innovation that the Kanban method does not work well in high variety production environments. This is because any individual part may only be made once, or at least infrequently, and replenishment based on batches of similar units is not possible. To implement his push-pull system (POLCA), the pull-signal is based on the number of production hours that a batch of work (the Work Order, or WO) represented in its destination Work Center (WC). This normalizes all production parts based on the hours required to accomplish the work in a given WC.

[0005] POLCA has been successfully implemented and has been shown to be a solution to the high-variety production problem. This disclosure describes another approach to this problem that is based on matching the flow times of WOs to their downstream demand requirements.

SUMMARY

[0006] This section provides a general summary of the disclosure and one or more of its advantages, and is not a comprehensive disclosure of the full scope of all of the features, of all of the alternatives or embodiments or of all of the advantages.

[0007] Disclosed herein is a WO flow control system for a production facility having WCs forming alternative flow paths for WOs. The system can include a computer system configured for analyzing the WOs in the WCs of the production facility. The computer system includes a main computer and an individual computer for and operatively connected to a respective one of the WCs and also to the main computer. The analyzing includes for each WC and the separate computer connected thereto: (1 ) identifying in the queues of all upstream-adjacent WCs the WO that should next be authorized for production based on a priority-setting rule ("Next WO"); (2) calculating the time for the Next WO to arrive ("time-to-arrive") at the next WC and comparing the time-to-arrive to the time to process all the work ahead of the Next WO ("need-time"); and (3) authorizing work on the Next WO if the time- to-arrive is greater than or equal to the need-time. As an example, the priority-setting rule can be a First-in First-out (FIFO) rule wherein the WO that is not yet authorized, and arrived in its queue before all other unauthorized WOs in the upstream-adjacent WC queues is the Next WO. The WCs, as examples only, can be gluing, folding, sanding or painting WCs.

[0008] A production method is herein disclosed that can include identifying for a given WC of a plurality of WCs in a production facility, in the queues of all upstream- adjacent WCs the WO that is next to be authorized for production based on a priority-setting rule ("Next WO"). The method can also include calculating the time for the Next WO to arrive ("time-to-arrive") at the given WC and comparing the time-to- arrive to the time to process all the work ahead of the Next WO ("need-time"). The method can further include authorizing work on the Next WO if the time-to-arrive is greater than or equal to the need-time. The priority-setting rule can be First-in First- out (FIFO), so the WO that is not yet authorized, and arrived in its queue before all other unauthorized WOs in upstream-adjacent WC queues will be the Next WO. The time-to-arrive can include the processing time for the Next WO at its current, upstream-adjacent WC plus the travel time from that WC to the given WC.

[0009] Also disclosed herein is a production method which includes: identifying a WO in a WC that has the highest priority ("the highest-priority WO") of any WO in a queue of a WC which is upstream adjacent to a WC at issue in a production plant; determining whether the time for the oldest WO to be processed and delivered to the WC at issue ("time to arrive") is greater than or less than the time until needed ("need-time") at the WC at issue; and if the time to arrive is greater than or equal to the need-time, authorizing the highest-priority WO to be worked on by its WC.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The drawings described herein are for illustrative purposes only of selected aspects of the present teachings and not all possible implementations, and are not intended to limit the scope of the present teachings.

[0011] FIG. 1 is a schematic of sample product workflows and WCs of a system of the present disclosure.

[0012] FIG. 2 is a schematic similar to that of FIG. 1 but for an exemplary print/mail shop.

[0013] FIG. 3 is a diagram of a demand-pull workflow of the schematic of FIG. 1 .

[0014] FIG. 3A is a chart showing examples of flow time calculations and WO authorizations (all values in hours).

[0015] FIG. 4 is a WO depiction which includes serial lot-splitting.

[0016] FIG. 5 is a schematic of an exemplary system architecture of the schematic of FIG. 1 .

[0017] FIG. 6 is a block diagram of an exemplary system architecture of the present disclosure.

[0018] FIG. 7 is a demand-pull system logic diagram of the present disclosure with no queue management.

[0019] FIG. 8 is a system diagram and flow chart of business processes of the present disclosure.

[0020] FIG. 9 is a demand-pull test logic flow chart with queue policy

management (for better visual management in the factory) of the present disclosure.

[0021] FIG. 10 is an exemplary graph illustrating completions by WC of FIG. 1 .

[0022] FIG. 1 1 is a graph illustrating cycle time and inventory of WOs by WCs of FIG. 1 .

[0023] FIGS. 12-19 illustrate work pieces at different stages of the print/mail shop of FIG. 2. [0024] FIG. 12 illustrates an 1 1x17 sheet having a letter and other flyer notes printed thereon at the Print WC of FIG. 2.

[0025] FIG. 13 llustrates a letter in the Fold WC.

[0026] FIG. 14 llustrates a folded letter in the Insert WC.

[0027] FIG. 15 llustrates three post cards in the Print WC.

[0028] FIG. 16 llustrates a cut, printed post card in the Score & Fold WC.

[0029] FIG. 17 llustrates a cut printed sheet in the Score and Fold WC.

[0030] FIG. 18 llustrates the sheet of FIG. 17 in the Glue WC.

[0031] FIG. 19 llustrates a printed cut sheet in the UV Coating WC.

[0032] FIG. 20 llustrates an exemplary embodiment of a computing device

DETAILED DESCRIPTION

I. Introduction

[0033] The time-based demand-pull system ("demand-pull system") technology of the present disclosure provides an implementation of demand-pull scheduling for various manufacturing operations/systems/factories. It can work in conjunction with a Material Resource Planning (MRP) or Enterprise Resource Planning (ERP) system, which creates production WOs and houses associated data, such as workflows and operational standard hours, to pull work through a factory with results similar to that of POLCA. The subject demand-pull system pulls work into a downstream WC by matching the Flow Time of the WO to the Need Time of the downstream WC. Need Time is the time at which the downstream WC will be ready to process the WO, and Flow Time is the time it will take the WO to reach the downstream WC. Matching these two values results in seamless flow and reduced inventory. While this may be simple in concept, the complexity of work flow in high-variety environments and the dynam ic nature of their production activities, results in overwhelm ing execution difficulty without the aid of computing hardware and software.

[0034] Using data from MRP that is introduced into the demand-pull system with the WOs, as well as data that is created internally, the demand-pull system is able to "reach back" for work from upstream operations and identify exactly which WO should be processed and when. It does this by creating virtual queues at each WC, identifying the optimum amount of work hours for the queues, then reaching back to identify whether authorized upstream WOs will properly replenish the queues and, if not, authorizing additional upstream WOs to be processed, if available. Matching the Flow Time of the next WO to be authorized with the Need Time of its downstream WC assures that work arrives just-in-time. The present disclosure describes this method. II. Production Priority-setting Examples

[0035] There are numerous methods of setting priorities in a production environment, too numerous to discuss in total in this paper, but some of the more prevalent methods are discussed below.

First-in, First-out (FIFO)

[0036] One means of determining the priority of authorizing work in queue at a given WC is FIFO. By this method, the priority of work is determined chronologically by examining the arrival time of the WOs. The WO that arrived at the earliest time will be the next WO to be authorized for production processing.

Due-Date Slack

[0037] Another method of determining the priority of authorizing work in a queue is the difference between the time remaining until its scheduled completion date, aka due date, and the time remaining for its Flow Time through the production process. By this method, a WO that is due to complete in five days, for example, and has five days of remaining processing time would have a higher priority than a WO that is due to complete in five days and has three days of remaining processing time. The logic is that the latter WO has two additional days of slack in its production schedule, while the former WO has no slack and must be processed immediately to complete on time.

Expedite Policies

[0038] Another prioritization method is to assign a higher priority to WOs that are being expedited due to management policy. This may happen if the customer of the WO has paid an expedite fee, or the WO is a replacement for a previously delivered WO that failed quality or safety standards. Management may prioritize a customer's work for a myriad reasons such as military materials during a time of war. By this method, the expedited WO is always authorized for production ahead of WOs that are not being expedited.

Other Priority-setting Scenarios

[0039] There are other settings in which certain products, or customers, may have higher priority than others. These priorities may be assigned numerically to WOs, such as a 1 - 10 with 1 being the highest priority and 10 being lowest. In this scenario, WOs for products that are Priority-1 would receive preferential treatment and be authorized ahead of WOs with Priority-5 products. [0040] Regardless of the system for setting priorities, for a given WC, the demand-pull system finds the highest-priority WO in its Upstream-Adjacent WCs and applies its Flow Time to Need Time comparison method to determine whether to authorize the WO for production.

III. FAFP Work Flow

[0041] When looking at work flow through a factory from the perspective of minimizing cycle time and honoring demand-pull policies, work should be processed on a first authorized, first processed (FAFP) basis. Deviating from this policy can result in an increase in the average cycle time, unless batching of WOs will reduce their aggregate cycle times due to machine capacity. For an example of the latter situation, a machine may be capable of simultaneously processing ten pieces, and if there are two five-piece (or fewer) WOs, they could both be processed at the same time to reduce their aggregate cycle time, improve efficiency and maximize capacity.

[0042] More common examples of "jumping the queue" include changing priorities at the WC due to material shortages and preferential treatment of WOs to

accommodate customer requests, management priorities or operator training. But because some WOs will spend more time in queue than they otherwise would, processing work out of chronological order is not optimal and can be counter- productive. Although the WOs that jump the queue will spend less time in queue than they otherwise would, the additional non-value-added time spent prioritizing each WO, in addition to the added time spent in the queue for WOs that are not prioritized, results in higher cycle times and more turbulent flow of the manufacturing process/operation.

[0043] Given this principle, with a pool of work to be done in a WC, it is usually desirable to work first on the WO that is first authorized, based on demand, at the WC. This would be the WO with the earliest-dated work authorization (or Pull-Tag (PT)).

[0044] To enable this policy, WOs should only be started when all the requisite resources are available, that is, never started into production if a resource shortage is present. If a shortage is present, it may not be possible to process the WO with the earliest dated PT, which can cause turbulence in the production flow.

IV. Demand-Based Production from a Flow-Time Versus Need-Time

Perspective

[0045] From a flow-time perspective, WOs arrive in a WCs queue at precisely the time when they are needed to be worked on. This minimizes both production cycle- time and inventory investment. The desired time for the next WO to arrive for processing is when the currently-authorized work in a WC and its upstream-adjacent (UA) WCs has been started into the WC. This assumes that demand exists for the WO at the next downstream work cell.

[0046] In FIG. 3, for example, WCs #130 and #135 would both be considered UA for WC #145 (refer to this destination WC as WC _N ), since work from both of these WCs flows into WC #145. In this construct, WOi can be considered to be a WO that has not yet been authorized (assigned a Pull-Tag) for processing in its WC (WC #135), and that has the highest priority of any WOs in any WCs that are UA to WC #145. In this case, since WOi is in WC #135, WC #135 can be referred to as WC _N- i _. The processing Flow Time, the elapsed time necessary to complete processing, for WOi in WC _N- i plus its transit time from WC _N- i to WC _N should be equal to, and certainly not greater than the time required to completely flush the WOs ahead of it through WC _N 's queue and first operation. That is the time that WC _N will be ready to begin processing it.

[0047] This timing can be modeled as shown in FIG. 3. WOi can be assigned a PT when the sum of the Flow Time of WOi in WC _N -i (twoi, n-i) plus its transit time from WC _N- i to WC _N (ΪΤ _, Ν-Ι _, Ν) [this is the time it takes WOi to arrive at the WC _N queue, once it is started into WC _N- i] is equal to or greater than the remaining Flow Time of all the previously-authorized WOs ahead of it and destined for WC _N or already in the WC _N queue.

[0048] This time can be modeled as the time to process the WO with the least remaining Flow Time in WC _N 's first operation (t _{R N} ) [this is the elapsed time until the next production start will take place at WC _N , thus pulling the next WO from the WC _N queue] plus ((the sum of the WC _N Flow Times of WOs in the WCN queue (Q _N ) and the sum of the WC _N Flow Times for all UA WOs already authorized (YN)), divided by the number of capacity units at WC _N (C _N ) [this is the time it will take to process all upstream and queued WOs through WC _N , accounting for the fact that some WCs may have the capacity to simultaneously work on multiple WOs and neglecting the transit time between cell pairs]), plus the remaining Flow Time at the WC in which WOi resides for the WO with the least remaining Flow Time of all WOs that are in the WC _N- i first operation (t _{R N-} ) [this is the time it will take for the first, currently in- process, UA WO to complete processing at WC _N- i s first operation and trigger the start of the next WO into WC _N- i _], plus the quotient of the authorized WC _N- i queue Flow Times (t _QiN -i) and the number of capacity units in WC _N- i (C _N- i)) [this is the time required to process all the currently-authorized _W CN-I queue through WC _N- i's first operation and thus the time at which WOi would be started into the WC _N- i WIP area]. [0049] r, when:

[0050] Where all variables are specified in the Section IX Table of Definitions.

[0051] Multiplying through by CN and rearranging to sim lify:

[0052] When this equality is true, then the next WO (WO-i) should be authorized (assigned a Pull-tag). This is what the demand-pull system does by continuously monitoring the state of the factory in the context of the parameters of this equation. Some of these parameters, like the Standard Process Hours that are used to determine the Flow Times that comprise come directly from the ERP/MRP system, while other parameters are continuously monitored / calculated by the demand-pull system to complete the algorithm and assign the Pull- Tags as appropriate for the production process.

V. Examples with Reference to FIGS. 3 and 3A

[0053] The examples set forth in the Table of FIG. 3A illustrate the WO

authorization process resulting from the pull-test in different circumstances. In all the examples, a set of WCs such as shown in FIG. 3 is used. There are two WCs (WC 130 and WC 135) that feed into a third WC (WC 145) and the downstream WC (WC 145) is presumed to be healthy (reference the discussion of Section IX. Work Center Performance Testing) so that the pull-testing for this WC is active. The interrogation of its upstream WCs finds that WOi is the WO that is currently unauthorized, has the highest priority, and is therefore the candidate to be authorized. The authorization is based on whether the time for this WO to reach WC 145's queue is equal to or greater than the time required to consume the work that has already been authorized ahead of WO-i.

[0054] In Example 1 , the authorization test is affirmative. The time required for WO1 to reach WC 145's queue is its Flow Time in WC 135 (four hours) plus the transit time required to get to the next WC (ten hours). It will therefore take fourteen hours for this WO to reach WC 145 once work on it has started in its current WC, WC 135. Therefore, the question is "Are there more than fourteen hours of work for WC 145 ahead of WO-i?" To calculate this, the time until the next WO is started is added into WC 145 (tR,N), two hours, plus the time to consume the authorized work ahead of WOi that is destined for WC 145 ((Q _N + YN)/C _n ), seven hours, plus the time until the next start in WC 135 (t _RiN -i) _, two hours, plus the time required in WC 135 to consume the work ahead of WOi in its queue (t _Qi N..i _/ C _N ..i) _, three hours. The sum is fourteen hours, which is equal to the fourteen hours required for WO1 to reach WC 145's queue and, therefore, WOi is Pull Tagged and authorized for processing.

[0055] In Example 2, the processing Flow Time for WOi in WC 135 is increased to six hours and therefore it will take an additional two hours for WOi to reach WC 145's queue, or sixteen hours. Since 16 >14, the test is affirmative and WOi is again authorized for processing in WC 135.

[0056] In Example 3, the currently-authorized work ahead of WO-i , destined for WC 145 (Y _N ), is increased to twelve hours as compared to the nine hours in Example 1 . The three hours of additional work ahead of WOi means that WOi is not required in the time it will take to arrive and results in the authorization test failing; that is, WOi is not authorized for processing.

[0057] In Example 4, the transit time between WC 135 and WC 145 is reduced from ten hours to one hour. This means that WOi will arrive nine hours sooner than it would have in Example 1 and the authorization test fails to authorize WOi in this case. It fails because, if authorized, it would arrive sooner than it is needed.

VI. Calculating Flow Time in a Work Center

Using Standard Labor/Machine Processing Hours:

[0058] In the case where all units in a WO are processed as a discrete set, the Flow Time of a WP in a WC is equal to the Standard Process Hours of the WO.

Adjusting for Serial Lot-Splitting

[0059] In the case where there are multiple, and serial, operations within the WC and the WO is split into multiple batches within the operations, the Standard Process Hours is adjusted to reflect the actual Flow Time. The situation is illustrated in FIG. 4 for a WO of twenty units with three serial operations within the WC and a batch size of five.

[0060] For example, a WO with a Standard Hour per Unit (HPU) of one-hour per operation, or three hours total. The total Standard Hours for this WO is then sixty hours and, if worked on at a single operation, or even moved from operation-to- operation as a single batch, the Flow Time would indeed be sixty hours. But when the WO is split into smaller batches, and moved from operation-to-operation as each batch is completed, the simultaneity of work activities will tend to compress the Flow Time. In the example shown above, each batch would move every five hours, the operation cycle-time or takt time, and the WO would complete queue-to-finished after six cycles, or just thirty hours, 50% of the Standard Hours. Thus, this Flow Time compression effect should be taken into account in the case of sequential batch- processing. [0061] The Flow Time of a WO at a WC is an essential component in this disclosure and is embodied in the previously defined variables

To account for the serial-lot-split case illustrated above, an

adjustment to convert Standard Hours to Flow Time is applied to these factors on a WO-WC basis.

[0062] In particular, an adjustment is made and it should take the form of a ratio that can be applied to the Standard Process Hours:

[0063] This ratio will vary at each WC and for each WO based on batch sizes and numbers of operations and is derived as follows:

[0064] The batch size that is processed through the WC for a WO is the quantity of units within the WO divided by the number of batches into which the WO is to be split, BN.

[0065] In a balanced line, the operation cycle-time for each batch is equal, or nearly equal, for all operations and is the HPU for the WO divided by the number of operations, ON, (to give HPU per operation) multiplied by the batch size. Expressing this in terms of a single batch gives:

[0066] The Flow Time, WO _F T _, is the amount of elapsed time between the first Batch starting at the first operation and the last Batch finishing at the last operation. This can be broken up into two segments. The first segment is the amount of time that it takes to complete all batches through the first operation, which is the "Clear Time". The second segment is the amount of time it takes to complete all batches through the rest of the operations, which is the "Flush Time." Flow Time is the sum of these two times:

[0067] Clear Time can be computed as the number of Batches times the OHPB-

[0068] Or

[0069] Alternatively, this variation is used to calculate Q _N , t _R , _N , and t _R , _N- in the pull-test algorithm, by substituting equation 3 for the value of O _H PB, and Clear Time can be expressed as:

[0070] The Flush Time is the time required for the last Batch to get though the rest of the Operations, not counting the first one since it was counted in the Clear Time, or

[0071] Adding the two segments together yields the following:

[0072] The denominator of the ratio, R from equation 1 , Total Standard Hours (WOSH), will equal the sum of the amount of time that each batch spends at each operation. This can be expressed as a simple multiplication of the number of batches by the number of Operations and by the Operational hours per batch.

[0073] Or

[0074] Now that both the Total Standard Hours and Flow Time are represented in terms of Quantity, Number of Operations, and Batch Size the ratio between the two values can be calculated. This ratio is the conversion factor for converting Standard Hours into Flow time from equation 3: [0075] Substituting the results from equations 1 1 and 13 into equation 3:

Example

[0076] An example follows:

[0077] Using equation 2, these values yield four for the number of batches that will flow through the WC:

[0078] Using equation 10, this gives a value of Total Standard Hours of sixty:

[0079] The Flow Time, equation 9, has a result of thirty:

[0080] Ratio R, equation 1 , has a value of 0.5:

[0081] A simplistic visualization of the flow of batches through a WC on the right plots Operations on the horizontal with time on the vertical. The numbers symbolize the Batch number and their flow within the WC. The boxes symbolize all of the Standard Hours. Notice that if all the columns are shifted up to form a rectangle the Total Standard Hours formula becomes a simple area calculation.

[0082] The other key visualization here is the Flow Time. The height of the vertical axis is the Flow Time.

[0083] The implications for the present system are that when serial lot-splitting is operational, this calculation is done for each applicable WO and WC, and the values of and are adjusted accordingly. References to Flow Time for a WO in this disclosure refer to:

Adjusting for Parallel Lot-Splitting

[0084] When CN or CN-I is greater than 0, WOs may be split and run through multiple paths in the WC. This causes Flow Time to contract depending on the number of paths through which the WO is processed. When a lot is split when started, the present system first checks to validate the number of paths through which it is split versus the value of C in the WC, and then adjusts the Flow Time based on the ratio of the largest quantity sub-lot versus the # Units in the WO, Rc

[0085] In this case, R can be further generalized as

[0086] Or, from equation 16:

Other Lot-Splitting Cases

[0087] There are other variations and combinations of lot-splitting cases that wil also result in deviations between Flow Time and Standard Process Hours. The derivations of these adjustments are not presented herein. VII. Demand-Based Production from a Work-Volume Perspective

[0088] When looking at authorizing work in upstream stages of production, the traditional Kanban system establishes quantity buffers, or queues, at each WC. Then when the buffer quantity hits a minimum value (the Queue Policy), the Kanban card is returned to its originating WC for replenishment. While this unit-quantity buffer does not work well in a high-variety production environment (Suri, et al), the concept of a Queue Policy can still be a useful management tool if expressed in work-hours as opposed to unit-quantities.

[0089] Within the present demand-pull system, the concept of a manageable Queue Policy is coupled with the demand flow concept of Section VII below, to create a management framework for setting inventory levels for the queues at each WC. Disclosed herein are a WC buffer, or queue, and a "policy" that provides for adjustment of the inventory in the factory. For this reason, the WC is conceptualized as a two-part entity in FIG. 1 , the Queue and the Work-in-Process (WIP) area, and a goal herein is to minimize the hours in the Queue and maximize throughput.

[0090] With FAFP processing in mind, this trigger can be expressed

mathematically for any given WC "N" (WC _N ), except the first WC in a production process, as follows:

[0091] Where all variables are specified in the Section IX Table of Definitions.

[0092] When this inequality is true, a Pull-tag is assigned to WO-i . Or, more completely, an upstream pull-authorization will be attempted on WOi whenever the amount of work in WC _N 's queue plus the work upstream that has already been authorized and destined for WC _N is less than the Queue Policy (X _N ). But the pull- authorization will not be completed, and a PT assigned, unless the amount of work represented for WC _N by WOi (W _N ), when added to the current queue (Q _N ) and currently-authorized UA WOs (either in UA queues or in UA WIP) (Y _N ) will not exceed the Queue Policy, X _N .

[0093] Assigning a precise value to the Queue Policy (X _N ) can now be

accomplished within the algorithmic context of Section III set forth above. VIII. An Optimum Queue Policy

[0094] The formulae from Sections IV and VI can now be combined to solve for the Queue Polic (X _N ). From Section VI, equation 22:

[0095] From Section IV, equation 2:

[0096] Therefore

and the Queue Policy for WCN is given by:

[0097] From Section VI, this value of X _N can be used to assign a Pull Tag to WOi when the sum of its Clear Time in WC _N (W _N ) + the queued Clear Times in the WC _N queue (Q _N ) + the sum of the Clear Times at WC _N for all authorized UA WOs' (Y _N ) is less than or equal to that value of X _N . This formula, in the limit where all flow-times are 0, sets a "floor" of W _N hours, which is needed to avoid "starving" a WC by setting a maximum Queue Policy that is less than the number of hours represented by the next WO to be authorized. All of the stated terms are "knowable" quantities within the construct of most ERP/MRP systems so that this construct is easily implementable.

[0098] The question can be raised as to why the formula from Section V is reintroduced to define a pull algorithm, or why the flow formula

cannot just be used to assign Pull tags. The answer is primarily a matter of visual management in a lean environment. The concept of a maximum Queue Policy is a manageable and understandable concept in the factory environment and one for which the present technology provides management over-rides and/or adjustment factors to accommodate the realities of variability in the individual WCs. This pull-system conforms to the idea that when inventory falls below a pre-determined policy level, a replenishment signal is sent, yet at the same time, by using ideal flow times, it is forcing queued inventory toward zero. IX - Table of Definitions

X. An Automated Demand-Pull System Embodiment

[0099] FIGS. 5 and 6 illustrate an embodiment of the demand-pull system of the present disclosure and which can be implemented using a software system with a database. In this embodiment, a .NET service bus and MSSQL database running on a networked Microsoft Windows server are connected via the local area network (LAN) to individual clients in the various WCs. These clients contain the browser-based AngularJS user interface and connect with the service bus through its Application Programming Interface (API).

[00100] Likewise, other enterprise-level software applications (ERP, CRM and so forth) interface with the software implementation and can inject new WOs and extract data on those WOs as they flow through the factory. The demand-pull system can include an Enterprise Resource Planning (ERP), Materials Resource Planning (MRP) or other similar system that creates WOs for parts to be produced by the factory. This system should also be capable of storing the associated operation sequence (Workflow), the WCs associated with each operation in the Workflow, standard processing hours per unit (HPU) at each operation, and quantities of units (# Units) to be produced.

[00101] WOs and their associated data (Workflows, HPU, # Units, and Batch sizes, if applicable, at a minimum) are then introduced into the demand-pull system. Initially, WOs have a Status code of "Pending" and when ready to begin production, the WOs are accepted into production through the demand-pull system user interface, which action changes the Status to Open." When a WO is accepted, a time-stamp is created and it is "moved" to the Queue of the first operation in the Workflow. This is the beginning of the "demand-pull" production process.

[00102] When demand is detected at the next WC in the WO's Workflow, the WO is assigned a Pull Tag, which authorizes work activities at the first operation in its Workflow. This "detection" can be based on an affirmative result to the

aforementioned test from Equation 2:

[00103] Where, in this case, N is the next WC in the WO's Workflow. This test is done in the demand-pull system software through continuous polling of all WCs in the factory, as well as instantaneously any time a WO is Started or Finished at a WC. In other words, when a WO is started into production at a given WC, the system immediately "looks" upstream for a candidate WO to refill its queue. Likewise, when a WO is completed and moved to its subsequent WCs queue, a pull-test is performed both upstream and downstream to detect demand. When a pull-test is performed on a WC, a record can be logged with a time-stamp and the order of polling of the WCs can be based on this time-stamp. The WC with the oldest time- stamp can be polled first. The polling frequency is a user-defined interval in the demand-pull system.

[00104] All the parameters of the demand-pull system are tracked, or calculated (such as by the software) on each execution of the Pull-test. The relevant parameters can include:

Calculated:

[00105] In addition, some of the calculated values are based on other parameters that are system generated or stored in the database. [00106] Specifically:

t _{R N} - is the remaining Clear Time for the WO in WC _N with the least Clear Time remaining and is calculated as the difference between the Clear Time for the relevant WO in WC _N and the elapsed time since the WO was started. Therefore, the system captures the Elapsed Processing Time for each WO. Then:

t _{R N} = Clear Time - Elapsed Processing Time

[00107] Likewise, t _{R N-} is a similar calculation done on the WOs in WC _N- i to determine the remaining Clear Time for the WO in WC _N- i with the least Clear Time remaining.

[00108] t _{Q N-} is the sum of the Clear Times for WC _N- i for all WOs in its

queue that have been assigned a PT. Since this calculation depends on the demand-pull system's ability to determine which WOs have WCN as the next

WC in their Workflow, the demand-pull system stores all the operations in the

WO's Workflow as well as the sequence of those operations and their

associated WCs. Then it stores in its database all PTs, their associated WOs and WCs so that it can identify the WOs that are UA to WC _N and that have

been authorized for production in their current WC (assigned a PT).

[00109] Likewise, Y _N relies on calculating its Clear Times for WC _N and relies on the association of PTs. This calculation knows that:

a. a PT has been assigned to the WO; and

b. the next WC in the WO's Workflow is WC _N - so for that reason, the demand-pull system has stored all the steps in the WO's Workflow as well as the sequence of those steps.

[00110] Q _N and W _N are calculated on the basis of Clear Times, since no PT association is needed for these two values.

[00111] A flowchart of the pull-system logic of the present disclosure is shown in FIG. 7. Explanations of the terms used therein are found in the Section IX Table of Definitions.

XI. Work Center Performance Testing

[00112] When a problem reduces production rates in a WC, the WOs in its UA WCs may stall. As previously discussed, the pull-test assumes that all WOs in the WC _N queue will be authorized for work prior to the arrival of WOi . Because of this, all WOs, Pull-tagged (authorized) or not, are included in the pull-test that calculates the time at which WC _N will be ready to consume WO-i. If some of this work is "stuck" and not authorized for work in a timely fashion, it can delay the arrival of WOi and "starve" the WC of work and also starve the problem WCs sibling WCs of work if they share WC _N in their Workflow. [00113] Production problems such as this can be caused by insufficient capacity, newer employees not meeting time standards, material quality or availability problems, or quality standards not being met. All these causes, and more, can affect the Flow Time and throughput of a WC. The demand-pull system must detect these problems and impose a Hold (the pull-test algorithm ignores WOs that are on Hold) on WOs in WCs that are upstream of the problem WC so that they do not throttle upstream pull signals and thereby starve their sibling WCs.

[00114] An indication of a problem in a WC is the consistent inability to meet the work standards (Standard Process Hours). Each WCs performance is therefore measured at the time it is polled for pull-testing, and a performance value of standard hours versus actual hours is computed and compared to a threshold, above which triggers a Hold for all upstream WOs and notifies the WC management. Stated more specifically, prior to running the pull-test algorithm for a given WC, a WC

performance check is done, whereby the sum of the actual hours for all in-process WOs in the WC is compared to the sum of the standard hours for these same WOs. If this comparison is more than a configurable percentage, a Hold is triggered for all upstream WOs that are destined for this WC and the pull-test is skipped. This process is self-correcting since in the next polling round for the WC, if the problems have cleared up, the Hold would be released and flow would begin again.

[00115] The test:

If:

Then the WC is "healthy" and pull-testing is done normally. If:

Then the WC is "un-healthy", pull-testing is suspended and all upstream WOs destined for this WC are put on Hold.

[00116] Where P is a configurable system variable, e.g. 1 .5 (meaning the actual hours worked for all WOs in the WC is currently 150% of the standard hours).

XII. Other System Features

[00117] When demand for a WO is detected by the system, a PT is created in the database and associated with the WO and the relevant WC. Once a PT is assigned to a WO, the WO can then be Started into the WC by the WC staff and the system begins to record the WO's processing time. No work activities can be Started on a WO unless it has an associated Pull-Tag. [00118] The Pull-Tagging algorithm is executed automatically when a WO is Started or Finished at a WC. This allows PTs to be created immediately after Need Time is known to have changed rather than wait for a polling system to create the PT at a later time. The Pull-Tagging algorithm will target the specific WCs where Need Time has changed. When a WO is Started the algorithm will be executed at the WC at which the WO is started to allow UA WOs to be pulled. When a WO is Finished the algorithm will be executed at the next downstream WC for the WO to allow it to be pulled immediately if appropriate. In this way, the system instantly identifies and authorizes new incoming WOs to assure a steady flow of production.

[00119] Once the work activities are completed in that WC, the WO is Finished by the WC staff, the PT is closed, and the WO is moved to queue of the next WC in its Workflow. When the WO is Finished, the staff may enter any units that were lost due to scrap or yield loss along with the predefined scrap codes that provide information on the cause for the losses. Each "pull" of a WO creates a unique PT, which is opened for the duration of the activity in that WC, then closed when the WO is moved to the next WCs queue. The PT information is then retained in the

database for reporting purposes.

[00120] These calculations also require that the system track the current number of units in a WO in an environment where units may be lost to scrap, yield loss or other reasons during the production process. The demand-pull system also accounts for losses during production. The reasons for the losses are also captured in the database for management and quality control purposes.

[00121] FIG. 8 is a flowchart describing the operation of the demand-pull execution system.

[00122] Software of the present demand-pull system can have an open API, so all data associated with WOs, including its status, quantity, and location, can be interrogated by external systems at any time through an API call. The demand-pull system can also have a series of built-in metrics for management oversight, two of which are shown in FIG. 8 and FIG. 9, and a simple Javascript framework (angular- charts.js) for creating new metrics.

[00123] That is, FIG. 7 is a logic flow chart of a software embodiment of the present disclosure without a Queue Management feature. FIG. 8 is a work-flow diagram depicting the activities in a typical factory environment and the resulting actions in the D-P System software. And FIG. 9 is a logic flow chart of the software embodiment with a Queue Management feature.

[00124] FIG. 10 is an exemplary graph illustrating completions by WC of FIG. 1 . [00125] FIG. 1 1 is a graph illustrating cycle time and inventory of WOs by WCs of FIG. 1 .

XIII. Working Example

[00126] FIGS. 12-19 illustrate work pieces at different stages of the print/mail shop (production facility) of FIG. 2 of the present disclosure.

[00127] FIG. 12 illustrates an 1 1x17 sheet 40 having a letter and other flyer notes printed thereon at the Print WC of FIG. 2.

[00128] FIG. 13 illustrates a letter 50 in the Fold WC.

[00129] FIG. 14 illustrates a folded letter 60 in the Insert WC.

[00130] FIG. 15 illustrates three post cards 70 in the Print WC.

[00131] FIG. 16 illustrates a cut, printed post card 80 in the Score & Fold

WC.

[00132] FIG. 17 illustrates a cut printed sheet 90 in the Score and Fold WC.

[00133] FIG. 18 illustrates the sheet 100 of FIG. 17 in the Glue WC.

[00134] FIG. 19 illustrates a printed cut sheet 1 10 in the UV Coating WC.

[00135] FIG. 20 illustrates an exemplary top level functional block diagram of a computing device embodiment 2000. The exemplary operating environment is shown as a computing device 2020 comprising a processor 2024, such as a central processing unit (CPU), addressable memory 2027, an external device interface 2026, e.g., an optional universal serial bus port and related processing, and/or an Ethernet port and related processing, and an optional user interface 2029, e.g., an array of status lights and one or more toggle switches, and/or a display, and/or a keyboard and/or a pointer-mouse system and/or a touch screen. Optionally, the addressable memory may, for example, be: flash memory, EPROM, and/or a disk drive or other hard drive. These elements may be in communication with one another via a data bus 2028 via an operating system 2025 such as one supporting a web browser 2023 and applications 2022, the processor 2024 may be configured to execute steps of identifying, for a given WC of a plurality of WCs in a production facility, in the queues of all upstream-adjacent WCs the WO that is next to be authorized for production based on a priority-setting rule ("Next WO"); calculating the time for the Next WO to arrive ("time-to-arrive") at the given WC and comparing the time-to-arrive to the time to process all the work ahead of the Next WO ("need-time"); and authorizing work on the Next WO if the time-to-arrive is greater than or equal to the need-time.

[00136] Embodiments have been described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments. Each block of such illustrations/diagrams, or combinations thereof, can be implemented by computer program instructions. The computer program instructions when provided to a processor produce a machine, such that the instructions, which execute via the processor, create means for implementing the functions/operations specified in the flowchart and/or block diagram. Each block in the flowchart/block diagrams may represent a hardware and/or software module or logic, implementing embodiments. In alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures, concurrently, etc.

[00137] Computer programs (i.e., computer control logic) are stored in main memory and/or secondary memory. Computer programs may also be received via a communications interface. Such computer programs, when executed, enable the computer system to perform the features of the embodiments as discussed herein. In particular, the computer programs, when executed, enable the processor and/or multi-core processor to perform the features of the computer system. Such computer programs represent controllers of the computer system.

[00138] The visual displays in the figures are generated by modules in local applications on computing devices and/or on the system/platform, and displayed on electronic displays of computing devices for user interaction and form graphical user interface for interaction with the system/platform disclosed herein.

[00139] The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

XIV. Comparison of Time-Based Demand-Pull versus POLCA

[00140] POLCA (Paired Overlapping Loops of Cards with Authorization) is a prior art system to produce solutions to the application addressed herein, that is, demand- based shop floor control in a high mix, or high variety, production environment.

POLCA has various pre-requisites to implementation: 1 . a High Level Material Requirements Planning system

(HL/MRP);

2. a cellular organization;

3. cells involved in the implementation have rough-cut capacity and lead-time planning ability; and

4. the HL/MRP system (or an associated scheduling system) can produce dispatch lists.

[00141] The demand-pull system of the present disclosure advantageously does not require 3 or 4 above, Once the pre-requisites for POLCA are met, the following activities, at a minimum are required to execute the system:

1. Each pair of adjacent WCs within the production environment must be defined so that POLCA cards can be created that are unique to each WC pair. And, of course, when new WC pairings are created by new products or variations on existing products, more POLCA cards must be defined.

2. The number of POLCA cards for each WC pair must be computed based on

production forecasts and WC capacity. When forecasts or capacity changes, the card numbers must be adjusted to compensate.

[00142] The present demand-pull system is rules-based: no color-coded cards, no pairing of WCs, no creating work quanta, no calculating the optimum numbers of cards, and no dispatch lists (unless an organization decides to supplement prioritization with MRP-based time). It is, therefore, simplified and optimum for a software embodiment. In addition, POLCA requires considerable ongoing

maintenance as explained below.

1 . Work cells must be paired based on any possible combination of production sequences, and if a new product with a different workflow is introduced, these new pairings must be added to the system, and cards generated.

2. POLCA requires that physical, multi-colored cards be created that circulate with the WOs through the production facility, and the demand-pull system of the present disclosure does not require them.

3. POLCA requires periodic examination of WC pairs, capacity, and throughput projections to regulate the numbers of POLCA cards that are allowed, so management must periodically add or remove cards based on conditions in the factory. The demand-pull system's algorithm is self-regulating and automatically adjusts the WC queue policy to compensate for changes in capacity and WIP.

4. POLCA uses MRP dispatch lists to determine which work is authorized and the sequencing of the work. This returns the system to a "quasi- push" system and dispatch lists can be labor intensive and subject to

inaccuracy. The demand-pull system herein assumes that if a WO has been created by MRP and accepted into production, that it is valid and should move through production as expeditiously as possible. Sequencing of work is a two- step process: 1 . First the WO must be authorized (Pull-tagged) based on its priority and downstream demand; 2. Once authorized, WOs are pulled into production on a First-Authorized, First-Out (FAFO) basis: the first WO in a WC's queue to be assigned a PT is the first one to be worked on. There are over-ride provisions in the system, but the present demand-pull system works automatically based on FAFO. The authors prefer that the priority-setting method for the authorization step be First-I n-F irst-out, but other methods have been discussed in Section II of this disclosure.

[00143] Although the present inventions have been described in terms of preferred and alternative embodiments above, numerous modifications and/or additions to the above-described embodiments would be readily apparent to one skilled in the art. The embodiments can be defined as methods of use carried out by anyone, any subset of or all of the components and/or users; as systems of one or more components in a certain structural and/or functional relationship; and/or as

subassemblies or sub-methods. The inventions can include each of the individual components separately. However, it is intended that the scope of the present inventions extend to all such modifications and/or additions and that the scopes of the present inventions are limited solely by the claims set forth herein. The

inventions include the methods being included or distributed in floppy disks, CD- ROMs, DVDs, over the Internet, as a programmed computer, a processor and a non- transitory computer-readable medium, and others as would be apparent to those skilled in the art in view of this disclosure.

[00144] Although the terms first, second, third and so forth may be used herein to describe various members, elements, components, regions, layers and/or sections, these members, elements, components, regions, layers and/or sections should not be limited by these terms. These terms may be used to distinguish one element, component, region, layer or section from another region, layer or section.

Terms such as "first," "second" and other numerical terms when used herein do not imply a sequence or order unless clearly indicated by the context. Thus, a first member, element, component, region, layer or section discussed below can be termed a second member, element, component, region, layer or section without departing from the aspects of the present teachings.