Aktuální vydání

celé číslo

12

2020

Systémy DCS pro kontinuální a dávkové výrobní procesy

Provozní analytická technika

celé číslo

Projektování IŘS: ohlédnutí po třinácti letech

číslo 11/2003

Projektování IŘS: ohlédnutí po třinácti letech

Projektování informačních a řídicích systémů prochází vývojem navazujícím na minulé zkušenosti. Nové metody a prostředky přitom nenacházejí vždy plnou odezvu v praxi. Příčinou je někdy nepřipravenost praxe a někdy také nesprávné předpoklady, ze kterých vycházejí tvůrci novým metod. Projektování je složitý proces, který musí být účinně řízen. Řízení projektů postupuje v několika hierarchických úrovních, které nelze směšovat. Nové metody a nástroje jsou správnou cestou vpřed. Jde jen o to, použít je na správném místě správným způsobem, což je záležitostí vedoucích pracovníků.

1. Úvod

Od počátku devadesátých let minulého století do dneška prošly způsoby projektování i sama koncepce informačních a řídicích systémů (IŘS) vývojem, který lze bez nadsázky nazvat bouřlivým a do jisté míry i překotným. Do devadesátých let nevstupovalo toto téma bez přípravy. I při omezených technických možnostech a z toho plynoucího nedostatku zkušeností bylo u nás instalováno nemálo funkčních počítačových automatizovaných IŘS. Jejich počet byl v řádu tisíců. Jen průmyslových aplikací počítače ADT tuzemského původu bylo jistě přes jeden tisíc. A navíc rok 1989 otevřel stavidla přívalu nejmodernější techniky. Pro následující období bylo charakteristické, že projektanti měli k dispozici nejmodernější produkty jak technické, tak i programové. Spolu s nimi se otevřel přístup také k moderním metodám projektování a realizace automatizovaných IŘS i příslušným nástrojům jejich počítačové podpory. Zvláště tyto metody a nástroje procházely i v následujícím období dalším zásadním vývojem. I nás tedy, stejně jako pracovníky ve vyspělejších zemích, zasáhly potíže provázející osvojování těchto nových prostředků a nezbytnou adaptaci uživatelů na ně.

Zajímavý a výstižný pohled na současnou situaci v projektování IŘS ze všech podstatných hledisek, která máme na mysli v tomto příspěvku, byl publikován v [1]. Autoři sice opakovaně deklarují neúplnost a nesystematičnost svých úvah, domnívám se však, že se v článku dotýkají všeho podstatného a s jejich názory lze vesměs souhlasit. Jedná se o problematiku velmi složitou, i nadále se vyvíjející. Jistě nebude na škodu připojit několik poznámek a pokusit se o pohled i z poněkud jiného úhlu.

2. Historický úvod

Na využití výpočetní techniky v automatizaci pomýšleli již tvůrci prvních počítacích strojů. Zcela praktické důvody, zejména ekonomické a spolehlivostní, však vedly k tomu, že se počítače vyvíjely pod vlivem jiných než automatizačních aplikací. Byly to v první řadě tzv. vědeckotechnické výpočty a brzy po nich hromadné zpracování dat motivované využitím počítačů v ekonomické a správní oblasti. Do automatizační techniky vstupovaly počítače pomalu a jaksi váhavě. Jistě zde hrály zásadní roli požadavky na nezbytnou velkou spolehlivost a na hospodárnost. Nelze však pominout neprozíravost „lidského faktoru„. Pamětníci jistě vzpomenou na případy, kdy u technologických procesů s běžnými výpadky v rozsahu desítek procent provozní doby byly kladeny požadavky na téměř absolutní spolehlivost počítačového řídicího systému. Probíhal zde také souboj analogové techniky s jejím novým konkurentem, číslicovou technikou (v oblasti vědeckotechnických výpočtů např. nikoho ani nenapadlo porovnávat mechanickou kalkulačku s moderním počítačem). V automatizační technice tak byla pro nalezení správného směru potřebná i jistá dávka prozíravosti a technické fantazie.

Všechny tyto vlivy a mnoho dalších, které zde z prostorových důvodů nelze podrobně rozebírat, způsobily stav, jenž má v oboru automatizace počátky již zhruba před 30 lety a v postatě trvá dodnes.

Nad dílem – automatizačním projektem – se schází několik profesí, které jsou vybaveny odlišnou metodikou a většinou jednotlivě postrádají komplexní pohled na řešený problém. Vše začíná u technologického zařízení, resp. technologického procesu, který má být automatizován, a pokračuje přes technické automatizační prostředky až po programové řešení – viz doprovodný text Složky projektu IŘS.


Složky projektu IŘS
Moderní IŘS jsou bez počítačů nemyslitelné. Snadno se tedy z počítačové terminologie do projektové praxe zaneslo dělení na hardware a software. Hardware znamená technickou, hmotnou část díla, ať již se jedná o počítačový hardware nebo o jiné nepočítačové hmotné součásti. Software znamená nehmotnou část díla. V počítačové části díla jsou to programy jakožto realizace příslušných algoritmů. V IŘS je však podstatnou složkou systémů nehmotná součást díla, jež představuje funkční postupy, metody a podobné nehmotné objekty, které jsou pro zajištění správné funkce díla vymýšleny a vyvíjeny a které jsou ve své konečné podobě obsaženy v již zmíněných algoritmech. Zásadní důležitost této složky pro úspěšnost díla vyžaduje, abychom ji neskrývali v softwaru, ale abychom ji postavili na místo, které jí v rámci díla přísluší. Měli bychom tedy mluvit např. o funkční složce díla, tj. funkčnosti systému. Projekt (zde jakožto návrh) systému tedy sestává z funkční složky (algoritmy funkcí systému), technické složky (hardware) a programové složky (software). Software je programovou realizací algoritmů. Algoritmy však lze realizovat i jinak, jak z vlastní zkušenosti ví každý, kdo se automatizací zabývá.

(jc)


Úmyslně zde z výčtu složek automatizačního projektu vydělujeme do zvláštního odstavce vlastní funkční schopnosti (funkčnost) IŘS. V rámci automatizačního projektu je třeba je důkladně prošetřit – a to nejen také, ale nejspíše na prvním místě –, neboť tato jeho stránka je pro budoucí úspěšnost automatizovaného procesu snad nejpodstatnější. Nestačí se pouze slepě držet zadání, ale i projektant se musí zamyslet nad účelností a úplností projektovaných funkcí systému a ze svého zamyšlení také vyvodit závěry. Ve skutečnosti je bohužel tato důležitá činnost zásadního významu vykonávána většinou nepříliš systematicky a často je suplována na úrovni nesrovnatelně nižší než úroveň, na jaké zpracovávají a předkládají svá řešení ostatní spolupracující profese. V organizačních schématech sice jde o činnost označovanou jako systémově analytická, avšak ve skutečnosti nakonec zpravidla spadne na bedra programátora a nebo automatizačního technika. Dosavadní automatizační projekty tak doplácejí na naprostý nedostatek systémových analytiků, kteří by spojovali obě naposled uvedené profese, ovšem na patřičné úrovni. Nestačí ovládat např. programování PLC (Programmable Logic Controller – programovatelný automat) nebo umět použít PID regulátor, budeme-li problém poněkud vulgarizovat.

V minulosti se tyto obtíže projevovaly v trochu menší míře. Praxe vyžadovala realizaci dílčích úloh, lokálních regulačních smyček, ovládání jednotlivých agregátů apod. Současný vývoj však pokračuje rychle dále a zadávané úlohy nyní již vesměs mají jasné rysy komplexní automatizace, kdy IŘS přesahuje rámec např. technologického procesu a zasahuje i do subsystémů ekonomie, údržby, zabezpečení kvality, spolehlivosti atd. V současných úlohách již nejde jen o pouhé předávání dat mezi systémy, které jsou v podstatě nezávislé, ale jedná se skutečně o jeden komplexní systém, který musí být řešen jako jeden celek tvořený vzájemně spolupracujícími a vzájemně se ovlivňujícími jednotkami, subsystémy. O systémovém řešení se mluví již desítky let. V minulosti byl však tento přístup při projektování brán vážně jen zřídkakdy. V současnosti je ale nepominutelný. V [1] je uvedeno několik poznámek, které tuto nezbytnost dokládají, např. zmínka o tzv. povelování z úrovně podniku. Zajímavým podnětem v tomto směru je kniha [3], o které bylo referováno ve [4] a v [5].

3. Podmínky realizace IŘS

V současnosti a jistě v blízké budoucnosti nevystačíme v automatizačních projektech s metodami a technikami programování, které jsme měli příležitost poznat při aplikaci PLC. Komplexní automatizační projekty dnes představují z hlediska softwaru heterogenní směs programovacích prostředků a metod. O tom, že končí éra ostrovů automatizace, není pochyb, a není tedy rozumné i nadále např. striktně dělit automatizační projekty na realizace systémů řídícího nebo ovládacího typu a na úlohy informační. Je zapotřebí, i když se nám to někdy ještě nemusí zdát nezbytné, vidět projekty jako celek, který má vždy informační a současně řídící charakter.

Vývoj nás však dovedl do stavu, kdy ovládací obvody řešíme pomocí speciálního softwaru programovatelných automatů, který se ještě dále dělí na prostředky pro tzv. diskrétní řízení, jako je např. řada Simatic od firmy Siemens, a prostředky pro tzv. spojité řízení, rozuměj regulaci, např. systém Teleperm od téže firmy. Vedle toho v automatizaci existuje neméně důležitá oblast dispečerských systémů založená na použití vizualizačních programových systémů. Ty se v posledním desetiletí rozvinuly v univerzální dispečerské informační a řídicí systémy a jsou pro většinu běžných úloh schopny zajistit nejen vizualizaci, nezbytnou pro operátorské řízení, ale i diagnostiku nestandardních stavů, dlouhodobé sledování procesu a archivaci záznamů o jeho průběhu, propojení s databázovým systémem a mnoho dalších činností, např. statistické řízení procesu (Statistical Process Control – SPC) zasahující do oblasti zajištění kvality produkce. A toto vše vlastně jen parametrizací již hotového programového produktu. Příkladem jsou produkty nabízené u nás firmou Pantek (CS).

Pestrost automatizačních prostředků dále rozšiřují např. prostředky pro komunikaci mezi počítači v průmyslovém prostředí, techniky komponentové tvorby softwaru (OPC – OLE for Process Control) a využití internetových nástrojů v řídicích systémech, vyjmenujeme-li jen ty nejfrekventovanější. Jestliže budeme trvat na komplexnosti pohledu, je třeba k tomuto seznamu ještě připojit databázové systémy samy o sobě i jejich aktuální odnož, datové sklady.

Současný systémový analytik se bez slušné orientace ve všech právě uvedených tématech neobejde. Důležité je, že tyto problémy nelze sledovat pouze z programátorského hlediska. Termín programátorský zde úmyslně používáme pro odlišení od hlediska softwarověinženýrského. Domníváme se totiž, že většina programátorů automatizace jsou mnohem více programátoři než softwaroví inženýři.

Pro úplnost se sluší poznamenat, že systémový analytik má část své profese společnou se systémovým inženýrem, avšak stejně důkladně musí obsáhnout i témata automatizační a systémově funkční. Zdá se, že se otevírá prostor pro rehabilitaci kybernetiky, v průběhu let postupně ustupující do pozadí. Byla to však právě kybernetika, která vždy zdůrazňovala onu nyní stále více postrádanou systémovost přístupu k řešení problémů a vytvářela pro ni solidní odborný základ. Je velmi důležité snažit se navázat užší kontakt mezi obory a pozvednout tak úroveň automatizačních projektů na patřičnou výši. Příkladem může být [2], článek na téma, které v současné době ještě asi nebude každý z nás považovat za aktuální a potřebné. Pak se však mýlí.

4. Podmínky projektování IŘS

V závěru [1] vyjadřují autoři pesimistický názor na reálné možnosti uplatnění moderních přístupů v aktuálních podmínkách a v celé jejich šíři nabízené v současné době. Upozorňují na to, že mnohé stávající systémy bude nutné zcela rekonstruovat. Dodejme, že nákladně. S touto situací, ani názorem, se však nelze smířit. Současný stav je nepříznivý a není snadno změnitelný, avšak změnit ho je třeba. Je důsledkem dlouhého vývoje a do značné míry je i pochopitelný. Nemá zřejmě smysl na tomto místě rozebírat podstatu a příčiny „různých okolností“ (viz závěr [1]), které použití moderních projektových a realizačních přístupů „předem vylučují“. To je téma, které spíše přísluší rozborům z manažerského a obchodního pohledu. Můžeme se však pokusit na příkladu moderních metod analýzy systémů ukázat příčiny některých neúspěchů.


Projekt IŘS
V článku se do detailů nedržíme terminologie, kterou se snaží zavést naše normy, jež se ve snaze o naprostou přesnost a jednoznačnost odchylují od názvosloví již přijatého většinou automatizační komunity.
Na rozdíl od jiných jazyků, např. angličtiny, je termín projekt v češtině chápan poněkud mnohoznačně.
Projektem se jednak rozumí vlastní návrh systému, v užším smyslu někdy dokonce jen soubor dokumentace. V jiných souvislostech se o projektu uvažuje jako o díle. Mluví se o účasti nebo podílení se na projektu a rozumí se tím účast na realizaci díla. Angličtina používá pro návrhovou část projektu termín design a pro dílo i v realizační části termín projekt. Není však důvod pro to, abychom vyslyšeli některé autory a snažili se o podobnou jednoznačnost i u nás. Z kontextu by totiž vždy mělo jasně vyplývat, oč běží, a nebezpečí nedorozumění by tak mělo být téměř zanedbatelné.

(jc)


Metody analýzy systémů se díky počítačové podpoře vymanily z balastu rádoby vědeckých přístupů, dlouhá léta předkládaných pod nadpisem systémový přístup, systémová analýza apod. Počítačová podpora se realizovala pomocí různých softwarových nástrojů a své vrcholné úrovně dosáhla v systémech typu CASE (Computer Aided System Engineering). Počátkem devadesátých let dosáhly tyto prostředky značné popularity, která vytrvala až téměř do konce století. Jen u nás bylo prodáno několik set licencí. Nejúspěšnější byl systém case/4/0 s téměř dvěma sty licencí. Distributor systému uváděl úspěšnost zavedení do užívání v praxi kolem 70 %. Skutečnost však byla jiná. Většina uživatelů CASE systém postupně téměř opustila, nebo ho využívala jen velmi omezeně. Nejlépe dopadli ti uživatelé, u kterých se aplikací ujali zkušení systémoví analytici, tj. pracovníci, kteří prošli praxí realizace větších počítačově automatizovaných systémů, především jejich softwarové části, ať již v oblasti průmyslové automatizace nebo tzv. hromadného zpracování dat. Ve většině případů však uživatel systémů CASE ztroskotal na naprostém nedostatku pracovníků s invencí, takových, kteří jsou schopni vytvářet koncepci projektovaného systému. Tím není řečeno, že takoví projektanti v našich firmách nejsou. Není jich sice nadbytek, ale je především na manažerech (zde úmyslně používáme tento termín místo zastaralého „vedoucího (tvůrčího) pracovníka„, abychom vyjádřili rozdíl mezi současným a minulým obsahem této profese), aby na správná místa postavili správné pracovníky a aby dokázali moderní postupy zavést do praxe s patřičným ekonomickým efektem.

Diskuse o ekonomické a také všeobecné efektivnosti moderních metod projektování zde není na místě. Jejich efektivita je zřejmá. Jestliže se o ní pochybuje, jsou to pochybnosti o rychlé návratnosti vložených nákladů, především nákladů na osvojení a zavedení do praxe, a nesnáze spojené s nedostatečně komplexním pojetím automatizovaných systémů (viz také kap. 7).

Samotná praxe ukazuje, že sice mnohem pomaleji, než by bylo možné, ale přesto se moderní přístupy v projektování IŘS prosazují. Stále častěji se ti, kteří ještě ani v nedávné době nepochopili smysl a význam nových přístupů a odmítali je, vracejí a hledají to, co jim tyto přístupy nabízejí nyní a nabízely již deset či patnáct let. Vracejí se oklikou na místa, na jejichž prahu již jednou stáli.

Naproti tomu tvůrci nových metod a jejich počítačové podpory podcenili reálnou situaci. Nesnažili se vytvořit podmínky pro postupné zavádění nových metod a nástrojů. Sice slibovali potenciálním uživatelům to, co nabízené prostředky skutečně umožňovaly, avšak neuvědomili si, že to bez odborného vedení a pomoci nemohou poskytnout v rukách nepřipravených uživatelů. Zde je tím myšlena nejen vhodná cenová politika, ale i uvážení nereálnosti zásadní skokové změny postupů projektování. Výsledkem je současný stav, kdy se moderní metody projektování uplatňují téměř výhradně u progresivnějších ze softwarových firem s převažujícími aplikacemi v oblasti „čistých„ informačních systémů. Neovlivněna nezůstala ani oblast objektově orientovaných systémověanalytických metod, kde však jde o záležitost komplikovanější a dosud neuzavřenou.

Vše, co je k systémům CASE v této kapitole řečeno, lze u nás vztáhnout i na metodiky projektování IŘS. I zde znamenají moderní metody velký nápor na změnu dosavadních, zaběhnutých postupů. Střetává se tu setrvačnost a s ní spojený odpor ke změnám s ekonomickou náročností a s požadavky na osvojování nových znalostí i z oborů dosavadnímu přístupu někdy relativně odlehlých. Jako triviální příklad je možné jmenovat prostou tzv. počítačovou gramotnost.

Bude tedy na místě, u problematiky metod projektování se zastavit.

5. Řízení automatizačních projektů

5.1 Řízení projektů (project management) je hierarchií řídicích procesů
Následující úvahy mohou snad někomu připadat poněkud triviální. Potřeba je opakovně připomínat však vychází ze zkušeností získaných v přímém kontaktu s realitou.

Automatizační projekty (kde projektem, jak jsme již naznačili, se rozumí dílo a nikoliv jen jeho návrh – viz doprovodný text Projekt IŘS) jsou složité soubory činností a jako s takovými se s nimi musí zacházet. Musí být řízeny neboli spravovány, tj. řízeny s náležitou váhou kladenou také na ekonomickou a organizační stránku věci.

Na tomto místě je třeba poznamenat, že řízení je v češtině pojmem obecným, avšak s významem např. ve srovnání s angličtinou poněkud užším. Řízením se rozumí působení na složky systému se záměrem dosáhnout nějakého určitého cíle. V případě automatizačních projektů je nutně předmětem zájmu pouze určitá třída vstupů a výstupů zmíněného systému. Těžko bychom asi hledali vstupní veličinu projektu, která by byla zařaditelná do společné třídy s vnitřní veličinou řídicího systému typu např. žádaná teplota v peci. Proto bychom měli dávat přednost termínu správa projektu před jeho řízením, i když druhý, obecnější z termínů nebude zdrojem zmatení pojmů, a je tedy dobře přijatelný (a je především ve významu správa používán v tomto článku). Reagujeme tímto na stav, kdy se v našich normách i v odborné mluvě a publikacích nevhodně a patrně již natrvalo usadil termín management (jedním z příkladů je [7]). K tomu nelze než konstatovat, že přejímání cizích termínů, u kterých se slovo nejenže jinak píše a jinak vyslovuje, ale po jeho necitlivém přenosu z jiného jazykového prostředí a kontextu se vytratí i to, co by měl nově vzniklý „český„ termín vlastně značit, je neomluvitelným prohřeškem nejen proti českému jazyku, ale jazyku obecně jako nástroji komunikace (např. s počítačem se podobnou hatmatilkou nikdo nedomluví, a ani se o to nepokouší).

Pohled na řízení projektů je možné zjednodušit, vyjdeme-li ze skutečnosti, že projekt, jakožto soubor činností, jejichž výsledkem je realizované dílo, má hierarchickou strukturu. Lze se pak zaměřit na každou úroveň hierarchie samostatně a tak lépe pochopit některé, na první pohled protichůdné názory a postoje těch, kdo se danou problematikou zabývají.

Hierarchické struktuře v řízení obecného projektu je věnován text Hierarchická struktura v řízení projektů umístěný v rámečku na této straně. O specifické struktuře řízení projektů IŘS pojednávají následující odstavce.

5.2 Tři úrovně v řízení automatizačních projektů Dlouhou dobu byly projekty IŘS řízeny na základě zkušeností a tzv. selského rozumu. Až poměrně nedávno k nám z vyspělých zemí pronikly exaktní metody řízení projektů. V praxi tento vývoj vedl k určitému zmatení pojmů a metod. Stále trvá stav, kdy si účastníci projektu z různých profesí nerozumějí. Zejména markantní je to při komunikaci mezi ekonomy, techniky, které je pro tento účel ještě třeba rozdělit nejméně do tří skupin na technology (strojaře, chemiky, elektrotechniky), „automatizéry„ a „počítačníky„. Projekt automatizace technologického zařízení vytvořený technologem je něco jiného než projekt automatizace, který na něj navazuje, a ten je opět něčím jiným než projekt programového vybavení téhož systému.

Takto složitý systém nelze efektivně řídit jednoduchým způsobem. Je účelné rozdělit řízení projektu IŘS jakožto návrhu a realizace díla do tří úrovní:

  • základní, tj. vlastní technickou realizaci projektu,
  • střední, spočívající v organizování a kontrole průběhu projektu,
  • vyšší, představovanou současným klasickým řízením prací na projektu.

Řídícím činitelem na základní úrovni řízení je sám realizátor, přesněji řečeno projektová skupina. Hlediska, která ve svých rozhodnutích – tj. řídících zásazích do systému – zohledňuje, však nejsou čistě technická. Dobrý projektant naopak musí přihlížet k hlediskům efektivnosti, rentability, spolehlivosti, kvality atd., která přímo a nebo ve svých důsledcích ovlivňují ekonomické ukazatele díla.

Střední úroveň řízení je nadřazena základní a zabezpečuje organizaci projektu a kontrolu jeho průběhu. V oblasti vlastní realizace díla náleží do její kompetence stanovení organizační struktury projektového týmu, přidělení zodpovědností a plánovací a kontrolní činnosti. Dále sem patří zabezpečení kvality prostřednictvím přiměřeného souboru zkušebních činností a souboru opatření na potřebné úrovni zajišťujících realizaci a kontrolu změn v projektu. Tyto úkoly doplňuje organizační zajištění dokumentační stránky projektu prostřednictvím tzv. správy konfigurací.

Vyšší úroveň řízení projektu IŘS spočívá v současné podobě klasického řízení projektových prací prostřednictvím plánování, sledování a vyhodnocování ekonomických, časových a kvalitativních ukazatelů realizovaného díla. Řízení na této úrovni má výrazněji ekonomický charakter. Celkový úspěch však zcela nepochybně závisí na kvalitě práce odvedené v podřízených řídících úrovních.


Hierarchická struktura v řízení projektů
Strukturou řízení projektu projdeme shora dolů.
V nejvyšší úrovni řízení musí každé dílo vycházet z nějakého záměru, jehož autorem je jeho budoucí vlastník a provozovatel či uživatel. Pomineme-li detaily, je možné říci, že se jedná o záležitost obchodně-technickou. Na straně realizátora (dodavatele) díla se dílo jeví jako zakázka, která je výsledkem obchodních činností. Realizátor díla musí zajistit, aby dílo bylo provedeno podle požadavků zadavatele. Ty lze shrnout pod trojici základních hledisek, která jsou pro výsledek určující, a to hledisko ekonomické, časové (termíny) a technické. Technické hledisko zahrnuje výkonnostní a kvalitativní ukazatele díla. Na vyšších hierarchických úrovních řízení projektu lze technické parametry díla ovlivnit jen na obecnější úrovni a prostředky v podstatě stejnými jako v záležitostech ekonomických a časových.
Dosažení požadovaných výsledků lze ovlivnit organizačním uspořádáním projektových činností, správným přidělením finančních prostředků a stanovením časového plánu. Účinným pomocníkem je sledování a operativní řízení postupu prací na projektu. Tyto záležitosti jsou tématem tzv. řízení projektů (project management). Na tomto místě je třeba poznamenat, že u nás se k označení těchto činností chybným překladem rozšířil termín projektové řízení. Současně se však tentýž termín, tentokrát v duchu našeho jazyka správněji, používá pro organizační uspořádání zajišťující řízení činnosti v závislosti na řešeném projektu (tedy by project).
Výstupem vrchní úrovně řízení projektu je rozhodnutí o tom, co se bude dělat (více či méně obecně formulované zadání), kdo a v jakém termínu to bude dělat a kolik to bude stát. Nejde však o jednorázové rozhodnutí jednou provždy, ale o soustavnou aktualizaci a kontrolu plnění těchto rozhodnutí. Ve vrchní hierarchické úrovni jsou k dispozici prostředky pro plánování, dokumentování, vyhodnocování a optimalizaci prací na projektu.
Úkolem nižší (základní) úrovně řízení projektu je plnit tato rozhodnutí a provést je do posledního detailu. Na této základní a spíše technické úrovni řízení projektu lze rozlišit čtyři skupiny činností. Dvě z nich lze pokládat za hlavní. Jsou to:

  • vlastní řízení projektu, které do určité míry kopíruje řízení (správu) projektu ve vrchní úrovni řízení: stanovuje podrobné organizační uspořádání činností, odpovědnost pracovníků (pracovních týmů), časový plán atd., detailně sleduje průběh prací na projektu, aktualizuje výchozí rozhodnutí a průběžně poskytuje údaje potřebné pro řízení projektu ve vrchní hierarchické úrovni,

  • vlastní realizace projektu, přestavující v jistém smyslu další, třetí úroveň řízení tvorby díla: tj. činnosti naplňující jednotlivé etapy životního cyklu projektu, mezi něž patří zejména specifikace a analýza požadavků na realizovaný systém, návrh realizovaného systému, jeho realizace (implementace), integrace, vyzkoušení a uvedení do provozu (tedy činnosti, které byly i v minulosti náplní projektování a realizace díla, ne však vždy všechny a ve správné míře).

Další dvě skupiny činností probíhajících v základní úrovni řízení projektu mají v jistém smyslu doplňkový charakter, jsou však v současných podmínkách nepominutelné. Jsou to:

  • zajištění kvality, zejména příprava zkoušek a vlastní zkoušky realizovaného díla,

  • správa konfigurací, kterou se rozumí důsledná správa všech složek projektu prostřednictvím dokumentace všech v něm vznikajících produktů prostřednictvím knihovny produktů, včetně správy verzí a dokumentačního a organizačního zajištění změnového řízení, které je důležitým nástrojem zabezpečení kvality díla.

Popsaná základní úroveň řízení projektu je náplní standardních metodik projektování, kterých je známo velké množství, a jejichž příkladem může být německý V-Modell [6].

(jc)


6. Úskalí počítačové podpory projektování

Řízení projektu je náročnou a nákladnou záležitostí. Počítačová podpora a s ní spojené nové metody řízení projektů se proto ukázaly být vítaným a postupem času nepostradatelným nástrojem. Různé úrovně řízení, na které jsme zde proces projektování (IŘS) rozdělili, vyžadují dosti zásadně odlišné metody a využívají specifické prostředky počítačové podpory, jako např.:

  • základní: textové a grafické editory, systémy CAD a CASE, vývojová prostředí (databázových systémů, programů pro PLC, programovacích jazyků),

  • střední: nástroje pro vedení prací (workflow), např. program InStep firmy microTOOL, knihovní systémy, Microsoft Project apod.,

  • vyšší: nástroje pro plánování a sledování činností, např. Microsoft Project, Primavera apod.

Podrobný výčet ani charakteristika těchto produktů ovšem nejsou tématem tohoto příspěvku. Podívejme se namísto toho na některá úskalí obecně provázející jejich použití.

Počítačová podpora je velmi dobrá, avšak dvousečná zbraň. Není pochyb o tom, že počítač je pro účinné, moderní řízení projektů zcela nezbytný. Naproti tomu není počítač nástrojem jednoduchým. Stále ještě není pouhou pomůckou, jen naším prodluženým smyslem nebo končetinou, jako je tomu u televizoru, telefonu nebo automobilu. Tuto nižší roli hraje počítač jen někdy, např. v roli textového editoru. Často však vyhledáváme jeho pomoc při náročnějších duševních činnostech představujících specifické způsoby zpracování informace. A v těchto případech nestačí jen „zapnout televizor„, kdy již nezáleží, zda a jak vnímáme to, co nám přístroj poskytuje. S počítačem je nutné spolupracovat a přinutit ho, aby zpracovával informace požadovaným způsobem, avšak ten je zapotřebí mu sdělit. Musíme tedy počítač programovat. Ať máme na mysli programování v klasickém smyslu v nějakém programovacím jazyce nebo práci s již hotovými programovými systémy, které tvůrčím způsobem využíváme. I tomto případě vlastně jde o jakési programování, tj. činnost vyžadující přiměřené vzdělání a zkušenost a především schopnost produkovat nápady, mít invenci. Počítač nelze efektivně využít bez dosažení určitého vyššího stupně rozvoje logického myšlení a určitého stupně nadání k matematice. A zde je zřejmě jádro příčiny, proč prostředky počítačové podpory řízení projektů (a nejen v této aplikační oblasti) narážejí na bariéru nepochopení a odmítání a proč se trvale lze setkávat s neúspěchy v zavádění moderních metod řízení a realizace projektů od počítačové podpory – jak jsme již řekli – neoddělitelných. Vedoucí i výkonní pracovníci často očekávají, že s metodami implementovanými programovými systémy dostávají do rukou hotové nástroje, které budou používat tak jako psací stroj. Jde ale o zásadní omyl. Ani práce s textovým editorem není tak jednoduchá jako psaní na psacím stroji nebo řízení auta v běžném provozu, natož práce s programovým systémem, který pouze podporuje určitou metodu, jejíž aplikaci musíme teprve vytvořit. Tyto, možná provokativní názory se opírají o dosti bohatou zkušenost z praxe. Zavedení nových metod naráží na nejméně potíží tam, kde se ho ujmou pracovníci s dobrou programátorskou a analytickou zkušeností, kteří prokázali schopnost myšlení, jehož charakteristiky jsme již uvedli, a které pro naši potřebu nazveme počítačovým myšlením.

Utopickou myšlenku přenesení lidského myšlení na stroje ponecháme stranou. Potřebujeme strojům svěřit jistým způsobem zmechanizované a nejvýše zautomatizované zpracování informace. To nelze realizovat bez zapojení lidského intelektu i ve fázi přímého řešení úkolu svěřovaného stroji. Stejně tak jako stroj musí vyhovovat určitým požadavkům, musí i člověk, který ho zapojuje do svých myšlenkových tvůrčích procesů, vyhovovat určitým předpokladům, mít potřebné vzdělání a zkušenosti – v souhrnu předpoklady pro tvůrčí práci. A řízení projektů je výsostně tvůrčí prací.

7. Efektivnost moderních metod projektování

Moderní metody projektování úzce souvisejí se zabezpečením kvality. Praxe se zaváděním norem řady ISO 9000 ukázala, že teoreticky dokonalý postup přináší závažné problémy, které souvisejí s ekonomickými hledisky. Všeobecně se ukazuje, že k uplatnění exaktních postupů není možné přistupovat tak, že je budeme aplikovat striktně bez ohledu na to, co to stojí. Je zde opět na pořadu hledisko ekonomické rentability postupů. Je tedy zřejmé, že propojení ekonomie a automatizace se dostává na pořad dne a do naší automatizační problematiky vstupuje ze všech stran [3].

Při úvahách o efektivnosti se znovu musíme vrátit k tématu komplexnosti automatizovaných systémů.

Každý automatizovaný řídicí systém je především systémem informačním. Současně je zařazen v řídicím a informačním systému technologického procesu, výrobního procesu, firmy nebo podniku. V současnosti již nelze toto začlenění chápat celkem jednoduše jen jako potřebu předávání dat mezi jednotlivými subsystémy celku, např. údajů potřebných pro fakturaci spotřeby energie ve výrobě. Dnešní potřeby jsou mnohem dále.

Lze se setkat s požadavky na sběr a zpracování dat a jejich poskytování v reálném čase dalším systémům a současně přizpůsobení vlastní činnosti aktuální situaci v nadřazeném a spolupracujícím systému. Tedy potřebou reagovat na aktuální, měnící se požadavky spolupracujícího systému. Zde již nebude kvalitní analýza systému nadbytečným luxusem. Mnoho nedomyšleností, nedostatků a chyb v realizovaných systémech vyžaduje podrobnou analýzu příčin jejich vzniku. Sledování stavu systému, jeho záznam a archivace už přestávají být jen doplňkem. Průběh stavu systému se tedy nezaznamenává jen pro dokumentaci určitých předem specifikovaných událostí, ale pro případnou analýzu jevů a vlastností, které postřehneme až v budoucnu. Budeme tedy zaznamenávat stav systému co nejpodrobněji, abychom měli dostatek údajů pro později specifikované analýzy. Tím se otevírá prostor pro uplatnění informačních systémů založených na moderních databázových systémech, technikách datových skladů, metodách statistické analýzy atd. A opět musí nastoupit systémová analýza, která je cestou ke stanovení koncepce projektovaného systému a která dovolí tyto nové možnosti plně využít.

Opakuje se zde situace, kterou systémy hromadného zpracování dat prošly již před několika desetiletími, kdy výpočetní střediska produkovala tištěné „sjetiny„ pravidelně odvážené do sběru starého papíru. Nebylo v lidských silách nevhodně uspořádaná data efektivně využít. Mnohý ze současných provozovatelů automatizovaných IŘS neví, co s archivovanými daty. Soubory dat bývají neúplné, s chybami, a tedy obtížně využitelné. Nelze se divit uživatelům, kteří nashromážděná data po poměrně krátké době likvidují jako nepotřebná.

8. Závěr

Závěrem tedy konstatujme, že situace není ve své podstatě nijak špatná. V tom směru bych nesdílel pesimismus autorů [1]. Nástroje a metody máme k dispozici. Technické prostředky svou kvalitou vyhovují požadavkům většiny úloh. Jistěže je mnoho problémů, které je třeba řešit, dokonce i na teoretické úrovni. K takovým patří např. záležitosti komplexních automatizovaných systémů. Na jednom stole se scházejí a vzájemně prolínají problémy technických a programových prostředků, automatizační, systémové a ekonomické, které je třeba sladit a řešit jako jeden celek. Proto je nutné zaměřit své úsilí na opětné sjednocení témat, která se v průběhu let přirozeným vývojem a vlivem různých okolností rozešla.

Potřebujeme systémové analytiky, ovšem ty skutečné. Dnes se již nerozšiřuje prostor pro izolované odborníky na programování, regulaci, zpracování dat atd. Potřebujeme odborníky, kteří budou schopni řešit automatizační úlohy z příslušného nadhledu. A zde je zřejmě hlavní tíha zodpovědnosti na manažerech, kteří musí pro tento vývoj vytvořit koncepční, organizační a ekonomické předpoklady.

Poděkování
Příspěvěk vznikl v rámci řešení výzkumného záměru Fakulty aplikovaných věd Západočeské univerzity v Plzni č. MSM 235200004.

Literatura:

[1] FIBÍR, J. – NOVOTNÝ R.: Nové trendy v automatizaci technologických procesů v praxi. In: Sborník z konference Pragoregula/Elexpo 2003, Praha, březen 2003.

[2] TŮMA, P.: Co nového přinášejí moderní softwarové architektury? Automa, v tisku.

[3] MARTIN, P. G.: Bottom-Line Automation. ISA – The Instrumentation, Systems, and Automation Society, 2002.

[4] CENDELÍN, J.: Technický pohled na automatizaci nestačí. Automa, 2003, roč. 9, č. 4, s. 45–46.

[5] FIALA, P.: Recenze: Bottom-Line Automation. Automa, 2003, roč. 9, č. 4, s. 43–44.

[6] CENDELÍN, J.: Moderní metody projektování automatizovaných informačních a řídicích systémů. Automatizace, 2000, roč. 43, č. 3–12 a 2001, roč. 44, č. 3–5 (příloha časopisu).

[7] ČSN ISO 10007 Management jakosti – Směrnice pro management konfigurace. ČNI, 1996.

doc. Ing. Jiří Cendelín, CSc.,
katedra kybernetiky,
Fakulta aplikovaných věd Západočeské univerzity v Plzni
(cendelin@kky.zcu.cz)

Pozn. red.: upravenou verzi [1] připravuje redakce do tisku.

Inzerce zpět