klausk Februar 10, 2013 Kalifornien feuert SAP Der Bundesstaat Kalifornien, vertreten durch den State Controller John Chiang, hat der SAP AG den Auftrag entzogen, die Personalbuchhaltung des Staates zu überarbeiten. Laut AP ist die Fehlerrate des SAP-Systems "unglaublich". Die 1300 Staatsangestellten, die das neue System testeten, wurden angewiesen, sofort wieder auf das alte System zurück zu gehen. Obendrein will der Staat auch die $50 Mio zurückfordern, die er bereits an SAP gezahlt hatte. Diesen Beitrag teilen Link zum Beitrag
Karl Napf März 8, 2013 Ein paar Bildchen: Diese Erkenntnis macht das Berechnen eines historischen Durchschnitts-KGVs mehr oder weniger zur Farce. Mit der Krise 2008/2009 hat allerdings anscheinend eine Neubewertung auf niedrigerer Basis eingesetzt, sodass ich die KGVs von 2009-2013 für eine Durchschnittsbildung heranzuziehen wage (bei IBM schon 2006-2013): Oracle wächst dauerhaft am stärksten; SAP und IBM sind auf Augenhöhe, aber IBM von diesen beiden eben niedriger bewertet. Die Gewinn-Entwickung noch mal separat als Bild: SAP kann nur dann mithalten, wenn es 2013 einen Gewinnsprung von fast 50% hinlegen wird. Eine solche Aufholjagd hatten die Analysten dem Unternehmen seit 2006 schon ein paar Mal unterstellt, und SAP hat es mit Ausnahme von 2011 nie hingekriegt. Diesen Beitrag teilen Link zum Beitrag
35sebastian März 8, 2013 Meine Ansicht ist bestätigt . Danke. Der Oracle Investor Diesen Beitrag teilen Link zum Beitrag
Plutos März 11, 2013 Meine Ansicht ist bestätigt . Danke. Der Oracle Investor Was Oracle sich da an Großakquisitionen alles zusammengekauft hat macht mir Angst. Scheint so als ob die organisches Wachstum überhaupt nicht hinbekommen. Diesen Beitrag teilen Link zum Beitrag
Wutschi März 11, 2013 Kalifornien feuert SAP Der Bundesstaat Kalifornien, vertreten durch den State Controller John Chiang, hat der SAP AG den Auftrag entzogen, die Personalbuchhaltung des Staates zu überarbeiten. Laut AP ist die Fehlerrate des SAP-Systems "unglaublich". Die 1300 Staatsangestellten, die das neue System testeten, wurden angewiesen, sofort wieder auf das alte System zurück zu gehen. Obendrein will der Staat auch die $50 Mio zurückfordern, die er bereits an SAP gezahlt hatte. Ich habe die Diskussion hierzu im Internet verfolgt. Damit ein Projekt scheitert braucht es mehr als nur den Hersteller und den Implementierungspartner. In einem Forum auf LinkedIn haben Leute direkt aus dem Projekt berichtet. Es ist wohl so, dass der Staat mehr oder weniger unmögliche Anforderungen stellt und das die vom Kunden erstellte Projektorganisation viel zu komplex und kaum handlungsfähig ist. Personen die Entscheidungen treffen sollen haben keine Erfahrung und nicht die erforderlichen Kenntnisse wird berichtet. SAP ist im übrigen die 2. Firma die an der Einführung scheitert. An der HR-Software von SAP selbst kann es ja wohl kaum liegen… Diesen Beitrag teilen Link zum Beitrag
Karl Napf März 11, 2013 In einem Forum auf LinkedIn haben Leute direkt aus dem Projekt berichtet. Es ist wohl so, dass der Staat mehr oder weniger unmögliche Anforderungen stellt und das die vom Kunden erstellte Projektorganisation viel zu komplex und kaum handlungsfähig ist. Personen die Entscheidungen treffen sollen haben keine Erfahrung und nicht die erforderlichen Kenntnisse wird berichtet. Für Softwareprojekte zur Anfertigung einer Speziallösung erstellt man normalerweise vor Beginn der Implementierung ein Pflichtenheft, um genau diese Art von Problemen in den Griff zu bekommen. Dieses Pflichtenheft sichert beide Geschäftspartner gegenseitig ab: Den Auftraggeber gegenüber einer Pfuschlösung, den Auftragnehmer gegenüber endlosen Nachbesserungswünschen seines Kunden. Ist das in diesem Fall nicht geschehen? Diesen Beitrag teilen Link zum Beitrag
Wutschi März 11, 2013 Für Softwareprojekte zur Anfertigung einer Speziallösung erstellt man normalerweise vor Beginn der Implementierung ein Pflichtenheft, um genau diese Art von Problemen in den Griff zu bekommen. Dieses Pflichtenheft sichert beide Geschäftspartner gegenseitig ab: Den Auftraggeber gegenüber einer Pfuschlösung, den Auftragnehmer gegenüber endlosen Nachbesserungswünschen seines Kunden. Ist das in diesem Fall nicht geschehen? Ich arbeite selbst im SAP Umfeld und habe auch schon an Projekten in den USA gearbeitet. Ob in diesem konkreten Fall ein Pflichtenheft erstellt wurde kann ich nicht sagen. Es wird auch nicht daran gelegen haben. In dieser Größenordnung vereinbart man eher Deliverables. Ein Sollkonzept ist dann ein solches Deliverable. Ein Pflichtenheft wie man es von der Auftragsprogrammierung her kennt, kann ab einer gewissen Projektgröße im Vorfeld nicht erstellt werden. Meist kann der Auftraggeber selbst nicht alle Anforderungen detailliert genug benennen, bzw. aus den eigenen Reihen einsammeln. Gerade Amerikaner versuchen Projektverträge nicht zu detailliert zu beschreiben damit man genug Spielraum für Nachverhandlungen hat. Diesen Beitrag teilen Link zum Beitrag
Chartwaves März 11, 2013 Für Softwareprojekte zur Anfertigung einer Speziallösung erstellt man normalerweise vor Beginn der Implementierung ein Pflichtenheft, um genau diese Art von Problemen in den Griff zu bekommen. Dieses Pflichtenheft sichert beide Geschäftspartner gegenseitig ab: Den Auftraggeber gegenüber einer Pfuschlösung, den Auftragnehmer gegenüber endlosen Nachbesserungswünschen seines Kunden. Wenn doch damit nur alle Probleme gelöst wären. Es wären da noch: 1.) Software-Projektleiter, die von dem konkreten Gegenstand, um den es geht, wenig bis gar nichts verstehen (erlebe ich allwöchentlich bei meiner Arbeit). 2.) Outsourcing an ungeeignete Leute: Ja, generell gibt es in Indien Leute die gut programmieren können. Das nützt aber wenig, wenn sie den konkreten Anwendungsfall des Kunden nicht oder nicht gut genug verstehen, weil sie z.B. mit der Branche um die es geht noch nie im Leben etwas zu tun hatten. 3.) Viele Kunden tun sich schwer damit, klar und strukturiert aufzuschreiben was sie denn nun eigentlich genau haben wollen. 4.) Viele Firmen tun sich schwer damit, Projekte klar und strukturiert abzuarbeiten (siehe auch 1.) 5.) Testen? Bitte was? Testen ist uncool. Das verursacht nur Kosten und bringt keinen messbaren Output. Da sparen wir doch zuallererst da, dann sind wir viel kosteneffizienter! Hurra! 6.) Termine sind generell unrealistisch und in 90% der Fälle zu knapp angesetzt. Der Vertrieb ist dazu verdonnert, Projekte reinzuholen, auch wenn man dafür gar nicht genügend fähige Ressourcen zur Verfügung hat. Teilweise wird so kalkuliert, dass man von vornherein weiß dass man die Termine nicht einhalten kann und eine Pönale zahlen muss. Solange man unterm Strich noch Gewinn macht, wird das Projekt aber trotzdem an Land gezogen. 7.) Einarbeitung? Bitte was? Wir holen uns (wegen Punkt 6.) mal eben schnell irgendwelche Leute vom Dienstleister, die kriegen einen Laptop in die Hand gedrückt und dann sollen sie gefälligst sofort loslegen und von Anfang an produktiv arbeiten. Glaub mir, da kann sooooooo viel schiefgehen. Ich spreche aus Erfahrung. Eigentlich mag ich meinen Beruf, aber an manchen Tagen... Diesen Beitrag teilen Link zum Beitrag
Wutschi März 11, 2013 8. Kontinuierliche Änderung des Scopes 9. Politische Entscheidungen/Diskussionen anstelle von Sachlichen 10. Fehlendes Risikomanagement Diesen Beitrag teilen Link zum Beitrag
Karl Napf März 11, 2013 3.) Viele Kunden tun sich schwer damit, klar und strukturiert aufzuschreiben was sie denn nun eigentlich genau haben wollen. Das ist klar, deshalb muss das Pflichtenheft eben vom Softwareproduzenten erstellt und vom Kunden abgesegnet werden. Das darf also kein Grund sein, die gegenseitige Absicherung in die Tonne zu treten und dann genau die hier aufgetretenen Probleme zu verursachen. Und wenn der Kunde "unterwegs" merkt, dass er doch mehr wollte, dann muss das Pflichtenheft ergänzt werden - mit aufgestocktem Budget und verlängerten Termine. Alles andere sind Vorgehensweisen wie beim Berliner Flughafen. Diesen Beitrag teilen Link zum Beitrag
WOVA1 März 11, 2013 · bearbeitet März 11, 2013 von WOVA1 Das ist klar, deshalb muss das Pflichtenheft eben vom Softwareproduzenten erstellt und vom Kunden abgesegnet werden. Das darf also kein Grund sein, die gegenseitige Absicherung in die Tonne zu treten und dann genau die hier aufgetretenen Probleme zu verursachen. Und wenn der Kunde "unterwegs" merkt, dass er doch mehr wollte, dann muss das Pflichtenheft ergänzt werden - mit aufgestocktem Budget und verlängerten Termine. Alles andere sind Vorgehensweisen wie beim Berliner Flughafen. Vorgehensweisen wie beim Berliner Flughafen sind in der Software-Branche nicht unüblich. Ich kenne da auch einige Projekte bei im DAX notierten Unternehmen :- Tatsächlich gibt's den Ausdruck 'Pflichtenheft' in D eher im öffentlichen Bereich - je internationaler Unternehmen aufgestellt sind, desto eher werden es 'Deliverables' oder 'Requirements'. Nur tun sich die Kunden oft damit ziemlich schwer, überhaupt zu entscheiden, was sie denn requirieren - und können öfter mal erst am Ende entscheiden, ob das was geliefert wurde, dazu passt. Einen Unterschied zu Bauprojekten gibt es aber doch - Bauruinen lassen sich besser tarnen Diesen Beitrag teilen Link zum Beitrag
Chartwaves März 14, 2013 Das ist klar, deshalb muss das Pflichtenheft eben vom Softwareproduzenten erstellt und vom Kunden abgesegnet werden. Hast Du jemals Software entwickelt? In einer real existierenden, großen Firma? Wo die linke Hand oft genug nicht weiß, was die rechte macht? Damit kommen wir nämlich zu: 11. Entscheidungen über Software werden oftmals von Leuten getroffen, die nichts von Software verstehen (nicht selten BWLer). Diesen Beitrag teilen Link zum Beitrag
hund555 März 21, 2013 Hi Karl Napf, nochmal auf deinen Vergleich Oracle, IBM, SAP zurückzukommen: SAP ist im moment dabei HANA aufzubauen. Es wird in immer mehr und mehr Modulen auf HANA umgestellt. D.h. Datenbank in SAP System, was zum größten Teil Oracle bei meisten Firmen ist, wird mit SAP System zusammen weniger gekauft, es wird aber umso mehr eigene neue Technologie HANA mehr und mehr verkauft. Ich kann es nicht einschätzten welchen Teil es von Oracle und SAP des Gesammtgewinns ausmachen wird, aber es muss berücksichtigt werden. Diesen Beitrag teilen Link zum Beitrag
Wutschi März 21, 2013 · bearbeitet März 21, 2013 von Wutschi Eine eigene Datenbank gab es schon vor HANA, nennt sich MaxDB. Oracle wird bei rund 2/3 der SAP Kunden eingesetzt. HANA wird in mehreren Schritten und Stufen in den Markt gebracht, derzeit wird HANA zusätzlich zu einer normalen DB installiert und betrieben. Das BI läuft bereits auf HANA und kann wohl auch recht gut migriert werden. Interessant wird HANA erst in der Ausbaustufe, wenn man Echtzeitauswertungen direkt im ERP laufen lassen kann und das BI abschalten kann. SAP lässt sich HANA aber auch fürstlich bezahlen, sodass sich für viele gar kein Umstieg rechnet. SAP hat mit HANA ein super Produkt entwickelt was sehr gute Zukunftsperspektiven hat, das wird aber nicht von heute auf morgen passieren. Diesen Beitrag teilen Link zum Beitrag
Optimist März 21, 2013 Eine eigene Datenbank gab es schon vor HANA, nennt sich MaxDB. Oracle wird bei rund 2/3 der SAP Kunden eingesetzt. HANA wird in mehreren Schritten und Stufen in den Markt gebracht, derzeit wird HANA zusätzlich zu einer normalen DB installiert und betrieben. Das BI läuft bereits auf HANA und kann wohl auch recht gut migriert werden. Interessant wird HANA erst in der Ausbaustufe, wenn man Echtzeitauswertungen direkt im ERP laufen lassen kann und das BI abschalten kann. SAP lässt sich HANA aber auch fürstlich bezahlen, sodass sich für viele gar kein Umstieg rechnet. SAP hat mit HANA ein super Produkt entwickelt was sehr gute Zukunftsperspektiven hat, das wird aber nicht von heute auf morgen passieren. SAP und Hana, Ziel von SAP ist die ERP und Business Suite (CRM u. SRM usw..) auf Hana zum "laufen" zu bringen, die Nachfrage steigert sich von Monat zu Monat. Das Thema Real Data Plattform (Hana und Sybase DB) ist dann eine Gesamtlösung für alle SAP Lösungen. Sybase deckt mobile Lösungen ab sowie Hana und oder IQ von Sybase -alles aus einer Hand ! Trotzdem wird das Geschäft Hana weiter von den Applikationen sehr stark profitieren (z.B. Smart Meter Lösungen für Utilities) Da ganze wird getopt das man das ganze auch ggf. in die ´" Cloud" stellen kann - SAP kann sich nur selber schlagen !! Optimist Diesen Beitrag teilen Link zum Beitrag
Mithrandir77 April 7, 2013 Hat SAP seine HANA-Zahlen geschönt? was denkt ihr darüber? wurde da etwas getrickst? Diesen Beitrag teilen Link zum Beitrag
WOVA1 April 7, 2013 Hat SAP seine HANA-Zahlen geschönt? was denkt ihr darüber? wurde da etwas getrickst? Tut doch jeder in dieser Industrie.. Mal ehrlich: wer jetzt ein einigermassen laufendes SAP-ERP/CRM/SRM hat, wird dies doch nicht ohne Not auf HANA umstellen - dazu hat SAP (wie die ganze Industrie) eine zu lange Geschichte aus Pleiten, Pech und Nachbesserungen. Und wenn man es doch tut, wird man sich vermutlich Sonderbedingungen für die Schulung seiner Mitarbeiter oder SAP-Support aushandeln - die fallen dann ganz unauffällig woanders in der SAP-Bilanz an. Diesen Beitrag teilen Link zum Beitrag
Mithrandir77 April 7, 2013 natürlich steigt nicht jeder sofort um, aber langfristig sollte HANA doch gute Chancen haben, oder? Diesen Beitrag teilen Link zum Beitrag
Optimist April 7, 2013 Hat SAP seine HANA-Zahlen geschönt? was denkt ihr darüber? wurde da etwas getrickst? Hana ist die strategische Lösung von SAP - SAP ERP und Business Suite werden auf Hana sind/kommen - sowie die industriespezifischen Lösung z.B. Utilties, Banken, usw.. Auch die SAP Partner werden Ihre zukünftigen Applikation auf Hana setzen. Es besteht durchaus die Notwendigkeit auf Hana umzustellen - Themafelder die das Thema Big Data innehaben z.B. SAP Analytics, Social Media usw... erzeugen Notwendigkeiten. Sollte man seine Anwendungen nicht auf Hana umsetzen, kann das SAP Unternehmen die Sybase Lösungen (Datenbank) nutzen. Wichtig ist das der Kunde alles aus einer Hand bekommt - Applikation sowie Datenbank - Sybase und Hana -RDS Real Data Plattform Hinsichtlich Bilanzen und Ergebnisse zu Hana wird es optimistischer gestaltet als es ist - richtig - mache alle so ! Hinsichtlich der Kursentwicklung halte ich Kurse für über 70 EUR für realistisch. Optimist Diesen Beitrag teilen Link zum Beitrag
WOVA1 April 8, 2013 Hana ist die strategische Lösung von SAP - SAP ERP und Business Suite werden auf Hana sind/kommen - sowie die industriespezifischen Lösung z.B. Utilties, Banken, usw.. Auch die SAP Partner werden Ihre zukünftigen Applikation auf Hana setzen. Es besteht durchaus die Notwendigkeit auf Hana umzustellen - Themafelder die das Thema Big Data innehaben z.B. SAP Analytics, Social Media usw... erzeugen Notwendigkeiten. Sollte man seine Anwendungen nicht auf Hana umsetzen, kann das SAP Unternehmen die Sybase Lösungen (Datenbank) nutzen. Wichtig ist das der Kunde alles aus einer Hand bekommt - Applikation sowie Datenbank - Sybase und Hana -RDS Real Data Plattform .. Wohl eher wichtig für die SAP - schliesslich füttert man derzeit via Datenbank-Lizenzen ausgerechnet den Konkurrenten Oracle. Und die hauseigene MaxDB kam mangels Unterstützung in eigenen Haus nie so recht vom Fleck. Diesen Beitrag teilen Link zum Beitrag
EmilioShark Mai 29, 2013 Ich bin gerade bei SAP eingestiegen bei genau 59,00 Euro. In Anbetracht der gelaufenen "Korrektur" und günstigen Aussichten, inklusive super Analystenmeinungen stehe ich dem SAP Titel sehr optimistisch gegenüber! Keep fingers crossed Diesen Beitrag teilen Link zum Beitrag
Garffield Juli 2, 2013 Hallo Allerseits, ich trade sehr gerne mit SAP und bin auch jetzt wieder involviert ( KK: 56,80 € ) . Nach der Bekanntgabe aus dem Hause SAP an den Zahlen für dieses Jahr festzuhalten stieg die Aktie um knapp 5%. Zwei Tage später ging es aber rapide gen Süden teils unter 55,00 €. begründet wird dies, dass es aus charttechnischer Sicht zu einem Verkaufssignal gekommen ist. Ich denke, dies war doch auch schon relevant als die gute Nachricht aus dem Hause SAP kam? Und hier muss ich passen, da ich mich mit der Charttechnik nicht auskenne Vlt. kann hier jemand aufklären? Warnschuss für die SAP-Aktie28.06.2013, 14:50 UhrDer Kurs des Software-Konzerns hat aus charttechnischer Sicht ein klares Verkaufssignal gegeben. Doch das Chartbild bietet noch einen letzten Rettungsanker, der den Titel vor einem Absturz bewahren kann. http://www.handelsblatt.com/finanzen/zertifikate/nachrichten/chartanalyse-warnschuss-fuer-die-sap-aktie/8413606.html Gruß garffield Diesen Beitrag teilen Link zum Beitrag
Schildkröte Juli 6, 2013 · bearbeitet Juli 6, 2013 von Schildkröte ich trade sehr gerne mit SAP und bin auch jetzt wieder involviert ( KK: 56,80 € ) . Und hier muss ich passen, da ich mich mit der Charttechnik nicht auskenne Vielleicht ist dir schonmal aufgefallen, dass die Mehrheit der Forumsteilnehmer langfristig orientiert ist!? Für sog. Trader gibt es wohl bessere Foren. Wenn du Charttechnik nicht verstehst, ist das aber eigentlich nicht schlimm. Die ist nämlich auch kein verlässliches Hilfsmittel für Anleger. Entweder du bist von dem Wert überzeugt und bleibst investierst oder du löst deine Position halt auf. Ohne Rücksicht auf deinen Einstandskurs, die Börse nimmt darauf auch keine Rücksicht! Diesen Beitrag teilen Link zum Beitrag
Wutschi September 16, 2013 Morgen startet der DSAG Jahreskongress, dort wird sicherlich kräftig die Werbetrommel für HANA gerührt und auch von ersten Projekten und Erfahrungen berichtet. Soweit ich es aus meinem Umfeld mitbekomme hat auch der Auftragseingang an HANA Projekten angezogen und auch die Suche nach HANA Spezialisten auf den Freelancerbörsen ist gewachsen. So wie es sich mir darstellt scheint sich HANA schneller als von mir gedacht zur Lokomotive zu entwickeln. Ich bin seit Freitag wieder bei SAP dabei, ich wollte eigentlich Kurse unter 50 Euro abwarten, aber ich fürchte die kommen so schnell nicht. Diesen Beitrag teilen Link zum Beitrag
Mithrandir77 Oktober 5, 2013 Plattner will mit SAP nach Amerika Diesen Beitrag teilen Link zum Beitrag
