Baza danych do obsługi zleceń produkcyjnych

Hej,
Wraz z bratem próbujemy wdrożyć do firmy bazę danych do obsługi zleceń produkcyjnych.
Firma z przemysłu metalowego - cięcie, gięcie, spawanie, malowanie proszkowe. Ogólnie rzecz biorąc wytwarzanie wyrobów metalowych.
Z uwagi na to, iż zakres usług został znacznie poszerzony zwykły plik excelowy przestał nam wystarczać.
Każde zamówienie ma rożne procesy technologiczne. Chcielibyśmy wprowadzić coś, dzięki czemu każdy pracownik wiedziałby jakie są kolejne procesy obróbki oraz jakie z nich zostały już wykonane.
Przy dodawaniu zlecenia oprócz podstawowych danych zaznaczane by były wymagane dla tego detalu procesy. Na podstawie zaznaczenia zakończonego etapu byłby wyświetlany kolejny etap, żeby można było sobie przefiltrować, co obecnie oczekuje do np. gięcia czy malowania.

Czy każdy system bazodanowy poradzi sobie z tego typu wymaganiami? Który system wybrać?
Jakiego języka programowania użyć do łączenia z bazą, aby był w miarę łatwy do ogarnięcia?
Mam niewielkie doświadczenia z C++, C#, VBA.

Z góry serdeczne dzięki za pomoc.
Pozdrawiam.

Cześć,

jeśli trochę znasz C# to zrób coś w .NET i połącz to z bazą Postgresql - powinno bez problemu dać radę.

OK, ale tak w sumie to o co pytasz?

Bo jeśli o samą bazę danych (w sensie - silnik) to po pierwsze: dałeś za mało informacji (ile osób ma pracować jednocześnie - a może tylko jedno stanowisko, czy mają być konta użytkowników z odpowiednimi uprawnieniami, ile przewidujesz operacji dziennie, co z kopiami zapasowymi, czy chcesz stawiać osobny serwer SQL, czy ma być dostęp do tego tylko z sieci lokalnej, czy przez net itp.), a po drugie - podejrzewam, że jakikolwiek RDB sobie z tym poradzi. Jeśli teraz trzymacie to w Excelu to nie jest to coś (z punktu widzenia baz SQL) poważnego.

Poza tym, skoro piszesz o jakichś etapach, to mam wrażenie, że już w grę wchodzi nie tylko "baza danych" ale jakaś aplikacja do obsługi zleceń. A to jest już poważniejsza sprawa.

I nie odbierz tego że Cie zniechęcam albo wyśmiewam. Jeśli masz dużo samozaparcia to ogarniesz temat. Tylko miej przy okazji świadomość, że kilka razy mocno się potkniesz po drodze. No i ta droga potrwa. Bo obecnie Twoje pytanie widzę na zasadzie chcę zbudować samochód i się zastanawiam, jakie felgi: aluminiowe czy stalowe powinienem zamontować. No i druga sprawa: chciałbym, że jak w nawigacji wpiszę jakiś adres to żeby się pojawiła taka strzałka ;) Masz z grubsza jakąś wizję, ale mam wrażenie, że średnio wiesz jak podejść do tematu (albo może i wiesz, tylko nie umiesz tego przekazać/pokazać).

Czy każdy system bazodanowy poradzi sobie z tego typu wymaganiami? Który system wybrać?

Jeśli do tej pory radził sobie z tym arkusz excela, to tak - każdy.

MartinTcV napisał(a):

Jakiego języka programowania użyć do łączenia z bazą, aby był w miarę łatwy do ogarnięcia?
Mam niewielkie doświadczenia z C++, C#, VBA.

Na pewno nie C++ ani VBA. C# się dobrze nadaje, ale python może być prostszy, zależy w jakim stopniu znasz te języki

Firma malutka, w sumie 10 osób. Z czego jednocześnie pracowałoby na tym maksymalnie 6 osób. Konta dla każdego, ale nie różne uprawnienia tylko, żeby było widać w historii, kto wprowadzał jakąś zmianę.
Operacji odczytu dziennie może z 50, zapisu znacznie mniej.
Kopie zapasowe chociaż raz dziennie, nawet robione manualnie.
Dostęp tylko z sieci lokalnej, najlepiej jakby serwer stał na serwerze firmowym.
Aplikacja nie jest konieczna, bo jak już wcześniej wspomniałem firma jest mała i chcielibyśmy po prostu się pozbyć zbędnej papierologii - drukowanie rysunków produkcyjnych, kartek ze zleceniami itp.

Zdaję sobie sprawę, że będą potknięcia i że to trochę potrwa, ale mamy na to czas i mamy obecnie na czym pracować.

W poprzedniej firmie mieliśmy bazę danych bodajże na PostgreSQL w powiązaniu z Pythonem i tam pracowało na niej ponad 50 osób i wydaje mi się, że to byłoby wystarczające.

Brat, który jest szefem nie tyle, że szkoda mu kasy, żeby zrobiła to firma zewnętrzna, ale chce, żebym ja się rozwinął, bo jak to mówi łeb mam, tylko za dużo czasu zmarnowałem we wcześniejszej firmie.
Mówi, że mam sobie poszukać jakiegoś szkolenia, za które zapłaci i żeby się tym pobawić i zrobić.

Postgres + Python. Najlepiej zrobić jak jest w mcdonalds, jakiś duży TV i żeby pojawiało się info, co się dzieje na którym stanowisku.

MartinTcV napisał(a):

Aplikacja nie jest konieczna, bo jak już wcześniej wspomniałem firma jest mała i chcielibyśmy po prostu się pozbyć zbędnej papierologii - drukowanie rysunków produkcyjnych, kartek ze zleceniami itp.

Aplikacja jest konieczna, bo RDBMS to w dużym uproszczeniu "tylko tabelki". Raczej nie wyobrażasz sobie, że pracownik produkcyjny będzie pisał polecenia SQL, by zmienić stan zlecenia produkcyjnego...

Zdaję sobie sprawę, że będą potknięcia i że to trochę potrwa, ale mamy na to czas i mamy obecnie na czym pracować.

A ile tego czasu masz? Kilka lat?

W poprzedniej firmie mieliśmy bazę danych bodajże na PostgreSQL w powiązaniu z Pythonem i tam pracowało na niej ponad 50 osób i wydaje mi się, że to byłoby wystarczające.

Jeśli baza jest dobrze zaprojektowana, a soft prawidłowo zaimplementowany, to na bazie mogą pracować jednocześnie setki użytkowników i nikt nie będzie narzekał. A jeśli popełnisz kilka skrajnie niefortunnych błędów, to i 2 osoby zamulą serwer.

Brat, który jest szefem nie tyle, że szkoda mu kasy, żeby zrobiła to firma zewnętrzna, ale chce, żebym ja się rozwinął, bo jak to mówi łeb mam, tylko za dużo czasu zmarnowałem we wcześniejszej firmie.
Mówi, że mam sobie poszukać jakiegoś szkolenia, za które zapłaci i żeby się tym pobawić i zrobić.

To może zacznij od obejrzenia gotowych systemów do zarządzania produkcją. Może znajdziesz jakieś filmy instruktażowe, albo nawet demo. Możesz też zaprosić jakiegoś mniejszego producenta/sprzedawcę takiego softu na prezentację (jesteś potencjalnym klientem, a przecież nikt Cię nie zmusi do podpisania umowy po prezentacji).
Jak dorwiesz demo, to dodatkowo będziesz mógł sobie obejrzeć strukturę bazy, a nawet prześledzić, jakie zmiany w bazie powodują poszczególne akcje wykonane w aplikacji. To da Ci lepsze rozeznanie nt. tego, co trzeba, co można, a czego lepiej nie robić u siebie.

No to powiem Ci tak - SQLite jest wystarczające całkowicie, a nawet z dużym zapasem.
Czemu polecam SQLite a nie "prawdziwego" SQL jak np. wspomniany parę razy w wątku Postgres?
Bo w przypadku Postgresa (lub jakiegokolwiek innego, prawdziwego silnika SQL) musisz mieć serwer, na którym to postawisz. Fajnie co jakiś czas sprawdzać logi, robić aktualizacje. Trzeba potworzyć konta użytkowników do dostępu do bazy itp. Nie jest to jakaś kosmiczna wiedza, ale też trzeba to ogarnąć, serwer musi chodzić, jak się serwer sypnie to wszystko stoi.

A do tak małego ruchu możesz mieć SQLite - https://sqlite.org/. Da Ci wszystkie możliwości, jakich potrzebujesz i do tego zabierze całą otoczkę związaną z administrowaniem i zarządzaniem bazą.

Aplikacja nie jest konieczna,

Tak, jak napisał @Fac powyżej - sama baza to są tabelki z danymi. Ale MUSI być apka, która się z bazą połączy, która da jakiś interface użytkownika (te okienka, formularze i przyciski, na których użytkownik będzie pracować). Chyba, że chcesz to jakoś inaczej rozwiązać - ale my nic o tym nie wiemy, więc odpowiadamy na podstawie tego, co zostało w wątku napisane.

1. Zanim zaczniesz kodować zastanów sie czy narzędzia low code typu https://www.appsmith.com/ czy https://budibase.com/ nie będą wystarczające.
2. Wybierz raczej języki wysokiego poziomu jak python, javascript etc. Najwiecej czasu spalisz nad UI tutaj.
3. Jak ma być to pomoc procesowa to zastanów sie jak pracownicy beda wprowadzać na ktorym etapie prcesu i co mają przed sobą. Najczęsciej są to kody kreskowe naklejone na pudełkach, częściach, stanowisku. Chodzi o kontekst czy pracownik będzie miał stacje z czytnikiem czy bedzie uzywal np telefonu, lub innego narzędzia.
4. Wybór bazy danych tutaj nie ma żadnego znaczenia. Nawet jakby na tym i 1000 osób miało pracować.

Poza tym zastanowiłbym sie czy jakieś gotowe rozwiązania nie bedą wystarczające (darmowe self-hosted, i grosze w cloud):

1. https://frappe.io/erpnext/manufacturing/work-orders
2. https://www.odoo.com/documentation/18.0/applications/inventory_and_mrp/manufacturing/advanced_configuration/using_work_centers.html
3. https://www.dolibarr.org/presentation-production-mrp.php

Jako że zajmuję się tematem zarządzania produkcją na poważenie od wielu lat, to pozwolę sobie odpowiedzieć ;-)

1. Zanim zaczniesz kodować zastanów sie czy narzędzia low code typu https://www.appsmith.com/ czy https://budibase.com/ nie będą wystarczające.

Raczej na pewno nie będą wystaczajaca. A już na pewno nie będą, jeśli zrobi to ktoś kto nie bardzo umie w architekturę.
Widziałem w fabrykach już niejedno takie rozwiązanie... Szkoda gadać.

1. Wybierz raczej języki wysokiego poziomu jak python, javascript etc. Najwiecej czasu spalisz nad UI tutaj.

Moim zdaniem zupełnie nie. Problemem jest silnik (compute) i model danych (czyli to czego nie widać), a nie UI sensu stricto.
UI może być problemem, jeśli np. chce się mieć reaktywnego Gantta - tylko że to akurat do plastycznej obróbki metali nadaje się tak średnio.
No, ale mowa była o zleceniach produkcyjnych, a to o rząd wielkości prostsze zagadnienie.
A minimum to: Zlecenie -> Przewodnik produkcyjny + wydanie materiałów -> Raport wykonania

1. Jak ma być to pomoc procesowa to zastanów sie jak pracownicy beda wprowadzać na ktorym etapie prcesu i co mają przed sobą. Najczęsciej są to kody kreskowe naklejone na pudełkach, częściach, stanowisku. Chodzi o kontekst czy pracownik będzie miał stacje z czytnikiem czy bedzie uzywal np telefonu, lub innego narzędzia.

Widziałeś kiedyś narzędziownie w realu?
Stacja z czytnikiem... Jakoś tego nie widzę przy wielooperacyjnych marszrutach technologicznych, zwłaszcza w dynamicznym środowisku (tj. kiedy produkcja działa de-facto bez hemogramu produkcji) produkcyjnym.
A coś mi się wydaje, że tak dokładnie może być w przypadku @MartinTcV

Robiłem kiedyś podobny projekt, gdzie pierwotny pomysł był właśnie taki (raport wykonania poszczególnych operacji danego zlecenia przez skanowanie kodów). I umarło to na etapie draftu - zbyt duża dynamika zmian.
Produkcja jest "wrednym" tematem ze względu na swoją nieprzewidywalność - zawsze może być wrzutka (przerwij to co robisz, rób teraz to ASAP!) lub coś się popsuje, zabraknie materiału czy operator nie zjawi się dziś w pracy.
No i właśnie takie nieprzewidziane rzeczy skutecznie eliminują wszelkie "sztywne" pomysły.

1. Wybór bazy danych tutaj nie ma żadnego znaczenia. Nawet jakby na tym i 1000 osób miało pracować.

Znam realne przypadki, które mogą poważnie zdziwić w tym obszarze, ale co do zasady tak - to nie ma znaczenia.
Ale zdecydowanie lepiej PostgreSQL niż MySQL.
SQLite odrzuciłbym w przedbiegach - świetne, ale nie do takich zastosowań.

Poza tym zastanowiłbym sie czy jakieś gotowe rozwiązania nie bedą wystarczające (darmowe self-hosted, i grosze w cloud):

1. https://frappe.io/erpnext/manufacturing/work-orders
2. https://www.odoo.com/documentation/18.0/applications/inventory_and_mrp/manufacturing/advanced_configuration/using_work_centers.html
3. https://www.dolibarr.org/presentation-production-mrp.php

Zawsze warto zacząć od czegoś takiego - chociażby aby się dowiedzieć co pasuje, a co nie.

@wloochacz Sr ale się nie zgadzam. Co do doświadczenia to robiłem systemy scada i ew zarządzanie konfiguracyjne maszynami(nie operacyjne) i proste zarządzanie procesem/raporty(bez buildera).

Raczej na pewno nie będą wystaczajaca. A już na pewno nie będą

Skill issue. Powiedz mi czego konkretnie tam nie zrobię albo będzie nie wystarczające.

Moim zdaniem zupełnie nie. Problemem jest silnik (compute) i model danych (czyli to czego nie widać), a nie UI sensu stricto.

XD o ile nie musisz budować buildera procesów to prostszej logiki i bardziej ksiązkowej we wzroce nie ma.

Widziałeś kiedyś narzędziownie w realu?
Stacja z czytnikiem... Jakoś tego nie widzę przy wielooperacyjnych marszrutach technologicznych, zwłaszcza w dynamicznym środowisku (tj. kiedy produkcja działa de-facto bez hemogramu produkcji) produkcyjnym.

Nie wiem na czym robiłeś.
Jak obsługujesz maszyne na ktorymś etapie procesu musisz mieć zebrane komponenty do danego procesu np jak zakuwasz węże ciśnieniowe, to musisz mieć ucięty wąż konretnego typu i końcówki. Zazwyczaj każdy z tych elementów ma kod kreskwy i paleta/skrzynka/półka też ma swój kod kreskowy. Dostajesz podkomponenty skanujesz opakowanie, wyswietla ci sie BOM i system wie ktore zlecenie jest na ktorym etapie procesu i ktory pracownik obslugiwal jaki krok.

Wszystko zależy od tego jak dana firma ceni swoją reputację i jaki ma apetyt na pomyłki. Jak duży obrót mają i jak wiele komponentów uzywają. W przypadku dużej zmienności nie wyobrażam sobie aby operator ręcznie weryfikował co dostał po np numerach seryjnych, sprawdzał długość albo czy to co dostał pokrywa się z procedurą która mu się wyswietla ręcznie.

Ale zdecydowanie lepiej PostgreSQL niż MySQL.
SQLite odrzuciłbym w przedbiegach - świetne, ale nie do takich zastosowań.

Bo? Konkrety... SQlite sam w sobie w wiekszości przypadków będzie wydajniejszy niż postgres, łatwiejszy w zarządzaniu w tego typu zadaniach. Jedyną wadą sqlita jest jak musisz bić do niego po sieci(mało optymalna implementacja) i masz wiele procesów piszących duże ilości danych w tym samym momencie (jeden writer).

Skoro :

Firma z przemysłu metalowego - cięcie, gięcie, spawanie, malowanie proszkowe. Ogólnie rzecz biorąc wytwarzanie wyrobów metalowych.

To zastanów się czy nie lepiej poszukać gotowca, który wpisywałby się w Wasze wymagania, może pozwolił na integrację z jakimś sklepem internetowym (nie wiem jakie macie kanały przyjmowania zleceń) czy systemami rozliczeniowymi. Chyba, że bazy danych i programowanie to Wasze hobby :-)

+1 dla Postgresa.

nie wiem jak obecnie wygląda Access i czy działa bez problemów wielostanowiskowo? właśnie obsługa wielu użytkowników była kiedyś problemem ale wyklikanie okien jednocześnie z bazą + prosty kod w Visual Basic for application to może być właśnie to czego potrzebujesz
robiłam w tym kiedyś aplikacje dla banku, robiła kilka projektów studenckich
no i raporty spoko się robiło
i współpraca z resztą office'a jak np. excel spoko była

Jako ktoś kto też tworzy firmę produkcyjną, a w programowaniu i bazach ma >15 lat doświadczenia - NIE IDŹ TĄ DROGĄ, na litosć boską.
Weź gotowy soft, możesz nawet open source i go rozwijaj czy jakiś inny ze swobodnym dostępem do bazy (ale mówię to tylko po to by zaspokoić Twoje ambicje programisty, najlepiej po prostu weź gotowca). Robiąc samemu poświęcisz kilkaset - kilka tysięcy h na stworzenie czegoś co możesz kupić za kilkaset zł/mc zamiast zająć się rozwijaniem firmy.
Albo zrobisz jakąś prowizorkę, którą potem i tak trzeba zmigrować do normalnego softu i zapłacisz dodatkowo za napisanie dedykowanie importu danych.
Jak teraz zrobisz ten soft, a później firma rozrośnie się to co? Zatrudnisz programistę czy jako wspólnik będziesz zajmował się naprawianiem błędów, rozwiązywaniem problemów bo jakaś funkcja nie działa bo user ustawił sobie niestandardowe skalownanie, naprawianiem podatności itd?

A co z testami? Zatrudnisz testerów? Sam będziesz to robił? Zaakceptujesz ryzyko, że zawalisz część zleceń produkcyjnych bo program będzie miał bugi?
A co jak będzie błąd, a Ty pojedziesz na urlop, zachorujesz albo nie będziesz w stanie go naprawić?
A co jak uszkodzi się baza danych?
A co jak konkurencja będzie miała lepszy soft (a będzie miała bo kupi coś nad czym siedziało przez 10 lat 15 programistów i 5 testerów)?
A co jak będzie chciał sprzedać firmę? Taki soft to kula u nogi.
A co jak będziesz chciał rozbudować magazyn, poświęcisz 3-6 mc na napisanie modułu do tego czy kupisz za 1k $ pakiet magazyn?

Firm oferujacych usługi obróbki metalu jak Twoja z kilkaset k na świecie, więc jest mnóstwo gotowych softów. Lepiej poświęcic 40h na wybranie odpowiedniego softu.
Taki duży producent konstrukcji aluminiowych (nie pamiętam nazwy, robi tez drabiny) chciał mieć własny soft, zlecił zrobienie go, a ostatecznie stracił kasę i wziął gotowca.

Jakby jakiś bukmacher zrobił zakład czy to dobry pomysł to bym wziął kredyt pod zastaw całego majątku firmowego, każdego najmniejszego paleciaka i wszedłbym ALL-IN, że to jest tragiczny pomysł zwłaszcza przy Twoich umiejętnościach (ale nawet jakbyś był full stack developerem to to nadal zły pomysł), spowoduje tylko problemy, pogorszy Twoją relację z bratem.

Rozpisałem się, ale liczę, że odpowiesz sobie na te pytania.

Masz sporo podpowiedzi - ale jeśli na ten moment największa potrzeba to jest zmiana Excela na coś lepszego to jak już wspomniano o tym wyżej (@Miang), weź na warsztat Access'a.
Przy zachowaniu podstawowych zasad, to taki Access będzie setki razy lepszy niż jakikolwiek Excel. Dodatkowo, możesz go sobie z czasem rozwijać.
Jak już coś tam klikałeś, to apkę będziesz miał gotową najdalej po tygodniu.

Absolutnie popieram wszystkie głosy za dedykowaną apką docelowo, ale jeśli na ten moment szukasz tylko zamiennika dla Excela to Access.

ps.
ograniczeniem mogą być licencje, bo kosztują. jeśli tak, to ewentualnie potrzebujesz jednej - dla autora projektu. Użytkownikom wystarczy wersja runtime, która jest bezpłatna.

Nie czytając całego wątku - jeśli szukasz prostej bazy danych żeby zastąpiła plik excela to SQLite pewnie wystarczy. Ewentualnie jeśli chcesz się więcej nauczyć czy mieć w CV coś co jest wykorzystywane praktycznie w dużych projektach to Postgres. Z nierelacyjnych Mongo jest spoko.

Nie wygląda jakbyś potrzebował jakiejś konkretnej bazy danych bo wymagania które masz to dosłownie wszystko uciagnie

To o co pytasz brzmi raczej jak jakiś BPMN w stylu Flowable i w te stronę bym patrzył

Witam po długim czasie. Niestety trochę go minęło, a nie miałem nawet chwili, żeby do tego zasiąść. Udało się tylko rozpocząć tworzenie magazynu dla blach w excelu z formularzami i VBA, a nawet nie skończyłem, bo za dużo zleceń i wyceń na głowie.
Będziemy musieli się zastanowić nad jakimś gotowcem, bo faktycznie tego nie widzę.

Brat kiedyś dostał wycenę od jednej firmy na system ERP i roczny koszt był rzędu 30tys. zł. A na potrzeby naszej firmy to trochę przesada.

Polecicie coś z gotowców nie aż tak drogich, żeby móc się umówić na prezentację nawet zdalnie i zobaczyć jak to wszystko wygląda i czy wpisze się w nasze potrzeby?

To tak co na szybko przychodzi mi do głowy. Reszta wyjdzie pewnie w praniu.

Prowadzenie magazynu blach i farb, czyli:

• dodawanie materiałów, gdy przyjeżdża zamówienie,
• usuwanie blachy, gdy została pocięta w całości,
• dodawanie odpadu blachy do wykorzystania w przyszłości z nadaniem numeru do opisania i odłożenia na regał, gdy nie cała blacha została pocięta,
• zdejmowanie ze stanu masy farby, która została zużyta do zlecenia.

Prowadzenie magazynu innych komponentów, które są rzadziej używane typu śruby, podkładki, nity, nitonakrętki, profile, chociaż tego jest na tyle mało, że jak dostajemy zlecenie jakieś to od razu zamawiamy z internetu i za 2-3 dni mamy u siebie.

Prowadzenie zleceń malarnii proszkowej:

• dodawanie zleceń z numerem do bazy z opisem detali, koloru, nazwy klienta itp. gdy przywieziony zostaje materiał, fajnie by było jakby można było załączyć zdjęcia materiału dla rozpoznania dla innej zmiany
• opis tego co jest malowane wraz z opisem obliczonej powierzchni, obecnie w excelu spisywane są zlecenia, a dla 2 klientów jest wyszczególniony dokładnie numer detalu, liczba sztuk, powierzchnia obliczona, a potem obliczana jest z tego cena i klient chce linijka po linijce osobny detal.

Najważniejsze to mimo wszystko planowanie produkcji, czyli:

• nowe zlecenie z opisem procesów - cięcie, gięcie, nitowanie, obróbka skrawaniem, spawanie, malowanie itp., żeby można było zaznaczyć jakie procesy potrzebne, żeby można było nawet dodać, że trzeba coś przeszlifować po cięciu, bo będzie potem gięte i malowane, a po gięciu może to się kiepsko szlifować, a co płaskie to zawsze lepiej,
• wskazówki do każdego procesu, żeby np. po gięciu odłożyć coś do kartonika, co nie będzie malowane, a coś odłożyć na inną paletę, bo np. będzie przed malowaniem nitowane
• załączenie potrzebnych dokumentacji, żeby ograniczyć zużycie papieru,
• określenie deadlinu, żeby określić co bardziej pilne, albo co dłużej oczekuje na produkcję,
• zmiana statusu przez każdego z pracowników po zakończeniu każdej części zlecenia,
• automatyczna informacja do biura przez powiadomienie, wyskakujące okienko, że jakieś zamówienie jest skończone, żeby można było poinformować klienta o możliwości odbioru.