Archive zu Kategorie 'Methodik'
15. Februar 2009 von KG
(Fortsetzung von Teil 2). Was ist beim Entwurf einer IT-Strategie zu beachten und wie macht man das in der Praxis?
Eine IT-Strategie entwerfen
Wesentlicher Leitsatz ist: Die IT-Strategie hat sich an der Unternehmensstrategie auszurichten und muss dabei die Produktstrategie tragen. Sie darf dabei die Produktstrategie, in manchen – gar nicht so seltenen – Fällen auch die Unternehmensstrategie, zu neuen Visionen anregen. Keinesfalls darf die IT-Strategie das Unternehmen und die Produkstrategie behindern.
Das klingt im luftleeren Raum schön und einfach, ist es in der Praxis aber nicht: Häufig widersprechen sich die Bedürfnisse des Produktmanagements und der IT-Führung.
Die Kunst besteht gerade darin, einen angemessenen Ausgleich zu schaffen und die IT-Strategie so zu formulieren, dass die IT der Produktentwicklung und dem Vertrieb ausreichend Spielräume verschafft, andererseits aber nicht zum bloßen Befehlsempfänger wird, der reaktiv versucht, die Produktentwicklungen des Vorjahres in die Backendsysteme zu “quetschen”, während längst schon andere Produkte verkauft werden.
Das Zusammenspiel ist hier allein erfolgversprechend und erfordert hochkommunikative Persönlichkeiten auf allen Seiten. Wünschenswert ist daher eine allgemein anerkannte Kommunikationskultur im Unternehmen, etwa basierend auf dem Harvard Principle of Negotiation.
Am Anfang ist das Ist
Nehmen wir nun an, dass die Mitarbeiter aus den betroffenen Abteilungen miteinander nutzbringend kommunizieren können. Wie soll es dann weitergehen? Man könnte, gewissermaßen im luftleeren Raum, eine Strategie ausarbeiten und dann alles tun, dass sie “irgendwie” umgesetzt wird.
Hier würde aber etwas fehlen: Die Einschätzung der aktuellen Lage, die Ermittlung einer zwar unbekannten, aber durchaus vorhandenen IT-Strategie. Ohne diese sind Sie gar nicht in der Lage, Vorgaben zu machen: Ähnlich wie bei einem Navigationssystem müssen Sie zunächst ermitteln (lassen), wo Sie sich gerade befinden.
Wie macht man das?
Die vier P: Personen, Prozesse, Philosophie, Performance
Einen guten Anhaltspunkt bieten vier Kriterien, die aus der Investmentbranche stammen (siehe z.B. hier), und möglicherweise eine Abwandlung des 4P-Prinzips von Toyota darstellen.
Diese vier Prinzipien sind deshalb so gut dafür geeignet, eine strategische Ausrichtung zu entwickeln, weil sie
a) den menschlichen Aspekt der IT berücksichtigen helfen (wenn Sie die Bücher De Marcos/Listers noch nicht kennen, wird es Zeit…);
b) ermöglichen, die Auswirkungen der eingeschlagenen IT-Strategie zu messen (und auf aktuelle Entwicklungen zu reagieren).
Ab Teil 4 werden diese Kriterien genauer betrachtet. Wir werden uns dabei fragen, wie sich das Unternehmen bezüglich dieser Prinzipien aktuell positioniert.
12. Februar 2009 von KG
(Fortsetzung von Teil 1).
Was ist IT-Strategie?
Als IT-Strategie im weiten Sinn verstehe ich:
Die Antwort auf die Frage, wie durch den Einsatz von Informationstechnologie die Unternehmens- und Produktstrategie unterstützt werden soll.
Die Frage…
“Welche IT-Strategie hat das Unternehmen eigentlich?”
…sollte eigentlich jeder Manager, insbesondere einer aus der IT, unmittelbar beantworten können. Sie/er sollte in der Lage sein, in wenigen Sätzen zu erläutern,
a) was die Unternehmens- und was die Produktstrategie ist;
b) wie der Einsatz von Informationstechnologie diese unterstützen soll.
Die Strategie ist verschwunden!
Häufiger als man denkt, ist die IT-Strategie aber unbekannt. Dies ist in jedem Fall ein ernstzunehmendes Krankheitssymptom für jedes Unternehmen, das IT einsetzt und ohne sie nicht funktionieren kann.
Variante 1: Keine Unternehmensstrategie
Woran kann das liegen? Der übelste Fall wäre, dass die Unternehmensstrategie noch nicht entwickelt wurde. Hier hilft nur, darauf hinzuwirken, dass dies schnellstmöglich erfolgt und die Strategie von der Unternehmensführung an alle Mitarbeiter kommuniziert wird.
Falls man keine Einflussmöglichkeiten in diese Richtung hat, muss man sich ernsthaft mit dem Gedanken auseinandersetzen, wie lange ein Unternehmen existieren kann, ohne über eine (nachhaltige) Unternehmensstrategie zu verfügen.
Variante 2: Keine Produktstrategie
Abgeschwächt könnte zwar eine Unternehmensstrategie vorhanden sein, aber die Produktstrategie fehlen (also die Antwort auf die Frage: mit welchen Produkten möchten wir unsere Unternehmensstrategie wie umsetzen?). Ohne Produktstrategie lässt sich aber keine IT-Strategie entwickeln. Hier sollte jeder IT-Mitarbeiter sehr daran interessiert sein, wie sich die Produkte des eigenen Unternehmens im Wettbewerb plazieren und nötigenfalls mit der Suche bei Monster etc. beginnen.
Variante 3: IT-Strategie vorhanden, aber nicht kommuniziert
Schließlich kann die IT-Strategie unbekannt sein.
Dass eine IT-Strategie unbekannt ist, kann unterschiedliche Ursachen haben. Beliebt ist die Konstellation, dass (irgend)eine IT-Strategie zwar im Kopf der leitenden Manager vorhanden ist (üblicherweise pro Kopf eine unterschiedliche Strategie), diese aber nicht kommuniziert und transparent gemacht wird und deshalb in summa unbekannt bzw. vage und widersprüchlich ist.
Dem kann verhältnismäßig einfach entgegengewirkt werden: Der oberste Chef der IT hat die IT-Strategie zu formulieren und nach unten zu kommunizieren. Dass dies auch erfolgt, ist Sache der Unternehmensleitung. Diese muss die IT-Strategie als Ausprägung der Unternehmensstrategie tragen und (deshalb auch: inhaltlich nachvollziehen können.).
Variante 4: Keine IT-Strategie
Schlimmer ist, wenn die IT-Strategie unbekannt ist, weil sie nicht entwickelt wurde. In diesem Fall muss die IT-Strategie erarbeitet werden (wir sind der Ansicht, dass sich die IT-Strategie von der Unternehmens- und Produktstrategie ableitet, und gehen hier davon aus, dass beide bereits vorhanden sind.) .
Wie man beginnt, eine IT-Strategie zu entwickeln, findet sich in Teil 3.
3. Februar 2009 von KG
Gerne verrate ich: IT-Strategie ist meine geheime Passion. Als Angestellter in der IT-Branche mit ambivalentem Hintergrund (Volljurist, der als Softwareentwickler, -architekt und IT-Berater tätig war und jetzt als Systems Engineer eine 100%ig passende Schnittstellenposition besetzt) reflektiere ich seit Beginn meiner Tätigkeit in der IT die Motivationen hinter unternehmerischen Entscheidungen mit unmittelbaren Einfluss auf die IT.
Immer wieder stoße ich auf die Frage (oder – schlimmer – werde gestoßen) welche IT-Strategie zu konkreten Handlungen oder Handlungsanweisungen in Unternehmen führt.
Die häufig wiederkehrenden Beispiele für konzeptionslosen, von keiner Strategie getragenen Aktionismus sind Legion:
- um Kosten zu reduzieren, wird die Softwareentwicklung der zentralen Transaktions- und Bestandsanwendungen “outgesourced”;
- Vertriebsmitarbeiter eines externen Softwareunternehmens bieten die neueste Version ihres Produkts an – das Management lässt daraufhin prüfen, welche Möglichkeiten es gibt, dieses einzusetzen (anstelle eine Software dann zu evaluieren, wenn sie benötigt wird);
- das von allen Mitarbeitern eingesetzte Helpdesksystem wird fachlich einem externen Mitarbeiter überantwortet; als dieser das Unternehmen verlässt, bleibt die Position vakant und wird einem Programmierer übertragen, der das System auch noch gleich warten soll;
- die technologisch kompetentesten Mitarbeiter aus der Softwareentwicklung müssen die Systeme selbst betreuen, weil kein Maintenance-Konzept vorliegt und Software nicht so entworfen wird, dass sie von Mitarbeitern ohne Programmierkenntnisse gewartet werden kann.
- für Softwareentwickler/Techniker ist kein Karrierekonzept vorhanden – sie können lediglich ins Management wechseln, um sich finanziell zu verbessern oder ihren Verantwortungsbereich zu vergrößern – dies führt dazu, dass sie entweder das Unternehmen verlassen oder sich “arrangieren” i.S.v. innerlich kündigen;
- Jungmanager werden ohne Assessment ausgewählt; am Beginn ihrer Karriere steht ihnen niemand zur Seite, der sie einarbeiten könnte; anstelle Mitarbeiter zu führen, verwalten sie diese und wundern sich, dass der Spaß an der Arbeit abnimmt und sich die Arbeitsergebnisse verschlechtern;
- ohne Rücksprache mit dem Entwicklungsteam wird versucht, die Qualität der Softwareprodukte zu messen, die verwendete Methodik berücksichtigt weder den Kundennutzen noch die Arbeitsweise des Teams.
All dies sind gute Beispiele, die sofort die Frage aufkommen lassen, was IT-Strategie ist und welche IT-Strategie ein Unternehmen hat. Die Antwort darauf findet sich in Teil 2.
22. Dezember 2006 von KG
Eine Frage beim derzeitigen Hype des Das-Web-2.0-begründet-das-Semantic-Web drängt sich mir gerade bei den Social Networks auf: Wie kann man sicherstellen, dass die Indizierung von Inhalten ("Tags") inhaltlich auch korrekt ist? Was ist, wenn bewusst falsch getaggt wird, um Suchende von bestimmten Inhalten fernzuhalten/abzulenken? Letztlich dürfte das mit einer Mischung aus statistischen Methoden und irgendwelchen Glaubwürdigkeitsmechanismen ("Net of Trust") beantwortet werden, ich finde diese – sehr offensichtliche Frage – aber nirgends erwähnt.
9. November 2006 von KG
Beim Lesen der Produktankündigungen großer Softwarehersteller (z.B. für Datenbanken, ERP-Tools, aber auch nur Office-Suiten) fällt mir eines immer wieder auf: Die Verbesserungen betreffen oft eine enorme Bandbreite an Funktionalität, die definitiv niemals von einem Unternehmen erschöpfend ausgenutzt wird.
Selten dürften z.B. native XML-Unterstützung, spezielle Transaktionsfeatures etc. etc. auf einmal eingesetzt werden. Ob diese Annahme zutrifft, ließe sich eigentlich einigermaßen leicht nachvollziehen: Man müsste "nur" die zugrundeliegende Software nach Funktionspunkten aufschlüsseln und überprüfen, wie viele Funktionspunkte im Tagesbetrieb verwendet werden. Sicherlich kommen da auf die Kernmodule die meisten Zugriffe. Was aber interessant zu erfahren wäre, ist die Zahl der Funktionspunkte, für die der meiste Programmieraufwand betrieben wird im Verhältnis zu den Funktionspunkten, die am meisten benutzt werden.
Ich wage zu behaupten, dass der überwiegende Teil (~80%) der Anwender die Funktionalitäten, für die der meiste Programmieraufwand (~80%) betrieben wird, zu einem ganz geringen Teil (~20%) nutzen.
8. November 2006 von KG
Immer wieder höre ich dies “interessante” Argument, man könne den Windows-Desktop nicht durch einen Linux-basierten Desktop ersetzen, da die Anwender im Geschäftsumfeld insbesondere zu stark an die MS-Office-Anwendungen gewöhnt wären und die nötigen Schulungen bei einem Umstieg zu teuer wären.
Hier möchte ich bezweifeln, dass dieses Argument wirklich greift: Bei der Ãœberprüfung von Userrequest stellte MS meines Wissens bereits fest, dass der überwiegende Teil der Wünsche bereits implementiert, den Anwendern aber unbekannt war. Aus eigener Praxis weiß ich, dass nur ein ganz kleiner Teil der Anwender in der Lage ist, überhaupt mehr als etwa 10-15% der Funktionalitäten der Anwendungen von MS Office Standard (Word, Excel, Powerpoint) zu nutzen.
Das dürfte daran liegen, dass die meisten Anwender nie in der Benutzung der Office-Anwendungen geschult wurden. Unabhängig davon, dass mit Crossover Office eine gut einsetzbare kommerzielle Lösung vorhanden ist, um Office-Anwendungen auch auf dem Linux-Desktop einzusetzen, die durchaus erschwinglich ist, kann man dem Großteil der normalen Office-Anwender einen Umstieg ohnehin zumuten: Die Grundfunktionalitäten sind bei KWord, Abiword oder OpenOffice so selbsterklärend wie bei MS Office…
20. September 2006 von KG
Geheimtreffen, Absprachen hinter der Hand, Aufgaben und Positionen verteilen, ohne dies zuvor transparent zu machen – für manche ist das ganz normaler Arbeitsstil, andere (zu denen ich mich zähle), finden das brechreizerregend.
Immerhin kann ich für diese aus einem allgemeinen Gerechtigkeitssinn und einer Achtung vor jedem Menschen ein Bibelzitat heranziehen: Jeder, der Böses tut, hasst das Licht und kommt nicht zum Licht, damit seine Taten nicht aufgedeckt werden. (Joh, 3, 20).
Da fielen mir aus meiner Berufserfahrung einige ein, die unter Berücksichtung dieses Textes eindeutig Böses getan haben. Offene Kommunikation bedeutet doch: Vor Veränderungen rechtzeitig informieren, Probleme kommunizieren, die eigenen Absichten/Wünsche/Pläne/Motivationen darlegen.
23. Juni 2006 von KG
Laut http://www.diepresse.com/Artikel.aspx?channel=h&ressort=ho&id=566909 stellt die Flut an E-Mails eine Belastung der Arbeitnehmer dar.
Unabhängig vom Medium denke ich, dass es nicht alleine das Medium ist, das Probleme bereitet. Es ist die allgemein steigende Komplexität der beruflichen Abläufe und das zu den auf dem Markt angebotenen Produkten (jeder Branche) exponential steigende Fachwissen, was beides immer schlechter beherrscht wird.
Natürlich könnte ein Problem des Mediums “E-Mail” schon die abnehmende textuelle Kommunikationsfähigkeit sein, die hiermit aus eigener Sachkunde postuliert wird. Da wäre eine Lösung vielleicht, anstelle des Textes Sprachnachrichten zu versenden und diese dann zusätzlich über Spracherkennung zu textualisieren.
Eine andere wäre, dass alle Mitarbeiter eines Unternehmens nur noch mit einer einzigen Unternehmensschnittstelle kommunizieren, die sämtliche Informationen aufnimmt, indiziert und ggf. routet, wobei die Mitarbeite sich gleich RSS-Feeds die für sie relevanten Informationen “abonnieren” können und selber entscheiden, wann sie sich informieren.
Hach, wie wäre das spannend, derartiges umzusetzen!
21. Juni 2006 von KG
Tritt ein Produktionsproblem auf, ist für mich selbstverständlich, dass für den Aufwand zur Fehlerbehebung auch das Schreiben eines Unit Tests gehört, der sicherstellen soll, dass sich das aufgetretene Problem oder ähnliche Probleme (sofern testbar) sich nicht wiederholen.
Letztens habe ich von einer gegenteiligen Entscheidung erfahren ("nö, haben wir keine Zeit für"), die nur von einem zeugt: Unkenntnis, Dummheit, Vernachlässigung der Firmeninteressen, keine Interesse an stabiler Software.
23. November 2005 von KG
Just a short update about what I'm interested in (on the software side). On the one hand it's the ESB concept: Despite the former EAI solution, the very fascinating thing is that the ESB can understood as virtual – it's not necessary to have a server running in the middle.
Have a look at http://www.celtix.org.
Then I read a little bit about the semantic web and I wonder why the bigger Wiki systems still don't support it. I mean think of Wikipedia – there people do all the meta-tagging anyway. Why not using the advantages of the semantic web and create clickable topic maps e.g.?
Also MusicXML is interesting to me. AFAIU this standard is basically a translation of the MIDI format to XML. If so, I think it's as useful as MIDI is. But not further and it does not reflect the needs of modern composers or of non-western musicians. From my opionion, a Lillypond equivalent XML standard is necessary.
Finally I'm fully fascinated by Ruby on Rails (hey, the Pragmatic Programmer's book has been released since some weeks, it's as great as every book published within this series). As I like to work more on End User Development stuff (in my free time), one approach could be to write a rails cartridge fro andromda. If that was finished, it'd be great to develop a rule engine based wizard that queries the customer different questions which result in the UML structure that'd be then processed with the rails cartrigde.
Wish one could buy time and I were rich then…
8. März 2005 von KG
Something you might experience not only once in your lifetime.
A new user acceptance test should be set up.
But the single steps for setup and the testing procedure are not documented.
The responsible business analyst just explains this situation with: “We have no time, I’ll explain it verbally to the person testing.”.
Whenever a test is done, the BA needs to go to the testers and explains to each of them the testing procedure.
Because the testers can’t always follow his explanations, they need to re-ask him things and become basically dependent on the BA’s information.
Each test cycle the BA has to spend around five hours on explaining testing procedure.
Writing the documentation roughly would cost only one hour, and I believe that the BA is aware of the discrepancy…
Have your thoughts about why a BA could think this sitation is useful for him/her…