Обыкновенное чудо

Некоторые люди, особенно те, кто далек от ИТ-технологий, считают, что автоматизация – это волшебная палочка-выручалочка. Стоит только захотеть, и всё устроится само собой. Такой подход вынуждает ИТ-специалистов для сотворения чуда задерживаться на работе до поздней ночи. В одной из предыдущих статей я рассказывал о программном обеспечении, которое позволяет автоматизировать процесс поиска решения. Именно поиска, а не генерации. Автор одного комментария просил помочь «совершить чудо», ускорить процесс обработки данных. Сразу хочу пояснить – я не Колумб и не открою Америку, если скажу, что вопрос сокращения скорости обработки данных возник не сегодня и не исчезнет завтра. Вопрос не будет снят с повестки даже в том случае, если вам удастся каким-то образом сократить время обработки данных в несколько раз.

Несколько лет назад, до моего перехода в «Техносерв», я работал в банке, который использовал программное обеспечение собственной разработки. О плюсах и минусах такого подхода я предлагаю поговорить в одной из следующих тем, а сегодня мы поговорим о «чуде». Так вот, когда в банке приступили к разработке программного обеспечения, то оно позиционировалось как приложение для работы с корпоративными клиентами. Через какое-то время стратегия банка изменилась - он стал работать в розничном секторе. Счетов и проводок с каждым днем становилось больше, а производительность системы оставалась на прежнем уровне. В результате банк оказался в ситуации, когда в конце месяца времени от завершения одного операционного дня и до начала следующего едва хватало для выполнения всех операций, связанных с закрытием месяца и подготовкой необходимых отчетных документов. И если для подготовки обязательных отчетных документов Центральный банк еще отводит дополнительно несколько дней, то для начисления процентов, комиссий или исправительных проводок этого времени нет. Частичное решение этой сложной задачи было поручено мне. Скажу с гордостью, что ситуацию в банке удалось взять под контроль и нормализовать.

Анализ причин показал, что наиболее узким местом в процессе закрытия дня были многочисленные операции ввода-вывода. Наиболее эффективным методом для сокращения времени выполняемых операций могло быть изменение алгоритма расчета или кода программы. Однако это процесс длительный, а банк живет текущим днем и не может ждать несколько месяцев. В данной ситуации было принято, на мой взгляд, наиболее оптимальное решение. Для обеспечения выполнения процедуры закрытия операционного дня были приняты организационные меры (составление графика начала и окончания отдельных операций, персональная ответственность за своевременное начало выполнения работ и контроль отсутствия непроверенных и неподтвержденных операций). Это позволило сразу же сократить риски срыва сроков при закрытии операционного дня. Следующим шагом была задача по модернизации алгоритма закрытия дня. Параллельно с этим в банк была приглашена внешняя компания-интегратор, которая предлагала без изменения исходного кода оптимизировать работу системы таким образом, чтобы время выполнения конкретных операций (закрытия операционного дня) сократилось минимум на 10-15%. Предвидя, что рано или поздно ситуация обязательно повторится, перед технологами банка была поставлена стратегическая задача выбора и перехода на новую промышленную систему. Как видим, для решения всего одной, но архиважной для банка задачи было параллельно реализовано четыре варианта локализации проблемы! А теперь о результатах. Организационные меры дали положительный результат. Используя благополучное сочетание выходных дней и окончания месяца, нам удавалось некоторое время достаточно успешно решать вопрос своевременного закрытия месяца. Четкая координация действий сотрудников различных подразделений позволила сократить временные потери, а следовательно, и риски, до минимума. В дальнейшем был разработан регламент предварительного начисления процентов и комиссий, что также благоприятно сказалось на продолжительности окончательного завершения работы всех процедур. Внешняя организация смогла оптимизировать работу системы с временными таблицами и индексными файлами таким образом, что время выполнения критически важных операций сократилось на 17%. А изменение кода программы специалистами банка уменьшило это время еще в три раза! Окончательную точку в решении вопроса своевременного выполнения работ по закрытию месяца банк поставил, перейдя на новое промышленное решение операционного дня. И вот примерно такие «обыкновенные чудеса» ИТ-служба банка делает ежедневно. Просто мало кто об этом знает.

Почему я обратился к теме ускорения обработки данных? Именно потому, что эта тема актуальна для многих ИТ-подразделений финансовых организаций, в то же время в этом вопросе нет универсального решения. К каждой задаче надо подходить индивидуально. Приведенный пример наглядно показывает, что в одном банке для решения всего одной задачи были параллельно применены абсолютно различные методы, каждый из которых позволил добиться положительного результата. Часто взгляд со стороны, привлечение интегратора, обладающего всеми необходимыми компетенциями и ресурсами, помогает оперативно выявить узкие места в процессе обработки данных и помочь банку и его ИТ-службе оперативно найти решение по оптимизации.