best practices for buying business intelligence...

E-Book

Best practices for buying business

intelligence technology

The business intelligence market offers a dizzying array of technology

options – making technology purchases a challenging proposition.

From collecting organizational requirements, writing RFPs, conducting

evaluations and running proof of concept projects, there is a lot

involved – and a lot at stake -- in BI purchases. In this eBook, get

straightforward advice from industry analysts and expert practitioners.

Sponsored By:

http://www.ibm.com

SearchBusinessAnalytics.com E-Book

Best practices for buying business intelligence technology

Sponsored By: of 25

E-Book

Best practices for buying business

intelligence technology

Table of Contents

Gartner: Business intelligence ROI, value a matter of mind over money

Buying business intelligence software: Top 11 considerations

Bring your business intelligence RFP in line with the times

Gartner: Which type of business intelligence software buyer are you?

Business intelligence software product purchasing criteria

Resources from IBM



Sponsored By: of 25

Gartner: Business intelligence ROI, value a matter of mind over money

By Jeff Kelly, SearchBusinessAnalytics.com News Editor

Determining the return on investment (ROI) and value of a business intelligence (BI)

software investment is often an exasperating task, but not an impossible one, according to

one Gartner analyst.

In the early stages of a BI deployment, most companies measure value based on IT-centric,

quantifiable criteria, including improved operational efficiency and minimized total cost of

ownership, according to Bill Hostmann, vice president and distinguished analyst with

Stamford, Conn.-based Gartner Inc. But today, as more BI deployments mature and

companies start focusing on optimizing business processes, the metrics have changed and

are more difficult to interpret.

No longer just about tactical issues like reporting, BI ROI and value are increasingly linked

to performance management frameworks, said Hostmann, hosts the annual Gartner BI

Summit. That means using BI to define new sets of performance metrics, he said, and

making more decisions through facts-based analysis. It's not just about getting the right

information to the right people at the right time, he said, but determining that the

information is in fact being used to make better decisions.

The problem?

"How do you understand that somebody used information to make a decision that then

improved a particular business process? How do you go about quantifying that in some sort

of direct financial terms?" Hostmann asked. "That's where it gets more difficult," he said, as

there are no ready-made sets of metrics for measuring improved decision-making

capabilities.



Sponsored By: of 25

Gartner advice for measuring business intelligence software ROI and value

What companies can do, however, is measure user satisfaction, based on a set of

predefined BI objectives, 18 to 24 months after deployment. This can be done through a

simple survey, Hostmann said, zeroing in on user satisfaction with the relevancy, accuracy,

consistency and timeliness of data being used to make decisions. He said that companies

should then see whether they have answered the question, "Do you have the information

that you need to manage your business?"

Another tactic is to consider the risks of not utilizing BI. It costs money to store, secure and

archive the stupefying amounts of data floating around a typical enterprise, Hostmann said.

If it isn't used to improve business processes, data becomes little more than an expensive

liability.

Organizations that aren't using BI are also putting themselves at a competitive

disadvantage, as more companies are investing in BI today than ever before. In fact, BI is a

top priority for most CIOs, Hostmann said, as they are increasingly expected to support

business processes, not just put out IT-related fires.

"You've got a peer over there that has better information for making decisions," he said.

"What's the risk of your not making similar investments [in BI]? The risk is that your

competitors are making these kinds of investments and are able to react more quickly,

manage their business better or respond to changes in the market better and, as a result,

perhaps have better earnings than you."

Legal compliance is another key consideration when it comes to valuing BI, Hostmann

added. By providing a detailed view of a company's performance, BI allows companies to

spot trends and other behavior that may fall foul of federal compliance regulations. The risk

of being noncompliant is difficult to quantify financially, he said, but it is certainly important

(and will get executives' attention).



Sponsored By: of 25

Gartner: Business intelligence software ROI, value a "mindset"

Clearly, though, valuing BI is not an exact science and often comes down to mindset,

Hostmann said, comparing BI to a college education: It may be expensive and time-

consuming, but there are many less tangible benefits, like increased earning power and

overall improved quality of life, which come years later.

"It's not easy to persuade someone to go to college based on a purely financial or numbers

game, and the same thing goes [for] BI," Hostmann said. "You just have to believe that BI

is absolutely essential for you as an organization to investment, that this is a fundamental

core competency that you have to have."



Sponsored By: of 25

Buying business intelligence software: Top 11 considerations

By Mark Whitehorn, SearchBusinessAnalytics.com contributor

Buying business intelligence (BI) software can be hard -- with technical evaluations,

prioritizing requirements, getting the funding you need and avoiding political landmines,

there's a lot to consider. But in my experience, these are the most important considerations

for business intelligence software buyers. OK, so eleven is an odd number -- but in addition

to the eight things you should consider, I wanted to cover three things you should not

consider. In my experience, some people give far too much weight to certain issues that

have little or no relevance when choosing a BI system, so it seemed valuable to list these as

well.

1. Return on investment (ROI)

ROI is king. It's top of the list because it's the bottom line (if you see what I mean). We

don't implement BI systems because they are trendy; we don't do it because the technology

is fascinating. We invest the company's money in a BI system because we expect to get

more money back, in terms of income or savings, than we invest. Of course, calculating the

income/saving is often a major challenge, but it must not be ignored. All the remaining

points essentially follow on from ROI.

2. User requirements

This could arguably be at the top of the list, but ROI got in first. There's no point building a

BI system unless it delivers exactly what users are requesting/demanding -- so take the

time to go through the requirements-gathering process with your business users, however

painful it may be. Make sure you can deliver what people want, or just don't start -- a failed

project helps no one (and certainly not your career path).

3. Ease of use

Traditionally, BI systems have been difficult to implement, set up, understand, drive –

everything about them has been hard. The good news is that the situation is improving, so

buy one that is easy to drive. Give serious consideration to ease of use for the end user, but



Sponsored By: of 25

also consider that the easier it is for your technical staff to build and deploy a BI system,

the cheaper it will be to implement. The systems that are currently available vary hugely in

ease of use -- so make ease of use a priority in all areas.

4. Existing expertise within the organization

Suppose your enterprise has a policy of using just one database engine and has developed a

very experienced technical team on-site. If you buy your BI solution from the same vendor,

you get double benefits. Almost certainly your staff will find the new tools easier to use,

because of the family similarity that runs through products, and secondly, the staff will be

happier. If you force them to use a product from a manufacturer they don't respect, they'll

hate it on principle and blame it (and/or you) for everything that goes wrong. And they will

make sure it does go wrong.

5. Compatible technologies

Notwithstanding the point made above, few vendors currently supply complete end-to-end

BI systems. So, depending on your needs, you might not be able to source everything from

one supplier. If that is the case, before buying any of the components, ask searching

questions to ensure maximum compatibility with your existing infrastructure. All too often,

individuals within the enterprise lobby for the purchase of a BI component without taking

this into account. (I'm thinking here of, say, the finance officer who insists upon a particular

analytical tool.) Compatibility lowers the cost of producing an integrated system (something

that finance officer might appreciate, once you explain it).

6. Killer functionality

It may be that one BI software product alone offers a single piece of functionality that

outweighs virtually every other consideration except ROI. I have no idea what that might be

for your particular enterprise, but you'll know it when you see it (or your IT team will tell

you about it, long and loud). It might be support for spatial data types, for example,

allowing you to incorporate GPS data for tracking deliveries, or perhaps decomposition trees

for innovative data visualizations. But sometimes, that one killer feature makes the whole

investment worthwhile, as opposed to trying to get another product to do something that it

really wasn't designed to do.



Sponsored By: of 25

7. Data volume

How much data do you have -- and how much will you have in the future? If you're a large

retail chain collecting point-of-sale data, you have lots of data. If you're a telecom company,

you have lots of data. If you're NASA … and so on. Certain BI technologies do not scale well.

In-memory querying is a case in point: It can be very effective with surprisingly large data

volumes, but there are limits to what it can handle. Some software products (particular data

mining algorithms, for example) scale badly. They may work well with a million rows, but

with 10 million, they may run like a (slow) dog. Try to gauge data volume accurately and

match it to software/hardware capabilities. Then make the vendor really prove to you that

the software can handle it.

8. Hardware

The hardware available for BI covers a huge range:

• Commodity standalone boxes.

• Commodity boxes bolted together to form Massively Parallel Processing (MPP)

arrays.

• Dedicated MPP machines.

Costs vary accordingly. If you under-specify the hardware or try to use the wrong hardware

for your new BI software, your system will never perform optimally and the ROI will fail to

appear.

The business intelligence software buying points that you should not consider:

9. Cost

Cost isn't important; it's return on investment that counts. It's better to invest $5 million

and reap $30 million than to invest $2 million and reap nothing. (Best of all is to invest $2

million and reap $30 million, of course.) With the right calculations and a convincing

business case, you should be able to prove this to the money people at your company.

10. Current source systems

Existing operational systems such as the finance, CRM and human resources systems are

typically underpinned by a database engine. Just because you're using Engine X for



Sponsored By: of 25

transaction processing does not mean you have to use it for the new BI project, for the

simple reason that the Extract, Transform and Load (ETL) tool essentially sits as a buffer

between them. Any good tool will be perfectly capable of extracting data from any number

of different source systems and transforming it into any flavor you like. This doesn't mean

you should ignore the existing expertise in your company – see above – but, in terms of

functionality, there is little need to consider the existing engine.

11. The sales pitch

I don't know how to break this to you -- but some salespeople make things up. They

exaggerate, omit pertinent information and even lie. This is sad, but inescapable. At best,

they often lack a technical grasp of the capabilities of the systems they are offering. It is

essential to talk to technically competent people and get them together with your

technically competent staff. In my experience, technical people are less likely to stretch the

truth. This is not a hard-and-fast rule, simply an observation based on experience. I have,

however, heard a technical guy say: "Don't use our Component Y – it's rubbish." I've yet to

hear the same words from a salesperson.

About the author: Dr. Mark Whitehorn specializes in the areas of data analysis, data

modeling, data warehousing and business intelligence (BI). Based in the U.K., he works as a

consultant for a number of national and international companies, designing databases and

BI systems. In addition to his consultancy practice, he is a well-recognized commentator on

the computer world, publishing about 150,000 words a year, which appear in the form of

articles, in publications such as PCW and Server Management Magazine, white papers and

books.



Sponsored By: of 25

Bring your business intelligence RFP in line with the times


Request for proposals (RFPs) are supposed to help companies differentiate vendors and

offerings, but when it comes to business intelligence (BI), most RFPs fall short, according to

Gartner.

That's because most BI RFPs today are little changed from 10 years ago, when the BI

market was much less mature and much more fractured and when BI vendors had widely

varying capabilities, according to James Richardson, a Gartner analyst and author of a

recent report on the topic.

Today, with the BI market dominated by mega-vendors and strong pure-plays, the more

generic RFPs of old, which asked questions about basic functionality, fail to identify many

differences among the competing players, let alone their strengths and weaknesses. But

many companies still use these outdated RFPs, the Stamford, Conn.-based research firm

found.

In a typical BI RFP, for example, SAP, IBM, Oracle and SAS would all meet the "required

functionality 'out of the box' for most commonly used capabilities like reporting,

dashboarding, online analytical processing and so on," Richardson wrote in his report. That

information doesn't help a potential customer trying to narrow the field of BI vendors for

evaluation.

For a BI RFP to be effective in today's market, Richardson said, it must take into account

the mature nature of BI vendors and technology and focus on specific business

requirements that are most important to the organization. Richardson offers the following

advice to help companies write better RFPs that will actually achieve the goal of reducing

the number of BI vendors being considered to a manageable number:



Sponsored By: of 25

• First, be sure to put together a large and diverse group of BI stakeholders to

determine your business requirements – the actual BI elements and functionalities

that will define the success of the initiative – to write the RFP. "Make sure you've got

a good group of people that represent all your BI needs," Richardson said.

• A good RFP should be short and sweet. So, after determining business requirements,

organizations should weight evaluation criteria by importance and eliminate low-

weighted ones altogether, he said. If BI search capabilities are not that important to

the organization, for instance, don't even bother asking about them. Otherwise,

scoring of less important criteria can skew the larger results of the RFP and overlook

top buying priorities.

• Be sure to avoid subjective and generic questions. If questions are too vague or

open to interpretation, the vendors' answers will do little to help you differentiate

them. "For example, a line item that says 'dashboard capability' is not granular

enough, while one that says 'strong report caching' is too open to subjective

interpretation," Richardson wrote. "The more specific and definitive you can be, the

better."

• Never take the shortcut of using vendor-supplied RFP templates. "It seems obvious,

but you'd be surprised at the prevalence of this," Richardson wrote. "Using a

vendor's RFP spreadsheet template may save a lot of work, but it will skew your

evaluation toward their capabilities rather than your firm's needs."

• Avoid questions about company size and staffing levels except for very small, niche

vendors. While questions such as "how many staff members do you have focused on

product development?" may have been important 10 years ago, when many BI

companies were still upstarts, that's no longer the case, according to Richardson.

Mega-vendors and the remaining top independent vendors are all of substantial size,

so asking Microsoft or Oracle or SAS for their revenue figures and staff size won't

help you differentiate among them anymore.

• Finally, use the RFP as an opportunity to ask – or even demand – two or three

customer references, Richardson said. This step is traditionally taken at the end of

the buying process, when a vendor has been all but chosen, and consequently little

of value is gained. The earlier you can talk to reference customers the better, and

there's no better place to start the process than in the BI RFP.



Sponsored By: of 25

Also remember that the RFP, while an important step, is just one of many pieces of the BI

evaluation and buying process, Richardson said. In addition to a well-thought-out RFP, the

process should also include demonstrations, proofs of concept and savvy contract

negotiations.

"The RFP is only one component in a sound BI evaluation process," Richardson wrote. "Keep

your RFP as short as you can, and focus its outcome via weighting. Remember that vendors

will almost always answer 'yes, we do that' to every question posed/function detailed, and

the job of the RFP is to frame questions that will minimize subjectivity and reflect your

organization's BI needs."



Sponsored By: of 25

Gartner: Which type of business intelligence software buyer are you?


Not all business intelligence (BI) software buyers – or sellers, for that matter -- are created

equal.

So says Bill Hostmann, an analyst and research vice president at Stamford, Conn.-based

Gartner Inc. In a recent report, Hostmann identified a number of distinct types of BI buyers

and warned potential BI customers to identify which category they fall into or risk the

consequences.

"Those who fail to recognize which segment they are in -- and the associated differences

between vendors, products and best practices -- will expose themselves to additional costs

relating to procurement, integration, governance and, potentially, failed initiatives,"

Hostmann wrote.

The first group he identified is buyers of BI software for departmental-level deployments.

They are most often looking for analytical applications, usually from data visualization

specialists or SaaS-based BI vendors, for a narrowly defined set of requirements such as

sales tracking or supply chain analysis.

Hostmann said that it is important for these buyers to recognize that the tools used for

departmental deployments require a high level of sophistication among end users. "It's

going to be very much a power-user skill set that you're going to need," he said. Training is

therefore necessary if the target end users lack the skill to take advantage of these types of

applications.

Departmental BI deployments also perpetuate the data silo problem, of course, but

Hostmann doesn't think this is any reason to avoid them. Departmental deployments can be

extremely useful at targeted functions, he said, so "don't stand in the way of giving

somebody the tools they need to do the job." He said, however, that IT should educate



Sponsored By: of 25

users that significant data governance and data quality work will need to be done if

departmental analysis is ever shared with the rest of the organization.

"It is important to encourage their use, but it is also important to encourage best practices,"

Hostmann said. It is important for users to understand what it means to have inconsistent

definitions and to develop some method for annotating analysis that explains data lineage

and data definitions for consumption outside the department, he said. "Things like these

that you might find automatically with a more comprehensive BI platform, you're going to

have to do more manually when you're publishing results from one of these departmental-

level applications."

The next type is the buyer that has deployed BI and data management technologies from

multiple best-of-breed vendors throughout the enterprise. In most cases, this type of BI

customer has already agreed on definitions for technology-independent business models,

rules and services for BI applications, according to Hostmann.

"Recognize that, given the complexity of multiple vendors and technologies, failure to define

and provide the right mix and levels of sponsorship, governance, and program and demand

management will seriously limit the success of BI investments, deployments and adoption in

this segment," Hostmann advises.

He also suggests that buyers of BI technology from multiple vendors establish BI

competency centers, also called BI centers of excellence, to plan the organization's BI

architecture and manage the development of standardized BI technologies throughout the

enterprise.

Hostmann identified a third group of BI buyers: those that decide to purchase all their

enterprise applications, including BI technology, from a single vendor. That limits buying

options, for the most part, to one of the so-called mega-vendors – IBM, which acquired

Cognos; SAP, which bought Business Objects; and Oracle, which purchased Siebel and

Hyperion.



Sponsored By: of 25

"The general feeling among this segment of buyers is that 'a single vendor will simplify and

reduce the IT costs of vendor management and the development and deployment of

applications,'" Hostmann wrote. That feeling, however, is not always correct.

In some cases, he said, while the mega-vendors are busy integrating their newly acquired

technologies, not all applications from the same mega-vendor can yet communicate with

one another on the metadata level.

"The way that the users navigate through the information is through the metadata

breadcrumb trails, if you will," Hostmann said. "And if those breadcrumb trails don't connect

together, then the users are not going to be able to navigate through that data, and you're

going to have a real serious problem."

Potential BI buyers in this group should ask vendors about their current level of metadata

integration, as well as about their product roadmap plans for future integration, according to

Hostmann. He also urged buyers to do a thorough proof of concept and talk to reference

customers with similar requirements.

In addition, they should "evaluate the overall product line and partner 'ecosystem,' not just

its individual tools," he wrote. "They should also recognize that their negotiating position for

subsequent purchases may be weaker if they commit themselves to a single strategic

vendor."



Sponsored By: of 25

Business intelligence software product purchasing criteria

By Kathryn Marquis, SearchDataManagement.com Assistant Editor

By now, most organizations understand the many competitive advantages of business

intelligence (BI) software. BI software can help organizations analyze data to learn more

about their business and make better-informed business decisions. But before reaping the

benefits of BI, companies must implement software -- an often complex process.

SearchDataManagement.com readers report that buying business intelligence software

products can be confusing and complicated. Many decisions need to be made about

technical requirements, RFPs, budgets and, of course, software vendors. This resource is

designed for organizations purchasing BI software products for the first time, or for

organizations looking to update or optimize their current BI system.

To learn more, SearchDataManagement.com spoke with Boris Evelson, principal analyst with

Cambridge, Mass.-based Forrester Research Inc.; William McKnight, senior vice president,

information management for East Hanover, N.J.-based Conversion Services International

Inc. (CSI); and Michael Corcoran, chief marketing officer for New York City-based

Information Builders. We asked these experts how to overcome the challenges of the BI

software purchasing process and how to streamline a successful BI vendor and product

selection process. Since every organization has unique needs and criteria, the BI buying

process can vary -- but all buyers can benefit by being well prepared.

Below, there are two lists of questions to get you started. The first is a list of questions that

experts recommend organizations ask themselves internally before they begin the BI

purchasing process. The second is a suggested list of questions to ask vendors.

• Do we even need a new business intelligence product?

"When you start on the journey of a successful BI implementation, selecting a BI tool

is definitely not within the first 10 steps." -- Evelson



Sponsored By: of 25

It's easy to get caught up in the idea of buying business intelligence software, but

before you advance in the purchasing process, make sure your organization isn't

overlooking existing resources. Look closely at your existing enterprise applications

to determine whether there is already a BI capability at your disposal, Forrester's

Evelson recommended. For small organizations, the reporting capabilities in finance

or CRM applications may be sufficient -- eliminating the need for a more complex BI

system.

• Who's going to be on my BI team? Are the evaluation and purchase

processes going to be run primarily by IT or by business -- or both?

Ensure that you have the right people in the organization on the BI team. Ideally,

business should take a lead role during the evaluation and selection processes,

according to experts. Since a BI application is going to bring overall value to both

business and IT, it's prudent to make both groups part of the evaluation process. If

IT and business professionals are represented from the beginning, communication

between the groups is likely to be more effective down the road, Information

Builders' Corcoran said.

"If you are deploying business intelligence on an enterprise level, then staffing the BI

competency center jointly with technical professionals as well as business users and

business subject matter experts is really important," advises Cindi Howson, author of

Successful Business Intelligence: Secrets to Making BI a Killer App.

• What should our data architecture look like?

An analysis of your data volume, organizational needs and existing infrastructure will

help dictate the most suitable data architecture for your BI system. Evelson suggests

asking (and answering) the following questions internally, before shopping for

technology: Will you need to build a new data warehouse? Do you have such a

heterogeneous environment that you'll need separate data marts? Do you require a

centralized data hub from which you'll spin off your data marts? Do you already have

these in place, or will you have to build from scratch?



Sponsored By: of 25

• Should we write a request for proposal (RFP)?

It's always useful to write an RFP, Evelson said. It's the best way to organize your

team's thoughts in one document and establish your priorities. Consider all user and

business requirements and articulate them clearly. Evelson has helped create RFPs

with as many as 600 criteria.

• What are our business requirements, short and long term?

An organization's business requirements will not be the same five years down the

road, all experts agreed. Try to visualize the evolution of the organization's business

requirements and evaluate BI tools accordingly. Needs change, and a BI system

must be agile to meet evolving business constraints. If you can't foresee how your

users are going to use BI and structure queries in the future, consider making BI

search a requirement. Also, make sure business and IT define business terms the

same way -- a task sometimes easier said than done.

"When I get 10 businesspeople in a room and I ask them, 'How do you define

customer profitability?' I get 11 answers," Evelson said.

While this can be a challenging process, analytical master data management,

enterprise-wide data dictionaries, data governance programs and communication

can help solve disparate terminology problems, experts say.

"[One should] take the current process of defining requirements -- where usually

the IT professionals will ask the business what they need -- and flip it on its head.

It's really studying what workers are doing [and] what information they need to do

their jobs more efficiently and providing that information to them in a way that's

easy, accessible and integrated into their work process," Howson said.

• Who will the BI end users be, and what will they need?

Understanding the ultimate end users of the system before selecting the final

product can go a long way toward user adoption and the overall success of the



Sponsored By: of 25

system, experts said. Ask such questions as: How many users will BI have now and

in the future? Will this BI tool be used outside the firewall by customers or partners?

Will the tool be used in the U.S. only, or internationally? Do executives or

salespeople need mobile BI capabilities? Will we implement dashboards, scorecards

or data visualization tools? How important is real-time BI for operational workers,

like customer service staff or tech support? What kinds of ad hoc queries must the

tool be able to handle? How many users will be querying the system concurrently?

Are the users technically adept or will they need a simple interface?

• What are my data volumes today? What will they be in the near and far

future?

Changes in data volumes go hand in hand with evolving business requirements,

according to Evelson. Examine growth trends over the last year, five years and 10

years to more accurately predict how much data the organization will have several

years from now.

• What's my budget?

Once a business case and corporate sponsorship is established for the BI purchase,

you'll often know your budget. (If you're lucky, you'll be involved in the process of

deciding that number.) Staying within a budget can be difficult, especially because

it's impossible to predict extra expenses that may accrue from minor issues, extra

training, maintenance or other tasks, McKnight said. Consider also the cost of

hardware, if applicable. Experts recommend creating a detailed BI budget -- allotting

money for each step of the purchasing and implementation process -- and tracking

expenses regularly.

• What's our timeframe for implementation?

Is there a corporate deadline for implementation? BI can take anywhere from one

week to one year to implement. Allow time for your BI team to evaluate vendors,

complete a proof of concept, negotiate with the vendor, implement software and



Sponsored By: of 25

hardware, train administrators and users, and troubleshoot problems. Break down

each step and develop a detailed project plan, experts recommend.

• Do we want to do our own proof of concept -- in our environment with our

real data?

Doing a proof of concept (POC) in your own environment can be a critical -- and

telling -- step in the BI evaluation process, Evelson said. Today, most vendors will let

you try their product in your environment to show real performance capabilities. If

you decide to do your own POC, you need to figure out what data to use and how to

structure that POC. Create trial dashboards, test different queries, run test reports --

and remember to get your users involved in the POC process as well. When

implementing a new data warehouse, hold back some sample queries (don't provide

them to the vendor in advance), Gartner analysts advise, so that complex queries

can be tested without any system pre-tuning.

• Is there a pre-existing vendor/technology bias within my organization?

If your organization has used or is currently using products or systems from other

vendors, there may be a vendor bias that could tilt the neutrality of a new vendor

evaluation. Try to be aware of this bias, and encourage your team to be open to

change.

"Probably the worst thing for any BI vendor is to have to replace an existing product

entirely, because the users want your product to do everything the other vendor's

product did," Corcoran said.

• What is the technical environment that this BI software will need to

integrate into (source systems, databases, preferred hardware platforms,

etc.)?

Many organizations use products from several vendors. Be certain a new BI product

will integrate into the existing environment. Experts recommend carefully



Sponsored By: of 25

considering future architectural changes, such as service-oriented architectures,

which could affect this integration in the longer term.

• How will success be measured? Does the organization expect a certain ROI?

You (and corporate!) will certainly want results that justify the BI purchase. During

the product evaluation process, think about the best way to measure success in your

organization, whether it's increased profits, happier customers, streamlined

processes or some other metric.

"We don't implement BI systems because they are trendy; we don't do it because

the technology is fascinating. We invest the company's money in a BI system

because we expect to get more money back, in terms of income or savings, than we

invest," said industry expert Mark Whitehorn, in a recent article covering BI software

purchases.

• How will BI users and administrators be trained?

To best answer this question, get a feel for the learning style of your users and

administrators, Evelson recommends. Would they benefit from an all-inclusive

training class? Or will you train only administrators and have the administrators

teach the others?

• What can the product do? How does it meet our requirements?

If you clearly define your business requirements before meeting with a BI vendor,

aligning their product with your organization's needs will be a much smoother

process, experts agreed. But flexibility on your end is important, too. Be open-

minded about alternatives that meet your needs. Meeting your own requirements

should be a priority -- just be aware that different products may have different ways

of getting to the same place, Corcoran said.



Sponsored By: of 25

• What pricing/licensing options are available?

Many vendors offer multiple licensing styles. A few of the most popular options are:

o Concurrent users

o Role based

o Server based

"Vendors do [licensing] differently, and that makes it hard to compare apples to

apples," CSI's McKnight said.

So when selecting the licensing style, consider long-term user requirements.

Another tip from Gartner analysts about negotiating with BI vendors is to ensure

that the contract lists every SKU that will be purchased. Not reviewing these SKUs is

a surprisingly common mistake, analysts say -- with costly implications.

Organizations that skip this step can find out later that a feature they thought they

had purchased wasn't included in the contract and will cost more to acquire.

"There are so many add-ons out there ... and sometimes customers [aren't]

thinking about all that stuff when they engage the vendor," McKnight said. "You get

to the checkout stand and of course you want [the add-on] ... and it makes it kind

of a pressure situation."

• How will your BI software integrate into our current environment?

If you have outlined the technical requirements -- source systems, databases,

hardware platforms, etc. -- it will be easier for the vendor to discuss the integration

process with you. Ask the vendor what the common integration challenges are that

he/she frequently encounters and consider longer-term requirements, like SOA

functionality.



Sponsored By: of 25

• Will we be able to test the product in our environment? Can we get a proof

of concept?

It's highly unlikely that a vendor will not meet this request, according to Corcoran.

Just be sure to factor the POC into your implementation timeline.

• How are support and maintenance contracts set up?

If you are using a new vendor and a new product, it's likely that your users and

administrators are going to need technical support – particularly during the first year

of implementation. Ask vendors for specifics and detailed pricing for support, training

and maintenance.

• How long will implementation take? Will we need consultants or vendor

services?

Make sure the implementation time frame given by the vendor is realistic, experts

warn, and matches the time frame you have determined for yourself. There are often

vendor services teams or independent consultants that can assist you -- either

throughout the whole process or for specific decisions/questions.

• What are your software update cycles like? How easy is it to add on new

functions/features?

When your reporting requirements change at some point down the road, your BI

software may have to change, too. Make sure you talk with the vendor about the

process and cost of adding on new features at a later date, McKnight said. Be certain

you understand software update cycles and potential upgrade costs as well.

• What happens if you get acquired? How likely is an M&A for you?

Vendors may be quick to dodge this question, but it's a wise one to ask nonetheless.

A lot of things can change with mergers and acquisitions (M&A), so make sure the

terms are clear in your contract, to protect yourself.



Sponsored By: of 25

"When buying, you need to consider the lifecycle cost of that software [not just its

purchase price] and match this against the benefits you confidently feel you will get

from using it," advises industry expert Andy Hayler, in his column Risky Business:

How to assess risk during software purchases.

• Can I talk to one of your customers in an industry similar to mine?

The best insight into vendors and products comes from people with firsthand

experience, all experts agreed. Ask your vendor whether you can talk to one of their

customers, ideally a similarly sized organization with similar needs.

"Talk to people in the same industry, with similar types of applications, similar types

of users -- that's where the real value comes in," Corcoran said. Good vendors

should have nothing to hide and should be happy to connect you to someone.

"User groups are typically outside the control of the vendor, and members are

usually happy to talk candidly about the numbers of people attending," according to

Hayler's column. "A product user group with flat attendance -- whether from a small

startup or a large vendor -- should be a red flag."



Sponsored By: of 25

Resources from IBM

Key considerations for business intelligence platform consolidation

Key trends in business intelligence

BI implementation project management best practices

About IBM

At IBM, we strive to lead in the creation, development and manufacture of the industry's

most advanced information technologies, including computer systems, software, networking

systems, storage devices and microelectronics. We translate these advanced technologies

into value for our customers through our professional solutions and services businesses

worldwide. www.ibm.com

http://www-01.ibm.com/software/analytics/cognos/platform/

http://www-01.ibm.com/software/data/businessintelligence/

http://www-01.ibm.com/software/data/cognos/

http://www.ibm.com/

http://www.ibm.com

best practices for buying business intelligence...

Documents