Automate This!

The trouble with Incident vs. Problem Management

2010-01-29T17:55:00Z

An interesting debate has been raging in a LinkedIn ITIL group (note: you will need to register to see it). A poster asked a simple question, "Does a Major Incident automatically lead to the creation of a problem record?". You would think that ITIL would have a simple answer to such a question, but given the eight pages of replies (as of Jan. 29th), it is clear that there is a need for more clarity in the ITIL guidance and ISO 20000, whether that clarity comes in the form of specifically saying that it is up to each organization to decide, or it decides to prescribe the "right" answer, as is the trend more and more in the evolution of ITIL.

For those of you who are not ITIL experts, in general terms, Incident Management is a discipline tasked with restoring normal operations to a service when it is degraded or down, as quickly as possible. Problem Management is tasked with preventing problem recurrence. In other words, Incident Management wants to "fix it now" by just about any means necessary, including work-arounds. Problem Management is a more methodical discipline, looking for patterns that will indicate some systemic problem and setting in motion actions that will prevent it from happening again. Given the speed vs. analysis dichotomy, there should be some natural tension between these two disciplines.

The confusion creeps in for several reasons:

1. There is a fundamental misunderstanding of the difference between an incident and a problem. Problems are not "really big incidents" as I heard a speaker at an itSMF Local Interest Group once say. Theoretically, all incidents have an underlying cause, which is a problem. Multiple incidents could point to one underlying problem, such as the proverbial network cable that gets pulled in the data center, shutting down several services to end users. Or, a problem could just be a user that needs some training.

2. The people doing Incident Management should not be the same people doing Problem Management. If they are, proper Problem Management will simply not happen, due to the constant firefighting. Problem Management takes time, special technical skills and tools, and is a major investment that few really appreciate. But the payoff in reduced outages and reduced need for Incident Management resources will eventually result in a return on that investment.

3. There is no clear guidance on who handles a Major Incident. If you really want to read the academic debate about what ITIL says or doesn't say on this topic, it's there in the post I linked to earlier. The result is a grey area that leaves it up to each organization to decide how to recover from Major Incidents.

So, where does that leave those of us who need to craft functioning Incident and Problem Management processes? My advice is that the biggest item to address is to ensure that everyone in your organization knows what is expected of them in a time of crisis. Consistency that ensures effectiveness is more important than academic adherence to ITIL.

IT Process Automation (ITPA) has a role to play in driving consistency by ensuring that incidents and events are properly correlated, documented and escalated to the right teams at the right time. At NetIQ we sometimes refer to this as "event enrichment", something we've been receiving more and more interest in from our customers. We will be producing additional content and releasing new workflow templates for event enrichment processes in our ITPA platform, NetIQ Aegis, over the coming months. Stay subscribed to this blog, to keep updated on the topic.

Why is it so difficult to maintain accurate process documentation across an IT organization?

2009-11-06T19:37:00Z

I saw this question posed in a discussion on LinkedIn, and thought that it deserved an answer from an IT Process Automation (ITPA) perspective. One respondent to the question stated it well: "The answer is simple, if there is not a common bond and governance mechanism between process documentation and the technology that is executing the process, the documentation eventually atrophies and collects dust." In my days as an independent ITIL consultant, I found that training and getting personnel to use process as part of their daily routine was at least as difficult as maintaining and updating process documentation. There is a chasm between theory and practice when it comes to process execution.

By applying ITPA to this problem, the general idea is that through automation, process drives people to make decisions and take actions at appropriate times, rather than depending on people to accurately follow process all the time. Because process takes the lead in governing activities, it is by default accurately documented (or a need for change becomes apparent). It also reduces training and enforcement burdens.

The ITPA approach is similar to what Business Process Management (BPM) has done for business processes, such as receiving orders all the way through to fulfillment. But ITPA differs in that it is tailored for IT processes, both at a "Macro" or ITIL discipline level, as well as at a "Micro" or procedure/work instruction level. A big distinction is the ready-made integrations to common tools already in use, such as ticketing tools, monitoring tools, provisioning tools, etc. that make it easier to document and automate process from available building blocks.

I see a lot of organizations benefiting from this approach, not just from a consistency of process documentation and execution perspective, but also from labor savings. This can be through reduced manual documentation requirements (such as filling out ticket details) as well as a reduction in performing repetitive manual tasks. It also raises visibility of process by allowing authorized users to check on the real-time progress of any specific process as well as providing metrics or reports on the general execution of processes to identify bottlenecks, unnecessary repetition and so on - supporting continual service improvement.

The trade-off is that it requires good process designers. If you automate a bad process, it can make things bad faster. You can't hide process problems if you go this route. For those companies that are taking the steps to mature their processes, though, ITPA technologies like NetIQ Aegis are worth a look.

NetIQ Announces Successful Completion of MSPAlliance Vendor Accreditation Program

2009-10-05T23:11:00Z

NetIQ has a long history of working with Managed Service Providers to meet their unique needs for multi-tenant, remotely accessible and highly scalable management software. But we recognized that there is a growing need - dare I call it an imperative - for automation software among MSPs. MSPs must constantly fight to improve profitability and gain competitive advantage vs. other MSPs and internal IT organizations, and IT Process Automation (ITPA) software is a great way to maintain that edge. So, to build awareness of this, NetIQ chose to submit to the MSP Alliance's rigorous evaluation to gain accreditation. You can read more about it in our press release.

While NetIQ has had dedicated account teams, flexible licensing terms and global support for MSPs for years, this effort marks the beginning of a new focus on helping our MSP customers become even more successful. The first part of that effort can be found on our new web page dedicated to MSPs, which contains a sample of MSP customer success stories from the likes of Presidio, Siemens, MTS Allstream and Attenda amongst others. More resources will be posted there over the coming weeks, so stay tuned and if you have suggestions or questions on how NetIQ can support your MSP operations, let us know at MSPsales@netiq.com.

Don't Just Monitor. Manage!

2009-08-03T08:23:00Z

Systems Management. It’s a common term, historically used by software vendors to categorise their monitoring solutions – the technologies that many organisations deploy to measure the performance and availability of their IT infrastructure. And there’s an important link there. Afterall, the old adage goes “you can’t manage what you don’t measure”. And it’s true. In order for IT teams to be able to optimise the performance of the IT infrastructure, and to respond to critical system problems, they have to know what is going on, and be notified quickly when something fails or degrades. And it can work. Practically all vendors in the ‘Systems Management’ space have case studies describing the value that ‘X’ customer is getting from deploying ‘Y’ solution. The important thing to remember is that it takes effort. Human effort. The countless man-hours of keyboard-bashing and mouse-clicking in response to the alerts that are generated. But that’s not management, is it? The Oxford English Dictionary defines ‘Management’ as “the process of managing”. Not an overly descriptive definition, but it makes an important assertion – namely that management is a process. The definition of Process? “A series of actions or steps towards achieving a particular end”. Now, if we apply this to the IT environment, whilst many organisations might say “we don’t have a process”, in reality they all do – it’s just not formally documented (and often not scalable or particularly resilient…)

Let’s look at ABC Corp again...

Jane, on the ServiceDesk knows that when a particular type of event is received for the CashOrder app, she should assign the call to Bob, because if there’s a problem with CashOrder, you call Bob – he’s supported it since day one. He always knows how to fix it. And what does Bob do? He spends the next 30 or so minutes connecting to the system, checking to see who is using the app, sends them an e-mail saying the app needs to be taken offline, so they’ll need to disconnect, and if they don’t he’s going to disconnect them anyway. He goes and grabs a coffee, then he checks again, stops the app, navigates through the obscure folder hierarchy to that folder tucked away where all those old files collect (and Bob knows that when there are more than 30 files, greater than 5mb in size and over 4 hours old, the app doesn’t like it and throws a wobbly), he deletes them all, then restarts the app. Sometimes he’ll check if the app is actually working again, and sometimes, if he’s in a good mood, he’ll actually tell the users that the app is back up again so that they can continue doing the job they are being paid to do. Bob loses count of the number of times he has to do this every month…

Who, or what, did the ‘management’ here? In reality, part of the process was undertaken by Jane on the ServiceDesk assigning the call to Bob, and then Bob himself who undertook all the necessary steps to resolve the problem. Not the ‘Systems Management’ tool – in this case it’s just monitoring. But what happens if someone new on the ServiceDesk responded to the alert, and, what if, heaven forbid, Bob was on holiday (Bob normally takes his Blackberry on holiday and checks his e-mail, but this time his wife put her foot down and told him to leave it at home…). Well, the monitoring tool continues to raise the alerts, but they take longer to resolve, as people have to work out who should own the problem, and what they need to do to fix it. The problem gets worse, people can’t do their job, they phone the ServiceDesk to complain, and eventually, a very unhappy Robin Farquhar-Brown, ABC’s VP of Operations storms into the CIO’s office…

Wouldn’t it therefore be good if the ‘Systems Management’ (read ‘Monitoring’) tools actually ‘Managed’? A kind of ‘Systems Management 2.0’. A solution that provides the comprehensive, and important, monitoring of the IT infrastructure, but then actually knows what to do with the events when they are generated, regardless of whether Bob is on holiday or not. A tool that:

Collects the event(s)
Creates a ServiceDesk Ticket
Connects to the app to check current users
E-mails the users asking them to disconnect
Waits for users to disconnect, any remaining are e-mailed again, telling them app is going down
Stops the app
Navigates to folder, searches for old files meeting the defined criteria
Deletes the files
Starts the app, and validates that it is functioning again
E-Mails the users to tell them the app is back up and working
Updates and closes the ServiceDesk ticket

Systems Management 2.0? IT Process Automation anyone..?

ITIL - does it really work? Part 3: introducing IT Process Automation as an ITIL enabler

2009-07-20T08:51:00Z

Over the past couple of weeks, this 'ITIL - does it really work?' series has explored the objectives of ITIL, and some of the challenges organisations can face in ITIL adoption. Here, in the final part, we'll take a look at how emerging technologies can not only drive greater ITIL process efficiency and effectiveness, but also maximise the value gained from existing people and technology in the organisation.

These emerging technologies are closely allied with the core objectives of ITIL. IT Process automation tools (ITPA) are essentially a means of capturing, modeling and automating IT operations processes providing benefits around the reduction of operational cost and risk as they help to offload repetitive, manual tasks from overburdened IT operations staff. They bring control and automation to IT operations by ensuring consistent process execution and improving run books and ITIL-based processes.

ITPA tools can bridge the gaps between existing systems, ensuring (as an example) that the systems management platform is tied to the service desk system resulting in a streamlining of processes between the infrastructure and the service teams, leading to even greater efficiencies.

Automation can operate at two distinct levels; a macro or micro level. At a macro level, ITPA spans multiple disciplines, silos and technologies. Macro level automation would be the overarching processes of incident, problem or change management. Micro level automation fits within a single silo or technology. It is typically a routine, individual process performed by administration staff, such as alleviating the problem of known errors. It defines the set of processes needed to identify and communicate the problem to the relevant staff and to determine the appropriate response and implement the fix. The micro level process automation is also commonly referred to as Run Book Automation (although Gartner tend to use this term to encompass both Macro and Micro level ITPA).

ITPA not only increases the value of existing technology investment but can also help to ‘liberate’ data traditionally trapped in silos of different technology areas - which can then be used to implement improvements and to enable more effective service delivery.

By modeling and automating responses a company can minimise risk and improve the consistency of response to common incidents. Human nature dictates that people may attempt to circumvent a process, so automation enforces a means of process execution that is not reliant on people following a set of procedures. It also allows an organisation to capture tribal knowledge and prevent information flight caused by people leaving an organisation.

From a compliance perspective this level of automation also provides an audit trail when it is essential to demonstrate that a task is undertaken in a consistent process. Automation tools can build in a set of checks so that managers can be confident that these are completed to a satisfactory level, in addition to eliminating the risk of human error. This also means that, for all auditing that is carried out on IT processes, the company can demonstrate that the procedure has complied with best practice.

In this way, ITPA crosses the three ITIL pillars of people, process and technology, bringing with it demonstrable cost savings. We ourselves are working with a number of organisations to build workflows to automate and orchestrate operational IT processes that involve multiple types of data, applications and company departments. Administrative and labour intensive tasks which address processes such as disk space clean up, server re-boots, new system releases or password resets, can be a considerable drain on an organisation’s time. Automated remediation of these tasks can free up considerable man hours; an end user could interact with a process rather than a person to obtain a password reset, if the process and the supporting technology is put in place, thereby freeing up the people to concentrate on other essential tasks.

We also work with numerous organisations to provide Incident Enrichment. We integrate the knowledge with the technology – incidents are recorded and fully populated with timely and pertinent information at the time of incident creation, then appropriately updated through the incident lifecycle. This detail can be gathered by using technology to capture and query the information. This additional level of detail allows an individual to then make a much more informed, faster decision about how to resolve the incident in the most timely manner and with minimal impact. This detail also allows root cause analysis and moves an organisation on from Incident Management into Problem Management.

These examples demonstrate the natural synergies that exist between process automation and ITIL in improving service quality, without increasing headcount, delivering process consistency and saving costs and resources.

It’s probably fair to say that many organisations do not yet have strong adherence to ITIL and nor have they yet reached the level of documenting all IT processes and determining what information needs to be shared with whom and who is responsible for managing which aspects of the overall process. Yet it would be a mistake to dismiss the framework as another level of ‘process for process’s sake’ and in this cost- conscious era. In a climate where organisations are being forced to focus on driving ever greater efficiencies, most can derive some benefit from re-assessing the way in which they deal with processes and considering areas in which automation can deliver time and resource savings.

ITIL - does it really work? Part 2: What are the challenges of ITIL?

2009-07-09T07:29:00Z

Earlier this week, I explored some of the goals of ITIL, and what it, and organisations implementing ITIL-based process, are striving to achieve. Here, I discuss some of the high-level challenges organisations can face in their adoption of ITIL, and the pursuit of it's objectives.

ITIL has many advantages, principally to drive the efficiency and effectiveness of IT service delivery, whilst ensuring that business needs are understood, and met. However, as with any new 'system' implementation, for many organisations ITIL could be viewed with a large degree of scepticism. Potential concerns centre on it bringing additional cost, disruption and increased layers of bureaucracy, or unwanted investment of time and resource when capital outlays are being squeezed.

Making ITIL successful depends on weighing up the benefits on a case by case basis. As with any procedural change, before embarking on ITIL implementations, it is essential to do a thorough assessment to identify how your current organisational structure compares to the ITIL framework and then look at how you would need to change your organisation and culture to best use ITIL. Implementing any kind of new process requires resource and in the current economic climate managers need to carefully consider if they will get full payback for their investment.

The first challenge is for the individuals themselves. Changes on any level can often bring a degree of resistance and implementing ITIL can require a shift in mindset. Therefore training, leadership and flexibility are important for its success. Often, so-called ‘green field’ implementations can be the most successful as ITIL-based approaches can be delivered from the ‘ground-up’ rather than worked into the existing processes and technology.

For some, the further investment in additional technology needed to fully adopt ITIL processes, particularly in today’s budget-conscious environment, is a barrier to adoption. The resources required to deploy, configure, and maintain these frameworks could outweigh the expected benefits and organisations also need to consider if they can integrate their existing technologies or if they need to replace these with, for example, a new suite of ITIL-based service desk solutions.

Documentation is a key component of ITIL, yet efficiencies can only be realised when this information is fed back into a cohesive system. Documenting incidents does not provide root-cause analysis of issues, and streamlining the time to resolution requires close alignment with problem management for improvements to be realised. For this to happen, a process needs to be built which captures and records the incidents, uses this knowledge to classify incidents, who is being affected, why it’s occurring and record the diagnosis and the process to restore service. Initially, this will mean that the service desk needs to allocate more time to their tasks, however, if there are long terms gains to be made, then the move towards ITIL-adherence can pay dividends.

So often, you hear organisations talking about their 'ITIL Project', as if when the identified tasks and milestones have been met, the job is done, and ITIL becomes an established facet of the organistion. We all know however, it's much more than that, and requires ongoing review, management, and support to be successful. Next week, in the third and final part of this short series I'll pick up on the solutions available to increase the ongoing effectiveness of ITIL processes, providing the glue to link together the much declared areas of People, Process and Technology.

Technorati Claim Code: tnwz3y87s9

2009-07-08T18:55:00Z

Apologizes to our regular readers and subscribers, but to ensure Technorati can find us we are required to publish this post.

tnwz3y87s9

For those trying to claim a blog on Technorati, claiming your blog establishes that you are its owner and allows you to use Technorati services to increase your blog’s visibility; such as associating your profile with your blog and listings in the Blog Directory and Blog Search.

Please be advised this process took several attempts, over several months, before it worked as described by Technorati. Once you have joined Technorati as an individual proceed to 'Claim A New Blog' and enter the URL and submit. It is at this point that our requests failed on numerous occassions. Eventually, we received the code featured in this blog post and its title and published it at the URL submitted. Within a day the blog was listed as claimed.

Enrich your (Incident) Life!

2009-07-07T13:02:00Z

Many organisations see many different advantages to IT Process Automation, and much is said about the benefits of automating routine, mundane and manual tasks from overburdened operations personnel. However one topic that seems to resonate consistently with organisations following an ITIL-based approach is that of ‘Incident Enrichment’. To explore why this might be the case, sit back, relax, and let me tell a story…

“A couple of years ago, ABC Corp threw themselves headlong into implementing ITIL, as they saw it as the ‘Magic Pill’ to cure all their IT operations woes. To support this initiative, they made an investment in the latest ServiceDesk technology from ‘Big Joes ServiceDesk Solutions’. And they loved it. They could finally see how many incidents were being raised and who was handling them, and could report to management on ‘Mean Time To Recovery' (MTTR), ‘Mean Time Between System Incidents’ and lots of other metrics they had learned about on their ITIL training. Even many of the guys at the coalface liked it; they could finally prove how hard they were working (and the IT department even ran a few friendly competitions in the early days, awarding Dons Delicious Donuts vouchers to the guys that closed the most incidents). And, they could only wonder at all the other ITIL processes that they could implement later.

But, the honeymoon period soon ended. ABC Corp wanted to introduce Problem Management – they knew that the best IT departments were all into ‘Proactive Problem Management’. Mary was appointed ABC’s ‘Problem Manager’. You had to hand it to her, she was keen. “Let’s review our Incidents for the last 6 months, see what we can identify as Known Errors”. She pored over the data, but it was decidedly lacking in information. “I can’t believe this” said Mary. “Look at all these incidents that have been closed without information. The admins have just commented ‘problem fixed’!” She needed to know why, so she headed off in search of ABC’s administrator extraordinaire – “Mike the MCSE”. Mike was quick to point out that since all the budget cuts, there were fewer staff, and updating tickets had just become a layer of bureaucracy that they didn’t need, and frankly didn’t feel they had time to deal with. “After all” Mike said, “I can resolve a customer problem in 2 minutes, yet it can take me 10 more to update the ticket with all the steps I took”. Mary knew she needed to find a solution…”

In this story, Mary could work with ABC Corp’s IT Management to enforce that incidents get updated more thoroughly, but they will likely hit resistance, and they may find that they only achieve a temporary result. It’s much better then to find a solution that actually helps the guys on the ground be more efficient and effective, resulting in improved service delivery. Many organisations try to achieve this exchange of data between technologies by implementing initiatives like auto-ticketing from monitoring tools, so the incident contains the exception information contained in an event or alert. Whilst this is a step in right direction, it presents challenges. After all, you don’t want to auto-ticket on all events, as you’d just overwhelm your Service Desk. So, how do you choose which events or alerts should be auto-ticketed, and how do you deal with the threat of an event storm? And, this doesn't solve the problem of Admins like 'Mike The MCSE' not updating incidents later in their lifecycle.

Ultimately, any initiative like this is trying support the Incident Management goal of restoring service as quickly as possible. To achieve this, the process of Incident Management has a number of steps, typically to Identify, Record, Categorise, Prioritise, Diagnose, Resolve & Recover and Close the incident. And it is the lifecycle of these activities, or the time taken to move from the Identify step to the Resolve & Recover step that gives us the useful metrics like MTTR etc. Common sense dictates therefore that if we can give the people/technology tasked with making some of these decisions better information to enable them to make a faster, better informed decision, we’re reducing our MTTR, meeting service levels, and potentially improving the perception of IT. This is where ITPA can help. By enriching incidents with timely pertinent data – perhaps End User Response Time data to determine ‘who’ is actually affected, or further diagnostic information, we can enable these decisions to be taken quickly. Next, enriched incidents provide a valuable input into Problem Management, where we can use them to identify Known Errors. These Known Errors could then be automated further, where ITPA orchestrates the steps of the Incident Management process from Record to Recovery, without human intervention if appropriate.

ITIL - does it really work? Part 1: What is ITIL striving to achieve?

2009-07-02T20:13:00Z

Much work has been put into developing Information Technology Infrastructure Library (ITIL) and many vendors want to be ITIL compatible, but does it really deliver and what value does it really provide the end user?

Since ITIL was introduced there has been much debate on the value that it adds to organisations and why they would opt to consider ITIL-based processes at all. In this era of ever more complex mandates, regulations and legislation, is ITIL simply another management buzzword; an extra layer of bureaucracy that adds a further burden to already over-stretched IT departments, or can it add real value to an organisation’s operations and help to achieve the all-important operational efficiencies that it was originally intended to deliver? Here we consider the pros and cons of the ITIL disciplines and framework, the approaches needed to make it work and the value that process automation can play in leveraging existing technology investments to drive greater efficiency, whilst ensuring that the quality and cost of service are the very best that can be achieved.

Over the next week, I'll explore what ITIL is striving to achieve; whether it really works and some of the challenges to effective and successful ITIL adoption; and how technology can be an ITIL enabler.

What is ITIL striving to achieve?
Principally, ITIL was borne from the need to develop standard procedures and best practice and is based on those used across a wide range of public and private sector organisations. The ITIL framework brings together people, processes and technology with a common terminology and accepted, global standards which can aid communication between suppliers and clients and improve understanding of what needs to be done to align with the needs of the business.

ITIL is a non prescriptive framework; there are no mandates enforcing its adoption, nor is there a rigid set of rules, in fact many organisations prefer to take a more selective approach to ITIL, only using those aspects which most suit specific operational functions such as configuration management or incident management. The framework sets out to drive greater alignment with the business and IT operations, so that IT supports the businesses needs, rather than providing an additional cost. The latest version of ITIL v3 sets out a lifecycle approach to continual service improvement which organisations can appraise at each stage, to ensure IT continually realigns to the needs of the business. This framework:

Describes strategies to align service management with the business strategy
Explains how to use the strategy to create designs for service
Details how to these can be used in a real business environment
Sets out how to support the day to day running of the service

This approach can, and does, add real value to businesses but those embarking on the process of ITIL adoption need to carefully consider what they’re trying to achieve to ensure that the benefit outweighs the cost of implementation. Take incident management as an example, perhaps the most ‘customer-facing’ of all ITIL processes. ITIL incident management provides a framework for organisations to improve their methodology and therefore reduce the effect on an organisation, The ITIL objective is to restore service levels in the fastest time with the least possible impact for the business and end user, and at the lowest possible cost to the organisation. Incident management is one of the disciplines where established processes and terms can ensure issues are resolved quickly, minimising the impact on the end user and enabling an organisation to shrink the time between steps so that a service can be restored more quickly, for example dealing with routine ‘Known Errors’ in a consistent, timely manner.

Of equal importance, these processes can more readily help in Problem Management, by establishing a means to carry out root cause analysis. Undertaking this type of analysis enables organisations to eliminate known errors and reduce or prevent incidents from occurring, resulting in streamlined operations. However, this kind of analysis, while valuable in the long-term, can create a heavy administrative burden to analyse and resolve the issue. Identifying trends or common issues and their impact is essential in focusing limited resources, saving costs and making service improvements over time.

ITIL clearly has many advantages, but despite this, there are obstacles to it's effective adoption. In my next instalment, I'll take a look at some of these challenges...

Presentation Video: Making ITIL Practical: The Impact of IT Process Automation

2009-06-18T21:06:00Z

I recently had the pleasure of presenting at the ITIL v3 Online Summit, hosted by BrightTALK, around a previous blog post of mine: Making ITIL Practical: The Impact of IT Process Automation.

The best-designed processes can sit on shelves while the organization refuses to change. IT Process Automation bridges the gap between process design and implementation by leveraging tools already in use and automating the repetitive and bureaucratic portions of ITIL. In the session I gave real-world examples of processes that have moved from paper to production and if you missed the live session, BrighTALK has just posted a recording:

(Please visit the site to view this media)

Automate or Die!

2009-06-05T13:35:00Z

I have a brother-in-law who has been a machinist for his entire career. In other words, he makes parts, mostly for large airplanes. When I’ve asked him about his job, his biggest complaint was that union rules prevent him from being productive. In order to protect jobs, the rules restrict him from operating multiple CNC machines at a time, whereas he has the time and skills to do so. He’s literally bored on the job.

The reason he can operate multiple machines at once is automation. CNC machines are, by their very design, highly automated. They take instructions from CAD/CAM programs and automatically machine aircraft parts (or whatever). But shops have taken automation to a whole new level by automating the changing of tools, delivery of materials pallets, and more. In other words, they’ve automated the inputs and outputs.

This has had a dramatic impact on productivity, as measured by the utilization of machines. In an article entitled, “Automate or Die,” American Machinist magazine describes the benefits of automation beyond CNC:

"The simplest forms of automation are automatic tool changing and automatic pallet changing. Combined, these two functions can increase a horizontal machining center's utilization 50 percent to 80 percent, given the right application."

Unfortunately, the complaint I hear from IT managers is just the opposite of my machinist brother-in-law. In our conversations, we still hear about skilled administrators performing very mundane tasks. There are examples we hear so often:

“We have a full-time employee dedicated to handling disk space-related events.”
“Maintaining monitoring thresholds is a constant challenge for us.”
“How can we automatically set maintenance mode in our monitoring tools?”
“We routinely reboot those servers to resolve a known issue. But it takes Joe four hours every time to do the reboot and make sure it was successful.”
“And then the analyst updates the trouble ticket with information from the monitoring tool.”

The list goes on. But this is much more important than a simple complaint. It’s a real business issue for IT. If skilled people are consumed by mundane tasks, they’re frustrated (if not bored). They’ll move on, and take what they know with them. More importantly, IT may fail to deliver on important commitments because they’re distracted by day-to-day issues.

If you must automate (or else), what do you automate? What are those “simplest forms of automation” that can provide a high return for the effort? Travis Greene recommends several questions to ask when identifying automation candidates:

What processes do users or customers complain about?
What activities occupy too much staff time?
What activities cause the biggest budget surprises?
What activities cause the most re-work?
What processes are competitors automating?

These questions should provide a good start. But the point is there are simple things that can be automated that can provide excellent benefits. Automation doesn’t have to be daunting; you can start simple. In fact, the more mundane something is, the more likely it can be automated.

Better to automate, than have your skilled people complain about their jobs. Give them something more challenging to do.

Putting IT on a diet! At what point is IT too skinny?

2009-05-30T03:36:00Z

Last week Denise Dubie, a senior editor with Network World, wrote an interesting article titled, Savvy management: Putting IT on a diet. In the article, she interviews Evelyn Hubbert, a Forrester analyst who is well versed in NetIQ technology - you should ask her about us if you have a subscription with them. Evelyn cites a statistic that up to 70% of IT costs go to managing existing systems (presumably meaning that the other 30% goes towards new projects). She goes on to say that IT is "starting to understand the importance of better management in their efforts to get leaner,” and that another area IT managers needs to investigate is software license usage to get leaner.

I certainly don't doubt Evelyn's or Denise's statistics, but I have a lot of friends in IT management who are probably asking themselves, where does all that budget go? The organizations I've met with recently have told me they're past the point of doing more with less. The reductions have been made. Budgets aren’t growing soon enough. Yet they have to deliver on projects now to keep the business competitive. With fewer resources, it's natural to look toward automation, and some smart companies are using IT Process Automation (ITPA) as the solution to deliver. I spoke with a company recently that is doing the workload of what used to take 40 people with 35. This year's savings is $500,000. They have two full time employees now working on automating additional processes because of the success and the list for more automation keeps growing.

Few would argue that automation is great, but it has to be relevant to challenges today and in the future. Many IT organizations will gravitate towards point automation tools (e.g. VMware provisioning), and then have to invest in other automation tools as new needs arise. ITPA is a general automation solution, that may take a bit more customization up front, but eliminates the need for licensing and maintaining yet another automation platform over and over again.

This brings up the second point that Evelyn made about watching software licensing costs. Reducing the software license footprint to match your current asset footprint is a good thing, but even better is to use more of the functionality in the tools you already have so you don’t have to buy new tools. Of course, that takes an investment in training and time (call it exercise), but ITPA is a way to get around that, because ITPA tools are built to understand the functionality available in your current tools like ticketing systems, monitoring tools, provisioning tools, etc. With ITPA, you may use capabilities that you didn't even realize you had, as part of enabling processes. And that is a great way to diet without all the fuss of exercising.

IT Automation Wrap-Up from Interop

2009-05-22T17:22:00Z

As Interop comes to a close, those of you who couldn’t attend might find this information useful. While trade shows around the nation have seen a decline in attendance, Interop ended up being busier than organizers expected. As I mentioned in my last post, IT Automation was a new track this year at Interop, and the discussion around the technology certainly justified its presence in this year’s lineup.

Forrester IT Forum, held down the strip over the same days, seemed focus heavily on IT Automation as well, according to Denise Dubie’s article, “IT automation technology dominates Vegas conferences.”

My own presentation focused on the reduction of operational expenses with IT Process Automation (ITPA), and the turnout filled the room. My main goal was to not only make the business case for ITPA, but to dispel some of the skepticism that surrounds this technology.

I presented the case that management and administration costs have risen faster than other IT costs. This is largely due to IT’s inability to free personnel from supporting legacy systems and applications, requiring ever-higher numbers of personnel to focus on innovation for the business. So, how can we liberate resources from support of low-value but necessary tasks so that they can focus on delivering business-enabling projects?

Answer: IT Process Automation.

As an example, there are events that arise throughout the course of a day that interrupt administrators from working on and completing their projects. Automating a process to respond to these repetitive events (such as disks that fill up) can free personnel to pursue other, more productive activities that impact IT service delivery more directly. .

During my presentation, I discussed the following steps that you can take now to get ready to deploy ITPA and reduce operational expenses:

1. Identify automation candidates

2. Evaluate your process maturity

3. Rank candidates by value

4. Identify needed tools

5. Prepare your staff

A couple of questions came up about retaining personnel (automation raises suspicions of replacement) and how ITPA works with current technology. First, the idea is not to eliminate personnel, but rather better utilize their time with activities that map directly to the overarching business goals. Second, ITPA products are designed to integrate directly with your existing tools so that you aren’t throwing anything away. If that’s not the case – you should be looking elsewhere for your solution provider!

My hope is that attendees left with a bit more confidence in ITPA as a solution to the repetitive pains that plague most IT organizations. My expectation is that we will soon see an increase in automation adoption rates and a resulting decrease in management and administration costs.

If You're Heading to Interop Las Vegas, Check Out Our Activities

2009-05-14T23:48:00Z

The NetIQ team is heading to Interop Las Vegas next week, and I’m happy to have the honor of speaking this year as part of a new track on IT Automation. As I put the finishing touches on my presentation, I’m struck by the fact that automation continues to gain more momentum as we see budgets cut and IT staff members asked to deliver more services without additional resources.

As you know, I believe IT Process Automation is an integral component to helping IT organizations thrive in a down economy. To continue my part as an IT Process Automation evangelist, I will be speaking on the topic on Tuesday, May 19^th (at 2:45 p.m. in the Breakers G/H room) for all those interested. My presentation, titled “Five Steps to Reduce IT Operations Expenses with Process Automation,” is designed to examine the healthy skepticism that still exists over the benefits of IT Process Automation.

While I plan to touch on the different steps you can take to ready your environment for IT Process Automation, I will also discuss several examples of process automation that we’ve seen our customers employ. These processes gave our customers a competitive advantage by helping them reduce their costs, deliver new IT services faster and reduce the errors inherent in manually performed processes.

I am still working on ironing out the fine details of my presentation, and if there are any specific topics that would be helpful to touch on, I welcome the feedback. Following my session, I plan to blog about the questions posed by attendees, and I will share my responses here as well for those of you who can’t make it to the show.

If anyone has plans to attend Interop, however, I hope you will stop by the booth and say hello – we’ll be at Booth 1119. It should be a great week, and I look forward to seeing what’s in store!

Hope for SCOM Users

2009-05-04T22:18:00Z

If you haven't heard the news yet, NetIQ has announced IT Process Automation (ITPA) support for Microsoft System Center Operations Manager (SCOM) with a specific adapter for NetIQ Aegis. According to the analysts at Gartner, Forrester and EMA that I've spoken with, Microsoft has no plans for an ITPA platform, as the System Center team is focused on getting their service desk/ticketing platform out the door. Yet, in our research, we found that SCOM users generally have a wish list of functionality to integrate, automate and extend the functionality of SCOM.

Now you might wonder if NetIQ, as a Microsoft competitor, really has credibility to claim that there is such a need for SCOM customers. Many of you know that NetIQ sold the Operations Manager platform to Microsoft in 2000. In all fairness, Microsoft has made a lot of changes, but much of the platform operates the same way it did back when we sold it. Add to that, the fact that we provide a competitive product that is a recognized leader in Windows systems management and it seems fair to claim that NetIQ understands what it takes to offer effective IT process automation in conjunction with SCOM.

But, we also decided to talk to current customers of SCOM to really understand the need today. We did that in a number of ways, through partners, services organizations, and even our own SEs who recently left Microsoft and joined NetIQ. What we found was that SCOM users are looking for easy ways to:

Integrate with third-party tools such as ticketing systems, other monitoring tools, provisioning tools, and so on, to reduce integration costs and increase operational productivity.
Automate alert enrichment to provide additional information, such as custom server information, to help reduce the time needed for troubleshooting.
Perform validation checks for alerts from Exchange, Biztalk and others to verify them. If they turn out to be false alarms, then the alerts are set to auto resolve and no human support is required.
Reset the priority of events based upon end-user impact as identified by SCOM or other tools, steering focus to high-impact events.
Automate SCOM administration, such as agent integrity checks to reduce administrator workload and the total cost of ownership for Operations Manager.
Drive alert resolution through progressive escalations, state changes and authorizations, reducing unplanned downtime due to missed alerts.

If you use Microsoft SCOM in your IT environment, you owe it to yourself to check out what NetIQ has to offer to address these needs, and we also invite you to attend a web seminar on May 13th to learn more about ITPA and this adapter, and see automation in action. Or you can find me speaking on IT Process Automation at Interop in Las Vegas on May 19th at 2:45pm in the IT Automation track.