Template Type: Web-Modeler Enabled Diagram

ActivityMap:EDGY

Purpose: The purpose of the Activity Board diagram is modelling what is being done or going on in our enterprise or its ecosystem.

Core concerns: Activities represent something happening that is relevant to our enterprise. This can be something people do, individually and/or collectively (work, entertainment, other ways to spend their time). It can also refer to something happening or going on, events unfolding within our enterprise or outside its boundaries within our ecosystem. They capture the behavior and dynamics of our enterprise over time and enable us to model and map what we do to go about our business and organize ourselves to do so.

The Activity Board is a part of the EDGY language created by the Intersection Group.

Decision Requirements Diagram DMN

The Decision Requirement Diagram shows how a set of decisions depend on each other, on input data, and on business knowledge models.

The Decision Requirement Diagram is a part of the Decision Model Notation (DMN) from OMG.

“The primary goal of DMN is to provide a common notation that is readily understandable by all business users, from the business analysts needing to create initial decision requirements and then more detailed decision models, to the technical developers responsible for automating the decisions in processes”.

 

 

Production Site

Purpose: The purpose of the Production Site template is to provide a model over the content and flow of a production site.

Core Concerns: The Production Site template enables you to model Production Lines, Work Centers, Equipment, Inventory and Fixed Installations. These elements can then be connected by Logistical Flows, Wires or Transport Systems. Below, you can see an example of a ‘Job Shop’ Production Site:

The Production Site can in its property window have its production process environment classified as being either a:

  • “Job Shop” which is characterized by the organization of similar equipment by function such as drilling, welding, painting and assembly. As jobs flow from work center to work center a different type of operations is performed in each center.
  • “Continuous Flow” which is characterized by an uninterrupted flow in the production such as processing of fluids, wastes, powders and basic metals., e.g. and oil refinery.
  • “Dedicated Repetitive Flow” which is characterized by production of discrete parts in a production facility dedicated to only one product.
  • “Batch Flow” which is characterized as a flow shop design producing more than one product. Due to long setup time production is run in large batches, e.g. a brewery where production line needs to be cleaned up between each batch to avoid product contamination from previous product.
  • “Fixed Site” which is characterized by transportation of materials, tools and personnel to a fixed location where the product will be built, e.g. shipbuilding, construction and assembly of item that are difficult to move.

 

Relation to other templates: The Production Site template offers an additional perspective to the Product Architecture, Product Canvas, and Product Roadmap templates. Together, these templates illustrate the different aspects of the production process.

 

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

Work Model

Purpose: The purpose of the Work Model template is to document development methods or project models.

Core concerns: The Work Model template enables you to model Project Activities, Milestones, Results, Quality Controls, Document Structures and Business Scopes. These objects are joined by Connections indicating a flow.

The Work Model template can, for example, be used by Enterprise Architects to document the Enterprise Architecture process from start to finish while covering all the project activities, milestones, and results. The Work Model helps ensure a standardized approach.

Below, you can see a few examples of Work Models utilizing a variety of the available objects:

 

The above model shows a simple project flow enriched with mile stones, results and a quality control.

The above model illustrates another generic model for a software development project – this example has more milestones inserted as well as added document structures containing project deliverable templates.

Relation to other templates: The Work Model template should be used to document project activities – to document business processes and workflows should be documented in Business Process Networks, Workflow Diagrams or Business Process Diagrams.

For a more detailed view of the structure of a project’s results and resources, a Work Breakdown Structure template should be used.

 

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

 

Workflow Diagram

Purpose: The purpose of the Workflow Diagram template is to document the Business Processes of an enterprise at the activity level.

Concerns: The Workflow Diagram template should be used to document the Activities, Roles, Business Events, Activity Paths and Workflow Conditions of a Business Process. Available in the default modeling syntax are also Business Objects, External Objects, Information Systems, Database, Inventory, Information Flow and Logistical Flow. The syntax can be easily extended to include more objects such as Requirements, Business Rules and Goals. Below you can see an example of a Workflow Diagram with multiple Roles that are modelled vertically:

WorkFlowDiagram_2

Relation to other templates: The Workflow Diagram does not support BPMN, if using that notation, you should model in the Business Process Diagram template. The Workflow Diagram can link to other Workflow Diagrams and are typically linked to by Business Process Networks. In the picture below, you can see another example of a Workflow Diagram. Here the Roles are modelled horizontally and you can see the links to and from other diagrams at two Business Events (‘ECR completed’ and ‘Rework’):WorkFlowDiagram_1

Other functionalities: In QLM, you can control which buttons related to risk management are shown below activities. You can choose to hide or show Risks, Controls and Key Controls. Both Controls and Key Controls are a type of Activity. From the Risk related toolbars (available via the “Actions” tab on the right-hand side of the Canvas in QLM) choose the following button to control what button panels appear on the Activity objects:

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

  • A description of the diagram
  • Information on cost and duration of the process
  • 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 Workflow Diagram’s properties dialogue window, where the diagram’s properties 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:

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: