Тиражируемое решение — продукт, который не пишут заново под каждого клиента. Его разворачивают из готовой основы и настраивают под компанию. Виктор Машошин, генеральный директор компании Integer, рассказал на Хабре, как его команда построила такой продукт: систему управления трейд-маркетингом для фармацевтики, или TMS. Материал написан в формате кейса и читается примерно за десять минут.
Главная цифра материала — сроки внедрения. Восемь лет назад TMS внедряли в среднем около восьми месяцев. Сейчас уходит от трёх до пяти месяцев, и это касается даже сложных клиентов. Остальной текст объясняет, за счёт чего это получилось.
Ниже конспект: где Integer нашли нишу, как устроены ядро и слой кастомизации, как доработка для одного клиента попадает в базовый продукт и как команда не ломает систему обновлениями. Мой взгляд на всё это — в последнем разделе.
Почему тиражируемое решение — не коробка
Первая мысль Машошина: тиражируемый продукт не обязан быть коробочным. Сложную отраслевую систему всё равно приходится подгонять под конкретного заказчика. Он сравнивает это с SAP, который тоже адаптируют под каждого клиента.
Выгода получается двусторонней. Заказчик быстро получает систему, настроенную под себя. Разработчик каждый раз берёт готовую основу и не начинает с нуля. Каждый новый проект показывает, какие потребности повторяются от клиента к клиенту. Их переносят в базовый продукт, и следующее внедрение требует меньше работы.
Поэтому главная задача при создании такого продукта, по словам автора, — заложить в базовый слой инструменты для быстрого развёртывания и настройки. Сокращение сроков внедрения с восьми месяцев до трёх–пяти он считает доказательством того, что подход выбран верно.
Как Integer нашли нишу: трейд-маркетинг в фарме
Делать ещё одну CRM, ERP или WMS автор считает бесполезным занятием: рынок уже занят сотней крупных игроков. Конкурировать там можно, только если переосмыслить продукт и иметь огромный маркетинговый бюджет. Поэтому команда искала незанятую нишу и начала с фармацевтики.
Трейд-маркетинг — это работа производителя с торговыми партнёрами: условия выкладки, бонусы, промоактивности. В российской фарме у него своя специфика, и Машошин называет три её источника.
- Регуляторика. Рецептурные препараты нельзя продвигать так же, как безрецептурные или обычные потребительские товары.
- Выкладки и фейсинги. Фейсинг — количество упаковок товара, обращённых к покупателю на полке. В аптеке выкладка и рекомендации фармацевта могут зависеть от маркетингового контракта. Это называется «информированием в категории», и один фейсинг и несколько фейсингов — разные условия размещения.
- Рибейты и ретро-бонусы. В Европе и на Ближнем Востоке эта система применяется не очень широко, а в России она развита и составляет важную часть трейд-маркетинга. По словам автора, это одна из причин, почему зарубежное ПО здесь почти не прижилось.
У Integer был опыт работы с фармкомпаниями в России и в Азии. Команда увидела, что трейд-маркетинг у клиентов в основном ведётся в Excel, нормальной автоматизации нет. Integer задокументировали повторяющиеся закономерности и правила, добавили собственную экспертизу и на этой основе собрали TMS на платформе ТУРБО X. По словам автора, сейчас систему используют крупнейшие фармацевтические компании.
Продукт уже вышел за пределы фармы: соотношение отраслей примерно 50 на 50. Условие применимости одно — у компании есть собственное производство и дилерская или дистрибьюторская сеть, с которой она работает по маркетинговым соглашениям.
Ядро и надпроекты: как устроен тиражируемый программный продукт
По Машошину, у тиражируемого программного продукта два слоя. Внизу лежит стабильное технологическое ядро, которое переносят из проекта в проект без переписывания. У Integer это платформа ТУРБО X: на ней выполняются все расчёты и обрабатываются данные.
Для фармы скорость ядра критична. Объёмы доходят до десятков миллионов транзакций. С появлением кодов маркировки клиенты перешли от агрегированных данных к детализации до конкретного продукта и контрагента. Данные при этом хранят за несколько лет, чтобы сравнивать периоды. Получается огромный объём пересчётов, калькуляций и аллокаций. Без ТУРБО X, по опыту команды, обработать его с нужной скоростью было бы сложно.
Второй слой — бизнес-логика, которую можно менять под заказчика и не трогать при этом базу. Тиражируемость, по словам автора, держится на двух вещах:
- Базовый слой покрывает большую часть встречавшихся кейсов. По принципу Парето около 80% клиентов идут по стандартному сценарию, 20% требуют отдельных решений.
- Высокая параметризация. Многое настраивается без разработчиков. Пример — цепочки согласования: последовательное, параллельное, многоступенчатое, с условиями. Как бы ни был устроен процесс у заказчика, базовый продукт его поддержит.
Когда настроек не хватает, начинается кастомизация. Платформа строит решение как иерархию проектов: верхний проект использует функциональность нижних и может расширять их модели, формы и отчёты. Под клиента создаётся надпроект. Базовая часть при этом не меняется, а кастомизация живёт в своём слое и не затирается при обновлении продукта.
Машошин выделяет три направления кастомизации: бизнес-логика, когда система работает по другим сценариям; интерфейс, например под жёсткий брендбук; нетиповые процессы. Последних много у зарубежных фармкомпаний на российском рынке — немецких, итальянских, венгерских. Процесс доработки стандартный: обследование, техническое задание, согласование с архитекторами, реализация, приёмка, передача клиенту. Архитекторы оценивают и способ реализации, и то, впишется ли требование в развитие базового продукта.
Как создать тиражируемый продукт из череды проектов
Самая практичная часть материала — механизм, по которому разовая доработка становится стандартом. Отдельный кейс сначала делают для конкретного заказчика. Потом команда ищет закономерность. Если сценарий может повториться, его переносят в базовый слой после согласования с архитекторами.
Пример автора — работа с несколькими юрлицами. У одного клиента их было три, и у каждого своя специфика вплоть до документооборота: разные договоры и модели работы с дилерами. Внутри системы каждое юрлицо живёт по своим правилам. Топ-менеджмент при этом видит их как единый холдинг с общей моделью данных и сводной отчётностью. В базовом исполнении система тогда работала только с одним юрлицом. Но компаний с похожей структурой оказалось много, особенно на фоне слияний и поглощений, и сценарий стал стандартным функционалом.
Обратный пример — идея заказчика, которая не прижилась. Клиент настоял, чтобы КАМы, менеджеры по работе с ключевыми клиентами, вносили данные через мобильное приложение. Команда заранее сомневалась: таблицы КАМов не помещаются на экран телефона и при уменьшении теряют смысл. Приложение всё равно разработали и запустили. Через три–четыре месяца КАМы подтвердили, что работать с основным объёмом данных на телефоне неудобно. Прижилась только часть функций, например заполнение результатов встреч. Вывод автора: даже очевидную архитектурную гипотезу иногда приходится проверять эксплуатацией.
Тесты, обновления и интеграции
Кастомизации угрожают базовому продукту, а обновления ядра угрожают кастомизациям. Integer защищаются от обоих рисков тестированием, и за приёмку у них отвечает отдельное подразделение. Этапов три:
- Машинные тесты воспроизводят типовые бизнес-процессы и проверяют, что новые блоки не сломали систему.
- Скрипты и другие методы проверяют все кнопки и флажки.
- Команда сопровождения ставит обновление на систему клиента и повторяет проверку, которая уже прошла в окружении Integer.
Кастомизированную часть массово не обновляют. Для каждого заказчика собирают отдельный релиз и ведут отдельное сопровождение.
С обновлениями самой платформы риск другой: ТУРБО X ничего не знает о кастомизациях Integer и может их задеть. Поэтому новые версии сначала ставят на DEV- и тестовые среды, проверяют совместимость с клиентскими конфигурациями и только потом передают дальше. Машошин прямо говорит, что риск остаётся. Это цена выхода за рамки стандартной конфигурации, и команда его принимает.
Интеграцию с ИТ-ландшафтом заказчика Integer стараются не навязывать. Основной способ — API: собственные и API систем клиента. Если подходящего API нет, используют текстовые файлы или интеграцию на уровне баз данных. Integer одними из первых интегрировались с МДЛП, системой мониторинга движения лекарственных препаратов. Тогда она была сырой, с тестовыми средами были сложности. Сейчас у неё есть API и документация, и для фармацевтической системы прямая интеграция с МДЛП фактически обязательна. Ещё один пример — проект в Китае: интеграция с самописной фармсистемой без документации и без англоговорящей поддержки. По словам автора, её удалось сделать в том числе благодаря возможностям движка.
В конце Машошин говорит о планах. Аптечные сети всё чаще выбирают поставщиков через тендер, а не через переговоры. Поэтому выверенное коммерческое предложение и промо-план становятся важнее, и в систему встраивают сервисы под эту задачу. Сам опыт TMS адаптируют для других отраслей: работа с дистрибьюторами и промоактивности устроены похоже почти у всех производителей.
Коротко
- Тиражируемое решение для сложной отрасли — не коробка, а основа с инструментами быстрой настройки. У Integer срок внедрения сократился с восьми месяцев до трёх–пяти.
- Нишу нашли там, где специфика рынка, то есть регуляторика, фейсинги и ретро-бонусы, отсекла зарубежное ПО, а клиенты сидели в Excel.
- Архитектура двухслойная: стабильное ядро на ТУРБО X и кастомизация в надпроектах, которая не затирается обновлениями. 80% клиентов идут по стандартному сценарию.
- Удачные доработки после проверки архитекторами переходят в базу, как работа с несколькими юрлицами. Неудачные проверяются эксплуатацией, как мобильное приложение для КАМов.
- Систему держат трёхэтапное тестирование, отдельные релизы для кастомизаций и проверка обновлений ядра на тестовых средах.
Что я об этом думаю
Больше всего меня зацепила мысль, что разовая доработка — сырьё для продукта, а не его порча. Обычно кастомизацию воспринимают как долг, который тянет разработку назад. У Integer это источник развития, но с фильтром: каждую доработку архитекторы оценивают на совместимость с будущим базы. Без такого фильтра продукт за пару лет превращается в набор несовместимых веток.
Ценю, что в кейс попал провал с мобильным приложением. Обычно компании пишут о таком только хорошее. Здесь честно признано, что команда сомневалась, сделала по желанию клиента, и через три–четыре месяца выяснилось, что сомневалась не зря. Причём часть функций всё-таки прижилась, а это полезный вывод и для тех, кто сам заказывает разработку.
Чего мне не хватило — денег. Сроки внедрения есть, а стоимости поддержки слоя кастомизаций, отдельных релизов под каждого клиента и трёхэтапного тестирования нет. Подозреваю, что именно там основная цена модели.
Пригодится материал тем, кто делает заказную разработку в одной отрасли и замечает, что каждый новый проект на 70% повторяет предыдущий. Как перейти от проектов к продукту и не сломать при этом обязательства перед клиентами, здесь описано довольно конкретно.