Продукт EAM система контроля износа рукавов высокого давления

О кейсе

«Еврогидросервис» — ведущая казахстанская компания по продаже, производству, сервисному обслуживанию и ремонту рукавов высокого давления и других деталей, необходимых для работы гидравлического оборудования. Сотрудничает с 11 официальными производителями европейских запчастей и имеет более 600 предприятий-постоянных клиентов.

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

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

Бизнес-контекст

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

Как работали

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

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

Этапы разработки

Аналитика

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

Проектирование и дизайн

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

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

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

Результат

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

Стек

• Backend: Python, Django, DRF, Celery, Postgres, Redis.
• Frontend: TypeScript, Vue, Pinia, ant-design-vue, Tailwind.