checkmateОдин из бизнес-процессов из цепочки на текущий момент закрывает недавно внедренная бесплатная версия одной российской BPM-системы (Элма). Но на которой далее непосредственные пользователи работать не хотят по ряду причин, и руководство считает, что нужно другую программу подыскать, где всё сразу будет.Хотелось бы услышать, что за причины, по которым пользователи не хотят работать в BPMS.

У вас задача очень "неудобная" для существующих систем. Вам требуется ПО, в котором интегрировано в "один флакон":
- управление проектами (Project Management),
- управление процессами (Process Management),
- управление задачами (Task Management),
- бюджетирование,
- управленческий учет,
- бухгалтерский и налоговый учет.

Не стану ничего советовать. Просто предлагаю пробежаться по этому списку остальным участникам обсуждения. Многие озвученные предложения что-либо из этого списка "отодвигают" как что-то несущественное. Как я понял, тут всё существенное.

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

s_ustinovБлок 1:
- управление проектами (Project Management),
- управление процессами (Process Management),
- управление задачами (Task Management),Любопытно, что можно предложить в качестве этого блока. Те продукты, с которыми мне довелось поближе познакомиться, акцентируются, как правило, на чем-то одном из этих трех компонентов. BPMS, например, делает акцент на Process Management. Я подозреваю, что именно поэтому и не устроила Элма. MS Project, например, акцентируется исключительно на Project Management. Некоторые ERP-системы могут совместить эти две компоненты до какой-то степени и даже задействовать единый пул ресурсов в проектах и в процессах таким образом, что закгрузка ресурсов, их доступность и дефицит определяется вполне корректно. Но с Task Management в известных мне большие проблемы. Подключить в единый пул управления ресурсами задачи, возникающие спонтанно, сроки исполнения и результаты которых необходимо контролировать одновременно с контролем выполнения процессов и проектов... я такого, работающего по-человечески, не видел. Хотя эта задача вполне живописно решается в тривиальном MS OutLook.
И совсем уже большие проблемы возникают, когда процессы и проекты должны иметь возможность порождать друг друга. А также "задачи" порождать процессы и проекты. Когда процессы в качестве обработки исключений могут порождать "задачи" (изначально плохо формализуемые).

checkmateТ.е. пользователи не привыкли работать процессноЭто нормально, так оно и должно быть. Процессность (или "регламентность") оставляет меньше свободы исполнителям, а более высокая степень контроля возможности посачковать от работы. Если это основная причина, то вам нужно как-то определиться, заниматься по-человечески внедрением Process Management или оставить некоторую степень хаотичности, неуправляемости, просто "плывя по течению". Если беретесь за подобную задачу, нужно быть готовым к тому, что ее придется "продавливать", преодолевая сопротивление и отказавшись "быть добреньким для всех".

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

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

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

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

Жытель ГондурасаПроцессный подход - реакционный, это как однопоточная программа.
Современные программы - многопоточные.Не могу с этим согласиться. Современные BPMS содержат две основные компоненты для настройки взаимодействия - оркестровка и хореография. Оркестровка - это так называемые "сильные" взаимодействия, которые настраиваются между "активити" в рамках отдельно взятых процессов - по сути, это алгоритм действия отдельного "потока". И уже на этом уровне в нотации BPMN существуют специальные управляющие конструкции, приводящие к "распараллеливанию" потоков, результаты которых затем обычно снова собираются в одной точке - соответственно, в этой точке находятся средства взаимодействия (диспетчеризации) потоков.
Настройка хореографии - это уже глобальная настройка взаимоедйствия великого множества разнообразных процессов ("потоков"), каждый из которых работает в собственном ритме. Это так называемые "слабые взаимодействия" (что не совсем точно отражает их суть). Так что средства многопоточности в подобных системах (по крайней мере, таких, которые имеют помимо оркестровки еще и хореографию) на весьма высоком уровне. Графическая визуализация этой многопоточности весьма удобна. Диспетчеризация взаимодействия многих потоков унифицирована на уровне уже самой нотации BPMN и автоматизирована движком BPMS. Так что многие RAD могли бы позавидовать подобной степени визуализации сложных многопоточных взаимодействий.

Помимо многопоточности процессный подход подразумевает постоянные улучшающие изменения, и полноценно реализующие его программные продукты ориентированы на возможность модификации процессных шаблонов (схем процессов) "на ходу" - без необходимости завершения "длинных транзакций" и/или изгнания пользователей из системы, которые такими шаблонами пользуются. Полноценная BPMS поддерживает версионность процессных шаблонов, их преемственность и возможность обрабатывать несколько версий одного и того же шаблона одновременно. Поэтому правильно сделанные BPMS обладают такой гибкостью, которой, как правило, не обладают ERP-системы. Они позволяют вносить изменения в настройки бизнес-процессов хоть каждый день и хоть по нескольку раз в день. И, тем самым, реализовывать два очень важных принципа:
1. Регулярность и постоянность улучшающих изменений при сохранении преемственности между данными изменяемой структуры.
2. Возможность применения Agile-технологий постепенного развертывания системы автоматизации процессов (в частности, "кадзен-развертывания"), которые до недавних пор противопоставлялись "водопадным" принципам организации проекта автоматизации или внедрения процессного подхода, а относительно недавно были включены и в стандарты управления проектами PMBoK, PMI, MSF. Этот подход содержит значительно меньше рисков и гораздо более результативен - позволяет получить быструю отдачу от самых первых фаз внедрения уже через несколько дней (сам реализовывал, знаю о чем говорю).

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

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

Иными словами, необходим программный продукт, которые совмещает в себе системы Process Management, Project Management и Task Management. Интегрированные с компонентами учета ресурсов, одни, по сути в комплексе могут оказаться способными полностью решать задачи управленческого и оперативного учета, так что отдельной системы для ведения УУ и ОУ не потребуется.

ViPRosТо есть ты думаешь что Project Management, Process Management - это сложившиеся управление, а Task Management - отстойник (предбанник) для не осознанных (часть ли проекта или сложившийся процесс) или ситуативных задач?
Думаю, в российских реалиях Task Management должен быть внедрен очень осторожно, так как 99% этих задач ничем не будут обоснованы. Скорее это не задачи, а хотельки (спам).Твое мнение я понимаю и принимаю - злоупотреблять такими вещами нельзя, согласен, ибо они могут полностью угробить регламенты.

Но если все делать правильно и грамотно, можно в "зарегламентируемую" деятельность включить регламентированный же переход на взаимодействия трудно формализуемые - когда в этом есть необходимость, когда некоторые виды деятельности действительно сложно формализовать. Например, обработка исключительных ситуаций, в зависимости от причин, по которым она возникла (упал астероид, возникли изменения законодательства, непредвиденные системой/регламентом обстоятельства и т.д. и т.п.) могут приводить к совершенно разным действиям на пути их устранения. Эти действия (в частности, сроки в зависимости от обстоятельств - каждый раз разные) должны контролироваться, их результаты должны фиксироваться. Для этих целей и должно быть сопряжение Task Management с процессным управлением. И из подсистемы Task Management в систему управления процессами, в конечном итоге, должна поступать информация о том, завершена ли обработка исключительной ситуации и, если она завершена некоторыми способами, возможно, имеет смысл продолжить выполнение процесса с некоторой фазы.
Потому возможность передачи управления в подсистему Task Management должна быть не "на каждом шагу", а допускаться лишь на определенных фазах процесса и с обязательной обратной связью с такой подсистемой. Вот как я считаю.

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


ViPRosУправленческий учет - часть этих 3 видов Management, как и бюджетирование (УУ - включает по умолчанию все аспекты отчуждения ресурсов в чью то пользу по каким то правилам включая бухгалтерские и налоговые).Тоже готов согласиться. По этому поводу я сам высказался чуть выше:
Garyaнеобходим программный продукт, которые совмещает в себе системы Process Management, Project Management и Task Management. Интегрированные с компонентами учета ресурсов, одни, по сути в комплексе могут оказаться способными полностью решать задачи управленческого и оперативного учета, так что отдельной системы для ведения УУ и ОУ не потребуется.

LSVНет никаких процессов, проектов, задач, потоков и пр. Есть таблички с полями и записями. И больше ничего.
Поэтому нужно выбирать систему, кот. позволяет быстро, гибко и эффективно работать с полями и записями.
Все равно разработчик на самом деле оперирует только табличками и полями.Такое понимание может привести к изобретению целого парка велосипедов... ;)