CC BY
11
податюв", "Введения даних до системи автоматизованоТ' обробки даних (АОД)", "Оперативний o6niK податюв i збор1в", "Формування звгпв та зведення ¡нформацн", "Прогнозування та анал1з податкових надходжень" та ¡н.
До четвертоТ групп вщносяться вщдти, яю мають зв'язки ттьки усередеж opraHisauiï. Це вщдю правового забезпечення - виконуе функцю "Правове забезпечення дтльносп податковоТ ¡нспекцн". Kpiis/i того, функцюнуе в оргажзацм вщд!л кадр1в, бухгалтер1я, адм1'нютративно-господарський вщдт. Вони виконують функци "Робота з кадрами", "Облк та контроль за використанням kolutîb на утримання ¡нспекцн", "АдмЫютративно-господарська д|'яльжсть" тоицо.
Граф1чно взаемод1я ¡з зовжшжм середовищем позначено як вихщ меж BiflflmiB за рамки оргажзацм.
Необхщжсть постмного удосконалення як вимоги стандарта якост1, вщображена наявнютю зворотного зв'язку мЬк результатом роботи - " виходом" та цшями i завданями - "входом".
Подальиш дослщження повинж бути нацтеж на встановлення i вивчення рацюнальних канал1в комужкацм м1ж визначеними структурними пщроздтами та трупами.
Л1ТЕРАТУРА
1. Друкер, Питер, Ф. Задачи менеджмента в ХХ1 веке : Пер. С англ. : Уч.пос. М.: Издательский дом «Вильяме», 2001. - 272с.
2. Хаммер М., Чампи Дж. Реинжениринг корпорации: Манифест революции в бизнесе. Пер. с англ. - СПб.: Издательство С.-Петербургского университета, 1997,- 332с.
3. Державна податкова служба УкраТни: довщник / Нечай H В , Онищенко В.А. - К.: "В'юник податковоТ служби УкраТни", 2001. -112с.
4. Наказ ДПА УкраТни вщ 20.04.2000 №207 "Про оргажзацмну структуру органов державно!' податковоТ служби".
5. Трахачов О. КритерШ роботи податювщв один - позитивний результат. //Вюник податковоТ служби УкраТни. - 2001(листопад-грудень). - с. 22-25.
6. Павленко В. Модержзацт системи навчання в державнш податковш служб1 УкраТни. //Вюник податковоТ служби УкраТни. - листопад-грудень 2001. -с. 13-15.
7. 7. В.А.Рач. К построению моделей проектного менеджмента.// Управлжня проектами та розвиток виробництва. Зб1рник наукових праць. -2000. - №2(1). - с. 18-23.
8. 8. ISO 9000:2000. Системи менеджменту якосл. Основоположш принципи i словник.
9. ISO 9001:2000. Системи менеджменту якостК Вимоги.
10. ISO 9004:2000. Системи менеджменту якосл! Настанови щодо полшшення показниюв.
Стаття надгёшла до редакцГТ 14.10.2001 р.
УДК 519.68:681.3:658.512
В.В. Морозов, О.М. Захарова
РОЗРОБКА МОДЕЛЕЙ УПРАВШННЯ 1НФОРМАЦ1ЙНИМИ ПОТОКАМИ В 1НТЕГРОВАНИХ ПРОЕКТАХ
У статт! розглядаеться коло питань, пов'язаних з розробкою моделей управлжня ¡нформацмними потоками в ¡нтегрованих проектах. Автори розробили еталонну модель або стандартну структуру, яка допомагатиме проектним менеджерам швидко отримувати "план елемент1в" (роботи, фази розвитку та документи) та "¡нструменти контролю " (звггжсть прогресу, bîxh та ochobhî лжи). Рис. 6, дж. 7.
Бтьшють npoeKTie, що сьогодж реал'1зуються в УкраТж, пов'язаж ¡нвестицтми у складж технологи, нове технолопчне обладнання, переозброення виробництва тощо. Важливе мюце тут придтено енергетичжй nporpaiwi УкраТни, яка пов'язана з проектами добудови енергогенеруючих потужностей ХмельницькоТ та РщненськоТ АЕС [6]. Очжуваний результат цих проект -
? S:
комплексний складний продукт (у кожый черз1 понад 50 взаемозв'язаних технолопчно скпадних об'екпв).
Виходячи з розвитку продукту, в проект! серед основних ресурса, яю е управляючими, прийнято визначати - час, грош/ / яюсть [1,2]. Безумовно, для складних ¡нтегрованих проект можна додати ще дв1 фундаментальж концепци: ¡нформацт /' оргашзацю, до яких застосовуеться управлжня. За такого ¡нтегрування виникають проблеми, скпаднють яких полягае в двох початкових елементах: структур/ юнцевого продукту проекту / в/'<Элов/дно оргамзацшному проектуванш. Для зменшення ц1е1 складност1 необхщно розробити механизм координаци м1ж цими двома елементами. Тому комплексному розвитку продукту необхщж нов1 методологи, яю управляють ¡нформац1йними потоками. Розвиток I застосування оргажзацмних процедур для ¡нтеграцм управлжня проектами \ управлжня документообтом дозволяе проектним менеджерам управляти ¡нформацмними потоками в проектах, тобто мати правдиву ¡нформац1ю про стан проекту та приймати ефективж ршення для його управлжня.
Документи з ¡нформац1ею про стан проекту мають можливють розширяти рамки ¡нформацн' з баз даних до щей 1 концепцм, а отже й впровадження комужкацм в межах оргажзацм \ за !х межами. Завдяки ц1й можливосп дуже важливо розвивати методи, яю ефективно управляють ¡нформац1йними потоками та передаються через документи. Ц1 методи допомагають управляти потоками ¡нформаци зпдно з дотриманням корисностч розподтення поток1в \ потр1бност1 ¡нформацн з потоюв, з визначенням потоюв, що спричиняють "шум".
Розвиток якосп продукту в проект! потребуе набору процедур, як1 визначають фази розвитку, рол1 \ вщповщальносп, документи. Отже, модель забезпечення якост1 потребуе трьох головних категорм робп-. По-перше, забезпечення якост1 вимагае оргажзацп плану 1 контролю робп\ а також простого управлжня документами для побудови продукту. По-друге, забезпечення якост'| потребуе управлжня документооб1гом згщно з вщповщальностями, повноваженнями, розповсюдженням, \ ф1зичним збер1ганням. По-трете, забезпечення якосл потребуе сильно!' системи, яка може вщстежувати документи для будь-якого типу юнцевого продукту проекту.
Рис.1 висвппюе два набори потоюв. Пот'1к вщ документа - до продукту пов'язаний з першою I другою категор1ею роб1т. Якщо набф правил I процедур, який регулюе фази проекту розвитку, ¡ндивщуальж рол1 \ вщповщальност^ \ управлжня документооб1гом добре визначеж, неважко досягти просування вщ документа до продукту. Влм, робота вщстеження документе для будь-якого продукту зазвичай важка 1 е перспективною частиною управлжня проектами або Тх основних частин (управлжня документооб1гом).
Досягнення якостч продукту вимагае того, щоб уа документи та специф|кацн будь-якого компоненту будь-якого продукту були вщстеженими. Для втшення цього потр1бно побудувати ефективну систему управлжня ¡нформацмними потоками ¡, як результат, ефективний документооб1г з боку управлжня.
ГПтература з проектного менеджменту [5,7] вщображае важлив1сть рол1 УУВБ (¡ерарх1чна структура робп-) та РИВЭ (¡ерарх1чна структура фаз) [3,4]. \ZVBS е потужним ¡нструментом, що використовуеться для планування \ контролю проекпв 1 зазвичай вщображае проектноор'юнтовану структуру. 1снуе безпосереджй зв'язок м1ж структурою продукту I ¡ерарх1чною структурою робп" в проектах, що розвиваються. РИВБ також потужний ¡нструмент, що використовуеться для планування 1 контролю проект за допомогою в1х проекту вщносно замовника. Ц| величини е дуже важливими через швидкий розвиток технолопй, складности продукту \ нестач1 стандарте. Використовуючи РИВЭ,
срентовану на кл1ента, проекгний менеджер може розвивати проектну структуру контролюючих завдань (цтей) 1 зв1тувати про статус проекту топ-менеджерам. Перетин цих двох структур показано на рис.2, вш визначае схему проекту. Остання е всеохоплюючим шаблоном, що вщображае, як ресурси розподтеж \ розташоваж.
ПРОЕКТ
В»д документа до продукту
Вщ продукту до документа
Рис.1. Документ як провщникдля розвитку якосп продукту
1ерарх!чна структура роб!т Тест _ тестування;
Док - документац1я;
Проект
Док
I
Тест! П
С
[I
А1
А2
С
□ □1
П - програмне забезпечення, ч^ А-програмно-апаратж ; засоби,
/К - комп'ютерна апаратура (робоч'| станцп), А1, А2- автоматизоваж робоч1 мюця (АРМ)
Функцюналь-ний прототип
Виробничий прототип
Пробний запуск
Торги
1ерарх1чна структура
Фази
Рис. 2.1ерарх1чна структура робп- (WBS) та ¡ерарх1чна структура фаз (РИВЭ) у
схем1 ¡нтегрованого проекту
lepapxiMHa структура докуменлв
Проект
Док|[
Тес
С
ц
г
п
Z1
□
Тест - Тестування
Док - Документация
П - програмне забезпечення,
А - програмно- anapaTHi
засоби,
К - комп'ютерна апаратура (робоч1 станци), А1, А2- автоматизоваж робоч1 мюця (АРМ)
lepapxiMHa структура фаз
Функцюналь-ний прототип
Виробничий прототип
Пробний запуск
Торги
~ Фази
Рис.3.1ерарх1чна структура докумекпв (DBS) та ¡ерарх!чна структура фаз проекту (PhBS) у модел'| документооб1'гу в npoeiai
Руипйною силою мон1торингу е DBS (¡ерархмна структура документооб1гу). Аналоги м1ж WBS та DBS вщдзеркалюються в структур! продукту. Проте вони pi3Hi, тому що WBS ор1ентована на завдання структури продукту, a DBS ор1ентована на документування структури продукту. Методология, що застосовуеться для управлЫня документооб!гом поеднуе Тх з PhBS при контролюванж наявност!' елементю i статусу розвитку фаз проекту. Документи створюються, утверджуються, запроваджуються та використовуються протягом життевого циклу проекту. Отже, якщо ми перехрестимо DBS та PhBS струетури, то зможемо визначити документи, що е сптьними для po6iT, що виконуються протягом ц1еТ фази. Рис.3, показуе перетин цих двох структур, в1н означае, що фаза розвитку не може бути повнютю закрита доти, доки eci документи за ц1ею фазою не будуть згенероваж, затверджеж та впроваджеж. Виходячи з ц!еТ перспективи, документи можуть бути розглянут1 як ф|'зичне досягнення фаз розробки.
Поеднавши рис.2 i рис.3, отримуемо рис,4, який представляв нар1жний кам1нь ¡нтеграцп компонента проектного менеджменту i управлЫня документооб1'гом. 1нтеграц1я м1ж ¡ерархмною структурою po6iT проекту (WBS) та затвердженою структурою вхщних та вихщних (3bit1b) документе (DBS) здмснюеться через PhBS - ¡ерарх!чну структуру фаз складного проекту. Головним результатом поеднання таких структур е "складання карти" мЫ< схемою проекту i документооб1гом. Завдяки цьому, запити кп1ента не можуть ¡гноруватися, i в'щповщно пщвищуеться яюсть юнцевого продукту завдяки яю'сному управлЫню проектом. Бтьш того, "складання карти" може бути переведено в процедури управлЫня конф1гурац'|ею якостк
Загальний потенцмний поштовх управлЫня документооб1гом значною Mipoio сприяе покращенню управляя фаз розробки продукту та реал'1зацм
1ерарх1чна структура робгг
1ерарх1чна структура документе
Проект
□ □
Док Тест П II А К
— _ г г-Ц г,
А1|А2
1ерарх1чна структура фаз
Функцюнальний прототип
Виробничий
Пробний запуск
Проект
1 1 1 1
Док Тест П|А|К
- Торги
- Фази
А1
А2
х: '1
х 1
□и □
□
Рис.4. 1нтеграц1я управлжня документами з компонентами управлшня проектами
проекту, тому що управлшня документооб1гом базуеться на впроваджены управлшня комушкац1ями та конф1гурац!ею проекту, швидкост1 призначення pecypciB i переплануванням, воно общяе пщвищення продуктивное^ управлшня проектами в цтому.
lepapxiMHa структура документе
Стандартний
список документа
Мххх
MAN
DBS для управлшня
[М421ДИ
INB
UP
SW
Стандартний
список попереджень
Стандартна WBS
WBS
Що
Коли
Хто
Стандартна PhBS OBS
PhBS
Л
□ о езёзеё:
WBS
г
»
ОТ
со л а.
I I lit I
II 1111
-I—«----т-"1"®»"*—
_i j___1
II 11 I г
---1--ir—»—---
■ III МШШШ
---1--
I I II I I
' ЙМЖМвМ»
Рис.5. Рекомендована модель проекту i процедури запуску проекту
Умовн1 позначки:
МХххх [Mail exchanges] - nouiTOBi записи (запис в DNS, що вказують адресу комп'ютер1в, яю обробляють кореспонденц1ю для даного домена);
MAN - [metropolitan area network] - ciTb, пром1жна за масштабом мЬк локальною i глобальною;
INB - 1нтернет баузер;
UP - скор, [microprocessor] мкропроцесор;
SW - скор [switch] 1. перемикач; комутацмний прилад; комутатор, ключ;
Р - [point] 1. точка, пункт;
М421 - канал (передач! даних або сигнал1в);
F.P. - ф|'ксована ц1на;
P.P. - покупна цша;
P.R. - платЬкна вщомють.
Модель управлшня ¡нтегрованими проектами
1нтеграцт компоненте проекту, що була проаналйована вище, мала на мел розвиток модел1 управлшня проектами, що розроблюеться. Запропонована модель побудована на засадах трьох головних стандартних структур: структури завдання або WBS, PhBS, DBS. Ц'| стандарты структури розвиваються зпдно з посиленням якост1 продукту, розвитку зниження цЫи i збтыиення швидкост1 процесу планування.
Метод базуеться на трьох основних ппотезах, що стосуються робп- з розробки продукту.
• Перше, доки розробка продукту може бути цтковито охоплена як ушкальна конф1гурац1я завдань, в реальностi pi3Hi продукти в межах даноi орган¡заци часто демонструють суттеву схожють в потоцi складових po6im.
• Друге, доки яюсть розробки продукту зазвичай обговорюеться в терм'ти статистичного контролю якост> (згЮно з планом eu6ipKu) i загальними ¡нструментами (контрольш таблицу, в diOcHocmi управлмня документооб'!гом е фундаментальним фактором, що забезпечуе яюсть.
• Трете, осктьки процеси створення продукту е важливим фактором розробки життевого циклу проекту, правильно визначеш процеси не потребують ущтьнення.
Наприклад, процес запуску проекту виглядае непотр1бним в багатьох компажях. Замють того, щоб скоординувати людей зосередитись на наборах стандарт i схожому практичному застосуванж, компанм пщштовхують людей пропонувати своТ оргажзацмж р1шення. Найбтьшим дефектом цього методу е те, що кожне ¡ндивщуальне впровадження в проект сприяе розрЬненню конкретно! структури i конкретного розумжня. Для запоб1гання цих довгих процес!в, потр!бно швидко зштися на piuieHHi побудови рекомендовано! модели яка охоплюе Bci фази, Bci роботи i контролююч1 системи.
Базуючись на цих шдставах, розробка запуску продукту враховуе еталон або базову структуру, яка поеднуе Bci елементи конф1гурацм, що можуть використовуватись в проектк 3 цього еталону можна обрати конкретж елементи, необх'щж для конкретного проекту.
Використовуючи стандарты структури, таю як WBS, PhBS, DBS проекты менеджери вилучають "плануюч1 елементи": роботи, фази розробки i документи. Також проектний менеджер може вилучити "контролююч1 ¡нструменти", таю як звп-ування прогресу, Bixn проекту i цтьов1 rtiHii. Завдяки рекомендована модел1 можпиво легко i швидко згенерувати плануюч1 елементи i контролююч1 ¡нструменти, виробити реалютичний i зручний план розвитку продукту. Рис.5 висв1тлюе процедури запуску проекту.
Рис.6. DOMAIN або ¡нтерфейс програмного забезпечення управлжня проектами
Таким чином, в ¡деальному випадку контроль змж е комплексною технолопею управлшня поведжкою 3mi'h проекту з вщповщним набором документами i розподтом обов'язюв.
Л1ТЕРАТУРА
1. KepiBHHL|TBO з основ проектного менеджменту. K.-.Binon, 1999.-197 с.
2. Бушуев С. Д., Г урин в.А. Инвестиционные инструменты проектного менеджмента. К.:УкрИНТЭИ, 1998, 184с.
3. Бушуев С.Д., Морозов В.В. Динамическое лидерство в управлении проектами. К.: Binon, 1999.-312 с.
4. Морозов В.В. Креативж технологи' розробки та прийняття pimeHb в концентричному управлжн1 портфелем проекта // Шляхи шдвищення ефективносп буд^вництва в умовах формуваиня ринкових bîahochh: Зб1рник наукових праць. Вип.8 - к.: КНУБА, 2000, с.44-49
5. LLIanipo В О. та ¡н. Управлшня проектами. -СПб.."ДваТри", 1996.- 610с.
6. Шепель В.И., Стариков И.В. Система управления проектами реструктуризации и развития предприятий // Управл!ння проектами та розвиток виробництва. Зб1рник наукових праць. Вип.2,-Луг.: Сх1дноукра'(нський держужверситет, 2000, с.25-36.
7. Савицкая Г.В. Анализ хозяйственной деятельности предприятия. Мн.:ИП "Эко-перспектива", 1998.-498 с.
Стаття надмшла до редакцп 06.07.2001 р.
