Move, Adapt, or Die

Change is eternal in life, nature, business, and technology and you only have 3 options:  1) Adapt; 2) Move, or 3) Die.  I learned this truism in my 7th grade from my social studies class regarding animals response to ecological change, but the same is true for changes in our business environment.  The technology environment has forever been changed by CLOUD (IaaS, PaaS, and SaaS).  The software business and the systems integration (SI) will never be the same and is now presented with 3 simple options: 1) Adapt; 2) Move, or 3) Die.

As humans, especially business people, engineers, etc. who populate a lot of technology field, we believe we can overcome or stem the tide.  While this may work for short term or against small storms of change, it will not defeat real, substantial change any more than you can push back on walls of water from hurricanes.

IBM recognizes the power and importance of Cloud, even if it got off to slow start. Look at the emphasis. Less than 10% of IBM’s revenue is now from hardware. At the same time, everything from IBM is now on the cloud. IBM is even beating back its latest foe – Amazon Web Services (AWS). IBM Beats Amazon In 12-Month Cloud Revenue, $15.1 Billion To $14.5 Billion.

SAP has made a massive shift around SaaS and is adapting.  In 2013, Jon Reed, noted that even SAP executives would love to go on selling traditional on-premise perpetual licenses when he paraphrases the executive with ‘Hey, if we could continue to sell software to customers the way we’ve sold it to them for the last 40 years, we would. But they want new options.’  (more from Jon Reed’s Diginomica blog). Fast forward to 2016 and about 80% of SAP’s revenue is from 4 acquired SaaS products: SuccessFactors, Fieldglass, Concur, and Ariba. If SAP could figure out S/4 HANA cloud, they might even become a dominant SaaS ERP player.

Cloud and specifically SaaS to the software industry is a category 5 hurricane force of change driving a wall of water.  Remember when virtualization was only for non-proction. Now, most systems depend on virtualization.

Moving and adapting take time. So while almost everything will go cloud, it will take time. It will have to make IT and financial sense to move. The argument that some applications will not run well on the cloud will be a moot point when they are rewritten for the cloud.

The hurricane of cloud  in all forms is coming here. What are you doing to make sure your ready to move or adapt (and not die).

 

Production HANA on VMware – for the few, for now

Production HANA on VMware is in “controlled availability, allowing selected customers, depending on their scenarios and system sizes to go live with SAP HANA on VMware vSphere immediately” per SAP OSS Note: 1788665 – SAP HANA Support for VMware vSphere Environments.  However, the SAP marketing team left this small stipulation off the press release and got everyone very hot and bothered.

It sounds like everyone should be able to put their HANA system on VMware.  First, my wife, who is not in the IT world, sent me a link to the NY Times SAP and VMware Head for the Future Together and then I got about dozen copies of the Market Watch Report: SAP and VMware Announce SAP HANA® for Production Use on VMware vSphere 5.5.  Well, at least that mentioned you needed the latest version of VMware.

So for now, if you want to production HANA on VMware, the main requirements are below and included in SAP OSS Note: 1788665 – SAP HANA Support for VMware vSphere Environments.

  • Must be approved for controlled availability by SAP
  • Must be on VMware vSphere 5.5
  • Must be on SAP HANA SPS07
  • Maximum of 1 TB
  • Must be on SAP approved HANA server and storage
  • Must comply to SAP’s current recommendations for vCPU and RAM
  • Must not over-provsion the CPU nor RAM
  • Maximum of 1 Virtual Machine (VM)

In other words you need the latest and greatest version of VMware and HANA running on your HANA approved appliance in a nearly non-virtual manner.  While this is less than what we all want, it is a step in the right direction.  It will allow you to manage the HANA instance under your VMware management utilities.  It makes HANA part of your Software Defined Environmental strategy.  I’m confident that over time, as it becomes Generally Available, that production HANA will have far fewer restrictions.

I’m actually looking forward to when we can run production HANA on lots of virtualization schemes.  I look forward to more of software defined service level agreement (SLA) with SAP so that other virtualization environments including the cloud providers can provide production services. Right now it is about shipping hardware to Waldorf, DE for certification and is so specific, it is not practical even for hardware manufactures.

SAP needs to move to software defined SLA would be good for everyone including SAP by making HANA more available and take less effort to certify platforms, hardware and cloud providers who want the ability to vary the make-up of servers based on market conditions and newer evolutions of chipsets, and especially my clients who want HANA, but in but running in a completely virtual word they are defining, not the one SAP is trying to define for them.

As Vishal Sikka (former SAP CTO) exits, limited Production HANA on VMware is great first step for the product he called his child, HANA. Unlimited production HANA on VMware would be a great toddler-hood.  I really look forward to seeing it rapidly reach its teenage years and start trying to run on everything everywhere.  Isn’t that what teenagers do?

 

2-tier ERP: A cure for the smaller markets in a global implementation

Many companies over-engineer, over-build, and spend too much for ERP as they begin to implement smaller markets where the needs are relatively simple when they try to shoehorn them into the larger global ERP system.  Even after implementation, the smaller “units” often find it difficult to get their requirements met as they account for such a small percentage (%) of revenue.  One of the biggest hassles in SAP is security and separation of duty (SOD) which often requires smaller offices with just a few workers to have special profiles, multiple login’s, or some special process to fit into the bigger office process.  There needs to be a better way to meet the requirements of highly optimized larger markets with large work forces and smaller, simpler, and more fickle markets with smaller work forces.  A 2-tier ERP solution might be the cure.

Up to now, companies have spent billions on  ERP implementations resulting in significant results.  Specifically for SAP, many of the fortune 100 companies I work with credit some portion of their ability to keep up, survive, and some cases surpass their competitors to their SAP systems.  The most successful implement SAP using standardized processes, strong governance, and fewer, and fewer instances.  Companies with lots of instances often ask me what is the right number of instances.  It is the fewest number of instances which can meet your business requirements.  Not 1, 2, or any specific number, but the fewest.  Each company has to look at its own situation, goals, and markets; however, I believe implementing a cloud based ERP (SaaS) such as Business ByDesign (https://www54.sap.com/pc/tech/cloud/software/business-management-bydesign/overview/index.html) can make implementing or getting to “fewer” much more possible and ultimately better meet the requirements of all parties unilaterally.

In the examples below, the imaginary company has about 80 divisions, units, or countries (depends on how the company organizes and implements) it wants to implement.  A rough cut of revenue shows that 65% resides in top 10 and additional 25% in next group of 10 (11 – 20).  The last group of 60 only account for about 10% of revenue.  While this is fictional, it is a composite many of my experiences in the real world.  We often spend as much, or more, getting the last 60 units into core instance.

All in one ERP model
All in one ERP model

If we recognize that the goal of the fewer or even a global single instance is not simply being on one system, but to have consistent, audit-able processes globally, a new option opens up using a 2-tier ERP model.  Bottom line is in many of these smaller units, often countries, the objective is really to make sure the financial results are valid and that ultimately the CFO can count on them when he reports out to Wall Street.  Getting everything into single SAP system was the best way, and in some scenarios still may be the best way, but it might pay to look at a SaaS based ERP solution as shown below.

Two Tier (2-tier) ERP model
Two Tier (2-tier) ERP model

Often I’m asked, why not just take one of our ERP systems and make it the “light” ERP system and we can even place it on the cloud (IaaS/PaaS).  It does work, but it misses many of the advantages of moving to SaaS.  It is a good option if those other units require lots of optimization.  In contrast the SaaS option will provide a more generic solution focused at smaller organizations with shorter implementation periods, mobile enabled GUI, and pricing by user which may match the more volatile small unit markets where staffing may quickly shift up or down.  Finally, if you are already on SAP ERP, there are significant integration between SAP ERP and Busines ByDesign pre-built with new ones being rolled out in future versions.

I will continue to encourage clients to move to the fewest number of instances which can meet their business requirements.  Adding a SaaS based ERP system such as Business ByDesign could make that journey even simpler and faster.

SAP SaaS marches on

SAP is laying out a strong SaaS program and has keen view of the future.  They’ve organized themselves into upper domain areas of: People, Money, Customers, Suppliers, and Special.  They then have their horizontal glue layers of Social and Integration.  Finally, they have supporting layer of SaaS ERP in 2 flavors: Business-By-Design and Business One.  This clearly laid out in the illustration below.

Image

Most of the SaaS attention has gone to People with SAP’s acquisition of SuccessFactors.  Indeed, success factors is leading the SaaS charge at SAP both in terms of ideation and management with Lars Dalgaard heading the cloud unit.  SuccessFactors brings a SaaS pedigree to SAP.

All “legacy” or pre-SaaS software vendors including those like IBM, Oracle, Computer Associates, etc. all face the same challenge.  How to use a usage base metric to drive revenue and determine re-investment.  In addition, legacy vendors often haven’t built in cloud capabilities and multi-tenancy which is the key scaling and upgrades leading to lower costs.  I think you’ll see legacy software vendors buy some of the skills.  I also think as the whole market shifts to cloud, SaaS will simply become the pervasive model and vendors will adapt.

Tersely put, how do you change your revenue stream?

  • Old Revenue Formula  = Licenses + Support
  • New Revenue Formula  = Utilization metric (i.e. per user, per month, per incident, etc.)

Honestly, I think the non-cloud and even non-SaaS type application will become the exception.  So like all creatures faced with drastic environmental changes, software vendors have 3 choices:

  1. Move (find business that can’t use cloud or won’t adopt as fast)
  2. Die (easy, just don’t change)
  3. Adapt (move to more efficient modes such as re-architecting for SaaS)

One of SAP’s other big SaaS applications is Ariba.  In addition to being a substantial procurement software product with huge numbers of consumers and suppliers in their network, they are the model of moving to cloud and SaaS to survive.  They have already made the adaption.  If SAP is smart, they will take the lessons learned from the trial by fire of Ariba and apply it to their own journey. 

I think the movement to cloud, and mostly to SaaS, is one that all vendors will need to follow to remain viable.  Keep in mind there are companies today that will join the Fortune 500 in the next 5 years and will have never purchased an enterprise class server or purchased enterprise software.  As an industry, How are we going to provide value add services?  How are we going to morph our products to meet their non-procurement cycles?  Are we going to be part of the company that: 1) Moves, 2) Dies, or 3) Adapts. 

Next blog, I’ll talk more about the lower layers of Social, Integration, the two ERP SaaS options which will yield a new way to do roll-outs via 2-tier ERP.