To streamline the menu, make a dependency table first: two dishes may have the same ingredients, but they do not share the same set of actions.

Menu streamlining does not mean deleting dishes from low to high sales, nor does it automatically classify dishes using "chicken" and "tomato" as shared ingredients. Each dish must be connected to specific raw material specifications, pre-treatment, oven locations, personnel, utensils, cleaning and service periods, and then see if deleting, merging or changing the schedule can truly reduce dependence. If the low-frequency dishes use the ingredients and tools already available in the store, there may be little increase in complexity; if the high-frequency dishes require special marinades, special containers, and a unique stove location during peak times, it may create more inventory and task conflicts.

Alto-Shaam's original article cited simplified menus, shared ingredients, inventory control and multi-function equipment as general suggestions for reducing kitchen operating costs. [1] This is a list of questions in the context of manufacturer marketing. It does not prove that any store will save costs after adopting it, nor does it prove that a certain device can replace on-site verification. The following dependency tables and hypothetical examples are constructed by the author to determine the next step, rather than claiming that business results have been achieved.

There must be a dependency table next to the sales table

First, establish nodes for each candidate dish: sales period, raw material SKU, packaging and processing status, recipe version, preprocessing, storage location, heating task, exclusive stove position, pots, serving utensils, cleaning, disinfection, drying and storage. Sharing is possible only if two dishes are connected to the same node; sharing is not possible if they are similar in node names but use different specifications, tasks or time windows.

Below are two examples of dishes constructed by the author. All names and times do not represent real stores.

Depend on	Dish A: Herb Chicken Rice	Dish B: Spicy Chicken Wraps	Is it truly shared?
chicken	Raw material SKU-J1, not pickled	Raw material SKU-J2, pre-pickled by supplier	No; the name is the same but the specifications and ingredients are different
tomato	Fresh tomatoes T1, diced	Same T1, same dicing specifications	May be shared after batch and usage verification
preprocessing	Uniform allocation in the morning	Independent unpacking and repacking after arrival	No
Furnace position	11:00-11:20 Occupy furnace position 1	11:10-11:30 Occupy furnace position 1	No; peak overlap conflict
utensils	General purpose platters and jigs	Special pressing plate and slotted pallet	Partially shared
End of class	Regular turnover	Wash, dry and store special utensils separately	No

This table reveals two things. First, if both dishes are written as "chicken", the inventory cannot be merged, because one is unmarinated SKU-J1 and the other is pre-marinated SKU-J2 from the supplier; the ingredients, processing status and applicable instructions may be different. Second, it seems that fresh tomatoes T1 can be shared. The cut type, recipe dosage, batch and food processing conditions must also be checked. You cannot just merge the purchase names.

The dependency table must also explicitly write out the before and after connections: raw materials point to preprocessing, preprocessing points to equipment tasks, and equipment tasks point to finished products and equipment turnover. If you delete dish B and only buy one less chicken SKU, but leave other stove tasks at the same peak, the equipment conflict may not disappear; if the special equipment of dish B is no longer used, the closing movement may be reduced. Only by recalculating along the connection relationship can we know where the complexity actually moved.

Shared ingredients must share specifications, status, and permitted uses

When judging the sharing of raw materials, we don’t ask “whether they are the same ingredient” but “whether they are the same controlled object”. Check suppliers, product codes, packaging, net content, processing status, formula ingredients, batches, storage, receipt, cutting and substitution conditions item by item. Any differences affecting dish claims, food handling or handling cannot be overridden by "same name".

For example, dish A requires unmarinated chicken to be processed according to the store's recipe, and dish B uses pre-marinated chicken from the supplier. If the two are combined into one SKU, the formula, front office ingredient response, personnel actions and occupied time may be changed at the same time. Even if it is sensory close, it is not a share that can be individually approved by the purchasing staff. Truly shareable nodes should record applicable dishes, usage, peak demand, failure conditions and approval roles; recheck when the raw material version changes.

Sharing does not mean receiving a large package of all dishes at the same time. Centralized purchasing may reduce SKUs, but increase packaging, labeling, storage location and remaining management after opening. The dependency table should show both the purchasing package and the actual unit used to see if more conversion actions are added to save one product code. If there is no on-site data, it will only be listed as a solution to be verified, and the savings amount will not be written in advance.

Oven positions are plotted by "full occupancy" rather than heating minutes

Assume that dish A enters furnace position 1 at 11:00, is heated to 11:15, and is removed and cleared at 11:20; dish B was originally planned to enter the same oven position at 11:10, heated to 11:25, and cleared out at 11:30. If the table only states effective heating for fifteen minutes, both tasks will seem very short; when placed on the common timeline, dish B will wait from at least 11:10 to 11:20. This waiting is a scheduling conflict and does not prove that dish B must be deleted.

First test the solution without changing the dishes: adjust the batch size or start-up time, move preparations that can be completed in advance out of the peak, use another oven that has been confirmed to be suitable, or adjust the service time that can be honored. Each path must retain the conditions of raw materials, food processes, personnel and equipment, and unverified heating or clearing cannot be compressed in order to avoid overlapping on the map.

In addition to the equipment, the schedule should also show the same employee, the same pot, and the same channel. If the equipment is idle but the operator is processing another batch, the task still cannot be started; if both stoves have empty seats but share the only pot, there will also be a queue. In this way, we can distinguish whether the conflict comes from the dishes themselves, batch design or scheduling, instead of blaming all the waiting on "too many menus".

Customer substitution must record real choices and cannot be replaced by internal similarities.

The kitchen believes that dish A and dish B are both chicken staples, and customers may not think that they are substitutable. If the sale of dish B is suspended during the short-term trial, only the requests that actually occurred during the effective display and sales period of dish B will be recorded: original dish transaction, clear change to dish A, selection of other dishes, cancellation, waiting, or failure to confirm. No preferences are inferred from customers who are not asked, ordered, or cannot be observed.

The customer's departure or cancellation cannot be regarded as a successful substitution; if you clearly change the selection of dish A, you must also check whether the waiting, out-of-stock, and remaining quantities of dish A have changed. Otherwise menu streamlining simply shifts demand and abandonment to another dish. Price, promotions, placements, weather, group orders, and personnel anomalies are listed separately, and short-term correlations are not written as long-term preferences or causation.

Write stop conditions before testing. For example, if sales are suspended and canceled, out of stock, or the wait exceeds the pre-approved range, or if there are gaps in food processing and ingredient information on substitute dishes, the original plan will be restored and records of occurrences will be retained. The rollback needs to include the same version of the menu, kitchen tasks, and front-of-house dialogue, not just putting the dish names back on the page.

Washing, disinfection, drying and storage should be calculated separately

Complexity is often transferred from peak production to closing shifts. Utensil turnover is broken down into at least collection and pretreatment, cleaning, disinfection, drying or cooling, inspection, storage and reuse. Different facilities, personnel and spaces may be used in different links; the end of a machine program does not mean that the equipment has been dried, inspected and returned to a usable position.

link	Record start and end	key object	Alternatives that should not be used
Clean	Wash until the dirt removal step is completed	Tools, loading, procedures, rework	"The machine has capacity"
Disinfection	According to the disinfection stage of the applicable process	Procedure, condition, batch, exception	“Washed so sanitized”
drying/cooling	Out of the machine until the subsequent processing conditions are met	Placement, time, space, re-contamination control	"The program can be stacked after the program is completed."
store	After inspection is completed, it will be used next time	Location, protection, quantity, accessibility	“It can fit in the cabinet”

If dish B uses a special pressing plate, deleting it may reduce the number of utensils; but it depends on whether the utensil is shared with other dishes, how many pieces are actually per peak, and whether it will cause additional loading, rewashing, drying and storage. The manufacturer's nominal capacity or drying description can only be used as a parameter for further verification of the specific model, and cannot cover the complete turnover, nor can it prove the reduction of total movement. In the absence of formal specifications and field testing, it is more honest to use a general equipment category than to list an unrelated model number.

Rework in particular cannot disappear. If the equipment needs to be rewashed due to improper loading, the program is interrupted and needs to be reprocessed, or there are still residues after leaving the machine, the start and end and the reason should be kept. If the menu is streamlined and the types of utensils are reduced, but each load becomes more crowded and rework increases, the complexity may not necessarily decrease. The closing time should also be viewed together with the cleaning results and availability status for the next day, not just when employees clock in.

When deciding whether to stay or leave, write down the reduced items, increased items and unresolved items at the same time.

Each alternative forms a row of decision accounts. Write down the deleted or merged dish versions, the expected reduction of raw material SKUs, storage locations, stove location conflicts, special equipment and shift closing actions; also write down the new centralized packaging, alternative dish pressure, labeling, training or scheduling actions; finally list the unresolved customer needs, food information, equipment and cleaning conditions.

For the hypothetical example of dish B, the limited conclusion that can be drawn is: "Stop selling dish B can reduce SKU-J2 and special pressing plate, and eliminate the conflict between dish B originally entering the oven at 11:10 and dish A occupying until 11:20; but the current observation is not enough It proves that customers will steadily switch to dish A, and there is no evidence that the wait for dish A itself is reduced; the peak value of tomato T1 and the remaining number of dish A still need to continue to be observed. "This is more reviewable than "deleting low-frequency dishes can reduce costs", and also allows the results to support the retention of dish B.

Decisions are first limited to clear stores, time periods and menu versions, and set review dates and rollback conditions. When the menu, raw material specifications, equipment, personnel or service channels change, the dependent table is updated with the version, and the expired table is not regarded as a permanent fact. The final judgment is not which dish has the most nodes, but which solution has indeed reduced total dependence and failed actions while maintaining the boundaries of necessary food and services; when there is no evidence, the conclusion is to continue to verify, rather than filling in the blanks with manufacturer promotions or equipment names.

References

• Reduce Operating Costs in The Kitchen