Why Organizations need a SAP HANA & Big Data Strategy

It is important to realize that most customers are taking the SAP HANA leap for one of two, or both, maturity reasons. The first is to increase the performance of existing analytics and reports and to be able to view more decision relevant information in Real-time.  The second, normally after the first is realized, is to find the diamonds in big data consisting of streaming, networked device and customer emotion data- the true big-data endeavors from outside your enterprise firewall. It is most critical to remember this as strategic planning mandate for optimization for the future where the Internet of Everything is today a reality providing solid competitive differentiation.

While most IT units are anxious to deploy big-data and SAP HANA one of the most pressing questions business stakeholders are asking worldwide is ‘show me the business benefits’ and ‘how are we going to assure we meet business expectations’. More than one enterprise is in a dilemma as to how to answer this very question. We have been encouraging business stakeholders to ask this very question and have developed global methodologies to meet these very objectives in a scientific and planned methodology. The roadmap to both above questions is only about understanding, defining, developing, documenting and communicating a global SAP HANA strategy that is led by a documented global methodology.

So what is a global SAP HANA Strategy? It is a part of the global Business Decision enablement Methodology with rules and regulations for all developments therein.

·       SAP HANA is a business solution. It is not simply another technical upgrade or installation.

·       The SAP HANA methodology has to be built from the ground up for this new platform to leverage its capabilities. It is not simply taking your old partners, resources and methodologies into the new platform.

·       The SAP HANA methodology mandates optimization prior to installation and/or migration. It is not simply taking your current SAP-BW, ERP, CRM or SCM and migrating it to HANA ‘As-Is’

·       The SAP HANA methodology starts with global standards, processes, data architecture with clean guidelines. It is not making broad-stroke statements like ‘Data is an enterprise asset’ or ‘IT will deliver reports based on their experience’

·       Strategy is all about ‘meeting business expectations’ and ‘enhancing business benefits’. It is not about producing a technocratic laundry list of technology installations and when they will be deployed.

·       Strategy is a clear roadmap of aligning tactical deliverables aligned to technology owner and business goals in the coming years. It is not laundry list of technical trends that might somehow influence decisions in the future without any need for business inputs.

·       Strategy is a decision with business stakeholder inclusion and benefit case acceptance. It includes business participation at every step for it to be successful. It is not just a triad-vendor vision, shoved to the enterprise with protocol top-down instructions, or led by IT technical goals that still do not comprehend the capabilities or limitations of the technology, with little or no business inclusion in the whole decision process.

So with the above let us define what your SAP HANA Enterprise Strategy really should look like:

Your SAP HANA Enterprise Strategy is the comprehensive business value-chain vision aligned to an actionable technology roadmap for an organization to align all technical developments towards a global strategic vision of enhanced decision capabilities.  It fall under the umbrella of Master Data Management, Business Intelligence, Big Data, data governance and so forth.

Thus a SAP HANA Enterprise Strategy is:

·       Documented, accessible and communicated.

·       Pre-qualification read for all developments across the enterprise

·       Becomes the backbone for Governance.

·       It must be actionable, relevant (e.g. contextual to the organization, not generic), dynamic (e.g. it is expected to change/evolve on a regular basis; communicated / Integrated - with everything that comes after it or from it)

Once we agree what an enterprise SAP HANA Strategy is we need to discuss why it is critical to have one. .Here are some the main reasons: - 

1.    A global methodology ensures that no matter where development is undertaken it conforms to a global methodology of architecture, design, definition and change management. Without a global / centralized methodology each part, region- application or developer, will traverse on a subjective path of what they perceive to be their truth. This inevitably leads to redundancies, duplicates and dead objects. It also leads to multiple versions of truth in the same application and much worse globally. Most importantly it slows SLA’s and drives up costs.

2.    A global methodology ensures the enterprise goal of ‘One version of truth’ is achieved. . Without a global methodology each developer can create newKPI’s, change KPI’s and create data flows at will without any form of checks and balances.  

3.    A global methodology clearly defines the hand-off points from business to IT with clear start and end points for every delivery. Without a centralized methodology business and IT get themselves into independent silos, with each blaming the other for lack of adequate information.

4.    A global methodology clearly defines global, regional and individual metrics and KPI’s. Without a centralized methodology there can be no global ownership of metrics and KPI’s and thus no single version of truth.

5.    A global methodology clearly defines periodic checks and balances, optimization audits and guidelines. Without a centralized methodology databases can go out of control, DW instances can get filled with redundant and dead objects all making SLA’s impossible to maintain.  

Sample components for a SAP HANA Strategy

So a typical SAP HANA Strategy should include:

·       Full documentation for the new SAP HANA platform. It must not solely rely on the old standards and processes. Gartner said it quite perfectly ‘What got us here will not get you there’

·       A full inventory of source systems, types of application and database servers, along with ownership and accountabilities. You can never model a data pipeline until you fully comprehend the underlying datasets and their relationship to your enterprise

·       A documented global methodology of critical areas for governance. How can governance teams govern without a documented methodology or rules and regulations?

·       Global definitions of corporate, global, regional and SBU level metrics and KPI’s. There is no way towards a ‘single version of truth’ without clear definitions of individual metrics and KPI’s. 

·       Global organization structure with Center of Excellence ownership. Clear definitions of data ownership and change management. Without clear ownership and accountabilities one can very easily drive straight into a world of unplanned, and subjective, spaghetti data architecture.

·       Global guidelines of reports, analytics and informatics architecture roll-up with self-correcting and audit processes built into the design and architecture. Without a global FEDW guidelines one can run into layers of data quality governance and information quality audits that can become a daily nightmare.

·       Global standards for enterprise value-chain IoT and IoE devices, data management, flows and security enablement. Dive into Big Data and HANA without strategic IoT and IoE considerations and you are short selling your strategic capabilities and the potential of your assets.

·       Global standards for sub-strategies for ERP,MDM, CRM,SCM, Single database platforms with clear instructions as to how the methodology fits into the future states contemplated.

·       Dynamic global Risk Register and Key Decision process documentation.

With this in place we are now ready for the three critical roles for strategic HANA success. Roles 1& 2 can be combined with the right resource, role 3 must be a direct employee of the customer

1.    Enterprise SAP HANA Solution Architect

2.    Enterprise SAP HANA Business Value Architect

3.    Enterprise SPA HANA Business Value Owner

The SAP Solution Architect are typically strong technical resources. They are experienced specialists in SAP application platforms from an architecture and technical solution point of view. Solution architects make excellent candidates for strategic designs and solutions they help companies define enterprise data and BI strategies. They must be charged with defining short-term, mid-term and long-term technical objectives from a system capabilities and optimization point of view. Solution architects have a good deal of experience designing global Infrastructure and working with an IT perspective of optimal utilization of resource distribution.

The SAP Business Value Architect are typically strong technical resources but with a stronger business benefit focus. They typically come from a strong business background and have adequate experience leading SAP projects from a customer point of view. Business Value Architects have just one deliverable –to ensure that all the project designs, plans, resourcing and development with deliver business value/ benefit. Their sole measure of success is ‘Meet Business Expectations’. They must be charged as the trusted, right hand advisor for project owners. Business Value architects must have a proven track record of consistently delivering projects with high user satisfaction scores.

The Business Value Owner is typically a customer employees only. They must not be representative of a person available at that point of time but a careful selection of a super user and a business user.  They typically come from a hands-on business background and understand the enterprise needs and expectations.  Business Value Owners have just one deliverable –to ensure that all the project designs, plans, resourcing and development deliver business value/ benefit. Their sole measure of success is ‘Meet Business Expectations’. They work as the internal business value expert in conjunction with the Business Value architect. While the Business Value architect is more technology and business facing, the Business Value owner is mostly internal facing with protocol access to business stakeholders and enterprise business users.  They must be charged as the trusted, right hand advisor for project owners with as a team for Business Value deliverables.. Business Value Owners must have a proven track record of consistently understanding internal business needs and situations along with org structures and key decision stakeholders.