Případové studie MMS

Řízení projektů a provozních agend v Microsoft 365

Výchozí stav

• Organizace realizuje několik centrálních projektů a současně několik menších provozních.

• Pro práci intenzivně využívá Microsoft 365 – zejména Planner, e-mail, Teams, SharePoint a OneNote.

• Nástroje fungují, ale práce probíhá napříč aplikacemi a postrádá jednotící strukturu.

• Dokumenty uložené napříč úložišti bez jasné vazby na projekty a agendy .
• Duplicitní soubory, paralelní komunikace v e-mailu a Teams.
• Velmi nízká orientace v aktuálním stavu projektu.

Problém

V průběhu projektu se začaly projevovat limity běžného využití Microsoft 365:

• dokumenty uložené v různých knihovnách bez jasné vazby na rozhodnutí
• úkoly v Planneru oddělené od kontextu projektu
• klíčová komunikace rozptýlená mezi e-mailem a Teams
• poznámky v OneNote bez návaznosti na konkrétní kroky
• paralelní verze dokumentů

Orientace v aktuálním stavu projektu vyžadovala neustálé přepínání mezi aplikacemi. 
Vznikaly nejsanosti, které vyžadovali pravidelné koordinační schůzky a vše vedlo k časovému skluzua frustraci. 
Microsoft 365 poskytoval nástroje, ale ne jednotný systém řízení projektu

Řešení

MMS je zde v roli jako sjednocující aplikační vrstva které rozšiřuje Microsoft 365.

• Projekty a agendy jsou převedeny do strukturované agendy.
• Vazba záznamu → dokumenty → schvalování → odpovědné role.
• Centralizovaný dashboard místo přepínání mezi aplikacemi.
• Eliminace duplicit díky řízené evidenci
• Úkoly nejsou izolované položky, ale součást řízeného kontextu.
• Vedení získalo dashboard nad stavem projektu bez nutnosti přecházet mezi aplikacemi.

M365 zůstává technologickým základem, ale řízení probíhá v jednom prostředí.

Výsledek

• Jeden zdroj pravdy pro celý projekt
• Eliminace duplicitních dokumentů
• Zkrácení času potřebného k orientaci v projektu
• Jasně definovaná odpovědnost
• Přehledný stav plnění úkolů

Nahrazení Excel-ového procesu řízení přeprav

Výchozí stav

Organizace realizuje speciální přepravy mezi výrobními závody. Proces byl dlouhodobě postaven na sdíleném Excelu doplněném e-mailovou komunikací. Excel sloužil jako hlavní evidenční nástroj pro zadávání, sledování i schvalování přeprav.

• Speciální přepravy řešeny e-mailem a tabulkami.
• Komunikace mezi závody bez jednotného systému.
• Papírové schvalování.
• Obtížná dohledatelnost pro audit.

Problém

Cílem bylo nahradit stávající proces, který nesl všechny typické znaky řízení postaveného na Excelu:

• ruční přepisování dat
• paralelní verze souborů
• chybějící kontrola povinných údajů
• nejasný aktuální stav požadavku
• omezená dohledatelnost historie změn
• vysoká závislost na konkrétním uživateli
• nemožnost efektivního filtrování a reportingu
• pomalá orientace při větším počtu záznamů

Z pohledu systému chybělo workflow. 
Z pohledu uživatelů vznikaly chyby, duplicity a nejasnosti.
Z pohledu managementu nebyl dostupný okamžitý přehled.

Excel fungoval jako tabulka, nikoliv jako řídicí proces.

Řešení

V MMS byl vytvořen specializovaný modul pro řízení speciálních přeprav:

• strukturovaný vstupní formulář s validací dat
• jasně definovaný stavový model (zadání → kontrola → schválení s eskalcí → realizace → uzavření)
• workflow schvalování napříč závody
• automatické notifikace odpovědným osobám
• kompletní historie změn a rozhodnutí
• možnost filtrování a exportů
• reportingu a přehledu podle lokality, typu přepravy či stavu
• importní / exportní SAP data  

Proces byl převeden z tabulky do řízeného systému s inetgrací na další systémy.

Přínos

• eliminace paralelních verzí a duplicit
• snížení chyb způsobených ručním přepisem
• výrazné zrychlení orientace v historii přeprav
• transparentní odpovědnost mezi závody
• připravenost na audit

Speciální přepravy přestaly být evidencí v souboru a staly se řízeným procesem s kontrolovaným tokem informací.

Automatizace řízeného nástupů a změn zaměstnanců
s distribuovanou odpovědností a automatizací přístupů

Výchozí stav

Organizace potřebovala řídit nástupy, interní změny a výstupy zaměstnanců napříč více odděleními a aplikačními systémy.

Proces zahrnoval:

• nadřízené pracovníků
• liniové manažery
• BU vlastníky aplikací
• HR jako vlastníka procesu
• IT jako garanta bezpečnosti

Součástí bylo napojení na evidenční databázi pracovníků a správa pozic, profilů a aplikačních sad.

Problém

Před zavedením řešení byl proces částečně manuální a nekoordinovaný:

• odpovědnosti nebyly systematicky rozděleny podle relevance
• změny rolí neznamenaly automatickou změnu oprávnění
• přístupy byly nastavovány izolovaně podle jednotlivých žádostí
• onboarding byl zbytečně pomalý
• při změnách vznikaly prostoje
• neexistoval centrální přehled otevřených případů
• reporting byl omezený

HR ani IT nemohly efektivně řídit celý proces - řešily pouze své dílčí části.
Rozhodující odpovědnost však ležela u manažerů a vlastníků aplikací.

Chyběl systém, který by tento model řízení podporoval.

Řešení

V MMS byl vytvořen role-based proces řízení zaměstnaneckého cyklu:

• centrální evidence pracovních pozic a profilů
• definice aplikačních sad a oprávnění podle role
• automatizované řízení přístupů do systémů a zařízení na základě přiřazeného profilu
• workflow rozdělené podle relevance odpovědnosti
• nadřízený schvaluje potřebu role
• BU vlastník potvrzuje aplikační přístup
• HR spravuje proces jako jeho vlastník
• IT garantuje bezpečnostní část a kontrolu přístupů
• napojení na evidenční systém pracovníků
• reporting a přehledy o stavu případů a přístupových oprávnění

Proces nebyl centralizován do HR nebo IT -  byl řízen distribuovaně podle kompetencí.

Přínos

• zrychlení nástupů a změn rolí
• minimalizace provozních prostojů
• automatizované a konzistentní řízení přístupů
• jasná odpovědnost podle role v organizaci
• plný přehled o tom, kdo má jaká oprávnění a z jakého důvodu
• připravenost na audit a bezpečnostní kontrolu

HR zůstává vlastníkem procesu.
IT zajišťuje bezpečnost.

Odpovědnost za oprávnění odpovídá organizační struktuře.
Proces se tak stal řízeným systémem, nikoli administrativní koordinací.

Zavedení řízení výrobních změn a technických požadavků s vlastními rozhodovacími maticemi

Výchozí stav

Výrobní organizace potřebovala řídit široké spektrum technických a provozních požadavků, zejména v oblastech:

• změnové řízení ve výrobě (engineering changes)
• správa strojů a zařízení během jejich životního cyklu
• přesuny, uskladnění a vyřazování majetku
• kontrolní a inspekční procesy
• provozní a organizační změny středisek

Každá oblast měla vlastní logiku rozhodování a odlišné schvalovací role.
Historicky byl proces řízen kombinací Accessu, Excelu a e-mailové komunikace.

Problém

Původní model vykazoval strukturální slabiny:

• roztříštěná evidence podle typu požadavku
• absence jednotného stavového modelu
• nejednotná rozhodovací pravidla
• chybějící formální schvalovací matice
• omezené validace vstupních dat
• slabé napojení na existující datové zdroje
• manuální reporting
• obtížná auditní dohledatelnost

S rostoucím počtem požadavků přestával být proces řiditelný jako celek.
Access a Excel evidoval položky, ale neposkytoval řízení toku odpovědností.

Řešení

V MMS byl vytvořen jednotný rámec řízení technických a výrobních požadavků, který umožňuje:

Tematické členění požadavků:
Požadavky jsou rozděleny do logických oblastí (změny, majetek, kontroly, provozní zásahy), přičemž každá má vlastní strukturu a pravidla.

Individuální rozhodovací matice podle oblastí :

• definované role schvalovatelů
• sekvenční nebo paralelní schvalování
• podmíněné větvení procesu
• jasně určenou odpovědnost

Datovou integraci a kontrolní mechanismy:

• napojení na interní datové zdroje (např. stroje, střediska, ERP)
• automatické notifikace dle stavu
• validační pravidla vstupních údajů
• kontrolu úplnosti dat
• exporty a přehledy pro reporting

Transparentní stavový model:
Každý požadavek prochází řízenými fázemi od zadání po uzavření, s plnou historií rozhodnutí.

Přínos

• sjednocení výrobních a technických požadavků do jednoho řízeného systému
• standardizace rozhodovacích pravidel
• zrychlení reakční doby při změnách
• snížení administrativní zátěže
• plná auditní dohledatelnost
• centrální reporting napříč výrobou

Řízení změn a majetku se posunulo z izolovaných evidencí do strukturovaného governance rámce podporujícího výrobu, kvalitu i management.

Postupný přechod na MMS + řízený model zavádění

Tento Use Case není o konkrétní agendě.
Je o modelu řízení změny a zavádění platformy bez zbytečného transformačního rizika.

Výchozí stav

Customer Prototype (PoC / MVP) - organizace potřebuje převést klíčové agendy do jednotného systému, ale odmítala:

• rozsáhlou jednorázovou implementaci
• dlouhé analytické fáze bez reálného výstupu
• závislost na dodavateli bez interní kontroly nad návrhem

Cílem je ověřit řešení v praxi a minimalizovat riziko špatného zadání.

Problém

Typická rizika podobných projektů:

• přeceňování rozsahu v úvodní fázi
• nejasně definovaný scope
• pozdní odhalení procesních nedostatků
• vysoké náklady při změnách během implementace
• oddělení návrhu od reálné praxe uživatelů

Organizace potřebovala model, který umožní:

• ověřit funkčnost
• zapojit klíčové uživatele
• řídit rozsah
• postupovat iterativně

Bez kontrolovaného rámce by projekt nesl vysoké transformační riziko.

Řešení

Ověřený třífázový model řízené implementace:

1. Customer Prototype (PoC / MVP) 
Zákazník připravil základní prototyp agendy v rámci platformy.

• strukturu dat
• logiku workflow
• uživatelské scénáře

Cílem je ověřit dosažení požadovaného řešení.
Bez rozsáhlé customizace. - bez rozsáhlé customizace.

2. ASAP EM Support
Poskytujeme průběžnou podporu:

• architektonickou validaci
• technickou podporu
• doporučení best practices

Cílem kontrola kvality návrhu bez ztráty flexibility.

3. Přechod z prototypu do produkčního rámce
Po ověření funkčnosti:

• je  definován produkční rozsah řešení
• je vymezena hranice mezi standardní funkčností (CORE) od požadovaných rozšíření
• rozhodnut a implemetace individuálních úprav
• řešení je stabilizováno pro dlouhodobý provoz

Implementace tak probíhá na základě ověřeného návrhu, nikoli teoretické analýzy.

Přínos modelu

• minimalizace implementačního rizika
• jasně definovaný scope
• zapojení klíčových uživatelů od začátku do tvorby
• omezení nákladných změn v pozdější fázi
• udržitelná architektura bez neřízených customizací

Místo jednorázové transformace vzniká řízený evoluční proces, který je predikovatelný, škálovatelný, opakovatelný napříč dalšími oblastmi a s nízkou křivkou organizační zátěže.