Pondělní ráno. Majitel firmy má za sebou víkend a před sebou týden, o kterém skoro nic neví. Otevře kalendář: devět hodin schůzek, z nichž šest jsou statusy. Každý tým mu řekne, co dělá. On to zapíše. Ve středu to udělá znovu.
Práce, kterou nikdo nechce dělat
Statusová schůzka je drahá forma přenosu dat. Obchodní ředitel ví, kde je pipeline. Projektová manažerka ví, které úkoly visí. Účetní ví, co se nezaplatilo. Jenže tato data sedí v různých systémech a majitel k nim nemá přímý přístup, takže se musí ptát lidí. Lidé mu odpoví. On to vezme na vědomí. A za týden se to zopakuje.
Výzkumy konzistentně ukazují, že manažeři tráví nadpoloviční část pracovního týdne na schůzích, přičemž velkou část tvoří právě statusové updaty. Problém přitom není v lidech, kteří reportují. Problém je v tom, že data nejsou dostupná bez zprostředkovatele.
"Zavolal jsem obchodníkovi, aby mi řekl, co je v CRM. Přitom jsem tam mohl kouknout sám, kdybych věděl, jak to přečíst dohromady s projekty a fakturami."
— Majitel výrobní firmy, 18 zaměstnanců, situace ilustrativní
Co "propojená data" ve skutečnosti znamenají
AI stack staví MCP servery: malé, zaměřené mosty mezi Claudem a systémy, které firma už provozuje. Každý server nese identitu uživatele, který se ptá. Claude vidí přesně to, co by viděl manažer, kdyby sám otevřel Pohodu, Freelo a Raynet najednou a uměl to přečíst najednou. Žádná kopie dat, žádný centrální sklad, žádný nový systém k zavedení.
Výsledek není dashboard. Dashboard se musí otevřít, pochopit a interpretovat. Výsledek je odpověď na otázku. Manažer napíše: "Co se minulý týden nestihlo a kde to brzdí cashflow?" Claude přečte úkoly, faktury a pipeline a odpoví konkrétně. Schůzka odpadne.
Konkrétně: Freelo, Raynet a Pohoda
Typická česká firma s desítkou až třiceti lidmi má projekty ve Freelu nebo Asaně, obchodní příležitosti v Raynetu nebo Pipedrivu a faktury v Pohodě nebo Fakturoidě. Tři systémy, tři přihlášení, tři různé logiky. MCP server pro každý z nich přidá most. Freelo zůstane Freelemu, Pohoda zůstane Pohodě. Bridge se přidá vedle, ne místo.
- Claude se zeptá Freela: které úkoly jsou po termínu a kdo je má přiřazené.
- Claude se zeptá Raynetu: které příležitosti jsou ve fázi "čeká na odpověď" déle než deset dní.
- Claude se zeptá Pohody: které faktury jsou po splatnosti a o kolik dní.
- Claude sestaví souhrn: tři odstavce, konkrétní čísla, konkrétní jména projektů.
- Manažer dostane odpověď za třicet sekund. Schůzka nebyla potřeba.
Majitel e-shopu s osmnácti zaměstnanci by mohl každé pondělí ráno napsat jednu zprávu a dostat přehled o stavu skladu (z e-shopového systému), otevřených objednávkách (z CRM) a nezaplacených fakturách (z Pohody). Ilustrativní odhad: to, co teď zabere hodinu schůzky a půl hodiny zápisu, by zabralo pět minut čtení.
Co AI reporting neudělá a proč je to dobře
Claude neví, jestli má projekt X prioritu před projektem Y. Neví, jestli zákazník, který nezaplatil, je klíčový partner nebo zapomětlivý plátce. Neví, jestli obchodník, který má pipeline zatuhlou, potřebuje pomoc nebo prostor. Tato rozhodnutí vyžadují kontext, který není v datech.
To je záměr, ne omezení. Souhrn má informovat, ne řídit. Manažer dostane přesný popis situace a pak se rozhodne. Zodpovědnost se nepřenáší na systém. Přenáší se jen rutinní sběr informací, který dřív stál lidský čas.
Co by to vyžadovalo
Tři MCP servery: jeden pro projektový nástroj, jeden pro CRM, jeden pro účetnictví. Každý nese oprávnění manažera, běží na infrastruktuře firmy, ne na naší. Žádná data neopouštějí firemní prostředí. Audit log zaznamenává každý dotaz. Jedno odpoledne nastavení, pak funguje denně.
Co zbyde
Model není úzké hrdlo. Claude umí přečíst a shrnout data z Freela, Raynetu i Pohody v jedné odpovědi. Úzké hrdlo je to, že tato data nejsou Claudovi dostupná. Schůzka je drahý způsob, jak obejít chybějící infrastrukturu.
Napište nám. Krátký hovor, projdeme, které systémy firma používá a co by stálo propojit jako první.