В этой статье мы поделимся неудачным опытом внедрения «страховой IT-системы» в одной крупной украинской страховой компании с иностранными инвестициями, которая в 2008 году входила в ТОП-5 крупнейших страховщиков.
Как все начиналось
Страховая компания, основана в 1992 году. Компания быстро росла, успешно развивалась за счет личных качеств руководителей, специфики «тогдашнего» рынка и удачно найденной ниши, которая и приносила основной доход. «Технология продаж» была очень простой и незамысловатой – то, что называется «бумажная». Из «IT» помощников – печатная машинка, база данных – папка с договорами.
Но компания росла, через год уже 19 филиалов. Вопрос автоматизации деятельности назрел и разрешился созданием IT-отдела и внедрением самонаписанной страховой системы. В качестве платформы была выбрана «FoxPro» компании «Fox Technologies» (в 1992 году «Fox Technologies» объединяется с «Microsoft»). Страховая система развивалась вместе с компанией и, на тот момент, отлично выполняла свои функции с точки зрения скорости ввода в систему новых продуктов и возможности наладить общий учет продаж.
Система устанавливалась как приложение на каждом рабочем месте. Файлы базы данных, в пределах офиса (локальной сети), находились на локальном файловом сервере. Проблема работы приложения в филиалах решалась очень просто - у каждого филиала была своя база данных. Кроме того, партнеры компании (банки и страховые агенты, некоторые автопредприятия и т.д.) имели версии такого приложения, специально собранные под специфические страховые продукты, продаваемые партнером.
Раз в месяц, данные из филиалов (иногда партнеров) привозились на дискетке в головной офис, и специальный отдел занимался синхронизацией этих данных с центральной базой. Казалось бы все просто отлично…
Но! Обнаруживаются «некоторые недостатки» (все перечислять не будем):
1. С ростом персонала усиливается проблема обслуживания каждого рабочего места (установка новых версий при внедрении нового продукта или изменения параметров уже внедренных продуктов)
2. Вводимые данные с одного рабочего места могут противоречить (а это так и происходит) данным введенным с другого потому, что (например):
1. Справочники обновляются не синхронно.
2. Проверить централизованно вводимую информацию (например: есть ли в системе такой клиент) невозможно.
3. Оценить реальные результаты деятельности компании за какой-либо период невозможно, слишком большой технологический разрыв, между действием, его отображением в системе и синхронизацией с головной базой данных.
Смена поколений
Как Каждый Охотник Желает Знать, Где Сидит Фазан, так и любому руководителю хочется знать, как обстоят дела в его бизнесе на самом деле. Исходя из этого, и в силу новой моды (необходимости) на объединения с иностранными компаниями, которые в знании реальной картины происходящего еще больше заинтересованы, в 2007 решено пройти IT-аудит. В числе прочих мер по «оптимизации» были даны рекомендации внедрить CRM и/или «промышленную» страховую систему, которая не будет иметь недостатков старой, и позволит:
1. Повысить качество вводимых данных.
2. Моментально выводить текущие отчеты.
3. Проводить анализ текущей деятельности и по их результатам быстро реагировать на потребности рынка.
4. Анализировать текущие риски, которые несет компания в каждый момент времени.
5. Снизить затраты на сопровождения за счет централизации
И т.д.
Итак, по итогам тендера, была выбрана страховая система одного из западных производителей. На результат тендера повлияла:
1. Стоимость лицензии на продукт (достаточно высокая, но не заоблачная для страховой компании такого масштаба)
2. На тот момент - факт внедрения в одной из страховых компаний Украины «А»
3. Факт начала процесса внедрения в другой украинской страховой компании «Б»
4. Факт работы системы в крупной страховой компании в стране производителя «В»
5. Обещание «быстрого» внедрения (в течение 6-7 месяцев)
6. Наличие отечественного «партнера-внедренца»
7. Возможность прохождения обучения в офисе производителя специалистов страховой компании
8. Наличие в системе встроенной поддержки разработки самой системы
Так как новая «концепция» развития страховой компании на тот момент была понятна, цели и средства достижения были определены - старая страховая система в эти планы не вписывалась, и ее развитие было прекращено.
Коллектив, как говорят «сел трудовую вахту», кто-то поехал за границу обучаться «новому». В их составе и Ваш покорный слуга. В процессе обучения выяснилось, что:
1. Система ориентирована на «западный» стиль страхования и не учитывает украинские реалии. В связи с этим предложено «работать как на западе», т.е. полностью сломать сложившийся бизнес-процесс.
2. Некоторые модули, например, на то время урегулирование, существуют только в проекте, а некоторые, движение бланков строгой отчетности – даже не предполагались.
3. Система встроенной поддержки разработки самими разработчиками используется нерегулярно, отчего ее ценность выглядит весьма сомнительно.
4. Интерфейс для операторов системы оригинален и универсален, но и, в связи с этим громоздок и неудобен. Правда, еще тогда производитель разработал альтернативную, упрощенную систему ввода данных, но общему состоянию юзабилити, это не очень помогло.
Это не все проблемы, которые выявились на этапе обучения, но надежда на завершение пилотного проекта в срок еще оставались.
Не осталось надежды на то, что страховая компания сама в состоянии сопровождать и развивать страховую систему.
Драку заказывали? Нет? – Уплачено!
Вопрос, отказаться ли при таких новых открывшихся обстоятельствах от проекта уже не стоял – деньги потрачены, и немалые. «Внедренцы» принимают на работу новый персонал, специально под проект. Понятно, что вновь принятые сотрудники внедряющей организации о самой внедряемой страховой системе имеют весьма приблизительное представление, но обещание и реклама некоторых местных «агентов» уважаемой заграничной фирмы делают свое дело. Проект продолжается… «Внедренцы» учатся на ходу и делают немало просчетов. Вместо параметризируемых процедур почти для каждого отдельного случая пишутся новые – так быстрее и проще. В результате система становиться плохо управляемая, запутанная и непонятная. В ней может разобраться только непосредственные участники сего действа. Слово «документация» повергает в шок!
На многие требование страховой компании два ответа:
1. В данной системе это невозможно
2. Может быть, сделаем, когда-нибудь
Ввод страховых продуктов в систему растягивается на месяцы, а что же будет, когда страховой продукт нужно будет ввести быстро? Сроки не выдерживаются, их переносят на …пол года. Но это только цветочки…
У «внедряющей» организации кончаются деньги. Она не может оплачивать набранный для проекта штат. Процесс внедрения переходит в стадию перманентного… «Внедренцам» задерживают, а иногда и не выплачивают зарплату. Более бойкие из них начинают покидать корабль. Пат!
Некоторое оживление происходит, когда «внедренцам» удается протолкнуть подписание так называемых «доп-работ» и таким образом получить часть зарплаты. Чайник на время вскипает!
… А в это время продолжает работать старая, добрая, на FoxPro написанная система. И, оказывается, не такая она уже и плохая. Во всяком случае, заявленные функции выполняет. И учет как-то, худо-бедно ведется.
Вести с линии фронта.
Неужели мы такие невезучие, неужели у нас так все плохо? Неужели мы особенные – думала страховая компания и отправила в разведчиков в тыл к другим страховым компаниям, имеющим особенное счастье внедрять у себя тот же продукт (помните, как принималось решение о внедрении?).
Вот разведданные:
1. В стране производителя сам производитель этого продукта является оператором своей же страховой системы для страховой компании «В», что ее купила! Т.е. страховая компания не в состоянии сама ее использовать!?
2. Первая украинская страховая компания «А», что внедрила у себя это чудо, отказалась от его использования.
3. Вторая страховая компания «Б», где внедрение происходило параллельно с нашей, вступило в фазу «промышленной эксплуатации». Из множества заказанных отчетов работают 3 (три!). Но самое главное, страховая система не поддерживается, ни производителем, ни «внедренцем» и страховая компания пытается внешними приложениями восполнять пробелы. (Правда, не признаваясь в этом напрямую).
Короткие перебежки
История на этом не кончается. История становится все увлекательней.
Помните страховую компанию «Б» где продукт больше не поддерживается? И знаете почему? Потому что наша компания переманила к себе «главного внедренца» этого продукта. А что делать!? Надо спасать инвестиции! Не могу не отметить радость в рядах сотрудников компании «Б», которые избавились от «главного внедренца». Вопрос «почему» отпал сразу после появления нового сотрудника в наших рядах. Главным методом внедрения оказалось не удовлетворение «потребностей» страховой компании, а подгонка требований под возможности «продукта». Знакомая картина, не правда-ли? А так как требования выдвигают люди, то с них надо и начинать. Так с легкой руки «нового руководителя проекта», команда, работавшая над внедрением и смевшая выдвигать требования к продукту, была уволена.
Решение было принято уже новым «иностранным» руководством нашей компании, видимо считающей, что неудача с внедрением связана с некомпетентностью старой команды страховой компании.
Кровати переставлены!
Итак, пусть свободен новая команда «внедряет» продукт изо всех сил. Пишет бумаги и отчеты. Общается с начальством. Говорит о сложностях внедрения. Подсчитывает человеко-часы. Подтверждает, что система «может все», но… виноватых уже уволили, а проект двигается не быстрее черепахи.
… А тем временем… Компания теряет рынок. Работники уходят из компании целыми филиалами вместе с портфелем клиентов.
Ситуация, когда старая система уже не работает, а новая еще не работает не из приятных. Начальство срочно ищет выход из ситуации и находит его!
Оказывается, есть программа под названием EXCEL! Всем работникам срочно поручено выучить этот программный продукт! Теперь страховая система стоимостью, обозначенную семизначной цифрой в евро, не считая аппаратной части, будет служить «единой базой данных», а необходимые функции и отчеты будут создаваться с помощью MS ECXEL! Мудрое, мудрое решение!
Кто виноват?
Столь драматичный стиль повествования выбран не случайно! Хотелось предостеречь страховые компании от такого сценария внедрения страховых систем.
Ошибки, совершенные нами в этом процессе теперь весьма очевидны:
1. При выборе производителя программного продукта поверили в рекламу заинтересованных лиц (имеется ввиду лиц заинтересованных в самом процессе внедрения, а не в конечном результате) – и это были в основном слова, что система может все. Никакой демонстрации, что система может хоть что-нибудь, не было.
2. В момент выбора не было четкого понимания, чего же мы хотим от страховой системы, не говоря уже о четком плане и техническом задании.
3. С разработчиком был заключен договор только на покупку лицензии. Договор на внедрение был заключен с местной компанией. В итоге получилось, что ответственность за внедрение «несла» только местная «внедренческая компания». У нее всегда была отговорка, что разработчик не предусмотрел ни того, ни другого, а влиять на разработчика никакой возможности не было.
4. Страховая система создавалась разработчиком под конкретную зарубежную страховую компанию. Решение о тиражировании страховой системы производителем было принято тогда, когда было поздно менять идеологию и архитектуру (мое личное мнение). Законодательство и практика у нас и на западе сильно отличаются. Практически мы сами сломали свой бизнес-процесс, пытаясь перекроить неподходящую выкройку.
5. Мы посчитали западных аналитиков умнее своих (воистину нет пророка в своем отечестве), хоть эта иллюзия быстро рассеялась – было уже поздно.
Что делать?
1. Не повторять наших ошибок.
2. Старайтесь, по возможности идти эволюционным путем, не прибегая к революции с непредсказуемыми последствиями – так вы сохраните бизнес-процесс в рабочем состоянии в период модернизации, если вы решили что она нужна.
3. Знайте, что кроме выкладок «специалистов», готовых продать вам «новые» дорогие «просто для вас необходимые технологии», есть еще и здравый смысл.
4. Присмотритесь к своим сотрудникам, возможно среди них есть то, что вы ищете на стороне, т.е. специалисты готовые осуществить ваши идеи модернизации. Они уже «в теме», знают нюансы бизнеса и стоят меньше чем приглашенные «звезды».
5. Не гонитесь за новыми технологиями, потому что они новые. Оцените их эффективность для вашей компании.
6. Не всегда новые технологии дорогие и сложные. Наоборот – новое должно быть качественным, простым и понятным. Принцип: все гениальное просто – работает. Так вы сэкономите средства и время на внедрении, обучении сотрудников и сопровождении, а значит, и получите конкурентные преимущества, особенно среди тех, кто ввязывается в дорогущие, продолжительные, сложные проекты, и использует потом 5% их возможностей.
Источник: forINSURER.com
