At least one primary goal of process pricing modeling is to construct models to capture objective data in order to analyze historical price behavior and current pricing portfolio, to create policies responsive to the analysis, and to predict and influence future price behavior. Systems like, for example SAP, attempt to manage and control business processes using objective data in order to gain enterprise efficiencies. By manipulating objective data, these systems offer consistent metrics upon which businesses may make informed decisions and policies regarding the viability and direction of their products and services. However, in many cases, the decisions and policies may be difficult to procure as a result of the volume and organization of relevant data and may be difficult to implement as both temporal restraints and approval processes may inhibit rapid deployment of valuable information.
For example, FIG. 1 is a simplified graphical representation of an enterprise pricing environment. Several example databases (104-120) are illustrated to represent the various sources of working data. These might include, for example, Trade Promotion Management (TPM) 104, Accounts Receivable (AR) 108, Price Master (PM) 112, Inventory Database 116, and Sales Database 120. The data in those repositories may be utilized on an ad hoc basis by Customer Relationship Management (CRM) 124, and Enterprise Resource Planning (ERP) 128 entities to produce pre and post sales transactions. The various connections 184 established between the repositories and the entities may supply information such as price lists as well as gather information such as invoices, rebates, etc.
The wealth of information contained in the various databases (104-120) however, is not “readable” by executive committees 140 due in part to accessibility and in part to volume. That is, even though the data in the various repositories may be related through a Relational Database management System (RDMS), the task of gathering data from disparate sources can be complex or impossible depending on the organization and integration of legacy systems upon which these systems may be created. In one instance, all of the various sources may be linked to a Data Warehouse 132 by various connections 144. Typically, the data from the various sources is simply aggregated to reduce it to a manageable or human comprehensive size. Thus, price lists may contain average prices over some selected temporal interval. In this manner, the data may be reduced. However, with data reduction, individual transactions may be lost. Additionally, the data from the various sources are different slices of pricing information in the time continuum or life cycle (i.e. commitment/forecast/projection vs. actual transactions). As a result, there is typically no integration or correlation between data from the various databases. For example, there is no correlation between sales data (e.g. projected/forecasted sales orders by specific customers for specific products) and the actual orders placed by customers against those sales orders for the specific products.
Analysts 136, on the other hand, may benefit from an aggregated data that unifies the pricing data across the time dimension from a data warehouse. Thus, an analyst 136 may compare average pricing across several regions within a desired temporal interval and then condense that analysis into a report to an executive committee. An executive committee may then, in turn, develop policies directed toward price structuring based on the analysis returned from an analyst 136. Those policies may then be returned to CRM 124 and ERP 128 entities to guide pricing activities via some communication channel 152 as determined by a particular enterprise.
As can be appreciated, a number of complexities may adversely affect this type of management process. First temporal setbacks exist at every step of the process. For example, a CRM 124 may make a sale. That sale may be entered into a Sales database 120, an Inventory database 116 and an AR database 108. The entry of that data may be automatic where sales occur at a network computer terminal, or may be entered in a weekly batch process. Anther example of a temporal setback is the time-lag introduced by batch processing data stored to a data warehouse resulting in weeks-old data that may or may not be timely for real-time decision support. A second setback is the lack of correlation between individual data from the various repositories. For example, sales projections generated by commitments from sales have not been correlated with the actual transactions or orders placed by customers. Consequently, pricing policies set by the executive committee 140 as well as proposals made by sales personnel have not been based on “accurate” business intelligence. As such, methods of correlating commitment data and transaction data into a unified database and making pricing decisions based thereupon may be desirable.
In view of the foregoing, methods of making pricing decisions in a price management system are disclosed.
USPTO Backgrounds
USPTO Backgrounds