Platformy danych i automatyzacja

• Pliki i eksporty - eksporty CSV i Excela z ERP, księgowości albo systemu magazynowego, odbierane o ustalonych porach, sprawdzane i ładowane do hurtowni - zamiast jednej osoby, która ręcznie scala zakładki.
• Systemy, bazy danych i API - bezpośrednie połączenia z systemami, których już używasz; dane pobierane według harmonogramu, za każdym razem tylko to, co przybyło od ostatniego razu.
• Pipeline'y w Pythonie albo Azure Data Factory - domyślnie zadania w Pythonie z harmonogramem, sprawdzane przed każdym zapisem i kończące się statusem, na który da się automatycznie zareagować; Data Factory, gdy firma woli składać te przepływy w gotowym narzędziu Microsoftu, bez pisania kodu, we własnej części chmury Azure.
• Papier i zapisy ręczne - prosty formularz albo skanowanie kodu kreskowego w miejscu pracy, żeby nikt nie przepisywał potem z papieru.

Plik składany ręcznie ma jedną przewagę nad pipeline'em, który milczy, gdy przestaje działać: gdy zabraknie pliku, ktoś to zauważy.

• Power BI - pulpity zbudowane wokół decyzji, które Twój zespół naprawdę podejmuje, odświeżane automatycznie. Gdy baza działa na Twoim serwerze, łączymy ją z Power BI w Twoim tenancie przez lokalną bramę danych - program po Twojej stronie, który czyta bazę na miejscu. Gdy dane są już w chmurze, Power BI czyta je wprost z Fabric. Pulpitu, przy którym nikt nie potrafi nazwać decyzji i osoby, która ją podejmuje, nie budujemy.
• Notatniki i SQL w Databricks - na tych samych danych co pulpity, gdy analitycy muszą zadać pytanie, na które pulpit nie odpowie.
• Fundament pod AI - czyste, historyczne, uporządkowane dane to pierwsza rzecz, której potrzebuje każde wdrożenie AI: bez historii liczonej w miesiącach, a nie w dniach, i bez definicji pól, które zgadzają się między źródłami, nie ma na czym budować. Budujemy właśnie to i mówimy wprost, do czego Twoje dane są gotowe - także wtedy, gdy odpowiedź brzmi: jeszcze do niczego.

Pulpit na danych, których nikt nie sprawdza, automatyzuje złą odpowiedź. Bramki jakości stoją przed hurtownią, nie za nią.

• Sprawdzanie przed zapisem - spodziewana liczba wierszy, pola wymagane, wartości mieszczące się w normie; kontrole, które dziś ktoś robi wzrokiem, stają się regułami działającymi za każdym razem, a progi walidacji - granice, poza którymi dane uznajemy za błędne - spisujemy dla każdego źródła. Przebieg, który się w nich nie mieści, zostawia bazę nietkniętą, a plik wraca do osoby odpowiedzialnej za to źródło, żeby go poprawiła - po Twojej stronie albo po naszej. Ustalamy to przed budową.
• Definicje i historia - każde pole znaczy jedną rzecz i jest to spisane; surowe zapisy źródłowe leżą obok oczyszczonych, więc da się pokazać, co było wiadomo danego dnia.
• Dane osobowe - ochrona wbudowana w schemat: pola usuwane przed zapisem, rekordy, których w ogóle nie przechowujemy, retencja, czyli czas przechowywania, ustalona, a nie przypadkowa.

Narzędzie do ładu danych kupione, zanim ktoś ustalił zasady, kończy się pustym spisem, którego nikt nie uzupełnia.

• Skrypty - Python do pracy z danymi: scalanie eksportów, uzgadnianie liczb, przygotowanie comiesięcznego pliku, który zajmował cały dzień; PowerShell do Microsoft 365 i Azure; wszystko w repozytorium i z harmonogramem.
• Azure Functions, Logic Apps, Power Automate - Functions do kodu, który uruchamia się tylko wtedy, gdy coś go wywoła: powiadomienie, przekształcenie, mała integracja; Logic Apps i Power Automate wtedy, gdy cały proces toczy się wewnątrz Microsoft 365 i mają go prowadzić sami pracownicy, bez programisty.
• Każde zadanie raportuje swój stan - wynik, liczby i czasy trafiają do monitoringu, a o awarii ktoś dowiaduje się tego samego dnia.

Platforma do automatyzacji w abonamencie nie jest przez to prostsza od krótkiego skryptu, który ktoś ma na własność i potrafi przeczytać.