Зміст
Вступ
Корпоративний ШІ не варто проєктувати за презентацією постачальника чи переліком доступних моделей. Спершу архітектор має зрозуміти підприємство: як організована робота, де створюються знання, хто ними користується та яких обмежень не можна порушувати.
Обстеження замінює припущення фактами. Воно допомагає обрати перший сценарій із реальною цінністю, а не побудувати технічно цікаву, але непотрібну систему.
Чому це важливо
Цінні знання рідко зберігаються в одній системі. Вони розподілені між системами планування ресурсів, системою електронного документообігу, файловими архівами, методиками, листуванням і досвідом фахівців. Самого переліку ІТ-систем недостатньо, щоб побачити весь контекст.
Обстеження також дає змогу заздалегідь визначити власників даних, вимоги інформаційної безпеки та вимірювані ознаки успіху пілота.
Основне пояснення
Роботу варто вести за кількома пов'язаними напрямами:
- інтерв'ю з керівниками, експертами й виконавцями;
- аналіз бізнес-процесів і втрат часу;
- інвентаризація систем та джерел знань;
- оцінювання зрілості інфраструктури;
- фіксація вимог безпеки й регулювання.
flowchart TD
interviews[Інтерв'ю] --> assessment[Архітектурне обстеження]
processes[Процеси] --> assessment
systems[Інформаційні системи] --> assessment
knowledge[Джерела знань] --> assessment
security[Вимоги безпеки] --> assessment
assessment --> requirements[Архітектурні вимоги]
Інтерв'ю лише з ІТ-службою недостатньо. Запитайте людей, які щодня працюють із документами: які відомості важко знайти, яким джерелам вони довіряють, де застарілі дані спричиняють помилки та чию експертизу ще не зафіксовано.
Безпека
| Запитання | Практичне значення |
|---|---|
| Які дані конфіденційні? | Визначає межі контуру й доступу |
| Які системи критичні? | Задає пріоритети захисту та відновлення |
| Хто володіє даними? | Визначає відповідальність за якість |
| Які вимоги обов'язкові? | Формує архітектурні обмеження |
Ці відповіді мають стати вхідними даними для проєктування до інтеграції та індексації, а не після першого інциденту.
Корпоративний приклад
Інженерна організація використовує систему планування ресурсів, систему електронного документообігу, архіви та внутрішній портал. Під час обстеження команда виявляє, що важливі методики й експертні висновки також містяться в листуванні та робочих каталогах.
Початковий план підключити одну систему перетворюється на поетапну стратегію роботи з джерелами. Для кожного визначають власника, пріоритет і правила доступу.
Приклад з промислової безпеки
У підрозділі експертизи промислової безпеки ключовими джерелами стали норми, внутрішні методики, архів висновків і результати обстежень. Водночас частина важливих практичних знань існувала лише в досвіді кількох провідних експертів.
Для платформи це окреме завдання: зберегти й перевірити експертизу, не видаючи її за затверджене джерело. ШІ пришвидшує пошук і підготовку матеріалів, але відповідальність за висновок залишається за фахівцем.
Типові помилки
- Проводити інтерв'ю лише з ІТ-службою.
- Вважати неструктуровані документи другорядними.
- Не фіксувати знання, що існують лише у співробітників.
- Відкладати питання безпеки до реалізації.
- Проєктувати рішення до завершення обстеження.
Практичні висновки
Результатом обстеження мають бути робочі артефакти: карта процесів, перелік систем, каталог джерел знань, власники даних, вимоги безпеки та архітектурні ризики.
Не потрібно одразу описувати все підприємство з однаковою деталізацією. Достатньо отримати надійну картину для вибору одного обмеженого сценарію та визначити питання наступних етапів.
Ключові тези
- Мета обстеження — зрозуміти підприємство, а не обрати технологію.
- Знання є і поза формальними корпоративними системами.
- Власників даних та обмеження потрібно визначити заздалегідь.
- Архітектурні рішення ухвалюють на підставі фактів.
- Безпека починається з першого інтерв'ю.