Historical Perspectives from mySAPcareers

A Look Back with B2B Workforce's Brian Trout

 

mySAP EBP - Strategies for Global Implementation
by Brian Trout
June 2002

One of the truly worthwhile realizations to come out of the dotcom frenzy is that the Internet provides companies with a unique opportunity to redefine how they will collaborate with their customers, suppliers, and even their employees. As we all know, this trend has produced a large number of B2B/B2C software applications aimed at helping companies to expand their market share and optimize processes while reducing costs. Just two short years ago, enterprise software giants like SAP looked out of step with this emerging B2B/B2C market. Suddenly, they found themselves pushing back office ERP solutions in a market that had changed its focus to the front office and the Internet.

Of course, the irony of the economic downturn is that it bought SAP some much-needed time to roll out a truly competitive e-business solution. After weathering some past criticism for its lack of Internet vision, SAP has emerged from its shell with a clear direction for mySAP.com. The new mySAP product line features a host of e-business applications, including Enterprise Buyer Professional (EBP). Like most of the competitive e-procurement solutions in the market, EBP offers support for purchase-to-pay Processes, as well as electronic tendering for auctions, reverse auctions, web marketplace integration and the like. EBP version 2.0 is quite an improvement over EBP 1.0 and earlier BBP/Commerce One offerings - not to mention the cumbersome R/3 MM environment.

However, all this new functionality presents new questions for SAP customers. In response, we'd like to offer some insights from an EBP Global Project Manager for a U.S Fortune 50 Manufacturing organization. This EBP manager has spent the last two years leading the effort to design and develop an EBP rollout solution to support 7,000 projected users in over a dozen countries. At present, this organization has the EBP internal catalog running, and is in the process of adding new users, suppliers, and functionality on a monthly basis. There are about 2000 users now with 5000 more anticipated in the next year. The short-term goal is to have EBP handle all standard purchasing transactions for the company worldwide by the end of the year - a total purchasing volume in excess of $3 Billion dollars annually.

When we asked this project lead what advice he might have for companies embarking on EBP projects, he stressed that the primary factor in their success with EBP has centered around a phased approach to introducing functionality. Early on, the organization determined that they would set up a simple, Internet-based version of their current indirect purchasing processes, thereby allowing them to place primary emphasis on ensuring standardization of catalog information from suppliers. (Although our contact pointed out that imposing OCI standards on suppliers for the catalog presentation of their products and services has remained a challenge, as has the intensive maintenance of the catalog.)

By leaving electronic tendering and direct procurement integration with APO out of the initial scope, this organization has been able to focus on standardizing an e-procurement culture worldwide. This is good advice for future EBP implementers to remember as they wrestle with the temptation to go "Big Bang" and leverage the power of open market dynamic pricing.

Surprisingly, we have yet to see an industry-wide trend towards the purchase and implementation of EBP systems - despite the fact that sources indicate the per seat cost of an EBP license is about one tenth that of a typical SAP user license. In addition, through its new web-based interface, EBP appears to be much easier to use than in previous versions. It's also efficient enough to automate a much wider array of indirect materials. So why has EBP growth stalled? According to the customers we surveyed, contributing factors include: the lack of available, standardized marketplaces, the workload of maintaining internal catalogs, the lack of proven technology to truly integrate direct materials, and lack of a quantifiable ROI.

From a staffing perspective, proven EBP functional and technical expertise is in fairly short supply, but recently quite accessible.  Direct customers can secure functional expertise in the $150 per hour range, with technical Basis support coming in at around $135 per hour on average.  The EBP independent consultants we are in touch with say demand for their skills peaked at the end of the first quarter and has been steadily dropping off since.  This may be bad news for the EBP consultants out there, but it's good news for those in search of EBP support. 

We will keep an eye on the developments in the EBP market. Look for more information in future additions of mySAP Market Watch.

 

mySAP APO - Real-Time Data Integration with CIF (Core Interface)
by Brian Trout
July 2002

The backbone of mySAP's Supply Chain Management (SCM) solution is the Advanced Planning & Optimization (APO) module. First introduced in the late 1990s, APO has evolved from its humble beginnings to the current 3.0 market release, (soon to be 3.1). APO 3.1 offers a host of collaborative planning functionality, including Demand Planning (DP), Supply Network Planning (SNP), Production Planning/Detailed Scheduling (PP/DS), Global Available to Promise (GATP) and Transportation Planning/Vehicle Scheduling (TP/VS). However, with this expanded functionality also comes added data integration complexity, and as with any other planning tool, APO's planning capabilities are only as effective as the source data it is provided with.

APO's solution for addressing real-time data integration is the Core Interface (CIF) R/3 Plug-In. The CIF provides a development environment complete with an Integration Model for mapping, a series of RFC definitions, a number of customer exits for enhancements and system monitoring, and analysis tools to support data transfer. In addition to the CIF, APO leverages integration with SAP BW through the use of extended infocubes for its DP function.

Sounds good on paper. However, what we have observed from many clients is that the CIF is quite "buggy," sometimes dropping data in transfer or rejecting data from RFC ques (qRFC).These problems are troubling for a number of reasons, most importantly that unprocessed qRFC information creates a bottleneck for subsequent data transfer and is not automatically deleted within the CIF. Or perhaps worse, critical pieces of data dropped in transfer can create scenarios where APO is operating with outdated or incorrect information, producing unreliable planning data.

In SAP's defense, they are working closely with customers to create patches to address these bugs. And it should also be noted that CIF errors can also be caused by a range of other factors, including issues with the network or source system failures. The APO customers we've spoken with advise others looking at APO to spend the time upfront to develop a clear list of specific functions they want from APO and to understand the fundamental differences between implementing execution and planning systems. This upfront work provides a more finite approach to working with the CIF Integration Model.

From a staffing perspective, we have observed a recent spike in demand for APO technical development resources. At present, most customers seeking an "expert" in the CIF development environment can expect to see resources with three to five years of ABAP experience along with six months to a year of APO-CIF background. Below this, there are a number of solid technical resources that have APO exposure, but more than likely only from a data load perspective. In terms of rates, from the smaller boutique firms, customers can expect to see rates in the $135 - 165 an hour range for APO-CIF experts, with APO data load resources available in the $100 - 125 per hour range.

We will continue to monitor the progress of the Core Interface and will have several more features on other areas of APO in the future.

 

Web Application Server - Poised to Redefine SAP Again
by Brian Trout
August 2002

Unquestionably, SAP's post Y2K mission has been to transform its image from an ERP software giant into an industry-focused, leading edge, eBusiness software company. In order to achieve this transformation, SAP has introduced the now familiar line of software products called mySAP. The mySAP product line represents a series of self-contained applications to support front office sales, supply chain, financial, and human resource systems, along with a host of business intelligence tools. Undoubtedly less familiar, but arguably just as important, has been SAP's introduction of the Web Application Server. The Web Application Server (or WAS) is an open systems, standards-based web architecture. As such, the WAS marks a major technical shift, as SAP continues to evolve from proprietary technical architecture and tools (Basis, ABAP), to a more "open" architecture ideal for collaborative eBusiness (Java, XML, J2EE, etc.).

Web Application Server represents the backbone on which SAP will ultimately launch a whole series of industry-specific web services and vertical industry content - all through a user-specific portal interface. The WAS maintains a powerful integration engine, a web-friendly development and runtime environment, and a set of landscape and administration tools that are designed to promote data integration and delivery for both R/3 and future non-R/3 customers. Sounds like an ideal infrastructure on which to build information portal solutions, and one we believe will afford SAP an opportunity to offer solutions to a whole host of non-R/3 customers in the future.

The Web Application Server concept was first introduced in 2001 with its initial 6.1 version. At the time, the release of WAS signified SAP's change in direction from a Microsoft-based NT environment with Internet Transaction Server (ITS) to a more robust Unix/Java based architecture with WAS. WAS (6.10) offered SAP users a true web browser interface known as Workplace. Workplace gave SAP users more open and focused access to information within the R/3 domain. 6.1 also offered developers an environment to publish ABAP programs on the Web via HTML. In addition, Web Application Server 6.10's adherence to standards like HTTP(S), XML, SMTP, and SOAP were revolutionary for an SAP product. (Although the SMTP and SOAP integration was not complete until 6.20).

However, it is SAP's newest version of Web Application Server 6.20 (available Q3 02') that is poised to redefine and likely extend SAP's market position. WAS 6.20 has expanded on the features of its predecessor in 3 main areas:

  • 1. It acts as a robust unification server supporting all mySAP.com, J2EE, and MS .NET applications. In addition, 6.2 now provides developers with the ability to host J2EE and ABAP applications on the same server with Java, XML, and SOAP output vs. static HTML.
  • 2. It provides a host of Business Process Connectors, comprised of SAP's IS solutions for industries such as A&D, Utilities, Public Sector, Telecomm, Consumer Goods, Retail, etc.
  • 3. It provides true extraprise connectivity, including full support for Web Services.
  • 4. Together with SAP Portals, WAS 6.2 forms the basis for the true conversion of SAP's offerings into "componentized" modules, with the realization that not all businesses require the full spectrum of SAP R/3 Financials or mySAP solution offerings. This will be most helpful in SAP's drive into the Small/Medium (SMD) field, whose requirements are not as stringent as a Fortune 1000 customer.

So what does all of this mean in today's environment for current SAP customers? Where does it leave R/3 customers looking at both mySAP and broader eBusiness initiatives?

In short, Web Application Server is not currently a requirement to run mySAP solutions. Many clients are effectively implementing mySAP components on top of 4.6C and below. However, when it comes to web-enabling standard R/3 information, such as Financials, you must be running on 4.6C with the 4.6D kernel in place, or, alternatively, running on the 6.2 Web Application Server. If you choose Web Application Server, our sources all tell us that 6.2 is very reliable, but there are still some browser output problems with certain mySAP components like APO.

If you do pursue the option of implementing the Web Application Server, your technical staffing needs will be a little different than the typical SAP Basis consultant who installed your R/3 system. Architecture specialists with specific WAS experience are very difficult to locate. Be prepared to allocate a fair amount of budget dollars for these resources, as experienced WAS architects will likely run in the $175+/hr range. The good news is that many of the new technical skills required, such as Java, XML, and J2EE/.NET experience, are often already present on the "in-house" IT staff who are rolling off e-commerce projects or other web-based initiatives. And some seasoned SAP consultants have also added these skills to their toolkit and can bring knowledge of both R/3 and web-based architectures to the table for things such as BAPI and ABAP Object customization for BSP (Business Server Pages).

Web Application Server 6.2 is the first product from SAP that can truly operate completely independently of other SAP applications. Its open integration framework allows customers to build specific information portal solutions (we will cover these in more detail next month), comprised of source data from a whole host of applications including Peoplesoft, Oracle, Legacy, or any other third party. That's quite a change from SAP products that played nice with R/3 but offered only limited integration support, if any, for other systems!

 

mySAP Enterprise Portals: Your User-Empowered Future
by Brian Trout
September 2002

Since the end of the ERP implementation craze of the late 90's, SAP has been on a quest to redefine itself as a market leader in eBusiness Software applications. By now, that it is certainly no secret. But throughout all the hype and confusion surrounding mySAP - including the introduction, merger, and reacquisition of SAP Markets and SAP Portals - a consistent vision has been maintained: Make SAP easier to use and more accessible to users. (I recall Hasso Plattner introducing this vision along with the initial mySAP components at SAPPHIRE 98' in Los Angeles).

Has SAP succeeded? Many would say no. However, I believe that is destined to change. SAP's latest Enterprise Portal Solution, EP 5.0, is poised to legitimize SAP as the market leader in Enterprise eBusiness Software. Leveraging the centralized Web Application Server architecture, EP 5.0 offers a combined Portal, Knowledge Management, and Business Intelligence platform capable of supporting customer, supplier, partner, and employee-specific portal solutions. In this article, we will focus on employee portals and what these solutions mean for the future. (Next month will we focus our attention on Business Intelligence and the maturity of the BW application behind it).

Employee-specific portals allow users to have a filtered view of enterprise data specific to their job roles, leading to increased efficiency and a more enjoyable user experience regardless of the employee's job role, location, or technical platform. Employee-based portal solutions have been available from SAP through earlier releases, known as SAP Workplace 1.0 - 2.11. EP 5.0 builds on the Workplace concept but no longer relies on the ITS/Mini Apps for its Portal and Business Intelligence content. Rather, EP 5.0 relies on the Java-based iViews and Unification technology to incorporate data from other non-R/3 applications such as Siebel, Peoplesoft, BAAN and Oracle. This is a dramatic application shift to open systems, and a clear sign that SAP is committed to a broad strategy of challenging Microsoft's monopoly on the corporate user desktop.

With EP 5.0, employees are able to customize their desktop through a combination of industry and role-specific business packages. These packages offer a predefined set of business content and iViews from various sources located in the iViewStudio Marketplace. Never before has this level of output customization been available to users, who can now even choose what colors and sounds they will see on their desktop. This is a far cry from the one-size-fits-all ERP days!

However, before you rush into launching a Portals initiative, the implementers we have talked to advise everyone to be prepared for the cost. According to our sources, costs for EP 5.0 are broken down into two portal segments: Enterprise Consolidation Portal (ECP) and Enterprise Unification Portal (EUP). ECP is intended to provide interactive portal access to R/3-specific applications only and currently runs about $300-350 per user. The EUP functionality, which offers full non-SAP to non-SAP system interaction, can cost a whopping $600 per seat! This is considerably more expensive than competitive solutions from Microsoft .Net and Plumtree. Of course, we do understand that these costs are negotiable, and are based on the number of seats you are considering and what other applications you may have already purchased from SAP. SAP justifies these costs by pointing out that on the ECP side, their standard Worksets and overall Business Packages our built with unmatched best practices models and out-of-the-box R/3 integration.

In terms of Portal implementations, our sources tell us that R/3 customers can activate standard roles and business content in as little as forty-eight hours. However, you should anticipate as much as sixty to ninety days for the customization of user profiles using the 1,000+ standard iViews available within the iViewStudio. With respect to staffing, customers looking to rollout EP 5.0 either as a new implementation or as an upgrade to Workplace 2.11, can expect to pay in the $135 -165 per hour range for an experienced Portal Solution engineer with at least a year of experience. At least two weeks should be allowed to identify a suitable candidate.

At mySAPCareers, we have committed ourselves to expanding our Portals resource capabilities in response to what we anticipate will be an spike in market demand for these types of solutions in the next twelve to eighteen months. We believe a combination of factors, both inside and outside SAP, will promote this trend, including:

  • The significant increases in ease of use and accessibility and long-term lowered cost of ownership afforded through the use of a Portal solution;
  • The rapid advancement and promotion of Internet security and XML standards such as SOAP and WSDL, in conjunction with emerging standards for Web Services; and
  • Anticipated cost-reduction incentives by SAP to promote the use of Portals, in combination with continued advancements in the Web Application Server Architecture and related Business Packages.

mySAPMarket Watch will keep you up to date on specific implementation and staffing trends surrounding this growing segment of SAP implementations.

 

SAP BW - An Emerging Player in Enterprise Data Warehouse Apps
An Interview with BW Expert Rick Sherman
by Brian Trout
October 2002

Since its introduction in the late 1990s, SAP Business Information Warehouse (BW) has slowly evolved from a basic reporting tool with limited business content into a robust, highly-scalable data warehouse application that stretches far beyond the confines of its original R/3 foundation. Today, the 3.0/3.1 releases of BW are a vital component of the entire mySAP application suite, encompassing CRM, SCM, ERM, SRM, and eBusiness Portal applications. There is no denying BW has matured, yet like many other professionals involved with SAP, I wanted to know what is fundamentally different about the 3.0 BW architecture fueling mySAP.

In order to gain some true insights into the evolution of BW, I am pleased to bring you and interview we conducted recently with Certified SAP BW and Data Warehouse expert Rick Sherman. Rick has been in the IT field for over seventeen years, with deep experience architecting and implementing Data Warehouse solutions from Oracle, Sybase, Cognos, and, for the last 3 + years, SAP BW. Most recently, he has been acting as a lead BW Architect and sub-project manager (BW Area) for the implementation of the SAP CRM/SEM/BW for SAP AG and SAP America.

Brian Trout: Rick, thank you for giving us the opportunity to discuss SAP's BW product with you. Can you give our readers a sense of how you think the BW 3.0/3.1 product compares with traditional industry leaders such as Oracle and Cognos?

Rick Sherman: Sure. One of the original strengths of BW has been to provide a comprehensive platform for data warehousing, which included metadata management, analysis tools, warehouse management and data transformation methods in a single scalable, securable environment. In the beginning, this made sense primarily to existing R/3 customers and was somewhat limited in scope. However, even in the early stages, BW was starting to show some advantages over traditional methods.

Trout: Rick, it's interesting to hear that even the 1.x version of BW, which was so highly criticized and not widely accepted, offered some technical advantages. Can you elaborate further on the traditional data storage and warehousing methods?

Sherman: Generally, the traditional methods centered around two areas: extracting the data from the R/3 environment into a separate data warehouse environment, often with the Oracle environment as a target. This approach could be taken with or without ETL tools like Acta to aid in the extraction. The second approach involved operating on the data in place, using external analytical point tools like Cognos and Business Objects. One of the major problems with these approaches has been in the metadata management, which resulted from release changes in the R/3 environment. Each external tool or environment has had to reflect these changes. Another has been in the actual transportation and coordination of the R/3 data in an efficient manner to an external DW environment. To a lesser degree, this is also true with the point tool approach, which often required extraction and transformation into a proprietary format such as Cognos cubes, or the conversion of data via OLE DB. In the end, a lot of data shuffling and restructuring takes place. Timing issues become critical as you look at the movement away from the traditional "nightly batch load" to the current trend towards "active" data warehouses, which are expected to have global availability and near-real time reflections of data changes.

Trout: How has BW evolved to address near real-time data access?

Sherman: What we are seeing with the BW 3.x series is the evolution of BW from a tool into a true enterprise-capable DW platform. One of the major improvements in the 3.x series has been the connectivity to outside, non-R/3 environments. Whereas before, we generally only recommended BW when a customer had a high concentration of "systems of record" within R/3, somewhere around 60%-70%. I now see BW making sense where only one or two primary systems of record are R/3, because of the improved connectivity.

Trout: You mention that the 3.x series provides better connectivity to non -R/3 systems. But what enhancements have been made to increase the productivity and capabilities of SAP's mySAP applications such as APO, CRM, SEM and so on? "

Sherman: Actually, one of the biggest beneficiaries of the 3.x release are the mySAP applications. The customer is demanding more and more in the way of pre-configured analytical applications, and these are delivered in BW 3.x. Actually, to be fair, some of this existed in BW 2.1C as of patch level 9 or higher, but these areas have received major enhancements and exposure in 3.x. There have also been enhancements made to the corresponding business content. These analytical applications are delivered with BW, and cover areas such as sales, marketing, service, and supply chain analytics. For example, in support of CRM, analytical applications for things like customer life time value, frequency monitoring, and the Data Mining Work Bench are provided. These allow the customer to use delivered or self-developed models to perform sophisticated behavioral analysis using methods such as clustering, decision trees, scoring and association analysis.

Trout: I see. Are there any other areas where mySAP applications have been enhanced in 3.x?

Sherman: Yes. Another area that helps the mySAP products is in the move towards an active data warehouse, where the data is available in near real-time. One of the changes in BW 3.x has been the implementation of a transactional ODS. These mechanisms enhance the trend started in BW 2.x, where the CRM Planner and SEM used BW as a real-time data container for the creation of measures (key figures) and manually entered amounts and quantities for the measures. Now with BW 3.x, SEM and CRM can utilize a direct write/update to an ODS, with direct feedback in any associated reporting or marketing target group creation. The new process chain capabilities provide a much-improved level of control in the loading process, and also contribute to making near real-time data more feasible.

Trout: Rick, you mention major enhancements in business content and data integration, but what about making the information more accessible? Many of the customers we talk with have a common vision of distributing analytical as well as transactional information to SAP users via Portal solutions. What major enhancements does 3.x provide for this type of solution?

Sherman: The Enterprise Portal now provides a reasonably tight integration with BW, which allows the inclusion of many data sources into a role-relevant, functional analytical dashboard. One example of how BW 3.x enhances this area is the overall movement in BW to web-based delivery as the primary information delivery vehicle, for example the direct publishing of BW queries as portal iViews. Other examples of enhanced BW-Portal integration include the independent web application developer, the significant enhancement of the alert mechanisms and pre-calculated results sets, and even seemingly simple things like the ability of the Report-to-Report Interface to generate parameterized URLs, which can be extremely useful in tying together disparate web reports.

Trout: It sounds like with web-based delivery and increased analytical capabilities, with BW 3.x, the stage is being set for a new generation of user-specific information tools.

Sherman: Well Brian, let me go back to something I just mentioned as an enhancement to BW 3.x: the alert mechanisms and pre-calculated results sets. As a response to the volumes of information that information systems now provide, customers are now requesting just information relevant to their roles. Role-based information delivery has been one response to this need. But more and more, customers are saying: "I do not want to have to ask the questions all the time, I just want to know when things are going wrong," or on a more positive note, "...when things are going really well." Sort of a "management-by-exception" approach. With reduced staffs and increased penalties for not paying attention to the business operations, you can see how this might have come about. Companies such as Siebel and SAP are responding by developing analytical "dashboards" which combine not only relevant, role-specific information, but also provide "relevant event notification" based on that information.

Trout: What benefits will users gain from these alert notifications?

Sherman: In the future, I see the question being answered like this: "Brian, based on your role, here is what is very right or wrong in your business, here are the relevant details to help explain the situation, and here are the suggested action steps." Though this process, the BW application will become a trusted adviser in helping to run the business. Now that may be a bit in the future, but BW 3.x already has many of these capabilities. The enhanced alerts now have advanced customization capabilities and delivery channels, combined with pre-calculated results sets and RRI. A parameterized query can be executed either in or outside of BW to pull together all the details, and with BW 3.x, the associated documents can be attached to master data to deliver an attached set of action steps. Although it might be a little awkward now, I think the trend is very interesting.

Trout: I agree. It is amazing to think that at some point BW may evolve into an infrastructure capable of not only providing whatever information may be necessary to the user, but also the relevant answers to problems as the arise. But what can we expect as BW evolves in the short term?

Sherman: The whole trend for SAP seems to be directed towards a pro-active, web-centric, event-driven, real-time application model. From a near-term perspective, I would imagine we will see a continued integration between mySAP products and BW, and an increase in connectivity with BW for things like large volume XML connectivity. I think we'll also see an increase in the pre-delivered non-SAP business content (Oracle Financials is in 3.x) and vertical industry richness. I also expect to see an increase in interactivity, pro-activity and functionality in the BW/Portal analytical applications, and additional incremental, near real-time capabilities for both data loading, re-alignment and reporting.

Trout: Rick, thanks for your time. I think our readers will enjoy hearing your perspective.

This concludes our interview with Rick Sherman. I hope you enjoyed Rick's overview of the 3.x BW platform. We look forward to bringing you more analysis of BW in future editions of mySAP MarketWatch.

 

SAP CRM - An Overview of the Current Market, Part One
by Brian Trout
November 2002

Since the announcement of SAP's initial CRM 1.0 product offering a few years ago, interest in SAP CRM amongst global customers has steadily risen. However, even as SAP's CRM product capabilities have grown, some SAP customers have chosen not to wait on SAP, and have elected to implement best-of-breed offerings from CRM software makers such as Siebel, Clarify, and Kana instead. But despite these defections, the clear consensus of SAP customers on CRM has been "wait and see." Are they waiting on SAP? Perhaps. Or are they just waiting in general? The lack of investment in SAP CRM can be attributed to a number of factors, including a perception that the organization is not ready for mySAP, the IT spending cutback and current economic conditions, SAP's perceived lack of CRM market credibility, and a decreasing level of market confidence in the return on investment (ROI) of CRM solutions. Whatever the reason, the reality is that a large segment of the SAP customer market has not elected to pursue SAP CRM. At least not yet.

In order to gain a better understanding of why SAP CRM has gained only modest market acceptance, and to learn what the real capabilities of the latest 3.0 product are, I am pleased to bring you the first of a two part discussion with SAP CRM expert Scott Cameron. Scott is a former Big Five Consultant with PwC who has spent the last three years managing the sale and implementation of the SAP CRM application, up through the current 3.0 version. In addition, Scott offers a deep track record in R/3 SD, MM and Workflow configuration, and he is an expert on SD Pricing and Variant Configuration processes.

Brian Trout: Scott, before we talk about the CRM 3.0 application, I would like to get your perspective on the current status of the market. We all know the down economy is a factor in the current soft market for application software, but do you see any specific reasons why demand for CRM applications has curbed so dramatically?

 

 Scott Cameron: Brian, I don't know if the demand has curbed, or if companies have just placed their CRM initiatives on hold. I think that most companies are looking to implement some facet of a CRM strategy in the future. I think the delay for CRM initiatives can be traced back to two main factors: one, as you stated, is the economy; and the second is the lack of tangible ROIs for CRM initiatives. With today's economy, we have seen companies pare back project budgets. Companies have become more internally focused to ensure viability. As a result, projects such as CRM solutions are less of a priority. For CRM projects to become a priority for a company, project sponsors must have a viable business case with tangible ROIs.

Trout: Determining ROIs for CRM is a difficult process. How do you tangibly measure customer service, customer retention, sales force integration and customer goodwill, to name a few? Most companies agree that these factors are very important, but how do you put a value on it?

Cameron: Well, most CRM business cases assess benefits against costs, using conventional investment appraisal techniques. However, this approach can be problematic when justifying expenditure in new technology that is unproven in a given industry. In this case, there may be little data available on benefits or base costs. There are two main approaches to tackling this: first, the benefit case may be less of a simple financial case, and could be based around intangibles such as the drive for competitive edge. Approval of such a case will be critically dependent on an organization's attitude to risk and their business goals. The second approach would be to evaluate how much the revenue line needs to increase in order to cover costs at a reasonable ROI, and to assess how realistic this is. Either approach can be a difficult and a time consuming process, one that takes effort at numerous levels of management.

Most companies in today's marketplace have shifted their resources from initiatives such as CRM to other aspects of their business to ensure survival in these tough economic times. The lower priority placed on CRM, coupled with the level of effort needed to determine tangible ROIs, makes it much easier for companies to delay CRM initiatives and refocus CRM dollars on other aspects of the business.

Trout: Several industry insiders I have spoken with seem to agree that many customers lack the vision necessary to effectively select and implement a CRM solution. How does an organization develop a vision for CRM and how is it important in determining the potential ROI?

Cameron: In order for a company to effectively evaluate their ROI, they need to have a clear CRM vision and a plan to achieve that vision. It's like building a house. You need a plan, a strong foundation and tasteful finishings. First you need the vision. Like a house, you need an understanding of what you would like to build. Do you want a bungalow or a two-story home? In order to obtain an understanding of your CRM needs, one must understand: what is CRM? CRM is not a software package, a call center or an Internet site. CRM is a business strategy that focuses on creating and improving relationships between customers and the enterprise, in order to maximize the lifetime value of that customer.

In order to document your vision, you need to answer the following question: What do I need to accomplish in order to maximize the value of my customer base? Is it to increase market share? Is it to better serve my customers, providing quicker order-to-delivery turn around? Is it to improve customer contact? Is it to reduce our customer care costs? Like a plan to a house, the vision is the big picture. This step will also provide you a main ROI for your CRM vision. For example, if the company's goal is to increase market share from 14% to 17%, the company should be able to extrapolate the specific dollar amounts associated with the 3% gain. These are the first ROI numbers.

Continuing with the vision, the company must determine ways to maximize customer value. There are two ways to achieve this. First, to increase revenues, and secondly to reduce internal costs. The foundation of any business is the order/service-to-cash processes. Therefore, the foundation for the CRM vision is the order/service-to-cash processes, coupled with the ERP and/or legacy systems. This is important because a sound customer order/service fulfillment process is visible to the end customer. Normally, the human factor in a company is able to conceal company inefficiencies. With CRM, a company's fulfillment business processes will become directly exposed to the customer and the customer will witness any process inefficiencies. If a business process appears inefficient, it may cause your customers to lose faith in order processing and/or servicing capabilities, which may result in losing the customer to a competitor. An efficient internal order/service-to-cash process will decrease your fulfillment costs as well as provide the foundation for customer retention. As a result, efficient internal processes will yield ROIs. Unfortunately, most companies overlook their internal processes as a possible CRM benefit.

Trout: I see. So potential CRM customers should pay more attention to how the CRM system can streamline internal processes. What other areas should customers focus on?

Cameron: Now that we have an understanding of the CRM foundation, we need to determine how we are going to create and improve the external customer relationships. At this stage, a company needs to evaluate how their customers interact with them today, how they would like their customers to interact with them in the future, and what information they would provide to the customer. Referring to the house analogy, this is our tasteful finishings; this is what people see as the finished product in their new home. These are your customer contact points which define how customers are going to interact with the company. Unfortunately, when most companies are evaluating CRM ROIs, they focus only on this particular aspect.

For a successful CRM strategy, a company must think BIG but execute small. The visioning stage will provide a company with the big picture, and then successful execution of the CRM strategy should be completed in small and manageable phases.

 

SAP CRM - An Overview of the Current Market, Part Two
by Brian Trout
December 2002

Since the announcement of SAP's initial CRM 1.0 product offering a few years ago, interest in SAP CRM amongst global customers has steadily risen. In order to gain a better understanding of where SAP-CRM stands today, in terms of functionality and scalability, I am pleased to bring you the conclusion of a two part discussion with SAP CRM expert Scott Cameron. Scott is a former Big Five Consultant with PwC who has spent the last three years managing the sale and implementation of the SAP CRM application, up through the current 3.0 version. In addition, Scott offers a deep track record in R/3 SD, MM and Workflow configuration, and he is an expert on SD Pricing and Variant Configuration processes.

In the first part of our discussion, we covered some of the overall issues facing the CRM market. In this installment, we take a closer look at the latest release of SAP CRM, and ask Scott to give us his perspective on how this solution will fare with both existing and potential SAP customers.

Brian Trout: Scott, shifting the discussion specifically toward SAP CRM, What significant enhancements has SAP included in CRM 3.0?

Scott Cameron: Brian, the main feature of the CRM 3.0 release is the integration across the mySAP.com suite of products and the integration into back-office legacy systems. With this integration into back office systems, SAP no longer has to rely on SAP CRM customers to have an SAP ERP system.

If you have an SAP ERP system with the functionality of the Sales and Distribution module implemented, you will find some duplication in functionality. This duplication in functionality occurs in the sales order and invoicing areas. One great feature of SAP is its scalability. If you have implemented the SD module, you do not have to re-implement the sales order or invoicing functionality within the CRM platform. For a successful implementation of any CRM strategy, a company needs to think big and execute small. A scalable platform will allow the implementation team to leverage previous work, which should reduce the implementation cycle to subsequent phase.

With 3.0, SAP has improved its messaging interfaces for B2B processes. Customers can be integrated using either XML-standards or EDI. Import interfaces for product catalogs, customer data, and sales orders have been expanded. As well, export interfaces for sales order confirmations and invoices are now available. These features give a company greater flexibility and functionality when implementing CRM for the electronic media medium.

In addition, there are a host of other enhancements specific to channel management, multi-channel analytics and deployment, but they are too numerous to mention within this forum.

Trout: I see. We have observed a similar trend moving away from R/3 reliance in other areas of SAP's latest applications such as BW 3.x, WAS 6.2 and Portals 5.x. What impact has this trend had with respect to CRM?

Cameron: Now for the reality: this non-reliance on the SAP back end has come at a price. With the early releases of the CRM 3.0 platform, the data integration with the back-end is not as strong as 2.0. For example, the sales office and sales group within the customer master fields was not developed in the 3.0 platform. Some companies have used these fields for territory management and sales analytics within the R/3 system. These fields were developed and released in the 2.0 version of the software, but were not available in the earlier version of the 3.0 software. Companies who migrated or implemented CRM 3.0 have had some challenges if they used these fields as a part of their business processes. Companies either had to rework their business processes to overcome this gap in functionality, or they had to custom develop these fields to get the functionality they desired. The sales office and sales group fields are now available with support pack 10.

I would recommend that any company starting a new implementation or starting a new phase of their CRM implementation upgrade to service pack 10 as a minimum. This will ensure that most of the undocumented features of the 3.0 release should be addressed. Like R/3, CRM is an evolving software platform. More functionality and improved integration will continue to be released as new versions become available.

Trout: Is SAP CRM as a stand alone truly able to compete with Siebel for non-SAP CRM customers? And if not, where is SAP still coming up short to Siebel?

Cameron: Yes, I think SAP can compete with Siebel for non-SAP customers.  SAP has developed strong interfaces within the R/3 platform and SAP has been able to leverage this functionality within the SAP CRM platform. It is this functionality that gives SAP an advantage over Siebel in terms of ERP integration. Another difference between SAP and Siebel is that Siebel has pre-delivered industry solutions. This is a feature that Siebel emphasizes when selling their CRM platform. 

Trout: Does SAP seem to have any intentions of marketing SAP CRM to non-SAP clients, or are they primarily focused on winning CRM accounts on their own install base?

Cameron: In my opinion, SAP will market SAP CRM towards non-SAP customers, but the sales cycle for new product, such as SAP CRM, to an existing customer base is short, and thus less costly than marketing towards non-SAP Customers.

I think SAP should continue to market SAP CRM towards their own customers first, for a couple of reasons. First, SAP customers understand the benefits of using SAP, such as data integration, vendor support, software platform release strategies, etc. Second, SAP customers are comfortable with the software platform look and feel, software design logic and their issue resolution channel. All of theses points can be summarized as the customer/vendor relationship.

The sales cost in developing new vendor/customer relationship in a new market niche is expensive. Thus, each sale of the product to the existing client base should yield higher profit margins to the vendor as well as easier market acceptance. This is why SAP should continue to market the SAP CRM platform to their existing customer base first.

Trout: In your opinion, has SAP CRM evolved enough to fulfill a company's CRM vision?

Cameron: The answer is YES. I believe that SAP has the technical and functional foundation to fulfill a company's CRM strategy. The CRM platform is scalable and robust enough to provide a company with the functional building blocks to meet their CRM requirements. As well, the mySAP.com platform is integrated, similar to the R/3 ERP platform - it provides the same customer data information in real time across many customer touch points.

One feature about the mySAP.com platform, which I like as a consultant, is that it will support any Internet, data or CRM strategy. Most companies have a centralized or decentralized data strategy, and/or an inside-out or an outside-in Internet business strategy. SAP CRM will support any business strategy. This is a real cost savings advantage because it reduces the change management factor needed to provide a working platform to support a company's CRM vision. From what I've seen with the other CRM platforms, they usually favor one type of business strategy over another. If the strategy they support does not reflect your company's business strategy, additional development and change management will be required to successfully implement your CRM vision.

---

This concludes our two part discussion with Scott Cameron. As we suspected, SAP has closed the gap considerably on its major CRM rival Siebel, and offers many of the capabilities that were once a competitive advantage for smaller CRM application providers such as Onyx and Kana.

We conclude with some final thoughts for any companies currently staffing or planning to staff an SAPCRM initiative. We would characterize the market for independent consultants with functional SAP CRM expertise as somewhat scarce, particularly with respect to 3.0 knowledge. Clients fortunate enough to find such expertise should expect to pay anywhere from $150 - $175/hr and up for proven experience. On the flip side, technical SAP CRM resources with SD-ABAP, IPC development and/or Java development skills are more readily available, and can typically be identified for hire at various levels of experience between $70 - $125/hr.