Architektura technologii sprzedaży B2B: jak połączyć proces, dane, narzędzia i ład

Przedmiotem J00 nie jest cała „cyfryzacja sprzedaży”. Taki obiekt jest zbyt szeroki, aby przypisać mu decyzję, właściciela, dowody i test sukcesu. Obiekt kontrolowany brzmi:

Przykładowy zakres może obejmować:

• rejestrację i potwierdzanie jednej kategorii zobowiązania klienta;
• przygotowanie snapshotu prognozy dla jednego segmentu;
• kierowanie zatwierdzenia cenowego;
• utrzymanie jednej wersji oferty i jej statusu;
• synchronizację tożsamości accountu między CRM i ERP;
• udostępnienie managerowi danych do jednej decyzji o zasobach wykonawczych;
• przygotowanie briefu rozpoznawczego przez AI z autoryzowanych źródeł.

Nie powinien natomiast brzmieć:

„wdrożenie CRM”
„AI w sprzedaży”
„integracja danych”
„automatyzacja follow-upu”
„pulpit dla zarządu”

bez jawnego użytkownika, decyzji, zakresu, danych, mandatu i wyniku.

Obiekt kontrolowany chroni projekt przed trzema typowymi rozszerzeniami. Pierwszym jest pełzanie zakresu (scope drift): lokalny problem zamienia się w przebudowę całego stosu technologicznego. Drugim jest dryf celu (purpose drift): dane zebrane do prowadzenia procesu zaczynają służyć do oceny ludzi. Trzecim jest dryf uprawnień (authority drift): system, który miał przygotowywać wersję roboczą, zaczyna wykonywać akcję lub sugerować formalny wynik.

Stos technologiczny opisuje, jakie produkty są obecne. Architektura opisuje, dlaczego istnieją, jakie obiekty i decyzje obsługują, jak współdziałają oraz co dzieje się przy błędzie, zmianie i zakończeniu.

Organizacja może posiadać nowoczesne produkty i nadal mieć:

• różne definicje accountu;
• rekord opportunity bez dowodów po stronie klienta;
• prognozę, której nie da się odtworzyć;
• integracje bez właściciela;
• konta serwisowe bez terminu ważności;
• dane bez ścieżki pochodzenia;
• aplikacje bez planu wyjścia;
• automatyzacje bez idempotencji;
• pulpit bez użytkownika decyzji;
• AI bez śladu źródłowego;
• retencję wynikającą z domyślnej konfiguracji dostawcy;
• archiwum, z którego stare dane nadal zasilają raporty.

Najgroźniejsza luka nie zawsze jest techniczna. Często organizacja nie potrafi wskazać, jaka decyzja ma się zmienić po wdrożeniu. Wtedy za sukces uznaje aktywację licencji, liczbę integracji, kompletność pól albo wzrost liczby logowanych aktywności. Są to sygnały wdrożenia lub obciążenia systemu, nie dowody poprawy decyzji.

Antywzorzec: feature-first design

dostawca pokazuje funkcję
→ organizacja kupuje moduł
→ integrator mapuje dostępne pola
→ użytkownicy dostają obowiązek uzupełniania
→ pulpit pokazuje adopcję
→ cel biznesowy jest dopisywany po fakcie

Właściwa kolejność

ZDOLNOŚĆ BIZNESOWA
→ DECYZJA
→ PRZEPŁYW PRACY
→ OBIEKT KONTROLOWANY
→ DANE I DOWODY
→ REKORD
→ ROLA APLIKACJI
→ INTEGRACJA
→ DOSTĘP I KONTROLA
→ OBSERWOWALNOŚĆ
→ CYKL ŻYCIA

Ta kolejność nie oznacza wielomiesięcznego projektu przed każdym usprawnieniem. Oznacza, że nawet mały pilot powinien potrafić odpowiedzieć na każde z tych pytań w proporcjonalnym zakresie.

Zdolność opisuje, co organizacja musi potrafić zrobić niezależnie od konkretnej platformy. Decyzja jako punkt wyjścia doprecyzowuje, kto i na jakiej podstawie ma wykonać określoną pracę.

Dla przypadku użycia „usprawnienie prognozy” zdolność może brzmieć:

Organizacja potrafi odtworzyć stan pipeline w określonym momencie, ujawnić założenia i niepewność oraz podjąć decyzję o zasobach wykonawczych na podstawie wersjonowanego snapshotu.

Nie brzmi:

Organizacja korzysta z modułu prognozowania predykcyjnego.

Dla przypadku użycia „lepsze przygotowanie do spotkania” zdolność może brzmieć:

Handlowiec potrafi uzyskać aktualny, źródłowy brief o account, hipotezach i otwartych pytaniach, z rozróżnieniem faktów, wnioskowania i niewiadomych.

Nie brzmi:

Handlowiec korzysta z AI copilot.

Zdolność jako punkt wyjścia ogranicza lock-in na poziomie języka. Decyzja jako punkt wyjścia ogranicza zbieranie danych bez celu. Razem umożliwiają ocenę alternatyw: zmiana procesu, prosty rejestr, szkolenie, nowa integracja, rozszerzenie obecnej aplikacji albo brak zmiany. Planowanie oparte na zdolnościach i jawne domeny architektury są również obecne w standardach architektury korporacyjnej, lecz ATS pozostaje własną syntezą dla systemu sprzedaży.⁷

Model ATS obejmuje dziesięć warstw:

ATS-1  zdolność, problem, użytkownicy i zamierzone wyniki
ATS-2  decyzje, mandat i użycia zakazane
ATS-3  przepływ pracy, stany, przekazania i wyjątki
ATS-4  obiekty kontrolowane, rekordy i identyfikatory
ATS-5  źródła danych, własność, ścieżka pochodzenia i jakość
ATS-6  aplikacje, usługi i role systemów
ATS-7  integracje, zdarzenia, opóźnienie i odporność
ATS-8  tożsamość, dostęp, ochrona danych i zabezpieczenia
ATS-9  obserwowalność, wsparcie, incydent i odtworzenie
ATS-10 kontrola zmian, przenoszalność, wygaszenie i wycofanie

ATS nie jest sekwencją, którą przechodzi się raz od lewej do prawej. Jest pętlą. Odkrycie w ATS-7, że dwa systemy nie potrafią uzgodnić tożsamości accountu, może wymagać powrotu do ATS-4. Incydent w ATS-9 może ujawnić, że model dostępu z ATS-8 jest zbyt szeroki. Brak kompletnego eksportu w ATS-10 może zmienić decyzję o aplikacji w ATS-6. Nowe użycie zakazane może unieważnić projekt przepływu pracy.

Status SAT-7 APPROVED_FOR_PILOT nie oznacza, że wszystkie elementy są idealne. Oznacza, że zakres, niewiadome, kontrole, kryteria akceptacji i warunki zatrzymania są wystarczająco jawne, aby bezpiecznie zebrać dowody. Status SAT-9 ACTIVE_CONTROLLED również nie jest metą. Każda architektura pozostaje wersjonowana i podatna na zmianę.

Pierwsza warstwa eliminuje projekty, których jedynym uzasadnieniem jest zakup, trend albo dostępna funkcja.

Minimalny rekord:

capability:
business_problem:
primary_user:
affected_roles:
segment_or_motion:
decision_or_job:
current_cost_or_risk:
intended_outcome:
success_criteria:
failure_condition:
prohibited_uses:
owner:
review_date:

Problem musi być obserwowalny

„CRM jest stary” nie jest pełnym problemem. Może być symptomem, lecz nie mówi, jaka decyzja jest niemożliwa albo kosztowna. Lepszy zapis:

Manager nie może odtworzyć, jakie dowody istniały w dniu zatwierdzenia prognozy, ponieważ system przechowuje tylko aktualny stan opportunity.

„Potrzebujemy AI” również nie jest problemem. Lepszy zapis:

Handlowiec poświęca 45 minut na zebranie jawnych informacji z sześciu autoryzowanych źródeł, a wynik nadal nie rozróżnia wersji i daty.

Kryteria sukcesu nie powinny mierzyć wyłącznie aktywacji

Przykładowe kryteria:

• udział decyzji wykonanych z kompletnym śladem źródłowym;
• redukcja czasu przy zachowaniu lub poprawie jakości;
• spadek liczby duplikatów;
• możliwość odtworzenia snapshotu;
• czas wykrycia i naprawy błędu integracji;
• kompletność eksportu w teście wyjścia;
• liczba błędnych automatycznych akcji;
• obciążenie użytkownika;
• liczba przypadków, w których system prawidłowo powstrzymał się od działania lub je zatrzymał.

Właściwym wynikiem ATS-1 może być CLOSE_NO_ACTION. Jeśli istniejące rozwiązanie spełnia wymagania, brak zakupu jest decyzją architektoniczną.

Technologia może:

• INFORM
• DRAFT
• RECOMMEND
• ROUTE
• EXECUTE
• COMMIT

Te role nie są równoważne. System, który prezentuje dane, wymaga innych kontroli niż system, który wysyła wiadomość, zmienia cenę, zamyka rekord albo wpływa na decyzję pracowniczą.

Minimalny rekord:

decision:
decision_user:
authority_source:
technology_role:
human_checkpoint:
execution_right:
customer_commitment:
legal_or_policy_gate:
employment_impact:
prohibited_secondary_use:
correction_and_appeal:

Uprawnienie w systemie ≠ mandat

Administrator może technicznie nadać handlowcowi uprawnienie do zmiany statusu umowy. Nie oznacza to, że handlowiec ma mandat biznesowy do zaakceptowania warunków. Integracja może technicznie zapisać won. Nie oznacza to, że istnieje zobowiązanie klienta. Model może wskazać wysokie prawdopodobieństwo. Nie oznacza to, że może samodzielnie utworzyć zatwierdzoną prognozę.

Użycia zakazane przed konfiguracją

Użycie zakazane powinno być zapisane na początku, nie po incydencie. Przykłady:

• używanie telemetrii wsparcia do rankingu pracowników;
• trenowanie zewnętrznego modelu na danych klientów;
• wysyłka wersji roboczej kierowanej do klienta bez punktu kontrolnego;
• zmiana zatwierdzenia cenowego bez mandatu;
• używanie pola development do formalnego HR;
• generowanie wnioskowań o osobowości, emocjach albo uczciwości;
• przypisywanie braku danych jako braku pracy.

AI Act ma wieloetapowy i zmieniający się kalendarz stosowania, z wyjątkami i późniejszymi terminami dla części systemów. Dlatego architektura nie powinna zawierać statycznego twierdzenia „zgodne z AI Act”. Powinna zawierać spis, klasyfikację, właściciela i wyzwalacz rewalidacji po materialnej zmianie lub zmianie prawa.⁸⁹¹⁰

Przepływ pracy opisuje realny przebieg pracy, nie kolejność klikania w interfejsie. Powinien ujawniać:

• warunek wejścia;
• stany;
• przejścia;
• kryteria wyjścia;
• przekazania;
• wyjątki;
• powroty;
• punkty kontrolne;
• dowody;
• ręczny tryb zastępczy.

workflow_id:
entry_condition:
states:
transitions:
exit_conditions:
roles:
handoff:
service_expectations:
exceptions:
manual_fallback:
control_points:
evidence_created:

Stan obecny przed stanem docelowym

Aktualny przepływ pracy może obejmować:

• prywatny arkusz;
• wiadomość na komunikatorze;
• ręczne kopiowanie danych;
• zgodę udzieloną ustnie;
• osobę, która „zawsze wie”, jak naprawić błąd;
• cotygodniowy eksport;
• obejście ograniczenia aplikacji;
• dane klienta zapisane lokalnie.

Pominięcie tych elementów prowadzi do architektury docelowej, która działa tylko na diagramie. Mapowanie stanu obecnego nie służy do dokumentowania wszystkiego. Służy ujawnieniu punktów, w których znaczenie, mandat albo dowody zmieniają nośnik.

Wyjątek jest częścią przepływu pracy

Jeżeli proces nie określa, co zrobić przy braku danych, konflikcie tożsamości, opóźnieniu, sprzeciwie klienta, awarii albo zmianie właściciela, system wymusi improwizację. Wyjątki nie są dowodem złego zachowania użytkowników. Często pokazują, że model stanów jest niepełny.

Technologia zarządza rekordami, nie rzeczywistością. Rekord jest reprezentacją obiektu, której jakość zależy od definicji, źródła, czasu i aktualizacji.

object_type:
business_definition:
identity_rule:
identifier:
attributes:
states:
relationships:
authoritative_sources:
owner:
version:
correction:
retention:
withdrawal_effect:

Account, organizacja i buying group to różne obiekty

Jedna osoba prawna może mieć wiele jednostek zakupowych. Jedna grupa kapitałowa może mieć różne umowy, waluty, procesy i właścicieli. Buying group może przekraczać granice jednego accountu. Próba wymuszenia jednego identyfikatora „klienta” może uprościć pulpit kosztem poprawności decyzji.

Opportunity nie jest umową

Opportunity może reprezentować hipotezę handlową, proces zakupowy, pakiet produktów albo jednostkę prognozy. Definicja musi rozstrzygać:

• kiedy powstaje;
• co ją identyfikuje;
• czy może obejmować wiele decyzji;
• jak łączy się z ofertą i umową;
• co oznacza closed;
• kto może zmienić właściciela;
• jakie dowody wspierają stan.

Korekta i zakwestionowanie

Każdy materialny rekord powinien mieć możliwość:

• poprawienia faktu;
• zachowania historii;
• wskazania sporu;
• wycofania wersji;
• propagacji korekty do konsumentów w dole strumienia.

Bez tego system produkuje precyzyjne, lecz nieodwracalne błędy.

Dane nie są wartościowe dlatego, że znajdują się w bazie. Ich użyteczność zależy od tego, jak powstały, co znaczą, kiedy zostały zarejestrowane i do jakiej decyzji mają służyć.

Minimalna ścieżka pochodzenia danych:

ZDARZENIE ŹRÓDŁOWE
→ ZEBRANIE
→ TRANSFORMACJA
→ PRZECHOWANIE
→ ZŁĄCZENIE
→ MIARA / AUTOMATYZACJA / WEJŚCIE MODELU
→ WYNIK
→ UŻYCIE W DECYZJI

source_system:
source_event:
source_owner:
collection_method:
transformation:
storage:
join_logic:
event_time:
processing_time:
latency:
missingness:
quality_criteria:
downstream_consumers:

W3C PROV-O rozróżnia encje, aktywności i agentów, co może wspierać reprezentację pochodzenia danych. Nie jest jednak gotową platformą ścieżki pochodzenia ani gwarancją poprawności semantyki biznesowej.¹¹

Jakość danych jest wielowymiarowa

Poprawność jest tylko jednym wymiarem. Użytkownicy potrzebują także adekwatności, kompletności, aktualności, interpretowalności, dostępności i spójności. Wymiar powinien być oceniany względem konkretnej decyzji, nie abstrakcyjnie.¹²

Brak danych wymaga przyczyny

Brak może oznaczać:

• zdarzenie nie wystąpiło;
• zdarzenia nie rejestrowano;
• źródło nie jest zintegrowane;
• integracja jest opóźniona;
• użytkownik nie miał dostępu;
• danych nie wolno było zebrać;
• rekord usunięto;
• źródło wycofano.

Kaskady błędów danych

Błąd w źródle może przejść przez złączenie, pulpit, automatyzację i model, a następnie stać się podstawą decyzji. Badania nad kaskadami błędów danych i długiem technicznym pokazują, że lokalne problemy danych oraz ukryte zależności mogą generować rozległe skutki systemowe.¹³¹⁴

Aplikacja nie jest zdefiniowana wyłącznie nazwą kategorii. Powinna otrzymać rolę w konkretnej architekturze:

• SYSTEM OF ENGAGEMENT
• SYSTEM OF RECORD
• SYSTEM OF ANALYSIS
• SYSTEM OF AUTOMATION
• SYSTEM OF KNOWLEDGE
• IDENTITY OR ACCESS SERVICE
• INTEGRATION OR EVENT SERVICE
• OBSERVABILITY SERVICE

Jedna platforma może pełnić kilka ról. Wtedy należy rozdzielić:

• właściciela;
• obiekty;
• uprawnienia;
• przepływy danych;
• dostępność;
• tryby awarii;
• cykl życia.

application:
role:
business_owner:
technical_owner:
objects:
users:
data_classes:
dependencies:
availability_need:
support_model:
contract:
lifecycle:

System of record jest relacją zakresową

Nie należy deklarować „CRM jest single source of truth”. Precyzyjny zapis brzmi:

CRM jest autorytatywnym źródłem aktualnego właściciela opportunity w procesie sprzedaży enterprise, z wyjątkiem rekordów w statusie wstrzymania migracji.

ERP może być autorytatywny dla zaksięgowanej faktury. Repozytorium umów dla podpisanej wersji. System klienta dla jego statusu. Ręczny przegląd dla ograniczenia albo sporu.

Shadow systems

Prywatny arkusz, notatnik albo lokalna baza mogą być symptomem:

• brakującej funkcji;
• zbyt wysokiego obciążenia;
• niedostępnego interfejsu;
• potrzeby prototypowania;
• konfliktu definicji;
• obchodzenia kontroli.

Właściwą reakcją nie jest automatyczne ukaranie użytkownika. Najpierw należy zinwentaryzować użycie, dane, właściciela i ryzyko, a następnie wybrać GOVERN, MIGRATE, LIMIT albo RETIRE.

Integracja przenosi nie tylko wartości. Przenosi semantykę, tożsamość, czas i odpowiedzialność.

producer:
consumer:
object_or_event:
contract_version:
identity_mapping:
authentication:
authorization:
schema:
frequency_or_trigger:
latency:
ordering:
idempotency:
retry:
timeout:
error_route:
observability:
owner:
change_policy:
rollback:

OpenAPI może opisać kontrakt HTTP API, a CloudEvents wspiera wspólny format opisu zdarzeń. Nie definiują jednak, czym jest opportunity, kto ma mandat ani kiedy stan klienta jest potwierdzony.¹⁵¹⁶

Ponowienie bez idempotencji

Jeżeli system nie otrzyma odpowiedzi, może ponowić żądanie. Bez idempotencji to samo zdarzenie może:

• wysłać dwie wiadomości;
• utworzyć dwa zadania;
• zarejestrować dwa zobowiązania;
• naliczyć dwa wyniki;
• wywołać dwie faktury.

Ścieżka błędu jest funkcją biznesową

Błąd nie powinien znikać w logu technicznym. Potrzebne mogą być:

• dead-letter queue;
• rekord wyjątku;
• alert;
• ręczna naprawa;
• właściciel;
• komunikacja z klientem;
• korekta w dole strumienia;
• wycofanie zmiany.

Real-time nie jest domyślnym wymaganiem

Im krótsze opóźnienie, tym większa złożoność i koszt. Prognoza zasobów wykonawczych może wymagać snapshotu dziennego, nie milisekund. Komunikacja z klientem może wymagać natychmiastowej deduplikacji. Wymaganie powinno wynikać z decyzji i kosztu opóźnienia.

Model dostępu obejmuje ludzi, konta serwisowe, integracje, automatyzacje i modele.

identity:
role:
object_scope:
actions:
purpose:
approval:
authentication:
authorization:
secret_or_token:
expiry:
logging:
review:
revocation:

NIST Cybersecurity Framework 2.0 organizuje wyniki wokół funkcji Govern, Identify, Protect, Detect, Respond i Recover. Jest elastycznym modelem zarządzania ryzykiem, nie certyfikatem zgodności konkretnej architektury.¹⁷ NIST Privacy Framework może wspierać spis i mapowanie przetwarzania, lecz nie zastępuje analizy RODO.¹⁸

Minimalne uprawnienia

Minimalny dostęp powinien uwzględniać:

• obiekt;
• atrybut;
• czynność;
• segment;
• czas;
• środowisko;
• cel.

Dostęp read all może być prostszy w integracji, lecz zwiększa skutek błędu, kradzieży poświadczeń i użycia wtórnego. Katalog kontroli NIST SP 800-53 może służyć jako źródło wymagań bezpieczeństwa i ochrony danych, ale nie powinien być kopiowany jako nieweryfikowana lista kontrolna wdrożeniowa.¹⁹

Konta serwisowe i sekrety

Konto techniczne potrzebuje:

• właściciela;
• zakresu;
• metody uwierzytelniania;
• rotacji;
• terminu ważności;
• telemetrii;
• odebrania dostępu;
• testu po odejściu dostawcy lub pracownika.

API i łańcuch dostaw

OWASP API Security Top 10 wskazuje między innymi ryzyka autoryzacji na poziomie obiektu, uwierzytelniania, nieograniczonego zużycia zasobów i niewłaściwego spisu. Lista nie zastępuje modelowania zagrożeń ani pełnego programu bezpieczeństwa.²⁰ Secure-by-Design i Secure-by-Demand wzmacniają odpowiedzialność producenta oraz wymaganie dowodów od dostawcy, ale również nie stanowią certyfikacji.²¹²²

Ochrona danych i użycie w relacji zatrudnienia

Dostęp do danych nie oznacza prawa do ich użycia. RODO wymaga m.in. ograniczenia celu, minimalizacji, przejrzystości, praw osób, bezpieczeństwa i — w określonych przypadkach — DPIA. EDPB podkreśla potrzebę analizy podstawy przetwarzania także w kontekście modeli AI.²³⁹

Telemetria zebrana do wsparcia nie powinna cicho stawać się systemem rankingu handlowców. Monitoring, nagrania, analiza komunikacji i użycie wpływające na zatrudnienie wymagają osobnej oceny lokalnego prawa, polityk, relacji pracowniczych, retencji i możliwości korekty.

Logowanie odpowiada na pytanie „co zostało zapisane?”. Obserwowalność odpowiada na pytanie „czy potrafimy zrozumieć nieznany stan systemu i jego wpływ na pracę?”.

Minimalny rekord:

health_signal:
business_signal:
logs:
metrics:
traces:
correlation_id:
threshold_or_slo:
alert_owner:
runbook:
manual_fallback:
recovery:
rollback:
incident_class:
post_incident_review:

OpenTelemetry zapewnia niezależne od dostawcy specyfikacje śladów, miar i logów. Instrumentacja nadal wymaga kontekstu biznesowego, retencji, ochrony i właściciela reakcji.²⁴

Sygnały techniczne i biznesowe

System może odpowiadać 200 OK, podczas gdy:

• aktualizuje niewłaściwy account;
• zapisuje stare dane;
• tworzy duplikaty;
• omija wymagany punkt kontrolny;
• traci historię;
• działa na wycofanym źródle.

Dlatego obserwowalność powinna łączyć sygnały kondycji z kontrolami integralności biznesowej.

Incydent i skutki w dole strumienia

Incydent architektury sprzedażowej może dotyczyć:

• poufności;
• integralności;
• dostępności;
• komunikacji z klientem;
• prognozy;
• danych pracownika;
• źródła wiedzy;
• automatyzacji;
• wyniku modelu.

Przegląd po incydencie powinien wskazać nie tylko techniczną przyczynę źródłową, ale także rekordy, decyzje, klientów i miary, których dotyczy, oraz wymagane wycofanie.

System sprzedażowy jest stale zmieniany. Dostawca aktualizuje usługę, API zmienia schemat, organizacja tworzy nowe pole, segment zmienia przepływ pracy, model dostaje nową wersję, dane przenoszą się do innego regionu.

version:
effective_date:
material_change:
change_owner:
consumers:
compatibility:
migration:
revalidation:
export:
exit_plan:
retirement_trigger:
retention:
deletion:
withdrawal_propagation:
archive:

Zmiana materialna

Wyzwalacz rewalidacji może obejmować:

• nowe zamierzone użycie;
• nowy model lub nowego dostawcę;
• zmianę subprocessora;
• zmianę regionu danych;
• nową klasę danych;
• zmianę mandatu;
• zmianę schematu;
• nową automatyczną akcję;
• zmianę prawa;
• incydent;
• utratę jakości lub pokrycia.

AI Act wszedł w życie 1 sierpnia 2024 r., lecz jego stosowanie jest etapowe i obejmuje wyjątki oraz późniejsze terminy dla części obowiązków. Z tego powodu każdy przypadek użycia AI w architekturze wymaga aktualnego przeglądu, a nie jednorazowej etykiety zgodności.⁸ Data Act stosuje się zasadniczo od 12 września 2025 r.; jego zastosowanie do konkretnego produktu, usługi i relacji umownej należy analizować dla każdego przypadku osobno.²⁵ NIS2 może ustanawiać obowiązki zarządzania ryzykiem i łańcuchem dostaw dla podmiotów objętych jej zakresem, dlatego przed przypisaniem obowiązku należy sprawdzić sektor, wielkość podmiotu i krajową implementację.²⁶

Przenoszalność to praktyczny test

Nie wystarczy zapis umowy „dane można wyeksportować”. Trzeba sprawdzić:

• jakie obiekty;
• historię zmian;
• relacje;
• załączniki;
• identyfikatory;
• reguły;
• konfigurację;
• logi;
• format;
• czas;
• koszt;
• kompletność;
• usunięcie danych po migracji.

Wygaszenie i wycofanie

Wygaszenie jest planowym zakończeniem. Wycofanie oznacza, że komponent, źródło albo wynik nie może być dalej używany. Oba wymagają propagacji do:

• raportów;
• automatyzacji;
• modeli;
• decyzji;
• zapisów historycznych;
• użytkowników;
• dokumentacji.

Poniższe 12 taksonomii opisuje odrębne obiekty. SAT-9 ACTIVE_CONTROLLED, DQL-12 FIT_FOR_USE i INS-12 RESILIENT_IN_SCOPE nie sumują się do „wysokiej dojrzałości cyfrowej”. Kod jest językiem decyzji i routingu.

5.1. SAT-0–SAT-12 — Status Architektury Technologii

5.2. UCB-0–UCB-13 — Granica przypadku użycia

5.3. DRA-0–DRA-13 — Prawa decyzyjne i mandat

5.4. WFS-0–WFS-14 — Stan przepływu pracy

5.5. ODS-0–ODS-14 — Projekt obiektu i rekordu

5.6. DQL-0–DQL-15 — Jakość danych i ścieżka pochodzenia

5.7. ARS-0–ARS-13 — Rola aplikacji

5.8. INS-0–INS-15 — Stan integracji

5.9. AXS-0–AXS-14 — Dostęp, ochrona danych i bezpieczeństwo

5.10. OBS-0–OBS-13 — Obserwowalność i incydent

5.11. VPR-0–VPR-12 — Dostawca i przenoszalność

5.12. LFC-0–LFC-12 — Cykl życia

5.13. Zasady kodowania

• kody opisują stan obiektu kontrolowanego, nie „poziom firmy”;
• kody nie są punktami;
• jeden rekord może mieć kilka kodów z różnych taksonomii;
• konflikt kodów należy zachować i wyjaśnić;
• UNKNOWN, HOLD, RETIRED i WITHDRAWN są pełnoprawnymi statusami;
• kody na poziomie osoby są niedozwolone;
• nie wolno sumować 172 kodów do jednego score.

Stan obecny powinien obejmować nie tylko systemy oficjalne, lecz także:

• arkusze;
• skrzynki;
• komunikatory;
• ręczne eksporty;
• ręczne zatwierdzenia;
• lokalne skrypty;
• notatki;
• automatyzacje poza ładem;
• ekspertów, którzy naprawiają błędy bez formalnej roli;
• wyjątki i obejścia.

Stan docelowy nie powinien być mapą produktów. Powinien pokazywać:

1. zdolność;
2. decyzję;
3. przepływ pracy;
4. obiekt kontrolowany;
5. źródło;
6. rolę aplikacji;
7. kontrakt integracji;
8. mandat;
9. kontrolę;
10. obserwowalność;
11. cykl życia.

Architektura różnicy

Najbardziej użytecznym artefaktem często nie jest docelowy diagram, lecz lista jawnych różnic:

gap:
current_consequence:
target_capability:
change_required:
evidence:
owner:
dependency:
risk:
pilot:
acceptance:
stop_condition:

Pozwala ona rozdzielić:

• zmianę procesu;
• korektę definicji;
• naprawę danych;
• rozszerzenie aplikacji;
• nową integrację;
• zmianę uprawnień;
• szkolenie;
• decyzję zakupową;
• wycofanie elementu.

Architektura danych nie jest zakończona, gdy wartości płyną między systemami. Musi istnieć odpowiedź na pytania:

• skąd pochodzi rekord;
• kto go utworzył;
• jaka reguła go zmieniła;
• jakie źródło zostało użyte;
• która wersja definicji obowiązywała;
• kto może poprawić błąd;
• jakie wyniki trzeba przeliczyć;
• kto otrzyma informację o wycofaniu.

Datasheets for Datasets i Model Cards powstały w kontekście dokumentacji danych i modeli, ale ich podstawowa logika jest użyteczna szerzej: motywacja, skład, przeznaczenie, ewaluacja, ograniczenia, utrzymanie i historia zmian powinny być jawne.²⁷²⁸

Karta źródła dla atrybutu

attribute:
business_definition:
authoritative_source:
source_owner:
collection:
event_time:
latency:
coverage:
quality:
limitations:
correction:
retention:

Korekta bez kasowania historii

Poprawienie rekordu nie powinno niszczyć informacji, że wcześniejsza wersja była użyta. W przeciwnym razie organizacja nie potrafi ustalić, dlaczego prognozy, zatwierdzenia albo automatyzacja zachowały się w określony sposób.

Integracja jest udana dopiero wtedy, gdy zachowuje znaczenie i obsługuje tryby awarii. HTTP 200, zielony job albo brak błędu w ETL nie dowodzą, że:

• właściwy obiekt został zaktualizowany;
• zdarzenie nie było duplikatem;
• kolejność była poprawna;
• źródło było aktualne;
• użytkownik miał mandat;
• konsument w dole strumienia zrozumiał wersję schematu.

Minimalny test integracji

• poprawne zdarzenie;
• zdarzenie niekompletne;
• duplikat;
• zdarzenia poza kolejnością;
• limit czasu;
• ponowienie;
• brak dostępu;
• zmiana schematu;
• opóźnienie;
• wycofanie źródła;
• awaria częściowa;
• wycofanie zmiany.

Bezpieczne wytwarzanie powinno być częścią cyklu życia. NIST SSDF i rozszerzenie dla wytwarzania modeli AI dostarczają praktyk organizacyjnych, lecz nie stanowią gotowego audytu konkretnej integracji.²⁹³⁰

Projekt dostępu powinien odpowiadać na trzy odrębne pytania:

1. Kto technicznie może uzyskać dostęp?
2. Kto operacyjnie ma mandat do działania?
3. Do jakiego celu wolno użyć danych?

Nadmierny dostęp może wynikać z wygody integratora, ograniczeń produktu albo braku autoryzacji na poziomie obiektu. Każde z tych źródeł wymaga innej naprawy.

Dryf celu w telemetrii

Log może zawierać:

• identyfikator użytkownika;
• czas;
• akcję;
• rekord;
• urządzenie;
• błąd;
• payload.

To może być potrzebne do bezpieczeństwa i wsparcia. Użycie tych samych danych do oceny produktywności, zachowania albo zaangażowania jest innym celem. Wymaga odrębnej analizy, przejrzystości, proporcjonalności, dostępu i możliwości korekty.

Realny nadzór człowieka

Przegląd przez człowieka jest realny tylko wtedy, gdy osoba:

• widzi źródło i ograniczenia;
• ma czas;
• rozumie system;
• ma mandat;
• może odrzucić wynik;
• może zatrzymać działanie;
• może udokumentować wyjątek.

Badania nad interakcją człowieka z AI podkreślają potrzebę kalibrowania oczekiwań, kontroli, informacji zwrotnej i korekty w całym cyklu interakcji.³¹

Due diligence dostawcy powinno obejmować co najmniej:

• PRODUKT I WERSJA
• ROLA BIZNESOWA
• KATEGORIE DANYCH
• ROLE ADMINISTRATORA I PODMIOTU PRZETWARZAJĄCEGO
• PODPROCESORZY
• REGIONY
• RETENCJA
• UŻYCIE DO TRENINGU LUB WTÓRNE
• DOWODY BEZPIECZEŃSTWA
• ZGŁASZANIE INCYDENTÓW
• ZASADY ZMIAN
• EKSPORT
• USUNIĘCIE DANYCH
• PRZENOSZALNOŚĆ
• SLA
• PRAWA DO AUDYTU
• WŁASNOŚĆ INTELEKTUALNA I ODPOWIEDZIALNOŚĆ
• WSPARCIE PRZY WYJŚCIU

Twierdzenie marketingowe nie jest dowodem

„Enterprise-ready”, „secure”, „AI compliant”, „single source of truth” i „real-time” są komunikatami. Architektura potrzebuje dokumentacji, testu, zakresu i ograniczeń.

Lock-in ma wiele warstw

• format danych;
• brak historii;
• zamknięty przepływ pracy;
• integracje;
• model punktacji;
• kompetencje zespołu;
• warunki umowy;
• koszt egress;
• brak dokumentacji;
• zależność od jednego konsultanta.

Plan wyjścia powinien zostać przetestowany przed krytycznym uzależnieniem, nie dopiero po wypowiedzeniu umowy.

Architecture Decision Record może mieć prostą formę:

adr_id:
date:
decision:
context:
options:
selected_option:
rationale:
evidence:
assumptions:
risks:
consequences:
prohibited_uses:
review_trigger:
owner:
status:

ADR nie ma dokumentować każdej drobnej konfiguracji. Ma utrzymać materialne decyzje, których późniejsza zmiana wpływa na obiekty, integracje, dane, bezpieczeństwo, koszt albo wyjście.

Przykładowe ADR

• wybór systemu nadrzędnego tożsamości dla accountu;
• rezygnacja z real-time;
• ograniczenie zakresu dostawcy;
• przyjęcie wzorca sterowanego zdarzeniami;
• zakaz użycia telemetrii do oceny pracowniczej;
• utrzymanie ręcznego punktu kontrolnego;
• rozdzielenie hurtowni danych i rekordu operacyjnego;
• decyzja o wygaszeniu starego API.

EX-01 — CRM kupiony przed zdefiniowaniem procesu

Sytuacja: Firma chce wdrożyć nowy CRM, lecz nie potrafi wskazać jednej decyzji, którą system ma poprawić.

Kody: UCB-1, DRA-0, WFS-0, SAT-1

Decyzja: Wstrzymać krótką listę dostawców do czasu mapy zdolności.

Przykład jest syntetyczny. Nie stanowi punktu odniesienia, studium przypadku ani dowodu skuteczności.

EX-02 — Duplikaty kont między CRM i ERP

Sytuacja: To samo przedsiębiorstwo ma trzy identyfikatory, przez co prognoza i rozliczenia nie są porównywalne.

Kody: ODS-11, DQL-5, INS-7

Decyzja: Ustanowić uzgadnianie tożsamości i jawne przeliczenie historii.

Przykład jest syntetyczny. Nie stanowi punktu odniesienia, studium przypadku ani dowodu skuteczności.

EX-03 — Integracja wysyła zdarzenie dwa razy

Sytuacja: Ponowienie po przekroczeniu limitu czasu tworzy duplikat zadania i dwie wiadomości do klienta.

Kody: INS-8, INS-9, INS-14, OBS-9

Decyzja: Dodać klucz idempotencji i ścieżkę odtworzenia.

Przykład jest syntetyczny. Nie stanowi punktu odniesienia, studium przypadku ani dowodu skuteczności.

EX-04 — Pulpit działa bez ścieżki pochodzenia danych

Sytuacja: Raport pokazuje konwersję, ale nikt nie zna filtrów, mianownika ani transformacji.

Kody: DQL-1, DQL-2, DQL-14

Decyzja: Zakazać użycia do decyzji do czasu odtworzenia ścieżki pochodzenia danych.

Przykład jest syntetyczny. Nie stanowi punktu odniesienia, studium przypadku ani dowodu skuteczności.

EX-05 — Nadmierne uprawnienia integratora

Sytuacja: Konto serwisowe ma dostęp do wszystkich rekordów klientów i eksportu danych.

Kody: AXS-3, AXS-6, AXS-12

Decyzja: Rotacja sekretu i przeprojektowanie do minimalnych uprawnień.

Przykład jest syntetyczny. Nie stanowi punktu odniesienia, studium przypadku ani dowodu skuteczności.

EX-06 — Prywatny arkusz jako system krytyczny

Sytuacja: Zespół prowadzi kluczowy backlog w prywatnym arkuszu poza kopiami zapasowymi i poza własnością.

Kody: ARS-11, VPR-0, OBS-0

Decyzja: Zinwentaryzować i zdecydować o migracji, objęciu ładem albo wygaszeniu.

Przykład jest syntetyczny. Nie stanowi punktu odniesienia, studium przypadku ani dowodu skuteczności.

EX-07 — SaaS bez pełnego eksportu

Sytuacja: Dostawca pozwala wyeksportować rekordy, ale bez historii zmian i załączników.

Kody: VPR-6, VPR-9, LFC-7

Decyzja: Przetestować wyjście przed rozszerzeniem zakresu.

Przykład jest syntetyczny. Nie stanowi punktu odniesienia, studium przypadku ani dowodu skuteczności.

EX-08 — Monitoring handlowców jako uboczny efekt

Sytuacja: Telemetria wdrożona do wsparcia zaczyna być używana do rankingu aktywności osób.

Kody: AXS-8, AXS-11, DRA-12

Decyzja: Zatrzymać wtórne użycie i przeprowadzić osobny przegląd.

Przykład jest syntetyczny. Nie stanowi punktu odniesienia, studium przypadku ani dowodu skuteczności.

EX-09 — Aplikacja wielofunkcyjna bez rozdzielenia ról

Sytuacja: Jedna platforma jest CRM, hurtownią danych, automatyzacją i bazą wiedzy, lecz nie ma osobnych właścicieli.

Kody: ARS-9, ARS-10, DRA-11

Decyzja: Rozdzielić role logicznie i ustanowić właścicieli.

Przykład jest syntetyczny. Nie stanowi punktu odniesienia, studium przypadku ani dowodu skuteczności.

EX-10 — Incydent bez możliwości wycofania danych

Sytuacja: Błędna transformacja zasiliła pulpit, automatyzację i model rekomendacyjny.

Kody: DQL-13, OBS-9, LFC-7

Decyzja: Propagować wycofanie do wszystkich konsumentów.

Przykład jest syntetyczny. Nie stanowi punktu odniesienia, studium przypadku ani dowodu skuteczności.

J00 nie wymaga jednoczesnej migracji wszystkich systemów. Wymaga wyboru jednego materialnego przypadku użycia.

Dni 1–15 — granica i stan obecny

• wybierz zdolność;
• wskaż decyzję i użytkownika;
• zapisz użycia zakazane;
• obserwuj realny przepływ pracy;
• zinwentaryzuj obiekt, źródło, systemy i obejścia;
• wybierz jeden materialny problem.

Dni 16–30 — obiekt, dane i mandat

• zdefiniuj tożsamość;
• wskaż autorytatywne źródła atrybutów;
• odtwórz ścieżkę pochodzenia danych;
• sprawdź braki danych i jakość;
• ustal mandat;
• wykonaj wstępną ocenę dostępu i ochrony danych.

Dni 31–45 — stan docelowy i kontrakty

• zaprojektuj docelowy przepływ pracy;
• przypisz role aplikacji;
• zdefiniuj kontrakt integracji;
• dodaj obsługę błędu, ponowienie, idempotencję i tryb zastępczy;
• zapisz akceptację i warunki zatrzymania.

Dni 46–60 — kontrole i obserwowalność

• minimalne uprawnienia;
• cykl życia kont serwisowych;
• logi, miary, ślady;
• kierowanie alertów;
• runbook;
• test odtworzenia i wycofania zmiany;
• test wyjścia od dostawcy.

Dni 61–75 — ograniczony pilot

• jedna populacja;
• jawni użytkownicy;
• monitoring jakości;
• rejestr wyjątków;
• cotygodniowy przegląd decyzji;
• brak rozszerzenia przed zebraniem dowodów.

Dni 76–90 — decyzja

Dozwolone wyniki:

• CONTINUE_AS_DESIGNED
• LIMIT_SCOPE
• REDESIGN_WORKFLOW
• CORRECT_DATA
• RESTORE_LINEAGE
• ADD_CONTROL
• RENEGOTIATE_VENDOR
• ROLL_BACK
• RETIRE_COMPONENT
• WITHDRAW_OUTPUTS
• CLOSE_NO_ACTION

TOOL-J00

Mapa Architektury Technologii i Danych Sprzedaży przeprowadza przez szybkie określenie zakresu, pełny ATS, stan obecny i docelowy, przegląd obiektów i danych, przegląd integracji, dostęp, ochronę danych i bezpieczeństwo, obserwowalność, wyjście od dostawcy oraz wygaszenie.

„Kupimy platformę, a proces dojrzeje”

Platforma może wymusić pola i sekwencję, ale nie ustanowi automatycznie mandatu, dowodów po stronie klienta ani jakości decyzji.

„Zintegrujemy wszystko”

Integracja bez kryterium decyzji zwiększa powierzchnię styku, koszt zmiany i ryzyko kaskady błędów danych.

„CRM będzie jedyną prawdą”

To hasło ukrywa zakres, czas i mandat nad atrybutem.

„Wymusimy kompletność”

Obowiązkowe pola mogą zwiększyć kompletność i jednocześnie obniżyć poprawność.

„Real-time usunie problem”

Szybsza dystrybucja błędnych danych przyspiesza błąd.

„Dostawca odpowiada za bezpieczeństwo”

Odpowiedzialność jest współdzielona. Organizacja kontroluje konfigurację, dostęp, integracje, cel i reakcję.

„Człowiek w pętli rozwiązuje ryzyko”

Nie, jeśli człowiek nie widzi źródeł, nie ma czasu albo nie może odrzucić wyniku.

„Eksport oznacza brak lock-in”

Eksport może nie obejmować historii, relacji, załączników, konfiguracji i reguł.

„Usuniemy starą aplikację”

Bez odłączenia tokenów, integracji, danych i konsumentów w dole strumienia stary komponent pozostaje aktywny w architekturze.

„Pulpit nie podejmuje decyzji”

Sposób prezentacji, progi i domyślne widoki kierują uwagą i mogą wpływać na decyzje, nawet bez automatycznej reguły działania.

J00 jest pierwszym modułem Obszaru J — AI, technologia, dane i RevOps. Nie zastępuje wcześniejszego projektu organizacyjnego. System operacyjny sprzedaży B2B dostarcza role, przepływ pracy, własność i granice; router Obszaru I pomaga rozpoznać, czy problem rzeczywiście jest technologiczny.

Definicje miar należy najpierw ustalić w materiale KPI nowoczesnej sprzedaży B2B i w narzędziu Architektura Miar Sprzedaży. Decyzje managerskie, ich przegląd i eskalacja pozostają domeną materiału Rola managera sprzedaży w zmianie sposobu pracy oraz narzędzia Rytm Pracy Managera Sprzedaży. J00 implementuje wspierające rekordy, integracje i kontrole, ale nie zmienia ich znaczenia dlatego, że system udostępnia inne pole albo łatwiejszą miarę.

ATS-1–ATS-10, SAT-0–SAT-12 i pozostałe taksonomie są autorską syntezą operacyjną. Nie są:

• zwalidowaną skalą dojrzałości;
• oficjalnym standardem enterprise architecture;
• certyfikatem cybersecurity;
• opinią prawną;
• DPIA;
• threat modelem;
• punktem odniesienia stosu technologicznego;
• rekomendacją dostawcy;
• gwarancją zgodności z AI Act, GDPR, Data Act albo NIS2.

Model łączy architekturę projektu Nowoczesna Sprzedaż B2B z publicznymi regulacjami, oficjalnymi modelami, standardami technicznymi i badaniami dotyczącymi data quality, provenance, technical debt, data cascades, dokumentacji modeli i human–AI interaction. Źródła wspierają poszczególne zasady. Nie walidują całego zintegrowanego modelu ATS jako jednej metody.

Przed zastosowaniem tego materiału w konkretnym wdrożeniu należy ponownie sprawdzić dynamiczne elementy: AI Act i jego harmonogram po 2 sierpnia 2026 r., aktualne wytyczne EDPB, zakres Data Act i NIS2, krajowe przepisy pracy i monitoringu, wersje produktów, specyfikacje API, podprocesorów, lokalizację danych, warunki dostawcy oraz bezpieczeństwo konkretnej konfiguracji.

WCAG 2.2 jest standardem dostępności treści i interfejsów. Zastosowanie go jako punktu wyjścia nie jest automatycznym dowodem zgodności prawnej lub technicznej produktu; finalny tool, formularze, diagramy i eksporty wymagają audytu dostępności.³²