Simulations

Who is this for ?

What you will learn :

A simulation lets you test a planning decision before you commit to it.

You pick one or more events. You change their dates or their quantities. Pelico then recalculates what happens next: material coverage, shortages, delivery dates, and the effect on the rest of your plan.

Nothing is committed until you say so.

Once your team agrees on a scenario, you commit it with a separate action. There are three of them, and they do different things. See From simulation to execution below.

Eight types of event can carry a simulation input.

You can also simulate gate committed dates on service orders. These use a separate mechanism, not the main basket.

💡This list is the same in every Pelico environment. Your configuration controls which simulation modes you have and sets limits, such as how many simulations can run at once. It does not change which events you can simulate.

You move the start date or the end date. Pelico keeps the original duration and moves the other date by the same amount. It counts working days only.

Example

Weekends do not count, so moving the start two working days later moves the end four calendar days later.

What counts as a working day. Monday to Friday. Saturday and Sunday are excluded, using your plant's local time zone. Pelico does not use your site calendar. Public holidays, plant shutdowns and shift patterns do not affect the simulated end date.

⚠️ This means a simulated end date can land on a day your site is closed. It can also look too optimistic across a holiday period. Read simulated dates as working-day arithmetic, and check them against your own site calendar before you commit.

This is the lever people use most. It answers "what if this slips?" and "what if I pull this forward?", and it shows you what that does to everything downstream.

You apply a percentage to the original quantity. Pelico recalculates the component needs. The dates stay as they are.

Example. You need 20% more output. Apply 120% and read the new material needs and any new shortages.

How the percentage is applied. Pelico converts it into a quantity and rounds to the nearest whole number. Component needs are then rescaled by the percentage and keep their decimals.

⚠️ A component need can therefore show decimals even though the order quantity is a whole number. This is normal. It is not a display error.

Use this lever when the change applies proportionally, especially across several events at once.

You type the quantity you want. The dates stay as they are.

Use this when you know the exact number: a revised production target, or an order cut down to match the stock you actually have. No percentage is involved, so nothing is rounded.

💡Percentage or exact number? Use a percentage when the change is proportional and applies to several events. Use an exact number when you know the figure you want for one event.

One simulation can hold many inputs across many events. You can change a date and a quantity on the same event in the same scenario. The two fields are independent and Pelico applies them together.

There is one exception. On a stock transfer order, you can simulate either the sending date or the receiving date, but not both. You can still change a date and a quantity on the same transfer order.

You start from any view that lists events. Most people start from the Work Order Book.

💡Build up your simulation step by step. Change one thing, read the impact, then add the next change. A simulation with fifteen changes at once is hard to understand when the result surprises you.

💡You will not lose your work. If you leave a simulation half-finished, Pelico saves it to the basket rather than throwing it away. The default wait is 8 hours.

Every saved simulation goes into the Simulation Basket. This is a shared space, so your colleagues can open your scenarios.

You cannot edit a saved simulation in place. To change one:

💡This protects your work. Nobody overwrites the original scenario by accident, so you keep a record of the options your team looked at. It does mean the basket fills up with similar scenarios, so give them clear names.

A simulation only helps if you look at the right views afterwards. Three of them work together.

💡People skip the Line of Balance step, and it is the one that catches the most problems. Rescheduling takes pressure off the events you moved, and it can put pressure somewhere else. Always finish there.

You can also download the current table as a CSV or Excel file, for offline review or to share outside Pelico. This export stays on your machine. It writes nothing back to Pelico or your ERP.

Testing a scenario and committing it are separate steps. Three actions commit a scenario, and they are not stages of one process. None of them triggers another. Pick the one that matches what you want.

⚠️ Apply to execution plan does not reach your ERP. Your changes stay in Pelico and survive after you log out, but they never travel outward. If your ERP needs to know, you also need Push to ERP.

Where it is switched on, Push to ERP writes your changes back to your source system. It covers work orders, customer order lines, purchase order line schedules, ASNs, purchase requests, service orders and stock transfer orders, including their dates and quantities.

How it behaves:

⚠️ Push to ERP is not available everywhere. If you cannot see the action, it has not been switched on for your environment. Talk to your Pelico contact. Where it is not available, you enter the changes in your own systems.

💡 Push to ERP is the only step that leaves Pelico, so treat it as the point of no return. Check the scenario in the basket and on the Line of Balance first.

The situation. Some work orders are still in Planned status even though their planned start date has passed. You need to reschedule them to realistic dates without creating new shortages.

What to do

The result. A reschedule you can defend, tested end to end before anything is committed, and a scenario your team can challenge.

The situation. Work in progress is the recurring problem in MRO. Service orders sit blocked on missing parts, and neither the OEM nor your supply manager can get the parts to you fast enough to help this month.

The idea. You may not need more stock. You need the right service orders served first.

Several service orders may need the same scarce part. Some are missing one or two components. Others are missing many. If you send the available parts to the nearly finished orders, you close more orders with the same stock. Work in progress drops without a single extra part.

How simulations help. Two levers drive priority in MRO:

Moving a commitment earlier raises that order's priority when Pelico allocates material. The scarce part goes to the order that can actually be finished with it, instead of to an order that will stay blocked anyway.

The result. Better coverage, and therefore better on-time delivery and revenue. You get there by changing the order of work, not by buying stock.

⚠️ Section to complete before publishing. The internal source illustrated this with a Required Coverage Date moved from 7 May to 11 April. That date is calculated by Pelico, not something a user can change, so the example does not work as written. This section has been rewritten around service order dates and gate committed dates. We still need confirmation of which field was actually changed in the original demo, so we can put a real before and after example back.