Apr 14, 2014

Focus on Business Value not Data – BW-on-HANA migrations


We are surrounded by mobile devices, smart phones and the unwired information consumers who are now getting used to getting information when, where and what they need. According to Gartner's report most BI projects are meeting the where and when but are seriously lacking in the what of business intelligence. My translation of this is that over 70% of reports in your production system Today enterprises are delivering over 5 billion gigabytes of information on a daily basis.
While many corporate analysis and business stakeholders are inspired by the opportunities of finding business diamonds in the domain of big-data and get more insights into true business value. However, before we go and jump into this big data technologies there are three critical decisions all stakeholders need to filter through.

1.    Speed alone does not add business value: What is the business value in accelerating a query that currently takes 715 seconds to run and now runs in 1 second- if business will never use it? (Gartner’s BI nightmare)
2.    Clean your BI before moving to big-data or HANA: There is a huge opportunity to clean your current BW environments prior to moving to BW-on-HANA. Your Si should be able to guarantee a minimum of 40% of db reduction. This will reduce your initial HANA costs by 40% and also reduce your annual support SLA’s by an equal 40% of more
3.    Data alone does not generate business value: What is the business value if you have petabytes of data but little information that drives business benefits à OUR FOCUS IN THIS BLOG
The traditional business intelligence technocratic methodology believed that if we collect all the data then we should be able to meet any information needs. This is how we have built our SAP BW environments, and other BI environments over the last two decades. Paradoxically, what our business value audits empirically prove is that this methodology actually makes it harder to find business value. Sometime it simply makes it totally impossible.
Moving forward companies need to focus on business needs and expectations and not the data. This kind of turns around the legacy methodology on its head but this is now proving to be core implementation best practice as we redefine best practices for BW on HANA migrations. Companies need to focus on decisions and information flow that assists business take better decisions. To use the space age analogy no one would build a rocket and blast it off with astronauts without deciding whether the rocket was going to the moon or Mars. Nor would be send a cruise ship out, loaded with passengers, but without having a clear destination and route. However, we continue to build our BI environments exactly like that.  The only exception to that is Christopher Columbus who was actually planning to go to India but ran ashore in the Americas – that is how the Native Americans probably got to be called as Red Indians. So the key here is ‘Plan your work and only then work your plan.
So the RIGHT ROADMAP TO BoH MIGRATION of Big-Data analytics is:
1.    Identify the business benefits and value in the form of what information consumers need and in what format = Business Expectations
2.    Identify the data that is required to meet those ‘Business Expectations’
3.    Collect the required data
4.    Architect, Model, build and deliver ‘Meet Business Expectations’ Analytics

Before we do anything in the new Big-Data nexus, it is most critical to firstly not get distracted by the size of the databases out there. Secondly it is critical to let business define exactly what their needs are. We need to set the stage for extracting business value from the data and not loading our new environment with redundant data elements. Rather than collecting data first we need to work backwards from decision enablement and business benefits and then identify the data required to support those decision analytics. It is no longer beneficial to take a technocratic approach of collecting data and just producing interesting information – hoping business can use it.
Let’s look at a live business case of a telecommunications company- Goal decrease customer churn
Their legacy reports, ran once a month, provided customer churn data, i.e. information of customers that had dropped their services and possibly gone to another provider. This report was a monthly report. These reports are reactionary.
With access to HANA the customer developed analytics that predicted customers that might drop their accounts in the next 15 days. Although, this model was accurate to around 80% the 15 days the reaction time was not adequate to retain customers. With the level 1 analytics customer retention increased by a mere 12%. These analytics though better than their prior reports still did not have any major impact on attrition rates. However, it was the right approach to a business solution....
For level 2 analytics the first goal was to provide at least a 60 day prediction based on empirical reasons as to why customers dropped them as a provider. Their Business Value architect recommended they talk to select store managers and business stakeholders. These were contacted to identify the main reasons customers were dropping. Within three weeks the front line managers identified 5 reasons that made customers drop and change to another provider. The first reason was dropped calls when coverage dropped from 4G to 3G. The second reason was customers being locked to current phone models by contract, and so on and so forth. It was also noticed that most of these customers contacted their stores with these concerns, and texted to their friends for alternative solutions. In most cases the stores had no way to collect this customer issue, not communicate it to the company. So the complaint went untracked and with no response other that that's how we do business. In a matter of 6 weeks they identified the need for a system whereby store managers would be able to track these specific 5 attributes when their users came into their store. They also sent out emails and texts to all their users asking them if they faced any of these issues. Thirdly they started tracking texts on these 5 attributes form their own devices.
By identifying customer churn reasons, the enterprise proceeded to define clear KPI's that needed to be tracked by the business stakeholders. These new KPI's now enabled sales and marketing to now predict churn by 90-120 days. Using the new data the analysts could now predict with higher certainty customers who could not only be leaving the company but the exact reasons they would be doing this for. This led to marketing developing specific solutions that were then communicated to their help-line support. The new model not only predict but also prescribed the exact answers the help-line was supposed to respond with along with solutions tailored for specific issues customers were facing. Using this prescriptive analytics, based on predictive information the company was able to decrease churn by 82%. Due to these new initiatives they not only decreased churn but were able to launch marketing promotions that let them gain new customers to the tune of 13%. The company also launched Trade promotions and marketing solutions based on specific customer issues when they reached a certain threshold, for example free upgrade to newer models without contractual penalties. The second was that the company would take all the transfer burden from competitors.
This approach differs from the traditional data collection and technocratic approach of IT- collect data --> build reports --> give it to business, i.e. creating reports in assumption of the business benefits and without direct business participation. This recommendation represents a 180 degree turnaround. Find business needs --> Define deliverables --> Now collect required data --> Build analytics --> Meet business expectations. Now instead of facing data we face business users and consumers.

Moving forward companies that continue to take technocratic decisions that are data facing will end up create more data and not necessarily more information. They will not be able to enhance the enterprise decision capabilities.
However, companies that hold their technocrats resources and turn them 180 degree around to face their business users  to understand their needs, with a collaborative approach and business goal, will truly add business value, enhance business decisions and deliver higher business benefits. They will consistently  leave competition breathing dust as they speed forward and most important of all save considerably in cost of deployments by optimizing their assets utilization.

Apr 8, 2014

Part 2- 7 things successful CIO’s must do in BoH Migrations


Part 1 of this blog was about what CIO’s must not say/do in BoH migrations. This one is about what they should do. 

According to current trends over 80% of HANA migrations will start with HANA Analytics and/or BW on HANA migration. We all want our HANA decisions to be successful both tactically and strategically. It is critical to remember that the columnar and In-Memory is best suited most for analytics- so you need to get this one right from the start. 
Key stakeholders need to work with a ‘zero-option’ to failure and right now your triad partners have collected adequate information on which of their BW-on-HANA (BoH) implementations resulted in meeting-business-expectations and which did not.

1.       “Don’t let Big-Data confuse you big time”
                 ... or what does big-data mean to my enterprise

Background: In one of my recent meetings with a CIO and chief architect of a very large global retail enterprise I was faced with executive confusion as to how complex big-data was accompanied with a perplexity on how they would put all these complex pieces together.  What the stakeholders failed to realize what that they were in the market, kind of, to buy a 9 to 12 seat corporate jet and were getting confused with all the noise created by the Deramliner and other very large airplane reports. The two were totally different. My final communications to them in 2010, that I have held to steadfast since then is that ‘Your big data is only as big as the biggest dataset your decision makers need to analyze to enhance their business decisions’. 

Business Case: Our first company a famous global music distribution company was in a state of major readjustments in the post digital world of music. Whereas prior to the digital revolution they owned 92% of the artists and their songs. They also used to sell a whole CD with one or maybe two good songs.  In the pre digital age an artist had to produce one great song, andother good ones and fill the rest of the LP or CD with fillers. In the new post digital world the pressure increases both on the artists and the enterprise. Today over 80% of music is bought as singles and as a digital download at 0.99 cents a pop. This single concept changed the world and there was a deep need to analyze the digital domains of music. The company decided to go on a private Hadoop option and have spent the last two years trying to get their hands around all the data from private labels, music bloggers, digital downloads, music likes and dislikes, promotion tours and text’s related to them, etc. The world suddenly got very confusing and IT started trying to contain and control Niagara fall of new data with a free-form technology like Hadoop all on their own.

Company 2 is a retail company with over 1600 stores. Their stores collectively sold over 1.7 million different products or SKU. Their main concern was the financial exposure between over 1.2 billion SKU’s across each store and nation, i.e. the store in France bought the same material from Vendor 1 and the store in New York bought it from Vendor 2. Their financial exposure was a result of the delta between the actual cost vs. the price tag on each retail item at the store and checkout register. Prior to HANA this company used to take 4-6 weeks with 18-20 resources to re-price each item in every store per region. They could only focus on 50% of all SKU’s due to the large number of items. These items then sat for the next 6 months with a fixed price on the shelf but with a variable cost in the background. An accident of a truck, a flooded storage location, a ship caught in a storm off the Cape of Good Hope, or even rising raw material costs all had a direct impact on their margins. With HANA we moved their price change from 6 weeks and 20 resources to à On demand in under 10 seconds for 100% of the products. Now the company is able to adjust their item price on a monthly basis. Next step is to put electronic price tags to each item and the checkout and change item prices on a weekly basis. Our annual benefit in year 1 was more than their total investment for migration to their BW-to-HANA- this is what we call focus on the business solution. Behind finding this solution was a scientific process for identifying true HANA business benefit.

 Recommendation:
Focus only on your business decisions and then flow down to the data required to assist that decision. Do not get confused with all the data that may reside in the total source areas, i.e. 17 TB in face book, 3 petabyte in Blogs, 14 TB in twitter, etc..
[1] When faced with overbearing complexities break them into bite-sized small steps and then solve things one-step-at-a-time
[2] Conduct a ‘Design Thinking workshop’ with your business stakeholders and identify true business value drivers.
[3] Identify data sources and then reduce it to the data elements you need for your business needs 
[4] There are many ‘Out-of-the-box’ solutions available that allow scanning, reducing and making this data available for direct analytics or for enterprise mish-mash analytics.

Identify your deliverables and do not start with the data. Once you have identified deliverables then review what data you need to meet those requirements. The rest is easy and 1-2-3 with an experienced Business Value Architect at your side.

2.      “Plan your HANA migration before you start”
                 ... and only then work your plan

Background: In my last few HANA installations, now totaling over 19, a majority of them were undertaken with what we can today term as a technical installation of HANA. It is critical to remember that ‘HANA is a business solution and not a technology installation’. Companies that have simp0ly installed HANA without planning have consistently lost a minimum of 50% of their investments from the start – not only as initial investments but also as annual support costs for SLA’s. In addition to this there is an opportunity to increase quality and decrease costs in the HANA migration.

Business Case: The first customer is a global CPG customer that decided to migrate their EDW BW environment to HANA. In the recent past they had split their enterprise into two companies, one leading their US operations and the second their international business.  In a one-day session we were able to reduce their total BW landscape from 52TB to 26TB. This is almost a 50% reduction in initial costs in a 1 day workshop.

 Recommendation:
Don’t accept a “let’s move the BW to HANA As-Is’ under any condition. There are various scientific, and proven, opportunities to reduce your BW database, models and architecture either before, during or after migration to HANA
[1] Undertaking any project without planning is in fact planning for failure. Stakeholders need to find out what is out there to enhance information quality and decrease migration costs prior to letting anyone take any protocol decisions in any HANA migration, be it BoH or SoH (Suite on HANA)
[2] Key stakeholders training is an executive training that simply takes 2 hours of your stakeholders time and leaves them with checklists for every stage of their decisions. It is critical to remember that pilots do not use pre-flight checklists because they do not have enough experience or flying hours, but because very often small mistakes before takeoff can lead to major disasters. According to reports pre-flight checklists have decreased flight disasters by a whopping 82%.  
[3] The preflight checklist for a B52 bomber is different from that of any other checklist. Similarly your pre-migration checklist for HANA will be very different from that of your legacy BW.

Plan your HANA migration and only then work on your plan. As executives plan to use available resources for planning your HANA migration. Do not accept any 3rd party recommendation for not planning nor take ownership of future disasters.

3.      “Build your global HANA methodology”
                 ... before you  work your plan

Background:  in over 80% of the BW projects I have audited the core group built standards and processes at the start of the BW project and then the documents gathered dust somewhere in the physical or digital world. What this results in is standards that are either completely wrong our totally our of date. Prior to migrating to HANA ensure that you document new standards with one of two options. The first is to redesign and remodel prior to migration. The second is to remodel during migration. The third is to redesign and migrate after migration.

Business Case: The first customer chose not to change any of their naming conventions or processes and take their BW as-is to HANA. Post go live they ended with a user satisfaction under 18%. Upon a deeper analysis that was their exact user satisfaction score prior to moving to HANA. So what this company managed to do was migrate 82% of their inefficiencies to HANA at considerable costs.

Our second customer decided to follow the IQDCT methodology and undertook select POC’s prior to migration. This company increased user satisfaction from 23% to over 80% while decreasing migration costs by over 50% overall.  

 Recommendations:
Just like one should never build a new building without proper approved plans so it applies to building any BI environment – HANA included.
[1] Gartner clearly states that as we start in big data we need to move from EDW to FEDW architecture, we need to remodel our Cubes prior to migration and clean-up the BW environment to optimize our assets utilization. As this has been done for various companies this is a rapid deployment program that should not take longer than 4 weeks to document, review and communicate.
[2] At a minimum start with standards and develop new naming standards. Continue with FEDW architecture and automated modeling for HANA; define a global BW-on-HANA landscape, data architecture and data quality along with governance. 
[3] It is mandatory to build the global HANA methodology but not mandatory to implement it prior to migration. Only when the methodology is defined can the stakeholders decide what they want to deploy at what Phase. For example the enterprise could decide to build all new content on the new HANA methodology.

Plan for global consistency in standards and processes as your foundation. Plan to use available resources for planning your HANA migration. Ensure that whether your BoH is in Singapore, Brussels or Chicago it follows the exact same guidelines.   

4.      Demand IQDCT
                 ... Increase Quality, Decrease Cost and Decrease Time in BoH Migration

Background:  no matter how we look at HANA and the business value it brings one of the largest concerns that remains with customers of all sizes is the HANA Sticker Shock.  However, the critical question to ask is whether the HANA cost is static or dynamic. Quote me as I clearly state that the HANA cost is dynamic and subject to optimization based on best practices and scientific principles. With the right advisors you can assure yourself of a minimum of 40% reduction in costs and as high as 80%.

Business Case: The first customer had 4 BW installations globally. BW1 was a 107TB instance; three regional BW’s were another 90TB. With this customer we finalized Global to move to BoH1 and all regional BW’s (3 in totals) to move to BoH2. So from 4 BW’s. This company also had 2 BW Accelerators. To cut the story short my methodology migrated them to HANA on what I term as ‘Near-Net-Zero’ migration cost, i.e. their post HANA TCO was very close to their current BW TCO. This company cleaned up their BW and as a result shot their user satisfaction from 28% to over 80% in the BW-on-HANA environment

Our second customer listened to all the recommendation. Took the 1 day workshop and managed to reduce their BW database from 52TB to 27TB but then thought they had all they needed. They went and migrated to HANA without adequate cleanup. Their end result was they managed to reduce costs but not increase user satisfaction. 

 Recommendations:
When you are on a winning streak don’t stop due to lack of stamina or because it exceeded your expectations midway. The IQDCT methodology is a process that will maximize your ROI and at the same time minimize your ROI.
[1] Gartner clearly states that as we start in big data we need to move from EDW to FEDW architecture, we need to remodel our Cubes prior to migration and clean-up the BW environment to optimize our assets utilization. As this has been done for various companies this is a rapid deployment program that should not take longer than 4 weeks to document, review and communicate.
[2] At a minimum start with standards and develop new naming standards. Continue with FEDW architecture and automated modeling for HANA; define a global BW-on-HANA landscape, data architecture and data quality along with governance. 
[3] It is mandatory to build the global HANA methodology but not mandatory to implement it prior to migration. Only when the methodology is defined can the stakeholders decide what they want to deploy at what Phase. For example the enterprise could decide to build all new content on the new HANA methodology.

Don’t allow your triad partners to take you down the yellow brick road that is paved with your assets. Demand IQDCT and a simultaneous increase in quality (Start with this) along with decrease costs and migration times by a minimum of 40%. Remember it is easy to increase quality and increase costs, it is easy to decrease time and decrease quality, it is equally easy to decrease time and compromise everything. The goal here has to be IQDCT period.     

5.      Rethink your Architecture, modeling and code reviews
                 ... The future is in cloud with  automation and more automation

Background:  Most BW installations surveyed (probability 0.8) are built as report marts. Large corporations have build data marts. A few have built a single global BW in the form of EDW (Enterprise  Data Warehouse) and these will not migrate perfectly in the new world order of acquisitions and divestures. Business stakeholders need to plan for their BI with the future in mind.

Business Case: The first customer is a major CPG company with their products in almost every home. They split their enterprise into two legal entities and in order to accomplish this they also split their ECC and BW environments. Over the last few years they have spent millions of dollars to accomplish a partial split of their environments. The main hindrance was common orders in their ECC that could not be split efficiently and common objects in their BI environment where splitting data elements by company were not possible without considerable additional work. In short the benefits were not worth the effort.  In order to solve their future design we have proposed a FEDW (Federated Enterprise Data warehouse design) that is build modular from the start like Lego blocks. While their traditional model glued lego block with superglue the new model allows them to add new acquisitions and separate existing entities like true Lego blocks. Their future design will allow them to split companies ovr a single weekend with ‘zero’ impact on all other legal entities.

Our second customer, a global make to order enterprise, started their BW in 2008 on the FEDW model and automated modeling baseline. When it came time to buy downstream distributors and make to stock their BW was realigned over two weekends and as the possibility of new entities was built into the design they got back on their feet with the new analytics three months before business even required it. This is just one of the advantages of the FEDW design.

 Recommendations:
Gartner in 2013- “This is a time of accelerating change, where your current IT architecture will be rendered obsolete,” “You must lead through this change, selectively destroy low impact systems, and aggressively change your IT cost structure. This is the New World of the (big-data), the next age of computing.” Mr. Sondergaard, Gartner Sr. Analyst, said.
[1] Rethink your architecture prior to moving to HANA. Then plan how to implement it. At a minimum all new developments in the new BoH environment must conform to the new architecture
[2] The worst architecture is report marts, the next is data marts, the recent design was EDW and all these are legacy designs and have to be dropped
[3] In the new nexus of HANA think FEDW, or Federated Enteprise Data Warehouse design. This allows many advantages the most important of them all being 100% centralized governance with 100% local independence. This has been implemented in over 10 very large global BW environments and our recent advantage to this model was a seamless integration/ migration of 3 regional BW environments to a single BoH environment.
[4] At an executive level when you think HANA-as-a-Service on Cloud think Amazon. (I) Start and end services with a single click; (ii) The HW must grow/shrink on demand; (iii) Billing must be on usage

Don’t proceed with a HANA migration without considering and understanding the FEDW design, its advantages and the effort of converting your current architecture to FEDW.  Then undertake a simp0le effort vs. benefit analysis to decide how you plan to deploy it.   

6.      HANA GPS Workshop
                 ... No wind is a good wind if the captain does not know their destination

Background:  When we land at an airport and have to visit a customer where we have not been before we rent a car with a GPS. We first have to enter our destination; our GPS knows the current location and with these two points and best practices embedded into its processes provides us a turn by turn direction to our expected destination. We recommend a similar two point check prior to commencing any BW-on-HANA migration initiative, i.e. identify your business expectations (destination) and your current IT capabilities ( Current location) and the rest is fairly logical and scientific task of building a strategic HANA charter (what all needs to be done) and your HANA playbook (roadmap)

Business Case: The first customer a global pharmaceutical enterprise decided to move from their BW 3.5 to BW 7.x and BusinessObjects 3.5. Their protocol order was to copy their 1999 Cognos reports and deliver them via BW and BOBJ. Reason very low user satisfaction. Their deliverables were very predictable and they ended taking 2 years, a delay of go-live by 8 months and a user satisfaction score lower than when they started. Their PM and CIO was summarily replaced. The SI recommended they hire lower cost resources from India under their guidance and move to HANA. They will go live in Q4 of 2014. Does any of the readers doubt when I state that this company will once again land exactly where they are. Remember Albert Ennsteins statement “Lunacy is doing the same thing again and again and hoping for different results” .

Our second customer opted for our GPS workshop which was completed in 4 weeks with business and IT. The workshops saved the enterprise over 68% in cost, increased their data quality by over 40%, and migrated one of the largest BW’s on the planet (total BW landscape in excess of 300TB) delivering the highest quality at a planned lowest cost.

 Recommendations:
GPS workshops are mandatory for BW-on-HANA migrations as they scientifically develop a plan, a charter and a roadmap for the migration. Do not proceed without this step unless you plan to fail in your HANA initiative.
[1] Gartner clearly states that as we start in big data we need to move from EDW to FEDW architecture, we need to remodel our Cubes prior to migration and clean-up the BW environment to optimize our assets utilization. Today this is a rapid deployment program that should not take longer than 4 weeks to document, review and communicate.
[2] At a minimum start with standards and develop new naming standards. Continue with FEDW architecture and automated modeling for HANA; define a global BW-on-HANA landscape, data architecture and data quality along with governance.  Document, communicate and govern after that.
[3] It is mandatory to build the global HANA methodology but not mandatory to implement it prior to migration. Only when the methodology is defined can the stakeholders decide what they want to deploy at what Phase. For example the enterprise could decide to build all new content on the new HANA methodology. For example if you have more than 1 BW should you merge them into one of migrate each instance separately.

Don’t allow your triad partners to take you down the yellow brick road that is paved with your assets. Remember it is easy to increase quality and increase costs, it is easy to decrease time and decrease quality, it is equally easy to decrease time and compromise everything. The goal here has to be IQDCT period.  Demand IQDCT with a commitment to simultaneously increase in quality (Start with this) and decrease costs plus reduce migration times by a minimum of 40%.

7.       Demand business participation at every phase, decision & step               
 ... Gartner 2010 “without business in business intelligence, BI is dead’

Background:  I keep this as item 7 so we do not forget it. It is your critical take away from this blog. The importance of business inclusion in every BI decision has been validated and proven over the last five to six years of BI deployments and BoH (BW on HANA) is no different. It is critical to remember that business is your customer, your financer and your jury. Train your business stakeholders in the BVA (Business Value Attainment) principles and empower them with professional ownership and accountability. I state this again and again ‘HANA is not a technology installation but a business solution’ so please take that away from this read.

Business Case: The first customer a global pharmaceutical enterprise recommended moving to BW-on-HANA when their users were very satisfied with their BOBJ deliverables, as defined in recommendation 6. When their BOBJ was a disaster their technocratic advisors, i.e. their SI and IT jointly advised to move to HANA as the strategic solution. Because they, once again, are not involving their business users or stakeholders other than to release their budgets, our prediction is that after moving to HANA they will once again find themselves in exactly the same scenario as they are in today.

Our second customer is a CPG customer and we started with a business workshop for three days prior to starting our HANA migration. We identified their expectations, provided them concerns with their current applications and infrastructure and even undertook a POC with Oracle Exadata and HANA. At the end HANA proved to be the winner in this case as speed was their primary driver for fiend sales mobile analytics. In accordance to our agreement with business we initiated a weekly conference call with key business stakeholders, commenced in a BW cleanup, identified redundancies and duplicates via automation, cleaned their BW and ended with a 63% reduction in HANA migration costs from their original estimates. Their HANA project has started and the weekly calls with business stakeholder will assure that each change is in accordance to business needs and expectations.  This is the same customer where we scored 102% in our user satisfaction survey 20 weeks after go-live in a new BOBJ implementation three years ago. Because of our past record and proven process  both IT and business is confident of tactical deliverables and strategic alignment to business goals.

 Recommendations:
GPS workshops are mandatory for BW-on-HANA migrations as they scientifically develop a plan, a charter and a roadmap for the migration. Do not proceed without this step unless you plan to fail in your HANA initiative.
[1] 2010 BI Valuenomics report: “98% of BI projects are declared successful in week 1 after go live, yet only 50% remain successful by week 10”. Our methodology is a cure for the cliff that most BO projects fall off 10 weeks or so after go live- when user satisfaction becomes a nightmarish reality.
[2] Business executives need to be trained in executive briefs (currently a 2 hour workshop) and business owners and stakeholder for a little more detail. These workshops come with tips and tricks on how to ensure HANA migration success, tips and tricks on how to IQDCT and other such details.
[3] Once armed with the executive training the business stakeholders are now empowered to ensure that failure is eliminated as an option with checklists and proven methodologies.  

Make your HANA migration a business inclusive design with full ownership and accountability from business stakeholders. With BVA training your business stakeholders will be able to take professional decisions and ensure that each customer is a 100% referenceable customer in your HANA arsenal.

Apr 4, 2014

Part 1: 7 Things CIO's dont say in BW-on-HANA Migrations


This blog is about what not to do. It will be followed by Part 2 highlighting - what to do.
We all want our HANA decisions to be successful. 80% of HANA migrations will start with HANA Analytics so we place our focus on this one aspect. Also it is critical to remember that the columnar and In-Memory is best suited most for analytics- so you need to get this one right from the start. 
You should start with a personal goal that – I want this to be successful from the get-go. At the end of the game no one will ask you if you spent a little more or a little less but how it met business expectations. In fact all our research proves, beyond reasonable doubt, that BI projects that are successful, i.e. meet business expectations, are never audited for how much they cost. Conversely, every BI project that has failed, to meet business expectations, is never measured on how much it saved. The distance between success and failure is razor thin, just as the distance between lunacies and genius is. The decisions you take today, the advisors you associate with and the ones that influence your decisions- no matter how inconsequential they feel today might be knocking on your enterprise, and your career, door and somehow placing your career options kind of out of reach.
The success of your HANA migration is important to both you and your career to be put aside. Here are the top seven things you need to strike out from your workplace vocabulary if you want to achieve both tactical and strategic success that is now in your grasp- it is your right of first refusal...

1.      “I don’t truly understand HANA”
                 ... so I have my experts  guide me in our HANA initiative”
Background: In my last few HANA installations, now totaling over 19, I have met various stakeholders that clearly state that they do not understand HANA and have advisors that will take ownership and accountability for all decisions. When we dove a little deeper we found that their internal experts had almost the same level of HANA understanding as they did. Still diving a little deeper we then found out that these key-internal-stakeholders then depended on their level 1 triad partners whose experts too knew a little about HANA but not to the depth and breadth required to make a professional holistic decision that is beneficial for the enterprise business stakeholders. In short what these various layers guaranteed customers was regurgitation of corporate sales positioning that were generically correct but not fine tuned for any single customer. In BW terms that most customers get is standard business content- which is almost guaranteed to sound very nice but rarely meet business expectations.
Content: When you accepted your current position as CIO, BI Lead or a Steering committee member you had a good idea of your role, ownership and accountability. As a CIO, BI lead, corporate information owner or a steering committee member you have taken the ownership and accountability to ensure that the decisions made by your group are tactically and strategically area aligned to meet business expectations. The key words here are ‘ownership and accountability’ and ‘business expectations’, everything else is a distraction- including the technology called HANA.
Very early in the game it is critical to remember that “HANA is business solution and not a technical installation”. As an owner of decisions you are no longer hired to state that you do not understand the executive HANA factors, i.e. do not understand the tactical or strategic impact of your HANA related decisions. It is also important to remember the Gartner 2003 and 2013 BI reports that clearly stated- 2003 “Fewer than 50% of BI projects will meet business expectations” and in 2013 “Fewer than 30% of BI projects will meet business expectations”.  My translation: In 2003-2009 50% of reports in your PRD BI environment did not meet business expectations. In the 2012-14 period 70% of reports in your PRD BI environment are not being used, or will never be used, by your business users.  If you nod yes to this statement you need a HANA Business Value Architect today, if you don't then you are planning for failure.
If you depend on your current experts then they can only take you down your current trajectories, i.e. what I refer to as the Gartner nightmare.

Recommendation:
Don’t end up blaming your ‘experts’ and ‘advisors’ when your HANA initiative does not meet business expectations.
[1] The Executive decision team needs to get themselves a ‘2x2 hour HANA Executive workshop’. This workshop comes with a two hour executive workshop and a bunch of checklists for each stage of the HANA decision. For example what are the critical selection criteria’s before starting a HANA Analytics project. Or, what are my alternatives to meet my business needs and how do they stack with each other? etc.. Ask for a BW-on-HANA GPS workshop executive brief. The second two hour is spent with actual operational resources on how to use the checklists. The executive workshop decides on which two to select and run the process through. It could be as simple as what HANA Cloud partner to select for our HANA initiative.
[2] Without providing adequate executive training your HANA migration is in-fact  planning for failure. Do not plan for failure invest a half day to access checklists to success.

Modern executive and key-stakeholders must no longer expect to hide behind ignorance as that leads to item #x- the Do not resort to the blame game as there is a two hour solution now to mitigate that defect.

2. “Our experts told us to do this”
Also called “What got you here will certainly not get you there”

Background: In their 2013 Gartner put is very beautifully stating: “This is a time of accelerating change, where your current IT architecture will be rendered obsolete. You must lead through this change, selectively destroy low impact systems, and aggressively change your IT cost structure. This is the New World of the Nexus (big-data), the next age of computing.” Sondergaard, Gartner Sr. Analyst.
Reading between the lines in resonance to the earlier Gartner report in this article we clearly recommends changing your global BI methodology, i.e. standards, processes and governance, all we will get is land at the same spot in the very near future. Even if it means changing your current SI as their lowest cost option is to continue with the existing BW resources and methodologies.  It reminds us of Albert Einstein’s statement “Lunacy is doing the same thing again and again and expecting different results”. In short HANA there is a dire need to renew your total BI methodology to optimally leverage our net-new platform with renewed set of standards, processes, architecture, modeling and governance. Any triad partner (SW, HW or SI) that states that the same rules of BW will continue to apply to HANA is taking you down the path of Gartner’s nightmare. They are planning to reuse their current SAP BW assets to take your HANA project along the same trajectory as your BW has done up-until now. For these ‘experts’ my single question is based firstly on a question (in the form of an assumption) followed by the question you need to ask our triad ‘expert.
Assumption: The way we translate the Gartner BI report of 2013, i.e. “Fewer than 30% of BI projects will meet business expectations” is by performing a high level self audit with a single statement (my interpretation of the Gartner findings). Over 70% of the reports in your current PROD BI system do not meet business expectations’.  If you nod to this statement then we go to the question- if you do not agree to the above statement you belong to IT and are not the business user community.
Question to ask: Tell us what is the business value of accelerating a 715 second report to 1 second if business is never going to use it?

.. and there you have the strategic answer to your initial assumption, i.e. the reliability of your taking your current methodology and simply installing it on BW-on-HANA

Recommendation:
Don’t end up stating that you did not know after your HANA investments do not meet business expectations.
[1] START WITH a ‘BoH (BW on HANA) GPS workshop’. Just like in a GPS situation where it is necessary to know your destination and your starting point before you plot your turn-by-turn directions. The GPS workshop is leveraged to document the same in a BW to à BoH HANA migration. These workshops take a mere 2-3 weeks and WILL save millions along the way. These workshops simultaneously document your business expectations and technology current state and deliver an executive charter and roadmap for BoH Migrations.
This workshop comes with a two hour executive workshop and a bunch of checklists for each stage of the HANA decision. For example what are the critical selection criteria’s before starting a HANA Analytics project. Or, what are my alternatives to meet my business needs and how do they stack with each other? Etc.. Ask for a BW-on-HANA GPS workshop executive brief. The second two hour is spent with actual operational resources on how to use the checklists. The executive workshop decides on which two to select and run the process through. It could be as simple as what HANA Cloud partner to select for our HANA initiative.

Only quitters throw in the towel, or blame others. Winners consistently plan to succeed. Wit5h current BVA (Business Value Attainment) principles, extensive HANA experience and scientific processes failure is no longer an acceptable option.

3.      “It’s not my fault”
                 Also called “Let’s hang someone else and let them take the blame”
Background: In their 2010 BI Valuenomics reported that: “98% of BI projects are declared successful on the week after go live, yet less than 50% of them remain successful after 10 weeks.” Sondergaard, Gartner Sr. Analyst.
So this report indicates that most BI projects, regardless if they are Oracle, Teradata, BW or something else tend to fall off a deep cliff in under 10 weeks. As an executive it is critical to firstly ensure that this does not happen and secondly when it happens your key stakeholders don’t end up play the traditional blame game – “It’s not my fault”.
No one wants to ever start to be viewed as a blame shifter. However, it is only a matter of time before some finally find it most convenient to shift the blame to someone else. Executive do not simply need to take ownership and accountability, but they need to be trained to take ownership and accountability with a scientific approach of being able to ask the right questions and installing the right processes and standard to eliminate the probability of failure. Only by admitting to failure can an organization learn from their mistakes. Shifting the blame on someone else only ensures that we make the same mistake all over again. Pointing fingers strongly predicts that this same stakeholder will never truly learn from their mistakes.

 Recommendation:
Don’t plan to get into any situation where you have to shed blame from yourself and point fingers at someone else when your HANA migration does not meet business expectations.
[1] START WITH a ‘2x 2 hr executive workshop’ for your key stakeholders. 
[2] Plan for success based on proven scientific principles and only then work your plan

Never forget that HANA is not a technical installation but a business solution.

4.      “Let’s not involve business in BI projects”
Background: In their 2010 Gartner probably made the most powerful BI statement since its inception: “..without business in business intelligence, BI is dead”. Critical error when aiming for success
Still three years out we continue to see the business owners and project investors kept out of BI rooms in a planned protocol manner. Under the BVA principles – this, according to Gartner and I, is planning for failure. Normal business involvement is getting them to sign off the budgets, showing them business content and getting their UAT sign offs. Since 2006 our experts have consistently recommended and practiced including business stakeholders in approval, decision, design, architecture, OLAP and deliverables in weekly conference calls. This has resulted in our last two BI projects scoring above 80% user satisfaction 20 weeks after go live, in a world dominated with under 30% user satisfaction. Need we say any more?

Recommendation:
Make sure business is trained to take ownership and accountability of their investments, assets and deliverables in all projects BI including BoH.
[1] Remember that business funds most BI projects, business is the owner of most BI deliverables and no one can tell me business is not the judge of all deliverables. Once business states it does not work all other comment have little value.
[2] In all my 15 years of BI experience once business declares that the delivered reports do not meet business needs there is little any of the triad partners or IT can do to reverse that judgment.
[3] Instead of selling technocratic solution that is built without business communications CIO’s need to market their BI deliverables in full communications with business stakeholders.

If any of your Triad partner recommends you keep business outside the doors of your BI project room, show them your door as they will take your BI project towards the Gartner nightmare.  Find a partner that will drive your project along the BVA principals of success.

5. “We don’t need any help.”
The rugged heroes playing cowboys and Indians (the US native Indian types) are mostly found in action movies, but they are unlikely to become heroes in your enterprise or your HANA implementation projects, just like legacy BI projects. Executives, BI Managers and client PM’s sometimes think that they can make it alone on a BW-on-HANA project but all their experience and their partner recommendations are consistently working against them. In the new HANA platform most of your existing standards, architecture, modeling and governance documentation is now obsolete. The BW-on-HANA migration is the type of project where you have to challenge your instincts, what you have learned so far about traditional BI.  Gartner BI reports from 2003 onwards to 2013 clearly establish that what we learnt up until HANA will harm us more than help unless refocused by an experienced HANA Business Value Architect.

Recommendation:
Don’t try to make this journey on your own or with legacy ideas, advisors or partner methodologies
[1] HANA is a new business platform so get yourself a ‘HANA Business Value’ Architect
[2] In all my 15 years of BI experience once business declares that the delivered reports do not meet business needs there is little any of the triad partners or IT can do to reverse that judgment.
[3] Instead of selling technocratic solution that is built without business communications CIO’s need to market their BI deliverables in full communications with business stakeholders.

If any of your Triad partner recommends you keep business outside the doors of your BI project room, show them your door as they will take your BI project towards the Gartner nightmare.  Find a partner that will drive your project along the BVA principals of success.

6. “This is the way it has always been done”
Simply doing things the way they have always been done is no way to run a modern business; it is also anti change and development. This is like trying to reach a goal ahead by driving in reverse. Your triad advisors may repeatedly state that they can leverage their existing standards, processes, designs and methodologies; they may also recommend they can leverage their existing resources and architects. They may further recommend that you can simply migrate your current BW to HANA as the path of least resistance. All these recommendations are completely erroneous to a very large degree. Yes, the current BW can be leveraged but there are changes you need to make before, during and after migration.  For example your SI advisor should recommend reducing your current BW database by a minimum of 40% prior to commencing migration, and if your BW is anywhere close to normal then they should be able to guarantee this as a commitment.  This has a direct impact on your TCO with a 40% reduction in initial costs, 40% reduction in migration times and 40% reduction on your annual support SLA costs. This is also just one of many areas where we can increase quality and decrease costs for BW migrations.  

Recommendation:
Remember the initial statement ‘..what got you here is not going to get your there’. Plan your migration prior to commencing your migration.
[1] Find yourself a ‘HANA Business Value’ Architect’ that you can trust
[2] Conduct a high level audit of your existing methodologies and governance
[3] Consider undertaking a GPS business and IT workshop if your BW is over 5TB of legacy

Never try to do what you have always done in the new HANA environment. Adaption is the only assurance to survival and change is the only constant. In the new HANA platform there is a need to conduct an executive audit for tactical, mid-term and strategic business benefits and then ensure that all tactical, mid-term and strategic initiatives align appropriately with strategic goals. This will assure [1] Increase your information quality; [2] Decrease migration costs; and [3] Decrease migration time- all of this contributing to overall success. It will also simultaneously prevent future deconstruction and wastage of valuable assets. You need to make a HANA Business Value Architect as your right hand advisor, and then come up with creative solutions that are proven to exceed business expectations.

7. “Can I get at least a 40% success?”
This actually happened in one of my recent, post 2010, BW on HANA installations. Ten weeks before go-live the customer called upon me and during my audit asked if they could at least meet 40% of business expectations. Unfortunately my report stated they would meet fewer than 18% of user expectations. This was a net new BoH installation. The client had hired Gartner for their initial executive planning and come away with a 50% probability of meeting business expectations in their new BI implementation. They then hired one of the existing SI’s, who used their existing BW team to deploy BW-on-HANA and drove the investment down the traditional path of Business content. This took them straight into Gartner’s nightmare scenario.

Recommendation:
Whether you are a BW migrate to HANA or a net new BW-on-HANA customer your minimum tolerance should be over 80% business user expectations. Once again remember the initial statement ‘..what got you here is not going to get your there’. Plan your migration prior to commencing your migration.
[1] In migrations start with a mandatory 40% reduction in your existing database size
[2] Follow this through with automated remodeling of cubes for HANA
[A] In net new BoH installations start with a global HANA methodology that is documented and communicated
[B] Aim for a 80%+ end user satisfaction goal 20 weeks after go live

Be part of success and do not plan for failure as an option.