Що змінюється в щоденній роботі?
Що отримує команда
Інформація рухається далі
Дані, введені один раз, можуть використовуватися на наступному етапі: у завданні, звіті, документі або сповіщенні. Ми визначаємо, яка інформація є спільною, а яка потребує підтвердження.
У кожного винятку є відповідальний
Відсутній номер замовлення не залишається непоміченим. Система зупиняє конкретну справу, вказує причину й спрямовує її людині, яка може ухвалити рішення.
Ви знаєте, що відбулося
Історія виконання дає змогу перевірити, з яких даних отримано результат, що змінилося та які завдання потрібно повторити.
Знайдімо момент, коли робота зупиняється.
Починаємо з реального прикладу. Хто отримує дані? Де їх перевіряє? Що копіює? На чиє рішення чекає? Така карта показує різницю між необхідною дією та звичкою, яка залишилася від колишнього способу роботи.
Спираємося на понад 10 років досвіду розробки програмного забезпечення для бізнесу. Знаємо, що у великій організації одна дія часто є частиною кількох пов’язаних процесів. Тому, вдосконалюючи звіт або документ, також з’ясовуємо, хто використовує його далі.
Не кожен крок варто автоматизувати. Якщо правила змінюються з кожним замовленням, спочатку їх потрібно впорядкувати. Якщо проблема полягає у відсутності відповідального за рішення, додатковий застосунок її не розв’яже. Обираємо фрагмент процесу, для якого можна описати правильний результат і розпізнати помилку.
- Звіти, що об’єднують дані з таблиць, файлів і систем.
- Зчитування документів і підготовка даних до перевірки.
- Передавання запитів, погоджень і завдань між людьми.
- Сповіщення про відсутні дані, строки та зміни статусу.
Автоматизація виконує правила. Рішення залишається за людиною.
У процесі підготовки пропозиції система може зібрати вкладення, перевірити повноту даних і підготувати чернетку відповіді. Надсилання пропозиції й надалі може потребувати погодження менеджера з продажу. У звітності можна автоматично підсумувати підтверджені значення, а сумнівні результати розпізнавання залишити для перевірки.
Рішення на основі ШІ використовуємо там, де потрібно інтерпретувати зміст: визначити тип повідомлення, виділити інформацію або запропонувати підсумок. Узгоджуємо обсяг даних, правила контролю та спосіб виправлення результату. Обчислення, валідацію й права доступу будуємо на чітких правилах там, де такі правила існують.
Надійна робота передбачає й неідеальний день.
Файл може надійти двічі, постачальник — змінити структуру документа, а зовнішня система — не відповісти. Ми проєктуємо реакцію на такі ситуації: виявлення повторів, контрольовані повторні спроби та чергу справ, які потребують уточнення. Одне повідомлення не повинно випадково створювати два замовлення.
Перед запуском визначаємо, хто відстежує помилки та як повернутися до ручного опрацювання. Перший етап можна вести паралельно з поточним процесом і порівнювати результати. Лише після перевірки правил розширюємо обсяг самостійної роботи системи.
Для першої розмови достатньо одного реального прикладу.
Підготуйте приклад вхідних даних і очікуваного результату, бажано без персональних даних та конфіденційної інформації. Покажіть звичайний випадок і той, який нещодавно спричинив проблему. Важливіше за розлоге технічне завдання — пояснити, як команда визначає, що роботу виконано правильно.
- Як часто повторюється завдання і скільки людей у ньому беруть участь?
- На якому кроці потрібна оцінка людини?
- Звідки надходять дані та хто може надати до них доступ?
- Що має відбутися, якщо даних бракує або виникає помилка?
Від першої розмови до впровадження
Дослідження
Описуємо вхідні дані, результат, винятки та відповідальність. Обираємо фрагмент, який можна перевірити без перебудови всієї організації.
Перевірка на даних
Будуємо перший потік і порівнюємо результати з ручною роботою. Також перевіряємо дублікати, пропуски та нетипові документи.
Запуск
Запускаємо погоджений обсяг, доступ до історії та опрацювання помилок. Наступні кроки визначає те, що насправді відбувається в процесі.
Запитання, які варто поставити
Чи завжди автоматизація процесів потребує ШІ?
Ні. Для відомих правил часто краще підходить передбачуваний механізм: прочитати дані, перевірити умови, виконати дію. ШІ може допомогти з неоднорідним змістом, але потребує додаткового контролю результатів.
Чи можна почати з одного звіту?
Так. Один звіт із визначеними джерелами й одержувачем — вдалий початковий обсяг. Він дає змогу перевірити якість даних і користь автоматизації, перш ніж додавати наступні процеси.
Що робити, якщо наша програма не має API?
Перевіряємо доступні можливості експорту, імпорту та інші підтримувані способи обміну даними. Відсутність API може означати повільнішу синхронізацію або обмежений обсяг робіт. Ми не припускаємо наявності доступу, якого постачальник не надає.
Як оцінити, чи виправдана автоматизація?
Порівнюємо частоту завдання, витрати часу та ціну помилок з обсягом упровадження й підтримки. Варто врахувати й опрацювання винятків. Якщо завдання повторюється рідко, доцільнішою може бути простіша організаційна зміна.