Как выбрать IT-подрядчика

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

Анна ПАВЛОВА, руководитель проектов в финансовой сфере, Digital Design, Санкт-Петербург

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

Платформа — прежде всего

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

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

Единственное, что нужно делать обязательно и с самого начала – указывать ту платформу, на которой должно быть разработано решение. Это экономит как время заказчиков, так и усилия IT компаний. В страховых компаниях со сложившейся IT инфраструктурой вопрос о выборе платформы первичен, поскольку это помогает оптимизировать затраты на автоматизацию. Microsoft ориентированные разработчики, скорее всего, не подойдут компаниям, программное обеспечение которых внедрено с использованием СУБД Oracle. Одной из возможных причин отказа от работы с тем или иным подрядчиком может быть невозможность оптимизировать IT структуру с точки зрении количества используемых серверов. У крупных страховых компаний подходы к выбору и установке программного обеспечения прописываются в предварительно разработанной IT стратегии. Они продиктованы, в том числе, требованиями информационной безопасности и величиной бюджета, который может быть выделен на автоматизацию деятельности. Если же особых требований к платформе решения страховой компанией не предъявляется, и она готова рассмотреть несколько вариантов, то дальнейший выбор зависит от способности IT подрядчиков убедить и доказать, что именно их решение будет оптимальным.

«Коробка» или разработка на заказ?

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

Основными преимуществами типовых решений являются:

• невысокая стоимость

• быстрое внедрение (например, «коробочное» решение для СЭД можно внедрить за десять(!) дней)

• наличие настроенных базовых бизнес процессов

• достаточная простота использования.

К недостаткам следует отнести:

• отсутствие кастомизации, то есть «заточки» решения под конкретный бизнес

• не всегда дружественный интерфейс

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

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

• учитываются потребности конкретной компании

• дружественный интерфейс, удобный и понятный каждому сотруднику компании• знакомый бизнесязык, используемый в работе (индивидуально настроенные справочники, база используемых документов и пр.)

• отсутствие лишних модулей, не используемых в работе

• настройка индивидуальных прав доступа в зависимости от функциональной роли сотрудника.

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

Выбор подрядчика

Если внедрение решения затрагивает не всю компанию, а только одно или несколько подразделений или видов бизнеса (например, работа по направлению ДМС или обслуживание VIP клиентов), то нет смысла проводить долгие сложные тендеры. Во первых, в таком случае будет потрачено неоправданно много времени (а его всегда не хватает!). Во вторых, у подразделения, скорее всего, есть полномочия на принятие решений в рамках выделенного бюджета, а необходимость в сложных и длительных согласованиях отсутствует. В таком случае и результат от внедрения можно будет увидеть быстрее, не тратя время на тендеры, а решая конкретные задачи. Сложные IT системы, затрагивающие деятельность нескольких подразделений, а то и всей страховой компании включаются в общий IT бюджет. Решения по покупке в таких случаях принимаются коллегиально и на основе тендера. В число лиц, участвующих в принятии решения, входят:

• непосредственные пользователи системы, чьи бизнес задачи она призвана решить (например, руководители блока по работе с корпоративными, розничными клиентами, службы андеррайтинга и пр.)

• руководители IT подраз делений, выступающие в роли экспертов и определяющие требования к аппаратному и программному обеспечению

• руководители финансового блока, отвечающие за бюджетирование и эффективное осуществление затрат

• руководители службы информационной безопасности

• представители других подразделений (в зависимости от конкретной ситуации).

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

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

• срок существования компании на рынке

• профиль деятельности компании

• наличие успешно реализованных проектов в рассматриваемой области

• наличие сертификатов по системам менеджмента качества

• наличие стандартизированных технологий внедрения рассматриваемого решения

• возможности по обучению работе с системой (в том числе, наличие собственного учебного центра).

Сами системы проверяются как на соответствие предъявляемым к ним общим требованиям заказчика (то есть способности наиболее эффективно решить поставленные бизнес задачи), так и с точки зрения удобства будущих пользователей. Среди критериев отбора отметим следующие:

• возможность видеть всю необходимую для работы информацию

• возможность создавать и редактировать все необходимые документы• возможность настройки бизнес процессов без программирования

• возможность контролировать работу сотрудников, ставить задачи и анализировать результаты их выполнения

• достаточный для работы набор возможностей интерфейса

• удобство ввода информации и проведения операций

• автоматический контроль ввода недопустимых значений (информации)

• эффективное использование справочников и пр.

После презентации каждого решения проектной команде следует заполнить анкеты и провести оценку того или иного решения «по горячим следам» (например, с использованием шкалы от 1 до 5). По итогам выступления всех потенциальных подрядчиков ответственный сотрудник (как правило, это представитель службы IT) формирует итоговую оценку каждого претендента, добавляя в нее свое экспертное мнение, которое касается предъявляемых требований к аппаратно программного обеспечению и наличия у страховой компании соответствующих ресурсов, и представляет результаты руководителю проекта. Немаловажным критерием является и стоимость проекта. Ко второму туру тендера допускаются несколько участников, которые могут сделать экспресс оценку бизнес процессов заказчика, провести консультации с сотрудниками подразделений, которые в будущем будут пользоваться системой. Очень полезным для страховой компании при отборе является возможность референс визитов в те компании, где соответствующие решения уже внедрены участвующими в тендере разработчиками. В таком случае заказчик формирует команду участников референс визита (обычно два три человека), которые посещают компании того же профиля, общаются с пользователями системы, имеют возможность «в живую» посмотреть, как работает IT решение. По итогам референс визитов составляются отчеты. Итоговая оценка подрядчика и предлагаемого решения производится с учетом всех обозначенных моментов, «shortlist» подрядчиков защищается перед руководством или собственниками страховой компании, после чего выбирается победитель.

Завершение проекта и оценка его эффективности

Основными рисками для заказчика при работе с подрядчиком являются:

• риск «затягивания» проекта, выход за согласованные рамки сроков проекта

• риск несоответствия конечного результата заявленным требованиям

• риск возникновения «зависимости» от подрядчика, «подсаживания» на дальнейшее техническое обслуживание и доработки системы.

Задача страховой компании на предпроектном этапе – максимально подробно выяснить методику взаимодействия подрядчика с заказчиками, оговорить все возможные риски и способы их нивелирования, и, безусловно, включить в договор условия об ответственности исполнителя. Чем больше внимание уделяется этим действиям на предпроектной стадии, тем меньше проблем возникает во время внедрения IT системы. Подробное и качественно составленное техническое задание – главный инструмент управления проектными рисками (и, в случае чего, главный источник для поиска ответа на вопрос «кто виноват?»).С другой стороны, повлиять на качество проекта в худшую сторону может и сам заказчик. Негативно отразиться на сроках и результатах внедрения могут следующие факторы:

• недостаточное качество и объем информации, предоставляемой подрядчику

• затягивание сроков внутренних согласований

• смена требований к системе и желаемому результату по ходу реализации проекта

• изменение состава и/или количества ресурсов (как технических, так и трудовых, финансовых и пр.) для полноценной реализации проекта.

Таким образом, обеспечение качества разработки – это двусторонний процесс, который формируют и подрядчик, и заказчик (в данном случае, страховая компания), и желаемый результат можно получить только усилиями обеих сторон. Внедрение можно назвать эффективным тогда, когда соблюдены озвученные сроки проекта, заказчики со стороны страховой компании получили инструмент, которым они могут пользоваться, и он действительно помогает в решении бизнес задач. При согласовании бюджета на решение формируется его экономическое обоснование, рассчитывается срок окупаемости проекта и другие финансовые показатели. Таким образом, целесообразно в контрольных точках отслеживать, выполняются ли поставленные цели, приносит ли IT система заявленные «бенефиты», и окупится ли она за обозначенный срок. В случае несовпадения желаемой и реальной ситуаций имеет смысл, во первых, вовремя обратить на это внимание, а во вторых, разобраться в причинах и определить возможные пути корректив. Среди причин могут быть ошибки разработчиков, которые должны быть исправлены в период гарантийного обслуживания абсолютно бесплатно (обратите внимание, что про гарантийный срок ни в коем случае нельзя забывать!) Кроме того, пользователи системы могут не понимать или не до конца понимать, как работать в системе и как использовать встроенный функционал. В таких случаях может помочь обучение, как внешнее, с привлечением сил того же подрядчика, так и внутреннее, силами сотрудников страховой компании.

Читать статью в pdf формате