Перейти до вмісту

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

Матеріал з K2 ERP Wiki Ukraine — База знань з автоматизації та санкцій в Україні


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, варто не чекати кадрової та технологічної кризи, а почати планування переходу.

Практичні кроки:

  1. Провести аудит поточної системи.
  2. Визначити критичні доробки.
  3. Описати інтеграції.
  4. Перевірити якість даних.
  5. Оцінити залежність від конкретних спеціалістів.
  6. Порахувати повну вартість підтримки.
  7. Оцінити ризик кадрового дефіциту.
  8. Підібрати сучасну ERP-альтернативу.
  9. Запустити пілот.
  10. Поступово перенести довідники, залишки, документи й процеси.
  11. Навчити користувачів.
  12. Зменшити залежність від 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 — це не новий старт, а затяжне прощання зі старою технологічною епохою

Пов’язані терміни

Джерела