While Salesforce provides a variety of tools to automate structured business processes, it does not provide the same level of functionality for “unstructured” processes (better referred to as “situational” processes – an unstructured process is an oxymoron). Thus, Salesforce tools must be augmented by tools that better support the increasingly complex, dynamic, and fragmented nature of work.
Designing a business process on the Salesforce platform involves mapping out all the steps required in the process, accounting for all possible paths, exceptions, events, etc. At some point, we declare the process design “complete.” This works well for processes that are structured, stable, and predictable.
But of course, in the real world, things are not always well structured and predictable. The problem is that the minute something happens that is not fully supported by the defined process, process participants are forced to jump out of the process into the chaotic sea of email and spreadsheets.
The Process Spectrum
There is a broad spectrum of processes – from the fully automated processes that Salesforce tools support, to the completely ad hoc processes on the other side of the spectrum.
Structured processes are designed to execute the same way every time. You can analyze them ahead of time, work out a pattern, then execute the same way every time. The key thing here is that executing routine work the same way every time can be limiting; we want processes be standardized and efficient, but there’s little room for creativity in these processes.
BPM industry analyst Sandy Kemsley describes it this way:
In order to standardize and automate routine work, it takes some amount of analysis and implementation up front, but the high volume of repeatable processes makes that effort pay off.Many end-to-end processes contain several phases, each of which may be at a different point on the process continuum and may be more or less likely to be subject to unpredictable exceptions.
Knowledge work, on the other hand, doesn’t have the same level of predictability as the routine work; instead, the knowledge worker needs to be able to decide what action to take next on a particular piece of work, and when to send it on to someone else. Since the processes don’t happen the same way each time, it’s more difficult to manage them using standard structured BPM methods as with routine work. If you had to map out every possible path that could be taken in this sort of situation, it would take forever to get something implemented, and it would never be complete. In other words, it would be too expensive to even try to do that sort of modeling and implementation for a process that is truly knowledge work. Furthermore, not only is it not possible to remove all of the runtime variation in knowledge work, it may be that variation – and the ability to manage it – that brings value to the process.
Supporting Situational Processes
The objective is to introduce a measure of structure and control into the everyday interactions between humans to assist them in reaching a common, predefined goal.
To model a process that has varying degrees of structure, we need a toolkit that supports the nature of the process.
In this environment, it is responsiveness, not efficiency that is the goal. So it’s not so much a matter of automation, though automation has a role to play – rather, it’s all about facilitation.
Here, change is the organizing principle, not a problematic intrusion.
With the right framework, uncertainty ceases to be a threat and becomes an opportunity. By facilitating the ability to dynamically shape processes to match each unique situation, companies can gain a significant competitive advantage.
Structured vs. Situational Processes
|The goal is to get repetitive work done as efficiently as possible.||The goal is to enable users to get their work done as effectively as possible by making it easier for them to make the right decisions and take the right actions at the right time.|
|The measure of success is the increase of volume of throughput or work completed for an individual process.||The measure of success is the optimization of outcome for each individual instance of a process.|
|Tries to eliminate as much human involvement as possible through automation.||People are an inherent and desired part of the process.|
|Controls the process by defining it in advance.||Does not try to control the process, leaving it to the user to define as it happens.|
|Reduces the need for judgment. The process designer builds all the decisions about what happens into the process. People just need to follow along.||Gives the user control over what tasks get done and what sequence to follow.|
|The rigidity of process limits what users can do when there is a set of circumstances the process cannot deal with.||Users have more, not less, control over their working day. They get to route things to the right people when they see the need, without any software barriers preventing them from doing so.|
|Requires a trained resource to pre-program sequence and rules.||No formal training is required, and sequence and rules are added as needed.|
ImplementationImplementing software to effectively support situational processes needs to include the following functionality:
- There may be little or no predefined process flow, with the worker defining the flow as the process progresses.
- Exceptions are not seen as exceptions – rather, they are simply a way to adapt the process to new realities. The way to deal with this is not to cause exceptions through rigid processes, but rather to facilitate the process participants to handle the exception inside the defined process.
- To do this, process participants need to be able to make changes to processes on the fly.
- These modified processes can optionally be saved as the new and improved process to be used the next time the process is run.
- Rules embedded in the process are enabling instead of controlling, in the sense that the user is prevented from doing things that must not be changed (e.g. for compliance reasons), but are able to do whatever else is necessary to make the process work. In other words, the rules are there not to tell participants what to do, but rather what they cannot do.
- To support this, business rules may constrain the selection of specific tasks, or trigger other tasks and processes based on the user selection of tasks within the process.
- The process can continue normal operations once the exception is resolved; the process does not have to be abandoned or restarted from the beginning.
- The process folder provides a persistent container for all tasks, rules, content artifacts and history related to the specific situation, so that process participants have a complete understanding of what has transpired before.
BenefitsThere are many benefits to this approach:
- Processes become adaptable to changes in the environment in the normal course of business.
- The flexibility this provides gives participants the ability to apply their knowledge and not simply follow rules.
- What were previously ad hoc tasks done outside the defined process become part of the process, providing visibility and auditability.
- There is no need for participants to step outside the system into the black hole of email and spreadsheets.
- Being able to make changes on-the-fly provides a competitive edge – you are taking the knowledge that is in workers heads and applying it directly in business operations. Harnessing and coordinating these unstructured processes is a way to provide customers with a consistent, cohesive and agile experience.