O aplicație AI care funcționează în cadrul unei singure echipe atinge la un moment dat limita acelei echipe. Un rezumat realizat de departamentul de marketing trebuie să poată fi citit de departamentul de vânzări. Un semnal apărut în serviciul clienți trebuie să ajungă la departamentul de produs. De îndată ce se întâmplă asta, nu mai este o întrebare despre model sau despre prompt, ci despre modul în care departamentele interacționează atunci când ceva se deplasează între ele care nu a existat înainte.
Experiența ferestrei de chat dă impresia că AI este ceva folosit de o singură persoană pentru a îndeplini o singură sarcină. Sub acea fereastră se află o altă realitate, mai ales de îndată ce munca se extinde peste mai mult de un departament. Cine configurează un lanț în care etapele se succedă descoperă că fiecare transfer între departamente este un punct în care ceva se poate bloca: un format care nu se potrivește, o responsabilitate pe care nimeni nu o revendică, un sistem pe care un departament îl are, iar altul nu.
Coordonarea între departamente presupune trei lucruri care nu depind de modelul folosit.
Departamentele folosesc adesea aceleași cuvinte pentru lucruri diferite. Un lead înseamnă la marketing altceva decât la vânzări. O plângere este clasificată diferit de serviciul clienți față de departamentul de produs. Cât timp aplicațiile AI rămân în cadrul unui singur departament, această diferență nu se observă. De îndată ce rezultatul unui departament devine intrarea pentru altul, diferența devine o perturbare. Acest lucru este valabil mai ales pentru munca care se bazează pe text și conversație: cine citește și rezumă documente pentru un alt departament trebuie să știe care termeni au acolo un alt sens, iar cine înregistrează și urmărește conversații trebuie să știe cine preia urmărirea de îndată ce conversația atinge un alt departament.
O aplicație care se oprește la limita unei echipe rămâne în cadrul mandatului acelui șef de echipă. De îndată ce aplicația traversează mai multe departamente, acel mandat nu mai este suficient. Trebuie să existe cineva care poate decide dincolo de limitele departamentelor: cine face care etapă, cine este responsabil dacă ceva merge greșit, cine decide dacă aplicația este ajustată. Fără această persoană, fiecare departament continuă să arate spre celălalt. Acesta este unul dintre motivele pentru care un demo fără proprietar nu produce niciun rezultat: un demo arată că ceva poate funcționa, dar nu spune nimic despre cine supraveghează colaborarea între departamente de îndată ce începe munca reală.
Departamentele își construiesc de obicei propriile sisteme, cu propriile presupuneri despre unde se află datele și cine are acces la ele. Coordonarea între departamente presupune ca aceste sisteme să poată comunica între ele, sau să existe un strat intermediar care poate face acest lucru. Nu este o chestiune de dorință; este o chestiune de ce există deja. O organizație în care fiecare departament și-a construit propriul sistem izolat are o sarcină diferită față de o organizație cu un fundament comun. Această diferență devine vizibilă de îndată ce munca implică agenți care execută efectiv etape: ce puteți face cu agenți care execută munca depinde de faptul dacă acel agent are la departamentul A același acces și aceleași reguli ca la departamentul B.
Un proiect pilot care se desfășoară în colțul unei singure echipe nu arată niciodată unde se blochează coordonarea între departamente, pentru că acea coordonare nu este niciodată testată. Proiectul pilot pare să reușească, iar întrebarea ce se întâmplă de îndată ce este conectat un al doilea departament rămâne fără răspuns până în momentul în care ceva merge greșit. Cine dorește să știe dacă un proiect pilot care funcționează doar în colțul său produce vreun rezultat trebuie să privească exact acel transfer: nu la ce se întâmplă în cadrul unui singur departament, ci la ce se întâmplă în momentul în care munca depășește departamentul.
Coordonarea între departamente este un strat dependent. Funcționează abia atunci când elementele fundamentale sunt în ordine: o organizație care știe cine este responsabil pentru ce, o infrastructură IT care poate conecta departamentele, și un management al datelor care asigură că ceea ce înregistrează un departament are sens pentru celălalt. Fără această bază, orice tentativă de coordonare între departamente este o reparație ulterioară, iar acea reparație costă mai mult timp decât aplicația în sine.
Dacă organizația dumneavoastră este pregătită pentru coordonarea între departamente nu este ceva ce puteți deduce din aplicația în sine. Depinde de modul în care este organizată organizația, ce sisteme comunică deja între ele, și dacă există cineva care poate decide dincolo de limitele unui departament. Măsurarea maturității de la hybridresourcing.com evidențiază acest lucru: cinci niveluri pe șapte dimensii, cu o rundă de evaluare în care mai multe persoane din organizație acordă scoruri separat, astfel încât dispersia dintre departamente devine vizibilă înainte ca acea dispersie să devină o problemă în practică. Instrumentul este în construcție; cei care doresc să îl folosească se pot înscrie pe lista de așteptare.
Această pagină descrie ce presupune coordonarea între departamente pentru a putea fi susținută. Ce parte din munca propriu-zisă poate fi preluată de AI, pe sarcină și pe departament, este o altă întrebare. Aceasta este calculată de scanul de muncă al FTE TO AI.
Vraag maar wat er moet staan voordat AI in uw organisatie kan landen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.