Multi-Plant Scheduling

Key Concepts

PlanetTogether allows plants that are interdependent on one another to be modeled using its Multi-Plant Scheduling features. The multi-plant system allows for collaboration between plants whose processes are interconnected. For example, a job's manufacturing orders can be set to occur in different plants as once and the operations belonging to those manufacturing orders can also be completed in separate plants. In addition, jobs finishing in one plant can act as material supplied for a job in another plant. 

Multi-Plant Scheduling Features

Can Span Plants

To allow operations to schedule in different plants, the job and manufacturing orders' "Can Span Plants" must be set. If a Job is set to "Can Span Plants", then all of its manufacturing orders are eligible to be scheduled on different plants. However, each operation within the manufacturing order will be scheduled on the same plant. This feature is set by opening the Jobs dialog for a specific job, then checking the "Can Span Plants" box found under the "Entry" tab:

If the manufacturing order is set to "Can Span Plants", then the separate operations can be completed in different plants. This is set by opening the Jobs dialog for the specific MO, then checking the "Can Span Plant" of the Manufacturing Orders tab:

Note: Operations cannot span plants unless the operation has been split. Otherwise, all resource and capability requirements must be present in the plant for the operation to schedule. 

Is Locked:

A manufacturing order can be locked to a plant to ensure that it is started and finished within that plant. A common reason for locking a manufacturing order to a plant is proximity to the customer who ordered the product. If a manufacturing order is locked to a plant, every operation belonging to the manufacturing order will also be locked to a plant. Manufacturing orders can be locked to a plant from the Jobs dialog. Under the Manufacturing Orders tab, select the plant you wish to lock the MO in from the drop-down menu of the "Locked Plant External Id" column.

Architecture:

  • There is no limit to the number of instances that can be run on a server. Additionally, each instance can have any number of plants.
  • Plants in the same instance can be independent or interdependent of each other.
  • Changes in one plant schedule updates other plant schedules in real-time (i.e. using drag-and-drop, optimize, completed jobs, offline capacity intervals, etc.)
  • Jobs can be supplied from jobs, purchase orders, or transfer orders from other plants. 

Integration:

  • When using multiple instances, each can have its own integration mappings and publish databases. 
  • Jobs can be manually or automatically level-loaded across plants (either the entire job or parts of the job, if allowed). 

Users & Security:

  • Multiple users can be logged into the same instance concurrently, regardless of the level of access they possess. They can also plan and create scenarios concurrently.
  • Users can have various levels of access to the scenarios. Master schedulers may have full access to view and edit all plants' schedules while other workers may simply have viewing or What-If scenario access. 
  • Users can see data from multiple plants in one session from the Gantt, Grids, and Alerts.

Optimization & MRP:

  • Single pass optimize generates a synchronized schedule across all plants. Plants can also be optimized separately according to their own set of optimize rules.                                                                                                  
  • Users can use their own personalized optimize options or can use a shared setup.
  • Single pass MRP will generate a plan across all plants present in the instance.
  • MRP can handle Multi-Plant and Multi-Warehouse situations.

Gantt:

  • Resources can be viewed by plant or by departments within a plant. 
  • Drag-and-drop can occur within a plant as well as between plants. 
  • Resources can be shared by jobs in separate plants. 

Multi-Warehouse:

  • Each plant can have multiple warehouses and each warehouse can have multiple plants supplying it.
  • Each item can have different routings/BOMs based on which plant or warehouse it is being produced in.
  • Transfer orders can be used to show inventory movements between plants and warehouses.
  • Multiple warehouses can be defined for inventory management in the inventory plan. The inventory information can be filtered by warehouse.

KPI:

  • Each plant can have a customized set of KPIs that will show different business measures.

Capable To Promise (CTP):

  • CTP requests can specify which warehouse the request can draw from.
  • CTP can be run in each plant where the item can be produced. 

Reporting:

  • All data is found in SQL, which allows us to easily create multi-plant reports. 
  • Plant-specific reports can also be easily created in a multi-plant environment.

Uses of Multi-Plant Scheduling

  1. Plant network capacity-level loading for redundant plants for planning and scheduling, or planning only.
  2. Optimization of vertically integrated plants.
  3. Splitting large plants into multiple "virtual plants" to enhance control when using multiple planners.
  4. Plants that share production resources can synchronize their schedules to ensure that the resources are available. 

Limitations of Multi-Plant Scheduling

  • Performance can be impaired with high data volumes as plant data is combined.
  • Scenarios must include all plants in the instance as converting to actual requires the coordination of all plants in the system. 
  • Imports are generally performed across all plants (system-wide). However, customizations are available if plant-specific imports are required. Publishing can also be done by plant or for all plants.
  • Data access permission flexibility is limited. Plant permissions can be set to that a user can be a viewer or editor per plant.
  • The system options are shared across all plants which creates less flexibility across multiple plants.