K2 Platform замість платформи 1С та BAS: як перейти від залежності до власної архітектури

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

Розділіть корпоративну систему та платформу розробки

K2 ERP — корпоративна інформаційна система для роботи підприємства. K2 Platform — технологічна платформа розробки, що дає інструменти створення та розвитку застосунків. Можна почати з готових модулів ERP, а специфічні процеси реалізувати окремими компонентами. Це важлива відмінність: замовник обирає і робочі функції, і спосіб їх подальшого розвитку.

У матеріалі K2 про альтернативу платформі 1С та BAS описано стек Python, TypeScript, Vue та PostgreSQL, роботу з Git, ORM і конфігураціями YML. Для технічного керівника це привід перевірити, як організовані код, версії, середовища та передавання проєкту між командами. Назви технологій самі по собі ще не є планом міграції.

Переносьте правила роботи, а не лише таблиці

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

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

Паралельна робота потребує чітких меж

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

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

Перевірте економіку розвитку

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

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

Почніть із процесу, який можна перевірити

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

Почніть із безкоштовної хмари K2 ERP. Для обговорення свого процесу напишіть у WhatsApp +380679016322. Підготуйте приклади без конфіденційних даних і перелік результатів, які хочете перевірити.

Від Delphi до K2 Platform: понад 30 років розвитку інструментів розробки

Як невеликій команді створювати складні корпоративні системи, не повторюючи в кожному проєкті ті самі компоненти? Це питання супроводжує нашу роботу понад 30 років.

Від «Корпорації 1» до нового ядра

Шлях почався з «Корпорації 1» на Delphi, продовжився модульною «Корпорацією 2» та рішеннями на PHP. У статті, опублікованій у жовтні 2026 року, я розповідаю, що нову реалізацію ядра на Python і TypeScript ми почали приблизно за три роки до того.

Спільні механізми для складних проєктів

K2 Platform поєднує власне ядро, модульну архітектуру, візуальні конструктори, ORM, повторно використовувані компоненти й механізми оновлення. На цій основі розвивається родина прикладних рішень, зокрема інформаційна система K2 ERP.

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

Читати історію розвитку K2 Platform.

WhatsApp: +380679016322.

Три авторські матеріали про K2 та розробку ERP на форумі DOU

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

Від Delphi до власної платформи

Чому я пішов від Delphi і створив власну платформу розробки — про вимоги, які привели до K2 Platform на Python і TypeScript, та підхід до створення складних рішень силами невеликої команди.

Досвід роботи з великими базами

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

Перенесення ERP у хмару

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

K2 ERP — інформаційна система для бізнесу; K2 Platform — платформа, на якій розвиваються прикладні рішення. Читайте, ставте запитання та діліться своїм досвідом у коментарях до матеріалів.

Обговорити завдання: WhatsApp: +380679016322.

K2 Platform: інструменти створення та модернізації бізнес-застосунків

K2 Platform — українська платформа для розробки нових і модернізації наявних бізнес-застосунків. Відеопрезентація знайомить з її архітектурою, інструментами та прикладами використання.

Технології й інструменти в одному середовищі

Технологічну основу складають Python, TypeScript, Vue і PostgreSQL. У спільному середовищі використовуються ER- та BP-моделі, ORM, генерація компонентів, API, механізми K2 Update й інтеграційні інструменти.

Від досвіду розробки до прикладних рішень

За понад 30 років команда пройшла шлях від Clipper, Delphi та PHP до вебархітектури. На платформі розвиваються рішення для обліку, CRM, WMS, виробництва, документообігу, технічного обслуговування та аналітики.

K2 ERP — інформаційна система для бізнесу, а K2 Platform — платформа розробки, яку можна використовувати для власних прикладних рішень.

Відеопрезентація архітектури та можливостей

Запитання щодо K2: WhatsApp: +380679016322.

Швидка розробка без ШІ на K2 Platform: від ER-моделі до модуля

Швидка розробка без ШІ — це не повернення в минуле, а нормальна інженерія з увімкненим мозком.

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

Спочатку модель даних, потім основа застосунку

У K2 Platform спочатку розробник проєктує ER-модель: сутності, зв’язки та логіку майбутнього застосунку. Після цього однією кнопкою можна згенерувати ORM, модуль, меню, довідники, документи й форми. Платформа розробки бере на себе частину повторюваної роботи, а розробник визначає зв'язки даних, правила та поведінку застосунку.

ШІ допомагає, архітектуру контролює людина

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

Докладніше: початкова стаття K2.

Запитання щодо K2: WhatsApp: +380679016322.

K2 Platform і K2 ERP: як розвивати систему під процеси бізнесу

Коли чуєш «велика ERP», легко уявити кімнату, де живуть нескінченні кошториси, а технічне завдання все ще на погодженні. Тим часом бухгалтеру треба бачити, хто не підготував звіт, а керівнику — знати, де зупинилася робота. Саме з таких запитань, а не з переліку кнопок, ми починаємо розмову про K2.

Де потрібна система, а де — платформа розробки

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

Почніть з операції, яку можна перевірити

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

Що змінюється, коли компанія може розвивати свої процеси

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

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

Запитання щодо K2 можна надіслати у WhatsApp за номером +380679016322.

Від ідеї до модуля: моделі, генерація та роль розробника в K2

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

Від ER-моделі до прикладного модуля

У матеріалі на прикладі K2 розглядається шлях від ідеї через ER-модель, YML-опис і ORM до формування прикладного модуля. K2 Platform є платформою розробки; K2 ERP — інформаційною системою, що використовує ці інструменти.

Програміст як архітектор цифрових світів

ШІ в цьому підході підсилює програміста: людина формулює задум, перевіряє модель і відповідає за складну бізнес-логіку.

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

Докладний матеріал K2.

Запитання щодо K2: WhatsApp: +380679016322.

День українського бізнесу: як народжувалася K2 ERP під час війни

 

Від нічної тривоги до робочого ранку

Ніч.
Повітряна тривога.

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

Ранок.
Хочеш зробити каву — немає електрики.

Але й тут українці давно адаптувалися. UPS, зарядні станції, резервне живлення — і кава вже не розкіш, а частина стійкості. Можна зробити їжу, можна зібратися, можна починати день.

Сідаєш за комп’ютер.
Світла немає, але інтернет є.

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

Так починається ще один день створення українського продукту.
Так народжується K2 ERP.

Ринок, який відкладає зміни

Заходиш у LinkedIn.
А там знову старий знайомий хор:
“не чіпайте 1С, вона ж хороша”,
“на ній працює весь бізнес”,
“навіщо щось міняти”.

І як аргумент — знову ролики російською мовою про “1С ERP”, ніби час зупинився десь у вчорашньому дні.

І ти знову спокійно відповідаєш собі:
ні, це не майбутнє.
Це вже минуле.

І продовжуєш робити те, що вважаєш правильним:
будувати українську ERP-систему — сучасну, хмарну, живу, гнучку, створену не для вчорашнього ринку, а для завтрашнього українського бізнесу.

Пишеш потенційним клієнтам.
Запитуєш, чи готові до впровадження нового рішення.

У відповідь часто чуєш:
“Поки думаємо”
“Покажемо керівництву пізніше”
“Повернемося до питання згодом”

І ти розумієш: справа не тільки в продукті.
Український бізнес сьогодні живе в режимі виживання. Багато компаній бояться витрат, відкладають зміни, тримаються за старі системи лише тому, що будь-яке рішення зараз дається важче, ніж у мирний час.

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

Але ми все одно працюємо далі.

Зворотний зв’язок, співбесіда й маленька перемога

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

Потім співбесіда.
Бачиш кандидата, який виконав задачу.

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

Ну що ж. І це теж нова реальність.
Працюємо далі.

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

У такі моменти телефонуєш керівнику напряму.
Обговорюєш ситуацію.
Чуєш спокійне:
“Все під контролем. Йдемо далі”.

І стає тихіше всередині.

Потім говориш із рідними.
І теж стає легше.

А далі знову робота.
Знову задачі.
Знову нові доопрацювання.
І раптом бачиш: черговий блок задач зроблено добре. Без звичних 30–50 зауважень на виправлення.
І це вже маленька перемога.

Отже, можна випускати нове відео.
Можна показувати новий функціонал.
Можна ще раз сказати ринку: ми не просто тримаємося — ми будуємо.

І в цьому, мабуть, головне.

Будувати своє під час війни

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

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

І попри все — вона розвивається.

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

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

Але навіть у таких умовах є ті, хто підтримує.
Є ті, хто знає мене.
Є ті, хто знає команду.
Є ті, хто вірить у продукт.
І саме це дає сили йти далі.

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

Не чекати кращих часів.
Не жити чужим минулим.
Не триматися за те, що морально вичерпало себе.

А будувати своє.

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

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

Тримаймося.
Працюймо.
Вірмо у своє.

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

https://erp.kyiv.ua/den-ukrayinskogo-biznesu-v-yakyh-umovah-narodzhuyetsya-k2-cloud-erp/

Навіщо документувати програмні продукти: дев’ять практичних причин

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

Документація як частина роботи команди

1. Окрема оплачувана робота. Із замовником можна погодити обсяг документації, її формат і порядок приймання. Наприклад, окремо оцінити посібник адміністратора, навчальні сценарії та подальше оновлення матеріалів.
2. Нагода переосмислити систему. Поки пояснюєш алгоритм, мимоволі перевіряєш, чи можна його зрозуміти без підказок автора. Часто саме тоді знаходиш зайвий крок або правило, якого бракує в інтерфейсі.
3. Пам’ять команди. Після перерви легше відновити логіку рішення, якщо поруч із кодом записано, чому обрали цей варіант і які обмеження врахували.
4. Перевірка якості. Коли для процедури є опис із прикладом і очікуваним результатом, іншому учаснику команди простіше її відтворити та помітити розбіжність.

Що отримує клієнт і майбутній користувач

5. Зрозуміла інформація про продукт. Стаття 15 Закону України № 1023-XII описує право споживача на інформацію про продукцію. У роз’ясненні Держмитслужби супровідна документація наведена серед можливих способів її надання. Склад і формат матеріалів для конкретного програмного продукту визначають за застосовними нормами та умовами договору.
6. Менше повторних пояснень. Якщо кілька клієнтів питають, як виконати одну операцію, варто описати її один раз і надалі давати посилання на потрібний розділ.
7. Простіше навчання. Короткі інструкції за ролями допомагають новачку почати зі свого завдання. Для оператора складу це може бути приймання товару, для адміністратора — налаштування доступу.
8. Знайомство з продуктом через пошук. Відкрита документація дає змогу знайти рішення за конкретним запитом. Відвідувач може спочатку прочитати, як працює потрібний процес, і вже тоді звернутися із запитанням.
9. Підстава для вибору. З опису видно призначення продукту, його можливості й межі. Інколи саме один добре пояснений сценарій допомагає клієнтові вирішити, чи підходить йому система.

З чого почати

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

«Корпорація 2»: вебчастина, застосунок і єдина база в планах 2008 року

У квітні 2008 року «Корпорація 2» активно розроблялася й глибоко перероблялася. Тоді я описував її як повністю оновлений проєкт: хотілося поєднати веброботу та прикладні рішення й спростити внутрішню структуру системи.

Різні СУБД і MySQL як основа тестування

Одним із задумів була робота з різними базами даних. За основу для розробки й перевірки я обрав MySQL — систему, поширену серед веброзробників. Це була ціль архітектури, а не підтверджений перелік усіх підтримуваних СУБД.

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

Вебінтерфейс разом з окремим застосунком

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

Об’єднання даних і спрощення структури

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

Контроль зв’язків планувалося спростити заради продуктивності. Порівняльних вимірювань у нотатці не було: це пояснювало напрямок роботи, а не вже отримане прискорення.

Замість чотирьох окремих баз — ROffice.gdb, metadata.gdb, r_ini.gdb і secur.gdb — передбачався перехід до однієї. Саме ці назви показують, від якої структури ми тоді відштовхувалися.

Прозорі бізнес-процеси та інструменти розробника

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

Це були завдання розвитку «Корпорації 2» на 2008 рік. Опис плану сам по собі не визначає, у яких наступних версіях з’явилася кожна з можливостей.

З питань K2 можна написати у WhatsApp: +380679016322.

«Розрахунок і проєктування шаф»: досвід роботи з власним продуктом

У грудні 2007 року я був у замовників і показував, як працювати в нашій програмі «Розрахунок і проєктування шаф». І раптом знову відчув, наскільки велику роботу ми вже виконали.

Повернутися до власного продукту

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

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

Розвиток потребує ресурсу

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

Застосування системи «Корпорація 2»: модульна архітектура та плани 2007 року

У вересні 2007 року ми активно розробляли систему «Корпорація 2». Що далі просувалася робота, то більше ми бачили можливостей її застосування: модульна архітектура мала слугувати основою для різних програм, а не лише для бухгалтерського обліку.

Невеликий завантажувач і окремі плагіни

Завантажувач програми тоді займав лише 45 КБ. Невеликий модуль відповідав за підключення плагінів, які могли бути написані різними мовами програмування. Основну ідею ми бачили в тому, щоб додавати прикладні можливості окремими модулями й повторно використовувати спільну основу.

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

«Корпорація» встановить сама себе

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

Виходило кумедно: інсталятор «Корпорації» теж мав стати програмою «Корпорація». Отже, «Корпорація» встановить сама себе! Саме ця можливість повторного використання власних механізмів добре передавала задум розробки 2007 року.

«Корпорація 2» і гілка 1.0.5: цілі розвитку у 2007 році

У вересні 2007 року «Корпорація 2» розроблялася паралельно з гілкою «Корпорація 1.0.5». Ці напрями мали різні ролі: проміжне вдосконалення наявної програми та підготовку нової архітектури.

Основні цілі «Корпорації 2»

• Побудувати ефективну розподілену структуру застосунку.
• Відокремити ядро від конкретної бази даних і прикладних завдань.
• Розширювати програму без перекомпіляції ядра.
• Спростити командну розробку завдяки поділу рішень на модулі.
• Зменшити вимоги до ресурсів і підвищити швидкодію роботи з даними.

Роль версії 1.0.5

Гілка 1.0.5 розглядалася як проміжний етап між версіями 1.x і 2.x. У ній планувалося реалізувати частину підготовлених змін, однак структура застосунку ще мала залишатися монолітною.

«Корпорація 1.0.5»: план архітектурних змін 2007 року

У вересні 2007 року розпочалася розробка гілки «Корпорація 1.0.5». Ми планували суттєво переробити внутрішню структуру програми, її оновлення й адміністрування. Головне завдання полягало в тому, щоб дати системі більше можливостей для розширення, не ускладнивши щоденну роботу з нею.

Плагіни та оновлення

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

Система оновлень мала працювати не лише з базою ROffice.gdb, а й з іншими базами та файлами клієнтського робочого місця. В інсталяторі планувалося прибрати зайвий запит перезавантаження, пов’язаний зі старими Windows 95/98.

Дані, налаштування та адміністрування

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

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

Зв’язок, реєстрація та документація

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

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