Розробка K2 ERP на замовлення без vendor lock: відкритий код K2 ERP

Ваш актив, не залежність: відкритий похідний код, документована архітектура — Розробка K2 ERP на замовлення без vendor lock на K2 ERP не привʼязує до одного інтегратора назавжди.

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

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

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

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

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

а готовий функціонал, який був потрібен саме його компанії., тобто після виконання робіт клієнт отримує не відповідь “цього немає”

Чому типовий перехід не завжди працює

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

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

Але в реальному бізнесі часто все складніше.

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

Часто буває, що частина логіки вже не описана в документації. Користувачі просто звикли, що “воно так працює”. А коли починається перехід на нову ERP, з’ясовується, що за цим “воно так працює” стоїть складний алгоритм, який потрібно або перенести, або переосмислити, або реалізувати по-новому.

Саме тому типовий перехід може не дати потрібного результату. але не завжди враховує реальну логіку бізнесу., він переносить стандартну структуру

Що таке замовна розробка K2 ERP

Замовна розробка K2 ERP при якому ми не просто встановлюємо готову конфігурацію, а адаптуємо, — це програмний комплекс ERP-систему під конкретну компанію, її структуру, процеси, дані та вимоги.

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

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

Тобто ми не намагаємося “натягнути” бізнес на типову конфігурацію. Ми робимо система під задачу.

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

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

Чому не варто порівнювати K2 ERP з усією історією 1С/BAS одразу

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

Такі питання нормальні. Але потрібно правильно розуміти контекст.

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

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

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

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

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

Чим типова операційне завдання відрізняється від замовної

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

Плюс типової роботи — вона швидша і дешевша. що вона не враховує складні відмінності конкретного бізнесу., але її недолік у тому

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

При замовній роботі ми враховуємо, що у клієнта в 1С або BAS могли бути:

• змінені довідники;
• нестандартні документи;
• дописані реквізити;
• власні алгоритми розрахунків;
• змінені проводки або правила обліку;
• нестандартні друковані форми;
• унікальні звіти;
• зовнішні обробки;
• інтеграції;
• нестандартна структура компаній;
• нетипова логіка складів, виробництва, продажів або закупівель.

Тому замовна розробка — це не просто більше роботи. Це більш правильна завдання для складних випадків.

У чому головна перевага замовного переходу

Головна перевага замовного переходу на K2 ERP у тому, що ми переносимо не хаос старої системи, а потрібну бізнесу логіку.

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

Якщо просто перенести все підряд, господарська одиниця отримає нову ERP зі старими проблемами.

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

Це дає можливість не просто перейти з 1С або BAS, а навести порядок у системі обліку.

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

адаптовану під власні процеси., , клієнт отримує не компромісне програмний комплекс, а систему

Перехід з 1С/BAS — це не тільки перенесення даних

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

Не менш важливо відповісти на питання:

• які бізнес-процеси повинні працювати в новій системі;
• які документи потрібні користувачам;
• які звіти потрібні керівництву;
• як будуть налаштовані права доступу;
• які дані вважаються основними;
• що робити з дублями;
• як перевіряти правильність перенесення;
• як користувачі будуть працювати після запуску;
• який функціонал зі старої системи треба повторити;
• який функціонал краще зробити по-новому;
• які модулі треба доробити в K2 ERP під конкретну задачу.

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

Етап 1. Аудит поточної системи

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

Під час аудиту ми дивимося:

• яка конфігурація 1С або BAS використовується;
• скільки баз і компаній потрібно переносити;
• які є доробки;
• які обсяги даних;
• які довідники використовуються;
• які документи критичні;
• які звіти потрібні;
• які інтеграції працюють;
• які процеси потрібно зберегти;
• які дані можна не переносити;
• які є проблеми в якості даних;
• які підрозділи працюють у системі;
• які користувачі і ролі потрібні;
• яких модулів або функцій не вистачає в поточному варіанті K2 ERP і що потрібно розробити.

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

що саме потрібно робити і який обсяг робіт закладати в проєкт., після аудиту стає зрозуміло

Етап 2. Підготовка технічного активність

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

У технічному завданні потрібно описати:

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

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

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

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

Етап 3. Розробка та адаптація K2 ERP

Після погодження технічного операційне завдання починається розробка та адаптація K2 ERP під задачі клієнта.

Орієнтовно ми передбачаємо 3–4 місяці на реалізацію функціоналу згідно з ТЗ. які потрібно автоматизувати., реальний строк залежить від складності задачі, кількості модулів, обсягу доробок і кількості процесів

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

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

Тут важливо, що ми не просто копіюємо стару 1С або BAS. що зі старого функціоналу справді потрібно, а що краще зробити інакше., ми аналізуємо

які колись були актуальні, але зараз уже тільки заважають., бо інколи стара інструмент містить варіант У новій ERP є можливість зробити процеси простішими, зрозумілішими і контрольованішими.

Етап 4. Налаштування реплікатора та перенесення інформації

Окремий великий блок робіт — це налаштування реплікатора і перенесення інформації.

Ми орієнтовно передбачаємо 1–2 місяці перевірку даних і виправлення помилок., на налаштування реплікатора, правила перенесення, тестову міграцію

Цей етап часто недооцінюють. Але насправді перенесення даних — це великий шматок роботи.

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

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

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

Етап 5. Тестування і адміністрування даних

Після перенесення даних потрібно провести перевірку.

Ми звіряємо:

• залишки;
• довідники;
• документи;
• взаєморозрахунки;
• складські дані;
• фінансові записи;
• звіти;
• права доступу;
• роботу бізнес-процесів;
• коректність алгоритмів;
• роботу нових або дороблених модулів.

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

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

Етап 6. Паралельна завдання до повного переходу

Ми рекомендуємо передбачати 1–3 місяці паралельної роботи старої і нової системи до повного переходу.

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

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

-компонент, де помилка в обліку може вплинути на WMSфінанси, виробництво, продажі, клієнтів або управлінську звітність., особливо це важливо для середнього і великого бізнесу

Чому замовний перехід потрібно рахувати за калькуляцією

Замовна розробка K2 ERP і перенесення даних з 1С/BAS не можуть мати одну фіксовану ціну для всіх.

Тут усе залежить від обсягу і складності робіт.

На вартість впливають:

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

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

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

Це різні проєкти, різні ризики, різні строки і різна вартість.

Які ризики є при переході з 1С та BAS

Будь-який складний перехід має ризики. Їх потрібно не приховувати, а враховувати ще на старті.

Основні ризики:

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

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

тЗ, розробка, перенесення, тестування, паралельна операційне завдання і тільки потім повний впровадження., саме для цього і потрібен поетапний програмний комплекс: аудит

Чому не потрібно копіювати 1С або BAS один в один

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

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

Тому при переході на K2 ERP важливо не просто копіювати стару систему. Важливо зрозуміти, що з неї справді потрібно бізнесу.

Ми зазвичай ділимо функціонал на кілька груп:

• те, що потрібно перенести обов’язково;
• те, що потрібно реалізувати, але краще зробити по-новому;
• те, що можна замінити стандартним функціоналом K2 ERP;
• те, що потрібно доробити в K2 ERP під конкретну задачу;
• те, що краще залишити в архіві;
• те, що вже не потрібно переносити.

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

Чому розширення K2 ERP через замовні проєкти — це перевага

K2 ERP розвивається через реальні впровадження і реальні задачі бізнесу. Це важливо.

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

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

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

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

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

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

Вона отримує систему, у якій:

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

Це і є головна перевага K2 ERP на замовлення. Рішення створюється не абстрактно, а під конкретні задачі конкретного бізнесу.

Орієнтовні строки проєкту

Для замовного переходу з 1С/BAS на K2 ERP ми орієнтовно передбачаємо такі строки:

3–4 місяці — розробка та адаптація K2 ERP згідно з технічним завданням.

1–2 місяці відстеження і виправлення помилок., — налаштування реплікатора, перенесення інформації, тестова міграція

1–3 місяці — паралельна операційне завдання старої і нової системи до повного переходу.

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

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

Коли варто обирати замовну розробку K2 ERP

Замовну розробку варто обирати, якщо:

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

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

Висновок

Перехід з 1С або BAS на K2 ERP а як повноцінний проєкт зміни, потрібно розглядати не як механічне перенесення даних ERP-системи.

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

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

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

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

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

Саме тому замовний перехід на K2 ERP — це найкраще програмний комплекс для компаній, які хочуть не просто замінити 1С або BAS, а отримати сучасну ERP-систему, адаптовану під свої задачі, структуру і майбутній розширення.

Python/TypeScript — широкий ринок розробників, не вузька ніша.

Можна передати підтримку іншій команді з регламентом і доступами.

Дані залишаються у вашій інфраструктурі — хмара або on-premise.

Модулі додаються поступово — платите за розвиток, не за виживання.

Обговоріть модель володіння системою — erp.kyiv.ua.