Проєкти бізнес-аналітики вимагають підходу до визначення вимог, заснованого на рішеннях, які користувачі повинні прийняти спираючись на дані.
Основною метою проєктів бізнес-аналітики є розроблення систем програмного забезпечення, які можуть перетворювати великі, дуже складні набори даних у відображення значущої інформації. Ця інформація дозволяє представникам бізнесу приймати тактичні, оперативні чи стратегічні рішення. Керівник може вивчати глобальну інформаційну панель показників своєї команди продажів, щоб вирішити, кого підвищувати (тактичний), які продукти потребують специфічних маркетингових стратегій (оперативний) або які цільові ринки визначити для продуктів (стратегічний).
Для більшості інформаційних систем звіти являють собою лише невелику частину реалізованої функціональності. Однак у проєктах бізнес-аналітики комплексні звіти та графіки, а також можливість користувачам маніпулювати їхнім вмістом є головними функціоналом. Проєкти бізнес-аналітики мають кілька рівнів, для кожного з яких потенційно необхідно визначити вимоги до програмного забезпечення. Ці проєкти можуть мати справу з самими даними, з операціями, які виконуються з цими даними, а також з форматуванням і розповсюдженням даних для їх подальшого використання.
Кінцеві результати процесу розроблення вимог для проєкту бізнес-аналітики подібні до тих, що є для будь-якого іншого проєкту – набір вимог (бізнес-вимоги, вимоги користувача, функціональні і нефункціональні вимоги). Схеми процесів, випадки використання та історії користувачів можуть виявити, що комусь потрібно генерувати результати аналітики. Вимоги до продуктивності (ефективності) описують, як швидко результати потрібні. Однак жодна з них не розкриває складних знань, необхідних для впровадження правильної системи. Таким чином, визначення вимог для проєктів «великих даних» дещо відрізняється від тих, що мають справу з більш типовими бізнес-інформаційними системами.
Ефективна стратегія виявлення вимог полягає у створенні специфікації на основі рішень, які мають прийняти зацікавлені сторони для досягнення своїх бізнес-цілей. Зазначений нижче процес мислення взято з книги Джеймса Тейлора «Використання методу виявлення рішень для управління аналітичними вимогами до проєкту»:
-
Опишіть бізнес-рішення, які зацікавлені сторони будуть приймати, використовуючи результати системи.
-
Поєднайте ці рішення з бізнес-цілями проєкту.
-
Декомпозуйте рішення, з метою виявлення запитань, на які потрібно відповісти, виявлення ієрархії запитань-попередників, на які необхідно відповісти, щоб підсилити основні питання, і визначення ролі, яку відіграє аналітична інформація у отриманні відповідей на ці запитання.
-
Визначте, як можна застосувати аналітику, щоб сприяти прийняттю цих рішень.
Використання цих кроків для обмірковування найважливіших рішень створює основу та стратегію для розроблення вимог до проєктів «великих даних» (big data). На рисунку 1 відображено огляд процесу визначення вимог до аналітичного проєкту.
Рисунок 1. Процес розроблення вимог до проєктів бізнес-аналітики
Пріоритизуйте розробницьку роботу виходячи з того, які рішення є найважливішими для вирішення. Для більшості типів проєктів функції можуть бути пріоритезовані, враховуючи їх вплив на досягнення бізнес-цілей. Такий спосіб мислення є актуальним і для аналітичних проєктів, за винятком того, що немає окремих «функцій», які слід пріоритезувати.
Натомість необхідно використовувати бізнес-цілі, щоб визначити пріоритетність бізнес-рішень, які забезпечить прийняте проєктне рішення, виходячи з того, наскільки вони (бізнес-рішення) сприяють досягненню цілей. Зокрема, рішення про те, які продукти продавати, матиме більший вплив на збільшення доходу, ніж прийняття рішень щодо часу відпустки команди продажів. Таким чином, ви, ймовірно, запровадите аналітику та звіти, щоб визначити, які продукти продавати, перш ніж запроваджувати інші можливості.
Бізнес-аналітик повинен формулювати рішення так само однозначно, як і вимоги. Прикладом гарно сформульованого рішення є наступне: «Віце-президент із маркетингу повинен щоквартально вирішувати, скільки маркетингового бюджету виділяти кожному регіону на основі поточних і цільових продажів у регіонах». Як і під час визначення вимог до інших проєктів програмного забезпечення, важливо розуміти основні потреби зацікавлених сторін, а не просто зосереджуватися на представленому рішенні.
Якщо зацікавлені сторони вимагають певних даних або звітів, ставте запитання на зразок «Навіщо вам ця інформація?» і «Як одержувач використовуватиме цей звіт?». Потім попрацюйте у зворотному напрямку, щоб визначити пов’язані бізнес-цілі та відповідні рішення. Цілком вірогідно, що Ви можете виявити, що деякі звіти, запит на які був зроблений спочатку, не допоможуть зацікавленим сторонам прийняти ці ключові рішення.
Виявивши найважливіші рішення, ви можете визначити, як користувачі використовуватимуть інформацію для прийняття рішень. Вам потрібно визначити, яким чином вони хочуть отримувати інформацію, як вона буде відформатована та як вони хочуть нею маніпулювати. Відповіді на ці запитання приведуть до багатьох функціональних вимог.
Якщо системи автоматизують прийняття рішень, вам також необхідно визначити вимоги до зовнішніх інтерфейсів для доставки інформації. Обов’язково вивчіть вимоги до атрибутів якості, а також пов’язану з рішенням функціональність. Наприклад, можуть існувати вимоги безпеки, які обмежують, які класи користувачів можуть створювати певні аналізи або звіти.
Визначивши те, як буде використовуватися інформація, необхідно визначити вимоги до даних. Вам потрібно зазначити, які складові даних необхідні для введення в запитуваний аналіз. Поки дані мають певну структуру, діаграми зв’язків сутностей та словники даних можуть допомогти розкрити та представити вимоги до даних.
Вимоги до даних також можуть включати: джерела даних; оброблення вхідних даних у стандартні формати та структури; механізми зберігання, управління та вилучення; і механізми презентації, такі як інформаційні панелі. Дані в системі можуть бути не просто виведені в оригінальному форматі: цілком може бути проведений аналіз даних, який перетворює їх для використання.
Одним із складних аспектів багатьох проєктів бізнес-аналітики є те, що особа, яка приймає рішення, може не знати наперед, що саме вона шукає в даних. (Я згадую стару абревіатуру проєкту програмного забезпечення IKIWISI: I’ll know it when I see it «Я дізнаюся це, коли побачу»). Особа, яка приймає рішення може захотіти, щоб певні об’єкти даних і атрибути відображалися в інструментах, які дозволяють йому досліджувати, запускаючи різні запити до даних у форматі «що-якщо ». Він буквально не знає, чого він не знає, але він сподівається, що, вивчаючи дані, він знайде щось корисне, щоб почати діяти.
Ось чому важливо почати з розуміння того, які рішення намагаються прийняти зацікавлені сторони. Навіть якщо зацікавлена сторона ще не знає точно, що вона шукає в даних, вона повинна мати можливість визначити тип проблеми, яку вона намагається вирішити. Досвідчений БА може допомогти скерувати мислення користувача через цей процес, щоб прояснити цілі, питання та рішення, а отже, виявити функціональні вимоги системи.
Будучи БА на проєкті бізнес-аналітики, вам потрібно працювати із зацікавленими сторонами проєкту, щоб зрозуміти їхні процеси прийняття рішень. Використовуйте ці рішення, щоб виявити вимоги, які відкриють доступ до необхідних даних, щоб визначити типи аналізу, які потрібно виконати, і щоб визначити спосіб представлення даних. Ви повинні розуміти, яких результатів зацікавлені сторони очікують від аналітичного рішення, які рішення вони сподіваються, що дані допоможуть їм прийняти, і як вони хочуть динамічно змінювати аналіз або їхню візуалізацію. Шукайте можливості, щоб допомогти користувачам досягти ще більшого успіху, пропонуючи рішення, про які вони навіть не уявляли. Це один із багатьох способів, за допомогою яких бізнес-аналітик додає цінність у проєкт.
Оригінальна стаття – Using Decisions to Derive Requirements for Business Analytics Projects, переклад – Олена Грищенко, ревью – Олександра Серебрянська (Business Analysis Community Kyiv), оригінальне фото від Stephen Phillips — Hostreviews.co.uk.