Serio Blog

Tuesday, 08 Jan 2008

This is just a very brief follow-up to Duncan's last post, which mentions Known Errors but does not define them.

A Known Error is an output from Problem Management (or more accurately, your Problem Resolution process). For a definition of a problem, click here.

If you think of a Problem as being something you don't understand, think of a Known Error as something you do understand – even if you don't know yet how to fix it just yet.

In the case of a software bug, it would be after analysis of source code and algorithms. In the case of an infrastructure problem it is after carefully verifying the conditions necessary for repetition of the Problem and (ideally) identifying the faulty components.

Known Errors typically have two parts. The first of these is the description of the Known Error itself, showing users or product modules and versions affected. The second is the Workaround and/or Change:

  • Workaround – a way to bypass the fault you've previous described that can be used by Customers.
  • Change – to resolve the underlying Problem.

In practice, many support professionals people seem to raise Known Errors whenever any error condition or bug is proved as repeatable, rather waiting for the Problem to be diagnosed (fully understood). Also, many raise a Known Error even if a Workaround is not currently available – simply to help Incident logging staff.

Known Errors are used during the Incident logging and resolution process, as a source of Workarounds for customers, and as an information resource for Customer-facing Incident handling staff. Because of this, we've made it so that searching Known Errors is quick and painless from Incident logging in Serio Release 5.

Wednesday, 02 Jan 2008

This is an update to the earlier Release 5 post, with more information about new features.

Firstly, the new PocketSerio-i application is available for anyone that wants it on servers hosted at our offices in Livingston (in other words, there is nothing to install). PocketSerio-i allows you to action Incident and Changes (and amend the CMDB) through a web browser on a PDA. It supports any browser, so if you can browse the Internet through your PDA then you should be able to use it just fine. It's designed for the very small screen and low connection speeds that PDAs typically have.

Things you can use it for a sending emails to customers through Serio (so they look and feel just like any other support email), making re-assignments and resolving tickets.

We've also added a single-line Issue Summary field to the logging form, so that you can add a pithy description to each Incident, Problem and Change you log. You can then add this to the subject line of emails you send to customers (which helps remind them what the email is about).

One area in which there has been a lot of Change is Known Errors. Previously, customers devised their own way of recording Known Errors – usually by means of Agent Status A or B.

This will still work just fine in Release 5, but we've brought the Known Error concept more directly into the tool. There is now a Chapter (under Tools) called 'Known Errors' which lists each and every Known Error in Serio, helpfully showing the Known Error Description and Workaround together.

As part of this, we've also extended the popular Service Status HTML web pages with Known Error pages – whenever you add or remove a Known Errors, these pages are updated.

Creation and deletion of Known Errors is now done directly via Action Extensions created specifically for that purpose. When creating a Known Error, you set the Known Error Description (which is defaulted to the ticket description, but can be amended independently) and add the Workaround details – and that's it.

And one final thing, we've made it so that you can view Incidents, Problems and Changes all together in your queue if you wish.

Friday, 14 Dec 2007

Customer Billy asks for help in producing his first management report. He's read our IT metrics white paper and other KPI posts, but writes 'my problem is one of interpreting the data. I've got a lot of data and interpreting it all is doing my head in. My predecessor never did any reports'.

First of all, be clear about why you are writing the report, and who the report is for. Is it for your own benefit to help you manage the IT service more effectively, or is it to show someone else how well or otherwise IT service is managed & delivered? Be absolutely crystal clear in your own mind about this. Having asked Billy about this, the audience is primarily himself and his team.

Right now, their team has a functioning Incident Management and Asset Management process, so this is what Billy should look at first. The next six months will see them define a Problem Management process, and begin work on their Service Catalog.  Both of these will increase the options for reporting.

One of the things that the white paper does is group different types of performance data together. Some of the data is really easy to understand: Input data and Output data. Input data is primarily the raising of Incidents, and Output data is the resolution of those Incidents.

If you are reporting monthly, why not look at 3 things:

  • Incidents logged month-on-month over the past 3 months
  • Incidents resolved month-on-month over the past 3 months
  • Backlog at the end of each month

First of all, you can get all three values from report ES1 – it's an Executive Summary report you'll find in SerioReports – just put in your data range and run it (there is a lot more data there as well, which I'll ignore for now).

Billy's question was about interpretation. So, where's some things you can ask yourself:

Is the number of Incidents logged rising or falling, when looked at month on month? If it's falling then great, if it's rising then try to examine why that is.

Remember some fluctuation is to be expected ('statistical significance') but a significant jump of (say) 15% or more is something to look at more closely..by running more reports. For example, run reports by Problem Area or Department – is one particular technology or use group responsible for the increase? If so, why? (at this point, examination of individual Incident records can often be quite revealing).

When looking at the number of resolutions, is it broadly in keeping with the number of Incidents being logged, or is there a backlog developing? If there is, why do you think this is so?

Asking these questions will help you identify problems, but will also (hopefully) lead you to solutions. As an example from my own career, an increasing backlog (and worsening timeliness of resolution) at a company I once worked at was due to increasing amounts of staff sick leave. I already knew we had problems in this regard, but it was revealing nonetheless to see the results on service delivery (the IT service chart and the sick leave chart correlated).

My own reporting schedules have typically been: run some standard reports (report I always run each month) and then, from time to time, run others to 'dig a little deeper'.

In addition, you can look at timeliness of resolution from a Service Level Agreement perspective (you'll also find this on ES1, amongst many others).

Bottom line: obtain data that reflects your own IT service management disciplines, and apply some though about what this means for your IT service group.

Thursday, 06 Dec 2007

First of all, thanks to Kirstie for filling in on this blog whilst I was away on extended sick leave. Thank you for an informative set of articles on ITIL V3 Kirstie!

My own thoughts are mixed on V3 – some of which was covered in this post on ITIL Qualifications.

Whilst not welcoming everything that has happened with V3, one thing I do welcome is a clearer focus on end-user experience, especially for monitoring. One thing I do see those involved in monitoring focus on is component-based monitoring (such as routers, individual servers) rather than the actual services that they provide to customers.

Now, I'm not saying it's a good thing to monitor individual devices, but the focus, as much as possible, should be on the end user service and experience. If you are producing Availability or Downtime statistics (for examples of which, see our white paper on Availability) then the most important graphs should not be component related, but end-user related. Specifically, I mean that systems that are important to your customers should be the focus – so rather than have Availability graphs that show

Router: Trillian 99%

Server: Zephod 98%

I prefer to see

Payroll System 95%

Sales Order Processing System 99%

(Note: I prefer the second example over the first because the first does not accurately tell me what the end user experience has been. For example, it's not clear if Trillian and Zephod were down at the same time, or different times – so how much downtime did our users experience?)

Which means, in many cases, your Availability statistics are going to be more accurately mined from your Incident data (because you log all your downtime, right?).

Although Command Center users sometimes view that tool as a component-level monitoring application, they usually ignore one of it's most powerful features – it's ability to log-on to websites, interact with them (examining the responses) and logging off again. So, if you deliver web-based services to users, it can act as a thoroughly tireless user, logging on every few minutes, performing the tasks you set it, and then logging-off again – recording the results of this as it does so.

It doesn't deal with AJAX (if you don't know what AJAX is or think it refers to the son of Telamon, a mythological Greek hero, google for 'AJAX Programming'). However, for most websites it works perfectly well.

Adopting this kind of approach to monitoring goes past components, and straight towards the end-user experience.

If you want to find out more, look-up the HTTP functions in the SerioScript reference, which you'll find on the Command Center help menu. The functions are targeted at those who have some familiarity with how web applications work. A worked example is also distributed with the tool.

Wednesday, 28 Nov 2007

This is a follow-up post continuing the introduction to ITIL V3 (George Ritchie is currently away). This week I'm going to talk about Service Operation in ITIL V3.

Quite simply, Service Operation is all about delivering the services to your customers and managing the infrastructure, applications and technologies that support these services.

This can be a real balancing act – and there are a number of conflicting goals that need to be considered. Getting a balance between these conflicting priorities is paramount to successful Service Operation. These conflicting goals are:

  • The internal IT view vs. the external business view
  • Stability vs. responsiveness
  • Service quality vs. Service costs
  • Reactive vs. Proactive Management

The key is to maintain an even balance in each of these conflicts, excessive focus on either side of the scale will result in degradation of service.

The key processes in the Service Operation Phase are:

  • Event Management
  • Incident Management
  • Problem Management
  • Request Fulfilment
  • Access Management

These should all be familiar to you, however previously ITIL dealt with Request Fulfilment, Access Management and Event Management within the Incident Management Process. V3 has cleared up this rather grey area and detailed these processes separately (something I think most people will welcome). I'll discuss each of these briefly below.

Event Management – “An event is a change of state that has significance for the management of a configuration item or IT service.”

An Event tells us that something is not functioning the way it should and causes the logging of an incident. Event management is reliant on monitoring, but it is NOT the same thing as monitoring. Event management lets us know when something has gone wrong, monitoring records information even when there are no problems.

Incident Management – “An incident is an unplanned interruption to an IT service, or a reduction in the quality of an IT service. Failure of a configuration item that has not yet impacted service is also an incident.”

There is a lot of information already in the blog on Incident Management so I won't elaborate on this. Use the search function to find related articles.

Request Fulfilment – “A service request is a request from a user for information or advice, or for a standard change, or for access to an IT service.”

Service requests were a real grey area in ITIL® V2, and many organisations were unsure of whether many of their service requests should be handled as minor changes or as Incidents. ITIL® V3 has attempted to clarify this for us. The purpose of the Service Request process is to allow customers to request and receive standard services. All requests must be logged and there should be a mechanism for approval in the process.

(And as an aside, the next release of Serio is almost certainly going to reflect this change in ITIL with a direct and clear way of handling Service Requests).

Access Management – This is the process of allowing authorised customers to access services, while preventing access by unauthorised users.

Problem Management – “A problem is a cause of one or more incidents. The cause is not usually known at the time a problem record is created, and the problem management process is responsible for further investigation.”

Again, this is a well established ITIL® process. For more information, search the blog or see our Problem Management White Paper

Monday, 19 Nov 2007

This is a follow-up to last week's ITIL V3 post on the subject of Service Design.

Service Transition simply involves taking all the good work you did in the Service Design Phase and transferring this to a new or changed service which is available to your customers.

ITIL® defines the scope of Service Transition as follows

“a service transition includes the management and coordination of the processes, systems and functions required for the building, testing and deployment of a ‘release’ into production, and establish the service specified in the customer and stakeholder requirements.”

The processes involved in the Service Transition phase are:

  • Change Management
  • Service Asset and Configuration Management
  • Release and deployment Management
  • Service Validation and Testing
  • Evaluation
  • Knowledge Management

Again many of these processes will be familiar to you from V2, but let’s have a quick review….

Change Management – this should be a very familiar one for most of you. Change management exists to allow us to handle changes in a repeatable manner and ensure that the risk to the business is minimised. Change Management should address all service changes - described by ITIL® as:

“A Service Change is the addition, modification or removal of an authorised, planned or supported service or service component and its associated documentation.”

Service Asset and Configuration Management (SACM) – this process has the goal of identifying, controlling and accounting for service assets and configuration items.

Activities involved in SACM are

  • Management and planning
  • Configuration identification
  • Configuration Management
  • Status accounting and protection
  • verification and audits

Release and Deployment Management – This process is involved with the building, testing and deployment of the services specified during the Service Design phase and the early life support of these services.

Service Validation and Testing – This process is aimed at ensuring that the new or changed service actually does provide what it is supposed to and that it is “fit for purpose”.

Evaluation – This is a generic process, it aims to verify that performance is acceptable. This process provides valuable input to the Continual Service Improvement (CSI) process.

Knowledge Management – Knowledge management is important to every phase of the lifecycle, but it is of particular importance in the Service Transition Phase. A successful transition from Design to Deployment depends greatly on the quality of information available to users and the Service Desk.

Monday, 12 Nov 2007

This is a follow-up to last week's Service Strategy post.

ITIL® tells us that the key objective of the Service Design Phase is “the design of new or modified services for introduction into a production environment”.

There are seven processes which are key to the Service Design Phase

  • Service Catalogue Management
  • Service Level Management
  • Capacity Management
  • Availability Management
  • IT Service Continuity Management
  • Information Security Management
  • Supplier Management

Most of these processes will be familiar friends from ITIL® V2 but I will give you a quick reminder on what these entail

Service Catalogue Management – the development and maintenance of a Service Catalogue that provides accurate and current detail of all your services and etails the business process which they support. It will also show services that are in development. The Service Catalog is the portion of the Service Portfolio which is presented to customers.

Service Level Management – this is the bridge between the customer and the IT Department. This process defines the levels of service which must be delivered to the customer and takes responsibility for ensuring that the agreed levels are reached and that customers are happy.

Capacity Management – ensures that capacity corresponds to current and future needs of the customer – recorded in a capacity plan.

Availability Management – ensures that availability levels correspond to the levels agreed with the customer in their SLA. This process involves both proactive and reactive activities.

IT Service Continuity Management – Ensures that required IT facilities can be restored within the agreed time, it focuses on occurrences that can be considered “disasters”.

Information Security Management – ensures that the information security policy satisfies the organisation’s overall security policy. This must be a continual process.

Supplier Management – Monitors the performance of suppliers to ensure that a consistent quality of service is received at an acceptable price.

In addition to these processes, there are three activities associated with the Service Design Phase:

  1. Development of requirements
  2. Data and information management
  3. Application Management

Service Design must include the “4 P’s” of design to be effective:

People: the people, skills and competences involved in the provision of IT services

Products: the technology and management systems used in the delivery of IT services

Processes: the processes, roles and activities involved in the provision of IT services

Partners: the vendors, manufacturers and suppliers used to assist and support IT service provision

Tuesday, 06 Nov 2007

This is a follow-up post to ITIL V3 - what does it deliver?

This key phase looks at the design, development and implementation of service management as a strategic resource.  Service Strategy is critical to all the processes involved in the Service Lifecycle.

If your organisation has already adopted ITIL® processes for its Service Management, then the Service Strategy Phase can help you improve the synchronisation between your IT and Business strategies.  This part of the V3 lifecycle can be used as a guideline for developing an overview of your capabilities. 

Service Strategy urges you to think about “Why” rather than “How”…the “Why” is far more important to your customer’s business than the “How”.

The aim of Service Strategy is to identify your competition and then compete with them by making your business stand apart and by delivering superior performance.

ITIL® names the following building blocks of well-performing service providers:

Market Focus – know where and how to compete

Distinguishing capabilities – create distinctive and profitable assets that the business appreciates

Performance anatomy – organisational standpoints that are measurable and feasible, such as viewing services as a strategic asset in which constant improvement is necessary.

The Service Strategy phase of ITIL® V3 can help your organisation to do business in a strategic manner. It encourages you to ask the questions that will help you stand apart from the competition. You should emerge from this phase with a clear vision of where you want to be and what milestones you need to reach to achieve that vision.

There are three processes involved in this phase of the lifecycle.

  • Financial Management
  • Demand Management
  • Service Portfolio Management

Financial management is critical to ensure that the correct financing is available for delivery and purchase of services.

The goal of Demand Management is to predict and, if possible, regulate demand.  Poorly managed demand is a risk on two fronts.  Excess capacity results in cost that cannot be recovered.  Insufficient capacity impacts the quality of service and limits its growth.

Service Portfolio Management (SPM) starts with the Service Catalogue. The process is dynamic and ongoing and comprises the following stages

  • Define
  • Analyze
  • Approve
  • Charter  

I'll follow this up later with more about ITIL V3.

Wednesday, 31 Oct 2007

So you have invested time and money in becoming a qualified ITIL® professional. With the changes in V3, are these qualifications still valid and meaningful?

This is probably one of the biggest debates in the IT Service Management community currently.

What I can tell you about the current state of play regarding qualifications is that there are bridging courses now available at Foundation level so that you can upgrade existing V2 qualifications to the V3 framework. The Bridging exam and syllabus for the Manager’s certificate is still under review and last I heard it will not be available until the first quarter of next year.

The V3 Foundation training is being reviewed in the light of concerns raised regarding the emphasis on Continual Service Improvement and Service Strategy; changes are likely to the syllabus as a result of this.

There has been some interesting discussion on the topic of exams and training for V3 on the IT Skeptic blog.

The new Manager’s qualification (the ITIL Diploma – although the name is still up for debate) will be made up of credits – you will be able to pick and choose the areas which apply best to the area you are working in to gain sufficient credits for the qualification.

There is a planned level above the ITIL Diploma qualification (Advanced Service Management Professional qualification), but details on this still seem to be a bit sketchy – there is not expected to be much more available on this until next year.

My own personal opinion is that the tried and tested V2 syllabus and exams are still valuable and valid qualifications. These qualifications are likely to remain available past the end of 2008 following feedback from the ITSM community. If I was looking at starting out now I would be trying to get my V2 qualifications and then bridge these to V3 once the syllabus and exams have had all the kinks ironed out of them.

From what I have seen of the proposed structure for the ITIL Diploma qualification, this will be a FAR more economical way to get this prized qualification under your belt. The number of training days required to get enough modules for the Diploma qualification if you start from scratch with V3 is going to make this qualification financially out of reach for many in the industry, it is hard enough to build a business case to do the V2 Manager’s certificate – the training days required for the V3 Diploma appear to be 2-3 times as many.

To get the new diploma you need to get 22 credits by taking the foundation course and various practitioner courses. From what I have been able to find so far it would appear that each course, worth 3-4 credits will take you around 30 hours of training - so you are looking at around 180 hours of training time to get the diploma. The V2 Manager's certificate was around 80 hours including the Foundation. It appears that the V3 Bridging course will also be around 30 hours. So doing the math, it is pretty obvious that getting the V2 qualifications and bridging is going to save a lot of time and money!

One thing to remember though, the pass rate for the Manager's bridging exam has been set at 80%, so you are really going to have to know your stuff to pass.

Some of the information on the qualifications is still a bit hazy, and it is a bit hard to get the full picture until the new courses start and people begin to get these qualifications, but I know what I would be recommending right now.

While the return to training organisations for each person who qualifies for the Diploma will be far greater than for the V2 Manager’s certificate, I think it will be a hard sell to get people to make the financial commitment needed to get there. So while I have heard a number of comments about what a windfall this is to trainers, I have a feeling that the opposite may be true…I guess time will tell.

Monday, 29 Oct 2007

ITIL® V3 was unveiled in May 2007. So what does it really mean to your business? If you designed the management of your IT Service on ITIL® processes, do you need to make changes?

The short answer is no…if you have robust processes that are delivering what your customers need and want then you don’t need to change anything.  The ITIL® v2 processes are still a valid and proven way to structure your IT Service offerings.  Maybe there is some added value you could get from investigating v3, but my advice is “if it’s not broken, don’t fix it!”

What v3 can help you do is move from an implementation of individual ITIL® processes to a truly service-centric model.  It gives you the ability to bring transparency to the relationship between IT and the business.

If you are new to ITIL® and looking at implementing processes then v3 gives some very good advice, it is more prescriptive than previous versions and gives you process models, flowcharts and organisational charts to help you model the processes in your organisation.  This is something that was missing in V2 and the most common complaint I heard about ITIL® – “it doesn’t tell us HOW to do it”.

This more detailed guidance can help you speedup ITIL® implementations and make them more cost effective.  You must remember, however, that these templates are just guides, you still need to determine your own business and IT requirements.  If you do not do this, no process design, flowchart or template is going to deliver the desired results.  The old adage still applies – you get out what you put in.

ITIL(R) V3 looks at service management from a lifecycle approach.  The lifecycle approach aims to give an improved and holistic structure to the functions, processes, roles and responsibilities that make up IT Service Management.

The Service Lifecycle has 5 distinct phases.  Each of the new ITIL® volumes describes one of these phases.

  1. Service Strategy
  2. Service Design
  3. Service Transition
  4. Service Operation
  5. Continual Service Improvement

Service Strategy is the hub around which the other phases revolve.  Service Strategy has links to all other phases.  This is where you make your policies and set your objectives.  The other phases are where you implement these strategies.

While Service strategy is the hub, Continual Service Improvement is an all encompassing phase which concentrates on learning from and improving on all the other lifecycle phases. ITIL® V3 still has the familiar processes from V2, these processes may belong in more than one of the lifecycle phases.

The  path of the Service Lifecycle is from Service Strategy to Service Design, to Service Transition and on to Service Operation.  Then we go through the Service improvement phase which puts us back to Service Strategy and so on.

Pages