HANA and the SolMan syndrome

[OttoGold]

I am carefully following the latest HANA (and other unimportant stuff) surveys and SAP representatives’ reaction to it. You may want to do some reading on what happened before reading my blog. If so then here are the useful sources:

1. ASUG survey that started the whole thing: ASUG Member Survey Reveals Successes, Challenges of SAP HANA Adoption
2. Blog by jelena.perfiljeva on the ASUG survey topic and the stir around it: Y U No Love HANA?
3. Blog by Steve Lucas on the ASUG survey: Thoughts on the ASUG Survey on SAP HANA
4. Hasso Plattner himself on the ASUG survey results: The Benefits of the Business Suite on HANA
5. DSAG survey: Demand for innovation potential to be demonstrated
6. dahowlett on the DSAG survey: Analyzing the DSAG survey on SAP Business Suite on HANA

If you made it here, let me share some thoughts with you. I must warn you that I don’t have much real life exposure to HANA and my thoughts are primarily based on what I consume from various sources like SCN or SAP official marketing. Combined with the customer surveys my information sources are very well mixed and hilariously contradict with one another.

The SolMan story

But to the point. Namely to the title of this article. When you read about HANA and customer being not so hot about it, what does that remind you about? It reminds me about the Solution manager. Note that I am a Security and Authorizations consultant working primarily with the basis component (which is the foundation of all ABAP based systems). I get to work with Solution manager a lot. I don’t claim to be a SolMan expert but I have enough of them around me to be reasonably well informed about what they do and how is the market for them as well as get to hear feedback from the customers.

I don’t want to discuss some recent confusions and disappointments of some of the customers about changes in the SolMan functionality. I believe the SolMan team on the SAP side is a team of seasoned engineers and they know what they’re doing. What I want to concentrate on is the perception of the SolMan as a symbol of the SAP basis and infrastructure as a whole. At that is very much the same bucket where HANA ends up as well.

Every customer that runs an ABAP based system must run the basis component (BC is the good old name), which means database, user administration, roles and profiles, performance, custom development etc. Every customer must run this and have an internal team (often combined with an external one) to run the systems. SolMan is something that wise people see as a central hub for many (if not most) of these things and if you deploy and use the SolMan wisely, it offers huge benefits. You run jobs in your systems? I am pretty sure you do. Boom here comes the SolMan central monitoring. You do custom development? Whoosh here comes SolMan’s CHARM, CTS+, CCLM etc. Seriously for many basis things (for security things less so) SolMan offers some way how to run everything centrally which in my opinion provides some nice benefits.

But how comes that I can see that many customers not investing into centralized basis operations via the SolMan? How comes that if the budget is cut, SolMan is axed in the first wave? How comes that so many people are trained on MM-Purchasing (random business example) but SolMan experience and understanding of the big picture is so rare?

In my opinion the problem is the following. The companies have a fixed budget they spend on IT. Part of the fixed budget is a fixed budget for SAP. The budget is fixed. Non-inflatable. No magic. Fixed. The SLA between the shared services centre, the competence centre or how you call the team or organization that provides the SAP services (and runs the systems) says that the functionality that keeps the business running must perform well, be secure and available, patched, people trained etc. It is a necessary evil for the rest of the company to have this IT basement and their budget, but that has limits. The budget is fixed and the outside perspective (and priority setting) is on what keeps the company running and making money. Tell me, haven’t you ever joked about “being just a cost center”? We don’t make money, we just keep the servers going.

So back to the SolMan. To leverage the SolMan powers you need trained and knowledgeable people. Such people don’t come cheap. Even more so every year we are older because you have these shiny start-up hubs all around the world, you have cool companies worth billions (like Facebook and Google with free food and a laundry service) and they push prices (of the smart heads) up as well as the number of available smart heads down. Anyway you know what I mean. More costs on people, on their training, on making them happy. Then you need hardware to run the SolMan on, you need to pay for the license, you need external support time to time, more patching, more auditing etc.

And what is the value? What is the benefit? Once you bend the company’s (IT team’s) processes around the SolMan (and win the motivation of the basis folks for the SolMan, all of them!) then you can see some (substantial?) savings (in the hopefully not-so-distant future). And all that only if people commit to use the new features and the size of your organization makes it easier to reach the point of break-even during this lifetime still.

So let’s briefly summarize:

1. Initial investment in the people, hardware and software
2. Investment into the change management process that would readjust your people’s mind-sets and processes around the new tool.
3. Savings are waiting for you in the future, some of them are rather theoretical and others will only arrive into your budget pool if everyone joins the effort.
4. The good news is that SolMan is around for long enough that you have the knowledge spread around pretty well so hiring someone for your team to run the SolMan is not like hiring a Tesla engineer.
5. In my opinion good news is that by slowly consolidating some of your process on the SolMan now and others later gives you the possibility to pay a series of small prices and get a series of smaller returns over the time.
6. Last but not least SolMan does not do that many things that you can’t do without it. Can you name any such things? You can only do them on SolMan? Not with Excel or lots of clicking in the local system?

SolMan is being underestimated. Underused. Underappreciated.

The SolMan syndrome

Now back to HANA. Did you try to replace the SolMan with HANA in some of the comments above? Just try it. How comes that so many people are trained on MM-Purchasing (random business example) but HANA experience and understanding of the big picture is so rare? To leverage the HANA powers you need trained and knowledgeable people. Once you bend the company’s (IT team’s) processes around the HANA… Last but not least HANA does not do that many things that you can’t do without it, with Excel or lots of clicking in the system… I know you can see where I am coming from, right?

At this point I am taking a ten minutes break to re-read the Hasso Plattner’s blog…

We can immediately filter some of his points out as they are irrelevant for customers (or maybe it is better to say they are irrelevant for me and I am a trained SAP engineer, I do this for living and the future of my family depends on the success of SAP at least partly, I engage on SCN and I talk to SAP engineers… I think I have showed enough dedication and loyalty than most of the customers).

Anyway I don’t want to argue here with Mr. Plattner as I respect him very much so I will paint my own picture here and you, dear reader, can choose what is closer to your everyday reality.

The two most important things about HANA are:

1. The cost that the customer must pay for the new ride
2. The benefit received for that cost

I don’t run a HANA system myself and only a few of my customers do (and they all run BW on HANA regardless of what other HANA options are). So I don’t have any idea about the costs (other than some mentions on the SCN). But I assume these costs are not low. They can’t be for cutting edge innovation (…see more kittens dying?).

We could go on about costs here, but you are a smart person, dear reader, you can get a rough picture about the costs yourself. It is also a bit unfair to complain about costs. In my opinion if the benefit outweighs the costs, it is worth it no matter what the cost is. So let’s concentrate on the value and especially the obstacles in reaping the value and benefits.

As I see it there are two benefits: speed and simplification.

Well let’s start with speed. Let’s assume I can pick random customers of mine and HANA would boost their business through the roof (since the costs would go through the roof as well because I need to pay for the HANA show I can only see the benefit going through the roof to break that even).

Let’s try … a car manufacturer for example (random example, ok?). I have a production line that builds cars. This production line is built very efficiently. This production must never stop (ok, rarely stop in a controlled and planned manner). If I want to improve my earnings or savings, what do I do? I take a screw that I use 50 times in every car and make it 2% cheaper (replace screw with any other part with a value, if you’re from the car manufacturing business; screw is just an example, ok?). How can speed of my IT speed up my business?

Readjusting the production line based on some HANA invention seems to be out of the question – time consuming, expensive etc. (correct me if I am wrong, I welcome a discussion).

Would I change my supply chain based on the HANA fast data? How? I have dozens of main suppliers I depend on, they each have dozens of their suppliers they depend on. I have my supply chain diversified to reduce the risk of my production line going down because I am out of screws. I don’t see HANA helping me with my supply chain. I have long term contracts with my suppliers (which are not easy to change) and I have Just-in-time (JIT) delivery to be super-efficient. Still no signs of HANA here.

Can I improve my distribution channels based on HANA? Maybe I can ship some cars to a country XYZ because I can see a tendency of the demand to go a bit up there. Normal mortals that order a new car either pay (or are given a voucher) for a speed delivery (anything under 3 months or so) or they just wait for those three months. Is sending a couple cars more (that can’t be customized and must be sold as I built them) improve my numbers?

I am not selling the cars I am producing. How can HANA sell my cars? Maybe I am late to the market with the model. Or it is too expensive compared to my competitors. I can either see it (base it on numbers) or not. But if I get the results of such analysis a day faster (assuming HANA cut the time of a long running job from a day to 8 minutes), how does it matter? What is a day in a life cycle of a car model?

On speed and people

Speed. That sounds cool right? Car manufacturers sell fast cars for a premium. People like fast cars. Do you like fast cars, dear reader? I would certainly try a couple of them on a German autobahn.

But do people like speed? I don’t think so. Speed means deadlines. It means thinking fast, acting fast. Sometimes it means making mistakes. It means facing risks. It means stress. It means swimming into the unknown with the pace that leaves less than our usual time for re-adjustment. That makes us uncomfortable. Discomfort. I don’t like that. Here is my comfort zone. I don’t want to go …there. I want to stay here. Inertia. Action and reaction.

Sorry for the emotional detour. What I am trying to say is that processes are run by people. They don’t run in machines. No matter how fast one report is (whether it runs on HANA or not) there are people that work with the machine, that provide inputs, collect outputs etc. There is a threshold when system performance becomes a pain. See a website that takes 30 seconds to load. That is annoying right? But if that report that you only run once a week for your team meeting to discuss it takes 12 second or 14, does it matter? Or let’s say that report takes 2 minutes to run. If you could push that down to 2 seconds, would you run the report more often? If you ran the report more often, would there be a benefit for you, your boss or your company in you doing it?

You can’t change people. At least not easily. For many people – the normal mortals and coincidentally users of a SAP system – the IT thing and the whole SAP system is a black-box. That means that when your secretary types in your travel expenses, she will not do it faster because this system runs on HANA. She does not know about HANA. She does not care either. Let’s say you work in the company’s IT and your boss decides your budget (reality, right?). Your boss is not an IT engineer (no matter if it is a lady or a gentleman) or even if so, it is not a HANA fanatic. Probably not even a SAP fanatic. How do you sell such a person your most recent HANA ambition?

If you are in the business for long enough, you must have heard the expression “bend the company around SAP”. Let’s put aside the fact that SAP brings some great industry best practices and such bending can bring lot of good into a company. People don’t like this. They will change their ways if the stimulus is strong enough (less work?) or the pressure is big enough (you must do it or you go). See iPhone. I don’t like Apple in general, but I can see how iPhone had this strong stimulus when it was introduced (it was idiot proof to use it, colourful, entry barrier very low since it is idiot proof etc.) and that is why it became a huge success. Is this the case with HANA? No. Huge adoption barriers and unclear benefit (for a normal mortal, an iPhone type of user). People will stand their ground. You want to bend your company around the new opportunities and reach for new horizons? Well, you must fire the people of wait for them to die (meaning their career at your company…).

IT is a black box for them. It must just work. They don’t care if you run SolMan. They don’t care if you run HANA (unless there is a problem with a vital threshold – like the one with the web page response – how many companies have such hard thresholds? Retailers maybe. Who else?). Technology shift that brings light-fast speed is not the killer trick.

...then it must be the simplification!

Then it must be simplification. Hm, ok. What could that mean? Mr. Plattner drops some hints. Simplified ERP? All my systems (CRM, SRM, ERP) put together? No BW system (because it is not needed)?

That sounds very very cool. If you’re the marketing guy and you buy what you sell. Reality check?

It does not sound like you take what you have (current ERP, current CRM, all the systems that you are currently running) and you push a button a voila… a sERP system. I still remember that OSS support ping pong when the landscape optimizer product (or what the official name was) was introduced. So I don’t see it how I put my current systems together into one easily.

I am a developer. I can see the loads of code that live in my system. Tons and tons of code where the quality varies and the “Date create” varies from 199X to yesterday. I have customers with systems full of non-Unicode programs. How could one turn this around into a sERP easily? As a developer myself I know that it is probably easier (from the development process organization point of view, quality standpoint etc.) and also right (because of the new software design trends etc.) to start over. Oh. But that means several things.

That means that SAP will probably start over with what they have. Either partially or completely. That means new bugs. New support ping pongs. New products aspiring for maturity which will take years and loads of frustration.

That also means I will have to implement or re-implement what I have. More consulting. More money needed. And spent. More dependency on externals that learn fast enough to keep themselves up-to-date with what SAP produces.

What about my custom code? If I have this simplified ERP thing now, it has a different data model. Different APIs. Different programs. I may not need my custom programs anymore. Or I may end up with a need for more. Gosh. More assessments. More upgrades. More development. More audits. More.

That was my company. But things also get personal. It is my job that we are talking about here and what happens to my job when there is no CRM, no SRM etc.? Unless I am overseeing something BW comes first here. If BW is not needed anymore because everything is real-time and I am a BW specialist, what will I do for living? I am not needed anymore. I am obsolete. A dinosaur. A fossil. How many customers are out there running BW? What happens with those people if BW is not needed anymore? Will that happen fast? Or over ten years period so they can adjust themselves so they can still keep their families fed and happy and safe?

When I hear about simplification in other areas these days, people translate it into job cutting. Simplified, lean, that means people will get fired. Not every company is so smart to understand that by automating or simplifying things you can give more advanced, more innovative type of work to people that don’t have to perform repetitious tasks anymore. That would boost their motivation. They would push the horizons further. They would have fun doing it (not necessarily everyone, but ok). Some companies lay people off instead.

I know, dear SAP, that you mean well. But you need to explain that better. You need to give people evidence, roadmaps (with meat on the bones), set expectations right, explain how we get from point A to B so that everyone is still on board. Remember SEALs? We leave no man (customer) behind. Tell us how you plan to do it. Dispel fear, confusion.

I know simplification is good. I like the Einstein’s quote (if it was Einstein, I hope so): “If you can explain it simply, you don’t understand it enough”. I don’t think that is the case with SAP. SAP invented the ERP as we know it (my opinion). The data model and the processes and the customizing, the know-how collected and invented hand in hand with millions of customers, all that is super impressive. I am sure SAP will know how to simplify because they know the business well enough (I am just a bit afraid that the individuals that will be responsible for the simplification process will not deliver on a consistent quality level, but that is a different story).

Back to the SolMan beginning. I didn't mean to criticize HANA. I didn't mean to criticize SolMan either. Both products are great. But they way they're sold, the way they are perceived is in my opinion very similar. You don't need them. They improve something you already have. Challenging.

But all will be well one day. For HANA. For customers. For SAP. But it is not that easy how SAP marketing sees it. You still have room for improvement there and please consider if it is not a good idea to fill that room with guidance, with numbers, with evidence, with fighting with your customers hip-to-hip. It is not you and them. It is us.

p. s.: Are you a normal mortal and want to read more on HANA? Consider the owen.pettiford3 ’s Impact of Platform Changes:  How SAP HANA Impacts an SAP Landscape, I quite liked it although it is just an overview.

[lbreddemann]

You described well what I believe is a very important, if not the most important, aspect of change and/or innovation.

It's definitively about people and their view of the situation now and to come.

I fully agree with the need for better (not just more) explanation of what SAP (that's us - me too) have in mind with SAP HANA and how and why we want this to happen.

This is a marketing problem.

And in my eyes it's not just one for SAP but pretty much for the whole industry of enterprise software.

There aren't any radically new processes available to customer that help to make them more profit. Most innovation circle around moving costs in the balance sheets (e.g. running your own pre-licensed setup or using a subscription model).

Likewise technology.

"Big data" and "Data science" are far from being mainstream.

Yet, every vendor spins the current sales pitch around this feature set.

Personally I do believe that there is a lot of profit, value and benefit to gain from applying information techniques to the some of problems you take on.  Being statistically literate is, what I think, very important to understand many things better.

But actually getting out an advantage of such information techniques (likely via technology) requires that either folks need to start walking out of the center of their comfort zone (yes, quiet that lizard brain of yours) or that the comfort zone gets expanded (iPhone did that with using internet and multi-media in a swoop).

The tricky part now is to combine both aspects and to create a story that comforts users/customers/developers and still looks nice in the balance sheets.

Not sure the current approach of the whole industry - following a marketing approach where market domination and first mover advantage means everything - will be able to do that.

Thanks for the good article. Really enjoyed reading it.

[Former Member]

Otto,

Great write-up and I sense a bit of longing for HANA in it or even beginnings of an RFQ or ROI or a feasibility study. My customers also don't care if there's a HANA engine that makes their jobs easier or faster, but in this rat race of ours and corporate peer pressure they don't want to be left behind, so once the speed and accuracy improve they will buy in. Financial close is a bit of a dog chasing its own tail, so once you cut it, they will ask for more. SAP is betting a house for HANA, and even SolMan is not coming close to what it means to the company and industry as a whole. At this point we can only plea our case in front of our CIO and not get discouraged when they refuse our pitches.

Good luck with HANA and SolMan!

greg

PS How did manage not to mention the cloud? Beats me.

[OttoGold]

Hello Lars,

thank you for the comment, I enjoyed reading it as well. It resonated with me.

cheers Otto

[OttoGold]

Hi Greg,

it wasn't so difficult to leave cloud for some other day. I don't see any connection between HANA and cloud (or UIs etc.). For me HANA and cloud is just like HANA and UI (in Hasso Plattner's blog). You can have HANA without cloud, you can have cloud without HANA. HANA is a database (and a philosophy), but it is not a cloud thing. It is an infrastructure thing. Whether you build a cloud on top of it or on-premise things is no difference.

I come from a on-premise world, I don't have a problem with cloud at all, it is just that I see the on-premise and cloud as two different things. Less critical processes (that the company is only starting with or is redesigning) can be moved to a cloud. For the core processes the company is very likely to start using the cloud from the beginning (when implementing a brand new system) or keep the on-premise for some time still (long time IMO).

Anyway... cloud is for me either "cloud first" or the other side of the barricade still.

Let's see the progress not on the technological front but on the people front.

cheers Otto

[petr_solberg]

Hi Otto,

my answer

Best regards,

Andy.

[OttoGold]

Andy,

can I please ask a little thing? Post it as blog. Too much knowledge, experience and valuable opinions are lost in comments that get rarely read. I would have never found yours there. It is well articulated so why not a regular blog?

cheers Otto

p.s.: I agree with things you say. It is just too techy. Doing something well on the technical front is far from being enough to score you a market success.

[petr_solberg]

Hi Otto,

ok, I'll do it this week.

Best regards,

Andy.

[Jelena]

Hi Otto! So basically you took my Dior dress analogy and rewrote it as a SolMan analogy. Nice. :smile: Since your blog doesn't have any pie charts either, I'd expect it to be labeled "emotional" as well (and if it doesn't then I'm totally calling the gender bias card :smile: ).

P.S. Hopefully upper SAP management doesn't blow a gasket over the DSAG survey. Well, I'll stock up on popcorn just in case. :smile:

[Jelena]

But actually getting out an advantage of such information techniques (likely via technology) requires that either folks need to start walking out of the center of their comfort zone (yes, quiet that lizard brain of yours) or that the comfort zone gets expanded

Well, by questioning their mental abilities we certainly won't lure many people out of their comfort zone...

When Russian entertainer Yuri Kuklachev (famous for his Cat Circus) was asked about his secret to training the cats he replied: "You can't force the cat to do a trick, but you can make it want to do it". People are not that different from the cats. :smile:

[lbreddemann]

Hmm... nobody was questioning anyone's mental capacity here.

Thinks like probabilistic decision making is simply not readily built-in to the human brain apparatus. It's something that has to be learned and trained by every single person over and over again.

With the "lizard brain" I was linking to good ol' Seth e.g. here.

To me, really there's no need to lure people out of their comfort zone. Folks who like to challenge themselves push it anyhow. And for the rest of us it would be nice if the tools for learning and applying statistical thinking be so nice that they are not outside of the comfort zone in the first place.

[Private_Member_7726]

This has got to be the best analogy this far. SolMan deliverers features that make me giddy just from reading the headlines (other colleagues are less than enthusiastic, and that's an understatement); but there are so many "small" reasons against it, that, all added up, we just won't be getting one any time soon. Not saying never, but as long as we manage to do without it... I sometimes even wish SAP would make it mandatory having one :smile:

[petr_solberg]

we have SolMan

we use it for Change Requests

we use it for IT Calendar

we use it for Maintenance Optimiser

we use it for storing Documents

we use it for Guided Procedures for repetitive tasks which are performed by oursourced Basis Teams but where we own the intellectual material and this material, these Guided Procedures can be followed by any Basis Technician (obviously with the righ competency) from any outsourcing supplier

we use it for Solution Manager Monitoring and Diagnostics - Early Watch Reports as well - Managed Systems setup

we use for, the Solution Manager Monitoring Alerts are linked to Incidents

we use it for Java Stacks custom default traces log file monitoring, this is a nice one, because Monitoring in the Java stacks has never been as strong as ABAP and in the Java stacks the Default Trace and the Work logs are the most complete sources of truth and with SolMan you can set up custom text searching of log files for Monitoring log file events. This means, if you are familiar with Java stacks and you know what you are looking for in the log files, you can setup Monitoring for those events, useful across Portal, CE, PI, BiJ etc

we use it for the custom Monitoring of Unix level processes, http://www.google.ch/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CB0QFjAA&url=http%...

this Unix process level Monitoring is very nice

there are many more examples, eg the BPM Monitoring which we have not tested yet, especially moving in the direction of Run SAP Like a Factory and SAP Operations Center using SolMan

I am looking forward to more of the SolMan Monitoring being available on the mobile phone, something I complained about over here.

Conclusion, Solution Manager is the Tool for SAP Operations in every company and should be embraced to get the value from it.

Best regards,

Andy.

[patrickbachmann]

First of all I want to say I DO like speed and would like to drive a Porsche on the autobahn at full speed if anybody will please loan me theirs.  Also, Otto, I think you have a great writing style with enough humor to keep my waning attention span at bay and just snarky enough to attract Lars.  And why doesn't SCN spell check recognize snarky is a word?!  It is! In fact Meriam Webster says NOUN: Lars Breddemann, Cyborg.  I was not surprised to see that he enjoyed this too.  So thank you for spending the time to submit this and I look forward to your future blogs.

Sincerely, your new fan.

-Patrick

[lbreddemann]

Pfff.... :razz:

[Former Member]

thanks for sharing your thoughts.

I'm in SAP Business since R/3 2.2 and it was amazing sice sap* started in 06071992 to see how SAP developed their product roadmap (and the 3 characters product acronyms 😉 up to know.

The mission was clear: split up the big monolitic R/x in new lightweight products. NetWeaver, suite products, PO, BW, Business One, the horror of stand alone industry solution systems (IS*) with own CRT patches...

But why was all that done ? My simple answer is: to make more money.

This is not a shame and a valid approach in capitalism. The more products you'll offer for niches, the more market shares you'll get.

But ... after reaching this broad level of product diversification, we now have complex landscapes, for which we need a LMDB, BP Monitoring, End2End & root cause traces.
SAP founded the switch framework to catch all the endlessly modified IS* stuff back in one system to get it maintainable.

BW was (in theory) obsolete from the beginning on, because building aggregates is typically done by a GROUP BY SQL clause, nothing more and nothing less. Near-line & far-line storage is data aging now but was also always possible e.g. with good archiving, oracle tablespaces, partitioning & data cache pinning.

Nevertheless the DB systems in the R/x times were not powerful enough to handle all the on the fly stuff which is possible now with HANA. So creating BW did make sense from that perspective in these times.

Personally I've no mercy with people complaining about all the complex landscapes they have now. They followed the roadmap and split up their central R/x as suggested. Now they need to follow this road again to get the opportunity of simplifying their landscape by putting it all together (again) on a HANA based plattform.

So it looks like a consequent path to migrate all these satellite systems (created out of base motives) technically and then functionally together.

The same happens on the UI path with FIORI's unified user experience. There are many more examples of splitting things up and then some years later, putting it together again.

So I'm in good mood that we can participate and share our knowledge to get smarter solutions in the future

[OttoGold]

Wise words! We have to go through the phases to learn about new questions and new answers for them, that is clear. To what extent it is ok to ask for extra money for some of those "transitions" or dub it revolutionary, that is a different ball game.

See you around!

cheers Otto