Russian IT Business Analysis #2

NALY A SS

T

IAN IT B SS

S RU I S

R

B

A

Russian Information Technologies BUSINESS ANALYSIS

USINE

Сущность [02] 2014 Бизнес Анализа

ГЕОРГИЙ САВЕЛЬЕВ ИВАН ШАМАЕВ АЛЕКСАНДР ДУБЛИН ВЛАДИМИР КОВЕШНИКОВ СЕРГЕЙ ПЮННИНЕН НАТАЛЬЯ ЖЕЛНОВА АЛЕКСАНДР БЕЛИН

Moscow, Russia

NALY A SS

T

IAN IT B SS

S RU I S

R

B

A

USINE ANALY

T

SS

RA

SS

IAN ITB

USINE

2

S RU

SI

B

RUSSIAN IT BUSINESS ANALYSIS

Russian Information Technologies BUSINESS ANALYSIS

When once you have tasted flight, you will forever walk the earth with your eyes turned skyward, for there you have been, and there you will always long to return.

Leonardo da Vinci

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

3

Авторы экспертных мнений Георгий Савельев

Сертифицированный бизнес-аналитик (CBAP), член команды авторов BABOK v.3. Один из ключевых создателей системы моделирования предприятий Enterprise Optimizer®. Член инициативной группы по созданию Российского Отделения Международного Института Бизнес Анализа (IIBA). georgysaveliev@gmail.com

Иван Шамаев

В 2012 году с отличием окончил МГТУ им. Баумана,. Участвовал в проектах по автоматизации управления недвижимостью, автоматизации заказного производства, калькуляции маржинальной прибыли. В текущее время работает системным аналитиком в Альфастраховании в Управлении финансовых систем. Работает с системами Hyperion Planning, QlikView. ivan.shamaev@gmail.com

Александр Дублин

С 1993 года по 2001 год работал бизнес-аналитиком на рынке ценных бумаг в различных компаниях. С 2001 года работал в качестве бизнес-аналитика, консультанта, менеджера проекта внедрения ERP системы (Axapta, SAP). Автор ДБС-методики расчёта экономической выгоды внедрения ИТ-Решения. С 2009 года работает как бизнес-аналитик - фрилансер. adublin@mail.ru

ANALY SS

T

IAN IT B SS

RA

B

USINE

4

S RU SI

RUSSIAN IT BUSINESS ANALYSIS

Владимир Ковешников

Руководитель направления и консультант по банковским бизнес процессам учебного центра Luxoft Training. Ранее руководил отделом процессов и технологий аппарата Среднерусского Банка Сбербанка России. Работает в ИТ с 2004 года, на финансовых рынках с 2007 года. С января 2011 года проводит тренинги по инвестиционному банкингу и финансовым рынкам для специалистов ИТ VKoveshnikov@luxoft.com

Сергей Пюннинен

Бизнес-аналитик, менеджер проектов. Опыт работы в области IT - более 10 лет. Сфера профессиональных интересов: реинжиниринг бизнес-процессов, автоматизация производственных процессов, системная интеграция. pyunninen@gmail.com

Наталья Желнова

Математик, дипломированный переводчик (английский и немецкий языки) и профессиональный редактор технической литературы. Стаж в IT - более 20 лет. В настоящее время - руководитель направления в компании «Сервионика» (группа компаний «Ай-Теко») и преподаватель курса «Анализ требований» в МФТИ. nzhelnova@teamcit.ru

Александр Белин Бизнес Аналитик.

Член инициативной группы по созданию Российского Отделения Международного Института Бизнес Анализа (IIBA).

russianitba@gmail.com

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

5

СОДЕРЖАНИЕ

ВВЕДЕНИЕ ГЕОРГИЙ САВЕЛЬЕВ

Сущность Бизнес Анализа ИВАН ШАМАЕВ

20

АЛЕКСАНДР ДУБЛИН

38

ВЛАДИМИР КОВЕШНИКОВ

48

СЕРГЕЙ ПЮННИНЕН

56

Типы требований и методики сбора требований в разрезе различных стандартов Правила проведения интервью при обследовании бизнес процессов Правильный подход к анализу бизнес процессов в банке Планирование содержания первичного интервью с заказчиком

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

6

8

RUSSIAN IT BUSINESS ANALYSIS

НАТАЛЬЯ ЖЕЛНОВА

62

АЛЕКСАНДР БЕЛИН

78

Business Process Modeling Notation Опыт использования объектно ориентированного подхода в бизнес анализе, или говорим с разработчиками на одном языке

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

7

Сущность Бизнес Анализа Георгий Савельев

Сущность бизнес-анализа

Это вторая статья цикла, посвященного объяснению профессии «Бизнес-анализ». В предыдущей статье рассматривались слои компетенций и уровни профессиональной зрелости бизнес-аналитика. Теперь мы поговорим о том, в чем состоит сущность его работы и как она соотносится с Моделью основных понятий бизнес-анализа. Мы также вернемся к обсуждению ключевых компетенций бизнес-аналитика с точки зрения самых важных его задач.

Т

Георгий Савельев CBAP

ретья версия Руководства по своду знаний бизнес-анализа (BABOK Guide v3), представленная на публичное обозрение, определяет Бизнес-анализ как «Практика обеспечения возможностей изменения предприятия путем определения потребностей и рекомендации решений, приносящих пользу участникам». Это определение отражает взаимосвязь между шестью элементами Модели основных понятий бизнес-анализа (BACCM™ – Business Analysis Core Concept Model), которая является одним из главных нововведений BABOK Guide v3.

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

9

Георгий Савельев Согласно BABOK, шесть основных понятий бизнес-анализа – это Изменения (Change), Контексты (Contexts), Участники (Stakeholders), Потребности (Needs) участников, Решения (Solutions) и Польза (Value). Все другие понятия, с которыми имеет дело бизнес-аналитик, такие как Проблемы, Требования, Ограничения, Предположения, Планы и Проекты, логически вытекают из этих шести. Модель основных понятий – это смысловой каркас бизнес-анализа, отражающий понимание того, что представляет собой бизнес-анализ независимо от его перспективы, отрасли, методологии или организационного уровня. Шесть ключевых терминов Модели имеют единое значение для всех бизнес-аналитиков. Они призваны помочь в обсуждении бизнес-анализа и его применения как в среде бизнес-аналитиков, так и за ее пределами. Впрочем, сама по себе Модель основных понятий бизнес-анализа ничего не говорит об особенностях работы бизнес-аналитика. С равным успехом она применима к управлению проектами, проектированию архитектуры предприятия, стратегическому планированию. Поэтому далее BABOK поясняет: «В конечном счете Бизнес-анализ помогает организациям понять потребности предприятия и причины нужных изменений, разработать возможные решения и объяснить пользу, которую эти решения могут принести». В этом предложении есть два слова, которые отражают самую суть деятельности бизнес-аналитика. Какие? Прежде чем ответить на этот вопрос, обсудим что такое вообще человеческая деятельность.

Понятие деятельности

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

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

10

Предмет деятельности, как правило, не является уникальным для конкретного вида деятельности. Например, нефть выступает в качестве общего предмета для множества деятельностей по ее разведыванию, добыче, хранению, транспортировке, продаже и переработке. Отличия между разными видами деятельности отражаются в их назначении и результатах. Так назначение деятельности по транспортировке нефти состоит в обеспечении возможности ее использования в местах, отдаленных от мест ее добычи. Соответственно, результатом транспортировки является наличие нефти в нужном месте. Тогда как назначение деятельности по переработке нефти состоит в получеRUSSIAN IT BUSINESS ANALYSIS

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

Назначение бизнес-анализа

Назначение любого вида анализа, как деятельности, состоит в выявлении и устранении неопределенности. Там, где всем все известно и понятно, аналитик не нужен. Это определение применимо к любому виду анализа – финансовый, химический, маркетинговый, статистический, психологический. Отличия между разными видами анализа определяются объектами анализа. Специфика бизнес-анализа состоит в том, что его объектами являются организационные и информационные системы, а особенно – их создание и изменение. Специфика бизнес-анализа состоит в том, что его объектами являются организационные и информационные системы, а особенно – проекты по их созданию и изменению. На начальных этапах большинства проектов присутствует значительная степень неопределенности относительно планируемых действий и их возможных последствий. Для устранения этой неопределенности нужны понятные всем участникам ответы на правильно поставленные вопросы, основанные на достоверных фактах и логических рассуждениях. Это позволяет более осмысленно подходить к принятию решений и управлению рисками, и повышает шансы на успех проекта. Насколько необходимы изменения? Что именно нужно изменить? Кого и как эти изменения затронут? Кому и какую пользу принесут? Какие новые возможности необходимы организации? Кто и как будет ими пользоваться? Какие решения обеспечивают нужные возможности и насколько они применимы в контексте данной организации? Задача бизнес-аналитика – найти ответы на эти и другие подобные вопросы, донести их до ключевых участников, и убедиться в их согласии с полученной информацией. Однако, как писал Марк Твен: «Проблемы создаёт не то, чего мы не знаем, а известное нам наверняка, которое на деле таковым не является». Причина провала многих проектов – ложная уверенность в том, что «всем все известно и понятно». Обычно такая уверенность основана на неподкрепленных убедительными доказательствами субъективных мнениях ключевых участников. Ошибочность этих мнений неизбежно обнаруживается в ходе проекта, но зачастую слишком поздно чтобы что-то исправить. Поэтому способность бизнес-аналитика выявлять зоны неопределенности может играть даже более важную роль, чем мастерство их устранения. Большинство людей не испытывают затруднений с нахождением нужной информации, когда им точно известно какой информации не хватает и для чего именно. Кроме того, полная определенность не только невозможна, но и не нужна для того, чтобы действовать эффективно. Множество дел люди даже на стали бы начинать, если бы заранее знали во что им это обойдется… и мы до сих пор жили бы в пещерах. Однако некоторые вещи мы, все-таки, предпочли бы знать заранее. Искусство определять те вопросы, на которые стоит искать ответ, основывается на опыте, интуиции и понимании особенностей того бизнеса, с которым мы имеем дело. Итак, назначение бизнес-анализа состоит в выявлении и устранении неопределенности относительно организационных изменений, которые и являются его основным предметом. Что еще является предметом бизнес-анализа?

Предмет бизнес-анализа

Модель основных понятий (BACCM), о которой мы говорили ранее, определяет предмет бизнес-анализа. Это – решения, обеспечивающие изменения нужные для удовлетворения потребностей, контексты в которых эти изменения осуществляются, участники этих изменений, и ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

11

Георгий Савельев польза, которую участники получают от изменений. Задача бизнес-аналитика – устранение неопределенности относительно участников изменений, их потребностей, возможных решений и ожидаемой пользы.

Расширенный набор объектов бизнес-анализа следует из основного и включает в себя: организации, процессы, технологии, правила, инструменты, проблемы, причины и последствия, цели, возможности, риски, проекты, планы, ресурсы, издержки, выгоды, требования, предположения, ограничения, приоритеты, зависимости. Важно понимать, что требования также являются предметом бизнес-анализа, а не его продуктом. Требования – это форма представления объективных потребностей, существующих независимо от присутствия бизнес-аналитика. Бизнес-аналитик не создает их, а выясняет и формулирует. Результатом его работы является правильное и пригодное для использования описание требований к решениям, а также факторов, влияющих на возможность или целесообразность их реализации.

Результаты бизнес-анализа

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

12

Как показывает предыдущая диаграмма, результатами бизнес-анализа являются определения, объяснения, объяснительные модели, оценки, прогнозы, обоснования и рекомендации, а также достигнутые относительно них договоренности между участниками проекта. Хорошо сформулированные вопросы, очерчивающие области неопределенности и позволяющие получить информацию RUSSIAN IT BUSINESS ANALYSIS

Сущность бизнес-анализа нужную для их устранения, также являются ценным продуктом работы бизнес-аналитика. Все результаты бизнес-анализа должны документироваться. Любой бизнес-аналитик знает, как быстро перестает казаться очевидным то, что мы пытаемся изложить в письменном виде. Документирование – это и проверка полноценности нашего понимания, и способ поделиться этим пониманием с другими. Сам аналитик редко является конечным потребителем собственных продуктов. Поэтому в бизнес-анализе результат, не зафиксированный в письменном виде – это отсутствующий результат. Обычно результаты бизнес-анализа представляются в виде набора типовых документов, таких как «Концепция», «Бизнес-требования», «Функциональная спецификация», «Технико-экономическое обоснование». В результате часто складывается ошибочное мнение, что именно эти документы и являются главными продуктами работы бизнес-аналитика, а их создание – его цель. На самом деле важно понимать, что документы и диаграммы – это не сами результаты, а лишь форма их представления. Главными же результатами являются объяснительные модели, о которых пойдет речь далее. Одно из наиболее заметных отличий третьей версии BABOK Guide от предыдущих состоит в том, что в ней никакие конкретные документы не упоминаются ни в качестве исходных данных задач бизнес-анализа, ни в качестве их результатов. Все результаты бизнес-анализа описываются в обобщенном виде, не накладывающем ненужных ограничений на форму их представления. Такой подход является следствием понимания того, что перечень и содержание создаваемых документов определяется практикой, о чем мы подробнее поговорим позже.

Действия бизнес-аналитика

Вернемся теперь к вопросу о том, какие два слова отражают сущность работы бизнес-аналитика. Эти два слова – понимание и объяснение. Все действия, которые аналитик выполняет в рамках своей профессиональной деятельности, нацелены либо на первое, либо на второе. Результатом понимания всегда является объяснительная модель. Эта модель может включать определение того, что представляет собой предмет анализа или из чего он состоит (онтологический аспект), как он работает или что с ним можно делать (операционный аспект), зачем он нужен или как его можно использовать (аксиологический аспект). Независимо от нашего желания мы, люди, всегда действуем на основании осознанных или неосознанных умозрительных моделей, которые также принято называть «ментальными». Бизнес-аналитик выявляет и описывает те из них, которые имеют отношение к функционированию организации. Основное назначение моделей, используемых бизнес-аналитиком, состоит в их применении для принятия решений и планирования действий. Поэтому важной задачей бизнес-аналитика является объяснение результатов анализа другим участникам. Это объяснение может относиться как к самим моделям, так и к способам их использования, а также к выводам, сделанным в результате их применения.

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

13

Георгий Савельев Главным критерием качества создаваемых нами объяснительных моделей является их полезность. Как выразился известный эксперт в области статистического анализа Джордж Бокс (George E. P. Box): “По сути, все модели неверны, но некоторые – полезны». Бизнес-аналитику, как никому другому должны быть понятны эти слова. Можно сказать, что бизнес-аналитик является профессионалом в области конструирования и применения объяснительных моделей, полезных для бизнеса. Существует популярная метафора, сравнивающая бизнес-аналитика с переводчиком, который «транслирует» требования бизнеса разработчикам решений. Такое сравнение предполагает, что модели бизнеса можно просто «перевести», например на «язык информационных технологий». Если бы это было так, это означало бы, что организационные изменения, не связанные с использованием информационных технологий, не нуждаются в бизнес-анализе. Однако дело не в том, что эксперты в области бизнеса и технологии «разговаривают на разных языках», а в том, что они пользуются разными моделями. Их модели имеют разное назначение и образуются разными понятиями. Бизнес-аналитик – это специалист, способный понимать и те, и другие модели. Выступая в качестве «посредника», он не «транслирует» их, а выясняет и объясняет каким образом их можно объединить для получения нужного результата.

Иногда работа бизнес-аналитика не предполагает анализа технологических решений. Например, если стоит задача оценки текущей ситуации бизнеса и обоснования потребности в изменениях. Однако характер наших действий при этом не меняется. Для достижения понимания мы всегда начинаем с выяснения информации, имеющей отношение к делу. Затем мы осмысливаем полученную

ANALY SS

T

IAN IT B SS

RA

B

USINE

14

S RU SI

RUSSIAN IT BUSINESS ANALYSIS

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

Средства бизнес-анализа

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

Инструменты бизнес-аналитика – это текстовые редакторы, средства визуального моделирования, средства сбора и структурирования информации, электронные таблицы и другие средства вычислений, средства управления требованиями, средства создания презентаций, средства обеспечения коммуникации, и множество других. BABOK Guide делит эти инструменты на три основные категории: Средства офисной продуктивности, Средства бизнес-анализа, Средства и технологии коммуникации. Однако BABOK не обсуждает и не рекомендует никакие конкретные инструменты, полностью возлагая ответственность за их выбор на бизнес-аналитика. То, какие именно инструменты из огромного многообразия нужно выбрать для выполнения той или иной работы, обычно определяется применяемой практикой. Это может быть личная практика бизнес-аналитика (как я это обычно делаю), корпоративная практика (как это принято делать в данной компании), общеупотребительная практика (как это обычно делают), стандартная практика (как это нужно делать в соответствии с требованиями определенного стандарта), или передовая (как это делать лучше всего). Помимо применяемых инструментов, практика включает в себя типовые последовательности этапов или шагов выполнения работы, перечни создаваемых в результате документов, их шаблоны и образцы, используемые нотации моделирования, применяемые техники и паттерны решения типовых задач. К сфере практики также относится соблюдение определенного формата или стиля изложения документов.

BABOK Guide является международно признанным стандартом практики бизнес-анализа, основанным на обобщении опыта множества бизнес-аналитиков из разных стран. Он определяет 30 основных задач бизнес-анализа, описывает 46 техник применяемых для их решения, и перечисляет 26 базовых компетенций бизнес-аналитика, обеспечивающих его успешность. Задачи бизнес-анализа сгруппированы в шесть областей знания: Планирование и мониторинг бизнес-анализа, Выяснение и взаимодействие, Управление жизненным циклом требований, Стратегический анализ, Анализ требований и определение дизайна, Оценка решения. Эти знаANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

15

Георгий Савельев ния являются универсальными и общими для всех бизнес-аналитиков, независимо от области их применения. Седьмая область знания – деловые знания – включена в перечень базовых компетенций, а не профессиональных знаний, поскольку относится не к процессу бизнес-анализа, а к сфере его применения. В нее входят: общая деловая осведомленность, знание конкретной отрасли, знание конкретной организации, знание конкретного решения, и знание определенной методологии. Деловые знания разных бизнес-аналитиков могут существенно отличаться в зависимости от места и характера их работы. Именно эта категория знаний имеется в виду, когда в описании вакансий мы встречаем такие требования, как «высшее образование в области …», «опыт работы в …», «знание системы …». Таким образом работодатель пытается убедиться в том, что кандидат владеет нужным понятийным аппаратом и практическими навыками, которые приобретаются в результате соответствующего обучения и/или опыта работы.

Компетенции бизнес-аналитика

Компетенции бизнес-аналитика включают в себя знание методов, техник, практик и инструментов бизнес-анализа, навыки их применения, знание предметной области и опыт решения связанных с ней практических задач, а также базовые способности, обеспечивающие возможность формирования компетенций и взаимодействия с другими участниками. К базовым способностям относятся аналитическое мышление, умение решать проблемы, способности общения, поведенческие характеристики, и способности взаимодействия. Как обсуждалось в предыдущей статье, компетенции бизнес-аналитика можно разделить на пять слоев, каждый из которых соответствует определенной категории его возможностей. Способности первого (нижнего) слоя являются универсальными. Они обеспечивают возможность освоения знаний и навыков, а также их понимания и объяснения. В ходе освоения элементов профессиональной деятельности формируются навыки второго слоя (операционные), обеспечивающие возможность выполнять конкретные действия с использованием специальных инструментов. Навыки третьего слоя (процедурные) приобретаются в результате регулярного применения процедур получения конкретных результатов.

ANALY SS

T

IAN IT B SS

RA

B

USINE

16

S RU SI

RUSSIAN IT BUSINESS ANALYSIS

Сущность бизнес-анализа Навыки четвертого слоя (управленческие) предполагают способность выбирать инструменты и практики, наиболее подходящие для достижения нужного результата в контексте конкретного проекта. Очевидно, что при этом качество выбора определяется богатством арсенала тех средств, которыми владеет бизнес-аналитик. Способность модифицировать эти средства для их адаптации к особенностям стоящих задач определяется навыками пятого слоя (архитекторского). К этой же категории относится способность создавать новые средства бизнес-анализа по мере необходимости. Теоретически, заказчик или работодатель нанимает не человека, а его навыки и способности. Однако на деле зачастую складывается противоположное впечатление. Решение о найме принимается по принципу «нравится-не нравится». Причины этого следует искать в том, что лицу, принимающему решение, трудно судить о профессиональных компетенциях специалиста, а также о их соответствии тем, которые нужны для реализации конкретного проекта. Это неудивительно, поскольку определение навыков и инструментов, необходимых для решения задач бизнес-анализа в рамках проекта, обычно также относится к сфере ответственности бизнес-аналитика. В результате сотрудники, занимающиеся подбором персонала, фокусируются на тех свойствах специалиста, которые им легче всего оценить. К таковым относятся манера поведения, навыки общения, уверенность, знание предметной области, знание программных продуктов, и опыт предыдущей работы. Однако проблема состоит в том, что наличие похожего предыдущего опыта не гарантирует ни его применимости в новом контексте, ни того, что специалист сможет его адаптировать к нуждам данной организации. Несмотря на внешнее сходство, организации столь же значительно отличаются одна от другой, как и люди, которые в них работают. В конечном счете, смысл появления новых компаний и проектов состоит именно в создании чего-то нового, отличающегося от того, что уже есть. О том, как определить требования к компетенциям кандидата на позицию бизнес-аналитика, и как оценить соответствие кандидата этим требованиям, речь пойдет в последующих статьях.

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

17

17-18 апреля 2015. Минск

ANALY SS

T

IAN IT B SS

RA

B

USINE

18

S RU SI

RUSSIAN IT BUSINESS ANALYSIS

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

19

Типы требований и методики сбора требований в разрезе различных стандартов Иван Шамаев

Типы требований и методики сбора требований в разрезе различных стандартов В статье описаны основные виды требований и методики сбора требований в разрезе различных стандартов/методик и книг, которые описывают порядок работы с теми или иными видами требований. Иван Шамаев системный аналитик, Альфастрахование

Business Analysis Body of Knowledge (BABOK) v2.0

Профессиональный стандарт/свод знаний по бизнес-анализу, разработанный и дополняемый международным институтом бизнес-анализа IIBA в Канаде

Мозговой штурм Анализ документов Фокус-группы Анализ интерфейсов Интервью Наблюдение Прототипирование Семинары по сбору требований Анкетирование

S RU SI

T

IAN IT B SS

RUSSIAN IT BUSINESS ANALYSIS

ANALY SS

Бизнес-требования Требования заинтересованных сторон Требования к решению: • Функциональные требования • Нефункциональные требования Переходные требования

Методы сбора требований

RA

B

USINE

Типы требований

21

Иван Шамаев

ISO/IEC 29148 Интернациональный стандарт, определяющий процессы, которые должны быть реализованы в ходе процесса инженерии требований для систем и программных продуктов на протяжении всего жизненного цикла ПО.

Типы требований

Требования заинтересованных сторон Системные требования: • Функциональные требования • Требования производительности • Системные интерфейсы • Требования по взаимодействию людей с системой • Ремонтопригодность • Надежность • Режимы работы и состояния системы • Физические требования • Адаптивные требования • Условия окружающей среды • Безопасность системы • Управление информацией • Регламенты и нормативные документы • Самообеспечение жизненного цикла системы • Упаковка, обращение, доставка и транспортировка

Требования к программному обеспечению: • Специальные требования • Внешние интерфейсы • Функциональные требования • Юзабилити требования • Требования к производительности • Требования к логической структуре базы данных • Ограничения проектирования • Соответствие стандартам • Системные атрибуты программного обеспечения

ANALY SS

T

IAN IT B SS

RA

B

USINE

22

S RU SI

RUSSIAN IT BUSINESS ANALYSIS

Методы сбора требований

Структурированные семинары с мозговым штурмом Интервью, анкеты Наблюдение за окружающей средой или шаблонами рабочих процессов Обзор технической документации Анализ рынка или оценка конкурентности системы Симуляция, прототипирование, моделирование Бенчмаркинг процессов и систем Метод организационного анализа (например, SWOT-анализ, анализ портфеля продуктов)

Типы требований и методики сбора требований...

Software Engineering Body of Knowledge (SWEBOK) Документ, подготавливаемый комитетом Software Engineering Coordinating Committee, в который вовлечено сообщество IEEE Computer Society. Назначение SWEBOK — объединение знаний по инженерии программного обеспечения (разработка программного обеспечения)

Типы требований

Программные требования Требования к продукту и процессу Потребности Независимые свойства Требования с количественной оценкой Требования к качеству программного обеспечения

Методы сбора требований

Интервьюирование Сценарии Прототипы Разъясняющие встречи Наблюдение

Группа функциональных требований: • Бизнес-требования • Пользовательские требования • Функциональные требования

Группа нефункциональных требований • Бизнес-правила • Внешние интерфейсы • Атрибуты качества • Ограничения

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

23

Иван Шамаев

Information Technology Infrastructure Library (ITIL) v2 IT Infrastructure Library — библиотека инфраструктуры информационных технологий, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий.

Типы требований

Требование к уровню услуг (SLR) Проектная документация услуги (SDP) должна содержать: • Требования бизнеса • Функциональные требования к услуге • Требования к уровням услуги • Требования к управлению услугой и ее эксплуатации

Детализированная спецификация с требованиями: • Функциональные требования • Требования к информационной безопасности • Архитектурные ограничения • Требования к интерфейсу • Требования к миграции данных • Операционные требования • Требования по правам доступа

ANALY SS

T

IAN IT B SS

RA

B

USINE

24

S RU SI

RUSSIAN IT BUSINESS ANALYSIS

Методы сбора требований

Интервью Семинары по сбору требований Наблюдение Анализ протоколов «Слежка» за опытным сотрудником Сценарный анализ Прототипирование Другие методы - анкеты, записи специального назначения, разбор отдельных активностей (действий) сотрудников.

Типы требований и методики сбора требований...

Capability Maturity Model Integration Development (CMMI DEV) v1.3 CMMI (CMM Integration) — набор моделей (методологий) совершенствования процессов в организациях разных размеров и видов деятельности. CMMI содержит набор рекомендаций в виде практик, реализация которых, по мнению разработчиков модели, позволяет реализовать цели, необходимые для полной реализации определённых областей деятельности. Наиболее известной является модель CMMI for Development, ориентированная на организации, которая занимается разработкой программного обеспечения, аппаратного обеспечения, а также комплексных систем

Демонстрация технологий Анкеты, интервью и сценарии операций, полученные от конечных пользователей Операционные пошаговые руководства и анализ задач конечного пользователя Прототипы и модели Мозговой штурм Разработка функции качества Исследования рынка Бета-тестирование Извлечение из источников, таких как документы, стандарты, спецификации или бизнес-регламенты Наблюдение за существующими продуктами, средой и шаблонами рабочих процессов Варианты использования Анализ бизнес-кейсов Реверсивное проектирование (для устаревших продуктов) Исследования удовлетворенности клиентов

S RU SI

T

IAN IT B SS

RUSSIAN IT BUSINESS ANALYSIS

ANALY SS

Требования заказчика (потребности заинтересованных сторон, ожидания, ограничения и взаимодействия) Требования к продукту Требования к компонентам продукта

Методы сбора требований

RA

B

USINE

Типы требований

25

Иван Шамаев

ГОСТ 34.602-89. Техническое задание на создание АС Техническое задание на создание АС ГОСТ 34.602-89 описывает рекомендуемые состав и структуру для технического задания по созданию, развитию или модернизации автоматизированных систем

Типы требований

Методы сбора требований

Требования к системе в целом: Не описаны • требования к структуре и функционированию системы; • требования к численности и квалификации персонала системы и режиму его работы; • показатели назначения; • требования к надежности; • требования безопасности; • требования к эргономике и технической эстетике; • требования к транспортабельности для подвижных АС; • требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы; • требования к защите информации от несанкционированного доступа; • требования по сохранности информации при авариях; • требования к защите от влияния внешних воздействий; • требования к патентной чистоте; • требования по стандартизации и унификации; • дополнительные требования. Требования к функциям (задачам), выполняемым системой Требования к видам обеспечения Общие требования к приемке работ по стадиям Требования к документированию

ANALY SS

T

IAN IT B SS

RA

B

USINE

26

S RU SI

RUSSIAN IT BUSINESS ANALYSIS

Типы требований и методики сбора требований...

ГОСТ 19.201-78. Техническое задание, требования к содержанию и оформлению Данный стандарт устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения

Типы требований

Методы сбора требований

Требования к программе или программному Не описаны изделию: • Требования к функциональным характеристикам • Требования к надежности • Условия эксплуатации • Требования к составу и параметрам технических средств • Требования к информационной и программной совместимости • Требования к маркировке и упаковке • Требования к транспортированию и хранению • Специальные требования Требования к программной документации

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

27

Иван Шамаев

Requirements Engineering Body Of Knowledge (REBOK) Свод знаний по инжинирингу требований — Requirements Engineering Body Of Knowledge (REBOK), который разрабатывается в японском университете Nanzan University группой под руководством профессора Mikio Aoyama на основе различных мировых стандартов по бизнес-анализу

Типы требований

3 Уровня требований: Бизнес/Продукт • Бизнес-стратегия • Бизнес-кейс • Бизнес-правила • Законы • Бизнес-среда • Бизнес-процесс

Система • Используемые системы • Цели системы • Функции • QoS/SLA • Операционная среда • Операционные сценарии

Программное обеспечение • Используемое ПО • Цели ПО • Переходные требования • Среда ПО • Варианты использования • Качество ПО • Функциональные требования • Нефункциональные требования

ANALY SS

T

IAN IT B SS

RA

B

USINE

28

S RU SI

RUSSIAN IT BUSINESS ANALYSIS

Методы сбора требований

Сбор информации о пользователях: • Наблюдение • Профилирование пользователя • Просмотр журнала действий пользователя (например, в операционной системе) Методы сценариев и пользовательских историй: • Анкетирование/Интервью • Наблюдение • Рабочие семинары по сбору требований • Анализ документации

Типы требований и методики сбора требований...

Project Management Body of Knowledge (PMBOK) Свод знаний по управлению проектами PMBoK (Project Management Body of Knowledge) представляет собой сумму профессиональных знаний по управлению проектами. Является Американским национальным стандартом

Типы требований

Методы сбора требований

Бизнес-требования: • цели организации и проекта для возможности отслеживания; • бизнес-правила для исполняющей организации; • руководящие принципы организации

Интервью Фокус-группы Семинары с участием модератора Методы группового творчества: • Мозговой штурм • Метод номинальных групп Требования заинтересованных сторон: • Построение ассоциативных • воздействие на другие области организации; карт • воздействие на другие субъекты внутри или за • Диаграмма сходства пределами исполняющей организации; • Анализ решений на основе мно• требования к коммуникациям и отчетности для жества критериев заинтересованных сторон Методы группового принятия решений Требования к решению: Анкеты и опросы • функциональные и нефункциональные требова- Наблюдения ния; Прототипы • требования соответствия технологиям и станБенчмаркинг дартам; Контекстные диаграммы • требования к поддержке и обучению; Анализ документов • требования к качеству; • требования к отчетности и т. д. (требования к решению могут быть документированы в виде текста, моделей или используя оба метода) Требования к проекту: • уровни обслуживания, производительности, безопасности, соответствия и т. д.; • критерии приемки Требования к переходу. Допущения, зависимости и ограничения в отношении требований.

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

29

Иван Шамаев

IBM OpenUP и FURPS+ OpenUP — это экономичный унифицированный процесс, использующий принципы итеративности и инкрементальности в рамках структурированного жизненного цикла.

FURPS — классификация требований к программным системам. Требования были разработаны и представлены Hewlett-Packard. В настоящее время используется аббревиатура FURPS+

Типы требований

Три уровня требований по IBM OpenUP: 1. Уровень концепции - Модель бизнес-процесса - Потребности заинтересованных лиц - Словарь предметной области - Бизнес-правила (ограничения) 2. Уровень пользователя - Функции системы - Варианты использования - Нефункциональные требования 3. Уровень системы - Эскизы интерфейса пользователя - Раскадровка

Модель «FURPS+» — функциональные, нефункциональные и вспомогательные требования Функциональные требования: - Функции системы - Требования по аудиту системы - Требования по лицензированию - Требования к функции печати - Требования к отчетности - Требуется ли функция генерации отчётов?

- Требования по безопасности Нефункциональные требования: - Требования удобства использования - Требования надежности - Требования производительности

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

30

Вспомогательные требования: - Проектные ограничения - Требования управления системой - Требования к графическому интерфейсу пользователя - Физические требования - Юридические требования - Требования к лицензированию - Требования к документированию RUSSIAN IT BUSINESS ANALYSIS

Методы сбора требований

Мозговой штурм Интервьюирование пользователей Погружение в среду пользователя Изучение аналогов Изучение «книги жалоб и предложений» Разговор с командой поддержки Изучение усовершенствований, сделанных пользователями Совместный семинар Демонстрация прототипа заинтересованным лицам

Типы требований и методики сбора требований...

Элизабет Халл. Разработка и управление требованиями В книге описан процесс разработки и управлениями требованиями, также подробно рассмотрены основные методы моделирования требований

• Интервью с представителями заинтересованных сторон • Сценарии использования (обычно получаемые в результате интервью) • Описательная документация (например, различные отчеты, анализ рынка) • Действующие системы, которые необходимо модернизировать • Проблемы, обнаруженные в существующих системах, и идеи как их исправить • Опыт работы с аналогичными системами • Разного рода прототипы, макеты, эскизы продукта или самих требований • Возможности новых технологий (согласованные с заинтересованными сторонами) • Результаты исследований • Опросы • Наблюдение за работой персонала или изучение видеозаписей их работы

S RU SI

T

IAN IT B SS

RUSSIAN IT BUSINESS ANALYSIS

ANALY SS

Требования в системной инженерии: • Пользовательские требования • Системные требования • Требования к подсистемам • Требования для компонентов

Методы сбора требований

RA

B

USINE

Типы требований

31

Иван Шамаев

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

Типы требований

Приемлемая схема требований: Цель и область действия Используемые термины/Глоссарий Варианты использования Используемая технология Другие требования: • Процесс разработки • Бизнес-правила • Производительность • Эксплуатация, безопасность, документация • Использование (простота использования) • Сопровождение и мобильность • Нерешенные или отложенные вопросы

Людские резервы, правовые, политические, организационные вопросы

ANALY SS

T

IAN IT B SS

RA

B

USINE

32

S RU SI

RUSSIAN IT BUSINESS ANALYSIS

Методы сбора требований

Не описаны

Типы требований и методики сбора требований...

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

Нефункциональные требования: • Атрибуты качества • Внешний интерфейс • Ограничения

Фокус-группы типичных пользователей Проведение совместных семинаров Наблюдение за пользователями на рабочих местах Изучение отчетов о проблемах работающих систем с целью поиска новых идей Повторное использование требований в разных проектах

S RU SI

T

IAN IT B SS

RUSSIAN IT BUSINESS ANALYSIS

ANALY SS

Бизнес-требования Требования пользователей Функциональные требования Системные требования Бизнес-правила

Методы сбора требований

RA

B

USINE

Типы требований

33

Иван Шамаев

Лешек А. Мацяшек. Анализ и проектирование информационных систем с помощью UML 2.0 В книге описывается методология и технология объектно-ориентированной разработки современных информационных систем (ИС) и предлагается итеративный подход к разработке ИС с пошаговым наращиванием их возможностей. Весь комплекс вопросов анализа и проектирования ИС рассматривается в контексте использования языка UML

Типы требований

Документ описания требований Предварительные замечания к проекту Системные сервисы: • Рамки системы • Функциональные требования • Требования к данным

Системные ограничения: • Требования к интерфейсу • Требования к производительности • Требования к безопасности • Эксплуатационные требования • Политические и юридические требования • Другие ограничения Проектные вопросы Глоссарий Три группы моделей спецификаций требований Модели состояний — детализируют требования к данным: • Моделирование классов • Моделирование ассоциаций • Моделирование отношений агрегации и композиции • Моделирование отношений обобщения • Моделирование объектов

Модели поведения — модели поведения обеспечивают детализированные спецификации для функциональных требований: • Моделирование прецедентов • Моделирование видов деятельности • Моделирование взаимодействий • Моделирование открытых интерфейсов ANALY SS

T

IAN IT B SS

RA

B

USINE

34

S RU SI

RUSSIAN IT BUSINESS ANALYSIS

Методы сбора требований

Традиционные методы выявления требований: • Интервьюирование заказчиков и экспертов в проблемной области • Анкетирование • Наблюдение • Изучение документов и программных систем

Современные методы выявления требований: • Прототипирование • Совместная разработка приложений (JAD-метод) • Быстрая разработка приложений (RAD-метод)

Типы требований и методики сбора требований... Типы требований

Методы сбора требований

Модели изменения состояний — охватывают два вида требований - каким образом действие функций приводит к изменению данных.: • Моделирование состояний объектов

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

35

Doing right things is much more important than do thing right ООО «Системный подход»

РАЗВИТИЕ ОРГАНИЗАЦИОННОЙ КОМПЕТЕНЦИИ ДЕЛАТЬ ПРАВИЛЬНЫЕ ВЕЩИ. С каждым годом растет сложность современных организаций и технологических решений необходимых для достижения Успеха. Повышается давление изменений и конкуренции на уже существующие системы. Растет кол-во возможностей по развитию. И чем сложнее система, особенно социотехническая, тем сложнее определить в чем именно состоит проблема и подобрать людей, которые смогут не только осуществить, но и найти, и выбрать именно то решение которое даст наибольшие преимущества организации. Успех организации и конкретного подразделения зависит от готовности к предстоящим изменениям, способности определить главное направлении и сосредоточить свои ресурсы на нем. Где искать компетентных аналитиков, руководителей продуктов и проектов, при том что универсальных решений не существует?

Как мы работаем? Для достижения результата необходим системный подход к развитию организационной компетенции:

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

ренность заказчика (как внутреннего, так и внешнего)

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

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

• Наставничество. Механизмы наставничества и непосредственного участия наших специалистов позволяют добиваться быстрых и надежных результатов и создают возможности для быстрого роста компетенции как отдельных специалистов, так и организации в целом.

ANALY SS

T

IAN IT B SS

RA

B

USINE

36

S RU SI

RUSSIAN IT BUSINESS ANALYSIS

Doing right things is much more important than do thing right ООО «Системный подход»

Наши направления • Инженерия требований • Бизнес анализ – Комплексное решение бизнес задач, Основной процесс и этап в достижении целей заказчика; • Системный анализ – Управление границами решения, Основной процесс в создании сложных решений в тесно интегрированной среде.

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

• Стратегическое планирование. Мы используем адаптированную Rapid Foresight методологию для создания осознанной стратегии развития продукта. Системы или подразделения.

• Управление проектами и командами (Soft Skills). Разработка ПО, как никакой другой вид деятельности близок к исследованиям, что в значительной степени усложняет и меняет принципы управления проектами заложенные в кросс дисциплинарных областях знаний, но без управления невозможно достичь целей и сложно создать команду.

• Архитектура – Один из самых сильных и наиболее дорогих факторов в создании и развитии решений. Даже незначительные ошибки могут привести к фатальным для продукта или решения последствиям. Обучение современным практикам и методикам не позволяет сделать из разработчика архитектора, однако в значительной степени ускоряет его формирование и позволяет снизить вероятность ошибок.

Преимущества нашей команды •

Мы умеем и делаем то, чему обучаем!

•

Надежные партнеры

•

Более чем 15 лет успешного опыта работы и управления командами в ИТ

•

Более 9 лет опыта консалтинга и обучения

•

Комплекс авторских модульных тренингов позволяет осуществить адаптацию учебных блоков с учетом потребностей заказчика

В отличие от:

• Индивидуального обучения, мы создаём команду единомышленников и среду в которой у новых практики и методов наиболее высокие шансы прижиться. Не возникает дисбаланса между знаниями специалиста и возможностями по применению тех или иных практик.

• Аутсорсинга работ, ваша компания и организация приобретает ключевые знания и навыки, и способна развивать созданное решение самостоятельно не прибегая к услугам сторонних организаций

Контактная информация Все вопросы по поводу сотрудничества могут быть направлены: Безуглому Дмитрию Леонидовичу bdl@system-approach.ru Подписаться на новости компании https://www.facebook.com/SystemApproach

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

37

Описание бизнес процессов. Правила проведения интервью Александр Дублин

Описание бизнес-процессов. Правила проведения интервью Наша статья ориентирована на руководителей практики консалтинговых компаний и бизнес-аналитиков. Описанный в ней подход к проведению интервью можно назвать ритуалом, но, по нашему мнению, необходимо, чтобы это стало обычной практикой Александр Дублин Бизнес Аналитик

Ч

уть более 10 лет назад меня назначали «главным» по предпроектному обследованию бизнеса заказчика. Предпроектное обследование проводилось для оценки объема (scope) и продолжительности проекта внедрения ERP системы Axapta. Мне в помощь были выделены два студента, не имеющих практического опыта ни предпроектного обследования, ни внедрения ERP системы.

Я понимал, что «успех» предпроектного обследования определяет состоится ли продажа услуг по внедрению Axapta. Продажа окажется возможной лишь в случае, если заказчик воспримет наших сотрудников как харизматиков и профессионалов своего дела. (Прим. В переводе с греческого харизма означает «дар богов». Харизматическое поведение может быть разбито на три основных элемента: присутствие, сила и теплота. Эти элементы зависят и от нашего осознанного поведения, и от факторов, которыми мы не управляем на сознательном уровне). Я взял трёхдневный тайм аут и создал некий документ – инструкцию по подготовке и проведению интервью. Мы успешно провели предпроектное обследование – клиент купил у нас Axapta. Через два года на одной из вечеринок в неформальной обстановке я спросил ЛПРа (лицо, принимавшего решения): «А почему вы купили именно у нас, а не у кого-либо другого?». Ответ меня приятно удивил: «Одновременно с вами мы начали работать ещё с двумя консалтинговыми компаниями. Внешний вид ваших консультантов нас сильно насторожил: очень молодые люди приятной внешности, мы засомневались, умеют ли они что-либо делать, кроме того, что «строить куры». Однако первые же интервью показали нам, что мы имеем дело с профессионалами: никаких лишних вопросов, всё строго по существу, прекрасные отчёты о встречах. Несмотря на внешнюю солидность и респектабельность, ваши конкуренты выглядели очень блекло на этом фоне.» После этого случая я решил создать документ «Правила проведения интервью». В течение 10 последующих лет мы с коллегой непрерывно совершенствовали эти правила, инкорпорируя в них опыт применения этих Правил.

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

39

Александр Дублин

Выгоды применения Правил на практике

О важности умения бизнес-аналитика проводить интервью с представителем заказчика можно найти много содержательных материалов в сети. Однако отсутствуют предписывающие (а не описывающие!) методики по интервьюированию, проведению встреч, собеседований, которыми бы мог руководствоваться бизнес-аналитик. В статье предлагается разработанная нами общая методика проведения интервью бизнесаналитиком с функциональными представителями компании заказчика (клиента). Как показывает наш опыт, в сравнении с неформальным подходом, имеющим место в настоящее время, предлагаемая методика обладает следующими преимуществами: • на 30% сокращается время проведения интервью; • на 40% сокращается время подготовки отчёта о проведении интервью; • практически сводится к нулю вероятность повторного интервью; • в разы повышается уровень взаимного доверия участников интервью; • формализованный (документированный) результат проведения интервью может быть включён в корпоративную базу знаний. Концепция интервью сформулирована в виде Правил проведения интервью. Это делает возможным её практическое применение в деятельности консалтинговой фирмы и бизнесаналитиков. Опыт «кровью и железом» показывает, что эти правила являются best practice. Но если ваш личный (корпоративный) опыт диктует вам иные формулировки пунктов свода Правил, приводимых ниже, вы можете внести необходимые изменения, так как он (свод Правил) открыт для модификации и оптимизации. Например, если вы уверены, что в определённых случаях необходима предварительная отправка интервьюируемому опросных листов, то этот пункт легко включается в свод Правил. В случае если в вашей фирме приняты другой порядок отчётности, вы можете изменить соответствующие пункты свода Правил без ущерба для общей концепции.

Правила проведения интервью

1. Общие положения 1.1. Правила проведения интервью (далее – Правила) устанавливают единый для сотрудников Компании порядок подготовки и проведения интервью при изучении (диагностике) бизнеспроцессов Клиента, а также порядок отчётности о проведённом интервью.

1.2. Настоящие Правила входят отдельным документом в документооборот Компании.

1.3. Настоящие Правила предусматривают три вида интервью (по способу проведения): • путём непосредственного общения; • путём общения по телефону; • путём общения по электронной почте.

2. Порядок подготовки интервью

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

40

2.1. Дату интервью и исполнителя (лей) процедуры назначает менеджер проекта (функциональный начальник).

2.2. За два дня до даты проведения интервью исполнитель представляет менеджеру проекта на утверждение: • план интервью (Приложение 1); • опросный лист, • текст Предварительного письма.

2.3. При составлении опросного листа рекомендуется использовать «Корпоративную методику подготовки опросных листов».

RUSSIAN IT BUSINESS ANALYSIS

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

2.5. Незадолго до проведения интервью следует внимательно прочитать «Правила общения» (Приложение 3).

3. Порядок проведения интервью и этикет

3.1. Следует (желательно) проводить интервью не одному (вдвоём).

3.2. Следует избегать действий, неприятных для интервьюируемого, например, садиться или курить без его согласия и т. п.

3.3. Интервьюеру не следует излагать своё мнение об услышанном от собеседника. Следует только накапливать информацию для последующего анализа и использования. Не следует обсуждать с интервьюируемым мнения других сотрудников. В ходе проведения интервью не следует давать советов.

3.4. Следует документировать вопросы и ответы по ходу проведения интервью с приложением черновых записей к отчёту об интервью.

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

3.6. Интервьюеру следует «уметь слушать» и демонстрировать корректность в разговоре. При высказываниях партнёра по вопросам, выходящим за рамки обсуждаемого, следует дать ему возможность изложить своё мнение, так как при этом представляется возможность получения дополнительной информации. Далее необходимо добиться ответа на обсуждаемый вопрос, вернув разговор в прежнее русло и убедившись в том, что вопрос был правильно сформулирован (понят) и интервьюируемый может дойти до сути дела.

3.7. В ходе проведения интервью необходимо уделять достаточное внимание вопросам, которые задаёт интервьюируемый. Следует поддерживать неформальную атмосферу беседы и способствовать её продолжению.

3.8. В конце интервью необходимо подвести его итоги с целью убедиться в том, что и вопросы и ответы были правильно поняты партнёрами.

3.9. Если по ходу интервью выясняется недостаток времени для его проведения, следует договориться о продолжении интервью и назначить следующую встречу или оговорить порядок её назначения.

3.10. Обсуждая ход бизнес-процессов, следует определять (выявлять) проблемы, возникающие у их подчинённых и руководителей, а также проблемы, которые индуцируют («наводят») трудности в других подразделениях компании или у клиентов (поставщиков). В результате, для каждого бизнес – процесса формируется перечень выявленных проблем.

3.11. По окончании интервью следует дать возможность партнёру сделать дополнительные замечания, которые он считает важными.

3.12. Необходимо узнать мнение интервьюируемого о необходимости проведения интервью с другими сотрудниками и изучения определённых документов.

3.13. Следует поставить в известность интервьюируемого о принципах и способах обработки результатов интервью, планах на дальнейшие встречи и планируемых сроках завершения этапа внедрения. Следует обменяться контактными номерами телефонов и адресами электронной почты.

4. Порядок обработки результатов интервью и отчётность. следующего

рабочего

дня

следует

отправить

RUSSIAN IT BUSINESS ANALYSIS

интервьюируемому S RU SI

ANALY SS

позднее

T

RA

B

USINE

Не

IAN IT B SS

4.1.

41

Александр Дублин Благодарственное письмо. После того как ключевой пользователь уделил вам полчаса или более своего времени, необходимо найти время и поблагодарить этого человека письменно. Это покажет, что сотрудники компании ценят и своё, и чужое время. Необязательно, чтобы письмо было написано безукоризненным языком, но оно не должно выглядеть как клише или шаблон, взятый из компьютерной библиотеки. В благодарственном письме должны быть указаны все существенные результаты встречи, в частности, должны быть перечислены: • рассмотренные в ходе встречи вопросы, • полученные / переданные документы, • плановый срок предоставления отчёта об интервью, • достигнутые договорённости.

4.2. Обработка результатов интервью производится в течение трёх дней после проведения интервью.

4.3. В пакет отчётных документов входят: • план интервью; • опросный лист; • отчёт об интервью.

4.4. План интервью и отчёт об интервью являются управленческими документами и составляются, учитываются и хранятся по правилам корпоративного документооборота.

4.5. С разрешения менеджера проекта следует представить отчёт об интервью на согласование интервьюируемому. Не подлежит представлению часть отчёта об интервью, определённая менеджером проекта.

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

4.7. Менеджер проекта обеспечивает подписание отчёта об интервью (купированного соответствующим образом) официальным представителем обследуемого Клиента.

ANALY SS

T

IAN IT B SS

RA

B

USINE

42

S RU SI

RUSSIAN IT BUSINESS ANALYSIS

Описание бизнес-процессов

Приложение 1. План интервью

1. Сведения о проекте Наименование проекта / Клиента: _____________________________________________________ Текущая стадия / этап проекта: _____________________________________________________ Связь цели проекта / технического задания с интервью: ___________________________________ 2. Структурированная цель интервью 1. ___________________________________________________________________________________ 2. ___________________________________________________________________________________ 3. ___________________________________________________________________________________ 3. Данные об интервьюерах

№ п/п

Роль в проекте

ФИО

4. Данные об интервьюируемых лицах № п/п

Должность

ФИО

Реквизиты для связи

Местоположение (географическое) в офисе

5. Взаимное представление Следует указать, когда и при каких обстоятельствах (совещание, фуршет и т. п.) был ранее представлен интервьюер. Следует указать лицо (должность, ФИО), которое представило / представит партнёров друг другу: _________________________________________________________________________ 6. Осведомлённость интервьюируемого о цели встречи Необходимо указать, когда и при каких обстоятельствах интервьюируемому сообщили / сообщат о цели интервью. Указать должность и ФИО сообщившего лица: _________________________________ ______________________________________________________________________________________ 7. Актуальная (деловая) информация, которой владеет интервьюер Следует специфицировать информацию, имеющуюся у интервьюера, и степень (произвольно) знакомства с ней (для документов). № п/п

Описание информации

Степень знакомства

8. Предполагаемое место проведения интервью (не обязательно) Следует указать место проведения интервью и наличие помех для проведения интервью: __________________________________________________________________________________ 9. Планируемое для проведения интервью время

Дата

Время начала

Время окончания

Длительность (чч, мм)

Дата, время и длительность продолжения интервью

Вид информации, которую интервьюер желает получить в процессе интервью

Степень детализации

Категория конфиденциальности

1

2

..

S RU SI

T

IAN IT B SS

RUSSIAN IT BUSINESS ANALYSIS

ANALY SS

№ п/п

RA

B

USINE

10. Информационная цель интервью

43

Александр Дублин 11. Предполагаемый способ записи информации Следует указать способ записи информации во время интервью. Опросные листы прилагаются к настоящему плану (составляются в произвольной форме): _________________________________________ _____________________________________________________________________________________ Количество опросных листов: _________ на __________ страницах.

12. План беседы и список вопросов Составляется список вопросов согласно цели интервью с указанием желательной степени (произвольно) точности ответа и времени на их обсуждение. План беседы определяется последовательностью и длительностью обсуждения вопросов. При количестве вопросов в перечне более 15 список вопросов обособляется как приложение к плану интервью. № п/п

Вопрос

Степень точности ответа (не обязательно)

Время обсуждения (не обязательно)

1

2

..

13. Список документов, предполагаемых к получению Перечисляются документы с отметкой предварительной договорённости о предоставлении № п/п

Наименование документа

1 2 ..

14. Планируемые сроки составления отчёта об интервью Срок возврата опросных листов: до _____________________________ Порядок согласования с интервьюируемым материалов отчёта: _____________________________ Срок представления отчёта менеджеру проекта: ______________________

ANALY SS

T

IAN IT B SS

RA

B

USINE

44

S RU SI

RUSSIAN IT BUSINESS ANALYSIS

Описание бизнес-процессов

Приложение 2. Отчёт об интервью 1. Сведения о проекте Наименование проекта: _____________________________________________________ Текущая стадия / этап проекта: _____________________________________________________ Связь цели проекта с интервью: ______________________________________________________ 2. Оценка достижения целей интервью Следует специфицировать информацию, имеющуюся у интервьюера, и степень (произвольно) знакомства с ней (для документов). № п/п 1

Цель

Степень достижения (произвольно)

2 3

3. Данные об интервьюерах № п/п

Роль в проекте

ФИО

1 2

4. Данные об интервьюируемых лицах № п/п

Должность

ФИО

Реквизиты для связи

Местоположение (географическое) в офисе

5. Место проведения интервью Следует указать место проведения интервью и наличие помех для проведения интервью: _____________________________________________________________________________________ 6. Время проведения интервью Дата

Время начала

Время окончания

Длительность (чч, мм)

Дата, время и длительность продолжения интервью

7. Способ записи информации Следует указать способ записи информации во время интервью. Черновые записи прилагаются к настоящему отчёту.___________________________________________________________________ ______________________________ _____________________________________________________ Количество полученных опросных листов: _________ на __________ страницах. Количество неполученных опросных листов: __________ Количество страниц черновых записей: ______________ 8. Список полученных документов № п/п

Наименование документа

Носитель

1

..

9. Список неполученных документов № п/п

Наименование документа

Причина, сообщённая интервьюируемым

1

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

45

Александр Дублин ..

10. Результат беседы Если перечень вопросов был обособлен как приложение к плану интервью, то результат беседы обособляется в том же документе. № п/п

Вопрос

Содержание ответа

Степень точности ответа

Время обсуждения

1 ..

11.Выявленные проблемы бизнес-процессов № п/п

Бизнес-процесс

Проблема

Примечание

1 ..

12. Отметка о согласовании отчёта Порядок согласования с интервьюируемым материалов отчёта (указывается время и способ согласования / передачи надлежащих материалов отчёта интервьюируемому) : __________________________ ______________________________________________________________________________________ 13. Прочие полученные сведения ____________________________________________________________________________________ 14. Контрольный лист умения слушать Слушая собеседника, поддерживайте с ним зрительный контакт Слушая собеседника, не занимайтесь посторонними делами Проявляйте к собеседнику чуткость Наблюдайте за мимикой и жестами собеседника Не перебивайте собеседника Задавайте уточняющие вопросы Заверьте собеседника в том, что вы поняли его. Спросите собеседника, можете ли вы ему чем-либо помочь

ANALY SS

S RU SI

T

IAN IT B SS

46

Рекомендация

RA

B

USINE

№ п/п 1 2 3 4 5 6 7 8

RUSSIAN IT BUSINESS ANALYSIS

Оценка выполнения (по 10-и бальной шкале)

Описание бизнес-процессов

Приложение 3. Правила общения Умение общаться - один из важнейших навыков SAP-консультантов. Предлагаю вашему вниманию небольшую «шпаргалку», которую следует иметь при себе и пользоваться перед каждой встречей к клиентом. После встречи с клиентом я рекомендую самостоятельно оценить выполнение каждого пункта. Слушая собеседника, поддерживайте с ним зрительный контакт Это помогает не отвлекаться мысленно и показывает собеседнику, что вы уделяете ему безраздельное внимание. Не закатывайте и не закрывайте глаза от удивления или недовольства, не смотрите поверх головы собеседника и не пяльтесь на его обувь. Слушая собеседника, не занимайтесь посторонними делами. Помните, качественно проведённое с кем-то время — это, прежде всего, безраздельное внимание. Если вы чем-то заняты, в тот момент, когда к вам обратился пользователь, от чего вам трудно оторваться, скажите ему честно: «Я с удовольствием пообщаюсь с Вами и уделю Вам полноценное внимание, но чуть позднее, потому что сейчас я занят. Если Вы подождёте, то через десять минут я выслушаю Вас». Большинство людей оценят такое отношение. Проявляйте к собеседнику чуткость. Спросите себя: «А что чувствует сейчас этот человек?» Если вы нашли ответ на этот вопрос, то обязательно уточните, так ли это. Например: «Похоже, Вы расстроены из-за...» Это даст возможность вашему собеседнику объяснить, что он испытывает в момент разговора, и будет свидетельством того, что вы его внимательно слушаете. Наблюдайте за мимикой и жестами собеседника. Дрожащие руки, недовольное выражение лица, нахмуренные брови, подёргивание век многое могут сказать о душевном состоянии собеседника. Иногда его мимика и жесты не совпадают со словами. Уточните, что на самом деле он чувствует и думает. Например: «Вы говорите, что согласны с предложенным изменением бизнес-процессов, но мне, кажется, что Вас заставили согласится. Это так или я ошибаюсь?» Не перебивайте собеседника. Исследования показывают, что в среднем человек обычно слушает первые семнадцать секунд, затем перебивает рассказчика и вставляет свои «пять копеек». Общение в таком случае может закончиться, не успев начаться. Ваша задача на начальном этапе разговора — не отстаивать свою точку зрения, не ставить собеседника на место, а понять его мысли, чувства и желания. Если перебить слишком рано, можно так никогда и не узнать, что пытался сказать человек. Задавайте уточняющие вопросы. Если вы не совсем понимаете, о чем говорит собеседник, уточните это, повторив то, что он сказал: «Вы имеете в виду, что... Верно?» Уточнение услышанного предотвращает непонимание между собеседниками. Заверьте собеседника в том, что вы поняли его. Каждому человеку важно знать, что его услышали и поняли. Выражая понимание, вы помогаете собеседнику почувствовать себя правым в ситуации. Спросите собеседника, можете ли вы ему чем-либо помочь. Заметьте, именно помочь, а не указывать, что делать. Никогда не давайте совет, если вас об этом не просят. Резюме Для того чтобы состоялась качественная беседа, необходимо потратить время и усилия. Фактически на выслушивание уходит в два раза больше времени, нежели на реплики. Однако это приносит огромные дивиденды. Собеседник почувствует с вашей стороны уважение, понимание и любовь, что является основной целью качественного общения.

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

47

Правильный подход к анализу бизнес процессов в банке Владимир Ковешников

Правильный подход к анализу бизнес процессов в банке Не секрет, что банковский бизнес развивается не одну сотню лет, но эффективно ли он работает в наши дни? Владимир Ковешников Руководитель направления и консультант по банковским бизнес процессам учебного центра Luxoft Training

П

оследние годы автоматизация в банковском бизнесе сводится к трем-четырем основным направлениям. Среди них можно выделить построение централизованной АБС, внедрение решений онлайн-банкинга, автоматизацию процесса выдачи кредита – кредитный скорринг, а так же внедрение системы управления взаимодействия с клиентами – CRM. Но насколько данные решения позволяют повысить эффективность банковской организации? Системы сами по себе позволяют добиться сокращения издержек на отдельном участке работы, повысить обороты на другом участке, но при этом эффективность банка в целом остается на прежнем уровне, а в некоторых случаях может и снижаться. Рассмотрим простой пример – вы внедряете скоринговую систему, позволяющую увеличить количество и скорость выдаваемых кредитов в пять раз. Для коммерческого подразделения банка это безусловный плюс, но, при этом, фронт-офисная система может не справляться с возросшими объемами, что негативно скажется на обслуживании клиентов. В долгосрочной перспективе внедрение скорринговой системы без пересмотра всех бизнес процессов банка может вылиться в увеличение просрочки по кредитам, снижение качества активов и, как крайний исход, привести к банкротству банка. Для качественного внедрения любой автоматизированной системы и при принятии любого решения относительно оптимизации численности персонала стоит в первую очередь обратить внимание на бизнес процессы организации – банка. И тут есть три основных этапа: 1. Описание бизнес процессов; 2. Оптимизация бизнес процессов; 3. Управление бизнес процессами.

Описание бизнес процессов

Прежде чем начинать рисовать архитектуру решения, строить UML диаграммы, надо понять, чем все-таки занимается то подразделение, которое мы собираемся автоматиANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

49

Владимир Ковешников зировать, на уровне основных целей (задач) подразделения. Когда описаны основные задачи, выполняемые внутри подразделения, необходимо перейти к анализу взаимосвязей с другими подразделениями организации. Полностью описанный бизнес процесс можно задокументировать и использовать в дальнейшем для работы. Плюсы в том, что облегчается ввод в процесс новых сотрудников, и облегчается контроль над исполнителями. Так же мы получаем выигрыш в скорости исполнения той или иной задачи, так как она может распределяться напрямую на исполнителя и передаваться следующему исполнителю в цепочке, минуя руководство и сторонний персонал. То есть снижается необходимое количество вовлеченных в процесс людей, за счет исключения людей, не приносящих дополнительного результата. Так как процесс становится описанным и прозрачным в исполнении, отпадает необходимость в прямом руководстве на каждом из его этапов. На практике для описания процессов нам всегда поможет нотация BPMN 2.0. Ее плюс это понятность как бизнес пользователям, так и людям, занимающимся автоматизацией.

Оптимизация бизнес процессов

Оптимизация – очень важный участок работы. Когда процесс описан, можно начать определение основных болевых точек – проблем. Обычно это делается методами VOC (Voice Of Client) и VOB (Voice Of Business) – голоса клиентов и бизнеса. Когда мы обозначили проблему, можно перейти к этапу измерения процесса – определению количественных и хронометрических показателей, и локализации данной проблемы на конкретном участке. То есть мы определяем конкретный участок в процессе, а далее анализируем его и проводим работы по его совершенствованию. После этого применяем изменения на практике и наблюдаем за повышением производительности или качества обслуживания, а так же смотрим, чтобы не пострадали остальные элементы процесса. Непрерывность данного действия является залогом успешно развивающегося и конкурентоспособного бизнеса. На помощь приходит LEAN1 методология и реализация DMAIC2 проектов.

Управление бизнес процессами

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

50

Управление процессами в компании – показатель зрелости бизнеса. Тут есть две составляющие. Первая – контроль и учет всех описанных бизнес процессов предприятия, ведение системы учета изменений (версионность процессов). Вторая составляющая – внедрение автоматизированной системы управлением бизнес процессами. Современная система класса BPM позволяет не только отслеживать бизнес процессы предприятия и вести их учет, но и позволяет в режиме реального времени производить изменения в процессах. Колоссальные возможности по изменению бизнес логики в масштабах предприятия, требующие минимальных временных затрат. Возможность ежедневно получать актуальную информацию по метрикам и данные для расчета показателей эффективности - это лишь малая часть тех преимуществ, которые получает бизнес. Какие трудности могут встретиться при анализе банковских процессов и, в частности, при последующем внедрении какой-либо ИТ-системы? Необходимо всегда помнить, что банк представляет собой набор из равноправных блоков, руководство которых формирует правление банка. Во главе правления стоит председатель правления и важно отметить, что он не наделен полномочиями принятия решения, как генеральный директор компании. Все органы управления в банке представляют собой коллегии с равными голосами от каждого участника коллегии. Любой крупный банковский проект утверждается на правлении банка. Если проект зародился в недрах какого-то блока без утверждения на правлении, то велика вероятность сопротивления при его внедрении со стороны сторонних блоков. Конечно, это не касается проектов по автоматизации звонков в колл-центре, но, как только мы интегрируем колл-центр с CRM системой малого бизнеса, у нас сразу появится масса проблем, и в результате проект может оказаться не реализованным вовсе. На практике встречаются проекты, на внедрение которых было потрачено до пяти лет, и они так и не были реализованы. Это говорит о том, что очень часто мы преRUSSIAN IT BUSINESS ANALYSIS

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

1 LEAN 2 DMAIC

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

51

ANALY SS

T

IAN IT B SS

RA

B

USINE

52

S RU SI

RUSSIAN IT BUSINESS ANALYSIS

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

53

ANALY SS

T

IAN IT B SS

RA

B

USINE

54

S RU SI

RUSSIAN IT BUSINESS ANALYSIS

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

55

Планирование содержания первичного интервью с заказчиком Сергей Пюннинен

Планирование содержания первичного интервью с заказчиком В статье рассматриваются рекомендуемые подходы к формированию содержательной части интервью с заказчиком, проводимого в ходе первичного бизнес-анализа Сергей Пюннинен Бизнес-аналитик

С

егодня мы поговорим о тех проектах, которые имеют на входе минимум информации, начинаясь, как правило, с абстрактного волеизъявления заказчика: «я хочу, чтобы у нас было нечто ...», и о первых шагах бизнес аналитика по превращению абстрактных представлений заказчика в конкретное техническое задание. Существует расхожая фраза, о том, что участие в проекте - это бег с препятствиями. И первый барьер, который встает на пути бизнес-аналитика, можно охарактеризовать вопросом: «С чего начать?». Методология BABOK дает однозначный ответ на данный вопрос – начинать следует с планирования. Объектом планирования и отправной точкой в извлечении бизнес-потребностей заказчика станет, в нашем случае, первичное интервью с заказчиком. Четкое представление о структуре необходимой аналитику входной информации, позволит не только минимизировать усилия аналитика по её извлечению, но и повысит профессионально-доверительный уровень во взаимоотношениях с заказчиком. Начинающие аналитики часто подвержены соблазну полагаться на импровизацию при проведении первичного интервью, предпочитая определяться с объемом и структурой извлекаемых знаний по ходу действия. Это отрицательно сказывается на полноте получаемых результатов, и, как следствие, возникает необходимость более частых обращений к заказчику за всевозможными мелкими уточнениями. Заказчик, при этом, негативно реагирует на постоянные отвлекающие факторы, что в свою очередь приводит к угнетению процесса коммуникаций и срыву основной задачи бизнес-анализа. Так из чего же должна состоять содержательная часть первичного интервью? Задачей первичного интервью является получение аналитиком дополнительных точек входа, достаточных для проведения дальнейшего бизнес-анализа и работы по извлечению истинных потребностей заказчика. Такими точками входа обычно являются: • цели; • задачи; • география проекта (территориальная и административная); ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

57

Сергей Пюннинен • • • • •

ресурсы и информационные потоки; информационная ёмкость системы; перечень заинтересованных сторон; список рисков; основные аспекты корпоративной культуры заказчика. Давайте, разберем вышеприведённый перечень по пунктам.

Определение цели

Цель необходимо определить как можно раньше, хотя бы в первом приближении, ведь это не просто формальность, не безликая строчка в заглавии, а стержень всей проводимой работы, своего рода компас, по которому выверяется направление на каждом из этапов бизнес-анализа. При формулировке цели, со стороны заказчика часто происходит подмена цели решением, когда вместо того, чтобы сформулировать потребность, заказчик навязывает вам доступный его пониманию способ решения. Так, например, заказчик может запросить: «Создание таблицы EXCEL на сервере, куда будут собираться данные обо всех контрагентах и сделках с ними», в то время как реальной потребностью является снижение средней стоимости заказов по тендеру за счет расширения базы поставщиков. Памятуя о том, что основная цель любого бизнеса - получение дохода, можно предложить заказчику один из следующих шаблонов формулировки цели: 1. «Минимизировать затраты на ..., за счет …», либо 2. «Повысить доходность ..., за счет …». Разумеется, возможны и иные варианты. Проверить качество формулировки цели можно путем применения к ней критериев методологии SMART [1]. В более сложных случаях, когда проблемы заказчика сформулированы менее четко, для выявления истинных потребностей заказчика и формулирования цели хорошо подходит метод построения логических деревьев [2]. Логические деревья существенно облегчают анализ причинно-следственных связей между негативными эффектами и их причинами. Это помогает сформулировать качественную цель, устраняющую причины негативных эффектов, а не их локальные проявления. Построение логических деревьев требует значительных временных ресурсов и в этом случае на первичном интервью цель формулируется предварительно, а основное внимание уделяется сбору данных о известных заказчику нежелательных эффектах. Эти данные используются в дальнейшем для построения логических деревьев и более точного формулирования проектной цели.

Декомпозиция цели на задачи

На практике часто встречается ситуация, когда в проекте обозначается несколько равноправных целей. Такая ситуация говорит о недостаточной глубине проведенного анализа, и смещения бизнес-аналитиком понятия цели с понятиями задача и(или) результат поставки. Задачи всегда являются следствием выводимым из формулировки цели. Результатами решения задач проекта, как правило, являются результаты поставки [3]. Применительно к приведенному выше примеру, задачи могут быть определены следующим образом: 1. Создание подсистемы автоматизированного сбора информации о поставщиках; 2. Создание подсистемы структурированного представления информации о поставщиках.

Определение географии проекта ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

58

География проекта представляет собой описание компонентов корпоративной среды, их терриRUSSIAN IT BUSINESS ANALYSIS

Планирование содержания первичного интервью с заказчиком ториального размещения, способов взаимодействия и структуре линейных и иерархических связей между ними. В этом разделе нужно уделить внимание следующим вопросам: • какие организации, подразделения, ЛПР будут задействованы в проекте; • где они территориально находятся; • какие каналы связи существуют между ними; • наличие линейных и иерархических связей между бизнес единицами. Сбор данных по этому разделу удобно организовать в виде матриц, таблиц и организационных диаграмм.

Схема ресурсов и информационных потоков

Для составления данной схемы нам потребуется уточнить, какими ресурсами обладают выделенные ранее бизнес-единицы. Под ресурсами здесь понимаются прежде всего оборудование, информационные системы и источники данных, а так же количество и тип имеющегося персонала. Варианты описания ресурсов и информационных потоков приведены в работе [4].

Прогноз информационной емкости системы

Определив основные направления информационных потоков и обозначив источники и приемники информации, можно переходить к оценке информационной емкости системы. Здесь следует определить виды, а так же стартовый и плановый объем циркулирующей в системе информации. Почему важно сделать это именно на этапе первичного интервью? Потому, что это один из пунктов, позволяющий определить полезную информационную мощность системы и оценить её экономическую эффективность, а значит во многом определяет дальнейшую судьбу проекта. Есть ещё три важных аспекта, которые должны стать неотъемлемой частью первичного интервью: 1. Выявление основных заинтересованных сторон проекта; 2. Создание списка рисков проекта с точки зрения заказчика; 3. Определение основных аспектов корпоративной культуры заказчика; Данные темы достаточно емки, и детальное их раскрытие заслуживает рассмотрения в рамках отдельной статьи. Следует так же отметить, что работа по планированию и подготовке первичного интервью проводится бизнес-аналитиком параллельно с иными видами подготовительной работы, такими как: поиск и анализ методических материалов, существующих систем, их аналогов и прототипов. После предварительной проработки по вышеизложенным пунктам, бизнес-аналитику необходимо будет подготовить опросник по разобранным выше по тексту направлениям, и направить его заказчику для предварительного ознакомления до проведения интервью. Надеюсь, приведенная в данной статье информация будет полезна, для построения конструктивного диалога с вашими клиентами.

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

59

Сергей Пюннинен

Список источников

Кузнецова Т. Целеполагание по правилам //Новый менеджмент. – 2007. – №. 1. Детмер У. Теория ограничений Голдратта: Системный подход к непрерывному совершенствованию /Детмер Уильям; Пер. с англ. – М.: Альпина Бизнес Букс. – 2007г. – 444С. Лич Л. Вовремя и в рамках бюджета: Управление проектами по методу критической цепи / Лоуренс Лич; Пер. с англ. — М.: Альпина Паблишерз, 2010. — 354 с. Репин В., Елиферов В. Процессный подход к управлению. Моделирование бизнес-процессов. – Litres, 2013.

ANALY SS

T

IAN IT B SS

RA

B

USINE

60

S RU SI

RUSSIAN IT BUSINESS ANALYSIS

Лаборатория системного анализа ООО «Лаборатория системного анализа», http://lab-sa.ru, +7(965)332-78-15, info@lab-sa.ru

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

Расписание

открытых

семинаров

на

IV

квартал

Основы функционального моделирования с применением вариантов использования Практика разработки технического задания на автоматизированные и информационные системы Цикл Планирование аналитических работ. Часть 1 - Контрактирование и оценка. Часть 2 - Организация обследования, сбора требований и проектирования Цикл Документарные технологии. Часть 1 - Базовые навыки создания технических и управленческих документов. Часть 2 - Методы проверки технического и управленческого текста. Часть 3. Методы организации технического и управленческого текста

2014г.

(*)

22 ноября 2014г.

29 ноября 2014г.

6 и 20 декабря 2014 г.

20 и 27 декабря 2014г. Начало 2015г.

(*) – Расписание мероприятий и регистрация на http://lab-sa.timepad.ru; с полным списком продуктов можно ознакомиться на сайте компании (http://lab-sa.ru). Компания существует с осени 2013 года. Наши клиенты: ОАО «ВНИПИгазпереработка», ЗАО «СиСофт» (ГК CSoft), ООО «Аплана. Центр разработки» (ГК «АйТи»), ЗАО «КРОК инкорпорейтед», ООО «ПрограмПарк». Наши учебные и консалтинговые продукты основаны на авторских наработках генерального директора и ведущего консультанта.

Сергей Нужненко

До ООО «ЛСА» работал в ведущих игроках на своих рынках: Лаборатория Касперского, ГК CSoft, структуры ОАО «Газпром». Консультировал и тренировал сотрудников многих компаний, в том числе ГК ЛАНИТ, Компания «Инфосистемы Джет», ОАО «АРМАДА». Докладчик на конференциях Training Labs 2009, REQ Labs 2009, Software People 2010, ЛАФ 2012 (лучший доклад). Сооснователь Школы Системного Анализа. Преподает управление проектами в НИУ ВШЭ. Автор многих статей, преимущественно размещенных на http://boatmanshome.ru ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

61

BPMN Business Process Model and Notation Christine Natschläger перевод

Наталья Желнова

BPMN (Business Process Model and Notation) BPMN является стандартом, опубликованным группой OMG, ориентированным на бизнес-аналитиков и технических разработчиков. BPMN представляет графическую нотацию, которая широко используется для моделирования процессов

Наталья Желнова, Руководитель направления в Сервионика и преподаватель МФТИ

Bведение

BPMN является стандартом, опубликованным группой OMG, ориентированным на бизнес-аналитиков и технических разработчиков. BPMN представляет графическую нотацию, которая широко используется для моделирования процессов; однако, ее спецификация очень обширна и не лишена противоречий. Для знакомства со стандартом рекомендуется выбрать заключительную редакцию BPMN 2.0, опубликованную в январе 2011 г. Онтология - формальное представление знания, она включает в себя операторы, которые определяют понятия, отношения и ограничения. Она формирует информационную модель предметной области. Онтология обеспечивает одинаковое понимание, повторное использование знаний предметной области и позволяет выполнять анализ предметной области. Поэтому для представления метамодели BPMN используется онтология.

Проблемы и цели

Спецификация BPMN 2.0 занимает более 500 страниц. Определения элементов содержатся в различных разделах (например, стартовые события (события начала процесса) описаны несколько раз в обзоре, в главах Процесс, Хореография и Семантика исполнения BPMN, а также в разделах, описывающих другие элементы, которые могут включать стартовые события). Кроме того, метамодель BPMN описывает структуру элементов и их отношений; однако, далее синтаксические правила определены в спецификации BPMN, в текстовом представлении, например: “Стартовое событие не ДОЛЖНО быть последующим элементом для потоков; у него не ДОЛЖНО быть входящих потоков”. Кроме того, спецификация BPMN местами противоречива и запутана. Например, в метамодели элемент Транзакция определяет два протокола атрибутов и метод как имеющие тип string [1, стр. 176], но в соответствующем описании упомянут и определен только метод, как имеющий тип Transaction-Method [1, стр. 180].

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

63

Наталья Желнова Все эти проблемы не только затрудняют понимание BPMN, но также и препятствуют разработке программ проверки синтаксиса. Основные цели онтологии BPMN 2.0, поэтому, определяются следующим образом: • База знаний: основная цель онтологии состоит в том, чтобы сформировать базу знаний, которая может использоваться для ознакомления с BPMN. Синтаксические правила объединены в соответствующем элементе, и каждое ограничение сопровождается полным текстом спецификации BPMN в аннотации.

• Программа проверки синтаксиса: онтология может использоваться для проверки синтаксиса, чтобы проверить конкретные модели BPMN, как описано в разделе «Проверка синтаксиса».

• Обнаружение противоречий: при определении онтологии были идентифицированы несколько противоречий –например, между диаграммой классов BPMN и XML-схемой. На настоящий момент времени, в OMG сообщили о наличии более чем 30 проблем в спецификации.

Предшествующие варианты спецификаций

В следующих двух подразделах представлены формальные спецификации BPMN, а также другие онтологии BPMN.

Формальные спецификации BPMN

Спецификация BPMN 2.0 [1] содержит метамодель, созданную для элементов BPMN в виде диаграммы классов UML, а также в виде XML-схемы. BPMN 2.0 - первый выпуск, который предоставляет такое формальное определение. Согласно [4], статический анализ моделей BPMN значительно затруднен из-за сложности языка. Отсутствие формальной семантики BPMN препятствует разработке средств проверки правильности моделей BPMN с семантической точки зрения. Поэтому в данной публикации формальная семантика BPMN соблюдается с точки зрения отображения BPMN на сети Петри. Кроме того, к моделям бизнес-процесса [7] был применен подход, который определяет синтаксис визуального языка через синтаксис направленного графа. Дальнейший подход определяет динамическую семантику базовых понятий моделирования процесса в BPMN с точки зрения абстрактных конечных автоматов (ASMs) [6]. Этот подход может использоваться для тестирования реализаций, приводимых в качестве примеров.

Онтологии BPMN

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

64

Две других опубликованных онтологии BPMN описаны ниже. Первая онтология BPMN называется sBPMN онтологией и определяет семантически расширенный BPMN [8]. Онтология разработана в SUPER project1 на основе заключительной версии BPMN 1.0. Классы соответствуют элементам BPMN и разделены на такие категории как объекты потока, соединяющие объекты, дорожки, артефакты и процессы. Онтология включает в себя 95 классов и приблизительно 50 аксиом. Вторая онтология BPMN основывается на BPMN 1.1, она представлена в работе [9]. Опять же, спецификация основывается на элементах BPMN, что в результате сводится к 95 классам, 108 свойствам объектов, 70 свойствам данных и 439 аксиомам класса. Элементы разделены на две категории – вспомогательные элементы и графические элементы, последняя категория далее реализована в следующих объектах: объект потока, объект соединения, дорожка и артефакт. В последующих публикациях, например [10], эту онтологию вызывают BPMNO. Согласно [9], онтология не содержит описание всех свойств, включенных в спецификацию BPMN, так как некоторые свойства описывают поведение при выполнении процесса, и другие не могут быть определены на основе известных ограничений в средствах OWL (например, значения по умолчанию). BPMNO также не предназначена для моделирования динамического поведения схем (т.е. того, как поток выполняется в процессе) [10]. Эти ограничения также применяются к онтологии BPMN 2.0, рассматриваемой в этой статье.

BPMNO был адаптирован к BPMN 1.2 авторами работы [11]. Обе онтологии, sBPMN и BPMNO, основываются на предыдущих версиях BPMN, и классы, главным RUSSIAN IT BUSINESS ANALYSIS

BPMN (Business Process Model and Notation) образом, определены для конкретных элементов BPMN. Онтология BPMN 2.0, однако, основывается на метамодели BPMN, что приводит к расширенной структуре онтологии, которая лучше отражает спецификацию BPMN.

Онтология BPMN 2.0

В данном разделе представлена онтология BPMN 2.0, которая основывается на спецификации BPMN 2.0 (ее заключительном выпуске, датированном январем 2011 г.) и разработана на основе языка Web Ontology Language (OWL) с использованием редактора онтологии с открытым исходным кодом Protégé (см. [13]). Онтология BPMN 2.0 разделена на две составные части (подонтологии); первая из этих частей называется bpmn20base, она представлена в разделе «Основная онтология BPMN 2.0 (bpmn20base)». Эта онтология содержит только спецификации, взятые из метамодели BPMN, включая все диаграммы классов, таблицы, определяющие атрибуты, и связи модели, а также XML-схемы. Вторая подонтология называется bpmn20; она представлена в разделе «Расширенная онтология BPMN 2.0 (bpmn20)». Она получена из первой онтологии и представляет собой ее расширение. Онтология bpmn20 содержит почти все синтаксические требования, которые описаны в спецификации BPMN. Она может усовершенствовать наследуемые ограничения без их изменения. Кроме того, она содержит некоторые новые классы (например, подклассы класса SubProcess), которые описаны в разделе «Расширенная онтология BPMN 2.0 (bpmn20)». Вместе эти две онтологии создают онтологию BPMN 2.0, которая представлена в разделе «Онтология BPMN 2.0 (bpmn20base и bpmn20)». Наконец, некоторые комментарии приведены в разделе «Дальнейшие замечания».

Основная онтология BPMN 2.0 (bpmn20base)

Онтология bpmn20base основывается на спецификации метамодели BPMN, включая все диаграммы классов, таблицы, определяющие атрибуты и связи, а также XML-схемы. Каждый элемент BPMN вставлен как класс; полная иерархия показана на Рис. 5. Некоторые элементы показаны дважды, так как в метамодели BPMN используется множественное наследование и, поэтому, оно также представлено в онтологии (например, SubProcess получен из Activity и FlowElementsContainer (см.

[1, стр. 176])). Определение иерархии было сложным, так как некоторые наследования явно не описаны в диаграмме классов BPMN. Суперклассы иногда только упоминаются в тексте спецификации, в XML-схеме, а в случае InteractionNode суперкласс не описан вообще (предполагалось, что он должен быть получен из BaseElement). Тем не менее, возможно определить иерархию, которая соответствует метамодели BPMN. Различные подклассы определены таким образом, чтобы они были раздельными; это позволяет избежать ситуации, когда отдельные объекты могли бы быть экземплярами нескольких классов (например, подкласс ExclusiveGateway – раздельный, отделенный от Event-BasedGateway, ComplexGateway, InclusiveGateway и ParallelGateway). Кроме того, метамодель BPMN определяет пакеты для классов. Однако эта информация не передается при наследовании, и поэтому подклассы одного класса могут содержаться в различных пакетах. Поэтому такая информация не может храниться в ограничении; вместо этого используется аннотация, как показано на рисунке 1.

Рисунок 1. Аннотация класса SubProcess После описания классов в целом, определяются отношения, ограничивающие классы и определяющие подробности. Онтология поддерживает два типа отношений: 1. Свойство объекта (см. Рис. 6): Описывает отношение между двумя объектами.

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

65

Наталья Желнова 2. Свойство данных (см. Рис. 7): Описывает отношение между объектами и значениями данных. Свойства класса SubProcess показаны на рисунке 2. Артефакты свойства объекта определяют отношение между отдельными экземплярами класса SubProcess и экземплярами класса Artifact. Кроме того, свойство данных triggeredByEvent определяет отношение между экземплярами класса SubProcess, используя значения булевых данных (см. [1, стр. 176]).

Рисунок 2 Свойства класса SubProcess Каждое ограничение далее определяет допустимое число элементов в связи (множественность отношения). В онтологии bpmn20base используются следующие множественности отношений: • Exactly x: определенное число (точно x) • Min x : множественность отношения [x..n] • Max x : множественность отношения [0..x ] В некоторых случаях ограничение на количество элементов бывает усилено в подклассах (например, увеличена минимальная граница, или уменьшена максимальная граница). Множественность типа [x. y] не используется в онтологии bpmn20base, но для реализация такой множественности потребовалось бы два ограничения. Спецификация BPMN далее определяет атрибуты экземпляра для некоторых элементов BPMN (например, у элемента Proces есть состояние атрибута экземпляра (см. [1, стр. 149])). В онтологии трудно различить собственно атрибуты и атрибуты экземпляра, поскольку для определения отношения используются одни и те же свойства объектов и данных. Поэтому было создано свойство аннотации, instanceAttribute, для которого установлено значение по умолчанию «yes» для каждого атрибута экземпляра, как показано на рисунке 3.

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

66

Рисунок 3 Аннотации для атрибута экземпляра state Спецификация BPMN также предусматривает значения по умолчанию (например, у состояния атрибута экземпляра есть значение по умолчанию None). Эти значения по умолчанию невозможно определить в монотонном OWL. Поэтому, в bpmn20base значения по умолчанию для онтологии RUSSIAN IT BUSINESS ANALYSIS

BPMN (Business Process Model and Notation) определены свойством аннотации defaultValue, как показано на рисунке 3. Альтернативный подход для немонотонного рассуждения на основе логики умолчания Рейтера предложен в [12]; он поддерживает значения свойств по умолчанию, а также неуказанную версию предположения о замкнутости мира. Четвертое и последнее свойство аннотации называется bpmnSpecification; оно включает соответствующее определение из спецификации BPMN для каждого атрибута и отношения (см. Рис. 3). В онтологии bpmn20base текст берется из столбца описания/использования соответствующих атрибутов и таблицы ассоциаций модели. В онтологии bpmn20 также определены синтаксические требования, и текст для аннотации взят из текста спецификации BPMN. В обоих случаях это свойство аннотации очень важно, так как оно позволяет использовать онтологию BPMN 2.0 как базу знаний. Если описания элементов BPMN содержатся во всей спецификации BPMN, то описания онтологии объединены в одном классе, и дальнейшие разъяснения представлены в аннотации. Это позволяет быстрее понять назначение элемента BPMN.

Расширенная онтология BPMN 2.0 (bpmn20)

Онтология bpmn20 основывается на онтологии bpmn20base и представляет ее расширение. Она содержит расширенные синтаксические требования, которые взяты из текста спецификации BPMN. Поэтому онтология bpmn20 добавляет новые или изменяет существующие классы и ограничения, но не изменяет и не удаляет их. Конечная цель состоит в том, чтобы онтология BPMN 2.0 использоваталсь как база знаний практически для всех синтаксических правил спецификации BPMN.

Дополнительные классы:

следующие дополнительные классы были добавлены к онтологии bpmn20, на основании текста спецификации BPMN: • Свернутые/развернутые классы (подробное описание приведено далее); • Подклассы SequenceFlow: SequenceFlowConditional, SequenceFlowDefault и SequenceFlowNormal; • PublicProcess и PrivateProcess (с соответствующими подклассами); • EmbeddedSubProcess и EventSubProcess, являющиеся подклассами SubProcess (подробное описание приведено далее); • AbstractTask, являющийся подклассом Task; • Подклассы Gateway, определяющие направление; • ExclusiveEventBasedGateway и ParallelEventBasedGateway, являющиеся подклассами EventBasedGateway; • Насколько подклассов Event, представляющие собой маркеры со своими подклассами, служащие для обозначения прерывания/не прерывания событий; • Подклассы StartEvent: StartEventEventSubProcess (StartEvent – стартовое событие EventSubProcess) и StartEventNotEventSubProcess (StartEvent - стартовое событие не EventSubProcess); • EventMarkerEnumeration, TransactionResultEnumeration и MarkerEnumeration – перечисления, описанные далее. Свернутые/Раскрытые классы: три элемента BPMN могут быть свернуты или расширены, а именно, SubProcess, SubChoreography и SubConversation. Для свернутого представления отображается CollapsedMarker, а развернутое представление показывает детали элемента, а не маркер CollapsedMarker. Два подкласса определены таким образом, чтобы они не пересекались друг с другом, однако они не являются раздельными по отношению к другим подклассам (например, конкретный SubProcess может быть свернут и при этом являться элементом Transaction). Например, у класса CollapsedSubProcess есть два необходимых условия:

base:SubProcess

hasMarker exactly 1 CollapsedMarker

Первое ограничение указывает, что класс CollapsedSubProcess является подклассом SubProcess. Второе ограничение определяет, что у него должен быть точно один маркер сворачивания ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

67

Наталья Желнова CollapsedMarker. Это ограничение отличается от ограничения из развернутого класса, так как у развернутых классов нет маркера сворачивания CollapsedMarker. Эти два ограничения вместе являются вполне достаточными. И поскольку классы определяют необходимые и достаточные условия, их называют определенными классами (Defined Classes). Другие классы (CallActivity, CallChoreography и CallConversation) иногда также отображаются с маркером CollapsedMarker. Однако эти классы вызывают другие элементы и только выводят на экран маркеры вызванного элемента. Если они вызывают, например, GlobalTask, то операции сворачивания или разворачивания вообще невозможны.

SubProcess: если рассматривать подклассы SubProcess, то метамодель BPMN включает два таких подкласса (AdHocSubProcess и Transaction) (см. [1, стр. 176]), тогда как в тексте спецификации упоминаются пять различных типов (EmbeddedSubProcess, CallActivity, EventSubProcess, Transaction и AdHocSubProcess) (см. [1, 173-183]). CallActivity соответствует повторно используемому подпроцессу (Reusable SubProcess) в BPMN 1.2, а в текущей реализации наследуется от Activity и, поэтому, является одноуровневым элементом для SubProcess. Однако остается открытым вопрос, почему EmbeddedSubProcess и EventSubProcess не были определены как подклассы в метамодели BPMN и должны ли они быть определены как подклассы или же нет. В первую очередь, класс SubProcess определяет следующее ограничение (см. [1, стр. 176]):

base:triggeredByEvent exactly 1 xsd:boolean

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

68

Свойство данных triggeredByEvent служит флагом. Если для него установлено значение true, то в этом случае SubProcess - это EventSubProcess, в противном случае SubProcess - “нормальный” подпроцесс (EmbeddedSubProcess). Свойство данных triggeredByEvent элемента SubProcess наследуется подклассами Transactions и AdHocSubProcesses; однако, никакое ограничение не определяет, что это свойство должно принимать значение false в подклассе. Поэтому возможны следующие комбинации: • AdHocSubProcess и EmbeddedSubProcess (triggeredByEvent: false) • Transaction и EmbeddedSubProcess (triggeredByEvent: false) • AdHocSubProcess и EventSubProcess (triggeredByEvent: true) • Transaction и EventSubProcess (triggeredByEvent: true) Так как EmbeddedSubProcess представляет «нормальный» подпроцесс SubProcess, первые два перечисленных варианта сводятся к следующим двум вариантам: AdHocSubProcess и Transaction. Последние два перечисленых варианта представляют проблему. Комбинация AdHocSubProcess и EventSubProcess противоречит спецификации BPMN, поскольку AdHocSubProcess может быть частью нормального потока (см. [1, стр. 153]), а EventSubProcess не разрешают иметь входящий и исходящий элементы SequenceFlows (см. [1, стр. 176f]). Кроме того, Ad-HocSubProcess не может иметь элемент StartEvent (см. [1, стр. 182]), тогда как у каждого EventSubProcess должен быть только один элемент StartEvent (см. [1, стр. 177]). Поэтому должно быть запрещено составлять комбинации AdHocSubProcess и EventSubProcess. Комбинация элементов Transaction и EventSubProcess также невозможна из-за конфликта между интеграцией в нормальном потоке и числом элементов StartEvents. Кроме того, только элемент Transaction может иметь BoundaryEvent с маркером отмены Cancel (см. [1, стр. 255]). Поэтому автор предлагает, чтобы свойство triggeredByEvent принимало значение false для элементов Transaction и AdHocSubProcess. Кроме того, остается вопрос, должны ли EmbeddedSubProcess и EventSubProcess быть подклассами SubProcess. Можно назвать несколько доводов в пользу этого предложения: • явное/неявное объявление классов: в метамодели BPMN только два класса явные, тогда как все остальные неявные. Однако текст спецификации BPMN явно описывает все типы SubProcess как элементы, расположенные на том же уровне, что и другие элементы. Поэтому все классы должны быть явными.

• раздельные классы: эти четыре класса могут быть определены как раздельные. Это явно запреRUSSIAN IT BUSINESS ANALYSIS

BPMN (Business Process Model and Notation) щает комбинации различных типов.

• наследованные ограничения: так как ограничения наследуются, только элементы Transaction и AdHocSubProcess (но не EmbeddedSubProcess или EventSubProcess) могут изменять ограничение. Согласно спецификации BPMN, только элементы Transaction позволяют иметь события BoundaryEvent с маркером Cancel (см. [1, стр. 255]). Структура метамодели позволяет определять, что у AdHocSubProcess не должно быть события BoundaryEvent с маркером Cancel, тогда как элементы Transaction могут иметь такие события. Однако, невозможно определить, могут ли у EmbeddedSubProcess или EventSubProcess не быть события BoundaryEvent с маркером Cancel, так как оба класса описаны в классе Sub-Process. Если маркеры Cancel запрещены в суперклассе, то Transaction наследует это ограничение и не может иметь маркера Cancel.

• дальнейшие Ограничения: если используются явные подклассы, легко могут быть определены дальнейшие ограничения, которые применяются только к EventSubProcess или к EmbeddedSubProcess. Например, EmbeddedSubProcess разрешено иметь только события Start с маркером None (см. [1, стр. 241f]), тогда как у EventSubProcess не должно быть маркера None (см.

[1, стр. 177]). Если эти два элемента выражены в одном классе и их отличает только свойство данных, то ограничения становятся более сложными и требуют анализа. На основании вышеизложенных рассужданий, автор определяет EventSubProcess и EmbeddedSubProcess как подклассы SubProcess и предлагает изменение метамодели BPMN.

Дополнительные ограничения:

Помимо дополнительных классов, согласно тексту спецификации BPMN в онтологии bpmn20 были определены более 300 дополнительных ограничений для существующих классов. Ограничения класса MessageFlow показаны на рисунке 4. Обратите внимание на то, что ограничения, определенные в онтологии bpmn20, выделены полужирным шрифтом.

Рисунок 4. Ограничения MessageFlow

Онтология BPMN 2.0 (bpmn20base и bpmn20)

Онтология bpmn20base совместно с bpmn20 формируют онтологию BPMN 2.0. Иерархия онтологии BPMN 2.0, содержащая около 260 классов, разделена на два столбца и показана на рисунке 5. Некоторые классы отображаются в свернутом виде из-за пространственных ограничений. Обратите внимание на то, что классы и свойства, определенные в онтологии bpmn20base, показаны ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

69

Наталья Желнова с префиксом «base», тогда как у классов, определенных в онтологии bpmn20, префикс отсутствует. Классы, которые были созданы или расширены в онтологии bpmn20, выделены полужирным шрифтом. Кроме того, на рисунке 6 показаны некоторые из 178 свойств объектов, а на рисунке 7 - некоторые из 59 свойств данных. В дополнение к предопределенным свойствам аннотации, еще четыре свойства (bpmnSpecification, defaultValue, instanceAttribute и package,) определенные в онтологии bpmn20base, показаны на рисунке 8.

Дальнейшие замечания

В этом разделе представлены замечания к онтологиям, представление о которых дано выше. Уникальные имена и ключевые слова: в метамодели BPMN отношения с одинаковым именем используются несколько раз и представляют отношения между различными классами. Однако имена объектов и свойств данных в онтологии должны быть различными. Поэтому, объект и свойства данных с тем же именем снова используются в различных ограничениях, а домен и диапазон свойств расширен, чтобы охватить все классы. Также повторно используются в различных перечислениях классы, представляющие такие значения, как None и Both. Кроме того, класс и имена свойств «Import», «value» и «language» являются ключевыми словами в онтологии и классификатор Pellet (см. раздел «Блок логики и классификатор»), определяет некоторые дальнейшие ключевые слова. Чтобы отличить эти имена от ключевых слов, к имени добавляется точка (например: «Import.»). Ассоциация и композиция: метамодель BPMN различает различные типы отношений: ассоциации и композиции. Это различие не нашло отражения в онтологии, несмотря на то, что в большинстве случаев различные типы также влияют на количество элементов (например, отношения композиции обычно имеют количество элементов 1 или (0.. 1) на исходной стороне, в то время как у ассоциаций часто определяется количество элементов (*) с обеих сторон). Подход, используемый для выражения отношений «является частью» в онтологии, описан в [14]. Импликация: Некоторые синтаксические требования включают импликацию (например, если SequenceFlow наследуется от StartEvent, то свойство conditionExpression не должно принимать значение None [1, стр. 245]). OWL обеспечивает только конструкции для выражения пересечения (И), объединения (ИЛИ) и дополнения (НЕ), однако, импликация (→ B) может быть выражена объединением и дополнением: ¬A ∨ B. Это альтернативное представление используется в онтологии в нескольких местах. Открытые синтаксические ограничения: Почти все синтаксические правила определены в онтологии. Единственные исключения - синтаксические правила с неразрешенными вопросами или правила, которые имеют сложные зависимости от других элементов. Например, для требования “Инициатор действия в хореографии ДОЛЖЕН БЫЛ быть включен... в предыдущие действия хореографии”. [1, стр. 336] недостаточно определить источник входящего элемента SequenceFlow, так как могут быть определены промежуточные шлюзы и события. Вместо этого может быть определено новое свойство объекта previousChoreographyActivity; однако, значение свойства не может быть определено автоматически.

ANALY SS

T

IAN IT B SS

RA

B

USINE

70

S RU SI

RUSSIAN IT BUSINESS ANALYSIS

BPMN (Business Process Model and Notation)

Рисунок 5. Иерархия классов онтологии BPMN 2.0 ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

71

Наталья Желнова

Рисунок 6. Свойства объекта

Рисунок 7. Свойства данных

Рисунок 8. Свойства аннотации

Тем не менее, большинство правил, которые зависят от других элементов, может быть определено, например, так: “У целевых элементов в конфигурации шлюза события не ДОЛЖНО быть дополнительных входящих потоков...” [1, стр. 298]. Это правило может быть выражено следующим ограничением для EventBasedGateway:

base:outgoing only (base:targetRef only

(base:incoming exactly 1 base:SequenceFlow))) Противоречия в спецификации BPMN: При рассмотрении онтологии BPMN 2.0 были найдены несколько противоречий в спецификации BPMN. На настоящий момент в OMG сообщено о существовании более 30 проблем. Далее приведено несколько примеров: • Как видно из диаграммы классов, у InteractionNode есть четыре подкласса: Participant, ConversationNode, Task и Event (см. [1, стр. 122]). Однако в тексте спецификации упоминается подкласс Activity, а не подкласс Task (см. [1, стр. 123]), и правила соединения для элемента MessageFlow позволяют соединять его с элементом SubProcess (см. [1, стр. 44]) (подклассом Activity).

• Как видно из диаграммы классов, StandardLoopCharacteristics определяет отношение к Expression, называемое loopMaximum (см. [1, стр. 189]). Однако в соответствующем описании атрибута мы видим, что loopMaximum определен как атрибут, имеющий тип integer (см. [1, стр. 191]).

• Согласно диаграмме классов, элемент Collaboration ссылается на 1 элемент ConversationAssociation, но в соответствующем описании модели, множественность отношения определена как [0.. n] (см. [1, стр. 109f]).

Оценка

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

72

При оценке непротиворечивости и правильности онтологий использовались два различных метода. Во-первых, чтобы проверить онтологии bpmn20base и bpmn20, использовались несколько различных классификаторов (они описаны в разделе «Блок логики и классификатор»). Кроме того, RUSSIAN IT BUSINESS ANALYSIS

BPMN (Business Process Model and Notation) конкретные модели BPMN проверялись согласно правилам онтологии (они представлены в разделе «Проверка синтаксиса»). Рассмотрение нерешенных вопросов и противоречий, а также доказательство полноты онтологий в настоящее время невозможно. Однако автор данной статьи несколько раз просмотрел всю спецификацию BPMN, чтобы создать практически полную онтологию BPMN 2.0.

Блок логики и классификатор

Блок логики или классификатор используется для проверки согласованности модели, а также позволяет получить полную иерархию классов. Класс в онтологии считается согласованным, если у него могут иметься экземпляры, в противном случае он не считается согласованным. Для проверки онтологии BPMN 2.0 использовались следующие три классификатора: • FaCT ++, классификатор OWL-DL, и лицензирован по GNU Public License (GPL). Он реализован с использованием C++ [15].

• Pellet - OWL 2-классификатор с открытым исходным кодом, реализованный на Java [16]. Pellet также поддерживает некоторые варианты проверки, которая требуется для одного из примеров, рассматриваемых в разделе «Проверка синтаксиса».

• HermiT 1.2.4 - OWL 2-класссификатор, совместимый с Java. HermiT лицензируется под GNU Lesser General Public License (LGPL) и предварительно установлен в Protégé [17]. Онтология прошла проверку на корректность во всех этих трех инструментах.

Проверка синтаксиса

В дополнение к проверке корректности с помощью классификаторов, для проверки синтаксиса используется онтология BPMN 2.0, и конкретные модели BPMN проверены с помощью онтологии BPMN 2.0. Поэтому для каждого примера созданы новые онтологии, полученные на основании онтологии bpmn20. В этих трех примерах показаны корректная, неправильная и неполная модели. Более сложные примеры проверяются аналогично, но создание онтологии модели и проверка требует больших усилий. Программа проверки синтаксиса будет дополнена графическим инструментом, как описано в разделе 6. Главное преимущество онтологии - возможность сделать выводы, как показано в первом примере. Если можно прийти к заключению, что элемент типа A на самом деле должен быть элементом подтипа B, то можно проверить, выполняет ли элемент ограничения, определенные данным подтипом. Пример 1: первый пример состоит из одного начального события StartEvent, одного конечного события EndEvent, двух элементов SequenceFlow и одного элемента Task как показано на рисунке 9. Экземпляры одного и того же класса (например, экземпляры SequenceFlow) определены, чтобы представлять различные объекты. Для всех элементов определен идентификатор свойства данных, объекты Activity далее определяют имя, и для свойства isInterrupting объекта Event установлено значение true. Относительно свойств объектов, все элементы SequenceFlow определяют sourceRef и targetRef, и элементы Activity определяют входящий и исходящий потоки (SequenceFlow). В этом случае модель объявляется корректной. Обратите внимание на то, что на основе соглашения по нотации не нужно определять все обязательные свойства (например, класс Activity определяет некоторые дальнейшие обязательные свойства, такие как isForCompensation или startQuantity, которые не были изначально определены для этого примера). Впоследствии пример был изменен, и для свойства данных isInterrupting StartEvent установлено значение false. Так как только EventSubProcesses разрешают иметь StartEvents без (свойство noninterrupting) (см [1, стр. 242ff]), классификатор автоматически приходит к заключению, что элемент StartEvent должен иметь тип StartEventEventSubProcess как показано на рисунке 12. Однако, если мы определяем, что StartEvent имеет тип StartEvent-NotEventSubProcess, тогда все классификаторы сообщают о некорректности онтологии.

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

73

Наталья Желнова

Рисунок 9. Пример 1

Рисунок 10. Пример 2

Рисунок 11. Пример 3

Пример 2: второй пример включает EventSubProcess как показано на рисунке 10. EventSubProcess определяет свойства данных id, name и triggeredByEvent; для свойства triggeredByEvent устанавливается значение true. Кроме того, определены входящий и исходящий элементы SequenceFlows. Эта модель BPMN некорректна, так как EventSubProcess не может иметь входящий или исходящий элементы SequenceFlow (см. [1, стр. 176f]). Онтология классифицирована как неправильная всеми классификаторами. Пример 3: в третьем примере элемент Gateway добавлен между двумя элементами SequenceFlow, как показано на рисунке 11. Эта модель неполная, так как элемент Gateway имеет только один входящий и один исходящий элемент SequenceFlow, в то время как он должен иметь по крайней мере два входящих или по крайней мере два исходящих элемента SequenceFlow (см. [1, стр. 290]):

(base:incoming min 2 base:SequenceFlow)

или (base:outgoing min 2 base:SequenceFlow)

На первом шаге несоответствие не может быть обнаружено путем открытого рассуждения, так как у элемента Gateway могли бы быть дальнейшее неуказанное входящий или исходящий элемент SequenceFlow. Эта проблема разрешима закрытым рассуждением, как описано в работе [16] для классификатора Pellet. Класс owl:Thing должен быть эквивалентен перечислению всех известных экземпляров как показано на рисунке 13, и необходимо определить отрицательные утверждения для всех логических элементов, которые определенно не являются истинными, как показано на рисунке 14. В конечном итоге, онтология противоречит всем логическим построениям.

Рисунок 12. Предполагаемые элементы

Заключение

Рисунок 14. Отрицательные утверждения

This paper described the development of two ontologies that formally represent the BPMN 2.0 specification. The bpmn20base ontology is based on the BPMN metamodel and the bpmn20 ontology contains further syntactical requirements taken from the natural text of the BPMN specification. Together, the two ontologies form the BPMN 2.0 Ontology. This ontology can be used as a knowledge base, since the descriptions are combined within the corresponding class and further explanations are provided in annotations. This allows a much faster understanding of BPMN. In addition, the ontology can be used as a syntax checker. Finally, three different reasoners prove the consistency of the ontology. В данной статье рассматриваются две онтологии, которые формально представляют спецификацию BPMN 2.0. Онтология bpmn20base основана на метамодели BPMN; онтология bpmn20 содержит ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

74

Рисунок 13. Класс owl:Thing

RUSSIAN IT BUSINESS ANALYSIS

BPMN (Business Process Model and Notation) дальнейшие синтаксические требования, взятые из текста спецификации BPMN. Совместно, эти две онтологии формируют онтологию BPMN 2.0. Эта онтология может использоваться в качестве базы знаний, так как описания объектов объединены в соответствующих классах, и дальнейшие объяснения представлены в аннотациях. Это ускоряет понимание BPMN. Кроме того, онтология может использоваться в качестве правил для программы проверки синтаксиса. Наконец, три различных классификатора доказывают непротиворечивость онтологии. Далее: следующая цель состоит в том, чтобы автоматически генерировать базовую структуру онтологии bpmn20base из XML-схемы спецификации BPMN, поскольку XML-схема соответствует диаграмме классов UML. Кроме того, проверка синтаксиса в настоящее время требует определять конкретные модели вручную, поэтому до сих пор были реализованы только простые проверки. Таким образом, другая цель состоит в том, чтобы расширить программу проверки синтаксиса с помощью графического инструмента (например, средства моделирования BPMN для Eclipse [18]), и автоматически проверять модель по онтологии. С этой целью может использоваться платформа Jena Semantic Web, как предложено в [2]. Благодарности. Проект Vertical Model Integration поддерживается программой «Regionale Wettbewerbsfähigkeit OÖ 2007-2013» фонда European Fund for Regional Development, а также штатом Верхняя Австрия.

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

75

Наталья Желнова Ссылки

1. Business Process Model and Notation (BPMN) 2.0, www.omg.org/spec/BPMN/2.0 2. Hebeler, J., Fisher, M., Blace, R., Perez-Lopez, A.: Semantic Web Programming. Wiley Publishing (2009) 3. Noy, N., McGuinness, D.: Ontology Development 101: A Guide to Creating Your First Ontology. Stanford Knowledge Systems Laboratory Technical Report KSL-01-05 and Stanford Medical Informatics Technical Report SMI-2001-0880 (2001) 4. Dijkman, R., Dumas, M., Ouyang, C.: Formal semantics and automated analysis of BPMN process models.

Technical Report (2007) 5. Wong, P.Y.H., Gibbons, J.: A Process Semantics for BPMN. In: Liu, S., Araki, K. (eds.) ICFEM 2008. LNCS, vol. 5256, стр. 355–374. Springer, Heidelberg (2008) 6. Börger, E., Sörensen, O.: BPMN Core Modeling Concepts: Inheritance-Based Execution Semantics. In: Handbook of Conceptual Modelling. Springer, Heidelberg (2010) 7. Mazanek, S., Minas, M.: Business Process Models as a Showcase for Syntax-Based Assistance in Diagram Editors. In: Schürr, A., Selic, B. (eds.) MODELS 2009. LNCS, vol. 5795, стр. 322–336. Springer, Heidelberg (2009) 8. Abramowicz, W., Filipowska, A., Kaczmarek, M., Kaczmarek, T.: Semantically enhanced Business Process Modelling Notation. In: Work. on Semantic Business Process and Product Lifecycle Management, SBPM (2007) 9. Ghidini, C., Rospocher, M., Serafini, L.: A formalisation of BPMN in Description Logics. Published as: Technical Report TR 2008-06-004, FBK-irst (2008), https://dkm.fbk.eu/images/3/35/-3631-_ BPMNOntology.pdf 10. Di Francescomarino, C., Ghidini, C., Rospocher, M., Serafini, L., Tonella, P.: Reasoning on Semantically Annotated Processes. In: Bouguettaya, A., Krueger, I., Margaria, T. (eds.) ICSOC 2008. LNCS, vol. 5364, стр.

132–146. Springer, Heidelberg (2008) 11. Zur Muehlen, M., et al.: BPM Research Forums - Process Modeling, www.bpm-research.com/forum/ index.php?showtopic=502 (visited February 2011) 12. Kolovski, V., Parsia, B., Katz, Y.: Implementing OWL Defaults. In: Workshop on OWL: Experiences and Directions (2006) 13. Prot´eg´e, http://protege.stanford.edu (visited February 2011) 14. Aitken, J.S., Webber, B.L., Bard, J.B.L.: Part-of Relations in Anatomy Ontologies: A Proposal for RDFS and OWL Formalisations. In: Pacific Symposium on Biocomputing (2004) 15. FaCT++, http://owl.man.ac.uk/factplusplus (visited February 2011) 16. Pellet, http://clarkparsia.com/pellet (visited February 2011) 17. HermiT 1.2.4, http://hermit-reasoner.com (visited February 2011) 18. BPMN Modeler, www.eclipse.org/bpmn (visited February 2011)

ANALY SS

T

IAN IT B SS

RA

B

USINE

76

S RU SI

RUSSIAN IT BUSINESS ANALYSIS

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

77

Опыт использования объектно ориентированного подхода в Бизнес Анализе Александр Белин

Объектно ориентированный подход в Бизнес Анализе Данная статья является транскрипцией доклада, с которым автор выступал на Летнем Аналитическом Фестивале в 2013 году Александр Белин Бизнес Аналитик

В

первую очередь я хочу в двух словах объяснить, чего мне хотелось добиться, о чем рассказать в своем докладе. Мы все очень любим истории с хорошим концом. Например: «Мы создали свою собственную систему управления требованиями. Ура!». Или: «Мы очень долго имели проблемы с заказчиком. Мы прочитали интересную статью, нашли уникальный метод, применили этот метод и у нас все пошло здорово. Ура!» Но, к сожалению, часто по окончании таких докладов единственное, что мы можем вынести - это чувство радости за докладчика. Ситуации, которые описал докладчик, слишком экзотичны, у нас не возникает и не возникнут такие ситуации. Опыт, который описал докладчик, мы не можем применить в своей практике, он невоспроизводим в наших условиях и для нас он бесполезен. Поэтому в процессе подготовки доклада я постарался описать тот опыт, который мы используем в наших проектах, опыт, который с большой долей вероятности может быть воспроизведен в вашей повседневной практике. Это те рекомендации, которые вы могли бы просто распечатать в виде справочника, положить на стол и использовать для вашей повседневной деятельности. На кого рассчитан данный доклад? Мой доклад рассчитан на людей, у которых в рабочем процессе возникают следующие вопросы или ситуации: • каждый раз, когда заканчивается очередной этап нашей работы, или мы заканчиваем разработку некоторого промежуточного артефакта, мы испытываем растерянность: а, что делать дальше?; • мы хотим работать, но не знаем, как это делать правильно; • я руковожу группой аналитиков. Что им сказать? Как построить их работу? Как объяснить, что сделано правильно, а что неправильно? Каков критерий этой оценки?; • передо мной сидит представитель заказчика, который готов вывалить на меня тонны информации о своем бизнесе. Как не позволить ему утопить меня в болоте его пространных рассуждений о бизнесе? Как провести заказчика по тому пути, коANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

79

Александр Белин торый выгоден для нас, для нашего бизнеса, для нашего проекта; для того, чтобы получить и правильную информацию, необходимую для нашего проекта? Выходом может быть сценарий, который позволит вам шаг за шагом последовательно разработать некую систему моделей, каждая из которых сама по себе: является самодостаточным и законченным артефактом, расширяющим ваше понимание бизнеса заказчика; является основой для разработки последующих моделей, входящих в данный сценарий. Это означает, что при разработке очередной модели вам не нужно проводить полномасштабное исследование. Вы используете знания, полученные на предыдущем шаге при разработке предыдущей модели, расширяете эти знания и получаете новую модель, новые знания. Этот сценарий позволит вам, во-первых, лучше понять бизнес заказчика, и, во-вторых, разрабатывая каждую новую модель вы имеете возможность: Согласовать эту модель (ваше понимание) с заказчиком; Предоставить готовую модель разработчикам. Таим образом все модели, которые будут разработаны даже на этапе бизнес-анализа, будут полезны разработчикам, и разработчики смогут этой информацией пользоваться. Для начала я попытался проанализировать две ситуации, которые мы имели или имеем в IT- проектах. Первая ситуация – это ситуация, когда разработка велась с полным отсутствием аналитиков в команде, или полным отсутствием анализа в проекте. Т.е. это ситуация, когда ни заказчик, ни проектная команда не готовы тратить время на проведение какого-либо анализа. У этой ситуации, безусловно, были свои плюсы (см. Рис. 1). Подобные ситуации продолжают иметь место, например, в проектах, проводимым с использованием подходов из семейства Agile.

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

80

Рис. 1. Пожелания в разработку. Отсутствие анализа. Плюсы Но, помимо плюсов, данная ситуация, безусловно, доставляла большое количество проблем, или RUSSIAN IT BUSINESS ANALYSIS

Объектно ориентированный подход в Бизнес Анализе рисков. Краткий анализ рисков ситуации полного отсутствия анализа в проекте приведен на Рис. 2

Рис. 2. Пожелания в разработку. Отсутствие анализа. Минусы Вторая ситуация более традиционна для нашего времени - в проектной команде есть системные аналитики, т.е. люди, которые пишут требования. Данная ситуация характеризуется наличием системного анализа, но в проекте по-прежнему нет понимания необходимости и не проводится бизнес анализ. Естественно, данная ситуация решает большое количество проблем из перечисленных для первой ситуации (см. Рис.3). Но, тем не менее, из-за отсутствия полноценного бизнес анализа, данные проекты потенциально могут содержать серьезные риски. Достаточно общий анализ таких рисков приведен на Рис. 4. Для каждой из ситуаций присущи собственные плюсы и минусы. Например, очевидный минус первой ситуации в том, что, если мы не включаем в проектный цикл этап бизнес-анализа, то у нас нет понимания того, каков на самом деле бизнес заказчика, нет систематизированных и полных знаний о той области, которую мы должны автоматизировать. Естественно, когда к нам приходит заказчик - мы не автоматизируем весь его бизнес полностью, а на основании его слов выделяем какую-то область и уже в ней выделяем процессы, которые автоматизируем. Для этого мы должны изучить и эту часть бизнеса, и смежные, чтоб представлять себе полную картину. Чтоб избежать типичных минусов, необходимо провести полноценный бизнес-анализ. Что нам позволит проведение этого анализа?

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

81

Александр Белин

Рис. 3 Наличие системного анализа. Отсутствие бизнес анализа. Плюсы

Рис. 4. Наличие системного анализа. Отсутствие бизнес анализа. Минусы

ANALY SS

T

IAN IT B SS

RA

B

USINE

82

S RU SI

RUSSIAN IT BUSINESS ANALYSIS

Объектно ориентированный подход в Бизнес Анализе Во-первых, (см. Рис. 5): на этапе бизнес анализа (БА) у нас есть возможность этот бизнес изучить. Для чего мы это делаем? Это не просто отвлеченное исследование ради интереса. Естественно, мы это делаем в интересах нашего проекта. Поэтому… Во-вторых, у нас есть возможность — это понимание задокументировать либо в виде текстового описания, либо в виде моделей. Это та польза, которую мы получаем в рамках этапа БА. Для чего мы это делаем? Мы это делаем для того, чтобы… В-третьих, понять бизнес заказчика, … В-четвертых, провести последовательную верификацию нашего понимания. Как я уже указывал выше, каждая последующая модель содержит в себе какие-то знания, которые мы получили на предыдущем этапе. И, поскольку, результат предыдущего этапа был проверен и согласован с заказчиком, то следующая модель содержит в себе уже значительную часть утвержденных знаний. И нам лишь необходимо добавить новые знания к предыдущей модели и согласовать новое понимание с заказчиком.

Рис. 5. Выход из ситуации. Проведение полноценного бизнес-анализа Таким образом, мы последовательно расширяем наши знания о бизнесе заказчика, пошагово, постепенно углубляем наши знания и создаем набор моделей, которые доступны не только для обсуждения с заказчиком, но уже готовы для использования разработчиками. Я предлагаю некий сценарий (roadmap), который последовательно, шаг за шагом позволит нам систематизировано провести этап БА, и на каждом этапе получать какую-то значимую, с точки зрения нашего проекта, модель. На чем основывается данный сценарий? На каком документе? Это документ «Описание Бизнеса». Сложно ли получить это описание бизнеса? Абсолютно – нет! Получить этот документ несложно, так как он формируется естественным образом: общаясь с заказчиком, мы накапливаем какую-то информацию, пишем на доске потом снимаем это на телефон, ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

83

Александр Белин у нас есть листы с Flipchart’ов, делаем пометки по ходу общения, подводим итоги после проведения встреч с заказчиком – формируем Meeting Minutes. Всю эту информацию мы постепенно собираем в единый документ, поясняющий, как работает данный бизнес (см. Рис. 6). В этом документе мы ещё не выделяем области, которые будем автоматизировать.

Рис. 6. Документ «Описание Бизнеса»

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

84

На следующем шаге мы из созданного документа “Описание бизнеса» выделяем информацию, полезную для нас с точки зрения нашего проекта, т.е. сущности, которые нам потребуются в будущем. Для этого в документе мы проводим разметку. Что это означает? В данном документе мы обычно выделяем три типа информации полезной информации: • действующие лица бизнеса (т.е. «кто?»); • бизнес-действия («что?» они делают); • бизнес-правила («как?», т.е. в соответствии с какими правилами бизнеса они выполняют свою работу).

RUSSIAN IT BUSINESS ANALYSIS

Объектно ориентированный подход в Бизнес Анализе Технически это делается следующим образом: вы берете маркеры трёх или более цветов и выделяете в тексте вашего документа ту информацию, которая будет вам полезна. Мы в нашей практике выделяем три типа сущностей; возможно, в рамках вашего бизнеса вам потребуется более. Например, красным выделяем действующих лиц, зеленым - бизнес-действия, синим - бизнес-правила (см. Рис. 7).

Рис. 7. Документ «Описание Бизнеса» с разметкой Следующий шаг: мы выносим выделенную при разметке информацию в отдельные документы. Представляем эту информацию в удобном для дальнейшей работы виде. Первым документом обычно становится “Описание бизнес-правил». Этот документ содержит все бизнес-правила, которые нам удалось выделить в процессе разметки. Это может быть текстовый документ или spreadsheet. Если проектная команда или компания являются достаточно зрелыми и у вас есть возможность тратить деньги на Системы Управления Требованиями, или Системы Управления Бизнес Правилами, таковые тоже существуют, значит Бизнес Правила (БП) будут храниться в отдельном репозитории. Поскольку бизнес-правила уже “выдернуты» нами из описания бизнеса, мы уже сейчас можем их ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

85

Александр Белин переформулировать в виде неких законченных утверждений. Поскольку это некий справочник БП, которым мы будем пользоваться, ссылаться на эти БП, в этом случае мы присваиваем каждому БП уникальный идентификатор (см. Рис. 8) так же, как это обычно делается для требований.

Рис. 8. Список БП

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

86

Почему надо так подробно останавливаться на бизнес-правилах? Потому что БП в виде Глоссария помогут нам общаться с заказчиком на одном с ним языке. Заказчик не будет рассказывать о своих потребностях на языке IT команды, он будет рассказывать на своем языке – языке бизнеса. Поэтому, для того, чтобы разговаривать с заказчиком на одном языке, этот язык необходимо выучить. Мы должны составить некий словарь бизнес терминов. Бизнес правила вне зависимости от того, реализуются ли они в данном проекте или нет. Реализуемы ли они вообще в рамках IT проекта. Существуют ситуации, когда БП не могут быть реализованы. Тем не менее, мы все-равно регистрируем эту информацию, поскольку она создает необходимый бизнес-контекст для разрабатываемого приложения. И последнее.

RUSSIAN IT BUSINESS ANALYSIS

Объектно ориентированный подход в Бизнес Анализе Несмотря на то, что БП не являются требованиями, и это очень важно понимать, они оказывают сильное влияние на требования. Они влияют на объем требований и на внутреннюю структуру требований. В некоторых ситуациях БП выполняют роль предусловий. Например, если мы описываем требования в виде вариантов использования (ВИ), то там всегда есть precondition. Роль precondition может выполнять бизнес-правило. Некоторые бизнес-правила могут выполнять роль триггеров - то есть тех бизнес событий, которые запускают к исполнению тот или иной вариант использования. Также бизнес-правила могут влиять на внутреннюю структуру собственно требований. Итак, наша задача на этом этапе - создать репозиторий бизнес-правил, на который мы можем ссылаться при разговоре с заказчиком и при формировании требований (“у нас будет функциональность N, потому что у вас есть бизнес-правило S»). В «хороших» проектах, проводимых грамотными аналитиками, бизнес-правила не “закапывают» в требования. Их выделяют как отдельные сущности, на которые можно ссылаться. Возвращаемся к разметке документа. На этапе разметки мы выделили еще два типа информации. Это «Бизнес Действующие Лица (Business Actors)» и «Бизнес Действия или Бизнес Цели этих Действующих Лиц (Business Goals)». Логично эту информацию также вынести в отдельный документ. Мы создаем отдельный документ “Описание бизнес-действующих лиц и их бизнес-целей» (см. Рис. 8). Как результат, мы будем иметь список действующих лиц бизнеса, с которыми можно и нужно встречаться, и общаться на тему требований. Это делается для понимания того, какие действия они выполняют, или какие Бизнес Цели они достигают в рамках своего бизнеса. Понимая, какие задачи выполняют те или иные пользователи, мы можем совместно с заказчиком определять те задачи, которые в дальнейшем могут быть автоматизироваться. Т.е. мы определяем некий поднабор Бизнес Задач, которые в последующем действующие лица будут решать с использованием нашего приложения.

Рис. 9. Описание бизнес-действующих лиц и их бизнес-целей Двигаемся дальше. У нас есть описание действующих лиц. Есть список бизнес действий или задач, решаемых этими лицами. Какой следующий логических шаг? Естественно представить эту инANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

87

Александр Белин формацию в виде модели «Бизнес Вариантов Использования (Business Use Case diagram)» (см. Рис.

10). Обращаю ваше внимание на то, что мы сейчас работаем именно на этапе бизнес анализа, поэтому модель отображает именно Бизнес Действующих Лиц (workers и actors) и Бизнес Варианты использования (Business Use Cases). Благодаря наличию в языке UML возможности расширения, мы выделяем эти элементы с помощью специальных штрихов.

Рис. 10. Модель Бизнес Вариантов Использования

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

88

Всех Бизнес Действующих Лиц, перечисленными нами ранее в списке, и работающих в рамках RUSSIAN IT BUSINESS ANALYSIS

Объектно ориентированный подход в Бизнес Анализе бизнеса (внутри бизнеса), мы изображаем в виде Business Workers в соответствии с требованиями нотации (в виде кружочков). Те Бизнес Действующие Лица, которые функционируют за пределами бизнеса и взаимодействующие с изучаемым бизнесом - поставщики, покупатели, посредники - изображаются в виде Business Actors. Для каждого действующего лица мы изображаем действия - либо те, которые они выполняют, либо те, в которых они участвуют. И эти действия мы ассоциируем, связываем, либо с Workers, которые эти действия инициируют, либо с Действующими Лицами, к которым осуществляется обращение в рамках данных Бизнес Действий. Например, есть бизнес-действие «Отправить чек на выплату». Оно выполняется Business Worker «Платежный администратор», но в рамках этого действия Business Actor «Почтовая организация» задействован как вторичное Действующее Лицо.

Рис. 11. Business Activity Diagram Итак, мы создали первую модель, которая на верхнем уровне описывает тех действующих лиц, которые работают в бизнесе и действия, которые эти лица выполняют. На данном этапе мы ещё не определяем, какие именно действия мы будем автоматизировать - мы только формируем наше обANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

89

Александр Белин щее понимание бизнеса, чтоб с этим документом прийти к заказчику и получить его согласование. Следующий шаг моделирования - это построение Business Activity Diagram (см. Рис. 11). Каждое действие, описанное нами в предыдущем шаге, мы с помощью текста либо диаграммы расписываем в виде внутреннего сценария. В итоге получается описание внутренней структуры бизнес вариантов использования. Т.е. мы расписываем внутренние шаги, которые необходимо выполнить в рамках той или иной задачи бизнес деятельности. Какую информацию содержат эти шаги? Шаги содержат следующую информацию: - “кто?» выполняет какое-то действие (пример: работник); - “что делает?» (пример: запрашивает отчет по работнику); - над какой информационной сущностью выполняется действие (пример: сущность “отчет по работнику», или другая сущность «запрос на формирование отчета по работнику»). Далее мы не добавляя в эту модель никакой новой информации, просто перестраиваем модель в виде Business Activity Diagram with Swim lanes (см. Рис. 12).

Рис. 12. Business Activity Diagram with Swim Lanes ANALY SS

T

IAN IT B SS

RA

B

USINE

90

S RU SI

RUSSIAN IT BUSINESS ANALYSIS

Объектно ориентированный подход в Бизнес Анализе Мы выделяем области ответственности для каждой роли, или Действующего Лица, принимающего участие в шагах этого варианта использования, и все действия разносим по этим областям ответственности. Например, на модели выделяется Swim Lane для «работника» и Swim Lane для «платежного администратора». И в соответствующие Swim Lane мы разносим действия, выполняемые именно этими Действующими Лицами. Таким образом, информация “кто?» уходит из описания шага – она есть в заголовке Swim Lane; в шаге осталась только информация “что делает?» и над какой информационной сущностью выполняется действие. Например, в Swim Lane “Работник» попадают только те действия, которые выполняются работником. Для того, чтобы удобнее было анализировать информацию об управляемых информационных сущностях, логично вынести их из описания шагов и изобразить в виде отдельного структурного элемента. Поэтому следующим шагом мы выделяем информационные сущности на модели в виде отдельного графического элемента (см. Рис. 13).

Рис. 13. Business Activity Diagram with Swim Lanes с указанием управляемого объекта ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

91

Александр Белин При этом, очень важно отметить, что некоторые шаги сценария изменяют состояние этой сущности, т.е. порождают, изменяют значения атрибутов этой сущности и, возможно, разрушают эту сущность. И некоторые шаги сценария получают данную сущность в некотором состоянии в виде входных данных или предусловия. Поэтому в качестве оптимизации этой модели мы разрабатываем следующий, упрощенный вариант: мы убираем потоки управления между всеми парами последовательных шагов, один из которых изменяет состояние сущности, а второй – получает сущность в новом состоянии в виде входной информации или предусловия. Мы заменяем эти потоки потоками управления данной сущностью (см. Рис 14).

Рис. 14. Упрошенный вариант Business Activity Diagram with Swim Lanes с указанием управляемого объекта

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

92

Эта модель похожа на ещё один тип диаграмм, который очень полезен в работе для согласования RUSSIAN IT BUSINESS ANALYSIS

Объектно ориентированный подход в Бизнес Анализе с заказчиком. Эта модель похожа на модель Бизнес Процессов (Business Process diagram). На рис. 15 изображена та же самая диаграмма, только уже в виде модели Бизнес Процессов. На новой модели обозначены начало и конец процесса, а между ними - те же самые бизнес-действия, с которыми мы работали раньше. Бизнес действия также разнесены на именованные Swim Lanes. Модель, представленная на рис. 14, очень простая. Эта модель была разработана исключительно в демонстрационных целях для данного доклада. Реальные модели бизнес-процессов могут быть гораздо сложнее демонстрационного примера и содержать гораздо больше информации, чем просто business-activity diagram с выделенными Swim Lanes.

Рис. 15. Диаграмма бизнес процесса (BPMN) Поэтому имеет смысл сделать шаг вперед и разработать именно такую диаграмму, чтоб прийти с ней к заказчику и получить от него подтверждение, что его бизнес работает именно так. Я использую в своей работе Business Process Modelling Notation (BPMN), потому что данная нотация создана именно для целей моделирования бизнес процессов. Безусловно, UML тоже позволяет создавать такие модели, но с моей точки зрения, эта нотация более подходит для описания бизнес-процессов, чем UML. BPNM – это серьезная нотация, решающая очень сложные задачи не только моделирования, но и автоматизации бизнес процессов. Поэтому данная нотация предоставляет очень широкий набор нотационных элементов. Кроме этого, в нотации, а точнее, в инструментах, созданных для моделирования с использованием этой нотации, реализован широкий набор достаточно строгих правил и ограничений. Но, это не должно становиться препятствием для начинающих аналитиков, желающих взять данную нотацию на вооружение. Достаточно небольшой набор нотационных элементов позволит вам решить большинство задач моделирования. В моем опыте много прецедентов, когда мы отправляли модели бизнес процессов заказчикам, которые впервые видели модель Бизнес Процессов в BPMN, и это его не пугало, потому что мы соANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

93

Александр Белин

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

94

провождали модель легендой, описывающей назначение элементов. После первого знакомства с этой моделью заказчики работали с остальными моделями без каких-либо проблем, и согласование проходило легко. С помощью этой модели мы проводили как согласование нашего понимания бизнес процессов с заказчиком, так и доведение информации о бизнес процессах нашим разработчикам. Разработчики считают данную модель достаточно полезной и совершенно не сложной для понимания. Итак, мы разработали модель бизнес-процессов, мы согласовали эту модель с заказчиком, и мы донесли информацию о бизнесе заказчика до разработчика. На этом этапе разработчики начинают погружаться в бизнес-контекст и знакомиться с бизнесом заказчика для того, чтобы понимать итоговый смысл собственной разработки. Возвращаемся к модели Business Activity diagram, включающей состояния объектов. На этой модели мы выделили состояния информационных объектов и выполняемые действия, которые либо производят изменения, либо потребляют информационную сущность в качестве входного параметра (см. Рис. 13 или 14). Что еще полезного мы можем почерпнуть из этой модели? У нас есть информация о том, какие бывают состояния объекта, управляемого в рамках данного Бизнес-Процесса, какие действия приводят к изменению состояния этого объекта, какие действия потребляют этот информационный объект в качестве входной информации или предусловия. Но, жизнь гораздо богаче, и чаще всего нам необходимо определить еще целый ряд очень важных моментов, таких как: • какие дополнительные действия выполняются при изменении состояния; • условия изменения состояния, всегда ли это безусловный переход, или переход может осуществиться только при выполнении некоторого условия; • какие дополнительные действия выполняются сразу после перехода в состояние, перед выходом из состояния, при нахождении в некотором состоянии. Эту информацию нам, как раз, и позволит зафиксировать последняя модель из этого сценария. Это модель - State Machine diagram, или диаграмма состояний, или диаграмма-автомат (см. Рис. 16). На этой простой модели, разработанной в качестве демонстрационного примера, мы видим следующее: • действия, которые заставляют объект переходить из одного состояния в другое; • логические условия, которые должны выполняться для осуществления такого перехода; • информацию о действиях, которые выполняются перед выходом из состояния и действия, выполнимые сразу после перехода в определенное состояние (если таковые необходимы). Очень важно понимать, что действия, выполняемые перед выходом из состояния и сразу после перехода в состояние – это не те действия, которые осуществляют собственно переход в из одного состояния в другое. Опять же хочу подчеркнуть, что данная демонстрационная модель очень простая и, на первый взгляд, дает минимальнейшую пользу при наличии уже готовой Activity Diagram. Но, реальные модели, описывающие реальные ситуации бизнеса, отличаются значительно большей сложностью. Эти модели дают значительный объем дополнительной информации, по сравнению с другими, уже разработанными моделями. В своей работе я практически постоянно разрабатываю данную модель. Используя статусную модель, мы обычно достаточно быстро согласовываем с заказчиком наше понимание о состояниях бизнес сущностей. Более того, заказчик, разобравшись с нотацией, сам добавляет в модель недостающие элементы, т.е. мы уже начинаем общаться через формальные модели. Достаточно легко проводить согласование и утверждение нашего понимания статусной модели с заказчиком. И эту, уже уточненную и согласованную модель мы передаем разработчикам. Для разработчиков, привыкших работать с информационными сущностями, эта модель понятна и очень полезна.

RUSSIAN IT BUSINESS ANALYSIS

Объектно ориентированный подход в Бизнес Анализе

Рис. 16. Диаграмма Автомата (статусная модель) Например, при программировании front-end разработчики программируют внешний вид формы, которая отображает некоторую информационную сущностью. Если у них есть подобная схема, то они понимают, как настраивать видимость и доступность управляющих элементов (кнопок, гиперссылок и т.п.), т.е., в терминах статусной модели, определять набор действий, доступных для данной сущности в зависимости от состояния, в котором эта сущность находится. Итого, я представил короткий сценарий того, как можно проводить Бизнес Анализ - последовательно от модели к модели. Но мы планировали поговорить об Объектно-Ориентированном подходе. Все модели, которые мы уже обсудили, построены с использованием языка визуального моделирования UML. И, несмотря на то, что UML был разработан для Объектно-Ориентированного Анализа и Проектирования, рассмотренные модели не являются Объектно-Ориентированными. Поэтому, для того, чтобы наш сценарий действительно был Объектно-Ориентированным, нам необходимо определиться, где же у нас Объекты и где у нас Классы. Как собственными силами, не прибегая к помощи Системных Архитекторов или Дизайнеров, уже на этапе БА, создать Модель Предметной Области (Domain Model) в виде Концептуальной Модели Классов? Возвращаемся к модели Бизнес Вариантов Использования (Рис. 10). Мы извлекаем всю информацию об «управляющих», активных сущностях. Это те сущности, которые изображены в виде Business Workers и Business Actors. На основе этой информации мы создаем новую модель – Role Map (см. Рис. 17). На следующем шаге мы преобразуем эту модель в модель классов, практически, просто заменяя изображения Действующих Лиц на изображения классов (см. Рис. 17). Хочу отметить, что уже на этом этапе мы вполне в состоянии провести доработку модели классов, например, выделить некий родительский или обобщающий класс, указать для него связи типа Обобщение (Generalization) с детальными классами и т.п. Например, мы выделили классы «Работник с почасовой оплатой», «Работник с фиксированной оплатой» и «Работник, получающий процент от продаж». Уже сейчас мы можем выделить некий обобщающий класс «Работник», который будет содержать атрибуты и операции, общие для всех ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

95

Александр Белин типов работников.

Рис. 17. Role Map

Рис. 18. Предварительная модель классов для активных сущностей ANALY SS

T

IAN IT B SS

RA

B

USINE

96

S RU SI

RUSSIAN IT BUSINESS ANALYSIS

Объектно ориентированный подход в Бизнес Анализе Аналогичные действия мы выполняем на основе модели Бизнес Вариантов Использования (Рис.

9) для создания модели классов неактивных информационных сущностей (см. Рис. 19).

Рис. 19 Предварительная модель классов для неактивных информационных сущностей Располагая двумя моделями классов для активных и неактивных сущностей, логично было бы их объединить в единую модель. Мы создаем единую модель классов (см. Рис. 20).

Рис. 20 Обобщенная модель классов ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

97

Александр Белин

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

98

На этой модели мы не только изображаем все описанные ранее классы, но и связываем классы между собой ассоциациями, если это необходимо. При этом мы уже можем определить назначение каждой связи путем указания стереотипа для связи. Например, класс «Работник» связан с классом «Запрос на формирование отчета по работнику» отношением типа Ассоциация, со стереотипом «Создает». Это отношение говорит о том, что работник создает этот от запрос. Какую пользу несет эта информация для разработчиков? С точки зрения программной реализации это означает, что у класса «Запрос на формирование отчета по работнику» должен быть метод «Создать», проще говоря – конструктор, который должен быть, естественно, публичным. И класс «Работник» может использовать данный метод для создания объекта класса «Запрос…». Т.е. уже на этапе бизнес анализа, даже не приступив к разработке требований, не прибегая к помощи Архитекторов и Дизайнеров мы уже создаем артефакты, которые будут понятны и, главное, полезны разработчикам. Этап бизнес анализа закончен, но мы понимаем, что бизнес анализ не является нашей целью. Наша цель – это разработка требований к программному обеспечению. Поэтому всю информацию, которую мы собрали, формализовали и согласовали с заказчиком, нам необходимо «переплавить» в системные требования. Таким образом, наши следующие шаги, говоря в общем, – это определение Системных Действующих Лиц и определение, хотя бы, высокоуровневых требований к системе. Откуда мы черпаем информацию о будущих Системных Действующих Лицах для нашего приложения? Мы получаем эту информацию из: • модели Бизнес Вариантов Использования (Рис. 9). Мы, практически без изменения, весь список Business Workers преобразуем в список Системных Действующих Лиц. При этом мы понимаем, что Business Actors в список Системных Действующих Лиц не попадут. Почему? Потому, что они существуют вне автоматизируемого бизнеса. И если мы разрабатываем корпоративную систему, которая будет доступна только сотрудникам компании, и не будет доступна за пределами компании, то Business Actors взаимодействовать с нашей системой не будут и, следовательно, в список Системных Действующих Лиц включаться не должны; • модели Бизнес Процессов (Рис. 14). Имея информацию о том, какие шаги бизнес процесса должны быть автоматизированы, мы видим, в чьей зоне ответственности они находятся. Это означает, что сотрудники, входящие в состав данной роли, будут взаимодействовать с нашим приложением для выполнения этих шагов, но уже с использованием нашей системы; • моделей Деятельности (Рис. 10-13), разработанных для каждого отдельного Бизнес Варианта Использования. Вспоминаем, в шагах этой модели мы описывали «кто?», «что?» делает и над какой сущностью выполняется действие. Информация «кто?», как-раз, и используется для пополнения списка Системных Действующих Лиц. Каким образом составляется предварительны список высокоуровневых требований? Откуда мы берем информацию о кандидатах на будущие требования? Мы используем следующие разработанные нами на этапе БА документы: • список Действующих Лиц и их Задач (Рис. 8). Если заказчик указал нам на некоторые Бизнес Задачи и сказал, что они должны быть автоматизированы, то эти задачи становятся кандидатами на высокоуровневые требования к будущей системе (features); • модели Деятельности (Рис. 10-13), разработанные для каждого отдельного Бизнес варианта Использования. Информация о том, «что?» делает активная сущность и используется для пополнения списка высокоуровневых требований; Бизнес Правила (БП) также могут предоставлять информацию о том, какие бизнес действия выполняются в бизнесе, и, потенциально, могут быть по желанию заказчика автоматизированы. Например, в случае если нами зарегистрировано БП, говорящее о том, что подача заявок на учебный курс возможна только в течение месяца после начала периода записи на курс, и по истечении этого срока должны выполняться процедуры проверки, сколько человек записалось на курс, набрано ли минимальное количество слушателей, необходимое для того, чтобы курс стартовал, и т.д. Это озRUSSIAN IT BUSINESS ANALYSIS

Объектно ориентированный подход в Бизнес Анализе начает, что в системе должны быть реализованы функции открытия и закрытия периода записи на курс, процедуры, выполняющие все необходимые проверки, процедуры, которые переводят выбранный курс в статус «открыт» или «отменен» и т.д. В завершение, буквально несколько слов о том, каким образом Бизнес Правила влияют на структуру требований, мы упоминали об этом в начале данной статьи. Мы уже говорили о том, что БП могут быть предусловиями для требований, написанных в формате Вариантов Использования. БП могут описывать некоторые события, которые играют роль спускного механизма для запуска на исполнение того или иного Варианта Использования. Это называется Триггер (Trigger). И последнее. Я предлагаю вам не верить мне на слово, а проверить в вашей практике. Если вы описываете требования в виде Вариантов Использования, и в этих вариантах использования есть разветвления типа: основной сценарий на альтернативный или основной на сценарии исключение, «виной» этому является некое зарегистрированное вами БП. Если срок записи на курс (1 месяц) не истек, значит Вариант Использования продолжает развиваться по основному сценарию. Если срок истек, то ВИ отправляется по сценарию исключению или альтернативному сценарию, в зависимости от того, как вы это оформили. Более подробную информацию о БП, их классификации, способах их регистрации, отличиях от требований и влиянии на требования, можно найти в моем докладе «Бизнес Правила – это не требования. Нужно ли с ними работать?». Запись этого доклада можно легко найти в интернете.

ANALY SS

S RU SI

T

IAN IT B SS

RA

B

USINE

RUSSIAN IT BUSINESS ANALYSIS

99