Szablon zapytania ofertowego (RFP) dla oprogramowania OEE: 47 wymagań i ważona macierz ocen

Zapytanie ofertowe (RFP) na oprogramowanie OEE pełni dwie funkcje: zmusza dostawców do odpowiedzi na Twoje konkretne wymagania zamiast na ich standardową ofertę, oraz tworzy ustrukturyzowaną podstawę do porównywania odpowiedzi różnych dostawców.

Wielu producentów wysyła słabo skonstruowane zapytania ofertowe dotyczące OEE, albo zbyt ogólne (prosząc o „możliwość obliczania OEE” bez określenia wymaganej szczegółowości), albo zbyt nakazowe (określające architekturę techniczną, która ogranicza odpowiedzi do dostawców, którzy zbudowali swoją platformę w określony sposób).

Właściwa struktura RFP koncentruje się na wymaganiach: jakie rezultaty są potrzebne, a nie jak dostawca musi je dostarczyć.

Skuteczne zapytanie ofertowe na oprogramowanie OEE składa się z siedmiu sekcji. Po pierwsze, przegląd firmy i zakładu, który daje dostawcom kontekst dotyczący środowiska produkcyjnego (branża, liczba linii, typy maszyn, istniejąca infrastruktura IT, system ERP). Po drugie, definicja zakresu obejmująca, które lokalizacje i obszary produkcyjne są objęte początkowym wdrożeniem, a które mogą zostać dodane później.

Po trzecie, wymagania funkcjonalne pogrupowane według kategorii (zbieranie danych, obliczanie OEE, raportowanie, integracje, dostęp mobilny, powiadamianie). Po czwarte, wymagania techniczne obejmujące architekturę wdrożenia, bezpieczeństwo, standardy integracji i eksport danych. Po piąte, wymagania dotyczące wdrożenia i wsparcia, w tym podejście do wdrożenia, szkolenia i oczekiwania dotyczące SLA.

Po szóste, wymagania komercyjne obejmujące model cenowy, warunki umowy i strukturę licencjonowania. Po siódme, wymagania dotyczące referencji klientów, proszące o referencje z branży i z zakładów o podobnej wielkości.

Sekcja wymagań funkcjonalnych to miejsce, gdzie większość producentów niedostatecznie precyzuje oczekiwania. Ogólne wymagania, takie jak „możliwość śledzenia przestojów”, niewiele mówią, każdy dostawca OEE to deklaruje.

Konkretne wymagania, np. „system musi rejestrować zdarzenia przestoju automatycznie za pomocą sygnału PLC bez ręcznego wprowadzania przez operatora, kategoryzować je na co najmniej 3 poziomach hierarchii oraz umożliwiać retrospektywną zmianę kategorii w ciągu 24 godzin”, zmuszają dostawców do opisania swoich rzeczywistych możliwości zamiast teoretycznego zapewnienia zgodności.

Sporządzanie wymagań o takim stopniu szczegółowości wymaga przygotowania, albo od wewnętrznych użytkowników, którzy wiedzą, czego brakuje w obecnym systemie, albo od konsultanta ds. wdrożeń OEE, który widział wiele systemów działających w produkcji.

Podział wymagań zapytania ofertowego (RFP) na kategorie ułatwia ocenę. Wymagania dotyczące zbierania danych powinny obejmować: automatyczne wykrywanie stanu maszyny przez PLC/OPC‑UA; konfigurowalną hierarchię przyczyn przestojów (minimum 3 poziomy); przepływ pracy potwierdzania przestoju przez operatora; zbieranie liczby wyprodukowanych sztuk z sygnałów maszynowych; rejestrowanie odrzuceń jakościowych w miejscu produkcji; kategoryzację stanów przezbrojenia i planowanej konserwacji; konfigurację harmonogramu zmian; oraz obsługę wieloproduktowych uruchomień z docelowymi czasami cyklu dla poszczególnych produktów.

Wymagania dotyczące obliczania OEE: obliczanie OEE zgodne z ISO 22400; konfigurowalna metodologia obliczeń (OEE klasy światowej vs. OEE praktyczne vs.

OEE teoretyczne); obliczanie i wyświetlanie podmetryk dostępności, wydajności i jakości; agregacja na poziomie zmiany, dzienna, tygodniowa i miesięczna; obliczenia zbiorcze na poziomie linii, obszaru i zakładu; obliczanie OEE w czasie rzeczywistym (nie tylko na koniec zmiany); wskaźnik jakości za pierwszym podejściem (first-time quality rate) odrębnie od ogólnego wskaźnika jakości; oraz obliczanie trendów historycznych obejmujących minimum 24 miesiące.

Wymagania dotyczące raportowania i analityki: konfigurowalny pulpit dla każdej roli użytkownika; analiza Pareto przyczyn przestojów według czasu trwania i częstotliwości; wykres wodospadowy OEE (drzewo strat pokazujące składniki: dostępność, wydajność i jakość); raporty porównujące zmiany; benchmarking linii pomiędzy zakładami; zaplanowane dostarczanie raportów e‑mailem; eksport surowych danych do CSV/Excel; oraz dostęp do API do integracji z narzędziami BI.

Wymagania integracyjne: klient OPC‑UA; integracja z zleceniami produkcyjnymi SAP/Oracle/D365 (jeśli dotyczy); wyzwalanie zlecenia w CMMS przy zdarzeniu przestoju; Single Sign‑On (SSO) przez SAML 2.0 lub OIDC; oraz szyfrowany transfer danych przez HTTPS.

Wymagania mobilne i powiadomień: aplikacja mobilna iOS i Android; powiadomienie w czasie rzeczywistym dla nadzorcy zmiany o zdarzeniu przestoju przekraczającym próg; codzienne push z podsumowaniem OEE; oraz tryb offline z synchronizacją danych po ponownym połączeniu.

Ważona macierz ocen przekształca odpowiedzi na RFP w porównywalne wyniki odzwierciedlające priorytety twojej organizacji. Wagi powinny odzwierciedlać względne znaczenie każdej kategorii wymagań w twojej konkretnej sytuacji, producent z rozbudowanymi integracjami SAP powinien przyznać większą wagę możliwościom integracyjnym niż ten korzystający z samodzielnego systemu ERP, podczas gdy zakład o niskiej dyscyplinie danych operatorów powinien bardziej ważyć zautomatyzowany zbiór danych niż elastyczność raportowania.

Typowa struktura wag dla producenta z segmentu średniego rynku: Możliwości zbierania danych (25%), fundament, bez którego dane OEE są niewiarygodne; Obliczanie OEE i analityka (20%), kluczowa dostarczana wartość; Integracja z ERP/CMMS (20%), połączenie z istniejącymi systemami; Wdrożenie i wsparcie (15%), ryzyko realizacji; Raportowanie i pulpity (10%), doświadczenie użytkownika; Warunki handlowe (10%), całkowity koszt posiadania.

W ramach każdej kategorii poszczególne wymagania oceniane są w skali 0, 3 (0 = brak wsparcia, 1 = w planie rozwoju, 2 = obsługiwane po konfiguracji, 3 = natywnie obsługiwane, gotowe do użycia), a wynik kategorii jest ważoną średnią ocen poszczególnych wymagań.

Poza wynikiem ilościowym umieść dostawców na krótkiej liście i poproś o ustrukturyzowane demo przed podjęciem ostatecznej decyzji. Odpowiedzi w RFP opisują możliwości; demo ujawniają użyteczność. Najlepsze oprogramowanie OEE dla twojego zakładu to takie, którego operatorzy będą faktycznie poprawnie używać, dlatego trzeba ocenić interfejs operatora w kontekście konkretnego środowiska produkcyjnego, z uwzględnieniem typów maszyn, systemu zmianowego i przepływu wprowadzania danych.

Oceń demo oddzielnie od wyniku RFP i połącz obie oceny w ostatecznej rekomendacji dostawcy dla wyższego kierownictwa.