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.

FUSION14: Bringing the ITSM Community Together for the Greater Good

Posted by on October 14, 2014 in ITSM
Our first visit to ITSM Fusion In the words of Peter, Paul, and Mary (or, if you prefer, John Denver), "All my bags are packed, I'm ready to go …" for SysAid's first visit to FUSION – an annual IT service management (ITSM) conference for ITSM professionals and IT leaders, brought to the ITSM Community by:
  • itSMF USA – a member-driven organization, and the United States chapter of the itSMF international organization, organized into local interest groups (LIGs) and special interest groups (SIGs) located in over 43 major metropolitan areas; and
  • HDI – a professional association and certification body for the technical service and support industry, serving a community of more than 120,000 technical service and support professionals.
We’re pretty excited about being there, meeting friends old and new, and learning more about ITSM in the conference track sessions on the 20-22 October 2014.

Socially Yours

If you can’t make it, but still want to hear what’s happening, you can follow the Twitter stream using #smfusion14 or follow the accounts of people I know will be tweeting there (some of them way too much): And hopefully many more people. Sadly there will be no Patrick Bolger there this year though. Even though he works for a competitor, we still love him.

Content Is King

FUSION is renowned for the breadth of its session content. This year is no exception with the nine tracks covering:
  • The Beginner’s View
  • Continual Service Improvement
  • Emerging Technologies
  • The Expert Focus
  • Industry Insights
  • IT Governance and Security
  • The People Factor
  • Service Support and Operations
  • The Strategic View
With so much content it’s hard to choose which sessions to attend, but here are a few I’m looking forward to.

Sophie's Choice

In no particular order other than date and time, I’m hoping to attend the following sessions amongst others: Monday, October 20 | 10:15am-11:15am SESSION 106: HOW TO ESTABLISH YOUR ENTERPRISE GENIUS BAR Speaker:  Jarod Greene (Gartner) Which unfortunately clashes with: SESSION 108: SUPPORT CENTER 2.0: LEADING THE CHARGE FORWARD Speakers:  Roy Atkinson (HDI), Cinda Daly (Focus Events), Jenny Rains (HDI) So I’m looking into cloning technologies. Monday, October 20 | 11:30am-12:30pm SESSION 202: PROBLEM MANAGEMENT: MAKING IT WORK FOR YOUR ORGANIZATION Speaker:  John Custy (JPC GROUP) Which clashes with: SESSION 209: COBIT AND ITIL SELF-ASSESSMENTS: ARE THEY FOR ME? Speaker:  Dr. Mauricio Corona (BP Gurus) Monday, October 20 | 03:00pm-04:00pm SESSION 304: EXPERT FOCUS: CONTROL SHIFT: HOW TO TALK TO YOUR CUSTOMERS ABOUT MANAGING SERVICES Speaker:  Hank Marquis (Global Knowledge) Tuesday, October 21 | 10:00am-11:00am SESSION 406: BREAKING DOWN THE BARRIERS BETWEEN LEVELS OF SUPPORT Speaker:  Rae Ann Bruno (Business Solutions Training Inc.) Tuesday, October 21 | 11:15am-12:15pm SESSION 505: TAKING THE MYSTERY OUT OF THE INTERNET OF THINGS Speaker:  Robert Stroud (CA Technologies) Which clashes with: SESSION 506: UPGRADING TO THE SERVICE DESK 2.0 Speaker:  Aale Roos (Pohjoisviitta Oy) Tuesday, October 21 | 02:45pm-03:45pm SESSION 601: ITSM NEXT Speaker:  Matthew Hooper (ISM) This one clashes with a number of other great sessions from industry luminaries Ian Clayton, David Cannon, and Jayne Groll in particular. Wednesday, October 22 | 10:15am-11:15am SESSION 803: CRASH AND BURN: HOW TO SCREW UP ITSM AND STILL CREATE AN ITSM FLIGHT PLAN Speakers:  Adrienne DuBrul (AC Group International), Chris Jaquay-Williams (AC Group International) So I’ve some tough decisions to make before the sessions start.

All Hail the Chief

Finally, Charles Araujo will be stepping into the itSMF USA President role at FUSION. We, especially Joe The IT Guy, would like to wish him all the best for the forthcoming year. We may have a special surprise to follow… If you are thinking about attending, more details can be found here. If you are attending, please search us out – we’ll be hanging with Joe The IT Guy and we love to talk ITSM, IT service delivery, and IT support.

Like this article? You may also like: IT Service Management at LEADit - It's as Easy as ABC.

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

BYOD: Will IT Departments Live Long and Prosper?

Posted by on October 7, 2014 in BYOD
BYOD: Will IT departments live long and prosper? Last week at Interop, New York’s Javits Center was abuzz with IT professionals seeking practical advice on IT management good practices (and the technology to support them). The conference element included the following tracks:
  • Applications
  • Business of IT
  • Cloud Connect Summit
  • Collaboration
  • Infrastructure
  • Mobility
  • Risk Management & Security
  • Software-Defined Networking (SDN)
This BYOD* and mobility-related blog is the first of a number of SysAid blogs based on the Interop sessions – with the intention of spreading the Interop advice and good practice wider than its physical attendees.

BYOD and Star Trek

Michele Chubirka, a security architect and best practice researcher, presented on “BYOD: Beating IT’s Kobayashi Maru.” For those of you not up on their Star Trek folklore, Kobayashi Maru refers to a no-win situation, or the need to redefine the problem. In this case, that in Michele’s opinion: “The answer to BYOD cannot be, “No,” but a qualified “Yes, and….”” The point is that BYOD is not something that can be prevented, bar situations where industry legislation or regulations limit the use of certain technology – corporate or otherwise – in the workplace. And, instead of fighting BYOD, corporate IT organizations should be looking to ensure that they are ready for, and accommodating to, BYOD – and both protecting business assets and operations, and optimizing employee productivity.

BYOD Needs Policies and Standards

Michele stated that organizations need to have the following in place for BYOD:
  • High-level BYOD policy
  • Acceptable use policy (AUP)
  • End-user agreement (EUA)
  • Data classification and handling standards
  • Basic user roles/classification
  • Supported application list
  • Resource matrix
And that organizations don’t need to reinvent the wheel here. Instead they should use Google to find existing examples of the above, which can be tailored to suit their own needs. For example, the White House’s BYOD guidance for government, or SANS’s AUP.

Guidance on Access Control

Michele also offered the following security-flavored advice, that:
  • Data has value and should be organized according to:
    • Sensitivity to loss
    • Disclosure
    • Unavailability
  • Appropriate application of controls creates the handling standards
  • User roles or personas determine privilege levels
  • Access controls are determined by the intersection of data classification with user classification
But it’s not just about security.

Employee Support Needs to Be Well Thought Out

No IT support organization could realistically support every BYOD device, personally-acquired application, or personally-chosen use case. So organizations need to be very clear on what they will and will not support. Michele's three key support points were that:
  • Even though you don’t own the device, what applications will you license and/or support on it?
  • How will you communicate this?
  • Many support costs don’t go away, they simply shift
She also pointed out that a resource matrix should be used, based on data classification and the level of risk the organization will accept, to document which applications and facilities are approved, provided, and supported for corporately owned devices, employee BYOD devices, and office guests.

Common BYOD Misconceptions

Michele finished with a short list of BYOD misconceptions:
  • BYOD is less secure
  • I can say "no" to BYOD
  • BYOD will always save money
  • I have to buy expensive solutions
  • I have to reimburse users to force adoption
  • We don’t need to consult HR or Legal

Key Takeaways

And some key takeaways for the audience (and now you):
  • Controls should focus on data/resources, not technology
  • Policies become requirements, don’t jump to solutions; you will pay for it later if you skip this step
  • Get executive buy-in on policies and sign-off on design, otherwise you’ll be redesigning later
  • Training and end-user support is critical
  • Offer options: full device management vs. containerization**
  • BYOD is no longer optional
So there’s a lot to consider from a BYOD management and service delivery perspective. But, importantly for us at SysAid, one has to remember that mobility isn’t really about mobile devices and apps. Rather, it’s really about supporting employees and customers while they are on the go – it’s about service delivery and service experience, and the pursuit of business over IT outcomes. If you want to hear more from Michele Chubirka you can find her on Twitter as @MrsYisWhy. * BYOD = bring your own device, the use of personally owned devices in the workplace ** And not forgetting mobile virtualization options such as Nubo. Image credit

Like this article? You may also like: Nubo - World's First Remote Android BYOD Launches.

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

Interop: a First-Timer’s View

Posted by on October 2, 2014 in General IT
Interop: a non ITSM event Well, SysAid’s and my first day at Interop New York was a busy one. As Joe the IT Guy states in his pre-Interop blog, SysAid is the only pure-play IT service management (ITSM) vendor at the event, which meant that we had some very meaningful conversations with attendees about ITSM, service desks, IT support, and improving IT service delivery. It was a very different experience to the many ITSM events we have previously exhibited, and in a good way. But you don’t want to read about the SysAid booth traffic. And, while I was on the booth most of the day, I still managed to attend the four keynotes and a Women in IT lunch panel.

Keynote Gems

I enjoyed the four keynotes to different extents based on what I took away from them and how the presenters engaged me. I’m quite black-and-white with presentations – I’d rather listen to a poor presenter deliver great content than a great presenter with poor content. Plus, of course, the personal relevancy of the presentation makes a massive difference. The first keynote, Ben Haines of Box being interviewed by R Ray Wang, offered up a number of gems such as:
  • "The common thing across all industry verticals is the need for speed of change."
  • "We talk in weeks and months for delivering new services not years."
  • "We need to think about users at the center of everything we do now."
With R Ray Wang throwing in an insightful: "Users want IT to be simple, scalable, and sexy." In the second keynote, Steve Comstock of CBS Interactive, aimed to convince the audience that Shadow IT is an opportunity for, rather than a threat to, corporate IT departments. It was humorous and engaging, recounting Steve’s personal journey with Shadow IT over the last 15+ years and how the IT organizations he has worked in needed to change. I particularly liked the statement that: “My IT conversations with business partners used to be like awkward first dates. We couldn't converse.” I think this resonated with many in the audience. But the real piece of wisdom was:“The problem with ‘engaging with the business’ is that IT people are rarely given advice on HOW to do this successfully.” How often is this true with non-technical aspects of IT management? We are frequently pointed in the right direction (on a journey of change) but are rarely offered a map and compass to help us make the journey successfully, and as swiftly as possible. Then John Jeremiah of HP offered advice on mobility, starting with some potentially hurtful home truths for IT, that:
  • "IT organizations often have mobility initiatives because they want to do mobility not because of user needs."
  • "It shouldn't be a mobile first mantra, it should be users first."
This and more - before talking about how HP can help throughout the mobility lifecycle. The fourth and final keynote was comedian Seth Myers who sent the audience off to the Expo with smiles on their faces.

Women in IT

As I mentioned in the pre-Interop interview I had with Adrian Bridgewater on Computer Weekly, I was really looking forward to the Women in IT lunch panel. And, as evidenced by the relatively small number of women (compared to men) in the day one keynotes’ audience, such initiatives stack up against valid concerns over workplace diversity. If you pardon my potentially inappropriate humor, I usually find IT conferences to be one of the only places where it’s the men’s restroom that has the queue. Sadly though, the Women in IT lunch panel didn’t live up to my expectations. I guess I had expected, and wanted, to hear a series of tangible things that female attendees could personally leverage. Proven plans, practices, activities, or techniques that had been shown to repeatedly help women succeed in IT work environments. Instead, the panel delivered personal stories of how they had individually triumphed within their own careers that, while sometimes interesting, did not leave me with my desired list of concrete things my female colleagues and I could use to our advantage. My disappointment soon disappeared though, thanks to the ladies of Bronx Academy for Software Engineering (BASE) who came over to chat to us at the SysAid booth. I was totally blown away by their enthusiasm and passion for technology. They are the future of Women in IT. So a mixed bag for me, but that is often the case for events - in that you can’t please everyone (given our individual wants, needs, and expectations) all of the time. And I’m really looking forward to day two of the Expo. More content to follow!

Like this article? You may also like: Like a Virgin - ITSM for the Very First Time.

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

CVE-2014-6271 aka Shellshock Bash Bug

Posted by on September 28, 2014 in General IT
CVE-2014-6271 aka Shellshock Bash Bug Remember Heartbleed? Back in April, I was flooded with questions from our customers, so I wrote that blog post about it when the hype was about as big as Apple’s iPhone 6 announcement. Well, guess what? Five months later we’ve got a new vulnerability with an equally awesome name. Meet "Shellshock" - an awesome bug with the potential to be a as big as Heartbleed. Today, I wanted to put together something definitive, both for me to come to grips with the situation, and for others to separate the hype from the true underlying risk.

What Is Bash and Why Do We Need It?

Let’s start at the beginning. Bash is a *nix shell or in other words, an interpreter that allows you to orchestrate commands on Unix and Linux systems, typically by connecting over SSH. It’s been around since the late 80s where it evolved from earlier shell implementations (the name is derived from the Bourne shell) and is enormously popular. There are other shells out there for Unix variants, but the thing about Bash however is that it’s the default shell for Linux and Mac OS X, which are obviously extremely prevalent operating systems.

What Is the Vulnerability?

The flaw involves how Bash evaluates environment variables. With specifically crafted variables, a hacker could use this hole to execute shell commands. A good example could be an application calling a Bash shell command via web HTTP or a Common-Gateway Interface (CGI) in a way that allows a user to insert data using this vulnerability. The most dangerous circumstance is if your application calls scripts with super-user, aka root, permissions. In this case, your attacker could get away with "murder" on your server.

Are You Exposed?

You are probably asking yourself, "If I am not running Linux/Unix/Mac, am I exposed?" Short answer "no" and long answer "yes". I'll tackle the easy one first – Bash is not found natively on Windows and whilst there are Bash implementations for Windows, it's certainly not common and it's not going to be found on consumer PCs. It's also not clear if products like win-bash are actually vulnerable to Shellshock in the first place. The longer answer is that just because you operate in a predominantly Microsoft-centric environment doesn't mean that you don't have Bash running on machines servicing other discrete purposes within that environment.

So What Should You Do?

Firstly, discovering if you’re at risk is trivial as it’s such an easily reproducible risk. There’s a very simple test — simply run this command within your shell: env X="() { :;} ; echo busted" /bin/sh -c "echo stuff" If you get “busted” echoed back out, you’ve exploited the bug and are vulnerable. Of course the priority here is going to be patching systems. Linux distros, such as Red Hat are releasing guidance on patching the risk, so jump on that as a matter of priority!

Are You a SysAid Cloud Customer?

As always, those using SysAid Cloud services can continue sleeping quietly at night knowing we already did all the necessary patching to make sure our systems are not exposed to Shellshock. Image credit

Like this article? You may also like: CVE-2014-0160.

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

Defining Metrics for Incident Management

Posted by on September 23, 2014 in ITIL
Defining Metrics for Incident Management I have written about how to define metrics and KPIs for IT service management processes before. In Defining Metrics for Change Management I discussed the importance of identifying stakeholders, and defining CSFs and then using these to help you think about what KPIs you should measure and report. In Defining Metrics for Problem Management I continued this theme, and showed how the KPIs that you find in best practice publications like ITIL may not be suitable for your needs. In response to these earlier blogs, I received some requests for more blogs in the series, and in particular a request for guidance on metrics for incident management. So here are my thoughts on how you can define metrics for incident management…
The first question to ask is what is incident management for? What are you trying to achieve? This won’t be the same for everyone, but most organizations will want something like:
  • We resolve incidents quickly, so they don’t have a significant impact on our customers
  • We prioritize incidents appropriately, based on their impact and urgency
  • We communicate well so that customers and users understand what is happening and when they can expect their incidents to be resolved
  • Customers and users are satisfied with the way we handle their incidents
  • We recognize repeating incidents and log problems to help reduce future business impact
  • We make efficient use of our incident management resources
Ideally our KPIs should help us to understand whether we are achieving these goals, and should provide trends to help us focus on where we need to improve. So let’s think about what we could measure to help with these. Please remember that these are all just examples, based on how I think about incident management. Some KPIs will be appropriate for one organization and completely inappropriate for another. For example some organizations measure the First Call Resolution (FCR) rate. This is a measure of what percentage of calls were resolved during the initial phone call with the service desk. For many organizations this is a great way of measuring that they resolved incidents quickly and made efficient use of resources, but if you are investing in self-service tools then you may find that FCR gets worse, even though the service is improving. Here are some examples of KPIs that might help you to understand how well you are doing against the goals listed above. In each case I have indicated the metric, but not provided a target, as this will be completely dependent on your environment. You may need to collect data for a while before you can set targets for any of these metrics.
  • We resolve incidents quickly, so they don’t have a significant impact on our customers
    • Percentage of Priority 1 incidents resolved within SLA agreed target
    • Percentage of Priority 2 incidents resolved within SLA agreed target
    • Percentage of Priority 3 incidents resolved within SLA agreed target
  • We prioritize incidents appropriately, based on their impact and urgency
    • Number of incidents where the priority was changed after logging
    • Number of customer complaints or escalations due to disagreement over incident priority
  • We communicate well so that customers and users understand what is happening and when they can expect their incidents to be resolved
    • Percentage of incidents where customer contacted the service desk to ask for an update
  • Customers and users are satisfied with the way we handle their incidents
    • Percentage of users giving a score of 4 or 5 on post-incident satisfaction survey
    • Increased satisfaction with incident management on annual customer satisfaction survey
  • We recognize repeating incidents and log problems to help reduce future business impact
    • Number of problems logged by the service desk
    • Number of problems identified by analysis of incident data
  • We make efficient use of our incident management resources
    • Percentage of incidents logged via self-service
    • Percentage of incidents solved by self-service
    • Average cost to resolve incident (by priority)
Remember these are all just examples. It really doesn’t take long to write down your own goals, and then to think about what you could measure to help you achieve them. What are your current incident management KPIs based on? Do they help you understand how well you are doing for your customers, or are many of them just internally focussed? Why not sit down and review them and see if you can start measuring and reporting the things that really matter to you?

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

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

ITSM: Shift Left, Left, Left…

Posted by on September 17, 2014 in Service Desk
Consider the concept of shift left in ITSM When looking at ways to improve your IT support and service desk, it’s always useful to take a look at what managed service providers (MSPs) are doing, since their entire business is based on successful and efficient service delivery – so they will always have some good ideas to consider.

The shift left concept

One of the most prevalent of these ideas over recent years has been the concept of shift left – which means moving the activity of providing resolution support as close to the front line and customer as possible. The concept is simple. By moving the capability and delivery of resolution work to the immediate front line, this reduces waiting time for customers, simplifies support activity and (important for outsourcers) reduces the actual cost of dealing with the incident. So, an incident fixed at the front line might cost $10, whereas the cost rises steeply for 2nd and 3rd level support to $100/$300, due to the increased numbers of staff involved, their costs, the cost of extended user downtime, etc. For many organizations, at a very basic level this is the prime activity that they might look at, in terms of service modeling, i.e. how they define the sort of service and service levels that are provided by their support structure. There are also often questions raised about the value of this approach, notably with the development of self-service and crowdsourcing in recent years, particularly as the models and norms of IT Support and IT service management (ITSM) are constantly being challenged. However, in general, the concept is a good and valuable one as it provides several highly desirable benefits, for both short and long-term gain, examples of which I will discuss below.

Speeding up resolution time for users, thereby improving the customer experience

We all know that if you can fix an issue on the first call this greatly improves customer satisfaction. No one likes being passed around or having to wait, then chase, then wait again. The old ‘Helpdesk’ model of ‘log and refer’ wasn’t usually supported by slick escalation processes and a culture of collaboration, so often incidents were delayed not because the IT organization couldn’t fix them, but simply because IT wasn’t organized into a service model that worked to achieve the quickest possible resolution for the customer or business. This is clearly a poor level of business support (where business performance is impacted by chaotic or incompetent IT management) and has led to a focus on pushing resolution competence and capability to the front line. The key element here is unproductive user time, not just bad experience. If customers are unable to work, this is punishing the very business that the IT organization is there to support. So, the faster the resolution time, the less productive downtime for the customer. This should be simple and obvious, however many IT people and organizations have resisted this over the years based on fear, prejudice, and ignorance – fear of losing their technical power, prejudice against ‘lower level’ technical people on service desks, and ignorance of the impact of their views and actions.

Simplifying the escalation and support processes, essentially cutting out waste and hassle

In simple terms, the whole process of escalationacceptance/rejection, updating, chasing, resolving, closing, and QA – is a painful one. So if this is reduced to a minimum, it also reduces friction between teams and reduces the time spent or wasted chasing updates, negotiating on priorities, etc. This in itself is a cost and efficiency saving but also allows re-focussing on high value work, for all concerned at different levels in the support model. Once in place, shift left removes a level of attrition, waste, and inefficiency that benefits both provider and customer alike.

Cost reduction

Basically it’s cheaper.There is a general consensus of agreement on this, since the figures have been around for some time from Gartner, for example, which show the cost of resolution increasing across 1st to 3rd levels of support in an IT organization. Of course nowadays there is also self-help and self-service, which is the ‘zero level’ and which is even cheaper that human 1st level support. So to return to the initial point, this is where MSPs can achieve value – their focus is of course on saving costs but in reality (unless this is done very poorly), using the shift left process will result in an improvement in speed of resolution, customer experience, and simplicity in operation too.

Overall shift left shows a commitment to service and customer experience – or at least it should!

It certainly provides the framework that would deliver better and faster resolution of issues and therefore reduction in downtime.

What if it’s just done only for cost saving?

Of course the customer experience may still need to be reviewed and improved, e.g. if the analysts/agents do not provide good customer care, etc. However there is still a focus with this on reducing the interruptions and inconveniences to the customer.

What are the implications of shift left? What do we need to do for success?

Traditional retained IT organizations have often struggled to come to terms with the real implications of shifting left. As mentioned above, this can be due to misplaced fears and uncertainties, as well as politics and empire building. True quality customer service and customer experience needs these barriers to be removed in order to achieve a consolidated and seamless service ‘supply chain’ and collaborative workforce.

Key pointers to removing barriers

  • Continual Service Improvement can be a strong driver; customer feedback and priority can be even stronger. There’s a need to document and prioritise key internal service improvements but also set these in the light of what customers say they want and need to do their jobs effectively. Customer feedback must be the most powerful mandate for action and this can trump any technical teams’ objections to change.
  • Knowledge management and its level of maturity in the organisation is a key factor in getting information, expertise and practical solutions documented and shared across teams.
  • It can be helpful to start setting targets for numbers of incidents that are passed over from technical teams to the front line, e.g. monthly targets. It’s also useful to have some simple pre-forms (as part of the knowledge approach) for handing these over.
The greatest challenge often is around changing the mindset that can’t allow service desk/front line teams to carry out apparently difficult/technical/high risk functions (those that need to be done by experienced people). That’s missing the point. If the business need is to get the issues resolved more quickly than can be practically done by escalation, then the model needs to change, i.e. the structure, staffing, and skills of the service desk. So they need to be trained, or re-hired. That’s the extreme end of the scale and in most cases, once the argument has been won, it’s a matter of simply delivering good knowledge management, staff training, and ongoing governance and management.

But remember, shift left doesn’t always work

Finally, shift left doesn’t work for every situation and should be considered in context of business need and priority. Some emergency/critical services simply need a log and triage approach. It should however always be considered as a valuable customer experience option and used as a de facto approach, rather than the other way round. Image credit

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

Evolution and How to Keep IT from Going Extinct

Posted by on September 9, 2014 in Cloud
ITSM Evolution and How to Keep IT from Going Extinct When I hear about Shadow IT and comments that the IT department will soon be dead, here are a few ITSM panicking thoughts I've heard so far:
  • Cloud computing is destroying the data center.
  • IT as we know it is going away.
  • Save yourself and change careers now! Perhaps an exciting job in exotic bird grooming?
Now that the panic is over, I want to reiterate what I’ve stated many times beforeIT service management (ITSM) will never go away. After all, a service can have several means to deliver value. As long as expected outcomes are being produced with little to no risk, it doesn’t matter if the technology is in a private datacenter or being hosted by Amazon. With that in mind, here’s a survival guide on how not only to survive, but what to do to excel in the new way of IT.

Survival Guide

  1. Think services: It's important for everyone in an IT group to understand that technology is nothing more than the tools used to deploy services in order to create value. Since the strategic value proposition will be the future role of IT, the next step is key to success.
  2. Map business outcomes to services: I once heard a brilliant idea from Mark Kawasaki, an ITSM practitioner at Emory University – “map business outcomes to the Configuration Management Database (CMDB)”. In other words, when you design a solution, understand how it will produce value for business processes.
  3. Build the service maps: Along with understanding expected business outcomes, service management focuses on the business getting value. The CMDB was a valiant attempt at managing technology, but its importance has been falling by the roadside as cloud computing has reduced the need to focus on technology. While a service map may include items that overlap with a CMDB, it should also expand beyond the scope of technology to include all elements, and their relationships, of a service.
  4. Stop Shadow IT: Shadow IT is similar to a warning light on a car’s dashboard - it indicates customers are finding technology solutions without the IT department. Several articles and blog posts have already been written on the topic, so to save time I’ll only state that it exists and is prevalent where customers aren’t being provided the solutions they want by IT. As a result, users are looking outside of the IT department to find their solutions.
  5. Take on Business Relationship Management (BRM): Everyone will agree it’s important for IT to understand the business, so it’s obvious why BRM made its way into ITIL 2011® as a formal process, but it may not be obvious why the understanding will be key in future IT operations. If IT is to move from being only a technology provider to being that of strategic partner, understanding market trends and business operations will help give insight as to how emerging technologies can give a business an advantage over competition.
If you noticed, I didn’t specifically list anything related to ITIL®, DevOps, or any other methods or frameworks for operations or development. The reason is that there’s no perfect way to run all IT departments. Depending on size, culture, industry, and several other factors that I may not even be aware of, each organization will have to evolve at its own pace and with the methods best fitting to maximize efficiency. The only guarantee is that technology is in a state of constant flux and IT will have to be the strategic advisor for how a business can take advantage of these changes and keep relevant in the market.

An Opportunity to Learn More

I'm not the only one that thinks ITSM is here to stay: “Service management is not only relevant, it’s more relevant than it’s ever been” - Glenn O’Donnell, Vice President and Research Director at Forrester Research. In our upcoming webinar we will be discussing with Glenn how the role of ITSM is changing. We’ll be talking about its strategic value proposition, as well as the role that cloud technology has to play in the future of ITSM. Discover what will likely become of ITIL, DevOps and Shadow IT, as the speed in which IT and business landscape further increases. Join Glenn and I on September 16th at 12pm EDT to learn how ITSM will evolve and how to keep your IT organization from becoming extinct. Register now. After the webinar, all attendees will also receive a short report with the 20 Top Tips for Addressing the Future of ITSM. Image credit

Like this article? You may also like: The Cloud Behind the Curtain - Why ITSM Matters.

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

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
Subscribe
Watch & learn from industry experts about ITSM and help desk hot topics!