Audit Program

The Purpose of the the AuditProgram template is to plan audit programs.

You can create an AuditProgram from the Compliance Desktop on the Web, or via the Repository Explorer.

An auditprogram have a dedicated focus, e.g. “ISO9001 audits Q3-2022” and collects a set of audits each having their own details and governance flow, cf. the QualityAudit-template.

 

Performance Diagram

Purpose: The purpose of the Performance Diagram is to provide a view over an organization’s performance in reaching their strategic goals.

Core concerns: The Performance Diagram enables you to model Key Performance Indicators – which can be related to strategic goals, derivative Performance Indicators and Derivation Rules. You can create a Performance Diagram as a decomposition of a Key Performance Indicator and model a hierarchy of performance diagrams. The model below shows an overview of an organizations Key Performance Indicators and their status:

In the following model the Key Performance Indicator has been enriched with derivative performance indicators explaining in more details the status of the performance and how it is measured:

The overview of the Key Performance Indicators can also be presented with a simplistic view, highlighting their status using color coded icons:

Relation to other templates: The Performance Diagram is a Strategic template and can be decomposed from Key Performance indicators contained in, for example, a Balanced Scorecard Diagram or Dashboard.

 

Properties and metadata: The Performance 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
  • 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 Performance Diagram where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

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:

Value Proposition Canvas

Purpose: The purpose of the Value Proposition Canvas template is to document the fit between specific customer segments and the value proposition targeted at them.

Core concerns: The Value Proposition Canvas template enables you to model Value Propositions and Customer Segments and populate them with objects by extending the modelling syntax (right click on the canvas, choose ‘Actions’ and then ‘Extended syntax’):

Below, you can see an example of a Value Proposition Canvas that has been populated by Objectives, Opportunities, Threats and Technology:

Relation to other templates: The Value Proposition Canvas is closely connected to the Business Canvas and should be seen as a more detailed view of elements from the Business Canvas’ Customer segment and Value proposition. As such, there could be multiple Value Proposition Canvases attached to a Business Canvas.

In a more general sense, the Value Proposition Canvas is a strategic model that should be viewed in relation to the enterprises Strategy Model, Enterprise Investment Portfolio and Strategic Roadmap.

Properties and metadata: The Value Proposition 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 Value Proposition Canvas where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

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:

Rule Family Table

Purpose: The Rule Family Table template is used as an auxiliary template to document Rule Family symbols from Decision Models in more detail.

Core concerns: The Rule Family Table template should be used to model Rule Family symbols in more detail, describing the decision in more detail and listing each eventuality relevant to the Rule Family. Each row represents a possible combination of rules in the Rule Family. For example, in the eventuality that there are 3 rules with 2 possibilities each, there will be 2^3=8 rows in the Rule Family Table. Below are two examples of Rule Family Tables:

RuleFamilyTable_1

RuleFamilyTable_2

Relation to other templates: The Rule Family template is used to detail Decision Models and should not be used to document decisions in a stand-alone context. It should always be used as an extension to Rule Family symbols.

Properties and metadata: The Rule Family Table 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 Rule Family Table’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:

 

 

Regulation Diagram

Purpose: The purpose of the Regulation Diagram template is to document those regulations the enterprise is subject to in detail, so it can be identified how the enterprise must adhere to them.

Core concerns: The Regulation Diagram template can model Regulations, Licenses, Business Scopes, Activities, Business Objects and their Connections. With this pallet of objects, you can model an overview of the regulations your organization must adhere to and break them down to more detailed diagrams describing their paragraphs. We recommend you keep it simple and link the regulations to the relevant Business Processes rather than modelling them in a complex diagram. Below, you can see two example of how you could model a Regulation Diagram for the ISO 9001:2008 standard:

RegulationDiagram_2

RegulationDiagram_1

Relation to other templates: As mentioned, the regulations can be linked to the relevant Business Processes or Activities, that typically are detailed in a Workflow Diagram or Business Process Diagram. The Regulation could then be shown as a link below the relevant Business Process or Activity:

How the enterprise will live up to the requirements from the different regulations can also be modelled in a Requirement Model.

Properties and metadata: The Regulation 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 Regulation Diagram’s properties dialogue window, where the properties can be viewed and edited: