HANA and the SolMan syndrome
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:
- ASUG survey that started the whole thing: ASUG Member Survey Reveals Successes, Challenges of SAP HANA Adoption
- Blog by Jelena Perfiljeva on the ASUG survey topic and the stir around it: Y U No Love HANA?
- Blog by Steve Lucas on the ASUG survey: Thoughts on the ASUG Survey on SAP HANA
- Hasso Plattner himself on the ASUG survey results: The Benefits of the Business Suite on HANA
- DSAG survey: Demand for innovation potential to be demonstrated
- Dennis Howlett 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:
- Initial investment in the people, hardware and software
- Investment into the change management process that would readjust your people’s mind-sets and processes around the new tool.
- 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.
- 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.
- 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.
- 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:
- The cost that the customer must pay for the new ride
- 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 Pettiford ’s Impact of Platform Changes: How SAP HANA Impacts an SAP Landscape, I quite liked it although it is just an overview.