Posted by Sarah Lahav
on June 27, 2017 in ITSM
There are some rumors that IT service management (ITSM)
No way – I’m here to tell you that ITSM is far from dead.
In fact, I think this is a great time for ITSM, and a great time to be an ITSM professional.
With technology such an integral part of every bit of a business, the line between business
is blurred, perhaps even non-existent. ITSM is no longer a “nice to have,” or something that only the service desk does. ITSM is the means by which IT delivers business capability. ITSM is the enabler for realizing real business value from the use of technology.
But some ITSM implementations have fallen short.
Where ITSM Has Fallen Short
ITSM was always intended to answer the following three questions:
- How do components work together to enable services?
- How do services provide business capabilities?
- How can a business best leverage its IT capabilities?
Unfortunately, in many cases, ITSM is implemented only to address the “squeaky wheels,” meaning such ITSM implementations are only operations-focused. Of course, these ITSM rollouts deliver incident management, change management, service desk, and maybe request fulfillment – all important processes to have. But then they stop at that. Services are not defined, design and strategy activities are not formalized, and continual improvement is an afterthought. The rationale for stopping is that the “squeaky wheels” in IT operations were addressed.
Some ITSM implementations fall short because they are more about processes, less about services. In the rush to implement ITSM, many organizations focus on designing and implementing processes. The notion of a “service” – the value and outcomes delivered to the business – often become secondary, or in many cases ignored.
A third area where ITSM implementations often fall short is in the area of business-IT alignment. The concept of aligning what IT does to what the business needs clearly makes a lot of sense – but it has a fatal flaw. Business-IT alignment depends upon the business inviting IT to participate in the development of business strategy. “The business” often goes along its way and only includes IT when there’s a technology need, not considering current IT capabilities and resources; or even worse, when a technology-based solution is identified – without having IT involved in identifying that solution.
The fact of the matter is that business-IT alignment
is not, and never was, the way to look at ITSM. The term ‘alignment’ implies that IT is not part of the business it serves. Business and IT convergence – the recognition that business and IT must work seamlessly – is the lens through which ITSM should be viewed.
The New Reality of ITSM
ITSM is going through an evolution. When ITSM first became popular in the late 1980s, it provided an orderly, linear approach to managing IT. But modern ITSM is reacting to a new reality. What does the new reality of ITSM look like?
||ITSM now is….
|Business and IT alignment
||Business and IT convergence
|Managing all things IT-related under one roof
||Ecosystems of components, partners, and suppliers found both internally and externally
||Business value and outcome focused
|IT project oriented
||Business initiatives enabled by IT
|One tool in the toolbox
||A robust set of capabilities and tools
Though ITSM continues to be a “people-process-technology
” approach for managing services, it is now a mix of frameworks and methodologies. While ITIL®
continues to be the defacto standard for ITSM, other frameworks and methodologies are providing ITSM professionals with tools or capabilities to do the job that IT organizations are being asked to do.
helps us visualize work and understand where our processes may be wasteful. DevOps
is delivering some of the “how” for deploying releases and reacting to changing business needs with greater nimbleness and effectiveness.
Technology, however, has made significant leaps in the past few years to help with process execution. Technologies such as the Internet of Things (IoT), robotic process automation, machine learning, and others provide the capability to realize the promises of process design like never before.
For example, using the SysAid IT Benchmark tool, we did an analysis of over 86 million service requests records from more than 10,000 IT departments in 140 countries over a six-year period. For argument’s sake, let’s assume that to process these requests manually required an hour each. We found that 17% - or nearly 15 million of those requests – could have been prevented by leveraging machine learning. What innovations could those IT departments have delivered using those 15 million hours?
You can read more about that in Oded Moshe
’s article: The potential for machine learning in ITSM
Why Is ITSM More Important than Ever?
Here are three reasons why I think ITSM is now more important than ever.
1. Business Value Contribution by IT
As technology has become more commercialized and consumerized, good ITSM can help tell the compelling story of why a business should get its technology from its IT organization. The IT value chain, enabled and supported by good ITSM, becomes a seamless fit into the business value chain.
2. Digital Transformation
It is not a question of “if” digital transformation
– it is a question of “when.” Many businesses are contemplating what digital transformation means to them. A core requirement for a business to begin digital transformation is to first have absolute clarity on its services and processes. Good ITSM provides that clarity regarding services and processes.
3. Business Agility and Responsiveness
Good ITSM supports business agility and responsiveness by promoting standardization in the form of models. And if something can be modeled – like standard requests, or password resets – it can be automated, which provides the ultimate level of responsiveness to a business.
Lead the Evolution!
So, I think now is a great time for ITSM and it’s a great time to be an ITSM professional. Technology has caught up with, and can now enable, many ITSM concepts.
Good ITSM enables the agility and responsiveness demanded by today’s business.
Good ITSM cements the convergence of business and IT by enabling business capability through the effective use of technology.
Good ITSM professionals are uniquely positioned to lead the evolution!
Posted by Rafi Rainshtein
on June 20, 2017 in Cloud
The world has been living with on-premise software for far too long now. The benefits that businesses and IT teams alike are gaining from well-managed, cloud-based services are rapidly changing the face of IT. We’re also becoming far more confident about how the costs of migrating IT service management (ITSM) software to the cloud
can be quickly recouped. This cost benefit is elevated even more so when IT departments are able to calculate the true cost of on-premise software. From the cost of physical servers, to the time spent running weekend upgrades... the list of hidden costs to the business is endless.
To help you get thinking about how these costs appear in your own IT environment, here is our arm’s length list of hidden on-premise costs:
Let’s start with a few easy ones…
So your software has to live on a physical server, which you need to buy, keep somewhere, run electricity to, and keep cool. You might even need to give it a polish from time to time.
Your data is only as good as your last backup. The costs attached to managing your own backups, storing data off site, and checking yesterday’s backups for any errors is an additional expense often not accounted for.
3. Anti-Virus Software
Keeping your anti-virus up-to-date is obviously important on all your software and servers. However, the more software you have, the more instances of anti-virus you need.
Oh the dreaded upgrades! Managing your own upgrades is one of the most time-consuming activities for IT staff. In addition to the planning, scheduling, and late nights, you also have to account for all the times it fails or breaks and doubles the workload.
Running patches is much like performing an upgrade. However, instead of doing one a month, you have to do about 25! And because they are mostly ad-hoc, managers rarely account for the time you spend doing them.
Planned or not, downtime caused by on-premise software is bad. The business always notices outages and clings on to the memories they create for way longer than you’d like them to. It also really drags down your SLAs and end-of-month metrics reports.
Okay, now here’s a few you perhaps hadn’t thought of…
How often have you calculated the amount of time you actually spent testing a new patch, release, or upgrade? Not very often, I’m sure! In reality, testing changes to internal hosted software is just something the sysadmin stays up all night doing, but never complains about!
8. When it Breaks
Many IT teams think software ‘breaking’ is just a part of normal life; you log the incident, fix the bug, and bring it back to life. However, the truth is once you’ve got rid of on-premise software, all that time you have to spend fixing it, magically disappears too.
On-premise software has SO MANY more integration parameters to consider. Tiny configuration changes on servers can totally screw with even the most basic Active Directory integration. Standardized cloud-based software is designed to integrate far more easily and tends to speed up the process significantly.
10. Risk Management
Cloud used to be looked at as a higher risk, but this is really old-fashioned thinking. Far more security breaches and data losses take place on internally hosted and on-premise servers these days. This is mostly due to the fact that IT teams are struggling more and more to keep up with the growing number of potential threats and risks.
Rarely considered until it’s too late, the ability to scale services can either cost or save a business huge amounts of time and money in the long run. Most on-premise installations are designed and built with the ‘now’ in mind, making scaling up later on very tricky indeed.
Every IT department has that server. The one that sends you an event notification every bloody Monday morning telling you it’s running out of hard disk space! Moving away from on-premise software not only solves this problem, but reduces your overall storage spend.
So here are a few boring ones, but the accountants will like them!
YAWN… did someone say software licensing? We know software licensing is probably the least sexy part of our jobs, but it’s also a very expensive thing to mess up! When dealing with on-premise, ensuring you’re compliant with software, databases, and virtual machines is a difficult and risky job, which often goes wrong.
14. Over Licensing
Another licensing cost worth mentioning (because loads of people do it) is owning more licenses than you use. Often described as shelfware
, over licensing on-premise software now accounts for around 20% (according to Gartner
) of the average business’ software licensing spend!
15. Unpredictable Budgets
Most of the points above and below are pretty hard to forecast. The estimated cost of running on-premise software is almost always under-estimated and frequently makes for bad news at the end of the financial year.
Every year the pressure for IT to keep track of its assets grows. From the number of desktops and servers, to the software and licenses you own, as businesses get bigger so does the need to be totally compliant. On-premise software just adds more and more unwanted weight and costs to the asset management and auditing process.
17. Overtime and Emergency Costs
Ever waited in the office till 3am for an urgent server part to be delivered? I have, and it sucks! Not only does this ruin your evening, but the costs attached to either compensating you for your time, calling out specialist engineers or raising high priority incidents with suppliers always comes at a high price.
Don’t worry, this list gets a bit better near the end!
18. Weekends and Evenings
Ditching on-premise software means you no longer have to spend weekends and evenings in the office or sitting in front of the computer running updates, testing, patching, and so on. Just get your software up in the cloud and spend some more time with your friends and family!
19. Continual Service Improvement
Remember that ITIL® book you have on the shelf? There is actually some really good stuff in there about improving your IT services
. Many IT teams struggle to have the time to focus on learning how to approach improvement, due to wasting time managing and fixing on-premise software.
20. Relationship Building
A huge focus for many IT teams nowadays is building better relationships with the business. Whether that be with peers in HR and finance, or all the way down to end customers. But frankly, IT teams who are weighted down with too much on-premise and legacy software, simply don’t have the time to do this.
21. It Really Does Take Up 30–40% of Your Costs
We’ve been working the numbers, talking to customers and testing it out and we’ve found that in most organizations, the cost of keeping on-premise software adds around 30–
40% to your overall IT costs vs. moving those services to the cloud!
At SysAid, we’ve invested a great deal into uncovering the difficulties brought about by keeping your ITSM software on-premise. As a result, we’ve developed a set of great cloud-based services and migration tools. We want to make moving from on-premise to the cloud
as easy and cost effective as possible.
If you’d like to discuss migration options with our team, just get in touch today
and we’ll talk you through everything from backing up your current tool set, to going live with your new cloud-based ITSM solution.
Find out more about SysAid in the Cloud.
Posted by Stuart Rance
on June 13, 2017 in Service Desk
When you work on a service desk, calls from angry users can be very hard work, not least because of the way we’re likely to feel about them. Being at the other end of an angry phone call or email, is never pleasant, and being confronted by an angry user can be very trying. What’s worse is that while managing the call is our responsibility, resolving the issues may not be. So what can you do to help a customer when they are so angry? How can you get past the anger so you can help resolve their problem? And how can you manage your own feelings?
In my years in the IT industry, I have had to deal with many angry users, and customers. Here are some of the things that I have found effective.
1. Accept that the User Is Entitled to Their Anger
The first thing you need to do is to accept that the caller is entitled to their anger. Even if you KNOW that the user is wrong, they are unlikely to be angry for no reason. So, listen to what they have to say, and try to understand why they feel angry. If you can work out what it is about the situation that has resulted in a furious user, rather than one just asking for help, you will have a much better idea of what you can do to help. For example, the user may be angry because a minor IT failure has resulted in a major business impact. If you treat this as a minor issue, then it’s not surprising that they get angry.
2. Don’t Get Defensive
This is, of course, much more easily said than done. It is very easy to get defensive, and respond angrily. But if you try to justify the situation, or to tell the caller why they are wrong, the caller is likely to get even angrier, and it will take even longer to achieve the calm you need to deal with the problem.
What you need to remember is not to take the anger personally. You are the target of this anger because you are a representative of the company. The caller is angry with the company, not with you.
Something that I have found useful in these circumstances is to remember a time when I have felt angry with a service organization. I think about what reaction I wanted from the person on the other end of the phone. I try hard to empathize with the angry user, it really could have been me on some other occasion.
3. Listen Actively
The first two points I have made are about managing your own emotional responses. But what do you actually do in this situation?
In my experience, the most important thing to do is to listen and to demonstrate that you are genuinely trying to understand. Listen patiently and give the user enough time to say what they need to. Don’t try and cut them short, but allow them to express their feelings. Don’t try to justify the situation, or to tell the user why they are wrong, simply listen to what they have to say, and listen to the emotions and feelings as well as the words. Show that you understand how they feel, as well as the technical details of what has happened. One way to do this is to repeat back what you’ve heard, and ask for confirmation that you have understood correctly – not just about the technical situation, but also about the anger and the reasons for it. Remember that it will help if you use the caller’s name when you talk to them, since people tend to respond much better when addressed by name.
Another way to demonstrate your understanding is to offer sympathy, and an apology, even if you don’t think you’re really in the wrong. BUT be careful. Make sure you’re sincere in your apology, since insincerity is likely to be recognized and resented! I know this sounds contradictory. Surely, it’s impossible to apologize sincerely if you don’t think you are in the wrong? However, if you accept that the user really is entitled to their anger,
then you should find that you can offer a sincere apology.
Let’s look at an example. Suppose a user is complaining because they have had to wait 2 hours for you to call them, but the SLA says you don’t have to call back for 4 hours. Of course, they are technically in the wrong. Nevertheless, by listening actively you will have gained a real understanding of the impact this has had on them, and this should enable you to empathize and to offer a genuine apology. It won’t hurt you to say “I am very sorry that we didn’t respond any sooner. I understand the impact this has had on you. Let me try to help put things right here.”
One piece of advice that I have found helpful is to smile while you are talking to the user. You may not notice the difference, but if you smile then it changes your voice, and the user will respond better to what you have to say.
4. Own the Issue
When you take a call from an angry customer, take personal ownership of the issue, even if you would normally pass calls on to another team. Try to ensure that the customer’s issue is handled properly from this point on. If necessary, escalate the situation to your management to get permission to deviate from normal procedures so that you can facilitate this. If you can provide excellent service from this point on, you have a chance not just to salvage the organization’s relationship with the customer but to actually improve it.
Tell the user that you are going to own the issue, and then make sure that you really do own it. It often helps if you ask the user what they would like to happen next. If possible manage the issue the way the customer wants. When that’s not possible, it’s best to be honest and straightforward. Tell the customer what the limitations are now, before they go away with an expectation that you can’t meet. I once had a problem with an organization that delivered a faulty product. I phoned to complain and the person who answered promised to get back to me within 24 hours with a resolution. When they took ownership of the problem, I felt much better. But although I waited patiently for them to call me back, the call didn’t happen! When I phoned them back two days later I was very angry.
As you progress the issue, you must make sure the customer is regularly updated. Talk to them about how often you will update them, and how you will do this, and then make sure you do what you have agreed.
5. Follow Up
After the issue has been resolved you should contact the user again. This is your opportunity to start building a new, healthier, relationship with that user. Make sure they are happy with the resolution, and show them that you care about the service you deliver, and about how they feel.
However good our services are, there are always going to be some users who aren’t satisfied. And sometimes they will get angry with us. One of the things that distinguishes a great service organization is how they manage that situation. You can make it worse by telling the user that they’re wrong, and they’re not entitled to feel angry, or you can acknowledge that they are entitled to their anger and do what it takes to resolve the situation.
As always, please let me know when you try the ideas in my blog and share how well they worked for you.
Posted by Oren Zipori
on June 6, 2017 in Asset Management
In the first part
of this blog series I provided my first four tips for creating a configuration management plan. These related to getting a common understanding of the basics, setting the right scope, agreeing a naming convention, and knowing more about your IT estate. This blog offers four more tips, taking it to eight in all.
Please read on to learn more about how best to get started with configuration management
through effective planning.
Tip 5: Watch the Edges
One of the most closely aligned IT service management (ITSM)
process to configuration management is the change management process. Therefore, your configuration management plan needs to cover how change will interface with configuration and at what point in the change lifecycle the configuration management process will need to be called upon.
Referencing your change management process in your configuration plan means that there’s appropriate support in place to ensure that when a configuration item (CI) is updated, the configuration management database (CMDB)
or configuration management system (CMS) is also updated, such that what you have in your CMDB or CMS matches exactly what you have in your production environment.
Nothing will make your configuration management capability fail quicker than your CMDB or CMS having incorrect or out-of-date information. Thus, control is a critical aspect of configuration management.
Also, work closely with change management personnel to ensure your processes are in sync. For example, you could put a process step in place where a change can only be closed off as successful when the CMDB or CMS is updated. Something else to consider is putting change restrictions or freezes in place during key configuration management process points such as baselining or audit exercises so that you have stability during these critical periods.
Tip 6: Remember Your Lifecycle
Having a section on status accounting in your configuration management plan ensures that the lifecycle stage of each CI is captured accurately. (You can read more about that in this great blog: ITSM Basics: How to Do Configuration Management
Some example configuration management statuses include:
- In test
- In pre-production
- In production
- Out for repair
- In disaster recovery (DR) environment
- Disposed of
Status accounting ensures that all CIs that make up the service baseline, or snapshot, have been captured and that all changes have been captured by change management and are correctly reflected in the CMDB or CMS.
Tip 7: Verify and Audit
For your configuration management plan to be truly effective, you need to have a section on how you will verify the accuracy of your data as well as how to respond in an audit situation. Verification includes routine checks that are part of other processes – for example, verifying the serial number of a desktop PC when an end user logs an incident, or checking that the version of software updated in a planned change has been added to the CMDB or CMS. Also, make sure that you detail who will be doing the checks, and how often, in your plan.
When defining an audit schedule, in the plan, look to the rest of the business for guidance. Do you have any regulatory requirements such as SOX
or BASEL 3
, or any standards such as ISO/IEC 20000
that need to be adhered to? If so, these will probably come with a defined audit cycle.
Also, add in a schedule for internal audits. Because, when preparing for external audits, the best thing you can do is to run an internal audit first so that you can correct any potential issues, or at least come up with a plan to improve in the case of any major findings, beforehand.
Tip 8: Don’t Forget Your Reference Section
The configuration management plan should include a reference section too – that details where information has been sourced from.
When you’re creating a CMDB or CMS you’ll be talking to third-parties such as support teams, service architects, and project managers – tag these teams or roles as references relative to the information they provide. Plus, you’ll need to capture the non-human sources of information such as a service catalog, support documentation, vendor contracts, or service level agreement (SLAs) so that it can be verified as necessary before it’s placed into your CMDB or CMS.
So, that’s my eight tips for what to include in a configuration management plan complete. What else do you have in your configuration plan? What would you add to my tips?
Posted by Oren Zipori
on May 30, 2017 in Asset Management
We’ve all probably heard, and even used, the phrase “fail to plan, plan to fail” but never has this been more pertinent than when planning for a corporate IT configuration management capability – from strategizing, through selling the investment in it, to using it to make a difference to IT and business operations.
Ideally, configuration management
is one of those ITIL and IT service management (ITSM)
processes that should sell itself, but the reality is that it’s much harder to get buy-in for configuration management than say change management. Then, once an initiative has been started, configuration management is an ITSM capability that can quickly spiral out of control, consequently failing to deliver on the promised positive business outcomes, and thus it needs very careful planning in order to be effective.
Don’t worry though, this blog contains the first four, of a total eight, top tips for creating an effective configuration management plan, one that you’ll have no trouble “selling.”
Tip 1: Start With the Basics
Start by explaining that ITIL’s service asset and configuration management (SACM) is the process (or capability) responsible for ensuring that the assets required to deliver IT services are properly controlled, and that accurate and reliable information about those assets is available when and where it is needed. This information includes details of how the assets have been configured and the relationships between assets.
It's also a case of setting the scope and boundaries for configuration management – what it is and isn’t, and what it will and won’t do. Thus, the plan’s introduction (or a referenced appendix) should include an overview of how configuration management will work in your organization, along with objectives and key outcomes.
This will likely include:
- Roles and responsibilities
- The interfaces into other ITSM and business processes
- The technology employed, and how it works with other IT management and business systems
- The reasons why configuration management is needed
- How configuration management will change things for the better
- Some anticipated outcome statements such as fewer change delays or issues, quicker incident resolution, or more efficient capacity planning
Tip 2: Set Out Your Scope
One of the primary reasons configuration management initiatives fail is because people try to do too much too soon. So setting the right scope is a key part of your plan. When planning for configuration management, there are two key approaches:
- Broad and shallow – knowing a little about everything
- Thin and deep – know a lot about a limited number of things, often the most business-critical or problematic IT services.
The latter approach is usually the one taken, as it provides maximum value early on.
Then there are three basic layers to consider:
- Configuration Items (CIs)
The inventory (management) layer takes care of consumables: keyboards, mice, CD drives (if still used), power cables, USB sticks, security peripherals, etc. It’s all about equipment that needs to be tracked for monetary value and to make sure that it’s in stock…but that’s about it.
The next layer is assets or asset management. Example assets include: PCs, laptops, and printers. This is still the stuff that we need to keep track of for monetary reasons and to make sure they’re in stock when needed, but we also need to know locational information and how they are supported.
The final layer is (configuration) items under the control of configuration management, which are often the important items that make up your critical IT and business services. Servers, network devices, and business applications are all CIs that should be under the control of configuration management to ensure that they are managed, supported, and subject to the appropriate change control.
Tip 3: Agree on a Suitable Naming Convention
The plan should explain any proposed, or agreed, naming conventions or nomenclature. Confused? Every CI or item that’s under the control of configuration management should have a unique name or identifier. When I’m tasked with implementing a configuration management capability from scratch, I try to use a naming model that will make it easy for the CI to be identified. So I tend to use something like the following:
Type of Service – Location – Level of Complexity
So a WinTel server based in New York requiring third-line support would be WinTel1234-NY-L3 and a business application located in Dublin requiring first-line support would be BusApp1234-DUB-L1, and so on. In terms of naming conventions, it doesn’t matter what logic you use, as long as everything has a unique identifier.
Tip 4: Know Your IT Estate
A key part of your plan is the baselining process, taking a snapshot of the critical services and their key dependencies so that we know exactly what makes up the IT or business service. The purpose of a baseline is to take a measurable part of the service so that it can be added to a CMDB
(configuration management database) or CMS (configuration management system).
Since it’s a snapshot of the state of a service at any given point in time, it can be used as part of change management activities. Because, if the service has changed, there will need to be a valid, authorized change request against it, as well as being a stable reference for future planned change works.
However, don’t fall into the trap of trying to capture too much data at first – you can always build things up later. If you try to go into too much detail when starting out, you might run out of time and money before achieving any communicable success. Also bear in mind that the more detail you capture, the more work it will be to maintain it.
Here are some useful CI attributes to capture as a starting point:
So that’s my first four configuration management planning tips. Want more tips? Please come back soon for the second part of this blog.
- Unique Identifier
- CI type, for example: server, network device, software package
- Version number
- Support details
- Vendor details
- License details
- Purchase date
- Warranty details
- Relationships to other CIs
Posted by Rafi Rainshtein
on May 23, 2017 in Cloud
Don’t be fooled – by the cloud tech-talk of instances, databases, code, and APIs – into thinking that cloud is all about technology. Unfortunately, this kind of tech-talk can convince IT service management (ITSM) professionals into thinking that cloud is just another technology evolution with zero impact on ITSM
. However, those that realize cloud is all about business, applications, service, and operations will understand the impact across the ITIL ITSM best practice framework – in particular, the impact on capacity management
Cloud requires a different capacity management process to that used for traditional, on-premise IT services. The key changes are in the following five approaches, all of which make capacity management more granular, and move from the long-range “vague” to the short-range “specific”:
- Forecast horizon is shorter
- Speed of change is faster
- Blend of resources is finer
- Automated changes in response
- Balance of CapEx and OpEx
An ITSM professional that understands these five cloud capacity management approaches will be a huge asset to any organization, measured in terms of the business bottom line as well as service quality.
1. Forecast Horizon is Shorter
Buying the full IT stack for on-premise IT service delivery is a long, difficult, complex, and expensive process. Want to know how long?
It takes months, maybe nine-to-twelve months is standard, to design, procure, and deploy any reasonably complex system on-premise. Once procured, it has a lifetime of three, five, or seven years. Maybe longer. This is the long, long, length of the on-premise capacity management horizon.
Over that time, capacity is over-provisioned for peak workloads and this over-provisioning burns money. One might as well be throwing dollar bills out of the window. But in the traditional IT operations spirit of “I only get fired for outages,” capacity management thinking prefers to avoid under-provisioning that can hurt customers and therefore the business.
A capacity manager doesn’t have this many-year-horizon with cloud services. The capacity manager now only needs to forecast ahead as far as the time it takes to add more capacity to the cloud services and that is, on average, around 15 minutes
from decision to deploy, including the time to make a coffee and get comfy in front of the console.
Cloud capacity managers additionally do longer predictions to save money by purchasing reserved cloud capacity, sometimes saving over 60% in costs. So capacity management still has a role to play in longer-forecast planning but it’s now about financial efficiency, not the avoidance of disaster.
2. Speed of Change is Faster
As if predicting capacity changes wasn’t hard enough, responding to them is difficult in non-cloud systems.
Capacity managers cannot quickly respond to unplanned changes in demand if it takes months to procure and deploy capacity on-premise. The brand is then damaged and customers leave if the IT service is down or the business can’t adequately process transactions during highly-visible seasonal fluctuations such as summertime or Christmas (when, unfortunately, many staff are off work).
Cloud components can be scaled quickly and even large amounts can be done in a few hours (10,000 VMs anyone?) with some extra communication with the cloud service provider. Plus, the business can scale down quickly too and turn off all of that excess capacity when the seasonal fluctuation subsides. This can’t be done on-premise, it can only be done in the cloud.
3. Blend of Resources is Finer
On-premise systems might be measured by the number and size of datacenters, comms rooms, and racks. Adding a server might mean adding another rack. That might mean adding another switch, and another rack. Which then might mean extending the closet or room, or even the datacenter.
To avoid hitting these capacity potholes, long-range capacity management forecasting is done to provide more capacity well ahead of the predicted demand. This is a standard enterprise “best practice” approach that’s wasteful and expensive.
In the cloud, it’s possible to keep on adding VMs without worrying about any physical infrastructure or other capacity limits – and so now the granularity of capacity is one virtual machine.
If it’s possible to use higher-order cloud services such as AWS S3 storage, then operations are further removed from storage capacity considerations as these are so scalable a normal enterprise will never hit the limits – and no capacity management is required in the traditional sense. Capacity management now moves to the question “How efficient are we being with our used capacity, can we save money?”
4. Automated Changes in Response
Responding to expected and unexpected demand causes much stress for a capacity manager. For instance, in a typical fixed-size, on-premise IT system there are physical limits to the processing capacity.
The normal behavior when capacity demand exceeds current supply is to push out or de-prioritize non-production workloads – something has to give. But what if getting the new product live is also business critical, and that’s what the non-production workloads are doing? Is the unplanned production capacity demand now delaying an important product release, promised to customers already through advertising and other communications?
In the cloud, this is handled differently. Capacity managers can use automated systems such as AWS EC2 Auto Scaling
to manually, by schedule, or dynamically add capacity, such as more compute or more load balancers. The only upper limit to capacity supply is how much the business can afford to spend.
5. Balance of OpEx and CapEx
Pay-as-you-go (PAYG) is one of the five essential cloud characteristics
. This consumption-focused purchasing method means that you can align operational expenditure to business need via only consuming the cloud services you need. The alternative approach with on-premise is purchasing hardware and software, and owning (and managing) these assets for a three, five, or seven-year period.
Some organizations have budget arrangements to annually plan spend against capital expenditure. This can also be done with the cloud with mix-and-match reserved capacity (annual) and PAYG (on demand). This allows capacity managers to cater for mostly-steady but occasionally-“bursty” workloads.
The other demonstration of mixing OpEx with CapEx is in the so-called Hybrid Cloud
model – mix the CapEx-laden on-premise systems with OpEx-savvy public cloud – handling the steady-state workloads on-premise; and the fluctuations in the public cloud. If
you can achieve this technically, architecturally, and operationally that is.
Capacity management is still important, but different, when it comes to cloud. The old constraints are different and a modern capacity manager is now constrained only by budget (and its efficient use) and a workload’s ability to exploit cloud architecture for auto scaling.
One of my biggest fears as an IT manager is coming to work one day and finding out that my company network was hit by a ransomware attack. So you can imagine my reaction when I read the world news on Friday (May 12th) regarding the wide ransom attacks that were taking place and affecting very large institutions, places where you’d think they were completely covered with their security standards. As it turned out, this was happening worldwide but the big hit was felt mostly in Europe.
Posted by Oren Zipori
on May 16, 2017 in General IT
Ransom Run by the Rotten Mafia
By now we all know the name of that ransom attack is “WannaCry” (official name Ransom:Win32/WannaCry) and like all other ransomware attacks, it encrypts files on an affected computer as well as any other network files that are available for that computer.
After the encryption, the hackers of this ransomware leave a text message or some kind of a note notifying the user that their files have been encrypted and the only way they can get their data decrypted is to pay cash, and then the “nice” hackers will send over a key to unlock all their files. It’s literally a ransom situation by the mafia in cyberworld!
After reading a bit on the WannaCry ransomware I understood that the best way to protect ourselves from such an attack is to deploy the Microsoft Security Bulletin MS17-010 fix, which was released in March 2017. Yup, not that long ago….hence many organizations and individuals had not done so before the insane cyber attack over the weekend.
Can You Say Patch Management?
As the IT Manager at SysAid, I’m using all the SysAid tools (but of course!) to manage my IT services and support, and that includes SysAid Patch Management, which helps to keep our Windows-based servers and PCs always up-to-date with the latest security patches/updates.
This means that all of my users’ computers were being patched on a regular basis and that the necessary security fix was already deployed. Thank goodness!
To feel completely secure, as an added precaution, I logged in to my SysAid Cloud console so I can asses the deployment of the MS security fix across my network and with a simple report I was able to see which computers had the security fix installed and where it was missing (there are various reasons why a mass patch deployment can fail). Then, with this data from my report, I was able to directly attend to those computers and make sure that the security fix was properly installed on them.
To make a long story short, as with all IT-related security issues, one of the most important things is a fast response!
Finally (a shameless plug), I’d love to share with you this entertaining video that my marketing colleagues put together so you can understand how SysAid Patch Management works:
Posted by Sarah Lahav
on May 9, 2017 in Cloud
Clouds are services, not products or technologies, so who better to manage them than an IT service manager with a “special set of skills.” Let’s call them Cloud Service Delivery Managers
The type of organization that has heavily invested in IT service management (ITSM)
is likely to be the “complicated” kind of IT organization that uses many cloud service providers to provision IT services. And while even the smallest, “simplest” organizations might be using multiple clouds for business and are struggling to manage all the different cloud bills, user accounts, and integrations – imagine that pain times-a-thousand. It’s the reality for these complex organizations as they juggle cloud, DevOps, ITSM, and possibly even service integration and management (SIAM)
Cloud Management Complexity
According to the RightScale State of Cloud 2017 Report
, which is based on a survey of over 1,000 practitioners, the cloud “situation” is getting increasingly complicated as cloud pushes into all aspects of business. From end users using cloud storage for work files, and cloud mail for email, to now replacing whole data centers with large cloud service providers – cloud is everywhere! Plus, DevOps
Thus, the challenge that all organizations have, regardless of size, is cloud service management. This ranges from consolidating the bills from the various services into finance all the way to some service administration and being the central point for standards and compliance. And the secret is to not “get in the way” while simultaneously de-risking the consumption of cloud services for the business.
Without someone like a Cloud Service Delivery Manager taking ownership for the above it will be the responsibility of each department, product team, or even individual end users. This might be perceived as great by freedom-seeking individuals who finally feel unshackled from IT – until, that is, the bill isn’t paid, confidential data is leaked by an ex-employee, or services can’t communicate – causing ever-increasing cost and pain.
This Cloud Service Delivery Manager role is an emerging reality, based on real organizational needs related to cloud computing. In this blog, I want to explore the needs driving the role and what the role actually entails.
The Driving Needs for Cloud Service Delivery Managers
All cloud services share similar characteristics and these can be seen differently through the eyes of a cloud optimist or cloud pessimist:
|Essential Cloud Characteristics
||Do it all by myself! No IT personnel needed!
||No IT involvement! No controls on end users!
|Broad network access
||Apps are available from anywhere
||Apps are available from outside controlled environments
||Lower cost by sharing public resources
||Noisy neighbors and risk of exposing business data
||I can balance business demand with cloud supply, scale to whatever I need
||Scale up but forget to scale down, wasting money, with unpredictable bills
||I can see exactly what I’ve used
||Multiple reports from different cloud service providers need reconciliation
At the heart of the Cloud Service Delivery Manager role is balancing these two perceptions, which brings us onto: What do Cloud Service Delivery Managers do?
The Roles and Responsibilities of a Cloud Service Delivery Manager
A Cloud Service Delivery Manager’s goal is to be at the center of tension between opposing drivers in the business. On the one hand, you have the business governance requirement to ensure risks are managed and money is spent wisely. On the other hand, you have business departments and individuals who want the empowerment and agility to create new business opportunities and revenues.
These two needs are often at odds because control can hamper agility, but not always – as the great IT Process Institute book, Visible Ops
, once said:
“Change (control) is like the brakes on your car – it lets you go faster!”
This quote is also used in the context of DevOps and increasing velocity.
Thus, the role of the Cloud Service Delivery Manager is to mirror this statement – to operate in this center of tension and to balance the opposing needs of agility and governance. But how?
The Cloud Service Delivery Manager needs to have responsibilities across five key areas:
|Cloud Service Delivery Manager Responsibilities
||➢ Consolidate all cloud bills for payment by finance
➢ Implement mechanisms to keep downward-pressure on spend such as turning of development resources (where unused out of business hours) and limiting subscriptions to those who need it for their role
||➢ Manage end-user adds, edits, and deletes to subscription services through a central directory
➢ Manage the on-boarding and exiting of staff in terms of cloud service subscriptions
➢ Run compliance reports on cloud services users and usage
||➢ Service catalog ownership and control
||➢ Educate cloud consumers on their rights and responsibilities
➢ Advise cloud service administrators on compliance requirements
➢ Run compliance reports, enforce standards and disciplinary policies
||➢ Maintain the map of business processes to services
➢ Assist with integration of cloud services (but the Cloud Service Delivery Managers don’t get in the way)
The secret to the success of this role is definitely “don’t get in the way” while mitigating risks and continually developing, monitoring, and enforcing standards and compliance.
As soon as the Cloud Service Delivery Manager makes the mistake of being a choke point where “all things cloud go through me” then it will introduce slowness and complexity into cloud service consumption, people will go around the Cloud Service Manager and the organization’s cloud consumption will splinter.
There are levels of maturity in cloud service management that can be understood by using a simple checklist, something the Cloud Service Delivery Manager will do with each cloud service:
The Cloud Service Delivery Manager could be a key role in your business as cloud services become all pervasive across the organization. Doing it badly will have a negative impact on business operations and success, such as if it becomes a choke point, but not doing it at all and letting individuals expose the business to known cloud risks with no guidelines could be more than negative – it could be catastrophic.
- What do I know about the cloud service? Is it invisible vs. on the radar vs. under control?
- Are we collecting metering and bills? Is finance paying for it, or is it on an employee credit card?
- Are we managing the end users? If the end users are not linked to the corporate directory, then this is a red flag risk.
- Is this service understood and available via on-boarding process via our service catalog?
- Do the cloud service consumers and administrators know their rights and responsibilities? Are they compliant? How can we help them enforce the rules? Do we have a reporting, escalation, and disciplinary process? Do we encourage whistle-blowers and white hat hackers?
- Is this service integrated into other services? What are the dependencies and what’s the business risk?
- Across all of the services, what’s the score of these services and where is it in our priorities for resource to improve?
Posted by Stuart Rance
on May 2, 2017 in ITSM
All the IT service providers I’ve worked with assure me that they measure the services they provide. They use metrics and KPIs to do this, and have service-level agreements (SLAs) with their customers, which they use to document what’s been agreed.
Unfortunately, most of the metrics and KPIs that I’ve seen only measure and report the things that service providers can control, and not the things their customers actually care about. This tends to result in reports that show service providers meeting most, if not all, of their targets, even when customers are distinctly unhappy about the service. This happens so frequently that the phenomenon even has a name: the “watermelon SLA
”. When you look at a watermelon from the outside, all you see is green. Delve a bit deeper and you discover that most of the fruit is red. In the same way, we report that everything is meeting its targets (it’s all green), but if you delve into the customer’s experience you find that it’s not very good (it’s mostly red).
So, what can service providers do that will help them to delve that bit deeper and focus on what matters?
What’s Important to Customers?
When service providers think about any service, they need to pay attention to what’s important: the value of the service, the intended outcomes, the costs, and the risks – together referred to as VOCR
. Here is a brief summary of what we mean by these terms.
- Value is a measure of the benefits that the service creates for the customer. This could be in terms of money, but it might be something like lives saved, or some other indication of the customer’s mission.
- Outcomes are the things that the customer achieves as a result of receiving the service. For example the service may help the customer to manufacturer products, or communicate with their partners, or collect payments on a web site.
- Costs are the money that the customer has to spend to achieve the outcomes they want.
- Risks are possible events that could affect the ability of the customer to achieve the desired outcomes.
In my view, if every service provider produced reports showing the VOCR of their services, then customers would have no difficulty understanding what these reports mean, and judging whether the service was good value (or not).
Of course, it’s not that easy. The trouble is that value, outcomes, costs, and risks are only partially under the control of an individual service provider. For example, consider an IT company that provides a manufacturing support service to a car manufacturer. The outcome that the customer wants might be “a car comes off the production line every 40 seconds” (my thanks to James Finister
for this example), but this outcome is not completely controlled by the IT service. Even if the IT service
works perfectly there could be other reasons why a car doesn’t come off the production line. So, what should you measure and report in this case?
What Should You Report to Your Customers?
Under these circumstances most IT service providers would probably report things like:
- Availability of the IT service
- Number and severity of incidents
- Average time to resolve incidents, subdivided by category
The information provided might be accurate, but it is very IT specific. It represents an IT service provider’s view of the world. But of course, this isn’t what the customer cares about. The metrics that matter to the customer are how many cars come off the production line (outcome), how much extra cost do they have due to IT failures (cost), how much lost production might they have next week (risk), and derived from these, how much profit can they make selling cars (value).
So, is it possible to create IT metrics and reports that actually show all of these things? Yes, it is. An ideal SLA could state the following:
“The desired outcome from this service is to support the production of one car every 40 seconds.”
The monthly report could then show whether this was achieved. Similarly there could be report sections on cost and risk, showing how well these have been managed for the customer.
Does this mean we stop measuring IT service availability, number and severity of incidents, incident resolution times? Obviously not. Providers can’t do their jobs well without this information. What I am saying is that these are not the key things to report to the customer. The main findings of any report to customers should be about value, outcomes, cost and risk; IT-centric issues should be reported within this context, as contributing factors, and at whatever level of detail suits the specific customer.
Here are two more examples of IT organizations that have great business-focused reports:
What about your SLAs and customer reports? Are they about IT or are they about value, outcomes, cost, and risk? Maybe it’s time to think about what your customers really care about, and create SLAs and reports that match their view of the world.
- One client that I worked with had a key business metric stating that they should never lose any customer data (the data represented a lot of money). It didn’t matter if the data was lost because a paper document got lost before it was scanned, or because of an IT error. The thing that mattered is that every piece of customer data must be correct and accurate at all times. The reports they produced started by summarizing the status of customer data, THEN they went on to account for any risks or issues that had occurred that month. Some of these were IT related, others were down to the various business units, but the report included everything.
- Another client was responsible for shipping parcels to end customers. Their key metrics were the percentage of parcels that arrived on time, and the percentage of parcels that were lost. As in the other examples, these things might be caused by IT failures, or they might be due to many other issues, but the IT reports focused on the business metrics, and then on how IT had contributed to these.
Posted by Doug Tedder
on April 25, 2017 in ITSM
Many businesses, and IT organizations, become frustrated with a lack of agility and responsiveness with their change management process. Rather than being viewed as a “value enabler,” the change management process is often seen as overly bureaucratic and a hindrance to getting things done. But in my experience, these issues usually boil down to a poor implementation and misunderstanding of the purpose of change management.
What Is the Purpose of Change Management?
The change management process has three primary purposes:
- To ensure the appropriate planning, review, coordination, and communication of a change.
While not all changes are created equal, all changes must have the appropriate degree of planning, evaluation, approval, orchestration, and communication. Without these elements, there can be no control over the managed environment, which ultimately means that the business cannot rely on IT.
- To protect what’s already in production.
A change must have no negative impact to services that are already in the managed environment.
- To ensure that a change delivers the intended result.
The whole reason why a change is being made is to deliver a planned result. If a change is implemented, but it does not deliver the intended result, this points to larger issues that must be addressed.
Seems rather straight-forward and common sense, doesn’t it? So why do so many change management implementations result in frustration, subterfuge, and headache? Perhaps you’ll recognize some reasons in my list below.
The Seven Deadly Change Management Sins
- Every request for change has to go before a change advisory board (CAB).
Out of all the sins, this is the one that I see most frequently. Because change models and evaluation criteria are not defined, *every* request for change – regardless of complexity, resource needs, or impact – gets dumped onto the CAB.
- No true management support.
This is my second-most encountered issue with change management implementations. I believe that management – especially senior management – must exhibit strong, visible support to ensure an effective change management process. But what I often find when it comes to enforcing policies and supporting the process, is that senior managers do not want to (visibly) enforce the very policies and process that they commissioned!
- Request for Change (RFC) not raised…until just before implementation.
This behavior essentially guts the change management process by bypassing the crucial initial review, evaluation, planning, and communication of upcoming work. This action in turn, has a cascade effect on work that has already been planned, resulting in resource conflicts.
- No one, other than the change manager, has any accountability for the success of the process.
I frequently encounter the misconception that once an RFC is logged, then it’s the responsibility of the change manager to coordinate all of the activities related to the change. The fact is that the change manager is accountable for the operation of the process – and ensuring that the handling of each RFC follows the process – not the design, build, testing, and implementation of a change itself.
- The change schedule is not published outside of IT – sometimes, it’s not even published *within* IT.
The change schedule is intended to promote communication and transparency, not only regarding the change management process, but also regarding the demand and workload within IT.
- CABs do not have the proper membership.
CABs are often just made up of IT personnel, with no participation from business colleagues.
- Process over engineering.
When discussing change management, I often use the analogy of the control tower at an airport. The control tower ensures that at any given time there is one and only one airplane on any given runway at the airport. The control tower does not pilot the plane, does not manage the loading and unloading of passengers and cargo, nor the servicing of the aircraft, and so on. Those activities belong within other roles and procedures. The control tower’s job is to ensure safe landings and take-offs. A good change management process is like the airport control tower – but unfortunately, many change process definitions include all of the other “airport operations” that really shouldn’t be there.
Any of the above sound familiar? It’s no wonder that our business partners are frustrated. It’s no wonder that IT
Seven Things You Can Do to Fix It
If your change management process is suffering, here are seven things you can do to fix it:
Is your change management process not producing the results your organization needs? Even worse, is your change management process in the way of making changes? Don’t give up – these seven fixes are sure to move your change management process from being the “barrier” to being the “value enabler”!
- Define change models.
A change model is simply a pre-defined way of implementing a change. Executing the steps within a change model is often the fastest way to implement a change.
- Define and enforce the responsibilities of the change owner.
The change owner is accountable for the success of a change, not the change manager. It is the change owner who is responsible for capturing the requirements for a change, ensuring the design and build of a change, defining and executing appropriate testing, and ensuring a smooth implementation of a change.
- Define evaluation criteria.
Not all RFCs should go before a CAB for review and authorization. In fact, in a well-defined change management process, most RFCs should be authorized by someone other than a CAB. Defining evaluation criteria helps ensure the “right” RFCs go before the “right” people as defined in… (see my #4).
- Define a change authority matrix.
Defining and following a change authority matrix identifies who the “right” people are to review and authorize RFCs. Have your senior management review, approve, and sign-off on it – this helps enforce accountability – and get management commitment.
- Publish the change schedule – to everyone.
Not only will this improve change management awareness and communications within IT, it is a great way to illustrate how much work is getting done by IT.
- Produce and publish metrics that make sense to the business.
While publishing the number of changes implemented within a timeframe is nice to know, measuring and publishing the business improvements resulting from the implementation of a change is much more meaningful. For example, if a change is intended to reduce order processing time – measure that!
- Remove any non-value added work and wait time from the process.
For example, why arbitrarily conduct CAB meetings on a weekly basis? Take a page out of Agile and use the daily stand-up meeting like a “CAB meeting.”
If you’d like more tips, I highly recommend Stuart Rance’s
blog listing his top tips for supercharging your requests for change
. And for the beginners out there, Joe The IT Guy
does a great job explaining the basics in his blog ITSM Basics: A Simple Introduction to Change Management