Manufacturing Routing Network

Purpose: The purpose of the Manufacturing Routing Network is to specify the steps used in manufacturing a product. Below is an example of a Manufacturing Routing Network of an Item including Assembly, test and final control. At the right-hand side, you can see that different specifications have been attached as well:

ManufacturingRoutingNetwork_2

Core concerns: The Manufacturing Routing Network template enables you to model Work Operations, Products, Business Objects, General Concepts, and Production Lines. You are also able to distinguish between Activity Paths, Assembly Flows and Transport Systems. If you wish to attach External Documents, they should be attached to the Work Operations they pertain to. Below is another example of a Manufacturing Routing Network that describes the process from assembly to shipping:

ManufacturingRoutingNetwork_1

Relation to other templates: The Manufacturing Routing Network template is related to the various different models for products such as the Product Viewpoint template, the Product Variant Master template, the Product Rule Table, the Product Roadmap and the Product Canvas. Each template offers a different viewpoint of the product in various stages of its lifecycle.

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

 

Lifecycle Assessment Diagram

Purpose: The purpose of the Life Cycle Assessment Diagram template is to document the relations for an activity or product in a lifecycle context.

Core concerns: The Lifecycle Assessment Diagram concerns itself with modelling elements in a company that interact with the environment. The template enables you to model Environmental Aspects and Objectives for Activities in your organization. This template allows you to model Business Objects, Activities, Performance Indicators, Business Connection, Goals, Policies, Critical Success Factors, Change Requests and Problems. These elements can be grouped into Categories and connected by Impact Quantity, Recycling, Logistical Flows, Information Flows, and Activity Paths.

Below, you can see an example of a Lifecycle Assessment Diagram for a Product, from production to packaging, focusing on reducing unbiodegradable waste:

The elements used in this example are Business Objects as input and output, Activities showing Logistical Flows and Recycle under Process. Under the Environment Category, Environmental Aspects, Impact and Objectives are identified and Policies for reaching the Objectives are also included. The diagram focus on a single Environmental impact: Waste. You can also choose to map out several Environmental impacts that are relevant to a specific activity or product.

Relation to other templates: The Environmental Aspects and Impacts from the Lifecycle Assessment Diagram can be further explored in the Environmental Impact Diagram. The Lifecycle Assessment Diagram is also related to the Business Process Diagram and Workflow Diagram, in the sense that they all are related to detailing aspects of processes. The Lifecycle Assessment Diagram can also be decomposed from the Inventory object shown in, for example, the Production Site template.

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

For more information: You can learn more about Lifecycle Assessment on the US Sustainable Facilities Tool website or turn to ISO standard 14040.

Hierarchy View

Purpose: The purpose of the Hierarchy View template is to show the hierarchy of objects related to a chosen root object.

Core concerns: The root object in the hierarchy View can for example be a Capability or a Business Process. The view is not modeled as a diagram, but generated based on information specified in the template’s property dialog, making the scope of the view flexible. Below, you can see an examples of a Hierarchy View for the Capability “Market Objects”:

Relation to other templates: The Hierarchy View is not directly connected to any single template but is not unlike a Context View. The Hierarchy View is, compared to a Context View, usually filtered to only show certain types of relations amongst certain types of objects and not as a default connected to diagram templates:

Properties and metadata: The Hierarchy View template can for example retain the following information:

  • A description of the diagram
  • Link to the owner of the Hierarchy View
  • Link to the one responsible for the Hierarchy View
  • Audits (auto generated information regarding its current state and access rights)
  • Specifications (definition of root object and other inclusion criteria)
  • Adjust (specification of templates that should be removed from the view)
  • 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 Hierarchy View template where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

The HierachyView can be used in relation to the Standard Tree View in the HTMLPublisher, to establish a hierarchy for the network of process models in a repository.

Generic Query

Purpose: The Purpose of the Generic Query template is to provide datasets for QualiWare System templates.

Core concerns: The Generic Query template is an auxiliary template. The Generic Query can be created using a Query Design template which enables you to easily structure the query for creating reports. When creating a Report for a diagram, the Generic Query created using the Query Design should be used as a Data Set in the Report Definition.

A Generic Query can also be generated using its Property Dialog, where you can link to Data Source and filter the data selection using a wizard – see example of the property dialog below:

The Generic Query can, for example, take the form of data sheets:

GenericQuery_2

The Generic Query template can also execute a command using the Advanced Query tab:

Relation to other templates: Generic Queries are automatically created when creating a Query Design. Generic Queries are used in the following templates: HTML Template Definitions, HTML Embedded content, HTML Publisher and HTML Content tab.

Properties and Metadata: The Generic Query can for example rentain the following information:

  • A description
  • Audits (auto generated information regarding its current state and access rights)
  • Query Filter, including a wizard for filter options
  • Attribute Definition
  • Advanced Query
  • Matrix Behavior

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

Read more about Query Design and GenericQuery here.

 

Decision Model

Purpose: The purpose of the Decision Model template is to document complex decisions by modelling decision trees that illustrates decision gates. Below you can see an example of a Decision Model:

DecisionModel_1

Core concerns: Complex decisions can be documented as decision trees. The model illustrates the Business Decision and its underlying Rule Families. The Rule Families can contain Rule Family Tables, that precisely describe the outcome of a given set of variables. Below you can see an example of a Rule Family Table:

DecisionModel_2

Relation to other templates: Where the Decision Model template illustrates the decision gates, the end to end process is described in either a Work Flow Diagram or a Business Process Diagram.

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

 

Data Model Diagram

Purpose: The Purpose of the Data Model Diagram template is to model the structure of data entities of an Information System and their relationships. Documenting the structure of information is a very important part of the preliminary analysis before implementing any Information System.

Core concerns: The Data Model Diagram template enables the user to document the structure of the information, that an Information System is supposed to store. The template allows you to model using Data Entities, Subject Area, Data Entity View, Model View and inheritance. The Connection types available are: Data Relation, Inheritance Connection, Complex Relation and Generalization. Below you can see an example of a Data Model Diagram describing the information structure related to an order:

DataModelDiagram_1

Relation to other templates: The Data Model Diagram template should not be used to document data flows. In that case the Data Flow Diagram template should be used.

Properties and metadata: The Data Model 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.

The above picture shows the properties dialogue window for the Data Model Diagram where you can view and edit the diagram’s properties.

 

 

Data Mapping Diagram

Purpose: The purpose of the Data Mapping Diagram is to map data’s sources.

Core concerns: The Data Mapping Diagram template enables you to model Data Entities, Classes, Tables, Records and Mapping Algorithms. These are connected by Data Mappings. The Data Mapping Diagram is sometimes called Entity Mapping Diagram.

Below, you can see an example of a Data Mapping Diagram where data is moved from one table to another transforming from ‘customer data’ into ‘client data’:

DataMappingDiagram_1

The following very simple diagram illustrates the relations between Records and their elements:

DataMappingDiagram_2

Relation to other templates: The Data Mapping Diagram is, through the object Data Transformation, related to the Data Replication Diagram. Data Transformation is contained in the Data Replication Diagram and has a mapping which is described in the Data Mapping Diagram.

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

  • A description 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

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

 

 

 

 

Data Flow Diagram

Purpose: The purpose of the Data Flow Diagram is to document a system’s or part of a system’s data flows; the data input the system (or a process within the system) consumes and the data output the system produces.

Core concerns: The Data Flow Diagram enables you to model Processes, Data Stores, External Entities, Control Processes and Control Stores. These elements can then be connected by either Data Flows or Control Flows.

Graphical representation of the elements:

The Data Flow Diagram can show different levels of processes within a system that exchange data, and illustrate how those exchanges occur. As such, the model can document a system’s functional hierarchies.

Below, you can see an example of a Data Flow Diagram showing the Data Flows between several Data Stores, Processes and External Entities in a Bookshop:

DataFlowDiagram_2

The next example shows the Data Flow between process, Data Stores and External Entities for a Highway Repair Service:

DataFlowDiagram_1

The final example shows the Data Flows between Processes, Datastores and External Entities in an Outlook Mailbox:

dfd

Relation to other templates: The Processes in the Data Flow Diagram can be decomposed into more detailed Data Flow Diagrams to comprise the total functional model. The top level of a Data Flow Diagram is sometimes called a Context Diagram. However, in QLM we use the Data Flow Diagram template for the higher levels as well as the more detailed ones.

The Data Flow Diagram can be a decomposition of an Information System. It can offer a more detailed view of Data Flows than, for example, the Application Architecture Diagram.

An Information System could likewise be decomposed into a Business Process Diagram which offers a complimentary view less concerned with Data Stores and Data Flow, and more concerned with Activity Flow.

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

Dashboard

Purpose: The purpose of the Dashboard template is to publish selections of Business Charts targeting different stakeholders. It should be used to gather a series of relevant or connected Business Charts to provide a dashboard-like overview.

Core concerns: The Dashboard template enables you to gather Business Charts, Key Performance Indicators, Performance Indicators and General Concepts to create stakeholder specific views of analyzed data. For example, an Enterprise Architect could find a Dashboard containing Business Charts relevant to the usage and governance of the Enterprise Architecture useful.

Below, you can see examples of different Dashboards presenting an array of Business Charts:

Dashboard_1

 

Dashboard_2

Relation to other templates: The Dashboard template is closely connected to the Business Chart template, as the Dashboard publishes the charts the Business Chart template generates.

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

  • A description of the Dashboard
  • Link to the owner of the Dashboard
  • Link to the one responsible for the Dashboard
  • 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 Dashboard template where you can view and edit the dashboard’s properties in QualiWare Lifecycle Manager.

Customer Journey Map

Purpose: The Purpose of the Customer Journey Map template is to document the customer’s journey from awareness to the end of their interaction with an organization, covering possible touch points from the customer’s perspective.

Core Concerns: The Customer Journey Map template allows you to model connections between different Personas, Customer Journey Phases, Touch Points, Goals, Roles, Locations, Channels, Technology and the aspects from a SWOT analysis.

You can choose to model both a current state and a desired future state of the customer journey and use the documentation for process improvement. Below is an example of a current state model and a future state model:

Current state model:

CustomerJourneyMap_2

Desired future model:

CustomerJourneyMap_1

Other functionalities: The customer’s touchpoints can be elaborated upon with four scores for Customer Satisfaction, Customer Importance, Customer Effort and Net Promoter Score. Particularly vital touchpoints can be designated as a Moment of Truth.

Relation to other templates: The Customer Journey Map can be used as a groundwork for a strategic change, which for example can be modelled in a Work Model, a Business Capability Model and/or a Strategy Model.

Properties and metadata: The Customer Journey Map 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.

The above picture shows the properties dialogue window for the Customer Journey Map, where you can view and edit the diagram’s properties.

For more information: on Customer Journey Mapping, please view our webinar Experience Mapping – Customer Obsession for IT and Digital Professionals with Milan Guenther and Katharina Weber.