System and method for scheduling token arrival in a business process simulation

A business process simulation system for scheduling token arrival in a business process simulation is provided. The system includes a frequency module for receiving user input defining a frequency of token arrival; a duration module for receiving user input defining at least one repeatable valid duration of availability to receive tokens; an exemption module for receiving user input defining an exemption duration within the availability duration; and a timer module for receiving user input defining a recurring timer calendar for the business process simulation. The system also includes a token scheduling controller, wherein the token scheduling controller is adapted to process instructions corresponding to the user inputs and sending token scheduling instructions corresponding to the user-defined parameters to the business process simulation.

TRADEMARKS

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to business process modeling and simulation, and particularly to scheduling token arrival in the business process modeling and simulation.

2. Description of the Related Art

In Business Process Modeling, simulation plays a vital role in evaluating and comparing the different alternatives prior to deploying those processes in a runtime environment. For a business to base its decisions on business process simulation, it is crucial that the business process simulation engine provide realistic information and benchmarks.

Process simulations may be used to observe a process in action, to examine the statistics that it generates as it runs, and to perform analysis on the simulation results. Changes to a process or to other model elements (such as available resources) may also be simulated and quantified with a comparative analysis of the before and after simulation result.

Simulation enables organizations to observe how a process will perform in response to variations of inputs to the process, just as in a real-life work environment. Simulation also provides the ability to vary process input volume over time by adjusting resources and current allocations. Simulation output provides detailed information regarding resource utilization levels and the results of cost and cycle-time calculations.

Within a simulation, a token represents a unit of work that is received by a process and transferred between different activities in the process flow. By specifying token creation settings, the quantity and rate of inputs that the process handles in a simulation run are defined.

For a process simulation to run, the process must receive one or more inputs. In a simulation profile, inputs to the process and to activities within the process are represented by tokens. Some tokens represent the transfer of data between activities, while other tokens represent only a transfer of control.

Token creation settings for any input that is associated with data, whether it is an input to a process or an input to an activity, within a process may be defined. The rate at which tokens are created for an input are determined by setting a time trigger. The time trigger can be a regular interval, or it may be a variable interval defined by a distribution.

The number of tokens to generate at one time (number of tokens per bundle), and a one time cost per token may also be defined. In addition, each of these attributes can be set to a constant value or to a variable value defined as a distribution may also be defined.

For example, to create tokens that represent the arrival of customers at a restaurant, one could use a normal distribution to specify an arrival interval, where five minutes is the mean and three minutes is the standard deviation. A weighted distribution list could be used for the number of tokens per bundle, to represent how many customers are in each party. In this example, the weighted distribution list enables setting of probabilities for each size of party, based on past experience.

By default, the token creation settings for a process in a simulation profile are set to the values specified in the local simulation preferences, except for the total number of tokens to generate. This value is instead derived from the minimum number of inputs as specified in the process model. This is done to prevent a situation in which the process cannot start because it does not receive the minimum number of inputs (which could be the case if the token creation settings in the local simulation preferences are a lesser value than the minimum number). You can also customize the token creation settings by changing them from their default values in the simulation profile.

Business process simulation engines in the marketplace base their token arrivals on a simple timetable where the user specifies the start time, end time, and number of tokens. In this way, the burden is put on the end-user to explicitly specify a table of constant point-in-times and associate each point-in-time with a constant number of tokens. Effectively, the end-user would have to fill a table like the one shown in Table 1.

However, it will be appreciated that many realistic business simulations require that token arrivals are based on a recurring time calendar with each recurring time interval—potentially—having a distinct distribution. Therefore a need exists for a token scheduler operating with a recurring time calendar.

SUMMARY OF THE INVENTION

The shortcomings of the prior art are overcome and additional advantages are provided through the provision of a system and method to schedule token arrival in a business process engine based on a recurring time calendar. Token and token bundles arriving within these recurring time intervals can either be specified as a constant or defined by a distribution. Additionally, the rate of token arrival can either be implicitly specified by a more granular recurring calendar (for example a calendar that defines a time interval recurring every minute) or can be specified by a constant time or defined by a distribution.

In accordance with one embodiment of the present invention a business process simulation system for scheduling token arrival in a business process simulation is provided. The system includes a frequency module for receiving user input defining a frequency of token arrival; a duration module for receiving user input defining at least one repeatable valid duration of availability to receive tokens; an exemption module for receiving user input defining an exemption duration within the availability duration; and a timer module for receiving user input defining a recurring timer calendar for the business process simulation. The system also includes token scheduling controller, wherein the token scheduling controller is adapted to process instructions corresponding to the user inputs from the frequency module, the duration module, the exemption module and the timer module.

The invention is also directed towards a method for scheduling token arrival in a business process simulation. The method includes entering a user-defined parameter for a frequency of token arrival; entering a user-defined parameter for at least one repeatable user-defined duration of the business process simulation availability; entering a user-defined parameter for a recurring timer calendar; and entering a user-defined parameter for an exemption duration within the availability duration. The method also includes sending token scheduling instructions corresponding to the user-defined parameters to the business process simulation.

TECHNICAL EFFECTS

As a result of the summarized invention, technically we have achieved a solution which improves business process simulation modeling with enhanced token scheduling capability.

A program storage device readable by a machine, tangibly embodying a program of instructions executable by the machine to perform a method for scheduling token arrival in a business process simulation is provided. The method includes entering a user-defined parameter for a frequency of token arrival and entering a user-defined parameter for a repeatable user-defined duration of the business process simulation availability. The method also includes entering a user-defined parameter for a recurring timer calendar and entering a user-defined parameter for exemption duration within the availability duration specified by the recurring timer calendar. The method continues with entering a user-defined parameter for a maximum allowable number of tokens to be scheduled for arrival. The method also allows for entering a user-defined parameter for an offset time for token arrival from the beginning of the availability duration and selecting a user-defined parameter for a user-defined distribution of the frequency of token arrival. Selecting the user-defined parameter for the user-defined distribution of the frequency of token arrival further includes selecting user-defined distribution from the group consisting of a normal model, a Poisson model, a Gaussian model, a growth model, a sigmoidal model, and an exponential model. In addition, the method also accounts for sending token scheduling instructions corresponding to the user inputs to the business process simulation.

DETAILED DESCRIPTION OF THE INVENTION

With reference now toFIG. 1, a block diagram illustrating a business process simulation system300is depicted in which the present invention may be implemented. Business process simulation system300employs a peripheral component interconnect (PCI) local bus architecture. Although the depicted example employs a PCI bus, other bus architectures such as Accelerated Graphics Port (AGP) and Industry Standard Architecture (ISA) may be used. Processor302and main memory304are connected to PCI local bus306through PCI bridge308. PCI bridge308also may include an integrated memory controller and cache memory for processor302. Additional connections to PCI local bus306may be made through direct component interconnection or through add-in boards.

In the depicted example, local area network (LAN) adapter310, SCSI host bus adapter312, and expansion bus interface314are connected to PCI local bus306by direct component connection. In contrast, audio adapter316, graphics adapter318, and audio/video adapter319are connected to PCI local bus306by add-in boards inserted into expansion slots. Expansion bus interface314provides a connection for a keyboard and mouse adapter320, modem322, and additional memory324. Small computer system interface (SCSI) host bus adapter312provides a connection for hard disk drive326, tape drive328, and CD-ROM drive330. Typical PCI local bus implementations will support PCI expansion slots or add-in connectors.

Token scheduler20receives user input via keyboard and/or mouse adapter320. Inputs to token scheduler20define offset durations, period durations, distributions, token frequency, exemption durations, maximum number of tokens allowed, and a recurring calendar input. The token scheduler inputs are described in detail herein. It will be appreciated that token scheduler20may receive inputs via any suitable method. For example, inputs may be predetermined and stored in memory324, or stored on disk326, for later retrieval.

Process simulator201receives token scheduling information from token scheduler20. It will be appreciated that process simulator201may be any suitable process simulator such as IBM's WEBSPHERE™ process simulator.

Those of ordinary skill in the art will appreciate that the hardware inFIG. 1may vary depending on the implementation. Other internal hardware or peripheral devices, such as flash read-only memory (ROM), equivalent nonvolatile memory, or optical disk drives and the like, may be used in addition to or in place of the hardware depicted inFIG. 1.

The depicted example inFIG. 1and above-described examples are not meant to imply architectural limitations. For example, business process simulation system300also may be a notebook computer or hand held computer in addition to taking the form of a PDA.

Turning now toFIG. 2there is shown an exemplary diagram of the token scheduler features in business process simulation in accordance with an embodiment of the present invention as shown inFIG. 1. Frequency module27receives user input defining a frequency of token arrival and provides a token frequency component to token scheduler controller21. Duration module25receives user input defining repeatable duration and provides a duration component for system availability to receive tokens to token scheduler controller21. Exemption module28receives user input defining exemption duration within the system availability and provides an exemption component to token scheduler controller21. Offset module26receives user input defining an offset period and provides an offset component to token scheduler controller21. Timer module23receives user input defining a recurring timer calendar and provides a timer component to token scheduler controller21. Maximizer module22receives user input defining a maximum allowable number of token arrivals in the availability duration and provides a maximizer component to token scheduler21. Distribution module24receives user input defining token arrivals based on a user-defined time distribution or portion of a user-defined time distribution and provides a distribution component to token scheduler controller21. Token scheduler module21contains logic and resources necessary for processing instructions from the components corresponding to the user inputs and providing to simulator201a calendar based token arrival schedule in accordance with embodiments of the present invention. As noted earlier, simulator201may be any suitable business process simulator such as IBM's WEBSPHERE™ business simulator.

Turning now toFIG. 3, and also still referring toFIG. 1, there is shown a flowchart illustrating one method of the token scheduler feature shown inFIG. 2. A token frequency is entered31by user via keyboard or mouse320. The entered token frequency is compared32to a predetermined threshold. If the predetermined threshold is exceeded the user is alerted and control is passed back to user. If the predetermined threshold is not exceeded the user enters33a token exemption period. The token exemption period is also compared34to a predetermined threshold. If the predetermined exemption threshold is not exceeded the user enters35a duration period. The duration period is compared36to a predetermined duration period. If the predetermined duration period is not exceeded the user enters37a distribution function describing token arrival over the allowed arrival duration. It will be appreciated that the distribution function may be any suitable distribution function such as, for example, a normal distribution, a Laplacian distribution, or a Poisson distribution. It will also be appreciated that the distribution function may be entered37by a user or pre-stored in any suitable media such as memory324or CD ROM330. If the distribution function is determined38as valid the user enters39a recurring calendar period. The recurring calendar period may be any suitable recurring calendar period as described herein. If the recurring calendar period is determined40to be valid the user enters41the maximum number of tokens allowed to be received during a duration period. If the maximum number of tokens allowed to be received does not exceed a predetermined threshold42the token(s) arrival is scheduled43by simulator (FIG. 1,201).

FIG. 4is a pictorial diagram of an example of the token interval features shown inFIG. 3. In this example a calendar recurring duration recurs every two hours45, lasts for an hour47, the first fifteen minutes of which is exempt49.

Turning now toFIG. 5, there is shown a graphical representation of the exemption interval features shown inFIG. 4. A recurring time calendar and is defined as a time calendar53that would contain one or more valid intervals (which could potentially be a point-in-time—i.e. have a zero duration) and optionally a recurring exemption time calendar. For example, if a business process necessitates that tokens be scheduled to arrive every other hour as shown by vertical lines54, but discount the first fifteen minutes of the recurring intervals as shown by hatched areas51. Effectively, a business process engine taking this timeline53as input when scheduling token arrivals would only allow tokens to arrive within the solidly-shaded (valid interval) areas52shown inFIG. 5.

It will be appreciated that in an embodiment of the present invention the feature of calendar-based token arrival solution allows the end-user to only have to define a recurring calendar and associate the number of token bundles to schedule for arrival—which could either be constant or a specification of a mathematical distribution (e.g. a uniform distribution with a specified minimum and maximum or a normal distribution with a specified mean and standard deviation, etc. . . . ).

For example, a user modeling token arrival on a call center would first define a time calendar with recurring time intervals that define token arrival everyday between 8:00 AM and 5:00 PM with an exemption interval from 12:00 PM to 1:00 PM in between—say for lunch. The end-user can then specify token arrivals in one of three ways, provided in Examples 1, 2 and 3:

Based on an offset time from the beginning of the recurring interval. Referring to Table 2, it is seen that the time is not absolute, (i.e., it's an offset from the start of the interval), and the user has a choice to either specify the number of tokens as a constant or as a mathematical distribution that best fit the business model under examination.

Based on number of tokens and rate of arrival. Referring to Table 3, in the first interval, the spread of token arrival is evenly distributed within the specified interval. If the user selects a total of four (4) tokens to arrive, the rate of arrival would be one per hour starting at 8:00 AM.

Alternatively, the user may choose to specify a non-even distribution in which case the user will specify the spread using the above table 3 for that particular time interval.

Based on a point-in-time recurring time calendar—it will be appreciated that this a benefit from the use of recurring timer calendars. Using this alternative, the user would model a recurring time calendar with zero duration for each time interval. These recurring point-in-times are then associated with a constant value specifying the total number of tokens to schedule for arrival or optionally an appropriate mathematical distribution.

For example, referring toFIG. 6, defining a recurring time interval62that recurs every second as shown by the vertical lines63inFIG. 6would effectively define the rate of arrival and the timeline61would appear as shown. Using this alternative the end-user advantageously need not specify a rate of arrival as the rate is implicitly defined by this recurring point-in-time calendar. Thus, the user would specify the token creation as shown in Table 4.

TABLE 4Number of TokensTime IntervalConstantDistributionSpread8:00AM~4NormalBased on Calendar1:00PM~7Poisson (8)Based on Calendar