Добрый день, уважаемые.

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

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


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

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

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

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

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

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

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


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

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


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

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

С уважением, Морозов Антон.

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

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

Антон, а у вас уже бы опыт, когда описание процесса помогло верно оценить потенциал для оптимизации?
Как описание процессов помогает вам «увидеть реальные проблемы»?

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

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

Всё это можно сделать и в Excel – имитировать swimlane, раскрасить цветами, повесить тэги, сделать реестр проблем со ссылками на них из процесса – voila!

Если именно для анализа, то ничего лучше FlyingLogic (http://flyinglogic.com/) я пока не видел. Применял в реальных проектах, потрясная вещь. Но сначала будет сносить крышу невозможность управления координатами элементов.

Если же всего лишь для описания, то можно и Visio использовать, и Excel, и PowerPoint

Если именно для анализа, то ничего лучше FlyingLogic (http://flyinglogic.com/) я пока не видел. Применял в реальных проектах, потрясная вещь. Но сначала будет сносить крышу невозможность управления координатами элементов.

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

Антон, а у вас уже бы опыт, когда описание процесса помогло верно оценить потенциал для оптимизации?
Как описание процессов помогает вам «увидеть реальные проблемы»?

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

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

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

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

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

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

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





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

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

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

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

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

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

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

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

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

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


Немного сумбурно и нагружено получилось и может я вообще гоню   

Всё это можно сделать и в Excel – имитировать swimlane, раскрасить цветами, повесить тэги, сделать реестр проблем со ссылками на них из процесса – voila!

Да, но это же я могу сделать и в ЕА и делать выборки в бд для анализа.
Но ЕА немного тяжеловат и поэтому я спрашиваю что ещё есть.

 попробую разные средства, и потом опишусь сюда что вышло.

РроjjДа, но это же я могу сделать и в ЕА и делать выборки в бд для анализа.
Но ЕА немного тяжеловат и поэтому я спрашиваю что ещё есть.

Антон, по моему мнению ЕА нельзя назвать тяжелым. Используйте только нужные возможности ЕА и он будет достаточно легок.

3SL Cradle оказался дороговат для моего случая.  Буду пились в ЕА пока.

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

Антон, а на EA у Вас приобретены лицензии?

Да, причем для работы и для домашнего использования.

а почему о BizAgi или ELMA никто не говорит?!
Системы позволяют строить БП и метрики по ним. автору именно это и необходимо.. как я понял.

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