Письмо Антона Марреро по созданию единой страховой IT-системы

Уважаемые Господа!

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

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

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

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

Примером может служить следующая ситуация, с которой мы столкнемся, реализовывая проекты для ряда авиационных компаний. Как известно процесс продажи авиабилетов связан с одновременным заполнением страхового полиса. Зачастую 75-90%% (!) времени кассира, оформляющего билет, уходит на заполнение вручную страхового полиса. Автоматизировать процесс не представляется возможным, т.к. у каждого страховщика свой бланк страховой формы и унифицировать его никто не имеет желания. Подобные проблемы могут решаться только совместными усилиями. Вторым примером может служить необходимость ведения общих банков данных (списков), в частности по «подозрительным» страховым случаям и лицам.

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

Разработка программного обеспечения - специфическая проблема. В то время как один специалист утверждает, что способен со всеми задачами справиться средствами MS Excel, другой тратит значительно больше на закупку системы управления базами данных. Но, как и в любом производстве, качественный, надежный и полезный продукт стоит соответственно. Для нас, разработчиков программ, очевидно то, что ни одна из коммерческих страховых компаний на Украине (за исключением «Оранты») не в состоянии собственными силами разработать полноценный программно-технологический комплекс для себя, не говоря о коммерческом продукте.

Вывод 3. Для создания страховой системы необходимы инвестиционные усилия нескольких компаний.

До настоящего момента общий вектор взаимопонимания целей и задач указывает общее направление для всех участников процесса. В момент, когда становится очевидным необходимость выбора организационной схемы для дальнейших действий, выявился «кризис  роста» идеи. Причинами кризиса на наш взгляд есть 4 «Кто»:

1) Кто соберет деньги?

2) Кто разработает систему?

3) Кто будет ее владельцем (следовательно - продавцом)?

4) Кто будет ее обслуживать, сопровождать и развивать?

Вопрос № 1 выделяется особо, т.к. определяющим образом влияет на следующие три вопроса. На сегодняшний день, являясь условно-сторонним наблюдателем процесса появления и обсуждения идей, просматриваем следующие варианты ответов:

1.     Отраслевая Ассоциация (Лига).

2.     Созданное специально для этой цели АО.

3.     Разработчик программного обеспечения.

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

Мы не будем до конца честны, если не признаем, что один реализованный Ассоциацией проект имеет место на Украине. Речь идет о создании внебиржевой системы фондовой торговли (ПФТС) под эгидой Ассоциации Фондовых Торговцев. Тем не менее, это исключение из правила, так как инфраструктура, обеспечение и финансы были представлены в качестве технической помощи USA ID, за ее счет развернуты и запущены. Более того, текущие расходы участников системы также финансировались американцами на протяжении нескольких лет.

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

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

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

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

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

Как и в любом деле, залог успеха и надежности – в простоте, прагматизме и последовательности. Именно на это и ориентируемся.

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

С надеждой на плодотворное и взаимовыгодное сотрудничество,

Генеральный директор «Софтлайн»,

Антон МАРРЕРО

P.S. По результатам предварительного ознакомления с предметной областью годовой бюджет разработки первой промышленной версии системы и ее внедрение на 5¸6-и предприятиях к концу 1999 года составляет порядка 200000 (±30000)$ США. Разброс в цене определяется двумя обстоятельствами – необходимостью уточнения соотношений общих и индивидуальных для каждого из предприятий-инвесторов функций системы и уточнение общего набора функций. Таким образом, для каждого из предприятий взнос составит порядка 30000¸40000$$ США, в зависимости от необходимости учета специфики системы.