История создания стартапа для страхового рынка (кто подхватит упавшее знамя?)

Добрый день, уважаемые Хабравчане!

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

Я недавно я обнаружил, что у меня лежит большое количество реализованных проектов в ящике стола. Большинство программ имеют простое происхождение – приходили клиенты, платили деньги, я разрабатывал для них продукты, внедрял, продавал нескольким похожим клиентам и забывал о них в рутине новых проектов.
При этом многие проекты – это готовые бизнесы. Решил опубликовать несколько публикаций на Хабре с целью найти партнеров, инвесторов или клиентов. Кому-то я могу дать права на реализацию, кому-то готовый бизнес под ключ. А кто-то, возможно, захочет развить данные идеи. Если будет интерес с проектам, и меня не закидают помидорами, то продолжу публикации.

Зачем: Программа «Мобильный Страховой Полис» позволяет в кратчайшие сроки организовать продажу страховых полисов на любом кол-ве удаленных точек по всей стране: филиалах, автосалонах, банках, турфирмах. Автоматизировать сбор данных в центральном офисе страховой компании. С 2006 года программа успешно используется в ряде ведущих страховых компаний Украины, среди которых Инго, Нова, Кредо-Класcик, а также в ОТП-банке. Продажа и сбор данных происходит в филиалах, турфирмах, автосалонах, таможенных переходах на границе, банках-партнерах. Внедрены полисы: ОСАГО, КАСКО, турстрахование, зеленая карта, имущество, несчастный случай.

История создания, или зачем нужно было чего-то делать?

В 2006 году я пытался продать в страховую компанию Инго свою партнерскую программу по GPS (это когда с любого компьютера видно, где находятся и как двигались автомобили). Интерес был вялый. Слово за слово — и я переключился на продажу другого нашего продукта — MobileSOP. Этот продукт внедрен у сотен клиентов на коммуникаторах и КПК для продаж в поле. Показывал продукт, прощупывал почву насчет интереса к программам на коммуникаторах. Особо понравилось будущему клиенту интерфейс программы — «как для дурака». Это сейчас такие сплошь и рядом увидишь на андроидных устройствах, а раньше — перегруженные информацией экраны, со скролирующими полосками… Обучение, обучение и обучение. И тут я со своей идеей внедрения продуктов для тупых, за пару часов. Впрочем, как я выяснил, для страховых продажа на выезде — это было вопрос будущего. И тут наткнулись на РЕАЛЬНУЮ проблему у клиента: организации продаж в партнерских точках. Как пример была приведена туристическая компания, которая должна продавать туристические полисы. Вначале я не понял, неужели нет программы для ввода полиса? Оказалось есть, и не одна! Но ни одна не подходит к установке у партнера! Либо это дорогостоящие лицензии сетевого продукта (типа ORACLE SIEBEl). Установить их на старенькие компьютеры — проблема, сопровождать их удаленно — страшная проблема. Вернее — большие затраты. Другой путь — WEB сервис тоже оказался не панацеей. Во первых — у ряда партнеров нельзя устанавливать онлайн продукты из соображений безопасности. Например, большинство банков не дает. Во вторых — нужно что-то такое легковесное и продуманное, чтобы людям было удобно. Например, поменял галочку «страховать багаж» — и тут же пересчиталась сумма и появились только необходимые поля. «Обычные» продукты (которые имеют ноги как CRM, ERP) — Они обычно делаются форм-ориентированными, т.е. вкладки, вкладки, поля, поля и кнопка рассчитать. А хочется сделать что-то такое приятное — чтобы сразу сотрудник мог СОЗДАВАТЬ и ПОДБИРАТЬ страховой продукт.

— Дорого? Нет проблем! Давайте попробуем поставить больше франшизу. Подходит? Нет? Давайте разобьем платеж..

И, самое главное, чтобы работало ЭТО автономно, в режиме оффлайн, с возможностью передать выписанные полисы по любым каналам связи КУДА-ТО В ЦЕНТР…

— РЕМАРКА 1 — В свое время наша компания делала очень интересный проект для компании Филип-Моррис — сбор информации с переднего фронта продаж и увеличение лояльности розницы. Со стороны ФМ мы сотрудничали с Валентином Кузенковым, ярким и одаренным человеком. Потом — Валентин начал работать сам на себя и делать проекты на аутсорсинг. Мы встретились, он поделился своими проблемами (оутсорсинг — это не развитие, это кусок хлеба) и мы решили на партнерских отношениях сделать какой-либо проект для бизнеса и дать возможность Валентину апробировать некоторые продажные схемы (аренда софта — SAAS и плата за поддержку). Так что я сделал предложение на страховую компанию, по продукту, которого не было, взял на себя обязательства и мы с Валентином полетели. Быстро сделали продукт и быстро запустили в живую работу первую версию. С точки зрения клиента я попробовал минимизировать риски, предложив пилотное внедрение за небольшую сумму. Клиент получал внедрение под ключ, и только потом принимал решение о приобретении лицензий. Т.е. с одной стороны он платил (мы видели заинтересованность), с другой стороны — не нес рисков по покупке. Искренне благодарен за то доверие, что нам оказали. Как мне кажется, мы его оправдали. — КОНЕЦ РЕМАРКИ 1 ---

Продукт получился интересным. С технологической точки зрения за шесть месяцев работы мы создали платформу, в которой весь пользовательский интерфейс был создан при помощи MSHTML. Фактически, ядро программы не содержало кода связанного с UI. Вместо этого сразу же в основном окне поднимался IE ActiveX, которому на вход подавалась HTML-страница которая и отображала пользовательский интерфейс [прочитайте техническую ремарку внизу статьи — все таки большинство Хаброжителей — технические люди]

Платформа позволяет строить разные приложения для финансового сектора, с ориентацией на гибкую логику форм, автокалькуляций сумм и обмена данными. Нам удалось добиться маленького размера продукта (было внутреннее требование, чтобы продукт мог выполняться прямо с флешки), стабильности и приятности для пользователя. Проверка боем у нас была тоже достаточно интенсивной. Мы поставили решение в двух туристических агентствах и наладили бесперебойную работу с передачей информации в страховую. Живьем проект проработал месяц, после чего пилот был признан успешным, мы продали лицензии и продолжили внедрение. Интересно, что внедрения мы делали практически самостоятельно, от разработки методологии ввода полисов, до установки и обучения персонала у партнеров. Т.е. по сути со стороны заказчика он получил не только систему, которая вливала полисы, но также мы сняли все вопросы по поддержке партнеров. В кратчайшие сроки нам удалось продать решение в внедрить в ряд компаний. Мы внедряли крайне быстро, за несколько лет по сути только мы делали завершенные внедрения в страховой сектор на рынке Украины (звучит немного пафосно, но на всех специализированных форумах и конференциях мы не услышали ни об одном внедрении кроме наших). Ресурсы по поддержке продукта были незначительны после первоначального этапа доработок и разработок под нужды клиентов. Я бы сказал, что продукт разрабатывался несколькими удаленными работниками в течении года). Также мы его четко с позиционировали Мобильный Страховой Полис — это продукт последней мили. Клиентам мы объясняли — что мы решаем конкретную проблему — организации удаленных продаж. Т.е. мы выгребаем информацию от заказчика (справочники, коэффициенты расчета и др), а назад высылаем полисы и другую информацию, такие как использованные бланки.

Результат (промежуточный)

В течении двух лет после появления идеи наше решение было внедрено в несколько крупнейших страховых компаний, таких как Инго, Кредо-Классик, Нова. Страховые полисы печатались и продавались в отделениях ОТП банка, салонах продажи автомобилей, туристическими агентставами, «в полях», на границе была продажа зеленой карты на пропускных пунктах в Ковеле и Яготине. Не встретили никаких пожеланий клиента, которые мы не удовлетворили. Сегодня мы сконцентрировали опыт по автоматизации практически всех видов страховых продуктов: КАСКО, ОСАГО, Страхование имущества, зеленая карта, туристическое страхование, медицинское. Внедрили удаленную схему документооборота, например, заказ и учет бланков, систему печати, интеграцию как со страховой компанией, так и с учетной компанией партнера (такие, например, как 1С разные CRM). Начали разрабатывать интеграцию с другими нашими продуктами (такими как СМС — для целей андеррайтинга, электронный цифровой штамп — для целей андеррайтинга и снижения рисков мошенничества — об этих продуктах расскажу в следующих публикациях) и тут…

… случился кризис в Украине.

Кризис поставил на грань весь финансовый сектор, страховые компании сильно пострадали. У них не было продаж, все вынуждены были сворачивать отделения и деятельность. Словами это описать тяжело — практически на глазах в один день угас сектор экономики. Я вынужден был закрыть отделение страховой, которые мы с моим партнером открыли, продажи новых продуктов упали до нуля. Денег с прибыли нашего стартапа стало не хватать, поэтому мы с ним приняли решение приостановить проект. Валентин ушел работать наемным топ-менеджером. Продукт продолжал поддерживаться нами и еще несколько лет мы получали деньги от клиентов. Сейчас все ожило. Я получил несколько звонков от страховых за последние несколько месяцев. Под боком — огромные рынки России и Казахстана. Поэтому решил описать историю продукта, чтобы найти реальных партнеров или инвесторов. Я вижу несколько вариантов:

• Найти инвестиции в проект и активного инвестора.
• Продать проект.
• Найти региональных ресселеров и внедренцев.

Что есть в проекте:

1. Доменные имена
2. Завершен процес регистрации авторского права (на руках сертификат).
3. Все исходные коды и документация.
4. Все ключевые разработчики доступны.
5. Моя и Валентина Кузенкова компетенция.

Кстати, со мной можно связаться напрямую на почте гугла — digsee собака gmail. com или по телефону +380505067999 Если будет интерес – продолжу публикации о других проектах. Не уверен, что ссылка на проект не будет рассматриваться как рекламмная, поэтому гуглите по словам Мобильный Страховой Полис.
Видео по продукту:

[Технологическая ремарка]

Требования к проекту (как они были сформированы до начала проекта)

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

1. Текстовое поле (фамилия, имя, т.п.)
2. Сумма в гривнах (валюте)
3. Выбор одного из предопределённых вариантов (фиксированные суммы страхования, фиксированные периоды страхования)
4. Логические значения (включено/выключено)

Многие из этих полей были логически связаны друг с другом (к примеру, какие-то опции могут быть доступны только при определённых значениях других опций)

Пользователь должен был иметь возможность создать набор страховых полисов для их последующей отсылки на сервер компании через HTTP или e-mail (SMTP)

Клиентская программа должна поддерживать возможность работы в on-line, с периодическим подключением к on-line и off-line:

● on-line (постоянный или с периодическим подключением) — программа должна была остылать данные на сервер через HTTP или SMTP

● и off-line — отсылка полисов на сервер должна была происходить при участии человека — программа должна была записать zip-файл на сменный носитель, человек должен был загрузить этот файл на сервер через web-интерфейс

Программа должна была уметь генерировать отчёты в формате MS Excel и MS Word.

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

1. Небольшой размер. В идеале программа должна была в упакованном виде помещаться на дискету (1.44Mb)
2. Возможность работы на слабых компьютерах и устаревших ОС Майкрософт: Windows 98, Windows 95
3. Расширяемость — возможность легко добавить поддержку новых форм сбора данных.

Техническое решение

Для обеспечения максимальной гибкости при сохранении небольшого размера программы было выбрано следующее решение:

1. Ядро программы пишется на нативном языке (C++) без использования дополнительных фреймворков.

2. Поскольку требования работы под ОС отличные от MS Windows не стояло, практически весь UI программы был сделан при помощи MSHTML. Фактически, ядро программы не содержало кода связанного с UI. Вместо этого сразу же в основном окне поднимался IE ActiveX, которому на вход подавалась HTML-страница которая и отображала пользовательский интерфейс. Достоинства такого решения:

a. Интерфейс пользователя создавался при помощи HTML/CSS и JavaScript, что дало возможность быстро прототипировать внешний вид приложений. К тому же, это дало возможность использовать существующие решения которые были разработаны для Web-приложений.

b. IE установлен практически на всех ОС Майкрософт, начиная с Windows 95. Для корректной работы наша программа требует наличия IE 5.01, найти компьютер под управлением Windows без IE 5.01 или выше практически невозможно, да и в этом случае IE 5.01 ставится на компьютер за считаные минуты. Теоретически, можно было обеспечить поддержку IE начиная с 4.0 — но это потребовало бы дополнительных усилий и было признано нецелесообразным.

c. Размер ядра программы (С++ — кода) получился очень небольшим. HTML содержит достаточно средств для создания UI, в итоге размер exe-файла составил около 1Мб, размер HTML/CSS/JS варьировался в зависимости от количества и сложности форм для данного конкретного заказчика, но в среднем редко превышал в сумме 1Мб.

d. Программа не требовала инсталляции (и прав администратора) и могла быть запущена из любого каталога.

3. Для хранения данных форм был выбран формат XML. Как альтернативы ему рассматривалось хранение данных в базе (но наличие даже небольшой встроенной базы данных класса SQLite увеличило бы размер EXE-файла минимум на 50%, к тому же при фатальных программных или аппаратных сбоях на стороне клиентов восстановление данных из XML выглядело куда более простой задачей чем восстановление данных из базы) и хранение данных в формате JSON (было отклонено поскольку подавляющих преимуществ JSON перед XML не имеет, при этом файл с данными форм был предназначен для импорта различными системами сборами данных — а импорт из XML поддерживается чуть лучше чем импорт из JSON).

4. Формат XML также был использован для хранения “входных данных” форм (т.н. “справочников”) — к примеру, список вариантов сумм страхования и т.п.

5. Поскольку бОльшая часть данных и кода программы была доступна на диске в виде XML и JS файлов встала задача защиты от злоумышленника. Злоумышленник мог изменить XML-файл вручную или изменить JS файл меняя логику работы программы. Чтобы избежать такой ситуации, все XML и JS файлы которые загружались программой были подписаны. Для каждого файла при загрузке вычислялся его хэш (использовалось MS Crypto API) и этот хэш сверялся с хранимым в начале файла. Если хэш не совпадал, программа сообщала о проблеме и прекращала работу.

6. Программа поддерживала автоматическое обновление как XML/JS скриптов так и EXE-файла. Для этого при каждой загрузке файлов с данными форм на сервер запускалась проверка наличия более свежей версии.

7. Формирование отчётов в MS Excel и MS Word (а позже и в аналогичные программы Open Office). Для того чтобы сделать эти отчёты максимально гибкими, была применена следующая схема:

a. Шаблон представлял из себя обычный файл MS Excel/MS Word

b. В тех ячейках MS Excel (для MS Word их аналогом были закладки “bookmarks”) куда требовалось вставить реальные данные в шаблоне стоял JS код со специальным префиксом. Префикс использовался для поиска JS кода, после чего он обрезался и JS код запускался на выполнение. Это позволяло обращаться к любым данным формы, выполнять над ними арифметические операции или операции со строками и т.п. После выполнения JS кода полученный результат вставлялся в ту же ячейку.

c. Для поддержки OpenOffice была использована та же схема. OpenOffice для Windows тоже позволяет обращаться к своим из JS, но имеет абсолютно другой API. Для того чтобы работать единообразно с MS и OpenOffice было создано внутреннее JS API которое скрывало разницу в реализации доступа к файлам различных офисных пакетов. В итоге один и тот же шаблон отчёта можно было использовать как с OpenOffice так и с MS Office

Перспективы развития, или современный вариант решения той же задачи

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

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

Вот то как видится современное решение этой же задачи:

Web-приложение с возможностью работы offline. Современные браузеры (WebKit, Mozilla, последние версии IE или старые версии с установленным плагином Google Gears) поддерживают т.н. AppCacheкоторый позволяет приложениям запускаться даже если подключения к интернету нет. Ещё одна технология которая делает возможным работу в off-line — это возможность сохранения данных на стороне клиента (Client-sidedatastorage). В сумме они дают возможность создавать “гибрид” впитывающий в себя лучшие стороны Web-приложений (возможность работы с широкого спектра устройств с различными ОС, остутствие этапа установки приложения) и клиентских приложений (возможность работы без доступа к интернет). Огромным плюсом такого подхода является то что единожды созданное приложение позволит работать пользователям с практически любого современного устройства поддерживающего доступ в интернет: Android-smartphone, Android-планшет, iPhone/iPod, iPad, нетбуки, десктопы.

Для серверной части интересным решением мог бы стать Google App Engine — большим её преимуществом видится бесплатность для небольших приложений сочетающаяся с высоким показателем uptime.