Review: Biomni Front Office for Service Catalogue

This independent review is part of our 2013 Service Catalogue Group Test.

Executive Summary – BIOMNI

Overview
  • Good functionality
  • Nice commercial approach
  • Good option for Tech-only implementations (e.g. MSPs)
Strengths
  • Good intuitive functionality
  • Commercial approach
  • Speed of implementation – doesn’t need other ITSM processes
Weaknesses
  • Little Strategic implementation focus
  • Functionality gaps
Primary Market Focus Offers IT Service Management, with integration to third party Systems Management software

Commercial Summary

Vendor Biomni
Product Front Office
Version reviewed V7.3
Date of version release December 2012
Year founded 1999
Customers 600
Pricing Structure End Users; either one-off purchase or subscription.
Competitive Differentiators
  1. Flexibility via easy configuration not customisation and supporting of multi-clients with users of different language
  2. Intuitive self service portal designed with shopping cart or app store like request experience
  3. Decoupled service catalogue able to integrate to multiple existing fulfilment system and not tied to any specific services desk
Additional features Biomni say “We have built a variety of integration adapters for cloud, service desk, asset management, user directory systems and platforms. Our community site allows customer to download service and request templates and adapters.”

largeIndependent Review

Biomni is based in the UK and is focussed on Service Catalogue capability. The vendor has developed a number of proven technical links with other products and providers, and offers a ‘bottom up’ discovery and integration approach.

The product is simple to use and has an intuitive WYSIWYG interface – the user view is similar to familiar retail experiences. The system meets most functional requirements, although there are gaps in visualisation of services and hierarchies, plus also some areas of reporting and demand management – although some aspects of this look effective (Reporting consumption forecast vs. actual).

Prospective clients can also use the product free as a trial until the catalogue is needed as an ‘actionable’ system (i.e. transactional) – this is useful for flexible and fast appreciation of Service Catalogue concepts and also for presentation of services, which can be useful to get buy-in and financial backing.

The vendor is focussed on developing and selling mostly at the technical level, so is not widely known as a fully functional option – they are now extending some marketing activity to make more of the industry aware of the product.

This product is useful for a variety of organisations as a simple and low cost entry to the market – the commercial option allows potential users to try out and create some functionality without major effort or expense. As a more strategic option it requires more focus from the vendor on positioning and capability around the product – in order to sell in at a more senior level.

This product is an excellent option for small and medium sized organisations as a means to quickly get up and running with Service Catalogue – it is also a good option for those looking outside their own existing ITSM product, as the vendor is experienced and capable in developing interfaces and integration with a number of ITSM tools. It is sold to enterprise organisations, although mostly as part of a ‘bottom-up’ technical integration.

Overview

  • Specific Service Catalogue/Request Management Vendor
  • Simple, easy to use and effective portal, user administration and request management system
  • Well established and integrated with multiple ITSM and other 3rd party systems management software
  • Interesting and useful commercial approach – software provided free as a presentation system
  • Meets most of the stated requirements – full request management – gaps in visualisation, service hierarchy, demand management, reporting
  • Sales and implementation approach is focussed on technical integration and organic development
  • Vendor becoming active in ITSM community
  • Little focus on strategic/top down approach

Strengths

  • Strong product for Service Portal and Request Management, plus discovery and IT user administration – e.g. security
  • Strong track record of integrations and front-end implementations with other ITSM and systems management tools
  • Product is offered on free basis until it becomes actionable (i.e. with transactional capability rather than just a service brochure). This is useful in this area as it allows for gradual organic development and implementation – or ‘suck it and see’ approach
  • Vendor becoming active in ITSM community – marketing and partnerships
  • Strong technical focus and subject matter skills from vendor
  • Demand Management not fully complete but looks to be potentially highly effective – forecasting vs. actual feature already in place. Looks intuitive and easy to use

Weaknesses

  • No dynamic graphic visualisation for service structure and hierarchy
  • Some gaps in demand management
  • Little vendor focus on business services and strategic approach
  • Gaps in dashboard and reporting features OOTB – requires specific consulting or in-house SQL skills
  • Vendor focussed on technical and bottom up implementation – could do more marketing around IP and practise to develop interest beyond technical level
  • Vendor has limited recognition beyond technical areas and also beyond UK/European base.

Front OfficeService Catalogue Customers

In Their Own Words:

“Biomni Front Office provides IT organizations of any size a flexible decoupled self-service portal through which users can intuitively discover and request services of any type. With easy point and click configuration and extensive interfaces to integrate supporting systems, processes such as cloud, software and user provisioning can be made available for self-service consumption with highly automated fulfilment.

In use by over 1 million production users globally, Front Office is a proven addition to any customer ITSM tool portfolio, delivering rapid tangible and highly visible value.

Front Office Essentials is the free entry level edition to the Front Office suite and provides foundation Service Portfolio/Catalogue management and publishing functionality.

Front Office Express adds shopping cart and app store requesting with optional approval to provide a fully actionable Service Catalogue. Request forms, approval routing rules and service packages/bundles can be configured and linked to services for intuitive self-service requesting.

Front Office Enterprise adds request fulfilment and measurement functionality, allowing requests to be orchestrated across multiples fulfilment systems and teams.

Front Office Service Provider adds multi-client support including client specific branding and support for client hierarchies (e.g. distributors and resellers) within a single instance of Front Office.”

Screenshots

Further Information

Group Test Index

This independent review is part of our 2013 Service Catalogue Group Test.

Coming Soon: Axios, Biomni, Matrix42 & ServiceNow Showcase Service Catalogue

Peloton
Axios, Biomni, Matrix42 and ServiceNow - who leads the pack in Service Catalogue?

Axios, Biomni, Matrix42 and ServiceNow are confirmed participants for our upcoming ‘Service Catalogue’ review.

Our assessment criteria at a glance:

  1. Service Design – the ability to create a database of service records, containing a number of business and technical attributes, processes and workflows.
  2. Service Structure – the ability to organise and structure these services into a hierarchy of services and service offerings, ideally useable in a graphical format
  3. User Request Portal – a user-friendly/external facing portal that provides users with an intuitive User Interface to request services
  4. Request Fulfilment – request management workflow functionality that can be easily used and configured by system users
  5. SLA and event management – the ability (in the software or by integration) to define universal and bespoke levels of SLA which are then automated and escalated though an event management process – ideally linking with Incident, Problem and Change Management functionality
  6. Demand Management – the ability to provide real time allocation and monitoring of Service consumption, with financial calculations
  7. Dashboard – real-time user-friendly graphical monitoring and analysis of usage, trends and metrics across services and to various stakeholders
  8. Service Reporting – the ability to present output that summarises individual and bundled service performance, consumption, SLA and event performance, in user-friendly, portable and graphical format

Full details of the assessment criteria can be found here.

Reviewer: Barclay Rae

Confirmed Participants:

Publication

All results will be published free of charge without registration on the ITSM Review. You may wish to subscribe to the ITSM Review newsletter (top right of this this page) or follow us on Twitter to receive a notification when it is published.

Image Credit

7 golden rules for getting the most from the Service Catalogue

This article has been contributed by Yemsrach Hailemariam, ITSM Consultant at Macro 4.

Implementing IT service management (ITSM) according to ITIL best practice is often seen as a large, complex undertaking which those outside of IT may sometimes struggle to see the true value of.  This can mean the IT department feels some pressure to demonstrate early evidence of practical progress to help win the confidence of the wider business organisation.  But that should not mean they skimp on the all-important first stage of the process – which is the creation of a Service Catalogue.

Here is a list of seven important rules that you need to consider if you are going to squeeze maximum value from the Service Catalogue

Squeeze the most out of your Service Catalogue initiative, but watch out for some of those sour low-hanging fruit!

Rule number one: don’t judge a catalogue by its cover

I have seen organisations that are tempted to speed through the process of defining the services in the Service Catalogue, viewing this as a quick ‘box ticking’ exercise.  After all, they think to themselves, it’s simply creating a list of the services that IT delivers to the business, right?

Wrong. Despite the slightly uninspiring name, the Service Catalogue is much more than just a list of services with some related information.  And in reality that ‘just’ is a loaded word. When you consider that many organisations have never actually gone through the process of clearly defining the services that IT should deliver to the business, you start to realise that ‘just’ getting it written down is actually the catalyst for defining the roles and responsibilities of IT to the business – and getting that right is an essential cornerstone of IT Service management.

Rule number two: bang heads together

To create the Service Catalogue, you will probably have to get IT sitting down in a meeting or workshop with representatives from the business to hammer out the detail of which services the business requires, how significant they are and how they support the business.  There is usually also some discussion about what the priorities are among the services, the required service levels and availability requirements.

If one of the goals for ITSM is to help IT align more tightly with the business, then you can immediately see how the process of creating the Service Catalogue plays a significant role – by getting everyone to review the global picture of the business’s IT requirements.  Without such an impetus of how often would technical and business colleagues meet and discuss the details of what the business actually wants from the IT department, and how it can be delivered?

Rule number three: ask people what they want FIRST – then look at how you can deliver it

A good place to start discussions around defining the contents of Service Catalogue is to run an analysis of the existing service portfolio.  You can ask a number of useful questions.  Is this the optimal range of services for the business?  Is it possible to demonstrate how each IT service supports the key drivers for the business?  Is it possible to tie the service definitions to specific business processes, benchmarks, and KPIs which might also help with tracking and reporting service provided.

Rule number four: resist the temptation of low-hanging fruit – it may leave a sour taste

Too often organisations rush through the development  of the Service Catalogue in order to move on as swiftly as possible to other areas which they feel can provide some initial ‘quick win’ benefits.   Unsurprisingly the area they tend to start with is Incident Management  – which involves developing the processes for restoring normal IT service operations as swiftly and effectively as possible and minimising the impact on business operations ( in the event that normal services have been disrupted for some reason).

The rest of the business can easily appreciate the practical, tangible value of Incident Management.  After all, it is an important area for any business and the whole topic of managing incidents is very familiar to, and resonates well with, the service desk – which is often heavily involved in the rollout of ITSM.

But a well defined Service Catalogue forms the foundation of Incident Management and getting this completed accurately should be the first priority. If you don’t, you might just find that your incident management process falls flat on its face…when there is an unplanned disruption to a service, it is the Service Catalogue that provides the service desk with speedy access to key information – about Service Level Agreements, numbers and types of users of the service and related configuration items (CIs) – that enables it to prioritise effort to restore the service to required levels.

Rule number five: build upwards from solid foundations

As well as helping to ensure that the services that IT delivers are really those that are valued by the business, a comprehensive Service Catalogue is the place to document the fine detail about the specific range of available services, their relative value and associated costs, the configuration items (CIs) – the various parts of the IT infrastructure involved in delivering that service; and service level expectations.

A well-defined Service Catalogue will be the connector between the Incident, Change, Problem and Service Request processes. The relevant CIs associated with delivering services and their inter-relationships are very often recorded within the Service Catalogue. So when a business user calls with an issue or a service request then the service desk can quickly identify the possible CIs affected based on the service.

For example if there is a connectivity problem with the exchange server, the Service Desk will decide that the service affected will be Email – Connection. The affected CI can be easily identified as the Service Desk will have a small number of CIs to select from.  This makes the task of identifying the affected CI, in a vast organisation where the Service Desk might not be familiar with the IT infrastructure, easier – helping the Service Desk to do its job well.  If subsequently a change is required to the CI then a change can be logged against the same Service Catalogue.

Rule number six: use the service catalogue to deliver tangible value to business stakeholders

The other benefit of having an up-to-date Service Catalogue is that different parts of the business can use it to easily identify the services that are available to them, assess whether they need them and how much it will cost their business unit.  It allows the business to make quick, informed decisions about what services they want to use, while taking account of the cost implications to drive an efficient allocation of IT resources. Demonstrating value in this way will incentivise your service deliverers to keep it up-to-date.

Moreover, the documented Service Catalogue information about service priorities, costs, service levels and uptime will help with monitoring the service delivery success.  This in turn can feed through to helping   identify opportunities for making service improvements and identifying where cost reductions might be possible

Rule number seven: one size does not fit all

Of course different organisations’ Service Catalogues can vary greatly in style and format. They can range from the very simple document based formats, or static web based catalogues through to interactive portals and fully interactive tools or ITSM suite based products.  The more sophisticated tools and solutions, which take considerable time to implement and maintain,  have additional advantages such as integration with other support based processes, self service capabilities and the ability to act as the ‘front end’ to all other ITSM process areas.

Each organisation needs to decide on the style and sophistication of Service Catalogue it requires, based on factors such as the specific audiences it needs to cater for, the scope of the aims and objectives and the resource constraints it is working to.  But the Service Catalogue remains the most logical and efficient place to start the ITSM journey.

This article has been contributed by Yemsrach Hailemariam, ITSM Consultant at Macro 4, which runs the UK arm of iET Solutions. Yemsrach has worked as a technical consultant for the past 10 years consulting on many ITSM projects in the US, UK and Germany.  She has a BS in Electrical Engineering from University of Maryland, USA.

Event Listing: Service Desk & SLM Seminar, itSMF UK, 12th September 2012, Manchester

What?

itSMF UK Seminar – Service Desk and SLM

The Service Desk is at the frontline to increase service quality, reduce cost and pressed to do more with less. Many are still searching for tools to help move them from their traditional fire fighting roles in-order to free up resources to more spend time on better managing customer expectations and improving service.

What are the best approaches to meeting this challenge?

This seminar is targeted at service desk, service level and service catalogue managers who want to ensure agreed customer expectations and promises are met

When?

Wednesday 12th September, 9am – 4pm

Where?

Museum of Industry & Science, Liverpool Road , Manchester, M3 4FP

Museum of Industry & Science Website

Map and Directions

Museum of Industry & Science (MUSI) in Manchester

Who?

itSMF UK

Agenda

Key learning outcomes of this seminar include:

  • Learn the processes that underpin a good service desk
  • Learn what are the key interfaces between the service desk, service level management and service catalogue
  • Learn how you know if you have got the right people working on your service desk
  • What is the skill profile and roles of a hybrid service desk manager and analyst
  • Learn which service desk structure is right for your organisation
  • Learn the challenges and approaches to managing a distributed or global service desk
  • Learn how to define a service catalogue with underpinning service levels that works for you
  • Learn how to get more out of 2nd line teams by implementing operational level agreements
  • Learn how to improve your workload planning and scheduling techniques to manage the service desk
  • Where will the service desk be in 5 years

Further Info…

Photo Credit

Rob England: What is a Technical Service Catalogue?

Amtrak 14th Street Coach Yard (Chicago, IL, US): A railway provides other functions: track gangs who maintain the trackwork, dispatchers who control the movement of trains, yard crews who shuffle and shift rolling stock. It is clear that these are not services provided by the railway to its customers. They are internal functions.

We are looking at railways (railroads) as a useful case study for talking about service management.

Last time we looked at the service catalogue of a railway.

We concluded that first and foremost, a service catalogue describes what a service provider does.

How often and what flavour are only options to a service or package of services.

ITIL refers to a technical service catalogue (TSC).  Where does that fit?

One thing everyone agrees on is the audience: a TSC is for the internal staff of the service provider, to provide them with supplementary information about services – technical information – that the customers and users don’t need to see.

But the scope of a TSC – what services go into it – is a source of much debate, which can be crudely categorised into two camps:

  1. TSC is a technical view of the service catalogue
  2. TSC is a catalogue of technical services

Those are two very different things.  Let me declare my position up front: I believe the answer is #1, a technical view of the service catalogue.  ITIL V3 was ambiguous but ITIL 2011 comes down clearly with #2.  This is unfortunate, as we’ll discuss.

Go back to what a service catalogue is: a description of what a service provider provides to their customers (and hence their users).  A good way of thinking of a service in this context is as something that crosses a boundary: we treat the service provider as a black box, and the services are what come out of that box.  A service catalogue is associated with a certain entity, and it describes the services that cross the boundary of that entity.  If they don’t come out, they aren’t a service, for that entity, depending on where we chose to draw the boundary.  To define what the services are, first define the boundary of the service provider.

Think of our railroad example from last time.  A railway’s service catalogue is some or all of:

  • Container transport
  • Bulk goods transport (especially coal, stone and ore)
  • Less-than-container-load (parcel) transport
  • Priority and perishables transport (customers don’t send fruit as regular containers or parcels: they need it cold and fast)
  • Door-to-door (trucks for the “last mile”)
  • Livestock transport
  • Passenger transport
  • etc etc

A railway provides other functions:

  • track gangs who maintain the trackwork
  • dispatchers who control the movement of trains
  • yard crews who shuffle and shift rolling stock within the yard limits
  • hostlers who prepare and park locomotives

It is clear that these are not services provided by the railway to its customers.  They are internal functions.

A railway provides track, rolling stock, tickets and stations, but these aren’t services either: they are equipment to support and enable the services.

A passenger railway provides

  • on train security
  • ticket collectors
  • porters
  • dining car attendants
  • passenger car cleaners

and a freight railway provides

  • container loading
  • consignment tracking
  • customs clearance
  • waybill paperwork

These all touch the user or customer, so are these services?  Not unless the customer pays for them separately as services or options to services.  In general these systems are just components of a service which the customer or user happens to be able to see.

So why then do some IT people insist that a technical service catalogue should list such “services” as networks, security or AV? (ITIL calls these “supporting services”). If the networks team wants to have their own catalogue of the services that only they provide, then they are drawing their own boundary around just their function, in which case it is not part of a technical service catalogue for all of IT, it is a service catalogue specifically for the networking team.  It is not a service provided by IT to the customer.

A technical service catalogue should be a technical view of the same set of services as any other type of service catalogue for the particular entity in question.   The difference is that it provides an internal technical view of the services, with additional information useful to technical staff when providing or supporting the services.  It includes information a customer or user doesn’t want or need to see.

A technical service catalogue for a railway would indeed refer to tickets and porters and stations and yard procedures and waybills, but only as components of the services provided – referred to within the information about those services – not listed as services in their own right.  I’m all for “supporting services” to be described within a service catalogue, but not as services.  They are part of the information about a service.  Supporting services aren’t services: they are component systems – CIs – underpinning the real services we deliver to our customers.

By adopting the concept of “supporting services” and allowing these to be called services within the catalogue of a wider entity that does not provide these services to a customer, ITIL 2011 contradicts its own description of “service”.

Service Design 4.2.4.3 says:

Supporting services IT services that support or ‘underpin’ the customer-facing services.  These are typically invisible to the customer… such as infrastructure services, network services, application services or technical services.

Yet the in the prior section 4.2.4.2, such IT systems are clearly not a service:

IT staff often confuse a ‘service’ as perceived by the customer with an IT system.  In many cases one ‘service’ can be made up of other ‘services’ and so on, which are themselves made up of one or more IT systems within an overall infrastructure…  A good starting point is often to ask customers what IT services they use and how those services map onto and support their business processes

And of course it contradicts the generic ITIL definition of a service as something that delivers value to customers.  This is important because the concept of “supporting service” allows internal units within the service provider to limit their care and concern to focus on the “supporting service” they provide and allows them to become detached from the actual services provided to the customer.  There is no SLA applicable to “their” service, and it quite likely isn’t considered by service level reporting.

A railway ticket inspector shouldn’t ignore security because that is not part of his ‘service”.  A yard hostler should make sure he doesn’t obstruct the expeditious handling of rolling stick when moving locomotives, even though rolling stock isn’t part of “his” service.  The idea of “supporting service” allows and encourages an “I’m alright Jack” mentality which goes against everything we are trying to achieve with service management.

It is possible that Lou Hunnebeck and the team writing Service Design agree with me: that they intend there to be a distinction between supporting services and IT systems.  If so, that distinction is opaque.   And they should have thought more about how the “internal” services model would be misused- the problem I’m describing was common before ITIL 2011.

There is the case where the supporting services really are services: provided to us by a third party in support of our services to our customer.  For example, a railway often pays another company:

  • to clean the carriages out
  • to provide food for the bistro car;
  • to repair rolling stock
  • to provide the trucking over “the last mile”

Where we bundle these activities as part of our service to a customer and treat them as an Underpinning Contract, then from the perspective of the services in our service catalogue – i.e from the perspective of our customer – these are not services: they are CIs that should not be catalogued here.  If this – and only this scenario – is what Service Design means by a “supporting service”, I can’t see that called out explicitly anywhere.

Technical service catalogue should be a technical view of the services that we provide to our customers.  I wish ITIL had stuck to that clear simple model of a catalogue and kept IT focused on what we are there for.

Photo Credit

Rob England: What is a Service Catalogue?

"The menu analogies we see all the time when talking about service catalogue are misleading. "
"The menu analogies we see all the time when talking about service catalogue are misleading. "

We are looking at railways (railroads) as a useful case study for talking about service management.

What is the service catalogue of a railway?

If you said the timetable then I beg to differ.  If you said one-trip, return and monthly tickets I don’t agree either.

The menu analogies we see all the time when talking about service catalogue are misleading.

A menu (or timetable) represents the retail consumer case: where the customer and the user are one.  In many scenarios we deal with in business, the one paying is not the one consuming.

The service catalogue describes what the customer can buy.  The request catalogue is what the user can request.  Consider a railroad cook-wagon feeding a track crew out in the wilds: the cook decides with the railroad what to serve; the staff get a choice of two dishes.

The cook’s services are:

  • Buying and delivering and storing ingredients
  • Mobile cooking and eating facilities
  • Cooking food
  • Serving food onsite

That is the service catalogue.  The railway can choose to buy some or all of those services from the caterer, or to go elsewhere for some of them.

The menu is a service package option to the “cooking food” service.  The railroad chooses the options based on cost and staff morale.  The menu gives staff the illusion of choice.

First and foremost, a service catalogue describes what a service provider does. How often and what flavour are only options to a service or package of services.  A railway’s service catalogue is some or all of:

  • Container transport
  • Bulk goods transport (especially coal, stone and ore)
  • Less-than-container-load (parcel) transport
  • Priority and perishables transport (customers don’t send fruit as regular containers or parcels: they need it cold and fast)
  • Door-to-door (trucks for the “last mile”)
  • Dangerous goods transport (the ethanol delusion generates huge revenues for US railroads)
  • Large loads transport (anything oversize or super heavy: huge vehicles, transformers, tanks…)
  • Livestock transport
  • Rolling-stock transport (railways get paid to deliver empty wagons back their owners)
  • Finance (a railway can provide credit services to customers)
  • Ancillary freight services: customs clearance, shipping, security…
  • Passenger transport
  • Luggage
  • Lost luggage
  • Bicycles
  • Pet transport
  • Food and drink services (onboard and in stations)
  • Accommodation (big Indian stations all have dormitories and rooms)
  • Tours and entertainment (party trips, scenic trips, winery trips…)
  • Land cruises (just like a cruise ship but on rails)
  • Travel agency
  • Bulk goods storage (railroads charge companies to hold bulk materials in wagons for them awaiting demand: they provide a buffering service)
  • Rolling stock storage (in the USA railroads make money storing surplus freight wagons for other railroads)
  • Rolling stock repair (railways repair private equipment for the owners)
  • Private carriage transport (in many countries you can own your own railroad carriage and have the railway carry you around; a fantasy of mine)
  • Property rental (many large railways are significant landlords)
  • Land sales

Where’s the timetable or ticket pricing now?  It has such a small part in the true scope of a railway’s services as to be trivial.  More to the point, it is not a service: tickets are request options associated with one of many services.  Users don’t request a service: “I’d like an email please”. No, they make a request for an option associated with a service: provision email, increase mailbox, delete account, retrieve deleted email etc…

People confuse their personal consumer experience with business: they try to apply consumer experience models to business processing.  Most customers don’t want a service catalogue “to look like Amazon”.  They want meaningful business information.  The best vehicle for that is usually a text document.  The users/consumers of a service(s) may want to see the requests associated with that service(s) in an Amazon-like interface.  Sometimes there may even be a valid business case for building them a groovy automated request catalogue, but it is not the service catalogue.

The service catalogue defines what we do.  It is not simply an ordering mechanism for customers.  That is that personal/business thing again.  A service catalogue has multiple functions.

  1. Yes it is a brochure for customers to choose from.
  2. It also provides a structure to frame what we do as a service provider: availability planning, incident reporting, server grouping… Once we have a catalogue we find ourselves bring it up in diverse contexts: “we see the list of services show up in the table of contents”.
  3. It is a reference to compare against when debating a decision
  4. It is a benchmark to compare against when reporting (especially the service levels, but not only the service levels)
  5. It becomes a touchstone, a rallying point, an icon, a banner to follow.  It brings people back to why we are here and what we are for as an organisation.

You don’t get that from Amazon.

Then we come to that endless source of confusion and debate: technical service catalogue.  That deserves a whole discussion of its own, so we will look at it next…

Event Listing: Service Catalogues & Service Portfolios Seminar, itSMF UK, 18th April, Solihull

National Motorcycle Museum, Solihull

What?

itSMF UK Seminar – Service Catalogues & Service Portfolios

“Service catalogue, service portfolio and service level management are the essential elements of the relationship between IT and the business.  Without these processes in place, it is increasingly difficult to define what IT services are available to the business and on what basis.

But the relationship between service catalogues and service portfolios is often poorly understood, and this can lead to confusion and misunderstanding. This seminar explains how these concepts inter-relate, and helps attendees to build a solution that suits their specific business needs. “Problem management is often the most under used process, and is described by some as the “If we only have the time” process. In reality it is a process that if used correctly adds real value to the business, and supports all of the other service management processes. To get there, there is a need to invest both time and resource – the very things that problem managers have little of.”

When?

  • Wednesday 18th April 2012, 9am – 4pm

Where?

Who?

  • itSMF UK

Agenda

  • Service catalogue – all things to all people?Not only is the service catalogue a way to orientate your organization and processes around services, it is also a user facing service itself. This is Unilever’s experience of delivering a user-friendly catalogue that is part of improved customer satisfaction. ~ Andrew Davies, Unilever
  • Unlocking the potential of service portfolios and service catalogues, and measuring the right thing This presentation will destroy some myths, make you think differently, and give you the tools to continually improve both IT and the business by integrating portfolios, catalogues and measures. ~ Kevin Holland, UK Public Sector Consultant.
  • Magic wand session: Service catalogues and service portfolios in your organizationTake part in one of our interactive round table discussions, led by Dr Don Page of Marval, and discuss the answers to some key questions concerning service catalogue and service portfolio implementation. ~ Don Page, Marval
  • The service portfolio – the new tool in your service management toolset Just when you have finally understood the concept of the service catalogue and managed to produce a useful addition to your service management toolset, along comes ITIL v3 and the service portfolio. What is it, how does it help us? This presentation will give you some answers. Rob Young, Fox IT

Further Info…

Image Credit