In most businesses, how processes perform is directly tied to the bottom line, down to how the steps within the workflow process matters.  Certain FlowWright customers process very large numbers of workflow instances per day; with large numbers like that running, performance is important.  In the case of processing drug prescriptions, 500,000+ workflow instances per day, that requires a very tight planning and execution. 

Given today’s infrastructure in the virtual environment, combined with physical server environments, companies need to be mindful of what their process architecture looks like. FlowWright is built in such way to take advantage of today’s processor/hardware architecture, even including distributed environments.  Especially in physical server environments, performance is limited to what you run on, as the FlowWright engine can be configured to perform in a distributed environment, all you need to do to solve for this challenge is add another physical server for processing.

So how do you measure the process performance? Well, there are many ways to do that:

• Render the workflow instance to view what steps within the workflow was executed and the number of times the step executed
• Tooltip on a rendered step shows how many milliseconds the step took to execute
• Using Business Intelligence, you can run a report on the workflow instance to view what steps took what amount of time to execute

Most engine steps within FlowWright execute within a few milliseconds, but user interactive steps may take minutes or days to complete, especially during a step like the "Task Step".  Using BI (Business Intelligence), process bottlenecks can be easily identified, since workflow instance execution can be graphically rendered, redundant steps and paths can be easily identified as well.  Given the last 2 points, process performance lead itself to optimization and improvement of the process.

In certain company processes, such as human resources onboarding, the workflow might wait until employee joins the organization.  In a such scenarios, these wait times must be included when measuring overall processing performance or the data will be flawed.

When a step executes, other timeouts can also come into play, for example, a SQL execute step might try to connect to an invalid database connection, where the default timeout for a database connection try is 15 seconds.  In this case, the workflow step will show that it took ~17 seconds to execute.

As described above, FlowWright provides many ways to measure process performance for all types of industry use cases.  As new versions of the software is available, more and more new process improvement/measurement features will be added to the product.  Measure your processes today with FlowWright!

https://www.flowwright.com/contact

Get started today with a customized demo.