Posts Tagged SAP
One of the articles I read mentioned that Vishal Sikka may be headed to Infosys as their CEO. Would be interesting to see if this happens. Here are my thoughts on that:
1. SAP is a software company and Vishal was key in spearheading their product development making strategic decisions on technology roadmaps and directions- Infy is still more known for its consulting business, and even though they have been involved in some SW development, it is not yet their bread-and-butter.
2. SAP is a global company with most of the action in the US and Germany – Infy is still very much anchored in India – the culture and pace there is still very different
If the rumors that Vishal left SAP because he was not happy with the lack of speed (or the powers that be in Germany were not happy with his aggressive approach), this is a challenge he will probably face @ Infosys as well.
Having said all this, it would be a great boost for Infosys to have someone like a Vishal Sikka lead the organization. He is a visionary, and he will probably forge Infosys into new and unchartered territories.
We will have to wait and see…..
Have been very busy and not had time to post any new blogs, but had to write a blog about Vishal Sikka leaving SAP. This IMHO is truly a blow. Vishal was a truly visionary and innovative leader who seemed to be leading SAP out of their old ways into the new world with new and emerging technologies.
Of the many articles I read since I heard the news, these lines from an article resonated the most:
“Given that SAP’s executive bench is now filled with sales and marketing talent and fewer technical folks who understand how core technology can transform SAP, this puts pressure to find a new visionary that can interpret Chairman Hasso Plattner’s visions while balancing the market’s need for 30 to 40% year over year growth.”
(Article by R. Ray Wang. http://www.enterpriseirregulars.com/74396/news-analysis-saps-cto-vishal-sikka-resigns-mean-sap-customers/).
Of late a few senior visionaries have left SAP; first Sanjay Poonen, and now Vishal.
I was looking forward to Vishal’s keynote @ Sapphire. Would be interesting to see where he resurfaces.
Everyone and their brother is involved in data analysis, data science, KPIs. Big Data; it’s data, data, data, everywhere. This includes SW vendors, consulting firms, and data specialists, pushing their solutions, and strategies on data analytics. While there is a lot of value in data analysis, a fundamental requirement to make data analysis successful in an organization is the voice from the top and a buy-in from the executives on the strategy, and goals of the CEO. I am narrating (blogging) a life experience to substantiate my theory.
Several years ago, I was tasked with developing and deploying enterprise-level KPIs and metrics to enable our company to achieve certain organizational and operational efficiencies. The initiative originated from the CEO and the company had engaged a top-tier management consulting firm to help identify the right KPIs and metrics for this exercise.
My team worked with the management consulting firm to define, and refine the metrics and try and get consensus from all the EVPs; I vividly remember a big debate about how to calculate and report Headcount – to get to their target, some of the EVPs were arguing strongly for including, temps, open requisitions, and part-time employees. Next thing you know, there was a big discussion about who would be considered a ‘temp’, versus ‘full time’ – it was all in the definition.
After much debate and discussion, the consulting company finally got the agreement on the definitions of the KPIs and we rolled out the metrics company wide- and right away, the s….. hit the fan. VPs and EVPs whose metrics were not within the target range started attacking the data itself – offense is the best form of defense. Fortunately, we had good data governance and cadence and were able to substantiate the veracity of our metrics with the underlying data for the most part. But it was not without its challenges….
One incident stands out in my mind – I got called by the GM of a large division to his office; in front of him were 3 or 4 excel reports which he was manually cross-checking against the details behind our system generated KPI for spans and layers. He showed me how we had missed 10 employees and his list had 10 more employees than our KPI had captured. I was caught a bit off guards because I did not expect a GM to be sitting down and manually validating data. Upon recovering from the shock, I reasoned with the GM that it was only 10 counts, and not a big deal, given the data volume size. And here was his response – and this is the punch-line to this whole blog, and provides perspective to the blog title. He said:
“Yes, it may only be 10, but with the 10 included, my KPI goes up from 3.75 to 3.80 – 3.80 is closer to the 4.0 target, looks better, and easier to explain than 3.75”.
The GM, like many of his peers, had not bought into the whole exercise and its underlying cause, and without the right tone from the top, and not being aligned with the CEO on the corporate objectives, was looking @ this as something he had to get a ‘pass’ on. This is the challenge with rolling out enterprise-wide analytics; until and unless there is buy-in about the intent of the data, there will be resistance to adoption and acceptance. Else, such exercises and their outcome will be viewed as a stick instead of a tool for improvement.
I have had more success in deploying analytics by providing senior execs and GMs data and analytics that they can use internally (within their department) to manage their business better – for example, spend analytics, revenue and margin trends, etc. These internal metrics/KPIs are not viewed as a threat because these are not corporate mandated, not used to compare the different BUs, and do not have to be presented to the CEO during quarterly review in front of a bunch of people; instead these are analytics and metrics used to fine-tune the operations of the specific division and driven/mandated by the GM/EVP themselves. If these metrics/analytics help the individual(s) achieve their goals, they will help promote the program to deploy corporate metrics (since they now view these as enablers instead of a threat).
Hence the title of the blog……
Big Data, Business Objects, Change Management, Corporate goals objectives, data, Data analytics, EDW, enterprise-wide analytics, EVP, executive alignment, GM, HANA, KPI, Metrics, SAP, tone from the top
I have been working with HANA and evangelizing about its use case and value with customers and prospects and yet I found it an uphill task to get engagement from the business (and in extreme cases, even IT); this despite the fact that SAP HANA is a great product and has lots of uses. So I started researching the issue and came up with some hypothesis, based on conversations and observations.
I theorize that IT departments went ahead and acquired SAP HANA for one or more of the following reasons:
1. HANA is the newest shiny toy
2. The IT department had left over budget and had to go buy something
3. The SAP AE was a very good sales person and gave the customer a huge discount
4. The consulting partner convinced them SAP HANA would help solve all their problems
5. The IT department had to find something new and sexy to work on so the CIO and his/her staff could show they were working on the latest technology, and could put SAP HANA (aka ‘Big Data’) on their resume (how can you work in IT and not have ‘Big Data’ on your resume……).
Now that IT had acquired the new shiny toy, they had to go find something to go fix- create a solution and then go find a problem – we have seen this before, many times.
The challenge was two fold: (1) IT could not really articulate how SAP HANA would create value for the business, and (2) because of the lack of understanding of real business issues, IT picked the wrong use case or a very weak use case.
Let us now turn to the product itself; SAP HANA is great, and I believe there is huge value to be derived from this product, if rightly deployed. So why has HANA not been adopted more readily. Let us look @ some of the potential reasons:
1. HANA is an SAP product and everyone associates HANA with the core SAP ERP and CRM; so the target customers have been mostly current SAP clients.
2. Many people believe that you have to be an SAP shop to leverage HANA; I was talking to a friend who is trying to build a custom healthcare app; I told him he should try and leverage HANA to build his app, and his first response was that his product has nothing to do with SAP.
2A. Because of the belief that you have to be an SAP shop with significant SAP installations and SAP data volume to be able to use SAP HANA, many customers believe that they do not need HANA because their SAP data footprint is so small. The argument I often hear is, “We have less than 80 GB of total SAP data; why would we need HANA?”.
3. SAP HANA has been sold as an application, whereas it is more of a fast database and a development kit. When you buy an application, you expect to install it and start getting value out of it – like SAP ERP, Workday, Ariba, etc. HANA is not an application – it is a super-fast database AND an ADK – and similar to the Apple iOS, you can use this platform to build applications which can then be used to solve business problems- so SAP HANA is an enabler and not the end app itself.
4. Many people do not remember that SAP acquired Sybase a few years back and a lot of the Sybase IP is being integrated into SAP HANA; old timers like me would remember Sybase as a very robust and stable database with a lot of capabilities (Sybase IQ came with columnar data store capability). SAP did not throw away all these features and functionality- instead these are being made part of SAP HANA.
A combination of these factors has hindered the adoption of SAP HANA both among SAP shops and non SAP shops.
For SAP shops, SAP HANA should be a no-brainer, just for using HANA Live; the pre-delivered analytics and calculated views alone can get someone trying to build a data analytics strategy a head start with SAP data. Here, of course the value of SAP HANA is dependent on the source data being SAP (see details about HANA Live in my earlier blog)
But there is a much bigger value for SAP HANA for non-SAP data; you can stage large data sets from the likes of Hadoop, Teradata, and other non-SAP sources into SAP HANA, using the likes of SAP SLT* or SAP Dataservices, and use HANA to combine data from multiple sources almost real-time, and render the data using either SAP analytics tools like SAP Business Objects, or one of the many other analytics tools available in the market. (* SAP SLT does not work for all applications).
SAP is pushing down more and more development capability into SAP HANA and this will allow more application developers to build widgets on HANA and leverage the power and capabilities of HANA.
It is incumbent on SAP, the SAP AEs, and the consulting firms to educate customers on the real value of SAP HANA and more important, the fact that this is not a simple plug-and-play application- this needs planning, identifying appropriate use cases, and proving the true value of SAP HANA.
IT departments should find a good use case, build the application powered by HANA and show the application and its robust capabilities to the business- HANA should almost be not revealed or discussed with the business (how many times do you go and discuss what database you are using with your business users?). After the use case has been proved, the capability behind it, in this case SAP HANA should be revealed- lead the discussion with the business value and then talk about the technology enabling it.
Until such time, SAP HANA will remain largely a toy for IT departments and CIOs trying to show they are using cutting edge technology, with minimal penetration or adoption in the business.
I was helping set the stage for the discovery session for a potential SAP implementation and ran into the usual ‘chicken or the egg’ problem. I explained the process of requirements gathering to the participants (who were pretty senior, VP level people) and then asked my team to start the process. Sure enough, after every second question, the question or comment back to us was either ‘how does SAP do it?’ or ‘we need to see how SAP handles it before we can answer the question’, or even, ‘you should be telling us the best way to do this’.
I always wonder if it is better to show a new system and its functionality prior to the requirements gathering or not let the new system influence the thinking of the users. After all, a requirement is a requirement, whether the new system can support it or not; just because a new system can do something, it should not become a requirement- it may drive a different way of thinking how to do things, but not the requirement.
But this is a battle I am yet to win (at least completely)- and I have been doing this for over 15 years….