Как разработать уникальное тиражируемое решение для отрасли? Опыт Integer в создании TMS для фармацевтики

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

Меня зовут Виктор Машошин, я генеральный директор Integer, и в этой статье на примере системы управления трейд-маркетингом (TMS) я расскажу, как мы пришли к тиражированию, и как это решение позволило сократить средний срок внедрения в два раза даже для сложных клиентов.

Тиражируемое решение – это не коробка

Тиражируемое решение не обязательно является полностью коробочным продуктом. Особенно если речь идет о сложной отраслевой системе, которую приходится адаптировать под конкретного заказчика. Аналогию скорее можно провести с SAP, который также адаптируется под клиента.

Основная задача при создании тиражируемого решения – заложить в базовый слой инструменты, позволяющие быстро разворачивать и кастомизировать продукт под компанию. Забегая вперед, динамика сроков внедрения показала, что подход мы выбрали правильно: восемь лет назад средний срок внедрения TMS составлял около восьми месяцев, сейчас – от трех до пяти месяцев даже для сложных клиентов.

Но как вообще появился этот базовый слой и почему команда решила создавать именно такой продукт?

Как мы нашли основу для тиражируемого продукта

На рынке много решений для корпоративной автоматизации – CRM, ERP, WMS. Создавать очередную CRM, когда вокруг уже сотня крупных игроков, – бесполезное занятие, если только не переосмыслить продукт и не иметь огромного маркетингового бюджета. Поэтому надо было искать незанятую нишу.

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

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

В отличие от Европы и Ближнего Востока, где система рибейтов и ретро-бонусов применяется не очень широко, в России эта практика хорошо развита и представляет собой важный элемент трейд-маркетинга. Это была одна из причин, по которой в этой области практически не применялось зарубежное ПО.

У нас был обширный опыт работы с фармой как в России, так и в Азии, что позволило проанализировать подходы наших клиентов. На их примере мы увидели, что процесс управления трейд-маркетингом в основном решался через Excel – качественной автоматизации не было. Специфика рынка открывала перспективу занять свое место.

Мы разглядели потребность, услышали запросы клиентов, задокументировали закономерности и правила, которые могли быть адаптированы для создания тиражируемого продукта, доработали определенные аспекты с учетом нашей собственной экспертизы. И на этой основе родился продукт – TMS, разработанная на базе платформы ТУРБО Х. Она быстро стала известна и хорошо себя зарекомендовала на рынке, на сегодняшний день ее используют крупнейшие фармацевтические компании.

Хотя исторически решение разрабатывалось под фармацевтическую отрасль, сейчас оно работает и в других сферах, соотношение примерно 50/50. Ключевое условие – наличие собственного производства и дилерской или дистрибьюторской сети, с которой производитель работает по маркетинговым соглашениям.

Одно ядро для разных проектов

Тиражируемый продукт должен иметь стабильное технологическое ядро, которое можно использовать на разных проектах, не переписывая. У нас таким ядром является платформа ТУРБО X. Вся функциональность реализована на ней: это вычислительная основа продукта, здесь выполняются расчеты и обрабатываются данные, что особенно критично для фармацевтических компаний, где объемы могут достигать десятков миллионов транзакций.

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

Без ТУРБО X, по личному опыту команды, обработать такие объемы с необходимой скоростью было бы сложно.

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

Как несколько проектов превращаются в один тиражируемый продукт

Тиражируемость обеспечивают два фактора: правильно спроектированный базовый слой, который покрывает большую часть встречавшихся кейсов, и высокий уровень параметризации, благодаря которому для настройки продукта под конкретного заказчика не всегда требуются разработчики. По принципу Парето около 80% клиентов идут по стандартному сценарию, а оставшиеся 20% требуют отдельных решений. Чем больше реализовано проектов, тем больше выявленной специфики попадает в очередное обновление продукта – и тем более гибким он становится.

Практически каждый функциональный блок можно настроить через внутренние инструменты базового слоя. Например, для цепочек согласования есть механизм настройки workflow: последовательное, параллельное, многоступенчатое согласование с условиями. Поэтому не имеет принципиального значения, как именно у заказчика устроен процесс согласования – базовый продукт уже способен его поддержать.

Если стандартных возможностей недостаточно, используется кастомизация. Самые частые запросы касаются изменения бизнес-логики: создается надпроект, при этом базовая часть остается неизменной, а отдельные элементы функциональности могут перекрываться и изменяться.

Кастомизация происходит в нескольких направлениях.

Первое – бизнес-логика: система начинает работать по другим сценариям.

Второе – интерфейс. Например, у клиентов с жесткими требованиями к брендбуку полностью поддерживается корпоративная стилистика.

Третье – нетиповые процессы заказчика. На российском рынке много зарубежных фармкомпаний – немецких, итальянских, венгерских – со своей спецификой. Процессы, не покрытые базовой функциональностью, оцифровываются в рамках кастомизации.

Сам процесс стандартный: обследование, подготовка технического задания на доработку, согласование требований с архитекторами на предмет совместимости с базовым решением, реализация зафиксированных требований, приемка функционала и передача клиенту.

При этом архитекторы оценивают не только то, как реализовать конкретное требование, но и насколько оно совместимо с развитием базового продукта.

Как кастомизация становится базой

Бывали случаи, когда удачные кастомные доработки после согласования с архитекторами переносились в базовое решение. Таким образом, best practice одного клиента становилась частью продукта и могла использоваться уже в следующих проектах. Один из показательных примеров кастомизации, попавшей в основу, – работа с несколькими юридическими лицами.

У одного из клиентов было три юридических лица. У каждого юрлица была собственная специфика вплоть до документооборота: договоры и модели работы с дилерской сетью различались.

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

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

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

Как не сломать базовый продукт кастомизациями

Как и в любой другой разработке – тестированием. У нас есть специализированное подразделение, ответственное за приемку функционала, которая осуществляется в несколько этапов.

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

Затем процесс продолжается с использованием скриптов и других реализованных методов, где тщательно тестируются все кнопки и флажки в системе.

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

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

Но с обновлениями есть и другая сторона.

Как не сломать кастомизации обновлением ядра

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

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

Это стандартная ситуация для решений с высоким уровнем кастомизации. Риски при обновлении ядра есть, и мы, выходя за рамки стандартной конфигурации базового приложения, принимаем их.

Как тиражируемое решение интегрируется с остальным ИТ-ландшафтом

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

Основной способ интеграции – API. У нас есть собственные API, и мы поддерживаем API систем, с которыми интегрируемся. Если система заказчика не предоставляет подходящего API, используем другие варианты: интеграцию через текстовые файлы или на уровне баз данных – в зависимости от возможностей и требований клиента.

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

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

Не всякая идея заказчика становится частью продукта

Были и кастомные решения, которые в процессе эксплуатации подтвердили свою несостоятельность. Один из примеров – попытка перевести работу КАМов (менеджеров по работе с ключевыми клиентами) по внесению информации на мобильное приложение.

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

Через три-четыре месяца эксплуатации КАМы подтвердили исходное предположение: работать с основным объемом информации на телефоне действительно неудобно. При этом часть функций прижилась – например, заполнение результатов встреч. Поэтому мобильный сценарий не исчез полностью, но в качестве основного рабочего инструмента КАМов не взлетел.

Для команды это стало полезным опытом: иногда даже очевидную архитектурную гипотезу приходится проверять реальной эксплуатацией.

Что дальше

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

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