AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Delphi-PRAXiS - Lounge Klatsch und Tratsch in DELPHI wäre dies wohl nicht passiert

in DELPHI wäre dies wohl nicht passiert

Ein Thema von bernhard_LA · begonnen am 17. Jul 2018 · letzter Beitrag vom 18. Jul 2018
Antwort Antwort
Seite 2 von 3     12 3   
TigerLilly

Registriert seit: 24. Mai 2017
Ort: Wien, Österreich
416 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#11

AW: in DELPHI wäre dies wohl nicht passiert

  Alt 18. Jul 2018, 07:52
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.
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
2.311 Beiträge
 
Delphi 2010 Enterprise
 
#12

AW: in DELPHI wäre dies wohl nicht passiert

  Alt 18. Jul 2018, 08:15
"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.
Gruß, Jo

Geändert von jobo (18. Jul 2018 um 08:51 Uhr)
  Mit Zitat antworten Zitat
Jumpy

Registriert seit: 9. Dez 2010
Ort: Mönchengladbach
1.503 Beiträge
 
Delphi 6 Enterprise
 
#13

AW: in DELPHI wäre dies wohl nicht passiert

  Alt 18. Jul 2018, 08:18
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.
Ralph
  Mit Zitat antworten Zitat
Benutzerbild von Sherlock
Sherlock
Online

Registriert seit: 10. Jan 2006
Ort: Offenbach
3.132 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#14

AW: in DELPHI wäre dies wohl nicht passiert

  Alt 18. Jul 2018, 08:22
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
Geändert von Sherlock (Morgen um 16:78 Uhr) Grund: Weil ich es kann
  Mit Zitat antworten Zitat
Benutzerbild von JasonDX
JasonDX
(CodeLib-Manager)

Registriert seit: 5. Aug 2004
Ort: München
1.052 Beiträge
 
#15

AW: in DELPHI wäre dies wohl nicht passiert

  Alt 18. Jul 2018, 08:31
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.
Mike
Passion is no replacement for reason
  Mit Zitat antworten Zitat
Benutzerbild von Sherlock
Sherlock
Online

Registriert seit: 10. Jan 2006
Ort: Offenbach
3.132 Beiträge
 
Delphi 10.2 Tokyo Enterprise
 
#16

AW: in DELPHI wäre dies wohl nicht passiert

  Alt 18. Jul 2018, 08:39
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
Geändert von Sherlock (Morgen um 16:78 Uhr) Grund: Weil ich es kann
  Mit Zitat antworten Zitat
Lemmy

Registriert seit: 8. Jun 2002
Ort: Berglen
2.130 Beiträge
 
Delphi 7 Professional
 
#17

AW: in DELPHI wäre dies wohl nicht passiert

  Alt 18. Jul 2018, 08:40
[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.

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
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
2.311 Beiträge
 
Delphi 2010 Enterprise
 
#18

AW: in DELPHI wäre dies wohl nicht passiert

  Alt 18. Jul 2018, 08:55
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.
Gruß, Jo
  Mit Zitat antworten Zitat
Benutzerbild von JasonDX
JasonDX
(CodeLib-Manager)

Registriert seit: 5. Aug 2004
Ort: München
1.052 Beiträge
 
#19

AW: in DELPHI wäre dies wohl nicht passiert

  Alt 18. Jul 2018, 08:57
[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.
Mike
Passion is no replacement for reason
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
2.311 Beiträge
 
Delphi 2010 Enterprise
 
#20

AW: in DELPHI wäre dies wohl nicht passiert

  Alt 18. Jul 2018, 08:57
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.
Gruß, Jo
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 15:21 Uhr.
Powered by vBulletin® Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2018 by Daniel R. Wolf