Чому облік деградує після впровадження: 5 правил

Синдром «старих костилів»: чому облік деградує після завершення впровадження і як цього уникнути

Автор: Інна Троценко, Керівник відділу впровадження (керувала проєктами і самостійно впроваджувала управлінський облік, брала участь у більш ніж 70 проєктах у бізнесах різних сфер: виробництво, гуртова торгівля, медичний бізнес)

Коротко. Після виходу консультантів нова облікова система часто поступово втрачає точність: працівники повертаються до зошитів, таблиць Excel і домовленостей «на словах». Це називають синдромом «старих костилів», тобто обхідних рішень, які з’являються, коли новий процес незручний або лазівки на старий залишилися відкритими. Щоб цього уникнути, керівнику варто закрити шляхи повернення до старого, відрізняти помилки від саботажу, призначити внутрішнього власника системи, регулярно оновлювати регламенти разом із бізнесом і подбати про передачу знань до завершення проєкту.

Ось ситуація, яка трапляється на багатьох підприємствах. Компанія пів року впроваджувала нову систему обліку: витратила значний бюджет, залучила весь відділ, виписала регламенти. Нарешті консультанти чи інтегратори повідомляють: «Система готова, свою роботу ми зробили» — і завершують проєкт.

Минає місяць, другий. Ви заходите в програму й помічаєте, що цифри знову починають розходитися з реальністю. Комірник тихо повернувся до зошита, бо «так швидше». Менеджер із продажів дає знижки поза системою, бо «програма не дає внести спеціальну ціну». Закупник веде власну таблицю в Excel, бо йому зручніше рахувати залишки.

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

Чому працівники повертаються до старих методів

У більшості випадків причина не в лінощах чи злому умислі. Людина обирає шлях із найменшим опором: старий процес знайомий, а новий потребує зусиль і навчання. Якщо старий шлях залишається відкритим, частина команди рано чи пізно ним скористається.

Важливо й те, що «костиль» часто є сигналом про недоліки самого процесу. Подивіться на типові ситуації:

Ситуація 1: Комірник веде паперовий зошит
– Що він каже: «Так швидше»
– Ймовірна причина: Внесення даних у системі займає забагато кроків, або йому не вистачає навчання
– Що робити керівнику: Спростити операцію, залишити потрібні кнопки, провести практичне навчання на робочому місці

Ситуація 2: Менеджер надає знижки поза системою
– Що він каже: «Програма не дає внести спеціальну ціну»
– Ймовірна причина: Регламент не враховує реальний сценарій продажів
– Що робити керівнику: Додати цей сценарій у систему з правилами погодження, а не забороняти знижки як явище

Ситуація 3: Закупник веде окрему таблицю в Excel
– Що він каже: «Мені зручніше рахувати залишки»
– Ймовірна причина: У системі немає потрібного звіту або він незручний
– Що робити керівнику: Налаштувати звіт і прибрати паралельну таблицю

Отже, перед тим як карати за «костиль», варто з’ясувати, що він вирішує. Іноді це порушення дисципліни, а іноді — недопрацьований процес. Докладніше про страхи працівників і опір змінам ми писали в статті «Опір впровадженню обліку на складі та виробництві».

Ознаки, що система починає деградувати

– фактичні залишки поступово розходяться з даними в системі;
– дані з’являються із запізненням: увечері, наприкінці тижня або після нагадувань;
– поруч із програмою знову з’явилися зошити, файли Excel, повідомлення в месенджерах як «офіційні» джерела;
– частина рішень (знижки, видача сировини, закупівлі) ухвалюється усно;
– звіти є, але керівник їм не довіряє й перевіряє все вручну.

Якщо ви помітили два-три пункти, діяти варто одразу, доки нові звички не закріпилися.

5 правил, які допомагають втримати систему після виходу консультантів

1. Закрийте шляхи повернення до старого

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

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

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

2. Відрізняйте помилку від саботажу

Коли після запуску щось іде не за планом (а зазвичай так і буває), перша реакція керівника — штрафи. Але в перші тижні люди помиляються переважно не через зловмисність. Вони плутаються у кнопках, забувають послідовність дій або потрапляють у ситуації, не описані в регламенті.

Якщо одразу вмикати режим покарань, люди починають приховувати помилки й вносити в систему неправдиві дані, аби уникнути санкцій. Для обліку це найгірший сценарій.

Введіть адаптаційний період без штрафів за помилки в системі. Як орієнтир підійдуть 2–3 тижні, для складних процесів довше. Скажіть команді: «Якщо помилилися, прийдіть і покажіть, де саме. Ми разом виправимо помилку й підлаштуємо процес». Це знімає страх, і люди починають працювати в системі, а не імітувати роботу.

3. Призначте власника системи всередині компанії

Поки триває проєкт, за процес відповідає зовнішній консультант чи проєктний менеджер. Після завершення вони йдуть. Кому належить відповідальність далі?

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

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

4. Оновлюйте систему разом із бізнесом

Жоден регламент не пишеться назавжди. Бізнес росте, змінюються логістичні ланцюжки, з’являються нові товари й типи угод. Якщо процес у реальності змінився, а в програмі залишився старим, працівники швидко вигадають новий «костиль».

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

5. Домовтеся про передачу знань і підтримку до завершення проєкту

Багато проблем виникають тому, що акт виконаних робіт підписано без плану на «життя після консультантів». Перед підписанням варто вимагати від інтегратора:

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

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

Висновок

Впровадження обліку не закінчується підписанням акта з розробниками, а лише переходить у нову фазу. Автоматизація — це нова культура роботи, а не разова дія.

Якщо закрити шляхи повернення до старого, дати команді час на адаптацію без штрафів, призначити відповідального за якість даних і регулярно оновлювати регламенти, система залишиться робочим інструментом, а не красивою іконкою на робочому столі.

Поширені запитання

Чому після завершення впровадження працівники повертаються до старих методів?
Найчастіше через те, що старий шлях знайомий і залишається відкритим, а новий процес незручний або погано пояснений. Іноді «костиль» сигналізує, що регламент не враховує реальних сценаріїв роботи, наприклад спеціальних цін чи нестандартних відвантажень.

Хто має відповідати за облікову систему після виходу консультантів?
Внутрішній власник системи: фінансист, старший оператор або головний бухгалтер. Його завдання — стежити за якістю даних, збирати пропозиції щодо змін і доносити їх до керівника.

Як часто перевіряти якість даних в обліковій системі?
Достатньо раз на тиждень вибірково перевіряти кілька операцій: наприклад, простежити шлях п’яти випадкових замовлень від заявки до списання зі складу й оплати. Так розриви в процесі помітні на ранньому етапі.

Що робити, якщо працівники вигадують обхідні рішення?
Спершу з’ясуйте, яку проблему вирішує обхідне рішення: чи не є процес у системі надто складним або неповним. Якщо так, змініть регламент і налаштування. Якщо процес зручний, а правила порушуються свідомо, тоді це питання дисципліни, і воно розв’язується за заздалегідь оголошеними правилами.