Description
Six Factors to Consider When Selecting Business Intelligence Software
Six Factors to Consider When Selecting Business
Intelligence Software
apparatus.net | simplify IT white paper
What is your data analysis environment?
BI software users use to be the technical folks in the IT department. Report development required familiarity with
databases and SQL, and couldn't be picked up by the marketing guy down the hall. Now, "self-service" BI proclaims
to break down these barriers and turn anyone into an analyst. Between these two poles are plenty of potential
organizational models, which combine various amounts of technical acumen with all kinds of business knowledge
into the role of "analyst." Likewise, all BI software is designed to be used somewhere along this spectrum. Some allow
more technical customization and centralized control, while others facilitate more ad-hoc analysis. Figuring out the
target users for each contender, and comparing it to your organization, will be vital for successful implementation.
What is your data presentation environment?
Assume that analysis and development with your new tool is a breeze. What are you going to do with it? Approaches
to report presentation and distribution vary widely. Your management team may just want simple, static pictures on
a website, easily viewed by non-licensed users. Or, maybe they want interactive reports, deeply integrated into
SharePoint. Maybe, in the old school fashion, they use email for everything - from distributing shared documents and
preparing for meetings, to shopping for groceries and storing pictures of their grandkids. (Have them give us a call
and we'll see if we can't change that.) Whatever the case, there's always an easy way, a hard way and an impossible
way to distribute reports with any given BI tool. This is re?ected by both its architecture and its licensing method. A
mismatch could mean that even the most e?ective and eye-catching charts lay wasted on a portal or email inbox
somewhere.
How well does it work with your current data and vendors?
Not all data sources are created equally when it comes to report development. Most tools are less than capable when
it comes to certain data sources (contrary to the list of possible sources that can be found on their websites). A
suspicious mind might attribute this to vendor lock-in, as the companies that produce the troublesome data source
often have a BI tool as well. The bigger issue is architectural: Some data sources simply cannot be fully read by the BI
tool. Make sure to get an honest answer from your sales engineer about the potential limitations of your data source.
This does not mean you should simply pick the same vendor as your databases/data warehouse. And by the way, this
advice doesn't just apply to databases. If all your "data" is stored in Excel ?les, it's likely not in a nice tabular format
that BI tools prefer in which case, you have other work to do ?rst. (Don’t panic here, remember you can call us).
How did the proof of concept go?
The proof of concept is an important antidote to limitations of canned demos: The sample datasets are pristine and
the analysis elementary. A proper demo can make the worst software look good. Thus, giving sample datasets to the
sales engineer for a limited period of development can reveal both advantageous features and thorny issues
regarding your data that you wouldn't normally discover. You may also try setting your current report developers
loose on the tool to see how quickly they can learn it and start producing results. However, it's important to not
overemphasize the results of this initial discovery. Some tools simply have sharper learning curves, so while it may
not produce the most impressive results immediately, its architecture and features may be a better ?t.
How do its current features work?
Evaluating features of tools can be tricky. All tools might be capable of performing a task but with di?erent levels of
con?guration and ease. Unless you dive into the weeds with the sales engineer about how feature X performs Y when
the situation is Z, you often end up with just a blanket “yes.” Usually, an underlying structure is responsible for the
performance of several related features. For example, how it handles calculated or custom ?elds will a?ect how
aggregation, dates and table joins work. Understanding the technical nuts-and-bolts of the feature allows you to
more map its capabilities to your needs more accurately at both a high and low level.
Do we need it to do that?
Finally, and perhaps contrary to what you may think, don't overanalyze the features. You may think that this or that
native functionality is absolutely necessary for your chosen data visualization tool. Perhaps it's a special kind of task
or required transformation that's unique to your data environment, and therefore, you need it in your tool. But no BI
tool can shoulder the entire demands of your data environment. Ask yourself, would your unique feature be
performed better at the ETL layer, or even with a separate application?
In order to thrive in your organization, your chosen BI tool cannot stand alone. Not only must it rely on your existing
data environment and publishing work?ow, but it has to be used properly. The growing cluster of BI software titles
are designed for a wide range of use cases, and not all are a good ?t. If your sales rep is honest, they'll admit this. An
important step on the path to becoming a data-driven organization is a BI tool that ?ts your organizational needs.
Need help deciding what tool will help you become the data driven organization you are longing to be? Schedule a
Whiteboard Wednesday session with us today.
Michael Carper
Business Intelligence
Thinking about investing in some new business intelligence software - speci?cally, a data
visualization tool to empower business users, reduce report development time and deliver
clear, actionable data? Congratulations, you're well on your way to becoming a data-driven
organization. Be careful, though, as you could also be on your way to wasting hundreds of
thousands of dollars on software that will only frustrate your users and management,
delivering nothing except delays and shattered hopes. Which way will you take? Choosing
your business intelligence (BI) software is a major step. Here are some important factors
when making this decision:
white paper apparatus.net | simplify IT
What is your data analysis environment?
BI software users use to be the technical folks in the IT department. Report development required familiarity with
databases and SQL, and couldn't be picked up by the marketing guy down the hall. Now, "self-service" BI proclaims
to break down these barriers and turn anyone into an analyst. Between these two poles are plenty of potential
organizational models, which combine various amounts of technical acumen with all kinds of business knowledge
into the role of "analyst." Likewise, all BI software is designed to be used somewhere along this spectrum. Some allow
more technical customization and centralized control, while others facilitate more ad-hoc analysis. Figuring out the
target users for each contender, and comparing it to your organization, will be vital for successful implementation.
What is your data presentation environment?
Assume that analysis and development with your new tool is a breeze. What are you going to do with it? Approaches
to report presentation and distribution vary widely. Your management team may just want simple, static pictures on
a website, easily viewed by non-licensed users. Or, maybe they want interactive reports, deeply integrated into
SharePoint. Maybe, in the old school fashion, they use email for everything - from distributing shared documents and
preparing for meetings, to shopping for groceries and storing pictures of their grandkids. (Have them give us a call
and we'll see if we can't change that.) Whatever the case, there's always an easy way, a hard way and an impossible
way to distribute reports with any given BI tool. This is re?ected by both its architecture and its licensing method. A
mismatch could mean that even the most e?ective and eye-catching charts lay wasted on a portal or email inbox
somewhere.
How well does it work with your current data and vendors?
Not all data sources are created equally when it comes to report development. Most tools are less than capable when
it comes to certain data sources (contrary to the list of possible sources that can be found on their websites). A
suspicious mind might attribute this to vendor lock-in, as the companies that produce the troublesome data source
often have a BI tool as well. The bigger issue is architectural: Some data sources simply cannot be fully read by the BI
tool. Make sure to get an honest answer from your sales engineer about the potential limitations of your data source.
This does not mean you should simply pick the same vendor as your databases/data warehouse. And by the way, this
advice doesn't just apply to databases. If all your "data" is stored in Excel ?les, it's likely not in a nice tabular format
that BI tools prefer in which case, you have other work to do ?rst. (Don’t panic here, remember you can call us).
How did the proof of concept go?
The proof of concept is an important antidote to limitations of canned demos: The sample datasets are pristine and
the analysis elementary. A proper demo can make the worst software look good. Thus, giving sample datasets to the
sales engineer for a limited period of development can reveal both advantageous features and thorny issues
regarding your data that you wouldn't normally discover. You may also try setting your current report developers
loose on the tool to see how quickly they can learn it and start producing results. However, it's important to not
overemphasize the results of this initial discovery. Some tools simply have sharper learning curves, so while it may
not produce the most impressive results immediately, its architecture and features may be a better ?t.
How do its current features work?
Evaluating features of tools can be tricky. All tools might be capable of performing a task but with di?erent levels of
con?guration and ease. Unless you dive into the weeds with the sales engineer about how feature X performs Y when
the situation is Z, you often end up with just a blanket “yes.” Usually, an underlying structure is responsible for the
performance of several related features. For example, how it handles calculated or custom ?elds will a?ect how
aggregation, dates and table joins work. Understanding the technical nuts-and-bolts of the feature allows you to
more map its capabilities to your needs more accurately at both a high and low level.
Do we need it to do that?
Finally, and perhaps contrary to what you may think, don't overanalyze the features. You may think that this or that
native functionality is absolutely necessary for your chosen data visualization tool. Perhaps it's a special kind of task
or required transformation that's unique to your data environment, and therefore, you need it in your tool. But no BI
tool can shoulder the entire demands of your data environment. Ask yourself, would your unique feature be
performed better at the ETL layer, or even with a separate application?
In order to thrive in your organization, your chosen BI tool cannot stand alone. Not only must it rely on your existing
data environment and publishing work?ow, but it has to be used properly. The growing cluster of BI software titles
are designed for a wide range of use cases, and not all are a good ?t. If your sales rep is honest, they'll admit this. An
important step on the path to becoming a data-driven organization is a BI tool that ?ts your organizational needs.
Need help deciding what tool will help you become the data driven organization you are longing to be? Schedule a
Whiteboard Wednesday session with us today.
Michael Carper
Business Intelligence
About Apparatus
Apparatus specializes in durable, scalable managed IT solutions backed by our unparalleled technological insights
that deliver increasing business value to our clients over time. Our top notch suite of highly con?gurable, enterprise
consulting solutions stretch across uni?ed communications, collaboration, business intelligence, mobile, and cloud
computing. Add transparent client service and a culture of passionate technologists, and you'll see what's propelled
Apparatus into the top ranks of managed service providers worldwide.
doc_691846191.pdf
Six Factors to Consider When Selecting Business Intelligence Software
Six Factors to Consider When Selecting Business
Intelligence Software
apparatus.net | simplify IT white paper
What is your data analysis environment?
BI software users use to be the technical folks in the IT department. Report development required familiarity with
databases and SQL, and couldn't be picked up by the marketing guy down the hall. Now, "self-service" BI proclaims
to break down these barriers and turn anyone into an analyst. Between these two poles are plenty of potential
organizational models, which combine various amounts of technical acumen with all kinds of business knowledge
into the role of "analyst." Likewise, all BI software is designed to be used somewhere along this spectrum. Some allow
more technical customization and centralized control, while others facilitate more ad-hoc analysis. Figuring out the
target users for each contender, and comparing it to your organization, will be vital for successful implementation.
What is your data presentation environment?
Assume that analysis and development with your new tool is a breeze. What are you going to do with it? Approaches
to report presentation and distribution vary widely. Your management team may just want simple, static pictures on
a website, easily viewed by non-licensed users. Or, maybe they want interactive reports, deeply integrated into
SharePoint. Maybe, in the old school fashion, they use email for everything - from distributing shared documents and
preparing for meetings, to shopping for groceries and storing pictures of their grandkids. (Have them give us a call
and we'll see if we can't change that.) Whatever the case, there's always an easy way, a hard way and an impossible
way to distribute reports with any given BI tool. This is re?ected by both its architecture and its licensing method. A
mismatch could mean that even the most e?ective and eye-catching charts lay wasted on a portal or email inbox
somewhere.
How well does it work with your current data and vendors?
Not all data sources are created equally when it comes to report development. Most tools are less than capable when
it comes to certain data sources (contrary to the list of possible sources that can be found on their websites). A
suspicious mind might attribute this to vendor lock-in, as the companies that produce the troublesome data source
often have a BI tool as well. The bigger issue is architectural: Some data sources simply cannot be fully read by the BI
tool. Make sure to get an honest answer from your sales engineer about the potential limitations of your data source.
This does not mean you should simply pick the same vendor as your databases/data warehouse. And by the way, this
advice doesn't just apply to databases. If all your "data" is stored in Excel ?les, it's likely not in a nice tabular format
that BI tools prefer in which case, you have other work to do ?rst. (Don’t panic here, remember you can call us).
How did the proof of concept go?
The proof of concept is an important antidote to limitations of canned demos: The sample datasets are pristine and
the analysis elementary. A proper demo can make the worst software look good. Thus, giving sample datasets to the
sales engineer for a limited period of development can reveal both advantageous features and thorny issues
regarding your data that you wouldn't normally discover. You may also try setting your current report developers
loose on the tool to see how quickly they can learn it and start producing results. However, it's important to not
overemphasize the results of this initial discovery. Some tools simply have sharper learning curves, so while it may
not produce the most impressive results immediately, its architecture and features may be a better ?t.
How do its current features work?
Evaluating features of tools can be tricky. All tools might be capable of performing a task but with di?erent levels of
con?guration and ease. Unless you dive into the weeds with the sales engineer about how feature X performs Y when
the situation is Z, you often end up with just a blanket “yes.” Usually, an underlying structure is responsible for the
performance of several related features. For example, how it handles calculated or custom ?elds will a?ect how
aggregation, dates and table joins work. Understanding the technical nuts-and-bolts of the feature allows you to
more map its capabilities to your needs more accurately at both a high and low level.
Do we need it to do that?
Finally, and perhaps contrary to what you may think, don't overanalyze the features. You may think that this or that
native functionality is absolutely necessary for your chosen data visualization tool. Perhaps it's a special kind of task
or required transformation that's unique to your data environment, and therefore, you need it in your tool. But no BI
tool can shoulder the entire demands of your data environment. Ask yourself, would your unique feature be
performed better at the ETL layer, or even with a separate application?
In order to thrive in your organization, your chosen BI tool cannot stand alone. Not only must it rely on your existing
data environment and publishing work?ow, but it has to be used properly. The growing cluster of BI software titles
are designed for a wide range of use cases, and not all are a good ?t. If your sales rep is honest, they'll admit this. An
important step on the path to becoming a data-driven organization is a BI tool that ?ts your organizational needs.
Need help deciding what tool will help you become the data driven organization you are longing to be? Schedule a
Whiteboard Wednesday session with us today.
Michael Carper
Business Intelligence
Thinking about investing in some new business intelligence software - speci?cally, a data
visualization tool to empower business users, reduce report development time and deliver
clear, actionable data? Congratulations, you're well on your way to becoming a data-driven
organization. Be careful, though, as you could also be on your way to wasting hundreds of
thousands of dollars on software that will only frustrate your users and management,
delivering nothing except delays and shattered hopes. Which way will you take? Choosing
your business intelligence (BI) software is a major step. Here are some important factors
when making this decision:
white paper apparatus.net | simplify IT
What is your data analysis environment?
BI software users use to be the technical folks in the IT department. Report development required familiarity with
databases and SQL, and couldn't be picked up by the marketing guy down the hall. Now, "self-service" BI proclaims
to break down these barriers and turn anyone into an analyst. Between these two poles are plenty of potential
organizational models, which combine various amounts of technical acumen with all kinds of business knowledge
into the role of "analyst." Likewise, all BI software is designed to be used somewhere along this spectrum. Some allow
more technical customization and centralized control, while others facilitate more ad-hoc analysis. Figuring out the
target users for each contender, and comparing it to your organization, will be vital for successful implementation.
What is your data presentation environment?
Assume that analysis and development with your new tool is a breeze. What are you going to do with it? Approaches
to report presentation and distribution vary widely. Your management team may just want simple, static pictures on
a website, easily viewed by non-licensed users. Or, maybe they want interactive reports, deeply integrated into
SharePoint. Maybe, in the old school fashion, they use email for everything - from distributing shared documents and
preparing for meetings, to shopping for groceries and storing pictures of their grandkids. (Have them give us a call
and we'll see if we can't change that.) Whatever the case, there's always an easy way, a hard way and an impossible
way to distribute reports with any given BI tool. This is re?ected by both its architecture and its licensing method. A
mismatch could mean that even the most e?ective and eye-catching charts lay wasted on a portal or email inbox
somewhere.
How well does it work with your current data and vendors?
Not all data sources are created equally when it comes to report development. Most tools are less than capable when
it comes to certain data sources (contrary to the list of possible sources that can be found on their websites). A
suspicious mind might attribute this to vendor lock-in, as the companies that produce the troublesome data source
often have a BI tool as well. The bigger issue is architectural: Some data sources simply cannot be fully read by the BI
tool. Make sure to get an honest answer from your sales engineer about the potential limitations of your data source.
This does not mean you should simply pick the same vendor as your databases/data warehouse. And by the way, this
advice doesn't just apply to databases. If all your "data" is stored in Excel ?les, it's likely not in a nice tabular format
that BI tools prefer in which case, you have other work to do ?rst. (Don’t panic here, remember you can call us).
How did the proof of concept go?
The proof of concept is an important antidote to limitations of canned demos: The sample datasets are pristine and
the analysis elementary. A proper demo can make the worst software look good. Thus, giving sample datasets to the
sales engineer for a limited period of development can reveal both advantageous features and thorny issues
regarding your data that you wouldn't normally discover. You may also try setting your current report developers
loose on the tool to see how quickly they can learn it and start producing results. However, it's important to not
overemphasize the results of this initial discovery. Some tools simply have sharper learning curves, so while it may
not produce the most impressive results immediately, its architecture and features may be a better ?t.
How do its current features work?
Evaluating features of tools can be tricky. All tools might be capable of performing a task but with di?erent levels of
con?guration and ease. Unless you dive into the weeds with the sales engineer about how feature X performs Y when
the situation is Z, you often end up with just a blanket “yes.” Usually, an underlying structure is responsible for the
performance of several related features. For example, how it handles calculated or custom ?elds will a?ect how
aggregation, dates and table joins work. Understanding the technical nuts-and-bolts of the feature allows you to
more map its capabilities to your needs more accurately at both a high and low level.
Do we need it to do that?
Finally, and perhaps contrary to what you may think, don't overanalyze the features. You may think that this or that
native functionality is absolutely necessary for your chosen data visualization tool. Perhaps it's a special kind of task
or required transformation that's unique to your data environment, and therefore, you need it in your tool. But no BI
tool can shoulder the entire demands of your data environment. Ask yourself, would your unique feature be
performed better at the ETL layer, or even with a separate application?
In order to thrive in your organization, your chosen BI tool cannot stand alone. Not only must it rely on your existing
data environment and publishing work?ow, but it has to be used properly. The growing cluster of BI software titles
are designed for a wide range of use cases, and not all are a good ?t. If your sales rep is honest, they'll admit this. An
important step on the path to becoming a data-driven organization is a BI tool that ?ts your organizational needs.
Need help deciding what tool will help you become the data driven organization you are longing to be? Schedule a
Whiteboard Wednesday session with us today.
Michael Carper
Business Intelligence
About Apparatus
Apparatus specializes in durable, scalable managed IT solutions backed by our unparalleled technological insights
that deliver increasing business value to our clients over time. Our top notch suite of highly con?gurable, enterprise
consulting solutions stretch across uni?ed communications, collaboration, business intelligence, mobile, and cloud
computing. Add transparent client service and a culture of passionate technologists, and you'll see what's propelled
Apparatus into the top ranks of managed service providers worldwide.
doc_691846191.pdf