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