Інтелектуальне управління проектами та імітаційне моделювання

Введення

Ця стаття планується як перша публікація із серії статей, присвячених інтелектуальному управлінню проектами.

У публікації будуть коротко розглянуті питання імітаційного моделювання управління проектами (УП) та інтелектуалізації УП.

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

Отже, приступимо.

1. Модель проекту

Відповідно до PMBoK 5 (1) виділяють кілька областей знань управління проектами (всі їх ми зачіпати не будемо). У кожній з областей проект розглядається з різних сторін, виділяються всілякі сутності/об'єкти, методи управління та їх вплив на проект, як на спосіб організації роботи для досягнення конкретної мети або вирішення завдання. Тут ми лише коротко опишемо типові об'єкти, які можна виділити при управлінні проектами, їх характеристики, взаємозв'язки, а також загальну механіку імітаційного моделювання і відповідність її життєвому циклу проекту.

Типові об'єкти та їх характеристики

Проект має такі характеристики: керівник, найменування, тип, планована дата початку, фактична дата початку, планована дата закінчення, фактична дата закінчення, поточний стан життєвого циклу, початковий баланс проекту, поточний баланс проекту.

Розрахункові або визначені на підставі інших об'єктів характеристики: команда проекту, відсоток виконаного обсягу робіт, відставання або випередження за обсягом виконаних робіт, відставання або випередження за термінами, планована вартість.

Завдання/Робота - тут вказуються схожі характеристики з проектом, до яких додаються наступні: приймач, відповідальний виконавець, тип виконуваної роботи, проект, місце, відсоток готовності.

Розрахункові або визначені на підставі інших об'єктів характеристики: послідовність виконання всередині проекту, склад виконавців, історія зміни стану, вартість виконання завдання/роботи.

Матеріальний ресурс (основні засоби): тип об "єкта, дата взяття на облік, дата введення в експлуатацію, назва, балансова вартість.

Розрахункові або визначені: амортизація, поточний стан, де задіяний зараз, розклад використання.

Ресурс (сировина, запасні частини): тип ресурсу, початкові запаси, місце розташування, дата поставки, термін придатності.

Розрахункові або визначені: поточні запаси, інтенсивність витрачання

Персонал: ПІБ, постійне розміщення.

Розрахункові або визначені: доступність для роботи, сумісність з іншими співробітниками, поточне розміщення на час виконання роботи, де задіяний, розклад роботи.

Ризик: ймовірність виникнення, ціна збитку, опис, тривалість впливу, індикатор спрацювання ризику.

Розрахункові або визначені: заходи щодо усунення наслідків, заходи щодо недопущення виникнення або ухилення, вартість, строки реалізації.

Взаємозв "язки і залежності

Проект- [1:M] -завдання - виконуються в обмеженнях термінів проекту.

Завдання - [1:M] -завдання - можуть мати ієрархічний зв'язок (вертикальний), можуть мати зв'язок у вигляді зазначення послідовності виконання (горизонтальний).

Матеріальний ресурс [M:M] -завдання - прив'язується через ставлення розкладу до завдання з зазначенням розкладу використання.

Ресурс- [M:M] -завдання - прив'язується через ставлення розкладу до завдання з зазначенням необхідного запасу для його виконання.

Персонал [M:M] -завдання - можуть бути задіяні в рамках декількох завдань, для чого вказується розклад робіт і відсоток використання в завданні.

Ризик- [M:M] - [Об'єкт] - під час зазначення взаємозв'язку з [Об'єктом] вказується ймовірність виникнення.

Зрозуміло це не повний перелік об'єктів.

Механіка

Кожен такт моделювання відповідає фіксованому часу - 1 день/годину виконуваного проекту. Для цього приймемо всі терміни, і інтервали в проекті - кратними величиною 1 день/год. Схема циклу моделювання зображена далі:

Цикл моделювання полягає в наступному:

1. Встановлюються початкові значення для проекту для симуляції. Створюється проект, готується розклад проекту, дерево ризиків. На цьому етапі так само доступні функції інтелектуальної підтримки управління проектами, але цей крок не може бути виконаний без ЛПР.
2. Ітерація починається з визначення чинних значень.
3. Виконання такту. Кожен такт моделювання виконуються наступні операції:
   • витрачаються ресурси за завданнями,
   • перевіряється ймовірність відмов (ризиків),
   • виконується певний обсяг робіт з переліку робіт за проектом,
   • виконуються фінансові операції за проектом.
4. Зберігаються розраховані значення для певного такту
5. Перевірка умов завершення моделювання.
6. Завершення моделювання і вивід результатів (аналітичних, агрегованих і докладних значень щодо кроків моделювання). Під час закінчення моделювання зберігаються останні (підсумкові) значення і причини припинення моделювання.
7. Видача користувачеві (або особі, яка приймає рішення - ЛПР) інформації про стан проекту без використання оптимізацій, модулів аналітики та підтримки прийняття рішень. Від користувача потрібна реакція на поточний стан (за потреби) або продовження моделювання.
8. Оцінка управлінських рішень користувача на основі поточних значень, а так само ретроспективи їх зміни та прийнятих користувачем управлінських рішень із застосуванням алгоритмів оптимізацій, модулів аналітики та підтримки прийняття рішень.

Відповідно до життєвого циклу проекту будемо розрізняти:

• ініціалізація та планування проекту - 1 крок
• реалізація проекту - 2-5, 7 і 8 крок циклу
• завершення проекту - 6 крок

Загальні зауваження

Всі дані проміжних кроків симуляції зберігаються і накопичуються в межах поточної симуляції. При подальшій роботі оптимізаційних алгоритмів (на 8 кроці циклу симуляції) можуть використовуватися дані як поточної, так і попередніх завершених симуляцій (з поправкою на результат завершення симуляції).

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

При декількох співробітниках/типах ресурсів моделювання виконується для кожного з них паралельно (тобто витрачаються одночасно), у разі відсутності розбіжностей за використовуваними ресурсами.

2. Технології реалізації

Основні розглянуті питання:

• зберігання структури даних проекту в БД
• інтерфейс для взаємодії користувача зі структурою БД
• засіб створення сервера симулятора
• інтерфейс для взаємодії між БД і сервером симулятора
• зберігання нейронної мережі і проміжних кроків ітерації симулятора
• взаємодія між інтерфейсом програми і нейронною мережею

Як нескладно помітити об'єкти проекту і зв'язку між ними легко уявити у вигляді відносин реляційної БД і зберігати в такому вигляді теж не складно, тобто буде досить реляційною БД - MySQL, наприклад.

Для розробки інтерфейсу виберемо фреймворк Yii 2 (і відповідний стек технологій - PHP, HTML тощо).

Реалізація сервера симуляції - Node.js

Реалізація нейронної мережі для Node.js, наприклад - habrahabr.ru/post/193738

Взаємодія з frontend (Yii2) і Node.js - github.com/oncesk/yii-node-socket

Залишається відкритим питання про формат зберігання найнейроннішої мережі, на яку накладаються наступні вимоги:

1. Відображення властивостей нейронної мережі (взаємозв'язку, ваги зв'язків тощо)
2. Безпечний доступ (виключити безпосередній вплив користувача на мережу)
3. Швидке завантаження нейронної мережі в пам'ять.
4. Можливість навчання мережі.

3. Логіка керування

Для кожної з галузей знань управління проектами існують постановки завдань та описані математичні способи їх вирішення, з якими автор поверхнево знайомий. Залежно від моделі управління знання цих правил і способів вирішення завдань повинні перерозподілятися між системою і користувачем. Моделі керування виділені наступні: (1)

1. управління з повідомленнями - система не впливає на об'єкт (проект), але відображає повідомлення про зміни показників і можливості виконання дій (прийняття рішень і максимум знань вимагається від ЛПР).
2. інтерактивне управління - система пропонує керуючі впливи, але рішення залишається за ЛПР (прийняття рішень залишається за ЛПР).
3. евристичне управління - система приймає рішення і виконує деякі впливи самостійно (ЛПР виключається з процесу управління).

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

1. Перерозподіл ресурсів між завданнями;
2. Перерозподіл трудових ресурсів між завданнями;
3. Зміна розкладу виконання завдань;
4. Планування закупівель;
5. Ухилення або вжиття заходів щодо ліквідації наслідків ризиків.

Для способів впливу важливі такі характеристики: ступінь відповідності ситуації, тривалість реалізації, вартість реалізації, можливий час початку реалізації. Для визначення застосовного способу впливу важливо:

1. Зазначені експертами характеристики.
2. Наявність інформації в накопиченій базі виконаних проектів.

Ці механізми логічно будувати із застосуванням нейронних мереж і нечіткої логіки. Використовувати ці алгоритми можна як на етапі ініціалізація і планування проекту, так і на етапі його реалізації. Можливе виконання аналізу - як змінюватися характеристики після застосування керуючого впливу.

4. Інтелектуалізація імітації

Т. о. на етапі виконання такту можливе повне виключення ЛПР з процесу управління. Що ж для цього необхідно? Для моделювання подій потрібні уточнення деяких характеристик (наближені). Для виконання керуючих впливів система повинна «знати» деяку додаткову інформацію щодо предметної області, наприклад:

1. Перерозподіл ресурсів між завданнями.

• взаємозамінність ресурсів - можна задати таблицями-матрицями відповідності;
• ймовірність виходу з ладу ресурсів - вказується ймовірність в діапазоні від Xmin до Xmax;
• можливість паралельного використання кількома виконавцями - як логічна властивість завдання.

2. Перерозподіл трудових ресурсів між завданнями.

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

3. Зміна розкладу виконання завдань.

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

4. Планування закупівель.

• інтенсивність витрачання ресурсу - визначається системою «нальоту».
• можливість закупівлі необхідного обладнання - як логічна властивість завдання.

5. Ухилення або вжиття заходів щодо ліквідації наслідків ризиків.

• ймовірність відмов обладнання - вказується ймовірність в діапазоні від Xmin до Xmax;
• можливі варіанти ухилення та ліквідації наслідків - вирішується матрицями або списками відповідності (із зазначенням ступеня відповідності).

Це не вичерпний список завдань. Тут так само необхідно відзначити той факт, що універсального рішення для будь-якого проекту бути не може і, що добре для одного проекту - для іншого смерть. Тобто необхідні певні ключові характеристики, їх сукупності, і їх значення, які дозволяли б типізувати і класифікувати, підбираючи схожі проекти для навчання системи, наприклад:

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

Далеко не останню роль буде грати фактор невизначеності як характеристик описаних вище, так і характеристик самого проекту.

5. Багатоагентність

Як було зазначено вище, розбіжності щодо використання ресурсів можуть бути як всередині проекту між завданнями, так і між різними проектами, що використовують одні й ті ж ресурси. Для спрощення роботи з ресурсами ми виділимо агента, якого назвемо «Арбітр ресурсів». Саме до нього будуть звертатися агенти «Проекти» за необхідними ресурсами, що дасть можливість перерозподіляти навіть зарезервовані ресурси залежно від важливості (критичності) виконуваних завдань або проектів.

Ув'язнення

Що дасть таке імітаційне моделювання або симуляція управління проектом? Відповідь проста:

1. управління з повідомленнями - можна використовувати як тренування або тестування ЛПР на знання певних принципів або вміння вирішувати завдання пов'язані з управлінням проектами.
2. інтерактивне управління - відпрацювання деяких практик і перевірка їх на моделі. Що дасть можливість змінити модель для відповідності ситуації або навпаки оцінити володіння методами вирішення завдань УП самому ЛПР (самоперевірка).
3. евристичне управління - можливість великої кількості запусків симуляції і накопичення певного досвіду (даних) про ці симуляції для їх подальшого аналізу.

Однак сама імітація і симуляція - не кінцева мета. У результаті накопичення досить точних простих і складних моделей у базі симуляції, розробки та налагодження поведінки імітаційної моделі і модулів, що здійснюють інтерактивну взаємодію та евристичне управління (без ЛПР), можливо використання накопичених правил і алгоритмів для управління (або інтелектуальної підтримки управління) реальними проектами (3).

Реалізація такої системи у вигляді SaaS рішення, із залученням деякої кількості учасників, дозволить отримати доступ до досвіду роботи (знеособленого) інших учасників (з можливістю навчання системи).

Список використовуваних джерел

1. ru/?p=1521. [В Інтернеті]
2. aaai.org/ojs/index.php/aimagazine/article/view/564. [В Інтернеті]
3. analytics8.com/images/uploads/general/US_2010-10_Whitepaper_BI_Project_Management_101.pdf. [В Інтернеті]