ITIL with a Beer

At last my second blog post contribution and this time it is about my obtaining additional ITIL certification.

So you might ask:

• What is ITIL?
  Its expansion is Information Technology Infrastructure Library.
  
• Why do we need it?
  It is a standard of best practice in IT industry.
  
• Does it have a purpose in my life?
  No, but it might change your way of thinking before telling your team that it is an easy change request (so perhaps yes!).

Brief history: ITIL was used during the mid 80’s and it’s first book was published in 1989. As technology advances, it’s latest version appeared in 2007 in the form of the ITIL v3 version. Note that books were updated on 2011 with the name “ITIL version 2011”.

There are five steps that define the ITIL lifecycle from the Strategy till the Continual Service Improvement, but before even getting into details, let’s think of an example.

 

The Business Idea: BeerBuddy

It has been three years that I have been dreaming of having a solution or an app to find friends on real time, spontaneously to simply have a drink together after work. However, contacting several individuals to find their availability, and planning a simple task of spending time together at a short notice gets really difficult.

Therefore I thought about making an app that would help me find friends for having a beer. This application would be an event creation app with the objective that people would get a short notice between 30 minutes to, say, 2hrs, for responding. If two persons are having a drink at a given location, every other friend in that group is notified that there is something happening and, if they want to join, they are welcome.

The main idea is to be spontaneous because sometimes after a hard day of work, one needs to chill with friends. The name of the app is “BeerBuddy”, which is self explanatory.

Now, having found the idea is great but one should never hurry to develop and instead, take time to analyse how we could achieve this outcome. Let’s see how ITIL would approach this Business Case.

Obviously, it is a simple analysis of the ITIL concepts as each lifecycle has a book, but it will give you first understanding of what are the key aspects in a service with a business case.

BeerBuddy: Service Strategy

The first step of each service is to define the correct strategy and the customer’s business value. Most of the time, perception, preference and business outcome have more value to customers than imposing a generic solution used by the business.

As a customer, my need is to have a solution/app that is quick, easy and that gives me an answer within a few tens of minutes to check the availability of my friends in a given group who want to have a drink spontaneously. Eventually, I don’t want to pay a big amount for maintaining this application (server, licenses or other) but I want it to have a reasonable capacity so that other people in the group could also use this solution/app effectively.

As a service provider, I have to analyse what kind of service my customer wants to have, what should be the processes, activity and scope of this project. Before even designing it, I need to define what are the objectives, risks, financial consequences and potential problems that might occur.

In this case, BeerBuddy might have more impact in a app model but developing would be more expensive. Otherwise with a service approach, it would imply dependencies with other providers. Final decision will always depends on the time frame and the available resources (budget and time) and, in our case, I would preferably try out the app development (as I want to learn Android/PhoneGap/Swift).

BeerBuddy: Service Design

Once the strategy is set, it is time for designing the solution with the 5 aspects of Design for BeerBuddy:

• Service Solution:
  • What are the key features of the solution?
  • Are they different components needed?

• Tools & Technologies:
  • What tools and technologies we would need for this app?
  • Can we do it with Adobe PhoneGap (multi-platform deployment framework for mobile)?
  • Could we use web tools and simply create a mobile interface and simulate an app?

• Architecture:
  • Do we need a server?
  • What kind of security do we need for servers?
  • Can we achieve the same business object by simply doing an adhoc communication?
  • Do we need to use design patterns?

• Process:
  • What are the processes involved to create an event?
  • How should communication between people be carried out (in the app, SMS, e-mails)?

• Measurement and metrics:
  • How do we measure that an event was created?
  • Do we need to store this in a secure database?
  • Could we use BI tools for reporting?

Obviously, there are many more questions that we could ask at this step (capacity, availability, etc..), but the main idea is to challenge yourself before designing. For bigger project it is often needed from the provider to realise a “Proof of Concept” to insure that the design is adapted to the business needs and potential technical risks are detected as well as resolved.

BeerBuddy: Service Transition

Once the design and planning are finalized, the next step is the implementation of the solution. The transition part is more focused on the following aspects:

• Build: Building the solution and integrating all the design aspects is quite important. It might happen (honestly, in almost all cases, it does happen) that while implementing the solution, there are some issues that were not analysed before and therefore, we might have to redesign some features. It is important to note that if I am doing some sprint during my implementation phase ( Agile IT or Scrum), these changes must always be considered.

• Configuration and Control: If I am not developing from scratch and instead using a tool for achieving my solution (Sharepoint, SaaS or any CMS), I have spent time to adequately configure the solution to satisfy my particular need of having a beer with buddies.
  In our case, for an app, it is also important to develop in a generic way such that the configuration and control can be modified when the business case changes (when possible, avoid hardcoding by giving more flexibility!).

• Support and Training: Implementing an app is nice but using it correctly is nicer. Therefore, I need to provide some support (phone, e-mail, etc..) for my users if they have any questions. If needed, I can also train them, but as my app is pretty simple to use because I will invest time on the UX then there shouldn’t be any training needed.

• Test and Validation: Obviously, when the solution is ready, it should be tested (with several test cases) and validated by the developer. Usually, it is not the funniest part but it is a good way to check that there are no business or technical issues. The QA (Quality Assurance) is often left behind as it has a huge cost in the implementation of a solution, but it is important that a reasonable degree of QA is guaranteed.
  For big solutions where many people (integrators and developers) are involved, continuous integration would optimize cost of quality testing and integration.

BeerBuddy: Service Operation

After execution of the first three steps, BeerBuddy is ready and working but not yet fully satisfactorily. Usually, there are some small issues that need fixing before it is able to show the desired performance without any crashes. User might have some incident happening  when a new event is created or there are some non expected issue in my scope that have appeared because of capacity of my database. Therefore the focus now shifts to different aspects, such as:

• Event management:  There are always events triggered once a solution is ready and it is important to detect which one are critical. Event should then be classified into there correct type (Information, Warning, etc..) and their priority (minor, major, critical, etc…).

• Incident management: The main purpose of Incident management is to restore service back to normal while minimizing impact on end user agreed on the SLA (Service Level Agreement). Depending on the gravity of an incident on the business, it should be escalated to management.  When a Incident is reported (by a user or other support team), it should follow a particular workflow process:
  • Identification
  • Logging
  • Categorisation
  • Prioritisation
  • Initial Diagnosis
  • Escalation
  • Investigation and Diagnosis
  • Resolution and Recovery
  • Incident Closure

• Request fulfilment: When user request a new or predefined services for a solution, they usually contact the service desk for advice. Depending on the size of the company and the services provided, it is needed to have some documentation and predefined authorization for these services.

There are process in the service operation with Problem Management and Access Management, but for our business case with BeerBuddy, it doesn’t have much value for the moment.

For BeerBuddy, as it is a small application, there won’t be much support (except if by some luck, it become a hot app with millions and billions of users… ). Note that as I am an Indian born, and Swiss trained, I should be able to provide you with the best support service, so you can trust me that one indian specialist would be suffice!

BeerBuddy: Continual Service Improvement

Now the solution is online, is active and is used by many people. If there are some incident, I am available as support. So this should be the end, but I thought about some new features that might have a better value for some customers. Some new ideas can be listed as follows:

• What if instead of simply saying “Yes or No” to an event, we would respond with a number like “Yes, I am coming at … %” ?

• What if we could find out (with the accumulated data) if a person is reliable when he says that he is coming to an event?

• What about privacy? Could we simply destroy the event once it is over?

• Could we expand this business to the next step, let’s say for helping people in need in a hospital environment? On volunteering when a natural disaster happens in a country? 

Therefore we need to structure all these ideas with a model.

CSI Approach Model

• What is the vision?
  For a solution (or company) to grow, long term business vision is one of the critical fact of success. For BeerBuddy, it might be a simple solution for people to have a drink, or it can go beyond that and use it for other application of spontaneous actions. Imagine if we could be spontaneous for some urgent need in a country or we could handle critical situations where resources are needed in matter of minutes. There is always a great scope for new ideas!

• Where are we now?
  Once a solution is provided, we need to assess that the solution is used by our customers and that the main business objective is reached. Did the solution also have a impact in our structure?
  In the case of BeerBuddy, if I am able to simply gather friends for a glass of beer, I am happy!

• Where de we want to be? 
  Setting up targets, with timed milestones always has a better impact than simply having ideas. Before reaching measurable targeted objective, identification should be processed with the team for achieving a higher-quality service provision.

• How to get there?
  Achieving objective needs to have defined process improvement discussed in at the vision level. Can the BeerBuddy system be reused with the current technology? Do we need to create a new project for a new business ideas? Do we need to create a product then?

• Did we get there?
  With the use of metrics and measurements, we can define if the milestones has been reached. It is usually compared with the baseline for the me “Where are we now” question.

• How do we keep the momentum going?
  When a change in the system occurs, organization will always take some time to get used to the new UX, new way of working and using the applications. The aim is to establish new baselines for the next improvement.

BeerBuddy: Conclusion

It took me a while to change my way of thinking before using some method. I have learned that even though there are many tools already available that could reach my business outcome like MeetUp. But for the moment, none let me choose a group of friends that will let me have a simple beer with some buddies (or  I am not yet aware of). So for the moment, I do it the old fashion way by calling friends after work.
And sometimes it doesn’t work as planned…

 

Reference:
– Foundation of IT Service Management, Brady Orand