SeedTactic OrderLink Allocation

OrderLink Allocation

The allocation algorithm's job is to take the demand, represented as the unscheduled bookings minus the previously scheduled parts without bookings, and produce a daily schedule. The algorithm uses the flexibility plan to help estimate the available capacity. The goal of the allocation algorithm is to generate a daily part schedule that keeps the machines busy, produces parts according to their due dates, and prevents traffic jams and inefficiency. We offer a variety of allocation algorithms for different situations. The allocation algorithm is chosen on the schedule screen in OrderLink.

The greedy allocation algorithm is the default and is what we recommend that you start with.

Greedy

The greedy allocation algorithm first sorts the bookings by their due date, then by their priority, and finally bookings with matching due dates and priorities are sorted by expected machining hours (with bookings with larger machining hours appearing first). The greedy allocation algorithm then uses all pallets to produce work, using the sorted order of unscheduled bookings to determine what to run on a pallet. The simulation then produces quantities of each part produced during the horizon and these quantities are used for the schedule.

This is simple and works well when each booking is small and there is some flexibility for the parts that are produced. One danger is that a single large booking might dominate the system and interrupt other work. For example, if a single large booking arrives and consumes a pallet, there might not be enough work on the other pallets to fill up the remaining machines. This can be combated by splitting large bookings into separate smaller bookings or by adding flexibility. By splitting a large booking into several bookings over several days, we can improve flow by making a few parts for the large booking each day (e.g. instead of trying to make 30 parts on Thursday we could instead make 10 on Tuesday, 10 on Wednesday, and 10 on Thursday). Or, if there is enough flexibility, a single large order cannot dominate the system since other work has enough pallets and machines to fill up the system. We recommend that at least 20% of the work each day be flexible.

Daily Demand

In this allocation algorithm, the bookings are sorted by due date. For each day, the total demand for that day from all bookings with that due date is collected together. Thus for each day we compute a daily total part demand. The simulation then runs, only releasing the daily total demand for a single day at a time. Once the demand for a single day has been completed, the simulation moves on to the next day. The total parts produced during the schedule horizon is used for the calculated jobs.

This works well in situations where machining is not the bottleneck of the process. For example, if assembly is the bottleneck and assembly generates a daily build schedule, machining's job is to just produce the parts that assembly requires. Thus the daily demand will produce all the parts for a single day, ensuring that they finish before perhaps attempting to get ahead by starting on the next day's bookings.

The main danger is that a single day's demand isn't enough to fill up the machines and achieve high station utilization. In Daily Demand, only bookings for a single date at a time are allowed into the system at once. The problem is sometimes there might not be enough demand for a specific machine or a pallet might be overused with the current day's mix. Also, even if the daily mixes are well-balanced, you might fall behind and require producing part of yesterday's schedule and the remainder of yesterday's schedule might not be balanced enough to satisfy all machines.

To combat this, Daily Demand should be used only when there is a lot of flexibility. If most pallets can go to most machines, no matter the daily mix or even a part of yesterday's daily mix, the parts will be produced quickly using all machines allowing the work on the next day's schedule to commence.

By Due Date

In this allocation algorithm, bookings are sorted by due date and priority and simulated one-by-one. Only the demand for a single booking will be active at once and the demand for the next booking won't be released until the previous booking is complete. The collection of bookings finished by the simulation in the schedule horizon is then used as the job demand.

This allocation algorithm is good with systems with one or two machines where a single part can consume all the available capacity. With more than one machine and multiple pallets, this allocation algorithm risks leaving a lot of unused capacity, since only a single booking is active at once.

Total Demand

The total demand allocation algorithm is simple, even simpler than greedy. It just takes the total demand, consisting of all the unscheduled bookings minus the previously scheduled parts without bookings, and ignores the priorities and due dates. The total part demand is put into the simulation and the simulation is allowed to run for the schedule horizon. The quantities that the simulation produces are the job quantities for the schedule.

This is simple and works well with a short booking lookahead. The booking settings have a setting for order lookhead in days and only orders within this timeframe are loaded for consideration. When this is short, using the entire booking demand in the simulation can work.

There are several dangers:

Since due dates and priorities are ignored, a singe part can dominate the available capacity. Perhaps a part has small but consistent demand every day; by accumulating the entire demand ignoring due dates, the part might run a lot the first couple of days, pushing other parts past their due dates. This can be somewhat mitigated by restricting flexibility (for example, restricting a part to only a couple of machines) or by shorting the order lookahead, but this risks the next danger.
If flexibility is restricted and order lookhead is short, the danger is there might not be enough demand to keep the machines busy. In order to fill up the machines, we might need a couple cycles of a part with a short cycle time. If the lookahead is too short, there might not be demand for this part. Inserting a handful of cycles into the gaps in the schedule is where huge cost savings occur, so we always want to have some demand to be able to keep all the machines busy.
With short order lookahead but a large flexibility, there is the risk of traffic jams. By letting all pallets and all parts go active at once, small fluctuations in flow can snarl up the system. This can be mitigated by a careful flexibility plan and pallet assignment, and FMS Insight's pallet cycle time graph can detect this situation.

Prioritize Demand Hours

Prioritize demand hours is very similar to Total Demand in that the entire demand from all bookings is put into the simulation. The only difference is that for each part, the total expected cutting time across all bookings is calculated and the parts with more expected machining hours get higher priority. During the simulation, this primarily effects which part to produce when multiple parts share the same pallet. All the same dangers of Total Demand are present.

Custom Plugin

A custom plugin is a .NET Framework DLL which implements the IAllocateInterface from the BlackMaple.SeedTactics.Scheduling assembly. For documentation, see the BitBucket project.