The Problem / Pattern.
I’ve seen a common pattern emerge across several of the client applications that I’ve had the pleasure to work with, and that pattern is a desire to implement greater flexibility within the process than is currently implemented. The issue wasn’t that the application was necessarily designed incorrectly, and may have been delivered exactly as the requirements and business asked for, completely approved and signed off on with great celebration. Instead, it seems that as the comfort level of the business unit leaders of the Pega technology & the users using it increased over time, and the end users themselves become more comfortable working within the application, there was a greater desire to have a less rigid, and more flexible goal-driven process putting some of the control back in the hands of the knowledge worker.
I’ve identified 4 major factors leading to this desire:
- Original Requirements took a very linear approach to the process to simply standardize every step, decision point, and detail of the process. The need for a flexible processes left up to the knowledge worker themselves was not even been considered at this time. It was do it this way, one piece at a time.
- Information can change. Especially in long-running case work, new or updated information may need to be added to the case at any point in time, which may affect overall end-to-end process.
- As the knowledge worker matures, both in application use and business expertise, business leaders have a stronger desire to let them work most efficiently and make smart cognitive decisions on their own when desirable. They are after all, knowledge workers, not robots.
- Mistakes happen. What do you do in a strict linear processes when 3 steps later the user realized they made a mistake earlier in the process, if you haven’t designed for these scenarios ?
In the case of original requirements taking a very linear approach to the process, many times the real driving motivator for that wasn’t that the process itself could literally only be done one way, it was fear of variance of quality and/or lack of confidence in the end users to do the right thing at the right time, every time.
In the case of changing information, the longer end-to-end processing time of a single unit of work, the more likely that information could have changed, new information been found, or some other external factor could come up that may play a role in what to do with that unit of work next.
As far as the knowledge worker is concerned, initial fears of poor quality can often be mitigated by good training, early exposure to the application, good quality control reporting, and smart functionality built within the process to perform validations where needed so the user can be corrected, if needed. And, when mistakes are made, the user simply needs a way to easily correct their mistake on their own, so that they can continue with their work, without the need for IT or support involvement (and that can be time consuming!).
The Process.
While each of these applications were had very complex end-to-end processes, and while it’s true major parts of these processes did need to occur in a specific order, at any one segment of that process many or all of the sub-processes/tasks could ultimately be performed in almost any order and be considered valid.
One example being a Fraud Investigation application for financial institutions. The key parts of the processes may be:
- Alert / Awareness of potentially fraudulent activity
- Location / Aggregation of similar Alerts and/or current or previous Investigations
- Triage / Decide to Continue or Not
- Investigation
- Research Parties (suspects, victims, other)
- Enrich with Data (transactions, accounts, etc…)
- Contact Necessary Parties for Additional Information
- Potential Law Enforcement Involvement
- Evaluate Risk to Bank Assets
- Determine patterns of behavior
- Determine compliance to regulations / bank rules
- Verify follow-up tasks to be taken
- and more!
- Disposition Investigation (Is this or is this not fraud?)
- Multiple Levels of Approvals, Rejections, or Requests More Info
- Review / Approve Investigation
- Review / Approve Disposition
- Review / Approve Info to be sent to Government
- Submission to Governmental agencies
- Follow Up Activities
- Close Accounts
- Follow up with Law Enforcement
- Contact Customer via Mail if necessary
- Financial settlement with customer and/or other banking institutions
- and more!
The application really had two key units of work, Alerts and their related effort which mimicked steps 1-5 above, and full blown Cases and related effort which copied steps 4 & 5, and added steps 6-8. Cases implemented Pega’s cover functionality to group one or more alerts, and were the bulk of the knowledge work.
While the end-to-end process does need to occur in a particular fashion, there’s no valid reason some of the sub-tasks couldn’t be done in any order the real-time scenario/information at hand calls for. If you control every step of the process in a minute and rigid manner, users are prevented from dealing with exceptions that require flexibility and as a result start to second guess when to move on to the next small tasks for fear of finding new information for an earlier step at a later point in time. Anytime a user must alter their behavior to use the application, the process is broken.
In this particular example, under the rigid process, business users determined a work around of completing the entire investigation and working with management to reject the submission so that it could come back to the investigator and restart, where new information could be added, or information from an earlier part of the process could be corrected. Ideally, that flexibility should be built into the tool, without users needing to work together to form work-around solutions.
The Solution.
There are ways to add this flexibility with the same standard flows used in the rigid, linear approach – however – keeping in mind ease of use, easy access to both retrieve/update data, and a pleasing UI, we decided there was probably a better approach.
The design solution to implement this new flexibility into a still very large, complex process was to leverage Screen Flows within Pega. Screen Flows come with simple back/forward wizard like capability right OOB – BUT they do have some limitations that must be designed around. There a few UI patterns than can be used when implementing Screen Flows, my personal recommendation being Tree Navigation. Tree Navigation allows for an easy to use collapsible tree to be displayed on the left hand side of the UI, that is easily clickable by the end user to jump around to different screens (tasks) of data which become nodes in the tree. The use of screen flows allowed us to design process flows so that the assignments and sub-flows within them could be turned into nodes within the tree dynamically at runtime.
Now, there is still a need to control the entire end-to-end process, and we only want to limit the flexible portions to User actions, within each major part of the process. This was accomplished by using standard flows to “control” the entire process, end-to-end. These standard flows took care of when to move to the next step in the process, at what point & where to go to if the need arose to go back to an earlier point in the process (leveraging tickets), and essentially created the controlling process framework, if you will, for the application. The sub-processes, and all UI components were built into specialized screen flows for each part of the process. The appropriate screen flows were then referenced in the appropriate place in the controlling process framework.
At each sub-process, the nodes in the tree essentially comprised of two different types of nodes:
- Supporting Data Nodes that could be accesses to be viewed or updated with a single click
- Process Nodes that would finish the resolution of this step, exit the sub-process and hand control back to the process framework
The Supporting Data Nodes were mostly made available to every sub-process along the entire end-to-end path with a few exceptions. Nodes within the tree were grouped, and sometimes nested in a parent-child manner to provide logically grouped sets of data where needed that could be expanded/collapsed at will.
The Process Nodes contained the actual goal task(s) for the overall step in the process, and were upgraded to included both manual checkbox validation that certain sub-tasks were completed by the knowledge worker as well as system performed validation. Both the user validation and system validation were required to pass before passing control back to the process framework.
The redesign/development effort was split into two phases within logical divisions of the application. The first phase comprising the first 5-6 weeks of the effort, and the second phase comprising of the last 9-10 weeks, and the bulk of the effort.
Design Considerations.
Screen flows have some limitations that need to be designed around. In addition, some additional design considerations were made to correctly handle re-use, and all other best practice design guidelines, all while staying within Pegasystems guardrails.
These were:
- No SLA Support from Screen Flows, but need for SLAs was critical
- No Workbasket to Operator Support within Screen Flows
- Screen Flows have limited flow shapes available for use, and essentially require a fairly linear flow design at development time
- Showing/Hiding Nodes Conditionally (e.g. certain users are not allowed to see certain data)
- How to develop common sets of nodes once and reuse across the specialized subprocesses
- Dynamic data-driven creation of nodes (e.g. adding a node for each suspect we had information on)
- Dynamic tree node label generation at runtime (e.g. adding a # on the label to show how many suspects are present)
- How to direct which node to go to next if you submitted data on one node and immediately wanted to be taken to another, non-sequential node.
- Ability to have the first default node be a node other than the first node in the tree, upon entry to the screen flow
- How to handle already in-flight work, bringing them into the new process and into the correct spot of the process
Each of these considerations were designed around following Pegasystems guardrails, and worked beautifully in a reusable, maintainable fashion using OOB functionality.
The Result:
The existing application was completely redesigned & delivered to production with the above solution in the span of 14 weeks with an initial small team of 3 dedicated technical resources, and 1 business analyst resource. This included all analysis, design, development, and testing. In order to accomplish testing so many changes in such a small time, code pushes were made to the testing environment almost daily and a very carefully planned strategy to re-use the same ruleset version was leveraged and managed very closely during this effort.
This design approach resulted in much greater flexibility for the knowledge worker to perform sub-tasks at the optimal time based on real-time data, and eliminated the inability of rigid process flows to handle unpredictability. In essence, this was goal driven processing by the knowledge worker rather than strict process management. The end-to-end process was not disturbed, but was enhanced and made more powerful and able to handle real world scenarios that cannot be predicted ahead of time.
In addition to injecting flexibility, greater access to data, and ease of use for end users, a backlog of 30+ change requests were folded into the work effort as well. Specialized tools were created and executes as part of the release effort to capture current in-flight work, perform necessary cleanup and inject them into the new processes at the exact appropriate location.
Business Unit leaders were thrilled with the quick turnaround, the new ease of use, and the addition of the 30 backlogged CR items, that had been accumulating since the initial release. End users and managers no longer needed to step through convoluted work around procedures to handle the need to correct an earlier step of the process, and the data was now literally at the fingertips of the knowledge worker, a tree node click away.
An added bonus of the new design meant greater ease of maintenance for future flow processing modifications, as the risk of a modification resulting in flow errors was diminished due to all user assignment being withun screen flows.
Critical Success Factors:
Several key factors played into the success of this aggressive effort, which was very large in terms of changes to the application and sheer amount of rules to be modified/created.
- Business Unit leaders were made available for quick access during entire effort to Business Analyst and Pega System Architects
- Experienced, skilled resources were tasked, left alone, and allowed to do the things they needed to do
- Loss of a critical resource after the 10th week was quickly backfilled with 4 additional resources
- Daily collaboration between QC testing team and delivery team
- Experienced testers who were already familiar with the business functionality of the application
- Design used OOB mechanisms that stayed within product guardrails
Takeaway:
It’s important to discuss this pattern and need for goal-driven flexibility within the process upfront with your business clients. Do not let fear pigeonhole your team into only delivering a very rigid linear process that cannot predict real-time scenarios and react appropriately. The value of flexible goal-driven processes will be apparent to your business clients when you start discussing exceptions and how to handle unpredictable data and do not let yourselves only focus on the big picture process.
If you’d like to hear more about either the solution details that handled the various design considerations, or how a similar approach could be implemented for your application, please contact me and I’d be happy to have that conversation.
BPM with Integrity 