Да - интересно, Антон. Тем более я сам хотел сделать нечто подобное но на более абстрактном уровне. Готов чем-то помочь.

Давайте начнем .
Скидывайте что вы конкретно хотели реализовать. Что есть "нечто подобное".

Антон, описанная вами проблема  хорошо знакома.
Смущает, что вы ищете решение именно в описании БП, не важно даже в каком инструменте.
Мне кажется, никакое описание БП не поможет правильно ранжировать хотелки бизнеса.

Вот скажите:
- Кто принимает решение, что вы ранжировали хотелки правильно? Вы сами? Владелец бизнеса? Аудиторы\консалтеры? Начальники отделов?
- Как вы видите описанные вами ситуации, после того как вы правильно описали БП в правильном инструменте? Начальник отдела приходит с хотелкой, а вы нажали кнопочку и говорите, эээ дружище чего-же ты меня с ROI то хочешь обмануть - приоритет 110 твоему проекту никак не больше. Или даже так, приходит к вам владелец бизнеса и говорит Антон, вот тут начальник транспортного цеха проект предлагает, что думаешь про ROI?
- Как вы думаете, ситуация, когда CIO принимает за бизнес решения чему развиваться, а у чего по хитрому описанию БП нет перспективы, она долго продлится? Думаю полгодика покряхтят все, а потом чего-нибудь и сделают с "оборзевшим" CIO. Благо повод будет - ИТ-отдел совсем перестал развивать собственно ИТ, а половину времени схему БП перерисовывает

Ситуация 1.

1. В оценке тех спец должен участвовать обязательно
2. Отрезать реквесты, кот превышают определенные трудозатраты: ну не может курица отложить страусиные яйца
3. Приоритет реквеста = К*Приоритет_Бизнеса/Трудозатраты
4. Требовать критерии у каждой задачи, которые должны быть достигнуты по факту внедрения, не достигнуты - по башке/снижение приоритета других реквестов и т.д.
5. Договариваться с бизнесом о выделении определенного времени на задачу в зависимости от трудозатрат, не соблюдают ...
6. Нужен чел, кот будет разрешать конфликты в приоритетах между разными нач отделами
7. Задачи/проекты больше определенных трудозатрат отдавать на аутсорс.

Ситуация 2.

См. п. 4 выше

Ситуация 3.

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

Сами Вы этот процесс не поставите, нужно привлекать каких-то топов, да хотя бы ИТ директора.

Антон, описанная вами проблема  хорошо знакома.
Смущает, что вы ищете решение именно в описании БП, не важно даже в каком инструменте.
Мне кажется, никакое описание БП не поможет правильно ранжировать хотелки бизнеса.

Вот скажите:
- Кто принимает решение, что вы ранжировали хотелки правильно? Вы сами? Владелец бизнеса? Аудиторы\консалтеры? Начальники отделов?
- Как вы видите описанные вами ситуации, после того как вы правильно описали БП в правильном инструменте? Начальник отдела приходит с хотелкой, а вы нажали кнопочку и говорите, эээ дружище чего-же ты меня с ROI то хочешь обмануть - приоритет 110 твоему проекту никак не больше. Или даже так, приходит к вам владелец бизнеса и говорит Антон, вот тут начальник транспортного цеха проект предлагает, что думаешь про ROI?
- Как вы думаете, ситуация, когда CIO принимает за бизнес решения чему развиваться, а у чего по хитрому описанию БП нет перспективы, она долго продлится? Думаю полгодика покряхтят все, а потом чего-нибудь и сделают с "оборзевшим" CIO. Благо повод будет - ИТ-отдел совсем перестал развивать собственно ИТ, а половину времени схему БП перерисовывает

Про описания БП

Я уже писал выше - описания БП сами по себе мне не помогут  решить проблемы ранжирования. Из моего описания даже понятно какое именно место я уделяю непосредственно описанию БП и кажется даже привожу примеры.

И далее по теме, откуда вы взяли что я делаю ставку на  "правильно описали БП в правильном инструменте"  ? Я не знаю что такое "правильный инструмент и правильное описание БП". 
 
Про хотелки

Я бы не стал употреблять слово "хотелки". Большинство реквестов  - это проблемы, которые уже нанесли ущерб в рубликах и от которых надо закрыться. Я бы даже сказал, что от них закрываться надо было "ещё вчера". С другой стороны нельзя отрицать существование именно "хотелок", обусловленных какой то подноготной у ЗЛ. Ни я первый это описываю в общем то.   

Про решения

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

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

В общем, вы верно описываете крайность, когда CIO решает слишком много сам, но вы видели крупный бизнес, где это допускается ?. Я такое видел в мелких конторах и это неприятное зрелище.

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

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

1. В оценке тех спец должен участвовать обязательно
2. Отрезать реквесты, кот превышают определенные трудозатраты: ну не может курица отложить страусиные яйца
3. Приоритет реквеста = К*Приоритет_Бизнеса/Трудозатраты
4. Требовать критерии у каждой задачи, которые должны быть достигнуты по факту внедрения, не достигнуты - по башке/снижение приоритета других реквестов и т.д.
5. Договариваться с бизнесом о выделении определенного времени на задачу в зависимости от трудозатрат, не соблюдают ...
6. Нужен чел, кот будет разрешать конфликты в приоритетах между разными нач отделами
7. Задачи/проекты больше определенных трудозатрат отдавать на аутсорс.
См. п. 4 выше
Поставить процесс работы с реквестом жестко и соблюдать для всех реквестов, исключение - реквесты от совсем топа.

Сами Вы этот процесс не поставите, нужно привлекать каких-то топов, да хотя бы ИТ директора.

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

Антон,

У Вас какие-то противоричивые показания:

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

и

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

Думаете задача 1 сложнее задачи 2? Если вы с бизнесом не можете поставить правильно процесс выбора реквестов, то безусловно справитесь с внедрением системы качества БП?
Что-то либо Вы не договариваете, либо совсем какой-то запущенный случай. Хотя меня всегда пугает ситуация, когда одна сторона кристальна чиста, а другая по уши в дерьме шоколаде.

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

Кто определяет полезность? Бизнес
Кто определяет ресурсы и скорость разработки? Вы.
Так вот сделайте баланс из вас и бизнеса для достижения поставленной цели.

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

А без топа конечно вы процессы опишите спокойно и выберите, что вам нужно?!

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

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

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

о, пошла психодиагностика по интернету

сообщение устарело

Действительно, мы как то съехали с темы. Давайте лучше поговорим про то, что 3DS Cradle это, кстати ещё и идеальный инструмент выстраивания взаимодействия бизнеса и ИТ

сообщение устарело

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

Антон,
У Вас какие-то противоричивые показания:

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

Вообще тех, кто есть в моей организации   я классифицировал след образом:

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

Я не знаю как это называется в терминологии БА. Классификация : топ, среднее звено, высшее звено в данном контексте не прикладывается.


leha очень правильно замечает:
" У вас в организации есть большая(?) коммуникационная проблема между бизнесом и ИТ. Скорее всего по вине ИТ."

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

Т.е. инструмент я ищу нашел в рамках задания от них. Попутно я использую его и для своих целей, но об этом ниже.
 
 
Далее leha пишет:
"Вы довольно радужно видите как трудозатраты на моделирование БП так и результаты этого моделирования. И верите в волшебные Инструменты "

и bas пишет:
"с внедрением системы качества БП"

У меня нет задачи  делать модели БП или внедрять систему их качества, и при этом ещё пользоваться волшебными инструментами. Нет ну правда, где я такое говорил ?   Я вполне четко обозначил что у меня проблемы с ранжированием.  Да, я не обозначил какой масштаб моих задач и какое мое положение внутри холдинга, и что для меня бизнес, но я и не уверен что должен был всё это расписывать.

То, что я собрал в Cradle, больше похоже на трекер  "проблема - решения".  БП в виде элемента к проблеме сбоку прицеплен ради сортировки.
Описание БП сводится к тому, что него выставляется значение категории, которая очень приблизительно обозначает значимость этого БП.
Диаграммы я использую только для случаев, когда решение проблемы в изменении БП, и я делаю "было / стало". Иногда мне нужно понять, что предлагаемое решение не идет наперекор БП и для этого составляю краткую схему. Мало времени ещё прошло, но вроде пока это то что нам нужно. 

Далее про Хабаровск

Вообще моя команда  достаточно успешно делает проекты, если смотреть  именно с точки зрения разработки.   
Мы пилим решения только посильного масштаба с понятной пропускной способностью. Если посмотреть на все проблемы бизнеса(хотя их реальный объем я не знаю), которые подлежат техническому решению, то мы в лучшем случае закрываем процентов 5-10%, а может и меньше. Понятно, что внутри этих 5-10% задачи мелкого, иногда среднего масштаба.
Непосредственно стратегические задачи босов слишком большие для нас обычно, поэтому  "манипулировать бизнесом" - это не про нас. Манипулировалка маловата да и чем там манипулировать ? Очередью на конвейере однотипных задач ?

Мы работаем с одним руководителями, который как раз рулит вопросы ранжирования. Этот человек имеет дело с проблемами внутри и между минимум 8 компаний внутри холдинга. Мне иногда кажется что это очень много для этого человека и что проблемы систематизации такого объема данных неизбежны, потому что превышают человеческие способности. Особенно когда проблемами этих 8 организаций больше особо никто не занимается.
   
Отношение именно боссов к проблемам, которые решает моя команда такое: "все эти проблемы б д решены вчера", и никакого стратегического ранжирования с их стороны не задается. Мы просто пилим всё подряд и чем быстрее, тем лучше.   

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

Ещё один момент, где мы ошибаемся в ранжировании. Мы оцениваем проблемы перед ранжированием. Ошибки в оценке приводят и к ошибкам ранжирования. 
Инструмент не поможет в правильности оценки, но он позволит отслеживать где оценка проведена на должном уровне, а где ещё надо поработать.
В идеале нужно добиться чтобы в ранжировании не участвовали проблемы с мутной оценкой.

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

Ещё риски можно к решениям привязать и по тяжести ситуации с ними ранжировать

Вообще успешность этого мероприятия я вижу след образом:

1)  У нас есть средний показатель высвобожденных (человеко-часов / рублей/мес) за единицу времени работы команды. Задача минимум за счет более четкого ранжирования увеличить этот показатель на 50%.

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

Вообще очень много буков. Прошу простить, но мне стало интересно


И про вот этот кейс:

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

Если под "внедрить систему класса Х" понимается вопрос " посоветуйте что имплементить ?" Если да, то я спрошу про цели и область проблем, потому что как иначе я пойму что советовать ?  Нет, м. б. если бы у меня был менталитет аутсорсера, я бы наверное задумывался в сторону "что же мне такое посоветовать чтобы попроще продать внедрение".

Антон, как я понимаю, Вам стало легче и Вы теперь представляете себе, что нужно делать?! Уже хорошо

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

Вообще успешность этого мероприятия я вижу след образом:

1)  У нас есть средний показатель высвобожденных (человеко-часов / рублей/мес) за единицу времени работы команды. Задача минимум за счет более четкого ранжирования увеличить этот показатель на 50%.

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

А как Вы мерите 1ый показатель?
Вы уверены, что текущими силами сможете увеличить его на 50%?
П. 2 - это вообще не цель, это м.б. задачей при достижении 1ого показателя, если это "достижимо".

Про показатель:
Предлагаемый показатель "высвобожденные ЧЧ за единицу времени работы команды" лично мне не нравится (не говоря уже о том, что я вообще против того чтобы ИТ отвечал за ранжирование)

- 30 ЧЧ высвобожденных в каком-нибудь малозагруженном подразделении (скажем АХО) не равны 30 ЧЧ высвобожденных в каком-нибудь перегруженном месте (условно в колл-центре).
- Многие задачи вообще не высвобождают ЧЧ, при том что они объективно полезны. Например, что-то направленное на улучшение клиентского сервиса
- ЧЧ разных людей, как минимум, по разному стоят.
- Некоторых людей в организации лучше не огорчать. Даже если высвобождаемые ЧЧ у их проекта плохие.
- Заказчик склонен преувеличивать высвобожденные ЧЧ, чтобы сманипулировать результатами ранжирования. Верификация заявляенных ЧЧ нетривиальна и может требовать трудоёмкой эксперитизы.
- При таком подходе функциональность ваших решений будет неуправляемо "разбухать", что увеличит затраты на поддержку, затруднит делание Больших Проектов и снизит другие KPI ИТ (количество дефектов за период, например).
- Если заведёте такой KPI то в следующем отчётном периоде его настоятельно попросят повысить процентов так на 15
- Кстати, с увеличением размера команды этот показатель, скорее всего, снизится


Про увеличение команды:
Есть у меня теория, что поток мелких реквестов обычно интересует бизнес только на
предмет занять чем-нибудь команду между деланием Больших Проектов, исправления багов и задачек, которые реально интересует топов. Сделает команда 30 мелких реквестов или 50 бизнес волнует очень мало. Для компании в целом они ничего принципиально не меняют - высвобожденные ЧЧ будут потрачены на ещё какую-нибудь малозначимую хрень - не только вам веселее работать в большой команде. Предположу, что именно поэтому эту задачу у вас заделегировали чуть ли не на уровень ИТ. Т.е. наращивание описываемого вами KPI - это плохое обоснование для увеличения команды. Лучше это обосновывается под какой-то проект который топам заметен.


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

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

• - Специальный комитет, который утверждает [план ближайших работ]. Чем более влиятельны его участники тем лучше. На моей прошлой работе туда даже CEO входил (компания среднего размера - ок.1000 сотрудников). Подразделения-заказчики защищают свои доработки перед Комитетом. CIO, естественно, был участником комитета.
• - В большой компании, где я сейчас работаю, запросы поступают в особое бизнесовое Подразделение-Координатор, которое, среди всего прочего, курирует развитие нескольких взаимосвязанных систем. Подразделения-заказчики договариваются с менеджерами этого подразделения. Подразделение-координатор путём переговоров с ИТ, формирует скоуп следующего релиза системы.
• - Слышал про систему жетонов. Подразделениям-заказчикам раздаются жетоны из каких-то общих соображений. Эти подразделения покупают на эти жетоны время ИТ-подразделения. Тут много подробностей не знаю, сам слышал только рассказы.

Вобщем, вопрос ранжирования, в том или ином виде, остаётся за бизнесом. И это прекрасно, с моей точки зрения.