SFIA Pocket Overview

Matthew Burrows has written a pocket overview for the latest version (V5) of SFIA.  It is available to purchase from the itSMF UK Bookshop and other places.

What is SFIA®?

The Skills Framework for the Information Age (SFIA®) provides a common reference model of the professional skills needed in technology-related activity.

The purpose of SFIA®

SFIA® provides a simple to use framework that identifies skills required, at different levels of responsibility.  This improves the ability of an organization to understand their current and future requirements, and better manage the full cycle of resource and capability management in a documented and repeatable way.  SFIA® aims to help organizations effectively, engage professionals in technology-related activity, either as employees or service providers. SFIA® also supports individuals in planning and managing their own professional development.

The Service Desk and IT Support Show (SDITS) is taking place in London on 24th and 25th April 2012.  Entry is free, and there is a large exhibition space with service providers and tools vendors telling you about their latest offerings, but also an impressive seminar programme, hot topics discussion tables and loads more.

BSMimpact will be represented at the show by Matthew Burrows, who will be delivering 2 sessions in the seminar programme:

• Tuesday 24 April, Seminar Theatre 2, 1340
• Transformation and driving business change

• Wednesday 25 April, Seminar Theatre 2, 1020
• The realities of Business Relationship Management

Matthew is looking forward to catching up with lots of people over the 2 days, and taking part in various other activities including a few related to #Back2ITSM, and itSMF UK.  If you want to meet Matthew during the event, please email matthew.burrows@bsmimpact.com with your contact details.

For full details, including registration, go to www.servicedeskshow.com

Changes Forcing the IT Makeover

The changes in the IT space were expressed extremely well in the BSMreview article “The Essence of Professionalism: Will it make a difference in your IT career?” by Pete McGarahan and Ric Mims.  They talked about the need for “creating business value from IT-enabled business initiatives and innovations”. As they hinted, the reality is that IT isn’t quite as specialist and separate as it used to be.  People want to bring their own devices to work, and for the most part can achieve the same results as they would with any kit imposed on them by the IT department.  It’s a sad reality that individuals often get more IT capability and capacity from cloud-based offerings and apps that they download.  IT is much more embedded in every aspect of the business, and also extensively in life outside of work.  Business models have changed, and consumers are much more dependent on technology because it’s now an integral part of many of the products and services which they use.

Within business, IT is still often seen as an expense to be minimized (a necessary evil), as it fails to demonstrate its strategic value.  Many aspects of IT are now commodity, and are often outsourced and removed from the core competencies of the organization itself.

Businesses still understand the need for IT, but not necessarily the need for an IT department – the capability is needed, but do they need the organizational function or department?  Many users would rather perform a search on Google to help resolve their issues or provide information, than make contact with an IT department.  If a user has to phone a Service Desk, or log a case online, their view is probably that IT has already failed them.  Some of this is unfair, of course, but nevertheless this perception does exist in many places.

The services of the business need to be delivered to customers, and these business services are almost always dependent on technology in some way or another.  To ensure that Business Services are delivered which enable the achievement of business outcomes and objectives, often about delivering products and services to customers at an agreed cost and quality, we need to manage them.  The real key here is Service Management, which didn’t get invented in IT …it comes from other business disciplines in marketing and product management.

Impact of ITSM and BSM

IT Service Management (ITSM) is nothing more than applying service management in the IT space.  It supports the ability to manage IT in a service-orientated way, recognising that there is no longer “IT for IT’s sake”.  The business value of everything has to be demonstrated, particularly in tough economic times.  If an IT function or department is to survive, it must demonstrate how it delivers business value, which is about how it supports the business objectives and outcomes.

In the 2011 edition of ITIL, Business Service Management (BSM) is now positioned as being above ITSM.  BSM is defined as “The management of business services delivered to business customers. Business service management is performed by business units.”.  It’s worth pointing out that ITIL is referring to the external customer of the business when it uses the term Business Customer – not a customer of IT within the business.  I wrote a blog on this for BSMdigest (before it changed it’s name to APMdigest – http://www.apmdigest.com/has-itil2011-got-it-wrong-with-the-definition-of-bsm), which included this definition, and the positioning of ITIL as “a set of best-practice publications for IT service management”.

My view is that BSM is something that the business does together, all of the business units (which could include IT if organizations continue to have IT departments), focused on delivering the products and services of the whole organization to their end customers.  For most organizations this is how they deliver their objectives, which for commercial companies could include a return for shareholders through profit, or for not-for-profit organizations it will be another set of specific objectives and outcomes.

Within all organizations, departments and business units are dependent on each other, nothing works in complete isolation.  IT is a capability on which pretty much everyone has some dependency, and ITSM can be used to ensure that the IT capability is managed and provided to support these dependencies.  This is done in the wider context, and in order to support the objectives of the whole organisation including the delivery of the products and services to the customers – something which a BSM approach should clearly be part of. BSM is the approach which recognises that IT is a dependency for the whole business, recognising it as part of the business rather than a supplier to it.  For IT functions, or Business Technology (as some, from the emerging trends, are predicting that it will become), keeping up with the shift and creating business value from IT is vital.  Technology should work in complete harmony and full integration with capabilities from other functions in order that the whole organization achieves the business outcomes together.  In my view, BSM helps address the reality of our present situation, and the needs of our organizations and customers.

http://www.bsmreview.com/blog/2012/02/product-or-service-does-it-really-make-any-difference.htm

What one customer sees as a service, another might see as a product.  As an example, a mobile phone company provides a phone, which could be seen by the customer as a product which allows them to make calls and send/receive text messages, and provides various other capabilities.  It could be regarded as a service – being able to make phone calls etc. which just happens to include the supply of a phone handset in order to use the service.  Whether the customer sees it as a Product or Service is subjective, and probably doesn’t really matter all that much.  From a customer’s perspective, it’s what the Product or Service does for them, the value it provides, which is important.  The mobile phone Product or Service allows them to make calls and other tasks – the value is in achieving the outcome, not in buying the product or service.  If the customer didn’t have the need, they probably wouldn’t be buying.

Our industry can be guilty of spending too much time on semantics  – is it an ‘incident’, or should we call it something else?  There are an embarrassingly  large number of examples.

Surely any organization who wants to be successful, realizes the necessity for understanding this customer-centric perspective.  This awareness is absolutely necessary if we hope to design and deliver successful products and services.  Regardless of whether we’re a commercial organization, charity, not-for-profit, public sector or private, isn’t this completely critical?

People have different views, and why should we have the right to dictate how people should think, or the language they use?  I would argue this is a distraction, and not massively important.  The main point is that a good service provider, or any of us who believe they have any element of service management in what we do, should do everything we can to understand what the customer wants or needs to achieve, and how what we do makes that happen – that’s what makes it a valuable service.

This particular debate about Incidents, Problems, Faults etc. seems to be dragging on far too long.  I must admit, I’ve not got the time or patience to look through everything that’s written.  Much of the debate seems to be about whether ITIL should have used a different word instead of Incident, rather than whether the process it suggests is a good starting point or not.

My view is that you can change as many terms as you like.  If it helps your organization and customers to rename ‘incident’ as ‘fault’ or even ‘problem’, go ahead – just have a note somewhere that makes it clear that for those familiar with ITIL, when we use this term, we are referring to what ITIL would label an incident.

Personally, I have a little bit of sympathy for those who find the term ‘incident’ is not natural customer language.  Not many customers will contact the Service Desk to say they have an incident.  They would probably be more likely to use the words ‘problem’, ‘fault’, ‘error’, ‘issue’ or something similar – that’s all OK, and we certainly shouldn’t be telling the customer that they should really use the word ‘incident’, just to fit in with what ITIL says.

We still seem to have several experts who can’t agree on the difference, and I find that very worrying, particularly as these include well-known names who give consultancy, presentations, advice and support.  I find ISO/IEC 20000 quite useful in understanding this.  Here are the relevant definitions:

“Incident: unplanned interruption to a service, a reduction in the quality of a service or an event that has not yet impacted the service to the customer”

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

“Known error: problem that has an identified root cause or a method of reducing or eliminating its impact on a service by working around it”

Some of the confusion seems to be in understanding the difference between a ‘problem’, a ‘problem ticket’ and the ‘problem management process’ – the same confusion for ‘incident’.  Here goes nothing, with my attempt to explain it rather than bitching about it:

• A ‘problem’ is the root cause of an ‘incident’, they are not the same
• The ‘incident’ is about the impact to the service and customer
• The ‘incident’ is resolved when there is no longer a service impact
• The focus of the ‘incident management process’ is to stop the service impact, either through workaround or when it fixed by the ‘problem’ being resolved
• The focus of the ‘problem management process’ in relation to the incident, is to identify the root cause and determine action required to fix it
• When the ‘root cause’ is identified, it is a ‘known error’
• If a ‘change’ is required in order to resolve the ‘problem’, it will raise a request for change, to be managed by the ‘change management process’.

Records should be kept of all activity, and to a certain extent it doesn’t matter how this is done.  Typically an ‘incident record’ is used to track the activity of the ‘incident management process’, a ‘problem record’ is used to track the activity of the ‘problem management process’, and all records are updated with relevant data – including data from other processes, e.g. incident record updated with known error information is provided by the problem management process.  The processes, of course, also do other things, including ‘problem management’ performing proactive tasks to identify root causes and their potential preventative action, thus preventing incidents.

Is that really so complicated and confusing?  Maybe I’ve completely misunderstood and it’s me getting it wrong.

Article from ServiceTALK magazine, January 2012

ServiceTalk_Jan2012_Ethics

Article of ethics from the January 2012 edition of ServiceTALK magazine – click the link above.

• 2 main groups

• Our customers and our organization (including our shareholders/members and employees).  Without these stakeholder groups, everything else is irrelevant because there would be no job for us to do.  We need to constantly demonstrate how we help them, and always be looking for ways to support their objectives.

• 0 excuses

• Understand why things didn’t work, but focus on improvement and how to prevent issues happening in the first place.  We need to move away from hero, fire-fighting behaviour – which is a big cultural shift for many of us.  For many organizations this will be a significant transformation, and require a new design for parts of the operating model, as tweaking the existing one won’t always work effectively.

• 1 core dependency

• People – It’s not the technology and tools, it’s the skills and experience of people which hold everything together and are the critical ingredients in making it all work.  I’d like to see more projects which give an equal balance to the people and culture change aspects rather than positioning them as technology or process implementation.

• 2 focal points

• The context for everything we do should be the outcomes our customers want to achieve, and the services we provide to meet these needs.  We should think about everything we do in this context.  Everyone will be happier if we have the ability to demonstrate this context when we explain what we do, why we need a change, or why we need investment.

At BSMimpact, we hope that you all have a good 2012, and we look forward to speaking to you and working with you to help achieve your goals during this year.  Please make contact if you need any help or advice from us.

Happy New Year

Matthew Burrows, January 2012

Best Wishes from the

BSMimpact Management & Directors

Fun video featuring Matthew, Elaine, James & Julian