Создание сообщества BPM профессионалов

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

Мы решили изучить вопрос создания BPM-сообщества на базе ABPMP Ukraine Chapter. Эта работа выходит за границы нашей компании, и нам нужна ваша помощь.

Уделите, пжл, 5-7 минут своего времени и поделитесь обратной связью, если идея сообщества вам близка.
Это поможет нам лучше понять, как сделать работу сообщества полезной.

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

  
Поделитесь с друзьями

Читайте также

Digital Transformation: чек-лист для успешных преобразований
Digital Transformation: чек-лист для успешных преобразований
Как мы писали ранее, цифровая трансформация (digital transformation) организаций неизбежна. Точки приложения усилий на этом пути разнообразны: BI-аналитика, омниканальное продвижение и коммуникация, управление опытом сотрудников (employee experience management), BPMS-платформы, новые продукты. Процесс цифровой трансформации уникален для каждой организации. Мы выделили шесть составляющих, на которые следует обратить особое внимание при подготовке к реализации цифровых изменений. Используйте этот список в качестве чек-листа перед стартом проекта. [caption id="attachment_2979" align="aligncenter" width="493"] Рис.1. Digital-transformation, чек-лист[/caption] 1. Создайте общее видение Прежде чем приступать к цифровой трансформации, сформулируйте потребность в изменениях. Компания, сотрудники которой считают, что изменения не нужны, вряд ли преуспеет в инновациях и новых подходах к привлечению клиентов Заручитесь поддержкой ключевых заинтересованных сторон на этапе выбора инициатив для трансформации Составьте четкий план реализации инициатив (с детализацией текущего состояния и конечного результата). Это позволит скоординировать усилия сотрудников и минимизировать потенциальные риски 2. Сформируйте совместные команды из представителей бизнеса и ИТ Включите в проектные команды специалистов с глубоким пониманием бизнеса (различных его функций) и умеющих слушать и слышать ИТ визионеров. Проблема в коммуникации между бизнесом и ИТ по-прежнему остается актуальной Обеспечьте среду, в которой ИТ-специалисты обучают представителей бизнеса современным ИТ-технологиям, а представители бизнеса доносят ИТ-специалистам потребности клиентов, их «точки боли», а также действия конкурентов. Включите взаимное обучение в свой фокус внимание Используйте общий язык в виде моделей бизнес-процессов и единую терминологию. Это укрепит взаимопонимание между бизнесом и ИТ. 3. Выберите подходящую технологию через реализацию пилотных проектов Запускайте пилотные проекты и быстро тестируйте новые технологии Обеспечьте оперативное внесение изменений в существующие ИТ-решения. Скорость реализации проектов выходит на первый план Используйте бимодальную ИТ-инфраструктуру (например, ERP-система и BPMS-система). Это позволит интегрировать различные технологии между собой и станет основой для быстрых изменений 4. Регулярно проводите мониторинг новых технологий На регулярной основе осуществляйте мониторинг ключевых инновационных технологий. Задавайте себе вопрос: «Как мы можем применить данную технологию в своем бизнесе?» Выберите доступные и актуальные для вас технологии (см. рис.2), встраивайте их постепенно в бизнес-процессы компании При адаптации новых технологий для вашей компании максимально используйте уже имеющуюся у вас инфраструктуру (hard&software) [caption id="attachment_2969" align="aligncenter" width="600"] Рис.2 Industry 4.0 framework (Источник: 2016 Global Industry 4.0 Survey)[/caption]  5. Измеряйте показатели успеха Измеряйте экономический эффект от реализации проектов. Внедрение новых технологий не должно быть самоцелью Для последующей оценки результатов проекта используйте измеримые индикаторы эффективности. Достижение этих показателей будет стимулировать всю проектную команду двигаться вперед Наметьте измеримые ориентиры на пути цифровой трансформации. Отслеживайте по ним правильность движения на пути к цели. 6. Уделите внимание выбору подходящей ИТ-платформы, которая станет основой для будущих инноваций Найдите ИТ-платформу, которая обеспечит интеграцию между существующими системами, а также позволит дополнить и расширить их новыми функциями Выберите системного интегратора, который поможет осуществить внедрение и интеграцию между системами Убедитесь, что новая ИТ-платформа обеспечит надежность и динамичное развитие в будущем. Читать далее 
Центр исследований Gartner: 5 ловушек, которых следует остерегаться руководителям BPM-проектов
Центр исследований Gartner: 5 ловушек, которых следует остер...
Хотим поделиться интересной статьей об исследовании Gartner о ловушках, в которые чаще всего попадают руководители BPM-проектов. А также напомнить, что мы обучаем не только процессному подходу к управлению компанией, но и проводим специализированные тренинги по BPMN (1 и 2), а также бесплатные мастер-классы для тех, кто по каким-либо причинам не может\не готов прийти на тренинг, но хотел бы обменяться опытом и узнать новое для себя. Система менеджмента, основанная на управлении бизнес-процессами (BPM), позволяет компаниям добиться значительных успехов. Однако согласно исследованиям аналитиков компании Gartner многие организации сталкиваются с определенными проблемами в ходе реализации BPM-инициатив. Gartner обращает внимание на пять наиболее распространенных ловушек, о которых должны помнить руководители BPM-проектов. “В последнее время все больше внимания уделяется BPM-инициативам и тем впечатляющим преобразованиям, которые происходят в ходе их внедрения в организациях. Однако проектные команды очень часто оказываются в тупике, так и не получив ожидаемых результатов” – отмечает Джон Диксон (John Dixon), руководитель центра исследований Gartner, -“При реализации BPM-инициатив проектные команды могут столкнуться с различными сложностями, что потребует от проектной команды разнообразных навыков и умения работать с различными инструментами. BPM-проекты чаще всего сопряжены с необходимостью проведения организационных преобразований, изменения системы учета и бизнес-анализа, требуют нового взгляда на систему коммуникаций, а также тщательного выбора поставщика BPMS”. На основании проведенных исследований Gartner составил пять наиболее распространенных ловушек, в которые попадали неудачные BPM-проекты: Ловушка №1: Неспособность проектной команды продемонстрировать реальную пользу от внедрения BPM-инициативы BPM-проект должен приносить реальную экономическую выгоду организации. Но зачастую руководители BPM-проектов либо не задумываются об этом, либо не способны перевести результаты проекта в измеримые показатели и донести их до конечного заказчика. Все BPM-проекты должны начинаться с определения того, что будет считаться его успешным завершением. Очень важно, чтобы проектная команда понимала, к каким измеримым результатам она должна прийти в результате реализации проекта. Более того, все результаты должны быть четко сформулированы и донесены до заказчика на том языке, который ему понятен. Ловушка №2: Внедрение BPMS без понимания методологии BPM Внедряя даже самые современные BPMS системы, вы не получите каких-либо результатов без одновременного использования методологии BPM. BPM – это не программное обеспечение. BPM – это прежде всего другая парадигма мышления, другой подход к организации работы. Взяв за основу мнение эксперта (или группы экспертов), Вы рискуете получить всего лишь видение эксперта того, «как это должно быть». Такой подход лишает Вас основных возможностей для улучшения: непрерывной работы над бизнес-процессом вместе с участниками и владельцем бизнес-процесса. Ловушка №3: Полагаться на предполагаемые проблемы, не подтвержденные реальными фактами Все BPM-инициативы должны опираться на реальные факты и цифры, а не быть реакцией на чьи-либо предположения. Хорошей практикой при реализации BPM-проекта является выделение этапа сбора и изучения данных. Такой этап лучше всего заранее согласовать со спонсором (или руководящим комитетом) проекта и запланировать его до фазы непосредственной реализации. Ловушка №4: Реализация BPM-инициатив, которые не несут ценности для организации Поскольку организации хотят получить быстрый возврат на сделанные инвестиции при реализации BPM-проектов, проектная команда должна реально смотреть на вещи и взвешено подходить к выбору инициатив для реализации. Каждая инициатива в конечном итоге должна приносить прибыль, пусть даже и небольшую на первых порах. Чтобы заказчик сохранил позитивное отношение к дальнейшему внедрению BPM методологии, руководитель проекта должен уметь продемонстрировать лицу, принимающему решения, экономическую выгоду от реализации BPM-проекта. Ловушка №5: Концентрация на описании процессов, а не на их улучшении Проектная команда может погрязнуть в описании бизнес-процессов, формально опираясь на методологию BPM. Однако если модели бизнес-процессов не используются впоследствии для повышения эффективности бизнеса, то такая работа не несет в себе ценности. Руководитель BPM-проекта должен постоянно демонстрировать добавленную стоимость, которую он приносит заказчику в ходе реализации проекта. Есть вопросы? Звоните: +380 44 221 4646. Читать далее 
Agile: революция или… эволюция?
Agile: революция или… эволюция?
На тренингах по управлению проектами и управлению бизнес-процессами нам часто задают вопросы об agile-практиках и их безальтернативности в современном быстроменяющемся мире. Мы подробно рассказываем о преимуществах и ограничениях agile. И даже идем дальше: показываем, как проекты и процессы дополняют друг друга и почему agile-практики хорошо применимы для оптимизации бизнес-процессов. Давайте попробуем исторически проследить, почему agile-практики близки к процессному управлению и какие концепции предшествовали их появлению. Появление Agile В 2001 году группа разработчиков программного обеспечения (ПО) собралась в г. Юта (США), чтобы предложить новую методологию управления проектами по разработке ПО в противовес классическим «бюрократическим и тяжеловесным» подходам. Прийти к консенсусу по методологии не удалось, зато появился «Agile-манифест», который позиционировался как радикально новый подход к управлению проектами. С легкой руки Кена Швабера (Ken Schwaber) Agile начинают называть революцией в управлении проектами. Идеи, которые легли в основу Agile-манифеста, появились задолго до 2001 года. Обратимся к истории (см. рис. 1). Рис. 1. PM/BPM Timeline Фредерик встретил Генри Корни Agile уходят в 1878 год, когда Фредерик Тейлор (Frederick Taylor) представил теорию «Научного менеджмента». Тейлора ассоциируют со стандартизацией труда на производстве и повышением производительности бизнес-процессов. Однако его вклад в развитие инструментов управления проектами и процессами этим не ограничивается. Дело в том, что в 1887г. Фредерик Тейлор нанял помощником Генри Гантта (Henry Gantt), который в начале 20 века предложил знакомый многим способ визуализации план-графика проекта (см. рис.2). Спустя 100 лет диаграмма Гантта все еще остается популярным инструментом среди руководителей проектов. Рис.2 Диаграмма Гантта Рождение Lean и итеративных практик Труды Тейлора дали толчок дальнейшему изучению бизнес-процессов. Фрэнк и Лилиан Гилбрет (Frank and Lilian Gilbreth) в 1921г. предложили использовать диаграммы процесса (process charts) для его визуализации, анализа и усовершенствования. В основе их рекомендаций по оптимизации лежали: стандартизация процесса, устранение потерь (waste) и упрощение работы сотрудников. В 1930г. Лилиан Гилбрет презентовала способ визуализации потока работ с помощью инструмента, известного сегодня как Kanban-доска: «We had three rows of hooks, one marked “Jobs to be done”, one marked “Jobs being done” and a third marked ”Jobs completed” with tags which were moved from hook to hook to indicate the progress of the task. (Источник: 1930 Speech by Lillian Gilbreth to National Federation of Business and Professional Women’s Clubs in New York)». Рис.3 Kanban-доска Спустя некоторое время, после завершения второй мировой войны, в 1950 году на встрече с японским сообществом ученых и инженеров доктор Эдвардс Деминг (Edwards W. Deming) представил идеи статистического контроля процесса (Statistical Process Control) и цикла PDCA (Plan-Do-Check-Act). Цикл PDCA подразумевает итеративную работу над улучшением бизнес-процесса: начинается все с планирования, затем следует реализация инициатив по улучшению, проверка полученных результатов и решение о дальнейших действиях на следующей итерации. Наиболее популярный agile-фреймворк Scrum предлагает фактически аналогичный подход к организации работы проектной команды (рис 4). Использование agile-практик в проектах по оптимизации бизнес-процессов получается столь органичным именно потому, что agile является эволюцией цикла PDCA. Рис.4 Two-week sprint Киичиро Тойода (Kiichiro Toyoda) познакомился с работами Гилбретов в 1929 году во время поездки в США и Европу. В 50-х годах компания Тойота стала пионером в адаптации идей Гилбретов и Деминга. Производственная система Тойота (Toyota Production System) вобрала в себя идеи стандартизации работы, устранения потерь, непрерывного совершенствования по итеративному принципу, канбан и проч. На волне роста интереса к японским автопроизводителям в 80-х годах в США появился термин Lean Production (бережливое производство). Lean — маркетинговое название принципов производственной системы Тойота. Подход быстро набрал популярность, и вскоре появились адаптации Lean для других отраслей. Концепция Lean software development стала одной из первых agile-методологий по разработке программного обеспечения. В это же время в Японии развивались фабрики разработки ПО (Software factories). По мере ослабления барьеров в торговле и глобализации бизнеса приходилось адаптировать практики параллельной разработки для географически распределенных команд. Идеи устранения потерь (elimination of waste), стандартизации ролей и упрощения процесса добрались до самой прогрессивной на сегодняшний день отрасли спустя 60 лет после возникновения. «Железный» треугольник, инкрементальные и итеративные практики Давайте вернемся к «классическому» управлению проектами и вспомним диаграммы процессов Гилбретов. Именно их компания DuPont адаптировала и положила в основу своего Critical Path Method (CPM). Диаграмма Гантта, критический путь и «железный» треугольник стали популярными инструментами руководителей проектов в 60-х годов прошлого века. Спустя 40 лет идею треугольника стали использовать последователи agile для пояснения отличий классического управления проектами и agile-практик (см. рис. 5).   Рис. 5. Agile-подход В 60-х годах прозвучали первые упоминания об инкрементальных и итеративных практиках управления проектами. Впервые это произошло в проекте Меркурий, который реализовала NASA в 1958-1963 гг. Чуть позже, с 1968 года, началась адаптация итеративных практик под проекты разработки ПО. Через некоторое время итеративные практики включили в фреймворк PROMPT (прообраз современного PRINCE2) и руководство PMBOK (упоминается как спиральный жизненный цикл проекта, spiral project lifecycle). С нашей точки зрения, концепция Agile стала закономерным продолжением эволюции подходов, которые использовались ранее, например, в проектах по разработке ПО и оптимизации бизнес-процессов. История показывает, что бОльшего успеха добиваются те компании, которые комбинируют разные инструменты и методологии в зависимости от специфики проекта и контекста, в котором он реализуется. Судя по всему, в скором будущем agile-практики также будут эволюционировать и в управлении проектами появятся новые «революционные» идеи.   При подготовке статьи использовались материалы: McKenna T, Whitty SJ. (2013) Agile is Not the End-Game of Project Management Methodologies. In: Proceedings of the Annual Project Management Australia Conference Incorporating the PMI Australia National Conference (PMOz), Melbourne, 17‐18 September 2013.   Читать далее