Vihreä Ruusu - Information Sharing and Multi-Vendor Delivery

Vihreä Ruusu

Service Governance	Service Level	Processes and Practices
Mode of Operation	Vendor Relations	Availability

Suomeksi

Matti Grönroos CV

Matti Grönroos

Information Sharing and Multi-Vendor Delivery

Customers are often interested in their information stored in the data repositories of the service providers. The interest often concerns the ticketing system or the configuration database, or both of them. A common request is to have access to those repositories.

The most common answer is a polite no.

Obstacles are usually confidentiality and intellectual property rights. No matter how close the customer-supplier relationship is, you don't want to share all the information with your friend. In the real world, the cases usually are complex: A single vendor may have contracts with competing customers and the customer may purchase services from competing vendors. No one wants to appear as the body through which trade secrets are leaked.

Every service provider is afraid of the situation where the customer's trade secret is leaked to another customer through the service provider. Or at least everyone should be afraid.

Similarly, service providers do not want to reveal their secrets to their competitors via their customers. There may be innovations in service delivery methods that you don't want to share with your friends. Quantitative data reflecting the state of the business is seldom wanted to be publicly visible without control either.

An oversimplification of a multi-vendor environment focusing on the essentials could be as shown in the figure below:

Customer A has a contract with vendor X and Y, and B with X and Z. Thus, X has information specific to both A and B. A does not want to share secrets with B and vice versa. Both A and B have information about their vendors, and the vendors do not want the information to be shared with others.

Of course, ticketing systems and configuration databases support selective access to the data. The question is if the data can be separated, if these separation actions are trusted, and if they are properly implemented. The implementation might lead to a very complex setup difficult to keep in a good shape.

Such a limited sharing is usually implemented using replication instead of direct access to the operative systems. There is a private area for the data to share across companies. The replication makes it possible to move data between different systems, if the replicator is capable on mapping the data fields.

However, sharing information is not about technology only.

In particular, the tickets may contain sensitive information which is not wanted or cannot be disclosed even with your own and trusted service provider. For example, there may be information about companies being customers to the customer. The ticket integration may be a point of pain. The ticket integration is nowadays quite a popular operating model: Two or more organizations each having their own ticketing system share the tickets by replication. Thus, there are several incarnations of the ticket kept synchronized. In such an environment, the users and Service Desk agents must strongly be guided to not use inappropriate language nor share confidential information. In some cases, a gatekeeper might be needed to check and edit the text before allowing the ticket to enter the replication path.