​​📃 Области рисков в бизнес анализе

Говоря про риски, хочется начать с определения термина, предложенного многоуважаемым Карлом Вигерсом. Итак, «риск — это условие, которое может повлечь какие — либо потери или другим способом поставить под угрозу успех проекта. Это условие ещё не породило проблему, и нужно, чтобы оно так и оставалось. 👉🏻 Эти потенциальные проблемы могут оказать неблагоприятное воздействие на стоимость, сроки, технический успех, качество продукта или эффективность работы команды».

Иными словами, риск — это неопределённое условие или событие, которое при наступлении может иметь негативный или позитивный эффект по отношению к бизнес — анализу.

Нас, в первую очередь, естественно, волнует негативный эффект, который могут принести риски. Давайте рассмотрим области рисков в бизнес — анализе.

1️⃣ Решения вместо потребностей
Вероятность того, что заинтересованные лица будут навязывать решения вместо потребностей, что повлечёт за собой разработку ненужного функционала, либо попросту трату времени на прояснение этих самых потребностей.

2️⃣ Scope creep
Неконтролируемое расширение границ решения в силу забывчивости, «передумывания» заказчика, что влечёт за собой увеличение параметров проекта, которое не на руку компании исполнителя.

3️⃣ Ограниченные искусственно сроки на разработку требований
На этапе переговоров, предложили максимально сжатые сроки, дабы проект «выгорел». Как итог - получили риск.

4️⃣ Несогласие со стороны клиента.
Неверно понятые требования — следствие ошибки аналитика.

5️⃣ Неявные, скрытые требования.
Когда есть что — то само собой разумеющееся, а потому не озвучивается и, как следствие, не учитывается аналитиком.

6️⃣ Неверная приоритизация.
Неверная приоритезация может повлечь недовольство со стороны клиента.

7️⃣ Непровалидированные, непроверифицированные требования.
🖍 Непровалидированные требования — требования, которые потенциально не отражают потребностей заинтересованных лиц, а значит потенциально направлены на разработку ненужного функционала.
🖍 Непроверифицированные требования — потенциально некачественные требования: неполные, некорректные и т. д. Отсутствие одного из качеств хорошо написанных требований может привести к ряду проблем.

👉🏻 Само собой, перечисленный в статье список не является избыточным. Риски могут крыться и в других областях, но главное для аналитика - вовремя их идентифицировать и вести работу с ними непрерывно.

​​Транзитные требования. Что это и как писать👇🏻

📍 Существуют случаи, когда предприятия внедряют новые ИТ решения как замену существующим. В тот промежуток времени, когда работают старое и новое решение, организации может потребоваться перемещать информацию между новой и старой системой, проводить обучение новому ПО для заинтересованных сторон и так далее.
Помимо разработки новой системы, разработчикам скорее всего придется имплементировать дополнительные решения, которые бы позволили осуществить и сам переход.

📍 Таким образом, транзитивные требования – это требования, которое должны выполняться в течение перехода организации от старой системы к новой. Срок действия этих требований - время переходного периода между решениями.

📍 В случае, если организация-заказчик планирует внедрить у себя новый ИТ продукт, который предоставляет совершенно новые возможности, а не является улучшением существующей системы, то транзитивные требования не анализируются, поскольку они и не существуют.

📌 В ходе написания транзитивных требований необходимо:

1️⃣ Исследовать существующую систему чтобы понять, что нужно перевести на новое решение.

2️⃣ Определить готовность организации к внедрению новой системы. Может будет необходимо добавить новые возможности в организации в определенных сферах чтобы эксплуатация нового решения стала возможна.

3️⃣ Обозначить информацию и процессы, которые будут необходимы для заинтересованных сторон во время перехода.

4️⃣ Проработать дизайн (в том числе архитектурный), чтобы можно было выявить основные различия между двумя системами.

5️⃣ Оценить текущие данные, чтобы определить, следует ли архивировать их или передать в новое решение. Кроме того, потребуется разработать правила преобразования этой информации и, возможно, определить бизнес-правила.

6️⃣ Предусмотреть варианты управления текущей работой. Возможны варианты: завершение текущих задач в старой системе и инициация всех новых работ в новой системе, приостановка текущих задач до ввода новой системы, преобразование всей работы в период имплементации новой системы и др.

7️⃣ Может потребоваться разработать рекомендации по изменению организационной структуры предприятия или функций персонала, поскольку должностные обязанности могут значительно измениться в результате автоматизации работы.

📌 Полезные инструменты, используемые при сборе транзитивных требований:

👉🏻 Анализ бизнес-правил: могут быть определены дополнительные бизнес-правила для переноса данных или для управления работой, перенесенной из существующего решения.

👉🏻 Диаграммы потоков данных, моделирование процессов и организационное моделирование.

👉🏻 Моделирование данных для оценки их сопоставимости в старом и новом решениях.

​​❗️ Вы системный аналитик? Тогда для вас новости!

👉🏻 IT компания Andersen запускает программу "SA hiring days! Получи Job Offer в 3 шага!"

👉🏻 Какие этапы?

1️⃣ Регистрация
Заполняете форму до конца ноября! После чего с вами свяжется рекрутер и согласует удобное время для прохождения собеседования
Заполнить форму можно тут:
https://hiring.andersenlab.com/

2️⃣ Проверка знаний
Проверка английского, 10 минут (на англоязычные проекты), и собеседование с тех. специалистом, 30-60 минут (вопросы по теории и практике - для определения вашего уровня)

3️⃣ Получение оффера!
Пройдите этап общения с руководителем отдела. После этого вам сообщают результаты: вы получаете оффер либо набор рекомендаций, которые позволят подтянуть слабые места и попробовать снова!

📌 Все подробности о требованиях, этапах, а также Sign-on Bonus можно узнать тут:
https://hiring.andersenlab.com/

​​Друзья, всем привет!👋

Для тех, кто давно хотел начать карьеру в системной аналитике, стартует набор на бесплатный online-курс "System Analysis"😊.

Начало уже в декабре. Два месяца, два раза в неделю(три часа) вечером.

Вся информация в "шапке" регистрационной формы⬇️ https://forms.gle/fo4BrW9yvQVtp3T46

​​Что такое Customer Journey Map и чем она полезна аналитику

👉 Карта путешествия клиента - Customer journey map (CJM) – это описание шагов, которые проходят пользователи при взаимодействии с компанией/продуктом, будь то онлайн-опыт, опыт розничной торговли, получение услуги или любая их комбинация.

Все пункты карты путешествия клиента принято называть точками контакта, они могут быть как онлайн так и оффлайн точками. Примеры онлайн точек: сайт, чат-бот, отзывы в Интернет, статьи, социальная сеть, онлайн-пощник, смс, мобильное приложение и др. Оффлайн точки контакта: консультант в магазине, каталог продукции, доставщик товара, сам товар, бизнес-процесс, реклама в печатных СМИ и др.

👉 В общем виде CJM – это таблица, иногда с элементами графического изображения. Не существуют унифицированного шаблона для CJM, однако можно выделить несколько основных элементов CJM:

1️⃣ Вертикальные столбцы. Имеют название этапов, проходимых клиентом. Например, если речь идет о покупке товара в интернет-магазине, то столбцы имели бы название желание приобрести, поиск, выбор, покупка, доставка, использование, лояльность.

2️⃣ Горизонтальные строки. Отражают характеристики для каждого этапа, т.е. как, когда, где и при каких условиях происходит взаимодействие. Например, для той же покупки в интернет-магазине, это были бы следующие строки: действия покупателя, цели покупателя, точки контакта, полученный опыт (эмоциональная оценка), проблемы, их решения, вовлеченные технические средства и т.д.

❗Особенности написания CJM:

📌 Количество как горизонтальных, так и вертикальных строк можно увеличивать или сокращать в зависимости от потребностей при описании CJM;

📌 Карта может разрабатываться для каждой пользовательской персоны, для персоны приносящей больше прибыли или для наиболее типичной персоны;

📌 Карта пригодна не только для более масштабного описания взаимодействия с продуктом выходящего за рамки посещения сайта (как в случае покупки товара онлайн), так и для описания более точечного взаимодействия (CJM покупки товара на самом сайте).

👉 CJM помогает:

📍систематизировать понимание о взаимодействии клиента с продуктом по разным каналам;
📍спрогнозировать поведение клиента в будущем;
📍при создании положительного UX (user experience) на всем протяжении использования продукта/услуги. Это непосредственно влияет на лояльность клиентов, т.е. приверженность к продукту и готовность вернуться к нему в будущем;
📍выявить и устранить барьеры при переходе от одной точки контакта к другой, тем самым доводя больше потребителей до цели.

​​Приятная новость😉 Ведущий BA из Andersen - Виталий Бирченко - выступит на ANALYST DAYS!

Тринадцатая Международная Конференция, посвященная системному и бизнес анализу, пройдет в Москве 19-20 ноября. Спикер из Andersen поделится своим опытом и выступит 19 ноября с докладом: “BA vs SME. Взаимодействие вместо противостояния”. Разбор темы на реальных Healthcare кейсах будет интересен как аналитикам, так и экспертам.

Желаем Виталию классно выступить💪

👉 Познакомиться со всей программой ANALYST DAY/13 и купить на него билеты можно по ссылке👇
https://analystdays.ru/ru/index

​​Всем замечательного понедельника! 🔆

Сегодня поговорим о системном анализе, а именно об объектах и методах интеграции.☝🏻💻

➡️ Объект интеграции - компонент интегрируемых информационных систем. Объектами интеграции могут выступать:
📍 платформы (ОС Windows, ОС Linux, сервер Intel Xeon и т.п.);
📍 данные (БД, СУБД Oracle Database, Microsoft SQL Server и т.п.);
📍 приложения (сервер приложений Microsoft, Java Runtine Environment, бизнес-логика или интерфейс какого-то приложения и т.п.);
📍 бизнес-процессы (функции сотрудников).

👉🏻 Интеграция платформ - это установление взаимодействия между приложениями, работающими на различных платформах (например, между приложениями на Linux и Windows), а также обеспечение работы приложений, разработанных для одной платформы, на других платформах (например, приложений Windows на платформе Solaris).

➡️ Интеграция платформ осуществляется следующими методами:
📍 Удаленный вызов процедур (remote procedure call RPC, Web-сервисы, REST и др.);
📍 ПО промежуточного слоя (Microsoft.Net, Java Runtime);
📍 Виртуализация - технология программного представления виртуальной версии ИТ-продуктов.

Интеграция данных предполагает совместное использование данных различных систем.

Осуществляется следующими методами:
📍 Универсальный доступ к данным - например, есть две БД, мы интегрируем одну со второй так, что первая получает всю необходимую информацию со второй по средствам запросов на выборку данных;
📍 Хранилища данных – информация с нескольких информационных систем «сливатся» в единое пространство (Data Lake).
Интеграция приложений – это использование функций одних приложений другими приложениями. Осуществляется следующими методами:
📍Интерфейсы прикладного программирования (API) - набор функций, который программист может использовать для доступа к данным и алгоритмам программ;
📍 Обмен сообщениями (Корпоративная сервисная шина) – промежуточный программный стой между приложениями, на котором происходит хранение актуальных данных и их обмен со всеми интегрируемыми приложениями;
📍 Сервис-ориентированная архитектура (SOA) – модульный подход к разработке ПО, базирующийся на использовании сервисов;
📍Интеграция пользовательских интерфейсов – интеграции UI компонентов за счет объединения их внешнего представления, а не логики или схем данных самих приложений.
Интеграция бизнес-процессов - это интеграция приложений, данных и людей, вовлеченных в определенный бизнес-процесс. Здесь речь больше идет о функциях сотрудников, не о программной среде. Например, слияние ролей менеджера по приему заказов с частью функций менеджера по поиску клиентов.

​​⭐️ Напоминаем, что остались последние деньки стать системным аналитиком в компании Andersen и получить хороший sign-on bonus💰💰

Программа "SA hiring days! Получи Job Offer в 3 шага!" заканчивается уже 30ого ноября.

☝🏻 Какие этапы?

1️⃣ Регистрация
Заполняете форму до конца ноября! После чего с вами свяжется рекрутер и согласует удобное время для прохождения собеседования
Заполнить форму можно тут:
https://hiring.andersenlab.com/

2️⃣ Проверка знаний
Проверка английского, 10 минут (на англоязычные проекты), и собеседование с тех. специалистом, 30-60 минут (вопросы по теории и практике - для определения вашего уровня)

3️⃣ Получение оффера!
Пройдите этап общения с руководителем отдела. После этого вам сообщают результаты: вы получаете оффер либо набор рекомендаций, которые позволят подтянуть слабые места и попробовать снова!

📌 Все подробности о требованиях, этапах, а также Sign-on Bonus можно узнать тут:
https://hiring.andersenlab.com/

​​Техники выявления рисков.

👉🏻 Согласно PMBOK (Project Management Body of Knowledge – своду знаний по управлению проектами) риск – это неопределенное событие или условие, которое может как положительно, так и отрицательно повлиять на результаты и цели проекта.

Чтобы минимизировать негативные последствия и увеличить позитивные, так важен процесс управления требованиями. Он начинается с их выявления и сейчас мы расскажем о некоторых из них:

📍 Анализ информации - подвергайте критическому анализу всю документацию, в том числе данные, которые заказчик представляет как “точно верные”. Зачастую там можно найти двусмысленности и неясности, которые позже могут оказать влияние на продукт и стать рисками. Плохие требования - главная причина неудач проекта.

📍 Анализ категорий рисков для выявления типичных рисков - открываем список видов рисков по Вигерсу и(или) BABOK и выбираем типы рисков, наиболее релевантных для нашего проекта.

📍 Анализ предположений и зависимостей - по своей природе они сопряжены с риском. Регулярно просматривайте и проверяйте предположения и зависимости.

📍 Мозговой штурм – собираем все, даже самые глупые и маловероятные идеи рисков на нашем проекте, а затем из полученных вариантов выбираем наиболее релевантные.

📍 Личный опыт – выявленные на прошлых проектах риски часто можно переиспользовать, а их повторная идентификация в будущем происходит проще и быстрее. Но не все риски можно переиспользовать - избегайте эффекта золотого молотка☺️

📍 Мнение и опыт экспертов (внешние эксперты, коллеги, авторитетные источники в интернете и т.д.) - эта техника может сыграть решающее значение, если Вы новичок в домене проекта или только начинаете карьеры. Не стесняйтесь спрашивать Ваших коллег (особенно в Andersen Вам всегда придут на помощь:)

➡️ Помните, что идентификация рисков - постоянный процесс на любой стадии проекта, поэтому список рисков нужно регулярно обновлять и помнить, что их идентификация - только первый шаг в процессе управления рисками. После идентификации рисков мы вносим их в реестр рисков.
📃 Реестр рисков — это инструмент, используемый для отслеживания и мониторинга проектных рисков. Подробнее о нем мы мы расскажем в следующем посте.

​​Продолжаем тему рисков и сегодня поговорим о реестре рисков.

📃 Реестр рисков на проекте. Что это и как создать.

👉🏻 Очевидно, что недостаточно просто знать о существовании рисков. Крайне важно работать с ними постоянно пока идет разработка. Это нужно для того, чтобы вовремя узнать о проблеме и сообщить о ней Заказчику и заинтересованным лицам. Помимо того, что риск может привести к потерям на проекте, он также может поставить под угрозу успех проекта в целом. Поэтому очень важным этапом в работе аналитика становится диагностика рисков.

Основной целью диагностики рисков являются актуализация и систематизация потенциальных рисков, а самое главное, создание и ведение Реестра рисков.
Результатом же диагностики рисков является создание условий для качественного и количественного измерения рисков.
При идентификации риска осуществляется анализ всех возможных факторов, объектов риска. Результатом выявления и анализа рисков является Реестр рисков. Иными словами, Реестр рисков это документ, содержащий все риски проекта с описанием и планами по работе с ними.

👉🏻 Как правило, риск описанный в документе включает следующие аспекты :
📌 Идентификационный номер риска;
Уникальный идентификатор должен быть присвоен каждому риску в момент обнаружения;

📌 Дата открытия риска;
Когда риск был обнаружен.

📌 Дата закрытия риска;
Когда риск был закрыт.

📌 Описание риска;
Обратимся к К. Вигерсу: «...сначала формулируйте причину возникновения риска, вызывающую озабоченность, а затем ее возможный неблагоприятный результат — следствие. Часто люди, говорящие о риске, приводят только условие («клиенты не придут к единому мнению относительно требований к продукту») или только следствие («мы сможем удовлетворить лишь одного из наших основных клиентов»).

📌 Убытки/потери;
В этом разделе следует описать все области проекта, которые буду затронуты при наступлении риска;

📌 Вероятность наступления;

Стандартно используется шкала

➡️ Высокие риски — это риски, для которых характерна высокая частота наступления ущерба.
➡️ Средние риски — это риски, для которых характерна средняя частота нанесения ущерба.
➡️ Низкие риски — это риски, для которых характерна малая вероятность наступления ущерба.

📌 План по работе с риском;
В этот раздел включаем действия, которые будем предпринимать по работе с риском.

📌Автор риска.

Не забывайте, управление рисками-ваш друг!

​​Гендерно-нейтральные местоимения в английском языке при написании требований.

☝🏻 Скорее всего, вы не раз задумывались над вопросом, какие же местоимения использоваться в документации, чтобы избежать неполиткорректных смысловых конструкций. Сегодня поговорим об использовании гендерно нейтральных местоимений или вариантах их замещения при созданий требований.

1️⃣ Вариант первый. "THEY"

С точки зрения современного английского языка приемлемым вариантом будет использование местоимения 👉🏻 “THEY” и его производных, когда мы говорим, например, о пользователе в единственном числе.

Это нам позволяют делать заслуживающие доверия словари английского языка, в которых говорится o “they” следующее:

👉🏻 pronoun (PERSON)
📍 used to refer to a person when you want to avoid saying 'he' or 'she' or when you do not know if the person is male or female (Cambridge dictionary)
📍 used instead of he or she to refer to a person whose sex is not mentioned or not known (Oxford dictionary)
📍 used with a singular antecedent to refer to an unknown or unspecified person
The person who answered the phone said they didn't know where she was
📍 used to refer to a single person whose gender is intentionally not revealed (Merriam-Webster dictionary)

В этом варианте требование будет выглядеть так.
A user enters their login and password to access the system.

Вместе с тем вариант с гендерно-нейтральным местоимением “they” следует использовать, если вы уверены в отсутствии негативного отклика со стороны читателя.

2️⃣ Вариант второй.
Для тех, кто чтит старые устои и не готов к таким радикальным переменам в языке, тоже есть вариант - при упоминании пользователя использовать множественное число.

The users enter their logins and passwords to access the system.

3️⃣ Вариант третий.
Этот вариант является наиболее правильным и вместе с тем требующим иногда чуть больше времени для написания требований.
Он заключается в том, чтобы строить предложение таким образом, чтобы отсутствовала необходимость в использовании местоимений.

A user enters personal login and password to access the system.

☝🏻 И немного истории.
В различные периоды могли использоваться варианты с одновременным перечислением “she” and “he” или “s/he”, или даже “ze”. Но они не прижились, т.к усложняли восприятие.

Как системному аналитику выбрать крутой проект и не прогадать?

В статье автор, системный аналитик зарплатного проекта в Центре развития финансовых технологий Россельхозбанка, рассказала о:
⁃ как senior или middle аналитику удачно выбрать проект;
⁃ какое будущее на рынке системного анализа;
⁃ с какими проблемами сталкиваются системные аналитики на проектах чаще всего.

https://habr.com/ru/company/rshb/blog/592951/

​​Маленькая шпаргалка для тех, кто хочет освежить память📃

📌 Различия между Use Cases и User Stories

👉🏻 User Story — это короткая формулировка намерения, описывающая что-то, что система должна делать для пользователя.
👉🏻 Use Case же больше про поведение, которое вы встроите в продукт, чтобы удовлетворить эти потребности.

📍 Основные различия:

1️⃣ Требования
Use case — это всегда функциональные требования.
User story может содержать требования и к UI, и к UX, и производительности и т.д.

2️⃣ Формат
Use case имеет четкий формат, а в его основном сценарии действия пользователя сменяются системными.
К User story не такие строгие требования. Заголовок должен отображать суть, а критерии приемки можно описывать как угодно, лишь бы это имело смысл для всех заказчиков.

3️⃣ Фокус
При составлении Use case у нас всегда есть последовательность действий и результат, который ожидает пользователь.
User story — это добавление ценности маленькими порциями и демонстрация результата заказчику.

4️⃣ Масштаб
User story— это, в идеале, наименьшая неделимая задача, которая имеет ценность для пользователя.
Use case может описывать как взаимодействие пользователя с конкретной фичей, так и более глобальный бизнес-процесс.

5️⃣ Готовность к разработке
User story — это небольшое техническое задание.
Use case — это описание взаимодействия, которое может служить частью глобальной спецификации и приложением к ТЗ. Но сам по себе он не является исчерпывающей инструкцией для разработчика.

6️⃣ Кто составляет
Поскольку User story — это атрибут гибких методологий, то и составляет её владелец продукта. Да, конечно, бизнес - аналитики часто этим занимаются, но в этом случае они проксируют владельца продукта, выполняя его обязанности.
Use case — это универсальный инструмент, который не привязан к какой-то методологии. Но для его составления требуются определенные навыки, которые относятся к сфере деятельности бизнес - аналитика или системного аналитика.

Начинаем цикл статей по интеграции для системных аналитиков (освежить знания) или тех, кто хочет ими стать😊

Определение интеграции. Общие подходы к интеграции

📌 Интеграция - это установка связей между информационными системами для получения единого информационного пространства и поддержка сквозных бизнес-процессов в рамках этих связей.

☝🏻 Интеграция – это самое узкое место в разработке системы и в большинстве случаев это мера вынужденная, направленная на повышение эффективности бизнес-процессов компании. Вне сомнений легко интегрироваться с крупными продуктами от технологических гигантов таких как Amazon или Microsoft, но если речь идет о мелких системах, особенно устаревших, на которых нет документации, то тут может понадобиться очень много времени на их изучение.

👉🏻 Кроме многочисленных сложностей в интеграции с такими мелкими системами вы можете столкнуться с тем, что в конечном счете интеграция не состоится вовсе. Именно поэтому при оценке проектов закладывается большой объем времени на исследование систем, с которыми будет производится интеграция.

Для того чтобы рассмотреть подходы к интеграции возьмем для примера компанию, включающую в себя следующие информационные компоненты: бухгалтерия, CRM и складская системы.
📃 Далее дадим определение разным подходам к интеграции.

1️⃣ Нет интеграции между системами
Компоненты компании никак не связаны между собой, обмен информацией происходит вручную через флешки, на бумажных носителях или путем отправления файлов работниками отделов друг другу по электронной почте.

2️⃣ Вертикальная интеграция
CRM и складская системы имеют интеграцию с бухгалтерией, в то время как CRM и складская системы между собой никак не связаны. Иными словами можно сказать, что бухгалтерия находится на одном уровне, а CRM и складская система – на втором.
☝🏻 Связь сверху-вниз между уровнями есть, а вот горизонтальных связей внутри отдельного уровня нет.

3️⃣ Интеграция многие ко многим
Каждый информационный компонент компании может обратиться к функционалу любого другого и быть самим использованным любым другим компонентом. Т.е. бухгалтерия, CRM и складская системы связаны между собой напрямую.
☝🏻 Ограничения: все элементы привязаны к функциональности друг, друга. Если поменяем функциональность одной системы, мы потеряем интеграцию.

4️⃣ Горизонтальная интеграция
Подразумевает использование промежуточного (middleware) ПО - сервисной шины.
Основная её функция – создание единого пространства для хранения данных, сервисов, энд-поинтов и т.п., чтобы любое связное с ним приложение могло бы отправить ей и собрать с неё необходимую информацию. Данные на шине всегда находятся в актуальном состоянии. Возвращаясь к нашему примеру, бухгалтерия, CRM и складская системы не обмениваются информацией напрямую, а через посредника – сервисную шину.
❗️ Это самая перспективная и часто используемая интеграция.

Отличная статья о том, как бизнес аналитик (lead BA) сдавал IIBA CBAP сертификацию.
В статье подробно и интересно написано о:
👉🏻 Что такое сертификация IIBA CBAP, и что требуется, чтобы вас к ней допустили
👉🏻 Как проходит экзамен на сертификацию
👉🏻 И, Сергей делится советами, как готовится к этому экзамену.

https://dou.ua/forums/topic/35577/