Если компания закупает товары у десятков или сотен поставщиков, работа с ними постепенно превращается в отдельный операционный процесс.
Нужно получать и обрабатывать прайсы, отправлять заказы, собирать подтверждения, контролировать УПД, передавать информацию на склад, разбирать расхождения и рекламации. В зависимости от бизнеса к этому добавляются маркировка, пропуска на склад, кроссы, применяемость и другие процессы.
Часть этой работы обычно уже автоматизирована. Прайсы могут загружаться по FTP, заказы — формироваться в 1С, документы — передаваться через ЭДО. Но наличие отдельных интеграций еще не означает, что участие сотрудников больше не требуется.
Прайс нужно не просто получить, а убедиться, что система смогла его разобрать. По заказу нужно получить подтверждение. До приезда машины должны появиться корректные документы, а склад — понимать, что и в каком количестве ему привезут. Если данные не совпали, ошибку нужно обнаружить и разобраться в причине.
Когда поставщиков один-два, эти задачи может совмещать сотрудник, который занимается закупками. Но по мере расширения базы контрагентов растет и объем работы по их сопровождению: одни и те же операции приходится выполнять уже десятки или сотни раз. В какой-то момент для этого требуется больше людей либо часть работы распределяется между закупками, бухгалтерией, складом и другими подразделениями.
Причем дополнительная нагрузка возникает не только там, где нужно договариваться с поставщиком или принимать решение. Значительная часть времени может уходить на контроль: загрузился ли прайс, подтвержден ли заказ, получены ли документы, все ли данные совпали. Если на каком-то этапе процесс остановился, сотруднику приходится выяснять причину.
В е-комЭКСПЕРТ мы проектируем и внедряем личные кабинеты для работы с поставщиками. И при подготовке требований к одному из таких проектов мы столкнулись с задачей автоматизации работы примерно с 200 поставщиками. На таком масштабе становится очевидно, что по мере роста числа поставщиков компания вынуждена увеличивать и объем ручного сопровождения работы с ними.
Именно эту зависимость и может разорвать личный кабинет. Его задача не в том, чтобы перенести те же действия в новый интерфейс, а в том, чтобы часть из них вообще перестала требовать участия сотрудника.
Прайсы могут автоматически попадать в систему и проходить проверку, заказы — передаваться поставщику и возвращаться с подтверждением, документы — сверяться до приемки товара. Человек подключается, когда система обнаружила расхождение, не смогла обработать данные или действительно требуется решение.
При этом универсального набора функций для такого ЛК нет. Одной компании важно убрать ручную работу с прайсами и заказами, другой — связать поставщиков с приемкой и документооборотом, третьей — выстроить через кабинет работу с маркированными товарами и хранителями.
Поэтому дальше будем смотреть на функционал не как на список возможных разделов и кнопок, а через конкретные бизнес-процессы: какую ручную операцию он убирает и что это дает компании.
Начнем с прайсов — процесса, который на первый взгляд уже давно можно считать автоматизированным.
Поставщик может размещать файл на FTP, отправлять его по email или передавать данные через API. Система покупателя автоматически получает прайс и загружает его. Но сам факт получения файла еще не означает, что товары действительно попадут в систему и станут доступны для дальнейшей работы.
Сначала нужно разобрать структуру прайса: определить, где находятся артикул, бренд, наименование, остаток, цена и другие необходимые реквизиты. Поскольку форматы у поставщиков отличаются, для каждого источника могут потребоваться свои правила обработки.
Следующий этап — проверка самих данных.
В одном из примеров, который мы разбирали при подготовке проекта, поставщик передавал около 75 тыс. SKU, но система покупателя принимала только 35 тыс. Остальные позиции отбрасывались из-за ошибок: где-то не совпадало название бренда, где-то в артикуле встречалась кириллица, где-то значение имело некорректный формат или не сопоставлялось со справочниками покупателя.
Для бизнеса результат вполне конкретный: товар у поставщика есть, но часть ассортимента фактически не попадает в предложение покупателя.
Поэтому одна из полезных функций ЛК — не просто возможность загрузить прайс, а обратная связь по результатам его обработки. Поставщик видит, сколько позиций принято, какие отклонены и по какой причине. Если проблема в бренде, можно сопоставить его со справочником покупателя; если в артикуле или формате данных — показать конкретные строки, которые требуют исправления.
При этом саму передачу прайса нет смысла делать ручной только ради личного кабинета. Если файл уже появляется на FTP, ЛК может автоматически забирать его оттуда. Если поставщик отправляет прайс на определенный email — получать его из почты. Для компаний с настроенной интеграцией данные могут приходить через API. Ручная загрузка остается одним из вариантов, а не обязательным сценарием.
То есть ценность ЛК здесь не в переносе загрузки файла из одного окна в другое. Система сама получает и обрабатывает данные, а поставщик подключается только к тем позициям, с которыми возникла проблема.
С заказами логика похожая.
Заказ формируется во внутренней системе покупателя и передается конкретному поставщику. В ЛК поставщик видит его состав и может подтвердить заказ полностью либо скорректировать фактическое количество, если части товара уже нет в наличии. Подтвержденные данные возвращаются в 1С покупателя.
И здесь снова важно не заставить поставщика выполнять лишние действия. Если между учетными системами двух компаний уже можно настроить автоматический обмен, нет смысла требовать, чтобы сотрудник скачивал заказ из ЛК, загружал его в свою систему, а затем таким же способом возвращал ответ.
Личный кабинет нужен прежде всего как точка контроля и работы с исключениями: увидеть новый заказ, скорректировать его при необходимости, понять статус и вмешаться, если автоматический процесс не отработал.
Следующая точка — документы.
УПД подтверждает, что именно поставщик отгружает, в каком количестве и по каким ценам. Если получить и проверить эти данные заранее, информацию можно передать на склад еще до приезда машины. А расхождение между заказом и фактической отгрузкой обнаружить не на приемке, когда товар уже приехал, а раньше.
В итоге даже на трех базовых процессах — прайсах, заказах и документах — ЛК может убрать целый слой ручного контроля. Но взаимодействие с поставщиком на этом не заканчивается. Следующий участок, где остается много таких операций, — уже непосредственно работа со складом.
После подтверждения заказа и получения документов взаимодействие с поставщиком не заканчивается. Следующий этап — физическая поставка товара, и здесь тоже остаются операции, которые сотрудники часто выполняют вручную.
Простой пример — оформление пропуска. Если поставщик привозит товар на наемном транспорте, автомобиль и водитель могут меняться от поставки к поставке. Поставщик сообщает данные сотруднику покупателя, тот передает их на склад или охране, после чего машина появляется в списке на въезд.
В ЛК эту цепочку можно сократить. Поставщик сам указывает автомобиль, госномер, данные водителя, телефон и планируемое время приезда. Дальше информация автоматически передается в систему доступа. Сотруднику покупателя уже не нужно быть посредником между поставщиком и складом.
Другой сценарий — подготовка товара к приемке.
Если склад работает со штрихкодами или требует определенную маркировку, а у поставщика нет своей системы для формирования нужных этикеток, их можно генерировать в ЛК под конкретный заказ. Поставщик получает готовые этикетки, маркирует товар до отправки, а на склад приезжает уже подготовленная к приемке поставка.
Через кабинет можно организовать и работу с рекламациями. Вместо переписки по почте и ручного контроля статусов поставщик создает обращение, прикладывает необходимые документы и видит, на каком этапе находится согласование. Через этот же процесс можно организовать возврат и закрыть рекламацию после получения корректировочных документов.
Во всех трех случаях принцип один: ЛК убирает сотрудника из тех участков процесса, где он фактически только передает информацию между поставщиком и другой системой.
Но складские сценарии могут быть значительно сложнее. Особенно если речь идет не просто о поставке товара покупателю, а о хранении чужого товара, маркировке и последующей продаже.
И здесь личный кабинет уже может выполнять другую роль — связывать процессы и учетные системы двух компаний.
Более сложный сценарий возникает, когда через личный кабинет нужно связать работу поклажедателя и хранителя с маркированным товаром.
Сейчас мы рассматриваем именно такой вариант: товар поставщика находится у хранителя, а при дальнейшей работе с ним необходимо передать коды маркировки и провести связанные операции в учетной системе поклажедателя.
Здесь ЛК становится промежуточным звеном между хранителем и 1С поклажедателя.
Из 1С поклажедателя в личный кабинет синхронизируется справочник контрагентов. Для хранителя назначаются логин и пароль, а работа в кабинете происходит после индивидуальной авторизации.
В ЛК хранитель получает раздел, где может передать коды маркировки в разрезе номенклатуры (МХ-3). После этого на стороне поставщика необходимо проверить, что товары с указанными кодами действительно ранее отгружались этому хранителю.
Следующий предусмотренный в процессе этап — передача МЗ-3 из личного кабинета в 1С. После этого в 1С поклажедателя происходит снятие товара с хранения и формируется документ «Реализация товаров и услуг» с полученными кодами. Далее из 1С в ЭДО выгружаются необходимые УПД с кодами маркировки.
Таким образом, в этом сценарии ЛК связывает несколько последовательных операций:
1С поклажедателя → синхронизация контрагентов → доступ хранителя в ЛК → передача кодов маркировки → проверка на стороне поклажедателя → МЗ-3 в 1С → снятие с хранения и формирование реализации → УПД в ЭДО.
При этом ручной ввод кодов маркировки в ЛК — не единственный возможный вариант. В ТЗ также предусмотрена возможность API между 1С хранителя и личным кабинетом как альтернатива ручной работе на этапе передачи кодов.
И это хорошо показывает, почему при проектировании ЛК важно сначала разобрать весь процесс между компаниями. В одном случае кабинет действительно нужен как интерфейс для сотрудника, в другом часть операций можно передавать между системами без ручного ввода.
Мы в е-комЭКСПЕРТ много работаем с автобизнесом, поэтому дальше разберем его специфику. Так как у каждой отрасли есть свои особенности и процессы — их важно учитывать при проектировании кабинета. В автозапчастях один из таких процессов, напрямую влияющих на то, увидит ли покупатель предложение поставщика, — работа с кроссами.
Представим, что у контрагента есть деталь бренда А, которая является аналогом детали бренда Б. Товар есть в наличии, цена и остаток переданы, прайс успешно обработан системой. Но если покупатель не знает о связи между этими деталями, предложение поставщика может не попасть в результаты поиска по нужному артикулу.
Получается парадоксальная ситуация: товар физически есть и данные о нем успешно загружены, но для части запросов покупателя его как будто не существует.
Поэтому для компаний, работающих с автозапчастями, отдельным функционалом ЛК может стать передача кроссов. Поставщик указывает связи между своей номенклатурой и аналогами, а после проверки эти данные используются в каталоге и поиске покупателя.
Ценность здесь уже не столько в сокращении ручной работы, сколько в полноте товарного предложения. Чем больше корректных связей знает система, тем выше вероятность, что существующий у поставщика товар будет найден по релевантному запросу.
По той же причине при проектировании ЛК в автобизнесе важно учитывать и другие отраслевые данные: бренды, артикулы, применяемость и справочники, от которых зависит поиск и сопоставление номенклатуры.
При этом добавление каждой новой функции создает риск сделать кабинет удобным для покупателя, но неудобным для самого поставщика. И это особенно важно учитывать, когда один поставщик одновременно работает с десятками таких систем.
Сейчас многие компании стремятся упростить работу с поставщиками через личные кабинеты. Логика понятна: поставщик сам загружает данные, подтверждает заказы, прикладывает документы — и часть операций у покупателя исчезает.
Но будет ли поставщик действительно работать в таком кабинете?
При подготовке одного из проектов мы отдельно обсуждали этот вопрос с поставщиком, который уже работает через личные кабинеты своих покупателей. У него было сохранено 106 доступов к таким кабинетам, но активно сотрудники использовали примерно 30.
То есть сам факт, что покупатель создал ЛК и выдал поставщику доступ, еще не означает, что новый канал действительно встроится в его работу.
Первая причина довольно простая — поставщику нужен достаточно весомый повод менять привычный процесс. Новый ЛК — это еще один доступ, еще один интерфейс и еще один набор действий, который нужно встроить в ежедневную работу. Если речь идет о крупном и значимом клиенте, поставщик скорее подстроится под его требования. Чем меньше значение покупателя для бизнеса поставщика, тем сложнее мотивировать сотрудников осваивать еще одну систему.
Вторая причина — насколько удобно поставщику работать с самим кабинетом.
Одно дело сказать: каждый день заходите в наш ЛК, загружайте прайс, проверяйте заказы и переносите данные из своей учетной системы. Другое — настроить обмен так, чтобы от поставщика потребовалось минимум действий. Например, получить доступ к API и дальше передавать данные между системами автоматически.
Во втором случае поставщику не предлагают еще один процесс, который нужно обслуживать вручную. Наоборот, новый канал встраивается в уже существующую работу, а сотрудник подключается только тогда, когда действительно требуется его участие.
Поэтому при проектировании ЛК недостаточно спрашивать, какую работу мы хотим убрать у себя. Нужно сразу смотреть и на вторую сторону: что после этого придется делать поставщику и насколько легко ему будет встроить это в свои процессы?
Когда становится понятно, какие операции нужно автоматизировать, возникает следующий вопрос: обязательно ли для этого разрабатывать отдельный личный кабинет?
Один из вариантов — открыть контрагенту ограниченный доступ непосредственно к части функционала 1С. Для него создается отдельная роль: пользователь авторизуется через браузер и видит только те документы и операции, которые ему доступны. Такой подход встречается на практике и позволяет не создава ть отдельный интерфейс для части процессов.
Другой вариант — отдельный веб-интерфейс, который обменивается данными с 1С, backend сайта и другими внутренними системами компании. Поставщик работает в ЛК, а все необходимое дальше передается туда, где эти данные должны использоваться.
Выбор между этими подходами зависит от самого процесса. Если контрагенту нужно выполнить несколько типовых операций с данными из 1С, отдельный интерфейс может оказаться избыточным. Если же в одной точке нужно объединить прайсы, заказы, документы, складские процессы и данные из нескольких систем, задача уже выходит за рамки доступа к отдельному участку 1С.
При этом отдельный ЛК сам по себе не решает вопрос безопасности. В любом варианте нужно определить, какие данные доступны конкретному контрагенту, какие действия он может выполнять и где проходит граница между внешним интерфейсом и внутренним контуром компании.
Но для поставщика архитектура внутри компании вообще не должна становиться отдельной задачей.
Ему не нужно разбираться, куда отправить прайс для сайта, где подтвердить заказ для 1С, в какую систему загрузить документы и кому отдельно передать информацию для склада. Данные передаются через согласованный канал, а их дальнейшее распределение между системами — уже задача инфраструктуры покупателя.
Поэтому вопрос при выборе архитектуры лучше ставить не как «делать ЛК или дать доступ к 1С?», а как «какой способ позволит провести весь процесс с минимальным количеством ручных действий с обеих сторон?»
И только после того, как сам процесс и необходимый функционал определены, имеет смысл считать, сколько такая автоматизация может дать бизнесу.
Когда мы считали экономику ЛК для одного из наших клиентов, начали с существующего ручного процесса и ФОТ сотрудников, которые в нем участвуют.
На тот момент компания работала примерно с 200 поставщиками. Отдельный ресурс уходил на сопровождение их работы: контроль загрузки прайсов, отправку и подтверждение заказов, получение документов, работу с рекламациями.
Чтобы понять, какую часть этих затрат можно сократить, мы разложили процесс на отдельные операции: что делают сотрудники, как часто это повторяется и сколько времени занимает.
Отдельно выделили работу, где человек действительно нужен: переговоры, согласование нестандартных условий, спорные ситуации. И повторяющиеся действия, которые можно перевести в автоматический контур: проверку статусов, перенос данных между системами, типовые уведомления и другой операционный контроль.
Расчет показал, что после внедрения базового функционала ФОТ на сопровождение процесса мог сократиться примерно на треть, а сам проект — окупиться примерно в течение года. Если учитывать дальнейшее развитие ЛК и автоматизацию дополнительных операций, потенциальный срок окупаемости мог сократиться примерно до полугода.
Конечно, переносить эти сроки на любой другой проект нельзя. Экономика будет зависеть от количества поставщиков, объема операций, состава команды, глубины автоматизации и стоимости разработки.
Причем ФОТ — только одна часть эффекта. Автоматизация может сокращать количество ошибок и задержек, ускорять обработку данных и позволять увеличивать число поставщиков или объем операций без пропорционального расширения команды.
Поэтому считать экономику ЛК лучше не через количество функций, а через изменение конкретного процесса после внедрения: сколько он стоит компании сейчас и сколько будет стоить после автоматизации.
И здесь появляется другая проблема. Когда процессы уже разобраны и становится понятно, сколько всего потенциально можно перенести в ЛК, ТЗ очень быстро начинает расти. Но далеко не каждая функция, которую технически можно реализовать, действительно нужна бизнесу.
Когда компания начинает проектировать ЛК, возникает соблазн посмотреть, что уже есть у других, и собрать максимально полный список функций.
В существующих кабинетах действительно можно найти много полезных решений. Например, отказ от заказа и оформление возврата, выгрузку акта сверки, запрос информации по заказу, скачивание сертификатов и QR-кодов для маркировки.
В других проектах к этому могут добавляться рекламации, пропуска на склад, аналитика, работа с кроссами, тендерные закупки и десятки уведомлений.
Но наличие функции у другой компании еще не означает, что ее стоит включать в свое ТЗ.
Например, если поставщики регулярно приезжают на наемном транспорте, автоматизация заявок на въезд действительно убирает ручную цепочку. Если бизнес работает с большим количеством аналогов автозапчастей, появляется смысл в передаче кроссов. Если компания использует VMI для маркированных товаров, нужен уже совсем другой процесс — обмен кодами между хранителем, ЛК, 1С поклажедателя и ЭДО.
То есть одна и та же функция может быть критичной для одного бизнеса и совершенно бесполезной для другого.
Поэтому перед добавлением очередного пункта в ТЗ полезнее задавать не вопрос «есть ли такая возможность у других?», а три более практических: какую существующую операцию она меняет, кто выполняет ее сейчас и что должно измениться после автоматизации.
Если на эти вопросы нет ответа, функцию, скорее всего, рано включать в первую версию продукта.
Так можно определить и границы MVP. В него попадает не максимальное количество возможностей, а тот набор функций, который закрывает наиболее трудоемкие или критичные участки текущего процесса. Остальные сценарии можно добавлять позже, когда появится подтвержденная потребность.
Но даже правильно выбранный функционал еще не гарантирует, что проект заработает внутри компании. Потому что внедрение ЛК меняет не только IT-систему — оно меняет привычный процесс работы сотрудников.
У личного кабинета должен быть владелец со стороны бизнеса. Это особенно важно в проектах, где после запуска часть привычных операций должна исчезнуть или перейти в автоматический контур. Если раньше сотрудник вручную контролировал получение прайса, передавал информацию между подразделениями или связывался с поставщиком на определенном этапе, после внедрения процесс будет устроен иначе.
Поэтому еще до разработки нужно определить, кто отвечает за весь процесс работы с поставщиками, какие операции компания действительно готова менять и по каким показателям будет оцениваться результат.
Иначе можно разработать технически рабочий ЛК, интегрировать его с 1С и другими системами, но фактически сохранить прежнюю схему работы: сотрудники продолжат пользоваться привычными каналами, дублировать данные и вручную контролировать то, что уже должно происходить автоматически.
Поэтому внедрение заканчивается не в момент, когда личный кабинет вышел в прод. Оно заканчивается тогда, когда изменился сам процесс и те ручные операции, ради которых начинался проект, действительно перестали выполняться по-старому.
Личный кабинет для работы с поставщиками имеет смысл не сам по себе. Его ценность появляется тогда, когда он меняет конкретный процесс внутри компании.
Поэтому начинать такой проект стоит не со списка будущих разделов и не с вопроса, какие функции есть у конкурентов. Сначала нужно разобрать существующую цепочку работы с поставщиком: какие данные он передает, куда они попадают дальше, какие действия выполняют сотрудники и на каких этапах без их участия действительно нельзя обойтись.
Где-то окажется, что человек принимает решение — согласовывает условия, разбирает спорную ситуацию, работает с исключением. А где-то он просто проверяет статус, переносит информацию из одной системы в другую или напоминает контрагенту о следующем действии.
Именно второй тип операций в первую очередь имеет смысл убирать в автоматический контур.
При этом хороший ЛК не обязательно означает, что теперь все действия поставщик должен выполнять в нем самостоятельно. Наоборот: если данные можно получить автоматически по FTP, API или напрямую из учетной системы контрагента, лучше исключить ручную операцию совсем.
Поэтому в одном проекте личный кабинет будет в первую очередь работать с прайсами, заказами и документами. В другом свяжет поставщика со складом. В третьем станет промежуточным звеном между учетными системами двух компаний, как в сценарии с VMI и маркированным товаром.
Но критерий во всех случаях один: после внедрения процесса ручной работы должно стать меньше, а не просто появиться новое место, где ее нужно выполнять.
Если раньше данные переносил сотрудник покупателя, а теперь те же данные вручную вносит поставщик, задача автоматизации не решена. Если же информация движется между системами сама, а люди подключаются только там, где требуется решение или возникло исключение, тогда личный кабинет действительно начинает приносить бизнесу пользу.