IT bietet einfach für Menschen mit Behinderung unglaubliche Chancen. Damit habe ich mich noch nie beschäftigt. Ich bin einerseits selbstständiger Berater... Ich bin Unternehmensberater für Mitarbeiter- und Kundenbindung. Barrierefreie IT und ein inklusiver Ansatz im Unternehmen kann dazu führen, dass man wirklich gewinnbringend Menschen mit Behinderungen auch im eigenen Unternehmen beschäftigen kann. Werte & Wandel, der Podcast zum Thema inklusives Management in Unternehmen. Herzlich willkommen bei unserem Podcast Werte & Wandel. Heute geht es um das Thema Beschaffung und Vergabe barrierefreier IT-Dienstleistungen. Diesmal mit dem Schwerpunkt Angebotsbewertung, Kompetenz und Qualitätssicherung. Und meine Gesprächspartnerin diesmal ist Steffi Hammerich vom Norddeutschen Rundfunk. Und magst du kurz, bevor wir einsteigen mit den Fragen, etwas nochmal kurz zu deiner Person sagen? Ja. Hallo Detlef, vielen Dank, dass ich nochmal dabei sein darf. Ich war ja bei einer Folge schon mal zu Gast bei euch. Und ja, ich bin Steffi Hammerich, bin 45 und IT-Projektleiterin beim Norddeutschen Rundfunk. Arbeite dort seit 2019 und betreue dort so den kompletten Ablauf von den Projekten, von der ersten Planung über dann Beschaffungsverfahren in der Umsetzung und Veränderungsprozesse, Schulung, Mitbestimmung und bis es dann irgendwann eingeführt werden kann und in den Betrieb geht. Ja, und in diesem Kontext ist natürlich das Thema Beschaffung von IT auch immer ein wichtiger Knackpunkt oder eine wichtige Weggabelung. Ja, darüber reden wir jetzt halt noch ein bisschen. Ok, vielen Dank, dann können wir einsteigen. Woran erkennt ihr das? In Angeboten, ob ein Dienstleister tatsächlich schon Kompetenz in der Barrierefreiheit mitbringt. Also hilfreich ist es, wenn ein Dienstleister von sich aus für uns nachvollziehbare Nachweise beifügt. Die Bieter lesen ja das Leistungsverzeichnis oder die Leistungsbeschreibung und sehen, dass das als Anforderung mit drin steht. Und natürlich toll, wenn man von den Beratern oder von den Personen, die dann an einem Projekt teilnehmen, dass man dort Zertifikate bekommt. Ich habe jetzt mal in dem Zusammenhang mal gegooglet: wie BIK oder IAAP-Zertifikate. Ich habe allerdings noch keins bekommen, aber es wäre etwas, wobei ich die Bewertung ... jetzt erstmal erhöhen würde. Ich weiß natürlich nicht, ob eine Firma, die so ein Zertifikat liefert, schon automatisch dadurch gute Leistung abliefern würde. Also was die Aussagefähigkeit solcher Zertifikate angeht. Also fällt dir da spontan etwas ein? Kannst du das einordnen? Wenn die so ein IAAP-Zertifikat schon mitbringen, ... haben die sich auf jeden Fall intern schon ... sehr mit dem Thema beschäftigt ... und mussten schon eine entsprechende Prüfung ablegen. Dieses IAAP-Zertifikat bekommt man nur ... aufgrund einer Prüfung. Und dieses BIK-Zertifikat, das ist tatsächlich nur ... ... für, sagen wir mal, eine Agentur. Und die hat eine Webseite gemacht und die hat sich zertifizieren lassen. Das heißt, zu dem Zeitpunkt auf jeden Fall haben die sich sehr mit Barrierefreiheit beschäftigt und haben es tatsächlich geschafft, diese Webseite oder den Auftritt oder die Anwendung, je nachdem was es ist, dann wirklich barrierefrei zu bauen. Das lässt auf jeden Fall schon Rückschlüsse auf Barrierefreiheit oder Kompetenz in gewisser Weise zu. Ist aber immer die Frage, wie alt ist das Zertifikat? Deswegen bin ich eigentlich immer dafür, wenn schon so ein Siegel mit auf einer Webseite ist. Bitte mit Datum, weil manchmal ist das schon fünf Jahre alt und dann kann es durchaus sein, also gerade in der IT ist die Fluktuation groß bei den Leuten, dass die Kompetenz gar nicht mehr mit im Hause sitzt, ne? Das ist ja immer das Risiko. Aber meine Frage zielte auch darauf ab, so ein bisschen: Gibt es Indizien? Kann man das auch zwischen den Zeilen lesen? Ja, also wenn man diese Nachweise jetzt nicht bekommt, so. Ja, ich habe schon von Firmen zum Beispiel firmeneigene Dokumente teilweise bekommen. Also, dass die selber festhalten: "Unsere Software kann in puncto Barrierefreiheit das, das und das." Das habe ich schon bekommen. Und ein Bieter hat auch schon meistens, wenn man in so einem Ausschreibungsverfahren ist, ist ja mal eine Unternehmensdarstellung dabei, und dann hatte ich ja schon mal, dass sie angegeben haben, sie haben einen eigenen Entwickler für Accessibility. Also das ist kein direkter Nachweis oder auch kein Zertifikat dabei, aber das war halt mit aufgeführt. Wenn dann noch Bietergespräche stattfinden, dann kann man bei sowas natürlich noch mal nachhaken, um das besser einordnen zu können. Also ob da jetzt wirklich was dahintersteckt oder ob die das so ein bisschen werbemäßig nur hingeschrieben haben. Es ist genau der Punkt. Wird das Thema Barrierefreiheit erwähnt und mit welcher Wichtigkeit wird das überbracht? Wenn dann geschrieben wird: "Haben uns auch um die Barrierefreiheit gekümmert" und sonst nichts, dann weiß man: Alles klar, das ist einfach nur, damit es da drin steht, mit reingebracht. Wenn aber wirklich geschrieben wird, wie du sagst, die haben einen eigenen Entwickler oder eine Entwicklerin, die wirklich mitmischt in der Entwicklung und die eine tragende Rolle hat, dann kann man auch davon ausgehen, dass sie sich weit, weit mehr mit dem Thema beschäftigt haben. Aber was können IT-Dienstleister konkret tun, um ihre Barrierefreiheits-Kompetenz im Angebot überzeugend darzustellen? Das ist ganz interessant. Das ist auch das, worauf wir gerade schon gekommen sind. Was macht es wirklich überzeugend? Was sind für dich die Kriterien, die dich überzeugen? Genau, klar, ich bin natürlich immer dankbar, wenn Zertifikate kommen, ob es jetzt personenbezogen für einen Entwickler oder einen Designer ist oder auch wenn eine Software schon kommt mit einem BITV 2.0-Test, das ist immer gut. Aber ansonsten finde ich es halt gut, wenn eine Firma dann im Angebot ein oder mehr Referenzprojekte angibt, gerne dann nochmal in einer ähnlichen Branche, in der das Thema mit aufgeführt ist. Das oft wird ja ein Referenzprojekt angegeben und dann kann man vielleicht dann dort, wenn dann da drin steht: "Es wurde Barrierefreiheit mit umgesetzt", aber vielleicht in welchem Umfang, also es wurde dort mit BITV 2.0 umgesetzt, so zum Beispiel, dass sie das hinbekommen haben in dem Punkt. Das fände ich hilfreich, um da noch weiter Sicherheit reinzubekommen, dass der Dienstleister das auch einfach hinbekommt. Ja, es muss einfach wirklich greifbar sein. Das, was ich bei dir raushöre: Sobald es wirklich greifbar ist als Kriterium, sobald du weißt, okay, BITV 2.0 sagt mir was, BITV-Test sagt mir was, und das sind dann so entscheidende Kriterien. Genau. Nach der Vergabe beginnt ja bekanntlich die eigentliche Arbeit. Und wie kann Qualitätssicherung für Barrierefreiheit während der Umsetzung sinnvoll verankert werden? Ja, ich habe das teilweise, das habe ich auch schon bei dem Aspekt ein bisschen mitbenannt. Also ich finde halt gerade in der Designphase und da natürlich hauptsächlich jetzt, wenn man irgendwie Individualsoftware entwickelt, dass man beim Design die relevanten Kriterien schon mitbedenkt und auch fest definiert. Und ja, wenn der Auftrag- nehmer jetzt irgendwie, also der Dienstleister jetzt keine Person hat, die das Thema so vertritt, also dann nehme ich tatsächlich auch die Rolle ein und ermahne sozusagen mal wieder dazu oder erinnere dran und so. Und dann ist es halt so, dass es bei uns ein Regelablauf ist, dass die Schwerbehindertenvertretungen des eigenen Unternehmens auch frühzeitig und regelmäßig eingebunden sind in die Vorhaben, die umgesetzt werden. Wie häufig, wie eng, muss man sich ja natürlich immer so ein bisschen rantasten. Das finde ich ist noch eine wichtige Stellschraube. Beim BITV-Test selbst, wenn man dann da dran ist, machen wir es oft so, dass wir zwischendurch so kleine Zwischentests machen für einzelne Seiten schon mal oder für bestimmte Aspekte. Erst schon mal Tastatur, dann mache ich schon mal einen kleinen Zwischentest oder so, und dann zum Schluss wird dann der große Test absolviert, und dann wird es so ein bisschen zur Routine über die gesamte Projektlaufzeit, und man merkt dann auch schon schneller, wenn etwas nicht okay ist und hat nicht so den Rückstau bis zum Ende des Projekts. Ja, aber das habe ich gerade richtig rausgehört. Du testest auch selbst, dass du das auch selbst ansiehst und mit der Tastatur mal durchtappst sozusagen. Ja, das mache ich auch. Wie geht ihr denn mit Abweichungen um oder mit Mängeln in Bezug auf die Barrierefreiheit? Also wenn sich zum Beispiel jetzt im Zuge der Umsetzung tatsächlich massive Mängel zeigen und ihr die seht, ihr die gerne behoben haben wollt und der Dienstleister sagt irgendwie so: "Wir sehen hier kein Problem." Wie geht ihr damit um? Also erstmal sollte man ja irgendwie versuchen, rauszufinden, warum finden die das jetzt gar nicht so als Problem. Weil es hat ja schon irgendwie eine Bewandtnis, dass es diese Anforderungen gibt und auch gab. Und das sollte man schon versuchen, mit dem Dienstleister zu besprechen. Also das habe ich bisher jetzt auch noch nicht erlebt, dass man auf so gar keinen gemeinsamen Nenner kam. Weil das war eher einfach ein Zeitthema dann auch. Dass man das einfach noch auch noch hinkriegen muss. Und das war dann meistens der Deal so: "Ja, dann machen wir es noch, aber dann brauchen wir noch ein bisschen" oder so. Also das war eher dann so der Punkt, dass sich das auf die Laufzeit des Projekts halt ausgewirkt hat. Ich hatte jetzt noch nicht das Problem, dass es so gar nichts wurde. Also ... Das Problem hattest du noch gar nicht. Dass gar nichts wurde am Ende. Und worauf beziehen sich denn die meisten Hürden, die dann dazu führen, dass wir brauchen noch länger oder sowas? Welche Herausforderungen sind das? Ja, also das ist tatsächlich eher bei so Stellen, wenn das Produkt eigentlich schon Features hat für Barrierefreiheit und man verlässt sich so ein bisschen drauf, und dann macht man doch vielleicht noch irgendeine Anpassung für die Software, weil man es halt als Kunde doch ein bisschen anders haben möchte, und dadurch passt dann wieder irgendwas nicht. Also solche Sachen sind es eigentlich eher, finde ich. Ja, so Folgeerscheinungen, das kenne ich auch. Man schraubt an der einen Stelle und dann ist es an der anderen Stelle nicht mehr so, wie man es haben wollte. Genau. Also ich meine, wir haben auch schon mal aufgedeckt, wo das eigentlich auch in der Standardversion alles funktionieren sollte mit dem Tabben und Vorlesen und so weiter. Und plötzlich ging es doch ganz woanders hin beim nächsten Drücken. Also da hat sich dann der Hersteller auch bei uns bedankt, so: "Hä, wie kann das denn sein?" So kann er es dann auch sehen. Also das nehme ich auch wahr, dass die dann auch froh sind, wenn ein Kunde... genau hinguckt. Und das meinte ich auch vorhin. Man ist manchmal so ein bisschen das Versuchskaninchen, auch umgekehrt. Das passiert dann. Solange das transparent ist, finde ich das auch gar kein Problem. Genau. Ja und ansonsten, also wenn es jetzt so gar nicht laufen würde, also ich habe ja schon meine Ansprechpartner bei uns intern, das ist halt dann die Schwerbehindertenvertretung, und da würde ich mir sonst einfach dann auch wünschen, da Verstärkung zu bekommen, weil das ist dann irgendwie doch die relevante Stelle, die da auch mehr Nachdruck verleihen kann. Okay, gibt es denn Best Practices, was sich bei euch irgendwie so besonders bewährt hat? Du hast jetzt schon ein paar Beispiele genannt, das sind eigentlich schon fast die Best Practices. Oder gibt es etwas darüber hinaus, was du als Best Practices siehst, so in euren Projekten? Best Practices, weiß ich nicht. Ich finde, ich bin immer noch viel am Erfahrungen sammeln. Ich finde, man lernt immer wieder was Neues und überlegt sich: Das kann ich beim nächsten Mal besser oder einfacher hinkriegen. Das merke ich schon, weil das ist ja auch so ... Ich habe jetzt nicht alle drei Monate ein Beschaffungsverfahren. Das ist ja auch nicht, dass man das so tagtäglich hat. Nicht in dem Umfang, dass man eine neue Software mit Tests hat. Das sind Projekte ... Sie haben ja schon eine gewisse Laufzeit. Insofern ist da der Zyklus vielleicht ein bisschen länger. Ich finde, scheitern kann man eigentlich nur, wenn man das Thema schon so früh komplett ignoriert. Also wenn man halt wirklich beim Beschaffen ... Ja. es noch so wegschiebt, weil die Personalvertretung oder Schwerbehindertenvertretung, also sie fragen früher oder später immer nach: "Was habt ihr denn da für ein System gekauft?" Und wir wollen wissen, ob die Menschen das so nutzen können, wenn sie eine Beeinträchtigung haben. Wenn man es bei der Beschaffung noch nicht berücksichtigt, dann kann man da eigentlich nur scheitern oder sich große Probleme machen. Das ist so die Kern-Best-Practice eigentlich, ne: sich so früh wie möglich um das Thema zu kümmern, sich wirklich auch Gedanken darum zu machen, was, an welchen Stellen, welche Kriterien die wichtigsten sind und so weiter und so fort, ne. Und für zukünftige IT-Beschaffungen, an welcher Stelle siehst du Weiterentwicklungsbedarf, also was kann noch verbessert werden? Ich habe einfach für mich so eine Art Checkliste an Punkten, die ich berücksichtigen muss. Das habe ich für die verschiedenen Gremien oder Personalvertretungen, die immer wieder im Projekt auftauchen. Ist die Schwerbehindertenvertretung, ob z.B. in Richtung Arbeitsschutz oder so was geht. Dass ich immer weiß: Was sind da die Punkte, an die ich jedes Mal denken muss. Wenn ich etwas rausfinde oder eine Erfahrung mache – "Daran muss ich beim nächsten Mal denken" – dann kommt das in die Liste und wird das nächste Mal mitberücksichtigt oder mit hinterfragt. Und da ist es auch so, dass wir beim NDR halt auch eine zentrale Stelle für Mitbestimmungskoordination haben, und über die wird das auch gut konsolidiert, muss ich sagen. Also, dass man auch eine Stelle hat, über die so ein Austausch stattfinden kann und auch von anderen Projekten lernen kann. Das ist wirklich ein guter Herangehensweise. Weil man ist ja auch nicht nur mit seinen eigenen Erfahrungen da, sondern hat ja auch noch Kolleginnen, die die gleichen Jobs machen, und dann ist es immer gut, sich da auch noch auszutauschen. Das höre ich da ganz toll raus, dass Kommunikation einfach ein ganz, ganz wichtiger Aspekt ist dabei. Du sprichst mit der Schwerbehindertenvertretung, du sprichst mit den internen Koordinatorinnen und Koordinatoren und so weiter. Und gibt es zum Beispiel in Bezug auf die Kommunikation mit den Dienstleistern irgendeinen Aspekt, wo du dir wünschen würdest, sagen wir mal, nicht unbedingt zu formalisieren, aber gibt es da möglicherweise Bedarf aus deiner Sicht, was sich in Zukunft ändern sollte oder was besser laufen sollte? Ja, also das wäre natürlich wünschenswert, wenn das Thema von vornherein von den Dienstleistern schon so mitgedacht oder mitgetragen wird. Also dass man es nicht so einfordern muss und vielleicht nicht so die Befürchtung haben muss: "Wenn ich das jetzt im Leistungsverzeichnis ein bisschen zu scharf formuliere, bewirbt sich nachher keine Firma" oder so. Oder: "Ach, das lohnt nicht, ich bewerbe mich gar nicht, die Ausschreibung gewinnen wir nicht." Dabei sind die Anforderungen ja nicht aus der Luft gegriffen, sondern sie müssen halt mehr umgesetzt werden oder Anwendung finden. Dann ist es halt wichtig, dass auch seitens der Dienstleister dem Thema einfach ein größerer Stellenwert zukommt, finde ich. Und jetzt noch als letzte Frage. Gibt es ein Praxisbeispiel, das besonders gut zeigt, wie Barrierefreiheit bei der Beschaffung gelingen kann oder auch woran sie scheitert? Zum Scheitern: eigentlich ist das so, als ich schon sagte, wenn man es halt ignoriert einfach lange, dann ist es ziemlich sicher, dass man da scheitert, weil halt die Gremien das nachfragen werden, wenn man es entwickelt oder beschafft. Und jetzt bei einem Praxisbeispiel, was wirklich gut gelaufen ist und in dem wir beide auch dann zusammengearbeitet haben später, das war ein Projekt im Social-Media-Bereich bei der Tagesschau, und das ... Da hatten wir die Normen und Kriterien für die Barrierefreiheit im Leistungsverzeichnis komplett drin, auch als A-Kriterien. Und der Bieter, der die Ausschreibung gewonnen hat, hat das Thema auch von Anfang an als selbstverständlich genommen. Also, das gehörte halt zum Design. Also wir haben, es war auch ein etwas längeres Projekt, weißt du noch. Von Anfang bis ganz zum Ende waren das, glaube ich, anderthalb Jahre, ne? Ja, wir haben ja vorher schon ein bisschen rumgepuzzelt, und gerade bei dieser Erstellung der Mockups und so des Systems, bevor überhaupt programmiert wurde, da hat die Firma halt auch schon darauf geachtet, das möglichst an diesen Standards aufzubauen. Also es wurde jetzt nicht gleich schon der wilde Fuchsbau designed, so, ne? Dann ist es halt so: Das war der Bereich mit den Mockups und mit dem Design, und dann war es halt auch im Entwicklungsprozess selber. Haben wir es halt immer wieder hochgeholt und immer wieder gesagt: "Wir müssen jetzt die Seiten nicht alle unterschiedlich machen, sondern lass uns eine ähnliche Struktur nehmen", und dass man das so berücksichtigt. Ja, und als es dann Richtung der Tests auch ging, und du dann auch dazu kamst, dass wir gewisse Testpakete schon mal vorab gemacht haben oder schon mal kleine Tests, die du ja schon mal absolviert hast, oder grobe Tests, und dass man den Korrekturaufwand so ein bisschen entzerren konnte und ... dann der finale Test wirklich gut bestanden werden konnte. Und da war es halt auch noch gut, dass der Entwickler, also der dort bei der Firma war für Accessibility, dass der auch wirklich sehr gutes Know-how hatte, wie ich das so raushören konnte in eurem Gespräch noch. Ja, ich drücke es mal lockerer aus: Der hatte richtig Bock auf das Thema. Dem hat das richtig Spaß gemacht, und der hat richtig gemerkt: "Hey, ich programmiere hier nicht nur, sondern ich mache auch noch etwas Sinnvolles, ich helfe Menschen." Und das kam rüber dabei, und das fand ich besonders schön. Und mir hat einfach insgesamt die Kommunikation unheimlich gut gefallen. Es ist alles sehr transparent, es gab niemanden, der jetzt anderen irgendwie Vorwürfe machte oder so was, sondern es war einfach eine durchgehend konstruktive Atmosphäre, in der das Ganze passiert ist. Das hat mir besonders gut gefallen. Ja, das fand ich halt auch. Das ist natürlich auch etwas, wenn man als Projektmanager in einem Projekt ist, wo man versucht, darauf hinzuwirken. Und da hat es anscheinend gut geklappt. Das war's dann. Ja, also ich bedanke mich ganz herzlich, dass ich hier dabei sein konnte, und höre mir eure Reihe auch an mit dem Podcast und verfolge eure Inhalte im Projekt WERTE.IT. Insofern, wir werden uns bestimmt nochmal wiederhören. Dankeschön. Werte & Wandel, der Podcast, der Inklusion in der Informationstechnologie in den Mittelpunkt stellt. Gemeinsam beleuchten wir, wie Unternehmen durch Inklusion nicht nur soziale Verantwortung übernehmen, sondern auch zukunftssicher und erfolgreich agieren können. Lassen Sie sich inspirieren von spannenden Gesprächen, Experteninterviews und praxisnahen Einblicken. Ein Podcast des Projekts WERTE.IT, gefördert vom Bundesministerium für Arbeit und Soziales, unter der Federführung des Blinden- und Sehbehindertenverein Hamburg e.V., wissenschaftlich begleitet von der Universität Siegen.