Dataspace is looking for 2 business intelligence analysts for positions at clients in New York State.  These are true analyst, not developer-level, roles.  So, while a knowledge of BI technologies is necessary, the role will not entail actual BI development.

We will consider applicants for either contract or permanent employment.

• BI Analyst: 2 needed -need analysts with understanding of SQL/Cognos/SAS but they need to understand the tools conceptually, don’t need to be hands-on programmers
• This is truly a higher-level analyst role, not a developer role. Consultants will be responsible for tasks such as:

Gathering requirements from end users
Understanding the data flows between systems
Designing business processes & reworking data flows

• Required qualifications include:

Perfect verbal ability
Strong writing skills
Business analysis / user interview skills
Technical analysis & design skills

• Desired qualifications include:

Ideally understand healthcare and financial data
Knowledge of healthcare / health insurance industry
Knowledge of financial systems is a plus

• Duration: 6 months + likely extensions
• CONTRACTOR CANDIDATES MUST BE DIRECT EMPLOYEES OF THE CONTRACTING FIRM – NO SUBCONTRACTS

Detailed Role Description: Business Analyst Role Description

WARNING: This month’s quiz is harder than it seems at first!  Are you up to it?

We recently worked with a client that does business all around the world. They capture millions of transactions which they then bring into a dimensional data warehouse for analysis.

The problem is that this company, and their customers, need to analyze their data indexed to any time zone. So, for example, if a transaction takes place in Mumbai at 0200, it might be analyzed in the Mumbai time zone as 0200 or the New York time zone as 1530 or as any other time zone in the world.

Now the question; assuming a standard relational database, what is the best way to model this data to provide correct time and date results as well as adequate query response time?

HINT: In formulating your answer, consider the impact of date, not just time. 

Most business intelligence efforts start with a statement like the following, “Let’s build a BI system so our employees can get whatever data they need, when they need it.”  While well intentioned, statements like these are misguided.

The truth:

• If folks do their jobs today without using a shiny, new BI tool, why are they going to put extra effort into learning your snappy new tool?
• Most folks don’t get a big thrill out of accessing data - BI is like a dishwasher, a tool for getting a job done.  Do you want to go to classes and learn a panoply of new things just to use your dishwasher?
• Most folks’ data needs are limited to a relatively narrow range of topics (e.g. sales folks typically don’t need to access HR data).
• Even with data warehouses and strong metadata, BI tool vendors have not yet produced a tool that gives anyone simple access to every piece of data in an organization.

The implications:

• A few folks do have the need, desire & technical skills to get and analyze their own data.  These folks are called data analysts.
• While it’s not sexy in terms of BI (is anything sexy in terms of BI?), the vast majority of folks have structured jobs that require access to a limited range of data and they usually need it in some set format (e.g. this week’s accounts receivable aging report).  Assume that these folks need BI tools that provide predefined reports into which they can enter a few parameters - tools like WebFocus, Crystal Reports, and SQL Server Reporting Services.  Also assume that these folks will NOT create these reports on their own - you will need technical experts to create and maintain these reports.
• You are far more likely to see wide usage of your BI systems if your business processes are designed to be data driven.  Business process design, along with a culture change towards being data-focused is a prerequisite to widespread BI adoption.  It is also hard, time consuming work.
• Widespread BI adoption isn’t always the correct measure of success.  A $2 million BI system that serves just one user could be a major success if that one person makes or feeds input into multi-million dollar decisions. 

So, if you want a clear path to ROI, rather than starting out to build a BI system, start out to change your organization.  Then, figure out how and where BI is necessary to enable that change.

• Which tables are being used and which aren’t?
• Which queries are run most often?
• Which queries gobble up the most resources?
• etc.

Armed with information like this you can do things like:

• Eliminate unused tables
• Develop strategies to improve the performance of troublesome queries
• Determine if your warehouse is really being used at all

In the end, monitoring like this can help you improve and, perhaps, lower the cost of your data warehouse.  You might want to give it a try.

The question I have is: With the ubiquity of web access, do we really need to be putting dollars and effort into supporting new BI delivery platforms?  Since web delivery has improved so much over the past few years and promises to move even farther, do we really need mobile BI apps?  Can’t we use existing, web-based BI to support multiple needs?  Are tablet vendors planning to stop supporting their web browsers? I doubt it.

To be clear, I am not doubting the need for BI on the go but I am doubting the need for BI software built solely for mobile devices.

I just spoke with an old contact, a sharp data warehousing manager here in Detroit and he had the same opinion.  I, also, recently read a strong blog posting on this subject (click here for the article) on the Dashboard Insight website that explains why dedicated mobile BI apps just don’t make sense.

Now, I’m sure there are some applications for which dedicated mobile BI Apps are a good fit but I’ll bet they are few and far between.  I am open to other opinions, however.  Think I’m wrong?  Post your reply and let’s get a conversation going.

Thanks!

What’s the first step in building a data warehouse or a business intelligence system?  Defining the key performance indicators (KPIs), right?  Wrong!  KPIs are certainly great to know and can definitely apply when you’re developing BI applications like management dashboards.  But, BI is NOT about management dashboards or data warehouses or query and reporting or QlikView or Business Objects…

Business intelligence is simply about capitalizing on data that was captured for other purposes.

I was struck by this thought over the Thanksgiving holiday when speaking to my brother in law.  He’s an executive with an up-and-coming, private-equity-financed distributor.  One night, his CEO had an epiphany

We know what people buy but we don’t know if what people buy is generally correlated with other things that they buy, or should buy.  If we knew this, we could encourage folks buying one thing to also purchase its natural accompaniment.

For those of us who have been in the BI business for long enough, this is a take on the classic ‘beer and diapers’ data mining example (click here for more on this BI ‘fable’).

This is certainly a use of BI, of capitalizing on data assets but it doesn’t really work in the way that folks expect BI to work:

• It doesn’t really start with a definition of KPIs
• While it may use a data mining tool, it doesn’t use dashboards or query tools or other, common, reporting tools
• It may use a data warehouse but it may, also, just use data assembled for a one-time analysis

In any case, when thinking about BI, the vast majority of companies need to stop thinking about BI.  BI is not the point.  Doing something extraordinary is the point and, if using data assets gets you to extraordinary, then BI is the mechanism.

Well, a recent client in New York has a great approach to ensuring that his new BI system gets used.  This senior manager has a set of subordinates reporting to him.  He’s a very data-savvy guy and wants his folks to be data driven, rather than flying by the seats of their pants.

So, when his new BI system became available he sat down with his managers and required each of them to pick two charts that they would review with him at their monthly meetings.  Charts, of course, are built around key metrics and dimensions.  Thus, in order to optimize their performance, his folks must keep their eyes on these metrics.

With this approach, this manager is showing that he fully supports the BI system while pushing the cultural changes necessary to be data driven and make sure his organization gets the ROI it expects.

Do you believe in being data driven?  Do you believe in your BI system?  Prove it!  Don’t passively hope that your folks will use your new BI toys.  Require them to make BI a key part of how work gets done.

Want to kick around some ideas?  Drop me a line at btaub@dataspace.com.

— Ben

For years we at Dataspace have been saying that, rather than picking a corporate BI Standard, companies should pick standards for business-focused BI applications (e.g. Dashboarding, OLAP, Ad hoc query, online reports, GIS, etc.).  Interestingly, the Infobright speaker pushed the same concept for databases.  The point is that there isn’t a job like, “Database.”  Instead, there are jobs like high performance OLTP, BI and reporting, unstructured data, etc.  

It makes sense.  Think about automobiles.  You don’t buy a generic, “Auto”.  Instead, you buy a sedan, or a sportscar, or a station wagon, or a pickup truck, or a van, or an 18 wheeler…  Could you use a sedan instead of a pickup truck?  Sure, for some jobs.  Is it wise to buy a sedan if what you need is a pickup?  Probably not; After all, how many shovels full of compost do you really want to be carrying in the back seat & trunk of your Altima?

Anyhow, if you’re having BI performance issues, this technology is definitely worth a look.  Want to kick it around, let’s talk!

— Ben (btaub@dataspace.com)

It seems that I can’t go to any client nowadays without them mentioning Endeca.  Usually it’s because the marketing department is bringing the tool in and violating all sorts of corporate BI standards.  I’ve heard mixed results.

In any case, this news item is very interesting to those who are on that Endeca path.

— Ben

Others companies, on the other hand, are stuck in a mindset of data simply as a necessary byproduct of operations.  Once they’ve recorded the transaction they can pay their taxes, publish their financials and then be done.  They throw it into a data warehouse because that’s “what everybody does nowadays” but no one really uses it thereafter.

How does your company’s culture treat data: do you have data because it’s necessary or do you see data as an asset, constantly thinking of how you might capitalize on it?