Business Processes

There are several reasons for extending project management with business processes; in fact the two are presented as alternatives for meeting team organizational needs. With Twproject  you get the advantages of both, in an integrated solution.

We use business process as synonymous with workflow.

Some company’ projects could be repeated in time and very well “standardized” that could be elected to “business process”.

A common approach  with Twproject is to have “templates” that can be reused several times; this approach left the user the ability to change something on the tree structure.
Another case  you may want to manage with your projects or process are “iteration” phases: e.g. development -> customer reject -> development -> customer reject   -> development -> customer approval -> party!

Project management, where processes are modeled with trees, dependencies and assignments, has several limits:
1. formal limits
2. rigidity
3. hard to maintain in time for the project manager
4. may result complex for the end user

For formal limits, just think to the recurring phases example above;  something hard to do with a tree. For 2 and 3, projects intrinsically lack the notion of “local evolution” (or expansion), which is natural in business processes. For 4, consider for example a step (a task) in a project which is assigned to a user only to get a signature from her; she may end up having tens of assignments only for a signature, and tens of task statuses to update and justify. Wouldn’t it be more natural that she got from the interface just some buttons to be pressed confirming that she signed, and that is all required from her to let the process proceed?

With business processes, we not only overcome such limits, but get more:
1. more flexibility and standardization of processes
2. easier to support change

screen1220
Even this simple example is hard to manage with a simple project tree; every iteration you have to change statuses of a couple of task manually, and this could lead to an inconsistent process state.

This is why Twproject implements a powerful workflow engine.

The integrated business process management tool greatly widens the modeling possibilities w.r.t. project trees, and improves usability even for complex use-cases, while maintaining the basic project based organization.

In our meetings with customers we often presented two way of modeling their business processes: with projects, aimed at giving a minimal structure to work and collecting a maximal amount of feedback, work logs etc., or using business process models, which are workflows. Workflows are more rigid but more accurate. They are more complex to plan but often easier for the final user, who has just to say “proceed” on her/his tasks when it is the case.

Process steps are actually standard tasks, so that say search in projects would find also steps contents.
Steps to be done (read: tasks to be closed) will be presented to users in the same locations where she usually finds her assignments and tasks.

So basically we have a “wizard” which let you starting a new “process” chosen from the ones you have set-up.
Processes are defined in JPDL, a powerful business process definition language (XML based) which covers all the usual fork/join/milestone etc. needed in process management. There are three aspects of workflows in Twproject: usage, administration and customization. In this section we will examine the usage only.

screen1221In order to start a project as “process” from the add button click on “create process” button.

This leads to the create process wizard that let you choose one of the available processes.

Once the process has been chosen for every step a task will be created, so here you have to assign a resource. The role is pre-filled in the process.
Depending on how a process has been designed, some assignment could be created “at runtime” using several possible options like “process starter”, “my boss”, one “random resource of a team” etc.

screen1223Fill every assignment and click “create the process”; you will redirected to the task editor page. As you can see process driven tasks have a slightly different editor and have a “process” button instead of the Gantt link. This because processes are managed by a separately defined process structure, and not by editing a tree.

screen1224

 

 

 

The swimlane view:

screen1225

Active tasks are on pink color, gray ones are completed.

screen1226When the current task is waiting for you action, you’ll have it on your home and a button will allow you to complete the task.

 

Once you completed your job, just click on proceed button.screen1227

 

Executing a step will automatically change status of tasks in the process flux and will notify the following resources there is something to do.

screen1228

The interesting case is when you will arrive to the “customer approval” step where you can approve or reject the development:

screen1229

Seems simple? Ok, now follow this hyperbole….

 

Reducing trees to business processes

Converting a business process, that by default can be a complex graph (not just a tree), in a tree structure (that is an “oriented” non circular graph, technically: “A tree is an oriented graph with a distinguished node (its root) from which to each node there is a unique oriented path.”) is not only not trivial but also impossible, so we adopted some reduction rules.

First of all every process’ node that requires user action (called task-node in process idiom) is converted to a Twproject task. For every process-“task” (in processes a task is an action required from a swimlane in a task-node) we create assignment with the role of the swimlane.

By doing this you can have task that require double confirmation (so you can have for instance processes with joint signing).

Example: a task-node of the process requires one action from swimlane A and an action for swimlane B. This is converted in a single task with two assignments.

Then there is the graph reduction problem…. We solved this by applying a “running reduction”; this means that every loop is cut and straightened during the instantiation phase. During the running phase when the process loops back, the statuses of tasks (Twproject tasks) are changed accordingly, a sort of rewinding of time, but the path is always straight.

Supporting change

In business processes, if you define a workflow, you can revise it anytime. Parallel instances of  “version 1” of still running processes and new “version 2” ones should co-exist. In this sense business-process enhanced project management becomes compatible with “change management”, so important in large organizations.

Now someone may be wondering: already the idea of introducing the complex sounding “project management” in our organization is scary, add “business processes”, it sounds horribly complex. Well, we actually agree with those feeling. But in Twproject it all comes down to very simple solutions: at least if you adopt Twproject, you are not letting very expensive, complex, old and unusable software enter the organization, but something quite simple and that can be loved by the users, as a time and memory saver. If your process is say registering incoming orders, performing draft in several phases, and then getting feedback either by customers or from internal testing, well this is a typical business process, in particular if you have recurring test phases, and this is what you’ll get from Twproject.

For a complete overview about Twproject business process, administration, maintenance, customization and JBPM technicalities see the customization section.