U.S. patent application number 15/857817 was filed with the patent office on 2018-05-10 for method for evolving shared to-do lists into business processes.
The applicant listed for this patent is INTERNATIONAL BUSINESS MACHINES CORPORATION. Invention is credited to STEPHEN DILL, JAMES LIN, THOMAS P. MORAN, BARTON ALLEN SMITH.
Application Number | 20180129986 15/857817 |
Document ID | / |
Family ID | 40877168 |
Filed Date | 2018-05-10 |
United States Patent
Application |
20180129986 |
Kind Code |
A1 |
DILL; STEPHEN ; et
al. |
May 10, 2018 |
METHOD FOR EVOLVING SHARED TO-DO LISTS INTO BUSINESS PROCESSES
Abstract
A method and apparatus for evolving a shared to-do list into a
business process is disclosed. A business process includes one or
more business steps and zero or more action rules related to the
business steps. Members of a workgroup participate in the business
process and are able to view, modify, add and delete business steps
and action rules as needed. An action rule is comprised of one or
more business actions and one or more events that trigger the
actions to be executed. A computer program keeps track of the
business steps, interprets the set of rules, and updates states of
the business process, notifies the members and validates and
accepts modifications by the members to the action rules of a
business steps.
Inventors: |
DILL; STEPHEN; (SAN JOSE,
CA) ; LIN; JAMES; (CUPERTINO, CA) ; MORAN;
THOMAS P.; (PALO ALTO, CA) ; SMITH; BARTON ALLEN;
(CAMPBELL, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
INTERNATIONAL BUSINESS MACHINES CORPORATION |
Amonk |
NY |
US |
|
|
Family ID: |
40877168 |
Appl. No.: |
15/857817 |
Filed: |
December 29, 2017 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12016150 |
Jan 17, 2008 |
9922295 |
|
|
15857817 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06Q 10/0631 20130101;
G06Q 10/06 20130101; G06Q 10/0633 20130101 |
International
Class: |
G06Q 10/06 20120101
G06Q010/06 |
Claims
1. A method of evolving a shared list of business steps into a
business process comprising the steps of: establishing an action
rule, wherein the action rule comprises at least one event and at
least one business action; and if the at least one event occurs,
taking the at least one business action; wherein the business
process comprises at least one business step; and wherein the at
least one business step has an associated state; the associated
state having at least two state labels.
2. The method of claim 1 wherein the step of taking the at least
one business action includes changing at least one of the at least
two state label values of the at least one business step; the at
least one state label value comprising "done", and "not done
3. The method of claim 1 wherein the step of taking the at least
one business action includes notifying an entity.
4. The method of claim 1 wherein the step of taking the at least
one business action includes changing a date related to the
business process.
5. The method of claim 1 wherein the step of taking the at least
one business action includes executing at least one operation in a
computer software program.
6. The method of claim 1 further comprising allowing for addition
of at least one business step to the business process while the
business process is being executed.
7. The method of claim 1 further comprising the step of allowing
deletion or modification of the at least one business step while
the business process is being executed.
8. The method of claim 1 further including the step of adding a new
associated state label to the at least one business step.
9. A method of modifying rules of a business process comprising the
steps of: accepting a proposed modification; parsing the proposed
modification to determine its validity; and if the proposed
modification is not valid, notifying an entity; if the proposed
modification is valid, modifying a rule using the proposed
modification; wherein the business process comprises a plurality of
business steps and a plurality of rules.
10. The method of claim 9, wherein the step of modifying rules is
executed during execution of the business process.
11. The method of claim 9 wherein the proposed modification is
represented as a text string.
12. The method of 11 wherein the text string comprises a business
action and a state label.
13. The method of 11 wherein the text string comprises a person, a
business step, and a state.
14. The method of claim 9, further including the step of notifying,
in response to modifying the rule using the proposed modification,
an entity outside the business process.
15. The method of claim 10 further comprising the step of altering
a sequence of execution of the plurality of business steps in
response to the step of modifying the rule.
16. The method of claim 9 further comprising the step of storing
the proposed modification in a template.
17. A computer program product comprising a computer useable medium
including a computer readable program, wherein the computer
readable program when executed on a computer causes the computer to
evolve a shared list of tasks to a business process; said computer
program product including; computer usable program code for
establishing an action rule; computer usable program code for
executing an action; computer usable program code for allowing
modification of a business step during execution of the action;
computer usable program code for assigning the action to a user;
and computer usable program code for storing the business process
as a template.
18. The computer readable program of claim 17 further comprising
computer usable program code for storing a representation of the
business process in a database.
Description
BACKGROUND OF THE INVENTION
[0001] The present invention relates generally to the field of
business process automation and more specifically to methods and
apparatus of evolving shared to-do lists into business processes.
This application is a divisional application of application Ser.
No. 12/016,150 filed Jan. 17, 2008, and claims priority to that
application.
[0002] Collaborative work requires execution of tasks by members of
a workgroup and communication among the members. The collaborative
tasks may be in the form of a shared list of to-do tasks. Shared
lists of to-dos can be found in a variety of software programs,
including Lotus Notes.TM. and Domino.TM., Lotus Connections.TM.
(http://www.lotus.com/connections), Basecamp.TM. software program
by 37signals.RTM. (http://www.basecamphq.com/), and Microsoft
Outlook.TM. and Microsoft Exchange.TM., and Microsoft Windows
SharePoint Services.TM. by Microsoft.RTM.. Typical capabilities of
the prior art programs include assigning a to-do to somebody,
setting a due date, and checking it as done: but it usually does
not go beyond this. No email or other communication provision is
available at the completion of a task. Each to-do item typically
stands alone and cannot affect other to-dos, such as changing the
deadline of one item if the deadline of another changes.
[0003] A prior art method for managing and sharing a business
process among multiple users includes constructing a business
process as a diagrammatic connection of several tasks. The
connection thus establishes a workflow for the business process;
such workflow, i.e., organization of business steps, is created
before the business process is executed. The diagrammatic
representation and execution may be achieved in authoring tools
that represent the process in a commonly used programming language,
such as the Business Process Execution Language (BPEL) available at
(http://www.oasis-open.org/committees/wsbpel/). The workflow is
created ahead of time by people who analyze the work to be done and
design a workflow and is distributed "one way" from designers of
the workflow to the users of the workflow. The workflow
pre-determines the steps people will take, allowing little
variation. This scheme lacks the flexibility to allow users to
modify the workflow to adapt to specific work situations they
encounter.
[0004] Bug tracking systems such as Bugzilla.TM.
(http://www.bugzilla.org/) are more sophisticated. In addition to
being marked "done" or "not done", a bug or an issue in a bug
tracking system can usually be in one of several states, such as
"fixed", "invalid", or "won't fix", and there is a discussion
thread associated with each item. The system e-mails any change in
a bug's state to the people who submitted and were assigned to the
bug, and some systems allow anyone to add themselves to the
notification list. The bug tracking system can also e-mail a member
of a project about any change in any bug in the whole project.
However, there is little flexibility in customizing these
notifications. However, no notification facility is available if a
particular bug is marked "fixed" or when a bug is overdue.
[0005] Microsoft BizTalk (http://www.microsoft.com/biztalk/), a
business process management server, allows the behavior of
processes to be specified using either a general workflow language
or through English-like rules, which state that something should
happen when a certain event is detected. However, a programmer must
define the vocabulary of the rules ahead of time to fit their
particular application. Commercially available e-mail programs such
as Microsoft Outlook (http://office.microsoft.com/outlook/) allow
the user to specify rules for handling incoming mail, such as
moving all messages from a particular person to a certain folder.
The user interface for these rules tend to consist of a mixture of
drop-down lists and text boxes, which makes it easy to create a
rule but tedious to create many similar rules or copy and paste
rules. An example of prior art programs is Lotus Quickr.TM..
[0006] One practical problem with following business processes is
that users do not have opportunities to make real time changes. In
addition, the prior art techniques require user to learn a new set
of rules and do not allow flexibility to a user to create new rules
for execution of tasks. A better approach is needed.
SUMMARY OF THE INVENTION
[0007] In one embodiment of the present invention, a method of
evolving a shared list of tasks into a business process comprising
establishing an action rule, wherein the action rule comprises at
least one event and at least one business action; and if the at
least one event occurs, taking the at least one business action;
wherein the business process comprises at least one business step;
and wherein the at least one business step has an associated state;
the associated state having at least two state labels is
disclosed.
[0008] In another embodiment of the present invention, a method of
modifying rules of a business process is disclosed comprising the
steps of accepting a proposed modification, parsing the proposed
modification to determine its validity, and if the proposed
modification is not valid, notifying an entity, if the proposed
modification is valid, modifying a rule using the proposed
modification, wherein the business process comprises a plurality of
business steps and a plurality of business rule.
[0009] In still another embodiment of the present invention, a
computer program product comprises a computer useable medium
including a computer readable program, wherein the computer
readable program when executed on a computer causes the computer to
evolve a shared list to a business process is disclosed. The
computer program product includes computer usable program code for
establishing an action rule; computer usable program code for
executing an action; computer usable program code for allowing
modification of a business step during execution of an action;
computer usable program code for assigning an action to a user and
computer usable program code for storing the business process as a
template.
[0010] Yet another embodiment of the present invention is a system
for evolving a list of tasks to a business process is disclosed.
The system comprises a server computer and at least one client
computer communicatively connected to each other by a
communications network; wherein the server computer is configured
to execute a software program comprising a rules interpreters unit
for accepting, validating and interpreting action rules of a
business process, a communication unit for performing communication
with an external entity, the communication including information
related to execution of the business process, a user interface unit
for accepting a text string for the action rules of a business
process and a management interface unit for allowing management by
a user; and wherein the client computer is configured to execute a
software program for interpreting action rules of the business
process.
[0011] These and other features, aspects and advantages of the
present invention will become better understood with reference to
the following drawings, description and claims.
BRIEF DESCRIPTION OF THE DRAWINGS
[0012] FIG. 1 is an illustration of a list of business steps
organized in accordance with an embodiment of the present
invention;
[0013] FIG. 2 illustrates a business step in the list of business
steps and an action rule, in accordance with an embodiment of the
present invention;
[0014] FIG. 3 is a flowchart showing business steps of
implementation of an activity, in accordance with an embodiment of
the present invention;
[0015] FIG. 4 illustrates various stages of creating and executing
an activity and shows interactions with an external entity, in
accordance with an embodiment of the present invention;
[0016] FIG. 5 is a flowchart illustrating the process of creation
and modification of a list of activities in accordance with an
embodiment of the present invention;
[0017] FIG. 6 is a flowchart illustrating the process of creation
and modification of a rule in accordance with an embodiment of the
present invention;
[0018] FIG. 7 is an illustration of an exemplary set of state
labels that are referred to by action rules, in accordance with an
embodiment of the present invention;
[0019] FIG. 8 is a block diagram illustrating a computer apparatus
in accordance with an embodiment of the present invention;
[0020] FIG. 9 is a block diagram of a network in accordance with an
embodiment of the present invention can be implemented.
[0021] FIG. 10 shows a software stack showing exemplary functional
blocks of an embodiment of the present invention.
DETAILED DESCRIPTION OF THE INVENTION
[0022] The following detailed description is of the best currently
contemplated modes of carrying out the invention. The description
is not to be taken in a limiting sense, but is made merely for the
purpose of illustrating the general principles of the invention,
since the scope of the invention is best defined by the appended
claims. As user herein, the terms "task", "business task" and
"to-do" are used to convey the same meaning as the term "business
step".
[0023] The present invention can be embodied in a product such as
Lotus Connections.TM. that allows web-based collaboration among
multiple users. Another exemplary embodiment is the Quickstep.TM.
collaborative software published by International Business Machines
(IBM.RTM.) Corporation.
[0024] In one aspect, the present invention provides a method and
apparatus for creation of a list of shared To-Dos (or tasks or
business steps) to a workgroup. Using the method of the present
invention, participants in the workgroup can evolve--that is,
incrementally change--that list into a more structured business
process that helps coordinate the work of the people carrying out
the activity. Furthermore, using the present invention, such
evolving can be achieved at the same time as the business process
is being executed.
[0025] FIG. 1 shows an exemplary composition 100 of business steps
101, shown as business step 1, business step 2 . . . business step
N that make up an exemplary business process. For example, "hiring
a new employee" may be a business process 100 that requires several
business steps 101 to accomplish it. Such a business process is
represented as a template of business steps 101. An instance of a
business process 100 applied to a particular business objective at
hand is referred to as an activity, shown as block 150. For
example, "hiring John Doe" may be an instance of this business
process 100. The business steps 102 in activity 150 are initially
copies of the business steps 101 in template 100. Activity 150 may
be created by any person who has access to the template 100. The
creator then becomes an actor 112 in activity 150, for example,
assuming a role (such as manager) that may be specified in the
template 100. Activity 150 may include activity-specific changes to
business steps 102 beyond the template. For example, activity 150
shows addition of business step N+1, which is not in the specified
business process 100. Similarly, activity 150 may include skipping
over some steps, such as shown by conditional jump 104, during the
course of its execution.
[0026] The execution of the activity 150 may proceed sequentially
through the tasks 102 in order or may have conditional jumps, such
as conditional jump 104, between tasks 102 in a different order,
depending on the circumstances of the activity. Such conditional
jumps may be based on results of actions performed during execution
of a task 102. For example, as shown in FIG. 1, either Task 2 or
Task N may be the next task performed after completion of Task 1.
In general, an activity 150 may have multiple orders of execution
among various tasks 102 that make up the task list for the activity
100. Each task 102 in the activity 150 can have various attributes
associated with it. A task has a title 118. A task can have a
textual description 120 and a sequence of comments 122 by the
actors 112. Each task has a state 116, which has a value from a set
of state labels, such as "started" or "done". Each task 102 can
also include resources 106, critical dates 108, roles 110, people
112, and action rules 114 (rules). Resources 106 may be a
conference room needed for the completion of the task or some other
material resource (e.g., a tool or a document) required for
completion of the task. Critical dates 108 may include a start
date, an end date and any other critical intermediate date to reach
a milestone; it may also include estimated duration of the task.
Roles are entities to be filled by people (e.g., a manager role can
be assigned to certain business steps; it may be unfilled or it may
be filled by a particular actor Joe). Actors 112 may include the
originator of the task and any other people participating in the
activity, such as people allowed to read, write, modify or delete
any of the tasks; people who should be notified upon completion or
failure of a task. An actor is usually a person, but it can also be
a computational agent (e.g., a program to add tasks to the
activity). A task may also have data 124 associated with it (e.g.,
a task titled "assigned room" would have a "room number" datum to
represent the room assignment). Action rules 114 may consist of
event-action pairs and may be created by one or more actors
112.
[0027] FIG. 2 shows exemplary business step 102 (a task) of an
activity along with its state (block 116). In one exemplary
embodiment, the state 116 of activity business step 102 can have a
single value from a set of at least two state labels, such as
"done", "ready", "upcoming", "started". Actors 112 can change state
labels. Actors can also create new state-labels. Actors 112 can
manually create and edit such an activity 150, e.g., add business
steps 102, assign other actors 112 or roles to business steps 102,
add deadlines 108, delete business steps 102, etc.
[0028] FIG. 2 further shows an exemplary action rule 114 and two
action rule syntax examples 200 that can include one or more
actions 204 and one or more events 206. In general, an action rule
114 may consist of a single event 206 and a single action 204. An
event may be any change to any of the business steps of an
activity. For example, when an actor changes the state of a
business step to "done", this is represented by an event "business
step becomes done". Action rules 114 may trigger on events 206 in
the business process 100. Other examples of events are "business
step 4 becomes ready", "actor Joe is assigned to business step 2,"
"it is now one day before the deadline of business step 3" etc.
When events 206 occur, the action rules 114 may specify that
actions 204 are to be executed by the system. Actions 204 can be
arbitrary procedures executed by the system, e.g., to change the
state 116 of a business step 102, to notify a person 112 by email,
to change a date 108, to change the order of the business steps, to
add a new business step, or execute an operation on some business
application, etc. Examples of actions rules 114 including notifying
a specific person 112 when a business step 102 changes to a
specific state 116 ("notify Tim when business step 4 is done"),
changing the state 116 of a specific business step 102 ("change
business step 4 to ready when business step 3 is done"), triggering
business application workflows ("start the approval process in the
travel-request system when business steps 3, 4, and 5 are done"),
etc. Action rules 114 can also be more general, applying to many
different business steps 102, such as "set next business step to
ready when this business step is done", "notify Tim when any
business step is started", etc. Thus action rules 114 can be the
primary device by which participants of a workgroup can evolve a
set of business steps 102 into a partially automated business
process 100. Actions 204 that the rules 114 can execute may include
but are not limited to: notifying someone through a mechanism such
as e-mail or instant messaging, running an external program,
posting a message to an external system, and changing the state 116
of a business step 102 or a set of business steps 102. One example
action rule 114 is shown as block 208 and has syntax "set STEP to
STATE when STEP is/are STATE". Another example action rule syntax
is shown in 210 as "Notify PERSON when STEP is/are STATE".
[0029] FIG. 3 shows a flowchart 300 illustrating an exemplary
business process in which an intern is hired for employment by a
company. The flowchart shows that the business process can be
accomplished by coordination of business steps among various
participants (actors) in the workgroup for the business process as
follows. The participants in the workgroup of this example are: a
manager, human resources (HR), information technology department
(IT), an intern, an admin, and a mentor. In phase 302, the manager
of the business process can create the activity of the business
process, which in this case is hiring the intern. In the next phase
304, a software system may handle coordination of the activity
using a method consistent with the specification. In the next phase
306, participants in the activity may complete their assigned tasks
and update the list by marking their completion. List 310 shows an
example of the business steps 102 comprising the activity 100 of
hiring an intern. A total of nine (9) exemplary business steps 102
are shown. Each business step 102 can have a state 116 with some
label (e.g., done, ready or upcoming), a title (e.g., "assign
office") and an actor or role assignee 112 associated with it
("manager", "intern", John, etc.). An actor 112 may be able to
modify the list of tasks 100 during the execution of the activity.
For example, in business step 4 of list 310 (assign office business
step), the actor (admin) may realize that the intern being hired
requires handicap access. The actor 112 can then add to the list a
new business step 6 (disability access). The actor 112 can also
specify the participants who are to act on the newly added business
step. The actor 112 can also specify who should be notified upon
completion of the newly added business step.
[0030] FIG. 4 shows an example 400 of interactions between an
activity 150 and external entities. In FIG. 4, there is a business
process 100 in the form of a template 404 providing steps 101 for
"how to propose a demo for a meeting". A researcher 450 can make
(shown as arrow 440) an activity instance 402 of this template 404.
Activity 402 guides the researcher 450 in creating a proposed demo.
When the researcher has completed the steps in activity 402, an
action rule in 402 will trigger an action that transmits the
proposal (shown as arrow 432) to a meeting management application
406.
[0031] The meeting management application 406 may for example be a
business process system which is an external entity to the demo
activity 402. If the meeting management system 406 decides that the
proposal is accepted, it will transmit (shown as arrow 430)
information about acceptance to activity 402. Then an action rules
102114 in activity 402 will trigger an action 204 to notify the
researcher 450 and another action 204 to copy (shown as arrow 442)
new business steps from template 408 into activity 402 for the
researcher 450 to follow. The modified rules may also be stored in
the modified template 408 and may be used for future instantiations
of a demo activity. The signal exchanges and interactions in FIG. 4
thus show how an activity 150 can communicate with an external
entity, the external entity may itself be an activity or an actor,
and how business process templates can be modified using
interactions among activities and actors.
[0032] FIG. 5 shows a flowchart 500 of exemplary steps of activity
lifecycle implemented in a computer program. In step 502, an actor
112 may start a new activity 100 and becomes its owner. In step
504, the actor owner 112 can propose to modify the activity 150. In
step 504, the computer program will be accepting the proposed
modification for further validation and processing. The
modification, for example, may be done to meet the business
requirements of the activity 100. Example modifications include,
but are not limited to, adding new actors 112, adding new rules
110, adding new steps 102 in the activity 150, changing existing
rules 110, and changing existing steps 200. When the modification
is received by the computer program managing the activity 150, the
computer program may check in step 506 if the proposed modification
is consistent with other steps 102 of the activity 150. If the
proposed modification is not consistent, then the computer program
may reject the modification and notify the actor, in step 510, that
the modification is inconsistent. If the modification is
consistent, then the computer program may makes changes, in step
508, to the activity as instructed by the proposed modification.
Making any change to an activity 150 may change that activity's
status. Activity status is the collective representation of all of
the attributes of all business steps 102 in the activity 150. The
computer program can then proceeds to the next step 512 to create
an event that describes the change. Next, in step 514, the computer
program may check for a rule 114 match for the modified event. If a
rule match is not found in step 516, the computer program may then
go to the step 504 in which it can accept a next proposed
modification from the actor 112. If a rule match is found in step
516, the computer program may then execute the matching rule in
step 518. After completion of step 518, the computer program can
then go back to step 508 in which it can then accept more changes
the state of the activity 100.
[0033] FIG. 6 shows a flowchart of exemplary steps implemented by
the computer program if the actor changes an action rule 114 in
step 504 in FIG. 5. In the first step 602, the actor may input text
for a new or changed action rule 114. In the next step 604, the
computer program may then parse the input text. The computer
program can then make a determination in step 606 regarding
validity of the entered text as a rule 114. If the entered text is
not a valid action rule 114, the computer program may notify the
actor 112, in step 608, that the entered text is not a valid rule.
The actor 112 can then execute step 602 again and add or change
action rules 114. If in step 606, the computer program determines
that the entered text is a valid rule, the rule parser module of
the computer program may then create an action rule 114 for
execution, in step 610, from the entered text. In the next step
612, the computer program can then add the action rule 114 created
in step 610 to the activity 100 or replace an existing rule 114
with the new rule 114.
[0034] The present invention lets users 112 create rules to specify
coordination of behavior. The present invention lets a user specify
rules using text string that is readable and understandable to a
human. As previously shown in FIG. 2, an action rule 114 may
comprise an action 204 and an event 206. Exemplary rule formats
possible include a rule such as "Set BUSINESS STEP A to STATE Y
when BUSINESS STEP B is STATE Z1" or "Notify PERSON X when BUSINESS
STEP C is in STATE Z2" or "notify PERSON Z when BUSINESS STEP D is
commented on" or "Set BUSINESS STEP E to STATE XX when DATUM DD is
filled". The former rule may provide instruction to a computer
program to set the state 116 of a business step 102 to a value "Y"
when a state 116 of another business step 102 equals another value
"Z1". The latter rule may provide instruction to the computer
program to notify an actor X when a business step 102 reaches a
state label Z2. The plain text nature of the rules makes it easier
for a user to input such rules in a text string format, without
having to memorize complex instruction sets. Other prior art exists
that also allow end-users to specify rules.
[0035] FIG. 7 shows an exemplary set of state labels 700. These
labels are possible values of a business step's state 116. The rule
parse module may use in making a decision in step 610 regarding
validity of the entered text as a rule 114, would check that the
input text uses one of the allowed state labels. The set of state
labels may be classified into three possible time epochs--future
time 702, present time 704, or past time 706. The state labels in
the future epoch 702 may include "upcoming" to signify that a
business step 102 is not expected to be executed until some time in
the future. The present epoch 704 may comprise a "ready" label,
indicating that a business step 102 is ready for execution; a
"started" label, indicating that a business step 102 is currently
being executed; and a "stuck" label, indicating that an actor 112
had some problems with successful completion of a business step
102. The past epoch 706 may include the following state labels 116:
a "done" label indicating that the business step 102 has been
completed; a "skipped" label indicating that a business step 102
was skipped due to some reason; and an "approved" label indicating
that an actor has approved the execution of a business step 102. A
business step 102 also may have associated dates 108, such as a
start date and a due date that shows the chronological constraints
on the business step within the activity 150.
[0036] FIG. 8 shows a computer platform 820 on which the computer
program embodiment of the present invention can be implemented. The
computer platform 820 may comprise a processor 802, a memory unit
804 that includes memory for data and instructions, a hard drive
806, and an interface 808 for input/output communication with other
computers or equipment.
[0037] FIG. 9 shows an exemplary system 900 where the present
invention can be implemented. The system 900 may comprise one or
more computers, one of which may be configured to act as a server
820, and one or more of which may be configured to act as a client
822. The computers 820 and 822 are in turn communicatively coupled
to each other using a communication network 902 such as the
Internet.
[0038] FIG. 10 shows exemplary software protocol stack of a server
software program run on a computer 820 in accordance with an
embodiment of the present invention. The software stack may
additionally comprise other functional blocks generally available
with industry standard operating systems such as Linux.TM.,
MacOS.TM. and Windows.TM.. For simplicity of description, only some
functional blocks relevant to an embodiment of the present
invention are shown. A user interface unit 1004 can be used to
accept input from a user regarding addition, deletion and
modification of business steps 102 of an activity 100 that is run
on the computer 820. A communication unit 1006 may be used for
communication with external entities, such as other users and
computers. The communication can include sending emails to other
users 112, sending instant messages, notifying users, checking for
updates to the execution of a module in the software stack 1000 and
so on. A rules interpreter unit 1008 may accept the proposed rules
114 from a user and check for validity of the rules. The rules
interpreter unit 1008 may also perform the task of creating or
executing computer code by interpreting the action rules 114
provided by a user. For example, the rules interpreter unit 1008
may be implemented as a web browser plug-in software module written
in a programming language such as JavaScript.TM.. The software
stack 1000 may also contain a management interface 1010 that allows
management and control tasks such as allowing a manager user to
manage execution of an activity 100 and allowing a programmer to
update the rules interpreter unit 1008. The software stack of a
client software program may share many of the same functional
blocks described for the server software program. In particular, it
may be advantageous to configure client software program with a web
browser plug-in that interprets the rules 114 of a business process
100. Such a configuration allows embodiment of the present
invention ubiquitously on any commercially available
software/hardware platform enabled with a web browser.
[0039] The present invention envisions that a variety of events for
triggering action rules 114 are possible. The events include, but
are not limited to, whether the state 116 of a business step 102 or
set of business steps 102 is changed; or whether a user 112 adds a
comment to a business step 102; or whether a set of business steps
102 are within a certain period of time of the start or due date
108 of a business step 102; or if a person 112 is added to or
removed from the process; or if a person 112 is assigned or
unassigned to a role 110; or if a message is received from an
external business process or within a certain period of time of a
particular change in the process.
[0040] An embodiment of the present invention is a prototype called
Quickstep.TM. Quickstep.TM. represents a business activity 150 as a
list of business steps 102 for people 112 to do. This list 100 can
represent an ordered set of business steps 102, an unordered
collection of to-dos, or a mixture thereof. Each business step's
state 116 can one of several state labels 700, such as "upcoming",
"ready", or "done," along with start and due dates. Along with the
business steps 150, a business process 100 may also have a list of
actors 112 involved in the business process 150, a list of the
roles 110 these actors 112 play in the process, and a list of
resources 106 (such as web links, documents, scripts, connections
to external applications, or messages).
[0041] Quickstep.TM. also allows actors 112 to automate certain
behaviors of the activity 150 by adding action rules 114. For
example, a manager 112 may want to be notified by e-mail whenever a
business step 102 assigned to one of his employees is completed,
without needing to check the list 150 itself. Another possibility
is setting the state 116 of a business step 102 to "ready" whenever
another business step 102 becomes "done." To specify such
behaviors, the business process 150 can include a set of rules 114
that act upon the business process 100. Each rule 114 may consist
of two parts as shown in FIG. 2: an action 204 and an event 206
that must occur for the action to be executed. Here are some
examples of Quickstep.TM. rules: "Notify me when the state of step
3 becomes ready" or "Notify Bob when the Approve Proposal step
becomes done" or "Change the state of step 6 to ready when the
state of step 5 is done" or "Notify Mary 3 days before step 10 is
due."
[0042] A rule 114 can react to any change in the business activity
150, and as a result create a notification or further change the
process 100 and the notification may then be communicated to an
external entity such as a human user or a software agent.
[0043] Quickstep.TM. implementation to support rules 114 may
consist of two parts: parsing the rules 114 and executing them. The
rule parser may take the English sentence that the user types in
and parse it into an internal representation that is stored, so
that the rule's condition can be checked and its action 204 can be
executed without needing to reparse it every time.
[0044] For execution of a rule 114, Quickstep.TM. can use an
event-based architecture. Rules 114 may set up event listeners to
listen for events from the Quickstep.TM. system, such as the state
116 of a business step 200 has changed or the due date for a
business step is 3 days away. When the system fires an event, each
rule 114 may receive the event and check to see if its condition
matches the event. If so, the rule 114 can perform its action,
which may result in the system firing more events.
[0045] To further customize the behavior of the process, users 112
can augment the possible state labels 700 with their own and then
define rules that are executed depending on those labels 700. For
example, a user 112 can define an "approval-needed" label, and then
a rule that says, "Notify Bob when any step becomes
approval-needed."
[0046] To enter a rule 114, a simple text box can be used. Such a
user interface is fast for users 112 to enter rules 114--they do
not need to fiddle with drop-down boxes and other widgets that can
slow them down. It also makes it easy for users 112 to cut and copy
rules 114, and paste them into other processes. However, without
further guidance, it is harder for the user 112 to remember the
syntax of the rules. Techniques such as a step-by-step wizard,
auto-complete as found in integrated development environments
(IDEs), and dragging and dropping from a palette of rule parts, can
be used to ease the burden of remembering the rules' syntax. More
sophisticated parsing techniques, such as sloppy parsing in
Koala/CoScripter, can also be used so that Quickstep.TM. would be
able to tolerate more variation in what a user 112 types in.
[0047] Quickstep.TM. is set up so that changes to any part of the
process 100, including the rules 114, can immediately go into
effect. This allows the process 100 to evolve incrementally,
without needing to stop and restart a process server 820. Since the
threshold to changing a process 100 is lower, it is more likely to
change and evolve as the underlying work practices also evolve.
[0048] At the same time, any behavior in a Quickstep.TM. process
100 can be overridden by the user 112. For example, the typical
lifecycle of a business step 200 may start in the "upcoming" state,
and then go through the "ready", "started", and "done" states.
While a prior art workflow application typically enforces such
transitions, in Quickstep.TM. a user can go straight from
"upcoming" to "done."
[0049] The present invention can be implemented using client/server
architecture as shown in FIG. 8 wherein client devices 822 are used
to interact with the process database on a server device 820.
[0050] Alternatively, a web-based embodiment is also possible. A
user can use an off-the-shelf web browser and see or modify content
on a central database through a web-based connection to a server
820.
[0051] The invention can take the form of an entirely hardware
embodiment, an entirely software embodiment or an embodiment
containing both hardware and software elements. In an exemplary
embodiment, the invention is implemented in software, which
includes but is not limited to firmware, resident software,
microcode, etc.
[0052] Furthermore, the invention can take the form of a computer
program product accessible from a computer-usable or
computer-readable medium providing program code for use by or in
connection with a computer or any instruction execution system. For
the purposes of this description, a computer-usable or computer
readable medium can be any apparatus that can contain, store,
communicate, propagate, or transport the program for use by or in
connection with the instruction execution system, apparatus, or
device.
[0053] The medium can be an electronic, magnetic, optical,
electromagnetic, infrared, or semiconductor system (or apparatus or
device) or a propagation medium. Examples of a computer-readable
medium include a semiconductor or solid state memory, magnetic
tape, a removable computer diskette, a random access memory (RAM),
a read-only memory (ROM), a rigid magnetic disk and an optical
disk. Current examples of optical disks include compact disk--read
only memory (CD-ROM), compact disk--read/write (CD-R/W) and
DVD.
[0054] A data processing system suitable for storing and/or
executing program code will include at least one processor coupled
directly or indirectly to memory elements through a system bus. The
memory elements can include local memory employed during actual
execution of the program code, bulk storage, and cache memories
which provide temporary storage of at least some program code in
order to reduce the number of times code must be retrieved from
bulk storage during execution.
[0055] Input/output or I/O devices (including but not limited to
keyboards, displays, pointing devices, etc.) can be coupled to the
system either directly or through intervening I/O controllers.
Network adapters may also be coupled to the system to enable the
data processing system to become coupled to other data processing
systems or remote printers or storage devices through intervening
private or public networks. Modems, cable modem and Ethernet cards
are just a few of the currently available types of network
adapters.
[0056] It should be understood, of course, that the foregoing
relates to exemplary embodiments of the invention and that
modifications may be made without departing from the spirit and
scope of the invention as set forth in the following claims.
* * * * *
References