Writing perfect processes is a dream all Process Street users share.
But a perfect process isn’t necessarily a process where all the steps work perfectly all the way through.
In real life, processes come up against external forces and unforeseen circumstances. A perfect process doesn’t have to predict all these external influences in advance; it needs to be able to adapt to them in real time as they arise.
Fortunately, there’s a concept for this: Process Flexibility.
Process flexibility helps keep our processes working even when everything else is going wrong.
In this article, we’re going to outline what process flexibility is and the main approaches to managing it:
- What is process flexibility?
- What are the main approaches to process flexibility?
- Flexibility by design
- Flexibility by deviation
- Flexibility by underspecification
- Flexibility by change
- How Process Street is designed for agility
What is process flexibility?
Process flexibility is a concept used in process management which refers to how an operation responds to outside factors, normally changes to supply or demand. Utilizing process flexibility well should reduce the cost of external factors which impact on a process.
What happens if demand soars? What happens if demand drops? What happens if demand loses its consistency and begins to fluctuate wildly?
How does your business react to these changes?
Do you invest in ramping up production? Do you lay off workers? Do you implement a just-in-time production system?
These scenarios also beg the question of how ready your organization is to deal with these changes. Process flexibility cannot prepare you for every external force you may come across, but it is about giving yourself the wiggle room to respond to these kinds of changes as they occur.
Along a given dimension, flexibility lowers the future cost of adjusting production decisions in response to changes in the external environment. Product design adjustments affect the demand for the firm’s products, while process adjustments lower the firm’s production costs. Our analysis reveals that these two types of adjustments are complementary in terms of increasing the firm’s net revenue in a given period.
But how does it work in practice?
What are the main approaches to process flexibility?
One of the difficulties of providing an overview of how process flexibility is implemented in practice is that there are no real overarching standards.
As Schonenberg et al outline in their paper Process Flexibility: A Survey of Contemporary Approaches which attempts to provide a taxonomy of current practices, most working standards focus more on notation; do we use XPDL or BPMN?
Instead, Schonenberg et al focus on looking at the differences between process or workflow based approaches, and the business processes of approaches with an implied process – like groupware systems.
Their explanation of process flexibility contains an interesting and somewhat counterintuitive description:
Process flexibility can be seen as the ability to deal with both foreseen and unforeseen changes, by varying or adapting those parts of the business process that are affected by them, whilst retaining the essential format of those parts that are not impacted by the variations. Or, in other words, flexibility is as much about what should stay the same in a process as what should be allowed to change.
The second aspect of their paper looks at contemporary software and how effective they are at providing process flexibility. However, given the fast paced world of software, that analysis is now laughably out of date. Later in the article, I’ll demonstrate how Process Street helps you achieve the kinds of flexibility described in this academic paper.
The first section, though, is highly relevant.
Schonenberg et al present the four major approaches to process flexibility and describe each in detail. These methods have been taken from their analysis of production techniques and of the available literature.
I’ll provide a definition for each – direct from the paper – and explain what this means and what scenarios it might be used in.
The four major approaches to process flexibility
- Flexibility by design
- Flexibility by deviation
- Flexibility by underspecification
- Flexibility by change
Flexibility by design
Schonenberg et al provide the following definition:
Flexibility by Design is the ability to incorporate alternative execution paths within a process model at design time allowing the selection of the most appropriate execution path to be made at runtime for each process instance.
This kind of approach is great for any process which needs to be used in a dynamic environment; a situation where the flow of the process depends on real-time variables.
The key here is that the process was designed to be flexible at the very beginning. The people designing the process were aware of the variables the process user would meet and so built in strategies for incorporating the effects of these variables into the process.
At Process Street we refer to this approach as conditional logic; at least, that’s the feature we use to accommodate it and it’s how we discuss internally the idea of built in process variations.
This could be something simple like our customer support process. The person using it identifies what kind of question a customer is asking and they enter that information into the process. The process then reacts to that new information and displays the steps relevant to them and hides the steps which aren’t related.
It’s a choose your own adventure but for business processes.
This model is obviously not ideal if there are significant unknown variations or such a large number of variations that it’s impossible to account for. I wouldn’t build a writing process with this system as it would possibly be far too complex and varying of a process to function or provide any value.
How you can use Process Street for flexibility by design
Let’s take our internal Company Research Checklist, embedded here below.
As you can see in the checklist, there are form fields within each task. When the checklist is run, the user is only shown the steps which pertain to them.
So, if we take a look at this image below, we’ll see that company details have been entered and we’ve selected in the visible form field to state that we do not have information about the company already in our CRM. Therefore, the next step is to begin the website research.
However, if we do have existing data on the company in our CRM and select that within the form field, then the next step for us changes. Take a look at the image below.
Now, the website research section does not have a task for us to begin. Instead, our next task is to assess what relationship our business might have had with that company in the past.
The tasks presented to us have changed on the basis of variables; variables which we were able to account for in the process design stage and build into the flow.
So, how was this achieved in Process Street?
When editing the process template, you navigate to the task where you want to enter the direction of the flow and click on the Conditional Logic button at the top of the page. Here’s the logic for that task:
As you can see, it doesn’t require any code and simply operates via the same kind of form fields you might find in your checklists already. These simple dropdowns help you define what the trigger is, what the result is, and how that relationship is defined.
This allows for you to quickly and easily account for known variables when you build your process.
You can read more about ways to use conditional logic here: How to Use Conditional Logic: 8 Ways to Simplify Complex Processes
Flexibility by deviation
Flexibility by deviation is another simple one:
Flexibility by Deviation is the ability for a process instance to deviate at runtime from the execution path prescribed by the original process without altering its process model. The deviation can only encompass changes to the execution sequence of tasks in the process for a specific process instance, it does not allow for changes in the process model or the tasks that it comprises.
Basically, it’s the freedom to follow the process in a slightly different order in case you suddenly need to.
One of the examples given in the paper is a doctor greeting a patient. Ideally, the doctor greets and assesses the patient first, taking their details and entering them into the system. In an emergency scenario, however, that all goes out of the window and the first priority is to treat the patient to some degree; the admin and pleasantries can wait.
Some processes need to be followed step by step.
The doctor, to continue the example, will follow the steps (i) locate vein (ii) enter needle, and that won’t change. For certain aspects of a process things need to be sequential. If you’re operating flexibility by deviation, you need to understand at the design phase what aspects of a process are fixed and which ones can be kept open for accepted deviation just in case.
How you can use Process Street for flexibility by deviation
At Process Street, our default setting is to have all tasks open so that the user could, if needed, jump ahead on the set process. Our stop tasks feature allows the person designing the process template to add enforced sequence where they deem it necessary.
It’s my personal opinion that process adherence should be achieved first and foremost through having a well designed process which benefits the process user most if used sequentially, and secondly through a culture of process adherence within the organization.
However, that’s just a general feeling from me on process management as a whole. Many processes in real life require sequential enforcement, which is why our stop task feature was so highly requested.
Within Process Street, a user knows if something is a stop task because it has a little asterisk next to it. If we return to the Company Research Checklist and zoom in, we can see these red markers – much like you would expect to see on any other kind of online form.
These markers are a simple and intuitive way of making sure the process user knows they are mandatory. If the process user does not complete a form field which has an asterisk next to it, then the process user cannot move onto the next task in the process.
This allows you as a process designer to define when a sequence is vital and when flexibility by deviation is preferred.
Note: if you’re applying conditional logic to your checklist then you have the option of only showing the process user the tasks which pertain to them. If you’re looking to allow for flexibility by deviation then it is best to leave those relevant tasks visible – otherwise you undermine your flexibility efforts.
It’s all about judging which approaches are most well suited for that particular aspect of a process.
Flexibility by underspecification
The paper describes this one as follows:
Flexibility by Underspecification is the ability to execute an incomplete process model at run-time, i.e., one which does not contain sufficient information to allow it to be executed to completion. Note that this type of flexibility does not require the model to be changed at run-time, instead the model needs to be completed by providing a concrete realisation for the undefined parts.
Pretty much, this is just the idea that you shouldn’t build complex step by step processes for tasks which are too large, complex, or prone to variation.
It’s pretty much the inverse of the flexibility by design approach described above.
And I’ll use the same example to explain why: my writing process.
I don’t have a set writing process. I have ways I normally approach it, but I’m not always consistent. It can change depending on the nature of the subject matter. More importantly, my process or processes likely differ from the flows of the rest of the team too. Writing an article doesn’t lend itself to a clinical defined process.
However, that doesn’t mean we don’t have a process for it.
We have a blog creation process which takes us from the very beginning of writing to the moment of hitting publish.
The process begins with defining the keyword and sending image specifications to our designer for the header image. The process finishes with all the formatting and SEO tasks. It’s a long complex process that upholds internal standards and best practices, while also tying the designer and editor into the flow.
It’s a good process.
But it has a huge gaping hole in the middle. The writing process itself. There are no steps for that.
Because we’re employing flexibility by underspecification. That particular aspect of the process does not require in depth detail and standardization. If anything, it benefits from freedom for the writer.
This is how we fit a complex, varying, undocumentable task into a larger business process. We define the parameters and provide process support before and after the task, but leave that space for creative freedom.
You shouldn’t run all your business processes like that, of course, as then you wouldn’t have documented processes. Some tasks lend themselves to this approach and it’s important to recognize when they do.
How you can use Process Street for flexibility by underspecification
Most of this is described above but one of our company policies is to always over-communicate, so I’ll quickly pull out our key takeaways for flexibility by underspecification.
- Use the traditional process design elements to determine the parameters of the underspecified section of the process. In our blog creation process, the initial section regarding keyword research and header design is explicit. The later sections regarding SEO and formatting are explicit too. It is very clear where the process freedom exists and where it doesn’t.
- For each task within a Process Street checklist, there is a section where you can include text, images, videos, form fields, or widgets. When using underspecification you can use this section to give guidance rather than procedural direction. The blog creation checklist could provide links to our best posts to show the process user what best practice looks like. Underspecification does not have to mean radio silence between the process designer and the process user.
Flexibility by change
The paper provides us with the definition:
Flexibility by Change is the ability to modify a process model at runtime such that one or all of the currently executing process instances are migrated to a new process model. Unlike the previously mentioned flexibility types the model constructed at design time is modified and one or more instances need to be transferred from the old to the new model.
This one is almost less about dealing with process problems as it is with dealing with process improvement.
The idea here is that you adapt to the variation and then build it into the process model in real-time.
The paper provides us with this nice long quote to explain it:
In some cases, events may occur during process execution that were not foreseen during process design. Sometimes these events cannot be addressed by temporary deviations from the existing process model, but require the addition or removal of tasks or links from the process model on a permanent basis. This may necessitate changes to the process model for one or several process instances; or where the extent of the change is more significant, it may be necessary to change the process model for all currently executing instances.
There are two points to pull out of this:
- Sometimes you realize the process model is wrong
- Sometimes you realize the process model needs to be improved
In both of these instances, you shouldn’t just deviate from the process during a run, you need to change the process at the source. And the likelihood is that you’ll need to change the process model for everyone.
This is something we do all the time internally at Process Street. We design our MVP (minimum viable process) and just keep changing the model and redeploying whenever we feel it needs a tweak and then we track the data.
Fortunately, we’re able to do that really easily as Process Street allows you to update a single checklist or all checklists with an improved template even while they’re still active.
You can change the process model in moments and deploy it live for all process users in real time with no wait or damage.
How you can use Process Street for flexibility by change
Imagine you’re running the Company Research Checklist for account management which we embedded and screenshotted above.
Let’s say I want to change the wording on one of the tasks. Or maybe I want to add another option to one of the dropdown fields? Or maybe I want to add a whole new section into the checklist with a bunch of new tasks?
All I do is go into the Edit Template wizard and make the changes I want to make. Then I click Save Changes and I’m presented with this pop up:
This gives us the option to force-update every active checklist or to do them manually. Every new checklist created will already run from the updated template.
If the changes you have made are small, then you’ll probably select to update all of them. If the changes you have made are substantial, then you may want to update them individually to check you aren’t losing any data or confusing the process user.
If you select to update them yourself, then the process user will see this pop up on their active checklist:
This lets the process user know that there is a new revision for them to move to, but gives the added flexibility of allowing them to hold off on an update if they feel it’s wise to do so.
To update, the process user simply clicks to expand the menu on the right hand side of their screen, where they will see the options for the checklist.
The path from wanting to improve a process model to having it new and fresh in the wild has never been quicker.
You could even add in complex automations rapidly without having to write a line of code or disrupt a workflow. All of these revisions are then stored and can be reviewed.
This feature allows you to improve and iterate your process model in real time with minimal disruption to anyone’s work. Flexibility by change is something Process Street takes very seriously, because flexibility by change is a core component of an agile methodology – something we know is of great importance to our users.
Which brings us to the key point…
How Process Street is designed for agility
Process Street was not designed with rigid unchanging structures in mind.
Process Street was and is designed with the principles of business process management in mind. This involves being able to adapt to new situations, being intuitive for a process user, and being able to optimize your operations as you move forward.
It’s the classic difference between Waterfall and Agile methodologies.
One spends half a year planning a process to put it into action as a fully formed entity, the other grows a process over time with love and care.
Both are valid approaches to utilizing processes, but agile methods provide more benefits to business processes specifically. Our goal with Process Street is to enable our software to work as your team does; in an agile environment, consistently learning and improving.
Where traditional software like Sharepoint or Confluence may need you to hire dedicated developers and to map processes laboriously in advance, Process Street allows you to be flexible, fast, and, dare I say it, fun.
Process flexibility not only improves your processes in terms of their output, but trusting the process user in key moments makes following the process easier for them too.
Process flexibility is a significantly underappreciated concept within business process management but one which Process Street, at least, is taking seriously.
How have you employed process flexibility in the past? Which methods worked best for you? Let us know in the comments below!