And Vijay Says…

As always , just my personal views here – nothing official about it .

The world of data is roughly split into two – preparation of data (master data management, cleansing, quality, integration etc) AND use of data (Analytics , transactions etc ). I think one of the biggest reasons that companies never get a grip of their data is because these two sides of data are some lbw treated differently .

The whole idea of preparing data exists because it is to be used for something like analysis or transactions . When do we know for sure that data is bad ? When we cannot do transactions and analysis meaningfully with it .

How do we define quality of data ? One way is to do so in somewhat technical terms – like 20% of the data is duplicated , or 15% zip codes do not have valid values etc . This means nothing really to the people who have to use the data . If this is represented as “you will incur $500K of return orders because of wrong addresses” – a rational decision can be made whether to spend time , effort and money to fix it .

How do we find this $500K impact? By Analytics of course . What do we analyze to find this ? The transactions that happened in the past , and those that might happen in future. In essence – data prep, Analytics and transactions all exist in real life without hard boundaries . Boundaries were drawn by IT , by vendors and by analysts . And because these boundaries were drawn – the various parts of the data world are busy thinking how to create the next best visualization tool or next best data cleansing engine , instead of thinking about how to create the next best holistic decision making system . We brought the curse of incrementalism on ourselves – no one else is to blame .

With every passing day, more and more information is created outside our firewalls than inside of it . But look at the data models used in systems – they are all mostly defined by in house systems . So then why exactly are we surprised that it is like pulling teeth to consolidate external and internal data to make decisions ? Rigid data models based on tables and fields and so on are not going away – transactions and some operational Analytics still need those . But we need to start dealing with real world data as it exists – as entities that have evolving relationships with other entities . That needs to be a part of both the preparation of data and the use of data .

Does data need to be fixed before we make use of it ? I think we should move beyond a binary yes/no answer . In real life that is not how we make decisions . So why should our systems behave differently ?

Case in point – if a CEO asks HR “who is the best sales person in the company today?” , HR system can probably answer that saying “That would be Mike”. Then an HR analyst will need to look at the information to come up with a more realistic answer “It is really a toss up between Mike and Sara” . Why don’t we have system that gives answers like ” 50% sure it is Sara and 60% sure it is Mike” ?

HR probably needed to check with Sales colleagues to find this answer . Decision making is collaborative in real life – you can’t predefine rigid workflows for every possible question that an executive should ask . Yet, we see collaboration and data technologies evolve rapidly in parallel tracks without much of a convergence . Shouldn’t this change ?

No system can fix all data problems – but the approach to solving problems is still stuck in the past for most part . Humans don’t magically know all answers either . But over time , humans can see patterns in data and make intelligent guesses . Machines can do that too in many cases – and can crunch more data than humans can . It is time machines did a little more of the heavy lifting before asking humans for help .

In pockets , all these things are happening. Technology is not the biggest hindrance to making the world of data more real life like . It is the approach of creating these artificial boundaries that stands in the way the most .

President Reagan famously said “Tear down this wall ” in a different context . I would like to borrow his words and say “Tear down these data walls please !” .

First – 6 weeks away from blogging was great . I am very grateful to all of you who encouraged me to start blogging again .

I stopped blogging rather abruptly – after reading my posts this year, I couldn’t think of a reason why anyone would want to read most of what I post. But seeing the responses from many of you – I guess I over estimated the deficiencies if my writing .

And so I am back. I am still going to stay away from twitter for now . So please leave comments here rather than on twitter like usual .

Over the last month, one topic kept on coming up in conversations . That is about why employees and managers feel “us and them” more often than not .

I think the root cause is goal setting and performance appraisals . It is a stupid idea in general to set goals formally once a year and then check back to see if you made it or not . The CXOs of the company cannot usually foresee how the market will work in next 3 months – so how will an individual and their manager predict what has to be done for 12 months ?

When the results of appraisals are given out – many managers feel an obligation to also give a speech on the topic . This is the beginning of the trouble . Generic messages are counter productive and usually insult the intelligence of the employee . More than the actual rating and rewards – it is the insult to intelligence that irritates most employees.

Performance appraisals set the pace of disillusionment – and other managerial communications sustain it.

Say an employee has a bright idea and brings it to his manager and asks for funding . Four scenarios generally are possible

1. Manager sits on it and in a passive way make sure nothings comes off the idea.

2. Manager says he will fund it – but doesn’t do it, and eventually gives a generic reply like “This is not a priority for now”.

3. Manager dismisses the idea completely upfront with no debate

4. Manager asks proving questions to see if the idea is worth pursuing and takes it up the chain. Manager keeps employee in the loop and explains the rationale for the final decision – even if the answer is “no go “. Better managers will also coach the employee on what needs to change for the next time

The first 3 makes the employee feel that her sole purpose in life is to do what others decide for her . There is no value for her original ideas or intelligence .

Option 4 in most cases ends well – and makes the employee feel he is appreciated , and he will try harder to find a better idea next time .

Sadly, option 4 happens in only the absolute minority of cases . If this managerial behavior is properly addressed – I bet the bitterness felt by employees will be eliminated in most cases .

I will make one last point – on rewards . Why are people promoted and compensated for performance in HR cycles ? If my daughter earns straight As in class and I tell her “good job kiddo – end of your school year, I will buy you two bars of chocolate. But make sure you keep straight A’s till then “, what are the odds of this being effective parenting ?

An employee that does something for the company that benefits the company should be rewarded closely after that – at least partially . If a development team creates a product that brings in profit today , what is the rational explanation of paying them their reward after the company enjoys 6 months of that profit ?
. The typical answer from managers is “that is out policy”. Employee probably tells in her mind “stupidity is not an admirable policy” 🙂

That was a long winded way of saying whatever you do as a manager – pls don’t insult the intelligence of people at the receiving end

This week was tiring in the extreme – but in a good way. And tomorrow morning, we are leaving on vacation to Hawaii. The plan is to switch off work email and phone and just chill with my family.

Last year – we went to another island in Hawaii around the same time. The week before that vacation was also very stressful – but in a bad way. Something that I was working on with all my energy did not come through – and I decided to take a vacation to get over it. We decided on Friday, and we left for Hawaii the next day. It was awesome – and I came back fully refreshed, and the thing that did not materialize before I left, that happened in few weeks.

This time is a little different – we hit the results we wanted with the launch (http://www.saphana.com/community/blogs/blog/2013/09/24/announcing-sap-bw-on-hana-trial-offering-on-sap-hana-marketplace#comment-4174) , with room to spare. And I am leaving it in the capable hands of my main man Ingo Hilgefort while I am away.

As the last meeting of the week got over, I have been thinking through our little side project. What immedeately striked me was that we never bothered to give it a code name. And it never mattered once – we all worked as hard as we could without slogans and call names. I now need to think if this should be the norm going forward for my gang.

We did this with a core team of three – Ingo, Rohit Kamath and me. Ingo acted as the project manager. We had a lot of other things to do in our day jobs – so this was a side project with no formal budget of headcount. We went right ahead – and pulled in colleagues as needed from every corner of the SAP organization globally. And no one hesitated to help – every colleague we asked help, turned around and helped us. Of course some more so than others. But no one turned us down. As it goes – ask and you will be given .

Why did we do this? Because we were in front of a lot of customers and partners across the world in the first six months of the year. We knew first hand that it is painful for ecosystem to do POCs – and people told us versions of the same story in every meeting and event we had. So it was a no brainer for us that this needed to be solved.

It also helped that Vishal challenged us to think of a way to get a POC system up and running in 3 days, instead of the weeks and months it typically takes in many projects.

It was not difficult to arrive at a conclusion that cloud deployment is the best way out. The big question then became – will BW shops use cloud at all? We all had different opinions. So I wrote a blog about it and put a poll inside it to see how the ecosystem percieves BW on Hana on cloud. The data – although a small sample – clearly showed it was a welcome idea. So we went ahead with the plan.

Next up was the question of what is needed for the POC system – and after some back and forth with ecosystem – it was agreed that BW alone didnt make sense, and that we needed BW on Hana with a BI server so that customers can better visualize the awesome capabilities of BW on Hana.

This solved half the problem – the other half was more difficult. How do we ensure that a customer will face minimum fuss in doing a POC? We analyzed further and figured out that it is not enough to provide raw infrastructure – we should also provide connectivity between BW and BI, as well as sample content and data. And for those who need more training – we also decided to provide tutorials. This is the same material we had tested with probably a thousand people before in our enablement sessions in the first half of the year. So we were sure that this was the best way to get someone up to speed.

Then came the actual deployment. We had many options – many different clouds, many different stores, many different integration technologies etc. We decided to make SAP HANA Marketplace as the entry point, make SAP store the transaction engine (record keeping) , SAP CAL (cloud appliance library that does the magic behind the provisioning) as the deployment engine , and AWS as the deployment infrastructure. Together – they offered the best trade offs.

At that point – we needed the best critics we could get to see if our plans hold water. That is where the SAP Mentors threw us some help. They got into a call with us and gave us excellent feedback. And to fill the remaining gaps – I also ran it with Dennis Howlett who also was helpful in his feedback. We listened and we acted – and that is what eventually went into production on September 25th morning.

We only did a soft launch – Ingo and I wrote a blog each, and we tweeted out from our personal handles. It was not exactly a social expiriment – it was a well thought through plan with colleagues in marketing. The results surprised me to no end. Thousands of hits on the blogs, plenty of twitter amplification, and significant traffic to marketplace. Best of all, way more people who reached the market place finished the transaction and got trial systems than we expected. I was skeptical that the numbers were any good – but after seeing comparables from people who do this thing for a living, I think we did pretty well.

You will see a lot more activity from next week to get the word out across all channels. I cannot thank enough everyone who is working hard now to get this in front of as many customers and partners as possible. It is also amazing how many colleagues pinged us directly to ask how they can help. That is what makes it special – where people volunteer to help when it is not their day job.

From the time we launched – we have been staying in close touch on all channels to provide assistance to people using it. Where we cannot help – like for example, there are only a subset of countries where we can legally offer this today – we are updating the marketplace with information about what is available and what is not. I am especially thankful to everyone who tried it out – and then took the trouble to communicate what they were happy with and where we need to do better.

There are some 18000 BW installations today – and BW on Hana is something all of them should try out. This is our first step to make it very easy to do so. Even more important, the feedback we get from this trial is what will drive our plans for what else we can do. Our hope is that data will tell us what they next step is, instead of us guessing what customers need.

It was a learning experience for Rohit, Ingo and I – and probably the 40 or so other colleagues who helped in the extended team. It gave us all a better idea of how many things are interconnected in a big company, and how we can all work together in informal settings to make good things happen. Sure there were many frustrations and crises along the way – but we prevailed as a team and got through it all. I am incredibly proud to be a part of this team and will gladly do it again. We also learned that we have to take turns in calming each other down 🙂

What would I change in how we did this?

1. Now that I know how many people have the kindness of heart at SAP to help – I will crowdsource more, and start involving more people early on. If that needs these things to have code names – so be it :). I should have know this after the success I had with it creating the IBM innovation lab for SAP in a crowdsourced model with Gagan. Good to know this works in all companies.

2. A small core team is the reason why we could move in an agile fashion. I will keep that philosophy. Rigid structures kill initiative in smart people.

3. Social is definitely the way to go to push the message and get feedback. I think we will do way more social interactions in next project. Not just more social – we will start doing this sooner too.

4. Start setting up measurement systems sooner in the project – even if it is informal projects. Sooner the better.

That is pretty much it . Couple more hours to finish the day off – and then get busy packing. I have promised my wife and daughter that I will not think of work when we are on vacation. Let me see how much I can keep that promise.

Ingo and Rohit – you guys rock ! Cant say enough thanks to you – and all the other colleagues who helped and continue to help. Also a very special thanks to Amit Sinha , Jonathan Becher, Steve Lucas, Prakash Darji and Vishal Sikka (and their teams of course). We could not have done it without you.

Hope that by the time I return to work – I will see a lot more people using the trial. If not – we will go back to more analysis and fix it. Long complex POCs suffering from complexity of IT systems is a problem the world doesnt need – we will fix it some how, no matter what.