Integrify BPM In Action

Who's Working on this Task?

2008-08-05T13:54:00Z

I recently received the following question:

"During our introduction of Integrify we experienced a very urgent issue: a lot of tasks get assigned to multiple people who are spread over different locations. To avoid multiple people doing the same work at the same time, everyone of them has to check if any body else has already “opened” the task and is working on the task. And even worse, by opening such a task and viewing the other’s people’s state you get marked as “in progress”. So from a controller’s view it is impossible to tell who is actually working on the task or just took a look at the other people’s state without speaking to everybody! "

We’ve actually run into many situations like this where a task is thrown out to a “queue” of rotating individuals and someone accepts to take a task on. The most efficient way to handle this is to slightly modify your process and have a task where all individuals are assigned but once a single individual completes that task it is cancelled out for all of the other recipients.

Take a look at the following Task Flow:

The first task is just a Milestone that is assigned to a group of individuals. The Worker Queue Milestone has a single option that states “I Accept This Work Assignment”. Once a person selects that option and completes the task, the next task called Form to Complete is assigned to the Dynamic Recipient Task Completer for the Worker Queue Milestone task.

As the process is executing it will look something like the following:

Another feature of structuring your process this way is that as an individual accepts the work assignment it will cancel the open task for the other individuals assigned, thus removing it from their dashboard automatically.

By structuring your process in this fashion, it will make it easier to identify who accepted a given work assignment and then the owner of the process can always monitor who is assigned to the Form to Complete task rather than trying to interpret the statuses of the other tasks where many people are assigned. It will also facilitate easier communication among your work force that maybe spread across several locations.

Measure Your Success (but plan it first!)

2008-02-26T19:02:00Z

How do you measure success with a product like Integrify?

How do you continuously improve on your process?

How do you make your superiors happy (look good ;-) and show your return on investment?

If you thought “reporting”, you are correct.

What is often not accounted or budgeted (time or money) for on most implementation plans?

If you thought “reporting” again, you are correct again!

In this and in other positions I have held, reporting and measurement of success always seems to be the after thought of most project/software implementations but in reality the definition of success and how to measure that success should be one of the first line items defined in the project plan.

Before you start building your process and implementing it in Integrify, reporting goals should be well defined. Certain questions need to be asked:

Do you need to measure the overall length time a process takes to complete? (Process Duration & frequency)
Do you need to measure the overall time specific tasks take to complete within the process? (Process Duration & frequency)
Do you need to know who has been assigned to tasks and how often? (Task Assignment, Task Frequency, Task Duration)
Do you need to extract user input data? If so, does is it need to be in a specific format, arrange in a specific fashion? (task detail, task input)
Do you need to extract data at specific points/statuses in the process and not others? (task detail, task input)

Each of the above can, and probably will, represent a distinct report type within Integrify so this must be accounted for while budgeting time and money for your implementation.

The following diagram helps illustrates the different levels of reporting that can be achieved in Integrify:

To aid in reporting, Integrify categorizes reports into three basic areas:

Administrative: basic system reports about users in the systems, users in groups or roles, etc.
Process Analysis: high-level summarization reports about the number of requests executed over time, duration of requests for a given process, duration of tasks for a given process. (Process Duration & frequency, task duration)
Request Detail: who is assigned to a task, how often certain tasks occur, how often is someone assigned to a task, retrieve information from tasks, etc. (task detail, task input, task status)

When one builds a new report in Integrify all that one needs to do is select the Report Type (Administrative, Process Analysis, Request Detail) and then the appropriate Report Sub-Type (Task Status, Process Duration, Task Duration, Task Detail, etc). Based on those two selections, the report layout, types of columns, filters, summary totals, and graphing will be predefined for you. You will just need to optionally add some report filters or possibly some additionally grouping to finish off your report.

Unfortunately, reporting, like building a process for a first time, can be daunting at first. Like building a process for the first time, the tendency is often to do too much with a single report. The reality of reporting is that the best report is one that is concise and targeted to a specific goal.

For instance, in our Integrify Services engagements we often hear requests like “I need a report that displays the total number of requests over a given timeframe, all of the tasks assigned to Bob over that timeframe, and the data from Form C only if a certain status has been reached in the process.” The reality of it is that this is most likely three reports. Let’s break that request down into a few parts:

“…display the total number of requests over a given time frame…”: This can be accomplished it a Process Request Count report under the Process Analysis Report Type. This report type is specifically structured to retrieve basic request information over a given time period.
“….all of the tasks assigned to Bob over that timeframe…”: When analyzing who is assigned to what task, this is best served with a Task Status report under the Report Type of Request Detail. The Task Status report is structured to group the report by who is assigned tasks within a given process.
“…the data from Form C only if a certain status has been reached in the process…”: Any time a user requests form data or other task information, that will be a Task Detail report under the Report Type of Request Detail.

Once the reporting request is evaluated and broken down into distinct parts it is often easier to implement the request for your end users. In most cases too it is often easier for your users to digest smaller quantities of targeted information than trying to create a single report with all of the information.

Like building a process, building a report will be an iterative effort too. Be patient, be focused, and plan those reports with your users for the best success.

Good luck and happy reporting!

Handling Lots of Recipients: Dynamic Assigner vs. Recipient Rules

2007-10-25T19:15:00Z

Introduction

Medium to large sized organizations will often have business processes that are used by many different people. An example would be a New Hire Request. If your company is segmented into many regions or divisions, the same approval tasks could have between five and over a hundred possible recipients. This article will compare the two methods of conditionally assigning recipients to a task. Those methods are, 1) Using Recipient Rules and 2) Using the Dynamic Assigner task.

Let us examine a portion of a typical new hire request:

The branch manager of a particular location will start the New Hire Request and fill out the New Hire Request Form. On the form there is a question asking what branch the manager is in. The branch location question is a drop down list that contains all the branch location cities and a branch number value associated with each city.

The branch manager will complete the form by answering some other questions about the position such as title and salary etc. Once the form is completed, the branch manager submits it and the next task in the flow is the Area Manager Approval. The area manager can either approve or deny the New Hire Request. Let us take a look at the first way to assign the approval to the appropriate area manager.

Using Recipient Rules

If the number of areas is not too big, say no more than ten, it probably makes sense to assign the correct area manager using Recipient Rules. In this case, each area manager is configured as a recipient for the Area Manager Approval task. Since we only want one of the area managers to actually receive and complete the approval with each request, we need to enter Recipient Rules for each recipient indicating in what circumstances they are to actually receive the Area Manager Approval task.

The Area Manager Approval's task recipients screen

Recipient rules are defined by clicking on the link, "Rules" that is beside each recipient.

Here is what the Recipient Rules look like for Brian Allen who is the Area Manager for upstate New York

We see, that unless the Position Location question's value is either 631, 624, 613, or 628, Brian will not be assigned the Area Manager Approval Task. Each of those numbers represents a branch location somewhere in Brian's area.

For each recipient that we defined for the Area Manager Approval task, we need to add similar rules so that they are only set as the approver when the New Hire Request is coming from a branch in their region.

Configuring Recipient Rules is a straight forward way to handle the situation where you have multiple, optional recipients for a given task and there are business conditions which stipulate when the recipients are to be assigned. Recipient Rules do not scale well to a large pool of potential recipients because it is very tedious to define them in great quantity and they are also a headache to maintain.

The alternative to Recipient Rules and the preferred method for handling large pools of optional task recipients is to use the Dynamic Assigner task.

Using the Dynamic Assigner

The Dynamic Assigner is available as an optional Integrify task plug-in. It performs a parameterized query against a database in order to retrieve a list of contact id's that will be matched against the Integrify users list. For each match that is found, that user will be assigned to the task. In this example, we will create a simple look-up table which contains the branch locations, the area, and regional manager associated with each branch.

Here is a snapshot of the lookup table

The drop-down list of branch locations in the initial form is filled from this table so we get the branch number as the value when a user selects a branch location. The other two columns in the table, area_mgr_id and regional_mgr_id contain the Integrify contact id's for the for those managers. We will configure the Dynamic Assigner task to look at this table, get the contact id's of the managers, and then assign those managers to their approval task.

Here is the new workflow with the addition of the Dynamic Assigner tasks :

Here is what the configuration for the Assign Area Mgr. Dynamic Assigner task looks like

The Dynamic Assigner is expecting a column named "CONTACT_ID" to be returned in the dataset and will use this value to match the appropriate contacts against the Integrify users table. In this example, only one result will be returned by the Dynamic Assigner because there is only one Area Manager per location. In other situations, the Dynamic Assigner may find multiple Integrify users with its query and all of those users would be assigned to the task.

Comparing the Pros and Cons of Each Method

Recipient Rules

Pros:

Simple, straightforward configuration

Great for small recipient pools

Cons:

Can take time to update every rule

Does not scale well for larger recipient pools

Dynamic Assigner

Pros:

Scales great for larger recipient pools

Easy to update

Allows for lookup table

Cons:

Requires knowledge of SQL

The First Step in Automating Your Workflow

2007-10-16T19:20:00Z

Many processes we deal with through Integrify Professional Services and Support have been documented at some time in the past, usually with an instructional document and nice Visio diagram, but as time passes, the document(s) is not maintained to reflect changes to the process or organization, and if it was ever accurate to begin with, it is usually out of date. This is not unusual and is a natural by-product of process evolution and usage within an organization.

The first step in migrating from a manual process to an automated will require that you take a fresh look at your company’s process and create a formal process description. A basic workflow definition should contain the following three items at a minimum:

Written description - purpose/goal of the process and how it works
Flowchart – graphical representation of your process
Task recipients chart – who is doing what in your process

Creating the workflow definition will likely be a very illuminating experience. You will often find that while your work has been getting done, it might not have been accomplished in a way that you wanted it to! Developing a formal workflow definition is a huge first step toward identifying and fixing inefficiencies in your business process.

Now that hard and fast business rules have to be applied to the process, you will be able to immediately identify which tasks in your process are either not well defined and may be removed from your process entirely. You may also find places where the proper ownership of certain tasks is in question. It will require effort, collaboration with fellow co-workers, and a degree ownership on behalf of one or many people in your organization to work through these issues and define your process effectively.

Once you have a well defined workflow definition, it is time to implement the workflow in the Integrify system. Many customers elect to have Integrify create their first process or two so they may take advantage of our expertise and learn the system better during the initial collaborative effort.

To help you get started Integrify Profession Services and Support has created some of the following resources for you:

One Big Process (or three smaller processes)?

2007-10-16T12:34:00Z

We are often asked during the sales process and in subsequent implementations “Can Integrify handle a really big process?” The answer, of course, is “yes”. If you can dream it up, 99% of the time, Integrify can implement the process.

But, just because Integrify can handle a large process, it doesn’t necessarily mean that that a single, all encompassing process to handle everything in your organization is a good idea. More often than not, what occurs in these types of situations is that while something outwardly is seen as one massive process in reality it often is two or three (or more) distinct processes all rolled up into one end-to-end process.

So, if Integrify can handle it, why shouldn’t you do it? Here are some common pitfalls that often occur when building that huge process:

Overwhelmed users: the task history of a given process becomes so large user gets lost trying to figure what has occurred, what they need to do based on previous tasks that occurred, or what comes next.
Simultaneous Task Assignment: Like the first item above, if a user is assigned two tasks within a process. It can be confusing for that task recipient. Do they know which task to complete first? Is there an order of precedence they should follow?
Process Administration headaches: it can be difficult to maintain a huge process. Many times the transition condition logic and looping become so complex that one change inadvertently impacts the entire flow of the process.

So how do you handle this? The first thing you should do is evaluate the process and determine if there are two (or three or more) distinct streams of work in the process. For instance, take the following flow into consideration:

In this particular scenario, a user would submit the initial request (Initial Form Request) which in turn starts three additional, yet completely distinct tasks that are assigned to different individuals. Once those three tasks (Work Stream A, Work Stream B, Work Stream C) are complete, then the Approval task starts.

Where things begin to get tricky is when the approver rejects a task and needs to loop back from the Approval task to Work Stream A and Work Stream C but not Work Stream B. Since each task is independent of one another, it may make sense to also create separate approval task for each work stream:

While it may seem redundant adding the additional approval tasks in the process, it actually provides you with a more streamlined way of handling loop backs and varying conditions that can arise with loop backs in your transitions. Likewise, you will often find that those three distinct streams of work are often approved by different individuals and/or require additional task to execute after they are complete anyway.

Another common issue that is often encountered when a large process is built is inclusion or exclusions of tasks at different points in the process based on user interactions. Take the following example:

After the Initial Form Request task is submitted there are a series of OR conditions on the Transitions so only one of the following tasks (Work Stream A, Work Stream B, or Work Stream c) will execute. Once one of those tasks is executed, then the first Approval Task will start. After that Approval is complete, the Secondary Approval Task is started. At this point, the Secondary Approval task has the option to loop back to either Work Stream A, Work Stream B, or Work Stream C. All of this is fine until the user completes the task on the loop back from Secondary Approval. Here is what you can often run into:

Depending on the Transition conditions you have defined from Work Stream A, Work Stream B, or Work Stream C tasks to the first Approval task it may not start again. Suppose in those Transition conditions it states the Approval task will begin when any of the Work Stream tasks completes. The problem is, one of the Work Stream tasks already completed before the loop back.
You only want the Approval task to be fired the first time but not after the loop back from the Secondary Approval Task.

Like in the first example, it often is just a restructuring of the process. It may be best to have three Approval tasks rather than one. Or, rather than looping back to Work Stream tasks again, you can just add more form tasks:

While it may seem cumbersome when initially building your process, in the long run it will most likely save you time. Processes change over time and more complex rules are often added. This structure would be able to handle these changes.

Note: Integrify can handle looping back through multiple tasks and evaluating rules differently with each loop back. In the Advanced Settings for any task, there is an option called “Only triggering task state in start rules will evaluate to true”. This will instruct Integrify only to evaluate the rules based on the last iteration of the tasks that start it.

While we have focused on altering a process to simplify loop backs and conditions, one other alterative is to simply create multiple processes.

The first thing to do is evaluate that initial form in the process. Suppose it was an IT request and on that form it has options for the end user to request a new computer, request access to a server, and change an email account. While each of those requests may go through the same IT department, they may follow very different approval paths, one may require an invoice to be created, another may require a security review, etc. In this scenario, it would best to break that process into three distinct processes:

New Computer Request
Access Request
Email Account Request

In addition to the simplification of building those processes and avoiding some of the common pitfalls discussed above, the added benefit is the end user has very distinct processes to select from when they start a new request too.

Good luck!

Welcome!

2007-10-04T18:30:00Z

Welcome to the The View from Within blog!

In our day-to-day operational experiences we (Integrify Professional Services and Support) often find ourselves discussing many re-occurring themes amongst ourselves and our customers. Our intent here is to share those experiences we find interesting and which we hope you will find interesting too.

Topics will vary considerably from the 'How To' to best practices in implementing and working with Integrify. If there is something of interest you would like to us to discuss, please let use know.

Regards,

Erik Johnson
Integrify Professional Services and Support