a-d comprise process modeling diagrams of the present invention;
e describes the assembly of
A cost management system and method using an automated features-based system and process for analyzing costs of direct, made-to-order parts is described herein. More particularly, the system utilizes a software process that employs proprietary algorithms to analyze features of the target parts including their material, shape, as well as other characteristics and estimate what parts should cost to produce. By comparing the “should costs” with vendors' prices the system identifies cost saving opportunities.
The present embodiment utilizes information in CAD files and other drawings, analyzes key features and manufacturing characteristics of the selected components, and identifies cost relationships. It then uses these relationships to identify outliers such as, parts that appear to be unusually expensive compared with what the model predicts that they should cost. Such parts are further analyzed to determine if they are candidates for cost reduction.
As part of its analytical models, one embodiment performs four primary calculations. First, based on part features, materials, manufacturing processes, and purchasing demand volumes, the embodiment calculates a “should cost” price for each part. It identifies outliers by comparing the “should cost” with the vendor's quoted price. Unusually expensive parts are candidates to be bid on by purchasing professionals, and thereby reduce costs. Second, it identifies key factors called “cost drivers,” which contribute to part costs. These key factors can be used by the engineering staff to minimize cost in the design process. Third, an embodiment of the system identifies similar parts called “nearest neighbors.” Last, it analyzes the capabilities of the suppliers to identify their core capabilities and thereby determines which parts are most efficiently sourced by each respective supplier.
The embodiment uses a top-down approach that can analyze an enterprise-wide set of data on purchased direct materials, quickly identify “sweet spots” that have the most cost reduction potential, and provide direction on how to attain cost savings. An embodiment of this invention can be used to funnel large amounts of data through a tool that will accurately pinpoint the specific opportunities that will give the most impact and efficiency in reducing costs. As such, the invention serves as the next generation of cost management tools that work in conjunction with existing cost management methods to accurately identify specific parts that are candidates for cost reduction and to steer the process used to obtain cost savings.
This detailed description is presented in terms of programs, data structures or procedures executed on a computer or network of computers. The software programs implemented by the system may be written in languages such as Java, HTML, Python, or the R statistical language. However, one of skill in the art will appreciate that other languages may be used instead, or in combination with the foregoing.
For purposes of illustration, the invention relates to a system and software product directed to an analytical methodology for cost management of highly engineered made-to-order parts. In one embodiment, the system takes data from computer assisted drawings (CAD) files, engineering specifications files, demand data from Enterprise Resource Planning (ERP) systems, cost data from financial systems, and/or other electronic files and utilizes data mining algorithms to analyze part features, usage patterns, and engineering specifications to construct “should cost” curves across individual families of parts. Based on the should cost curves, the embodiment determine the significant cost drivers that affect the cost of the one or more target parts.
As best seen in
I. System Data Management Layer
In one embodiment of the system, the data management layer 120 consists of five parts. First, the system implements integration points that enable it to assimilate purchasing, financial, and part features information from the customer's internal systems. Within the integration points are data loading rules 175 the system uses as part of its data assimilation process. The reason for the data loading rules 175 is that each customer stores its parts purchasing and financial data using different formats. The data loading rules 175 aggregate data various customers and thereby enable the system to employ a business intelligence “should cost” database 165 that is reusable across customers.
The part features extraction process involves two types of information. The first type includes engineering specifications 115 that describe physical characteristics of the part. By processing these files the system can extract a set of physical features that describe the part. Examples of these features include material, e.g., which metal, height, width, and depth of the part, physical volume, number of cores, and characteristics of the drill holes. The second type of information involves machining specifications such as tolerances, smoothness, drill holes, drill hole volume, and parting line perimeter. There is a set of engineering specifications associated with each part. As a component of the feature extraction process, the system processes each specification and extracts relevant information for cost modeling.
Second, using the data loading rules 175, the system data loading tools transform, normalize and validate parts data as it is stored in the database 165. In one embodiment, the data loading rules 175 are written in the R statistical language.
Third, the system employs exception reports 160 that highlight unusual and suspect information. The reports, for example, identify unusually expensive parts or cheap parts, parts with missing weights, parts with no demand, suppliers, and many other characteristics of the data.
Fourth, the system analyzes 2D parts drawings and 3D engineering models of the parts and extracts features that are predictive of costs. In one embodiment, cost predictive features variables include financial information, purchasing information, and feature information. As best seen in TABLE 1, the features may involve part characteristics such as the volume of the part, which along with the density of the material, is used to calculate the part's weight, number of holes drilled into the part, type of drill used, number of cores, number of risers, surfaces, machine setups, and the like. One of ordinary skill in the art will appreciate that this table does not provide an exhaustive list, but is merely illustrative. The features characteristics are the primary drivers that enable the system's predictive models to achieve high accuracy.
The fifth part of the system's data management layer is the database 165. In one embodiment, the system organizes parts data using snowflake schema data warehouse model with fact tables for parts and suppliers. An embodiment of the snowflake database schema is shown in
It should be appreciated that part of this invention relates to choices of variables which may be loaded and data loading rules 175 used to process the data. There are many possible features that can be extracted from CAD data and many possible purchasing and demand variables. One aspect of the invention is the selection of variables and modeling techniques that are predictive of cost.
1. Data Management Architecture
At the architectural level, one embodiment of the system performs data management functions using a four-step process, as best seen in
First, in one embodiment, the system extracts the data from the customer delivered formats and loads the files into memory. Next, the system aggregates, categorizes and filters the data based on customer defined rules. At this point, the system performs extreme value elimination by applying the data loading rules 175 and looking for extreme statistical values. The parts associated with the extreme values are eliminated from the data set under consideration. The system then takes the data from step 2 and loads it into database 165 for analysis. If a part is excluded from loading, the system will generate exception reports 160 which provide the user with information on any data load failures or exceptions. Once the data is properly loaded into the database 165, the analytics layer 120 performs model fitting algorithm analysis.
II. Analytics Layer
The second layer of the system's architecture is the analytics layer 125. This analytics layer 125 consists of a series of statistical routines that, in one embodiment, are implemented using the R Statistical Language. Further, this analytics layer 125 in the disclosed embodiment comprises two parts: the analytics module and analytics architecture.
A. Analytic Modules
As part of its analytical layer 125, an embodiment of the system performs four primary calculations. First, based on part features, material, manufacturing processes, and purchasing demand volumes, the should cost 300 module of the analytics layer 120 calculates a “should cost” price for each part. For purposes of illustration, “should cost” refers to the amount of money a part should reasonably cost. In this embodiment, the system identifies outliers by comparing the “should cost” with the vendor's quoted price. Outliers refers to parts which seem to be unusually expensive compared with what the model predicts that they should cost. Second, the cost drivers 350 module of the analytic layer 125 identifies key factors called “cost drivers,” which contribute to part costs. These key factors can be used by the engineering staff to minimize costs in the design process. Third, the nearest neighbor 375 module identifies similar parts called “nearest neighbors.” Last, the sourcing analyis 325 module of the analytics layer 125 analyzes the capabilities of the suppliers to identify their core capabilities and thereby determines which parts are most efficiently sourced which each respective supplier.
1. Should Cost—Predicting What Each Part Should Reasonably Cost
The should cost 300 module models the costs of parts by predicting the price/kg for each part using generalized linear models.
a. Linear Combination Algorithm—Predicting the Price/kg
This algorithm predicts the log of the cost per kilogram of a part using a linear combination of features and categories.
What should be appreciated is that our model does not predict “should cost” directly. Instead, for each family of parts, the algorithm predicts the log of cost per kilogram as a linear function of the log of the annual demand for parts, physical features of the part, machining costs, and engineering specifications. The type of material, which the model includes as a variable, is also important. The predicted “should cost” price is then the exponential of the predicted log cost per kilogram of the part.
In one embodiment of the system, models of this form are developed for all of the parts together and then again for each family of parts (e.g., Bonnets, Brackets, Covers, Housings, Elbows, and Supports). After the full model is fit, the embodiment refines its models using R's step procedure. In this embodiment, step applies the stepAIC algorithm. In this embodiment, the algorithm refines the model, adds and removes variables, and iterates until it finds the best fit. It will be appreciated by one skilled in the art that other refinement procedures may be used and that the above described embodiment is not exclusive but merely illustrative.
2. Cost Drivers
In one embodiment, the cost driver 350 module identifies outliers by comparing the “should cost” with the vendor's quoted price. After outliers are eliminated, in a similar calculation to “should cost,” the cost drivers for a family of parts are predicted using a linear combination of features and categories. The system models the cost per kilogram of each part as:
2 John M. Chambers and Trevor J. Hastie (1992). Statistical Models in S, Wadsworth & Brooks/Cole Cole Computer Science Series, Pacific Grove, Calif.
What should be appreciated is that our model does not predict “cost drivers” directly. Instead, for each family of parts it predicts the cost per kilogram as a linear function of the log of the annual demand for parts, features that describe the part, machining costs, and engineering specifications. The type of material, which the model includes as an interaction term, is also important. The predicted “cost driver” price is then the exponential of the predicted log cost per kilogram of the part. In one embodiment, models of this form are developed for all of the parts together and then again for each family of parts (e.g., Bonnets, Brackets, Covers, Housings, Elbows, and Supports).
In one embodiment of the system, most predictive factors (cost drivers) and their relative effects are easy to interpret.
The relative effects of cost drivers for this example are shown in Table 2. The units in the table are incremental costs measured in cents per unit change in the cost driver. Thus, for example, on average a 10× increase in demand (logdmd) (1× in log scale) decreases the cost per kilogram of a part by $1.99.
It should be appreciated from linear regression theory that the parameters in Table 2 are the cost drivers that are displayed in the system's Cost Management Analysis (CMA) user interface. These parameters estimate the incremental costs for each of the features included in the model. In one embodiment of the system, these features are validated by applying the business rules (are these the data loading business rules?). It is sometimes the case that randomness in the statistical models results in aberrant estimates. The business rules flag suspect values and provide explanations such as insufficient data in the case of extreme randomness.
3. Nearest Neighbor Algorithm—Identifying Similar Parts
The second class of system algorithms involves searching feature space to identify similar parts or nearest neighbors. In one embodiment, calculation of data structures subsequently applied to produce predictions and used in the nearest neighbor analysis is performed at data loading time or whenever new data is added to the system's database. The system uses predetermined variables as feature vector and defines these vectors as a point in feature space:
vi=(v1, v2, . . . , vn)
where vi is the value of feature i for the particular part under consideration. Table 3 shows a list of variables used in one embodiment of the nearest neighbor analysis. It should be obvious to one of ordinary skill in the art that the table is meant to be only illustrative and not exclusive. The system then normalizes each of the numeric features using the standard normal transform and in one embodiment calculates the Euclidean distance (d) between the points representing the different parts in feature space. One of skill in the art will appreciate that other distance metrics, besides the Euclidean, may be used.
d(vpart1, vpart2)=||vpart1−vpart2||
where || || is the standard Euclidean distance function. When the user selects a target part, pre-selected feature variables of that part become reference points and the system then provides the distance between those target variables and all other parts. The nearest neighbor algorithm constrains the match so that certain attributes of the parts must match exactly, e.g., the parts must be made of the same material and be the same part type. Within this restricted class it enumerates all distances and returns the n candidates to the user interface.
4. Sourcing Analysis—Evaluating the Suppliers
One possible reason for an over priced part maybe because it is sourced with a supplier who cannot produce it efficiently. For each part the system rates each supplier on an Overall Sourcing Fit Rating 1400 (See
The sourcing fit analysis works by analyzing the parts that each supplier produces, as shown in
The score percentage displayed in the user interface is the Score(p)/number of features checked. For each part, the algorithm checks every possible supplier, sorts them in reverse order, and displays the best suppliers. Ties for suppliers that have the same percentage are broken by sorting on pdiff, the percentage difference between should cost and the actual price.
B. Analytics Architecture
At the architectural level, one embodiment of the system performs system analysis, as best seen in
Using all of the parts data in the system's populated database 165, in an off-line process, the system runs several statistical and data mining routines that fit models. The fitting process results in sets of models and coefficients that are used in subsequent analysis. In addition, the system pre-calculates many data structures that are subsequently applied to produce predictions and used in the nearest neighbor 375 module. As part of its off-line calculations, the system stores each part in the invention database for “cost reasonableness” and flags any unusual parts for further investigation. In one embodiment, model fitting and scoring are performed at data loading time or whenever new data is added to the system's database 165.
In this embodiment, as shown in
Once the data is loaded into the database 165, as discussed above and shown in
First, the system calculates the “should cost” price in the should cost 300 module. Here, for each part, in one embodiment, the system applies the log(costperkg) model from step 3 to predict the cost of each part. The predicted “should cost” value is compared with the vendor's price to identify large percentage differences, which one embodiment stores in a variable called pdiff. Parts with large positive pdiff's, e.g., a part is much more expensive than predicted, are candidates for cost savings. The should cost 300 module is described at length above.
Next, the system calculates “Cost Drivers” from the cost drivers 350 module. Here, for each part family, in one embodiment, the system uses the R statistical language to fit linear regression that predict should cost as a generalized linear function of the part's features. As with normal statistical theory, the coefficients in this model are the relative contributions of the particular features. The “cost driver” 350 module is described at length above.
Next, the system performs the “Nearest Neighbor” analysis in the nearest neighbor 375 module. Here, in one embodiment, for each part the system normalizes each feature to a (−1,1) scale and calculates the Euclidean distance between every part in feature space. Using this distance the system identifies the nearest parts and labels them neighbors. The nearest neighbor 375 module is described at length above.
Next, the system performs a Sourcing Analysis in the sourcing analysis 325 module. In one embodiment, this analysis involves analyzing every part in the dataset that each supplier produces and calculating the [0.5, 0.95] range of each feature. Then for each part the system, in one embodiment, scores each supplier on 16 possible features and give the supplier points each time the part's feature is in the [0.5, 0.95] range of the supplier's capability. The system also subtracts points in cases of a low volume supplier. The rating of a supplier for a part is its total score/number of features evaluated. The calculation is performed by material for each supplier. The sourcing analysis 325 module is described at length above.
The last step involves pushing out the analytical results to a database 165. The CMA website then accesses the database 165 to provide information to CMA users. Users access the system's analytical routines, through the system's presentation layer, which is described below. A top level view of the CMA application architecture can be seen in
III. Cost Management Layer
The third layer of the system architecture is the cost management layer 130. The system's cost management layer 130 allows for the user to automatically group parts for analysis and provides a detailed analysis of cost saving opportunities.
A. Accessing the System
Users may access the system in one of three ways: (i) selecting parts by feature, (ii) selecting parts by category, or (iii) retrieving parts selected in previous analysis session. The logical flow of the cost management layer 130 is best represented by
One way for the user to access the system is to search for parts by features, as best seen in
In one embodiment of the system, as best seen in
The second entry point to the system provides a Category Part Selector mechanism for specifying a system database search. In one embodiment of the system, users can create search rules for category part searches. In this embodiment, system users may create rules by selecting parts segments 700, part families 710 and part classes 720 to include in the search rules as well as filters based on part material 410, part buyer 510, part supplier 440 and part annual purchasing demand 445. The search rule list 740 is displayed and the user may add a rule by engaging the add search 730 function. Optionally, the user may remove a rule by engaging the remove rule 740 function. One of ordinary skill in the art will appreciate that the categories for creating search rule listed above are not exhaustive but are merely illustrative of possible search criteria. The system will apply these rules to select parts from the system database for analysis. The Select Parts by Category mechanism is shown in
Third, users may review and “fine tune” their analysis working set using the dialogue shown in
B. Cost Savings Opportunity Summary
Next, the system takes the results provided by the analytics layer 125 and presents the cost savings opportunities and their respective actions to the end user. For example, as can be seen in
1. Detailed Part Analysis
The system's detailed part analysis shows the details of the analytic layer 125 applied to a single part. The system shows the user what the part should cost as well as what the current part does cost and the potential savings based on the parts demand. In addition, a summary of how each of the cost factors (pricing, sourcing and design) are applied to that part.
2. Cost Driver Analysis:
The system Cost Driver Analysis provides the user with the cost model for a specific family of parts. This analysis details the costs associated with each of the parts parameters for a specific family of parts and shows graphically how the parts relate to each other.
3. Comparables Analysis
Referring now to TABLE 5, the nearest neighbor 375 module is used within the system to group parts based on like features (“comparables analysis”). This analysis is used when selecting parts by feature as well as when trying to find comparables to define redesign opportunities. The system nearest neighbor 375 module shows the users comparable parts as well as their characteristics. This analysis will show the user how similar parts are designed as well as provide the user with insight into design changes to the existing part that may reduce cost.
4. Sourcing Analysis:
The system sourcing analysis 325 module determines the capabilities of a supplier by the parts they currently make. This analysis is used to help the user determine which options are available to them to resource a specific part as well as understanding the current capabilities of their suppliers.
While the description above refers to particular embodiments of the present invention, it will be understood that many modifications may be made without departing from the spirit thereof. The accompanying claims are intended to cover such modifications as would fall within the true scope and spirit of the present invention. The presently disclosed embodiments are therefore to be considered in all respects illustrative and not restrictive, the scope of the invention being indicated by the appended claims, rather than the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.
This nonprovisional application claims priority to and incorporates herein by reference the content of Provisional Application No. 60/659992.
Number | Date | Country | |
---|---|---|---|
60659992 | Mar 2005 | US |