- Київ
- +380 (98) 543 13 33
В цій статті я розповідаю про те, як підготовити бізнес-процес для автоматизації. Це друга частина матеріалу про створення технічних вимог. Зміст всього матеріалу:
Як працювати з бізнес-процесами
Створення ідеального, або оптимізація існуючого бізнес-процесу, – найскладніша частина роботи бізнес-аналітика. Вам потрібно буде розібратись в існуючому процесі та оптимізувати його, або вигадати новий. Після цього новий або оптимізований робочий процес потрібно узгодити з усіма ключовими учасниками та описати у вигляді технічних вимог, або технічного завдання.
Почнемо з основ. Незалежно від того, яке підприємство ми будемо обговорювати (лікарня, кав’ярня, фабрику з пошиву одягу, і так далі), робочий цикл буде однаковим:
Ви маєте розуміти, що ідеальною бізнес-моделлю є та, в якій попит відповідає пропозиції: клієнти задоволені і не утворюється надлишок товарів або послуг. Для цього деякі компанії можуть починати продажі товарів ще до їх виготовлення. Автор технічних вимог маєте розуміти, що в даній ситуації немає правильного рішення, проте це впливає на формування комунікацій всередині компанії, а також на процеси формування звітності. У першому випадку виробництво формує план продажів, адже вся продукція має бути реалізована, а в другому, – продажі формують завантаження виробництва.
Вам краще якомога раніше розібратись з бізнес-процесами конкретного підприємства, адже вони є фундаментом для побудови архітектури майбутнього програмного забезпечення. Наприклад, у випадках, коли продажі формують навантаження на виробництво, може виникнути ситуація, в якій інформацію про нове замовлення необхідно якомога швидше передавати на виробництво, адже від цього може залежати собівартість конкретного замовлення.
Скоріш за все, у Вас вже сформувалось уявлення про те, як відбувається процес, над автоматизацією якого Ви будете працювати, бо так працює людський мозок. Але Ваш мозок може Вас ввести в оману, тому до вивчення фактичного процесу треба підходити максимально неупереджено. Навіть якщо Ви вже займались автоматизацією подібного процесу на іншому підприємстві. Давайте розберемо на прикладі оформлення кредиту в банку.
Базуючись на попередньому досвіді, я б розділив методи збору інформації на дві категорії: інтерв‘ю і ті, на які ніколи не вистачає бюджету. Детальний опис будь-якого методу із другої категорії Ви легко знайдете в Google, тому я лише перерахую їх:
Ця тема на стільки обширна, що для її розкриття знадобиться ціла стаття. Але я спробую висвітлити окремі думки, про які зазвичай не говорять в класичній літературі. Почнемо з психотипів людей, з якими Вам доведеться працювати. Звертаю увагу на те, що це класифікація дуже спрощена, і показує вплив на роботу автора технічних вимог.
Найскладніше працювати з другим типом людей. Із власного досвіду можу порекомендувати не сприймати їх невдоволення як особисту образу. Краще намагайтесь спілкуватись з ними через керівництво. Зрештою, це їх проблема, а не Ваша.
Щоб будувати ефективну комунікацію, Вам потрібно навчитись швидко завойовувати довіру людей, та не втрачати її протягом всього часу. Маю декілька порад щодо цього:
Після закінчення дослідження процесу Ви маєте почати формувати перші артефакти: поетапний опис бізнес-процесу та довідник працівників, які відповідають за кожен етап.
Найбільший вплив на розробку програмного забезпечення матиме чинне законодавство в сфері діяльності компанії: кодекс, постанови, нормативно-правові акти, і так далі. Кількість таких обмежень буде відрізнятись, в залежності від сфери діяльності компанії. Вам бажано прочитати їх всі. Рекомендую відразу додавати всі обмеження і посилання в таблицю. Зверніть увагу, що крім обмежень у Вас можуть з‘явитись навіть нові обов‘язкові етапи.
Після закінчення цього етапу, у Вас має сформуватись повний, та повністю легальний бізнес-процес, з яким можна починати активно працювати.
Може відбуватись двома шляхами: заміна витрат людського ресурсу на комп‘ютерні розрахунки, або ж нехтування застарілими бізнес-процесами під час автоматизації. Давайте розглянемо на прикладі автоматизації того ж самого процесу, — оформлення кредиту та отримання готівки в касі банку.
Давайте уявимо, що обмін кредитними історіями до початку автоматизації відбувається менеджерами вручну, і для цього необхідно відправити менеджера на інший край міста. Там він заходить в спеціальну будівлю, сідає за комп‘ютер і ознайомлюється з усією необхідною інформацією. Скільки часу він на це витратить? Три-чотири години на одного клієнта. Але автоматизація цього процесу дозволила йому переглядати інформацію про потенційних клієнтів одразу на своєму робочому місці. Відповідно, час обробки однієї заявки скоротився в декілька разів. Так ось задача людини, яка буде займатись проектуванням майбутньої системи, — це автоматизувати якомога більшу кількість таких процесів, щоб скоротити витрати ресурсів. А для цього необхідно непогано розбиратись в домені компанії щоб розуміти, що взагалі підлягає автоматизації.
А тепер інша ситуація. В нашому вигаданому банку існує людина, яка в кінці кожного робочого дня підраховує кількість використаного паперу. Навіщо? Ніхто не може відповісти. Чи треба цей процес автоматизовувати? — Звичайно ж ні! Якщо говорити звичайною мовою, то до кожного процесу потрібно задати питання: «Шоб шо?» І якщо Ви не почуєте одразу чіткої відповіді, то варто задуматись над доцільністю існування цього процесу в житті компанії.
Крім очевидної економії ресурсів, автоматизація дає можливість подумати над пошуком додаткових можливостей для отримання прибутку. Для цього доповнимо нашу таблицю.
Всі додаткові можливості Ви маєте узгодити з замовниками, щоб уникнути конфліктів інтересів. Але будьте готові до того, що Ваші майбутні клієнти не обов’язково мають бути у захваті від Ваших пропозицій. Наприклад, керівник відділу обслуговування клієнтів скоріше за все буде у захваті від нових можливостей, в той час як керівник касового обслуговування – ні. Тому процес узгодження процесу є найскладнішим в роботі аналітика і може затягуватись з неочевидних для Вас причин. Для презентації результатів Вашої роботи замовнику, бізнес-процес можна відобразити у вигляді діаграми з використанням мов UML або BPMN.
Після подолання останнього бар’єру в спілкуванні з замовниками під час узгодження нового робочого процесу, Ви отримуєте досить детально описаний позитивний сценарій поведінки системи. Тепер Ви маєте зосередитись на тому, щоб закласти основи поведінки майбутньої системи не тільки в позитивних, а й в негативних сценаріях. Давайте поясню на прикладі етапу “Подача заявки на отримання кредиту”.
Це сценарій, який описує поведінку системи під час досягнення бізнес-цілей. Наприклад, коли клієнт звертається в банк для отримання кредиту, то позитивним завершенням першого етапу можна вважати заповенену і успішно відправлену заявку на його отримання.
Це сценарій, який описує поведінку системи у випадку виникнення будь-яких непередбачених обставин під час спроби досягнення бізнес-цілей. Коли клієнт звертається в банк для отримання кредиту, то негативним сценаріє варто вважати будь-яку подію, яка не дозволяє заповнити заявку та відправити її на розгляд в кредитний комітет. Наприклад, у клієнта відсутні необхідні документи, або у відділенні вимкнули світло. Від кількості та різноманітності передбачених негативних сценаріїв буде залежати стабільність та передбачуваність поведінки майбутньої системи. Всі негативні сценарії також додавайте в таблицю.
| Назва етапу | Сценарій | Відповідальна роль, або очікуваний результат поведінки системи під час настання негативного сценарію | Менеджер по роботі з клієнтами | Менеджер кредитного комітету | Касир |
| Подача заявки на отримання кредиту | Позитивний | Менеджер по роботі з клієнтами | Створює нову заявку на отримання кредиту (до 100 000 грн, відповідно до постанови #17 НБУ), заповнює її, та відправляє на розгляд кредитного комітету | Отримує заявку та розглядає її | А чи може касир в майбутній системі створювати заявки на отримання кредиту, щоб пришвидшити цей процес? |
| Негативний сценарій #1: у клієнта відсутні всі необхідні документи | Заявка відправлена успішно, але знаходиться в статусі “Чернетка”, — це дозволить зекономити час на її заповненні при повторному зверненні клієнта | ||||
| Негативний сценарій #2: в відділенні банку зникло світло під час створення заявки | Система зберігає чернетку заявки на комп’ютері автора та оновлює її після заповнення кожного поля, — це дозволить зекономити час на її заповненні при ввімкненні світла | ||||
| Перегляд кредитної історії | Звертається в УБКІ та переглядає кредитну історію клієнта | ||||
| Отримання рішення кредитного комітету | Менеджер кредитного комітету | Виносить рішення стосовно видачі кредиту та відправляє його | Отримує рішення про видачу готівки клієнту | ||
| Видача готівки в касі банку | Касир | Верифікує клієнта та видає йому необхідну суму |
Таким чином, після успішного завершення цього етапу Ви отримаєте не тільки новий процес, а й перший вагомий артефакт: покроковий опис поведінки системи, який в подальшому трансформується в технічне завдання.