|
AW: ERP Software mit Delphi
Seid bitte so gut und kommt vom Thema "Component-Replacement" wieder zu den ERP-Systemen. :-)
|
AW: ERP Software mit Delphi
Der Titel trifft 2 Themen:
1. Braucht man noch ein neues ERP-System? ...Schlage einen neuen Thread vor,bei em man vorhandene ERP-Systeme ...vergleicht und dann nach Lücken im Markt sucht. 2. Eignet sich Delphi für eine Programmklasse bei der Webfrontends ...und standortübergreifende Vernetzung üblich sind. ...Ist hier der Vorsprung von Java und Net inzwischen zu groß? Grüße in die Runde Martin |
AW: ERP Software mit Delphi
So nochmal ein Versuch da mein Voriger Beitrag gelöscht wurde da er Werbung enthielt!:thumb:
Suche dir ein ERP System was Du Programmieren und anpassen kannst, diese gibt es auch auf delphi basierende mit eigenen Delphiscriptsprachen. Welches das ist kann ich hier nicht Posten, sonst wird mein Beitrag wieder gelöst, also suchen und finden, dann sparst Du Dir einige Jahre Entwicklungsarbeit ..... |
AW: ERP Software mit Delphi
Ich habe auch mal ein BDE/MES entwickelt. Läuft heute noch. Alle Wendeln (in Glüh- und Entladungslampen) von OSRAM gehen durch meine Software. Anpassbar ist es auch. Und in Delphi entwickelt.
|
AW: ERP Software mit Delphi
Zitat:
|
AW: ERP Software mit Delphi
Zitat:
|
AW: ERP Software mit Delphi
Zitat:
|
AW: ERP Software mit Delphi
und was hilft das nun dem Ersteller dieses Threads?
|
AW: ERP Software mit Delphi
Er sieht dass es nicht so einfach ist und man sich in die Haare kriegen kann. Er hat sich aber auch seit 3 Tagen nicht mehr zu Wort gemeldet´.
|
AW: ERP Software mit Delphi
Um nochmal zurück zum Thema zu kommen:
also Delphi ist nach wie vor wirklich super geeignet für die GUI Entwicklung. Wie aber Martin schon sagt, ist es derzeit leider schwierig wie wir alle wissen, jetzt kommt man zurück zum leidigen Thema Zukunft von Delphi. Ich muß leider sagen: ich würde derzeit leider auch kein Projekt im Umfang eines ERP, welches auch eine Lebensdauer von 10+ Jahren hat, mit Delphi *beginnen*. Mit DevExpress sind wir allerdings absolut top aufgestellt im GUI Bereich, auch bei den Entwicklungszeiten => Kosten. Letztlich ist fakt, das Dir hier eigentlich alle davon abraten. Inhaltlich, der Kosten wegen, der Erfahrung wegen, der Standards wegen und nicht zuletzt leider auch, da die Aussichten von Delphi derzeit zu nebulös sind. Sucht Euch ein System, welches Euch von der Philosophie und bedienweise gefällt und wo Ihr die Möglichkeit habt, die Strukturen der Software auch an Eure anzupassen, oder eben sogar an den Code kommt um eigene Dinge implementieren zu können. Wir haben ja wie gesagt auch die Philosophie kein Massenprodukt zu sein, sondern eben doch individuell pro Anwender zuzuschneiden und mit unseren Kunden eng zusammenzuarbeiten. Und da gibt es noch einige Hersteller. Wichtig ist, das Ihr nicht Kunde 5000 seid, sondern unter den ... sagen wir Top 30. Dann macht der Hersteller .... vieles möglich. ;) Daniel. |
AW: ERP Software mit Delphi
Zitat:
Ich würde es vielleicht anders ausdrücken: Die Anpassbarkeit muss gewährleistet seit, aber der Kern der Software muss passen. Es wäre sehr sinnvoll, wenn das System über eine API verfügte, für die man beliebige Clients entwickeln kann. WEnn man dann noch Zugriff auf die DB hat und eigene Tabellen anlegen kann, dann ist man imho flexibel genug. |
AW: ERP Software mit Delphi
Zitat:
|
AW: ERP Software mit Delphi
Zitat:
Mir ging es um produzierende klein- bis mittelständische Unternehmen und da ist tatsächlich sehr, sehr vieles vergleichbar. Ein Orthopäde und ein Mercedes-Händler passen aber in dieses Schema tatsächlich nicht rein. ;) Und natürlich ist bei der Einführung immer Handarbeit gefordert, da sind wir uns doch völlig einig. Aber mit den Kern-Funktionen eines guten ERP-Systems kann man schon mal viel abbilden (und eben mehr als die meisten denken, weil sie sich für sehr individuell halten - darum ging es mir) und der Rest lässt sich dann gut durch Skripte o.ä. anpassen. Bis denn Bommel |
AW: ERP Software mit Delphi
Um mal zum Anfang zurückzukommen :
Zitat:
 http://de.wikipedia.org/wiki/Eierlegende_WollmilchsauUm alles mögliche abzudecken, dann gehts auch kaum anders. Aber ist das gut ? Den AvERP Quelltext (nur die DB), habe ich mir mal angesehen, allerdings vor ca. 3 Jahren. Um da zu wissen, wozu was gebraucht wird (3-stellige Anzahl an Tabellen, SPs usw.), das würde Wochen, eher Monate dauern. In wesentlich kürzerer Zeit (Stunden /Tage) hätte ich (mit Sicherheit auch kleinere) DB selber aufgebaut, die auch zu 100% passen würde. |
AW: ERP Software mit Delphi
Hans Du scheinst das Prinzip hinter AvERP nicht verstanden zu haben. Die Datenbank ist ja nicht die Datenbank für das zu entwickelnde System, sondern die des darunterliegenden AvERP. Willst du dieses erweitern, kannst Du die Datenbank verändern ( bei gleichzeitiger Anpassung des Quellcodes) willst Du "nur" ein System damit entwickeln, solltest Du tunlichst die Finger von der DB lassen!
Zitat:
Zitat:
Wenn man Deinen Beitrag so liest könnte man daraus ableiten "15 -20 MJ = wenige Wochen Hansa" |
AW: ERP Software mit Delphi
Zitat:
Denke ich genauso. Ein Ansatz: Wochen ist vielleicht für einen GUI-Prototypen oder die Aufnahme der Anforderungen oder Use-Cases zu schaffen aber für kein Produktives ERP-System. Hier werden die Möglichkeiten/Notwendigkeiten selbst der minimalen absolut notwendigen Kernfeatures eines ERP vollkommen unterschätzt. |
AW: ERP Software mit Delphi
Zitat:
|
AW: ERP Software mit Delphi
Zitat:
eben habe ich versucht, den Unterschied zwischen ERP und WaWi zu ermitteln und bei Wikipedia gelesen, daß der Übergang zwischen Warenwirtschaftssystem und ERP-System nicht klar definiert sei: "Die Abgrenzung erfolgt in der Regel anhand des Funktionsumfanges. Sind z. B. Funktionen oder Module im Bereich Controlling und Materialwirtschaft integriert, spricht man eher von einem ERP, als von einem WWS." Nun steht aber am Anfang der Erklärung des WaWi-Begriffs, es sei "ein Modell zur Abbildung der Warenströme im Geschäftsprozess eines Unternehmens".Worin besteht denn nun der Unterschied zwischen Materialwirtschaft und Warenwirtschaft? Denn wiederum bei Wikipedia werden Materialwirtschaft und Warenwirtschaft als Synonyme behandelt: "Die Materialwirtschaft oder Warenwirtschaft beschäftigt sich mit der Verwaltung sowie der zeitlichen, mengenmäßigen, qualitativen und eventuell auch räumlichen Planung und Steuerung der Materialbewegungen innerhalb eines Unternehmens und zwischen dem Unternehmen und seiner Umwelt. Sie koordiniert den Warenfluss zwischen Lieferanten, Kunden, Bedarfsträgern (zum Beispiel Produktion) und den Lagern. In produzierenden Unternehmen stellt sie die Versorgung der produzierenden Bereiche mit direkten Gütern wie Roh-, Hilfs- und Betriebsstoffen, Zulieferteilen und Halbfabrikaten sowie allgemein die Versorgung mit indirekten Gütern wie Büroartikel, Ersatzteile oder Serviceleistungen sicher."Der Begriff Controlling, der ebenfalls zur Abgrenzung eines ERP zu einem WaWi verwendet wird, besagt laut Wikipedia doch auch nur, daß die Daten, die das ERP liefert, zur Kontrolle des Betriebs verwendet werden. Ist das denn bei einem WaWi anders? Oder betrifft Controlling nicht bereits das, was bei Wikipedia als Management-Informations-System (MIS) bezeichnet wird?Meine eigentliche Frage lautet aber: Was bietet ein Enterprise Resource Planning-Systemen (ERP) mehr an Funktionen, das nicht durch ein Warenwirtschafts-System (WaWi) gedeckt ist? |
AW: ERP Software mit Delphi
naja, WaWi ist schon nur ein ganz kleiner Teil einer ERP Software, weil da der ganze Part Fertigung fehlt. Das nannte in der Steinzeit noch PPS (Produktionsplanungssystem) und war eine eigene Softwaregattung, die mit Beschaffung relativ wenig zu tun hatte.
Ob man nun aber bei einem Mercedes Händler oder einem Orthopäden eine komplexe Fertigungsplanung braucht, hängt sicher von der Größe des Unternehmens ab. Die Dokumentation, wer and welchem Auftrag wie lange gearbeitet hat und welches Material verbraucht wurde, ist aber auch bei kleineren Unternehmen gar nicht mal so blöd, um den realen Aufwand abrechnen und den Ertrag bewerten zu können. In kleinen Handwerksbetrieben meint der Chef das meistens aber auch aufgrund seiner Erfahrungswerte so zu wissen (und fragt sich am Jahresende, warum er wieder kein Geld verdient hat). Dafür muß es aber auch nicht zwingend Fertigungspläne, Stücklisten, Kapazitätsauswertungen, usw. geben, aber schaden tut es auch nicht, es sei denn, der Aufwand diese zu erstellen, ist zu hoch, was bei vielen Einzelfertigern sehr oft der Fall ist. Beim Beginnn einer Inspektion eines Kundenfahrzeugs aber schon zu wissen, das die dafür erforderlichen Ersatzteile (wie z.B. der Ölfilter) auf jeden Fall auf Lager sind, ist schon gar nicht so blöd. AvERP hat übrigens mittlerweile eine vierstellige Tabellenzahl erreicht, was nicht unbedingt als Merkmal für Qualität zu bewerten ist (sonst wäre die ERP Software eines unserere Kunden aus dem Logistikbereich mit über 4000 Tabellen ja das NON Plus Ultra, ist es aber keineswegs). Die Preisermittlung für Rechnungen war in averp in mehr als 60 Modulen (Reports, Trigger und SPs) verteilt, da hatte sogar ich mit diversen Jahren Erfahrung firebird/averp mehrere Stunden gebraucht, um eigentlich banale Änderungen an den Rabattmechanismen umzusetzen. Closed Source Systeme sind da aber keineswegs im Vorteil. ERP muss nicht immer gleich SAP sein, ist aber sicherlich mehr als Wawi .... |
AW: ERP Software mit Delphi
Zitat:
Ein Mercedes-Händler brauch keine Fertigung. Es hat zwar ein Werkstatt ab hier ist der Materialfluss nicht wie bei einer großen Fertigung zu planen. Hier gibt es kein JustInTime-Anlieferung/Planung wie bei einer Autofertigung. Dem entsprechend ist hier kein Fertigungsplaung wie Durchlaufzeiten/Rüstzeiten und ähnliches zu planen. Er hat für die normale Inspektion seine Vorgaben"zettel" und für das Tagesgeschäft (Unfall/Reparatur) seine Meister die solche Schäden Zeit und Materialmäßig abschätzen. Der Mercedes-Händler bekommt seinen Einkaufsschnittstelle (jedenfalls was alles die Autos betrifft) von Mercedes "aufgedrückt". Das Fertigungswerk hat mit den wichtigsten (möglichst allen) Zulieferen direkte ERP-ERP-Kopplungen definiert so das Bestellungen direkt beim Zulieferer in die Planung einfließen. |
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: |
AW: ERP Software mit Delphi
Zitat:
Zitat:
Zitat:
Zitat:
|
AW: ERP Software mit Delphi
Ruhig Blut. :-)
Die Sache war doch erledigt und wir als Team sind uns der Tatsache sehr wohl bewusst, dass die Frage, was Werbung ist, höchst subjektiv ist. Und dann müssen wir halt einfach eine Entscheidung treffen. Dem einen mag sie zusagen, dem anderen weniger. Ich möchte aber daran erinnern, dass wir über sehr, sehr wenige Beiträge reden und auch dann sind es "nur" Beiträge: Niemand von uns fährt zum (vermeintlich) Webetreibenden und zündet dessen Firmensitz an. (Zumindest dieses Jahr haben wir davon Abstand genommen...) Wir sollten das Thema "Werbung" nicht höher hängen, als es das verdient. :cheers: |
AW: ERP Software mit Delphi
Zitat:
Was spricht eigentlich dagegen, all diese Komponenten – Buchhaltung, Personalverwaltung, Finanzwesen, Warenwirtschaft, Statistik, Auswertung und was sonst noch alles an Firmen-Software nötig ist – in einem Paket zu liefern oder anzubieten? Meinetwegen auch als nachrüstbare Module mit einer WaWi oder Finanzbuchhaltung als Basis-Modul? |
AW: ERP Software mit Delphi
Zitat:
Gruß K-H |
AW: ERP Software mit Delphi
Kommt auf die Betriebsgröße des Softwareanbieters an ,
wenn du so ab hundert Programmierer aufwärts hast , kein Problem :) Buchhaltung, Lohnabrechnung, Personalwesen sind sensible Bereiche die durch, auch mehrfach im Jahr , sich ändernde Gesetze und Bestimmungen ständig aktualisiert werden muessen, da sitzt dann ne halbe Abteilung dauerhaft nur in Fortbildungen um die Änderungen mitzukriegen :) Ausserdem , wenn deine WaWi/ERP Mist baut und mal ein paar Teile mehr bestellt , dann zahlts im schlimmsten Fall deine Betriebshaftpflicht, bei dem Steuer, Zoll und Lohnzeugs stehst du als "Laie" mit einem 1/2 Fuss im Knast |
AW: ERP Software mit Delphi
Zitat:
Aber, die Moderatoren haben eine Linie und diese durchgezogen. Keinem wurde geschadet, alles ist in Butter. Alles ist richtig gemacht worden. Vor einigen Jahren fleuchte ein DP-Mitglied (Helge Lange) hier herum und bewarb sein Delphi-ERP-Framework (ERP-Components) beinahe täglich bzw. berichtete, was er nun alles neues eingebaut hat. Damals krähte kein Hahn danach, aber so ändern sich die Zeiten. Zitat:
|
AW: ERP Software mit Delphi
Zitat:
SAP, Navision, Infor, Oracle, Sages und Co. dieser Welt ... |
AW: ERP Software mit Delphi
Arbeitet dort einer mit Delphi, ich glaube nicht oder nur mit Nebenprodukten.
Wo hier die Werbung raus geworfen wurde, die haben zum Teil Lösungen, die mit Delphi gemacht wurden mehr oder weniger erweiterbar und anpassbar sind, aber man darf ja nur über nicht im Forum teilnehmende hier schreiben, was eigentlich bei dieser Fragestellung etwas schade ist! |
AW: ERP Software mit Delphi
Könntet Ihr wieder zum Thema zurückkehren, dass Ihr mit meiner (unserer) Entscheidung zum Thema Werbung und was darunter fällt nicht einig seit, habe ich längst zur Kenntnis genommen.
|
AW: ERP Software mit Delphi
Meiner Frage nach Gründen, weshalb es eigentlich keine Anwendung gibt, die alle Bereiche eines Unternehmens abdeckt, lag die Problematik zugrunde, daß ja nicht jedes Teilsystem mit jedem anderen kompatibel ist. Soweit ich das bislang mitbekommen habe, müssen Systeme, die auf Daten von anderen Applikationen angewiesen sind, immer erst an diese angepaßt werden, bevor man damit sinnvoll arbeiten kann. Leichter hat man's da, wenn man sich direkt mit der Datenbank des "Quell"-Systems verbinden kann, und auch da braucht man in der Regel Username und Passwort, was ja nicht jeder FiBu-Entwickler herauszugeben bereit ist.
Daß der Aufwand, eine "eierlegende Wollmilchsau" für Firmen zu entwickeln, im Grunde nicht von einer Firma bewältigt werden kann, ist mir durch eure Antworten nun endgültig klar geworden, auch wenn ich mangels Erfahrung vermutlich nur eine vage Vorstellung davon habe, wie riesig der Aufwand wirklich wäre. Die ganze Thematik ist für mich dennoch oder gerade deswegen hochinteressant, weil man sonst kaum derart wichtige Details quasi aus erster Hand erfährt. Ich danke den Ausführenden für ihre wertvollen Hinweise. :!: :thumb: :coder2: |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 11:52 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz