Как мы перешли на 1С и превратили внутреннюю ERP в рыночный продукт

Мы начали переход раньше, чем он стал неизбежным. Ещё в 2021 году собрали на 1С прототип для учета закупки, транспортировки и реализации нефти и проверили, справится ли платформа со сложным отраслевым контуром. Типовая 1С:ERP для этого не подходила. Чтобы сохранить привычные для пользователей процессы, её пришлось бы почти полностью переписать. Поэтому новую систему начали строить с нуля на БСП, а функциональность переносили из существующей ERP по частям. Ядро команды досконально знало первоначальную ERP и реализованные в ней бизнес-процессы, поэтому людям предложили переучиться. В итоге около 30 специалистов перешли на новую платформу, а недостающих экспертов добрали с рынка.

Мы сделали классную штуку. Сейчас пойдём и порвём рынок. Примерно так думала команда после нескольких лет работы, когда появился интерес у внешних компаний. Код ведь работает, есть первые пользователи, и остаётся «красиво» упаковать разработку. Но на практике быстро выяснилось, что работающий код ещё не продукт. Ему нужны оформленные права, дистрибутив, лицензирование, конкурентная цена, правила развития и поддержка. Пришлось меняться и самой команде. Люди, которые десять лет обсуждали задачи с одними и теми же внутренними заказчиками, теперь должны были показывать продукт незнакомым компаниям и не закапывать их в ГУ-12 (заявка для РЖД на перевозку).

Получились две миграции: технологическая и организационная. Дальше расскажем, как перешли на 1С и какие решения можно переиспользовать, чтобы не проходить этот путь с нуля.

Как появился продукт и почему потребовался переход на новую платформу

К 2021 году прежняя ERP-система уже много лет работала внутри компании. Она поддерживала планирование, операции с нефтью, производственный учёт, логистику, сбыт нефтепродуктов, отчётность. Её развивали собственные специалисты, которые хорошо знали процессы и могли напрямую обсуждать детали с ключевыми пользователями.

Почему мы не остались на старой системе

В 2021 году компания начала оценивать, стоит ли переходить с действующей версии вендорской ERP на следующую. Миграция требовала много времени и значительного бюджета, но явных преимуществ перед уже работающей системой не приносила. Бизнес-процессы после переноса остались бы почти такими же. Конечно, отказ от перехода на новую версию ещё не означал, что старую систему сразу нужно отключать. Она была развёрнута внутри корпоративного контура, стабильно работала и могла прослужить ещё много лет. Уход вендора не превращал её в тыкву и не обнулял уже созданную функциональность. Проблема была не в текущем состоянии системы, а в её будущем. При выборе новой платформы учитывали накопленный в компании опыт работы с 1С и наличие специалистов, на которых можно было опереться.

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

Как сохранили процессы без типовой конфигурации

Главное требование к новой системе звучало просто. Пользователь должен перейти в неё почти бесшовно и продолжить работать по знакомым правилам. Но типовая конфигурация 1С построена вокруг другой процессной логики. И чтобы приспособить её к действующему контуру, пришлось бы переделывать почти весь продукт, а затем самостоятельно поддерживать сложную надстройку.

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

В проектах миграции часто кажется, что достаточно нанять людей, хорошо знакомых с новой платформой. Однако им всё равно придётся разбираться в процессах, текущем решении, исключениях и договорённостях, которые копились у вас годами. А большинство специалистов 1С привыкли работать с типовыми конфигурациями. Опыт создания крупного корпоративного решения непосредственно на БСП на рынке практически не встречался, а для части кандидатов этот подход выглядел слишком нишевым.

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

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

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

Как переучить команду с синего на жёлтое

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

Перед активной разработкой сотрудников отправили на курсы и сертификацию 1С. Учились в рабочее время, а затем закрепляли знания на реальных задачах. Около 30 специалистов освоили новую платформу и продолжили работу. Единицы отказались сразу, кто-то сошёл с дистанции в процессе, потому что смена стека так и не сложилась. Тяжелее переобучение далось разработчикам. Поэтому их чаще нанимали с рынка и объединяли с прежней командой, чтобы знания передавались в обе стороны. А большинство аналитиков и архитекторов сохранили свои роли и стали мультивендорными специалистами.

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

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

Самый показательный спор возник вокруг регистров 1С. Архитекторы предлагали хранить данные в привычных плоских таблицах. Разработчики отвечали, что на 1С такая схема начнёт тормозить и нужно использовать регистры сведений и накопления. В результате архитектуру переделывали несколько раз. К первому запуску договориться ещё не успели. Общее решение нашли примерно к третьему крупному запуску функциональности, а часть кода пришлось менять уже на ходу.

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

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

Единый коллектив не возник автоматически после обучения и найма. Его несколько лет собирали из людей с разным опытом, постепенно передавая знания в обе стороны.

Как внутреннее решение превратилось в продукт

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

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

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

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

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

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

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

Что потребовалось для выхода на рынок

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

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

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

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

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

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

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

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

Ценовую и лицензионную модели пришлось собирать заново

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

Экономику особенно легко упустить. Внутренняя система может годами развиваться за счёт бюджета основного заказчика. Но для выхода на рынок нужно знать стоимость развития, внедрения и поддержки, а также ожидаемый объём продаж и срок окупаемости. Иначе получится, что технология есть, а бизнеса нет. Но изобретать всю схему с нуля необязательно. Лучше заранее определить правообладателя, порядок выплаты роялти, заработок партнёра, цену для клиента и состав услуг.

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

Для внешнего рынка пришлось меняться

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

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

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

• Владелец продукта отвечает за направление развития и целостность платформы.

• Продуктовый менеджер следит за метриками, упаковкой и методологией.

• Специалист по развитию бизнеса работает с рынком и партнёрами.

• Продавец ведёт конкретные сделки.

• Технические лидеры подключаются к сложным демонстрациям и отвечают за свои функциональные контуры.

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

За время коммерциализации команда взаимодействовала более чем со 180 компаниями. Речь, конечно, не о 180 продажах, но это общение дало нам много пользы. Для сложного B2B-продукта полтора года встреч, демонстраций и обсуждений почти со всем доступным рынком превратились в отдельную исследовательскую работу. Мы поняли, что коммерциализация требует другой культуры. Поэтому пришлось менять процессы и меняться самим. Теперь и руководители, и даже разработчики всегда помнят, что внешний клиент ничего не знает о наших внутренних договорённостях и совершенно не обязан ждать, пока мы разберёмся в своих процедурах.

Уроки двух миграций

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

1. Начинайте с процессов, а не с возможностей платформы. Сначала определите границы функциональных участков, необходимые данные и интеграции, а затем выбирайте способ реализации на новом стеке.

2. Сохраняйте накопленную экспертизу. Новую платформу можно освоить, а десятилетний контекст быстро не восстановить.

3. Заранее закладывайте время на столкновение инженерных культур. Первые архитектурные решения придётся пересматривать, и это нормальная часть перехода.

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

5. Сразу разделяйте внутреннюю и рыночную версии и определяйте, сколько веток сможет поддерживать команда.

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

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