Как внедрить САБ в банке?

Андрей Литовкин занимается внедрением САБ с 1987 года. За это время он накопил ценнейший опыт и поделился своими наблюдениями, размышлениями и полезными советами в этой статье.

Часто у меня спрашивают: «Что же делать? Руководство дало указание работать на новой информационной системе через месяц!». Отвечаю – плачьте! Ваш проект из серии нереализуемых проектов и тут Вам остается только одно – решить для себя, что пришла пора искать работу или искать пути выживания, чтобы при ответе на вопрос «Кто виноват?!» не показали пальцем на Вас. Эта статья не касается аспектов выживания в проектах подобного рода. На тему нереализуемых проектов очень много написано у таких авторов, как Брукс, Йордон, О"Коннэл и т.д . Лучше этих, всемирно признанных авторитетов, я вряд ли сумею изложить тему выживания в нереализуемом проекте, остается только рекомендовать Вам почитать труды этих авторов, которые давно стали у уважающих себя ИТ-менеджеров настольной литературой, не потеряв своей актуальности и сегодня.

Эта статья не претендует на состязание с монографиями Йордона, Брукса и других, её цели заметно скромнее. В ней нет описания строгих математических методов проведения планирования. Фактически это тот опыт, который был накоплен автором в процессе внедрения целого ряда САБ.

Если Вам, после прочтения данной статьи, удастся хоть на тысячную долю процента увеличить вероятность успешного внедрения САБ в Вашем банке – я сочту свою задачу успешно выполненной.

Составление плана проекта

Внедрение САБ – нормальный проект, подчиняющийся практически всем законам проектного управления и не отличающийся от проекта внедрения любого программного обеспечения. Поэтому, до заключения контракта, Вы, а главное руководство банка, должны представлять себе основные характеристики этого проекта, а именно, сроки и ресурсы, которые Вам необходимы для реализации этого проекта. Конечным результатом данного этапа должно стать формирование бюджета проекта и плана-графика реализации проекта.

Я глубоко убежден, что начинать эти работы следует с разработки и утверждения бюджета проекта. Этот документ первичен. В случае если бюджет проекта не разработан и не согласован с руководством банка, вся остальная работа будет представлять собой ни что иное, как удовлетворение собственного профессионального любопытства за счет работодателя.

При составлении бюджета проекта необходимо помнить, что внедрение САБ – решение комплексное, подразумевающее изменение в структуре аппаратных средств, средств телекоммуникаций и (о чем очень часто стыдливо умалчивают) приобретение лицензий на системное и инструментальное программное обеспечение. Затраты по этим статьям в результате могут быть сравнимы со стоимостью лицензии САБ.

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

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

Получив некоторые оценочные значения, следует заложить в бюджет коэффициент запаса, который, в зависимости от степени риска проекта должен составлять от 10 до 30 % от требуемого объема финансирования. Я не могу порекомендовать какую то единую методику вычисления коэффициента запаса, во многом выбор его – это вопрос Вашего практического опыта и интуиции.

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

Зачем это надо? Не мне Вам, как менеджерам, ответственным за информационные технологии в банке объяснять, что принятие бюджета на информационные технологии в большинстве случаев весьма похоже на ведение боевых действий. В рамках этих боевых действий Вам и стоить строить кампанию по внедрению новой САБ. Начинать боевые действия следует на позициях максимального варианта бюджета. Ценой длительных и затяжных боев вы можете сместиться (или будете оттеснены) на заранее подготовленные позиции так называемого оптимального варианта. Как правило, стороны к тому моменту уже достаточно серьезно измотаны боевыми действиями по согласованию бюджета, поэтому зачастую именно этот вариант принимается в качестве долгожданного мирного соглашения. Однако, если боевые действия продолжаются – минимальный вариант бюджета – это тот рубеж, оказавшись на котором Вам следует безоговорочно капитулировать перед превосходящими силами и отказаться от внедрения новой САБ, потому что с таким объемом финансирования внедрение новой САБ будет равносильно самоубийству, причем в весьма извращенной форме.

Итак, примерный бюджет на реализацию проекта составлен, и после долгих хождений по мукам он согласован с руководством банка.

Теперь следует, опять таки в тесном сотрудничестве с поставщиком подготовить проект плана-графика внедрения САБ. При составлении плана-графика рекомендуется ориентироваться на наиболее плохой вариант развития событий, так как компьютеры, заказанные под проект, запросто могут застрять на таможне, при подготовке тестового, а затем и рабочего сервера могут возникнуть совершенно неожиданные проблемы совместимости программного обеспечения и так далее. Иными словами, рекомендую оставлять время на локализацию и ликвидацию неожиданных проблем. Размеры запаса также определяются Вашим опытом и интуицией. Не следует действовать согласно шутливым рекомендациям Фокса и Йордона. По мнению этих авторов «…при оценке продолжительности реализации проекта следует полученную путем предварительных оценок продолжительность перевести в следующую категорию времени и прибавить к ней 2» Например, если проект по Вашим оценкам реализуем за 3 месяца, то декларировать его продолжительность следует как 5 кварталов.

Что касается непосредственно процедуры планирования, на мой взгляд, в этой области ничего лучше классической диаграммы Ганта пока не существует. Программных средств осуществления проектного планирования великое множество, в качестве примера можно привести Microsoft Project. Да и описание методов использования технологических средств управления проектами выходит за рамки данной статьи.

Точно также как и бюджет, план-график должен быть согласован с руководством банка. Не стоит на данном этапе добиваться его утверждения, поскольку у Вас только первичная версия этого плана, которая впоследствии может быть изменена при заключении контракта, но руководство банка должно быть осведомлено о предполагаемых сроках реализации проекта, чтобы сроки исполнения заключенного контракта не явились для них полной неожиданностью.

Теперь пришла пора приступить к заключению контрактов как с поставщиком САБ, так и на поставку необходимых для реализации проекта аппаратных средств, средств телекоммуникаций и программного обеспечения. Этому и посвящен следующий раздел статьи.

Заключение контракта

Это один из важнейших этапов внедрения САБ в банке, как ни парадоксально это звучит. К сожалению именно этому этапу внедрения зачастую уделяется недостаточно внимания, а значит, существенно растут риски успешного внедрения. К сожалению, специалисты банков уделяют недостаточное внимание нюансам составления контракта, готовы во многом верить устным обещаниям поставщика САБ, за что потом приходится очень дорого расплачиваться. Контракт на поставку и внедрение САБ – это не типовой договор на поставку программного обеспечения, объем серьезного контракта редко меньше, чем несколько десятков листов. Верным признаком недостаточно проработанного контракта является типовой трех или четырех страничный договор.

Я постараюсь рассмотреть некоторые аспекты, которым при заключении контракта рекомендуется уделить пристальное внимание.

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

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

Проблемой может также явиться (и мне известно множество примеров, где это так и было) слабый контроль действий поставщика со стороны банка. В качестве одной из мер я предлагаю жестко фиксировать в контракте согласование с банком большинства действий поставщика.

В разделе санкций обязательно должна быть определена ответственность поставщика (лучше в форме штрафных санкций) за задержку внедрения по вине компании. Как минимум должны быть четко определены процедуры определения и согласования причин задержек, виновной в задержке стороны и перенесения работ. Контракт также должен однозначно определять предельные сроки и предельную стоимость проведения работ. Особенно это важно при заключении контракта, в котором нет четкой фиксации общей суммы соглашения, например, когда командировочные затраты поставщика компенсируются на основании отдельных счетов.

Идеальный вариант, если в контракте предусмотрен механизм возврата всех лицензионных платежей при провале или существенной задержке внедрения. Следует отметить, что поставщики идут на это крайне неохотно. Мне ни разу не удалось согласовать в контракте подобные условия, хотя подобного рода прецеденты мне известны.

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

Большое количество проблем по моему опыту при проведении внедрения возникает из-за отсутствия однозначной трактовки критериев успеха при завершении этапов контракта. Поэтому контракт должен содержать укрупненный план-график реализации проекта внедрения (вот где пригодится тот план-график, который Вы заранее приготовили) с обязательным определением критериев успешного завершения каждого ключевого этапа проекта. Типовой набор шагов проекта таков: поставка системы, установка тестовой системы, настройка тестовой системы, импорт данных из существующей САБ, опытная эксплуатация, приемка системы пользователями, прием системы в промышленную эксплуатацию. Ни в коем случае не следует идти на поводу у поставщика, который иногда старается ограничить контракт на внедрение поставкой системы, или установкой системы в опытную эксплуатацию. Внедрение должно завершаться передачей системы в промышленную эксплуатацию в полном объеме.

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

И, в заключение, несколько мелких замечаний. Не стесняйтесь торговаться с поставщиком. Даже цена, объявленная на тендере допускает корректировку, причем не только в сторону увеличения. Также не стоит забывать о том, что современные САБ – системы модульные, поэтому, во избежание неприятных для банка сюрпризов, четко согласуйте и зафиксируйте в контракте список поставляемых модулей и покрываемый этими модулями функционал.

Учет перечисленных критериев на этапе заключения контракта позволит существенно снизить риски внедрения и определить изначально прозрачные условия игры как для банка, так и для поставщика.

Реализация проекта

Параллельно с началом работ по разработке и согласованию контракта следует инициировать работы по формированию команды специалистов банка, ответственных за внедрение САБ. Это могут быть специалисты, принимавшие участие в выборе системы, но зачастую состав этой команды существенным образом отличается от состава группы специалистов банка, выбиравших систему.

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

Члены команды внедрения должны обладать соответствующими знаниями и полномочиями в своих профессиональных областях для принятия решений, связанных с внедрением САБ в области их функциональных обязанностей. Ничто так не затягивает процесс внедрения, как бесконечные согласования действий одного или нескольких членов команды внедрения со своим непосредственным руководством.

Персональный состав команды внедрения с перечнем функций каждого из членов команды должен быть зафиксирован приказом по банку, для придания команде внедрения соответствующего официального статуса. Хорошим стимулирующим фактором для работы над внедрением САБ является увеличение вознаграждения непосредственным участникам команды внедрения.

Команда готова, контракт заключен. Что дальше?

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

В процессах поставки, установки и настройки тестовой версии, на мой взгляд, нет ничего достойного упоминания в рамках этой статьи.

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

Зачастую, для сокращения сроков реализации проекта внедрения, проще всего остановиться только на импорте текущих данных. Как правило, поставщик будет настаивать именно на этом варианте. Аргументы вероятнее всего будут таковы: «план-график внедрения и так достаточно напряжен, а импорт истории можно осуществить потом, после завершения внедрения в гораздо более спокойной обстановке». Если сроки проекта позволяют, я Вам настоятельно не рекомендую идти на поводу у поставщика. Мой опыт показывает, что ни один из известных мне проектов, в которых импорт истории был отложен «на потом», до завершения импорта истории так и не дошел.

На этом можно перейти к вопросам, посвященным опытной эксплуатации.

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

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

Заключение

Естественно, что я привел далеко не все соображения, касающиеся вопросов реализации внедрения САБ, на эту тему можно написать очень много, но, к сожалению, я ограничен объемом статьи, да и злоупотреблять вниманием уважаемых читателей не хочется.

Разумеется, что многие могут счесть данную статью набором общеизвестной информации, с такой постановкой вопроса сложно не согласиться, принципы реализации проектов внедрения программного обеспечения общеизвестны, однако, я ни разу не видел краткого, сублимированного изложения основных, на мой взгляд, подводных камней процесса внедрения САБ.