Я сегодня переводил оглавление BABOK'а для нашего файлохранилища, и с удивлением обнаружил, что он посвящён в основном работе с требованиями. Вот это оглавление:

   1. Анализ предприятия
         1. Создание и управление бизнес-архитектурой
         2. Проведение исследований реализуемости
         3. Определение рамок проекта
         4. Подготовка экономического обоснования
         5. Проведение первоначального выявления рисков
         6. Подготовка пакета решений
         7. Выбор, запуск, управление и контроль хода проектов
   2. Планирование и управление требованиями
         1. Командные роли
         2. Стратегия разделения работы группы бизнес-аналитиков
         3. Определение подхода к управлению рисками требований
         4. Выбор видов деятельности по требованиям
         5. Управление масштабом требований
         6. Управление изменениями требований
   3. Выявление требований. Техники
         1. Мозговой штурм
         2. Анализ документации
         3. Фокус-группы
         4. Анализ интерфейсов
         5. Интервью
         6. Наблюдение
         7. Прототипирование
         8. Семинар
         9. Инженерный анализ
        10. Опросы, анкетирование
   4. Анализ и документирование требований
         1. Структурирование пакетов требований
         2. Создание модели предметной области
         3. Анализ пользовательских требований
         4. Анализ функциональных требований
         5. Анализ качества требований к уровню обслуживания
         6. Определение предположений и ограничений
         7. Определение атрибутов требований
         8. Документирование требований
         9. Валидация требований
        10. Проверка требований
        11. Модели данных и поведения
        12. Модели процессов и потоков
        13. Модели использования
   5. Передача требований
         1. Создание плана распространения требований
         2. Разрешение конфликтов требований
         3. Определение подходящего формата требований
         4. Создание пакета требований
         5. Проведение презентации требований
         6. Проведение формального пересмотра требований
         7. Заключение соглашения о требованиях
   6. Проверка решения
         1. Разработка альтернативных решений
         2. Оценка технологических возможностей
         3. Помощь в выборе решения
         4. Обеспечение удобства решения
         5. Поддержка процесса обеспечения качества
         6. Поддержка процесса реализации решения
         7. Передача сведений о влиянии решения
         8. Обзор и проверка реализации решений
   7. Основы бизнес-анализа
         1. Коммуникационные навыки
         2. Лидерские навыки
         3. Навыки решения проблем
         4. Знание бизнеса
         5. Знание IT
   8. Словарь

Да, очень интересно, но 372 страницы будет осилить трудно

Я сегодня переводил оглавление BABOK'а для нашего файлохранилища, и с удивлением обнаружил, что он посвящён в основном работе с требованиями. Вот это оглавление:

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

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

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

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

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

Однако бизнес-анализ сам по себе в нашем случае не нужен.

В каком-таком "нашем" случае? Есть документ, озаглавленный просто и незатейливо - "Руководство к Своду знаний по Бизнес-анализу". Никакого контекста, предметного уклона в IT нигде в реквизитах документа не указано. Открываем уже раздел 1.4.3 - с места в карьер - определение видов требований - пункт 2 - "Требования пользователей". Какие-такие пользователи в бизнесе??? ) Какое к чёрту "прототипирование"?

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

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

Если бы ЗЫИБА ясно сказали, что они пишут про Бизнес-анализ с целью выявления требований для по улучшению деятельности бизнеса посредством реорганизации и автоматизации, или хотя бы Business Analysis in IT, я бы понял, а в такой обобщённой формулировке, как сейчас, я вот этого крена от БА в Требования не понимаю.

Что такое "Бизнес-анализ" в вульгарном понимании, основанном на анализе самого термина?

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

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

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

В случае создания нового бизнеса БА используется для:
* Возможно, разработки модели бизнеса (хотя я это называю бизнес-проектированием, new business development)
* Анализа целесообразности нового бизнеса со всех сторон, прежде всего в терминах экономической выгоды (ROI, маржа). Тут же полезны имитационные моделирования и проч .и проч.

То, что всё это так или иначе может быть в ряде случаев связано с требованиями (К устройству будущего бизнеса и соответствующей инфраструктуры) - понятно. Но почему требования проходят красной нитью по всему БАБОКу - мне НЕ понятно. Финансовый анализ мне кажется терминологически гораздо ближе у БА (имхо, входит в него), чем какие-то там требования

Почему на обложке изображена логическая модель данных, в маленькой процессной части сказано про SSADM, ER, IDEF, UML, BPMN, а про ARIS'овские нотации ни слова?

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

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

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

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

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

Где мы упускаем, когда? Для чего заявлена тема "Целеполагание"? Кто первый полез в моделирование системы, вместо того чтобы сначала получше понять саму проблему?

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

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

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

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

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

Лично я не очень понимаю твою упертость в бизнес-анализ, целеполагание и прочее.
Не моя это область деятельности. Не я должен сам себе целеполагать. ИМХО и бизнес-аналитик не должен целеполагать, вернее он должен целеполагать в рамках создаваемого решения, устраняющего проблему.
Какую проблему? Возникла у некой организации проблема - падение темпов производства и уменьшение прибыли. В ходе анализа этой проблемы выяснилось, что это происходит от несвоевременности принятия решения. А это в свою очередь связано с запаздыванием получения статистических данных, а запаздывание связано с тем, что информация во многом собирается хоть и системно, но во многом в ручную, часто одна и таже информация дублируется, требуется много времени на обработку информации. Стратеги от бизнеса решают - да проблему можно попытаться устранить вероятно улучшением информационного фактооборота. Вот и дальше идет целеполагание. Приглашается ИТ-специалист и с ним начинается работа. У этого ИТ-специалиста есть свой бизнес-аналитик, который с одной стороны понимает нужды бизнеса. с другой стороны умеет мыслить в категориях требований и т.п.

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

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

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

Лично я не очень понимаю твою упертость в бизнес-анализ, целеполагание и прочее.

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

Самым элегантным и нужным бизнесу решением, имхо, является устранение ПРИЧИНЫ проблемы (если речь идёт только о проблеме, а не возможностях), а не погружение в процесс производства/внедрения софта.

Не моя это область деятельности. Не я должен сам себе целеполагать.

А ты кто?

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

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

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

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

И ты мне теперь будешь утверждать, что твои theiiba имеют в виду именно анализ вообще бизнеса?

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

А ты кто?

Я преподаватель. Если представить себе роль в ИТ-индустрии, то скорее тот, кто реализует решение

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

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

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

ИТ-специалист = фирма, которая реализует систему

Не обязательно цель вытекает из проблемы. Можно рассматривать бизнес-анализ как инструмент предупреждения проблем, инструмент мониторинга, что-ли?
Финансовый анализ, например, направлен более на мониторинг, чем на уяснение проблем с финансовыми показателями.
Вот читаю ваши посты и понимаю, что действительно, можно термин "Бизнес-анализ" рассматривать в широком и узком смысле.
Вигерс постоянно употребляет его в узком смысле.

Ребята! Я с вами полностью согласен.

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

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

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

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

Может, имеет смысл под бизнес-анализом понимать именно иследование бизнес-процессов - "широкий смысл".
А бизнес-анализ в узком смысле именовать "аналитикой требований"?

Может, имеет смысл под бизнес-анализом понимать именно иследование бизнес-процессов - "широкий смысл".
А бизнес-анализ в узком смысле именовать "аналитикой требований"?

Не, лучше приводить контекст, в котором мы говорим "бизнес-анализ". Вигерс и RUP его приводят (RUP правда несколько широко замахнулся поначалу) ...