Bonus Lesson in a Ten Part Series
By
Given
the points made in the ten lessons learned, you may be wondering what my
strategy recommendation would be for launching a new ITSM platform. Well, as I mentioned, each organization is
different and will have differing levels of ITSM knowledge within it. Similarly, you may have IT executives who
don’t see the value of defining services and CIs prior to launching the
platform. ITSM platforms can be
expensive and executives are eager to show value for money as quickly as
possible. This will most likely
translate in a directive to get “Incident”, “Problem”, and “Change” launched ASAP. There may be no change management system currently
in place and the organization’s viability depends on getting a handle on
changes in the IT environment. You’ll
need to tailor your approach to the organizational dynamics at play, but give
deference to the items I’ve mentioned above.
If you’re being forced into the market without a properly defined
service catalog or configuration management database (CMDB), setup your service
management processes to allow for the eventual introduction of these
pieces. Keep in mind that a new ITSM
platform can be relegated to simply a “ticketing” system if services and
configuration items are not defined. The
true power of the ITSM platform is “Service” management, not Incident or Change
Management.
If
you’re allowed the time and the money to “do it right” from the beginning,
here’s my recommendation:
-
Phase 1: Discovery, CMDB, & Asset
Management. Many ITSM platforms will
perform a network scan of your environment and automatically discover
configuration items (CIs). When you
first turn this on, it will be like drinking from a fire hose. There will be a lot of data that will need to
be sifted through. Many data points of a
CI will be pre-populated, but these will need to be reviewed for accuracy
against underpinning contracts. You may
see duplicate CI entries. For example,
duplicate entries may be the result of scanning a Windows domain controller
that may not be properly configured or up-to-date. There will most likely be components that
cannot be scanned, or components that can only be scanned upon completion of
appropriate troubleshooting. Some
scanning will require credentials whereas others may be discoverable without
them. There may be add-on components
that you can purchase to make discovery easier.
You’ll want regular scanning to be enabled so that when new devices are
found, appropriate action can be taken.
Using the underpinning contracts, you’ll want to populate warranty,
maintenance, and depreciation information.
A properly setup CMDB and asset management practice will serve as a
solid foundation from which to build your service catalog.
-
Phase 2: Service Catalog, Self-Service
Request Fulfillment. Once you have
all of your IT assets properly defined, you’re now able to use them in the
construction of services to be consumed by your customers. The
“menu” by which a customer can order a service is the “Service Catalog”. Some services are running all the time and
need not be ordered, and some may need to be ordered only once. The key thing to keep in mind is that IT
assets are used in delivering services, so the underlying principle to
developing a service is the mapping of configuration items to business
outcomes. For example, a service could
be “Messaging”, which could entail email, mobile phone, desktop telephone, and
instant messaging. A number of
configuration items are responsible for delivering the “Messaging” service. Development of the Service Catalog involves
mapping these CIs to the “Messaging” service.
Keep in mind that a single CI can be mapped to more than one
service. Once the service is defined,
Request Fulfillment entails the definition of one or many service requests that
can be logged against the defined service. A Service Requests differs from an Incident in
that a Service Request is a request from a customer to run a service as it’s
designed, versus an Incident entails a service being degraded or broken. An example of a service request for the
“Messaging” service would be creation of a new user mailbox.
-
Phase 3: Incident, Problem, Change, and
Release. Only after Services &
CIs are properly defined can true service management occur. As mentioned, you may experience pressure
from executive to skip straight to this step in the deployment of your ITSM
tool. If this is the case, you’ll want
to make room in your process for the eventual introduction of the items in
phases 1 and 2. The proper configuration
of Category, Sub-Category, & Item as discussed in Lessons 2 & 6 becomes
even more important if you’re not allowed to complete phases 1 & 2
first. Again, the goal of this exercise
is to implement “service” management and not simply a “ticketing”
system. You’ll want to ensure that you
have process models created for Incident, Problem, Change, and Release. ITIL foundations will provide you with basic
models that can be tailored to your organization.
-
Phase 4: Project Management (Waterfall & Agile). With a solid ITIL operating platform
established via the first three phases of your rollout, you are now ready to
“bolt-on” project management modules. In
most organizations, the management of an IT project will culminate in the
raising of one or more Requests for Change (RFCs) to implement one or more
releases into the production environment.
Project management modules will assist you in managing these efforts. Having project management as a part of your
ITSM platform will also facilitate integrated resource management across all
work types within IT. The ideal situation
is one in which an IT resource can access a single application (e.g. the ITSM
tool) and see all of their work items.
Whether it’s a trouble ticket (Incident), a Service Request, a Problem,
a task associated with a Change or Release, or a task associated with a
project, your ITSM platform is intended to be the one-stop-shop for all work
within IT. Integrated time tracking will
also facilitate labor capitalization for qualifying work.
-
Subsequent Phases: Service Level Management, Reporting, Governance,
Risk, Compliance, Cost Management, Knowledge & Content Management, and User
Survey. With each of the subsequent phases, you are “tightening the screws”
on your ITSM platform. Increasing
service availability and IT operational efficiency are the overarching themes
while managing risk, enforcing compliance, collecting knowledge, publishing
content, and polling users for satisfaction.
The
approach above is intended to be comprehensive and is the ideal scenario. Rarely do we get to implement exactly how we
want. Don’t let perfection get in the
way of being good enough. In general,
modules are flexible and your implementation can be tailored to your specific
organization’s dynamics.
