Skip to main content

ITSM, ITIL and DevOps – an education process

Originally posted on The AXELOS Blog - by @itsm_Donna


In IT service management (ITSM) education is critical: it helps organizations get a shared understanding of terms and concepts and a proven body of knowledge such as ITIL®.

The IT industry is rife with buzzwords carrying varied interpretations, so education helps get everyone on the same page. But while ITSM professionals may well understand the “what?” and “why? – for example why to minimize risk or restore services ASAP – today it’s the how that needs to evolve and change.

And while there is always value in education, achieving certification creates a different level of engagement: people get involved and – critically – seek to understand. Getting certified allows you to represent your competence and understanding of the concepts you’ve learned. After that, you need to get out there and apply them to benefit your organization and add to your credibility and your baseline of experience. Today’s hiring managers are looking for that combination of education (certification) and experience.

The ongoing relevance of ITSM

ITSM remains relevant today with its focus on value and the needs of customers.

As business increasingly needs IT to take a leadership role in harnessing new technology and ensuring the right mix of services at the right cost, ITSM helps organizations understand this.

For people working in organizations at every stage of ITSM maturity, proven practices are a great starting point; learning from those who have been down the path before and jumpstarting activities without trying to reinvent the wheel.

Indeed, ITIL provides some of the basic concepts needed in our world today: it provides a big picture understanding of how to achieve the ultimate balance; providing innovative services and focusing on customer needs, while ensuring reliability and stability of services. Its core practices are still relevant and can evolve from where they are, continuously improving from a sound starting point.

Advocating ITIL Practitioner

Since its introduction in 2016, ITIL Practitioner has emphasized key concepts that were already there in ITIL, such as continual improvement and adopt and adapt. They’ve just been brought forward and highlighted.

This need to continually improve and evolve – and the competencies required to do so – speaks to organizations that believe they can “implement” ITIL and forget about it. It doesn’t work that way! Practices and processes must continually evolve as the organization’s circumstances, needs and goals evolve.

The authors of ITIL Practitioner deserve particular credit for the 9 Guiding Principles which embody many of the agile, lean and DevOps values needed in today’s IT world; giving people a succinct vocabulary they can use to navigate improvement efforts and to help change the way people think and work.

ITIL and DevOps: "either/or" or complementary?

While ITSM delivered via ITIL persists, what has emerged in some organizations – often as a backlash to heavyweight ITSM processes – is DevOps.

However, people sometimes forget that DevOps has a very specific scope in software delivery. And not necessarily all software. It relates to applications where speed makes a difference to the business. ITIL is much broader than that and there is still a need to manage services, handle incidents and create service desks that provide great support. So, it’s not about throwing out years of proven and evolving practices in favour of DevOps which is still evolving itself.

It’s not either ITIL or DevOps; they are complementary. ITSM professionals need to understand DevOps and how service management can be adapted to enable and support DevOps because its promise is awesome. To remain competitive businesses need what both ITSM and DevOps have to offer.

Multiple frameworks and ongoing education

No one framework has all the answers and the risk is when people believe they can do everything with one framework. The biggest thing for ITSM professionals is to understand the different standards and frameworks, exposing themselves to new ways of thinking and working and choosing what part they play in delivering overall value and organizational improvement.

Maintaining our commitment to education will help us get where we need to be. That’s why we should be excited about the ITIL update and how it will address the needs of the ITSM community. The level of outreach to the community in this current process gives me confidence we will get there.

For more information please see our website

Comments

Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you.

Roles and Responsibilities:
Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance.Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables. An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the policies (r…

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service".
I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize:
SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle.
ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with the needs …

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?
Thanks, René W.

Answer: René. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to…