The procedure. Inside a bank that is a topic that has all the appeal of a trip to the dentist. Regulators expect us to have them and senior managers expect us to follow them, not least because that certainly gets them a tick in the CYA box of life. For the poor schmucks that are supposed to do the day job though, these things are an accident waiting to happen. This week’s post takes a look at the world of procedures. You might think you are about to read a tale from the Ministry of the Bleeding Obvious; that is far from the truth.
Imagine a GMAT or CFA question on procedures. If you are not familiar with those quiz forms, think of the them as an advanced form of what the Brits call “a multiple guess exam”, in other words a not so straight forward multiple choice test.
For your organisation, select the answer that best applies to the following statements.
- The procedure is something that has to be published due to some compliance reasons
- I have no idea what the current version is. There is a copy of the procedure in my bottom draw, or at least there was last time I looked
- The procedure is stored somewhere on a shared drive; I have no idea what it is called
Select A if statements I, II & II are correct Select B if none are correct, but before you do, think that one through again
I was in a client’s office recently where a good friend of mine has become the local Operations manager. Whilst I was in the office, enjoying the morning coffee, he was running round the office with a thin sheath of papers in his hand. “Guys, this err procedure, does anybody err know where we have this on the LAN?”, “What’s the document called?”, “Err, dunno.” At some point, perhaps not even that long ago, somebody had done some work and written all of it down. Maybe six months later, a revision was needed, but nobody could find the document. The few sheets of paper had not one indication as to the file name, the location it was stored at, or even the author and there was certainly no version number in sight. So the old version was as much use as a broken watch; it could only be right twice a day.
There are two things that are pretty certain in today’s world of Operations: things go wrong infrequently and, in this world of follow-the-sun processing and 7×24 support, those things will go wrong on a different guy this time than the last time. It is simply not realistic to keep all these things in your head and expect to be able to recall them. Even if at the exact moment in time the procedure was written, it was a good one, it was an inadequate procedure if it can not be readily maintained. In fact, after a few months, it will be as much use as a chocolate teapot. Now, even if you can find a copy of the procedure, how do you know it is the right one? Somebody I know very well works for one of those nice big Swiss banks. In retail cross-border client relations. Even in neutral Switzerland, that is the equivalent of working in an unmarked minefield. Switzerland of course has rules and of late in that business segment, having upset the governments and finance ministers of many a G20 nation, it is making and changing rules like a bunch of rabbits overdosed on Viagra. The client advisors have to be certified in the rules of country group they support. No harm in that. And, when I asked the question about procedures, yes of course they have them. “We hev rules!” How are they shared and kept up to date? A word file sent round by e-mail. Now you have to feel sorry for those client advisors. Of late, every one of them that does the slightest thing wrong is getting the old tin tack, in a manner that owes more to a Kangaroo Court than the hallowed halls of a global institution.
A simple view of operational blow-ups or incidents is that one would triage them into two piles; adequate procedure not followed or an inadequate procedure. Having the procedures either without basic details, or “somewhere on the LAN”, or in Word is simply a priori an inadequate procedure.
Here is a example of the procedure doing exactly what it should do. If you are in the FX business, you have to deal with something called CLS. It allows you to settle the payment of one side of an FX trade simultaneously with the other side: If you are selling USD vs. GBP, you can exchange those USD for GBP without having to make a payment and hope the other guy pays you. FX is a huge market, both in terms of the numbers of trades and the value of them. CLS is like Heathrow airport and Clapham Junction rolled into one; all the big planes and the overwhelming majority of trains go through each of them. CLS processes one million trades a day worth some four trillion USD. Loadsamoney. And it is connected to 17 of the largest Central Banks in world. Everybody involved globally in that ecosystem strives and does get it right, day in, day out. That does not mean that nothing goes wrong, but it does mean there are some robust procedures underneath it. Recently, a bank I am acquainted with had a very bad day. Plan A, the fully automated process did not work. Diligently and as per the procedure, the team switched to Plan B, which meant manually entering the payments. That failed too. As the play clock ran down to the witching hour of 08:00, the team switched to Plan C, a totally manual “send the payments by fax” option. Old fashioned and crude yes, but effective. Two of the nine payments, all of them in the many millions of dollars, were late. But just, one minute in fact. That is a bruise and it is not fatal. As it turns out the cause of failure to Plans A and B was a process not owned by the FX team; the team owning that piece of the infrastructure either had an inadequate process or one that was not followed. In full the spirit of full disclosure and thorough learning, the Fx team did discover that they had been prescriptive about when to go from A to B, but not about exactly when to bin B and go to C. Immediately after the event, all the procedures could be updated on-line by the end users, the folks doing the job, and all the details that were needed about how to execute plans A, B & C were on line in a combination production checklist and procedure that included all the contact details for the banks, input details for Plans B & C, templates for option C. Al the information that might be needed. There was no reliance on Joe, Marcel or Sanjay being there and doing heroics. And, there’s one more thing. The FX team owned the whole process. It was absolutely not their fault that some process somewhere else in the bank fell over, but it was their responsibility to run production and get those payments made.
One particular excuse in Operations, much loved when you are checking the status of something is the “e-mail cop out”. As in “I have sent an email chaser to so and so”. This is a lesson I learned early and never forgot; it was during my formative year at IBM as an industrial trainee, which the Americans call a co-op student. I was asked to pull a project together and had to source a piece of it from a long time IBM vet who was just not delivering. Asked about the status by my boss and “master sergeant trainer”, a brilliant guy and long time IBM’er, Kevin Walling, I gave it the old “Well I asked Pete and he hasn’t delivered anything” explanation. That was followed by what in German is called “ein Abrieb” or in plane English, a good old-fashioned bollocking. I was told in no uncertain terms that this was a black and white case of it being my responsibility even it was the other guy’s fault. One dressing down was enough and that lesson was impregnated in my grey matter forever!
Lessons Learned: Last week we commented on Standard Operating Procedure, or SOP. That procedure must at the very least have: document details, including filename and version, author, file location and detail, as well as enough detail that an insider could jump in and do the job. Now in the ideal world, that procedure is on-line in a place where every Operations person can find it without a special login and password. It will be in pdf format; locked and certain. In Nirvana, that procedure will be sliced up into a production checklist that allows tasks to be assigned as daily, weekly, quarterly etc. One and only one team can own the procedure and the checklist. They might have help with some tasks, but they own and are responsible for the whole lot.
Epilogue: “We don’t need another hero!” So sang Ms. Tina Turner, incidentally a nearby neighbour on the fine shores of Zurich’s Gold Coast. It might be taking a few liberties to think she was thinking about banking, but her words are on target: “Looking for something we can rely on, there’s gotta be something better out there”. There are lots of workflow tools now out there that will take you beyond the simple MS Word document. But, beware. Many of them are not truly end user tools that are as easy to use as a Spread Sheet. Invariably, the purveyors of the best thing since sliced bread will tell you that they have a great box of Lego and they can solve all your problems, as well as send a man to the moon. Well, with all due respect to my numerous and talented friends in the IT world, any tool around procedures and checklists that needs their help to add a procedure or change one, is an inadequate tool. Get the power in the hands of the user. Hunt around, try some things out. One you might want to look at is Menntor (see: http://menntor.com/)
Share on:
