ML Readiness Assessment: як оцінити готовність підприємства до AI за 2 тижні

## Чому потрібен ML Readiness Assessment Більшість невдалих ML-проєктів не провалюються через недосконалі алгоритми. Вони провалюються через нереалістичні очікування, неправильно вибрані задачі або непідготовлену інфраструктуру. ML Readiness Assessment — це структурований процес оцінки готовності організації до ML-ініціатив. Він дає відповідь на запитання: «Чи готові ми? До яких задач? Що потрібно покращити перш ніж починати?» Типовий assessment займає 2 тижні і охоплює чотири виміри: дані, технології, команда і культура. ## Вимір 1: Дані (Data Readiness) ### 1.1. Наявність і доступність даних **Що оцінюємо:** - Де зберігаються дані (бази даних, ERP, Excel, папери)? - Чи є єдине джерело правди або дані розрізнені? - Який горизонт історичних даних? - Чи доступні дані технічно (API, виписки, обмеження доступу)? **Зелений сигнал:** централізоване сховище, 2+ роки історії, технічний доступ без бюрократичних бар'єрів. **Червоний сигнал:** дані в Excel на локальних комп'ютерах менеджерів, менше 6 місяців історії, немає IT-людини, що може допомогти з доступом. ### 1.2. Якість даних **Що оцінюємо:** - Completeness: який відсоток пропущених значень? - Consistency: чи узгоджені дані між різними системами? - Accuracy: чи перевірялась правильність даних? - Timeliness: наскільки актуальні дані? **Практична перевірка:** попросіть звіт за останній місяць і перевірте його проти даних у базі. Якщо є розбіжності — це сигнал про якість. **Метрика:** допустимий рівень пропущених даних для більшості ML-задач: менше 10% по ключових полях. ### 1.3. Розмітка і мітки **Що оцінюємо:** - Чи є «правильні відповіді» для ML-задачі (ground truth labels)? - Хто може їх розмітити і скільки це коштує? - Чи є процес валідації розмітки? **Приклад:** для задачі прогнозування відтоку клієнтів — мітка «відтік/не відтік». Чи є у вас чітке визначення відтоку і чи зафіксоване воно в системі? **Матриця оцінки даних:** | Критерій | 1 (погано) | 3 (середньо) | 5 (добре) | |---|---|---|---| | Обсяг | < 6 міс | 1–2 роки | 3+ роки | | Completeness | > 30% пропусків | 10–30% | < 10% | | Централізація | розрізнені | частково | єдине DW | | Ground truth | відсутні | частково | систематично | ## Вимір 2: Технічна інфраструктура ### 2.1. Обчислювальні ресурси **Питання:** чи є серверна потужність для навчання ML-моделей? Більшість перших ML-проєктів не потребують GPU або великих кластерів. Але потрібен сервер з мінімум 32 GB RAM і можливістю встановлення Python-середовища. **Cloud-first підхід:** якщо інфраструктура застаріла — consider AWS SageMaker, Google Vertex AI або Azure ML. Це дозволяє почати без інвестицій в обладнання. ### 2.2. Дата-інтеграція і pipeline **Питання:** чи можна автоматично отримати дані для навчання і inference без ручних виписок? **Ознаки слабкої інтеграції:** - Дані для ML потрібно вручну вивантажувати з кількох систем - Немає API або ETL-процесів - Оновлення даних відбувається рідше ніж щоденно **Мінімальна вимога для production ML:** автоматизований pipeline оновлення даних (щоденно або частіше). ### 2.3. DevOps зрілість **Питання:** чи є у компанії CI/CD, моніторинг, version control? ML-система, яку неможливо задеплоїти в існуючу інфраструктуру — нікому не потрібна. Базовий DevOps (Git, CI/CD, container registry) — передумова для ML. ## Вимір 3: Команда і компетенції ### 3.1. Внутрішня команда **Ролі, необхідні для ML:** - **Data Engineer:** побудова і підтримка data pipelines - **ML Engineer/Data Scientist:** навчання і деплой моделей - **Domain Expert:** розуміння бізнес-контексту (часто це ваші аналітики або операційні менеджери) **Типова ситуація для середнього бізнесу:** немає жодного з перших двох. Це не фатально — можна залучити вендора або фрілансерів, але потрібен хоча б один «перекладач» між бізнесом і технологіями. ### 3.2. Бізнес аналітики і операційна залученість **Питання:** чи готові операційні менеджери активно брати участь у ML-проєкті? ML-проєкти, де технічна команда ізольована від бізнесу — часто будують не ту модель. «Правильна» задача для ML завжди формулюється разом з людьми, що приймають бізнес-рішення. **Оцінка:** пройдіть опитування з 5 ключовими менеджерами. Чи можуть вони сформулювати конкретну задачу і прийнятний результат? ### 3.3. CDO / Chief Data Officer або Champion **Питання:** чи є хтось у топ-менеджменті, хто «спонсорує» ML-ініціативу? Без executive buy-in ML-проєкти помирають через відсутність ресурсів, пріоритетності або просто через опір змінам. ## Вимір 4: Організаційна культура ### 4.1. Ставлення до прийняття рішень на основі даних **Питання:** як зараз приймаються ключові рішення? На основі даних чи інтуїції? Якщо компанія вже активно використовує аналітику (BI-звіти, KPI, A/B тести) — перехід до ML буде плавнішим. Якщо рішення приймаються «по відчуттю» — потрібен культурний зсув, що займає роки. ### 4.2. Готовність до змін **Питання:** чи є в компанії випадки успішного впровадження нових технологій за останні 2–3 роки? ### 4.3. Ставлення до помилок ML-моделі помиляються. Організація, що вимагає 100% точності з першого дня або не толерує ітеративного підходу — не готова до ML. ## Процес проведення assessment за 2 тижні **Тиждень 1:** - День 1–2: збір документації та даних - День 3–5: технічний аудит (доступ до систем, якість даних, інфраструктура) - День 6–7: інтерв'ю з ключовими stakeholders (CEO, CDO, операційні директори, аналітики) **Тиждень 2:** - День 8–9: аналіз результатів, розрахунок readiness score - День 10–11: формування roadmap і пріоритетних задач - День 12–14: підготовка і презентація звіту ## Результати assessment: Readiness Score Кожен вимір оцінюється за шкалою 1–5. Підсумковий Readiness Score = зважене середнє: - Дані: вага 35% - Технічна інфраструктура: вага 25% - Команда: вага 25% - Культура: вага 15% **Інтерпретація:** - 4.0–5.0: «ML-ready». Можна запускати амбітні проєкти - 3.0–3.9: «Умовно готові». Є прогалини, що потрібно заповнити паралельно - 2.0–2.9: «Потрібна підготовка». 3–6 місяців підготовчої роботи - < 2.0: «Не готові». Фундаментальні проблеми з даними або культурою ML Readiness Assessment — інвестиція, що окупається. Краще витратити 2 тижні і $5 000 на assessment, ніж 6 місяців і $100 000 на проєкт, що приречений провалитись через непідготовленість.