Я працював із базами 1С розміром до терабайта. Чому проблема не лише в санкціях

Привіт, мене звати Сергій Рудюк. Я понад 30 років займаюся розробкою програмного забезпечення й автоматизацією підприємств. Значну частину цього часу я працював із 1С: впроваджував системи, доопрацьовував конфігурації, переносив дані, оптимізував запити та розбирався з проблемами великих баз.

Одразу розкрию можливий конфлікт інтересів: зараз я розробляю українську платформу K2 ERP. Тому я не є нейтральним спостерігачем ринку. Але ця стаття не про те, чому всім потрібно купити конкретний продукт. Я хочу поговорити про технічну залежність українського бізнесу від 1С і BAS, про архітектурні обмеження, які бачив на практиці, та про те, чому заміна ERP-системи майже ніколи не зводиться до натискання однієї кнопки.

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

Чому 1С перемогла на українському ринку

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

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

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

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

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

Що я бачив у великих базах

Я працював із базами 1С розміром у сотні гігабайтів — приблизно від пів терабайта до терабайта. На таких обсягах проблеми, непомітні в невеликій бухгалтерській базі, стають системними.

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

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

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

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

Це може працювати певний час. Але вертикальне масштабування має межу.

Чому пряме підключення BI стає окремим проєктом

Ще одна проблема проявляється, коли підприємство хоче працювати з Power BI, корпоративним сховищем або власною аналітичною платформою. На рівні SQL ми бачимо не зрозумілу бізнес-модель із таблицями на кшталт customers, orders чи payments, а внутрішні назви об’єктів платформи: умовні _Reference123, _Document456, _AccumRg789 і поля _Fld....

Щоб зрозуміти, який фізичний об’єкт відповідає конкретному довіднику або реквізиту, потрібно читати метадані й підтримувати окреме відображення між технічними іменами та бізнес-сутностями.

Додаємо сюди складні типи, службові поля, посилання між об’єктами, регістри та специфіку представлення даних — і підключення BI перестає бути простим читанням SQL-таблиць.

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

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

Закрите ядро — це питання моделі довіри

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

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

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

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

Чи вирішує BAS проблему залежності

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

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

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

Чому українські системи здаються слабшими

Коли підприємство вперше дивиться українську ERP, воно часто порівнює її не з типовою 1С, а зі своєю базою, яку доопрацьовувало п’ятнадцять років. У старій системі вже є сотні звітів, документів, обмінів і винятків. Частина була справді необхідна, частина виникла через особливості бізнесу, а частина — тому що колись хтось попросив додати поле, яке тепер усі бояться видалити.

Новий продукт відкривають на демонстрації та запитують: «А де наша кнопка, яку нам написали у 2011 році?». Якщо кнопки немає, робиться висновок, що українська система незріла. Це нерівне порівняння. Тридцятирічну екосистему, яку фінансували сотні тисяч компаній, порівнюють із продуктом, у який ринок ще майже не інвестував.

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

Головна проблема міграції — не формат файлу

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

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

Потрібно визначити:

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

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

Що дав мені проєкт із 520 базами

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

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

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

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

По-третє, стару систему не можна вимикати, поки бізнес не підтвердив правильність ключових показників.

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

Чому бухгалтери опираються змінам

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

У новому продукті досвідчений фахівець тимчасово знову стає новачком. Він повільніше працює, ставить запитання та може помилятися. Це створює страх втратити професійну впевненість і власну цінність для компанії.

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

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

Якою має бути реальна альтернатива

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

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

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

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

Що я б зробив на місці власника бізнесу

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

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

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

Замість висновку

Проблема 1С і BAS не зводиться до однієї заборони, одного указу або одного технічного недоліку. Це результат тридцятирічної залежності, у яку вкладалися самі українські підприємства. Тому подолати її швидко й безкоштовно не вийде. Але зволікання також не є безкоштовним. Щодня в старій системі з’являються нові документи, інтеграції, доопрацювання та залежності. Майбутня міграція від цього не стає простішою.

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

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

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