Wenige erlauben sich einen ganzheitlichen Blick, auch wenn dieser zu hilfreichen Erkenntnissen führt: mangelnder ganzheitlicher Blick, ungenaue Kenntniss von Prozesskosten, mangelhaftes Verständnis füreinander und schlechte “Usability” von  Nutzerschnittstellen sind wesentliche Fehlerquellen. Solche, teilweise grundsätzlichen Überlegungen, bergen das größere Optimierungspotential. Es wird befürchtet, dass diese Themen, einmal begonnen, zu viel Zeit in Anspruch nehmen.

Offensichtlicher und daher häufiger in Diskussion sind Themen wie fehlerhafte oder unfertige Programme oder Systeme, unzureichende Vernetzungen, oder uneinheitliche oder mehrdeutige Daten.

Ein Blick zurück offenbart die sieben häufigsten Fehlerquellen, die wir bei Analysen und Tests von Geschäftsprozessen festgestellt haben. Man sollte sich auf vier Themen konzentrieren, die möglicherweise grundsätzlicher Natur sind:

• Der ganzheitliche Blick geht verloren: zu schnelle Entwicklung von Prozessen führt zu Qualitätsproblemen; zu langsame Entwicklung derselben verschlechtern die Wettbewerbssituation. Ausnahmen werden betont anstatt minimal erforderliche Prozesse fehlerfrei zu implementieren.
• Die Kosten werden zu ungenau geschätzt: oft gibt es keine klare Aussagen zu den Kosten einzelner Prozessschritte. Deshalb werden Prioritäten grob geschätzt.
• Absprachen und das Verständnis füreinander sind mangelhaft: die wahren Bedürfnisse der Kunden werden vielfach falsch eingeschätzt. Auch durch unternehmensinterne Missverständnisse entstehen so fehlerhafte Schnittstellen, unnötig lange Prüfungen oder Risikofaktoren.
• Die Nutzbarkeit („Usability“) von Nutzerschnittstellen ist zu gering. Dazu zählen wir nicht nur Internetseiten oder andere graphischen Benutzeroberflächen, sondern auch Dokumente, Korrespondenz, Telefonate und Verträge.

In der Praxis stellt man drei häufige Probleme in den Mittelpunkt:

• Programme oder Systeme sind nicht rechtzeitig fertig oder fehlerhaft. Dies ist ein andauerndes Streitthema, da Anforderungen genauso wie Technik die Ursache bilden können.
• Vernetzungen sind fehlerhaft:  verdeckte Abhängigkeiten, implizite Annahmen, unklare Statusmeldungen, nicht eingehaltene oder uneinheitliche Definitionen führen zu Schnittstellenfehlern.
• Daten sind uneinheitlich oder mehrdeutig:  Migrationssünden, Dubletten,  Fehler in der Konfiguration, mehrdeutige Bezugsgrößen, fehlende Definitionen, unsaubere Messungen oder subjektive Interpretationen sind die Quelle für Fehlinterpretationen oder fehlende Reproduzierbarkeit.

Das mangelhafte Training  von Mitarbeitern zur Einstellung auf neue Prozesse ist ebenfalls ein häufig anzutreffendes Problem. Wir sehen dies nicht als wesentliche Fehlerquelle, weil vielfach obige Probleme zugrunde liegen.

Das Resultat sind oftmals unzureichende Kundenkontakte, die zu einem großen Kostenfaktor werden. Eine Studie von 2009 von  Datamonitor/Ovum in England (unterstützt von Genesys Telecommunications Laboratories, Inc., Alcatel-Lucent) kommt zu dem Schluss, dass ein wesentlicher Kündigungsgrund unzureichender Kundenservice ist (über 73% der Teilnehmer der Studie), und dass intelligenterer Self-Service dringend angeraten ist, damit Kunden nicht in schlecht automatisierten Systemen verloren gehen.

Deshalb sollten Prozesse immer wieder durch Kunden getestet werden.

Stolpersteine im Prozessmanagement sind oftmals nicht nur falsch aufgestellte IT-Systeme: Mitarbeiter, Prozesse und Systeme harmonieren nicht, oder einzelne kritische Probleme verzögern gesamte Prozessketten.

Die vorgeschlagenen Tests bieten Sicherheit bei überschaubarem zeitlichen Aufwand, wenn sie professionell durchgeführt werden.

Im Einzelnen hilft Cridon bei den folgenden Fragen:

• „Wie garantieren und verbessern wir unseren Kundenservice?“
  • Model Office (Tests) bereiten den Kundenservice auf neue Aufgaben vor oder helfen bei der Optimierung
  • Kundenservicetests prüfen, bevor dies ein anderer tut
• „Funktionieren alle Geschäftsprozesse?“
  • Prozesstests testen End-to-End unter Beteiligung der Mitarbeiter,
  • Operational Readiness Tests untersuchen die Betriebsbereitschaft vor Start von neuen Prozessketten, und
  • Systemtests und System-Integrationstests bilden die Basis dafür.
• „Wo können wir vereinfachen und Kosten sparen?“ Alle obigen Tests können dazu beitragen.

Diese Prozesstests sind Teil des 15 sinnvolle und erprobte Kundentests umfassenden Cridon CTC Customers‘ Testing Center. Cridon hat Tests durch echte Kunden analysiert, und kommt zu dem Schluss, dass diese überlegene Dienste leisten, wenn die wesentlichen Erfolgsfaktoren beachtet werden. Das Customers‘ Testing Center bietet

• die Möglichkeit mit echten Kunden im Sinne der „Open Innovation“ zu testen
• die leichte Auswahl des passenden Tests zu den Themen Produkte und Service, Geschäftsprozesse und Marketingansatz
• professionelle Planung. Um Trugschlüsse zu vermeiden ist dies ebenso wichtig, wie die eigentliche Durchführung der Tests
• zielgerichtete Auswertung. Mit unserem Beratungshintergrund können wir optimierende Quick Wins oder zukunftsweisende und disruptive Alternativen in den Mittelpunkt der Betrachtung rücken

Cridon bietet so die Möglichkeit, die Risiken der Einführung neuer Produkte und Services zu minimieren und für eine höhere  Innovationsbereitschaft einzustehen.

Cridon bietet eine Vielzahl solcher Tests an und stellt diese im Cridon CTC Customers’ Testing Center  basierend auf unserer über 15 jährigen Erfahrung und unseren Recherchen vor. Wir bieten so die Möglichkeit, die Risiken der Einführung neuer Produkte und Services zu minimieren und für eine höhere  Innovationsbereitschaft einzustehen.

Das Cridon CTC Customers‘ Testing Center umfasst 15 erprobte Tests. Cridon hat Tests durch echte Kunden analysiert und kommt zu dem Schluss, dass diese überlegene Dienste leisten, wenn die wesentlichen Erfolgsfaktoren beachtet werden. Das Customers‘ Testing Center bietet

• die Möglichkeit mit echten Kunden im Sinne der „Open Innovation“ zu testen
• die leichte Auswahl des passenden Tests zu den Themen Produkte und Service, Geschäftsprozesse und Marketingansatz
• professionelle Planung. Um Trugschlüsse zu vermeiden ist dies ebenso wichtig, wie die eigentliche Durchführung der Tests
• zielgerichtete Auswertung. Mit unserem Beratungshintergrund können wir optimierende Quick Wins oder zukunftsweisende und disruptive Alternativen in den Mittelpunkt der Betrachtung rücken

Das Cridon Test Center umfasst

• Marketingtests: Diese Tests prüfen, ob, wo und in welcher Ausprägung ein Produkt oder eine Dienstleistung am besten verkauft werden kann:
  • A/B Test (Variantentest, Shelf Test)
  • Marketing Message Test
  • Markttest
  • Friendly User Test (Customer Trial)
  • Feldtest
• Prozesstests: Ob Prozesse funktionieren, und wie schnell bzw. wie gut diese funktionieren lässt sich mit Prozesstests prüfen (siehe White-Paper zu Prozesstests). Diese umfassen meist die gesamte Organisation:
  • Kundenservicetest
  • Prozesstest und Prozess-Integrationstest
  • Operational Readiness Test
  • Model Office Test
  • Systemtest und System-Integrationstest
• Produkttests: Diese Tests prüfen, ob ein Produkt oder eine Dienstleistung funktioniert, und wie Kunden darauf reagieren;
  • Usability Test (User Interface Test)
  • Produkttest
  • Servicetest
  • Operational Readiness Test
  • Prototypentest

Einige dieser Tests betrachten die gesamte Wertschöpfungskette und lassen sich als End-to-End Tests bezeichnen (in obiger Graphik durch “*” markiert).

Wir haben seit über zehn Jahren Erfahrung mit der Organisation von Tests, die gesamte Unternehmen umfassen. Gerne beraten wir bei der Konzeption und der Durchführung dieser Tests.

Vor der Betriebsaufnahme eines neuen Produkts oder eines neuen Service ist es bei komplexen Umgebungen sinnvoll zu prüfen, ob ein Geschäftsprozess überhaupt funktioniert. Dann spricht man von einem Prozess-Integrationstest (PIT).

Allen Prozesstests ist gemein, dass Sie End-to-End durchgeführt werden müssen, um sinnvolle Ergebnisse zu erhalten.

Marketingperspektive

Prozess-Integrationstests liefern erstmals während der Entwicklung eines neuen Produkts oder einer neuen Dienstleistung eine nahezu fertiges System. Prozesstests zeigen auf, an welcher Stelle im Geschäftsprozess Optimierungsbedarf besteht.

Es empfiehlt sich, dieses Tests zu begleiten, um ein erstes Verständnis dafür zu erhalten, ob das Produkt oder die Dienstleistung entsprechend Ihren Erwartungen Kundennutzen generiert.

Das Cridon Angebot

Prozesstests können relativ einfach durchgeführt werden, da man mit im Betrieb befindlichen Einheiten arbeiten kann.

Hier ist das Augenmerk vor allem darauf zu legen, dass der Test repräsentativ ist, und die Auswertung auf der Basis von ausreichend vielen Daten erfolgt und statistisch gesehen korrekt ist.

Prozess-Integrationstests müssen sehr genau vorbereitet werden um einerseits die technische Komplexität hinreichend zu prüfen, und andererseits gestellt Anforderungen zu berücksichtigen.

Da der PIT kurz vor Vertriebsstart durchgeführt wird, ist der Zeitdruck meist hoch. Es empfiehlt sich dann, einen “War Room” einzurichten, in dem der Fortschritt bei der Lösung der wichtigsten Probleme regelmäßig und häufig diskutiert wird.

Unser High-Level Projektplan

Ziel definieren

(Test-)Kunden akquirieren

• Zielgruppe definieren und “n” ermitteln
• Testpersonen ermitteln und einladen

(Test-)Kunden binden

• Testvertrag abschließen
• Termin fixieren

Produkt  oder Service auswählen

Test planen

• Testcases und/oder Testszenarien definieren
• Testdaten vorbereiten
• Erwartete Ergebnisse definieren
• Testpunkte definieren
• Testfahrplan erstellen

Produkt  oder Service bereitstellen

• Systeme zum Test bereitstellen
• Organisation zum Test bereitstellen (Launch)
• Verkaufskanal an Testkunden kommunizieren

Auswertung des Tests vorbereiten

• Berichte und Statistiken anfordern
• Trackingsoftware konfigurieren

Test durchführen

Test auswerten

• Protokoll erstellen
• Zahlen prüfen und auswerten
• Fehler notieren, priorisieren und lösen

Analyse und Empfehlung erstellen

• Ergebnisse interpretieren
• Handlungsempfehlungen auszeigen

Unsere Erfahrung

Jürgen H. Stäudtner hat bei o.tel.o communications die Abteilung Prozess-Integrationstest geleitet und unter anderem den Start der Produkte “Intelligent Networks” sowie “o.tel.o und business online” begleitet.

Expertenwissen bei der

• Definition erreichbarer Testziele und präziser Testplanung
• Testdurchführung
• Auswertung und der Analyse des Tests und dem Ableiten von Empfehlungen

Anmerkungen

Risiko

Bei einem Prozesstest müssen vor allem die Messung und Auswertung professionell erfolgen. Sonst können “Probleme” entstehen, die keine sind aber viel Zeit erfordern.

Der Aufwand für einen Prozess-Integrationstests kann sehr hoch werden, wenn nicht frühzeitig Testziel und die Testfälle ausgearbeitet kommuniziert werden. Sonst besteht die Gefahr, dass zu viele oder zu wenige Einheiten zum Testzeitpunkt einsatzbereit sind.

Verantwortung

Geschäftsprozessabteilung (wenn existent) oder zentrale IT Abteilung.

Operativer Einheiten und deren Mitarbeiter werden einbezogen.

Voraussetzungen

Prozess-Integrationstest: Isolierte Systemumgebungen; Prozesstest: produktive Umgebungen.

Klare Definition der Kriterien zu Erklärung der Systembereitschaft im Vorfeld des Tests.

Sorgfältige Vorbereitung der Testfälle, -szenarien und -daten.

Zustimmung der gesamten Organisation.

Alle Prozesstests sollten mit bekannten und ggf. ausgewählten Testkunden arbeiten.
Note: There is a print link embedded within this post, please visit this post to print it.

Nachfolgend sind einige Erfolgsfaktoren für End-to-End Tests aufgeführt, um Sie vor Entäuschungen zu schützen. Verkauszahlen, die unter den Erwartungen liegen, hohe Test- und Entwicklungskosten, organisatorische Probleme und unpassende Informtionstechnologie werden häufig beklagt. Deshalb sollte der Endkunden im Mittelpunkt stehen, Tests strukturiert geplant werden, die operative Organisation involviert werden und berücksichtigt werden, dass gestellte Anforderungen veraltet sein können.

Ausrichtung am Endkunden

End-to-End Tests schützen nicht zwingend vor Verkaufszahlen, die unter den Erwartungen liegen. Vor allem dann, wenn konzeptionelle Fehler vorliegen, oder die Ausrichtung auf den Kunden mangelhaft ist. Deshalb sollte die Konzeption eines Produkts ggf. in einem End-to-End Test hinterfragt werden. Außerdem muss klar sein, dass die Qualität oder die Schönheit eines Produkts letztendlich von Kunden beurteilt werden, und nicht von den an der Entwicklung eines Projektes Beteiligten. Letztlich muss  von Anfang an das Angebot eines Unternehmens klar am vorhandenen oder erwarteten Kundenwunsch gemessen werden.

Strukturierte Testplanung

Häufig liegt die Wahrnehmung von hohe Kosten von End-to-End Tests darin begründet, dass die Aussagefähigkeit der Testergebnisse beschränkt ist. Tests müssen gründlich geplant, und fokussiert durchgeführt werden um verlässliche Ergebnisse hervorbringen. Die 80/20 Regel ist bei Tests nur dann anwendbar, wenn man weiß, dass Fehler in nicht getesteten Bereichen nicht kritisch sind. Unsauber ausgeführte Tests sind keine Garantie für Funktion und können unterbleiben.

Außerdem sollte der Aufwand für Tests im Auge behalten werden. Tests sollten z.B. immer aufeinander aufbauen um zu vermeiden, dass sich Tests überschneiden und zu großer Testaufwand die Organisation lähmt. Der Umfang eines Tests kann genau definiert werden – hier gilt die Regel „wenig aber gut testen“.

Einbeziehung der operativen Organisation

Bei allen End-to-End Tests oberhalb von Prozess-Integrationstests sind operative Abteilungen und deren Mitarbeiter beteiligt. Es ist darauf zu achten, dass diese Kollegen keine gesonderten Schulungen durchlaufen, sondern sich der Materialien bedienen, die im operativen Betrieb nach Einführung eines Produkts vorliegen. Nur so können dort Schwachstellen gefunden werden, die für die Wahrnehung eines Produktes ebenso wichtig sind, wie Informationssysteme.

Übergangene Abteilungen können die Einführung fertig getesteter Produkte oftmals zu Recht blockieren. Operativer Abteilungen sollten nicht vor vollendete Tatsachen gestellt werden. Auch Abteilungen, die die Dienstleistung den Kunden anbieten müssen einbezogen werden, und müssen als Messlatte dienen – die Meinung operativer Mitarbeiter muss gehört werden.

Differenzierung zwischen Pflichtenheft und aktuellen Anforderungen

In den meisten End-to-End Tests treten zunächst Fehler in Informationssystemen zu Tage. Deshalb sollte die Funktion eines Systemes geprüft und abgenommen sein, bevor ein solcher Test beginnt. Die Abnahme von Systemen erfolgt grundsätzlich nur auf den Anforderungen (Pflichtenheft) nach Vertrag, denn Lieferanten arbeiten meist auf der Basis von Anforderungen, und sollten danach beurteilt werden.

Unstimmigkeiten in den Anforderungen sind oftmals keine Fehler der Entwickler, sondern Folge der schnellen Änderungen der Umwelt oder in ungenauen Anforderungen begründet. Solche Fehler zu finden, sind mit die Hauptaufgabe von End-to-End Tests und sollten provoziert werden. Entscheidend ist, wie die Anforderungen des Geschäftes in den Entwicklungsprozess aufgenommen, und Änderungen eingebaut werden, denn Systeme können oft auf vielfältige Art und Weise eingesetzt werden. Deshalb werden Anforderungen oft anders erfolgreich implementiert als ursprünglich diskutiert.

Siehe auch die Artikel zu den Definition für End-to-End Tests und der Arten dieser Tests, die wir bereits erfolgreich organisieren konnten.

Wir haben bereits eine Reihe von End-to-End Tests in komplexen Umgebungen aus Organisation, Prozessen und Systemen durchgeführt und unterstützen Sie gerne bei der Konzeption und der Durchführung eines End-to-End Tests.

• schnelle Entwicklung einen Marktvorteil bedeutet,
• viele Einflüsse auf ein Entwicklungsprojekt zu geänderten Anforderungen führen, und
• die Zufriedenheit der Kunden und Mitarbeiter oberstes Kriterium ist.

Der Einsatz agiler Methoden sollte überdacht werden, wenn

• komplexe Sachverhalte zu bewältigen sind oder sehr hohe Qualität erforderlich ist,
• die andauernde Pflege der Systeme bedacht werden muss, und wenn
• fachliche Kreativität und disruptive Innovation gewünscht sind

Was sind agile Entwicklungsmethoden?

Im Jahr 2001 wurde von einigen Entwicklern, das “Agile Manifesto” veröffentlicht und unterzeichnet. Das Manifest legt Prinzipien fest, die bei kunden- und ergebnisorientierten Arbeiten beachtet werden sollten. Das Manifest charakterisiert die Ziele vieler agiler Methoden und fasst diese zusammen mit

• “Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan”

Agile Methoden stellen deswegen das eigentliche Programmieren in den Vordergrund und nicht häufig diskutierte klassische Themen wie Dokumentation, umfangreiche Abstimmungen und Struktur. Gelegentlich kann es bei agilen Methoden deshalb auch dazu kommen, dass Programme neu erstellt werden müssen.

Stellt man die Dimensionen „Anzahl der Iterationen“ und „Komplexität pro Zyklus“ gegenüber, so lässt sich argumentieren, dass agile Methoden dort gut angesiedelt sind, wo Geschwindigkeit vor Komplexität geht. „Wassferfall“ Methoden sind eher auf ausführliche Abstimmungsprozesse ausgelegt um die bestmögliche Lösung in wenigen Iterationen zu erreichen.

Was ist Scrum?

Scrum wurde in den 90er Jahren von zwei Unterzeichnern des Agilen Manifests Ken Schwaber und Jeff Sutherland entwickelt. Letzterer hat 2003 mit zwei Partnern die “Scrum Alliance” ins Leben gerufen. Diese ermöglicht eine Zertifizierung und trägt zu der Popularität von Scrum bei.

Teammitglieder organisieren ihre Arbeit hier weitgehend selbst und wählen auch die eingesetzten Software-Entwicklungswerkzeuge und -methoden. Mittels eines Product-Backlog werden kleinere Entwicklungspakete abgegrenzt, die von einer überschaubaren Mannschaft (z.B. 5 Entwickler in einem Monat) in so kurzer Zeit umgesetzt werden können, dass das System getestet und einsatzbereit ist. Mit vielen, klar strukturierten Meetings zum Teil auf täglicher Basis wird ein intensiver Kontakt zwischen der fachlichen und der technischen Seite des Projekts hergestellt. Diese Gespräche werden nur grob und oft handschriftlich dokumentiert und ersetzten so oft die Dokumentation.

Jeff Sutherland erklärt Scrum auch so: „Scrum is …

• an agile process to manage and control development work …
• a team-based approach to iteratively, incrementally develop systems and products when requirements are rapidly changing
• a process that controls the chaos of conflicting interests and needs
• a way to improve communications and maximize co-operation …
• a way to maximize productivity.
• Scrum is scalable from single projects to … projects with over a thousand developers and implementers.

Pro und Contra

Schnelle Entwicklung

Agile Methoden sind im Vorteil, wenn die Geschwindigkeit der Entwicklung wesentlich ist. Die Abstimmung zwischen Entwicklern und den anfordernden Parteien erfolgt schnell und wird nur dokumentiert, wo dies nötig erscheint.

Unabhängigkeit von externe Einflüssen

Projekte werden in kleine Einheiten unterteilt. Gerade bei Scrum sind diese Einheiten auch so gestaltet, dass nach kurzer Zeit bereits Produkte entstehen, die getestet und lauffähig sind.  So ist auch bei grundlegenden Änderungen ein Produkt vorhanden, das funktioniert.

Zufriedene Kunden und Mitarbeiter

Kunden können in Abstimmungen stark einbezogen werden. Damit haben sie viel Einfluss auf die Entwicklung und sind gut informiert. Mitarbeiter werden bei agilen Methoden gefordert. Gerade bei Scrum wählt das Team Entwicklungstechniken und Arbeitspakete gemeinsam aus.

Komplexe Sachverhalte

Vorgelagerte Schritte zur Abstimmung von komplexen Sachverhalten erfordern häufig hohe Konzentration. Funktionale Gesichtspunkte zu durchdenken und abzustimmen, User Experience Tests oder Markttests können lange dauern.
In diesen Fällen ist es oft empfehlenswert, die fachliche und die technische Entwicklung zu entkoppeln und ausgearbeitete Konzeptionen über Testbedingungen abzusichern.

Pflege der Systeme

Je weniger Dokumentation vorhanden ist, desto schwieriger ist die Pflege bestehender Systeme. Bei der Pflege von Systemen sind ursprünglichen Experten selten dann verfügbar, wenn man sie braucht. Dann wird vor allem fachliche Dokumentation benötigt.

Kreativität und disruptive Innovation

Oft wird erwähnt, dass Scrum gerade für Situationen geeignet ist, in denen Kreativität gewünscht ist. Dabei bezieht man sich auf Ikujiro Nonaka und Hirotaka Takeuchi, die Ihren Artikel “The New New Product Development Game” 1986 im Harvard Business Review eben solche Situationen untersucht haben. Sie haben zwar ein sinnvolles Vorgehen mit dem Rugby-Spiel verglichen woraus sich der Name Scrum ableitet. Aber ansonsten bestehen wenige Parallelen. Die auffälligste ist, dass Nonaka und Takeuchi interdisziplinäre Teams fordern. Dies ist bei Scrum nur eingeschränkt der Fall.
Kreativität und disruptive Innovation bedingen, dass sich ein Team Zeit dafür nimmt, Fehlschläge einkalkuliert und unter Hochdruck arbeitet.

Die Lösung liegt in der dritten Ordnung: mit der Hilfe von Computern können wir alle sinnvollen Zuordnungen von Löffeln auswerten und mit mehreren Attributen arbeiten: den Tags.

Allen Dingen werden Informationen an die Hand gegeben, die beschreiben, was sie sind oder darstellen. Weinberger beschreibt sehr langatmig, dass dies eine enorme Komplexität mit sich bringt. Nicht nur die Fülle möglicher Tags (erläutert am Beispiel Capri: italienische Insel oder Ford Sportwagen – gibt es nicht auch ein Getränk diesen Namens?) sondern auch die Auswertung derselben stellen Probleme dar. Die Lösung scheint bis heute darin zu liegen, menschliche Intelligenz zur Sortierung zu nutzen, und bei der Auswertung zu berücksichtigen.

Bis zu 72% aller Tags für eine Information sind gleich, erwähnt Joshua Schlachter, der Gründer der Lesezeichen-Plattform „Delicious”, die auf Tags aufbaut. Der Rest ist durcheinander. Also wählt man die Insel, wenn von Sonne, Meer und Italien die Rede ist, bei Autos denkt man an den Sportwagen. Tags sind komplex und bis dato gibt es keinen Automatismus, diese zu verwalten und auszuwerten. Nur soziale Netzwerke können dies heute nach Weinberger.

Damit schließt er den Kreis zu seinem früheren Betätigungsfeld. Im Cluetrain Manifest begründet sich sein “Internet”-Ruhm, denn bereits 1999 formulierte er mit den Kollegen Chris Locke und Doc Searls 95 Thesen zur künftigen Beziehungen zwischen Unternehmen und Konsumenten. Unterstützt durch Rick Levine gelang Ihnen ein internationaler Beststeller der Wirtschaftsliteratur.

Im Folgenden sind die 95 Thesen des Manifests zusammengefasst, um in Kürze einen Überblick zu ermöglichen:

• Markets are conversations among human people (1 – 5)
• The Internet is enabling conversations among human beings that were simply not possible before (6 – 9)
• As a result, markets are getting smarter, more informed, more organized. Participation in a networked market changes people fundamentally (10 – 13)
• Corporations do not speak in the same voice as these new networked conversations. To their intended online audiences, companies sound hollow, flat, literally inhuman. (14 – 27)
• Corporations do not want the market to see what’s really going on inside the company. (28 – 32) – they take security measures to prevent the workforce to communicate with the market (41 – 48)
• Today, Corporations must be part of a community, act “human” (33 – 40) and they must organize in order to link internal to external communication (the market) (49 – 56)
• Smart companies will get out of the way and help the inevitable to happen sooner (57 – 60)
• We are the market and we want access to your best thinking, your genuine knowledge. We will not settle for the 4-color brochure (61 – 71)
• We like this new marketplace much better. In fact, we are creating it and we could help you (72 – 77, 86 – 88)
• You want us to pay? We want you to pay attention (78 – 85, 89)
• To traditional corporations, networked conversations may appear confused, may sound confusing. But we are organizing faster than they are. We have better tools, more new ideas, no rules to slow us down (90 – 91, 93 – 94)
• Wake Up (92, 95)

Der immer besser kommunizierende und deshalb informierte Konsument bringt klassische Unternehmen in Bedrängnis. Diese müssen reagieren, sich öffnen und unter Mithilfe der Konsumenten ehrlich werden. Vieles davon ist bereits heute Realität, und manches wird noch folgen.

Auch wenn die Thesen etwas schwer zu lesen sind, die Webseite beeindruckt: obwohl seit Jahren nicht mehr bearbeitet hat sie immer noch Page Rank sieben Unzählige Unterstützer haben sich verewigt.

Ob nun tatsächlich nur soziale Kompetenz und soziale Netzwerke die Fähigkeit haben, Tags sinnvoll anzulegen und zu sortieren, wird sich zeigen. Wir wissen heute, dass dies funktioniert (siehe Wikipedia). Möglich ist es aber sicherlich auch, durch Semantik oder intelligente Mechanismen gute Ergebnisse mit Tags zu erzielen. Die Unternehmen würde es freuen, und die Nutzer wahrscheinlich auch, denn dann müssten Sie nicht immer Tags vergeben.

P.S.: David Weinbergers „Everything is Miscellaneous” erschien soeben auf Deutsch unter dem Titel “Die Macht der neuen digitalen Unordnung”

• Geschäfts- und Produktentwicklung (Business and Product Development): Wir greifen gemeinsam mit Ihnen Erfolg versprechende Ideen auf um Produkte oder Nischen zu entwickeln. Oder wir suchen Ansatzpunkte für Sie und generieren Ideen. Im Mittelpunkt stehen für uns der Nutzen Ihrer Kunden und Ihre mittel- und langfristigen Umsatz- und Gewinnerwartungen.
• Design und Implementierung von Geschäftsprozessen (Process Management): Effiziente und zielführende Abläufe sind nach unserer Erfahrung entscheidend für den langfristigen Geschäftserfolg. Deshalb legen wir Wert darauf, dass nicht nur vordergründig, sondern ganzheitlich gearbeitet wird. Wir orientieren uns an Ihren Geschäftserfordernissen und nicht an technischen Möglichkeiten. Falls erforderlich bringen wir auch unsere Erfahrung im Outsourcing mit ein.

Wir haben einen Schwerpunkt auf die Branchen Internet und ITK (Informations- und Telekommunikationstechnologie) gelegt, sowie oft in den Bereichen Marketing, Vertrieb und Customer Management gearbeitet. Zu diesen Themen werden Sie in nächster Zeit die meisten Artikel oder White Papers finden.

Siehe auch OpenPR.