Dear ITIL, it doesn’t have to be complicated

ZDguideDisclaimer: Most of my readers will know that I’m affiliated with Zendesk. Zendesk do pay me for content and consulting on ITSM and knowledge management stuff. This book review I’m about to do, which covers mapping Zendesk functionality to ITIL processes, has not been commissioned by Zendesk, nor endorsed by them. It is my objective opinion as an independent consultant.

A couple of weeks ago Crystal Taggart released a short guidebook to the Amazon Kindle store. This isn’t the first guidebook she’s released; there’s also a Quick Start Guide to using Axure 7 for rapid prototyping and 10 Secrets for Launching a Software Startup. Crystal describes herself as a technologist and entrepreneur who specialises in creating and implementing solutions that solve business problems. Her most recent book, a Zendesk Quickstart Guide is a step-by-step guide to mapping ITIL processes quickly and easily.

It’s no secret I’ve always liked Zendesk for how it looks, but I’m also a strong believer in their philosophy of “beautifully simple”. We have a tendency in IT operations to over-think things and sign off on expensive lifecycle solutions with All The Things where we’re likely to end up using only a fraction of the available capabilities. Crystal’s book describes an implementation of Zendesk that covers Incident, Problem, Change and Release to the requirements of her client. “The goal was to write a book that would take the reader 1 hour what took me 3 days (and 17 years of experience!) to do.” That’s a bit different from the months it can take to rollout a more complex solution.

She starts out by defining each of those processes and acknowledges that the set up she recommends made sense for this case, and that your mileage may vary depending on your own needs and circumstances.

Crystal maps ITIL terminology to the Zendesk ticket type terminology in the following way:

  • Incident = incident
  • Request for service = task
  • Request for information = question
  • Request for change (or enhancement request) = task
  • Change control = task
  • Problem (or defect) = problem

Tasks are used in place of incident tickets to allow for SLAs to be set up for different categories—a known issue vs an enhancement request, for example.

The book then goes through the step-by-step details on setting up groups that take ticket assignments and custom fields on tickets that feed macros, triggers, automations, and reporting for problem management. Crystal offers definitions for the different priorities of urgent, high, normal and low and designs automations accordingly.

After a brief explanation of how the Zendesk Help Centre can be used as an IT knowledge base, you can learn how to integrate Zapier to have change control notifications created to automatically populate a knowledge base article. This is a really clever, but kind of painful and complicated way of achieving something that should be able to happen natively. It’s the one significant bugbear I have with Zendesk—that knowledge creation is not a part of the native agent workflow, beyond searching for existing articles. The classic Zendesk forums, pre the launch of New Zendesk and the Help Centre, did have the functionality where you could create an article from a ticket with a single click, so I am confident that ability will return some day soon.

The book also provides a plan comparison, but do your own analysis there, because I’m not sure the details are completely accurate.

For not much more than $9, this is a great guidebook for any Zendesk administrator aspiring to meet some level of ITIL adherence in their organisation, or for any ITIL-aware organisation that is considering Zendesk. It’s a beautifully simple explanation (I only wish I’d written it), but it’s not the only way to approach it, so keep in mind that your workflows may change as your processes and organisation matures.

 


The book that changed my mind

everythingismisc

I’ve talked about my preference for ordered taxonomies before. In another article, I even claimed that folksonomies weren’t scalable. Everything is Miscellaneous: The power of the new digital disorder, by David Weinberger may have just changed my mind. Published in 2007, the book isn’t new, but I came across it on a list of recommended reads for knowledge management.

Weinberger, co-author of the international bestseller The Cluetrain Manifesto,  has an easy-to-read conversational style. In Everything is Miscellaneous, he lays out humankind’s fixation for heirarchy across history. “[O]ur knowledge of the world has assumed the shape of a tree because that knowledge has been shackled to the physical.”

From Aristotle to Apple and Amazon, the way we work with information and knowledge has changed. Apple freed our music libraries so we could order our music how we wanted. Amazon clusters books in as many ways as we can so that we may discover what we want as well as find what we know we want. In Amazon’s world we can make our own top 10 lists—tagging and categorising books in the multiple ways that make sense to us as individuals. Collaborative filtering then displays other books that Amazon thinks we might like.

That’s when I opened my eyes.

I’ve espoused careful categorisation because I believed it meant for easier browsing. But with a digital knowledge base, who browses in order anymore? Not me. I have a carefully ordered list of bookmarks in my web browser, but I don’t look down that list, I rely on auto-completion and Google, and that is no-doubt common and quicker. I took a long, hard look at my own behaviour and realised I’ve been holding onto a hard-copy way of looking at the world.

Weinberger argues that it’s the metadata that holds the value in the way we can make new connections, new knowledge. In the miscellaneous world, everything is metadata. So, in our knowledge bases, how do we decide what metadata to collect; how do we decide the ways in which the user can create their own information display based on that metadata. Many of our knowledge base tools constrain us to categories, forcing us to decide how the reader should experience what we want them to know. But what if our knowledge bases were more like Amazon? “People that read this article also read this one”, or “this article is in the top 10 list for others in the marketing team”, etc.

This book seems to be about offering new ways of working with digital information, but it’s so much more than that. It highlights our reflexive grasp on hierarchy in the real world, too. Just as Apple democratised music playlists, Zappos’ Tony Hsieh is taking structure out of the organisation. Is that just the beginning of what could become miscellany in the corporate world? It makes sense that cross-functional roles could get more done in an organisation, because they don’t have to present their ideas up through the hierarchy of one silo and then have it be passed down the next. We reflexively grasp order though, because we don’t want to think too hard and come up with new ways. Hierarchy, steps, pre-defined order—it’s all automatic pilot—but it’s also conforming to someone else’s idea of how things should go.

A miscellaneous world may seem chaotic but it’s filled with boundless opportunities.


Book Review: The Phoenix Project

The Phoenix Project - a business novelLate last year I was lucky enough to get an early preview of The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. Written by what seems to be the holy trinity of the DevOps movement—Gene Kim, Kevin Behr and George Spafford—the book has only recently been released and is already #1 in Amazon’s Information Management category. I can see why.

The business novel genre is not somewhere I’d normally find myself. Comedic autobiographies and Clancyesque action-fiction is where you’ll generally find me. But when the manuscript landed in my inbox, I started reading straight away. The Phoenix Project tells the story of an IT manager, Bill Palmer, being assigned the hapless task of fixing a chaotic and messy IT environment within 90 days.

When I met with Gene last October, we talked about our past experiences, we talked about our hopes and dreams, and we talked a lot about IT and the similarities between it and manufacturing. Indeed, The Phoenix Project is inspired by well-known predecessor of the genre, The Goal, by Eli Goldratt. And that’s why I’m late to the party with my book review, because I wanted to read The Goal, too. Well, I’ve read it now, so where’s my honorary MBA?

All kidding aside, The Phoenix Project absolutely succeeds in what it was set out to do—teach us good business and IT practices through storytelling. In fact, I’ve already had occasion to draw on scenarios from the book to help my own decision making in the workplace.

Even ignoring the DevOps angle to this story, so much of this book will feel familiar. You’ll feel like you’re reading about your own organisation. Every one of Bill’s colleagues are so amazingly representative of my own past IT colleagues, it’s a little discomfiting. Clearly, we are all just archetypes copied and pasted from one IT department to another across time and space. In terms of the characters, I came away from the reading with one small criticism. At one point in the book obstructive Chief InfoSec Officer, John Pesce, goes off the rails and is uncontactable, but then resurfaces a few days later, clean-shaven and helpful. We aren’t given an explanation and I closed the book still wondering what made him change his ways. Sequel? Nonetheless, my one gripe doesn’t impact the central plot.

The Phoenix Project is a compelling case study in failing fast and continuous improvement in IT operations. Experienced managers will love this; CIOs need to read this.


Archives