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.

A Practical Approach to Getting Started with Service Catalog

Posted by on March 9, 2016 in ITIL
Service catalog Q&A Recently I presented a webinar on getting started with service catalog. It's a topic that comes up often because getting started can be harder than it looks – especially without the support of a full IT service management (ITSM) program. If you know you need a service catalog but aren’t sure where to get started, the webinar offers a practical approach to get you up and going with a basic service catalog. Some of the common challenges that organizations face when trying to build the service catalog are:
  • Staff may think: ”Our users know what we do”
  • IT services evolve too rapidly
  • Changes are made with little formal change management
  • Siloed organization: poor/informal communication between teams - app dev, infrastructure, and support
  • “We are technology (not service) providers”
  • Lack of service owners
  • Cultural resistance
  • Lack of organizational support
  • Lack of time and attention to build it
  • Thinking that 'service catalog' is a document – “We already have one...somewhere...”
If any of these sound familiar, I encourage you to watch the webinar and download the whitepaper.

Your Questions and My Answers

Below are my answers to some questions asked during the webinar. Q1: "If you need to create a request catalog within a very short timeframe, what is the least amount of information you would recommend to publish in a live catalog, before being able to circle back and add/fill in more information?" A1: Kind of a 'minimum viable product’ approach. I like the question, partly because it's realistic. Of course, the balance you’re getting at is that it will take some time to gather the information I described in the webinar, delaying publishing a catalog. This is why I strongly recommend starting with a very basic service description. I like the saying "if you can't explain it to a six year old, you don't understand it well enough" (or something like that). The bottom line is that it should be relatively simple to write a paragraph or two describing the service. Getting bits and pieces of that description from as many people who know parts is the strategy I highly recommend. In so doing, you both get a complete picture, but you also get the buy-in of those who contributed to the effort. So, to answer the question directly: a one or two paragraph description is the minimum amount of information on which to base your first service catalog. Q2: "Can we have an example of a good service catalog?" A2: I wrote a whitepaper to go along with the webinar that has a pretty decent sample in it. You can download it here. Hopefully it will get you going in the right direction. Q3: "Can I use <several tool vendors mentioned> for ITSM just like other vendors available on the market?" A3: There are lots of effective tools for service catalog. Honestly, though, the greater challenge, by far, will be the cultural aspects addressed in the webinar. There's no magic solution to make that part easy, which is why I encourage you to focus on the people and the process long before looking at tools. This is my recommendation even if you already have a tool. Keep it simple and focus your efforts on the people and the process. Once you've done the hard part – as I addressed in the webinar – implementing it in a tool is a snap. Q4: "Typically, what does each item in a service catalog link to? Help Desk requests? General documentation? Just curious to see or hear about examples." A4: This gets to a point that I only lightly touched on during the webinar – the difference between a service catalog and a service request catalog. In short, a service catalog is a listing of available services. Clicking on a service generally brings up additional details about the service, and likely includes a "how to request service" section. A service request catalog is automated, so clicking on the service takes you directly to a request form of some type – making it very simple to find, select, and request a service. The obvious analogy is the online shopping cart. Online retailers have mastered the art of making it easy to find what you're looking for (and often stumble upon some things you didn't even know you needed!), and making it super easy to get in your cart. Q5: "How do you handle third-party and hosted systems?" A5: I think the question has to do with implementing a service catalog on a hosted ITSM tool, which can vary quite a bit between the various vendors. I’m far from an expert in the various tools out there, but there are two key things you want to keep in mind:
  1. Make sure it’s easy for users to find the services they need
  2. Easy integration with the rest of your ITSM solution
These are key regardless of the tool or hosting arrangement. Q6: "What is the best way to determine the frequency of the service catalog update for a particular company?" A6: The challenge is doing it often enough to keep it current, but not too frequently that people start feeling like it’s taking up a lot of their time. It’s something you kind of have to size up according to the culture of your organization. Yearly is the least frequent I’d recommend. Ideally, I like having a quarterly review – maybe even tied in with a quarterly service review, or customer meetings. Q7: "Would you use a service catalog as a starting point to agree on SLA's? Should they be included in the catalog?” A7: It depends how well established SLAs are in the organization. For organizations who are just establishing what their services are – SLAs probably either don’t exist, or are just being introduced. My concern is introducing two concepts at once – the service catalog and SLAs. On the other hand, if your organization has had SLAs in place for some time, and both IT and the business understand them, then they should be included (to help users understand what they can expect of the service). Q8: "What if our customers are both non-IT and IT users who would be using the Service Catalog? How do we gear the Catalog for both?" A8: I like the concept of a multi-viewed catalog – a customer view and an IT view. It’s a concept buried in the ITIL books, and it can be really helpful. The customer view should be focused on the details important to end users, and the IT view should highlight the technology components and how they’re integrated to deliver the service. Q9: "Do you recommend a category and a sub-category of service catalog?” A9: During the webinar, I talked quite a bit about making it easy for users to find what they’re looking for. I’m a fan of broad categories – like “computing services” and “phone and voice services” with no further sub-categories. One of the elements of good user interface design is limiting the number of clicks required to find what the user is looking for. Drilling down to multiple sub-categories, which may seem logical (especially to us techies), can make it harder for users to find what they’re looking for. Also – keep in mind that we IT people think differently than our customers. What makes perfect sense to us may completely confuse our users. It’s also worth mentioning that it’s a good idea for users to be able to find services in various ways, like alphabetical listing and keyword searching. Q10: "For your internal view of your service catalog, should you link your more detailed service catalog items to standard operating procedures or should SOP's be separate?" A10: In concept, I like having everything nicely linked and easy to find. But in practice, this is where a service catalog effort can really struggle – trying to do too much too soon, and losing support. I’d much rather see success with a very basic service catalog with strong cultural support for it, and then continually improving it – with the input and involvement of stakeholders. Q11: "How can we determine the best level of granularity/detail to include in the service catalog?" A11: A good question that actually gets to the heart of my webinar. To answer the question, you have to get the experts in your organization involved. I talked quite a bit about ‘tribal knowledge’ – the idea that the details of your services are known in part by many different subject matter experts in the organization. The goal is to leverage that knowledge and create descriptions that the ‘tribe’ agrees to in the end. Keep in mind that it’s far, far better to be successful with a very basic service catalog and improve it over time than to start too big and fall short. Q12: "How can we involve the end users in performing the service catalog?" A12: Here’s a question that I love – how to get your customers involved. I really like it because that’s where it has to start – with the customer perspective, and what better way than to get them involved.  But how? Most organizations have what I call “IT-friendly” users out in the business. Those people who other users go to for help and questions before they call IT. If you don’t know who they are, ask your service desk team. They do. Form a users advisory group and ask for their help in shaping the service catalog. (Many major software vendors have been dong this successfully with beta programs, power users forums, and advanced releases.) If you do a customer survey, ask if they would be willing to serve on a focus panel, and form a group to review the service catalog. If you have relationship management, do service reviews, or hold other customer meetings; put the service catalog on the agenda and ask for feedback. Q13: "If I was starting from nothing should we start small and grow out services; was thinking of building internal IT services first and then learn and build out. Does this seem a reasonable approach?" A13: Couldn’t have said it better myself. Yes; that’s exactly what I’d recommend. Remember that a big part of the challenge is getting the culture of your organization to adopt the service catalog into daily operation. By starting small and gaining momentum, you’re greatly increasing the odds of successful adoption. I also like that you highlight learning as you go. This is really important even if you’re very familiar with service catalog – you want the people in your organization to learn about service catalog, and get engaged in improving it as you go along. Q14: "Some services have nothing to do with technology (e.g. consulting).... " A14: That’s absolutely right. And if there are non-technology services you offer – include them in the service catalog. You’ll want to be sure they’re defined as services (not activities). Services should:
  • Be recognized by users as a solution
  • Support a business process
  • Include all the technology components
Thanks everyone who attended the webinar, and thanks for all the great questions.  If you haven’t had a chance, you can still watch the recording. Good luck with your service catalog!
Continue reading

6 Tips to Stay Motivated on the Service Desk

Posted by on March 2, 2016 in Service Desk
Service desk motivation Working on an IT service desk can be a thankless task at times. There’s a reason why it’s generally accepted that there is often a finite shelf life for people in the service desk agent role. If your IT service desk is of the “log it and flog it” variety, where the ticket is logged and transferred to a specific resolution group if it isn't a super-easy fix, it can feel like you are working in a never ending loop Feeling enslaved to your telephone and computer can be dreadful. It can be a serious drain on morale, with a direct impact on how motivated you are to do your job. Then there are the irate end users – unhappy either that their IT isn’t as it should be or because they aren’t being treated with the importance that they think they deserve.
Factor these in with the heavy workloads, multitasking expectations, and potentially long days and it can be hard to stay focused. And tiredness and a general feeling of boredom do not make for the most effective service desk analysts. So what can you do to get your service desk mojo back? And how do you sell the change to your boss?

1 – Rediscover What You Love About Your Service Desk Job

Chances are that you started on the service desk because you wanted to help people. So spending time within the business, with your colleagues and customers, can help. Hopefully you will see issues and problems being experienced that may well be going unreported. Or you will see opportunities for technology-use improvement. Spending time in this way will also give you further insight into how the business views the service desk, and hopefully remind you of the importance of your service desk role in keeping people and business operations working. How to sell it to your boss: Concentrate on the benefits to the service desk. Insight into the struggles of your end users will help to shape the services that your team provides.

2 – Keep Learning, Maybe “Shadow” Someone Higher Up the IT Hierarchy

You may have already decided that working on a service desk long term is not for you. You may have an idea of the direction that you would like your career to take. Or you may not. Either way, “shadowing” someone else in the organization – that’s working with another employee in a different job who might have something to teach– will give you experience of what their job entails. It may cement how you feel about the new role or scare you off completely. At the very least it will give you insight into what these other roles or teams deal with on a daily basis. How to sell it to your boss: Many service desks experience a degree of conflict with other IT teams. Working within these teams can help service desk agents to appreciate the other side of the argument. Experiencing the challenges of these teams helps with empathy and maybe could even lead to a change in inter-team working practices.

3 – Change of Scenery, Maybe Apply for a Secondment

Shadowing another role is fantastic but do you know what's potentially even better for your service desk blues? Actually doing the other role. Getting to perform an alternative role on a temporary basis –what my British colleagues call a secondment – will give you a fantastic experience and a change from the old routine (and the associated pressures). It’s an excellent opportunity for you to see if this is something you could see yourself doing longer term. How to sell it to your boss: Can you see a spot where there is pressure building within another IT team – usually evidenced by work backlogs and delays? Could you help to reduce it by stepping in for a while? An externally-sourced temporary staff member might not have been considered due to the time and energy it would take to train someone in the nuances of your business. But you already have this knowledge and can “hit the ground running.” It may also be easier to recruit a replacement service desk analyst to temporarily back-fill you than for a more specialized position.

4 – Take on a “Project” Role

Sometimes a “bit of a change” is as good as a complete change. Taking on something new for a finite amount of time, i.e. a hands-on project that is longer and more involved than a secondment, may give you the break from the service desk that you need. Flexing your brain, and skills you don’t normally get to use, on something new even for a short while can help to stave off boredom and reignite your passion for your role once you return to it. You may find that the project role suits you or that the project area is something that you excel at. Succeeding at a project, either individually or as part of a larger team, is also a great way to get yourself noticed if you are trying to climb the career ladder. Project management methodology, whether you are formally trained in it or are just obliged to follow it on others’ instructions, can also be brought back into the service desk environment to help with day-to-day operations and improvement opportunities. How to sell it to your boss: Working on a project will help you to gain insight and knowledge in other areas – this could be either in business operations or a new technology. If the project is on a new application or business service you can also propose that you become the go-to person on the service desk after it goes live. An extra benefit to the service desk is having someone who can forewarn them of upcoming changes. As someone who has never worked on a service desk might miss the importance of involving it during the project. I’m sure that most of the service desk agents and managers who read this will have horror stories to tell about when a delivered project caused a massive spike in service desk tickets.

5 – Make a Plan of Where You Want to be Career-Wise and How to Get There

Is your career lacking direction? Could this be the reason why you are lacking motivation? Now is a great time to sit and think about where you want your career to go. Don't have any definite ideas? Then start with what you don't want to do and move forward from there. You can always use the previous tips to experience different things until you find something you think that you will love. Already know where you want your career to go? Well then, it’s time to think about training and courses that can help to support you in your journey. Again the previous tips can also help. How to sell it to your boss: Is the training also of benefit to your service desk role and the service desk as a whole? If so, then you should have minimal issues persuading your manager to support you (and to hopefully fund it). If they say that there is no budget, then see if you can find out when there will be budget. Go armed with information about the course you want to go on. If possible, take several different versions with different prices. Got the kind of manager that will always pick the cheapest option? Make a pros and cons list for each of them. Ultimately, make it as easy as possible for your manager to say yes, and to make their decision based on value rather than cost.

6 – Tell Your Boss About Your “Situation”

While you are ultimately responsible for your on-the-job motivation and performance, and career path, our manager has a responsibility too – not only to get the most out of you work-wise but also to ensure that staff are developed to provide maximum value to the organization. So have a chat with your boss at your next one-on-one meeting or performance review. You never know, they might have been in a similar position at some point in their career. Even if they haven’t, a good boss should be able to help through assessing possible internal changes and/or helping to find you temporary opportunities outside of the service desk. How to sell it to your boss: You shouldn’t have to if your boss is worth working for.

Over to You…

It’s inevitable that you’ll encounter periods of low energy at some point in your career. So remember that you have the power to overcome your slump. Hopefully these six tips can help you to renew your motivation and to become a happier service desk analyst (with a career plan) again. My six tips are just a handful of possible options. What are your tips for getting out of a motivation slump?
Continue reading

Pink16: Some of the ITSM Wisdom That Shouldn’t Stay in Vegas

Posted by on February 25, 2016 in ITSM
ITSM wisdom at Pink16 As always, the annual Pink Elephant IT service management (ITSM) conference (and Las Vegas itself) was a blast. Some of what happened in Vegas of course has to stay in Vegas, but much of the session content deserves to be shared with a wider audience. You’ve heard of “Joe Public,” well you can now think of me as Joe Public Service. It’s not easy when you’re an intergalactic ITSM superstar but, with the help of a blonde wig, sunglasses, and a few pseudonyms, I was able to sneak into a number of Pink16 sessions without the attendees being distracted from the presenter by my sheer awesomeness. Sadly, it happens a lot if I don’t go in a little like Daniel Radcliffe at Comic-Con.

My Pink16 Key Learnings

Learning number one, unfortunately, is that people still know that it’s me if I try the Spider-man suit approach. It didn’t help at Pink16 that The IT Skeptic didn’t follow my lead with a superhero pants-outside-the-tights costume. So I won’t try that again. I did get some good ITSM learning though. If you read my good friend Dena Wieder-Freiden’s pre-Pink16 blog, you’ll notice that I took her advice on which sessions to attend. Plus, I snuck into fellow New Yorker Alan Berkson’s session on enterprise service management. So here is my session-by-session breakdown…

“The IT Renaissance” with Rob England, The IT Skeptic

One of the great things about Rob’s presentation was that it joined, or pulled, a number of things that we tend to talk about in isolation together. Just as the Renaissance period between the Middle Ages and modern history was filled with new ideas, a new culture, new ways of thinking, and a new beginning, Rob’s concept of “The IT Renaissance” covered:
  • New ideas
  • A new IT culture
  • A new way of doing IT
  • A new beginning
Hopefully Rob won’t mind me borrowing four of his Pink16 slides (© Two Hills Ltd.) to articulate his points (and to save on my typing):

The IT Renaissance: New ideas

The IT Renaissance: A new IT culture

The IT Renaissance: A new way of doing IT

The IT Renaissance: A new beginning

“Don’t Rain On My ITSM Parade – Transitional Change Management When Moving to the Cloud” with Earl Begley

You can’t beat good quality practitioner presentations at ITSM industry events. It was great to hear Earl talking to why the University of Kentucky made the move to the cloud – it might be similar to what cloud vendor marketing collateral says, but it’s great to hear it from the horse’s mouth:
  • The inability of the infrastructure team to scale configurations to meet peak loads for critical academic events
  • Shrinking operational budgets, meaning longer gaps in hardware refresh and limited opportunity to change architecture
  • Increasing labor time spent on maintenance functions versus new project/creative solution work
  • Risks around natural disasters, security, and resource management
And no, I’m not saying you’re a horse Earl. In his offered lessons learned, Earl used two great images* in particular to talk about how: Practice is different to theory Practice is different to theory User experience will always trump design User experience will always trump design I’ll definitely be stealing them for my future presentations.

“Why Governance of Enterprise IT (GEIT) Is Not a 4 Letter Word!” with Robert E. Stroud

Firstly, you have to watch Rob Stroud and his four-letter words! One of the key things that I took away from Rob’s presentation is the ISACA, or at least Rob’s, multi-faceted definition of IT governance:
  • “IT Governance is the responsibility of executives and the board of directors, and consists of the leadership, organizational structures and processes that ensure that enterprise IT sustains the organization's strategies and objectives.”
  • Integrate and institutionalize good practices
  • Take full advantage of information
  • Satisfy quality, fiduciary, and security requirements
  • Optimize resources
  • Balance risk versus return
And that it’s all too easy to have a narrower view of what IT governance is, probably determined by the limitations of our knowledge of different governance capabilities. I’d bet that if we asked eleven people to define IT governance that we’d get at least ten different definitions. Also that governance and management are different, in that:
  • Governance ensures that stakeholder needs, conditions, and options are evaluated to determine balanced, agreed-on enterprise objectives to be achieved; setting direction through prioritization and decision making; monitoring performance, compliance, and progress against agreed direction and objectives.
  • Management plans, builds, runs, and monitors activities in alignment with the direction set by the governance body to achieve the enterprise objectives.
Finally, Rob showed a great visual representation of how COBIT fits in with ITIL and other IT frameworks and standards: COBIT fits in with ITIL

“Helping Managers Enhance Skills & Services With ITIL Practitioner” with Kaimar Karu

Kaimar started by covering the skills gaps in modern-day ITSM:
  • Challenges with communication
  • Challenges with metrics and measurement
  • Challenges with organizational change management
His slide on “understanding how good metrics help” was of great importance to all those of us just “going through the motions” with their ITSM metrics – you know what I mean, the endless cycle of collect-report-collect-report with little done outside of this. Instead, ITSM metrics should:
  • Support validating decisions and assumptions
  • Set a clear direction for activities and improvements
  • Justify what we do and why we do it
  • Provide the means of healthy intervention for failing services
  • Utilize balanced, meaningful KPIs
  • Link the vision, mission, objectives, goals, CSFs, and KPIs
But where was the free craft beer you promised me Kaimar?

“Enterprise Service Management: It’s Time To Share ITSM Best Practices Outside Of IT” with Alan Berkson

Of course anything said by a native New Yorker sounds great and has a good chance of being ITSM gold dust… or at least that’s what I tell my boss. It was great to be reminded that IT didn’t invent service management. Plus, that IT isn’t the only corporate service provider that can benefit from service management or, for that matter, ITSM. Also that enterprise service management (or whatever you prefer to call it) is nothing new – with ITSM technology used by other business functions for at least the last decade. I especially took away Alan’s suggestions for improving an organization’s chances of enterprise service management success:
  1. Don’t treat enterprise service management as an IT project
  2. Allow for the differences between different business functions
  3. Don’t try to help other corporate service providers before helping yourself
  4. Don’t assume that enterprise service management will sell itself – justify it in business terms
  5. Think long and hard about how to deliver the enterprise service management project – starting small, focusing on a single business function or capability
Who’d have thought Alan went to school with Dena? It IS a small world after all. So some great ITSM learning from Pink16, although I’m sure Dena will put it down to her great session selections. If you were there, what nuggets did you come away with?
*Earl’s image sources:
Continue reading

Who Is Your Customer?

Posted by on February 24, 2016 in Service Desk
Customer service Great IT services create value for customers, with a focus on customer experience and customer satisfaction. Organizations that deliver IT services must manage a balance of people, processes, and technology. When it comes to people you need to consider the skills and behavior of IT staff, but it is even more important to focus on the most important people, your customers. This is not a new message, but it bears repeating because far too often the main focus of the people delivering IT services continues to be on the technology and the processes.

A Team with No Customers!

I was teaching an IT service management (ITSM) training course recently, and some of the students worked in a group that managed infrastructure. They delivered storage, servers, and networking to application teams, who used these as building blocks to create IT services for the business. I asked some of these students who their customers were, and they said that they didn’t have any customers. Really?! This reminded me of another organization where I worked some years ago, where there was a team who configured and deployed monitoring software to thousands of servers. People on the operations bridge told me that the monitoring software generated thousands of red alerts every day, and they picked out the really critical ones, ignoring the others. This was obviously a very risky way to detect events so I asked the team responsible for the monitoring software who their customer was. “We don’t have customers,” I was told, “we just configure and install the software.” This team had all the skills needed to configure the software correctly, but they had completely failed to consider the needs of their customers – because they didn’t’ think they had customers! My students eventually recognized that they did have customers – the application teams who built services using the infrastructure that they provided. This was a definite improvement, but it didn’t go nearly far enough. If teams within an organization see each other as customers, then they tend to focus on internal issues, and lose sight of the real customers, the ones that actually fund everything they do. The key thing to remember is that the external customers of the business provide the money that enables all of the business activities to take place. Activities that help to create value for the paying customers are worthwhile; and anything that doesn’t, is wasted effort. Service cycle As I worked with the students from the infrastructure team we established that they provide services to the application team, who in turn provide services to a business unit, who create value for the paying customer. Although it is very difficult for the infrastructure team to consider the needs, and experiences, of the paying customer at the end of this chain, it is essential that they keep this paying customer in mind when they are working if they are to provide that paying customer with great service.

Customer Focus

Like every other part of the organization, the infrastructure teams need to focus on customer value creation, customer experience, and customer satisfaction.
  • Customer value creation. I once had a really wise manager who said to me “At least once a day, you should stop whatever you’re doing and ask yourself ‘If the paying customers knew their money was being used to fund what you are doing right now, how would they feel?’. If you aren’t 100% sure that they would be happy then you should stop doing it.” I have followed this advice ever since, and it has been of huge value to me. Everybody in the entire value chain should be focused on creation of value for the paying customer.
  • Customer experience. Every interaction with the customer contributes to their overall experience. If you are designing a process, or a web form, or any other potential interaction with a customer, then you should base your design on an understanding of their needs. Ideally you should include customers into the design of everything that might potentially impact them. In the case of the infrastructure team, they should definitely consider the needs of their internal customers, the application team, but they should also think about how anything they do might impact the experience of the business units and of the real paying customers.
  • Customer satisfaction. Everyone contributes to customer satisfaction. Sometimes by positive acts that delight customers, and other times by failing to notice the impact of actions on the customer. Customer satisfaction comes from their entire “customer journey” – every interaction with the customer makes a contribution. We need to set their expectations correctly and then reliably deliver what they are expecting in a way that creates positive experiences. If you aren’t dealing directly with paying customers that doesn’t mean that you have no impact on their satisfaction, it just means that you have to work really hard to understand your impact.
The key thing to understand from all this is that all the different parts of an organization need to collaborate to ensure they delight their customers. If all the teams in the organization treat each other as suppliers and customers then they may manage to cooperate, but this just isn’t enough. Everyone must collaborate to achieve a common goal of delighting the paying customers. That way the business will grow and everyone will succeed.
Continue reading

ITSM Basics: Change Impact Assessment – Part 2

Posted by on February 16, 2016 in ITIL
ITSM change management   In part 1 of this blog, I focused on what to look, and ask, for when assessing a change. Here, in part 2, I go further, and beyond the impact assessment, to look at minimizing the potential for adverse IT and business impact from poorly planned or executed changes. You could argue that the title of my blog is now inappropriate but, in my opinion, it’s good to talk about change impact and the potential risks rather than change management per se. You could argue that this blog also dips its toes into release management too. But, if you have time to argue about blog titles, you probably need to find a more engaging job.

Don’t Skimp on Change and Release Planning

Sadly, it’s not just a case of hitting a big red button and cackling “fly my pretties, fly.” A good plan clearly sets out who does what, where, and at what time. Sounds simple but I’ve lost count of the amount of time I’ve had to spend rounding up engineers that were distracted mid-change or just weren’t aware of what they should be doing… “Oh right, that was today wasn’t it?” Sometimes it’s like herding cats. So make sure that you’ve got any handover periods highlighted and primary and secondary contact details for everyone involved. Mobile signals can drop and Exchange servers can glitch, so make sure the people involved are contactable at key times.

Post-Implementation Testing Can Make a Big Difference

How do we know the change was successful? “Okay people, we’ve deployed the change and nothing looks hideously wrong. Back away quietly and don’t make any sudden movements.” Does it sound vaguely familiar? It’s important to run a few tests. To have a few simple tasks to ensure that not only has the change been deployed but that all relevant services are up – with everything as it should be. “Trust but verify” is the name of the game here. You don’t have to “rock the world” but simple things like making sure that all the shared drives/folders are available on a WinTel server, or that system traffic is running correctly over your network, are simple things that can make the world of difference to your customers and end users, and to ongoing business operations.

Don’t Forget the Back-Out Plan

With the best will in the world, even if you’ve done everything right before the change, something unexpected could still pop up. Hardware failures, power spikes, and code glitches all can, and do, happen – so you need to have a robust plan in case something goes wrong during the implementation window. So consider how you’ll deal with something unforeseen. Can you roll back, fix on fail, or do something else? There’s no right answer here, just make sure that if something does go wrong, then you have a plan to restore service – with the appropriate timings built into the change window. Also ensure that the team of people implementing your change are empowered to make decisions and if there are points during the change window that we know pose particular risks, schedule a quick call with involved parties to discuss them.

Other Environments Matter Too

Which environment are we applying the change to? Don’t give me that look. I know that we’re overrun with changes to our production environments, but other environments such as pre-production or DR (disaster recovery) are important too. Why should you be worried about DR environments? A friend of mine onceworked for a large investment bank in the city. And during a code change to one of the bank’s most business-critical systems – the market data feed to the trade floors – things were taking a little longer than expected. So, ignoring what was written in the change plan, the decision was made to only update the production environment. It was always the plan for the implementation team to go back to update the DR environment but, as tends to happen in the busy land of IT, they got distracted by other operational priorities and it was never done. Fast-forward six weeks and a crisis hit the trading floor. The call is made to invoke DR but they couldn’t because the market data services were out of sync. Cue a hugely stressful two hours where the whole IT organization desperately scrambled to find a fix. The business impact here was estimated at over US$8 million – not a mistake that any IT professional wants to be held responsible for. Well, not if they want to stay employed. By asking the right questions (and using templates or change models to make raising changes less painful), not only do you mitigate adverse business risk, if something does go wrong, but you can support incident management activity in fixing things as quickly as possible. You can also support problem management in identifying or confirming the root cause before raising the appropriate actions to ensure the similar future changes don’t fail. You’re never going to be able to achieve “bulletproof” change management but using the list in the first blog, and covering the points made in this one, it will help to ensure that you are at least consistent – which will go a long way to reducing risk and the potential for any disruptions in business operations. What are your top tips for change impact assessment? Image credit
Continue reading

ITSM Basics: Change Impact Assessment – Part 1

Posted by on February 9, 2016 in ITIL
ITSM change impact assessment One of the things that worries me most about where the IT industry is headed is how we sometimes get so caught up in “the new stuff” that we forget to make sure that we have all the basics covered.  A good example is change management, which can be easily overlooked while we’re looking at, and then researching, the newest and shiniest trends, and technologies, in the world of IT and IT service management (ITSM). Unfortunately IT change doesn’t happen in isolation. In fact, these days it’s common for IT change to be business change – and it can impact the whole organization around it, and all the people touched by it. Consequently, changes that are inadequately assessed, managed, and reviewed can have a significantly harmful impact on both IT and business operations. In my opinion, not taking change seriously is akin to playing business-continuity Russian roulette.
Of course change will always involve a certain level of risk, but taking the time to properly assess the impact of a change can make things significantly less risky for everyone involved. Ultimately, it doesn’t matter how brilliant your service desk is, or how talented your tech support people are, if you get changes right the first time, you’ll break less things, generate less incidents, and have happier end users. It’s a win, win, win situation!

What to Look for When Assessing a Change

I’ve seen some pretty poor excuses for change requests in my time. Some have been so bad that they’ve resulted in me going to the requesters to find out what I’ve done to make them hate me. Remember though that some of your colleagues will request changes very infrequently and so, to save them time and energy, and yourself from head-butting the wall, it’s worth having a check list of everything you need to adequately consider a request for change:
  • Change title. Is the title clear and does it make sense? It’s not rocket science but when you’re working through lots of changes, possibly with your change advisory board (CAB), you might need to instantly be able to tell what something is and what it’s trying to achieve.
  • Change description. Is the description easy to understand and is it written in clear business language, or at least in something that you can easily translate to the rest of the organization when seeking customer approval? The last thing you want is to have to come away and ask more questions of the requester. You want the business to have faith in you knowing what you’re doing and, if you can’t explain what you’re trying to achieve to them, you might as well just tell them that you don’t have a clue.
  • Change reason. Why do we need to do this change? It sounds obvious, but once I had a change request appear in my queue where the server support analyst wanted to move a business-critical server, which hosted the transactional part of the corporate website, from a secure data center to under his desk because, and I quote, “My legs are getting tired walking to and from the server room.”  I hope you’ll agree that this wasn’t an acceptable reason for a change. So to be better at change assessment, we don’t just want to know why we want to do a change, we also need to know how it will benefit the business.
  • The systems/services/groups/users affected by the change. In order to let your stakeholders know that they won’t be able to access something, or if there is a risk-involving change proposed, you need to know whose IT and business services and operations will be affected by a change request. Ideally, this information will be driven by your CMDB, as this should give you the most up-to-date and trustworthy information. If you’re unable to use your CMDB for this task, it’s still vitally important to have this impact information available to identify and inform interested parties. You can do this manually using a spreadsheet or you might be able to pull it from your service catalog. The important thing is that you do it.
  • Risk assessment. What happens if it all goes wrong? In my experience, too many people choose “medium risk” when requesting a change because they either don’t know, or don’t care, what the risk actually is. There really is no excuse for this and I suggest using a change management risk matrix in your organization, like the one on page 17 in this change management process guide, so that change requesters can select a tangible, meaningful level of risk that’s appropriate for the work being carried out. This also gives the change assessor(s) added peace of mind that the risk category hasn’t been chosen at random.
Well, that’s it for Part 1. I’ll return with Part 2 to cover implementation planning, post-implementation testing, back-out plans, and more. In the meantime I’d love to hear any change assessment advice you can share. Image credit
Continue reading

Why ITSM OpEx Efficiencies = IT Efficiencies

Posted by on February 4, 2016 in ITSM
ITSM OpEx Efficiencies Equals IT Efficiencies In preparing for this blog I interviewed a global support manager at an international agribusiness corporation where SysAid was enabling increased end-user responsiveness, improved asset and change management, and enhanced OpEx efficiencies overall. As it turned out, this very strong narrative aligned very well with EMA research data on how IT service management (ITSM) operational efficiencies are impacting IT OpEx effectiveness overall. Looking at this bigger picture, the role of ITSM teams is growing, not shrinking in importance. ITSM is increasingly providing a source of governance and efficiency in supporting all of IT in incident and problem management, release management (including agile and DevOps), change management, and asset management. In many cases ITSM teams are also leading the charge in supporting mobile requirements both for IT service consumers and IT professionals for improved efficiencies. So given all these trends, which I’ll examine in a little more depth in this blog, I think it’s safe to say that ITSM operational efficiencies reside at the very center of improving IT efficiencies overall.
Before going any further, I should mention that the data points I’m referring to in this blog are taken from three different research projects: one on digital and IT transformation; one on ITSM futures, and one on next-generation asset management. Let’s start with the growing role of ITSM teams in supporting IT more broadly. Workflow and scheduling are part of the reason why ITSM integrations reach out to support operations and other IT groups. This is especially true as workflows evolve into runbook requirements for operations and release management processes for application developers. For instance, our data also shows that improved operations-to-service desk integrations for incident and problem management is a number one ITSM strategic priority going forward. These integrations may feature workflow, shared analytics, leveraging configuration management database insights into service interdependencies, and combining trouble ticket data and user interaction with operational data on service performance—just as a few examples. Improved operations integration with ITSM configuration management capabilities for change and configuration management comes in at second place. But perhaps the most surprising piece of news is that 80% of ITSM teams in our research either already had support for DevOps or planned to—through workflow or scheduling or even through provisioning via CMDBs and configuration management tools. In all of the areas mentioned here, ITSM efficiencies directly impact the efficiency of IT overall. Another key area for ITSM is integrated support for asset management. Hardware and software asset management often become sinkholes of inefficiency in IT organizations. Here are just two key data points:
  • IT organizations spend an average of ten hours a week reconciling data accuracy issues for asset inventory.
  • IT organizations spend an average of more than 30 hours preparing for audits for compliance-related reasons (and 8% spent more than 100 hours).
Talk about OpEx efficiencies—this area is clearly a sweet spot for improvement that good ITSM /ITAM investments can help to rectify! Now let’s talk about mobile. Mobile is changing the game for IT, and once again ITSM efficiencies stand in the forefront of making mobile access an effective reality. 78% of our ITSM respondents indicated that mobile support for IT service consumers either meaningfully, or dramatically, improved outcomes in terms of both IT efficiencies and end-user productivity. In another question, mobile showed strongly in both enabling improved responsiveness to IT service consumers and increasing IT efficiencies overall while reducing OpEx costs. By now hopefully you can see the connection—whether through integrated workflow, project management, incident, problem or change management, ITAM and mobile support—ITSM operational efficiencies really do equal IT efficiencies overall. But how important are IT and ITSM efficiencies in the larger scheme of things? Insight on IT and ITSM efficiencies was the number one analytic priority for digital and IT transformation in our research. And when it came to business metrics, IT OpEx efficiencies were at the very top. To explore one case study of an effective ITSM team who are providing the backbone to global business growth, please take a look at my Q&A here. This case looks at some of the key factors that enable greater IT efficiencies, including the adoption of a scalable ITSM solution that is simple to use and easy to deploy. Image credit
Continue reading

Pink16: So Little Time, So Much to Learn

Posted by on February 2, 2016 in ITSM
  Pink ITSM conference It’s that time again, for one of IT service management’s (ITSM) “grand slam” industry conferences – Pink Elephant’s Pink16, now in its 20th year at the swanky Bellagio Hotel in Las Vegas. But sadly not for me, instead I’ll be watching the conference from afar this year (via Twitter). It doesn’t stop me dreaming of the sessions I’d attend though, and I’ll be recommending these to my colleague Ami Shimkin and anyone else willing to listen. The theme of this year's conference is “IT @ The Speed of Change” – with Pink Elephant stating that IT teams now “need to be quick, lean, innovative, proactive, timely and effective.” As per usual, there’s a wide range of content, some would say too much content, crammed into three days across the following session types and tracks:
  • Keynotes
  • “Power hour”
  • Pre-conference optimizers
  • IT leadership
  • IT strategic management
  • Lean IT and Agile
  • Service support and operations
  • “How to” ITIL clinics and workshops
  • DevOps
  • Organizational change management
  • Pink Think Tank
  • Tools and technology
  • Cyber risk and security management
  • Ask the expert breakfast club
  • Half-day workshops
So much content that it really is an excuse for human cloning. Alternatively, you just have to realize that you can’t see all the sessions you want to, pray for minimal session clashes, and selectively pick what you imagine to be the best use of your limited time. But I’m happy to help, with the following suggested sessions. And please excuse the odd early-bird session – I selected what I deem to be the most promising sessions no matter when they are.

Pink16 Must-See Sessions (Well, According to Me)

07:15 Monday, February 15: “The IT Renaissance” with Rob England, The IT Skeptic (Track 2: IT Strategic Management)
Rob will talk to how the world of IT is changing – from the drivers to the effects on corporate IT. Listening to Rob speak about anything IT and ITSM is a no-brainer, so to hear him talk about how so much is changing from employee expectations through to the technology itself is definitely a must-see session for me.
10:30 Monday, February 15: “Pink Think Tank Summary – What They Really Talked About Behind Closed Doors” with Rob England, The IT Skeptic (Track 8: Pink Think Tank)
Sorry to recommend two Rob sessions in a row, I can only blame the schedulers and the fact that Rob is doing so many sessions at Pink16. This session provides feedback from the collected conversations and noodling of a number of ITSM “big thinkers.” It clashes with Earl’s presentation below, so you could always flip a coin as to which of the two you attend. And, if like previous years, Rob will most likely produce a white paper on the Pink Think Tank outcomes.
10:30 Monday, February 15: “Don’t Rain On My ITSM Parade – Transitional Change Management When Moving to the Cloud” with Earl Begley, Total Quality Manager, Analytics & Technologies, University of Kentucky (Track 9: Tools & Technology)
Earl is a well-respected ITSM practitioner and we have to take advantage of good practitioner advice whenever we can as it’s not as common as I’d like it to be. In this session, Earl shares the lessons learned from a higher-education IT department’s journey from a risk prone, on-premise data center to an Infrastructure-as-a-Service (IaaS) model.
14:00 Monday, February 15: “Why Governance of Enterprise IT (GEIT) Is Not a 4 Letter Word!” with Robert E. Stroud, Forrester Analyst and ISACA International President 2014/15 (Track 2: IT Strategic Management)
Rob is a seasoned presenter from his days in a senior ITSM role at CA Technologies, plus his international itSMF and ISACA positions. Now a principal consultant at Forrester Research, I’m sure Rob will deliver an insightful overview of where IT organizations need to be from a governance perspective in the light of the rapidly changing IT and business landscapes.
07:15 Tuesday, February 16: “Helping Managers Enhance Skills & Services With ITIL Practitioner” with Kaimar Karu, Head of ITSM, AXELOS Global Best Practice (Track 9: Tools & Technology)
Kaimar will discuss the current skills gap in the IT industry and the impact it has on the way we deliver services. He’ll be using the new “ITIL Practitioner” syllabus to outline how individuals and teams can improve, with an emphasis on communication, change, and continual service improvement.
10:30 Tuesday, February 16: “Bimodal IT: Shortcut to Innovation or Path to Dysfunction?” with Damon Edwards, Managing Partner, DTO Solutions
He’s a well-known DevOps figure, so I’d bet that Damon’s bimodal IT session will be of great value to those wanting to hear more about the future of IT management and ITSM. If you can’t make this one, then look out for Damon’s second session later on the same day, at 14:00, called “The History Of DevOps (& What You Need To Do About It)” (Track 6: DevOps).
14:00 Tuesday February 16: “The CMDB in a Cloudy & BYOD Universe” with Carlos Casanova, President  & Solutions Architect, K2 Solutions (Track 9: Tools & Technology)
Sadly, Carlos’s session clashes with Damon’s second so it’s another flip a coin time. Carlos is co-responsible for what must be the biggest-selling CMDB book ever, along with Forrester analyst Glenn O’Donnell, and it’s great to see him talking CMDB in a world where cloud and BYOD make configuration management even more complicated, yet even more important.

But That’s Not All…

So that’s just some of my recommendations for the session tracks. I’m sure the keynote sessions will be great too. The one by Tom Koulopoulos, chairman and founder of Delphi Group, in particular looks very interesting. Plus, there are the final-day afternoon workshops of which I’d personally opt to attend Paul Wilkinson’s of GamingWorks – his sessions are always funny and informative. Then finally, and I’m not just saying this because I work for an ITSM tool vendor, make good use of the expo hall time. Not just to grab freebies and to win prizes, but to also speak to vendors about ITSM best practices and the new challenges they are seeing with customer ITSM activities. It’s a great place to learn too, if you ask the right questions. Read this blog about getting the most out of ITSM conference expos for more on this. We would love to have you as our guest at the SysAid booth, so please pop by for a chat about ITSM best practice and the ITSM community as a whole. You can find out who will be attending from SysAid on our event page for Pink16. If you’ve chatted with us at an industry event before, then you will know that while we are there to demo SysAid (especially our new reporting and BI capabilities!), we are also there to spend time talking with IT professionals about the challenges and opportunities they face. And you’d also know that we have the best swag at every event! So please come by to say “hello” at Pink16. Joe the IT Guy loves all the attention.
Continue reading

How You Can and Should Manage Availability of IT Services

Posted by on January 26, 2016 in ITIL
Manage Availability of IT Services In my recent blog 5 New Year’s Resolutions for ITSM Practitioners, I recommended that people should think about how they manage availability. I was surprised by the number of people who contacted me to say that they thought I had got this one wrong since availability management isn’t that important. I don’t think I got it wrong and this blog explains why. Well-run IT services make a huge contribution to a customer’s business, and this means that when those services aren’t available, the negative impact can be huge too. If we don’t plan to deliver the right level of availability, we’re just relying on luck, and, as we all know, hoping for the best isn’t a viable management strategy. Availability management activities can be broken up into three distinct areas:
  • Understanding and negotiating customer requirements
  • Designing services so they are able to deliver the required availability
  • Ongoing management to ensure agreed targets are met or exceeded

Understanding and Negotiating Customer Requirements

How available does a critical IT service need to be? How often have you worked with customers where there are no clear availability requirements beyond “It must be available all the time” or “We want 100% availability”? The biggest problem with this kind of target is that it gives you no guidance on how to design the service and its recovery mechanisms. You should never agree to targets like these. You will fail. Maybe not this week or this month, but eventually there will be some downtime. What’s more, you will not have the tools and the knowledge you need to manage that downtime effectively. One IT organization that I worked with designed a shiny new service that included clustered servers, RAID disks, dual network paths, and many similar technologies. The solution was designed so that routine hardware failure would have caused the service to stall for 20 to 40 seconds. Not bad, you might think. Nobody could possibly notice such a short interruption of service. Sadly, the availability target was poorly defined. When I elicited the customer‘s actual requirements, it turned out that they needed the solution to recover within 250mS (that’s a quarter of a second) whenever any component failed. A longer recovery time than this would have had a huge business impact. A major business project had to be put on hold for a year so that a new IT service design could be created! You must define availability requirements based on a thorough understanding of how the IT service supports the customer’s business processes, and what the impact of failure will be over different time periods.

Designing Services so that They Are Able to Deliver the Required Availability

When you design services to deliver the level of availability your customer needs, regardless of the technology you choose, you need to consider two things: reducing the frequency of failure and reducing the time taken to recover after failure. Failure happens less often when you use reliable infrastructure, with simple well-understood components. Ideally you should standardize on a small number of infrastructure components that you know well; this can help to reduce the chance of unexpected interactions. You should also use fully tested well-designed software, reusing existing software components wherever possible, rather than starting every project from scratch. The modern trend towards use of containers facilitates this, as new solutions are largely built from existing containers that are already well tested and well understood. Reducing time to recover is probably the most important aspect of availability design. If you think through all the different ways that IT services could fail, and plan how you would recover from each of them, then you can make a huge difference to availability. The concept of anti-fragile takes this to another level by accepting that failure cannot be prevented and designing services that can rapidly recover from almost any failure.

Ongoing Management to Ensure Agreed Targets Are Met or Exceeded

It isn’t enough to make sure that you include availability management when you first design and deploy services. You have to manage the availability of those services on an ongoing basis to ensure that agreed levels of availability are met. Here are three activities that need to be performed:

Testing Countermeasures to Ensure that They Will Work When Needed

Failover and recovery measures that you have invested in may not work when you need them if you don’t test them at regular intervals. I have reviewed many different IT services, to help identify risks.  In nearly every review I have discovered countermeasures that would not have worked when they were needed. Sometimes this was for technical reasons, but often it was simply because people did not know the exact steps they were supposed to follow after a failure. A regular schedule of testing verifies that everyone knows exactly what to do. So make sure the testing covers all of your recovery mechanisms, not just failover but also restoring backups, invocation of service continuity plans, and anything else that might be needed. Organizations that use the anti-fragile approach may actually inject random failures on a regular basis to make absolutely sure that the recovery mechanisms work correctly.

Measuring and Reporting Availability

It can be very difficult to measure and report the availability of an IT service in terms that are meaningful to customers. If one user has a faulty laptop, then the service may not be available to that user at a critical time, and this could be just as significant as a failure of a server or a critical application. Similarly, if just one transaction fails, this may be of low significance, or it could have a major impact on the business. Your measurement and reporting should reflect the customers’ experience of availability, not just data about technology components. This measurement and reporting must include the entire end-to-end IT service, not just the application or the server.

Intervening to Ensure that Availability Targets Are Met

Simply producing a report each month that shows when you missed the agreed targets is of very little benefit. Measuring and reporting availability is of most value when it helps you ensure that you meet your targets. If you monitor availability trends, you can identify IT services that might be in danger of breaching their targets in the future. This will give you time to identify improvements you can make to ensure you do meet the targets. You can also set warning thresholds so that you are aware of services that might breach their targets during the current measurement period. Then you can take measures to ensure targets are not breached. For example, one of my customers has a process that detects any service that has exceeded 50% of its allowed downtime during a quarter. They then take the following actions to ensure the target is met:
  • Put in place a change freeze until the end of the quarter
  • Ask a senior support person to review recent downtime to look for issues that might repeat
  • Set a flag on the service desk to raise the priority of any incidents
This active intervention has enabled them to reliably meet their availability targets for many years.

Summary

If you just monitor and report availability, then sometimes you will have to tell your customers that you failed. Alternatively, you could implement some of the ideas in this blog to actively manage the availability of your IT services, and ensure that you reliably meet your customers’ expectations.  Which do you think is better? Why not start now by discussing the ideas I bring up here with your IT team and thinking about which you can adopt straight away? Image credit
Continue reading

ITSM and Business Intelligence: Why Do We Continue To Ignore Our Wealth of ITSM Data?

Posted by on January 19, 2016 in General IT
brain.jpg I’ve written about IT service management (ITSM) and the opportunities of business intelligence (BI) before, but that was four years ago, as an industry analyst. Since then, I’ve seen very few vendors shouting about the fact that they have upped their reporting, and potentially BI, game. It’s really odd, especially when you consider how the ITSM marketplace has embraced the Nexus of Forces, a concept (developed by global research and analysis firm Gartner) that describes “the convergence and mutual reinforcement of social, mobility, cloud and information patterns that drive new business scenarios.” So while the ITSM world has dipped its toes into the first three of these forces (social, mobility, and cloud) with varying degrees of success, the latter (information patterns) continues to be largely overlooked. Why do we continue to waste the BI opportunity that sits atop our wealth of ITSM data?

So What about Information and BI for ITSM?

ITSM solutions house a great deal of IT-related data. Whether it be in a configuration management database/system (CMDB/CMS), a service catalog, or within the more-transactional records for incidents, service requests, problems, and changes. But how many IT organizations are using this data to better understand their past and to influence their present and future? We might look for incident trends for problem management purposes. And we often have a death-by-metrics approach to performance reporting, where it can take someone a week to pull together a monthly reporting pack that gets very little attention or reads. But beyond the number of incidents handled and level of first contact resolution, what could the wealth of ITSM data be telling the IT organization and business colleagues about the past and the future?

So What’s Stopping the ITSM Data Opportunity?

I’d like to think that few would argue with the saying that “good decisions are guided by good data” or the logic that great businesses are built on good decisions. So why aren’t IT professionals using all their ITSM data for greater insight and better decision making? Maybe all the hype around “Big Data” has made people think that the ITSM data set isn’t big enough to pay attention to? Or maybe the cobbler’s children principle applies with IT folk, who are too busy dealing with other business information needs, resulting in no time to deal with its own needs? Maybe it’s because we are not numbers people in IT? If the numbers have $ or £ signs in front of them then I could believe this, but when we are talking volumes and percentages, I think not. Pardon my stereotyping, but I can’t think of many other corporate groups that are as excited by the quoting of statistics as IT professionals. Is it because we don’t see the need for planning and improvements? For most businesses, the IT and cloud-service infrastructure, and annual IT budget, are now so large (and potentially still growing) that the failure to plan and to continually seek out improvements in efficiency and quality of service is not an option. It happens, it has to happen, although one could question how much better it could be with more and better data or information to fuel decision making. Finally, is it because ITSM solutions don’t give as much insight into the data they hold as they could? I think we are getting warmer. It’s a common complaint from ITSM tool customers – with the native reporting capabilities often seen as difficult to use, ineffective, or both.

The Case for Business Intelligence in ITSM

Many IT organizations will already be leveraging ITSM data to some degree; I’ve already mentioned incident trend analysis and performance reporting. But what could be achieved through easier, and more insightful, access to the data trapped within an ITSM solution? I’d like to think that we are only limited by the available technology and the power of our imagination. And perhaps the courage to dig into the data not knowing what we will find. So consider being able to benefit from the following capabilities:
  • Understanding how the IT ecosystem works in reality to identify which service level targets can’t be (consistently) met, or conversely those that can never fail and are as such pretty useless as targets.
  • Demonstrating how upping or lowering service levels will increase or decrease IT costs versus the change in business performance. It could be an easy way to reduce IT costs with a minimal impact on business operations.
  • Using “predictive analytics” to understand the likelihood of future outcomes based on historical data.
  • Using ITSM data from various tool modules to create a real-world service taxonomy. This could be as part of a larger service portfolio management initiative.
  • Correlating service desk contact methods to issue type to understand how best to encourage and increase self-service adoption.
  • Improving service desk efficiency and effectiveness. It could be as simple as refining the incident classification hierarchy or as complex as understanding “flow” across a number of common service desk scenarios.
  • Improving the IT knowledge base and self-help facility, and consequently reducing service desk workload.
Then there are opportunities around other ITSM needs and activities such as more accurate availability and capacity management decisions, reducing change risk, improving governance, reducing financial “wastage,” and improving customer satisfaction.  And I’m only just scratching the surface in this blog. I’m sure that there are many more opportunities that can present themselves when greater access to ITSM data is made available. What would you like to be able to do? Image credit
Continue reading
Subscribe
Watch & learn from industry experts about ITSM and help desk hot topics!