One of the biggest challenges I’ve been asked was how Salesforce set up their Service Management program. I can tell you that it wasn’t easy nor was it a straight line, but I’ll give it a shot in a multi-part post.
At the beginning, we measured different “Services” which really meant what apps were supporting the basic functions of the business. For example, if Gmail went down, we’d contact our Google admin, and we could measure how well the Gmail service performed. At the end of the day our “services” were mainly an application list.
But then the problem became a little more complex. How could we keep our Business stakeholders notified and how could we link the various applications and their owners accountable too? We then thought to distinguish Services, or the business processes, and the Technologies, which were the applications, infrastructures, and vendors that supported them. The relationship would be that a Service could be supported by multiple Technologies, and a Technology could support multiple Services. While this made the data model harder to design, it actually gave us really good visibility as to what was happening in the Organization.
Soon we were overwhelmed with Services, so we came up with a third category called Capabilities (The “CEO” view). This would summarize the business with around 10 or so Capabilities to complement the 60+ so Services. We also ended up with hundreds of Technologies.
The end output could be seen in our visual browser:
Here you can see that no matter where we browse, we can see the full Operational map of Salesforce, whether it is our Capabilities (like R&D, Sales or HR functions), to the actual business processes (like BI Reporting or Recruiting), to the applications and integrations that support those functions.
Not only that, we are able to see who to contact. Let’s say a workday integration goes down, in the example picture above, we are able to contact both the Technology Manager for the integration as well as the Service Manager, but it keeps going up. Workday supports Recruiting, we are able to contact the Business Owner of the Recruiting business function as well, not only to notify them of an issue, but also to set up future root cause analysis tasks to avoid issues from recurring again.
You might also notice, there is a Service Level Target listed in this web of data as well. In part 2, I will describe how we measure each Service and Technology, from the granular application issues to how it resolves in a simple dashboard for our CEO to view.