Главная | Обратная связь | Поможем написать вашу работу!

ЧАСТЬ 5. Тютюник А.В., Шевелев А.С. Информационные технологии в банке – М.: Издательская группа «БДЦ-пресс», 2003. – 368 с.

Глава 1. Выбор решений

Организация процесса выбора системы

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

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

Основными этапами выбора АБС являются проведение тендера на
выбор системы и заключение контракта.

Приведем аргументы в пользу тендерной формы выбора системы:

— независимость и относительная объективность решения (посредством тендера оценивается максимальное количество решений, и в этом
процессе участвуют многие специалисты банка, а иногда и привлечен
ные эксперты и консультанты;

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

— быстрота выбора (использование тендера на основе правильных методик позволяет существенно сократить общее время от начала вы-
бора до окончательного решения, что немаловажно, так как процесс
выбора системы может длиться от нескольких месяцев до года и более,
то есть составлять от 10 до 40% всего времени замены старой системы
на новую).

Проведение тендера

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

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

Рассмотрим этапы проведения тендера.

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

- правила (методику) проведения и подсчета результатов;

- приглашение на участие в тендере, которое будет рассылаться учас-
тникам;

- анкета участника тендера (должна быть заполнена и возвращена
вместе с подтверждением участия).

На этом этапе необходимо утвердить основные подходы к проведе-
нию процедуры тендера.

Второй этап — формирование расширенного списка участников
(Long List) и рассылка приглашений (Invitation to Tender). Для выбора
потенциальных участников тендера осуществляется анализ существу-
ющих поставщиков программных продуктов на предмет целесообраз-
ности включения их в тендерный список (предварительный анализ по-
ставщиков и систем на предмет соответствия общим требованиям),
после которого осуществляются определение и утверждение участ-
ников тендера.

Приглашение на участие в тендере содержит:

— общую информацию;

— условия тендера и порядок взаимодействия;

— сроки проведения;

— контактную информацию;

— условия конфиденциальности.

Анкета участника содержит:

— общую информацию о компании (наименование представляемой
системы, год создания, число сотрудников, количество клиентов, пред-
ставительства и партнеры);

— общую информацию о системе (количество внедрений, в том чис-
ле в российских и зарубежных банках, техническая платформа — база
данных, операционная система, требования к серверам и рабочим стан-
циям, архитектура, иностранные языки, поставка лицензий на дополни-
тельное программное обеспечение);

— сведения о функциональности (мультивалютность, ведение бух-
галтерского учета в соответствии с инструкциями ЦБ РФ, поддержка
нескольких планов счетов и международных стандартов учета);

— данные об открытости (возможность импорта данных из внешних
систем, уровень детализации данных при импорте, взаимодействие с
внешними системами);

— среднее время внедрения, примерную стоимость системы и ус-
луг, сведения об организации сопровождения системы.

Третий этап — отбор наиболее предпочтительных систем для де-
тального ознакомления (Short List). На этом этапе компаниям из рас-
ширенного списка, подтвердившим свое участие, передается документ
требований к системе. Далее проводятся ознакомительные показы по,
общим возможностям системы (около 2 — 4 часов на каждую систему).
Участникам дается некоторое время на формирование официального ответа о соответствии их решений представленным банком функцио-
нальным и техническим требованиям.

На основании информации, полученной из анкет участников тенде-
ра, впечатлений от просмотров систем, а также из ответов о соответ-
ствии требованиям осуществляется выбор наиболее предпочтительных
систем для детального ознакомления. Результатом этапа должен стать
список из 3 — 4 систем. Большее количество неудобно из-за существен-
ного увеличения времени изучения, меньшее — потому, что увеличива-
ется риск невключения в детальное изучение действительно подходя-
щей банку системы.

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

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

• степени соответствия бизнес-требованиям банка;

• необходимости в доработке и модификациях предлагаемого решения;

• предварительной стоимости и срокам проведения доработок и мо-
дификаций;

• стоимости системы и стоимости обслуживания/поддержки;

• скрытым издержкам и выгодам от использования системы;

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

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

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

Итоговым результатом должен стать отчет по оценке и анализу сис-
тем с рекомендацией оптимального варианта. На основе отчета с пере-
числением плюсов и минусов каждой из систем руководство банка де-
лает выбор. Такой окончательный выбор, учитывая важность задачи,
обычно осуществляется на заседании правления, где выслушиваются
представители различных подразделений, обсуждаются результаты
взвешенной оценки и стоимостные параметры решений. Можно реко-
мендовать выбирать не только один (оптимальный) вариант (лидер тен-
дера), но и второй (страховочный) вариант — в случае возникновения
проблем с выбранным поставщиком (например, на стадии заключения
контракта) можно будет вступить в переговоры со вторым поставщи-
ком. Выбор двух вариантов можно открыть обеим компаниям, что, бе-
зусловно, пойдет на выгоду банку.

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

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

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

1. Необходимо помнить, что компания будет делать только то, что
записано в контракте.

2. Предполагать негативный сценарий и анализировать контракт с
этой точки зрения.

3. Софтверные компании умеют не только «вспоминать» о не вклю-
ченных в первоначальное предложение услугах и модулях, но и «падать»
в ценах.

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

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

6. Везде, где это только возможно, необходимо включить в контракт
требование об обязательном согласовании с банком действий компа-
нии — поставщика решения.

7. В контракте должны быть предусмотрены санкции за задержку
адаптации или внедрения по вине компании и процедуры определения и
согласования причин задержек или перенесения работ.

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

9. Поддержка российской отчетности, налоговых и прочих требова-
ний должна быть рассмотрена отдельно и детально.

10. Процедура отказа от старой системы должна быть также рас-
смотрена.

11. Необходимо предусмотреть возможность по требованию банка
замены отдельных специалистов или менеджера проекта в случае недостаточной их квалификации или при возникновении сложностей во
взаимоотношениях с ними.

12. Желательно определение предельных сроков и стоимости работ.

13. Нужно включить в контракт процедуры разрешения споров и кон-
фликтных ситуаций.

Если учесть все эти факторы, можно существенно снизить риски,
сопровождающие выбор системы.

Глава 2. Управление ИТ-персоналом

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

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

⇐ Предыдущая 23 24 25 26 272829 30 31 32 Следующая ⇒