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.

 

 

Configuration Diagram

Purpose: The purpose of the Configuration Diagram template is to document a well-defined combination of documents and files to enable an explorer functionality.

Core concerns: The Configuration Diagram template enables you to model Document Categories, External Documents, and Document Revisions (which store references to files containing a revision of an External Document).

The Configuration Diagram should be used to link external documents like CAD-files, word processor documents, spreadsheets etc. including the applications that must be used to view or modify the documents, to the repository.

Other functionalities: Controlling paper documents and their distribution is also possible with this diagram type.

The diagram contains embedded revision control of the external documents. This functionality is based on the following placement of the repository related documents:

Directory structure example:
c:\qwc\
. db\…
. demos\…
. guides\…
. models\…
. Projects\
. . repdb1\…
. . repdb2\…
. . …
. . repdbx\
. . . in\…
. . . out\…
. . . Docs\< here are all related documents placed >

Relation to other templates: The Configuration Diagram can be contained in a Workflow Diagram, be linked as ‘Relevant Documentation’ for a Project Activity and be a decomposition of a Business Scope.

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

 

Conceptual Data Model

Purpose: The Conceptual Data Model template is used to describe a high-level business oriented structure of the information concept used in a specific business area. Below yo can se an example of a Conceptual Data Model where the data is divided into data for internal and external use:

ConceptualDataModel_2

Core concerns: The conceptual data model template enables you to model a preliminary high level data model. It may be abstract in content and sparse in attributes. Its preliminary structure allows for many-to-many relationships. When using the Conceptual Data Model, you can model Information Concepts, Subject Areas, and their interrelationships. Below, you can see a car rental service’s Conceptual Data Model for a customer’s data.

ConceptualDataModel_1

Relation to other templates: The conceptual data model is a means of communicating information structures between participants in a project or documenting the overall Information Concept of a specific organization. For a more detailed model you should use a Data Model Diagram.

Properties and metadata: The Conceptual Data Model can for example retain the following metadata:

  • 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 Conceptual Data Model’s properties dialogue window, where the information can be viewed and edited:

Concept Model

Purpose: The purpose of a Concept Model is to organize an enterprise’s vocabulary to support cPonsistent and unambiguous communication about specific problem domains across business units.

Core concerns: The Concept Model template enables you to model Concepts, Specialization Aspects and Subject Areas. They can be linked by Concept Associations, Concept Aggregations, Concept Generalizations, Type Relationships, and Relationship Constraints.

You are also able to link the diagram to its area of usage through the model’s property dialogue. This area of usage can by default be set to be either an Organization Unit, Role, Actor or External Entity.

Below you can see some examples of Concept Models from a healthcare domain:

The model above shows the concepts related to the healthcare activity ‘knee arthroplasty’. The model below shows the concepts related to a signature in the healthcare domain:

ConceptModel_1

The model above shows the concepts related to the healthcare activity ‘knee arthroplasty’.

The model below shows the concepts related to a signature in the healthcare domain:

ConceptModel_2

Relation to other templates: A Concept Model should enable the identification of the right terms to use in communications where high precision is needed. This is useful when creating large sets of business rules or processes that need to fit together without ambiguity and when creating complex Data Models. As such, it could be advantageous to link to a concept model from the affected Business Process Networks, Workflow Diagrams, Requirements Models and Regulation Diagrams.

Properties and metadata: The Concept 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
  • Link to view of area of usage
  • 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 Concept Model, where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

For more information: to learn more about Concept Models, you can read the following article:

Ronald G. Ross , “What Is a Concept Model?” Business Rules Journal Vol. 15, No. 10, (Oct. 2014). URL: http://www.brcommunity.com/a2014/b779.html

Composite Structure Diagram

Purpose: The purpose of the Composite Structure Diagram template is to document the internal structure of a class, Class interactions with the environment and behavior of collaborations. The Composite Structure Diagram is part of the UML version 2.5.

Core concerns: The Composite Structure Diagram enables you to model Collaborations, Collaboration Use, Properties, Classes, Interfaces and Ports. These elements can be connected by Connectors, Dependencies, Interface Realizations and Usage.

Below, you can see an example of a Composite Structure Diagram for a car safety inspection:  

The Diagram shows internal structure of the Car-safety inspection class as well as the behavior of collaborations and the different classes’ interactions.

Relation to other templates: The Composite Structure Diagram is part of the UML templates QualiWare supports along with the Activity Diagram, Communication Diagram, Deployment Diagram, Class Diagram, State Diagram, Package Diagram, Component Diagram, Sequence Diagram, Use case diagram and Timing Diagram.

The Composite Structure Diagram can be defined as the components content along with the Component Diagrams, Class Diagrams, Classes, and Interfaces. The Component Object is a representation of a physical part from the system specification.

Properties and metadata: The Composite Structure 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
  • Extensions (Stereotypes, constraints and tagged values)
  • 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 Composite Structure Diagram where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

For more information: about the UML, please visit the Object Management Group’s Website, where you can find the complete specification.

Component Diagram

Purpose: The purpose of the Component Diagram is to specify the structure of and dependencies among the different components that make up a system.

Core concerns: The Component Diagram template enables you to model a system’s Components, Classes, Interfaces, Packages, Artifacts and Ports. They can be connected by Dependency, Interface Realization, Component Realization, Usage, Generalization or a generic Connector. Below, you can see an example of a simple Component Diagram consisting of Components connected by Dependencies.

ComponentDiagram

Using the properties dialogue, you can identify extensions such as Stereotype, Constraints and Tagged values:

Relation to other templates: The Component Diagram is part of the Application domain and shows how a system is structured. To model how users interact with a system you should use a Use Case Diagram, to model how interactions with the system through processes you should use the Sequence Diagram template. To model the structure of an application landscape you should use the Application Architecture Diagram.

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

Communication Diagram

Purpose: The purpose of the Communication Diagram template is to document interactions between objects or parts, focusing on sequenced messages.

Core concerns: The Communication Diagram template is a simplified UML 2.0 alternative to the UML Collaboration Diagram. It enables you to model Lifelines and Annotation, which can be connected by messages.

Below you can see a simple example of a Communication Diagram:

CommunicationDiagram_1

Relation to other templates: Usually, Communication Diagrams would be modeled using information from Class Diagram, Sequence Diagram, and Use case diagram. It is related to the other UML interaction diagrams: Sequence Diagram, Interaction overview diagram and Timing Diagram.

While the Communication Diagram show much of the same information a Sequence Diagram does, the Communication Diagram conveys which elements each one interacts with better, while sequence diagrams show the order in which the interactions take place more clearly.

Other UML diagrams that QualiWare support include: Activity Diagram, Communication Diagram, Deployment Diagram, , Composite Structure Diagram, State Diagram, Package Diagram, Component Diagram, Composite structure Diagram, and Object Diagram.

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

  • A description of the diagrams
  • Link to related sequence diagram
  • Extensions (Stereotype, Constraints and Tagged values)
  • 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 Communication diagram, where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

For more information: about the UML, please visit the Object Management Group’s Website, where you can find the complete specification.

Class Diagram

Purpose: The primary objective of the Class Diagram template is to visually represent and document the structural components of a system utilizing the Unified Modeling Language (UML). Displayed below is an example of a straightforward Class Diagram:

ClassDiagram_2

Core concerns: The Class Diagram effectively captures the various classes within a system, their attributes, operations, and the relationships between classes and other objects, such as packages. This comprehensive representation enables a clear understanding of the system’s structure, promoting efficient communication among stakeholders and facilitating system design and maintenance.

Example: In the Class Diagram below, the relationships between the classes “Customer” and “Internet User” and the packages “WEB-API”, “Reservation Control”, “GUI” (Graphical User Interface), and “Database” are illustrated. This example highlights the connections among different components and provides a visual overview of how they interact within the system:

ClassDiagram_1

Relation to other templates: The Class Diagram presents a detailed structural view of information. It can for example be a decomposition of an Information System which typically is presented in an Application Architecture Diagram. If a Class Diagram becomes too complex or large, a Package Diagram, where the classes are grouped into Packages, could be modelled instead.

Properties and metadata: The Class 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)
  • Extensions regarding constraints and tagged values
  • 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

In the picture below you can see the Class Diagrams properties dialogue window, where the information can be viewed and edited:

 

Business Process Network

Purpose: The purpose of the Business Process Network is to at document a mid- to high-level view of Business Processes and their interrelationships.

Core concerns: The Business Process Network template enables the documentation of top to mid-level processes. The core objects available to model with are Business Processes, Business Events, Business Objects, Business Scope, Information Systems, and different types of connections. Below you can see two examples of a Business Process Network modelled in different styles.

High level process view without business events or connections between processes:

BusinessProcessNetwork_2

High-level process view where business events and connections indicate a flow between processes, stakeholders and customers:

BusinessProcessNetwork_1

Relation to other templates: The top-level processes would typically be broken down to one or more levels of mid-level processes. The last level of Business Process Networks can then be broken down to several Workflow Diagrams or Business Process Diagrams detailing the activities contained within the business process

Properties and metadata: The Business Process Network can for example retain the following information:

  • Description of the diagram
  • Link to the owner of the diagram
  • Link to the one responsible for executing the processes in 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

In the picture below you can see the Business Process Network’s properties dialogue window, where the diagrams properties can be viewed and edited:

Business Process Diagram

Purpose: The purpose of the Business Process Diagram template is to enable workflow modelling using the industry standard BPMN (Business Process Modeling Notation).

Core concerns: The Business Process Diagram template supply you with the BPMN icons that enable you to draw a workflow diagram. These icons include different types of events, activities, gateways, connectors, as well as pools, lanes and artifacts such as data objects and messages. The Business Process Diagram is typically used to illustrate business processes and software processes used in requirement documentation. Below is an example of a classic BPMN diagram with swimlanes:

BusinessProcessDiagram_1

To ensure the right BPMN syntax, the Business Process Diagram template will continuously perform Graphic Syntax Checks while you model. When a graphic syntax error occurs, you will be met with an error message like the one shown below:

Other functionalities: The Business Process Diagram can enable the execution and automation of a process when the diagram is converted into XML type files.

If you don’t wish to have a visible pool in your diagram, you can choose to have a ‘default pool’ that doesn’t have to be graphically represented. You can see an example of a diagram without pool and lanes below:

BusinessProcessDiagram_2

Relation to other templates: The Business Process Diagram template is exclusively aimed at modeling using the BPMN standard. If the BPMN is not chosen as a mandatory standard, the WorkFlow Diagram template, which has fewer syntax limitations, can be used instead.

The Business Process Diagram is typically linked as a decomposition of a Business Process contained in a Business Process Network template.

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

  • Description of the diagram
  • Expression and query language
  • Link to the owner of the process
  • Link to the one responsible for executing the process
  • 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

In the picture above you can see the Business Process Diagram’s properties dialogue window, where the diagram’s properties can be viewed and edited:

For more information: about the BPMN standard please visit OMG’s dedicated website.