Czesc, potrzebuję podpowiedzi jak zaplanować na starcie architekturę systemu ktory powoli tworze /chcialbym stworzyc na potrzeby swojego działu w pracy /dział technologii produkcji - firma elektroniczna/, szczególnie chodzi mi o warstę dostępu do danych i sposob przechowywania danych które sam dodaje do obecnych teraz w ERP. Pisze w C# w WPF.
To co jest mi narzucone przez firme i to co zalezy tylko ode mnie i jak to mogę zrobić.
Narzucone:
- do bazy danych w firmie moge dostawac dowolne zapytania od administratorów systemu ERP ale tylko SELECT, zadnych update'ów czy insert'ów nie dostane /nawet gdyby to bylo mozliwe nie chcialbym, na tym etapie wiedzy programistycznej/
- aktualizowanie i wprowadzanie danych do systemu ERP odbywa się poprzez, bardzoe nieywgodne widoki ERP i narzucajace wprowadzanei dnaych "na piechote - rekord po rekordzie, albo reczne przygotowywanie plików wsadowych o narzuconym formacie do importu wielu rekordow, one potem chyba sa juz w systemie przetwarzane przez wewnetrzne serwisy i taki serwis sam konwertuje to na odpowiednie updatey/inserty, pominiecie tego sposobu wprowadzania danych i bezposrednie polecenia insert/update powoduja utrate wsparcia dostawcy systemu ERP - info od administaratorow systemu
- obecnie SELECT'y uzyskiwane od adminow uzywane są powszechnie jako kwerendy w Excelach ale mozliwosci usprawnienia pracy aktualizacji danych systemowych technologow dzieki korzystaniu i recznemu przetwarzania danych uzyskiwanych z widokow excelowych szacuje na 5-10% w stosunku do tego co mozna zrobić obiektowo obrabiajac dane.
- programisty w firmie do usprawnienia pracy swojego dzialu nie moge uzyskac od paru juz lat, pomimo obecanek dyrekcji zawsze programista dostaje priorytety na usprawnienia w obszarach dzialow finansowych/handlowych/kadrowych/logistycznych i planistycznych - produkcja ma najnizszy priorytet i skoro nie zmienilo się to juz od tylu paru lat to juz sie nie zmieni
- nie dostane mozliwosci postawienia odrebnej bazy danych na czesc danych ktore bede tworzyl ponad to co jest w obecnym systemie ERP
To co mogę i chcialbym zrobic:
- mogę wykorzsytać siec lokalna, do przetrzymywania danych ktore sam utworze w swoim programie, na ktorej obecnie trzymamy te wszystkie wspolne dla dzialu technologicznego dane /m.in. excele o ktorych wyzej/ dokuemmtacje robocze, oferty na usprawnienia technologiczne itp.
- moge i jestem juz w trakcie robienia warstwy dostepu do bazy danych systemu ERP /SELECTy/ przetwarzam zapytania na obiekty, buduje repozytoria i na nich bede sie opieral /nadal się ucze takich wzorcow dostepu do danych/
- jestem tez w trakcie tworzenia domeny/modelu i logiki systemu w obszarach ktore mnie interesują - tu jakos sobie radze
- dane uzyskiwane z ERP: artykuly proste i zlozone, marszruty, BOMy,
- oraz to co sam tworze czego nie ma w ERP /to tu generuje dane ktorych nie wiem jak przetrzymywac/: operacje technologiczne i zarzadzanie nimi neizaleznie od marszrut w ktorych sa, w ERP, budowanei w oparciu o nie uniwersalnych marszrut nie przypisanych sztywno do artykulu tylko do rodziny artykulow, operacje na marszrutach i BOMach - porownywarki BOMów i marszrut, pilnowanie spojnosci danych miedzy bomem i marszruta jednego artykulu obecnie wszystko polega na samokontroli technologa, wersjonowanie zmian, oraz najwazniejsze automatyczne generowanie plikow importu z pelną i rygorystyczna kontrola formatu tych plików - obecnie gdy tworzone sa recznie, dochodzi do sporej ilosci bledow ktore powoduja ze technolodzy ida w strone aktualizowania tych danych w widokach systemu ERP /na piechotę rekord po rekordzie/ a te widoki wolaja o pomste do nieba, sa archamiczne - byly przeskokiem technologicznym z systemu ERP pracujacego w DOSie 15 lat temu, ale teraz nie przystają już do standarów pracy w windowsie, takie aktualizacje danych przez widoki wymagaja jeszcze wiecej czasu i jeszcze bardziej trzymaja technologa przy komputerze
I tu pojawia sie wlasciwe pytanie:
- Jak zaplanować na starcie zbudowanie bazdy danych dla swojej czesci danych /teraz mysle o plikach tekstowcyh/, ktore beda wspoldzielone pomiedzy technologami ktorzy to rownolegle beda pracowac na tych danych /przypominam ze nie dostane ms sql ani systemu ERP /do zapisu/ ani nie postawią mi teraz na starcie mojej niezaleznej bazy ms sql - moze jak program ruszy i zdobede zaufanie, za jakies 1-2 lata moze wtedy, ale na rozruch potrzebuje to inaczej zorganizowac nawet kosztem nadmiarowosci.
Aby bardziej zobrazować problem, opisze jeden z przypadkow uzycia.
Obecnie jest tak ze w systemie ERP, BOM i marszruta nie istnieje bez artykulu. scenariusz jest taki ze najpierw trzeba utworzyc w systemie artykul zlozony, /prosty to material/ do niego zdefiniowac BOM i marszrute i tyle. Jezeli mam w systemie 10 artykolow customizowanych tzn. BOMy i marszruty mają identyczne różnią sie jedynie logiem klienta na etykiecie znamionowej /etykieta nie jest artykulem ERP jest mapowana do artykulu jako dokumentacja i naklejana na jednym z etapow produkcji/ to w przypadku wprowadzenia jakiejs drobnej optymalizacji technologicznej w marszrucie czy wprowadzeniu zamiennika jakiegos materialu w BOMie trzeba te zmainy przeklikac w tych dziesieciu artykulach po kolei lub przygotowac plik importu recznie i zaimportowac grupowo - haczyk polega na tym, e w widokach ERP artykul po artykule aktualizuje sie recznie rekor po rekordzie a plik importu tez przygotowuje się recznie linia po linii - wynik: pliki importu nie sa czesto uzywane bo zysk czasowy jest niwielki a ryzyko popelnienia bledu wieksze. /takich artykolow prostych + zlozonych obecnie w bazie jest okolo 200k/.
Aby zachowac spojnosc danych, jezeli program ruszy i bedzie wygodny do uzytku moge z adminami zablokowac korzystanie z widokow w ERP aby juz nie bylo mozna w tamtym miejscu wprowadzac zmian w definicjach - aby jedynym kanalem wprowadzania zmian w systemie byly pliki importu np. wygodnie i przyjemnie tworzone w programie. /wygoda i szybkosc zmian w programie jest krytyczna i ma spowodowac samoistna chec korzystania z tej metody u technologow, nad tym juz pracuje i tu mam na razie priotytet/
Chcialby tu wprowadzic m.in. taka optymalizację:
- Chcialbym moc definiowac marszrute jako niezalezny obiekt /np. poprzez nadanie jej nazwy grupy wyrobow dla kotrej jest zdefiniowana i wersjonowac ją najlepiej data i godzina zapisania/ - taka definicje musialbym trzymac u siebie w danych
- chcialbym przypisac do niej indexy artykulow dla ktorych ja definiuje /lub grupe wyrobowa ktora ma w sobie te indexy/ i trzymac taka definicje u siebie w danych aby moc ja rozszerzac albo ograniczac, oczywiscie wersjonujac
- chcialbym przy edycji tej marszruty w jednym miejscu ja zmienic np. poprzez aktualizacje czasów operacji i jednym kliknieciem wygenerowac plik importu marszrut dla wszsytkich artykulow powiazanych - ten fragment mam oprogramowany w logice wraz z gruntowym przetestowaniem utrzymania formatu plikow importu
I teraz moje niewiadome i problemy do rozwiazania.
-
Program sam nie aktualizuje danych w bazie danych systemu, robi to poprzez wyenerowanie pliku importu ale zaimportowanie tego pliku to juz praca reczna technologa - planuje przypilnowac proramowo tego tak ,ze po klinieciu przyciusku generowania pliku importu wyswietli sie jakies okno modalne proszace o potwierdzenie zaimportowania pliku. Okna nie da sie zamknac dopóki program nie uzyska rownosci definicji artykulow przygotowanych w widoku pod oknem modalnym czyli w pliku importu z tym co odpyta z bazy danych. Czy to trzeba jakos inaczej zaplanowac czy moze byc?
-
Jak zadbac o to zeby jeden technolog nie wchodzil sobie w droge np. jeden definiuje marszrute zbiorcza dla kilku artykulow i drugi definiuje swoja zbiorcza ale bierze do swojej grupy artykul juz zdefiniowany w grupie u pierwszego technologa - jezeli to tak zostawie to jeden drugiemu bedzie nadpisywal dane swoimi plikami importu w ktorych bedzie wspolny artykul. myslalem o jakiejs wewnetrznej logice ktora dzialalaby tak ze w momencie gdy technolog bedzie dodawal artykuly do swojej grupy system bedzie sprawdzal czy taki artykul juz nie jest w ktorej grupie i wysylac takie ostrzezenia, pewnie sposob kontroli zalezy od tego jaki system zapisu danych przyjme patrz pkt.3?
-
I najwazneijsze jak przechowywac moje dane z ktorych beda korzsytac okolo 15 technologow? nie jestem pewien czy jeden plik XML dla jednego obszaru usprawnianego przez program, to dobry pomysl /jeden obszar to np. zarzadzenia marszrutami, drugi to to samo ale BOMami, trzeci spojnosc danych miedzy BOMem i marszruta w obrebie jednego artykul, zarzadzanie odbiorami komisyjnymi itp./. Bo program w przypadku otwarcia tego pliku przez jednego technologa moze go trzymac otwartym tak dlugo az technolog jeden nie skonczy swojej roboty /tak teraz dziala system ERP jezeli jeden technolog wejsdzie w widok edycji jednego artykulu to drugi nie moze wejsc w widok edycji tego samego artykulu/.
-
dostep do danych plikowych i tak bym musial jakos opakowac tak aby potem dostajac za 1-2 moze 3 lata swoja baze danych mogl tylko zmienic w warstwie dostepu obiekt zalezny od zrodla danych i przekazywany do repozytoriow, musialbym zadbac tylko o wspolny interfejs dla tych obiektow.
Troche sie zamotalem, nie jestem pewien czy dobrze przedstawilem problem i czy kombinuje, chodzi mi o podpowiedzi na starcie zanim zaczalem robic ta czesc warstwy dostepu do danych od bardziej doswiadczonych programistow ktorzy widza szerzej i dalej. zebym za jakis czas nie robil rewolucji w architekturze.