This case study is based upon a short exploratory project undertaken by
a large UK-based bank. As for any large bank, 'Arrears and Collections' is
a core business activity. At any given time it will have tens of
thousands, perhaps hundreds of thousands, of products in arrears, ranging
from a current account that has exceeded its agreed overdraft limit, to a
mortgage where whole payments have been missed. Many of these situations
are not serious: they may have arisen from a simple oversight or
misunderstanding on the part of the customer, or possibly a clerical error
by the bank itself, and will rectify themselves within a few days. At the
other end of the spectrum, the arrears and collections department must deal
with serious default, bankruptcies and fraud.
Business background
The sheer volume of the minor infringements dictates that they be
handled initially by an automated system. This bank has a sophisticated
system for generating a series of automated letters, of rising severity.
The wording of these letters is a science: the system constantly tracks the
effectiveness of each letter template, and tests new 'contenders' against
the 'champion' letter for any given arrears status.
If the letters fail to correct the situation then at a certain point
the case will come to the attention of an arrears and collections officer.
The threshold for that transfer may be based on fixed criteria such as the
amount and duration of arrears, or upon an assessed risk profile for the
customer. The officer will then decide what new course of action to
initiate. This may involve seeking to negotiate an agreement for the
gradual repayment of the arrears, restructuring the debt, repossessing the
goods (for a secured loan), or pursuing the debt through the courts. It
may even involve the discovery that the borrower is deceased and the
initiation of a claim against the estate.
Whilst the generation of automated letters is a model of technical
sophistication, IT support for the interventions of an officer is minimal -
little more than a speadsheet and word processor. Ideally, an arrears and
collections system should seamlessly integrate the automated early stages
of a case with the intensely manual later stages. Such integration would
make it easier to track a single case from end to end, and to monitor the
relationship between early tactics and later ones. It would also allow the
officers to intervene earlier in some cases, and place others back into
'auto-pilot' for a period.
Approach
We worked with a small team of business and IT managers to explore a
possible design for such a system using Naked Objects. The team had no
difficulty identifying certain core business objects that would feature in
the system, including Customer, Officer, Account, Transaction, and
Case.
At any given time, each arrears case will be subject to a particular
'strategy', though this strategy will change according to how the case
progresses. At the start of the exercise, the business managers referred
to 'thousands' of such strategies. However, within a couple of weeks the
team had abstracted them to just 13 core strategies, each of which has
branches and variations:
- Identify cause and try to identify non-arrears situations (e.g.
technical errors).
- Extend facilities (e.g. extend overdraft, offer new loan
product).
- Generate automatic letters of increasing severity.
- Accept the customer's verbal promise to remedy by a specified
date.
- Make direct contact with the customer and establish
circumstances.
- Make and monitor an arrangement to repay (over a period).
- Trace a customer who has gone missing.
- Recover securities.
- Take legal action.
- Write off the debt.
- Outsource the debt.
- Claim against (the deceased's) estate.
- Monitor account closely after rehabilitation.
One of the main challenges we faced was that both the IT and business
manager involved had a very strongly process-oriented view of the world.
They assumed that these strategies would be implemented using a workflow
engine or some other form of high-level scripting mechanism, and would draw
data, and perhaps even some limited forms of behaviour, from the core
business objects. However, since part of the purpose of this exercise was
to evaluate the potential of the Naked Objects approach, the team somewhat
reluctantly agreed to think of these strategies as objects in their own
right. (In fact the 13 strategies would all be sub-classes of a generic
Strategy class.) Unlike, say, the Customer object, these Strategy objects
have a sense of direction: they would be designed to follow a sequence of
known states, even if that sequence might sometimes backtrack. It can be
useful in object modelling to draw a simple distinction between
'purposeful' objects and 'non-purposeful' objects: the former can be
thought of as vestigial processes, but it is important to understand that
they do not 'sit on top of' the other objects in the way that processes are
usually conceived. In fact, it is just as valid to envisage them as
'sitting inside' the non-purposeful objects.
Prototyping the system using the Naked Objects framework not only
helped the team to envisage this concept, but also to see the benefits of
this way of thinking. Now, instead of thinking of the strategies as verbs
on a top-level menu, they saw them as nouns - represented as icons.
Changing the strategy being applied to a particular arrears case could be
envisioned, both metaphorically and literally, as dragging a new Strategy
object into the Case object. Moreover, when an officer reviews a case, she
can immediately see the history of the case summarized as a list of icons
representing the Strategies previously attempted. Double-clicking on any
of these icons would permit inspection of how that Strategy actually
progressed and was terminated. It is very hard to get this kind of view
from a workflow system. Each Strategy object is capable of executing a
sequence of actions and responding to events such as new Transaction on the
Account that is in arrears. Additionally, each Strategy will have its own
exit conditions, which may include simply the passage of sufficient time.
Upon exit, a given Strategy may replace itself with a different one or it
may bring the Case to the attention of an Officer to make the
decision.
In fact, experienced object-oriented programmers will recognise that
this is a standard programming design pattern, coincidentally named
'Strategy'[Gamma1995]. Such patterns seldom seem to be
known by business analysts, however. This brings out another general point
about Naked Objects: they make it easier to apply the rich, expressive
power of a language like Java or SmallTalk to solving business problems.
Most methodologies insist that the analysis be independent of any
programming language. This would be a laudable aim except that the net
effect is that resulting designs fail to take advantage of these powerful
object patterns.
Evaluation
Two things surprised the team. The first was that it was possible to
design a sophisticated system purely in terms of behaviourally rich
objects, without ever having to draw a set of process diagrams. The second
was that accepting the constraints of the Naked Objects approach quickly
yielded some insights into the nature and structure of the arrears and
collections activity that no-one had previously seen (specifically, the
abstractions that existed within the notion of strategies). Given the very
limited amount of time that the business representatives could devote to
the exercise, they were very surprised at the amount of useful work that
actually got done. One comment was that: "In the time that we would
normally have spent just discussing how to get started on gathering the
requirements, we had actually built a simple working model of the business
domain that yielded some new and useful insights into how our business
actually operates."
A brief description of the responsibilities of four of the naked object
classes follows.
Class: Account
Sub-classed for different types of account including: mortgage, credit
card, unsecured loan, bank account etc. The object acts as a wrapper onto
the account management system, which will perform the transactional and
management reporting responsibilities. Specific responsibilities
include:
- Identify if it is in arrears and be able to advise the amount and age
of arrears.
- When the account first goes into arrears, either create a new Case,
or if a Case already exists for that Customer, then add this Account to
that Case.
- Display a zoomable, visual history of the account for a specified
period, showing planned and actual balances.
- Calculate the impact of one or more hypothetical transactions upon
the account (mostly used when making an arrangement - this ideally
should be done like a spreadsheet).
- Alert the Case either to a significant change to the arrears
situation (in amount or age) or to any transaction.
- Report arrears to credit agency if appropriate.
- Freeze or make temporary restrictions.
Class: Asset
Most commonly these will exist because they are securities on a loan
(e.g. a mortgaged property) or because they form part of the loan contract
(e.g. a car). Asset can also be used to model any known physical asset in
cases of recovery. The most common assets will be modelled as specialized
sub-classes of Asset so that they can record their own specific details.
Specific responsibilities include:
- Initiate physical recovery.
- Realize value (initiate a sale of the asset).
- Assess net worth (e.g. apply depreciation).
Class: ArrearsCase
Responsible for managing the workload of the arrears and collections
process, and for producing management information. The majority of arrears
cases, however, will not involve the intervention of an officer. Specific
responsibilities include:
- Split, merge, or subsume other Cases.
- Be brought back to the attention of an officer.
- Be forwarded to another officer.
- Choose initial Strategy upon creation.
- Alert Strategy to changing events.
- Provide management reporting on current status.
Class: Strategy
Some Strategies will operate automatically - others will involve an
Officer. Each strategy has a desired outcome, which may be fixed or may be
determined by the officer. Strategy is an active object - it is not
merely an attribute. Strategy is a means to achieving an outcome, not a
sequence of actions. Specific responsibilities include:
- Select the version to be used (most Strategies have 'champion' and
'challenger' versions). This is done by the system, not by the
user.
- Take next action - when and what.
- Generate the standard Communications appropriate to that
Strategy.
- Instruct the Account (e.g. freeze withdrawals).
- Respond to events such as a transaction, communication from customer,
increase in debt, or the passage of time.
- Terminate itself (or be terminated manually by an Officer) and pick
the next strategy (including referral to a officer to decide
manually).
- Benchmark itself - whether it worked or not, including by
version.
|