Чому саме ці сім
У впровадженні сотні рішень, і майже всі можна переграти. Не сподобалась форма документа — змінили. Не вистачає поля — додали. Помилилися з правами доступу — переналаштували за годину.
Але є сім, які або не змінюються взагалі, або змінюються ціною повторного запуску. Їх ухвалюють на першому-другому тижні проєкту, коли ще нічого не зрозуміло, і ніхто не попереджає, що це назавжди.
Список складений за тим, що ми бачили на проєктах. Кожен пункт — про те, що станеться, якщо вирішити неправильно, і як перевірити себе до того.
1. Валюта обліку
Що вирішується: у якій валюті ведеться головна книга.
Чому назавжди: змінити після старту практично неможливо. Це перезапуск системи з новою базою й повторна міграція.
Окремо існує додаткова валюта звітності — паралельний облік у другій валюті. Її теж вмикають на старті: додати заднім числом означає перерахувати всю історію.
Як перевірити себе: є іноземні власники? Плануєте залучення інвестицій? Звітуєте в групу? Якщо хоч одне «так» — вмикайте додаткову валюту одразу, навіть якщо зараз вона не потрібна. Механіка — у статті про валютний облік.
2. Структура аналітик
Що вирішується: у яких розрізах ви бачите цифри — підрозділ, напрямок, проєкт, менеджер, регіон.
Чому назавжди: технічно аналітику можна додати будь-коли. Але вона не з’явиться заднім числом у вже проведених документах. Тобто рік ви будете жити без порівняння з минулим періодом.
Це найнедооціненіше рішення зі списку. Аналітики визначають не лише звітність: на них будуються бюджети, обмеження доступу за даними та аналіз знижок.
Як перевірити себе: випишіть п’ять питань, на які ви хочете отримувати відповідь щомісяця. Якщо серед них є «скільки заробив цей напрямок» або «яка маржа за цим менеджером» — відповідні аналітики мають бути на старті. Деталі — у матеріалі про аналітики.
3. План рахунків
Що вирішується: структура рахунків і те, що ви кодуєте номером рахунку.
Чому дорого: формально план рахунків змінюється. Практично — після року роботи перебудова означає перепроведення документів і розходження з попередніми періодами.
Типова помилка: закодувати аналітику в номер рахунку. Окремий субрахунок під кожен напрямок, під кожен склад, під кожен проєкт. План рахунків розростається до сотень позицій і продовжує зростати з кожним новим напрямком бізнесу.
Як перевірити себе: подивіться на свій нинішній план рахунків. Якщо в ньому є субрахунки, що відрізняються лише напрямком або підрозділом, — це аналітика, а не рахунки. Переносити таку структуру в нову систему не треба.
4. Одна середовище чи кілька
Що вирішується: якщо юридичних осіб кілька — вони живуть в одному середовищі чи в різних.
Чому назавжди: розділити спільне середовище пізніше означає міграцію. Об’єднати роздільні — звіряння довідників, які роками розходились.
Компанії в одному середовищі ділять довідники, користувачів і графік оновлень. Це зручно, поки одній із них не знадобиться локалізація, що конфліктує із загальним шаблоном.
Як перевірити себе: чи торгують ваші юрособи одна з одною? Чи однакові в них процеси? Якщо процеси суттєво різні — краще роздільні середовища, навіть якщо це виглядає надлишковим.
5. Глибина історії при міграції
Що вирішується: скільки років минулих документів переїжджає в нову систему.
Чому назавжди: дотягнути історію після запуску теоретично можна, практично — ніхто цього не робить. Це повторна міграція з повторною звіркою.
Перенесення повної деталізації за п’ять років може коштувати більше, ніж уся решта міграції. Звертаються до цих даних, за нашим досвідом, кілька разів на рік.
Як перевірити себе: скільки разів за минулий рік вам знадобився документ старший за два роки? Якщо відповідь «один-два» — переносьте залишки й рік оборотів, решту лишіть у старій базі в режимі читання. Порядок — у статті про міграцію даних.
6. Доробка чи зміна процесу
Що вирішується: процес не лягає у стандарт — ви дописуєте систему чи міняєте процес.
Чому назавжди: кожна доробка коштує двічі: при написанні і при кожному оновленні двічі на рік. Через три роки набір доробок стає окремою системою, яку супроводжує лише той, хто її писав.
Частина запитів на доробку насправді означає «ми звикли робити так», а не «інакше не можна». Розділити ці два випадки — окрема робота, і вона окупається.
Як перевірити себе: для кожної доробки спитайте, що станеться, якщо її не зробити. Якщо відповідь «буде незручно» — це звичка. Якщо «порушимо законодавство» або «втратимо клієнта» — це вимога. Критерії — у статті про доцільність кастомізації.
7. Дата відключення старої системи
Що вирішується: коли стара система перестає працювати.
Чому назавжди: формально дату можна перенести. Практично — якщо її не призначили до старту, паралельний період не закінчиться ніколи.
Механіка проста: поки стара система доступна, люди повертаються туди, бо там звичніше. Дві системи ведуться неповно, дані розходяться, і через півроку ніхто не може сказати, де правда.
Як перевірити себе: дата має бути в договорі або в плані проєкту, а не «десь через місяць після запуску». І бажано припадати на початок періоду.
Що з цим робити
Ці сім рішень ухвалюються на першому-другому тижні, коли ви ще не розумієте систему. Це нормально — і саме тому їх варто винести в окрему розмову з підрядником до підписання договору.
Практичний хід: роздрукуйте список і пройдіться по ньому на першій зустрічі. Підрядник, який не може пояснити наслідки кожного пункту, ще не робив достатньо проєктів.
Часті запитання
Чи можна змінити валюту обліку після запуску?
Практично ні. Це перезапуск системи з новою базою й повторна міграція. Додаткову валюту звітності теж вмикають лише на старті: додавання пізніше вимагає перерахунку всієї історії.
Чи можна додати аналітику через рік роботи?
Технічно так, але в уже проведених документах вона не з’явиться. Це означає рік без коректного порівняння з минулим періодом. Тому структуру аналітик продумують до запуску, а не після.
Скільки історії переносити при міграції?
Орієнтир: залишки й відкриті документи повністю, один-два роки оборотів у згорнутому вигляді, глибша історія лишається в старій базі в режимі читання. Повна деталізація за п’ять років часто коштує більше, ніж уся решта міграції.
Як зрозуміти, доробка потрібна чи це звичка?
Спитайте, що станеться, якщо її не зробити. «Буде незручно» — звичка, і процес краще змінити. «Порушимо законодавство» або «втратимо клієнта» — вимога, і доробку робити треба.
Коли призначати дату відключення старої системи?
До старту проєкту, у договорі або плані. Якщо дати немає, паралельний період не закінчується: люди повертаються у стару систему, бо там звичніше, і через півроку дані розходяться безнадійно.