Neven Zitek Whenever I’ve become engaged in conversation regarding Vital Business Function (VBF), at first it looks like everyone knows what it is. As conversation progresses, several variations, or very different definitions appear, after which a “Google race” starts in order to find out which one is the closest to the ITIL definition, and that person usually wins the argument.
While ITIL defines VBF as a Function of a Business Process that is critical to the success of the Business, it actually tells you very little about what constitutes “critical,” and this is the point where all arguments begin. Such discussions are generally benign when performed with your peers, but they may be very serious and have grave consequences if they occur between a business and its IT service provider.
Clash of the Titans
IT is a master of technical competence, and as such they tend to compare service requests with existing features of hardware, software, or whatever the current topic is. Even a slight match between the stated requirements and existing features is often seen as “perfect fit” and may never be questioned again.
Businesses usually have a hard time explaining and unambiguously stating their requirements. It gets even worse when they attempt to use “IT language” to do so. Due to greater competence within subject matter, IT will “guide” the requirements to achieve that “perfect fit,” and will be able to justify the changes with “that is how stuff actually works; therefore, it must be what you want.”
Such an arrangement during the service design process has a high chance of ending up operationally costly, or unable to deliver the expected utility or warranty (or both). You can bet that poorly communicated service requirements will surface at some point during the Service Lifecycle, and then it usually costs too much to change, or may be even impossible to change without redesigning the whole service.
It’s not just a theory
Let’s take an example of ATM (automated teller machine, cash machine, cashpoint, cashline, bankautomat) service, which is one of the important services for any bank. It allows you to withdraw money from your account, check your balance, deposit money, and nowadays you can purchase additional services such as prepaid cell/mobile credit, movie tickets, lottery tickets, train tickets, gift certificates, make a donation to charity or even buy gold. Out of all of those services, only withdrawing money from your account can be considered a vital business function.
When communicating the requirements, a business may state that ATM is the vital business function. Without looking deeper into the layers of the ATM service, the service provider may deliver an ATM that prevents you from withdrawing your money if the ATM is unable to print a receipt – even if you have enough money in your account, and there is enough money in the machine. This scenario happened to me, as a bank customer, and I found it very inconvenient and unacceptable. I don’t care if all the other services the ATM provides are working if I can’t withdraw my money.
Back to ITIL
Within ITIL, Vital Business Functions are used in Capacity, Availability and Continuity management.
- Capacity Management uses VBF in the Capacity Plan to ensure adequate service capacity and performance.
- Availability Management uses VBF in the Availability Plan to design services and maintenance procedures that meet required availability targets.
- Continuity Management uses VBF in order to perform risk assessment, disaster avoidance, and recovery planning.
VBF is a living document, and should contain the story that describes the importance of services listed. It should also contain a technical section that identifies underpinning IT services using CMDB (Change Management Data Base), and related CIs (Configuration Items), and of course all other resources essential to VBD such as people, other processes, products, or dependencies.
Determining Vital Business Functions
True VBFs can only be identified with lots of conversation with the customer, by understanding their business and their users.
- Communicate with the Customer to understand what is really important to them.
- Communicate with the users to understand how they use, or plan to use the service.
- Translate technical activities into business activities (vice versa isn’t recommended).
- List all agreed and important aspects of business on which IT should focus, using clear and unambiguous vocabulary.
Start with critical business services – services the business depends on, and can’t continue without. This may include services whose unavailability will generate great loss (monetary, legal, environmental, etc.) to the company or the organization. Look for business functions that must operate continuously.
Converse with the customer in order to learn what’s important to them. Never let your personal opinion or criticism cloud your understanding; technical competence over the subject matter doesn’t make you superior.
Overcoming listening barriers
Any complex system should be broken into smaller parts and dependencies first, and the customer may not always be able to elaborate on the inner workings of the business system, especially if it’s tied into an existing IT product or solution. For example, many companies today use internet and web services as part of their daily business operations; the Customer may declare Internet to be a VBF, but there is a great difference between designing and operating high-speed, always available, robust and redundant internet access, and accessing currency exchange rate – if that is only internet-based service the business depends on.
A key success factor for determining VBFs is active listening, even for the things that may not have been told. Transforming that conversation into a structured document may even require having a bit of poet in you; as poets don’t write down their thoughts – but rather voice those things that common people hear as background noise. So, I guess in order to settle the arguments from the beginning of the article: the answer, my friend, is blowing in the wind…
Look here for a free preview of the Availability, Capacity and Continuity Management process.
