What are the plans for SAP’s planning solutions portfolio?


A quick jog down memory lane, as I am flying from PHL to SNA. About 10 years ago, I went to an SAP training course in Northern CA to learn SEM-BPS . My background at that time was all ABAP, BW and some SD/FI on functional side. Till today – that BPS training by Peter Jones has been the best class I ever took for an SAP technology, and till date – BPS is the fastest I ever came up to speed on any SAP technology.

With all its technical beauty, BPS had its fair share of problems too. One such issue was the front end in Excel. It was a powerful front end, but BEx had an excel front end too. It was not an efficient process to use BPC excel for planning, and then switch to BEx for reporting. As a result, we used to replicate a lot of reporting functionality into BPC layouts to make life easier for users.  Needless to say, users were not thrilled – and this was not good for TCO.

BPS was not the slickest way to do planning in an enterprise, but it did its job within its limitations. SAP did the right thing soon after – and brought out integrated planning – popularly known as BI-IP. Now, BEx was the one client for planning and reporting. But IP could not do everything BPS could do – and there were a lot of consultants who hated it, and thought it was a step backwards compared to BPS.

 

One  issue with IP was lack of CRM integration. CRM planning could not be done with IP – it still needed to be done using BPS, due to a UI limitation. So market planning, TPM etc continued to use BPS while others moved over to IP.  Incidentally, the CRM integration to BPS is nothing to write home about – it is as un-user friendly as it gets. But it did its job at the time.

Then SAP acquired Outlooksoft. When I was a BPS consultant, I used to think that SAP will surely buy Hyperion. But Oracle bought them instead, and SAP took Outlooksoft, which is a Microsoft based product.

Outlooksoft’s strength was superior user experience. When I played with it – not in a project scenario, I think it was at an SAP booth at Teched or SAPPHIRE – I liked it, and thought it was pretty fast too. The only thing I did not like was that there was no netweaver integration. But SAP said they will come out with a netweaver version soon, and they did.

By now, SAP had at least 4 planning options – BPS, IP and 2 outlooksoft versions, which got renamed to BPC. Well, same with consolidations part of the house too – with EC-CS, BCS, BPC, Cartesis. As far as I know – everything was and is supported till date, and there is a “it depends” answer if SAP is asked what tool to choose.

So much for history – lets fast forward to the shiny new world of HANA. So the stand-alone HANA is mostly a datamart on steroids, with no generic killer app till date. SAP came up with CO-PA accelerator, which is pretty good. Then there is smart meter analytics – which I never understood why SAP did, instead of something else with more widespread appeal across the install base. And all this time – SAP, customers and partners have been asking “where is the HANA killer app?”.

So the next generation of HANA came where BW could use it as a database. The moment I heard about BW on HANA – the thought that crossed my mind was “wow – this is exactly what SAP needs. Not just for reporting, but for planning”. BPC netweaver is not exactly the fastest planning engine I have seen. In fact, I am not so sure how well it will work with big amounts of data, unless customers also buy BWA.  I am sure SAP will claim it is quite good on performance etc based on what they have seen – but based on my own limited experience, it has some ways to go.

Remember the BPS question of why do I need separate excel client for BPS when BEx already has one –  And then SAP coming up with IP that solved that issue? One would have thought that lesson was learned well by SAP – but guess not. BPC has its own excel client, while BEx, and Analysis for office also have excel clients. It beats me why analysis client couldn’t have been enhanced to cater to BPC too. There is more – remember the postable nodes in BPS that saved many a project some valuable time in implementing? Where did that disappear in the new products?

In my mind – BPC on HANA is a no brainer for SAP to prioritize. That is a killer app that SAP and Partners and Customers can all be happy to implement without the necessity for marketing  hype. Now, I do know that BPC on HANA is in the works, and will come out some day soon. I also understand from some blogs on SDN that SAP is building a planning layer in HANA that is different from BPC (but probably can be used by BPC later I suppose). The question is how many evolutions will it take before it moves all the performance hogging functionality into the HANA layer and provide true disaggregation, and lightning fast performance?

 

Since ECC on HANA is also around the corner, will it take away investment from BPC on HANA?

And will SAP converge its planning technologies? Can SAP incorporate the best of BPC’s user experience, IP/BPS’ netweaver integration, NGAP’s HANA friendliness, R’s predictive abilities , BWA’s OLAP processing speed etc into one coherent product? or- as a buddy warned me today on twitter – will it end up with BPC’s integration and BPS’ user experience if SAP went down this route?  And will SAP come up with a full fledged cloud based planning environment along the lines of tidemark ?

I am sure SAP has some smart people doing its product portfolio planning, and that everything will converge at some point. But the sooner it happens – the more their customers will appreciate it.

I am not sure if the agile development paradigm used by SAP these days will help or hurt the speed of such integration. When different scrums happen for BPC, BW, NGAP etc – the project manager in me keeps thinking they will find it harder and harder to prioritize integration dependencies. Each product might get unique benefits for sure – but customers only care about overall solutions at the end – not individual products. With a distributed development organization like SAP, I would expect this to create more silos – not less. I have seen fiefdoms develop in big globally distributed teams I have managed in my past life – but those were in implementation projects, not product development. I have heard that SAP uses scrum of scrums to address this issue – so I trust they have a grip on this. And in any case, I am out of my depth when it comes to product development – so I will leave it at that.

Random parting thoughts –

1. Now that SAP plans to put HANA as the engine on every SAP product runs, and since Vishal has announced ECC will work on HANA in Q4 – I wonder if planning will stop being a separate system, and get folded into the business suite. On first thoughts it makes sense to me for a large set of customers to do cross domain planning to pull it back into business suite, and then let HANA deal with OLTP/OLAP planning loads efficiently. Planning is one of the most collaborative aspects in an enterprise – so I think streamwork integration is also a no brainer in this situation.I have no idea what are SAP’s thoughts on this – but I am very curious on what is the strategy for planning in the nirvana state.

2. A more technical question – if HANA is the database for BW going forward, will it make sense to convert most cubes to an account modelling structure to make use of columnar storage? Has any one tried to compare this with a traditional key figure model in BW on HANA to check performance?  If my instinct is right – and account model does help – it is definitely a plus for BPC, since it only supports account model now.

Only time will tell – or may be one of the EPM leaders at SAP can explain that to me at some point, ideally as a comment here, so that everyone can read it.

Innovation – the price to pay


Everyone and his brother is out there on social media lamenting on lack of disruptive innovation.  While I don’t pretend to be a big innovator, there is a portion of my work that can be termed as “innovation” , or even “disruptive innovation”.  And after a few years of doing this, I can say with confidence that it comes at a high price, and it is not for everybody. Admittedly, I have come close to getting out of “innovation” a few times – but have continued to keep at it.

 

First issue is identifying what to work on. On an average, I consider 10 ideas to pick one to work on. These ideas come up as I talk with customers, colleagues, mentors, mentees and some times while watching TV or reading a book in a plane.  I will jot it down the soonest I can – and usually have an assortment of paper napkin sketches, notepad files etc where ideas are scattered.  I am not the only one who comes up with ideas – everyone in my team contributes ideas. Then I shortlist these based on only one criteria – is this something that can make my customer’s life easier in a tangible manner? If the answer is no – I ruthlessly cut it off.  This hurts egos more than one would think – especially my own. Some ideas that look brilliant as I jot it down in a plane ride look ridiculous when I think about it over a weekend.  And occasionally, it upsets my team when I kill one of their ideas. This needs to be done with some balance – if all you do is kill idea after idea, it just becomes a de-motivator.

 

Next up is recruiting a team to work on the idea. This is probably the hardest part – not everyone likes to do everything. And people have a life outside work, and value their work life balance. I have to respect that, and still make it work. And where I work, the team is spread across the globe – and typically we catchup over late evenings and weekends to work on innovations. No one pulls rank when it comes to innovation – people are free to join and drop off . My philosophy is that if people work on innovations voluntarily, it works out better than if it is forced down their throats based on official rank. So far it has worked out well – and I could not have asked for a better set of colleagues to work with.

 

It also improves teamwork and delegation abilities. I understood early on that delegation is the key to success. And I try to teach that to everyone in my team. The trick to delegating successfully is to make sure the team understands what is being delegated, and what is their authority and responsibility.  You cannot just delegate responsibility ! But once they are comfortable with taking on authority, and willing to be held responsible – the results are unbelievable. Irrespective of the result of the actual innovation project – they develop into amazing leaders, and it is the biggest gratification I get in my job. I did not invent this – my managers took this approach with me, and I am paying it forward for the next generation.  Some times, things don’t work out as planned and an inexperienced person might screw up. It is up to the manager to make sure there is sufficient support when failure happens, and no one is thrown under the bus.  Especially when it comes to disruptive innovation, this is key. If you cannot live with this – don’t start down this path.

 

And then there is the price to pay on family life, hobbies etc.  I had to sacrifice a lot, and so have many people I know. My wife supports me to a great extent, and without that I would not have taken this up. It is hard to balance – and once you are deep into an innovation project, it is extremely hard to switch off completely. This is rather unfair for the family, and has to be carefully weighed before starting, and then periodically throughout the project.  At the moment, the only way I handle this is to take breaks between innovation projects so that there is some balance on personal front. The work-life balance is a personal decision – and if you care enough about your team, you should watch out for their work-life balance too.  All of this needs to be factored in when you plan the project. Nothing ever works to plan, and you need to balance aggressive milestones with a dose of reality.  This is a learning process, and I am definitely in the first half.

 

Finally – disrupting the “life as usual” for a customer, or for your own company is a challenge. it does not matter if you spent 3 months working every waking hour on this project. If you cannot make a business case and SHOW things will get better, no one will accept your innovations. And then you have 2 problems -1. risk of wasting the blood, sweat and tears spent on current project, and 2.  getting investments for next project from management.  And you would have broken a lot of glass before the final solution is pitched – so there is a potential long term price to pay as well.

 

And one last thing – be prepared to take the least amount of credit for success, and maximum amount of criticism for failure.  It is easy to know if this is working or not – if it is not working, you will soon find that there is no one left working shoulder to shoulder with you any more.

 

So with this big price tag – will I do this ever again?  ABSOLUTELY ! I won’t change a thing – it is the most satisfying part of my job 🙂

 

 

 

 

 

 

 

 

 

 

 

 

 

 

As HANA matures, where should SAP focus?


It is not news that SAP is betting the farm on HANA. SAP’s sales and marketing organizations have done a tremendous job in making sure the HANA message is delivered loud and clear to its customer base.  SAP sold more that 100M Euros worth of HANA last year , and will probably do much bigger numbers this year too.

 

BW on HANA is already out, and is touted as a killer app. It might very well be a killer app – but that remains to be seen. In our internal lab projects, it is not as smooth as we expected. It is a bumpy road – but it is definitely fast. DSO activation for example is super fast, but it will also fail inexplicably, and then the time you save in activation is lost in trying to research what went wrong. The good thing is that since we know it is very fast, despite the teething problems – I am sure lot of customers will buy it. And to a certain scale, software is sold in bundles any way – so nothing will stop SAP from selling HANA licenses. Customers actually using HANA in production is another story altogether.

 

Buying is just a first step – the bigger question is who will implement. As of now, mostly SAP PSO is doing the implementation. But that is not a scalable model at all. PSO cannot satisfy the market by themselves, and SAP should be aggressively pitching to SI partners to sell and implement BW on HANA. You get some benefit by just doing a database switch to HANA, but the real benefits come from simplification – which means redefining the datamodels and data flow.  And that takes time and expert industry knowledge , and not just technical skills.

 

SI partners are terrific at implementation, and building accelerators for implementation. However, what they are the best at is NOT building apps. For apps, it is the smaller developer’s world. But then, SAP HANA is not yet available for smaller developer to do something about productively.  SAP has made a good first step. A sandbox is available for them to play with. But it is not a full development environment they can create a product, license it and sell it in a store.

 

So on both sides – implementation and apps building, SAP has some ways to go. If they don’t get their act together in short time, next year – we will start hearing the HANA shelfware stories.

 

There has been some announcements meanwhile on HANA for SMEs that I saw a few days ago. I am not convinced how SAP is going to sell HANA to SME clients. SME is primarily a market for hosted systems – public or private.  Why would they care about the nuts and bolts of the database that their system is based on? They just expect it to be reasonably fast.  As I mentioned to few friends on twitter – not verbatim –  “If I hire a landscaper to mow my lawn, why would I care if he uses a Black and Decker electric machine, or a manual push mower?”. I don’t – I just pay the guy to mow the lawn, and will hire another one if the first one does not do a decent job.  If there are special apps that are HANA based that give me a positive top line impact, there is a case to pay a premium for HANA. Otherwise, I doubt this will fly.  Especially after companies like Workday have made their cloud offering in-memory based fully and not charging specifically for it, it is hard to ask a customer to pay a premium for modernizing an old system.

 

Once BW on HANA is out of the way, obviously SAP will come out with ECC on HANA.  With most of the heavy lifting in ECC done in ABAP layer, customers will not see any huge benefits buying HANA as a database. And it is a few hundred million lines of code – so SAP is not going to rewrite everything in ECC to work on HANA. This essentially means SAP needs to build more things like the CO-PA accelerator, and more specialty apps for ECC that needs HANA.  Which then needs the small developers and SIs to play a big role to scale it meaningfully.

 

So, will SAP make the effort and actually make it work for the small developers and SIs ? or will they try to do it all by themselves?  And while they are at it – I hope they try to make this work for mobility, cloud and everything else too.  one approach – is to stay the way it is now. SAP will try to create the market, with the hope that some day in future partners can scale it. Or they can make it work for partners and smaller developers right upfront, and build a larger momentum.

 

None of this is new to SAP – several people have already made the case to SAP on these matters. And to SAP’s credit, they are good listeners. Now the only question that remains is when they will act.