Section 7.3. How does SAP help customers adopt ESA?


7.3. How does SAP help customers adopt ESA?

SAP's program for adopting ESA is a formalized yet flexible methodology that turns the journey toward an SOA into a logical series of steps. Each step involves a team of stakeholders, and together they can streamline and simplify an otherwise complex endeavor and provide an evolutionary path. With careful advanced planning and consideration of all risk factorstechnical, economic, political, and so forthdisruptions are kept to a minimum.

The ESA Adoption Program SAP has developed reduces adoption to a series of four sets of activities. It is a cross-organizational approach designed to align business and IT, help customers keep costs in check, and shorten the time needed to create a versatile, powerful foundation on which to build ESA.

The program is divided into four phases, as outlined here and as illustrated in Figure 7-1.

Figure 7-1. Phases of ESA adoption



Discover

The user organization endeavors to grasp the vision of an SOA in general and ESA in particular.


Evaluate

The goal of this phase is to identify a first set of valuable enterprise services to build, framed as a short-, medium-, and long-term plan.


Implement

A new composite application is constructed from the services identified in the evaluation phase.


Operate

The value of the new architecture is showcased internally and externally, allowing other companies to see the new solution.

Each phase is supported by SAP's portfolio of field-tested enablers, a dozen or so support services that include a variety of tools, templates, samples, and workshops. Because of the program's flexibility, customers can select these enablers on an as-needed basis and they don't necessarily have to start from the first phase.

No two enterprises will progress along the same path while working through this sequence of steps. Of course, SAP supports customers throughout the process with its consulting services and other aids. But any enterprise that does make the effort will be able to achieve similar gains: a good measure of mid- and long-term planning reliability, a major reduction in risk and complexity, and greater alignment across the customer organization. What's more, that enterprise will have the advantage of being able to leverage SAP's deep and unmatched expertise in applications, services, business processes, and the modeling of business objects.

The SAP NetWeaver Customer Advisory Office

Helping customers is the job of the aptly named SAP NetWeaver Customer Advisory Office, which ensures that early adopters can leverage newly introduced SAP solutions effectively. The Customer Advisory Office works with account teams to identify customers facing common challenges who are moving forward with new solutions. They work to develop a complete solution from the new product introduction that can be replicated to other customers. The complete solution is then tested to ensure it can scale to other customers. The Customer Advisory Office takes care to coach the account teams and the customers to introduce new solutions at an early stage to ensure successful adoption. The Customer Advisory Office helps minimize the risk of failure for early adopter projects and at the same time speeds up the mass-adoption process for the solution for SAP.


The guiding principle throughout is sober-minded evolution, not wildly optimistic revolution. The result will be an in-depth plan, or roadmap, describing in fairly specific terms what needs to be done at each stage of the adoption process, when to do it, and why.

We must emphasize that this four-stage adoption process is not intended to yield a complete, enterprisewide plan for adopting ESA. The aim is simply to identify a good starting point or two for trying out ESA and proving its concept in the context of a specific enterprise and its specific IT systems and business strategies. An incremental approach such as this makes it possible to leverage some early successes and thereby encourage other parts of the organization, and eventually all of the enterprise, to get on board and adopt ESA, too.

A key aspect of these sessions, making them particularly valuable, is that they inevitably help IT and business to better align with each other. Each side can describe what it believes as essential and, through give and take, can come to an agreement about how to proceed. Each side can identify the most pressing projects in its pipeline, and can work with the other side to hammer out a prioritized list of what should be done first and what can wait.

7.3.1. What happens in the Discover phase?

As the term discover implies, the emphasis in this phase (see Figure 7-2) is on learning and understanding. Line-of-business IT staff gather with SAP consultants in a series of workshops or interactive sessions that are designed to explore ESA's basic workings and its potential for enhancing the organization's business. Typically, IT and business leaders work together, brainstorming on the ways and areas in which an SOA could foster innovation and lower costs for their particular enterprise given its specific IT landscape or set of systems, and its specific business needs and strategy.

Figure 7-2. The Discover phase


The aims of these sessions are to:

  • Grasp the value of the NetWeaver platform

  • Identify opportunities for applying the enterprise services idea

  • Explore the total cost of ownership (TCO) of this approach

In support of these goals, SAP has developed a workshop plan for each session. First, customers can participate in an ESA and SAP NetWeaver Vision Value Session. This provides a basic understanding of two entities: one a concept and the other a product that supports that concept.

Next comes an ESA Opportunity Workshop, in which the customer and SAP advisor/consultants explore the customer's key business challenges and how ESA might help to address them. As we'll see shortly, this workshop can be an eye-opener for many people, revealing the true power of an SOA while showing that this concept is not as new as one might think. The provision and consumption of services are pervasive in today's corporation, even if those services are not always rooted in IT.

Finally, a TCO Discovery Session identifies and validates the long-term economic advantages of SAP NetWeaver. A customer will see, for instance, how ESA can help reduce ongoing development costs, mainly through its ability to enable businesspeople and IT staff to work on relatively high-level, graphical models of business systems that SAP NetWeaver translates directly and automatically into functioning code.

7.3.1.1. What do the workshops reveal?

Let's look a little closer and see what these Opportunity Workshops strive for. Both IT managers and business managers must gain an understanding of just how new ESA is, how it does what it does, and how it offers a fundamentally new way for large enterprises to apply IT to business problems. Equally critical is a general understanding of the SAP NetWeaver platform and its business value.

Getting comfortable with ESA may require some determined thinking by newcomers. What makes the idea so new, of course, is that it centers not on pieces of hardware or software, but instead on the notion of servicesself-contained tasks, that is, or building blocks of functionality, that can be called into action by other services or by people through well-defined and stable interfaces.

By definition, each enterprise service that an organization defines and makes available for use will consist of some business logic and a method, or technology, which enables individual workers, business processes, or other enterprise services to gain access to that logic. ESA's goal is to provide a single technology platformin this case, SAP NetWeaverfor all enterprise services to use in a common, standardized way, a platform that also enables users to identify new services within their set of applications and business solutions. In many cases, enterprise services will combine functions that several disparate information systems currently handle, thus creating a brand-new, higher-level construct.

The first step toward implementing ESA, therefore, is to identify potential areas of enterprise services that promise to be particularly useful to the organization in question. These services won't necessarily map on a one-to-one basis to existing IT resources or business processes. Identifying these potential areas for enterprise services will likely require new thinking and analysis. You can find more information about the design and discovery of enterprise services in Chapter 4.

7.3.1.2. How about a concrete example?

Good idea. Let's suppose a U.S. manufacturer's high-level business strategy calls for expanding annual sales in the South American market over the next few years, and to achieve that growth, it has decided to rely mainly on indirect channel partners. This goal may appear to have little to do with ESA, but let's take a closer look. An executive in charge of this strategy might explain that the company will depend on indirect sales partners in South America simply because it is not sufficiently familiar with the business and sales culture in South America to succeed on its own. Listen again and you'll understand that this executive is actually concerned with the quality of a specific servicenamely, a service whose focus is the selling of goods in South America. The company could decide to provide this service through internal means, setting up offices in South America, hiring and training the appropriate staff, and doing whatever is required to find customers and successfully close sales with them. Instead, however, the manufacturer has decided that South American channel partners can provide this localized sales service more effectivelywith a higher level of quality and at a lower costthan an in-house sales team could manage.

With this choice, however, the company has embarked on a plan that, to be successful, will require a costly and somewhat risky integration of its new South American channel partners into the main body of the enterprise. And more likely than not, setting up and managing that kind of integration is not one of the manufacturer's core competencies. Indeed, the company would do best to treat its sales partners strictly as providers of a serviceas transparently as possible, with stable, well-defined expectations of what they are to deliver and how much they are to be paid for different kinds and levels of their services.

The lesson here is that this kind of service-focused analysis of business strategy often yields a clarity that a company's business managers will find tremendously valuable. If a company wishes to have direct power over its South American channel partners, more or less telling them how to do their jobs, then those partners become part of the company's internal business processes. Therefore, the company will have to invest accordingly, perhaps installing a full-blown CRM system to serve them, for example. But if those channel partners are treated as hands-off providers of a service, the manufacturer can safely reduce the investment in such systems by a significant degree.

In precisely this way, through reframing strategic business problems in terms of enterprise services, a company can begin to grasp the nature and ultimate benefits of the ESA approach. Of course, getting to the point where a company can conceive, plan, and conduct business and IT in terms of such enterprise-level services requires serious effort in analysis and planning.

This discovery process will make it clear that ESA is not just another IT concept. A company is most likely already using enterprise services, even though they may not go by that name or be understood in those terms, or it may not contain any obvious IT component. A good example is that of an external warehouse operated by an outsourcer under contract. Typically, this contract will bind the warehouse operator to provide a well-defined set of services at a predefined level of service and at a predefined cost, perhaps with incentives and penalties added to further structure the relationship. What truly matters to the company acquiring this service is that this warehouse service delivers the right goods at the right time, as expected. How or where or by whom this service is executed is less important.

In creating an ESA roadmap, managers who run key business processes can start to understand their business process strategy in terms of services. And they can do a much better job mapping those strategies to ESA, which empowers their business to the full extent possible. That is, by defining an enterprise service as being ripe for ESA, an organization learns about the underlying layers of business solutions and technology and can take advantage of those layers in ESA.

Executives will now be aware, for instance, that they must keep the interface between their organization and any provider of a service as reliable and stable as possible. This is a key concept with ESA, whether the interface faces outward to engage with third-party providers or connects a provider and a consumer that are both internal.

The main goal is to start to understand what changes will be needed to develop ESA, both in terms of manpower and IT elements. This understanding will be at a fairly high level, and the organization will understand that an ESA roadmap is not just another process optimization; it is an architecture that can cause a change in ownership, in moving activities, in creating a service provider organization, in reviewing corporate strategy, and so on. Executives will become aware, for instance, of the need for a vehicle to feed their applications with the enterprise services being created. At the same time, they will see that new skills may be needed. Take the example of that company seeking to boost sales in South America. Although its headcount in sales may shrink because the company is using external providers, the headcount will need to increase in the department that interacts with those new partners.

7.3.1.3. Are there different types of enterprise services to look for?

By drilling down to an appropriate level of detail, two types of prototype enterprise services may be identified: execution-related services, and those that support Master Data Management (MDM).

In many cases, a particular step of some business process will be standardized enough for it to be treated as an enterprise service. It will then be available for reuse across the enterprise and therefore able to yield economies of scale. For example, looking up the profile of a customerpostal address, phone number, email address, and so forthis the kind of activity that lends itself to being provisioned as a service.

In some cases, though, a certain business process step may not be standardized across the enterprise. The reasons may vary: for instance, they could include local laws, regulations, or cultural factors. The best that can be done, therefore, is to create an enterprise service that accepts inputs from different sources but makes sure that master data records are updated in a standardized way. Depending on circumstances, this may be as far as the enterprise services concept can be taken in that particular area.

Take as an example the checking of customers' credit ratings. At first glance, this may seem like a perfect candidate for being treated as an enterprise servicewell-defined parameters and a task that's typically handled by an outside provider. In Germany, however, legal restrictions might render credit checks to be quite different, in terms of scope and the kind of data returned, from the credit checks typically run in the U.S. As a result, a company operating in those two countries may depend on a different provider of credit-checking services in each locale. But to pursue the enterprise services model as thoroughly as possible, this company might also create an enterprise service that receives the data supplied by each of those services and, in a highly standardized way, makes sure that the data is clean and consistent before permitting it to go any further and update the enterprise's master data records.

7.3.1.4. How can companies avoid disruptive change?

Short answer: by careful planning.

In its ESA Adoption Program workshops, SAP works closely with each customer to identify its pain points and, in turn, the two or three business processes that make the most sense as the initial places to implement ESA. The customer IT team will work with SAP's consultants to analyze, quite closely, their firm's business processes and IT landscape. This analysis ranges from the organizational model to the specific IT systems to the structure of the business processes. Key to avoiding risk is that the analysis will take into account the interdependencies that may exist between different processes and underlying systems and attempt to evaluate the risks that may arise if any of these systems are significantly changed.

At this point, a company and its senior consultants will work together to select the best initial candidates for enterprise services. They will base their choices on an informed analysis of the potential value that each such service may yield, taking into account all relevant factors. The company must evaluate each process step on its own, using a standard compare-compute-analyze procedure, with the results presented in the form of a matrix that compares effort and benefit.

The goal is not to rush forward at all cost, but to make solid progress while avoiding too much disruption to company activitiesto strike a good balance, that is, between costs, both direct and indirect, and the benefits that may accrue. The potential gains to be reaped from creating a new enterprise service may be substantial, but they must be weighed against negative consequences, too. For example, an enterprise may have recently upgraded a particular IT system in a major way, putting its end users through a trying period of testing and retraining. Aware of this episode, consultants might recommend postponing the implementation of any enterprise service that would affect that system and those users, just to avoid additional trauma.

As a company begins to see the first outlines of ESA, revealing in limited but growing detail the people, processes, and information integration that will be involved, it will have an increasingly concrete plan for moving forward. This plan, or roadmap, will show the optimal sequence of enterprise services to be created, one after the other. This development sequence is of critical importance because it will take into account not only logical interdependencies between different enterprise services, but also any preparatory work that a company needs to do before creating those services. For instance, with different partners providing credit-check services in different parts of the world, it's possible that each service would identify the same customer in a unique and different way. Without some kind of data-cleansing mechanism, these disparate customer IDs would pollute the master data record with redundant information. In order to proceed with the relevant enterprise services, the company must ensure that this data-cleansing mechanism is developed and tested before deployment.

To help determine dependencies, evaluate risks, and generate specific action items, a quality consulting organization will rely on the so-called SWOT technique. In a structured manner, consultants will weigh Strengths, Weaknesses, Opportunities, and Threats that each service brings to the table. Done properly, such a thorough analysis takes time but is the best way to identify potential problems before they become serious. Equally important, this analysis can show the owners of business processes, in explicit and concrete terms, just how the move to ESA will directly benefit them.

7.3.2. What happens in the Evaluate phase?

The goal of the Evaluate phase (Figure 7-3) is to design a customer-specific roadmap for reaching ESA. This roadmap will take into account vital details of the customer's IT systems and key processes such as interdependencies, IT practices, and the needs and even moods of the people who work with those systems.

Figure 7-3. The Evaluate phase


To help out, SAP offers two workshops: the ESA Enabling Roadmap Workshop, which is project focused, and the ESA Roadmap Workshop, which has longer-term vision and considers how the organization can tap into the full power of ESA. Together, these workshop sessions can provide the customer a point-by-point strategy for working with ESA. Depending on their circumstances, customers may choose to run either workshop or both in their development of a roadmap.

Let's look at them in more detail.

The Enabling Roadmap Workshop is not concerned with enterprise services per se. Instead, its focus is on identifying the customer's current applications, his IT infrastructure, the business processes those systems enable, and ultimately, the opportunities that may exist in this IT landscape for improvements. In this regard, the customer will be on the lookout for areas where two systems may overlap and where consolidation would improve the efficiency of the IT operations.

The ESA Roadmap Workshop adds to this analysis the notion of enterprise services. Its goal is to redraw the customer's IT setup in terms of enterprise services and show what it might look like after that transformation.

Now, after undertaking these two evaluation workshops, the ESA adoption roadmap will finally be ready for review.

7.3.2.1. What will the customer be able to see with the roadmap in hand?

With the roadmap in hand, the customer will be able to see:

  • What needs to be done

  • When to do it

  • Why to do it

Thanks to the thorough analysis undertaken with guidance from the consulting team, the roadmap defines a route through and around all important constraints and logical dependencies. It details the prep work that may need to be done before certain enterprise services can be created, implemented, and brought into production. The roadmap puts all of this together in a single, well-structured document that can serve as a central point of reference.

The roadmap will need to be revisited from time to time, as the customer and consulting team implement ESA, encounter problems, revise plans, and respond to changing business conditions. Once the company creates the roadmap, it can hammer out a release, or rollout, strategyaddressing an important question: what is the potential for disruption to daily activities as each candidate enterprise service is brought online? The goal, of course, is to keep disruption to a minimum. For example, a company's credit-check service may entail only the integration of information that can be turned into a service quite quickly. Even if the consulting team doesn't have such a service in its portfolio, the company may be able to use technologies to build the service itself.

An available-to-promise service, on the other hand, would be significantly more complicated because it involves not just checking for availability, but also making a reservation, and that calls for writing data to the appropriate systema potentially risky operation if the proper controls and data-checking routines are not put in place. The most advanced service would also check on availability by polling partners' systems, too, which requires integration across companiesyet another exposure to risk, given how complicated that kind of integration tends to be. Clearly, an enterprise service of this complexity could not be implemented quickly.

It may be that some steps in a service can be done quickly in a few weeks or so; other more complicated steps may take many months; and one or two steps will require more than a year's work. Companies can perform this necessary ESA work one step at a time, with each step done as soon as possible.

7.3.3. What about the Implement phase?

In the Implement phase (Figure 7-4), customers plan, build, and implement their first enterprise services and then see them go live. This phase does not require a great deal of ESA-specific work, as implementing these services involves standard development procedures. Using SAP NetWeaver's robust set of tools, customers will plan, build, and run an initial set of services.

7.3.4. What happens in the Operate phase?

This brings us to the Operate phase of the adoption process (Figure 7-5), with the focus on showing the value of ESA, learning as much as possible from the preceding activities, and spreading the word about ESA's benefits.

Figure 7-4. The Implement phase


Figure 7-5. The Operate phase


At this point, the main question that customers will ask is simply this: what is the value we have achieved from our first ESA implementation, and how does it compare to what we expected? Depending on the answers, certain steps in the next round of adopting ESA may be improved. ESA can be used to easily support other business processes by creating new composite applications from existing enterprise services.




Enterprise SOA. Designing IT for Business Innovation
Enterprise SOA: Designing IT for Business Innovation
ISBN: 0596102380
EAN: 2147483647
Year: 2004
Pages: 265

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net