Semantic Web im Unternehmen — Linked Data, Knowledge Graphs und mehr

Was soll das denn bedeuten?

Das Semantische Web oder Web 3.0 bezeichnet die Idee, Daten im Web besser maschinell verwertbar zu machen und besser miteinander zu verknüpfen. Grundlage hierfür ist die Beschreibung der Bedeutung dieser Daten. Gleichzeitig sollen die grundlegenden Eigenschaften beibehalten werden, die das Web so erfolgreich gemacht haben.

Ein Beispiel für eine solche semantische Beschreibung ist die Kennzeichnung von Produktdaten in Web Shops mittels des Good Relations Vokabulars, das mittlerweile in das umfassendere schema.org Vokabular integriert wurde.

Beispielsweise hilft diese Kennzeichnung Suchmaschinen dabei, die entsprechenden Produktinformationen korrekt zu interpretieren.

Linked Data und Knowledge Graphs

DBpedia hingegen stellt Daten nicht primär über Webseiten, sondern als strukturierte Datensätze bereit. Zu diesem Zweck analysiert dieses Projekt Wikipedia-Seiten (insbesondere deren Infoboxen) und stellt die extrahierten Daten strukturiert bereit.

Die einzelnen Bestandteile dieser Informationen werden — ganz ähnlich wie bei Webseiten — mit einander verknüpft. Folglich spricht man hier von Linked Data.

Sind die Datenbestände offen, so spricht man von Linked Open Data.

The Linked Open Data Cloud gibt einen Überblick über verfügbare offene Linked Data Datenbestände.

Daten in solchen Linked Data Beständen formen einen Graph. Ist eine Wissensbasis als Linked Data Graph abgebildet, so sprechen wir von einem Knowledge Graph.

Ein wirklich einfaches Datenmodell

Als Datenmodell kommt das Resource Description Format (RDF) zum Einsatz.

RDF ist ein sehr einfaches — und dadurch extrem flexibles — Modell, dass Daten in Form sogenannter Triples (d.h. 3-Tupel, Tripel) definiert. Diese haben die Form:

Subjekt Prädikat Objekt

Das Prädikat beschreibt die Beziehung zwischen Subjekt und Objekt. Subjekte sind i.d.R. Identifikatoren (in Form von IRIs) während Objekte entweder Identifikatoren oder Werte sind.

Die Prädikate sind wiederum Identifikatoren. Durch die Nutzung bekannter Vokabulare kennzeichnen sie die Bedeutung der codierten Daten.

Das folgende (triviale) Beispiel nutzt das bekannte Friend of a Friend Vokabular und weist einem Identifikator einen Namen zu.

ex:Oliver foaf:name "Oliver Baier" .

In diesem Beispiel kommt Turtle als Datenformat zum Einsatz. Neben Turtle gibt es noch weitere Formate zur Codierung von RDF-Daten.

Eulen, Funkeln und Fesseln

RDF Schema (RDFS), die Ontologie-Beschreibungssprache Web Ontology Language (OWL) sowie Constraint-Sprache SHACL erlauben es, die Formate und Bedeutung von Daten standardisiert zu beschreiben.

Die Abfragesprache SPARQL erlaubt es, Anfragen an RDF-Datenbestände zu stellen sowie diese Datenbestände zu modifizieren (Zugriffsrechte vorausgesetzt). SPARQL ist SQL im Kontext relationaler Datenbanken ähnlich. Interessant ist, dass SPARQL mehrere Datenbestände in einer einzelnen Abfrage ansprechen kann.

Hinter der Firewall

Diese Technologien sind natürlich nicht nur im offenen Web, sondern auch „hinter der Firewall“ im eigenen Unternehmen sinnvoll einsetzbar. Viele Unternehmen könnten beispielsweise von einem eigenen Knowledge Graph profitieren.

Besonders interessant erscheint mir das Potenzial dieser Technologien jedoch im Zusammenhang mit eher klassischen Enterprise IT Problemen wie z.B. dem Stamm- und Referenzdatenmanagement, der Daten- und Applikationsintegration oder auch der Integration mit Partnern über Unternehmensgrenzen hinweg (B2B-Integration).

Vor dem Hintergrund sehr hoher Anforderungen im Bereich des Financial Risk Management überrascht es nicht, dass Banken und andere Finanzinstitutionen diesen Technologien besondere Bedeutung beimessen. Beispielsweise ist FIBO, die Financial Risk Business Ontology, eine umfassende Ontologie für den Finanzsektor.

Diese semantischen Technologien können inkrementell und iterativ zum Einsatz gebracht werden. Erste Experimente und Prototypen sind mit geringem Aufwand zu realisieren. Die erarbeiteten Ergebnisse können dann schrittweise erweitert und vertieft werden.

Und jetzt?

Sind Sie neugierig geworden? Möchten Sie diese Technologien besser verstehen? Oder ihr Potenzial — insbesondere im Enterprise Information Systems bzw. Enterprise Applications Umfeld — diskutieren?

Sprechen Sie mich einfach an!

On-Demand Consulting: Qualifizierte Leistungen auch für Kleinaufträge

In der Zusammenarbeit mit meinen Kunden erzielen wir die höchste Wertschöpfung durch die sehr bewusste Definition meiner Einsätze und die fokussierte Erbringung meiner Leistungen. Beispiele sind die Vorbereitung, Durchführung und Nachbereitung kurzer Discovery Workshops und Architekturbewertungen.

Als freiberuflicher Berater bin ich in der Lage, meine Leistung noch kleinteiliger anzubieten und damit Kunden auch in Einzelfragen effektiv zu unterstützen.

Das Besondere daran ist, dass Experten mit meinem Qualifikations- und Leistungsprofil in der Regel nur im Rahmen größerer und längerfristiger Aufträge zur Verfügung stehen. Damit sind meine Leistungen auch für kleinere Unternehmen und Projekte verfügbar.

Einige Beispiele für solch kleinteilige Aufträge sind:

  • Review von Ausschreibungsentwürfen und Projektkonzepten,
    z.B. hinsichtlich Verständlichkeit, unnötiger Komplexitäts- und Aufwandstreiber, vermeidbarer Risiken, ‚Beantwortbarkeit‘ durch Anbieter, Machbarkeit des Projektansatzes
  • Beratung bei der Bewertung von Anbieterantworten auf Ausschreibungen
  • Review von Strategie-, Architektur- und Designentwürfen sowie Situationsanalysen, insbesondere aus interdisziplinärer Sicht
  • Durchführung von Kurz-Workshops zur gemeinsamen Konzeptentwicklung, sowohl hinsichtlich initialer Projekt- und Produktideen als auch hinsichtlich detaillierter funktionaler und technischer Einzelfragen aus den Bereichen Architektur, Design, Implementierung und Betrieb

Die Bearbeitung vieler anderer Aufgaben ist in diesem Kontext denkbar.

Voraussetzung für die Erbringung solch kleinteiliger Leistungen sind die effiziente Auftragsvergabe und -abwicklung auf dienstvertraglicher Basis.

Sprechen Sie mich einfach für eine kurzfristige Ersteinschätzung Ihrer Herausforderung an.

Lean vs. Agile vs. Design Thinking … kurz & knackig

Viele unterschiedliche Methoden und Ansätze überfluten den Markt in den Bereichen Softwareentwicklung, IT, Projektmanagement, Produktmanagement und Digitalisierung. Hierzu gehören unterschiedliche Geschmacksrichtungen von agilen Softwareentwicklungs- und Projektmanagementmethoden, von denen Scrum wohl die bekannteste, aber nicht die einzig relevante ist.

Im Bereich der schlanken Methoden hat sicherlich Lean Startup den höchsten Bekanntheitsgrad. Hier geht es um schlankes Produktmanagement und eigentlich sogar um die Entwicklung ganzer Geschäftsmodelle mittels schlanker Methoden.

Design Thinking wird in unterschiedlichen Variationen als eine Methode beworben, um Managern und Fachspezialisten ein größeres Verständnis für die Arbeit von Designern und auch deren Wertbeitrag zum Unternehmen zu vermitteln. Das große Interesse an diesem Thema hat leider auch viele recht zweifelhafte Beratungs- und Schulungsangebote entstehen lassen, so dass die Ergebnisse von Schulungen und Workshops oft dürftig sind oder aber niemals den Weg in die Umsetzung finden.

In seinem Buch „Lean vs. Agile vs. Design Thinking: What You Really Need to Know to Build High-Performing Digital Product Teams“ gibt Jeff Gothelf einen kurzen und knackigen Überblick über Ansätze und Methoden aus den Bereichen Lean, Agile und Design Thinking. Er erklärt, dass diese drei Ansätze nicht sinnvoll nebeneinander in einem Unternehmen existieren können, sondern dass cross-funktionale Teams in diesen Unternehmen einen eigenen Ansatz mit relevanten Aspekten dieser Methoden entwicklen müssen. Zusätzlich beschreibt er die Aspekte einer solche Methode, die seiner Erfahrung nach essenziell für den Erfolg sind.

Und all dies schafft Jeff Gothelf auf nur 44 Seiten bzw. in 45 Minuten als Hörbuch. (Link zum Verlag)

Ich empfehle dieses Hörbuch allen, die an einer wirklich kurzen, aber dennoch außerordentlich fundierten und realistischen Einordnung dieser überstrapazierten Begriffe interessiert sind.

Fragen? Fragen! Ich freue mich über Nachfragen oder Anmerkungen zu dieser Empfehlung.

(Ich erhalte keine Vergütung oder anderen kommerziellen Vorteile für diese Empfehlung und den Link.)

Digitalisierung in mittleren Unternehmen und dem Mittelstand

Überschaubare Budgets und geringe Mitarbeiterkapazität setzen enge Grenzen

Kleine und mittlere Unternehmen (KMU), einschließlich Unternehmen des Mittelstands, verfügen über begrenzte Geldmittel und Mitarbeiterkapazität für die Digitalisierung, die nur eins von mehreren wichtigen Zukunftsthemen für diese Unternehmen ist.

Dies ist erst einmal ein wesentlicher Nachteil gegenüber größeren Unternehmen, kann aber auch eine Chance beinhalten: es zwingt Unternehmen dazu, ihre Investitionen bewusst zu treffen anstatt in Aktionismus zu verfallen.

Klarheit über Gründe für und erwarteten Nutzen von Digitalisierungsprojekten ist essenziell

Wie in der Vergangenheit scheitern Projekte auch heute häufig: Accenture beschreibt in einer Studie anlässlich der Hannover Messe 2019, dass 80 % der Pilotprojekte zur Digitalisierung in deutschen Unternehmen nicht erfolgreich waren oder sogar abgebrochen wurden (S. 5).

Aus meiner Sicht spricht dies klar dafür, vergleichsweise kleine Digitalisierungsprojekte mit klar definierten Zielen und erwartetem Nutzen zu initiieren — und dann diszipliniert gegen diese Erwartungen zu managen (wenn auch mit schlanken und agile Methoden). Dieser Ansatz hat sich bewährt und gewinnt zunehmend Anhänger, beispielsweise auch in der Entwicklung vollständig digitaler Produkte — auch wenn manche Dienstleister lieber möglichst große Projekte verkaufen.

Hoher Innovationscharakter erfordert exploratives Vorgehen

Digitalisierungsprojekte haben für die betreffenden Unternehmen in der Regel einen hohen Innovationscharakter. Daraus folgt, dass sie nicht detailliert zu planen sind und ihre Ergebnisse nicht im Detail absehbar sind. Ein exploratives Vorgehen ist also sinnvoll und sogar notwendig: Hierbei werden die Annahmen oder Hypothesen identifiziert, die wahr sein „müssen“, damit sich das Projekt als sinnvoll erweist. Diese Hypothesen werden dann möglichst früh im Projekt auf möglichst leichtgewichtige Weise getestet — beispielsweise mit Hilfe von unterschiedlichen Arten von Prototypen in einer initialen Discovery-Phase.

Kernfragen hierbei sind: Lösen wir das richtige Problem? Ist unsere Lösung effektiv und effizient? Gibt es einen Markt für unser Produkt? (Die letzte Frage bezieht sich primär auf digitale Produkte mit externen Kunden, gilt aber sinngemäß auch für interne Projekte.)

Customizing treibt Komplexität und Kosten oft unnötig in die Höhe

Um Komplexität und Kosten bei der Einführung von digitalen Produkten, insbesondere von Softwaresystemen, möglichst gering zu halten empfehle ich, das Customizing, also die kundenspezifische Anpassung dieser Produkte, möglichst zu vermeiden. Sinnvolle Ausnahmen können nur dort gemacht werden, wo der (wirtschaftliche) Nutzen dieser Anpassung unverhältnismäßig groß ist. Hierbei sind aus meiner Sicht hohe Hürden an die Höhe des Nutzen sowie an dessen Nachweis zu stellen.

Meiner Erfahrung nach werden Komplexität und Kosten solcher Anpassungen regelmäßig erheblich unterschätzt, der zu erwartende Nutzen jedoch regelmäßig erheblich überschätzt. Insbesondere kleine und mittlere Unternehmen können also allein durch diesen Grundsatz die Reichweite ihres Budgets erheblich steigern.

Einfache Tools und gute Cloud-Dienste erhöhen die Effektivität und Effizienz

Kleine und mittlere Unternehmen sollten relativ einfache Produkte und Technologien für jeweils gut definierte Zwecke und realistische Anwendungsszenarien bevorzugen. Insbesondere sind hier Cloud-Dienste oft eine gute Wahl, da diese Unternehmen eine annähernd vergleichbare Leistung beim Betrieb eigener Systeme in der Regel nicht erreichen können — und schon gar nicht bei annähernd vergleichbaren Kosten.

In diesem Zusammenhang erinnere ich an eine Frage aus einer Werbekampagne von IBM:

Does your kid have better technology than your business?

— IBM

Wenn wir ehrlich sind, müssten viele Unternehmen antworten:

Leider ja.

Produkte, die vielleicht schon aus dem Consumer Bereich bekannt sind, können auch im Unternehmen sinnvoll eingesetzt werden (z.B. Dropbox).

Kritische Auswahl — und ggf. Ablehnung — von Digitalisierungsprojekten vermeidet Fehlinvestitionen

KMU sollten die eigene spezifische Situation bei der Auswahl von Digitalisierungsprojekten kritisch bewerten. Dies hört sich vielleicht wie ein Widerspruch zur o.g. „möglichst kein Customizing“ Empfehlung an, ist es aber nicht: beispielsweise ist ein Web Shop nicht unbedingt das wichtigste Projekt für jedes mittelständische Unternehmen.

Handelsunternehmen oder Hersteller von recht standardisierten Produkten sind mit einer E-Commerce Lösung sicherlich gut beraten — obwohl auch hier zu prüfen ist (z.B. in Abhängigkeit von der Art der Kunden und deren Bedürfnissen), ob ein Web Shop das Mittel der Wahl ist oder ob im ersten Schritt der automatisierte Datenaustausch mit den ERP bzw. Procurement Systemen der Kunden nicht vielleicht doch wichtiger ist.

Ein Hersteller von hochspezialisierten großen Maschinen oder Anlagen, der regelmäßig Einzelstücke oder bestenfalls Kleinserien gemäß kundenspezifischer Konfigurationswünsche fertigt, wird für diese Produkte mit einem Web Shop wenig erfolgreich sein: erstens wird ein Auftrag für solche Produkte nicht über einen Web Shop vergeben und zweitens würde die Komplexität der Konfigurationsregeln üblicherweise erhebliche Implementierungs- und Pflegeaufwände verursachen.

Eine Webseite, die sich auf die Bereitstellung qualitativ hochwertiger Informationen zu diesen Produkten, Konfigurationsoptionen, Anwendungsmöglichkeiten und Ratschlägen zu deren Betrieb konzentriert, erscheint wesentlich erfolgsversprechender.

Ein Web Shop für Ersatzteile, Betriebsmittel und ggf. Service- und Wartungsdienstleistungen kann sinnvoll sein (und wäre dabei viel einfacher zu halten als ein Web Shop für die Anlagen und Maschinen selbst).

Kurz gesagt

Kleine und mittlere Unternehmen haben oft nur relativ kleine Budgets und Mitarbeiterkapazität für Digitalisierungsprojekte und müssen diese sorgsam einsetzten. Ebenso muss mit Risiken angemessen umgegangen werden. Projekte sollten aus unternehmerischen Gesichtspunkten heraus ausgewählt werden (also ‚vom Business getrieben‘ werden). Hierbei sollten sich KMU auf die eigenen Bedürfnisse — und Stärken — besinnen und sich nicht zu sehr vom allgemeinen Hype und den Initiativen anderer Unternehmen beeinflussen lassen.

Digitalisierung in der Steuerberatung

„Digitalisierung in der Steuerberatung — das müsste für Dich doch ein Thema sein!“ sagte mir ein ehemaliger Studienkollege vor Kurzem. Obwohl ich schon vorher ein Gespräch mit einem Steuerberater zum Thema Digitalisierung hatte, zündete der Funke hier noch nicht.

Nach weiteren Impulsen und ein wenig Recherche stellt sich heraus, dass Digitalisierung in der Steuerberatung tatsächlich ein interessantes und hoch aktuelles Thema ist. Eine kurze Einführung bietet das Springer essenitals Booklet Digitale Geschäftsmodelle in der Steuerberatung von Thomas Egner.

Eine Reihe von Entwicklungen in der Steuerberatung verleihen dem Thema eine gewisse Dynamik. Hierzu gehören:

  • Zunehmende Verpflichtungen zur digitalen Kommunikation durch die Finanzbehörden
  • Wachsende Erwartungen zumindest von Teilen der Mandantenschaft (und wohl auch der eigenen Mitarbeiter) durch Digitalisierungserfahrungen im Privatleben oder in Unternehmen (auch wenn hier viele kleine und mittlere Unternehmen (KMU) noch erheblichen Aufholbedarf haben)
  • Entdeckung des Themas durch große, vormals oft stark traditionell ausgerichtete IT-Dienstleister der Branche (z.B. DATEV eG)
  • Veränderungen von Kanzleistrukturen
  • Veränderungen im Mix von Steuerberatungstätigkeiten

Die ersten beiden Punkte sind unmittelbar als relevante Treiber der Digitalisierung zu erkennen. Die letzten drei Punkte sind vielleicht erklärungsbedürftig:

Der Anteil von vormals wichtigen Tätigkeiten in Steuerberatungskanzleien wie z.B. das Belegmanagement und die Buchhaltung nimmt ab: Belege können durch Steuerpflichtige bequem elektronisch erfasst werden (falls sie nicht ohnehin digital vorliegen) und auch Buchhaltungstätigkeiten können mittels auf breiter Basis verfügbarer Software durch Mandanten selbst durchgeführt werden. Die entsprechende Software wird u.a. von den dominanten IT-Dienstleistern der Steuerberatungsbranche bereitgestellt (z.B. der DATEV eG), aber auch Drittanbieter bieten kostengünstige Softwarepakete auch für kleinere Unternehmen an.

Hierdurch steigt der Anteil digitaler Kommunikation und Zusammenarbeit zwischen Steuerberatern und Mandanten unmittelbar. Gleichzeit fallen jedoch wesentliche Tätigkeiten — und damit Umsatztreiber — zunehmend weg. Neue Ideen und ggf. Tätigkeiten müssen her, um diesen Wegfall zu kompensieren.

Die Dominanz einiger weniger IT Dienstleister bzw. Softwareanbieter macht eine effektive Differenzierung der Steuerberater schwierig, da hier „Waffengleichheit“ hergestellt wird: die Fähigkeiten eines Dienstleisters bzw. Softwarepakets (z.B. der DATEV eG) bleiben für Mandanten grundsätzlich gleich — egal durch welchen angebundenen Steuerberater diese Mandanten vertreten werden.

Wenn sich Steuerberater durch ihr Kernprodukt bzw. ihre Kerndienstleistung und auch durch die Fähigkeiten der digitalen Kernplattformen nicht effektiv differenzieren können, so muss diese Differenzierung anderweitig erfolgen. (Servicedesign und New Service Development in der Steuerberatung sind vielleicht auch einmal interessante Themen für einen Artikel.)

Eine Differenzierungsmöglichkeit ergibt sich über die Qualität des Onboarding neuer Mandanten auf die entsprechenden digitalen Plattformen, ggf. einschließlich Unterstützung der Integration gängiger Softwarepakete bzw. -dienste der Mandaten. Kanzleien mit entsprechender Erfahrung und Kompetenz können sich hier stark von weniger erfahrenen Kanzleien abheben und ihren Mandanten eine reibungslose Erfahrung bieten. (Das könnte uns irgendwann einmal zu Customer Experience Design in der Steuerberatung bringen.)

Weiteres Differenzierungspotenzial findet sich im Bereich der betriebswirtschaftlichen Beratung, die Steuerberater also sogenannte vereinbare Tätigkeiten durchführen dürfen. Dies erscheint insbesondere mit Blick auf KMU interessant, da Steuerberater hier bereits hohes Vertrauen genießen und die Unternehmen ihrer Mandanten bereits gut kennen. Damit haben sie einen nicht zu unterschätzenden Vorsprung gegenüber unternehmensfremden Beratern.

Steuerberatungskanzleien sind selbst oft kleine — und zunehmend auch mittlere — Unternehmen. Sie kennen also wesentliche Teile der Herausforderungen, denen sich ihre Mandanten im Zuge der Digitalisierung gegenübersehen, aus erster Hand. Sie könnten sich also recht gut relevante Erfahrung und die damit verbundene Glaubwürdigkeit aus Sicht ihrer Mandanten erarbeiten.

Es ist sinnvoll zu prüfen, ob die Digitalisierungsberatung von KMU Mandanten ein sinnvoller Aspekt der betriebswirtschaftlichen Beratung in entsprechend digital-affinen Steuerberatungskanzleien sein sollte.

Ich höre und lese, dass neue Steuerberater immer seltener den Weg in die Selbständigkeit einschlagen und immer öfter eine feste Anstellung wählen. Dies führt dazu, dass die (durchschnittliche) Größe von Steuerkanzleien steigt und ihre Anzahl sinken wird. Mit zunehmender Größe wächst auch die Wirtschaftskraft, so dass größere Investitionen in die Digitalisierung und entsprechende Kompetenzen möglich werden. Auch kann dann die Einstellung von Mitarbeitern außerhalb des Kernbereichs der Steuerberatung (z.B. Betriebswirtschaftler, ggf. auch Informatiker?) wirtschaftlich abbildbar werden.

Im Rahmen dieser Überlegungen ist stets zu prüfen, welche Grenzen durch regulatorische Einschränkungen gesetzt werden, z.B. wo der Rahmen der vereinbaren Tätigkeiten verlassen würde.

Nicht ganz uneigennützig weise ich darauf hin, dass die Zusammenarbeit mit qualifizierten Freiberuflern, die ein breites Spektrum betriebswirtschaftlicher und technischer Digitalisierungsthemen abdecken können, sinnvoll sein kann. Insbesondere in frühen Phasen der Beschäftigung mit dem Thema Digitalisierung lassen sich so Kosten und Risiken effektiv managen und Chancen erfolgreich nutzen.

Über einen völlig unverbindlichen Austausch zu diesem spannenden Thema würde ich mich freuen.


Ich mutmaße, dass es ähnliche Entwicklungen auch in den Bereichen der Wirtschaftsprüfung und Rechtsberatung gibt, auch wenn sich deren Auswirkungen im Detail sicherlich von denen in der Steuerberatung unterscheiden. Auch hier wäre ich an einem Austausch stark interessiert.


Eigentlich sollte es klar sein, aber hier noch einmal ausdrücklich: Ich biete keine Steuerberatung, Wirtschaftsprüfung oder Rechtsberatung an. Dieser Artikel stellt lediglich betriebswirtschaftliche Überlegungen dar.

Prototyping ist Discovery-Arbeit

Agile Methoden haben unsere Arbeit revolutioniert — in der Softwareentwicklung und weit darüber hinaus.

Auffällig ist, dass diese Verbesserungen sich stark auf Delivery-Tätigkeiten konzentrieren, zumindest in großen Unternehmen und solchen Unternehmen, die auf lange Erfahrung in Softwareentwicklung und Systemintegration zurückblicken.

Obwohl durch die Bank zunehmend über die Wichtigkeit von Design und Design Thinking gesprochen wird sind hinsichtlich Discovery-Tätigkeiten weniger greifbare Fortschritte zu beobachten.

Zu oft kommen noch (ausschließlich) klassisches Anforderungsmanagement und traditionelle Business-Analysis-Ansätze zum Einsatz. De facto glauben viele Kunden und Dienstleister immer noch, Projektergebnisse und Produkte früh im Prozess zumindest auf konzeptioneller Ebene belastbar — und abschließend — definieren zu können.

Für Initiativen mit hohem Innovationscharakter ist dies jedoch eine Fehleinschätzung. Innovation erfordert regelmäßig ein exploratives Vorgehen nicht nur bezüglich des Lösungsentwurfs und der anschließenden Umsetzung (d.h. Delivery), sondern insbesondere auch für die Situationsanalyse, Problemidentifikation und Problemauswahl (d.h. Discovery).

Prototyping kann ein essenziell wichtiges Discovery-Werkzeug sein. Die Entwicklung von Prototypen zur Evaluierung der technischen Machbarkeit einer bestimmten Lösung (Proof-of-Concept) ist bekannt, wird in meiner Erfahrung jedoch in der Softwareentwicklung weniger oft eingesetzt als es sinnvoll erscheint. Dies mag damit zusammenhängen, dass die hierfür notwendige Softwareentwicklung oft als Delivery-Arbeit angesehen wird und die damit konkurrierende Entwicklung neuer Features regelmäßig höher priorisiert wird.

Eine hohe Umsetzungsgeschwindigkeit kommt vor allem daher, das richtige Produkt zu entwickeln. Wir wollen also nur die Elemente tatsächlich entwickeln, die mit hoher Wahrscheinlichkeit erfolgreich sein werden. Entsprechende Tests müssen dann also in der Discovery erfolgen.

Erinnern wir uns daran, dass erfolgreiche Produkte nicht nur technisch machbar (technical feasibility) sondern auch kommerziell tragfähig (business viability) und für Menschen wünschenswert (desirability to humans) sein müssen (siehe z.B. https://www.google.com/search?tbm=isch&q=desirable+feasible+viable).

Es liegt auf der Hand, dass Prototyping auch für diese beiden anderen Dimensionen sinnvoll und notwendig ist. Unterschiedliche Aspekte von Desirability können im Rahmen der Product Discovery gut mit Hilfe von Prototypen evaluiert werden: Ist das Problem, das wir erkannt haben, real? (Gibt es genügend Menschen, die die Situation auch als Problem wahrnehmen?) Löst die von uns anvisierte Lösung das Problem effektiv?

Auch die kommerzielle Tragfähigkeit können wir über Prototypen im Rahmen unserer Discovery-Tätigkeiten evaluieren: Können wir aus der anvisierten Lösung ein tragfähiges Produkt machen? Gibt es einen Markt für dieses Produkt (bzw. können wir einen Markt schaffen), d.h. würden genug Kunden für dieses Produkt genug Geld ausgeben?

(Siehe hierzu auch The Lean Startup.)

Wichtig ist, dass diese Prototyping-Tätigkeiten klar dem Bereich Discovery zuzuordnen sind. Dies ist insbesondere wichtig, falls Software-Prototypen entwickelt werden. Die entsprechenden Aktivitäten konkurrieren also ggf. mit anderen Discovery-Tätigkeiten — sie sollten jedoch niemals mit Delivery-Tätigkeiten in Konkurrenz stehen, da letztere sonst oft (mit negativen Folgen für die gesamte Initiative) höher priorisiert werden.

Selbstverständlich wollen wir auch im Rahmen der Discovery-Tätigkeiten die Kompetenz des gesamten Teams zum Einsatz bringen. Das heisst, das auch eher ‚delivery-orientierte‘ Teammitglieder in die Discovery einbezogen werden — und dies schließt Softwareentwickler ausdrücklich mit ein und zwar nicht nur für die Entwicklung von Software-Prototypen.

Kurz: Ein stärkerer Fokus auf Discovery-Arbeit kann die Produktentwicklung erheblich verbessern und beschleunigen. Die Entwicklung von Prototypen ist Discovery-Arbeit. Das gilt insbesondere für die Entwicklung von Software-Prototypen.

Discovery & Delivery: erst das Problem, dann die Lösung

Bei Kunden und Dienstleistern gibt es die Tendenz, sich stark auf die Delivery-Aspekte von Projekten und digitalen Initiativen zu konzentrieren: ein möglichst schneller Lösungsentwurf und die anschließende Umsetzung der Lösung rücken in den Vordergrund. Dieser Ansatz ist jedoch bestenfalls für Situationen geeignet, in denen nicht nur eine angemessene Lösung, sondern auch das zugrunde liegende Problem offensichtlich sind. Diese Situationen entsprechen der Simple Domain des Cynefin Framework — der einzigen Domäne dieses Modells, in der Best Practices sinnvoll anwendbar sind.

Wirklich interessante Probleme fallen jedoch in der Regel nicht in diese Domäne. Beispiele für solch interessante Probleme sind die Entwicklung eines neuen Produkts, die Erschließung eines neuen Marktes oder der Versuch, die Conversion Rate einer Webseite wesentlich zu verbessern.

In diesen Situationen sind effektive Lösungen nicht offensichtlich erkennbar, sondern müssen mittels eines explorativen Prozesses iterativ und inkrementell entwickelt werden. Agile und schlanke Methoden bieten hierfür geeignete Ansätze, die mittlerweile auch von großen Teilen der Wirtschaft eingesetzt oder zumindest anerkannt werden.

Weniger verbreitet ist jedoch die Erkenntnis, dass in solchen Situationen in der Regel auch das zu lösende Problem nicht offensichtlich ist: vielmehr muss aus einer ersten vagen Idee im Rahmen von Discovery-Tätigkeiten eine effektive Problemdefinition entwickelt werden. Zu diesen Tätigkeiten gehören die Analyse unterschiedlicher Aspekte der zugrunde liegenden Situation, die Identifikation möglicher Probleme oder Chancen sowie die schlussendliche Auswahl des durch eine bestimmte Initiative zu lösenden Problems.

Auch in der Discovery kommen explorative Ansätze sowie ein inkrementelles, iteratives und interaktives Vorgehen zum Einsatz. Insbesondere kann die iterative Konkretisierung der Problemdefinition (z.B. auf Basis von ‚Experimenten‘ mit potenziellen oder tatsächlichen Kunden) sehr wirkungsvoll sein. Die Lean Startup Methode bietet hierfür effektive Ansätze.

Der Design Thinking Ansatz und das Double Diamond Modell des Designprozesses (sowie viele andere Designprozesse) beschreiben die Notwendigkeit solcher Discovery-Tätigkeiten im Designprozess (allerdings differenzieren sie feiner als ich das hier mit dem einfachen Discovery/Delivery-Modell tue).

Einige Dienstleister schalten den Delivery-Phasen ihrer Projekte mittlerweile eine Discovery-Phase vor. Dies ist begrüßenswert, aber noch nicht ausreichend. Um größtmöglichen Nutzen zu erzielen, muss Discovery auch auf detaillierteren Ebenen innerhalb eines Projekts zum Einsatz kommen, z.B. für einzelne Features oder Funktionen.

Die Entwicklung von Prototypen mittels geeigneter Prototyping-Werkzeuge (und nicht etwa mittels Softwareentwicklung) kann die Produktentwicklung erheblich verbessern und beschleunigen — mehr dazu in Prototyping ist Discovery-Arbeit.

Welche pragmatischen Ansätze gibt es, um Ihre Discovery-Praxis — und damit Ihre Leistung in der Produktentwicklung — zu verbessern? Sprechen Sie mich an, um erste Ideen zu diskutieren!

Digitalisierung in Industrie-, Handels- und Dienstleistungsunternehmen

Klassische Industrie-, Handels- und Dienstleistungsunternehmen sehen sich gegenüber Digital Pure Plays (also Unternehmen, die ihr Geschäft rein digital betreiben und auf klassische Verkaufs-, Marketing- und Kommunikationskanäle verzichten) oft im Nachteil. Auf den ersten Blick ist dieser Eindruck nachvollziehbar. Bei genauerer Betrachtung zeigt sich jedoch oft, dass die Situation wesentlich differenzierter zu betrachten ist.

Natürlich sind die Medien voll von teils reißerischen Artikeln über das Silicon Valley, das neueste Startup oder auch bereits etablierte Digital Pure Plays. Hierbei fällt oft unter den Tisch, dass viele dieser Unternehmen eine höchst aggressive Wachstumsstrategie verfolgen — und Profitabilität hier keine oder nur eine untergeordnete Rolle spielt. Venture Capitalists investieren regelmäßig in viele unterschiedliche Startups, so dass das Überleben jedes einzelnen Unternehmens nicht besonders wichtig ist.

Etablierte Unternehmen aus Industrie, Handel und Dienstleistung — d.h. etablierte Unternehmen der Realwirtschaft — haben hier oft eine völlig andere Ausgangslage. In Deutschland trifft dies insbesondere auf Unternehmen des Mittelstands zu. Diese Unternehmen sind regelmäßig erfolgreich (oft schon seit vielen Jahren oder gar Jahrzehnten), kennen ihre Kunden (und oft auch deren Kunden) genau und entwickeln ihre Produkte kontinuierlich fort. Strategien, Lieferketten und Geschäftsprozesse sind bewährt.

Digitalisierungsinitiativen in solchen Unternehmen sollten auf diesem Fundament aufbauen anstatt diese Errungenschaften über Bord zu werfen! Digital Business ist und bleibt Business: vieles von dem, was diese Unternehmen erfolgreich gemacht hat wird durch die Einführung einer Digital Business Plattform oder die Digitalisierung von Kernprozessen nicht plötzlich falsch.

Natürlich bietet jede Digitalisierungsinitiative die Gelegenheit, die eigenen Prozesse, Praktiken und Annahmen kritisch zu überprüfen und ggf. zielgenau zu verbessern. „Wir machen jetzt alles anders!“ ist jedoch kein erfolgversprechender Ansatz für die Digitalisierung eines etablierten Unternehmens.

In einigen Situationen kann das klassische Geschäft sogar neue Digitalisierungsinitiativen beeinflussen und deren Erfolgsaussichten verbessern. Beispielsweise verfügen etablierte Unternehmen oft über erhebliche Kompetenz im Bereich Produktentwicklung und haben eine starke Innovationskultur. Beides sollte die Entwicklung digitaler Produkte inspirieren und deren Ansätze und Kultur können sich an bestehenden erfolgreichen Beispielen orientieren. Dies macht Lernerfahrungen aus dem Kerngeschäft auch im digitalen Bereich nutzbar und kann die Zusammenarbeit und das ‚Alignment‘ zwischen etablierten und neuen digitalen Unternehmensbereichen erheblich vereinfachen und verbessern.

Auf welchen Stärken Ihres Unternehmens können Ihre Digitalisierungsinitiativen aufbauen? Welche etablierten Unternehmensbereiche könnten von Ansätzen, Methoden und Arbeitsweisen aus dem digitalen Umfeld profitieren? Wie startet man eine Digitalisierungsinitiative in kleinen und mittleren Unternehmen (KMU) ohne sich vom Hype ablenken zu lassen? Kontaktieren Sie mich, um ein unverbindliches erstes Gespräch zu führen!

Erfolg durch Integration und Evolution

Integration und Evolution sind zwei essenzielle Erfolgsfaktoren für digitale Initiativen sowohl im Bereich Digital Commerce als auch im Bereich Analytik, insbesondere wenn höher entwickelte Techniken wie Machine Learning oder Künstliche Intelligenz zum Einsatz kommen.

Integration bedeutet sicherzustellen, dass die einzelnen Bestandteile einer Initiative ein schlüssiges Ganzes ergeben und dabei effektiv und effizient zusammenarbeiten. Dies bezieht sich natürlich auch auf technische Systeme und Komponenten — viel wichtiger ist jedoch das Zusammenwirken von Menschen über die Grenzen von Organisationseinheiten und von Unternehmen hinweg. Hier geht es oft um die Einbeziehung von Mitarbeitern aus unterschiedlichen Fachbereichen, die Abdeckung unterschiedlicher Stakeholder-Interessen und die Berücksichtigung der Bedürfnisse unterschiedlicher Kunden, Nutzer oder anderweitig Betroffener.

Der Fokus auf bestmögliche Integration zieht sich idealerweise wie ein roter Faden von der Formulierung einer ersten Idee für eine neue digitale Initiative über Discovery (d.h. Situations- und Problemfeldanalyse), Problem- oder Projektdefinition, Roadmap- und Konzeptentwicklung bis hin zur Delivery (d.h. Lösungsumsetzung und -inbetriebnahme).

Evolution bedeutet hier die schrittweise Erweiterung und Verfeinerung der Ergebnisse digitaler Initiativen, d.h. in der Regel die schrittweise Entwicklung einer digitalen Plattform. Hierbei steht die konsequente Anwendung inkrementeller und iterativer Methoden im Vordergrund.

Insbesondere hinsichtlich der iterativen Entwicklung von Produkten oder einzelner Plattformfähigkeiten gibt es in der Praxis regelmäßig erhebliches Verbesserungspotenzial. In diesem Zusammenhang können Discovery und Delivery Tätigkeiten oft besser voneinander getrennt werden und dann jeweils geeignete Werkzeuge und Methoden optimal zum Einsatz gebracht werden.

Ein wirklich evolutionärer Entwicklungsansatz erlaubt es, erarbeitete Ergebnisse früh zum Einsatz zu bringen — und dadurch bereits früh (gemessen an der Gesamtdauer der Initiative) Nutzen aus diesen Ergebnissen zu ziehen (z.B. Kostenersparnis, Umsatzerhöhung, Verbesserung des Kundenerlebnisses). Dieser Nutzen trägt dazu bei, die positive Wahrnehmung der und die Unterstützung für die Initiative im Unternehmen zu verbessern. Im Idealfall tragen diese Ergebnisse sogar zur Finanzierung späterer Phasen der Initiative bei (z.B. durch Kostenersparnis oder Umsatzerhöhung).

Gute Integration und konsequente Evolution können die Ergebnisse digitaler Initiativen erheblich verbessern — und dies nicht nur in Großkonzernen sondern auch in kleinen und mittleren Unternehmen (KMU), insbesondere auch in nicht IT-zentrischen Unternehmen in Industrie und Handel. Ein pragmatisches Vorgehen mit greifbaren Ergebnissen ist möglich.

Sprechen Sie mich an, um die Relevanz dieser Überlegungen für digitale Initiativen in Ihrem Unternehmen zu besprechen!