PA105 7.3/zk Malé a střední podniky Small to medium enterprises (SME) •Z hlediska podnikové kultury jsou malí asi do dvaceti ajťáků. •Střední do dvou set ajťáků •Hranice závisí na tom, co podnik dělá a na kvalitě jeho zaměstnanců. SME •Mnoho ajťáků pracuje v nějakém menším podniku •SME – podniková kultura, klíčové inovace a omezení pro podrobné rozpracování procesů a velikost monolitických systémů •Mnohé technologie vyvinuté v SME jsou postupně používány mimo SME a jsou předobrazem budoucnosti ITC •Z malých občas vyrostou velmi velcí –Facebook, Google, HP •SME a moderní moderní architektury Malí a velcí a IS •Malý dodavatel SW a malý odběratel – Typická oblast uplatnění malých SW firem •Comodity, open source, vlastní vývoj, dobré nápady i při rizicích •Malý dodavatel – velký odběratel, vlastní vývoj –Subdodávky pomocí „přílepků“ resp. přepsání •Binární SOA, •Opencard transformace na Lítačky v Praze •Žádanky, •Z velkého systému se pomocí změny architektury stane malý •účast malých podniků na inkrementálním vývoji řešení velkých systémů, agilní vývoj ve velkém Velcí dodavatelé SW a malí uživatelé •Nejčastěji poskytovatelé SW komodit – datové báze, řízení, standardní operační systémy a normy •Problém s rozdílností podnikových kultur –SAP, Oracle •Problém s nákladností řešení, konfekce za vysokou cenu –SAP 6 Podceňované vlastnosti IT •Efekty IT, především IS se obtížně měří, často jsou jinde než se čekalo (uvedeme příklady) •Jsou často dlouhodobé a ty jsou jiné než krátkodobé •Někdy není ochota je uplatnit (př. školství) •Praxe ochrany dat neumožňuje data správně využívat aniž zajišťuje dostatečnou ochranu dat •Kvalita IT je tedy věcí kvalifikovaného používání, znalostí, zkušeností a někdy i (politické) vůle a boje s předsudky 7 Malé a střední podniky small to medium enterprises, SME •Malé podniky do 20 zaměstnanců •Střední podniky do cca 200 zaměstnanců •SW firmy považované za SME mají tendenci být menší než v jiných oborech •V ČR pracuje v malých a středních firmách 80% ajťáků (průzkum ČSÚ prosinec 2013) 8 ZÁKLADNÍ POZOROVÁNÍ •Podniková kultura menší SW firmy se méně liší od podnikové kultury podobně velkých organizací pracujících v jiných oborech (tedy i obvyklých zákazníků) než od podnikové kultury opravdu velkých organizací. •SME vývojář má větší šanci rozumět zákazníkovi, který je SME 9 Co je typické pro malé (SW) firmy •Rychlé změny –Diktuje je trh, malá tržní síla firmy – nemůže si dupnout –Úkoly i metodiky se rychle mění v důsledku požadavků uživatelů a změn vývojových ekosystémů –Menší firmy jsou pružnější obecně •Nejsou zdroje: –Nelze nasadit mnoho specialistů, nejsou k dispozici •V malých a středních SW firmách se snáze uplatní superprogramátoři a nové nápady 10 Co je typické pro malé SW firmy •Často nelze použít hotová komplexní řešení –Hotová řešení často dělají velcí pro velké, to není nic pro svět malých firem, mnohdy platí i pro normy, mnohé se musí použít znovu –Speciální požadavky: ne velké náklady ani dlouhá doba řešení –Kupodivu leccos vhodné pro malé firmy se uplatní i v e-governmentu a tam, kde IS silně ovlivňují přímo uživatelé (dokumentově orientovaná rozhraní), Viz používání digitalizovaných papírových dokumentů 11 Omezení pro malé výrobce SW •SME mají omezené zdroje (investice, čas, zkušenosti, …) a tedy nemohou zpravidla vyvíjet či modernizovat velké a dokonce ani středně velké systémy metodou velkého třesku (uvidíme, že to pro velmi velké systémy platí i pro firmy s prakticky neomezenými zdroji) •Musí se vyrovnat s tím, že jejich zákazníci potřebují ne zcela malé systémy a vyžadují, aby bylo možné některé části svého a systému outsourcovat •Nové systémy musí být integrovatelné s existujícími systémy •Musí být snadné je udržovat a při instalaci přizpůsobovat specifickým podmínkám svého zákazníka •Reagovat na globalizaci, dnes Industry 4.0 12 Důsledky omezených zdrojů v malých organizacích obecně •Méně lidí: role musí mít širší škálu úkolů, člověk ale zvládne jen omezený počet pravidel Þ podnikové procesy nemohou být detailně specifikovány •Malá uživatelská firma nemá prostředky na nákup komplikovaného systému, a ani nevytvoří podmínky pro jeho používání (zaučení, změny podnikové kultury), totéž platí pro vývojová prostředí SW firem •Velké IS vytváří velcí pro velké, nejsou tedy vhodné pro malé uživatele, malí výrobci SW je nejsou schopni vzhledem k výše uvedeným omezením vyvinout systém naráznaráz • • 13 Řešení omezených zdrojů v SME •Vyrábět co nejjednodušší systémy, –princip maximální možné lenosti –K čemu a proč je to třeba –Stálé podceňování pracnosti úprav •Přebírat •Používat otevřený SW a adaptovat ho (ERP5,AGdampiere,..) nebo používat hotová řešení (systémy třetích stran nebo legacy) • – – – 14 Řešení omezených zdrojů v SME •Nepoužívat Big Bang, nedělat monolitická řešení, používat architektury s autonomními komponentami –Moderní servisně a orientované architektury dokumentová orientace spolupráce komponent •Integrace systémů, cloud… •Inkrementální vývoj a údržba •Integrace komponenty s existujícími systémy (doplňky), •Změny skryté v komponentách, mnohé lze dosáhnout analýzou komunikace •Údržba splývá s vývojem •Uživatelé úzce spolupracují s ajťáky ve všech etapách životního cyklu Volba moderní SW architektury •Sítě autonomních entit komunikujících prostřednictvím strukturovaných textů (typicky digitalizovaných a zapouzdřených byznys dokumentů) •Entita může být i informační systém (ERP) •Entita může být uživatelské rozhraní jako služba Klíčové paradigma •Sítě autonomních entit (modulů) s rozhraními používajícími digitalizované byznys dokumenty, systémy správy dokumentů a případně s využíváním cloudů a inteligentní dokumentové rozhraní. •Dokument je strukturovaný text typicky v XML •Široce používaný konektor jako služba •Komunikace přes inteligentní síť používající transformace zpráv, jejich směrován, atd. •Modul může být uživatelské rozhraní •Komponenta může být i zapouzdřená sítě modulů •Postupně se stále více používá Překážky •Je obtížné přejít na nové paradigma. Např. vzory řešení pro objektový přístup mohou být špatná řešení pro SOA a naopak. •V praxi SW firem je pocit, že sítě autonomních komponent je prázdné heslo (viz. antipattern whats new) a že se bezdůvodně vzdáváme toho, co dobře umíme, zvláště když máme cloudy). •Je nutné stále více spolupracovat s uživateli. –Klesá význam/rozsah kódování, samotné kódování se mění. –Do vývoje i do běhu systému agilně vstupují uživatelé. • Výhody •Lze zjednodušit vývoj (agilní vývoj ve velkém, inkremetálnost, efektivní prototypování, adaptibilita ) a údržbu, lze se vyhnout velkému třesku •Snadné zaučování a využití byznys dovedností uživatelů •Nové nástroje pro management (analýza efektivnosti, snazší vyhledání příčin problémů,optimalizace, •Příklad z praxe –CRAB centrální registr administrativních budov, –Automatizovaná dílna jako síť autonomních komponent Na cestě k dokumentové orientaci •Jak zapouzdřovat, předřazená brána skupiny entit •Automatické převody formátů •IoT •UI jako prototyp •Přesměrování, transformace, •Gateway v síti • • • Dokumentová orientace Komunikace autonomních entit prostřednictvím strukturovaných zpráv Princip •Vrstva zobecněných komponent komunikujících pomocí komplexních strukturovaných zpráv –Typicky komunikující IS, resp. IS a UI (dynamická síť –Zprávy v XML –I data i příkazy –ditalizované (zapouzdřené ) byznys dokumenty •Obvykle navíc middleware s branami (gateway) •Existující komponenty lze zapouzdřit aby pracovaly s dokumenty –Lze hierarchicky skládat V prvém přiblížení SOA •Ale s dokumentově orientovanou spoluprací •To poskytuje mnoho možností, např. přílepky •a umožňuje hladký přechod od papírových dokumentů k digitalizovaným, snadné zapojení uživatelů • Existují metody jak zapouzdřit a snadno modifikovat to, co už je napsáno •Příklad žádanek Efekty •Inkrementální vývoj •Dekompozice na autonomní (často velké)části, ty lze převzít •Snadné transformace formátů a skládání zpráv •S průvodkami lze sledovat průběh vývoje i problémy za provozu. •Entity mohou být dynamicky zaměňovány, vytvářeny kopie, nahrazovány ručními zásahy… •Sourcing je jednoduchý •?? Zatuhnutí principů Automatická doplnění zpráv •Ke zprávě lze přiložit subdokument s údaji o tom, co se kdy s dokumentem dělo, resp s jinými organizačními údaji •To lze využívat různými způsoby při řízení prací resp. při různých analýzách a optimalizacích 25 Problém manažerů ve větších firmách •Jsou potřeba, manažer musí mít specifické dovednosti •Domnívají se často, že zvládnou řízení čehokoliv a nemusí při tom brát ohled na odbornost •Podceňují experty •Často dělají jaksi bokem odborná rozhodnutí –Omezíme se na C# a na produkty Microsoftu •A co nedostatky těchto produktů, –Často prosazují antipattern vendor lock in –Zavrhují open source (to se mění) V menších SW firmách se management často podceňuje •Manažerské činnosti dělají mnohdy zprvu vedoucí týmů •Ale časem při růstu firmy to nelze –Žere to čas klíčových lidí –Ti na to nemusí mít buňky –Je to stále složitější –Je třeba odlišovat manažerská a odborná rozhodnutí •Outsourcovat provozní řízení •Použít moderní SW architekturu, to mnohé usnadní • 26 Vedoucí týmů a manažer •V malých firmách často jeden člověk vede lidi odborně a dělá i manažerské činnosti a zabezpečuje provoz a byznys … •I ve velkých firmách je nutná vzájemná spolupráce vedoucích týmů a manažerů •Úkoly manažera a vedoucích týmů se částečně překrývají mnohdy doplňují, mohou být i v rozporu (příkladem je detailní sledování každé maličkosti) 27 28 Postup výběru členů týmu •Pomocí dotazníků se vyhodnotí úroveň požadavků na jednotlivých atributů projektu •Zjistí se úroveň atributů jednotlivých (vedoucích) členů týmů a zjistí se maximum hodnocení jednotlivých atributů přes hodnocené členy týmu •Maxima hodnocení členů mají být větší, než hodnocení atributů úkolu, je výhodné, aby se příliš nelišily •Lze pro to používat paprskové grafy •Důležitý je sociální talent vedoucího 29 Tři aspekty činnosti týmu Dosažení cílů týmu Budování a údržba týmu Profesní růst členů týmu Nadání k abstrakci a vedení lidí Nadání sociální Workoholici ? Učitelské nadání Kamarádi 30 Činnosti v týmu, především úkol vedoucího a manažera •Plánování je nutná spoluúčast členů a konsensus •Vysvětlování, rozbor úkolů, varianty, připomínky •Kontrola a Regulace, reakce na výsledky kontroly •Podpora včasné řešení problémů a sporů, cukr a bič, diskuse variant •Informování, nedopustit náhradu informací drby •Hodnocení, pokud možno veřejné, na základě i schůzek a brainstormingů, zaznamenávat •Vůdčí schopnosti, dovést seřvat, dovést přesvědčit a motivovat, ustát krizi, podpořit v krizi, obhájit navenek, držet slovo, charisma •Společenské aktivity. Není jednotný názor Přesun úkolů na podnik •Obecné podmínky pro vzdělávání a pracovní podmínky •Podniková podpora podmínek práce •Sociální vztahy •Personalistika všeobecně •Kontrola financí •ATD 32 Manažerské typy 1.Charismatický Rychle se nadchne, ale nevydrží. 25% případů, •při spolupráci dbát o to, aby neztratil zájem (tlačit) 2.Hloubavý. Je nutné mít připraveny eventuality, varianty a data. 11% •Pokud ho ukecáme bude držet slovo 3.Skeptik, Nutno vše doložit a vyčíslit. Dá na rady lidí z blízkého okolí. 19% •Často se bez nich nerozhodne, tendence přeceňovat deaily. 4.Následovník. Bere jen to, co se někde někomu už osvědčilo. 36%, snaží se mít alibi 5.Kontrolující. Má tendenci opakovaně silně prověřovat detaily. 5% Způsob řešení podle manažerských typů se uplatní i v SME •Lidé s tendencemi Následovníka se více uplatní u běžných provozních záležitostí • Hloubavý a charismatik při řešení nerutinních úkolů