Údaj „na sklade“ ešte nehovorí, koľko materiálu môžete použiť na novú zákazku. Časť zásoby už môže byť rezervovaná, ďalšia blokovaná a očakávaná dodávka môže meškať.
AI vie nákupcovi pomôcť tieto podklady spojiť a vysvetliť. Potom môže pripraviť návrh ďalšieho kroku. Výpočet dostupnosti, nákupné pravidlá a právo objednať však potrebujú pevné miesto v systéme. Užitočný asistent je súčasťou tohto procesu, nie jeho náhradou.
Od chýbajúcej zásoby k rozhodnutiu
- Systém načíta podklady Zásoba, rezervácie, dodávky a termíny
- AI vysvetlí riziko Ukáže zdroje a chýbajúce údaje
- Pripraví sa návrh Množstvo, alternatívy a dôvod
- Nákupca rozhodne Potvrdí, upraví alebo odmietne
- ERP vykoná schválený úkon Výsledok zostane dohľadateľný
Dostupnosť má rovnaký význam pri každej otázke
Výpočet zásoby patrí do dohodnutých pravidiel ERP. Inak by odpoveď závisela od toho, ako nákupca otázku položí. AI môže použiť výsledok výpočtu a vysvetliť, prečo konkrétna zákazka nemá materiál.
Ilustračný príklad: výroba potrebuje 120 kusov. Na sklade je 90, z toho 40 rezervovaných. Bez ďalších blokácií je voľných 50. Ďalších 50 je na ceste, ale dátum ich príchodu zatiaľ nikto nepotvrdil.
Takýto súhrn pomôže nákupcovi vidieť problém. Ešte z neho nevyplýva konečné nákupné množstvo: záleží na termíne spotreby, alternatívach a minimálnej objednávke. Odpoveď má preto ukázať aj čas aktualizácie a zdroje údajov.
Fyzická zásoba nie je voľná zásoba
Prvý proces môže začínať ranným prehľadom
Zoznam zákaziek ohrozených materiálom má jasné využitie. Nákupca z neho rozhodne, kde treba objednať, preveriť dodanie alebo zatiaľ počkať. Výsledok sa dá skontrolovať.
Takto ohraničená prvá verzia nepotrebuje predpovedať celý sklad ani vyjednávať s dodávateľmi. Najprv má dobre využiť údaje, ktoré firma už má, a ukázať tie, ktoré chýbajú.
Do pilotu patria aj blokovaná zásoba a zmenená spotreba. Práve pri nich sa ukáže, či vysvetlenie pomáha pri rozhodnutí a neponúka iba uhladený súhrn bez podstatných súvislostí.
Schválenie platí pre konkrétny návrh
Nákupca potrebuje vidieť dodávateľa, množstvo, cenu, termín a dôvod. Ranný návrh pritom nemusí byť platný popoludní, keď kolega už objednal materiál alebo dodávateľ zmenil podmienky.
Pred vykonaním sa preto porovná aktuálny stav s tým, čo človek schválil. Podstatná zmena môže vyžadovať nové rozhodnutie. Táto kontrola má byť v systéme, aby platila pre formulár aj AI nástroj.
Nákupné pravidlá navyše sledujú viac než sumu: rozpočet projektu, typ nákupu či povoleného dodávateľa. Proces potrebuje aj cestu po zamietnutí a zastupovanie počas dovolenky, inak zostane stáť na jednom človeku.
Dokument od dodávateľa nie je pokyn pre asistenta
AI môže spracúvať e-mail, cenovú ponuku alebo prílohu. Taký obsah je vstupný údaj. Nemá právo meniť oprávnenia asistenta, vypínať schvaľovanie alebo určovať, kam systém odošle firemné údaje.
Pri návrhu oddeľte čítanie dokumentov od vykonávania operácií. Text ponuky môže pomôcť vyplniť položky návrhu. Systém potom údaje overí voči pravidlám a používateľ vidí ich pôvod. Neznáma hodnota má zostať označená na kontrolu.
MCP bezpečnostné odporúčania opisujú riziká pri prepájaní AI s nástrojmi vrátane práce s nedôveryhodnými vstupmi. Samotné použitie protokolu tieto riziká neodstraňuje. Pri nákupe preto potrebujete konkrétne kontroly nad dostupnými nástrojmi a ich oprávneniami. Bezpečnostné odporúčania MCP
Ponuka dodávateľa vstupuje ako údaj
- E-mail a príloha Cena, položky a podmienky dodávateľa
- Návrh od AI Údaje so zdrojom; neisté hodnoty na kontrolu
- Pravidlá nákupu Dodávateľ, jednotky, rozpočet a oprávnenia
- Rozhodnutie nákupcu Potvrdí presný návrh pred vykonaním
Asistent potrebuje práva podľa svojej úlohy
Prvý asistent často potrebuje len čítať zásoby a pripraviť návrh. Nemusí mať právo meniť skladové pohyby, zakladať dodávateľov ani potvrdzovať objednávky. Takto obmedzený rozsah sa jednoduchšie overuje aj prevádzkuje.
MCP môže sprístupniť AI aplikácii pomenované nástroje nad vašimi systémami. Užitočný názov je napríklad „priprav nákupnú požiadavku“. Všeobecný nástroj na ľubovoľnú úpravu ERP vytvára oveľa širšiu právomoc, než tento scenár potrebuje. Úvod do MCP
Pri demonštrácii požiadajte o nepovolenú operáciu. Skúste objednávku pre pobočku, ku ktorej používateľ nemá prístup. Dodávateľ má ukázať odmietnutie systémom, nie iba slušnú odpoveď asistenta. Oprávnenia musia platiť aj pri neobvyklej formulácii požiadavky.
Kto má robiť ktorú časť práce
| AI | Systémové pravidlá | Človek | |
|---|---|---|---|
| Zhrnutie podkladov | Pripraví vysvetlenie so zdrojmi | Poskytne overené údaje | Overí sporné prípady |
| Výpočet dostupnosti | Použije výsledok výpočtu | Vypočíta podľa dohody | Schváli význam pravidiel |
| Návrh nákupu | Pripraví možnosti | Overí povolené hodnoty | Posúdi dôsledky |
| Záväzná objednávka | Len v dovolenom rozsahu | Overí práva a stav | Schváli podľa pravidiel firmy |
Úspora zahŕňa aj čas na kontrolu
Rýchlo vytvorený súhrn nepomôže, ak nákupca každý údaj znova hľadá v ERP. Do porovnania s pôvodnou prácou preto patrí zber podkladov, kontrola aj rozhodnutie.
Opravené návrhy zároveň ukazujú, kde hľadať príčinu. Zlá rezervácia potrebuje opravu dát, nesprávne vysvetlenie úpravu asistenta. Lepší prompt sám nevyrieši chybnú evidenciu.
Prínos sa dá posúdiť podľa času do rozhodnutia a počtu opráv pri porovnateľnom objeme práce. Týždeň s menším nákupom by bez tohto kontextu vytvoril príliš optimistický obraz.
Niekedy je správnym výsledkom zastavenie
Pilot nehodnoťte iba podľa správne pripravených požiadaviek. Vyberte aj prípady, pri ktorých je správnym výsledkom zastavenie. Napríklad chýba potvrdenie dodávateľa, množstvo má inú jednotku alebo nákup prekračuje oprávnenie používateľa. Každý taký prípad má mať jasné vysvetlenie a cestu na vyriešenie.
Osobitne otestujte zastaraný návrh. Nákupca ho nechá otvorený, kolega medzitým materiál objedná a prvý človek sa neskôr vráti k schváleniu. Systém má pred zápisom skontrolovať aktuálny stav. Nestačí, že AI pri pôvodnej odpovedi použila vtedy správne údaje.
Ďalšia skúška overí opakované kliknutie alebo stratené potvrdenie. Jedno schválenie nesmie nepozorovane vytvoriť dve rovnaké požiadavky. Používateľ potrebuje vedieť, či operácia prebehla, čaká alebo zlyhala. Tento výsledok má zostať dohľadateľný aj bez otvorenej konverzácie s asistentom.
Nakoniec si nechajte vysvetliť postup pri nesprávnom návrhu. Kto ho môže stiahnuť, kto opraví podklady a ako sa prípad vráti do spracovania? Použiteľný pilot nie je taký, ktorý nikdy neukáže chybu. Je taký, v ktorom chyba nevytvorí nepozorovaný záväzok a tím ju vie opraviť dohodnutým postupom.
- Vy: Dokončite nákup podľa ranného návrhu.
- Kontrola ERP: Overím aktuálnu zásobu, otvorené požiadavky a verziu návrhu.
- Výsledok: Kolega už založil nákupnú požiadavku. Ranný návrh nezodpovedá súčasnému stavu.
- AI: Novú požiadavku som nevytvoril. Otvorím existujúcu a pripravím zvyšnú potrebu na kontrolu.
- Človek: Nákupca posúdi nový stav pred ďalším schválením.
Prečo tento proces často patrí do vlastnej vrstvy
Nákupné pravidlá, rezervácie a kompetencie sa medzi firmami líšia. Hotová AI funkcia môže pomôcť so súhrnom, no váš postup schvaľovania potrebuje presnejšie prispôsobenie. Vlastná vrstva umožní spojiť tieto kroky do jedného zrozumiteľného procesu.
Existujúce ERP môže ďalej spravovať dohodnuté evidencie. Vlastný softvér nad ním pridá podklady, návrhy, kontroly a jasné odovzdanie práce. Investujete do časti, kde dnes vzniká najviac ručného dohľadávania a neistoty.
Pri schvaľovaní je užitočný najprv spoľahlivý základ procesu. Transfer International napríklad rozlišuje žiadosť o preddavok a jej schválenie pracovníkom. Možnosti vlastných pracovných postupov nájdete pri interných systémoch a automatizácii; AI sa k nim pridáva podľa konkrétnej úlohy.
Navrhnime jeden nákupný proces s AI. Začneme tým, čo má človek rozhodnúť, aké údaje potrebuje a ktoré operácie musí systém spoľahlivo obmedziť.
