Explique mecanísticamente la formación de 4.223.

Services, Groups and Service Contracts are the three Model Components Types (or Component Types). Collections of Components of the three types make up an Organisation (as shown in Figures 32 and 33, below). The Component Types are defined as follows:

Services are the units of work performed by the Organisation. Groups represent Organisation entities/resources.

Service Contracts define work expectations for the Organisation, its personnel and the Client.

5.3.1 Component Relationships

Figure 32: Basic Model Component Relationships

Figure 32 shows the relationships between the three Model Component Types. The

relationships between Component Types are shown by the lines between them, with the dotted end indicating that that Component Type is associated with the Component Type at the non-dotted end. This means that Services are associated with Groups and Service Contracts, not the converse.

The relationship between Services and Groups is 1 to 0...many, meaning that each Service is allocated to 0, 1 or more Groups. The case where a Service is allocated to “0” Groups is where the Service exists but is not being offered or used. Services that are being offered are allocated to “1 or more” Groups.

The relationship between Services and Service Contracts (“Contracts”) is 1 to 1, meaning that each Service is associated with exactly “1” Contract.

The association between Services and Groups embodies the Group Based Services FMC. Group members (including Sub-Group members) can perform the Services that are associated with the Group. This associationrelationship controls who (which Groups) is allowed to do what (which Services). In other words, it controls which Groups do which Services.

The Contract Based Services FMC (see Figure 31) is embodied in the association relationship between Services and Service Contracts. Services can only be performed in accordance with the associated Service Contract. This association relationship defines the expectations of ServiceDelivery.

The combination of the Service-to-Group and Service-to-Contract associations defines how Groups do Contracted Services.

5.3.2 Organisation Composition

Figure 33 shows how an Organisation is composed of many Groups, Services and Contracts, and the relationships between them. The solid lines show the Basic Component Relationships between Services and Groups, and Services and Contracts (the type shown in Figure 32). The dotted lines reveal the relationships between Components of the same type: Group/Sub-Group relationships, Service/Sub-Service relationships and Contract/Sub-Contract relationships.

The “Organisation Icon” in the “Organisation” column represents the entire Organisation. The Organisation itself is defined by a single Global Group (the Organisation is a global entity), the Organisation Group, represented by the large icon at the top of the “Group” column. The Organisation Icon shows the Sub-Groups of the Organisation inside the Organisation Group together with the associated Services and Contracts.

5.3.3 Component Origin

The Model is based on the idea of reusing Components. This means having Global Components that can be copied and modified as necessary to meet local requirements. The concept of Global Groups was discussed at 1.6.3 and 4.4.5, but Services and Contracts can also be global; for instance, consider the need for global standards for online businesses.

In view of this, the Model employs three hierarchical structures, one for Services, one for Groups and one for Service Contracts (as shown in Figure 34, below). At the top level of each hierarchy are Base Components for a Base Service, a Base Group

and a Base Service Contract. These Base Components are the Model Components which would be at the level below the “Object” Class in Object Oriented Programming (OOP) terms. There is one Base Component for each Component Type.

Each of the three Component Hierarchies has five Level Types (“Base”, “Type”, “Specific”, “Configured” and “Tailored”). The top three levels contain Components that are stored globally, while the bottom two levels represent Components for individual Organisations. The diagram is symbolic only as its purpose is to portray

multiple levels. In practice, each Component can have 0…many children and each level can have 0…many sub-levels.

Figure 34: Component Hierarchies

The fundamental idea is to have repositories of Components stored on the “Global” level that can be used (copied) by individual Organisations and configured and tailored to meet their individual requirements. It is also possible for Organisations to

upload their Components into the repositories so that they can be used by others. This facilitates the evolution of templates, organisational structures and business management techniques.

As well as individual Group, Service and Contract Components, whole

Organisational Templates can be created and stored, as shown in Figure 34. These can be copied to provide New Organisations with ready-made “Start-up Systems”. For example, a new florist business could copy an Organisational Template for a typical florist containing appropriate Services, Groups and Contracts. The Organisational Template can then be modified (configured and/or tailored) to meet individual business needs.

The collection of imported and modified Components and the relationships between them form the foundation of an Organisation’s System. The running of the Organisation, which involves the creation and management of Client-Services, is built on this foundation.

5.3.4 Component Instances

The System that implements the Model, the CMS, is essentially composed of two types of elements, Components and Component Instances.49 The Components(and the relationships between them) represent the management structure of the Organisation, and the state of the Component Instances represents the state of the Organisation.

The Components are imported and modified as necessary when the Organisation is created. They can be added to and modified over time as the management structure evolves. Their state, however, is relatively “static”.

Component Instances represent the state of the work that the Organisation is performing. This is in constant flux and is thus “dynamic” in nature.

An example of a Component is a “House Painting Service”. An Organisation can offer this Service to customers, who when they accept the Service become Clients of the Organisation. Now for John to get his house painted by the Organisation he must firstly be offered and then accept a House Painting Service (that is, accepting a contract for the provision of the Service by the Organisation). On acceptance, the CMS will generate a new instance of a House Painting Service. This is a Component Instance. Every time a customer accepts a House Painting Service a new Component Instance is generated. The CMS manages each of these instances and, at any particular time, each instance will be at a particular stage of completion. So, in terms of Components and Component Instances, there is exactly one House Painting Service Component and many Component Instances. This is typical.

The CMS uses a Component as a template for the generation of Component Instances.50 More specifically, a Service is a template for making Client-Services, a Group is a template for making Client-Service Groups and a Service Contract is a template for making Client-Service Contracts.

In technical IT (OOP) terms, Components are like Object Classes, Component Instances like Objects (that are instances of an Object Classes), Component Instance Data like Object Attribute values and ServiceTasks like Object Methods. As Object Classes are hierarchical, so too are Components. A CMS can therefore easily be programmed using an OOP language like Java.