Mezi stavem informačních technologií ve východní Evropě a v té části světa, která bývá označována jako Západ, jsou v současné době dosti značné rozdíly - především proto, že na Východě není dosud vybudováno rozsáhlejší zázemí technického vybavení, aplikací a vyškolené obsluhy. Jak si však zdůvodníme dále, je tento zdánlivý nedostatek spíše velkou příležitostí než problémem. Nabízí totiž východní Evropě jedinečnou možnost využít při zavádění informačních technologií výhod, které současný téměř nulový stav nabízí, namísto otrockého kopírování dosavadní západní cesty.
Kopírování západních postupů je ve skutečnosti pro východní Evropu naprosto nevhodné. Západ se totiž ve využívání informačních technologií dopustil řady vážných chyb, které - pokud k nim již jednou došlo - jsou v zásadě nenapravitelné. Bylo však možno (a nyní je možno) se jich předem vyvarovat. Východní Evropa má příležitost poučit se z cizích chyb a následně se jim vyhnout. Pokud neuspěje, stane se obyčejnou technologickou kolonií Západu; v opačném případě má skutečnou naději dostihnout (a snad i předběhnout) v informačních technologiích Západ, a to hned v několika důležitých oblastech.
Ilustrujme na příkladech obecnou skutečnost, že na Západě se nepodařilo vytěžit z informačních technologií to, co nabízely.
První příklad se týká zpracování bankovních šeků. V převážné většině velkých západních bank je tento proces již více než 30 let plně automatizován. I když se během této doby poměr ceny a výkonu při zpracování elektronických dat zlepšil nejméně 10.000krát, jednotková cena zpracování šeku se nijak výrazně nezměnila. Navíc je v podstatě totožná v celé rozsáhlé oblasti bank různých velikostí a v různých zemích, takže vysvětlení nelze hledat v ekonomičnosti či neekonomičnosti různých tarifů.
Druhý příklad se týká aplikací v oblasti obchodu. Za posledních 30 let se kvalita typických široce používaných obchodních aplikací nezlepšila, tj. nenastal žádný podstatný posun v rozsahu funkcí, které tyto aplikace v obchodní oblasti skutečně zajišťují, ani v efektivnosti podpory těchto funkcí prostředky zpracování dat. Přitom však ceny za vývoj aplikací postupně rostly, a to dokonce rychleji, než klesaly ceny hardwaru. To vedlo ke zvýšení výsledné ceny za aplikaci. Jak vyplyne z dalších úvah, je to vše způsobeno převážně chybami v řízení, nikoli základními technologickými nedostatky.
Třetí příklad se váže k oblasti osobních počítačů. S obrovskými náklady se během posledního desetiletí instalovalo velké množství osobních počítačů - jak v oblasti obchodu, tak ve státní správě. Měření produktivity práce lidí v součinnosti s technickým vybavením (alespoň v tom rozsahu, jak je takové měření vůbec možné) jasně ukázalo, že masové nasazení osobní výpočetní techniky má na produktivitu záporný vliv. Byly vynaloženy ohromné prostředky, aby se celková výkonnost snížila.
Čtvrtý příklad se týká metod používaných při vývoji programů. Velmi výkonné metody (ve srovnání s těmi, které se běžně používají) jsou známy již přes 40 let. Více než 15 let je zřejmé, že se jejich používáním snižují výsledné ceny. Přesto se tyto metody dosud nerozšířily a existují různé důvody, proč se pravděpodobně ani nikdy nerozšíří.
Základní příčiny výše uvedených (a mnoha podobných) jevů nemají technický charakter, ale jsou v oblasti řízení. Sice víme, jak dělat věci lépe, ale odmítáme je tak dělat. Nedostatky v řízení lze rozdělit do čtyř skupin, říkejme jim pasti. Jsou to pasti z
O pastech mluvíme proto, že jakmile se v nich octneme, je únik v podstatě nemožný. Můžeme se jim však vyhnout.
Ve své podstatě jsou tyto čtyři pasti příklady zásadního odmítání existujících technologií. Všechny vyplývají ze zmatku mezi argumenty trhu a realitou.
Než začneme rozebírat povahu jednotlivých pastí a způsoby, jak se jim nejlépe vyhnout, může být poučný pohled na dvě historické analogie.
V Americe se v r. 1910 odhadovalo, že do r. 1940 bude nutno zaměstnat všechny dospělé ženy jako telefonní operátorky, aby bylo možno zvládnout očekávaný nárůst telefonního systému. I když pak rostla telefonní síť dokonce rychleji, než se odhadovalo, předpokládaný důsledek se ukázal jako mylný.
V r. 1820 se ze stávajícího růstu dopravního provozu v centru Londýna odhadovalo, že do r. 1950 budou všechny ulice pohřbeny pod sedmimetrovou vrstvou koňského trusu. Ve skutečnosti se pak londýnská doprava rozrůstala ještě rychleji, než se původně očekávalo.
Zmíněné problémy se nevyřešily nějakým (ať už okrajovým či zásadním) vylepšením existujících metod. Vyřešily se tím, že prostě nenastaly. Jinými slovy, cílem úsilí vypořádat se s problémem uvedeného typu není zlepšit metody odstraňování koňského trusu; cílem je v první řadě nalézt způsob, jak se koňskému trusu úplně vyhnout. Naneštěstí spadnout do některé ze zmíněných čtyř pastí (jak se to na Západě ve velkém měřítku stalo) znamená nejen zvýšenou produkci koňského trusu, ale i selhání všech způsobů, jak jej odstranit.
Zaměřme se na povahu a příčiny každé z uvedených pastí a preventivní opatření proti ní. Vzhledem k rozsahu článku si nemůžeme dovolit vyčerpávající diskusi, proč přesně tyto problémy vznikají a proč jsou uvedené způsoby prevence účinné, přestože jde o známé skutečnosti: snad i stručná informace bude čtenáře motivovat, aby v naznačených úvahách pokračovali.
Všeobecně se soudí, že údržba pohlcuje 30 až 80% typického softwarového rozpočtu. Tato čísla jsou však dosti matoucí. Uvážíme-li, co vše se zahrnuje pod pojem údržba, rozlišíme nejméně pět různých kategorií.
V prvé řadě jde o reálnou údržbu, jíž je odstraňování nedostatků softwaru s cílem dosáhnout té funkčnosti, která byla původně zamýšlena. Toto mívají lidé na mysli, když se řekne "údržba", ve skutečnosti však jde o poměrně malou část toho, co do oblasti údržby celkově spadá. Z historického pohledu se obecné úsilí "zlepšit údržbu" zaměřuje převážně na tento její aspekt.
Hlavní kategorií tzv. "údržby" jsou však rozšíření. Jde o dodatečné funkční požadavky, které vyplývají z procesu vývoje, nikoli z chyb v původní specifikaci či implementaci. Rozsah těchto rozšíření se úzce váže k nedostatečné rychlosti implementace: u mnoha organizací je rychlost změn požadavků na systém vyšší než rychlost, jakou je systém implementován; výsledkem je, že neustále zaostávají.
Třetí kategorií údržby, která se příliš neliší od předchozí, je uspokojování nových požadavků. Běžně se v tomto případě mluví o údržbě z administrativních důvodů, protože vyčlenit v rozpočtech prostředky na údržbu je mnohem snazší, než vyčlenit prostředky na další rozvoj. Snaha zredukovat tyto dvě kategorie údržby se v běžné praxi v podstatě nevyskytuje.
Čtvrtou kategorií údržby je indukovaná údržba, kterou si vynucují problémy s kompatibilitou nových verzí softwaru, tak jak jsou výrobci postupně uvolňovány na trh. V některých případech se takto pohltí až polovina celkového rozpočtu vyčleněného na údržbu, bez ohledu na to, že uživatelům nepřináší vlastně žádný užitek. Je to typický příklad situací, kdy uživatelé platí nesmírné sumy za položky, jež jsou pro ně bezcenné.
Pátá kategorie, nazývaná sekundární údržba, se podobá indukované údržbě. Příčinou je úsilí přizpůsobit se různým "standardům", které přijímají výrobci softwaru nebo organizace, které vlivu výrobců do značné míry podléhají. Ani v tomto případě nevyplývají pro uživatele žádné výhody - na rozdíl od značných výhod pro dodavatele. Ovšem proč by to neměli být právě uživatelé, kdo budou nakonec platit?
Problém nadměrných nákladů na údržbu je samozřejmě reálný. Nejrůznější nabízená zázračná "řešení" jsou samozřejmě k ničemu. Ve skutečnosti jsou i horší než "k ničemu", protože nejenže neřeší problém, ale dokonce jej ještě zhoršují.
Nejabsurdnějším ze všech řešení k ničemu je prosazování myšlenky znovupoužití jednotlivých softwarových modulů. Smysluplné znovupoužití nějakého softwarového modulu by totiž kromě jiného vyžadovalo, aby bylo úplně známo a zdokumentováno jeho chování (včetně aspektů, které v době, kdy tento software vznikal, nikdo nepředvídal, protože se netýkaly původního účelu). Protože nevíme, jak porozumět chování na úrovni modulu (a jak je vhodně popsat) ani v jednoduchých případech, je absurdní předpokládat, že je možno efektivně zvládnout zcela obecný případ.
Další skupina řešení k ničemu souvisí s aplikací strukturované analýzy a návrhu, třeba i v součinnosti s prostředky CASE (Computer-Aided Software Engineering). Nejde tu o nic jiného než o pokus nahradit tvořivou práci byrokracií. Metody tohoto typu spolehlivě zajišťují, že náklady porostou: ani v nejmenším nezlepšují rychlost či efektivitu návrhu a implementace, zato však garantují širokou papírovou stopu, kterou může sledovat naprosto kdokoli s odvoláním, že dodržuje správný postup. Za případný neúspěch není nikdo zodpovědný, protože všichni postupovali podle pravidel.
Třetí skupina řešení k ničemu spočívá v orientaci na stále vyšší úroveň jazyků a generátorů kódu, která jde často ruku v ruce s tím, že programování se namísto profesionálů ujímají koncoví uživatelé. Opět skvělá metoda, jak nejen zvýšit ceny, ale i přeměnit zjevné (viditelné) ceny na ceny skryté. Zúžení údajů o řešeném problému, které nevyhnutelně vyplývá z aplikace jazyků a generátorů kódu vyšší úrovně, dále úspěšně snižuje soulad mezi vyvíjeným systémem a požadavky uživatelů. Problémy však naštěstí vznikají pouze uživatelům, nikoli dodavatelům. Navíc díky tomu, že uživatelé ve svých požadavcích často nedoceňují problémy při zpracování dat, bývají jejich požadavky na údržbu rovněž omezené. Všichni jsou spokojeni - s výjimkou těch, kdo zpracování dat skutečně potřebují. Těm se sdělí, že si mohou své požadavky naprogramovat sami (coby koncoví uživatelé), čímž vznikne ona absurdní situace, kdy draze placený odborník v určité oblasti tráví svůj čas jako amatérský (a často nekompetentní) programátor. Protože výdaje tohoto druhu jsou zároveň relativně skryté, jsou opět všichni spokojeni - až na ty, kdo počítačové zpracování dat skutečně potřebují.
Poslední kategorií řešení k ničemu je respektování standardů a důraz na "kvalitu". To je skutečně úžasný mechanismus. V jádru spočívá v přejmenování nějakého aspektu problému (sekundární údržba) tak, že jej lze považovat za řešení. Pochopitelně: nic se nemění, ale té rétoriky!
Obecně platí, že údržbu nelze nikdy zlepšit; lze pouze snížit její rozsah (ve skutečnosti dokonce podstatně). Stačí se jen řídit několika základními principy a problém se zredukuje do přijatelných rozměrů.
Prvořadý je důraz na opatření, která v reálných podmínkách zvyšují produktivitu programátora. (Dostupné technologie umožňují zlepšení přibližně o dva řády ve srovnání s typickou praxí.) To přímo ovlivní dobu vyhraženou pro vývoj nového softwaru, a tudíž i nevyřešené problémy údržby. Při rozšiřování systémů se tímto přístupem podpoří spíše vyvíjení nového než modifikace existujícího, což povede k jasnému odlišení nových funkcí od oprav.
Indukovaná a sekundární údržba by měly být jednoduše vyloučeny nařízením shora. Podobně by mělo být nekompromisně vyloučeno jakékoli zbytečné zobecňování předloženého problému. Zkušenosti ukazují, že pokusy předpovídat budoucnost jsou spolehlivě chybné; nejlepší radou je řešit předložený problém a neplýtvat zdroji na dalších problémech, které mohou, ale nemusí v budoucnu vyvstat.
Za nejrozumnější přístup lze označit "havarijní" ("crash") projekt. Jinými slovy: projekt, který má být dokončen v nejkratším možném čase. Nedostatky spojené s tímto přístupem budou více než kompenzovány skutečností, že zpracování dat bude k dispozici tehdy, kdy je uživatelé potřebují, a že systém bude vyvinut dříve, než se změní úvodní požadavky. Navíc se tímto způsobem celkem snadno omezí byrokratické přístupy k řízení zpracování dat, protože se jasně projeví jako příčiny zpoždění.
Téměř veškerý současný vývoj softwaru si vyžaduje značné nasazení pracovních sil. Převládají tendence k postupnému snižování úrovně dovednosti, což má za následek početní růst programátorských týmů; mezi těmito dvěma jevy je ale trvale pozitivní zpětná vazba. Další aspekty pozitivní zpětné vazby se vytvářejí zaváděním pracných postupů a "standardů", pokusy o "mikrořízení" vývoje softwaru a zahlcováním zdrojů, které jsou pro vývoj softwaru k dispozici. Výsledkem je situace, která se s postupujícím časem stále zhoršuje.
Pokračovat v současném postupu je opět zjevným řešením k ničenu, přestože to mnozí lidé považují za nevyhnutelné. Dokonce se objevují předpovědi, že za pár let se bude polovina veškeré pracovní síly věnovat programování. Připomeňme si na tomto místě ony dvě historické analogie.
Často je prosazován názor, že řešením je lepší vyškolení lidí, ať již vnitrofiremní či formou praktičtěji orientované výuky na vysokých školách. Tento přístup však nikdy nemůže fungovat. Problémem totiž nejsou nedostatky ve vyškolení, ale zaměstnávání nezvládnutelného množství relativně málo schopných jedinců. V žádném případě nelze očekávat, že se schopnost programovat projeví u obrovského počtu jednotlivců. Jakékoli řešení, které tuto skutečnost nerespektuje, je opět řešením k ničemu.
Jiným často prosazovaným řešením k ničemu je snaha nahradit vývoj vlastních programů použitím již existujících softwarových produktů. Jinými slovy: uživatelům se doporučuje, aby nevyžadovali to, co vyhovuje jejich potřebám, ale aby se raději spokojili s čímsi, co vyhovuje potřebám někoho jiného. Značnému počtu těchto uživatelů by bylo lépe bez počítačové podpory; v mnoha jiných případech je třeba existující software modifikovat, což obecně stojí více, než začít vlastní vývoj od nuly.
Jakmile se přišlo na to, že tady jde především o problém v řízení, začaly se vynalézat různé způsoby, jak proces vývoje softwaru automatizovat; stále se však počítá s masovým nasazením relativně málo schopných jedinců. Je samozřejmě směšné hloubat nad úlohou, jak automatizovat něco, co neumíme dělat ani ručně. Obranou bývá tvrzení, že řízení vývoje softwaru již manuálně zvládnuto je: stačí jen respektovat obsažnou sadu standardů a postupů, abychom měli zajištěno, že jdeme nejlepší možnou cestou. Pokud snad takto vytvořené projekty neuspějí, lze jednoznačně vyvodit, že byly neřešitelné a že uživatelské požadavky byly nereálné.
Reálná řešení i v tomto případě existují. Jejich základním koncepčním prvkem je uvědomit si, že vývoj softwaru není a nikdy nebude průmyslovou činností. Analogie s průmyslovou výrobou selhávají a tzv. "softwarová továrna" je chybnou cestou, ať už si Japonci říkají, co chtějí. Jedinou platnou analogii lze najít v řemeslech a povoláních.
Z letitých zkušeností v oblasti řemesel a svobodných povolání přímo vyplývá, že intenzívní nasazování pracovních sil má být při vývoji softwaru vyloučeno. Především je třeba zaměstnat malý počet velmi schopných a motivovaných lidí namísto armády neschopných. Těm je pak třeba poskytnout nejlepší možné pracovní podmínky; účelem totiž je efektivně vyvíjet software, nikoli plně využít vybavení, jež je pro vývoj k dispozici.
Je třeba využívat lidi již vyškolené, a to s větším důrazem na teorii než na detaily současné praxe. Takoví lidé jsou schopni rychle se seznámit s novým strojem či jazykem, dokonce i s novými aplikacemi; nedostatečně teoreticky vyškolení lidé většinou záhy zaostávají a jen zřídka jsou schopni naučit se rychle přijímat nové věci.
Při návrhu systémů je třeba respektovat stanovené požadavky a nesnažit se je modifikovat podle nějakých předem vytvořených představ o řešení. Velmi důležité také je, aby dodavatelé existujících produktů (ať už hardwarových či softwarových) neměli možnost návrh systému ovlivnit. A co je snad nejdůležitější, nemít strach udělat něco vlastního namísto pasívního převzetí cizího produktu; často je rychlejší a levnější (za předpokladu schopných spolupracovníků) udělat sami něco nového, než modifikovat již existující. Ve východní Evropě se najde dost lidí s tím pravým základním teoretickým vzděláním; je jen třeba jejich schopností správně využít.
Přirozenou reakcí na problémy spojené s vývojem programů je pokušení zcela se jim vyhnout a sáhnout po již existujícím softwaru. Z mnoha důvodů je takový postup krajně nákladný. V prvé řadě je třeba si uvědomit, že přibližně 80% ceny typických softwarových produktů připadá na distribuci, nikoli na software samotný. Navíc značná část zbývajících 20% ceny nemá nic společného se skutečnými potřebami konkrétní uživatelské organizace.
Hotové programové balíky většinou jen slabě odpovídají požadavkům uživatele a systému organizace, z čehož vyplývají velmi vysoké skryté náklady a/nebo extrémně nákladné modifikace. Tento jev, spojený s přílišnou (ačkoli často nepatřičnou) obecností softwarových produktů, se projevuje v potřebě zbytečně nákladného technického vybavení (často o řád) a mívá za následek téměř úplnou závislost organizace na vnějších zdrojích.
Tak jako v případech ostatních pastí, i tady se nabízí celá řada řešení k ničemu. Ta nejčastěji propagovaná spočívají v "lepší" analýze uživatelských požadavků a nabízených produktů. V tomto kontextu je slovem lepší obvykle míněna podrobnější dokumentace. Protože obecně platí, že žádný z nabízených produktů neodpovídá požadavkům uživatele, je toto řešení lepší pouze v byrokratickém smyslu. Výsledkem obvykle bývá rozsáhlá přehlídka toho, jak se postupně modifikovaly uživatelské požadavky, aby se přizpůsobily nabízeným produktům. Skutečné uživatelské požadavky se samozřejmě nemění a zůstávají nesplněny.
Častou odpovědí dodavatelů je, že uživatelé a jejich týmy, zabývající se zpracováním dat, nabízeným produktům nerozumějí; tudíž je zapotřebí poskytnout rozsáhlejší školení. Dodatečná školení vedou v nejlepším případě k tomu, že zúčastnění dodanému softwaru porozumějí; to ovšem ani zdaleka neznamená, že uživatelské požadavky jsou uspokojeny - pouze se mění téma rozprav. Častým výsledkem je, že se dodavatelé a tým lidí kolem zpracování dat spojí ve snaze přesvědčit uživatele, že nerozumí svým vlastním potřebám.
Samozřejmě lze vždy hotový produkt modifikovat, ať už vlastními silami nebo za pomoci dodavatele. Dodavatelé si pak začnou uvědomovat obtížnost takových modifikací, takže mají snahu přesvědčovat uživatele, že požadované změny je třeba provádět přímo u něj. Odtud vyplývá nekonečný sled pokusů přizpůsobit se novým verzím dodaného softwaru, končící po několika letech neúspěchem.
Některé uživatelské organizace, které si uvědomily, že vlastní vývoj je zdlouhavý a drahý, se pokoušejí získat vynaložené prostředky zpět, a to tím, že se snaží uplatnit vyvíjený výrobek i na externím trhu (v protikladu ke snaze uspokojit pouze požadavky svých vlastních uživatelů). Představa, že organizace, která má problémy s uspokojením určité množiny požadavků (svých vlastních uživatelů), je schopna efektivně uspokojit mnohem větší a hůře definovanou množinu požadavků, je dosti absurdní. Navíc je poměrně zřejmé, že i kdyby toho byla schopna, nebyl by to její přednostní zájem.
Důvody jsou v účelnosti počítačové aplikace. Počítačová aplikace by měla být vyvíjena pouze tehdy, vyplývají-li z ní konkurenční výhody pro tu organizaci, která ji používá. Nemá smysl poskytovat konkurentům stejnou výhodu za cenu nižší, než byly plné náklady na vývoj aplikace. A taková cena jistě nebude příliš lákavá.
Posledním a nejobvyklejším případem je, že organizace změní své vlastní obchodní postupy, aby se přizpůsobila zakoupenému softwarovému produktu. Tento absurdní případ nemá smysl dále rozebírat.
Zkrátka: hotové programové balíky jen zřídka šetří čas či peníze. Dovedou však převádět jasně viditelné náklady na méně viditelné náklady. To, že se náklady stávají méně viditelnými, však nesmí být zaměňováno se snižováním nákladů, přestože k tomu svádí známá skutečnost, že méně viditelné náklady se obtížněji sledují a ovlivňují.
Základním způsobem, jak se vyhnout pasti z hotových výrobků, je nebát se vlastního vývoje. Vývoj může být interní i externí, ale pouze lidé, kteří jsou "uvnitř", skutečně vědí, co potřebují (i když jim konzultanti mohou pomoci jejich potřeby více osvětlit). Rozhodneme-li se pro vlastní vývoj, měli bychom používat jen efektivní prostředky a nesnažit se kompenzovat své náklady tím, že bychom výsledky vývoje začali prodávat. Není-li projekt ekonomicky zdůvodnitelný v rámci organizace, neměl by být vůbec realizován.
Ze všeho nejdůležitější však je, abychom nikdy neplatili za něco, co ve skutečnosti nepotřebujeme, a abychom se nesnažili přizpůsobovat zaběhnuté praxi. Kdo sleduje stádo ovcí, skončí na porážce.
Do pasti z unáhlených řešení spadneme, jestliže u principiálních problémů trváme na rychlých řešeních. Vždy je snadné prohlásit, že nemáme dostatek času, abychom mohli určitý problém úplně vyřešit, takže je třeba pokusit se o taková řešení, třeba i částečná, která lze implementovat rychle. Totéž se dá říci třeba i takto: "Nikdy není dost času dělat věci pořádně, ale vždy je možnost udělat je znovu."
Takováto příliš rychlá řešení téměř nikdy nefungují. Většinou jsou spíš kosmetická a nejdou k jádru problému. Pochopitelně právě proto bývají tak atraktivní. Rychlá řešení se všem zamlouvají, protože nikdo nemusí dělat zásadní změny. Je však jasné, že pokud nikdo nic nezmění, nezmění se ani problém.
Řešení k ničemu se u tohoto typu pasti vyskytují vskutku hojně. Předními mezi nimi jsou reorganizace a joint ventures, případně spojené s nákupem nových technologií. Je dost nepochopitelné, že tyto aktivity, jejichž zvládnutí patří k těm nejobtížnějším, jsou voleny jako řešení problému, který je především z oblasti řízení. Ve skutečnosti jsou atraktivní právě proto, že se nedotýkají problému samotného, ale přenášejí pozornost jinam.
Samozřejmě i zde se objevují všechna řešení k ničenu, na něž jsme narazili u ostatních pastí (např. hotové softwarové produkty, metody, standardy, kvalita). Žádné z nich není v případě příliš rychlých řešení o nic úspěšnější než v předchozích případech.
Kritickým hlediskem je, že závažné problémy mají obecně strukturální, nikoli povrchní charakter. V tomto kontextu se strukturou nemíní čáry v organizačním schématu, ale základní přístup organizace k její činnosti. Rychlá řešení nikdy nemohou zvládnout strukturální problémy; mohou však problémy přejmenovat nebo dočasně zastřít jejich povahu.
Jedinou možnou obranou před touto pastí je odolat pokušení sáhnout po nějakém příliš rychlém řešení a přitom si zachovat přesvědčení, že každý projekt je třeba realizovat co nejrychleji. Je třeba zvážit celý problém, včetně všech kroků, které bude operativní řešení vyžadovat, a přitom nepřipustit, aby rozhodovací proces uvázl z důvodu přehnaných rozborů různých alternativ; dost často se stává, že všechny schůdné alternativy jsou víceméně stejně efektivní a víceméně stejně nepříjemné, pokud jde o ospravedlňování předchozích akcí.
Nesmíme nikdy zapomínat na to, že evoluční rozmístění (ať už systémů či organizační struktury) lze zprovoznit, avšak evoluční projekt nebude fungovat nikdy. Není možné udělat první krok směrem k nějakému cíli, pokud nemáme jasnou představu, co tím cílem je.
Výše uvedené názory jsou v kontextu zpracování dat zcela nekonvenční. Přesto však platí právě ony a nic jiného. Naneštěstí rozsah tohoto článku dovoluje pouze nástin toho, jak vypadají řešení. Není tu prostor vysvětlit, jak tato řešení implementovat a čím to je, že jsou úspěšná. Zdůvodnění však existují a lze o nich diskutovat.
Je třeba zapamatovat si tyto čtyři klíčové body:
(Přeložila Jana Kohoutková,
ilustroval Jiří Franek)
předchozí článek
