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

07.12.23

Бизнес-процессы - Анализ бизнес-процессов

Закупки – больная тема для многих компаний. Основная проблема – широта предметной области и разница в понимании «что такое закупки» разными участниками этого процесса. О том, как правильно оценивать контур проекта автоматизации управления закупками, анализировать требования к автоматизации и гармонизировать интересы разных сторон, пойдет речь в статье.

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

 

 

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

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

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

 

 

Я хочу рассказать:

  • как оценивать контур проекта правильно, чтобы потом не попасть на неучтенные требования и в разного рода риски;

  • какие смежные процессы могут оказаться у вас в контуре проекта автоматизации закупок, и что с этим делать – какие точки связей нужно проверять при обследовании и потом, при формализации требований;

  • и немного еще про кроссфункциональный или процессный подход при автоматизации управления закупками – в том числе, как организовывать такие проекты на территории заказчика.

 

 

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

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

    • Кто-то под закупками понимает только работу с заказами поставщику, или только работу со складом, или только учет ТМЦ – но на самом деле зона автоматизации для управления закупками намного шире.

    • Когда вы заходите в такого рода проекты, очень важна ваша экспертиза – вы должны знать, какие проблемы бывают с закупками, и с чем еще может предприятие столкнуться. Я регулярно помогаю заказчику доформулировать, что он на самом деле подразумевал, когда говорил, что хочет «автоматизировать закупки». Потому что бывает множество скрытых потребностей – об этом мы сегодня тоже поговорим.

  • Вторая проблема связана с тем, что закупочная деятельность – это сквозной процесс. Это всегда:

    • планирование, бюджетирование, выделение финансовых ресурсов на то, что мы закупаем;

    • нормализация НСИ и выверка данных учета, чтобы получать корректную аналитику для планирования тех же самых закупок;

    • балансирование в условиях ограниченных денежных средств и приоритизация – на что мы можем позволить себе выделить средства в определенный момент времени.

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

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

    • если компания работает в оборонной сфере или государственной среде, ей нужно соблюдать требования законодательства по закупочной деятельности – 44-й и 223-й ФЗ;

    • для импортных закупок есть законодательные ограничения по импорту, которые, в том числе, накладывают специфику на автоматизацию;

    • у некоторых поставщиков свои жесткие требования, которые приходится учитывать, и они очень разные;

    • есть ограничения, связанные со спецификой той или иной номенклатуры, которую мы закупаем;

    • если ваше предприятие входит в холдинг, накладываются ограничения управляющей компании;

    • в случае горизонтальной интеграции могут быть еще и взаимодействия с дочерними предприятиями, которые вам тоже что-то поставляют;

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

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

 

 

Чтобы проект по автоматизации управления закупками был успешен, нужно обращать внимание на несколько моментов.

  • Первое – нужно более детально, более углубленно выстраивать предпроектное обследование. До того как мы начнем моделировать и собирать детальные требования к информационной системе, мы должны:

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

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

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

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

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

    • Здесь важно провести нормализацию НСИ, сегментацию (классификацию) номенклатуры, реализовать сценарное планирование, драйверы для планирования и так далее.

    • Для этой цели мы должны у себя в репертуаре иметь номенклатурную матрицу. Вы должны уметь классифицировать номенклатуру по видам и под разные виды номенклатуры предлагать сценарии, драйверы и бизнес-процессы – от планирования до осуществления закупок.

  • И третье – это процессный подход.

    • Поскольку процессов огромное количество, и практически все так или иначе связаны с закупками, у вас должны быть разработаны типовые модели (карты) бизнес-процессов, где обозначены стыки входа и выхода между поставщиками и потребителями результатов закупочной деятельности. Такие карты – это основной инструментарий аналитиков в подобных проектах. Эти карты желательно разработать в привязке к отраслям – потому что в зависимости от номенклатуры процессы закупок в разных отраслях могут быть разными.

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

 

На что важно обращать внимание на этапе оценки проекта.

Во первых, это цели и контур:

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

    • у него проблемы с планированием;

    • у него неликвиды;

    • у него нет связи между планированием закупок и планированием производства, если мы говорим о закупках под производственную деятельность;

    • нет связи между планированием закупок и планированием продаж;

    • то ли еще что-то – наверняка, проблематика есть, о ней обязательно нужно поговорить на этапе предпроекта.

  • Контур проекта. Мы должны договориться с заказчиком:

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

    • Мы должны определиться, что заказчик подразумевает под процессами закупок. Мой любимый пример: встречаемся с клиентом, обсуждаем контур проекта, клиент рассказывает, что ему нужно автоматизировать закупки – всякие разные. Я задаю вопрос: «А работа с договорами поставщиков?» Клиент говорит: «Да, это тоже закупки». Для клиента работа с договорами поставщиков может войти в контур проекта по закупкам, хотя в автоматизации зачастую управление договорами – это документооборот, другая подсистема. Такие вещи тоже желательно уточнять в самом начале.

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

 

Вторая зона, на которую важно обращать внимание – это требования и ограничения.

Определяем внешние ограничения процессов:

  • гос. закупки есть или нет, если есть, то какие федеральные законодательства действуют (44 или 223 ФЗ);

  • есть ли дополнительные требования, связанные со спецификой отрасли (лицензирование, сертификация, проверочные испытания и т.п.);

  • есть ли импорт, и если есть, то где лоцированы поставщики:

    • если в Евросоюзе – это одно;

    • если Китай – другое;

    • если Евроазиатский альянс – третье;

    • а если все в России – четвертое.

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

Например, если у заказчика импортный поставщик, я сразу задаю вопрос: «Вы хотите видеть контроль обеспечения потребностей по факту поступления на склад? Или вам нужно видеть статус вашего заказа по промежуточным перевалочным пунктам – когда он пришел в порт, прошел таможню, погружен в вагон, машину и так далее?» – «Конечно, нужно!, отвечает клиент. И здравствуй, транспортная логистика! Хотя изначально мы говорили про закупки.

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

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

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

Проверяем методологическую готовность:

  • На этапе предпроекта смотрим, какие регламенты и правила по закупкам есть. Есть учетная политика – покажите. Три странички? Считаем, что учетной политики нет и ее придется разрабатывать. Толстый том? Надо смотреть, что там написано. Реально пользуетесь документами? Если учетную политику делали 10 лет назад, никто даже не знает, где она лежит – нет учетной политики. В этом случае в проекте возникает большой блок работ по методологии: либо проектирование с нуля, либо уточнение.

  • Проверяем состав, качество, актуальность НСИ, драйверы и так далее.

 

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

  • Процесс закупки может различаться по технологии планирования:

    • когда мы планируем закупки для производства и продаж – там своя дискретность и драйверы планирования;

    • когда мы планируем закупки для общехозяйственной деятельности – там процесс организован совершенно по-другому.

    • инвестиционные закупки – третий вариант технологии планирования.

  • Процесс закупки может различаться по способу закупки:

    • если используются внешние регулируемые конкурсные процедуры – это один набор процедур и свои требования;

    • если проводятся внутренние конкурсы, нерегулируемые законодательством – другие требования;

    • если без конкурса – третьи, и так далее. Эти тонкости тоже нужно проверять.

  • Процесс закупки может различаться по видам и назначению номенклатуры:

    • если мы закупаем ТМЦ – одна история с организацией процесса и требованиями к системе;

    • если работы – другая;

    • если услуги – третья;

    • если внутренние работы и услуги между подразделениями – четвертая.

Причем, когда мы говорим про закупки, все обычно имеют в виду закупки исключительно ТМЦ. Но на вопрос: «Коллеги, мы в закупки сторонние работы и услуги включаем?», отвечают: «Конечно!» И снова здравствуйте – новый бизнес-процесс.

  • Процесс закупки может различаться в зависимости от локации поставщика – про это я уже проговорила выше.

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

 

Что мы должны увидеть на входе в опроснике на этапе предпроектного обследования:

  • Номенклатура и участники закупок.

    • Внешние/ внутренние, отечественные/импортные закупки.

    • Субъекты, отвечающие за планирование и обеспечение потребностей – разные отделы, разные должности.

  • Процессы в контуре проекта – основные и смежные. Их перечень будет серьезно влиять на объем работ в контуре проекта.

  • Ограничения. Смотрим, кто какие требования может предъявлять к организации закупок – от этого зависят дополнительные требования к автоматизации и расширение функциональности, которая у нас будет в контуре.

  • Методология:

    • Какие правила планирования используем.

    • Есть ли резервирование, обособление.

    • Как учитываем и распределяем затраты.

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

 

Методология – это основная зона нашего риска.

  • Бюджетирование:

    • при планировании мы должны укладываться в правила финансирования, учитывать приоритезацию и так далее;

    • мы должны понимать, как у нас в принципе выстраивается бюджет закупок, и какие требования к закупкам предъявляет бюджетная модель компании.

  • Сценарии планирования:

    • на какой горизонт мы планируем;

    • какие драйверы и правила планирования используем;

    • как обеспечиваем потребности – то ли по заявкам, то ли под поддержание минимального складского запаса, то ли еще как-то.

  • Ответственность за закупки:

    • централизованная или децентрализованная;

    • какова степень самостоятельности подразделений в закупках;

    • кто отвечает за минимальные запасы, за оптимальные запасы, за неликвиды – иногда это тоже разные вещи.

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

  • Учет и хранение:

    • настройка НСИ, физические и логические склады – мы должны сопоставить номенклатуру с группами номенклатуры, складами учета, а потом еще и с физическими складами хранения. Чтобы нормально внедрить информационную систему, нам приходится устранять складской бардак в учете;

    • мы должны описать, как учитывается движение ТМЦ: как регистрируются материально ответственные лица, как происходит выдача ТМЦ материально ответственным, как организован учет по местам хранения;

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

С какими проблемами приходится работать?

  • Планирование потребностей. Я регулярно сталкиваюсь с тем, что:

    • планирование строится на статистике прошлых периодов,

    • закупки для инвестиционной и операционной деятельности четко не разделены или есть путаница, какая номенклатура – инвестиционная, а какая – для операционной деятельности;

    • отсутствует процедура корректировки планов в связи с изменением ситуации – в последнее время это особенно актуально;

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

  • Контроль целесообразности закупок. Здесь проблемы могут быть связаны со следующими аспектами:

    • проверяется ли при формировании заявки, что уже лежит на складе;

    • кто согласует, кто акцептует заявки;

    • есть ли внеплановые закупки и как по ним принимается решение;

    • что мы делаем, если обнаруживается брак или неликвиды, и так далее.

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

  • Учет НСИ. Здесь всегда нужно сначала «разгрести» сложившийся бардак:

    • устранить дублирование;

    • запустить процесс выверки и классификации номенклатуры;

    • распределить ее по складам учета и так далее.

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

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

Выводы:

  • Автоматизация закупок – это автоматизация управления и автоматизация методологии.

  • Качество методологии – основная зона вашего внимания в проекте автоматизации закупок.

 

Теперь поговорим о работе с требованиями. Как я уже говорила, закупки – это сквозной процесс. Если мы говорим об этом процессе глобально, то укрупненно в нем есть 4 этапа:

  • планирование;

  • подготовка;

  • осуществление закупок – непосредственно оперативная деятельность;

  • и завершение обязательств.

На каждом из этих этапов у нас есть:

  • входные требования из других процессов;

  • результаты, которые мы поставляем в другие процессы.

Как вы видите, очень много данных, с которыми закупки соприкасаются с другими процессами.

 

На что нужно обращать внимание:

  • На этапе планирования закупок должны быть учтены и перепроверены требования, возникающие на стыке со смежными процессами:

    • драйверы и начальные данные для планирования – наличие, актуальность, сроки подачи заявок;

    • связи номенклатуры закупок и номенклатуры, которую нужно произвести – это коды, спецификации и так далее;

    • требования бюджетирования – лимиты, источники и приоритеты финансирования.

  • На этапе подготовки закупок нужно учесть:

    • аналоги, замены;

    • данные об условиях и качестве поставщиков;

    • актуальность договоров и так далее.

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

Какие смежные процессы влияют на остальные этапы закупок:

  • На этапе осуществления закупок нам нужно учесть:

    • существующие запасы и наличие излишков;

    • наличие свободных денежных средств, сроки погашения оплаты и условия оплат поставщикам;

    • сроки поставки и так далее.

В этом случае на контур закупок влияют управление ТМЦ, казначейство и логистические процессы.

  • На этапе завершения обязательств нам нужно учесть:

    • наличие денежных средств и сроки оплаты по завершенным обязательствам;

    • блок складских процедур, связанных с регистрацией поступления ТМЦ – проверка по количеству, качеству;

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

Здесь у нас возникает связь с процессами управления ТМЦ и всеми процессами компании, которые были инициаторами закупок. Они потребляют то, что мы для них закупили.

Смежные процессы – это источник дополнительных требований.

  • Из бюджетирования у нас идут:

    • лимиты;

    • различные правила актуализации планов.

  • Из планирования:

    • правила планирования;

    • правила распределения расходов на финансовый результат.

  • Из управления производством и продажами:

    • различные статусы исполнения заказов поставщику;

    • данные по отклонениям в планах, которые будут влиять на поставку материалов/комплектующих для производства.

  • Из управления производственной документацией у нас возникают требования:

    • к результатам входного контроля;

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

  • Из управления договорами тоже возникают требования – их определяют:

    • типовые шаблоны;

    • условия договоров;

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

Смежные подразделения, у которых могут возникать требования к управлению закупками:

  • На этапе планирования закупок требования к процессам могут выставлять:

    • все, кто является инициатором закупок;

    • обязательно – финансовая служба.

  • На этапе подготовки:

    • однозначно договорной отдел;

    • состыковка с заказчиками закупок – с теми, кто участвует в выборе поставщиков, выставляет какие-то требования к закупаемой номенклатуре;

    • и, конечно, бухгалтерия, потому что она у нас выставляет требования к документации.

  • На этапе осуществления закупок источниками требований будут:

    • все подразделения, для которых мы закупаем – они должны знать, в какой момент их потребность будет реализована с учетом всех отклонений;

    • склады – кто отвечает за приемку, входной контроль и учет хранения ТМЦ;

    • логистика;

    • служба качества;

    • бухгалтерия;

    • плановый отдел;

    • и казначейство.

  • И на этапе завершения обязательств:

    • конечно, договорной отдел – они контролируют, что договор исполнен полностью и закрыт;

    • и весь финансовый блок (бухгалтерия, плановый отдел, казначейство) – потому что они деньгами оперируют.

Выводы:

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

  • Нужно внимательно перепроверить, кто должен быть задействован в контуре проекта – соблюдены ли интересы всех смежных подразделений.

 

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

Со стороны исполнителя:

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

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

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

 

Со стороны заказчика – также важно правильно организовать команду:

  • У заказчика должен быть руководитель проекта «Закупки» – человек, заинтересованный в том, чтобы закупки в компании проходили нормально.

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

  • И, естественно, руководители всех подразделений, которые непосредственно участвуют в закупках – если у нас закупает не одно подразделение, а эта функция как-то диверсифицирована.

 

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

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

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

    • Когда мы работаем непосредственно с требованиями по работе с поставщиками, мы работаем с группой, отвечающей за взаимодействие с поставщиками.

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

 

С чем нам приходится сталкиваться в управлении такими проектами?

  • Размытая зона ответственности за результат проекта. Много заинтересованных сторон, а в реальности никто ни за что не отвечает. Кросс-функциональные группы решают этот вопрос, позволяют гармонизировать интересы.

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

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

 

Какие инструменты по работе с требованиями к автоматизации закупок уже есть?

Для методической поддержки аналитиков и руководителей на проектах по автоматизации закупок на Инфостарте есть учебно-методический комплекс «Целевая модель процессов управления закупками: инструменты сбора и формализации требований». Эта модель включает в себя:

  • «Опросник» с ответником – детальный, подробный, страниц на 30-50;

  • модели процессов в графическом виде и их детальное описание в Excel, где выделена специфика – на что обращать внимание при работе с требованиями;

  • плюс видеоматериалы по работе с опросником и моделями процессов.

Эта инструментальная часть входит в курс, который проводится на Инфостарте с открытой датой – по мере появления запросов.

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

 

Вопросы

 

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

А кто инициатор проекта?

Руководство. Владелец бизнеса сказал: «Мне нужна прозрачность».

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

Если у вас заинтересованное лицо – владелец бизнеса, привлекайте финансовую службу туда же, как тяжелую артиллерию.

Руководство пытается давить на закуперов, но они говорят: «Окей, мы сейчас просто перестанем закупать, и у вас встанет работа».

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

Так, чтобы KPI для ваших руководителей отделов закупок стала внедренная система управления закупок, которая была спущена собственником. Если этого нет, вы получите сопротивление – им это невыгодно. Открывайте проект еще раз.

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

  • приказ по компании об открытии проекта;

  • назначение ответственных;

  • обязательно KPI и обязательно в мотивацию.

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

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

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

Трансформация подходов в работе бизнес-аналитика

Анализ бизнес-процессов Бесплатно (free)

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

15.01.2024    830    0    chavalah    3    

7

Технология разработки Рабочих мест для автоматизации производственных процессов и управленческого учета

Кейсы автоматизации Работа с требованиями Анализ бизнес-процессов Бесплатно (free)

Автоматизировать производственные процессы в 1С:ERP без доработки типовых механизмов очень сложно. А дорабатывать типовые механизмы 1С:ERP не всегда оправданно. Решением может стать технология разработки Рабочих мест, которая позволяет автоматизировать самые сложные участки последовательно – шаг за шагом, процесс за процессом. Расскажем о том, как помочь пользователям вводить большое количество данных, не нарушая порядок ввода и полноту заполнения всех необходимых реквизитов, и как вовлечь сотрудников Заказчика в разработку и тестирование функционала Рабочих мест.

26.10.2023    1947    0    user1754524    15    

15

Митинг-накачка перед обследованием клиента

Анализ бизнес-процессов Россия Абонемент ($m)

Из старого когда-то наболевшего. Памятка молодого бойца.

1 стартмани

15.07.2010    36    317    tango    43    

27
Оставьте свое сообщение