ERP Software mit Delphi

[mkinzler]

Zitat:

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.

Das birgt aber eine gewisse Gefahr, dass bei Änderungen an der Datenbank, abhängige Systeme nicht mehr funktionieren oder noch schlimmer, dass die Datenbank unbrauchbar wird.

Besser sind Schnittstellen, die die eigentliche Datenstruktur abstrahieren.

[Furtbichler]

Zitat:

Zitat von mkinzler (Beitrag 1225037)

Das birgt aber eine gewisse Gefahr, dass bei Änderungen an der Datenbank, abhängige Systeme nicht mehr funktionieren oder noch schlimmer, dass die Datenbank unbrauchbar wird.

Sei mir nicht böse, aber ganz so dämlich sind professionelle Systeme nun wirklich nicht.

Folgende Maßnahmen sind durchaus effektiv:
1. Virtuelle Tabellen bereitstellen. Einfach: Views, besser: updateable Views
2. Rechte des Anwenders genau definieren, d.h. Änderungen an Tabelle nicht zulassen (geht bei virtuellen Tabellen eh nicht)
3. Consumer-Bereich (aka Tablespace oder separate DB) erstellen und dort alle Rechte zuweisen.

Somit kann die DB nicht unbrauchbar werden.

Es gibt auch Systeme, die per Admin-Tool erweitert werden können. Dadurch wird die Integrität gewährleistet und nix kann kaputtgehen. Hier können Erweiterungen an Tabellen vorgenommen werden, alle Views und CRUD-Routinen werden automatisch angepasst. Systemrelevante Spalten/Tabellen können natürlich nicht verändert werden.

Ich kenne ein (BuHa-)System (nein, nicht meins), das in Delphi geschrieben ist und sehr flexibel ist. Hier können einfach zusätzliche Tabellen erstellt werden, die die individuellen Daten enthalten. Per Konfiguration werden die Dialoge angepasst, zur Not auch mit Customizing, aber das ist laut Hersteller etwas blöd, eben wegen der Upgradeproblematik.

Es geht aber auch ohne.

[mkinzler]

Wenn B direkt auf die Daten von A zugreift ohne das A B kennt kann so etwas bei Änderungen von A passieren. Es geht hier ja nicht um ein integriertes System, bei dem sich A und B absprechen.

[Furtbichler]

"Direkter Zugriff" ist das Zauberwort. Jedes halbwegs normale System wird hier den schreibenden Zugriff hinter einer -wie auch immer gearteten- API verstecken. Das reicht von einer klassischen API eben bis zu virtuellen Tabellen.

Lesen kann man ja alles, ohne das es zu Manipulationen kommt. Und Schreibzugriffe sollten *immer* über eine Fassade laufen.

[mkinzler]

Das meinte ich mich "Schnittstelle". Ob das nun eine API ist oder Views sind ist ja zweitrangig.

[Perlsau]

Zitat:

Zitat von mkinzler (Beitrag 1225037)

Zitat:

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.

Das birgt aber eine gewisse Gefahr, dass bei Änderungen an der Datenbank, abhängige Systeme nicht mehr funktionieren oder noch schlimmer, dass die Datenbank unbrauchbar wird.
Besser sind Schnittstellen, die die eigentliche Datenstruktur abstrahieren.

Tja, dann muß der Anbieter des abhängigen Systems eben nachziehen. Hab mal an einem solchen Fall gearbeitet: Datenbank war eine sehr komplexe MSSQL-Struktur, hunderte von Tabellen, die meisten gar nicht oder kaum benutzt/belegt. Bis ich überhaupt erst mal herausgefunden habe, welche Tabelle mit welcher in Beziehung steht, vergingen schon ein paar Tage. Der Betreiber des WiWa (denn darum handelte es sich), sprich: der Firmenchef konnte mir dazu auch nichts weiter sagen, der kannte nur seine Programm-Oberfläche, und davon auch nur einen geringen Teil, denn das meiste machten ja seine Angestellten. Meine Aufgabe bestand darin, eine Katalog-Software, die im Grunde durchgestilte Berichte für's Internet oder die Druckerei erstellt, an diese Datenbank anzupassen. Änderungen an der DB waren selbstverständlich tabu. Ich hab allein für die Anpassung gute drei Wochen gebraucht: Welche Daten, die das abhängige Programm benötigt, stehen wo, welche Daten sind veraltet (zwischendrin gab's auch Updates des WiWa-Betreibers), welche Artikel doppelt oder unvollständig usw. Das war fast schon als Chaos zu bezeichnen.

[Furtbichler]

Normalerweise, bzw. in meiner kleinen Welt, werden System nicht so gekoppelt, das man direkt ins Zielsystem schreibt.

Normalerweise gibt es den berühmten Pull/Push-Mechanismus, d.h. Import/Export-Dateien, wobei 'Dateien' auch ein Synonym für eigenen Tabellen sein kann. Natürlich gibt es auch die berühmten TXT/CSV/XML-Dateien in einem Verzeichnis deiner Wahl.

Der Import in die eigene DB wird dann von customized-Importprozessen vorgenommen. Meist behält sich der Anbieter vor, die Importe zu schreiben, was auch anzuraten ist. Bei SAP kann man das auch selbst machen, da die meines Wissens nach, das Paradigma der virtuellen Tabellen mit einer API verfolgen, d.h. man beschreibt bestimmte 'Tabellen', um Daten zu importieren.

[Perlsau]

Zitat:

Zitat von Furtbichler (Beitrag 1225053)

Normalerweise, bzw. in meiner kleinen Welt, werden System nicht so gekoppelt, das man direkt ins Zielsystem schreibt.

Mich hat das damals auch etwas gewundert, daß ich eine vollständige Kopie der Firmen-DB einfach so erhalten habe. Da waren auch Bankverbindungen und Kontenbewegungen drin. Selbstverständlich hab ich nichts programmiert, um da reinzuschreiben, es ging nur um's Auslesen des aktuellen Artikelbestandes nebst Preisen, Bildern, Attributen wie Länge, Breite, Höhe, Gewicht, Farbe usw. Irgendwelche virtuellen Tabellen waren da nicht zu sehen, alles war stark normalisiert, d.h. jede Möglichkeit, Subtabellen anzulegen, wurde genutzt. Ich weiß bis heute nicht mal, mit welchem WiWa-System dort genau gearbeitet wurde, ich hatte nur die DB als Zip-Datei erhalten.

Zitat:

Zitat von Furtbichler (Beitrag 1225053)

Normalerweise gibt es den berühmten Pull/Push-Mechanismus, d.h. Import/Export-Dateien, wobei 'Dateien' auch ein Synonym für eigenen Tabellen sein kann. Natürlich gibt es auch die berühmten TXT/CSV/XML-Dateien in einem Verzeichnis deiner Wahl.

Das würde aber auch bedeuten, daß bei einem Daten-Update des abhängigen Systems immer zwei Schritte notwendig sind: Export vom Quellsystem und Import ins Zielsystem. Bei meiner damaligen Entwicklung war immer nur der Importvorgang nötig, das Aktualisieren des Quell-Systems besorgten die Damen in der Fakturierung. Beim Start des Katalog-Programsm wurde dann automatisch dessen DB aktualisiert: Veränderungen übernommen, nicht mehr existierende Artikel gelöscht, neue Artikel eingefügt. Das war im Grunde eine doppelte Verwaltung, ging aber nicht anders, weil die Suche in der Quell-DB viel länger dauerte als in der Katalog-DB.

Zitat:

Zitat von Furtbichler (Beitrag 1225053)

Der Import in die eigene DB wird dann von customized-Importprozessen vorgenommen. Meist behält sich der Anbieter vor, die Importe zu schreiben, was auch anzuraten ist.

Mit Anbieter meinst du jetzt den Anbieter des zugrundeliegenden Systems, also des Quellsystems, z.B. die FiBu, die Daten für ein WaWi liefern soll? Wenn ja, wie kann ein Anbieter einer FiBu z.B. Importe für ein Warenwirtschaftssystem schreiben, das ein anderer entwickelt hat? Der müßte doch zumindest den Quellcode des WaWi haben, und zudem die entsprechende Entwicklungsumgebung, und sich dann noch mit der Programmiersprache auskennen.

Zitat:

Zitat von Furtbichler (Beitrag 1225053)

Bei SAP kann man das auch selbst machen, da die meines Wissens nach, das Paradigma der virtuellen Tabellen mit einer API verfolgen, d.h. man beschreibt bestimmte 'Tabellen', um Daten zu importieren.

Vielleicht gab es damals bei diesem WaWi ja auch eine entsprechende API, aber das konnte mir niemand sagen, ging ja alles fernmündlich bzw. via Teamviewer über die Bühne. Ich hab die dortige Clientsoftware nie richtig gesehen.

[Hansa]

Zitat:

Zitat von Perlsau (Beitrag 1225059)

...
also des Quellsystems, z.B. die FiBu, die Daten für ein WaWi liefern soll?

Perlsau, wie soll denn eine Fibu (zumindest eine klassische) Daten an ein WaWi liefern ? Auf mittlerweile glaube 9 Seiten wurde die Nomenklatur doch genau erläutert. Wie soll man nun aus Rechnungs/Mwst.-Beträgen (also aus der Fibu) einen Lagerbestand für WaWi rekonstruieren ? :shock: Holger Klemt hat das doch ausführlich beschrieben : FiBu hat nur am Rande etwas mit WaWi zu tun ! Das ist eine Einbahnstrasse. Aus dem Wawi werden sich vielleicht Daten für die Fibu ableiten lassen, umgekehrt aber wohl kaum.

[mkinzler]

Ein WaWi-System benötigt aber u.U. Zugriff auf die Nebenbücher ( Kreditoren, Debitoren) z.B. für das Bestellwesen

[hstreicher]

ich ergaenze mal die vorherige Aussage,

eine Fibu _muss_ einen Rückkanal zur Wawi/ERP haben um zu verhindern dass Kunden die nicht zahlen weiter beliefert werden,
ob das jetzt Elektronisch oder als Liste per Sneakernet erfolgt ist wohl Betriebsgrößen abhaengig

[Furtbichler]

Ich glaube, ihr verwechselt 'man wäre in der Lage, die DB zu schroten' und 'der Datenaustauschprozess funktioniert so, das man direkt in die DB schreibt'.

In der Tat hatte ich bei diversen Systemen direkten Zugriff auf die DB. Verändert man die Daten allerdings, erlischt der Support, die Garantie usw.

Ich persönlich würde beim Datenaustausch hererogener Systeme für die einzelnen Systeme Adapter implementieren (lassen), die ein standartisiertes Austauschformat und -protokoll verwenden.

[mkinzler]

Es ging um die Notwendigkeit des Datenaustausches und Hansas Ansicht, das ein WaWi (Aus seiner Sicht) keine Daten der Fibu benötigt.

[musicman56]

Hallo,

es gibt Standard-FiBu's die per DLL Buchungsstapel(z.B. Debitorensollstellung) verarbeiten, lesenden Zugriff auf die Konten und Stammdaten (Debitoren/Kreditoren, Sachkonten, Kostenstellen...) bieten, und auch Adressänderungen an den Debitoren- und Kreditorenstamm übernehmen können. Die FiBu lässt also schreibenden Zugriff auf die für die Buchhaltung selbst nicht relevanten Daten zu. So soll es sein.

Ich mache das mt meiner WaWi schon über 10 Jahre so zur höchsten Zufriedenheit aller Kunden. Darum meine Meinung (zum Thema des TE): Wer ein ERP programmieren möchte ist gut beraten Lohnabrechnung und Finanzbuchhaltung aussen vor zu lassen, und sich Partner mit guten Schnittstellen zu suchen. FiBu und Lohn sind Bereiche mit denen man wirklich mit einem halben Bein im Knast steht, wenn etwas passiert. Da stößt selbst die Betriebshaftpflicht an ihre Grenzen, ausser man bezahlt ein kleines Vermögen dafür :roll:

[Perlsau]

Zitat:

Zitat von musicman56 (Beitrag 1225093)

FiBu und Lohn sind Bereiche mit denen man wirklich mit einem halben Bein im Knast steht, wenn etwas passiert. Da stößt selbst die Betriebshaftpflicht an ihre Grenzen, ausser man bezahlt ein kleines Vermögen dafür :roll:

Oben hatte das bereits schon einmal jemand geschrieben. Ich hab mich jetzt dumm und dämlich gesucht, konnte bislang aber keinen Fall finden, wo ein Programmierer wegen fehlerhafter Software zu einer Freiheitsstrafe verurteilt wurde. Natürlich wandern auch Programmierer mal ins Gefängnis, wenn sie sich illegal betätigen. Könntet ihr vielleicht mal einen Fall benennen, wo ein Entwickler von FiBu oder Lohnbuchhaltung verurteilt wurde, weil seine Software fehlerhaft war? Oder vielleicht auch, auf welchen Paragraphen diese Einschätzung beruht?

[mjustin]

Zitat:

Zitat von Perlsau (Beitrag 1225098)

Zitat:

Zitat von musicman56 (Beitrag 1225093)

FiBu und Lohn sind Bereiche mit denen man wirklich mit einem halben Bein im Knast steht, wenn etwas passiert. Da stößt selbst die Betriebshaftpflicht an ihre Grenzen, ausser man bezahlt ein kleines Vermögen dafür :roll:

Oben hatte das bereits schon einmal jemand geschrieben. Ich hab mich jetzt dumm und dämlich gesucht, konnte bislang aber keinen Fall finden, wo ein Programmierer wegen fehlerhafter Software zu einer Freiheitsstrafe verurteilt wurde. Natürlich wandern auch Programmierer mal ins Gefängnis, wenn sie sich illegal betätigen. Könntet ihr vielleicht mal einen Fall benennen, wo ein Entwickler von FiBu oder Lohnbuchhaltung verurteilt wurde, weil seine Software fehlerhaft war? Oder vielleicht auch, auf welchen Paragraphen diese Einschätzung beruht?

Es ist bei "fehlerhafter Software" denkbar, dass sie auf Wunsch fehlerhaft ist (Beispiel: "Schwarze Kasse"): Falls ein Entwickler mit der Software zu Steuerhinterziehung Beihilfe leistet, ist er in Deutschland laut Gesetz von Haftstrafe bedroht, wenn der hinterzogene Betrag bestimmte Grenzen überschreitet.

http://de.wikipedia.org/wiki/Steuerh...Strafandrohung

http://www.gevestor.de/details/beihi...en-653722.html

"Selbst wer die Haupttat missbilligt, aber ihre Ausführung erleichtert, leistet Beihilfe zur Steuerhinterziehung."

[arnof]

Zitat:

Zitat von hstreicher (Beitrag 1225077)

ich ergaenze mal die vorherige Aussage,

eine Fibu _muss_ einen Rückkanal zur Wawi/ERP haben um zu verhindern dass Kunden die nicht zahlen weiter beliefert werden,
ob das jetzt Elektronisch oder als Liste per Sneakernet erfolgt ist wohl Betriebsgrößen abhaengig

Es soll sogar WAWIS (ERP 's geben), die eine eigene OP Verwaltung haben, damit man das machen kann. Viele kleine Firmen bis zu mittleren (was mittel ist, da kann man ja wieder 100 Posts machen) lagern die Buchhaltung aus zum Steuerbüro. Der Rückkanal ist da meistens verwehrt, da nicht gerade Leuchten der EDV dort tätig sind :wink:

Das ist meine Erfahrung in nun ca 25 Jahren auf diesem Gebiet und bei über 50.000 Kunden in diesem Bereich!

[musicman56]

Hallo,

eine schöne Formulierung: Software die auf Wunsch fehlerhaft ist. Werde ich mir merken! :thumb:

Die Formulierung "ins Gefängnis" oder "Knast" ist zumindest bei meinem Beitrag nicht wörtlich gemeint. Es kommt im Einzelfall vermutlich auf Schadenhöhe, Vorsatz, Fahrlässigkeit usw. an. Was aber eindeutig sein dürfte ist die Haftungspflicht. Der Softwarehersteller kann bei Programmfehlern haftbar gemacht werden. Oder im Einzelfall sogar der Kundenbetreuer/Händler der den Schaden verursacht hat. Das kann im Einzelfall ein ziemlich komplexes Unterfangen werden.

Ein Beispiel:

Ich habe für meine Software ein eigenes Installationsprogramm programmiert. Ein Händler meiner Software installiert früh morgens bei seinem Kunden meine Software. In der Installationsanleitung steht "vorher eine Datensicherung durchführen". Der Händler fragt den Kunden "Wann wurde zuletzt gesichert" und der Kunde bestätigt "heute Nacht automatisch gesichert". Nach der Installation sind Daten weg (irgend ein Problem mit der Festplatte). Dann das problem: Die Datensicherung ist nicht lesbar. Es stellt sich heraus, dass das Bandlaufwerk schon einige Wochen lang nicht mehr richtig funktioniert, und keiner (Anwender) hat das Fehlerprotokoll gelesen.

Mein Händler musste dem Kunden damals 18.000 Euro Schadenersatz bezahlen. Begründung des Richters: der Händler hätte die ordnungsgemäße Durchführung der Datensicherung kontrollieren müssen. Die Haftpflicht hat nicht bezahlt, weil der Richter die Vorgehensweise als grob fahrlässig eingestuft hat. Ich hatte kein Problem mit der Angelegenheit weil in der Installationsanleitung der Hinweis auf die Datensicherung enthalten war.

Hier ging es "nur" um 18.000 Euronen, aber wenn die Schandenhöhe sechsstellig und höher wird, dann ist die Zelle durchaus im Bereich der Möglichkeiten :cyclops:

[arnof]

Zitat:

Zitat von musicman56 (Beitrag 1225105)

Hallo,

Ein Beispiel:

Ich habe für meine Software ein eigenes Installationsprogramm programmiert. Ein Händler meiner Software installiert früh morgens bei seinem Kunden meine Software. In der Installationsanleitung steht "vorher eine Datensicherung durchführen". Der Händler fragt den Kunden "Wann wurde zuletzt gesichert" und der Kunde bestätigt "heute Nacht automatisch gesichert". Nach der Installation sind Daten weg (irgend ein Problem mit der Festplatte). Dann das problem: Die Datensicherung ist nicht lesbar. Es stellt sich heraus, dass das Bandlaufwerk schon einige Wochen lang nicht mehr richtig funktioniert, und keiner (Anwender) hat das Fehlerprotokoll gelesen.

Mein Händler musste dem Kunden damals 18.000 Euro Schadenersatz bezahlen. Begründung des Richters: der Händler hätte die ordnungsgemäße Durchführung der Datensicherung kontrollieren müssen. Die Haftpflicht hat nicht bezahlt, weil der Richter die Vorgehensweise als grob fahrlässig eingestuft hat. Ich hatte kein Problem mit der Angelegenheit weil in der Installationsanleitung der Hinweis auf die Datensicherung enthalten war.

Ja so ist das vor Gericht, aber da muss man halt auch Kämpfen!

Wenn die DASI schon länger nicht geht ist das Sorgfaltspflicht des Kunden, wenn der Händler Ihn auch sonst EDV mäßig Betreut (z.B. einen Wartungsvertrag hat), so kann man das Urteil nachvollziehen, ansonsten hat er einen schlechten Anwalt gehabt.

Bei 18.000 ist man beim Landgericht und nicht beim Dorfrichter.

Ja einer der bei mir Fachinformatiker gelernt hat, Studiert nun Jura, der fand das bei uns so interessant.

Zitat:

Hier ging es "nur" um 18.000 Euronen, aber wenn die Schandenhöhe sechsstellig und höher wird, dann ist die Zelle durchaus im Bereich der Möglichkeiten :cyclops:

Ins Gefängnis kommste da nicht, man darf nur nichts haben bzw. alles vor der Rechtskraft des Urteils auf jemanden anderen Überschrieben haben. Wenn man in D kein Geld hat, dann passiert einem auch nichts, da kann ste machen was Du willst (hier geht es um Zivilrecht), da kann dich einer verklagen solange er lustig ist: keine Chance! Ich habe auch so einen Fall, hier ist meine Firma der klagende: mehrfach verurteil, der lacht mich nur aus und macht weiter .....

[hstreicher]

naja ganz so einfach ist das Überschreiben auch nicht mehr , da gibt es im Insolvenzrecht den Paragraph 133ff Anfechtung mit der die Überschreibung
bis zu 10 Jahre vor Eröffnung des Insolvenzverfahren rückabgewickelt werden kann (und der Beweis ist ganz lächerlich einfach ,
es reicht die Vermutung des Insolvenzverwalters dass der Begünstigte Kenntnis vom Vorsatz der Gläubigerbenachteiligung hatte)

[arnof]

Wenn er keine Privatinsolvenz anmeldet zieht das nicht ....

[Hansa]

Zitat:

Zitat von mkinzler (Beitrag 1225080)

Es ging um die Notwendigkeit des Datenaustausches und Hansas Ansicht, das ein WaWi (Aus seiner Sicht) keine Daten der Fibu benötigt.

Das ist einerseits Definitionssache und zweitens die Frage, wo und von wem solche Sachen wie Kreditlimit abgehandelt werden, sofern das überhaupt vom Programm gewünscht wird (es gibt Leute die wissen genau, wer ihre "Pappenheimer" sind 8-)). Um zu verhindern, dass einer der nicht bezahlt immer weiter beliefert wird braucht man nur die im Wawi vorliegenden offenen Rechnungen zusammenzuzählen und mit dem (üblicherweise im Kundenstamm hinterlegten) Kreditlimit zu vergleichen. Man braucht jedenfalls keine Vorsteuer, Abschreibung, Lohnkosten, BWA etc., was entweder die Fibu oder der Steuerberater liefert. Ausserdem gibt es für beide Bereiche natürlich eine Schnittmenge, aber ich habe noch nie gesehen, dass ich bei vorhandenem Wawi eine Fibu brauche, um Rechnungen schreiben zu können. Es kann durchaus sein, dass die Fibu ihre Daten (z.B. Kunden) aus dem Wawi erhält. aber wohl kaum umgekehrt.

[musicman56]

Hallo,

ganz so einfach kannst du es dir nicht machen. Das Problem ist der Zahlungseingang, der logischerweise nur "ein einziges mal" gebucht werden soll. Der Buchhalter bucht die OP's anhand der Kontoauszüge in der FiBu aus. D.h. die OP's in der WaWi können gar nicht aktuell sein, d.h. die WaWi braucht in diesem Fall die Daten aus der FiBu. Das ist sogar bei meinem kleinen popeligen WaWi für Handwerksbetriebe so. Umso mehr ist das bei Betrieben in der ERP-Größenordnung der Fall.

[arnof]

Zitat:

Zitat von musicman56 (Beitrag 1225136)

Hallo,

ganz so einfach kannst du es dir nicht machen. Das Problem ist der Zahlungseingang, der logischerweise nur "ein einziges mal" gebucht werden soll. Der Buchhalter bucht die OP's anhand der Kontoauszüge in der FiBu aus. D.h. die OP's in der WaWi können gar nicht aktuell sein, d.h. die WaWi braucht in diesem Fall die Daten aus der FiBu. Das ist sogar bei meinem kleinen popeligen WaWi für Handwerksbetriebe so. Umso mehr ist das bei Betrieben in der ERP-Größenordnung der Fall.

Es gibt sogar WAWI's mit eigenen Banking und Op Verwaltung die sogar diese Buchungen an den Steuerberater weitergeben können. Incl. Kassenbuch, das man ja auch führen muss :thumb:

[jaevencooler]

Moin,


ganz schön selbst gerecht wie Du Dich hier darstellst.

Wie gut das mich Deine Meinung nicht die Bohne interessiert.

Beste Grüße
Michael

Zitat:

Zitat von Perlsau (Beitrag 1224966)

Zitat:

Zitat von jaevencooler (Beitrag 1224919)

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.

Das kann man hinterher immer behaupten. Soweit ich deinen Werbetext in Erinnerung habe, waren da ganz gezielte Hinweise auf dein/euer kommerzielles Produkt zu lesen. Eine Erläuterung der Möglichkeiten von ERP-Systemen benötigt nicht zwingend einen werbenden Hinweis auf ein bestimmtes Erzeugnis. Ich zumindest glaube deine Beteuerung eher nicht.

Zitat:

Zitat von jaevencooler (Beitrag 1224919)

Für die Werbung unserer Produkte nutze ich definitiv andere Plattformen, das Forum ist ganz sicher der falsche Platz dafür.

Das interessiert hier doch überhaupt nicht, wo deine Firma Werbung betreibt und wo nicht.

Zitat:

Zitat von jaevencooler (Beitrag 1224919)

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-)

Das ist – mit Verlaub – vollständiger Bullshit, denn in den Nutzerprofilen ist es bislang nicht verboten, einen Hinweis auf vom Benutzer betriebene Internetseiten zu geben. Beim Verbot von Werbung in den Foren geht es, soweit ich das interpretiere, vorwiegend darum, das Forum weiterhin les- und benutzbar zu halten. Außer deinem Werbetext hattest du zum Thema nichts beizutragen, und das stört ganz sicher nicht nur mich.

Zitat:

Zitat von jaevencooler (Beitrag 1224919)

Nein im Ernst, das ist natürlich Quatsch, aber Deine Reaktion IMHO auch leicht überzogen....

Das darfst du dir zusammendenken, wie es dir paßt. Ich halte meine Reaktion nicht für überzogen, und falls du den Moderator meinst, der deinen Werbe-Beitrag aus gutem Grund entfernt hat, dann solltest du dich vielleicht besser gleich wieder abmelden ...

[Daniel]

Den Rest des Disputs tragt Ihr bitte unter Euch aus.
:roll:

[QuickAndDirty]

Zitat:

Zitat von IBExpert (Beitrag 1224262)

Das Problem an der Vorgehensweise nach Lehrbuch ist das du dafür auf der Gegenseite Leute brauchst, die dir als Ansprechpartner

1. fachkompetent mit dem Prozesswissen zur Seite stehen
2. auch Lust haben an dem Projekt mitzuarbeiten
3. auch die Zeit von der Geschäftsleitung bekommen, das neben Ihres üblichen Aufgaben zu leisten

Ja ich weiß ...habe das Lehrbuch gelesen ;). Alle Stakeholder müssen an einem Tisch sitzen, dann weiß jeder wer auf welche weise überstimmt wurde...danach ist es eine Sache des Change Management immer vorhandene Bremser zu beseitigen.

Gibt es eine BPEL Unterstützung für Delphi?