7.6 Budowa własnego SOP

Każdy rozdział tej części opisuje jeden komponent. Ten opisuje dokument, który trzyma je razem i sprawia, że pipeline przeżywa zły tydzień.

Test SOP-a nie polega na tym, że wygląda profesjonalnie. Polega na tym, że we wtorek, gdy masz dwie godziny i zero entuzjazmu, możesz go przejść i wyprodukować coś publikowalnego.

Format SOP-a

Pięć pól na krok i nic więcej:

Dlaczego progi, a nie opisy. Krok, który mówi „wygeneruj wystarczająco dużo obrazów", nie jest wykonalny. Krok, który mówi „150 frame'ów, stop, jeśli odsetek niepowodzeń przekroczy jedną czwartą", jest. Progi są tym, co zamienia procedurę w coś, co możesz przekazać komuś innemu — albo wykonać o 23:00.

Dlaczego szacunki czasu. Czynią proces widocznym. SOP produkcyjny o sumie trzech godzin to inna decyzja życiowa niż ten o sumie dziewięciu, a nie porównasz ich, dopóki liczby nie istnieją.

SOP 1: jeden post

Cel: 20 do 40 minut od początku do końca. Jeśli zajmuje dłużej, brakuje jakiegoś kroku albo coś jest improwizowane.

Dwa kroki, które najczęściej rozwalają budżet: krok 6, bo zasada trzech podejść nie jest egzekwowana, i krok 5, bo kanon się rozjechał, a sprawdzenie wymaga myślenia. Oba to problemy z wcześniejszych etapów, ujawnione na ostatnim.

SOP 2: tydzień

Cztery sloty. To rytm, który zakłada reszta książki:

Dlaczego trzy sloty produkcyjne, a nie codzienna praca. Praca w batchach jest tym, co czyni godzinę produktywną: jedno setup, jedna sesja QA, jeden run wysyłki. Codzienna produkcja to pięciokrotne płacenie kosztu setupu.

Dlaczego slot na budowanie banku. Piątkowy output nie jest na ten tydzień; to bufor, dzięki któremu pipeline przeżyje chorobę, wyjazd albo zły batch. Kolejka publikacji z rozdziału 5.6 potrzebuje dwudziestu zatwierdzonych frame'ów w rezerwie, a ten slot jest miejscem, z którego one pochodzą.

Dlaczego slot przeglądu jest osobny i zaplanowany. Czytanie analityki z rozdziału 2.6, uzupełnienie listy promptów i kwartalny audyt assetów (5.3) mieszkają tutaj. Niezaplanowany przegląd się nie zdarza.

SOP 3: playbook awaryjny

Dokument, który piszesz raz i masz nadzieję nigdy nie potrzebować. Cztery scenariusze, każdy z pierwszą reakcją.

Model albo provider jest wycofywany lub się psuje. Reakcja: przełącz się na drugiego providera (zasada two-vendor rule z 7.5). Twoje keyframe'y, prompty i referencje są neutralne wobec providera, więc to re-run, a nie przebudowa. Warunek wstępny: klipy na drugim providerze masz już przetestowane.

Konto jest ograniczone albo zbanowane. Reakcja: odwołanie, a w międzyczasie publikacja na drugiej platformie. Twoje kanoniczne assety są poza platformami (7.3), więc persona przeżywa. Warunek wstępny: masz obecność na drugiej platformie, choćby małą.

Batch wraca zły albo poza tożsamością. Reakcja: zatrzymaj produkcję, zdiagnozuj z tabelą z 7.2, powtórz sprawdzenie tożsamości względem reference sheet. Nie publikuj z tego batcha. Warunek wstępny: masz zabankowane frame'y, więc zatrzymanie produkcji nie oznacza zatrzymania publikacji.

Budżet miesiąca kończy się wcześniej. Reakcja: trzy odczyty z 7.5 — sprawdź wybór modelu, sprawdź rejection rate, potem zdecyduj, czy wolumen jest rzeczywiście wyższy. Warunek wstępny: śledzisz koszt na użyteczny frame, więc wiesz, który odczyt ma zastosowanie.

Wspólna struktura: każdy scenariusz ma pierwszą reakcję i warunek wstępny, który musi już być spełniony. Warunki wstępne są powodem, dla którego ten SOP warto napisać, zanim będzie potrzebny.

Wersjonowanie SOP-a

Proces się starzeje. Modele się zmieniają, platformy się zmieniają, ceny się zmieniają i twoje własne preferencje się zmieniają. SOP, który ma trzy wersje zaległości, produkuje pipeline, który nie pasuje już do rzeczywistości — a awaria jest cicha, bo dokument nadal dobrze się czyta.

Wersjonuj go z datą i powodem, ta sama dyscyplina co wersje adaptera z rozdziału 4.7:

sop-post.md       v4  2026-10-01  new: disclosure step added before scheduling
sop-week.md       v3  2026-09-15  changed: three production slots, moved bank to Friday
sop-failure.md    v2  2026-08-20  added: video provider switch procedure

Przeglądaj SOP w kwartalnym rytmie (rytm operacyjny z 12.5). Trzy pytania: który krok pomijałem wielokrotnie, który krok zajął dłużej niż zapisano i co zrobiłem inaczej, a działa? Każda odpowiedź to edycja.

Krok, który zawsze pomijasz, jest tym ciekawym. Albo jest niepotrzebny — usuń go — albo jest potrzebny i kumulujesz ryzyko. Rozstrzygnięcie, który to przypadek, to realna decyzja operacyjna i jedno z niewielu miejsc, gdzie zauważenie własnego zachowania zmienia system.

Gdzie to się psuje

SOP bez progów. Niewykonalny.

Brak szacunków czasu. Nie widzisz procesu.

SOP-y, które opisują intencje, a nie kroki. „Przejrzyj jakość uważnie" to nie krok.

Brak playbooka awaryjnego. Każda awaria jest improwizowana.

Brak banku. Zatrzymanie produkcji staje się zatrzymaniem publikacji.

SOP bez wersjonowania. W ciszy przestaje pasować do rzeczywistości.

Nigdy go nie przeglądasz. Krok, który zawsze pomijasz, zostaje, a proces zostaje zepsuty.

Bramka

1. Czy każdy krok ma narzędzie, próg, właściciela i czas?
2. Czy twój SOP na jednego posta mieści się w 20–40 minutach i czy wiesz, który krok go rozwala?
3. Czy masz cztery zaplanowane sloty, w tym slot na budowanie banku i slot przeglądu?
4. Czy twój playbook awaryjny obejmuje utratę modelu, utratę konta, nieudany batch i wyczerpanie budżetu — każdy z warunkiem wstępnym, który jest już spełniony?
5. Czy SOP jest wersjonowany z datami i powodami?
6. Czy SOP jest przeglądany kwartalnie i czy usunąłeś krok, który zawsze pomijasz?

Z czym wychodzisz

Format SOP-a o pięciu polach, w którym progi zastępują opisy; dwunastokrokową procedurę jednego posta z celem 20–40 minut i dwoma krokami, które zwykle się przedłużają; tydzień z czterema slotami, w tym slot na budowanie banku i zaplanowany przegląd; playbook awaryjny z czterema scenariuszami, w których każda reakcja ma warunek wstępny; oraz dyscyplinę wersjonowania z trzema pytaniami, które utrzymują dokument w prawdzie. Część VII jest domknięta: pipeline istnieje, kosztuje znaną kwotę i przeżywa zły tydzień.