Objects:About Enterprise Ontology - Revision history

Admin at 18:15, 28 October 2015

2015-10-28T18:15:05Z

Admin at 08:45, 20 July 2015

2015-07-20T08:45:45Z

Admin: Admin moved page Objects:About Enterprise to Objects:About Enterprise Ontology: By Request

2015-07-20T08:45:16Z

Admin moved page Objects:About Enterprise to Objects:About Enterprise Ontology: By Request

Ufoldager at 11:43, 17 July 2015

2015-07-17T11:43:44Z

Ufoldager at 11:43, 17 July 2015

2015-07-17T11:43:33Z

Ufoldager at 11:43, 17 July 2015

2015-07-17T11:43:24Z

Ufoldager at 11:43, 17 July 2015

2015-07-17T11:43:12Z

Ufoldager at 11:43, 17 July 2015

2015-07-17T11:43:01Z

Ufoldager at 11:42, 17 July 2015

2015-07-17T11:42:32Z

Ufoldager at 11:42, 17 July 2015

2015-07-17T11:42:06Z

@@ Line 47: / Line 47: @@
 When an organization decides to make use of ontology and semantics to lay the foundation of ‘what we call process things’, it is done so for a vast variety of purposes (we will be naming a few of them throughout this chapter), but the most important purpose is the fact that – once you have established a specific and very clear definition for a meta object, for example – this definition will be available to all the relevant employees across organizational boundaries of the enterprise after is has been documented and published for use. This means that a common understanding and consensus has been reached within the organization for what name a particular meta object has for whenever you’re referring to that particular meta object. This, of course, makes it a lot more practical for organizations to handle objects in the bigger picture. Not just for documenting, but also for using them when modelling, engineering and architecting process concepts and solutions, regardless of business unit and/or business requirement. In the sense of semantics then, it allows you to accurately describe how a particular object relates to another particular object (regardless of object type or hierarchical location). This has to be defined as well, of course, but just like the ontology definitions, an organization must also in semantic relationships reach a common understanding and consensus on how exactly each object relate to another. This is meticulous work and takes time and effort, but it is nevertheless extremely important to avoid common pitfalls.
-So, we now know what to call a particular object, in our case we choose to use the Driver meta object (through the creation of our ontology), and we know how the Driver meta object relate to a Business Process meta object (because we have also defined a set of semantics that accurately describe how they influence and relate to one another). If we would then create a process template where the relationship to a value driver is relevant, we would be able to use the Business Process meta object and place it in the process template, both for information and documentational purposes as well as the ability to further on relate it to other aspects. We would most likely be identifying and listing (for example in columns in an excel spreadsheet) values such as the name of each Business Process meta object, where it is located, what resources it uses, etc. Maps are always used within the concept of the BPM Way of Thinking, which is the starting point, where the conceptual aspects are covered. It is at this planner’s view we generate and describe business concepts, document important and essential information around the business, and we create a general overview of more or less anything of importance.
+So, we now know what to call a particular object, in our case we choose to use the Driver meta object (through the creation of our ontology), and we know how the Driver meta object relate to a Business Process meta object (because we have also defined a set of semantics that accurately describe how they influence and relate to one another). If we would then create a process artefact where the relationship to a value driver is relevant, we would be able to use the Business Process meta object and place it in the process artefact, both for information and documentational purposes as well as the ability to further on relate it to other aspects. We would most likely be identifying and listing (for example in columns in an excel spreadsheet) values such as the name of each Business Process meta object, where it is located, what resources it uses, etc. Maps are always used within the concept of the BPM Way of Thinking, which is the starting point, where the conceptual aspects are covered. It is at this planner’s view we generate and describe business concepts, document important and essential information around the business, and we create a general overview of more or less anything of importance.
 Continuing from this path, we would next create a process matrix for the purpose of relating the value drivers meta object (in a row next to the columns in the excel spreadsheet) to the relevant Business Process meta object. Matrices are almost always created within the concept of the BPM Way of Working, because it is here we begin to actually take action and relate objects to each other. And keep in mind, that whenever you’re creating a matrix, you are actively using the information provided to you through the previous creation of a process map. The map provides you with the information that you need to create an efficient process matrix. By creating a process matrix, we then allow ourselves to directly and accurately identify which kind of value driver (whether internal or external) has an impact to the business process (regardless of impact type, although it has to carry some importance because we expect to note down information that impacts the business somehow, and bearing that in mind, it is therefore worth documenting) on the business processes of the organization (regardless of business unit). Not only do we describe which value driver impacts which business process, we could also identify exactly how the value driver impacts the business process, where the impact occurs, what are the consequences, and who is responsible (role object) and who is accountable (owner object) for acting upon this knowledge.
 Last, but not least, we could – if deemed necessary and/or beneficial – create a process model to build a visual representation of how these value drivers would impact the business processes of the organization. Process models, as the name implies, are mostly used within the concept of the BPM Way of Modelling. It is here that we illustrate (visually) behaviors, relationships, connectivity, location as well as function and purpose. But keep in mind, however, that a model always makes use of both the process map and the process matrix. The map and the matrix is your source of information, the model is how you would visualize this information.
-As you can see, this is why the BPM ontology and semantics have real business value, because you have put down definitions of what (ontology) the objects are, and how (semantics) they relate to other objects. And as you can possibly imagine, this is an absolutely essential piece of information for any process expert (process modeller), process engineer and/or process architect in their daily work. This is also the foundation and the reason that our process templates are 100% standardized and integrated with each other, enabling the ability to share process objects across various process templates.
+As you can see, this is why the BPM ontology and semantics have real business value, because you have put down definitions of what (ontology) the objects are, and how (semantics) they relate to other objects. And as you can possibly imagine, this is an absolutely essential piece of information for any process expert (process modeller), process engineer and/or process architect in their daily work. This is also the foundation and the reason that our process artefacts are 100% standardized and integrated with each other, enabling the ability to share process objects across various process artefacts.
 [[Category:Enterprise Ontology]]
 {{DISPLAYTITLE:About Enterprise Ontology}}

← Older revision		Revision as of 08:45, 20 July 2015
Line 53:		Line 53:

	[[Category:Enterprise Ontology]]		[[Category:Enterprise Ontology]]
−	{{DISPLAYTITLE:About Enterprise}}	+	{{DISPLAYTITLE:About Enterprise Ontology}}

@@ Line 5: / Line 5: @@
 As ontology formally represents knowledge as a set of concepts within a domain, and the relationships between those concepts, it can be used to model a domain and support reasoning about concepts. The Global University Alliance has used the concept of ontology as both a shared vocabulary and the very definition of its objects and concepts. In order to go the next steps and fully use the potential of its ontology.
-[[File:Ontology Reference Content - Enterprise Ontology Concept.png|1200px|thumb|left|Enterprise Ontology]]
+[[File:Ontology Reference Content - Enterprise Ontology Concept.png|1200px|thumb|none|Enterprise Ontology]]
 Ontology Reference Content - Enterprise Ontology Concept

@@ Line 5: / Line 5: @@
 As ontology formally represents knowledge as a set of concepts within a domain, and the relationships between those concepts, it can be used to model a domain and support reasoning about concepts. The Global University Alliance has used the concept of ontology as both a shared vocabulary and the very definition of its objects and concepts. In order to go the next steps and fully use the potential of its ontology.
-[[File:Ontology Reference Content - Enterprise Ontology Concept.png|1200px|thumb|right|Enterprise Ontology]]
+[[File:Ontology Reference Content - Enterprise Ontology Concept.png|1200px|thumb|left|Enterprise Ontology]]
 Ontology Reference Content - Enterprise Ontology Concept

@@ Line 5: / Line 5: @@
 As ontology formally represents knowledge as a set of concepts within a domain, and the relationships between those concepts, it can be used to model a domain and support reasoning about concepts. The Global University Alliance has used the concept of ontology as both a shared vocabulary and the very definition of its objects and concepts. In order to go the next steps and fully use the potential of its ontology.
-[[File:Ontology Reference Content - Enterprise Ontology Concept.png|1200px|thumb|center|Enterprise Ontology]]
+[[File:Ontology Reference Content - Enterprise Ontology Concept.png|1200px|thumb|right|Enterprise Ontology]]
 Ontology Reference Content - Enterprise Ontology Concept

← Older revision	Revision as of 08:45, 20 July 2015
(No difference)

← Older revision		Revision as of 11:42, 17 July 2015
Line 4:		Line 4:

	As ontology formally represents knowledge as a set of concepts within a domain, and the relationships between those concepts, it can be used to model a domain and support reasoning about concepts. The Global University Alliance has used the concept of ontology as both a shared vocabulary and the very definition of its objects and concepts. In order to go the next steps and fully use the potential of its ontology.		As ontology formally represents knowledge as a set of concepts within a domain, and the relationships between those concepts, it can be used to model a domain and support reasoning about concepts. The Global University Alliance has used the concept of ontology as both a shared vocabulary and the very definition of its objects and concepts. In order to go the next steps and fully use the potential of its ontology.
		+
		+	[[File:Test.jpg]]

	[[File:Ontology Reference Content - Enterprise Ontology Concept.png\|1200px\|thumb\|Left\|Enterprise Ontology]]		[[File:Ontology Reference Content - Enterprise Ontology Concept.png\|1200px\|thumb\|Left\|Enterprise Ontology]]