2. Defining a service
something which supports a business process, something with an outcome and
something which is tangible by the business
● include things such as service requirements & outcomes relating to
performance, availability, reliability, availability
● other elements of a good service design such as disaster
recovery/Continuity arrangements, capacity requirements & operability
requirements
● designed collaboratively with users, business sponsors, business process
owners & technical support teams
4. SINGLE portal
● where all end users can go
to interact with IT,
● to report an issue,
● check knowledge articles
● to initiate service
requests
Users seek simplicity, they
want to engage with a simple
portal through which they can
quickly and easily engage with
services
5. End users are engaged
they understand where they need to
go,
they understand that circumventing
the process is not in their
interests
and risk of untraceable, poorly
structured communication, such as
verbal or email requests, coming
into IT & simply not being logged
This type of inbound work is
impossible to track, trace and
measure
6. filtering process
● follow a route-based
approach, routing
incidents to resolver
teams,
● requests to approval
● fulfilment workflows, etc
● Each incident and request
should follow an
established workflow
If these are understood and
mapped, it’s easier to
introduce efficient ways of
recording, assigning, tracking
and fulfilling them
7. established workflow
● For common service request
types,
● which describes the
approval processes,
● fulfilment tasks,
● who does what and
eliminates the need for
manual intervention
These workflows can be codified
within the service management
toolset, allowing a degree of
automation to the allocation of
work
9. seeking approval
should be an automated workflow task
no justification for an
approval
Ask whether the approval steps required
for your various request types are really
required, and if they are, whether they
could be automated