Joseph Fultz, Technology Architect
Microsoft Technology Center—Austin

Michael Riley, Technology Architect
Microsoft Technology Center—Austin

Moin Moinuddin, Industry Architect
Microsoft Corporation

Laura Preslan, Industry Manager
Microsoft Corporation

Ellen Terry, Architect

May 2007

Applies to:
   Price Management

Summary: This paper walks through a solution that plays itself many times in real-world enterprises. The reference application pack (RAP) provides a basic reference for solving price-management challenges. However, the solution highlights a very capable platform that is appropriate for use in solving a wide variety of business challenges around line-of-business (LOB) augmentation and integration. (15 printed pages)

"Leading companies use price management to increase revenue by 2 percent, gross margin by up to 15 percent, and contribution margin by up to 50 percent."

Source: AMR Research Alert, "Reader's Guide to B2B Price Management Research," June 1, 2005, Laura Preslan, Author

Contents

Abstract
Introduction
Current Business Challenges
Microsoft Office SharePoint Server (MOSS) Solution
Solution Architecture
Technology
Conclusion
References

Abstract

Across industries, there is a rise in the need to get more value out of existing information systems within an organization, including enterprise resource-planning (ERP) systems. Conventional ERP customization, however, often entails project life cycles and spending that do not allow IT organizations to keep pace with business requirements. These IT organizations need a more flexible platform that allows them to deliver business solutions quickly based upon a well-known user experience, and that supports other organizational drives, such as workflow, enterprise content management, and business intelligence.

This paper will walk through a solution that plays itself many times in real-world enterprises, especially Fortune 500 companies. Many enterprise organizations use SAP as their back end, where all the pricing information and rules will be stored. However, the gap between the pricing-rule updates and the field-sales organization always tends to be huge, which results in pricing-rule updates reaching the field-sales teams much later than they should. Many Fortune 500 organizations are looking for a way to reduce the delay between pricing-information dates and delivery to the sales group. This is now possible to achieve by building a solution that uses the 2007 Microsoft Office platform to achieve real-time price-update capability both in online and offline modes.

Introduction

Price management is the end-to-end process of optimizing, communicating, and enforcing prices and discounts. The benefits of improved price management are undeniable. Several studies have shown that incremental increases in price and margin have a dramatic, positive impact on the bottom line:

• A $5 billion distribution company increased its contribution margin by 50 percent in 18 months through the improvement of pricing processes and the use of price-optimization technology, leading to $45 million in benefits in 9 months.
• A $3 billion industrial-manufacturing company increased its median price by 12 percent, resulting in more than $19 million in benefits while driving a 1 percent increase in year-over-year volume.
• A $20 billion chemicals company found over $250 million in benefits across 11 divisions by closing margin leaks in its price-execution processes.

These brief examples beg the question, "If improving price management generates such impressive results, why isn't everyone tackling it?" The answer comes down to process and technical limitations that plague many companies, as shown in Table 1.

Table 1. Process and technology pricing issues

The complexity of these issues often overwhelms companies and prevents them from acting. The key is to start small and fix the most painful areas first.

According to an AMR Research Report entitled "Order of Operations, Start with Execution," companies must begin by capturing the low-hanging fruit and increasing efficiency first. This then sets the stage for more advanced capabilities, such as algorithmic price-optimization engines that identify the less obvious opportunities.

To address price-execution issues, Microsoft has developed an Office Business Application (OBA) solution that uses capabilities in the 2007 Microsoft Office systems platform and Windows Server system to integrate the common, intuitive interface of Microsoft Office tools, the flexibility and power of 2007 Microsoft Office system servers, and the existing business processes and knowledge that exists within line-of-business (LOB) systems. In the words of Forrester Research, OBAs link the "system of action" in which people actually perform their jobs with the "system of record" in which the data and process are housed.

The key benefits of this approach are as follows:

• No more struggling with clunky interfaces. Allows salespeople and pricing analysts to use the tools with which they are familiar, instead of having to learn a new interface.
• No rip-and-replace. Leverages existing investments.
• No more double entry of information. Increases process accuracy through improved integration.
• Within this solution, you will see corporate end users exercise new-found capabilities:
  • Pricing analysts use Microsoft Office tools to define pricing rules.
  • Sales engineers create quotes in the Microsoft Office applications they prefer.
  • Sales and service managers leverage 2007 Microsoft Office system capabilities to monitor, investigate, and participate in business processes around quotations.

All of these activities take place within the context of business information and process that is grounded in—and fed by—information from corporate ERP instances.

Current Business Challenges

Existing solutions used by many Fortune 500 companies have many challenges, which are directly affecting the productivity and revenue of the organization. Some of the most prominent challenges pertaining to this scenario are listed in the following section.

Unstructured Processes

Within current solutions, it is not uncommon to have sales engineers create, approve, submit, and service customer quotes using a variety of tools—some structured, and some more free-form. Some solutions will tend more toward carefully honed tools that facilitate quoting specifics, while some center upon sales engineers using a combination of paper-based pricing books, a macro-heavy Office Excel workbook for quote creation, and e-mail. A common attribute that spans all of these solutions, however, is the existence of an unstructured process that somewhat parallels the structured world. This unstructured process represents the collection of workarounds that are informally followed within a population to feed the structured, formal business process. As shown in Figure 1, this unstructured process may actually form the bulk of an actual business process.

Figure 1. Existing quote-to-order process (Click on the picture for a larger image)

In the example shown in Figure 1, most human interactions exist outside the confines of the structured business-process platform. This means that a significant slice of the human-oriented process exists outside the support of IT-process-platform investments, and will also typically indicate that these human touch points are not visible to an organization trying to assess additional aspects of business performance.

Slow Propagation of Price Rules

Business analysts manually combine reference information from key LOB systems, and record this into a combination of printed and template spreadsheets. These spreadsheets are informally propagated through field sales personnel. Personnel use these assets to create customer quotes, and then pass these through an informal approval cycle with sales-management personnel. Along the way these, quotes may be passed via e-mail, chat, voice, or other means. As soon as a quote is deemed acceptable, clerical staff record this quote down into LOB systems, and structured processing can begin.

Serving the Request

As the quote is being recorded for structured processing, it is also passed along to service personnel, so that service can be performed against the quote. After servicing, clerical staff will update order information held in SAP, and structured processes can proceed toward invoicing.

Poor Performance

In the example shown previously, field-based sales-force personnel are able to conduct business with customers. However, the organization is faced with several challenges to the business:

• Accuracy—Quote creation disconnected from business facts, leading to inaccuracies.
• Performance—Inaccurate information leads to financial errors in pricing of sales to customers.
• Visibility—The rest of the business has no insights into the sales pipeline to support its planning.
• Audit—No system of record for quotes, so no ability to support a "single version of the truth."
• Support for unstructured processes—Individuals continue to build networks and semistructured processes informally, to "work around" structured business processes.

Outdated Data

Because it takes significant effort and cost to distribute paper-based price books to a distributed sales force, sales engineers are continually working with outdated pricing information. This lag in information distribution means that not only are quotes potentially wrong, but that the business is going to be fundamentally limited in how quickly it can distribute new pricing policy/information to the sales force to respond to changing conditions. These two factors combine to contribute to a perceived lack in accuracy of the quotes.

Loss of Revenue

This inaccuracy contributed to a general lack of confidence in quotes generated to meet customer needs, but the more significant side effect of inaccurate quotes is that sales engineers are potentially offering inappropriate discount rates to customers. The customer perception of this is that discount rates are, on average, several percentage points lower than they need to be. This perceived lack of business performance for the quote process is a major driving factor behind this solution. In fact, project payback initially was measured in time based upon 1, 2, and 3 percent declines in average discount rate; each of these would have justified project execution on its own.

Lack of Planning

Within the scope of order fulfillment, it is very common for an organization to want to have visibility into the sales pipeline. In a specific example, service personnel are expected to deliver goods and services against a customer quote, and invoices are generated after these goods and services have been delivered to the customer. Given this, service managers likely will be able to plan and balance their staffing pipeline better, given that they have some known horizon of visibility into their service schedule. Because quotes are approved informally through e-mail threads, service-management personnel have no dependable means to assess this pipeline of quotes and plan accordingly. This means that service managers have difficulty building the right staffing and allocation plans to meet the sales forecast.

In summary, today's process exists outside the lines of information systems; quotes are passed informally between sales engineers, sales management, and credit management—without any usable record of this unstructured work process. This lack of inward visibility into the unstructured world means that business does not have the opportunity to audit, monitor, or improve anything going on in the critical space—the space in which their people work. Put another way, the enterprise has no opportunity to audit approvals or even view business performance of the approval process itself. For customers, this factor might not drive technology change, but the push to have some record of these documents (such as versions, workflows, or actors) is an unexpected, desirable side effect.

The lack of "audit" within existing solutions also speaks to the general concept of business not embracing/supporting unstructured business processes. We continually find that organizations will give rigorous thought and planning toward support for structured processes and needs; but, that as these structured processes are deployed to waiting consumers, one of the first things that a user community will ascertain are the "workarounds" around this structured process. In Figure 1, the entire grey box simply describes this unstructured process that user communities put in place around their ERP structured processes, so that field-based personnel might work more effectively.

Microsoft Office SharePoint Server (MOSS) Solution

In defining a solution to these challenges, there were several assets that were accepted as solution constraints. These included:

• LOB system. Given that this overall architecture was meant as a pattern for augmenting a traditional system, a general "hands-off" approach was adopted for the back-end LOB systems—such as SAP R/3. Although minor changes were made to support specific, documented integration needs, the majority of delivered value would need to come from innovation outside of the traditional LOB system.
• Microsoft Office user experience. The common request from organizations to "give me SAP in Outlook and Excel" leads the team to accept Microsoft Office user experiences as an additional constraint. This decision was not made to the exclusion of other interfaces, but did represent acknowledgement that, for some user profiles, "Office Excel–like" is not sufficient; the organization required surfacing data and process natively into Office Excel for end users.

Given these constraints, the architecture team began looking for solutions that would meet the capability, productivity, and price point desired by the customer—all while respecting key, existing assets. The resultant business process remains very similar to the existing process in terms of flow, but represents key strides forward in specific areas.

The new process maintains the core flow of sales engineers creating their quotes within Office Excel, but supplements this experience as follows:

• Sales engineers continue to use Office Excel to prepare quotes. Now, however, this spreadsheet guides them in putting together quotes that are anchored to accurate, current customer and catalog master data.
• As quotes are saved out of this Office Excel workbook, they move into a defined Microsoft Office workflow system for approval and further processing.
• Sales and service managers now interact with quotes as they are in this workflow system. This allows management personnel to view and approve quotes seamlessly through a Web browser (or natively through Office Outlook 2007, which allows you to display data from other 2007 Microsoft Office programs directly in Office Outlook without switching applications), while also giving better visibility into the overall flow of quotes moving through the quote-to-order process.

Moving down further into the details of the solution, we can begin to see how the solution works in terms of activity flows.

Figure 2. Revised quote-to-order process (Click on the picture for a larger image)

At a high level, the process shifted to run as follows:

• Solution developers define the set of master customer and catalog data that must be cached outside of traditional LOB boundaries for additional processing and offline use.
• A very small team of business analysts use lightweight, custom tools to create business rules that pull together this master data with business logic and surface into an Office Excel workbook.
• A large, distributed group of sales engineers use this new "guided" Office Excel workbook to create customer quotes. These sales engineers may be online, or could be running offline; they still have a partitioned, offline cache of the master information out of the ERP system and other key LOB systems.
• Sales managers use Microsoft Office applications and a Web browser to view and approve quotes within the context of a rich workflow.
• Service managers use Microsoft Office applications and a Web browser to view, service, and close-out quotes within the context of a rich workflow.
• The workflow system, as it drives quotes to completion, communicates these quotes as transactions back into the core ERP system.

Solution Architecture

A solution that fundamentally leverages capabilities found in a few cornerstone technologies to provide the end-to-end scenario looks like Figure 3.

Figure 3. Architectural tiers (Click on the picture for a larger image)

This begins to depict the logical flow of information and process that makes up this solution. Specifically, it identifies five discrete elements of the solution.

• Caching and rules
• Surfacing into Microsoft Office
• Workflow platform
• Appropriate workflow experiences
• Integration back into LOB systems

As we walk through the information flow, these will each take on more prominence. Looking through the process, we can begin to see how the technology platform cleanly supports the capabilities exhibited by our revised scenario.

Caching and Rules

The application system begins as business facts and pricing rules are cached from LOB systems up into a more accessible data store. This store can be regarded as read-only, and simply serves as an alternate store to use for processing as merited by business requirements. Commonly, this cache may be used to provide some amount of offline capability around data that was traditionally stranded in a set of monolithic LOB assets.

Figure 4. Analysis and composition of rules

It's very common to partition this cache of information as it moves through an enterprise, based upon security, role, and sphere of influence. For instance, a manger may have more access to data—such as the ability to change or apply discounts—than a salesperson. For example, a salesperson selling drilling equipment will see only business facts and rules related to that specific area, whereas a manager with sales quota for both drilling equipment and transportation might see business facts and rules related to both.

After this information has been made available to other processing platforms, the reference system brings to bear a small, custom application that allows business analysts to define rules that bring together business facts, so that they have business value outside of their traditional applications.

There likely will be some element of overlap between these rules and rules that exist in the traditional LOB assets. Because of this potential overlap, rules likely should exist in this platform only if there is accompanying business value to having these rules live outside the confines of the single LOB system: cross-system implications, portability, offline needs, and so forth.

Because there is a lot of analysis and composition of rules of going on, this is also called the "Analyze" phase.

Surfacing into Microsoft Office

As soon as data and rules are available for use outside of their LOB confines, work will shift to surfacing these new assets into Microsoft Office experiences. Here, sales engineers open an Office Excel spreadsheet and are guided through the process of creating quotes; all the particulars of business rules, product-configuration peculiarities, and customers' specifics are handled by the rules engine running behind the scenes.

Figure 5. Surfacing of information through Microsoft Office

These experiences typically will involve some amount of code development to produce a process-specific experience. Architecturally, this Microsoft Office add-in will need to leverage and provide for access to supporting business facts, submission of task outputs into some other system, and some means to achieve data-driven experiences that will leverage the rules defined during the Caching and Rules phase.

Another consideration is the format in which the quote is conveyed to the larger organization. Traditional, closed document formats are not appropriate for this solution, as an organization might want to have a diverse set of technologies touching the data that lives inside this quotation: quote-validation tools, business-activity monitoring engines, and so on. As such, formats that are easily understandable by server-side technologies are important. Microsoft Office 2007 platform uses Open XML formats, which help in manipulation and massaging of data while it is transitioning through various stages. In this example, XML is used extensively to ensure full compatibility across various platforms and applications.

As a sales engineer completes a quote and wants to commit the information into the organization for further processing, the application should leverage a technology that can accommodate online/offline requirements. Examples of this might include MSMQ, e-mail, and so on.

Workflows

After a quote has been created and submitted for processing, the system atomically begins running a quotation-approval workflow against that quote. It is worth noting that the quote is recognized at this point as a document for the purposes of processing. This means that the platform can bring to bear traditional enterprise content-management (ECM) capabilities to the benefit of the organization: workflow, versioning, security, offline availability, information policy enforcement, and search. Additionally, archival and retention policies can treat collections of quotes as just collections of documents—thereby, bringing the management of these business-process artifacts more inline with other efforts to manage business documents.

Figure 6. Workflows in progress

As the approval workflow for a given quote progresses, the workflow system will need to support additional access and views on this data. To support this, workflow actors in the reference implementation leverage a Web-publishing capability inherent in the workflow system to allow them role-specific views and actions against a quote based upon process context, organizational context, and specific role information.

In addition to workflow and experience aspects, the process engine coordinates workflow performance information with an external business-activity monitoring (BAM) engine that is collecting and aggregating real-time business performance information for use in a providing process and performance back to business owners.

Figure 7. Workflows in construction

Workflow Experience

After quotes are approved and service is performed against the quote, the workflow will complete. At the end of the workflow, business transactions must be committed back into SAP and other defined LOB systems.

After the transactional processing of the quote, the workflow system moves the quote from the "active" to the "processed" repository and closes out the activity records for workflows against this quote.

Solution Benefits

This revised process delivers improved user experiences for all participants and provides organizational benefits, as follows:

• Accuracy—Our revised architecture caches master customer and catalog data out of SAP into a set of local Microsoft SQL Server databases. These reside on the sales engineers' laptops and specific production servers to support offline and extra-SAP verification of quotation information versus current business standards.
• Performance—Sales engineers generate quotes based upon current, actual business data. By coupling this accuracy of information with a rules engine, customer business analysts are able to put quotation guidance in place to support sales engineers in creating better quotes; customers get the right combinations of items, and the business sees increasingly appropriate prices.
• Visibility—Because all quotes now move through a managed workflow process, business has visibility to this pipeline. This allows service engineers to balance their staffing better to meet customer and business demand.
• Audit—A side effect of having managed workflows is that the business now has records of all quotes moving through the system and how they have moved through specific workflows. This information extends from simple audit information up to business-performance-related information. For example: What is the average dollar amount of all quotes in-flight? What is the average approval time for quotes that must be approved in the Southeast region? What is the average close rate for quotes generated by sales engineer "John Doe?"
• Capturing unstructured processes and data—By leveraging a workflow solution that has presence both in server and client applications, end users began to perceive workflow not as "extra" work, but as more of a warm blanket. By requirement, they can still delegate and transfer ownership of tasks, so they continued to feel freedom. The big change, however, came in the realization that workers were coming to depend upon this workflow system as a key system for their interactions with quotes; they would consult it to find items in-process that needed their attention. And, because the engine specifically can surface tasks and documents directly into Office Outlook and other Microsoft Office client tools, users were still using the tools they prefer.

Technology

As mentioned previously, the capabilities used to bring together this solution come from a few key layers. As shown in Figure 8, the team selected specific technologies to support each of these layers. This section will walk through each of these technologies, and highlight the reasoning behind their selection.

Figure 8. Technologies used (Click on the picture for a larger image)

2007 Microsoft Office Platform

This solution leveraged Office Excel 2007 as the principal user interface for creating quotes. This provided a productive, extensible platform on which we were able to build the right quoting solution to meet business needs.

Offline data storage was provided by SQL Express, with data replication, partitioning, and security being taken care of by core Microsoft SQL Server 2005 functionality.

Rules-engine functionality was brought to bear by the rules-engine capabilities inherent in Microsoft .NET Framework 3.0. This means that rules could be executed both client- and server-side, and that workflows likewise could bridge client and server seamlessly.

Microsoft Office SharePoint Server

Microsoft Office SharePoint Server 2007 (MOSS) acts as the collaboration layer within this solution. This layer may provide a set of presentation technologies that are assembled to build-out presentation-layer experiences, but this layer must expose also functionality for programmatic consumption, such as a Web services interface.

MOSS was considered because of its great strengths, especially the following ones:

• A flexible and capable workflow engine.
• Ability to integrate data from business systems seamlessly.
• Enterprise content-management capabilities.

Other strengths of MOSS that biased the decision in its favor are:

• Empowering user communities. Support for customer self-management of knowledge and Web properties. This means that, for every site created within an enterprise, it becomes easier for business owners to become self-sufficient.
• Web-only experience. Microsoft Office integration provided by Microsoft Office and Office SharePoint Server support rich robust access through Web channels, directly from Microsoft Office client applications, as well as through mobile devices.
• Cross-system capabilities. There is a wealth of information available on integrating Microsoft Office with LOB applications. MOSS forms the basis for the collaboration layer. A core concept of this collaboration is that we modeled the workflow as being document-centric in nature. That is, any specific instance of workflow is just a workflow around a collaborative document.

Specifically, MOSS brought to bear capabilities that include:

• Place. This layer must support the basic concept of providing a means for end users to create, recognize, and visit a logical "place" where they can collaborate with others. This place may be visual in nature (and, therefore, exist as an experience in the presentation-layer section) or may be a logical destination that supports appropriate programmatic access. Either way, however, the layer should support the concept of grouping relevant information, documents, performance metrics, and people around an item of collaboration.
• Workflow. This layer should be capable of providing extensible document-centric workflow, and serves as the process model that connects presentation-layer users with constituent business systems.
• Communication. This layer should be able to connect end users better around an item of collaboration. Specific communication needs may vary from one process to the next, but the guiding concept is that end users should perceive that they are better interconnected through the use of this technology. A clear example of this better connection comes as we look at collaboration technologies that expose the concept of user presence, so that end users can get a real-time view of the availability of other users involved in their process.
• Content management. Given that we have made the decision to adopt a document-centric view of process, the collaboration layer should have the ability to manage content items involved in a business process. This concept of content management should include workflow (as mentioned previously), but also should include abilities such as metadata definition and storage, document versioning, document retention/archival, and the ability to handle varying document formats.
• Search. As the amount of business information grows within this application system, end-user search will become an increasingly important capability for end users. The collaboration layer inherently should support the ability for end users to find current, or historic, business-process instances. An implicit requirement within this layer is for the collaboration layer to support broader enterprise needs for search. This broader support could manifest through the collaboration layer, acting as the enterprise search technology, or through it, supporting existing enterprise search mechanisms through some form of federated search integration.
• Business-data access. As a business process is in motion, specifics about that instance will be described within the document associated with the process. There will be additional information relevant to process actors. However, that would be of benefit to them as they interact with the process. In support of this need, the collaboration layer should support the ability to reference and include relevant information from other business systems. This information could take the form of relevant transaction, status, or historical data. A specific example might be to show the last three payment transactions associated with a customer who is in the process of requesting additional work. An architectural note is that this data should be lifted in some near-real-time fashion out of its owning system, instead of encoded into process instance–specific documents. This is because this data is supporting data that is likely to change based upon time or system condition, instead of upon any direct user action associated within the process.
• Analytics. Over and above the need to have real-time views into related business systems will be the need to include analytics information within the logical view that an end user has of a specific process. This view could take the form of reports that describe information relevant to the business-process-instance, customer, or business unit over a period of time. The analytics information also could take the form of a scorecard displaying performance metrics relevant to the user. The information included within these analytics typically will be surfaced out of outside enterprise data sources, so the collaboration layer should bring with it the capability to include analytical information from elsewhere in the enterprise.

The collaboration layer stood up as the layer that was, again, somewhat tied to user experience. In this layer, the "experience" is not as visually obvious as in the presentation layer, but directly affects experience through its ability to provide guidance, oversight, and insights—all without being perceived as making life more difficult. As a customer expressed recently, "Collaboration usually sounds like 'red tape' for end users. MOSS succeeds, because it's perceived as easier by our workers."

Microsoft BizTalk Server

While the collaboration and presentation layers exist to support end users working effectively with the context of business processes, the integration layer exists to allow the business to abstract and manage the specifics of interfacing with other enterprise application systems. This layer adds value specifically through managing the complexity of system integration, through providing a well-connected reusable platform for interfacing with different systems, and through providing the capability for business-level monitoring of these interactions.

• Abstraction—Microsoft BizTalk Server provides a single model of architecture that will span processes and customers. It also acts as a layer of abstraction between collaborative processing and the back-end systems that support and will be affected by these processes. This layer of abstraction allows business to identify touch points with the affected systems, as well as the opportunity to shield the end-user environment from any complexities that might be inherent in the back-end system.
• Service-capable—As a business surfaces additional processes from the back-end systems into their end-user environment, they likely will want to leverage assets they already have in place. In this way, the integration layer should be capable of providing a service veneer over existing systems. The integration layer also should embrace and support the concept of multisystem integration. That is, this layer should not be tied to any specific underlying technology provider, as integration needs likely will span outside the domain of that single provider.
• Well-connected—If the integration layer is more complex to interface with than the systems around it, the value of that layer should be suspect. As such, BizTalk Server supports a variety of incoming and outgoing communication protocols. Among these are Web services, as well as common file-transfer formats and transports. In addition to basic communication capabilities, BizTalk Server has the concept of an adapter ecosystem by which it can connect into business systems without the need to resort to transport-level programming. This well-connected aspect of the BizTalk Server goes to establishing this "extra" layer as bringing additional flexibility and reducing overall time to value for your application system.
• Business-activity monitoring (BAM)—As a business process is flowing, the collaboration layer likely might want to display health and performance information for the process. This might be in relation to other process instances, or might just be a display of performance metrics for a specific instance. Either way, this information likely will need to span all the way from looking at specific user interactions and values down to information about the exchanges with various back-end systems. As such, BizTalk Server has the capability to provide BAM.

Conclusion

As we moved into defining a solution architecture to meet the needs described previously, several base concepts became clearer:

• Business processes rely upon strong collaboration. Perhaps this one should have been obvious; but, in working through business processes, it quickly became clear that these were describing collaborative processes. Each would vary in the specific roles, phases, and amount of improvised flow, but all involved the basic idea of interuser, intersystem collaboration.
• No single user experience will be correct. Within a single solution space, different users will have different needs for presentation of information, process, and analysis. To meet this need, this solution adopts a presentation layer that would allow enterprises to create and modify new user experiences quickly.
• Every solution will require its own business process. For this architecture to support multiple, unique business processes, it would need to have strong collaborative process definition and management capabilities. In short, it must provide a basic implementation with the mind-set that every single customer will alter that process to meet their specific needs for that specific business process.
• Every customer will have unique, likely complex, integration needs. While the initial working environment was based upon SAP, each customer will have unique assets for integration. These differences could extend from different customer preferences for integration protocol for integration with SAP, to customer desires to interface with a different LOB systems, to customer requirements to interface with homegrown legacy applications. The clear need was that this architecture needed to have strong support for integration with customer ERP systems, but needed to provide an equally strong means to integrate with other enterprise application systems.

This RAP provides a basic reference for solving price-management challenges. However, more broadly, the solution highlights a very capable platform that is appropriate for use in solving a wide variety of business challenges around LOB augmentation and integration.

References

• Preslan, Laura, and Ranjit Singh. "The Pricing Myths that Could Be Holding Back Your Profit." Deloitte Consulting LLP Web site. Deloitte Development LLC, 2006.
• "The Pricing Odyssey," as presented at the Professional Pricing Society by Deloitte Consulting, October 6, 2006.