Source: https://patents.google.com/patent/US7213232B1/en
Timestamp: 2020-01-27 08:47:22
Document Index: 179108620

Matched Legal Cases: ['§ 119', 'Application No. 60', 'art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 300', 'art 450', 'art 450', 'art 450', 'art 300', 'art 850']

US7213232B1 - System and method for configuring software using a business modeling tool - Google Patents
System and method for configuring software using a business modeling tool Download PDF
US7213232B1
US7213232B1 US10/163,782 US16378202A US7213232B1 US 7213232 B1 US7213232 B1 US 7213232B1 US 16378202 A US16378202 A US 16378202A US 7213232 B1 US7213232 B1 US 7213232B1
US10/163,782
G. Gordon Knowles
12 Tech Inc
2001-06-07 Priority to US29660101P priority Critical
2002-06-06 Priority to US10/163,782 priority patent/US7213232B1/en
2002-06-06 Assigned to I2 TECHNOLOGIES US, INC. reassignment I2 TECHNOLOGIES US, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: KNOWLES, G. GORDON
2002-06-06 Application filed by 12 Tech Inc filed Critical 12 Tech Inc
2007-05-01 Publication of US7213232B1 publication Critical patent/US7213232B1/en
A method for configuring software includes communicating a business configuration interface to a user and receiving a selection of a business configuration from the user. In addition, the method includes communicating a business topology interface to the user that includes one or more functional elements associated with the selected business configuration. The method also includes receiving a selection of a functional element, which includes one or more business functions, from the user. In addition the method includes communicating a functional element interface to the user, the functional element interface including one or more business functions associated with the selected functional element, and receiving a selection of a business function from the user, the business function having one or more associated business processes. Furthermore, the method includes communicating one or more business process interfaces to the user and receiving software configuration information from the user via the one or more business process interfaces.
This application claims the benefit under 35 U.S.C. § 119(e) of U.S. Provisional Application No. 60/296,601 filed Jun. 7, 2001.
This application is related to copending U.S. application Ser. No. 10/164,516, entitled “Software Deployment System and Method” and U.S. application Ser. No. 10/164,448, entitled “Software Valuation Simulation Tool.”
This invention relates to the field of software, and more particularly to a business modeling tool.
Recently, large advances have been made in providing businesses with software solutions covering practically the entire operating environment of a business, including customer and supplier relationship management and supply or value chain management. However, the price of this increased functionality is the complexity of deploying (selling and implementing) this software in the business environment. This complexity of deployment affects the ability of software vendors to deploy these solutions quickly and to ensure that both physical and intellectual ownership of the software is transferred to the customer. As an example, the cost of deploying this business software is often as much as the cost of the license to use to the software. Although large businesses may be able to absorb this deployment cost and realize the significant savings provided by the software once deployed, most small- to medium-sized business cannot afford this deployment cost. For a business software vendor to be successful in the low end of the market, there need to be significant cost and time reductions in the traditional business cycle of selling and implementing business software.
According to the present invention, disadvantages and problems associated with previous software deployment techniques have been substantially reduced or eliminated.
FIG. 1 illustrates an example deployment system 10 that may be used to sell, implement, and evaluate the performance of a variety of different business software. Deployment system 10 uses a bundled set of unique business cases, tools, and business knowledge that are used in association with a novel deployment methodology to assist a user in performing the above functions in an efficient and uncomplicated manner. The methodology is divided functionally into three different phases that correspond with phases of the software business cycle. Deployment system 10 includes a module that implements and is associated with each of these phases. These modules include a decision module 12 (associated with a sales phase of the business cycle), an execution module 14 (associated with an implementation phase of the business cycle), and a measurement module 16 (associated with an evaluation or value determination phase of the business cycle).
A user accesses system 10 to initiate the deployment of one or more software solutions (and more specifically the decision phase of the deployment cycle). During the software deployment process, one or more different users may access and use system 10 from one or more locations. As an example, a representative from the business in which the software is to be deployed may access deployment system 10 remotely to being the sales phase and a representative from the company selling the software may later come to the business to finish the sales phase and to perform the implementation phase. The representative from the software company may bring system 10 to the business (for example, in the form of software loaded on a laptop computer) or may access deployment system 10 remotely. In any of these cases or any other appropriate cases, the person or person accessing system 10 are referred to herein as “users.”
In an example deployment process using deployment system 10, a business prospect may be directed to the software provider's web site and directed to use qualification and value assessment tools and computer-based training (CBT) to determine which software solutions offered by the software provider are appropriate for the business. This process may be done independently by a user from the business or in conjunction with a liaison from the software provided who locally or remotely assists the user (for example, using MICROSOFT NETMEETING™ or other suitable software).
Once the prospect is “qualified” and interested in particular software solutions, one or more representatives of the software provider may visit the business and use appropriate business cases and associated tools to assess the functional suitability of the software solutions for the business prospect. This suitability determination may begin, in an example deployment process, with a determination of the business case and associated business topology that are relevant to the business prospect. The use of predefined business cases is different from past deployment processes in which a software solution was tailor-made for a particular business. These past deployments typically involved extensive design and business analysis in which skilled consultants designed a complete software solution from scratch specific to a particular customer. Unlike these tailor-made solutions, the businesses cases provided by system 10 include pre-defined software solutions that a business can choose and configure using system 10.
A business case includes a business model containing pre-selected functional elements and one or more business processes to support particular business process functionalities. For example, a business case may support capacity balancing (which is a sub-set of factory planning) or volume-based forecasting (which is a sub-set of demand planning). Multiple business cases may be bundled into a “business release.” For example, a business release associated with factory planning might contain business cases having business models that support functions such as alternate parts, capacity balancing, indented bill of materials, and revision control. A software vendor may create a number of different business cases associated with the various functionalities included in the software solutions provided by the vendor. Once the various business cases are created, the business cases are stored in one or more data storage locations 18. As described below, the business cases may be grouped into business releases by business topology, industry vertical, and/or any other appropriate grouping.
A representative of the software vendor or other appropriate users may then select specific business releases and demonstrate the features of these business releases to the prospect. The business model or models associated with the business release copied out of an appropriate data storage location 18 and tagged with a prospect identifier to creating a prospect-specific “prospect model.” The representative or other user may then gather information about the prospect and input particular business requirements, functions, processes that are specific to the prospect by completing one or more data inquiry sessions. After the prospect model is “filled in” with prospect-specific data, it is saved and stored in an appropriate data storage location for possible use in the implementation phase of the deployment cycle. Once this is performed for all appropriate business releases (if more than one are appropriate), the sales phase may end by the prospect deciding to purchase (or likely license) the software solutions used to implement the business releases.
The two rectangles outside of the largest rectangle in business topology interface 250 are associated with what may be referred to as “external agents.” An external agent captures the external interaction with third party entities, which in this example are customers 201 and suppliers 202. These external agents are not modeled, however the functional interaction to the internal business environment is clearly depicted and illustrates the business prospect's interaction with supply chain partners.
Milestone chart 300 includes a number milestones 310 associated with different stages of the decision phase. Milestone chart 300 further includes milestone dpDO1 310 a and milestone dpDO2 310 b. Milestones 310 a and 310 b are listed in the order that they are to be performed. Each milestone 310 has one or more associated activities 320 that are to be performed to complete the milestone. For example, the first milestone 310 is “Orientation” and the associated activity 320 is for supply chain management (SCM) concepts and capabilities to be demonstrated to the customer using computer based training. As described above, this activity may be performed remotely by customer 202 and no representative from the software vendor need be present. In addition to displaying activities 320 that are associated with a milestone 310, milestone chart 300 may also provide other appropriate information associated with milestones 310. For example, milestone chart 300 may identify the “owner” of a milestone (the entity responsible for its completion), the resources required to perform the milestone, and/or any other appropriate information.
FIG. 5 illustrates an example activity checklist 350 that may be accessible from milestone chart 300. Checklist 350 may include a checkbox 360 associated with each activity 320 that allows and a user to identify when a task has been completed. Furthermore, checklist 350 may include detailed information about an activity 320 (which may or may not be more detailed than the information provided in milestone chart 300) such as a detailed activity description, the entities involved in the activity, the deliverables from the activity, and/or any other appropriate information to aid the user in identifying and performing the activity. Activity checklist 350 may also include links 370 to one or more tools that may be used to complete an activity 320. For example, the activity “Complete Prospect Business Profile” has an associated link 370 to a prospect qualification tool that may be used to perform this activity 320. Examples of the tools that may be provided are described in further detail below.
The prospect qualification tool is used to obtain information from the prospect about its business to properly select and deploy appropriate software solutions. Interface 400 presents various questions to the user (for example, the prospect itself or someone helping the prospect complete the decision phase) and allows the user to select appropriate answers to the questions. For example, interface 400 may provide drop-down menu to allow the user to select the appropriate answer. Furthermore, any other appropriate techniques for presenting questions to the user and obtaining answers to the questions may also or alternatively be used. Although an example interface 400 is illustrated, it will be understood that many other interfaces for obtaining other types of information from the user may also or alternatively be used. After the user has communicated its answers to system 10, the answers are analyzed and weighted calculations may be conducted which allow a comparison of the prospect against an “ideal fit” with respect to particular dimensions or characteristics that are being measured.
FIG. 7 illustrates an example customer profile spider chart 450 that illustrates the result of an analysis of the answers provided by the user using the prospect qualification tool. The prospect's “score” in each of multiple dimensions 460 is shown in chart 450 along a scale that ends with the “ideal” score in each particular dimension. Furthermore, a prospect profile 470 may be illustrated to more clearly compare the prospect's scores in all of the dimensions to an ideal profile 480. In the example chart 450, it is clear that the example prospect has a poor score in the “data quality” dimension 460 a. This low score may serve as an early warning signal and may automatically trigger further questioning of the prospect (using the prospect evaluation tool or any other appropriate technique) in relation to its data availability. This questioning may continue until it is determined that it is alright to move to the next activity or milestone or until it is determined that an appropriate software solutions is not available for the selected functional element (in this example, demand planning).
Upon the completion of the value simulation activity or any other appropriate “Orientation” phase activity, the user may proceed in the example milestone chart 300 from the “Orientation” phase of the “Decision” stage to the “Business Modeling” phase. The user may automatically be taken to the first activity in the “Business Modeling” phase or the use may initiate the activity by selecting a link to a business modeling activity or a deployment modeling tool. Since the user has previously selected the demand planning functional element of the MTO environment, the business modeling interfaces presented to the user, as described below, may automatically be associated with this function. Alternatively, the user may select a different functional element to configure. Furthermore, once the user has completed the modeling of one functional element in the “Decision” stage, the user may return to business configuration interface 200 and/or a particular business topology interface 250 to select additional functional elements to configure.
The example business model that is described herein has an architecture that includes four levels of decomposition, each level being represented by one or more diagrams. At the top level is the business topology diagram, such as the diagram presented in business topology interface 250. As described above, this diagram depicts the functional footprint of a typical business topology in which the prospect operates (for example, ATO, ETO, MTS and/or MTO). The second level in the model is represented using one or more functional element interaction diagrams (described in FIG. 11) that are each associated with a particular functional element 260 in the business topology. Each functional element 260 includes various business functions which are illustrated in the functional element interaction diagrams. The business functions may be further decomposed into core functions. The third level is represented using one or more functional decomposition diagrams (described in FIG. 12) that are each associated with a particular business function from a functional element interaction diagram and that identify the core functions of that business function. The fourth and lowest level of the business model is represented by one or more business process diagrams that are each associated with one of the core functions from a functional decomposition diagram. These business processes are described in further detail below with respect to the “Execution” phase of the deployment cycle.
FIG. 12 illustrates an example functional decomposition interface 700 for the revenue-based forecasting business function 660. As described above, the functional decomposition interface 700 includes sales and other history 701 and core functions 710 that make up a particular business function 660 (in this case, revenue-based forecasting). Core functions 710 further includes core functions 711–715. In order to assist the user in the translation of this business function 660 into execution of business processes, the model decomposes core functions 710 into one or more business process that reside at the fourth level of the business model. However, in the context of the decision stage of the deployment cycle, the model is used to extract enough relevant information from the prospect and to determine the suitability of various software solutions (business releases) for the prospect and to demonstrate to the prospect the manner in which the software conducts certain functions.
This process of obtaining information in the decision stage may be referred to as an inquiry session. Each core function 710 may have an associated inquiry session. In the example interface 700, the inquiry session associated with a particular core function 710 may be accessed by right-clicking or otherwise selecting at least one core function 710, which in turn brings up a menu 720. An “Inquiry” option 740 may then be selected to initiate the inquiry session (as will be described below, a “Modeling” option 730 may be selected in the Execution phase). Since the primary purpose of the business modeling effort in the “Decision” phase (the sales phase) is to conduct business analysis and data gathering to determine which software solutions are appropriate for the prospect, the user chooses the Inquiry option 740 in the Decision phase where the user will be presented with the opportunity to determine functional requirements and to pose deliberate questions regarding the functional elements being demonstrated to the prospect.
As mentioned previously the techniques, tools, and methodologies in the Decision phase are primarily concerned about rapid, low-cost methods of selling and understanding the scope of a proposed implementation of a software solution. Embodiments of the present invention thus utilize tools and methods designed to begin the implementation process as early as possible (even before the product is sold). Once the Decision phase is completed, the prospect model created at the prospect site (based on the various information and data provided by the user) is saved and stored until an agreement to purchase the software solution is completed. Once a deployment team arrives at the prospect (now the customer) site, the prospect model is transferred to a “deployment model” and is used by the team as the basis for the deployment. However, the prospect model may be simply modified in some embodiments, and there is not necessarily a distinction between the prospect model and the deployment model in particular embodiments. The prospect model and deployment model may be individually or collectively referred to as an “entity model.”
FIG. 14 illustrates an example project summary interface 800 depicting the Execution phase in stages with integrated timelines 801. The user may enter the start date of the Execution phase into progress block 802 and then as milestones are completed, the progress may be uploaded to this chart allowing a project manager to view progress on a daily basis. Although not described above, a similar project summary interface may be used for the decision phase and/or a similar project summary interface may be used for multiple phases of the deployment process. Project summary interface 800 displays the various stages 810 a–810 b in the execution phase and milestones 820 a–820 f in each of stages 810 a–810 b. Project summary interface 800 provides a good overview of the entire project and gives the customer a good understanding of the degree of commitment required of its resources. The user may drill into project summary interface 800 for a particular time period and may be taken to the milestone chart for the particular period.
FIG. 16 illustrates an example execution checklist 900 that may be accessed from milestone chart 850 and used to monitor completion of the various activities which make up a milestone (similarly to activity checklist 350, described above). As described above, checklist 900 indicates each activity, the responsibility for its completion, and the deliverable associated with the completion of the activity. In order to access the tools or templates associated with an activity, the user may select the link associated with activity and be directed to the appropriate tools or templates, as described above. Once the activities are complete and the check boxes are selected, the user can update the progress in project summary interface 800 by selecting the “save and upload progress” button at the top of checklist 900.
The example checklist 900 lists the activities associated with milestone “eI1.” Once the project scope is discussed, risk assessment plan and communication plan developed, and roles and responsibilities defined, the user may typically recall the prospect model created during the Decision phase and begin the process of reviewing the data and configuration decisions which were captured in the Decision phase (for example, in the inquiry sessions).
The modeling process for a particular aspect of a software solution (such as for a particular business function 660 of a particular functional element 260) may be accessed using functional element interface 650 and functional decomposition interface 700, described above. As an example, it will be assumed that the user has used these interfaces 650 and 700 to select the revenue-based forecasting business function 660 to model. As described above in conjunction with FIG. 12, revenue-based forecasting business function 660 includes a number of core functions 710. Each core function 710 may have an associated inquiry session and an associated modeling session. In the example interface 700 illustrated in FIG. 12, the modeling session associated with a particular core function 710 may be accessed by right-clicking or otherwise selecting a core function 710, which in turn brings up a menu 720. A “Modeling” option 740 may then be selected to initiate the modeling session.
FIG. 17 illustrates a portion of an example business process interface 1000 used in association with the business modeling activity. In particular embodiments, there are two types of business processes in the model, main processes and sub-processes. A main process starts at the highest level of process definition and provides the user with a first pass at decision making. The example business process interface 1000 is associated with a bill of materials (BOM) core function 710. In the process, diamonds 1010 a–1010 b represent decision points and modeling activity rectangles 1020 a–1020 c represent the modeling activities associated with the selected core function. Each decision diamond 1010 a–1010 b may be configured for one input path and three output paths to provide AND, OR and XOR Boolean decision logic; however, any other appropriate configurations may be used. Upon reaching a decision diamond 1010 a–1010 b, a user may determine the answer to the question presented and go to the next appropriate activity rectangle 1020 a–1020 c or decision diamond 1010 a–1010 b. Alternatively, in particular embodiments, the user may select the correct answer to the question (for example, by clicking on “yes” or “no” arrows coming from a decision diamond 1010 a–1010 b) and the entire process as displayed to the user in interface 1000 may be modified as a result of the selected “path.” For example, if the user selects “yes” to a question, the decision diamonds 1010 a–1010 b and/or activity rectangles 1020 a–1020 c in the path starting from the “no” arrow may be removed, dimmed, colored, or otherwise distinguished from the decision diamonds 1010 a–1010 b and/or activity rectangles 1020 a–1020 c in the selected path to indicate that the user does not need to make decisions or enter modeling input for this non-selected path. The model will then effectively no longer contain these options and associated modeling activities and sub-processes, described below. The user can also select activity rectangles 1020 a–1020 c that request information and provide this information to help configure the software.
In certain embodiments, two different types of activity rectangles 1020 a–1020 c may be included in a process, those having an underlying sub-process and those that do not have an associated sub-process. Activity rectangles 1020 a–1020 c having an associated sub-process may be identified in any appropriate manner. In the illustrated embodiments, such activity rectangles 1020 a–1020 c have shadowed borders and associated arrows. The associated sub-process for these activity rectangles 1020 a–1020 c may be accessed by right-clicking the activity rectangle 1020 a–1020 c or in any other suitable manner.
FIG. 18 illustrates a portion of an example business sub-process interface 1050 that may be accessed from business process interface 1000. The sub-process is the lowest level of business modeling process. The example sub-process displayed in interface 1050 is for material level consumption modeling and may be reached from the BOM modeling process illustrated in FIG. 17. As can be seen, a decision to specify parts being consumed in the first decision diamond 1060 takes the user to a “Model Operation Level Material Consumption” activity rectangle 1070. In order to set the parameters in the software solution to do this the user needs to know which records relate to this decision. In the illustrated embodiment, at the left of the activity rectangle 1070 an icon is visible. The user can select the icon to see a specification file record for operation level material consumption and what the setting should be or the user can use a configuration wizard which takes the user through the steps involved in configuring the specification file. A specification file is a file that identifies what configuration of data is required from the customer for processing (essentially, a meta-model). This file identifies for the customer what data is needed and in what format, so that the customer can then create appropriate data and communicate it for processing.
In the example embodiment, if the user clicks on the icon next to an activity rectangle 1020 a–1020 c or 1070, the user is presented with the specification file record associated with the process activity associated with the activity rectangle. An example of such a specification file record 1100 is illustrated in FIG. 19.
FIG. 20 illustrates an example BOM record configuration interface 1200. Upon selecting the relevant record (for example, the BOM record) from a main menu or upon selecting the configurator from a particular activity rectangle, 1020 a–1020 c or 1070 the user is presented with a configuration interface, such as configuration interface 1200. Configuration interface 1200 allows the user to select particular fields within the BOM record to configure within the specification file. Each field that is selected is added to the specification file and thus specified as being a portion of data that is to be used by the software being configured. In order to select a particular field for inclusion in the specification file, the user may select the associated check box. It should also be noted that certain fields may be mandatory in order to establish a basic configuration. These required fields may be pre-selected in the configuration interface.
FIG. 21 illustrates a example portion 1250 of a configured specification file relevant to BOM data. Portion 1250 has been configured by selecting the “operation” field check box in BOM record configuration interface 1200. Accordingly, the record for operation has been set and all other records preceded with the “#” sign are not valid for this record. When the user has completed the entire configuration process (for example, after selecting the desired records and fields within the business model(s) for an entire business topology), the user may then generate a complete specification file for that business model or topology. This complete specification file may then be used to specify all the data (and the data format) that should be input into the software solution being configured. A specification file may be generated before configuring an entire model, but such a specification file may be incomplete.
After receiving a decision from the prospect to implement the software, the “prospect” becomes a customer and the implementation phase of the software deployment cycle begins. At step 1408, the stored prospect model is retrieved (for example, by an implementation team). This prospect model may be saved as a deployment model. At step 1410, functional requirements of the entity are specified using a business modeling tool (as described above), and the deployment model is configured using the specified functional requirements at step 1412. At step 1414, one or more specification files are automatically generated according to the configured entity model, as described above, and the method ends.
US10/163,782 2001-06-07 2002-06-06 System and method for configuring software using a business modeling tool Expired - Fee Related US7213232B1 (en)
US29660101P true 2001-06-07 2001-06-07
US10/163,782 US7213232B1 (en) 2001-06-07 2002-06-06 System and method for configuring software using a business modeling tool
US7213232B1 true US7213232B1 (en) 2007-05-01
ID=37991568
US10/163,782 Expired - Fee Related US7213232B1 (en) 2001-06-07 2002-06-06 System and method for configuring software using a business modeling tool
US (1) US7213232B1 (en)
US20070192149A1 (en) * 2006-02-15 2007-08-16 International Business Machines Corporation System and method for managing risk in services solution development
WO2014152800A1 (en) * 2013-03-14 2014-09-25 Massively Parallel Technologies, Inc. Project planning and debugging from functional decomposition
2002-06-06 US US10/163,782 patent/US7213232B1/en not_active Expired - Fee Related
Aberer et al., Configuration of distributed message converter systems using performance modeling, IEEE, Apr. 2001 pp. 57-67. *
Coupaye et al., Foundations of enterprise software deployment, IEEE Feb. 29-Mar. 3, 2000 pp. 65-73. *
Gibson et al., Enterprise resource planning: a business approach to systems development, IEEE, Volume: Track7 1999 pp. 1-9. *
Haag, Sales configuration in business processes, IEEE, vol. 3 Issue: 4 Jul./Aug. 1998 pp. 78-85. *
Hall et al. A cooperative approach to support software deployment using the Software Dock, IEEE, May 16-22, 1999 pp. 174-183. *
Heimbigner et. al., A framework for analyzing configurations of deployable software systems, IEEE, Oct. 18-21, 1999 pp. 32-42. *
Jarzabek et. al., Model-based design of tools for business understanding and re-engineering, IEEE, Jul. 10-14, 1995 pp. 328-337. *
Sommerville, et al., Configuration specification using a system structure language, IEEE Mar. 25-27, 1992 pp. 80-89. *
US7933746B2 (en) 2005-05-06 2011-04-26 Targeted Convergence Corporation Relation-based product development
Kosanke et al. 1999 CIMOSA: enterprise engineering and integration
Macher et al. 2002 e-Business and disintegration of the semiconductor industry value chain
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:KNOWLES, G. GORDON;REEL/FRAME:012990/0641