Patent Application
20050144033
Not Applicable
Not Applicable
Not Applicable
The field of invention is in information technology based systems that manage core business activities specifically those business activities that are complex in nature.
Most e-commerce transactions are simple in nature. For example, the retailer to consumer business process is a direct sequence of events; browse a catalog, make a selection, make a payment using a credit card and deliver the purchased product. The entire transaction is completed with a single interaction between the seller and the buyer. This type of transaction does not reflect the complex nested transactions of many of today's commercial transactions. Transactions in the business world are often long lived propositions, involving: negotiations, commitments, contracts, floating exchange rates or other complex financial derivatives, shipping and logistics, tracking, varied payment instruments, exception handling and termination or satisfaction. Each of these stages may cycle multiple times with prior transactions impacting present transactions and present transactions creating additional commitments for future transactions.
In a joint white paper of the Object Management Group and CommerceNet, Gabriel Gross, President of Centre Internet European, summarized the current state of electronic commerce applications as
Mainly limited to two functionalities: cataloging on one side and payment facilities on the other side. The current electronic commerce world is in practice a lot less sophisticated than real world commerce where several levels of interaction can take place between potential client and vendor, and several levels of intermediaries can act or interfere.
At a basic level, commercial transactions have two phases:
Ideally an information technology system will integrate other aspects of a business into the transaction process. This integration will allow for optimization of business processes. The integration of physical capabilities will allow for maximum resource utilization. Integration of financial data will allow for maximization of revenue. The greatest potential gain comes from the combined integration of contracting, physical capabilities and financials to allow optimization according to marginal costs. Through a marginal costing approach a business can maximize net income.
Enterprise systems must also address the world of multi-seller, multi-buyer commerce. This requires building information systems capable of handling/processing simultaneous requests from multiple users. Inherent to this disclosed system is a request scheduling process, which prioritizes, queues and processes the requests of multiple users.
In addition, a complex transaction or business process requires management of many dynamic roles: customer (the one who pays), consumer (the one who receives), merchant (the one who gets paid) and provider (the one who delivers). Additional sub-roles also exist, including: brokers, aggregators, referral services and other forms of intermediation. Additional supporting roles exist, including: bankers, credit providers, shippers, insurers and other third parties. Each of these roles imposes requirements on the Enterprise System.
The underlying data sources must be accessible to meet the different information needs of each role and procedure. This disclosed system maintains data at the minimal level of granularity required by any system, subsystem or role. This level of granularity ensures that no data are lost by a roll-up process. While stored at a granular level the data must possess the structural information needed to reassemble the data into any required format. Again this disclosed system allows for the summation and efficient handling of the granular data.
Enterprise systems require the inter-operation of computer applications, which depend upon consistent protocols and formats for information exchange. The complexity of building such virtual marketplaces mandates a computing paradigm based on standards. Otherwise inter-operability is impossible. The ultimate purpose of these standards is to develop consistent business semantics used by all participants—a common language of digital commerce. The extent of today's solution is to provide commonality to the names and relationships of processes, workflows, and data across all value and supply chains. This commonality is often provided through direct mapping of fields and/or translation tables.
An example is the new standard for defining and naming data on a Web page adopted by the World Wide Web Consortium (W3C) in 1997. The Extensible Markup Language (XML) allows structured data—with standard names and consistent semantics—to be moved around the Web in a simple, straightforward manner. XML is, however, little more than the reintroduction of the “unit record concept” introduced with the punch card in the 1950s. These cards stored chunks of data (fields) that were tagged with names giving them attribute/value pairs bound together as a standalone document (record). In other words, XML is simple text data (ASCII) and must be linked to an underlying infrastructure in order to handle the adaptive business processes and workflows needed for e-commerce. The most difficult aspect of inter-operability is to gain global agreement and definition of the underlying processes and procedures—an effort that has eluded information systems designers since the introduction of centralized databases. Thus, XML enables the use of the consistent business semantics but does not provide for the complex processes or functions. The disclosed system goes beyond simply creating a uniform naming structure. This system provides a structure for defining the entire process that lies on top of the data structure.
Without consistent business semantics, the business processes and workflows cannot be shared between multiple organizations or even inter-company departments. However, even with consistent semantics the task knowledge needed for such activity, adaptive business processes and workflows, overwhelms current software paradigms. A proposed solution is the use of intelligent agent technology, which is based on task level knowledge and knowledge sharing standards [such as a simplified version of the Knowledge Interchange Format (KIF)]. Today's intelligent agent technology is still in its infancy and, therefore, cannot approach the knowledge base required to prepare transactions. This disclosed system provides for a basic transaction language to describe the complex transactions and processes. The language focuses on supporting human decision makers not replacing them.
Enterprise computing seeks to consolidate and harmonize the many disparate information systems and data sources scattered throughout an enterprise into a unified whole. The goal is to streamline business processes and enable outward-facing information systems. The attention given to enterprise computing in recent years is a result of the business process re-engineering revolution, which was enabled by information technologies such as client/server computing. Through some hard learned lessons, corporations now know that it is insufficient to wire together machines through a network using a client/server architecture. A coherent information model and technology architecture was missing from this structure.
The disclosed system provides the much needed solution. Rights and engines define the core of this system. The Rights maintain subsystems and roles, at the most granular level required by any business system. The engines are responsible for the exercise of these Rights. Maintaining sufficient granularity ensures the integrity and availability of all system data. In other words, the core of this system prevents the loss of data by storing all data centrally in one usable format. These core Rights are subsequently developed into hierarchical structures. The hierarchical structures may involve tiering relationships within and between the Rights. These tiered hierarchical structures allow the creation of complex transactions and processes.
Object oriented computing is touted as the solution for managing the ever-growing complexity inherent in computing solutions. Objects are chunks of software that reflect real things in the real world: customers, employees, orders, shipments, and so on. Objects combine their processes and their data into a single entity in such a way that the integrity of the object is ensured by the object itself. This is in contrast to the relational database model typical of client/server architectures, where data is isolated from the processes that manipulate it. Such processes may be scattered across an organization resulting in integrity and complexity problems when they are integrated. Companies that tried to link the relational databases with the processes that use them created incomprehensible spaghetti architectures. These spaghetti architectures failed to create a unified enterprise information infrastructure. The structured products approach maintains the data in its most granular form. Therefore, data is exposed to all systems and the web of interconnected data sources is avoided. Each organization or business area is subsequently responsible for the reconstruction of the data to produce their required view of the business.
The next evolution in object oriented design, distributed object computing, is recognized as the future for building enterprise information architectures. Objects communicate to one another, to users and other systems by presenting interfaces with their services. To ask an object to perform a task, the object is sent a message requesting a service. In essence, using objects to build information systems is like building a simulation that includes the representation of people, places, things and events, which are found in the business setting or domain. Four key advantages result:
Distributed object computing has evolved rapidly over the past five years. Early uses of this computing paradigm dealt with system or “technology” objects. A printer is a simple technology object. A programmer no longer needs to “program” a printer. Instead the programmer sends the printer object a message to request the object take care of printing the current document. Traditional procedural programming required that programmers know all about programming printers, carefully writing each instruction to handle line feeds, tabbing and so on.
While technology objects simplify coding, they do not address the business applications or business semantics. The object-oriented solution created of a higher level of abstraction allowing information system developers to work with objects representing business entities and processes. At this level of abstraction, powerful business information models were designed with object-oriented concepts. These business objects handled the tasks of business processes and activities while suppressing the details of the underlying objects. The details were needed, of course, but the internals of the business object managed theses matters by sending appropriate messages to the underlying objects. While at an abstract level the use of objects to manage business processes is both appealing and practical, implementation problems exist. In an enterprise system the underlying data and the corresponding processes are frequently used across the entire system. This requires the exposure of the process and underlying data which is exactly what true object oriented design attempts to prevent. The disclosed system presents a unique combination of business objects with exercise engines and data structures. While the exercise engines control the processes, the granular data structure ensures data availability across business units. The business objects are built upon these shared structures.
The “Holy Grail” of enterprise systems is to allow the business user to define, manage and maintain the business functions. Thus, control of the implemented business processes is returned from the realm of the corporate information technology department to the domain of the business user. In this regard, Common Object Request Broker Architecture (CORBA) made system and technology inter-operations available, and many mission critical business systems and applications have been developed. The interface definition language (IDL) specification allows programmers to write and publish interfaces that are used by objects anywhere. To date, however, developers must still master a mix of business object semantics and the underlying technology objects, which require low-level plumbing, in order to build complete business solutions. A business object component model that suppresses the complexity of the underlying systems technology is needed to provide a clear separation of concerns. With such a system, business solution developers can assemble and tailor pre-built business components into complete solutions.
Technologists are component assemblers and deal with the complexity of the underlying information systems and technology infrastructure. Computer specialists are the tool-smiths for building reusable components. Because business objects provide the abstractions needed for building high-level components that inter-operate, business solution developers are able to assemble applications using business constructs and semantics that insulate them from the underlying complexity. The ultimate language of application development will be the “language of business,” not “the language of computers”, and eventually business users will develop their own information systems solutions to business problems. Only when the business user can accomplish the tasks originally in the domain of the computer specialist, can the goal of a truly agile business be realized. The disclosed system creates the structures necessary to minimize the services of a computer specialist. Business strategies identified by the business users can be implemented on an enterprise wide scale using this disclosed system.
The component paradigm has changed “programming.” Application programmers who made up the bulk of commercial information technology shops are being replaced by technologists assembling components. The components are not delivered to corporations as a big pile of parts and pieces. Instead the components arrive pre-assembled into industry specific application frameworks. These frameworks represent applications that are nearly complete. The task of solutions developers will be to customize the components of the frameworks to meet the unique needs of the specific company.
Solution developers will concentrate on the unique character and knowledge of the company, which accounts for the company's competitive advantage. The extension and tailoring of components will focus on the user interfaces and will involve both graphical and task-centered customization. In the long run, corporations will no longer need to waste resources designing their own applications. Instead, they will buy component-based enterprise application packages. These packages, however, will not be the complex, confusing packages available in the current market. Instead, the framework of these packages will be based on distributed object architectures, allowing for individual components to be mixed and matched regardless of the individual software vendor. The disclosed system is such a framework. But rather than an ancillary function of merging different systems, the disclosed framework represents the core of the business to which the other components are attached. Only with a granular data structure and the necessary exercise engines can the component approach be implemented in a flexible fashion. The disclosed system is specifically tailored to the forecast, sales, contracting, supply chain and settlement process that are at the foundation of any business.
SAP and other enterprise resource planning (ERP) vendors are aggressively implanting their software based on case studies into business (not computer science) curriculums at both the graduate and undergraduate levels. This will result in business graduates who can build information systems from frameworks. The programmer as “translator” between the business and the digital domain will fade into history. However, the true benefits of component assembly will not be realized without the disclosed structured products approach providing the framework to which the components may be attached.
In one aspect, the disclosed system serves as a development language for business users. CommerceNet is working on a Common Business Language (CBL) to blend e-commerce components into their evolving eCo System architecture. Other high level tools, such as VisualAge for Java, serve as component assemblers that suppress the details and complexity of the underlying technologies and systems. Basic, Pascal and similar high-level languages were created to hide the complexity of machine code. The novelty in the structured products system is that the language of the business user is used to create the business functions. The disclosed system lies between the abstract level of CommerceNet and higher-level languages. This business user accessibility allows for the creation of truly agile business solutions.
The basis of the disclosed system is the process of disassembling a service into its individual atomic Rights. These Rights are then defined and assembled within the system to create mass customized services. At the most basic level, the Rights specify a unique collection of parameters. Thus, the user is not tied to any database type structure and the Rights are amorphous.
An additional feature of the disclosed invention is the exposure of the Right parameters to the business user. The parameters are accessible and, therefore, allow Rights to be configured as a typical business user builds them into services.
Another novel feature of the disclosed system allows for the Rights to be associated into complex structures, such that they depend upon other Rights or services. This allows for both Rights and services to be inter-related. This results in one Right or service having the ability to affect others, depending upon the actual utilization of the Right or service adopted by the customer.
Furthermore, each Right can be associated with other objects or parameter groups, including: scheduling priority, pricing, marginal cost, and actual cost. These additional structures enable the seller to configure management systems for the services he provides.
Another novel feature of the disclosed system is that the pricing object associated with a Right is modeled as an option. Option pricing format allows a base charge for actually having the Right/Service and an incremental charge for the utilization of the Right/Service.
Another novel feature is the system's capacity to manage products in the service industry. The use of the term Service to represent an assembly of Rights was intentionally used to accent the applicability of the system to all industries, including; those that sell tangibles and intangibles.
Additionally, the disclosed system allows for the entire scheduling system to be changed by simply modifying the scheduling priorities of each Right. This can be done without writing any additional code, a revolutionary feature of this system. During Right definition and service creation each Right is assigned a scheduling value. After a Right has been utilized in a given circumstance (exercised), a scheduling value is automatically read from each Right. For the Rights exercised, scheduling values are subsequently summed to determine the scheduling priority of the individual service. The scheduling of the actual services is achieved by sorting the totaled scheduling priorities. Thus, scheduling is simply a number map schema of all of the scheduling priorities and their summation under different conditions.
Other aspects and advantages of the present invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings illustrating by way of example the principles of the present invention.
There are many different types of Rights, including: scheduling, pricing, transportation, transformation and storage. Each of these Rights represents an elemental business function. As shown in
Code elements define the way in which a Right is processed by the system. In particular, the code element covers unique processing requirements of the specific type of Right. For example, certain aspects related to the processing of a transportation Right will obviously differ from a transformation Right. The processing is independent of any particular value input for the name value pair. The code should use these name value pairs in a fashion similar to variable declarations where the code processes regardless of the actual values.
Code elements are created in many ways. The simplest is to directly hard code the functioning of the Right. This approach benefits from simplicity and rapid processing speeds. However, hard code is inflexible and requires an experienced software engineer to develop. Typically, the software engineer does not have the necessary business domain knowledge and, thus, requires the translation of business knowledge by a domain expert. An alternative is to “code” the business logic using a natural language system, which allows the business user to input domain knowledge in the language of the business user. This generally results in slower processing speeds since the system is now responsible for the translation. The actual approach will depend on the system requirements and will probably be a synthesis of both approaches.
In addition to the Demand and Commodity component, a group of parameters similar to these elements are attached directly to the Right. This Parameter group allows for the combination of Demand and Commodity limits. It can also be used to price additional elements of a Right. For example, in the gas transport industry the basic transportation Right is charged a Demand, a Commodity and a fuel usage fee. The currency used to pay the fuel fee is not necessarily a dollar denominated figure. As in options trading, payment is frequently made in-kind, (i.e. the payment is made in the commodity traded).
Operation of Invention
The basis of the Rights Based System (RBS) is the process of decomposing services into core constituent Rights. These core constituent Rights are then recombined through the flexible Rights Based System such that any service can be managed. This general system overview is intended to show how the envisioned Rights Based System could operate. In this example there are nine primary elements, which cover the life cycle of the Right from Right definition through Right analysis as shown in
Service Decomposition
The first and critical aspect of the structured products based management process is to break the business processes into their core components. The accurate and complete definition of the core components is essential for the subsequent reassembly process to work properly and to be sufficiently flexible to accommodate variations within business processes. Many of these basic Rights are actually applicable across industries. Examples of Rights and their functional description are given in Table 1.
It is evident that with a set of fundamental Rights it is possible to address a variety of cross industry processes. While it is possible to address many processes with the already described set of Rights the inventors fully anticipate the need to create additional Rights that serve functions unique to an industry. Once created these become part of the tools available for subsequent system upgrades ad base functionality on new system installations.
Right Properties
At a fundamental level the Rights are composed of two elements: parameters and an optional code block (
The parameter values such as commodity of interest will tend to be highly industry specific. However, the fundamental processing of the parameters will transfer across industries. For example in the chemical processing industries the transformation Right may take unsaturated fats as input and produce saturated fats as an output. The from and to parameters would be unsaturated fats and saturated fats respectively. In the gas industry the transformation Right may take Liquefied Natural Gas (LNG) and convert this to pipeline grade gas. The from and to parameters now being LNG and pipeline gas. While the values of the parameters may be changing the processing remains the same. In a general sense product A goes to B (B=f(A)). Once processing for rate, time interval, multiple products or multiple starting materials is implemented, the actual transformation handled is mainly a matter of specifying the variables.
System flexibility is provided by the parameters and the potential to dynamically redefine and enhance parameter operation utilizing the configurable logic engine (
While the Rights can be constructed with an extensive parameter list the grouping of parameters and associated functions into logical subunits allows for simplified configuration.
The tiering object allows a single Right to have multiple values for a single or group of parameters that are dependent upon the condition or value of a parent parameter. Accounting for minutes on a typical cellular phone plan can be expressed in a tiered structure. For example a plan may allow 100 on peak and 500 off peak minutes. Minutes used in excess of the allowed minutes results in an incremental charge. There are several accounting rules that apply to the minutes. Off and on peak are accumulated at specified times during the day. After all off peak minutes have been used additional off peak minutes are accounted for as on peak. After all on peak minutes have been used additional on peak minutes are accounted for as charged minutes. To express the business logic in the preceding example requires separate tiers for the on peak, off peak and charged minutes. The applicable tier is based on the time at which the minutes are used. Thus the time window at which the call is placed is the parent. In addition several logical rules must be applied to redirect the system to the correct tier on the occasion that the airtime in a tier exceeds the specified level of minutes. Traversal of the tiered constructs requires the tier to maintain both its structural relationships and the logic rules dictating the type of call being placed.
The concept of time is also maintained by the parameters. In the Rights Based System time is a relative concept. There is no set definition of time, nor is there any time periods which the process is built around. Everything is defined in terms of start time and end time. By defining time boundaries, industries that need second by second tracking can be accommodated along with industries that simply need hourly or daily tracking. Additionally, a combination of time granularities can be achieved within the same process. The recurrence/profile object or parameter group serves to neatly package more advanced timing concepts but still adheres to the original timing principle where no fixed clock cycle is set.
Recurrence covers the details of complex timing sequences. To deal with business processes that involve multiple transactions occurring over extended periods certain Rights are replicated over variable time durations at uniquely defined intervals. Recurrence is designed to easily express the periodicity of the fundamental Rights using a uniform process and set of parameters. The defined recurrence then facilitates the expansion of the Right with a recurrence pattern to multiple expressions of the Right each with the desired time parameters sufficiently detailed. The basic parameters in recurrence are the start time and end time. This start time and end time is further defined by a recurrence pattern. For example the Right to attend a college course associated with a scheduling application may have a recurrence object. The particular course may have a start time and end time of 10 and 11 respectively. The recurrence pattern may be M, W, and F and apply for the duration of the semester. The recurrent object and attendance Right thus express the student's Right to attend class.
The pricing object is the most complex object (
Additionally the pricing object allows for costing in terms of non-financial costs. The external interaction of companies is typically financial in nature but internal functions are often resource constrained vs. financially controlled. Tracking the non-financial costs is essential for any supply chain management function. It is also applicable to operations optimization. The options based pricing in conjunction with pricing based on resource utilization allows a company to fully address marginal costs, marginal revenues and decision making based on incremental modification versus management by the aggregate. Management in aggregate allows companies to maximize revenue but is does not allow for maximization of profit. Maximizing profit requires the separation of demand and commodity costs in addition the incremental impact of exercising a particular Right must also be calculated. Only then can a business be managed for maximal return.
Services:
Once the fundamental Rights of a business or business process have been defined, these Rights can be reassembled into services. Services are the unique combination of Rights that represent a product offering by a company. In one regard services are merely a placeholder for an aggregation of Rights. However, services are potentially more than a product offering. The Rights can be assembled to create other business functions. For example supply chain management can be expressed in a Rights based system. The performance of a particular supply chain function such as delivery of good G from location A to location B may require X, Y, and Z resources which when requested are expressed as Rights X, Y, and Z used to accomplish the movement of G.
Each time a product is sold, it could be assembled starting from the individual Rights. It is more expedient to preassemble these Rights into services. Unlike Rights which may be applicable across industries, services will be unique to an industry.
Once the service has been assembled it is immediately obvious that instantiation of an instance of a service will require the population of a significant number of Right parameters. In order to minimize the input required by the user especially for services that are frequently used the concept of a service template was conceived. Creation of a service template requires the identification of the “input” parameters. The input parameters are the essential parameters that define a service. These inputs are subsequently mapped to all the parameters of all the Rights on the service. The mapping function can use constants, simple math and logic functions to convert these inputs into populated Rights. The end result is the service template. Now the user can simply select a template, provide the input parameters and the result is a populated service. Within the concept of the service template is the utility to have optional Rights. Optional Rights are expressed as part of the mapping process and increase the flexibility of the templates. For example: If a service was generated whose only difference from an existing service was the existence or lack of a specific Right, this scenario could be managed with a single template and an optional Right.
Structured Products Usage
Contracting
Use of the structured products starts with the concept of contracting. In the structured products world contracting entails not just the contractual relationship between a buyer and seller of a good. Contracting also covers the complex relationship involved in service industries where the product supplied has a complex lifecycle or the fulfillment of a contract takes multiple actions by both the seller and purchaser. Additionally the contracts may cover internal company processes. Prime examples are supply chain and manufacturing production management.
Creation of a contract can take the form of instantiating a service template by supplying the input parameters, populating all the parameters under a service or assembling the Rights independently and then populating the parameters. Each contracting process requires an increasing level of knowledge about the business and Rights based operation.
During contracting the recurrence object may have been invoked on one or more Rights. Once the recurrence parameters are fully populated the Rights can be expanded according to the timing sequence defined in the recurrence. For example in an injection molding shop a contract was created for the production of 100 k injection molded pieces per day over the course of 6 months. The shop works Monday to Friday from 8 to 5. The Right for creation of the 100 k pieces per day would be duplicated to every weekday for the duration of the 6 month contract. For contracting we capture all the Right information within the recurrence, and it is not necessary to do the expansion for the expression of the contract. However, this level of granularity is required for utilization of the Rights. While not absolutely necessary we can keep the contract at the most granular level required by the business thus minimizing some of the system processing requirements.
After the contract has been fully expressed it is then possible to perform business using the contract. The contract and its Rights define what the customer can do or request and the required response of the company. Obviously the business being performed is completely dependent upon the industry; however, the basic Rights and the assembly process should traverse the industries. It is anticipated that several generic Right operation engines will be required. The first engine is a validation engine. Obviously when a request is received by the system, the request must be confirmed against available Rights to ensure that the request is valid. The incoming request is broken down into the same granularity that the contracted Rights are stored at. The request is then stored to the database with a status parameter indicating where the request is in the overall business process.
Upon validation of the Right the request will be passed to a scheduling engine. The scheduling engine prioritizes the incoming requests and creates a que for subsequent action. The prioritization algorithm can take many different forms. The primary factor is what variable(s) determine priority. Obviously the service provider will want to prioritize for maximal return while the purchaser will have certain prioritization benefits due to the type of service purchased. This engine potentially requires the storage and processing of a significant number of business rules. One alternative to a strictly business rules approach is to assign a priority to each contracted Right. To prioritize a request a summation of the priorities of the Rights to be exercised is executed. This sum determines the priority for action. The obvious benefit is the simplicity of action versus traversing actual business rules. In addition it is easier to change the priority of a Right (simply a Right parameter) as opposed to recoding fixed business rules.
Once the requests have been queued according to Right priority the service provider can optimize their operations to handle the requests. Since each request is a compilation of the atomistic operations, as expressed in the Rights, the service provider is able to truly see the impact for each operation. This level of detail allows for a more complete systems operation. Realistically, the quantity of data generated will exceed an operator's ability to efficiently process all of it. This necessitates a method to provide data summation or a method to automate the optimization process.
After the requests have been appropriately scheduled, the actions specified by the Rights are allowed to proceed. It should be noted that the Rights Based System would not necessarily carry out the activities. In most cases the actions will entail some physical process, which the system will only monitor. Once the actions have been completed the results of the actions are passed back into the RBS where they go to the settlement engine.
The settlement engine determines the final charge monetary or other for the actions. The engine will have to perform the following tasks. First the demand charge is calculated. The demand charge can actually be calculated at the time of contracting but the calculation is none he less processed by the settlement engine. Once actions are completed the system imports the results of the actions. The actions must first be associated to a particular contract. In most industries the allocation of an action to a contract is strait forward. However, some industries operate with shared capital resources and commodity products. Here the allocation can be more complex and the business rules must be coded into the settlement engine. Once the actions are assigned to a contract the commodity charges can be calculated. The pricing object allows for a very complex pricing scheme. While for basic cases only a demand and commodity charge is calculated, the more sophisticated pricing will require checking for minimums, maximums and inter Right dependencies. Additionally settlement will have to manage any unique pricing event such as penalties or overruns for non-compliance with contracted terms. Ideally the structured products system would prevent the customer from exercising Rights which they do not have. In reality many industries do not have the ability to fully control their operations, and they are forced to respond to customer actions after the fact. The result is that there is the potential requirement for some manual adjustment of the settlement process.
Portfolio Analysis
Portfolio analysis is one of the strengths of the Rights Based System. Since all the data is maintained at an atomistic level, the status of the entire business can be viewed according to the needs of the individual user. The “cube” as shown in
Once plotted the cube allows dynamic resizing of the X, Y, and Z axis scales such that the resolution of the data can be adjusted to the required granularity. For dimensions that are continuous such as electricity transported, it is a simple process to take a derivative of one dimension with respect to time or other parameter. This allows the system operators to identify swing events and transients which are the critical variables to manage in many industries. It also allows for forecasts based on business momentum. The portfolio analysis provided by the structured products system is far more flexible than what can be achieved with presently available online analytical processing tools (OLAP). The reason is that today's OLAP tools are placed on top of presently existing systems and are designed to integrate many different data sources and allow for their combined analysis. The Rights Based System starts with the database defined at an atomistic level of granularity. The primary business functions are managed through this database. Each stage of the business is represented as a status in the original database or a separate database still maintaining the low level granularity. The benefit for analysis is that all the data is readily available. The integration achieved by an OLAP often requires summation processes that obscure essential business details.
| Number | Date | Country | |
|---|---|---|---|
| 60533417 | Dec 2003 | US |
