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