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

Меня зовут Виктор Машошин, я генеральный директор 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 для фармацевтики, уже адаптируется для других отраслей. Принципы работы с дистрибьюторами и организация промоактивностей одинаковы для большинства производственных компаний. Решение может найти применение практически везде, где есть своя дистрибуция и бонусные модели.