Ситуация на стартеВсё начиналось непосредственно на строительном объекте.
Прораб или главный инженер определял, какие материалы необходимы, формировал заявку и передавал её на согласование. После этого в процесс подключался отдел снабжения: нужно было найти поставщика, проверить договорные условия, провести оплату и проконтролировать поставку.
В закупке могли участвовать сразу несколько подразделений:
- сотрудники строительных объектов;
- главный инженер;
- отдел материально-технического обеспечения;
- финансовый директор;
- бухгалтерия;
- руководство компании.
При этом заявка могла несколько раз измениться, вернуться на пересогласование или быть отменена.
Отдельная сложность возникала с договорами. Часть закупок проводилась в рамках уже действующих договоров с установленными лимитами, а для других сначала требовалось оформить новый договор.
До внедрения Pyrus информация хранилась в Excel, документах и переписках. Из-за этого было сложно быстро понять, на каком этапе находится закупка, кто сейчас должен с ней работать и сколько средств ещё доступно по конкретному поставщику.
Компании требовалась единая система, которая связала бы заявку, поставщика и договор, провела закупку по всем необходимым этапам и автоматически пересчитывала доступный лимит.
Основой такого решения стал Pyrus.
Сначала описали реальный процессПеред настройкой системы мы не стали сразу переносить существующие таблицы и формы в Pyrus. Сначала разобрали, как закупки действительно проходят внутри компании.
Мы изучили структуру организации, роли сотрудников, используемые документы и весь путь заявки — от возникновения потребности на строительном объекте до получения материалов.
Для каждого этапа определили:
- кто отвечает за задачу;
- сколько времени занимает этап;
- какие данные обязательно нужно указать;
- кто имеет доступ к информации;
- при каких условиях заявка может перейти дальше;
- в каких случаях она возвращается на доработку или отменяется.
После этого реальный процесс перенесли в Pyrus и добавили необходимые автоматизации.
Единая заявка на материалыЦентральным элементом системы стала форма «Заявка».
Инициатор указывает строительный объект и заполняет таблицу с необходимыми материалами. В ней фиксируются позиции, количество, стоимость, поставщики и другие параметры закупки.
При этом вся информация по закупке остаётся в одной карточке. По мере прохождения процесса в неё добавляются:
- первоначальная потребность;
- результаты согласований;
- выбранные поставщики;
- договоры и счета;
- платёжные документы;
- информация об отгрузке;
- подтверждение получения материалов.
Сотрудникам больше не приходится собирать информацию о закупке из нескольких Excel-файлов, документов и переписок. Вся история находится в одной заявке.
Автоматический расчёт итоговой суммыОдна заявка может включать большое количество материалов, поэтому итоговая стоимость рассчитывается непосредственно в табличной части.
Чтобы сотрудникам не приходилось вручную переносить получившуюся сумму, мы разработали отдельный скрипт.
При каждом изменении таблицы он автоматически переносит итог в денежное поле «Итоговая сумма заявки».
Например, сотрудник добавил новую позицию, изменил количество или скорректировал стоимость материала — итоговая сумма автоматически пересчитывается.
Дальше это значение используется в согласовании и при расчёте лимитов поставщиков.
Сквозной маршрут закупкиВ Pyrus настроили единый маршрут, который охватывает весь процесс:
Создание заявки → Согласование главным инженером → Работа отдела снабжения → Выбор поставщика и счёта → Финансовое согласование → Оплата → Подтверждение платежа → Контроль отгрузки → Получение материалов.Сначала прораб или главный инженер формирует потребность строительного объекта.
После проверки заявка передаётся в отдел материально-технического обеспечения. Снабженец подбирает поставщика, добавляет счёт и указывает условия закупки.
Дальше маршрут зависит от способа оплаты.
Если используется расчётный счёт, заявка проходит финансовое согласование и передаётся в бухгалтерию.
Если оплата проводится через специальный счёт, на основании заявок формируется отдельный реестр. Он проходит дополнительную проверку перед оплатой.
После проведения платежа в заявку прикладывается платёжное поручение. Затем задача возвращается сотрудникам строительного объекта — они контролируют отгрузку и подтверждают фактическое получение материалов.
Таким образом, Pyrus сопровождает закупку не только до момента согласования, но и до её фактического завершения.
Работа с договорамиЕсли закупку нельзя провести по действующему договору, в системе запускается отдельный процесс его оформления.
В карточке договора фиксируются:
- поставщик;
- предмет и сумма договора;
- установленный лимит;
- необходимые документы;
- ответственные сотрудники;
- статус согласования и подписания.
Договор проходит проверку финансовым директором. При необходимости его можно вернуть на корректировку, после чего он снова проходит согласование и направляется на подписание.
После подписания данные договора используются при оформлении следующих заявок.
Для договоров, счетов и заявок также настроили автоматическую нумерацию. Это упростило поиск документов и исключило появление одинаковых номеров.
Справочники поставщиков и договоровДля работы системы были созданы отдельные справочники:
- «Поставщики»;
- «Договоры»;
- «Разделы».
В карточках поставщиков и договоров хранится поле «Текущий лимит».
Когда снабженец выбирает поставщика в заявке, Pyrus автоматически обращается к справочнику и показывает доступный лимит прямо в строке таблицы.
Сотруднику не нужно отдельно открывать Excel или искать информацию в другой системе. Он сразу видит, позволяет ли текущий остаток провести закупку.
Автоматический контроль лимитовОдной из самых важных доработок стала автоматизация расчёта лимитов поставщиков.
Система учитывает не только создание новой заявки, но и изменения, пересогласования и отмены. Это особенно важно, потому что в реальной работе закупка редко проходит строго по первоначальному сценарию.
1. Выбор поставщикаКогда снабженец выбирает поставщика, Pyrus находит его в справочнике и показывает текущий доступный лимит непосредственно в заявке.
Сотрудник получает необходимую информацию в рабочей форме и не тратит время на ручную проверку в отдельных таблицах.
2. Согласование заявкиПосле согласования закупки система определяет поставщиков, указанных в табличной части, и уменьшает их лимиты на соответствующие суммы.
Например:
- доступный лимит поставщика — 1 000 000 рублей;
- в заявке согласована закупка на 100 000 рублей;
- после согласования доступный лимит — 900 000 рублей.
Если в одной заявке участвуют несколько поставщиков, система рассчитывает сумму отдельно по каждому из них.
3. Изменение заявкиПосле создания заявки может измениться практически всё: стоимость материалов, их количество или даже выбранный поставщик.
В такой ситуации недостаточно просто пересчитать новый лимит — важно не списать сумму повторно.
Поэтому система сначала восстанавливает лимит с учётом предыдущего состояния заявки, а затем рассчитывает его заново на основании новых данных.
Так мы исключили двойное уменьшение лимита при пересогласовании.
4. Отмена закупкиЕсли заявка отменяется, ранее учтённая сумма возвращается в доступный лимит поставщика.
Для этого в процессе был создан отдельный этап «Заявка отменена».
При переходе заявки на этот этап система:
- определяет всех поставщиков в заявке;
- рассчитывает суммы по каждому из них;
- возвращает эти суммы в соответствующие лимиты;
- фиксирует статус отмены;
- завершает процесс без передачи заявки на оплату.
В итоге справочник показывает не просто первоначальный лимит договора, а его актуальный остаток с учётом всех согласованных, изменённых и отменённых закупок.
Роли и контроль исполненияДля сотрудников настроили роли и права доступа к формам.
Каждый участник получает заявку тогда, когда наступает его этап работы:
- объект формирует потребность;
- главный инженер проверяет её обоснованность;
- отдел снабжения выбирает поставщиков;
- финансовый директор согласовывает расходы и договорные условия;
- бухгалтерия проводит оплату;
- сотрудник объекта подтверждает поставку.
Для отдельных этапов установили обязательные поля и сроки.
Заявка не может перейти дальше, пока в ней нет информации, которая необходима следующему участнику процесса.
При изменении состава команды сам процесс перестраивать не требуется. Нового сотрудника достаточно назначить на соответствующую роль.
Обучение и развитие системыПосле настройки мы обучили сотрудников работе с задачами, формами, комментариями и документами в Pyrus.
Но на этом проект не закончился.
После запуска сотрудники начали работать в системе на реальных закупках, и по результатам использования мы продолжили её дорабатывать: меняли этапы, корректировали обязательность полей, права доступа, правила закрытия заявок и отображение информации.
Такой подход позволил адаптировать Pyrus под реальную работу строительной компании, а не просто перенести первоначальную схему в новую систему.
Что получила компанияВ результате «ШАРКС» получила единый процесс управления закупками строительных материалов.
Теперь одна заявка связывает между собой:
- потребность строительного объекта;
- согласование главного инженера;
- работу отдела снабжения;
- поставщика и договор;
- доступный лимит;
- финансовое согласование;
- оплату;
- отгрузку;
- получение материалов.
Сотрудники работают по понятному маршруту и всегда видят, что уже сделано и кто отвечает за следующий этап.
Руководители получают возможность контролировать текущее состояние закупок без необходимости собирать информацию из разных источников.
А автоматизация лимитов позволяет снабженцу сразу видеть доступный остаток, учитывать согласованные заявки, корректно пересчитывать лимит после изменений и возвращать сумму при отмене закупки.
ИтогКейс проекта «ШАРКС» наглядно показывает, что Pyrus можно использовать не только для согласования заявок, но и для управления всей логикой закупочного процесса.
Мы перенесли в систему полный путь — от появления потребности на строительном объекте до фактического получения материалов. Связали заявки с поставщиками и договорами, автоматизировали расчёт итоговой суммы и контроль доступных лимитов.
Отдельно проработали нестандартные сценарии, которые возникают в реальной работе: закупки у нескольких поставщиков, изменение уже согласованной заявки и возврат лимита при отмене закупки.
В результате Pyrus стал единым контуром материально-технического обеспечения, где заявки, договоры, счета, поставщики и движение закупок связаны в один управляемый процесс.