Seitdem das bayrische Wirtschaftsministerium den Startschuss für den Digitalbonus freigegeben hat, denken viele Unternehmen darüber nach, wie sie diese starke Förderung sinnvoll nutzen können. Und diesen Bedarf hat auch jedes Unternehmen. Es gibt überall Probleme, bei denen eine kleine Softwarelösung doch richtig schick wäre. Und warum bis zu 50% Förderung verschenken? Aber was sind eigentlich Projektbeschreibungen? Wie unterscheiden sie sich inhaltlich?

Inhalte von Projektbeschreibungen

Wer sich die Projektbeschreibungen von neuen individuellen „digitalen Software-Projekten“ näher angeschaut, erkennt schnell bei sehr vielen eine Gemeinsamkeit. Eine Vielzahl von Projekten beschäftigt sich damit, analoge Prozesse abzulösen. Das ist gut. Und das ist auch eine Idee der Digitalisierung – allerdings ist diese Idee nicht vollständig. Wenn man analoge Prozesse durch digitale ersetzt, kann man sich schon über eine Vielzahl von sinnvollen Vorteilen freuen: Es können Automatismen integriert werden, sodass Prozesse nun nicht mehr „stehenbleiben“, sondern tatsächlich vorangetrieben werden. Die Daten liegen nun persistent in einer Datenbank und können jederzeit wieder angefragt und verwertet werden. Doch genau da liegt das Problem. Denn viele sehen dieses „könnte man“ nicht. Wenn Daten bereits digitalisiert vorliegen, kann man nicht nur interne Prozesse optimieren, sondern auch externe oder gar neue Prozesse, die zu neuen Geschäftsfeldern führen, erschaffen. Es ist zum Beispiel immer eine Überlegung wert, ob die neue Softwarelösung nicht auch eine bessere Interaktion zum Kunden bieten kann, z.B. durch Schaffung von Transparenz wie Lieferverfolgung.

Jeder Nervtöter hat Potenzial zur Innovation

In der digitalen Transformation steht die Innovation im Vordergrund. Das Rad soll dabei nicht neu erfunden werden, aber warum nicht etwas erfinden, wo das Rad ein Teil davon ist? Aus dem beruflichen und privaten Alltag kennt jeder Situationen, in denen er Fragen auswirft wie „Was soll das denn?“, „Muss das jetzt sein?“ oder „Jetzt reichts mir aber, Zefix!“. Stop! Und genau das sind die Momente, aus denen bereits erfolgreiche Startups hervorgegangen sind. Sei den Startups der Erfolg vergönnt, aber warum trauen sich etablierte Unternehmen aus dem Mittelstand nicht an diese Problemzonen im Leben heran? Innovation bedeutet nicht, dass es ein untragbarer finanzieller Aufwand ist. Wenn der Gedanke Form annimmt, kann man sich über den technologischen Aspekt noch in Ruhe Gedanken machen und verschiedene Lösungswege untereinander vergleichen.

Lassen Sie sich reizen!

Mit diesem Gedanken sollten Sie sich auf den Moment freuen, wo das nächste mal die Zornesfalte auf der Stirn anschwillt. Der Moment, wenn die Stimme laut wird, die Hände verzweifelt in die Höhe geworfen werden und Sie sich schlichtweg fragen „Was soll der Sch***?“. Holen Sie Kollegen dazu und schimpfen Sie erstmal gemeinsam auf das, was den kollektiven Unmut hervorruft. Doch bitte schreiben Sie all diese Punkte, die für Unmut sorgen, auf. Schnell kommen dann auch Sätze wie „Bei dem Programm x funktioniert sowas besser, die machen das und das“ – schnell auch das aufschreiben! Das ist Ihre Grundlage, um das Problem in den Griff zu bekommen.

Kein Frust ins Konzept einarbeiten

Wenn Sie nun versuchen, den Unmut aus dem Kollegenkreis und die Wünsche, die geäußert wurden, zusammenzubringen, sind Sie bereits in der Konzeptphase drin. Wichtig ist hier allerdings, dass Sie da strategisch und analytisch vorgehen. Frust zerstört sachliche Analysen. Oft hilft es auch, sich an ein Whiteboard zu stellen und die Interessen der verschiedenen Stakeholder darzustellen. Wer ist denn alles betroffen und flucht immer wieder? Wer flucht nicht? Geht es bei dem Unmut manchmal auch um interne Konflikte oder um einen Prozess, der einfach nur umgestellt werden muss? KANN ein Prozess mit den gegebenen Mitteln überhaupt vollständig abgebildet werden oder muss hier ergänzend eingegriffen werden? Schnell erhalten Sie ein komplettes Bild von dem, was da ist, und dem, was fehlt.

Den Mehrwert erkennen

Nur den Frust und das Gefluche aller Mitarbeiter zu minimieren, sollte aber nicht das Ziel eines Konzeptes sein. Sicherlich ist dies ein großer Faktor, denn nur zufriedene und motivierte Mitarbeiter sind auch gute Mitarbeiter, die mit Freude und viel Engagement Ihre Arbeiten verrichten. Dennoch denken Sie bitte auch wirtschaftlich: Welchen Mehrwert bringen Anpassungen einer Software oder die Einführung einer neuen Lösung? Wo kann Zeit gespart werden, und wieviel? Wo sind Informationen eine wichtige Quelle, und warum? Kann man auf Grundlage der Informationen vielleicht sogar Voraussagen treffen?

Fazit

Unmut sorgt für Unproduktivität. Nutzen Sie lieber die Energie, die durch Unmut frei wird und überlegen Sie bei der Lösungssuche, ob man hier nicht noch mehr rausholen kann, als einfach nur das Problem in den Griff zu bekommen.

Der Erstkontakt beim Kunden ist das Wichtigste. Nicht nur, damit man sich kennenlernt. Nicht nur, damit man ein Gesicht zum Namen hat. Es ist vor allem deshalb wichtig, weil der Kunde genau hier das erste Mal erzählt, wo ihm der Schuh drückt. Wer da nicht genau zuhört, kann ein Konzept komplett in die falsche Richtung lenken.

Der erste Kontakt

Nachdem beide Parteien sich brav vorgestellt haben und nun jeder weiß, was die Stärken des anderen sind, in welchen Märkten man sich bewegt etc. kommt der eigentliche wichtige Teil. Der Teil, der später wieder schnell vergessen wird, verdrängt von weiteren Besprechungen, Telefonaten und Emails. Der Kunde wird erzählen, was ihn an der Ist-Situation stört. Und hier beginnt der Teil, bei dem der Software-Dienstleister genau zuhören sollte. Denn hier werden die Probleme geschildert, für deren Lösung sich der Kunde vertrauensvoll an das Unternehmen gewandt hat. Der Kunde hofft darauf, dass der Dienstleister ihn versteht und seinem Elend ein Ende bereitet.

Zuhören und verstehen – der große Unterschied

Da gibt es keinen Unterschied? Oh doch, den gibt es sehr wohl. Diesen Unterschied leben wir bei der WOGRA in allen Software-Projekten. Der Unterschied beginnt bei der Involvierung des kompletten Teams, das für das Projekt verantwortlich ist. Auch der Werkstudent, der nur einen kleinen Teil der Implementierung übernimmt, soll wissen, warum dieses Projekt dem Kunden einen Mehrwert liefert. Der Unterschied geht weiter über das Konzept. Wir hören nicht nur zu und erarbeiten dann ein Konzept, sondern wir gehen auch hier iterativ mit Prototypen vor. Der Kunde kann so immer wieder evaluieren, ob die vorgeschlagene Lösung genau die richtige ist oder nicht und wir arbeiten dieses Feedback ein. Am Ende steht ein Konzept, bei dem wir durch viele Gespräche mit dem Kunden genau verstanden haben, warum dies und das eben doch nicht die Lösung seines Problems ist. Gut, dass da nicht gleich nach dem Zuhören ein fertiges Konzept erstellt wurde. Der Unterschied endet auch nicht in der Produktivsetzung. Genauer gesagt, endet er gar nicht. Sobald eine Software produktiv ist, halten wir engen Kontakt mit dem Kunden, um zu erfahren, wie gut das System in die internen Abläufe integriert werden konnte.

Featurewünsche richtig einordnen

Schnell werden nach Produktivsetzung die ersten neuen Featurewünsche geäußert. Der Mehrwert wird erlebt und es eröffnen sich weitere Möglichkeiten, wie die Software das Unternehmen noch besser unterstützen kann. Hier kommt wieder der Unterschied zum tragen, denn wer weiß, wie sein Kunde „tickt“ und was er mit der Umsetzung des Features eigentlich erreichen will, der kann auch das liefern, was der Kunde wirklich braucht.

Was der Kunde will – und was der Kunde braucht

Der Kunde will zunächst nur, dass ihm geholfen wird. Sein Problem soll beseitigt werden. Es macht den Eindruck, als wäre sowas ganz einfach. Ist es aber nicht. Denn der Kunde sagt selten klipp und klar, warum er dieses Problem beseitigt haben will. Welchen Mehrwert bringt es ihm? Wenn es dumm läuft, beseitigt man zwar das Problem des Kunden, schafft mit der Lösung aber gleich ein oder gar mehrere neue.

Ein Beispiel

Den Kunden stört seine lästige Excel-Tabelle. Ständig verändern die Mitarbeiter die Summen, weil sie sich nicht merken können, in welche Felder sie was eintragen sollen, damit am Ende die korrekte Summe berechnet werden kann. Die Mitarbeiter kriegen es einfach nicht auf die Reihe. Jetzt soll die Excel-Tabelle abgelöst werden. Sein Wunsch ist es, eine Webanwendung dafür zu bauen. So kommen die Mitarbeiter nicht mehr an die bösen Summenfelder ran, und können nix mehr kaputt machen. Im weiteren Gesprächsverlauf kommt heraus, dass einige Mitarbeiter eine eigene Version dieser Excel-Liste besitzen, in der sie Spalten umbenannt haben um sich besser zurecht zu finden. Oder sie haben sich eine eigene kleine Hilfstabelle gebaut, in der sie nur die Informationen verwalten, die für ihren Bereich wichtig sind und diese kopieren sie dann später in die große undurchsichtige Tabelle, die der Chef zur Auswertung braucht und die dann hinten und vorne nicht mehr stimmt.

Wer hats verstanden?

Wer nur zugehört hat, weiß, es soll eine Weblösung her, die die Excel-Tabellen ablöst, damit die Mitarbeiter die Business Logik dahinter nicht mehr zerstören können.

Wer allerdings verstanden hat, weiß, dass die Mitarbeiter total überfordert waren mit der Pflege der Excel-Tabelle. Und wer es verstanden hat, weiß auch, warum: Sie haben Datenfelder gesehen, die nicht in ihren Bereich gehören. Sie haben Business Logik gesehen, die sie nicht verstanden haben. Sie haben Spaltenbezeichnungen gelesen, die nicht in ihre Domäne gepasst haben. Dass eine Weblösung hier viele dieser Probleme in den Griff kriegt, ist eine Sache. Aber wer nur zugehört hat, der hat nicht verstanden, dass die Mitarbeiter scheinbar maßgebliche Probleme mit der Usability hatten. Wer nicht versteht, rennt beim ersten Prototypen oder gleich beim Konzept in die Falle, dass die Mitarbeiter später wieder überfordert sind und andere Probleme in der Handhabung der neuen Software haben. Wer versteht, berücksichtigt das gleich und kann sich sicher sein, dass der erste Prototyp bereits ein guter Weg zur Lösung des Problems ist.

Aber Design Thinking ist doch viel mehr!

Ja, da haben alle Experten Recht, die hier nun substanzielle Informationen zum Thema Design Thinking vermissen. Aber es gibt genug Fachartikel und Bücher dazu, die müssen wir nicht in einem einzigen Blog-Beitrag neu erfinden. Uns war und ist es wichtig, den Kerngedanken des Design Thinking in die Softwareentwicklung zu bringen, nämlich die Frage: Wo ist das Problem?

Design Thinking bei WOGRA

Die Frage nach dem Problem haben wir nicht nur beim Erstkontakt mit dem Kunden im Hinterkopf, sondern auch bei der Umsetzung der einzelnen Features. Nicht nur der Mitarbeiter, der das Konzept erstellt, trägt diese Frage immer mit sich herum, sondern auch jeder Entwickler. Bei der Implementierung hinterfragt auch jeder Entwickler, ob diese Umsetzung so Sinn macht oder ob ein anderer Ansatz für den Kunden besser wäre. Mit dieser flexiblen Feature Driven Entwicklung konnten wir bisher jedes Projekt so umsetzen, dass nicht hinterher eine Vielzahl an Änderungen gewünscht wurde, weil die Software nicht den gewünschten Mehrwert bringt. Was gewünscht wird, sind Erweiterungen, weil die Lösung, die wir präsentieren, die ist, die dem Kunden weiter hilft und bei der er sieht, dass sie noch viel mehr bieten kann.

Nearshore/Offshore? Gelegentlich werden wir von potenziellen Neukunden gefragt, weshalb sie WOGRA beauftragen sollten. Warum nicht ein viel günstigeres Unternehmen in Ost Europa, Indien, Pakistan oder Vietnam? Wenn wir diese Frage gestellt bekommen, dann hat uns der Interessent erst gerade eben kennen gelernt oder er hat unsere Philosophie nicht verstanden. Wir wollen in unserem Blog die Gelegenheit nutzen, um die WOGRA Besonderheiten heraus zu arbeiten.

Nearshore und Offshore – Barrieren beim Konzept

Dazu muss man wissen wie Nearshorer oder Offshorer arbeiten. In der Regel gibt es einen deutschen oder deutschsprachigen Ansprechpartner, der die Anforderungen beim Kunden aufnimmt und daraus im besten Fall ein Pflichtenheft erstellt. Hier wird es schon schwierig. Wird das Pflichtenheft in Deutsch verfasst und vom Kunden freigegeben, muss es anschließend in die Muttersprache der Entwickler oder ins Englische übersetzt werden. Dieser Übersetzungsvorgang kann zu Lücken führen. Alternativ kann das Pflichtenheft sofort auf Englisch geschrieben werden. Probleme können aber entstehen, wenn Mitarbeiter des Kunden nicht immer perfekt Englisch sprechen und somit unsicher sind, ob die Anforderungen korrekt und vollständig beschrieben sind.

Das Domänenverständnis und seine Tücken

Wenn man diese Hürde übersprungen hat und die Software umgesetzt wird, entstehen neue Herausforderungen. Denn um wirklich die Ziele des Kunden erreichen zu können müssen Entwickler die Möglichkeit bekommen Detailfragen klären zu können. Denn so aussagekräftig ein Pflichtenheft auch sein mag: Es wird immer Punkte geben, die geklärt werden müssen. Der Weg geht wieder über den deutschen Ansprechpartner wie beim Flüstertelefon mit Übersetzungsschwierigkeiten. Bei einer solchen Arbeitsweise hat ein Entwickler auch wenig Chancen die Domäne des Kunden kennen zu lernen und zu verstehen.

Nicht nur technisches Verständnis erforderlich – WOGRA denkt in Lösungen

Bei WOGRA suchen wir Entwickler, die sich in die Domäne des Kunden hinein denken, eigene Lösungsvorschläge bringen und weiteres Optimierungspotenzial in den Prozessen erkennen. Es ist uns wichtig, nicht nur effektiven und qualitativ hochwertigen Code zu entwickeln, sondern unseren Kunden Lösungswege aufzuzeigen, die sie selber vorher vielleicht noch gar nicht gesehen haben. Dieses Wissen und KnowHow können unsere Kunden nur effektiv nutzen, wenn sie eng mit uns zusammen arbeiten. Gut, dieses Argument kann man sicherlich etwas entlasten, indem man vom lokalen Ansprechpartner diese Leistungen erwartet, aber mehrere schlaue Köpfe erreichen meistens mehr als nur ein einziger. Auch später, wenn ein Problem auftaucht, können Entwickler, die die Lösung nicht nur aus technischer, sondern auch aus fachlicher Sicht betrachten, viel schneller Lösungen erarbeiten, weil sie einfach ein tieferes Hintergrundwissen besitzen, schnell den Kunden verstehen und so auch schneller das Problem eingrenzen können.

Dieses Vorgehen sorgt dafür, dass der Kunde die Lösung bekommt, die ihm tatsächlich weiterhilft und nichts was zu Projektbeginn mal in einem Pflichtenheft festgehalten wurde und vielleicht zum Zeitpunkt der Realisierung nicht mehr zutreffend ist.

Weit verbreitete Entwicklungsumgebungen sind der Standard

Neben der engen Zusammenarbeit gehen wir auch noch weitere Ansätze mit dem Ziel, für unsere Kunden optimale Lösungen zu entwickeln. Nahezu alle Dienstleister setzen die herkömmlichen Entwicklungswerkzeuge ein. Das sind integrierte Entwicklungsumgebungen von Microsoft, Apple oder der OpenSource Bewegung. Alle lösen in etwa das gleiche Problem, nämlich Code möglichst schnell zu produzieren. Dazu verwenden sie Standard-Frameworks für die Entwicklung von Benutzeroberflächen, zum Datenaustausch mit Datenbanken und vieles mehr. Das ist schon mal ein guter Anfang. Aber diese Werkzeuge verwenden alle Entwickler auf der Welt, so dass die Ausgangsvorraussetzungen alle gleich sind. Es spielt dann nur noch die persönliche Erfahrung, das Talent und das Engagement die entscheidende Rolle, ob ein Entwickler effizienter ist als ein anderer. Und welcher Dienstleister behauptet nicht von sich selbst, dass nur die talentiertesten, engagiertesten und erfahrensten Mitarbeiter für ihn arbeiten?

Standard-Entwicklungsumgebungen reichen nicht aus – WOGRA denkt weiter

Wir sagen: Die Tool-Landschaft zur Entwicklung von Software ist weiterhin ungenügend. Wir wollen möglichst viel Code vermeiden. Denn Code wird von Menschen gemacht und Menschen machen Fehler. Und wir wollen möglichst viele Routine-Tätigkeiten automatisieren, sodass Code nur noch dann entwickelt werden muss, wenn es um die eigentliche Geschäftslogik der Anwendung geht. Bei WOGRA entwickeln wir keine Benutzerverwaltungen, keine Datenexporte oder -importe, keine Datenbankschnittstellen mehr. Wir reduzieren uns auf die reine Anwendungslogik. Häufig ist es auch so, dass wir keine Benutzeroberflächen entwickeln müssen, da unsere Generatoren für den Anwendungsfall optimale Oberflächen generieren. Dadurch sparen wir viel Zeit, können Softwaresysteme früher zur Verfügung stellen und viel mehr Augenmerk auf die Qualität unserer Systeme legen.

Automatisierung von Prozessen und Generierung von Oberflächen mit WMS

Natürlich können wir nicht Zaubern, aber wir schauen seit unserer Gründung immer über den Tellerrand. Mit WMS haben wir ein System entwickelt, dass uns eine Menge Routine-Aufgaben abnimmt und uns das Leben erleichtert. Mit WMS fahren wir den konsequenten Weg uns selbst zu disruptieren und kontinuierlich Entwicklungsaufwände zu reduzieren. Mittlerweile können wir für nahezu jedes Endgerät vom Embedded Device, über Smartphones und Tablet bis hin zu Web und Desktop-Applikationen alles in Rekordzeit entwickeln. Ich behaupte wir sind einer der wenigen Dienstleister auf der Welt, die dies können und der Einzige in unserer Größe.

Warum soll man also mit WOGRA zusammen arbeiten? Weil das für den Kunden der beste Weg zu einer optimalen Lösung ist.

Das Problem

WOGRA entwickelt Softwarelösungen für diverse Endgeräte. Das kann eine Lösung sein, die in einem Webbrowser läuft oder nativ auf Smartphones oder auf dem PC. Oftmals gibt es die Anforderung, dass eine App auf dem Smartphone oder Tablet ebenso laufen muss, wie auch als Web-Lösung. Das kann man lösen, in dem man die Weblösung „responsive“ macht und so auch in Webbrowser der Smartphones läuft. Dies hat jedoch einige Nachteile.

Die Applikationen, die in Webbrowser laufen, können nicht auf alle Features eines Smartphones zugreifen. Gewisse Vorteile wie zum Beispiel der Zugriff auf das Adressbuch oder den Terminkalender des Smartphones können nicht genutzt werden. Das hat zur Folge, dass die Funktionen, die bereits für die Web-Lösung realisiert wurden, noch einmal für die native App nachimplementiert werden müssen. Der Aufwand für die Entwicklung wird so beträchtlich erhöht.

Mit unserer modellgetriebenen Entwicklungsplattform WMS haben wir eine Lösung entwickelt, mit der wir in der Lage sind, Software nur einmal zu entwickeln und für verschiedenste Endgeräte zur Verfügung zu stellen. Dies funktioniert solange wir die Benutzeroberflächen aus den Datenstrukturen generieren und nicht mehr überarbeiten müssen. Besonders bei Smartphones legen die Anwender allerdings auf sehr viel Wert auf tolles Design und einfache Bedienung. Hier ist die Verwendung von generierten Benutzeroberflächen sehr stark eingeschränkt. Bisher löste WOGRA dieses Problem, indem für Smartphones Benutzeroberflächen mit QML und für Weblösungen Benutzeroberflächen mit Vaadin gebaut wurden. Die Logik blieb in beiden Fällen in den Bestandteilen von WMS und es genügte, diese nur einmal zu modellieren und umzusetzen.

Aktuell gibt es keinen Standard, der sich durchgesetzt hat um plattform- und lösungsübergreifende Benutzeroberflächen definieren zu können, die dann für Smartphones, Tablet, Desktop und Weblösungen optimiert funktionieren. Leider führt genau das in Softwareentwicklungsprojekte weiterhin zu stark erhöhten Aufwänden. Bereits zu Jahresbeginn überlegten wir uns, wie eine Beschreibungssprache aussehen könnte, die es ermöglicht, plattformübergreifend Benutzeroberflächen zu definieren, die auch mit Oberflächen-Logik versehen werden kann. Mit Oberflächenlogik ist zum Beispiel eine Funktion gemeint, die automatisch Daten in der Oberfläche darstellt oder die Funktionalität der Oberfläche zu erweitert bzw. einschränkt.

Die Lösung: Interactive Component

Soll dies plattformunabhängig geschehen ist ein Standard notwendig. Dieser muss als Beschreibungssprache auf allen Plattformen interpretierbar sowie leicht les- und schreibbar sein. Dieser Standard sollte auch die Möglichkeiten bieten, Informationen in beliebiger Form darstellen und verändern zu können. Seit März arbeitet WOGRA nun an dieser auf JSON basierten Beschreibungssprache. In dieser ist eine Javascript Engine integriert um so mit einer Codebasis für jede Plattform die perfekte Benutzeroberfläche zu schaffen.

Neben der Definition der Features wurde bereits ein Interpreter für responsive-fähige Web Lösungen implementiert. Hiermit können bereits Benutzeroberflächen entstehen, die sowohl im Browser für PCs als auch für Smartphones optimal dargestellt werden. Der nächste Schritt ist die Portierung für nativen Desktop und Smartphone Lösungen. Damit können diese Benutzeroberflächen letzten Endes auf allen Endgeräten verwendet werden.

Vorteile von Interactive Component

• Einmal entwickelt, funktioniert die Oberfläche auf jedem Endgerät und stellt dort die Informationen optimal dar. Dies führt zu einer erheblichen Reduzierung des Implementierungsaufwands.
• Da eine Sprache zugrunde liegt, die zur Laufzeit interpretiert wird, können Benutzeroberflächen jederzeit angepasst erweitert oder customized werden. Der Programmcode muss nicht immer wieder neu kompiliert werden. So erhält der Kunde auf seine Bedürfnisse zugeschnittene Benutzeroberflächen, ohne dass ein eigener Softwarestand für ihn gepflegt werden muss, oder dass ein Deployment notwendig wird.
• Aufgrund der Tatsache, dass die Beschreibungssprache eine Javascript Engine enthält, können diverse Logiken für die Benutzeroberflächensteuerung eingebaut werden. Diese müssen ansonsten aufwendig programmiert werden. So sind wir in der Lage, sofort auf Dateneingaben zu reagieren und daraufhin automatisch Daten nachzuladen oder Auswahllisten zu ändern. Auch das Ein-/Ausblenden von Komponenten in den Benutzeroberflächen wird nun eleganter gehandelt.
• Mit einem eigenen Editor können die Benutzeroberflächen mit Autocompletion entworfen und getestet werden.
• Basierend auf den Standards JSON und Javascript muss ein Entwickler nur dass verwenden, was er ohnehin schon kennt. Die Einarbeitungszeit ist durch die Wahl dieser weit bekannten Sprachen kurz und der Zeitgewinn dadurch sehr hoch.

Nun wird auch klar, weshalb diese plattformübergreifende Benutzeroberflächensprache den Namen „Interactive Component“ erhalten hat. Interaktiv steht sowohl für das Verhalten der Oberflächen-Komponenten gegenüber dem Anwender als auch die Chancen, diese jederzeit an Kundenbedürfnisse anpassen zu können.

Die Technik

Vielleicht noch ein paar Worte zur Technik. WMS erstellt auf Knopfdruck Software-Lösungen, die bereits auf sehr vielen Endgeräten nach dem Single Source Prinzip funktionieren. Bisher mussten allerdings Benutzeroberflächen speziell für Webbrowser, für Smartphones und Desktoplösungen entwickelt werden. Diese Arbeit wird durch Interactive Component abgenommen und man erhält auch ein Single Source Prinzip bei den Benutzeroberflächen. Die Weblösung von WMS basiert auf Java Vaadin. Auch der Interpreter generiert aus der Oberflächenbeschreibungssprache Java Vaadin Benutzeroberflächen.

Auf der Smartphone und Desktop Seite basiert WMS auf C++ Qt, weil man dadurch auf sehr vielen Endgeräten Lösungen anbieten kann. C++ Qt hat mit QML eine ähnliche Beschreibungssprache wie Interactive Component. Allerdings mit der Einschränkung, dass diese nur auf Smartphone, Tablet, Desktop und Embedded Devices funktioniert, aber nicht in Weboberflächen. Deshalb wird die Interactive Component Benutzeroberflächenbeschreibung in QML umgewandelt und steht somit auch für alle anderen Endgeräte zur Verfügung.

Ausblick

WOGRA plant noch im Jahr 2016 den Einsatz von „Interactive Component“ in neuen Projekten, die dann noch bessere Benutzererfahrungen ermöglichen und noch einmal WOGRAs Geschwindigkeit in der Softwareentwicklung erhöhen.

Voll im Trend – die digitale Transformation

Die Politik ist ja inzwischen schon ganz heiß auf die Digitalisierung und setzt alles daran, damit der Funke auch bei den Unternehmen überspringt. Die digitale Transformation bedeute ja immerhin eine Menge für uns – geht es doch um die Sicherung des Wirtschaftsstandorts Deutschland und seiner Zukunftsfähigkeit!

Doch zeigt sich am Beispiel dieses aktuellen Trends, dass eine Software-Lösung nicht immer auch eine Lösung ist. Sicherlich, wir brauchen nicht darüber reden, dass eine Fabrik mit großen Lagerhallen ein Warenwirtschaftssystem braucht, um die Bestände verwalten zu können. Oder dass eine Auto-Werkstatt ein Auftragserfassungs-System braucht. Nur um solche Lösungen, die bereits jetzt einen reibungslosen Ablauf und die Existenz eines Unternehmens sichern, geht es hier gar nicht.

Wir brauchen eine Software – jetzt!

Die Entscheidung, eine neue Software einzuführen, kommt in den meisten Fällen nicht aus der Belegschaft, sondern von dem zuständigen IT-Leiter oder der Geschäftsführung. Die Grundlage für diese Entscheidung bilden dann vor allem Zahlen aus dem Controlling oder aus Beobachtungen, dass bestimmte Prozesse zu lange dauern. Dann folgt der erleuchtende Gedankenblitz: Wir brauchen eine Software dafür! Und nun wird ein Riesending gestartet: Dienstleister werden ausgewählt, ein Pflichtenheft zur Beschreibung der erforderlichen Funktionen wird erstellt, Prototypen werden analysiert, Testversionen werden an bestehende Systeme angebunden, nach jeder Fehlerbehebung muss die Funktionalität erneut überprüft werden, am Ende wird die Software produktiv genommen und schlussendlich müssen die Mitarbeiter, die nun damit arbeiten werden, auch geschult werden. Das kostet Zeit, das kostet Geld. Und manchmal auch Nerven.

Die heiße Phase – Einsatz im produktiven Betrieb

Doch die spannende Phase kommt eigentlich erst im produktiven Einsatz. Denn erst hier zeigt sich, wie gut sowohl das erdachte Konzept als auch die realisierte Software tatsächlich ist! Die große Gefahr beim Konzept besteht darin, dass es jemand geschrieben hat, der keine Berührungspunkte mit dem späteren produktiven Einsatz hat. Möglicherweise wurden Prozesse vergessen, unnötige Zwischenschritte oder Angaben eingeführt – und nicht mit den beteiligten Mitarbeitern gesprochen, ob eine Software die Prozesse überhaupt erleichtern würde. Auf der anderen Seite kann die Software von der Oberfläche her schlecht gestaltet sein – die Mitarbeiter finden dann entsprechende Funktionen gar nicht oder unterlassen wichtige Schritte, weil es ihnen schlichtweg zu kompliziert ist. Wenn die Anbindung an Schnittstellen anderer Systeme fehlerhaft ist, wird die ganze Software sogar komplett unbrauchbar.

So wird die Lösung eine Lösung

Die Motivation, eine Software einzuführen, ist lobenswert – denn sie kann definitiv einen Fortschritt für das Unternehmen bedeuten – nur sollten sowohl die Mitarbeiter bedacht werden, die dann mit der Software arbeiten sollen, als auch die Schnittstellen der Systeme, die angebunden werden müssen.

Das bedeutet, dass man die Anwender möglichst von Anfang an mit ins Boot holt, regelmäßige Vorführtermine der Software durchführt um sich das Feedback der Anwender einzuholen. So entstehen fruchtbare Diskussionen zu einer bestmöglichen Lösung im Sinne des Anwenders. Wenn es möglich ist, sollte man die Software in kleinen Iterationen entwickeln, sodass die dadurch entstehenden Features vom Anwender schnell verwendet werden können. So sammelt man bereits frühzeitig Erfahrung mit der Software und hat die Möglichkeit Verbesserungen durchzuführen. Ist die Anwendung für Endkunden gedacht, sollte man sich potenzielle Benutzer mit ins Boot holen und deren Eindrücke von der Software bei der Weiterentwicklung berücksichtigen.

Gerade bei einer großen Anzahl an Benutzern sollte man auch Methoden wie z.B. die Empathiekarte hinzuziehen um die Anwendungen nach den Bedürfnissen der Anwender zu entwickeln. Sich in den Anwender hinein zu versetzen heißt neudeutsch Design Thinking. Design Thinking wird als Begriff aktuell sehr stark verbreitet, doch die Idee dahinter sollte eigentlich bei jedem guten Softwaredienstleister, der für seine Kunden die bestmögliche Lösung entwickeln will, schon immer in jedem Softwareprojekt wesentlich berücksichtigt werden.