Vishal Sikka News

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…..

Vishal Sikka resigns from SAP

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.

 

 

 

 

 

The importance and value of a backup stakeholder

We have heard about the importance of a stakeholder to ensure the success of the project. Every article and white-paper written about the keys to the success of a project talk about the stakeholder- and the more influential the stakeholder, the better.

What is seldom talked about is the need for a back-up stakeholder. What do I mean? You identify the stakeholder @ the start of the project and leverage him/her to get the necessary support and backing from the larger organization. Even when there is a group of stakeholders, there is usually one person, who is the lead stakeholder with the most interest (and hopefully passion) in the successful completion and roll-out of the project.

However, we live in a constantly changing environment, with people moving out of their roles, and sometimes even changing jobs. When a key person leaves a company, it creates a power vacuum and someone else will step in to fill the void. Now, if the person leaving happened to be the biggest supporter of your project, you are suddenly exposed and you have no idea if the support for your project is going to continue. This is especially true in a very divided organization where individuals have strong likes and dislikes and opinions.

To mitigate this risk, it is a good practice to have a back-up stakeholder identified and prepped; you want to identify someone who is strong, is aligned with the project goals and objectives, and can potentially step up if and when the primary stakeholder leaves.

I have seen and heard of many projects fail because of a shift in the stakeholder- my guess would be that there was no secondary stakeholder identified and when the primary stakeholder left, there was nobody to back-up the project.

Data Analytics Adoption – Its the people, stupid…..

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……

Death (Dirth) of the Data Scientist with improved Predictive Analytics Software?

Starting a couple years back, there has been a lot of hype about data scientists and how this was going to be the hottest job in the coming years; analysts were predicting that the need for analyzing big data and finding patterns and trends would require thousands of data scientists who can build statistical and predictive analysis tools.

Terms like R and Python suddenly became sexy and all the statistical nerds starting coming out of the woodworks. Caching, sharding, clustering, classification, overfitting, underfitting, and scalability became terms to be thrown out @ random in social events and parties. And to make sure resume scanning programs found the buzz words, Hadoop, MapReduce, Hive, and HBase became must have words on resumes.

The dirth of qualified data scientists was a hot topic of discussion and following the projected supply demand laws of economics, companies were scrambling to hire the few data scientists available and paying them highest dollars (or pounds, or Euro, or bitcoins…..). Of course, not to miss out on the hype and opportunity, academia jumped on the bandwagon and started hyping up their data science programs or offerings. Boring and unpopular statistics and econometrics classes suddenly got rebranded as ‘data science’ courses – marketing @ its best.

A 2011 McKinsey report estimates there will be 140,000 to 190,000 unfilled positions of U.S. data analytics experts by 2018. In response, universities are scrambling to improve their existing degree programs and create entirely new offerings.

Note: Ironically, while the companies like Facebook, and Twitter that generate much of the data are in California, there are only a handful of universities in California offering a dedicated data science program.

I have not tracked if companies like eHarmony.com jumped into the fray as well promoting the socially challenged candidates trying to find a match, but would not be surprised if they did (“John does not talk much, has no interests or activities, but is great @ projecting the outcome of a coin toss…….”).

Recently though, the hype seems to have gone down.

One of the possible reasons could be the improvement in new predictive analysis tools like #SAS, #SPSS, #KXEN (now called #InfiniteInsight after being acquired by SAP). I recently attended a 2-day workshop focused on SAP Insider Insight (formerly #KXEN) and I came away impressed. The tool allows you to build models using various statistical methods and predictive algorithms that can be used to analyze structured and unstructured data. With SAP HANA, one can process large volumes of data streams from various data sources (including Hadoop, O Data, etc.) and use SAP Infinite Insight to process this data and publish trends and co-relations. I was able to easily build various models with minimal training using the easy to use UI.

Unlike a data scientist, who has to constantly tweak and update his/her model manually with changing business conditions and data feed types, predictive analysis software tools can update models easily and be used to analyze data for predictions.

Infinite Insight incorporates R and other statistical capabilities and can be used independently or on HANA. Infinite Insight is going to be embedded into SAP #Hybris, according to the SAP roadmap; this will allow companies to use predictive analysis on their e-commerce sites.

Now back to the original topic – where does this leave the data scientist? My guess is while the data scientist may be hired to help build models in tools like Infinite Insight, it will not necessarily be a long-term employment. With more machine learning being developed almost on a daily basis, predictive analytics software will only get better @ modeling and predictions.

Now if only if there was a software to predict the future of the data scientist.

BATNA – What you do when your boss puts you in a no-win situation

I ran into an old friend/acquaintance who used to be the head of IT of this company; he had quit his job and was looking for his next gig – and so we got talking. Here was his story…..

The auditors had identified a potential gap in the company’s  IT security and had flagged it as a SOX deficiency in their statement. Of course, they also wanted to  to increase their audit scope (and fees!). To fix this issue my friend went to get approval for a project to tighten up IT security by automating certain features and processes. His supervisor however had no interest in approving the funding for this project; instead the supervisor, who had minimal IT experience, lectured him on how to run his IT organization. My friend, realized that he was in a no-win situation; so he followed the BATNA approach.

For those who do not know what BATNA is, my definition of ‘BATNA’ is, ‘Best Alternative to No Alternative’; in this case, the best alternative he had was to quit because he had no other alternative- he was in a lose-lose situation.

Note: A good friend (must be a good friend because she actually takes time to read my ramblings, aka blogs) pointed out that the wiki definition for BATNA is ‘best alternative to negotiated alternative’. I find ‘best alternative to no alternative’ to be a better fit for my use because that that is what we usually face – there is no alternative. So maybe I should go create a BATNA 2.0 definition……

We have had situations in our career at one point or the other when our supervisor puts us in a no-win situation. Your boss asks you to follow a certain strategy or take a certain approach that he or she believes in; you know that the strategy and/or approach is either not the right one, or a recipe for failure.  And yet, you have to follow your supervisor’s recommendation. You may try and persuade your supervisor against the approach, but unless you and your supervisor share a very strong and open relationship (and bond) with frequent information and idea sharing, chances are, you will have to tow the line and do as told.

So what do you do in such a situation. You look @ your BATNA, and if you do not have the option to change departments and supervisors, your only alternative is to quit. Unless your supervisor is one of those rare individuals who has your back and will stand up and take the blame if the strategy or approach fails, chances are high that you will be the fall guy anyway. And when the failure happens, you cannot use the excuse pthat you followed the guidance given to you – it seldom works. So, the earlier you recognize the situation, the sooner you can start working on on your exit strategy, which might be your only BATNA.

Why SAP HANA has not had more success than it deserves (no, I do not work for SAP)

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.

My New Arbor and How It Relates to some IT Projects – The Chicken and Pig Analogy

I recently finished installing an arbor in our backyard (pix in the next blog) and my experience reminded me a lot of IT projects that I have either been involved either as a project manager, biz sponsor, or onlooker. My arbor looks great (you can see for yourself after I post the pix), but I installed the arbor w/o consulting my wife or getting her involved in the design, or purchase process. So now, she will not accept it…..

This is what often happens in IT projects that do not have biz buy-in, or involvement from early on. IT decides that it needs to go improve something or go build something, without getting the biz involved and then they are surprised when the biz refuses to accept the solution. In fact, I am currently involved in a project where we are facing this situation; the idea is great, the solution even better, but the biz never quite signed up for the change, because it involves them committing their time to the testing and validation. If the solution does not work, they are in trouble – so they are even more reluctant to sign up for the new solution because of the risk involved. The classic chicken and the pig situation – while IT is involved in developing the solution, the biz is the pig in this situation- they are committed and if anything goes wrong, their job is on the line.

I remember yet another situation where my corporate controller told me “if we go-live and the solution does not work, I will lose my job, whereas if we do not go live the only thing I would have lost is the cost of the SW and implementation – I would like to keep my job” – and there ended that project, a month before go-live, after 5 month of hard work.

The key to success for IT projects is to get the biz involved early on in the process, and more important, show them (with data and facts, not just with ‘trust me’ words), that the solution will work, and there are mitigations if it does not work. They need to feel ensured that they are not ‘committing’ to something that may or may not work and the more comfortable they feel early on in the effort, the easier it is to get their buy in and support.

Now off to try and convince my wife that the arbor is really very nice…….

 

The wonderful world of GRC

While SOX requirements and the hoopla around SOX may have reduced these past few years, GRC remains a key requirement at most PLCs. In fact, I know of a handful of companies that got marked up for SOX failures on GRC deficiencies and usually the sword falls on the IT department. Unfortunately, these failures often become a source of opportunity for vendors to come peddle their GRC tools. – vendors are ready to demo their latest and greatest GRC tools with all fancy dashboards and reports. Word to the wise- implementing GRC is 80% preparation, 20% implementation. Companies should spend significant time designing their requirements, org structure, tolerance for risk, and available mitigation before embarking on choosing a tool. Once all the design is done, it is just a matter of finding a tool that is easy to install and use and maintain. Unfortunately, most companies choose the tool first and then start grappling with this bigger challenge. Another factor is that it is very easy to make this more complicated than it needs to be. This is where you need to remember that all you need is a passing grade and don’t need to have the best GRC installation- since there is no prize for the best GRC. There are many companies peddling their ‘custom GRC’ designs as well- once again, these need to be reviewed in the framework and context of the specific company.

Unfortunately, when it comes to compliance, most companies like to err on the side of caution and sign up for more than less. Objective thinking and some careful planning could make this a lot simpler than it is made out to be.

Chicken or the Egg in ERP Implementation

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….