"Ингосстрах" : от собственных разработок к коммерческим продуктам

"Ингосстрах" : от собственных разработок - к коммерческим продуктам

     ПРОЕКТЫ

Одна из важных тенденций сегодняшнего дня в области ИТ-обеспечения бизнеса крупных и средних предприятий выражается в том, что наращивающие обороты компании, стремясь адаптироваться к изменяющимся рыночным условиям и обеспечить себе конкурентоспособность, все чаще отказываются от поддержки и использования доморощенных корпоративных информационных систем и приложений (зачастую созданных много лет назад) в пользу коммерческих продуктов. Во многом этому способствует расширение спектра предложений со стороны грандов в сфере разработки корпоративного ПО, адаптирующих свои решения под специфические нужды вертикальных рынков. Развитие корпоративной информационной системы ОСАО "Ингосстрах" - один из примеров эволюции от собственных разработок на основе СУБД корпорации Oracle к ее же бизнес-приложениям. Заметим, что на российском страховом рынке Oracle не новичок - ее продукты уже работают в "Росгосстрахе" (Oracle Financial Analyzer), "АльфаСтраховании" (Oracle E-Business Suite - OEBS), "1-й Страховой компании" и "Югории" (OEBS + Oracle FSA) и ряде других страховых компаний, но проект в "Ингосстрахе", о котором далее пойдет речь, в данном ряду особенный ввиду его масштабов (по итогам финансового 2006 года "Ингосстрах" стал крупнейшим клиентом Oracle на нашем страховом рынке).

Предыстория проекта

Еще недавно для решения почти всех задач по поддержке бизнеса в "Ингосстрахе" служила информационная система собственной разработки - АИС "Ингосстрах", построенная на основе СУБД Oracle (в качестве средства разработки использовался Delphi). Система создавалась с середины 90-х годов и к 2004-му охватила практически все сферы деятельности компании: собственно страховой бизнес и обеспечивающий блок - учетно-финансовую деятельность, хозяйственную и др. Единственная программа стороннего разработчика, широко используемая в "Ингосстрахе", - это продукт компании "Диасофт" (с IV квартала 2005-го это Master Insurance), с помощью которого был автоматизирован бухгалтерский учет в филиалах и дочерних фирмах страховой компании.

"Ставка на программный продукт собственной разработки во многом была связана с отсутствием на российском рынке в середине 90-х годов полноценных решений для страховых компаний, - пояснил Андрей Харитонов, директор по информационным технологиям ОСАО "Ингосстрах". - Те немногие программы отечественных поставщиков, что были тогда представлены, автоматизировали лишь отдельные направления бизнеса, а коммерческие страховые продукты западных разработчиков не были локализованы под наши реалии".

Андрей Харитонов: “В ближайшем

 будущеммы планируем распространить

 единую КИС “Ингосстраха” на филиалы”

Но к середине 2004-го года выросшие масштабы бизнеса "Ингосстраха", рост российского страхового рынка (в частности, в связи с введением такого массового вида обязательного страхования, как ОСАГО) и рост конкуренции на этом рынке сделали актуальной задачу модернизации КИС. Для анализа возможностей АИС "Ингосстрах" и разработки возможного плана перехода на новую систему в 2004 г. была привлечена фирма Accenture. Изучив результаты проведенного ею исследования, руководство компании приняло решение сосредоточить усилия своих ИТ-специалистов и разработчиков на развитии и сопровождении АИС "Ингосстрах" в той ее части, которая поддерживает собственно страховую деятельность компании, а информационное обеспечение всего остального (отчетность, бюджетирование, финансовая система) осуществить с помощью решений от поставщиков специализированного ПО. Ситуация на рынке коммерческих программных продуктов для страховых компаний к этому времени изменилась в лучшую сторону - появились отечественные продукты хорошего уровня, а западные вендоры адаптировали свои программы под российские условия.

На пути к новой ИС

Прежде чем приступить к реализации проекта, "Ингосстрах" провел серию тендеров, первый из которых был посвящен выбору платформы для разработки новой ИС. В нем приняли участие компании Oracle, SAP и Microsoft, причем, по признанию г-на Харитонова, изначально всерьез изучались только платформы от SAP и Oracle. Выбор остановили на корпорации Oracle, потому что, во-первых, тем самым во многом снималась проблема интеграции с основной АИС, которая должна была служить ядром КИС и поддерживать профильную деятельность компании. Во-вторых, по мнению директора по ИТ "Ингосстраха", решения SAP все-таки больше ориентированы на промышленность, в то время как продукты Oracle - на финансовые институты. В-третьих, большое значение придавалось возможности использовать лучший мировой опыт, реализованный, по мнению специалистов "Ингосстраха", в продуктах Oracle. Наконец, четвертое соображение касалось набора модулей, которым предполагалось закрыть требуемую функциональность. "При анализе приложений SAP было выяснено, что количество модулей достаточно велико, а вот КПД каждого модуля (с точки зрения востребованности бизнесом заложенных в каждом из них функций), как нам показалось, не очень высок, - пояснил выбор компании Андрей Харитонов. - Хотя я не исключаю вероятности того, что если бы мы остановились на продуктах SAP, эта функциональность в дальнейшем была бы востребована. Что касается продуктов Oracle, то КПД программных продуктов (может быть, в силу того, что они больше "заточены" под финансовые институты), на наш взгляд, был выше".

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

Последующие тендеры проводились с целью выбора конкретного программного продукта по каждому из четырех проектов в рамках модернизации КИС, предполагавших создание единого хранилища корпоративных данных для формирования управленческой отчетности и расчета страховых резервов, новой системы бюджетирования, финансово-учетной системы и, наконец, системы управления взаимоотношениями с клиентами. Кстати, в тендере на разработку финансово-учетной системы наряду с западными приняли участие и отечественные разработчики: "Галактика" и "Диасофт". И хотя решение Master Insurance компании "Диасофт" и сейчас работает в "Ингосстрахе", выбор все по тем же причинам, о которых мы упомянули, был сделан в пользу Oracle E-Business Suite.

Четыре проекта в рамках построения единой КИС

На данный момент проекты, реализуемые в ходе построения новой КИС "Ингосстраха", находятся на разной стадии.

На основе Oracle Financial Service Application (OFSA) уже создано единое хранилище корпоративных данных для формирования управленческой отчетности и расчета страховых резервов в масштабах всей компании. Его запуск в эксплуатацию запланирован на IV квартал текущего года, но уже сейчас в системе сформировано более 80 отчетов по 400 показателям, для каждого из которых разработана и утверждена методика расчета (это, как утверждают специалисты "Ингосстраха", привело к значительному снижению трудоемкости и времени подготовки отчетов).

Проект создания новой системы бюджетирования реализуется на основе Oracle Financial Analyzer (OFA). Промышленная эксплуатация системы в полном объеме будет проводиться при формировании бюджета 2007 г., которое начнется в октябре, но она уже используется для корректировки бюджета компании на второе полугодие нынешнего года.

Новая финансовая система базируется на Oracle E-Business Suite (OEBS). Цель данного проекта - обеспечение возможности сводного учета (РСБУ, МСФО, налоговый, управленческий учет) по всем видам деятельности. По состоянию на сентябрь определены требования к новой финансовой системе и состав доработок, необходимых для учета специфики работы "Ингосстраха", осуществляется настройка системы. Развертывание системы запланировано на январь 2007 г.

Интересно, что в ближайшие два года OEBS (в региональном варианте, т.е. с учетом специфики работы филиалов, предполагающей, в частности, минимизацию трафика по каналам связи с центральным офисом, поддержку пула специальной региональной отчетности) должна заменить в филиалах компании продукт Master Insurance (он установлен на отдельном сервере в центре, а регионы работают с ним в режиме тонкого клиента). По словам Андрея Харитонова, функциональность и качество MI вполне устраивают компанию, и планируемая замена данного продукта связана с другим аспектом - необходимостью снижения рисков развития КИС и соответственно бизнес-рисков такой крупной компании, как "Ингосстрах". Уже к концу текущего года должны быть подготовлены два пилотных проекта по установке OEBS в двух филиалах с двумя типами каналов: "медленным" (по протоколу ADSL) - с калужским филиалом, "быстрым" (по оптоволоконной линии) - с петербургским. Они будут тестироваться почти весь следующий год (до IV квартала). В последнем квартале 2007-го будет подготовлен план перехода на OEBS и начнется сам переход, с тем чтобы уже с января - февраля 2008-го во всех филиалах перейти на продукт Oracle. В дочерних компаниях будет продолжать работать Master Insurance, но в перспективе возможна замена на OEBS и там.

И наконец, последний проект в рамках модернизации КИС "Ингосстраха" - построение системы управления взаимоотношениями с клиентами на основе Oracle Siebel CRM (это первое внедрение Oracle Siebel CRM на территории СНГ после слияния Oracle и Siebel). Цель проекта (он находится на стадии проработки функциональных требований к системе) - снижение издержек обслуживания клиентов (как физических, так и юридических лиц).

В планах компании на ближайшие несколько лет - построение системы логистического учета, а также системы управления и развития карьеры.

Проблемы внедрения

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

Как отмечает г-н Харитонов, одна из проблем общего характера связана с тем, что внедряется законченный продукт с заложенной в нем логикой бизнес-процессов, изменение которой приводит к утрате продуктом его ценности (и это нужно было понять и принять бизнес-подразделениям). Образно говоря, в Oracle CRM Siebel при желании можно реализовать функционал АИС "Ингосстрах", но тогда он перестанет быть Oracle CRM Siebel, а станет АИС "Ингосстрах", переписанной на другом языке. Вместе с тем некоторая кастомизация, т. е. настройка продукта под бизнес компании, неизбежна, и здесь важно соблюсти баланс между текущими потребностями бизнеса и необходимостью сохранить в основном логику бизнес-процессов внедряемого продукта, поэтому степень кастомизации продукта должна быть ограничена.

Вторая существенная проблема - построение правильных интерфейсов обмена между модулями КИС (передача данных из одной базы данных в другую, вызов функций, интерфейсные таблицы). Идеальный вариант решения этой задачи - выбор архитектуры "звезда", когда в центре ИС стоит единая платформа (в данном проекте - АИС "Ингосстрах" и общее хранилище данных), причем каждый модуль корпоративной системы имеет интерфейс только с центральной платформой, и обмен данными происходит исключительно через нее. Именно к такой архитектуре стремятся специалисты "Ингосстраха" и компаний, участвующих во внедрении продуктов Oracle в рамках программы построения новой КИС, но по объективным причинам это не всегда возможно и целесообразно. Есть отдельные случаи, когда обмен данными между модулями через АИС "Ингосстрах" и единое хранилище данных нецелесообразен (например, передача данных о планируемых затратах из системы бюджетирования OFA в финансовую систему OEBS с целью контроля затрат), и в этом случае строятся интерфейсы между модулями.

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

"На этапе выработки функциональных требований со стороны внутреннего заказчика очень важна роль представителей исполнителя - консультантов, которые должны объяснять сотрудникам бизнес-подразделений, каким образом те или иные задачи бизнеса можно реализовать с помощью логики, заложенной во внедряемом продукте стандартной конфигурации, - отмечает также Андрей Харитонов. - Одна из ошибок консультантов по внедрению на данном этапе - излишняя уступчивость по отношению к представителям заказчика ("как хотите, так и сделаем"). В результате возникают завышенные ожидания со стороны бизнес-подразделений, на почве которых вполне вероятны конфликты, если впоследствии окажется, что требуемое изменение приведет к существенному изменению бизнес-логики продукта и существенной же потере его ценности, против чего начнут возражать бизнес-аналитики партнера, помогающего внедрять продукт. Для разрешения конфликтной ситуации бывает целесообразно подключение специалистов департамента ИТ. Основная трудность миссии специалиста в данном случае - "комплекс второй системы", когда в ответ на соображения отказаться от требуемых изменений он слышит возражения, что ведь в АИС "Ингосстрах" это было реализовано. Опыт показывает, что таких конфликтных ситуаций можно избежать, если консультант хорошо знает бизнес-модель, заложенную во внедряемом продукте, и может на стадии выработки функциональных требований доступно объяснить сотрудникам бизнес-подразделений, как воспользоваться стандартной функциональностью для реализации нестандартных бизнес-задач. На следующем же этапе проекта важна четкость следования технологии внедрения продукта, прописанной в соответствующей документации (в случае с Oracle - это Application Implementation Method, AIM)".

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

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

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

Что касается проекта Oracle CRM Siebel, то данный проект, как уже говорилось выше, находится на стадии формирования функциональных требований, поэтому уровень необходимых доработок еще неизвестен. Вообще, по мнению Андрея Харитонова, доработкой может быть затронуто не более 10, максимум 15% стандартной системы, что позволит в будущем развивать ИС, следуя за новыми версиями продуктов Oracle.

Партнеры по проектам

Характерно, что по всем четырем проектам, о которых идет речь, исполнителями выступают разные компании - партнеры Oracle. Систему формирования управленческой отчетности и расчета страховых резервов внедряет компания РДТЕХ (www.rdtex.ru), систему бюджетирования - TopS BI (www.topsbi.ru), OEBS - "Борлас" (www.borlas.ru), Oracle Siebel CRM - Sputnik Labs (www.spklabs.com). Как пояснил Андрей Харитонов, связано это, во-первых, с тем обстоятельством, что универсального партнера Oracle, способного одинаково качественно выполнить все разноплановые проекты, просто нет. Во-вторых, даже если бы такой партнер нашелся, "Ингосстрах" все равно не стал бы сотрудничать с одной компанией, поскольку возникает риск слишком большой зависимости от исполнителя. Можно также предположить, что в условиях дефицита специалистов на рынке вряд ли, наверное, нашлась бы компания - партнер Oracle, способная выделить на такой масштабный проект и на такой длительный период (сроки окончательного завершения проекта пока не обозначены) необходимое количество специалистов.

Версия для печати