SysAid Blog

Blog Home
Welcome to the SysAid Blog - the place to go to find out where the IT industry is going, and what is SysAid’s role in it.

SysAid 15.2: Your Voice, Your Service Desk

Posted by on June 3, 2015 in SysAid
SysAid's new service desk release I have a confession to make: for me, the most exciting times, in the realm of my job, which I have the privilege to take part in, are the official releases of SysAid Help Desk Software. Even today, after orchestrating over a dozen On-Premise official releases, I still get the same excitement and butterflies in my stomach…. I am writing this blog after finalizing a great beta with our Pathfinders who helped test and fine-tune this release so it will be optimized for all of you. The content of this release is especially focused on your requests. 100% of the enhancements and fixes came directly from all of you — our customers. We always put resources on issues and challenges you raise to us; this time we put all of our resources on your issues.

What’s New in SysAid 15.2?

I would like to pick a few of the enhancements that I think are particularly worthy of sharing their story. The first bunch of enhancements is related to the SysAid Agent. We had several improvements over the past few releases, and 15.2 continues that momentum.

Ability to Download Agent Logs from Within the Asset Form

Simply add the get logs field to the asset form and you’re able to download the logs of any SysAid Agent. This enhancement is actually one of those issues that “helps you help us to help you….” SysAid Agent logs are usually required for our support engineers to help troubleshoot and solve issues that you encounter. Our agent for Windows is installed on millions of machines worldwide, and the variety of OS versions and flavors challenges us every once in a while. SysAid has an extensive lab where we test and re-create issues, but no lab can simulate your real environments. So when you report issues, the logs help us improve our agent. We just made retrieving these logs much easier for you, and it will definitely help us improve in helping you :).

Ability to Set Various Agent Settings from the Asset List

Continuing the agent improvements, you can now set various agent settings from the asset list, by simply selecting a single asset or a group of assets and changing their settings. This comes in very useful when you want to activate or update features on your agents, as you can easily do it from the asset list. It also keeps track of the version of the agent settings, so you can have better visibility on what settings the agents are using.

Efficiently Stop the Agent from Running

The last feature in this set is an efficiency feature — the option to stop the SysAid Agent from running when it loses connection with the SysAid Server. This is done in cases where the SysAid Agent fails to contact the SysAid Server over a very long period of time, so you can assume that something is wrong and it will never be able to contact the server. The new feature in 15.2 makes the agent give up trying by stopping the service, i.e. the SysAid Agent. The idea behind this is to be more efficient in cases where due to wrong settings, or any other environmental change, the agent can’t reach the server, creating unnecessary network traffic. In most of these cases, the issue won’t be able to be resolved from the server anyway, so we just taught the agent to give up trying until told otherwise. Once the issue is locally resolved, you can simply start the service again and set it to run on startup.

Third-Party Integrations

Third party integrations are a great way to enhance the capabilities of SysAid with other software. For SysAid 15.2, we developed a mechanism that allows you to dynamically add these integrations as “add ons”. One small ZIP file contains all the magic required to integrate SysAid with LogMeIn, Bomgar, Google Apps, and more. The greatest thing about having this mechanism in place is that we can now provide you with add-ons that, in most cases, won’t require a server upgrade. Over the next few months, we’ll be making available a large set of add-ons that will work with 15.2 and future versions.

Security Fixes

We also tightened SysAid security by fixing multiple security vulnerabilities that were discovered. As you know, new security threats pop up all the time, which is why we have a dedicated process and team to handle these threats and provide a quick turnaround. SysAid 15.2 includes a new set of enhancements that tighten the security surrounding the database, uploading files, and more. This release has a lot more enhancements and improvements, and I am sure you will all enjoy them. We’re already busy working on the next set of enhancements and can’t wait to deliver them to you! Meanwhile, though, you can check out this video we prepared that goes through many of the 15.2 enhancements. [embed=videolink]{"video":"https://www.youtube.com/watch?v=PV664Jm2NN8","width":"400","height":"225"}[/embed]

Like this article? You may also like: SysAid Support is About to Get Even More Supercalifragilisticexpiali-Help-You!

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

We Need to Talk…About Change Management

Posted by on May 27, 2015 in ITIL
Change Management process You know those awkward conversations that start with “we need to talk”? Well, it’s time. We need to talk. About ‘change management’. Ever see someone endorsed for ‘change management’ on professional networking sites, and wondered what kind of change management?  Ever thought, “wait, they don’t know anything about IT Service Management”? There seems to be a fair amount of confusion around  the term ‘change management’. Most of us IT service management folks think of IT change management, emphasis on the ‘IT’. Project managers think of changes in the scope or definition of a project - change management being the formal process to review and approve material changes to the project scope, schedule, or resources. Yet another is organizational management of change, frequently known as ‘change management’. This change management has to do with the people aspects of changes in an organization, and is sometimes used interchangeably with ‘transition’.

A Rose by Any Other Name

Add to these a host of also-known-as variations:
  • Change control
  • Change board
  • Change enablement
  • Change leadership
  • Transition management
  • Management of Change (MOC)
  • Change adverse culture
Not to mention:
  • Game changer
  • Culture change
  • Theory of change
  • Change agent
  • Course change
  • Change framework
And my favorite:
  • Spare change
Adding to the difficulty is that many of them are closely related. ‘Change control’, for instance, is often used interchangeably with ‘IT change management’. ‘Change board’ and change advisory board (CAB) are often used to describe the same thing. Change management is a process that’s covered in the ITIL® Service Transition lifecycle. Change agents and change leadership usually has to do with leadership and the ability to achieve change in an organization. In the United States, Management of Change (MOC) is a well-defined standard for risk management, generally associated with occupational health and safety in manufacturing and facilities management. It’s no wonder there’s a lot of confusion surrounding change management.

Time to Face the Strange Cha Cha Changes

Each term is important in its own right, and has a context-specific meaning. The problem isn’t so much confusing the terms themselves. That would be easy enough to clear up, and you can usually derive the meaning from the context. No harm done. Where there’s a problem is when the meanings get confused,andit happens more than you might think. Shall we, as David Bowie famously put it, turn and face the strain?

IT Change Management

Over the years, I’ve come to add ‘IT’ in front of ‘change management’ to make it more clear to what I’m referring.  ITIL doesn’t make this distinction; I’ve just found it helpful to avoid misunderstandings. IT change management, then, is the process that manages the lifecycle of all IT changes.  Stuart Rance does a great job describing it succinctly in What is Change Management For? There’s no single right way to manage change, but when talking about IT change management, we’re generally talking about some variation on the best practices approach described in ISO 20000, COBIT, and ITIL. In short, IT change management seeks to:
  • Ensure timely and effective implementation of business-required changes
  • Appropriately manage risk
  • Minimize business impact and unintended consequences from changes
  • Ensure changes achieve desired business outcomes
Most IT people are familiar with the change advisory board (CAB). CAB is perhaps the most recognized component of change management. The change management process is triggered by a request for change (RFC), which is a record that describes the proposed (requested) change in enough detail that CAB can effectively evaluate it. Where it gets complicated is when IT change management has to consider the cultural implications of a proposed change. In these cases, organizational changes must occur for the proposed change to produce the anticipated outcomes. This is where IT change management intersects with organizational management of change, which is an altogether different thing than IT change management.

Organizational Management of Change

Whereas IT change management is focused on managing changes to IT services, processes, and infrastructure, organizational management of change is about managing people and organizations through changes of any type, generally separate from IT changes. Good examples include implementing a new work-at-home policy, outsourcing a function, reorganizing a division, or closing a site. Management would be wise to carefully apply organizational management of change to successfully transition to the desired new state. Prosci describes change managementlike this:

“Change management is the application of a structured process and set of tools for leading the people side of change to achieve a desired outcome.”

The key difference here is ‘…the people side of change…”, which is similar to, and yet very different from IT change management.

Hey Buddy, Can You Spare Some Change?

The Greek philosopher Heraclitus infamously said that the only thing that’s constant is change, and that’s probably about right. In our time, businesses must constantly change and adapt to stay competitive. That requires an IT organization that can execute changes with speed and precision. Good reason to be clear about what we mean by change management. That’s a change we can all agree on.

Like this article? You may also like: Change Evaluation: The Seven R's Revisited

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

The 2015 ITSM Show – The Greatest Show on Earth

Posted by on May 19, 2015 in ITSM
ITSM Show - The Greatest Show on Earth It may be in a completely different month to normal, and at a new venue, but the buzz around the upcoming SITS15 - IT Service Management (ITSM) Show (formerly known as the Service Desk and IT Support Show) is as intense as ever. After all, it’s one of the biggest ITSM events in the world (as what happens in Vegas stays in Vegas, we’ll just completely ignore that big shiny Knowledge thing), so what’s there not to be excited about?!

The Content

Whilst this event is primarily an ITSM tool vendor exhibition, its ITSM presentations should not be underestimated. Some of the hot topics at this year’s event include:
  • Service integration and management (SIAM) – what it is, it’s importance, and best practice
  • Customer experience – as opposed to user experience, it’s a new hot topic in ITSM
  • Service catalogue – still popular after all these years, but it is so hard to get service catalogue right
  • Continual service improvement – it should be the first ITIL “process” adopted but often gets lost in a melee of incident, problem, and change investment
  • DevOps – so hot you might burn your fingers, find out why its DevOps and ITIL, not DevOps instead of ITIL
  • Service desk success – listen to those who have been there, done it, and bought the t-shirt
If you feel a little spoilt for choice and aren’t sure which sessions to attend, then let me help with some personal recommendations based on my knowledge of the presenters and their chosen topics:

Day 1

10:30–11:30: Stuart Rance, Optimal Service ManagementPutting people before technology and process 11:30–12:30: Andrea Kis and Martin Goble, Tata Consultancy Services Creating seamless service with SIAM 12:30–13:30: Girish Mathrubootham, Freshservice** – Using service catalogue for non-IT functions 13:30–14:30: Ian Connelly and Gregory Baylis-Hall, BCSPerfecting the service desk personality mix 14:30–15:30: Helen Bayliss, AccentureBuilding a culture of Continual Service Improvement 15:30–16:30: Daniel Breston, QriousityDoing more with less – a crash course in lean ITSM

Day 2

10:30–11:30: Patrick Bolger, Hornbill** – Is collaboration the future of business IT? 11:30–12:30: Duncan Watkins, Corporate Executive BoardNext-generation IT service skills 12:30–13:30: Sarah Lahav, SysAidWhat IT can learn from external customer relationship management 13:30–14:30: Jon Hall, BMC** – Swarming – a radical approach to managing critical problems 14:30–15:30: Tobias Nyberg, Handelsbanken How to win at configuration management 15:30–16:30: John Fahey, STI TrainingRe-invigorating a tired service desk ** At SysAid we’re not afraid to recommend that you check out presentations by our competition. Good quality content is good quality content no matter where it comes from. If you also find time to squeeze in a keynote or two I also highly recommend the Women in IT panel (more information below), and “Does your business really need a service desk?”, hosted by Stephen Mann. As an aside, and as a polite warning to Stephen Mann, if the answer is “no”, then neither I, nor any of the other vendors attending the event, are going to be very impressed (i.e. prepare to be lynched).

The Exhibition

Are you looking for a new IT help desk, service desk, or ITSM solution? Or are you simply out hunting for the best free giveaways (*cough* our swag was voted the best at a recent SDI event)? Or perhaps you’re a huge fan of Joe The IT Guy? If you answered “yes” to any of the above, then be sure to add a visit to the SysAid stand to your agenda. In addition to showcasing our ITSM product, we’ll also be offering a first peek at our new mobile asset management module and application (on iOS), which provides barcode scanning, audit, and reporting capabilities. The new module (driven by customer feedback) helps to address challenges such as:
  • Loss of assets
  • The inability to track inventory, including checking out and in scenarios
  • Limited auditing and reporting capabilities
Swing by and we’ll provide you with a little more information. Then, as if that isn’t enough, when you drop by you can also pick up a Conference In A Box, packed with free information and wisdom around improving service management and customer experience (as well as free chocolate). Phew, that’s the shameless marketing plug out of the way, now back to the event…

Women in IT

In the run up to the event, the team behind the ITSM Show has launched Women in IT Week, an initiative to inspire more women to pursue positive career pathways in IT. The aim is to help bridge the gap of gender inequality within the IT sector; something that us at SysAid fully support (not least with a female CEO at our healm). I’m personally very excited to listen to the all-women panel on Wednesday 3rd June at 13:45, hosted by Karen Ferris, on why we should champion equality in the IT workplace. You can also enjoy the upcoming series of blogs, written by women in IT, on how they started in their career, and what advice they have to offer to other women interested in joining the industry. Karen recently kicked off the blog series by sharing her Six life lessons for every ambitious IT professional.

Customer Dinner

Just like last year, we’ll also be holding a special customer dinner after day one of the ITSM Show. Hosted just across the road from the Olympia venue, you can expect to swap stories and ideas with other SysAid customers, hear about the upcoming SysAid roadmap, learn more about how to get extra value from your investment in SysAid, and enjoy free booze and food (which will be much needed after a long day on your feet at the show – trust me).  There’s also a rumour going around that there may be some special free gifts for the customers that attend… The dinner will take place at The Hilton London Olympia on Wednesday 3rd June from 5pm – 7pm. If you’re interested in attending, please contact my colleague Kim Haimovic. We look forward to seeing you at the show! And don’t forget to follow the Twitter feed with the hashtag #SITS15. Image credit

Like this article? You may also like: What Can Estonia Teach You about IT Service Management?

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

COBIT 5 Plays Well with Others

Posted by on May 13, 2015 in ITIL
COBIT 5 plays well with ITIL Are you looking for an overarching IT framework that is compatible with other IT standards and approaches?  Do you need help in building the business case to justify investments in IT service management and IT governance?   Are you looking for a way to have the governance of IT considered as part of overall governance of the enterprise?  Then let me introduce you to COBIT®! Since its introduction in 2012, COBIT 5 reflects the evolution of COBIT from an audit and control approach to an overarching governance and service management framework.  Let’s take a closer look at COBIT and the benefits that COBIT can provide for an organization.

What Is COBIT?

COBIT, formerly known as Control Objectives for Information and Related Technology, is a framework created by ISACA® (formerly known as the Information Systems Audit and Control Association) for IT management and IT governance. First released in 1996, COBIT focused initially only on auditing. The current version of COBIT, COBIT 5, integrates previous ISACA guidance, including Val IT™, Risk IT™, and COBIT 4. COBIT 5 also aligns with other IT standards and frameworks, such as ITIL®, ISO/IEC 38500, and others. As a result, COBIT 5 provides a truly comprehensive framework for helping organizations achieve their objectives for the governance and management of IT.

Why COBIT?

COBIT can be used within any size and type of organization, as it’s written in non-technical language and looks at integrating the governance of an organization from end-to-end, not just the governance of IT. Immediately one can see the positive outcomes of this approach. COBIT promotes the fact that IT is pervasive and integral in all business activities in nearly all organizations. As such, IT should be governed as part of an overall enterprise governance approach, and not separately and distinctly from the rest of the enterprise. IT can no longer be thought of as a “function” or department within an organization. IT is enterprise-wide. No longer can organizations think of projects as “business projects” or “IT projects, but rather projects, whether initiated within or external to the IT organization, must be thought of as IT-enabled business initiatives. The use and implementation of IT is not cheap, and now more than ever the investments that businesses make in its use of IT must result in furthering competitive advantage and utilizing IT as a strategic asset. COBIT provides needed guidance to ensure that IT is governed as a part of the overall governance of the enterprise.  Nevertheless, I recognize that within some organizations, governing an enterprise from end-to-end, and including IT as part of that enterprise governance may not quite be in reach just yet. If this describes your organization, COBIT can still be utilized within your organization, particularly in regards to IT service management (ITSM). If you’re already doing some kind of ITSM – regardless of the maturity of your implementation – COBIT will enhance and help identify justifiable improvements to your ITSM implementation. If you’re just getting started on your ITSM journey, COBIT provides great advice regarding the questions you should ask for identifying and justifying needed governance and management processes.  The answers to these questions then help in obtaining buy-in for getting IT governance or ITSM started in your organization.

COBIT Benefits

Looking at COBIT from the IT perspective, there are a number of benefits that may be derived from incorporating COBIT. COBIT is “framework-friendly”

As I mentioned earlier, not only does COBIT 5 integrate previous COBIT guidance, such as Val IT, Risk IT, and COBIT 4, it also provides an overarching governance for, and implementation of, other relevant frameworks and standards. So if your organization has based its ITSM implementation and IT governance on ITIL, ISO/IEC 38500, ISO/IEC 27001, ISO/IEC 9000, TOGAF®, PMBOK®, or others, COBIT can enhance what you’ve done. Through the use of the goals cascade and process capability model, COBIT can also help identify justifiable changes to what you’re doing to further improve your use of these other standards and frameworks.

COBIT helps translate business needs into IT enablers

COBIT 5 introduces the goals cascade, a mechanism that can be used to correlate business goals into IT goals and deliverables. The goals cascade starts at the stakeholder level through identifying business drivers. These business drivers then form the basis for specific enterprise goals. The enterprise goals in turn cascade to IT-related goals, which are then mapped to the specific COBIT processes that can be used to realize these IT-related goals. Within the detailed mapping, there is guidance for whether an identified process is a primary or secondary enabler of that IT goal.

COBIT provides a “ready-made” toolset

To assist with implementation, COBIT provides a robust set of tools. First of all, COBIT provides a documented question set, which can be used to clarify the needs and requirements of the stakeholders of an enterprise. For each of its 37 processes, COBIT documents a suggested RACI (Responsible, Accountable, Consulted, and Informed) matrix to help articulate the roles involved, as well as generic guidance on how to build, execute, monitor, and improve processes. COBIT also provides a process capability assessment model, based on ISO/IEC15504, to identify strengths, weaknesses, and risk. This assessment model introduces objective criteria that can be used to identify opportunities for improvement.

COBIT helps illustrate the business value of IT

Arguably, one of the more powerful features of COBIT 5 is the use of a balanced scorecard to illustrate the business value of IT. The balanced scorecard (BSC), developed by Kaplan and Norton of the Harvard Business School in 1996, is used in many organizations to help measure enterprise execution in four defined areas – Financial, Customer, Internal, and Learning and Growth. COBIT extends the use of the BSC by applying the same four areas from the perspective of IT. By doing so, the IT BSC provides insight into the value contribution of IT in business terms.

Your Mileage May Vary

These are only a few of the benefits that may be achieved through the adoption of COBIT. Like any IT framework, the use of COBIT must be approached from an “adopt and adapt” perspective. As the needs and requirements of any enterprise are unique to that enterprise, implementation of COBIT must be considered in the context of the organization, and adapted for use within that organization.

Find Out More about COBIT

If you’d like to learn more, the primary COBIT 5 reference, “A Business Framework for the Governance and Management of Enterprise IT” is freely available for download from the ISACA website (www.isaca.org).  Enjoy! And let me know if you have any questions. Acknowledgements ISACA, COBIT, Val IT, and Risk IT are trademarks of ISACA. ITIL is a registered trademark of AXELOS Limited. TOGAF is a registered trademark of The Open Group. PMBOK is a registered trademark of Project Management Institute, Inc. Image credit

Like this article? You may also like: What Is ITIL?

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

My SysAid Beta Adventure

Posted by on May 12, 2015 in SysAid
ITSM solution based on customer feedback A warm hello to all readers. I'm Danny, and some of you may already know me as the Technical Community Manager over in the SysAid Community. Over the past couple of weeks I’ve been managing the beta phase of the SysAid 15.2 Help Desk Software On-Premise release with our instrumental set of Pathfinders. Our focus, as with any Beta, was to collect as much customer feedback as possible regarding improvements and feature requests, and to make SysAid harder, better, faster, stronger! As part of 15.2, we made a wide range of improvements and tweaks, whilst implementing many sought-after features, such as third-party integrations [FR #15910], the ability to decide your own ticket prefix [FR #14042], being able to update agent settings directly from the Asset List without uninstalling and reinstalling the agent [FR #16189], and many many more – in total over 100 new enhancements (fresh features and multiple improvements).

Smooth Sailing Beta

The importance of the Beta is to ensure that everything is thoroughly tested – not only internally here at SysAid, but also by the awesome customers who volunteered to participate in our beta-testing Pathfinder Program. Despite the cautionary tales of my co-workers suggesting to bring a sleeping bag to the office, I was surprised by how calm the whole process has been. The first "pre-beta" phase, testing On-Premise 15.2.00 on MySQL, went smoothly and some customers not only installed it on MS SQL as well (despite our warnings!), but also adopted it in their production environment (I'm looking at you, Karlson!), and yet - only four issues were discovered, and of course resolved. Then came the MS SQL beta release of On-Premise 15.2.01, aimed at Pathfinders using SysAid with an MS SQL database. This triggered a significant influx of participating customers, and additional issues were identified and fixed. At the moment we have roughly 20 of our Pathfinders (both from the Community and outside of it) participating in this beta, and the feedback has been exceptional. This version is so stable you could park horses in it, so fast you have to watch out for the cops, so smooth... you get my point. Two days ago (May 19), we released version 15.2.02, which added more tweaks. Additionally, thanks to the R&D team who were ready early with a new feature (originally it was going to be included only in the next on-premise release), we also added the capability for admins to edit Network Discovery rules for WMI and SNMP scans, agent deployments, asset data updates, and agent version upgrades [#17009]. We’re happy to call this version a true... *drumroll* Release Candidate! *cue cinematic orchestral music*.

Challenge Us

But it’s not over yet! I’m excited to invite you to participate in these final stages of the beta testing and challenge our 15.2.02 Release Candidate to the test as to whether it truly deserves its title. If you haven't already, please join our Pathfinders Program and tell us more about how stable it is – or how much of a badass you are for managing to break it (*knocks on wood*). And may the force be with us. The final version of SysAid 15.2 is planned to be released early next month (June), when it’ll be made available for all customers to enjoy. Until then, you’re welcome to reach me at at my virtual home – the SysAid Community. Cheers and until next post!

Like this article? You may also like: 2014 in (Content) Review

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

What Is ITIL?

Posted by on May 5, 2015 in ITIL
If I type “What is IT” into my favourite search engine then the suggestion “What is ITIL” appears near the top of the list of suggestions, so I guess lots of people must be asking this question. What is ITIL?
Unfortunately this is one of those questions that is very easy to ask, but quite difficult to answer. I followed the links that I found when I searched for “What is ITIL”, but the explanations I found were often written in language that would be quite hard to follow if I didn’t already know what ITIL® is. Here are some examples:

The Short Answer

I guess if you’re reading this article then you’d also like to know what ITIL is, and that explanations like these have left you still searching, so here is my attempt to answer the question. I’ll start with a one sentence explanation, just so you can compare my attempt with the ones I found on my internet search.

ITIL is a way of ensuring that investments in IT create real value by providing a consistent, structured framework for planning, building, and running IT services.

A Longer Answer

If my short answer leaves you no wiser, then let me give you some context as a basis for a more long-winded explanation that I hope will be a bit easier to understand. We are becoming increasingly dependent on IT, both in our personal lives and in the organisations where we work. We invest significant amounts of time and money on purchasing and using IT equipment, so we need to make sure that our investment delivers the value that we need, rather than just soaking up all the resources we make available before letting us down when we most need it. Obviously, we all want IT to deliver the value we need. ITIL is simply a way to help ensure that we do all the things we need to do to make sure that happens.

Services and Service Management

Organisations don’t get any value just from their hardware, or their network, or the applications they use; it takes all of these things and many more to create value. ITIL considers IT as a provider of services that creates value. There are lots of different definitions of what a service is, and I’m not going to quote the ITIL definition here as that would require a lot of explanation. The simplest way to think about it is that a service is something that somebody else does for you, to help you achieve something that you want. Examples of IT services are:
  • Gmail, Hotmail, or the email service you receive from your Internet service provider
  • Provision of a PC and all the required software, hardware, and support you need so that you can use it for your work
  • A customer relationship management (CRM) system used by a large organization to manage all their interactions with their customers
An organization that wishes to provide these IT services efficiently and effectively has to do lots of things, including:
  • Understanding what their customers need, and ensuring that they invest in the right services to meet that need.
  • Making sure that each service they design can deliver not only the functionality customers want, but also sufficient availability, the right capacity, and all the necessary security features.
  • Planning how to implement new and changed services so that they are properly tested, and they actually deliver what is expected.
  • Operating the services and dealing with things that go wrong.
  • Continually monitoring everything they do and planning improvements.
These sort of activities are called service management, and since we are dealing with IT services, they are IT service management, commonly abbreviated to ITSM.

So What Is ITIL?

Now that I’ve given you a bit of context I can try again to explain what ITIL is. ITIL is the world’s best known framework for ITSM. It includes:
  • Publications describing ITSM best practice that you can adapt to suit your own environment
  • Training and exams to help people develop understanding and skills
  • An endorsement scheme for ITSM tools to help ensure they can deliver the functionality required
  • A global community of consultants, practitioners, and trainers who share ideas and promote best practice
To find out more about ITIL you can:  

Like this article? You may also like: ITSM Basics: A Simple Introduction to Incident Management

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

Change Evaluation: The Seven R’s Revisited

Posted by on April 29, 2015 in ITIL
Seven R’s trigger ITIL’s change evaluation process The 2011 version of ITIL introduced the lesser known change evaluation process. It’s a great addition, and I haven’t seen a lot written about it. The first thing to know is not every change requires a formal change evaluation. It’s intended to be used primarily for major changes, where the complexity and scope of the change warrants careful and formalized evaluation. Change evaluation comes with its own Seven R's - a handy same-letter list that’s easy to remember, and can help make sure we’ve explored the most common sources of issues with proposed changes.
Here’s the seven R’s:
  • Who raised the request for change (RFC)?
  • What’s the reason for the RFC?
  • What return is the change expected to deliver?
  • What risks does the change pose?
  • What resources are necessary?
  • Who is responsible for the key tasks?
  • What's the relationship between this and other requested changes?
The list is not intended to be a set of required fields on the RFC form; modern IT systems are far too complex. It’s intended to be used in the evaluation process to trigger deeper thinking about a proposed change and uncover potentially hidden sources of risk and unintended consequences.

A Great Start

The R’s are a great start, but we really need to do a little more serious detective work. Remember, change evaluation is reserved for major changes, where there’s often a great deal of complexity and high visibility. Let’s put on our detective hats, and take a closer look.

Raised

Who raised the RFC is a good place to start. It goes well beyond who's filling out the form or taking administrative responsibility for the RFC. Change evaluation needs to know the role and business function of the requestor. If it's IT, what functional unit? Why was it raised by this particular person or group? If customer, does the requestor represent all user groups of the service? Has the requestor worked with relationship management and/or the service owner? Was it raised by a person who was directly impacted by a recent incident? Understanding more about the role and context of the requestor helps change evaluation understand the bigger picture. Again, these are supposed to get you thinking deeper about the proposed change.

Reason for the Change

An analogous question would be "What are you hoping to accomplish with this change?" This one can be tricky because you need to get to the question behind the question. Sometimes RFCs come on the heels of a significant incident. Some changes are proactive changes to avoid a potential incident or problem (such as keeping technology current). Other changes are raised to address very specific business needs. Some reasons are urgent and pressing and others are related to longer term releases or system upgrades. The question of what you hope to accomplish helps identify what specific outcomes are anticipated, so change evaluation can help determine if the RFC is likely to deliver them. This question should be answered in plain, unambiguous language that makes very clear the purpose of the proposed change. In my experience, this question can unearth significant issues. In the evaluation process, it may be discovered that there are differences in understanding the reason behind a change. If the request isn't clear, it's harder for the change to be successful in meeting the desired outcome(s).

Return

This one tends to get forgotten because it's hard to answer. ”Return” here is talking about business value. It too should be answered in plain language. An example would be: "RFC will deliver new order processing functionality that will reduce order processing time by 20%". The "return" should be specific and measurable, and from the perspective of the business. If it's an infrastructure RFC, what risk or impact is it seeking to mitigate, and what's the value of the avoided risk?

Risks

Identifying risks associated with change requests is critical for an effective change program. The risks here are not limited to technical and infrastructure risks – things like adding firewall rules may block application-required traffic. When identifying risks, keep a business-impact focus in mind:
  • What could happen that would have adverse impact on the business?
  • Could the change impact other services running on the same infrastructure? Could there be unanticipated impact to business processes? Will the change increase the support load? Are there multiple changes happening at the same time, and are they compatible?
  • Do the results from the test environment accurately predict what will happen in production?
  • Will the changed service be able to meet its service level targets?
There are a number of formal risk management methodologies, such as ISO 31000 and Risk IT. If your company uses a formal methodology, that would be a good place to start. Otherwise, a simple and common approach is to create a risk matrix, where risks are identified and each rated on the probability of its occurrence, and impact, if it does. Risk Matrix for ITSM With this simple matrix, it’s pretty easy to see that you should focus most of your attention on the critical and high risks, some on the minimum, and little on the low risks. One thing to keep in mind is that all changes have some level of risk. It’s not helpful to either under or over state risks. Both can have disastrous impact.

Resources

This is where you identify all resources required for a successful change implementation. This includes everyone needed to build, test, implement, communicate, support, or roll back the change.
  • Will the required resources be available during the development and implementation phases?
  • Are other changes scheduled that require the same resources?
  • Are the needed infrastructure and technical resources available (e.g. server and network capacity)?
  • Is there sufficient infrastructure capacity to support the changed service? (How will you know?)
  • Do all the players have what they need to be successful? (Will they be available immediately after the change is implemented?)

Responsible

Similar to resources, the “responsible” question seeks to ensure there are clearly established and understood roles and responsibilities. A RACI chart may be helpful (see What’s a RACI chart and how do I use it?). This is a critical step that helps eliminate assumptions and avoid misunderstandings.

Relationship

This is where we seek to understand how the change in question may impact or be impacted by other recent or planned changes. How do the service components fit together?
  • Are there hidden dependencies to the components being changed? (What efforts have been made to identify?)
  • Are there unknown users of a service that’s being changed or decommissioned? (How do we know?)
  • Are there version dependencies between components, and have they been tested?
  • Does the test environment accurately represent the production environment?
  • Are critical parts of the infrastructure needed to implement the change that may be unavailable because of other changes?
Beyond the scope of this article, good configuration management and change modeling can be really helpful in understanding complex relationships.

Finding the Right Balance

Out in the real world, we all know some changes are more risky than others. It’s up to you to determine how deeply you need to go in evaluating a proposed change. If a change is large or complex or significant risk may be present, change evaluation is warranted. Changes that involve critical business functions or significant business process changes are excellent candidates for formal evaluation. It’s been my experience that just when you think a change is benign, you get hit with something you didn’t think about, but maybe should have. So, let me suggest a few additions of my own – reality, respect, results, and repeat:

Reality

This is where we take a quick reality-check. Yes, 12 Ninjas might drop from the ceiling and cause a large impact. But, in reality, how likely is it to happen? Have changes similar to the one under review been successfully implemented? Reality can be an important data point to help strike the right balance. Data is a great reality check. Historic change information can be really helpful to help determine where additional evaluation is warranted and where it would be unnecessary. In reality, some change types, and components are just less problematic. Likewise, some that should be harmless no-brainers can cause big problems. Use reality as a guide.

Respect

The Change Advisory Board (CAB) is comprised of your best subject matter experts - those who have deep knowledge and are respected for their expertise and track record. Respect their experience and knowledge. When it comes down to it, change evaluation depends on people who are good at what they do.

Results

  • Do the test plans adequately ensure the change will operate as intended?
  • Has business functionality been tested? (Have the ‘intended result’ been validated?)
  • Do the test results meet identified criteria for success?
  • Were business users involved with testing? (Were any significant issues raised?)
  • Has the business reviewed the test results?

Repeat

  • Has the change being evaluated been done before? (Was it successful?)
  • Is it a change that’s been attempted and failed? (Have the reasons for the failure been identified and addressed?)
  • Have previous changes to the service components been successful?
  • If it involves vendor-supplied updates, what’s the track record of prior updates?

Making It Happen

Remember to use the R’s as a reminder to explore all aspects of a change. Effective change evaluation is core to successful service delivery and business value. Use the seven R’s of change evaluation to make sure you’re covering all the bases. Also, take a look at the extra ones I’ve suggested. How about you? What additions would you make? Do you have any that you’ve found helpful?

Like this article? You may also like: Defining Metrics for Change Management

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

Software Asset Management: How to State the Case for Obtaining a SAM Solution

Posted by on April 22, 2015 in Asset Management
Software Asset Management (SAM) is also part of IT So you’re the “go to” guy or gal within IT, and IT service management (ITSM) has been your life for the last five years.  You can soak up ITIL and ISO 20000, and your team is well versed in the nuances of ITSM and how that has been moulded within IT to deliver great service to the rest of the business.  And then someone says to you “What about Software Asset Management (SAM)”?
Your IT budget has been apportioned to various projects and training requirements for the next 12 months, and your ITSM solution doesn’t come with a reconciliation engine to enable comparisons of inventory data to proof of entitlement (contracts, licenses etc.), which in turn could produce a license compliance report. Plus the CIO has said there is no money in the budget “for another tool, on a topic I have little comprehension of.” (Sorry – I’m sure some CIOs understand SAM!) So what’s a hard-pressed IT manager to do to try and enforce some degree of SAM discipline within a company without a bona fide SAM solution to measure his/her efforts?  Below are a few ideas that could make the job of managing an IT estate a little bit easier, as well as acting as a way to state the case for obtaining a SAM solution in next year’s IT budget.

Control Spending on Software

The organizations where SAM is weakest will most likely have the most liberal financial control also.  If software purchases are not funnelled through an IT portal for a company to maximise the benefits to be derived from economies of scale, then there is also a good chance that any evidence of purchase/proof of entitlement is not finding its way back to a SAM function to justify the install.  Commercial culture has to be bent, not broken – so perhaps a step forward is to say to those liberal budgets holders:  “Buy whatever IT you like, but buy it through authorized channels.”

Control Deployment of Software

Not unlike the previous restraint mentioned, deployment of software should not be a knee-jerk reaction to a red-faced project manager looking to massage his ego by demanding deployments “yesterday”.  Granted, certain installations can be justified off the back of existing contracts, but make sure financial evidence can be levied against individual installs for true compliance.  However, due-diligence should take place between the requestor, procurement, and deployment to ensure that what was requested was what was bought, and that what was bought was what was installed.

Educate Your Workforce

Communications best practice highlights that the right message goes to the right people at the right time in the right format.  Clearly, the SAM/IT asset management (ITAM) message that goes to a developer is completely different to the SAM/ITAM message that would go to an end user or a contractor.  Ensure that the policies and ambitions for managing SAM are consistent across the board.

“Be Mean” with Your Supported Software Catalogue

If you rationalize the number of software titles that are used to run your company, then the amount of SAM overhead in chasing down entitlement and contract management is also reduced.  Interestingly, this can have a knock-on effect to the service desk, as fewer titles also leads to a reduction of support tickets on the dizzying array of titles that could be installed on a given IT estate.  Interestingly, a mean supported software catalogue can also be used to further limit purchases, as only approved software will receive authorisation to proceed with a request for purchase.

Start Learning About Licensing Types

One license = one install is so 90s! Terms and conditions offered through support and maintenance and/or volume contract agreements can extend the capability/footprint of software considerably (and in a legitimate fashion too).  Also, try and stay vendor-neutral in respect of learning licensing types, as you will start to find that terminology plays a large part in how one vendor to the next defines a device, or a user, or an installation.  This extends to the roles devices play too – one vendor might view a back-up server as requiring a full production license, regardless of whether the software is being used or not.  This gets evens trickier in the database space as the hot/cold standby nature of the reserve install can be factored into a license calculation.

Get to Understand How IMAC Can Influence SAM

It may be that you believe once a SAM solution is installed, you will be able to produce real-time dynamic license compliance reports at the touch of a button.  The question to ask yourself here is: Do you really want to? Is it reasonable to be taking license compliance reports to senior management on a daily/weekly basis asking them to make management decisions on either uninstalling or purchasing software to rectify a compliance position?  The churn and frequency of change within your IT estate should offer a fairer indication as to how frequently such reports should be placed in front of senior management for a call to action.

Understand the Role of Software when Conducting Value-Chain Analysis

If it is your intention to take SAM into the boardroom, then understand the role and value the software has in revenue production.  Calculation of this is a subjective matter, merely comparing the cost of the software against the revenue the software supports could be viewed as naïve. Whatever calculation you do settle upon, make sure you can justify that calculation in support of any figures that might be placed before the board.

Identify Allies to the SAM Cause

Once you start to dig deeper to understand where data is coming from to derive a license compliance position, you will come to realize that a significant portion of it comes from outside of IT.  A SAM manager has to ensure the goodwill of key stakeholders in getting that data in a timely and accurate fashion, and also in a format that will ultimately be acceptable to the SAM solution.  Establishing those links prior to the arrival of a SAM solution will put you in a great position.

Try to Spot Points of Crossover with Other IT Disciplines

Don’t reinvent the wheel when it comes to creating SAM processes; several of the processes required of ITSM, as outlined in ITIL, can be modified to address SAM concerns. I hope the above gives you a flavour of issues/steps to address prior to acquiring a SAM solution.  Regardless of the size of your organization, SAM should extend as far into your organization as the IT does, and does not “go away” merely because a SAM solution has been purchased.  If anything, SAM serves to prove the old maxim of “Garbage In – Garbage Out”.  If you can adopt an ounce of quality assurance/plan-do-check-act (PDCA) in your approach/preparation to SAM, then when the SAM solution arrives you will be better placed to gain quality results that serve, and can be trusted by, the business. Image Credit

Like this article? You may also like: 9 Ways ITAM Can Empower IT

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

Meeting Business Needs: Doing the Right Things and Doing Things Right

Posted by on April 14, 2015 in ITIL
ITSM-business alignment Good business-IT alignment (please note that I use this well-known and oft-used phrase reluctantly as IT is part of the business) relies on two things: doing the right thing and doing things right. Without both of these, what IT does will never live up to what business colleagues and stakeholders need and expect; where:
  • Doing the right things” means executing IT initiatives that support business strategy.
  • Doing things right” means executing these initiatives in a way that delivers the proposed value within the required timescale and cost constraints.

How Does IT Normally Fare?

In my opinion, IT can sometimes do the wrong things badly. But it’s less common for IT to do the right things well, at least in the eyes of business colleagues. The two key factors here are business-IT alignment and operational excellence. When there is a disconnect between the business and IT there can be a reduction in the business value generated, even if IT is run very efficiently. And if IT has issues with its operational efficiency, it may struggle to deliver value to the business, even if it does know what the business needs. This can be represented in a simple matrix that shows IT maturity in the context of business alignment and IT operations. IT maturity matrix

So What Can IT Organizations Do?

Organizations want and need to move up and to the right (into quadrant C), with this desire driven by different instincts on either side of the divide. The IT department wants to focus on new infrastructure and improved operational efficiency, because that’s what they care about. They want to move across the matrix from left to right. The business wants IT to “stop messing around with the shiny technology” and to give them what they really want (or at least what they think they want). They want IT to move up the matrix. They want more business value from IT. Unfortunately, many IT organizations (being more focused on the “how” rather than the “what”) will take a path from A through D to C. However, the preferred path would be to do the rights things slowly and then ramp up efficiency over time (going from A to B to C) as this will have a more immediate impact on the business value delivered, not to mention reducing the money spent on things that are potentially irrelevant to generating business value.

Which quadrant is your organization in?

Quadrant A

IT organizations in quadrant A suffer from a combination of poor processes and poor strategic alignment with the business. From here, IT has a lot of ground to cover. Simultaneously improving business value and internal operational efficiency is tough, so IT will need a solid improvement roadmap outlining the key priorities. The catch-22 is that the business may have little faith in IT, making it difficult to get the budget and manpower needed to get out of the “firefighting mode” and take steps to increased maturity.

Quadrant B

Organizations in quadrant B have good alignment between IT and the business, but suffer from poor execution. They understand what the business needs, but immature capabilities and processes are preventing them from delivering value quickly, efficiently, and with minimal risk to current business operations. This means the output can be frequently late, over budget, and below the level of quality the business needs. For organizations in quadrant B, implementation of best practices (such as ITIL®, the IT service management best practice framework, formerly known as the Information Technology Infrastructure Library) will help to give them the efficiency boost they need to execute delivery more quickly.

Quadrant C

Quadrant C is where IT organizations need to be, combining a good understanding of what the business needs with a solid supporting IT strategy and good execution capabilities. However, this is not an end point; there will always be room for improvement. IT organizations in this quadrant will have a clear track record of delivering business value fast, so the perception of IT will be considerably more favourable. This will make it easier to work with business stakeholders and get additional budget for improvement.

Quadrant D

With established processes and capabilities, IT departments in quadrant D are moving fast — but in the wrong direction. It’s a common situation for IT departments that put too much focus on implementing a best practice framework like ITIL. Efficiency goes up and the internal IT metrics look good but IT has effectively disengaged from the business at a strategic level. To get back on track, the IT department needs to re-engage with business stakeholders, implement business value metrics to measure performance, and institute IT customer satisfaction surveys to keep a gauge on the business’s perception of IT.

Mature IT organizations that measure business value and operational performance will be able to use their metrics to quickly place themselves in the matrix. However, the majority of organizations that actually have suitable measurements are more likely to already sit near the top-right. Organizations with lower IT maturity should be able to establish their position by consulting the business directly. Do business stakeholders feel that they have the right services and technology to do their jobs efficiently and effectively? Are IT projects delivered quickly enough? Do IT expenditures balance well against business value delivered? Do changes to the IT infrastructure frequently have an adverse impact on business operations? Is IT responsive when something goes wrong? The matrix is a tool for IT to plot its maturity level from an alignment perspective, frame conversations with internal and external stakeholders, and hopefully crystallize a commitment to moving in the right direction. With it, IT can identify whether it needs to improve internal operational efficiency, develop a better understanding of business strategy, or both. The path to business-IT alignment begins with a shift in the mentality of IT — from devices, infrastructure, and processes to customers, services, and value.

Like this article? You may also like: 4 Things You Need to Know About IT Maturity Assessments

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

Improving Categorizing Incidents

Posted by on April 7, 2015 in Service Desk
Categorizing incidents in your service desk Recently a customer asked me how many different categories they should have for managing incidents. They seemed to think that, like a magician, I could pull an “ideal” number of incident categories out of a hat, and that they could somehow compare themselves to this to see if they had the right number. I gave them the typical consultant’s answer of “it depends”, because there really isn’t any right answer to this question. If you only have 3 or 4 categories then you are almost certainly doing something wrong, but if you have more than 1,000 categories then you probably have it wrong in the other direction. Between these extremes it really does depend on the scope of your service desk and what you’re using the categories for.

What Are Incident Categories Used For?

There are lots of different things you might use incident categories for. Typically organizations use incident categories to help them:
  • Determine what information the service desk should ask for when logging an incident; for example if the user cannot log in to their laptop then you may want to find out what username they are using and what domain they are logging in to.
  • Identify the correct SLA for the incident, which will tell the service desk how quickly the incident needs to be resolved.
  • Identify scripts or tools that should be used for initial diagnosis of the incident.
  • Decide which group or team will carry out initial diagnosis of the incident; for example there may be a dedicated team providing support for a critical line-of-business application.
  • Identify when multiple incoming incidents are all related to a single problem, so they can be managed together to avoid duplication of effort.
  • Decide when an incident should be escalated and which group or team it should be escalated to if the service desk cannot resolve it within the required time frame.
  • Analyse trends to identify problems and improvement opportunities.
  • Create reports that record the reliability and availability of individual IT services.
This is not a definitive list; you may have other reasons for categorising incidents. The important thing is to think about why you are categorising incidents, so that you can make sure the categories you define are appropriate for how you intend to use them.

How Many Category Fields Should You Have In Your Service Desk Tool?

It is very common to use categories and sub-categories to allow a larger number of overall categories to be easily managed. Many organizations use a three level hierarchy of categories. This has the advantage of limiting the number of choices presented to the service desk agent at any one time, while still allowing a larger number of overall categories. For example if the first level has 10 categories, and on average each of these has 8 sub-categories and these in turn have an average of 8 sub-categories then you have a total of 640 categories, but the dialog boxes from which categories are chosen only have 8 to 10 entries. Categorization in SysAid If you use this kind of approach then you need to be very careful that the hierarchy makes sense to the people entering the information. I have seen a situation where a service desk agent knew exactly what option they wanted to select in the final dialog box, but had to keep guessing to find the right higher level choices to get them to it. As well as setting initial categories, you also need suitable closure categories for your incidents. Closure categories cannot be set when a call is logged, as they depend on the outcome of the incident. Closure codes are vital, however, in helping with your incident analysis, and they often have options based on the outcome of diagnosis, such as “user training issue”, “faulty hardware”, and “known error”.

Defining Categories

The best way to set about defining incident categories is to get all the people who need to be involved into a workshop. Start by agreeing on the purpose of your categories; you can use my list above as a starting point for your discussions. Based on what you intend to use the categories for, you can decide on how many different categories you need. At this stage you will answer questions like “How many different levels of categories do we need?” and “Is the impacted IT service the top level category or should it simply be a separately recorded item of information?” In my experience, it’s better to have too few categories than too many. Very large numbers of categories cause problems for service desk agents who have to look through many different entries to find the correct one, and later on have little value in analysis, as each category has very few incidents.  This makes it harder to identify trends that you need to think about, or issues you need to address. So start with as few categories as you can, and add more as you find the need for more information.

Summary

In summary, you need to think about incident categories in terms of what you use them for, rather than just allowing people to define more and more categories that may be of very limited value to you or your customers. If you haven’t reviewed your incident categories recently then why not spend a bit of time looking to see if they are still fit for purpose. Improvements you make in this area can make life much easier for your service desk agents, and ultimately for your customers. Image credit

Like this article? You may also like: Defining Metrics for the Service Desk

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading
Subscribe
Watch & learn from industry experts about ITSM and help desk hot topics!