5 Things that Cripple HANA Projects before it Even Starts

If you’ve ever been involved in any SAP project we know there are many things that can go wrong. It all came to focus when I was recently talking to a CIO who stated ‘It’s not about HANA..?

In almost all my experience it was never about SAP ERP, or SAP BW, or SAP BWA or now about SAP HANA. It was all about the decisions that were taken with each of these business enablers.

In poll after poll our results from customers and users have constantly come back with response that illuminates this point. When we asked whether they thought that SAP BW could meet their business needs over 95% of users have consistently answered ‘Yes’. When asked their own current satisfaction score the ranking stood somewhere between 18% to 36%. This is what the CIO meant by saying ‘It’s now about HANA..(That I’m worried about). We recently delivered a BI project where the user scored us at 102% (now that seems ridiculous as it’s a mathematical impossibility) but that is how we were scored. Also it was 21 weeks after go live. This is based on another report we published that reported that ‘98%

As we go into SAP HANA’s platform replacement or net new Greenfield implementations, we all know there once again are many places where things can go wrong again. How many of us have been involved with SAP BI projects where things went wrong.

We all also know that there is nothing worse than seeing a good project go bad. There is nothing worse than seeing protocol decisions that doom projects to failure before the project even begins. My book ‘BI Valuenomics – the story of meeting business expectations’ is full of such business cases and examples and was written from the ground up for business stakeholders to take ownership and accountability in a scientific manner.

But there's nothing worse than seeing a project doomed to fail before the implementation even begins because of non-optimal decisions taken that have little to do with the new HANA platform, but more about how we have been doing things so far.

Customers worldwide are still grappling with the SAP HANA decisions.  Regardless of the region, industry or sector, we’ve see common mistakes that cause SAP HANA projects to not provide the anticipated Business Expectations, something we term as BVA or Business Value Attainment.   Here's a list of the top five mistakes that we've seen selection teams make during the procurement phase:

1. Not focusing on Business Benefits

Gartner stated it very aptly in 2010 ‘Without business in business intelligence, BI is dead’. Companies need to hold executive workshops of two to four hours for their key stakeholders, GPS workshops for their Business owners and IT owners to empower business to become part of the design, architecture and implementation process. We recently built two RBS® solutions, which are 100% custom business solutions and each of them scored in the upper 90% customer satisfaction score in a world dominated in the lower 30% (for customer satisfaction. Focus on Business Value and not only the data’

2. Treating SAP HANA as just another Technical upgrade

Our motto: ‘HANA is a strategic business solution not just a technical install’ has resulted in many large HANA customers deriving very high business value from their initiatives. If we don’t plan to extract business benefits from HANA then the platform will deliver exactly what you plan. The biggest mistake customers can make is to move all their current SAP applications to HANA ‘As-Is’. This is highly desirable for the triad partners- but not necessarily in the strategic interest of the customer and their business users. Start by asking what your strategic goals are, ie. What business will you be in five years from today? Follow through with how to get the Highest Quality at the lowest cost? Finally what did not work for other customers? There are far more lessons in failures than promises of success.

3. Canned existing Partners

We all come with deep alliances with their HW and SI partners. SAP is a zero option in this question as the SW partner- unless they are also your HW(Cloud) and/or Implementation partner. Gartner stated this eloquently ‘“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 Nexus (big-data) the next age of computing.” Mr. Sondergaard, Gartner Sr. Analyst, said in 2013. In this time of change reconsider your partners in the strategic domain of Big-Data, Digital monetization, IoT and then HANA. Your HW and SI partners must take ownership, not of migrating you to HANA but delivering business benefits and benchmarked business satisfaction scores for the project to be considered as delivered. We call it the technology Acid Test.  

Another thing to remember is a famous statement ‘What got you here, will not get you there’ – this reasoning is buried within the statement by Gartner above. So using existing architecture, methodologies, architectures systems and costs structures will be a form of self-cannibalism bot by the enterprise and the key stakeholders.

4. Canned decisions

Many Companies first decide their partners and then get into negotiating. Time and time again we see companies sacrifice their negotiating rights until after the vendor is selected. Most companies simply go through the process of three vendors knowing fully well that the selection will be their incumbent vendor. The vendors know that too. We have seen executive decisions that ban business stakeholders from entering project rooms to instructions being given not to talk to any other vendors unless they are whetted by the incumbent vendor. All this simply delivers is what you currently have on a new platform. Our question is very simple ‘You tell us the benefit of accelerating a query that takes 1,500 seconds (actual case) to under 1 second. It business is never going to use it”. Here is a brief guideline for the modern CIO planning to move to HANA.

5. Not optimizing SAP prior to moving to HANA

Time and time again we see triad partners speed customers to move to HANA with more attractive pricing, deals and add-ons so they can close the deal in this month or quarter. Time and again we see customers get influenced by these recommendations. By moving to HANA in an ‘As-Is’ state customers are throwing away anywhere from 40% to 68%, represents actual results, of their assets that they could otherwise save and use elsewhere.

In case you are interested it is possible to reduce your BoH migration TCO by 40% with a probability of achieving this at 90%. In fact the last three BoH optimizations we have undertaken all were 100% over 40% reductions. This directly translates into a 40% reduction in your initial HW costs, 40% reduction in your initial migration costs and a 40% reduction in your annual support SLA’s. This represents is the cream of our services and our focus on TCO reduction – is is directly related to financial business benefits. In a $10 million HANA project this could represents an initial saving of $4 million and an approximate saving of $1 million in the next 5 years.

When it comes to your final decision demand IQDCT (Increase in data quality, decrease in Cost and Decrease in time for migration) as a deliverable and business benchmark.

We are so confident of our process that we often tell customer ‘ Don’t pay us a thing. You get your quote and then let us optimize- then you pay us 20% of what we save you”, we add “You’ll pay us many times over that what we will charge you for the service”. No one’s yet signed on our Free for 20% contract yet, and we’ve delivered 100% of the time.

Conclusion

‘Plan your work, and only then work your plan. You only get what you plan for so make sure business benefit is in your deliverable mix for your HANA project.

7 Critical Elements to a Successful Partnership

Today is as good a time as any to take a new idea, form new partnerships towards a common goal. A business partnership is very much like life itself, and it is the human factor that always makes or breaks any relationship, collaboration, alliance or partnership. Whether in business or in life, it’s the human element that makes or breaks any forms of relationship, collaboration or alliance. Companies don’t create alliances and relationships people do.  

Since the beginning of time humans have been social animals. Some say that humans are like termites that live on small mounds on this planet and we only make them bigger and bigger. While some see this as a negative statement I think that is exactly who we are. Humans are social animals and we grow best when we share, co-exist and thereby co-innovate. We would never have been where we are today if not for our being intrinsically very social animals. However being a human is not enough to succeed in a relationship or partnership. We can all get into relationships but few can maintain that relationship at a level of quality that is truly a synergy of personal and professional force multiplier.

Partnering is a lot like dating, and if you have not read my recent fun blog on dating and polling then do run by it – ‘How Big-Data is making Polling Obsolete’. The first part of dating is honesty, but evidence proves that being honest seems to be the responsibility of only 50% of the respondents. There is the question of ‘id’ and ‘ego’. Ego being our portrayal of who we want to be perceived as and Id being who we actually are- its briefed in the blog. Finally it boils down to what we have to offer any partner, what differentiates you from the crowd, are your details complimentary or competitive, and finally how dedicated are you to the partnership and not simply yourself and your ego. Partners is a great relationship need to be transparent, trustworthy, mutually complementary and desiring a great and profitable relationship.

 Here is a list of critical elements that make partnerships successful.

In my experience, after two decades of helping companies create multiple forms of strategic collaboration, I came up with 11 critical success factors that could make or break a partnership in business.

1. The Business Value element: The only test of any new idea is the impact it has on your bottom and top line. No matter what your partnership plans to deploy, build or service there has to be a clearly identifiable business benefit for your customers. This will be the reason customers will come to you and remain with you, this is the reason they will tell other customers about your company and this is the way the partnership will ultimately be beneficial to its customers and the partnership. The second part of this element is it must be beneficial to both partners. Partnerships must be designed so neither party loses, even if they don’t initially make a profit.
2. The Trust element – Trust is like the parachute chord between you as the jumper and the parachute as the partnership. Having worked together for long or briefly but having a strong trust factor. People work as a tram with other people they like to work with and can trust. There are volumes of research that establish that humans chose people they like. We like to team with them, partner with them, have relationships with them, marry them, and love spending our precious times with them. They are basically trustworthy and fun to be with. You need to genuinely trust your partners and never feel that they are not putting their cards on the table or have an agenda all of their own. There are enough successful stories between the founders of major companies and it all boils down to professional and mutual trust.
3. The Compartment element– The big question in most exceptional partnerships is the professional compartmental element. When we studied Duo partnership one was always the outgoing, sales and marketing personality and the other the doer. This mix works exceptionally well so long as both partners understand their compartment. The best partnerships like Steve Jobs and Woz are based on very tight, even in uncomfortable situations, compartments. Woz never wanted to be Steve and Steve never wanted to be Woz- perfection. Learn from the best. These two complemented each other to form what can be viewed today as one of the world’s greatest technology company. Though partners need a compatibility of trust, likeability, values and processes, they also need to be very separate in who is accountable and owns what aspect of the partnership. Too many partnerships crumble when one compartment thinks they can do the job better o their own.
4. The Alliance element – Alliances are the strength of companies as they start to grow and need specialized skills or needs. No group of individuals can be exceptional in everything. Just like each individual has their own skills and strengths so does a partnership. An important part of a partnership is in identifying mutual strengths and making them stronger, along with also recognizing our weaknesses that could make the partnership weaker. Alliances are one way of getting past this hurdle.
5. The Fairness element: If you plan to get the cake it must not be at the expense of someone else getting the crumbs. No one likes to be taken advantage of in any situation. So the more ownership an individual or a group has on the overall success of the company the higher must be their share of the pie. Fair never means equal. All parties must feel they are treated in a fair and professional manner and get out of the partnership a quid-pro-quo that is proportionate to what they are putting into it and contributing towards the overall growth.
6. The Strategic element: Without a strategy all winds seem to be good winds. This includes the tactical, mid-term and strategic goals, visions and expectations. When partnerships fail they often do so either because different people had different agendas or different expectations. Partners have to be clear and transparent to all aspects of the lifecycle of the partnership and the partnership.
7. Clear Communications element: Some partnerships communicate others communicate skillfully- this leads to miracles. Communications is the lynchpin of all relationships. All too often partners either try to hold communication of bad news or just communicate it blandly. We recommend partnerships can postpone good news a little but broadcast issues immediately. This leads to early resolutions and eliminates unnecessary headaches.

Be brutally honest in your partnerships. Share your experience and profits and don’t cut corners. Great things don’t happen overnight. Focus on the light- the key question is do you see the light at the end of the tunnel- then you are on the right track.

The IoT Question: What Business are you Truly In?

This started as a Delphi discussion along with Scott Feldman from SAP, Alex Paleologoes a CTO from a Greek shipping company, Klaus Huber from Deutch Telekom and the undersigned over a round of beer in Palo Alto. We started discussing how IoT is already changing the very definition of any industry.

We started by asking the foundation question "What industry is the Ford company truly in?" Only to realize very fast that Ford is not in the automobile business any longer. Just like Kodak was not in the business of photography or Telex in the business of print replication. Ford and other automobile companies we agreed after a few minutes are in the business of taking a passenger, or a product, from point A to point B in a safe and timely manner. Using this as a baseline we then delved as to how the very definition of this industry is rapidly and predictably changing based on new IoT technology.

Google has been experimenting with over 10 driverless cars that have driven over one and a half million miles without a single accident, scratch or other issues. Each of you try and remember how many miles you had driven before your first scratch or an accident and we suddenly see a very different view of driverless cars. Imagine no more auto insurance, no more scratches, no more running out of gas, no more a whole lot of hospital bills and no more DUI or deaths on the road- what is the price for that assurance. Ten years from today when you have to buy a car for your 16 year old daughter will you buy a car that you get today or one that drives itself to where she need to reach in a timely and safe manner- and more.  At the same time Jaguar has built a car that tracks head and eyes movement and auto stops if the driver is falling asleep. And BMW already has a prototype self-parking car that works on streets as they are today with Zero changes. Its a driverless, self-parking version. You can drive to a restaurant, get out of the car and ask the car to park itself. The car will find the nearest parking spot on its own and park itself. You smart watch or BMW app allows you to step outside, walk around and when ready ask the car to pick you up. The car will self-drive to your location in driverless mode to pick you up. Now with all these changes the biggest disruptions to the Auto industry just might just be Google and Apple (Now that apple is planning on an Apple-Car (according to the Silicon Valley street talk).

Companies have to re-evaluate this new world of IoT that GE estimates to be $14 Trillion just in the IIoT space - that is the Industrial IoT, i.e. manufacturing sector only.  Cisco projects the IoE (Internet of Everything) as a $19 Trillion market. HRB predicts this to be a $14 trillion market. From our studies we see a $1-2 Trillion market in the SAP IoT Market area alone. So no matter how you slice these numbers the market is huge. Read the article by the anchor of global competitive positioning Michael Porter in HBR 'How smart connected products are Transforming Competition' and you will begin to get a feel of the disruption right around the corner.

Me thinks this is going to be as big a change as Computing was in by the mid 80's. The speed of change accelerates each year so adoption is going to be faster than computers.

Some sample disruptions we are already witnessing:

Smart IoT Hub: For the coming future we will see an explosion of smart devices from smart watches to Fitbits and other personal sensors. However the hub of all these personal IoT devices will remain the smart phone. The Apple and Android Apps will become all the more important. Data harmonizers will provide a single pane of glass to all your health apps that will surround you and your smart phone. We don't see this hub being replaced anytime in the near future- but then change is the only constant- who ever could foresee the disruption of the iPhone before it happened. event in the enterprise world this device will remain the personal hub of information for the near future with the maximum per capita penetration of all other devices with a easy UI (User interface)

Automobile: Our grandfathers used to drive a car which would often break-down without warning. It had to be towed to the mechanic who would take a day or so to find out what is wrong. A decade or two ago we fixes some sensors in our cars and a red light switched on when something was wrong, but the driver had no clue what was wrong till they took the car to a certified mechanic. The mechanic would shove a plug into the compute slot and carry some expensive decoder that would rapidly analyze what was wrong in the vehicle. Today we can get a gizmo that we can shove by ourselves and get that same level of detail on our IPhone or iPad. Companies like Tesla already have a dashboard console larger than a standard iPad that can tell us what is wrong.

In the future your driverless car will not only identify what may be wrong with a component but will simultaneously inform the car company, find a service provider, check their stocks and ask the owner that time slot is available for the car to self repair. At the same time it will talk to other cars to find out if this is a systemic problem or something isolated to this one case. with such a system we could avoid the Tekeda safety bag that some think turned out to be a grenade under the steering wheel in disguise from every happening.

Smart Healthcare: Patients will not become products with real-time IoT devices they carry or imbedded into their bodies. They will select providers not by loyalty by by crowd recommendations of quality versus cost. Patients will be walking data producers and broadcasters. All patients today are real-time IT data producers - a product for real time visibility across the entire health-care fabric.

Smart Farming: Farms are already becoming smart with precision seeding, fertilizer and watering undertaken with IoT sensors. This not only saves wastage and thus money but also results in higher yields. so its a win-win. All seeds, farm workers, soil condition, water saturation, fertilizers, finished product storage; transports are today becoming real-time IT data producers - a product for real time decisions across all the enterprise farms. add weather to all these examples.

Smart cities: Israel is the first country to go the smart Country way. Barcelona the first Smart city. Smart cities will monitor social security, buses, energy and water, parking, snow cleaning, crime, buildings, and a host of other areas with streaming sensors [places in all critical locations for real-time visibility of all critical flows in a city. All critical assets today are real-time IT data producers - a product for real time visibility across the city.

Smart Army: with guns, equipment and personal being tagged with sensors we can easily identify friend or foe in low visibility situations. we can identify friend down of the soldier stops moving and the weapon continues to move. We can track every shipment of ammunition and weapon from start to end and send real-time alerts when a shipment or part of the shipment is diverted into the wrong hands- all this in real-time. We are already building smart Army HQ's with 3D visualizations and tracking of every authorized and unauthorized entry into any room. This is the part we know. The soldier and all army assets today are real-time IT data producer - a product for our decisions.

Eliminating the Risk Out of the HANA TDI Model

Part 1 of this blog ‘Is TDI going to make the HANA Appliance model Obsolete’. was published in August 4^th, 2014. By March 2015 it has been reviewed over 2,000 times making it my most read blog so far. I have received many emails from readers stating that this blog made them rethink their Appliance model in preference to the TDI approach. This is a continuation to that blog so if you have not read the first one highly recommend you do as it lays the foundation to this blog. We have developed a leadership position in the North America market in SAP HANA-TDI build and deploy support and optimization to reduce TCO by around 40%. However if the customer wants to go with HP Compute and Net App storage and backup (TDI) then the mix could take slightly longer- but is very doable. We have faced many customers who had some very valid concerns with the TDI option with its current deliverables and support SLA’s. Here is a brief on their concerns and available solutions.

 

 

Very Important Note: The traditional Appliance model comes into play with vendors that provide HANA appliances only with their components. So if you buy an HP, IBM, Dell, NEC or SGI HANA box the Compute, Storage, Network all come from the same supplier. So if a customer states they want their compute from one of the above vendors and their storage from another then the TDI business case is clear and comes into play. This may be due to the customer wanting to use best in world-class components, or because they have some unused components sitting in their data-center or because their datacenter has standards/partners that would be better served with the TDI option.
Cisco is an outlier in the Appliance and TDI case. This gets slightly complicated when our customer asks us for a Cisco UCS Compute with an EMC Storage and requests both an appliance and a TDI Quote. Cisco sits in a very unique position of having started from the ground up with a TDI as their appliance. The Cisco designers chose from the ground up to go with best in world-class components. So their appliance comes with Cisco UCS Compute, EMC or NetApp Storage and other HANA stuff. Cisco HANA appliance is a TDI build from the get-go. So as a prospective customer when does an appliance make sense and when does a TDI come into play if you plan to go the Cisco route. My brief answer-
[1] Cisco Appliance: If you are buying everything net-new opt for the Cisco appliance, i.e. if you want a combination of Cisco + EMC or Cisco + NetApp.
[2] Cisco TDI: If you have a bunch of Cisco UCS servers, or EMC Storage or NetApp Storage sitting idle in your data center then take the TDI approach as that would be assembled and tested on site for certification. This is a net new question that has started flowing in just this week with more and more customers wanting to review the TDI option.


We currently see no evidence that any one company is the best-in-world-class vendor for all the SAP HANA components, i.e. as in a SAP Appliance. We also predict that other leading HW vendors will now rapidly reposition themselves towards providing options to build best in world-class components for your HANA TDI platform.

TDI is like a buying a readymade or a custom Pizza where you can choose your personalized toppings from a list of available options. The only difference here is that the toppings are available in your data center.

A HANA TDI platform thus allows customers to leverage and use their surplus hardware and/ or existing partners. For example an existing partnership with the world’s top two Storage vendors EMC and/or NetApp can now be professionally leveraged to combine best-of-world-class components versus that of being stuck with sub-par components inside a black-box appliance, that the customer is disallowed from touching without a single vendor service contract.   

However, while this TDI option did sit comfortably with IT owners, they had serious concerns in two critical areas.   
[A] Time-to-Value and
[B] Risk mitigation for on-Premise HANA landscape.

[A] Time to Value: In a HANA Cloud option Time-to-Value is identical or close to the Appliance model. The cloud option is a level playing field for one simple reason that in a HEC model what the customer needs is [1] system uptime SLA’s and [2] security assurances in compliance to all the industry requirements for the customer. What the HANA runs on is normally not an issue with a HANA Cloud solution provider, i.e. it makes little difference whether it runs on IBM HANA or Cisco HANA – it’s in the cloud. Also the cloud providers normally have HANA platforms available for on demand consumption or subscriptions. The cloud model works to satisfy very rapid start-up needs for a HANA platform and can be delivered in under 10 minutes on AWS to 30 minutes with other HANA cloud partners.

The major difference comes in the On-Premise HANA Appliance. Most large companies so far prefer to keep their production systems On-Premises for various reasons. Here once again the customer has two options.

Option A.1 - Existing TDI combination: In this option the Customer needs to build a TDI design that has already been validated before by SAP. Just as an example the company uses EMC as their storage vendor and use Cisco for their network. They also have Cisco UCS servers available in their data centers, and now need to consider their HANA TDI build. This customer would logically choose EMC storage, with a Cisco UCS Compute as a TDI build. As we know this mix is already certified we can provide a more rapid TDI solution to the customer.  

Option A.2- Custom TDI Combination: is when the customer wants to put together a custom TDI mix that has probably never been certified together before. For example the customer wants to go with HP Compute and Net App backup and storage along with cisco network- then the mix could take slightly longer- but is very doable.This is the only instance where the Time-to-Value clause would kick in for we will first need to build the TDI, then test it and then get it certified by SAP. Once certified we can then build the same mix as many times as the customer requires. The process can take around a month which could represent  the time to value impact. But if planned and done ahead of time this bridge is just a matter of proactive planning and a sign of professional execution. Who are the prime customers for TDI - Data Centers with existing partners and components in their inventory.

B. Risk Messaging: One of the biggest risks as perceived by customers, communicated  by most of the pure appliance vendors thus far has been that – with the TDI model you are on your own. This translates into something like this “If you buy a HANA appliance with us (appliance) then the support of that HANA appliance is standard and you’re fully covered by a SAP certified appliance and our global support framework. i.e. you have a single throat to choke. However, should you choose a TDI build then you are on your own. You will need a separate support contract with SAP, another with the storage partner, another with your Compute partner and yet another with your network partner. In most of such cases when you have a problem fingers will point in all directions and the customer will be the loser’. That truly is a very big issue and extremely important and a very convincing reason to choose the HANA Appliance model despite its carrying a ‘Black-Box’ mentality and rather high support costs for any ‘black-box’ support.

The Big Risk BVA*[1] Question:  What if a HANA HW partner provided the exact same ‘HANA Support Contract’ whether you buy a HANA Appliance or a TDI, i.e. a single service contract, a single hand to shake, a single call to make whether you choose the HANA Appliance or the TDI decision.

The BIG TDI Risk Solution:  The  2014 Gartner magic quadrant for integrated systems reported Cisco in the leader quadrant for Integrated Systems.   Cisco has  just finalized a single unified  Support offering for SAP HANA customers- whether they buy an appliance or a SAP HANA TDI platform. With this proactive support option the final barrier towards choosing a  TDI model is now mitigated. 

Note: in this chart both VCE and Cisco-NetApp are Cisco Computes. This combination provides the best-of-best world class Servers from a global leader.

Some additional notations:

1.      The datacenter is transforming towards enabling the converged infrastructure for a ‘Single-pane-of-glass’ management of best in class hardware offering.  Today this is a $5B market with a 30% CAGR far outpacing the datacenter industry growth rate.

2.      Cisco servers are driving over 50% of the Converged Infrastructure market with their UCS Integrated Infrastructure offerings with their Flexpod and VCE options

3.      Cisco designed the HANA appliance based on their very successful Converged Infrastructure designs predicting that the appliance model would give way to the TDI model as SAP HANA matures

4.      Cisco is able to offer end to end infrastructure support for HANA TDI because the design is based on a design architecture that is already supported. Competitors have to now commence building their TDI support from the ground up – Cisco’s unified support model is already in place.

Takeaways:

As SAP HANA technology and platform matures SAP is opening the platform build to more open hardware decisions. With SAP’s release of the TDI support this is proof positive that SAP HANA has now matured far beyond what BWA could manage in 7 years of its lifetime.

As the TDI build and support matures TDI providers will similarly open their support contracts to become more harmonized as a standard SAP HANA Support contract. Cisco has done exactly that with their unified SAP HANA support. Now, whether a customer chooses an Appliance or a TDI platform this support decision from Cisco removes the last barrier of risk that customers, auditors or supporters had prior to today

1.       First and foremost TDI is a sign of SAP HANA maturity where they are now comfortable with open ware components for a HANA build.

2.       In August 2014 we predicted that TDI was going to be the way forward as SAP HANA matures and become more stable. Today TDI has become a reality as more and more proactive customers are choosing TDI for HANA. To see the strategic logic ask the basic question: How many customers out there are running their traditional SAP applications on black-box type appliances?  Then why not?

3.       The TDI decision today represents a no greater, or less, risk than an appliance model. However it does guarantee best in class components or components that your datacenter is comfortable with. TDI provides more power to the customer and their Data Center/Basis stakeholders.

4.       TDI allows you to leverage your existing skills and assets to the maximum.

5.       TDI allows customers and data-centers to mix and match best-in-world-class components and not get stuck to a black-box, contractual lock-in, and sub-par components at a premier rate.

6.        TDI allows customers to get out of the choke-grasp of a single vendor monopoly and launches them on a path of open-ware selections based on world class providers.

7.       Today we can confidently state that SAP HANA Appliances are on their way out and TDI is on the way in- so plan your HANA Infra with the future in mind.

8.       SAP currently allows Virtualized Production SAP environments, and with SP 9 and promises of what SP 10 is going to bring the TDI dynamic models certainly seem to be the professional choice for cloud, data-centers and customers that have a trusted SAP basis support team.

 

Start thinking TDI and release yourself from any choke-hold that a HANA appliance may represent and plan to leverage the maturing SAP HANA platform ecosystem. Plan towards getting the highest quality at the lowest cost via professional selections based mainly on your current assets and existing partnerships - which represents your in-house knowledge and experience.

---

[1] BVA= Business Value Attainment

---

Does my Boss and HANA Project Pass the Grade

In August 2014 SAP reported that there were over 5,200 HANA Initiatives. By going at a standard 700 new customers per quarter we can fairly assume that number to be around 5,900 by January 2015.Or 6,000 by Feb 2015- now.

·       Like most projects there are the great projects and then there are the not-so-great projects.

·       Like most projects the technology is most often not to blame as it has worked successfully with a lot of the initiatives

·       Like most projects it is normally one or all the triad partners rushing to close the deal that creates a rush to start and end the project without adequate professional planning

·       Like most of the projects it is inadequate planning, business benefit roadmap and with HANA it is all about treating HANA as just another upgrade and/or migration

We have all thought about the SAP HANA new installations or migrations. We have thought about how it could have been done better, and in most cases either we have not raised our opinions or been asked to keep them to ourselves.

So it all boils down to methodology, standards and processes. All things owned by our bosses or their bosses.

The first part is will our bosses make the grade that they expect their subordinates to maintain? Do they practice what they preach in a SAP HANA initiative? Do they make the grade?

The second part is will our SAP HANA migration project make the grade that will pass the BVA (Business Value Attainment) test? Do we practice proven best practice methodologies, or simply chug along treating HANA as still another upgrade or db migration.

 

So score your own boss, your HANA project on a score of 100. The scale is 1-10, with 10 being the most positive score. Be as objective and empirical as can, fill the truth as only you know.  

2. DOES YOUR BOSS PASS THE GRADE

 URL for scoring your boss as a success criteria.  Enter email for feedback

Does your boss…:

1) Take ownership and accountability of their decisions

2) Fully understand the strategic and tactical impact of their decisions?

3) Provides an environment that makes you comfortable to express your hones feedback?

4) Builds a clear skill-map with each individual to maintain a healthy task allocation framework?

5) Exhibits good grace when someone makes a genuine mistake

6) Starts every initiative with a ‘Show me the business benefits’ approach

7) Behaves in ways that continues to build your respect for them

8) Has a high level of integrity and project knowledge to understand the strategic impact of every decision

9) Allocates tasks based on individual skills, strength and capabilities

10) Very balanced both when providing positive and/or negative feedback

Fill the form. Tally your scores. Reflect what the scores mean to you tactically and strategically. Perfection is something we desire but rarely something that is attained. So a score around 70 is good news.  If you become the boss these can be your roadmap items and then you can score yourself again.

2. DOES YOUR HANA PROJECT PASS THE GRADE

 URL for scoring your HANA Migration Project success criteria’s.  Enter email for feedback

 Does my SAP HANA Migration Project…:

1) Start with Optimizing the SAP Application for a 40% reduction in cost (TCO). Talk to partners that have reduced TCO by over 40%

2) Build global HANA Standards, processes, Architecture and modeling for the HANA Platform prior to commencing migration

3) Consider the data merge from Big-Data, IoT and SAP HANA as part of strategic planning.

4) Build a clear roadmap of alternatives, HANA Hot, Warm and Cold deployment plans

5) Select HW and SI partners based on a scientific process of Strategic and tactical attributes

6) Clearly understand that “what got you here will not get you there”. Here is defined by under 30% success according to Gartner 2012 BI report.

7) Plan for HANA as a strategic business solution and not just another technical upgrade or migration

8) HANA Migration TCO and ROI calculations have been undertaken based on scientific data

9) Understand that HANA costs can be decreased by over 40% with a little planning

10) Our HANA Project is designed, architected and planned with business stakeholders

Fill the form. Tally your scores. Reflect what the scores mean to your Project tactically and strategically. Perfection is something we desire and in SAPHANA project they can be attained. So a score around 70 is once again good news.  If you become the owner of a SAPHANA migration project these can be your roadmap check-items and then you can score yourself yet again

Be Brave, Take ownership and sleep well