Business Operating Model

Purpose: The purpose of the Business Operating Model is to visualize how an organization functions and delivers value to its customers. The model presents a ‘one-page-overview’ of the organization and offers a quick way to communicate an organization’s value structure to different types of stakeholders.

Core concerns: The Business Operating Model can be put together in numerous ways including information on Stakeholders, Business Processes, Products, Projects, Channels, Key Performance Indicators and more. This enables you to create a Business Operating Model that reflects your organization’s specific value chain in detail. Below is an example of a Business Operating Model that shows a business’s suppliers, high-level processes, products & services, channels and customer segments:

Relation to other templates: The Business Operating Model is a strategic model that can be supplied with more detailed models such as a Business Capability Model, Requirement Models, Stakeholder Models and the Business Ecosystem Model.

Properties and metadata: The Business Operating Model can for example retain the following information:

  • A description of the diagram
  • Link to the owner of the diagram
  • Link to the one responsible for the accuracy of the diagram
  • Audits (auto generated information regarding its current state and access rights)
  • Associated documents, diagrams and other objects
  • Inherent Risk detailing risk considerations
  • Governance information detailing information about the published diagram and who has been involved in the approval of the diagram
  • Project status: information about budgeted and actual man-hours spent, percentage completed and the latest milestone, result and quality control of a change process.

In the picture below you can see the Business Operating Model’s properties dialogue window, where the information can be viewed and edited:

Use Case Diagram

Purpose: The purpose of the Use Case Diagram template is to document user interactions in a system context, as well as the context between different cases of user interactions. Below, you can see an example of a Use Case Diagram for the service at a restaurant:

UseCaseDiagram_2

Core concerns: The available objects you have to model use cases include: System Boundary, Actors, Use Cases, and connectors such as Association, Generalization, Include and Extend. Below, you can see an example of a Use Case Diagram for a booking system at a car rental service:

UseCaseDiagram_1

Relation to other diagrams: It is important to break down use cases into other diagrams such as Sequence Diagrams, Communication Diagrams, and Activity Diagrams templates for elaboration.

Properties and metadata: The Use Case Diagram can for example retain the following information:

  • A description of the diagram
  • Link to the owner of the diagram
  • Link to the one responsible for the accuracy of the diagram
  • Audits (auto generated information regarding its current state and access rights)
  • Associated documents, diagrams and other objects
  • Inherent Risk detailing risk considerations
  • Governance information detailing information about the published diagram and who has been involved in the approval of the diagram
  • Project status: information about budgeted and actual man-hours spent, percentage completed and the latest milestone, result and quality control of a change process.

In the picture below you can see the Use Case Diagram’s properties dialogue window, where the properties can be viewed and edited:

Transformation Plan

Purpose: The purpose of the Transformation Plan template is to document strategic transitions over time in the form of transformation plans. Below is an example of a Transformation Plan consisting of a sequence of projects:

TransformationPlan_2

Core concerns: The Transformation Plan template should be used to document the transformation of a part of an enterprise from a current to a future state. Additionally, a past state can be documented for reference. The template allows you to model Projects, Initiatives and Business Cases, and connect them with Activity paths and generic Connections. Below is an example of a Transformation Plan that specifies Initiatives, their related Projects and Business Case:

TransformationPlan_1

Relation to other templates: The Transformation Plan template should not be used to document project plans for calculating a Critical Path. The Critical Path Method Diagram should be used for that purpose. The Projects can be further detailed in a Work Model that includes Milestones in its syntax.

Properties and metadata: The Transformation Plan can for example retain the following information:

  • A description of the diagram
  • Link to the owner of the diagram
  • Link to the one responsible for the accuracy of the diagram
  • Audits (auto generated information regarding its current state and access rights)
  • Associated documents, diagrams and other objects
  • Inherent Risk detailing risk considerations
  • Governance information detailing information about the published diagram and who has been involved in the approval of the diagram
  • Project status: information about budgeted and actual man-hours spent, percentage completed and the latest milestone, result and quality control of a change process.

In the picture below you can see the Transformation Plan’s properties dialogue window, where the properties can be viewed and edited:

Strategy Model

Purpose: The purpose of the Strategy Model template is to document the strategy of the enterprise in a series of models and dashboards.

Core concerns: The Strategy Model template should be used to document the enterprise’s strategy via a wealth of models and dashboards. Vast amounts of different symbols are available in the Strategy Model template, which is why it might be tempting to model everything in the Strategy Model template. However, the template should only be used to model an enterprise’s strategy, as diagram specific connection types are not present in this template.

Below, you can see an example of a SWOT diagram modelled in the Strategy Model Template:

StrategyModel_2

Other functionalities: The Strategy Model template can also be used to build CxO specific dashboards containing strategically critical systems, processes, goals and KPIs for the given CxO, as seen in this example:

StrategyModel_1

Relation to other templates: The Strategy Model template can be used in addition to other strategic templates such as the Business Ecosystem, the Business Capability Model, the Business Canvas and the Strategic Roadmap.

Properties and metadata: The Strategy Model template can for example retain the following information:

  • A description of the diagram
  • Link to the owner of the diagram
  • Link to the one responsible for the accuracy of the diagram
  • Audits (auto generated information regarding its current state and access rights)
  • Associated documents, diagrams and other objects
  • Inherent Risk detailing risk considerations
  • Governance information detailing information about the published diagram and who has been involved in the approval of the diagram
  • Project status: information about budgeted and actual man-hours spent, percentage completed and the latest milestone, result and quality control of a change process.

In the picture below you can see the Strategy Model’s properties dialogue window, where the properties can be viewed and edited:

Strategic Roadmap

Purpose: The purpose of the Strategic Roadmap template is to document initiatives and projects over time from the perspective of a specific narrative. Strategic Roadmaps are not static and should ideally be revisited and iterated upon.

Below, you can see an example of a Strategic Roadmap for the implementation of two systems:

StrategicRoadmap_2

Core concerns: Using the Strategic Roadmap, you can model Initiatives and Projects, Timeframes and, if needed, connections. The Strategic Roadmap should be given a limited scope of a department, a program, or a strategic initiative. Typically, the enterprise will document several strategic roadmaps from different perspectives and business units.

Below, you can see an example of a Strategic Roadmap describing a company’s asset management initiatives over four years:

StrategicRoadmap_1

Relation to other templates: The Strategic Roadmap can show strategic initiatives over time that may be shown in other strategic diagrams such as the Strategy Model. For a more extensive overview of projects you can generate a Gantt chart using the Business Chart template.

Properties and metadata: The Strategic Roadmap can for example retain the following information:

  • A description of the diagram
  • Link to the owner of the diagram
  • Link to the one responsible for the accuracy of the diagram
  • Audits (auto generated information regarding its current state and access rights)
  • Associated documents, diagrams and other objects
  • Inherent Risk detailing risk considerations
  • Governance information detailing information about the published diagram and who has been involved in the approval of the diagram
  • Project status: information about budgeted and actual man-hours spent, percentage completed and the latest milestone, result and quality control of a change process.

In the picture below you can see the Strategic Roadmap’s properties dialogue window, where the properties can be viewed and edited:

State Machine Diagram

Purpose: The purpose of the State Machine Diagram template is to document the dynamic behavior of a class or an object.

Core concerns: The State Machine Diagram template enables you to model States, Pseudo States, History States, Lines and Annotations. These can be connected by Transitions.

As such, the State Machine Diagram can be used to show the different states of a class or an object and how the class or object responds to various events by changing from one state to another.

Below, you can see an example of a State Machine Diagram for an ATM:

StateMachineDiagram_1

Relation to other templates: The State Machine Diagram can be a decomposition of a State and can also be derived from a Class. The State Machine Diagram template is related to, but cannot replace the State Event Diagram, which is used to document Event States and time dependent behavior of systems.

Properties and metadata: The State Machine Diagram can for example retain the following information:

  • A description of the diagram
  • Link to the owner of the diagram
  • Link to the one responsible for the diagram
  • Link to a specific State of an object the diagram specializes
  • Audits (auto generated information regarding its current state and access rights)
  • Associated documents, diagrams and other objects
  • Inherent Risk detailing risk considerations
  • Governance information detailing information about the published diagram and who has been involved in the approval of the diagram

The above picture shows the properties dialogue window for the State Machine Diagram where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

 

 

 

Stakeholder Model

Purpose: The purpose of the Stakeholder Model template is to document internal and external individuals or groups who have a stake in for example an enterprise or a project. Below, you can see an example of a Stakeholder Model of Order Management:

StakeholderModel_1

Core concerns: Stakeholders can be grouped via Business Scope. Stakeholder relations are illustrated via the Interaction connection. Beyond this, you can enrich the Stakeholder Model with Capabilities, Business Processes, Information Systems, Initiatives, and Projects. Below, you can see several groupings of stakeholders:

StakeholderModel_2

Relation to other diagrams: The Interaction connections in the Stakeholder Model can be broken down into Requirement Models. The internal structure of the organization is modelled in an Organization Diagram while the interaction between the organization and its external environment can be modelled in a Business Ecosystem.

Properties and metadata: The Stakeholder Model can for example retain the following information:

  • A description of the diagram
  • Link to the owner of the diagram
  • Link to the one responsible for the accuracy of the diagram
  • Audits (auto generated information regarding its current state and access rights)
  • Associated documents, diagrams and other objects
  • Inherent Risk detailing risk considerations
  • Governance information detailing information about the published diagram and who has been involved in the approval of the diagram
  • Project status: information about budgeted and actual man-hours spent, percentage completed and the latest milestone, result and quality control of a change process.

In the picture below you can see the Stakeholder Model’s properties dialogue window, where the properties can be viewed and edited:

Requirement Model

Purpose: The purpose of the Requirement Model template is to document goals, objectives and other requirements for the enterprise or a specific project. Below, you can see an example of a Requirement Model showing the Policies and Business Rules of an organization:

RequirementModel_1

Core concerns: With the Requirement Model template, you can for example model Requirements, Goals, Change Requests, Policies, Business Rules, Critical Success Factors and Problems. This enables you to illustrate the interrelationships of requirements, for example showing which goals influence or contribute to each other, as the example below shows:

RequirementModel_3

You can also divide goals up in different areas that may for example be subject to different regulations as below:

RequirementModel_2

Relation to other templates: The Requirement Model offers a more detailed view on Requirements and Goals filtering out elements such as vision and mission compared to the Strategy Model. It can be used to detail how your organization live up to requirements specified in a Regulation Diagram or Requirements indicated in a Stakeholder Model.

Properties and metadata: The Requirement Model can for example retain the following information:

  • A description of the diagram
  • Link to the owner of the diagram
  • Link to the one responsible for the accuracy of the diagram
  • Audits (auto generated information regarding its current state and access rights)
  • Associated documents, diagrams and other objects
  • Inherent Risk detailing risk considerations
  • Governance information detailing information about the published diagram and who has been involved in the approval of the diagram
  • Project status: information about budgeted and actual man-hours spent, percentage completed and the latest milestone, result and quality control of a change process.

In the picture below you can see the Requirement Model’s properties dialogue window, where the properties can be viewed and edited:

 

 

Product Roadmap

Purpose: The purpose of the Product Roadmap is to visualize the lifecycles of the projects, within a specific scope and timeframe, in your product portfolio.

Core concerns: The Product Roadmap template enables you to model Products, Markets, Projects and Personae within a Timeframe. Additionally, you can add objects representing Equipment and Work Centers. This allows you to map the lifecycle of product releases within different markets for different customer segments.

Below, you can see two examples of Product Roadmaps. The first showing the timeframe and markets for the release of different apps with multiple versions:

ProductRoadmap_1

The second figure spans over several years to provide a high-level view of a products expected lifecycle spanning over several projects. It also illustrates how you can model markets with multiple customer segments, in this case based on gender:

ProductRoadmap_2

Relation to other templates: The Product Roadmap Template is inherently related to the Product Architecture, Product Canvas and Product Variant Master, in the sense that all these models focus on different aspects of the lifecycle of a product. Another view on projects and initiatives are provided from the Enterprise Investment Portfolio. There, the reasoning behind the investment in the project is visualized by connecting the initiative (in this case a new product) to the specific goals of the enterprise that it contributes to.

Properties and metadata: The Product Roadmap can for example retain the following information:

  • A description of the diagram
  • Link to the owner of the model
  • Link to the one responsible for the model
  • Audits (auto generated information regarding its current state and access rights)
  • Associated documents, diagrams and other objects
  • Inherent Risk detailing risk considerations
  • Governance information detailing information about the published diagram and who has been involved in the approval of the diagram

The above picture shows the properties dialogue window for the Product Roadmap where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

 

Product Canvas

Purpose: The purpose of the Product Canvas template is to present the relevant information related to a specific product.

Core concerns: The Product Canvas template enables you to gather relevant Business Charts and model Personae, Product Demands, Markets, Locations and Products. Additionally, you can model a SWOT analysis that details the Strengths, Weaknesses, Opportunities and Threats the product is affected by.

Below, you can see two Product Canvases. The first has its focus on a product within two markets, showing the expectations two different customer segments have to the product.

ProductCanvas_2

The second example shows information related to a specific market, Poland, including product architecture and business assessment:

ProductCanvas_1

Relation to other templates:

The Product Canvas Template is inherently related to the Product Architecture, Product Roadmap and Product Variant Master, in the sense that all these models focus on different aspects of the lifecycle of a product. Furthermore, you can create additional Business Charts for the Product Canvas by using the dedicated template. Another view on projects and initiatives are provided from the Enterprise Investment Portfolio. There, the reasoning behind the investment in the project is visualized by connecting the initiative (in this case a new product) to the specific goals of the enterprise that it contributes to. Another view on how the product meets customer needs can be documented in the Value Proposition Canvas.

Properties and metadata: The Product Canvas can for example retain the following information:

  • A description of the diagram
  • Link to the owner of the canvas
  • Link to the one responsible for the canvas
  • Audits (auto generated information regarding its current state and access rights)
  • Associated documents, diagrams and other objects
  • Inherent Risk detailing risk considerations
  • Governance information detailing information about the published diagram and who has been involved in the approval of the diagram

The above picture shows the properties dialogue window for the Product Canvas where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.