There are two perspectives:
This blog is about the first perspective.
A case management application (or case system) often has a process as its main thread. Such a process has both size and dynamics. The size (how many steps, data, and documents) is typically not a challenge in our field, but the level of dynamics can be. A process can be fully static (always the same order for everyone to reach the goal), or highly dynamic (everyone has different requirements and preferences).
There are roughly four types of processes, all of which can be supported by Blueriq. They range from using very little to a lot of knowledge and rules. This is not a ranking from bad to good, because there is a large market for each type of process. It's more about choosing the right type for your process design.
1. Everyone fits into this one process
Many processes can be captured in a simple flowchart. And if that’s the case, do it. Think about purchasing a cool T-shirt from a website; always two steps (choose, pay), always in that order, with a small detour if you have a discount voucher. A pitfall is using this type of process even when the steps don’t quite fit. Then, you have to skip unnecessary questions or answer with “n/a” or just fill in something because nothing is done with it anyway.
2. Almost everyone fits into this one process, exceptions are handled manually
Think of the scripts a call center uses to sell (complex) products. They almost always follow the process steps and questions neatly. But if a customer says, “I want it just a bit differently than you offer, and I’m willing to pay for that,” a case is created, and it is handled manually. Often by a senior handler, as exceptions and authorizations come into play. With enough senior handlers, it might be possible to keep everything going smoothly—unless they all decide to take vacation at the same time. This type of process design could also be the perfect match. However, if too many cases are flagged as special, you risk a bottleneck. Or if those exceptions take up all your time without yielding much.
3. We create a case for everyone and then find the best predefined process that fits
This turns the process design upside down: everyone gets a personal case, and we find the process type that fits best. This could also be a perfect match. Much vertical software works this way. A specific market is fully thought out and encapsulated in many small processes. There’s always one that applies. A website might start with: “I want a …” followed by a bullet list of things you can do. And if that list is comprehensive, it works perfectly! Until you want something that’s just not on the list, of course.
Very often, this last type of application is labeled as Dynamic Case Management. But that’s a bit of a stretch, as it only gives the illusion of dynamism.
If you have the power of a rule engine at your disposal, you’ll know how to create true dynamism: with rules. Because why write out the sequence when you can simply ask your case at any time what makes sense to do next?
4. There’s no sequential process, there’s only a case with a goal
A few years ago, this was a challenging starting point. What if there’s simply no sequential process? You know the goal of each case, and based on what you know about the customer in that case, rules (not the process!) determine what makes sense to do next. The comparison to a navigation system is inevitable: Given what I know about you now (where you are) and your goal (where you want to go), here’s the next step (turn left).
Our experience with this last type is vast. Complex requests for complex products cannot be captured in predefined processes. Thanks to the power of our rule engine, we can handle these requests with true Dynamic Case Management: rule-driven.
Want to read more? Check out parts 2, 3, 4, and 5.
