B: Business Analyst

Business Analyst – who is that?

Definition of business analyst

Hello there! Word of the day – Business Analyst. Let’s finally talk about the people who perform the activities and tasks we discuss in this blog. According to IIBA® and BABOK® v3, a business analyst is any person who performs business analysis, no matter their job title or organizational role. Business analysts are responsible for discovering, analyzing, and transforming information from different sources into requirements for future solutions. The sources may vary, but usually, those are processes, documentation, stakeholders, and tools. Along with that, the business analyst is responsible for eliciting the actual needs of stakeholders, which involves investigating and clarifying their expressed desires to determine root issues and causes.

The progress of business analysts depends on combining education, hard and soft skills, and business domain knowledge which help drive better business outcomes across all industries. This leads to the understanding that there are a lot of roles that directly are business analysis roles and many of those are supported by business analysis. To understand how many professions within IT and not only are affected by subject area, I would like you to take a look at the sample of critical roles supported by business analysis provided by IIBA®.

You may see now that are so many of them that it’s impossible to say that a business analyst is a simple one-dimension role whose responsibility is to just document requirements. It’s ultimately the opposite, as we are a part of most everything happening within enterprises, one way or another. As soon as there are a lot of business analysis professions, I would like to take a closer look at a few of them. I picked the types of analysts most commonly represented in IT, along with their logical evolution from one to another.

Business analyst types

Business-focused roles

• Business Requirements Analyst. This role is tasked with helping the business to meet its objectives and goals. They understand how work is being conducted and, through analysis, determine solutions to the issues. They have in-depth business knowledge typically related to a department (e.g., customer service, manufacturing);
• Business Process Analyst. They specialize in bringing change to organizations through analyzing, designing, and implementing the business processes that keep organizations running and managing changes to those processes. Business process analysts have deep competencies in identifying the current state of operations, eliciting valuable and harmful attributes of them, documenting models of the processes, and facilitating stakeholder groups to a consensus regarding new business process designs;
• Business Systems Analyst. This type utilizes broad IT and in-depth business knowledge to implement IT solutions that address business needs. They will identify, develop and implement effective technology solutions that address business needs.

IT analyst roles

• Product owner. That is a specific role from the Scrum framework. Product owners are accountable for maximizing the product’s value resulting from the Scrum Team’s work. How this is done may vary widely across organizations, Scrum Teams, and individuals. Most importantly, the Product Owner is responsible for developing and explicitly communicating the Product Goal. But most of the time, the Product Owner works on creating and maintaining the product backlog by eliciting information from stakeholders to create epics and user stories and define acceptance criteria;
• Requirements Engineer (IT Business Analyst). In collaboration with stakeholders, a person elicits, documents, validates, and manages requirements. In most cases, requirements engineering is a role, not a job title. Their goal is to transform needs into requirements for IT solutions, manage and detail requirements during the development process, and work with DEV/QA teams;
• Systems Analyst. This role performs business analysis tasks through specialization in understanding the business usage of information technology (IT) and helping technology add value to the business. They know and are comfortable with various technical architectures and platforms and understand IT capabilities and which applications in an organization deliver different capabilities;
• Business Data Analyst (or Decision Analyst). They utilize technologies, methods, and practices for continuous iterative exploration and investigation of past business performance to gain insight and drive business planning. The decision analyst will help the business to develop new insights and understand business performance based on data and statistical methods.

Enterprise level roles

• Enterprise Architect. This role aligns IT infrastructure with IT and business strategy, supporting the goals and objectives and successfully implementing change. They develop formal standards, manage the enterprise architecture processes and guide the architectural team, CIO, CEO, and Business Architect;
•  Business Architect. Architects work to create and maintain business architecture. They leverage enterprise capabilities and efficient usage of process, technology, data, and people and align these capabilities to the business strategy.

Business Analyst responsibilities

Not depending on what type of analyst we are talking about, they all perform the same activities and tasks, which also means they share the same responsibilities, as described in detail in BABOK® v3. But since one of our subscribers asked for more, I would like to add a few comments on some areas touched by business analysts based on experience:

• Requirements life cycle management. That is the complete and sole responsibility of a person who performs business analysis, period. If a PM/QA is helping with this – be my guest, but not as a first chair;
• Elicitation and Collaboration. Same as for above;
• Communication. There is a lot of tension between BA and PM in this area. PMs tend to bound all communication with clients and, sometimes, the team on themselves, while BA becomes the source of information for such communication. In some cases, when BA is inexperienced or PM has a lot of BA experience, this approach could be tolerated for some time. But in the end, those who perform BA activities should be the primary communication person;
• Decision-making. There are many decisions through the initiative when it’s unclear who should call the shots – PM, BA, QA, Developer, or another team member. Usually, that is a question of design, specifics of some feature implementation, or scope changes. After years of experience, it became clear that there would not be a silver bullet, and there would be cases when it’s a grey area. But, to fix most problems, there is enough to have a RACI matrix that defines responsibilities for such things, for there is a standard template you can modify for each project. E.g., design alterations can be approved by any of PM/BA/QA, scope changes – by PM/BA or client only (depending on the level of trust);
• Estimation. Of course, BA is responsible for its task estimation. When we talk about other estimations, BA is a precious consultant whose comments on the suggested approach and supposed effort might change the estimation completely;
• Management. Duh, it’s PM’s area; what’s to discuss? Well, yeah, but I usually see problems here. The situation is that some activities, like scope planning or estimation, depend on requirements. While PM’s plan is based on estimation and available resources, usually, they do not possess information about dependencies and do not have the big picture about the product. That’s why BAs usually feel more critical within planning. Because of this, it is essential to listen to BA and help BA understand that while they are valuable consultants, PMs are accountable for this task.

That is your first visit to Passionate BA?

If you just started reading my blog, I have to indicate that you can find many articles on a blog page. You will find my digests, glossary definition reviews, and much more! Enjoy!

Бізнес-аналітик – хто це?

Визначення бізнес-аналітика

Привіт! Слово дня – бізнес-аналітик. Давайте нарешті поговоримо про людей, які працюють у професії, яку ми обговорюємо в цьому блозі. Відповідно до IIBA® та BABOK® v3, бізнес-аналітик — це будь-яка особа, яка проводить бізнес-аналіз, незалежно від посади чи ролі в організації. Бізнес-аналітики відповідають за виявлення, аналіз і перетворення інформації з різних джерел у вимоги для майбутніх рішень. Джерела можуть бути різними, але зазвичай це процеси, документація, зацікавлені сторони та інструменти. Крім того, бізнес-аналітик відповідає за виявлення фактичних потреб зацікавлених сторін, що передбачає дослідження та з’ясування висловлених бажань для визначення основних проблем і причин.

Прогрес бізнес-аналітиків залежить від поєднання освіти, хард та софт навичок, а також знань у сфері бізнесу, які допомагають досягати кращих бізнес-результатів у всіх галузях. Це призводить до розуміння того, що існує багато ролей, які безпосередньо є ролями бізнес-аналізу, і багато з них підтримуються бізнес-аналізом. Щоб зрозуміти, наскільки багато професій в ІТ-сфері й не тільки, спирається на бізнес-аналіз, я хотів би, щоб ви поглянули на зразок критичних ролей, які підтримуються бізнес-аналізом, наданим IIBA®.

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

Типи бізнес-аналітиків

Ролі, орієнтовані на бізнес

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

Ролі ІТ-аналітиків

• Продукт овнер. Це особлива роль у Scrum-фреймворк. Продукт овнери несуть відповідальність за максимізацію цінності продукту в результаті роботи Scrum-команди. Те, як це робиться, може сильно відрізнятися в різних організаціях, Scrum-командах і окремих осібах. Найважливіше те, що продакт несе відповідальність за розробку та чітке повідомлення про ціль продукту. Але більшу частину часу продакт працює над створенням і підтримкою беклогу продукту, збираючи інформацію від зацікавлених сторін для створення епіків та користуваціькиї історий і визначення критеріїв прийняття;
• Інженер з вимог (ІТ бізнес-аналітик). У співпраці із зацікавленими сторонами ця людина виявляє, документує, підтверджує та керує вимогами. У більшості випадків розробка вимог — це роль, а не посада. Їхня мета — трансформувати потреби у вимоги до ІТ-рішень, керувати та деталізувати вимоги під час процесу розробки та працювати з командами DEV/QA;
• Системний аналітик. Ця роль виконує завдання бізнес-аналізу через спеціалізацію в розумінні використання інформаційних технологій (ІТ) у бізнесі та допомагає технологіям підвищити вартість бізнесу. Вони знають різні технічні архітектури та платформи та розуміють їх, розуміють ІТ-можливості та програми в організації, які надають різні можливості;
• Аналітик бізнес-даних (або аналітик рішень). Вони використовують технології, методи та практики для безперервного ітеративного дослідження та дослідження минулих показників бізнесу, щоб отримати розуміння та стимулювати бізнес-планування. Аналітик рішень допоможе компанії отримати нові ідеї та зрозуміти ефективність бізнесу на основі даних і статистичних методів.

Ролі на рівні підприємства

• Архітектор підприємства. Ця роль узгоджує ІТ-інфраструктуру з ІТ-стратегією та бізнес-стратегією, підтримуючи цілі та завдання та успішно впроваджуючи зміни. Вони розробляють офіційні стандарти, керують процесами архітектури підприємства та керують командою архітекторів, CIO, CEO та бізнес-архітектором;
• Архітектор бізнесу. Архітектори працюють над створенням і підтримкою бізнес-архітектури. Вони використовують можливості підприємства та ефективне використання процесів, технологій, даних і людей і узгоджують ці можливості з бізнес-стратегією.

Обов’язки бізнес-аналітика

Незалежно від того, про який тип аналітика ми говоримо, усі вони виконують однакові дії та завдання, що також означає, що вони поділяють однакові обов’язки, як детально описано в BABOK® v3. Але оскільки один із наших підписників попросили більше інйормації, я хотів би додати кілька коментарів щодо деяких питань, яких я торкнувся на досвіді:

• Управління життєвим циклом вимог. Це повна та виключна відповідальність особи, яка проводить бізнес-аналіз, крапка. Якщо PM/QA допомагає з цим – раді допомозі, але не як головна особа в цьому завданні;
• Виявлення та співпраця. Те саме, що й вище;
• Коммунікація. У цій сфері існує напруга між BA та PM. Менеджери проектів мають тенденцію зв’язувати всю комунікацію з клієнтами, а іноді й командою, на собі, тоді як BA стає джерелом інформації для такого спілкування. У деяких випадках, коли BA недосвідчений або PM має великий досвід BA, такий підхід можна використовувати протягом деякого часу. Але врешті-решт ті, хто виконує діяльність BA, повинні бути основними комунікаторами;
• Прийняття рішень. Є багато рішень в ході виконання ініціативи, коли незрозуміло, хто має вирішувати – PM, BA, QA, Developer чи інший член команди. Зазвичай це питання дизайну, особливостей реалізації якоїсь функції або зміни обсягу продукту. Після багаторічного досвіду стало зрозуміло, що срібної кулі не буде, і будуть випадки, коли це сіра зона. Але для вирішення більшості проблем достатньо мати матрицю RACI, яка визначає відповідальність за такі речі, оскільки існує стандартний шаблон, який можна змінити для кожного проекту. Наприклад, зміни дизайну можуть бути затверджені будь-яким з PM/BA/QA, зміни обсягу – тільки PM/BA або клієнтом (залежно від рівня довіри);
• Оцінка. Звичайно, BA несе відповідальність за оцінку своєї роботи. Разом із тим, коли ми говоримо про інші оцінки, BA є цінним консультантом, чиї коментарі щодо запропонованого підходу та передбачуваних зусиль можуть повністю змінити оцінку;
• Менеджмент. Начебто все зрозуміло: це зона PM, що обговорювати? Так, але зазвичай я бачу тут проблеми. Ситуація полягає в тому, що деякі дії, як-от планування обсягу або оцінка, залежать від вимог. Планування, що виконує PM, базується на оцінці та наявних ресурсах, на голих фактах. При цьому, не рідко PM не володіють інформацією про залежності між модулями чи вимогами, та не мають загальної картини продукту. Ось чому BA зазвичай відчувають себе більш критично важливими під час планування. Через це дуже важливо вислухати BA. При цьому також важливо допомогти BA зрозуміти, що, хоча вони є цінними консультантами, керівники менеджерів відповідають за це завдання та мають останнє слово.

Це ваш перший візит до Passionate BA?

Якщо ви тільки починаєте читати мій блог, то просто мушу звернути вашу увагу на свої попередні статті, в т.ч. BA-дайджести, де зібрані різноманітні корисні матеріали!