An important principle of ITIL is that all requests should go through a single point of contact (abbreviated to SPOC). What this means, is that a single channel should be defined for the reception, classification, and distribution of a request or incident. Crucially, it does not mean that all contact with the customer should be done by tier one.
In December of 2016, I discovered Bear Writer. At the time, I had been using a number of different solutions for note-taking and organisation, none of which had really done the trick for me. That all changed with Bear. Arriving to critical acclaim, Bear is certainly a very pretty app, and its iCloud sync feature has served me well enough. There has just been one issue; it is only available on Apple devices.
In recent years, a number of approaches to taking hand-writing and turning it digital has come to the market. From tablet computers to writing tablets with e-Ink technology, there are plenty of offerings out there, none of which has scratched my itch for hand-written notes. Tablet computers tend to be too slick and slippery, resulting in a less than satisfactory writing experience, and e-ink writing tablets are – at least as this is being written – just not good enough for my use.
As should be clear to anyone who has read any of the other instalments of this long series of reviews of the Model S, I am a very happy Model S owner and driver. The car is comfortable and fun to drive, while getting me from a to b with a minimum of fuss. I have not, however, claimed that it is the perfect car.
Ask anyone who has a glancing familiarity with Kanban what they know of it, and one of the (if not the) first things they will mention, is the use of a kanban board. This is true; the kanban board, whether physical or digital, is one of the most visible parts of the Kanban method. It is an eminently visual way to represent WIP. So, how do you implement a kanban board in IT support?
In keeping with my tradition, I am inviting you to take a look at the year which is about to end with me, as it pertains to me, my life, and the blog.
This is one part of the review I was not expecting to write, yet events would have it another way. Back in April, while on our way to kindergarten and work, a pedestrian suddenly stepped into the street (just ahead of an SUV on my left). With one bad option, and the other significantly worse, I opted for the bad one, and veered right, ending with the front end planted into a lamp-post. My quick reaction resulted in no serious damage to anyone, though the front end did suffer more than a little:
The title of this post might seem a bit on the conceited side. After all, who am I to claim to be a DevOps practitioner, much less thinker? I will simply say that I am working to implement DevOps principles in my day to day life, am spending more than a little time reading, thinking, and writing about DevOps, and though I may not be considered a DevOps thinker today, I certainly aspire to join their ranks. The title, then, is a statement of aspiration, more than a statement of achievement.
When I wrote my blog post about important features of a service management tool, I wrote “I am increasingly coming to believe that the change management process is perhaps the most important one for success in ITIL – not to mention DevOps – adoption” – and I stand by that assessment. Not because change management is such a revolutionary idea in and of itself, but because of what true management of change means for a business.