russian it business analysis #2

Сущность Бизнес

Анализа[02] 2014

RussianInformation Technologies BUSINESS ANALYSIS

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

Moscow, Russia

TRB A

RUSSIAN

IT

BUSINESS

AN

ALY

SIS

TRB A

RUSSIAN

IT BUSINESS A

NALY

SIS

TRB A

RUSSIAN

IT

BUSINESS

ANALY

SIS2 RUSSIAN ITBUSINESS ANALYSIS

RussianInformation Technologies BUSINESS ANALYSIS

TRB A

RUSSIAN

IT

BUSINESS AN

ALY

SISRUSSIAN ITBUSINESS ANALYSIS 3

Leonardo da Vinci

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.

TRB A

RUSSIAN

IT

BUSINESSA

NALY

SIS

4 RUSSIAN ITBUSINESS ANALYSIS

Авторы экспертных мнений

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

Иван ШамаевВ 2012 году с отличием окончил МГТУ им. Баумана,. Участвовал в проектах по автоматизации управле-ния недвижимостью, автоматизации заказного про-изводства, калькуляции маржинальной прибыли. В текущее время работает системным аналитиком в Альфастраховании в Управлении финансовых систем. Работает с системами Hyperion Planning, [email protected]

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

TRB A

RUSSIAN

IT

BUSINESS AN

ALY

SISRUSSIAN ITBUSINESS ANALYSIS 5

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

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

Сергей ПюнниненБизнес-аналитик, менеджер проектов. Опыт работы в области IT - более 10 лет. Сфера профессиональных интересов: реинжиниринг бизнес-процессов, авто-матизация производственных процессов, системная интеграция[email protected]

Владимир КовешниковРуководитель направления и консультант по бан-ковским бизнес процессам учебного центра Luxoft Training. Ранее руководил отделом процессов и тех-нологий аппарата Среднерусского Банка Сбербанка России. Работает в ИТ с 2004 года, на финансовых рынках с 2007 года. С января 2011 года проводит тре-нинги по инвестиционному банкингу и финансовым рынкам для специалистов ИТ[email protected]

TRB A

RUSSIAN

IT

BUSINESS AN

ALY

SIS

6 RUSSIAN ITBUSINESS ANALYSIS

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

ГЕОРГИЙ САВЕЛЬЕВ 8

Сущность Бизнес Анализа

ИВАН ШАМАЕВ 20

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

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

Правила проведения интервью при обследовании бизнес процессов

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

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

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

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

7TRB A

RUSSIAN

IT

BUSINESS AN

ALY

SISRUSSIAN ITBUSINESS ANALYSIS

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

Business Process Modeling Notation

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

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

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

СущностьБизнес Анализа

9TRB A

RUSSIAN

IT

BUSINESS AN

ALY


ретья версия Руководства по своду знаний бизнес-анализа (BABOK Guide v3), пред-ставленная на публичное обозрение, определяет Бизнес-анализ как «Практика обе-

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

Т

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

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

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

10 TRB A

RUSSIAN

IT

BUSINESS AN

ALY

SIS RUSSIAN ITBUSINESS ANALYSIS


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

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

Впрочем, сама по себе Модель основных понятий бизнес-анализа ничего не говорит об особен-ностях работы бизнес-аналитика. С равным успехом она применима к управлению проектами, про-ектированию архитектуры предприятия, стратегическому планированию. Поэтому далее BABOK поясняет: «В конечном счете Бизнес-анализ помогает организациям понять потребности предпри-ятия и причины нужных изменений, разработать возможные решения и объяснить пользу, которую эти решения могут принести». В этом предложении есть два слова, которые отражают самую суть деятельности бизнес-аналитика. Какие? Прежде чем ответить на этот вопрос, обсудим что такое вообще человеческая деятельность.

Понятие деятельностиВ современном общепринятом понимании, деятельность – это набор организованных действий,

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

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

11TRB A

RUSSIAN

IT

BUSINESS AN

ALY


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

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

Назначение бизнес-анализаНазначение любого вида анализа, как деятельности, состоит в выявлении и устранении нео-

пределенности. Там, где всем все известно и понятно, аналитик не нужен. Это определение приме-нимо к любому виду анализа – финансовый, химический, маркетинговый, статистический, психоло-гический. Отличия между разными видами анализа определяются объектами анализа. Специфика бизнес-анализа состоит в том, что его объектами являются организационные и информационные системы, а особенно – их создание и изменение. Специфика бизнес-анализа состоит в том, что его объектами являются организационные и информационные системы, а особенно – проекты по их созданию и изменению.

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

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

Однако, как писал Марк Твен: «Проблемы создаёт не то, чего мы не знаем, а известное нам на-верняка, которое на деле таковым не является». Причина провала многих проектов – ложная уве-ренность в том, что «всем все известно и понятно». Обычно такая уверенность основана на непод-крепленных убедительными доказательствами субъективных мнениях ключевых участников. Ошибочность этих мнений неизбежно обнаруживается в ходе проекта, но зачастую слишком поздно чтобы что-то исправить. Поэтому способность бизнес-аналитика выявлять зоны неопределенности может играть даже более важную роль, чем мастерство их устранения.

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

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

Предмет бизнес-анализаМодель основных понятий (BACCM), о которой мы говорили ранее, определяет предмет биз-

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

12 TRB A

RUSSIAN

IT

BUSINESS AN

ALY


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

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

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

Результаты бизнес-анализаКак показывает предыдущая диаграмма, результатами бизнес-анализа являются определе-

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

13TRB A

RUSSIAN

IT

BUSINESS AN

ALY


Сущность бизнес-анализанужную для их устранения, также являются ценным продуктом работы бизнес-аналитика.

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

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

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

Действия бизнес-аналитикаВернемся теперь к вопросу о том, какие два слова отражают сущность работы бизнес-аналитика.

Эти два слова – понимание и объяснение. Все действия, которые аналитик выполняет в рамках сво-ей профессиональной деятельности, нацелены либо на первое, либо на второе.

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

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

14 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



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

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

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

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

15TRB A

RUSSIAN

IT

BUSINESS AN

ALY


TRB A

RUSSIAN

IT

BUSINESS AN

ALY

SIS

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

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

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

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

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

тат. Таковыми являются те знания, навыки, методы, техники, практики и инструменты, которые мы применяем для решения наших задач.

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

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

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

BABOK Guide является международно признанным стандартом практики бизнес-анализа, осно-ванным на обобщении опыта множества бизнес-аналитиков из разных стран. Он определяет 30 ос-новных задач бизнес-анализа, описывает 46 техник применяемых для их решения, и перечисляет 26 базовых компетенций бизнес-аналитика, обеспечивающих его успешность.

Задачи бизнес-анализа сгруппированы в шесть областей знания: Планирование и мониторинг бизнес-анализа, Выяснение и взаимодействие, Управление жизненным циклом требований, Стратегический анализ, Анализ требований и определение дизайна, Оценка решения. Эти зна-

16 TRB A

RUSSIAN

IT

BUSINESS AN

ALY


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

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

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

Компетенции бизнес-аналитикаКомпетенции бизнес-аналитика включают в себя знание методов, техник, практик и инструмен-

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

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

17TRB A

RUSSIAN

IT

BUSINESS AN

ALY


Сущность бизнес-анализаНавыки четвертого слоя (управленческие) предполагают способность выбирать инструменты и

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

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

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

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

18 TRB A

RUSSIAN

IT

BUSINESS AN

ALY


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

19TRB A

RUSSIAN

IT

BUSINESS AN

ALY


Иван Шамаев


21TRB A

RUSSIAN

IT

BUSINESS AN

ALY


Иван Шамаевсистемный аналитик, Альфастрахование

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


Business Analysis Body of Knowledge (BABOK) v2.0

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

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

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

22 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



ISO/IEC 29148

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

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

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

стемы• Упаковка, обращение, доставка и транс-

портировка

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

данных• Ограничения проектирования• Соответствие стандартам• Системные атрибуты программного обе-

спечения

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

23TRB A

RUSSIAN

IT

BUSINESS AN

ALY


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

Software Engineering Body of Knowledge (SWEBOK)

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

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

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

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

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

24 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



Information Technology Infrastructure Library (ITIL) v2

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

Типы требований Методы сбора требованийТребование к уровню услуг (SLR)

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

эксплуатации

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

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

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

25TRB A

RUSSIAN

IT

BUSINESS AN

ALY



Capability Maturity Model Integration Development (CMMI DEV) v1.3

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

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

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

26 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



ГОСТ 34.602-89. Техническое задание на создание АС Техническое задание на создание АС

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

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

Требования к системе в целом:• требования к структуре и функционированию

системы;• требования к численности и квалификации пер-

сонала системы и режиму его работы;• показатели назначения;• требования к надежности;• требования безопасности;• требования к эргономике и технической эстети-

ке;• требования к транспортабельности для подвиж-

ных АС;• требования к эксплуатации, техническому об-

служиванию, ремонту и хранению компонентов системы;

• требования к защите информации от несанкцио-нированного доступа;

• требования по сохранности информации при авариях;

• требования к защите от влияния внешних воз-действий;

• требования к патентной чистоте;• требования по стандартизации и унификации;• дополнительные требования.

Требования к функциям (задачам), выполняе-мым системойТребования к видам обеспеченияОбщие требования к приемке работ по стадиямТребования к документированию

Не описаны

27TRB A

RUSSIAN

IT

BUSINESS AN

ALY



ГОСТ 19.201-78. Техническое задание, требования к содержанию и оформлению

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

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

кам• Требования к надежности• Условия эксплуатации• Требования к составу и параметрам технических

средств• Требования к информационной и программной

совместимости• Требования к маркировке и упаковке• Требования к транспортированию и хранению• Специальные требования

Требования к программной документации

Не описаны

28 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



Requirements Engineering Body Of Knowledge (REBOK)

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

Типы требований Методы сбора требований3 Уровня требований:

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

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

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

Сбор информации о пользовате-лях:• Наблюдение• Профилирование пользователя• Просмотр журнала действий

пользователя (например, в опе-рационной системе)

Методы сценариев и пользова-тельских историй:• Анкетирование/Интервью• Наблюдение• Рабочие семинары по сбору

требований• Анализ документации

29TRB A

RUSSIAN

IT

BUSINESS AN

ALY



Project Management Body of Knowledge (PMBOK)

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

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

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

Требования заинтересованных сторон:• воздействие на другие области организации;• воздействие на другие субъекты внутри или за

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

заинтересованных сторон

Требования к решению:• функциональные и нефункциональные требова-

ния;• требования соответствия технологиям и стан-

дартам;• требования к поддержке и обучению;• требования к качеству;• требования к отчетности и т. д. (требования к

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

Требования к проекту:• уровни обслуживания, производительности, без-

опасности, соответствия и т. д.;• критерии приемки

Требования к переходу.Допущения, зависимости и ограничения в отно-шении требований.

ИнтервьюФокус-группыСеминары с участием модератораМетоды группового творчества:• Мозговой штурм• Метод номинальных групп• Построение ассоциативных

карт• Диаграмма сходства• Анализ решений на основе мно-

жества критериевМетоды группового принятия ре-шенийАнкеты и опросыНаблюденияПрототипыБенчмаркингКонтекстные диаграммыАнализ документов

30 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



IBM OpenUP и FURPS+

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

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

Типы требований Методы сбора требованийТри уровня требований по IBM OpenUP:

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

Модель «FURPS+» — функциональные, нефункцио-нальные и вспомогательные требования

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

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

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

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

31TRB A

RUSSIAN

IT

BUSINESS AN

ALY



Элизабет Халл. Разработка и управление требованиями

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

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

• Интервью с представителями заинтересованных сторон

• Сценарии использования (обычно получаемые в резуль-тате интервью)

• Описательная документация (например, различные отчеты, анализ рынка)

• Действующие системы, кото-рые необходимо модернизиро-вать

• Проблемы, обнаруженные в существующих системах, и идеи как их исправить

• Опыт работы с аналогичными системами

• Разного рода прототипы, маке-ты, эскизы продукта или самих требований

• Возможности новых техноло-гий (согласованные с заинтере-сованными сторонами)

• Результаты исследований• Опросы• Наблюдение за работой персо-

нала или изучение видеозапи-сей их работы

32 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



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

Книга содержит общее введение в написание вариантов использования и подробное описание составных частей варианта использования

Типы требований Методы сбора требованийПриемлемая схема требований:

Цель и область действияИспользуемые термины/ГлоссарийВарианты использованияИспользуемая технология

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

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

Не описаны

33TRB A

RUSSIAN

IT

BUSINESS AN

ALY



Вигерс Карл. Разработка требований к программному обеспечению

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

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

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

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

34 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



Лешек А. Мацяшек. Анализ и проектирование ин-формационных систем с помощью UML 2.0

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

Типы требований Методы сбора требованийДокумент описания требований

Предварительные замечания к проекту

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

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

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

зиции• Моделирование отношений обобщения• Моделирование объектов

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

Традиционные методы выявле-ния требований:• Интервьюирование заказчи-

ков и экспертов в проблемной области

• Анкетирование• Наблюдение• Изучение документов и про-

граммных систем

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

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

ний (RAD-метод)

35TRB A

RUSSIAN

IT

BUSINESS AN

ALY



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

36 TRB A

RUSSIAN

IT

BUSINESS AN

ALY


РАЗВИТИЕ ОРГАНИЗАЦИОННОЙ КОМПЕТЕНЦИИ ДЕЛАТЬ ПРАВИЛЬНЫЕ ВЕЩИ.

С каждым годом растет сложность современных организаций и технологических решений необ-ходимых для достижения Успеха. Повышается давление изменений и конкуренции на уже суще-ствующие системы. Растет кол-во возможностей по развитию. И чем сложнее система, особенно социотехническая, тем сложнее определить в чем именно состоит проблема и подобрать людей, которые смогут не только осуществить, но и найти, и вы-брать именно то решение которое даст наибольшие преимущества организации. Успех организации и конкретного подразделения зависит от готовности к предстоящим измене-ниям, способности определить главное направлении и сосредоточить свои ресурсы на нем. Где искать компетентных аналитиков, руководителей продуктов и проектов, при том что универсаль-ных решений не существует?

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

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

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

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

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

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

ООО «Системный подход»

Doing right things is much more important than do thing right

37TRB A

RUSSIAN

IT

BUSINESS AN

ALY


Наши направления• Инженерия требований

• Бизнес анализ – Комплексное решение бизнес задач, Основной процесс и этап в достиже-нии целей заказчика;

• Системный анализ – Управление границами решения, Основной процесс в создании сложных решений в тесно интегрированной среде.

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

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

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

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

Преимущества нашей команды • Мы умеем и делаем то, чему обучаем!

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

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

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

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

В отличие от:• Индивидуального обучения, мы создаём команду единомышленников и среду в которой у новых

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

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

Контактная информацияВсе вопросы по поводу сотрудничества могут быть направлены: Безуглому Дмитрию Леонидовичу[email protected] Подписаться на новости компанииhttps://www.facebook.com/SystemApproach

ООО «Системный подход»

Doing right things is much more important than do thing right

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

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

39TRB A

RUSSIAN

IT

BUSINESS AN

ALY


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

и продолжительности проекта внедрения ERP системы Axapta. Мне в помощь были выделены два студента, не имеющих практического опыта ни предпроектного обследования, ни внедрения ERP системы.

Я понимал, что «успех» предпроектного обследования определяет состоится ли продажа услуг по внедрению Axapta. Продажа окажется возможной лишь в случае, если заказчик воспримет наших сотрудников как харизматиков и профессионалов своего дела. (Прим. В переводе с греческого харизма означает «дар богов». Харизматическое поведение может быть разбито на три основных элемента: присутствие, сила и теплота. Эти элементы зависят и от нашего осознанного поведения, и от факторов, которыми мы не управляем на сознательном уровне).

Я взял трёхдневный тайм аут и создал некий документ – инструкцию по подготовке и проведению интервью. Мы успешно провели предпроектное обследование – клиент купил у нас Axapta.

Через два года на одной из вечеринок в неформальной обстановке я спросил ЛПРа (лицо, принимавшего решения): «А почему вы купили именно у нас, а не у кого-либо другого?».

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

После этого случая я решил создать документ «Правила проведения интервью».В течение 10 последующих лет мы с коллегой непрерывно совершенствовали эти

правила, инкорпорируя в них опыт применения этих Правил.

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

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

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

40 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



Выгоды применения Правил на практикеО важности умения бизнес-аналитика проводить интервью с представителем заказчика можно

найти много содержательных материалов в сети. Однако отсутствуют предписывающие (а не описывающие!) методики по интервьюированию, проведению встреч, собеседований, которыми бы мог руководствоваться бизнес-аналитик.

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

чён в корпоративную базу знаний.Концепция интервью сформулирована в виде Правил проведения интервью. Это делает

возможным её практическое применение в деятельности консалтинговой фирмы и бизнес-аналитиков.

Опыт «кровью и железом» показывает, что эти правила являются best practice. Но если ваш лич-ный (корпоративный) опыт диктует вам иные формулировки пунктов свода Правил, приводимых ниже, вы можете внести необходимые изменения, так как он (свод Правил) открыт для модифика-ции и оптимизации.

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

Правила проведения интервью1. Общие положения1.1. Правила проведения интервью (далее – Правила) устанавливают единый для сотрудни-

ков Компании порядок подготовки и проведения интервью при изучении (диагностике) бизнес-процессов Клиента, а также порядок отчётности о проведённом интервью.

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

• путём непосредственного общения;• путём общения по телефону;• путём общения по электронной почте.

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

ный начальник).2.2. За два дня до даты проведения интервью исполнитель представляет менеджеру проекта на

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

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

41TRB A

RUSSIAN

IT

BUSINESS AN

ALY


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

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. Порядок обработки результатов интервью и отчётность.4.1. Не позднее следующего рабочего дня следует отправить интервьюируемому

42 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



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

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

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

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

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

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

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

43TRB A

RUSSIAN

IT

BUSINESS AN

ALY



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

№ п/п Роль в проекте ФИО

4. Данные об интервьюируемых лицах№ п/п Должность ФИО Реквизиты для связи Местоположение

(географическое) в офисе

5. Взаимное представлениеСледует указать, когда и при каких обстоятельствах (совещание, фуршет и т. п.) был ранее

представлен интервьюер. Следует указать лицо (должность, ФИО), которое представило / представит партнёров друг другу: _________________________________________________________________________

6. Осведомлённость интервьюируемого о цели встречиНеобходимо указать, когда и при каких обстоятельствах интервьюируемому сообщили / сообщат

о цели интервью. Указать должность и ФИО сообщившего лица: _______________________________________________________________________________________________________________________7. Актуальная (деловая) информация, которой владеет интервьюерСледует специфицировать информацию, имеющуюся у интервьюера, и степень (произвольно)

знакомства с ней (для документов).№ п/п Описание информации Степень знакомства

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

Дата Время начала

Время окончания Длительность (чч, мм)

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

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

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

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

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

1 2 ..

44 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



11. Предполагаемый способ записи информацииСледует указать способ записи информации во время интервью. Опросные листы прилагаются к

настоящему плану (составляются в произвольной форме): ______________________________________________________________________________________________________________________________Количество опросных листов: _________ на __________ страницах.12. План беседы и список вопросовСоставляется список вопросов согласно цели интервью с указанием желательной степени (про-

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

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

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

1 2 ..

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

№ п/п

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

12..

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

45TRB A

RUSSIAN

IT

BUSINESS AN

ALY



Приложение 2. Отчёт об интервью

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

знакомства с ней (для документов).№ п/п

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

1 23

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

Роль в проекте ФИО

12

4. Данные об интервьюируемых лицах№ п/п Должность ФИО Реквизиты для связи Местоположение

(географическое) в офисе

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

Дата Время начала

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

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

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

7. Способ записи информации

Следует указать способ записи информации во время интервью. Черновые записи прилагаются к настоящему отчёту.___________________________________________________________________ ___________________________________________________________________________________

Количество полученных опросных листов: _________ на __________ страницах.Количество неполученных опросных листов: __________Количество страниц черновых записей: ______________8. Список полученных документов

№ п/п Наименование документа Носитель1..

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

1

46 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



..10. Результат беседы

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

№ п/п

Вопрос Содержание ответа Степень точности ответа

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

1..

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

Бизнес-процесс Проблема Примечание

1..12. Отметка о согласовании отчётаПорядок согласования с интервьюируемым материалов отчёта (указывается время и способ

согласования / передачи надлежащих материалов отчёта интервьюируемому) : __________________________ ______________________________________________________________________________________

13. Прочие полученные сведения____________________________________________________________________________________14. Контрольный лист умения слушать№ п/п

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

1 Слушая собеседника, поддерживайте с ним зрительный контакт

2 Слушая собеседника, не занимайтесь посторонними делами

3 Проявляйте к собеседнику чуткость

4 Наблюдайте за мимикой и жестами собеседника

5 Не перебивайте собеседника

6 Задавайте уточняющие вопросы

7 Заверьте собеседника в том, что вы поняли его.

8 Спросите собеседника, можете ли вы ему чем-либо помочь

47TRB A

RUSSIAN

IT

BUSINESS AN

ALY



Приложение 3. Правила общенияУмение общаться - один из важнейших навыков SAP-консультантов. Предлагаю вашему внима-

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

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

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

Слушая собеседника, не занимайтесь посторонними делами.Помните, качественно проведённое с кем-то время — это, прежде всего, безраздельное внимание.

Если вы чем-то заняты, в тот момент, когда к вам обратился пользователь, от чего вам трудно оторваться, скажите ему честно: «Я с удовольствием пообщаюсь с Вами и уделю Вам полноценное внимание, но чуть позднее, потому что сейчас я занят. Если Вы подождёте, то через десять минут я выслушаю Вас». Большинство людей оценят такое отношение.

Проявляйте к собеседнику чуткость.Спросите себя: «А что чувствует сейчас этот человек?» Если вы нашли ответ на этот вопрос, то

обязательно уточните, так ли это. Например: «Похоже, Вы расстроены из-за...» Это даст возможность вашему собеседнику объяснить, что он испытывает в момент разговора, и будет свидетельством того, что вы его внимательно слушаете.

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

могут сказать о душевном состоянии собеседника. Иногда его мимика и жесты не совпадают со словами. Уточните, что на самом деле он чувствует и думает. Например: «Вы говорите, что согласны с предложенным изменением бизнес-процессов, но мне, кажется, что Вас заставили согласится. Это так или я ошибаюсь?»

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

затем перебивает рассказчика и вставляет свои «пять копеек». Общение в таком случае может за-кончиться, не успев начаться. Ваша задача на начальном этапе разговора — не отстаивать свою точ-ку зрения, не ставить собеседника на место, а понять его мысли, чувства и желания. Если перебить слишком рано, можно так никогда и не узнать, что пытался сказать человек.

Задавайте уточняющие вопросы.Если вы не совсем понимаете, о чем говорит собеседник, уточните это, повторив то, что он ска-

зал: «Вы имеете в виду, что... Верно?» Уточнение услышанного предотвращает непонимание между собеседниками.

Заверьте собеседника в том, что вы поняли его.Каждому человеку важно знать, что его услышали и поняли. Выражая понимание, вы помогаете

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

не просят.РезюмеДля того чтобы состоялась качественная беседа, необходимо потратить время и усилия. Фактически

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


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

49TRB A

RUSSIAN

IT

BUSINESS AN

ALY


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

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

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

Для качественного внедрения любой автоматизированной системы и при принятии любого решения относительно оптимизации численности персонала стоит в первую оче-редь обратить внимание на бизнес процессы организации – банка. И тут есть три основ-ных этапа:

1. Описание бизнес процессов;2. Оптимизация бизнес процессов;3. Управление бизнес процессами.

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

понять, чем все-таки занимается то подразделение, которое мы собираемся автомати-

П

Владимир КовешниковРуководитель направления и кон-сультант по банковским бизнес процессам учебного центра Luxoft Training

Не секрет, что банковский бизнес развивается не одну сотню лет, но эффективно ли он работает в наши дни?


50 TRB A

RUSSIAN

IT

BUSINESS AN

ALY


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

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

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

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

Управление бизнес процессамиУправление процессами в компании – показатель зрелости бизнеса. Тут есть две составляющие.

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

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

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

51TRB A

RUSSIAN

IT

BUSINESS AN

ALY



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

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

1 LEAN 2 DMAIC

52 TRB A

RUSSIAN

IT

BUSINESS AN

ALY


53TRB A

RUSSIAN

IT

BUSINESS AN

ALY


RUSSIAN ITBUSINESS ANALYSISTRB A

RUSSIAN

IT

BUSINESSA

NALY

SIS

54

55TRB A

RUSSIAN

IT

BUSINESS AN

ALY


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


57TRB A

RUSSIAN

IT

BUSINESS AN

ALY


Сегодня мы поговорим о тех проектах, которые имеют на входе минимум информации, начинаясь, как правило, с абстрактного волеизъявления заказчика: «я хочу, чтобы у

нас было нечто ...», и о первых шагах бизнес аналитика по превращению абстрактных представлений заказчика в конкретное техническое задание.

Существует расхожая фраза, о том, что участие в проекте - это бег с препятствиями. И первый барьер, который встает на пути бизнес-аналитика, можно охарактеризовать во-просом: «С чего начать?».

Методология BABOK дает однозначный ответ на данный вопрос – начинать следует с планирования. Объектом планирования и отправной точкой в извлечении бизнес-по-требностей заказчика станет, в нашем случае, первичное интервью с заказчиком. Четкое представление о структуре необходимой аналитику входной информации, позволит не только минимизировать усилия аналитика по её извлечению, но и повысит профессио-нально-доверительный уровень во взаимоотношениях с заказчиком.

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

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

чек входа, достаточных для проведения дальнейшего бизнес-анализа и работы по извле-чению истинных потребностей заказчика.

Такими точками входа обычно являются:• цели;• задачи;• география проекта (территориальная и административная);


Сергей ПюнниненБизнес-аналитик

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

58 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



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

Давайте, разберем вышеприведённый перечень по пунктам.

Определение целиЦель необходимо определить как можно раньше, хотя бы в первом приближении, ведь это не

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

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

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

Памятуя о том, что основная цель любого бизнеса - получение дохода, можно предложить заказ-чику один из следующих шаблонов формулировки цели:1. «Минимизировать затраты на ..., за счет …», либо2. «Повысить доходность ..., за счет …».

Разумеется, возможны и иные варианты.Проверить качество формулировки цели можно путем применения к ней критериев методоло-

гии SMART [1].В более сложных случаях, когда проблемы заказчика сформулированы менее четко, для выявле-

ния истинных потребностей заказчика и формулирования цели хорошо подходит метод построения логических деревьев [2].

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

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

Декомпозиция цели на задачиНа практике часто встречается ситуация, когда в проекте обозначается несколько равноправ-

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

Применительно к приведенному выше примеру, задачи могут быть определены следующим об-разом:1. Создание подсистемы автоматизированного сбора информации о поставщиках;2. Создание подсистемы структурированного представления информации о поставщиках.

Определение географии проектаГеография проекта представляет собой описание компонентов корпоративной среды, их терри-

59TRB A

RUSSIAN

IT

BUSINESS AN

ALY



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

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

Сбор данных по этому разделу удобно организовать в виде матриц, таблиц и организационных диаграмм.

Схема ресурсов и информационных потоковДля составления данной схемы нам потребуется уточнить, какими ресурсами обладают выделен-

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

Варианты описания ресурсов и информационных потоков приведены в работе [4].

Прогноз информационной емкости системыОпределив основные направления информационных потоков и обозначив источники и прием-

ники информации, можно переходить к оценке информационной емкости системы.Здесь следует определить виды, а так же стартовый и плановый объем циркулирующей в систе-

ме информации. Почему важно сделать это именно на этапе первичного интервью?Потому, что это один из пунктов, позволяющий определить полезную информационную мощ-

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

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

Данные темы достаточно емки, и детальное их раскрытие заслуживает рассмотрения в рамках отдельной статьи.

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

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

Надеюсь, приведенная в данной статье информация будет полезна, для построения конструктив-ного диалога с вашими клиентами.

60 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



Список источниковКузнецова Т. Целеполагание по правилам //Новый менеджмент. – 2007. – №. 1.Детмер У. Теория ограничений Голдратта: Системный подход к непрерывному совершенствова-

нию /Детмер Уильям; Пер. с англ. – М.: Альпина Бизнес Букс. – 2007г. – 444С.Лич Л. Вовремя и в рамках бюджета: Управление проектами по методу критической цепи / Лоу-

ренс Лич; Пер. с англ. — М.: Альпина Паблишерз, 2010. — 354 с.Репин В., Елиферов В. Процессный подход к управлению. Моделирование бизнес-процессов. –

Litres, 2013.

61TRB A

RUSSIAN

IT

BUSINESS AN

ALY


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

Профессиональное развитие ИТ аналитиков и менеджеров; организация и аутсорсинг управле-ния и аналитических работ

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

Расписание открытых семинаров на IV квартал 2014г. (*)Основы функционального моделирования с применением вариантов ис-пользования

22 ноября 2014г.

Практика разработки технического задания на автоматизированные и ин-формационные системы

29 ноября 2014г.

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

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

Цикл Документарные технологии.Часть 1 - Базовые навыки создания технических и управленческих доку-ментов.Часть 2 - Методы проверки технического и управленческого текста.

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

Часть 3. Методы организации технического и управленческого текста Начало 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

Лаборатория системного анализа

Christine NatschlägerпереводНаталья Желнова

BPMN Business Process Model and Notation

63TRB A

RUSSIAN

IT

BUSINESS AN

ALY


BведениеBPMN является стандартом, опубликованным группой OMG, ориентированным на

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

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

Проблемы и целиСпецификация BPMN 2.0 занимает более 500 страниц. Определения элементов содер-

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

“Стартовое событие не ДОЛЖНО быть последующим элементом для потоков; у него не ДОЛЖНО быть входящих потоков”.

Кроме того, спецификация BPMN местами противоречива и запутана. Например, в ме-тамодели элемент Транзакция определяет два протокола атрибутов и метод как имею-щие тип string [1, стр. 176], но в соответствующем описании упомянут и определен только метод, как имеющий тип Transaction-Method [1, стр. 180].

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

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

BPMN (Business Process Model and Notation)

64 TRB A

RUSSIAN

IT

BUSINESS AN

ALY


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

Все эти проблемы не только затрудняют понимание 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Две других опубликованных онтологии 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, и классы, главным

65TRB A

RUSSIAN

IT

BUSINESS AN

ALY



образом, определены для конкретных элементов 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): Описывает отношение между двумя объектами.

66 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



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.

Рисунок 3 Аннотации для атрибута экземпляра stateСпецификация BPMN также предусматривает значения по умолчанию (например, у состояния

атрибута экземпляра есть значение по умолчанию None). Эти значения по умолчанию невозмож-но определить в монотонном OWL. Поэтому, в bpmn20base значения по умолчанию для онтологии

67TRB A

RUSSIAN

IT

BUSINESS AN

ALY



определены свойством аннотации 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. Второе ограничение определяет, что у него должен быть точно один маркер сворачивания

68 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



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

Свойство данных 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 как элементы, расположенные на том же уровне, что и другие элементы. Поэтому все классы долж-ны быть явными.

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

69TRB A

RUSSIAN

IT

BUSINESS AN

ALY



щает комбинации различных типов.• наследованные ограничения: так как ограничения наследуются, только элементы 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 и Embedded-SubProcess как подклассы 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, показаны

70 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



с префиксом «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; однако, значение свойства не может быть определено автоматически.

71TRB A

RUSSIAN

IT

BUSINESS AN

ALY



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

72 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



Рисунок 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]).

ОценкаПри оценке непротиворечивости и правильности онтологий использовались два различных ме-

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

73TRB A

RUSSIAN

IT

BUSINESS AN

ALY



конкретные модели 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 без (свойство non-interrupting) (см [1, стр. 242ff]), классификатор автоматически приходит к заключению, что элемент StartEvent должен иметь тип StartEventEventSubProcess как показано на рисунке 12. Однако, если мы определяем, что StartEvent имеет тип StartEvent-NotEventSubProcess, тогда все классификаторы сооб-щают о некорректности онтологии.

74 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



Рисунок 11. Пример 3Рисунок 10. Пример 2Рисунок 9. Пример 1

Пример 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. В конечном итоге, онтология противоречит всем логическим построениям.

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

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

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

Заключение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 содержит

75TRB A

RUSSIAN

IT

BUSINESS AN

ALY



дальнейшие синтаксические требования, взятые из текста спецификации 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, а также штатом Верхняя Австрия.

76 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



Ссылки 1. Business Process Model and Notation (BPMN) 2.0, www.omg.org/spec/BPMN/2.02. 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)

77TRB A

RUSSIAN

IT

BUSINESS AN

ALY


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

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

79TRB A

RUSSIAN

IT

BUSINESS AN

ALY


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

Мы все очень любим истории с хорошим концом. Например: «Мы создали свою соб-ственную систему управления требованиями. Ура!». Или: «Мы очень долго имели пробле-мы с заказчиком. Мы прочитали интересную статью, нашли уникальный метод, примени-ли этот метод и у нас все пошло здорово. Ура!»

Но, к сожалению, часто по окончании таких докладов единственное, что мы можем вы-нести - это чувство радости за докладчика.

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

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

На кого рассчитан данный доклад?Мой доклад рассчитан на людей, у которых в рабочем процессе возникают следующие

вопросы или ситуации:• каждый раз, когда заканчивается очередной этап нашей работы, или мы заканчи-

ваем разработку некоторого промежуточного артефакта, мы испытываем расте-рянность: а, что делать дальше?;

• мы хотим работать, но не знаем, как это делать правильно;• я руковожу группой аналитиков. Что им сказать? Как построить их работу? Как объ-

яснить, что сделано правильно, а что неправильно? Каков критерий этой оценки?;• передо мной сидит представитель заказчика, который готов вывалить на меня

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

В

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

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

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

80 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



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

Выходом может быть сценарий, который позволит вам шаг за шагом последовательно разрабо-тать некую систему моделей, каждая из которых сама по себе:

является самодостаточным и законченным артефактом, расширяющим ваше понимание бизнеса заказчика;

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

Этот сценарий позволит вам, во-первых, лучше понять бизнес заказчика, и, во-вторых, разраба-тывая каждую новую модель вы имеете возможность:

Согласовать эту модель (ваше понимание) с заказчиком;Предоставить готовую модель разработчикам. Таим образом все модели, которые будут разра-

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

Для начала я попытался проанализировать две ситуации, которые мы имели или имеем в IT- про-ектах.

Первая ситуация – это ситуация, когда разработка велась с полным отсутствием аналитиков в команде, или полным отсутствием анализа в проекте. Т.е. это ситуация, когда ни заказчик, ни про-ектная команда не готовы тратить время на проведение какого-либо анализа. У этой ситуации, без-условно, были свои плюсы (см. Рис. 1). Подобные ситуации продолжают иметь место, например, в проектах, проводимым с использованием подходов из семейства Agile.

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

81TRB A

RUSSIAN

IT

BUSINESS AN

ALY



рисков. Краткий анализ рисков ситуации полного отсутствия анализа в проекте приведен на Рис. 2

Рис. 2. Пожелания в разработку. Отсутствие анализа. Минусы

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

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

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

Чтоб избежать типичных минусов, необходимо провести полноценный бизнес-анализ. Что нам позволит проведение этого анализа?

82 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



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

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

83TRB A

RUSSIAN

IT

BUSINESS AN

ALY



Во-первых, (см. Рис. 5): на этапе бизнес анализа (БА) у нас есть возможность этот бизнес изучить. Для чего мы это делаем? Это не просто отвлеченное исследование ради интереса. Естественно, мы это делаем в интересах нашего проекта. Поэтому…

Во-вторых, у нас есть возможность — это понимание задокументировать либо в виде текстового описания, либо в виде моделей. Это та польза, которую мы получаем в рамках этапа БА. Для чего мы это делаем? Мы это делаем для того, чтобы…

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

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

Рис. 5. Выход из ситуации. Проведение полноценного бизнес-анализа

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

Я предлагаю некий сценарий (roadmap), который последовательно, шаг за шагом позволит нам систематизировано провести этап БА, и на каждом этапе получать какую-то значимую, с точки зре-ния нашего проекта, модель.

На чем основывается данный сценарий? На каком документе? Это документ «Описание Бизне-са».

Сложно ли получить это описание бизнеса? Абсолютно – нет! Получить этот документ несложно, так как он формируется естественным образом: общаясь с за-

казчиком, мы накапливаем какую-то информацию, пишем на доске потом снимаем это на телефон,

84 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



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

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

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

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

работу).

85TRB A

RUSSIAN

IT

BUSINESS AN

ALY



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

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

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

Поскольку бизнес-правила уже “выдернуты» нами из описания бизнеса, мы уже сейчас можем их

86 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



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

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

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

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

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

И последнее.

87TRB A

RUSSIAN

IT

BUSINESS AN

ALY



Несмотря на то, что БП не являются требованиями, и это очень важно понимать, они оказывают сильное влияние на требования. Они влияют на объем требований и на внутреннюю структуру тре-бований.

В некоторых ситуациях БП выполняют роль предусловий. Например, если мы описываем тре-бования в виде вариантов использования (ВИ), то там всегда есть precondition. Роль precondition может выполнять бизнес-правило.

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

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

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

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

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

Рис. 9. Описание бизнес-действующих лиц и их бизнес-целей

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

88 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



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

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

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

89TRB A

RUSSIAN

IT

BUSINESS AN

ALY



бизнеса (внутри бизнеса), мы изображаем в виде Business Workers в соответствии с требованиями нотации (в виде кружочков). Те Бизнес Действующие Лица, которые функционируют за пределами бизнеса и взаимодействующие с изучаемым бизнесом - поставщики, покупатели, посредники - изо-бражаются в виде Business Actors.

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

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

Рис. 11. Business Activity Diagram

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

90 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



щее понимание бизнеса, чтоб с этим документом прийти к заказчику и получить его согласование.Следующий шаг моделирования - это построение Business Activity Diagram (см. Рис. 11).Каждое действие, описанное нами в предыдущем шаге, мы с помощью текста либо диаграммы

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

Какую информацию содержат эти шаги?Шаги содержат следующую информацию:- “кто?» выполняет какое-то действие (пример: работник);- “что делает?» (пример: запрашивает отчет по работнику);- над какой информационной сущностью выполняется действие (пример: сущность “отчет по ра-

ботнику», или другая сущность «запрос на формирование отчета по работнику»).Далее мы не добавляя в эту модель никакой новой информации, просто перестраиваем модель в

виде Business Activity Diagram with Swim lanes (см. Рис. 12).

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

91TRB A

RUSSIAN

IT

BUSINESS AN

ALY



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

Например, на модели выделяется Swim Lane для «работника» и Swim Lane для «платежного адми-нистратора». И в соответствующие Swim Lane мы разносим действия, выполняемые именно этими Действующими Лицами.

Таким образом, информация “кто?» уходит из описания шага – она есть в заголовке Swim Lane; в шаге осталась только информация “что делает?» и над какой информационной сущностью выпол-няется действие.

Например, в Swim Lane “Работник» попадают только те действия, которые выполняются работ-ником.

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

Поэтому следующим шагом мы выделяем информационные сущности на модели в виде отдель-ного графического элемента (см. Рис. 13).

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

92 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



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

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

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

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

93TRB A

RUSSIAN

IT

BUSINESS AN

ALY



с заказчиком. Эта модель похожа на модель Бизнес Процессов (Business Process diagram). На рис. 15 изображена та же самая диаграмма, только уже в виде модели Бизнес Процессов.

На новой модели обозначены начало и конец процесса, а между ними - те же самые бизнес-дей-ствия, с которыми мы работали раньше. Бизнес действия также разнесены на именованные Swim Lanes.

Модель, представленная на рис. 14, очень простая. Эта модель была разработана исключительно в демонстрационных целях для данного доклада. Реальные модели бизнес-процессов могут быть гораздо сложнее демонстрационного примера и содержать гораздо больше информации, чем про-сто business-activity diagram с выделенными Swim Lanes.

Рис. 15. Диаграмма бизнес процесса (BPMN)

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

Я использую в своей работе Business Process Modelling Notation (BPMN), потому что данная нота-ция создана именно для целей моделирования бизнес процессов. Безусловно, UML тоже позволяет создавать такие модели, но с моей точки зрения, эта нотация более подходит для описания биз-нес-процессов, чем UML.

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

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

В моем опыте много прецедентов, когда мы отправляли модели бизнес процессов заказчикам, которые впервые видели модель Бизнес Процессов в BPMN, и это его не пугало, потому что мы со-

94 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



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

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

Возвращаемся к модели Business Activity diagram, включающей состояния объектов. На этой мо-дели мы выделили состояния информационных объектов и выполняемые действия, которые либо производят изменения, либо потребляют информационную сущность в качестве входного параме-тра (см. Рис. 13 или 14).

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

Бизнес-Процесса, какие действия приводят к изменению состояния этого объекта, какие действия потребляют этот информационный объект в качестве входной информации или предусловия.

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

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

ствиться только при выполнении некоторого условия;• какие дополнительные действия выполняются сразу после перехода в состояние, перед вы-

ходом из состояния, при нахождении в некотором состоянии. Эту информацию нам, как раз, и позволит зафиксировать последняя модель из этого сценария.

Это модель - State Machine diagram, или диаграмма состояний, или диаграмма-автомат (см. Рис. 16).На этой простой модели, разработанной в качестве демонстрационного примера, мы видим сле-

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

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

перехода в состояние – это не те действия, которые осуществляют собственно переход в из одного состояния в другое.

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

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

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

95TRB A

RUSSIAN

IT

BUSINESS AN

ALY



Рис. 16. Диаграмма Автомата (статусная модель)

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

Итого, я представил короткий сценарий того, как можно проводить Бизнес Анализ - последова-тельно от модели к модели.

Но мы планировали поговорить об Объектно-Ориентированном подходе. Все модели, которые мы уже обсудили, построены с использованием языка визуального модели-

рования UML. И, несмотря на то, что UML был разработан для Объектно-Ориентированного Анализа и Проектирования, рассмотренные модели не являются Объектно-Ориентированными.

Поэтому, для того, чтобы наш сценарий действительно был Объектно-Ориентированным, нам необходимо определиться, где же у нас Объекты и где у нас Классы. Как собственными силами, не прибегая к помощи Системных Архитекторов или Дизайнеров, уже на этапе БА, создать Модель Предметной Области (Domain Model) в виде Концептуальной Модели Классов?

Возвращаемся к модели Бизнес Вариантов Использования (Рис. 10).Мы извлекаем всю информацию об «управляющих», активных сущностях. Это те сущности, кото-

рые изображены в виде Business Workers и Business Actors. На основе этой информации мы создаем новую модель – Role Map (см. Рис. 17).

На следующем шаге мы преобразуем эту модель в модель классов, практически, просто заменяя изображения Действующих Лиц на изображения классов (см. Рис. 17). Хочу отметить, что уже на этом этапе мы вполне в состоянии провести доработку модели классов, например, выделить некий родительский или обобщающий класс, указать для него связи типа Обобщение (Generalization) с детальными классами и т.п.

Например, мы выделили классы «Работник с почасовой оплатой», «Работник с фиксированной оплатой» и «Работник, получающий процент от продаж». Уже сейчас мы можем выделить некий обобщающий класс «Работник», который будет содержать атрибуты и операции, общие для всех

96 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



типов работников.

Рис. 17. Role Map

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

97TRB A

RUSSIAN

IT

BUSINESS AN

ALY



Аналогичные действия мы выполняем на основе модели Бизнес Вариантов Использования (Рис. 9) для создания модели классов неактивных информационных сущностей (см. Рис. 19).

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

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

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

98 TRB A

RUSSIAN

IT

BUSINESS AN

ALY



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

Т.е. уже на этапе бизнес анализа, даже не приступив к разработке требований, не прибегая к по-мощи Архитекторов и Дизайнеров мы уже создаем артефакты, которые будут понятны и, главное, полезны разработчикам.

Этап бизнес анализа закончен, но мы понимаем, что бизнес анализ не является нашей целью. Наша цель – это разработка требований к программному обеспечению.

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

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

Откуда мы черпаем информацию о будущих Системных Действующих Лицах для нашего прило-жения? Мы получаем эту информацию из: • модели Бизнес Вариантов Использования (Рис. 9). Мы, практически без изменения, весь список

Business Workers преобразуем в список Системных Действующих Лиц. При этом мы понимаем, что Business Actors в список Системных Действующих Лиц не попадут. Почему? Потому, что они существуют вне автоматизируемого бизнеса. И если мы разрабатываем корпоративную систе-му, которая будет доступна только сотрудникам компании, и не будет доступна за пределами компании, то Business Actors взаимодействовать с нашей системой не будут и, следовательно, в список Системных Действующих Лиц включаться не должны;

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

• моделей Деятельности (Рис. 10-13), разработанных для каждого отдельного Бизнес Варианта Использования. Вспоминаем, в шагах этой модели мы описывали «кто?», «что?» делает и над какой сущностью выполняется действие. Информация «кто?», как-раз, и используется для по-полнения списка Системных Действующих Лиц.

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

Мы используем следующие разработанные нами на этапе БА документы:• список Действующих Лиц и их Задач (Рис. 8). Если заказчик указал нам на некоторые Бизнес За-

дачи и сказал, что они должны быть автоматизированы, то эти задачи становятся кандидатами на высокоуровневые требования к будущей системе (features);

• модели Деятельности (Рис. 10-13), разработанные для каждого отдельного Бизнес варианта Ис-пользования. Информация о том, «что?» делает активная сущность и используется для пополне-ния списка высокоуровневых требований;

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

99TRB A

RUSSIAN

IT

BUSINESS AN

ALY



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

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

Мы уже говорили о том, что БП могут быть предусловиями для требований, написанных в форма-те Вариантов Использования. БП могут описывать некоторые события, которые играют роль спуск-ного механизма для запуска на исполнение того или иного Варианта Использования. Это называет-ся Триггер (Trigger).

И последнее. Я предлагаю вам не верить мне на слово, а проверить в вашей практике. Если вы описываете требования в виде Вариантов Использования, и в этих вариантах использования есть разветвления типа: основной сценарий на альтернативный или основной на сценарии исключение, «виной» этому является некое зарегистрированное вами БП. Если срок записи на курс (1 месяц) не истек, значит Вариант Использования продолжает развиваться по основному сценарию. Если срок истек, то ВИ отправляется по сценарию исключению или альтернативному сценарию, в зависимо-сти от того, как вы это оформили.

Более подробную информацию о БП, их классификации, способах их регистрации, отличиях от требований и влиянии на требования, можно найти в моем докладе «Бизнес Правила – это не требо-вания. Нужно ли с ними работать?». Запись этого доклада можно легко найти в интернете.

russian it business analysis #2

Documents

russiatrb arussian

solutions value

hyperion planning

erp axapta

enterprise optimizer

luxoft training