Tag Archives: project management

IT explained

sclable: Das “rapid everything” ERP

Vergangene Woche hatte ich das Vergnügen, an einer sneak peek für ein überraschend neuartiges ERP-System teilzunehmen. Das Wiener Startup sclable tritt an, um das SAP oder Oracle von morgen zu werden. Die Ansage ist natürlich zu stark, um zu halten, aber dennoch ist das Produktkonzept mehr als nur einen Blick wert.

Ich würde sclable als Scaffolding Framework mit Workflows und hübschem UI beschreiben. Sagt vorerst wenig: Man kann damit jedenfalls sehr schnell individuelle Workflows in Software gießen und bleibt überdies flexibel. Es klingt ein wenig nach Heiligem Gral der Softwareentwicklung: Vorteile von Standard- und Individualsoftware vereint in einer Lösung, das Ganze durch geschulte Mitarbeiter in Eigenregie durchführbar.

sclable besetzt mit dieser Idee eine – zumindest für mich – komplett neuartige Nische im Unternehmen irgendwo zwischen zur Unhandhabbarkeit gewachsenen Excels, dem von Haus aus unhandhabbaren Sharepoint, der schwerfälligen Business Class mit SAP Workbench oder Oracle Forms sowie der Plugin-Architektur von WordPress.

Bereits nach der kurzen Einführung würde ich mir zutrauen, beispielsweise einen Bestellworkflow für ein mittleres Unternehmen mit sclable innerhalb weniger Stunden umzusetzen. So schnell, wie ich in sclable editiere, kann ich beim besten Willen nicht programmieren.

hgd
sclable at its best: Im Handumdrehen erstellte Entitäten werden mit beliebig komplexen Workflows verknüpft. Die graphische Darstellung ist bereits der halbe Weg zur Dokumentation.

Damit kommen wir zum wirklichen Vorteil: Durch die enorme Geschwindigkeit wachsen Spezifikation, Umsetzung, Test und Dokumentation zusammen. Es ist also vorstellbar alle Präsentationen, Powerpoints, e-Mails und Telefonate zu skippen und gleich gemeinsam mit dem Kunden loszulegen. Solange also die Aufgabenstellung zum Kern von sclable passt (“Mehrbenutzer-Workflow rund um ER-Modell”), ist’s ein Wahnsinns-Tool.

“Don’t ever fight a framework!”

Den Punkt, wo Customizing zur Vergewaltigung wird, darf man allerdings – wie bei jedem anderen Framework auch – nicht übersehen. Dann endet man schließlich wiederum in der Individualentwicklung, und hier würde ich dann generell zu Python/Django greifen. (Nun ja, da greife ich fast immer hin.)

Was paranoide oder Policy-geplagte CIOs beruhigen dürfte, ist außerdem die Info, dass das Produkt nicht nur als SaaS sondern auch on-premise laufen soll. Dank API sind Daten außerdem exportierbar, was langfristige Abhängigkeiten ohne Ausweg unterbindet.

Nachteil ist womöglich PHP als Runtime. Technisch ist es einfach pfui wegen fehlender Namespaces einer besch*** Standard Library, Patch-Wahnsinn, usw. Entwickler gibt’s jedoch genug. (Und mit Wikipedia oder Facebook gibt’s zugegebenermaßen ziemlich große PHP-Projekte, wo auch niemand über die Programmiersprache schimpft…)

Ich bin gespannt auf den Launch und weitere News von sclable.at!

Edit: Markus Nenning hat mich darauf aufmerksam gemacht, dass ERP eine nicht ganz korrekte Schublade für das Produktkonzept ist. Ich hab’s dennoch beim Titel belassen, da man sich mit bekannten Kategorien einfach leichter tut. Aber klar, mit der Flexibilität von sclable könnte man auch ganz andere Schubladen füllen – von Projektmanagement über CMS bis hin zu einem Universitätsverwaltungssystem.

business

Selbständig neue Wege gehen

Nach spannenden Jahren an der WU ist es für mich an der Zeit, einen neuen Weg zu beschreiten.

Und da ich wohl kaum einen abwechslungsreicheren Job als meinen bisherigen finden werde, führt der Weg in die Selbständigkeit.

Die Firma ist gegründet, sie heißt c99 und wohnt (noch) daheim im Bügelzimmer, die ersten Umsätze sind getan, und – am Wichtigsten – es macht wirklich Spaß!

frere
Visitenkarten druckfrisch in den Händen meiner Grafikerin.

Manage complexity

Business und IT sind unglaublich komplex – oder schlimmer noch – kompliziert. Ein zentrales Thema meiner bisherigen Arbeit war der langfristige Umgang mit betrieblicher Komplexität. Dazu zählen unklare Anforderungen genauso wie häufige Änderungen, Zeitdruck, Ressourcenmangel oder externe Gesetzgebung.

Ich habe an der WU vermutlich um die zwei Millionen Zeilen Code geschrieben und dabei wohl jeden Fehler begangen, aber – anders als externe Berater – diese auch selbst ausbaden müssen. Ich habe mich in unzähligen Umgebungen (Webanwendungen, Data Warehouse, Zutrittskontrollsysteme, Smartcards, SAP FI/CO und HCM, Kiosk Terminals) und Programmiersprachen (Python, JavaScript, Perl, PL/SQL, C, ABAP, Java, PHP) ausgetobt.  Ich habe viel gelernt und habe nun ebenso viele Ideen.

ddd
“Wie gründe ich eine GmbH?”, angewandte Komplexitätsreduktion: Mein Weg zur eigenen Firma.

Ich werde mich dem Thema Komplexität widmen – sei es als Berater, Entwickler oder in einer gänzlich anderen Rolle. Die Nachfrage danach ist jedenfalls enorm.

What’s in a name, what’s in a logo?

Abschließend nun ein wenig Namens- und Logo-FengShui, weil ich sehr oft gefragt wurde, was denn c99 zu bedeuten hätte.

dfh
Logo und Subline der c99 Business Services GmbH.

Das c steht für 100 Begriffe wie createconsult, code, communicatecompete oder cooperate – jedenfalls nicht für complicate. Den guten 99 will ich mich widmen, complicate gilt es zu verhindern. Außerdem sind die 99 eben nicht 100 – für manche hat das den Touch von unfertig, für mich von Effizienz und Pragmatismus. Aber wer beim nächsten Waschmitteleinkauf 10,99 zahlt und dabei an c99 denkt – auch ok.

Das Logo wiederum spielt mit einer Referenz zur Chemie: Unsere physische Welt besteht aus lediglich knapp über hundert Elementen. Die unglaubliche Vielfalt wird erst durch Kombinationen dieser wenigen Einzelteile erreicht. Modularität spielt jedenfalls auch in der IT eine herausragende Rolle. Die stilisierten Atombrücken – in der IT würde man sie Interfaces nennen – stellen diese Kombinationsmöglichkeiten dar.

Und ganz nebenbei: Das kleine c ist der 99. Buchstabe im Unicode.

tltr;

Mathias ist jetzt selbständig. Abseits des esoterischen Namens und Logos bestehen inzwischen echte Umsätze.

Webseite der c99 Business Services GmbH

IT project management

Campus WU: Drei Jahre in drei Minuten

Drei Jahre intensive (Projekt-)Arbeit, oder physikalisch ausgedrückt: Große Masse mal hoher Geschwindigkeit mal viel Weg.

“Man muß ins Gelingen verliebt sein, nicht ins Scheitern.”
Ernst Bloch

Door Signs

Über 200 Stück am gesamten Campus verteilt: Starten und aktualisieren sich über Netzwerk, gehen nachts schlafen, lesen Blinden die Belegung vor und kosten dabei ein Viertel der ursprünglichen Planung.

hj
61 der über 200 Displays vor Ort. Die angezeigte MAC-Adresse diente als Key bei der Inbetriebnahme.

Blogs dazu:

Self Service Terminals

Zehn Selbstbedienungsautomaten vor dem Study Service Center: Eine technische Herausforderung, barrierefrei, verbesserte Usability und – nach wahnsinnig stressiger Inbetriebnahme – inzwischen stabil.

bsfdb
Zwischenzeitlich haben tausende Studierende die Self Service Terminals im Library Center genutzt. (Sechs Terminals im Bild mittig; © Mathias August 2013)

Blogs dazu:

Final-Teilnahme beim Niederösterreichischen Innovationspreis.

Rooms

Dezentrale Raumbuchung für knapp 30.000 Benutzer_innen: Inhaltlich ist es Logistik pur samt dynamischer Lagerhaltung, Simulation, Statistik und passenden Visualisierungen. Rein technisch eine Herausforderung in JavaScript.

fff
Screenshot: User Interface der Raumbuchung für Studierende.

Blogs dazu:

Byte Bar und Leitsystem Terminals

fgfg fg
Die ByteBar- und Leitsystem-Terminals vor der Montage am Campus WU; Codename “Super-Toblerone”.

Surfstationen mit Login mittels berührungsloser Karte; Touchschirm, barrierefrei. Das Schwesterprojekt “Leitsystemterminal” dient zur Orientierung am Campus.

Blogs dazu:

API

gsg
Digital Signage Screens, die prominentesten Kunden unserer Lehrveranstaltungs-Daten API.

Viele unserer Daten sind – auch öffentlich – über Programmierschnittstellen verfügbar. So greifen alle hier beschriebenen Services auf dieselben Daten zurück, überall liest dieselbe Stimme Blinden vor, überall läuft dieselbe Logik, das Design ist gleich: managing complexity eines übergroßen Projekts eben.

Identmedien RFID

Eine Studierende holt sich einen Ausweis, verschließt ihre Sachen in einem der 3.600 Spindkasteln, bezahlt anschließend bargeldlos in der Mensa und öffnet einen gebuchten Projektraum: Keine Selbstverständlichkeit, läuft aber (immer besser).

Campus GIS

Geo-Informationssystem des Campus WU: Verortung von Personen und Organisationen, Suche nach POIs, Modellierung eines Routingnetzwerks zur Navigation, Flug einer Drohne für hochauflösende Luftbilder. Tool live: gis.wu.ac.at

Detaillierte Pläne, Suche, Routing bis hin zum Buch
Im Screenshot: Detaillierte Pläne der Regale zum Auffinden von Büchern in der Universitätsbibliothek.

Thanx + Uff!

Gerne würde ich hier behaupten, ich hätte das Alles programmiert, habe aber dann doch oft nur E-Mails geschrieben oder bin in endlosen Meetings gesessen. Ich musste langweilige Ausschreibungstexte querlesen, extern erdachte Konzepte ertragen, Kostenschätzungen durchs Haus schicken, Ideen verteidigen und am Widerstand Dritter scheitern sehen… Vier Befestigungsschrauben meiner Terminals kosteten mich so ein halbes Jahr Abstimmungsaufwand.

Als im Feuer getaufter Planerschlossertischlerdesignerentwickler kann ich nun verorten, kollaudieren, ausschreiben, beschaffen, eintakten, einbringen, einkippen, und Katzen hüten. Ich habe am Weg viele beeindruckende Menschen kennengelernt und dafür bin ich dankbar.

Es war ein Heidenspaß, ein Riesenstress und manchmal auch ein Mordsärger, vor allem aber war’s einzigartig und großartig. Wann und wo wird also der nächste Campus gebaut?

hacks

Project visualization with redesigned Gantt charts

When reading the Edward Tufte forum on Project Management Graphics I was surprised (and relieved) that a lot of people seem to have their problems with Gantt charts and their doubtful usefulness for project management.

After some thoughts on the topic I’d like to present my proposal for visualization of project flows. In case it matters: I’m currently part of a half a billion Euro construction project in Austria.

The real world example

The image below shows one Gantt chart of the project I’m currently involved in.

dfgh
Actual Gantt chart of “my” current project.

Aside from its professional look it transports surprisingly little content. My main points of criticism are:

  • On the one hand, with more than a hundred tasks on the left I get overwhelmed by things I’m not responsible for anyway.
  • On the other, my 15 tasks lack important detail.
  • Since it’s not possible to combine overview with sub-project specific detail I have to manage my tasks in parallel.
  • I easily lose track between tasks and the bars on the far right. Gridlines would be a bad idea as well since they add too much clutter.
  • Data is sparse and the chart needs too much space for the presentation thereof.
  • In my context of software development the chart’s implicit focus on sequential, waterfall-like project flows does not fit my reality of ever-changing project plans.
  • I definitely need to print it out to be able to use it.

What would I need?

First of all: Everybody can read a Gantt chart so let’s stick to some reasonable habits: bars that encode project duration by length and diamond symbols that mean milestones, i.e. important dates.

When I think of project management, the whole story is about one core task: Align your output and handover dates with those of others.

As a member of any project team I simply cannot be interested in the task of each individual. However the Gantt chart’s focus lies on the presentation of single tasks. I state that any visualization for project management should focus on people or teams, i.e. responsibilities, rather than tasks.

My second point revolves around overview and detail: My own tasks should be presented in greater detail than data of other teams. My only concern with them is deliverables when we approach mutual handover dates.

The Redesign

Here’s some example data taken from one of my schedules:

Responsible Task Start End
Construction Define location Sun Jan 01 2012 Sun Apr 15 2012
Construction Finish site Thu Aug 01 2013 Milestone
IT Develop prototype Sun Jan 15 2012 Sat Jun 02 2012
IT Testing Sun Jun 03 2012 Sun Jul 01 2012
Business Process Give feedback Sun Jun 03 2012 Sun Jul 01 2012
Supplier Deliver parts (prototype) Thu Mar 01 2012 Sun Aug 05 2012
IT Update integration Sun Jul 01 2012 Tue Aug 14 2012
IT Evaluate prototype (hands-on) Wed Aug 15 2012 Mon Oct 01 2012
IT Evaluate prototype (remote monitoring) Tue Oct 02 2012 Wed May 01 2013
IT Production Mon Aug 19 2013 Wed Jan 01 2014
Business Process Launch prototype environment Wed Aug 15 2012 Milestone
Business Process Go live Mon Aug 19 2013 Milestone
Procurement Procure Mon Apr 01 2013 Wed May 01 2013
Supplier Deliver parts (production) Wed May 01 2013 Mon Aug 12 2013

Classic Gantt chart

And here goes the corresponding Gantt chart:

srg
Gantt chart encoding the tabular data above. (Written in JavaScript).

My version, aka: Gantt90

My enhanced version is shown below. Instead of single tasks I only show the responsible team. Additionally I rotate by 90 degrees – thus Gantt90 – to shift the attention from process flow to responsibility, from a mechanical point of view to a more social one if you want to put it like this.

While the information conveyed is almost equal, the charts size is halved. Hence even the thumbnail becomes readable.

dsf
Proposed redesign of a Gantt chart: teams instead of tasks and rotation by 90 degrees.

Adding detail

Since I’m a member of IT, the two blue bars on the right should now convey more information than the others. I do that by highlighting my team and showing the specific tasks along the time axis. Enough detail for the team, and I manage to simultaneously keep track of other teams’ schedules.

sd
Overview and detail combined. The chart could even be made recursive with sub-teams of IT on the right. (…)

Thinking of my big example from the beginning it will be necessary to further divide the detail view on the right. Since projects – tasks as well as teams responsible – fit into hierarchical, tree-like data structures my chart would recursively expand to the right. (IT would then be divided into developers, testers, administrators, etc. and the new chart would resemble its left neighbour – both aligned with the common time axis.)

What about connecting lines?

You may have noticed that I skipped the connecting lines between the taks. I’m convinced that a proper visualization should signalize the project’s inherent structure on its own. Even if the lines are not there, you can see the dependencies between tasks and/or milestones anyway. Your brain does quite a good job at pattern recognition.

tldr: Like spreadsheets, Gantt charts are used to visualize business fiction rather than to manage projects. I’ve proposed a modified Gantt chart to better visualize projects by drawing attention to responsibility rather to single tasks.

Thanks to Elena Reitman’s tweet I stumbled upon the Tufte forum.

I highly recommend the book Envisioning information by Edward Tufte. The charts and the source code used can be found here.

IT project management

Checklist Softwareauswahl

Knappe eineinhalb Jahre vor Inbetriebnahme des Campus WU werden aktuell zahlreiche Softwareprodukte unterschiedlicher Größe beschafft. Software ist durch ihre nicht überschaubaren Anwendungsmöglichkeiten komplex, die Auswahl des richtigen Produkts daher keine triviale Aufgabe.

Im Zuge der Beschaffung eines Geoinformationssystems (GIS) fand allerdings ein Bilderbuchbeispiel für einen strukturierten Entscheidungsprozess seinen Weg bis zur Vertragsunterzeichnung; ein Beispiel, das ich in abstrakter Form hier gerne teile.

Ausgangspunkt

Wir kaufen also Unternehmens-Software: Diese ist im Jahr 2012 beinahe immer webbasiert, oder zumindest in einer three tier architecture umgesetzt. Das Unternehmen möchte die Gesamtkosten (total cost of ownership) minimieren, dabei aber dennoch eine ausreichend gute Software einführen.

Im Studium lernte ich die Nutzwertanalyse als Werkzeug bei derartigen Entscheidungsprozessen kennen. Als ich sie vor Jahren zum ersten Mal anwenden wollte, erlebte ich allerdings zahlreiche Probleme: Die Punktevergabe samt Gewichtung gaukelt ein genaueres, transparenteres Ergebnis vor, als es tatsächlich ist. Gewichtungen werden oft auch noch nachträglich verändert. Die Betriebswirtschaftslehre nennt das Sensitivitätsanalyse, in der Praxis ist das eher ein Hintricksen zum gewünschten Ergebnis.

Was ich an Methoden agilen Projektmanagements mag, ist weniger die Fähigkeit, Prozesse vielleicht besser steuern zu können, sondern die im Lieferumfang enthaltene Transparenz mit der Unsicherheit und Ungenauigkeit nach außen hin als solche deklariert werden.

Soll heißen: Ich präsentiere hier eine absichtlich zur Checklist verkommene Nutzwertanalyse, weil jedes mehr an Datenpunkten, lediglich mehr Zahlenspiel als sinnvolle Entscheidungsgrundlage bedeutet. Anstatt Punkten und Gewichtungen treten nur noch drei Zustände: KO, entscheidend, relevant. Während KO als Filter zu sehen ist, sind die beiden letzteren rein qualitative Aussagen: “Dieses Kriterium ist entscheidend und Anbieter A ist da wohl ein wenig besser” – mehr ist nicht möglich.

Nutzwertanalyse “light”

Zuerst zur Software selbst
  1. Erfüllt die Software alle meine mir jetzt bekannten Anforderungen? Gibt es zumutbare Workarounds für fehlende Anforderungen?
    (KO-Kriterium)
  2. Kann die Software deutlich mehr, als ich es will? Paradox: Je mehr unnötige Funktionalität geboten wird, desto schlechter!
    (siehe: Complexity kills!, entscheidend)
  3. Können alle künftigen Endanwender den Client verwenden oder gibt es Einschränkungen bei Browserversionen und/oder Betriebssystemen? Gilt dies auch noch künftig in meinem Unternehmen?
    (KO-Kriterium)
  4. Falls ein mobiles Szenario existiert: Ist der Service mobil nutzbar?
    (relevant)
  5. Ist eine zentrale Authentisierung (Login mit unternehmensweitem Passwort) möglich?
    (KO-Kriterium)
  6. Ist eine zentrale Autorisierung (Übernahme zentral gepflegter Berechtigungen) möglich?
    (relevant)
  7. Falls ein älteres System abgelöst wird: Können Daten übernommen werden?
    (entscheidend)
  8. Wie schätze ich die wirtschaftliche Situation des Anbieters ein? Wird es ihn in fünf Jahren noch geben? Ist sein angebotenes Produkt für ihn selbst wichtig oder wird mir ein Auslaufmodell angeboten? (Product Roadmap) Wie stark ist letztlich meine Abhängigkeit?
    (entscheidend)
    ODER
    Handelt es sich um Open-Source Software? Gibt es andere Anbieter, die auf Basis dieser Software Dienstleistungen anbieten?
    (relevant. Das bedeutet, dass dieser Punkt im Falle von OSS weniger Tragweite erhält.)
  9. Liegen die Daten in einem lesbaren Format vor, oder sind sie im System des Anbieters gefangen?
    (entscheidend)
  10. Kann ich das System (notfalls) selbst administrieren? Gibt es ausreichend Angebote für Dienstleistungen (Beratung, Support, Administration), wenn möglich auch von anderen Anbietern?
    (entscheidend)
  11. Gibt es Referenzen? Habe ich Erfahrung von anderen Installationen des Anbieters in meiner Branche? Welches Feedback ergibt eine Netz-Recherche?
    (relevant)
  12. Was sagen meine Endanwender? Hat Ihnen die Produktpräsentation gefallen? Gefällt ihnen die Software?
    (arrogant, aber: beinahe irrelevant)
  13. Bietet das System offene Schnittstellen für Daten und/oder Automatisierung?
    (entscheidend)
  14. Erfüllt das System meine Sicherheitsanforderungen hinsichtlich Architektur, Datenhaltung, Verschlüsselung, usw.? Ist das Angebot “in der Cloud” bzw. gebe ich unternehmenskritische oder datenschutzrechtlich sensible Daten in fremde Hände?
    (KO-Kriterium)
  15. Darf ich das System in dieser Form einsetzen, oder spricht geltendes Datenschutz-Recht dagegen? Besitze ich eine Meldung beim DVR oder ist gar mit einer Ablehnung zu rechnen?
    (realistischerweise lediglich relevant)
  16. Passt die vom Anbieter vorgeschlagene Vorgehensweise bei der Einführung zu Kultur und Ressourcen meines Unternehmens? Sind etwa Schulungen zeitlich möglich? Wissen alle Stakeholder überhaupt von ihren künftigen Rollen?
    (relevant)

Man sieht, in meiner Auflistung fehlen zentrale Punkte, die normalerweise (stärker) repräsentiert sind. Dazu zählen etwa die Zufriedenheit der Nutzer oder die technische Ausgereiftheit des Produkts.

Bei einer Produktpräsentation etwa bewerten Endanwender eher die sympathische Art des Beraters, nicht aber das Produkt selbst. Bewerten sie in Ausnahmesituationen doch die Software anstatt der Powerpoint-Präsentation, lassen sie sich vom GUI blenden und schaffen es de facto nie, das Gezeigte zu abstrahieren und in ihre Arbeitswelt zu überführen.

Doch auch IT-Spezialisten sind schlecht im Bewerten: In zehn Jahren IT habe ich festgestellt, dass in Systeme nicht hineingesehen werden kann. Die traurige Nachricht lautet, dass man alle Probleme am eigenen Leib erleben wird, bevor man sie mühsam lösen muss. Dabei gibt es kaum Unterschiede zwischen Open Source und kommerzieller Software: Bei ersterer ist tendenziell mehr Expertenwissen bei der Problemlösung vonnöten – bei höheren Erfolgsaussichten -, bei zweiterer sind zeitlicher Aufwand (Support-Hotline!) und monetärer Einsatz (Beratertage) weitaus größer.

Den Reifegrad einer Software anhand des Namedroppings von Programmiersprachen, Protokollen, Datenbanksystemen, Dateiformaten, usw. feststellen zu wollen, ist blanker Unsinn. Verwendete Technologie und Qualität korrelieren äußerst schwach. Die Eckpunkte von Softwarequalität lauten Entwicklungsprozess, automatisiertes Testen, Sourcecodemanagement, Erfahrung & Motivation, … – alles Dinge, die von außen gänzlich unsichtbar sind.

… und dann das Geld

Nun zu den Kosten: Diese sind bei Hardware und Lizenzen zwar noch vergleichbar, aber oft stellen Schulungen, Beratungsleistungen, Support u.ä. ein großes Problem dar. Veranschlagt ein Anbieter etwa das Doppelte für Beratungsleistung, kann es gleich mehrere Gründe dafür geben: Das System ist schwieriger einzuführen, die Berater sind teurer, der Anbieter ist vorsichtiger bezüglich des Projektfortschritts, usw.

Ein möglicher Ausweg ist die Aufschlüsselung der Kosten in angebotene Gesamtstunden und Stundensatz. Der Median der angebotenen Stunden (über alle Angebote hinweg) ist zunächst die beste Näherung für den Aufwand. Mit dem jeweiligem Stundensatz multipliziert kommt man so zu normierten Angeboten hinsichtlich der Dienstleistungen.

Diese so errechneten (fiktiven!) Angebote sollten Basis eines Preisvergleichs sein.

Eine Pattstellung zwischen zwei Anbietern ist aufgrund der bestehenden Unsicherheit nach wie vor äußerst wahrscheinlich. Möglicher Ausweg hier: Beauftragung beider Anbieter mit einer in maximal acht Wochen durchführbaren Pilotphase bei voller Transparenz des Modus und fairen Bedingungen.

Diese Vorgehensweise stellt die beiden Anbieter in direkten Wettbewerb. Man kann davon ausgehen, dass die “Motivation” auf beiden Seiten hoch sein wird. Auch im nachfolgenden (Groß-)Projekt – wenn dann die Auswahl letztlich getroffen ist – kann das Ergebnis der Pilotphase als Qualitätsreferenz dienen. (Der Anbieter legt sich selbst eine hohe Latte.)

Während die Methode bei kleineren Beauftragungen übertrieben scheint, stellt sie bei wichtigen Projekten eine probate Möglichkeit dar, Entscheidungsunsicherheit tatsächlich zu reduzieren.

hacks

Service Terminal Plus, oder wie ich lernte, Automaten zu bauen

Das für Außenstehende wohl spannendste, weil greifbarste, Projekt meiner Tätigkeit ist das Service Terminal Plus. Mit beinahe 500.000 Euro Budget geht am Campus WU der Nachfolger der heutigen Selbstbedienungsterminals in Betrieb. Zeit für einen Erlebnisbericht, der sich für mich wie eine Hintergrundgeschichte zur (zweiten) Mondlandung schreibt…

Beim Service Terminal Plus handelt es sich um einen interaktiven Terminal, der RFID-Leser, Kartendrucker, Touchscreen, Webcam, Bezahlfunktion für Bankomat und Kreditkarte, Ausdruck auf Normal- und Zeugnispapier im A4-Format, zusätzlich Rechnungsdruck auf Thermopapier sowie Lichtsteuerung vereint. Kein Wunder also, dass der interne Codename des Projekts Riesenkrake lautet, besitzt der Automat wie sein tierisches Vorbild (mindestens) acht Arme und neun Gehirne…

Aktuelle Version der SB-Terminals an der WU Wirtschaftsuniversität Wien: Foto für den Ausweis, Rückmelden inkl. Bezahlen, Ausdruck von Zeugnissen und Bestätigungen.

Die aktuellen SB-Terminals wurden 2001 von Siemens geliefert, zwischenzeitlich mussten einige Hardwarekomponenten getauscht werden. Die Software wurde 2006 aufgrund vieler Ändeurngswünsche komplett neu in-house entwickelt.

Dank der in zehn  Jahren Betrieb gesammelten Erfahrung wollen wir nun einen Automaten bauen, der in seiner Wartbarkeit deutlich verbessert wird. Die spannendsten Änderungen spielen sich allerdings auf Seiten der Benutzungstauglichkeit ab, wo wir in den vergangenen Monaten einige interessante Ideen geboren, aber vor allem auch zur Reife gebracht haben.

Künftiger Standort ist das LLC am Campus WU. Wir nehmen Anleihe an der Architektur und holen den "Geist des Gebäudes" ins Projekt.
Eine der ersten Studien zum Service Terminal Plus.

Barrierefreiheit: Einer für Alle!

Ein Thema, das keinesfalls zu kurz kommen darf, lautet Barrierefreiheit. Die bisherige Lösung bot zehn Terminals für normale Menschen und einen für Behinderte.

Wem sich beim vorigen Satz auch der Magen umdreht, mir geht’s genau so.

Wir wollen weg vom Separieren von Menschen mit Behinderungen hin zu Gleichbehandlung. Das heißt im konkreten Fall, alle Terminals werden (mit Kompromissen) barrierefrei sein. Das bedeutet aber auch, dass viele Studierende sich werden bücken, Rollstuhlfahrer eben auch strecken müssen. Mir gefällt der Ansatz, etwas fundierter nennt sich das Inklusion.

Die Bedienelemente werden auf einem Kragarm platziert, der für Rollstühle unterfahrbar ist.

Zielsetzung mit dem nächsten Protoypen wird unter anderem sein, Rollstuhlfahrer testen zu lassen, um so zu verwertbarem Feedback abseits abstrakter Gesetzesnormen zu kommen.

Technische Neuerungen

Doch auch technisch wird sich viel tun. Seit Smartphones und Tabs will niemand mehr einen resistiven Touchschirm bedienen – die neue Generation ist kapazitiv und bietet deutlich erhöhten Bedienkomfort. Teure, weil vandalismussichere Tastaturen sind dank dieser Technologie ebenso Geschichte – das erledigt neuerdings die Software.

Die größte Innovation scheint uns aber im Bereich des Druckens zu gelingen: Während in der aktuellen Version immer wieder Papierstaus auftreten, glauben wir, das Problem nun endgültig geknackt zu haben. Dank Modifikation des Beförderungsmechanismus wird der Drucker rückwärts verbaut. Das bedeutet, dass künftig sämtliche Wartungsarbeiten von hinten durchgeführt werden, während vorne das User Interface keine Ladeklappen benötigt, also “clean” bleibt. Gemäß dem alles beherrschenden Motto “Was nicht existiert, geht nicht kaputt”, kann Papier nirgends mehr stecken bleiben. Es fällt einfach nach unten in eine Lade.

Das Innenleben eines Lexmark T652dn: Wir ändern die Richtung des Papierauswurfs und erreichen: Drucken vorne - Nachfüllen hinten.

Einheitliches User Interface (UI)

Als Softwareentwickler denke ich bei UI vorrangig an das, was sich letztlich am Bildschirm tut. Doch beim Service Terminal Plus ergeben sich durch den Möbelbau ungeahnte Möglichkeiten: Wie am Foto der aktuellen Generation erkennbar, ist das physische UI zurzeit stark zerklüftet. Drucker, Bankomatkassa und Kartenleser befinden sich in einem separaten Möbelstück rechts des Bildschirms. Der Zahlungsbeleg hingegen wird unterhalb des Bildschirms gedruckt, weit weg also vom eigentlichen Bezahlvorgang. Zumindest ich finde so etwas verwirrend.

Am Mockup des Möbelbauers werden die Komponenten verortet. Zusammengehöriges wird mittels Fräsung umrandet und dadurch zusammengefasst. Eine Lichtsteuerung leitet schließlich den Benutzer von Bedienfeld zu Bedienfeld.

Agil versus legal, oder: Grenzen des Outsourcings

Wie auf den Bildern erkennbar haben wir Spezialmöbelbauer im Team, mit denen die Zusammenarbeit auf Basis von Mock-ups abläuft. Es ist unglaublich hilfreich und effizient, ein Projekt anhand eines an-greifbar-en Prototypen zu be-greifen, anstatt detailliert zu planen. Das Gesamtprojekt ist schlicht zu komplex, als dass man es abschließend spezifizieren könnte. Trial and Error ist hier der richtige Weg.

Eine der größten Herausforderungen des Projekts liegt daher weitab aller technischen Sphären: im Vergaberecht, an das sich öffentliche Auftraggeber halten müssen. Beschaffungen ab gewissen Schwellenwerten haben über Ausschreibungen zu erfolgen. Was etwa bei Standardmöbeln zu transparenter und effizienter Haushaltsführung führt, stößt bei derartigen Spezialthemen an Grenzen. Die Aufgabe lautet daher, gemeinsam mit einem vertrauenswürdigen Partner ein Produkt zu entwerfen, dass später als Referenz für eine Ausschreibung an einen unbekannten Bieterkreis dienen soll. Im Regelfall stellt sich diese Schwierigkeit nicht, da oft so genannte Integratoren wie IBM oder eben Siemens eine Gesamtleistung anbieten. Die Erfahrung lehrt uns aber, dass es viele Themen gibt, die besser in-house gelöst werden, da ein komplexes Projekt nicht beliebig auf Externe verteilbar ist.

Getting real!

Wer sich von den Entwicklungen aus nächster Nähe überzeugen will: Bereits im Sommer 2012 soll “Nummer 1” noch am Altstandort in Betrieb gehen. Dann wird sich zeigen, ob sich die vielen, vielen Arbeitsstunden hinter Monitoren, Mock-ups und Kaffeemaschinen rechnen…

ideas

Von Software-Qualität und Eisbergen

In Kürze gehen zwei unserer Anwendungen in Testbetrieb (gebloggt und nochmal gebloggt). Nach wochenlanger Entwicklungsarbeit naht nun der Moment, den ich so hasse: der Moment des ersten, überhasteten Feedbacks.

Ich will diesen Moment als Eisberg-Moment bezeichnen. Er findet da statt, wo Endbenutzer oder Auftraggeber erste Rückmeldungen zum Softwareprodukt liefern. Rückmeldungen, die lediglich die sichtbaren Merkmale der Software betreffen und somit den Großteil der Anstrengungen außer Acht lassen.

Auch wenn Usability-Leute behaupten, the interface is the product, dann ist das nur die halbe Wahrheit. Insbesondere über einen Bewertungszeitraum, der länger als fünf Minuten – in unserem konkreten Fall hoffentlich mehr als fünf Jahre – dauert, spielen ganz andere Faktoren die Hauptrolle:

  • Investitions- und Wartungskosten; die IT ist schließlich ohnehin personalintensiv.
  • Wartbarkeit
  • Security
  • Verfügbarkeit
  • Konsistenz/Integrität
  • usw. (…) Nur eben nicht Logos, Schriftarten und oder Ränder drumherum.

Kurzum, mein Kollege Dennis und ich haben den Eisberg auf einem Whiteboard verewigt. Unter der Oberfläche liegen die unbeachteten Merkmale von Software-Qualität. Auf der x-Achse haben wir die investierte Arbeitszeit aufgetragen; auf der y-Achse (zugegeben etwas sarkastisch) das Geld, das man mit den jeweiligen Services verdienen kann.

Qualitätsmerkmale von Software(-projekten) und was davon für Außenstehende sichtbar ist. Der "Eisberg-Moment", ein künftiger Management-Klassiker.

Der Eisberg-Moment ist übrigens das Gegenteil des black triangle moments.

Edit 1: Ich bin übrigens der Meinung, dass Feedback wichtig ist. Es sind nur diese ersten Rückmeldungen, die mich immer und immer wieder an den Rand der Verzweiflung treiben…

Edit 2: Passend zum Thema, dass Feedback qualitativ sehr unterschiedlich sein kann: TornadoGuard bei xkcd.