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.
No comments:
Post a Comment