Структура декомпозиції робіт

Структура декомпозиції робіт, тж. ієрархічна структура робіт (англ. work breakdown structure, WBS) у проєктному менеджменті та системотехніці є орієнтованою на доконане виконання проєкту декомпозицією проєкту на менші частки. Структура декомпозиції робіт є ключовою часткою робіт по проєкту, яка організовує командну роботу по проєкту у керовані частини. PMBOK визначає структуру декомпозиції робіт як «ієрархічну декомпозицію робіт, що має бути виконаною командою проєкту та орієнтована на успішне завершення проєкту».

Елементом структури декомпозиції робіт може бути продукт, дані, Послуги або будь-яка комбінація вищезгаданого. Крім того, WBS надає необхідний каркас для детальної оцінки термінів та контролю, а також надає управління для розробки графіків робіт і контролю за їх виконанням.[1]

Огляд

WBS є ієрархічною та інкрементною декомпозицією проєкту у фази, кінцеві результати та пакети робіт. Вона є ієрархічною структурою, що показує подальший розподіл необхідних для виконання мети зусиль; наприклад,  програма, проєкт чи договір.[2] У проєкті чи договорі, розробка WBS відбувається, починаючи з кінцевих цілей та успішного розподілу її у керовані частини, що можуть бути оцінені за критеріями розміру, тривалості та відповідальностей (наприклад, системи, підсистеми, компоненти, задачі, підзадачі та пакети робіт) та включають усі необхідні для досягнення мети проєкту кроки.

Приклад структури декомпозиції робіт, що була застосована у звітних структурах NASA.[2]

Система декомпозиції робіт надає загальний каркас для природного розвитку загального планування та контролю договору і є базисом для розподілу роботи у такі інкременти, що можуть бути визначеними, та з яких може бути зроблене Технічне Завдання і установлені звіти по технічним даним, графікам, вартостям, робочим годинам .[2]

Структура декомпозиції робіт дозволяє зібрати докупи підлеглі витрати по задачах, матеріалах тощо на вищий рівень «батьківських» задач, матеріалів тощо. Для кожного елементу структури декомпозиції робіт генерується опис задачі, що має бути виконаною.[3] Ця техніка (іноді називається структурою декомпозиції системи [4]) використовується для визначення і налагодження сумарних рамок проєкту.

WBS організовується навколо ключових продуктів проєкту (чи запланованих результатів), а не необхідних робіт для випуску продукту (заплановані дії). Так як заплановані результати є бажаним завершенням проєкту, вони формують відносно стабільний набір категорій, у яких ціни запланованих для їх досягнення необхідних дій можуть бути зібрані докупи. Добре розроблена WBS робить легко досяжним призначення кожної діяльності проєкту до виключно однієї термінальної події у WBS. Додатково до її функцій у обліку витрат WBS також допомагає співвіднести вимоги одного рівня системних специфікацій до іншого, наприклад, відповідність матриці вимог перехресних посилань до функціональних вимог на вищий чи нижчий рівні документації.

Розробка WBS зазвичай має відбуватися на початку проєкту і перед детальним плануванням проєкту і задач.

Історія

Концепт структури декомпозиції робіт був розроблений у рамках Техніки Оцінювання та Аналізу Програм (PERT) Міністерством Оборони США (DoD). PERT був запропонований ВМС США у 1957 році для підтримки розробки ракетної програми Поларіс.[5] В той час як термін «структура декомпозиції робіт» не був вживаний, найперша імплементація PERT організувала задачі у продукто-орієнтовані категорії.[6]

У червні 1962 року, DoD, NASA та аерокосмічна індустрія опублікували докумен для системи PERT/COST, що описував підходи WBS.[7] Цей путівник був представлений Міністром Оборони для ухвалення всіх послуг.[8] У 1968 році, DoD видав «Структура Декомпозиції Робіт Для Товарів Військової Техніки» (MIL-STD-881), військовий стандарт, що потребував використання структур декомпозиції робіт у DoD.[9]

Документ був переглянутий кілька разів, останній раз у 2011 році. Поточна версія цього документу може бути знайдена у «Структури Декомпозиції Робіт для Товарів Військової Техніки» (MIL-STD-881C).[10] Він включає визначення WBS для специфічних систем військових товарів, та стосується елементів WBS, що є спільними для всіх систем.

Приклад із MIL-HDBK-881, що відображає перші три рівні типової системи повітряного апарату.[11]

Категорії товарів Військової техніки згідно MIL-STD-881C є:

• WBS систем повітряних апаратів;
• WBS електронних систем;
• WBS ракетних комплексів;
• WBS систем артилерії;
• WBS морських систем;
• WBS космічних систем;
• WBS систем поверхневого транспорту;
• WBS систем безпілотних літаючих апаратів;
• WBS систем безпілотних морських апаратів;
• WBS систем запуску транспортних засобів;
• WBS автоматизованих інформаційних систем.

Спільними елементами, визначеними у MIL-STD-881C, Додаток L, є:

• Інтеграція, збір, тестування та перевірка;
• Інжинірингові системи;
• Програмний Менеджмент;
• Тест і Оцінка систем;
• Тренування;
• Дані;
• Обладнання Власної Підтримки;
• Обладнання Загальної Підтримки;
• Оперативна/Місцева активація;
• Промислові об'єкти;
• Початкові Запчастини та Частини для Ремонту.

Стандарт також включає додаткові спільні елементи, що є унікальними для Космічних Систем, Систем Запуску транспортних засобів та Автоматизованих Інформаційних Систем.

У 1987 році,  Інститут Проєктного Менеджменту (PMI) задокументував розширення цих технік на використання не лише в системах оборони. У книзі Звід Знань по Проєктному Менеджменту (PMBOK) викладений концепт WBS, в той час як «Практичний Стандарт для Структур Декомпозицій Робіт» є порівняним для книги DoD, проте призначений для більш загального використання.[12]

Принципи

Правило (охоплення) 100 %

Важливий принцип проєктування для Структури Декомпозиції Робіт називається «правило 100 %».[13] Він визначається так:

Правило 100 % визначає, що WBS включає в собі 100 % роботи, що виділена в межах проєкту та охоплює всі результати — внутрішні, зовнішні, проміжні — що мають бути завершені з точки зору виконуваної роботи, включаючи проєктний менеджмент. Правило 100 % є одним з найважливіших принципів, що керують розробкою, декомпозицією та оцінкою WBS. Правило застосовується до усіх рівнів у наступній ієрархії: сума робіт на «дочірньому» рівні має бути рівною 100 % роботи, що представлена «батьківським» рівнем, а також WBS не має містити будь-якої роботи, яка не є частиною актуальних меж, визначених проєктом, що в свою чергу визначає, що вміст не може бути більшим за 100 % роботи… Важливо пам'ятати, що правило 100 % керування також застосовується до рівня діяльностей. Робота, що відтворюється діяльностями у кожному робочому пакеті, має складати 100 % роботи, необхідної для його завершення.[14]

Взаємовиключні елементи

Несумісні події: Додатково до правила 100 % охоплення, важливо пам'ятати про відсутність перекриттів між різними елементами у питанні визначенні меж в рамках структури декомпозиції робіт. Ця неоднозначність може призвести до подвійної роботи чи проблем комунікації у питаннях відповідальності та авторитетності. Таке перекриття також може спричинити плутанину щодо обліку витрат проєкту. У випадку, коли назви елементів WBS є неоднозначними, словник WBS може стати у нагоді задля прояснення відмінностей поміж елементами WBS. Словник WBS описує кожен компонент структури WBS разом з віхами, результатами, процесами, межами та інколи датами, ресурсами, витратами, якістю.

Заплановані висновки замість дій

У разі, якщо автор структури декомпозиції робіт спробує охопити будь-яку дієво-орієнтовану деталь у WBS, він/вона включить або забагато, або замало дій. Забагатість дій перевищать 100 % батьківських меж, в той час як замалість відставатиме від 100 % батьківських меж. Найкращим шляхом є дотримання правила 100 % керування для визначення елементів WBS у термінах результатів, а не дій. Це також гарантує, що WBS не буде занадто приписуючим, що збільшить винахідливість та креативне мислення у частини учасників проєкту. Для нових проєктів, що розробляють продукти, найбільш популярною технікою для гарантування результато-орієнтовної WBS є використання структури декомпозиції продукту. Розробка, керована функціональністю може використовувати схожу техніку, що має утворити структуру декомпозиції ознак. Коли проєкт надає професійні послуги, зазвичай використовується техніка охоплення всіх запланованих результатів для створення результато-орієнтовної WBS.[15] Структури декомпозиції робіт, що розділяють роботу на фази проєкту (наприклад, попередній етап проектування, фаза критичного технологічного планування) мають гарантувати, що фази чітко розділені запланованими результатами та вони також використовуються для визначення критерію завершення (наприклад, затверджений у минулому, чи огляд критичної технічної частини).

Рівень деталізації

Має існувати кінцева точка завершення поділу роботи на менші частини. Це допоможе у визначенні тривалості діяльностей, що необхідні для вироблення результату, що визначений у WBS. Є кілька евристичних чи «емпіричних» правил, що використовуються при визначенні відповідної тривалості для діяльності чи групи діяльностей, необхідних для вироблення специфічного результату, визначеного WBS.

• Першим є «правило 80 годин», яке визначає, що жодна одинична діяльність чи група діяльностей на найнижчому рівні деталізації у WBS  для отримання результату не може тривати більш ніж 80 робочих годин.
• Друге емпіричне правило визначає, що жодна діяльність чи група діяльностей на найнижчому рівні деталізації у WBS не боже бути довшою за одиничний звітний період. Таким чином, якщо команда проєкту звітується по прогресу проєкту щомісячно, жодна одинична діяльність чи їх група не може тривати більше місяця.
• Останнє евристичне правило є правилом «чи є це доцільним». Застосовуючи це емпіричне правило, можна застосувати «здоровий глузд» при створенні тривалостей діяльностей чи груп діяльностей, що необхідні для вироблення результату, визначеного у WBS.

Робочий пакет на рівні діяльностей є задачею, яка:

• може бути реалістично і впевнено оцінена;
• відповідає критерію недоцільності подальшого поділу;
• може бути завершена у відповідності згідно одного з вищеописаних евристичних правил;
• виробляє результат, що можна оцінити; а також
• формує унікальний пакет робіт, що може бути відданий на аутсорс чи підряднику.

Схема кодування

Для елементів структури декомпозиції робіт є частою практика послідовної нумерації при створенні ієрархічної структури. Метою нумерації є надання послідовного підходу до визначення та управління WBS у вигляді системи незалежно від вендору чи обслуговування.[16] Наприклад, 1.1.2 Рухова установка (у прикладі нижче) визначає цей елемент як Елемент Рівня 3 структури WBS, так як існує три числа, розділених десятковим розділювачем. Схема кодування також допомагає елементам WBS бути визначеними у будь-якому письмовому контексті.

Практичний приклад схеми кодування WBS:[17]

1.0 Система Літаків

1.1 Повітряний апарат

1.1.1 Корпус

1.1.1.1 Інтеграція корпусу, Збір, Тестування та Перевірка

1.1.1.2 Фюзеляж

1.1.1.3 Крило

1.1.1.4 Хвіст

1.1.1.5 Кабіна

1.1.1.6 Інші компоненти корпусу 1..n (Визначити)

1.1.2 Рухова установка

1.1.3 Підсистеми апарату

1.1.4 Авіоніка

1.2 Системний Інжиніринг

1.3 Програмний Менеджмент

1.4 Перевірка і Оцінювання Системи

1.5 Тренування

1.6 Дані

1.7 Обладнання Власної Підтримки

1.8 Обладнання Загальної Підтримки

1.9 Оперативна/Місцева Активація

1.10 Промислові об'єкти

1.11 Початкові Запчастини та Частини для Ремонту

Приклад у сфері програмного забезпечення буде виглядати наступним чином:[18]

1267.1 Системна Інтеграція

1267.1.1 Визначення Вимог

1267.1.2 Регламент

1267.1.3 Планування

1267.1.4 Моніторинг та Контроль

1267.1.5 Менеджмент Закупівель

1267.1.6 Закриття

1267.2 Дизайн

1267.2.1 Концептуальний Дизайн

1267.2.2 Попередній Дизайн

1267.2.3 Фінальний Дизайн

Термінальний елемент

Найнижчим елементом у деревній структурі – термінальним елементом – є такий, що не може бути надалі поділений. У структурі декомпозиції робіт такі елементи є елементами, що оцінюються як вимоги до ресурсів, бюджету та тривалості; пов'язані залежностями; а також заплановані. На стику елементу WBS та організаційного блоку, встановлюються рахунки управління та робочі пакети, планується продуктивність, вимірюється, записується та контролюється.[19] WBS може бути деталізована до будь-якого рівня зацікавленості. Мінімально рекомендованими є три рівні, в той час як додаткові рівні мають бути заданими лише для елементів з високою вартістю чи високим ризиком,[20] і два рівня деталізації у випадках, таких як системний інжинірінг чи програмний менеджмент,[21] зі стандартами прикладами того, що WBS з різною глибиною, такі як розробка програмного забезпечення, доходять до 5 рівнів[22], або системи керування вогнем, що доходят до 7 рівнів.[23]

Відповідність до норм

Найвищий рівень структури WBS має відповідати нормам чи шаблонам компанії, що існують всередині організації чи домену. Наприклад, кораблебудування для ВМС США має брати до уваги, що морські умови та відповідна ієрархічна структура мають відповідати стандарту MIL-STD[24], включеному у Військово-Морську Архітектуру [25], а також що відповідні Воєнно-Морські офіси і процедури були побудовані у відповідності до цієї архітектури, тому будь-яка істотна зміна у нумерації елементів WBS чи неймінгу у ієрархії буде неприйнятною.

Приклад

Техніка конструювання WBS, що використовує правило 100 % керування під час побудови.

Фігура зліва показує структуру декомпозиції робіт для техніки будування, що демонструє правило 100 % керування, а також техніку «прогресивної розробки». На рівні WBS 1 показано 100 одиниць роботи як загальний обсяг проєкту для конструювання та побудови користувацького велосипеда. На рівні WBS 2, 100 одиниць розподілені у сім елементів. Кількість одиниць, виділених на кожен елемент роботи, може бути базований на об'єму зусиль чи вартості; задачі оцінити тривалість не встановлено.

Три найбільших елементи WBS Рівня 2 надалі діляться на Рівні 3. Кожен з двох найбільших елементів на Рівні 3 визначає лише 17 % загального об'єму проєкту.  Ці більше елементи можуть бути надалі поділені за допомогою використання техніки прогресивної розробки, що описана вище.

Дизайн WBS може бути підтриманий програмним забезпеченням (таким як Електронний аркуш), що дозволить автоматичне встановлення контрольних точок. Оцінки зусиль чи вартостей можуть бути розробленими шляхом обговорень членами команди. Ця спільна техніка створює велику проникність у визначення меж проєкту, припущень та консенсусів, стосовно необхідного рівня деталізації для управління проєктами.

Оманливі уявлення

• WBS не є вичерпним переліком необхідних до виконання робіт. Насправді вона є комплексною класифікацією рамок проєкту.
• WBS не є ані планом проєкту, ані графіком виконання, ані хронологічним списком. Вона лише визначає, «що» саме буде зроблено, а не «як» чи «коли».
• WBS не є ієрархією організації, хоча й може використовуватися при призначенні відповідальності. Див. також: Матриця Відповідальності (інша назва Кадрова Матриця).

Див. також

• Глосарій термінів з управління проєктами
• Ієрархічна структура ресурсів
• Планування проєкту
• Статут проєкту
• Структура декомпозиції продукту
• Структура декомпозиції значень
• Система управління проєктами
• Графік структури

Посилання

1. Booz, Allen & Hamilton Earned Value Management Tutorial Module 2: Work Breakdown Structure [Архівовано 8 вересня 2017 у Wayback Machine.], Office of Science, Tools & Resources for Project Management [Архівовано 29 липня 2018 у Wayback Machine.], science.energy.gov.
2. NASA (2001).
3. Electronic Industries Alliance Standard Systems Engineering Capability Model EIA-731.1
4. Institute of Electrical and Electronics Engineers Standard for Application and Management of the Systems Engineering Process IEEE Std 1220—2005
5. Fleming, Quentin W., Joel M. Koppelman «Earned Value Project Management» CROSSTALK: The Journal of Defense Software Engineering July 1998, p 20 (PDF). Архів оригіналу (PDF) за 31 жовтня 2012. Процитовано 20 січня 2016. [Архівовано 2012-10-31 у Wayback Machine.]
6. Haugan, Gregory T., Effective Work Breakdown Structures, pp7-8
7. DOD and NASA Guide, PERT/COST System Design, June 1962
8. Hamilton, R. L., Study of Methods for Evaluation of the PERT/Cost Management System [Архівовано 11 січня 2020 у Wayback Machine.], MITRE Corporation, June 1964
9. MIL-STD-881, 1 November 1968
10. MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items [Архівовано 7 листопада 2017 у Wayback Machine.], 3 October 2011
11. Systems Engineering Fundamentals. (PDF). Архів оригіналу (PDF) за 11 лютого 2006. Процитовано 20 січня 2016.
12. Haugan, Gregory T., The Work Breakdown Structure in Government Contracting, Management Concepts, 2003 ISBN 978-1567261202
13. Effective Work Breakdown Structures By Gregory T. Haugan, Published by Management Concepts, 2001, ISBN 1567261353, p.17
14. Practice Standard for Work Breakdown Structures (Second Edition), published by the Project Management Institute, ISBN 1933890134, page 8
15. Swiderski, Mark A., PMP workbreakdownstructure.com [Архівовано 10 жовтня 2017 у Wayback Machine.], PMBOK-Work Breakdown Structures.
16. MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶4.3
17. MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011 Appendix A, ¶A.3
18. Taylor, Michael, WBS Examples [Архівовано 4 березня 2016 у Wayback Machine.], PM Hut.
19. MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶3.1.4
20. MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶1.4.1
21. MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶2.2.4.2
22. MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶Fig.3-6
23. MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶Fig.3-1
24. MIL-STD-881C, Work Breakdown Structures for Defense Materiel Items, 3 October 2011, ¶Appendix E
25. Gilmer, Thomas (1982-08-04).

Подальше  читання

• Carl L. Pritchard. Nuts and Bolts Series 1: How to Build a Work Breakdown Structure ISBN 1-890367-12-5
• Project Management Institute. Project Management Institute Practice Standard for Work Breakdown Structures, Second Edition (2006) ISBN 1-933890-13-4 (Note: The Second Edition is an extensive re-write of the Practice Standard.)
• Gregory T. Haugan. Effective Work Breakdown Structures (The Project Management Essential Library Series) ISBN 1-56726-135-3
• Dennis P. Miller, PMP, «Building Your Project Work Breakdown Structure — Visualizing Your Objectives, Deliverables, Activities and Schedule». ISBN 1-42006969-1 (Note: This new book is essentially a facilitator's guide for planning a project based on the WBS.)

Посилання

• how to create work breakdown structure WBS using standard Division of work [Архівовано 7 грудня 2019 у Wayback Machine.]
• EverySpec.Com copies of MIL-HDBK-881 versions [Архівовано 13 січня 2021 у Wayback Machine.]
• Defense Acquisition University ACQ101 Summary for Work Breakdown Structures
• How to Make a Work Breakdown Structure [Архівовано 5 липня 2018 у Wayback Machine.]
• NASA Work Breakdown Structure Handbook, NASA/SP-2010-3404, January 2010

Примітки