IgorTv

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


Шефы в бизнесе и бизнеспроцессах шарят больше, чем все ключевые пользователи и консультанты вместе взятые. Просто им проблематично въехать в каракули консультантов и ключевых пользователей. Ни те не другие обычно не в состоянии подняться над процессом и глянуть на все вместе. Вот и получается, что каждый рисует в своем маштабе и базисе. Красивые нотации типа OBM или АRIS по моему мнению только ухудшают положение. Когда все собирается вместе тяжело соотнести кривую карту и реальный вид местности. А в чем кривизна сообразить тяжело. Вроде все на месте и не подкопаешься, а глаз режет.

[quot Станислав C.]Кроме того, после описания бизнес-процессов на предприятии, становится понятным кто и чем занимается и как эффективно перераспределить обязанности между исполнителями. :) [quot]

И чем по вашему мнению подход на основе Бизнес-процессов лучше, чем функциональный?

Прохожий2Вопрос об альтернативе был тихо замят :)

Альтернативы.

1) Описание информационных потоков.
2) Описание системы документооборота.

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

IgorTv
Не согласен. Все уперается в лень топменеджеров. Методолгии типа ARIS или IDEF0 нормальное решение. Схемы с квадратиками и стрелочками достаточно наглядны.

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

P.S. "Лень и непрофисионализм" - я не правильно сказал. Скорее здесь идет речь о разных уровнях восприятия. Правильнее было сказать "Рожденный ползать - ..."

Semaphore
А Вы их видели, те, которые "правильно описанные"??

Нет не видел. И сам когда писал халтурил.


Semaphore

Alexey_МakienkoПротив квадратиков я ничего не имею против, но чтобы ими пользоваться надо еще больше професионализмаПростите, если Вы решили лететь самолетом, то Вы обязаны при этом быть профессиональным пилотом? Нет? А почему директор предприятия пригласив консультантов, должен быть профессиональным пользователем IDEFx?

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

SemaphoreПисали для серьезного предприятия или для "лавочки"?


Для разных от 200 до 10000тыс.чел

Semaphore
Ваше высказывание ("с первого взгляда") навевает размышления...

Теперь попросите профессионалов верифицировать созданные ими описания "бизнес-процессов".


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

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

GoBeer
Хорошая аналогия с телом :)
Я знаю что у меня есть нога и какие ф-ции она может выполнять. Если нога плохо выполняет свои ф-ции я обращаюсь к консультатну, к-й знает устройство этой ноги досконально. Если у меня нет денег и я буду заниматься самолечением, то скорее всего так и буду хромать :( Но если я немного знаю об устройстве ноги, значит некоторые легкие симптомы я способен исправить сам.


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

Станислав C. GoBeer А описание БП нужно например для того, чтобы составить и подписать договор на внедрение (поправьте если я не прав).
Все-таки это не так. Договор может быть подписан и без БП. А описание БП, ИМХО, нужно для определения "фронта работ", чтобы представлять с чем имеешь дело... Ведь даже на предприятиях одной отрасли БП могут достаточно сильно отличаться в деталях...

Ну вот и ответ на вопрос "Кому нужны БП?".

Владимир11 Прохожий2to Semaphore
Возвращаясь к исходному письму - альтернатива описанию БП - ?

Альтернатива - текстовое описание, которое будет занимать в зависимости от подробности - от 500-700 страниц. Тоже самое в Idef и dfd - 60 схем + 50 листов пояснений. Заставить сотрудников клиента почитать, понять и верифицировать 500-700 листов нереально... С точки зрения трудоемкости, легче 2 недели потратить на объяснение основ IDEF, чем 2 месяца ждать , когда клиент вычитает текстовое описание...



- Это описание MRP2 http://citforum.proc.ru/cfin/mrp/mrp2.shtml скорее всего по сути вы уже прочитали десятки таких статей и ничего нового не узнаете. Но по теме дискусии можно прикинуть, как преобразовать, эту статью в ТЗ или описание текущих будущих БП.
Ну на первый взгляд:
Добавить структурную схему предприятиях.
Описать материальные потоки
Расписать процессы по подразделениям в том числе линейным.

Таким образом эта статья вырастет в раза 3. Это далеко не 500-600 страниц. В тоже время легко читаема любым пользователем.

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


Мои выводы из сравнения.
Если мы пишем документ для ТОПов это текстовое описание с достаточным количеством рисунков, диаграм схем. Схемы могут быть различного направления: бизнесс-процессов, материальных и информационных потоков, документооборота, организационная диаграмма и т.п. Но все хорошо в меру. Например, бизнес-процессы должни быть только ключевые. Документ должен быть 50 -80 страниц. И написан должен быть написан в терминах принятых в организации.
Такой документ реально позволит ТОПу увидеть картину в целом. И для него может быть даже полезем взгляд человека "со стороны". Так же его полезно перечитать консультантам. По нему можно судить, что же в конце концов они делают и как выглядит хорошо сделанная работа.
Однако, написание такого документа требует очень высокого мастерства консультантов. У меня в свое время вышло довольно криво.


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

И в конце концов ни кто не мешает включить в проект оба документа. По моему мнению это окупится.

Alexey_Мakienko

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


PS Забыл приаттачить

Владимир11

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


Я приатачил только часть, которая как и статья описывает процедуру MRP. Для сравнения. В целом все выглядит значительно хуже. И руководителю придется до-о-олго въезжать, что к чему.

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

Смежные процессы тоже не смог приаттачить по тому как ограничение 70к Однако если интересует остальное, то могу мылом.

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

В принципе очень правильный подход.

А про время и силы можно подробней типа с цифрами?

Semaphore
4. Подготовка ТЗ и проектной док. 5 дней 15 чел-дн.


Это с описаниями БП? По теме собственно топика.

А что за система?