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.

The Cloud Behind the Curtain – Why ITSM Matters

Posted by on September 3, 2014 in Cloud
Why ITSM Matters I’ve enjoyed working in the technology field for well over a decade. Either working on the service desk, in the process arena with incident management, or as a developer building creative solutions, I’ve always felt that the overall goal of IT was to make everything for customers as easy and seamless as possible. Mobile devices, virtual desktops, IP phones – all things that are designed to allow a person to connect with their workplace and perform their job from almost anywhere with any device they find preferable. For the better part of my IT career, these things have always been supported by the system administrators, developers and engineers living behind a mysterious technology curtain, existing for the purpose of getting people to ignore the technology and focus on how to best use a solution.

The Wizards of IT

This curtain is where IT service management (ITSM) exists. ITSM never focuses on servers or databases, but has the goal of looking at how services are delivered to the customer. Not ignoring hardware, ITIL® (formerly the Information Technology Infrastructure Library) outlines the best practice for how to design, operate, change and improve IT as efficiently as possible, while providing high quality and value of services.

Building a Curtain Within the Curtain

Something ironic has been taking place during the last few years. The same hardware and technology we’ve been keeping behind the curtain has itself started to disappear from IT, essentially going behind another curtain that IT organizations don’t touch. A process of ordering and placing a new physical server, which at best would still take several days, has now been replaced with an online ordering system that can deliver a new virtual server in a matter of minutes. Enterprise applications that used to look like spider webs in a CMDB mapping can now be represented as a SaaS solution with only one symbol (maybe two if you use SSO or LDAP integration). Some of the newer and smaller startups are able to run with no traditional datacenter. Even older corporations, long considered to have more bureaucracy with a longer technology refresh cycle, are finding that they can reduce dependency on physical technology by moving parts, or all, of common applications into the cloud. While those operation centers may take longer to disappear, I’m willing to bet there isn’t a single organization out there that doesn’t have some application or service in the cloud. The traditional sense of IT is disappearing, and if the technology disappears, where does that leave the thousands of IT departments out in the world? With no physical servers to maintain, there obviously isn’t a need for the same manpower to run a virtual environment. Considering several applications can be delivered by SaaS, there’s even a reduction of virtual infrastructure.

Different Technology, Same Service

While IT is changing due to cloud computing and SaaS solutions, the only thing that remains constant is that customers depend on those services to complete their jobs and help build successful businesses. As I pointed out earlier in this post, ITSM doesn’t focus solely on hardware – its focus is on delivering valuable services to customers, no matter how the delivery takes place. It doesn’t matter how technology changes, or how an IT department functions, such as using DevOps, as long as we can provide customers with a seamless experience that provides the value they expect.

Coping with Evolution During a Revolution

Cloud technology has given every business the capability to own technology without the traditional IT department, but this revolution has a ceiling dictated by the evolutionary pace at which an entire culture can change to match technology. Nonetheless, it’s certain that changes will come in time. Ignoring the opportunity to adapt runs the risk of being outsourced by the very services driving the revolution. The best way to keep IT relevant is to move from being a technology provider, and to take on the role of being a strategic service provider for the business.

So What Changes in the Future Will We See?

In our upcoming webinar with Glenn O’Donnell, Vice President and Research Director at Forrester Research, we will discuss what the future holds for ITSM. From the so-called “death of ITIL” to Shadow IT, from cloud technologies to DevOps – Glenn will provide his insight into how the role of ITSM will develop and change in the coming weeks, months and years. Looking for a glimpse into the future and wanting to know how best to prepare? Then don’t miss this great opportunity to learn; join Glenn and I on September 16th at 12pm EDT to see what the future holds for IT service management. Register now. After the webinar, all attendees will also receive a short report with the 20 Top Tips for Addressing the Future of ITSM.

Like this article? You may also like: 6 Steps to Successfully Migrate Your Organization to Cloud.

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

Clearing Up the Myths of CMDB

Posted by on August 27, 2014 in Asset Management
Clearing Up the Myths of CMDB "You can't achieve value from your investment in IT service management (ITSM) – ITIL processes, training and tools - if you haven't got a fully functional integrated, single-source of truth Configuration Management Database (CMDB)." This has long been trumpeted out at meetings and events, generally (although not always) by people who have no idea what this is or how to achieve it. If there's one element that has been used (deliberately or otherwise) to slow down and scupper ITSM projects then it's been this – the impenetrable world of CMDB, or Configuration Management System (CMS), which is part of Service Asset and Configuration Management (SACM).
CMDB can be a convenient way of grinding a project to a halt, often by technicians trying to achieve the unachievable with unnecessarily high expectations regarding quality and levels of detail (which cannot be easily defined and maintained). What better way is there to ensure that nothing will change by spending time on an impossible task that no one understands?! Often it is not clear to organizations what the point of Configuration Management (CM) is, and this therefore can lead to failed expectations on all sides. Certainly it is a topic that most agree is important and useful (somehow), but few actually have a clear vision of what CMDB looks like, what is needed to make it work and how to get there. Owing to this, several ‘myths’ of CMDB have evolved over the years, including:
  • As a CMDB is seen as a central pillar of IT service management (ITSM), it will somehow magically fix all other issues related to ITSM.
  • A CMDB must include all IT assets/components linked together in one single database.
  • CMDB has to be a ‘big’ project.
  • A CMDB needs to be built by technical people.
Here's some simple points of advice to clear up these myths and fantasies (plus others):
  1. Configuration Management is a way of mapping and storing information on the IT landscape – to support risk assessment, change management, fault/incident diagnosis, service design and service level management, financial and asset management, capacity, etc. In essence, it is an integral underpinning element for most ITSM processes. However this doesn't mean that CM will fix all other ITSM issues – if it's not applied at the right level then it can actually do the opposite.
  2. Defining, building, and mandating a CMDB requires thought and ongoing effort. However, it’s debatable whether this is actually a process in itself, or simply an element of it (i.e. the CM element) that is required in all other processes. This is a key point and often the cause of misunderstanding and failure, as organisations embark on CM projects without any clarity about what it is trying to achieve and deliver.
  3. The classic definition of CM is “to provide a logical model of the infrastructure." The objective of CM, as stated in Service Transition, is “to define and control the components of services and infrastructure and maintain accurate configuration information on the historical, planned and current state of the services and infrastructure.” However, every organisation that embarks on CM should be transparently clear on what is expected from CM, in what form, and to what level of detail – otherwise there will be very little chance of success.
  4. The single database idea that sees all Configuration Items (CIs) and service components in one single repository – hardware, software, applications – does NOT exist. There are few, if any, organisations where this works, i.e. where there is one single, large central database containing all the CI information linked together. IT inventory and application metadata are different entities and we need to recognize this. Also the logistics of a single database are often impossible. So we need to think of the ‘CMS’ as a federation rather than a unitary body.
  5. Your CMDB should be the (master data) hub, and not the single data store (which actually only replicates data from one tool into another). Implementation of the CMDB has been interpreted as meaning “one huge data repository”. There is no need for this, your CMDB should federate and not replicate, a key distinction.
  6. It’s important to be clear on the level of CI that you store and maintain. There’s no need to identify every conceivable CI you can think of, plus you will not be able to capture all the data at once. You probably won’t ever be able to have the database 100% accurate all the time – nobody does. So be clear on what is good enough. Sometimes this is challenging for more technical people and that’s why it’s important to be clear on the business outcomes that are needed from this.
  7. If you need to have a CM owner, then it’s probably best to give this responsibility to someone with more of a business focus than technical, as technical people may have a different internal IT focus on what is needed, which may not fit with business goals. Clearly there is a strong technical element in the delivery of CM, but if technical focus is the driver it can lead to issues, such as waste of time and resources.
  8. CM Is a fundamental ‘under the hood’ activity. Under our streets and cities are cables and pipes and other infrastructure that we need in order to keep our society functioning. There are different authorities and utilities that keep maps of these cables/pipes/infrastructure, so that these systems can be maintained. However there’s no need for most citizens to see these records and the process of mapping and maintaining them is not a separate activity for these companies, rather it’s just an essential part of what they do. CM is similar. We don’t need to make it something separate with its own value set, or try to turn it into a process that it doesn’t need to be.
  9. CMDB isn’t overly complicated - it’s simpler than it seems. We tend to over-engineer it when really all it needs is just to provide some helpful information – nothing more complicated than that.

What Should You Watch Out For?

Avoid the common pitfalls of CMDB by watching out for the following:
  • A lack of shared understanding of the purpose of the CMDB; it’s not a panacea.
  • Making the goal of CM too narrowly defined – don’t make it too technical or operationally focused.
  • Inputting poor quality data – this can invalidate CM as a basis for making good decisions.
  • Letting your CMDB become out of date – it must be kept up-to-date at an appropriate level to maintain its value.
  • Unclear CM goals – this can damage your attempts to gain funding and approval as it can be difficult to justify the expense in isolation. Be sure to clearly define your CM goals.
Ultimately the CM concept can be very difficult to define and clarify to management and people both in and beyond IT. The question often asked is ‘what’s the point?’ This is a good and difficult question. It may be better to be honest and say it’s simply a fundamental requirement for ITSM, rather than trying to separate it out as a distinct activity with its own value proposition. The bottom line is that you just need to have accurate and relevant information on hand to make decisions in change and release management, to support analysis and diagnosis in incident and problem management. No mythology is needed. CM is a tool to support other aspects of service management, which requires clarity, simplicity, and business focus in order to keep it relevant and useful. If it starts to become a ‘mythological monster’ that no one understands and that is eating up loads of resources, then it’s time to stop and review. Image credit

Like this article? You may also like: How Long Should an ITSM Project Take?.

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

IT Service Management at LEADit – It’s as Easy as ABC

Posted by on August 20, 2014 in ITSM
SysAid at the Annual itSMF Australia ITSM Event (LEADit) With an awesome 674 delegates (its biggest turnout yet), we were not left disappointed by our first visit to the Annual itSMF Australia Conference and Exhibition (LEADit). The passion for knowledge, the enthusiasm of IT professionals, the amazing presenter line up of IT service management (ITSM) speakers, the first-class entertainment, and the penguin, made this a truly unrivalled event. A huge thank you to the remarkable team at itSMF Australia, we had a blast. From speaking with delegates at our booth (when Joe The IT Guy let people step away from him and the camera that is) and also managing to catch a couple of presentations ourselves, it seemed to be that the main theme running throughout the conference was “Attitude, Behaviour and Culture” aka The ABC of IT – aka the human aspect of ITSM and service delivery. Essentially we have to remember that IT isn’t about the technology (yes you did just hear a technology provider say that), it’s about the business and it’s about people.
There were plenty more messages to be heard throughout the conference as well (most of which seemed to be underlined by ABC) and overall a great deal to learn from. It’s impossible for us to do justice to all of them, so instead we’ve listed what key takeaways we brought back from the event (with some suggestions for further reading for those who weren’t fortunate enough to attend).

Key Takeaways

  • Agile methodologies in ITSM are gaining ground. This message was even more evident as Axelos announced a new PRINCE2 Agile Best Practice Framework.
  • Continual service improvement (CSI) is vitally important to your organization. Every IT professional should spend at least 5% of their time improving what they do.
  • ITIL is not the only global framework (don't forget that!). It’s important for IT Professionals to have a good understanding of all frameworks and what value they can provide, COBIT5 for example.
  • Service Level Agreements (SLAs) need to support end-to-end business; they should not be overly technology-focused.
  • IT is not merely a technology operation it is an enabler of business (it is the business!). The Service Desk should be a hub of value creation.

A Little More Information

As not everyone was lucky enough to attend the event, we thought it might be useful to pull together a list of recommended reading (and watching) to help you learn more about these key takeaways. First of all, you should start by familiarizing yourself with your ABC’s with this great paper from Paul Wilkinson. Then dive into:

Other Topics

Advice was provided on a wide variety of other ITSM topics as well, such as:
  • Using Service Integration and Management (SIAM) to improve the delivery of your IT services
  • Migrating to the Cloud
  • BYOD benefits and strategy
  • The importance of customer experience – ITSM is not just about technology
  • Service Desk training and employees
For these we recommend taking a look at the following: Over the course of the next few weeks we'll also endeavor to write some "how to get started" articles on these main topics (e.g. "how to get started with DevOps"). Too often at events we find ourselves discussing the "why" but rarely explaining the "how". So don't forget to check back for those.

Overall

LEADit was a fabulous event and one that we would recommend to any IT professional, not just in Australia, but worldwide. It's not the only event itSMF Australia runs either, there are plenty of regional events to choose from. Don’t just take it from us though, check out the Twitter stream to see what others in the ITSM community are saying (you’ll likely pick up a few more gems of knowledge by reading through these tweets too). SysAid at the ITSM Australia Event Joe at Australia ITSM Conference  

Like this article? You may also like: My Feet Are Killing Me!.

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

How Long Should an ITSM Project Take?

Posted by on August 19, 2014 in ITIL
Incremental improvements is perfect for ITSM I know that the question “How long should an ITSM project take?” is going to get an answer of “It depends on what you’re trying to achieve”, but stay with me a while and see if you agree with my view on this.
I was running a workshop for a customer recently, helping them to create an operating model for IT support. Participants in the workshop included people from many different parts of the customer organization, and an independent ITSM consultant who the customer had selected to do any process development work that was needed. The customer already had working processes for most ITSM areas, the trouble was that they had different processes in each of many countries. As part of our plan to consolidate some of the work to fewer locations the customer needed to develop new processes for incident management, request fulfilment and knowledge management. The first stage of the project would require development of the new processes, including defining all the categories, priorities etc. that would be needed by the service desk, and also defining how existing knowledge could be shared more effectively. A later stage of the project would actually deploy these new processes. I was absolutely astonished when the ITSM consultant told the customer that the process development work would take at least 12 months to complete. Both the customer and I explained that we didn’t need “perfect” processes, just something that was good enough to continue the project. We intended to use continual improvement to make the new processes more effective over time, but the ITSM consultant was quite sure that even this couldn’t be done in less than 8 months, and that it would then take a bigger team than the two people that he had been planning to use! If ITSM consultants continue to tell customers that they need to run enormously expensive and time consuming projects that take years to deliver any value, then those customers are just going to stop listening. Businesses can’t afford to invest money in internal projects like that anymore, and there are much better ways of working that can deliver value in weeks rather than years. I had some involvement in development of the ITIL Journey, which was published by AXELOS (the owners of ITIL) last month. This was designed to help organizations make significant improvements to their ITSM practices in just a few weeks. There are also some great ideas on how to make quick ITSM improvements in “ITSM doesn’t have to be complicated” by Joe The IT Guy, and I’m sure that many readers of this blog could point me to more examples of how this can be done. I remember projects from many years ago where we would spend years developing ITSM processes and nobody got any value until we were good and ready, but I thought this monolithic approach to ITSM process implementation had been consigned to history long ago. I hear people explaining that the Agile approach to software development is not suitable for all organizations, and that some critical software development still needs a slower waterfall approach. The examples people refer to are usually design of controls for critical infrastructure, or core financial applications, or other areas with very challenging requirements for confidentiality, integrity or availability. I can see how these critical solutions might need a different approach, but I really can’t see how development of IT service management processes falls into this category. The iterative approach to creating value by implementing the minimum viable functionality and then incrementally improving our solution seems perfect for ITSM. If we take this approach then we can deliver some value in weeks – and the people we are asking to invest in our ITSM solutions will get measureable improvements, and measureable value, in the sort of timescales that make sense to them.

What Can You Do?

If your ITSM project doesn’t plan to create real value in a short time then you probably need to think again. Think about how you can break your ITSM solution down into multiple short sprints, each of which can deliver something you need. For example here are some things that an IT Consultant could do to shortcut the 12 month process development phase described above.
  • Review what is being done in each location to see if you could simply adopt one of the existing solutions, with a view to improving it later if it isn't 100% right.
  • Decide to create very few incident categories for the first release of the new process; it’s easy to add new categories later if they are needed.
  • Agree to a basic prioritization scheme with key customers. Again this can be refined later, it just needs to be good enough.
  • Trust people to follow high level process documentation and only create detailed work instructions for things that will need many people to behave identically. Again, it is easy to create more work instructions later if people clearly need them.
  • Pilot the new processes in a small location to see if they work. This will help to reduce the risk of introducing new processes worldwide in one big change.
  • Define very simple customer-focussed reporting for the first release, with a limited set of internal metrics. More KPIs and reporting can be added later if needed.
  • Limit the first release of Knowledge Management to simply consolidating all existing knowledge articles into a common structure, so that anyone can find and use them. Future iterations can improve this.
  • Only create a small number of automated service requests for the initial Request Fulfilment process. This can be used to demonstrate the value of the tools and process and you can then iteratively add more automated requests.
This is just an example; your situation will be completely different. The key idea to take away is that you can create something valuable fairly quickly and then improve it by incrementally adding more value.

Like this article? You may also like: Continual Service Improvement (CSI) - The Most Important Service Management Process.

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

4 Things You Need to Know About IT Maturity Assessments

Posted by on August 13, 2014 in General IT
4 Things You Need to Know About IT Maturity Assessments IT maturity assessments come in many shapes and sizes. Some are broad and look at a large number of areas, like strategy, culture, governance, people, skills, transparency, risk management, security, processes, asset management, customer satisfaction and supplier management. Others are deep, looking in detail at how your organisation aligns to a best practice framework, like ITIL or COBIT. Either way, an IT maturity assessment is designed to benchmark your current IT capabilities against a fixed scale. It will give you a baseline – a snapshot of where you are now – from which you can plan a roadmap for improvement. An IT maturity assessment tool can be a valuable tool, but some planning is needed to make sure you get value from your effort - so here are some of the things you should be aware of...

You Need to Have a Clear Purpose

The first question you need to ask is why do I want to assess my IT maturity? If it’s to benchmark your IT capability against the rest of your industry, you’re doing it for the wrong reasons. If it’s to arm yourself with a maturity score to fend off attacks from the business, think again. To get the most value, you need to take a step back and look at the bigger picture. An IT maturity assessment is worth nothing without a commitment to acting on the result. The value of an IT maturity assessment lies in the context of improvement. It will tell you where you are now. From there, you can plot a roadmap of actions to get you to where you need to be (we’ll look at that in a moment). Once you’ve followed that path, you can use the IT maturity assessment again to benchmark against your former self and identify if you’ve actually arrived. However, it’s important to remember that IT maturity is a moving target. As soon as you take a step forward, it moves away from you. IT maturity is the pot of gold at the end of the rainbow. You never quite reach it, because there will always be room for improvement as new technologies and best practices emerge.

IT Maturity Is What the Business Says It Is

So, we’ve mentioned where you need to be. In other words: what does IT maturity look like? It looks like what the business wants it to look like. Whatever IT capabilities the business needs to compete and succeed – that’s what IT maturity looks like. In the cycle of strategic IT improvement, once you’ve done a maturity assessment, your gap analysis should be against where the business needs you to be. Alignment with ITIL best practices doesn’t make IT mature in the eyes of the business. The business doesn’t care about ITIL. So, if you want to define what mature looks like, you have to involve business stakeholders and it has to be done in non-technical business language. Once you’ve defined it, get acceptance from the business before you proceed.

The Best IT Maturity Assessment Is Your Own

Every business is different, so every IT department is different. With many of the “commoditised” IT functions (like email) being outsourced to the cloud, what remains is the technology that makes your company different. The chances are that your data centre is changing, and the people and process factors are becoming a bigger part of IT capability. So IT maturity will look different in every organization. It’s up to you and the business to decide what IT maturity looks like. That means looking at business objectives and identifying the IT capabilities that support those objectives. It’s unlikely that you’ll find an “off the shelf” IT maturity assessment that represents what IT maturity looks like in your organisation, but as long as you are mindful of the differences a ready-made maturity model can be is a good starting point – particularly if you’re ranking at the lower end of the scale. Over time, you will be able to form a better picture of what your own IT maturity looks like, so you can adapt the model to form a better fit.

People Bend the Truth When They Complete Maturity Assessments

IT is a complex domain, so IT maturity assessments can become very involved, with dozens or hundreds of probing questions. What happens if you hit an “I don’t know” question half way through? Do you abandon the assessment? Do you just guess? Or do you go and find the guy who knows? Soon you’ve got a room full of people arguing over each and every input. But who’s right? Egos and self-preservation quickly come to the surface. And didn’t they all have jobs to do half an hour ago? Maybe you persevere with the assessment on your own. With no universally agreed metrics, the numbers you plug in to a maturity assessment will always be subjective, and people tend to err on the positive side. Nobody wants to hand the boss “a rod for their own back” by submitting a low score, so a few minor adjustments will make the picture a bit rosier and the boss a bit happier about IT. But if the assessment is to form a baseline for improvement, you’re starting off on a shaky foundation.
Continue reading

It’s 14.4 O’Clock in the Cloud

Posted by on August 12, 2014 in SysAid
It's 14.4 O'Clock in the Cloud I can't believe how fast time flies. It's been only a few weeks since our last release and already our next Cloud release is about to be launched. SysAid 14.4 is packed with really great features for all of you to enjoy, and of course several more fixes and improvements. I’ll guide you through some of my personal favorites.

New Report: Track SR Field Changes

We added a new report that runs on the history records of the Service Records (SRs) and can report any changes in field values. You can:
  • Define the threshold for the report that includes the number of changes.
  • Select any field, from Priority to Category and even Assigned Admins.
  • Get the initial value and the current value with the details of who updated and when.
  • Display in the report all the values that appeared for the selected field during the SR’s lifecycle.
I'm sure you'll find this report very useful, especially those of you who follow the CSI (Continual Service Improvement) processes. You can track the quality of services and the processes behind them by identifying areas that need improvement. For example, when there are a lot of changes to the assigned admin or category or even priority, then all these changes affect the quality of service you provide; this report will help point out the SRs you would probably want to look into in your weekly/monthly review. SysAid 14.4: Track incident management field changes

Links Between SysAid Items and Solution Models

In Release 14.4, be sure to pay attention to the following set of features regarding linked items in SysAid.
  • We enhanced the linked item functionality allowing you to link practically any item in SysAid (e.g., SRs, knowledge base articles, assets, users, projects, CIs, company, etc.) to any other item. This allows you to create the relevant links that make sense in your internal processes.
  • We also made it possible to create related items in templates so that when you create new SRs from templates the links will be included automatically.
  • We added a new field in the SR form called Solution Model. When you have a well documented process for solving a specific issue, you want to make sure your IT team follows that process and doesn’t “reinvent the wheel” each time they run into similar issues. You can make the most out of this feature in 2 simple steps:
    1. Make sure to link your KB articles (that contain the knowledge to solve issues) with any relevant entity in SysAid, such as: assets, CIs, users, companies, SLAs, groups, templates, and more.
    2. Once you have those items related, all you need to do is add the Solution Model control to your SR form. You probably want to locate it on top near the title. This control stays hidden and doesn’t consume any of your screen space.
Once you use a template that has a KB article attached to it, or select an entity that is attached to a KB article, then the KB article will be presented to you and your team so you are aware of the suggested solution model. This way you can make the most out of the existing knowledge and ensure it is being presented to your team whenever relevant, as opposed to asking your teams to look it up each time. Try it out, I promise you will love it! Links Between SysAid Items and Solution Models Speaking of the Knowledge Base, I want to mention that following requests from many of you, we also added a full history log for KB articles. Just like the SR history log, the modify time and user is displayed along with the revision version of the article. This provides a full audit trail for your knowledge base articles!  

Weighted SRs

Saving my favorite feature for last. Now IT Managers can assign a weight to their staff's SRs to determine the order for handling the SRs according to true business priorities. This way you can make sure that the SRs that require immediate attention won’t be missed, regardless of their priority. Every admin will clearly see SRs in his/her queue that have been given weight, to indicate that they should be dealt with first. Clicking the new icon also sorts the weighted SRs according to their actual weight value, floating them to the top of the admin’s list no matter what filters are applied and no matter how the list is ordered. Your admins will easily see the true priority the business has assigned and you can rest assure that your team is putting effort in the right place and in the desired order. SysAid 14.4: Weighted incident records As always, to enjoy the new features, make sure to opt-in.You can read more about them in our Online Help - available in your SysAid from your Personal Menu on the top-right of the screen. There are more features included in Release 14.4. Check out the Release Notes, and I can’t wait to tell you about some of the new features we are already working on, but I’ll save that for a different blog post. Image credit

Like this article? You may also like: SysAid 14.3 – It's Your Voice that Matters.

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

Whipping ITSM into BDSM

Posted by on August 5, 2014 in Service Desk
Whip IT Service Management into Business Development Service Management Why do I keep reading such statements as “get rid of IT from ITSM?” Is it that Service Management simply needs to get out of the IT world? I can get that—we want to try and project the belief that IT has been growing its involvement with the business. In fact, there are the ongoing debates on whether IT will survive the next 10 years, if it'll take over the business, or if regular users will become so technically adept, that the business will eventually do away with IT. Since I'm not an astrologer, I can't predict what's going to happen in the next decade, although if I had to guess, I’d say not much will really change and all of this talk is mostly hot air. But I do have an issue with just stating "get rid of IT from ITSM," and the issue is simple.
Look, people can grasp the idea of Information Technology. Ask anyone, and they'll probably say "its computers and stuff." Easy. In fact, I'm all for dropping "Information," since technology itself is a good enough descriptor for defining our use of computers as tools. But if we completely get rid of IT from ITSM, then what are we left with? Service Management? Can you imagine meeting new people at a party (and I mean a real party, not Fusion, Pink or SDI, and telling someone you work in Service Management? I've just started getting used to the blank stares I get from newly met friends in stating I work in IT Service Management - they can at least get the idea I work in IT, which then leads into the next question of how best to prevent viruses (incidentally, the answer is to stop visiting religious websites since porn has become safer to surf). Not only that, but the word "service" can have several different meanings. In the US, it's most closely associated with a call center or help desk. I've given up a long time ago in trying to reeducate my fellow man that a service, according to the ITIL® Foundation, is "a means of delivering value to Customers by facilitating Outcomes Customers want to achieve without the ownership of specific Costs and Risks." I think people tend to think of services in such a way, but when actively being questioned on the definition, few of the people outside of ITSM can really describe a service as eloquently as the standard ITIL® definition. That now brings me to the people already working in IT. How common is it for an organization to provide an accurate, useful and practical map of its services? The closest I've seen to such a thing is a CMDB that has applications listed as the services. This lack of understanding of how to map technology to actual business value is a driving force for pushing to have IT understand the business, and it's a great philosophy that every CIO should push in their organization, but it's still not forefront in the mind of the day-to-day developer or sysadmin. In essence, why focus on the phrase of "Service Management" when IT itself still doesn't know what to do with it? While I think dropping IT from ITSM is a bad idea, I am not against changing the verbiage to better describe the growing trends we're seeing in IT. As IT and the business grow into the impending singularity (which I still have some doubts about, but I'll go with it), I'd like to suggest a description that fits how IT is moving from the role of technology provider to that of strategic partner. We should consider Business Development Service Management (BDSM). That's right, business development - the act of supporting the business for long-term growth and profitability. Making this distinction will play in our favor in a few different ways:
  • The BDSM discipline places the IT culture and mindset around the concept of ongoing growth and search for new opportunities.
  • BDSM isn't about tying up resources specifically to focus on new growth, but also it’s about binding with the aspect of Service Management, which is key to having IT act as a strategic partner.
  • There have been references to the idea that future COOs will be those coming from an IT background. With a history of BDSM, the next generation of business leaders will be able to position traditional business processes to be more aligned with the agile practices and DevOps culture growing in IT.
  • With growth and change being constant in business development, BDSM will be able to better prepare practitioners for the pain involved in continual improvement, something so prevalent in ITSM.
  • The business could then take blindfolded confidence in IT, knowing that the primary goal of the BDSM mindset, as run in IT, is to guide the business for new development, instead of being subservient in the technology support role, thus becoming a true strategic partner.
As the role of IT evolves and takes shape over the next few years, we'll be seeing several changes. Some analysts predict the end of the service desk. Others predict that the business side will start to develop its own solutions. Even others have predicted an end to IT. While I doubt such prophesies will come true overnight, as IT moves into the business world, we’ll eventually have to determine the role which ITSM will play. By verbally shifting focus of ITSM from IT to business development, we can prevent cuffing ourselves to the traditional sense that we only care about technology, and instead embrace ideas of strategic growth and value. Who’s with me?

Like this article? You may also like: High Touch, Transparency, and Good Customer Service.

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

Advice for Improving Customer Satisfaction on the IT Help Desk

Posted by on July 29, 2014 in Service Desk
Advice for Improving Customer Satisfaction on the IT Help Desk “The customer is always right,” right? Whether that old adage is true is irrelevant.  But there is another saying that should be plastered on the walls of every IT help desk: The Customer is Always the Customer. And, as a customer, each is entitled to polite service, accurate information, and timely resolution of any issues. The following tips for IT help desks will help you improve customer satisfaction levels. Remember that ITSM is not just about the technology; ITSM is about people. Staffing a help desk with people who are both technically savvy and customer-centered is a fundamental building block of a successful IT help desk.

Tip #1: Remember – your job is to help the customer

Sometimes, you may become frustrated by customers’ endless requests. In these situations, take a step back to understand how your customer feels. Try to view the situation from their perspective. A customer may need a password reset, which in the grand scheme of IT challenges, seems trivial.  But, to the customer, the password issue hinders their work and causes a major problem. When addressing your customers, understand their frustration, empathize, be patient and polite, and offer easy-to-follow guidance and effective solutions. This is the golden rule of customer satisfaction: treat your customers as you would want to be treated.

Tip #2: For the resources you provide to be useful, they must be easy to find and understand

If you have a thorough knowledge base that nobody uses, or if your team spends too much time answering questions that are in the FAQ, your resources are likely either too hard to find or too hard to understand (or both). In a 2012 survey conducted by leading analyst firm Coleman Parkes, more than 40% of customers contact a call center after they can’t find answers to their question via self-service; up to 50% of “How do I …?” calls could be deflected to self-care channels if information was provided online or in a knowledgebase. If they are not using your resources, find out why. Survey your customers to find out how they currently search for answers and what medium (text instructions, images, video) would be most helpful to them.  In some cases, different types of customers prefer different types of resources.  You could offer some of your most common solutions in multiple formats and track which ones are used most often (and by whom) to resolve issues. If your surveys are not getting the response rate you would like, see tip #5 below for advice on improving your feedback strategy. The bottom line here is that your resources need to be both informative and user-friendly.  Striving for the utmost of both factors will enable your customers to help themselves.

Tip #3: Respond quickly, even if only to acknowledge receipt of the ticket

When a customer opens a ticket, respond.  And respond promptly. A timely response lets your customers know that their issue is in the queue and it sets expectations. It only takes a moment (you can automate it in most ITSM tools), but promptness is critical.The faster you respond to your customers, the easier it becomes to solve a problem. Timely responses increase customer satisfaction.

Tip #4: Update customers about ticket status

Your customer would be more satisfied if they were updated about the status of their ticket. At this stage (and, really, at every stage), it is important to set expectations.  Focus first on the customer’s key concerns. Did they need equipment that is on backorder?  Explain how much of a delay they should expect. Were they concerned with availability? Inform them of what a reasonable standard may be. Until all tasks are complete and their issue is closed, send an email, update the ticket, give them a call – and let them know the steps you have taken, what the next step will be, and what the ETA is for resolution.

Tip #5: Ask customers for feedback and act on their advice

If you want to improve your customer satisfaction, ask your customers what needs to be improved. But conducting a survey is not enough, to show your customers that their input matters, use their feedback to instill change. You can send a survey after each ticket has been resolved or you can send periodic surveys to customers who fit a certain profile (or you can do both). According to Oracle, “Ideally, you should survey your customers just often enough to get the information you need but not so often as to annoy them. The frequency of customer satisfaction surveys will depend on the frequency of your organization’s interactions with customers.” Inform customers how long the survey will take (there we go, setting expectations again). Make your questions as neutral as possible to get honest, helpful answers. A normal response rate to customer satisfaction surveys is 10-15%.  To increase yours, consider sending a reminder and offering an incentive.

Opportunities to improve customer satisfaction

The customer may not always be right, but if you take each interaction as an opportunity to learn something from a customer to improve your service, then the customer is never wrong either. At the end of the day, the customer and the IT help desk are all on the same team with the same goal—resolving the issue.  As you focus on that, take this advice to heart:
  • Treat customers with respect
  • Offer them helpful ways to solve the issues themselves
  • Respond to their requests quickly
  • Keep them updated
  • Ask them for feedback
Want to share any other bits of advice? Would love to hear from you.

Like this article? You may also like: If We Could Just Talk to Our Customers.

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

Can You Imagine a World Where IT Professionals Do Not Exist?

Posted by on July 25, 2014 in General IT
Before you click play, imagine a world where IT professionals do not exist. Can You Imagine a World Where IT Professionals Do Not Exist?
Throughout the year we stand by all of you amazing IT people. We appreciate everything you’ve done in the past 365 days. This year was full of IT challenges, like BYOD, shadow IT, cloud, and Heartbleed, not to mention standard day-to-day challenges, like keeping up the good service, coping with end users, aligning to business needs, and so much more. In the industry this year, a new discussion was started on what the future holds for the IT role, what it will look like with the growing trends of BYOD, shadow IT, and cloud. Many even went as far as to say the role of Service Desk Analysts and SysAdmins would potentially not exist a few years from now. At SysAid, we know exactly what you do and have no questions about the important role you take in the success of your organization. We don’t see your roles disappearing, in fact we believe that with the new changes, the organization will only need your IT skills even more. So...as we do every year here at SysAid for System Administrator Appreciation Day, we’re happy to once again provide you an opportunity to look at an alternative reality that will make you laugh and will show our growing appreciation to all of you great IT people and everything you do—365 days a year. Happy SysAdmin Day! Cheers, Sarah
Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

Knowledge Management Is Not Just About Document Repositories

Posted by on July 23, 2014 in Service Desk
Knowledge Management Is Not Just About Document Repositories When I ask people how they acquire the knowledge they need to do their jobs they describe a huge variety of approaches that work for them, including working with other people, attending training, reading books and blogs, watching videos, trial and error, being mentored and more. When I ask IT management what tools and techniques they use in their knowledge management programs they often just describe tools that are used for managing and sharing documents. If our knowledge management efforts are focussed on this very limited view then we will never equip our people with the knowledge they need to be effective and efficient. If we remember that knowledge only has value when it is available to someone, either because they remember it or because they are guided towards it at the time they need it, then that can help us to understand what knowledge management needs to achieve. It’s much more than just storing documents in a repository.
When you create a knowledge management programme, you should focus on achievable outcomes that will generate some short term value that you can then build on. Don’t start with an enormous over-arching programme that will take years to implement and even longer to create value. It’s good to think about the entire scope of where you may want to be in the long term, but make sure that you have manageable steps to get there and that each step has measureable ROI. One place that many organizations start to implement knowledge management is at the service desk. If your service desk people have the right knowledge then they can work more efficiently, and they can also deliver more value to your users. This great combination of improved efficiency and greater quality is a common result of good knowledge management. So what is needed to improve the knowledge of your service desk people? Maybe you could start by talking to them. Understand what they find difficult, what kinds of mistakes they make, what knowledge they think would be useful to them. Make sure you think about things beyond technical knowledge. What do they know about how the business works and what the users do? Is this enough to help them communicate well? Research how other organizations do knowledge management, at a minimum you should investigate Think about all the different tools and techniques you could use to help your people develop the knowledge they need. Some of the things that you might consider include:
  • A known error database integrated with your service desk tool
  • A document repository such as SharePoint
  • Face-to-face or online training
  • Webinars, podcast, YouTube videos and other on-demand media
  • Forums and social media that can be used to ask and answer questions – in-house or external
  • Mentoring or coaching
  • Directory of subject matter experts to enable people to find someone that can help when needed
  • Newsletters, emails and other mass communication channels
  • Access to “sandpit” environments where they can experiment with the software and hardware that the users have – this is especially useful if there is a planned change so they can familiarize themselves before the users get new or updated applications
Once you have understood what knowledge is needed you should be able to identify one or more of the above tools and techniques to make this knowledge available when and where it is needed. Remember that different people learn in different ways and you shouldn’t force everyone to use the same approach. It is important to think about how you can measure the effectiveness of your knowledge management efforts, and how you can use these measurements to facilitate continual improvement of knowledge management – both the process and the actual content. Then when you have created effective knowledge management for your service desk you can identify the next area of IT that could benefit from this approach. Image credit

Like this article? You may also like: Continual Service Improvement (CSI) - The Most Important Service Management Process.

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!