�and whatever the man called each living creature, that was its name.
Genesis 2 - 19
This experience-based paper describes the protocol used by BT Portfolio Services Limited to assist administrators in the manual inspection of approx 1.8 million investor instructions per year. Using this protocol, supervisors list phenomena that administrators in their department may observe, and actions that other departments must then perform. Administrators use these lists while inspecting investor instructions.
At the core of the protocol's implementation lies a distributed checklist framework. Each department manages its own checklists. The protocol defines a method for the synchronisation of checklists between departments.
The protocol helps to coordinate inspections, standardise reporting and unify incident handling procedures across multiple departments. Using the protocol, the quality of the inspection process was increased in terms of uniformity, accuracy, depth and throughput. The protocol also helps with 'on the job' training of administrators. It could be deployed in various environments such as source code walk through, GUI inspection and more.
BT Portfolio Services Limited (BTPS) is a fully owned subsidiary of BT Financial Group, the Australian member of the Principal Financial Group of Des Moines, Iowa.
BTPS offers investment organisations the expertise of more than 900 specialist administration staff. It has more than AU$60 billion under administration and 21 years experience in investment administration (as at November 2000). BT Portfolio Services offers the following outsourcing services:
Unit registry (for wholesale and retail investment and superannuation vehicles)
Accounting and taxation
�Unit pricing.
Wrap, a service that allows financial planners to maximise the revenue generated by their unique skills as time-consuming administration is outsourced to BT Portfolio Services.
BTPS received 1.8 million instructions from investors in 2000. Most of them arrive via Australia Post, and some arrive via the Internet, the telephone or BT Funds' Voice Response System. The first department to handle investor instructions that arrive via Australia Post is the Document Control Centre� (DCC). The DCC opens envelopes, scans the investor instructions into an imaging system, performs preliminary verification, deposits cheques and electronically forwards the investor instructions to the appropriate departments within BTPS.
Investor instructions move within BTPS and evolve through activities performed in successive departments. These departments may process the investor instruction if it complies with the business rules, or transfer the investor instruction to another department for further action, for example to contact the investor. As most transactions yield a confirmation letter that the fund manager sends to the investor, the send-out department is the final destination of most investor instructions.
During the processing, each administrator composes comments and attaches them to the investor instruction. The comments list the administrator who handled the investor instruction, the transaction, the investor, issues raised during the processing of the investor instruction and the resolution of these issues.
The comments were written in free text format resulting in ambiguity, inconsistency, shallow learning curve and inability of the computer to analyse these comments.
To handle that challenge, BT wrote the Comment Assistant - a tiny computer program that helped administrators to compose and tailor these comments. The Comment Assistant is a data driven program. Its data files list:
Phenomena that administrators may observe,
Activities that the administrators in downstream departments must then perform, and
The electronic pigeonhole in which the investor instruction must be placed.
Each department created files using this structure for each type of investor instruction that it processed.
The deployment of the Comment Assistant to each department was a structured project. In stage one the Comment Assistant was demonstrated to the department managers who had to decide if the Comment Assistant could help their department. If they thought it would help, they assigned a supervisor to be the first to use it. That administrator had to:
Be knowledgeable of the variety of issues arising in his department,
Perform hands on processing,
Be able to devote time to the task, and
Be able to train colleagues to use the tool upon completion.��
After the installation of the Comment Assistant on the supervisor's PC, a member of the deployment team visited the supervisor to explain the technicalities of the Comment Assistant and to help the supervisor create some basic comments.
The supervisor then used the Comment Assistant for a week, improving the configuration files. Next, a member of the deployment team visited the administrator for a second time. By then, the technicalities were usually resolved and the discussion was focused on workflow issues. A week later the configuration files were mature and the Comment Assistant was ready for deployment to the supervisor's team.
The size of configuration files varied between 5 and 50 comments depending on the complexity of the task
To ease the selection of phenomena, the supervisors were presented with the option to classify phenomena using a hierarchical structure. Sometimes they used a logical structure where, on the top level (the menu first presented to the administrator), only categories were listed. On the other hand, some supervisors picked a functional structure whereby on the top level the most commonly observed phenomena were listed together with a small number of categories that included the less common phenomena.
The latter grouping method optimised time and motion in terms of the number of mouse clicks needed to key the observations.
Comment configuration files are never frozen; whenever new issues are identified, the supervisor adds them to his department's configuration files. Furthermore, the dialogue between departments makes sure that all the messages created by the upstream departments are relevant and clearly understood by the downstream departments, somewhat like the tuning of the bidding process in the game of Bridge.
This section will present the lessons learned from sociological and data processing viewpoints.
Free format annotations expose the administrator to phenomena that Norman described as "the tyranny of the blank screen".�(That is to say, when one is trying to write for whatever reason, the first few words are always the hardest ones to get out. The same thing happens to painters...the first brushstroke is the hardest one to make on the blank canvas). To overcome this we are presenting the administrator with a checklist that helps her to describe the attributes of an investor instruction.
To facilitate the formal communication between departments we created a simple commenting language. Its grammar had three constructs: Phenomenon, Action and Electronic Pigeonholes.�
Phenomenon is what the administrator sees.
Action is what a down stream administrator consequently has to perform.�
Electronic Pigeonholei dentifies the next process that the investor instruction has to move to.
Now imagine that two departments can negotiate a protocol to describe what phenomena one department should look for and what actions the other should consequently perform. That will make sure that upstream departments are looking for the phenomena that are relevant, ignore phenomena that are not and convey their findings to downstream departments in a clear, consistent and unambiguous manner.
In the simple workflow described in Drawing 1, three departments A, B and C have to process an investor instruction, and a fourth department - Reject Management handles exceptions. Twelve protocols need to be defined to establish bilateral communication between each of the four departments.
In the general case the number of protocols is:
p=2(n-1)!
Where p is the number of protocols and n is the number of departments.
Due to the nature of the factorial expression
(n-1)! - p can be large.
Maintaining these protocols, by themselves and in synchronisation with each
other, is a Sisyphean-task (The
Gods had condemned Sisyphus to ceaselessly rolling a rock to the top of a
mountain, whence the stone would fall back of its own weight. They had thought
with some reason that there is no more dreadful punishment than futile and
hopeless labour).
To store these protocols we have thus constructed the logical data model illustrated in the recursive drawing 2.
The following paragraphs annotate the logical data model:
A Department observes many Phenomena.
A Phenomenon requires one Activity.
An Activity is queued in a Pigeonhole in front of another Department.
This logical data model was implemented as a number of flat files, in which each department maintains its own outgoing-comments. All the comments relating to each investor instruction type were grouped into a single flat file. All the investor instruction types handled by each department were then grouped in a directory dedicated to that department.
Using the protocol, administrators are reminded to perform a diagnostic, but in some cases the diagnostic is not simple and requires training and experience. For example, administrators can be reminded to compare signatures, but nothing in the protocol can teach them how to do so. To learn how to compare signatures the administrator has to attend dedicated training.
The protocol cannot cope with high complexity diagnostics where the number of roles is in the thousands as the hierarchical structure will be too slow to navigate.
The average menu size is seven. The average number of Keystrokes (k) behaves as the base 7 log of the number of possible phenomena (N).�
k = log7 (N)
For N larger than a million, k is larger than seven, so the user will have to answer too many questions before he arrives at the appropriate answer.
This section lists possibilities that are still open.
Overlaps management - Identify phenomena that were supposed to be found upstream, but were only found downstream.
Straight through processing - rather than letting a downstream department perform the task, spoon-feed it into a STP engine.
A relational database is an appropriate mechanism to store the information currently stored in the flat configuration files.
Productivity of administrators is improved when they use the document annotation protocol, and its three major building blocks:
Phenomena observed,
Activity to be performed and
Department that will perform the activity.
The author wishes to acknowledge the help of his colleagues in brainstorming and proofing this paper, in particular Michael Mekhitarian, Robert James, Bill Fulton and Peter Ward.
The New English Bible, Oxford University Press Cambridge University Press 1970
The Psychology of Everyday Things Donald A. Norman HarperCollins; ISBN: 0465067093
http://www.1122productions.com/brandon/thoughts/insightful/00-01-19.html
http://stripe.colorado.edu/~morristo/sisyphus.html
By now you may have benefited from our Web site, so please sign our guest book and turn this monologue into a dialogue.
