Joseph Fultz, Technology Architect
Microsoft Technology Center—Austin
Michael Riley, Technology Architect
Microsoft Technology Center—Austin
Moin Moinuddin, Industry Architect
Laura Preslan, Industry Manager
Ellen Terry, Architect
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
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.
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:
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
|Process issues||Technology issues|
|Belief that companies are powerless to affect prices||Lack of access to current price lists and discount structures|
|Sales-incentive structures that reward revenue over margin||Specialized packaged or custom tools with weak user interfaces and poor workflow|
|Convoluted and chaotic approval workflow that slows down the process dramatically||Stand-alone pricing tools that require information to be reentered in multiple systems|
|Customer segmentation strategies based on trade class instead of buying characteristics||Use of inflexible ERP tools that cannot handle complicated pricing rules required|
|Limited understanding of the value of products and services||No analytic capabilities to review and compare deals|
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:
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.
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.
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.
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.
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.
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:
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.
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.
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.
In defining a solution to these challenges, there were several assets that were accepted as solution constraints. These included:
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:
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:
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.
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.
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.
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.
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
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.
This revised process delivers improved user experiences for all participants and provides organizational benefits, as follows:
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)
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 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:
Other strengths of MOSS that biased the decision in its favor are:
Specifically, MOSS brought to bear capabilities that include:
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."
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.
As we moved into defining a solution architecture to meet the needs described previously, several base concepts became clearer:
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.