Start · Rozwiązania · Operacje i produkcja
Rozwiązanie · Operacje i produkcjaWyniki, przestoje i braki z czterech zakładów w Teams przed poranną odprawą
Dzienny raport produkcyjny bez arkusza o szóstej rano
Roboty pobierają liczniki, przestoje i potwierdzenia z MES, SCADA i ERP po każdej zmianie; kierownicy zmian komentują na karcie w Teams; jeden raport trafia na kanał zakładu przed odprawą.
Streszczenie dla zarządu
Kontrolerzy produkcji nie powinni przepisywać liczb z MES do arkusza, któremu odprawa i tak nie ufa.
Poranna odprawa zachowuje swój raport i swój rytm; zmienia się to, skąd biorą się liczby.
Raport jest na kanale przed odprawą każdego dnia roboczego, z tymi samymi liczbami co MES i ERP, bo z nich powstał.
baza raportowa (Azure SQL Database lub SQL Server grupy); model semantyczny i raport Power BI; dziennik zmian i miesięczny skoroszyt na SharePoint
Problem biznesowy
Raportowanie produkcji
Każdy producent prowadzi dzienny raport produkcyjny: wykonanie na linię, braki, przestoje z przyczynami, realizacja planu. W większości średnich grup powstaje on ręcznie z trzech źródeł, które nigdy do końca się nie zgadzają: liczników MES lub sterowników PLC, arkusza kierownika zmiany i potwierdzeń w ERP. Kierownicy zmian wpisują dane z pamięci po nocnej zmianie; kontrolerzy produkcji spędzają pierwszą godzinę dnia na kopiowaniu zamiast na planie; jeden analityk w grupie wie, dlaczego makro konsolidujące nie działa w poniedziałki.
W skali grupy pęka zaufanie. Przestoje trafiają do raportu jako „inne”, bo lista przyczyn w arkuszu różni się od listy w MES; braki raportuje zmiana, która ma interes w tej liczbie; liczbę zakwestionowaną na odprawie poprawia się później w pliku, który już został rozesłany. Cztery zakłady kończą z czterema definicjami OEE, a cel grupowy staje się przedmiotem negocjacji.
Jak to wygląda dzisiaj
- CzłowiekNa koniec zmiany kierownik zmiany wypełnia arkusz zmianowy w Excelu: wykonanie, braki i przestoje na linię, przyczyny z pamięci
- OczekiwanieArkusze leżą na dysku sieciowym do przyjścia kontrolera produkcji; arkusze ze zmiany nocnej są najczęściej niekompletne
- CzłowiekKontroler kopiuje trzy arkusze do skoroszytu zakładu, porównuje sumy z licznikami MES i potwierdzeniami ERP i poprawia rozbieżności
- CzłowiekCztery skoroszyty zakładowe trafiają e‑mailem do analityka grupy, który je scala i wysyła PDF uczestnikom odprawy
- Ryzyko błęduLiczba na ekranie różni się od MES; przyczyn brakuje lub są ogólne; nikt nie odróżni realnego problemu od błędu w liczeniu
- OczekiwanieKorekty uzgodnione na odprawie nanosi się później, ręcznie, tylko w pliku grupowym
Dlaczego obecny proces kosztuje więcej, niż widać
To nie jest praca, którą ktoś zaplanował.
- Siedemdziesiąt pięć minut poranka kontrolera na zakład to koszt widoczny. Za nim stoi sama odprawa: od ośmiu do dwunastu menedżerów poświęcających jej część na spór o poprawność danych.
- Korekty nanoszone po dystrybucji nigdy nie docierają do wszystkich kopii, więc dane narastające od początku tygodnia rozjeżdżają się, a statystyki produkcji na zamknięcie miesiąca trzeba uzgadniać od nowa.
- Przestoju bez przyczyny nie da się ograniczyć. Czterdzieści minut zaksięgowanych jako „inne” ukrywa przezbrojenie, brak materiału albo awarię.
- Grupa, która nie ufa dziennym liczbom, nie może wyznaczać celów na poziomie linii, więc OEE pozostaje miesięczną liczbą omawianą po fakcie.
Koszt zaniechania
110 godzin miesięcznie ludzi o kompetencjach planistycznych zostaje na kopiowaniu, odprawa codziennie zaczyna się od sprawdzania danych, a program doskonalenia pracuje na przyczynach odtwarzanych następnego ranka.
Większy koszt jest niewidoczny: cele OEE na poziomie linii i uczciwe porównania między zakładami to decyzje, których grupa nie może podjąć, dopóki jej liczby są sporne.
Przykładowa organizacja o realnych proporcjach — liczby służą do policzenia sprawy na Waszych danych, nie są wynikiem klienta.
Europejski producent mebli: cztery zakłady w Polsce i Niemczech, 22 linie, około 1 800 pracowników; MES na 14 liniach, liczniki SCADA na 6, liczenie ręczne na 2; ERP klasy średniej; Microsoft 365 E3 i Power BI Pro.
88 zakłado-dni miesięcznie (4 zakłady × 22 dni robocze); około 1 300 rekordów linia-zmiana miesięcznie; jeden raport na zakład i jeden dla grupy każdego dnia roboczego.
Arkusze zmianowe w Excelu; około 75 minut poranka kontrolera na zakład na ich konsolidację i uzgodnienie z MES i ERP; następnie PDF od analityka grupy.
Około 110 godzin miesięcznie czasu kontrolerów w całej grupie plus godzina analityka; spóźniony raport, który w większość dni nie zgadza się z MES.
Roboty pobierają liczniki, przestoje i potwierdzenia z MES, SCADA i ERP po każdej zmianie, liczą OEE, braki i odchylenia od planu według stałych reguł, proszą kierowników zmian o brakujące przyczyny na karcie w Teams i publikują podsumowanie na kanale każdego zakładu przed odprawą.
W modelowanym przypadku 110 godzin miesięcznie wraca do pracy planistycznej, raport trafia na kanał przed odprawą z tymi samymi liczbami co MES i ERP, a każdy przestój powyżej progu ma kod przyczyny albo widoczną lukę. To wartości z modelu, nie wynik u klienta.
Proponowane rozwiązanie
Poranna odprawa zachowuje swój raport i swój rytm; zmienia się to, skąd biorą się liczby. Robot raportowy robi to, co dziś kontrolerzy, ale ze źródeł zamiast z arkuszy. Po każdej zmianie wyzwalacz czasowy w Orchestratorze uruchamia zadanie zbierania danych: liczniki, czas pracy i zdarzenia przestojów z MES przez widoki SQL, liczniki z bazy historycznej SCADA dla sześciu linii bez MES, potwierdzenia i plan z ERP. OEE, braki i odchylenie od planu są liczone na linię i zmianę według stałych, wersjonowanych reguł, identycznych dla czterech zakładów.
Rola kierownika zmiany kurczy się do tego, co wie tylko on: przepływ Workflows w Microsoft Teams wysyła Adaptive Card z wypełnionymi liczbami oraz polem kodu przyczyny i komentarza dla każdego przestoju powyżej progu. Odpowiedzi trafiają na listę SharePoint, czyli do dziennika zmian; brak odpowiedzi wchodzi do raportu jako luka, nie jako liczba. Przed odprawą robot raportowy scala całość, zapisuje bazę raportową, odświeża model semantyczny Power BI przez REST API i publikuje kartę z podsumowaniem na kanale każdego zakładu; miesięczny skoroszyt na SharePoint zachowuje Excel jako wynik, a nie źródło. Nie ma tu sztucznej inteligencji: wejściem są dane systemowe, reguły należą do zakładów, a ocena pozostaje po stronie ludzi.
Wyzwalacze czasowe i audyt UiPath Orchestrator; UiPath Robots z aktywnościami Database i Excel Online; konektory UiPath Integration Service dla Microsoft Teams i Microsoft OneDrive & SharePoint; Workflows w Microsoft Teams (Power Automate) z Adaptive Cards i oczekiwaniem na odpowiedź; odświeżanie Power BI przez REST API i zakładka raportu w Teams
Zadania zbierania danych, reguły obliczeń i mapowanie kodów przyczyn; Adaptive Card i dziennik zmian; bazę raportową, model semantyczny i raport Power BI; kartę podsumowania, miesięczny skoroszyt i instrukcję operacyjną dla kontrolerów
Widoki SQL na MES i bazie historycznej SCADA, przygotowane z automatykiem zakładu; potwierdzenia z ERP przez widok bazodanowy lub API
Jak działa proces po automatyzacji
- AutomatyzacjaKilka minut po zakończeniu zmiany wyzwalacz czasowy w Orchestratorze uruchamia zbieranie danych: liczniki, czas pracy i przestoje z MES, liczniki SCADA, potwierdzenia i plan z ERP
- AutomatyzacjaRobot liczy dostępność, wydajność i jakość na linię i zmianę oraz flaguje odchylenia według reguł zakładu: OEE poniżej celu, braki powyżej progu, nieplanowany przestój ponad limit, niezgodne ilości MES i ERP
- AutomatyzacjaRekord zmiany trafia na listę SharePoint; nowa pozycja uruchamia przepływ Workflows, który wysyła kierownikowi zmiany Adaptive Card w Teams z liczbami, oflagowanymi przestojami oraz polami na przyczyny, komentarze i liczenie ręczne
- CzłowiekKierownik zmiany wypełnia kartę przed wyjściem; odpowiedź wraca na listę ze znacznikiem czasu; po uzgodnionym oknie przepływ zamyka kartę i oznacza rekord „brak komentarza”
- AutomatyzacjaPrzed odprawą robot raportowy scala komentarze i rekordy, zapisuje bazę raportową, uruchamia odświeżenie Power BI, aktualizuje miesięczny skoroszyt i publikuje kartę podsumowania na kanale każdego zakładu
- SystemJeśli źródło jest niedostępne, Orchestrator ponawia próbę; jeśli nadal nie działa, raport wychodzi z oznaczonym brakiem źródła, a kontroler dostaje alert w Teams
Model współpracy człowieka z automatyzacją
Automatyzacja obsługuje
- Zbieranie danych z MES, SCADA i ERP po każdej zmianie
- Arytmetykę OEE, braków i odchyleń od planu według stałych, wersjonowanych reguł
- Prośbę o przyczyny, konsolidację, odświeżenie Power BI, podsumowanie i wykrywanie luk
Ludzie decydują o
- Kodzie przyczyny każdego oflagowanego przestoju i kontekście, który zna tylko kierownik zmiany
- Działaniach wobec oflagowanych linii, na liczbach wspólnych dla wszystkich; decyzja należy do dyrektorów zakładów
- Progach, standardach czasu cyklu i mapowaniu kodów przyczyn, które kontrolerzy zmieniają w kontrolowanym wydaniu
Przed i po
Systemy i integracje
Wszystko poniżej działa na licencjach i systemach, które już macie albo które i tak trzeba mieć.
Wejścia
- liczniki, czas pracy i zdarzenia przestojów z MES
- liczniki z bazy historycznej SCADA
- potwierdzenia i plan z ERP
- plan linii planistów w Excelu na SharePoint
- odpowiedzi kierowników zmian z karty w Teams
Warstwa automatyzacji
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- Workflows w Microsoft Teams (Power Automate)
Systemy docelowe
- baza raportowa (Azure SQL Database lub SQL Server grupy)
- model semantyczny i raport Power BI
- dziennik zmian i miesięczny skoroszyt na SharePoint
- kanały zakładów w Microsoft Teams
Punkty styku z człowiekiem: Adaptive Card w Teams dla kierowników zmian; karta podsumowania na kanale zakładu; zakładka raportu Power BI; alerty dla kontrolera w Teams
Wykorzystane technologie
wyzwalacze czasowe po każdej zmianie, zadania zbierania i obliczeń, ponowienia, logi, audyt
Aodczyt MES, bazy historycznej SCADA i potwierdzeń ERP przez widoki SQL; zapis bazy raportowej
Apozycje listy dziennika zmian, skoroszyty planu i miesięczny w Excel Online, karty podsumowania na kanałach zakładów
AAdaptive Card dla kierownika zmiany z oczekiwaniem na odpowiedź, uruchamiana przez nową pozycję listy
Amodel semantyczny nad bazą raportową, zakładka raportu na kanale zakładu, odświeżanie przez REST API z jednostką usługi
Aliczniki, zdarzenia przestojów, potwierdzenia i plan, przez widoki SQL lub API ERP
CIlustracyjny model ekonomiczny
Model, a nie obietnica.
Liczony jest wyłącznie czas konsolidacji kontrolerów; godzina analityka, czas odprawy i korekty po odprawie zostały pominięte, więc wynik jest konserwatywny. Siedemdziesiąt pięć minut na zakłado-dzień odpowiada trzem arkuszom zmianowym uzgadnianym z MES i ERP; 30 € to pełny koszt godziny pracy kontrolera lub planisty w Europie Środkowej. Pokazujemy uwolnioną zdolność, nie redukcję etatów; wszystkie wartości są ilustracyjne i żadnej nie zmierzono u klienta.
Policz to na swoich danych
Szacunek ilustracyjny na podstawie Twoich danych. To model uwolnionej przepustowości, nie obietnica oszczędności.
Korzyści biznesowe
- Raport jest na kanale przed odprawą każdego dnia roboczego, z tymi samymi liczbami co MES i ERP, bo z nich powstał
- Około 110 godzin miesięcznie czasu kontrolerów w modelowanej grupie wraca do pracy planistycznej
- Przestój ma kod przyczyny od zmiany, która straciła ten czas, więc program doskonalenia pracuje na pełnym Pareto, a nie na „innych”
- Jedna definicja OEE, braków i przestojów nieplanowanych w czterech zakładach; linia stale poniżej celu jest oflagowana pierwszego dnia, nie na koniec miesiąca
Perspektywa zarządu
- Poranna odprawa zaczyna się od listy wyjątków, a nie od sporu o to, który plik jest właściwy
- Widoki od początku tygodnia i miesiąca powstają z tych samych rekordów co dzienne; statystyki na zamknięcie miesiąca nie wymagają drugiego uzgodnienia
- Każda liczba ma ślad: system źródłowy, czas pobrania, wersja reguł, komentarz kierownika zmiany i jego znacznik czasu
Wpływ na KPI zarządu
Bezpieczeństwo i nadzór
Bezpieczeństwo projektujemy razem z procesem, nie po nim.
- Roboty czytają systemy produkcyjne przez dedykowane konta z prawem odczytu wyłącznie uzgodnionych widoków; jedynym celem zapisu jest baza raportowa
- Sekrety do baz i API przechowywane są w magazynie poświadczeń Orchestratora, w razie potrzeby z Azure Key Vault; odświeżanie Power BI działa na jednostce usługi ograniczonej do jednego obszaru roboczego
- Państwa tenant Microsoft 365 i Państwa własna baza przez cały czas przechowują dane produkcyjne; stojący za tym Orchestrator pracuje w regionie UE UiPath Automation Cloud lub we własnym Automation Suite
- Progi i mapowania kodów przyczyn są wersjonowane i zmieniane wyłącznie za zgodą właściciela procesu; odpowiedzi kierowników zmian są zapisywane z tożsamością i znacznikiem czasu
Dlaczego teraz
Cele OEE wchodzą do rocznych planów na poziomie grupy; cel ustalony na czterech arkuszach z czterema definicjami to negocjacja, a stojąca za nim konsolidacja kosztuje w modelu 3 300 € miesięcznie, zanim policzy się czas odpraw
Planistów i kontrolerów produkcji brakuje w zakładach, które znamy; ich pierwsza godzina dnia na kopiowaniu to najtrudniejsze do obrony wykorzystanie tych, których Państwo mają
Elementy są standardowe: wyzwalacze czasowe Orchestratora, konektory Integration Service, Adaptive Cards z oczekiwaniem na odpowiedź i API odświeżania Power BI; a odkąd Microsoft wycofał w maju 2026 stare konektory Teams, zakłady wysyłające alerty z MES przez dawne webhooki i tak potrzebują ścieżki przez Workflows
Role zarządcze, których to dotyczy
Jeden dzienny obraz czterech zakładów zbudowany z systemów; przegląd operacyjny dotyczy oflagowanych linii, nie danych
Odprawa zaczyna się od tego, co poszło źle i dlaczego, z kodami przyczyn od zmiany, która straciła czas
Statystyki kosztu jednostkowego i zamknięcia miesiąca pochodzą z tych samych rekordów co dzienny raport
Nadzorowana integracja z MES, SCADA i ERP zastępuje makra, skoroszyty na dysku sieciowym i łańcuchy e‑maili
Częste pytania i zastrzeżenia
MES raportuje linie, do których jest podłączony, w jednym zakładzie, własną logiką. Poranny raport potrzebuje w jednym miejscu czterech zakładów, linii bez MES, potwierdzeń z ERP i przyczyn od kierowników zmian. Robot traktuje MES jako najlepsze źródło, nie jako konkurencję.
Karta przychodzi z wpisanymi liczbami i pyta tylko o to, czego systemy nie wiedzą: o przyczynę 40-minutowego postoju zarejestrowanego przez MES. Minuta na telefonie wystarcza, a brak odpowiedzi jest widoczny jako luka, zamiast znikać w sumie.
Raport wychodzi na czas z oznaczonym brakiem źródła, a kontroler dostaje alert. Ilości niezgodne z ERP są flagowane, nigdy uśredniane; w pierwszych tygodniach to sprzężenie zwrotne jest zwykle najcenniejszym wynikiem.
Kiedy to nie jest właściwe rozwiązanie
- Jeden zakład z MES obejmującym każdą linię i raportem zmianowym, któremu odprawa ufa: wystarczy raport Power BI na bazie MES
- Liczniki i przestoje są rejestrowane wyłącznie na papierze; najpierw trzeba uchwycić dane przy linii, konsolidacja jest krokiem drugim
- Zakłady nie zgadzają się co do tego, co jest brakiem lub przestojem nieplanowanym, i nikt nie jest właścicielem definicji; automatyzacja tylko szybciej ujawniłaby ten spór
Pytanie na najbliższe posiedzenie
Której liczbie wierzy nasza poranna odprawa, z MES, z ERP czy z arkusza, i ile godzin miesięcznie poświęcamy na to, żeby te trzy się zgadzały?
Podejście wdrożeniowe
Pierwszy tydzień wygląda tak samo u każdego klienta: patrzymy na dane.
Dostarczamy
- Analizę w jednym zakładzie: źródła na linię, obecne arkusze i definicje OEE, braków i przestojów nieplanowanych
- Zadania zbierania danych, reguły obliczeń i mapowanie kodów przyczyn, wersjonowane i udokumentowane
- Przepływ z Adaptive Card, dziennik zmian, bazę raportową, model semantyczny i raport Power BI, karty podsumowania
- Równoległy bieg z raportem ręcznym w zakładzie pilotażowym, instrukcję operacyjną dla kontrolerów, następnie wdrożenie zakład po zakładzie z hypercare
Potrzebujemy od Państwa
- Dostępu do odczytu tabel lub widoków MES, bazy historycznej SCADA i ERP, uzgodnionego z działem automatyki i IT
- Właściciela procesu w operacjach, jednego kontrolera na zakład oraz trzech miesięcy arkuszy zmianowych z odpowiadającymi danymi MES i ERP
- Obszaru roboczego Power BI, jednostki usługi do odświeżania i kanałów zakładów w Teams
Etapy
Analiza
Źródła, definicje, progi i obecny raport w zakładzie pilotażowym
Projekt i budowa
Model danych, reguły, przepływ z kartą, baza raportowa, model i raport Power BI w Państwa tenancie
Walidacja
Równoległy bieg z raportem ręcznym przez dwa do czterech tygodni; odbiór przez dyrektora zakładu
Wdrożenie
Zakład po zakładzie z hypercare; następnie strojenie progów, nowe linie, widoki tygodniowe i miesięczne
Szybki efekt. Nakład zależy od liczby odrębnych źródeł na liniach, od tego, czy MES i ERP udostępniają użyteczne widoki, oraz od stopnia zgodności definicji między zakładami.
Poranna odprawa zaczyna się od sporu o to, czyja liczba jest prawdziwa.
Prosimy o tydzień arkuszy zmianowych z jednego zakładu wraz z eksportem z MES i potwierdzeniami z ERP za te same dni. Odsyłamy pisemną ocenę, gdzie te trzy źródła się rozchodzą i które linie da się raportować bez udziału człowieka.
Zacznijmy od jednego zakładu i tygodniaTen sam problem ma zwykle sąsiedni proces
Pakiet dla zarządu nie powinien zależeć od tego, który analityk i którego dnia scalił który arkusz.
Zobacz rozwiązanie Łańcuch dostawZgodne stany magazynowe: WMS i ERP uzgadniane co nocKoniec z odkrywaniem podczas inwentaryzacji lub przy wysyłce, że WMS i ERP pokazują co innego.
Zobacz rozwiązanie Operacje i produkcjaNiezgodności i CAPA obsługiwane w TeamsZabezpieczenie, przyczyna źródłowa, 8D dostawcy i weryfikacja skuteczności żyją w jednym arkuszu i trzech skrzynkach.
Zobacz rozwiązanieBranże, w których wdrażamy to najczęściejProdukcja i przemysł