OneOperations

Wewnętrzna platforma operacyjna CLI-first, która ujednolica powtarzalne workflow finansowe i procesy cen transferowych, ułatwiając ich wyjaśnianie i utrzymanie.

Podsumowanie

OneOperations to wewnętrzna platforma centralizująca powtarzalne procesy finansowe i procesy cen transferowych dotyczące wielu podmiotów i aktywności gospodarczych.

Zapewnia spójny sposób wykonywania operacyjnych workflow, pozwalając jednocześnie każdemu z nich korzystać z architektury i modelu przetwarzania najlepiej dopasowanych do własnych wymagań.

Platforma obejmuje wyspecjalizowane workflow domenowe, takie jak TaxFlow i Cost Plus Solution.

Status

Wewnętrzna platforma operacyjna

To case study jest anonimowe i nie ujawnia nazw firm, danych wewnętrznych, zastrzeżonych formuł, szczegółów podmiotów ani poufnych zrzutów ekranu.

Problem

Przed OneOperations wiele operacji wykonywano w plikach Excel, które nie były nawet ustandaryzowanymi szablonami.

Przy każdym zadaniu analityk często musiał zrozumieć, jak ktoś inny poradził sobie z podobnym przypadkiem. Proces bywał nieudokumentowany lub opisany zbyt ogólnie, co utrudniało:

• odtworzenie wcześniejszej pracy;
• odróżnienie reguł biznesowych od indywidualnego osądu;
• stosowanie tego samego podejścia w różnych podmiotach;
• wdrożenie kolejnego analityka;
• spójne wprowadzanie zmian;
• zrozumienie, dlaczego powstał konkretny wynik.

Problemem nie było więc wyłącznie ręczne przetwarzanie. Chodziło o brak jednego, zrozumiałego sposobu działania.

Wyzwanie architektoniczne

Najważniejsze pytanie w każdym workflow nie dotyczyło technologii. Dotyczyło sposobu działania procesu.

Różne workflow mają różne ograniczenia, dane wejściowe, reguły i użytkowników. Zastosowanie jednej architektury wszędzie tworzyłoby niepotrzebną złożoność w jednych przypadkach, a w innych zapewniało zbyt mało struktury.

Dlatego OneOperations dobiera do każdego workflow najbardziej odpowiednią architekturę i model operacyjny.

Wymaga to równoważenia:

• wygody osoby uruchamiającej proces;
• przejrzystości logiki biznesowej;
• powtarzalności;
• łatwości utrzymania;
• łatwości wyjaśnienia;
• kosztu wprowadzania dodatkowej infrastruktury technicznej.

Wybór właściwego modelu procesu jest często najbardziej brzemienną w skutki decyzją projektową w całym workflow.

Model operacyjny

OneOperations jest CLI-first.

Interfejs wiersza poleceń utrzymuje ścieżkę wykonania jawną i umożliwia zdefiniowanie spójnego sposobu uruchamiania każdej operacji. Analityk nie powinien za każdym razem odtwarzać sposobu, w jaki ktoś wcześniej wykonał zadanie.

Zakładany model operacyjny jest prosty:

1. analityk wykonuje sanity check danych wejściowych;
2. uruchamia odpowiedni workflow przy użyciu zdefiniowanego procesu;
3. weryfikuje wyniki;
4. identyfikuje i komunikuje zmiany w logice biznesowej;
5. aktualizuje workflow, gdy zmienia się wymaganie leżące u jego podstaw.

Oddziela to osąd dotyczący danych wejściowych od implementacji logiki biznesowej, zachowując połączenie między nimi.

Moja rola

Moja rola obejmuje obie strony procesu.

Rozumiem wymagania finansowe i dotyczące cen transferowych, wykonuję początkowe sanity checks, identyfikuję zmiany w logice biznesowej i wdrażam odpowiednie zmiany w workflow.

Oznacza to, że potrafię:

• przekładać wymagania finansowe na jawne reguły przetwarzania;
• dobierać odpowiedni model operacyjny do workflow;
• wdrażać i utrzymywać proces techniczny;
• wyjaśniać proces użytkownikom nietechnicznym;
• rozpoznawać, czy żądana zmiana dotyczy danych, procesu czy reguły biznesowej.

Możliwość pełnienia zarówno roli analityka, jak i developera pomaga zmniejszyć lukę między potrzebami biznesu a tym, co implementuje system.

Projektowanie z myślą o użytkownikach nietechnicznych

Proces nie jest udany tylko dlatego, że działa technicznie.

Musi być również zrozumiały dla osoby odpowiedzialnej za jego uruchamianie. Dlatego OneOperations traktuje wyjaśnianie jako część projektowania systemu.

Analityk nietechniczny powinien rozumieć:

• jakie dane wejściowe są wymagane;
• jakie kontrole wykonać przed uruchomieniem;
• co workflow ma robić;
• co oznaczają wyniki;
• kiedy nieoczekiwany rezultat wskazuje na problem z danymi;
• kiedy zmiana wymaga aktualizacji logiki biznesowej.

Celem jest takie wyjaśnienie procesu, aby nie zależał od prywatnej wiedzy jednej osoby.

Model systemu

OneOperations rozdziela główne etapy workflow:

1. dane wejściowe są zbierane i sprawdzane;
2. workflow stosuje właściwą logikę biznesową i finansową;
3. wykonywane są transformacje i obliczenia;
4. wyniki są tworzone w spójnej strukturze;
5. rezultaty są porównywane z oczekiwanym zachowaniem.

Dokładna architektura różni się między workflow. TaxFlow używa konfigurowalnych pipeline’ów do logiki finansowej uwzględniającej podatki. Cost Plus Solution obsługuje inną klasę powtarzalnych obliczeń z obszaru cen transferowych.

Wspólną zasadą jest jawny model operacyjny każdego workflow, zamiast nieformalnego zbioru kroków w arkuszu.

flowchart TD
    A[Analityk uruchamia workflow CLI] --> B[Sanity check danych wejściowych]
    B --> C{Wybór workflow i architektury}

    C --> D[Pipeline TaxFlow]
    C --> E[Pipeline Cost Plus]
    C --> F[Workflow usług wspólnych]

    D --> G[Zastosowanie logiki domenowej i transformacji]
    E --> G
    F --> G

    G --> H[Test implementacji względem oczekiwanego zachowania]
    H --> I[Weryfikacja wyników]
    I --> J[Wykonanie operacji]
    I --> K{Zmiana logiki biznesowej?}
    K -->|Tak| L[Aktualizacja reguł workflow]
    L --> C
    K -->|Nie| J

Testowanie i kontrola ryzyka

Excel utrudniał niezależne testowanie implementacji reguły biznesowej względem wykonywanego zadania. W praktyce oznaczało to poleganie na implementacji arkusza bez możliwości pełnej weryfikacji, czy logika odpowiadała założonemu procesowi.

OneOperations umożliwia testowanie implementacji względem oczekiwanych danych wejściowych i wyników. Błędy oraz nieoczekiwane zachowania można wykrywać wcześniej, zanim wpłyną na powtarzalny proces operacyjny.

Poprawia to niezawodność workflow i ułatwia spójne wykonywanie strategii finansowej lub strategii cen transferowych. Z perspektywy Group Tax i cen transferowych testowanie pomaga również ograniczać ryzyko podatkowe, zmniejszając szansę na wielokrotne powtórzenie błędnej implementacji w podmiotach lub cyklach raportowych.

Kontrole i audytowalność

Platforma jest projektowana wokół powtarzalnego i wyjaśnialnego przetwarzania.

Najważniejsze kontrole obejmują:

• sanity checks danych wejściowych;
• jawne reguły biznesowe;
• spójne modele wykonania;
• wyniki możliwe do zweryfikowania;
• wyraźne rozdzielenie problemów z danymi od zmian logiki;
• powtarzalne przetwarzanie;
• testowalne implementacje i oczekiwane wyniki;
• udokumentowane założenia tam, gdzie potrzebny jest osąd.

Celem nie jest usunięcie analityka z procesu. Chodzi o to, aby weryfikował właściwe elementy, zamiast za każdym razem odtwarzać proces od zera.

Rezultat

OneOperations zastępuje zależne od konkretnych osób procesy w Excelu jednym, wielokrotnego użytku sposobem wykonywania powtarzalnych operacji.

Ułatwia:

• spójne uruchamianie workflow;
• wdrażanie nowych analityków;
• identyfikowanie zmian w logice biznesowej;
• dobór odpowiedniej architektury do każdego procesu;
• wyjaśnianie operacji użytkownikom nietechnicznym;
• testowanie logiki biznesowej i wykrywanie błędów implementacji;
• ograniczanie ryzyka podatkowego grupy i ryzyka związanego z cenami transferowymi;
• utrzymywanie wspólnych workflow finansowych i procesów cen transferowych w czasie.

Czego się nauczyłem

Najważniejsza lekcja była taka, że projektowanie procesu i wybór architektury są ważniejsze niż sam wybór technologii.

Technicznie zaawansowany system nadal może być niewygodny, trudny do wyjaśnienia lub niedopasowany do osób, które muszą go używać.

Najskuteczniejszy workflow to taki, który równoważy łatwość utrzymania technicznego z wygodą operacyjną i jasnością biznesową.

OneOperations uwidocznił również lukę między pracą techniczną a nietechniczną. Zbudowanie niezawodnego procesu wymaga nie tylko wdrożenia logiki, lecz także jasnego jej wyjaśnienia i zaprojektowania procesu tak, aby osoba go uruchamiająca rozumiała, co się dzieje.

To połączenie wiedzy domenowej, oceny architektury, implementacji i umiejętności wyjaśniania stanowi główną wartość platformy.