Patent Publication Number: US-6665648-B2

Title: State models for monitoring process

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation of PCT Application PCT/US99/28357, filed Nov. 30, 1999 and Provisional Application No. 60/110,192, filed Nov. 30, 1998. 
    
    
     FIELD OF THE INVENTION 
     This invention relates to state models and state model development for defining and monitoring processes, more specifically, for monitoring industrial and business processes. 
     BACKGROUND 
     As the business environment becomes more complex, with multiple, overlapping channels, competing and complementary paradigms, providing customized products to large numbers of customers, it becomes absolutely essential for the enterprise to bring its business processes under control. Control of the business process must be accomplished in such a way as to provide management with accurate and current knowledge of the state of business, including deals in progress, and their progression through the enterprise. 
     There is an especially strong need for a readily scalable and readily deployable development environment, including development tools, to allow end users to develop business applications customized to their needs and derived from supplied base classes, functions, subroutines, and the like. 
     Likewise, in the industrial sector as industrial processes become longer and more complex, with parallel paths of discrete process steps, frequently carried out at different locations, leading to nodes, and to still further process steps. This has created a need for a readily scalable and readily deployable development environment to allow end users to develop industrial modeling applications derived from supplied classes, functions, routines, and subroutines. 
     A particular need for programming tools is in the area of the representation of a process as a sequence of discrete, frequently parallel, steps, as in flow charts, and especially funnel charts. 
     A further need exists for development tools for the development of pipeline models, as industrial, manufacturing or sales pipeline models. 
     A still further need exists for development tools for assistant modules, as industrial, manufacturing or sales assistant modules used to guide personnel through manufacturing sequences and sales transactions. 
     SUMMARY OF THE INVENTION 
     Our invention relates to state models of “objects” and especially configurable state models of “objects.” “Objects” which are referred to herein as “business objects” or as “objects” include sets of functions, and variables, characterized by permitted states and transitions, and prohibited states and transitions. The objects may model steps or states in a business process or in a manufacturing process. Objects may be called by an end-user, and incorporated into an end-user&#39;s programs, routines, subroutines, functions, and applets. According to our invention the “objects” are related to and/or are useful in one or more types of industrial and manufacturing processes, business transactions, and/or business processes, such as product fabrication, product assembly, warehousing, shipping, customer contacts, sales leads and referrals, orders, order configuration, and similar transactions. 
     The invention provides a method of preparing a state model of a process, as an industrial or business process. The state model defines the behavior of logical industrial or business objects in an industrial or business process model of the industrial or business process as a set of permitted states and a set of permitted transitions between the permitted states. This is done through the steps of selecting a template for the state model; selecting industrial or business object components for the state model; selecting or defining state transitions for the state model; defining permitted state transitions from a “from state” to a “to state” with a State Transition Rule name; associating state transitions with state transition rules, names, and conditions; enumerating the state transition names and state transition rule names; and extracting the state transition rules from a database. The states, transitions, and extracted rules make up a state machine execution engine; and process the industrial and/or business model through the state machine execution engine. 
     At least one of the state transition rules include prerequisites which must be met before the transition is permitted, and at least one of the state transition rules define authorized users for effecting a state transition. 
     In one embodiment of the invention the business objects define a manufacturing or sales pipeline funnel model (here illustrated as a sales pipeline) of a set of industrial processes or business deals (here illustrated as business deals), where the sales pipeline funnel shows business deals being worked in different methodologies on a single sales pipeline graphic. The methodologies are chosen from the, for example, telesales process deals, strategic deals, and standard process deals. 
     In this embodiment of the invention the business deals may be grouped by sales methodology, and classified as, for example, as qualifying deals, working deals, and closing deals. Similarly, industrial processes may be grouped by technology, physical processes, equipment, or the like. 
     In the case of business models, the method of the invention is practiced by creating a sales opportunity, creating a sales method, breaking the sales method into sales cycles within the sales method, and breaking the sales cycles down into sales phases for each sales cycle. In the case of industrial models, the method of the invention is practiced by creating process flows, manufacturing steps, identifying manufacturing steps to manufacturing equipment or processes, and introducing testing and/or quality control steps. 
     In carrying out the method of the invention a sales method is associated with a sales opportunity, and the sales opportunity is advanced based upon the associated sales method. Sales opportunities are sorted and grouped by at least one of sales methods, cycles, and phases. The deal data, grouped by one or more of sales method, sales cycle, and deal phase, to a charting engine, and from the charting engine to the Sales Pipeline Funnel Chart. 
     An aspect of the method of the invention is monitoring the state of deal or product as it moves from state to state, for example, to determine additional actions with respect to the deal or product. 
     Another aspect of the invention is assigning activity and assessment templates to a deal or product in process, for example, to assess the deal or manufacturing process flow using the assigned activity and assessment templates. 
     A further embodiment of our invention is a system running on at least one computer (but frequently on more then one computer, as a client and a server, or a web client and a web server and one or more application servers) for preparing a state model of a process as described above. The state model defines the behavior of logical business or industrial objects in a business or industrial process model of the process as a set of permitted states and a set of permitted transitions between the permitted states. The system is configured to: select a template for the state model; select object components for the state model; select or define state transitions for the state model; define permitted state transitions from a “from state” to a “to state” with a State Transition Rule name; associate state transitions with state transition rules, names, and conditions; enumerate the state transition names and state transition rule names; extract the state transition rules from a database; wherein the states, transitions, and extracted rules comprise a state machine execution engine; and process a business model through the state machine execution engine. 
     In the system and method of our invention we provide a unique integration, through a state model and state machine of several objects, as industrial or business objects, to provide graphical reports, such as a Multiple Method Sales Pipeline, a Funnel Chart Engine, and a set of reporting tools. As a result, data, including sales pipe line data and industrial work-in-progress data, can be reported graphically across multiple sales methods and industrial methods and locations using such techniques as funnel charting, sales pipelines, and customized reporting techniques. 
     The invention described herein includes a method and a system for preparing and using a state model of an industrial or business process. The state model defines the behavior of the logical objects making up a business process model of the business process as (1) a set of permitted states and (2) a set of permitted transitions between the permitted states. The state model is created by selecting a template for the state model, and selecting industrial or business object components for the state model (for example, by using “OOP” or other programming paradigms and methods as described herein). The user then selects or defines state transitions for the state model, for example, by defining permitted state transitions from a “from state” to a “to state”. This is the “configurability” aspect of the state model. The defined or selected state transition rules are identified to State Transition Rule names. That is, state transitions are associated to specific state transition rules, names, and conditions, and the state transition names and state transition rule names are enumerated. The specific state transition rules corresponding to the names are extracted from a database. The extracted states, transitions, and rules define the state machine execution engine. This state machine execution engine is used to process business models, as described herein. 
    
    
     THE FIGURES 
     The method and system of our invention may be understood with reference to the Figures. 
     FIG. 1 illustrates a flow chart of the Configurable State Module of the method and system of our invention. 
     FIG. 2 shows the relations of the state model, and specifically, the state model, the state, the state transitions, the state transitions and positions, and the positions. 
     FIG. 3 illustrates a screen shot of the State Model view of our invention. 
     FIG. 4 illustrates a funnel chart engine representation of the method and system of our invention. 
     FIG. 5 illustrates a flow chart of the method and system of the multi-method sales pipeline module of our invention. 
     FIG. 6 illustrates a flow chart of the Sales Assistant Module of the method and system of our invention. 
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     The system and method of our invention relate to “objects” including industrial and business objects, that are associated through a “configurable state model” having sets of permitted states and sets of permitted transitions to provide a manager with needed information, and with tools to extract, analyze, and display the information. This is accomplished through such business objects as an opportunity object, a sales method object, a multi-method sales pipeline object, and a funnel chart engine business object, as well as such industrial objects as manufacturing operations, manufacturing equipment, workflow, capacities, and the like. 
     As pointed out above, “objects” include sets of functions, variables, routines, and subroutines and configurable state models. Objects may be called by an end-user, and incorporated into an end-user program, routines, and applets. According to our invention when the “objects” are business objects they relate to and/or are useful in one or more types of business transactions and/or business processes, such as customer contacts, sales leads and referrals, orders, order configuration, and similar transactions. Similarly, when the “objects” are industrial objects they are related to and/or useful in one or more types of industrial, manufacturing, or warehousing processes. 
     Our invention utilizes a configurable state model of processes. The configurable state model defines the behavior of the logical industrial or business objects, including functions and variables therein, making up an industrial or business process model of the industrial or business process as (1) a set of permitted states and (2) a set of permitted transitions between the permitted states. 
     The Configurable State Model provides users with a data driven method for extending workflow control based on the status of an object. In order to make this work, users need to define the state model which consists of a set of acceptable states and state transitions. The state machine then ensures that these objects go through the desired process defined by the state model. 
     The configurable state model is created by selecting a template for the state model, and selecting business object components for the state model (for example, by using “OOP” methods, such as calling a member function with a calling object, using the C++ syntax Calling_Object.Member_Function (Argument_List) as described herein or the JAVA syntax, or by calling routines, subroutines, functions, and the like as in conventional programming paradigms, using, for example BASIC, FORTRAN, C, and the like). The user then selects or defines state transitions for the state model, for example, by defining permitted state transitions from a “from state” to a “to state”, as by specifying arguments in the “Argument_List” of the called Member_Function. The defined or selected state transition rules are identified to State Transition Rule names. That is, state transitions are associated to specific state transition rules, names, and conditions, and the state transition names and state transition rule names are enumerated, using object oriented programming methodology. The specific state transition rules corresponding to the names are extracted from a database of state transition rules. The extracted states, transitions, and rules define the state machine execution engine. This state machine execution engine is used to process business models, as described herein. 
     In the configurable state model and associated applications of the method and system of our invention, we provide a unique integration of several business objects with an interactive synergy therebetween through the configurable state model. 
     For example, in the Funnel Chart application of our invention, multiple streams of sales transactions and customers at different levels of completion can be integrated and the resulting sales pipeline data can be reported graphically across multiple sales methods using funnel charting technique. Similarly the Funnel Chart application of our invention can be used to graphically report industrial processes similar to the “N Server-M Queue” models. 
     The components that are associated in the system and method of the invention are: 
     A state model which is a characterization of objects as a set of configurable state models, each configurable state model itself being a set of permitted states and permitted transitions between the permitted states, including permitted state transitions, prerequisites for transitions such that one cannot move into the next stage until the prerequisite is met, and actors that are permitted to move the process to a stage (e.g., only specific users may change the status of the object to “approved” or “closed.”). 
     A funnel chart engine, as shown in FIG. 4, that, given specific charting instructions, generates graphical chart based on the sales pipeline and sales methods. As shown in FIG. 4, the funnel chart engine breaks deals up into classes, for example, qualifying deals, working deals, and closing deals. Within each class are categories of deals, such as telesales process deals, strategic deals, and standard process deals. 
     An opportunity object which is a business object that keeps information about a sales opportunity. 
     A sales method object which is a business object that allows a user to create and store data related to sales methodology, including sales cycles and phases. 
     Related objects for industrial processes can include shop orders, equipment and process flow chart and sequencing parameter data, capacities, and the like. 
     Specific Components of the System and Method 
     State Model 
     Returning to the state model, the state model is part of the system and method of our invention. A state model is an abstraction of a digital device where the present state (output state) of the model is a function of its immediately preceding state (input state) and of a binary control signal (input control signal). In a state model, the output state of the model is a unique function of the input state and the input control signal ( 0 ,  1 ). According to the system and method of our invention, the “state model” works through a “state machine” with the business objects to define allowable state values, transitions, and paths. 
     The state model defines the behavior of logical objects, as industrial or business objects, as a set of states and transitions between states. In addition to defining the universe of permitted values and transitions, the state model allows administrators to define prerequisites for transitions such that one cannot move into the next stage until the prerequisite is met. 
     The state model also defines authorized “users” (by title or by security access or the like) that are permitted to move the state model of a transaction or workpiece to a state. Only specific users may change the state of the object, for example by advancing it to the next state, or to “approved” or “closed.” Moreover, the authority or power to change the state of an object may be function of both the user and the present state. For example, a manager may have the power to “approve” or “disapprove” a deal at the nth state, but not when the deal reaches the n+1th state. Similarly, a manufacturing technician can divert a workpiece from the nth tool to the n+1th tool, but can not divert the workpiece further once it has reached the n+1th tool. “Position” as shown in blocks  70  (“State Transition/Position”) and  75  (“Position”) of FIG. 2 defines the “user.” 
     The state model is the blueprint of acceptable states and state transitions that the state machine will enforce. The state machine then ensures that these objects go through the desired process defined in the state model. 
     A state machine is an engine that enforces the transitions between states for an object during its lifetime. A state represents the status of an object, such as Open, Closed, Pending, and so on. The state represents where the object is in its lifetime. The state machine can also control whether or not the data of that object can be modified or not. As an example, a Service Request that is in a Closed state may be considered “frozen”, such that its attributes cannot be modified. 
     A state transition defines the allowable migration of an object from one state to the next. For instance, a Service Request that has been closed but must be re-opened may go from the Closed state to an Open state, and may go from Open to Pending, but may not transition directly from Closed to Pending. The allowable migration of a Service Request from Closed to Open, or Open to Pending, represents defined state transitions. The state transition can also enforce other behavior. The state transition definition can verify that specific conditions have been met before the transition occurs. The state transition definition can also control what individuals or groups of individuals can initiate the transition. 
     Configurable State Models—Technical Description 
     The Configurable State Model module illustrated in FIG. 1 provides users with a data driven method for extending workflow control based on the status of an object. In order to make this work, users need to define the state model, which consists of a set of acceptable states and permitted state transitions. The state machine then ensures that these objects go through the desired process defined by the state model. According to the system and method of our invention, the configurable state model is used in the context of logical business objects. Specifically, state model states and transitions are defined for business objects using an intuitive user interface, with limitations put upon those who can transition objects from one state to another state. FIG. 3 is a screen shot of the State Model view of our invention. 
     The State Model consists of the following components: 
     State: The state is the status of an object. This can also refer to the value of an attribute where the attribute will change values over the life of the object. Value can be Boolean, alphanumeric, or numeric. 
     State Transition: A state transition is a linkage or set of linkages between two states that define the allowable migration from one state to the next. We can add the rule validations to a state transition and the state machine will determine if we can advance to the next state or not at run time. Also we can define who has the privilege to advance to the next state by defining the authorized users. 
     State Model: The state model is the set or blueprint of allowable states and state transitions that the state machine will enforce. 
     State Machine. The State Machine is the engine that enforces the states and state transitions that an object may go through during its lifetime. 
     As shown in FIGS. 1,  2 , and  3 , the first step in the method of our invention is to create a state model or modify an existing state model, block  61  of FIGS. 1 and 2 and block  62  of FIG. 2 where certain parameters (“State Model ID,” “Value,” “Description”). This is illustrated in FIG. 3 as the actions called for in the top block, that is, entering and/or selecting the “State Model,” the “Business Component” of the “State Model”, the “Field”, and the “Activation Date/Time” and the “Expiration Date/Time”. The next two steps are to “Create/Modify State Transition for a State Model” as illustrated in block  63  of FIGS. 1 and 2, and “Associate State Transition With Rules and Conditions” as shown in block  65 . This is illustrated by block  65  of FIG. 2 (where “State Model ID,” “From State ID,” “To State ID,” “Field Name,” “Operator,” “Value,” “Rule,” “Public Flag,” and “Description” are entered into the “State Transition” block). Each permitted transition has a “From State Name”, a “To State Name”, a “Public Flag”, a “Rule Field Name” a “Rule Operator”, and a “Rule”. Typically, state machine and state model rules are expressed as “If present state is ‘0’ and input is ‘0’, then new state is ‘1’, but if input is ‘1 ’,then new state is ‘0’; and if present state is ‘1’ and the input is ‘0’, then the output is ‘0’. but if the input is ‘1’, then the output is ‘1’. 
     As shown in the next block of FIG. 1, entering these rules into the graphical user interface of FIG. 3 causes the appropriate rules to be extracted from the database, block  67 , and, in the next block, assembled into a state machine execution engine, block  69  of FIG.  1  and implemented as in block  70  of FIG.  2 . This produces an enforced state model on targeted business objects, block  71 , and the target business object is enabled, as shown in block  73 . 
     The State Model Class Definition reproduced in Appendix A and the State Machine Source Code is reproduced in Appendix B. 
     Multi-Method Sales Pipeline 
     The multi-method sales pipeline method and system of our invention is illustrated in FIG.  4 . FIG. 4 shows a large funnel  1  and small funnels  11 ,  13 , and  15  representing deals being worked in different methodologies on a single sales pipeline graphic. The small funnels,  11 ,  13 , and  15 , represent the sales pipelines of a group of deals being worked in a single methodology. The bigger funnel  1  at the top represents a way to combine the small ones and compare the value of all of the deals to the sales person&#39;s quota. As shown in FIG. 4, the funnel chart engine breaks deals up into classes, for example, qualifying deals,  3 , working deals,  5 , and closing deals,  7 . Within each class are categories of deals, such as telesales process deals,  11 , strategic deals,  13 , and standard process deals,  15 . 
     A flow chart of this embodiment of the system and method of our invention is shown in FIG.  5 . As shown in FIG. 5, an opportunity is created on one side, block  21 , and a sales method is created on the other side, block  31 , which method is broken down into sales cycles within the sales method, block  33 , and further broken down into sales phases, block  35 , for each of the sales cycles, block  33 . The processed sales method and the opportunity are brought together, as shown in block  37 , and the sales method associated with a sales opportunity. The sales opportunity is then advanced based upon the sales method, as shown in block  39 . The sales opportunities are then sorted and grouped by sales methods, cycles, and phases, as shown in block  41 . The data, grouped by sales method, sales cycle, and deal phase, is then passed to a charting engine, as shown in block  43 , and from the charting engine to the Sales Pipeline Funnel Chart of FIG. 4, as shown in block  45  of FIG.  5 . 
     Sales Assistant 
     The sales assistant module of the system and method of our invention monitors the state of the deal as it is being worked and suggests, but need not require, specific actions and evaluations (“assessments”) that should be performed based on the methodology employed for that specific deal. Using the state model, as deals move from stage to stage, the sales assistant module continues to monitor the deals to determine (based on the then current methodology) whether additional actions or assessments should be suggested. A flow chart for the Sales Assistant is shown in FIG.  6 . 
     The Sales Assistant is a coaching tool. With the Sales Assistant, everyone in an organization can learn from each other, and especially from the most experienced sales reps. Activity Templates automatically list, schedule, and assign all of the activities that are needed to move sales opportunities quickly from one sales stage to the next. Assessments compare like opportunities with a “model” or “optimal” opportunity. 
     As shown in the flow chart of FIG. 6, templates, such as a Sales Assistant Activity Template, block  51 , and a Sales Assistant Assessment Template, block  53 , are created. These two templates are then manually assigned to Opportunities, Accounts, and Contacts, in block  55 . Meanwhile, the templates are also associated with sales methods and opportunities, as shown in block  57  on the right hand side of FIG. 6, and then associated with opportunity sales methods, block  59 , and the sales cycles are advanced, block  61 . Sales cycles are advanced using the permitted states and the permitted transitions of the state model described herein above. The activity templates and assessment templates are then assigned, block  63 , and the assessments and activity plans performed, block  65 . The product or output of the assessment and activities function, block  65 , is the suggestion of additional actions and assessments, based upon permitted states and state transitions, and the comparison of the deal with optimal deals. 
     Sales Assistant Module 
     Sales Assistants Module Technical Description: 
     Sales Assistants provide a unique method to facilitate and to monitor the life cycle of a sales opportunity, account or a contact. The components included in a C++ exemplification of this method are: 
     Activity Template Object—a business object that holds a set user definable actions that can be applied to an opportunity/Account/contact. 
     Assessment template object—a business object that holds a set of user definable assessment rules for evaluating the quality of an opportunity/account/contact. 
     Sales Assistant Agent—a smart agent program that can assign Activity and Assessment to an opportunity/account/contact based on the sales methodology and cycles. 
     It would, of course, be understood that the Sales Assistant methodology can be used for production planning and debottlenecking, among other industrial applications. 
     The following Appendices are code listings for the methods described herein.                                                            
     While the invention has been described with respect to certain preferred embodiments and exemplifications, it is not intended to limit the scope of the invention thereby, but solely by the claims appended hereto.