In our software, we have a task list where “requests” go. They can be created by our users, or online by their customers. We have 2 boxes where these go: “Requests” and “Requests With Queries“. As far as I understand, the Requests are often safe to approve because it’s basically just a repeat order and added by the staff member so has already had one official approval on it. When there is some uncertainty, they go into the “With Queries” box for more scrutinisation. The requests coming from online always go into “With Queries” and require more scrutinisation.
The time it took to click approve and then load up the next task was quite slow. We added a Bulk Approval feature where the user can view tasks quickly, then approve several at once which means they don’t have to go through the load/send/load/send/load/send workflow. It’s more like load/load/load; and the sending can be done in a background process.
For Requests, this bulk feature worked fine because they can be quickly reviewed, then sent. For ‘With Queries’, it made sense that our users would want to bulk review the user-created ones, but the customer-created ones would require further time to review. So we decided to create a new box where the customer-created ones go.
This was requested by some of our users, and it made sense to us. However, we didn’t ask all our users if it was appropriate for them.
So when it went out, many users complained that we had “doubled their work“.
The comments from our users often seemed strange, but many seemed to be saying they had a Receptionist that went through all the tasks and reassigned the task owner to different staff members so they all had an even amount of tasks. Then each user would check their tasks and approve them. They referred to this as “regulated distribution”. We were baffled why having the same number of tasks as before but just located in 2 boxes rather than one would be a problem.
One user said this:
“unfortunately we don’t work like that. The requests have to be counted – so many queries and so many straightforward. They are allocated daily and completed but have to be collected and centralised first.. Nightmare for us.”
Another user said this:
We cannot work out now within this new box which are queries and which are not so we are having to open every single one ( 500 today) in order to sort them out.
But before, all these tasks would appear in the Requests With Queries box because they were all customer-created. Now in the Requests With Queries box, they should be able to review these faster because each one would require the same level of scrutiny, whereas before, they would have to keep looking at the “source” to see if it was from a user or customer to decide what level of checking it required.
I think it must be the case of just being shocked when something changes and reluctant to adapt.
During development, we also debated what the Review Date really meant. If it was set, then we check if the date has passed and don’t allow these to be bulk approved. However, customers can have no Review Date at all which we interpreted to mean it wasn’t applicable to them, so we allowed all their tasks to be bulk approved. However, one particular organisation thought this was very unsafe for them. They wrote an interesting write-up, full of capitalised letters and very much geared to a Hazard Matrix:
This issue has been discussed at the Joint IT Committee, who are expecting feedback in due course.
The Committee's concern is that there is a HAZARD that items may be issued through Bulk Approvals that have not been appropriately reviewed. The CAUSE of concern is that the Bulk Approvals module includes orders for customers who have no items Review date. Where an organisation's business operations involve using items Review date to govern their ordering, the EFFECT may be that a customer whose items has not been appropriately reviewed may have bulk approved orders (potentially repeatedly). The HARM to the customer may be any of the wide range of harms that can come about through unreviewed access to order items including death. Therefore a LIKELIHOOD needs to be calculated (you are best placed to do so as you can audit your records to identify how many customers have had repeat orders issued through Bulk Approvals, describe any case reports you have had of customers who have been harmed (and near-misses), and estimate the future risk by identifying how many customers have repeatable orders and no review date.
I believe that on your hazard matrix, the CONSEQUENCES therefore could plausibly result in death = CATASTROPHIC
The LIKELIHOOD I would appreciate your guidance on, but I wonder if it might be UNLIKELY i.e. likely to occur some time (the longer it is running the higher the chance), or if you have other CONTROLs I'm not aware of, possibly EXCEPTIONAL i.e. unlikely, but may occur exceptionally, which would give the HAZARD a rating of HIGH or MEDIUM.
The Committee would therefore be grateful for more detailed feedback on the HAZARD so that we can respond to our Members. This might be the relevant row from your Hazard Log for example, but a narrative description would be fine.
The suggested REACTIVE CONTROL is to consider excluding those customers from Bulk Approvals which would ELIMINATE this cause. There are alternative controls but none that would eliminate the cause entirely that we are aware of. In any interim, a organisation could mitigate this risk until any change in module behaviour if they audited their customer records to identify customers who have current active repeat orders but no review date.
Stranger Coding Tings 