Ps Implementation

Production Scheduling
Implementation Guide
An Oracle White Paper
May 2008
Production Scheduling Implementation Guide
OVERVIEW.
This document is intended as a starter kit for people implementing Production

Scheduling (PS). It takes concepts beyond those presented in the base training and
documentation guides and addresses modeling concepts frequently encountered
during implementations. This document assumes that the reader is competent in
the concepts behind the PS and be able to navigate the PS GUI.
It is important to note that this document does not replace PS training or the PS
user guides. This document is a compliment to, and is not a replacement for the
documentation.
IMPLEMENTATION DIVERSITY.
Implementations vary from industry to
industry and organisation to organisation.
This paper attempts to capture common
threads and experiences to enable
successful implementations across a
diverse range of implementations.
It is important to note that every implementation is different; in particular

organisational structure can drive the nature of an implementation. For instance all
of the following affect the implementation:
ERP consulting companys implementation process and experience

Roll out strategy
o Simultaneously with planning
o Planning before ERP
o ERP before planning
Integration strategy / methodology
ERP system and version
Nature of organisation
o Highly autonomous divisions
o Centralized organisation
o Companys ability to adapt to change / embrace new business
processes
o Senior management commitment
o Acceptable risk levels
Forward or backward scheduling (left or right justified schedules)
Work order or demand driven
Floating or static bottlenecks
Presence of tanks
Page 2
Make Store Pack or Synchronous make packer scheduling with 2 stage

dynamic rate matching requirements
Ovens/Kilns
ERP integration
Integration and feedback loops to tactical or other planning levels
Scheduling objectives minimize WIP, minimize changeovers, maximize
throughput
Because of this diversity it is not possible to provide a template for all

implementations. However it is hoped that this document will help be an aid to
those starting out on their first few PS implementations.
Also users should be cognitive of the version of PS being implemented/ERP
environment and adapt their implementation to accommodate those variations
Throughout the document there is the notation (red flag). These highlights an
area where there is risk or extra thought is required. Implementers should take
special note of these areas and ensure that the appropriate action is taken.
This document is organized in the following major categories:
Typical project plan describes the various processes and participants in a

typical Product Scheduling project.
Schedule success criteria Helps implementers frame the objectives of a

Production Scheduling implementation in order to focus on ensuring that
the implementation targets the customers success criteria.
User acceptance test criteria Successful testing is key to avoiding a golive tragedy. This section describes some common user acceptance tests.
PS fundamentals: Inventory Key aspects of setting up inventory items in

PS
PS Fundamentals: Machines/ Crews and Tools Key aspects of setting up

resources in PS
PS Fundamentals: Routings and Operations How to configure routings

and operations to achieve the customers goals
PS Fundamentals: Supply and Demand How to model supply and

demand in the model.
PS Fundamentals: Other items Covers the must know aspects in other

parts of the Production Scheduling portfolio.
Debugging Tips How to resolve problems in a model under

development.
Page 3
A TYPICAL PRODUCTION SCHEDULING PROJECT PLAN.

The following is an example of typical items in a project plan for Production Scheduling. Individual projects or company implementation methodologies
may need to massage these to fit individual requirements.
This does NOT include administrative tasks such as project management, project start-up, project closure etc.
This is based on legacy type integration, EBS and E1/SCBM type implementations would follow the same steps but the tasks may be simplified.
Some Key Players may be marked (), this implies that these roles have a lesser level of involvement in this task than the other roles.
Stage/Task
User Requirement
Gathering
Key Players
Project Sponsor
Scheduling Leads
Senior Consultant
Senior ERP Consultant
Notes
Identify the nature/number of the PS model(s)
What is the objective of each PS model
The Horizon for each model
An understanding of the organisations scheduling environments
Purchasing and Lead Times
Manufacturing Stages
Inventory Policies and Storage constraints
Purchasing lead time constraints, critical raw materials
Demand points
An understanding of key issues in the supply chain
Scheduling Objectives
Bottle Necks (red flag)
Demand Prioritization
Work Centre/ Crew strategy
What resources are modeled as individual resources or as a collection of resources
Batchable Resources Attributes for batchable resources
Overtime policies manufacturing calendars
Outsourcing (red flag)
Manufacturing batches/run length considerations (red flag)
Government/Ecological/Legal constraints
(water consumption restrictions/ restrictions on operating hours for certain operations)
Interfaces into other systems
Purchasing Suppliers/Lead Times/Prices/Contracts/
Current purchase orders/Stock in-transit
Manufacturing Representation Machines/Crews/BOMs/Routings
Inventory Master and Transaction information Inventory Levels/Product in QA/warehouse transfers/
Safety Stock Levels/Warehouse Capacities (red flag)
Demand sources and types
Resources: Pre Implementation Questionnaire (described in a later section)
Page 2
Initial Product Training
PS Consultant
Functional Lead
In order to maximise the chances of a successful implementation, customer functional leads and their backup (red
flag) must be thoroughly familiar with the PS application, the models and how to analyse/problem solve the
models.
The training is just the first step in this process.
This training is reinforced in the remaining project stages by being intimately involved in:
Developing the prototype,
Working with input/output data and the associated integration
Leading the unit and system testing process.
KPI Collection/Customer
Profile
PS Consultants
Resources: Oracle University Production Scheduling Training Course

In order to determine the success/failure of the implementation it is important to be able to collect KPI statistics
both before and after the implementation.
Failure to collect statistics prior to the implementation will only lead to a speculation as to the success or failure of
the implementation rather than placing it on a definitive statistical basis.
Some common KPIs are listed in the chapter Schedule Success Criteria.
The beginning of the project is also the appropriate time to gather customer profile information for later use in
reference material/project summary.
Collect Prototype Data
PS Consultants
Functional Lead
ERP Consultants
Resources:
Schedule Success Criteria (section later in this document)
Customer Profile Template
It is important to prototype the solution in order to:
1. Validate that the applications behaviour is as expected by the consultant and
2. A validation by the customer of the results expected from the model
3. Continuing in-depth training regime of the software for the functional leads
In order to make the prototype as successful as possible, as realistic data as possible should be used in the building
of the data. This
1. Confirms the source of data identified in the Requirements gathering stage
2. Identify complications expected in the transformation of the raw data to the form required by PS
3. Assessment of data quality/consistency (red flag)
4. Identify technical/timing issues with data availability (e.g. FTP etc.)
5. Identify what data will need to be manually maintained
Page 3
Prototype
Development/Validation
PS Consultant
Functional Lead
The purpose of the prototype is:

Validate the model design
Validate the consultants understanding of the organisations supply chain
Validate the results expected from the PS model
Ensure that the required data is available
Deepen the functional leads knowledge of the PS models and their use/behaviour
Develop Detailed Model

Design
PS Consultant
Functional Leads
ERP Consultants ()
A key part of the project where user requirements meets product functionality. This requires sign off from the
customer before moving into integration development.
PS Consultant
Functional Lead
User Acceptance Tests need to be developed for both functional tests (internal to model/PS) and system tests
(integration with external components). These should be defined before the model prototype is actually built and
executed on the prototype as well, so you should probably move this section
Develop User Acceptance

Tests
As part of the detail design process consider:

Calendars to be used
Machines/Work Centers to be modeled and their setup do all machines need to be modeled?
Crews to be modeled and their setup Is crew a constraint in what areas?
Tools to be modeled and their setup Are tools a constraining resource?
Items to be modeled and their setup What raw materials need to be modeled? Do WIP items required?
Finished Goods to be modeled?
WIP to be modeled Which Raw Materials will be modeled (and which will not be modeled)
How Operations will be setup
How Routings will be setup
Representation of Demand and Supply events
Representation of Work Orders
How Changeovers will be defined
The model tree and folder structures for machines/crew/tools/items/demands/supplies/work orders
Machines/crew/tools/items/operation groups
Scheduling Rules (Scenario properties/Solver Options)
Model building options (ERP dependent)
External data to be incorporated
Solver Sequencing
Expecting Manual scheduling processes
Publishing processes
These should be incorporated into the model design, so that the customer commits to the testing regime at the
same time they are committing to the model design.
Page 4
Integration Development
PS Consultant
ERP Consultant
Functional Leads ()
This is highly dependent upon the nature of the implementation.

If integrating to EBS or E1 then a predefined implementation is available and the project may require minimal
integration effort.
However if a more custom model is required or integrating with E1 without SCBM or integrating to another ERP
solution, then the integration effort may be quite extensive.
Unit and System Testing
Schedule Tuning
PS Consultant
ERP Consultant ()
Functional Lead
Critical to a successful implementation is a comprehensive documented testing regime, which is signed off by the
user and key management staff.
PS Consultant
Functional Lead
A key part of the implementation is the tuning of the model once it has been created. Tuning options can include
but are not limited to:
Setting the Solver Sequence
Configuring Solver options (JIT vs. WIP)/ Cycle Times etc.
Setting of costs against machines/crews/tools and items
Scaling of Costs for CRO machines and items
Solver options on machines/crews and tools
A list of common user acceptance tests can be found in the chapter User Acceptance tests for PS projects.
This is an iterative process that requires close collaboration between the consultant/functional lead/schedulers.
Documentation
PS Consultant
Functional Lead
Critical to ensure ongoing success of the solution once the consultants depart and when key customer personnel
leave/take on new roles.
User Training
PS Consultants
Functional Leads
If functional leads and their back-ups are heavily committed in the prototyping/ development and testing stages
then this should not be required.
Go Live Sign off and Go

Live
All
Sign Off is a key part to going live.

Sign off indicates customer management acceptance of the solutions current state (possibly including itemized
outstanding issues) and that the customer can successfully operate their business with the solution in its current
state.
Go Live Support
All
The time required for this is directly related to the quality and time spent in the previous steps in the project.
Solution Refinement
PS Consultant
Functional Lead
PS Consultant
Functional Lead
After the solution has stabilized, users will have identified some areas for improvement. Now that users have a
better understanding of the system, the need for and the benefit of enhancements can now be evaluated.
This would occur several months after the go-live when the results of the planning solution have made an impact
on the organisation.
This is an evaluation of the success or failure of the project against the KPIs identified at the beginning of the
project.
At this time, a project summary should be prepared and any reference material prepared and agreed to with the
customer.
KPI Evaluation
Page 5
Page 6
PRE-IMPLEMENTATION QUESTIONNAIRE
The pre-implementation questionnaire
facilitates building project estimates and
starting the implementation. It is a useful
document for handling the Sales and
A pre-implementation questionnaire has been developed to:
Consulting transition.
Provide input into the implementation estimation process

Determine the suitability of PS for a prospect
Quickly highlight areas of complexity that need to be scoped and
articulated clearly at the beginning of the implementation
Allow implementers to rapidly startup at the beginning of an
implementation.
The pre-implementation questionnaire can be customized for individual

customers/prospects.
The pre-implementation questionnaire should be retained as a document in the
project archives as this document sets out the basis for
Suitability of PS to solve the customers requirements

The basis of the project implementation estimate/quote
The pre implementation questionnaire can be found at the same location as this
document.
Page 2
SCHEDULE OBJECTIVES AND SUCCESS CRITERIA
For a successful implementation it is best

to have a clear understanding of your
objectives and the criteria for a successful
implementation.
Before you focus on creating a model, you should have a clear vision of what the
objective is of the schedule is. It is possible to have many objectives, but initially
you should just focus on just one or two, and drive the model to deliver these
objectives, at a later time the model can be extended to account for secondary
objectives.
It is important at a very early stage of the implementation to identify what would
define the implementation as been a success. The success criteria should align with
the implementation objectives.
Success Criteria are covered in the pre-implementation questionnaire and in
particular the metrics sections. However success criteria deserve additional mention
in this document.
Questions that need to be asked are:
How do you schedule now
Are you looking to retain the base scheduling strategy or is this an opportunity
to implement a different approach to scheduling
o Current scheduling strategies may be unsustainable given company
growth/departmental restructuring
o New approaches raise additional risk,
Where does your current scheduling process have problems now?
What is the definition of a successful schedule?
o Minimize changeovers
What is the typical product cycle time?
What percentage of available time do changeovers take now
What is the target percentage of available time for
changeovers in the new paradigm
o Maximize throughput
How is throughput measured?
What if the new scheduling process results in excess capacity,
is that capacity to be used on what products?
What is your current throughput
What is the target throughput
o Maximize Resource Utilization
On all or specific resources?
How is utilization measured?
What is current utilization
What is the target utilization?
o Minimize WIP or Finished Goods Inventory levels
What product groups are we trying to minimize
What are the current inventory levels
What is the target
Is this achieved through JIT or some other scheduling
process
Would you tradeoff carrying additional inventory over
minimizing changeovers?
Page 3
Maximize demand satisfaction

How is this measured?
By Order Lines
By complete Order
Is a demand met one hour late considered late? 4
hours? 2 days?
What are the current demand fulfillment levels?
What are the target demand fulfillment levels?
What is the desired scheduling frequency / business process?
o
Choosing an objective will drive:

How the operations and routings are modeled
What costs are loaded into the model (for the Campaign Run
Optimization algorithm only)
How resources are configured
What solver technology is used
What solver tuning parameters are set
Page 4
USER ACCEPTANCE TESTS

The following are typical areas to consider for inclusion in user acceptance tests:
Calendars
Are all the required departmental calendars present
Do calendars include one off holidays like public holidays
Items
Is all the expected inventory present
Consider Raw Materials/WIP/Finished Goods
Are purchased materials in receiving considered available
Are items recently manufactured in QA considered available
Are the Manufactured/Purchased/Saleable flags correctly set
Minimum/Maximum values/flags correctly set
Starting inventory correct
For purchased information, is supplier information correct
Do all purchased items have supplier information
Have product with attributes, been associated with the correct attributes
Machines/Crews/Tools
Is capacity (Single/Multiple/Batchable) correctly set
For multiple and batch resources, is Maximum set correctly.
Is the Calendar correctly set correctly
Solver options set correctly
Time Fence set correctly
Resource Attributes defined
Resource Costs defined correctly
Operations
Are operations correctly defined?
Are primary outputs defined
Do all operations have lot multiples set
Are lot multiples logical
Are lot multiples set such that a typical schedule has less than 50,000
instances
Do all operations have a duration resource
Are resource or item sets defined correctly
Are resource preferences coming through correctly
Are All of Sets/Resource Sets correctly defined
Routings
Are primary operations defined
Are temporal relations correctly defined
Are S@E and S@S relationships avoided
Check that temporal constraints are logical
Demands
Are past active demands present
Are demands that would expect to be scheduled within the horizon of the
model present
Page 2
Does the Request date represent the time it needs to be off the factory
floor in order to meet the customers requested date (does it take into
account post production time delays etc.).
Are the earliest and latest dates specified appropriately (typically these
should be null)
Work Orders
Are demands present when they are associated with a works order
Are the capacity required/ times/consumption rates correct
Are the materials listed, including where alternates exist
Are resources, including alternates, present
Changeovers
Are all the changeovers represented correctly
If CRO is optimising on cost, are costs correct relative to each other.
Log File
Is the model loaded with no errors/warnings
Solution Quality
Is the schedule look as if it is achieving the goal (minimize change over
etc.)
Does the overall order fill rate meet expectations
Does the resource utilization fill rate meet expectations
Publish
Does publish update the ERP system without errors
General
Take a typical product, analyze in depth the
o Routings
o Operations
o Demand
o Work Orders
o Purchase Orders
o Test the sample product
Deactivate all demands
Deactivate all work orders
Set starting inventory for the Finished Good to zero
Set starting inventory for WIP products to zero
Create a single demand line of a typical run quantity
Solve
Validate the resulting schedule
Page 3
PRODUCT SCHEDULING FUNDAMENTALS.
The following sections briefly address some basic production scheduling

principles that users should be aware of.
PS FUNDAMENTALS: INVENTORY.
INVENTORY FUNDAMENTALS
Avoid enforcing maximum inventory
levels
Avoid shared storage areas
Only model critical/constraining Raw
Materials
Avoid dynamic safety stocks
Ensure purchase items have supplier
details
Maximum Inventory Levels and Storage Areas.
As a general rule maximum inventory levels may be set, but the constraint should
be marked as relaxed. Typically the solver will not produce excess inventory if
pull forward windows etc., are set correctly. However enforcing a maximum
inventory level may lead to significantly increased solve times, typically with
negligible return.
Similarly, the use of shared storage spaces increases solve times and should be
avoided unless necessary.
Non Critical Raw Materials.
As a general rule, if the presence of a raw material can be taken for granted such
that it is not a concern for the scheduler then that raw material should not be
included in the model
Including unconstrained raw materials increases the size of the model, increases
solve times and makes navigation more difficult, and so unconstrained raw
materials should be avoided when they are not critical.
Supplier Items and Order Multiples.
Production Scheduling needs to represent supplier information for purchased

materials in order to replenish critical raw materials in the model.
However care needs to be taken in the setting of the order multiple for the
internally generated supply event.
Take the example of a supplier lead-time of two weeks. If the system will need
purchased inventory that is not covered by an existing purchase order then it will
create an internal supply event. This supply event will be the order multiple. If the
order multiple is 1 and the system needs 500, then 500 instances of the purchasing
operation will be created internally and all 500 of these would then need to be
scheduled. Note, the user would not observe the 500 instances directly, however
this will impact solve time as, under the covers, they are a scheduled operation
The setting of high order multiples is often countered with the fact that purchase
multiples may be in the order of 50 or 100 and there is a tendency to populate the
order multiple against the item with this number to get closer to life purchasing
Page 4
behaviour. However if must be remembered that from a scheduling perspective

there are only three things of importance when it comes to raw materials:
1.
2.
3.
How much of the raw material do I have now

What is my lead time to order more raw material
What supplies, if any, do I have incoming between now and the lead time
Given these, we can assume any supply required beyond the lead-time can be
infinite, as if we need more we can just order more. Therefore in order to avoid
impacting solve times, the order multiple should be set at a very large number to
keep the number of operations down
It needs to be remembered that although Production Scheduling contains
purchasing type information, this is needed in order to support scheduling
decisions and is not intended to be used as an MRP substitute.
Page 5
PS FUNDAMENTALS: MACHINES/ CREWS AND TOOLS.

MACHINE/CREW AND TOOL
FUNDAMENTALS
CRO focuses on maximizing selected
Campaign Run Optimisation.
PS has an additional solver option - Campaign Run Optimization which

addresses the following business requirements:
resources
CRO has some limitations
Multi Capacity versus multiple

instances
Solve Sequences allow users to
Scheduling of production campaigns on designated resources in and

across manufacturing cycles
Respect minimum run length constraints on these designated resources

within manufacturing cycles
Optimization of sequence dependant changeovers on these resources.
specify scheduling priority
When creating production campaigns, the solver dynamically calculates the tradeoff between:
Carrying inventory
Incurring expensive setups
Missing demand
Violating safety stock levels
It is important to remember the most important restrictions associated with the

CRO solver:
Only bottleneck resources should be marked for solving using the CRO
option.
It is critical that only ONE resource across a given items material flow is
marked as being a CRO resource.
o
This restriction holds true even when there is multiple routings to

manufacture a product. From raw material, through the various
WIP products to finished good assembly only one
resource/resource set can be designated as a resource AND that
resource can only be referenced ONCE in the routings that when
combined make that product.
CRO uses a bucketed system for the initial model. The user defines the
bucket size and CRO will optimize manufacturing and inventory holding
within the buckets.
The CRO solver is bucketed, so as long as product is satisfied within the

bucket then the solver will consider itself successful. So if the bucket is a
Page 6
week long and there is a demand on Tuesday, the solver will consider itself
to having to produce the product by Friday.
A post solver process will attempt to fix any late deliveries due to the
bucketed approach but this is not guaranteed.
CRO uses costs to determine the optimality of a solution. Costs can

therefore be used to drive change over policies and resource preferences
(CRO ignores resource preference in resource sets)
CRO enables minimum run lengths
When using CRO, a single activity MUST not exceed the size of the CRO
bucket.
In the Scenario Horizon properties there is the ability to specify the First Cycle
Start Time. This is an important field for CRO, it defines the starting time when
calculating the buckets.
The power point Oracle Production Scheduling Campaign Run Optimization
Overview.ppt gives a good overview of the CRO process, the setup and
limitations.
Multi Capacity versus unique resources.
Where a resource has multi-capacity then the user needs to determine how to
model the resource. Multi-capacity simply means the number of simultaneous
operations that can be run on a resource at a given point in time.
If a resource is modeled as a multi capacity resource then the resource will be
scheduled as a collective. The user will specify the number of resources available
and the scheduler will schedule within that capacity. The schedule views will
indicate the level of usage (e.g. 50% of the resources are in use) however the
schedule will not be able to specify which particular resource a job is running on.
If the users wants to be able to see which resource a job is on, or wants the publish
process to update a specific machine against the job then the machines need to be
modeled as individual resources.
Multi Capacity Resources cannot be used when defining changeovers.
Page 7
Solve Sequences.
In some cases, the customer has specific requirements as to how the schedule
should be generated and this may involve solving the problem in a particular
sequences.
From a resource perspective, Production Scheduling generically considers all crew,
machine, tool capacity and calendar constraints simultaneously when sequencing
operations. Focusing and resolving the most critical constraints in the scheduling
horizon has generally been regarded as the most effective scheduling strategy to
resolve multi-stage floating bottleneck problems when sequencing operations.
Addressing the more critical problems first results into the sequencing problems
being broken down into smaller sub-problems, which are generally speaking
easier to resolve.
However, it sometimes is desirable for users to be able to dictate to the PS solver
which resources to focus on first when creating a schedule as opposed to having
the solver simultaneously consider all constraints and potentially jump between
resources when contention levels dictate. Supporting resources may be considered
secondary by the user in terms of the priority of having their constraints considered
during the solve process.
Users sometimes accomplished this via the user manually performing multiple
solves in conjunction with the ability to relax / activate resource constraints.
Typically, users would first perform a cold solve with all resource constraints
relaxed except for dedicated bottleneck resources. Once the first-pass solve was
complete, the user manually activated constraints for supporting upstream /
downstream resources incrementally and performed a repair solve for incremental
constraint activation, essentially a solve stage. This sometimes resulted in
improved solution quality when compared to generic solver functionality.
Solve Sequences allows the user to specify solve stages and then assign resources to
those stages.
Page 8
Unfortunately, there isnt necessarily a black and white answer as to when the best
time to use this functionality. As a general rule of thumb, if you are not satisfied
with overall first pass schedule quality using PS generic solver logic, it may be a
good idea to set this up for various solver trials. Generally speaking, the order in
which to the constraints should be solved is the following sequence below. Of
course, the optimal sequence will result from testing various solve stage
permutations and order of resources solved.
Solve the dominating bottlenecks(s) in the first solve stage.
Work your way downstream by resource. Keep alternate resources in the

same solve stages.
Once you reach the end, work your way back upstream from the
bottleneck resource.
Does not apply when using CRO.
Page 9
PS FUNDAMENTALS: ROUTINGS AND OPERATIONS.

The majority of problems encountered with
Understanding the Operation Diagram
operations are in the areas of:
This section illustrates and explains the operation diagram.
Understanding the operation diagram
Setting the lot multiples correctly
This paper details both of these subjects
Take the following recipe to package peanuts:

Material Input
Resource Input
Supporting Resource
Output
Peanuts Salted
Packing Line 1
WIP Operator
Sales Peanuts 6oz
1906 units
1 hour
100 Bags
If the natural production multiple for this item is batches of 100 bags then the lot
multiple will be 1. In which case the Operation diagram would look like:
Page 10
The duration resource link looks like:
If there were 500 units of demand for this product, then the schedule would have 5
(500/100) instances of this operation.
With the resource consumption been as follows:
Page 11
Now, if the Lot multiple changes to 2, (but we leave the time as the same [ 1
hourso effectively the line is now running at double the previous speed]) the
picture changes significantly.
Each instance will now produce 200 units not 100 units. The materials consumed
will now be doubled as well (3812 rather than 1906). However unless the duration
has been changed to reflect the time to take the 200 units, the one hour relates to
the time taken to make 2 lot multiples, that is the it now takes one hour to make
200 units not two hours.
The time taken on the duration resource is the time taken

to make the specified number of lot multiples, the raw
materials and outputs are for one lot multiple and so will
need to be multiplied by the lot multiple.
Page 12
As the operation now needs to produce 2 lot multiples worth of product, the
operation instances will produce 200 each, so for the demand of 500, we will now
manufacture 600 and there will be 100 units of surplus inventory.
Page 13
Page 14
The inventory increases 3

times, equating to the
inventory released at the
end of the three job
instances
Note: The 100 units of

excess inventory.
Page 15
Defining Primary Operations and Primary Outputs.
In order for the pegging to work correctly, it is essential that each routing
be associated with a primary output and a primary operation. Pegging
enables you to view all of the item resources and operations associated with
each line item in a demand order, and how they have been allocated.
The blue box in an

operation indicates that
this is the primary
output for the routing.
The blue box in a routing

indicates that this is the
primary operation for the
routing.
Page 16
Routings versus Inventory Relationships.
When there is a multi step manufacturing process. There are two options on how
to set them up: with an intermediate inventory or with operations directly linked.
With Intermediate Products:

Mix
Mix WIP
Make WIP
Make
Pack
With NO Intermediate Products:

Mix
Pack
Make
There are advantages to both methods:

Inventory Relationship:
Use this method when there is a significant lag between two operations
and the WIP inventory is counted and stored in inventory (ERP inventory
pay point)
When there is a minimum/maximum storage requirement that must be

met
There should be one routing for each set of set of operations that produce
an inventory item
Temporal Relationship with no intermediate products:
Use this method when there is no inventory storage
Temporal constraints can be used (minimum and maximum separation

times can be specified between operations)
Solves more efficiently
Avoids the potential pitfall of unbalanced inventories
You can use a mix of systems. For instance:
Taking the above three stage manufacturing system but altered so the
Mix WIP product is consumed immediately by the Make process but the
Page 17
Make WIP can be stored in inventory. In this case two routings would
be used, the Mix/Make routing would only produce the Make WIP
product with no intermediate product between the Mix and the Make
operations.
Mix
Make
Take another situation where the output of the Make process is still
stored in inventory and the Mix product is consumed immediately but
there is a requirement for a two-hour cool down before the product can be
packed. In this case, two routings would be used again, there would be no
intermediate product between Mix and Make but an extra operation
would need to be added after the Make operation. The new operation
would produce the Make-WIP product. The link between Make and
the new operation would specify the cooling period.
Note: There is one problem with this, the inventory will not appear until
after the cooling off period. If it was an absolute requirement to also see
the inventory in the cool down state, then the following is a possible work
around.
Cooling Time
2 hours min separation
Make-Cool WIP
Make-Cool
Make Inventory Item
0 duration
Unconstrained Resource
The sum of the inventory levels Make Inventory Item and Make-Cool
WIP would equate to the actually inventory level for Make Inventory
Item
Unbalanced intermediate Inventory levels.
It is not normally recommended to have a product produced inside a routing and

consumed in the routing as it is usually transient as PS instantiates the entire
routing. The above example is due to a specific requirement and would not be
considered typical.
When there is a production/consumption relationship between two operations
within a routing then it is essential that the amount produced/consumed within the
routing be the same.
For instance, it is fine for an operation to produce 10 units of an intermediate and
for a later operation in the routing to consume 10 units of the intermediate. Then
for every instance of the routing, there will be no change in the inventory level for
the intermediate product.
Page 18
However take the example of where Operation A produces 15 units, but Operation
B consumes only 10 units, in this case every instance of the routing will generate an
excess of 5 intermediate inventories. And the intermediate inventory levels will
continue to grow infinitely:
However, another example would be where Operation A produces 10 units, but

Operation B consumes 15 units, in this case, the model would be infeasible
(assuming no starting inventory) as in this case as soon as an instance of a routing is
created it will be consuming more intermediate than it is producing.
Page 19
Ensuring consistent lot multiples within a routing.
Within any operation in any given routing, you have the ability to setup an
operation lot multiple. When you set these up within the context of a given
routing, they should be set to the same value, as the lot multiple for all intents and
purposes is a routing attribute.
Assume the following manufacturing example:
When you setup a lot multiple on an operation (as set to 25 on Operation C), it
means the operation will yield 25 units of finished good when the operation
completes after 4 hours. Basically, if produced or consumed items are present
within this operation, they will be scaled by a factor of 25. (i.e. You set the material
consumption quantity according to 1 unit of output of finished good and the lot
multiple will automatically scale the material inputs). However, since all operations
on the routing will run every time this routing is instantiated, you should set all lot
multiples to 25 (if they produce or consume inventory) otherwise the material
quantities (such as Material X in Operation A) will not be scaled properly.
In this particular example, 18.75 units of Material X are required in the first
operation of the routing that makes Item A. The lot multiple is still set to 25 on
the operation, but will scale the quantity of Material X on defined on the arc by 25
(in this case, 18.75 units are required).
Page 20
Getting the correct lot size and the impact on solve times.
This section discusses how operations can be set up and the use of lot multiples.
Large lot sizes have a significant impact on decreasing solve times, while at the
same time large lot sizes also affects surplus inventory production/excess
manufacturing times.
Solve Times
Excess Production
Exaggerated Resource
Usage
Lot
Multiples
Traditionally the lack of planning in this area has resulted in poor solve
times.
Many people set the lot multiple to an operation as one unit of output as this gives
the ultimate flexibility, to make exactly what has been demanded. However this
precision needs to be balanced against the impact on the solver.
To understand the impact of the solver it is important to understand how the
solver works. Take the following scenario:
500 units of demand for a product.
The manufacture time per unit is 2 minutes
The operation has an output quantity and lot multiple of one.
In this case, the solver will internally create 500 instances of the operation to satisfy
this demand. All these instances need to be sequenced etc. by the solver
Now extend this to other products, if they had similar run times, then for a four
week schedule, the solver would be looking at sequencing up to 5000 operations
for a single resource, extend this to multiple resources when there are multiple
production lines and multiple manufacturing stages and the number of instances
increases significantly.
The number of operation instances to be scheduled directly affects the solve
times.
Page 21
As a ROUGH guide when initially looking at what an appropriate lot size would be
for an implementation, the number of operation instances should be below 50,000.
To work out what this means in terms of a particular implementation you need to
consider the:
The quantity of Finished Good produced Average Finished Good Lot

Multiple
The quantity of WIP produced Average WIP Lot Multiple (consider

that there may be multiple WIP levels all of which contribute to the total)
The quantity of raw materials purchased order multiple
Then try to set the lot multiples such that for the number of operation instances is
below the target of 50000 (approx).
The following gives an idea on the impact of the number of operations on solve
times:
Customer Model 1 - This model has ~500 operations. It solves in 5 seconds.
Customer Model 2 - This model has ~1600 operations. It solves in 2 minutes.
Customer Model 3 - This model has ~30,000 operations. It solves in 20 minutes
Customer Model 4 - This model has ~21,000 operations. It solves in 45 minutes.
Customer Model 5 - This model has ~2000 operations. It solves in 10 minutes.
Customer Model 6 - This model has ~220 operations. It solves in 2 seconds.
Customer Model 7 - This model has ~300 operations. It solves in 1 second.
From a hardware sizing perspective, as a general rule, PS does not consume a lot
memory so most computers can handle reasonably large models, however solve
times are directly related to CPU speed. So the fastest reasonable CPU should be
use for PS computers.
If the solver spends a long time at the phase Assigning resources to
operations then this may be an indicator that the demand levels and the lot
multiples are not in balance.
It is also important to note that in a work order, that the inventory for a work order
is typically released at the end of the work order, not when a lot is reached within
the work order. However if work order units of effort is turned on, then inventory
from a work order is released when the lot multiple is reached, with the last
inventory release being the outstanding quantity which may be less than a lot
multiple.
Page 22
The Lot multiples impact on the make span.
Lot multiples also affect the relative timing of operations in a routing, and in
particular it determines when there is sufficient inventory to start the next
operation.
The example below depicts a 100 unit demand, with a lot multiple of 100 units on
the manufacturing operations. However, in reality inventory is yielded to
downstream operations in 25 unit increments, which can obviously not occur the
way the model is configured. Manufacturing cycle time is exaggerated as the
operations are scheduled to respect the routing precedence constraints. This same
problem applies to inventory relationships, where work-in-process inventories
connect operations.
The proper use of lot multiples in the application will produce a schedule which
reflects reality on the shop floor informing PS of the appropriate proper material
flow between manufacturing stages will allow manufacturing to be scheduled much
more flexibly. In the example below, the lot multiples have defined at the 25 unit
value which represents the true flow of material between production stages.
Manufacturing cycle time is drastically reduced, there is more concurrent
manufacturing occurring, resource usage, inventory production and consumption is
accurate as well.
Page 23
Work Orders and Lot Multiples.
Of course, when work orders are introduced into the equation this changes the
problem somewhat. When work orders are created within ERP and sent to PS,
they will resemble the first scenario as they are pre-lot sized. In a work order driven
environment, the primary sources of demands are explicit work orders across the
scheduling horizon. In a work order driven environment, these work orders may or
may not have a matching demand associated with them. The major difference in
this approach is that these work orders usually have quantities greater than the
routing lot multiple, which inherently provides for scheduling inaccuracy as
durations and precedence relationships are distorted.
For example, take the following routing which produces Item A in a lot multiple
of 25 units:
Assume a work order for 50 units of Item A is due at January 11th, 4:30PM. When
PS schedules this work order, it will result in the following:
The work order states a manufacturing requirement of 50 units on 3 operations,

which reduces scheduling flexibility and accuracy. When the Work Order was
created, it was created for the entire quantity of 50 units. All three operations are
accordingly scaled for both duration and any applicable parts consumption.
Obviously, there are issues with this:
Page 24
Makespan Exaggeration - Total Routing Makespan shows up as 18 Hours, but

can feasibly be accomplished in 13 hours (see next diagram).
Inventory Distortion In PS, materials are consumed at the start of an operation
and produced at the end. Since the operations are run back to back and as 1
operation, both these times are distorted consumption of materials is early and
only at the end of the operation are produced components released to downstream
operations.
Resource Use Exaggeration - The use of resources across the routing is
exaggerated, in particular on Operation A and Operation B there is actually some
idle time available between the first two units of work which is not available for
other operations.
Many people recognize these issues and some have chosen to use operation overlap
on work order operations as an answer, which results in the following schedule:
Although the overall make span problem appears to be resolved as it is now 13
hours, this approach still has problems as well.
Inventory Distortion In PS, materials are consumed at the start of an operation
and produced at the end. Since the operations are run back to back and as 1
operation, both these times are distorted consumption of materials is early and
only at the end of the operation are produced components released to downstream
operations.
Resource Use Exaggeration - The use of resources across the routing is
exaggerated, in particular on Operation A and Operation B there is actually some
idle time available between the first two units of work which is not available for
other operations.
Precedence Infeasibility Since a single Operation B requires all inventory to be
available at the start of operation, it can not actually feasibly start until Operation A
is completed (when the inventory is released). The application of overlap does not
address this during the scheduling process.
Precedence Relationship Distortion The use of operation overlap only
provides a subset of precedence relationships that PS can handle and can not
handle non-linear relationships at all. For example, consider the following types of
precedence relationships:
Page 25
Precedence Relationship between

Operations
Handled in PS
Handled with Operation

Overlap on a Work Order
Starts at Start
Starts After Start with flexible

separation times (i.e. No Min
and No Max Separation
Specified)
Starts after Start with Minimum

Separation, but No Max
separation
Starts after Start with no Minimum

Separation, but with a Maximum
Separation time specified
Starts after Start with Minimum

Separation equal to Maximum
Separation
Ends at End
Starts after End with neither Min

or Max Separation
Starts after End with Min

Separation
Starts after End with Max

Separation
Starts after End with Both Min

and Max Separation Window
Starts after End with Minimum

equal to Max Separation time
Starts at End (Immediately)
Recognizing this, PS has a feature, which reconciles this issue by providing the
ability to schedule work orders according their individual lot multiple or unit of
effort - addressing the shortcomings of what work orders present in the world of
finite capacity scheduling. The approach provides complete schedule accuracy, as
production is instantiated according to individual units of effort required to
produce routing lot multiples. Lets take a look at this in a bit more detail.
Page 26
Building on the current

example, assume the user has
decided to enable this feature
within the application. The
feature is designed to be
enabled as either a global
option, which applies to all
routings or the user can select
the feature for a specific
routing. Obviously, this is an
attribute of the data model, but
for testing purposes the user
can enable this manually if
necessary. To do so, first, the
user navigates to the schedule
solver options and enables
Select by Routing.
Conversely, the user could disable this feature completely (default for migrated
models) or turn it on for all routings (default for newly created models).
Assuming the user chooses Select by Routing, the user now navigates to the
Routing itself in the workspace and opens up its properties:
In the Work Order Configuration

section of the dialog box, there is an
option entitled Schedule Work
Order operations according to their
unit of effort. This simply means
that any work orders, which refer to
this routing, will have the logic
applied to them when they are being
scheduled in PS.
Assume the user selects this option and solves again.
Page 27
Initial Schedule WITHOUT Units of Effort (18 Hour Duration)
Schedule with Units of Effort Enabled (13 Hour Duration)

As one will note, the work order schedule now schedules according to the routing
lot multiple. Two routing instances are now created and the issues outlined above
are now addressed.
However, once Units of Effort is enabled, most models will result in more
operations being planned. This in itself does not mean the model will be solvable
or not from a performance perspective - the main message is that it is important to
ensure operations reflect logical inventory relationships to ensure sequencing
flexibility, inventory accuracy from both a production / consumption perspective
and manufacturing make span accuracy.
Page 28
PS FUNDAMENTALS: SUPPLY AND DEMAND.
The following are some common best practices in regards to modeling supply and
demand within PS. As discussed earlier, it is important to note that PS should not
be used to perform MRP rather it should be used to ensure production schedules
are material feasible.
Ensuring sources of supply for all items.
Have you ever experienced the following error message with an accompanying
infeasible schedule?
Schedule: Schedule #1
Error : No Producing Operation in Model
Hints:
Resource
"Raw Material"
Time
Date Time: 2008/03/24 15:53:20
When modeling procured items, it is necessary to ensure all items have a source of
supply whether that be via a Supplier / Item relationship or a producing operation.
Its all too easy for this type of error to occur due to data integrity, therefore try to
put in some simple checks and balances within your integration environment to
account for this.
Removing supply events beyond item lead-time from the model
Purchase Orders or other supply events should not be imported into PS beyond
purchase lead-time as this can cause PS to delay production when there is not
enough supply to meet short-term requirements. This effect is shown below.
Assume the Raw Material has a purchase lead time of 5 days. However, a
purchase order is in PS 9 days into the horizon. Due to this, Operation 1 has been
delayed until the PO arrives causing the demand to be late.
Page 29
However, as shown below, the operation could actually be run earlier if the PO was
removed. This would allow the PS Solver to create its own supply event based on
the specified supplier lead-times.
Demand Earliest and Latest Dates.
The earliest and latest dates on demand lines should be left to null unless there are
significant reasons for them to be populated. Latest dates in particular impose
hard (not difficult, but meaning they can not be violated) constraints to the solver
and this potentially will increase solve times. Use only opportunistically.
Demand Prioritisation.
In most manufacturing environments, demand priority setting is a common

practice. These priorities are generally dictated by various factors such as customer
size / revenue contribution, length of time a sales order has been outstanding,
predetermined agreements and other factors. In the event of resource conflicts,
higher priority orders are expected to receive preferential treatment over other
orders in the system.
Demand priorities often change during planning simulations such as when a

scheduler is doing ad-hoc order promising to facilitate the effect of adding a hot
order to the existing production schedule (i.e. which other demands are late or
affected). This can be an iterative process to achieve the schedule and service
levels the user is satisfied with.
PS allows users to input 3 new order classes (Hot, Committed and Uncommitted).
Within each of these classes contain priorities 1-5. Uncommitted orders are
Page 30
essentially opportunistic orders, which look for holes in the schedule and/or
inventory to fill a given demand. For example - two demands (Demand 1 and
Demand 2) have stated priorities of2 and 1 respectively. Demand 1 is due on
Day 1 and Demand 2 is due on Day 2. Each demand shares a common machine,
which is used to manufacture the respective items on the demand. If there are no
resource conflicts (i.e. there is enough capacity), Demand 1 would be scheduled
first (the lower priority demand due earlier) and Demand 2 would be scheduled
next (the higher priority demand due later). However, if these demands compete
for capacity, users expect that the higher priority demand would be fulfilled first
which is where demand priorities and order classes come in.
PS FUNDAMENTALS: SOLVER TUNING.

Earliest or Most Contention?
You can configure whether the solver first addresses earliest or most resource
criticality
In PS, resource contention or criticality is a measurement that occurs in the

solver when two or more operations compete for the same resource at a given
point in time in the scheduling horizon. The more operations that need to be
scheduled on that resource at that given point in time coupled with its capacity,
the higher the resource contention or probability that constraints will be
violated.
Focusing and resolving the most critical constraints in the horizon has generally
been regarded as the most effective scheduling strategy to resolve floating
bottlenecks when sequencing operations. Addressing the more critical
problems first results into the problems being broken down into smaller subproblems which are easier to resolve.
Solving in this fashion provides high quality results for most PS client models.
However, sometimes resolving the highest levels of criticality in the horizon
first may not necessarily be the optimal scheduling strategy, but rather
addressing the earliest instances of resource criticality may be more efficient in
some cases, such as (but not limited to):
Routings which contain recursive resources that are considered

manufacturing bottlenecks
Coupled with the recursiveness, a mixture of crewed / non-crewed

operations that also require these bottleneck resources
Preferred run times for non-crewed operations during non-business hours

(e.g. Evenings and weekends)
Page 31
To allow users to solve with either the default (i.e. Most Contention) or Earliest
Contention flag set, there is a new
flag in the Scenario | Solver
Options dialog box.
In terms of when to use this

functionality, there are no hard
and fast black and white rules as to
when this option is applicable or
not other than some of the general
guidelines specified above. It is
advisable to run some trials with
this option enabled or disabled to
understand the differences in
schedule quality.
Resource Offloading
When making resource offloading decisions, the solver does a capacity evaluation
of each resource when placing operations where they are required to meet a given
demand on time. This happens operation-by-operation, one at a time when they
are placed initially in the horizon before detailed operation sequencing takes
place. If the utilization of the resource is greater than its offload threshold, it will
offload to an alternate (if available).
When performing the utilization calculation, a given operation instance is
considered, starting with the operations closest to the beginning of the horizon.
Lets say, the duration of a given operation instance must finish by time t to meet
the demand date of the order it is associated with.
At this point, the solver looks at how many other operations have to be finished
before time t that are already assigned to the same resource and calculates the
total utilization from the horizon start or the prebuild target time which you have
defined on the resource and t. The utilization can be expressed as the total run
time of all the operations (except for the given operation) running between the
horizon start or prebuild target time and t divided by the total up time and t
(which his net of calendar downtime / delays and dynamic capacity).
Utilization = {Total Time Required of All Operations (excluding current op

(from start of horizon or prebuild taget to t)}
{Total Available Time (from start of horizon to T,
net of calendars)}
Page 32
If the utilization level exceeds the off-load threshold for a resource with the highest
preference, then the solver will off-load it to a secondary resource with a lower
utilization level. If the preferences are marked as the same, then the solver will try
to evenly utilize each resource. This off-load process is performed from the
earliest operations in the horizon to the latest operations. The resource specific
flag is illustrated below.
The reason that you may want to use this flag is simple. If the solver looks back
from the start of the horizon (as opposed to the prebuild window), it may not see
the resource as hitting its offload threshold from that point in time, although it
may be very busy around the time that the demand is due. This may result in
longer make-spans or late demands or both.
For example, the diagram below illustrates the window of time (on the highlighted
red operation) that would be used to decide if resource 200-101 or 100-103 is used.
Page 33
If not prebuild target was specified, the solver would look to the
beginning of the horizon when performing the offload calculation. If a
two day prebuild target was specified, the solver would look back two
days only to determine utilization and offload to the alternate, enabling
more flexibility during sequencing.
Without the use of the prebuild target, operations could potentially be
sequenced much earlier on this resource. For example, assume the
offload threshold was set to 75% utilization of 200-101. From the start
of horizon to the time the highlighted operation is required to meet the
demand on time, assume the utilization is 74%. The operation would
not be off-loaded resource 200-103. As a result, the operation may be
sequenced (subsequent solver step) to run earlier, resulting in a long
makespan or later (resulting in a late demand) while there appears to be
idle time on the alternate machine.
Page 34
PS FUNDAMENTALS: OTHER ITEMS.

Calendar down times and temporal constraints.
Down times in a calendar do not allow a job to be suspended for the duration of
the down time and resume once the calendar is up. In effect down times force a job
to find a contiguous chunk of up time to run in.
Alternately delay times allow a job to be suspended during the event and resume
once the calendar is up again.
Job A
Gap
UP
Job B
DOWN
Job C
UP
An example of Down Time

Job A
UP
Job B
Job C
DELAY
UP
An example of Delay Time
Down times when combined with tight temporal relationship constraints can cause
schedule infeasibility. Take for instance two related operations. The first runs for 6
hours and the second runs for 4 hours. If the temporal relationship between the
two operations is Start at End then in effect the solver needs to find 10 hours of
contiguous up time do satisfy the two operations. If the company uses a 8 hour
shift with down times in between then it would not be possible for the solver to
find a 10 hour block to schedule the operations and the solve will become
infeasible.
The moral of the story is:

1.
Avoid down times except for those situations where it is absolutely not
possible to have a job straddle an unproductive time. For instance
Machine Maintenance, or food industry where spoilage issues prevent a
job from being suspended
2.
Avoid, where possible, the use of Start at End (S@E) relationships.

Start after End (S>E) will normally produce similar results due to the
Page 35
JIT nature of the solver but without the hard constraints associated with
Start at End.
Operation and Resource Groups
A well thought through group structure can have a significant impact on the model.
Resource and Operation Groups can be used to:
1.
Simplify the Change Over Rules by

a.
reducing the number of entries and
b. making the entries using product relationships more logical

c.
2.
reducing the maintenance when products are added or deleted
Make the Schedule Views (Gantt charts etc.) easier to view and navigate.
Page 36
DEBUGGING MODELS.
In this section we investigate common problems in a model and some of their

solutions.
Infeasible Schedule - Insufficient Capacity.
If a resource has a capacity of 2, while an operation requires 3, then schedule

infeasibility will be detected. And the solve will be aborted.
Message Type: Error
Time: 2008/03/27 15:43:29
Message: Validation Error - 100.000, 1.00 hours (Reusable Resource
Utilization Link): Operation exceeds the capacity of resource Packer 1.
Infeasible Schedule No producing operations.
The scheduler needs to know how to make or obtain products. When this happens
the following type of message is displayed in the log file:
Error : No Producing Operation in Model
Hints:
Resource
"Apples"
Time
Date Time: 2005/01/11 22:14:05
MinLevel
Level:
0
NumProducers
Number: 0
NumConsumers
Number: 1
StartingLevel
Level:
-1820836480
There are two common causes for this:
1.
2.
A purchased material does not have a supplier record associated with it

There is no manufacturing operation for a product
Infeasible Schedule Tightly constrained work orders.
Tightly related work orders (e.g. Start at Start relationship) with material
(producing/consuming) relationships between the work orders.
Infeasible Schedule Calendar down events.
As explained earlier, if calendars use down events then there is a possibility that an
operation or a series of linked operations with tight temporal relationships may not
have enough up time to complete in. In this case the schedule will be infeasible.
Page 37
Infeasible Schedule Conflict producing and consuming operations in

the same routing.
As explained earlier, if a product is both produced and consumed in the same

routing and the amount produced is less than the amount consumed then the solve
will become infeasible (assuming no starting inventory).
Schedule: Schedule #1
Error : Unbalanced Item in Routing
Hints:
Routing
"Routing #1"
Resource
"New Item #1"
Produced
Level:
1000000
Consumed
Level:
2000000
Infeasible Schedule Other Causes.
Circular references where two or more routings produce and consume

products such as to cause a circular reference.
Related work orders that have material dependencies with conflicting

precedence defined.
Avoid specifying Latest dates on demands
Insufficient resource capacity Where there is insufficient capacity to

meet demand within the entire internal Production Scheduling horizon
(1yr before, 8 yrs after). This tends to indicate a problem with plan data.
Excessive solve times.
There are several causes of excessive solve times. The following are some of the
common causes:
If solve times are excessive and the solver message seems to be stuck at
Assigning operations to resources, there is a good probability that the
model will be suffering from a lot size problem. The user should review
the lot sizes and ensure that the number of operations generated will be
less than 50,000.
Max inventory levels are too restrictive. In this case turn on the Relax
Max Constraints flag. Similarly avoid the use of shared storage spaces.
Lowering the threshold for certain resources allows the solver to offload
some production and make sequencing easier
Page 38
CRO produces questionable results.
1.
2.
Check that the costs used by CRO are all populated and reasonable for the
schedule objectives
Changeover costs
Inventory - Carrying cost
Inventory - Safety stock violation cost
Inventory - Stockout costs
Resource Setup costs
Resource Operating costs
Validate the CRO solver by turning on View Campaign Run Optimization
solution results only. This can be found in the scenario Solver Options
3.
Validate the cycle /bucket size
4.
Remember that stock out costs etc are not incurred unless the stockout occurs
at the end of the CRO cycle/bucket
Page 39
General Debugging.
The following are some common steps that can be used to identify the problems in
a model. As some of these steps are destructive, ensure that you save the
model under a different file name or use a separate scenario before starting
these steps. You may try these in different sequences to try and understand the
nature of the problem. After making the change, the Resource Gantt chart may
provide clues to the problem.
Delete work orders

o Easiest method of doing this is by deleting the folders under the
top level work order folders (e.g. those under the Production
Orders folder)
Turn Units of Effort off for Work Orders.
o Assumes you have not deleted the work orders !
o If the solve is fast with Units of Effort turned off then this would
indicate a lot multiple problem!
Inactivate Demands and then re-active one demand (possibly progressively
activate more)
o The easiest way of deactivating the demands is by right clicking
over the Demand folder and selecting Change.
Relax other constraints
o Inventory minimum
o Resources
o Calendars
Page 40

May 2008
Author: John Chivers
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com
Copyright 2007, Oracle. All rights reserved.
This document is provided for information purposes only and the
contents hereof are subject to change without notice.
This document is not warranted to be error-free, nor subject to any
other warranties or conditions, whether expressed orally or implied
in law, including implied warranties and conditions of merchantability
or fitness for a particular purpose. We specifically disclaim any
liability with respect to this document and no contractual obligations
are formed either directly or indirectly by this document. This document
may not be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without our prior written permission.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Other names may be trademarks of their respective owners.

Ps Implementation

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Ps Implementation

Hochgeladen von

Copyright:

Verfügbare Formate

Production Scheduling

Production Scheduling Implementation Guide

This document is intended as a starter kit for people implementing Production

It is important to note that every implementation is different; in particular

ERP consulting companys implementation process and experience

Production Scheduling Implementation Guide

Make Store Pack or Synchronous make packer scheduling with 2 stage

Because of this diversity it is not possible to provide a template for all

Typical project plan describes the various processes and participants in a

Schedule success criteria Helps implementers frame the objectives of a

PS fundamentals: Inventory Key aspects of setting up inventory items in

PS Fundamentals: Machines/ Crews and Tools Key aspects of setting up

PS Fundamentals: Routings and Operations How to configure routings

PS Fundamentals: Supply and Demand How to model supply and

PS Fundamentals: Other items Covers the must know aspects in other

Debugging Tips How to resolve problems in a model under

Production Scheduling Implementation Guide

A TYPICAL PRODUCTION SCHEDULING PROJECT PLAN.

Production Scheduling Implementation Guide

Initial Product Training

Resources: Oracle University Production Scheduling Training Course

Collect Prototype Data

Production Scheduling Implementation Guide

The purpose of the prototype is:

Develop Detailed Model

Develop User Acceptance

As part of the detail design process consider:

Production Scheduling Implementation Guide

This is highly dependent upon the nature of the implementation.

Unit and System Testing

Go Live Sign off and Go

Sign Off is a key part to going live.

Production Scheduling Implementation Guide

Production Scheduling Implementation Guide

A pre-implementation questionnaire has been developed to:

Provide input into the implementation estimation process

The pre-implementation questionnaire can be customized for individual

Suitability of PS to solve the customers requirements

Production Scheduling Implementation Guide

SCHEDULE OBJECTIVES AND SUCCESS CRITERIA

For a successful implementation it is best

Production Scheduling Implementation Guide

Maximize demand satisfaction

Choosing an objective will drive:

Production Scheduling Implementation Guide

USER ACCEPTANCE TESTS

Production Scheduling Implementation Guide

Production Scheduling Implementation Guide

PRODUCT SCHEDULING FUNDAMENTALS.

The following sections briefly address some basic production scheduling

Maximum Inventory Levels and Storage Areas.

Supplier Items and Order Multiples.

Production Scheduling needs to represent supplier information for purchased

Production Scheduling Implementation Guide

behaviour. However if must be remembered that from a scheduling perspective

How much of the raw material do I have now

Production Scheduling Implementation Guide

PS FUNDAMENTALS: MACHINES/ CREWS AND TOOLS.

CRO focuses on maximizing selected

Campaign Run Optimisation.

PS has an additional solver option - Campaign Run Optimization which

CRO has some limitations

Multi Capacity versus multiple

Solve Sequences allow users to