commit 62f34b13295f170508a17b11d9e37a1faa6a64e8
parent c13720c5ca8cf50ac0d77860018dcc7c08631243
Author: Bob Haugen <bob.haugen@gmail.com>
Date: Thu, 1 Aug 2019 19:13:13 -0500
Merge pull request #525 from valueflows/upper-plan
Higher level planning
Diffstat:
8 files changed, 329 insertions(+), 0 deletions(-)
diff --git a/docs/SUMMARY.md b/docs/SUMMARY.md
@@ -23,6 +23,8 @@
* [Transfers](introduction/transfers.md)
* [Exchanges](introduction/exchanges.md)
* [Proposals](introduction/proposals.md)
+* [Operational Planning](introduction/plans.md)
+* [Estimated Planning](introduction/estimates.md)
* [Scoping](introduction/scoping.md)
* [Classification](introduction/classification.md)
* [Recipes](introduction/recipes.md)
diff --git a/docs/introduction/estimates.md b/docs/introduction/estimates.md
@@ -0,0 +1,29 @@
+# Higher Level Planning, Budgeting, and Analysis
+
+The Processes section explains processes at their basic level, starting with operational observable processes. The Operational Planning section explains how to group those processes into a scheduled plan at an operational level. This section explains how to use the same process and plan pattern to represent higher level requirements, those that are not (yet) actually scheduled. We are calling those Scenarios.
+
+Processes can be composed into scenarios at any level. Like scheduled plans, these scenarios can be created from recipes. Like scheduled plans, they have inputs and outputs (usually intents, sometimes sumarized economic events), derived from nested processes.
+
+### Scenarios
+
+Some examples we have seen:
+* <b>Plan Refinement</b>. Before the final operation plan is set, sometimes it is useful to make more general plans, which then can be refined further, ending with the scheduled plan. These plans are estimates made using "planning horizons", which are defined durations starting from the planning date - for example year then month, then blending into the actual scheduled plans.
+* <b>Budgeting</b>. A Budget is a summary of input requirements for a scope for a time interval (sometimes corresponding to the organization's "accounting period"), often yearly, as a higher level of planning. Budgets are often created to support a specific goal. Budgets are usually created before operational planning is done, and are estimates. Often a forecast is made consisting of desired or expected deliverables for the period, sometimes using past event history as a starting point. This would create a demand-driven budget. Or sometimes a supply-driven budget makes more sense, for example when all of the producing capacity will be used in any case, and then the outputs will be constrained by the inputs available. In any case, the budgeted inputs and outputs are kept, as they are often compared to actuals later. The budget itself could be represented as a Process, and it could nest line item processes based on type of resource or process. A budget is usually for one scope.
+* <b>Comparative Analysis</b>. Often different plans will be created for the same basic data set. One example is when doing risk analysis or other comparative analysis. Different assumptions might skew a plan in different useful directions, for example a "normal scenario" and a "worst case scenario".
+* <b>Network Analysis</b>. This is an analytical look at all or some of the actual and/or potential resource flows for a scope, often a community or region. This can be modeled using higher level types of processes and types of resources, and could include intents or economic events. One use of this kind of analysis is to identify gaps and opportunities to keep resources circulating in a community to improve economic health and resilience.
+
+Agents can define different scenarios that they want to use. So for example, if a group does yearly budgets, each new budget could reference a "yearly budget" scenario definition.
+
+The model itself is quite flexible, and we expect there will be more uses for it, all using the basic input-process-output structure with resource flows connecting them, contained by a scenario.
+
+### Connecting Plans and Scenarios
+
+Plans and Scenarios do not need to be connected. If comparisons are needed, often the time periods and scope are all that is needed. In addition, if resource specifications and/or process specifications are part of a classification taxonomy, that can be used for connecting the higher to lower perspectives.
+
+Often Plans do not fit cleanly within Scenarios, because plans tend to be for real production when it happens, which usually does not fit nicely into accounting periods or planning horizons. Seasonal food production can be an exception to this.
+
+Scenarios can be refinements of other scenarios. For example, a group might do scenarios for yearly estimates, then refine those for each month, before creating operational plans which will be executed.
+
+If other requirements arise, we are happy to add connections as needed to the vocabulary.
+
+
diff --git a/docs/introduction/plan.md b/docs/introduction/plan.md
@@ -0,0 +1,36 @@
+# Operational Planning
+
+An operational plan is a schedule of related operational processes, that constitute a body of scheduled work with defined deliverable(s). A plan normally contains one or more process resource flows, one for each deliverable.
+
+A plan can cover more than one scope, if the different scopes are tightly coordinated with pre-agreed rules, for example sub-organizations of a main organization, or an ongoing supply chain. If not, or if the agents prefer, then requirements from another scope should become deliverables for that scope's plan. Different batch sizes could trigger a new plan for inputs to the main deliverable too. But all of this does not affect the vocabulary or model. Plans can relate to each other through resource flows just like Processes.
+
+Plans are used for understanding and coordinating what needs to happen for specific outputs. The size and complexity of a Plan is up to the people who are planning and coordinating the work.
+
+A Plan can be generated from a Recipe, or created without one.
+
+Some examples:
+
+* A communications group creates articles for a larger group. The communications group needs some of their articles to be translated into various languages, by another group within the larger group. Both the creation of an article and its translation could be part of the same plan.
+
+* An organization decides to mount a campaign for some objective. There might be many different deliverables: a fundraising website, some brochures, some events, etc. All of these can be part of the same plan for easier coordination. For example, a campaign logo could be used in all of these separate outputs.
+
+* An organization gets an order for some things they produce. They can create a plan to produce to that order, including all line items. Or they can gather all the orders for a time period for an item and produce to that as a larger plan.
+
+* An organization produces a standard batch size to stock, in anticipation of future orders.
+
+### Processes nested in a Plan
+
+When processes are "nested", it is not random, nor based on a taxonomy. It is based on what processes are actually part of the plan. And not all the inputs and outputs of nested processes are considered inputs and outputs of the plan, since some are both produced and consumed within the plan. In the following simplified example, the flows between plant/weed and weed/harvest are not flows input or output of the plan.
+
+
+
+* There are some common situations for nested processes that will not be as simple as the above diagram. Thes include:
+ * Action makes a difference. When a piece of equipment or tool is "used", it is not gone at the end of the nesting process. But if it is managed as a time-based resource with a calendar, some calendar duration is in fact consumed. Or if a citable resource is created and then cited inside, it is also still there at the end of the nesting process.
+ * Batch or lot size makes a difference. Suppose you have a requirement for 5 of some assembled item, and 4 of some input component are needed to make each item, 20 components in all. But the minimum batch size for the component is 100. Then 80 of the components will be left in inventory at the end of the nesting process, and that 80 will also an output of the outer process.
+
+
+### Planning from a Recipe
+
+Plans can be generated from a recipe by scaling the recipe according to the demanded quantity of the end outputs. This is called a "demand explosion". The generation might take into account current inventories, batch sizes, etc., so it is not necessarily a "pure" reflection of the recipe. In addition, often plans are tweaked after generation from a recipe, depending on how firm and exact the recipe is. A manufacturing recipe might be more exact than a recipe for a more general business process. For these reasons, a plans is decoupled from the recipe that generated it in the vocabulary. It maintains only the references to the resource and process specifications that were supplied from the recipe.
+
+
diff --git a/examples/budget.yaml b/examples/budget.yaml
@@ -0,0 +1,98 @@
+# Example: Simple operational plan
+
+'@context':
+ - https://git.io/vf-examples-jsonld-context
+ - csa: https://csa.example/
+
+'@id': rgh:valueflows/valueflows/master/examples/budget.yaml
+'@graph':
+
+ - '@id': csa:8e5fe80d-a769-4bd5-89e5-2136d33eab9f
+ '@type': Scenario
+ name: Budget for 2019
+ skos:note: Inputs and outputs to determine production and support needed
+ hasBeginning: 2019-01-01T00:00:00-5:00
+ hasEnd: 2019-12-31T00:00:00-5:00
+
+ - '@id': csa:02b39a30-3e04-4305-9656-7f261aa63c84
+ '@type': Process
+ name: 2019 production
+ plannedWithin: csa:8e5fe80d-a769-4bd5-89e5-2136d33eab9f
+
+ - '@id': csa:a8236bbb-81e0-422d-9861-56d2417db0fb
+ '@type': Intent
+ inputOf: csa:02b39a30-3e04-4305-9656-7f261aa63c84
+ action: consume
+ provider: https://csa.example/
+ receiver: https://csa.example/
+ resourceClassifiedAs: csa:6b97b1be-8e07-44ac-82e5-214f1b2aaf33 # seeds
+ flowQuantity:
+ qudt:unit: unit:Kg
+ qudt:numericValue: 1000
+
+ - '@id': csa:b52a5815-fae9-43bf-be95-833b95dc0adb
+ '@type': Intent
+ inputOf: csa:02b39a30-3e04-4305-9656-7f261aa63c84
+ action: consume
+ provider: https://csa.example/
+ receiver: https://csa.example/
+ resourceInventoriedAs: csa:3129ca8b-fcda-45be-bbda-294dc924d3b9 # paper
+ flowQuantity:
+ qudt:unit: unit:Number
+ qudt:numericValue: 1020
+
+ - '@id': csa:33e8933b-ff73-4a01-964a-ca7a98893083
+ '@type': Intent
+ outputOf: csa:02b39a30-3e04-4305-9656-7f261aa63c84
+ independentDemandOf: csa:8e5fe80d-a769-4bd5-89e5-2136d33eab9f
+ action: produce
+ provider: https://csa.example/
+ receiver: https://csa.example/
+ resourceInventoriedAs: csa:6078f30a-b15b-4b1c-8e77-797abae11378 # specific posters
+ flowQuantity:
+ qudt:unit: unit:Number
+ qudt:numericValue: 35
+
+ - '@id': csa:60f4204e-b8d2-4026-8577-102c3f82c0af
+ '@type': Intent
+ inputOf: csa:02b39a30-3e04-4305-9656-7f261aa63c84
+ action: consume
+ provider: https://csa.example/
+ receiver: https://csa.example/
+ resourceInventoriedAs: csa:e56fd654-7b94-4d96-8e60-de39e08329a7 # paper
+ flowQuantity:
+ qudt:unit: unit:Number
+ qudt:numericValue: 35
+
+ - '@id': csa:b90b0b77-09a2-42e2-8bd4-e9ae2c1c6172
+ '@type': Intent
+ inputOf: csa:02b39a30-3e04-4305-9656-7f261aa63c84
+ action: use
+ provider: https://csa.example/
+ receiver: https://csa.example/
+ resourceInventoriedAs: csa:e4783bef-9006-490c-9c03-389272c7444d # printing plate for the specific posters
+ flowQuantity:
+ qudt:unit: unit:Hour
+ qudt:numericValue: 1.5
+
+ - '@id': csa:583e83d9-a46d-44ff-bd71-88513a1d83c0
+ '@type': Intent
+ outputOf: csa:02b39a30-3e04-4305-9656-7f261aa63c84
+ action: produce
+ provider: https://csa.example/
+ receiver: https://csa.example/
+ resourceInventoriedAs: csa:e4783bef-9006-490c-9c03-389272c7444d # printing plate for the specific posters
+ flowQuantity:
+ qudt:unit: unit:Number
+ qudt:numericValue: 1
+
+ - '@id': csa:ad56a7ed-be3c-4937-a3fb-0f156bcd2c47
+ '@type': Intent
+ inputOf: csa:02b39a30-3e04-4305-9656-7f261aa63c84
+ action: consume
+ provider: https://csa.example/
+ receiver: https://csa.example/
+ resourceInventoriedAs: csa:86ad6e22-7640-4b93-972a-db7177ab2616 # blank printing plate
+ flowQuantity:
+ qudt:unit: unit:Number
+ qudt:numericValue: 1
diff --git a/examples/simple-plan.yaml b/examples/simple-plan.yaml
@@ -0,0 +1,111 @@
+# Example: Simple operational plan
+
+'@context':
+ - https://git.io/vf-examples-jsonld-context
+ - alice: https://alice.example/
+ printer: https://printer.example/
+
+'@id': rgh:valueflows/valueflows/master/examples/simple-plan.yaml
+'@graph':
+
+ - '@id': printer:8e5fe80d-a769-4bd5-89e5-2136d33eab9f
+ '@type': Plan
+ name: Anti climate change campaign materials
+ skos:note: A set of printed materials for the campaign by Students for Peace and Justice
+ time:before: 2019-04-08T17:00:00-5:00
+ dcterms:created: 2019-04-01T10:35:00-5:00
+
+ - '@id': printer:02b39a30-3e04-4305-9656-7f261aa63c84
+ '@type': Process
+ name: Print brochure
+ plannedWithin: printer:8e5fe80d-a769-4bd5-89e5-2136d33eab9f
+
+ - '@id': printer:a8236bbb-81e0-422d-9861-56d2417db0fb
+ '@type': Commitment
+ outputOf: printer:02b39a30-3e04-4305-9656-7f261aa63c84
+ independentDemandOf: printer:8e5fe80d-a769-4bd5-89e5-2136d33eab9f
+ action: produce
+ provider: https://printer.example/
+ receiver: https://printer.example/
+ resourceInventoriedAs: printer:6b97b1be-8e07-44ac-82e5-214f1b2aaf33 # specific brochures
+ flowQuantity:
+ qudt:unit: unit:Number
+ qudt:numericValue: 1000
+
+ - '@id': printer:b52a5815-fae9-43bf-be95-833b95dc0adb
+ '@type': Commitment
+ inputOf: printer:02b39a30-3e04-4305-9656-7f261aa63c84
+ action: consume
+ provider: https://printer.example/
+ receiver: https://printer.example/
+ resourceInventoriedAs: printer:3129ca8b-fcda-45be-bbda-294dc924d3b9 # paper
+ flowQuantity:
+ qudt:unit: unit:Number
+ qudt:numericValue: 1020
+
+
+ - '@id': printer:9bd19194-a36d-4a1f-896b-8082887962cb
+ '@type': Process
+ name: Print posters
+ plannedWithin: printer:8e5fe80d-a769-4bd5-89e5-2136d33eab9f
+
+ - '@id': printer:33e8933b-ff73-4a01-964a-ca7a98893083
+ '@type': Commitment
+ outputOf: printer:9bd19194-a36d-4a1f-896b-8082887962cb
+ independentDemandOf: printer:8e5fe80d-a769-4bd5-89e5-2136d33eab9f
+ action: produce
+ provider: https://printer.example/
+ receiver: https://printer.example/
+ resourceInventoriedAs: printer:6078f30a-b15b-4b1c-8e77-797abae11378 # specific posters
+ flowQuantity:
+ qudt:unit: unit:Number
+ qudt:numericValue: 35
+
+ - '@id': printer:60f4204e-b8d2-4026-8577-102c3f82c0af
+ '@type': Commitment
+ inputOf: printer:9bd19194-a36d-4a1f-896b-8082887962cb
+ action: consume
+ provider: https://printer.example/
+ receiver: https://printer.example/
+ resourceInventoriedAs: printer:e56fd654-7b94-4d96-8e60-de39e08329a7 # paper
+ flowQuantity:
+ qudt:unit: unit:Number
+ qudt:numericValue: 35
+
+ - '@id': printer:b90b0b77-09a2-42e2-8bd4-e9ae2c1c6172
+ '@type': Commitment
+ inputOf: printer:9bd19194-a36d-4a1f-896b-8082887962cb
+ action: use
+ provider: https://printer.example/
+ receiver: https://printer.example/
+ resourceInventoriedAs: printer:e4783bef-9006-490c-9c03-389272c7444d # printing plate for the specific posters
+ flowQuantity:
+ qudt:unit: unit:Hour
+ qudt:numericValue: 1.5
+
+ - '@id': printer:d4d2fd71-34f2-41c3-b1c5-19ad5ed2da59b
+ '@type': Process
+ name: Create poster plate
+ plannedWithin: printer:8e5fe80d-a769-4bd5-89e5-2136d33eab9f
+
+ - '@id': printer:583e83d9-a46d-44ff-bd71-88513a1d83c0
+ '@type': Commitment
+ outputOf: printer:d4d2fd71-34f2-41c3-b1c5-19ad5ed2da59b
+ action: produce
+ provider: https://printer.example/
+ receiver: https://printer.example/
+ resourceInventoriedAs: printer:e4783bef-9006-490c-9c03-389272c7444d # printing plate for the specific posters
+ flowQuantity:
+ qudt:unit: unit:Number
+ qudt:numericValue: 1
+
+ - '@id': printer:ad56a7ed-be3c-4937-a3fb-0f156bcd2c47
+ '@type': Commitment
+ inputOf: printer:9bd19194-a36d-4a1f-896b-8082887962cb
+ action: consume
+ provider: https://printer.example/
+ receiver: https://printer.example/
+ resourceInventoriedAs: printer:86ad6e22-7640-4b93-972a-db7177ab2616 # blank printing plate
+ flowQuantity:
+ qudt:unit: unit:Number
+ qudt:numericValue: 1
diff --git a/release-doc-in-process/all_vf.TTL b/release-doc-in-process/all_vf.TTL
@@ -61,9 +61,19 @@ vf:RecipeFlow a owl:Class ;
vs:term_status "unstable" ;
rdfs:comment "The linkage between a process recipe, an action that structures a recipe, and a resource specification." .
+vf:ScenarioDefinition a owl:Class ;
+ rdfs:label "vf:ScenarioDefinition" ;
+ vs:term_status "unstable" ;
+ rdfs:comment "The type definition of one or more scenarios." .
+
# PLAN CLASSES
+vf:Plan a owl:Class ;
+ rdfs:label "vf:Plan" ;
+ vs:term_status "unstable" ;
+ rdfs:comment "A logical collection of processes that constitute a body of scheduled work with defined deliverable(s)." .
+
vf:Intent a owl:Class ;
rdfs:label "vf:Intent" ;
vs:term_status "unstable" ;
@@ -84,6 +94,11 @@ vf:Agreement a owl:Class ;
vs:term_status "unstable" ;
rdfs:comment "Any type of agreement among economic agents." .
+vf:Scenario a owl:Class ;
+ rdfs:label "vf:Scenario" ;
+ vs:term_status "unstable" ;
+ rdfs:comment "An estimated or analytical logical collection of higher level processes used for budgeting, analysis, plan refinement, etc." .
+
# OBSERVATION CLASSES
@@ -171,6 +186,28 @@ vf:recipeOutputOf
vs:term_status "unstable" ;
rdfs:comment "Relates an output flow to it's node in a recipe." .
+vf:plannedWithin
+ a owl:OBjectProperty ;
+ rdfs:label "planned within" ;
+ rdfs:domain vf:Process ;
+ rdfs:range vf:Plan ;
+ vs:term_status "unstable" ;
+ rdfs:comment "The process with its inputs and outputs is part of the plan." .
+
+vf:independentDemandOf
+ a owl:ObjectProperty ;
+ rdfs:label "independent demand of" ;
+ rdfs:range vf:Plan ;
+ rdfs:domain vf:Commitment ;
+ rdfs:comment "Represents a desired deliverable to the outside of this plan." .
+
+vf:scheduled
+ a owl:ObjectProperty ;
+ rdfs:label "scheduled" ;
+ rdfs:range xsd:boolean ;
+ rdfs:domain vf:Plan ;
+ rdfs:comment "The plan is scheduled, or is a higher level estimated plan." .
+
vf:resourceInventoriedAs
a owl:ObjectProperty ;
rdfs:label "resource inventoried as" ;
@@ -541,6 +578,22 @@ vf:conformsTo
vs:term_status "unstable" ;
rdfs:comment "The primary resource knowledge specification or definition of an existing or potential resource." .
+vf:refinementOf
+ a owl:ObjectProperty ;
+ rdfs:label "refinement of" ;
+ rdfs:domain vf:Scenario ;
+ rdfs:range vf:Scenario ;
+ vs:term_status "unstable" ;
+ rdfs:comment "This scenario refines another scenario, often as time moves closer or for more detail." .
+
+vf:definedAs
+ a owl:ObjectProperty ;
+ rdfs:label "defined as" ;
+ rdfs:domain vf:Scenario ;
+ rdfs:range vf:ScenarioDefinition ;
+ vs:term_status "unstable" ;
+ rdfs:comment "The scenario definition for this scenario, for example yearly budget." .
+
vf:recipeFlowResource
a owl:ObjectProperty ;
rdfs:label "recipe flow resource" ;
diff --git a/release-doc-in-process/plan-process-oper.png b/release-doc-in-process/plan-process-oper.png
Binary files differ.
diff --git a/release-doc-in-process/plan-process.png b/release-doc-in-process/plan-process.png
Binary files differ.
