Форум Сообщества Аналитиков
Дисциплины => Бизнес-анализ и Целеполагание => Тема начата: NewbieAnalist от 05 Февраля 2016, 12:22:16
-
Привет, коллеги!
Работаю в интеграторе, и так получается, что здесь больше занимаются системным анализом, нежели бизнес-анализом.
Иногда занимаюсь пресейлами и готовлю оценку в части анализа и дизайна. Клиенты присылают для оценки такие документы как БТ, RFP, BRD или ФТ. Как правило (80-90% случаев), эти документы не содержат бизнес-требований и бизнес-целей(!), а описывают набор необходимой функциональности.
В результате примерно понятно, что должна уметь делать система, но совершенно непонятно для чего планируется внедрение системы.
Проблема в том, что вопросы типа "для чего внедряется система?", "какой эффект планируется получить в результате?", "какие цели и бэкграунд у проекта?" воспринимаются... не очень хорошо.
Во первых, такие вопросы стараются не пропустить клиентские аккаунт-менеджеры и продавцы, во-вторых, сами клиенты не всегда нормально реагируют на это. :-\ А мне кажется, что это главные вопросы которые надо разъяснить в начале проекта.
Может быть вы сталкивались с подобным? Как бороться с такой проблемой, может я неправильные вопросы задаю? ???
-
А не надо задавать неудобные вопросы. :)
Вот Вам прям так и ответили, что этот проект у нас - для доосвоения всего объема годового бюджета, вот этот - уступка ЛПР заказчика Семен Семенычу с фирмой его сына "Суперсофт", этот - потому, что Екатерина Матвеевна метит в замгены по техническому направлению, этот - потому, что надо заплатить за работы прошлого полугодия, которые были выполнены формально за копейки. А вот этот вообще нам "сверху спустили", и для нас он как серп по тестикулам, поскольку своя аналогичная разработка на этапе завершения (реальный случай).
Как быть? Для начала прощупать почву у своих аккаунтов и продавцов. Не зря же они эти вопросы заворачивают? Два - если клиенты отводят глаза и воротят нос - не надо настаивать, спокойнее спать будет.
А в норме, если проект действительно для дела, то и на контакт идут охотно, и отвечают в меру откровенно.
-
Я, в общем-то, ожидал такого ответа. По вашему как-то совсем грустно получается. Что ни проект - то распил и освоение.
Видимо, очень многие думают подобным образом. Особенно аккаунты и продавцы. И в результате боятся задавать "неудобные" вопросы.
Даже если и проект для дела.
Ну т.е. правильно понимаю, что вопросы, в целом, нужные и нормальные. Но надо следить за реакцией, и, если что, переходить к следующим.
-
Что ни проект - то распил и освоение.
Вам на каждом проекте так вот "глазки строят"? Если да, то я бы подумал о смене места работы. От греха. А то мало ли - вдруг в соучастниках пойдете?
-
Вам на каждом проекте так вот "глазки строят"?
Ну зачем же так передергивать. Это из Вашего ответа такой вывод напрашивается. Мне бы не хотелось продолжать дискуссию в этом русле. Вашу точку зрения я понял.
-
Привет, коллеги!
Работаю в интеграторе, и так получается, что здесь больше занимаются системным анализом, нежели бизнес-анализом.
Всё правильно, вы же интегратор ИТ-систем, а не трансформатор бизнеса.
Иногда занимаюсь пресейлами и готовлю оценку в части анализа и дизайна. Клиенты присылают для оценки такие документы как БТ, RFP, BRD или ФТ. Как правило (80-90% случаев), эти документы не содержат бизнес-требований и бизнес-целей(!), а описывают набор необходимой функциональности.
В результате примерно понятно, что должна уметь делать система, но совершенно непонятно для чего планируется внедрение системы.
Это классика.
Проблема в том, что вопросы типа "для чего внедряется система?", "какой эффект планируется получить в результате?", "какие цели и бэкграунд у проекта?" воспринимаются... не очень хорошо.
Во первых, такие вопросы стараются не пропустить клиентские аккаунт-менеджеры и продавцы,
Вы аналитик? Вот и спросите у своих коллег, почему они их не пропускают.
во-вторых, сами клиенты не всегда нормально реагируют на это. :-\ А мне кажется, что это главные вопросы которые надо разъяснить в начале проекта.
Может быть вы сталкивались с подобным? Как бороться с такой проблемой, может я неправильные вопросы задаю? ???
А в чём именно заключается проблема? Проблема — эта ситуация, влекущая за собой существенный ущерб интересам ЗЛ. Ну не знаете вы целей проекта — и что? Вы перерабатываете из-за этого? Вас штрафуют, увольняют? Ругают?
Да, возможно заказчик использует деньги нерационально. Но вы за что отвечаете? За расходование денег отвечает ответственный менеджер заказчика, у которого может быть, а может не быть выделенный бизнес-аналитик, процесс обоснования проектов и т.д.
Вы со стороны подрядчика, помогаете ему продавать время разработчиков, чем больше продадите — тем лучше для компании и для сохранения вашего статус-кво.
Хотите больше работать со смыслом и эффектом — переходите на сторону заказчика в бизнес-аналитики. Но там 1) зарплаты меньше 2) политики больше 3) очень часто реальные цели всё равно скрываются, а в качестве обоснований делаются липовые документы.
Идеальный вариант, если хотите честного смысла — это пойти в посредники-консультанты (те самые "трансформаторы бизнеса"). Но рынок у них очень маленький, работа очень сложная, влияния мало, ответственность размытая. Поэтому тоже не всё гладко.
-
"Как бороться с такой проблемой, может я неправильные вопросы задаю"
Ну а если в лоб — устанавливать личные связи, наводить контакты, ходить с ними в баню.
Только как я писал выше — многие знания — многие печали.
-
Да что с вами не так-то. Вы сами себя слышите?
У каждого есть свои личные цели от проекта. Меня они не интересуют. Я полагаю, что помимо личных целей могут быть (должны быть) какие-то бизнес-цели, какое-то адекватное обоснование, которое должно помочь понять что и как надо улучшить.
Вас послушать, так получается, сказали что нужна красная, круглая кнопка, вот и делай. И не спршавай почему.
Вам нравится ваша работа? Довольны результатом? Я не имею в виду ваши зарплаты, бонусы и т.д
-
Я полагаю, что помимо личных целей могут быть (должны быть) какие-то бизнес-цели, какое-то адекватное обоснование, которое должно помочь понять что и как надо улучшить.
Похоже это вы пытаетесь решить за счет Ваших заказчиков личностные проблемы:)
Аналитик работает по озвученным целям клиента.
-
Похоже это вы пытаетесь решить за счет Ваших заказчиков личностные проблемы:)
Можете описать цепочку Ваших умозаключений, которые привели к такому выводу?
Аналитик работает по озвученным целям клиента.
Вот прям Браво! ;D
-
Я полагаю, что помимо личных целей могут быть (должны быть) какие-то бизнес-цели, какое-то адекватное обоснование, которое должно помочь понять что и как надо улучшить.
Бизнес-цели — это ничто иное как выражение совмещённых интересов Заказчиков, его коллег, руководителей и инвесторов. Конкретных людей.
Вас послушать, так получается, сказали что нужна красная, круглая кнопка, вот и делай. И не спршавай почему.
Аналитик, учитесь анализировать, а не инсинуировать.
Системный аналитик со стороны подрядчика — это ИТ-сметчик. Он помогает осметить хотелки заказчика. Может задать вопросы о цели, предназначении and everything. Вам может быть ответят. Если не ответят и вы этим недовольны, то можете уйти в другой проект, компанию, дворники. А можете учиться задавать аккуратные вопросы, нарабатывать опыт и квалификацию, двигаться в сторону бизнес-аналитика.
-
Я повторяю — если во фразе "Во первых, такие вопросы стараются не пропустить клиентские аккаунт-менеджеры и продавцы," продавцы — это ваши коллеги, то вы спрашивали у них, почему они так себя ведут?
-
Похоже это вы пытаетесь решить за счет Ваших заказчиков личностные проблемы:)
Аналитик работает по озвученным целям клиента.
Большинство аналитиков работает не по озвученным целям, а за регулярный доход. Чем больше и регулярнее доход, тем лучше для аналитика. Размер и регулярность дохода зависит от заслуг при достижении не только озвученных, но и скрытых целей
-
Похоже это вы пытаетесь решить за счет Ваших заказчиков личностные проблемы:)
Можете описать цепочку Ваших умозаключений, которые привели к такому выводу?
Собственно почти все сказал Denis Beskov
Бизнес-цели — это ничто иное как выражение совмещённых интересов Заказчиков, его коллег, руководителей и инвесторов. Конкретных людей.
К этому хочется добавить, что это реальные цели конкретных людей. Они могут сильно отличатся от тех, которые описаны в умных книгах, и даже от тех, которые вы считаете правильными. Но они не обязаны быть правильными или неправильными - они такие, какие они есть. У вас похоже были какие-то завышенные ожидания от этой профессии - это вовсе не профессия самого главного умника, а самая обычная технологическая профессия. Типа мусорщика или патологоанатома:) Есть инструменты, есть навыки , вы их используете.
Вот у весьма близких нам по характеру профессии психоаналитиков есть институт супервизии. Чтоб начинающий психоаналитик определился со своим предназначением - кто он врач или священник? Если первое, то он должен быть максимально осознанным в своих целях и не допускал проекции своей личности на клиента. А если уж очень хочется это делать, то профессию лучше менять.
Аналитик работает по озвученным целям клиента.
Вам может быть ответят. Если не ответят и вы этим недовольны, то можете уйти в другой проект, компанию, дворники. А можете учиться задавать аккуратные вопросы, нарабатывать опыт и квалификацию, двигаться в сторону бизнес-аналитика.
Да, именно так. Чтобы задавать вопросы, устанавливать контакт и получать информацию Вы должны быть психологически абсолютно нейтральны, а этого порой добится гораздо труднее, чем освоить пару нотаций или разобраться в сложнейшей системе показателей
-
Эта статья http://egorovde.ru/archives/1484 (http://egorovde.ru/archives/1484) не отвечает на исходный вопрос, но полезна, как один из элементов пазла.
"Конкретные цели, конкретных людей" - логично, что они могут не соответствовать целям организации.
- "Ты зачем систему учета внедряешь, а как же я воровать буду?" - в РФ такое встречается повально.
Но бал правит более клинический случай. Почти каждый собственник предприятия в РФ готов пойти на все, даже на разорение, только бы не менять свой стиль управления.
-
Кстати. Крайне рекомендую фильм "Игра на понижение". Прекрасное описание, как менеджеры ведут свои фирмы к гибели, просто потому, что не желают включить мозг и пять минут подумать.
-
"Конкретные цели, конкретных людей" - логично, что они могут не соответствовать целям организации.
У организаций нет и не может быть никаких целей.
Цель — это образ будущего.
Умение формировать образ будущего требует наличия у субъекта сознания, мышления, воображения.
Организация такими свойствами не обладает.
-
Цель — это образ будущего.
Это весьма неоднозначное определение, и чрезмерно расширенное.
Вот более каноническое
ЦЕЛЬ
Женский род
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 критерия, записать и все будут счастливы. Наверное объяснять излишне, что формулировка "чтобы все ФТ удовлетворялись" не катит. Хорошо идти от отчетов по системе, н-р, отчет Обортка должен отображать то-то и то...
-
1. Могли бы написать перечень ответов которые вы бы хотели получать? Среди всей переписки мне не ясны Ваши требования к ответам.
2. В любом ТЗ или уставе проекта(по крайней мере я стараюсь так делать) указываются цели внедрения системы и это как раз бизнес цели только не самого верхнего уровня, указываются процессы, которые должны быть автоматизированны.
Пример целей внедрения системы,
- Автоматизация функции бюджетного контроля;
- Создание инструментов для анализа: своевременности оплаты; выставления первичных документов; сроков поставки; исполнительской дисциплины по бизнес-процессам ..........;
Мы исполнителям спускаем такие цели, и этого вполне достаточно. А вот на вопрос для чего мы хотим контролировать оплату, поставки и т.д. Вам вряд ли кто ответит. Это уже как писали выше личные отношения уровня руководителей проектов или выше.
-
Пример целей внедрения системы,
- Автоматизация функции бюджетного контроля;
- Создание инструментов для анализа: своевременности оплаты; выставления первичных документов; сроков поставки; исполнительской дисциплины по бизнес-процессам ..........;
То что вы указали в качестве целей, - являются задачами, а не целями.
Об этом уже много раз говорилось, в том числе и на данном форуме.
-
.. Организация - по сути общество, объединенное общими целями и интересами. А иначе, в чем тогда заключается работа бизнес-аналитика, если бизнес-цели это личные цели отдельных дядь и тёть.
Работа заключается, в том числе, в выявлении этих разных интересов и целей, обнаружении сходств и конфликтов, помощь в выработке совместной групповой цели ЗЛ относительно конкретной инициативы.
-
То что вы указали в качестве целей, - являются задачами, а не целями.
Об этом уже много раз говорилось, в том числе и на данном форуме.
Буду признателен если подскажете где обсуждалось. Еще не все здесь просмотрел. По поводу отличие целей от задач готов подискутировать, так как цели бывают разных уровней и на данном уровне, этого вполне хватает исполнителям. К задачам я бы отнес разработку ЭП/ТП, загрузку данных, разработку пояснительных документов и т.д.
Так или иначе интересно, что для автора поста является целью внедрения системы которая его бы удовлетворила. Сильно утрируя главная цель любой коммерческой компании должна быть одна - зарабатывание денег (кажется это по Голдрату).
-
То что вы указали в качестве целей, - являются задачами, а не целями.
Об этом уже много раз говорилось, в том числе и на данном форуме.
Присоеденюсь к mironov.work. С удовольствием бы ознакомился бы с какой-нить литературой по этому поводу. Сейчас работаю с коллегами , которые уверенно различают между собой задачи, функции, цели... Но при этом мне их обьяснения кажутся несколько схоластическими. В процессном подходе все несколько проще - есть цель процесса, есть выходы процесса. При этом и то и другое определяется в реальности и легко проверяется на интерпретабельность.
-
Присоеденюсь к mironov.work. С удовольствием бы ознакомился бы с какой-нить литературой по этому поводу. Сейчас работаю с коллегами , которые уверенно различают между собой задачи, функции, цели... Но при этом мне их обьяснения кажутся несколько схоластическими. В процессном подходе все несколько проще - есть цель процесса, есть выходы процесса. При этом и то и другое определяется в реальности и легко проверяется на интерпретабельность.
Можете посмотреть вот эту ветку форума http://www.uml2.ru/forum/index.php?topic=177.0 (http://www.uml2.ru/forum/index.php?topic=177.0)
Так же посмотрите сайт Сергея Нужненко, там есть хорошие материалы касательно работы с целями http://boatmanshome.ru/wiki/wacko/?page=BoatmansHomeStart (http://boatmanshome.ru/wiki/wacko/?page=BoatmansHomeStart)
-
По поводу отличие целей от задач готов подискутировать, так как цели бывают разных уровней
Более того, что для одного цель - для другого может быть задачей. И наоборот. И все это - в рамках одной "системы" (не ИТ-системы, а системы в широком смысле).
Уверенно судить о том, что есть цель, а что - задача, можно только заняв определенную позицию.
К задачам я бы отнес разработку ЭП/ТП, загрузку данных, разработку пояснительных документов и т.д.
Если я - РП, я бы отнес туда же. Однако я зову аналитиков Иванова и Петрова, и ставлю им задачу: "Значит так. Нам нужен удобочитаемый черновик ТП завтра к утру. Поэтому ты, Иванов, пишешь 2-й раздел пояснительной записки, а ты, Петров - 3й. Завтра к 9 мне на стол!"
Итого, у меня задача - получить ТП к утру с целью продемонстрировать опережение графика и выбить под это дело некий задел на будущее.
У Петрова с Сидоровым задача - разработать свои разделы ТП, в целях его появления.
А все это затеял гендиректор моей конторы потому, что ему нужны козыри в предстоящих переговорах с заказчиком по всему портфелю проектов. Вот он и поставил мне (наряду с остальными РП) задачу их добыть.
Сильно утрируя главная цель любой коммерческой компании должна быть одна - зарабатывание денег (кажется это по Голдрату).
Не стоит настолько утрировать. Целей у коммерческой компании может быть масса, и зарабатывание денег может стоять далеко не на первом месте. Вполне достаточно утрирования о том, что коммерческая компания вообще может иметь цель, не обладая собственным разумом и волей.
-
Присоеденюсь к mironov.work. С удовольствием бы ознакомился бы с какой-нить литературой по этому поводу. Сейчас работаю с коллегами , которые уверенно различают между собой задачи, функции, цели... Но при этом мне их обьяснения кажутся несколько схоластическими. В процессном подходе все несколько проще - есть цель процесса, есть выходы процесса. При этом и то и другое определяется в реальности и легко проверяется на интерпретабельность.
Как правило, формулирование цели является наиболее сложным из всех видов работ по созданию ТЗ (34.602). Кроме того может иметь место прямой запрет заказчика на указание цели. В этом случае стоит поместить в этом разделе обтекаемые и ничего не значащие фразы, изложенные канцелярским языком. Предельно непонятные.
На почитать.
Из очень простого: Голдратт Элиягу, "Синдром стога сена"
Далее, его же "Цель-1"
Как ни странно, ГОСТ 24.104-85. Да, да от 1985 года.
--------------------
В подразделе «Цели создания системы» приводят наименования и требуемые значения технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания АС, и указывают критерии оценки достижения целей создания системы.
ГОСТ 24.104-85: Ввод в действие АСУ должен приводить к полезным технико-экономическим, социальным или другим результатам, например:
- снижению численности управленческого персонала;
- повышению качества функционирования объекта управления;
- повышению качества управления и др.
Отраслевая АСУ должна обеспечивать:
- улучшение характеристик объекта управления (повышение производительности труда в отрасли, повышение качества продукции, своевременное выполнение поставок продукции, снижение себестоимости выпускаемой продукции);
- совершенствование процессов обработки информации (снижение стоимости обработки информации, повышение достоверности исходных данных, повышение точности и оперативности расчетов);
- совершенствование организации выполнения функций управления (в частности, рациональное распределение работ между подразделениями аппарата управления, вычислительными центрами и научно-исследовательскими организациями и предприятиями).
-------------------
В 1985 госзаказчики и разработчики были гораздо более адекватны.
-
Не хотите быть уволенным - не занимайтесь выявлением бизнес целей.
-
Или более полно — если вы ссыте, не занимайтесь сложной и рискованной работой
-
А наш девиз - "Внедряй, поддерживай, не ссы" (с)
-
Я в общем соглашусь с Сергеем.
Часто реальные цели внедрения (в основном это конечно касается ERP-систем, но иногда относится и к не очень объемным задачам) лежат далеко за пределами стандартных формулировок "оптимизировать" "сократить" "улучшить" и не оглашаются. И речь вовсе не об "откатах".