Jak přežít

Kdyby existoval klub zlomených srdcí v oboru vývoje aplikací, Jeff Meyer by byl jedním z jeho předních členů. Jeho po...


Kdyby existoval klub zlomených srdcí v oboru vývoje aplikací, Jeff Meyer by byl
jedním z jeho předních členů. Jeho poslední neúspěch byl zatím nejhorší. Šlo o
on-line aplikaci pod názvem Group Paperless, která by umožnila institucionálním
zákazníkům Meyerovy firmy, Blue Cross and Blue Shield of Rhode Island (BCBS)
provádět změny v informacích o jejich zaměstnancích (jako například o počtu
rodinných příslušníků) prostřednictvím webového browseru.

Firemní oddělení systémů vyhrálo zakázku na tento projekt ve veřejné soutěži
před několika lety a uspělo tak u cizích vývojářských firem. Asi po šesti
měsících usilovné práce však v BCBS nastaly těžké časy a projekt byl stornován.
"A tohle se děje pořád," lamentuje Meyer, který je ředitelem strategického
vývoje v jedné pojišťovací firmě v Providence. "Group Paperless byla považována
za strategickou záležitost, jejíž návratnost není jasně vyčíslena. Naši
zákazníci se sami aktivně dožadovali přístupu ke svým účtům přes Internet, ale
my jsme jim nemohli říct, že to ve výsledku ušetří takovou a takovou částku, a
tak to všechno šlo do kanálu."

Není to jen v penězích

Peníze nejsou jediným faktorem, který v současné době omezuje vývoj firemních
aplikací. Tom Beegle, zástupce generálního manažera skupiny MIS/Aplikačních
systémů ve společnosti Matsushita Electric of America ve státě New Jersey
najednou zjistil, že soupeří o přízeň své vlastní firmy s německým cizincem
jménem SAP, výkonnou aplikací, která automatizuje podnikové procesy což byl po
celá léta výhradní úkol firemních vývojářů která má navíc výhodu podpory stovek
softwarových vývojářů, kteří každých pár měsíců k programu přidávají další
funkce a schopnosti. Matsushita právě instaluje R/3 firmy SAP, univerzální
podnikovou aplikaci klient/server, která automatizuje klíčové podnikové procesy
společnosti. Až začne v hlavním sídle Matsushity koncem tohoto roku naplno
fungovat finanční modul R/3, a jestli celkový vývoj bude v příštích několika
letech pokračovat jako dosud, valná část práce v oblasti vývoje aplikací,
kterou Beegle a jeho skupina prováděli, se stane zbytečnou. Teď musí změnit
pracovní náplň skupiny z vytváření aplikací na jiné úkoly, jinak jeho lidé
nebudou mít co dělat. Ačkoliv zvažuje řadu možností, otevřeně přiznává, že si
zatím není jist, jaké "jiné úkoly" to nakonec budou.

Je důvod k panice?

Řada dalších firemních skupin pro vývoj aplikací přemýšlí o tomtéž. I když
zprávy ohlašující smrt podnikového vývoje aplikací se čas od času objevují už
asi 40 let a zatím se vždy ukázaly jako předčasné, nyní jsou tady jasné důkazy,
že možnosti pro skupiny firemních vývojářů klesají. Průzkum společnosti Cutter
Information Corp. z Arlingtonu z roku 1998 například zjistil, že výdaje na
vývoj nových aplikací, vyjádřené jako procento celkového rozpočtu firem na IT,
klesly od roku 1997 asi o 34 %, ale výdaje na balíky softwarových instalací se
zdvojnásobily. S tím, jak se šíří softwarové balíky, podnikoví vývojáři
ztrácejí schopnost udržet krok s nejnovějšími technologiemi a programovacími
jazyky. Nástup prodejců, "outsourcingu" a konzultantů s podrobnými,
specifickými technickými znalostmi začal omezovat schopnost podnikových
vývojářských skupin fungovat jako dodavatelé aplikací pro vlastní firmy. Dnešní
podnikové skupiny pro vývoj aplikací si musí být vědomy svých silných a slabých
stránek, a co je nejdůležitější, své schopnosti dodat to, co slibují, protože
konkurence zvnějšku je tvrdá a vnitřní zdroje jsou napjatější než kdy jindy.
A co je ještě horší, domácí skupiny jsou v nevýhodě už proto, že jsou domácí.
Prodejci a poradenské firmy v oblasti softwaru žijí a umírají s aplikacemi,
které vytvářejí a instalují. budou vždycky rychlejší a levnější a budou mít
větší skupinu zákazníků, pro které pracují a také se od nich učí, než podnikové
skupiny. Podnikové týmy, které se pokoušejí s těmito vetřelci otevřeně
soupeřit, budou odsouzeny k zániku a vyhubeny.

Jak dál?

Tyto podnikové skupiny, pokud chtějí přežít, se musejí vydat tam, kde nejsou ti
druzí. Podnikoví vývojáři přesouvají pozornost na řízení projektů, jako je
například dohled na integrátory a softwarové balíky, které instalují. Stávají
se z nich také softwarové opravárny, které doplňují mezery v balíkových
softwarových aplikacích a integrují různé balíky softwaru tak, aby vyhovovaly
specifickým potřebám jejich firmy. "Úkolem podnikových vývojářů již nebude
vývoj aplikací v tradičním monolitním smyslu. Budou vytvářet systémy aplikací,
které budou spolupracovat," předpovídá Rob Veitch, ředitel podnikového vývoje,
aplikačních serverů a nástrojů pro divizi internetových aplikací z kalifornské
společnosti Sybase, majitele PowerBuilderu, populárního nástroje pro vývoj
aplikací.
V dnešní době, kdy potřeba určitého aplikačního "tmelu" začíná převyšovat
potřebu nových aplikací, pozvedávají úspěšné podnikové skupiny pro vývoj
aplikací oportunismus na úroveň umění. "Musíte najít místo, kde má byznys
trhliny, které nemůže spravit ani prodejce, ani integrátor," říká Mike
Gurevich, výkonný ředitel pro technologii a viceprezident vývoje společnosti
Concorde Solutions Inc. (CSI), pobočky Bank of America, banky, která vznikla
loni v říjnu fúzí BankAmerica Corp.(BA) a NationsBank Corp. CSI. Bank of
America navázala na práci vnitropodnikového vývoje aplikací BankAmerica, která
byla vytvořena v roce 1995, aby vyřešila jeden obrovský problém: propojení
nových aplikací a starých informací. Oddělení IT v BankAmerica marnilo nesčetné
hodiny budováním a udržováním jednotlivých linků mezi novými a starými
aplikacemi, novými databázemi a starými databázemi, novými počítačovými jazyky
a starými počítačovými jazyky. Nebyl čas ani potřebné zkušenosti k vytvoření
celkové technologie, díky níž by tento proces integrace byl rychlý a kdykoliv
zopakovatelný. Proto se BA rozhodla vytvořit svou vlastní verzi zárodku Silicon
Valley malou skupinu bystrých lidí ochotných pracovat dlouhé hodiny za podíl na
společnosti a na produktu samém.
"CSI začala ze dvou důvodů: abychom získali lidi a abychom si je udrželi," říká
Gurevich. Lidi, kteří by znali nejnovější, nejaktuálnější technologie a byli by
ochotni vraždit, jen aby s nimi mohli pracovat. Tento typ znalostí a vášně v BA
neexistoval, a přeškolováním firemních vývojářů na nové technologie by se toho
nedosáhlo, dodává. "Je riziko spoléhat na to, že stávající personál bude
schopen takovéhoto průlomu. Lidé, kteří mají své pohodlí a slušný plat proč by
pracovali 16 hodin denně? Proč by se ničili? Ale tohle chce kreativní tenzi,
cíl, o který je nutno usilovat, a odměnu za jeho dosažení." Tato strategie se
podle všeho vyplatila: Gurevich alespoň tvrdí, že za tři roky CSI neopustil
jediný programátor a počet lidí přitom vzrostl ze 4 na 50.

Skupina vytvořila řadu objektově-orientovaných aplikací určených k tomu, aby
dokázaly "lovit" data v množství aplikačních systémů BA a dodávat je bankéřům
do desktopů. Omezení času a složitosti integrace aplikací dává vývojářům výhodu
před konkurencí: rychlost a výkonnost. "Pracujeme na aplikaci, kterou chceme
propojit se 14 různými odkazovými systémy" říká Sukan Makmuri, viceprezident
pro internetovou bankovní technologii u BA. "Kdybych s tím začínal úplně od
začátku, musel bych nasadit 14 programátorů, aby propojili každý z těchto
systémů." Místo toho mohou jeho programátoři použít aplikací CSI, aby z těchto
systémů dostali data, která potřebují.

Vytvoření soustředěné, nadšené skupiny `a la CSI ve firemním oddělení IT by
bylo bývalo velice těžké, říká Gurevich. "Musíte vytvořit prostředí, v němž
vaši vývojáři budou neustále motivováni a budou před sebou mít vždy nějakou
technickou výzvu, na které mohou pracovat," říká. "Pokud nastane hluché období,
kdy společnost nepracuje na nových věcech, můžete o ty lidi snadno přijít." A
nebuďte překvapeni, když vztahy mezi touto novou skupinou a zbytkem oddělení IT
začnou být maličko napjaté. "Na jedné straně jsou oddělení IT, která pracují
klasickým způsobem, a tady máte najednou tohle velice agresívní oddělení, které
se neustále ohlíží po té nejnovější, nejzajímavější práci to by mohla být
nebezpečná sestava, pokud by se to neudělalo správným způsobem," varuje
Gurevich. "Mezi těmito skupinami může existovat tvůrčí napětí nebo jenom
obyčejné napětí. Úkolem je vytvořit mezi složkami IT v organizaci dobré a
přátelské prostředí, kde tato zvláštní skupina není považována za elitářskou a
lidé z firmy mají možnost se stát jejími členy, pokud mají požadovanou
kvalifikaci.

Udržet limity

Nejnebezpečnější stránkou čistě vývojové skupiny v rámci společnosti je ale
tendence k experimentování, riziko sklouznutí výzkumu a vývoje k nepodstatnému.
Právě toto trvalé napětí mezi současnými potřebami a experimentováním přispívá
k náhlým koncům aplikací jako byla Group Paperless v BCBS. "Technologie se pro
nás stala problémem, namísto aby nás problémů zbavovala," říká Bill Boffi,
tamní viceprezident pro informační technologie a CIO. "Ve vývoji aplikací se
techniky a nástroje mění tak rychle, že moje organizace prostě nestíhá udržet
krok." Boffi a Meyer se snaží snížit zranitelnost strategického vývoje snížením
očekávání jak co do nákladů, tak co do funkčnosti aplikací. Podle jejich nového
plánu bude veškerá práce, týkající se strategického vývoje, korigována
grantovým procesem, který bude řídit nové podnikové Středisko pro strategický
vývoj (jehož jediným zaměstnancem je teď Meyer). Každý projekt bude mít přísné
limity pokud jde o náklady, přesně definovaný časový rámec a seznam základních
funkčních předpokladů, kterých má být dosaženo. To by mělo zamezit překračování
rozpočtu a nedostatečné zaměření na účelnost v dobách hojnosti a zabránit
předčasným koncům, jakmile naopak nastane čas utahování opasků. Tyto granty,
podobně jako konzultační smlouvy za předem stanovený honorář, které jsou
nejnovějším výkřikem v projektech systémové integrace, kladou důraz na rychlost
a splnění účelu oproti zbytečným "výmyslům".

Boffi doufá, že snížením výdajů a očekávání ve vztahu ke strategickému vývoji
se konečně vyhrabe z "černé díry byrokracie", která byla mlýnským kamenem na
krku strategického vývoje v BCBS. "Vynakládali jsme spousty peněz na první
pokusy a aplikace pak byly zcela náhodně úspěšné nebo žalostně selhávaly,"
říká. Nový grantový proces vyžaduje, aby se vývoj zaměřil na jeden konkrétní
problém a nesnažil se vyřešit všechny. "Dobrá zpráva je, že si nebudu muset
lámat hlavu s tím, jestli obrazovka bude modrá nebo červená prostě jde o to,
aby fungovala," říká Meyer. Jestliže se skupině podnikových zkušebních
odborníků bude líbit to, co jim bude předvedeno jako zcela funkční výrobní
prototyp, Boffi a Meyer předají aplikaci systémové skupině BCBS, která má asi
90 pracovníků, k dalšímu vývoji. Zatím poslední zpráva je, že Group Paperless
bude možná oprášena a zařazena opět do programu.

Světlo naděje

Plán BCBS vztyčuje vlajku, kterou by většina podnikových vývojářů a analytiků
ráda viděla vlát co nejvýše: žádný poradce nebo prodejce zvenčí nezná podnikové
procesy, které daný podnik odlišují od konkurentů, lépe než vlastní pracovníci
IT. Konzultanti a prodejci softwaru se věcí nezabývají dostatečně dlouho, aby
takového znalosti získali, a musejí své produkty zobecňovat tak, aby je mohli
prodávat široké klientele. "Argumentoval bych tím, že tyto klíčové funkce by
nikdy neměly být zadávány ven nebo nakupovány jako hotový balík," říká Meyer.
"Jakmile to začnete dělat, ztratíte svou jedinečnou identitu a to, co vás
odlišuje od vaší konkurence."
Právě to výrobci Matsushita a ostatní vždycky říkali o procesech, jako je
kontrola inventáře, hospodaření s hmotnými prostředky a řízení dodavatelského
řetězce tedy alespoň do doby, než je ambiciózní prodejci softwaru jako SAP
začali začleňovat do prefabrikovaných softwarových balíků. To přinutilo
viceprezidenta a generálního manažera MIS Matsushity Boba Schwartze přehodnotit
roli podnikového vývoje aplikací. "Naši společnost tlačí čas," říká. Vrcholový
management Matsushity chce informace o všech nejrůznějších stránkách podnikové
činnosti, které je třeba integrovat a dodávat téměř v reálném čase. To do
značné míry odsoudilo většinu starých firemních mainframových systémů, které
spolu navzájem (a s podnikem) komunikovaly prostřednictvím dávkového předávání
informací v nočních hodinách. Schwartz nechtěl tento problém řešit se svými
podnikovými vývojáři, protože prodejci to už udělali za ně. Ale i když se v
americké centrále Matsushity instaluje SAP, pro příští generaci rozlišovacích
procesů komunikaci se zákazníky a dodavateli, řízení toku materiálů ve výrobním
procesu je tady množství menších prodejců softwaru, kteří už jen dokončují
poslední úhledné mašličky na balíčcích, a většina těchto balíčků je
kompatibilní s velkými softwarovými balíky ERP jako je SAP. "Během příštích
několika let se budeme zabývat výhradně už jen balíky," říká Beegle. "I naše
logistika bude řízena balíkem. A my budeme řešit otázku: co bude s námi?"

Konec jedné éry

Zatím je jasné jen to, co s nimi nebude. "Tradiční role programátora jde
stranou, když se podíváte na kteroukoliv prefabrikovanou aplikaci, zejména z
hlediska integrace," říká Schwartz. Aplikace už nevytváříte, jen je dolaďujete.
"To, jak konfigurujete ten balík, rozhoduje o tom, jakým způsobem bude
prováděna určitá funkce, jako třeba finance. Takže člověk pracující v IT musí
rozumět té podnikové funkci nebo toku, který se automatizuje, aby mohl
dosáhnout požadovaného výsledku. Podnikové procesy probíhají naprosto
bezprobémovým způsobem, jestliže různé softwarové balíky, které je podporují,
jsou sladěny tak, aby spolu dobře fungovaly. "Čili jejich kvalifikace nebude
spočívat jen ve znalosti určitého balíku, ale bude se týkat toho, jak
implementovat prefabrikovaná řešení."
Někteří programátoři Matsushity budou podporovat zbývající mainframové systémy
nebo se budou muset naučit, jak obsluhovat nové balíky. Jiní budou přeškoleni
na vývoj v oblasti Webu, se kterým firma začíná. A další zase absolvují mnohem
dramatičtější přechod od programování k řízení projektů. To pro lidi z IT bude
nejnáročnější posun a bude možná příliš obtížný pro ty, kteří nemají předchozí
zkušenosti nebo nemají dostatečný zájem. "Tohle není něco, co se můžete naučit
v nějakém kurzu," říká Schwartz. "Kvalitní projektoví manažeři museli vynaložit
velké úsilí a obrousili si zuby na tom, jak se postupně učili jednotlivé kroky
pozitivní i negativní procesu řízení projektu.

Tito noví projektoví manažeři budou závislejší na pomoci zvenčí, dodává Beegle.
"Potřebujeme přejít od řízení lidí v softwarovém vývoji a technologii k řízení
lidí v podnikové sféře, prodejců a konzultantů zvenčí," říká. "V řízení
projektů budou mít daleko větší význam smluvní otázky, protože budeme mít co do
činění s více cizími lidmi." Projektoví manažeři se budou muset stát
vyjednavači a pacifikátory velkých výrobců softwaru a hardwaru.
Budou také muset z oněch "cizích lidí" vysávat informace pro použití ve
vlastních skupinách. Poločas rozpadu doporučení a znalostí, které v podniku
zůstanou poté, co projekt skončí a prodejci a poradci odejdou, není dlouhý,
většinou se rozplynou jako pára nad hrncem.

Nový styl práce

Myles Trachtenberg, viceprezident a generální ředitel zdravotnické divize
pojišťovny The Prudential Insurance Co. z amerického New Jersey, se snaží
prodloužit tento poločas a získat zároveň ty odborné znalosti, na které si
nemůže dovolit mít vlastní personál. Konzultanti u něj patří k běžnému provozu
na plný úvazek. Spolupracují s jeho lidmi každý den, na každém projektu nejen
na konkrétních projektech vývoje aplikací. Cílem je zlepšit proces vývoje
softwaru, od počáteční koncepce po konečnou instalaci, a zabudovat tato
zlepšení do trvale užívaných pracovních postupů. "Budovat a školit vlastní
organizaci můžete i tak, že ji necháte pracovat s jinou," říká. "Je to
získávání znalostí prostřednictvím asimilace."
Vnější tlaky ze všech stran od prodejců, konzultantů, zákazníků a samozřejmě z
podnikání samotného to žádnému oddělení podnikového vývoje aplikací, které se
bude chtít vydat vlastní cestou, neusnadní. Zejména pokud hovoříme o ojedinělém
oddělení, jako je to v BCBS. Meyer si ale nemyslí, že se svým grantovým plánem
zůstane dlouho sám. "Tím, že tady bude jasná finanční návratnost založená na
určitých definovaných funkcích, které mají být dodány, je méně pravděpodobné,
že zákazník projekt stornuje v půli cesty," říká. Je si ale vědom, že nápadité
využití technologie samo jeho projekty neuchrání. "Cena mého strategického
úsilí bude záviset na tom, nakolik se tyto aplikace budou používat," říká. Je
přesvědčen, že když se bude držet čistě prototypu jako kostry, nová verze Group
Paperless snad nesejde ze světa jako ta první. "Prostě bych tomu rád věřil,"
říká. "Částečně na to sázím svou kariéru."
9 0547 / jafn

Názory
"Ve vývoji aplikací se techniky a nástroje mění tak rychle, že moje organizace
prostě nestíhá držet krok."
Bill Boffi, Blue Cross and Blue Shield of Rhode Island.
"Klíčové funkce by nikdy neměly být zadávány vnějším zdrojům nebo nakupovány
jako hotový balík. Jakmile to začnete dělat, ztrácíte svoji jedinečnou identitu
a to, co vás odlišuje od vašich konkurentů."
Jeff Meyer, ředitel strategického vývoje, Blue Cross and Blue Shield of Rhode
Island.
"Během příštích několika let se budeme zabývat prakticky výhradně už jen
balíky. A my budeme řešit otázku: co bude s námi?
Tom Beegle, první zástupce generálního manažera skupiny pro MIS/Aplikační
systémy, Matsushita Electric Corp. of America.
"Musíte najít místo, kde byznys má trhlinu a kde to nemůže spravit ani
prodejce, ani integrátor."
Mike Gurevich, výkonný ředitel pro technologii a viceprezident vývoje
společnosti Concorde Solutions Inc.
"Budovat a školit vlastní organizaci můžete i tak, že ji necháte pracovat s
jinou. Je to získávání znalostí prostřednictvím asimilace."
Myles Trachtenberg, viceprezident a generální ředitel zdravotnické divize The
Prudetnial Insurance.
"Tradiční role programátora podnikových aplikací jde dnes stranou, když se
podíváte na
kteroukoliv prefabrikovanou aplikaci, zejména samozřejmě z hlediska integrace."
Bob Schwartz, viceprezident a generální manažer MIS, Matsushita Electric Corp.
Podle studie The Standish Group International Inc., poradenské společnosti se
sídlem v Massachusetts, omezení velikosti vývojového projektu aplikace zvyšuje
jeho šance na úspěch. V roce 1994 byly šance na úspěch (tj. včasné dokončení,
při dodržení rozpočtu a se všemi charakteristikami a funkcemi specifikovanými v
původním požadavku) podnikového projektu vývoje aplikace u firem z žebříčku
Fortune 500 jen asi 9 %. V roce 1998 průměrné náklady klesly na 1,2 milionu a
naděje na úspěch vzrostly asi na 24 %. Standish Group to připisuje lepšímu
řízení projektů (především omezení funkčnosti aplikace a času určeného na
vývoj) a většímu využívání standardních infrastruktur (např. Internetu).
Standish Group International zkoumala v letech 1994 až 1998 míru úspěšnosti na
vzorku 23 000 projektů aplikací u firem všech velikostí. Z jejích údajů vyplývá
dobrá zpráva: míry úspěšnosti stoupají.
Úspěch společnost definuje jako včasné dokončení, v rámci rozpočtu a se všemi
původně stanovenými charakteristikami a funkcemi.
Ohrožení vypadá tak, že projekt byl funkční, ale rozpočtové a časové odhady
byly překročeny a funkcí bylo méně, než se původně plánovalo.
Neúspěch znamená, že projekt byl stornován před dokončením.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.