Detailed Production Modelling in Cosmic Frog (Neo – Network Optimization)

Depending on the type of supply chain one is modelling in Cosmic Frog and the questions being asked of it, it may be necessary to utilize some or all the features that enable detailed production modelling. A few business case examples that will often include some level of detailed production modelling include:

• Tactical capacity planning of packaging lines at a weekly or monthly level. Think for example of a beverage bottling company determining which bottling line at what plant should produce which product(s) for the next 8-12 weeks. This can involve optimizing how to manage seasonality where the model decides whether pre-building when there is slack capacity is more beneficial than sourcing from farther away if there is only slack capacity in more distant factories during high season. Known outages due to pre-planned maintenance and repair can also be incorporated as to minimize the impact of those. For a somewhat longer horizon, say for example 1-2 years, upgrades to existing lines or adding/removing any lines can be considered in the modelling too to see the impact on the overall utilization and costs.
• If raw materials, intermediates, bulk products, packaging products and/or by-products are a significant part of the network, either in terms of cost or storage space they take up, they may need to be included in the modelling. Where these are sourced from, their storage options, associated costs, and how these are converted into each other can be specified. Examples are for example the production of cheese or beer.
• Determine the production equipment investment strategy for the mid- to long-term based on forecasted demand. When and where is it most optimal to add or remove production capability in the next 5-10 years? Think of decisions like building a new plant vs adding new lines or upgrading existing line(s) at an existing plant, is it more advantageous to invest in higher throughput, more expensive equipment than in lower throughput less expensive equipment, etc. For these types of questions often a lot of scenarios that explore sensitivity around the demand forecast and supply & production costs are run to ultimately select the most robust solution to move forward with.

In comparison, modelling a retailer who buys all its products from suppliers as finished goods, does not require any production details to be added to its Cosmic Frog model. Hybrid models are also possible, think for example of a supermarket chain which manufactures its own branded products and buys other brands from its suppliers. Depending on the modelling scope, the production of the own branded products may require using some of the detailed production features.

The following diagram shows a generalized example of production related activities at a manufacturing plant, all of which can be modelled in Cosmic Frog:

In this help article we will cover the inputs & outputs of Cosmic Frog’s production modelling features, while also giving some examples of how to model certain business questions. The model in Optilogic’s Resource Library that is used mainly for the screenshots in this article is the Multi-Year Capacity Planning. There is a 20-minute video available with this model in the Resource Library, which covers the business case that is modelled and some detail of the production setup too.

General Pointers before diving into Detailed Production

To not make this document too repetitive we will cover some general Cosmic Frog functionality here that applies to all Cosmic Frog technologies and is used extensively for production modelling in Neo too.

Using the Neo (network optimization) Technology Filter

To only show tables and fields in them that can be used by the Neo network optimization algorithm, select Optimization in the Technologies Filter from the toolbar at the top in Cosmic Frog. This will hide any tables and fields that are not used by Neo and therefore simplifies the user interface.

Information contained in Tooltips

Quite a few Neo related fields in the input and output tables will be discussed in this document. Keep in mind however that a lot of this information can also be found in the tooltips that are shown when you hover over the column name in a table, see following screenshot for an example. The column name, technology/technologies that use this field, a description of how this field is used by those algorithm(s), its default value, and whether it is part of the table’s primary key are listed in the tooltip.

UOM (unit of measure) Input Fields

There are a lot of fields with names that end in “…UOM” throughout the input tables. How they work will be explained here so that individual UOM fields across the tables do not need to be explained further in this documentation as they all work similarly. These UOM fields are unit of measure fields and often appear to the immediate right of the field that they apply to, like for example Unit Value and Unit Value UOM in the screenshot above. In these UOM fields you can type the Symbol of a unit of measure that is of the required Type from the ones specified in the Units Of Measure input table. For example, in the screenshot above, the unit of measure Type for the Unit Value UOM field is Quantity. Looking in the Units Of Measure input table, we see there are 2 of these specified: Each and Pallet, with Symbol = EA and PLT, respectively. We can use either of these in this UOM field. If we leave a UOM field blank, then the Primary UOM for that UOM Type specified in the Model Settings input table will be used. For example, for the Unit Value UOM field in the screenshot above the tooltip says Default Value = {Primary Quantity UOM}. Looking this up in the Model Settings table shows us that this is set to EA (= each) in our current model. Let’s illustrate this with the following screenshots of 1) the tooltip for the Unit Value UOM field (located on the Products input table), 2) units of measure of Type = Quantity in the Units Of Measure input table and 3) checking what the Primary Quantity UOM is set to in the Model Settings input table, respectively:

1. 

 

2. 

 

3. 

Note that only hours (Symbol = HR) is currently allowed as the Primary Time UOM in the Model Settings table. This means that if another Time UOM, like for example minutes (MIN) or days (DAY), is to be used, the individual UOM fields need to be utilized to set these. Leaving these blank would mean HR is used by default.

Status and Notes fields

With few exceptions, all tables in Cosmic Frog contain both a Status field and a Notes field. These are often used extensively to add elements to a model that are not currently part of the supply chain (commonly referred to as the “Baseline”), but are to be included in scenarios in case they will definitely become part of the future supply chain or to see whether there are benefits to optionally include these going forward. In these cases, the Status in the input table is set to Exclude and the Notes field often contains a description along the lines of ‘New Market’, ‘New Line 2026’, ‘Alternative Recipe Scenario 3, ‘Faster Bottling Plant5 China’, ‘Include S6’, etc. When creating scenario items for setting up scenarios, the table can then be filtered for Notes = ‘New Market’ while setting Status = ‘Include’ for those filtered records. We will not call out these Status and Notes fields in each individual input table in the remainder of this document, but we do encourage users to use these extensively as they make creating scenarios very easy. When exploring any Cosmic Frog models in the Resource Library, you will notice the extensive use of these fields too. The following 2 screenshots illustrate the use of the Status and Notes fields for scenario creation: 1) shows several customers on the Customers table where CZ_Secondary_1 and CZ_Secondary_2 are not currently customers that are being served but we want to explore what it takes to serve them in future. Their Status is set to Exclude and the Notes field contains ‘New Market’; 2) a scenario item called ‘Include New Market’ shows that the Status of Customers where Notes = ‘New Market’ is changed to ‘Include’.

1. 
2. 

The Status and Notes fields are also often used for the opposite where existing elements of the current supply chain are excluded in scenarios in cases where for example manufacturing locations, products or lines are going to go offline in the future. To learn more about scenario creation, please see this short Scenarios Overview video, this Scenario Creation and Maps and Analytics training session video, this Creating Scenarios in Cosmic Frog help article, and this Writing Scenario Syntax help article.

Summary of Multi-Year Capacity Planning model

The model that is mostly used for screenshots throughout this help article is as mentioned above the Multi-Year Capacity Planning model that can be found here in the Resource Library. This model represents a European cheese supply chain which is used to make investment decisions around the growth of a non-mature market in Eastern Europe over a 5-year modelling horizon. New candidate DCs are considered to serve the growing demand in Eastern Europe, the model optimizes which are optimal to open and during which of the 5 years of the modelling horizon. The production setup in the model uses quite a few of the detailed modelling features which will be discussed in detail in this document:

• Raw and bulk materials are included in the modelling. As part of the cheese production process, the model uses recipes (bills of materials) to convert raw materials into bulk materials and make the finished goods from the bulk materials.
• The cheese making equipment, i.e. the production lines, at 2 plants is also part of the model. A new additional production line is set up at each of the 2 cheese making plants to see where and when a new line needs to be added to keep meeting demand.
• Detailed costs and capacities of the production processes are modelled.

Note that in the screenshots of this model, the columns have been re-ordered sometimes, so you may see a different order in your Cosmic Frog UI when opening the same tables of this model.

The 2 screenshots below show the Products and Facilities input tables of this model in Cosmic Frog:

1. We are on the Products input table.
2. Three raw materials (RAW_) that are ingredients of the cheese making process are being modelled: rennet, additive, and milk.
3. From the 3 raw materials, 5 different cheeses are made, in bulk form (BULK_…).
4. From the bulk materials, the 5 finished goods (FG_) cheeses (MOZ – mozzarella, CHE – cheddar, SWI – Swiss, FET – feta, and BLU – blue) are made by packaging the bulk materials.
5. All products have a value associated with them to calculate inventory holding costs.
6. Only the finished goods that will be sold have a price associated with them in order to calculate revenues.

Note that the naming convention of the products lends itself to easy filtering of the table for the raw materials, bulk materials, and finished goods due to the RAW_, BULK_, and FG_ prefixes. This makes the creation of groups and setting up of scenarios quick and easy.

1. We are on the Facilities input table.
2. There are 3 suppliers (SUP_) in this model, these supply the raw materials to the DCs.
3. There are 2 plants (PLT_) in this model, these turn the raw materials into the bulk products and package them into the finished goods.
4. There are 3 DCs (DC_) in this model, these receive the finished goods from the Plants and serve the 23 Europe based customers (specified in the Customers input table, not shown here).
5. There is an Overflow facility specified, which as a last resort can produce any of the finished goods at a very high cost and serve these to all the customers. This is really a modelling trick to not have the model return infeasible if there is not enough capacity to fulfill all demand. The results of when and where the Overflow location is used will give the user valuable information about capacity insufficiencies.

Note that similar to the naming convention of the products, the facilities are also named with prefixes that facilitate filtering of the facilities so groups and scenarios can quickly be created.

Here is a visual representation of the model with all facilities and customers on the map:

Production Modelling in Cosmic Frog

The specific features in Cosmic Frog that allow users to model and optimize production processes of varying levels of complexity while using the network optimization engine (Neo) include the following input tables:

1. We are in the Input Tables part of the Data section of the Multi-Year Capacity Planning Cosmic Frog model.
2. Click on the square grid to go to input tables if not yet there. Clicking on the round grid icon will open the list of output tables, while clicking on the square grid icon with solid bar at the top will open the list of custom tables.
3. The 4 single-period production focussed input tables are:
   1. Production Policies
   2. Processes
   3. Bills Of Materials
   4. Work Centers
4. There are 3 multi-time period tables that are specific for production:
   1. Production Policies Multi-Time Period
   2. Processes Multi-Time Period
   3. Work Centers Multi-Time Period
5. Of the Constraints tables, the following 3 are production related:
   1. Production Constraints
   2. Production Count Constraints
   3. Work Center Count Constraints

We will cover all these production related input tables to some extent in this article, starting with a short description of each of the basic single-period input tables:

• Production Policies: any product that is in-scope for the modelling and originates within the supply chain needs to have at least 1 production policy set up on the Production Policies table. Products that originate from outside the supply chain can be added by using the Supplier Capabilities and Procurement Policies input tables. The production policies contain the details of which products can be made where. In addition, costs and production rates can optionally be associated through the production policies table. If the manufacturing process of the product requires more detailed modelling, then bills of materials, processes, and/or work centers can also optionally be associated through production policies.
• Bills Of Materials: if raw materials are for example in-scope for modelling, then the Bills of Materials (BOMs) table can be used to specify the “recipes” of how much of each raw material goes into a finished good. Any stage of a product from raw material, component to intermediate, bulk, by-product to finished good can be modelled if deemed in-scope. Examples:
  • Bottling or other packaging plants – BOMs for the ratio of packaging and bulk food/drink product
  • Recipes to manufacture products like cheese from rennet, milk, cultures, and salt or to produce beer from malt, hops, yeast, and water. If multiple different recipes exist for the same product, Cosmic Frog can optimize which recipe is best to use when and where.
• Processes: if details such as costs, production rates, and/or changeover times/costs of a manufacturing process need to be included in the model, this can be achieved by utilizing the Processes table. Each step of a process can also have a Work Center associated with it.
• Work Centers: if detailed costs and capacities of resources like packaging lines, machines, tools, and/or robots need to be taken into account, this can be done by specifying those details in the Work Centers table.

These 4 tables feed into each other as follows:

A couple of notes on how these tables work together:

• If Bills of Materials, Processes and/or Work Centers are specified in the model, they will only be used if they are associated with a Production Policy.
• If both a Process and a Work Center are specified on the same Production Policy, the Work Center on that Production Policy will be ignored. This is regardless of the Process itself having a Work Center associated with it or not.

Basic Production Input Tables

Production Policies

For all products that are explicitly modelled in a Cosmic Frog model, there needs to be at least 1 policy specified on the Production Policies table or the Supplier Capabilities table so there is at least 1 origin location for each. This applies to for example raw materials, intermediates, bulk materials, and finished goods. The only exception is if by-products are being modelled, these can have Production Policies associated with them, but do not necessarily need to (more on this when discussing Bills of Materials further below). From the 2 screenshots below of the Production Policies table, it becomes clear that depending on the type of product and the level of detail that is needed for the production elements of the supply chain, production policies can be set up quite differently: some use only a few of the fields, while others use more/different fields.

1. We are on the Production Policies input table.
2. These 2 records are for 2 of the 3 raw materials: RAW_RENNET and RAW_MILK are specified as the Product Names. A group named ALL_SUP_GROUP, which consists of all 3 suppliers, is specified as the Facility Name on both records. This means that these 2 raw materials can be made at each of the 3 suppliers. The Unit Cost field indicates that the cost of these is €1 each for both raw materials at all 3 suppliers. Had the costs been different at the different suppliers, separate records would have needed to be set up to capture that detail (or a Lookup would have needed to be used to read in costs data from an external source like for example an Excel worksheet).
3. These 3 records are all for the third raw material: RAW_ADDITIVE, as specified as the Product Name. Here the Facility Name field contains the individual names of the suppliers, SUP_1, SUP_2, and SUP_3. These are set up as separate records so the different Unit Costs (€10, €15, and €18 respectively) can be captured correctly.
4. None of these records for the raw materials at the suppliers require more detailed production modelling through BOMs, Processes or Work Centers, and therefore the BOM Name, Process Name, and Work Center Name fields are blank on these records.
5. This record tells us that the OVERFLOW location (Facility Name), can make all products that are part of the ALL_FG_GROUP (Product Name), which contains the 5 finished good cheeses, using a process named PROC-OVERFLOW (Process Name), but at a high cost of €1000 (Unit Cost) for each unit of cheese (Unit Cost UOM = EA).

A couple of notes as follows:

• In this specific model the suppliers have been added to the Facilities table, and therefore the policies for raw materials are specified on the production policies table. Had the suppliers been added to the Suppliers table instead, then the Suppliers Capabilities table would have been used to specify that the raw materials are coming from the supplier locations and at what cost. This is a modelling decision where the main difference between facilities and suppliers is that inventory and certain costs (like fixed operating) can be modelled at facilities, but not at suppliers.
• If a Process is used as part of a production policy (i.e. the Process Name field is used), then the Unit Cost set on this production policy will be ignored, since the record for the specified Process Name in the Processes table overrides the details of the production policy.

Next, we will look at a few other records on the Production Policies input table:

1. We are on the Production Policies input table still, now filtered for the mozzarella bulk material (BULK_MOZ) and finished good (FG_MOZ).
2. This record tells us that the bulk material BULK_MOZ (Product Name) can be made at PLT_1 (Facility Name) using a bill of materials named BOM_BULK_MOZ (BOM Name).
3. These 2 records tell us that the finished good FG_MOZ (Product Name) can be made at PLT_1 (Facility Name) using a bill of materials named BOM_FG_MOZ (BOM Name) and using either a process named PROC-PLT_1_Line-FG_MOZ or a process named PROC-PLT_1_NewLine-FG_MOZ. As the names of the Processes suggest:
   1. The first record uses a process on a currently existing production line that is located at PLT_1 and which is specific for making mozzarella cheese.
   2. The second record uses a process on a production line that currently does not exist but is considered to be added at PLT_1, and will also be specific for mozzarella cheese.

We will take a closer look at the BOMs and Processes specified on these records when discussing the Bills of Materials and Processes tables further below.

Note that the above screenshot was just for PLT_1 and mozzarella, there are similar records in this model for the other 4 cheeses which can also be made at PLT_1, plus similar records for all 5 cheeses at PLT_2, which includes a new potential production line for future expansion too.

Other fields on the Production Policies table that are not shown in the above 2 screenshots are:

• Production Rate with its 2 UOM fields, Rate Quantity UOM & Rate Time UOM: use these fields to specify how long production of this product at this facility takes. For example, setting Production Rate = 5, Rate Quantity UOM = EA (eaches), and Rate Time UOM = HR (hours) means that 5 units are produced per hour, which equates to 12 minutes for 1 unit.
• CO2 Emission Rate with its CO2 Emission Rate UOM field: use these fields to specify how much CO2 is emitted when producing this product at this facility. For example, setting CO2 Emission Rate = 0.2 and CO2 Emission Rate UOM = KG means that per unit produced 0.2 kg CO2 is emitted.

Bills of Materials

The recipes of how materials/products of different stages convert into each other are specified on the Bills of Materials (BOMs) table. Here the BOMs for the blue cheese (_BLU) products are shown:

1. We are on the Bills of Materials input table.
2. These 3 records make up 1 bill of materials as they all have the same BOM Name “BOM_BULK_BLU”. The Product Name and Product Type fields tells us that there are 3 different raw materials (RAW_ADDITIVE, RAW_MILK, and RAW_RENNET) that are going into this recipe as Components. The Quantity field indicates how much of each raw material is used: 0.1 units of RAW_ADDITIVE, 5 units of RAW_MILK, and 0.01 units of RAW_RENNET.
3. This record has BOM Name set to “BOM_FG_BLU” which suggests it is the BOM to make the finished good blue cheese. There is only 1 Component (Product Type) that is the ingredient into this BOM, which is BULK_BLU (Product Name). 1 unit (Quantity) of it is used for the BOM.

Note that the above specified BOMs are both location and end-product agnostic. Their names suggest that they are specific for making the BULK_BLU and FG_BLU products, but only associating these BOMs on a Production Policy which has Product Name set to these makes this connection. We can use these BOMs at any location that they apply. Filtering the Production Policies table for the BULK_BLU and FG_BLU products we can see that 1) BOM_BULK_BLU is indeed used to make BULK_BLU and BOM_FG_BLU to make FG_BLU, and 2) the same BOMs are used at PLT_1 and PLT_2:

It is of course possible that the same product uses a different BOM at a different location. In this case, users can set up multiple BOMs for this product on the BOMs table and associate the correct one at the correct location in the Production Policies table. Choosing a naming convention for the BOM Names that includes the location name (or a code to indicate it) is recommended.

The screenshot above of the Bills of Materials table only shows records with Product Type = Component. Components are input into a BOM and are consumed by it when producing the end-product. Besides Component, Product Type can also be set to End Product or Byproduct. We will explain these 2 product types through the examples in this following screenshot:

1. BOM_BULK_BLU (BOM Name) now has 1 additional record where BYP_WHEY (Product Name) is specified as a Byproduct (Product Type) of the production of BULK_BLU. 2 units (Quantity) of BYP_WHEY are produced as part of the production process of BULK_BLU. To include by-products in a Cosmic Frog model, they not only need to be specified as part of the appropriate BOM(s), but also:
   1. Need to be specified on the Products table.
   2. Need to either have an Inventory Policy with Stocking Site = True at the Facility where the by-product is being produced or need to have Transportation and/or Sourcing Policies (depending on the Lane Creation Rule setting in the Neo run parameters) set up from the location where it is produced to end up at a location where there is an Inventory Policy with Stocking Site = True for it.
2. BOM_FG_BLU (BOM Name) also has 1 additional record where it is specified that FG_BLU (Product Name) is the End Product (Product Type). The Quantity field indicates that 0.1 units of FG_BLU are produced as a result of this BOM. If no End Product is specified in a BOM, by default 1 unit of product is produced when the BOM is used on a Production Policy for that product. Sometimes BOMs are specified in different units though and it may be easier to enter the BOM as is with adding the Quantity for the End Product as in the example here, rather than converting the entire BOM so the quantity of the End Product is 1.

Notes:

• It is possible to set up multiple BOMs with (different quantities of) different components and/or by-products for the same end-product at the same location. The model will then optimize which one(s) to use when. To do so: 1) add all relevant BOMs to the Bills of Materials table, and 2) create multiple Production Policies for the same Facility Name – Product Name combination and use the different BOM Names on them.
• It is possible that products in a model do not only function as components or by-products. For example, there can be situations where they are also used as end products for which there is customer demand in the model, or a by-product is also used as a component into a different BOM.
  • If components are also end-products with customer demand, the model set up for this is straightforward: add the demand to the customer demand table, and add the correct inventory, sourcing and/or transportation policies so the product can reach the customer(s) that have demand for the component.
  • If by-products are also end-products with customer demand, the model set up is somewhat more involved and an example will be discussed in the addendum at the end of this help article.
  • If a product is both used as a component and a by-product on different BOMs, this is no problem, and it can just be set to either Product Type as needed.

Processes

On the Processes table production processes of varying levels of complexity can be set up, from simple 1 step processes without using any work centers, to multi-step ones that specify costs, processing rates, and use different work centers for each step. The processes specified in the Multi-Year Capacity Planning model are relatively straightforward:

1. We are on the Processes input table.
2. Process Name: specify a unique name for the process here. If a process consists of multiple steps, then multiple records (one for each step) will be set up, which all use the same Process Name. A systematic naming convention for processes that takes into account whether processes are product, location, and/or work center specific is recommended. Here, based on the name we can tell that it is a process at the existing production line at PLT_1, which makes FG_SWI (Swiss cheese).
3. Step Name: specify a step name here that is unique within this process (i.e. a Step Name cannot repeat within the same process, but different processes can have the same Step Name as one of their steps). Here, all specified processes have only 1 step, named Production.
4. Step Number: the position of the specified step in the process sequence. As these are all single-step sequences, Step Number is set to 1 for all records.
5. Status: set whether the Process Step should be used (Status = Include) or ignored (Status = Exclude) during an optimization run.
6. Work Center Name: if a work center is used as part of this process step, then associate it here.
7. Unit Cost & Unit Cost UOM: the cost per quantity, volume, or weight of this process. Here set to 0.01 EA, meaning producing 1 unit of product using this process costs 1 eurocent.
8. Here the Notes field is used to indicate which finished good is produced by this process step. This can be used to easily filter the table and set up scenario items that make specific changes based on the finished good.
9. These 2 records are 2 processes to make FG_SWI at the second plant PLT_2, 1 record for production on the existing line and 1 for production on the potential new line.

Let us also look at an example in a different model which contains somewhat more complex processes for a car manufacturer where the production process can roughly be divided into 3 steps:

1. We are again on the Processes input table, although in a different model as compared to the screenshots so far.
2. We see that the Process named SUV1_Detroit_1 has 3 steps associated with it: Welding (step 1), Assembly (step 2), and Painting (step 3)
3. Each step uses a different work center specific to that step, and each step also has a different Processing Rate. For example, the Welding step (step 1) utilizes the Detroit_Welding_1 work center, which can process 60 cars (EA = eaches) per day. This means 24 minutes per car. The rate limiting step on this process is the Assembly step with 36 cars per day (= 40 minutes per car).
4. There is another process specified for producing SUV1 at the Detroit plant, SUV1_Detroit_2, in the bottom 3 records of the screenshot. All 3 records are the same as for the SUV1_Detroit_1 process, except that the Assembly step (step 2) is done on a different work center, Detroit_Assembly_2. In this example, this work center is considered to be added to the Detroit Plant as demand increases and the assembly step is the rate limiting one.

Note that, like BOMs, Processes can in theory be both location and end-product agnostic. However:

• Often the process name suggests that it is specific for making a certain product at a certain location, but only associating these Processes on a Production Policy which has the specific Facility and Product Names makes these connections.
• Processes that use work centers need to be associated on production policies which have the same facility name as the work center of that process. For example:
  • A Work Center named PLT1_Line1 is located at PLT_1 (per the Facility Name field on the Work Centers table which will be discussed in the next section)
  • This Work Center PLT1_Line1 is specified as the Work Center used by a Process named PLT1_Line1_Stamping.
  • If this PLT1_Line1_Stamping process is associated with a Production Policy where the Facility Name is not PLT_1, this production policy will be ignored.

Other fields on the Processes table that are not shown in the above 2 screenshots are:

• Fixed Time with its Fixed Time UOM field: use these to incorporate changeover times into processes. In each period of the model’s horizon where the process step is used, this fixed time will be applied once.
• Fixed Cost: use this to incorporate changeover costs into processes. In each period of the model’s horizon where the process step is used, this fixed cost will be applied once.

Work Centers

If it is important to capture costs and/or capacities of equipment like production lines, tools, machines that are used in the production process, these can be modelled by using work centers to represent the equipment:

1. We are on the Work Centers input table.
2. Each Work Center that is being modelled needs to have a unique Work Center Name, and the facility where it is located needs to be specified in the Facility Name field. If a Facility group is used in the Facility Name field, then the same Work Center is created at each of the facilities in the group.
3. The Work Center Status can be set to Open, Closed or Consider:
   1. Open means that the work center is part of the network for the duration of the model.
   2. Closed means that the work center will not be used for the duration of the model.
   3. Consider – the behavior depends on what Initial State is set to. If Initial State = Existing, then the Work Center is part of the network at the start of the modelling horizon; it can be closed if it is optimal to do so, in which case Fixed Closing Costs will be applied (if specified). If Initial State = Potential, the Work Center is not yet part of the network at the start of the modelling horizon; it can be opened if it is optimal to do so, in which case Fixed Startup Costs will be applied (if specified).

In the above screenshot, 2 work centers are set up at each plant: 1 existing work center and 1 new potential work center. The new work centers (PLT_1_NewLine and PLT_2_NewLine) have Work Center Status set to Closed, so they will not be considered for inclusion in the network when running the Baseline scenario. In some of the scenarios in the model, the Work Center Status of these 2 lines is changed to Consider and in these scenarios one of the new lines or both can be opened and used if it is optimal to do so. The scenario item that makes this change looks like this:

1. The name of the scenario item “Consider new lines”.
2. The table to be changed is selected from the Table Name drop-down, here the Work Centers table is selected.
3. In the Actions box, the change that needs to be made to the selected table is specified. Here the Work Center Status is set to Consider.
4. In the Conditions section we can indicate if the Actions need to be applied to a subset of the records in the selected Table Name by setting a condition. Here it was done by using the Condition Builder: the Actions will only be applied to records that have Initial State set to Potential.

Next, we will also look at a few other fields on the Work Centers table that the Multi-Year Capacity Planning model utilizes:

1. We are still on the Work Centers input table, now showing the Work Center Name frozen on the left and several other fields that were not visible in the screenshot further above.
2. We are focusing on the 2 lines at PLT_1 here, the existing one (PLT_1_Line) and the new potential one (PLT_1_NewLine).
3. Both the existing and new line have their Throughput Capacity set to 90,000 units. Since the model has 5 yearly periods, this means that in each year, each production line can at a maximum produce 90,000 units of product (this is across all products that these lines can produce). They also both have the same Fixed Operating Cost of €20,000, which is applied once for every year the line is used.
4. The potential new line also has a Fixed Startup Cost of €50,000 associated with it. If the model determines it is optimal to start using the new line, this cost will be applied once in the year when the line is first being used.

In theory, it can be optimal for a model to open a considered potential work center in one period of the model (say 2024 in this model), close it again in a later period (e.g. 2025), for it then to open it again later (e.g. 2026), etc. In this case Fixed Startup or Fixed Closing Costs would be applied each time the work center was opened or closed, respectively. This type of behavior can be undesirable and is by default prevented by a Neo Run Parameter called “Open Close At Most Once”, as shown in this screenshot:

After clicking on the Run button, the Run screen comes up. The “Open Close At Most Once” parameter can be found in the Neo (Optimization) Parameters section. By default, it is turned on, meaning that a work center or facility is only allowed to change state once during the model’s horizon, i.e. once from closed to open if the Initial State = Potential or once from open to closed if the Initial State = Existing. There may however be situations where opening and/or closing of work centers and facilities multiple times during the model horizon is allowable. In that case, the Open Close At Most Once parameter can be turned off.

Other fields on the Work Centers table that are not shown in the above screenshots are:

• Fixed Closing Cost: if a Work Center with Work Center Status = Consider and Initial State = Existing is closed during the model horizon, this cost is applied in the period(s) where it is closed.
• Minimum Throughput with its Minimum Throughput UOM field: the minimum amount of product or time the work center needs to produce / be used during each period of the model’s horizon. For example, if this is set to 80 DAY in a model with 5 yearly periods, it means that the work center needs to be used at least 80 full days (e.g. 80*24 = 1,920 hours) during each of those 5 years.

Fixed Operating, Fixed Startup, and Fixed Closing Costs can be stepped costs. These can be entered into the fields on the Work Centers input table directly or can be specified on the Step Costs input table and then used on the Work Centers table in those cost fields. An example of stepped costs set up in the Step Costs input table is shown in the screenshot below where the costs are set up to capture the weekly shift cost for 1 person (note that these stepped costs are not in the Multi-Year Capacity Planning model in the Resource Library, they are shown here as an additional example):

• The first shift of 8 hours every day of the week costs €15 per hour, so total cost for those 7*8 = 56 hours is €15*56 = €840.
• A second 8-hour shift can be added on weekdays for a cost of €25 per hour, so total cost for those 5*8 = 40 hours is €25*40 = €1,000, making the total costs of the 2 shifts together €840 + €1,000 = €1,840.
• This makes the maximum weekly capacity of the work center 56 + 40 hours, which can be set as the Throughput Capacity on the Work Centers table (Throughput Capacity = 96, Throughput Capacity UOM = HR).

1. We are on the Step Costs input table.
2. The multiple steps of a cost function need to have the same Step Cost Name, here the stepped cost function consists of 2 steps and it is called WC_Shifts. The Step Cost Behavior can be Stepwise, as is applicable here (e.g. from a certain lower throughput level to a certain higher throughput level the cost stays the same) or it can be either Incremental or All Item where unit costs change based on the level of throughput with either incremental discounts (only applied to units over the throughput level) or all item discounts (discounts applied to all units once a certain threshold throughput level is reached).
3. The first step of the step cost function is set to start from 0 throughput (Throughput Level) as measured in hours (Throughput Level UOM) and costs €840 (as calculated above, the cost of the first shift of 8 hours/day every day of the week). The second step of the step cost function starts from 56 hours and the total cost between 56 and 96 hours (the maximum throughput capacity) is €1,840 (also calculated above).

To set for example the Fixed Operating Cost to use this stepped cost, type “WC_Shifts” into the Fixed Operating Cost field on the Work Centers input table.

Multi-time Period Production Input Tables

Many of the input tables in Cosmic Frog have a Multi-Time Period equivalent, which can be used in models that have more than 1 period. These tables enable users to make changes that only apply to specific periods of the model. For example, to:

• Increase costs & prices over time.
• Increase capacities for planned expansions that are coming online.
• Decrease capacities for planned downtime/closures.
• Use different BOMs during different periods of the modelling horizon.

The multi-time period tables are copies of their single-period equivalents, with a few columns added and removed (we will see examples of these in screenshots further below):

1. A Period Name field is added to indicate in which period of the model the change as compared to the single-period table should be applied: the record in the multi-time period table for the specified period(s) essentially overrides the matching record in the single-period table. If a model has 5 periods and a multi-time period input table contains a record for period 4 and none for periods 1-3 and 5, then the single-time period input table is used for periods 1-3 and 5 and the record from the multi-time period input table for period 4.
2. Additional Status fields (e.g. Work Center Status or Process Step Status) to indicate whether or not the policy exists in the specified period. For example, say there is a policy in the Work Centers single-time period input table for Line1_Detroit with Status = Include. This work center has planned downtime in the 3^rd period of the model, so a record for this work center is added to the Work Centers multi-time period input table where Period Name is set to the name of the 3^rd period and the Work Center Status is set to Exclude. This way the work center is included in all periods of the model, except the 3^rd.
3. A few columns that cannot be changed on a period-by-period basis have been removed from the multi-time period input tables as compared to their single-period equivalents. Examples of these include the latitude and longitude fields on the Customers, Facilities, and Suppliers input tables.

Notes on switching status of records through the multi-period tables and updating records partially:

• It is important to note that changing the status of a record in a single-period table for specific periods using the multi-period table only works properly if all the key fields of the 2 tables are set to the same values. Records on the multi-period table which do not have records that have the same values for the key fields on the single-period table will be ignored. Key fields are easily recognized in the Cosmic Frog tables, as they have a key icon in front of the column name and the column name is in bold font. The Work Centers table has 2 key fields for example: Work Center Name and Facility Name, which is pointed out in the next screenshot. From the screenshot it is also clear that Status and Work Center Status are not key fields:
  • 
• When updating values of non-key fields for specific periods through a multi-time period table, it is again important that the records on the single- and multi-period table have the same values for the key fields. However, for the non-key fields that are being updated, only those fields that need to be changed during specific periods need to be populated with the changed numbers on the multi-period table. For non-key fields that have a value in the single-period table and are left blank on the multi-period, the value from the single-period table will be used.

Three of the 4 production specific input tables that have been discussed above have a multi-time period equivalent: Production Policies, Processes, and Work Centers. There is no equivalent for the Bills Of Materials input table, as BOMs are only used if they are associated on records in the Production Policies table. Using different BOMs during different periods can be achieved by associating those BOMs on the Production Policies single-period table and setting the Status of them to Include for those to be used for most of the periods and to Exclude if they are to be included for certain periods / scenarios. Then add those records for which the Status needs to be switched to the Production Policies multi-period input table (we will walk through an example of this using screenshots in the next section).

The 3 production specific multi-time period input tables do have all of the same fields as their single-period equivalents, with the addition of the Period Name field and additional Status field. We will not discuss each multi-time period table and all its fields in detail here, but rather give a few examples of how each can be used.

Note that from this point onwards the Multi-Year Capacity Planning model was modified and added to for purposes of this help article, the version in the Resource Library does not contain the same data in the Multi-Time Period input tables and production specific Constraint tables that is shown in the screenshots below.

Production Policies Multi-Time Period

This first example on the Production Policies Multi-Time Period input table shows how the production of the cheddar finished good (FG_CHE) is prevented at plant 1 (PLT_1) in years 4 and 5 of the model:

1. We are on the Production Policies Multi-Time Period input table
2. Four records are set up and these are all for the cheddar finished good (FG_CHE) at PLT_1 – note that the values of the key fields of these (Facility Name, Product Name, BOM Name, and Process Name) match those of records on the Production Policies single-period input table.
3. The first 2 records are for the period named YEAR4 and the last 2 for the period named YEAR5.
4. The BOM Name field is set to the BOM that makes the cheddar finished good (BOM_FG_CHE) and the Process Name field indicates the 2 process options for FG_CHE at PLT_1: the process for FG_CHE on the existing line and the process for FG_CHE on the potential new line.
5. The Status field reflects if this record of the Production Policies Multi-Time Period model is to be used (included) or ignored (excluded) when the model is run. These 4 records are all set to include, so they will be used when the model is optimized.
6. The Policy Status field indicates if the policy that has been set up here and exists in the Production Policies Single-Period table should be included or excluded during the specified Period Name. Here, all 4 are set to Exclude, meaning that together these 4 records ensure that no FG_CHE can be made at PLT_1 during periods YEAR4 and YEAR5.

In the following example, an alternative BOM to make feta (FG_FET) is added and set to be used at Plant 2 (PLT_2) during all periods instead of the original BOM. This is set up to be used in a scenario, so the original records need to be kept intact for the Baseline and other scenarios. To set this up, we need to update the Bills Of Materials, Production Policies, and Production Policies Multi-Time Period table, see the following screenshots and explanations:

On the Bills Of Materials input table, all we need to do is add the records for the new BOM that results in FG_FET. It has 2 records, both named ALTBOM_FG_FET, and instead of using only BULK_FET as the component which is what the original BOM uses, it uses a mix of BULK_FET and BULK_BLU as its components.

Next, we first need to associate this new BOM through the Production Policies table:

1. Two new records at PLT_2 to make FG_FET using the new BOM (ALTBOM_FG_FET) are added to the Production Policies table. We need 2 records so that the new BOM can be used on both the existing production line and the new potential production line at PLT_2 (see the Process Name field).
2. The Status of these 2 new records is set to Exclude, so when the Baseline or any already existing scenarios are run, these are not included.

Lastly, the records that need to be added to the Production Policies Multi-Time Period table are the following 4 which have all the same values for the key columns as the 4 records in the above screenshot of the Production Policies single-period input table, which contain all the possible ways to produce FG_FET at PLT_2:

1. We are on the Production Policies Multi-Time Period input table.
2. As mentioned, this is for making FG_FET (Product Name) at PLT_2 (Facility Name).
3. In this case, we want to change to using the alternative BOM for FG_FET at PLT_2 during the whole modelling horizon, so for Period Name a period group named ALL_PERIODS is used. This group contains all 5 periods that exist in this model (see Groups input table).
4. There are 2 records for each of the 2 possible processes to make Feta at Plant 2, the top 2 records are for the existing production line.
5. The BOM Name of the first record is set to BOM_FG_FET which is the original BOM that we do not want to use anymore. The second record has the BOM Name set to the new BOM ALTBOM_FG_FET which we do want to use for the specific scenario we are creating.
6. To make this change from the original BOM to the alternative BOM, the Policy Status of the first record will be set to Exclude and that of the second record will be set to Include.
7. The Status of these records in this multi-time period table is set to Exclude, meaning that if we run any other scenarios, these records will be ignored and the original BOM (BOM_FG_FET) for FG_FET at PLT_2 will be used. This Status field is changed to Include through a scenario item in the scenario(s) where this change from original to alternative BOM for FG_FET needs to be made (see next screenshot).
8. The bottom 2 records are for the new potential production line at PLT_2 and make the same change from original BOM to alternative BOM by switching the Policy Status fields. These records again also have their Status set to Exclude, which is swapped to Include through a scenario item for the scenario(s) in which the new BOM needs to be used:

1. This scenario item is named “Alternative_Feta_BOM”.
2. The table that is being changed is the Production Policies Multi-Time Period table.
3. The change that is made is to set the value of the Status field to Inlcude.
4. The records that this change is made on are those where the Product Name is equal to FG_FET.

Processes Multi-Time Period

In the following example, we want to change the unit cost on 2 of the processes: at Plant 1 (PLT_1), the cost on the new potential line needs to be decreased to 0.005 for cheddar cheese (CHE) and increased to 0.015 for Swiss cheese (SWI). This can be done by using the Processes Multi-Time Period input table:

1. These records are for the processes that make cheddar and Swiss cheese on the new potential line at PLT_1. The Process Name and Step Name fields are the key fields on this table, and their values match those of records on the Processes single-period table.
2. We only want to change the costs of these processes, which we do by setting the Unit Cost field to 0.005 for CHE and 0.015 for SWI.
3. These changes need to be applied to all 5 periods of the model so the period group ALL_PERIODS is used as the Period Name.
4. By setting the Status of these 2 records to Include, these changes will be made to all scenarios, including the Baseline.

Note that there is also a Work Center Name field on the Processes Multi-Time Period table (not shown in the screenshot). As this is not a key field on the Processes input tables, it can be left blank here on the multi-time period table. This field will not be changed and the value from the single-time period table Work Center Name field will be used for these 2 records.

Work Centers Multi-Time Period

In the following example, we want to evaluate if upgrading the existing production lines at both plants from the 3^rd year of the modelling horizon onwards, so they have a higher throughput capacity at a somewhat higher fixed operating cost, is a good alternative to opening one of the potential new lines at either plant. First, we add a new periods group to the model to set this up:

On the Groups table, we set up a new group named YEARS3-5 (Group Name) that is of Group Type = Periods and has 3 members: YEAR3, YEAR4 and YEAR5 (Member Name).

1. We are on the Work Centers Multi-Time Period input table.
2. The first record is for the Work Center called PLT_1_Line (Work Center Name) at PLT_1 (Facility Name). The new group for years 3-5 of this 5 year model is used as the Period Name to make this change for just those 3 years.
3. The changes that are being made are to set the Throughput Capacity to 110,000 (from 90,000) and the Fixed Operating Cost to €22,000 (from €20,000). Note that the Throughput Capacity UOM field is not set on this table (left blank, not shown in screenshot), meaning that the UOM set in the single-period table (EA for eaches) still applies.
4. The Status of this record is set to Exclude, it is switched to Include through a scenario item in the scenario(s) that we want to include these changes in while leaving the other scenario(s) and Baseline as they are.
5. The second record is set up in the same way, except it is for the existing line PLT_2_Line at plant PLT_2.

Constraint Input Tables related to Production

Cosmic Frog contains multiple tables through which different types of constraints can be added to network optimization (Neo) models. A constraint limits the model in a certain part of the network. These limits can for example be lower or upper limits in terms of the amount of flow between certain locations or certain echelons, the amount of inventory of a certain product or product group at a specific location or network wide, the amount of production of a certain product or product group at a specific location or network wide, etc. In this section the 3 constraints tables that are production specific will be covered: Production Constraints, Production Count Constraints, and Work Center Count Constraints.

A couple of general notes on all constraints tables:

1. The fields which specify facilities, products, periods, BOMs, work centers, processes, etc. (the “… Name” fields) almost all allow the use of groups. If a group is used, a “… Group Behavior” field (e.g. “Facility Name Group Behavior, Period Name Group Behavior, etc.) that is placed to the right of the name field is used to indicate how to interpret the constraint for this group. If the Group Behavior field is set to Enumerate (the default for all Group Behavior fields), the constraint applies to each member of the group individually; if the Group Behavior field is set to Aggregate, the constraint applies to all members of the group together. In the below explanations of the production related constraint input tables, not all individual Group Behavior fields are discussed, since they all work this same way.
2. These same Name fields (Facility Name, Product Name, Period Name, etc.) can all generally be left blank, in which case the default of ALL will be used, e.g. meaning all included Facilities in the model, all included Products in the model, etc.

Production Constraints

In this example, we want to add constraints to the model that limit the production of all 5 finished goods together to 90,000 units. Both plants have this same upper production limit across the finished goods, and the limit applies to each year of the modelling horizon (5 yearly periods).

1. We are on the Production Constraints input table.
2. The first record is set up for PLT_1 (Facility Name), one of the 2 plants in the model.
3. The ALL_FG_GROUP product group which consists of the 5 cheese finished goods is used for the Product Name. As the Product Name Group Behavior field is set to Aggregate, the constraint that is specified here is applied over these 5 finished goods together.
4. The ALL_PERIODS period group which consists of the 5 yearly periods that the model contains is used for the Period Name. Since the Period Name Group Behavior field is set to Enumerate the constraint applies to each individual period.
5. The Constraint Type field is set to Max which indicates that this constraint sets an upper limit (production needs to be less than or equal to the Constraint Value). The upper limit itself is set by the Constraint Value field and its accompanying UOM field: 90,000 eaches. Other options for Constraint Type are:
   1. Min – sets a lower limit, i.e. the production needs to be equal to or greater than the Constraint Value.
   2. Fixed – sets a fixed limit, i.e. the production needs to be equal to the Constraint Value.
   3. Fixed With Tolerance – sets a fixed limit with some leeway in either direction: the production needs to be equal to the Constraint Value * (1 +/- Relative Constraint Tolerance), where Relative Constraint Tolerance is set as a percentage in the Neo (Optimization) Parameters section on the Run screen, with a default value of 0.02.
   4. Conditional Min – production needs to be either 0 or equal to or greater than the Constraint Value

Note that there are more fields on the Production Constraints input table which are not shown in the above screenshot. These are:

• BOM Name and its Group Behavior field: if the constraint should apply to a BOM or group of BOMs specifically, use these fields to indicate to which BOM(s) and, if applicable, what the group behavior should be.
• Process Name and its Group Behavior field: if the constraint should apply to a Process or group of Processes specifically, use these fields to indicate to which Process(es) and, if applicable, what the group behavior should be.

Production Count Constraints

In this example, we want to limit the number of products that are produced at PLT_1 to a maximum of 3 (out of the 5 finished goods). This limit applies over the whole 5-year modelling period, meaning that in total PLT_1 can produce no more than 3 finished goods:

1. We are on the Production Count Constraints input table.
2. This constraint applies to PLT_1 (Facility Name).
3. The Product Name field uses the ALL_FG_GROUP product group, which consists of the 5 finished good cheeses. Since the Group Behavior field is set to Aggregate, the constraint applies to all finished good cheeses together.
4. The Period Name field uses the ALL_PERIODS period group, which consists of the 5 yearly periods. Since the Group Behavior field is set to Aggregate, the constraint applies to all periods together (i.e. to the whole modelling horizon).
5. The Max value for Constraint Type, the Constraint Value of 3, and the Counting Rule being set to Products together specify that a maximum of 3 products is allowed to be produced. Possible entities to count on for the Counting Rule are: Facilities, Products, BOMs, Processes, and Periods. Here, since the Counting Rule is set to Products, it means “count the number of unique products for which production occurs for the specified facility-BOM-Process-Period combination”. If it were set to Period it would mean “count the number of unique periods for which production occurs for the specified facility-product-BOM-Process combination”, etc.

Again, note there are more fields on the Production Count Constraints input table which are not shown in the above screenshot. These are:

• BOM Name and its Group Behavior field: if the constraint should apply to a BOM or group of BOMs specifically, use these fields to indicate to which BOM(s) and, if applicable, what the group behavior should be.
• Process Name and its Group Behavior field: if the constraint should apply to a Process or group of Processes specifically, use these fields to indicate to which Process(es) and, if applicable, what the group behavior should be.

Work Center Count Constraints

Next, we will show an example of how to open at least 3 work centers, but no more than 5 out of 8 candidate work centers. These limits apply to all 5 yearly periods in the model together and over all facilities present in the model.

1. We are on the Work Center Count Constraints input table.
2. The Work Center Name is set to a group of work centers which contains 8 new potential Work Centers (these Work Centers all need to have Status = Consider and Initial State = Potential on the Work Centers table). As the Group Behavior is set to Aggregate, the constraint applies to all 8 work centers together.
3. The constraint applies to all 5 yearly periods in the model together.
4. The first record sets the lower limit by using Constraint Type = Min. As the Constraint Value = 3 and Counting Rule = Work Centers, this means at least 3 Work Centers need to be opened and used during the modelling horizon. Other options for Counting Rule are Facilities and Periods.
5. The second record has the same values except that is sets the number of work centers to be opened and used to Max = 5: an upper limit of 5 out of the 8 candidate work centers.

Again, there are more fields on the Work Center Count Constraints table that are not shown in the above screenshot:

• Facility Name and its Group Behavior field: if the constraint should apply to a facility or group of facilities specifically, use these fields to indicate to which facility(/facilities) and, if applicable, what the group behavior should be.

Production Output Tables

After running a network optimization using Cosmic Frog’s Neo technology, production specific outputs can be found in several of the more general output tables, like the Optimization Network Summary, and the Optimization Constraints Summary (if any constraints were applied). Outputs more focused on just production can be found in 4 production specific output tables: the Optimization Production Summary, the Optimization Bills Of Material Summary, the Optimization Process Summary, and the Optimization Work Center Summary. We will cover these tables here, starting with the Optimization Network Summary.

Optimization Network Summary

The following screenshot shows the production specific outputs that are contained in the Optimization Network Summary output table:

1. We are on the Optimization Network Summary output table.
2. As all output tables, the first field on the Optimization Network Summary output table is the Scenario Name field, indicating for which scenario the outputs of the record are.
3. This subset of the costs fields on this output table are partially or entirely the result of production:
   1. Total Production Cost: the total production costs of this scenario as resulting from the Unit Cost set on the Production Policies input table.
   2. Total Fixed Operating Cost: this is the total of fixed operating costs for facilities and work centers. The inputs for these are specified on the Facilities and Work Centers input tables.
   3. Total Fixed Startup Cost: this is the total of fixed startup costs for facilities and work centers. The inputs for these are specified on the Facilities and Work Centers input tables.
   4. Total Fixed Closing Cost: this is the total of fixed closing costs for facilities and work centers. The inputs for these are specified on the Facilities and Work Centers input tables.
   5. Total Process Cost: this is the total of the variable and fixed costs associated with processes, resulting from the Unit Cost and Fixed Cost fields on the Processes input table.

Other production related fields on this table which are not shown in the screenshot above are:

• Total CO2 Emissions: this is the total of all CO2 emissions in the scenario. This includes for example facility and transportation related CO2 emissions. The production related CO2 emissions that are part of this total are the result of the CO2 Emission Rate field on the Production Policies input table.
• Total CO2 Cost: the total cost associated with the Total CO2 Emissions in this scenario. Costs are calculated based on the CO2 Cost field in the Model Settings input table.

Optimization Production Summary

The Optimization Production Summary output table has a record with the production details for each product that was produced as part of the model run:

1. We are on the Optimization Production Summary output table.
2. The first several columns indicate the Scenario Name, the Starting Period Name of the production, the Completion Period Name of the production (not shown in screenshot), the Facility Name where the production takes place and the Product Name of the product being produced.
3. If a BOM was used for the production, the BOM Name will be populated. If it contains the word “none” it means no BOM was used for the production.
4. If a Process was used for the production, the Process Name will be populated. If it contains the word “none” it means no Process was used for the production.
5. The Production Quantity field and its UOM field (not shown in screenshot) indicate the amount of this product produced at this facility in this scenario, during these Starting and Completion periods, using specified BOM (if any) and Process (if any).
6. The costs associated with the production are listed in the next 2 fields: Production Cost is the result of the Unit Cost field on the Production Policies input table, and Process Cost is the result of the Unit Cost and Fixed Cost fields on the Processes input table.

Other fields on this output table which are not shown in the screenshot are:

• Production Volume, Production Weight, and Production Time, together with their UOM fields to summarize the production amount in several units of measure.
• CO2 Emissions and CO2 Cost: the CO2 Emissions are the result of the CO2 Emission Rate set on the Production Policies input table; the CO2 Cost results from the emissions multiplied by the CO2 Cost set on the Model Settings input table.
• Latitude and Longitude: the coordinates of the facility at which the production occurs.

Optimization Bills Of Material Summary

The details of how many components were used and how much by-product produced as a result of any bills of materials that were used as part of the production process can be found on the Optimization Bills Of Material Summary output table:

1. We are on the Optimization Bills Of Material Summary output table, filtered to look at BOMs for Feta cheese in period YEAR3 in the Sc2_Consider_New_LINES scenario.
2. The first few fields indicate the name of the scenario (Scenario Name = Sc2_Consider_New_LINES) in which this BOM was used, the name of the period the BOM was used (Period Name = YEAR3), the name of the BOM (BOM Name) used – here BOM_BULK_FET which is used to make the bulk material BULK_FET, and the name of the facility at which the BOM was used (Facility Name = PLT_1). For these 3 records, these are all the same.
3. The next 3 fields indicate the names of the products used as part of this BOM_BULK_FET BOM, here those of the 3 raw materials, which are used as Components (Product Type) in this BOM. How much of each component is used is listed in the BOM Quantity field. The other value for Product Type can be Byproduct if any are specified for a BOM on the Bills of Materials input table.
4. This record uses the BOM_FG_FET at PLT_1 in the same scenario and period as the first 3 records. The component here is BULK_FET and 24,102 units of it are used.

Note that aside from possibly knowing based on the BOM Name, it is not listed in the Bills Of Material Summary output table what the end product is and how much of it is produced as a result of a BOM. Those details are contained in the Optimization Production Summary output table discussed above.

Other fields on this output table which are not shown in the screenshot are:

• BOM Volume, and BOM Weight, together with their UOM fields to summarize the production amount in several units of measure.
• Latitude and Longitude: the coordinates of the facility at which the BOM was used for production.

Optimization Process Summary

The details of all the steps of any processes used as part of the production in the Neo network optimization run can be found in the Optimization Process Summary, see these next 2 screenshots:

1. We are on the Optimization Process Summary output table.
2. The table is filtered to look at the production of FG_CHE (Product Name), in period YEAR5 (Period Name) of the Sc2_Consider_New_LINES scenario (Scenario Name).
3. The first record is for production at PLT_1 (Facility Name), using a process named PROC-PLT_1_Line_FG_CHE which tells us that the existing line at PLT_1 was used.
4. The second and third record are for production of FG_CHE at PLT_2 (Facility Name), using 2 different processes: 1 that uses the existing line at PLT_2 and 1 that uses the new potential line at PLT_2.

1. The Current Step Name and Next Step Name fields are also part of the outputs on this table. In this case they are straightforward as all Processes in this model consist of 1 single step that is named “Production”. If the current step is the last step, then the next step is indicated as “end” like we see in this example.
2. If a work center was used for the process step, it is listed in the Work Center Name field.
3. The quantity of this product made using this process at this facility during this period in this scenario and using the specified work center is listed in the Processed Quantity field, while the associated costs can be found in the Process Unit Cost field. These costs are a result of the Unit Cost field on the Processes input table.

Other fields on this output table which are not shown in the screenshots are:

• Process Type: to be used in future when processes can also be associated to other parts of the network.
• Processed Volume, Processed Weight, and Processed Time, together with their UOM fields to summarize the production amount in several units of measure. The Processed Time is the result of the Processing Rate and Fixed Time fields on the Processes input table.
• Process Fixed Cost: the changeover cost of the process step, resulting from the Fixed Cost field on the Processes input table.
• Latitude and Longitude: the coordinates of the facility at which the process was used.

Optimization Work Center Summary

For each Work Center that has its Status set to Include or Consider, a record for each period of the model can be found in the Optimization Work Center Summary output table. It summarizes if the Work Center was used during that period, and, if so, how much and at what cost:

1. We are on the Optimization Work Center Summary output table.
2. The table is filtered for the scenario called “Sc2_Consider_New_LINES” (Scenario Name) and the new potential line at PLT_2 (Facility Name) named “PLT_2_NewLine” (Work Center Name). The Initial State of Potential is repeated from the Work Centers input table.
3. There are 5 records for this work center, 1 for each yearly period in the model.
4. These fields summarize the Initial Status at the start of the period, the Optimized Status at the end of the period, and the amount of throughput in eaches (Throughput Quantity). This Work Center PLT_2_NewLine was Closed at the beginning of period 1 as its Work Center Status = Consider and Initial State = Potential on the Work Centers input table. We see that at the end of the third period (“YEAR3”), the Optimized Status has changed to Open: the work center has started being used in this period, with a throughput of 21,293 units. It stays open and is used in periods 4 and 5 too.

The following screenshot shows a few more output fields on the Optimization Work Center Summary output tables that have non-0 values in this model:

1. The Total Work Center Cost field is the sum of all costs associated with this work center for this period. It is the sum of any Operating Costs, Startup Costs, Closing Costs, and Process Costs.
2. The Operating Costs are the result of the Fixed Operating Cost inputs on the Work Centers input table. If this is a stepped cost, the work center throughput is used to determine which step of the stepped function to use as the cost.
3. The Startup Costs are the result of the Fixed Startup Cost inputs on the Work Centers input table. If this is a stepped cost, the step to use as the cost is determined based on the largest throughput recorded in any of the periods the work center is used after it was initially opened.
4. The Total Process Costs are the result of the Unit Cost and Fixed Cost inputs specified on the Processes input table. If any Process Steps use the specified work center in the specified period, all Unit and Fixed Costs for those steps are summed together and reported here.

Other fields on this output table which are not shown in the screenshots are:

• Closing Cost, which are the result of the Fixed Closing Cost inputs on the Work Centers input table. If this is a stepped cost, the step to use as the cost is determined based on the largest throughput recorded in any of the periods the work center was used before it closed.
• Throughput Volume, Throughput Weight, and Throughput Time, together with their UOM fields to summarize the work center throughput in several units of measure. The Throughput Time is the result of the Processing Rate and Fixed Time fields on the Processes input table if the Work Center is associated on any Processes. If the Work Center is directly associated with a Production Policy, then the Throughput Time is the result of the Production Rate set on the Production Policies input table.
• Throughput Capacity and its UOM field: this repeats the inputs on the Work Centers input table of what the maximum throughput of this Work Center is during this period.
• Throughput Utilization: if a throughput capacity is set, the utilization is calculated as throughput / throughput capacity.

Optimization Constraint Summary

For all constraints in the model, the Optimization Constraint Summary can be a very handy table to check if any constraints are close to their maximum (or minimum, etc.) value to understand where the current and future bottlenecks are and likely will be. The screenshot below shows the outputs on this table for a production constraint that is applied at each of the 3 suppliers, where neither can produce more than 1 million units of RAW_MILK in any 1 year. In the screenshot we specifically look at the Supplier named SUP_3:

1. We are on the Optimization Constraint Summary output table.
2. In this scenario, we are looking at 1 constraint, the name of which is auto generated based on the values of the constraint in the Production Constraints input table. This name is repeated for all 5 records (1 for each yearly period).
3. These fields indicate we are looking at periods YEAR1 – YEAR5 (Period Name) for SUP_3 (Facility Name) and RAW_MILK (Product Name).
4. The Constraint Type and Constraint Value are repeated here, which are set to Max = 1,000,000, i.e. SUP_3 cannot produce more than 1 million units of RAW_MILK in any of the periods of the model. The Constraint Activity field indicates how much RAW_MILK SUP_3 actually produced in each period of the optimization run: in YEAR1-YEAR3 the activity increased from ~850K to ~956K and in YEAR 4 and YEAR5 the activity reached the 1million units limit.

Other fields on this output table which are not shown in the screenshots are:

• Destination Name: the destination of a flow in case of a flow (count) constraint).
• Origin Name: the origin of a flow in case of a flow (count) constraint.
• Mode Name: the mode of a flow in case of a flow (count) constraint.
• Process Name: the process name in case of a production (count) constraint.
• BOM Name: the BOM name in case of a production (count) constraint.
• Work Center Name: the work center name in case of a work center count constraint.
• Slack Percentage: shows how close the constraint is to being binding (e.g. maxing out in case of Type = Max, etc.).
• Constraint Violation: if a model is infeasible and this constraint needed to be relaxed to make it feasible, this field indicates by how much it had to be relaxed.
• Suggested Constraint Value: if the model is infeasible and this constraint needed to be relaxed to make it feasible, this suggested constraint value contains the value the original constraint should be set to in order to make the model feasible.

Other output tables that contain some production related outputs

There are a few other output tables of which the main outputs are not related to production, but still contain several fields that result from productions. These are:

1. Optimization Cost To Serve Summary: the Per Unit Production Cost, Per Unit Process Cost, Per Unit Work Center Fixed Operating Cost, Per Unit Work Center Fixed Startup Cost, Per Unit Work Center Fixed Closing Cost, and Per Unit CO2 Cost outputs are all (partially) the result of production activities in the model.
2. Optimization Facility Summary: the Total Production Cost, Total Process Cost; Total Production Quantity, Total Production Volume, and Total Production Weight, and their UOM fields; Total Production CO2 Emissions, and Total Production CO2 Cost outputs are all the result of production activities in the model.
3. Optimization Facility Cost To Serve Summary: the Per Unit Production Cost, Per Unit Process Cost, Per Unit Work Center Fixed Operating Cost, Per Unit Work Center Fixed Startup Cost, Per Unit Work Center Fixed Closing Cost, and Per Unit CO2 Cost outputs are all (partially) the result of production activities in the model.
4. Optimization CO2 Emissions Summary: the Total CO2 Emissions, Total CO2 Cost, Total Fixed CO2 Emissions, Fixed CO2 Cost, Total Production CO2 Emissions, and Total Production CO2 Cost are all (partially) the result of production activities in the model.

Addendum – Additional Example Use Case Setups

Use Facility Count Constraints to Consider Entire New Plants

In this help article we have covered how to set up alternative Work Centers at existing locations and use the Work Center Status and Initial State fields to evaluate if including these, and from what period onwards if so, will be optimal. We have also covered how Work Center Count Constraints can be used to pick a certain amount of Work Centers to be opened/used from a set of multiple candidates, either at 1 location or multiple. Here we also want to mention that Facility Count Constraints can be used when making decisions at the plant level. Say that based on market growth in a certain region, a manufacturer decides a new plant needs to be built. There are 3 candidate locations for the plant from which the optimal needs to be picked. This can be set up as follows in Cosmic Frog:

• Add the 3 potential plants to the Facilities table:
  • Facility Status = Consider
  • Initial State = Potential
• Set up all the required Production Policies, Processes, Work Centers, and BOMs needed for each potential new plant
  • Note that the Status of all these can be set to Include, they will only be used if the model finds it optimal to start using the new plant these are located at
• Set up the required inventory policies at the potential new plants and the sourcing and transportation policies going into and out of them. Again, the Status of all these can be set to Include. Think for example of the following policies which may need to be added:
  • Inventory policies for raw materials, finished goods, intermediates, and by-products
  • Procurement policies and corresponding transportation policies into the plant for acquiring raw materials
  • Replenishment policies and corresponding transportation policies out of the plant to DCs
• Create a group for the 3 new potential plants in the Groups table, Group Type = Facilities
• Set up a Facility Count Constraint for this group of new potential plants, with most likely following values for certain fields:
  • Facility Name Group Behavior: Aggregate
  • Period Name: group of all periods in the model
  • Period Name Group Behavior: Aggregate
  • Constraint Type = Max or Fixed, Constraint Value = 1
    • When set to Max, the model is also allowed to not use any of the 3 new potential plants at all (if optimal)
    • When set to Fixed, the model has to open 1 of the 3 new potential plants during the modelling horizon
  • Status = Include (or set to Exclude and change to Include through a scenario item)
  • Counting Rule = Facilities

A couple of alternative approaches to this are:

1. Run it as in the above-described approach, but just without the Facility Count Constraint (set Status = Exclude). This way the model is allowed anything from not opening/using any of the new potential plants to opening and using all 3 during the modelling horizon.
2. Set up 3 separate scenarios where in each scenario 1 of the 3 new potential plants is opened (do not use the facility count constraint when using this approach). This way the outputs can be compared to see how different the costs for inclusion of each new potential plant are. Should it for example turn out that the costs of 2 plants are very close to each other, then other factors may determine the final choice of new plant location.

(Flexible) Demand for By-Products

As mentioned above in the section on the Bill Of Materials input table, it is possible to set up a model where there is demand for a product that is the By-product resulting from a BOM. This does require some additional set up, and the below walks through this, while also showcasing how the model can be used to determine how much of any flexible demand for this by-product to fulfill. The screenshots show the set-up of a very simple example model built for this specific purpose.

On the Products table, besides the component (for which there also is demand in this model) that goes into any BOM, we also specify:

1. EndProduct_1, the finished good for which there is demand and which is produced using a BOM. The Unit Price is set to 5, meaning for each unit sold, the revenue is $5.
2. ByProduct_1, this is a by-product that results from the BOM that produces EndProduct_1. There is also flexible demand for this by-product, and for every unit sold, the revenue is $3 as set by its Unit Price.

The demand for the 3 products is set up on the Customer Demand table and we notice that 1) there is demand for the Component, the End Product, and the By-Product, and 2) the Demand Status for ByProduct_1 is set to Consider, which means it does not need to be fulfilled, it will be (partially) fulfilled if it is optimal to do so. (For Component_1 and EndProduct_1 the Demand Status field is left blank, which means the default value of Include will be used.)

The EndProduct_1 is made through a BOM which consumes Component_1 and also make ByProduct_1 as a Byproduct. For this we need to set up a BOM:

1. FG_BOM is the BOM that produces EndProduct_1. It is associated with the production of EndProduct_1 via a Production Policy (see next screenshot below).
2. This second line of FG_BOM tells us that for each unit of EndProduct_1 produced, half a unit of ByProduct_1 is also made.
3. To make it work to have demand for ByProduct_1 in the model, this product needs to have its own Production Policy, and since it is the result of making EndProduct_1, it also needs its own BOM, which is set up here in records 3 and 4, named “BYP_BOM”.
4. We use the EndProduct_1 here and set it as a Byproduct for this BOM, by setting Quantity = 2, we maintain the correct ratios between EndProduct_1 and ByProduct_1. I.e. this BOM (once associated with the ByProduct_1 on the Production Policies tables) says that 2 units of EndPrododuct_1 are made as a result of making 1 unit of ByProduct_1.
5. Again, to maintain the correct ratios, we also need to set that 2 units of Component_1 go into making 1 unit of ByProduct_1 (and 2 units of EndProduct_1 at the same time).

Next, on the Production Policies table, we see that Component_1 can be created without a BOM, and:

1. End_Product_1 is made by using FG_BOM
2. ByProduct_1 is made by using BYP_BOM

In reality, these 2 production policies result in the same consumption of Component_1 and same production amounts of EndProduct_1 and ByProduct_1. Both need to be present however in order to be able to also have demand for ByProduct_1 in the model.

Other model elements that need to be set up are:

• Inventory Policies for Component_1, EndProduct_1, and ByProduct_1 at the locations where they can flow through / be stored. Note that for EndProduct_1 and ByProduct_1 it is recommended to have at least 1 inventory policy with Stocking Site = True at a location the product can get to, the model may otherwise return infeasible (unless the BOM and demand ratios for these products always exactly match each other).
• Sourcing and transportation policies between the nodes of the network, including Customer Fulfillment Policies from the customer facing location(s) into the customer location(s)

Three scenarios were run for this simple example model with the only difference between them the Unit Price for ByProduct_1: Baseline (price of ByProduct_1 = 3), PriceByproduct1 (Unit Price of ByProduct_1 = 1), PriceByproduct2 (Unit Price of ByProduct_1 = 2). Let’s review some of the outputs to understand how this Unit Price affects the fulfillment of the flexible demand for ByProduct_1:

The high-level costs, revenues, profit and served/unserved demand outputs by scenario can be found on the Optimization Network Summary output table:

1. The Baseline scenario with the highest Unit Price for ByProduct_1 has the highest Supply Chain Cost, but also highest Revenue and Total Profit as compared to the other 2 scenarios. All demand is served as the Total Unserved Demand Quantity is 0. As a reminder, demand was 300 units of Component_1, and 100 units each of EndProduct_1 and ByProduct_1.
2. The PricByproduct1 scenario which has the lowest Unit Price for ByProduct_1 has the lowest Supply Chain Cost, and also the lowest Revenue and Total Profit. There are 100 units of Unserved Demand, which is for ByProduct_1 as that is the only product with flexible (considered) demand.
3. The PriceByproduct2 scenario which has Unit Price for ByProduct_1 set to 2, which is in between the value for Unit Price in the other 2 scenarios, also sits in between the other 2 scenarios when we look at Supply Chain Cost, Revenue, and Profit. 50 units of unserved demand means that half of the demand for ByProduct1 was served.

On the Optimization Production Summary output table, we see that all 3 scenarios used BYP_BOM for the production of EndProduct_1 and ByProduct_1, it could have also picked the other BOM (FG_BOM) and the overall results would have been the same.

1. In the Baseline scenario, 100 units of Byproduct_1 have been produced, as it is overall optimal to fulfill all demand for Byproduct_1.
2. In the PriceByproduct1 scenario 50 units of Byproduct_1 have been produced as there is demand for 100 units of EndProduct_1, which is Included (i.e. this demand must be fulfilled). And, based on the BOMs, for each unit of EndProduct_1, half a unit of Byproduct_1 is made too.
3. Same as in the PriceByproduct1 scenario, 50 units of Byproduct_1 have been produced in the PriceByproduct2 scenario as there is demand for 100 units of EndProduct_1, which is Included.

As the Optimization Production Summary only shows the production of the end products, we will also have a look at the Optimization Bills Of Material Summary output table:

1. Since it is optimal to fulfill all 100 units of the flexible demand of Byproduct_1 in the Baseline scenario, this results in production of 200 units of EndProduct_1, even though there is only demand for 100 units of it. In other words: it is more beneficial to overproduce and store 100 units of EndProduct_1 than not fulfilling the flexible demand for Byproduct_1.
2. Since the 100 units of demand for EndProduct_1 have to be fulfilled, the PriceByproduct1 scenario produces that exact amount, but no more as it is not beneficial to produce more to fulfill more of the flexible demand for Byproduct_1 due to the lowered Unit Price.
3. Same as in the PriceByproduct1 scenario, the PriceByproduct2 scenario also produces no more than the 100 units needed to fulfill the demand for EndProduct_1. The lowered Unit Price for Byproduct_1, even though higher than in the PriceByproduct1 scenario, is not high enough to warrant over production of EndProduct_1 in order to fulfill more of the flexible demand for Byproduct_1.

Lastly, we will have a look at the Optimization Inventory Summary output table:

1. In the Baseline scenario, we saw that it was optimal to fulfill all flexible demand for Byproduct_1, which led to over production of EndProduct_1: 200 units while 100 were demanded. The remaining 100 units are ending up in inventory at PLT_1.
2. In the PriceByproduct1 scenario, 50 units of Byproduct_1 were produced as a result of the production of 100 units of EndProduct_1. Because the UnitPrice is so low ($1), it is cheaper to keep these 50 units in Inventory at PLT_1 than to ship them through the DC to the customer to fulfill the customer’s demand for 100 units of Byproduct_1 partially.
3. There is no record for the PriceByproduct2 scenario in this output table, as there is no inventory of any of the products at the end of the optimization run. The Unit Price of Byproduct_1 in this scenario ($2) made it profitable to use the 50 units of it that were produced as a result of needing to serve the demand for EndProduct_1 to partially fulfill the demand the customer has for Byproduct_1.

Note that had the demand for Byproduct_1 been set to Include rather than Consider in this example model, all 3 scenarios would have produced 100 units of it to fulfill the demand, and as a result have produced 200 units of EndProduct_1. 100 of those would have been used to fulfill the demand for EndProduct_1 and the other 100 would have stayed in inventory, like we saw in the Baseline scenario above.