Microstrategy Blog

I wouldn’t say that it’s commonly overlooked, but I’ve seen it overlooked by some developers…simple and streamlined data sources. There’s basically two ways that this can be achieved: single reports, multiple reports.

Keep in mind as you are creating these reports that you don’t want to design a report that will be used as a data source that contain more that what you need. If you just need the current price of an item on your store front, make sure that your report is built to pull back the current price…not every single price with a view filter for “today”. A lot of the usability and functionality of a Dashboard comes from the amount of time that it takes to run it. Trust me when I say executives don’t like to wait for 5 minutes just so they can see what the inventory level of one product is. Make sure there’s a little “cubing” and every attribute and metric that exists in the report, you’re actually going to be displaying.

As a rule, I like to create reports specifically for dashboards, that way I can work with them from Development to Production, and I know exactly what to expect. I tend to not make these reports visible.
I put them all in a hidden folder, in this case called “Source”, and under folder properties, there’s an option to make it hidden. I don’t want these reports accessible to the general public, unless there’s a specific search, and I don’t want to deal with security issues and user group functionality, so I just avoid dealing with those settings in this case. We’re keeping this higher level, so for clarification purposes, this is a dashboard that is going to be visible by everyone. There are no user or object level security in anything that I’m going to be going here.

Once you’ve selected your data set, the next option is to select what kind of dashboard you actually want to create. MicroStrategy has several templates at your disposal, as seen below.

Four our purposes, we’re starting from scratch. The image above is actually in Desktop…but, the medium I’m going to be doing most of this in is web, simply because it’s easy to flip back and forth in the web environment, and actually see what you’ve created, as it’s meant to be seen. As another note, if you’re on a developer box, and you’re not necessarily sure about your companies IT rules, now is a good time to check.

MicroStrategy works on all of the major browsers, and you’ll see some differences in some of the data as presented in Firefox, IE, and especially Safari. I’m going to be doing my development on IE and Firefox for the most part, so if you’re a Mac shop, or you have weirdos that browse in Safari or Chrome, there’s some extra homework you’re going to have to put into the process.

Next post, I present my sketch/storyboard for what I’m going to be presenting. I’m thinking right now this is going to be a two tabbed report, with a selector on each page. So, conceptually, this means two reports. One is going to be at the “Item Group” level…since my project is going to be cell phones, that group is going to be “Manufacturer”; think Blackberry or Apple. The next report is going to be specific to the Models. I’ll have the data aggregated at the two levels that I care about. I’m going to avoid from getting specifically into what drives the values of the reports (trade secret), and some of the data might be jumbled.

One of the clients that I have through my side gig (Orange Box Tech) has given me permission to document the Dashboard creation I’m going to be doing for him. I know that this is a subject that many are interested in…simply because what Google Analytics tells me so. So what I’m going to be doing over the next few weeks is taking you through the steps that I do when I create a dashboard, from concept to execution, hopefully as granular as I have the patience for, and hopefully with lots of community feedback.

So, the first step, which I can’t really do screen caps for, is to sit down, and in depth figure out from the end user, NOT EXCLUSIVELY JUST THE DATA, what questions they have, and what they’re trying to glean. This doesn’t just mean put all of the data on one screen, but instead, get at the root of the problem that they’re trying to solve. This means a lot of questions…and learning and understanding the application of the business application of the data and not just the data itself.

This is just the basic intro, and the “face of things to come” I suppose.

Over a year ago I put this link up. (LINK!!1!!). I just got a new comment on this post I thought worth sharing from “Someone MicroStrategy is REALLY trying to piss off” (that’s his/her name).

As to the search terms, when I’m evaluating a product for installation onto my company’s servers, I always google for productname sucks. I’ve found out more interesting bugs, shortcomings and little dirty secrets about quality of support or pricing gotchas that way than you’d apparently believe. Sure, the end user types that would use MicroStrategy are too uptight to use a word like sucks, but the IT people are the ones whose opinions I value. When it all comes down to dust, 90% of BI users are sales drones and beancounters that don’t truly have any valid perspective on evaluating software other than whether they think it looks pretty and whether or not it’s easy for them to use.

In terms of MicroStrategy, I’ll leave out the bulk of my story and just relate the one glaring WTF that is really pushing me to drop MicroStrategy from our number 1 BI candidate down well below several other companies. I called their support folks because their Linux demo VMWare appliance is built improperly and so it breaks when you try to do some things. In the process of attempting to get me sorted out, the tech I spoke to suggested that rather than using the IP address of the VM I put localhost into the address bar of my browser, and attempted to argue with me and tell me that it would get somewhere other than my own desktop PC. Any qualified IT person (and a good many power user end user types) know that localhost always, ALWAYS points to your local machine (at IP address 127.0.0.1 or the equivalent on your setup), and will almost never even send a single packet of data off your PC if you attempt to hit that address.

That might not seem like a problem to you, but that’s such a fundamental misunderstanding of network application troubleshooting that it really just blows my mind. I like to try to believe that the managers of a support department at a software company would be able to recognize that powerful of a lack of knowledge in their employees that they would know to either send them for training or put someone else on the job. Time and time again I’ve seen BI vendors with either an utter lack of concern for that sort of issue, or that are completely managed by the type of people who would be the end users of their product, who have absolutely zero technical competence or comprehension. As the person who has to install, setup and maintain whatever BI app I decide we’re going to use, it’s just amazing to me that these companies charge tens, sometimes hundreds of thousands of dollars (often yearly) for what is essentially a support contract.

I know MY company isn’t spending 5-6 figures on an app with support that poor. In this economy, you’d think they’d be concerned about that…

Valid points.

UPDATE: MicroStrategy Responds

First, I’d like to point out that it is very wise of you to consider technical support in your overall BI evaluation. Quality of technical support is a critical factor to success of any enterprise software deployment and one that is often not given appropriate consideration during the evaluation process. The fact is that the high quality of MicroStrategy’s Technical Support is consistently recognized by the top industry analysts (Gartner, BISurvey, Cindi Howson, etc) as a significant differentiator between MicroStrategy and other BI vendors.

That said, the interaction that you’ve described certainly appears to fall short of our standards and our well-established track record as world class support organization. I’m confident that this experience was an anomaly and would recommend that you contact support again and request to speak with a manager. I’m sure that they will be happy to review the ticket to ensure that we resolve your current problem(s) and that we conduct the appropriate review with the engineer you worked with.

Last week I’ve attended a Free BI Class organized by MicroStrategy in Toronto, to see what’s new.

The presentation was really well planned – a mix of the usual sales pitch and a nice hands on web and desktop exercises.
Some new (at least to me) things that they’ve been working on are a great looking app for iPhone and some new geographic widgets, so heads up BigDataLabs. The app comes as no surprise, now that Apple no longer supports Flash. It takes advantage of the iPhone controls, including the G-sensor.

As a side note, there was a SAS training on the same floor as the Free BI Class, and the participants seemed to have a lot of fun in there, judging by their laughter. Our MSTR sales guy came with an awesome explanation – “Probably someone said it can be deployed in three months”

Business Intelligence is complicated.

IT people think that they have all of the answers for all of the problems, and that answer is “data”. Just give people the ability to drill through whatever it is that they want, the ability to pick whatever they want out of the giant metric bin of values, and they’ll solve problems, right?

In practice, it’s never that easy. The IT department seems to forget at time that while they might deal with the data, they aren’t the end user, and while they understand the warehouse, they don’t use it to make directional decisions. The response of some is just to throw it all out there, and have your user base sort through it, gleaning the pearls of wisdom that may or may not be there…don’t worry about the fact that accountants, finance department, managers, strategic planners, and executives have never used the tools before, and might not be technically inclined; that’s on them. Sometime the myopia of the data managers leads to poorly implemented systems.

In a great white paper by Kevin Quinn, VP of Product Marketing for Information Builders, he addresses this issue in depth.

He states:

Even a simple data warehouse has hundreds of columns of data, and it’s not uncommon for more complex systems to have thousands of columns. When an end user is faced with a blank canvas, thousands of columns of data, and hundreds of accessible features, complexity is automatic. “Where do I begin?” is often the first question, shortly followed by “I don’t have time for this,” or “I give up.”

It’s important to remember that while we might be quick to trumpet the value of in depth drill maps, predictive algorithms, and complex data mining tools, it’s the end user that uses the data on a daily basis to make the strategic decisions that a company requires. As a data warehouse and business intelligence developer, it’s not just our job to build systems, it’s also our job to take the time to ask the right questions. What works for the technically advanced, might be useless for the 90% of people who are not, and have neither the time, nor the drive to learn systems that might be our life blood.

In the 60′s, Theodore Levitt wrote the industry altering article Marketing Myopia where he criticized the marketing professionals of the time for their narrow understanding of the industries that they were in. Levitt concludes, “…the organization must think of itself not as producing good or services, but as buying customers, as doing the things that will make people want to do business with it.” As BI professionals the end user is our customer, let’s make sure in addition to focusing on the warehouse life-cycle, and data freshness, we take the time to make sure that our user base wants to do business with us. We achieve that by starting the conversation:

What do you need?