Abstract:
A system and method for processing project data enables a user to identify an engine model based on specific customer specifications. Package options based on the identified engine model are stored in the system, and a user is able to select desired package options from the stored package options. Selected reports can be generated based on the selected package options. In this manner, product and project information can be communicated upstream to sales and/or the customer, project specific information can be communicated downstream to project execution, the business process can be directed and automated, and historical data on all projects and revisions can be maintained.

Description:
BACKGROUND OF THE INVENTION  
         [0001]    The present invention relates to a database structure and method of processing project data and, more particularly, to an automated package information and configuration communication process for communicating product information upstream to a sales department or the like and a customer, project specific information downstream to project execution, direct and automate a business process, and maintain historical data on all projects and revisions.  
           [0002]    [0002]FIG. 1 is a schematic illustration of a business process flow. Generally, in an inquiry to order (ITO) process, a sales team first interfaces with a customer, followed by a request for quote (RFQ) being submitted to the sales support group. Sales support would then break the RFQ into commercial and technical issues, and the technical issues (including a customer specification) would be submitted to the product management group.  
           [0003]    The product management group would then review the customer specification and create two documents: (1) a production data sheet (PDS) presenting the scope of supply, and (2) a budget that identifies the cost to manufacture the defined scope based on the customer request. Both documents have generally been configured using known spreadsheet computer programs. These spreadsheets are then submitted to sales support via an iterative process until the scope of the project is well defined and accurate. A proposal would then be generated by sales support and submitted to the customer for review.  
           [0004]    Assuming the company wins the bid, an agreement in principle (AIP) or contract will be signed and submitted along with a sales order summary (SOS) document that is also based on the project scope, to product management group for final review and the hand-over meeting (HOM) to OTR. The HOM consists of the project team meeting and reviewing the numerous documents (including the PDS, budget, SOS and an open items document among others) to verify that the project scope is accurate, attainable and consistent from document to document. A final revision is made to the documentation, and the resulting information is submitted to project management for execution.  
           [0005]    Project management then meets directly with the customer to begin addressing the open items, revising PDS and SOS documents, and releasing the information to engineering. Engineering would then review the official documents and create a features and options document detailing what drawings are required to manufacture and assemble the package.  
           [0006]    In addition to the multiple points of data entry, excessive numbers of documents presenting information based on a single scope of supply are required, multiple document translations and hours of unnecessary work are also required, and there exist no running budget, open item metrics, project metrics, business impact measurements or budgetary analysis capabilities within the current process.  
           [0007]    Package configuration and information is thus scattered across numerous documents that are often identified as inconsistent, inaccurate and/or out-of-date. Moreover, the multiple documents are time consuming to create and maintain and they do not allow for statistical analysis facilitating future process improvement.  
         BRIEF DESCRIPTION OF THE INVENTION  
         [0008]    In an exemplary embodiment of the present invention, a method of processing project data includes (a) receiving customer specifications, (b) identifying an engine model based on the customer specifications, (c) storing package options based on the engine model identified in (b), (d) enabling a user to select the package options from the stored package options, and (e) generating selected reports based on the package options selected in (d).  
           [0009]    In another exemplary embodiment of the invention, a system for processing project data including structure for carrying out the method of the invention is provided.  
           [0010]    In still another exemplary embodiment of the invention, a system for processing project data includes a user interface for receiving customer specifications and identifying an engine model based on the customer specifications. The processor including a memory storing package options that are segregated based on the identified engine model enables a user to select the package options from the stored package options via the user interface. The processor generates selected reports based on the selected package options. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0011]    [0011]FIG. 1 is a business process flow diagram;  
         [0012]    [0012]FIG. 2 is a flow diagram of the general process of the present invention;  
         [0013]    [0013]FIG. 3 is a flow diagram showing the process for revising the configuration/project information;  
         [0014]    [0014]FIG. 4 is a flow diagram for modifying the drawing list;  
         [0015]    [0015]FIG. 5 is a flow diagram for creating/modifying a budgetary analysis;  
         [0016]    [0016]FIG. 6 is a flow diagram for tool maintenance;  
         [0017]    [0017]FIG. 7 is a flow diagram for viewing sales tools;  
         [0018]    [0018]FIG. 8 is a screen shot showing a user interface and package configuration;  
         [0019]    [0019]FIG. 9 is a screen shot showing project information; and  
         [0020]    [0020]FIG. 10 is a flow diagram showing an approval process. 
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0021]    A database configuration in the present invention includes data tables that respectively store varying information for a particular project. The invention will be described in the context of a particular application for exemplary purposes, but the invention is not necessarily meant to be limited to the described application.  
         [0022]    In the database, an engine table holds all of the different engines offered via the system to provide in a configuration package. In the engine table, an ID field orders the list of engine models on a pull-down menu, with the lowest number at the top of the list and with the remaining models following in ascending order. In an Engine Desc field, the name of each engine model is provided. The names are used for display in the pull-down menu and matched up with the engine key in the model table to determine which database is to be opened.  
         [0023]    In a model table, all of the models associated with each of the engines are stored. In an EngineKey field, a list of engine types is provided. Each engine type is listed once for each model to which it is associated. In a Model Desc field, the names of each model offered for each engine type are provided. A second pull-down menu will only display the values in the model description field that are associated with the engine key field value that the user selects in the first pull-down menu. A Default field determines which database is initially loaded for each engine type. The field should also be checked if the engine type only has one model description associated with it.  
         [0024]    There is a specific table for each of the engine models. This table holds all of the package options for the selected model with a nesting structure used to identify the applicable options based for user input. The table also contains information such as what validation logic applies to the option, whether the option is mandatory, whether the option is the default option, the associated key to that option, and a metric score.  
         [0025]    In a package options table, a Text field contains a title of a main heading of a section down to the deepest level of configuration selection choices. A Level field determines the nesting order of the configuration choices and formats a corresponding display. A highest choice or title is given a level of one (1). The program then checks for and indents displays of all configuration choices with a level of two (2) rating. The database does a similar procedure with every new level encountered. It indents farther with each new level and returns to its original level of indentation when a configuration selection is reached with the level number equivalent to its own. Therefore, for example, all level twos are indented the same amount as with level threes and so on while remaining underneath their respective section. (See, for example, FIG. 8.) An Option field defines if the user has the ability to select the configuration choice. For titles or main sections, the field is left unselected. If the field is selected, then the user will have the ability to select or unselect the choice in the configuration section of the program. A Standard field is selected if that configuration choice is selected by default when the option becomes available through interaction. The user, however, maintains the ability to select another option on that same nest level. A MultiSelect field, if selected, for a nest level, allows the user to select multiple options in that nest level. If unselected, the user must choose one and only one option in the corresponding nest level. A Key field includes a keyword relating a configuration selection to the budget and drawing numbers. A Metric field includes a score attached to main selection criteria identifying the importance of the information. The greater score is reported for items that have a greater business impact when unknown or changed. The overall metric adds up to the scores of all sections that have been left blank or “to be determined.” 
         [0026]    In a configuration flag table, all potential keys for the package options are contained. The keys tie user selections to budgetary and drawing information for reporting purposes. In a Keyword field, a list of words that are used to associate the configuration selections with drawing numbers and budgetary costs is provided.  
         [0027]    A budgetary cost table holds the information necessary to create the budget. This information includes budget section, line items, description, cost, required keys per line item, and whether or not the line item is part of the base package. A Section field defines which budget section the particular line item will fall under. A SectionID field identifies the order the line item will be placed inside the major section of the budget report. Each line item is given a one letter code and is displayed in the budget report in alphabetical order. A Description field contains the name of the budgetary unit used for pricing the different components of the package. A UnitCost field includes the price of each budgetary unit that is displayed and summed in the total cost on the budget report if the user has selected the option from the configuration section. Fields from Key  1 -Key  10  include words used to specify which line item should be entered into the budget report. These words are the same as the key words attached to the configuration options. When a configuration has been selected, the associated keywords are compared to the ones in each key column to determine what cost line items are applicable to the user defined configuration. Up to ten keywords can be used to differentiate the different budgetary cost line items from one another. Only one keyword can be entered into each of the ten key columns. Multiple flag fields designated Flag  1 -Flag  10  contain logic criteria associated with keywords in the Key  1 -Key  10  columns. If the check box is checked, then the keyword in the key column of the same number as the flag must be true in order to select the particular line item. If the check box is unchecked, then the keyword in the associated column must be false or not present in the current configuration selections in order to select the particular line item.  
         [0028]    A features and options table holds the information necessary to create a features and options document. This information includes the system, drawing numbers and associated keys per line item. A Section field defines which section of the features and option report the drawing will fall under. A DwgNumber field contains the drawing number, wherein when the keyword criteria is met, the drawing number in this field is inserted under the appropriate section. Similar to the budgetary cost table, the features and options table contains key fields including Key  1 -Key  10  and flag fields including Flag  1 -Flag  10 .  
         [0029]    Finally, a general information table contains all information regarding the package configuration information. A GenInfoID field contains a number that determines the order in which information will be saved in the data file. A Caption field contains a title next to the data entry field and identifies which piece of information should be entered in the appropriate area. A Desc field contains comments to the user by using a mouse-over on the particular line item (Tool Tip) as to the meaning of each caption or issues related to the caption. A Default field contains an initial value of the data field. Numeric data are given an initial value of 0, while text data are initially set to TBD (to be determined). A Section field includes a title of the tab in the general information section of the program. The caption and data entry field are located on the particular tab based on the value of the field. An Object field describes the nature of the data field. If simple text is to be entered, then the field is given a value of text. If a combo box is to be used to select the data to be entered, the field is given the value of combo. A FormUsed field identifies which main page or report, if any, the data entered into the field is to be displayed on. Finally, a MetricScore field contains a score attached to selectable information identifying the importance of the data. As noted above, a greater score is reported for items that are deemed more essential to the OTR process. Non-essential items are given a score of 0. The overall metric adds up the scores of all sections which have been left blank or to be determined. A higher score means more open issues are present at the time of the HOM.  
         [0030]    In the exemplary embodiment of the present invention, the performance program contains certain data elements that the application stores and utilizes in the project information and the configuration sections. A sales department completes the remainder of the project information and configuration to the best of their ability. Applications reviews the configuration and project information for accuracy and level of completion and is responsible for completing the budgetary analysis. Project management maintains the project information and configuration through the project execution phase, and engineering maintains the features and options lists and utilizes the program to identify scope changes.  
         [0031]    The system and process of the present invention will be described with reference to the flow charts of FIGS.  2 - 7  as well as the screen shots of FIGS. 8 and 9. With particular reference to FIG. 2, the program is first loaded in step S 1 , and the system determines whether the user is creating a new configuration (step S 2 ). If so (YES in step S 2 ), the user is prompted to select an engine based on the customer provided specifications (step S 3 ). Once selected, the program reads the default model configuration table for the selected engine (step S 4 ). Using a recursive function, the application identifies the structure of the options. In other words, the application identifies what options are dependent on or nested under higher level options and creates a treeview graphical user interface (GUI). A screen shot with the configuration table and selectable options is shown in FIG. 8.  
         [0032]    Prior to creating and/or modifying a configuration (step S 6 ), the system queries whether the user would like to view sales tools in step S 5 . If so (YES in step S 5 ), the system carries out the process shown in the flow diagram of FIG. 7, which will be described in detail below.  
         [0033]    As the user selects options applicable to the project in step S 6 , the application automatically identifies and deselects all conflicting information. Additionally, the system identifies what options have been selected and locates the associated Boolean operator (found in the Boolean table). The appropriate Boolean operator is then set to true. Conversely, the application also identifies what options have been deselected and sets those indices to false. These Boolean operators are later utilized to analyze the budget and features and options lists for data reports. Additionally, the system identifies the treeview structure and displays applicable options in the treeview based on the user&#39;s selected options and closes all nest levels that are no longer available.  
         [0034]    The project information is entered in step S 7 , and when complete, the system queries whether the project is to be released to engineering (step S 8 ). If not (NO in step S 8 ), a “PTC” file is stored in a hard drive or other data storage device (step S 9 ). If the project is for release to engineering (YES in step S 8 ), the system initiates the approval process (step S 10 ) and subsequently determines whether the user has received all required approvals (step S 11 ). If so (YES in step S 11 ), a standard folder structure is created in step S 12 , and the configuration is published to the folder structure in step S 13 . If the necessary approvals have not been received (NO in step S 11 ), the process returns to step S 6  for further data entry or revision of project information.  
         [0035]    The approval process (step S 10 ) will be further described with reference to FIG. 10. In step S 101 , a project manager submits the project for approval. An e-mail notification is sent to an approval manager requesting review of the project (step S 102 ). If the approval manager has not reviewed the project (NO in step S 103 ), the system determines whether forty-eight (48) hours has passed since the approval manager received the e-mail notification (step S 104 ). If not, the system allows additional time to pass for manager approval. If so (YES in step S 104 ), the system determines whether seven (7) days have passed since the approval manager received the initial e-mail (step S 105 ), and if not, the e-mail notification is resent (step S 102 ). In step S 106 , the system determines whether the project has been approved (step S 106 ) and whether additional approval managers are required to review the project (step S 107 ) If no further approval managers are required to review the project (NO in step S 107 ), an e-mail notification is sent in step S 108  to the project manager who submitted the project indicating project approval.  
         [0036]    If the project is not approved (NO in step S 106 ), the project is thus rejected (step S 109 ), and an e-mail notification is sent to the project manager who submitted the project of the project&#39;s rejection (step S 110 ).  
         [0037]    The user has the ability to save the project configuration, notes, general information, budgetary analysis, SOS line items, features and options list, and all open items based on what information the user has selected/entered with a metric score associated with each open item. The user can choose between publishing the data to a business server or saving locally to the computer hard drive. Publishing a file signifies an official release to the business for review/approval. Each time a package is published, a separate line item is created in the standard folder structure on a hidden server. This gives the application the ability to track changes and analyze those changes for business impact and statistical analysis. The PIC file stores the package information locally without releasing it to the business.  
         [0038]    If the user is not creating a new configuration (NO in step S 2 ), the system queries whether the user is working with an existing published project in step S 14 , and if so (YES in step S 14 ), the published file is loaded in step S 15 . If not (NO in step S 14 ), the PIC file is loaded in step S 16 .  
         [0039]    Like step S 5 , the system queries whether the user would like to view sales tools in step S 17 , and if not (NO in step S 17 ), the system queries whether the user is revising the configuration and/or project information in step S 18 . If so (YES in step S 18 ), the system proceeds to step S 6 . If not (NO in step S 18 ), the system proceeds to the process flow illustrated in FIG. 3.  
         [0040]    With reference to FIG. 3, in step S 19 , the system queries whether the user would like to view information concerning the project configuration. If so (YES in step S 19 ), the user is provided options to view PDS (S 20 ), budget (S 21 ), features and options (S 22 ), budgetary analysis (S 23 ), or SOS (S 24 ). Selection and viewing of the respective reports may be limited by the user&#39;s permissions. A screen shot illustrating an exemplary report is shown in FIG. 9. In these displays, information is never manipulated or added, which forces the user to enter any necessary change in the configuration or project information sections.  
         [0041]    In the PDS information view (step S 20 ), the application references the information found in the general information table. If the information is defined to be available with the user selected report (the PDS in this case), the user input corresponding with the field is included in the report. The configuration selected by the user is then displayed in the report. Any applicable notes are also presented. Notes are used to identify and describe any non-standard information regarding the customer specific package. In other words, any customer requests outside the typical scope of supplies.  
         [0042]    In the budget information view (step S 21 ), the application references the information found in the general information table. If the information is defined to be available with the user selected report (the budget in this case), the user input corresponding with the field is included in the report. The application references the information found in the budget table. Each line item in the table is analyzed against the Boolean values (i.e., the configuration). If the keys and flags match the Boolean values found in the configuration, then the line item is added to the report. All notes and their associated costs are then displayed in a special request section. Each budgetary line item has specific customer options associated with it. These options are often complex, for instance: if given five options a, b, c, d and e, the budgetary line item may require (1) the user to select option a, c and d, (2) the user not to select b, and (3) not be affected one way or the other by e. In this case, the database would show the key associated with option a (found in the package options table) with a TRUE flag field.  
         [0043]    In the features and options list (step S 22 ), the application references the information found in the features and options table. If the information is defined to be available with the user selected report, the user input corresponding with the field is included in the report. The application references the information found in the features and options table. Each line item in the table is analyzed against the Boolean values (i.e., the configuration). If the keys and flags match the Boolean values found in the configuration, then the line item is added to the report.  
         [0044]    In the budgetary analysis view (step S 23 ), the application creates a budget and pulls the line items into the budgetary analysis format. Text boxes are supplied for the user to input actual cost per line item. The application then calculates variance between the package&#39;s actual cost and initial estimated cost.  
         [0045]    In the SOS information view (step S 24 ), the application references the information found in the general information table. If the information is defined to be available with the user selected report, the user input corresponding with the field is included in the report. The application then reviews all of the packages associated to the current project and reports all SOS line items.  
         [0046]    If the user does not desire to view information (NO in step S 19 ), the user is provided with options to modify the drawing list (step S 25 ), create and/or modify the budgetary analysis (step S 26 ), or maintain the tool (step S 27 ). The selected processes in steps S 25 , S 26  and S 27  are shown in the flow charts of FIGS. 4, 5 and  6 , respectively.  
         [0047]    If the user intends to modify the drawing list (YES in step S 25 ), with reference to FIG. 4, the system selects the features and options list option (step S 251 ) and subsequently selects a modify option (step S 252 ). The system then queries whether the user intends to add a drawing or part (step S 253 ), delete a drawing or part (step S 254 ) or return to the configuration (NO in step S 254 ). In either instance (YES in either step S 253  or step S 254 ), the add option is selected (step S 255 ) and the modification is entered (step S 256 ). Various levels of approval may be required for such modifications, and the system determines whether any required approval has been received in step S 257 . If not (NO in step S 257 ), the system returns to step S 256  for further modification. If so (YES in step S 257 ), the modified configuration is published to the folder structure in step S 258 .  
         [0048]    With reference to FIG. 5, if the user desires to create and/or modify the budgetary analysis (YES in step S 26 ), the system selects the budgetary analysis option in step S 261 , selects the modify option in step S 262 , and enables the user to enter the modification in step S 263 . The system queries whether the user has received any required approval in step S 264 , and if so (YES in step S 264 ), the modification is published to the folder structure in step S 265 . If any required approval has not been received (NO in step S 264 ), the system returns to step S 263  for further modification entry.  
         [0049]    If the user desires to maintain the tool (YES in step S 27 ), with reference to FIG. 6, the system performs tool maintenance in step S 271  and subsequently returns the process to the configuration section. In the maintenance process, the database can be modified or manipulated in any fashion. Due to the structure of the application, the results will range from modifying reports to adding package options or even an entire package.  
         [0050]    With respect to effecting changes in the configuration, fields are supplied to allow the user to create a document used to track contractual or scope changes defined through the life of the project. This view also allows the user to load previous change orders that apply to the loaded package.  
         [0051]    The process flow for viewing sales tools will be described with reference to FIG. 7. In this process, the user is provided with options to view brochures (step S 28 ), view technical specifications (step S 29 ), view proposal drawings (step S 30 ), generate a proposal (step S 31 ), or return to the configuration (step S 32 ). In the brochure view process (YES in step S 28 ), the user is prompted to select the brochure option (step S 281 ), and the information is displayed (step S 282 ). A similar process is carried out with respect to technical specifications (YES in step S 29 ) in steps S 291  and S 292  and generate proposal (YES in step S 31 ) in steps S 311  and S 312 . Similar to budget and features and options, the technical specification is generated dynamically. This document describes the package specific information based on what the user has selected/inputted.  
         [0052]    In viewing the proposal drawings (YES in step S 30 ), the user selects the drawing option in step S 301 , a search tool is navigated in step S 302 , and the information is displayed in step S 303 . Several different drawings may be available based on the selected engine/model. The user must select which drawing to view.  
         [0053]    The program is responsible for producing the production data sheet (PDS), the budget, the features and options list (F&amp;O), the budgetary analysis, and the sales order summary (SOS). In addition, the program must have the capability of producing the metric data as discussed above. The PDS contains information that is required for engineering to order parts and manufacturing to build the package. This information includes items such as customer information, site conditions, testing information, among other information as defined in the general information table. In addition to the package information, the PDS also contains the entire project scope.  
         [0054]    The budget provides the item costs as defined in the budget cost table and the package information (required items are defined in the general information table). The budget document then sums the item costs into a section total (again, this information is included in the budget cost table). The total package cost is then calculated by summing up each of the section totals. The features and options list is created by listing each of the drawings, as defined in the features and options table, that apply to the identified package configuration. The list is organized into sections that are also defined in the table. The budgetary analysis reads the information from the initial budget, allows the user the ability to enter actual costs associated with each line item, calculates a variance per line item, allows the user to enter a description of the variance, and then summarizes the variance. The summary separates the line items into one of two categories. The base packaging is defined as necessary items for a GTG package. These items are identified in the budget cost table. The remaining items are categorized as standard options.  
         [0055]    Generally, the program is designed to have the functionality of maintaining project information and configuration from the ITO process to the project completion. Furthermore, the program formats this information appropriately to provide the business with the required documentation and information. Specifically, as noted above, the program is required to create the budget, PDS, F&amp;O (including production releases, customer transmittals, and required dates), the SOS and a budgetary analysis document. In addition to the listed functions, the program tracks the project using the ITO metrics on quality. The metrics include open items, specific revisions that were made, the personnel that made the revisions, when the revisions were made, and why.  
         [0056]    The system of the present invention provides the ability to automate, direct and monitor a project development through business processes. The system effects streamlined project documentation, comprehensive single source data entry and stores historical data while maintaining current and up-to-date information, including project information and documentation, package availability and options, budgetary information, base offerings, and features and options lists. Through direct electronic routing, automated approval processes for modifications and/or base configurations can be obtained. A running project budget can be maintained enabling budgetary analysis capabilities. The system maintains and generates reports on change order descriptions, magnitude of change calculations, metric data, open items, administration capabilities and project information location/structure. The system enables automatic updating for the database as well as for executable operations. Still further, the system accommodates multiple points of data entry and processes data using standard document formats.  
         [0057]    While the invention has been described in connection with what is presently considered to be the most practical and preferred embodiments, it is to be understood that the invention is not to be limited to the disclosed embodiments, but on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.