In the previous article we divided the collaborative work continuum into projects, processes, cases, document-oriented workflows and issues.
We also noted that it was made for analysis purposes only; in reality, they are interrelated. As an illustration, the PMBOK (Process Management Body of Knowledge) talks about processes more than about projects; similarly, the big part of BPM CBOK (Business Process Management Common Body of Knowledge) is devoted to processes improvement and process transformation projects.
This interrelation shows itself in the following:
1. Interoperability: one form of collaborative work initiates or calls another.
Examples: a patient’s treatment at the hospital (a case) calls a series of tests and procedures (processes). A project is instantiated by the project initiation process according to PMBOK.
2. Migration: changing the collaborative work classification over time.
Attributing a collaborative work as a project, process or case often is a matter of interpretation. The real world example: a pharmaceutical company considered a new drug development as a project, until one day they came to the idea of a standard project template. Soon after that they realized that this work should be better treated as a process.
Another common example is case-process migration. The popularity of case management is partly due to lower initial implementation and deployment costs in comparison with processes. Therefore, even if the activities flow is fully predictable and may be managed as a process end-to-end, an organization may choose to treat it as a case to save the process analysis, design and automation costs. The case management doesn’t require a process model or diagram – it starts from the given goal and assigning a performer who then defines and completes a series tasks, either by himself or by assigning them to others. After a while best practices can be collected, analyzed and implemented as a process – hence the migration.
3. Unified tasks management: every collaboration decomposes to tasks eventually. The task content remains the same whether it comes from a project, process or case. The “My tasks” portal should contain all tasks assigned to the performer wherever they come from.
4. Unified resources management: tasks coming from various collaboration channels usually require the same resources, i.e. people. A manager responsible for the efficient resources utilization should have the whole picture: what processes, cases and/or projects a particular employee participates in.
Software Supporting Collaborative Work
Let’s consider the existing software categories and their collaboration features and capabilities.
- Email. Probably the most common collaboration tool. It doesn’t provide reuse, predictability, accountability, cannot deal with structured data, yet it’s universally available and hence popular.
- File sharing. May come in various forms: network drives, internet services like Dropbox or Google Docs etc. Collaboration may still rely on email, it just becomes more “civilized”: large files are not sent by email, so there are less duplication and usually some version control.
- Enterprise Content Management (ECM). It perfectly fits the main purpose: managing the document life cycle. It has many advantages compared to file sharing: access control, versioning, indexing and fast search, scanning and content transformation, multi-level backup. The processes functionality is generally less advanced than that of BPMS, yet some products (e.g. EMC Documentum, Alfresco Activty) offer combined ECM and BPMS functionality.
- Issue/Problem Trackers. Originally appeared as bug (software defects) trackers and eventually evolved to the tools managing all aspects of software development: bugs, feature requests, builds, releases, etc. A typical tracker controls tasks assignation, duration, priorities. Users are able to comment an issue, attach images and files. The best products are fully configurable and may well be used to track issues of any kind from any industry, not just IT. Sometimes trackers are used to manage processes however these capabilities are usually limited by setting a simple attribute “State”.
- Adaptive Case Management (ACM). This category of software is still in its childhood hence it is sometimes difficult to separate the functionality really available from the hype. Yet it’s possible to name the common features: task lists (checklists) created dynamically by users, structured and unstructured content, business rules. Advanced functionality includes the ability to save a case as a template to help processing next instances.
- Project Management Software. It manages the list of tasks and dependencies (sequences), supports scheduling, resource planning and costing. Advanced functionality includes critical path calculation and project management portfolio planning within given resources constraints. The project content is typically unstructured: text documents, links to web pages.
- Business Process Management Suites (BPMS). A typical BPMS includes process and data modelers, screen forms designer, process execution engine, business rules, user portal, monitoring and analytics.
Summarizing it up, all quadrants in Fig. 2 from the previous article are covered:
- ACM for cases
- ECM for documents
- BPMS for processes
- Tracker for issues
- Project Management software for projects
This the good part of the news. The bad one is that there is no single tool able to support all forms of collaboration unless your organization mainly relies on just one form, e.g. it’s totally project-oriented.
A possible option for others is to use more versatile but less functional product, e.g. managing processes via tracker or ECM. After all, an organization can manage everything with just email and file sharing. The negative implication of this approach is manual control. It’s generally non-robust and error-prone.
The opposite approach is “downsizing”, e.g. using a heavy-weight BPMS to manage issues. It’s not too difficult to implement but probably it will be much more expensive and more complicated than using a dedicated tracker.
As the figure above shows, case management, document management and issue tracking are “close relatives” so ACM may be a reasonable solution for them all.
Benefits of The Unified Collaboration Environment
Why should we need a single environment? After all, “best of breed” concept has some advantages too.
Apart from standard arguments like “simpler IT infrastructure” and “lower maintenance costs”, there are certain specific arguments:
1. Interoperability (see above)
2. Migration (see above)
3. Unified task management
From user’s perspective there shouldn’t be significant difference between tasks assigned from a process, case or project. Each one may be presented by a screen form containing some input data, output data/decisions, “Done” button. However, if they are managed by different software, the difference will be substantial. Besides, users will have to switch between portals.
Apart from different look and feel, different collaboration software provide different functionality: delegations, notifications, tasks assignation and load balancing, logging etc. would be implemented differently or not implemented in some products.
4. Managing resources across projects and processes
How many employees participate in projects only or in processes only and how many participate both in processes, projects and sometimes get one-time tasks, too? How should their workload be managed? How should these tasks be prioritized? How can a manager decide whether an employee doesn’t actively participate in a project because he/she is busy or truly overloaded?
It’d be hard to answer these questions as long as projects and processes are managed by separate products. Apart from separate environments and rather technical issues of data aggregation, there is a serious methodological problem: project and process management approaches to resource planning are fundamentally different. For example, “project people” are often shocked when first acquainted with a business process management software. They ask a question: “When will this project (i.e. a process instance) complete?” and get a disappointing answer like: “The duration of a particular instance is unknown. The average duration of this process equals…”
That is, process duration and costs are approached statistically whereas a project has a schedule that provides the exact answers to these questions. (Well, in fact the accuracy of project estimates isn’t absolute either: the project plan may be revised so that durations costs would change. So these estimates are probabilistic, too, but this is usually ignored.)
5. Unified platform supporting social, mobile and cloud
Today any collaborative environment shall meet certain standard requirements: mobile access, support for social interaction (like Facebook or Twitter, but within the company), cloud deployment option. Implementing all these requirements in a single platform means significant costs saving.
But even more important is user experience: who needs several social networks within the company – one for project work, another for processes etc.? There must be just one, obviously. A social collaboration enclosed within a silo would not gain the critical mass of participants and therefore not take off.
The Vision of Collaborative Environment
As of today, no software vendor offers a single environment supporting all forms of collaboration. However the demand becomes more and more evident so a number of companies, including OpenText, IBM, SAP are developing such solutions. Comindware has made it the core mission which is reflected in the company name: COllaborative MINDs softWARE.
Let’s outline the basic principles of the unified collaborative environment:
1. Case-management has everything one needs for issues and documents tracking
The case management supersedes document-oriented workflow by structured data support. Unstructured information (content) is supported by both.
Cases also differ from issues by repeatability.
Therefore case management is able to support both issues and documents tracking. There will be some redundancy, yet not critical. Separate support of issues and documents isn’t necessary.
2. Cases and processes are essentially different yet supplementary to each other
The difference is that a process is predictable while a case is unpredictable. Within a process, a task is created and performer is assigned according to the process model; within a case tasks and performers are defined by a user on the fly. Taking into account interoperability and migration requirements above, cases and processes must be integrated as much as possible. Monitoring and analysis can and should be common.
3. Cases differ from projects by being structured, repeatable and unpredictable
Are these differences critical, do we need to support projects essentially differently than processes and cases? From project management perspective, support of structured data and repeatable work is excessive but the overhead doesn’t seem to be critical.
Predictability dimension is more challenging. As was mentioned above, projects are essentially predictable; ability to plan the project end-to-end is mandatory. Cases, by contrast, are dynamic and unpredictable. In theory, it is possible to allow case tasks scheduling in advance and to implement tasks dependencies like in typical project management. It’s doable but it’d make the possible tool that supports both projects and cases overcomplicated. After all, the ease of use is the major advantage of case management solutions so it should be preserved.
Therefore, projects, processes and cases should be treated as separate entities; interoperability and migration should be supported indeed.
4. Processes differ from projects by being structured and repeatable
Both are predictable yet as noted above, in a different way: a project is predictable at the instance level (Gantt chart shows it all) while a process is predictable only statistically. A closer examination reveals that this difference is not fundamental: one can depict the already completed process tasks as a Gantt chart, thus lowering the barrier between projects and processes.
Predicting the future of a process instance is much more difficult indeed yet not impossible. Statistical predictions may of the most probable tasks sequence and their completion dates can be made based on the history of previous instances. The forecast would be more accurate if the data (process attributes values) were taken into account.
General Functional Requirements
5. Support for both unstructured and structured data
Unstructured information need to be supported in projects, processes, and cases. Structured data is a must in processes and cases while optional in projects.
It should be also possible to work with the data directly, without a process or a case. The development environment of a typical BPMS already has everything one needs for this: data modeling tools, screen forms designer, runtime forms engine; however most of them give access to this functionality from a process only. This seems to be an artificial restriction and should be removed.
6. Unified task management
Regardless of where a task comes from it should appear in a common “My tasks” list. All tasks should obey the same rules of assignation, delegation, notification etc.
7. Total resources management
Tasks assignation & load balancing, labor costs accounting should span tasks coming from projects, process and cases uniformly. Resource planning and possible overload identification should utilize statistical methods mentioned above (#4).
8. Support for social interaction
Uniform user experience through projects, processes and cases. Comments feeds, likes, subscriptions, invites, notifications, etc.
System Requirements
9. Data storage
Process management software clearly separates design- and runtime. It makes a traditional Relational DBPMS a perfect fit. The case management, on the contrary, requires the data model to be updated on the fly (in the runtime). This degree or flexibility can be provided by non-SQL data sources, e.g. semantic databases.
10. Cloud and/or on-premise
At the discretion of the customer, the solution should be available on-premise, deployed as a cloud service or utilize a hybrid model.
11. User interfaces and devices
One hundred percent functionality, both runtime and design time (process and data modeling, screen forms design, business rules etc.) should be accessible through a web browser. All runtime functionality (execution, monitoring and analysis) should be available on major mobile platforms (iOS, Android).
12. Legacy integration
This part of the requirements intentionally left beyond the current discussion.
- Originally published at BPM.com
Previous parts of the series: