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.

SAP Business One hilft beim gesund arbeiten

Besondere Geschäftsmodelle erfordern besondere Lösungen. US-Wellness ist eines dieser besonderen Unternehmen. Seit 1997 bieten sie Services für Unternehmen, die ihre Mitarbeiter in Sachen Gesundheit unterstützen möchten. Eine innovative Idee, die gleichermaßen mit den Firmen wächst, die sich um das Wohlbefinden ihrer Angestellten sorgen.

Wellness im Unternehmen

So zählt US-Wellness Microsoft oder Boehringer zu seinen Kunden. Das Angebot an „Wellness-Strategien“, Tests und Termin-Management muss softwaretechnisch gewährleistet sein. Da sich die Bedürfnisse des Unternehmens von denen eines produzierenden Unternehmens stark unterscheiden, braucht US-Wellness ein flexibles System, das sich anpasst und mit ihnen wachsen kann. Raten Sie für welche Software sich das Unternehmen entschieden hat?

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

YouTube immer entsperren