1. Field of the Invention
The present invention generally relates to computer/user interactive systems and, more particularly, to an interactive tooling framework that can accept multimodal input, including voice input, and responds with multimodal output, including synthesized voice output, to guide a user in progressively creating a business model.
2. Background Description
State of the art tooling available for business analysts to create business process models is inherently passive and inflexible in nature. Typically, the tool will have a pallette of icons representing modeling artifacts. The analyst is given a graphical whiteboard where he or she drags one or more of these icons and wires them together to create the desired business process. This process sounds conceptually easy, but unfortunately it is far from easy in practical application. Each of these icons have some semantic meaning, and wiring between them also needs to be semantically correct. The tools are quite inflexible and unforgiving to wrong or partial input. In addition, the set of icons and their wiring vary from tool to tool based on the business model on which it is based on. Thus, the analyst has to go through a painful learning process before he or she can start to be productive. The analyst's expertise lies in the knowledge of the business, and he or she has a unique way of formalizing or visualizing it. Unfortunately, the current toolsets follow a “one size fits all” philosophy which, in most cases, is alien to the way the analyst thinks about their business.
It is therefore an object of the present invention to provide an interactive tooling framework that can accept multimodal input, including voice input, and respond with multimodal output, including synthesized voice output, to guide the user in progressively creating a business process model.
According to the invention, the business analyst starts by selecting the type of model he or she wants to create. The system then engages analyst in a (potentially long running) conversation where appropriate input is solicited from the analyst at different steps of creating the model. The advantages of the invention are the following:
The foregoing and other objects, aspects and advantages will be better understood from the following detailed description of a preferred embodiment of the invention with reference to the drawings, in which:
Referring now to the drawings, and more particularly to
The multimodal processor 201 is responsible for processing and converting input from the user to text, which may optionally be displayed to the analyst for visual feedback. The user input may be in the form of spoken words, keystrokes, mouse movements and clicks, and, if the computer interface is equipped with a video capture device, gestures. Similarly, the multimodal processor 201 converts text responses from the system to user output, including synthesized voice output. The text from the system may also be displayed. In other words, the multimodal processor 201 integrates the functions of a voice recognition system, image capture system and a voice synthesizer system, together with a keystroke and pointing device capture system and a display driver system, all of which is well known in the art.
The conversation policy is implemented in a play-in scenario conversation policies 202, for the user state conversation support module 203 and for the model state conversation support module 204. These conversation support modules 203 and 204 support the interactive play-in scenarios by which input is solicited and response is sent to/from the user. Each of the user state conversation support module 203 and the model state conversation support module 204 are, in turn, supported by respective text analyzers 205 and 206 which access a common scenario vocabulary database 207.
For different business models we could expect to have one or more such play-in conversation policies 202. For example, in modeling at the operation level, the scenario could start by asking for the list of transactions in the process. Another play-in scenario could start with listing the main business objects/artifacts of the process and then tasks that use and manipulate them.
The conversation support module 203 running on behalf of the user is responsible for maintaining the state of the conversation and enforcing protocols defined in the currently loaded and active conversation policy. It accepts text input from the multimodal processor 201, and validates it using text analyzer 205 to select the appropriate state transitions. The conversation support module 204 running on behalf of the system maintains the state of model creation. It accepts text messages from the user side conversation support module 203, and validates it with the text analyzer 206. The text input is converted to appropriate model artifacts and passed onto the model synthesizer 208.
The model synthesizer 208 holds in memory the instance of the model as it is being progressively created. Each instance will be based on a particular meta model 30. It will accept appropriate input from the conversation support module 204 to add or modify the in-memory model instance. In case of erroneous input, it will respond appropriately which then propagates back to the user. Given the current completion state of the model instance, it will solicit the next level of input from the user.
The conversation completes with a completed in-memory model instance 40. The model instance can then be exported to the file system in a suitable format, e.g., an XML file.
In the preferred embodiment of the invention, the browser implemented on the user computer interface 15 has a graphical representation of the model instance being created. The multimodal processor 201 is preferably implemented using IBM's Websphere Voice Server. The conversation support modules 203 and 204 are preferably implemented as conversation adapters employing IBM Alphaworks release—Conversation Support for Web Services. The preferred embodiment uses the Operation Model as the business proess meta model 30. An Operational Model Synthesizer 208 is created to corresponding to that and outputs the model instance 40 as an XML file.
As a specific example, the invention will be described in terms of a just-in-time (JIT) scheduling process. Suppose a valued customer informs the manufacturer that they wish to increase the quantity of a product that is on order and due to be shipped within the next three days. The order change request is received by the manufacturer's Fulfillment Department, which keeps a record of it and sends a “build schedule change request” to the Scheduling Department. The Scheduling Department is responsible for implementing the JIT Scheduling process.
The Scheduling department, upon receiving the build schedule change request, first uses a capacity scheduling application to determine whether the company has the capacity to produce the increased order quantity in the available time. If sufficient capacity is not available, then a negative response is returned to the Fulfillment Department. If, on the other hand, sufficient capacity is available, the next task is to check the supply plan to see if the planned inventories of all the raw materials needed for the increased order are expected to be in stock. If they are, then the build schedule change request is passed on to the “update build plan” task. Here the build plan is modified to reflect the increased production for the changed order, and a positive response is sent to the Fulfillment Department.
In the event that the supply plan indicates a shortage of one or more components needed to manufacture the product, in the check supply task a set of “part requests” is created, one for each component in short supply. Meanwhile, the build schedule change request is put into a “pending” state, which indicates that it cannot be further processed until processing of the part requests is completed. The part requests are processed individually by the “request supply” task, in which the company's procurement department consults a supplier profile database to look up the primary supplier(s) for that part. If the primary supplier is able to provide the increased quantity, then the pending request is updated with the required quantity of a part on the spot market. The results of this effort are used to update the pending request as well.
If any part cannot be acquired cannot be acquired in the required quantity, the pending request can be immediately processed by the “completion” task, and all remaining parts requests cancelled. The completion task returns a negative response to the Fulfillment Department. If and when all part requests are successfully returned, indicating that all parts could be procured, then the completion task can begin. In “completion”, the company considers the responses from the suppliers, including price, and decides whether to approve the build schedule change request. If the decision is negative, that message is returned to the Fulfillment Department. If the decision is positive, then the suppliers' pending orders are confirmed, the supply plan updated, and the acceptance of the build schedule change request is relayed back to the Fulfillment Department.
With this background example, a play-in scenario conversation for the JIT process will now be described as a dialog between the Analyst and the System. The bold-faced words are part of the play-in scenario vocabulary. During the conversation, the text analyzer extracts these keywords and passes them onto the conversation policies. These keywords are mapped to state transitions on the CPs and the output is either sent to the user as system response or to the model synthesizer as model input.
The process is illustrated in the state chart diagram of
The process of the Task play-in scenario conversation policy (CP) is shown in the flow diagram of
The information gathered for the JIT process in this example is summarized below:
Fulfillment
Base Request
Parts Request
Build Plan
Supply Plan
Vendor Profile
Check Capacity
Check Supply
Update Schedule
Source Parts
Spot Purchase
The synthesized JIT Process Model for the example given is shown in the block diagram of
While the invention has been described in terms of a single preferred embodiment, those skilled in the art will recognize that the invention can be practiced with modification within the spirit and scope of the appended claims.
The subject matter of this application is related to that of co-pending U.S. patent application Ser. No. 10/128,864 filed Apr. 24, 2002, by James E. Hanson et al. for “Apparatus and Method for Providing Modular Conversation Policies for Agents” (IBM Docket YOR920020017US1) assigned to a common assignee herewith. The disclosure of application Ser. No. 10/128,864 is incorporated herein by reference.