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

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

У организаций нет и не может быть никаких целей.
Цель — это образ будущего.
Умение формировать образ будущего требует наличия у субъекта сознания, мышления, воображения.
Организация такими свойствами не обладает.

Цель — это образ будущего.

Это весьма неоднозначное определение, и чрезмерно расширенное.

Вот более каноническое
 

ЦЕЛЬ
Женский род
1.
Место, в к-рое надо попасть при стрельбе или метании, мишень.
"Попасть в ц."
2.
перен.
То, к чему стремятся, что надо осуществить.
"Ставить себе что-н. целью"

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

https://ru.wikipedia.org/wiki/%D0%A6%D0%B5%D0%BB%D1%8C

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

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

А контекст у нас тут задан — не военное дело, не приготовление картошки с мясом, а управление развитием организаций с участием информационных технологий.

А контекст у нас тут задан — не военное дело, не приготовление картошки с мясом, а управление развитием организаций с участием информационных технологий.

Если задан контекст управления развитием организаций, совершенно непонятно почему употреблен термин "образ".

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

Я повторю, что я тут пишу не для повторения привычного, а для формирования вызова этому привычному.

Добрый день, коллеги 

Давайте, вернемся несколько назад. Мне кажется тут снова возник вопрос терминологии.
По Вигерсу, бизнес-требование - это высокоуровневая бизнес-цель организации или заказчиков системы.
Отсюда следует, что бизнес-цель и бизнес-требование это одно и то же.
В википедии, также говорится, что Бизнес-требования — определяют назначение ПО, описываются в документе о видении (vision) и границах проекта (scope).
И я придерживаюсь этого определения. Т.к. с этим можно работать.

Как я понял, на этом форуме у многих иной взгляд на бизнес-требования и бизнес-цели. То о чем говорили Денис, Леонид и товарищ Humbert больше похоже на личные интересы ЗЛ. Мне кажется, личные интересы и бизнес-требования - все же разные понятия. Иначе, я просто не понимаю как с этим работать. Я не совсем согласен с позицией Дениса о том, что у организации не может быть цели. Организация - по сути общество, объединенное общими целями и интересами. А иначе, в чем тогда заключается работа бизнес-аналитика, если бизнес-цели это личные цели отдельных дядь и тёть.

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

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

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

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

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

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

Что в этой ситуации делать БА на стороне исполнителя?

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

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

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

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

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

У организаций нет и не может быть никаких целей.
Цель — это образ будущего.
Умение формировать образ будущего требует наличия у субъекта сознания, мышления, воображения.
Организация такими свойствами не обладает.

Хорошо, пусть будет "Цели владельцев предприятия". И цели прочих заинтересованных лиц. Эти цели хорошо разобраны в книге "Цель-2".

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

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

Хорошо, пусть будет "Цели владельцев предприятия". И цели прочих заинтересованных лиц. Эти цели хорошо разобраны в книге "Цель-2".

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

Хотя владельцам компании приятно слышать как можно чаще, что они самые главные  

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

Может и может. Но, как правило, не может.
Как правило: "Ну остальные то тоже это делали"

Коллеги,

ИМХО, как обычно, мы ушли от вопроса топикстартера, к вопросу смысла жизни (организации)...

Наверное, никто не будет спорить, что работать над проектом намного легче, если понимаешь цель его внедрения?! Можно и без целей, а тупо по сформулированной верхнеуровневым функциональным требованиям, но тут будут проблемы:
1. Сложно определить приоритеты и нужность той или иной функциональности
2. На сколько вглубь будут расти требования?
3. Как тот или иной впихиваемый функционал на этапе приемки отсеивать?

Но для реализации ИС нужно знать цели создания/внедрения системы, а не бизнес цели. Хотя опять же никто их не может сформировать и тем более БТр не прорабатывались до этого, что как правило приводит при внедрении ИС к изменению БП в т.ч., а в проекте к ругани Заказчика и Исполнителя: Заказчик думал, что это будет меняться, а Исполнитель не заложил это в стоимость.

Цели очень сложно выудить у Заказчика, тем более, если это внешний Заказчик (своих внутренних мы к этому уже приучили ). Поэтому можно задавать следующие вопросы:
1. Какие проблемы вы сейчас испытываете и как вы предполагаете, что ИС этому поможет? Потом можно плавно перейти к целям, если позволят.
2. Если на первый вопрос не хотят отвечать (ну вообще это полезно всегда), то спросить - по каким критериям будет считаться, что ИС внедрена успешно? Нужно выработать 2-4 критерия, записать и все будут счастливы. Наверное объяснять излишне, что формулировка "чтобы все ФТ удовлетворялись" не катит. Хорошо идти от отчетов по системе, н-р, отчет Обортка должен отображать то-то и то...