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.
