Demo: Setup, Offers Requests, Planning (start)
This first demo (December 2023) includes network setup, offers and requests, and the start of seasonal planning, which is development in progress.
Work to do from this point (a rough list):
- Complete the planning function, including saving the plan, add/edit/delete individual commitments on the plan, supply-driven vs demand-driven capability, flagging of shortages, and other features to be discovered in use
- Complete user-maintainable recipes (sets of instructions for producing Resources to match Resource Specifications, including the required input Resources and flow of Processes).
- Record actual economic events against the plan, which will allow plan vs actual comparisons and reporting.
- Record economic events outside the production plan, such as fee and donation events.
- Network accounting, reporting, inventory
- A number of features incomplete or left behind, like complete configuration by each network, handling subsequent years, UX and UI improvements based on user feedback, authentication and authorization, and some technical debt
Agents are people and organizations (and ecological agents if needed).
Agents are also displayed on a map, along with their offers and user-defined attributes of interest (such as Carbon Beneficial Certified). They can be searched and filtered.
Resource Specifications are the types of resources of interest to the network. CFN needs the different types of fiber at their stage of the supply chain, the services performed by the mills, the the types of yarn produced, and the currency used for payments. Networks that manage manufacturing operations might want more detail, such as skills needed and equipment used in production.
For the Carbon Farm Network, as a supply chain network, the offers will be from the farms, processing mills, and transporters, who offer inputs to the network.
Requests will be from the designers who make up the purchasing cooperative in the network, usually yarn which they will use to produce their designs.
A network can have more than one plan defined, which appear on a list. CFN will usually have one plan per season, but could in the future have more if they run a later sequence of production in the year. The list gives the ability to add a new plan, or edit or delete an existing plan.
A plan starts from the offers and requests, which are displayed initially. Offers can be considered the potential inputs to a plan, requests are the potential plan outputs from the network supply chain.
Requests can be used to create the initial demand for the plan, on the Satisfy Requests column. (To satisfy a Request means to turn it into a plan to provide the requested Resources.) Or the initial demand can be created from scratch by adding items that the plan should create. Since CFN wants to completely satisfy the designer's needs in one seasonal plan, they will start by creating the Satisfy Requests column automatically from the requests.
The recipes are applied to the requests to be satisfied, to create the initial seasonal plan, which is spread horizontally on the page. Each column is a stage in the supply chain network. Each column shows the inputs and the outputs of the processes performed at that stage. The outputs of one stage feed the inputs of the next stage.
(At the current stage of development, the recipes are in a data file, as the recipe add/edit/delete feature is not complete.)
Scrolling to the right....
The recipes are used to create this plan, using algorithms that have developed over the decades since computers were first used in planning for manufacturing and supply chains - actually, one of the first uses for computers that couldn't be practically done manually. (In those earlier systems, recipes were called bills of material and routings.) In this case, the algorithm is "demand driven", meaning the recipes are applied backwards from the "independent demand" on the Satisfy Requests column.
Briefly, the inputs for each column are used to search for the next column of recipes, by matching the input resource specifications to recipe outputs. This continues recursively until no more recipes are found. The quantities and formulas in the recipes are used to calculate the sets of inputs and outputs in each column. If only one agent is offering a resource specification, it is included in the input or output. If there is an "exchange recipe" defined, the cost is calculated from the matching offer if one exists, or from the recipe, and included in the plan.
Looking at the detail of one planned process (the scouring process below), we can see that 75 pounds of White Alpaca Dirty fiber is the input to the process. Carbon Farm Network appears as the from and to agent because they own the fiber through the supply chain. Cleaned fiber, White Alpaca Clean is one output. It is 60 pounds because the recipe knows that scouring white alpaca fiber reduces the weight by 20%. A Scouring Service commitment is also output from this process, so that the service can be paid for. Scouring is billed in pounds, and the recipe knows to use the input pounds. The cost is calculated from a separate recipe for the exchange, and represents a reciprocal commitment from CFN to pay for the scouring service.
A note on the "actions" of consume, produce, deliver service. When the fiber is consumed, it is taken out of inventory. The cleaned fiber is produced, so it is now in inventory. Since services are not inventoried, the Scouring Service does not affect any actual resources. On the process detail below, you see "actions" of pickup and dropoff. They do not affect the owned inventory, but do affect the onhand inventory, since the location was changed. The pickup and dropoff actions also imply that the same resource is input and output. The shipping recipe indicates that the quantity for the delivered service is the sum of the quantities of the fiber dropped off.
Once the initial plan is displayed, the user can make adjustments to the Satisfy Requests column (add/edit/delete), and the adjustments will ripple backwards through the whole plan, using the same recipes and algorithms.
Once the initial plan is saved, further individual adjustments (add/edit/delete of any input or output) can be made to tweak the plan. This is frequently the case for CFN, as it take some weeks to finalize the season's plan. The development team will want to work closely with the CFN to iterate the planning software (and then the rest of the software) during the season.
Further feature additions we know about include:
- Some "supply driven" logic to apply the offers to the plan, especially for situations where the CFN might want to purchase more fiber from farms to keep as inventory for other opportunities (different networks use different amounts of "supply driven" and "demand driven" planning, partially depending on the industry)
- Visual notification of issues in the plan, like not enough supply of a particular resource specification at any point
We also need to clean up the styling, better user-defined graphics will be created, etc.
Some notes on the planning user experience (UX). This UX is tailored specifically for CFN, and will continue to be more tailored through iterations of using it. It should be reasonably applicable for other supply chain networks with a regular set of production stages. It will need to be somewhat, or even completely, different for other kinds of networks. The create-from-recipe logic will be very similar for other kinds of networks, but not exactly the same. With enough experience, this can become more generalized and modular.