|
Current Location: United States
|
|
|
Region:
|
|
|
Country:
|
|
|
|
| |
Feature
|
P100
|
P200
|
P300
|
P400
|
P500
|
 |
Finite and infinite resources, calendar states, efficiencies and templates
|
|
|
|
|
|
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.
|
 |
Operation locking/unlocking by order or operation attribute, resource and time
|
|
|
|
|
|
Individual operations can be locked onto the planning board (they will not be removed from the schedule when a reschedule occurs) in a number of ways. Single operations may be locked one at a time or all operations for an order can be locked together. Similarly operations can unlocked one at a time or all operations in an order.
An alternate method of locking or unlocking multiple operations at a time is to use the locate feature. Here you can select an appropriate attribute then lock or unlock all those operations with the same attribute value.
An alternate method of locking and unlocking multiple operations at a time is to right click on a resource name in the sequencer and use the lock/unlock options to lock all operations that are currently assigned to that resource.
An alternate method of locking multiple operations at a time is to drag the terminator time to some time in the future. Operations that are within or lie across the terminator will not be removed from the schedule when reschedule takes place.
|
 |
Schedule Statistics
|
|
|
|
|
|
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
|
 |
Lot sizing, transfer batching, auto repeat orders and call-off
|
|
|
|
|
|
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.
|
 |
Plots Window for Secondary Resources
|
|
|
|
|
|
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 (Lite and P100 FCS)
- The number of units of a secondary resource in use (P200 FCS and above)
- The stock level for materials, parts, sub-assemblies and finished products (P400 APS and above)
|
 |
Rule building using Event Script Processor (including muti-pass 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
|
 |
Standard algorithmic rules, Minimize WIP, Dynamic Bottleneck, Selective Bottleneck (TOC), and Campaigning.
Minimize Overall Setup time
|
|
|
|
|
|
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.
|
 |
Standard dispatching rules e.g. preferred sequence, critical ratio
|
|
|
|
|
|
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.
|
 |
PBX memory resident BoM Exploder for real-time Visible Order Promising (Run from Preactor)
|
|
|
|
|
|
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.
|
|
|
|
|
|
|