Modeling the pandemic is a critical problem. A good model should help us better understand how it is growing and also how it may end. This is a "system dynamics" problem.
I'm sure those doing the models have some sophisticated tools. They are probably using some form of system dynamics. However, to my understanding, there is no formal standard for the modeling language and tools.
System dynamics has been around for many years. You can learn more about it in a book described at http://web.mit.edu/jsterman/www/BusDyn2.html You will find examples of similar but more limited social systems.
The basic concept is that things flow from sources through stocks and more flows with feedback loops. The flow rates, feedback loops and stock levels are determined by statistical formulas and the dynamic evolution of the system is analyzed over a period of time.
I have included a rather simple model of the public mental health system in Michigan, below, that likely is similar for other states.
This is over-simplified, but demonstrates the general concept.
There is a need for a modeling language standard so that more people can develop and share expertise, and models can be shared, but, more importantly, so that parts of models, the data and the formulas can be more readily shared, and so that the basic modeling techniques can be refined and extended, potentially to support networks of distributed, contributing components.
Many who read this may be familiar with the Object Management Group (OMG), and the development of specifications for computer-based modeling languages. I am co-chair of the Business Modeling and Integration task force, and have considered the possibility of a system dynamics modeling initiative, but I have not sparked much interest among those who would build or buy modeling tools that would implement such a standard. Maybe the time is now.
The scope of a pandemic model could be very large since there are many stocks and flows, or simpler systems (more like the example, above) can generalize stocks, such as patients in all hospitals, or in a region, as consolidated stocks.
At the same time, the statistical formulas should support statistical probability ranges, so that we can analyze the best, worse and most likely changes under different circumstances, and understand the key points at which the growth might be most effectively mitigated and the recovery might be more graceful.
Similar models must be applied to the economy as it is affected by the pandemic, ways to mitigate the adverse consequences as the pandemic grows and wanes, and the measures to gracefully compensate both as the pandemic grows and as we recover.
While I am sure there are models, they tend to be focused on narrower interests, particularly business and financial interests. Development of pandemic models would also surface additional economic, social and healthcare factors that may help mitigate the impact on many people who may otherwise be overlooked. In addition, in the long run, it may enable us to better improve our economic and healthcare systems to avoid and mitigate the consequences of future pandemics.
Building the Agile Enterprise
Sunday, March 22, 2020
Modeling the Pandemic--System Dynamics Modeling
Sunday, March 31, 2019
VDML: Making Business Process Models Agile
Keith Swenson recently posted an assertion that Business Process Models are Not Agile. I agree. Business process models can be large and complex, involving multiple organizations, and the design and development of a process can be very remote from the people who actually manage and do the work.
The solution is not to throw out business process modeling, but rather to provide a more agile architecture and supporting business modeling capability to limit the scope of responsibility for each process change to improve local control and adaptation of processes.
VDML (Value Delivery Modeling Language) supports development of a more agile architecture. A VDML model represents processes as "capability methods" (the implementations of business capabilities).
A line of business delivers a product or service as a value stream. The value stream is composed of a network of capability methods, as services, delegating work to other capability methods to perform work of supporting specialties. The scope of a capability method should be within the scope of responsible of the operational organization unit. Recursive delegation forms a decomposition network. At the same time, capability methods may be engaged as shared services across lines of business for economies of specialization and scale.
A VDML capability method is a business process abstraction. The focus is on statistical flow of deliverables and creation of value rather than flow control of individual transactions. This significantly reduces the process complexity and enables attention to business requirements for performance and consumption of resources. The delegation and deliverable flow networks define the dependencies between capability methods for resolution of changes with broader scope. The value stream defines the impact of capability methods on customer value propositions. This process architecture and abstraction enables business leadership to define clear business requirements and responsibilities for implementation of a business transformation.
The result is that each business unit has more focused responsibility, accountability and control for its capability methods both for incremental improvements and for strategic business transformations.
The solution is not to throw out business process modeling, but rather to provide a more agile architecture and supporting business modeling capability to limit the scope of responsibility for each process change to improve local control and adaptation of processes.
VDML (Value Delivery Modeling Language) supports development of a more agile architecture. A VDML model represents processes as "capability methods" (the implementations of business capabilities).
A line of business delivers a product or service as a value stream. The value stream is composed of a network of capability methods, as services, delegating work to other capability methods to perform work of supporting specialties. The scope of a capability method should be within the scope of responsible of the operational organization unit. Recursive delegation forms a decomposition network. At the same time, capability methods may be engaged as shared services across lines of business for economies of specialization and scale.
A VDML capability method is a business process abstraction. The focus is on statistical flow of deliverables and creation of value rather than flow control of individual transactions. This significantly reduces the process complexity and enables attention to business requirements for performance and consumption of resources. The delegation and deliverable flow networks define the dependencies between capability methods for resolution of changes with broader scope. The value stream defines the impact of capability methods on customer value propositions. This process architecture and abstraction enables business leadership to define clear business requirements and responsibilities for implementation of a business transformation.
The result is that each business unit has more focused responsibility, accountability and control for its capability methods both for incremental improvements and for strategic business transformations.
Monday, September 3, 2018
VDML for Business Architects: Part 1 of 11, Introduction
The OMG (Object Management Group) issued an RFP for a
Business Architecture Core Metamodel (BACM) in March, 2017. The purpose of this
RFP is to obtain a modeling language for business architects to support
business leaders in the development of strategic business plans and
transformation models. The modeling
language will ensure that the multiple perspectives for a strategic plan are
integrated to ensure a consensus on a consistent and validated transformation
plan. The RFP can be found at https://www.omg.org/cgi-bin/doc?bmi/17-03-07
.
The reference to a “core metamodel” reflects the intent to provide a metamodel (modeling language specification) that captures and integrates the key elements of existing diagrams and tables used by business architects to describe strategic solutions. This integration will ensure the consistency of the various perspectives and associated displays for rapid configuration, validation and development of consensus on business transformation solutions. The RFP does not call for specification of displays since an integrated modeling capability will enable enhanced views that will be refined as business architect practices continue to evolve. The VDML specification can be found at https://www.omg.org/spec/VDML/
· Abstraction to represent a business design at an appropriate level of detail for business leaders,
· Identification of the sources and consequences of value contributions for customers,
· Recognition of the many ways that people participate in doing the work of the enterprise,
· Support for analysis of potential improvements and the impact of innovations,
· Analysis of the interactions with customers, business partners and other members of the business ecosystem, and
· Rapid exploration of potential business changes and optimization of operations across lines of business.
The BAVE submission to the BACM RFP demonstrates VDML support for most of the business architecture perspectives and provides some extensions to address innovation, strategic planning and transformation shortcomings. The submission illustrates how subsets of the metamodel support the following perspectives:
· Organization
· Capability
· Process
· Value
· Scenario
· Measurements
· Business partners and customers
· Products and services
· Information and data
· Regulations, policies and rules
· Objectives and transformation planning
· General features
· Organization
· Capability modeling
· Process abstraction
· Measurements
· Accountability
· Value contribution analysis
· Executive dashboard support
· Agile business architecture
· Business transformation
The reference to a “core metamodel” reflects the intent to provide a metamodel (modeling language specification) that captures and integrates the key elements of existing diagrams and tables used by business architects to describe strategic solutions. This integration will ensure the consistency of the various perspectives and associated displays for rapid configuration, validation and development of consensus on business transformation solutions. The RFP does not call for specification of displays since an integrated modeling capability will enable enhanced views that will be refined as business architect practices continue to evolve. The VDML specification can be found at https://www.omg.org/spec/VDML/
Three draft specification proposals were submitted to OMG in
May, 2018. One of those submissions is based on VDML (Value Delivery Modeling Language), an existing OMG specification,
adopted in May, 2015. The BACM
submission proposes some extensions to VDML to improve support of strategic
planning and transformation management. The current VDML specification can be
found at https://www.omg.org/spec/VDML/
.
VDML was developed to address the modeling needs of business
leaders, such as· Abstraction to represent a business design at an appropriate level of detail for business leaders,
· Identification of the sources and consequences of value contributions for customers,
· Recognition of the many ways that people participate in doing the work of the enterprise,
· Support for analysis of potential improvements and the impact of innovations,
· Analysis of the interactions with customers, business partners and other members of the business ecosystem, and
· Rapid exploration of potential business changes and optimization of operations across lines of business.
While providing a powerful modeling capability for business
analysis and design, the version of VDML adopted by OMG falls short of support
for strategic planning and business transformation as required by the Business Architecture Core Metamodel
(BACM) RFP. The VDML-based submission to
the BACM RFP is named Business
Architecture VDML Extension (BAVE) and includes extensions to address strategic
planning and business transformation.
The result is an integrated modeling capability that fills
the gap between strategic planning and conceptual business design that ensures
a clear, shared understanding for implementation of transformation requirements
as well as analysis, monitoring and incremental improvement of business
operations.The BAVE submission to the BACM RFP demonstrates VDML support for most of the business architecture perspectives and provides some extensions to address innovation, strategic planning and transformation shortcomings. The submission illustrates how subsets of the metamodel support the following perspectives:
· Organization
· Capability
· Process
· Value
· Scenario
· Measurements
· Business partners and customers
· Products and services
· Information and data
· Regulations, policies and rules
· Objectives and transformation planning
These perspectives will support various diagrams currently
used by business architects. However, the
integrated model will also support evolving business architect practices and future
diagrams enabled by VDML integration of these different perspectives. The integrated metamodel also brings together
the key VDML modeling features that I will describe in subsequent posts.
The subsequent ten posts on this topic, VDML for Business Architects, will describe features that
distinguish the extended VDML as a robust modeling language for business
planning, analysis and design by business people and, in particular, by
business architects. Most of these
features are included in the current version of VDML. The features are presented in the following
categories:· General features
· Organization
· Capability modeling
· Process abstraction
· Measurements
· Accountability
· Value contribution analysis
· Executive dashboard support
· Agile business architecture
· Business transformation
Features based on the proposed BAVE extensions are identified
in Parts 7, 10 and 11.
For more abut business modeling and VDML, see my book, Building
the Agile Enterprise with Capabilities, Collaborations and Values.VDML for Business Architects: Part 2 of 11, General Features
Please see the post for VDML for Business Architects: Part 1
of 11, for the introduction to this series of posts. This post describes general features of VDML that
help fill the gap between strategic plans and realization of appropriate
business transformation.
1. Round-Trip design modeling
If the executive model is defined in a different, more abstract tool, the model will be imported to VDML for the development of detail. Additional modeling detail will likely reveal needs to revise the strategic plan for feasibility or efficiency. The revised model will be returned to the executive tool for approval or additional revisions. However, if the executive modeling tool is independent of VDML, then details will be lost returning to the executive tool, and further executive revisions will then make the executive model inconsistent with the VDML detail thus resulting in repeated work.
2. Single, seamlessly integrated model
3. Incremental business design
1. Round-Trip design modeling
Executives can develop a high-level model of a transformed
enterprise to pursue a strategic objective.
However, in order to validate and realize a strategic objective, it is
necessary to develop a more detailed business model to ensure that the solution
is feasible and beneficial, and that it can be implemented appropriately at a more
detailed level.
VDML supports the executive model and the structure for
expansion of the design to an appropriate level for implementation
requirements. In addition, since VDML
provides a consistent model from executive vision to operational requirements,
there is a seamless expansion of the executive model. If the executive model is defined in a different, more abstract tool, the model will be imported to VDML for the development of detail. Additional modeling detail will likely reveal needs to revise the strategic plan for feasibility or efficiency. The revised model will be returned to the executive tool for approval or additional revisions. However, if the executive modeling tool is independent of VDML, then details will be lost returning to the executive tool, and further executive revisions will then make the executive model inconsistent with the VDML detail thus resulting in repeated work.
2. Single, seamlessly integrated model
VDML represents the design and operation of an enterprise
and its ecosystem as a single, seamlessly integrated model as opposed to a
composite of linked models that represent different aspects of an
enterprise. The single model minimizes
complexity and ensures consistency without human effort to reconcile different
viewpoints.
All the displays that could be supported by separate models
can be implemented as views on the seamless model assuming the separate models
have consistent concepts. In addition,
the seamless model will more easily support views that bring together multiple
aspects of the enterprise. For example,
one current implementation of VDML supports a Business Model display (e.g.,
Osterwalder or Lindgren) with multiple business perspectives that are
integrated and consistent through the underlying VDML model. In the long term, the seamless model will
lead to more and better views and methods for developing and analyzing a model,
and it will support further advances in enterprise modeling and associated
practices.3. Incremental business design
A VDML model can be developed top-down, selectively expanding
delegation with deferred activity details to the extent acceptable for
executive consideration. Alternatively,
a model can be developed by examination of current business operations to
identify capabilities and activity networks to the extent necessary to support
current analysis and performance improvement, and to reconcile current
operations with transformation plans.
4.
Scenarios
A scenario defines a set of measurements and a capability
method delegation tree for a particular business situation. This supports rapid analysis of differences
in operating variables. Different
measurements and configurations can be applied to the same model in different
scenarios for exploration of what-if solutions.
Measurements can be attached to any MeasurableElement of VDML for each
scenario and computed for propagation of effects such as customer value.
5.
Support for system dynamics modeling
The statistical flow and value contribution design of VDML
models (see Part 6) provides the basis for future development of system
dynamics (simulation) models of enterprise operations. Such models would be valuable for consideration
of resource requirements, costs and delays involving Stores (a network element
where units of production are held pending action by a receiving Activity) and
Pools (a Store that holds reusable resources pending assignment by receiving
Activity) along with business partner and market effects of changes in value
propositions.
6.
Technology-independent abstraction
The VDML abstraction is IT technology-independent except as
the technology applied affects the speed, efficiency or quality of business operations. A VDML model represents enterprise design and
operations without reference to the complexity of the technology(s) involved in
the implementation. This extends to
modeling of interactions with outsourcing providers and other business
partners, thus including the enterprise ecosystem.
7.
Business process and activities abstraction
Capability methods represent abstractions of conventional
business processes but with statistical flow measurements. These abstractions are much less complex than
conventional business process models and are more compatible with the interests
of executives (see also Part 5).
8.
Computer-generated process design framework
Activity networks can be translated to business process
models that provide a framework for the more detailed design of
flow-control-based process models. This
framework can provide alignment of VDML, abstract activity networks with operational
business process models for shared performance and value measurements.
VDML for Business Architects: Part 3 of 11, Organization
Please see the post for VDML for Business Architects: Part 1
of 11, for the introduction to this series of posts. This part focuses on collaboration as a
fundamental organizational concept for more robust modeling of the structure,
operations and relationships of people and organizations to achieve enterprise
objectives.
1. Collaboration as how all work gets done
VDML can represent personnel and resources shared across organizations for resource sharing and workload balancing.
1. Collaboration as how all work gets done
Collaboration is the fundamental concept for how work of an
organization gets coordinated and accomplished.
Any collaboration can receive inputs, produce outputs and contribute to
values. Collaborations include all forms of persons and/or other collaborations
working together for a shared purpose.
Collaborations are specialized to four sub-classes: OrgUnit
(organization), BusinessNetwork, Community and CapabilityMethod (process
abstraction).
2.
Organization structure
An organization hierarchy is composed of nested OrgUnit
collaborations with Position roles, including roles for unit leader/manager and
sub-organizations. OrgUnits, in general,
have responsibility for resources in Stores (consumable resources) and Pools
(reusable resources including personnel).
3.
Collaborations as a core building block
A collaboration has
Participant roles that do the work of the collaboration. A role may be filled by another role such as
an OrgUnit Position, or a collaboration (as a Performer) representing
delegation of one collaboration to another (most often a capability method
delegates to an OrgUnit that performs another capability method). These capability methods can be implemented
as sharable services that contribute to multiple value streams and lines of
business.
4.
Context-based role assignments
Scenario-based contexts enable some capability methods to be
engaged in different contexts including other value streams and lines of
business. The measurements and role
assignments will be different in different contexts. Performance measures may depend on different
work products and facilities. Roles of the capability method may draw on
personnel resources of different organizations.
5.
Roles of roles
Roles can be filled by roles. This enables, for example, roles of an
OrgUnit to fill roles of a capability method or roles of another collaboration
such as a project team or a committee.
Roles may represent personnel in a Pool for assignment to roles in other
collaborations.
6.
Extended organizational relationships
Traditional organization models focus on the management
hierarchy with weak recognition of other relationships that are essential to
the operation of the business. VDML
provides for integrated modeling of the many cross-organization collaborations
and multiple roles of employees to identify the multiple contributions and
relationships of employees in additional collaborations.
7.
Organizational change impact analysis
Cross-organizational role assignments highlight less obvious
organizational contributions and dependencies.
These are important relationships to understand when changing
organizational assignments.
8.
Shared personnel/resourcesVDML can represent personnel and resources shared across organizations for resource sharing and workload balancing.
VDML for Business Architects: Part 4 of 11, Capability Modeling
Please see the post for VDML for Business Architects: Part 1
of 11, for the introduction to this series of posts. This part focuses on business capabilities
and their application to accomplish required work. A capability is the ability to perform the
type of work to deliver desired results.
It includes personnel with required skills, facilities, access to
resources and the intellectual capital for reliable and efficient capability application.
1. Capability applied by individuals and/or collaborations
1. Capability applied by individuals and/or collaborations
A capability method is a combination of collaboration and
capability that specifies the application of a capability including the
activities performed by individuals or delegated to organization units that
apply other, supporting capability methods.
2.
Capability delegation network
Delegations from a capability method to other capability
methods form a delegation tree that may be modeled without the detail of
activities that engage the delegated capability methods. Value contributions of capability methods (or
other collaborations) can be manually specified without activity network details. The delegation tree is not only important for
specification of shared services, but it supports refinement of the scope of
capabilities and it provides the basis for assignment of capability resources
and responsibilities to organization units.
3.
Capability methods as building blocks
Capability Methods can represent sharable services in a
service-oriented architecture. This
supports capability methods as shared components for configuration of new
business models that leverage existing capabilities. It also achieves economies of scale in the development
of methods and personnel as well as utilization of resources and adaptation to
changing business requirements.
4.
Capability library links to capability
implementers, providers and applications
The capability library is a taxonomy of all capabilities of
the enterprise. These have links to the
organization units that have implementation and/or application responsibility
and the activities that engage capability method(s) that deliver the capability
in different value streams and lines of business. The taxonomy is a classification
hierarchy. This is not the same as a
delegation tree that depicts levels of engagement of capability methods.
5.
Selective expansion of capability delegation
Capability method delegations form a tree of capability
methods. These delegation trees with
activity networks may be selectively expanded as appropriate to the level of
delegation necessary for the accuracy required by the purpose of the model. An un-expanded capability method can provide
an estimated summary of value contributions of the un-expanded branch of the
delegation tree.
VDML for Business Architects: Part 5 of 11, Process Abstraction
Please see the post for VDML for Business Architects: Part 1
of 11, for the introduction to this series of posts. VDML represents an abstraction of a business
process as a capability method with an activity network representing particular
operations. The activity networks do not require the technical details
encountered in operational business process models.
1. Unit of production flow model
1. Unit of production flow model
Instead of specification of flows of individual business
transactions, VDML represents the statistical flow of a unit of
production. While there may be different
flows through an activity network, these flows are described as fractions of a
unit of production and they impact value contributions according to those
fractions. This abstraction is less complex and more consistent with business
leader concerns and mental model of processes.
2.
Context-based role assignments
Capability methods can be engaged in multiple contexts
within the same VDML scenario (e.g., different lines of business). These
capability methods may be managed by different organization units such that
there are different role assignments by the different organization units.
3.
Performers as business objects/deliverables
Role participants can be passed by delegation and/or be used
as deliverables in activity networks.
For example, a patient may be an activity performer and also be the
subject (i.e., work product) of activity operations.
4.
Asynchronous/buffered deliverable flows
Where business process models send messages for asynchronous
exchanges, VDML sends deliverables to Stores that function as buffers or
queues. A store may have measurements of
the number of deliverables waiting and the time a deliverable is delayed in the
store.
5.
Inputs and outputs of collaborations and
activities
Various subject matter such as products, documents,
resources, materials and communications are the inputs and outputs of
collaborations, activities, stores and pools.
VDML identifies all of these as “business items” that are classified,
described and named in the BusinessItemLibrary.
The physical nature of these business items is generally unimportant in
the VDML abstraction except as their nature affects the measurements of the
performance and value contributions of the collaborations and activities that
consume and produce them. The
classifications and descriptive names are meaningful for model developers and
users to understand what the collaborations and activities are doing and
exchanging.
6.
Resource/personnel requirements analysis
Resource and personnel requirements can be computed from
consumption by assigned activities, production rates and duration of
assignments (from Pools of reusable resources and personnel).
Subscribe to:
Posts (Atom)