Tesnet Group GmbH Blog

Business Ziele und IT - nicht immer ein Traumpaar!

dgrausdies@tesnet-group.de ( Dieter Grausdies) — Fri, 19 Mar 2010 13:37:44 +0100

Der Schluss liegt nahe, wenn wir den Ergebnissen einer Online-Umfrage Glauben schenken, die IDG Research im Auftrag von Unisys unter 550 IT-Verantwortlichen großer Unternehmen durchgeführt hat.

Weniger als die Hälfte der Befragten konstatiert der internen IT, die vorrangigen Businessziele Kostensenkung, Kundenzufriedenheit, Flexibilität, Produktivitäts- und Gewinnsteigerungen und die Geschäftsstrategie des Hauses effektiv zu unterstützen.

Bei den IT-Zielen sieht es nicht anders aus. So glauben nur 50 % der Antwortenden, dass die eigene IT zum für sie wichtigsten Ziel der Vermeidung und Reduzierung von Betriebsausfällen beiträgt.

Eine ähnliche Kluft zwischen Auftrag und Wirklichkeit klafft hinsichtlich Service Delivery, Business IT Alignments, Kontrolle der IT-Kosten, höhere Servicequalität für die Anwender.

Wie kann dem begegnet werden?

Die Analyse der angewandten IT-Management-Methoden ergab, dass die Ergebnisse am besten waren, wenn die eingesetzten Methoden als Best Practices geeignet sind. In den positiven Fällen waren häufig ITIL-basierte Prozesse vorzufinden. Besonders effektiv sind die Geschäftsziele anscheinend zu erreichen, wenn ein gutes Knowledge-Management im Support mit Frameworks für die Entwicklung und Modelle zur Serviceautomatisierung (z.B. Software as a Service, SaaS) kombiniert werden. Diese Kombination bietet Möglichkeiten zu einer engeren Zusammenarbeit zwischen IT-Abteilungen und Business.

Und: Viele IT-Verantwortliche schätzen den Input, den externe Dienstleister in ihre Teams bringen. Die Outsourcing-Partner tragen zur Verbesserung der Best Practices in den Unternehmen bei und stützen effektiv die Geschäftsziele ihrer Kunden.

Herzlichst, Ihr Dieter Grausdies

7W des Projektmanagements

bullinger@tesnet-group.de ( Robert Bullinger) — Mon, 15 Feb 2010 10:47:11 +0100

Die Diskussionen über gutes Projektmanagement verlaufen in viele Richtungen. Die einen schwören auf Zahlen und Metriken oder auf mal mehr mal weniger Dokumentation, andere setzen auf eine klare Organisation und wieder andere schwören auf PM-Software, um nur ein paar zu nennen.

Dabei ist nicht der Weg das entscheidende, sondern das allen gemeinsame Ziel. Unter Einsatz von bestimmten Ressourcen in einer gegebenen Zeit einen Mehrwert zu erzeugen.

Um dieses Ziel nicht aus den Augen zu verlieren, sollte man folgende Fragen stets beantworten können.

* Warum machen wir etwas?
* Was machen wir?
* Wie machen wir es?
* Wann machen wir dies?
* Wer macht es?
* Wie viel benötigen wir wovon?
* Wo stehen wir?

Sind Sie dazu in der Lage, haben Sie Ihre Chancen auf einen erfolgreichen Abschluss eines Projektes bereits enorm erhöht.

Herzlichst Ihr
Robert Bullinger
Solution Architect REST ASSURED!(TM) Processes

Requirements Engineering - Stiefkind in IT-Projekten?

dgrausdies@tesnet-group.de (Dieter Grausdies) — Wed, 20 Jan 2010 19:02:00 +0100

Alle kennen es, die meisten wollen es ("eigentlich") - aber in den

Projekten fristet qualifiziertes Anforderungsmanagement häufig ein

Schattendasein.

Laut einer Untersuchung der FHS ST. Gallen von 2008 sind lediglich 25% der befragten Unternehmen mit ihrem Requirements Management zufrieden und das, obwohl IT-Vorhaben oft genug die Wünsche und Anforderungen ihrer Kunden nur teilweise oder nicht erfüllen.

Und als häufigste Ursache wird das unzulängliche Erheben, Dokumentieren, Prüfen und Verwalten von Anforderungen (= Requirements Management) gesehen.

Typische Indikatoren für die Vernachlässigung dieser IT-Strategie sind:

- der geringe eingeplante Aufwand in der Projektplanung

- eine wenig intensive Suche nach den Stakeholdern der Anforderungen

- der geringe Aufwand innerhalb des Projektes für diese Aufgabe

(häufig unter 10 %)

- Einsatz nicht adäquat ausgebildeten Personals für diese Aufgabe (wenn überhaupt)

- Endanwender werden nicht beteiligt.

Vielleicht liegt es an den "weichen" Faktoren, die für eine erfolgreiche Umsetzung des Anforderungsmanagements eminent wichtig sind:

Kommunikationsfähigkeit, soziale Kompetenz, funktionierende

Informationsflüsse und Meinungsaustausch.

Ändert letztlich nichts an der großen Bedeutung, die dem Requirements Management für den Projekterfolg zukommt.

Ein paar Kennzahlen:

83% der Anforderungsänderungen gehen auf sprachliche Unzulänglichkeiten zurück,

77% der Fälle sind bedingt durch Missverständnisse;

Widersprüche, Redundanzen und inhaltliche Fehler sind da noch nicht drin (s. ebenda)! Das wirkt sich abgesehen von der Kundenzufriedenheit direkt auf die Kosten aus.

Ferner: Anforderungsanalysen auf solider Basis erlauben zuverlässigere Aufwandsschätzungen, erleichtern Investitionsentscheidungen, verbessern die vertragliche Basis von IT-Vorhaben. Dies trifft gerade auf Outsourcing-Projekte und komplexe Stakeholder-Verhältnisse zu.

Also kein Grund, das Requirements Engineering stiefmütterlich zu behandeln. Allerdings scheitert das Requirements Management in den Projekten oft am erheblichen Aufwand und der Komplexität der Tools, die sich auf dem Markt befinden.

Dennoch hilft eine bessere Kommunikation unter den Beteiligten, die erwähnten Missverständnisse und Fehler zu vermeiden und trägt so erheblich zum Projekterfolg bei.

Bei der Toolunterstützung gibt es allerdings noch etwas zu tun...

Herzlichst,

Ihr Dieter Grausdies

Agil, aber richtig!

bullinger@tesnet-group.de ( Robert Bullinger) — Mon, 07 Dec 2009 11:29:55 +0100

Immer mehr Softwareentwicklungsfirmen machen sich agilen Methoden zu Eigen und arbeiten nach dem agilen Manifest:

* Individuen und Interaktionen haben Vorrang vor Prozessen und Werkzeugen.

* Funktionsfähige Produkte haben Vorrang vor ausgedehnter Dokumentation.

* Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlungen.

* Das Eingehen auf Änderungen hat Vorrang vor strikter Planverfolgung.

Um das agile Manifest sinnvoll einsetzen zu können, sollte man aber auch die Grundgedanken dahinter verstehen, denn leider werden diese 4 Punkte auch gerne als Ausreden für "zu lockeres" Arbeiten missverstanden. So sollten diese Aussagen z.B. nicht als Ausschlusskriterium verstanden werden.

Wenn Menschen in einem Team zusammenarbeiten und interagieren, dann benötigen sie auch klare Basisprozesse, die die Zusammenarbeit regeln. Werkzeuge können hierbei helfen.

Komplett auf Dokumentation zu verzichten, kann man sich aus rechtlicher Sicht kaum leisten, anstatt seitenlanger Wälzer bevorzugt man allerdings das persönliche Gespräch, die daraus resultierenden Notizen können abgelegt werden.

Das offene, klärende Gespräch und der gute Kontakt zum Kunden sind ausdrücklich gewünscht in agilen Projekten, aber die eigene rechtliche wie finanzielle Absicherung darf dadurch nicht vernachlässigt werden.

Zusätzlich darf das Ende eines Projektes nicht aus denn Augen verloren werden vor lauter Änderungen am Produkt.

Wer nie zum Ziel kommt, kann nicht abschließen und auch nichts Neues beginnen.

Herzlichst,

Ihr Robert Bullinger

Solution Architect REST ASSURED! Processes

SOA Testing (Teil 2, Herausforderungen)

sreitinger@tesnet-group.de (Siegfried Reitinger) — Fri, 20 Nov 2009 13:41:30 +0100

Nach einem kurzen allgemeinen Überblick über die Thematik „SOA“ im ersten Teil folgt nun die konkrete Beschreibung einiger Herausforderungen, die mit SOA Testing verbunden sind. Diese Herausforderungen gelten eingeschränkt auch für funktionale Tests.

Herausforderung 1: Funktionsweise

Die meisten Applikationen arbeiten nach einem einfachen Client/Server Prinzip. Die Rollen sind klar verteilt, der Client generiert, üblicherweise ausgestattet mit einer GUI (z.B. Webbrowser), eine Anfrage und der Server schickt synchron eine Antwort.

Je nach SOA Implementierung ergeben sich hierzu einige Unterschiede:

Es existiert kein universeller SOA Client bzw. eine GUI dafür. Clients kommen meist in Form einer API abhängig von der verwendeten Technologie (z.B. Message Queueing).
SOA Request Generierung erfolgt nicht notwendigerweise beim Enduser, sondern häufig auf einem Applikationsserver der dann z.B. via Web eine GUI zur Verfügung stellt.
Für asynchrone Webservices (Callback Webservices) sind beide Seiten technisch gesehen gleichermaßen Client und Server. Man verwendet deswegen hier die Bezeichnung Provider (liefert Daten) und Consumer (fordert Daten an).

Herausforderung 2: Toolunterstützung

Üblicherweise werden Capture & Replay Mechanismen verwendet, um die Testimplementierung zu vereinfachen. Angesichts der beschriebenen Funktionsweisen ist das im SOA Testing meist nicht möglich.

Ein Out-of-the-Box Support aller SOA Varianten unterstützt derzeit kein Testtool, dies trifft besonders auf asynchrone und proprietäre Implementierungen zu. Eine Realisierung erfordert meist einen beträchtlichen zusätzlichen Entwicklungsaufwand (Einbindung API in das Testtool, Antwortzeiterfassung bei asynchronen Services usw.) und detailliertes technisches KnowHow.

Herausforderung 3: Technische Komplexität

Ohne Kapselung durch das Testtool wird die technische Komplexität an den Tester weitergereicht. Dies kann auch sehr spezielle Kenntnisse im weiteren IT Umfeld wie zum Beispiel der Kryptographie erfordern. Ein umfassendes Verständnis der Protokolle, Datenformate und technischen Abläufe ist Voraussetzung für einen erfolgreichen SOA Test.

Herzliche Grüße

Siegfried Reitinger

Solution Architect REST ASSURED!™ Performance