in DELPHI wäre dies wohl nicht passiert

[bernhard_LA]

......

https://www.br.de/nachrichten/lidl-s...-sand-100.html


:wink:

[Schokohase]

Was wäre in DELPHI nicht passiert?

Die hohen Kosten, die Zeitspanne bis zum Exit, oder ...

Das du Birnen mit Äpfeln vergleichst ist dir hoffentlich bewusst?

[jobo]

Ich schätze, man kann jedes System so einsetzen, dass es nicht praktikabel ist. Manche Systeme eignen sich vielleicht auch grundsätzlich nicht für bestimmte Aufgaben. "Skaliert nicht" sagt man ja gerne, allerdings ist es in der Praxis wohl so, dass zum Skalieren der Leistung auch die Frage der Kostenskalierung gehört und in welchem Verhältnis die stehen bzw. welche Steigung die Kurven jeweils haben, ganz unabhängig von einer vielleicht vermurxten Entwicklung.
Bin mir nicht sicher, aber das alte System war vielleicht vom Datenbank "Erzfeind". Über das Frontend weiß ich gar nichts.

[generic]

Nicht das erste mal, das ich es höre das eine SAP Einführung schwierig ist/war.

Aber es trift viele Unternehmen, welche ihre stark vernetze eigene Software durch Standardlösungen ersetzen wollen. Meist sind viele Jahre in die Entwicklung geflossen. Diese holt man nicht mal eben mit einer neuer "fertigen" Software auf, welche die alten Abläufe genau so können muss. Meist sind dann genau so lange Anpassungen an die neue Software notwendig. Alternative könnte man sich von den alten Prozessen trennen, aber das macht niemand so gerne.

Beispiele aus meiner Welt:
Ersetzung eine Versicherungsbestandsführung durch eine Standard-Software:
Geplant 1 Jahr - tatsächliche Dauer >3 Jahre

Ersetzung eines DMS durch eine Standard-Software:
Geplant 6 Monate - tatsächliche Dauer >1,5 Jahre

Beide Projekte laufen noch.
Die Bestandsführung ist jetzt sein 1 Jahr live, aber die Nachbearbeitung hält an. Software-Bugs, Anpassungen und Migrationsfehler.

Das DMS ist teilweise eingeführt für eine Abteilung. Die nächsten zwei Abteilungen kommen "zeitnah".

Über die Mehrkosten brauchen wir uns natürlich nicht unterhalten.

[jobo]

also von Delphi (Deine Welt) nach "Standardsoft" (ohne Delphi)?

Im Prinzip sehe ich es auch so, aber bei einem Discounter, Warenwirtschaft, Standardsoftware denke ich nicht primär an Umstellungsprobleme und Speziallösung.
Ich meine was könnte man sich bei einer Standardwarenwirtschaft als standardisierter vorstellen als einen Discounter?

Lidl ist m.E. vor allem einfach groß.

[Neutral General]

Ich mag ja Delphi auch, aber die Aussage ist einfach Unsinn...
Du glaubst also wenn SAP mit Delphi geschrieben wäre, hätte es keine Probleme gegeben oder was? :roll:

[Headbucket]

Zitat:

Zitat von generic (Beitrag 1407544)

Aber es trift viele Unternehmen, welche ihre stark vernetze eigene Software durch Standardlösungen ersetzen wollen. Meist sind viele Jahre in die Entwicklung geflossen. Diese holt man nicht mal eben mit einer neuer "fertigen" Software auf, welche die alten Abläufe genau so können muss. Meist sind dann genau so lange Anpassungen an die neue Software notwendig. Alternative könnte man sich von den alten Prozessen trennen, aber das macht niemand so gerne.

Das beschreibt es ziemlich gut.

Wir sind übrigens gerade (seit Anfang des Jahres!) dabei unser altes ERP-System durch ein neues zu ersetzen, welches in Delphi geschrieben wurde!
Und bisher ist die Stimmung im Unternehmen eher negativ... .

Es liegt aber vorwiegend auch einfach daran, dass unser bisheriges ERP-System extrem vernetzt war und viel Entwicklung reingeflossen ist.

Grüße

[Der schöne Günther]

Danke für den Artikel.

Wie der in die Rubrik "Sonstige Fragen zu Delphi" gehört habe ich zwar auch noch nicht verstanden, aber das klärt sich sicher auf.

[DP-Maintenance]

Dieses Thema wurde am "17. Jul 2018, 17:24 Uhr" von "mkinzler" aus dem Forum "Sonstige Fragen zu Delphi" in das Forum "Klatsch und Tratsch" verschoben.

[Bernhard Geyer]

Zitat:

Zitat von Headbucket (Beitrag 1407554)

Wir sind übrigens gerade (seit Anfang des Jahres!) dabei unser altes ERP-System durch ein neues zu ersetzen, welches in Delphi geschrieben wurde!
Und bisher ist die Stimmung im Unternehmen eher negativ...

Ich hoffe nicht zu dem das wir einsetzen und das vom Hersteller eigentlich abgekündigt wurde da er nur noch Cloud macht ...

[TigerLilly]

SAP ist toll, wenn Abläufe einheitlich und standardisiert sind. Und wenn die Abläufe möglichst nahe am Datenmodell abzubilden sind. Sobald aufwändige Berechnungsmodelle oder Algorithmen ins Spiel kommen, klappt das mit SAP nicht mehr so gut.

Auch wenn es in den Berichten so aussehen mag, als ob SAP die Ursache gewesen sein soll, bin ich sehr sicher, dass die Wahrheit woanders liegt. SAP hätte nach Analyse klar sagen müssen: die und die Abläufe müsst Ihr ersatzlos streichen, die harmonisieren und hier müsst Ihr es ganz anders machen. Aber dann hätten sie den Auftrag nicht bekommen. LIDL hätte bereit sein müssen historisch gewachsenes radikal (mit 100 !) und unvoreingenommen (mit 1000 !) zu durchforsten. Aber dann wäre das weniger ein Softwareprojekt als ein Restrukturierungsprojekt geworden.

[jobo]

"Restrukturierungsprojekt"
Das bleibt ja nicht aus, wenn man eine Standardsoftware einsetzt und nicht alles nachprogrammiert.
Bei SAP ist es nicht das erste mal, dass man sowas hört und diese Geschichte hier ist nicht die schrägste. Keine Ahnung was davon Legende und Wahrheit ist. Ehrlich gesagt, ich weiß nicht, wann bei derartigen Projekten SAP selbst involviert ist. Meist sind es ja normale Unternehmen.
Aber SAP hat natürlich Interesse an diesen "Success Stories". Und je toller und größer der Kunde, desto größer ist das Interesse.
Auch wenn es mir fern liegt, SAP in Schutz zu nehmen. Jede Softwareeinführung steht vor dem Problem, dass die Anwender gewohntes loslassen müssen und bei Analyse und Umsetzungen Fehler gemacht werden können. Dazu kommen Machtkämpfchen innerhalb von Abteilungen, niemand will hoheitliche Aufgaben verlieren, alle wollen nahtlos weiterarbeiten und meist vorneweg sucht die IT, möglichst wenig Verantwortung zu übernehmen und gibt den besten Bremser.

[Jumpy]

Wir betreuen eine Standard-Software im HR-Bereich und z.B. am Thema Personalkostenplanung / Personalkostencontrolling / Rückstellungen gibt es bei unseren ca. 100 Kunden keine 2 die da die selbe Systematik anwenden. Ohne großes Rumgegurke können vielleicht 20% der Kunden die Module der Software für diese Thematik "out of the box" anwenden, 30% können die Module mit großem Rumgegurke (meist unsererseits) anwenden und mit den Zusatzlösungen für die anderen 50% verdiene ich u.a. meine Brötchen. Aber kaum ein Kunde sieht ein, seine Prozesse zu verändern (und dabei wahrscheinlich zu optimieren), um sie in der Standard-Software abbildbar zu machen.

Das schmerzhaft lustige ist, dass die Vertriebler immer schön die Software anpreisen: "Ja klar können wir Personalkostenplanung, gibt es ein Modul für..." aber keiner sich anguckt, was denn der Kunde unter PKP versteht. Das kommt dann immer nachher. Umgekehrt kann sich der Kunde dann auch nicht vorstellen, dass man PKP auch anders machen könnte, als bei ihm: "Das ist doch die normale Art und Weise wie man PKP macht, was wir da machen. Machen doch alle so!"

Was ich sagen will: Ist nicht nur bei SAP so, SAP ist halt der prominenteste Vertreter der Standard-Software.

[Sherlock]

Hintergrundinfos:
https://www.heise.de/newsticker/meld...g-4113285.html

Ich weiß nicht, was jemanden dazu bewegt, ein funktionierendes System zu ändern, ohne das System ändern zu wollen. Dazu muss man vermutlich BWL studiert haben.

Sherlock

[JasonDX]

Zitat:

Zitat von Sherlock (Beitrag 1407615)

Hintergrundinfos:
https://www.heise.de/newsticker/meld...g-4113285.html

Ich weiß nicht, was jemanden dazu bewegt, ein funktionierendes System zu ändern, ohne das System ändern zu wollen. Dazu muss man vermutlich BWL studiert haben.

Sherlock

Steht ja nirgendwo, dass nix im System geändert worden wäre. Bestimmte Aspekte sollten sich aber nicht verändern, was auch verständlich ist und Sinn macht. Dafür muss man nix studiert haben ;)

[Edit]
Das Kernproblem aus dem verlinkten Artikel zusammengefasst:

Zitat:

Dabei sollte die Software aber nicht von etablierten Praktiken abweichen, etwa dem Lidl-Konzept, Warenbestände anhand von Verkaufspreisen zu bewerten. SAP Retail kalkuliert von Haus aus nur mit Einkaufspreisen, musste für Lidls Bedürfnisse also mit viel Aufwand umgestrickt werden.

[Sherlock]

Eine nützliche Information fehlt leider immer noch: Warum hat man dieses Projekt in Angriff genommen? Stieß man auf Grenzen des gegenwärtigen Systems? Warum wollte man nicht die eigenen Entwickler damit beauftragen, die immerhin wissen, was vom System erwartet wird, und zwar zu 100%?
500 Millionen in die eigene Entwicklungsabteilung gesteckt, und schon hätte man ein hervorragendes System, das man eventuell sogar weiterverkaufen könnte. 500 Mio an SAP und ein Heer von externen Beratern sind halt jetzt für Lidl einfach nur eine dicke, fette, tiefrote Zahl.

Sherlock

[Lemmy]

Zitat:

Zitat von JasonDX (Beitrag 1407616)

[Edit]
Das Kernproblem aus dem verlinkten Artikel zusammengefasst:

Zitat:

Dabei sollte die Software aber nicht von etablierten Praktiken abweichen, etwa dem Lidl-Konzept, Warenbestände anhand von Verkaufspreisen zu bewerten. SAP Retail kalkuliert von Haus aus nur mit Einkaufspreisen, musste für Lidls Bedürfnisse also mit viel Aufwand umgestrickt werden.

Da muss ich dem Typ aus dem Heise-FOrum recht geben: Wenn es viel Aufwand ist in einer Formel ein Datenbankfeld durch ein anderes zu tauschen bzw. die Bewertungsformel für ein Reporting zu ändern, dann hat irgend jemand seine Hausaufgaben nicht richtig gemacht.

Zitat:

Zitat von jobo (Beitrag 1407612)

Bei SAP ist es nicht das erste mal, dass man sowas hört und diese Geschichte hier ist nicht die schrägste.

Und sicher ist nicht immer SAP Schuld, denn da gibt es noch ein paar andere Beteiligte: Consultingunternehmen, Programmierer und das Management, die am Ende nicht verstehen / wissen / sich dafür interessieren was eigentlich gebraucht wird

[jobo]

Zitat:

Zitat von Jumpy (Beitrag 1407613)

Was ich sagen will: Ist nicht nur bei SAP so, SAP ist halt der prominenteste Vertreter der Standard-Software.

Genauso ist es. Wobei das allein auch eine Verkürzung der Problematik wäre.

[JasonDX]

Zitat:

Zitat von Lemmy (Beitrag 1407618)

Zitat:

Zitat von JasonDX (Beitrag 1407616)

[Edit]
Das Kernproblem aus dem verlinkten Artikel zusammengefasst:

Zitat:

Dabei sollte die Software aber nicht von etablierten Praktiken abweichen, etwa dem Lidl-Konzept, Warenbestände anhand von Verkaufspreisen zu bewerten. SAP Retail kalkuliert von Haus aus nur mit Einkaufspreisen, musste für Lidls Bedürfnisse also mit viel Aufwand umgestrickt werden.

Da muss ich dem Typ aus dem Heise-FOrum recht geben: Wenn es viel Aufwand ist in einer Formel ein Datenbankfeld durch ein anderes zu tauschen bzw. die Bewertungsformel für ein Reporting zu ändern, dann hat irgend jemand seine Hausaufgaben nicht richtig gemacht.

Ich hab wenig Erfahrung mit SAP, von daher kann ich nicht sagen ob du recht hast oder nicht, aber immer (nicht nur in diesem Fall) wenn ein Außenstehender ankommt mit "Das ginge so doch viel einfacher" und "da hat jemand eine dumme Entscheidung getroffen", denke ich an die Fälle wo ein Außenstehender zu mir kommt und versucht zu erklären, wie man das ganze doch viel einfacher machen könnte, und warum eine Entscheidung falsch war, obwohl er nicht weiß, welche Parameter zu berücksichtigen waren. Und auch hier denke ich mir "ein Datenbankfeld mit dem anderen austauschen" - aber welche Berechnungen genau sind damit verbunden? Welche anderen Parameter fließen in diese Bewertung rein? Wenn ich Verkaufs- statt Einkaufspreis als Bewertungsfaktor verwende, muss ich dann auch steuerliche Parameter in die Bewertung mit einbeziehen?

Es ist einfach zu sagen "da hat jemand verkackt", und oft stimmt das auch. Aber wenn mir jemand nicht erklären kann wie eine Entscheidung zustandegekommen ist, halte ich diese Person auch nicht qualifiziert zu sagen, dass diese Entscheidung zu dem Zeitpunkt falsch war.

[jobo]

Zitat:

Zitat von Lemmy (Beitrag 1407618)

hat irgend jemand seine Hausaufgaben nicht richtig gemacht.
..

Und sicher ist nicht immer SAP Schuld, denn da gibt es noch ein paar andere Beteiligte: Consultingunternehmen, Programmierer und das Management, die am Ende nicht verstehen / wissen / sich dafür interessieren was eigentlich gebraucht wird

Das wären eben Themen, jenseits der Thematik "diese Probleme haben alle"
Aber das führt in eine mehr oder weniger tiefe Diskussion über Architekturkonzepte usw.

[jobo]

Zitat:

Zitat von JasonDX (Beitrag 1407624)

.."ein Datenbankfeld mit dem anderen austauschen"

In Kundenanforderungen erlebe ich teilweise, dass diese Ideen oft gar nicht so schlecht sind.
Der Kunde weiß, je komplizierter meine Änderung, desto teurer wird es und hat ein ureigenes Interesse an einfachen Lösungen. Dabei hat er mindestens seine offensichtlichen oder ihm bekannten Prozesse im Blick.

Ob die einfache Idee dann umsetzbar ist und welche Randeffekte dabei berücksichtigt werden müssen, ist dann mein Job. Dabei kann es viele oder wenig Schwierigkeiten geben und ich kann entweder von guten Anwendungskonzepten profitieren oder mich immer tiefer in Sonderfallbehandlung verstricken. Hier merkt man sofort, wo wie gut oder schlecht modularisiert wurde, wo definierte Interfaces bestehen und je nach Architektur bekommt man vom System viele Folgeeffekte und Abhängigkeiten schon auf Anfrage serviert.

[TigerLilly]

SAP ist eine parametrisierbare Standardanwendung, also sollte da vorerst mal nix mit programmieren, Modularisierung etc sein. Diese Architekturprobleme gehören SAP allein + die müssen sehen, wie sie es auf die Reihe bekommen. Und das tun sie gut!

Das Problem bei SAP/LIDL ist ja kein software-architektonisches, sondern ein strategisch/organisatorisches. Wenn da wer den schwarzen Peter haben sollte, dann der/die Projektverantwortliche auf LIDL-Seite.

[mkinzler]

https://www.stimme.de/heilbronn/wirt...140955,4054349

[Uwe Raabe]

Zitat:

Zitat von mkinzler (Beitrag 1407644)

https://www.stimme.de/heilbronn/wirt...140955,4054349

Zitat:

das die internen Abläufe des Unternehmens grundlegend verändern sollte.

Offenbar ja gerade das wohl nicht.

[Lemmy]

Zitat:

Zitat von JasonDX (Beitrag 1407624)

Es ist einfach zu sagen "da hat jemand verkackt", und oft stimmt das auch. Aber wenn mir jemand nicht erklären kann wie eine Entscheidung zustandegekommen ist, halte ich diese Person auch nicht qualifiziert zu sagen, dass diese Entscheidung zu dem Zeitpunkt falsch war.

da geb ich Dir völlig recht, nach dem Post habe ich mehrfach überlegt, warum das an so was scheinbar einfachem scheitern sollte. Vielleicht ist es am Ende halt auch nur die halbe Wahrheit was in den Berichten steht....

[jobo]

Zitat:

Zitat von Uwe Raabe (Beitrag 1407645)

Zitat:

Zitat von mkinzler (Beitrag 1407644)

https://www.stimme.de/heilbronn/wirt...140955,4054349

Zitat:

das die internen Abläufe des Unternehmens grundlegend verändern sollte.

Offenbar ja gerade das wohl nicht.

Jein?
Es sollte ein online system mit Echtzeit DV werden, was es dann vorher -Gupta-wohl nicht war.
Das neue, originale SAP System (Hana-in Memory- basiert) hatte aber wohl eine andere Kalkulationsbasis (Warenbestand), als Lidl sie -nachwievor- einsetzen wollte. Hieran wurde also zumindest heftig gestrickt.

Zitat:

Zitat von TigerLilly (Beitrag 1407629)

Das Problem bei SAP/LIDL ist ja kein software-architektonisches, ..

Ich denke schon, gewisse Architekturen verbieten eben gewisse Vorgehensweisen. Letztlich können wir von hier aus diese Dinge kaum beurteilen.

In den verlinkten Artikeln ist jeweiles von "..vertretbarem Aufwand.." als KO Kriterium die Rede. Das kann die reinen Entwicklungskosten betreffen oder auch die Betriebskosten, also Hardware, Bandbreite, Lizenzen, Wartung, ..
Ich denke, da liegt der Haase im Pfeffer, es funktioniert (siehe Aldi Nord), ist aber im gewünschten Betriebszustand (Online DV) ungleich teurer, als kalkuliert.

[mkinzler]

Wobei ALDI vielleicht auch andere Anforderungen an das System stellt.

[himitsu]

Zitat:

jetzt ist Elwis tot.

Ich dachte der lebt noch?

Aber bei dem Namen hätte man sich das doch denken können. :stupid:

[mkinzler]

Code:

finger elwis