| Zehn Gebote für erfolgreiche BPM-Vorhaben | |
| 4. Klare Zuständigkeiten und Abläufe definieren | |
| 7. Open Source gegen proprietäre Fallen |
In allen IT-Lösungen, auch in herstellerspezifischen quelloffenen Systemen, lauern Fallen, deren Ergebnis eine Abhängigkeit von einem Anbieter wäre. Das kann den evolutionären Wandel der Infrastruktur sehr aufwändig machen kann. Vergleichen lässt sich das Problem mit den Unterschieden zwischen Unix-Derivaten, die trotz vieler Standards einen Wechsel zwischen Herstellern erschweren. Open-Source-basierende Lösungen haben den Vorteil, dass sich solche Punkte von erfahrenen BPM-Praktikern identifizieren lassen.
Die Basisdienste müssen klar definiert sein. Die Anwendungs-Programmier-Schnittstellen (APIs) sind sauber zu dokumentieren. Unterschiedliche Datenmodellierungen, etwa in Folge divergierender Beschreibungen einer Entität - beispielsweise eines Kunden - in verschiedenen Fachabteilungen, gilt es zu verhindern, weil sie aufwändige Transformationen notwendig machen. Starke Bindungen, in denen ein Dienst einen anderen voraussetzt, sind nicht immer auszuschließen, sollten aber auf ein Minimum reduziert werden. Technologieübergänge werden durch die Integration von Legacy-Systemen und Ähnlichem zwangsläufig auftreten. Bei SOA-inhärenter Technik, etwa in Form von Schema-Transformationen, sind sie zu vermeiden.
Bei der Einführung eines so stark mit den Fachabteilungen verzahnten Systems ist von Anfang an mit vielen Korrekturen und Änderungen zu rechnen. Die Qualitätssicherung der Prozessdefinitionen ist in der Regel langwieriger als bei üblichen Softwarekomponenten und muss realistisch geplant werden. Änderungen lassen sich durch eine gut geplante Pilotphase reduzieren. Um Änderungen effizient zu verarbeiten, ist es notwendig, vorab spezielle Tools zum Fehler- und Change-Management zu implementieren.
Prozess- und Software-Updates sind bei Prozess-Management-Systemen aufwändiger als bei anderen Unternehmensanwendungen. Denn bestehende Prozessinstanzen lassen sich oft nur mit größerem Aufwand auf eine neue Prozessversion migrieren. Unabhängig von der verwendeten technischen Infrastruktur muss das Design dem System auf jeder Ebene eine Zukunft von zehn Jahren und mehr eröffnen. Dazu sollte man mögliche Perspektiven für die Entwicklung des Anwenderunternehmens, seines gesellschaftlichen Umfelds (zum Beispiel in der Gesetzgebung) sowie des technischen Fortschritts in der Informations- und Kommunikationstechnik in Betracht ziehen.
