Three ways to deal with the concept of data i.r.t. service and management system

Last week, I got a call from a government architect who, in a discussion with colleagues, failed to answer the following question: "How does the concept of data relate to the concepts of service and management system?"

My answer to this question was easily generated with USM.

But let's first agree on the terminology that is used

First, we need to agree on what we mean by the service provider's 'management system'. USM defines this term as follows.

"The management system is the coherent set of organizational resources for the effective and efficient realization of objectives of the organization."

The management system refers to the service-providing system in a customer-provider relationship. In that relationship, the provider makes a facility available to a customer, and supports that customer in using that facility. Hence the universal definition of the term 'service':

"A service is a supported facility."

Service delivery is then the provision and support of facilities with which the customer creates value in its own environment (its 'business'). Facilities are 'the things' the customer gets from the provider, and a facility is always a mix of goods and actions - in any line of business.

So what is the role of data in service delivery?

The role of data depends on the context. I distinguish three situations.

[1] In the context of service delivery, you may find an information processing service, aka an information service or an IT service. A customer (or user) of such a service uses a facility to process data (CRUD: create, read, update, and delete). That data is then the property of the customer and is therefore not part of the facility and as a consequence also not part of the service and neither part of the provider's management system. After all, the customer uses the information processing facility to process his own stuff (in this case his data).

By comparison: if you hire a truck to move your furniture, your furniture has not suddenly become part of the service ('furniture transport') either. By the way, regarding the term 'information processing': bearing in mind the DIKW hierarchy, most of the time information processing is actually data processing.

So, in case we are talking about this customer data, that data is outside the scope of the supported information processing service. Data is then simply something that is owned by the customer.

It's also possible that the customer (user) voluntarily transfers ownership of submitted data to another party. The situation then still applies. Ownership is not the determining factor here, use is.

[2] Things are different when the data is part of the facility. You can imagine a provider making a dataset available to the customer so that the customer can use that data set in his business. Think of the national postcode register. In this second case, that data set is part of the facility, and therefore also part of the service. This positions that data outside the scope of the service provider's management system: the service provider creates the data set with his management system and makes it available to the customer as part of a supported facility.

[3] As a final option: the provider can use data to create the supported facility (i.e. the service). Consider a facility that contains information, such as a newspaper or a knowledge base. In this case, the data that formed the basis for that information (or in terms of DIKW: the knowledge) is outside the scope of the facility: the data was internally used by the service provider to produce the facilities and only the resulting information was made available in the facility.

In case 3, the question may arise "who created the data?" and the answer may again be based on the very same three options, but now one step further down the supply chain.

A simple explanation based on a simple view

This analysis is based on the building blocks of a simple management architecture, which you can use to set up a simple shared management system for an enterprise service management strategy, based on the Unified Service Management method (USM). One of the building blocks of the USM architecture is a consistent terminology framework: a crucial component of any architecture.

If you want to know more about USM, check out the USM wiki. There, you will find extensive information available in a structured format about the new thinking for enterprise service management. This will help you reduce the overwhelming complexity that has become the result of a load of technology, ineffective best practice frameworks, and inefficient tooling.