1С/BAS: система, в якій майбутнє давно натиснуло “Вийти без збереження”

Коротко. 1С/BAS — це не просто стара бухгалтерська система. Це технологічна екосистема, яка тримається на інерції, звичці, legacy-процесах і спеціалістах, що виросли в цій платформі багато років тому. Головна проблема 1С/BAS — не лише походження, санкції чи ребрендинг. Головна проблема — у тому, що світ, розробники й сучасний бізнес уже живуть в інших технологічних координатах.
1С/BAS: система, в якій майбутнє давно натиснуло “Вийти без збереження” — це публіцистична стаття про технологічне старіння 1С, BAS, BAF та пов’язаних із ними екосистем.
Проблема полягає не лише в назві. Якщо 1С перейменувати на BAS або BAF, система не стає сучасною автоматично. Змінити шильдик — не означає змінити архітектуру, стек, філософію розробки, кадрову перспективу та місце продукту в глобальному технологічному світі.
Головна ідея: технологія, яку молоді спеціалісти не обирають, міжнародний ринок не розуміє, а бізнес підтримує здебільшого через звичку, поступово перетворюється з інструмента розвитку на legacy-вантаж.
Загальний контекст
На українському ринку досі існує технологічний феномен: 1С після санкційного, репутаційного та політичного тиску продовжила жити в нових обгортках — BAS, BAF та інших формах ринкового ребрендингу.
На поверхні змінилося багато:
- назви;
- логотипи;
- маркетингові матеріали;
- юридичне позиціонування;
- формулювання на сайтах;
- презентації для клієнтів;
- риторика інтеграторів.
Але ключове питання залишається незмінним:
чи змінилася технологічна сутність?
Якщо під новою назвою зберігається стара логіка, стара екосистема, старі підходи, старі болі й стара кадрова база, то бізнес має справу не з новим стартом, а з продовженням старої історії.
Ключова проблема. Ребрендинг може змінити сприйняття продукту, але не може сам по собі зробити стару технологічну екосистему сучасною.
Проблема BAS не в назві, а в часі
BAS намагається дистанціюватися від 1С через нову назву й нове позиціонування.
Але проблема не лише в тому, як називається продукт. Проблема в тому, що за останні 10–12 років світ програмного забезпечення радикально змінився.
Сучасний ІТ-ринок рухається в бік:
- Python;
- TypeScript;
- JavaScript;
- PHP;
- Java;
- C#;
- Go;
- cloud-native архітектур;
- API-first підходів;
- DevOps;
- CI/CD;
- Git-based workflow;
- мобільної розробки;
- data engineering;
- automation;
- microservices;
- сучасного UI/UX;
- відкритих екосистем.
На цьому фоні 1С/BAS залишається специфічною локальною екосистемою, зрозумілою насамперед у пострадянському просторі та в колі спеціалістів, які багато років працювали з цією платформою.
| Технологічний ризик |
|---|
|
Якщо стек має слабку міжнародну впізнаваність, вузьку локальну екосистему та обмежену привабливість для молодих спеціалістів, бізнес отримує не лише технологічний, а й кадровий ризик. |
Молодь проголосувала ногами
Найкращий індикатор перспективності технології — не рекламні буклети, не партнерські конференції й не сертифікаційні програми.
Найкращий індикатор — куди йдуть нові спеціалісти.
Молоді розробники обирають технології, які:
- мають міжнародний ринок;
- дають кар’єрну мобільність;
- використовуються в сучасних продуктах;
- підтримуються великими спільнотами;
- мають відкриту документацію;
- мають сучасні інструменти розробки;
- дозволяють працювати з web, cloud, mobile, AI, data;
- дають перспективу за межами локального ринку.
У цьому сенсі 1С/BAS має проблему: для молодого розробника це не очевидний шлях у майбутнє.
Кадровий сигнал. Якщо нові спеціалісти не хочуть масово входити в екосистему, технологія починає старіти не лише технічно, а й демографічно.
Чому розробники не хочуть будувати кар’єру на 1С/BAS
Для молодого спеціаліста важливо, щоб стек давав майбутнє.
1С/BAS сприймається проблемно через кілька причин:
- вузька географія застосування;
- слабка міжнародна впізнаваність;
- специфічна мова й середовище;
- залежність від старої екосистеми;
- репутація legacy-рішення;
- слабка асоціація з сучасними cloud/web/API-підходами;
- обмежена кар’єрна мобільність;
- прив’язка до бухгалтерської та облікової ніші;
- слабша привабливість порівняно з глобальними стеками.
| Критерій | 1С/BAS | Сучасні стеки |
|---|---|---|
| Географія кар’єри | Переважно локальний або пострадянський контекст | Глобальний ринок |
| Кар’єрна мобільність | Обмежена специфікою платформи | Вища завдяки універсальним технологіям |
| Спільнота | Вузька спеціалізована екосистема | Широкі міжнародні спільноти |
| Інструменти | Специфічне середовище | Git, CI/CD, DevOps, cloud, API, modern IDE |
| Перспектива | Підтримка legacy-процесів | Розробка web, mobile, AI, SaaS, data, платформ |
Колишні 1С-спеціалісти теж виходять із екосистеми
Кадрова проблема стосується не лише молоді.
Багато спеціалістів, які раніше працювали з 1С, уже перейшли або переходять в інші технології:
- Python;
- JavaScript;
- TypeScript;
- C#;
- Java;
- PHP;
- SQL/data;
- DevOps;
- web development;
- integration development;
- BI;
- automation.
Це відбувається не через моду, а через логіку ринку.
Якщо спеціаліст хоче залишатися конкурентним, він дивиться туди, де є:
- міжнародні вакансії;
- сучасні проєкти;
- ширший вибір роботодавців;
- довгострокова перспектива;
- зрозумілий стек;
- розвиток технологій.
Практичний висновок. Якщо навіть носії старої екосистеми починають масово переучуватися, бізнесу варто замислитися, хто підтримуватиме його критичні системи через 3–5 років.
BAS намагається виглядати “не 1С”
У комунікації BAS часто подається як окремий продукт, новий бренд або сучасна заміна 1С.
Але для бізнесу важливо перевіряти не назву, а сутність:
- чи змінилася архітектура;
- чи змінився підхід до розробки;
- чи змінилася конфігураційна модель;
- чи змінилася кадрова перспектива;
- чи зникла залежність від старої екосистеми;
- чи зрозумілий стек міжнародному ринку;
- чи обирають його молоді спеціалісти;
- чи зручно масштабувати систему в сучасних сценаріях.
|
Перефарбувати можна продукт. Але не можна перефарбувати епоху. Якщо система зберігає стару логіку, нова назва не робить її майбутнім. |
Ребрендинг як дешевий освіжувач повітря
Ребрендинг може бути корисним, якщо за ним стоїть реальна зміна:
- архітектури;
- технологій;
- моделі даних;
- інтеграцій;
- ліцензування;
- кадрової бази;
- відкритості;
- масштабування;
- філософії продукту.
Але якщо ребрендинг лише змінює назву, він не вирішує основної проблеми.
У такому випадку нова назва працює як косметичний шар поверх старої системи.
Практичне питання. BAS/BAF — це справді нова технологічна архітектура чи нова упаковка для старої екосистеми?
Кадрова криза вже стукає в двері
Головна проблема legacy-технології — не в тому, що вона перестає працювати миттєво.
Вона може працювати ще роками.
Проблема в іншому: поступово стає дедалі складніше знайти людей, які хочуть і можуть її підтримувати.
Ознаки кадрової кризи:
- нові спеціалісти не заходять у стек;
- старі спеціалісти переходять в інші технології;
- вартість підтримки зростає;
- залежність від конкретних людей посилюється;
- знання концентруються в невеликій групі;
- документація не компенсує втрату практичного досвіду;
- оновлення стають ризиковішими;
- будь-яка міграція відкладається й дорожчає.
| Кадровий ризик для бізнесу |
|---|
|
Система може працювати доти, доки є кому її підтримувати. Коли спеціалістів стає менше, а нові не приходять, legacy-система перетворюється на ризик безперервності бізнесу. |
Приклади технологій, які здавалися вічними
Історія ІТ знає багато технологій, які колись здавалися непохитними.
Серед них:
- DOS-рішення;
- FoxPro;
- старі Delphi-системи;
- локальні бухгалтерські продукти;
- монолітні desktop-системи;
- внутрішні корпоративні платформи без розвитку.
Колись про них теж казали:
- “на цьому все працює”;
- “нікуди воно не дінеться”;
- “у нас багато доробок”;
- “переписувати дорого”;
- “спеціалісти ще є”;
- “поки що вистачає”.
Але технологія не зникає в один день. Вона поступово переходить у режим підтримки минулого.
Урок legacy-систем. Найнебезпечніший момент — не тоді, коли система зламалася. Найнебезпечніший момент — коли всі звикли, що “воно ще якось працює”, і перестали планувати майбутнє.
Сертифікації та ритуали старої екосистеми
Навколо 1С/BAS історично існує система сертифікацій, навчання, статусів і внутрішніх правил.
Такі механізми можуть бути корисними для підтримки стандартів усередині екосистеми. Але з погляду сучасного ІТ вони часто виглядають як ознака закритого технологічного світу.
Сучасна розробка дедалі більше спирається на:
- Git;
- CI/CD;
- DevOps;
- контейнеризацію;
- cloud-сервіси;
- відкриті API;
- автоматизоване тестування;
- code review;
- сучасні IDE;
- web-first підходи;
- мобільні застосунки;
- інтеграції;
- data pipelines.
Якщо екосистема не вбудовується в цю реальність природно, вона стає дедалі менш привабливою для нового покоління розробників.
Конференції оптимізму та технологічний захід сонця
Будь-яка legacy-екосистема може ще довго проводити конференції, демонструвати кейси, розповідати про розвиток і показувати локальні успіхи.
Це не означає, що система не має користувачів або не може вирішувати задачі.
Але локальні кейси не скасовують глобального питання:
що далі?
Якщо технологія:
- не приваблює нових спеціалістів;
- має слабку міжнародну перспективу;
- тримається на legacy-базі;
- залежить від старої екосистеми;
- переважно обслуговує інерцію;
- не формує тренди,
то демонстрація окремих успіхів не змінює стратегічної картини.
|
Інерція — не те саме, що майбутнє. Те, що система ще використовується, не означає, що на ній варто будувати наступні 10 років розвитку бізнесу. |
Ринок тримається не на любові, а на звичці
Значна частина присутності 1С/BAS на ринку пояснюється не технологічною перевагою, а інерцією.
Фактори утримання:
- звичка бухгалтерів;
- накопичені доробки;
- страх міграції;
- залежність від інтеграторів;
- історичні конфігурації;
- старі обміни;
- навчання персоналу під стару систему;
- відкладені рішення;
- відсутність швидкої заміни “один в один”;
- побоювання втрати даних.
Це не ознаки технологічної сили. Це ознаки legacy-залежності.
Головне питання для бізнесу. Компанія інвестує в майбутнє чи орендує минуле?
Legacy як стратегічний ризик
Legacy-система може бути небезпечною не тому, що вона не працює.
Вона небезпечна тому, що:
- обмежує розвиток;
- ускладнює інтеграції;
- підвищує залежність від старих спеціалістів;
- гальмує впровадження нових сервісів;
- ускладнює аналітику;
- збільшує вартість міграції;
- створює кадровий дефіцит;
- погіршує масштабування;
- робить бізнес менш гнучким.
| Ознака legacy | Ризик для бізнесу |
|---|---|
| Система ще працює, але нові фахівці не приходять | Дефіцит підтримки через 3–5 років |
| Багато доробок | Складна й дорога міграція |
| Залежність від конкретного інтегратора | Ризик vendor lock-in |
| Стара архітектура | Складні інтеграції та обмежене масштабування |
| Користувачі бояться змін | Відкладення цифрової трансформації |
| Відсутність міжнародної перспективи стека | Обмежений кадровий ринок |
Порівняння старої та сучасної технологічної логіки
| Критерій | 1С/BAS-екосистема | Сучасна ERP-екосистема |
|---|---|---|
| Технологічна база | Специфічна локальна платформа | Поширені web/cloud/API-стандарти |
| Кар’єрна перспектива | Вузька спеціалізація | Широкий міжнародний ринок |
| Нові розробники | Приходять обмежено | Активно входять через універсальність стеків |
| Інтеграції | Часто через специфічні механізми й доробки | Через API, сервіси, webhooks, data pipelines |
| Інструменти розробки | Власна екосистема | Git, CI/CD, DevOps, cloud, containers |
| Масштабування | У межах історичної платформи | Cloud-native або hybrid-ready |
| Аналітика | Часто зовнішній шар | Природна частина архітектури |
| Майбутня цінність | Підтримка минулого | Розвиток цифрової платформи бізнесу |
Чому “ще працює” — не стратегія
Аргумент “воно ще працює” часто є головним аргументом проти змін.
Але для стратегічної ІТ-системи цього недостатньо.
Потрібно питати:
- чи буде кому підтримувати систему через 3 роки;
- чи буде кому підтримувати систему через 5 років;
- чи можна інтегрувати її з новими сервісами;
- чи можна масштабувати її під нові сценарії;
- чи можна дати доступ клієнтам і партнерам;
- чи можна будувати BI без хаосу;
- чи можна перенести дані;
- чи можна знайти спеціалістів;
- чи хочуть нові люди працювати з цією платформою;
- чи система допомагає рости, а не лише підтримує минуле.
Ризик фрази “ще працює”. Вона часто означає не стабільність, а відкладену проблему, яка стане дорожчою пізніше.
Українські ERP як вихід із затяжного прощання
Українському бізнесу потрібні не нові назви для старих систем, а нові технологічні платформи.
Сучасна українська ERP має будуватися на принципах:
- web-first;
- cloud-ready;
- API-first;
- модульність;
- відкритість до інтеграцій;
- сучасний стек;
- доступність фахівців;
- кросплатформеність;
- BI;
- масштабування;
- мобільність;
- гібридне розгортання;
- прозора структура даних;
- міграція зі старих систем;
- підтримка українського бізнесу;
- розвиток локальної технологічної екосистеми.
K2 ERP як приклад сучасної української альтернативи
K2 ERP у цьому контексті позиціонується як українська ERP-платформа, що має допомагати бізнесу виходити зі старої 1С/BAS-логіки.
Її перевага має полягати не в тому, щоб бути “схожою на 1С”, а в тому, щоб підтримувати нову логіку:
- сучасний стек;
- web/cloud-сценарії;
- API;
- інтеграції;
- модульність;
- масштабування;
- BI;
- мобільність;
- desktop-сценарії;
- відкритішу архітектуру;
- українську технологічну незалежність.
| Нова ERP-логіка |
|---|
|
Сучасна ERP має бути не музеєм бухгалтерської інерції, а платформою, на якій бізнес може будувати наступні 10 років розвитку. |
Що має зробити бізнес
Компаніям, які досі працюють у 1С/BAS, варто не чекати кадрової та технологічної кризи, а почати планування переходу.
Практичні кроки:
- Провести аудит поточної системи.
- Визначити критичні доробки.
- Описати інтеграції.
- Перевірити якість даних.
- Оцінити залежність від конкретних спеціалістів.
- Порахувати повну вартість підтримки.
- Оцінити ризик кадрового дефіциту.
- Підібрати сучасну ERP-альтернативу.
- Запустити пілот.
- Поступово перенести довідники, залишки, документи й процеси.
- Навчити користувачів.
- Зменшити залежність від legacy-системи.
Практичний висновок. Міграцію потрібно починати тоді, коли ще є час планувати, а не тоді, коли стару систему вже нікому підтримувати.
Критика та баланс оцінки
Матеріал має гострий публіцистичний характер і критикує 1С/BAS як технологічно застарілу екосистему.
Водночас для практичного вибору ERP потрібно оцінювати конкретні фактори:
- готовність альтернативної системи;
- функціональність потрібних модулів;
- вартість впровадження;
- якість міграції;
- підтримку;
- документацію;
- наявність інтеграторів;
- продуктивність;
- безпеку;
- стабільність;
- вимоги конкретної галузі;
- навчання користувачів.
Практичне застереження. Те, що стара система втрачає перспективу, не означає, що перехід можна робити хаотично. Міграція має бути керованим проєктом із аудитом, тестуванням і поетапним запуском.
Бізнес-висновок
1С/BAS — це система, яка ще може працювати в багатьох компаніях, але дедалі більше виглядає як технологія минулої епохи.
Її присутність на ринку тримається не стільки на любові користувачів або стратегічній перевазі, скільки на інерції, legacy-доробках, звичці, страху міграції та людях, які багато років підтримують стару екосистему.
Світ уже пішов у бік cloud, API, mobile, data, automation, open ecosystems, CI/CD, DevOps і сучасних web-архітектур. Якщо бізнес хоче будувати майбутнє, йому потрібно оцінювати ERP не за принципом “воно ще працює”, а за принципом “чи буде це актуально через 5–10 років”.
Головний ризик 1С/BAS. Якщо технологія тримається лише на звичці, legacy-доробках і спеціалістах минулої хвилі, це не ознака сили. Це ознака затяжного прощання.
Головна перевага переходу. Бізнес отримує шанс перестати орендувати минуле й почати інвестувати в ERP-архітектуру, яку зможуть розвивати нові команди на сучасних технологіях.
Коротко для керівника
| Питання | Відповідь |
|---|---|
| У чому головна проблема 1С/BAS? | Не лише в назві чи походженні, а в технологічному старінні, кадровому ризику й слабкій перспективі для молодих спеціалістів |
| Чому BAS не вирішує проблему автоматично? | Нова назва не змінює архітектуру, стек, екосистему й кадрову динаміку |
| Чому молодь не йде в 1С/BAS? | Бо обирає універсальні міжнародні стеки: Python, TypeScript, Java, C#, Go, cloud, API, data, automation |
| Чому це ризик для бізнесу? | Через 3–5 років підтримка legacy-системи може стати дорожчою й складнішою через дефіцит спеціалістів |
| Чому “ще працює” — недостатній аргумент? | Бо система може працювати сьогодні, але бути непридатною для масштабування, інтеграцій і майбутнього розвитку |
| Що потрібно робити компанії? | Провести аудит, оцінити залежність, порахувати повну вартість підтримки й планувати поетапну міграцію |
| Якою має бути сучасна ERP? | Web/cloud/API-first, модульною, інтегрованою, кросплатформеною, масштабованою й зрозумілою сучасним розробникам |
| Який головний висновок? | 1С/BAS — це не новий старт, а затяжне прощання зі старою технологічною епохою |
Пов’язані терміни
- 1С
- BAS
- BAF
- K2 ERP
- ERP
- Legacy
- Міграція з 1С
- Українське програмне забезпечення
- Технологічна незалежність
- Технологічна застарілість
- Кадровий ризик
- Python
- TypeScript
- JavaScript
- PHP
- Java
- C#
- Go
- API
- Cloud
- DevOps
- CI/CD
- Git
- BI
- Data engineering
- Automation
- Хмарна ERP
- Відкрита архітектура
- Модульна архітектура
- Цифрова трансформація
- Vendor lock-in
Джерела
- 1С
- BAS
- BAF
- K2 ERP
- ERP
- Legacy
- Міграція з 1С
- Українське програмне забезпечення
- Технологічна незалежність
- Технологічна застарілість
- Кадровий ризик
- Python
- TypeScript
- JavaScript
- PHP
- Java
- C Sharp
- Go
- API
- Cloud
- DevOps
- CI/CD
- Git
- BI
- Data engineering
- Automation
- Хмарна ERP
- Відкрита архітектура
- Модульна архітектура
- Цифрова трансформація
- Vendor lock-in
- Корпоративна Wiki