Кейси / Виробництва · Платформа від замовлення до відвантаження
Клієнт під NDA Інтеграції та розрахунки

Замовлення доходить до цеху за години замість днів, і вчасно їде 92% відвантажень замість 70%.

70% → 92%
відвантаження вчасно
4 дні → 4 години
від замовлення до запуску в цех
~4 міс
до повного контуру

Клієнт під NDA: галузь і розмір указані діапазоном. Цифри — з боку клієнта, порівняння періодів до і після запуску; на схожих проєктах результат відрізнявся в обидва боки. Порахувати на своїх обсягах →

Контекст

Дні губилися між підтвердженням замовлення і запуском у цех.

Серійне виробництво, близько 200 співробітників, один майданчик. Замовлення приходили на пошту і в CRM, менеджер переносив їх у таблицю, а потребу в матеріалах постачання рахувало руками — за специфікацією виробу з іншої таблиці та за залишками з облікової системи, які відставали на день-два. Кожен крок був перебиванням даних, і на кожному губився день: до змінного завдання замовлення доходило через три-п’ять днів після підтвердження. Частина партій зупинялася вже в цеху, бо матеріалу не вистачило, і з’ясовувалося це в момент запуску, а не до нього. Строки клієнту називали із запасом, і все одно приблизно кожне третє замовлення їхало пізніше обіцяного. Залишки на складі жили у двох місцях — в обліковій системі та в голові комірника.

Рішення

Одна платформа між замовленням, специфікацією і складом.

Стек той самий, що й на решті проєктів: Python і Django в ядрі, PostgreSQL як джерело істини щодо замовлення, специфікації та матеріалу. Замовлення вводиться один раз, платформа розкриває партію в потребу за специфікацією виробу, рахує її проти фактичних залишків і вже розміщених закупівель, а дефіцит перетворює на заявку постачанню сама. Облікову систему ми не замінювали — вона лишилася системою обліку і документів, платформа обмінюється з нею даними.

Архітектура
Замовленняпошта · CRMСпецифікаціїнорми і техпроцесСкладзалишки і партіїЗакупівлізаявки і строкиЯдро платформизамовлення · специфікація · матеріалОблікова системаоблік і документиЗмінне завданняцех і дільниціПостачаннязаявки постачальникамСтатуси замовленняменеджер і клієнтЗвітистроки і собівартість
Що побудували

Шість контурів за чотири місяці.

Порядок обирали за грошима: спершу те, що прибирає втрачені дні, потім усе інше.

01
Замовлення і специфікація
Замовлення входить один раз і розкривається в потребу за специфікацією виробу. Специфікації та норми витрат живуть в одному місці й в одній версії, а не в таблиці у технолога і ще одній у постачання.
02
Потреба в матеріалах
Рахується проти фактичних залишків і вже розміщених закупівель. Дефіцит іде в постачання заявкою, а не листом, і видно його до запуску, а не в цеху.
03
Запуск у цех
Змінне завдання платформа збирає сама — із замовлень, під які матеріал є, — і пояснює кожен рядок: що чим обмежено і що доведеться зсунути. Начальник виробництва затверджує або змінює. Від замовлення до змінного завдання стало кілька годин замість трьох-п’яти днів.
04
Склад і списання
Списання йде за фактом випуску, а не раз на тиждень, і залишки перестали розходитися з обліковою системою.
05
Строки і статуси
Статус замовлення видно менеджеру і клієнту, і менеджер більше не ходить у цех питати, де замовлення. Вчасно стало їхати 92% відвантажень замість 70%.
06
Звіти
Собівартість рахується за замовленням, а зриви строків розкладені за причинами — брак матеріалу, переробка, простій, — а не зведені в одне «не встигли».
До і після

До і після.

До
Відвантаження вчасно~70%
Від замовлення до цеху3–5 днів
Специфікаціїу таблицях
Потреба в матеріалахза вчорашніми залишками
Дефіцит матеріалуз’ясовується в цеху
Списання зі складураз на тиждень
Собівартість замовленняпісля закриття
Після
Відвантаження вчасно~92%
Від замовлення до цехугодини
Специфікаціїодна версія
Потреба в матеріалахпроти факту і закупівель
Дефіцит матеріалудо запуску
Списання зі складуза фактом випуску
Собівартість замовленнявидно на ходу
Межі автоматизації
Що лишилося за людьми — навмисно.
—Норми витрат і техпроцес. Їх задає технолог; платформа рахує за ними, але не вигадує їх.
—Затвердження змінного завдання. Платформа збирає його і пояснює кожен рядок, але натискає начальник виробництва, а не автомат.
—Перемовини з постачальником щодо строків і ціни. Заявка йде автоматом, домовляється людина.
—Приймання матеріалу за якістю. Це очі й руки, а не рядок у накладній.
Стек
Python Django PostgreSQL Обмін з обліковою системою Черги задач Звітність Моніторинг і алерти
Відверто про те, де були втрати

Дні губилися не в цеху, а між системами.

Цех працював нормально, і ми не чіпали ні обладнання, ні людей на дільницях. Губилося між підтвердженням замовлення і запуском: чотири перебивання даних поспіль, і на кожному день. Облікову систему ми теж не замінювали — вона лишилася на місці, платформа стала поруч і обмінюється з нею даними. Чотири місяці пішли не на код: норми витрат і специфікації довелося привести до ладу, бо рахувати потребу в матеріалах немає за чим, якщо норми живуть у трьох версіях. Цю частину робив технолог з боку клієнта, і без неї запуск був би безглуздим.

Повʼязане

З чого зібраний цей кейс.

Сторінки послуг пояснюють метод, за яким зроблений цей проєкт; сторінки рішень беруть ті самі блоки окремо — кожен зі своїм обсягом і ціною.

Хочете те саме для свого процесу?

Безкоштовний міні-аудит покаже ROI для найважливішого процесу — далі розробка за фіксованою ціною.

Безкоштовний міні-аудит →