Date System Limitations in Ideagen Quality Management – suggested improvement. | Ideagen Success Cloud
Skip to main content
There's more discussions to explore simply by registering for Ideagen Community. Join us and start speaking with your peers today!

Recently we requested for Ideagen to develop the way the due date system works to improve functionality and save on time wastage within the business.

The current workload functionality is set at the template stage and is purely based on the raised date. This is great in theory, but in the real world, it leads to a lack of efficiency & requires considerable manual intervention with the need for micro-managing all the due dates of stages & actions within the system.

As an FYI some of our Q-Pulse processes have 15 or more stages with multiple tasks within each stage.

Scenario - We have a process that involves three sequential stages, the current methodology has defined dates as follows:

The first stage due date is preset 7 days from the raised date, the second stage due date is preset 12 days from the raised date, and the third stage due date is 16 days from the raised date.

In theory, the task will be completed in 16 days and no dates will ever be changed.

However, what if the first stage was completed within 2 days?
The due dates for the remaining stages would not change so instead of maximising the efficiency and taking advantage of the potential 5-day bonus the dates would remain unchanged unless there was manual intervention to update all the due dates for the following actions and stages.

Conversely, if the first stage was delayed and took 14 days to complete then the original due dates on the second & third stages (along with all the associated actions) become void as although overdue, none of the tasks can be actioned.
Considerable manual intervention and micro-managing will be required to update due dates to maintain accurate workload functionality for staff members.

Suggested Solution

We have asked Ideagen if they could introduce an option for a “Relative Due Date” function to remove the need for this manual intervention.

The theory is simple:
Instead of having a fixed Due Date based on the raised date, the “Relative Due Date” is instead relative to the date that the stage becomes active.

 

The advantages of this methodology are plenty and the efficiencies this will provide are numerous:

 

Instead of micromanaging due dates, using relative due dates for actions will enable an accurate actionable workload without any manual intervention.

 

Efficiencies will become automatic. If a stage can be started early then the system will automatically allocate valid due dates and workloads will reflect this.

 

Conversely, if a stage is delayed (which in the real world often happens) then the template due dates on future stages will not require manual intervention.

This functionality already exists “under the hood” as the previous stage completed date is already a variable within the system. This date could be used as the basis for the Relevant Due Date.

 

I recently spoke to another company that suffers from the same problem, they would use this “Relevant Due Date” functionality throughout their system. Please feel free to comment if you would support the implementation of what seems to be a much-needed improvement.

100% agree. it should be easy to say that e.g. stage 2 should be given a target date of +2 weeks after stage 1 closed date.

 

i would also add to this, that any stage should not appear on the stage owner’s workload until it is actually available to be closed. there is complete confusion amongst our users as to what they actually have to do in the CAPA module as their workload is full of stages and actions that they cannot close yet, because the previous parts of the workflow have not been completed. it should only appear on their workload once it is an “active” stage i,e, with a green arrow.


I think it is great idea and we would like to have it implemented


Reply