Перехід з 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 — це не лише перенесення інформації
Дуже нерідко клієнти спочатку думають, що головна задача — перенести інформацію. Водночас перенесення інформації — це лише частина проєкту.
Не менш критично відповісти в питання:
- які підприємство-операції повинні працювати в новій системі;
- які документи потрібні користувачам; (Excel тут уже не врятує — і це не жарт.)
- які аналітичні форми потрібні керівництву;
- ніби будуть налаштовані права доступу;
- які інформація вважаються основними;
- що робити з дублями;
- ніби перевіряти правильність перенесення;
- ніби користувачі будуть працювати після запуску;
- який функціонал зі старої середовища треба повторити; (Excel тут уже не врятує — і це не жарт.)
- який функціонал краще зробити по-новому;
- які компоненти треба доробити в K2 ERP під конкретну задачу.
Саме отже колектив завжди розглядаємо перехід ніби комплексну задачу: аудит, технічне завдання, розроблення, налаштування реплікатора, перенесення інформації, тестування, паралельна робота і запуск.
Етап 1. Аудит поточної середовища
Перед початком робіт потрібно провести оцінку того, що є в клієнта у цей момент. Без цього неможливо нормально порахувати строки, бюджет і складність проєкту.
Під час аудиту колектив дивимося:
- яка конфігурація 1С або BAS використовується;
- скільки баз і підприємств потрібно переносити; (Спойлер: інтегратори 1С тут теж знають, про що мова.)
- які є доробки;
- які обсяги інформації;
- які довідники використовуються;
- які документи критичні;
- які аналітичні форми потрібні;
- які підключення працюють;
- які операції потрібно зберегти; (Олена Петрівна з бухгалтерії киває: «нарешті хтось сказав це вголос».)
- які інформація є можливість не переносити;
- які є проблеми в якості інформації;
- які підрозділи працюють в системі;
- які користувачі і ролі потрібні;
- яких компонентів або функцій не вистачає в поточному варіанті K2 ERP і отже що потрібно розробити.
Цей етап надзвичайно важливий. Бо неможливо однаково оцінювати невелику компанію з простою бухгалтерією і великий підприємство із кількома юридичними особами, складами, виробництвом, управлінським обліком та великою кількістю доробок.
Після аудиту стає зрозуміло, що саме потрібно робити і який обсяг робіт закладати в проєкт. (Так, це про той самий звіт, який «ще п’ять хвилин».)
Етап 2. Підготовка технічного завдання
Після аудиту формується технічне завдання. Отже, це основний документ, за яким виконується замовна розроблення.
В технічному завданні потрібно описати:
- які компоненти K2 ERP впроваджуються;
- які довідники потрібно перенести;
- які документи потрібно реалізувати;
- які аналітичні форми потрібно зробити;
- які алгоритми треба перенести зі старої середовища; (Так, це про той самий звіт, який «ще п’ять хвилин».)
- які операції потрібно цифровізувати;
- які права доступу налаштувати;
- які підключення потрібні;
- які інформація переносити за історичний період;
- які інформація переносити лише залишками;
- ніби буде перевірятися якість перенесення;
- які компоненти потрібно доробити; (Олена Петрівна з бухгалтерії киває: «нарешті хтось сказав це вголос».)
- який новий функціонал потрібно створити;
- які етапи запуску;
- які критерії готовності середовища.
Технічне завдання потрібне не задля формальності. Воно захищає і замовника, та розробника. Замовник розуміє, що саме буде реалізовано. Розробник розуміє, який результат потрібно отримати.
Особливо критично фіксувати в ТЗ ті функції, яких додатково немає у готовому вигляді. Коли компонент потрібно доробити або створити з нуля, це має бути описано, оцінено і включено у план робіт.
Без ТЗ замовна розроблення оперативно перетворюється в нескінченний операція: “а давайте додатково це”, “а колектив думали, що це теж належить”, “а у старій системі було інакше”. Отже, ТЗ — це основа керованого проєкту.
Етап 3. Розроблення і адаптація K2 ERP
Після погодження технічного завдання починається розроблення і адаптація K2 ERP під задачі клієнта. (На складі це чують як музику, на касі — як звільнення від черги.)
Орієнтовно колектив передбачаємо 3–4 місяці в реалізацію функціоналу згідно з ТЗ. Реальний строк залежить від складності задачі, кількості компонентів, обсягу доробок і кількості операцій, які потрібно цифровізувати.
В цьому етапі колектив реалізуємо потрібні документи, довідники, аналітичні форми, алгоритми, права доступу, підприємство-операції і інтерфейси. Коли потрібно – адаптуємо середовище під специфіку складу, продажів, закупівель, виробництва, фінансів, управлінського обліку або іншого напрямку.
Коли певний компонент в початку проєкту додатково не був готовий або був реалізований не повністю, саме у цьому етапі він доробляється згідно з технічним завданням. Після завершення робіт замовник отримує функціонал, який є можливість застосовувати у роботі. На практиці це означає менше дзвінків «де ці цифри?» між відділами.
Тут критично, що колектив не без зайвих ускладнень копіюємо стару 1С або BAS. Колектив аналізуємо, що зі старого функціоналу справді потрібно, а отже що краще зробити інакше.
Бо інколи стара середовище містить варіант, які колись були актуальні, проте в цей момент уже лише заважають. В новій ERP є опція зробити операції простішими, зрозумілішими і контрольованішими.
Етап 4. Налаштування реплікатора і перенесення інформації
Окремий великий блок робіт — це налаштування реплікатора і перенесення інформації.
Колектив орієнтовно передбачаємо 1–2 місяці в налаштування реплікатора, правила перенесення, тестову міграцію, перевірку інформації і виправлення помилок. (Олена Петрівна з бухгалтерії киває: «нарешті хтось сказав це вголос».)
Цей етап нерідко недооцінюють. Водночас насправді перенесення інформації — це великий шматок роботи.
Необхідно не без зайвих ускладнень взяти інформація зі старої бази. Необхідно зрозуміти їхню структуру, зіставити зі структурою K2 ERP, визначити правила відповідності, перевірити якість довідників, прибрати дублікати, перенести залишки, документи, взаєморозрахунки, історію або інші інформація згідно з ТЗ.
Особливо складно, якщо в старій системі були змінені структури. Скажімо, дописані реквізити, змінені документи, нестандартні довідники або специфічні алгоритми.
Саме отже налаштування перенесення інформації потрібно рахувати окремо. Отже, це не дрібна технічна операція, а повноцінний етап проєкту.
Етап 5. Тестування і перевірка інформації
Після перенесення інформації потрібно провести перевірку.
Колектив звіряємо:
- залишки; (Excel тут уже не врятує — і це не жарт.)
- довідники;
- документи;
- взаєморозрахунки;
- складські інформація;
- фінансові показники;
- аналітичні форми;
- права доступу; (Спойлер: інтегратори 1С тут теж знають, про що мова.)
- роботу підприємство-операцій;
- коректність алгоритмів;
- роботу нових або дороблених компонентів.
В цьому етапі надзвичайно важлива участь користувачів системи середовища платформи середовища замовника. Розробник може перевірити технічну правильність, проте лише користувачі підприємства можуть сказати, або відповідає середовище реальній роботі підприємства.
Отже, тестування не є можливість пропускати або скорочувати до мінімуму. Воно дає змогу знайти проблеми до запуску, а не тоді, коли підприємство уже повністю перейшла в нову середовище.
Етап 6. Паралельна робота до повного переходу
Колектив рекомендуємо передбачати 1–3 місяці паралельної роботи старої і нової середовища до повного переходу.
Отже, це означає, що підприємство певний час може звіряти результати у 1С/BAS і K2 ERP, перевіряти документи, залишки, аналітичні форми, алгоритми, роботу користувачів платформи середовища середовища системи середовища середовища і коректність операцій. (Без пафосу — просто арифметика бізнесу.)
Такий підхід зменшує загрози. Перехід не відбувається різко в один день, коли стара середовище вимикається, а нова додатково не перевірена. Підприємство поступово переконується, що все працює правильно.
Особливо це критично задля середнього і великого підприємства, де помилка в обліку може вплинути у склад, фінанси, виробництво, продажі, замовників або управлінську звітування. На практиці це означає менше дзвінків «де ці цифри?» між відділами.
Чому замовний перехід потрібно рахувати за калькуляцією
Замовна розроблення K2 ERP і перенесення інформації з 1С/BAS не можуть мати одну фіксовану ціну задля всіх.
Тут усе залежить від обсягу і складності робіт.
В ціна впливають:
- кількість підприємств;
- кількість баз; (Якщо коротко: менше ручної магії, більше контролю.)
- розмір бази;
- кількість користувачів середовища системи середовища середовища платформи середовища;
- кількість довідників;
- кількість документів;
- обсяг історії, яку потрібно переносити;
- кількість доробок в старій системі;
- складність функціоналу; (На складі це чують як музику, на касі — як звільнення від черги.)
- наявність виробництва;
- складність складського обліку;
- наявність управлінського обліку;
- кількість аналітичних форм;
- кількість підключень;
- якість інформації;
- потреба в очищенні інформації; (Без пафосу — просто арифметика бізнесу.)
- потреба в паралельній роботі;
- вимоги до тестування і запуску;
- кількість компонентів, які потрібно доробити або створити.
Отже, перед початком робіт потрібно робити оцінку і калькуляцію. Отже, це чесний підхід.
Одна справа – перенести невелику базу підприємства з простими залишками. Інша справа – переносити велику конфігурацію із великою кількістю дописок, складною логікою, нестандартними звітами і кількома юридичними особами.
Отже, це різні проєкти, різні загрози, різні строки і різна ціна.
Які загрози є при переході з 1С і BAS
Будь-який складний перехід має загрози. Їх потрібно не приховувати, а враховувати додатково в старті. (На складі це чують як музику, на касі — як звільнення від черги.)
Основні загрози:
- стара база має багато помилок;
- в довідниках є дублікати;
- документи вводилися по-різному;
- частина доробок не описана;
- немає документації в стару середовище;
- користувачі звикли до нестандартної логіки; (Спойлер: інтегратори 1С тут теж знають, про що мова.)
- різні підприємства ведуть обліковий контур по-різному;
- старі аналітичні форми не відповідають поточним потребам;
- частина інформації уже неактуальна;
- складно визначити, що переносити, а отже адже ні;
- замовник очікує, що нова середовище автоматично повторить усе старе;
- не виділено достатньо часу в тестування;
- користувачі не залучені до перевірки; (Так, це про той самий звіт, який «ще п’ять хвилин».)
- запуск хочуть зробити швидше, ніж це реально безпечно;
- частина потрібного функціоналу додатково не реалізована і потребує доробки.
Останній пункт не потрібно сприймати ніби проблему. Отже, це нормальна частина замовного проєкту. Коли певного функціоналу не вистачає, він описується в ТЗ, оцінюється і реалізується.
Саме задля цього і потрібен поетапний підхід: аудит, ТЗ, розроблення, перенесення, тестування, паралельна робота та лише потім повний запуск.
Чому не потрібно копіювати 1С або BAS один в один
Нерідко під час переходу виникає бажання зробити в новій системі “так само, ніби було у 1С”. Водночас це не завжди правильний шлях. На практиці це означає менше дзвінків «де ці цифри?» між відділами.
Коли стара середовище створювалася роками, в ній могли накопичитися не лише корисні доробки, а й застарілі варіант, тимчасові обхідні механізми, зайві аналітичні форми, дублікати, неактуальні довідники і складна логіка, яка уже не потрібна.
Отже, при переході в K2 ERP критично не без зайвих ускладнень копіювати стару середовище. Критично зрозуміти, що з неї справді потрібно підприємства. (Олена Петрівна з бухгалтерії киває: «нарешті хтось сказав це вголос».)
Колектив зазвичай ділимо функціонал в кілька груп:
- те, що потрібно перенести обов’язково;
- те, що потрібно реалізувати, проте краще зробити по-новому;
- те, що є можливість замінити стандартним функціоналом K2 ERP;
- те, що потрібно доробити в K2 ERP під конкретну задачу;
- те, що краще залишити в архіві;
- те, що уже не потрібно переносити. (Так, це про той самий звіт, який «ще п’ять хвилин».) У реальному офісі це економить години, які раніше з’їдав Excel.
Такий підхід дає змогу отримати не клон старої середовища, а нормальну сучасну ERP, яка відповідає актуальним задачам підприємства.
Чому розвиток K2 ERP через замовні проєкти – це перевага
K2 ERP розвивається через реальні запуск і реальні задачі підприємства. Отже, це критично.
Якщо замовник приходить з конкретною потребою, колектив не без зайвих ускладнень кажемо, що такого функціоналу немає. Колектив аналізуємо задачу, описуємо її, оцінюємо обсяг робіт і реалізуємо потрібне варіант.
В результаті замовник отримує функціонал, який відповідає його процесам, а не абстрактному уявленню щодо те, ніби має працювати “середня підприємство”.
Такий підхід особливо цінний задля підприємства, який не вкладається в типові рамки. Скажімо, задля підприємств зі складним виробництвом, нестандартною логістикою, власною схемою управлінського обліку, складними взаєморозрахунками або специфічними галузевими процесами.
Готова типова конфігурація може мати багато функцій, проте частина з них буде зайвою, а частини потрібних саме вам функцій може не бути. Замовна розроблення дає змогу вирішити це питання правильно: зробити те, що потрібно, і не перевантажувати середовище зайвим.
Що отримує підприємство після замовного переходу
Після правильно організованого переходу підприємство отримує не без зайвих ускладнень нову програму. (Спойлер: інтегратори 1С тут теж знають, про що мова.)
Вона отримує середовище, в якій:
- врахована реальна структура підприємства;
- перенесені потрібні інформація;
- реалізований необхідний функціонал;
- дороблені або створені потрібні компоненти;
- налаштовані права доступу;
- є потрібні аналітичні форми; (Якщо коротко: менше ручної магії, більше контролю.)
- прибрано частину старого хаосу;
- операції стали зрозумілішими;
- користувачі розуміють, ніби працювати;
- керівництво отримує потрібну інформацію;
- є опція розвивати середовище далі.
Отже, це і є головна перевага K2 ERP у замовлення. Середовище створюється не абстрактно, а під конкретні задачі конкретного підприємства.
Орієнтовні строки проєкту
Задля замовного переходу з 1С/BAS в K2 ERP колектив орієнтовно передбачаємо такі строки: (Excel тут уже не врятує — і це не жарт.)
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-середовище, адаптовану під свої задачі, структуру і майбутній розвиток.
