To start using Signavio Workflow to coordinate a business process, you can start with a simple process, and incrementally add structure. This article shows an example of a business process that can start small but which may hide plenty of complexity.
For this article, let’s revisit the business process that provided the example for Google Cloud Print Integration: Sign Contract. Signing a contract may seem trivial at first, but it involves more than the simple act of putting a signature on a piece of paper.
Signing contracts
As you would expect, the process goal is to sign a contract. To start with, you don’t need to do any process modelling to add this to Signavio Workflow: instead create a process with a single task that represents the process goal.
Two things characterise signing contracts, which make software support worthwhile. First, a manager may have a large number of contracts to sign at any one time, which can make it a challenge to keep track. Second, any mistakes or forgotten contracts may incur a higher cost than neglecting other kinds of tasks.
The traditional solution uses a printed copy of the contract as a physical token, and an in-tray to manage incoming cases. This remains reliable, as long as you can keep the contract in the tray, handle one at a time, and don’t need to work with electronic copies.
In Signavio Workflow, even a process with a single task benefits from an overview of open cases, so you can see which contracts haven’t been signed yet, and task assignment, due dates and escalation, to manage the work in a team.
Reviewing contracts
When you use a simple process for a number of cases, you naturally learn how you would like to extend the process model. This typically means adding a modelling pattern, such as an approval pattern or a collaboration pattern.
For signing contracts, add a document approval pattern before the Sign contract task that completes the process.
Now the process has two roles: a Signer will review and sign the contract, and the Author will update the contract if necessary. Either one could start the process and upload the draft contract for review. Next, add another role.
In Signavio Workflow, you can publish this new process version without affecting existing cases, which continue with the version that was current when they started. Meanwhile, new cases will use the new process version. This allows you to work incrementally, and frees you from attempting to model the complete process up-front.
Notifying the requestor
The process may still have a separate Requester role for whoever requested the signed contract. Use this role with Notify Requester, an email notification pattern that emails status updates to the person who started the case.
This version of the process adds a new Decline option for the approval decision, and sends an email notification that informs the requester whether the signer has signed the contract. The email tasks require the requester’s email address, so on the Upload contract task’s form, add a Requester field (either a user or email address).
Additional changes
When you start with a simple process, such as the first three versions above, you might consider using off-the-shelf software. In practice, however, you tend to reach the limits of a standard tool’s flexibility sooner rather than later.
With Signavio Workflow, you can continue to extend the process however you like. This next version incorporates several more changes.
This version adds a Delegate review option, to reassign the Signer role to someone else. The Request Change option now has a separate task for describing the change, and the success flow now has Google Drive archive and print tasks, in parallel with the success email notification. Finally, this model includes explicit start and end events, for clarity.
Conclusion
However simple the Sign contract process may seem at first, you still benefit from the flexibility Signavio Workflow gives you to start simple and gradually extend the process while you use it. At the same time, the value of this incremental approach also applies to other processes.
As a process modeller, you might think that you should stop extending these process models at some point, because increasing complexity and flexibility increases the cost of maintaining the model. In practice, however, people get a lot of benefit from evolving a process that matches exactly how they work, however much complexity the reality hides. Best of all, you will find it easier to simplify the way you work the more visibility you get about how you work.
Photo: jason saul / CC BY-ND 2.0