Process Pain Points: Pended Processes

Hi, I’m Sandy Kemsley of column2.com. I’m here for the Trisotech blog with a third in a series of videos on finding and dealing with process pain points. Although, this will be of interest to business analysts who are figuring out the Asis and 2B processes within our organization, I’ll also touch on implementation issues that will be of interest to my more technical listeners.

Now, in the first video I talked about finding where people are using spreadsheets and email as workarounds because this indicates that the existing systems aren’t doing everything that the business needs. In the second part I looked at handoffs, when you trace a business process from start to finish. You start to find the inefficiencies and errors that can happen when work is handed off between people and departments.

Now, I’m going to cover pending processes, in other words what happens when somebody is in the process of working on something and decides that they need to pend it for a later time. Maybe they’re not able to complete the task right at the moment, or they have to step away from their desk so this sounds deceptively simple but after decades in the trenches of process automation, I can assure you that improperly managed pended items are like the Bermuda Triangle for processes.

Now, I’m not talking about automated pens that are automatically released, such as a process that waits for an overnight batch to run before continuing then gets released first thing in the morning. This is about manual pens where someone who’s assigned an activity in a process just isn’t able to do it right then.

Now, there are a number of different reasons why someone needs to manually pen the process.

So first of all, the activity might be time consuming and the worker doesn’t have time to complete it before they leave for the day or step out of the office. In that case it’s a pretty simple hold situation it’s much like a file that you would put aside on your desk and then pick up first thing the following day.

Secondly they might not have the skills required to complete the activity that’s been assigned to them and they need to loop someone else in to help them. If the system that they’re using doesn’t allow them to reassign the work to someone else who does have the skills then they might need to pend it while they wait for the help that they need.

Thirdly, they might not have the information required to complete an activity, and they’re waiting for something to arrive, this could be from a colleague or a customer or a business partner and it could be a document or a phone call. So they’re just they have to set it aside wait for the information to come in and then they can pick up the activity again and complete it.

Now, pens can be handled in a couple of different ways. Sometimes the worker has a list of work assigned to them, in sort of an inbox, like you would have with email and they can just close the activity and it will stay there in their inbox and they’re going to leave it there in their own work queue until they decide to come back to it. Or you might have workers that are working through in more of an assembly line fashion or what we would call Push workflow. So they have to finish one item before they start on the next one. In that case if they’ve got something that they’re actively working on and they’re not able to finish it they have to send it somewhere in order to pend it because otherwise they won’t be able to move on to the next thing that’s in their that’s in their work queue. So either they need to assign it to another worker or they have to put it in a personal hold queue that then they will go back and get later or they put it in some sort of shared queue for items that require followup for anybody possibly on their team.

Now, what we can find is that once items get pended they can have a number of problems with them and in general these fall into two different categories.

First of all, how is the process located and unpend? In other words how does it get released and show back up in somebody’s work queue so that they that they work on it again so there could be a timeout that makes it just pop back into somebody’s queue. The worker might have to search for the process manually and then release it back to their work queue, and if so they have to know when to search at a specific time in order to do that. There might be reminders that are sent to the worker or to someone else to go and search for the item for example, there could be some other information that arrives asynchronously and then that automatically rendez-vous together with the process and causes it to be released back to their workflow, or to their work queue. So there’s a number of different ways that the process might be located and then unpend as part of the natural part of how the work get processed.

Now, the second thing we need to consider, is what happens when that doesn’t happen. What happens if no one searches for and releases a process that’s been pended, or nothing rendez-vous with it, maybe the original worker went on vacation or they quit their job or they just forgot about it, or the item that was supposed to come in and match with it never came in. So is the work automatically released back to them after a certain period of time, so in other words is there a condition but then it times out, maybe somebody who’s supposed to be handling escalations or a manager needs to review the contents of everybody’s pend queues on a regular basis, and again we have the issue what happens if they forget to do that, or do the items just sit there forever or wait until the irate customer calls in to say: “what happened to my transaction?” and then somebody goes searching for it. So, a lot of companies have tried to solve the pen problems by just stating that all work is one and done, there’s no pens you just have to finish the work when you have it in front of you but that’s not always a feasible alternative, as I mentioned the reasons why we could be pending might have to do with information that’s missing or skills that are missing. So there’s always going to be a scenario when somebody can’t finish a task. And if you don’t let them pend it, they’ll find a way! I’ve seen situations where pens were not permitted, but you could send the item to your manager. Now, that policy really quickly changed, because all of a sudden, the managers had like a million things in their workbox that really had nothing to do with them and didn’t require their attention. But the workers just had to get the things off of their plate, so that they could move on to the next item, and that was the only way that they had of moving them on to the next item.

So given that you can’t avoid pens in all scenarios, you need to properly address how and when pended items are are released. Now, the best way to start is to build these pens into your process models and then look at how they impact your process performance depending on how they’re handled. If there’s timeouts can you do a simulation on this or can you use some process mining data and look at what actually occurs, and say what happens if they sit there for 24 hours or when should they be released back to the to the workers. So if you do have some historical data, you can see how long items have normally sit in in pen queues then that’s really helpful for helping those edge cases that might get managed by pens.

Now, if you’re pending for some sort of asynchronous event that’s external to the process, like some missing information or documentation has to come in, might be something internal to your organization or it could be outside with the customer, the best possible solution is to automatically rendez-vous the inbound item with the pended item, so then that rendez-vous is going to release the item back into the work queue and then it’ll pop up for somebody to complete. So this works really well when the item is pended because it’s missing a document from a a customer and then the inbound document is can be matched up to to the pendent item based on a customer number or a transaction number. You see this a lot with onboarding situations where you have to wait for the customer to to upload some proof of ID or some financial information or other documentation.

Now, if you can’t match and rendez-vous automatically, somebody needs to be alerted if an inbound event might match with a pended item, and then search for that item and then release it manually. So you might have an admin who does this with all of the inbound correspondents so they might take every piece of inbound correspondence see where it belongs look through everyone’s pended items and then match up the ones that they think should be matched up and released back to the work queues, or maybe a worker gets a notification that they have inbound correspondence and then they have to search for it. So in either case the item is manually released back to the work queue and more critically it’s not released if nobody searches for it, so that can become a bit of a problem.

Now, you can always have the situation where I mentioned this previously, where items are pended for a period of time, that could be because your process management system doesn’t know how to do a synchronous rendez-vous, and this is the best it can do, or maybe it’s legitimately a timed pen like waiting for an overnight process, or it’s a reminder to call the customer back on a specific date and time to get some information. So when the timer expires, the item is going to come back into the work queue. You probably also need to give the worker the opportunity to go in and find the item that’s sitting there waiting for a timer and say: “release it now, because the customer called me and I need to get access to that item right now, and work on it”. Wo you have to look at all these scenario something is in a timer state, something is just in a pending queue, something is in an exception queue of some sort.

Now, finally you have the case where you’re just relying on workers to remember to review their pen queue on a regular basis and then release items back that are ready to work on. So if you’re allowing this model for pens, you have to be absolutely sure that more than one person is able to access everyone’s pen queues, and that escalation notifications are being sent to multiple people, as the pen time increases. Otherwise, if someone is unable to check their pens or they leave their job unexpectedly, there’s your bur Bermuda Triangle of processes.

Now, I’m going to wrap up this series next time with an episode on how escalations are handled.

That’s all for today. You can find more of my writing and videos on the Trisotech blog or on my own blog at column2.com. See you next time.