Economic Networks

https://www.valueflo.ws/ describes itself as “a vocabulary for the distributed economic networks of the next economy, to coordinate the creation, distribution, and exchange of economic resources”. This article will focus more on the data models and logic used to “coordinate the creation, distribution, and exchange of economic resources” than the vocabulary used to communicate between economic agents (which is also important).

REA: Resources Events and Agents

Valueflows is based on the REA ontology, which was first defined and published by Professor William McCarthy of Michigan State University in 1982 in this paper https://www.valueflo.ws/linked-docs/REA%2BAccounting%2BModelA%2BGeneralized%2BFramework%2Bfor%2BAccounting%2BSystems%2Bin%2Ba%2BShared%2BData%2BEnvironment1982.pdf .

Bob Haugen, who is writing here, first ran into it in the 1990's when he was hired to lead a project to re-invent ERP (Enterprise Resource Planning) systems. That project was called https://en.wikipedia.org/wiki/Quick_Response_Engine . Existing ERP systems were hodgepodges of older software connected by the software equivalent of spaghetti. The REA model allowed all of the functions of ERP systems to be based on the same simple model and logic. Moreover, ERP systems tacked on a different system to manage their supply chains. But REA can manage both the internal workings of a company plus the whole supply chain using the same simple model and logic. In other words, one system (model and logic) to manage them all, and one system for the players to learn.

The REA data model

• Economic Resources like food, land, tools, work, houses and other buildings, vehicles, energy, etc.
• Economic Agents like people and organizations who manage the Economic Resources, including ecological agents like Lake Erie who influence their ecosystems.
  
  • Relationships between Agents in organizations, like member or employee.
• Economic Events that create, change, and transfer the Economic Resources from one Economic Agent to another.
• Metadata to describe and classify them all:
  
  • Resource Types (which we call Specifications because the word “Type” has too many other conflicting uses).
  • Relationships between Resource Specifications like parent and child to define product structures
  • Agent Relationship Roles.
  • Event Types (Actions).
  • Economic Processes which are managed by Economic Agents and which have Input and Output Events, allowing Agents to plan Input-Process-Output resource flows. (Migrating off of metadata.) See https://www.isixsigma.com/dictionary/input-process-output-i-p-o/
• The model has three layers or levels:
  

REA logic

I will focus here on the logic to plan and coordinate Input-Process-Output resource flows. This logic was first defined by https://en.wikipedia.org/wiki/Material_requirements_planning (MRP) systems. Those were among the first computer-aided systems that allowed people to coordinate processes that would be impossible without the computers.

This logic requires some metamodels defining the relationships among Resources, Events, and Processes. MRP uses Bills of Materials (BOMs) to define the relationships among Resources and Routings to define the resource flows through Processes. We use a combined single model that we call a Recipe https://www.valueflo.ws/concepts/recipes/ that defines the inputs and outputs of Processes and enables IPO flows when the output of one Process becomes the input to another.

Planning IPO flows

Generating dependent demands

You can read a lot about dependent demands here https://duckduckgo.com/?t=ffab&q=dependent+demand&ia=web

Short version: independent demands are externally defined, like customer orders, or internally planned, like “we should do this”. Dependent demands are whatever you need to do to satisfy the independent demands.

To create a plan: start with the independent demands.

Using whatever model you have to define the relationships between Resource Specifications, calculate the quantities and timing of Resources that will be required to satisfy the independent demands.

For each of those Resources, do the same: calculate the quantities and timing of Resources that will be required to satisfy those dependent demands, and keep going, recursively, until all known demands have been added to the plans.

You should end up with trees of planned Resources: a tree for each planned resource: possibly overlapping, becoming a directed graph, or maybe a forest.

Another direction: scheduling forward from output flows.

The previous section was about planning backwards from demands. But it is also useful sometimes to schedule forward from outputs, either known or expected. For example, in agriculture, crops need to be harvested when they are ready, and any subsequent processing of food or fiber needs to schedule forward from there.

The https://www.newyorktextilelab.com/ has animals like sheep or alpacas coming in to be sheared, and textile processing into usable fibers and clothing can't start until the wool comes in to be cleaned.

Combine supply and demand driven planning and scheduling, meet where they make sense:

Once the alpacas come in to be sheared, the wool moves forward into (for example) yarn and socks.

That’s an example of an app based on Valueflows logic, which was designed to coordinate the resources and work of the New York Textile Lab.

Exchanges can also be planned in conjunction with the production or supply chain planning…

…...for example paying a supplier for an input, as the textile lab pays its farmers and service providers for their resources.