Deutsche Übersetzung folgt in Kürze.
There's a special kind of process - the one that has lived so long enough without thorough, deep planning, that it became a nightmare to automate. The lack of this kind of planning was not out of malice, of course. It's just quite a challenge to design something that doesn't yet exist. Especially if the process to design is a thing as complex and dense as every bank committee is.
Yes, the process that has pushed me so much that I decided to write an article about it - is our default committee.
Committees in general, and default committees in particular, exist in every bank. And in the bank where I've been for three years now - through thick and thin - all committees depend on similar, not particularly great, systems and abide by the algorithm that demands dozens of hours of paperwork.
And you know what?
I've understood how good it really is - that, above all, committee is about people, not a machine.
After all, knowing - or at least having a sense of - where your dear colleagues are looking and why, you can enhance the system, direct their attention, and please their eyes with a simple, clear diagram, report, or form. Nicely structured or cozily embedded into the process where its base couldn't be just altered.
So, when the automation task landed on my desk, that's exactly where I started: human-centered design.
The first thing, of course, was to eliminate (or rather, reduce) operational issues caused by simple data input.
After all, a committee is something of a complex manual beast: default decisions require... a mountain of manually filled out documents. Sure, colleagues fill them out responsibly, but mistakes here are just inevitable.
My deeply respected colleague did everything he could about it: instructions, templates, training sessions (and not just once). But the mistakes remained, no matter how many we put in our rich dictionary - sometimes human creativity works against us.
But all the paperwork was filled out following a pattern: yes/no, accept/not accept... - so, I decided, validation should be logical as well. It should check: - data types and dimensions; - true/false conclusions across the entire document; - syntax.
And Python helped me with that.
And all the errors I caught, once accumulated, fed into improving the document forms themselves, to reduce the amount of issues.
Of course, if I could simply highlight errors and report them at the entry stage - that would have been perfect. But alas. Not particularly great systems have their limits.
At first, this validation covered only the final documents. But we receive documents constantly.
And they constantly travel between different people and departments, and those people draw very important conclusions based on them. So, the cost of a single mistake is enormous - in the direct monetary sense. Though more often, it just causes frustration, conflicts, and waste of precious time.
So I adjusted the system: more validation points. They have to be everywhere. At every stage: - during machine-side calculations on the server; - during machine-side calculations on the user's side (if there are options to change values or an algorithm manually); - between systems (consistency checks); - during manual transfer (integrity checks); - during calculated aggregation of manual data (logical relationship checks).
Here Python came to my rescue again.
I can't help but mention how documents automation via Python is saving us every day. Taking and processing data right from the servers, with neat documents at the end - that is a small miracle. The one that saves us dozens of hours.
Sure, any committee isn't just documents at entry. It is also some at the end: decisions themselves, dates, time, participants and clients (with all the related data) - everything exclusively for human readers.
And it's critically important to make it machine-readable and store properly and as completely as possible.
Not least for the very important and thorough inspections by the Central Bank (CB).
In this area, I had quite the wide freedom. And I made good use of it: - I set up fast storing with validation at every step (all - with those CB reporting requirements in mind); - I reconstructed existing entities and added a couple of new ones - to fill the gaps where they could make our lives easier; - I created data quality reporting system to support the process; - I accompanied every step with instructions;
And, of course, I was reporting every entry issue I encountered to my colleagues.
The result: a pretty neat system of validation and thorough recording of default committees in the databases. A good friend of any report. With - what makes me especially proud - a very small error pool that shrinks even further with each new report made.
It was nice to get praise from my boss for it. Though, of course, I saw: there was still much to be done, it wasn't ideal. But it was good, considering the tools and process conditions I had: time is more precious to us than a couple of extra MB.
And honestly, this kind of conclusion could be applied to our entire default committee process.
Every automation has its limits, mostly set by the sources. The data sources.
Legacy code, attributes, architectural decisions made in the past, lacking data quality systems, - all of these are natural artifacts of long-lived systems. But they still create problems that can't be solved without workarounds, and not the most elegant ones. And along with them unplanned transitional business entities and data marts spring up - things not originally designed for.
While working on default committees automation I realized - it's not so much about trying to avoid those artifacts (that's impossible, we are just users), but rather to anticipate them, plan for them, and gracefully integrate them into the process, with their eventual disappearance in mind. One day the source will be adjusted or replaced entirely.
No architecture is perfect (and design rarely is). But that's okay. It just needs to be ready for a change.
And with my efforts, it will definitely become better.