Sebastian FreundInnovation und Technologie

Unworte und ihre Folgen – heute: Portal

Manchmal wünsche ich mir, dass der Begriff „Portal“ niemals in der IT aufgetaucht wäre. Kaum ein anderer Begriff stiftet eine derartige Verwirrung mit teils verheerenden Folgen.

Oft treffen wir bei Kunden auf die Situation, dass bereits die Entscheidung für ein „Portalprojekt“ getroffen wurde. Häufig wurde bereits eine technische Lösung ausgewählt. Die großen Software-Anbieter bieten den Kunden Portale ja auch in ihren Software-Katalogen und Preislisten als eigene Software-Gattung an und bewerben sie.

Vision des CIO: Ein Portal muss her!

Neulich sprach mich ein Vertriebskollege an und schilderte mir folgenden Fall: Der CIO eines großen Unternehmens hat den Auftrag an seine IT-Abteilung gegeben, ein Portal zu erstellen. Die Vision des CIO bestand darin, die 250 bis 300 Anwendungen des Konzerns über ein Portal zugänglich zu machen. Mein Kollege wurde nun mit der Frage des IT-Abteilungsleiters konfrontiert, welche Software er denn jetzt kaufen müsse. Er brauche schnell eine Entscheidung, weil er dem CIO eine Entscheidungsvorlage inklusive aller Kosten – im Speziellen für einen Proof of Concept – vorlegen müsse.

Nach einem relativ kurzen Telefongespräch war eines klar: Das Problem unseres Kunden liegt an einer ganz anderen Stelle, als er selbst vermutete.

Bist Du sicher, dass Du Dein Problem kennst?

Auf einem Stück Papier skizzierte ich dem Kollegen dann die Lage und einen Lösungsweg unter vollständiger Umgehung des Begriffs „Portal“.

2014-02-skizze

Ich machte ihm deutlich, dass das eingeschlagene Vorgehen zu spät ansetzt. Mit dem zu frühen Kauf einer Software werden viele Entscheidungen bereits getroffen. Oft leidet darunter eine fundierte Anforderungsanalyse und in der Folge schleichen sich nur aufwendig behebbare Design-Fehler ein. Bei Projekten mit vielen Stakeholdern und einer heterogenen Systemlandschaft kann sich das Vorhaben so schnell zu einem Kostengrab entwickeln.

Ich schlug vor, zunächst die Problemlage des Kunden zu sortieren. Welche Ziele hat er? Was ist sein eigentlicher Wunsch? Wo entstehen heute Kosten, die es zu optimieren gilt? Um welche Applikationen geht es? Welche Prozesse sind betroffen?

Anhand dieser geschärften Ausgangslage entwickelten wir einen Vorschlag für ein Vorgehen, das letztlich zu einem abgestuften und bedarfsorientierten Lösungsbaukasten führte, der systematisch die Integration aller Anwendungen und Prozesse unter einem Dach ermöglichte. Es stellte sich heraus, dass die ursprünglich geplante Portal-Software nun keine tragende Rolle mehr spielte.

Vielmehr wurden die einzelnen Problemstellungen zum großen Teil mit bereits vorhandenen Lösungen abgedeckt. Allen voran wurde ein Single Sign On zum tragenden Element der Strategie. Auf der konzeptionellen Ebene wurden Richtlinien für die Gestaltung von Oberflächen und für Entwicklungs-Frameworks festgelegt.

Problem und Lösung – Auf die Reihenfolge kommt es an!

Wie sich herausstellte, traf diese pragmatische Sicht des Problems zu und der Vorschlag zum Vorgehen den Nerv des Kunden.

Folgende Leitsätze fassen die Erfahrungen zusammen:

  • Beginnen Sie beim Problem. Nicht bei der vermeintlichen Lösung.
  • Vermeiden Sie den Begriff „Portal“. Versuchen Sie, das Problem zunächst neutral zu beschreiben.
  • Machen Sie sich Gedanken über den praktischen Bedarf. Ordnen Sie ihm weitergehende Visionen unter.
  • Erklären Sie nicht mangelndes Interesse an der Auseinandersetzung mit den realen Herausforderungen zur strategischen Entscheidung. Es rächt sich.
  • Wer „Portal“ sagt, meint meist nicht die Software-Gattung „Portal“

Achtung Cliffhanger: Möchten Sie wissen, wie es dem Begriff „Portal“ weiter an den Kragen geht, dann lesen Sie auch meinen nächsten Post.

Schlagwörter: , ,