Cubegeek

Microsoft's BI Marketing

The first time I went on a sales call with a guy named Richard M., I didn't realize that he had met with some marketing folks at Hyperion. So when he started drawing up his whiteboard presentation for Essbase, I suddenly thought that he was a genius. His pitch was RAMP. Reporting, Analysis, Modeling and Planning. Thus began one of a number of sales pitches to customers about the fabulous technology that was and is OLAP. Today Microsoft's Marketing echoes the same message with a bit more focus. It's called MAP.

The most important and difficult aspect of RAMP is the Modeling part. It's also the part that most companies fail to accomplish. When you have a multidimensional read-write concurrent access database, the great strength of it is that it manages business hierarchies and allows you to model your business. You'd be surprised at how few companies have a good model for their overall business, much less those smaller businesses that might work at the data mart level. That is why the Master Data Management business is in high demand. Getting that model right is often a painstaking and tedious process, primarily because it requires high level stakeholders to put stakes in the ground  and determine once and for all what every business entity and widget in the company is called, and then discipline compliance around that. So most every business has some level of fudge and compromise in their Modeling of business processes and benchmarking the same. WalMart did that heavy lifting long ago, which is why they can use real demand planning, but that's another story. For most of American business, one model is good enough, and thus a lot of technical capability in the BI world is left unexploited in the product stacks.

Monitoring is sort of a new term, but everybody knows they need to Monitor their business - that's what reporting is all about. And a good feel, a ubiquitous feel is better than a precise feel. The 80/20 rule applies. Considering how many folks have been living with Crystal and other derivative non-OLAP reporting systems, you can bet that a decent reporting suite will go a long way. Getting monitoring right, especially with near-real time tools, is a swift kick in the pants for any IT provider to business.

Analysis is as it ever was in OLAP. Being able to figure out the primary factors in a KPI's provenance is always a necessary component of driving business performance. Everybody with OLAP can do a good job here, and every vendor up the curve will continue to do well, so long as the engines below are powerful enough for the task. Microsoft's not so secret hole card is 64bit computing, which is easier to get than ever before. Man do I love those HP boxes. With 12GB of RAM, on quad core processors, a universe of BI is within quick grasp.

Planning is the hottest area of enterprise computing. It is the big revenue driver for all of the BI stacks in the industry, and it is keeping a lot of players fed. That's because financial teams get it. It's a job they do on a regular basis and that will ever be the case.

So you will see Microsoft and their partners speak to MAP as they move forward with Performance Point Server this year. It's an old tune sung by a new choir.

Change Is Good

As I move up in my career, I will focus more on questions of organizational enablement, and looking at a longer horizon for tech. I would like to apply some new approaches to the BI world.

So first things first. I am moving over to my new company this month and will be running the BI practices. We're going to be focused on Microsoft technology. No more Essbase in the immediate future. I will be thinking of Microsoft as a technology company rather than as a software products company - so thus I will think of my staff as artisans and craftsmen working with the raw materials of Microsoft instead of appliance installers working with the highly developed products of Oracle/Hyperion. What I am noticing is a serious deficit in the ability to attract and retain folks who are interested in the pure tech of Oracle/Hyperion, and a decreasing willingness to train up such folks. The result being a more limited ability to customize systems towards the appropriate workflows of organizations.

There is a kind of hybridization of systems knowledge when it comes to business finanical planning & reporting (which will be ground zero). I've observed that your CPA folks are the domain experts and your BI and DW folks are your tech experts. We talk about best practices in both areas and we adjust those to the budgets and schedules of the host company, but these best practices are not synergized consistently from one project to the next. That is because the cost of customization is still relatively high in the stacks of the enterprise vendors. I say that these stacks will ossify, that the incremental cost to making them more flexible will be prohibitive and that nobody will staff up to handle that. Therefore I'll be focused on staffing up people from a technology perspective who will customize from day one. We will attempt to bespokify the Microsoft 'product' which is actually a large set of commodity technologies in the .NET framework (or at least that's what I fervently hope).

Let's come right out and say it. The repository and backend to Hyperion Planning may be proprietary, but there are plenty of developers who are smart enough to build such schemas. A lot of them have already done so in IT shops with their own homebrew systems. I expect to integrate closely with these custom schemas with the extensibility I expect in the new Microsoft frameworks for BPM, and move from there.

That's the difference, and that difference will be all the difference. All I need to do now is scope out the market.

Solver baby!