|
|
Manufacturing and ERP (Enterprise Resource Planning) systems typically document their manufacturing instructions in Bills of Material (BOM) (relationships between parent products and their components) and separate Routings (a linear series of manufacturing "steps").
|
|
|
|
|
|
Computerized BOMs and Routings came from Material Requirements Planning (MRP), which was one of the first business computer systems that did something that could not have been done practically by manual methods. Here's some of the [history](https://en.wikipedia.org/wiki/Material_requirements_planning#History).
|
|
|
|
|
|
Value Flows uses a combination of Bills of Material and Routings that we call Recipes.
|
|
|
|
|
|
# Why?
|
|
|
|
|
|
Manufacturing recipes, also called [bills of manufacturing](http://www.mikeonmanufacturing.com/mike-on-manufacturing/2016/06/why-your-small-business-needs-a-bill-of-manufacturing-and-not-a-bill-of-materials.html) and [supply chain bills](http://www.profitpt.com/distribution/managing-your-supply-chain-bill-of-materials-that-is/), evolved in the 1990's.
|
|
|
|
|
|
Many problems with the old ways (separate BOMs and Routings) emerged as manufacturing became more distributed and more accurate scheduling became more important.
|
|
|
|
|
|
One of the problems was, **what routing step does a component go into?** If a product has 10 steps and 20 components, do they all go into the first step? Unlikely. But that's all you could know from a separate BOM and Routing.
|
|
|
|
|
|
The next step in evolution was [Routed Bills](https://www.youtube.com/watch?v=bS_uwsWx50Y), where each Bill of Materials component was assigned to a particular Routing step.
|
|
|
|
|
|
But, **what if a Routing step has more than one output?** This happens with by-products and co-products, for example, "flash" (trimmings) from molded metal or plastic components being fed back into the melt as an input to the next mold. Or products that are usually made together because of process similarities.
|
|
|
|
|
|
Or **what if the same Resource goes through more than one processing step**, which happens all the time in food processing, like dough that is mixed and then kneaded and risen several times before being shaped, and then risen again before being baked.
|
|
|
|
|
|
Manufacturing systems in 1990 assumed "discrete products", like nuts and bolts. They could not handle food processing.
|
|
|
|
|
|
And **manufacturing requires a lot more inputs than material parts**: for example, equipment, tools, workers with particular skills, space, energy, etc. Routings often include some of that information, but disconnected from the material part information. So manufacturing software typically ran two separate planning programs, Material Requirements Planning (MRP), which used the Bills of Material, and Capacity Requirements Planning (CRP), which used the Routings. Both of them had long execution times and were usually run in off-hours when no other changes could be allowed.
|
|
|
|
|
|
Also, **component parts are often manufactured by somebody else** and the production schedules for all of the inputs and outputs might want to be synchronized. But the bills of material and routings will belong to different organizations and live in different systems and often use different software.
|
|
|
|
|
|
# The introduction of Recipes
|
|
|
|
|
|
The first software that was specifically designed for food processing was called Prism, although the company has been bought and resold and renamed several times since then.
|
|
|
Prism rethought Bills of Material and Routings completely and combined them in a model they called a Recipe (which is why we used that name: VF Recipes are heavily influenced by Prism Recipes).
|
|
|
|
|
|
A Recipe is a set of Processes that may be connected when the output Resource from one Process becomes an input to another Process.
|
|
|
|
|
|
Recipes can handle all the problems mentioned above:
|
|
|
* each Process is linked to each of its inputs and outputs: no questions of which Process a component goes into.
|
|
|
* more than one output can come from the same Process, including recycled outputs that go back into the same or another Process.
|
|
|
* the same Resource can go through multiple Processes, being modified each time.
|
|
|
* the Processes that produce outputs that are needed as inputs to other Processes can belong to different Agents and still be linked and planned together.
|
|
|
|
|
|
(Recipes can also handle any other situation that can be handled by separate Bills of Material and Routings.)
|
|
|
|
|
|
# Separate BOMs and Routings do not work for resource flows. Recipes do.
|
|
|
|
|
|
Value Flows are another name for resource or material flows. Such flows are usually represented by [Input-Process-Output models](https://en.wikipedia.org/wiki/IPO_model). See https://en.wikipedia.org/wiki/Material_flow_analysis
|
|
|
|
|
|
A Recipe is an input-process-output model, where the Processes are connected when an output from one Process becomes an input to another Process.
|
|
|
|
|
|
The Processes are loosely connected, and can form networks of any complexity, not tightly connected in a linear sequence like a Routing where the steps are typically given sequence numbers. (Often the first step starts as number 100, the second step as 200, so a step 150 could be added later...sorta clumsy...)
|
|
|
|
|
|
The Processes that have resource flow dependencies can also live in different systems managed by different Agents using different software, if they all communicate using the same vocabulary (hint: https://valueflo.ws/ )
|
|
|
|
|
|
# Planning with Recipes
|
|
|
|
|
|
Because all of the relevant information lives in the same structure, material and capacity and workflow requirements can all be planned together, at the same time, and synchronized with each other.
|
|
|
|
|
|
Requirements for inputs from other Agents can be sent as Value Flows Intent messages to the other Agent, who can schedule their own related production and respond with a Commitment to a delivery time.
|
|
|
|
|
|
Moreover, all of the related schedule changes, new requirements, etc., can be scheduled or rescheduled event-by-event, so no massive overnight planning program ever needs to be run.
|
|
|
|
|
|
# Examples of Recipes and Planning
|
|
|
|
|
|
Start at page 8 in the [Pie Story](http://mikorizal.org/ValueFlows-Story.pdf).
|
|
|
|
|
|
Or https://valueflo.ws/examples/ex-planning.html#simple-plan-from-recipe
|
|
|
|
|
|
# Economic networks
|
|
|
|
|
|
Most economic activity involves more than one Agent (where an Agent is an individual person or organization like a company or a cooperative). Many manufactured products include components made by different Agents.
|
|
|
|
|
|
The Agents might be organized in a supply chain (usually an upside down tree with maybe several tiers of suppliers producing inputs to components made by the next tier and tier-by-tier arriving at a final product). Automobile manufacturing is organized like that. ValueFlows evolved from some supply chain software conversations around the year 2000 (among other influences). See for example [REA, a semantic model for supply chain collaboration](http://mikorizal.org/REA_+A+Semantic+Model+for+Internet+Supply+Chain+Collaboration_2000.pdf).
|
|
|
|
|
|
Other forms of economic networks include [economic ecosystems](https://www.academia.edu/10252910/The_uneasy_transition_from_supply_chains_to_ecosystems_The_value-creation_value-capture_dilemma), which don't necessarily have a "head" Agent like auto supply chains, and are organized in a loose network instead of a tree. Android phones are an example, where Google is a dominant Agent but not the only important one: Samsung probably sells more phones, and here's a list of [36 Android phone manufacturers](https://phandroid.com/manufacturers/).
|
|
|
|
|
|
Here's [a blog with many articles about economic networks](https://write.as/economic-networks/).
|
|
|
|
|
|
# Economic networks are different from corporations
|
|
|
|
|
|
A corporation, even a conglomerate, usually has a unified ownership (although it may be a group of investors) and a unified management which can dictate product structures like bills of material and routings which everybody is supposed to follow.
|
|
|
|
|
|
That is not the case with a network, where each Agent is independent and can do pretty much what they want, but will have negotiated agreements with other Agents about inputs to products.
|
|
|
|
|
|
Recipes as networks of loosely-coupled Processes in Input-Process-Output patterns fit economic networks better than linear Routings.
|
|
|
|
|
|
# GOSH, GOAT, and FabCity
|
|
|
|
|
|
The work of these three organizations intersects with each other and also all of the issues mentioned in this article.
|
|
|
|
|
|
[GOSH](https://openhardware.science/) is the Gathering for Open Science Hardware.
|
|
|
|
|
|
[GOAT](http://goatech.org/) is the Gathering for Open Agricultural Technology.
|
|
|
|
|
|
[FabCity](https://fab.city/) is a global initiative of cities aiming to "shift away from the industrial paradigm of Product-in Trash-out, by enabling the return of manufacture to cities supported by a Data-in Data-out urban model". [Their manifesto](https://fab.city/uploads/Manifesto.pdf) includes principles that are shared by GOSH and GOAT, like being ecological, participatory, sharing knowledge, and producing locally.
|
|
|
|
|
|
All of those organizations are also developing economic networks, that could potentially internetwork with each other.
|
|
|
|
|
|
FabCity is developing software using Valueflows. GOSH and GOAT are not, or at least not yet. But this article is being shared with people from all of those organizations to discuss what they can all agree on regarding manufacturing documentation, and Valueflows will use their agreements to influence VF:Recipes, which are not finished yet.
|
|
|
|
|
|
## Shared requirements for tracking resource flows
|
|
|
|
|
|
FabCity shares some principles and plans to share some software with [the Reflow project](https://reflowproject.eu/), which "aims to develop circular and regenerative cities through enabling active citizen involvement and systemic change to re-think the current approach to material flows in cities. The project utilizes Fab Labs and maker spaces as catalysts for change in urban and peri-urban environments." Both FabCity and Reflow will use Valueflows to track their circular material flows.
|
|
|
|
|
|
While tracking material flows is not yet an explicit requirement of GOSH or GOAT, GOSH will need such tracking if they want to manufacture medical devices (which they say they want to do), and GOAT will need material flow tracking for food products.
|
|
|
|