Einen Punkt zu “Proof of Concepts” möchte ich ergänzen: Manche Kunden sind – wahrscheinlich auf Grund der schlechten Erfahrungen: Siehe im Originalartikel – dazu übergegangen, uns (bzw. unseren Presales/System Engineers) tatsächlich und buchstäblich über die “Schulter” zu schauen, was wir wann wie machen in webMethods während eines PoCs. Da ist nicht nur die Anzahl der Berater klar, sondern auch, wie rasch man wirklich am Tool (= BPMS) arbeiten kann.

Ein Kunde hat uns sogar 3 Monate nach dem (erfolgreichen) PoC “eingeladen”, noch “rasch” etwas zu ändern im Rahmen eines sogenannten Flexibilität Tests: Dabei mussten wir *vorher* schätzen, wie lange das dauert – und der Kunde hat dann gestoppt, wie lange wir wirklich gebraucht haben.

Eine Anmerkung zu dicken RFPs: Unser Rekord in RFP Fragen beträgt mittlerweile 600 Fragen (auf Englisch – auch im deutschen Sprachraum) innerhalb 10 Arbeitstagen zu beantworten: Unsere Antwort war dann auch mehr als 200 Seiten lang.

Für uns sind derartige extrem und in der Sache selbst nicht unbedingt Nutzen stiftende Randbedingungen oft ein Zeichen von Unbestimmtheit oder Unsicherheit auf Seiten des Kunden, der wahrscheinlich (noch) nicht genau weiß, was er wann benötigt. Aber um das so differenziert mit ihm zu diskutieren, mussten wir erst die Fragen beantworten…

Die Fiktion, dass “die Fachabteilung direkt ausführbare Prozesse malen könnte” wird u.a. von Smith & Fingar (“BPM – The Third Wave”) propagiert (ebenso wie der Pi-Kalkül und ist auch aus unserer (meiner ehrlichen) Sicht auf absehbare Zeit ins Reich von “pure Magic” (oder “Dream”) einzuordnen. Nichteinmal unser webMethods BPMS kann das im nächsten Release.