Flaskamp Dirk – 2019-02

Alexander Petsch: Mein Name ist Alexander Petsch. Ich bin der Gründer des HRM Instituts, euer Gastgeber. In unserer heutigen HRM Hacks-Folge spreche ich mit Dirk Flaskamp, zum Thema Hacks zur Einführung von HR-Software. Dirk Flaskamp ist senior special executive HCM bei Oracle, und hat schon eine langjährige Leidenschaft für HR und HR-Arbeit. Es ist sein Ziel, die Situation nicht nur für die HR Abteilung etwas besser zu machen. Und wenn man sich Dirks Vita anguckt, dann lesen sich die Stationen seiner bisherigen Karriere wie das "Who is Who" der HR Branche von Lumesse, SumTotal, Cornerstone, CrossKnowledge, jetzt zu Oracle. Am Anfang seiner Karriere war Dirk auch vier Jahre selbstständig, hat eine Agentur aufgebaut, und ich kann mir gut vorstellen, dass ihm heute diese "Macher-"Qualitäten auch zugute kommen und er dafür geschätzt wird. Ansonsten spielt Dirk Bass, was natürlich für uns im Kontext der Monsters Of Rec spannend wird, der Band der HR-Branche, die wir als Institut vor vier-fünf Jahren gegründet haben und fördern. Ich freue mich umso mehr, dass du heute bei uns bist, Dirk! Herzlich willkommen!


00:01:43
Dirk Flaskamp: Ja, lieben Dank für die Einladung. Ich freue mich sehr, dabei sein zu dürfen, macht jetzt schon sehr viel Spaß. Und ja, du hast schon viel zu meiner Person gesagt, und ich denke, das zeichnet mich tatsächlich aus, dass ich jetzt seit mittlerweile über 15 Jahren in der HR-Industrie, in der HR-Branche in verschiedenen Positionen unterwegs bin; Ja, und so langsam versuche, die Erfahrung daraus ein bisschen auch wieder unter die Leute zu bringen und Leute davon profitieren zu lassen. Das mit dem Bass spielen ist natürlich eine besondere Überraschung. Jetzt auch wo du das ansprichst, freut mich das sehr, weil das eine ganz große Leidenschaft von mir ist.

00:02:14
Alexander Petsch: Wir sind auf jeden Fall nächstes Jahr auf der Talent pro wieder live dabei. Ja, vielleicht hast du Lust ein Gastspiel, ein Gastsolo sozusagen, zu spielen. Können wir gerne drüber reden! Ich vernetze dich mit Carsten, unserem Bandleader. Wir haben jedenfalls immer viel Spaß damit!

00:02:33
Dirk Flaskamp: Immer gerne, immer gerne, auf jeden Fall! Ich bin auch selten davon abzubringen, irgendwo das auf die Bühne zu springen! [lacht]

00:02:44
Alexander Petsch: Ja, also, deine Hauptexpertise ist ja HR Software, und das ist auch unser Thema heute, nämlich Hacks - Was sollte man tun oder nicht tun? Möglichst eine Einführung in die Software - was ja in vielen Fällen, glaube ich, gar nicht so eine triviale Nummer ist - möglichst unfallfrei, sag ich mal, durchzubekommen.

00:03:02
Dirk Flaskamp: Ja, ja, unfallfrei ist ein guter Punkt. Das ist auch ungefähr das, was uns tatsächlich dazu gebracht hat, überhaupt über dieses Thema mal nachzudenken und verstärkt mit unseren Kunden zu sprechen, weil es eben oft Themen sind, die im Vorfeld, wenn man sie denn etwas zu wenig bedenkt, ja, die dann dann oft zu unangenehmen Punkten führen; dass man plötzlich merkt, die Projekte kommen ins Stocken und das ganze läuft nicht so, wie ich mir das vorgestellt habe, und meistens lässt sich das doch so auf die gleichen Punkte herunterbrechen bei vielen Kunden, und so sind wir eben zu diesen, ja auch so ein bisschen zu diesen Hacks gekommen. Einmal haben wir zusammengefasst, was muss unbedingt vorher bedacht werden, wenn es um so ein Projekt geht? Weil, wie du sagst, es ist eben nicht trivial, es geht manchmal über eine sehr lange Zeit - entsprechend muss man sich davor ordentlich Gedanken gemacht haben.

00:03:57
Alexander Petsch: Was wäre denn so der Einstieg? Womit sollte man anfangen? Was wäre denn der erste Punkt?

00:04:03
Dirk Flaskamp: Im Grunde ist der Einstieg eigentlich der: Wenn man mit den Kunden spricht, geht es ganz oft darum, dass die Philosophie des geringsten Widerstands manchmal erst mal verfolgt wird und man aber merkt, das führt aber nicht so richtig dazu, dass man ein begeisterndes Projekt zustande bringt. Entsprechend muss man eben in die Details gehen und in diese Prozesse, oder über diese Prozesse sprechen. Zum Beispiel ein Punkt: der, der bei uns immer wieder aufkommt, ist dieses Thema Governance. Wenn wir das Thema Governance im Gespräch haben, dann weiß manchmal das Gegenüber gar nicht so genau, was ist denn darunter jetzt eigentlich zu verstehen? Was ist denn gemeint, wenn er jetzt über Projekt-Governance spricht?

00:04:52
Alexander Petsch: Hätte ich jetzt auch direkt gefragt als nicht ITler.

00:04:55
Dirk Flaskamp: Genau, und bei der Projekt Governance geht es im Grunde darum, dass man das Projekt an sich wie so ein kleines Unternehmen betrachtet und wie ein kleines Unternehmen auch im Projekt, ja, gewisse Zuständigkeiten definieren muss, und man muss im Grunde sagen, okay, wer trifft denn die Entscheidungen im Projekt? Es gibt Entscheidungsgremien, und natürlich muss ich auch dafür vorsorgen, was passiert, wenn das Projekt mal nicht rundläuft. Also wie eskaliere ich gewisse Dinge, von wo nach wo funktioniert so eine Eskalation? Welche Rollen habe ich denn, auf die ich überhaupt zugreifen kann? Und das ist schon mal eine recht komplexe Sache. Und wenn wir in diese Projekten dann starten, gerade im Bereich dieser Governance, erkennen wir, dass es eben nicht reicht, nur so zu definieren: Ich treffe mich alle vier Wochen, und dann sprechen wir über das Projekt - sondern ich muss wirklich sehr klare Regeln aufstellen: Ich treffe mich regelmäßig mit festgelegten Personen mit festgelegten Entscheidungswegen, und auch wenn ich beispielsweise meine Projektgruppe nicht zusammen bekomme, darf ich dann überhaupt Entscheidungen treffen? Also solche Dinge sind relativ wichtig.

00:06:11
Alexander R. Petsch: Spannend! Das wäre jetzt das letzte, was ich zu unserem Podcast Thema als erstes genannt hätte. Aber ich habe mal gelernt, dass Verhandlungen meistens schon in der Definition des Setups entschieden werden, und das erinnert mich da gerade so ein bisschen dran. Ja, damit beginnt, so wie du es beschrieben hast, erst mal die Regeln, Personen, Rollen und Entscheidungshierarchien festzulegen und zu definieren. Und was passiert, wenn es nicht ganz automatisch rund läuft, und wer darf was …

00:06:49
Dirk Flaskamp: Genau, und tatsächlich ist das etwas, was auch oft zu kurz bedacht wird. Gerade Menschen oder Organisationen, die nicht jeden Tag so ein Projekt zu stemmen haben, haben das oft nicht ausreichend auf dem Schirm - und da wird zu Beginn des Projekts im Grunde schon werden Probleme geschaffen, die am Ende zu unheimlich viel Zeitverlust führen können, und deswegen haben wir das als einen der ganz wichtigen Punkte wirklich zu Beginn des Projekts gesetzt, damit man das einmal definiert, um spätere Schwierigkeiten, die in jedem Projekt früher oder später kommen. Jedes Projekt hat mal irgendwann so kleine Hubs, und so habe ich einfach eine Lösungsgrundlage dafür direkt geschaffen.

00:07:26
Alexander Petsch: Okay, und also, du hast das in unserem Vorgespräch "robuste Projekt Governance" genannt, und vielleicht noch mal Hack im Hack, sozusagen: Was wäre da wichtig? Was macht's robust, vielleicht so rum gefragt?

00:07:49
Dirk Flaskamp: Robust macht es, oder Robustheit bekommt es durch die Regeln, und diese Regeln sind etwas, die man natürlich oder auf natürlichem Wege erst mal nicht gerne setzt. Also, ich muss Regeln dafür schaffen. Zum Beispiel, wie oft treffe ich mich (ich wiederhole mich jetzt so ein bisschen). Wer muss dabei sein? Wie muss ich vorab informiert werden? Also gibt es vorher eine Zusammenfassung oder besprechen wir das im Projekt? Das kann durchaus unterschiedlich sein, dann auch die Regeln der Entscheidungsfindung. Also, wenn ich im Gremium entscheide, muss bitte auch der Weg klar sein, wie ich entscheide, brauche ich eine Mehrheitsentscheidung oder, was ich eben schon mal gesagt hatte, in Eskalationsfällen. An wen geht diese Eskalation, was haben diejenige KollegInnen wieder für Entscheidungsmöglichkeiten? Das ist es ja; das muss man dann in dieser Organisation tatsächlich darauf anpassen. Welche Leute hab ich denn im Projekt und wie wollen die sich selbst einbringen? Und ich muss nur dafür sorgen, dass solche gesuchten Entscheidungen nicht irgendwo ins Leere laufen. Das ist ein wichtiger Punkt: Dass sehr, sehr klar ist, wer da was zu entscheiden hat, auch vielleicht bis zu Größenordnungen, Budget, Größenordnung und und und. Also, das sind alles so Punkte, die man dazu heranziehen kann.

00:09:08
Alexander Petsch: Das heißt also, je besser man es im Vorfeld entscheidet, oder beschreibt und entscheidet, desto weniger Probleme hat man nachher auf dem Weg.

00:09:18
Dirk Flaskamp: Absolut richtig. Das ist es wirklich, und deswegen dieser Vergleich sieht das Projekt wie ein kleines Unternehmen auch. Ein Unternehmen hat feste Entscheidungswege, und so muss ich das Projekt auch sehen, um so leichter ist es hinterher zu steuern.

00:09:32
Alexander Petsch: Okay, also, jetzt habe ich die Regeln bestimmt und weiß, wie die Entscheidungsfindung zustande kommt. Wer am Schluss den Daumen hoch oder runter macht bei wichtigen Themen und Fragen, und wer sozusagen nachher auch ausbaden muss - hätte ich jetzt gesagt - das haben wir auch klärt. Wie geht's dann weiter?

00:09:52
Dirk Flaskamp: Also, dann geht es im Grunde weiter. Natürlich muss ich das Ganze mit Leben füllen, und ich muss drüber nachdenken, was will ich denn eigentlich erreichen? Wir sprechen ja darüber, eine neue Lösung einzuführen im HR Bereich, HCM, also human capital management, und natürlich muss ich mir dann auch überlegen, wie sind denn meine Gestaltungsprinzipien? Also, wie möchte ich denn mein Unternehmen und meine Mitarbeiter miteinander arbeiten lassen? Also, wie ist sie? Wie sieht denn zum Beispiel die Arbeitsplatzarchitektur aus, wo ich hin möchte? Wie sieht denn der Kompetenzrahmen aus, den ich benutze? Und je besser ich diese mein Zielbild quasi schon beschreibe, desto besser kann ich in dem Projekt darauf darauf hinarbeiten. Also, es heißt nicht, oder es hilft nicht nur zu sagen, wir wollen ein gutes Mitarbeitererlebnis schaffen, und wir kaufen das System ein, was das am besten liefern kann - denn das ist etwas, was ich als Unternehmen selbst bestimme. Was ist ein gutes Mitarbeitererlebnis? Und wie erreiche ich das, indem ich ein System, was ich einkaufe, dahinbringe, dieses Mitarbeitererlebnis zu liefern? Da muss ich eben diese Definitionen im Vorfeld machen, und das ist ein ganz, ganz spannendes Thema. Also, ich habe gerade auf der vergangenen HR-Messe in Paris mit jemanden gesprochen, der hauptberuflich dafür zuständig ist, für die Mitarbeitererfahrung im Unternehmen zu sorgen. Großer deutscher DAX-Konzern, und das war ein unheimlich spannendes Gespräch, auf welche Dinge er achtet und worauf er guckt. Und da geht es eigentlich unheimlich viel um Umsetzung in bestimmten IT-Systemen; und was passiert für den User? Was läuft gut, was läuft schlecht? Das hat sehr viel damit zu tun, was ich im Vorfeld definiert habe.

00:11:49
Alexander Petsch: Also, ich hätte jetzt mal aus meiner Anforderungsliste direkt gesagt, es muss möglichst intuitiv sein. Ich möchte keine Handbücher mehr lesen oder wenig -muss ich mir selbst erklären - und möglichst wenig redundante Arbeit. Also, ich möchte nicht irgendwie irgendwas zweimal eingeben oder was schon mal eingegeben ist, nochmal eingeben, oder Dinge kontrollieren, die auch die Maschine kontrollieren kann oder so. Also, das wären für mich so user experiences …

00:12:23
Dirk Flaskamp: Absolut richtig. Aber genau, was man aber auch zum Beispiel bedenken muss, ist, es gibt ja immer diese Definition der Jobfamilien, Besoldungsgruppen, Gehaltsbänder und und und. Und dann ist auch ganz oft wichtig, in diesem Zusammenhang, festzulegen: Was sind denn Schlüsselrollen für mich? Welche habe ich im Fokus, welche sind für mich wichtig und welche laufen quasi so als Grundlage? Also, wo liegt mein Fokus? Und der muss bei weitem, und das ist ganz klar, nicht auf jeder Rolle und nicht auf jeder Kompetenz liegen, und das ist eben wichtig, das in diesem Projekt auch mitzunehmen. Wo wird das Projekt sehr wichtig? Welche Rollen sind für mich die wichtigsten Unternehmen, die Schlüsselstellen?

00:13:05
Alexander Petsch: Okay, sozusagen an den Stellen sollte es möglichst reibungslos laufen. Ist das das, was du mit Arbeitsplatzarchitektur meinst?

00:13:15
Dirk Flaskamp: Genau, das geht in diese Richtung. Dieser Arbeitsplatzarchitektur muss insofern definiert werden, dass - weil in diesem Fall wir als Anbieter ja auch wissen müssen, welche Rollen müssen wir gestalten, was müssen wir in System aufsetzen oder eben von woanders importieren. Und je besser wir dieses Bild für uns selber kennen, desto besser können wir das auch im Sinne des Kunden und Kundinnen dann umsetzen.

00:13:38
Alexander Petsch: Okay, das heißt also, wenn jetzt eine Organisation sagt, es gibt einen Funktionsbereich, der für uns extrem wichtig ist und unter dem wir im vieles andere unterordnen. Also nochmal als Beispiel: Recruiting ist für uns top prio, weil Speed und die richtigen Leute rekrutieren, ist King. Dann würdest du auch die Softwarearchitektur dahingehend anpassen. Verstehe ich das richtig, oder bin ich jetzt auf dem falschen Gleis?

00:14:12
Dirk Flaskamp: Ja. Es ist halt wichtig, im Projekt das zu wissen, und es ist wichtig jetzt, wenn du zum Beispiel sagst, ja, Recruiting ist unser Hauptthema, dann ist für uns ganz wichtig, im Recruiting Bereich möglichst genau zu wissen, was ist denn deine Kategorien fürs Recruiting? Wen willst du rekrutieren, welche Kompetenzen und wie und wo bekommst du sie, und diese Punkte bekommen dann eben eine größere Bedeutung als bei einem Unternehmen ist, das das nicht als Fokus gesetzt hat. Genau.

00:14:46
Alexander Petsch: Okay, also heißt, ich muss mir vorher Gedanken machen, nicht nur über die User experience, die ich sozusagen erwarte und ich voraussetze für meine HR Organisation in dem Fall, sondern auch,ja, wie sind meine Prioritäten? Du hast es als Arbeitsplatzarchitektur beschrieben, und ja, wie sehen meine Kompetenzrahmen aus? Das heißt also, wer darf was? Wie sind die Freigabewege?

00:15:15
Dirk Flaskamp: Genau das also das. Wir sehen Freigabewege, wie sehen Prozesse aus, auch vor allem dieses Thema. Wie sollen die in Zukunft aussehen? Das ist ja ein ganz wichtiger Punkt. Also wo möchte ich denn eigentlich hin? Wir haben relativ oft die Situation, dass wir gegen alte Gewohnheiten manchmal kämpfen müssen, also, dass man so ein bisschen diese Vorstellung hat: Wir beschäftigen uns mit dem neuen System. Das neue System möchte bitte oder soll bitte alles besser, schöner und schneller machen, was wir aber bisher schon gemacht haben, und diese Diskussion ist oft die, dass das, was wir bisher gemacht haben, gar nicht immer der beste Weg war und man das vielleicht auch einfach mal ein bisschen erneuern kann, und das ist häufig eine Diskussion, die wir antreten.

00:16:01
Alexander Petsch: Das wäre meine nächste Frage gewesen. Ist das denn so, dass ich das so vorgeben sollte oder müsste? Also wenn ich von uns ausgehe, jetzt als Beispiel, wir haben auch IT-gestützte Prozesse und Software gehabt, wo wir zum Teil auch über Jahre Dinge selbst entwickeln haben lassen für unsere Bedürfnisse, und irgendwann an dem Punkt kamen, dass ich auch die Entwicklung -und ich meine, gerade wenn ich mir Recruiting angucke, dann ist das ja genau so ein Fall,- dass einfach die technologische Entwicklung und die dahinterliegende Prozess-, KI- und und Knowhow-Entwicklung so explodiert ist, dass ich ehrlich gesagt… Jetzt für uns als Beispiel mit unseren Veranstaltungen, war das Thema Ticketing irgendwann das Thema. Wir waren mal super im Ticketing selbst, wir hatten Systeme, die gab es am Markt nicht zu kaufen zu dem Zeitpunkt, es gab Veranstaltungsplätze, die uns gefragt haben, ob wir Ticketing für wichtige Veranstaltungen übernehmen. Weil das so unglaublich gut lief aus deren Perspektive, was wir machten. Und dann kamen wir an dem Punkt, dass dieses ganze Thema so eine Dynamik bekommen hat, dass wir gesagt haben, nee, wir wollen uns das einkaufen, und wir wollen uns damit auch das Know How einkaufen, diesen Prozess noch viel besser zu machen. Wenn ich das jetzt … ja.

00:17:20
Dirk Flaskamp: Aber das wäre für mich so die Rückfrage. Tatsächlich, wie habt ihr es denn dann eingekauft? Seid ihr hingegangen und habt gesagt, das sind die Prozesse, die wir haben, und die möchten wir bitte abgebildet haben. Oder seid ihr hingegangen und habt gesagt, das sind zum Beispiel gewisse Eckpunkte in unserem Prozess, auf die wir nicht verzichten können, aber der Rest liegt bitte bei euch, lieber Anbieter.

00:17:40
Alexander Petsch: Naja, wir haben uns angeguckt, haben gesagt, natürlich gibt es gewisse Pflöcke, die für uns gesetzt waren, wo wir gesagt haben: Okay, das ist ein Mindeststandard, was wir erwarten, was das System können sollte, oder ein Prozess, den wir grundsätzlich als sinnvoll erachten. Und dann haben wir uns eigentlich aufgemacht und haben uns halt sehr viele Systeme angeguckt und uns angeguckt, wie sie verschiedene Dinge gelöst haben und wer einfach aus unserer Sicht weiter gedacht hat und weiter denkt als andere und auch als wir selbst, und haben dann gesagt: Okay, das ist ein Prozess, den haben wir so noch nie gemacht, oder den wollen wir in Zukunft sein lassen, oder den können wir sein lassen, weil das System das halt auch alles macht. Ich sag mal, der Vergleich mit Recruiting ist eigentlich ganz gut, weil es da ja auch ständig neue Themen und Lösungen gibt, um die ich mich kümmern muss. Das gab's und gibt es im Ticketing auch, also als Beispiel, dass dann Corona kam, musste man auf einmal die privaten Adressen der Teilnehmer erfassen. Und solche Geschichten. Also, das hätten wir in unserem selbstgestrickten System, wäre das sehr aufwendig gewesen, das alles mal eben so nebenher auch noch zu machen, und das war halt der Riesenvorteil dann, wenn wir bisschen zugekauft haben. Die konnten das auf Knopfdruck, sage ich mal.

00:19:04
Dirk Flaskamp: Ja, ich hab deshalb gefragt im Hintergedanken, natürlich, weil genau das der Punkt ist, der für uns auch immer sehr, ähm, sehr wichtig ist. Wenn wir… wir sind, natürlich dann am stärksten, wenn wir gewisse best practices mitbringen können, wenn wir die quasi Erlaubnis haben, das, was wir besonders gut umgesetzt haben, auch zu nutzen, und wenn wir nicht gezwungen werden, alten Prozessen zu folgen, weil sie eben schon bestehen. Ja, das macht tatsächlich die Einführung eines neuen Systems viel, viel leichter, sich auf neue Dinge, auf best practices einzulassen und nur dafür zu sorgen, dass unverzichtbare Eckpunkte abgedeckt werden, und das ist im Grunde auch der Hintergrund dieser Geschichte.

00:19:51
Alexander Petsch: Okay, also, jetzt haben wir, ich sag mal, das Fundament gelegt, die Anforderungen, die Gestaltungsprinzipien sozusagen festgelegt. Ähm, ja, wie geht's dann weiter?

00:20:06
Dirk Flaskamp: Jetzt kommen wir zu einem ganz wichtigen Punkt. Das ist einer der zentralen Punkte der Hacks: Das Thema der Daten und der Integration. Hier geht es im Grunde darum, dass es oft so ein Reflex ist, wir müssen so viele Daten wie möglich aus unserem alten System übernehmen und dann in Zukunft auch darauf zugreifen können. Und… Oder wir haben eine Reihe von Berichten. Die wollen wir auf jeden Fall im neuen System haben, und diese Punkte sind natürlich interessant und sind für uns wichtig zu wissen, was wirklich gebraucht wird. Aber es ist auch der richtige Zeitpunkt, um mal darüber nachzudenken: Welche Daten brauche ich denn wirklich? Welche Daten benutze ich wirklich? Welche Berichte benutze ich wirklich? Und dann eben auch danach, eine Datenmigrationsstrategie zu… ja zu erstellen, wo dann eben tatsächlich festgelegt wird, welche Daten muss ich migrieren, wie migriere ich die… auch, wenn es dann später in die Richtung der Integration geht … also Daten, die regelmäßig aus unserem System raus oder in unser System rein transferiert werden. Auch da muss eben ein klarer Plan bestehen oder ein klares Bild bestehen. Welche Daten brauche ich? Wie oft laufen die von A nach B, und wo rufe ich die ab? Und es ist eben nicht die beste Lösung, so viel wie möglich reinzupacken, so viel wie möglich Altes ins neue System mitzunehmen, sondern tatsächlich auch da auf best practices zu gucken und sich wirklich auf das zu beschränken, was essenziell wichtig ist. Es ist oft eine Reduzierung, eine Reduktion auf das wirklich Erforderliche.

00:21:53
Alexander Petsch: Spannend! Hätte ich jetzt auch so nicht erwartet. Ehrlich gesagt, du sagst, ach, da sind wir Spezialist, wir importieren alles, was ihr haben wollt oder so. Aber zu sagen, es ist vielleicht besser, sich die Frage neu zustellen, was brauche ich denn? Und wenn ich dich richtig verstehe, welche Schnittstellen brauche ich in dem Kontext auch? Also, welche Daten müssen von wo wohin fließen, und das natürlich dann möglichst ohne, dass ich sie nochmal anfassen muss.

00:22:22
Dirk Flaskamp: Genau, und das ist deshalb ein wichtiger Punkt, weil es ein Projekt auch einfach sehr teuer machen kann, je mehr Berichte ich bauen muss oder bauen lassen muss, je mehr Daten ich bewege, importiere und so weiter, je mehr Schnittstellen ich habe, umso teurer wird das Projekt in der Implementierung und natürlich auch desto länger dauert das, umso mehr Aufwand muss ich reinstecken, und deswegen ist das ein ganz wichtiger Punkt.

00:22:50
Alexander Petsch: Mhm.

00:22:51
Dirk Flaskamp: Jetzt haben wir gerade auch gesehen, in Paris auf der "Unleash" ist es eben das Thema ein ganz großes gewesen, hat im Grunde alles überlagert. Im Grunde kann man sagen, in den letzten zwölf Monaten ist ja irre viel passiert, und da geht's dann auch viel darum, dass die künstliche Intelligenz tatsächlich auch in der Lage ist, aus vielen Daten gewisse Dinge oder Erkenntnisse herauszuholen, und entsprechend muss ich mir vorher Gedanken machen, welche Daten möchte ich denn eigentlich halten in meinem Datenpool. Was soll drin sein? Und da gibt es vielleicht auch relativ bald ganz neue Ansatzpunkte, wie man eben mit den eigenen Daten umgeht.

00:23:39
Alexander Petsch: Ich hätte jetzt reflexartig gesagt: Daten, mein Schatz! Ja!

00:23:42
Dirk Flaskamp: Das ist absolut so. Daten sind ein Schatz, so ist es, und leider, für diesen Schatz wird das manchmal zu kurz besprochen, tatsächlich.

00:23:55
Alexander R. Petsch: Mhm.

00:23:56
Dirk Flaskamp: Was wir jetzt noch gar nicht erwähnt haben, beispielsweise, sind Sicherheitsanforderungen. Es ist ja auch ganz, ganz interessant, auch mal darüber zu sprechen. Was gibt's denn für Anforderungen? Also Klassiker, DSGVO, der Datenschutz. Aber weitere Themen sind auch, von wo zum Beispiel auf die Daten zugegriffen werden darf und muss, und auch, von wo Servicemitarbeiter auf Daten zugreifen können. Also beschränke ich das auf Europa. Ist mir das egal? Kann das Global passieren? Also, alle diese Dinge spielen natürlich rein in die Strategie für die Daten und die Datenintegration. Wer hat wie Rechte und Möglichkeiten, auf Daten zuzugreifen?

00:24:44
Alexander Petsch: Mhm, das kann natürlich auch direkt ausarten, diese Frage, ja.

00:24:51
Dirk Flaskamp: Kann ausarten, aber ich lasse lieber die Frage ausarten als später das Projekt. Ich setze mich lieber nochmal wirklich lange und ausführlich hin und diskutiere diese Fragen, und wenn man dabei irgendwelche Punkte entdeckt, die noch nicht so ganz zu Ende gelöst sind, dann ist das eine gute Stelle am Anfang des Projektes und nicht mittendrin, wenn man mitten in der Migration steckt und merkt, dass einem wichtige Dinge fehlen.

00:25:18
Alexander Petsch: Okay, oder wenn auf einmal jemand kommt, den wir vorher in der robusten Projektgovernance leider vergessen haben, und der dann sagt, I overrule it!

00:25:29
Dirk Flaskamp: Zum Beispiel, zum Beispiel, das ist ja auch völlig in Ordnung. Ein Projekt lebt, und ein Projekt ist nichts, was in Stein gemeißelt ist, gerade mit den Laufzeiten oder mit den Laufzeiten, in denen wir uns bewegen. Also ein Implementierungsprojekt von dem Thema CO-HR und Recruiting und Learning und so weiter, das dauert ja schnell mal ein halbes Jahr oder ein Jahr oder länger, je nach Größe und Komplexität des Unternehmens, und das darf ruhig leben. Das ist in Ordnung, und es dürfen sich Dinge verändern. Das ist auch in Ordnung. Es muss aber eben im Rahmen dieser Projekt-Governance funktionieren, und es darf nicht zu ständigen Überraschungen führen, die dann das ganz zum Stoppen bringen. Das ist der Schlüssel daran.

00:26:16
Alexander Petsch: Aber ich sag mal so, dieses Pflichtenheft am Anfang … Das ist doch irgendwie nicht mehr so, oder?

00:26:25
Dirk Flaskamp: Also, Pflichten-/ Lastenheften und so weiter gibt es nach wie vor. Es ist so ein bisschen die Frage, wie man sie gestaltet. Ich bin eher …, und das ist tatsächlich so, so habe ich die Erfahrung auch gemacht. Ich bin eher ein Freund eben von diesem Thema, wirklich Eckpunkte zu definieren und dann gemeinsam die Lösung zu erarbeiten. Dieses starre und ganz klassische Pflichtenheft ist meiner Meinung nach nicht mehr so ganz up to date, und nicht mehr das Mittel der Wahl.

00:27:01
Alexander Petsch: Naja, wenn man halt so vorgehen würde oder vorgeht, dass man am Anfang ein Pflichtenheft bis ins kleinste definiert, dann nimmt man sich ja die Chance, vom Know-How der Lösung zu profitieren, weil dann tut man ja nichts anderes als einen eigenen alten Prozess auf die höchste Ebene heben und alles danach bauen, ja?

00:27:25
Dirk Flaskamp: Absolut! Absolut richtig!

00:27:27
Alexander Petsch: Und umgekehrt, wenn ich dich richtig verstehe, darf halt nicht zu "scrum" und "agil" sein, also nicht zu liquide im Sinne davon, dass man dauernd Dinge wieder in Frage stellt und über den Haufen wirft.

00:27:43
Dirk Flaskamp: Genau, man muss mal gucken, braucht natürlich eine gewisse Verlässlichkeit, weil Dinge irgendwann ja auch im System umgesetzt werden, und dann natürlich, wenn ich alles wieder umwerfe und ständig von vorne beginne, macht es das Projekt erstens nicht schneller und zweitens nicht günstiger. Das ist eben auch so ein Punkt. Deshalb diese klare Regelung, dass auch klar sein muss, wie reagiert eine Organisation auf gewisse Dinge, die sich verändern. Es passieren ja Dinge im Laufe des Prozesses, im Laufe des Projektes. Das Unternehmen kommt in eine andere Phase. Es müssen Dinge berücksichtigt werden, und entsprechend muss ich einfach nun dafür gesorgt haben, dass das funktioniert, dass Änderungen eingebaut werden können, dass man flexibel reagieren kann. Aber eben so, dass es klar ist und man nicht in Unklarheiten rennt, die dann zur Projektverzögerung führen. Das ist im Grunde das Wichtigste.

00:28:41
Alexander Petsch: Gut, ja, wie geht's dann weiter?

00:28:44 Dirk Flaskamp: Wie geht es weiter? Ein wichtiger Punkt, den wir oder vor allem unsere KundInnen auch definiert oder identifiziert haben, ist auch das Thema des HR Target operating model, das heißt, auch die HR-Abteilung muss sich hinterfragen: Arbeite ich nach der Einführung eines neuen Tools genauso weiter, wie ich das bisher getan habe? Also, mit der Einführung einer Software, habe ich natürlich im Grunde ein neues Betriebssystem, und ein neues Betriebssystem führt natürlich auch immer dazu, dass ich meine Arbeit in der HR verändern muss oder die sich ganz natürlich schon verändert. Also, zum Beispiel spare ich Zeit an vielen Stellen durch Automatisierung von Reports, von Analysen und und und… was stelle ich mit dieser Zeit an? Was passiert damit, ist für mich, ist das qualitative Zeit, die ich gewinne. Was, was mache ich damit? Also, deswegen ist diese Frage nach dem Betriebsmodell daher eher ganz wichtig und eben auch eine, die… naja, nicht immer wirklich im Detail beantwortet wird, sondern dieses Thema "Renne in Veränderung sehenden Auges rein, ohne ohne darüber nachzudenken, was was für mich dann daraus passiert." Und das ist eben ein Punkt, der der klar sein muss. Also, das ändert sich vielleicht die Organisationsstruktur, es ändern sich Prozesse, es ändern sich Beschäftigungszeiten mit dem Tool, und das muss ich einfach in meinem Operating Model im Grunde berücksichtigen. Habe ich die richtigen Fähigkeiten in meinem Team? Habe ich die richtigen Kompetenzen in meinem Team, um diese Lösung zu zu betreuen? Hab ich die Prozesse, so wie ich sie geplant habe, richtig umsetzen? Also, Stichwort Recruiting. Ändere ich jetzt meine Art zu rekrutieren, geh viel mehr auf social Recruiting ein. Habe ich die richtigen Leute? Dafür können wir das, und solche Dinge kann ich die da hinbringen? Wie bilde ich sie auch dafür aus? Und das ist eben wichtig, nicht nur von der HR eben in die Organisation zu gucken, wie verändern sich HR Rollen, sondern eben auch zu gucken, wie verändern sich Rollen an sich.

00:31:16
Alexander Petsch: Du hast gerade gesagt, wie habe ich die Kompetenzen, die die neue Lösungen, die neuen Prozesse auch zu betreuen? Ich hätte es eher umgekehrt gesagt, habe ich auch die Kompetenzen, die Power, die in der Lösung und in dem neuen Prozess liegt, überhaupt zu entfalten?

00:31:35
Dirk Flaskamp: Absolut die richtige Frage, also verstehe ich das, komme ich? Wie komme ich an die Daten beispielsweise ran, die mir das System liefern kann, und kann ich die interpretieren und kann ich damit umgehen? Und das ist ein ganz wichtiger Punkt. Deshalb ist es eben so wichtig, über dieses operating Model auch einfach nachzudenken. Was macht mich, was macht mich flexibel oder was macht mich unflexibel? Was sind erforderliche Schlüsselinformationen, die ich, die ich einfach haben muss? Hab ich denn überhaupt genug Mitarbeiter? Habe ich genug Ressourcen, um ein Projekt beispielsweise auch in einer gewissen Größenordnung stemmen zu können? Das kommt auch dazu, also dieses Thema. Ich möchte, oder es gibt oft diese Diskussion mit Kunden. Machen wir das in einem großen Big bang, oder gehen wir phasenweise vor; gehen wir pro Land, pro Einheit vor, wie auch immer, und natürlich sieht dieses Thema big bang erst mal sehr attraktiv aus, weil ich schnell fertig bin, und ich bin dann, ich gehe dann nach relativ kurzer Zeit, verglichen zu diesem Phasenmodell. Aber ich muss das eben auch als HR-Abteilung oder IT-Abteilung stemmen können, das leisten können, und das ist eben ein Punkt, über den man sich tatsächlich vorher sehr genau Gedanken machen sollte. Überfordert mich so ein Projekt beispielsweise auch?

00:33:02
Alexander Petsch: Ja, ich hätte gesagt, ich, im Idealfall habe ich da nachher Ressourcen, die, die ich neu einsetzen kann, aber natürlich ist in der Phase dorthin die Belastung sicher höher.

00:33:18
Dirk Flaskamp: Die Belastung kann kann sehr groß sein in so einem Projekt. Wir können das auch, und deswegen auch eben diese Diskussion im Vorfällt. Wir können das auch entsprechend abfangen. Das ist so. Man ist ja als Anbieter durchaus in der Lage, so ein Projekt auch von unserer Seite so zu staffeln, dass man, dass man solche Dinge unterstützen kann. Das müssen wir nur wissen, und dann geht das durchaus. Aber eine gewisse Leistung muss eben auch von der Abteilung selbst erbracht werden können.

00:33:46
Alexander Petsch: Gut, ja, also jetzt habe ich ein neues Wort gelernt. Ja HR Target Operation…

00:33:53
Dirk Flaskamp: Target operating model.

00:33:55
Alexander Petsch: Also, ein Model? Hast du uns sonst noch etwasmitgebracht?

00:34:00
Dirk Flaskamp: Ja, wir kommen natürlich so langsam jetzt in Richtung Business as usual, also diese Umsetzung im Alltagsbetrieb, und deswegen ist ein weiterer Hack tatsächlich dieses Sportmodell für Business as usual. Also, sobald ich mit der Lösung live gehe, muss ich natürlich Support leisten, und ich muss überlegen, wie ich den leisten. Wie stelle ich sicher, dass alle, die das neue System nutzen, die Hilfe bekommen, die sie brauchen? Wie mache ich das? Das ist wirklich vom klassischen Ticketsystem über Beschreibungen. Wie mache ich was? Wo finde ich Hilfe, solche Dinge, dieses klassische Support System für den Betrieb der Lösung, das ist ein wichtiger Punkt, sich tatsächlich Gedanken drüber zu machen.

00:34:52
Alexander Petsch: Wie sieht also heute der state of die art aus?

00:34:59
Dirk Flaskamp: Das ist unterschiedlich; es geht vor allem darum zu identifizieren, wie man am besten mit den Menschen kommuniziert. Wie erhalte ich möglichst leicht Anfragen, wenn es um Bedienung, bestimmte Teile der Lösung geht? Aber auch bevor diese Anfrage überhaupt kommt, habe ich denn vielleicht für die User schon eine Möglichkeit, diese Anfrage abzufangen, indem ich gewisse Infos anbieten kann, die Nutzer dann zur Verfügung haben, um ihre Themen zu lösen? Also vielleicht lass ich es gar nicht erst zu einer Anfrage kommen, indem ich vorher gut abfange, was der Nutzer können muss.

00:35:43
Alexander Petsch: Eigentlich muss ich das auch in meine eigene Business-Infrastruktur integrieren. Jetzt, wo du das gesagt hast, hab ich gesagt, na ja, was würden wir machen? Also, natürlich würden wir da natürlich in Anführungszeichen, wenn wir als erstes mal ein Slack Channel dazu machen. Da hätten wir schon mal viele schnelle Dinge abgefrühstückt. Wenn jemand ein kleines Problem hat, würde das da durchlaufen. Das würde aber jetzt nicht dazu führen, dass man damit die Chance hätte, viel mehr tiefere Schulungen zu bekommen, oder wenn er sagt, okay, ich hab jetzt gerade gar keine Ahnung von dem Teil, da brauche ich jetzt mal so Erklärvideos oder was auch immer. Ja!

00:36:27
Dirk Flaskamp: Ja, und das lässt natürlich auch eine gewisse Skalierbarkeit am Ende vermissen. Das heißt, klar, kann der Slack Channel eine kurze, schnelle Hilfe sein, aber je größer das ganze wird, desto weniger ist dann so ein unkoordinierter Slack Channel hilfreich, und das ist genau der Punkt. Darum geht es dann: Welche Dinge kann ich locker und über so ein un- oder wenig formelles Tool lösen, oder was muss ich zum Beispiel über bewusste Tickets zu lösen? Wo brauche ich auch Lösungen oder Regelungen, wie schnell muss ich auf gewisse Anfragen reagieren? Ist das jetzt systemkritisch?

00:37:03
Alexander Petsch: Welcher Supportlevel ist für dieses Problem relevant?

00:37:07
Dirk Flaskamp: Genau welcher Supportlevel ist relevant? Und all das, diese Szenarien tatsächlich sauber zu definieren, das ist gar nicht mehr so trivial. Und jetzt denkt man mal an Größenordnungen, ich weiß nicht, DHL, wie auch immer, da geht es gleich um, da geht es nicht mehr um Minuten, die sich das relativ schnell zu Personen, Tagen und mehr und mehr und mehr. Und das ist etwas, wo ich unheimlich viel Spielraum habe, Dinge positiv zu beeinflussen, wenn ich früh genug drüber nachdenke.

00:37:43
Alexander Petsch: Mhm, ja, und es gibt natürlich auch… Also, im Rahmen unserer in HRTech in Köln haben wir das auch natürlich tief diskutiert … Es gibt natürlich auch HR Prozesse, die eigentlich auch niemand mehr anfassen will. Worst szenario, ich sag jetzt mal, das Gehalt wird nicht rechtzeitig überwiesen, weil ich System geändert habe. Ja!

00:38:14
Dirk Flaskamp: Da ist natürlich der Killer, das steht über allem, das darf nie passieren!

00:38:18
Alexander Petsch: Genau daran musste ich gerade denken, als du gesagt hast: Support Level. Okay, es gibt auch Support Level, die sind… ja, dann wird es extrem schnell sehr weit eskaliert wahrscheinlich.

00:38:31
Dirk Flaskamp: Und es geht dann eben auch so weit, dass dass man darüber nachdenken kann. Schaffe ich das inhouse? Möchte ich das überhaupt inhouse? Kann ich das auslagern? Also all diese Themen, die stecken da dann auch drin.

00:38:44
Alexander Petsch: Ja, oder gibt es eine hybride Variante, die genau das ermöglicht? … Jetzt haben wir selbst in-support bedacht. Sonst noch was?

00:39:05
Dirk Flaskamp: Ich würde sagen, last but not least, und wirklich eins der wichtigsten Punkte ist im Grunde: Schafft Argumente für den Wandel, und zwar Argumente, die jeder versteht. Das ist ein Thema bei der Technologieadaption, wirklich Akzeptanz für das neue Tool zu schaffen, und zu erklären, warum. Das ist oft die Herausforderung. Bei uns ist oft die Herausforderung, dass natürlich Projektteam und natürlich Geschäftsführung da seit Ewigkeiten darüber sprechen und genau wissen, was sie erreichen wollen, und eine Lösung ausschreiben, einkaufen und und und; und was manchmal einfach vergessen wird: Übersetzt am Ende die Botschaften für die Mitarbeiter, übersetzt die Projektsprache in HR Sprache für die Mitarbeiter, und zwar im Sinne von, was sind die Vorteile, die jeder hat mit der neuen Lösung? Was verbessere ich auch für die Mitarbeiter? Also quasi wie so einen kleinen Business case für die verschiedenen Zielgruppen zu bauen in der Sprache der jeweiligen Zielgruppe. Ich meine jetzt gar nicht Muttersprache, sondern wirklich diese Alltagssprache der Menschen im Unternehmen; also eine Begründung schaffen, dieses klassische "what's in it for me?", also was ist für mich drin, wenn dieses neue Tool kommt? Warum ist das für mich gut? Und da muss man tatsächlich sagen, sind auch schon Projekte dran gescheitert an der Akzeptanz für dieses Tool, und ich weiß nicht, ist immer eine schöne, schöne Anekdote aus meiner Zeit in der in der Selbstständigkeit. Damals, da haben wir viele Projekte ja auch begleitet und auch mit mit Training und mit Informationen begleitet, und teilweise war es, oder ich hatte ein ganz schlimmes Projekt, wo dieser Punkt wirklich schief gegangen ist. Dann da waren sämtliche Mitarbeiter absolute Opposition gegen ein neues Tool, was wir den Leuten näher bringen sollten, und wir waren extern und haben unsere unsere Info und Trainingsveranstaltungen gehabt, und teilweise sind ganze Abteilungen nicht erschienen oder nach der Pause nicht mehr wiedergekommen, und es war eine komplette Kontraposition. Also, die waren wirklich, und es ist jemand da nachher dann auch zu mir gekommen und sagt, es tut mir leid, Herr Flasskamp, das ist überhaupt nicht ihr Problem. Sie leiden da jetzt drunter, aber dieses Tool findet bei uns keinen Support, Punkt, und wir kommen nicht wieder. Ich lasse meine Leute hier nicht noch mal zwei, drei Stunden verschwenden, sondern die sind jetzt wieder auf der Straße. Das waren Sales-Mitarbeiter, und die machen jetzt ihren Job und bringen mir Geld. So, und das ist so ein Klassiker, das werde ich nie vergessen, und das ist auch immer so. Ein Punkt, wo wir in unseren Projekten sehr viel drüber sprechen: Schafft eine Botschaft, vielleicht schafft dir eine Marke, vielleicht gibt's den Produkt, vielleicht einen Namen und schafft ein Slogan oder so was. Das hilft ungemein, die Akzeptanz im ganzen Unternehmen zu puschen.

00:42:05
Alexander Petsch: Mein Lieblingssatz zu dem Thema ist eigentlich: "Wenn du Argumente für den Wandel suchst - Betroffene zu Beteiligten machen!" Das muss eigentlich das Ziel sein, und das kann ich auf verschiedenen Wegen schaffen - du hast zum Beispiel gesagt Marke. Anderer Punkt ist vielleicht auch frühzeitig in den Prozess mit einbinden, also im Prinzip schon bei der Bedarfsanalyse schon Andockmöglichkeiten schaffen, dem ganzen viel, viel mehr Stallgeruch geben, indem ich möglichst frühzeitig die, die es nachher kippen könnten, mit ins Boot hole.

00:42:48
Dirk Flaskamp: Absolut richtig sehe ich genauso, und es ist tatsächlich wirklich auch gelungen nachzuweisen, dass, je mehr ich das tue, je mehr ich diese Kommunikation hochfahre, desto erfolgreicher laufen tatsächlich diese Transformationsprojekte. Ja, also, das ist wirklich eine Erkenntnis, die ist nicht vom Tisch zu wischen.

00:43:11
Alexander Petsch: Ja, ich denke, es hat sich schon viel verändert, technologisch, in den letzten, gerade auch natürlich in den letzten drei, vier Jahren. Es hat einen unglaublichen Boost gegeben, und du hast vorhin gesagt, jetzt die letzten, eigentlich zehn, zwölf Monate mit KI auch nochmal total Veränderungen durch die Decke gegangen. Ich glaube, wir werden jetzt die nächsten Jahre noch viele, auch digitale Innovationen im HR-Bereich sehen. Ich glaube, man kann nur unseren Podcasthörerinnen und Hörern den Tipp geben: Setze dich damit auseinander, daran führt kein Weg vorbei.

00:43:47
Dirk Flaskamp: Nein, das glaube ich auch. Es wird kein Weg daran vorbeiführen. Das haben wir jetzt auch auf der Messe gesehen, da wiederhole ich mich gerne, und auch wir selbst können im Moment… Es geht so schnell, Technik oder das Thema, es geht so schnell nach vorne, dass wir selber noch nicht überschauen können, was genau denn da jetzt in zwei, drei Jahren passiert sein wird. Aktuell haben wir unheimlich viel Spaß daran, das umzusetzen und damit zu arbeiten. Sowas wie Generative KI, also, ich lasse mir bei der Autorenschaft von gewissen Dingen helfen und so weiter, macht irre viel Spaß. Aber das wird ein Thema sein, das uns alle noch überraschen wird … Da bin ich mir sehr sicher.

00:44:31
Alexander Petsch: Ja, herzlichen Dank, denke also, ich habe viel gelernt heute in unserem Podcast. Danke, dass du da warst!

00:44:39
Dirk Flaskamp: Vielen Dank für die Einladung nochmal.

00:44:41
Alexander Petsch: Ja, und wenn ihr die einzelnen Hacks nachlesen wollt: Einfach auf HRM.de gehen, und dort findet ihr die Checkliste zum heutigen Podcast. Ansonsten: Glück auf und bleibt gesund und denkt dran, der Mensch ist der wichtigste Erfolgsfaktor für euer Unternehmen!