Preactor

When Preactor schedules it will try loading onto each resource in the group before deciding the 'best' one. This is the resource that would finish first and by choosing this Preactor is in effect load levelling work across resources in the group.

In most cases you will want to define resources as having finite capacity however in some circumstances infinite resources are used to model certain processes. For example a sub-contract operation may always have a 2 day lead time no matter how many batches are sent and in this case an infinite resource called ‘Sub-Contract’ might be used to model the delay. A third alternative ‘Infinite with Shift Patterns’ is also available. This might be used for example if our sub-contractor did not work at weekends so that the 2 day lead time would be extended if sent on a Friday.

Preactor Calendars provide the user with an intuitive approach to the development resource shift patterns. It simplifies the definition of standard shifts and allows for the use of non seven day repeating shift patterns. Default shift patterns can easily be assigned to either resources or groups of resources. Resources may operate under different shift patterns. Complex working practices built up in this manner may be saved for future use. It is a simple matter to switch resources from one shift pattern to an alternative for a short period of time, e.g. overtime working.

There is a hierarchy in how resource calendars are made up. Each resource has a calendar. This calendar is defined in a calendar template. A calendar template is made up of a number of periods. Each period has a calendar state. The creation or editing of calendar states, calendar templates and assignment of templates to resources is done within the Preactor Sequencer.

When scheduling operations for an order you can choose to forward sequence or backward sequence. For forward sequencing the first operation in the order (by operation number) is loaded onto one of the resources in the workcenter specified (by default it would choose the resource that finishes first) as soon as possible after the earliest start date. The next operation is then added until all operations for that order have been sequenced.

In backward sequencing the last operation is sequenced first with the finish time at or before the due date for the order. The previous operations are then added backwards from the start of the previous operation.

In bi-directional sequencing one operation is locked. Previous operations to the locked operation are sequenced backwards from the locked operation's start time and subsequent operations sequenced forward from the locked operation's finish time.

A number of standard reports are available in all versions. These include:- Schedule Performance Work-to list for each resource and resource group, Orders and Orders by Customer, Route cards for each order, To do Operation list by day, Late operations and orders, and Shift patterns for each resource.

Manage sequencer datasets

You can edit one or multiple resource calendars within the sequencer window.  An example of a calendar edit is to add an exception representing a breakdown when the resource will not be available for an expected period of time. It could be minutes, days or weeks. When added the schedule is automatically updated showing the effect of the breakdown.  If the resource is an operator you might to use this feature to add a training day or other reason for absence.

Another exception would be add a planned maintenance period or variation in efficiency (speed of working) due to some unexpected event.

Preactor 11 uses Microsoft SQL 2005 or higher as the data store. Both Express and Server editions can be used. The SQL database allows use of a range of additional standard tools for reports and analysis.

Attributes can be defined and assigned to products and operations to help locate them in the Preactor Sequencer. In higher versions these attributes can be used to calculate sequence dependent changeover times and control the sequencing of operations and orders.

Operation locking/unlocking by order or operation attribute, resource and time

Operation progress

Order enquiries from within Preactor

Overview Gantt window with optional utilization display

Each operation has an operation number, say 10, 20, 30 and so on. If you define two operation 10s then Preactor will schedule them ‘in parallel’ and then wait until both have finished before sequencing operation 20. In effect parallel processing will occur for the two operations provided of course that the required resources are available to use.

The Preactor Sequencer is the heart of the scheduling system and contains Preactor's Calendar Editor, Planning Board, Editor, Plots (Preactor 100 FCS is limited to plots showing the queued workload at each resource over the period of the schedule that highlights bottlenecks) and Trace Chart windows. It establishes the shift calendar patterns for both primary and secondary resources, provides automatic and manual scheduling functions and carries out all finite capacity calculations.

You can define how you wish Preactor to calculate the run time for an operation by specifying the process rate as time per item, rate per hour or a fixed time for the batch.

In Preactor 200 FCS and higher versions the user has access to a number of reports that help you analyse a schedule or compare one saved schedule with another. These include:- Order Analysis data, Order Comparison Data, Order Makespan bar chart, and Order Net Change Summary.

The Schedule Statistics dialog is displayed, showing data for the currently loaded schedule:-

Order Count Data (Number and percentages)

Early

Late

Incomplete

Started Order Completion Data (Total, Minimum, Average & Maximum)

Early Time

Late Time

Setup Time

Lead Time

 Added Value Percentage

Resource Data (% Minimum, Maximum & Average)

Working Percentage

Setup Percentage

Unavailable Percentage

Idle Percentage

Utilization Percentage

Schedule Span

In Preactor 100 FCS and 200 FCS you can define one finite constraint per operation. In higher versions you can define multiple finite constraints per operation.

The number of records allowed in the data tables is configurable by the user.

User definable bar colors

Additional constraints usage by operation and plots

Preactor API to allow data manipulation, event trapping and custom actions and custom reports. The API will link with any .NET compliant programming language such as VB.NET or C#.

In Preactor 200 FCS and higher versions the user has the capability to place Custom Window(s) within the Preactor Sequencer.

At Risk orders and operations are highlighted in a number of ways.

There are two buttons in the sequencer to highlight only At Risk operations or orders. Also in the editor any operation record that is At Risk is colored yellow. A report is available to list At Risk operations.

In Preactor 200 FCS and higher versions the user has access to a schedule repair button. Schedule repair can be used to correct a schedule where small alterations to actual start and finish times for an operation has caused operations within an order to overlap (assuming transfer batching has not been defined as allowed). Schedule repair will keep operations on the same resource (where possible) but adjust the start and finish times for un-started operations to maintain the correct operation sequence within an order.

In Preactor 200 FCS and higher versions the user can define a delivery buffer time that can be product or customer specific (or a combination of them). Preactor uses the delivery buffer in two ways.

When backward sequencing Preactor will schedule the last operation, where possible, to finish at the Due Date less the delivery buffer. Any order with the last operation finishing after the start of the delivery buffer is then referred to as an At Risk order.

Dynamic three bar color change

The import / export wizard is used to create an import or an export script for importing or exporting data to and from an external data file in CSV format.

In Preactor 200 FCS and higher versions the user can define for an operation that a batch is split into smaller lots. For example a batch of 20 may be split into lots of 10. Each lot is scheduled independently. This is used for example to allow the batch to be processed across more than one resource in a resource group or workcenter. It is also used where a resource can only process a smaller lot at a time e.g. an oven can only take 10 parts at a time.

The user can allow transfer batching between operations. For example a batch of 100 could have a transfer quantity of 20. Then as soon as 20 parts have been completed the next operation can be scheduled for the subsequent operation.

The user can enter an order and then define a repeat interval. For example you could enter an order for 100 of product A then use the repeat order tool to create 5 sub-orders of 100 offset by 1 week. Preactor would then set the Earliest start date and due date of each sub-order taking into account the repeat interval.

The user can enter an order and then define a call off. In this sub-orders are created with defined quantities and time interval. For example you could enter an order for 100 of product A then use the call off order tool to create 5 sub orders of 20 each separated by a 1 week interval. Preactor would then set the Earliest start date and due date of each sub-order taking into account the call off quantity and time interval.

Any operation can be set to Hold using the toggle check box. When unallocated, this operation (and later operations in that order) will not be scheduled.

An order state can be used to change bar colors and patterns.

The Plots Window is used to display a variety of plots.

Depending on the version of Preactor you can configure the Plots Window to display:-

-  The Queued Workload waiting to be processed at each primary resource

-  The number of units of a secondary resource in use (P200 FCS and above)

In Preactor 200 FCS and higher versions the user can define a different additional constraint usage for each resource for an operation within a workcenter or resource group. For example two resources A and B may carry out the same task. Resource A may require an operator but resource B does not.

In Preactor 200 FCS and higher versions the user can define a different process time for each resource for an operation within a workcenter or resource group. For example two resources A & B may be able to carry out the task. Resource A may take 5 minutes per item in a batch and resource B takes 10 minutes.

Secondary resource management

Sequence in infinite capacity mode

In Preactor 200 FCS and higher versions the user can define sequence dependent setup or changeover times based on the attributes of one operation to another operation on a resource. For example the sequence of product A to product B on a resource could incur a 30 minute changeover time but product B to product A would incur a 3 hour changeover time.

Multiple matrices may be defined.  For example a color to color matrix, a material to material matrix and a tool to tool matrix.  Preactor can be configured for example to add the values from the three changeover times or use the longest as the value to use.

Sequencing dependant on several attribute settings, with weighting rule

Preactor has an real-time messaging system called PCO (Preactor Communication Object). In Preactor 200 FCS and higher versions the user can configure the messages that Preactor uses to pass information between it and other applications such as SFDC, ERP, etc..

This kind of interface is referred to as an event driven interface, and is used extensively thoughout Supply Chain Server solutions.

Preactor 11 uses SQL 2005 or higher as the data store. Both Express and Server editions can be used and data is automatically saved and retrieved from the database. Preactor’s flexible method of configuring the data tables automatically generates the appropriate SQL schema. The database is automatically created/updated by Preactor using the field names, tables and classifications that have been such a strength of Preactor in previous versions. Add a field or table to your configuration and Preactor can modify the SQL database appropriately without losing data. The SQL database allows use of a range of additional standard tools for reports and analysis.

In 100 FCS and higher versions the user can automatically create reports and Gantt charts in HTML format to display on a web page. These can be viewed using Microsoft Internet Explorer version 4 or greater.

Goes beyond the Schedule comparison reports in P200 FCS in that it contains information on utilization by day and week by resource, by resource group and by secondary constraint.

In Preactor 300 FCS and higher versions the user can define a number of data fields associated with costs. For example you can define the cost per hour for resources, whether these are multiplied depending on calendar state (e.g. on-shift and overtime variations), and material cost for each operation. The cost for each operation may be displayed in a tool tip in the sequence overview. As an operation is dragged and dropped to an alternative resource or is rescheduled or overtime added, so the operation cost is recalculated.

The hot spots grid is a table of information that includes primary resource capacity, utilization, setup time and Idle time for each resource by week.

In Preactor 300 FCS and higher versions you can define a maximum span for an operation. For example a process may take 4 hours but, due to breaks or other zero efficiency periods the span has been increased to 6 hours. This may not be allowed and by specifying a maximum span Preactor will automatically avoid this condition.

In Preactor 300 FCS and higher versions you can enter a mid-batch update for a batch at an operation. For example you may wish to enter the quantity complete and time for part of a batch. Preactor re-calculates the process time per item.

In Preactor 300 FCS and higher versions the user can define multiple finite constraints for an operation. In Preactor 200 FCS the user could define secondary resources and plot the usage however these were infinite capacity. For example you can define in P300 FCS that an operation requires a machine, an operator, and a tool and only when all three are available for the entire period of the process will Preactor load it onto the schedule. Another example of additional finite secondary resources is where multiple operations from different orders can be loaded onto a primary resource at the same time. Secondary resources are then used to limit the number that can be processed at the same time. Another example of using finite secondary resources constraints is to use them to model the capacity of a tank. The primary resource is the tank and the secondary resource will limit the quantity of material that be emptied into the tank.

In Preactor 300 FCS and higher versions Preactor provides a convenient and visual way of tracking the progress of an operation. As a mid-batch quantity and time is entered for an operation, part of the bar color will change equivalent to the progress made. The change color is definable by the user.

In Preactor 300 FCS and higher versions you can define preferred resources within a workcenter or resource group. For example you may have two machines that can carry out an operation. Machine A is a new machine, machine B is older. You would prefer to use machine A and will wait for this machine in preference to machine B for up to an hour even though machine B will not be utilized. In this situation you would list a time-out period for machine A as zero and machine B as 60 minutes.

In Preactor 200 FCS and higher versions you can define a batch to be split into smaller lots for an operation. All lots must though be completed before the next operation ca start. In Preactor 300 FCS the user has the option to allow lots to be processed on subsequent operations independent of the other lot status.

In Preactor 300 FCS and higher versions you can define a resource group for a subsequent operation depending on the resource selected for the current operation. For example you may have two manufacturing lines, Line A and Line B. The first resource in each line may be selected for operation 10. If the first resource in Line A is selected then you may wish to force subsequent operations onto resources in Line A. If the first resource in Line B is selected then you may wish to force subsequent operations onto resources in Line B.

When Standard Material Control (SMC) is employed, Preactor 400 APS and higher versions provide facilities that allow you to check whether orders have been raised, to authorize the procurement or production of all parts and materials, to satisfy the demands generated by a schedule of production. Outstanding material shortages can be viewed as a 'Shortages' report or in the Materials Explorer. The system determines a shortage to exist when the quantity defined in the last operation of a supplying order for a part, is less than the combined demand from the first operation of the consuming orders in which it is to be used. Thus if you were to modify 'Quantity' of a supplying order, that had more than one operation, the 'Quantity' field must be modified for all process steps.

 

CTP (Capable to Promise) for single level BoM orders

Typically orders are passed to Preactor from an ERP system where the process route information and BOM structure are included as part of the download. These orders can be manufacturing orders for each level of the BOM, sales orders (Demand) and purchase orders (Supply). Preactor can run its SMC (Standard Material Control) functionality as part of the download process or run separately after the download. When SMC runs it uses the BOM information to link 'producing orders' and 'consuming orders' together using SMC rules that decide which orders are linked where there is more than one option. So a purchase order for raw materials may be linked or pegged to one or more manufacturing orders that require the material to start. This manufacturing order may be linked to one or more manufacturing orders at a different level of the BOM. One final assembly manufacturing order may feed one or more sales orders. These links and dependencies are used when Preactor schedules so that material constraints and other resource constraints are taken into account and in addition it keeps a record of the links to provide traceability of materials.

In Preactor 400 APS the user has access to a function called SMC, Static Material Control. SMC is uses order information and BOM information together with an SMC rule to peg or allocate materials between different orders. This is typical when an ERP system generates work or shop orders because it will produce an order for each level of the BOM. For example if an assembly A was made from sub-assembly B and sub assembly C, it would generate an order for A and order for B and an order for C. Preactor uses this information to link these orders together so it can be used as part of the scheduling process.

Standard Material Control uses a concept of producing orders and consuming orders. By using SMC rules the user can define which orders are linked together assuming there is more than one option. SMC rules work as a series of passes where it examines the contents of producing orders and consuming orders and attempts to match them. Where acceptable matches are made then these are removed from the queue for the next pass. Quite complex links can be set up in this way. An example would be to match sales orders (Demand) with manufacturing orders. There could be multiple batches of the same product but with different quality levels. A rule could be set up to allocate product to customer orders based on the quality of the batches available.

In Preactor 400 APS and higher versions an interactive graphical tool for reviewing the results of the linking process between orders is provided by the Materials Explorer. This shows the links or pegs that have been made between orders (Sales, Works and Purchase) and provides a plot of stock levels of each material over the period of the schedule. This powerful and interactive tool works in synchronization with the Preactor Sequencer.

In Preactor 400 APS and above the user can also create their own parallel loading rules and ASCL rules using VB.NET and C#. Preactor has a library of rule building functions or macros that can be used for this task but you can also use native .NET as required if the functions do not do everything that is required. The Preactor API course is a useful introduction to building unique scheduling rules.

In Preactor 400 APS you can use the Preactor event script processor (PESP) to build multi-pass scheduling rules. In this a series of events may be for example....

1. Highlight all jobs with attribute Customer = ABC

2. Forward schedule.

3. Highlight all jobs with Order Status = Suggested

4. Backward Schedule

5. Schedule Remaining Jobs forward by due date

Schedule despite shortages

In Preactor 400 APS you can have schedule rules that are product or resource specific. The preferred sequence rule is resource specific. The ASCL rules can be made product specific. So for example you want product A to use the Min. WIP forward rule and product B to use the Min. WIP backward rule. Another example is in the biscuit making process where certain additives such as nuts must not contaminate other product lines. For each week you may want to forward sequence non nut products and backward sequence all nut products so that cleaning can be carried out at the weekend.

In Preactor 400 APS and higher versions the user has to an alternative scheduling engine to other Preactor versions. With the lower version scheduling engine all operations for an order are loaded onto the schedule before another order is considered. In Preactor 400 APS you can also elect to load one operation at a time and use dispatching or parallel loading rules to select which operation to load next. Dispatching or Parallel loading rules are resource specific. Operations that are ready to load are put in one or more queues which can be ranked according to the rule assigned to the resource. As a resource becomes free it looks at the queue of waiting operations and selects the best one to process next. The in-built preferred sequence rule uses this logic. It also has a Look-ahead window. This is the period that will be used to determine if an operation should be allowed into a queue for a specific resource. When a resource becomes free the rule determines what its look-ahead window is from the current time. If an operation from an order has a due date within that window then it is allowed into the rule queue.

Where shortages of materials occur in a schedule, by default Preactor will not schedule orders that are affected. The user has the option to allow orders to be scheduled despite shortages. The sequence in the BOM structure is still respected in terms of timing. The user can set the ‘ignore shortages’ from within the Materials Explorer and the plots will update as to when the shortage will occur in the current schedule.

In Preactor 400 APS and above there are additional rules that are a combination of operation at a time sequencing as in the preferred sequence rule engine but without using parallel loading dispatching rules. A preferred sequence or parallel loading rule can only run forward in time. This can be a problem in some situations where you want to load operations both forward and backwards in any sequence. Preactor has a special sequencing engine for this type of rule and with its in-built Algorithmic Sequencing Control Language, ASCL. This is part of the Open Planning Board capability. In effect any sequence of loading, unloading, creating and deleting operations during a scheduling run can be accomplished to fit the needs of an application.

There are standard in-built rules in Preactor 400 APS that use the ACSL. These are Forward, Backward, Min. WIP Forward, Min. WIP Backward, Selective Bottleneck and Dynamic Bottleneck. Forward and backward sequencing operate in a similar way as the forward and backward algorithmic rules in Preactor FCS. Min. WIP forward is a combination of forward and backward sequencing. First all operations for an order is forward sequenced. The last operation is then locked and all previous operation backward sequenced. This in effect minimizes the make-span period and thus reduces work in process. Min. WIP backward starts by backward sequencing from the due date. The first operation is locked and subsequent operations forward sequenced.

Dynamic bottleneck is a variation on the Min. WIP forward rule. Each order is forward sequenced. Preactor then finds the operation that waited longest to be processed. This is the bottleneck operation and defines the bottleneck resource for this order. Preactor then locks the last operation and backward sequences the other operations except that an additional buffer time is used on the bottleneck resource. Thus if there are any delays to operations up to the bottleneck operation, the buffer will prevent starvation of work on the bottleneck resource.

The Selective Bottleneck rule is based on the Theory of Constraints (TOC) philosophy. It works by the user selecting the Bottleneck Resource or Bottleneck Resource Group. Each order is then backward scheduled from the Due Date (less Delivery Buffer). Any operations loaded onto a bottleneck resource are offset by the Bottleneck Buffer time (defined in the Resource data table for each resource) which is designed to give some slack such that any delays to operations before the bottleneck resource will not result in it being starved of work. Preactor then detects whether any operations in that job must start before current time. If so then these operations are re-scheduled forwards using up some or all of the bottleneck buffer. If this is consumed then some or all of the delivery buffer may also be used up and the At Risk or Late flag is set.

The Campaign Rule uses a Reference Date, Campaign Period and Number of Campaigns to locate all orders where the reference time entered is greater or equal to the due date of the order, these orders are then forward scheduled. The Reference Date is then incremented by the Campaign Period, the Number of Campaigns decremented. The second pass of the rule will again locate all orders where the reference time entered is greater or equal to the due date of the order. The number of passes of the rule will be the same as the number entered into the Number of Campaigns field.

This APS rule is similar in some respects to the Preferred Sequence rule. However it is focussed purely on minimizing the setup or changeover time on resources. In the Preferred Sequence rule, as each resource becomes idle it selects the next operation to load based on the preferred sequence criteria in the resource database without any consideration of other resources that could also be used. Thus, provided one or more operations can be run on the resource and they lay within the Look Ahead Window one of them will be scheduled based on the preferred sequence. In the Minimize Overall Setup rule, consideration is made across all resources able to run the operation even if they are still busy. The rule does not use the preferred sequence criteria in the resource database. It does however use the Look Ahead Window o decide whether an operation should be available to be scheduled in the same way as the Preferred Sequence rule.

In Preactor 400 APS you can set up in the resource database the ranking of operations when running the preferred sequence rule. The in-built attributes are:-

Due date, Priority, Critical ratio, Dynamic critical ratio, Process time, Setup time, Other attributes.

You can select any of these to rank the queue for a resource (either highest value first or lowest value first). You can select more than one attribute too to deal with ties. So for example you might select Due date, lowest value first and add priority, lowest value first. In this case the queue is ranked by due date and those operations with the same due date are ranked by priority. Another example is to use Setup time, lowest value first. Then as a resource completes an operation it will select the operation in the queue that will result in the lowest setup time.

Two other attributes, critical ratio and dynamic critical ratio can also be important in minimizing lateness. The critical ratio attribute is calculated by Preactor for each operation in a queue as a resource becomes free. It is the ratio of time to due date compared to the sum of remaining operation times for the order. As this ratio falls to one it become more critical. Dynamic critical ratio goes one step further. Rather than just summing remaining operation process time, Preactor calculates the remaining lead time by test loading operations onto the planning board taking into account all constraints and shift patterns. This is a more accurate estimate of criticality but takes longer to run.

CTP (Capable to Promise) with Preactor BoM exploder for multi-level BoM orders

 

 

In Preactor 500 APS the user can apply Advanced Materials Control to a schedule. Advanced Material Control allows materials to be consumed and produced at any operation step within an order. This allows for example for the user to accurately model co-products, by-products and multi-line sales orders as well as material constraints at any operation step. These links can be viewed within the Materials Explorer.

 

 

The ability to make ad-hoc enquiries to establish when an order can be shipped has been the 'Holy Grail' for ERP companies for many years. So called 'Available To Promise', ATP, (usually defined as a calculation based on the availability of current stock, work in process or fixed lead times) does not necessarily meet the needs of many companies.

Capable to Promise, CTP, (generally defined as taking into account the current status of production and the finite capacity of resources) is often what is really required.

This is a more complex calculation based on data that most ERP systems do not have, so many offer instead, a simpler calculation based on finite capacity at a bucketed level e.g. daily or weekly buckets of capacity. This takes no account of the effect of sequencing on resources within a bucket which may effect changeover time, nor does it take account of additional constraints e.g. staff, tooling, space etc.

To do this properly the ERP system needs to have access to a multiple constraint, bucketless production scheduling system that can receive ad-hoc enquiries, access the process routing and BoM structure and schedule the operations onto the current live production schedule on a 'what if?' basis.

It is for this reason that the Preactor 500 APS was developed specifically for companies who have their Master Scheduling System connected to an ERP system and wish to carry out CTP, Capable to Promise enquiries from within Preactor.

Because all routing and BoM structures are held in the ERP system, Preactor does not have its own data table with this information in order to carry out a CTP enquiry. Either it need to request this information from the ERP system, which may not be very timely, or it needs to get its information from another source.