Installing SAP applications is no picnic. Employees who are capable of deploying and maintaining SAP software are in high demand and practically form a whole profession by themselves.
SAP, which built its reputation with ERP software, is rarely chosen by enterprises for one-off applications, AMR Research analyst Jim Shepherd notes in a report this month titled “The five SAP strategies that you need to understand.”
“For huge organizations, this is typically a multiyear, multimillion-dollar effort to transform the business,” he writes.
Unfortunately, executives often pay little attention to SAP installations after they are deployed, he adds.
That’s a big mistake. Let’s take a look at the five SAP strategies Shepherd details in his report, and how they affect your technology decisions.
SAP’s growth strategy
SAP tries to increase revenue by licensing 75% or more of each customer’s employees, and by convincing ERP customers to sign up for an ever-expanding portfolio of business tools, such as Microsoft Office integration and Business Objects‘ set of reporting, business-intelligence and analytics applications.
“The strategy is to create capabilities that either encourage additional user seats within the existing products or require licensing brand-new products outside the Business Suite [software line],” Shepherd writes.
Customer challenge: SAP’s large customers generally expect to pay a lot of money upfront on licensing charges, and then a lesser amount in ongoing payments for additional licenses as needed and maintenance fees. SAP does want a lot of money upfront — but it also wants a lot of money later, and this creates “considerable debate and tension,” Shepherd writes.
Customers think new capabilities should be available for free as product enhancements, but SAP likes to position new capabilities as brand-new products, Shepherd adds.”Like most established software vendors, SAP derives most of its revenue from the installed base,” he writes. “Its object is to ensure that customers never stop buying licenses, maintenance and servers.
SAP’s platform strategy
SAP’s platform concept emerged in 2003, when it packaged a large number of technology components and renamed them the NetWeaver line. SAP built the platform to develop its product line for service-oriented-architecture (SOA) deployments, and it has been successful even though there doesn’t seem to be any huge increase in demand for a business-process platform.
Customer challenge: With the SAP platform, customers are expected to deploy standard SAP applications and use NetWeaver’s development tools and library of Web services to build new applications and modify existing ones to adapt to changing business processes.
“The reality is that SAP customers have to use NetWeaver because their applications won’t run without it, and over time, they tend to begin to use the optional components, such as business intelligence, the portal, and integration,” Shepherd writes.
SAP’s industry strategy
SAP has gained huge market share in such industries as oil and gas, chemicals, and life sciences, by tailoring products to their specific needs. Now SAP is focusing on increasing its market share in industries where it hasn’t gained a strong foothold.
Look for SAP to use acquisitions and partnership to target the customer requirements of industries where the vendor is looking to grow. These include non-manufacturing such sectors as retail, insurance, education, banking and government.
Customer challenge: If you’re in one of those industries that SAP already dominates, you may find that “enhancements requests have a somewhat lower priority than industries that SAP has designated as strategic,” Shepherd writes.
Long-time customers inevitably will complain they aren’t getting enough new features in exchange for their maintenance payments. This, however, could be a bonanza for non-manufacturing customers, who will have the negotiating leverage to convince SAP to fill holes in industry-specific applications.
SAP’s product strategy
SAP was basically a one-product company for most of its history, Shepherd writes. “First there was R/1, then R/2, and then R/3 (naming was so much easier then),” he notes.
Since 1999, however, SAP has branched out from its flagship ERP software to deliver dozens of products “with a bewildering set of options, variants, and names,” Shepherd writes. SAP now has four ERP product lines targeting companies based on size, and numerous non-ERP products for performance management, regulatory compliance and analytics.
Customer challenge: At large enterprises, CIOs must consider the long-term ramifications of an SAP deployment, which can take years for a global business. SAP’s current flagship product, the Business Suite (including ERP, CRM, product life-cycle management and other components), will offer a stable maintenance cycle until 2013.
“The SAP Business Suite looks stable until then, and [customers] like the idea of regular enhancement package releases rather than major upgrades,” Shepherd writes. “That said, they live in fear that after 2013 they may be faced with another product transition.”
The good news: Shepherd thinks the Business Suite will remain the SAP flagship until well after 2013, partly because some customers still haven’t upgraded from R/3, and SAP is facing no major competitive threats.
SAP’s product-release strategy
SAP historically has overhauled its ERP product line every five years. Customers used to face a difficult choice each time a new product was developed, but SAP finally is providing easier transitions, with enhancement packages being issued every six to 12 months at no extra cost.
“Instead of bundling five years of product enhancements and technology improvements into one massive upgrade, SAP has now moved to what it calls a continuous innovation strategy,” Shepherd writes.
Customer challenge: Before October 2005, when SAP started issuing more frequent upgrades, customers agonized over whether to install upgrades that were disruptive, expensive and time-consuming. Now customers can decide every six to 12 months whether an enhancement package is worth installing, while knowing another is on the way a year later.
These upgrades aren’t nearly as disruptive as those of the past, but they do require a new approach. User departments, rather than IT, often will make the decision about which new features should be activated.
“There will be some testing and training required, but nothing like the multi-month efforts associated with traditional upgrades,” Shepherd writes.
