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

Собственно, я занимаюсь в «СЕГЕЖЕ» развитием закупок. У меня опыт 9 лет в сфере оптимизации supply chain менеджмента, включая КатМен, управление запасами и автоматизацию. Как я уже сказал, хотел бы поговорить про гибкие подходы закупках. 

Первое, с чего мы начинаем – сколько мы сегодня тратим времени, для того чтобы что-то закупить. И у меня к вам вопрос. Пожалуйста, пройдите тест, опрос, чтобы понять, сколько у вас в компании занимает стандартный RFP. Мы не берем в расчет упрощенную схему, т.е. стандартная закупка с ТЗ от момента получения заявки на закупку до, собственно говоря, выбора победителя. Например, у нас в «СЕГЕЖЕ» по регламенту это 35 рабочих дней, и мы практически никогда в них не укладываемся. 

До выбора победителя у нас 35 рабочих дней по регламенту, т.е. как получили заявку на закупку, начали готовиться к процедуре. Да, вне зависимости. Опять же, я говорил, упрощенные не берем в работу, т.е. дешевые закупки, допустим, до 500 000, мы не проводим процедуры, сами определяем 3 поставщиков, находим каким угодно образом на рынке. Нет, мы сейчас говорим про закупки, где есть ТЗ и стоимостью более какого-то лимита. В нашем случае это 500 000.

Давайте посмотрим результат, что там получается. У кого-то даже есть от 5 до 15. Круто! Большинство, как и мы, это 30-45 дней. Соответственно, логично задаемся вопросом: а сколько же стоит 1 день проведения процедуры для нашего бизнеса? И, собственно говоря, срок…  RFP, он влияет на два ключевых показателя. Это time to market – это то время, за которое мы, допустим, реализуем проект, и он начинает работать и приносить нам ценность или, допустим, время, когда мы хотим нарастить производство, сделать что-то новое. И cycle time – это один цикл в производстве, время, которое нужно, чтобы произвести продукцию нашу. И, соответственно, в случае cycle time мы влияем прямо на запасы, т.е. чем больше мы закупаем, тем больше запасов нам нужно держать, чтобы успеть привезти. А в случае с time to market это, собственно, когда проект начнет работать и приносить ценность.

Мы грубо пытались посчитать в «СЕГЕЖЕ» сколько же у нас стоит RFP. Сделать это довольно сложно. Мы взяли несколько категории, несколько проектов и уже постфактум посмотрели, а если бы мы закупали побыстрее, сколько бы мы сэкономили денег. И, соответственно, нужно найти компромисс между минимальными строками проведения процедуры и тем эффектом, который мы приносим компании. И в некоторых случаях, собственно говоря, эти agile, или гибки практики, могут нам в этом помочь.

Agile-практики можно поделить на два основных направления. Это гибкие каналы закупок и гибкие динамичные подходы к выбору поставщика. Многие из этих подходов вам знакомы. Это и корпоративный маркетплейс, и punch-out каталоги, и выдача заказчикам закупочных банковских карт либо перевод малых закупок на их сторону – они могут за cash пойти что-то купить. И интересная тема по динамичному выбору поставщика – это так называемый beauty contest – конкурсы прототипов, о которых я остановлюсь чуть позже.

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

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

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

Сейчас мы у нас «СЕГЕЖЕ» тоже делаем маркетплейс. Выбрали такую схему, что мы будем пользоваться решением вендоров. Пока не определились с платформой, сейчас находимся на этапе как раз выбора платформы. Но при этом мы не хотели бы жертвовать всеми нашими действующими контролями и максимально хотим их автоматизировать. То есть маркетплейс нашего вендора будет интегрирован с нашей учетной системой, для того чтобы все наши процессы контрольные и учетные, в нашем случае с SAP, они также, как и сейчас существуют, так и продолжали существовать. 

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

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

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

Но можно пойти по-другому. Допустим, даже возьмем наш вариант с маркетплейсом. Мы решили попробовать тему с конкурсом прототипов, т.е. мы для себя поднимаем, какие цели хотим достичь, какие у нас есть требования к этому маркетплейсу, но какую выбрать платформа мы не понимаем и различные технические нюансы для нас пока тоже под вопросом. Поэтому мы вышли на рынок, сделали закрытый конкурс, делаем сейчас и предложим компаниям на основе наших требований предложить свои прототипы. Мы хотим [10:36], посмотреть, что они предлагают, и дальше, собственно, наша комиссия выберет самые интересные прототипы решения, и после этого мы с этим поставщиком пойдем поэтапно это внедрять. Причем внедрение и оплата у нас будет проходить поэтапно с наращиванием функционала и ценности для нашей компании.

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

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

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

Что это все нам дает? На примере «СЕГЕЖЕ» мы смотрели, это нам сокращает Lead time в 2 раза. Мы получим эффект от маркетплейса и еще пары тем где-то, мы посчитали, примерно 40 млн в этом году. И не маловажная тема – это естественно высокий клиентский опыт. Сейчас мы внедрили у себя SAP, сильно усложнили жизнь нашим заказчикам и теперь думаем, как бы ее облегчить, сделать более понятными закупки и удобными.

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

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

Спасибо большое, Артем! А результаты опроса будут доступны коллегам? Можно будет их сбросить в чатик или что-то такое?

Они сами у себя увидят. Если хотят, смогут поделится.

Все, отлично. Потому что я видела, что многие фотографировали, но, наверное, не все. Спасибо! Есть ли вопросы? Да, пожалуйста.

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

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

То есть у вас какие-то максимальные бюджеты на каждый этап, за рамки которого вы не можете выходить, правильно?

Да, как вариант такое может быть.

Спасибо! Есть еще один вопрос за этим столом. И давайте буквально, если есть, еще один и у нас следующие дела.

Алексей Кривосар, «Север Минерал», поставщик комплексных решений для горнорудной отрасли. Скажите, вы предпочитаете идти с такими сложными, непонятными проектами в Time & Material? Или вы идете проекте Fix, где вы фиксируете цену с поставщиком на этапе конкурса красоты или прототипов, и потом вы поэтому проект идете? Ваша практика.

Все прошлые годы это был обычный Fix, сейчас только решили попробовать эти конкурс красоты и прототипов, и в том числе будем, скорее всего, идти в Time & Material по теме маркетплейса.

Пока вы не имели возможности сравнить, что из это эффективнее?

Да.

Спасибо!

Спасибо, коллеги! Еще за этим столом вопрос и за последним у Марии.

Да, спасибо большое. Такой вопрос. Чем конкурсы красоты или прототипов отличается от стандартного процесса RFI? Когда мы перед RFP делаем RFI, чтобы как раз определиться с ТЗ, посмотреть, что есть на рынке. В чем отличие?

Я думаю в том, что вы сразу садитесь выбираете пул поставщиков. Допустим, хотите внедрить какое-то IT-решение, открываете отчет Гартнера текущий, смотрите на правый верхний квадрант, приглашаете этих вендоров к себе в процедуру и сразу вместе с ними, говорите: «Вот, что я хочу получить на выходе. Предложите меня ваши решения». В случае с RFI вы делаете то же самое, но кто-то придет, кто-то не придет, а тут вы сразу с ними садитесь и начинаете работать. И тут есть экономия в том, что после RFI вам не нужно начинать заново процедуру, с ТЗ входить на рынок, получать уже конкретные предложения.

Ок. Спасибо!

Спасибо! И еще микрофон сюда, пожалуйста.

Подскажите, вы, когда проводите agile-закупку, формируя команду, туда привлекаете все смежные подразделения или кого конкретно привлекаете? Или только agile закупку делают через закупщиков?

Лидируют закупщики, привлекаем в команду, собственно, кто будет связан. Например, с маркетплейсом – это у нас айтишники, IT-безопасность, финансисты. Собирается команда и мы вместе смотрим каждый из прототипов.

И, получается, под каждую задачу – это отдельная команда, нет какого-то костяка базового?

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

Спасибо!

Кстати, в случае с RFI то, что говорили, я начинал с RFI, направил в 4 компании RFI, одна только ответила с каким-то предложением, все остальные до сих пор думают.

На этой радостной ноте я предлагаю завершить выступление Артема. Спасибо вам большое!

Да. Спасибо большое!