Браво! Всё по делу :-)

Мне понравилось.
Изменило мое мнение о BP для небольших компаний.

Супер! Очень понравилось

Кстати, в связи с п.1 небольшие соображение возникли. В те 10% небольших компаний, которым нужно BPM, входят ли разработчики софта/консалтеры? Багтрекинг или обработка заявок саппортом в BPM-системе это - хорошо или лучше оставаться на уровне списка задач со статусами?

Багтрекинг или хелпдеск в BPM-системе - это ни в коем случае! См. п.3. Стандартный процесс, протекающий в одном подразделении. Причем процесс слабоструктурированный, с которыми BPMS пока справляются плохо (см. mainthing.ru/ru/item/216/) а стандартный софт - хорошо.

Хорошая статья, правильно обозначенная проблемная область. Я уже давно поймала себя на той же самой мысли, что и автор. Когда раздается звонок (или в личной беседе), и собеседник говорит о том, что его интересует система для управления бизнес-процессами, то первое, что я ему говорю: "Очень хорошо, Вы обратились по адресу, но зачем она вам нужна?" Думаю, что по имеющемуся у меня лично опыту, я могу кое-что добавить и кое-с чем не согласиться с автором.
Говоря о BPM автор, в данном случае, хоть и неявно, но говорит в большей степени о workflow-BPM или иначе human-BPM. А вот я в первую очередь пытаюсь всегда выяснить, какого типа процессы преобладают в компании - system или human ориентированные. Или точнее - какие из своих процессов они видят как объекты для BPM (поскольку обычно есть и те, и другие, и "немного и того и другого"). Как правило, при ответе на этот вопрос можно сразу определить, надо оно им или нет.
К примеру, ответ "я не знаю, я просто секретарь, и мне поручили узнать" говорит о том, что у этой компании достаточно низкий уровень зрелости, они, скорее всего, просто что-то об этом слышали. И руководитель, который делегирует подобные вопросы секретарю, не будет лично вникать во "весь этот BPM". И тут мы просто теряем время.
Иногда сразу становится понятно, что люди под BPM понимают простой документооборот. И даже если мне удастся убедить их, что BPM-система эту задачу может решить, и они купят софт, то это скорее всего тоже "дохлый" клиент, т.к. он еще не дозрел.
Дальше примерно то же, о чем написано в статье. Но только я не согласна, что если процесс еще не формализован в виде схемы или другого описания, то он не достиг зрелости. Иногда очень хорошо отлаженные процессы работают годами, но при этом по разным причинам его не описывают - нет специалистов, просто не надо было раньше и т.д. А иногда процессы так классно отрисованы, и даже на стене вывешены, а на деле не работают. Так что этот критерий для меня не является определяющим.
Кстати, количество сотрудников в компании меня тоже интересует, но с несколько другой точки зрения. Если в компании 25 человек, а в работу с системой планируется вовлечь 3-4-х, то зачем из пушки лупить по воробьям? Оправдает ли это затраты? Хотя были случаи, когда заказчик действительно аргументировал такую необходимость.

Согласен - отрисованность мне тоже показалась слабым критерием.

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

))) Ответ: мы такие штучные!

мелкооптовые что ли?

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

Максим

Если задаться вопросом - можно ли получить эффект от BPM в условиях, которые автор обозначил как неблагоприятные - то при желании, конечно, можно.

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

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

Анатолий,

полностью согласен. Про это и говорю - мне не кажется, что проблема в BPM, а проблема с BPM автора в этих областях. Впрочем статья полезна в любом случае, так как это такие известные недостатки BPM систем.

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

Статья отражает взгляд на BPM co стороны ProcessMaker, системы автоматизации потока работ.
В этом контексте полезна и интересна.
Но нельзя ставить знак равенства между BPM и потоком работ.
В современных BPMS внимание акцентируется не столько на автоматизации, но на управляемости и совершенствовании процессов.
Заслуживает уважения позиция автора, отсылающего клиентов к системам других вендоров. Тем более, что их становится все больше и они предлагают не только BPMS но и готовые решения на их основе. Эти решения могут быть применены не только для средних и крупных компаний, но и для начинающих и малых.

Николай

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

Если ставить целью не только автоматизацию, но и на управляемость процессов (governance) и непрерывное их усовершенствование, то 5 вопросам, приведенных автором, превратятся в 10. Один из дополнительных вопросов, навскидку: "есть ли в вашей компании служба качества или иные *выделенные* сотрудники, имеющие навык анализа и моделирования бизнес-процессов?"

"Честно говоря, то, что предлагается для управления проектами, большей частью – полное барахло (в особенности MS Project)"

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

Андрей

Какие проблемы - задайте вопрос автору, ссылка на оригинал имеется.