Чтобы понять, что происходит с конкретной закупкой, приходится обращаться к сотрудникам, искать информацию в нескольких системах или собирать данные вручную. Нельзя быстро увидеть, на каком этапе находится заявка, кто сейчас с ней работает, соблюдаются ли сроки и где возникло отклонение.
Чем больше одновременно идет закупок, тем сложнее руководителю контролировать их таким способом.
Согласование одной и той же заявки может занимать разное время, документы возвращаются на доработку, ответы поставщиков приходится запрашивать повторно, а сотрудникам — вручную отслеживать, завершен ли очередной этап и кто должен продолжить работу.
В результате сложно заранее определить срок завершения закупки и вовремя заметить отклонение от планового графика. Для производства, строительства и других процессов, связанных с жесткими сроками, это создает риск задержек в обеспечении необходимыми товарами и услугами.
Значительную часть рабочего дня занимают действия, которые не требуют анализа и принятия решений: перенос данных между системами, рассылка запросов и напоминаний, проверка статусов, сведение предложений поставщиков в сравнительную таблицу, подготовка типовых документов и отчетов.
Чем больше закупок, тем больше времени уходит на такую административную работу. В результате у закупщиков остается меньше времени на анализ предложений, переговоры, поиск новых поставщиков и проработку возможностей снизить закупочные затраты.
Информация о контрагенте часто хранится в нескольких местах: реквизиты — в корпоративной системе, документы — в файловом хранилище, переписка — в почте, результаты прошлых закупок — в таблицах или других источниках.
Перед новой закупкой приходится отдельно искать сведения о том, в каких процедурах поставщик участвовал, какие условия предлагал, соблюдал ли сроки, были ли претензии и нарушения.
Часть информации остается только у сотрудников, которые работали с поставщиком. При их переходе на другую должность или уходе из компании восстановить историю взаимодействия становится сложнее.
В процедурах регулярно участвуют одни и те же компании, а новые поставщики привлекаются редко. В результате закупщик получает меньше альтернативных предложений и может не увидеть более выгодные цены или условия.
При большом количестве закупок сложно вручную отслеживать, по каким товарам и услугам закупщики постоянно обращаются к одному и тому же кругу поставщиков и где стоит расширить число участников.
Когда данные приходится вручную переносить из одной системы или документа в другой, сотрудник может неверно указать цену, срок, реквизиты или пропустить часть информации.
Проблему усугубляет работа с несколькими версиями документов и таблиц. Можно использовать устаревший файл или не учесть изменение, которое осталось только в переписке.
При большом количестве одновременно идущих закупок такие ошибки сложнее вовремя обнаружить и исправить.
Если сроки и изменения по поставке отслеживаются в разных источниках, информация об отклонении может появиться уже после того, как срок нарушен.
К этому моменту задержка уже может повлиять на производственный план, строительный график или работу внутреннего заказчика, а времени на поиск альтернативы остается меньше.
В крупной компании подразделения со временем формируют собственные шаблоны документов, маршруты согласования и правила проведения схожих закупок.
В результате одинаковые по сути задачи выполняются по разным сценариям. Руководству сложнее контролировать соблюдение общих требований и сопоставлять результаты подразделений.
Перед началом проекта нужно определить, какие результаты компания ожидает от SRM, кто будет принимать ключевые решения и какие показатели покажут, достигнут ли ожидаемый эффект.
Формулировка «внедрить SRM» не задает ориентиров для проекта. Нужны конкретные изменения в работе закупочной функции:
Чтобы понять, дала ли SRM ожидаемый эффект, нужно знать исходные значения показателей.
Если компания хочет сократить срок согласования, нужно измерить, сколько он занимает сейчас. Если задача — уменьшить объем рутинной работы, следует определить, сколько времени закупщики тратят на перенос данных, подготовку отчетов, рассылки и другие операции. Если компания хочет увеличить число участников закупок, стоит зафиксировать среднее количество предложений по основным группам товаров и услуг.
Без такой отправной точки после запуска системы трудно понять, насколько изменились показатели.
Ключевые решения по закупочным процессам должен принимать представитель бизнеса, который отвечает за результат проекта. Обычно это директор по закупкам или руководитель закупочной функции.
Именно он определяет приоритеты, согласовывает изменения процессов и решает спорные вопросы. Например, какие согласования действительно необходимы, где можно унифицировать правила работы и какие функции нужно реализовать на первом этапе.
В проект должны войти сотрудники, которые знают, как закупки проходят в реальной работе, а не только по регламентам:
Состав команды зависит от процессов, которые должна охватывать SRM. Если в системе планируется контролировать исполнение поставок, к работе нужно подключить сотрудников, которые занимаются этим процессом. Если затрагивается договорная работа — представителей юридической службы.
На старте легко перейти сразу к обсуждению экранов, отчетов, маршрутов и других функций будущей системы. Но до анализа текущих процессов такой список часто отражает привычный порядок работы, а не то, как процесс должен выглядеть после автоматизации.
Сначала нужно понять, где возникают задержки, какие действия выполняются вручную, где дублируются данные и какие исключения действительно необходимы. Иначе в SRM можно перенести существующий процесс почти без изменений — вместе с лишними согласованиями и дублирующими действиями.
До анализа процессов полезно собрать документы и данные, которые показывают, как закупки организованы сейчас:
Не нужно заранее подробно описывать весь процесс. Эти материалы станут фактической основой для анализа текущей работы.
После анализа текущей работы нужно определить, что именно изменится после внедрения SRM. Этот этап отвечает не на вопрос «как работает сейчас», а на вопрос «как должно работать после автоматизации».
По результатам анализа нужно решить, какие согласования, повторный ввод данных, ручные проверки и другие действия можно исключить. Не стоит переносить в SRM операцию только потому, что она есть в текущем процессе.
За сотрудниками остаются действия, где нужны анализ, переговоры, оценка условий и принятие решений. Системе можно передать маршрутизацию заявок, уведомления и напоминания, сбор и передачу данных, формирование типовых документов и фиксацию действий.
Для основных типов закупок нужно зафиксировать последовательность действий: кто создает заявку, когда подключается закупщик, где требуется согласование, как выбирается поставщик и куда передается информация после завершения каждого этапа.
Одновременно определяют роли участников и права, необходимые им для выполнения этих действий.
Маршруты и действия лучше привязывать к понятным условиям. Например, порядок согласования может зависеть от суммы, подразделения, вида товара или услуги, способа закупки. Это позволяет не создавать отдельный сценарий для каждого возможного сочетания условий.
До настройки системы полезно взять несколько типичных закупок и пройти их по новой схеме. Так можно заранее увидеть лишние шаги, недостающие данные, спорные роли и исключения, которые не были учтены.
После определения состава первого этапа нужно подготовить данные для SRM и определить, как система будет обмениваться информацией с другими корпоративными системами.
В SRM обычно используются данные, которые уже есть в других системах компании. Например:
Для каждого вида данных нужно определить источник. Если одна и та же информация хранится в нескольких местах, заранее решают, какой источник считается основным.
Переносить в новую систему данные «как есть» не всегда разумно. В справочниках могут быть дубли поставщиков, неактуальные контакты, разные варианты наименований одной компании и устаревшие записи.
Перед загрузкой данные нужно проверить и определить, какие из них действительно понадобятся после запуска SRM. Особенно это важно для информации о поставщиках: если перенести несколько карточек одной компании, неполные реквизиты и устаревшие сведения, качество данных не улучшится после перехода в новую систему.
Необязательно загружать в SRM все данные за прошлые годы. Нужно определить, какая информация действительно понадобится пользователям после запуска: данные о действующих поставщиках, результаты последних закупок, актуальные договоры, оценки, сведения о нарушениях и претензиях.
Чем больше исторических данных переносится, тем больше времени потребуется на их подготовку, очистку и проверку. Объем переноса лучше определять исходя из того, какие сведения будут использоваться в работе и аналитике.
Если нужные данные уже хранятся в других корпоративных системах, их можно передавать в SRM автоматически, без ручного переноса.
Нужно определить, какая информация будет передаваться между системами: заявки на закупку, сведения о сотрудниках и подразделениях, номенклатура, данные о поставщиках, бюджеты, результаты закупок, заказы, информация об исполнении.
Для каждого обмена фиксируют, какая система является источником данных, куда они передаются и в какой момент должен происходить обмен.
На первом этапе нужно реализовать интеграции, без которых нельзя выполнить выбранные процессы.
Например, если заявка создается в другой системе, ее данные должны поступать в SRM. Если результат закупки используется для формирования заказа в другой системе, его нужно передавать туда автоматически.
Остальные интеграции можно перенести на следующие этапы внедрения и добавлять по мере подключения новых процессов и функций.
До разработки интеграций нужно зафиксировать состав передаваемых данных и правила обмена: какие поля передаются, в каком направлении, как часто, что происходит при изменении данных, какая система считается источником актуальной информации и как обрабатываются ошибки передачи. Чем точнее эти правила определены заранее, тем меньше спорных ситуаций возникает при разработке и тестировании интеграций.
После согласования процессов, данных и интеграций начинается реализация системы: SRM разворачивают в выбранной инфраструктуре, настраивают под утвержденный порядок работы, подключают обмен с другими системами и выполняют необходимые доработки.
До начала настройки система должна быть развернута и доступна проектной команде.
Если SRM устанавливается в инфраструктуре заказчика, ИТ-служба и поставщик подготавливают необходимые серверные ресурсы, устанавливают компоненты системы, настраивают доступ и выполняют требования информационной безопасности.
Если используется облачная версия, устанавливать систему в инфраструктуре заказчика не требуется. Поставщик предоставляет готовую среду, после чего настраиваются доступы и взаимодействие с корпоративными системами.
Технические детали этого этапа в основном находятся в зоне ответственности ИТ-службы и поставщика SRM. Для проекта важно, чтобы к началу настройки была готова среда, в которой можно реализовывать и проверять процессы первого этапа.
После развертывания SRM в системе настраивают утвержденный порядок работы.
В частности:
Настройки должны соответствовать процессам, согласованным на предыдущих этапах.
На этом этапе настраивают автоматический обмен данными с другими корпоративными системами: например, передачу заявок, справочников, результатов закупок.
Данные должны передаваться без дополнительных ручных операций и появляться там, где они нужны участникам процесса.
Если стандартных возможностей SRM недостаточно для согласованного процесса, выполняют индивидуальные доработки.
Это может быть особая логика проведения закупки, дополнительная форма или другая функция, необходимая для процессов первого этапа.
Перед тестированием нужно убедиться, что все, что входит в первый этап, готово к проверке:
Тестирование и пилот решают разные задачи. Сначала систему проверяют на подготовленных сценариях, затем — в реальной работе на ограниченном объеме закупок.
Нужно пройти основные сценарии целиком: создать заявку, провести согласование и закупочную процедуру, получить предложения, выбрать поставщика и передать результат дальше.
Если SRM устанавливается в инфраструктуре заказчика, ИТ-служба и поставщик подготавливают необходимые серверные ресурсы, устанавливают компоненты системы, настраивают доступ и выполняют требования информационной безопасности.
На этом этапе выявляют ошибки в настройках, интеграциях и доработках до начала реальной работы.
Систему должны проверять не только разработчики и проектная команда, но и сотрудники, которые будут работать в ней ежедневно. Закупщики, внутренние заказчики и руководители быстрее замечают лишние действия, непонятные статусы, неудобный порядок заполнения данных или отсутствие нужной информации на конкретном этапе.
После тестирования часть закупок проводят уже в SRM. Для пилота лучше выбрать типовые закупки и ограниченный круг пользователей.
Пилот показывает то, что сложно проверить на тестовых сценариях: насколько понятен новый порядок работы, сколько времени занимают операции, где сотрудники продолжают использовать Excel и почту, хватает ли им информации и не появились ли новые ручные действия.
Если стандартных возможностей SRM недостаточно для согласованного процесса, выполняют индивидуальные доработки.
Это может быть особая логика проведения закупки, дополнительная форма или другая функция, необходимая для процессов первого этапа.
По итогам пилота появляется список замечаний. Ошибки, которые мешают провести закупку или приводят к неверным данным, нужно исправить до запуска. Улучшения интерфейса, дополнительные отчеты и пожелания отдельных пользователей можно перенести на следующие этапы.
До полноценного запуска сотрудники должны освоить новый порядок работы, а поставщики — понять, как участвовать в закупках через SRM.
Обучение лучше строить не вокруг функций системы, а вокруг задач, которые выполняет каждая группа пользователей.
Так сотрудникам не приходится изучать весь функционал SRM — достаточно освоить действия, которые нужны им в работе.
Если после внедрения меняются маршруты согласования, обязательные данные, роли участников или порядок взаимодействия с поставщиками, это нужно отдельно объяснить сотрудникам.
Иначе часть пользователей продолжит работать по старой схеме: вести параллельные таблицы, пересылать документы по почте или дополнительно согласовывать действия, которые уже предусмотрены в системе.
После обучения у сотрудников все равно будут возникать вопросы. До запуска нужно определить, куда они будут обращаться и кто сможет помочь.
Нужно заранее подготовить короткие инструкции по основным операциям, собрать ответы на частые вопросы, определить контакты для обращений, установить порядок сообщения об ошибках и назначить сотрудников, которые будут помогать пользователям в первые недели работы.
Если поставщики должны регистрироваться в SRM, получать приглашения и подавать предложения через личный кабинет, их нужно заранее проинформировать об изменениях.
Им следует сообщить, как зарегистрироваться в системе, какие данные и документы потребуются, как получить приглашение на закупку, как подать предложение и куда обращаться по техническим вопросам.
Если поставщик впервые начинает работать с SRM уже после получения приглашения на закупку, часть времени до окончания приема предложений уйдет на регистрацию, оформление доступа и освоение системы. В результате у него останется меньше времени на подготовку самого предложения.
Если база контрагентов большая, не обязательно сразу регистрировать в системе всех поставщиков компании. Сначала достаточно перевести на новый порядок тех, кто участвует в закупках первого этапа.
После того как регистрация, инструкции и помощь поставщикам отработаны на этой группе, тот же порядок можно распространить на остальных контрагентов.
После пилота и обучения пользователей SRM переводят в рабочий режим для процессов и подразделений, которые вошли в первый этап.
Нужно установить, с какой даты выбранные виды закупок проводятся только в SRM, а также решить, что делать с закупками, начатыми до запуска системы.
Если сотрудники смогут по своему выбору вести закупку в SRM, Excel, почте или прежних сервисах, часть процессов останется вне системы. В результате информация по закупкам снова будет распределена между разными источниками.
Закупки, которые уже находятся на поздних этапах, не всегда имеет смысл переносить в SRM. Для этого придется восстанавливать в новой системе документы, статусы и уже выполненные действия.
Поэтому заранее определяют, какие текущие закупки завершаются по прежнему порядку, а какие переносятся в SRM.
После запуска возникают ситуации, которые не встретились во время обучения и пилота. Кроме того, часть настроек может потребовать уточнения уже на реальных закупках.
В первые недели нужно:
После запуска пользователи начинают предлагать изменения. Не все из них нужно сразу включать в доработку.
В первую очередь исправляют то, что мешает провести закупку, приводит к неверным данным или нарушает согласованный процесс. Изменения, которые делают работу удобнее, но не мешают использовать систему, можно перенести на следующие этапы.
Сам факт запуска SRM еще не означает, что сотрудники полностью перешли на новый порядок работы.
Нужно проверить:
Если часть работы остается вне SRM, нужно выяснить причину: не хватает необходимой функции, пользователи не освоили новый порядок или отдельные действия по-прежнему выполняются вне системы.
После того как система некоторое время проработала в штатном режиме, можно оценить результат внедрения.
До начала проекта были зафиксированы показатели и результаты, которых компания ожидала от SRM. Теперь их нужно сравнить с фактическими значениями.
Например, если целью было сократить срок согласования заявок, нужно проверить, насколько он изменился. Если планировалось уменьшить объем ручной работы — сколько таких операций удалось убрать. Если компания хотела увеличить число поставщиков, участвующих в процедурах, нужно сравнить среднее количество поставщиков, которые фактически подают предложения.
Так можно понять, насколько достигнуты цели, поставленные перед внедрением.
Закупки, которые уже находятся на поздних этапах, не всегда имеет смысл переносить в SRM. Для этого придется восстанавливать в новой системе документы, статусы и уже выполненные действия.
Поэтому заранее определяют, какие текущие закупки завершаются по прежнему порядку, а какие переносятся в SRM.
Не все результаты можно оценить только цифрами. Поэтому нужно вернуться к проблемам, которые были определены перед внедрением, и проверить, остались ли они.
Если такие проблемы сохраняются, нужно понять причину: не хватает функций, процесс был спроектирован неудачно, сотрудники продолжают работать вне системы или часть возможностей SRM используется не полностью.
В первые недели сотрудники еще осваивают систему, исправляются ошибки и уточняются настройки. Показатели этого периода могут заметно отличаться от тех, которые будут после перехода к обычной работе.
Оценивать эффект лучше после того, как основные процессы стабильно работают в SRM, а сотрудники освоили новый порядок.
После первого этапа уже видно, какие задачи остались нерешенными и какие возможности потребуются дальше. Это могут быть автоматизация дополнительных видов закупок, подключение новых подразделений, расширение работы с поставщиками, новые интеграции, дополнительная аналитика и контроль исполнения поставок.
Следующие этапы развития SRM можно планировать на основе фактических результатов и опыта работы пользователей, а не только первоначальных предположений.