Анна Бузова, «Логика молока»: «Начинайте с аудита закупочных процессов, чтобы не получить автоматизированный хаос»

Анна Бузова, вице-президент по закупкам и логистике, «Логика молока», рассказала CFO Russia про типичные методологические ошибки, которые блокируют цифровизацию, и дала рекомендации, как правильно подготовить процессы к внедрению ИТ‑решений в закупках.

Какие устаревшие подходы в методологии закупок чаще всего мешают внедрению автоматизации?

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

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

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

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

Не нужно пытаться оцифровывать такие вещи, как опыт работы компании или количество реализованных ею проектов (10 или 15), и присваивать им какой‑то вес в матрице – скажем, 70% на цену и 30% на качество. В данном случае нет никакого «качества» как отдельного параметра – есть только блокирующие факторы. Попытки использовать некорректные матрицы оценки – это источник ошибок и неэффективности, потому что для автоматизации сначала нужно задать целевые матрицы на концептуальном уровне, а потом уже их автоматизировать.

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

При этом заказчик не должен оказывать давление. Например, говорить: «Мне нравится компания на букву А, а компания на букву Б не нравится», «Не зовите тех, зовите других», «Я работал с этим поставщиком, он мне привычнее, а тех я не знаю, наверное, они не справятся». Закупщик, напротив, должен формировать максимально широкий список потенциальных поставщиков, обеспечивая конкурентную среду. Далее идёт третий этап –формирование короткого списка и проверка его соответствия техническому заданию, которое подготовил заказчик.

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

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

С чего, на ваш взгляд, следует начать построение системы автоматизации закупочной функции, если неэффективности выявлены?

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

Далее важно понять границы автоматизации. Существуют разные процессы: Source-to-Pay (S2P) – от получения заявки на закупку до утверждения финального протокола, контрактинг – заключение контракта на основе утверждённого протокола, Procure-to-Pay (P2P) – этапы от оформления заказа до расчёта с поставщиком. Сначала нужно определиться, что именно мы считаем процессом закупок: все три этапа или только некоторые из них (возможно, включая этап планирования). От этого зависит, какие системы потребуются для автоматизации.

Например, для управления поставщиками подойдёт SRM‑система, контрактинг может быть реализован как в SRM‑системе, так и в ERP‑ и ESM-системе или системе электронного документооборота, P2P‑процессы также могут быть автоматизированы с помощью SRM‑ или ERP‑систем. Поэтому важно сначала определить границы процессов, которые планируется автоматизировать, а затем детально прописать целевые бизнес‑процессы внутри этих границ – именно они станут основой для дальнейшей автоматизации.

Ваш совет коллегам: как сделать автоматизацию максимально эффективной?

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

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

В‑третьих, нужно грамотно организовать управление проектом: решить, будете ли вы привлекать консультантов или интеграторов, кто будет отвечать за проект (ИТ‑служба, отдел закупок), получит ли инициатива поддержку руководства. Важно продумать, как будет осуществляться управление проектом, включая тайминги, отчётность, работу комитетов и прочие организационные моменты.

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

Мария Харитонова