Інструменти ІТ бізнес-аналітика для аналізу та специфікації Бізнесу/Системи – Частина I

Коли ви здійснюєте пошук в Інтернеті за словами: «інструменти бізнес-аналізу» або «інструменти ІТ бізнес-аналітика», ви отримуєте багато результатів. Це може збити з пантелику або ввести в оману аналітиків, які тільки почали свій прекрасний кар’єрний шлях.

Звісно, кожен проект має різні завдання. Різні завдання вимагають різних інструментів і підходів. Своєю статтею я намагаюся допомогти вам розібратися з найпоширенішими інструментами для аналізу та кращого розуміння бізнес-процесу або ІТ-системи.

В останні роки моєї роботи в якості ІТ спеціаліста я часто використовував нижчезазначені професійні «інструменти» бізнес-аналітика. (Звичайно, методологія ІТ консультанта або ІТ бізнес-аналітика містить десятки інших, але ці були корисними саме для мене).

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

1. Business Process flow diagram (BPMN)
2. Entity-Relationship (ER) model
3. Use case diagram (UML)
4. Data flow diagram (DFD)
5. Decision tree graph

Розберімо кожний детальніше.

Basic Process flow — Процес замовлення товару в інтернет-магазині

1. Business Process flow diagram (BPMN)

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

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

«Діаграма бізнес-процесу — це стандартизоване візуальне представлення процесу, який здійснює компанія для досягнення бажаного результату. Тобто в ній використовуються стандартизовані символи для опису кожного кроку процесу».

Ви можете застосувати цю діаграму для будь-якого процесу. Вона може допомогти вам зрозуміти, як працює процес, та дозволить виявити прогалини, які призводять до зниження ефективності.

Для впровадження ІТ-рішення команда розробників повинна розуміти бізнес-процеси, на які впливає розробка. Як ІТ бізнес-аналітик ви повинні скласти карту й розуміти поточні процеси (як є), а також бути здатними намалювати майбутні процеси на основі вимог (як має бути).

Створення діаграм бізнес-процесів може:

• Підвищити ефективність і продуктивність;
• Зменшити бізнес-витрати;
• Визначити можливості для автоматизації;
• Підвищити прозорість;
• Зменшити надлишковість ;
• Зберегти знання в компанії.

5 основних частин діаграми бізнес-процесів:

1. Мета або результат;
2. Етапи процесу (ключові слова: подія, дія, шлюз, потік);
3. Залучені відділи/люди;
4. Умови або правила переходу до наступного кроку;
5. Необхідні інструменти (пристрої, інструменти, програмне забезпечення тощо).

7 кроків для створення діаграми бізнес-процесу:

1. Запишіть поточну інформацію про процес.
2. Запишіть очікування та бажаний результат.
3. Визначте прогалини та зберіть необхідну інформацію.
4. Визначте події, дії, шлюзи та потоки.
5. Попросіть колег надати зворотній зв’язок і виправте неправильні інтерпретації та недоліки.
6. Розподіліть ролі на етапах процесу.
7. Установіть правила та умови.

Для отримання додаткової інформації про діаграми бізнес-процесів або підпроцесів відвідайте офіційну сторінку.

Ще один крок до повної картини — https://www.flokzu.com

2. Entity-Relationship (ER) model

ER-модель ілюструє логічну структуру бази даних. Вона візуалізує зв’язки між сутностями в базі даних, а іноді і їхніми атрибутами.

Діаграма/модель «сутність-зв’язок» може допомогти задокументувати існуючу структуру бази даних, зібрати вимоги до проектування або виявити можливі проблеми з логікою або розгортанням. Звичайно, ви також можете використовувати її для проектування нової бази даних.

Ви можете намалювати традиційну ER-модель або реляційну схему.

Модель «сутність-зв’язок» може допомогти аналітикам (та іншим членам команди) тому, що:

• Має просту візуалізацію, легку для розуміння.
• Її легко перетворити в модель відносин (relation model).
• Популярна для високорівневого проектування системних баз даних.
• Допомогає членам ІТ-команди зібрати інформацію для фази деталізації.
• Допомагає пояснити, як дані будуть організовані в базі даних.

4 основні частини моделі «сутність-зв’язок»:

1. Сутність — це люди, речі, об’єкти або концепції. Наприклад, клієнт, інвойс, фабрика, продукт тощо.
2. Зв’язок визначає… саме так, зв’язок між двома сутностями.
3. Атрибути: зовнішній вигляд сутності. Може мати одне або декілька значень.
4. Кардинальність показує, скільки екземплярів сутності відносяться до одного екземпляру іншої сутності (один-до-одного, багато-до-одного, багато-до-багатьох). А модальність визначає обов’язковість (повинен), чи необов’язковість (може) зв’язку.

Типи діаграм «сутність-зв’язок» або моделей даних:

1. Концептуальна. Забезпечує високорівневий огляд із найменшою кількістю деталей. Здебільшого використовується бізнес-аналітиками для великих проектів.
2. Логічна. Додає більше деталей до концептуальної моделі.
3. Фізична. Включає кардинальність, показує первинні та зовнішні ключі сутностей і перераховує всі атрибути у вигляді стовпців. Це план бази даних з усіма технічними деталями.

Поради щодо створення ефективної ER-моделі:

1. Ідентифікуйте сутності

– Кожна сутність з’являється на діаграмі один раз

– Кожна має своє унікальне ім’я

2. Визначте типи зв’язків

– Обов’язкові чи необов’язкові? Чи є надмірність? Чи є у вашій моделі зв’язок «відношення до відношення»?

3. Визначте кардинальність.

4. Додайте атрибути до сутностей

ER-diagram— відображення зв’язків Лікар<->Пацієнт

3. Use case diagram (UML)

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

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

Стандартна діаграма варіантів використання визначається уніфікованою мовою моделювання (UML).

Основні частини діаграми варіантів використання:

1. Актор. Актор — людина, пристрій або система, які взаємодіють із певним рішенням. Зазвичай відіграють роль в бізнесі. Актор не є безпосередньо користувачем, це як роль.
2. Варіант використання. Варіант використання — це функція системи. (Автоматизований або ручний процес). Кожен актор має принаймні один пов’язаний варіант використання, але не всі варіанти використання пов’язані з акторами.
3. Комунікаційний зв’язок. Зв’язок між акторами та варіантами використання.
4. Межі системи. Одна або декілька систем включають варіанти використання. Показує, які варіанти використання є частиною певної системи.
5. Зв’язки.

Поради щодо створення ефективної діаграми варіантів використання:

1. Варіанти використання мають різні типи зв’язків. Візуалізація — це рішення бізнес-аналітика. Іноді це допомагає краще зрозуміти залежності, але може призвести до ускладнення візуалізації. Типи зв’язків: розширення, включення, узагальнення.
2. Визначте акторів. Хто запускає або вимикає систему? Хто отримує інформацію від системи? Хто надає інформацію системі? Хто її підтримує? Яка інша система буде використовувати цю систему? Чи відбувається в ній щось автоматично?
3. Визначте варіанти використання. Які очікувані функції? Яка інформація буде зберігатися? Як учасники будуть створювати, читати, змінювати та видаляти цю інформацію? Чи повинна система містити сповіщення, зовнішні зв’язки та звіти?
4. Організовуйте. Завжди організовуйте варіанти використання з точки зору акторів.
5. Зосередьтеся на «Що», а не на «Як».

Діаграма варіантів використання — Прості функції доставки їжі

 

До теми – Базові компетенції бізнес-аналітика – інструменти та технології

4. Data flow diagram (DFD)

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

Існує два типи потоків даних. Логічний потік даних описує потік даних через систему, а фізичний потік даних описує реалізацію логічного потоку даних.

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

Діаграма потоків даних може допомогти визначити фізичні вимоги до побудови системи та встановити нові системні вимоги.

Високорівневу діаграму потоків даних часто називають діаграмою контексту системи.

Переваги діаграми потоків даних:

• Представляє бізнес-інформацію на рівні інформації.
• Допомагає ІТ-команді зрозуміти бізнес, визначити причину нової функції або знайти прогалини в системі. (Детальніше: чорна діра, диво, сіра діра).
• Незалежна від технології.
• Фізична діаграма потоків даних може бути легко перетворена в логічну DFD.

Основні частини діаграми потоків даних:

1. Процес. Ось де відбувається магія. Процес отримує вхідні дані, обробляє їх і створює вихідні дані іншого формату або змісту. Назва процесу — це дієслово, за яким слідує іменник в однині, наприклад, «замовити товар».
2. Потік даних. Потік даних являє собою один або кілька наборів даних. Він показує, які дані рухаються від однієї частини системи до іншої.
3. Сховище даних. Місця, де зберігається інформація. Найчастіше це бази даних, таблиці БД або файлові сховища.
4. Зовнішні сутності. Надають дані системі або отримують їх від неї. Вони показують, як система взаємодіє з рештою світу.

Поради щодо створення ефективної діаграми потоків даних:

1. Визначте основні вхідні та вихідні потоки даних. Що є вхідними даними системи? Хто буде вводити їх у систему? Якими є вихідні дані? Яке їхнє призначення?
2. Побудуйте концептуальну діаграму. Намалюйте визначений вхідний потік даних, принаймні один процес і вихідний потік в одну лінію. З’єднайте їх.
3. Розгорніть її на нижчі рівні. Розбийте процеси на підпроцеси з додатковими вхідними й вихідними потоками.

Діаграма потоку даних 0 рівня — Контекстна діаграма даних

Діаграма потоку даних 1 рівня — Контекстна діаграма процесу

5. Decision tree graph

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

Основна перевага дерева рішень полягає в тому, що його легко дотримуватися і розуміти.

Основні елементи дерева рішень:

1. Кореневий вузол. Відправна точка. Містить питання, на які потрібно відповісти. Кожен кореневий вузол має два або більше листкових вузлів.
2. Листковий вузол. Відгалуження кореневого вузла або іншого листкового вузла. Містить питання, на які потрібно відповісти. Кожен листковий вузол має два або більше листкових вузлів.
3. Гілка. Гілка — це лінія між вузлами. Гілка позначена можливою відповіддю кореневого вузла й веде до листкового вузла (дочірнього) або кінцевого вузла.
4. Кінцевий вузол. Указує на кінцевий результат(и).

Поради щодо створення графа дерева рішень:

1. Почніть із головного рішення. Поставте головне питання.
2. Розробіть можливі результати.
3. З’єднайте їх гілками.

Діаграма дерева рішень

Автор статті: Attila Evanics

Оригінальна стаття – IT Business Analyst tools for Business/System analysis and specification, переклад  Зеленська Софія, ревью – Іван Вільчавський, зображення від Marvin Meyer з сайту Unsplash.