На смену BPM идет Adaptive Case Management (ACM)

Евгений Кочуров пишет: Кстати, об этом я как-то уже писал раньше: «Ахиллесова пята» процесса

Олег Захарчук пишет: Я тоже так думаю. Тем более, что этот вопрос уже поднимался в дисуссии: http://www.e-xecutive.ru/forum/forum4.../messages/

Спасибо, гляну чуть позже.

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

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

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

WBS можно применять на любом уровне. Ваш пример решается заведением задачи "подписание документа". При планировании работ устанавливаем срок и назначаем ответственного. Вуаля - задача по планированию решена! Далее вступают в силу обычные технологии управления проектами. При желании детализируем задачу (осуществляем декомпозицию) до подзадач "согласование с юристом" и "согласование с секретарем"...

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

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

Марат Максумов пишет: Я честно говоря, не понимаю, чем поможет ACM в предлагаемых к рассмотрению ситуациях. Давайте вот это обсудим, а?

Для примера, попробуйте взглянуть на процесс согласования договора не с точки зрения схемы процесса, а с точки зрения документа: в каких состояниях он может находиться (например: в разработке, на рецензии, на утверждении, в работе, исполнен), что в этих состояниях с ним можно делать, и каковы условия, по которым может изменять состояние документа. В итоге получится описание жизненного цикла документа. Останется сравнить модель жизненного цикла документа с моделями процессов, в которых этот документ участвует.

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

Там были еще слова "по возможности". Так что призывов действовать себе в ущерб у меня не было.

Марат Максумов пишет: WBS можно применять на любом уровне. Ваш пример решается заведением задачи "подписание документа". При планировании работ устанавливаем срок и назначаем ответственного. Вуаля - задача по планированию решена! Далее вступают в силу обычные технологии управления проектами. При желании детализируем задачу (осуществляем декомпозицию) до подзадач "согласование с юристом" и "согласование с секретарем"...

Хотел бы я посмотреть, как это будет работать на потоке хотя бы в 200-300 договоров в год.

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

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

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

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

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

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

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

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

Евгений Кочуров пишет: Там были еще слова "по возможности". Так что призывов действовать себе в ущерб у меня не было.

Речь не об этом - я не увидел управления данными процессами.

Евгений Кочуров пишет: Хотел бы я посмотреть, как это будет работать на потоке хотя бы в 200-300 договоров в год.

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

Марат Максумов пишет: Так есть же способ сокрытия малозначимых деталей (повышения читабельности) без потери работоспособности (машиночитаемости) который я описал выше - перенос деталей на отдельную диаграмму. В этом случае какие могут быть проблемы?

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

Уважаемые коллеги, добрый день!

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

Мы, собственно, такие системы и делаем, и отдаем заказчику вплоть до программных кодов, и учим специалистов настраивать бизнес-процессы в системе, естественно, далеко не всех..

Как-то так..

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

Интересная классификация, ранее не встречал. Как бы то ни было - система управления проектами позволяет оперативно управлять обоими типами процессов (задач).

Евгений Кочуров пишет: Этот способ на практике работает не всегда. А точнее, он вообще редко срабатывает, потому что "малозначимые детали" могут запросто содержать переходы практически в любое место процесса, в результате свернутый блок-подпроцесс тянется стрелками ко всем значимым блокам, как заправский паук :) И таких "паучков" у нас может быть по несколько штук на каждую диаграмму.

Речь о циклах? Вполне возможно, что Вы правы - у меня не настолько богат опыт проектирования бизнес-процессов.

Марат Максумов пишет: Речь не об этом - я не увидел управления данными процессами.

Простите, Марат, я еще не готов к тому, чтобы показывать, как должно выглядеть управление необратимыми процессами. И в самом начале четко объяснил, почему: мне не известны ни теории, ни реализации такого управления.

Марат Максумов пишет: В строительстве (где мало что можно сделать без систем управления проектами) не редкость управление в рамках одного проекта тысячами и десятками тысяч задач с завязкой на тысячи видов ресурсов. А теперь представьте что строительная организация управляет портфелем проектов, т.е. стоит задача одновременного управления десятками проектов с разделением между ними ресурсов (техника, материалы, люди). Хотите сказать, что Ваш пример более сложен?

Представил. Мой пример гораздо проще, что только усиливает смысл сказанного. Или я что-то не так понял?

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

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

Евгений Кочуров пишет: Представил. Мой пример гораздо проще, что только усиливает смысл сказанного. Или я что-то не так понял?

Я не понял в чем сложность ведения 200-300 задач "подписание договора" в рамках системы управления. Необходимые примеры вроде бы привел. Вообще говоря системы управления проектами зачастую опираются на системы документооборота.

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

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

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

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