This is the second part of my previous post.
Communication Management
Back in the days of
shrink-wrapped software, the ISV usually had a single touch point with the customer, i.e. IT. All issues on the customer’s end were addressed by their IT department,
and what they could not resolve would find its way to Support (sometimes,
months later).
But with SaaS this is no longer the case. The customer CIO may have a direct line to the SaaS CEO. IT may be
in touch with professional services, and customer business managers could be speaking
with the Program Management group. The Ops group will inevitably be in touch
with supervisors or IT managers on the customer side, and Sales will have
developed personal relationships with managers on the customer’s side, as they
nurture the relationship to expand the sales in-house. And, of course, the end
users might be in daily contact with Customer Support.
If all these functions
within the SaaS company do not talk to each other, if they do not share the
info about the customers, there is potential for embarrassing situations that
lower customer confidence and loyalty. E.g. imagine a Sales rep calling the customer
to up-sell a service, and that customer informs the rep that the service is
down right now and that he might consider switching to the competition.
The Ops group is the hub
of all the service activity. It deals with R&D, QA, Professional Services,
Customer Support, Sales, the Customers and the Service Providers. It should
initiate and manage daily, weekly, bi-weekly, monthly and quarterly meetings with
the various functions and provide communication channels with the end users and the
customer’s managers.
Communication with
customers takes many shapes and forms. It can be via email, phone calls,
quarterly meetings, an RFO, notifications on the application message board or
via the Status Page web site.
You won’t find ‘Communication
Management’ in any ITIL/ITSM vocabulary, but the importance of it cannot be
overestimated.
Release Management – um, DevOps?
So, we want to upgrade to the newest features or bug fixes. In today’s very complex environments, with multiple
configurations, possibly geographically distributed, some on real servers, some
on virtual ones, the management of a release update could be a grueling task. This
is where automation becomes crucial. This is a growing discipline with many cool products and tools, making strong use of virtualization.
Although it has become the norm in the industry
that DevOps is all about configuration automation scripts, I would argue that DevOps is nine
parts communication, one part automation,
I claim that between Change and Asset Management, with agile
development and Continuous Delivery, Release
Management is not much of a discipline of itself, but part of the orchestration and
conversation between Product, Engineering, QA and Operations.
Operations Intelligence - OI
There are other aspects
of STORM™ that are not covered in this short article (e.g. Churn Management, Cost Management, Service Continuity, Team Building, Product Serviceability), but a crucial derivative of a good STORM solution is Operations Intelligence.
Collecting and compiling
all the reports of the STORM practices in a repository allows the management of
the SaaS vendor to gain insight into the Operation of the company, assess
progress and plan for next steps to improve the overall Service Operations of
the provider.
The executive team must be able to answer questions such as:
- How are we really doing vis-a-vis our SLAs?
- How long since our last downtime?
- What do we invest our next dollar in?
- What are the main causes of our customer churn?
- How many changes have succeeded, failed, rolled-back?
- Which components are most troublesome?
- What customers might be affected by changes to this particular asset?
- How are our TOP 10 customers fairing?
- Are we improving with our incident management?
- How do the last twelve trailing months look like?
The ability to gain
insight into the various aspects of the Service Operations allows to plan more
sensibly, focus efforts and resources where needed and improve the clockwork,
therefore improving customer satisfaction and loyalty
The Dummies
The title “STORM™ for Dummies”,
is not just a marketing play on the ‘X for Dummies’ series – there is a
philosophy behind it as well. Software developers are bright, creative,
out-of-the-box thinkers that may disregard the rules in search of a better
solution. Smart, creative people do not necessarily make a good operations
team.
Service Operations is a routine,
day-to-day, unimaginative process. You want to have the best people at your
disposal and to have them respond in creative ways to unexpected events. But,
you want to reduce the unexpected events to a minimum and make sure you cover
all bases. And when an unexpected event does occur, you want to make sure that
lessons have been learned, so that next time it will become part of the
routine.
The Dummies will benefit
from the fact that all they have to do is follow a rigorous routine, so they
can go home, have a beer and play with their kids instead of staying around
late and figuring out creative ways to deal with the current crisis (now tell
me, who is the dummy?).
2 comments:
Great one!
Thanks for the insightful post!
Post a Comment