Charitable donations for small amounts can become substantial if the barrier to donation is reduced by making it easy to do, increasing the number of people who donate.

soll Uglow unlängst sinngemäß, laut gedacht haben und man ist verleitet zuzustimmen: Ein möglichst einfaches Sammelsystem bei gleichzeitig möglichst vielen Mikrospendern könnte den Erfolg bringen. Was dabei „einfach“ in technischer Hinsicht bedeutet und welche „Barrieren“ oder auch (psychologische) Hemmschwellen bei den potentiellen Spendern abgebaut werden sollen, bleibt dann bis auf weiteres der Phantasie überlassen. Zu konkret wäre schon keine Vision mehr.

Dabei existieren Vorstellungen, dass die „Web-Riesen“, gemeint sind wohl Google, Youtube, Amazon und Co., sich nicht erst seit gestern mit den Möglichkeiten von „Micro“ auseinandersetzen:

„Die Web-Riesen werden vermutlich Pläne für Micropayment haben“

meint z.B. Linus Olsson, der sich, als Mitbegründer des Micropayment-Dienst Flattr, nicht nur im Spannungsfeld zwischen Micropayment und Microdonations bewegt sondern sich auch noch mit der Entwicklung konfrontiert sieht, wonach die „Großen“ oder „Riesengroßen“ im Web nicht unbedingt auf externe Anbieter gewartet haben sondern sich so ihre ganz eigenen Gedanken machen:

„Es ist eine knifflige Sache, die Pläne der Web-Riesen zu kommentieren. Die werden vermutlich Pläne für Micropayment haben, aber die haben auch einen Haufen anderer Dinge zu tun.“

Und so scheint es, als ob es zukünftig nicht die „Universallösung“ in Sachen Mikrospenden geben wird sondern verschiedene Ansätze parallel existieren werden. Letztlich werden die Nutzer entscheiden, welcher Dienstleister nun die „Hemmschwellen“ am erfolgreichsten reduziert hat, welche Systeme am einfachsten gestaltet wurden.

Interessant wird es auch sein zu beobachten, welche Pläne, neben denen der „Web-Riesen“, bei (regionalen) Banken zum Thema Mikrospenden konkretisiert werden, wenn es diese Pläne überhaupt gibt. Das sich, im Gegensatz zu den o.g. Entwicklern/Kreativen, die Bankvertreter der Volks- und Raiffeisenbanken und der Sparkassen aus dem Bereich Banken-IT/Innovationen mit Aussagen zurückhalten verwundert zunächst wenig, da die Chance, die oftmals auch das Scheitern miteinbezieht, bankseits keine große Rolle spielt oder spielen darf. Ganz im Gegensatz zu den Kreativen um Google wie Tom Uglow, der gerade im „Trial and Error“-Prinzip ein mögliches Erfolgsrezept erkennt:

„Rather, making mistakes is a part of the process – often you don't know what the answer is, so you have to explore. And often it goes wrong.“

Kurzum:

„Making (beautiful) mistakes is a part of the process“

Nun ist es so, dass Banken-IT wohl nur von den wenigsten Menschen im Zusammenhang mit „Fehlern“ gedacht wird, auch wenn es sich um „wunderbare“ Fehler handeln könnte, aus denen, unter Umständen, am Ende des Prozesses etwas großartiges Entstehen kann. Vielmehr bilden Banken-IT und das Thema „Sicherheit“ und „Stabilität“, aus meiner Sicht, eine Symbiose. Gut ist, was sicher ist.

Ich möchte den zentralen Themen „Sicherheit“ und „Stabilität“ nichts in ihrer Wichtigkeit für Banken-IT absprechen, aber sie sind für mich die Basis, das Fundament, auf dem aufgebaut werden sollte, auf dem sich Innovationen ausbreiten können. In dieser Frage sind Bank-Rechenzentralen als IT-Dienstleister von Banken bzw. deren Innovations-Abteilungen Ansprechpartner, wobei sich der Prozess der Produktentwicklung eben weniger am „Trial and Error“ Prinzip ausrichtet:

--------------------------------------------------

„Was wir als Rechenzentrale anbieten können, ist eigentlich: Zuhören.

Denn der erste Schritt in der Produktentstehung ist letztendlich ihre Anforderungen, d.h. wenn wir als Dienstleister im IT-Bereich ihnen ein Angebot machen sind wir immer sehr sehr vorsichtig damit das Geld anderer Leute auszugeben.

Das heißt: Bevor wir komplett ein Produkt neu entwickeln und integrieren möchten wir sicher sein, dass die Kunden das auch wünschen.

Bedarfe wecken, dafür machen wir das hier aber ein Produkt fertig zu machen um dann zu gucken ob es funktioniert – das ist nicht unser Prinzip zu arbeiten.

Sondern wir wollen Ihnen Informationen und Impulse geben, auch hier auf dieser Messe, an vielen Orten und vielen Ständen, um uns die Anforderungen zu geben und zu kommunizieren: Hey das ist super, das gefällt uns. Wie können wir das tun das wir das jetzt nutzen können? Und damit meine ich dann auch natürlich die Prozesse, die nicht technologie-gebunden sind, also nicht techniklastig sondern mehr organisatorisch und ich würde sogar sagen: persönlich.

Zum anderen dann natürlich sehen, das ist unser Job als Rechenzentrale, nach dem Impuls, nach ihrer Anforderung ein Pflichtenheft letztlich zu schreiben: OK, was ist als Technologie, als Technologieplattform dafür notwendig und wie können wir ihnen das am preiswertesten zur Verfügung stellen.

Und da gilt natürlich auch das Genossenschaftsprinzip: Je mehr mitmachen, desto preiswerter wird es."

-----------------------------------------------------

Die, aus meiner Sicht, tragenden Unterschiede in der Produktentwicklung von Google und Co. Und den Innovationsabteilungen von Bank-Rechenzentralen habe ich im persönlichen Statement des Sprechers hervorgehoben. Die Vorteile liegen auf der Hand:

- Es passieren weniger Fehler im Laufe der Produktkonzeption und Entwicklung

- Geld kann eingespart werden

- Der gesamte Entwicklungsprozess wird überschaubarer, planbarer, voraussehbarer

u.a.

die Nachteile aber auch:

- Es passieren weniger „wunderbare“ Fehler, die z.T. Innovationen im wahrsten Sinne erst möglich machen

- Langfristig bleiben Chancen, mit diesen Innovationen Geld zu verdienen auf der Strecke, da sie von anderen Anbietern bereits genutzt wurden

- Es liegen i.d.R. lange Zeitspannen bis hin zu mehreren Jahren zwischen Idee und Implementierung in der Banken-IT – sofern es überhaupt dazu kommt, da zunächst ein Großteil der „Kunden“, also ein großer Teil der jeweiligen Bankengruppe ein Thema erst einmal auf die Agenda des angeschlossenen Rechenzentrums bringen muss.

u.a.

Wo sind die ("wunderbaren") Fehler?