Стратегии развития АБС. Семилетняя история автоматизации российских банков позволяет узнать: есть ли общие черты в путях автоматизации российских банков. При описании базовых стратегий технологического развития банков (в части программных решений) удобно использовать классификацию, предложенную В. Колсаноным (в прошлом – начальник управления банковских технологий Тверьуниверсалбанка). Любая стратегия технологического развития банка подразумевает формулирование функциональных и экономических требований (с различной степенью детальности) к системе автоматизации и соответствующую реализацию этих требовании.
Собственная разработка. Этот этап в развитии автоматизированных технологий в разное время был пройден подавляющим большинством российских банков, поэтому ему стоит уделить внимание. В этот же сегмент включены так называемые «эксклюзивные» разработки, выполненные под заказ одного банка и не поддающиеся тиражированию. Основные признаки подобной стратегии:
- первыми автоматизируются исторически «базовые» функции банковской системы – бухгалтерия и расчетно-кассовое обслуживание, существующие по крайней мере в двух-трех десятках тиражируемых российских систем;
- не разделены служба разработки и служба эксплуатации банковской системы, не выделены моменты передачи версий банковской системы в эксплуатацию, и, как правило, понятие «версия АБС» вообще не приемлемо;
- неполноценное документирование системы (частичное наличие проектной и эксплутационной документации) либо полное отсутствие документации.
- С точки зрения специалистов, имеющих опыт создания и внедрения АБС в крупных и средних банках, разумными основаниями для собственной разработки могут являться:
- интеграция нескольких систем при числе автоматизированных рабочих мест в банке более 200;
- разработка целых модулей системы при числе автоматизированных рабочих мест в банке более 500;
- наличие у банка уникальных бизнес требований и уникальной стратегии информатизации, удовлетворить которые не в состоянии ни специализированные системные интеграторы, ни разработчики промышленных тиражируемых решений. В этом случае требования и стратегия должны быть явно сформулированы во внутренних документах банка с соответствующим контролем (аудитом) их реализации;
- столь динамичное развитие банка, что бизнес требования не могут быть выдвинуты даже на год вперед. В этом случае разрабатываемая система является только макетом будущей информационной системы. Сегодня это уже в прошлом: наступает этап стабильного развития банковской системы.
С точки зрения специалистов, имеющих опыт профессионального банковского консалтинга, помимо приведенных причин, собственная банковская разработка может быть оправдана:
- для небольшого по количеству персонала одно-филиального банка с небольшим количеством ежедневных операций – «домашнего» банка крупной промышленной либо торговой компании, консорциума, холдинга (примеров тому довольно много);
- как связующее звено для автоматизации головного офиса многофилиального банка при установке однотипных тиражируемых решений в филиалах и отделениях;
- для узкоспециализированного банка со значительным преобладанием операций, не характерных для банковского сообщества в целом;
- для крупного универсального банка в части автоматизации передовых финансовых технологий, пока еще недостаточно освоенных российским банковским рынком. При отсутствии адекватного предложения на рынке тиражируемых решений такая разработка бывает оправданной в части указанных финансовых технологий вплоть до их сопряжения с основной AБC. Эта причина становится все менее определяющей, поскольку промышленные решения ведущих российских разработчиков быстро развиваются в функциональном отношении;
- для среднего банка, имеющего целью стать «законодателем технологической моды» в области автоматизации финансовых операций при сильной динамике развития банковского рынка в целом (например, Инком банк, Кредо банк, Сибирский Торговый банк, Оптимум-банк). Однако и эта причина осталась в прошлом как из-за нынешней стабилизации банковского рынка, так и из-за наличия большого числа конкурентоспособных предложении. Заметим также, что правильнее изначально ставить задачу создания «отчуждаемых технологий», а не «технологий для себя».
Основным недостатком собственной разработки является сложность интеграции консолидированных технологий в получаемые проектные или программные решения. Кроме того, обычно собственные разработки характеризуются низким (в большинстве случаев) качеством закладываемых проектных проработок, которые позволяют получить решение проблемы лишь «на сегодня», но не дают возможности оперативно отслеживать изменение внешних условий в будущем (отчетность, развитие финансового рынка, введение новых банковских операций, развитие информационных технологий вообще).
Еще одна опасность заключена в неоправданном завышении приоритетов системных требований (аппаратное обеспечение, операционная среда, инструментарий разработки, коммуникации) перед бизнес-требованиями (функциональность, надежность, безопасность, поддержание и развитие технологий).
Одним из негативных последствий этого преобладания является то, что в банке могут более или менее успешно решаться только текущие проблемы автоматизации типа «не проводится документ», «потерян клиентский платеж», «требуется более мощный компьютер», «нет связи с филиалом/отделением». Кроме того, хотя все пользователи знают, что в далеком будущем банк будет работать на «самой лучшей» программно-аппаратной платформе типа Sun + Oracle или Hewlett-Packard + Informix, никто не знает, как будет развиваться автоматизированная система в среднесрочной перспективе и какие финансовые технологии «завтрашнего дня» можно использовать «уже сегодня», хотя бы в ограниченном объеме.
Замеченная еще в 1995 – 1996 гг. тенденция к снижению относительного качества и количества собственных разработок сегодня получает дальнейшее развитие. В 1997 г. существенно сузится тот сегмент технологий банковской автоматизации, где представлены собственные разработки. В дальнейшем, на рынке останутся лишь те, которые выполнены по законам классической программной инженерии: Техническое задание ® Технический проект ® Информационная модель ® Прототип АБС ® Система комплексной автоматизации.
Корпоративно-субъективная. Цель такой стратегии состоит в реализации любых требований всех (или почти всех) банковских пользователей. Финансирование стратегии ведется в зависимости от возможностей банка и искусства руководителя управления (департамента, отдела) автоматизации, роль которого весьма велика. Стратегия характерна главным образом для малых банков, а для средних и крупных она оказывается крайне опасной. Банкам не всегда удается удержаться в рамках подобной стратегии, особенно при неравномерном развитии и при смене приоритетов в банковском бизнесе. Поскольку требования по переходу на новую систему учета в конце 1997 г. были «самыми главными», то для небольших банков с подобной автоматизацией приемлемыми были решения по обновлению версии или по покупке наиболее дешевых из «двадцатиразрядных АБС».
Партнерская. В рамках этой стратегии обычно выбирается стратегический поставщик информационных технологий, и вся работа ведется исключительно (или главным образом) с ним. Возможен вариант, при котором банк и фирма являются взаимными акционерами или учредителями друг друга. Как правило, поставщик является производителем интегрированных программных решений класса АБС. Разновидностью этой стратегии стало использование конкретной промышленной АБС во всех филиалах крупной «банковской империи». В целом это достаточно дорогой способ, но эффективный при следующих условиях:
фирма-партнер профессионально специализируется в области банковских информационных технологий и имеет опыт разработки и внедрения высокотехнологичных отчуждаемых программно-аппаратных решении;
при действительно партнерских отношениях фирма-партнер должна быть тесно интегрирована с банком (желательное условие) и иметь успешный опыт работы с банками такой же «весовой категории» (обязательное условие). Разумеется, что банк и фирма-партнер должны территориально находиться в одном городе.