Відповідь на презентацію Михайла Софілканича від 02.09.2026: кроки від заявки до передачі й супроводу, на кожному кроці роль і людина, документ на виході, хто його підтверджує і строк; точки входу ІТ та ІБ МХП; ролі бізнес-аналітика і системного аналітика; що робиться, коли замовник змінює вимоги. У розділі 9 відповіді на питання зі слайдів 10 до 13 так, як є зараз, а не як хотілося б.
| Підстава | зустріч МХП і Initask 02.09.2026, презентація «Поставка AI-агентів: проблема, напрямок рішення і питання до IniTask» |
|---|---|
| Координатор МХП | Михайло Софілканич, радник Голови ради директорів з впровадження ШІ |
| Відповідальні Initask | Віталій Міняйло (керівник, архітектура, ТЗ і оцінка), Катерина Почерніна (менеджер проєктів, веде замовника від першої розмови до супроводу) |
| Статус | проєкт для правок Михайла; після погодження стає єдиним регламентом для всіх заявок МХП і основою памʼятки у кожному Telegram-каналі |
| Пілот регламенту | два кейси фінблоку: собівартість продукції (Юлія Шевела) і фінансовий сервіс (Максим). Обидва повертаються на крок 2 «Опис потреби» і проходять процес першими |
| Дата | 3 вересня 2026 |
Сині картки: крок на боці МХП. Рядок під пунктиром: чиє підтвердження відкриває наступний крок. Обидва кейси фінблоку повертаються на крок 2.
Строки рахуються у робочих днях. Строк відповіді замовника і МХП це не претензія, а межа, після якої позиція у Sync позначається «чекає на замовника» і лічильник іде на його бік.
| Крок | Хто робить (роль і людина) | Вхід | Документ на виході | Хто підтверджує | Строк | Хто може бути блокером |
|---|---|---|---|---|---|---|
| 0. Заявка | Михайло знаходить ініціативу і передає замовника. Катерина Почерніна реєструє | потреба підрозділу словами замовника | картка заявки у Sync (етап «нова заявка»), Telegram-канал проєкту з памʼяткою | Михайло: замовник переданий, контактна особа названа | 1 день | МХП: не названо власника процесу |
| 1. Бриф | замовник (керівник і фахівець) разом з PM Initask (Катерина) на інтервʼю 45 до 60 хвилин. Форма на initask.com/brief/mhp або документ у довільній формі, якщо замовник не хоче форми | картка заявки | Бриф обсяги, системи, болі, очікуваний результат, хто підтверджує результат, права агента, контур | замовник поштою: «бриф відповідає нашому запиту» | 5 днів від заявки | замовник: немає часу на інтервʼю |
| 2. Опис потреби | бізнес-аналітик Initask (Катерина, на першій сесії разом з Віталієм) і власник процесу замовника. Одна або дві робочі сесії по 60 до 90 хвилин на його документах | бриф, робочі файли і методики замовника | Опис потреби процес як є; бізнес-логіка і формули, за якими замовник рахує сьогодні; винятки; джерела даних; критерії приймання пунктами; від трьох реальних кейсів з відомим правильним результатом; що не входить | замовник поштою, дослівно: «описано правильно, за цим можна робити ТЗ» | 5 днів на документ, 3 дні на відповідь замовника | замовник: методика не передана або немає кейсів; Initask: документ не готовий |
| 3. Архітектурна записка | системний аналітик Initask (Віталій) разом з точкою входу ІТ МХП і представником ІБ МХП ІТ МХПІБ МХП | опис потреби | Архітектурна записка джерела і спосіб доступу (вивантаження, view, API), де живе агент, яка модель і де вона працює, які дані виходять за контур і як маскуються, доступи лише на читання, журналювання, резервування | ІТ МХП: доступи і розгортання. ІБ МХП: дані, модель, контур | 5 днів на записку; строк погодження ІТ та ІБ за їхнім регламентом, його називає Михайло | ІТ МХП або ІБ МХП: немає відповіді або немає точки входу |
| 4. ТЗ і оцінка | Віталій пише ТЗ і оцінку, Катерина звіряє ТЗ з описом потреби пункт за пунктом | опис потреби, архітектурна записка | ТЗ що агент робить і чого не робить, критерії приймання у форматі «закрито або не закрито», план перевірки на кейсах з кроку 2, строк, межі відповідальності. Оцінка CAPEX і OPEX цього агента, картка у Карті проєктів Sync | замовник: ТЗ і критерії. Михайло: оцінка, далі затвердження бюджету на боці МХП | 5 днів на ТЗ, 3 дні на відповідь | замовник: ТЗ не підтверджене; МХП: бюджет не затверджений |
| 5. Замовлення | Михайло, юридична служба і підписант МХП, Initask | підтверджене ТЗ і оцінка | Замовлення до рамкового договору, ТЗ і критерії приймання додатком, строк, ціна, порядок змін | підписант МХП | за регламентом МХП | МХП: договірний цикл |
| 6. Розробка і пілот | команда Initask, керівник розробки Віталій. Катерина веде замовника: щотижнева синхронізація 15 хвилин, показ проміжного результату раз на два тижні на кейсах замовника | замовлення, доступи або вивантаження за запискою | робочий кабінет з доступом замовника з першого тижня; Протокол після кожної зустрічі у канал того ж дня; Реєстр змін (розділ 6) | протоколи: замовник читає, заперечення протягом 2 днів. Зміни до ТЗ: лише поштою, письмово | за ТЗ; орієнтир за типом рішення: з каталогу 120 годин, доопрацювання 200, з нуля 320 | замовник: немає відповіді на питання понад 2 дні; ІТ МХП: доступ не виданий; Initask: зрив строку з ТЗ |
| 7. Внутрішня перевірка | тестувальник Initask (Катерина), не той, хто розробляв. Автоматичні прогони плюс ручний прохід | реліз, кейси замовника з кроку 2 | Протокол внутрішнього прогону кожен критерій ТЗ з результатом, на яких даних перевірено | Віталій. Без зеленого протоколу замовнику не показуємо | 2 до 3 дні | Initask |
| 8. Приймання | замовник (керівник і фахівець) разом з Катериною, на кейсах з кроку 2 і на нових, які замовник приносить на приймання | протокол внутрішнього прогону, кабінет | Протокол приймання кожен критерій ТЗ закрито або не закрито з коментарем; зауваження класифіковані: дефект або зміна. Акт | замовник поштою, копія Михайлу | 5 днів на приймання; дефекти виправляємо, повторне приймання лише по відкритих пунктах | замовник: приймання не проведене у строк; Initask: відкриті дефекти |
| 9. Передача і супровід | Катерина за стандартом супроводу Initask; ІТ МХП, якщо агент розгорнутий у контурі МХП ІТ МХП | акт | Памʼятка користувача, канал звернень; кожне звернення це тікет з карткою закриття (причина, що змінено, хто, як перевірили, тип робіт); Звіт раз на місяць одним посиланням | тікет закриває ініціатор, не виконавець | реакція за пріоритетом: P1 за 2 години, P2 за робочий день, P3 і P4 за 3 дні | називається у кожному тікеті: замовник (потрібні дані), Initask, ІТ МХП |
Етапи воронки у кабінеті Sync відповідають крокам: «нова заявка» (0), «бриф надіслано» і «бриф повернувся» (1), «зустріч» (2), «оцінка капекс і опекс» (3 і 4), «на погодженні бюджету» і «погоджено» (5), «у розробці» і «пілот» (6 до 8), «в експлуатації» і «оцінка замовника» (9). Тому «де ми зараз» видно у кабінеті без переписки.
| Коли | Хто з боку МХП | Що погоджується | Що приносить Initask |
|---|---|---|---|
| Крок 3, до ТЗ і до розробки ІТ | точка входу ІТ (керівник напряму або архітектор) і адміністратор системи-джерела (1С, ERP, сховище, Power BI). Персоналії називає Михайло | спосіб доступу до даних (вивантаження, view, API), технічний користувач лише на читання, де розгортається агент, вимоги до середовища, порядок оновлень | архітектурну записку, перелік потрібних обʼєктів і полів, оцінку навантаження, схему розгортання контейнером, план резервування |
| Крок 3, до ТЗ і до розробки ІБ | представник департаменту інформаційної безпеки | класифікація даних, які дані виходять за контур і як маскуються, вибір моделі (хмарна у регіоні ЄС або локальна), журналювання дій агента, доступи людей, NDA | ту саму записку з окремим розділом ІБ: потоки даних, де працює модель, що саме бачить модель, як рахується вердикт (детермінований код, модель лише розбирає текст) |
| Крок 6, при інтеграції ІТ | адміністратор системи-джерела | видача доступів за запискою, тестовий контур, вікна для навантаження | запит доступів у форматі ІТ МХП, звіт про використання доступів |
| Крок 8, перед бойовим доступом ІБ | представник ІБ | підтвердження, що реалізація відповідає записці; повторне погодження лише якщо контур змінився | протокол відповідності записці |
| Крок 9, супровід ІТІБ | чергова служба ІТ, ІБ при інцидентах | порядок оновлень, інциденти, відкликання доступів | памʼятку експлуатації, журнал змін, контакти |
Хто вирішує: ІБ і ІТ МХП на кроці 3 за архітектурною запискою. За замовчуванням пілот проходить у першому варіанті, бойова експлуатація за запискою.
| Роль | Що робить у процесі | Як є зараз в Initask | Як буде за регламентом | Що потрібно від МХП |
|---|---|---|---|---|
| Бізнес-аналітик | витягує з замовника процес як є, бізнес-логіку і формули, винятки, критерії приймання і реальні кейси; пише опис потреби (крок 2); звіряє ТЗ з описом (крок 4); веде приймання (крок 8) | окремої посади немає. Роль виконують менеджер проєктів і Віталій на зустрічах, без окремого документа на виході. Через це логіка собівартості не була знята і записана до старту | роль закріплена за Катериною Почерніною. Документ на виході обовʼязковий, без підтвердження замовника далі не йдемо | власник процесу з боку замовника: фахівець, який рахує сьогодні, 2 до 3 години на тиждень на кроках 1 і 2, далі 1 година на тиждень. Створювати нову посаду не треба |
| Системний аналітик | перекладає потребу в архітектуру: джерела, інтеграції, доступи, де живе агент, модель; пише архітектурну записку (крок 3) і ТЗ (крок 4) | Віталій Міняйло. Записки як окремого документа не було: усе робилось на вивантаженнях, тому ІТ та ІБ не залучались | Віталій, документ на виході обовʼязковий і погоджується ІТ та ІБ МХП до ТЗ | точка входу ІТ і адміністратор системи-джерела на кроці 3; представник ІБ. Створювати роль з боку МХП не треба, треба назвати людей |
| Менеджер проєктів | одна людина від першої розмови до супроводу: веде замовника, календар зустрічей, протоколи, реєстр змін, Sync і Telegram-канал | Катерина Почерніна. Технічні зустрічі просили проводити з Віталієм, і через його зайнятість одна зустріч з Юлією не відбулась | Катерина. Технічні зустрічі плануються з Віталієм заздалегідь у календарі замовника; перенесення лише за домовленістю з замовником | назвати контактну особу замовника і час, який вона дає (розділ 8) |
Мовчки не робиться нічого і не відкидається нічого. Кожне «а ще треба ось це» проходить один і той самий шлях.
| Документ | Крок | Автор | Підтверджує | Де лежить |
|---|---|---|---|---|
| Бриф | 1 | замовник з PM | замовник | картка позиції у Sync, копія у каналі |
| Опис потреби | 2 | бізнес-аналітик Initask | замовник поштою | Google Docs з доступом замовника і Михайла, посилання у картці Sync |
| Архітектурна записка | 3 | системний аналітик Initask | ІТ і ІБ МХП поштою | Google Docs, посилання у картці |
| ТЗ з критеріями приймання | 4 | Initask | замовник і Михайло поштою | Google Docs, додаток до замовлення |
| Оцінка CAPEX і OPEX | 4 | Initask | Михайло | Карта проєктів у Sync, вивантаження для CEO |
| Замовлення | 5 | Initask і юрслужба МХП | підписант МХП | договірний архів обох сторін |
| Протокол зустрічі | кожна зустріч | PM Initask | замовник: заперечення за 2 дні; зміни до ТЗ лише поштою | Telegram-канал того ж дня |
| Реєстр змін | 6 | PM Initask | замовник поштою по кожній зміні | картка позиції у Sync |
| Протокол внутрішнього прогону | 7 | тестувальник Initask | Віталій | картка позиції у Sync |
| Протокол приймання і акт | 8 | PM Initask із замовником | замовник поштою, копія Михайлу | Sync і договірний архів |
| Тікети і місячний звіт супроводу | 9 | PM Initask | ініціатор тікета | кабінет супроводу, посилання у каналі |
| Питання | Правило |
|---|---|
| Як формується вартість і коли | CAPEX і OPEX рахуються по кожному агенту окремо, на підставі підтвердженого ТЗ, на кроці 4, до замовлення. Карта проєктів у Sync до ТЗ це орієнтир по заявці, після ТЗ у картці стоїть цифра з ТЗ. CAPEX це години за типом рішення (з каталогу 120, доопрацювання 200, з нуля 320) за ставкою 35 доларів на годину плюс резерв 15% на зміни. OPEX це місячна підписка за каталогом агентів Initask, включає роботу моделі, сервери ядра, супровід і оновлення. Той самий агент у двох підрозділах оплачується один раз, другий підрозділ платить 30% за адаптацію і власну підписку. |
| Хто затверджує на боці МХП | оцінку погоджує Михайло і несе на затвердження бюджету за процедурою МХП. Персоналії затвердження бюджету називає Михайло. |
| Договірна рамка | рамковий договір один раз, далі замовлення на кожного агента. Предмет замовлення це ТЗ з критеріями приймання і строком, а не «агент» і не опис можливостей. Зміни за розділом 6. |
| Гарантія і супровід | дефект у межах гарантії не списується з годин супроводу: у звіті такі тікети стоять з нульовими годинами і позначкою «гарантія». Супровід за стандартом Initask: тікет, картка закриття, місячний звіт, пріоритети P1 до P4. |
| Хто з боку замовника реально працює з нами і скільки часу | дві людини: керівник підрозділу (рішення, підтвердження документів, приймання) і власник процесу (методика, дані, кейси, відповіді на питання). Час: кроки 1 і 2 разом 4 до 6 годин протягом двох тижнів; розробка 1 година на тиждень на синхронізацію плюс відповіді на питання за 2 робочі дні; приймання 3 до 4 години. Якщо замовник цього часу дати не може, це фіксується у картці як блокер на боці замовника, а не як затримка Initask. |
| Питання | Як є зараз | Як буде за регламентом |
|---|---|---|
| Хто заповнює бриф і де | замовник сам, у формі на initask.com/brief/mhp з картки каталогу; відповіді падають до нас і у Sync. Частина замовників бриф не заповнювала (Юлія відмовилась: «зробимо один, далі решту»), тоді потребу знімали усно на зустрічі і з переданих файлів. У формі бракувало: логіки як є, критеріїв приймання, реальних кейсів, хто підтверджує результат | бриф заповнюється на інтервʼю з PM (крок 1), а логіка, критерії і кейси знімаються окремим документом на кроці 2 і підтверджуються поштою |
| Що відбувається між брифом і початком робіт | роботи починались одразу після зустрічі, рішення «йде в роботу» приймав Віталій. Кроку, де ми повертаємо замовнику своє розуміння, не було. Саме тут народились обидва кейси | крок 2 обовʼязковий, без письмового підтвердження опису потреби розробка не починається |
| Хто з нашого боку веде замовника | Катерина Почерніна від першої розмови, технічні питання Віталій. Письмово ролі не були закріплені, і замовники просили присутності Віталія на кожній зустрічі | Катерина від першої розмови до супроводу, Віталій на кроках 2, 3, 4 і на технічних зустрічах за календарем. За відповідність результату ТЗ відповідає Віталій, за відповідність ТЗ опису потреби Катерина |
| Де фіксується домовлене | нотатки Fireflies, Telegram, описи рішень у Google Docs (для собівартості це «План пілота v2»), але без письмового підтвердження замовника. Документа, у якому замовник підтвердив, що саме робитиме агент, сьогодні немає у жодному з двох кейсів | опис потреби і ТЗ, обидва підтверджені поштою; протоколи у каналі; зміни через реєстр |
| Бізнес-аналітик є чи немає | окремої посади немає, роль виконують PM і Віталій без документа на виході | роль закріплена за Катериною, документ на виході обовʼязковий. З боку МХП потрібен власник процесу, не нова посада |
| Системний аналітик є чи немає | Віталій; записки як документа не було | Віталій, записка погоджується ІТ і ІБ МХП до ТЗ |
| ТЗ: хто пише, хто погоджує, коли | описи рішень писали ми у довільній формі, погоджувались усно або не погоджувались. Оцінка вартості робилась по заявці, до ТЗ | ТЗ за шаблоном (розділ 7), пише Віталій, звіряє Катерина, підтверджують замовник і Михайло поштою, після архітектурної записки і до замовлення. Оцінка йде разом з ТЗ |
| Що є критерієм «зроблено правильно» | наші автоматичні прогони (сотні перевірок на кабінет) на наших прикладах і на файлах, які замовник передав. Чого бракувало: набору реальних кейсів замовника з відомим правильним результатом і критеріїв, підписаних ним. Тому «звірка в нуль на файлі» для Юлії не була критерієм: вона чекала логіку розрахунку, а не звірку | критерії і кейси задає замовник на кроці 2; внутрішній прогін і приймання ідуть по них |
| Як обробляються зміни | правки з переписки робились одразу, без запису і оцінки | реєстр змін, оцінка за 2 дні, чотири рішення, письмова відповідь замовника (розділ 6) |
| На якому кроці йдемо в ІТ МХП і з ким | не йшли взагалі: усі кабінети працюють на наших ресурсах з вивантаженнями, тому доступи не були потрібні. Точки входу в ІТ у нас немає | крок 3, до ТЗ. Точку входу і адміністраторів систем називає Михайло до 10.09 |
| Де живе агент і хто це вирішує | у нашій хмарі (Azure), окремий сервер під кожен кабінет, вхід за логіном. Вирішували ми, бо замовник просив MVP на вивантаженнях | три варіанти у розділі 4, вибір ІБ і ІТ МХП на кроці 3 |
| Коли заходить ІБ і чи заходила для фінблоку | не заходила. Дані для фінблоку передавались вивантаженнями поштою і через Google Drive за рішенням самого замовника | крок 3 (дані, модель, контур) і крок 8 (підтвердження перед бойовим доступом) |
| Хто супроводжує після здачі | ми, через робочий чат, без тікетів. Стандарт супроводу Initask (тікет, картка закриття, місячний звіт, гарантія без списання годин) є, для МХП ще не застосовувався, бо жоден агент формально не зданий | крок 9 за стандартом, з першого зданого агента |
| Як формується вартість і хто затверджує | Карта проєктів у Sync: CAPEX по нормах годин за типом рішення, OPEX за каталогом, по кожному агенту, рахувалось по заявці. Хто затверджує на боці МХП: Михайло і далі CEO за картою | те саме, але після ТЗ і з підтвердженням Михайла на кроці 4 |
| Договірна рамка | договору з МХП немає; пілоти робились до договору | рамковий договір плюс замовлення на агента з ТЗ як предметом |
| Хто з боку замовника реально працює з нами | керівник підрозділу: заявка і фідбек по результату. Фахівець з методикою і даними зʼявлявся не завжди, час не був домовлений | дві людини і час за розділом 8, зафіксовані у картці на кроці 0 |
Це не претензія, а перелік того, що теж має піти у процес.
| Коли | Що | Хто |
|---|---|---|
| до 10.09 | цей документ у Михайла на правках; ІТ і ІБ МХП: точки входу; фінблок: зобовʼязання замовника; підготовка двох кейсів до повернення на крок 2 | Initask, Михайло |
| 10.09 | зустріч: погодження воркфлоу, правки Михайла, один документ для всіх заявок | Михайло, Віталій, Катерина |
| до 12.09 | памʼятка у кожному Telegram-каналі (розділ 12), картки обох кейсів у Sync повернуті на етап «зустріч» | Катерина |
| тиждень після 10.09 | крок 2 по собівартості: робоча сесія з Юлією на її методиці, документ «Опис потреби» з логікою розрахунку її словами, критеріями і кейсами; підтвердження поштою | Катерина, Віталій, Юлія |
| тиждень після 10.09 | крок 2 по фінансовому сервісу: те саме з Максимом. Зустріч 03.09 проводиться уже як крок 2: інтервʼю по процесу як є, а не показ | Катерина, Віталій, Максим |
| далі | кроки 3 і 4 по обох кейсах з ІТ і ІБ; нові заявки (агровиробництво і решта) йдуть лише за процесом: без підтвердженого брифу і ТЗ робота не починається | усі |
Закріплюється у кожному каналі після погодження. Замовник бачить, де він зараз і що від нього очікують.