Блеск и нищета STP

STP как она есть

Есть такое понятие, как «уровень STP». Если, например, из 10 000 поручений, принятых депозитарием , для 90 понадобилось вмешательство оператора, а остальные 9910 были выполнены автоматически, то уровень STP равен 99,1%. Чтобы не быть совсем уж голословными, приведем конкретные примеры исполнения поручений клиентов по технологии STP. На рис. 1 представлена схема операции перевода между корреспондентскими счетами двух депонентов НРД. Во втором примере, на рис. 2, показано исполнение операции в Euroclear (ЕОС) через счет НРД. И все это без какого-либо участия человека. Конечно, чтобы все это реально функционировало без человеческого вмешательства, приходится изрядно потрудиться, создавая эффективные информационные системы и договариваясь о стандартизации сообщений. О преимуществах STP написано много, и мы не будем к этим рассуждениям подробно возвращаться. Все знают, что STP — это хорошо. Повышается скорость работы системы, ее надежность. Операционные ошибки исключаются. Себестоимость исполнения операций снижается. И все это чистая правда. Так что? Да здравствует STP?! Да, но с оговорками. У STP есть оборотная сторона, о которой нечасто задумываются. Умная STP должна быть избавлена от недостатков. Но сначала надо их описать. Именно это и является нашей задачей: обсудить недостатки STP и наметить пути их устранения или хотя бы смягчения.

Проблемы STP, или Утраченные иллюзии

Нестандартные ситуации

Раз в 5–10 лет любая уважающая себя и своих клиентов компания полностью заменяет ПО. Каждый, кому приходилось в этом участвовать, знает, каким сложным и «кровавым» является процесс запуска нового ПО и сколько сил при самом благоприятном раскладе требует такой переход. Но сейчас не об этом. Будем рассматривать благоприятный ход развития событий. Допустим, новая система написана хорошо, грамотно, с пониманием предметной области и аккумулирует весь предыдущий опыт. Ее внедрение прошло без особых жертв и разрушений. Конечно, для всех значимых технологических процессов предусмотрена полная STP. Если что-то к запуску не доделано и операционисты вынуждены работать руками, то программисты клянутся, что еще немного — и все будет хорошо. В жизни такой момент почему-то никогда не наступает, но помечтаем, что в некотором приближении чудо произошло. Итак, наступило счастливое время для операционных подразделений. Сверкают красивые экраны, все летает и обрабатывается автоматически. Остается тратить время на приятные беседы и мониторинг идеально выстроенных процессов. Но эйфория быстро проходит при столкновении с первой же нестандартной ситуацией. Жизнь разнообразна, и быстро оказывается, что разработчики далеко не все предусмотрели. STP в нестандартной ситуации не работает. Приходится возвращаться к старым проверенным методам. Все «защитные кожухи» с нового механизма снимаются и уже никогда не надеваются обратно. Вставляются поправки, заплатки, позволяющие выйти из режима STP и перейти к ручной обработке. Страдает информационная безопасность, операционная надежность. Но нестандартная ситуация обрабатывается, потому что иначе никак нельзя. Откуда берутся нестандартные ситуации? На то они и нестандартные, что невозможно достоверно предсказать их появление. Но некоторые источники все же можно описать.

Вот уважаемый клиент принимает решение перевести крупный пакет бумаг в НРД. Почему-то это обычно происходит вечером «последнего» рабочего дня. Клиент работает с НРД только по SWIFT. После прихода первого поручения (естественно, в конце дня, около 18:00) выясняется, что форматы сообщений клиента и НРД не совпадают. Клиент не может изменять свои форматы — у него STP; и внести изменения в систему невозможно: требуется согласование с «Мельбурном» и полгода работы. Однако формат не проходит через систему, НРД приходится решать задачу. Для этого надо для начала «обезвредить» полную STP и обработать поручение вручную. Вечером и ночью операционисты и программисты принимают на себя риски внесения изменений в ПО, риски неисполнения или неправильного исполнения поручений. Нестандартные ситуации размывают гранитные берега полной STP.
Помимо проблем крупных клиентов, нестандартные ситуации возникают еще из-за изменений законодательства, запуска новых продуктов и услуг, необходимости обслуживания новых рынков, приема на обслуживание ценных бумаг нового типа и, наконец, глобальных потрясений типа дефолта 1998 г. НРД, находясь в фокусе интересов Банка России, регуляторов, своих активных клиентов чаще других попадает в ситуацию неприменимости ранее сконструированной STP и необходимости «агрессивной» доработки и аварийной эксплуатации ПО. В такой ситуации STP — только помеха.

Вот еще примеры нестандартных ситуаций. Вечная тема квитовки встречных поручений. Ее правила то ужесточаются (после судебного разбирательства), то смягчаются под давлением клиентского блока. Русские или латинские буквы А, B, С, E, Н, К, М, О, Р, Т, Х? Глазами на бумажном поручении не отличишь, а машина находит разницу — и не квитует. А 007 и 7 — это одно и то же? Если число, то да, если текст, то нет. А что делать с некстати вклинившимся пробелом? А дроби 1/2 и 3/6 ? Конечно, надо бы сделать квитовку более интеллектуальной, но мнения клиентов на этот счет не всегда совпадают. Да и не предусмотришь всего. К тому же серьезные клиенты иногда так устают от квитовки и STP, что готовы написать в НРД обычное письмо с просьбой как-нибудь исполнить поручение. И на основании такого письма операционисты должны уметь вопреки STP сквитовать поручения с не вполне совпадающими полями. А вот депонент заключил сделку на локальном иностранном рынке. Локальных рынков в Euroclear около 80, и у каждого свои особенности и регламенты. Где-то нужна дополнительная информация. Надо приостановить отправку инструкции и руками внести изменения. Человек справляется, а STP — никак. Приняли на обслуживание новую для НРД бумагу. Варрант, например. Получили «экзотические» корпоративные действия. Такого раньше не было. Опять необходима ручная работа. Опять надо отключать STP.

Что уж говорить о глобальных катаклизмах… Новое ПО было введено в эксплуатацию в НДЦ через две недели после дефолта 1998 г. За эти две недели мир кардинально изменился, и старый STP не мог работать в новой реальности. Так, например, если выплата доходов по ГКО-ОФЗ до дефолта проходила в один день всем инвесторам, то после дефолта надо было платить только «физикам», чьи облигации находились в депозитариях надежных дилеров. То есть в первый же день произошел крах полной STP. Пришлось программистам, как это часто бывает, ночью «на коленке» дорабатывать промышленную систему. И таких глобальных изменений, хотя и не столь драматичных, как дефолт, в жизни НДЦ-НРД было немало: объединение НДЦ и Расчетной палаты, интеграция НРД и ДКК, создание центрального депозитария и т. п. В каждом из таких случаев STP становилась, мягко говоря, не вполне функциональной.

Автоматизированная система с нестандартными и экстремальными ситуациями справляется намного хуже человека. Выпал из потока — проблем становится намного больше, чем при ручной обработке. STP хороша и надежна в стандартных ситуациях, но очень плоха и неудобна в нестандартных. При отклонении от регламентированных процессов так плохо, как в автоматизированной системе, в ручной модели никогда не бывает. Человеку легче выкрутиться, если ему не нужно бороться еще с автоматом.
К тому же STP требует абсолютной детализации процесса. На любой вопрос необходимо найти однозначный ответ. А как этого добиться, когда даже законодательство бывает туманно, а иногда ставит невыполнимые задачи? А ведь в истории НДЦ было, что автоматическая обработка непредусмотренной алгоритмом ситуации привела к уголовному процессу.
Нестандартные ситуации — враг STP. Полная автоматизация и реальная жизнь находятся в постоянном конфликте, в борьбе противоположностей.

Оковы STP

Как ни парадоксально, но STP тормозит развитие. Это «локальный максимум». Чтобы улучшить систему, надо ее переработать, т. е. включить в план, вложить средства, потратить силы на разработку и для начала — усложнить и ухудшить. То есть прежде чем подняться на новую, более высокую гору, надо сначала спуститься вниз с этой. А зачем? И так хорошо. Зачем напрягаться и уходить от работающей STP? На рынке появляются новые перспективные сервисы и возможности. Но мы не можем ими пользоваться — у нас STP! STP новую услугу не поддерживает, а работать вручную мы уже не хотим, да и не можем. К тому же еще и некому. После успешного внедрения STP объем ручной работы уменьшается, и высвободившийся персонал подлежит сокращению. А те, кто остался, не жаждут работать руками и, закрывая собой амбразуру, обеспечивать новые услуги. Никто не оценит — у нас же STP, которая обошлась недешево. Какая еще ручная работа?! Получается, что мы упускаем шансы из-за STP: не продвигаемся вперед, не оказываем новых услуг клиентам. И еще один фактор, про который не следует забывать: STP приводит к деквалификации персонала — все забывают, как надо работать руками, в том числе в нестандартной ситуации. Операционисты отучаются думать. Опытные сотрудники покидают организацию — их умения не очень-то нужны, а новички в условиях STP медленно приобретают необходимые навыки.

В STP вложены миллионы. Необходимо показать отдачу в виде повышения надежности, снижения рисков, сокращения персонала. Разговоры о необходимости вводить новые ручные процедуры становятся неприличными. Ручной труд стал позором операционного подразделения. Невозможно объяснить, почему нельзя сократить персонал, для чего опять понадобились неавтоматизированные процессы. Поэтому ручная работа превращается в дополнительную нагрузку операционистов, о которой к тому же руководители операционных подразделений из чувства самосохранения предпочитают не заявлять. Нужно совершенствовать процедуры, но как это сделать, если проблемы остаются в тени? Однако жить как-то надо, и рядом с STP начинают работать теневые алгоритмы самого разного уровня. Если в возникшей ситуации невозможно немедленно выполнить доработки, восстанавливающие STP, то организуется ручная работа. В лучшем случае заявка ставится в очередь. А от некоторых доработок вообще приходится отказываться, поскольку есть неопределенности в алгоритме. В этом случае новые услуги можно обеспечить только руками. Это самая распространенная причина возникновения ручных технологий.

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

Ручной труд необходим. Но его тоже надо хорошо организовать, о чем часто забывают в погоне за миражом полной STP. Инструменты и технологии, облегчающие ручную работу, должны быть удобными и хорошо продуманными. Не везде применим экскаватор, иногда нужна лопата. Но лопата должна быть удобной и эргономичной. Хорошую лопату сделать не так просто. К сожалению, об этом часто забывают.
Любая ручная операция рассматривается как минус системе — недоработка ИТ. В результате ручной режим исполнения операций программируется зачастую по остаточному принципу, без серьезной проработки, а то и вовсе не реализуется из-за вечного дефицита ресурсов. А реализация сопряжения автоматической и ручной обработки — не всегда простая задача. Нужно сопрягать безошибочно и быстро работающий автомат с медленным и постоянно ошибающимся человеком. Нужны дополнительные проверки, двойной ввод, контроль исполнения операций и т. д. Ручной режим надо тщательно проектировать и реализовывать. А сейчас процветает экстремизм: либо STP, либо как-нибудь. И это неправильно.

Назовем основные причины, по которым STP через некоторое время начинает тормозить развитие компании:

• Действующая система морально устарела и требует полной замены. Ядро уже не соответствует новым требованиям.
• Темпы развития компании опережают возможные темпы модернизации системы.
• Доходы от новой услуги оцениваются ниже расходов по доработке STP.
• На начальных этапах процедуру оказания новой услуги трудно формализовать.
• Не хочется прилагать усилия — мы и так хорошо живем на своем уютном локальном максимуме. К чему лишние беспокойства?

Хлопоты поддержания STP

Достоинства STP неоспоримы, поэтому при разработке ПО особое внимание уделяется именно автоматизации процессов. Современные системы должны взаимодействовать с десятками систем-контрагентов. У каждой такой системы свои форматы (даже если они основаны на мировых стандартах), свои особенности, регламенты работы и прочие нюансы. Типичный сценарий налаживания взаимодействия между системами выглядит так: поначалу сообщения вводятся вручную, а параллельно процесс автоматизируется и тестируется. Когда автоматизация готова, она вводится в эксплуатацию, время от времени улучшается и оптимизируется. Все хорошо, но жизнь не стоит на мечте. Внезапно от системы-контрагента приходит сообщение в таком формате, что наша система его не понимает. Причины могут быть самыми разными: модернизировано ПО контрагента, изменилось правовое регулирование, к нам пришли сообщения по операциям с нового зарубежного рынка. Казалось бы, выход очевиден: нужно перейти на ручную обработку и параллельно настроить или доработать систему под новые форматы. Но все не так просто. Ручной ввод проектировался и разрабатывался для одного-двух сообщений в день, и раньше этого хватало. Но теперь сообщений, требующих ручной обработки, приходит в день несколько сотен, и в существующих формах ввести их имеющимися силами нереально. К тому же при организации взаимодействия систем все внимание было уделено STP, а оптимизацией процедур ручного ввода никто не занимался. В результате аврал. STP должна быть реанимирована в течение нескольких часов. В операционном подразделении тоже пожар — данные приходится вводить вручную, а это долго, неудобно и опасно. В конце концов подвиг будет совершен, данные героически введут, систему на коленке доработают, все закончится благополучно. Но достается это дорогой ценой — авральные доработки не так тщательно проектируются и тестируются. И это может оказаться миной замедленного действия, проявившись в будущем в виде ошибок или сложностей при дальнейшем развитии системы.

Поддержание во всех случаях полной STP трудоемко и нецелесообразно. Надо заранее планировать устойчивые механизмы ремонта STP в чрезвычайных обстоятельствах. В том числе временного перехода на хорошо подготовленный и обустроенный ручной режим, наличия для этого необходимого квалифицированного ресурса. А иначе не избежать частых изматывающих авралов. Если же авралы случаются регулярно, то это оказывает демотивирующее воздействие на пользователей и разработчиков системы. Нельзя работать в условиях постоянного пожара. Хлопоты поддержания STP разнообразнее, чем это может показаться. Если мы принимаем решение автоматизировать очередную область, следует позаботиться об автоматизации взаимодействия с существующими автоматизированными кластерами. А это увеличивает затраты и риски. Поэтому необходимо провести дополнительную оценку: если затраты на сопряжение окажутся значительными, интеграция с существующими STP-областями сложна, а объем операций и риски не слишком существенными, разумнее оставить такую область без STP, грамотно организовав ручную обработку. Если услуга автоматизации перестает быть актуальной и ее требуется закрыть, то необходимо данный сервис демонтировать либо, по крайней мере, законсервировать. Если этого аккуратно не сделать, то со временем такие области превращаются в зоны отчуждения, поведение которых предсказать невозможно и которые могут оказывать влияние на процесс по своим, давно забытым «алгоритмам».
Например, в НРД к таким областям можно отнести работу со счетом «До выяснения» применительно к центрально-депозитарным ценным бумагам. В соответствии с действующим законодательством зачисление центрально-депозитарных бумаг на такой счет невозможно. При этом все ЦД-бумаги, учитываемые на нем до момента вступления в силу Закона «О центральном депозитарии», были переданы регистраторам. Это было отражено в системе и стало примером грамотной консервации старого процесса. Другим примером демонтажа ранее автоматизированных процессов стали «мостовые» схемы: мост НРД–ДКК, схемы ускоренных расчетов SSS с ING, Ситибанком, Дж.П. Морган, Дойче Банком, Сбербанком, ВТБ и другими местами хранения. Степень автоматизации работы «мостовых» схем была близка к 100% — это были одни из первых интеллектуальных STP-процессов в НРД с элементами самонастройки параметров. После получения статуса центрального депозитария «мосты» были за ненадобностью закрыты, а сама технология демонтирована. И такой демонтаж и консервация также являются необходимым элементом поддержания системы STP.

Проблемы клиентов

Как сказывается STP на клиентах? Плюсы очевидны: формализация процессов, скорость, отсутствие ошибок. Казалось бы, при развитии STP роль службы клиентской поддержки должна неуклонно уменьшаться. В НДЦ на заре эры электронного документооборота один из ИТ-менеджеров депозитария сделал прогноз, согласно которому по мере развития ЭДО будет постепенно исчезать потребность клиентов в службах, сопровождающих их деятельность: в клиентских менеджерах, операционистах, технической поддержке. Однако время шло, а клиентская поддержка не исчезала. Более того, сопровождение клиентов год от года набирает все большие обороты. Почему же не сбылось предсказание? Казалось бы, все просто: подавай поручение и жди исполнения. Но на деле все оказалось совсем не так.
На наш взгляд, наиболее существенными причинами этого являются:

• недружественный интерфейс клиентского рабочего места;
• трудные для прочтения и понимания регламенты и инструкции;
• сложность используемых форматов;
• частые изменения форматов и регламентов;
• несоответствие форматов и систем клиентов и депозитария;
• ошибки в клиентских приложениях и ПО депозитария.

Только этих причин достаточно, чтобы клиент сам не справился бы с навалившимися на него проблемами в одиночку, без постоянного взаимодействия с помощниками через приоткрытое окно автоматизированной системы.
По мере развития депозитария проблемы частично решались, но одновременно с этим возникали новые вопросы, связанные с изменением регулирования, выходом НРД на новые рынки, появлением новых услуг, модернизацией операций, созданием сложных продуктов и т. д., что, в свою очередь, приводило к дополнительной нагрузке как на клиентов, так и на сам депозитарий. Развитие любой компании всегда сопровождается шероховатостями; не стал исключением и центральный депозитарий: временами возникали сбои в работе ПО, наблюдались расхождения регламентов и реальности. Внедрение новых продуктов приводило к замедлению обновления действующих технологий и услуг. В этих условиях ждать сокращения числа обращений клиентов вряд ли приходится.

При всех своих достоинствах STP создает для депонента дополнительные проблемы. Клиент, как правило, привык к ручному обслуживанию, хорошему сервису и ласковой поддержке. Интерфейс автоматической системы недружелюбен. Инструкции по эксплуатации — огромные и нечитабельные. Клиент готов написать в НРД короткое письмо, где он может простым человеческим языком (а не языком STP) попросить исполнения той или иной услуги. Например, зачислить в НРД бумаги с нового локального рынка. Как это сделать в форматах STP, клиент не знает и ждет помощи. Бывает, что жесткие рамки STP дезориентируют клиента. То есть он не получает ожидаемого результата. Бумаги оказываются не там, либо сроки нарушены. Надо помогать клиенту в таких ситуациях. По крайней мере, пытаться устранять такие «автоматические ловушки» для неискушенных клиентов.

Можно ли облегчить жизнь клиента в суровых условиях STP? Для этого надо как минимум решить выявленные проблемы — «развернуть» перечисленные в начале раздела пункты:

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

А также многое другое. И тогда можно будет говорить о построении качественной системы электронного взаимодействия клиентов и депозитария, эффективной, удобной и дружелюбной STP. В этом случае сделанный более 10 лет назад прогноз приблизится к реальности. Жесткая STP станет мягче и добрее по отношению к клиенту. Необходимость в клиентской поддержке снизится, но было бы наивно думать, что потребность в ней исчезнет. Пока система развивается, пока есть клиенты, их надо будет сопровождать и поддерживать.

Умная STP

Проблемы STP не смертельны. Если подойти к конструированию системы разумно, то многих проблем можно избежать. Надо понимать, где нужна STP, а где без нее лучше обойтись. Попробуем описать, какой должна быть умная STP.

Долой экстремизм полной автоматизации

При проектировании и разработке системы автоматизации нужно изначально закладывать возможность проведения операций вручную. Полная автоматизация хороша тогда, когда операции и процедуры взаимодействия с внешними системами проверены временем, устоялись и отлажены. В условиях же внедрения нового функционала должна быть возможность использования полноценного режима ручной обработки. Ключевое слово тут — «полноценный». Такой режим работы должен быть запланирован изначально, продуман и реализован. Необходимо иметь возможность управления тем, какие операции система выполняет автоматически, а какие выдает на ручную обработку. Возможность такой настройки должна быть заложена изначально, это должно быть правилом, обязательным при разработке системы. При этом ручная обработка должна быть органичной частью системы, дружелюбной для пользователя. Имея надежный тыл в виде продуманной и гибкой системы ручной обработки, легче искать компромиссы между бизнес-пользователями и разработчиками в решении о полной или неполной реализации STP. Бывают ситуации, когда лучшее — враг хорошего, и затраты на полную автоматизацию выходят за рамки разумного баланса между стоимостью реализации и частотой использования. Автоматизировать редко исполняемые операции дорого и бессмысленно. Так, например, обстоит дело с обработкой нестандартных SWIFT-сообщений по новым локальным рынкам. Следуя правилам STP, система «не понимает» эти сообщения и отклоняет их, не раздумывая. Но жизнь требует от НРД такие сообщения принимать и обрабатывать. В системе должна быть предусмотрена возможность останавливать «неправильные» сообщения, в частности от определенных контрагентов, и отправлять на ручную обработку. Этого было бы достаточно. Но такой режим не был реализован, так как система разрабатывалась под лозунгом полной STP. В результате приходится в пожарном порядке дорабатывать систему под новые сообщения. И совсем не факт, что это еще кому-то понадобится в ближайшее время, — клиент привел свои бумаги в НРД и больше ему эти операции не нужны. Получается, что пришлось поработать ударно и напрасно.

Другой пример, когда ручная обработка была реализована и доказала свою эффективность, — ввод и изменение анкет ценных бумаг в депозитарную систему. Вроде бы ничего сложного: ввели параметры бумаги, а система автоматически внесла изменение в анкету. Но жизнь, как всегда, сложнее. Например, бумага торгуется на бирже и ее параметры нельзя менять пока не прошли расчеты. Или бумага снимается с обслуживания, но по ней еще не проведены корпоративные действия и есть остатки на счетах клиентов. Можно долго и увлеченно описывать все подобные ситуации и придумывать изощренные алгоритмы их автоматической обработки. Однако решили, что проще и дешевле будет останавливать изменение анкеты и ждать подтверждения операциониста. И это сработало! Система выполняет трудоемкие рутинные проверки, обеспечивает контроль правильности данных, но при этом не перегружена логикой тотальной автоматизации всевозможных нестандартных ситуаций. А человек с этим справляется неплохо. В результате система оказалась и не чрезмерно сложной, и абсолютно гибкой.

Еще пример — проведение корпоративных действий с бумагами, различного рода конвертации и т. п. Система реализует довольно сложный функционал по проведению «инвентарных» корпоративных действий, но при этом у операциониста есть возможность приостановить исполнение сформированных поручений и вручную их отредактировать. Большая часть корпоративных действий обходится без ручного вмешательства, но иногда в нестандартных ситуациях оно оказывается необходимым. И это тоже работает. Конечно, операционисты время от времени требуют автоматизировать действия, ставшие регулярными, но это можно делать не в авральном режиме. Правда, у такой благостной картины есть и оборотная сторона. Разработчик системы должен быть нацелен на автоматизацию, а не отмахиваться от нее, прикрываясь тем, что есть ручной режим — вот им и пользуйтесь. Но это уже вопрос управления. Найти компромисс и определять, когда автоматизация нужна и рентабельна, а когда нет, — это и есть работа администратора. В умной системе автоматизация не должна быть полной. Должен оставаться люфт для хорошо продуманной и организованной ручной работы. Сложные и редкие вещи автоматизировать не надо. Это дорого и нецелесообразно. К тому же наличие разумного объема ручной работы поддерживает персонал в хорошей форме и позволяет сохранять квалификацию.

Хорошая система должна быть интеллектуальной

Известный публицист Лоуренс Питер написал:«Любая хорошо работающая вещь или идея будет использоваться во все более сложных условиях, пока не станет причиной катастрофы».Это в полной мере относится и к системам STP. Коварство STP заключается в ее обманчивой успокоительности: кажется, что ты все предусмотрел, система автоматизирована на 100% и можно позволить себе расслабиться. Но не тут-то было. Все предусмотреть невозможно, а STP не прощает ошибок проектирования, каждая из которых рано или поздно приведет к инциденту в боевом режиме. Причем когда его совсем не ждешь. И иногда с тяжелыми последствиями. Почему так происходит? Любая система имеет пределы, или по-другому — «горизонты», своей применимости. Понятно желание построить универсальную автоматизированную систему, пригодную во всех случаях жизни. Но так не бывает. В умной STP-системе «горизонты» должны быть четко определены с самого начала, при этом предсказуемый автоматический процесс возможен только в их границах. Если пределы применимости системы на этапе проектирования не определены или определены некорректно, то процесс заходит за «горизонт» — в этом случае поведение системы предсказать невозможно. Например, рассмотрим систему, принимающую и обрабатывающую в автоматическом режиме электронные сообщения участников. При потоке стандартных сообщений выигрыш STP-подхода очевиден. Но достаточно направить одно очень большое сообщение, чтобы «сломать» систему, если при проектировании мы не предусмотрели ограничения объема. Система начнет обрабатывать полученное сообщение как стандартное, «подвешивая» весь процесс и тормозя тем самым обработку остальной информации.
В приведенном примере этой неприятности легко избежать. Достаточно было при проектировании определить максимальный объем сообщений, обрабатываемых по стандартному алгоритму. Но проблема намного шире. «Горизонты» могут быть самые разные, в том числе заранее не предусмотренные и не предвиденные. В идеале система должна сама понимать, что она достигла своего «горизонта», что возникло что-то непредусмотренное и подозрительное и надо выходить из стандартного режима. Такую систему можно было бы называть «интеллектуальной STP».

Не всегда обозначить «горизонт» так легко, как в рассмотренном примере. Самое опасное — когда система, работая по своему алгоритму, сталкивается не с количественным барьером, а с качественно иной, не предусмотренной алгоритмом ситуацией. В истории НРД был случай, когда таким образом были списаны арестованные бумаги, потому что алгоритм исполнения обязательного выкупа не предусматривал такую проверку. Виновата была STP, а отвечать пришлось людям. В этом случае системе явно не хватило интеллекта, ощущения опасности и «чувства своей некомпетентности». Казалось бы, предвидеть все такие случаи невозможно. Это правда. Риск останется всегда. Однако вспомним, что антивирусные системы не только вылавливают знакомые им вирусы, но и регистрируют подозрительную активность, пытаясь квалифицировать странные объекты в качестве вредоносных. Не будучи специалистами, не беремся судить, насколько успешно они с этим справляются, но неплохо было бы, чтобы в наших системах такие возможности тоже были заложены: уловить потенциальную опасность, остановить процесс и отправить его на ручную обработку. Увы, пока об этом можно только мечтать.

Один хороший программист говорил, что правильно написанная программа умнее своего автора. Он имел в виду, что если программу написать «правильно», то она нормально работает даже в таких ситуациях, которые автор не предвидел, когда эту программу писал. Вот так и наши системы постепенно должны становиться умнее своих изготовителей, хотя достичь этого не так легко по разным причинам. Интеллектуальная STP должна быть организована по модульному принципу. Помимо обычной автоматической обработки процессов, также должен работать «контролер» — модуль анализа отклонений процесса от нормы и при выявлении таких отклонений перевода его в другие режимы. Кроме того, «контролер» может накапливать статистику отклонений от нормы для последующего принятия решения о расширении области STP или для установки новых ограничений. Другими словами, работу STP-системы необходимо все время изучать, проводя R&D (Research and Development) с целью выявления тех областей, где чаще всего происходят выбросы и в которых, возможно, требуется дальнейшая автоматизация или обозначение новых «горизонтов».

Для нормальной работы сложной системы в постоянно меняющемся мире нужна не просто STP, а «интеллектуальная STP», в основе которого лежат следующие принципы:

• четко определены ограничения системы — «горизонты» автоматизации;
• ведется постоянный анализ отклонений процессов от нормы и в случае выявления таких отклонений (выхода за границы) — перевод системы в режим ручной обработки;
• осуществляется анализ работы системы для определения последующих областей автоматизации процесса и/или необходимости введения новых ограничений.

Следуя данным принципам, можно надеяться на создание STP-системы, которая, с одной стороны, сократит время обработки операции и повысит производительность труда, а с другой стороны, позволит избежать разных неприятностей, в том числе катастрофы, предсказанной Лоуренсом Питером. «Интеллектуальная STP» дороже и сложнее обычной, но скупой платит дважды — ошибками, инцидентами и авралами.

Гибкость облегчает выживание

Нужно ли оставлять рядом с полной STP ручные режимы работы? Нужны ли волшебные операции, которым разрешены любые проводки в обход запрещающих корреспонденций? Нужно ли создавать «программы-вездеходы», которые выполняют в системе приказы супероперационистов? У каждого, кому пришлось ночью по много часов ждать исполнения элементарного скрипта, меняющего в системе состояние флажка, сомнений нет: конечно, нужно. Точно так же не может быть никаких сомнений у того, кто хоть раз получал неоспоримое указание высших сил: несмотря ни на что сделать все быстро и качественно. Конечно, нужно!
Но создание такого режима работы гораздо сложнее реализации примитивной STP. Затраты на такие системы могут намного превышать затраты на обычную STP. А ведь еще надо позаботиться о создании эффективного ручного режима обработки документов, который обычно реализуется по остаточному принципу. Если вдруг отказывают каналы связи, то в подписанных договорах обычно предусматривают переход на бумажный документооборот. Но, по сути, при нынешних объемах и скорости доставки документов это чистая фикция. Реально доставку такого количества бумажных документов никто обеспечить не может. Далее, при обработке бумажных документов предполагается автоматическая выгрузка из базы данных актуальной информации. И для этого нужны ИТ-ресурсы. Требуется приложить немало усилий, чтобы все эти «маргинальные» процессы работали и не перестали работать после очередной реорганизации системы. А как убедить в необходимости тратить на это силы и время? Ну и конечно, упомянутые ранее нестандартные ситуации. Их разрешение чаще всего сводится к совершению операций в ручном режиме. И такой режим тоже должен быть разумно организованным. А почему не предоставить клиенту возможность указывать в своих поручениях признак ручной обработки (за дополнительную плату)? Да мало ли что еще…
Сделать систему гибкой нелегко, но стремиться к этому нужно. Это должны быть и выходы на хорошо организованный ручной режим, и универсальные «программы-вездеходы», и возможности супероператора при надлежащем контроле рисков. Трудно, но необходимо. Окупится эффективностью.

Преодоление оков STP

Необходимость преодоления оков STP — естественная задача, с которой сталкивается любая развивающаяся организация. Надо двигаться вперед, а сотрудники не всегда хорошо мотивированы и не хотят лишних трудностей в своей жизни. В этом ситуация с STP мало чем отличается от похожих ситуаций в других областях. Решение подобных вопросов — важнейшая задача бизнес-менеджмента, и вряд ли авторы могут претендовать здесь на что-то новое и необычное. Но все же позволим себе несколько простых соображений. Высокий процент автоматизации приучает операционный персонал к относительно хорошей жизни. Поэтому возникновение необходимости ручного исполнения операций вызывает возмущение у операционистов. Тотальная автоматизация воспринимается как норма, а ручная работа как недоразумение. В итоге формируется позиция: если не автоматизировано, то не делаем. Обычно это объясняется увеличением операционных рисков, особенно рисков информационной безопасности. Плохо воспринимаются также попытки финансовой оценки необходимости STP: «автоматизировано должно быть все, независимо от цены».

Никаких волшебных методов борьбы с такими взглядами не существует. Эффективные менеджеры должны проводить тимбилдинги и размышлять, как стимулировать коллектив к развитию, но никак иначе, как административными методами, решить такую проблему невозможно. После тщательного анализа «за» и «против» приходится брать ответственность на себя и принимать жесткое решение о ручном режиме оказания услуги. Чем более эффективна система, тем меньше издержек у такого решения, но совсем без них обойтись нельзя. «В геометрии не бывает царских путей». Другое дело, что ручной труд должен быть почетным, хорошо организованным и достойно компенсированным, но это опять азбука менеджмента.

Есть также проблемы, связанные с разработчиками. STP надо развивать. Команда, обычно находящаяся в штате компании, как правило, не готова серьезно ломать недавно созданную нормально работающую систему: лучшее — враг хорошего, да и отдохнуть не мешает. Проверенные кадры предпочитают поддерживать старую STP как можно дольше и без крайней необходимости не будут трогать самые сложные места: пока не сломается, я туда не полезу. А еще ведь нужно окупить затраченные средства. Система обошлась недешево во всех смыслах. Надо как можно дольше ничего не менять, чтобы затраты окупились. Средств на большие доработки в бюджете не запланировано. Будем находить обходные пути, делать заплатки.

Увы, и здесь не обойтись без административного ресурса. Определяется бюджет, принимается решение, подбирается команда. Приходят новые люди, готовые к переменам. Для них легче написать новый код, чем разбираться в старом, стараясь законопатить трещины. Умение объединить в одной команде опыт и стремление к новому — большое искусство. Успех зависит от двух факторов: замотивировать старую команду и создать новую, боеспособную. В истории НДЦ и НРД все великие перестройки инициировались извне. Принималось решение. Утверждались бюджеты. Старая команда обычно тяжело втягивалась в работу. Часто критиковала, искала повод указывать на некомпетентность новой команды. Какие-то из этих перестроек были успешными, какие-то не очень. Но в конечном итоге появлялось новое качество, и система начинала работать на новом, более высоком уровне.
Где располагается в организации источник импульсов, стимулирующих к развитию STP? Как показывает практика, такого единого места нет. Их как минимум три. Первое находится в «развитии», которое следит за рынком и призвано внедрять новые услуги. Второе — это операционные подразделения, которые оказывают очень срочные и очень важные штучные услуги, а также начинают эксплуатировать новые неавтоматизированные продукты. Третье — это клиентские подразделения, которые принимают на себя потоки предложений, жалоб и недовольств депонентов. И конечно, должны быть механизмы анализа всех таких импульсов и принятия решений о модернизации системы STP.

И в заключение…

Может быть, кому-то показалось, что авторы видят в STP только минусы и проблемы. Нет, конечно. Нашей задачей было привлечь внимание к недостаткам технологии STP и предложить пути их преодоления. А так, да здравствует STP! Но только умная и гибкая.

Авторы благодарят Ирину Медовскую за материалы, предоставленные для подготовки статьи.