Eigenes Produktionsmodul entwickeln (cc) [gelöst]

Guten Morgen zusammen,

ich habe die Aufgabe bekommen, eine für all unsere Produktionsstätten flächendeckende Lösung zur Betriebsdatenerfassung zu finden / zu programmieren.
Grundsätzlich stellt sich hier natürlich die Fragen, wie und wo ich das ganze abbilden könnte.

Da ich, zumindest vor 2 Jahren, mal ganz fit in Visual Basic war, wäre dies natürlich eine Lösung in Verbindung mit einer SQL-Datenbank.
Am liebsten hätte ich den Teil der Produktion allerdings in NAV.

Für die Betriebs- / Produktionsdatenerfassung ist bei uns allerdings weitmehr nötig als der Navision Standard bietet.
Sprich, würden wir den in NAV vorgesehenen Bereich der Produktion nutzen wollen, wären hier dermaßen viele Anpassungen zu machen, dass es in meinen Augen keinerlei Sinn ergibt, grade auch hinsichtlich NAV Updates.

Mein Gedanke war nun, eine komplett eigenständige Betriebsdatenerfassung in NAV zu erstellen, völlig losgelöst vom NAV Standard.
Somit hätte ich trotzalledem noch die Möglichkeit, auf den Artikelstamm usw. zuzugreifen, die produzierten Mengen direkt in die Warenwirtschaft fließen zu lassen usw.

Aber irgendetwas in mir hat das Gefühl, dass dies nicht der richtige Weg ist.

Gibt es irgendetwas, dass gegen ein selbstentwickeltes "Betriebsdatenerfassungs-Modul" spricht (Abgesehen von dem zusätzlichen Aufwand bei NAV Updates)?

Ich würde mich freuen, wenn Ihr eure Bedenken hierzu posten könnten.

Vielen Dank!

Gruß

howare

Zuletzt geändert von howare am 31. Juli 2014 11:50, insgesamt 1-mal geändert.

[...] wären hier dermaßen viele Anpassungen zu machen, dass es in meinen Augen keinerlei Sinn ergibt, grade auch hinsichtlich NAV Updates.

Hallo howare,

widersprichst du dir da nicht gerade selber?
Du sprichst das Thema NAV-Updates an, willst ein solches Modul jedoch komplett selbst entwickeln?

Es gibt zahlreiche Microsoft Dynamics NAV Partner, welche Lösungen sowohl für verschiedenste Produktionsarten (Auftragsfertigung, Prozessfertigung, Projektfertigung, ...) wie auch für die Betriebsdatenerfassung als zertifizierte Lösung anbieten.
Diese Lösungen werden von den Partnern permanent weiterentwickelt, womit euch entsprechende Updates zur Verfügung stünden.

Schaut euch doch mal auf Microsoft PinPoint um, welche Partner für euch in Frage kämen, und lasst euch deren Lösungen präsentieren.

Hehe ja irgendwie schon,
aber ich denke, wenn es ein komplett eigenständiger Teil ist, hat man es bei einem Update nicht so schwer, wie wenn man die neuen Standardobjekte wieder mit den Anpassungen zusammenführen muss, oder? (Habe noch nie ein Update mit gemacht)

Das Kaufen einer fertigen Branchenlösung bietet natürlich auch Vorteile, wer will schon das Rad neu erfinden.
Problematisch ist bei uns nur, dass alles immer so sein muss, wie die Herren es gerne hätten, sprich die gekaufte Lösung müsste durch einen Dienstleister wieder individuell auf uns angepasst werden, sofern dieser es überhaupt zulässt.
Ein weiteres Problem ist, dass immer alles "billig" sein muss.

Wir haben in einer unserer Produktionsstätten seit langer Zeit eine, nicht nur Branchenlösung sondern tatsächlich auf die Produktion unserer Produkte spezialisierte Betriebsdatenerfassung im Einsatz.
Trotzalledem sind seit langem eine Menge Anpassungwünsche vorhanden, die aber nicht genehmigt werden, da sich der Hersteller dies natürlich ordentlich bezahlen lässt.

Diese Probleme hatten wir mit einem "eigenen NAV-Modul" auch erschlagen.

Billig, billig......

Das könnte aber auch nach hinten losgehen. Eine Eigenentwicklung hat sicher den Vorteil, das alle Wünsche berücksichtigt werden können.
Pech nur, wenn der Entwickler dann später das Haus verlässt und das Wissen mitnimmt.....
Außerdem kostet eine Eigenentwicklung auch sehr viel (internes) Geld, die Entwickler wollen ja auch ihr Gehalt haben. So "nebenbei" ist eine solche Entwicklung nicht zu wuppen.

Aus meiner Erfahrung kann ich nur sagen, Nav Standard als Basis, bestimmte Branchenlösung(en) als Addon (das können auch mehrere sein, die über einen Partner zu einer Lösung zusammengefasst werden)
und geringe individuelle Anpassungen, das ist immer noch auf längere Sicht der kostengünstigste Weg.
Dann sind Updates später auch nicht mehr primär Euer Problem, sondern das des Partners.

aber ich denke, wenn es ein komplett eigenständiger Teil ist, hat man es bei einem Update nicht so schwer, wie wenn man die neuen Standardobjekte wieder mit den Anpassungen zusammenführen muss, oder? (Habe noch nie ein Update mit gemacht)

Ein komplettes Modul völlig eigenständig in NAV?
Das widerspricht sich abermals, da spätestens bei der Buchung des Produktionsauftrags eine Integration in den Rest der Anwendung unausweichlich ist.
(Dimensionen, Buchungsroutinen, Kontenfindung, Lagerregulierung, ...)
Und wenn es dann um das Thema Update geht, dann bedenkt bitte auch, dass ihr eure individuelle Funktionalität in Teilen neu schreiben müsstet, z. B. bei den Dimensionen, welche beim nächsten Update auf Dimension-Sets umgestellt werden müssten.

Das Kaufen einer fertigen Branchenlösung bietet natürlich auch Vorteile, wer will schon das Rad neu erfinden.

Gerade bei Updates würdet ihr jedes Mal das Rad neu erfinden. bei einer fertigen Lösung wäre der größte Teil bereits durch den Partner erfolgt, so dass ihr euch nur noch um die wenigen individuellen Stellen kümmern müsstet.

Ein weiteres Problem ist, dass immer alles "billig" sein muss.

"Billig" ist leider das Gegenteil von "Günstig", denn: "Wer billig kauft, kauft zweimal."

Wir haben in einer unserer Produktionsstätten seit langer Zeit eine, nicht nur Branchenlösung sondern tatsächlich auf die Produktion unserer Produkte spezialisierte Betriebsdatenerfassung im Einsatz.
Trotzalledem sind seit langem eine Menge Anpassungwünsche vorhanden, die aber nicht genehmigt werden, da sich der Hersteller dies natürlich ordentlich bezahlen lässt.

Ich habe schon in vielen Projekten 100%-Individual-Programmierung auf die NAV-Standard-Prozesse umgestellt und an die individuellen Bedürfnisse des Kunden angepasst.
In aller Regel ist dies der deutlich einfachere und bessere Weg, als das Individual-Modul in der neuen Version lauffähig zu machen.
Wenn der Partner ordentliche Leistung erbringt, darf er dafür natürlich auch einen ordentlichen Preis verlangen.

100%-Individual-Module machen nur dann Sinn, wenn weder der Standard, noch eine Lösung eines Drittanbieters existieren bzw. annähernd an eure Bedürfnisse kommen.

Das könnte aber auch nach hinten losgehen. Eine Eigenentwicklung hat sicher den Vorteil, das alle Wünsche berücksichtigt werden können.
Pech nur, wenn der Entwickler dann später das Haus verlässt und das Wissen mitnimmt.....

Wie wahr, wie wahr! Leider schon häufiger erlebt, als es einem lieb ist.
Keiner weiß, wie das Modul (intern) funktioniert, und was sich der Entwickler bei der Programmierung gedacht hat.
Spätestens dann ist das Updaten dieses Moduls auf die nächste NAV-Version nicht mehr rentabel.

Wie bereits vorgeschlagen, solltet ihr euch mal umschauen, was der Markt bereits an Lösungen bietet und euch diese vorführen lassen.
Ggfls. auch mal nach Referenzkunden fragen und dort einen Besuch vereinbaren.
Wenn ihr dann immer noch der Meinung seid, dass es nichts passendes gibt, dann könnt ihr ja immer noch die Eigenentwicklung starten.

Hallo RaiNav,

ich verstehe was du meinst, aber wenn die EDV nun mal nicht so viel kosten darf, dann ist das nunmal so, da kann der kleine Mann nichts gegen machen

Den Entwickler, welcher das Haus verlassen könnte, bin ich selbst (was ich in keinster Weiße beabsichtige).
Wobei wir in naher Zukunft auf mein drängen hin, einen weiteren Mitarbeiter, welcher bereits eine Ausbildung im Bereich der Anwendungsentwicklung hat, zur NAV Schulung schicken werden, um genau solche Fälle abzusichern (Krankheit, Unfall oder was sonst noch alles passieren kann).

Da ich unter anderem für solche Projektarbeiten angestellt bin, sehe ich den Kostenfaktor Personal nicht ganz so kritisch, zumal die Entwicklung keine Monate verschlingen würde.
Im Prinzip ist das was gefordert ist, relativ simpel, aber eben im NAV Standard sowie in den Branchenlösungen die ich mir bisjetzt angeschaut habe, nicht vorhanden.
Vieleicht habe ich den Betreff dieses Beitrags auch etwas falsch gewählt. "Modul" ist eventuell etwas zu überdimensioniert.
Es ist im Prinzip eine Erfassung der produzierten Waren mit Soll Ist Ausschuss, hierzu kommen dann allerdings eine ganze Menge produktionsspezifischer und teilweise noch Produktionsstättenspezifischer angaben, die für diesen Produktionsvorgang erfasst werden müssen.

Mit ein paar Tabellen, Forms und 4-5 Reports wäre das ganze abgedeckt.

Wie Ihr sicher merkt, bin ich durch und durch begeistert von diesem Gedanken

Gibt es von Seiten NAV Grunde, die dagegen Sprechen?
Nach dem Motto "Es ist ein absolutes NoGo - eigene 'Module' in NAV abzubilden"?

Vieleicht habe ich den Betreff dieses Beitrags auch etwas falsch gewählt. "Modul" ist eventuell etwas zu überdimensioniert.
[...]
Mit ein paar Tabellen, Forms und 4-5 Reports wäre das ganze abgedeckt.

"Modul" + "Produktion" + "Betriebsdatenerfassung" = Großer Aufwand
Wenn es hier jedoch "nur" um eine individuelle Form der Datenerfassung geht (z. B. um nicht den ganzen Produktions-Prozess im NAV-Standard zu durchlaufen), dann passt das Wort "Modul" wirklich nicht.

Wie Ihr sicher merkt, bin ich durch und durch begeistert von diesem Gedanken

Das klang in deinem ersten Beitrag in diesem Thema aber noch ganz anders:

Aber irgendetwas in mir hat das Gefühl, dass dies nicht der richtige Weg ist.

Gibt es von Seiten NAV Grunde, die dagegen Sprechen?
Nach dem Motto "Es ist ein absolutes NoGo - eigene 'Module' in NAV abzubilden"?

Absolutes NoGo ist es mit Sicherheit nicht, denn wenn es nichts annähernd Vergleichbares auf dem Markt gibt, dann ist es der einzig richtige Weg.
Man sollte sich vorher nur sehr gut umgesehen haben, ob es nicht doch schon etwas gibt, was die Anforderungen größtenteils abdeckt.

1. Erfassung der produzierten Waren mit Soll Ist Ausschuss,
2. produktionsspezifische und teilweise noch produktionsstättenspezifische Angaben, die für diesen Produktionsvorgang erfasst werden müssen.
3. Mit ein paar Tabellen, Forms und 4-5 Reports wäre das ganze abgedeckt.
4. Gibt es von Seiten NAV Grunde, die dagegen Sprechen?
5. Nach dem Motto "Es ist ein absolutes NoGo - eigene 'Module' in NAV abzubilden"?

1. im Istmeldungsbuchblatt, in den Stücklistenzeilen und FA-Zeilen ist Ausschuss als Feld verfügbar.
2. welche spezifischen Angaben wären das? klingt nach erweiterte Stammdaten.

3. zuerst solltest du ein richtiges Projektmanagement aufsetzen:
3.1 Anforderungsanalyse durchführen und in einem Detailkonzept schriftlich festhalten. Das DKZ enthält schon einen Lösungsentwurf.
3.2 Daraus Arbeitspakete schnüren
3.3 Arbeitspakete in einer Fit/Gap-Liste pro Bereich auflisten und bewerten, ob machbar / nicht machbar, falls ja ob im Standard-NAV enthalten / nicht enthalten (programmiert werden müsste)
3.4 Arbeitspakete mit einem Kosten- und Zeitbudget versehen
3.5 Projektstrukturplan
3.6 Projektressourcenplan
3.7 Projektzeitplan
3.8 Verknüpfung zwischen 3.5, 3.6, 3.7
3.9 Unterschrift der Abteilungsleiter / Verantwortungsträger, die ihre Wünsche geäussert haben bzw. das Budget "sponsern" (falls derjenige, der den Wunsch äussert < > derjenige der das IT-Budget genehmigt)
3.10 Übergabe der einzelnen Arbeitspakete an die verantwortlichen Ressourcen (du, dein neuer Kollege, der externe NAV-Partner, Freelancer)
3.11 Umsetzung der Arbeitspakete
3.12 Kontrolle der Arbeitspakete
3.13 Test der Arbeitspakete durch IT
3.14 Auslieferung der Arbeitspakete auf einen Testserver
3.15 Test durch die Fachabteilung
3.16 schriftliche Abnahme der Fachabteilung
3.17 Letzte Intergrationstests
3.18 Go-Live
3.19 Projektnachbetrachtung hinsichtlich Qualität, Budget, Zeit

Es nützt IMHO nix, wenn du die Kurse zu Programming 1 und 2 mit NAV absolvierst, aber weder methodisch noch strukturiert arbeitest.
Dann kann dieses "Modul" auch in eine 1-Jahrearbeit und ABM ausarten.

Das Wort "Modul" ist hier IMHO zu hoch gegriffen.
Ich würde eher von einem Zusatz oder einer Ergänzung sprechen.

Modul heisst für mich, es gibt Stammdaten, Einrichtungstabellen, Buchungsroutinen, druckbare Reports, Bewegungsdaten und nachträgliche Auswertungen

4. nein, es gibt seitens NAV nix, was dagegen spricht. Höchstens von meiner Seite, falls du unstrukturiert vorgehst, dann erzielst du nicht den gewünschten "Mehrwert" für dein U'en, sondern vergeudest deine knappe Ressource Zeit.
5. es gibt kein NoGo, mit C/AL Programmierung kann man NAV bis zum "hastdunichgesehen" aufbohren. Die Kosten hierfür steigen aber exponentiell an, weshalb irgendwann ein anderes ERP oder eine NAV kompatible 3rd Party Lösung / AddOn evtl. kostengünstiger wären.

Hallo,

ich kann mich nur den Vorrednern anschliessen... eine komplette Eigenentwicklung ist meines Erachtens definitiv die teuerste Lösung. Zumindestens wenn es dann eine ernstzunehmende Komplexität erreicht. Und das muss ja wohl so sein wenn die schon erheblich komplexen Lösungen auf dem Markt es nicht bringen. Ihr tragt das Entwicklungsrisiko, könnt im Zweifelsfall niemanden fragen und / oder externe Hilfe holen (und wenn dann nur für Geld), und macht (laut Statistik) alle Fehler, die die anderen auch gemacht haben, und müsst sie wieder ausbügeln.
Eine gründliche Anforderungsanalyse und ein Vergleich mit dem was es auf dem Markt gibt scheint der sinnvollste nächste Schritt zu sein. Und auch der wird Geld kosten, ich sage nur "Workshops", weil darauf läuft es hinaus.

LG Jens

Zunächst mal vielen vielen Dank für die schnellen Meinungen und Denkanstöße!

Ich werden wohl zunächst so wie von Freestyler beschrieben vorgehen und anschließend eine Entscheidung treffen bzw. eine persönliche Empfehlung an die Entscheidungsträger abgeben.

Vielen Dank!

Gruß

howare