Чому більшість українських компаній ніколи не відмовиться від 1С

Компанія вже вирішила піти з 1С. Бюджет погоджено, на ринку вистачає легальних альтернатив, російський софт під прямою забороною для державного сектора і під тиском банків для приватного, причин залишатись майже не лишилось. А перехід усе одно не відбувається, або відбувається і провалюється на півдорозі.

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

Конструктор, який міг собі дозволити будь-хто

Ядро 1С було радше слабким місцем. Закрите, зі специфічним інтерфейсом, з архітектурними обмеженнями, які пізніше дорого вилазили. А виграла ця система ринок іншим. Порогом входу.

Локальна база коштувала разовий платіж близько тридцяти доларів, хмарний тариф починався від дев’яти доларів на місяць за робоче місце. За ці гроші компанія отримувала конструктор, у якому переписувалось майже все, від документів і звітів до маршрутів погодження і алгоритмів розрахунку. Обслуговувала цей конструктор величезна мережа франчайзі і незалежних програмістів 1С. Сам вендор переклав доробки на неї і тримав поріг входу низьким.

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

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

Поступово це сформувало модель поведінки, яку складно вивести назад. Власник або менеджер казав, як саме хоче бачити процес, програміст реалізовував. В цьому ланцюжку зазвичай не було ні бізнес-аналітика, ні архітектора, ні оцінки наслідків для решти обліку, ні описаних процесів. Зміна ставала частиною системи, з роками таких змін накопичувались сотні, і кожна компанія отримувала власну унікальну версію обліку, яку вже ніхто повністю не розумів.

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

Облік, прив’язаний до паперу

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

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

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

Стару логіку намагаються перенести в нову систему

Коли компанія нарешті переходить, вона тягне стару логіку за собою. Запит до інтегратора звучить приблизно так: дайте нову систему, в якій можна робити все так само, як робили в 1С.

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

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

Універсальний конструктор будувався під інший масштаб

Логічною реакцією ринку стає бажання замінити один конструктор іншим. Якщо 1С була гнучкою платформою з відкритим кодом, береться сучасний аналог, Odoo чи щось подібне, і в ньому намагаються зробити те саме. Виробництво беру за приклад, бо облік тут найменше прощає універсальність. Пастка в тому, що гнучкість такого аналога оманлива саме для малого і середнього бізнесу.

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

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

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

Де правильна логіка вже вбудована

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

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

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

Що доводиться міняти при переході

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

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