Nintex Workflow Complexity

Some of the feedback I have received after my recent post Why would I buy Nintex? was in regards to how to gauge the complexity of your workflow.  Now one way is to actually map out the process and see how much work there is in automating the process.  The problem with mapping out the process is that now you have gone a long way down the road and are not even sure it is viable to re-engineer; although I recommend it even if you were not doing workflow automation.  The other way, which I want to go through today is a simple way to quickly evaluate it so you know whether it is a simple, medium or complex workflow.


The other question that users often have is, How do I know if there is value in automating a process?  I will go through each of these and hopefully provide you some insight that makes your life easier or at the least clarify something you had a question about.

Part I - Gauging Complexity

Now. like my previous post I am going to do some basic math that you can apply to calculate the level of complexity, first I want to define those levels and then you will know a ball park of the budget to map and create the workflow in question.


Before I get into defining the levels of complexity, I want to point out that the majority of effort in process automation is the actual mapping and redesign, not the programming, though the programming is the direct cost, while the other efforts are not. 


As I mentioned above, process mapping should be an existing function within your business units, it allows you to see your processes and quickly identify areas for improvement, if it is not being done regularly, you may have a lot of work ahead of you.  The good news is you can and should take an iterative approach to making this happen.  What I mean by that is that you can record it and come back to it as needed to refine the process; processes are often moving targets until they are mapped and set as a standard.  There is really only one rule you can rely on with an undocumented process and that is the process will change!, so map it as soon as you can, communicate it to everyone and make modifications as necessary.


A simple rule to use for gauging the amount of time to map and reengineer a process is typically 60-80% of the total time to get a final automated workflow that meets your needs.


Ok, so let's talk about complexity, as I mentioned above we can use some simple buckets (if you will) for the complexity of the process automation. A simple workflow is from 0-40 hours of effort to create, a medium complexity workflow takes from 41-120 hours of effort to create and a complex workflow takes more than 121 hours to create.  These numbers are based off the use of Nintex and you can multiply then by 2-3 times for C# development, depending on how good your developer is.

Complexity of the Workflow

Ok, so now that we have an idea on the size of the buckets, we can do our math that will help gauge which bucket our proposed workflow should fit in.  If we look at a process from a high level we can ask and answer a few questions that will help us gauge the complexity.  I will explain why it is important before we calculate.

1. How many users in the organization does this workflow affect (meaning how many are going to use it)? N
2. How many people/business units are going to need to interact with this process? I
3. Roughly how many steps from beginning to end do you perceive? S
4. How many possible results are possible (roughly)? R
5. How many different systems are involved? V

Ok, so we have some variables and here is why they are important.

1. N is a number that represents the number of employees (in multiples of 5000) utilizing the workflow, the larger the number the more impact on complexity, a good rule of thumb is that you can expect the workflow complexity to double for every 5000 users that interact with it, but anything less than 5000 should not affect it.
2. I is the number of interactions, for each person/ business unit that interacts with the workflow you can expect roughly 5 additional actions in the workflow.
3. S are the total number of perceived steps, for each of these steps you can expect roughly 5 actions in the workflow.
4. R is the number of results, in a workflow these are different paths and it is easiest to think of it as a multiplier of the number of tasks where two or one is the base number of outcomes and the addition of another result will effectively double the actions.
5. V is another complexity multiplier, when ever we interact with any system outside SharePoint, we are doubling the complexity.

So here is what the formula looks like:

1. N = Answer to Q1/5000, Round up
2. I = Answer to Q2 * 5
3. S = Answer to Q3 * 5
4. R = If Answer to Q4 is 1 or 2, then 1 otherwise Answer to Q4 - 1
5. V = Answer to Q5 (there is always at least SharePoint)

X = (I+S)NRV


Now if we use an example of a company of 250 people wanting to do a vacation leave workflow.  The workflow needs approval from their direct Manager and notification sent to the requestor and HR of the result.  The vacation leave needs to poll the Accounting system to determine the number of days available for leave and then deduct the amount when approved.  From this scenario we can calculate the complexity as:


Q1. There are 250 People
Q2. There are 3 interactions (Requestor, Manager and HR)
Q3. There are 6 steps

1. Make the request
2. Poll the accounting system
3. Send to the Manager
4. Deduct the Leave
5. Notify HR
6. Notify the Requestor

Q4. There are 2 results.
Q5. There are 2 systems (SharePoint and Accounting)


I = 3*5 = 15
S = 6*5 = 30
N = 250/5000 = 0.05, Rounded up = 1
R = 1
V = 2


X = (15+30)*1*1*2 = 90


90 is rough hours to create your workflow using Nintex. If we put that in our bucket we would say this is a medium complexity workflow, which I would expect due to the interaction with the accounting system.  I personally would use the upper end of the bucket for medium and low complexity workflows and would perform a proper mapping for anything that seems to be complex.  Be prepared however for changes in interaction and re-evaluate any workflow each time there is a change in scope as it affect complexity, especially when dealing with the multipliers.

Part II - Gauging Value

The second part of this is how do I gauge the value of automating a workflow?  You can do time and motion studies and determine the actual time spent on tasks, or you can use rough numbers again.  when using the rough numbers in this case be optimistic on how quickly people are performing the process today, it will give you a pessimistic value for automation.


In part one we asked the question, how many users interact with the process, this number will be used again as a base multiplier.  We will then ask two new questions,

1. How much time does someone currently spend doing this task? remember be optimistic, ask a small sample and take the lowest three numbers averaged as your result.
2. How often do they need to do this task? again ask a small sample and take the three largest occurrence averaged out and represented as a yearly amount.

Now we simply calculate:


N = Number of people
T = Time spent currently (in Hours)
O = Task Occurrences/Year


X = NTO


The result is the number of Man/hours/year spent on this process.  You can then compare that to the estimated savings in time spend and the cost of development, here is a continuation of our above example.


As above, when asked the above questions we get the following answers: currently our people spend an average of a half hour filling out and submitting a leave request, then carrying it around for approvals and checking the system for available leave.  Based on the small sample people do this once a year.


So now let's do the math:


X = 250*0.5*1 = 125


So currently it costs the company 125 man hours for leave requests, we can expect the workflow to reduce the time of a leave request to roughly 15 minutes (note I am being pessimistic the other way now, taking the maximum time it should take).  If I calculate this I can then get a gauge on how long it will take before I make my money back.


X = 250*0.25*1 = 75


So we can expect to half the total number of man hours by automating this workflow, but the 90 hours we incurred above to develop it, means we will not positively affect the bottom line until the second year (90/75 = 1.2 years ROI).  Is that worth it, I guess it depends on you...


Feel free to follow me on twitter @DavidRMcMillan or @DevFactoPortals or become a member of this blog.  Thanks, feedback is appreciated and encouraged!