Před uzavřením smlouvy a formulací vizí Základní technologie přemýšlení a formulace myšlenek a požadavků Důvody zavádění IS * Přínos IS by měl být především v oblasti strategických výhod. Využití IS je cesta jak se vyrovnat s rostoucí složitostí rozhodovacích procesů spojených s - s rostoucím počtem skutečností, které je při rozhodování nutné brát do úvahy, - se zkracováním doby na rozhodnutí, - s růstem rizik z opožděného či chybného rozhodnutí, - s důsledky rostoucí migrace pracovníků. To mj. vyžaduje, aby podnik nebyl závislý na žádném pracovníku a na informacích které jsou známy jen jemu, - se zrychlením inovací, * S potřebou oběhu informaci mezi všemi oprávněnými nutnou pro horizontální spoluprácí a zrychlení podnikových procesů. Důvody zavádění IS Z marketingového hlediska jsou důležité následující potenciální možnosti IS. - Lepší porozumění vývoje na trhu a potřebám zákazníků. - Zrychlení inovací výrobků a služeb. Tím dosáhnout předstihu nabídky před konkurencí. Pro zrychlení inovací je možné zkrátit dobu potřebnou k tomu, aby se správně rozhodlo, zda je inovace nutná a jaká by měla být, zkrátit dobu vývoje a náběhu výroby. - Zlepšení spolupráce se zákazníky CRM (rychlost vyřizování objednávek, reklamace, sběr požadavků), customer relationship management -Zlepšení spolupráce s dodavateli SCM (sledování toho jak probíhá příprava dodávek, supply chain management) Důvody zavádění IS * Z marketingového hlediska IS umožňuje * Sledování obchodních charakteristik (trendy, rozložení poptávky podle kategorie a druhů zboží atd.). - Využívání získaných informací pro optimalizaci (např. optimalizace výrobních dávek, optimální řízení zásob atd.). * IS umožňuje zachytit i méně zjevné či téměř skryté skutečnosti, např. fakt že existuje rezerva v prodeji u prodejce s vysokým obratem (zásobuje více velkých zákazníků než ostatní). * Z interního pohledu IS umožňuje získávat lepší informace o chodu podniku (informace o zásobách, lepší využívání kapacit, výrobní časy, prostoje, trendy prodeje atd.). * Spolupráce s obchodními partnery!! Důvody zavádění IS * Klíčovou podmínkou dosažení přínosů IS je včasnost a dostupnost a použitelnost informací pro všechny, kteří ho potřebují ke své práci. Ani to nebývá snadné - pro mnohé bývá výhradní vlastnictví určitých informací zárukou mocenské pozice v podniku a zárukou nepostradatelnosti. * To závisí na opomíjených aspektech kvality dat Shrnutí hlavních požadavků * Hlavní strategické přínosy -- Pozice na trhu * Znalost požadavků, vyhledávání a spolupráce se zákazníky * Spolupráce a kontrola s dodavatelů * Kvalitní služby a výrobky (montáž aut pro jednotlivé zákazníky na míru) * Inovace -- Podklady pro management, podpora rozhodování -- Zlepšování kvality zaměstnanců a vybavení firmy * Taktické -- Úspory lidí -- Efektivnější vnitropodnikové procesy -- Úspory zdrojů (zásoby, energie) Překážky přínosů IS 1 * Skrytým zdrojem růstu nákladů na IS bývá nutnost příliš velkých organizačních změn (prodlužuje to dobu zavádění IS a snižuje po jistou dobu výkon, zvyšuje rizika), snaha o naprostou úplnost a dokonalost oproti včasnosti. Specifikace mohou nabýt dokonalosti jen postupně. * Přesné postupy mají smysl jen pro kvalitní data, jinak jsou kontraproduktivní Překážky 2 * IS je drahé zboží, které poměrně rychle zastarává. Je tedy důležité, aby IS bylo uvedeno do provozu včas i za cenu, že budou zprvu zprovozněny jen hlavní funkce. Cenu IS při metodě velkého třesku zvyšují ztráty vzniklé tím, že IS nepracuje během uvádění do provozu. * Dlouhá doba zavádění IS do provozu zkracuje vlastně i dobu, kdy bude IS v provozu (od optimální doby provozu je nutné odečíst dobu zavádění). Je tedy důležité IS oživit co nejrychleji. * Jsou známy případy, kdy odkládání uvedení IS do provozu pro nepodstatné maličkosti způsobilo ztráty z přínosů ve výši několikanásobně převyšující cenu IS. Stalo se dokonce, že kvůli odkladům nebyl vcelku vyhovující IS vůbec uveden do provozu. IS ve státní správě * IS ve státní správě by měly sloužit především jako rychlý zdroj informací důležitých pro chod občanské společnosti. * Pro občany by měly zajišťovat rychlý přístup k legislativním informacím a informacím důležitým pro hospodářskou činnost, jako je ověřování existence firem a jejich kvality, ověřování občanských průkazů při hospodářské činnosti, celní informace atd. IS ve státní správě * IS mohou umožnit, aby úřady nevyžadovaly vždy znovu stejná data. Pro vládu představuje IS efektivní nástroj kontroly chodu státního ústrojí. Dobrý celostátní IS může být velmi efektivním nástrojem boje proti kriminalitě (např. odcizování aut) a dodržování pravidel občanské společnosti. * IS ve státní správě umožňují redukci počtu úředníků a zefektivnění státní zprávy. Tato možnost však bývá zřídka využívána. Je totiž proti zájmům řady vlivných zájmových skupin. * IS ve státní správě má charakter volné konfederace (není zřejmé, zda je použitelný Enterprise Service Bus) Potřeba tvůrčích lidí * Správné zahájení spolupráce má většinou ještě zásadní vliv na výsledek, viz agilní formy vývoje. Při tom velmi záleží na kvalitě zúčastněných a jejich schopnostech k tvůrčí práci * Na počátku spolupráce a při formulaci vizí je značný podíl tvůrčí práce a poněkud méně rutiny. Je tedy nutné, aby se mohlo postupovat tvůrčím způsobem. Pro to je ale třeba splnit řadu někdy nelehkých podmínek. Překážky tvůrčí práce (červeně souvisí s ergonomií) * Pracovní přetížení, nedostatek odpočinku (mozek pracuje i při spánku a při rekreaci, nesmí ale být přetížen) * Nadměrná kritičnost * Konzervatizmus * Hloupost * Lenost * Špatná ergonomie * Stres * Špatná fyzická kondice -- Sport a mentální hry * Špatná psychická kondice * Neuplatňování principu vítěz-vítěz při jednáních a diskuzích * Samolibost, snah si nezadat * Špatné osobní vztahy , nefunkční tým * Vyhoření neboli přepísknutí * Pesimismus * Dietní zlozvyky * Neschopnost naslouchat * Neschopnost měnit úhel pohledu a vidět souvislosti * Obavy (např. z propuštění) * Tíseň -- Časová -- Z nepřiměřenosti úkolu -- Z poměrů na pracovišti * Předsudky a apriorní soudy * Kariérizmus a snaha ovládat * Netvůrčí šikanující vedoucí * Demotivace * Neschopnost vidět souvislosti Stupně k uzavření smlouvy na straně uživatele * Uvědomění si základních potřeb a hlavní body vize * Poloformální písemná analýza potřeb * Vyhledání potenciálních partnerů (výběrová řízení) s případnou pomocí poradenské firmy * Rozhodnutí o míře outsourcingu a rozsahu nákupu customizovaných systémů * Výběr partnera (partnerů) * Jednání o vizi a cílech projektu * Uzavření (rámcové) smlouvy * Uzavírání smluv na jednotlivé etapy a realizace etap Uvědomění si základních potřeb * Situace na trhu: Existují potenciální zákazníci -- Kteří, kde, kolik jich je * kteří potřebují něco z toho, co umíme poskytnout -- Co -- Jak moc -- Proč právě od nás -- Proč a co si na tom cení -- Jak dobře to děláme a za kolik -- Co jsou ochotni zaplatit -- Jak dosáhnout toho, abychom to dělali stále lépe * V čem bychom se měli zlepšit a jaká jsou rizika Tři ekonomické dimense projektu * Při uzavírání smlouvy je nutné sladit -- Termín dokončení (čas řešení) -- Funkcionalitu (počet a komplexnost funkcí) -- Peníze * Je dobré si ujasnit, který rozměr je rozhodující (zda je nutné dodržet především termín, lze ale překročit rozpočet nebo omezit funkcionalitu). Snaha vyhovět všem třem dimensím vede k potížím. * Realistický termín nelze při pevném rozsahu funkcí zkracovat o více než 30% Nejčastější prohřešky * Syndrom pejska a kočičky, typické pro customizovaný SW, nevyhýbá se ani vývoji od počátku -- To by se snad mohlo hodit, tak to koupím. Nepotřebné ale překáží nejen v domácnosti * Všechno hned, neuzavírat rámcovou smlouvu i když to architektura SW umožňuje v domnění, že dodavatel pak neodejde od nedokončeného díla, podceňovat problémy se zaváděním systému * Nezvažovat, která řešení jsou důležitější a která méně a podle toho řídit projekt i nákup * Nadměrná snaha mít SW od jednoho výrobce * Nezajistit správnou spolupráci mezi vývojáři a uživateli Zákon 80-20 (někdy dokonce 90-10) * Ekonom Pareto zjistil, že u vývoje většiny systémů (nejen SW) 20% úsilí přináší 80% užitku. Málo potřebné a tedy většinou nedomyšlené funkce v IS dají většinou mnoho práce. Je tedy vhodné funkce nebo požadavky uspořádat podle významu a od těch začínat budovat systém. To má následující výhody: Varianty podnikových procesů Podnikové procesy mohou připouštět různou míru iniciativy a předpokládat různou míru znalostí těch, kteří je provádějí. Procesy velmi pečlivě a podrobně rozepsané na jednotlivé kroky většinou zajišťují kvalitní provedení, umožňují snadné zapracování nových pracovníků, často s malými nároky na kvalitu pracovníků (provádím to jako cvičená opice), jsou však náročné na vypracování, spolehlivost předpokladů a kvalitu podkladových dat. Hodí se proto pro velké podniky a velké země. Selhávají při nečekaných událostech (válka v Iráku, New Orleans) Varianty podnikových procesů Přechod od procesů umožňujících iniciativu a rychlé změny k procesům podrobně rozepsaným je velmi náročné (pozor proto na BMMI) Je to výrazná změna podnikové a národní kultury (proto u nás máme učňovská učiliště a průmyslovky a v USA taková zařízení prakticky nejsou) Varianty procesů * Proces pro úzkou třídu prací neumožňující iniciativu a on line změny: + snadné zaškolení i nekvalifikovaného, během života lze změnit typy zaměstnání - závislé na spolehlivých datech, drahý vývoj procesů, nízká iniciativa a omezené možnosti zastupování (zaskakování za) kolegů Typické pro USA Restrukturalizace podnikových procesů * Je velmi žádoucí nemodifikovat radikálně podnikové procesy (business process reingeneering, BPR), pokud není absolutně nutné. * V reálných situacích jsou v zemích, jako je ČR, BP skryty v myslích lidí a založeny na zvládnutých dovednostech a mnohé není vůbec známo, vybaví se až při vzniku určité situace * Obtížnost BPR -- případ NDR. Úplná restrukturalizace průmyslu NDR se ukázala jako neobyčejně drahá a velice dlouhodobá záležitost. Ani dnes po více než deseti létech není jasné, zda a kdy úspěšně skončí * Ani v USA nejsou s radikální BPR nejlepší zkušenosti i když tam nepředpokládají iniciativu. Restrukturalizace podnikových procesů * Studium známých případů BPR naznačuje, že jistější cesta než radikální (tvrdé) BPR je angažování kvalitního manažera. Revoluční změny podnikových procesů, jako TQM, často vedou ke zhoršení výsledků (výsledky průzkumu Gartner Group). Důvody selhání restrukturalizace podnikových procesů * V déle existujících organizacích v Evropě je mnohé založeno na zkušenostech (vzpomenu si, co mám dělat až když nastane příslušná situace). restrukturalizovaných procesech se tato znalost ztratí. * Změna typu procesů (s iniciativou/přesný) * Nové principy a zásady nemusí být pro danou situaci vhodné. Nové principy mohou být příliš jednostranné Důvody selhání restrukturalizace podnikových procesů * Kulturní bariéry (nelze procesy měnit i když jsou založeny na nekvalitních datech) * Nové nemusí být správně zvládnutelné s danými zaměstnanci (kvalifikace, znalosti, školení, zvyky) * Obrana zaměstnanců proti změnám při ohrožení jejích postů může být velmi efektivní. Nové nelze bez účinné pomoci zaměstnanců vůbec implementovat. Měnit jen to, co je nezbytné * U BPR je možná buď úplná změna, ta je ale velmi riskantní (tvrdá varianta BPR) * Nebo uplatnit měkkou variantu BPR, což je vhodné v případě, kdy jde o celkem dobře fungující organizaci. Tehdy lze často postupovat tak, že se nasazení IS jeví jako informační podpora a jednoduchá modifikace dosavadních procesů, byť fakticky za změnou stojí výkonná optimalizace. Takové BPR je levné a málo riskantní, nejde ale uplatnit vždy -- Mohou následovat postupné modifikace Postupná reorganizace a nový management * Nový management občas provádí BPR i proto, aby zlikvidoval náskok znalostí těch, kteří podle stávajících procesů jednají Minimalizace rozsahu -- Začínat od co nejmenšího již užitečného systému pokrývajícího nejurgentnější potřeby, -- 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 a zda není ruční práce efektivnější Minimalizace rozsahu -- Minimální řešení by mělo být zaměřeno na rozhodující omezení ve smyslu Goldratta -- Problém: je nutný inkrementální nebo iterativní vývoj a tedy je nutná rámcová smlouva. To vyžaduje důvěru mezi partnery. Tento problém je ještě vyhrocenější pro agilní formy vývoje Je rozumné začínat od co nejmenšího použitelného jádra? * Námitka: -- Zákazníkovi bude stačit to jádro a já přijdu o kšeft * Řešení: -- Dobře fungující systém inspiruje zákazníka k novým požadavkům tím spíše, že nedošlo k hororům při zavádění systému -- Některé funkce jsou možné až po oživení jádra, např. data pro management podniku. Až tehdy management zjistí, co může rozumně chtít. Vyloučit rizika ztráty znalostí * Přílišná závislost na počítači -- Ztráta kontaktu s realitou * Co je ještě OK, závislost na datech opomíjena (praktik okamžitě poznal, že hala je špatně navrhnuta, ostaní slepě věřili počítači, který ale počíta pro nesprávná data), IS vychází z modelu, který nemusí být OK * Přílišná víra ve výstupy (kvalita dat a meze výpočtů) * Ztráta schopnosti improvizovat * Ztráta znalostí lidí * Ztráta mezilidské komunikace (komunikace mezi lidmi může být i neverbální) Existenční řešení a úzké místo * Je výhodné systém budovat postupně počínaje snadno implementovatelným jádrem, které je již ale rozumně použitelné. Takové jádro nazveme existenčním řešením. Podle zákona 80-20 může již malé úsilí a investice přinést velmi významný efekt. -- Podmínkou je vhodná architektura systému, souhlas uživatele a možnost uzavřít rámcovou smlouvu. Tento princip je vhodné využít i při zavádění customizovaných systémů. Existenční řešení a úzké místo * Uspořádání požadavků podle významu by mělo umožnit vyhledání Goldrattova úzkého místa. -- Existenční (nemenší zahrnující všechny kritiké požadavky) řešení by obvykle mělo zahrnovat úzké místo (mohou být samozřejmě výjimky, ale pak je nutno provést kvalitní analýzu, proč tomu tak je). -- Pokud se neprokáže, že na prvých (prvém) místech seznamu požadavků je úzké místo, je třeba ho vyhledat a zařadit do seznamu s nejvyšší prioritou. Výběrová řízení * Cíl: najít nejlepšího partnera veřejnou poptávkou. Ve státních orgánech a někdy i pro přiznání dotací ze zákona. * Jednostupňová varianta -- Veřejná poptávka -- Příjem a vyhodnocení nabídek -- Výběr nejlepšího -- Uzavření smlouvy Výběrová řízení * Vícestupňová varianta -- Veřejná poptávka -- Příjem a vyhodnocení nabídek -- Výběr nejlepších dvou-tří nabídek -- Vybraní vypracují za úplatu podrobné nabídky -- Výběr nejlepší nabídky, -- Uzavření smlouvy * Je možné požadovat integraci toho nejlepšího ze všech nabídek Výběrová řízení * Některé špinavé triky -- Nedostatečná publicita (např. v regionálním listu v druhé části republiky) -- Odmítnutí nabídky lpěním na nepodstatných formálních maličkostech s tím, že někteří žadatelé nejsou požádán o nápravu (indoš) -- Stanovení nesmyslných podmínek tak, aby jim vyhověl jediný žadatel (MO), př. Mýtné. Obrana: Alespoň dva posuzovaní, audit průběhu, vícestupňové řízení, dohled odpovědných orgánů, sledování možnosti korupce Bohužel je to věcí orgánů, jejichž činnost máme jen malou možnost ovlivnit. Lze na to upozorňovat Spolupráce s poradci * Jsou vlivní, ale za výsledek přímo neodpovídají, často poskytují hlavně alibi pro management, ručí přes renomé své firmy (dá se zneužít: Andersen Consulting a Enron) * Mají rozsáhlé znalosti, viděli leccos, vymakané postupy * Umí vyhledat lidi s rozhodujícími znalostmi a vlivem (šedé eminence) v organizaci i mimo ni -- Chemička nedůvěřovala expertovi, zjednala si poradce, ti toho experta vyhledali a jeho doporučení zahrnuli do své zprávy. Stálo to místo desetitisíců miliony, přesto se to nakonec vyplatilo -- bylo přijato správné řešení s efektem stovek miliónů -- Hlavní bariéra mezi je ekonomy a technickými kádry (vi havarii Challengeru, kterou byly možno očekávat). IS by měl pomáhat bariéry zrušit (podpora horizontálních, tj. jdoucích napříč hierarchií, vazeb). Průšvihy s poradci * Je možná jen nepřímá kontrola -> větší možnost švindlování * Bývá střet zájmů (Andersen c., Kalifornie, Enron) -- Stejná poradenská firma je odměňována za výsledky firmy a dělá audit účetnictví * Poradci někdy doporučují dodavatele SW a současně za velké peníze dělají audit jeho výrobků * Přes to všechno je dobrý poradce terno. Problém volby partnera * Oboustranný prospěch (strategie vyjednávání vítěz-vítěz) -- V dlouhodobé spolupráci jinak nelze, jinak tratí oba -- Při vývoji IS je typická dlouhodobá spolupráce * Hodí se do portfolia našich zákazníků -- Dodavatel a odběratel by se neměli výrazně lišit co do velikosti -- Odběratel požaduje něco, co umím Problém volby partnera * Ekonomicky zdatný (zaplatí, asi nespadne, bude asi dobrý při jednání a poněvadž jako úspěšný bude pravděpodobně vědět, co je potřeba co má chtít). -- Indikátory: Růst, zisk a růst obratu, pověst na trhu, předchozí zkušenosti s daným partnerem, zkušenosti jiných s daným partnerem (restart), požaduje to, co umím -- Dobré reference (vysoký počet ale může znamenat, že se nebude vývoji IS věnovat dostatečná pozornost, zákazníka netlačí bota a tak neví, proč by se měl zabývat něčím takovým, jako je IS) Problém volby partnera sw firmy, co hodnotit * Vstřícnost * Podpora managementu a vstřícnost partnerů -- Dodržování termínů, dochvilnost, čas na jednání -- Vstřícnost při jednání (vítěz-vítěz), snaha najít oboustranně přijatelná řešení -- Zajištění účasti a dostupnost koncových uživatelů bez ohledu na pozici, včetně odměn a vytváření časového prostoru a odměn za vícepráci, styčný důstojník a spolupráce při agilním programování -- Zajištění zdrojů (místo, dokumenty, jiné prostředky) -- Přístup do pracovního procesu * Dojem -- Pověst, pořádek na pracovištích, pracovní rytmus Problém volby partnera sw firmy, co hodnotit * Má parametry, na které jsem zvyklý -- Velikost asi jako já (velký asi raději použije SAP, velký se s malým těžko domlouvá -- mají jiný pohled na svět) -- Je činný v oblasti, se kterou mám zkušenosti -- Používá typ organizace, se kterou mám zkušenosti -- Nebudu muset podstatněji měnit podnikovou kulturu (někdy ale nutné, např. když podnik ovládly soupeřící kliky) Organizační typy * Jednoduchá struktura. -- Nejsou explicite stanoveny role, vše na okamžité dohodě (jako tým je známo pod jménem horda) * Ad-hoc-kracie -- Role se na jistou dobu dohodnou (demokratický tým) * Strojová byrokracie -- Vše přes společného šéfa, přísně stanovené role, typické pro vojenské jednotky * Profesní byrokracie -- Pozice plyne z profesní způsobilosti (lékaři, akademická sféra) * Divizní struktura (decentralizace) Ad-hoc-kracie Role se na jistou dobu dohodnou (demokratický tým) * Nízká organizační pyramida * Dobře vyvinuta horizontální specializace (jaké typy činností kdo dělá), málo vertikální (kdo koho řídí), vysoká flexibilita * Vhodná -- Pro nová nikoliv extrémně velká řešení -- Pro situace vyžadující přímou, častou a rozsáhlou komunikaci mezi pracovníky -- Pro vývoj a výzkum, jsou-li k dispozici kvalitní lidé, pro agilní formy vývoje -- Pro virtuální týmy spolupracující přes internet (GNU, virtuální ad-hoc-kracie) * Podmínky: -- Nekritické aplikace -- Nepříliš tvrdé termíny -- Kvalitní pracovníci -- Nová řešení Strojová byrokracie "vojenská organizace" * Centralizace: Vysoká org. pyramida, veškeré dohody přes nejnižšího společného šéfa, jasně vymezení rolí a nadřízeností a podřízeností * Náplň práce je do značné míry určena postavením v pyramidě * Vhodné pro rychlou předem "nacvičenou" reakci na známé situace a pro spíše rutinní činnosti * Nutná v armádě. Často nutná u velkých organizací, pokud se nemohou, nebo nechtějí decentralizovat * Flexibilita závisí od kvality vedení, nebývá nikdy vysoká * Žádoucí podporovat iniciativu a horizontální vazby Strojová byrokracie a IT "vojenská organizace" * Předpoklad, že IT sníží výšku pyramidy se potvrdil jen zčásti, spíše usnadnil decentralizaci. * IT usnadňuje vedení opravdu velkých organizací, podporuje horizontální spolupráci urychlením cest přes šéfy, často ale neformálně i přímo * Je nutno pro IT získat šéfy. Je ale riziko, že se nedostaneme ke koncovým uživatelům. * IT bývá ohrožen střední management, bez něhož ale nelze systém specifikovat a uvést do provozu * Podniky se strojovou byrokracií bývají konzervativní. Často čekají, jak ad-hoc-kracie uspějí, pak je koupí, nebo napodobí Profesní byrokracie * Pozice a pracovní náplň plyne z profesní způsobilosti nebo z politického pověření, z papíru (lékaři, akademická sféra, státní byrokracie) * V části organizace je vždy nutná profesní byrokracie (důvodem je potřeba kontinuity, profesionality), s tou je vhodné domlouvat detaily IS. * Vedoucí bývají pověřeni vedením nebo zvoleni jen na určitou dobu. Není proto výjimkou, že nemají zájem o dlouhodobé projekty a často ani pro ekonomiku provozu * Při budování IS je nutné balancovat mezi šéfy volenými a byrokraty. * Rizika změny cílů na začátku dalšího volebního období. * Bývají nejasnosti v dělbě pravomocí * Nebývá ochota efektivně spolupracovat, tendence ke všimnému. Dosti obtížná varianta spolupráce. Divizní struktura (decentralizace) * V globalizovaném světě stále častější * Víceméně nutná pro opravdu velké organizace * Centrum stanovuje rámcové podmínky a alokuje zdroje, o které divize fakticky bojují na základě svých výsledků, vizí a někdy i známostí. Divize si tedy mohou i tak trochu konkurovat (viz VW a Škoda Mladá Boleslav) * Přechází až do spolupráce nezávislých (dceřinných) organizací * Šetří náklady, zvyšuje otevřenost, zvyšuje flexibilitu včetně outsourcingu a insourcingu, prodeje a nákupu částí * Divizní struktura je hlavní oblast uplatnění SW konfederací. IS budovány často zdola metodou pokusů a někdy i omylů. Důležitost vizí. IS usnadňují decentralizaci a organizační změny. Usnadňuje budování virtuálních sítí podniků Praha 1.12.04 Problém volby partnera SW firmy, co hodnotit * Dojem -- Pověst, -- Pořádek na pracovištích, kvalita sociálních zařízení -- Pracovní prostředí (především sociální zařízení) -- Pracovní rytmus (nikdo nešílí, nikdo se nefláká, všichni mají co dělat) -- Pocity z jednání s lidmi -- Organizační a věcné zajištění jednání -- Dodržování dohod Problém volby partnera * Shoda na prioritách -- Porozumění pro skutečnost, že je vhodné vyvíjet z co nejmenšího ještě použitelného jádra -- Porozumění pro požadavek účasti koncových uživatelů (většinou vedoucí oddělení, někdy i šikovní ze dna hierarchie), top management nemá specifikovat, jak má pracovat skladník, ale musí říci, jaká data od skladu potřebuje a jaká kriteria má splňovat -- Top management se musí účastnit vývoje jako koncový uživatel pro funkce, které chce používat -- Vzájemná důvěra založena na porozumění potřeb a a schopnost porozumět znalostem uživatele (např. mikroekonomické kategorie) Porozumění pro strategické imperativy * IS nemůže nahradit podnikatelský záměr a jen těžko odstraní nepořádek. -- Bývá dobře použít poradenskou firmu. * Problémy často bývají v podnikové strategii a ve fungování koalice zúčastněných v podniku. -- Co dobře funguje bývá neradno měnit, * Provést analýzu procesů a uvážit, zda není lépe zjištěné nedostatky odstranit ještě před nebo během specifikace požadavků * Jen po důkladné analýze měnit dobře fungující procesy, vyhýbat se situaci, kdy je nutná změna jen proto, že to vyžaduje instalovaný customizovaný informační systém Porozumění pro strategické imperativy * Smlouvu uzavírat jako rámcovou, jinak nelze použít moderní procesy vývoje systému * Domluvit se a angažovat IT oddělení uživatele, nesmí to ale nahradit jednání s koncovými uživateli, * Oddělení IT by nemělo být odstaveno, nesmí ani mít takový dojem, nemělo by mít vrch, pokud to celé nedělá samo * Je třeba se shodnout na důležitosti jednotlivých požadavků a cílů Agile manifesto * Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. * Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. * Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. * Business people and developers must work together daily throughout the project. * Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. * The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Agile manifesto * Working software is the primary measure of progress. * Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. * Continuous attention to technical excellence and good design enhances agility. * Simplicity--the art of maximizing the amount of work not done--is essential. * The best architectures, requirements, and designs emerge from self-organizing teams (ad-hoc-cracy). * At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Smlouva a agilní formy programování * Agilní formy programování neřeší dostatečně problém formulace smlouvy externím partnerem. Je možné učinit dohodu, že se smlouva doplní v okamžiku kdy se odevzdá nějaká komponenta. To je ale dost riskantní pro obě strany a hlavně to neřeší otázku, jak odměňovat neustálé změny. Jednou z možností je, že se řešitelský tým jako by najme od dodavatele, nebo se skutečně najme nebo se použije vlastní IT oddělení. Ověřeno to ale není. Rizika agilních forem * Vyžaduje kvalitní lidi * Nasazení uživatelů * Nejasné jak customizovat customizované systémy (nějaké možnosti zřejmě jsou) * Nelze pro opravdu velké systémy * Nelze pro kritické systémy * Menší rizika jsou a vyšší možnosti nabízí SO, pro kritické systémy asi i tehdy nevhodné Základy vyjednávání * Cílem vyjednávání je dosažení dohody (v podstatě formální nebo neformální formulace nějaké smlouvy) vyjadřující zájem jednajících stran změnit ve vzájemné spolupráci stávající stav. Cílem jednajících stran je dosažení stavu, který bude pro ně "výhodnější" (žádoucnější) než stav stávající (já chci jablko a je to pro mne důležitější, než peníze, které budu muset zaplatit, u prodejce je to naopak) * Dosažení cílového stavu budu muset něčím "platit", něco pro to obětovat (peníze, práci, ...). * Vyjednávání proto obsahuje stanovení předmětu smlouvy (koupě jablka), a (abstraktních) nákladů -- (jablko a peníze), které musí strany "investovat". Základy vyjednávání * Vyjednávání a diskuse v týmu jsou založeny na podobných principech jako vyjednávání. Zde investicí může být integrace vlastního nápadu do společného díla či potřeba nějaké práce. Cílem je zlepšení vyhlídek na dosažení cílů týmu. * Smlouva je vyrovnaná, jsou li investice obou stran pociťovány při daném předmětu smlouvy za vyrovnané. Vyjednávání vedené s cílem dosažení vyrovnanosti smlouvy se nazývá vyjednávání s cílem vítěz-vítěz * Vyjednávání v neformální formě je obsahem značné části činnosti manažera (s externími partnery i s podřízenými) * MANAGER AS NEGOTIATOR, James K. Sebenius, David A. Lax, , The Free Press, 1986, Manažer jako vyjednávač, James K. Sebenius, David A. Lax, , Victoria Publishing, 1994 Zásady mezilidské komunikace Je nutná při vyjednávání P.J.Howard, Příručka pro uživatele mozku, Portál, Praha, 1998 * Schopnost ptát se -- Dobře formulovat otázku -- Střídat uzavřené otázky (odpověď ano/ne nebo volby varianty odpovědi) s otevřenými * Umění naslouchat -- Slušně se zeptat se, mám-li pochybnosti zda rozumím -- Neskákat do řeči -- Parafrázovat komentáře kolegů, ale slušně a je-li obava z nedorozumění * Umění kritiky -- Věcnost, ne emocionalita. Ne ale záporné emoce k partnerovi -- Začínat pochvalou toho, co je dobré, je-li co, nebo alespoň něco ve smyslu, že to přispělo k porozumění problému Zásady mezilidské komunikace * Umění uznat přínos -- Co nejdříve po tom, co je k pochvale důvod -- Přesně říci a shrnout, co se skutečně podařilo a kde to lze využít * Umění využívat nápady -- Nápady se snažit využít a dobré rozvíjet, hledání nápadů není sportovní intelektuální soutěž, neprosazovat své za každou cenu * Umění předávat instrukce -- Jasnost, jednoznačnost -- Adresáti měli svými slovy zopakovat obsah instrukce (test porozumění) * Umění být struční a včas ukončit řeč či příspěvek do diskuse Zásady mezilidské komunikace * Umění zvládání konfliktů -- Zviditelňovat skryté potřeby a motivace stran -- Sladit zájmy a cíle stran, i v diskusi je dobré používat zásadu vítězí oba (nikdo se nedostane do nepříjemné pozice) * Assertivita -- Názory a pocity vyjadřovat neútočně a klidně -- Budit důvěru a šířit dobrou náladu a optimizmus * Umění řeči těla -- Gestikulací a postojem budit dojem otevřenosti znalostí a talentu -- Nepotlačovat mimiku vyjadřující pozitivní emoce -- Budit dojem přímosti a přiměřené sebejistoty, nežmoulat ruce, se nedívat stranou a také necivět upřeně do očí atd. Tvorba koláče a licitace * Obsahem dohody je -- Předmět dohody (popis cílového stavu). To nazveme pro jednoduchost tvorbou koláče -- Jak obě strany přispějí k tomu, aby se předmětu dohody dosáhlo, jak si rozdělí náklady a výhody (dělba koláče) * Vložení zdrojů (náklady), dohoda jak se náklady rozdělí * Stanovení termínů * Jak se rozdělí případné přínosy a výnosy * V případě prosté koupě je obsah dohody jednodušší Tvorba koláče a licitace Je vhodné se na uzavírání dohody dívat jako na dvoustupňový proces, byť ve skutečnosti se mohou jednotlivé kroky vícekrát střídat -- Stanovení obsahu a rozsahu smlouvy, proč se dohoda uzavírá (odpověď nemusí být pro obě strany přesně stejná) -- Licitace o rozdělení nákladů a případných výnosů a stanovení ostatních obchodních podmínek Tvorba koláče a licitace * Licitace je při jednání obvykle skutečnou licitací v běžném smyslu toho slova -- partneři se vstoupí do licitace s návrhy, které jsou pro ně velmi výhodné, o nichž si však myslí, že ještě stále nejsou tak nevýhodné pro partnera, aby odstoupil od vyjednávání -- Partneři se pak snaží postupným slevováním ze svých požadavků usmlouvat vzájemně přijatelné podmínky -- Je nutný talent jednat a schopnost najít ještě přijatelnou výchozí nabídku Licitace * Z pozorování a z prosté úvahy lze učinit závěr, že pokud si partneři důvěřují a nemusí se proto všelijak jistit a skrývat citlivé informace, je možné dosáhnout stavu, kdy je smlouva výrazně výhodnější pro obě strany, než by tomu bylo v případě vzájemné nedůvěry. (viz. příklady z Lax). To je typické zvláště pro dlouhodobou spolupráci. * Mělo by být snahou obou stran, aby smlouva byla vyrovnaná a přinesla maximální uspokojení oběma stranám. To je podstata taktiky vítěz-vítěz. Teoretici vyjednávání ukazují, že taktika, kdy jedna strana ztrácí, vede dlouhodobě ke ztrátám všech. Licitace a podmínky u nás * Legislativní džungle, neustálená společenská pravidla hry a úspěšnost nečistých metod zbohatnutí -> převládá snaha o uplatnění taktiky vítěz (dříve tunelář) -- ztráta (ostatní). Dlouhodobě to vede ke ztrátě i na straně vítěze, protože nakonec zvítězí ti, kteří vědí, že taktika vítěz-vítěz má své přednosti. A to jsou hlavně zahraniční firmy a také ti, co k majetku přišli vlastní prací (noví mladí podnikatelé). Vítěz zleniví! * To že politici připustili vznik podmínek, které usnadnily používání taktiky vítěz-poškozený vede nejen ke krátkodobým, ale také dlouhodobým ztrátám. Proč i vítěz nakonec tratí podrobněji * Ztratí zákazníka, neboť ten -- Spadne -- Nebude mít na další investice -- Půjde ke konkurenci * Nezíská další zákazníky (pověst) * Tratí -- Zleniví, neprovede modernizaci (Telekom) -- Přispěje k devastaci trhu (nedůvěra při vyjednávání a proto ztráty, špinavé praktiky, málo peněz) -- Zhorší politické podmínky -- Přispěje k zhoršování ekonomických podmínek Tvorba koláče a licitace u IS Zvláštnosti pro IS * Vyjednáváním lze dosáhnout toho, že se za dané peníze nebo s jen málo většími náklady dodá podstatně užitečnější systém (zvětší se koláč) * Obvykle je nutná dlouhodobá spolupráce, -- Je potřeba se chovat slušně a nevyužívat krátkodobé výhody, např. svoji převahu ve znalosti IT. Z dlouhodobého hlediska se to nevyplatí Tvorba koláče a licitace u IS * Předmět dohody se může měnit (vše naráz nebo postupně, výběr funkcí), odběratel nemusí mít jasno v tom co vlastně chce. -- Při daných nákladech může dodavatel optimalizovat obsah IS z hlediska přínosů pro uživatele (a sám z toho trochu získat) -- Modifikace předmětu uzavírané smlouvy se může kombinovat s cenovými nabídkami (licitací) -- Výhodné je používat dobré poradce * Zkušenosti ukazují, že optimalizovaná nabídka může po realizaci zvýšit zájem odběratele o další spolupráci a o rozšiřování systému -- princip vítěz-vítěz nutností Vyjednávání a společenské chování * Jednání, Jak úspěšně vyjednávat, Barabara Schott, Grada, 2002, ISBN:80-247-0412-9 * Důležité jsou obecné zásady slušného chování a společenského postavení -- Dochvilnost, ceremoniální zvyky -- Oblečení odpovídající situaci (za ředitelem nepůjdu v džínech, za koláčem ve fraku), pohodlné (nepohodlnost může vyvolat dojem nejistoty v předmětu jednání) -- Prvý dojem bývá důležitý * Organizační podmínky úspěšného vyjednávání -- Dost času na jednání -- Příjemné prostředí -- Dostupnost účastníků a expertů a budoucích koncových uživatelů (to závisí na správné volbě termínu, s účetními je lépe nevyjednávat v době uzávěrek) Organizace vyjednávání * Připravenost k jednání (vše, co se dohodlo, si pamatuji, vše, co jsem si mohl sám zjistit, znám) * Dokonalé zajištění lidí a ostatních podmínek vyjednávání * Dohoda o formátu a způsobu vyjednávání (dvojice, porada,...); vyjednávání na dálku (mail, telefon) je možné, ale spíše na dolaďování detailů a přípravu vyjednávání tváří v tvář, při vyjednávání na dálku chybí řeč těla (až 60% komunikace) * Místo konání -- Snadno dostupné -- Je lépe, když je to v místě odběratele,neboť jsou dosažitelní lidé, jejichž účast se ukáže potřebná až v průběhu jednání, má to však nevýhodu, že účastníci budou odvoláváni k problémům v pracovním procesu -- Jednání v místě může umožnit hostujícímu partnerovi nepříjemný vhled a poskytnout i informace, které by mohlo být lépe nechat pod pokličkou Řeč těla Průběh vyjednávání silně ovlivňuje neverbální komunikace (řeč těla). Tato komunikace je často podvědomá a tedy i nechtěná a někdy významnější, než komunikace verbální. Při hlasové komunikaci hraje roli i barva hlasu, proto je vhodné se i při komunikaci o telefonu usmívat. Intonací a rytmem řeči lze zčásti nahrazovat neverbální komunikaci při hlasové komunikaci. V mailu lze dosáhnout mnohé správnou volbou formulací Porady Pro nás společné označení skupinových činností, jejichž vstupy i výstupy jsou dokumenty nebo skupinové činnosti, které slouží k seznamování řešitelů mezi sebou, budování týmové spolupráce a k rychlému šíření informací. Cílem porad je nejčastěji posuzování dokumentů a presentací (verifikace) a týmová tvorba dokumentů Porady jako skupinové a řízené přemýšlení Budeme především, avšak nejenom, diskutovat porady jako prostředek řízeného přemýšlení * Správná příprava a organizace interakce ve skupině umožní -- Zefektivnit proces hledání řešení oproti individuálním postupům a mnohdy i jednání ve dvojicích (moderátor -- respondent) -- Synergické efekty umožní najít zcela nečekaná řešení -- Budování osobních kontaktů -- Ztotožnění lidí s cíli projektu -- Ztotožnění lidí s týmem a podnikem Cíle a účel porad (daná porada může mít více cílů) * Rychlé předávání informací a příkazů s podporou osobních kontaktů. * Rozvoj osobních vztahů, týmové loajality a týmového ducha * Synergické efekty týmového hledání návrhů a řešení (více lidí více ví), * Oponentury a posuzování návrhů a možností, * Integrace dílčích řešení Obecné zásady vedení porad Příprava předem -- Zajištění účasti a reservace místa -- Je vhodné rozeslat materiály k poradě předem -- Dohodnout styl debat (někdy i školením) Těsně před zahájením -- Prověření místnosti, presentační prostředky (fliphart, dataprojektor atd) -- Rozestavění židlí -- Přístup do DB a na internet, je-li třeba (pozor, aby to neblokovalo synergii spolupráce lidí) Při zahájení -- Zopakovat pravidla hry (program, volba témat a úhlů pohledu, pravidla přihlašování do diskuse a psaní na flipchart, délka příspěvků) Doba trvání nejlépe do hodiny, max. 3 hodiny. Přestávky po hodině, krátké (historky..) alespoň po 30 min. Obecné zásady vedení porad * Vedoucí (moderátor) porady, tato role může být rozdělena, pak administrativu spojenou s poradou dělá zástupce vedoucího, u brainstormingu může role moderátora chybět a pokud nechybí má být neformální. Úkoly moderátora. -- Stimulující vedení (moderování) porady * Zahájení se shrnutím cílů porady * Pokud možno nenápadné vedení diskuse, hlavně aby se dostalo na všechny, dodržováni fair-play (vítězi všichni) * Formulace poznatků, pokud s tím mají účastníci problémy * Vedoucí de facto (všichni ho uznávají) * Doba trvání do dvou hodin, s velkou přestávkou do 3 hodin, u braistormingu raději do 90 min. Krátké přestávky po půlhodinách Obecné zásady vedení porad Nápady a řešení se ihned zapisují a to tak, aby byly stále na očích všech (např. na flipcharty, lze navíc zapisovat i do databáze), to platí především u brainstormingu, je vhodné i jindy. Zápis na flipchart: -- Zvyšuje to pocit závažnosti, objektivnosti, -- Zpřesňuje formulaci myšlenek, -- Zbaví zápisy osobních ostnů -- Nic se neztratí, nápady nezapadnou -- Zlepšuje to komunikací a brání zacyklení diskuse -- Je nutné pro paralelní formy porad * Je vhodné, aby zápisy dělal pověřený člen skupiny - zapisovatel Obecné zásady vedení porad Výstupem porad je zápis o jednání a obvykle i několik listů flipchartu. -- Zápisy na flipchartu je třeba konzolidovat a zredigovat * doplnění odkazů, * vyloučení duplicit, * řešení kontroverzí a rozporů,.... -- a zanést do databáze projektu, je-li třeba a je-li kam -- Následuje * Vymezení úkolů, * Kontrola využití závěrů * Případné naplánování následné porady Použití porad při hledání nových cest * Na začátku je třeba se rozhlédnout a zjistit, jaké věci by se měly řešit, v čem je problém, co se o věci ví ve světě a co stojí za to, bychom se měli věcí zabývat. Přitom je velmi potřeba pozorně vyslechnout lidi ve vlastní organizaci a zcela na počátku požádat o pomoc manažery firmy. To řeší úvodní porady * Pak je nutno ve spolupráci se spolupracovníky najít cesty jak řešit vytypované problémy. Řešitelské porady * Nakonec je třeba přijatá řešení podrobit formální oponentuře. Oponentury by měly končit zápisem, v jehož důsledku by se mělo stanovit, jaký je výsledek oponentury (obhájeno?) a jaká jsou následná opatření Jaká rizika jsou spojena s nedostatečnou spoluprací s kolegy * Špatné rozhodnutí z nedostatku informací * Přehlédnutí důležitých skutečností * Převáží názory řvounů * Nepostřehne skryté emoce * Důležité informace se díky špatnému organizaci porady vůbec nevynoří * Lidé závěry nevezmou za své * Mají důvod je považovat za chybné * Mají pocit, že nebyly respektovány jejich znalosti (minule se to přece takto úspěšně řešilo) * Mají pocit, že se bezdůvodně jejich názor neprosadil proto, že ani oni nejsou bráni dostatečně vážně * Nemohli vyjádřit svoje intuitivní pocity Úskalí porad * Pokud není porada správně připravena a vedena , může být výsledek horší, než kdyby se problému věnoval pouze nejslabší člen skupiny * Neformální porada může být při správném provedení velmi efektivní. Podmínkou je, že je do 8 účastníků. Zainteresovaných a znalých problém ale bývá mnohem více. * Časté problémy, zvláště je-li mnoho účastníků: -- Ne všichni dojdou sluchu, převáží křiklouni, poznatky schopných se nevyužijí -- Příliš mnoho materiálu, poznatky se nestačí zaznamenat a vyhodnotit -- Diskuse se točí v kruhu, zapomíná se na obecně známá fakta -- Destruktivní jedinci -- Pocit křivdy u jiných * Náprava -- Paralelní porady, techniky provedeni řízeného přemýšlení atd., standardní oponentura Úskalí porad Zabijáci smysluplné debaty -- Dlouhé monology, odbíhání od tématu, nedodržování pravidel -- Osobní výpady nebo jen pocit, že jde o snížení prestiže -- Zatvrzelost při hájení stanovisek -- Neschopnost mezilidské komunikace Náprava -- Dodržovat pravidla slušnosti při dialogu a zásad mezilidské komunikace -- Vedení diskuse zkušeným moderátorem -- Stručně k věci -- Nezačínat negativně, např. vždy konkrétně pochválit, je-li co, a to tak, že není pochyb, že to myslíte vážně (je dobré hledět při pochvale přímo do očí). Nesouhlas skrýt do návrhu jak nápad vylepšit s využitím toho, co je využitelné v tom, s čím nesouhlasíte. -- Není-li zbytí, je nutno nesouhlas vyjádřit přímo, ale neurážlivě a fundovaně -- Neospravedlňovat se, nepotvrzovat se Podmínkou kvalitních porad je dobrá mezilidská komunikace P.J. Howard, Příručka pro uživatele mozku, Portál, Praha, 1998 Slušnost (nevyvolávat záporné reakce partnera), tj.: Umění naslouchat Čekat na dokončení myšlenky partnera Při pochybách, zda jsem rozuměl, parafrázovat myšlenku partnera Nebát se zeptat, pokud mám pochybnosti, zda jsem rozuměl Umění konstruktivní kritiky Raději bez obviňování a spíše neosobně Uznat positivní aspekty, jsou-li Kritiku zabalit do návrhů na zlepšení (lze-li) Podmínkou kvalitních porad je dobrá mezilidská komunikace Umění uznat Včas, co nejdříve po tom, co je k tomu důvod Co se přesně podařilo a jak se to dá využít Umění využívat nápady Snažit se využít to nejlepší, neprosazovat svoje nápady za každou cenu, nechápat spolupráci jako soutěž v níž si dokazujeme, kdo je lepší Umění předávat informace a instrukce Partneři by měli shrnout obsah instrukcí jako test porozumění Podmínkou kvalitních porad je dobrá mezilidská komunikace Asertivita Vyjadřuji se přesvědčivě, srozumitelně, klidně, šířím dobrou náladu Zvládání konfliktů Umění zviditelňování skrytých potřeb stran Uplatňování taktiky vítěz -- vítěz, slaďovat zájmy stran Umění poznat skryté motivace, které není vhodné zveřejňovat a omezovat jejich negativní působení Nazapomínat na řeč těla Bezprostřednost, postoje "vnímám vás", jsme celkem přátelé, nelezete mi na nervy, může hrát roli "líbíte se mi" Projevy otevřenosti a přátelství Závisí na talentu a výchově v dětství, dá se cvičit Hodně lze zlepšit tím, že důležitější body komunikace porady zapisujeme, nejraději na tabuli/flipchart * Názory jsou na očích * Blokuje opakování stejných nápadů * Nutí myšlenku domýšlet * Myšlenka se lépe zapamatuje * Odosobní se nápady * Dá se dále zpracovávat Obvyklá struktura porady * Zahájení a formulace cílů porady * Presentace problému (problémů), které by se měly řešit (referát) * Stanoviska posluchačů/diskusní příspěvkynebo podreferáty * Shrnutí a závěr Vždy je třeba vypracovat zápis z porady a snažit se formulovat závěry Na poradu by mělo navazovat řešení závěrů s případnou následnou poradou hodnotící, jak se závěry uplatnily v praxi Činnosti související s poradami Techniky porad Schůze -- Presentace dokumentu, úkolu nebo záměru (referát), je většinou vhodné ho rozdat účastníkům předem -- Krátká diskusní vystoupení, -- Závěr -- Varianty * Seznamovací * Kontrolní * Oponentury/revize -- Zřídka hledání nových idejí V SW se používají různé varianty oponentur (revize, procházení, inspekce) Techniky porad. Brainstorming * Neformální porada s cílem najít nová řešení, vize a myšlenky -- Krátký úvod, kde nás bota tlačí, možné využití podnětů managementů -- Okamžité nápady se zapisují na flipcharty a obvykle neformálně hodnotí, i bláznivé nápady se nezatracují, zápisy do 2 řádek, zapisovatel -- Vše, co se napsalo má být na očích -- Vyhodnocení a koordinace nápadů již nebývá součástí porady -- Není jasné, zda se má formalizovat postavení moderátora, -- Používají se různé techniky řízeného přemýšlení a formulace strategických záměrů Workshop . Pro hodnocení a kontrolu průběhu prací, získání přehledu o stavu prací -- Úvod -- Řada kratších vystoupení -- presentací výsledků s diskusí -- Shrnutí a závěr Interview * Varianta porady, kde se jedni převážně ptají a druzí odpovídají -- Ve dvou (moderátor a respondent) -- Skupinové Audit * Varianta porady, kdy se má zjistit, zda se řešení (ekonomicky) neodchyluje od plánu a zda je naděje na dosažení cílů co do obsahu i termínů -- Často za účasti managementu a vnějších auditorů -- V komplikované formě známé jako kontrolní den Techniky zjišťování a hodnocení opatření a řízeného přemýšlení * Paralelní brainstorming -- vlaječky * Brainstorming -- úhly pohledu * SWOT tabulka * Strategická matice * Strategické plátno * Strategická mapa * Balanced score card Paralelní brainstorming (vlaječky) * Rozdělení týmu na 4 skupinky rozumné velikosti (nejvhodnější je velikost 6-8) -- Každý má rozumnou šanci pro uplatnění -- Agresoři obtížněji nacházejí spojence -- Snazší koordinace práce * Každá skupinka posuzuje projekt podle atributů: -- Fakta, -- Přínosy-příležitosti-výhody -- Problémy, rizika, nevýhody, hrozby -- Pocity, intuice Paralelní brainstorming (vlaječky) http://www.edwdebono.com/ * V každém okamžiku řeší skupinka právě jeden aspekt a postupně jsou řešeny všechny aspekty * Úkoly se řeší cyklicky (je representováno symbolickým rotováním vlaječek, bílá fakta, žlutá přínosy, černá problémy, červená pocity), nápady se zapisují na flipchart * Skupinka má zapisovatele * Zápisy na flipchart jsou anonymní, barevně podle aspektu, na konci kola provádí zapisovatel redakci příspěvků a definitivní zápis na papír * Na začátku každého kola si účastníci přečtou, co udělali ostatní * Zaznamenávání pocitů a intuice je podle výzkumu důležité * Edward de Bono Úhly pohledu (aspekty) * Princip hodnocení podle aspektů je možné použít též jako obecnou metodu kultivace přemýšlení (i pro jednoho člověka, obecně pro skupinu). Doporučuje se k aspektům z paralelního brainstormingu * Emoce a intuice (červená) * Kritika (černá) * Přínosy (žlutá) * Fakta (bílá) * doplnit * Řízení (modrá) * Tvůrčí myšlenky (zelená) * V každém okamžiku si explicitně stanovím, který aspekt uplatňuji a pak se snažím hodnotit jen podle daného aspektu, aspekty mohu libovolně řadit, např. E, P, K, T, F, T, K, E Příklady obsahu úhlů pohledů Fakta Ztratili jsme deset procent podílu na trhu Ryby neobsahují cholesterol Lidé podle průzkumu se přestávají bát BSE Emoce Mám pocit, že se to nepovede Jsem proti povýšení Franty Prostě mu nedůvěřuji Zamlouvá se vám to? Mně se to líbí. Rizika Přijdeme o úvěr Podle mne to nemůže fungovat, protože ... Na trhu nás předběhne konkurence Příklady obsahu úhlů pohledů Řízení Domnívám se, že existují ještě tyhle alternativy Teď bychom měli vyhodnotit rizika. Shrňme, k čemu jsme dospěli. Pokusme se reformulovat problém. Vraťme se k faktům. Nemá cenu se přít. Tvůrčí myšlenky Mistr na dílně by měl s IS pracovat podle principu řízení na průšvih IS umožní užší spolupráci se zákazníky V Nokie se dřevem neuživíme, co takhle mobily Přínosy Naše auto je opravdu OK, marketingem bychom mohli dosáhnout zvýšení prodeje o desetinu CRM umožní zlepšit služby zákazníkům a tím zvýšit obrat Obsah úhlů pohledu Obsah úhlů pohledu Jak střídat úhly pohledu * Každý pohled lze aplikovat vícekrát * Začínat emocemi, je-li téma kontroverzní, jinak od faktů * Po zjištění problémů při kritice hledat tvůrčí myšlenky, jak z průšvihu ven * Po závěrečné oponentuře zkusit emoce * Kritika by měla být vždy po hodnocení přínosů * Možné sekvence -- Pro hodnocení nápadu EPKTFTKE -- Pro hledání nápadu FTPKTŘKE Jak střídat úhly pohledu Pro hodnocení nápadu * Emoce Intuice, existuje opozice mezi posuzovateli nápadu? * Přínosy Co může nápad přinést * Kritika Hledání slabin, kde můžeme narazit * Tvůrčí Jak na zjištěné slabiny a nedostatky * Fakta Existují skutečnosti ve prospěch nápadu? * Kritika Je to lepší? * Tvůrčí Závěrečný návrh zahrnující reakce na slabiny * Kritika Závěrečná oponentura * Emoce Pocity z výsledku Jak střídat úhly pohledu Pro hledání nápadu -- Fakta shrnutí dostupných informací -- Tvůrčí situace, hledání alternativ a možností -- Přínosy přínos každé z alternativ -- Kritika hodnocení slabin alternativ -- Tvůrčí odstranění nedostatků alternativ, další možnosti -- Řízení shrnutí výsledků, volba nejlepší alternativy -- Kritika oponentura vybrané alternativy -- Emoce jak to vypadá SWOT tabulka * Velmi používaná technika volby cílů používající následující atributy: * Externí -- O oportunities, příležitosti -- T threats, hrozby * Interní -- S strengths, přednosti -- W weakness, nedostatky SWOT tabulka * Hodnotí se dvojice S-O ,S-T ,W-O ,W-T v tabulce z obr. Postup zaplňování * Lze začínat od prostředku -- od toho, co děláme a jaký to má efekt * Nebo od okrajů, v čem obecně jsme dobří či slabí a co nám hrozí a jak to eliminovat SWOT tabulka * Programátorská firma SWOT tabulka * Programátorská firma SWOT tabulka * Prodejna. Inspirováno materiály firmy Anima Strategické plátno * Atraktivity jednotlivých obchodních atributů produktu (cena, občerstvení, reservace, ....) vlastních produktů a konkurenčních produktů se hodnotí známkou od 0.0 (nejhorší) do 1 a vynesou do čárových grafů (lze použít excel). Uveďme příklad pro aerolinky podle W. Chan Kim a R. Mauborgne, letadlo v ceně auta. Strategická matice * Matice -- Řádky jsou podúkoly cíle/akce -- Sloupce obsahují úkoly pro oddělení nebo pro nástroje, např. poradu -- Prvek i,j: Co se má udělat pro úkol i v oddělení (nástroji) j. * Použití -- Horizontálně: Jsou uvedeny všechny potřebné akce pro daný cíl/úkol -- Vertikálně: Je oddělení vytíženo? Je schopno úkoly zajistit? * Podobné použití: Delegování pracovníků na úkoly v týmu Strategická matice Strategická mapa Strategie firmy musí být zaměřena na dlouhodobý profit, ten závisí na službám zákazníkům. Služba zákazníkům zajišťují procesy ve firmě a ty mohou být dobré jen, jsou-li podpořeny investicemi do prostředků a do kvalifikace lidí. V každé oblasti může být řada opatření. Opatření v dané oblasti ovlivňuje opatření v dané oblasti nebo v oblasti bezprostředně vyšší. Odměny mohou ovlivňovat růst. Profit zajišťuje spokojenost majitelů, platy a profesní růst zaměstnanců a investice (zlepšování vybavení) a růst firmy. Oblasti: * Růst * Procesy * Zákazníci * Odměny Uvědomění si základních potřeb * Situace na trhu: Existují potenciální zákazníci -- Kteří -- Potřebují něco od nás -- Kolik jich je -- Kde jsou * kteří potřebují něco z toho, co umíme poskytnout -- Co -- Jak moc -- Proč od nás -- Proč a co si na tom cení -- Jak dobře to děláme a za kolik -- Co jsou ochotni zaplatit -- Proč od nás -- Jak dosáhnout toho, abychom to dělali stále lépe * V čem bychom se měli zlepšit a jaká jsou rizika Strategická mapa Uvědomění si základních potřeb * Situace na trhu: Existují potenciální zákazníci -- Kteří, kde, kolik jich je * kteří potřebují něco z toho, co umíme poskytnout -- Co -- Jak moc -- Proč od nás -- Proč a co si na tom cení -- Jak dobře to děláme a za kolik -- Co jsou ochotni zaplatit -- Proč od nás -- Jak dosáhnout toho, abychom to dělali stále lépe * V čem bychom se měli zlepšit a jaká jsou rizika (uplatnit TOC) Strategická mapa Strategická mapa Výhody: Orientace na klíčové prvky Lze doplnit kvantitativní údaje (metriky) Sledovat cykly Snížit počet reklamací- Vyšetřit příčiny reklamací -- Odstranit příčiny reklamací -- Snížit počet reklamací.... Každá akce by měla být na nějakém cyklu (cestě od zdola až nahoru) * Akce se lépe formulují * Odhalí se chybějící články * Cyklus podporuje stálé zlepšování Funguje i když nejsou metriky, účinnost cyklů se ale lépe prověří na metrikách Balanced score card: strategická mapa doplněná o metriky Budování strategické mapy * Nejprve se vyhledají problémy k řešení pomocí tipů od manažerů, a porad, především brainstormingů, případně interview * Vyberou se ty, o kterých se předpokládá, že jsou nejdůležitější (asi by jich nemělo být mnoho, tak pět až deset) a ty se umístí do strategické mapy * Najdou se sousedi daných problémů v mapě * Bezprostřední předchůdci opatření která jsou pro dané opatření nutná v dané a v nižší vrstvě a * Bezprostřední následníci - opatření, které na dané opatření navazují v dané a vyšší vrstvě * Musí se najít následníci ve všech vyšších vrstvách a předchůdci ve všech nižších vrstvách (podmínka cyklů) tím že se hledají sousedé sousedů Od strategické mapy k BSC * Po vybudování strategické mapy se k jednotlivým opatřením , např. zvýšit příjem, doplní měřitelné efekty - metriky, např. o 30%, a zkoumá se, jak tyto efekty dosáhnout pomocí předchůdců daného opatření v BSC schématu. Přitom se schéma upravuje, mohou se doplňovat další opatření Balanced score card, textová zjednodušená notace Balanced score card, textová zjednodušená notace Nejčastější účely porad, zpřesnění * Vstupní porada * Seznámení lidí, seznámení s úkolem, formulace vize * Forma -- klasická schůze * Investigativní * Hledání nových řešení * Brainstorming, řízené přemýšlení, interview * Integrační * Workshop, schůze Nejčastější druhy porad * Kontrolní porada -- Oponentura, revize (schůze ) -- Acceptační (schůze) -- Inspekce (silně formalizovaná oponentura) -- Kontrolní den (i oponentury) -- Kontrolní porada (průběh testů, schůze či workshop) * Závěrečná porada Jak hledat rychle nápady do 5 minut Pro hledání nápadu Prvá minuta -- zaostření Obhlédnout situaci, koncentrace na cíl přemýšlení Chybějící informace nahradit domněnkami Druhá a třetí minuta -- generování Které mé zkušenosti jsou relevantní pro daný cíl Generace myšlenek a jejich shrnutí do několika variant Čtvrtá minuta - výběr variant na základě priorit Nejbezpečnější varianta Nejoriginálnější varianta, atd. Pátá minuta -- vyhodnocení Kritika vybrané varianty Co jsme o tématu zjistili Soutěž nápadů * Po (několika) poradách s cílem najít nápady a také při implementaci nápadů je žádoucí nápady uspořádat podle významu s uvážením všech (nově zjištěných) skutečností a rizik * Nápady je také třeba uspořádat podle významu (očekávané efekty) Kriteria pro volbu SW balíku, pohled uživatele i dealera * Reference pro oblast aplikace (funkce, velikost zákazníků, třídy uživatelů -- výroba, stát, obchod, finance,... - zkušenosti z česka), cena, termíny dodávky * Velikost výrobce a počet zemí, kam dodává, ekonomické výsledky * Otevřenost (integrace vlastních produktů a produktů třetích stran, komunikace s cizími systémy) * Technologická modernost, * Přenositelnost (HW, OS, databáze) * Požadavky na restrukturalizaci * Zkušenosti s dealery a systémovými integrátory * Podpora při provozu Převzít? + menší nebezpečí, že dodavatel opustí trh (customizovaný IS bývá obvykle podporován větší firmou), menší náklady na vývoj, snazší údržba + menší riziko totálního krachu projektu - ztráta znalostí nutných k vývoji vlastních komponent - neodpovídá přesně potřebám. To obvykle znamená menší účinnost a také vícenáklady na reorganizace, které by jinak nemusely být nutné. - IS má i konkurence, takže neposkytuje podstatnou výhodu před konkurencí. - závislost na dodavateli * vyšší nabídka funkcí, které však nemusí být vždy potřebné a pak zbytečně zvyšují nároky na obsluhu systému a také na hardware. Převzít? + obsahuje know-how mnoha instalací, + dodavatel většinou poskytuje přesné postupy pro zjišťování požadavků, instalaci, školení koncových uživatelů a oživování systému na místě, + ověřeno na více instalacích (reference, lze převzít zkušenosti), + úspora nákladů na vývoj a především údržbu, - vyšší nebezpečí, že je IS založen na zastaralých technologiích, - u cizích systémů nedostatečná lokalizace (potíže s českou legislativou a abecedou), - obtíže s integrací produktů třetích stran a existujících aplikací Výhody a nevýhody převzetí oproti vývoji Výhody * menší nebezpečí, že dodavatel opustí trh (customizovaný IS bývá obvykle podporován větší firmou * Menší riziko totálního krachu projektu, alibi pro m-t * obsahuje know-how mnoha instalací, dodavatel většinou poskytuje přesné postupy zjišťování požadavků, instalaci, školení koncových uživatelů a oživování systému na místě * ověřeno na více instalacích (reference, lze převzít zkušenosti), * úspora nákladů na vývoj a především údržbu, Nevýhody * neodpovídá přesně potřebám - menší účinnost a vícenáklady na reorganizace. * IS má i konkurence, takže neposkytuje konkurenční výhodu * vyšší nebezpečí, že je IS založen na zastaralých technologiích * u cizích systémů nedostatečná lokalizace (potíže s českou legislativou a abecedou) * obtíže s integrací produktů třetích stran, nově vyvinutých modulů existujících aplikací (v SOA přestává být problémem) * Závislost na dodavateli Optimální řešení * Při servisní orientaci mám poměrně snadnou možnost kombinovat customizované a nově vyvíjené komponenty, to je třeba využít s cílem dosáhnout optimálního výsledku Systémový integrátor * Finální dodavatel * Typická forma dodávky customizovaných systémů -- Ručí za vše, včetně subdodávek -- Specifikuje požadavky, včetně rozhraní na jiné systémy a integraci existujících aplikací a dodávek třetích stran -- Dekomponuje a stanovuje implementaci spolupráce komponent -- Dohaduje pravidla ručení a pravidla údržby -- Je partnerem pro celý životní cyklus * Často velmi silná závislost na výrobci balíku (i org. začlenění) Problémy systémové integrace * Do značné míry stejné, jako u vývoje SW obecně. Některé problémy jsou zvláště palčivé. * Systémový integrátor by měla být větší firma * SI je obvykle příliš vázán na jednoho výrobce * Nedostatky při řízení projektů * Česká společnost pro systémovou integraci * Nedořešena spolupráce s malými firmami Organizace spolupráce se SI * Dohlížecí výbor, kontrola, audit Vedoucí projektu (od SI), jeho zástupce (styčný důstojník) zástupci managementů stran, vedoucí řešitelských týmů, pomocné síly * Řídící výbor, věcné řízení, operativa Vedoucí projektu, styčný důstojník, zástupce vedoucího, vedoucí řešitelských týmů, klíčoví zástupci uživatele, pomocné síly * Řešitelské týmy Customizace. Dokumentace, zavádění, systémové služby Vedoucí týmu, jeho zástupce, zástupci koncových uživatelů daného subsystému, řešitelé, dokumentování Hlavní zádrhele na počátku projektu * Podceňování počátečních etap a předčasná formalizace či programování. -- Nejde jen o řeči -- Nereálné představy -- Špatná spolupráce -- Obtížné testování --inspekce! * Nedostatečné vedení projektu -- Není vedení týmu, chyby v týmové práci, neobsazeny důležité role -- Není formální (tj. podle přesně formulovaných pravidel) stanovování úkolů, jejich kontroly a přebírání -- Mnohé důležité informace nejsou v písemné formě * Nepostupuje se metodou maximální možné lenosti -- předčasné řešení technických detailů Hlavní zádrhele na počátku * IS jako náhrada invence při hledání strategie podniku a podnikatelského záměru, -- Nejasné cíle * Syndrom pejska a kočičky * Přesnost požadována větší, než umožňují data, zbytečně ostré požadavky na interaktivnost, kvalita dat * Zamlčené předpoklady a souvislosti * Nedostatečná kvantifikace cílů * Nereálné termíny, nezájem managementu, chybějící zdroje * Neochota budovat systém postupně. Jazyk dokumentů počátečních etap budování IS * V úvodních etapách životního cyklu přecházíme od intuitivních (a často vágních) představ a úmyslů k poměrně exaktní formulaci požadavků, tj. vymezení toho, co se bude nakonec realizovat. * V této části životního cyklu je značné nebezpečí, že při zpřesňování představ se odchýlíme od původního záměru. * Specifikace požadavků musí zohledňovat vlastnosti počítače a dostupného softwaru a vyžaduje jistou praxi. Proto se neosvědčuje se, aby specifikaci požadavků dělal výhradně uživatel, který často pro stromy nevidí les. * Je ale nutné, aby se uživatelé specifikace účastnili. Bez nich se nedají dobré specifikace udělat Jazyk dokumentů počátečních etap budování IS * Při specifikaci požadavků je ovšem potřeba ověřovat u budoucích uživatelů, zda to, co navrhujeme, pokrývá potřeby. * Zde je problém společného jazyka partnerů, protože způsob vyjadřování (jazyk) různých profesí (programátor a např. ekonom) bývá velmi odlišný. * Navíc mívají různé profese různé požadavky na přesnost vyjadřování a různá kritéria pro to, co je pro řešení problému důležité (a co je třeba) a co nikoliv - mají různá základní paradigmata Jazyk dokumentů počátečních etap budování IS * Vzhledem k problému společného jazyka partnerů bývá nejdostupnější formou specifikace požadavků formulace požadavků na IS formou odborného článku (tj. formou používanou ve vědeckých a technických publikacích znalostního oboru uživatele s menšími doplňky , např. diagramy), tj. specifikace požadavků formou založenou na přirozeném jazyce. * Takový postup je prakticky nevyhnutelný u formulace cílů (při formulaci cílů vycházíme z intuitivních představ) a má mnohé výhody i při specifikaci požadavků. Poznamenejme, že popis funkcí v přirozeném jazyce má velký význam pro údržbu (srv. Guinares, 1985). Podobný efekt má uživatelsky orientované rozhrani služeb. * Specifikace by se neměly obsahovat prvky softwarového návrhu. Měly by se omezit na požadavky uživatelských funkcí v jazyce uživatele, tedy v jeho odborném jazyce srozumitelném i vývojářům, v jazyce blízkém jazyku přirozenému * Struktura specifikace ale musí být vhodná pro danou SW architekturu Jazyk dokumentů počátečních etap budování IS Použití jazyka odborných článků (včetně grafických metod, vzorců atd.) má při specifikaci požadavků na IS následující výhody : 1. Jazyk odborných článků umožňuje plynulý přechod od formulace cílů k formulaci požadavků (formulace požadavků se realizuje jako zpřesnění a rozpracování cílů projektu; požadavky se formulují v jazyce blízkém jazyku dokumentu o cílech projektu). Při vnitřních oponenturách lze snáze ověřit, zda je realizován původní záměr. 2. O používaném jazyce se mohou partneři poměrně snadno dohodnout. 3. Jazyk odborných článků umožňuje postupný přechod od vágních (nepřesných) formulací k přesným definicím. Tato vlastnost je výhodná především v počáteční etapě prací, kdy nelze ještě vše definovat přesně a úplně - pak je výhodné, že můžeme být jen tak přesní, jak je to při dané úrovni znalostí možné. Jazyk dokumentů počátečních etap budování IS Jazyk odborných článků je založen na částečné formalizaci přirozeného jazyka a má jako přirozený jazyk tyto nevýhody : 1. Dokumenty mohou i při konečné redakci obsahovat nejasné, nepřesné nebo víceznačné formulace. 2. Pro formulace v jazyce odborných článků se jen obtížně provádí (matematický) důkaz správnosti. Obrana -- dobře provedené opnentury 3. Jazyk je volen tak, že odpovídá okamžitým potřebám. Proto může být nedokonalý (nepřesný) a není standardizován. 4. Jazyk odborných článků nelze mechanicky převést na program - prototyp. To ztěžuje tvorbu prototypů ( a oddaluje okamžik, kdy je možné ověřit správnost návrhu provedením funkcí systému; často lze testovat funkce až v okamžiku realizace cílových programů - a to může být příliš pozdě). Obrana - prototypy Jazyk dokumentů počátečních etap budování IS Jazyk počátečních etap musí do jisté míry zrcadlit architekturu softwaru a filosofii, jak bude vyvíjen. To je poněkud v rozporu s tím, co jsme dosud říkali. -- Lze použít diagramy, které jsou po krátkém zaškolení srozumitelné i uživatelům -- Architektura SW ovlivňuje hlavně strukturu specifikací, méně již jazyk dokumentů -- Vždy se zaměřujeme na to, co je třeba, a to v termínech a jazyce, kterému uživatel dobře rozumí. Jak se bude věc řešit je pro řešitele irelevantní, i když fakticky vhodný popis toho, co je třeba, značně usnadňuje problém jak to udělat (viz UML) Specifikační jazyky * Specifikační jazyk je v mnoha směrech jazykem programovacím (viz možnost generace prototypů). Požadavek používání specifikačního jazyka tedy může obsahovat požadavek zvládnutí základů programování (nebo přinejmenším požadavek přesného vyjadřování v oblasti, kde není zadavatel odborník). Také to může omezit intuici a vnucení myšlenkových modelů specifikačního jazyka. * Spolupráci se zadavatelem může někdy usnadnit takový formální specifikační jazyk, který je "šit na míru" řešené problematice. * Kombinovat s diagramy (to je také formalizace) Specifikační jazyky * Formalizované specifikační (tj. téměř programovací) jazyky jsou obecně schopny vyjádřit požadavky, a snížit tedy nebezpečí nedorozumění. Tento efekt však přinesou jen tehdy, když jsou opravdu zvládnuty všemi zúčastněnými. V opačném případě mohou být výsledky horší než při specifikacích formou odborného článku. * Formální metody mohou být používány jen velmi kvalifikovanými týmy a jsou vhodnější pro software, při jehož vývoji není nutná spolupráce s uživateli. Pokud mají specifikační metody tvar matematických teorií (např. algebraické specifikace) je v principu možné provést důkaz správnosti. Bohužel je tato metoda pracná a neumožňuje komunikaci s uživateli. Je tedy vhodná pro ty typy softwaru, kde není spolupráce s budoucími uživateli nutná (komunikační protokoly, zčásti systémy pro hromadný prodej). Specifikační jazyky, výhody * Shrneme-li, mají formalizované specifikační postupy následující výhody: 1. Umožňují (v principu) přesnější vyjadřování a snáze se při nich dodržuje disciplína. 2. Lze pro ně provést snáze důkaz správnosti. 3. Někdy mohou být formálně (automaticky) transformovány na prototypové řešení (a tím usnadňují prověření správnosti specifikací). 4. Lze snáze zkontrolovat, zda výsledné programy odpovídají specifikacím. Specifikační jazyky, nevýhody * Specifikační jazyky mají i nevýhody : 1. V případě IS je obvykle nutné, aby specifikačnímu jazyku rozuměli všichni zúčastnění.Pokud tomu tak není, nelze očekávat dobré výsledky. To je většinou případ formálních specifikací. 2. Zápis požadavků ve specifikačním jazyku je složitější a pracnější než u specifikací formou odborného článku. 3. U těch částí specifikace cílů, které nelze testovat na prototypech, je větší nebezpečí, že specifikujeme (zdánlivě přesně) něco jiného než chceme (podobnost procesu specifikování s programováním znamená, že začínáme de facto programovat příliš brzy). Proč nemůže specifikovat zákazník sám * Zdálo by se, že vypracování "Specifikace požadavků" by mělo být výhradním dílem budoucího uživatele. Podle zkušeností však specifikace požadavků zákazníkem značně zvyšuje pracnost realizovaného systému a především zvětšuje pravděpodobnost neúspěchu. Příčiny této situace jsme diskutovali na více místech. Shrňme je nyní: Proč nemůže specifikovat zákazník sám * a) Uživatel nebývá schopen omezit požadavky na rozumné minimum. Nevylučují se požadavky méně potřebné až neužitečné (syndrom dortu pejska a kočičky). b) Uživatelé jsou si zřídka plně vědomi vlastností, možností a omezení moderních informačních technologií (zvláště u customizovaných IS). c) Uživatele nemají dostatek zkušeností pro vypracování uceleného systému požadavků.Nezřídka jim chybí komplexní znalosti o fungování vlastního podniku na mikroúrovni. Nemají cit pro to, co lze použít, co lze snadno realizovat a kdy je realizace ohrožena. d) Je větší nebezpečí, že se do požadavků prosadí zájmy těch "co jsou u toho" a budou opomenuti ostatní budoucí uživatelé systému. Proč nemůže specifikovat zákazník sám * Dokument "Specifikace požadavků" by měl proto být vypracován ve spolupráci pracovníků dodavatele s pracovníky uživatele a oponován budoucími koncovými uživateli systému. * Je tedy žádoucí, aby mezi členy týmu vyvíjejícího dokument "Specifikace požadavků" byli pracovníci zákazníka.Je ale riskantní specifikuje-li podrobné požadavky sám zákazník předem. * Role zákazníka při specifikaci požadavků v důsledku shromažďování zkušeností s provozem informačních systémů a možnostem, které nabízejí nové informační technologie, postupně vzrůstá. * Optimální je, když jsou v týmu uživatelé, kteří mají trochu pojem o IT a vývojáři, kteří rozumí problémům uživatele * Pozor na poučené laiky (Případ Olomouc) Základní vlastnosti specifikací požadavků * Specifikace požadavků musí vycházet z dobře formulovaných cílů a mají splňovat následující požadavky * a) Mají být úplné (ve všech aspektech - tj. v definici funkcí, požadavcích na efektivnost a ve stanovení rozhraní na vnější prostředí). Důležité je stanovení reakcí na chyby (v datech,obsluhy atd.) a exitů. b) Měly by být ověřitelné (testované). Není vhodné formulovat požadavky, které nelze otestovat (např. požadavek, aby program neobsahoval nedosažitelný (mrtvý) kód - takový požadavek nelze v plné obecnosti ověřit, nebo aby doba odpovědí byla obvykle nižší než 10s -v tomto případě je nutné slovo "obvykle" kvalifikovat, např. stanovením, že v 5% případů může být doba odezvy mezi 10s a 20s. Základní vlastnosti specifikací požadavků * c) Musí být bezrozporné (tj. nesmí obsahovat požadavky, které jsou ve sporu, např. na jednom místě se požaduje sečítání vstupů a v jiném násobení; jeden požadavek stanoví, že události A a B se vylučují jiný, že A a B probíhají souběžně). * d) Měly by být konzistentní, podobné věci se řeší obdobně Základní vlastnosti specifikací požadavků * d) Musí být modifikovatelné (změny se provádějí snadno) srozumitelné. To vyžaduje, aby byl každý požadavek formulován právě jednou a vyskytoval se na jediném místě. Výhodné jsou různé rejstříky a tabulky vzájemných odkazů. * e) Musí být vystopovatelné ("vysledovatelné"), tj. u každého požadavku je možné zjistit důvody, proč byl formulován a také jaké důsledky z daného požadavku vyplývají.Bez toho lze jen obtížně požadavkům rozumět a vyhnout se opakovaným chybámU algoritmů realizujících některá zákonná opatření, je důležité uvést přesný odkaz na paragraf, podle kterého je daný algoritmus realizován. * f) Definice požadavků by měla být použitelná i během provozu systému a při údržbě. Pro údržbu je důležité především všeobecné, ne nutně formálně úplné popisy (podrobné specifikace mohou být z části nahrazeny zkušebním provedením výpočtu). * g) Stabilní. Je důležité, aby se požadavky v průběhu prací neměnily. Základní předpoklady spolupráce na specifikacích * Pocit vlastnictví a a odpovědnosti za celek * Neegoistický přístup -- Opravuje ten, komu to dá nejméně práce -- Neprosazuje sobecká řešení z důvodu nafoukanosti nebo lenosti * Mezi posuzovateli jsou ti, kteří budou závislí na kvalitě specifikací (uživatelé, řešitelé následných etap), ti budou mít zájem o kvalitní oponenturu Náklady * Složitý výpočet, často odhadem na základě zkušeností. Využít služby rozpočtářů. * Lidé -- Členové týmu, manažeři, konzultanti, dohled, systémáři -- Daně a odvody z mezd -- Cestovné a dovolené -- Ztrátové časy -- Náklady na mazískání zakázky * Nájemné a jiné provozní náklady (nájem, odpisy, služby) * Investice * Náklady na subdodávky * .... Standardy * IEEE standard 830-1993: IEEE Recommended Practice for Software Requirements Specifications, IEEE Standards Collection, Software Engineering, 1994 Edition, ISBN 1-55937-442-X * ISO/IEC 90003:2004 Software engineering -- Guidelines for the application of ISO 9001:2000 to computer software * IEEE Recommended Practice for Software Requirements Specifications: IEEE Std 830-1998. In: IEEE Software Engineering Standards, Volume Four, Resource and Technique Standards. IEEE, Inc. 1999.