Як Bimp не дає провести збиткове замовлення

Замовлення, яке виглядає ідеально

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

Щоб не втратити угоду, Олена погоджується на додаткову знижку. У системі замовлення виглядає прибутковим: собівартість прийнятна, маржа є, документ проходить усі етапи погодження без зауважень.

Тиждень потому фінансовий відділ виявляє: для відвантаження довелося взяти іншу партію комплектуючих — дорожчу. Фактична собівартість виявилася вищою за ту, що бачила Олена в момент продажу. Маржа замовлення — майже нульова.

Паралельно колега Олени створює в системі новий товар і забуває увімкнути серійний облік, хоча для цієї категорії продукції він обов’язковий. Коли за два тижні знадобилося простежити партію цього товару, з’ясовують, що дані просто відсутні.

А коли керівник намагається зрозуміти, що взагалі пішло не так — хто змінив налаштування, коли і чому — відповіді в системі немає. Є тільки поточний стан і здогадки.

Коли подібних операцій — сотні щомісяця, саме вони поступово з’їдають прибутковість бізнесу.

Скільки коштують такі помилки

Для компанії, яка оформлює близько 500 замовлень на місяць, навіть невелика частка таких випадків перетворюється на суттєві втрати:

• 5 замовлень на місяць проходять із втратою маржі в середньому 1 500 грн — через надмірні знижки або неправильну оцінку собівартості, як у випадку Олени;
• 3–4 відвантаження на місяць потребують термінового доукомплектування — через неточну інформацію про доступні запаси;
• керівники та менеджери регулярно втрачають час на пошук причин помилок і перевірку змін у документах заднім числом.

У такому сценарії прямі втрати можуть перевищувати 150 000–200 000 грн на рік. І це без урахування зривів термінів відвантаження, втрати довіри клієнтів та додаткового навантаження на команду.

Проблема Олениної компанії — типова. Ось її основі причини:

1. різні співробітники ведуть облік за різними правилами;
2. менеджер може випадково провести збиткову угоду — і система це не зупинить;
3. зміни в документах залишаються непомітними для керівника;
4. рішення про продаж приймаються на основі загальних залишків, без урахування резервів.

Поки компанія невелика, це вирішується ручним контролем: керівник особисто перевіряє знижки, дзвонить на склад, тримає все в голові. Але з ростом команди ручний контроль перестає встигати за кількістю операцій. Далі — те, як ця сама ситуація виглядає в компанії, де ці чотири прогалини закриті на рівні Bimp.

Рівень 1. Єдині правила для всіх нових товарів

Було. Колега Олени створює товар і забуває увімкнути серійний облік — бо у попереднього товару, який він створював, це налаштування було не обов’язковим. Через кілька місяців у системі накопичуються сотні позицій із різними принципами обліку, і частина історії руху товару просто не існує.

Стало. В Bimp адміністратор один раз централізовано визначає правила створення нової номенклатури: для яких категорій обов’язковий партійний та серійний облік. Коли колега Олени створює новий товар, система сама застосовує потрібні параметри — вибір людини на це вже не впливає. Компанія отримує однаковий, передбачуваний облік незалежно від того, хто саме працює в системі того дня.

Рівень 2. Захист від збиткових продажів ще до відвантаження

Було. Олена бачить прийнятну суму замовлення, узгоджує знижку, проводить документ — і дізнається про реальну збитковість лише через тиждень, коли угоду вже не відкрутити назад.

Стало. В Bimp увімкнено контроль відвантаження товару нижче собівартості. Коли Олена цього разу вводить ціну зі знижкою, система порівнює фінальну суму продажу з собівартістю позиції — і перевірка спрацьовує динамічно, навіть якщо Олена змінить партію, склад чи додасть товар через пошук за артикулом. Собівартість, яку буде списано (включно з дорожчою партією комплектуючих), вища за ціну продажу — і комірка «Сума» одразу підсвічується червоним. Провести чи навіть зберегти документ у такому вигляді неможливо: система показує попередження «Збереження неможливе: у документі є товари з ціною нижче собівартості». Олена бачить ризик ще під час роботи над замовленням, а не після нього, і може або переглянути знижку, або узгодити її свідомо, розуміючи реальну маржу. Контроль переміщується зі щомісячного звіту фінвідділу в момент створення угоди — саме туди, де ще можна щось змінити.

Рівень 3. Повна прозорість усіх змін через Diff

Було. Керівник намагається зрозуміти, чому маржа за минулий місяць нижча за очікувану, і хто саме змінив налаштування облікової картки товару. Ніхто не пам’ятає, історії немає — доводиться перевіряти документи вручну і сподіватися, що хтось згадає деталі.

Стало. В Bimp запущено фоновий Diff-аналіз, який фіксує історію редагування за принципом «було / стало». Наразі механізм повністю працює для «Замовлення покупця» — того самого документа, з якого й почалася історія Олени, а в наступних оновленнях з’явиться і в інших довідниках та документах. У вкладці «Історія змін» керівник бачить хронологію подій: точний час, тип дії та ім’я користувача, який її виконав. Розгорнувши конкретну подію редагування, він одразу бачить таблицю змін по полях — наприклад, поле «Ціна»: було 100, стало 150. Без листування й без здогадок. Історія зберігається рік і автоматично очищується фоновим процесом, а доступ до логів залежить від тарифного пакета компанії. У компанії, де з ERP щодня працюють десятки людей, це перетворює розслідування, яке раніше займало дні, на перевірку, яка займає хвилини.

Рівень 4. Контроль резервів до того, як виникне проблема з відвантаженням

Було. Наступного разу Олена бачить у системі 100 одиниць потрібної позиції та підтверджує нове замовлення — товар же є. Але частина цих 100 одиниць уже зарезервована під інший контракт. Проблема випливає лише перед самим відвантаженням: компанія терміново шукає комплектуючі, платить за дорожчу логістику, а замовлення, яке мало бути прибутковим, з’їдає маржу на форс-мажорі.

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

Рівень 5. Перевірка фактичної рентабельності по кожній угоді окремо

Було. Навіть якщо конкретне замовлення пройшло без червоних підсвічувань, фінвідділ дізнається про його реальну рентабельність лише в загальному місячному звіті — де витрати по десятках угод і проєктів змішані в одну суму. Щоб зрозуміти, чи прибуткова саме Оленина угода з тим клієнтом, потрібно вручну піднімати документи й рахувати вручну.

Стало. У звіті «Накопичена собівартість» з’явився параметр «Проєкт» — з фільтрацією та гнучким групуванням, які можна зберегти в шаблоні звіту. Тепер фінвідділ одним кліком відфільтровує звіт по конкретному замовленню чи напрямку й бачить, скільки реально коштувала угода — з урахуванням усіх партій, знижок і супутніх витрат. Це вже не інструмент, який зупиняє помилку в моменті (як рівні 2 і 4), а спосіб системно перевіряти, чи справджуються очікування щодо маржі по кожній угоді чи проєкту, і вчасно помічати відхилення, які жоден точковий контроль не зловить.

Що змінилося для компанії Олени

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

У Bimp такий контроль побудований на п’яти рівнях:

1. єдині правила створення нової номенклатури;
2. захист від продажів нижче собівартості;
3. повна історія змін через Diff;
4. контроль фактично доступних запасів через резервування;
5. перевірка фактичної рентабельності по кожній угоді чи проєкту в звіті «Накопичена собівартість».

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