Business Processes
Why extend project management with business processes (we use business process as synonymous with workflow)? There are several reasons for extending project management with business processes; in fact the two are sometimes presented as alternatives for meeting team organizational needs. But with Teamwork you get the advantages of both, in an integrated solution.
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, we refer to http://www.workflowpatterns.com; just think of recurring phases for an example of 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 signatures, 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
See in this image how natural is to see a project tree as a flow swimlane based. Of course, you may always see that very same project as a more classical project tree , and you may have that the process is part of a wider project tree.
For more explanations and technical details, we refer to the user guide.
Want to know more?The main source of detailed information is the user guide.
Need icing on the cake?Look here.
OK, I'll give it a tryTry it here.
|
|
|
|
){kind=link}
){kind=link}