Форум Сообщества Аналитиков

Общий раздел => ПО Аналитика => Тема начата: anton morozov от 20 Августа 2013, 14:04:55

Название: Помогите с выбором инструмента для описания БП
Отправлено: anton morozov от 20 Августа 2013, 14:04:55
Добрый день, уважаемые.

Сейчас я отыгрываю роль системного аналитика + ui дизайнера в команде разработчиков. Мы внутри холдинга(=группа компаний).

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


Зачем мне это нужно  ?

Схема нашей работы сейчас след.:

К нам приходят бизнес, и просит: "Помогите нам автоматизировать то и то, помогите улучшить то и то, сделайте нам то и то."

Такое обращение мы называем "реквестом".

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

Реквест "лучше", если за меньшее количество ресурсов команды сможем высвободить большее количество Человеко-часов для какого-нибудь договорного отдела.

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


Что мне нужно от инструмента для описания БП:

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


Я работаю в ЕА над проектами по разработке смогу организовать всё что описал выше этим инструментом, однако мне интересно посмотреть, может есть что-нибудь специально для моего случая ?

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

С уважением, Морозов Антон.
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: pmle от 20 Августа 2013, 16:56:51
сообщение устарело
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: Denis Beskov от 20 Августа 2013, 18:14:43
Я связываю это с тем, что мы изучаем БП, не в том масштабе, в котором нужно.
Хочу описывать БП для того, чтобы видеть в нужном масштабе.
Кроме того, ряд реальных проблем мы просто не видим, потому что бизнес не догадается к нам обратиться с этим.
Антон, а у вас уже бы опыт, когда описание процесса помогло верно оценить потенциал для оптимизации?
Как описание процессов помогает вам «увидеть реальные проблемы»?
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: Denis Beskov от 20 Августа 2013, 18:17:36
Что мне нужно от инструмента для описания БП:

- нужно видеть БП в виде диаграммы (всё равно какая нотация)
- нужно чтобы один процесс имел 2 варианта: текущий и исправленный.
- нужно, чтобы в процессе было обозначено узкое место, т.е. проблема.
- нужно чтобы я мог видеть какие БП  в какой организации происходят
- нужно видеть БП между организациями с обозначением проблем в них, а ещё лучше чтобы было видно на стороне какой организации проблема в этом БП.
- желательно, чтобы проблемы имели теги, чтобы по ним можно было потом дергать БП со схожими проблемами.
- желательно, чтобы проблема была самостоятельной сущностью и имела поля, в которые я мог бы записывать разные стандартные данные.
Всё это можно сделать и в Excel – имитировать swimlane, раскрасить цветами, повесить тэги, сделать реестр проблем со ссылками на них из процесса – voila!
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: SALar от 20 Августа 2013, 21:21:08
Если именно для анализа, то ничего лучше FlyingLogic (http://flyinglogic.com/) я пока не видел. Применял в реальных проектах, потрясная вещь. Но сначала будет сносить крышу невозможность управления координатами элементов.

Если же всего лишь для описания, то можно и Visio использовать, и Excel, и PowerPoint
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: Galogen от 21 Августа 2013, 21:02:44
Если именно для анализа, то ничего лучше FlyingLogic (http://flyinglogic.com/) я пока не видел. Применял в реальных проектах, потрясная вещь. Но сначала будет сносить крышу невозможность управления координатами элементов.
То, что на сайте выглядит весьма привлекательно, но не очень убедительно. Ты бы мог какие-то примеры привести?
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: anton morozov от 26 Августа 2013, 16:58:10
Антон, а у вас уже бы опыт, когда описание процесса помогло верно оценить потенциал для оптимизации?
Как описание процессов помогает вам «увидеть реальные проблемы»?

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

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

Рецепт правильной оценки реквестов действительно не в составлении описания всем БП.
Расскажу текущую ситуацию, только слово "реквест" заменю на слово "проблема".

Итак, мне дано:

1. Тонны проблем.  О проблемах мне сигнализируют от всех компаний из всех отделов 24/7.
2. Метрики известных проблем в большинстве случаев заранее не сняты.  Тонны проблем мне вообще не известны.
3. Проблема сидит на каком-либо БП, но роль этого БП для бизнеса мне заранее не известна.  Представители бизнеса частенько эту роль преувеличивают, поэтому я не могу им 100% доверять. Всё приходится проверять.
4. Маленькая команда для решения проблем. Мне одним выстрелом нужно красиво завалить как можно больше сидящих рядом зайцев. Чем эффективнее моя команда стреляет, тем больше шансов, что мне её расширят и у меня появится больше ресурсов.
5. Отсутствует единая система хранения данных о проблемах и БП, поэтому я не могу проводить полноценный анализ.

Как я выбираю, какую проблему решать следующей?

1. Стараюсь понять для всех проблем на каком БП они сидят и какая роль у этих  БП для бизнеса.
Это как раз пункт, который дает ошибки в оценке. Даже если я знаю, что для отдела "А" я могу высвободить 3 человеко-часа/день за 80 часов работы конамады, а для отдела
"Б" 1 человеко-час за 90 часов работы команды, то это не всегда значит, что для успешности бизнеса нужно делать автоматизацию для отдела "А".
Т.е. я хочу сказать, что для правильной оценки одних метрик проблем недостаточно.
2. Снимаю метрики со всех известных проблемы в реальных цифрах, если это можно сделать вообще.
3. Найти решение, в котором можно было бы хранить и анаизировать все данные.
4. Пытаюсь найти смежные проблемы и попробовать убить побольше зайцев за один выстрел, ну или чтобы не плодить сущности.
5. Выбираю лучшую проблему ( выгода от решения/ затраты на решение), которая сидит на самом важном для бизнеса БП и пытаюсь её решить.   





Таким образом я отвечу на ваши вопросы:

1. "Как описание процесса помогло верно оценить потенциал для оптимизации ?" // тут я немного перефразировал

Голое описание БП не помогает в этом. В этом помогает осознание значения БП для бизнеса. Т.е. я должен знать каждый БП и понимать их значение до такой степени чтобы мог дать сортировку БП от наиболее важных к наименее важным для бизнеса. Это косвенно видно из диаграмм. В любом случае, оценивая БП, его описание не будет лишним.
 
Когда я говорил "мы изучаем БП, не в том масштабе, в котором нужно", я имел ввиду, чтобы  мне нужно понимание роли БП для бизнеса в купе с четко снятыми метриками проблемы, чтобы не делать ошибок в выборе лучших проблем для решения. Роль описания тут второстепенна.

2. "Как описание процессов помогает вам «увидеть реальные проблемы»?"

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

В чем мне помогают описания БП сами по себе ?

Удобно осмыслить как построить сценарии GUI.

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

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

Помогают сформировать архитектуру решения с заделом на группу сидящих рядом зайцев.


Немного сумбурно и нагружено получилось и может я вообще гоню  :) 
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: anton morozov от 26 Августа 2013, 17:19:52
Всё это можно сделать и в Excel – имитировать swimlane, раскрасить цветами, повесить тэги, сделать реестр проблем со ссылками на них из процесса – voila!

Да, но это же я могу сделать и в ЕА и делать выборки в бд для анализа.
Но ЕА немного тяжеловат и поэтому я спрашиваю что ещё есть.
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: anton morozov от 26 Августа 2013, 17:40:58
 попробую разные средства, и потом опишусь сюда что вышло.
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: Сергей Евтухович от 26 Августа 2013, 20:47:34
РроjjДа, но это же я могу сделать и в ЕА и делать выборки в бд для анализа.
Но ЕА немного тяжеловат и поэтому я спрашиваю что ещё есть.
Антон, по моему мнению ЕА нельзя назвать тяжелым. Используйте только нужные возможности ЕА и он будет достаточно легок.
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: anton morozov от 27 Августа 2013, 13:56:15
3SL Cradle оказался дороговат для моего случая.  Буду пились в ЕА пока.
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: pmle от 27 Августа 2013, 15:17:34
сообщение устарело
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: anton morozov от 27 Августа 2013, 16:28:05
Антон, а на EA у Вас приобретены лицензии?

Да, причем для работы и для домашнего использования.
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: korovin от 28 Августа 2013, 13:40:22
а почему о BizAgi (http://www.bizagi.com/) или ELMA (http://www.elma-bpm.ru)никто не говорит?!
Системы позволяют строить БП и метрики по ним. автору именно это и необходимо.. как я понял.
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: pmle от 28 Августа 2013, 15:06:41
сообщение устарело
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: pmle от 28 Августа 2013, 17:53:08
сообщение устарело
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: Galogen от 28 Августа 2013, 18:42:26
Конкретно в данном случае было проведено сравнение цен на лицензии разных классов. Если брать лицензию EA Standard Ultimate (23000руб), то ее нужно сравнивать с Cradle SE Pro (14600руб).  Очевидно, что Cradle дешевле. Об этом, кстати, когда-то писал Эдуард на uml2.ru, а он EA знает гораздо лучше меня.

Да, я подтверждаю слова Юлии. Правда, когда я делал это сравнение цен, то я шел от максимально возможного наполнения. Т.е. ЕА Ultimate - самая дорогая, но мне думается, достаточно иметь EA Corporate - а это существенно дешевле порядка 7 000 рублей.

Цитировать
Однако в общем случае такое сравнение некорректно, т.к. это все-таки инструменты разных классов, хотя и пересекающиеся по возможностям.
Также согласен с Юлией, что сравнение будет некорректным. Следует также учесть квалификацию того, кто планирует выполнять анализ. ЕА потребует существенных знаний SQL, знаний UML, например, в области формирования профиля. Хотя некоторые вещи в ЕА сделаешь проще и быстрее, но вот с разными связями не все так просто, трассировки можно анализировать по разным связям, но вот логические зависимости можно понять только для зависимостей (dependency) или агрегаций. Использование ассоциации будет указывать только на факт связности.
Сам ЕА, кстати, просто так не умеет делать impact analysis, хотя есть надстройки типа RAQuest, которые требуют еще дополнительного вложения, но суммарно может быть подешевле или на уровне с Cradle.

Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: Thinkler от 28 Августа 2013, 21:11:54
Хотя в EA 10 заявлена возможность проведения impact analysis, или я ошибаюсь?
http://www.sparxsystems.com/products/ea/10/
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: pmle от 28 Августа 2013, 22:49:56
сообщение устарело
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: anton morozov от 29 Августа 2013, 12:42:43
Антон, я думаю многим участникам поднятой Вами дискуссии было бы интересно узнать, чем именно не устраивает EA. Конкретизируйте, пожалуйста,  что значит "EA немного тяжеловат". Это позволит всем сэкономить время.


Я не вижу дискуссии тут никакой.
Я могу собрать в ЕА и других средствах и выложить. Можем хоть сравнение устроить. Нужно только время.

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



Я думаю тяжелость ЕА почувствуется только когда я в него запихну процессы для всех моих 8 организаций :(

На самом деле, тяжел ли ЕА для моей задачи можно будет сказать только когда я её выполю )
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: pmle от 29 Августа 2013, 13:07:04
сообщение устарело
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: SALar от 29 Августа 2013, 17:16:15
То, что на сайте выглядит весьма привлекательно, но не очень убедительно. Ты бы мог какие-то примеры привести?
На шкафу лежат несколько диаграмм с реальных проектов. Будешь у нас - заходи, покажу.
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: Galogen от 29 Августа 2013, 18:42:30
На шкафу лежат несколько диаграмм с реальных проектов. Будешь у нас - заходи, покажу.
Я почитал руководство. Это инструмент разработан под ТОС. Я согласен, что это вынос мозга. Об этом читать приятно в цели 2, но чтобы использовать! Если ты пользуешься и легко, то тебе уже пора в Санта-Барбаре местечко иметь :)
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: SALar от 29 Августа 2013, 21:03:30
Я почитал руководство. Это инструмент разработан под ТОС. Я согласен, что это вынос мозга. Об этом читать приятно в цели 2, но чтобы использовать! Если ты пользуешься и легко, то тебе уже пора в Санта-Барбаре местечко иметь :)
Да, инструмент разработан под ТОС.
Не скажу, что использовать было сильно легко, особенно учитывая, что я пытался делать полноценную верификацию по книге Детмера. Их руководство "Думаем с флаингложик" гораздо, гораздо проще Детмера.

А по поводу места в Санта Барбаре - владельцы российских фирм не заинтересованы в увеличении прибыли. Так что бизнес анализ им просто не нужен.
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: bas от 30 Августа 2013, 22:42:30
Что-то мне кажется, что Автор хочет быть умнее бизнеса, а это, как минимум, опасно, как максимум, очень и очень долго, а главное скорее всего не даст ожидаемого эффекта.

ИМХО проблема выбора реквестов решается проще:
1. Собирать раз в неделю/две/месяц по одному представителю от каждой единицы бизнеса и дать им самим выставить приоритеты, потом эти приоритеты соблюдать и только с разрешения ген дира что-то туда вкрячивать до след совещания (итерации).
или
2. Предложить метрики, с кот должны приходить реквесты, бизнес их заполняет и все само выстраивается, при конфликтах зовете нужных представителей от бизнеса.
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: SALar от 30 Августа 2013, 22:50:10
ИМХО проблема выбора реквестов решается проще:
1. Собирать раз в неделю/две/месяц по одному представителю от каждой единицы бизнеса и дать им самим выставить приоритеты, потом эти приоритеты соблюдать и только с разрешения ген дира что-то туда вкрячивать до след совещания (итерации).
или
2. Предложить метрики, с кот должны приходить реквесты, бизнес их заполняет и все само выстраивается, при конфликтах завете нужных представителей от бизнеса.
Гуру от менеджмента говорят, что без глубинных знаний это не работает...

PS. Первую теорему Деминга никто не отменял. А кто я такой, чтоб с ним спорить?
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: bas от 31 Августа 2013, 15:41:55
PS. Первую теорему Деминга никто не отменял. А кто я такой, чтоб с ним спорить?
В одиночку тоже мир не спасти, тем более без глубинных знаний того же Деминга...
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: anton morozov от 02 Сентября 2013, 14:10:25
Что-то мне кажется, что Автор хочет быть умнее бизнеса, а это, как минимум, опасно, как максимум, очень и очень долго, а главное скорее всего не даст ожидаемого эффекта.

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

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

Была приблизительно след. картина, когда ранжирование и прочие решения были полностью на стороне бизнеса:

Ситуация 1.
Много реквестов  не по зубам моей маленькой команде.  Зарефьюзить крайне сложно, потому что "так босс сказал" и местами проще было уволиться. Не рефьюзить я пробовал - провалил проекты, потерял команду, потом долго и болезненно её пересобирал.

Бизнес упорно не хочет понимать, что для больших реквестов нужно больше ресурсов.
Вот вы отдали ранжирование на откуп бизнесу. Он выделил "приоритетные" реквесты для себя, но при этом не готов выделять ресурсы на "самые важные для себя решения" 
Вам не кажется это странным ?

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

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

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


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

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

Если этого нет, и если вы относитесь к своей работе как перфекционист, то не анализируя реквесты самостоятельно,  вы рискуете получить много много много боли. Я в свое время получил.

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

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

Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: anton morozov от 02 Сентября 2013, 15:45:35
Кстати.

Я погорячился на счет цены Cradle. Там всё приемлемо.

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

Понятно, что мне понадобится пару месяцев чтобы всё обкатать и понять как это вообще всё работает.

Тут есть  вопрос к сообществу:

Я обещал сделать сравнение реализации в Cradle и EA своей задачи. Это действительно кому-нибудь интересно  ?
   
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: Galogen от 02 Сентября 2013, 16:17:29
Я обещал сделать сравнение реализации в Cradle и EA своей задачи. Это действительно кому-нибудь интересно  ?
Да - интересно, Антон. Тем более я сам хотел сделать нечто подобное но на более абстрактном уровне. Готов чем-то помочь.
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: anton morozov от 02 Сентября 2013, 16:22:29
Да - интересно, Антон. Тем более я сам хотел сделать нечто подобное но на более абстрактном уровне. Готов чем-то помочь.

Давайте начнем .
Скидывайте что вы конкретно хотели реализовать. Что есть "нечто подобное".
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: leha от 02 Сентября 2013, 20:01:50
Антон, описанная вами проблема  хорошо знакома.
Смущает, что вы ищете решение именно в описании БП, не важно даже в каком инструменте.
Мне кажется, никакое описание БП не поможет правильно ранжировать хотелки бизнеса.

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

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

Ситуация 2.
См. п. 4 выше

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

Сами Вы этот процесс не поставите, нужно привлекать каких-то топов, да хотя бы ИТ директора.
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: anton morozov от 02 Сентября 2013, 21:56:55
Антон, описанная вами проблема  хорошо знакома.
Смущает, что вы ищете решение именно в описании БП, не важно даже в каком инструменте.
Мне кажется, никакое описание БП не поможет правильно ранжировать хотелки бизнеса.

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

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

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

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

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

Про решения

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

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

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

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

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

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

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

Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: bas от 03 Сентября 2013, 16:11:19
Антон,

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

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

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

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

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


Сейчас процесс  поставлен во многих  принципах  именно так. Только у меня хед по контрорю качества, а не ИТ директор.  Вообще это капитанские принципы(= принципы капитана очевидность). Подтверждаю что такое возможно только при содействии какого-нибудь топа. Причем, это должен быть хоть сколько-нибудь компетентный в области аналитики и разработки человек.
А без топа конечно вы процессы опишите спокойно и выберите, что вам нужно?!
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: bas от 03 Сентября 2013, 16:16:52
Прикольный кейс получился, как раз для Аналитика:
Заказчик - хочу внедрить систему класса Х, посоветуйте мне какую.
Аналитик - а нет, давайте про цели сначала поговорим
:)
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: leha от 03 Сентября 2013, 17:39:32
Антон,  действительно упустил пару ваших постов из ветки обсуждения, поэтому некоторые мои мысли были не совсем по делу.

Лично у меня после перечитывания остались следующие устойчивые ощущения:
- Вы таки пытаетесь манипулировать бизнесом из своих соображений что хорошо, что плохо. И даже пытаетесь это как-то институализировать.
- У вас в организации есть большая(?) коммуникационная проблема между бизнесом и ИТ. Скорее всего по вине ИТ.
- Вы довольно радужно видите как трудозатраты на моделирование БП так и результаты этого моделирования. И верите в волшебные Инструменты :)
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: Denis Beskov от 03 Сентября 2013, 18:24:13
о, пошла психодиагностика по интернету
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: pmle от 03 Сентября 2013, 18:28:35
сообщение устарело
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: leha от 03 Сентября 2013, 20:29:45
Действительно, мы как то съехали с темы. Давайте лучше поговорим про то, что 3DS Cradle это, кстати ещё и идеальный инструмент выстраивания взаимодействия бизнеса и ИТ :)
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: pmle от 03 Сентября 2013, 20:47:14
сообщение устарело
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: anton morozov от 04 Сентября 2013, 23:03:32
За годы варки в своей ситуации глаз замыливается капитально. Реакция и вопросы leha и bas - это взгляд со стороны, которого мне крайне не хватает. 
Есть ощущение, что местами мутно понимаю свою ситуацию. За время темы я пересмотрел некоторые моменты. Позволю себе последнюю порцию оффтопика в надежде на избавления от этой мутности.     

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: bas от 05 Сентября 2013, 11:26:07
Антон, как я понимаю, Вам стало легче и Вы теперь представляете себе, что нужно делать?! Уже хорошо :)

Но все же начните для себя с четкой цели и далее уже оптимальных путей ее решения. Не забывайте, что цель должна быть SMART (http://ru.wikipedia.org/wiki/SMART).

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

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

2) Задача максимум - выбить ресурсов увеличить команду в 2 раза, чтобы работать было поинтереснее :)
А как Вы мерите 1ый показатель?
Вы уверены, что текущими силами сможете увеличить его на 50%?
П. 2 - это вообще не цель, это м.б. задачей при достижении 1ого показателя, если это "достижимо".
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: leha от 05 Сентября 2013, 14:19:27
Про показатель:
Предлагаемый показатель "высвобожденные ЧЧ за единицу времени работы команды" лично мне не нравится (не говоря уже о том, что я вообще против того чтобы ИТ отвечал за ранжирование)

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


Про увеличение команды:

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


Про процесс в целом:

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

Этот нехитрый расклад, рано или поздно понимают в большинстве организаций. Что, по моему опыту, с этим делается:
- Процесс создания реквеста максимально усложняется - нужно заполнить 100500 листов специальной хитрой формы, подсчитать хитрые показатели эффективности итд.
- Реквесты фильтруются путём утверждения по всей вертикали начальников подразделения, где работает заявитель.
- Реквесты фильтруются на входе в ИТ. Тут разные подходы я видел и слышал:
Вобщем, вопрос ранжирования, в том или ином виде, остаётся за бизнесом. И это прекрасно, с моей точки зрения.
Название: Re: Помогите с выбором инструмента для описания БП
Отправлено: anton morozov от 05 Сентября 2013, 17:53:37
Чтобы завести реквест нужно потратить 15 мин. Чтобы его реализовать- нужно не меньше дня.

У нас реализация недели по 1-3 на один реквест. Задачи на день - это скорее к починка аварий и подобное, но там надо просто починить скорее.

На счет метрик. Мы снимаем время выполнения задач в команде. Я могу сказать сколько времени ушло аналитику, кодинг на фиксы, развертывание и т.д в рамках проекта, его версии или на одну какую то задачу.

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

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

На счет цифры в 50%/ 9 мес. было бы точнее.  Положа руку на сердце, это почти отфонарно. Я не знаю в какую сторону тут думать чтобы сформулировать эту цифру. Знаю, что смогу заметить её в графике по нашей метрике.  :) НА этом мысли заканчиваются.

При таком подходе функциональность ваших решений будет неуправляемо "разбухать"

Поддержка наших же решений нас действительно давит. Чем больше пишем, тем больше поддерживаем.  Я не понимаю, что значит "разбухает".

Кстати, с увеличением размера команды этот показатель, скорее всего, снизится

Я тоже думаю снизится. Но если команду настроить нормально, то вернется в обратное положение. Суть не в показателе. Увеличение команды мне поможет выйти на проекты поинтереснее где побольше интерфейсов, аналитики и прочее. :) Я примитивный. Люблю когда в работе есть вызов и когда вижу в лицах заказчиков радость от того что мы им заимплементили. Ненавижу бесполезную работу в стол. 


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

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

Всё верно. На что потратят освобожденные ЧЧ решают другие люди.  Надеюсь что они хорошо решают.
Я не знаю как смотрят наши топы и на какие проекты. М.б им заметно только то, что у них с бизнесом всё ок или не ок.     

Если не получится с командой тут - перейду в другое место.  Буду там получать удовольствие от работы :) Я люблю аналитику и интерфейсы. Меня вполне устроило бы место в команде где всё решено и организовано до меня и без меня, когда можно идти и работать на благо компании/проекта.

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

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

Слушайте, а это очень полезная для меня информация.  :)
И теперь я пожалуй немного больше стал понимать что bas имел ввиду под Хабаровском.