Есть такой тип процессов, автоматизировать которые - дело особенно неприятное. Это процессы, долгое время живующие без грамотного планирования. Не от злого умысла, конечно. Порой грамотно распланировать то, чего еще нет - задача весьма нетривиальная. Особенно, если процесс сам по себе сложный и с плотным бекграундом в виде аналогичных процессов, существующих в вашей очень большой и серьезной компании.
Так вот, процесс, так меня взбодривший, что я решила посвятить ему статью - это комитет по дефолтам.
Комитеты в целом и по дефолтам в частности есть во всех банках. И в банке, в котором я уже третий год - и в горе, и в радости - все комитеты живут в похожих, не особенно оптимальных, системах и реализуются по схожему алгоритму, требующему десятки человеко-часов бумажной работы.
И, знаете, оказалось, это даже плюс, что любой комитет - это именно люди, а не машина.
Ведь зная или по крайней мере представляя, куда дорогие коллеги смотрят и зачем, систему можно дополнить, внимание можно направить, а глаз можно порадовать простой и понятной схемой, отчетом или формочкой. Грамотно выстроенными или уютно встроенными в процесс там, где его нельзя было изменить в своей основе.
Поэтому, когда передо мной выросла задача по автоматизации, именно с такого, человеко-ориентированного, проектирования я и начала.
Первым, конечно, требовалось устранить (или точнее - уменьшить) операционные ошибки от простого заполнения.
Все же, комитет - это своего рода ручной зверь: для его решений нужно множество документов. Вручную заполненных. И пусть коллеги заполняют их ответственно, но неминуемо делают ошибки.
Мой уважаемый товарищ постарался сделать все от него зависящее: инструкции, шаблоны. Он даже провел обучение пару раз. Только ошибки не исчезли, сколько бы мы ни ловили их и ни заносили в обширный словарь - человеческие творческие жилки порой работают против нас самих.
Однако все документы заполнялись по алгоритму: да/нет, признать/не признать... - значит, решила я, валидация тоже должна быть логической, с проверкой: - типов и размерности данных; - true/false выводов по всему документу; - синтаксиса.
С этим нам помог Python.
А все отловленные ошибки, накопившись, уже шли в дело более близкого к коллегам проектирования - работы над формой документов. Чтобы заполнять их было проще и удобнее.
Конечно, если бы мы могли просто подсвечивать ошибки и сообщать о них еще на этапе заполнения - вариант был бы идеальный. Но увы. Неоптимальные системы накладывают свои ограничения.
Итак, по началу такая вот валидация покрывала лишь итоговые документы.
Только ведь... мы получаем документы постоянно.
И они постоянно кочуют между разными людьми и отделами, и эти разные люди делают на их основе выводы. Обычно - очень важные. Так что и стоимость одной ошибки огромна - в прямом денежном смысле. Пусть куда чаще она просто вызывала раздражение, конфликты и трату бесценного времени.
Тогда я скорректировала систему: больше точек валидации. Валидация должна быть везде. На каждом этапе: - при машинном расчете на сервере (тут все проще и понятнее - подчинено машине); - при машинном расчете на стороне пользователя (там, где есть опции корректировки данных или алгоритма на месте); - между системами (проверка консистентности); - при ручной передаче (проверка целостности); - при машинной агрегации ручных данных (проверка логических связей).
И везде нас снова выручал Python.
Не могу не упомянуть и то, как нас выручила автоматизация документации средствами Python. Брать и обрабатывать данные с серверов, выдавая аккуратные документы на выходе - это маленькое техническое чудо. И экономия десятков, если не сотен, человеко-часов в год.
Конечно, любой комитет по дефолтам - это не только документы на входе. Это и сами его решения, их дата, время, участники, клиенты (с широким набором связанных с ними данных) - исключительно человекопонятная информация.
И ее смертельно важно перевести в понятную машине и отразить в системах как можно полнее.
Не в последнюю очередь для тщательных проверок Центрального Банка, конечно.
На этом поле у меня была особенно большая свобода. И я сумела ей грамотно распорядиться: - организовала быструю фиксацию с валидацией на каждом шаге (и с учетом требований по отчетности!); - переворошила существующие сущности - исправила и добавила то, что было необходимо; - подтянула новые сущности - для заполнения пробелов там, где это упрощало жизнь мне и коллегам; - внедрила отчетность по качеству данных в сопровождение процесса; - сопроводила инструкциями каждый шаг фиксации и проверки; - регулярно репортила коллегам странные места во входной документации и данных.
Как результат: аккуратная система, валидирующая и впечатлительно полно фиксирующая в базах каждую подробность прошедших комитетов. Добрый друг любой отчетности. С минимальным пулом ошибок, который уменьшается еще больше - с каждым новым отчетом.
Приятно было получить похвалу от начальства за это. Хотя, конечно, я видела: архитектура вышла не идеальной. Но, что же - таковы доступные нам средства и условия процесса: время нам дороже пары нелишних МБ на сервере.
И, честно говоря, этот вывод актуален для всего нашего комитета.
Полнота автоматизации (от которой зависит и скорость фиксации) всегда упирается в источники данных.
Legacy-код, атрибуты, решения в архитектуре, отсутствие корректной валидации, денормализация - все это естественные артефакты жизни долгоиграющих систем, но они все же порождают проблемы, без обходных, не самых элегантных процессов нерешаемые. А с ними плодятся незапланированные, переходные бизнес-сущности и витрины, не заложенные изначально.
Я поняла - важно не сколько стараться их избежать (это невозможно, мы часто всего лишь пользователи), сколько предусмотреть, запланировать и грамотно встроить их в процесс, подразумевая их дальнейшее исчезновение, удаление - когда сама система будет скорректирована или источник - просто заменен.
Никакая архитектура не идеальна (вообще редкое планирование - идеально). Но только это нормально. Она просто должна быть готова к изменениям.
И моими стараниями она обязательно станет лучше.