Створення спільноти 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. Приділіть увагу вибору відповідної ІТ-платформи, яка стане основою для майбутніх інновацій Знайдіть ІТ-платформу, яка забезпечить інтеграцію між наявними системами, а також дозволить доповнити й розширити їх за допомогою нових функцій Виберіть системного інтегратора, який допоможе здійснити впровадження та інтеграцію між системами Переконайтеся, що нова ІТ-платформа забезпечить надійність та динамічний розвиток у майбутньому. Читати далi 
Центр досліджень 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. Читати далi 
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. Читати далi