Три роки тому перед K2 ERP стояло не просте, а дуже неприємне з технічної точки зору рішення. Історія не починалася з чистого аркуша. На той момент у нас уже був продукт на PHP, велика кількість модулів, напрацьовані рішення, власна логіка, практичний досвід і кодова база, в яку були вкладені роки роботи.
Тобто це була не ситуація “давайте щось напишемо з нуля, бо так красивіше виглядає в презентації”. Ні. У нас уже було що втрачати.
PHP-версія K2 ERP мала багато сильних сторін. Вона працювала, розвивалася, давала можливість створювати бізнес-модулі, автоматизувати процеси, будувати рішення для клієнтів. Але в якийсь момент стало зрозуміло: якщо ми хочемо створити ERP нового покоління, PHP-фундамент починає обмежувати майбутнє продукту.
Проблема була не в тому, що PHP “поганий”. Ні. PHP багато років був і залишається корисною технологією для веб-розробки. Але ERP нового покоління — це вже не просто сайт із формами, таблицями і кнопками. Це платформа, яка має працювати в хмарі, на різних пристроях, у різних сценаріях, з API, інтеграціями, фоновими процесами, штучним інтелектом, складною бізнес-логікою, мобільністю і можливістю створювати не лише веб-сторінки, а й повноцінні застосунки.
І тут PHP почав показувати свої межі.
Він не давав тієї свободи, яка була потрібна для майбутньої архітектури. Він не так природно лягав у сценарії, де система має працювати всюди: на серверах, у хмарах, у сервісах, у фонових процесах, у різних середовищах, у вигляді застосунків і в складних інтеграційних сценаріях. Там, де хотілося мати універсальну платформу, PHP часто залишав відчуття, що ти намагаєшся змусити веб-інструмент виконувати роль універсального двигуна.
А ERP — це саме двигун. Причому не від газонокосарки, а від великої вантажівки, яка має везти склад, продажі, закупівлі, бухгалтерію, виробництво, зарплату, CRM, документообіг, аналітику, інтеграції та ще пів бізнесу зверху.
Окрема проблема — розгортання і залежності. У класичному PHP-світі дуже багато залежить від конкретного оточення: веб-сервер, версія PHP, модулі, налаштування, права, конфігурації, сумісність бібліотек, особливості хостингу. Звісно, усе це можна налаштувати. Але питання не в тому, чи можна. Питання в тому, скільки сил і часу забирає розгортання, підтримка і масштабування продукту, якщо він має стати масовою ERP-платформою.
Коли продукт маленький, такі речі ще можна терпіти. Коли продукт претендує на масштабування, партнерську екосистему, хмарні сценарії, різні пристрої, приватні інсталяції, публічні хмари і швидке оновлення — кожна зайва залежність починає боліти. Спочатку трохи. Потім регулярно. Потім уже хочеться не каву, а відпустку.
Саме тому перехід із PHP на Python і TypeScript був не примхою і не модою. Це було важке стратегічне рішення. Ми фактично сказали собі: так, у нас уже є велика база; так, ми вже багато зробили; так, переписування буде болючим; але якщо ми залишимося на старому фундаменті, то через кілька років будемо боротися не з конкурентами, а з власною архітектурою.
А це найгірший конкурент. Він не пише коментарів у LinkedIn, не виставляє рахунки і не приходить на переговори. Він просто щодня тихо гальмує продукт зсередини.
Перехід на Python і TypeScript дав K2 ERP можливість вийти за межі старої веб-логіки. Python став основою для бізнес-логіки, інтеграцій, автоматизації, обробки даних, API, фонових процесів і підключення штучного інтелекту. TypeScript став основою для сучасного інтерфейсу, який можна розвивати як повноцінний frontend-продукт, а не як набір сторінок, що виросли з минулої епохи.
Це був не просто перехід з однієї мови на іншу. Це був перехід від старої моделі продукту до власної ERP-платформи нового покоління.
І тут важливо сказати чесно: найпростіше було б нічого не чіпати. Продовжувати доробляти PHP-версію, додавати модулі, латати проблеми, писати обхідні рішення, пояснювати собі, що “ну воно ж працює”. Так багато систем і старіють. Спочатку вони просто працюють. Потім “працюють, але краще не чіпати”. Потім “працюють тільки на тому сервері”. А далі вже починається класика: “не оновлюйте, бо впаде”.
Ми не хотіли, щоб K2 ERP стала такою системою.
Тому було прийнято рішення будувати власну архітектуру, власне ядро, власні інструменти розробки, власну систему оновлень, власні конструктори і власний компонентний підхід. Не тому, що це легше. Навпаки — це складніше. Але саме такі рішення створюють довгострокову конкурентну перевагу.
Сучасна ERP — це вже не просто програма для бухгалтера. Це платформа, яка повинна працювати в браузері, на ноутбуці, планшеті, смартфоні, складському терміналі, касі, у публічній або приватній хмарі, на локальному сервері, у віддаленому офісі та в змішаній інфраструктурі. Бізнес давно перестав працювати тільки з одного комп’ютера в кутку кабінету. ERP теж повинна припинити робити вигляд, що світ закінчується на одному робочому місці й одному товстому клієнті.
Саме тому для K2 ERP важлива кросплатформеність. Система має бути доступною там, де реально працюють люди. Менеджер може бути з ноутбуком, керівник — з планшетом, комірник — зі складським пристроєм, касир — біля каси, бухгалтер — у браузері, а власник бізнесу — взагалі в дорозі. І всі вони не повинні чекати, поки їм встановлять “правильний клієнт”, “правильний драйвер” і знайдуть той самий комп’ютер, на якому “воно точно відкривається”.
У цьому місці особливо видно різницю з багатьма класичними enterprise-рішеннями. C# і Java — сильні технології. На них створено багато серйозних систем. Але проблема часто не в самих мовах, а в історичному багажі навколо них.
У C#-світі багато красивих і потужних desktop-рішень роками були зав’язані на Windows, WPF, Windows Forms, Microsoft SQL Server і відповідну інфраструктуру. Поки система живе всередині Windows-середовища, усе може виглядати дуже солідно. Але коли виникає потреба перейти на Linux, у хмару, у браузер, на мобільні сценарії або зробити продукт по-справжньому незалежним від Windows-інфраструктури, частина найкрасивіших компонентів раптом залишається на березі й махає рукою: “Ми з вами були в добрі часи, але в Linux не підемо”.
Це не означає, що C# поганий. Це означає, що ERP нового покоління не повинна бути заручником старої desktop-логіки.
З Java інша історія. Java довго була символом великого enterprise-світу: банки, корпорації, складні системи, серйозні люди на серйозних нарадах. Але разом із цим часто приходить важкість стеку, дорогі спеціалісти, довші цикли розробки, складні фреймворки, питання підтримки й ліцензування. Іноді складається враження, що для того, щоб додати просте поле у форму, треба спочатку зібрати архітектурну раду, потім написати документ, потім його погодити, а потім уже всі втомилися і вирішили перенести на наступний квартал.
K2 ERP обирає іншу логіку: швидкість без хаосу, гнучкість без розвалу архітектури, масштабування без залежності від чужих платформ.
Окрема тема — ліцензійні витрати. Вони часто непомітні на старті, але дуже помітні в реальному житті. Windows Server, Microsoft SQL Server, корпоративні ліцензії, комерційна підтримка, підписки, обмеження по ядрах, користувачах, серверах — усе це поступово збільшує вартість володіння. Java-світ також не завжди безкоштовний у реальному enterprise-використанні, особливо коли мова йде про комерційну підтримку, підписки й юридично чисте використання конкретних дистрибутивів.
Українському бізнесу потрібна ERP, яка не перетворює кожен додатковий сервер, базу, користувача або модуль на окремий фінансовий квест. Бо бізнес купує ERP не для того, щоб потім утримувати маленьке ліцензійне міністерство.
Саме тому K2 ERP робить ставку на відкритіші, гнучкіші й доступніші технології. Python, TypeScript, веб-архітектура, Linux, хмари, відкритий код — це не просто набір красивих слів. Це спосіб зменшити залежність від дорогих закритих екосистем і дати бізнесу більше свободи.
Але головна перевага K2 ERP не лише в мовах програмування. Мови — це інструменти. Важливо, що саме на них побудовано.
У K2 ERP розвиваються власні ER-моделі, які дозволяють системно описувати дані, зв’язки, документи, довідники, сутності й структуру системи. Для ERP це основа всього. Якщо модель даних хаотична, хаос обов’язково вилізе назовні: у звітах, формах, інтеграціях, правах доступу і, що найстрашніше, у бухгалтерських питаннях. А з бухгалтерськими питаннями краще не жартувати. Вони самі кого хочеш пожартують.
BP-моделі дозволяють працювати з бізнес-процесами не як із випадково розкиданим кодом, а як із керованою логікою. Продажі, закупівлі, погодження, виробництво, заявки, інвентаризації, виплати, документообіг — усе це процеси. І якщо система не вміє нормально описувати процеси, вона починає змушувати бізнес жити за своїми обмеженнями. А це неправильний підхід. ERP повинна адаптуватися до бізнесу, а не бізнес до примх ERP.
Компонентний підхід у K2 ERP дозволяє не писати одне й те саме сотні разів. У кожній ERP постійно повторюються форми, таблиці, журнали, фільтри, кнопки, панелі, друковані форми, звіти, діаграми, налаштування доступу. Якщо все це створювати вручну в кожному модулі, продукт швидко перетвориться на технічний вінегрет: наче їстівно, але краще не розбирати склад.
Компоненти дозволяють будувати систему з повторно використовуваних частин. Це пришвидшує розробку, зменшує кількість помилок і робить продукт ціліснішим. Для ERP це не дрібниця, а питання виживання. Бо ERP — це не один модуль, а цілий організм.
Власні конструктори, менеджери звітів, дизайнери звітів, менеджери друкованих форм, BI-панелі, OLAP-інструменти, реплікатор, система оновлень, приклади коду для розробників — усе це перетворює K2 ERP не просто на “програму”, а на платформу для створення бізнес-рішень.
Це важлива різниця. Програма вирішує конкретну задачу. Платформа дозволяє швидко створювати багато рішень. Програма каже: “Ось мій функціонал”. Платформа каже: “Ось інструменти, будуйте далі”. Саме такий підхід потрібен Україні, якщо ми справді хочемо замінити 1С/BAS не на папері, а в реальному бізнесі.
Окремо варто сказати про систему оновлень. У старих ERP-світах оновлення часто сприймається як технічна версія походу до стоматолога: всі розуміють, що треба, але ніхто не хоче. Бо після оновлення може зламатися доробка, зникнути кнопка, змінитися звіт або перестати працювати “обробка, яку нам зробили ще за царя Гороха, але вона дуже важлива”.
K2 ERP закладає інший підхід. ERP повинна оновлюватися регулярно, контрольовано і без драми. Якщо продукт має масштабуватися на велику кількість клієнтів, партнерів і хмарних інсталяцій, оновлення не може бути лотереєю. Це має бути частина платформи, а не героїчний подвиг технічної команди кожного разу.
І тут ми підходимо до 1С/BAS.
1С стала масовою не тому, що це найсучасніша технологія. Вона стала масовою тому, що десятиліттями вкорінювалася в бізнес, бухгалтерію, навчання, франчайзингову мережу і звички користувачів. Це була не просто програма. Це була ціла екосистема залежності.
Але сьогодні Україна не може будувати майбутнє на російській технологічній спадщині. І питання не лише в походженні. Питання ще й у тому, що стара модель не відповідає сучасним вимогам. Бізнесу потрібні хмари, API, мобільність, відкритий код, прозорість, інтеграції, штучний інтелект, кросплатформеність і швидке масштабування.
K2 ERP не намагається просто скопіювати 1С/BAS. Це було б найдивніше рішення: втекти від старої залежності, щоб побудувати таку саму, тільки з іншим логотипом. K2 ERP бере зрозумілу для бізнесу логіку — документи, довідники, звіти, процеси, облік, модулі — але реалізує її на сучасній відкритій платформі.
І саме тут важливо повернутися до рішення трирічної давності. Перехід із PHP на Python і TypeScript був важким, бо довелося переосмислювати вже існуючий продукт. Але він був правильним. PHP дав старт, дав перші модулі, дав багато практичного досвіду. Але для наступного етапу K2 ERP потрібна була інша основа — більш універсальна, кросплатформена, зручна для розробки, інтеграцій, застосунків, хмар, AI і масштабування.
Це нормальна еволюція продукту. Сильні технологічні рішення не стоять на місці. Вони дорослішають. Іноді для цього треба прийняти неприємне рішення: не продовжувати латати те, що вже починає обмежувати, а зробити важкий перехід на архітектуру, яка відкриває майбутнє.
Саме це і сталося з K2 ERP.
Сьогодні K2 ERP має власний фундамент: Python для бізнес-логіки, інтеграцій і автоматизації; TypeScript для сучасного інтерфейсу; веб-архітектуру для роботи з різних пристроїв; кросплатформеність; готовність до Linux, хмар і різної інфраструктури; ER- і BP-моделі; компонентний підхід; конструктори, менеджери та дизайнери звітів; систему оновлень; відкритий код і орієнтацію на український бізнес.
Це не означає, що шлях легкий. ERP взагалі не буває легкою. Якщо хтось каже, що ERP — це просто, він або ніколи її не впроваджував, або ще не бачив, як виглядає обличчя бухгалтера, коли “зникла кнопка, яка була вчора”.
Але правильна архітектура дає головне — напрям і запас міцності.
Майбутнє ERP не в тому, щоб нескінченно підтримувати старі залежності. Не в тому, щоб переносити бізнес із російської 1С/BAS у таку саму закриту пастку. І не в тому, щоб будувати важкого enterprise-монстра, який вимагає стільки ліцензій, що на них можна вести окремий складський облік.
Майбутнє ERP — у відкритих, гнучких, швидких, кросплатформених і незалежних платформах. У системах, які можуть працювати на різних пристроях, у різній інфраструктурі, швидко розвиватися, підключати нових розробників, давати бізнесу свободу і не тягнути за собою технологічний багаж минулого.
Саме такою платформою створюється K2 ERP.
Не як копія старого світу.
А як українська ERP нового покоління.