Getting Started—How to Evaluate Vendors

So far in this guide, we've covered quite a bit of ground. Chapter 1 set the stage for ITPA and illustrated how the state of the data center today is becoming increasingly dynamic as it approaches optimization through automation. To achieve the goal of a sustained state of IT efficiency while remaining quick to respond to business needs and able to meet standards and compliance challenges demand dynamic optimization methods, and ITPA tools deliver to meet that need. Chapter 2 explored the various stages of process maturity and presented tips on how to automate returns. In Chapter 3, we covered many of the ways in which the pain associated with common IT processes can be relieved through ITPA.

This chapter will answer what may be the most important question: Who can we trust to deliver on the need for ITPA in your enterprise? Identifying the right vendor to partner with and work through your ITPA goals can be challenging. However, through research, you can answer the appropriate questions and base your technical evaluations on the right criteria to ensure success. Research is absolutely essential, and if you know the right questions to ask, the work becomes much less daunting and produces much more useful results.

Establishing a Short List of Vendors: Do Your Analyst Research

For many organizations, the entire success or failure of their ITPA initiatives hinge squarely on vendor selection. Knowing this, however, organizations still fail to consistently put aside the time and resources necessary to fully evaluate their vendor selections. Evidence to this point is clear and likely lurking in your own enterprise as no doubt by now you may have already identified several systems that may be consolidated and optimized through ITPA.

Vendors in the ITPA tool market vary in size, market focus, and experience, so it is important to research all options to find the vendor best suited for your needs. One commonly used tool to help in vendor evaluation is known as an evaluation matrix. The following list highlights key areas you should ensure receive heightened attention and are captured on your matrix:

  • Experience
    • How long has the vendor been developing ITPA tools?
    • Does the vendor show evidence of understanding best practices in your area of interest such as ITIL/ITSM, security, or virtualization?
  • Compatibility Integration
    • Will this system interaction/function with all your existing infrastructure applications?
    • Will any special coding be required?
  • Ease of Use/Supportability
    • What does the process design process and interface look like (that is, is it script driven or is there a GUI with a drag-and-drop interface)?
    • How difficult is it to relate a business process to the system input?
    • Can a non-technical person understand the process steps as they appear in the system?
    • How much will support cost and how will it be delivered?
    • What is the learning curve/on-boarding time for new associates?
  • Infrastructure Overhead
    • Is the ITPA tool client based (requiring code on each system it interacts with) or is it clientless? If it is client based, who will support those clients? How often do they need to be updated?
    • How many new transactions/traffic is this system going to introduce? Will it touch multiple systems/multiple times or does it retain information for use throughout its processes?
    • How many servers and what kind of processing power is going to be required to maintain this environment?

Table 4.1 shows a sample evaluation matrix based upon these categories used to evaluate two vendors with similar products.

Table 4.1: Sample evaluation matrix.

Your own evaluation matrix may weight these categories differently or perhaps break them into their core elements a bit further to ensure a fully detailed analysis. For example, Ease of Use/Supportability could be broken into segments focused on the user experience, learning curve, support overhead, and documentation, just to name a few. The important factor is that you clearly establish your criteria prior to vendor selection so that as you perform your evaluations, you are doing so with a common measuring stick.

Request for Proposal and Request for Information

Once you've established your measurement criteria, the next step is to document a Request for Proposal (RFP) and send it through your supply chain management process and begin to solicit vendor proposals. If you have a particular vendor in mind, a similar document, a Request for Information (RFI), can also be used to solicit information directly and to determine whether the vendor's surface qualifications meet your expectations before pursing them by sending an RFP.

Your organization is likely to have its own standard format for which RFPs are created, including their structure and layout. Rather than give a lesson in RFP structure, let's cover what it will take to ensure that your RFP will be as effective as possible and help you receive the most qualified RFP responses. From a high level, your RFP should contain basic answers to the common interrogative construct, also known as "The 5 W's" (Who, What, When, Where, Why) and how. Specifically

  • Who—What industry are you in? Who do you serve? From within which departmental organization do you operate?
  • What—What is it specifically that you're looking for? For example, you may state something along the lines of "We desire an ITPA tool capable of orchestrating all the various disparate systems within our enterprise into a centrally managed process framework that can be managed by entry-level process design consultants with no programming experience. The system should be GUI based, easy to use, and integrate fully with all existing systems including..."
  • When—What is your project timeline?
  • Why—State the reasons you're requesting the proposal. If it is fair to say that you're looking for an ITPA tool to assist in ITIL implementation or infrastructure optimization, then do so. Some tools may be geared more towards server provisioning, for example, rather than IT service management. You'll want to identify any potential gaps in the solutions vendors offer and note those for review.
  • How—How will the vendor be evaluated by your team? This is an important step both for your own team's understanding and for the vendors submitting the proposals so that everyone has a documented reference of what is expected and graded.

Answering these questions will prove a solid foundation upon which to begin to author the RFP within your organization.

Time to Value and Implementation

The following sections offer a few important notes to cover in your RFP document specifically around time to value and implementation of an ITPA tool.

Best of Breed vs. Suites

Is your infrastructure a single vendor environment or heterogeneous? Solutions that can meet the needs of heterogeneous environments are much more desirable for their flexibility and for "future proofing" your environment against change. Best of breed vendors provide agility, with more frequent release cycles and an ability to influence product direction, and are specialists in ITPA. Management vendors who acquire smaller vendors have used technology to fix integration between product suites.

IT Process Automation vs. Task Automation

Many vendors offer point solutions for task automation for their own products, but these are not true ITPA tools in the sense that they do not orchestrate IT processes across platforms, product suites, and silos. There are also ITPA vendors that specialize in a specific area such as storage, database, or incident handling. Although these solutions might meet initial needs, expanding automation outside of that silo may not be possible.

Service-Based vs. Product-Based Automation

How does the ITPA vendor implement ITPA? Many ITPA vendors started as service companies and implement ITPA using code/script-based methodologies, which lengthens implementation and makes it more difficult to update process rules as business logic changes. Be wary that services cost more than the product.

Out of the Box

What support services are offered beyond the ITPA tool implementation? Are process automation consultations available? What about best practices libraries of processes to be automated (look for mature libraries of predefined best practice processes)? Does the vendor offer any visibility into its future release schedules so that you can plan for change? All these questions will provide you with a much clearer understanding of the experience and capabilities of the vendor you may be working with.

Does the tool offer a truly end-to-end process framework? ITPA tools are not merely job schedulers or management tools; they are cross-platform, logical decision tree–based tools with built-in monitoring, capable of working with many applications to execute an end-to-end IT process. Even human-based Help desks can't offer this kind of end-to-end process execution, which begins with an event and ends with a resolution often touching dozens of systems inbetween and all within a matter of mere moments from inception.

It is also important to fully involve in the RFP process all parties that will contribute to the success of the project. Gaining a clear voice of the customer and maintaining an open seat at the project "table" often means the difference between project success and failure. Invite your partners to participate, solicit feedback, and encourage open and candid discussions on concerns.

Technical Evaluation—Features and Function

Once your RFPs have been received and weighed through your evaluation matrix, the process of detailed vendor evaluation can begin. You've no doubt narrowed your choices and now, with full proposal details in hand, your teams can begin to technically evaluate the features and functionality of the vendor products. To orchestrate, integrate, and automate your environment, there are a number of key technical features to consider, which the following sections highlight.

Design Environment

Look for a design environment that offers:

  • Operator's console—Ability to view and interact with running workflow
  • Executive dashboard—Ability for executives to view operational metrics to measure the impact of automation on the business
  • Intuitive workflow designer—Ability to create codeless workflow designs, with codeless integrations, codeless rules engine, and codeless data bus

Architecture

Is the environment entirely server based or is it distributed? A distributed automation tool depending upon many "agents" spread across the various application systems and devices it may potentially need to integrate with is much less attractive than an agent-less solution which would accomplish its automation tasks seamlessly and without any added overhead on any of your existing application systems. Be leery of code that "must" be executed on you secondary systems (such as your virtual server provisioning platform, or help desk) that may interfere with normal maintenance of those software packages.

Script vs. Non-Script Environments

Script is a code word for "software code" which implies complexity, implies specialized knowledge and implies added support costs to maintain. Introducing even the slightest bit of code complicates the process design work flow and may require added support to ensure that as IT processes are changed the appropriate level of technology management is engaged to "script" solutions. In short, scripts and automation are not ideally paired for the long-haul. ITPA tools that offer a script-less interface are clearly preferred over those which require bits of code strung together to enable them to function properly within your environment. An ideal solution would involve no coding on the part of the IT process designer at all, simply a point and click interface connecting IT processes together in a visual way that is easy to understand and easy to manage going forward.

The Truth About BPEL

There has been some considerable "buzz" and some confusion in recent years over BPEL, the Business Process Execution Language, so as an important point of clarity let's pause for a moment to discuss. BPEL is an XML-based language designed to enable task-sharing for distributed (otherwise known as "grid") computing environments. It is not an IT process automation tool or workflow designer. BPEL is commonly used by programmers to write code that can execute across multiple web servers. The name is deceptive and easy to confuse in name alone with ITPA tools which, in contrast, offer a full workflow design suite geared towards process designer use. These technologies are not related and do not serve similar functions. One is a XML based language, the other will reduce your infrastructure costs, streamline your processes, optimize your infrastructure, save you money and increase your customer satisfaction.

Real-World Value

The ease of use and rapid implementation of ITPA tools are making real impacts in many organizations today along the pain points we discussed in Chapter 3. All manner of IT service management can be automated (Incident, Problem, Change, Release, and Configuration) as well as IT processes supporting server provisioning, virtualization, and business continuity. Table 4.2 illustrates how ITPA tools are being used today in midsize and large organizations to significantly decrease process time and FTE resources and save organizations money.

Industry

Business Challenge

Without ITPA

With ITPA

Estimated Savings

Telecommunications

Time‐to‐acknowledge and response to customer outages on 200 servers (9 processes)

25 min

1 min

$ 2.5M/year

Software

Time‐to‐onboard new employees through Active Directory (1 process)

45 min

3 staff

2 min 0 staff

$ 450K/year

(1800 requests)

Food Retailer

Time‐to‐run 100 maintenance and inventory processes across 2,000 stores

60 min per store

1 staff

5 min per store

0 staff

$ 150K

Prevented on‐site staff $10M

Financial Services

Time‐to‐fulfill service requests for new virtual servers (1 process)

120 min

2 staff

3 min 0 staff

$ 280K/year

Table 4.2: ITPA real-world impact.

To dive a bit deeper, let's take an up-close look at a real-world implementation for a large government tax authority.

Situation

The organization monitors thousands of operations and application servers that process tax applications, insurance, assessment, and customs taxes for companies and individuals for millions of customers. The organization has deployed multiple monitoring systems that have traditionally required a sustainable human investment to manage each application environment and ensure continuous service delivery. A proprietary application had been developed to "integrate" some of the systems; however, the software was code-based, and built upon aging technology that proved to be restrictive and difficult to manage, which resulted in gaps in service-level support. Gaps in documentation and the core competencies of the internal teams and vendors, few of which could still support this aging technology and then only at a premium, increased the systems, people, and process risk associated with managing the environment and maintaining operational stability.

Impact

Year after year, budget drain increased as support capabilities from internal and external teams waned. As knowledgeable support diminished, service response times and expenses increased.

Challenge/Goal

The goal is to consolidate the nine operations needed into a single, cohesive, operations center and to free up 12 full-time employees for reallocation to other, more strategic projects and initiatives as well as enable the delivery of a single management console. This will reduce costs and improve service quality.

Solution

An ITPA tool has been implemented and is today processing approximately 2 million events per month filtering, translating, and then generating up to 750,000 events per month into the enterprise console.

Taking a look at the breakdown of numbers, the solution resulted in:

  • Each of the 2M events initiates at least two actions in an ITPA workflow = 6million actions
  • Of those, as many as 750,000 events can get forwarded into the console per month; every one of those passes through a minimum of three policies and a total of 23 objects, for a total of 17,250,000 actions undertaken (23 × 750,000)
  • 2.75M workflows /month
  • 91,600k workflows/day

This results in 275,000 actions a day being executed by a tool that is not "code based" or dependent upon "tribal" knowledge but rather is built to deliver a simple drag-and-drop interface to ITPA.

Benefit/ROI

Costs have been reduced and significant improvement in service quality and response time has been gained. An estimated savings of $1.5M / 12 people at $125,000 (fully loaded employee cost) has been realized and those associates are now focused on more strategic initiatives that will further reduce the organization's costs through ITPA and ultimately save tax payers money.

The value of ITPA by now is clear. Through sound design and simplified execution, ITPA tools can reduce the total cost of IT by automating repetitive, even deeply complex, tasks. As tools designed to be vendor agnostic, ITPA tools orchestrate data center operations to deliver extremely high process efficiency yields while remaining a neutral companion in "vendor wars" for your operational budget. Combined with industry best practices and sound IT governance, these tools will make your organization more effective and agile while freeing up your talented IT human investment to focus on the projects that matter most: those that grow your business.

Time to Value, Adaptability to Change

There's an old saying in IT that goes "Test then invest." Simply put, every idea must be vetted for its viability, and this process, when properly executed, also delivers as a byproduct an indication to the project's time to value. IT projects usually start with a small first run, also known as a pilot, to identify viability. IT process improvement efforts are no different. When weighing ITPA tools, consider this: How quickly can you prototype and test an "idea" with this tool? Will your teams be able to test ITPA solutions quickly? The answers of course should be yes.

A solid ITPA tool will enable your IT process design team members to rapidly develop, test, and deploy new processes or make changes to existing processes. Interfaces into your existing IT infrastructure shouldn't feel like "interfaces" but rather simply part of the ITPA tool itself so that your teams can spend their valuable time focusing on developing and refining the best processes rather than trying to make processes work within the constraints of an ITPA tool.

ITPA is the cornerstone that must be laid to architect the next generation "lights out" data center, and selecting the vendor best capable of delivering ITPA to your enterprise is no simple task. However, armed with the tips covered here, you're well on your way to success.