Навігація
Головна
 
Головна arrow Менеджмент arrow Інформаційний консалтинг
< Попередня   ЗМІСТ   Наступна >

Організація проектно-інноваційної консультаційної діяльності

Основними цілями розробки консультаційних проектів є:

  • - Представлення діяльності підприємства і прийнятих у ньому технологій у вигляді ієрархії діаграм, забезпечують наочність і повноту їх відображення;
  • - Формування на підставі аналізу пропозицій щодо реорганізації організаційно-управлінської структури;
  • - Упорядкування інформаційних потоків (у тому числі документообігу) усередині підприємства;
  • - Вироблення рекомендацій з побудови раціональних технологій роботи підрозділів підприємства та його взаємодії із зовнішнім світом;
  • - Аналіз вимог і проектування специфікацій корпоративних інформаційних систем;
  • - Рекомендації та пропозиції щодо застосовності і впровадженню існуючих систем управління підприємствами (насамперед класів MRP - manufacturing resource planning і ERP - enterprise resource planning).

Фактично консультантом виконується два види робіт. Насамперед це елементарне наведення порядку в організації: бізнес-аналіз і реструктуризація (реінжиніринг бізнес-процесів). Цей напрямок одержав назву "бізнес-Консультрованіе". У кінцевому підсумку мова, зрозуміло, йде про автоматизацію, однак якщо ми будемо автоматизувати існуючий хаос, що панує на російських підприємствах, то в результаті отримаємо не що інше, як "автоматизований хаос". Будь-яка організація - це досить складний організм, функціонування якого одній людині зрозуміти просто неможливо. Керівництво в загальних рисах уявляє собі загальний хід справ, а клерк досконально вивчив тільки свою діяльність, з'ясував свою роль у сформованій системі ділових взаємин. Але як організація функціонує в цілому, не знає, як правило, ніхто. І саме діяльність, спрямована на те, щоб розібратися у функціонуванні таких організмів, побудувати відповідні моделі і на їх основі висунути деякі пропозиції з приводу поліпшення роботи деяких ланок, а ще краще - бізнес-процесів (діяльностей, що мають цінність для клієнта), вважається бізнес -консультування.

Інший вид робіт - власне системний аналіз і проектування. Виявлення та узгодження вимог замовника призводить до розуміння того, що ж насправді необхідно зробити. За цим слідує проектування або вибір готової системи так, щоб вона в підсумку якомога більшою мірою задовольняла вимогам замовника.

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

Загалом, підхід до розробки консультаційних проектів включає наступні етапи:

  • 1. Аналіз первинних вимог і планування робіт. Даний етап передує ініціацію робіт над проектом Його основними завданнями є: аналіз первинних бізнес -Требования, попередня економічна оцінка проекту, побудова план-графіку виконання робіт, створення і навчання спільної робочої групи.
  • 2. Проведення обстеження діяльності підприємства. В рамках даного етапу здійснюється:
    • - Попереднє виявлення вимог, що пред'являються до майбутньої системи;
    • - Визначення оргштатної і топологічної структур підприємства;
    • - Визначення переліку цільових завдань (функцій) підприємства;
    • - Аналіз розподілу функцій по підрозділах і співробітникам;
    • - Визначення переліку застосовуваних на підприємстві засобів автоматизації.

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

В якості вихідної інформації при проведенні обстеження та виконанні подальших етапів служать:

  • - Дані по оргштатної структурі підприємства;
  • - Інформація про прийняті технологіях діяльності;
  • - Стратегічні цілі та перспективи розвитку;
  • - Результати інтерв'ювання співробітників (від керівників до виконавців нижньої ланки);
  • - Пропозиції співробітників з удосконалення бізнес-процесів підприємства;
  • - Нормативно-довідкова документація;
  • - Досвід системних аналітиків в частині наявності типових рішень.

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

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

Кожна з моделей включає в себе повну функціональну модель діяльності (наприклад, у вигляді ієрархії діаграм потоків даних з розробленими для всіх процесів нижнього рівня докладними їх специфікаціями на структурованому природною мовою або у вигляді ієрархії Баіт-діаграм), інформаційну модель (як правило, з використанням нотації "сутність-зв'язок"), а також (у разі необхідності) подієву (описує поведінку) модель (з використанням діаграм переходів станів).

Перехід від моделі "як є" до моделі "як має бути" здійснюється наступними двома способами.

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

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

  • - Включає в себе існуючі неавтоматизовані технології, що працюють на підприємство. Формальний аналіз цієї моделі дозволить виявити вузькі місця в технологіях і запропонувати рекомендації щодо її поліпшення (незалежно від того, передбачається на даному етапі автоматизація підприємства чи ні);
  • - Дозволяє здійснювати автоматизоване і швидке навчання нових працівників конкретному напрямку діяльності підприємства (так як її технологія міститься в моделі) з використанням діаграм;
  • - З її допомогою можна здійснювати попереднє моделювання нового напрямку діяльності з метою виявлення нових потоків даних, взаємодіючих підсистем і бізнес-процесів.
  • 4. Розробка системного проекту. Даний етап є першою фазою розробки власне системи автоматизації (саме, фазою аналізу вимог до системи), на якій вимоги замовника уточнюються, формалізуються і документуються. Фактично на цьому етапі дається відповідь на питання: "Що повинна робити майбутня система?". Саме тут лежить ключ до успіху всього проекту автоматизації. У практиці створення великих програмних систем відомо чимало прикладів невдалої реалізації саме через неповноту і нечіткості визначення системних вимог.

На цьому етапі визначаються:

  • - Архітектура системи, її функції, зовнішні умови її функціонування, розподіл функцій між апаратною і програмною частинами;
  • - Інтерфейси і розподіл функцій між людиною і системою;
  • - Вимоги до програмних та інформаційним компонентам системи, необхідні апаратні ресурси, вимоги до бази даних, фізичні характеристики компонент системи, їх інтерфейси;
  • - Склад людей і робіт, що мають відношення до системи;
  • - Обмеження в процесі розробки (директивні терміни завершення окремих етапів, наявні ресурси, організаційні процедури і заходи, що забезпечують захист інформації).

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

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

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

  • 5. Розробка пропозицій по автоматизації підприємства. На підставі системного проекту здійснюється:
    • - Складання переліку автоматизованих робочих місць підприємства та способів взаємодії між ними;
    • - Аналіз застосовності існуючих систем управління підприємствами для вирішення необхідних завдань і формування рекомендацій щодо вибору такої системи;
    • - Спільне з замовником прийняття рішення про вибір конкретної системи управління підприємством або розробці власної системи;
    • - Розробка вимог до технічних засобів;
    • - Розробка вимог до програмних засобів;
    • - Розробка пропозицій щодо етапах і термінах автоматизації.
  • 6. Розробка технічного проекту. На даному етапі на основі системного проекту і прийнятих рішень по автоматизації здійснюється проектування системи. Цей етап поділяється на два підетапи:
    • - Проектування архітектури системи, що включає розробку структури та інтерфейсів її компонент (автоматизованих робочих місць), узгодження функцій і технічних вимог до компонентів, визначення інформаційних потоків між основними компонентами, зв'язків між ними і зовнішніми об'єктами;
    • - Детальне проектування, що включає розробку специфікацій кожної компоненти, розробку вимог до тестів і плану інтеграції компонент, а також побудова моделей ієрархії програмних модулів і міжмодульних взаємодій і проектування внутрішньої структури модулів.

При цьому відбувається розширення системного проекту за рахунок:

  • - Його уточнення;
  • - Побудови моделей автоматизованих робочих місць, що включають подсхеми інформаційної моделі та функціональні моделі, орієнтовані на ці подсхеми аж до ідентифікації конкретних сутностей інформаційної моделі;
  • - Побудови моделей міжмодульних і Внутрімодульное взаємодій з використанням техніки структурних карт.
  • 7. Наступні етапи. У разі розробки власної системи наступні етапи є традиційними: за специфікаціями технічного проекту здійснюється програмування модулів, їх тестування, налагодження і подальша комплексація в автоматизовані робочі місця і в систему в цілому. При цьому схема інтегрованої бази даних, як правило, генерується автоматично на підставі інформаційної моделі.

Налаштування існуючої системи MRP або ERP здійснюється за такими етапами:

  • - Наповнення системи практичними даними;
  • - Побудова процедур їх обробки;
  • - Інтеграція процедур всередині автоматизованих робочих місць;
  • - Інтеграція автоматизованих робочих місць в систему.

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

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

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

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

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

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

Інший чинник, що гальмує результативне впровадження інноваційних проектів у вітчизняних умовах, пов'язаний з тим, що методології управління проектами, розроблені західними менеджерами, не можуть бути безпосередньо впроваджені в практику роботи вітчизняних виробників. Адаптація ж відповідних методик стосовно російських умов - сформованому стереотипу діяльності, систему взаємовідносин різних рівнів управління, способу мислення і т. Д. - Вимагає значних інтелектуальних і фінансових зусиль, для чого необхідна відповідна підтримка на федеральному рівні.

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

Сучасні методології управління проектами фахівці умовно поділяють на групи - рамкові і тактичні. Розглянемо зміст цих понять.

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

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

Прикладами рамкових стандартів з управління проектами є британський федеральний стандарт Prince (Projects in a Controlled Environment) і американський федеральний стандарт РМВОК (Project Management Body of Knowledge) (нижче наведені у скороченому варіанті).

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

Схема взаємодії цих процесів представлена на рис 6.2.

Процесний підхід до управління проектами

Рис. 6.2. Процесний підхід до управління проектами

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

Керівник консультаційної фірми стверджує як керівника проекту, так і робочу групу, а також план стадії ініціації проекту.

Процес ініціації проекту ставить своїми цілями обґрунтування необхідності проекту, створення стабільної управлінської основи для його виконання, підготовку ресурсів для первісної стадії проекту, контроль трудомісткості і ефективних витрат часу в ході проекту.

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

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

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

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

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

Перераховані процеси та їх взаємодія описані в стандарті істотно докладніше.

Рамковий стандарт РМВОК. Стандарт включає в себе кілька галузей знань проектного менеджменту, представлених на рис. 6.3.

Рамковий стандарт РМВОК

Рис. 6.3. Рамковий стандарт РМВОК

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

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

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

Область управління вартістю проекту описує процеси, необхідні для забезпечення виконання проекту в рамках затвердженого бюджету. Включає планування ресурсів, а також оцінку, облік і контроль витрат.

Область управління якістю проекту описує процеси, необхідні для забезпечення відповідності результатів проекту поставленим завданням. Включає планування, забезпечення і контроль якості.

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

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

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

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

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

Дана модель передбачає наступні дії:

  • - Специфікацію мети (суб) проекту;
  • - Складання списку завдань (суб) проекту;
  • - Визначення керівника проекту (лідера), для (суб) проекту - відповідальної особи;
  • - Розподіл завдань в (суб) проекті;
  • - Ризик-аналіз (суб) проекту;
  • - Моніторинг та інформаційний менеджмент (суб) проекту.

Аналіз і зіставлення наведених вище стандартів дозволили сформулювати наступні висновки:

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

Серед типових ознак неконструктивності таких моделей були виділені:

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

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

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

На відміну від рамкових тактичні моделі надають собою інструментарій для вирішення конкретних проблем в ході проекту. Вони грунтуються на алгоритмі, що визначає порядок і спосіб вирішення проектних завдань. Такі моделі не можуть служити в якості базової основи для проектів корпоративного рівня, однак можуть використовуватися як для адаптації рамкових стандартів у конкретних організаціях, так і самостійно, т. Е. Без залучення рамкових стандартів. Прикладом такої моделі є розробка ірландської консультаційної компанії, що носить назву Structured Project Management (SPM).

Тактична модель SPM. У моделі визначається набір дій, які використовуються на всіх вкладених рівнях проекту по мірі їх застосовності (рис. 6.4).

Тактична модель SPM

Рис. 6.4. Тактична модель SPM

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

У цьому випадку співробітники консультаційної фірми на основі аналізу можуть самі вибирати найбільш прийнятні стандарти, конкретизувати їх стосовно окремим проектом або модифікувати варіанти їх поєднань.

Незважаючи на певні труднощі, пов'язані зі створенням власних розробок на основі поєднання рамкової і тактичної моделей, сам підхід має низку переваг, оскільки дозволяє:

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

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

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

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

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

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

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

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

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

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

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

Життєвий цикл проекту визначає:

  • - Роботи, що виконуються на кожній фазі;
  • - Учасників виконання фаз.

Більшості фаз життєвого циклу проекту властиві такі схожі характеристики:

  • - Вартість і кількість учасників на старті невеликі, вони зростають до середини і різко зменшуються перед завершенням проекту;
  • - Ймовірність успішного завершення проекту на старті найменша, але зростає в міру його виконання;
  • - Вартість внесення змін, виправлення помилок зазвичай зростає в процесі виконання проекту.

Більшість проектів організаційних змін проходить наступні чотири фази:

  • o Концептуальна фаза. На цій фазі визначаються ті зміни, які необхідно провести. Вона супроводжується інтенсивними обстеженнями і переговорами і закінчується випуском концепції, яка описує необхідні зміни і вигоди від їх проведення. Якщо концепція схвалюється керівництвом, то відбувається перехід до наступної -лабораторні фазі проекту.
  • o Лабораторна фаза. На цій 4> азе команда проекту деталізує, обговорює і тестує різні підходи до організації проектної роботи. При цьому деякі ідеї відкидаються повністю, а від інших у проекті залишаються лише окремі деталі. Інновації мають аналізуватися з усіх боків, включаючи організаційну культуру і структуру, роль технологій, зміст роботи і вимоги до ресурсів. Важливо визначити чіткі межі цієї фази, яка закінчується створенням і тестуванням об'єкта проектування. Команда проекту повинна бути впевнена, що запропоновані рішення приведуть до необхідних результатів. До цього моменту вона готова тестувати розроблену систему.
  • o Пілотна фаза. Являє собою практичне тестування і призначена для оцінки спроможності пропонованих рішень в реальних умовах, перш ніж будуть проведені значні витрати. Оцінюючи ефективність запропонованих рішень, команда проекту вносить необхідні корективи. Повинні бути розглянуті всі питання, включаючи комп'ютерні системи, використовувані програми, мережі, устаткування, персонал, навчання і т. Д.
  • o Фаза впровадження. Є заключною фазою проекту, оскільки на ній відбувається завершення проекту.

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

Розглянемо групи учасників проекту починаючи з моменту його створення і до впровадження на практиці.

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

Інвестор - той, хто вкладає кошти в проект. При цьому інвестиції можуть бути спрямовані як на розробку проекту, так і у вигляді капітальних вкладень у створення об'єктів матеріально-технічного призначення. При цьому інвестор може бути і замовником.

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

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

Підрядник - юридична особа, яка несе відповідальність за виконання робіт відповідно до контракту.

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

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

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

Банк - один з основних інвесторів, які забезпечують фінансування проекту. В обов'язки банку входить безперервне забезпечення проекту коштами, а також кредитування генпідрядника для розрахунків із субпідрядниками, якщо в замовника немає необхідних коштів.

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

 
Якщо Ви помітили помилку в тексті позначте слово та натисніть Shift + Enter
< Попередня   ЗМІСТ   Наступна >
 
Дисципліни
Агропромисловість
Аудит та Бухоблік
Банківська справа
БЖД
Географія
Документознавство
Екологія
Економіка
Етика та Естетика
Журналістика
Інвестування
Інформатика
Історія
Культурологія
Література
Логіка
Логістика
Маркетинг
Медицина
Нерухомість
Менеджмент
Педагогіка
Політологія
Політекономія
Право
Природознавство
Психологія
Релігієзнавство
Риторика
Соціологія
Статистика
Техніка
Страхова справа
Товарознавство
Туризм
Філософія
Фінанси
Пошук