By Brett Norgaard
(Part 1 of a 3 part series)
Recently, we participated in and reviewed several deals involving help desk consolidations, platform migrations, system upgrades, and the transitioning of new clients onto the standard service delivery platform. The constant? Change. Movement. The challenge? Service items are tied to, trapped if you will, to the specific instances, version, client (in a multi-tenant environment) or role (development vs. production server) and do not migrate without extensive rework, manual intervention or a complete re-do.
Let’s examine these dimensions of service item portability a little closer. Many service providers have multiple instances of the same version of their service platform. There are many many reasons for this—consolidations of multiple providers, client requirements involving security/privacy/regulatory considerations. Several service providers have reported issues with the reality of moving service items between different instances of the same version of their service platform. Issues tend to arise when “best practice” service items are captured and uploaded to the new, but same version, service platform.
Due to some of the same reasons cited above, many service providers end up with many different versions of the same service platform. Problems start to appear in this case around the upgrade procedures. Many service providers have had to redo vast portions of the service items post upgrade.
Some service providers have intended to offer a standard set of services to a set of clients on a multi-tenant platform. Challenges arise as each client requires customizations including branding and theming. In order to deliver on this promise, service providers have resorted to extensive filtering which adds complexity to the code which move often manifests during upgrades resulting in going back to the drawing board.
One service provider reported that service items created in the test environment were not able to run in the production environment without extensive manual rework.
Two fundamental issues are at work here and conspire against service providers and their service platforms. Multi-tenancy and Self-Service. The major service platforms have concentrated on and solved the back office issues surrounding incident, change, problem and asset management. Today, each client wants service their own way. This means that they demand a unique experience—incorporating self-service, co-creation of services, and a more engaging overall experience. This is a challenge of the front office, client-facing part of the application. The usual programming and customizations of the past era no longer solve but instead work against service item portability. In our next entry, we will explore how a secure, configuration driven strategy addresses the issues of multi-tenancy, self-service with a unique experience for all.
Cassy Lueneburg