Business software solutions for product cost controlling serve the purpose of providing a monetary valuation for processes residing in the logistics production area. Production entities like materials and production orders of finished products are assigned a monetary value along configured strategies and form a basis for complex calculations aimed at giving vital information on a production process' quality from a financial perspective.
Typically actual costs of production are compared with expected values from planning processes which are performed at defined discreet points in time. On a common calculation basis variances are calculated along defined characteristics which can be related to actual objects such as products, plants or production orders. An example of production cost analysis is this task of analyzing production processes along financial criteria.
While existing production cost analysis systems may be capable of aggregating and analyzing data on objects such as products, plants, or production orders, these capabilities may be limited. Organizations need to perform production cost analysis on a more granular level (i.e., on a level which provides more detailed information about the product or service being analyzed) in order to accurately allocate costs to production. However, existing production cost analysis systems cannot aggregate and analyze data on a more granular level due to the large amount of data and the necessity to access this data in real-time.
Accordingly, there is a need for a production cost analysis system which is capable of aggregating and analyzing data in real-time on more granular objects such as routing, operation, work center, cost center, component, and activity.
In the past, production cost analysis (“traditional production cost analysis”) was performed by storing data from the plant 100, product 105, and production order 110, aggregating this data by running summarization processes at the end of defined intervals such as a week or a month, and then finally analyzing the aggregated data. As part of the analysis, variance calculation may be performed on the aggregated data to assess the efficiency and accuracy on a plant 100, product 105, and production order 110 level.
The data had to be aggregated at defined time intervals due to 1) the large amount of data generated on a plant 100, product 105, and production order 110 level even for a medium sized company, and 2) the lack of technology to access such large amounts of data in real-time. Due to the large amounts of data involved and the necessity for aggregating the data at defined time intervals, it was not practical to store or access data at a more detailed and granular level. Specifically, it was not practical to store or access data pertaining to routing 115, operation 120, work center 125, cost center 130, component 135, and activity 140, since the amount of data at these levels was a multiple of the data generated on a plant 100, product 105, and production order 110 level.
As explained above, traditional production cost analysis only analyzes data pertaining to the top half 300 of
The limitations of traditional production cost analysis is due to traditional systems available for data storage. In traditional data storage systems, production data is usually split into two databases for performance reasons. Disk-based, row-oriented database systems are used for operational data and column-oriented databases are used for analytics (e.g. “sum of all sales in a company grouped by product”). While analytical databases are often kept in-memory, they can also be mixed with disk-based storage media.
Transactional data and analytical data are usually not stored in the same database:
analytical data is replicated in batch jobs and is stored in separate data warehouses. As a result, real-time reporting was not possible. However, in the last decade, hardware architectures have progressed dramatically. Multi-core architectures and the availability of large amounts of main memory at low costs have made it possible to store data sets of multiple companies in main memory. With in-memory database technology and hybrid databases using both row and column-oriented storage where appropriate, according to an embodiment of the present invention, transactional and analytical processing can be unified, resulting in performance that is orders of magnitude faster than traditional data storage systems.
With the advent of in-memory database technology, large amounts of data can be accessed and aggregated in real-time, therefore eliminating the need to aggregate data at defined time intervals. This in turn opens up new and improved ways to store, access, and analyze data. In-memory database technology includes systems such as SAP's HANA (high performance analytic appliance) in-memory computing engine.
In an embodiment, data pertaining to the lower half 310 of the production process in
Analyzing data at a more granular level and performing real-time analysis on them opens up a new area of analytical possibilities at the interface between production and financials. The real-time capability, along with the possibility of identifying the responsible entities for inefficiencies (from a financial perspective) will help companies to react extremely quickly and adapt production processes until the expected efficiency is reached.
Each of the systems in
In an embodiment, memory 513 may contain different components for retrieving, presenting, changing, and saving data. Memory 513 may include a variety of memory devices, for example, Dynamic Random Access Memory (DRAM), Static RAM (SRAM), flash memory, cache memory, and other memory devices. Additionally, for example, memory 513 and processing device(s) 512 may be distributed across several different computers that collectively comprise a system.
Database 511 may include any type of data storage adapted to searching and retrieval. The database 511 may include SAP database (SAP DB), Informix, Oracle, DB2, Sybase, and other such database systems. The database 511 may include SAP's HANA (high performance analytic appliance) in-memory computing engine and other such in-memory databases.
Processing device 512 may perform computation and control functions of a system and comprises a suitable central processing unit (CPU). Processing device 512 may comprise a single integrated circuit, such as a microprocessing device, or may comprise any suitable number of integrated circuit devices and/or circuit boards working in cooperation to accomplish the functions of a processing device. Processing device 512 may execute computer programs, such as object-oriented computer programs, within memory 513.
The foregoing description has been presented for purposes of illustration and description. It is not exhaustive and does not limit embodiments of the invention to the precise forms disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from the practicing embodiments consistent with the invention. For example, some of the described embodiments may include software and hardware, but some systems and methods consistent with the present invention may be implemented in software or hardware alone. Additionally, although aspects of the present invention are described as being stored in memory, this may include other computer readable media, such as secondary storage devices, for example, solid state drives, or DVD ROM; the Internet or other propagation medium; or other forms of RAM or ROM.