Expand +



How SAP Customers and Partners Are Shaping Future Applications: Defining Enterprise Services in Collaboration with SAP and Industry Peers

by Dietmar Giljohann and Marion Augenstein

October 2, 2009

What happens when industry competitors join forces to come up with some shared, standard services-based processes? Procter & Gamble shares its experience working with other companies to streamline order, shipping, and billing systems -- work that eventually led to a new composite application: the Sales Order Cockpit. This is the power of Enterprise Services Community (ES Community) groups, where customers and SAP partners identify services to drive functional and technical improvements.

Enterprise services can provide huge benefits to your organization — especially because they support flexible business processes that combine various SAP and non-SAP applications. However, achieving these benefits depends on properly defining the processes these services drive.

SAP provides a unique collaborative opportunity — Enterprise Services Community (ES Community) groups — where SAP customers can work with their industry peers and fellow SAP customers to help shape and define future enterprise services, processes, and the applications that run on these services.

Procter & Gamble (P&G) was one of the companies that worked with SAP and industry peers to drive new standards for enterprise services and together created a definition for a composite application: the Sales Order Cockpit. In this article, Dietmar Giljohann of P&G and Marion Augenstein of SAP AG share their experiences with such a group, why a company would commit to participate, and how customers benefit as they help shape new SAP products and interfaces using open enterprise service definitions.

What Is an Enterprise Service?

Enterprise services are highly integrated Web services combined with business logic and semantics that can be accessed over a network and used repeatedly to support particular business processes. These services communicate with each other by passing data from one service to another, and users can combine and reuse these services to build composite applications. As a quick definition, Dietmar Giljohann tells his colleagues that composites are Web applications that connect with SAP functionality or other back-end programs, applications, or required functions.

ES Community Groups Influence the Next Wave of Applications

Companies learn about ES Community groups in a number of ways — and each company has its own reasons for becoming involved. P&G, for example, heard about this specific opportunity — a group focusing on upcoming sales order cockpit (SOC) development at SAP — from Uwe Birke, an enterprise architect at Hewlett-Packard (HP), an SAP partner. HP, which is P&G’s IT supplier and strategic partner in global outsourcing services, was also instrumental in introducing enterprise services to the company.

As with most businesses, having efficient sales order processes at P&G is crucial to retaining satisfied customers and generating strong revenue. For P&G, there were two key types of motivation for participating in the SOC group: functional and strategic.

What Makes Up an Enterprise Services Community Group?

Nearly two years ago, SAP piloted a new collaboration channel to its customers and third-party software providers called the Enterprise Services Community, in which groups work together to define requirements for future enterprise services.

Various parties — including SAP customers, software providers, and service providers — can comprise an ES Community group. To form the group, SAP usually sends the initial invitation to all potentially interested SAP customers and partners. There may even be cases where partners and SAP customers create such a group themselves.

Bring About Functional Innovation

First, the company was looking at achieving functional improvements with its order, shipping, and billing systems. Maintaining speedy and efficient order delivery and logistics often demands locating products, monitoring customer credit limits, relocating materials, and obtaining approvals, to name a few. Knowing that the group’s main focus was developing a cockpit — a single monitor that supports everyday sales order activities and issues — P&G wanted to get a hand in defining the workflow and business processes that would drive the new product for the consumer products industry.

Done right, this application could address specific problems that P&G wanted solved for its own organization, such as truck load optimization. Providing this solution to its users via standard technology would also support open development that could be further enhanced by continued reuse and retooling in the future.

Gain Experience with Enterprise Services

Secondly, P&G looked at participating in the SOC group as a strategic way to help drive the company’s own first steps toward implementing enterprise services. P&G’s initial strategy was to start by building enterprise services together with vendors or creating home-grown services to meet specific P&G requirements. But when the offer came from SAP to participate in the ES Community group, P&G realized that it was a great way for the business to work with other companies to set standards and, as a result, realize initial enterprise services benefits at P&G.

After all, using standard functionality — and having it developed by SAP — was much more resource- and cost-effective than any custom development. Also, because the services were built using standard SAP software and therefore comply with SAP maintenance contracts, ongoing support will not be an issue for SAP customers.

Starting Point: A Foundation Meeting

A foundation meeting is the first step for a newly created group to define the relevant standard enterprise services. In this meeting, the ES Community group, typically driven by SAP customers, will meet directly with experts from SAP and with other customers around a specific topic. SAP and one of the participating companies provide a few slides or diagrams on the motivation and scope of the group to initiate the discussion and ensure that each participant has the same understanding of common issues. Objectives during the foundation phase are:

  • Understand the expectations of each member and jointly define the scope that also includes your requirements.

  • Define the group’s specific objectives and agree on a timeframe for delivering the high-level needs and the more detailed requirements.

  • As a prerequisite, require all of the contributing companies to sign a confidentiality agreement.

With the SOC group, the first order of business was to set the high-level topics — or workstreams — that were driving the processes the group needed to define. To help support the elaboration of these high-level topics, SAP provided a single slide showing a scope diagram of the application (see the figure). With members who specialized in order management but were less familiar with credit management, for example, this overview was helpful as the initial kickoff for the group’s brainstorming.

SAP provided the Enterprise Services Community group with the initial scope of the Sales Order Cockpit application

In the end, SAP was looking to the group to come up with the start-to-finish workflow. SAP supported the process by providing a high-level picture of the back-order process: filtering of orders with issues, analyzing issues, and resolving issues.

The final workstreams for the group to tackle were:

  • Sales order approval

  • Incomplete orders

  • Available to promise (ATP) issues

  • Allocation issues

  • Credit issue

  • Not Full truck load issue (sales orders)

Twenty participants from different companies and industries, but mainly other consumer companies and a third-party software provider, joined the foundation meeting of the SOC group, each with their own expertise in the area of order management. To use this expertise to its advantage, the group assigned each key topic to individuals who served as workstream leads.

The workstream leads were supported by small teams, and later by the whole group, to deliver the final requirements in a more detailed form. The group started with simpler topics — approvals or incomplete orders — to develop a higher level of process knowledge before moving to the most complex topic: how to link order management to transportation, commonly referred to as truck load build.

Considerations for the Cockpit

The Sales Order Cockpit ES Community group realized two different aspects that needed to be considered for the cockpit:

  • Industry best practices: Issues and issue resolutions that are relevant and defined by all companies in the community as industry standard.

  • Individual company concerns: Issues that are seen as differentiators within a company.
The community group made it clear to SAP that the cockpit needed to support all issues — issues that are common in the industry and solved in similar ways but also those issues that can be very individual. When specifying the composite application and services, SAP considered the two aspects: the industry best practices for typical issues and significant flexibility to make the adoption of individual issues via the services easily possible.

The Group Timeline

To set expectations, SAP recommends that participants target four to six months for the group to formulate its requirements for new standard enterprise services. This may be ambitious, especially for complex functionality, but this timeline is designed to respect the participants’ own schedules and help ensure that requirements can be included in an upcoming enhancement package release.

After the group delivers its requirements to SAP, it can sometimes take six to nine months for developers to translate these requirements into an initial draft of the parameters for an enterprise service interface. SAP then publishes the initial draft for a review by a wide swathe of industry peer organizations, to reach stakeholders beyond the ES Community group members. So from the initial foundation meeting to final publication of a service, the process may take two years.

The SOC group was actually able to define standard functionality in a much shorter timeline — formulating simpler requirements within just a couple months. The group’s total lifetime — from the creation of the group to the delivery of the enterprise service — was 12 months.

The communication among the industry peers in the group was a key factor in keeping the group on track. SAP supports group communication with an online collaboration workspace, a virtual meeting place for group members to share information and documents, and groups hold regular conference calls and occasional onsite meetings to tackle more complex requirements. As a best practice, SAP advises that the industry side of the group moderate ongoing face-to-face meetings to ensure that the group’s work remains industry driven.

An early mock-up of the Sales Order Cockpit selection screen, and the final screen developed after input from the SOC group

Broader Benefits for Participants

For P&G, one of the benefits is, of course, in the final application itself. The Sales Order Cockpit application will benefit customer service representatives who need a single view of all problem orders, for example, special orders that require approval, customers exceeding their credit limit, or incomplete order data. Rather than having users move from transaction to transaction, P&G’s objective — as well as the group’s — was to put all these issues together into a single screen.

In addition to influencing the technology, companies gain by:

  • Achieving measurable efficiencies. With the resulting cockpit, P&G expects significant savings due to increased user productivity for the majority of sales order transactions.

  • Getting hands-on expertise with composites. This is also a huge learning opportunity for participants and a chance for the group members to look to their peers to develop new knowledge and skills. For example, you may be an expert in the approval area and order management, but you could gain a great deal of new expertise by collaborating with a specialist in credit management. After discussing the complex truck load build topic with the group members, two people who were previously unable to solve the issue tackled the issue and wrote logic for the functionality in just a couple days. According to Giljohann, it was clear that the group members had learned a great deal that they would take with them long after the group’s work was completed.

  • Collaborating directly with SAP developers. The SAP process specialists and the developers in the group continue to collaborate from the beginning of the process right until the end. For service definitions that include a front end, SAP provides mock-ups of the service interfaces and the GUI along the way to assure that the functionality is meeting the set requirements. In the SOC group, during the early stages, SAP brought in other process experts to increase the group’s understanding of highly complex topics, and later the GUI developers helped smooth user productivity when navigating the cockpit. P&G found that SAP can make significant achievements and improvements regarding its application portfolio by interacting closely with its customers.

  • Working closely with industry peers. Meeting with other companies reflecting deep and broad knowledge in SAP-related topics is very fruitful for all participants. Comparing processes and understanding experiences from various sides of an industry can highlight the complexity of providing standard software to meet various needs. When the SOC group collaborated to define the workflow and those services, this was an advantage to the companies involved too. Together they could compare processes, understand common needs, and shape what those processes would be on an industry standard.

The Final Step: User Acceptance Testing

In the SOC group — because the front end (a composite application) was part of the scope — the final step was user acceptance testing. First, the group ran through the acceptance test of the front end, which was already connected to most of the enterprise services of the scope, which ended up amounting to more than 20 enterprise services. During the test sessions, the group checked all functionality and looked at user productivity and ease of use.

During daily calls with the GUI developer team, the group discussed the test case issues and options for improving productivity. Some of the testers were involved from the inception of the ES Community group. Others saw the front end and its concept for the first time to ensure a realistic analysis.

The enterprise services were already tested by SAP internally, so issues were not reported during the testing. Productivity issues were openly discussed with the GUI team, and because of these discussions, the cockpit will incorporate various improvements.

The final result reiterates the benefits that customers have from this process:

  • SAP customers share their best practices and jointly define the “one” best practice so SAP can provide the most beneficial enterprise services to all.

  • SAP customers define and review use cases and specifications to paint a clear picture of the process requirements to help ensure that developed services fully support the business requirements.

  • SAP can determine when its own developers should create a composite application, in addition to delivering the service. This allows customers to more quickly see the delivery of a new SAP solution and services with direct customer influence in the scope, design, and reviews.

How a Service Becomes a Composite

Because of the availability of a pre-defined enterprise services repository plus an easy-to-use toolset — that in combination allow developers to build lean composite applications with tailored, easy-to-use front ends — services can be delivered in a way that is friendly for casual users who are not trained in SAP applications.

The agreement on a set of enterprise services usually means that SAP decides which services to include in upcoming enhancement packages and which ones will simply remain as an interface definition. However, composite applications are independent of the SAP release strategy and can be developed and shipped at any time.

Composite applications do not necessarily need to come from SAP, of course; vendors and customers might build applications consuming the agreed services as well, or software may not be developed at all. Some service definitions satisfy long-term strategic needs of high complexity rather than more urgent needs, so those services will provide a framework for future functionality and for standardization to be developed by interested parties.

In the case of the SOC group, SAP shipped the functionality starting with enhancement packages 3 and 4 for SAP ERP. The composite application with the GUI is planned for later.

Join the Community

ES Community groups provide a well-established and exciting way for collaboration between SAP and interested customers and partners in an industry across regions. If you are destined to employ enterprise services as part of your SAP infrastructure, we recommend that you participate in an ES Community group to realize significant benefits, as P&G did to create the Sales Order Cockpit application.

ES Community groups are open to SAP partners and SAP customers of all sizes, based on your area of interest. For more information on participating in a group, please contact your SAP representative or visit the ES Community at

6 Lessons Learned

Once you’ve decided to join an ES Community group, here’s some advice on getting the most from the experience:

Speak up and be assertive. Don’t leave the service definition to chance. Explain what you want to receive from SAP and provide details. Only what you share can be considered.

Create parallel workstreams. When defining a set of workstreams, assign the individuals with the best business knowledge in those particular areas. These parallel workstreams will reduce the dependency on the contributing companies and will shorten the life cycle of the group.

Take advantage of Web 2.0. Use the online collaboration workspace to encourage group members from various regions to contribute to the requirements. Participants can share information and materials virtually.

Select a leader. Assign an individual from the industry members of the group to moderate ongoing face-to-face meetings. This will help ensure that the group remains industry driven.

Keep it simple. Maintain a lean workspace structure and limit the number of subgroups. With too many groups, participants may get lost and may give up contributing or following the discussions.

Stay engaged. Join and actively participate in the entire collaboration process. Active companies have a better chance of seeing their requirements considered. Prioritization and directions of requirements in the group can be influenced by your insights.

Dietmar Giljohann is an SAP business systems analyst and solution owner in order management in the consumer goods industry. He has a mechanical engineering diploma and a Ph.D. in computational acoustics. His expertise areas are order management, EDI, and SAP NetWeaver Process Integration. On the industry side, he moderated the Sales Order Cockpit ES Community group.

Marion Augenstein is the SAP Industry Solution Manager for Consumer Industries at SAP AG. She has a diploma in economics and has been working for more than 10 years at SAP. As Solution Manager for Demand Management, she leads roll-in activities for several business processes in the area of responsive supply networks and contributes to industry-specific SAP Thought Leadership topics.

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!