Business Impact Analysis (BIA): There’s a Difference Between a Service and a Process

I’ve sat through many workshops and meetings lately and many of the session presenters – or meeting facilitators – seem to have something in common.  Many believe that the first thing a corporation needs to ensure they have up and running are their key services.  Well, I can’t really disagree with that; key services to be up and running in vital if you want your business operations – the key parts of it anyway – to have minimal downtime.  Of course, this assumes you don’t have a duel site and failover capabilities, which many companies can’t afford. 

 The issue I have with what the session leaders/presenters state is that they aren’t familiar with the processes that make up a service.  Thus, when a service is to be restored some corporations have forgotten that a service isn’t just made up of the facets that are seen/experienced by the client but are also made up of other smaller functions – processes – within other areas that aren’t seen by the client/customer and can cause serious issues if they aren’t available.  If some of these smaller processes aren’t available, then the overall service won’t be functional or available – at least not in the way the corporation may expect.

 A service can be made of many processes; some are directly related to the customer/client but others may be dependant / inter-related functions that are behind the scenes.  In many instances, these smaller dependencies aren’t even known by the corporation because they seemingly appear not important or serve any real purpose.  However, sometimes the smallest item when not available – the smallest process – can have the biggest impact on the service availability.

For example, let’s look at a car.  It’s made up of many key pieces, right?  Of course it is.  When you think of a car you might think of it’s engine, its tires and many other aspects that make up the car.  When it comes of the manufacturer’s floor there is a small component, that if it’s not made available, won’t make that 2 tonne car operate; gas.  No gas means the car won’t operate, not matter what you do.  Though, you may still believe you’ve delivered your service – the car.  It looks like its supposed to, meets all the Quality Assurance specifications, shines beyond believe and has all the various extra components desired.  But no gas – the forgotten process, so-to-speak – means no car or no service.

It takes many various processes to create a service.  A service isn’t a single entity but a collective of various processes from multiple departments, that create that service.  The processes can be directly realted to the delivery of the service – like a call centre representative or a salesman on the show room floor – but they can also be support roles.  Like the various phone systems or applications needed by that call centre representative or those that make the cars in the show room sparkle, making people want to buy them. 

It’s unfortunate, but many organizations don’t understand the two concepts and focus solely on the service, without realizing the service is more than just one single thing.  It can be applications, IT servers, people, facilities and processes ; some key some not so key. 

I have to admit, that the AS/NZ 5050 standard is the really the first time I’ve seen it captured clearly in a documented format (and thanks to Ken Simpson for bringing the standard to my attention).  I think this is a very important aspect for corporations to understand. 

I showed this to a colleague (someone not in BCM) and the got it right away because it was clear to them rather than some – and I do mean some – of the material that is out there.  I liked what I saw when I read this because It’s what I’d been saying and doing for years. 

When people or corporations understand the difference between a service and a process and how they relate to each other, it would really open their eyes as to what BCM is responsible for and how it can help.  It’s not just, ‘IT will make it right” or “IT knows what we need” but rather, this is more complex than originally thought and there’s more consideration that needs to be given to contingencies / recovery restoration activities than just get a single service up and running.  You’re actually recovering/restoring numerous processes to get the service up and running. 

Granted, there are processes within a service that may become available at a later time – a later Recovery Time Objective (RTO) if you will – but it will still take a few processes to become available to get that one service up and running; even if it’s operating at a reduced capacity/capability. 

Not understanding the difference between the two and identifying what processes make up that service can mean the wrong IT components are recovered that support the service and no support/direct related components are available to ensure the service becomes available.  I’ve personally seen restoration/recovery strategies that are based around an application that had the most users, when in fact, it wasn’t the application that customer/clients needed.  It was simply the most commonly internally used application, so the powers that be thought it must be what they needed to keep their services available.  Boy, did they find out how wrong they were when they did an exercise. 

I’ve said it before; you can’t develop your services/products at the snap of your fingers (it can takes years to develop that) and if you have a disaster you can’t snap your fingers and have everything back the way you want it.  You have to build it piece by piece; service by service – and all the processes that make up those services. 

I’d suggest doing a real assessment of all the processes performed by each department (a Business Impact Analysis (BIA) if you will) to help identify what you really need in a disaster.  I beat you’ll find some surprises.  Heck, I bet you find that some of your services have more dependencies than you thought, which aren’t accounted for in restoration/recovery efforts. 

 To add some fun to the mix, processes can be made up of many tasks/activities, which again, probably aren’t accounted for either.  Some of these little activities within processes, which make up a service can be show stoppers if they aren’t accounted for. 

 So know the difference between them all.  You can make sure you have the service up and running but what activities and what processes are needed to allow you to do it?  Make sure you know or else you could be standing on the showroom floor with no cars to sell.  

**NOW AVAILABLE**

The new book by StoneRoad founder, A.Alex Fullick, MBCI, CBCP, CBRA, ITILv3, “Heads in the Sand: What Stops Corporations From Seeing Business Continuity as a Social Responsibility.”  Available at www.stone-road.com **