2010

Business Discovery Blog Archive

May 2010 Previous month Next month

Acing the Interview

Posted by mmy May 14, 2010

I spoke to an executive who downloaded our free desktop BI software the other day. He mentioned that he downloaded the software because he was interviewing for a job with a company that used our BI and he wanted to find out about:

  • the volume of data that could be analyzed
  • how easy it would be for him to develop his own dashboards, charts, graphs, and pivot tables
  • the drill down and ad-hoc capabilities
  • costs and time associated with training power users and other end-users

He also asked about cases where our BI was able to succeed at other companies in improving company performance or reducing costs to increase cash flow. Lastly, he asked questions about using our BI to make strong presentations to other executives.

I thought about how this candidate is going to create a more favorable impression for his interviewer than others who didn't know as much about the BI that they would be using.

I also thought that if I were an interviewer, it would be insightful to ask interviewees what BI they used, and the type of queries and information they were accustomed to conducting and accessing in order to increase or decrease key metrics.

Ultimately, perhaps the most important question is whether candidates could accurately state the total benefit received, the total cost of ownership and ultimately the ROI's associated with their BI projects and implementations. Answers to these questions could quickly reveal a glimpse of the performance capabilities of each prospect. Are they the type of executive who continuously seeks to improve their insight and use of technology, or have they reached a status quo?

Part 2 of 2

 

In the previous post, I discussed how prior "successes" in data warehousing and data mart creation in my business life had not necessarily translated in to business intelligence successes. Beautifully modeled data marts can go large unused. Rock solid and comprehensive data warehouses can be all but ignored by business users and BI teams. So how and why does this happen? What are we doing wrong?

I submit that the problem is not with the modeling and building the BI data structures, but rather with the process of scoping them in the first place. How would a business user know what requirements to include in a data warehouse that is supposed to meet his/her data mining needs to perform value-added business discovery and data mining? Consider that this business person has little or no knowledge of the contents of data sources around his or her company. The business users and I.T. both need a way to visualize and communicate the information opportunities that are locked away in their data sources. Once we know where these information opportunities are, we can proceed to gathering requirements against them for a data warehouse or data mart. This is not a discipline that is mature, technically enabled or staffed today in most companies. So how will we do this?

Simply put, BI is the best discipline available to pinpoint warehouse needs. Yet, we're told that the warehouse needs to get built and perfected prior to BI. A catch-22 at best. A land mine at worst. So what do we do about that?

I'm seeing a new approach crop up with large QlikView clients. They are, of course, using QlikView as the front end to navigate and explore data structures like data warehouses and data marts. But they are also now starting to use QlikView as a discovery tool prior to building new BI data structures. Data warehouse teams are sitting down with business users and performing interactive discovery sessions using QlikView to connect data sources as potential inputs to the warehouse. Is that the chicken before the egg? Maybe so. But to business users it's like have a full refrigerator waiting for them to experiment and lead us to the menu they would like for lunch. What a great thing for I.T. and for the users!

With this approach, IT gets a seat at the table of discovery. IT is there for the "ah-ha" moments of epiphany and information opportunity. IT learns more about the business and potential value of BI in these meetings than in any others. The business teams see the value of IT in collaborative sessions like this, increasing the likelihood of funding and support for new projects and efforts. If you haven't seen this happen before, bring QlikView into a data requirements meeting and try it. Your users will thank you.

What's your opinion? If you've seen your company stuck in that rut of creating BI data structures in anticipation of use (if we build it they will come) send me a reply and let me know how (or if) you've gotten them out of that rut. I know there are great successes out there leading the way to better BI. Tell me what you think.

Filter Blog

By date:
By tag: