Как компании понять, что пора внедрять портал поставщика? (SRM)

Всем привет, я — Антон Белов, управляющий собственник компании Tool-kit.tech. Мы создаем IT-системы, упрощающие жизнь бизнеса.

Мы с вами продолжаем разбирать тему SRM. Supplier Relationship Management или систему управления взаимодействия с поставщиками.

Сегодня мы с вами поговорим о том, как компании подготовиться к внедрению портала поставщика. Тут важно определить, нужно ли вообще его внедрять.

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

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

И вот когда потери, возникающие при исполнении этого процесса, начинают мешать дальнейшему росту и развитию сети, возникают проекты автоматизации отдела закупок - портал поставщика или SRM.

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

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

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

И в этом случае использование может не только не принести результат, но и обернуться серьезными потерями времени в будущем.

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

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

Мы постоянно встречаем необходимость доработки коробочных решений, в которые был встроен функционал SRM.

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

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

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

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

Также не стоит забывать о том, что многие поставщики тоже занимаются автоматизацией. Это означает, что система должна быть готова работать не только с человеком через интерфейс, но и с системами поставщика через API.

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

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

Если же вы занимаетесь автоматизацией бизнес-процессов, то при выборе подрядчика стоит обратить внимание на наличие похожих кейсов.

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

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

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

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

Давайте теперь поговорим про то, как должна выглядеть команда со стороны заказчика, самой важной фигурой здесь будет product-owner или владелец продукта.

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

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

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

Также важно, чтобы продукт оунер возглавлял подразделения, задачи которых в первую очередь покрывает продукт. Это делается для того, чтобы KPI работы подразделения и его руководителя зависел от успешности внедрения.

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

Часто, чтобы внедрить изменения, приходится брать на себя дополнительную работу и, если руководитель подразделения отвечает только за операционные показатели, а product owner за внедрение продукта, у руководителя возникает непонимание, почему он должен брать на себя дополнительную нагрузку и он всячески пытается отложить внедрение.

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

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

Какие обязательные этапы с взаимодействием с подрядчиком при разработке подобных проектов автоматизации?

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

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

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

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

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

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

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

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

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

Выбирая самописное решение, важно правильно выбрать подрядчика. Желательно искать интегратора с релевантным опытом. В команде разработки должны быть как инженеры, так и аналитики и их состав должен быть сбалансированным.

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

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