Błąd „darmowości”: Stworzenie narzędzia do śledzenia OEE w programie Excel lub PowerBI wydaje się darmowe, ale koszty godzin pracy inżynierów i zadłużenia z tytułu konserwacji często przekraczają cenę subskrypcji SaaS.
„Czynnik magistrali”: Narzędzia tworzone lokalnie zazwyczaj opierają się na jednym kluczowym inżynierze. Jeśli ta osoba odejdzie, system OEE przestanie działać.
Doświadczenie mobilne: Łatwo jest stworzyć pulpit nawigacyjny dla komputera stacjonarnego, ale niezwykle trudno jest stworzyć niezawodną, działającą w trybie offline aplikację mobilną dla techników.
Kluczowa kompetencja: Zadaj sobie pytanie: Czy jesteś firmą tworzącą oprogramowanie, czy producentem? Skoncentruj swoje zasoby na tworzeniu produktów, a nie na debugowaniu zapytań SQL.
To klasyczny dylemat inżyniera.
Patrzysz na komercyjną platformę OEE (Ogólnej Efektywności Sprzętu), widzisz miesięczną opłatę abonamentową i myślisz: „Mógłbym to sam zbudować w weekend. Mamy już Excela, Pythona i PowerBI. Po co płacić?”
Technicznie rzecz biorąc, masz rację. Prosty kalkulator OEE można zbudować w weekend. Ale stworzenie skalowalnego, bezpiecznego i przyjaznego dla użytkownika systemu, z którego będzie korzystać codziennie 50 techników? To zupełnie inna bajka.
Decyzja o budowie czy zakupie nie dotyczy tylko opłaty licencyjnej za oprogramowanie. Chodzi o całkowity koszt posiadania (TCO) i ukryte ryzyko przypadkowego przekształcenia się w firmę software'ową.
Oto uczciwa analiza, która pomoże Ci podjąć decyzję.
Zazwyczaj zaczyna się od arkusza kalkulacyjnego na dysku współdzielonym lub niestandardowej aplikacji stworzonej przez inteligentnego inżyniera procesów.
Zerowy koszt licencji: Korzystasz z narzędzi, które już posiadasz (Excel, Arkusze Google, Microsoft Power Apps).
Pełna personalizacja: Możesz tworzyć dokładnie takie metryki, jakich potrzebujesz, bez żadnych „rozdętych” funkcji.
Ryzyko związane z „czynnikiem magistrali”: Większość narzędzi wewnętrznych tworzy jedna osoba z pasją. Wie, jak działają makra; wie, jak połączyć się z bazą danych SQL. Jeśli ta osoba awansuje lub odejdzie z firmy, system staje się „aplikacją zombie”. Nikt nie wie, jak to naprawić, więc wszyscy przestają z niego korzystać.
Luka mobilna: Wyświetlanie danych na 27-calowym monitorze w sali konferencyjnej jest stosunkowo łatwe. Bardzo trudno jest stworzyć responsywny, przyjazny dla użytkownika interfejs dla smartfona technika. Jeśli narzędzie jest trudne w obsłudze na iPadzie, Twój zespół (Tom) po prostu nie wprowadzi danych.
Dług konserwacyjny: API się psują. Aktualizacje systemu Windows powodują problemy ze sterownikami. Na serwerach kończy się miejsce. Jeśli coś zbudujesz, musisz to obsługiwać. Każda godzina, którą inżynierowie spędzają na naprawianiu narzędzia OEE, to godzina, której nie poświęcają na optymalizację linii produkcyjnej.
Werdykt: „Build” sprawdza się w przypadku pilotaży w pojedynczych lokalizacjach lub bardzo małych warsztatów (<5 maszyn), w których ilość danych jest niewielka.
Wymaga to subskrypcji specjalistycznej platformy OEE i konserwacji, np . Fabrico .
Wdrożenie w 1. dniu: Nie spędzasz 6 miesięcy na rozwoju. Instalujesz czujniki lub podłączasz bramkę, a dane masz od razu.
Natywne doświadczenie mobilne: Platformy takie jak Fabrico inwestują miliony w projektowanie UX/UI. Aplikacja jest stworzona specjalnie z myślą o użytkownikach, małych ekranach i środowiskach offline. To przekłada się na wysoki wskaźnik adopcji wśród techników.
Stabilność i bezpieczeństwo: Dostawca odpowiada za dostępność serwera, tworzenie kopii zapasowych danych i poprawki zabezpieczeń. Nie musisz angażować działu IT przy każdej drobnej aktualizacji.
Tak, obowiązuje opłata abonamentowa. Porównajmy ją jednak z pensją pełnoetatowego programisty (lub 20% czasu pracy głównego inżyniera poświęconego na debugowanie w Excelu). W prawie każdym przypadku opcja „Kup” jest tańsza, jeśli weźmiemy pod uwagę roczny koszt pracy.
Werdykt: „Kup” to właściwy wybór w przypadku operacji obejmujących wiele maszyn i pracujących na wiele zmian, w których niezawodność i integralność danych mają kluczowe znaczenie.
Gdy tworzysz coś wewnętrznie, zazwyczaj skupiasz się na funkcjonalności (czy matematyka się zgadza?).
Kupując platformę taką jak Fabrico, płacisz za użyteczność (czy jest łatwa w użyciu?).
Różnica Fabrico:
Nie zbudowaliśmy po prostu kalkulatora; zbudowaliśmy także cały proces pracy.
Tryb offline: Jeśli połączenie Wi-Fi zostanie przerwane, Fabrico kontynuuje pracę i synchronizuje się później. (Trudny do zbudowania wewnętrznie).
Uprawnienia użytkownika: Mamy wbudowane, rozbudowane role (administrator, menedżer, technik). (Wdrażanie ich wewnętrznie jest żmudne).
Ślady audytu: śledzimy każdą edycję pod kątem zgodności. (Skomplikowane do stworzenia wewnętrznie).
Powinieneś BUDOWAĆ jeśli:
Masz mniej niż 5 maszyn.
Dysponujesz dedykowanym zespołem programistów z wolnymi mocami przerobowymi.
Twój proces jest tak wyjątkowy, że nie nadaje się do niego żadne narzędzie komercyjne (np. wysoce eksperymentalne prace badawczo-rozwojowe).
Masz zerowy budżet na OpEx, ale nieograniczony budżet na godziny pracy wewnętrznej.
Powinieneś KUPIĆ Fabrico jeśli:
Musisz skalować na wiele linii lub witryn.
Potrzebujesz aplikacji mobilnej, z której technicy będą faktycznie chętnie korzystać.
Chcesz, aby Twoi inżynierowie skupili się na produkcji, a nie na kodowaniu.
Potrzebujesz niezawodnego wsparcia, które odbierze telefon, gdy coś się zepsuje.
Produkcja jest wystarczająco trudna, bez konieczności prowadzenia startupu zajmującego się oprogramowaniem w swojej fabryce.
Celem jest poprawa OEE, a nie zbudowanie narzędzia OEE. Wybierając sprawdzoną platformę, przyspieszasz fazę „Budowania” i przechodzisz bezpośrednio do fazy „Ulepszania”.
Zaloguj
Blog
