Užitečná pravidla pro formulací cílů (vizí) projektu Jak alespoň zčásti formulovat odpověď na otázku proč do projektu jít A kdy do toho nejít a čeho se vyvarovat OD PROBLÉMŮ K CÍLŮM (vizím) •Nejprve je třeba formulovat problém (př. menší spokojenost zákazníků ) •Co chceme získat jeho řešením •Př. ŘEŠENÍ: Rychleji zjišťovat a reagovat na požadavky zákazníků, a tím zvýšit šanci, že koupí u nás, –Je nutné vyčíslit přínos v nějaké metrice (v byznysu v penězích, případně eliminace hrozeb, získáme o 10% více zakázek) Na co se zaměřit •Skutečné přínosy pro uživatele •Zohlednit zájmy, znalosti a dovednosti koncových uživatelů •Nezačínat od úspor lidí •Začínat od co nejmenší už užitečné varianty •Pozor na antivzor „ještě by se hodilo! • • To je seznam samozřejmostí •Čím samozřejmější věc zanedbáme , tím horších důsledků se dočkáme •Ještě dříve ale musíme řešit obchodní aspekty – klíčový je podnikatelský úspěch, - peníze na činnost firmy, silný manažerský aspekt •Najít témata a zákazníky /sponzory •Odkud získat peníze •Možné projekty, •Projekční záměry •Výběr projektu (projektů) a plánování …. •Doplňování poznatků a korekce podle zkušeností, smlouvy Nejobvyklejší činnosti SME •Přílepek – projekt jako doplnění stávajícího systému (př. nástavba nad cloudem) dokumentové rozhraní bývá výhodou • Posloupnost přílepků s vužitím rozhraní •Integrace existujících SW systémů •Je nutné zohlednit předpoklady podniku (i osamělého vlka), vybavení, kvalita lidí, co jsou k dispozici (především analytiků), krátkodobé i strategické –příklady •Ovládání HW • Obchod a více projektů •I menší firma, chce-li přežít, musí na úrovni koncepční pracovat na více projektech •Ubývá možností budovat celý systém •Přílepek se může stát komoditou –Velké firmy se snaží o spolupráci na úrovni rozhraní cloudů Probereme indikátory složitosti a příznaky možných průšvihů málo závisejících na typu úlohy. Jedná se většinou o jednoduché principy až triviality. Opomenutí triviality mívá stejně fatální následky jako srážka s blbcem. Co má stanovovat cíl: zformulovat proč se projektvyvíjí, jaký je problém a proč a případně principy, jak ho řešit •Přispět k zlepšení poslání organizace, tj. vyhovění důvodů, proč organizace existuje (jejího poslání), a důvody, proč je nutné současný stav zlepšit. •Podnik – vydělávání peněz prvotní důvod existence, kde máme rezervy, co nám hrozí. •Organizace státu – zlepšit službu občanům (s co nejmenšími náklady) –Pozor na lenost a úplatnost úředníků Problém času Odpověď na to, jak šetřit či získat peníze, závisí na době výhledu. Délka výhledu určuje, zda je prioritní zlepšit operativu, nebo pozici na trhu. Pranostika •Chceš-li, aby statek dobře hospodařil za rok, pohnoj pole •Chceš-li, aby statek dobře hospodařil za 10 let, zasaď stromy •Chceš-li, aby statek dobře hospodařil za 20 roků, dej syna na studie –Hnojit se ale také stále musí, aby bylo na studie • Operativa •Řízení ze dne na den –Operace ve skladu,účetní operace, zadávání výrobních operací •Vlastnosti potřebné SW technologie –Časté operace s poměrně málo daty –Data buď přesná, kvalitní, nebo jsou nepoužitelná –To ale neplatí pro data používaná při strategickém řízení (statistika, …) a rozhodování při neúplné informaci •Prostor pro přílepky – Role operativy (ze dne na den) •Dá se ušetřit rychle (úspora zásob, propouštění lidí). Někdy je to nutné, aby podnik přežil, –Propouštění a a úspora zásob je často levná cesta, jak rychle dosáhnout (dočasné) zlepšení hospodaření podniků, může to ale zastřít hlubší problémy (neperspektivní výroba). –Fatální je rušení činností majících charakter výzkumu a vývoje (př. Horní Bříza) •Úspory jsou často jen jednorázové •Neřeší to obvykle problémy dlouhodobé, může je i skrýt •Dobrá operativa je nutná, aby podnik dobře fungoval Čeho se vyvarovat •IS není hlavní nástroj zlepšení nefunkční organizace a odstranění jiných nedostatků podniku –IS sám nevytvoří koncepci podniku a nevymyslí nové výrobky a ani sám o sobě nezlepší marketing podniku –Počítač je zesilovač, zesiluje pořádek, ale také nepořádek, platí to i pro státní správu, tam nepořádek mnohým vyhovuje –Je nebezpečné měnit současně organizaci podniku a zavádět IS, razantní restrukturalizaci podnikových procesů (BPR) provádět opatrně, zvláště v nižších patrech hierarchie, import procesů může být kontraproduktivní •Někdy nelze jinak, to už ale bývá opravdu zle •Je žádoucí podnik nejdříve uvést do funkčního stavu; –jiný postup je někdy nutný, ale je vždy riskantní –To je trivialita, která se často nebere v potaz Další zásady •Strategické cíle mají v delším výhledu přednost i když i zlepšení operativy je významné, může dokonce zlepšit chování na trhu, nebývá dlouhodobě rozhodující. Co hlavně zohledňovat –Chování na trhu (marketing, CRM, SCM,…) je klíčové, •úspory uvnitř podniku (lidé, zásoby) jsou důležité, ale ne zásadní z dlouhodobého hlediska –Musíme zohledňovat zájmy všech členů koalice v podniku –Informace mají být dostupné každému, kdo je potřebuje –Zlepšování sociálního kapitálu (ztotožnění s podnikem, spokojenost, dobré klima, menší stres) je důležité, •sociální kapitál může mít efekty srovnatelné s investovaným kapitálem –Uplatňovat principy učící se organizace (znalosti se uchovávají a postupy zdokonalují, viz CMM) –Cíle by měly být stanoveny kvantitativně, ne však na úkor intuice –Minimalizovat okamžité organizační změny Další zásady •Strategické cíle mají v dlouhodobém výhledu přednost (pokud je na to čas a peníze ) –pro stanovení strategických a cílů je nejdůležitější zkušenost, intuice a schopnosti managementu obou stran, –SW má jen podpůrnou úlohu při formulaci cílů byznysu, ale zásadní význam při implementaci změn a při kontrole efektů •Pro strategické cíle lze často využívat přístupy teorie omezení od Goldratta (je jedna abstraktní podmínka, pokud se ta nezmění, ke zlepšení nedojde, srv. CPM), to může být úkolem přílepku •u Neměním co nemusím •Změny až po přesvědčivé analýze –Nedělám, pokud byznys dovolí, nic navíc – Začínám od minimální již užitečné konfigurace •Snažím se zapojit uživatele, kterých se daný úkol nejvíce týká, i ty “dole“ •Myslím na to, jak to prospěje i lidem dole, snažím se využít jejich dovednosti, např. způsob komunikace se systémem Minimalizace rozsahu jednoho kroku –Začínat od co nejmenšího již užitečného systému pokrývajícího nejurgentnější potřeby (srv. agilní postupy vývoje). • Paretův zákon 80-20 (80% užitku přináší funkce, jejichž vývoj si vyžádal jen 20% nákladů na vývoj) –Při rozšiřování systému se zaměřit na nejvýznamnější dosud nepokryté potřeby; vždy vážit: • zda použít hotovou komponentu, • jak nejlépe kombinovat ruční a automatizované prostředky, • zda není ruční práce efektivnější –Platí to i pro koupi systému, i v tom případě narazíme na problém, že nadměrně rozsáhlý systém přetěžuje lidi a že obsahuje balast, neboť nejsme schopni naráz správně specifikovat příliš velké množství požadavků • Balast je nejen drahý, ale také překáží, a tím vlastně snižuje užitnou hodnotu systému Musí být zohledněny i obchodní aspekty •Záleží i na technických limitech •Leccos umožní vhodná architektura. Cesty pomocí architektury •Dekomponovat a zprvu řešeit jen jeden nebo několik málo komponent, typicky uživatelské rozhraní, často ze použít jako prototyp •Zbytek koupit nebo neměnit (nechat ruční) a případně dodělal •Přilepovat k velkým systémům •Při dokumentovém rohraní lze dosáhnout mnoha dalších přeností usnadňujících modifikace a údržbu (skrývání informací!!! • Minimalizace rozsahu –Minimální řešení pro strategii by mělo být zaměřeno na úzké místo ve smyslu Goldrattovy „Teorie omezení“ –Problém: Je žádoucí inkrementální nebo iterativní vývoj (ekvivalent postupné dodávky) a je tedy nutná rámcová smlouva. To vyžaduje důvěru mezi partnery. •Obchodním problémem může být, že to omezuje pravděpodobnost, že se bude budovat velký a tedy drahý systém, což není zdánlivě v zájmu dodavatele SW, zvyšuje to ale pravděpodobnost úspěchu systému; to zvyšuje pravděpodobnost, že systém bude smysluplně rozšiřován (uživatel si po získání provozních zkušeností uvědomí, jak efekty zvýšit), dlouhodobě je to tedy i v zájmu dodavatele Některé špinavé triky při specifikacích cílů – snížení cíle Snaha snížit cíl Rozdíl cíl a skutečnost Cíl Implemetace Změna skutečnosti S S S S o o S – souhlasné O - opačné Způsobí změnu skutečnosti po jisté době, je žádoucí nedělat vše naráz, reorg cycle Některé špinavé triky – snížení cíle 2 Snaha snížit cíl Rozdíl cíl a skutečnost Kvalita cíle implemetace Skutečnost S S S S o o S – souhlasné O - opačné „udělat dobře“ s cílem odložit Vůle dosáhnout cíl S o o Posun termínu S o B B1 B, B1 – balancující cyklus Psychologický kontrakt při uzavírání pracovní smlouvy •Newstrom, J.W., Davis K., Organizational behavior at Work, 10th ed., McGraw-Hill, 1997 • •Lidé, někdy podvědomě, uzavírají sociálně psychologický kontrakt který má dva aspekty: –Ekonomický (peníze, vedlejší výhody jako rekreace, pracovní podmínky, pracovní doba, postavení, kariérní růst) –Sociální (dobrý kolektiv, jistota zaměstnání, pořádek a práce bez stresu, prestiž firmy, zajímavá práce a někdy odborný růst) •Při nástupu do zaměstnání je dobré vědomě uzavírat smlouvu s vědomím, jak dalece pokrývá všechny aspekty mojí virtuální psychologické smlouvy Psychologický kontrakt •Newstrom, J.W., Davis K., Organizational behavior at Work, 10th ed., McGraw-Hill, 1997 •IS by měl vytvářet podmínky pro výhodný psychologický kontrakt –Zlepšení pracovních podmínek, pořádek, menší stres, stabilita zaměstnání, prestiž, zajímavá práce –Vlastní (kvalitní) počítač a přístup na internet –Vyplatí se nebránit pracovníkům v zábavě na internetu, pokud je to jen v rozsahu menší přestávky –Může to být výhodné pro efektivnost práce a zdraví Psychologický kontrakt při uzavírání smlouvy na IS •Všechny významné aspekty psychologických smluv je žádoucí zohlednit při vývoji IS •Při vývoji a zavádění IS hledat spojence mezi těmi, jimž mohu vedle ekonomických výhod nabídnout výhodný psychologický kontrakt. Atributy technické složitosti úkolu •Systém,který implementujeme, nesmí být technicky podstatně náročnější na vývoj, než systémy, se kterými jsme dosud měli zkušenosti. Atributy věcné složitosti: •Množství funkcí, velikost systému •Rozsah a kvalita dat, •Interaktivnost, počet koncových uživatelů a počet rolí koncových uživatelů •Počet organizací, kteří budou používat (jeden, několik, obecná použitelnost,..) •Kritičnost aplikace (riziko ztrát při špatné funkci) Atributy technické složitosti úkolu •Systém,který implementujeme, nesmí být technicky podstatně náročnější na vývoj, než systémy, se kterými jsme dosud měli zkušenosti. Atributy složitosti: •Rozsah zabezpečení •Potřeba nových metod a nástrojů vývoje •Nový typ úkolu, nový typ uživatele •Příliš krátký termín •Modifikovatelnost, otevřenost IS •…… Tabulka pro hodnocení rizika neúspěchu pro vůdčí aspekty složitosti Aspekt 0 1 2 3 Interaktivnost Dávka Dotazovací systém Soft real-time Hard Real-time Počet on-line uživatelů 1 Desítky Stovky až tisíce Miliony Rozsah dat Gigabyty Terabyty 1000x více Kritičnost Prosté IS Ekonomické ztráty Ohrožení životů Vyvolání katastrofy Velikost Běžná pro dodavatele Pětkrát větší než obvyklá Alespoň 30krát větší Alespoň stokrát větší Rozsah použití Jediný uživatel Více uživatelů Hromadné použití Zabezpečení Nízká úroveň Běžná ochrana Vysoká ochrana Hodnocení rizika, zjednodušený postup •Pro každý aspekt najdu odpovídající sloupec v tabulce a číslo a v záhlaví sloupce •Číslo a zmenším o číslo b odpovídající dosavadní zkušenosti s daným aspektem. Má-li daný projet interaktivnost 2 a byly-li řešeny projekty s interaktivností 1, odečtu 1 a výsledek je 1. Vyjde-li číslo menší než nula, vezmu nulu. Tím dostanu hodnocení daného aspektu •Sečtu hodnocení všech aspektů. To je výchozí hodnocení rizikovosti projektu. Hodnocení rizika 2. krok •Hodnocení zvýším o 2 až 4 podle rozsahu potíží se specifikacemi) •Výchozí hodnocení zvětším o 2 až tři, je-li restart (tj. nové zahájení zkrachovalého projektu) a o 1 na každou následující okolnost: –Nový typ úlohy, –Nový typ partnera (je podstatně větší, je jiný a ne menší) –Nový typ partnera – typ byrokracie (ad hoc, strojová, profesní) –Náznaky špatné spolupráce s uživateli resp. nejasnosti v jejich záměrech, při silnějších příznacích zvětšit o 2-3 –Náznaky nedostatečné podpory managementů obou stran • Vyjde-li hodnota větší než čtyři, projekt nezahájím. Pro tři a čtyři jdu na věc jen výjimečně. Pro dvě jsou pravděpodobné potíže, neměly by být kritické. Jinak OK Hodnocení rizika opravím v závislosti na následujících skutečnostech •Kvalita vztahů se zákazníky •Vlastnosti členů týmu •Kvalita vedoucího •Případně další –Hodnocení snížím o 1, je-li daný aspekt velmi příznivý, a zvýším o 1, je-li velmi nepříznivý •Moje praktické zkušenosti: U projektů, kde jsme neuspěli, bylo toto hodnocení rizika vždy alespoň tři Musíme stále sledovat symptomy ohrožení projektu A využívat intuici a zkušenosti