PerformAPS™ Features Table



	Version 10 Feature Table

Feature

P-Lite

P100 FCS

P200 FCS

P300 FCS

P400 APS

P500 APS

P600 APS

Limited to X operations, Y resources, Z products etc

Data tables in the Lite product are limited to:

Data Table	Number of Records
Orders	1000
Resource Groups	40
Resources	40
Calendar	5000
Default Calendar	250
Calendar States	100
Products	1000
Order Import	1000
Product Import	1000

Forward/Backward and bi-directional sequencing by order-attribute

Parallel operations in process route (assembly & dis-assembly)

Process run time by part, rate per hour and time per batch

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.

Single resource constraint for an operation

Automatic resource selection within workcenters

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

Manual and interactive breakdowns, planned maintenance etc.

Graphical and textural reports

Preactor Sequencer

User defineable three color bars

Schedule Statistics

Microsoft SQL 2005 Server Express database

License Site Manager

E-mail support

Unlimited Data for Number of Operations, resources, products etc

Unlike Preactor Lite, Preactor 100 FCS and higher versions has unlimited database size.

Data Table

Number of Records

Orders

1000

Resource Groups

40

Resources

40

Calendar

5000

Default Calendar

250

Calendar States

100

Products

1000

Order Import

1000

Product Import

1000

Operation & Product Attributes

Capable to Promise (CTP) Enquiries from within Preactor

Import/Export Wizard

Web Publisher

Telephone & E-mail support

User configurable SQL 2005 database, menus, and custom routines

Additional constraints usage by operation and plots

Plots Window for Secondary Resources

Resource dependant additional constraint usage by resource within a workcenter

Resource dependant process times by resource within a workcenter

Sequence dependant changeover time matrices

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.

Delivery Buffer and 'At Risk' Report

At Risk' Order highlighting and report

Operation Progress

Operation Hold

Order Status bar patterns

Automatic Schedule Repair

Schedule Analysis Window

User configurable real-time messaging system

ActiveX links to other software (OCX)

ActiveX linking for custom event processing

Multiple constraints for each operation

Hot Spots Grid Window

Subsequent operation constraints based on current operation

Preferred resource selection and time-out

Maximum operation span & delay interval to next operation

Sequential and parallel lots at each stage of process route

Mid-batch update and calculations

Operation progress bar color change based on mid-batch update calculation

Cost calculation by order and entire schedule

Additional Schedule Comparison Tables

Automatic allocation of materials during download from MRP

Material plots

Ability to schedule with or without material constraints

Shortages report and plot

Automatic linking of dependent orders (e.g. for assembly)

Material allocation rules linking consuming and producing orders

Sequential and parallel loading of operations from different orders

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.

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.

Sequencing rules that are order, product or resource specific

Rule building using Event Script Processor (including muti-pass rules)

Rule building functions using Visual Basic

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.

Non-Continuous Blind CTP and ATP functionality for ERP from outside Preactor

This it does from the Preactor BOM Exploder (PBX) which is an integral part of Preactor 500 APS. PBX is provided with product routings and BOM structures by the ERP system. PBX can blow through the BOM for a product and create orders for each level.

The communication between PBX and the Master Scheduling System (Preactor 400 APS) is handled by the Preactor Communication Object (PCO) using an Event Script developed with the Preactor Event Script Processor (PESP). After the PBX has generated the orders with routing it then passes these back to the Master Scheduling System.

The next stage of this automated process is to run Static Material Control (SMC). In this process the PBX orders are linked either with orders already scheduled (where there are unallocated materials available created by other scheduled orders) or to the orders created by the PBX as part of the enquiry process. Orders that are unlinked, and therefore not required by this order promise, are then automatically deleted. The remaining orders are then scheduled taking into account the availability of resource to provide a promise date. Running SMC in this way 'nets off' current unallocated materials so introducing some control over inventory levels.

Please note that PBX is not meant as a replacement for ERP. Typically, order promises that have been created by running the order enquiry process are replaced completely by orders entered into the ERP system.

Because accepted enquiries are replaced by orders from the ERP system a mechanism is required to allow them to be removed from the schedule file before they are replaced by the appropriated order from ERP. The link between the enquiry and the subsequent order is provided by the 'Order Promise Number'.

Not all accepted order promises will subsequently translate into firm orders and therefore consideration must be given to the length of time an 'Order Promise' is to remain valid and consequently how long it remains on the planning board. The potential customer should be provided with this information when they are given the Order Promise date.

Continuous Blind CTP and ATP functionality for ERP from outside Preactor

Remote Order Promising

Remote Multi-Plant Planning

In some applications it is necessary for more than one set of schedule data to be taken into account when answering the question "When Can you Ship? You may also want to make decisions on where to make a product based not only on capacity at one or more plants, but also take into account the location of the customer and other cost factors.

For example you may have three facilities at different locations. Each location has a Preactor 600 APS that holds the current live schedule for that facility and a local Master Scheduling System.

A central Master Planning system is used to decide the best location to satisfy an order by sending out electronic inquiries to each Preactor 600 APS using a LAN or WAN. The local Preactor 600 then test loads the inquiry onto the current schedule using local routing information and available resources and then sends back information to the Master Planning System. When the result of the enquiry is received from each facility then the Master Planning System can then be used to decide the best location based on a variety of criteria, and after selection, pass order information to the selected facility system.

Remote Multi-Plant Scheduling