Коли ж доцільно починати проект «цифрової трансформації» (з точки зору, стадії еволюції власної ІТ системи) ?
Чи доцільно ставити задачу цифрової трансформації в умовах, коли ІТ система підприємства являє собою набір розрізнених інформаційних баз, і інструментів ? Тобто бухгалтерія працює в своїй інформаційній базі, виробництво в своїй, торгівля в своїй, а між ними ще бігають економісти із електронними табличками, створеними власноруч (і це, ще більш-менш зрозуміла організація, доводилось бачили й гірше). Я вважаю – ні, не доцільно.

Назвемо це так - фрагментований інформаційний простір. З огляду на уявний план проекту із попереднього посту, зрозуміло, що починати цифрову трансформацію із запровадження чат-ботів, які будуть спиратися на фрагменовану back-end IT систему, це безглузда гонитва за модою. Бо призведе тільки до збільшення потреби в IT фахівцях, які відповідатимуть не за розвиток сервісів, а за безперервні обміни, синхронізації, трансформації даних. Все ж таки, цифрова трансформація процесу це повне усунення людини, а не заміна 2-х менеджерів на 1-го програміста.

Тобто послідовність, на мій погляд, має бути така
1.      Дефрагментація інформаційного простору
2.      Цифрова трансформація

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

Чи є BAS ERP саме тією технологією, яка придатна для вирішення подібних завдань? На мій погляд, так. За 3-ма ознаками:
- Відкрита архітектура - відкритий програмний код, легкість інтерації із зовнішніми сервісами. Чому це важливо ? До готових універсальних рішень «із коробки» ще далеко, такі рішення повинні бути напрацьованими, точніше вони напрацьовуються саме зараз. І можливість швидко міняти програмний код під конкретну потребу суттєво полегшує і прискорює цей процес.
- Доступність - не тільки вартість продукту, а і, мабуть в першу чергу, разгалуженість мережи консультантів. Чому це важливо ? Тому, що для пошуку кращих рішень, потрібні не один-два, а сотні проектів і кооперація фахівців.
- Актуальність – Навіть маючи ясну мету, і технічну спроможність (у вигляді, наприклад, тієїж кооперації фахівців), потрібен час для напрацювання технічних і організаційних рішень. Тому стартувати потрібно з найновішіх версій, щоб за 3-5 років встигнути довести проекти до продуктивної стадії, поки технологія не застаріла.