• Check overall effort, utilization, First Time Right  against the scope and intent document to ensure that the FTE required reflects management view of reality

• Consider wait times as the delay between individual activities pairs. If there are multiple incoming arrows, consider which of the preceding activities requires waiting, rather than apply the same wait period for all predecessor activities.

• 1.Incorrect calculation of critical path as all paths containing the waiting activity will contain the same wait period .

• 2.Incorrect computation of bottlenecks, hand-off delays, cycle time and therefore Peak Utilization

• 1.Check critical path(s) to see if they contain the same delay as other paths

• When using TOD, BOD or EOD as wait period , be aware that these timings apply to the work times of the successor activity (the activity to which the delay is added).  The actual delay may therefore change according to the relevant actor’s work times.

• 1.Error message stating that the relevant actor is not available at the TOD applied, or that the team count needs to increase because of TOD, EOD or BOD activities

• Particularly check if TOD is applied to activity timers, to ensure that the work time of the correct actor is factored in.

• 2.Check cycle time and the Peak Utilization against the scope and intent document and if see if the difference is because of wrong wait periods.

• 1.Inspect where TOD, EOD or BOD are used as wait period  and edit the values of these (TOD) to match the actor work times.

• 2.Consider using POST instead of TOD, BOD or EOD to capture delays as POST does not have inherent adjustments for work times. Of course, if the actor is not available at the end of the POST wait time, the successor activity will wait until the actor becomes available the next day.

• Keep in mind that TOD, BOD or EOD act as semi deadlines and try and force preceding activities to complete in time to meet these deadlines. This may increase the FTE required artificially to meet these deadlines.

• Incorrect (over-estimated) Peak Utilization, FTE required

• 1.Warning that team count needs to increase because of TOD, EOD or BOD activities

• 2.Peak Utilization is higher than management expectation in scope & intent document

• Consider using POST instead of TOD, BOD or EOD to capture wait period  as POST does not have inherent deadline but delays the successor activity, rather than increase FTE required.

• Use INST delays sparingly to avoid artificial peaks or delays in ensuring both teams are available simultaneously perform this pair of activities.

• Incorrect (over-estimated) Peak Utilization, FTE required

• 1.Warning that either team is not available at common time for INST activities

• 2.Peak Utilization is higher than management expectation in scope & intent document

• Avoid multiple deadlines on a single path; rather stay with the last, or the most difficult deadline
  •Keep in mind that TOD, BOD or EOD act as semi deadlines and try and force preceding activities to complete in time to meet these deadlines. This may increase the FTE required artificially to meet these deadlines.

• 1.Warning of multiple deadlines on the same path
  2.Peak Utilization is higher than management expectation in scope & intent document

1. Forces artificial Peak Utilization as try to complete before artificial deadlines

• Check deadlines to ensure the minimum deadline is set to sum of AHT for preceding activities on deadline paths , plus sum of preceding wait period  on deadline paths .  Ideally adjust deadline so that the deadline is set to effort of preceding activities on deadline paths plus sum of preceding wait period

• Consider wait times as the delay between individual activities pairs.  If there are multiple incoming arrows, consider which of the preceding activities requires waiting, rather than apply the same wait period for all predecessor activities.

• Incorrect calculation of critical path as all paths containing the waiting activity will contain the same wait period .

• Check cycle time against the scope and intent document and if see if the difference is because of batch delays

• Scan the process map in advance and note which activities are batch processing, if any. Review the serial and batch values in the validation screen and determine if these are correct.

• ANY predecessor removes any inherent delay in waiting for all preceding paths to be completed, while ALL predecessors means the activity is delayed until all preceding paths are completed, increasing the critical path and influencing bottlenecks and hands-off delays.

• Check cycle time against the scope and intent document and if see if the difference is because of ANY/ALL predecessors.

• Scan the process map in advance and note which activities have multiple incoming arrows. Determine whether this activity needs to wait for all the arrows before it starts (usually when the arrows are from a branch) or if it can proceed with any arrow being complete (typically from a decision). Review the ANY and ALL values in the validation screen and determine if these are correct.

• Process map should not have significantly less than 50 activities

• High AHT (>30% per item) may result in higher than true bottlenecks .

• Use the merge activity functionality to merge activities where AHT < 30 seconds, or activity effort < 2 hours

• Incorrect computation of bottlenecks hand-off delays .

• Inspect effort  of activities that are on the peak or that are causing bottlenecks.  Check if the effort is overly high because of AHT.

• Incorrect computation of bottlenecks hand-off delays

Check wait periods for process map with multiple incoming arrows and apply the correct wait period between each pair

• Ensure that you have factored in batch or serial processing when considering critical path and if you have factored in all predecessors, or any predecessor

• •Draw all teams associated with the operation whether in or out of scope.

• Might miss out on how upstream or out of scope team impact on in-scope and downstream teams

• Inspect process prior to upload. Trace the transaction through the process to identify where decisions are taken and add these decision shapes.

• Erroneous scheduling and false delays , leading to increased  cycle time  because of artificial “non-availability”

• Enter the total time that resources are in office for the Geolocate Teams input

• Incorrect delays and cycle time because of artificial false “non-availability” of resources

• Provide the total number of employees per team (for which salaries are being paid) rather than adjust for shrinkage, buffers or other considerations

• Check that that TOD, BOD or EOD are correct given model and work times of the successor activity
  TOD, BOD or EOD act as semi deadlines and may increase the Peak artificially

• Check the volume and the AHT for each high effort activities to ensure correctness. 

• •Confirm the effort for each activity, particularly where effort >= 8 hours

• 1.Incorrect Peak Utilization , cycle time, FTE required and Total Cost

• •For work hours, enter the time a person is present in the office, not adjusted for breaks or other shrinkage

• •For team size, enter the total number of employees per in-scope team doing the tasks in the process map (including ‘buffer’), not just the calculated FTE

• Check that that TOD, BOD or EOD are correct given model and work times of the successor activity

• •TOD, BOD or EOD act as semi deadlines and may increase the Peak artificially

• •Avoid multiple deadlines on a single path; rather stay with the last, or the most difficult deadlines

• Ensure sufficient time provided for previous activities and wait periods when entering a deadlines

• Incorrect computation of Peak Utilization .

1. Check Peak Utilization against the scope and intent document and if see if the difference is because of wrong wait periods.

1. Warning of multiple deadlines on the same path
2. Peak Utilization is higher than management expectation in scope & intent document

1. Warning of multiple deadlines on the same path
2. Peak Utilization is higher than management expectation in scope & intent document

• .Inspect where TOD, EOD or BOD are used as wait period  and edit the values of these (TOD) to match the actor work times. Consider using POST instead of TOD, BOD or EOD

• .Check deadlines and rationalize the deadlines entered along the path to capture the deadlines relevant to the objectives per the  scope & intent document
• 1.Ideally adjust deadline so that the deadline is set to effort of preceding activities on deadlines paths plus sum of preceding wait period

• Check overall utilization against the scope and intent document to ensure that the FTE required reflects management view of reality
  •Check the impact that First Time Right has on the cycle time, particularly when there are wait periods within the rework loop
  •Check what is causing the Peak Utilization
  •High effort activities on the peak
  •Relative shift timings causing work to bunch
  •Prior activity delays or wait times causing work to bunch
  • deadlines causing work to be completed faster than effort available

• *STAR TIP*:  Create a test scenario without deadlines and delays to see the peak utilization.  Introduce the deadlines and delays one by one to check the impact and identify which is causing the peak and why.
• In case of any continued doubts on utilization, contact support@insorce.com  to understand any edge case that causes spikes in peak.  For example, there may be edge cases that include (but  are not limited to)

• •Check overall utilization against the scope and intent document to ensure that the FTE required reflects management view of reality
  •Check the impact that First Time Right has on the cycle time, particularly when there are wait periods within the rework loop
  •Check what is causing the FTE required
  •High effort activities
  •Activities on the peak
  •Relative shift timings causing work to bunch
  •Prior activity delays or wait times causing work to bunch
  • Deadlines causing work to be completed faster than effort available
  Check what is the impact on cycle time by increasing team size for activities that are bottlenecks . Understand the trade-off between cycle time and FTE required

• False peaks due to bottlenecks caused by system or out of scope teams

• Incorrect impact of model vs team time zones and need to adjust work time by ± 24 hours when team worktime start at midnight

• Incorrect relative team sizes or inadvertently running when clicking reset team size

• Process map has significantly more than 80 activities
   

1. .Periodically use the merge activity functionality in the product to merge process map
2. a.Check post entering AHT for activities AHT; 30 seconds, activities effort; 1 hours

1. Difficulty in filling system related systems , Forms mode business rules .
2. .Incorrect automation assessment and missing automation potential

1. .Check systems names after entering to ensure the entered names are correct

• Process map has significantly more than 80 activities

• 1.Periodically use the merge activity functionality in the product to merge activities
  a.Check post entering AHT for activities AHT < 30 seconds, activities effort < 1 hours

1. .Inability to associate Formsthat are transmitted via workflow with the activities

• Extra effort and errors in filling up modes and Business Rules

1. Entering Formsthat are synonyms of other Formswill throw a warning in the add  Formsscreen.
2. Same  Business Rules for multiple Forms
3. Many Forms associated with each activity

1. .Make a list of Formsprior to uploading, check for duplicates a) .Check if any Formsare duplicates of each other,

1. Check spellings of Formsbefore upload or data entry

• Use the synonyms functionality in  add Forms

• When activities have multiple Forms, the least automation friendly mode is considered for potential automation

1. Check the Modes & Systems table in automation validation
2. Error in classification of automation type

1. .Check automation potential by automation type.  Verify if there are any inconsistencies because of modes:
2. Example: Mode is workflow instead of image resulting in high RPA potential rather than digitization

• •Process map has significantly more than 80 activities

   

Incorrect relative team sizes or inadvertently running when clicking reset team size

• 1.Inability to associate rules that are carried on the Forms used by the activities

• Error message stating that it is there are activities with no Forms associated with them

• 1.Check Formsnames after entering to ensure the entered names are correct

• Extra effort and errors in filling up Business Rules

• 1.Entering business rules that are synonyms of other business rules will throw a warning in the add  rules screen.

• 2.Similar  business rules for multiple Forms

• 3.Many fact-based business rules associated with each activity

• 1.Check the automation validation.  If mismatch between automation type and expectation, check competency.

• 2.Check salary vs skill graph to see if team complexity seems correct.

• Draw all teams associated with the operation whether in or out of scope

• Inspect process prior to upload.

1. No ‘undesired’ outcome in the process map and no loop warning
2. Possible misrepresentation of First Time Right if rework and reject steps not captured

• Business Rules are consistent for the decision and upstream activities, i.e., is there incorrect or missing information

• Are the rules human judgment and could the person doing the decision have arrived at a different conclusion

• Does the decision-making team have competency for the rules; or is the error upstream leading to reject / rework?

• •Are the systems the same, or could there have been an inter-system error

• •Process map should not have significantly less than 50 activities

   

• Inspect process prior to upload

• Effort levers may be missed due to non-materiality [Automation, NVA, FTR]

• Incorrect automation assessment and missing automation potential

• Wrong opportunity size for automation

• 1.Check if model utilization is significantly different from the estimate in scope and intent document,

• •Check activities that are causing Peak Utilization

• •Define control objective as the purpose(s), aim(s) or end-goal(s) of the controls in a process
  •Multiple controls map into a single control objective.

1. Request management to spend time in the scope and intent document to articulate control objectives
2. May be worthwhile to speak to the internal audit or risk management function to arrive at control objectives by domain
3. When mapping controls,
   a.most controls have single control objective: check if control objectives are too granular
   b.Most controls map on to multiple control objectives: check if control objectives are too abstracted
   3.The number of lines of defense are significantly different from 3. 

1. .List the control objectives before entering. Most operations will have between 4-8 control objectives
2. If < 4 objectives, you may have
   
3. Missed out some objectives.  Check whether the objectives cover the entire scope of the Process Map .
4. b.Represented the objectives at a very abstracted level. Check if each control objective covers a single product.
   If > 8 objectives, you may have
   a.Duplicated some objectives.  Check if there are duplicate objectives for each  part of the Process Map .
   b.Represented the objectives at a very granular level. Check if each control objective tends to have a single control.

• Draw all teams associated with the operation whether in or out of scope 

• Inspect process prior to upload.

.Multiple Wrong opportunity size for automation associated with single activity

.Inability to separate control from risk

Inspect process prior to upload

Incorrect lines of defense and control effort

• Process Map has significantly more than 80 activities
   

• Inspect process prior to upload.

• Likely errors in mapping leading to incorrect non FTR ,   automation , potential, skill clusters, and control efficacy

1. .Make a list of rules prior to uploading, check for duplicates a.Check if any rules are duplicates of each other b.Check spellings of rules before upload or data entry

1. .Inability to solve for control efficacy leading to higher control rework
2. Possible need for lines of defense leading to higher effort
3. Poor control environment leading to control objective not being met leading to financial, reputation or regulatory losses

• Segregation of duty: Consider which teams can and should perform the controls to improve control efficacy

• *STAR TIP*:  Consider if the teams that should do the control know the Business Rules and competency to perform these.

• Control placement:  Inspect the control path and find the distance between the risk activities and the control activities.  Check if it helps to have a control point closer to the risk activity.

• *STAR TIP*:  See if there are multiple changes in Forms , Business Rules or systems . If yes, interim control is better.

• *STAR TIP*:  Consider the benefit of multiple smaller controls through the process over a single catch all control at the end

• Business Business Rules:  Consider skilling either the team performing the control or performing the risk activities, or both results

• *STAR TIP*:  See if the teams have the experience

• Draw all teams associated with the operation whether in or out of scope.
   

• Ensure the teams are captured in chronological starting with the trigger and then tracing the transaction flow to all the teams that touch it until it completes (desired, or undesired end)

1. 1.Multiple Wrong opportunity size for automation associated with single activity
2. 2.Inability to separate control from risk

• Inspect process prior to upload

1. Inspect process and data prior to upload a)Use the merge activity functionality in the product to merge activities where > 6 activities required to define one control

• Incorrect lines of defense and control effort

1. When mapping controls, a)most controls have single control objective: too granular b) .Most controls map on to multiple control objectives: too abstracted

1. Abstract or consolidate control objectives depending on the situation
2. Consider discussion the internal audit, quality or risk management function

1. No risk activities in control validation table
2. Incorrect lines of defense in validation

1. Poor control environment leading to control objective not being met
2. Incorrect assessment of lines of defense
3. Poor control environment if under leading to objectives not being met and redundant control effort  if over

1. .Inspect the lines of defense by looking at the control paths by objective in control validation.
2.  lines of defense = # path controls + 1

1. Check that all control in the path are applicable to the relevant risk type* by control objective . (If not applicable, see if risk type* or control type to change.)
2. .If over control , check which controls have high control effort and low control efficacy to assess which control to remove.
3. If under control, check which risk type* have fewer control ,  to assess which control to add.

• Draw all teams associated with the operation whether in or out of scope.

1. May not capture all non-First Time Rightmetrics and the effort associated with them

1. No ‘undesired’ outcome in the process map and no loop warning
2. .Possible misrepresentation of First Time Right if rework and reject steps not captured

• Inspect process prior to upload.

  1.Trace the transaction through the process to identify where decisions are taken and add these decision shapes.
  a.Rework is one arrow goes to a previous activity

• *STAR TIP*: Most controls have a decision that causes control rework , typically the mitigation part of the control.  If the control does not have rework, check activities first control does not a decision, look for adjacent activities that are decisions causing rework. 

• Incorrect assessment of opportunity to resolve leading to higher effort
• Incorrect assessment of training, work allocation or process change to improve control efficacy

• Ensure that total effort has been validated to make sure no errors in volume and AHT

• Check the volume and the AHT for each control activity to ensure correctness. 

1. .Incorrect impact analyses for all effort, Peak Utilization and cycle timelevers

• STAR TIP*: All controls have activities that Detect, Mitigate, Escalate and Prevent risks. Check that the activities associated with each control activities have these elements.

• lines of defense = # path controls + 1

1. .If control validation shows lines of defense as materially different from 3, reinspect control activities and mapping to objectives
2. Check that the controls include activities that include detection, mitigation, escalation and prevention of the risk
3. Inspect risk activities associated with the control objective and correct as required

1. .Incorrect impact analyses for all effort, Peak Utilization and cycle time levers

1. Check volume and AHT for each control activity and correct as required
2. Check lines of defense for each control objective and correct as required
3. Check activities in all control and correct as required

• Assess which controls have the highest effort and the least efficacy to rank controls

1. 1.Incorrect solution levers for effort, Peak Utilization , cycle time and control efficacy levers

1. .Check the effort vs efficacy graph in the over-controlled lever
2. Good controls have high efficacy and low control effort
3. For controls with high efficacy and high control effort, check what causes the effort.  Can volume be changed by sampling?  Can AHT be impacted through NVA or automation?