Wo stehen die Unternehmen derzeit beim Thema Enterprise Mobility?

Leif-Olof Wallin: Ich glaube, es gibt zwei Dimensionen zu dieser Frage: Setzen sie Enterprise Mobility ein? - Ja, praktisch alle haben Mobility zu einem gewissen Grad im Einsatz. Die brennende Frage ist allerdings eher: Haben sie sie unter Kontrolle? Haben sie die geeigneten Policies, Tools und Prozesse im Einsatz, um Enterprise Mobility sicher und professionell zu managen? In Hinblick auf die großen Unternehmen - in Deutschland, sowie auch in ganz Westeuropa - würde ich sagen, wir treffen auf rund 75 Prozent, die in bestimmte Tools investiert haben oder sie als Managed Services kaufen.

Wenn wir aber kleine und mittelgroße Unternehmen ansehen, nutzen diese im besten Fall Exchange, um Policies auf die Devices zu schicken, um Verschlüsselung zu aktivieren und Passwörter sowie -komplexität und Timeout etc. einzustellen …

… was vermutlich nicht so schlecht ist, wenn man nur PIM-Daten auf dem Device nutzt…

Leif-Olof Wallin: Ja, es kommt auf die Branche an - wenn man Zugang zu Privacy-sensitiven Informationen hat, mag es nicht ausreichend sein, aber die meisten unserer kleineren Kunden kommen damit aus. Man erhält jedoch eine Reihe signifikanter Vorteile, wenn man sich ein Enterprise-Mobility-Management-Produkt anschafft: Man bekommt ein besseres Verständnis von der mobilen Nutzung, erhält eine Umgebung, die kosteneffektiver zu verwalten ist. Mit Exchange wird es jenseits von 300 Geräten auch sehr teuer, weil man im Prinzip ein riesiges Access-Spreadsheet verwaltet. Das funktioniert für 50 Nutzer, aber bei einigen Hundert…

Der Bereich, wo mehr und mehr Kunden Herausforderungen erleben, ist File Sharing und Synchronisation. Sobald man mobile Devices im Unternehmen nutzt, kommt das Bedürfnis - zumindest ein scheinbares - auf, Informationen zwischen den verschiedenen Geräten zu synchronisieren. Es ist leicht, Kontakte oder Kalender zu synchronisieren, aber nicht Dokumente, PDFs oder Preislisten.

Dann gibt es üblicherweise zwei Möglichkeiten: Entweder investiert das Unternehmen in ein EMM-Tool, das Filesharing und Synchronisierung als eines der Features unterstützt, möglicherweise auch ein Standalone-Produkt wie Box oder Accelion, dann erhält es eine richtige sichere Business-Lösung. Die Alternative ist, dass man nichts tut. Dann denken sich die Mitarbeiter eine Lösung dafür aus, mit Endkundenlösungen wie Dropbox oder Evernote. Als Unternehmen hat man dann keine Chance herauszufinden, wo die Daten gehostet werden. Im besten Fall liegen sie auf einem Server in den USA, sie können sich aber auch in der Ukraine oder anderen Orten befinden.

Was wir sonst noch in den meisten Unternehmen beobachten: Ja, E-Mail macht viel Sinn, es liegt aber nicht viel Wert darin, Mitarbeitern unterwegs Zugriff auf ihren Spam-Mails zu geben. Der wahre Wert von E-Mail kommt, wenn man sie als eine Workflow Engine im Unternehmen verwendet. Viele meiner Kunden nutzen E-Mails für Approvals, für die interne Kommunikation. So ist es generell: Mobility an sich hat null Geschäftswert - der kommt nur, wenn sie dabei hilft, die zentralen Geschäftsprozesse effektiver zu machen. Etwa um die Verzögerungen bei Genehmigungsprozessen zu reduzieren.

Wie steht es mit Enterprise Apps?

Leif-Olof Wallin: Betrachtet man den Mittelstand, kreiert kaum jemand jemals eigene Enterprise-Apps, sondern nutzt eher Standards wie Salesforce.com oder Office für das iPad. Aber es gibt Ausnahmen, Mittelständler, die sehr kundenfokussiert sind und Apps nutzen, um sich mehr auf die Kunden einzulassen, also B-to-C-Lösungen. Manchmal auch B-to-B-to-C.

Ein typisches Beispiel dafür sind die Autohersteller. Sie verkaufen die Fahrzeuge an die Händler und diese wiederum an die Endkunden, aber die Kommunikation erfolgt direkt zwischen Hersteller und Kunden. Händler haben kein Budget, Apps zu entwickeln.

Liegt es wirklich am Preis? Es gibt auch Mittelständler, die ziemlich groß sind und dennoch keine eigenen mobilen Anwendungen besitzen.

Leif-Olof Wallin: Mobile App Development kommt in verschiedenen Geschmacksrichtungen. Wenn Sie native Apps für iOS, Android und Windows Phone entwickeln - mit sagen wir einmal tiefer Hardwareintegration wie Position, Kamera etc. - dann wird das sehr teuer. Insbesondere, wenn Sie dann noch eine gute Benutzererfahrung wollen. Das Bauen ist dabei nur ein Aspekt, dazu kommt dann noch die Instandhaltung …

... und die Verknüpfung mit dem Backend.

Ja, wenn es nur darum geht, eine Art Dashboard für fünf Manager zu erstellen, um die Produktion einzusehen oder die Lieferkette etwa, und die APIs bereit stehen, macht das ein Programmierer in ein bis zwei Tagen. In einer Woche läuft die Anwendung. Quick & Dirty sozusagen …

… Okay, das wird dann einfach mit HTML 5 erstellt …

Leif-Olof Wallin: ... Ja, und wenn eine App gewünscht wird, wird es mit Phonegap gewrappt - das ist ebenfalls Open-Source. Wenn man aber etwas Anspruchsvolleres, etwa für die Aufzug-Wartung wie bei Thyssen-Krupp benötigt, also eine Custom-App, die auch offline funktioniert - dann sprechen wir plötzlich von einigen Millionen Euro.

Es gibt typischerweise vier Herausforderungen für ein Unternehmen, wenn es Apps entwickeln will. Erstens Device-Diversity - für wie viele Geräte muss man entwickeln und testen. Es ist ziemlich einfach, wenn man sich für iPhone oder Windows Phone entscheidet. Dann muss man alle neun Monate, wenn eine neue iOS-Version herauskommt, testen, möglicherweise auch bei den kleineren Releases.

Will man für Endkunden eine Android-App herausbringen, muss man in Deutschland aber gleich für 30 bis 50 Modelle testen - nicht unbedingt physikalische Geräte, aber auch remote. Bei Business-to-Employee-Apps ist es viel einfacher, aber mit Android immer noch eine Herausforderung. Erlaubt man Mitarbeitern die Nutzung von Android wird es teuer.

Auch beim COPE-Modell, also wenn man den Mitarbeitern einige Modelle, etwa aus der Samsung Galaxy-Reihe, zur Auswahl gibt?

Leif-Olof Wallin: Das ist lustig, dass Sie das erwähnen. Viele unserer Kunden kommen zu Android, weil sie eine günstigere Alternative zum iPhone suchen. Denn da gibt es bereits Geräte ab 100 Euros. Nach einer Weile erkennen sie dann: Oje, das ist zu komplex mit den verschiedenen Android-Versionen, wir müssen standardisieren. Dann sehen sie, dass es nur einen Hersteller im Android-Bereich mit einem klaren Enterprise-Fokus gibt, nämlich Samsung.

Und dann finden sie heraus, dass es da noch das SAFE-Programm mit verbesserten Management- und Security-APIs gibt und vielleicht auch noch Samsung Knox und auf einmal realisieren sie: Wir sind eigentlich zu Android gewechselt, weil wir günstige Devices gesucht haben. Und jetzt kaufen wir die teuersten Top-Geräte, die im Prinzip genauso viel kosten wie ein iPhone. Das ist dann der Punkt, wo sich Unternehmen Windows Phone ansehen. Hier gibt es eine breite Auswahl an Geräten von 125 bis 600 Euro, die alle ihre Aufgabe bewältigen.

Aber bei der Verwaltbarkeit gibt es dann doch immer noch Einbußen.

Leif-Olof Wallin: Sicher, es ist einfacher, Samsung-Geräte zu managen. Aber Windows Phone 8.1 ist schon ziemlich geradlinig, Microsoft hat schon eine Menge repariert.

Haben die CIOs bereits erkannt, dass der Hardwarepreis nicht wirklich der Kostentreiber ist?

Leif-Olof Wallin: Ja, Sie haben Recht, die Hardware macht lediglich 20 bis 25 Prozent der Gesamtkosten aus, der Rest fällt für Mobilfunkverträge, Softwarelizenzen, Support und Ähnliches an. Und meine Kunden berichten mir, dass Android-Geräte etwa 2,5-mal mehr Support benötigen als Devices mit iOS oder Windows Phone.

Aber zurück zum Ausgangspunkt: Die zweite große Herausforderung - und das ist wirklich frustrierend für viele meiner Klienten - ist die Integration. Bei Präsentationen greifen wir dafür gerne auf eine Folie mit einem großen Stopschild zurück, denn so fühlen sich viele Entwickler behandelt. Sie entwickeln für eine Fachabteilung die App und gehen dann zur IT-Abteilung und sagen: Gebt mir die API, damit ich die App in das Backend integrieren kann - und die IT sagt Nein. Manchmal gibt es auch gar keine Schnittstellen oder die existierenden APIs sind furchtbar geschrieben und schicken beim Aufruf 24 Zeilen Code zurück. Im besten Fall muss man die APIs neu schreiben.

Oder die IT will kein neues Loch in der Firewall?

Leif-Olof Wallin: Ja, das ist eine andere Variante, die vorkommt. Und manchmal muss man die APIs von Grund auf neu schreiben. Das ist teuer und schwierig. Oder man ist kreativ und nutzt Web-Scraping als Übergangslösung. Ich erinnere mich an die 90er Jahre zurück, als man diese Methode nutzte, um Anwendungen zu webifizieren - und stülpte dann ein nettes GUI drüber. Einige meiner Kunden machen genau das: Sie nehmen die vorhandene Web-Anwendung für PCs und emulieren sie und scrapen sie und nutzen sie als API für eine Mobile-App. Man muss manchmal kreativ sein, um seine Deadline einzuhalten. Es skaliert nicht wirklich, hilft aber, um den Job zu erledigen.

Über die Zeit sehen wir viele Lösungen mit einem Mobile-Backend as a service, es geht in die Cloud und da kann man schauen, welche APIs verfügbar sind. Diese Option versteckt die Komplexität verschiedener API-Versionen, da man etwas in der Cloud aufruft und die Cloud ruft das ERP-System auf. So eine Lösung macht viel Sinn, da sie auch bei Veränderungen an den SAP-Instanzen funktioniert. Schaut man auf die traditionellen SAP-Installationen, nutzen viele Unternehmen verschiedene Releases und man muss vorsichtig sein, dass die mobile App nach einem Upgrade noch funktioniert.

Die dritte Herausforderung ist Security: Die meisten Kunden sehen sich bei der Mobilisierung die Sicherheitsanforderungen an und denken dann: Ich muss wohl die Anforderungen anpassen, um die Produktivität zu steigern. Es ist sehr schwierig, den Zugriff auf Informationen auf ein kleines Gerät zu erweitern und die gleichen Anforderungen wie bei großen Devices beizubehalten. Die Mitarbeiter werden verrückt, wenn sie ein achtstelliges alphanumerisches Passwort mit mindestens einem Sonderzeichen etc. eingeben müssen und die Produktivität wird dadurch sicher auch nicht gefördert.

RSA-Security Hard-Tokens funktionieren auch nicht auf einem mobilen Endgerät - die eine Hand hält das Token, die andere das Device und dann braucht man eine dritte Hand, um die Zahlenkombination einzugeben. Viele Kunden gehen daher dazu über und nutzen RSA Secure ID als Software auf dem Gerät. Security-Spezialisten könnten jetzt sagen, dass die Methode nicht so sicher sei wie ein separates Token. Es ist immer schwierig, eine Balance zwischen ausreichender Sicherheit und Produktivität zu finden.

Und dann gibt es noch das Problem, überhaupt Entwickler zu finden.

Leif-Olof Wallin: Ja, der vierte Aspekt ist das mangelnde Fachwissen. Es gibt einfach zu wenige echte Experten für Javascript und andere Techniken, die man braucht, um überzeugende Apps zu erstellen. Dazu gehört die Kenntnis über das Nutzerverhalten, also eher Psychologie, aber auch das Wissen, wie man Apps auf kosteneffektive Weise testet. Der Mangel an entsprechendem Know-how zeigt sich auch in der gegenwärtigen Begeisterung für Crosscompilation Lösungen zur Wiederverwertung existierender Skill sets.

Bei diesen vier Punkten haben meine Kunden Schwierigkeiten und kaum einer ist in der Position, hundertprozentig zu beherrschen. Geht es um das Thema Mobile App Development, kommt dann üblicherweise die Frage: Wieviel sollen wir intern machen, 25 Prozent? Macht man gar nichts, wie einige Kunden in der Golf-Region, verliert man die Kontrolle und weiß zu wenig, um ein kompetenter Käufer zu sein.

Die IT hat inzwischen aber ein starkes Interesse daran, dem Line of Business zu helfen, um die Situation unter Kontrolle zu bekommen. Wenn es eine Outsourcing-Situation gibt, muss die IT involviert werden, um sicherzustellen, dass der Partner wirklich qualifiziert ist und länger am Markt ist. Vielleicht nicht wie üblich fünf bis zehn Jahre, aber immerhin zwei oder drei Jahre.

Die IT muss sich auch um Details kümmern wie Ownership, dass die eigenen Zertifikate genutzt werden und nicht die von Drittanbietern. So gesehen fungiert die Unternehmens-IT mittlerweile als eine Art Reiseführer. Viele Kunden richten inzwischen auch ein Mobility Centre of Excellence ein - nicht, um alles zu entwickeln, sondern um Hilfe anzubieten, Best Practices zu geben, was die Auswahl der Plattformen, vorhandene Lizenzen, Partner, Testszenarien betrifft. Sie halten auch Bestandteile vor, die wiederverwendet werden können, etwa für ein Single-Sign-On.