In part 1 we looked at CRM Evolved, Pega’s vision for enterprise applications that focus on consistent, positive customer experiences and connecting customers with outcomes. In part 2 we started zooming in on the layers that comprise this vision, by taking a closer look at the BPM layer and code generation.
We will now look at the other layers, starting with the notion that code generation is not just essential for the BPM layer, it is the way in which Pega can integrate all layers seamlessly. Each layer introduces its own new concepts, but code generation makes sure that they integrate perfectly with the existing concepts.
The next layer on the slide is Case Management. When we looked at BPM, we saw the main attention going to processes, and we saw the Work Page as being pushed through the process. Now with Case Management, the focus has shifted from the process to the Work Page. But it no longer goes by that name. When creating the Case Management layer, Pega turned the concept of a Work Page into the concept of a Case. And here we see a nice example of what Pega means by “Build for change”. (Even though this is normally applied to applications built on Pega, we can see it at work on the Pega platform itself as well.) Since the executable code of applications is generated out of higher level chunks of functionality (see part 2), Pega was able to make the transition without breaking any code of existing applications. They introduced the functionality in a new version of the Pega platform, and anyone upgrading to that new version would see Work Pages turn into simple Cases. From there, it would be possible to either leave the application functionally the same, or extend the functionality by using the new Case Management features.
Case Management features
A Case represents much more than a work page. According to Alan Trefler in his PegaWorld 2015 keynote, “a case can be anything from a diabetic being treated through a personalized health action plan to someone who is sold a new set of credit instruments that might include a mortgage and a credit card, to a credit card dispute”. Therefore, a Case has much richer functionality.
In the first place there are easy ways to configure cases, subcases and their dependencies. In Trefler’s example, the main case would be the customer’s wish to have wider credit facilities, and one subcase would be the whole set of actions to set up a mortgage, and another subcase would represent a new credit card. These can have subcases themselves etc. The relationship between the main case and the subcases can also be configured, for example: what data is propagated from one to another, or: how does the status of the subcases influence the status of the main case.
Also new is a visualization of the whole life cycle of Cases, in terms of Stages.
Editing the whole life cycle of a Case in one diagram, with five Stages, and some Steps per Stage. Note the two Case icons in the fourth Stage, Reservation. These indicate that the Steps involve the creation of sub cases, which will each have a life cycle of their own.
Stages are the phases through which a Case can pass, and each stage consists of one or more Steps. Each Step then is defined using a process diagram, as we have seen in the BPM layer. Some steps involve the creation of a subcase, which is indicated by a “case” icon. Alternative stages, like Rejection and Cancellation, are also clearly visible. All this is a big improvement over the BPM-way of working, where we had to model the whole lifecycle in one top level process diagram, which would call sub processes.
If an end user clicks on the blue-to-white chevrons, on overview opens which shows the Case life cycle and the status of the Steps.
The visualization of stages is again a step to bring systems closer to the Business people. It helps Business and IT in DCO workshops (Direct Capture of Objectives, see part 2) during which they design a new system. When they configure stages directly in the system, it immediately becomes executable, with simple screens. The screens then can be configured during these workshops to capture what data is important in which stage.
Finally, an essential part is Dynamic Case Management, which is also yet another way to narrow the gap between Business and IT. It allows users to create ad-hoc Cases, for situations that were not foreseen during development of the system. In an ad-hoc Case, a user can add documents and tasks, and indicate what person, or what department, must fulfill those tasks. An ad-hoc case is mainly about gathering relevant documents and routing simple tasks to the right people. It does not involve connecting to other systems to retrieve data. But… ad-hoc cases for a situation that turns up frequently can serve as a blue print to build new, full-fledged Case handling functionality into the system.
We have seen a continuous progression in the possibilities for Business people to get directly involved in the actual creation of an application. The culmination of this was announced during PegaWorld in the form of Pega Express. It is a an intuitive environment with a subset of Pega capabilities, designed to make it easy to get started on the platform, without weeks of formal training. It allows anyone who is interested to start visualizing stages, processes and screens. The results of this can directly be incorporated into an actual application.
An important part of Case Management is, according to Pega, the customer context. A Case is not fulfilled in isolation, but against a large body of knowledge that an organization has about a customer. This helps to make sure that the right choices are made. And this leads us to the next part of the slide: Decisioning. When a customer gets in touch with an organization, or when an organization contacts a customer proactively, the aim is to perform an action that is most beneficial to both. In other words, to choose from a number of options, the Next Best Action (NBA). This requires a clever analysis of everything the organization knows about the customer, and that is where the Decisioning functionality comes in. It consists of rules for Strategies, data import, Predictive Models, Adaptive Models, Scorecards etc.
A Next Best Action Strategy
And here again we see how code generation has helped Pega to leverage the ease of change of their own platform: the integration of this Decisioning functionality. Decision rules were already known within Pega, and are an important part of the platform. They are used within decision shapes in process models, and in other system actions, and they are used to build up a whole web of logic. However, to extend this functionality, Pega found a company with a very advanced product for the analysis of large amounts of data. Pega was able to rebuild this product from scratch in its own platform, and provide the functionality in a familiar way: in Decision Shapes and Rules. And because of this, it is possible to integrate the complex Decisioning logic into process models.
A Flow diagram that integrates the Strategy shown above.
Silo’s and channels
Another important part of Case Management in Pega’s vision is the possibility to bridge the silos of an organization, and to provide a consistent interaction across all channels. Both are needed to present the organization with one face. As to the silo’s: these are essentially caused by gaps, or boundaries between the departments within an organization. Case Management builds on two aspects of the BPM layer of the platform to overcome this. First, there are powerful ways to route work to any possible workgroup or individual. And thanks to elaborate security configurations, it is possible to expose only relevant pieces of an application to a specific department. Second, to fetch any data from any department, the platform can generate code to connect to other systems over many protocols.
Bridging silos using Case Management.
The consistency over channels means that the customer gets the same possibilities and level of service through a phone call, a web page, or a mobile application. To this end, one Pega application can present screens for call center employees, and different screens for customer self-service. And the application can be configured such that screens adapt themselves to the size of the device, to have an optimal layout for PC, tablet or smartphone. In addition, these same screens can also be used to generate a native mobile app. For this pretty powerful feature, Pega has, just as with Decisioning, woven an advanced third-party product into its own platform.
These two ways of supporting mobile devices (self-adapting screens and generating mobile apps) represent the last part of the slide that we have been following throughout this journey.
It starts with an interaction between customer and organization which more and more takes place on a mobile device like tablet, smartphone or smartwatch.
Pega has incorporated strong technology that makes it very easy to generate Mobile apps.
Based on this interaction, and often during that interaction itself, the system determines what would be the best response, the Next Best Action. This is based on very powerful Decisioning technology: predictive analytics, which can be fed with big data and existing models, but which is also adaptive and self-learning.
This intelligent Decisioning greatly increases the chance that the customer responds positively to the offer. And then it becomes important that the organization can fulfill that offer in a fast and flawless manner. And this is where Case Management comes in, which builds upon years of experience in Business Process Management and Business Rule Engine technology.
And not only is the interaction between customers and organizations changing dramatically, it is also changing at an ever increasing speed. Therefore, the time between a great idea for new functionality and exposing it to customers must become shorter and shorter. To support this, the Pega platform has many features that bring Business and IT as closely together as possible.
So, Pega provides a lot of technology to help organizations excel in this one crucial concept: connecting customers to outcomes.
– Marc Hartogs