In The Enterprise Software Race, No Horse Ever Loses For Being Slow


Another random rambling – this time caused in part by a twitter conversation today morning, and a few analyst reports I got around to reading at lunch break. And finally I saw this past homework sheet that my daughter filled last year , where she says she wants a job like the one her daddy has.

Image

I work in this great industry, and yet I continue to be amazed (and amused) by the logic of big and small companies that make our industry. An entire set of companies operate as if the forces of market just don’t EVER apply to them.

For software, supply is a non-issue in most cases. You build it once, and you sell it many times. And one way or another, you get customers to pay for maintenance and enhancements – either explicitly in case of on-premises companies, or built into subscription costs for the cloud companies. This model worked great for many years because only a few companies were competing in each segment – be it ERP, Databases, CRM or whatever. The threshold of entry was always high enough so that supply side remained a vendor advantage – Supply won over demand , believe it or not.

Software was not the only industry where this happened – even in the world of tangible goods, we have examples to learn from. Look at semiconductor companies. Till very recently – they defined demand of their customers based on their available capacity. Customers were told how much they will be allocated – and customers could not do much about it given the capital needed to stand up a new fab was beyond the financial strength of  most companies. Well, these companies eventually had to turn (painfully) to pure demand driven companies – and the same is bound to happen to software companies too at some point. In a few cases, it is already happening.

Along came cloud, and it made it easy for anyone to be a SW player. When I passed out of college – it was hard to start a SW company given there was no cheap way to access internet or buy hardware. Many good ideas never saw the light of day and many bright students shelved their ideas and took employment at big companies to execute on someone else’s vision. That is so not the case now – it costs very little to start a new software company today in comparison – at least from a “production” point of view.

Challenge today is that of demand (as in top line revenue) – not supply. Since threshold of entry is low, everyone and his brother is now in the SW game. And not surprisingly, the quality of ideas is poor in many cases, and there are no “easy” customers to find . So what is one to do – you hire the best sales person(s) you can afford and ignore the cost of selling to “buy” market share.

Profits be damned – it is all about growth. The trouble with this model is that you probably can never take your foot off the high sales/marketing expense pedal since competitors are also trying the very same strategy as you are.It is a mega race downhill.

Its not just high sales and marketing expenses that come with accelerated growth. To “buy” market share – acquisitions cannot be avoided either. The problem is that the owners hate to dilute their stock – so in most cases, debt is the only viable option. So between debt and the high expenses – the question is how long can such a company do its business . Debt is cheap for now – so probably they can all keep afloat for a while, but sooner or later, they will have to pay up. And it remains to be seen how many will be still viable and solvent at that time.

Then there are the companies who care only about profit ( EPS for the public companies ). They have the same challenges to generate demand – but instead of taking the harder route of increasing topline to create more profit, they play with other levers. They squeeze costs out of their system ( move to cloud, use labor arbitrage etc), they buy back shares aggressively and so on. Again, at some point – you run the risk of cutting into the bone.

Then there are the companies who try to take a more balanced view on top line and bottom line together. But they are in a fight of their life too – since companies who are aggressive on top line and companies who are aggressive on bottom line both have “trained” their customers on what to expect. So these “middle of the road” companies usually will have to resort to tactics unnatural to their DNA to fight it out with the others.

Customers “might” win in the short term when there is intense competition on vendor side, and that is a good thing. But in the long term, the very existence of some of the vendors might be questionable. So over the long term, do even customers win? or do customers also join this downhill race , maybe without even knowing it?

In short it is a mess – or I guess the more PC way of saying it is “It is an interesting scenario”. The extent of this mess is clear in the communication style of the leaders who run some of these companies. Every one touts they have the right strategy – yet very few seem to execute to it over time.  How fast can they drive forward while constantly watching the rear view mirror?

When I worked in the UK more than a decade ago, my friends got me hooked to watching horse races. Did you know that a horse never loses a race because it is slow ? That is how I understood it reading the coverage of races in newspapers and magazines. A horse  might lose because of bad training, bad surface, unfair handicap and a hundred other reasons. But NEVER will a horse lose because it was slow. If you watch our beloved industry from outside, I think you will feel kind of the same way about the companies that make this industry.

I do believe that the forces of market will eventually trump everything else – and I wonder how many vendors will stand when that happens and how many will bite the dust. Maybe it is time for this industry to get off the high horse called “strategy” and focus a little more on good execution.

And I hope this happens before my kiddo starts looking for a job – and yes it would be quite an honor if IBM (or SAP) employs her.

 

 

What Does BI Mean To You?


Totally an unstructured rant – be very warned ! 🙂

Over the last few weeks , a lot of discussions happened on BI between me and some friends . Essentially – why is it that BI projects seem to stay the same way it was always done even while tools became a lot better ?

To begin with – tools have become better , but not to the level where a user can use it in self service fashion in most cases . So, education is probably the number one issue in the context of BI. Education comes in many flavors – and the easiest one in my mind for a user is the actual tool training . So lets move past that.

There are a few things that have not changed from a BI project POV in several years

1. Users do not understand the data available to them

This needs a lot of bottom up and top down effort to fix . I think top down governance will hit a wall sooner than most of us estimate . Data needs to be explained for each user with real life examples, but that approach is hardly scalable.

BI project plans need to budget time and resources to fix this – but having seen no change in many years , I guess the inertia is just too much

2. Users do not understand what reports are telling them , and most of them have limitations in explaining requirements to IT or consultants

I have done elementary statistics type classes to explain data to users in some past projects . I have a feeling this needs a deeper look to see if such an approach needs to be standard in BI project life cycle.

Users have unrealistic expectations of BI in many cases. This movie is now playing again with predictive Analytics . I see a lot of users and consultants having limited idea of what a predictive model is telling them and what it’s limitations are . No wonder several of them crash and burn .

3. IT and consultants takes a one size fits all approach for BI , and spends little effort in acknowledging BI is personal , not generic

This won’t change till BI is no longer treated as a side kick for ERP . People personalize ERP quite a bit ( at least compared to BI) , and that rigor needs to get into more BI projects .

There are a dozen more things , but I feel better already after typing 3 to get it off my chest

Sorry – had to rant . Will try to not do this too often .

BW on Hana , How About In The Cloud ?


I have been talking to customers on BW on Hana for a good while now – about their plans to make use of BW on Hana, and what roadblocks exist for its adoption etc. Here are the top three concerns that I hear the most

1. Projects to migrate to BW take a long time to complete, delaying value realized by business
2. Due to the length of the project and the cost to acquire HW, SW and Consulting services – the initial investment to be made looks high for some customers
3. Is it possible to try a few scenarios in BW on Hana quickly before going all in with a full migration?

Last year, several customers asked me why they should consider BW on Hana. These days, I hardly hear that question – I get more questions on “HOW” they should go about it . And to help customers and partners with this , my team and I have been traveling across the world doing hands on sessions on BW on Hana as well as BI on BWoH. Several other teams at SAP have also been doing similar enablement sessions, so I think the “HOW” part will be adequately taken care of too.

But we still need to better address the 2 questions on length of migration projects as well as the initial cost. And this why I wanted to ask your opinion of putting BW on Hana on cloud, on a subscription basis. There are many potential deployment options like I scribbled in these pictures on what systems can move to cloud.
BW on hana alone in cloud

BW and BI in cloud

everything in cloud

I I really have no idea whether SAP can actually do any of these ( it needs to make sense on technical and business dimensions). So please do not treat this as an official SAP statement. My intention is strictly to present my thought process to the ecosystem and get some feedback from all of you. And of course , this is just an “additional” deployment option, not a replacement of on premises BW on Hana which I fully expect to continue.

Back to the 2 common concerns – how do we solve that? I think a cloud option is probably one worth considering.  Here is what I think might work

1. SAP or a Partner acts as the cloud provider and signs a subscription contract with customer via SAP Hana Marketplace

2. Customer gives a copy of current BW system to the provider

3. Provider imports and migrates the copy into their cloud, and does testing. Maybe customer can do some user testing too.

4. With necessary signoffs, the solution is cut over into a productive instance on a cloud that customer can access

5. Any extra data/ transports etc that are needed are applied, deltas initialized, BI tools connected etc

6. Customer starts using the productive instance of BW on Hana with some agreed up on SLA

7. Customer starts paying the monthly subscription, with some provisions for data growth, additional BI clients and so on in future

I probably made it sound simpler than it is – but hopefully the general idea is clearly coming across to you.

I think there are many advantages in the cloud model

1. Customer deals with one provider alone – not one each for HW, SW, Consulting and Support.

2. Since one provider has full control over end to end experience on multiple customers – economies of scale should kick in and result in less time to do migration, and less cost than customer doing all the steps individually via multiple partners.

3. With subscription pricing, there is no big initial outlay for customers . Monthly payments are predictable for budgeting reasons etc .

Of course there are some trade offs too that need to be considered

1. There might be some reluctance to move a data warehouse to cloud for fear of security. However, this reluctance is definitely coming down – and VPN and other security measures can be put in place .

2. Network can become a constraint for loading and reporting. However, given the speed of BW on Hana on both reporting and loading are faster than classic BW, some of this can definitely be compensated. Also, not all loads are real time into BW . There is of course the option of moving the source systems also into the same cloud and reap even more benefits.

Now the million dollar question(s) – what do you folks think about this? Do you think this will help more customers derive value from BW on Hana ? What other factors should be considered from the customer’s perspective ?

And about the third concern of how to get a jump start on BW on Hana without going all in – Do you think customers will like to get a Hana One Premium type system for BWoH that they can run in parallel with existing BW systems for just a few scenarios ?

Lets discuss here in the comments section, and pls fill out the polls below