Построение единого процессного контура на базе Pyrus для запуска косметической продукции «Пурпур»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обязательные поля и единая база данных по процессам
Для форм сформировали список обязательных полей по этапам.
Это решение помогло превратить Pyrus в единую базу данных по запуску продукции. Теперь нужная информация фиксируется не произвольно, а в конкретный момент процесса — тогда, когда она действительно нужна для следующего этапа.

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

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

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

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

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

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

Что получили менеджеры
Для менеджеров Pyrus стал рабочим инструментом, который помогает вести запуск продукции без постоянного ручного контроля в чатах.

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

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

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

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

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

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

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

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

Итог
В результате проекта Pyrus стал для «Пурпур» единым процессным контуром для управления разработкой и запуском косметической продукции.

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

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

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