Маленькие вещи могут создавать большие проблемы. И нет, речь не о камешке в ботинке и даже не о вирусах. Мелкие закупки — крупная головная боль для отдела снабжения. А поскольку в ЕВРАЗе активно развивается цифровая трансформация, мы эту головную боль решили лечить не цитрамоном, а соответствующим IT-продуктом.

Каждая фирма регулярно закупает разную мелочёвку. Для «обычной» компании это могут быть канцтовары, расходники, компьютерные клавиатуры и мыши. Для предприятий ЕВРАЗа это инструменты, электродетали и тому подобное. Но, с точки зрения снабженца, и то и другое — надоедливая мелочь. Оформить покупку плоскогубцев, разумеется, проще, чем покупку кислородного конвертера, но не прям на порядок проще. При этом покупаются они на порядок чаще — чем снабженца изрядно выматывают. Да и сотруднику не очень улыбается ждать свои пассатижи месяц (или месяцы).

Решается эта проблема в разных компаниях по-разному. Где-то постулируют, что отдел снабжения должен страдать, — судьба у него такая. Где-то приходят к выводу, что страдать должны другие сотрудники, — и закупка всего оптом планируется на год вперёд. В небольших фирмах часто подходят к вопросу неформально — мол, возьми денег в кассе да купи, оформим задним числом. А у некоторых недобросовестных работодателей сотрудникам приходится покупать нужную мелочёвку за свой счёт: закупка через полгода, а работу надо сделать вчера, и вертись как хочешь.

ЕВРАЗ — крупная компания, и позволить себе неформальный подход мы не можем. Но всё равно хотим, чтобы всем было хорошо. Чтобы сотрудник мог быстро и без проблем получить свой шуруповёрт, но при этом руководство могло спокойно спать, зная, что деньги ушли по назначению. Мы хорошенько подумали — и придумали внутренний маркетплейс.

Как всё устроено: крупный план

На первый взгляд — самый обычный интернет-магазин: товары, ценники, корзина. Даже стек достаточно стандартный — 1С + Битрикс. Но уже на второй взгляд начинаются нюансы: и оплата как-то странно происходит, и Kafka зачем-то прикручена. Поскольку все примерно представляют, как устроен обычный интернет-магазин, сосредоточимся на нюансах.

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

Начнём с «кто надо». Вообще, в маркетплейс может зайти любой из 50К сотрудников ЕВРАЗа. Но у большинства доступ, так сказать, ридонли — можно посмотреть ассортимент, но купить что-либо не получится.

Типичные сотрудники ЕВРАЗа разглядывают ассортимент

Покупками занимаются отдельные, избранные сотрудники — они называются покупатели заявителями. Их уже гораздо меньше — тысячи полторы. Как правило, это какие-то ответственные лица из своих структурных подразделений. (Логично: кто доверит безответственному лицу распоряжаться бюджетом?) Авторизация идёт через общеевразовскую систему — так решается вопрос «кто надо».

Вопрос «у кого надо» решается тендером. На конкурсной основе отбираются поставщики, способные предоставить необходимые товары по приемлемым ценам в разумные сроки. Сейчас у нас 18 поставщиков. Больше не нужно: хорошо спроектированная система должна беречь интеллектуальные силы пользователя и не вгонять его в паралич выбора. Это, кстати, часть решения вопроса «что надо».

Вообще, сам по себе формат маркетплейса уже очень способствует выбору «что надо». Снабжение по классической схеме — это проблема. Допустим, работник пишет заявление, что ему нужен шуруповёрт фирмы Х модели Y. В идеальном случае снабженец действительно достаёт именно такой шуруповёрт. А что, если его нет в наличии? Купить шуруповёрт фирмы X модели Z? Или шуруповёрт фирмы W модели «что-то типа Y»? Или вступить с сотрудником в переписку, выясняя, какой следующий шуруповёрт в его вишлисте? А что, если нужный шуруповёрт есть в наличии, но ещё имеется модель, у которой на бумаге аналогичные характеристики, а цена на 20% ниже?

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

1. отдел снабжения заранее даёт добро на его покупку;

2. товар есть (точнее, должен быть) в наличии.

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

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

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

1. Ассортимент одобренных товаров.

2. Месячный бюджет структурного подразделения на такие-то нужды.

3. Максимально допустимая стоимость одного заказа.

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

5000 гвоздодёров в месяц и в самом деле слегка перебор

Разумеется, это не значит, что в ЕВРАЗе полная анархия и каждый заявитель может покупать что угодно, пока бюджет не иссякнет. К такому шопоголику у соответствующего отдела быстро возникнут вопросы — но уже постфактум. Система построена на том, что у заявителя есть некоторый кредит доверия и, пока он не растрачен, можно действовать по своему усмотрению в рамках полномочий.

В общем, если вынести бюрократию за скобки и наладить взаимодействие с поставщиком, то время поставки радикально сокращается: с месяца и больше — до считанных дней.

Гладко было на бумаге

Разумеется, подобно ТАРДИС, наш проект внутри значительно больше и сложнее, чем кажется снаружи. И во всём, что описано в предыдущем разделе, есть нюансы, особые случаи и подводные грабли.

Начнём с заявителей. На некоторых предприятиях ЕВРАЗа роль заявителя дробится на две:

1. Младший заявитель — человек, который собирает корзину.

2. «Полноправный» заявитель — человек, который имеет право нажать кнопку.

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

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

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

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

2. Когда приёмщик получил и проверил заказ, он называет секретный код экспедитору.

3. Экспедитор вводит код в специальном АРМе (это считается ПЭП) и подписывает акт приёмки.

При необходимости СМС с секретным кодом можно отправить заново

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

Работа с поставщиками — самая мозголомная интересная часть проекта. Казалось бы, в чём проблема: собрал данные о товарах, залил в базу. На самом деле проблема примерно во всём.

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

1. Через специальный API.

2. Из файла, расшаренного по FTP.

3. Из таблички, которую присылают руками.

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

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

Главные и основные грабли, на которые мы наступили в этом проекте, — тотальная недооценка количества нужных товаров. Когда при запуске проекта у нас был ассортимент на 15К наименований, всё шло хорошо. Но потом пришёл следующий поставщик и прислал нам прайс, где одних только электродеталей было 200К разных видов. «Кряк!» — сказал 1С и завис на месяц. У штатного механизма обмена данными между 1С и Битриксом обнаружилась недостаточная пропускная способность. «Ага!» — сказали суровые сибирские айтишники и пошли налаживать нештатный механизм, с оптимизацией и RabbitMQ. По схожим причинам, когда мы сделали для поставщиков API заливки данных, пришлось заморочиться и разделить во времени получение и обработку прайса: данные промежуточно хранятся в Kafka, а уже оттуда 1С их «кушает» в комфортном для себя темпе. Без этой оптимизации поставщик превращался в диверсанта — массовый синхронный обмен данными ронял веб-сервис, а вместе с ним, по доброй 1С-ной традиции, ложился весь бэкенд целиком.

Обмен данными между 1С и Битриксом. Нештатный механизм работает в штатном режиме

На все эти оптимизации постфактум у нас ушло месяца два или три работы.

Другое следствие этих объёмов — беды с поиском. А именно — он довольно долгий. Мы экспериментировали с разными поисковыми движками, доступными для Битрикса, и по итогу выбрали наименьшее из зол. Всё равно долго, но для пользователя — цитата — «приемлемо». Если объёмы ещё вырастут и станет неприемлемо — будем думать дальше.

Есть нюансы, связанные со спецификой внутренних процессов. Например, всё это великолепие должно интегрироваться с системой учёта. Для системы учёта 400К видов товаров — это несколько избыточно, поэтому они мапятся в ограниченное число статей расходов с помощью системы групповых справочников. Допустим, когда заказываешь гвоздодёр для повседневных нужд, система находит его в справочнике «инструменты» — и он списывается по статье «инструменты». А вот если гвоздодёр нужен для какого-то проекта (скажем, для ремонта цеха) — тут уже другая история. Под проект создаётся отдельная статья расходов и отдельный справочник. Если гвоздодёр есть в нескольких справочниках — маркетплейс предлагает выбрать, по какой статье он должен идти. Также учитываются складские остатки — если нужный гвоздодёр, оставшийся от прошлого ремонта, есть на близлежащем складе, то можно заказать его оттуда и не обращаться к поставщику.

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

Критерий успеха

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

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

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

Гвоздодёр — отличный повод для беседы

С тех пор несколько лет проект находится в состоянии вялотекущей доработки. Последняя крупная фича — мы добавили небольшой CRM, чтобы пользователь мог прямо внутри маркетплейса списаться с нужными людьми и решить с ними вопросы. Услышали ли мы от пользователей хоть слово благодарности? Конечно, нет. Но надеемся, что через полгода от кого-то из них поступит жалоба: помогите, в маркетплейсе сообщение не отправляется, всё пропало, производство на грани срыва, а-а-а-а!

Ну а если не спрашивать пользователей, можно взглянуть на статистику. За 2023 год через маркетплейс прошло более 70 тысяч заказов, по которым привезли 700 миллионов штук товаров. Из этих семидесяти тысяч заказов примерно половина — т. н. заказы с коротким сроком, то есть с доставкой быстрее чем за неделю. Для сравнения: раньше любая доставка занимала от 30 до 60 дней. И все эти цифры значат одну простую вещь: мы старались не зря.