Як ІТ бізнес-аналіз покращить роботу у вашому бізнесі. Конспект лекції Кирила Белявського в рамках інтеграції з Дія.Бізнес

Бізнес-аналіз — це виявлення реальних бізнес-потреб компанії, створення та реалізація плану по їх вирішенню через впровадження ефективних змін у процеси, у тому числі, за рахунок цифрової трансформації. Докладніше про це розповість провідний фахівець у Business Analytics Кирило Белявський, що має великий досвід у традиційному та IT-менеджменті.

Про лекції

Це п’ята лекція з циклу освітніх вебінарів за ініціативою IAMPM разом з Дія.Бізнес, теми яких:

1. Цифрова трансформація для не ІТ-компаній.
2. Цифрові трансформації без значних фінансових вкладень.
3. Робота та розвиток компанії за ІТ-практиками.
4. Продуктовий менеджмент за ІТ-практиками.
5. Як ІТ бізнес-аналіз покращить ваш бізнес.

Ця лекція важлива, бо в ній ви дізнаєтесь про:

1. Основні завдання бізнес-аналітика.
2. Бізнес-аналіз у традиційному та ІТ-менеджменті.
3. Комунікацію із зацікавленими сторонами — стейкхолдерами.
4. Техніки формування цінностей та цілей проєкту.
5. Моделювання того, як буде працювати компанія.

Трохи про спікера:

Кирило Белявський, Lead Business Analysis в Softserve. Понад 14 років у корпоративному бізнесі, останні 6 років працює в IT. На практиці знає відмінності бізнес-аналізу у ІТ-компаніях та традиційному бізнесі. Також займає посаду Business Analysis Office Service Manager у компанії SoftServe. Кирило управляє командами бізнес-аналітиків, активно бере участь на різних стадіях залучення клієнта, веде подкаст.

Основні завдання Business Analyst на прикладі IT

Бізнес-аналітик у IT-компанії виступає своєрідним містком між командою розробки та замовником, основні завдання якого — це:

• зрозуміти потреби клієнта, виходячи зі специфіки його бізнеса;
• допомогти обрати вірне рішення, щоб перекласти бізнес-ідею на софт та реалізувати поставленні бізнес-цілі;
• налагодити ефективну комунікацію між клієнтом та командою розробки;
• супроводити зміни у бізнесі клієнта, що пов’язані із впровадженням IT-рішень в екосистему роботи його організації.

Тепер доречно уточнити, чи існують відмінності у роботі на позиції Business Analyst у IT-компанії від аналогічної посади у традиційному бізнесі.

Бізнес-аналіз у традиційному та ІТ-менеджменті

Основні знання про Business Analysis складені у посібник під назвою BABOK (Business Analysis Body of Knowledge), який розробили фахівці Міжнародного інституту бізнес-аналізу IIBA. У книзі викладені підходи та техніки, які допомагають ефективно проводити аналіз бізнесу незалежно від напрямку діяльності компанії.

Увесь матеріал у BABOK базується на 6 концепціях, які використовує у своїй роботі кожен Business Analyst:

1. Needs (потреби) — проблеми бізнесу (закрити питання щодо покращення робочого процесу, комунікації тощо) або ж можливості (зростання компанії, вихід на новий ринок та подібне). Уявимо магазин взуття, у якому купують товари тільки офлайн-клієнти. Щоб підвищити продажи (потреби), власник робить сайт — це і є можливість.
2. Solution (рішення) — те, що допоможе задовольнити бізнес-потреби. Наприклад, для зменшення витрат компанії власник оптимізує кількісний склад співробітників організаційними методами.
3. Value (користь) — опис того, що саме ви повинні отримати у результаті впровадження конкретного рішення, та як це виміряти. Наприклад, якщо проблема фінансова, то користь буде оцінюватися грошими. Якщо пов’язано з процесом, то це вимірюватиметься у різниці часу на виконання якоїсь задачі до впровадження рішення та після. 
4. Stakeholders (стейкхолдери) — люди та організації, що приймають участь у створенні рішення чи якимось чином можуть вплинути на нього, або ж навпаки — Solution впливає на них.
5. Changes (зміни) — ті перетворення, що відбуваються у бізнесі після реалізації рішення незалежно від того.
6. Contexts (контекст) — описує, що саме відбувається навколо всього процесу: які стейкхолдери на проєкті та як працюють, Solution якого типу обрано тощо.

На схемі видно, як всі 6 концепції пов’язані між собою. Бізнес-аналітик працює з усіма ними разом незалежно від ніші компанії. 

Різниця між роботою бізнес-аналітика у традиційному бізнесі та IT

Якщо порівнювати роботу Business Analyst в IT та у традиційному бізнесі, основні відмінності — у фокусі айтішного фахівця.

Business Analyst охоплює всі етапи розробки рішення: від потреб до оперативної діяльності після впровадження. Між традиційним бізнес-аналізом та IT різниця у тому, що в айтішній компанії фахівець робить більший фокус на Solution, вимогах до нього та тому, як воно буде виглядати та функціонувати.

Комунікація зі стейкхолдерами на прикладі IT-проєктів

Від того, як бізнес-аналітик вибудує комунікацію з усіма зацікавленими сторонами, багато у чому залежить процес розробки та подальшої реалізації задуманого. Узагальнений список стейкхолдерів, які можуть бути на будь-якому проєкті:

• Business Analyst — бізнес-аналітик;
• Customer — замовник рішення;
• Domain Subject Matter Expert — експерт-консультант, який добре розуміє нішу конкретного бізнеса;
• End User — кінцевий користувач рішення: замовник цього Solution або його клієнт, співробітник, колега;
• Implementation Subject Matter Expert — фахівці, що будуть втілювати задуми Customer у життя; 
• Operational Support — служба підтримки; 
• Project Manager — менеджер, який відповідає за проєкт загалом;
• Regulator — регулятор, вимогам якого має відповідати рішення: держоргани, фахові стандарти тощо;
• Sponsor — спонсор, що фінансує розробку та реалізацію рішення; 
• Supplier — люди чи організації, які поставляють додаткові сервіси, без яких розробка та робота Solution ускладнені чи неможливі; 
• Tester — відповідальний за тестування готового рішення.

Деякі стейкхолдери можуть виступати одразу у кількох ролях (наприклад, Customer може бути ще Sponsor) або взагалі бути відсутніми на проєкті. Також кожен з них має свій рівень впливу на майбутнє рішення:

Процес роботи бізнес-аналітиків зі стейкхолдерами та інструменти

Перед стартом проєкту Business Analyst повинен визначити, з ким він буде комунікувати під час роботи, та що пов’язує кожного Stakeholder з майбутнім рішенням. Починати краще всього зі збору даних про всіх зацікавлених сторін та заповнити ними так званий Stakeholder Register — таблицю, в якій є основні дані всіх стейкхолдерів:

• ім’я та посада;
• роль у проєкті: замовник, спонсор тощо;
• контакти для зв’язку;
• вплив (Power) стейкхолдера на рішення;
• зацікавленість (Interest) в проєкті.

Дані у розділах Power та Interest дають можливість розподілити всіх учасників проєкту на відповідній шкалі Power vs Interest Grid та розділити умовно на 4 групи:

• Manage Closely — стейкхолдери, що мають найбільший вплив на проєкт та інтерес до нього. З ними бізнес-аналітик працює найбільш щільно.
• Keep Informed — учасники, що майже не впливають на процес, але зацікавлені у результаті. Їх зазвичай просто інформують щодо важливих моментів.
• Keep Satisfied — люди чи організації, які суттєво можуть вплинути на рішення, але у яких мала особиста зацікавленість у ньому. Класичний приклад — фінансовий директор, який вирішує, виділяти гроші на щось чи ні. Стратегія бізнес-аналітика у роботі з такими учасникам полягає у тому, щоб вчасно задовольняти їх запити, які пов’язані з проєктом.
• Monitor — стейкхолдери з мінімальним впливом та інтересом до майбутнього рішення. Їх достатньо просто моніторити та не пропустити момент, коли така людина чи організація змінять своє положення на шкалі Power vs Interest Grid.

Подібне розподілення стейкхолдерів на групи дає можливість бізнес-аналітику побудувати ефективну стратегію комунікування з кожним. Також для полегшення роботи можна використовувати RACI-матрицю — універсальний інструмент розділення обов’язків серед учасників проєкту:

Це таблиця, де бізнес-аналітик прописує зверху стейкхолдерів, а зліва — завдання. Потім навпроти кожного проставляє значення у вигляді однієї з чотирьох літер: R — Responsible (виконавець), A — Accountable (відповідальний), C — Consulted (консультант), I — Informed (той, кого інформують про процес або результат).

Для прикладу візьмемо відділ бухгалтерії. У ньому є керівник, відповідальний за весь документообіг, та кілька його помічників, які виконують завдання по квартальним звітам кожен по своєму напрямку. Очільник відділу іноді звертається до фінансового директора за консультацією та завжди інформує власника компанії щодо поточного стану бізнесу.

RACI-матрицю бізнес-аналітик робить на початку проєкту, погоджуючи з усіма стейкхолдерами їх ролі. Хороша практика — навпроти кожного завдання позначати тільки одну людину, що буде відповідальною за нього. До перелічених інструментів — Stakeholder Register, Power vs Interest Grid та RACI-матриця — корисним буде додати Communication Plan. У цьому документі фахівець з бізнес-аналізу записує:

• канали, частоту та засоби комунікації з кожною зацікавленою особою;
• можливі шляхи ескалації та кроки по їх вирішенню, коли, наприклад, хтось зі стейкхолдерів не може допомогти чи не йде на контакт;
• правила розповсюдження інформації тощо.

Головне у побудові комунікації між бізнес-аналітиком та стейкхолдерами — це чітко визначити, хто яку роль виконує, та рівень впливу і зацікавленості кожного з них у проєкті.

Техніки формування цінностей та цілей проєкту

Одне з основних завдань бізнес-аналітика — правильно визначити бізнес-потреби замовника та на базі цього сформувати пропозицію щодо майбутнього рішення. Чи можливе воно взагалі, та якщо так, яким воно має бути та яку користь принесе в результаті.

Для формування цінностей та цілей проєкту існує багато технік. Почнемо з тих, що допомагають визначити вимоги до рішення та бізнес-потреби — Elicitation Techniques.

Elicitation Techniques

На зображенні — 9 основних технік, які найчастіше використовують бізнес-аналітики на проєктах різного рівня:

1. Interview (інтерв’ю) — по суті це розмова з замовником чи його представниками, ціллю якої є виявлення справжніх бізнес-потреб та приблизного бачення їх рішення.
2. Brainstorming («мозковий штурм») — генерація ідей бізнес-аналітиком та командою фахівців для пошуку вирішення якихось проблем. Можливе підключення замовника до процесу.  
3. Workshop (навчальний чи інформаційний захід) — розширений варіант Brainstorming, коли на додачу до бізнес-аналітика та команди фахівців збирається велика кількість представників з боку замовника, та проводиться сесія з обговорення та затвердження важливих моментів щодо проєкту. Головне в Workshop — врахувати інтереси всіх груп та уникнути конфліктів між ними.
4. Focus Groups (фокус-групи) — це коли сегментуємо потенційних користувачів майбутнього рішення на окремі групи та проводимо опитування. Ця техніка особливо ефективна, коли потрібно протестувати новий продукт на ринку або ж перевірити внутрішнє рішення для компанії замовника, яке стосується різних відділів.
5. Document Analysis (аналіз документів) — пошук та структурування корисної для проєкту інформації, яка може міститься в документах різного типа: внутрішніх стандартах компанії замовника, регулятивних органів тощо. 
6. Observation (спостерігання за роботою) — це коли бізнес-аналітик дивіться, як користувач чи співробітник клієнта працює. Наприклад, потрібно покращити роботу кас в супермаркеті. Щоб краще зрозуміти проблему, Business Analyst дивіться за діями касира та фіксує процес. На базі отриманої інформації роблять висновки щодо вимог до майбутнього рішення.
7. Modelling (моделювання) — створення моделі, як працює бізнес замовника на різних рівнях та у системі в цілому.
8. Data Mining (робота з даними) — пошук, структурування та аналіз будь-яких даних про підприємство чи організацію клієнта, які потрібні для розуміння бізнес-потреб та формулювання пропозиції щодо їх вирішення.
9. Research/Benchmarking (дослідження ринку) — процес аналізу конкурентів та спостереження за аналогічними рішеннями, які вже реалізовані, з ціллю знайти найкращі шляхи для досягнення поставлених цілей на проєкті.

Найкращий результат виходить, коли бізнес-аналітик використовує кожну з технік у системі з іншими. Це не обов’язково мають бути усі й одразу, але для точнішого розуміння роботи бізнесу, які вимоги у нього є та що можна запропонувати, краще застосовувати більшу частину зі списку вище. Загалом же у кожній з технік виявлення проблем в основі лежить Route Cause Analysis.

Route Cause Analysis

Техніка полягає у тому, щоб через 5 питань до однієї проблеми виявити справжню причину. 

Добрий приклад — це історія з монументом Авраама Лінкольна, який став руйнуватися. Зібралась комісія, яка через конкретні питання та відповіді на них змогла дійти до неочікуваної причини цієї проблеми та пошуку рішення.

Route Cause Analysis на прикладі пам’ятника Аврааму Лінкольну:

1. Чому монумент руйнується? — Тому що використовуються агресивні хімікати.
2. Чому потрібні агресивні хімікати? — Тому що навколо багато птахів, які полюбили сідати на монумент, та залишають на ньому сліди після себе.
3. Чому там так багато птахів? — Тому що біля пам’ятника знаходиться велика колонія павуків, які є їжею для них.
4. Чому там так багато павуків? — Тому що навкруги хмари комах, які також вбудовані в цей харчовий ланцюжок.
5. Чому там так багато комах? — Тому що яскраве освітлення монумента вмикається якраз в той час, коли мошки та інша живність найактивніша, і вони всі злітаються на це місце.

У результаті було винайдено просте та недороге рішення — змінити тон освітлення пам’ятника та вмикати його пізніше. Ця історія повчальна, бо показує, що завжди треба шукати корінь проблеми. Часто замовники приходять з симптомами «хвороби», завдання ж бізнес-аналітика — знайти причини та запропонувати рішення. 

Окрім Route Cause Analysis в цьому може допомогти Fishbone diagram.

Fishbone diagram

Ця діаграма також має назву «риб’ячий скелет» за її зовнішній вигляд. Принцип роботи з нею полягає в аналізі кожної з частин «скелета», що потім дасть всебічне уявлення про проблему.

У загальному вигляді «рибу» поділяють на 6 блоків:

1. People (люди);
2. Process (процес);
3. Equipment (обладнання);
4. Management (управління);
5. Environment (середовище);
6. Materials (матеріали).

Тобто є проблема, і ви задаєте питання «Чому вона з’явилась?» з урахуванням перелічених аспектів можливих причин. Наприклад, на підприємстві зробили деталі іншого розміру. Використовуючи підхід Fishbone diagram, ви зможете знайти причину: чи це була зламана машина, невірно настроєний робочий процес, помилка оператора тощо. Fishbone diagram на прикладі підприємства та деталей іншого розміру буде виглядати приблизно так:

Усі ці інструкції по виявленню коренів проблеми потрібні для того, щоб розробити рішення, яке справді принесе користь бізнесу. У допомогу до цього можна використовувати Problem Statement.

Problem Statement

Цей метод рекомендовано застосовувати під час проведення робочих зустрічей, наприклад, інтерв’ю. Базується на 5 питаннях:

1. Яку проблему ми вирішуємо? (Need)
2. Кого вона стосується? (Stakeholder)
3. За яких умов виникає проблема? (Context)
4. Чому її потрібно вирішувати? Які переваги ми очікуємо від рішення? (Value)
5. Як зрозуміти, що проблема вирішена? (Solution)

Відповіді на ці питання конкретизують проблеми та допомагають зрозуміти, чи потрібно взагалі щось з ними робити. Іноді краще просто пам’ятати про деякі складнощі бізнесу та сфокусуватися на інших потребах. Якщо ж бізнес-аналітику після отримання відповідей щось не зрозуміло, він має уточнювати інформацію до останнього. Від цього багато у чому залежить, чи правильно буде обране рішення з точку зору факторів успіху.

Success Factors and KPIs

Оцінювати рішення та його користь для бізнесу можна у кількох напрямків:

• Financial (фінансова складова). Наприклад, після апгрейду обладнання бізнес отримує більше прибутку.
• Customer (клієнти замовника). Припустимо, що після впровадження нової системи CRM зменшився відтік клієнтів.
• Internal Process (внутрішні процеси бізнесу). Це може бути пришвидшення, підвищення якості роботи співробітників тощо.
• Innovation (інновації). Це про те, що допомогло бізнесу вийти на новий рівень. Наприклад, трансформація з офлайн-формату в онлайн допомогло компанії розширити кількість варіантів для збуту продукції чи пропозиції послуг.

На практиці оцінювання будь-якого нововведення за одним критерієм відбувається рідко. Кожен з них майже завжди пов’язаний хоча б ще з одним. Загалом у бізнесу може бути кілька проблем, які мають ще й свої рівні. У цьому випадку добре працює техніка постановки та оцінювання цілей Business Objective Model.

Business Objective Model

Техніка побудови моделі бізнес-целі базуються на співпраці 3-х основних концепцій:

1. Business Problem — щось, що заважає бізнесу досягти поставленої цілі.
2. Business Objective — вимірювальний спосіб, за яким бізнес буде знати, що проблему вирішено.
3. Product Concept — технічне, інноваційне або організаційне рішення, яке команда може створити або зробити, щоб досягти бізнес-цілей та вирішити бізнес-проблеми. 

Працює все за такою схемою:

Побудову Business Objective Model прийнято починати з окреслення бізнес-проблеми. Потім йде перехід на визначення того, як має виглядати результат при вирішенні — типові показники, які б могли збільшитися чи зменшитися. Після цього кроку треба задати питання: «Що зараз заважає досягати подібного?». Є велика вірогідність, що початкова проблема має кілька рівнів, для кожного з которих також потрібно зробити Business Objective.

Цей процес може повторюватися кілька разів. У кінці, після опрацювання усіх бізнес-проблем, до кожної з них ви маєте отримати варіант вирішення — у сукупності все це дає головний Product Concept. Приклад такої моделі:

Іноді замовники звертаються до бізнес-аналітиків вже з баченням готового концепту, але не мають чіткого розуміння проблем. Тоді потрібно проходити весь шлях у зворотному напрямку. Після побудови Business Objective Model можна переходити й до більшого — моделювання того, як буде працювати бізнес.

Моделювання того, як буде працювати компанія

Процес моделювання являє собою побудову різних схем та діаграм на базі даних, які відображають поточний актуальний чи потенційно можливий стан компанії чи . Класичний приклад використання цього методу — це створення моделі роботи компанії на поточний момент та тієї, якою б мала бути в ідеалі, для порівняння між собою. Це допомагає краще зрозуміти цілі компанії та вимоги до рішень, які допоможуть досягти таких результатів.

Є багато типів та підходів до моделювання. Нижче розглянемо ті, що використовують найчастіше. 

Concept Modelling

Ця модель добре підходить компаніям та бізнес-аналітикам, які працюють з великим бізнесом. Базується підхід на концепціях та зв’язках. Концепції — щось, що описує якусь важливу частину бізнесу або категорію: рахунок, договір, послугу, рішення тощо. Зв’язки ж показують, як концепції пов’язані між собою та який вплив мають одна на одну.

Завдяки концептному моделюванню з’являється чітке розуміння, що та від чого залежить у конкретному бізнесі, плюс створюється словник термінів. Це дуже допомагає у подальшому спілкуванні бізнес-аналітика з замовником або іншими фахівцями конкретної ніші.

Business Process Modeling

Моделювання бізнес-процесів — ще один популярний метод. Виконується на декількох рівнях:

Приклад стратегічного моделювання:

На схемі — ідеальний шлях, яким має пройти процес найму кандидатів. Керівництво ставить завдання відділу кадрів знайти фахівця на конкретну позицію. HR оцінює вимоги та публікує вакансію. Далі поступають відгуки від кандидатів. З тими, хто сподобався, проводять інтерв’ю. Найкращому пропонують місце в компанії, і якщо він погоджується, завдання виконується — вакансія закривається.

Приклад операційного моделювання:

На зображенні позначений той же процес найму співробітника, але у поглибленому форматі, коли є варіативність. Наприклад, керівник якогось відділу надсилає вакансію у HR-департамент компанії, де після ознайомлення з її текстом можуть затвердити запит або ж повернути на уточнення якихось моментів. На інших етапах також можливі різні варіанти розвитку подій. 

Приклад технічного моделювання:

Це та ж сама схема найму працівника, але у ще більш поглибленому варіанті, ніж операційна модель. Додаються ще дані та зв’язки, за якими кожен з учасників процесу має щось передавати, зберігати тощо.

Business Use Case Modeling

Business Use Case Modeling — це діаграма, на якій бізнес-аналітик визначає існуючі у бізнесі функції на різних рівнях абстракції. Для прикладу розглянемо відділ бухгалтерії.

Схематичні чоловічки — це ролі (Actors), які існують у конкретній компанії. У даному випаду — це головний бухгалтер, молодший бухгалтер та технічний адміністратор. Головний бухгалтер пов’язаний з усіма функціями, а інші — тільки з деякими. Блоки з текстом (Use Cases) описують, що можуть робити представлені «актори» у рамках своїх ролей, та як взаємодіють між собою.

Така модель — простий спосіб візуально пказати, чим займається конкретний бізнес-юніт, і хто  залучений до кожної бізнес-функції. 

Висновки  

Бізнес-аналіз — це про виявлення справжніх бізнес-потреб та розробку рішень для їх задоволення незалежно від ніші компанії та її рівня. Одне з головних завдань Business Analyst — запропонувати бізнесу те, що дасть йому найбільшу користь. Для цього BA аналізує інформацію від різних стейкхолдерів, використовує різні техніки формування цінностей та цілей, а також моделює роботу компанії замовника. Якщо все зроблено вірно, то існує велика ймовірність, що кінцевий результат на 100% задовольнить важливі потреби бізнесу.