|
AW: ERP Software mit Delphi
Wenn ich euch beide, Holger und Bernhard, jetzt richtig verstanden habe, beinhaltet ein WaWi lediglich die Warenwirtschaftsverwaltung, also Warenein- und -ausgang, Preise und Lagerverwaltung. Rechnungswesen, Kostenrechnung, Gläubiger- und Debitorenverwaltung, Buchhaltung und Kalkulation gehören nicht dazu? Im Gegensatz würde ein ERP umfassenderen Überblick über alle nur existierenden Geschäftsabläufe bieten, also nicht nur Daten, sondern auch Datenauswertung in Form von Tabellen und Diagrammen?
Da die Grenze zwischen WaWi und ERP laut Wikipedia fließend sein soll, kann man das ja nicht genau abgrenzen. Es geht mir daher nur um eine gedankliche Möglichkeit der Unterscheidung zwischen den beiden Modellen, um der Diskussion hier überhaupt folgen zu können. Kann man das grob wie oben ausdrücken? Zitat:
|
AW: ERP Software mit Delphi
Ja, der Übergang ist absolut fliessend und auch der Schwerpunkt ist ja nach Brranche sehr unterschiedlich.
Fall 1: Ein CNC Auftragsfertiger bekommt oft sogar das Material noch von seinem Kunden gestellt oder nutzt einfaches Rohmaterial (Rundstahl in verschiedenen Qualitäten und Abmessungen), das er je nach EK und Auftragsbestand auch mal großzügig auf Lager bestellt. Er muß aber für verbindliche Liefertermine in erster Linie die Kapazitäten seiner CNC Fräsen mit seinem Auftragsbestand abgleichen und im Einzelfall sogar Arbeitsgänge extern vergeben. Das klingt zwar sehr einfach, kann aber auch recht komplex werden, insbeosndere wenn man mehrere Maschinen mit gleichen Fähigkeiten, aber unterschidlichen Geschwindigeiten hat. Ein Mitarbeiter kann in so einem Umfeld meistens auch mehrere Maschinen bedienen und somit kann seine Arbeitszeit auf mehrere Aufträge verbuchen. Spezielle Arbeitsgänge wie Härten beeinflussen die Durchlaufzeit noch mal zusätzlich. In diesem Fall ist die Stücklistenproblematik meistens relativ unwichtig, aber die zeitliche Betrachtung sehr wichtig, die aktuellen Einkaufspreise für das Rohmaterial sind hier selten der wichtigste Faktor, weil die Maschinenkosten meiste wesentlich höher sind. Die Maschinenkosten zu kennen und deren Auslastung über das Jahr zu kennen ist entscheidener Faktor für die Preisfindung. Lohnkosten sind ein Faktor, aber relativ kostant. Fall 2: Ein Maschinenbauer, der zum Beispiel Steuerungsanlagen für Schiffe baut, hat dagegen auftragsbezogen Baugruppen zu fertigen, die möglichst auch in der richtigen Reihefolge aus der Fertigung kommen sollten. Er bestellt dafür noch diverse Hydraulikschläuche und sonstiges Material für die Montage und muss den ganzen Kram auch oft noch auf jeden Fall rechtzeitig vor Ort montieren. Dafür muß er aber auch sicherstellen, das sein Montageteam am Tag x auch verfügbar ist ist definitiv das gesamte gebrauchte Material vorhanden ist, im Einzelfall geschieht die Montage sogar während der ersten Test-/Probefahrten, so das 5 Minuten Verspätung oder auch eine fehlende Schraube mehr als ärgerlich ist. Wenn hier was an der Stückliste nicht passt, kostet das richtig Geld. Hier kommt es zunächst auf die Stückliste an. Für die Auftragssumme ist die Kenntnis der aktuellen Einkaufspreise extrem wichtig. Maschinenkosten sind in diesem Fall meist weniger wichtig, aber auch nicht zu unterschätzen. Ggf. müssen externe Dienstleister mit beauftragt werden, so das Lohnkosten hier ein sehr großer und teilweise nur begrenzt kalkulierbarer Faktor sind. Fall 3: Ein Zulieferer, der Module für die Federung eines Autoherstellers per Laserschweißen verbindet, hat einfach nur diverse Gitterboxen vom Vorlieferant mit der nicht verbundenen Rohteilen in seiner Halle stehen. Ein Mitarbeiter nimmt die Teile raus, steckt die in eine Vorrichtung, drückt einen Knopf und dann knattert es diverse male und das Ding ist verbunden. Hier kommt es in erster Linie auf den Bau der Vorrichtung an, mit der das automatisiert verarbeitet werden kann. Für einen Angebotspreis muß man wissen, wie oft dieser Artikel gefertigt wird und in welchen Mengen das jeweils gebraucht wird. Wenn eine Maschine 50 Stück in einer Schicht schafft, aber 100 Stück bebraucht werden, muß man sich was überlegen (Zweite Maschine und zweite Vorrichtung (wenn bezahlbar) und wenn ein Mitarbeiter beide Maschinen gleichzeitig bedienen kann, sonst Zweischichtbetrieb). Wenn 10000 Stück gebraucht werden, muß man Mitarbeiter und Maschine ca. 100 Tage im 2 Schichten (oder 200 Tage bei einer Schicht) einplanen und für die Kalkulation des Einzelpreises den Energieverbauch, die Maschinenkosen (Afa Werte für 100 Tage + x%), die Lohnkosten für die 2 Schichten, die Gemeinkosten, usw. in einen großen Topf werfen und durch 10000 teilen. Das ganze dann mit einem geplanten Gewinnaufschlag dem Kunden als Angebot mitteilen. Wenn der Preis passt, dann passt es auch für das Unternehmen. Handwerker kalkulieren oft ganz anders (im Sinne von: Was könnte der Kunde denn als Preis akzeptieren ....) Man kann aber mit relativ wenig Dokumentation die eigenen Zahlen deutlich besser erfassen, dafür muß nicht jeder Handschlag mit Barcode an- und abgemeldet werden. Wenn jeder Mitarbeiter abends die Arbeitszeit auf die Fertigungsaufträge anteilig verteilt, an denen er gearbeitet hat, sieht man wesentlich früher ob ein Auftrag schon einen negativen Deckungsbeitrag erwirtschaftet hat, wenn man es denn wissen möchte. Sehr viele Unternehmen arbeiten nun mal seit Jahren finanziell erfolgreich und kriegen schon die Krätze, wenn man denen zeigt, das man in einer Software zig Minuten braucht, um einen Fertigungsauftrag zu erstellen, der ohne Stückliste auch nicht erstellt werde kann, ohne den keine Zeiten gebucht werden können und die Zeitbuchungen zwangsweise per Terminal erfolgen müssen. Dann nutzt der Kunde die Funktion eben nicht weil er dafür keine Zeit hat und sich der Aufwand nur bei Serienteilen rechnet. Wenn nun (wie in der Realität üblich) ein Mitarbeiter einem Kollegen bei einem anderen Auftrag hilft, müsste er nun erst mal zum Terminal dackeln, sich am alten Auftrag abmelden, am neuen anmelden, dann helfen, dann wieder abmelden, anmelden, usw. Das ein Mittelständler da die Nackenhaare auf Halbmast stehen, verstehe ich nur zu gut, ist ja auch nicht bei jeder Software so. Ist aber für alle hier im Forum ein sehr spannendes Marktsegment, weil gerade diese Firmen meistens finanziell gut aufgestellt sind und es sich auch leisten können, Software so erstellen zu lassen, wie man sie denn haben will und nicht wie jemand anderes denn meint, wie man arbeiten soll. Es ist aber ein Bereich, bei den man relativ leicht durch Unkenntnis der üblichen Betriebsabläufe schon bei den ersten Gesprächen mit dem potentiellen Kunden Probleme bekommt, die eigene Qualifikation für den Auftrag erfolgreich darzustellen. Oft wissen die Kunden zwar wie es geht und wie man es derzeit macht, können (und teilweise wollen) das aber beim besten willen einem Externen ohne Branchenkenntnisse so erlären, das er es programmieren könnte. Wenn die Software am Ende für die Anforderungen des Kunden passen, ist es auch relativ egal, ob man die Wawi, ERP, PPS, oder sonstwie nennt. Scheut euch nciht davor, auch nur Teilbereiche abzudecken, viele Kunden arbeiten im Wawi Bereich zum Beispiel mit Lexware und finden das auch ganz ok, das hat aber für Fertigung Null Funktionalität, also lieber den Teil für den Kunden umsetzen, der Ihm fehlt, wenn Ihr keine eigene Ersatzlösung auf gleichen Niveau habt, als mit aller Gewalt alles ersetzen zu wollen. Schnittstellen zu kleinen Teillösungen, die Ihr programmiert, sind oft der erste Schritt in eine großeres und gerade auch für Einzelkämpfer dauerhaft lukratives Projekt. Den meisten Kunden ist es dann auch egal, ob Ihr das mit Delphi oder sogar in Assembler programmiert, Hauptsache es macht was es soll. Wenn Ihr dem Kunden dann auch offen Zugriff auf den Quellcode anbietet, wobei damit keinerlei weitere Vermarktung ohne eure Zustimmung erlaubt ist (einfach in jeden Header reinschreiben das Ihr das nicht erlaubt), dann schafft das erstens Vertrauen und wenn man realistisch ist, kann der Kudne ohne eure Hilfe damit meistens eh nichts anfangen, weil damit ja nicht unbedingt eine lauffähige Kopie der Entwicklungsumgebung verbunden ist, die er im Falle Delphi ja auch mit allen Komponenten erst mal kaufen müsste. Ich nehm mal den klassischen Handel hier raus, der ist meistens mit Standardsoftware ganz gut bedient, bei Fertigungsbetrieben sieht das aber schon ganz anders aus |
AW: ERP Software mit Delphi
Hallo Holger,
das war jetzt mal eine für meine Bedürfnisse sehr erhellende Erläuterung. Dafür sei dir herzlich gedankt. :thumb: Ich denke, ich begreife langsam den Umfang von ERP-Systemen. Die können offenbar sehr komplex und kompliziert werden ... Und ein WaWi kann also auch Buchhaltung und alles, was damit zusammenhängt, beinhalten, ohne gleich ein ERP zu sein? Zitat:
|
AW: ERP Software mit Delphi
Zitat:
 Werbung? |
AW: ERP Software mit Delphi
nein , eine Buchhaltung würde ich weder in einer Wawi noch in einem ERP System suchen , sie liefert beiden nur die Daten
|
AW: ERP Software mit Delphi
Zitat:
In erster Linie wird aber die Finanzbuchhaltung von Daten asu dem Rechnungswesen gefüttert und nicht umgekehrt. Für die Ermittlung von Gemeinkosten geht das dann gleich in die Kostenrechnung über, die sich dann meistens wieder Daten aus der Fibu bedient. Zitat:
Zitat:
Ich maße mir übrigens auch nicht an, sämtliche Handelsprozesse zu kennen, dafür beschränkt sich meine Praxiserfahrung doch mehr auf fertigende Unternehmen (bei denen ich aber auch nicht sämtliche Prozesse kenne). Da ich aber teilweise schon seit 25 Jahren für solche Firmen Software entwickelt habe, blieb da doch einiges hängen. Praxiserfahrung ist etwas, was in vielen Branchen sehr viel wichtiger ist, als Programmiererfahrung. Wir haben mal eine Programmiererschulung für verschiedene Mitarbeiter aus einem Oberlandesgerichtsbezirk gemacht. Die waren alle Justizoberinspektor oder wie auch immer die Titel da heißen, teilweise sogar selber Richter. Es war in diesem Fall einfacher, den Fachleuten das Programmieren beizubringen, als einem Programmierer das Fachwissen beizubringen. Wenn man also eine Branche hat, bei der man Spezialkenntnisse hat und trotzdem Programmieren kann, dann hat man schon eine ganz gute Marktposition, wenn die Branche nicht leider gerade am Aussterben ist. Es zählt dann eben in erster Linie, wie kann ich meine Kenntnisse an potentielle Abnehmer kommunizieren und ob man es glaubt oder nicht, dafür sind Branchenfachmessen immer noch die erste Wahl, wenn man sich traut, einfach mal ein paar Aussteller anzuquatschen, gerade wenn man das freiberuflich und Projektbezogen machen kann. |
AW: ERP Software mit Delphi
Zitat:
|
AW: ERP Software mit Delphi
Zitat:
K-H |
AW: ERP Software mit Delphi
Moin,
nur zur allgemeinen Information, mein Beitrag war nicht als Werbung gedacht, sondern als Hinweis auf die vielseitigen Varianten von ERP - Systemen und den Möglichkeiten diese alle mit Delphi zu bedienen. Für die Werbung unserer Produkte nutze ich definitiv andere Plattformen, das Forum ist ganz sicher der falsche Platz dafür. Wenn du schon so genau auf Werbung achtest, dann solltest du auch Links auf proffessionelle Seiten entfernen, wie sie gerne in den Nutzer Profilen hinterlegt werden. 8-) Nein im Ernst, das ist natürlich Quatsch, aber Deine Reaktion IMHO auch leicht überzogen.... Beste Grüße Michael |
AW: ERP Software mit Delphi
Ja die Werbeaufsicht hat mich auch gekickt :cyclops:
Aber ok, ich verstehe es ja, ich könnte ja auch einen bezahlten Werbebanner schalten :wink: |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 16:30 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz