Patent Application
20090070167
1. Field of the Invention
The invention generally relates to the field of enterprise resource planning, particularly to the assessment of cost of goods manufactured, and, more specifically to a technique of deriving cost estimates for given scenarios based on standard cost estimates.
2. Description of the Related Art
Enterprise resource planning systems are used for unified integration of all data and processes of an organization. Typically, an enterprise resource planning system uses multiple components of computer software and hardware to achieve the integration. One important software module is a unified database to store data for the various system modules. Depending on the size of the systems, data modules and system modules may be both physically and logically distributed. Physical distribution means that the components are spread over different hardware (e.g. servers) whereas logical distribution describes a functional separation of software modules which may be implemented on the same hardware platform. The term “modules”, as referred to herein, means software capable of running on a hardware platform. Modules are define by function and need not be a single file set at code or running on single hardware platform. For example, a module can be a single executable file, multiple executable files or portion of a single or multiple executable files. All of the functions described herein can be implemented as modules.
Enterprise resource planning systems used to be implanted only in the manufacturing environment, but today they are used in a much broader scope, i.e. covering all basic functions of an organization, regardless of the organization's business character. Generally, the benefit of an enterprise resource planning system is to replace two or more independent applications eliminating the need for external interfaces previously required between systems, and providing additional benefits ranging from standardization and lower maintenance (one system instead of two or more) to easier and/or greater reporting capabilities as all data is typically kept in one database with only one well defined interface.
The term “costing” describes the process of identifying the costs of the business and of breaking them down and relating them to the various activities of the organization. In order to determine the factory costs for a given product, typically cost estimates are developed at all stages of a product development and product production cycle based on a plurality of scenarios describing characteristics such as potential future variations of schedule, production site, technology, suppliers, subcontractors, tariffs, prices etc. In other words, costing is a process which requires analysis, simulation, and optimization of future production cost.
The analysis phase covers identifying characteristics such as all raw materials, preliminary products and production passes necessary to manufacture the final of finished product. In the simulation phase the influence of technical alternatives, increasing product and project complexity and innovation management is examined including the evaluation of economic alternatives such as the trade-off between make or buy, the production site selection, the supplier selection and the target date for the start of the production.
Finally, in the optimization phase the processing of data obtained in the simulation phase is structured in a beneficial manner, usually to minimize the overall cost.
Though these steps could be performed by spreadsheet calculation (or in simple cases even manually) it is evident that in order to increase efficiency, the costing of complex products require structuring, standardization, versioning, automated quality testing, audit proof archiving and incorporation of different calculations.
The costing process is subjected to market trends such as cost pressure and risk dislocation requiring a design to cost or target cost calculation or defined usage of standardized parts.
If a high proliferation of options is important, costing includes variant management for simulation of technical alternatives such as product structures, production and processes. If, however, an increased outsourcing is desired, variant management for simulating economical alternatives with respect to the selection of suppliers and determination of the right place and time is required.
Product globalization has to be budgeted by a cost, process analysis, product- and project controlling and a deliberate investment management. Finally, increased differentiation requires innovation management and a benchmark with function costs analysis. In Summary, costing captures various trends by means of methodical expertise resulting in a combination of technical and economical perspectives by identification of the specific cost drivers, the defined usage of standardized parts and a lifetime simulation.
As a module of the enterprise resource planning system, this costing module is often highly communicative with other modules and the user of the system to provide cost transparency for a flexible reporting system. For example if a customer requests a quotation for a certain product from a supplier expecting a pricing of the quotation based on the requirements stated either in the quotation or by reference to known industry standards, the costing module must collect various data. The supplier starts with a decision whether or not the product meets the given requirements. If this decision is positive, the supplier either imports an existing calculation of a bill of materials or creates a new product structure. Now the supplier initiates and internal optimization process by iteratively adapting the calculate towards the cost target. This phase includes the identification of cost reduction potential, costed evaluation of technical alternatives, suppliers and site selection. Ideally, the supplier meets the cost target and starts the production after signing the contract with the customer. One should note that depending on the type of industry, the unilateral calculation towards the cost target could also include the cost consideration of the entire value chain, integrating suppliers and customers, e.g. by aiming at stronger negotiation positions when purchasing raw materials or by balancing product cost versus cost in use.
While optimizing the cost relevant parameters in order to meet the cost target, a multitude of possible production scenarios should be considered: A simulation might for instance suggest to postpone the start of production (e.g. when a drastic decrease in purchase price for product parts is to be expected in the future). Usually, production costs can vary considerably among different production sites, the simulation should be able to calculate these differences and utilize them for the compilation of best and worst case scenarios. The same holds for the evaluation of alternatives in production technology.
The cost of a product crucially depends on the choice of suppliers for purchased parts and the availability of block pricing and rebates. The simulation should be able to weigh all these factors against each other automatically and suggest an optimal set of choices between alternatives. It is usually important that the various scenarios to be analyzed are managed separately from a standard cost estimate, i.e. it is desirable that the scenarios can be embodied in derived cost estimates.
Traditional costing approaches require a full cost estimate which has to be recursively calculated on a nested product structure for each scenario separately, resulting in a high computational complexity if a large number of scenarios are simulated on complicated products. This is especially the case if the required products are not based on raw material but also require a design and manufacturing cycle. The complex dependencies of a citing process cannot be easily tracked by means of static lists or simple spread-sheet calculation.
A first embodiment of the invention is a computer implemented method for automated processing of standard cost estimates comprising defining and storing a standard cost estimate indicating standard costs of a business activity, using a design pattern to encapsulate product characteristics, and deriving an updated standardized cost estimate indicating updated cost of the business activity based on the at least one change request.
A second embodiment of the invention is a computer readable medium comprising instructions for defining and storing a standard cost estimate indicating standard costs of a business activity, using a design pattern to encapsulate product characteristics, and deriving an updated standardized cost estimate indicating updated cost of the business activity based on the at least one change request.
A third embodiment of the invention is a system for automated processing of standard cost estimates comprising a device for defining and storing a standard cost estimate indicating standard costs of a business activity, a device for using a design pattern to encapsulate product characteristics, and a device for deriving an updated standardized cost estimate indicating updated cost of the business activity based on the at least one change request.
Reference will now be made in detail to the present preferred embodiments of the present invention, examples of which are illustrated in the attached drawing, wherein like reference numerals refer to like elements throughout.
Embodiments of the present invention by provide an interface to an enterprise resource planning system in order to simplify analysis, simulation and optimization of the costing process of a product. In one example, a computer implemented method for automated processing of standard cost estimates comprises defining and storing a standard cost estimate, using a design pattern to encapsulate product characteristics for defining one or many change requests, modifying the standardized cost estimate and deriving an updated standardized cost estimate based on the change requests.
An important distinction can be made between manual updates of standard cost estimates based on reliable data on the one hand, and the formulation of change requests to these estimates depending on possible production scenarios and based on assumptions of varying reliability on the other hand. The following procedure has been devised in order to keep track of the manual updates as well as the management of change requests. The method enables repeated, automatic, and selective application of change requests to an evolving standard cost estimate.
As illustrated in
Costing is a recurring operation of enterprise resource planning which is an attempt to integrate all data and processes of an organization into a unified system. Typically an enterprise resource planning system consists of multiple components of computer software and hardware to achieve the integration. In an industrial environment the cost for a finished product is usually determined by the sum of the raw materials needed for manufacturing this particular product plus a number of additional dependent cost factors such human resources and tools needed for the manufacturing process. Naturally an enterprise seeks close to optimal operation conditions, namely full load of the machinery, modest workload of employees and maximization of the raw materials.
Typically process optimization can be archived by iterative updates of table-like data, with the aid of spread sheet calculation such as Microsoft EXCEL, for example. Spread sheet calculation programs allows implement action of dependencies by means of programming—either graphical user interface based, or command driven—as long the items of interest can be represented by numbers, or a limited vocabulary and simple conditional dependencies known from basic programming language, such as IF-THEN-ELSE statements. On the other hand, object oriented programming languages such as C#, JAVA, C++ or PHP allow more sophisticated implementation of rules and dependencies—at the expense of higher complexity and the need for adaptation to the specific optimization goal.
The preferred embodiment of the present invention makes use of design patterns known from software engineering generally describing a repeatable solution to a commonly occurring problem in software design. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Computer science differentiates between fundamental patterns, creational patterns, structural patterns, concurrency patterns and behavioral patterns. The latter are used to identify common communication patterns between objects. Several implementations are known from literature. Interpreter patterns implement a specialized computer language in order to solve a specific set of problems. Specification patterns are used to implement recombinable business logic in a Boolean fashion whereas strategy patterns allow selection of algorithms on the fly. Especially in message driven systems like operating systems, Observer patterns are used for publishing or subscribing to event listeners where objects register to observe an event which may be raised by another object.
Yet another design pattern is the command pattern which allows encapsulation of a request as an object, thereby letting a user parameterize clients with different requests, queue or log requests, and support external operations. In other words, command pattern implements commands as objects and are typically used for implementing transactional behavior, thread pools or macro recording. It is also possible to send serialized command objects across the network to be executed on other computers.
More precisely, instead of processing a command as simple text a command class is generated which actually contains the actual command as a parameter. This approach is advantageous because the object can inherit properties from other objects. One of the standard properties of objects generated using object oriented programming language is serialization which allows storing an object as binary data to a data storage or transmitting the data across a network.
These properties are leveraged in the preferred embodiment to achieve novel and unexpected results. used by the present application in a beneficial way: Command objects may store complex rules which can be applied by simple execution of the object carrying these rules simplifying the analysis of complex scenarios. Common behaviors are identified and packaged in reusable libraries and frameworks. In particular, large applications benefit by avoiding duplicate code which is difficult to maintain.
From a developers perspective, command patterns effectively separate the execution of a command 303, i.e. an abstract base class for all command objects from its invoker 302. The invoker itself does not need to know anything about the command at all except that it is required to implement the Execute method. Any concrete command 305 which is any number of classes derived from the command class 303 can be implemented as a single object with an Execute method that implements its behavior.
In one embodiment of the present invention the Microsoft NET framework is used to implement the command pattern adapted to the problem of costing. So the invoker may be implemented either as a Windows Service Application or as stand-alone application. Service applications have the advantage of automatic startup at boot time of the operating system. An invoker service can be stopped while commands build up in the queue. Once the service is restarted is continues with the next command in a queue.
In order to accomplish scalability in complex systems, a distributed command architecture using a dispatcher concept may be used: The dispatcher serves as virtual service endpoint, optionally with a load-balanced queue behind it. Note that the dispatcher might be implemented to accept commands from remote systems by means of remote procedure calls. A remote procedure call is a popular model for implementing distributed client-server computing environments. As suggested by its name, this approach to concurrency works as follows: A process requests another process to do work by executing a remote procedure call, using a well-defined interface for the service to be performed. The processor executing the remote procedure call starts a process to service the request, which performs the desired work, returns the result, and finally terminates.
Yet another class ChangeDescription 407 implements AddProductCommand( ) and ApplyChanges( ), and can contain a multitude of objects of classes ProductCommand 408. By means of inheritance, the classes ChangeWorkTime 409 and ChangePrice 410 are defined as (exemplary) specialized ProductCommands which can be utilized by class ChangeDescription to describe the changes of the calculation parameters work time or price, respectively.
Upon invocation of the Calculate method 501G of the BaseCalculation 502 class, a CalculateAllSubparts( ) 503A method is executed resulting in a Calcutate( ) 504B action of the Worker X class In step 506 the actual cost is derived by multiplying cost rate by the required work time set in step 501D and 501E respectively.
In summary, a product (a detailed description of the production of a concrete product) implements an interface that allows for modification of cost relevant parameters like WorkTime and Price. The ChangeDescription employs command objects like ChangeWorkTime and ChangePrice for storing changes on those parameters for products in general.
The DerivedCalculation object triggers the execution of the commands stored in a ChangeDescription on a concrete Product. The result is a DerivedProduct which can be calculated by the DerivedCalculation automatically using the changed parameters.
The whole process runs automatically, the user only initiates it by requesting a derived calculation of a product.
Applying this to a risk analysis scenario, the user would define the costing adopting basic conditions which will be stored as standardized cost estimate. In order to obtain costing for the best and worst case scenario in a conventional approach the user would have to compile several different calculations, since it might not be obvious which combination of cost relevant parameters is optimal. For instance, Supplier A may be cheaper for part X and more expensive for part Y compared to Supplier B, but for reasons of rebates and block prices it might be necessary to choose either A or B for both X and Y. Now this choice depends on how many X-parts and Y-parts are needed, which might in turn depend on technology issues and be a cost relevant parameter as well. In short, cost relevant parameters might interact, and it is useful to be able to handle (many) derived calculations automatically.
The method disclosed by this application would automatically process best and worst case costing based on Rules and properties of each product involved in the production process. Related to the given example, this would include rules for price changes, such as general advances in prices, as well as position changes, such as discontinuation of positions or adding new positions. It allows one to create many different derived calculations by means of combination of different change descriptions.
The functions described herein can be accomplished by any computer or computer system programmed in a known manner. The various modules can be executed on a single computer or processor or distributed over various computers or processors.
Although the present invention has been described herein in considerable detail with reference to particular exemplary embodiments, certain modifications or alterations may be apparent to those skilled in the art, without departing from the scope of the invention. The exemplary embodiments are meant to be illustrative, not limiting the scope of the invention, which is defined the following claims.
