Information technology is one of the most demanding industries in today’s rapidly changing world. You would be hard pressed to find any service that does not rely, to some extent, on IT to function.

Even the most basic of agricultural tasks, which would previously have been 100% manual, will now utilize technology, improving productivity and efficiency in the process.

Ten or twenty years ago, your average IT worker was a skilled generalist who could confidently turn their hand to virtually anything that was technology based. In 2021 that is no longer the case. We now rely on narrowly focussed specialists to keep the lights on and the innovations coming.

Even the largest of organizations with the biggest IT budgets will struggle to justify keeping infrequently used specialist skills within their organization.

This means that we need to share these specialists via an outsourcing model, thus providing the best value to our organizations.

Outsourcing: What’s the big deal?

To some people, “outsourcing” is a bad word. It is seen by some as a way to rid organizations of staff, replacing them with contract resources. Any mention of outsourcing is seen as a threat to the internal IT team.

Certainly, outsourcing is not without risk. But I prefer to think of it as an opportunity, one where you are both:

• Letting your own team concentrate on what they are good at.
• Learning new skills from an external specialist.

Outsourcing simply makes sense in a variety of situations. In the case of low-value, commodity IT capability, there are compelling reasons to use external parties as suppliers.

Why set up your own data center, staff it, and maintain it, if this is not your core business?

It is far more sensible to outsource the responsibility in this space to a specialist provider, letting you get on with your own core business, while they take care of theirs.

When you are looking at infrequently used, specialist IT capability, it does not make economic sense to pay for in-house expensive resources who will only be used on rare occasions. Instead, it’s far better to outsource this capability to businesses for whom this is their daily responsibility. They will have more experience and understanding of the systems that you are using.

Successful IT departments will use a mix of insourcing and outsourcing, making best use of what can be scarce resources. The key to success is being able to:

• Coordinate your internal and external resources effectively and efficiently.
• Provide the best outcomes for your organization.

(Read our primer on outsourcing & insourcing.)

The SIAM solution

This coordination is what Service Integration and Management (SIAM) systems are designed to enable.

SIAM is an outsourcing service model drawn from the success of major corporations around the world. The term can be used interchangeably with Multisourcing Services Integration (MSI). It is also sometimes referred to as SIAM/MSI. Any of the above names are appropriate.

At its core, SIAM provides guidance on good practice in managing multiple suppliers of IT services.

(See how SIAM works with ITIL^®.)

In traditionally run IT departments, trained in-house professionals are selected to oversee various functions like network efficacy or database management. These professionals may find it necessary to outsource some requirements to vendors, completing the remaining work in-house.

One example might be an IT department that outsources the implementation of a new database to an external vendor but manages the data, training, and user adoption in-house.

This piecemeal approach can lead to a disjointed vendor management strategy, based on the premise that you can bring vendors in on an as-needed basis to work however they see fit without direction and oversight of in-house IT managers. That approach can be highly problematic—there is no single point of oversight of these vendors.

For example, it’s in no way uncommon to find single vendors having multiple contracts with different parts of a single organization, with varying conditions and costs.

IT Management may elect to outsource all their external work to one vendor. But the trouble is that most single vendor solutions aren’t equipped to handle every IT problem. This means that the vendor may end up subcontracting some work to third parties, which offers the hiring organization:

• Very little transparency
• Very little quality control

It is out of these models that SIAM was born. It’s the strategic process which gives an IT department the framework it needs to efficiently manage multiple vendors to accomplish organizational goals with full oversight over the process and with appropriate quality control measures in place.

Multi-sourcing could solve your problems

Using SIAM to manage a multi-sourced IT capability can resolve many issues faced by today’s IT organization.

If you have, or currently are, experiencing any of the issues listed here, it is time for you to investigate taking a SIAM based approach to your vendor management:

• Unclear delineation of duties among vendors
• Lack of cooperation and coordination between vendors
• Little accountability and no transparency of vendor processes and benchmarks for completion
• Leadership discouraged by lack of innovation among vendors who are eager to fulfill a contract
• Reporting on quality assurance is costly and labor intensive for vendors
• You have a growing need to deliver a number of diverse IT services
• You are seeing an increase in the complexity of the services you need to provide
• You have 24/7 operational needs
• You are seeing an increase in internal and external customer expectations
• You currently have no set standards for measuring vendor performance

If any of these statements sound familiar to you, then it is time to review the way you manage your current pool of vendors, and the SIAM model is a very good place to start.

Ensuring SIAM is solutions-oriented

If you’re going to change your IT outsourcing strategy, you need to ensure you are making a change for the better, not just changing for the sake of change. If you do not take the time to fully understand the SIAM model you plan to employ, you could simply swap one set of problems for another.

It’s important to validate the SIAM models against your own requirements and select the appropriate way of working. If you do not do this you risk running into a number of problems:

• SIAM becomes more costly than the benefit received
• No benefits are being received
• Service quality deteriorates
• The selected SIAM model does not scale appropriately
• The SIAM model you employ causes an increased need for costly company resources

These issues can occur for several reasons, including:

• Lack of consensus and understanding by management regarding SIAM activities, approach and application
• Failure to understand the capabilities of SIAM software providers and the solutions they offer
• Incomplete or absent benchmarks and metrics to determine SIAM success
• Inadequate training of in-house service integrators

Having a clear understanding of best practice for SIAM and the different models that are available will allow you to effectively mitigate any risks that could be costly to your business.

Choosing the right SIAM model

There are four common SIAM models that fit most situations—and you need to select the one that works best for your own situation. That decision will be impacted by:

• The level of SIAM expertise within your organization
• The complexity of the systems you are managing
• The ability and availability of specialist SIAM services

Let’s look briefly at the four SIAM models.

Internal service integrator

In this model, the control of the various vendors remains within your organisation.

This can be a cost-effective model. However, if the person charged with managing this model is not skilled in service integration, or does not have sufficient authority, it is unlikely to provide the expected benefits.

External service integrator

In this model a specialist, independent service integrator is responsible for managing all vendor relationships on your behalf. They will have significant experience in vendor management.

The downside to this way of working is that the cost of employing a specialist company will be high, although the benefits of having a highly experienced, independent management team can be significant enough to make the investment worthwhile.

Hybrid service integrator

This model combines the internal and external service integrator models, with, perhaps, an internal resource managing a group of smaller vendors and a specialist company taking responsibility for your most critical vendor relationships.

This is a common model which may then move to the fully internal service integrator once your own team has built up its knowledge and experience in the SIAM world.

Lead supplier as service integrator

This model will see one of your key suppliers taking over the management of other vendors. This arrangement needs to have a high level of trust between you and your key vendor. Where this trust exists, this arrangement can be a very successful way of working.

Wherever possible it’s useful to consolidate areas of necessity into one vendor relationship.

For instance, instead of hiring nine vendors to service each of your IT infrastructure needs, hire three vendors who each cover three of the requirements. Even if they subcontract the work you are going to enter into a single agreement with each of them that ensures quality standards are met.

SIAM Best Practices

Using good practice allows businesses to safeguard themselves against any potential risks associated with changing their outsourcing strategy.

Create a vendor agreement

Your Vendor Agreement is the binding document between your company and a supplier, that ensures that both:

• Your end user’s expectations are being delivered on
• Your company’s mission is being furthered

Some things to include are:

• Cooperation clauses between vendors
• A service management manual with guidelines
• Key performance indicators (KPIs) that will help determine the success of the vendor relationship

Tracking and reacting to non-performance against these KPIs in a timely manner is critical to success, regardless of which SIAM model you decide to employ.

Build relationships

By building relationships with your vendors you take the experience beyond a transaction and inspire others to focus on your brand’s mission. If one relationship should go awry you have a backup plan with your other vendors who value the relationship you’ve built to complete the work.

A successful vendor relationship must be beneficial to both sides: You need your vendor to be successful. If they are not, your organization will ultimately suffer.

There must be fairness and some level of give-and-take and mutual understanding, as with any relationship, business or otherwise.

(Understand the Business Relationship Manager role.)

Ensure you’re set up for a multi-vendor approach

This one takes a little more finesse. A good start is designating a layer of vendor management that provides input in the decision about which functions to outsource, manages vendor relationships, and implements quality assurance.

This is like Human Resources for vendors.

Select the right tool

Select a tool for your SIAM that has service and performance management. The right tool will make sure there are no gaps that could allow accountability and transparency to be sacrificed.

If selecting among multiple vendors, ensure you understand all the differences between each platform before making a decision.

Switching to SIAM

In the end, each business must weigh pros versus cons and decide what approach is best for their vendor situation and unique IT requirements. Some level of SIAM is becoming essential in today’s complex IT environment, where very few organizations can afford to hold all the required expertise in-house.

For any business that is struggling to come to terms with the complexity of their IT situation, those who are wondering if the output they are getting is providing a seamless, high-quality experience for end users, SIAM is an option worth exploring.

For some who are considering the switch, it may make sense to compartmentalize each component of SIAM before diving in. As mentioned, the biggest issues arise when companies immerse themselves in SIAM, without a deep understanding of it.

A component model allows businesses to take inventory of each necessity along the way at the beginning of a transition to a SIAM provider. It aids leadership in gaining a clear picture of the overall functionality, so everyone is on the same page.

In visual form, a component approach to SIAM might look something like this:

Whatever approach you select, it’s important to understand all the risks, benefits, and resources involved when it comes to Service Integration and Management.

A well thought-out, meticulously planned and executed transition to a SIAM model will provide benefits to your organization, regardless of size or complexity. You will certainly:

• Free up your own staff to concentrate on your core business.
• Save precious resources by only paying for the IT services you actually need, when you need them.

Related reading

• BMC Service Management Blog
• BMC Business of IT Blog
• 10 Best Practices to Avoid Cloud Vendor Lock-In
• Evaluate & Choose ITSM Tool Vendors in 4 Steps
• Choosing IT Metrics That Matter
• IT Budget Trends: How Companies Spend on IT

The concept of a Tiger Team is not new. But it might be just the approach you need in order to solve a problem that is severely detrimental to:

• Your customers
• Your ability to deliver services
• Your company’s reputation and wallet

Let’s take a look at how to use tiger teams successfully.

(This article is part of our IT Leadership & Best Practices Guide. Use the right-hand menu to navigate.)

What is a tiger team?

A tiger team is a group of cross-functional experts brought together to solve a specific problem or critical issues.

According to a 1964 definition, a tiger team consists of:

‘A team of undomesticated and uninhibited technical specialists, selected for their experience, energy, and imagination, and assigned to track down relentlessly every possible source of failure in a spacecraft subsystem.’

These teams had been pulled together in military and other settings for many years but came to public attention dramatically in 1970 when NASA brought together a tiger team who were charged with bringing the astronauts aboard the crippled Apollo 13 spacecraft back to earth alive.

Mission Control during final 24 hours of Apollo 13 mission. April 16, 1970 (Source)

How tiger teams work

You don’t have a pre-determined tiger team that you call together every time you have a critical issue you are struggling to solve. The team that solves one issue is very unlikely to be the same team—with the same skillsets—that solves the next issue.

Instead, a tiger team will be handpicked for the situation you are facing at that time. Participants in a tiger team might include any mix of:

• Internal staff
• Vendors
• Subject matter experts who are not connected to your organisation

Tiger teams will be assigned to investigate possible solutions to unique situations or problems. Any team will be populated with mature experts who:

• Appreciate the criticality of the task they are facing
• Understand what needs to be done
• Work well with others
• Demonstrate strengths including a diversity of knowledge, a single focus/purpose, and organizational agility

Crucially, the people in your tiger team must be removed from the grind of business as usual. You cannot afford for them to be distracted by their day jobs. Their full attention needs to be applied to resolving the issue at hand. (This ensures full focus and maximum efficiency, saving time and money in the long run.)

Once the tiger team completes the assigned task—solving the issue—the team will be disbanded. Its members will go back to their normal roles.

(Explore IT teams you might draw upon for your tiger team.)

Considerations for building a tiger team

It is possible that one tiger team may not be enough. Highly complex problems may require more than one team to resolve.

Using the principles of best practice in problem management, each team should only be looking at one problem—a single object and a single fault. If you discover during your investigations that you are looking at multiple contributing issues, then either:

• Split your tiger team
• Build a new one to investigate each separate cause

(Look at reactive & proactive problem management.)

It is essential that a tiger team can concentrate on their specialist area and not be distracted by other, potentially conflicting, issues.

You must clearly define the result you expect your tiger team to deliver, defining and understanding what “done” looks like. (Remember, done is a relative term.) Tiger teams are expensive resources, so you don’t want them to be wasting time on non-critical issues. Make sure reach tiger teammate understands the boundaries of the problem you are asking them to solve.

At the onset, clearly state the expectations, rules of engagement, and team and project boundaries. If you do not, you may encounter several risks:

• Team members understood the issue differently. This murkiness will hinder any issue resolution before it gets underway.
• The team may start applying short-term fixes, and sometimes multiple fixes at the same time. A common refrain is “Just a second…try it now.” The danger here is that you no longer understand your starting point—the true problem you’re trying to solve, not work around.
• The team gets confused. Every time the team meets, they look at a different symptom, with no strategic direction.
• Lack of resolution. Once the initial emergency is over, people stop attending meetings and the team isn’t always sure what fixed the issue
• The team skips final determinations and lessons learned. The risk here is that if you don’t allow time to document lessons learned or understand the root cause, the issue might not be as resolved as you think it is.
• Scope creep. Scope creep is a real danger. When discussion wanders to other topics, beyond the team’s original purpose, the tiger team will fail to be productive.

(Discover the #1 success factor in any lessons learned or portmortem report.)

Tiger team best practices

Of course, tiger teams aren’t only about defining the boundaries to solve the problem—they require logistics and management.

Some housekeeping tasks that need to be considered when assembling your team:

• Isolate the team in a dedicated space. War rooms are specific spaces for dedicated events and problem-solving (not routine meetings), and it might be just what you need for a tiger team. Of course, make sure everyone in the team has the appropriate access to your war room.
• Cancel all other work obligations. Block off all team members’ calendars with individual all-day appointments so no other meetings sneak in.
• Ensure sufficient wall space for collaboration.
• Allow for breakout spaces for small groups to work together.
• Arrange catering. Keeping your team together during breaks increases collaboration time.
• Locate and have access to all technology requirements, like test environments, additional hardware, smart screens, etc.
• Communicate clearly and with the entire team. Create a team on your messaging app (Teams, Slack, etc.) and add everyone to it. Create an email distribution list, a Jira or Trello board or similar, and a shared documents folder.

When to form a tiger team

One thing that I would urge is to create a tiger team sooner rather than later. Weigh up the cost vs. benefit equation.

How much is the issue you are dealing with costing the business each day—not just financially, but reputationally as well? If you are getting close to the promised resolution time and are not well on the way to restoring service, it is time to get the experts to work.

Of course, not every incident or issue should have a tiger team. But certainly some will require it.

I have worked in an organization that refused to form a dedicated team to work on a major issue…until the pain experienced by the organization and its customers had reached the top levels of management. By that time, so many attempts to fix the issue had been made, further complicating the situation, that it took weeks of concentrated, and very expensive, effort to restore full service.

The entire time this was happening, the organization’s reputation was suffering, and we were being featured regularly in the media as a result. If a tiger team had come together as soon as it was obvious that we didn’t understand the root cause, the path to resolution would have been much easier and faster.

Bringing top internal and external experts together to resolve a difficult issue is not a cheap option. It’s certainly not one that needs to happen for every situation that is proving difficult to resolve.

But, if your organizational reputation is being damaged, or the viability of the business is threatened, do not hold back. The cost, while often high, will be justified.

Related reading

• BMC Service Management Blog
• Incident Management vs Problem Management: Differences Explained
• The Incident Commander (IC) Role Explained
• Roles & Responsibilities in Change Management
• What Is an IT Steering Committee?
• How Service, Business Relationship & Product Management Work Together

I think of business relationship management, agile product management, and service management as a three-legged stool. You know what happens when a stool is not well balanced. It’s not pretty!

In this article, I take a look at each of these viewpoints—BRM, ITSM, and product management—and how they relate to and support the other perspectives.

First, let’s start with how we arrived at this comparison.

How we got here…

In the 20 or so years I have been working in or around IT service management (ITSM), there have been many changes, lots of new ideas and philosophies. We have seen multiple frameworks come and go and many new flavours of the month pass in and out of fashion.

Service management as a discipline has outlived them all.

What’s different now, in 2021? Agile has been part of the landscape for many years, and business relationship management (BRM) became part of our vocabulary more than a decade ago. So, why should they now start being of interest, or concern, to the service management practitioner? If we ignore them for long enough, surely they will, like all the others, just fade into oblivion…

We are living in a complex world. Our business partners expect things to work. When they want new features or solutions, they want them now, not in two years’ time after an expensive waterfall project has come to fruition.

Success in today’s world looks very different, as I’ve previously written. ITSM is no longer the only pathway into the IT function, and the service desk as the “single point of contact” for all things IT has ended.

We need to find a better way of providing the level of care that our business partners expect.

This is a balancing act. We need to take care that each leg is the right length and gives the appropriate level of support in what can be a confusing landscape of competing interests, where we have:

• Service management saying, “We are the single point of contact.”
• The product owners and managers saying, “We are the voice of the customer.”
• Business relationship management claiming they’re the “single point of focus” for business partners.

Surely, they can’t all be right? Or can they?

The role of IT service management

Everyone reading this knows how important effective service management is. But is it still the single point of contact for the entire IT arm of the organisation? I am going to put my hand up and say “No, it is not.”

ITSM is where you turn when…

• Existing services are not functioning correctly.
• Changes are needed to something that is already in production.
• You need access to a service that is in use in the organisation.

Service management keeps the lights on and ensures that business as usual (BAU) keeps happening. If things break, service management is responsible for:

• Getting services back up and running.
• Stopping services from breaking in the first place.

ITSM is the single point of contact for anything to do with existing capabilities.=

The role of business relationship management

In my opinion, the business relationship manager has the perfect job. (I might be biased here as that is now the role I have.) BRMs are not actually responsible for doing anything! That’s not quite true, of course—the BRM practice has many roles:

• Getting out and talking to business partners.
• Discovering the outcomes partners need (or want) to achieve.
• Pulling the right people together to have technology help the organisation meet these outcomes.

The BRM enables the IT organisation to converge with the rest of the organisation, building a productive strategic partnership between these functions. They are the orchestrator, the connector, the facilitator. They help to define the “what”—what do we need to achieve to be successful?

They then connect to the teams that can articulate and build the “how”.

The role of product management

So now we come to our product managers and product owners. This is where we find the “how”. This is where the creative solutions are uncovered to provide the answer to the “what” statements the BRM team have presented. The product teams are the magic in the middle. They:

• Take the ideas and value plans from the BRM team.
• Build a solution around those plans.
• Deliver the end product to ITSM, where it is introduced to the business and the value is realised.

(Learn more about product managers & product owners.)

A well-balanced act, hopefully

Back to our three-legged stool. When the stool’s legs are well balanced, life is good, and nobody topples over.

BRM uncovers ideas, bringing them to the product teams to devise and build solutions, who in turn deliver new capability to the service management team, who supports the organisation to use and extract the value from the IT investment.

But what happens when the stool’s legs are not well balanced? Let’s play it out.

When service management is sub-optimal…

If we have less than optimal service management practices, many areas will not function as they should.

BRMs, who have the ear of your business partners, will inevitably find themselves plugging gaps and making up for processes that are lacking. This dilutes the value of a strategic BRM practice and forces the BRM to work at a tactical level, limiting their ability to seek out opportunities for innovation that can make a difference to the business on a much deeper level.

The BRMs will find themselves becoming a VIP service desk, expected to fix broken tech systems for the senior business partners they are engaging with. This not only limits the strategic impact BRM can have, it also impacts their ability to be a trusted advisor and strategic partner: the BRM has unwittingly come to be viewed as the person who can get IT problems fixed.

Your product teams will also suffer when IT service management is less than optimal. Product owners need service management to feed items into their backlog for service improvement:

• If the ITSM continual improvement practice is broken or inefficient, backlogged items will either not reach the product teams or not be appropriately prioritised or documented.
• Poor incident, problem, and change processes will cause product teams to work on the wrong things, spending too much or too little effort on BAU tasks.

I am sure I am not the only one who has heard comments along the lines of “We are going agile, so we don’t need service management anymore.” WRONG. Instead, what you need is:

• The right sort of service management, with practices and processes that have been adopted and adapted to fit with your new ways of working.
• Strong relationships and trust between product teams and service management practices.

In an agile environment, service management will not look like it did 20 years ago. Life has moved on.

To be honest, the most important part of service management has not changed, and it never will—communicate! Talk to people, inside out outside of your team or function. The more you understand about your business and the other teams that help to deliver the IT capability that makes it tick, the better off you will be.

Service management remains a critical enabler for any business, but it is not the only player. Ensure that your practices are supporting both the business and the other business enablers within the IT function—ensure you are an effective cog in the wheel.

When project management isn’t ideal…

Now let’s look at our product teams. What happens to the other legs of our stool when this part of the IT function is less than optimal?

Firstly, let’s get one misconception out of the way: Agile does not mean unplanned or undisciplined.

Life happens. Unplanned work will need to be done. But this must be kept to a minimum. A good product team will know just what it can achieve in a program increment. The planning around this will give business partners a level of comfort, understanding two things:

• What they will get
• When they will get it

That’s the picture I want to see. But what impacts are we going to see if our product construct is not working the way it should?

Your business relationship managers love certainty. They like to be able to go out to their business partners and say, “The feature you are waiting for will be completed in PI 8, so we can expect to see it in production on this date.” What they don’t like is letting people down! Trust is too easily broken.

In many organisations, the IT function has a legacy of…

• Letting the business down
• Not delivering on time
• Not providing a robust IT infrastructure that enables the organisation to succeed

The BRM is tasked with converging the IT function with the business. Every time a delivery is delayed or does not perform as expected, that convergence becomes harder and harder to achieve. Why should the business trust us with their strategy if we can’t deliver on our promises? The BRM is the holder of those broken promises. It is not a nice message to have to deliver, and harder still if you have to deliver it multiple times.

Again, the key here is communication. We know that dates slip, things happen, and sometimes you need to delay delivery. If this is clearly communicated—as soon as a problem is seen—the message is easier (and less painful) to convey.

That’s all about getting stuff out, though. What about getting ideas into the product owner’s pipeline? Do you have a clear process for accepting items into your backlog? If a BRM gives a product team an idea, do they know what will happen next?

The best ideas for capability uplift or new capabilities are pointless if nobody knows what to do with them once they are defined.

An effective, strategic BRM will be uncovering opportunities to provide business value all the time. The product teams need to ensure that they have a gateway and a clearly defined process for bringing these in to their queues. If that does not exist, we are left with a culture of shoulder tapping to get work done, causing more issues for product teams who are being asked to deal with increasing levels of unplanned work.

Don’t let this happen. Instead, you must:

• Define your processes.
• Articulate them.
• Make sure the rest of the organisation understands and follows them!

Now, how does the ITSM function suffer when product teams falter?

Where BRM needs improved or new capabilities, ITSM needs the product teams to devote adequate time to:

• Keeping the lights on
• Maintaining BAU functionality

When incidents and problems are escalated to product teams, we need to be certain that the needs of our business partners are understood and that their expectations are being met. It is a matter of trust.

Product teams need to:

• Respect the prioritised tasks that have been assigned to them and deal with them appropriately.
• Have planned for an adequate amount of time to deal with BAU work. If they have not, then either current or new functionality is going to suffer as a result.

Understand your own IT environment and how fragile your systems are. One size does not fit all. Different organisations will need to devote different percentages of time to keeping the lights on, so we need to plan for our own unique business environments—no industry average formulas will work!

What about new products coming into production? Do we deal well with those, do we communicate clearly with our service desk teams, change teams, and other ITSM functions? Or do we just throw things over the fence and hope for the best?

To provide the appropriate level of support to business partners who will be using new services, the product team must include service management. A good product team will ensure the ITSM practices that support new products have a clear understanding of:

• What is going to be delivered
• Who it will be delivered to
• What they need to know about the new product or feature

The best IT services in the world will not provide the expected business value if we do not know how to support them. (Did somebody say communicate?)

When BRMs isn’t strategic…

The last leg of the stool we will look at today is our business relationship managers.

Now, in my part of the world, we are only just starting to understand the value that a BRM team can deliver to the organisation. So, for some of you, the full value of the BRM practice is well understood. For others, you may not fully understand the concept of the BRM as a strategic partner.

What happens to our product teams when BRM is not functioning at the strategic partnership level?

BRM is a conduit into the IT function that:

• Brings in value-producing ideas from the organisation
• Looks at these ideas at a strategic level

If the BRM function is not working at the right level, the full value of new ideas will not be realised.

For example, let’s say one business partner identifies a potential business improvement from automating a part of their daily work. A strategic-thinking BRM will look at the idea at an organisational level to see if other parts of the business could benefit from the same or similar capability. Then, the BRM can create a value plan that fully articulates the potential value of a new idea.

When a BRM does not think this way, ideas that are not fully explored at the organisational level will come to the product team. This will cause one of two things to happen:

• The ideas will be discarded as not providing sufficient business value.
• The product teams working in a piecemeal manner. When one part of the organisation sees a new feature delivered to another, they will seek to have the same capability developed for their own business unit, causing additional work, waste, and a decrease in the value of the work being done by product teams.

A well-developed and strategic BRM practice ensures that ideas that reach the product teams have been fully explored and the total business value has been defined.

What about service management—how does the BRM leg of the stool support the work of the ITSM practices?

As the glue that brings the business and technology together cohesively, the BRM will be meeting with senior business partners throughout the organisation. Without a BRM function, many opportunities for improvement may be missed. That’s because BRM has conversations that ITSM doesn’t get to have. Business partners talk to ITSM only when:

• Things are broken.
• They need something.

Compare that to the BRM, who is out there all the time, hearing ideas that can help to improve the way ITSM supports its business units.

The BRM function aims to converge the strategies of the IT function with the strategy of the wider organisation. There should not be an IT strategy that supports the business strategy—there should simply be an organisational strategy. The BRM aims to build a web of trusted relationships, connecting the dots between the business and IT functions.

Communication is the #1 tool

I am hoping that you can see what the main tool that will help us to level the legs of the stool is—communication!

We all need to talk to each other and to understand that we are part of the same team. We are all here to enable to organisation we are supporting to succeed. We all share the same goals:

• To provide business value
• To enable outcomes
• To delight our business partners

We need to be forward thinking. We must understand the goals and strategies of our business and remember that we are not here to play with technology: we are here to meet the outcomes of the business we support, whatever that may be.

Of course, this stool has many more legs that support it. But, when we get these three legs in balance, good things will happen!

Related reading

• BMC Business of IT Blog
• BMC Service Management Blog
• IT Management: Get Started with Help from Two Experienced Joes
• Managing IT as a Product
• Design Thinking, Lean Startup & Agile: What’s The Difference?
• What Is Enterprise Service Management? (ITSM for the Rest of Us)

Agile practices, being adopted almost universally, necessitate faster and earlier testing in the software development lifecycle (SDLC). Bringing development and testing together early is commonly referred to as ‘shifting left’.

Traditional testing

A typical waterfall software development project would have seen testing occur immediately prior to release into production. This meant that when bugs or usability issues were inevitably found, the release would be delayed until these were fixed.

In this model, testing became a bottleneck that seriously impeded the ability of projects to deliver on time.

What’s shift left testing?

The easiest way to explain shift-left software testing is to think of the development cycle as a line running from left to right.

In the old model, testing only came into play on the far right of the line. Recognizing the bottleneck here, we now want to move the initiation of testing as far to the left as possible.

Shift Left is a practice intended to find and prevent defects early in the software delivery process. The idea is to improve quality by moving tasks to the left as early in the lifecycle as possible. Shift Left testing means testing earlier in the software development process.

Why Shift Left?

In the traditional software development model, requirements are kept on the left side of the plan, and the delivery and testing requirements on the right. The problem is that these practices can’t handle changing expectations and requirements, resulting in negative outcomes for the business such as:

• Increased costs
• Increased time to market
• Unexpected errors

Cost alone is a very strong incentive for shifting your testing to the left. Estimates indicate that over half of all software defects could be identified during the requirements phase, with less than 10% emerging during the development phase of the lifecycle. The cost of resolving these defects works in reverse:

A defect that is removed after the product has gone into product will cost around 100 times more than one that is identified and removed during the requirements phase.

Research from the Ponemon Institute, in 2017, found that if vulnerabilities get detected in the early development process, they may cost around $80 on an average. But the same vulnerabilities may cost around $7,600 to fix if detected after they have moved into production.

The Shift left approach emphasizes the need for developers to concentrate on quality from their earliest stage of a software build, rather than waiting for errors and bugs to be found late in the SDLC. Shifting left enables product teams perform daily tasks like:

• Testing
• Providing feedback
• Reviewing changes and progress

Is Shift Left always appropriate?

A Shift Left testing approach may not always be able to deliver optimal performance and functioning in a real-world environment. In such situations, a Shift Right testing strategy may help to:

• Enhance customer experience
• Provide scope for implementation of test automation
• Ensure better test coverage

Shift Right initiates testing from the right, i.e., post-production. In this Shift Right practice, you’ll test a completely built and functioning application to ensure performance and usability traits. Reviews and feedbacks from targeted users further help in enhancing the quality of the software.

An important characteristic of the Shift Right approach is a willingness to:

• Validate a hypothesis by trying out new solutions
• Collaborate with customers to determine what is working (instead of working from assumptions)

Continuous feedback from users may help in responding better to software failures.

How to move to Shift Left

There are some key strategies that will help you shift left with your software testing:

Demand planning

Test analysts will engage with business and operational stakeholders, providing a forward view of demand. Having this view enables you to—ahead of time—plan and finalize:

• The budget
• Resourcing
• Test strategies

Demand planning is an integral part of the shift left approach and provides a starting point for all other activities in the test lifecycle.

Static testing

Static testing is carried out in the early cycles of the project, and includes validation of requirements and design. The purpose of static testing is to find defects early in the life cycle that could prove to be very expensive to remove in the later phases of the project.

Use appropriate checklists to verify and validate requirements and design. Log defects into a defect management tool.

Unified test strategy

This is an overall, high level strategy for testing end-to-end—from unit testing through user acceptance testing (UAT), operational readiness testing (ORT), and post-deployment testing. The strategy will cover all phases of quality control, defining clear responsibilities.

A unified test strategy allows you to analyse dependencies on environments, stubs, automation, and test data—ensuring that the respective teams can fulfill the needs.

Risk-based analysis

Risk-based analysis is carried out to determine the impact and likelihood of failure for each test scenario. This approach is used for functional, non-functional and regression types of testing.

Once the test cases are established, decide the priority for the test cases based on the finished analysis. Discuss the impact of failure with the business analyst or designer. Determine the likelihood of failure from the development team.

Benefits of a shift left approach

There are several benefits that can be obtained by adopting a shift left strategy. Here are some of the most important:

Automation

Shifting left gives a greater ability to automate testing. Test automation provides some critical benefits:

• Much fewer human errors
• Increased test coverage (multiple tests can be conducted at the same time)
• Ability for testers to focus on more interesting and fulfilling tasks
• Fewer production issues

Increased delivery speed

Earlier means faster. When you find defects earlier in the production cycle, you can also fix them a lot faster. As a result:

• The time between releases can reduce significantly.
• The quality of software improves.

Increased satisfaction

Faster delivery of software with less defects is a major benefit of the shift-left approach.

If nothing else convinces you that this is a good move, then the smiles on the faces of your business partners should be all you need.

Learn from the choices Humana made when selecting a modern mainframe development environment for editing and debugging code to improve their velocity, quality and efficiency.

Related reading

• BMC DevOps Blog
• What Is Continuous Testing?
• Load Testing, Performance Testing & Stress Testing Explained
• Testing Frameworks: Unit Tests, Functional Tests, TDD & BDD Explained
• What is Parallel Testing?
• Patch vs Hotfix vs Coldfix vs Bugfix: Differences Explained

DevOps has dramatically increased how quickly you can deliver new features to the market. But with this speed comes new security risks—this is where DevSecOps comes into play.

(This article is part of our DevOps Guide. Use the right-hand menu to navigate.)

Overview of DevOps & SecOps

DevOps and SecOps have some key similarities. For everyone to have a deeper understanding of other aspects of the project they are working on, both DevOps and SecOps:

• Emphasize the importance of collaboration
• Promote the use of cross-discipline teams

This enhanced insight provides team members with a unique perspective that empowers them to:

• Focus on their tasks
• Consider how their work will impact the work of teammates

Operational intelligence is a constant concern for the teams as they look to enhance their understanding of each system and its vulnerabilities.

SecOps tools feed teams constant streams of insightful data that empowers them to maintain security standards while achieving continuous compliance. Yes, this intense focus on security can result in slower deployment rates. But that extra time provides high levels of security for increased stability and mitigated risks.

What is DevSecOps?

Marrying SecOps and DevOps gives us the tools to go faster—while still maintaining safety. DevSecOps refuses to accept that the speed and safety are mutually exclusive.

DevSecOps is about creating a culture where security is a part of everyone’s job, not just the people specifically working in security roles. Security needs to be at the top of every developer’s mind as they build, test, and release features to production.

Bill Gates (reportedly) shared this very message in a 2002 Wired article:

“When we face a choice between adding features and resolving security issues, we need to choose security”.

The faster we move, the truer this becomes.

When we prioritize code creation above security testing, Parkinson’s Law dictates that development work will consume the time up until the release date. Parkinson’s Law says:

“Work expands to fill the time available for its completion.”

This normally means that less thought than necessary is given to security during the development process. If the release date is to be kept, often there is no time left to fix security issues.

Remediation of security concerns, identified late will see the production release date delayed, displeasing the development team and business owners alike. This can lead to dev teams and line of business owners circumventing the IT security team, shipping code to production with or without security scans, regardless of the results.

We cannot afford for security checks to be the final piece of the development puzzle. When security flaws aren’t discovered until the 11th hour or after release, you will have reputational and financial damage—as too many businesses have demonstrated, to their peril.

DevSecOps moves the responsibility for security, ensuring it is fully integrated into every stage of the development journey, continually delivering security throughout the software development process. It achieves this goal through a combination of new tools and processes that enhance security of both the application software and the cloud resources which these apps use.

How DevSecOps works

There aren’t steps in some process you need to achieve in order to “be DevSecOps”. Instead, you’ll want to incorporate two significant practices into your development practice.

1. Run early, frequent security checks

In order to secure the application software itself, run security checks much earlier and more frequently during the software development process. The earlier you catch vulnerabilities, the less dramatic and expensive those violations are to resolve. Waiting until release will just leave you nervous and unprepared.

By continuously delivering security alongside the continuous delivery of software, you’ll identify security problems before they become hopelessly entangled in the application and therefore more difficult, and costly, to resolve.

For example, when an application developer checks-in a new code snippet, a scan can be automatically initiated at build time to check for known vulnerabilities, such as those which might originate from the use of third-party libraries.

Performing early, automatic scans ensures that you’re testing both functionality and security throughout the development cycle. The continuous delivery of security makes security scans far less disruptive than the old style ‘big-bang’ security scan at the end of the just prior to delivery. Just as they would have fixed a compile error found during automated testing, the developer can fix a discovered security issue as soon as it is flagged. In this way DevSecOps ensures that far fewer application vulnerabilities find their way into production.

2. Manage cloud resources for security

But security checks do not start and finish here. Most applications are now delivered using cloud services and resources such as:

• Storage
• Serverless compute functions
• Database searches

The number of these options provided by cloud service providers can easily number in the 100s and each of these must be correctly configured, by the customer, in order to be secure.

Gartner predicted that, through 2020, 95% of cloud breaches would result from the customer’s action or inaction. For example, misconfiguring permissions of cloud storage. A quick online search of cloud data breaches over the last 12 months proves that prediction accurate.

As developers ship incremental application enhancements at a weekly, daily, or even hourly continuous delivery cadence – and where IT Operations provide self-service resource provisioning and configuration to those developers – they must put mechanisms in place to manage the security and regulatory compliance of all these cloud resources.

Benefits of DevSecOps in your company

Embedding a DevSecOps practice into your product development will:

• Ensure that security and compliance scans are integrated into DevOps processes
• Find and fix security and compliance concerns in cloud services

Best of all, DevSecOps will allow you to achieve these ends at a pace that mirrors DevOps. The business will innovate more quickly because security is integral to the process, not a hindrance to it. The result will be less risk of data breaches, more secure applications, and continuous security monitoring of cloud resources and services.

Implemented well, DevSecOps can deliver a sustainable competitive advantage, minimizing company exposure to the reputational and financial risks delivered by security breaches.

Related reading

• BMC DevOps Blog
• BMC Security & Compliance Blog
• DevOps Guide, a series of DevOps articles
• SecOps vs DevSecOps: What’s The Difference?
• SecOps Trends of 2020

As I read the book The Phoenix Project, A Novel About IT, DevOps, and Helping Your Business Win, by Gene Kim, Kevin Behr, and George Spafford, for the first time in 2013, I found myself looking around the office to see if I could spot the cameras that had quite obviously been recording the trials and tribulations of our IT development adventures.

I think that just about every IT professional reading the book will have had the same suspicions.

The difficulties being faced by Parts Unlimited, the fictional company at the heart of the book, are sadly familiar to many, if not the majority, of IT professionals. But don’t be fooled—this is not a book only for those of us who work in technology.

The Phoenix Project should be compulsory reading for all business leaders as it gives a very clear vision of how to deliver real business value through IT capability.

(This article is part of our DevOps Guide. Use the right-hand menu to navigate.)

The Phoenix Project synopsis

Parts Unlimited is a company in peril. Legacy IT systems, poor communication, badly managed change, and a lack of knowledge sharing. These factors all contribute to the company falling rapidly behind their competition in the auto parts market.

Bill Palmer is our protagonist. At the outset, he is promoted to the role of VP of IT Operations, having been happily working as the Director of Midrange Technology Operations. Bill is not convinced that he wants this challenge, given the current issues being faced by the company. But, if wants to stay employed, he has little choice in the matter.

Bill’s first challenge is to rectify a payroll system failure so their employees can be paid. On top of this major incident, he is charged with managing the deployment of the Phoenix Project, a huge IT project that the company is hanging all its hopes of turning around the downward spiral it finds itself in.

Business as usual demands, unclear processes, and unrealistic business expectations mean that Bill has a thankless, almost impossible job. Working late nights, weekends, forsaking any hope of having a work-life balance, he does his best to deliver. Bill quickly realises that this will be impossible given the current way of working at Parts Unlimited’s IT department.

DevOps: A new way of working

Reading this book for the first time in 2013, the concept of DevOps was rapidly growing in acceptance and delivering exceptional gains in IT value delivery. But it was still relatively new and, for many, a step too far.

The DevOps ideas of failing fast, accepting failure as a good thing, and pushing constant code delivery to production system were frightening concepts at the beginning of the decade. Fast forward to 2020 and DevOps, Agile, and other similar ways of working are accepted practice in organizations ranging from small start-ups to mammoth government institutions.

The Phoenix Project paints a picture that those both within and outside of the IT organization can clearly understand. The novel shows just how DevOps can:

• Improve the value delivered by IT
• Allow organizations to react quickly and effectively to market pressures

No quick fix

The Phoenix Project does not give anyone cause for unrealistic expectations. The story shows just how painful change can be and illustrates that things are not going to turn around overnight. But the novel excels at showing just how much value a DevOps mindset and way of working can deliver when given the chance.

The three authors showed the DevOps journey for Parts Unlimited in story form, with recognisable characters, plot twists, failures, and successes. The story allows the reader to see just how this way of working can be applied to a real organization with all its imperfections, different personalities, and cultural challenges. Change takes time, it can be painful, and not everybody will survive the journey.

Through Bill’s advisor Eric, we are introduced to:

• The theory of constraints
• Lean thinking
• Agile methodologies

We learn how these have impacted manufacturing operations. With guidance, it dawns on Bill that these ideas can have the same positive impact on IT development and operations.

Here is Gene Kim, one of the authors, describing the three ways (principles) of The Phoenix Project:

1. Flow
2. Feedback
3. Culture of continuous learning

A story to be shared

The lessons learned by the characters in The Phoenix Project and the transformational possibilities presented by moving to a DevOps way of working need to be shared—not just with people working within IT. The presentation of the DevOps journey in novel form, rather than as an academic and theoretical textbook description of how to adopt DevOps, makes the subject accessible to a far wider audience.

While the novel is never going to win The Booker Prize, it is an enjoyable read with likeable characters. Best of all, it manages to humanize the theory behind DevOps.

The book clearly shows the impact DevOps can have on any organization, without making it seem like a magic wand that will magically transform your business. The novel:

• Realistically portrays the cultural and personality challenges that will inevitably threaten to derail your efforts.
• Gives valid examples of strategies on how to overcome these challenges.

Whether you are just thinking about embarking on a DevOps transformation, are some way along this journey, or are fortunate enough to have been part of a successful transformation, I strongly recommend reading The Phoenix Project. Once you’ve finished it yourself, drop a copy on to the desks of your business leaders.

The more we share this story the better!

Related reading

• BMC DevOps Blog
• DevOps Guide, a series
• Guide to Tech Books & Talks
• Lewin’s 3 Stage Model of Change
• Organizational Change Management (OCM): A Template for Reorganizing IT

IT asset management (ITAM) is not a project. You do not do it once and expect it to be finished. ITAM is a practice that needs to be nurtured and continually improved if it is to provide your organization with the value that it can—should—deliver.

Here’s what I often see: organizations beginning ITAM reactively, in response to an incident they have experienced. But, when that issue is resolved, the organizational focus on ITAM is deprioritized until the next incident. Then the project starts all over again. This constant rebooting of ITAM is never going to deliver its true potential value.

In this article, I want to share how ITAM goes wrong for many organizations. And then I’ll share my 10 best practices for making asset management a valuable, ongoing practice.

How ITAM goes wrong

My first exposure to this way of working was some 15 years ago. A lease refresh meant we had to find 1,000 Windows terminals. These were scattered in locations around the country—we had absolutely no idea where. It took over six months to account for around 80% of these assets. The company was penalized for late returns and missing devices. As part of the recovery exercise, we catalogued all the devices we found, thinking that the next lease refresh would be much simple. And it was.

But fast forward two years when 2,000 devices needed to be returned. The asset register was found to be woefully inaccurate. Devices had been moved, swapped out, or were just plain missing. The whole process of cataloguing devices had to start over from square one.

Imagine how much better things could have been had an efficient ITAM practice been developed and maintained in the preceding two years.

I know that this organization is not alone in this. Ask anyone working in ITAM why their company is investing, and they will most likely tell you about an event that finally brought the need for IT asset management to the attention of their management:

• Perhaps it was a failed audit resulting in a big bill from Microsoft or Adobe.
• Maybe there was a sudden need to apply patches on systems that were spread far and wide to ensure continued credit card processing capabilities (a common Payment Card Industry requirement).

There will be many reasons for the initiation of ITAM in an organization, but I have found few that established the practice proactively, rather than in reaction to a negatively impacting event. This needs to change. Let’s try shutting the stable door before the horse bolts!

10 steps to asset management success

Do a quick calculation on the value of the software and hardware that your IT organization is responsible for managing and protecting. That calculation will only give you the basic, physical costs of these items. It pays no attention to the value of business that these assets facilitate. This should tell you that ITAM is a fundamental practice that you need to initiate, maintain, and improve.

ITAM deserves your full attention. Don’t wait for a costly incident to kickstart the practice. Meet the challenge head-on and avoid the reputational and financial consequences that poor, or non-existent, ITAM can bring.

Where do you start? Establishing ITAM is a major undertaking, and I wholeheartedly recommend a one-step-at-a-time approach. Here are my 10 ITAM best practices, broken down into steps:

1. Enroll an active, visible executive champion

Find and enlist an executive sponsor who will actively and visibly champion ITAM. As with any organizational change, it’s unlikely you’ll succeed without a critical executive sponsor supporting your efforts. Better still, have more than one.

Without this, most ITAM initiatives fail or fade away as priorities and budget shift. A champion can also help evangelize the value ITAM delivers. Communications with management/understanding the value will keep the project funded.

Your ITAM project has to drive value…and be able to prove it.

2. Include your ITAM team from Day 1

Organize your ITAM implementation team thoughtfully. Bring them in at the beginning and allow them to build the practice from the ground up. If people are handed a process, they may follow blindly.

When people are involved in the process—not simply told how to execute it—then they are invested in it and more likely to help evolve and improve it over time

3. Start with a pilot

Don’t try to do everything at once! A big-bang approach is almost certain to fail. Pick a manageable pilot, work on that, test the process, and improve before extending it to other areas.

The Plan Do Check Act (PDCA) Cycle 

4. Define critical assets

Define the criteria for what constitutes a critical asset. It may be a specific type of hardware. It may be certain software titles. Discovery tools are going to give you a huge asset list. Some assets will require more oversight or management than others.

Making an early decision on what assets deserve full attention will be critical to your success. Why? Because it will stop you from being overwhelmed by the data that you are delivered.

5. Use a lifecycle-based approach

Follow a lifecycle-based approach to ITAM—don’t try to reinvent the wheel. IT asset management starts from the time the request for purchase is made and ends after a device is deprecated (reclaiming software licenses and maintaining the historical asset information, of course.)

6. Decide whether to use a CMDB

Do you have a CMDB? It’s not necessary for all organizations, but it can be a useful way to:

• Manage configuration items (Cis), including IT assets
• Understand how CIs and assets are interconnected and what services they support.
• Normalize data from multiple sources.

Be thoughtful about what data you choose to feed the CMDB. While it can be an important single source of truth, it doesn’t need to contain every piece of data you have. Only include what adds value.

7. Automate

Automation will improve your ITAM practice. Wherever you can introduce automation, do it. Constantly look for new opportunities for automation as technology in this area is developing almost daily.

Whatever you are manually or repeatedly doing today, ask yourself, “Can this process be automated?”  Odds are the answer is “yes.”  From patching, to application deployment, to reporting—there are many opportunities to set it up once and forget it.

8. Exploit your data

Are you making the most of the data you have collected? Consider who in your organization may benefit from ITAM data, or from the access to manage device changes in an automated or remote fashion.

One of the most common integrations is with the service desk. Integrating ITAM data with the service desk can:

• Result in fewer escalations
• Automate self-service fulfillment for certain requests
• Increase the overall satisfaction rate for both the business user and for IT.

Change management can also benefit from the asset data, ensuring that changes do not result in unplanned outages or other issues that could impact critical services or business users.

9. Know your software licenses

When it comes to software license management, knowing what you are entitled to have deployed is critically important. More often than not, organizations fail software audits for over-deployment because they can’t prove exactly what they have the right to have deployed.

Don’t guess here. Make sure you have the license documentation. Make sure your ITAM processes compare deployed instances with this information. This will ensure there are no nasty surprises in store when the software auditor comes calling.

10. Gather feedback for continual improvement

Allow for a feedback mechanism to facilitate continual improvement. Plan for process change and evolution. The longer you run and the more you integrate ITAM across your environment, the more you will learn.

And the one thing that ITAM will teach you is that everything is always changing—IT is one of the least static environments out there. If you are managing something that is constantly changing, odds are you will need to change how you manage right along with it.

Nurture your ITAM practice

These ten practices are just a starting point, remember that ITAM needs to be constantly fed and nurtured. Neglecting your ITAM processes, even for a short period of time will reduce the value of the entire practice. An incomplete or inaccurate dataset can cost you more than having no data at all.

Additional resources

For related reading, explore these resources:

• BMC Service Management Blog
• Software Asset Management: Mistakes, Truths & Best Practices in SAM
• What Is ADDM? Application Discovery & Dependency Mapping Explained
• Lewin’s 3 Stage Model of Change Explained
• 7 Ways to Put Automation Everywhere Into Practice for the Enterprise

If your help desk is not employing every possible option for automation that’s available, you are missing out on opportunities to:

• Improve productivity
• Increase customer satisfaction

With readily accessible tools to automate common, repeatable tasks undertaken by the help desk, I find myself shaking my head when I see so many—particularly in small to medium businesses—that have still not taken advantage of available technology solutions.

Here, I’ll introduce you to help desk automation, from why and how start to building your investment case to how to choose automation tools.

Your help desk’s current state

Do you still manually reset passwords and unlock accounts? Do you spend time assigning access rights to folders and applications? Do you manually assign and prioritise incidents and service requests?

If you do, I have one question: Why?

Automating these tasks removes the drudgery from your help desk analysts and allows them to spend more time resolved more complex queries, meaning they can get customers back to work faster as well as giving them far better job satisfaction. Nobody wants to spend their days clicking on ‘unlock account’ buttons and listening to customers explain why they have forgotten their password for the fifth time this year.

Why do organizations—of all sizes—continue to use manual processes on their help desks?

The answer you will often get is that these tools are expensive, and they cannot justify the investment. Unfortunately for them, that is not a valid argument. The outlay required to automate basic tasks has a rapid return on investment (ROI).

Every day that your help desk depends on manual workflows, you risk losing:

• User satisfaction, confidence, trust
• Time that could be spent on direct assistance, not admin drudgery
• Energy that could be directed toward learning and skills improvement
• Issues and projects that fall through the cracks
• Knowledge and fixes that are not shared with the team
• Market reputation

Ultimately, all these inefficiencies cost your company money and your well-earned reputation.

Prioritize automation

If you want to improve the value your help desk offers to the business, then automation needs to be at the top of your ‘to do’ list. Why? It will allow you to:

• Use your team’s skills more effectively
• Get a grip on heavy or spiking workloads
• Accelerate issue resolution to please users
• Look like a help desk hero to management

Automation can help your team stay lean while handling larger volumes of tickets with ease. In other words, automation helps you work smarter, not harder.

Benefits of help desk automation to build your case

There are many benefits from employing automation on your help desk. These five benefits, however, stand out for their clarity in convincing top leadership that you need to prioritize automation on the help desk—ASAP.

1. Faster response times

Help desk teams are judged by how quickly they respond to and resolve issues. Being able to quickly resolve issues will greatly improve customer satisfaction.

Workflow automation and orchestration can significantly improve incident response times and problem resolution by incorporating predetermined if, then capabilities. In other words, if you receive a request like this, then do this specific task. For instance, if the help desk receives a call about a printer problem, workflow automation can:

• Determine the type of call.
• Route it to the right person.
• Send an automated response to the user.

Most automation systems also provide some way of allowing users to submit their own tickets via a web portal or email, thus reducing calls to the help desk while speeding up routing—a two for one benefit.

 2. More accurate reporting

Automating workflows improves the accuracy of help desk statistics by avoiding human errors and inconsistencies in data entry. It also relieves managers of the manual work required to collect data and correct errors. Field defaults, required fields, and auto-routing rules are all tools to ensure every incident reported is handled properly and in precisely the same way.

Understanding how your help desk is currently performing will give you the information you need to plan improvements.

3. Improved user communication

One thing that annoys customers, perhaps more than anything else, is a lack of communication. When help desk analysts are busy trying to resolve incidents or fulfil service requests, it is easy to neglect customer communication.

Automating standard customer communications will mean that you can keep customers informed with little or no effort required from support staff. Automating call notifications, SLA escalations, and call resolution emails will:

• Ensure that your customers understand what is happening with their calls
• Help to manage their expectations

 4. Skyrocketing productivity

When you can resolve incidents faster and fulfill requests more efficiently, users get back to work faster. This increases productivity and ultimately improves the bottom line for the business.

5. Increased staff satisfaction

Automation of mundane, repeated tasks frees up help desk team members to concentrate on more challenging work. This will increase their job satisfaction and motivation, reducing the cost of higher turnover.

Choosing help desk automation solutions

Help desk software solutions offer powerful help desk automation functionality based on customizable business rules. When it comes to automation in help desk software, make sure you’re getting these capabilities:

• Automatically capturing and logging all incoming requests
• Automatically assigning each issue to a specific help desk technician (or group of technicians) based on skill routing
• Automatically notifying the technician that a new task has been assigned
• Automatically prioritizing issues according to rules (i.e. severity, system, person reporting)
• Automatically applying due dates and routing based on configurable service level agreements (SLAs)
• Providing tools to document successful fixes for issues so they can be leveraged later
• Creating and automating workflows to deal with processes such as user onboarding
• Documenting communication with the user
• Automatically notifying users of issue resolution or escalation
• Automatically surveying users after their issue is resolved to gauge satisfaction levels
• Generating reports based on issue-related and service-related metrics and automatically sending these to stakeholders

Additional automation will allow you to process simple requests without any human intervention, such as:

• Password resets
• Folder creation
• Permissions

No question on automation

If you can automate, you should automate. Initial investment for technology solutions to facilitate automation will quickly be returned by way of improved efficiencies, reduction in errors, increased business productivity, and higher levels of customer satisfaction.

Additional resources

For more on this topic, explore these resources:

• BMC Service Management Blog
• Service Desk Automation: Are You Missing Opportunities?
• 7 Ways to Put Automation Everywhere Into Practice for the Enterprise
• What are Service Orchestration and Automation Platforms (SOAPs)?
• 5 Metrics & KPIs All Service Desks Need
• SLA Best Practices for ITIL, Help Desk & Service Desk

Is your service desk consistently delighting your customers? Or, if they had a choice, would they be going elsewhere for their IT support? Is your knowledgebase or service desk team the first place your customers think to ask for advice, or do they head straight to Google and online forums for advice?

If you don’t know the answers to these questions, you need to first ask yourself, “How do I find out the answers to these questions?”

There’s more to creating a world-class service desk than embracing the right tools and principles. To make sure your vision is translating into reality, it’s essential to measure the effectiveness of your service desk in the areas that matter most for efficiency, effectiveness, and customer satisfaction. There are endless key performance indicators (KPIs) to choose from, some more meaningful than others.

In this article, we will explore the most important measurements you should be paying attention to. These are basic metrics that every service desk should track. Only once you get these right can you start adding additional measurements—the icing on the cake—but I caution: you need to get these basics in place first.

1. Incident reassignments (Increase/decrease)

Incidents and requests that are moved among support teams take longer to resolve. Getting assignments right the first time will save time, increase productivity, and improve customer satisfaction. Utilising automation and artificial intelligence to direct calls to the right team can help you improve in this area.

• Reporting frequency: Monthly
• Measurement procedure: Count of incident re-assignment per ticket
• Target range: < 5

2. Incidents responded within target (Increase)

Your responsiveness to reported incidents is a critical factor in both customer satisfaction and the credibility of IT among business users. Letting your customer know that their issue has been logged and somebody is looking at it is a good start.

When this metric is static or increasing, that’s generally positive. Any significant or prolonged decrease might require changes. Make sure you’re meeting expectations by hitting defined service level targets, and work to continually improve your success rate.

• Reporting frequency: Weekly/Monthly/Quarterly
• Measurement procedure: Incident Responded within Target/Total Resolved Incidents * 100
  • This should be measured by Priority where Critical is 100%
• Target range:
  • > 95% = Green (Good)
  • 90-95% = Yellow (Acceptable)
  • <= 90% = Red (Concern)

3. Incidents resolved within target (Increase)

The primary function of the service desk is to ensure that customer issues are resolved as quickly as you’ve promised. This is different from the above metric, which focuses on response time. This one is about resolution time.

An increase in this metric validates your core effectiveness as a service desk: you’re resolving incidents within defined service level targets.

• Reporting frequency: Weekly, monthly, and/or quarterly
• Measurement procedure: Incident Responded within Target/Total Resolved Incidents * 100
  • This should be measured by Priority where Critical is 100%
• Target range:
  • > 95% = Green (Good)
  • 90-95% = Yellow (Acceptable)
  • <= 90% = Red (Concern)

4. Tickets reopened by customers (Decrease)

Nothing annoys customers more than having their tickets closed when the incident is still active, or the fix turns out to be temporary. Here, a decreased in reopened tickets is a good thing—customers agree you’ve satisfactorily solved the issue. An increase here could indicate some anomalies, but too many means you’re missing something major.

• Reporting frequency: Weekly or monthly
• Measurement procedure: Percentage of tickets reopened at customer’s request
• Target range: < 2%

5. Aging incidents by priority (Backlog decrease)

Your backlog should keep you up at night—it might well be costing your business users some sleep, too. Clear out aging incidents (defined as those more than 14 days old) to keep users satisfied and avoid high support time and cost.

If your backlog is climbing, you need to understand why and do something about it. It could be a resourcing issue, or perhaps your team needs training in new services that have been introduced recently. When tickets are sitting in your backlog for extended periods of time, customers will rapidly become unhappy with the service you are providing.

• Reporting frequency: Weekly, monthly, and/or quarterly
• Measurement procedure:
  • Aging: (Today’s date – submit date)
  • Untouched tickets: (Today’s date – date incident last modified)
  • (Aging incident count / total open incident *100)
• Target Range:
  • Overall < 30%
  • Or by priority level
    • Critical: 0%
    • High: < 5%
    • Medium: < 10%
    • Low: < 15%

Beware watermelon metrics

The metrics in this list are a very basic starting point that will help you to understand the effectiveness of your service desk function. Get these right and consistently within SLA requirements and you will be on the way to providing a service desk that meets your customer needs.

I would, however, caution you to beware of “watermelon metrics”. At the same time as you are measuring these quantitative metrics, you need to be measuring customer satisfaction.

If all the metrics we have described in this article are showing as green, but your customers are not happy, you will need to reassess what you are measuring and what the results are telling you.

Above all, listen to your customers. At the end of the day, their satisfaction is the only metric that matters.

Additional resources

For related reading, explore these resources:

• BMC Service Management Blog
• Service Desk Mission and Vision Statements: The Basics
• Creating a Strong Service Desk Culture
• Pitfalls of Choosing the Wrong IT Service Desk Metrics
• Top ITSM Metrics & KPIs: Measuring for Success, Aiming for Improvement
• Choosing IT Metrics That Matter

As organizations increasingly rely on the applications they use, whether through on-premise installations or cloud subscriptions, it is essential for you to understand:

• What you have
• Who is using it
• How it is supported
• What you are paying for

Well-developed and clearly understood software asset management (SAM) processes are your key to getting value from your software investments. SAM also ensures that you are neither using more software licenses that you are paying for (leaving you open to legal consequences), nor less, which means you’re paying for more than you need.

Let’s introduce software asset management, including:

• The concept
• Common challenges
• How to avoid them
• Best practices for choosing SAM tools
• Additional resources

What is software asset management?

Software asset management is an ongoing IT practice. Like the overarching practice of IT asset management (ITAM), the primary end goals of SAM are usually to:

• Ensure compliance
• Mitigate risk of penalties
• Avoid security breaches
• Reduce risk of unplanned costs
• Optimize investments (i.e., lower costs)

Software is a huge, ongoing financial investment for all organizations. The ability for departments, or individual users, to acquire software licenses through software as a service (SaaS) providers means that it can be difficult to understand what software is being consumed by your organization, much less control the financial and legal implications of software use.

To demonstrate this challenge, the image below indicates a variety of asset types you’ll need to manage. Many of these will fall within your SAM practice:

This means that SAM is more important than ever, but also more difficult to do effectively due to the decentralization of software procurement. There is no easy button for asset management—regardless of the tools and content.

I have heard SAM referred to as a “dark art”, which implies SAM is much more than a tool or technology. It requires skilled resources and the right technologies to cover all platforms, titles, and license models within scope.

Common SAM mistakes

Many organizations start with unrealistic expectations because they have not been exposed to the challenges inherent in building a SAM program. Therefore, to build a successful and sustainable SAM program, start with a critical understanding of the most common challenges.

There are many mistakes organizations make when setting up a SAM practice. These three are the most common mistakes I come across:

1. Setting unrealistic expectations when planning or maturing a SAM program.
2. Not identifying a roadmap, a phased approach with a clear, prioritized list of requirements.
3. Not performing the proper due diligencewith SAM vendors to fully understand what you can do out-of-the-box vs. what requires customization, professional services, or consulting. This can have a significant impact on cost.

Any one of these three can delay or even completely derail a SAM project. Not in the list above is something that is almost more problematic—so here’s a fourth mistake:

4. Expecting a tool to do all the work for you. As the saying goes: “A fool with a tool…” A SAM tool can do a lot of heavy lifting for you by discovering software and enumerating license usage. But no single tool is going to provide all the answers you are looking for. If you do not design the SAM practice well BEFORE implementing a tool, then you are very unlikely to have a successful outcome.

Challenges and fundamental truths of SAM

Too many organizations ignore or discount these challenges. The value of their SAM practices suffer as a result. The above mistakes are frequent challenges, often due to organizations:

• Jumping in too quickly without any experience
• Setting unrealistic expectations
• Not defining a focused scope with a phased approach

The list below are the most common SAM challenges—and their truths.

No single tool/solution

No single tool can discover all software and the data necessary to measure all license models. I’ll say it again: There is no such thing as an out-of-the-box SAM solution for all software.

Some tools are better with certain vendors and/or platforms than others. Some vendors bundle and/or partner with other technologies and content to broaden their coverage. For example:

• On the discovery front, some software requires usage information and/or specific configuration settings (e.g., Oracle database licensing).
• On the licensing front, the product use rights (PUR) can be very complex—think MIPs and points-based licensing.

On either front, very specialized knowledge is required to create and maintain this level of specialization. This is just one factor as to why a phased approach is essential for success.

Content drives automation

In today’s SAM world, content is a critical success factor. Without it, the onus is on the customer to create and maintain it, which is not practical unless the scope is very limited. Content covers a wide range of areas including, but not limited to:

• Discovery
• License models/SKUs/PURs
• Maintenance
• End of life

For example, with product use rights, the default license can be associated to the discovered software, significantly reducing the effort to measure compliance

Complex and ambiguous

License models can be complex and ambiguous, and they will continue to grow. Datacenter software tends to be the most complex. Some information required to measure compliance may be difficult to collect. Not all vendor terms are clear and/or measurable and new license models continue to emerge.

Tip: Prior to purchasing any software, verify the compliance terms in order to avoid any ambiguity. If you don’t know what to measure, you cannot be confident in your compliance position. (Jump to questions about compliance below.)

Standards slow to adopt

The primary standards in this area (ISO/IEC 19770-1, -2 and -3) have been slow to adopt to further enhance automation in order to reduce the dependency of content services.

As adoption grows, these standards (particularly -2 and -3 below) will reduce the dependency on content which is essential today to drive automation and reduce the SAM effort:

• ISO 19770-1 provides a process framework for SAM. This is a great standard to evaluate and baseline your SAM program.
• ISO 19770-2 provides the standard for software tagging (discovery) which software vendors are slowly adopting.
• ISO 19770-3 standard provides the transport format, which is intended to drive standardization on the entitlements front.

Cloud complexity

Cloud licensing adds complexity as this is typically (but not always) less of an issue regarding licensing and compliance and more about usage and optimization. Hence, some cloud vendors are getting better at controlling the usage to avoid non-compliance, which shifts the primary focus on the customer to ensure they don’t over purchase (i.e. optimization over compliance)—an improvement over traditional on-premises software.

The tools and technology to capture and manage cloud-based software are improving as consuming applications via cloud services moves to becoming the rule rather than the exception.

Choosing SAM tools: Ask the right questions

Understanding the complexity of your own environment is going to provide you with direction when you are planning your SAM initiative.

If your organization simply uses technology for basic productivity tasks and the bulk of your staff only use Microsoft Office 365, then your scope will much easier to define and the licensing much easier to manage. If, however, you use a wide variety of on-premise and cloud-hosted applications—which is likely—you need to plan accordingly.

When dealing with multiple vendors, it is important that you understand the licensing models that apply to each application.

The table below gives you a starting point to find out the information you need to understand when planning SAM for your organization. This is not an exhaustive list of questions, but it will give you direction on the additional information you will need to know in order to effectively manage your software assets.

Most organizations I have worked with to establish SAM have been surprised, in some cases shocked, at what they learned:

• For many it was an opportunity to save money on licenses that were being paid for and not utilized.
• Others discovered that they were overutilizing licensing, leaving them open to fines and other legal consequences

Either way, uncovering the truth of your licensing state means you can know—and ensure—that you’re neither over- nor underutilizing software.

SAM resources

In my experience, it is not that organizations cannot handle the truth—they can. They just need to find and understand the truth before starting a SAM program. So now the question is, “How do I find the truth?”

The best source of truth about SAM is with those who have the real-world experiences of implementing more formal SAM programs. There are a range of sources including several independent industry organizations including:

• The ITAM Review
• The International Association of Information Technology Asset Managers, Inc. (IAITAM)

These organizations provide great content, guidance and training around SAM. For example, The ITAM Review provides a solid SAM Tool Selection Kit, which includes an in-depth questionnaire to assist in the process of selecting the best SAM solution for your business.

Additional resources

For related reading, explore these resources:

• BMC Service Management Blog
• IT Asset Management Best Practices
• CMDB vs Asset Management: Difference Between Assets and Configuration Items
• Shadow IT Explained: Risks & Opportunities
• 5 Practices for Controlling Costs as You Move to SaaS