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

Т.е. я все-таки от себя постулирую тот факт, что понимание, анализ и поиск путей решения проблем бизнеса, задача не тривиальная и требует серьезной подготовки и солидного опыта. Я очень сомневаюсь, что выпускник скажем кафедры САПР, ИС или иной "программисткой" кафедры, может стать бизнес-аналитиком.

Вот даже среди форумчан, кто в своем послужном списке имеет такую красивую профессию как бизнес-аналитик имеет первичное или вторичное образование юриста, экономиста и т.п.

Давайте посморим еще раз, что пишет RUP. Возьмем методические указания Золотухиной.

Основными ролями в проектной команде по RUP, участвующими в бизнес моделирования являются:
•   бизнес аналитик (Business-Process Analyst);
•   бизнес проектировщик (Business Designer);
•   рецензент моделей бизнес процессов и моделей анализа бизнеса (Business-Model Reviewer).

Основными видами деятельности бизнес аналитика являются:
•   оценка организации заказчика;
•   определение и уточнение целей организации заказчика;
•   определение бизнес правил;
•   разработка словаря бизнес терминов;
•   выявление бизнес процессов и действующих лиц, инициирующих процесс или являющихся потребителями его результатов;
•   уточнение связей между бизнес процессами;
•   описание архитектуры бизнеса;
•   разработка рекомендаций по бизнес моделированию.
Результатами деятельности бизнес аналитика являются:
•   разработанные модели бизнес процессов и модели анализа или объектные модели, описывающие реализа-ции бизнес процессов;
•   подготовленные документы:
•   документ Оценка автоматизируемой организации (Target-Organization Assessment);
•   документ Архитектура бизнеса (Business Architecture Document);
•   документ  Словарь предметной области (Business Glossary);
•   документ  Бизнес правила (Business Rule);
•   документ  Концепция развития организации (Business Vision);
•   документ Дополнительные требования к деятельности организации (Supplementary Business Specifications);
•   документ Рекомендации по бизнес моделированию (Guidelines).

Основными видами деятельности бизнес проектировщика являются:
•   описание бизнес процессов;
•   определение участников бизнес процессов;
•   детальное описание участников бизнес процессов;
•   детальное описание бизнес сущностей;
•   определение требований к системе на основе документов и моделей.
Основными результатами деятельности бизнес проектировщика являются:
•   документ Описание бизнес процесса (Business Use Case);

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

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

Как мы видим процесс бизнес-моделирования включает как минимум три различные роли. Вопрос кто делает эту работу? Сам заказчик? Фирма-разработчик? Или сторонний системный интегратор?

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

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

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

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

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

Вопрос в каком объеме и какой аналитик. Аналитик сам по себе? Аналитик информационных технологий, Бизнес аналитик, Аналитик-архитектор, Системный аналитик.

Анализ это метод  им пользуется, как ты правильно заметил, любой здравомыслящий профессиональный работник.

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

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


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

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

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

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

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

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

1. Быстро изучаю отрасль, в которой занято предприятие - нормативные акты, отраслевые стандарты, конкуренты, потребители продукции, сама продукция.
2. Заинтересованные лица - руководитель предприятия, ключевые менеджеры. Интревью с ними позволяет понять что их тревожит - конкретные проблемы, ощущения, падения показателей, недостаток информации.
3. По списку проблем отрабатываю бизнес-процессы, пытаюсь их моделировать. Здесь приходится и статистические показатели смотреть и финансовые, и временные задержки, ресурсы.
4. Повторное интервью с ключевыми фигурами - представление им понимания проблем, их масштабов. Здесь выясняются их ожидания и готовность тратить ресурсы. выясняются ключевые работники, уточняются процессы.
5. Интервью ключевых работников - уточняются оценки, модель.
6. Рекомендации - автоматизировать/не автоматизировать. В качестве шаблона стараюсь использую vision Вигерса.

Можно начинать пинать ...

Можно начинать пинать ...

Пинать Вас (а может лучше просто тебя? в древнеруссоком Вы означало тьму ) абсолютно не за что.

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

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

Клиент: "Катастрофа! телефон работает но вызовной звонок не работает. Что делать?". Мастер: "Не надо волноваться, давайте проанализируем. Почему не срабатывает звонок?" Клиент: "Может напряжение вызова не достигает порогового значения?" Мастер: "Я вижу вы мыслите логично. Что мы можем сделать? В чем причина? А так у вас спаренный телефон? Думаю вероятная причина плохой коэффициент отсечки тока в СОС. Давайте попробуем поставить вот другой более современный СОС. Вот видете - теперь все отлично"

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

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

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

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

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

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

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

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

Очень типичный ответ: ты придумай, а мы типа посмотрим.

С другой стороны тип задачи действительно информационный. Это не такая задача как: Нужно каким-то образом повысить прибыль на Х% за Y месяцев.

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

Это я прекрасно понимаю. Я сам сталкивалься с этим.

Пример из жизни:
Заказчик(приятель): Слушай, а ты нам не можешь сделать какой-нибудь компьютерный учет в моем магазине?
Я: А тебе , что денег некуда девать?
З: Ну понимаешь век компьютеров, а у нас учет идет на бумажках.
Я: Ну и чтобы ты хотел?
З: ну сделай мне чего там делают, чтобы типа все учитывалось.
Я: Окей, а как у вас все это делается?
З: Ой не доставай меня с этим вопросами - спроси вот у О.
Я: привет О., ну и как у вас это все тут делается
О: ну привозим товары записываем в тетрадку, размещаем на полках
Потом когда продана вещь, продавец выбивает чек и записывает все в тетрадочку.
Я: Хм, вы хотите поставить компьютер в магазин?
О: Нет нет, все записи из тетрадочки вечером буду сама наколачивать
Я: А зачем вам такая система? Что она Вам даст? Только лишнюю работу.
О: Ну может мы со временем и поставим комп в магазин.
Я: Ну чтож давай попробуем (далее идет ыяснение в основном деталей привоза, продажи и других разных практических вопросов)
Месяц спустя:
О: Какая замечательная программа, все так кажется удобным
Неделю спустя
О: Слушай а вот так можно? А вот это а вот здесь, а вот чтобы....
Я: Все возможно за ваши деньги:-)
Год спустя
З: Слушай я смотрвсем нравится твоя программа, покажика мне чего там в ней и как работает
2 часа спустя
З: ну что ты меня за лоха держишь? Что тут у тебя ничего не понятно, нифига не могу понять! Где например у тебя от это?
Неделя спустя
Я: Вот тебе это - доволен?
З: О зашибись, круто вся жизнь об этом мечтал
3 года спустя
З: Слушай никак не могу собрать свое мужество и понять как в твоей программе работать.
Я: Да там все же прозрачно - все твои девочки визжат от восторга и говорят все не сложнее чем писать в тетрадку.
Как то на пьянке
Я: Ну скажи после стольких лет - пригодилась тебе программа
З: Знаешь шикарная программа. Очень удобно формировать заказ на поставку, видно когда сколько и чего продали, четко рассчитывает зарплату с выручки, просто класс
Пару недель спустя
З: знаешь я тут посчитал сколько я выложил за программу за все время получилось около 30 штук.
Я: ну и что? У тебя есть претензии?
З: Да нет нет, вот жена хочет освоить, поучи ее
Я: нет проблем
Через месяц
З: ты знаешь мы от твоих услуг отказываемся (я мыслю - видно чем то я жене не понравился:-)))


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

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

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

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

Мне потом друзья сказали - ты типа с ума сбрендил - ты им считай КИС сварганил (ну это конечно преувеличение).

Так что все цели ставились практически мною. и мною же достигались:-))

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

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

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

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

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

Правда что-то мы не в тему тут уже дискутируем, тема то Роль бизнес-аналитика :-)

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

Понимаешь, тут проблема трактовки термина. И тут нужно быть очень осторожным.

В твоих словах можно уловить такой факт: цель <> назначение.
Однако семантически - это очень близкие слова, а порой простые синонимы.

Сравни: цель прибытия - пункт назначения.

Вот ссылка. Так для раскраски текста:-)

Предлагаю образовать раздел: Терминология или что-то в этом роде.

Раздел "терминология" нужен обязательно. Причем хорошо бы это сделать в каком то структурированном виде прямо на сайте в таблицы:
Термин / Определение / Кто сформулировал / Источник
Причем приводить следует термины как классиков, так и выведеные на форуме

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

Ну, окончательно-то мы не определимся никогда, как и по поводу любого термина, всё-таки это не "треугольник", а более абстрактное понятие. Я пытался делать нечто подобное для СА: раз, два, с теми же ощибками неуказания контекста.

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

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

Я очень сомневаюсь, что выпускник скажем кафедры САПР, ИС или иной "программисткой" кафедры, может стать бизнес-аналитиком.

Что значит "может-не может"? Захочет, жизнь заставит - сможет. Давай ещё скажем, что выпускник театрального училища не может стать президентом.

Вот даже среди форумчан, кто в своем послужном списке имеет такую красивую профессию как бизнес-аналитик имеет первичное или вторичное образование юриста, экономиста и т.п.

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

Давайте посморим еще раз, что пишет RUP. Возьмем методические указания Золотухиной.

Логика изумительная Что, Золотухина - представитель RUP'а на земле? "Давайте посмотрим ещё раз, что говорит Маркс. Итак, открываем Ленина...". Ты анализировал, насколько её текст соответствует настоящему РУПу?

... Возьмем методические указания Золотухиной ...

Несчитая тех опасных оплошностей, что она Business Use Case считает описанием бизнес-процесса, а Use-case - функции системы, её материал очень неплох.

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

Вопрос кто делает эту работу? Сам заказчик? Фирма-разработчик? Или сторонний системный интегратор?

Я понимаю, что практика в России такова, что нам нужен специалист, который "коня на скаку остановит, в горящую избу войдет".

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

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

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

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

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