Aspects of the present invention relate to process monitoring, and more particularly to a method, system and computer program product for defining and monitoring processes at a monitoring-level view.
Implementations of real-world processes are usually quite complex. For example, a fulfillment process may involve hundreds of implementation steps that run on one or more process engines. When trying to monitor such processes using conventional process monitoring tools, business users are often overwhelmed by this large number of implementation steps. While business process modeling tools can be used to draw simplified, higher level views of such processes and often are used to obtain a simplified view there is currently no way to link such a view to the implementation, so that process executions can be monitored in real time at the higher abstraction level
According to one aspect of the present invention, a method for process monitoring may include generating a monitoring-level process model. The monitoring-level process model may include a monitoring-level view of a process and be associated with one or more implementation-level process models. The implementation-level process model may include a series of implementation-level steps to perform the process. A selection of a monitoring-level step in the monitoring-level process model may be received. Also, a selection of at least one implementation-level step in the implementation-level process model may be received. The implementation-level steps may be associated with the monitoring-level step.
According to another aspect of the present invention, a system may include a processor and a tool, operating on the processor, for process monitoring. The tool for process monitoring may allow a monitoring-level process model to be generated, drawn or loaded. The monitoring-level process model may include a monitoring-level view of a process and be associated with one or more implementation-level process model(s), where the implementation-level process model(s) may include a series of implementation-level steps to perform the process. A selection of a monitoring-level step in the monitoring-level process model may be received. Also, a selection of at least one implementation-level step in the implementation-level process model(s) may be received. The implementation-level steps then may be associated with the monitoring-level step.
According to a further aspect of the present invention, a computer program product for process monitoring may include a computer readable storage medium having computer readable program code embodied therewith. The computer readable program code configured for generating, drawings or loading, by a computer system, a monitoring-level process model. The monitoring-level process model may include a monitoring-level view of a process and being associated with one or more implementation-level process model(s). The implementation-level process model(s) may include a series of implementation-level steps to perform the process. The computer readable program code may also include computer readable program code configured for receiving a selection of a monitoring-level step in the monitoring-level process model. The computer readable program code may additionally include computer readable program code configured for receiving a selection of at least one implementation-level step in the implementation-level process model(s). The computer readable program code may further include computer readable program code configured for associating the at least one implementation-level step with the monitoring-level step.
According to a further aspect of the present invention, another method for process monitoring may include generating, drawing or loading a monitoring-level process model that may include a monitoring-level view of a process and may be associated with one or more implementation-level process model(s). The implementation-level process model(s) may include a series of implementation-level steps to perform the process. The method may further include receiving a selection of a monitoring-level step in the monitoring-level process model and receiving a selection of event points in the implementation models that signal a change in status of the monitoring-level step. The change in status of the monitoring-level step is associated with the corresponding event point in an implementation-level process model.
The present invention is further described in the detailed description which follows in reference to the noted plurality of drawings by way of non-limiting examples of aspects of the present invention in which like reference numerals represent similar parts throughout the several views of the drawings and wherein:
As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware aspect, an entirely software aspect (including firmware, resident software, micro-code, etc.) or an aspect combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing. Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to aspects of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
The process that is to be monitored can be any process where a user desires to monitor the status of the process. The process can be a business process, such as fulfilling orders and shipping goods, or the process can be a non-business process, such as a person monitoring flights, tracking a package, monitoring the status an insurance claim, and the like.
The monitoring-level process 103 may include a series of monitoring-level steps 105 that may be an outside-to-in view or a top-down view of the process to be monitored. According to some aspects, the monitoring-level process may be a simplified overview or an abstract representation of the implementation-level steps 104. The monitoring-level process 103 may not be a portion of the software program used to actually implement the process and thus, may not be executing instructions using the process engines, messaging engines, or other business integration software platforms 107, according to some aspects.
As is discussed later in
An example of a monitoring-level process includes selling and delivering of goods. Specifically, a monitoring-level process for selling and delivering goods may include a seven-step process: 1) receive an order from customer; 2) validate order and customer information; 3) check inventory; 4) fill order; 5) ship goods; 6) send invoice; and 7) receive payment. This monitoring-level process has seven steps, but may have hundreds of implementation-level steps implementing the process. For example, for the first monitoring-level step of “receiving an order from a customer,” there may be several implementation-level steps required to complete the monitoring-level step, such as “call graphical user interface to allow user for inputting order,” “open IP portal,” “present graphical user interface to user,” “receive data packets from graphical user interface,” “store IP address of customer,” “transmit data packets to web server,” “unpack data packets from web server,” “input order information into proper variables,” “create order number,” “create order entry into database,” “store order number into order entry on order database,” “store other order data into order entry on order database,” “determine if any errors have occurred,” etc. Because these steps are implementation-level and thus, may have a level of detail that a business person may not desire to monitor, a monitoring-level view (e.g., “receive order from a customer”) may be instead more desirable.
Another example of the above-mentioned monitoring-level step may include “check inventory” which may require a large number of implementation-level steps or interactions with humans and systems. These implementation steps may include looking up storage bin numbers, finding alternative items or initiating replenishment when goods are not in stock, calling the customer to see if a partial order can be shipped, etc. Yet, an operations manager tracking order fulfillment, or an executive asking for status, may not be interested in that level of detail. His view of the process is the simple seven-step flow outlined above, and he may desire to monitor the process at that abstraction level.
In one aspect, methods, systems and computer program products described herein enables users to configure business process monitoring outside-to-in starting from the business user's perspective. This allows for reconciliation of a monitoring-level view of processes with the possibility of a much more detailed implementation. The methods, systems and computer program products, as described herein, may offer a side-by-side view of the monitoring-level process (e.g., business user's view) and a list of processes and activities implementing the monitoring-level process (e.g., implementation-level view). The methods, systems and computer program products also allow users to specify which implementation-level activities correspond to each step in the monitoring-level process model. This information is used at runtime to show progress at the higher abstraction level, such as when the first implementation-level steps that corresponds to “check inventory” starts, the corresponding monitoring-level step is considered in progress, etc. A more detailed description of some aspects is provided below with regard to
Referring back to
In block 208 of
In block 210, a selection of the implementation-level step(s) that corresponds to the selected monitoring-level step is received by the system. These implementation-level step(s) correspond to the selected monitoring-level step discussed above in block 206 so that, when viewing the monitoring-level process, the monitoring-level step will reflect or indicate the status of the implementation-level step(s).
In block 212, a collection of links 214 is created that indicates the associations between the monitoring-level step and the corresponding implementation-level step(s) similar to that previously described with reference to
In decision block 216, a determination may be made as to whether any monitoring-level steps are left to be associated with implementation-level steps. If all monitoring-level steps that have been desired to be associated have been associated, then the method 200 may continue to block 218; otherwise, the method 200 may return to block 206 where the next monitoring-level process step is selected and processed similar to that discussed above with regards to blocks 208-212.
In block 218, at least one monitoring-level instance identifier for the monitoring-level process is identified or selected. A monitoring-level instance identifier may relate to a parameter that will identify one or more specific instances of the monitoring-level process. For example, if a monitoring-level process is configured to illustrate selling and delivering goods, a monitoring-level instance identifier may be a specific order number, which allows a manager to view the status of a single customer order associated with the order number. It should be understood that a single monitoring-level instance identifier may be associated with more than one instance of a monitoring-level process, for example when customer orders are bundled. Consequently, according to some aspects, more than one monitoring-level instance identifier may be required to uniquely identify a monitoring-level process instance. For example, more than one monitoring-level instance identifier may be needed for a process of tracking or monitoring airplane flights, where both the flight number and the flight date would be needed in order to pinpoint the “instance” of a flight.
In block 220, a user is presented with a list of process variables, or other parameters, such as fields of input or output messages, of each referenced implementation-level process, and a selection of a process variable or parameter (or path into a variable or parameter if those have a complex structure) corresponding to each monitoring-level instance identifier is received. The selected process variable or parameter may be the variable or parameter which defines the data and/or instance(s) that the monitoring-level process will present. For example, if a user desires to monitor customer orders, then the user needs to define a way to identify which customer orders the user desires to view. As such, the user may decide that she wants to identify customer orders by the order number and in that event, the user will need to indicate to the monitoring-level process model that the process variable is the “order number.” And since the process variable has been set to be the order number, the user can then simply tell the system the specific order number that the user desires to monitor and the system will then retrieve the corresponding information associated therewith, by using the process variable or parameter that has been selected to correspond to “order number”, to find the implementation-level process instances for a specific order. For example, assuming the user has selected the monitoring-level instance identifier to be “order number,” and selected a process variable “orderNo” as the corresponding process variable, when the user selects a specific order number (e.g., order #1308), the user then will view the status of the order of that specific order number in the monitoring-level process. If the user instead would like to view all orders by “customer ID,” the user should indicate a process variable as “customer ID.” An example of selecting the process variable is illustrated in
In block 504, a list of monitoring-level instance identifiers may be presented to the user. These monitoring-level instance identifiers may be taken from the currently running or completed executions of the corresponding implementation-level processes, where the values of the process variables or parameters identified in block 220 may be used to establish this list. In block 506, at least one monitoring-level identifier is selected, or entered manually if a selection has not been provided, for the desired monitoring-level process. The monitoring-level identifier effectively selects which instance of the monitoring-level process to view. For example, as previously discussed, a selection of a monitoring-level identifier could be an “order number” in the case of monitoring the status of purchase orders, which will allow a user to select a specific “order number” (or group of order numbers) to monitor at a time. In block 508, a determination is made as to whether an identifier is selected. If not, the method 500 returns to blocks 504 and 506; otherwise the method 500 may proceed to block 510.
In block 510, the system selects the corresponding process executions based on specified monitoring-level identifier(s) values and the corresponding variable selections, previously discussed in method 200 of
In block 512, a determination is made as to the status of the implementation-level steps that were mapped to the monitoring-level process steps. Once the status of the implementation-level steps is determined, the status of the monitoring-level process steps can then be derived and updated in the monitoring-level process view.
In block 514, the status of each monitoring-level step is set in the monitoring-level process model. For example, when all implementation-level steps for a corresponding monitoring-level step are completed or skipped, then that corresponding monitoring-level step is marked as “completed.” When none of the implementation-level steps corresponding with a monitoring-level step has been started, then that corresponding monitoring-level step is marked as “not started.”When at least one of the implementation-level steps corresponding with a monitoring-level step has been started, but not all such steps have been completed, then that corresponding monitoring-level step is marked as “in progress.”
These representations are then presented to the user visually (or possibly audibly) through the monitoring-level process, as described in block 515. The status of each step of the monitoring-level process may be indicated in any manner, such as by changing the color of box around each monitoring-level step to indicate the status. This process can be viewed in
In decision block 516, a determination is made as to whether the monitoring session has ended. Such determination may be made, for example, if the user logs out or some other indication is received indicating to end the monitoring session. If block 516 determines that the monitoring session has ended the method 500 continues to block 518 where the method 500 ends; otherwise, the method 500 may proceed back to block 512 to repeat blocks 512, 514 and 515, all of which have previously been discussed.
Notably, as previously mentioned with regard to
In block 708, a selection is received of event points that signal a change in status (e.g., start, end, pending, etc.) of the currently selected monitoring-level step. For example, if an event point indicates that a product has been loaded onto a delivery vehicle, then the monitoring-level step of “deliver goods” will be marked as “started.”
In block 710, a collection of links 712 is created between monitoring-level step status changes (e.g., step 1 start, step 1 end, step 2 start, etc.) and corresponding event points. Those links may be stored as part of the monitoring-level process model 703.
In block 714, a determination is made as to whether any monitoring-level steps are left to have event points selected that indicate their status changes. If so, the method 700 may proceed back to block 704; otherwise, the method 700 may proceed to block 716.
In block 716 at least one monitoring-level instance identifier for the monitoring-level process is specified. This is similar to block 218 of
In block 718, the user is prompted with a list of fields in the events of each event point. In response, the system receives a selection of a field (or path into the event's data structure) that corresponds to each monitoring-level instance identifier. The event field selections that for each monitoring-level instance identifier are stored in a database 720, and optionally may be stored as part of monitoring-level process model 703 as indicated by the dotted line and
According to some aspects, process monitoring may extend beyond mapping implementation-level steps to monitoring-level steps and tracking the monitoring-level process. For example, a frequent monitoring goal may be to measure the time it takes to get from one point in the monitoring-level process to a later point, where such a “path” can comprise multiple implementation-level steps. A business user could define two points in the monitoring-level process graph as representing the start and end of such path and instruct the system to monitor the time between these points. Furthermore, a user could highlight a decision in the monitoring-level process, and instruct the system to monitor the branching probabilities. Using such “point-and-click” techniques of specifying monitoring goals is dependent on having a view of the process that business users can understand and relate to.
The system 900 may include a module for a process monitoring 902 operable on a computer system 904, or similar device of a user 906 or client. Alternatively, or in addition to the process monitoring module 902 on the user's computer system 904 or client, the system 900 may include a server process monitoring module 908 operable on a server 910 and accessible by the user 906 or client 904 via a network 912. The methods 200, 500, 700, 800 may be embodied in or performed by the process monitoring module 902 and/or the server process monitoring module 908. In one aspect, the methods 200, 500, 700, 800 may be wholly performed by the process monitoring module 902. In another aspect of the invention, the methods 200, 500, 700, 800 may be wholly performed by the server process monitoring module 908. In a further aspect of the present invention, some of the features or functions of the methods 200, 500, 700, 800 may be performed by the process monitoring module 902 on the user's computer system 904 or client and other features or functions of the methods 200, 500, 700, 800 may be performed on the server process monitoring module 908.
The network 912 may be the Internet, a private network or other network that allows for interaction between the server(s) 910 and the computer system 904. Each computer system 904 may be similar to the exemplary computer system 904 and associated components illustrated in
The user's computer system 904 may include a speaker 929 and a speaker 925 or speaker system. The display may present the monitoring-level process model when monitoring a process as described herein. Any GUIs associated with the virtual world viewers may also be presented on the display 929. The speaker 925 may present any voice or other auditory signals or information to the user 906.
The user's computer system 904 may also include one or more input devices, output devices or combination input and output device, collectively I/O devices 927. The I/O devices 927 may include a keyboard, computer pointing device or similar means to control operation of avatars and VW viewer features and to enter information into various GUIs as described herein. The I/O devices 927 may also include disk drives or devices for reading computer media including computer-readable or computer-operable instructions.
The process monitoring module 902 may be stored on a file system 916 or memory of the computer system 904. The process monitoring module 902 may be accessed from the file system 916 and run on a processor 918 associated with the computer system 904.
The process monitoring module 902 may include a module to select monitoring-level identifier(s) 920 (hereinafter “identifier selection module”). The identifier selection module 920 allows presentation of a list of monitoring-level identifiers 938 and allows the user to input into the computer system 904 an entry or selection of at least one monitoring-level identifier. Input of the monitoring-level identifier(s) may be allowed via any manner, such as presenting one or more interactive GUIs or the like.
The process monitoring module 902 may include a module to send and receive data to/from server 922 (hereinafter “send/receive module”). The send/receive module 922 allows for data to be exchanged between the computer system 904 and the server 910 and may call one or more modules in the server 902.
The process monitoring module 902 may also include a module to present/update monitoring-level process 924. As previously discussed, a monitoring-level process may be presented to the user and may be constantly being updated with the status of the monitoring-level steps via the module to present/update monitoring-level process 924. The module to present/update monitoring-level process 924 also may control presentation of the monitoring-level process to the user, as previously discussed with regard to
The process monitoring modules 902, 908 may present one or more predetermined GUIs 926, 926′ to permit the monitoring-level process model to be drawn, loaded, generated, configured and/or monitored. The GUIs 926, 926′ may include a GUI to allow the user to define the monitoring-level process monitor, as previously discussed. These GUIs 926, 926′ may be predetermined and presented in response to the user indicating the user would like to enter/select data, information and/or settings. The predetermined GUIs 926, 926′ may be generated by the process monitoring module 902, 908 and may be presented on the display 929 of the computer system 904. The GUIs 926, 926′ may also include GUIs to permit the user to select monitoring-level instance identifier(s) and monitor the monitoring-level process, as previously discussed.
The server process monitoring module 908 may include a module to create monitoring-level process model 928, module to associate monitoring-level and implementation-level model steps (“mapping module”) 930, monitoring-level process models 932, module to monitor monitoring-level process 934, implementation-level process models 936, definitions of monitoring-level instance identifiers 938, and relationships of those with process variables or event fields 940. These modules 928, 930, 932, 934, 936, 938, 940 of the server process monitoring module 908 may be included within the process monitoring module 902. For example, the functionality of modules 928, 930, 932, 934, 936, 938, and/or 940 of the server process monitoring module 908 may be performed on the server process monitoring module 908 and/or on the process monitoring module 902 of the user's computer system 904.
In an aspect of the present invention, some of the features or functions of the methods 200, 500, 700, 800 may be performed within the process monitoring module 902 on the user's computer system 904 and other features or functions of the methods 200, 500, 700, 800 may be performed within the server process monitoring module 908 on the server 910.
The server process monitoring module 902 may include the module to create monitoring-level process model 928. As previously discussed with regard to blocks 202 and 702 of
The server process monitoring module 902 may also include the mapping module 930. The mapping module 930 allows for associating steps or event points of an implementation-level process 936 to the monitoring-level process model 932, as previously discussed with regard to blocks 212 and 710 of
The server process monitoring module 902 may additionally include the module to monitor a monitoring-level process 934. The module to monitor a monitoring-level process 934 allows a user to monitor a selected monitoring-level process 932 by entering or selecting specific values for monitoring-level instance identifiers 938, as previously described by
The server process monitoring module 902 may also include implementation-level processes 936. The implementation-level processes 936 contain a plurality of implementation-level steps, each of which may relate to software program(s) which contain computer program code to perform one or more functions for the process to be monitored. The implementation-level processes 936 allow for programs to receive inputs manually and/or automatically and are not to be limited to only software programs but any other means which can achieve a function for the process to be monitored. For example, an implementation-level step could consist of a person scanning packages being loaded on a truck, in which case the scanner events may represent the event points associated with state transitions of steps in a monitoring-level logistics process.
The flowcharts and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various aspects of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The terminology used herein is for the purpose of describing particular aspects only and is not intended to be limiting of aspects of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to aspects of the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of aspects of the invention. The aspect was chosen and described in order to best explain the principles of aspects of the invention and the practical application, and to enable others of ordinary skill in the art to understand aspects of the invention for various aspects with various modifications as are suited to the particular use contemplated.
Although specific aspects have been illustrated and described herein, those of ordinary skill in the art appreciate that any arrangement which is calculated to achieve the same purpose may be substituted for the specific aspects shown and that aspects of the invention have other applications in other environments. This application is intended to cover any adaptations or variations of the present invention. The following claims are in no way intended to limit the scope of aspects of the invention to the specific aspects described herein.