Wie kann man Business Process Management (BPM) und Robotic Process Automation (RPA) zusammenbringen? Und wie lässt sich diese Kombination konkret im Zuge der Digitalisierung in Unternehmen umsetzen und nutzen? Gemeinsam mit unseren Freunden von RST Software Masters aus Polen haben wir uns im Webinar „Integrating BPM und RPA – From Strategy to Practice“ mit den Antworten zu diesen Fragen beschäftigt.
Unsere fleißigen Kolleginnen und Kollegen sind viel auf Konferenzen unterwegs. Wir halten interessante Vorträge und Workshops. Wir richten Meetup- und User-Group-Treffen aus. So tragen wir unser Wissen weiter und engagieren uns in der Community.
Im Jahr 2018 sind bzw. waren wir u.a. vertreten auf der OOP in München, auf der JavaLand Konferenz in Bonn (siehe Foto), auf dem Global Scrum Gathering Minneapolis, USA und auf der SEACON in Hamburg.
Unser Themenspektrum ist vielfältig. Wir widmen uns Technologie-Themen wie beispielsweise Microservices, Continuous Integration/Delivery/Security, Web Performance und Cloud Computing.
Enterprise-Architektur-Themen wie zum Beispiel BPM und Prozessautomatisierung decken wir ebenso ab wie den agil-methodischen Bereich. Agile BPMN-Projekte, Anforderungserhebung und Liberating Structures sind hier nur einige unser Schwerpunkte.
Weiterhin gewinnt auch bei uns der Aspekt der Smart Data immer mehr an Bedeutung.
Für mehr Details zu unseren Veranstaltungen besucht einfach unsere Homepage: www.holisticon.de.
Oder stöbert durch die Kategorie Veranstaltung hier im Blog.
Foto: JavaLand Konferenz in Bonn von Jan Weinschenker – Lizenz: Creative Commons BY
Eigentlich hatte man sich von der Einführung einer Prozessengine erhofft, flexibel und gleichzeitig zuverlässig Anpassungen am Geschäftsablauf der Anwendung vornehmen zu können. Leider kommt es immer wieder zu Fehlern im Produktivbetrieb, da bei den Änderungen Abhängigkeiten im Prozess übersehen werden. Auch dass eine komplette Integrationsumgebung aufgesetzt wurde, um den Prozess vorab durch Tester manuell testen zu lassen, hat nur bedingt Besserung gebracht: Wiederholt rutschen Bugs in die Produktion durch. Die Idee, diese Tests automatisiert ablaufen zu lassen, wurde aufgegeben – zu aufwändig waren die Provisionierung der Integrationsumgebung, automatisierte Testdatenbereitstellung in allen beteiligten Systemen sowie die Pflege der Testabläufe im Fall von fachlichen Prozessänderungen. Und mit den gefundenen Fehlern konnte sowieso niemand etwas anfangen – sie waren unspezifisch und es dauerte Stunden, bis die Ursache gefunden und behoben werden konnte.
Waren die vollmundigen Versprechen des Zusammenwachsens von Fachbereich und IT durch die gemeinsame Arbeit mit Prozessmodellen also nur ein schöner Traum? Könnte man meinen. Es geht aber besser. Und wie das geht, wollen wir in diesem Blogbeitrag erklären.
Wer hat das nicht schon mal erlebt? (Gern und besonders schlimm in großen Projekten): Der Fachbereich formuliert Wünsche und weil die IT diese ja niemals verstehen würde, gibt es diverse Proxies, die das Geschwafel des Fachbereichs übersetzen. Dieses ist natürlich viel zu unkonkret und oberflächlich. Es gibt Business Analysten, die Fachkonzepte schreiben, Modellierer und Architekten, die alles genau durchdenken und in Modelle (häufig UML) gießen, so dass die Entwickler nur noch programmieren müssen. Im Gutfall gibt es dann noch Tester, die die Ergebnisse der Entwickler verifizieren und an den Fachbereich zurückmelden. Im Schlechtfall geht die Kommunikation die ganze Kette vom Entwickler über Architekten und Business Analysten zurück zum Fachbereich. Denn natürlich versteht dieser das Entwickler-Kauderwelsch ebensowenig.
Klingt irgendwie unagil und falsch? Ist es auch. Warum es gerade bei BPM-Projekten so nicht laufen muss, erkläre ich im Folgenden.
Sind Eure Arbeitsabläufe auch weitestgehend durch IT-Systeme bestimmt? Das ist gut so! Nein? Ihr würdet viele Dinge eigentlich anders machen wollen? Wie kann das denn sein? Diese Systeme wurden doch extra für Euch entwickelt, um Eure fachlichen Prozesse und Aufgaben bestmöglich zu unterstützen. Wart Ihr denn nicht an der fachlichen, inhaltlichen Ausgestaltung beteiligt, hat die IT-Abteilung Eure Anforderungen nicht verstanden oder sich (ggf. unter dem Deckmantel der technischen Machbarkeit) vielleicht sogar darüber hinweggesetzt?