Zeptali jste se, aneb dotazy a odpovědi

Pokud se sami chcete na něco zeptat, neváhejte se na nás obrátit, rádi pomůžeme a nebo přiznáme, že nevíme.

Na této stránce uvádíme odpovědi na otázky, které naši konzultanti dostali nebo které jste nám zaslali emailem a přišly nám zajímavé. Zásadně neuvádíme autora dotazu, aby to někoho neodradilo od chuti se na nás obrátit. Vždy také měníme kontext, pokud by hrozilo, že by se někdo mohl v situaci poznat nebo poznat svou firmu.


2023

[Dotaz od vedoucího vývoje bankovního IS] My to teraz mame tak, ze mame navrhnute overview od architektury ako by to cele malo vyzerat na uroven aplikacnych sluzieb danych komponent, ale realne analyza prebieha na urovni popisu obrazoviek a nasledne navrhu integracnych sluzieb na danych komponentach (aka operacie..) a teraz vznika dotaz kto by mal vytvorit (a hlavne udrzovat!!) mapping medzi aplikacnycmi sluzbami a integracnymi sluzbami, t.j. arch vs analyza..

Je dobré, aby se držel jeden směr toku informací a každý si přebíral vstupy pro svou vrstvu od předchozí. Za sebe bych prosazoval, aby integrace (nižší vrstva) přebírala od aplikace. Přebírat = dělá i mapping, protože na základě business zadání vymýšlí technické řešení. Musí tedy buseinss zadání rozumět, kdežto business architektura pro svou práci rozumět technické služby znát nepotřebuje.

Důvody a komentář
  • Když se staví na hotovém sytému, business analytici budují nad existující architekturou, protože oni nastavují business vrstvu podle možností systému. Vy jste ale soudím v opačné situaci.
  • Když budovaná architektura má být poplatná business modelu, je potřeba, aby informace šly správně od businessu k architektuře - agilní model, kdy vstupem je "user story". Business model je vstupem pro architekturu, architektura by si je tedy měla převzít. To je myslím váš případ.
  • Jiná situace by nastala, kdybyste budovali univerzální systém. Tam je nutné, aby architektura byla taky univerzální, tedy nikoli poplatná jednomu konkrétnímu použití. V takovém případě business zadání musí architekti splnit, ale současně do něj mluví, aby vzniklo řešení univerzálnější.
    tomto případě bych prosazoval postup opačný, protože business analytici, kteří se s modelem služeb seznámí, budou současně schopni jej revidovat a kompetentně opnovat.

Je to rada trochu "od stolu" bez pdrobností, ale smysl uvažování snad zachycuje: Komptence dělit tak, aby se co nejvíc využilo, že někdo studuje návrhy někoho jiného. Předpoklad, že oba komunikující týmy mají kvalifikované odborníky je v tom samzřejmostí.

2022

Máme používat v projektu raději UML nebo SysML

UML a SysML jazyky jsou na první i druhý pohled poměrně podobné, takže se mohou jevit jako záměnné. UML se vyvíjí o něco rychleji, oba jsou ale standardizovány relativně nedávno (SysML je standardizován v ISO/IEC 19514:2017.

Zásadní rozdíl jazyků je v jejich zaměření. SysML má své místo především tam, kde se dělá návrh komplexních systémů obsahujících elektroniku i software. UML je naproti tomu zaměřen výhradně na softwarový vývoj.

SysML je de-facto i de-iure (díky zmíněné normě ISO 19514) standardem pro týmy v automobilovém průmyslu, letectví, ale i dalších odvětvích vyvíjející stroje, které mají vliv na bezpečnost a u kterých je vysoká spolehlivost vyžadována nejenom zákazníky, ale i standardy.

UML je používán výhradně při návrhu a vývoji software, pro který je určen. Pokud má projekt jenom softwarovou vrstvi, je UML výhodnější zejména díky jeho většímu rozšíření a znalostem. Ale pokud by se měl vývoj týkat např. embeded software, už je na místě zvážit SysML, protože nejenom software, ale i jeho analýzu a návrh bude třeba sladit s analýzou a návrhem okolního hardware.

Pro oba jazyky, máme školení, tak je možné si vybrat mezi školením SysML a školením UML.

2016


jaká KPI / cíle má smysl definovat pro implementaci projektu enterprise architektury a co to firmě objektivně (měřitelně) přinese?

Jak velký bude v absolutních číslech přínos, samozřejmě závisí zejména na tom, jak "špatná" je situace před implementací i jak pořádně se implementace architektury udělá. Následující čísla odpovídají nejběžnější situaci, kdy firma dělá pro své projekty analýzy, ale ty zůstávají projektovou dokumentací a v dalších projektech se využívají minimálně nebo vůbec.

  • Zrychlení implementačních prací projektů (část analýza až o 40% – analýza současného stavu a vyšší kvalita analýzy); relevantní je měřitelný úspěch o 30%
  • Snížení počtu předělávek a oprav zjištěných v průběhu testování a zkušebního provozu úprav; lze předpokládat zlepšení cca o 30%
  • Snížení závislosti na konkrétních lidech resp. jejich znalosti a zvýšení zastupitelnosti; v optimálním případě lze předpokládat 100% zastupitelnost u analytiků a to i v průběhu projektu (předpokládá se zastupitelnost jinými analytiky se znalostí business domény
  • Zlepšení škálovatelnosti týmů provádějících analýzu a dynamické přidělování kapacit (jde o přímý důsledek předchozího bodu)
  • Snížení rizikovosti celého IT díky lepší analýze rizik a závislostí; v ideálním případě lze u 100% elementů (SW i HW) možné říct, jaký důsledek na business má jejich výpadek/porucha a mít tak kvalitně připravené recovery plány

Důležité je upozornit, že Enterprise architektura je dlouhodobá investice, a její přínosy jsou tomu podobně – projevují se s časem a většinou nejdříve rok po skutečném zavedení principů do praxe. Proto bývá i obtížné vázat přínosy s KPI, které jsou v naprosté většině vyhodnocovány s periodou roku nebo méně.

Jaké jsou vhodné nástroje pro modelování organizace (procesů nebo celé enterprise architektury)?

Takto položenou otázku je těžké odpovědět bez toho, abychom dělali nějakému nástroji reklamu a jiný zatracovali. A stejně tak se vystavujeme riziku, že budeme nařčeni z neporozumění či neznalosti toho kterého nástroje a náš soud bude lynčován pro nekorektnost. Přesto se pokusíme odpovědět, i když trochu obecně.

Za zásadní oblasti, které doporučujeme ověřit a ohlídat před rozhodnutím pro ten který nástroj, jsou:

Umožňuje vytvářet modely, které potřebujeme? Podporuje např. procesní modelování v BPMN, enterprise architekturu v ArchiMate? Samozřejmě existují další potřebné jazyky, např. pro návrh software může být důležitý jazyk UML.

Podporuje nástroj modelování obecně? I tato otázka je důležitá, řada nástrojů modelování fakticky téměř nepodporuje.

Umožňuje výstupy tak, aby s nimi mohli všichni pracovat? Dokážeme výstupy sdílet, publikovat, odesílat apod.? Není přístup k informacím vázán na nástroj, které je obtížné pochopit? Je třeba rozlišit mezi autory informací – aktivní tvůrci modelu a příjemci informaci, kterými jsou typicky metodici, manažeři, ale i dodavatelé IS. Pro ně musí být informace snadno dostupné a přehledné.

Umožňuje sdílení a omezování přístupu k informacím? Zdaleka není samozřejmé, aby nástroje umožňovaly sdílení modelů a současně umožnili přístup jen k určitým částem modelu.

Podporuje skutečně práci s modelem? Možnost pracovat s prvky modelu nezávisle na schématech je pro seriozní práci fakticky nezbytná a snad komerční nástroje to podporují (pokud nejsou primárně "kreslítky"). U free nástrojů už to zdaleka tak samozřejmé není.

Kolik bude nástroj stát jednorázově a ročně? Peníze až na posledním místě, nicméně náklady na jednotlivé nástroje se liší (skutečně!) řádově. Nezapomeňte dobře spočítat, kolik lidí by s informacemi mělo ideálně pracovat. Nejedna dobrá snaha skončila na tom, že licencí organizace pořídila tak málo, že se nástroj stal v praxi nevyužitelný. Na celkových nákladech se v případě některých nástrojů hodně podepisuje i faktická nemožnost nástroj používat bez soustavné pomoci dodavatelské firmy. Příkladem je situace, kdy si bez dodavatele nemůžete nastavit metodiku, vytvořit datový výstup, tiskovou sestavu apod. Tyto dodatečné náklady často představují o to větší limit, že jejich potřeba nastává nenadále a oddělení na ně nemají rozpočet.

Hodilo by se na závěr říct, který nástroj vyhovuje. Ale v tom je potíž: žádný z nástrojů, se kterými jsme dosud pracovali, nevyhověl ve všech kritériích podle potřeby. Vždy je výběr postaven na kompromisu mezi tužbami, potřebami, možnostmi i znalostmi lidí. Rádí vám pomůžeme vybrat, ale víme, že co se hodí pro jednoho, není dobré pro všechny.

2015


Musí být business analytik schopný modelovat data v 3NF (datový model v 3 normální formě)?

Na tuto otázku je odpověď alibistická: Jak kdy. Rozhodující totiž není, jak se ta která pracovní role jmenuje, ale jak jsou rozložené úkoly v týmu.

Směrodatnější je, co očekáváme od business analytiků u přijímacích pohovorů a tady mohu odpovědět jednoznačně, že ať jsme dělali přijímací pohovory na analytiky pro pořizovatele software (banky, apod.) nebo dodavatele (softwarové firmy), ani v jednom případě nebyla role definována tak, že by přípravu dat do podrobnosti datového modelu vyžadovali.

V praxi lze očekávat, že od business analytika kdekoli jinde než v softwarové firmě, se tato schopnost neočekává. Není důvod pro to důvod.

Naopak – i když to tak vedoucí a tým nepožadoval – pokud jde někdo dělat analytika do softwarového týmu, spíš bych doporučil, aby význam 3NF alespoň chápal, protože pak bude lépe rozumět tomu, jak s datovým návrhem pracují designeři.

Proč na začátku odpovídám "Jak kdy", když odpověď je nakonec docela jednoznačná? Protože zejména v malých týmech (a mohou to být i týmy vytvořené velkými firmami o stovkách SW specialistů), je prostě nezbytné, aby analytik kvalitní návrh databáze zvládl, protože nikdo jiný to za něj dělat nebude. Stejně tak nemálo projektů skončí tak, že analytik připraví data v nástroji typu Access nebo Excel a pokud bude chápat teorie správné práce s daty, tedy mj. i 3NF, má šanci udělat řešení, které bude sloužit spolehlivě a bez závad.

Z našich vlastních projektů můžeme potvrdit, že dodržování teoretických modelů návrhu aplikace i dat se nám maximálně vyplatilo – jejich důsledné dodržování snižuje náklady na údržbu aplikace na méně než 10% toho, co jinak aplikace běžně vyžadují. Bohužel, mnohé současné "rapidní" přístupy k vývoji, házejí teorie za hlavu a nahrazují je rychlostí – tedy rychlostí z počátku vývoje. Z hlediska celého životního cyklu aplikace spíš než o rychlost jde o dohánění hrubou silou. Ale to už jsme u zcela jiného tématu.

Pokud chcete dělat analýzy kvalitně, pomůže k tomu náš cyklus školení pro analytiky.

2014


Jaké informace o IT aplikacích by měl sledovat vrcholový management organizace?

Vrcholový management je v principu odpovědný za vše, co se v organizaci děje, ale jeho role je vzhledem k Enterprise architektuře stejná, jako vzhledem k ostatním částem firmy:

  • Kontrola, že výkonný management se o oblast správně stará
  • Sbírat podklady pro upřesňování globální strategie a tuto strategii definovat
  • Vést péči v souladu se strategií organizace

Z tohoto úhlu pohledu lze říct, že vrcholový management v podstatě zajímají informace, které by IT mělo o aplikacích kontinuálně udržovat a vyhodnocovat. Vrcholové vedení tak navazuje na dobrou práci odpovědného hospodáře, který má přehled o tom, o co se stará.

Konkrétně pro oblast IT aplikací by management (CEO) měl po vedoucím IT (CIO) chtít informace o pohledech

Finanční pohled

  • Kolik stojí provoz (správa, údržba)
  • Kolik se do ní ročně investuje (rozvoj)
  • Jak se náklady na provoz vyvíjí

Strategický pohled

  • O jaké klíčové informace se aplikace stará
  • Jaký je překryv funkčnosti aplikace s jinou aplikací (kolik by dalo práce její funkčnost integrovat do jiné)?
  • Jaký je objem ročních změn aplikace
  • Jaká je strategie IT s dalším rozvojem aplikace
  • Jaké strategické projekty v posledním roce vyžadovaly implementaci do aplikace a jak dlouho se na implementaci čekalo

Ochrana rizik

  • Kdo se o ní stará
  • Jaké je riziko, že se starat přestane (jak se s rizikem pracuje)
  • Co by se stalo, kdyby o ní nebylo postaráno
  • Jak budeme fungovat, když aplikace selže/nebude dostupná

Pro posuzování všech hledisek je podstatné:

  • Jaké vnitřní služby (schopnosti) nebo produkty (služby klientům) jsou na aplikaci závislé
  • Na jakých dalších aplikacích je tato aplikace závislá

2013


Našel jsem na vašich stránkách, že pomáháte rozvoji businessu a podnikání. Máte nějaká doporučení, co je nejlepší marketingová strategie pro malou firmu, abychom naše produkty lépe prodávali?

Především musíme rozdělit pojmy marketingová strategie a propagace (pravděpodobně existujících) produktů.

Marketingová strategie

Marketingová strategie začíná dlouho předtím, než máme hotový produkt. Začíná ve chvíli, kdy si klademe otázku, kam chceme s firmou dlouhodobě směrovat:

  • Jaký trh chceme oslovovat - zaměřujeme se na B2B korporace, malé firmy nebo B2C – bohaté klienty nebo širokou veřejnost?
  • Jakou chceme mít strategii, s čím na trh přicházet - chceme být leadery trhu nebo přicházet s levnými variantami existujících produktů?
  • Jakou jedinečnou vlastnost budou naše produkty mít – cenu, konkrétní vlastnost, souhrn vlastností apod.
  • ... a řada dalších témat, bez kterých bude business strategie neužitečná nebo dokonce nebezpečná

Těmto rozhodnutím musíme přizpůsobit celou firmu (vývojové, výrobní, obchodní i marketingové oddělení), produkty, jejich propagaci atd. Rozhodnutí o změně marketingové strategie je jedním z nejzávažnějších, které firmy dělají a pokud se udělá špatně, může i velkou nadnárodní firmu zlikvidovat, historie zná takových případů řadu.

Už kvůli závažnosti rozhodnutí není možné dát jakoukoli radu "naslepo" bez detailní znalosti firmy, jejího potenciálu postavení na trhu a konkurence. Neexistuje ani žádná univerzálně použitelná strategie. PDQM má zkušenosti, jaké kroky udělat, aby změna business strategie proběhla úspěšně a pro firmu nepředstavovala velké riziko. Se změnou můžeme pomoci, ale jedině v úzké spolupráci s managementem firmy.

Propagace

Samotná propagace, na kterou dotaz v úvodu mířil, je součástí celkové strategie. Má pomoci dostat se a udržet na trzích vytipovaných v rámci strategie. Každý trh a každý produkt vyžaduje svou vlastní metodu propagace. Jinak nabízíte levná jídla z bistra a jinak klenoty Jinak masáže a jinak školení pro firmy. Ani v tomto případě nelze radit bez znalosti strategie a síly firmy.

A upřímně: PDQM pomáhá vytvářet business a marketingové strategie, ale nejsme PR / reklamní firmou a pokud jde o samotnou propagaci na vytipovaném trhu, využíváme partnerů, se kterými dlouhodobě spolupracujeme. Rádi Váš kontakt předáme jim, víme, že na propagaci jsou zkušenými odborníky.

Červenec 2013


Jakou notaci používáte pro popis procesů? BPMN má přes 150 různých symbolů a i technicky zdatný odborník se v modelu ztrácí

Jednoduchou odpovědí je ano, BPMN používáme. Má to však svá ale, o kterých je více v příspěvku o zkušenostech s BPMN. Důležité přitom je, že tam, kde modely v BPMN používáme, uživatele a tvůrce v používání BPMN také školíme.

Červen 2013


Zkoušel jsem ukecat naši novou vedoucí analytiků, aby se dalšímu rozvoji procesů věnovala. Máte nějaké náměty, jak další zlepšování práce analytiků u nás rozhýbat?

Jakékoli zlepšování v organizacích funguje pouze pokud za ním stojí lidé, kteří mají sílu lidi ve firmě přesvědčit, aby změny realizovali. Upřímně, musí to být management, nebo neformální leader skupiny, nikdo jiný ten potenciál nemá. Když za změnou nestojí přesvědčení vedení, je možné změnit konkrétní techniky, ale rozhodně ne návyky a postupy.

Druhá zásada zlepšování je, že lidé musí cítit potřebnost – naprostá většina lidí o změny nestojí, ráda dělá vše zaběhaným způsobem a teprve vědomí, že se řítí do maléru, je přesvědčí, aby změnili směr. Když aktivně pracuji s lidmi, tak základem zlepšení je, aby pochopili, proč je současná praxe problémová. Ostatně je to i správná kontrola práce – pokud by mě osobně nebyla potřeba zlepšení jasná, nemám právo změny navrhovat (nemohu přece zlepšovat něco, co funguje optimálně, nebo nevím, proč to nefunguje). Druhým – a často těžším – úkolem je lidi přesvědčit. Bohužel, řada procesních problémů a následných malérů je totiž toho charakteru, že nepálí zrovna ty, kdo je způsobují (např. špatné hospodářské výsledky, nespokojenost uživatelů nedoléhá na analytiky vždy natolik přímo, aby je skutečně motivovaly).

Třetí podmínkou je vize – musím mít představu, kam se chci zlepšováním dostat. Tuto vizi dáváme dohromady na workshopech v úvodu práce. Nová vedoucí ale vizi nemá (nebo dříve vytvořenou vizi nesdílí). Do jisté míry je to pochopitelné – když převzala tým a odpovědnost za něj, vizi, kam jej chce dostat, si musí teprve vytvořit. Vize se nedají příliš předávat, manažer by měl mít vlastní. K tomu, aby si ji vytvořil, nejvíc pomáhá, když je ve firmě skutečně živá kultura zlepšování; firma se vždy chce někam posouvat, rozvíjet. V takových firmách se od každého manažera očekává, že vizi rozvoje má. (Naopak, firmy, kde tato kultura není. mají manažery zvyklé přežívat, nikoli rozvíjet). Jsme tak opět u odpovědnosti zejména vrcholového vedení, protože tah na rozvoj musí přicházet shora a týká se celé organizace.

Co se dá dělat ve chvíli, kdy se vedoucí rozvoji nevěnuje a problémy neřeší? V podstatě bych doporučil dva přístupy:

  • Artikulovat ve firmě potřebu změny založenou na identifikaci problémů, které nám současný stav způsobuje a důsledků, ke kterým vede. Čím více lidí ochotných problémy řešit si je bude uvědomovat, tím spíše se s nimi bude něco dělat. Je přitom ale nezbytné, když se současně s problémy prezentuje i vize řešení. Bez vize to může vést jenom k šíření "blbé nálady", negativních postojů k práci bez konstruktivního přístupu. V důsledku by to tým rozkládalo.
  • Využít kontaktů na vrcholové vedení, aby od středního managementu vizi rozvoje vyžadoval.

Obojí může pomoci týmu další rozvoj nastartovat ať už pro to využije do budoucna jakékoli metody. PDQM může pomoci s vytvořením vize zlepšování i s její realizací, ale pomoc musí vyplývat ze zájmu vedení; bez toho ke skutečnému zlepšení nedojde.

Březen 2013


Je těžké řídit chytré lidi?

Mám pěkné úsloví: Chytrému poraď, hloupého nakopni. Řídit tým chytrých lidí je velmi odlišná práce, než tým průměrných pracovníků.

S týmem chytrých lidí vedoucí projektu potřebuje především

* Motivovat (přičemž motivuje výzva, existence problému)

* Koordinovat (což bývá složitější, protože chytří lidé častěji pracují "po svém")

* Zajistit zdroje (není závislé na konkrétních lidech)

S průměrnými pracovníky naproti tomu práce vedoucího projektu vyžaduje zejména zajistit

* Motivaci (postavenou většinou na odměně nebo zážitku nesouvisejícím s vlastní prací)

* Vedení krok za krokem (časově velmi náročné)

* Řešení problémů (Všechno je problém a žádný problém se nevyřeší sám)

* Koordinaci na úrovni mikromanagementu

* Účinnou kontrolu kvality

Únor 2013


2012

Naše firma má zaměstnává kolem 15 zaměstnanců. Většinu ze zaměstnanců tvoří dělníci a řidiči stavebních strojů. Předmětem podnikání je stavební činnost, rekultivační činnost a zemědělská činnost. Cílem firmy je si co nejdéle udržet už zaběhlé pracovníky a tím zajistit určitou stálou kvalitu svých poskytovaných služeb.

Chceme zhodnotit, co by nám přinesl a co stál kariérní řád např. od PDQM, co by takový řád obsahoval a podle jakých bodů ho sestavujete.

Předtím, než se pustíme s klientem do přípravy kariérního řádu (KŘ) nebo jakéhokoli jiného organizačního dokumentu, musíme vědět, jaký cíl tím klient sleduje. U KŘ tím je většinou snaha motivovat zaměstnance ke vzdělávání a zlepšování kvalifikace. Na druhou stranu pro KŘ je potřeba, aby organizace mohla nabídnout odpovídající odměnu – nové pracovní možností a příležitosti, postup v organizační nebo profesní hierarchii, růst základního platu spojený s vyšší odpovědností apod.

Obsahem řádu je popis pozic, jejich role, odpovědnosti, kompetence, cíle vzdělávání a rozvoje osobních schopností tak, aby rozvoj byl v souladu s business strategií organizace (tj. byl pro ni užitečný). Za to řád nabízí "benefity" – zajímavější resp. různorodější práci, již zmiňovaný postup v hierarchii organizace po manažerské linii (předák, vedoucí,...) nebo odborné (samostatný pracovník, senior, kouč...) a s tím odpovídající pracovní výhody.

Z hlediska kalkulace ceny je výše uvedená úvaha významná z hlediska posouzení pracnosti přípravy plány. Hlavním kritériem určujícím cenu je počet pracovních pozic, kterých se řád týká, cože podle Vašeho organizačního diagramu bude 5 pozic (ve schématu nejsou výkonní pracovníci – členové čet), naopak pro jednatele, majitele, sekretářky (pardon, asistentky) se většinou nedělá.

16.5.2012


2011

Co pro Vás udělá mentor a kde ho najít?

Otázky jsou dvě:

Co pro vás mentor udělá – kvalitní mentor pomůže překlenout mezeru mezi teorií a praxí. Školení a semináře, byť sebelépe připravené a vedené, dávají pouze teoretický základ, ale začlenění jejich poznatků do praxe je obtížné. Více o tom píšeme v článku o vzdělávání a mentoringu.

Kde ho najít – mentor má vést, být expertem na oblast, kterou mentoruje. Má pomoci s praxí a je proto důležité, aby sám aktivní praxi měl. Vzhledem k tomu, že skutečně efektivní zlepšení pracovních návyků jednotlivců je ideálně spojeno i se změnami pracovních standardů organizace, je žádoucí, když se mentor orientuje i v této oblasti. Bez jejich změny narážejí všechna zlepšení na odpor typu "vždycky to všichni dělali takto".

Při výběru mentora je proto nejlepší hledat člověka s praxí shrnující vlastní odbornou práci, vzdělávání i rozvoj interních procesů.

A kde ho tedy najít? Logicky ve firmách, které se všemi třemi oblastmi zabývají. Pokud máte zájem o pomoc mentora v oblasti business a technických analýz, objektového designu, kvaltního testování, projektového řízení nebo organizačních změn, pak můžete hledat přímo u nás, protože my tyto zkušenosti máme.

17.11.2011


Jaké parametry sledovat u chyb v softwarové aplikaci?

Je snadné vysypat řadu možných parametrů pro sledování testování software, ale je obtížné říct, které jsou kdy vhodné. Rada bez znalosti situace bude téměř jistě neužitečná. Zobrazit celou odpověď – parametry pro sledování testování.

15.02.2011


2010

Můžete doporučit společnost/freelancera na zpracování Corporate Identity? Na co při zadání zpracování CI nezapomenout?

Záleží na tom, pro koho to potřebujete. Menší společnost si s freelance službami jistě vystačí, pro větší společnost bych doporučoval spíš firmu, která má samostatné analytiky, PR specialisty, samostatné grafiky a front-end vývojáře. U takové firmy lze očekávat podstatně větší porozumění tomu, jak jinou organizaci vhodně reprezentovat. V takové firmě jsou lidé, kteří se zaměřují na obsah prezentace, jiní se zaměří na formu a zase jiný na technologii řešení. Když dělá všechno 1 člověk, nelze očekávat ve všech – a to velmi odlišných – směrech stejně kvalitní výsledek ani a/nebo kvalitu specialisty.

Při výběru a v rámci další komunikace bych dával pozor především na porozumění smyslu, principům a cílům organizace. To není vůbec samozřejmé, většina společností se chlubí a i skutečně zaměřuje jenom na SEO resp. "mainstream" internetových i tištěných publikací a jedinečnost organizace samotné je ve skutečnosti v podstatě nezajímá (v lepším případě se zeptají na firemní barvy). Bohužel, naprostá většina prezentací ať už internetových, tak papírových (informační letáky, obálky atd.) se jen velmi málo odlišuje jedna od druhých, protože je snazší vymyslet a klientovi prodat typické řešení, než si lámat hlavu se skutečným kreativním nápadem. A přitom jenom takový má opravdu reprezentační smysl.

Pokud máte čas, tak myslím, že je dobré projít si profily organizací podobného zaměření (ale ne přímo konkurenci), rozmyslet si, jak se která prezentuje a pak ideálně oslovit firmu, která připravila profil, který se vám zdál nejlepší.


Vybíráme dodavatele z oblasti IT. Co nám o něm řeknou certifikáty?

Každý certifikát má své specifika a liší se tím jeho vypovídací hodnota. Otázka je obecná, ale obecná odpověď neexistuje.

Především řada certifikátů je osobních, tj. týkají se konkrétního pracovníka firmy. Mezi takové patří např. ISACA certifikáty, PMP certifikace projektového manažera nebo stupně znalosti ITIL. S mírnou nadsázkou se dá říci, že pokud certifikát nemá z firmy zrovna ten pracovník, který bude řešit váš projekt, je vám informace o certifikátu k ničemu. Není to ale tak úplně: pokud lidé získali certifikáty za dobu svého působení v dané firmě, vypovídá to o jejím zájmu mít kvalitní pracovníky. Pokud se ale firma chlubí osobními certifikáty a nemají je pracovníci, kteří pro vás budou pracovat, asi nejste pro dodavatele zrovna klíčový zákazník.

Zajímavější pochopitelně jsou certifikáty firemní resp. týmové. Patří k dobrému jménu firmy v ČR mít certifikát ISO 9001. Jeho vypovídací hodnota o skutečně kvalitě práce a její organizace je, bohužel, velmi nízká. Právě tím, že se díky pravidlům státní správy stal de facto povinnou výbavou firmy, vypovídá držení tohoto certifikátu ze všeho nejvíc o zájmu firmy účastnit se výběrových řízení a získat za certifikát body navíc. Devalvace hodnoty tohoto certifikátu je smutná, protože samotné myšlenky a požadavky normy jsou rozumné.

Z hlediska IT firem jsou zajímavé zejména certifikáty s přímým vztahem k IT službám: ISO 20000, ISO 17999 a zejména CMMI nebo SPICE či Automotive SPICE. Díky podstatně menšímu rozšíření těchto standardů je i kvalita auditorů a mechanismů certifikace průměrně na výrazně vyšší úrovni než u zmiňované ISO 9000. U všech certifikátů ale úroveň kolísá a všechny mají jednu nepochybnou vlastnost: vyjadřují stav, který byl v minulosti a navíc téměř jistě mírně přikrášlen.

Držení standardu každopádně vyjadřuje schopnost firmy či jednotlivce pracovat s technickým materiálem, přizpůsobit se požadavkům normy a pracovat na sobě. Nesporně vyjadřuje i zájem brát kvalitu a celé podnikání vážně.

Pokud vám záleží na tom, jak dodavatel interně pracuje, je nejlepší si jeho interní standardy ověřit před zahájením spolupráce. Jeden zkušený auditor radí jednoduchou otázku: Zeptejte se, v čem firma pracuje lépe, než před rokem a jakými daty to může doložit. Pokud má skutečně smysluplná data o tom, jak nějaká práce probíhala před rokem, záznamy o tom, kdy a jak ji zlepšili a co to skutečně přineslo, můžete si být jisti, že to s kvalitou myslí skutečně vážně.

2009

Otázky a odpovědi týkající se CMMI klikněte na tuto stránku.


K čemu je nezávislé oddělení jakosti?

Chce se mi odpovědět, že k ničemu. Navzdory tomu, že jej každá velká profesionální firma většinou má. Nezávislé oddělení jakosti, nebo anglicky Independent Quality Group či v terminologii CMM (předchůdce CMMI) SEPG (Software Engineering Process Group) to všechno jsou pozůstatky strnulé liniové organizační struktury 20. století, které fungovaly jako kontrolní orgán nezávislý na výkonných složkách a pokud byl kvalitní, tak kromě interních auditů a řízení výstupní kontroly, pomáhal vrcholovému vedení identifikovat vnitrofiremní problémy a zlepšovat procesy.

Všechny činnosti uvedené v předchozím odstavci jsou jistě užitečné. Nic proti nim nenamítám, doplňuji však jedno podstatné ale: Ale neměla by je dělat nějaká nezávislá, tj. od reality odtržená skupinka úředníků / intelektuáků / policistů / nemakačenků (vyberte si podle své zkušenosti) nýbrž měla by fungovat v rámci normální organizace.

Měl jsem možnost seznámit se s pěkným modelem, jak oddělení kvality organizovat a tento model mi přišel následováníhodný: Ponechme toto oddělení i se všemi jeho fakticky rozsáhlými úkoly a pravomocemi, ale odstraňme z něj všechny stálé pracovníky. Že je to bláznovství? Kdo tu práci udělá? Podívejte se znovu na předchozí odstavec: nezpochybňuji užitečnost činností, ale smysluplnost odtržených pracovníků. A to právě nabízí kouzelné řešení. Oddělení kvality může být plovoucí povinností, na které se podle nějakého deterministického klíče střídají všichni pracovníci firmy včetně vedoucích pracovníků. Náhle jde o pracovní skupinu, jakých jistě máte ve firmě řadu, která solní své úkoly, předá je a žezlo s dalšími úkoly vezmou noví lidé. Díky tomu, bude mezi všemi převládat pragmatický, odborný náhled na problémy a řešení a můžete se spolehnout, že např. navržená zlepšení budou téměř jistě použitelná a změny procesů budou určitě efektivnější, než když je vymýšlení teoreticky fundovaní "kvalitámři, kteří vědí, že podle těch procesů nikdy sami pracovat nebudou. Když vymýšlíte práci, která ale nejde za vámi ani za vašimi penězi, můžete se úžasně rozmáchnout a navymýšlet takových činností, že z toho výkonným i řídícím pracovníkům půjde hlava kolem.

K čemu že tedy to oddělení kvality je? Ano jistě, aby dbalo na kvalitu. Ale aby to dělalo kvalitně, musí to dělat lidé, kteří rozumí skvěle celé práci a jejím problémům. A to jsou nejlépe ti, kdo ji přímo vykonávají. Mějte tedy oddělení kvality naplněné lidmi, kteří tu práci dělají. Že vám to něco připomíná? Ale ano, jistě; jde přece o všem světa znalým dobře známé pracovní skupinky z TQM zajišťující – Kaizen, stálé zlepšování. Všechny modely jakosti od ISO 9000 až po CMMI tak znovu objevují něco, co TQM zná již desítky let. I když spíš než modely, tak ti opravdoví kvalitáři, kterým záleží na tom, aby jejich práce byla pro firmu skutečným přínosem.


Zdravím, můžete nám podle standardů doporučit, jak vést provozní deník k serveru?


Potřebovali bychom nějaké informace o "typických" velikostech aplikací v nějakých strojově měřitelných metrikách (SLOC, class count, nesting depth, atd.).