Ghid operator pentru sop-creator

Ce face

sop-creator transformă material operațional dezordonat — notițe brute, transcripturi, screenshoturi, înregistrări, fotografii cu notițe sau un SOP vechi — într-o procedură repetabilă și auditabilă.

Output-ul corect nu este un text „curățat”, ci un document controlat: un singur owner Accountable, roluri numite, precondiții, pași executabili, verificări, rollback pentru schimbări de stare, failure modes și un registru vizibil de presupuneri. Dacă lipsește informație, skill-ul trebuie să o marcheze ca presupunere sau ca input necesar. Nu are voie să o îngroape într-o propoziție frumoasă. Așa mor procedurile. Elegant, dar inutil.

Ghidul acesta face parte din All guides.

Când îmi folosește

Folosește sop-creator când ai semnal operațional, dar nu ai încă procedură. Exemple: ai notițe dintr-un call, un transcript în care cineva explică procesul, screenshoturi ale unui tool, o listă veche de pași sau un SOP depășit care trebuie refăcut.

Este potrivit pentru taskuri repetabile, executate de mai multe persoane, predate unui coleg nou sau folosite într-un context unde trebuie să dovedești ce s-a făcut. Pentru cereri mici, cu un singur rol și sub aproximativ zece pași, poate produce un checklist scurt. Pentru procese cu mai multe roluri, pași ireversibili, risc operațional, legal, financiar, compliance sau public, trebuie tratat ca SOP complet.

Nu îl folosi pentru politici, strategii, job descriptions sau idei vagi fără acțiuni discernabile. Dacă inputul este prea subțire, comportamentul corect este să ceară 2–3 întrebări țintite, nu să fabrice proces din ceață.

Cum îl invoc / declanșez

Nu există o comandă publică universală garantată. Invocarea depinde de mediul în care rulează. Declanșatorul este cererea explicită de a transforma material brut într-un SOP, procedură, proces documentat sau checklist.

Formulări naturale: „fă un SOP din notițele astea”, „transformă asta într-o procedură”, „scrie procedura pentru acest proces”, „fă-mi un checklist pentru pașii ăștia” sau „actualizează SOP-ul vechi”. Acestea nu sunt API stabil; sunt intenții conversaționale.

La intake, dă materialul brut, scopul procedurii, limba documentului, audiența, rolurile cunoscute, sistemele implicate, precondițiile, verificările, pașii de rollback și constrângerile. Pentru screenshoturi sau înregistrări, etichetele vizibile din interfață trebuie folosite literal. Dacă un buton, meniu sau câmp nu se vede, se marchează ca lipsă. Nu se ghicește UI-ul din memorie.

Exemplu practic

Ai un transcript despre publicarea unei note operaționale. Persoana explică pașii amestecat: cine pregătește conținutul, cine aprobă, unde se publică, cum se verifică formatul și ce se face dacă publicarea e incompletă.

sop-creator trebuie să reconstruiască fluxul într-un document executabil: scop, owner Accountable unic, roluri, precondiții, pași cu verbe imperative, puncte de decizie, verificări între faze, rollback pentru pașii care schimbă stare și tabel de failure modes. Dacă transcriptul nu spune cine aprobă finalul, apare ca ❓ NEEDS INPUT. Dacă skill-ul a completat un pas mecanic evident, apare ca ⚠️ ASSUMED. Diferența contează. Una e inferență controlată, cealaltă e ficțiune procedurală.

Output / unde aterizează

Pentru un checklist scurt, output-ul trebuie să fie lean: titlu, owner sau rol unic, precondiții, pași numerotați și o linie de presupuneri dacă a fost completat ceva.

Pentru un SOP complet, output-ul trebuie să includă cel puțin: titlu, versiune, dată efectivă, owner Accountable unic, approver dacă există, scop, scope, roluri, definiții unde e cazul, prerequisites, procedură pe faze, gates de verificare, rollback sau puncte de no return pentru schimbări de stare, troubleshooting/failure modes, criterii de succes, evidență păstrată și assumptions/gaps.

Destinația fișierului nu este garantată public. În unele medii poate fi returnat în conversație; în altele poate fi salvat într-un spațiu configurat. Nu presupune auto-salvare, folder sau aplicație. Cere sau verifică destinația înainte de a trata documentul ca publicat.

Limite / gotchas

sop-creator nu validează magic adevărul procesului. Dacă inputul este fals, incomplet sau ambiguu, SOP-ul poate doar să expună problema. Nu trebuie să inventeze owneri, aprobatori, SLA-uri, KPI-uri, contacte de escaladare, etichete UI, pași de tool sau rațiuni compliance.

Nu transforma redesign-ul în documentare. Dacă procesul are defecte — lipsă de aprobare, rollback imposibil, roluri suprapuse — acestea se marchează ca recomandări sau gaps. Operatorul decide schimbarea.

Nu include materiale sensibile în ghiduri publice sau SOP-uri partajabile: credentiale, valori secrete, căi locale, IP-uri interne, conturi, date personale sau detalii private. Descrie generic verificarea necesară și păstrează dovezile în locul configurat pentru mediul respectiv. Publicarea accidentală a infrastructurii nu este transparență. Este autopsie preventivă.