During recent discussions with customers and digging through many RFP requirements in the area of Debt Management, there seem to be 2 main streams when it comes to the organization of the debt management workforce. The first one is the traditional approach: Every debt (bundled liability of a debtor) is linked - at any time - to an org unit – even often a position or a person.
There are 3 key considerations of this approach:
- Reporting and success measurement needs to be belong to an org unit.
- Actual monitoring of debt and case decisions. Someone needs to “own” the debt and “case manage” the debt.
- No debt/debtor should "fall through the cracks" or in other words every debt should get constant (or at least periodic) attention
The organisational units (org units) are classified along certain type of debt, regions, activities and many more attributes. As the debt has a very dynamic life cycle, debt is often “re-shuffled” from one org unit to the next. In a more "advanced version", IT will build tools to help with the reshuffling. For better oversight of the debt, it is often managed in work-lists. Sometimes reporting within the work-lists is needed because of high debt volume in the work-lists.
This, very traditional, approach has been derived from the time when debt collectors managed washing baskets of debt cases. “Mobile - meant putting the washing basket full of debt cases into a car boot”, “Reshuffling meant to move some paper folders – the workflow objects - from one washing basket into the next”.
In the beginning, IT automation did not challenge this approach much. The "debt case washing baskets" were basically organised in digital work-lists. It was a typical approach to model the real world 1:1 in computer systems without much re-engineering. Soon this approach was questioned, because departments realized that complete automation does not necessarily need an org assignment anymore. Moreover, 2 new types of collection personal were added to the traditional debt case managers. First the IT personal that needed to manage the automation and second the personal that only performs certain, specialized tasks (e.g. phone calls) without case managing debt.
Often this new approach was hybrid in nature, meaning that there was a clear cut between auto and manual-case enforcement. However, it was an either or approach; many systems struggled to operate automation and manual approaches hand-in-hand.
In requirement roll-in sessions with customers, I was surprised that more and more customers did not require a general debt-case at all anymore. Yes they needed work-items and specialized cases e.g. for certain enforcement or bankruptcy cases, but it sounded the like the generic debt case is dead. Most generic debt cases were anyhow always a 360 debtor view of current open debt and linked proceedings.
I guess it made sense to me, because manual decision making along generic debt cases - managing millions of debtors - is not a very scalable approach. Every manual decision is only good for the individual case, but the system does not learn from past decision making across cases.
Exactly this shortfall led to the second - more modern - stream:
As in the world of collection management automation is an absolute paradigm, your system becomes the main owner of a very high percentage of debt (being currently completely automated). The system is intelligent and only involves the workforce when necessary; the system can automate many decisions and creates work items or enforcement actions whenever it is necessary (e.g. create a property lien only when a property exists and legal prerequisites are met). There is no strict separation between auto enforcement and manual enforcement anymore. For example, the collection engine can pick up circumstance changes automatically in real-time and notifies enforcement officers owning one or more enforcement actions currently running. Sure generic debt cases still exist e.g. for high-value/profile cases or cases where all other avenues had been exhausted, but they clearly become the exception.
Monitoring of debt, which has not been pursuit for some time is extremely important, because the rules of the engine become more complex. This process can be automated without constant, direct org-debt assignment. It becomes part of a system, which is highly automated and supports exception handling - including human decision making – only when required.
Finally, in order to support this shift, we need to add a fourth type of workforce. A highly skilled Debt Collection Manager: (S)he is involved in understanding data, patters and trends with the help of new analytical tools. Understanding of the complete system with all legal/policy/quality/workforce boundaries is required. With a deep business understanding, the learnings can lead to new or improvement of existing collection strategies. These strategies need to be constantly tested and success evaluated. New successful strategies are automated to become new best business practice. This is an ongoing process as your environment, customer behaviour, policies and so on change all the time. A modern debt management system needs to support the daily task of debt collection managers by providing automation, data insight, prediction, decision support and flexibility. Decisions of the debt collection manager will have a positive effect on many cases – so their work truly scales. It is a quantum change as also success will be measured more holistically rather than on individual case-worker or org level. Assigning the success to an org unit where payment was received based on a completely automated standard letter was always the success of the holistic system rather than that of a regional org unit (which might have never touched the debt, but was just assigned because e.g. the debtor lived in their region).
The following picture summarizes the types of debt management workforce and their importance for the optimization approach:
SAP is deeply committed to support the daily work of debt managers, so your debt management workforce can focus on the optimization of your debt collection machine. Please let me know your thoughts about this topic.
- SAP Managed Tags:
