ERP w centrum firmy: gdzie Microsoft Dynamics spotyka codzienność procesów
W projektach opartych o Microsoft Dynamics szybko wychodzi na jaw, że sam ,,system ERP" to tylko fragment układanki: liczy się przepływ danych między działami, spójność procesów i to, jak rozwiązanie zachowa się pod obciążeniem. Ta kategoria jest o tym, co dzieje się po etapie demo -- gdy trzeba utrzymać porządek w sprzedaży, magazynie, produkcji czy dystrybucji i nie zgubić po drodze jakości danych. Można się zastanawiać, czy ważniejsza jest funkcja czy architektura... zwykle wygrywa rozsądny kompromis.
NAV i Business Central: architektura, rozszerzenia i integracje bez półśrodków
W praktyce wdrożeniowej często kończy się na pytaniu: ,,jak to połączymy z resztą świata?" -- i tu przydają się książki, które pokazują integracje z aplikacjami zewnętrznymi, rozproszone środowiska oraz dobór podejścia do konkretnych branż. W Building ERP Solutions with Microsoft Dynamics NAV. Solve business scenarios using NAV Stefano Demilianiego widać krok po kroku, jak rozwiązywać typowe (a czasem podchwytliwe) problemy wdrożeń, korzystając z pełnego stosu technologii Microsoftu. Z drugiej strony, gdy wchodzisz w nowoczesny model rozwoju, liczy się praktyka pracy na sandboxach, pisanie w AL i cykl życia rozszerzeń -- i to właśnie prowadzi przez codzienność deweloperską.
Jeśli siedzisz bliżej wytwarzania niż analizy, ważne będą tematy debugowania, automatycznych testów i wdrożeń, bo to one ratują czas przy kolejnych wersjach. W Mastering Microsoft Dynamics 365 Business Central. Discover extension development best practices, build advanced ERP integrations, and use DevOps tools Stefano Demilianiego i Duilia Tacconiego mocno wybrzmiewają integracje (np. przez web services i API), użycie Azure Functions oraz podejście DevOps/CI CD, które -- szczerze mówiąc -- przestaje być ,,opcją", a staje się standardem. To są rzeczy, które da się od razu przełożyć na środowisko projektu: od przygotowania piaskownicy po dostarczenie działającego rozszerzenia użytkownikom.
W codziennej pracy często przychodzi też moment migracji: co zrobić z istniejącymi rozwiązaniami, gdy przechodzisz na model oparty na rozszerzeniach? Tu liczą się decyzje techniczne, ale też organizacyjne: jak planować wdrożenia, jak ograniczać ryzyko regresji, jak dogadać się z biznesem co do okien serwisowych. A kiedy w tle dochodzą jeszcze elementy typu uczenie maszynowe czy współpraca z aplikacjami Office 365, robi się ciekawie -- i, paradoksalnie, bardziej ,,życiowo" niż akademicko.
Od konsultanta wdrożeniowego po developera AL: ścieżki, które realnie się przydają
Ta półka bywa pomocna dla kilku ról naraz: konsultanta, który musi umieć nazwać sensowną architekturę i obronić ją przed klientem; developera, który buduje rozszerzenia i integracje; oraz tech leada, który spina standardy pracy zespołu i CI/CD. W zależności od projektu możesz iść w stronę integracji z usługami w chmurze, utrzymania rozwiązań on-premises albo pracy ,,na styku" -- kiedy ERP gada z e-commerce, systemem WMS czy aplikacjami raportowymi. Dla porządku: jeśli interesuje Cię szerszy kontekst relacji z klientem i procesów sprzedażowych, naturalnym uzupełnieniem będzie też podkategoria CRM w dziale e-biznesu i marketingu.
Na koniec warto dodać, że czasem najlepiej uczy pojedynczy, dobrze opisany przypadek wdrożeniowy -- a takich case'ów w tej kategorii po prostu nie brakuje, więc łatwo złapać ,,to jest dokładnie mój problem z projektu".
Jeśli po lekturze temat integracji i procesów frontowych wciągnie Cię bardziej, zajrzenie do podkategorii CRM może sensownie domknąć perspektywę pracy z danymi klientów.
