KLARTEXT. Der Podcast FÜR IT OHNE BARRIEREN. Interessante Informationen und wertvolles Wissen zur digitalen Barrierefreiheit in der Arbeitswelt. Ein Podcast zum Forschungsprojekt iDESkmu, gefördert vom Bundesministerium für Arbeit und Soziales unter der Federführung des Blinden- und Sehbehinderten- vereins Hamburg. Hallo und herzlich willkommen zur Episode #12. Mein Name ist Nadia David. Im ersten Interview spreche ich mit Detlef Girke über die iDESkmu Testing Suite. Im darauf folgenden Interview mit Stefan Schnürer vom Ministerium für Energie, Infrastruktur und Digitalisierung in Mecklenburg-Vorpommern geht es um das Thema Angebotsbewertung und Auswahl im Rahmen von Ausschreibungsverfahren. In den Shownotes finden Sie die Timecodes zu den Beiträgen und Hintergrundinformationen zu unseren Gesprächspartnern und Gästen. Zum Einstieg in die Episode hören Sie wieder einen kurzen Auszug aus einem bekannten Märchen. Das tapfere Schneiderlein. An einem frischen Sommermorgen saß ein Schneider an seinem Tisch, war guter Dinge und nähte aus Leibeskräften. Nach kurzer Zeit umschwirrten Fliegen seinen Kopf. Er schlug nach ihnen und erwischte sieben auf einen Streich! “Das soll die ganze Stadt erfahren.“ sprach er bewundernd. Er fertigte sich einen Gürtel und stickte mit großen Buchstaben darauf: „Sieben auf einen Streich!“Der Schneider band sich den Gürtel um, und wollte in die Welt hinaus. Eh er abzog, suchte er sich Proviant zusammen. Er fand einen Käse, den er sich einsteckte. Vor dem Stadt-Tor bemerkte er einen Vogel, der sich in einem Strauch verfangen hatte, den steckte er auch noch ein. Der Weg führte ihn auf einen Berg. Dort saß ein gewaltiger Riese und schaute sich ganz gemächlich um. Das Schneiderlein ging beherzt auf ihn zu und sprach: „Guten Tag, Kamerad! Hast du Lust mich zu begleiten?“ Der Riese sah den Schneider verächtlich an und sprach: „Du Lump! Du miserabler Kerl!“ „Na sowas!“, antwortete das Schneiderlein und zeigte dem Riesen den Gürtel. Der Riese las: „Sieben auf einen Streich,“ ...  Das war "Das tapfere Schneiderlein", gelesen von Grandpa aus JAWS in der Geschwindigkeit 134. Kommen wir zu unserem ersten Interview. Ja, heute spreche ich wieder mal mit Detlef Girke, unserem externen Berater in dem Projekt iDESkmu. Und es geht um etwas sehr spannendes, nämlich um eines unserer Projektziele. Erzähl uns doch mal: Was ist die iDESkmu Software Testing Suite Die Software Testing Suite? Das ist ein modulares und erweiterbares Tool zur Erfassung von Barrieren. Und dabei haben Nutzerinnen und Nutzer die Möglichkeit eigene Prüfkataloge zu erstellen und zu verwalten, ja selbst eigene Prüfformen wie kooperative Evaluation im Rahmen einer heuristischen Untersuchung der Software-Ergonomie und so weiter einfach selbst aufzubauen. Das ganze mit dem Ziel, dass nicht immer mehr unterschiedliche Tools für die unterschiedlichsten Zwecke genutzt werden. Nicht - wie heutzutage noch absolut üblich - hunderte von Seiten voll geschrieben werden und nachher dann mühevoll analysiert werden müssen, sondern dass das alles sozusagen in einem Tool systematisch gesammelt wird. Ja, und das ganze Tool besteht aus drei Bereichen. Wir haben einmal einen Administrations- bereich natürlich. Prüfverfahren müssen natürlich erst entwickelt und dann natürlich auch in irgendeiner Form eingepflegt werden. Dann den Prüfbericht natürlich, wo man eben die Tests dann eben durchführt. Und ganz wichtig als drittes natürlich auch noch den Reporting Bereich, weil nur ein guter Report ist auch ein Report, der etwas nützt am Ende, weil der Report ist sozusagen die erste Kommunikationsmöglichkeit, bevor man dann in den Dialog tritt. Und solche Reports müssen natürlich auch barrierefrei sein. Gerade aber jetzt im Bereich der Prüfung, da soll es in Zukunft auch darum gehen, das Tool um zum Beispiel automatisierte Tests oder zumindest nach dem Aufruf durch das Tool funktionierende Tests zu erweitern. Also es gibt ja zum Beispiel sowas wie den Color Contrast Analyser von der Paciello Group, die das ja kostenlos zum Download bereitstellen. Und wenn dieses Tool dann zum Beispiel direkt aus der Software Testing Suite aufrufbar ist und man es einfach direkt nutzen kann, ohne dann noch mal umzuschalten, das Programm aufzurufen oder sowas, sondern einfach nur einmal klick, dann macht es schon ein wenig bequemer, das Testen. Ja, du bist ja unser Spezialist im Bereich der Technik, du bist ja unser technischer Leiter. Deshalb einfach mal ganz provokant die Frage, war denn das von Anfang an so geplant, dieses Tool zu entwickeln im Rahmen des Projektes? Das ist in der Tat eine provokante Frage. Wir haben, als wir uns überlegt haben, wir machen ein solches Projekt, da hatte ich natürlich etwas im Sinn, was so ähnlich war wie das, was es schon gibt. Wie auch anderes. Wir können ja immer nur von dem ausgehen, was es gibt. Und dann das Ganze weiterentwickeln. Und wir hatten wirklich vor, ursprünglich einzelne Prüfmodule zu bauen. Wirklich wie so was wie so eine fest verdrahtete Logik speziell für jeden Kunden gebacken. Und dann ausgeliefert. Und dann kann der Kunde wirklich nur diese Kriterien prüfen, die dann wirklich fest eingebrannt sind in dieses Prüfmodul. Das ist eine unflexible Lösung, aber es hat in sich natürlich auch den Vorteil der Schlankheit. Man muss sich nicht rumschlagen mit einem Administration Bereich, einem Prüf-Bereich, Reporting-Bereich und so weiter, sondern im Zweifel hat man 5, 6 Knöpfe, die man drücken muss und kann sofort loslegen. Also Usability mäßig ist so ein fest verdrahtetes Prüfmodul sicherlich leichter nutzbar zunächst mal als als eine ganze Testing Suite. Auf diese Idee kamen wir überhaupt, weil wir immer gemerkt haben, es gibt so viele Anforderungen im BITV-Test, im Software-Test und so weiter, die einfach immer nicht anwendbar sind. Welches Dokumentenmanagement-System, es sei denn für den Multimedia Bereich, beinhaltet Videos. Noch nicht mal Bilder gibt es ... Doch Bilder gibt es schon in einigen Dokumentenmanagement-Systemen, aber Audioaufnahmen oder irgendwelche seltenen Formate? Wo? Wann hat man schon mal eine InDesign oder eine Quark Express Datei in einem Dokumentenmanagement-System? Meistens sind es doch PDF Dokumente, Word- Dokumente, Excel-Dokumente und damit hat sich's. Und von daher braucht man eigentlich auch nicht so viele Anforderungen und das wollten wir halt fest verdrahten sozusagen: Ok, dieses DMS braucht nur diese Anforderung und dann kann man das entsprechend prüfen. Das hätte natürlich eine gewisse Halbwertszeit gehabt. Also spätestens nach zwei Jahren wäre dieses Modul wahrscheinlich unbrauchbar gewesen und es hätte einfach ein neuer Prozess losgehen müssen, um zu ermitteln, wie das nächste Modul auszusehen hat. Und dann wurde neu überlegt. Genau. Es gibt ja so viele Wege, Barrieren zu erkennen, einerseits die technische Prüfung, dann die Prüfung, die nur Menschen durchführen können, die Sinnhaftigkeit von Beschriftungen, Alternativtexten und Frage nach dem Wohlbefinden. Ich habe das ja an anderen Stellen schon öfter mal beton. Wenn die Arbeit mit der Anwendung Unbehagen verursacht, obwohl die fachliche Expertise vorhanden ist, dann kann es ja nur an der Anwendung liegen. Und sehr häufig ist es genau dieses Unbehagen, das ein ganz wunderbarer Hinweisgeber ist für Optimierungsmaßnahmen. Einfach nur zur Geschichte jetzt noch weiter für unsere Software Testing Suite: Irgendwann haben wir dann gemerkt, dass es teils gar nicht möglich wäre, einem Kunden einen komplett optimal individualisierten Prüfkatalog oder Fragenkatalog zu erstellen, sondern es wäre viel, viel besser, wenn Kunden dann auf Basis unserer Vorschläge ihre eigenen Kataloge erstellen und anpassen können. Das ist aber nur dann möglich, wenn die eingesetzte Anwendung natürlich entsprechende Flexibilität besitzt. Und die Software Testing Suite ist bzw. wird genau so eine Anwendung sein. Hoch flexibel und zuschneidbar auf alle Kundenbedürfnisse. Kannst du noch ein bisschen genauer beschreiben, wie es dann dazu gekommen ist? Ja, wie das dazu gekommen ist? Also unser Projektpartner Uni Siegen besitzt ja eine große Expertise im Bereich Human Centered Design, kurz HCD. Und durch unsere Zusammenarbeit haben wir eben gemerkt, dass es sehr von Vorteil wäre, die Entwicklung der Prüfmodule gemeinsam anzugehen. Das ist so ein richtiger, typischer, ich nenne es mal iDESkmu-Effekt. Wir arbeiten sowieso alle sehr vernetzt miteinander. Es gibt kaum ein Arbeitspaket, wo jemand ... Es gibt eigentlich gar keins, wo man es wirklich ganz alleine, ... eigentlich hängen da alle mit drin. Und das ist auch gut so, weil genau aus dieser Teamarbeit, aus dieser Zusammenarbeit ergibt sich ja gerade das: dieser Mehrwert unseres Projektes. Das ist auch genau das, was wir zeigen wollen, dass eine gute Kommunikation zu perfekten Ergebnissen führen kann, nicht nur innerhalb unseres Projektes, sondern eben auch in Unternehmen. Na ja, und die Uni Siegen hat auf jeden Fall, nachdem wir gemerkt haben, dass wir das gemeinsam angehen wollen, zwei Design-Workshops veranstaltet, einen noch vor Ort in Siegen, den zweiten dann online. Und an diesen Workshops haben Menschen mit Behinderung teilgenommen oder auch Menschen ohne Behinderung, Menschen mit Expertise im Bereich barrierefrei IT, mit Expertise im Bereich HCD und Menschen auch ohne, ganz ohne Expertise in diesen Bereichen, aber mit viel Erfahrung im Bereich der Nutzung von Software, welche auch immer. Und gemeinsam mit Teilnehmerinnen und Teilnehmern haben wir dann Überlegungen angestellt, wie solche Prüf-Module optimal gestaltet werden könnten. Was braucht man? Und daraus ist letztlich die Idee entstanden, ein universelles Prüftool, ein universelles Prüfmodul zu bauen und dieses universelle Prüfmodul, das haben wir dann eben Software Testing Suite genannt. Das hört sich an, als hätte sich da eine große Veränderung eingestellt in Bezug auf eines der Projektziele. So eine Software muss ja entwickelt werden. Wurde die denn ausgeschrieben? Das war zunächst so angedacht, das auszuschreiben. Aber zunächst mal haben wir festgestellt: "Hey, wir haben ja intern die ganze Expertise vorhanden." Wir haben einerseits den Bereich Planung, den Bereich Programmierung und so weiter, den haben wir mit im Projekt drin und deswegen haben wir uns einfach dazu entschieden, gemeinsam eine AG ins Leben zu rufen, die AG Software Testing Suite, und wir entwickeln die Anwendung einfach projektintern und realisieren sie. Und die Uni Siegen unterstützt uns eben bei der Planung des Interface Designs. Darin besitzt sie oder Teile der Mitarbeiterinnen und Mitarbeiter auf jeden Fall jahrelange Erfahrungen und die Firma HAVI übernimmt jetzt die Programmierung. Und ich bleibe dabei, ich leite den technischen Part, also mache ich die Projektsteuerung. Das ist sehr spannend. Wann soll es denn soweit sein, dass das Tool zum Einsatz kommt? Im Herbst soll es soweit sein. Wir wollen also bis zum Projektende allen unseren Partnern das Tool natürlich an die Hand geben, wollen es selber einsetzen natürlich bei unseren Tests. Und ja, wir wollen es ja auch bei der optimalen Individualisierung unterstützen. Eben das, dass sie eben das Tool dann so nutzen können, dass es ihnen am meisten Gewinn bringt. Es geht ja nicht nur darum, das Tool in einem Unternehmen einmal einzusetzen, sondern es soll ja maßgeschneidert sein und in möglichst vielen Abteilungen eingesetzt werden. Das heißt, das Tool muss für unterschiedliche Anwendungsbereiche innerhalb eines Unternehmens auch mehrfach angepasst werden. Die Software Testing Suite ist letztlich nicht nur ein unternehmensinternes Kommunikationsmittel bezogen auf das Thema barrierefreie IT. Sondern es ist gleichzeitig auch ein Sensibilisierungstool dem gesamten Thema gegenüber. Und es soll helfen, Berührungsängste mit Menschen mit Behinderung abzubauen. Wenn ich an meinem Arbeitsplatz sitze und eine Dokumentationsmöglichkeit für Barrieren habe, steigert sich natürlich auch mein Bewusstsein dafür, was ein Mensch mit Behinderung empfinden könnte, wenn er auf diese oder jene Barriere stößt. Und schon ist da ein anderer Punkt. Wenn einem dann zum Beispiel ein blinder Mensch im Gang entgegenkommt und sagt: "Hey, ist dir das auch schon mal passiert?", und so weiter und schon hat man das Gespräch. Und wenn dann alle im Team am Ende, wenn dann die Barrierefreiheit soweit hergestellt ist, dass alle im Team über das Gleiche sprechen können, obwohl sie eine Anwendung aus ganz, ganz unterschiedlichen Modalitäten heraus wahrnehmen, dann hat die Software Testing Suite ja nicht nur in technischer, sondern eben auch in menschlicher Hinsicht ja den ihr angedachten Zweck erfüllt. Das heißt, wer soll alles diese Testing Suiten nutzen? Das fängt an mit Mitarbeiterinnen und Mitarbeitern im Verwaltungsbereich zum Beispiel, die erst mal überhaupt gar keine Berührungspunkte haben mit Barrierefreiheit. Also klassische Anwenderinnen und Anwender. Klassische Anwenderinnen und Anwender sollen die Software Testing Suite für all die Dinge an die Hand bekommen, die man eben auch ohne fachliche Expertise testen kann. Spannend! Und dann weitere Gruppen? Ja, natürlich! Entwicklerinnen und Entwickler zum Beispiel, die eine potentiell höhere Expertise haben und ein höheres Verständnis dafür, was an Barrieren auftreten kann und vor allen Dingen, wie man solche Barrieren beheben kann. Und auch die Leute bekommen dann entsprechende Prüfschritte zugeteilt sozusagen und können dann mit der Software Testing Suite arbeiten. Im Idealfall hat die Software Testing Suite sogar etwas Selbst- lernendes: Ich fange an zu testen. Die Software Testing Suite bemerkt, was ich kann und was ich nicht kann. Oder ich mache Haken bei dem was ich kann und nicht kann. Und entsprechend werden mir Prüfschritte zugeordnet. Dann teste ich weiter, lerne dazu, die Software Testing Suite registriert es und ich bekomme wieder einen oder mehrere weitere Schritte zugeordnet und so weiter und so fort. Und so unterstützt einen die Software Testing Suite. Ja, so ein bisschen KI, so ein bisschen intelligent gestützt auf jeden Fall dabei seine eigene Expertise zu erweitern. Das klingt wirklich sehr spannend, Detlef. Wir haben ja in einem anderen Beitrag schon über die öffentlich zugänglichen Testverfahren gesprochen. Reiht sich denn die Testing Suite dann da ein? Nein, die Testing Suite ist ein Instrument, letztlich zum Erstellen von Prüfreports. Ja! Und ein solches Instrument, wie wir es jetzt vorhaben zu bauen, das gibt es derzeit noch nicht. Was es momentan gibt, das sind Prüfumgebungen, Dokumentationsumgebungen, wo ich auch Prüfschritte definieren kann, diese Prüfschritte abarbeiten kann, die Prüfschritte bewerten kann. Ich kann sogar ein Scoring mit einbauen und erhalte dann nachher auch einen barrierefreien Prüfbericht. Aber es ist doch alles immer noch sehr starr und orientiert sich immer noch sehr, sehr stark an dem, was sozusagen Anfang der 2000er Jahre seit 2003 durch den BITV-Test vorgegeben wurde. Wir weichen jetzt von dieser Linie vollkommen ab, erlauben mit unserer Software Testing Suite diese Form des Testens, wie beim BIK BITV-Test. Wir erlauben heuristische Untersuchungen, wir erlauben kooperative Evaluationen, wir erlauben natürlich Softwaretests, entweder in der Form, dass wir einzelne Punkte herauspicken und dann sagen: "Okay, hier ist ein Fehler." Also elementweise prüfen oder auch nach Use Cases prüfen. Das Tool ist wirklich sehr, sehr universell gedacht und es soll dabei natürlich noch eine perfekte Benutzeroberfläche haben. Dafür haben wir die Uni, die Uni Siegen mit dabei, die uns immer wieder auf die Finger schaut und sagt: "Nein, das ist ein Klick zu viel. Da müssen wir etwas anders denken." Alles klar! Du sagtest ja, im Herbst soll das Tool zum Einsatz kommen und das läuft ja - das Projekt iDESkmu - noch bis August 2022. Das heißt, dieses Zeitfenster wird dann genutzt, um diese Suite noch zu optimieren, im Einsatz zu testen, mit den LOI-Partnern zum Beispiel zu optimieren und Ähnliches? Ja genau! Zu optimieren, einzuführen, eine größere Plattform aufzusetzen, die den Anwenderinnen und Anwendern es auch erlaubt, Kritik zu üben, Verbesserungsvorschläge zu machen. Wir können das dann alles sammeln und noch in die weitere Entwicklung einfließen lassen. Großartig! Ja, und derzeit ist es auch noch geplant - ich weiß nicht, ob das am Ende möglich ist - das hängt natürlich auch von den beteiligten Projektpartnern ab - aber momentan ist es noch geplant, das ganze Tool auch öffentlich, also den ganzen Quelltext öffentlich zugänglich zu machen, sodass dann die Community weiter programmieren kann und das Tool weiter optimieren kann oder auch etwas eigenes draus machen kann. Also einen sogenannten Fork. Also ist das schon etwas sehr, sehr innovatives, was im Rahmen des Projektes entsteht? Ja! Es ist zumindest so innovativ, dass ich mich richtig darauf freue. Klasse! Ja, danke dir, Detlef, dass du uns einen Einblick gegeben hast in eines unserer ganz erklärten Ziele im Projekt iDESkmu, nämlich das Tool Testing Suite. Wir werden noch einige andere Beiträge von dir hören im Rahmen unserer Podcastreihe. Erst mal ganz herzlichen Dank und unsere Hörerinnen und Hörer können sich natürlich auf unserer Webseite unter www.projekt-ideskmu.de über den aktuellen Stand der Entwicklung immer informieren. Vielen, vielen Dank, Detlef! Bitte schön! Jetzt erhalten Sie die Antwort auf die Frage aus der letzten Episode: Was verbirgt sich hinter der iDESkmu Software Testing Suite? Nach den Ausführungen von Detlef Girke fasst Dr. Fabiano Pinatti, tätig als Research Associate und Deputy Director am Lehrstuhl für Computer Supported Cooperative Work and Social Media an der Universität Siegen die Informationen für uns zusammen. Die iDESkmu Software Testing Suite ist ein modulares, erweiterbares Tool zur Erfassung von IT Barrieren. Sie besteht aus den Bereichen Administration, dem Prüfbereich und dem Reporting. Sie ermöglicht, eigene Prüfkataloge zu erstellen und zu verwalten und sogar eine Prüfform wie zum Beispiel heuristische Evaluation zu ergänzen. Die iDESkmu Software Testing Suite ist hochflexibel und individualisierbar. Das heißt, die Nutzerinnen können es selbst nach den eigenen Bedürfnissen aufbauen. Weiter geht es mit einer neuen Quizfrage, die wir in der nächsten Episode beantworten. Stellen Sie sich vor, Sie tappen mit eingeschaltetem Screenreader durch eine Anwendung. Plötzlich hören Sie: "Eingabefeld. Bitte geben Sie Text ein." Sie wissen aber nicht, welchen Text sie eingeben sollen. Daraufhin tappen sie weiter und hören plötzlich "Keine Suchergebnisse". Was ist alles falsch gelaufen? Antwort A: Mit JAWS wäre das nicht passiert. Antwort B: Die Beschriftung von Formularfeldern muss von Screenreadern immer mit einem speziellen Tastaturbefehl, nämlich EINFÜGEN + F ermittelt werden. Antwort C: Das Feld hat keine programmatisch ermittelbare Verknüpfung zum dazugehörigen Label und wird unangekündigt als Eingabefeld mit Autovervollständigung genutzt. Kommen wir zu unserem zweiten Interview. Herzlich willkommen, Stefan Schnürer, heute das zweite Mal mit uns im Gespräch im Projekt iDESkmu im Rahmen unserer Podcast Reihe KLARTEXT FÜR IT OHNE BARRIEREN. Stefan Schnürer war schon Gast, wie gesagt und stellt sich jetzt noch mal für die neuen Zuhörerinnen und Zuhörer kurz vor. <v Stefan Schnürer, Ministerium für Energieinfrastruktur und Digitalisierung>Ja, auch herzlich willkommen von meiner Seite aus! Dankeschön für die erneute Einladung zu diesem Gespräch. Ich arbeite im Ministerium für Energieinfrastruktur und Digitalisierung in der Abteilung für Digitalisierung und bin dort zuständig im Referat 520 war ich zuständig für das Vergabeverfahren, wo es darum ging, eine E-Akte Software zu beschaffen, die dann in der gesamten Landesverwaltung eingesetzt werden soll, sprich in den Ministerien und der Staatskanzlei sowie auch in den nachgeordneten entsprechenden Landesbehörden und in dieser Funktion war es für mich auch wichtig, also hatte ich dann die Vergabe selbst begleitet. Unter anderem halt auch unter dem Aspekt, dass wir eine Software beschaffen wollen, die einen höchstmöglichen Grad der Zugänglichkeit gewährt, also im Rahmen der Barrierefreiheit auch entsprechend positiv abschneidet. Ja, toll, vielen Dank! Ihr erster Beitrag handelte ja von den Mindestkriterien bei der Beschaffung inklusive Leistungsbeschreibung bei Ausschreibungen. Heute kommen wir zu dem nächsten Schritt in diesem Prozess, nämlich der Angebotsbewertung und Auswahl. Den ersten Teil hören Sie übrigens in unserer Episode #09. Die Frage, mit der ich starte: Wir sind ja jetzt an dem Punkt, die Ausschreibung wurde veröffentlicht, die Ausschreibungs- frist ist abgelaufen und Angebote sind eingegangen. Wie kann man gewährleisten, dass auch nur die Angebote in die Auswahl kommen, die die zuvor festgelegten Kriterien tatsächlich erfüllen? <v Stefan Schnürer, Ministerium für Energieinfrastruktur und Digitalisierung>Also wir haben uns da in unserem Verfahren vorher mit den Rechtsberatungen abgestimmt, wie man natürlich, ich sage mal dann auch nur zu Angeboten kommt, die man auch wirklich haben möchte, dass man die größtmögliche Qualität bekommt, aber natürlich überhaupt auch Angebote bekommt. Das muss man immer ein Stück weit im Hinterkopf behalten. Wenn man zu scharfe Anforderungen formuliert, kann es sein - das ist ja eine freie Vergabe, worauf sich Firmen dann bewerben - kann es dann halt auch passieren, dass vielleicht der Aufwand, sich dann an dem Verfahren zu beteiligen, zu groß von der Firma angesehen wird bzw. ich sage mal, wir ihnen zu scharf sind als Auftraggeber. Da muss man so ein gewisses Maß halt mitbringen. Und deswegen war es halt auch wichtig, dass wir dort halt entsprechend auch Expertise uns dazu geholt haben von Fachleuten, die solche Verfahren einfach auch schon durchgeführt haben, damit man im Prinzip nicht übers Ziel hinausschießt. Und wir haben natürlich unseren Anforderungskatalog, das ist quasi Dreh- und Angelpunkt gewesen für das Ausschreibungsverfahren. Und im Endeffekt haben wir dort die fachlichen, aber auch nicht fachlich übergreifende Anforderungen gestellt, die dann durch die Software zu erfüllen waren. Und wir sind nachher bei 578 Kriterien in dem Leistungskatalog gelandet. Der war sogar mal viel größer. Der wurde dann aber ein Stück weit eingedampft, weil man die Gefahr im Prinzip gesehen hatte, dass man eventuell sonst am Ziel vorbei schießt und am Ende des Vergabeverfahren mit leeren Händen dasteht, weil sich keine Firma darauf bewirbt. Und von diesen 578 Kriterien, die dort abgefragt wurden, sind 283 Kriterien sogenannte Leistungskriterien gewesen. Das heißt, die sind zwingend zu erfüllen gewesen, damit man überhaupt berücksichtigungsfähig ist in dem Vergabeverfahren, und 295 Quoten-Kriterien und wie der Name schon andeutet, davon musste halt eine gewisse Quote auch umgesetzt werden und wir haben uns dafür entschieden, 90 Prozent dieser Quoten-Kriterien mussten erfüllt sein, damit die Firma überhaupt berücksichtigungsfähig ist mit ihrem Angebot. Die Barrierefreiheit insgesamt, also das Thema Barrierefreiheit, spielte dort auch eine Rolle. Diese Anforderungen sind halt vom fachlichen Berater zusammen mit den Interessenvertretungen, also mit den Schwerbehindertenvertretungen vor allen Dingen erarbeitet worden. Und das sind insgesamt "nur" in Anführungsstrichen 25 Kriterien, die dort festgelegt wurden. Wobei man aber sagen muss, dass es auch Kriterien gibt, die sind dann als ein Kriterium erfasst worden, haben aber diverse Unterthemen, die dann abgefordert werden. Aber diese 25 Kriterien, auch wenn das jetzt vielleicht wenig klingt im Verhältnis, sind reine Leistungskriterien gewesen. Das heißt, die müssen zwingend erfüllt sein, sonst hätte eine Firma nicht den Zuschlag bekommen dafür. Und das war uns halt auch entsprechend wichtig, dass wir damit sozusagen Ausschlusskriterien geschaffen haben, um dieses Thema halt auch entsprechend zu gewichten. Dann kann ich also zusammenfassend sagen, dass nicht nur der Preis sozusagen über die Vergabe entscheidet. Vielleicht können Sie noch ein bisschen was zur Bedeutung des Preises sagen. <v Stefan Schnürer, Ministerium für Energieinfrastruktur und Digitalisierung>Genau. Natürlich sind wir immer angehalten, ich sage mal im Rahmen von Ausschreibungen, das sogenannte wirtschaftlichste Angebot zu ermitteln, sprich Preis ins Verhältnis gesetzt zu Leistung. Allerdings, und das haben wir vorab abgeklärt mit unserem Rechtsberater und auch mit der Vergabekammer. Die werden ja quasi die Instanz gewesen, hätte es Verfahrensrügen gegeben, wo wir denn unser Verwaltungsverfahren dann ausgefochten hätten. Mit denen haben wir vorher abgesprochen, welches Verfahren man anwenden kann. Und wir sind bei einer sogenannten erweiterten Richtwert-Methode gelandet für unser Vergabeverfahren, um im Prinzip nicht nur den Preis im Verhältnis zur gebotenen Leistung in die Wertung einfließen zu lassen. Diese erweiterte Richtwert-Methode quasi bedeutet im Endeffekt, man zieht noch ein zweites Qualitätskriterium mit rein. Nicht nur die reine Preisbildung, sondern man gewichtet auch noch weitere Themen für den Zuschlag. Und da ist es quasi im Prinzip so gewesen, dass wir ausgehend vom Besten - der hätte ja ein Quotienten ermittelt: Preis durch Leistung. Und ausgehend von diesem Besten haben wir gesagt: "Okay, alle Angebote, die sich innerhalb eines 10 Prozent Bereiches um das beste Angebot sammeln, also 10 Prozent ... Bis zu 10 Prozent darunter liegen, also dicht dran sind, aber nicht ganz so gut wie das beste Angebot, die werfen wir alle gemeinsam in einen Topf und gucken uns dann an, wie das Abschneiden in der Teststellung war. Das heißt, es wäre dann der Zuschlag nicht an die Firma erteilt worden, die im Zweifel das preislich beste Angebot gemacht hätte, sondern dann wäre tatsächlich als Zuschlagskriterium die Firma in Betracht gekommen, die am besten in der Teststellung abgeschnitten hat und die Teststellung selbst umfasste die ganzen fachlichen Tests durch das Personal, also durch das Personal, die wir bereitgestellt haben, und auch das Thema der Barrierefreiheit. Das Thema der Barrierefreiheit selber ist hier nicht in der Teststellung mit einem eigenen Testbogen eingeflossen, wodurch sozusagen denn auch entsprechend auch dieses Thema in der Software schon während des Ausschreibungsverfahrens wirklich auf Herz und Nieren abgeklopft wurde. Und dieser Testbogen, der entsprach dann auch 1:1 den formulierten Anforderungen, die in der Ausschreibung zu finden waren? <v Stefan Schnürer, Ministerium für Energieinfrastruktur und Digitalisierung>Genau! Das ist wirklich 1:1 so übernommen worden. Das sind ja auch die Anforderungen, die vorher quasi durch den fachlichen Berater zusammen mit den Interessenvertretungen, Schwerbehindertenvertretung erarbeitet wurden. Und dieses ist auch wirklich so 1:1 abgeprüft worden, während bei den fachlichen Tests das so war, dass man quasi eine Qualitätsbewertung abgegeben hat, um auf bestimmte Punkte zu kommen. Also wie gut ist zum Beispiel das Anlegen einer neuen Akte in diesem E-Akte-System umgesetzt worden? Da musste das halt der Tester entsprechend bewerten und hat dort von 0 bis 5 Punkten die Möglichkeit gehabt, sozusagen die Qualität der Umsetzung im System zu beurteilen. Bei dem Testbogen der Barrierefreiheit wollten wir gerade im Prinzip ja in dem Sinne ein "Ja" oder "Nein". Deswegen sind quasi hart getestet worden ... sind im Prinzip die Anforderungen dahingehend, sind sie in der Software wirklich so umgesetzt worden, wie sie aus dem Anforderungskatalog halt auch entsprechend abgefordert wurden? Und sollte es da Probleme geben, hätten wir im Prinzip mit unserem fachlichen Berater zusammen immer aufgeschlüsselt und dann hätten wir damit den Softwarehersteller auch konfrontiert. Das Vergabeverfahren selber ist ja an der Stelle nach der Teststellung noch nicht zu Ende gewesen, sondern wir haben ja noch eine nachgelagerte Verhandlungsphase mit den Bietern im Prinzip auch entsprechend aufgesetzt. Und dort wurden dann auch Themen da, wo nicht noch einmal über die Preisbildung, nicht nur über die Preisbildung nochmal so ein bisschen gesprochen, sondern es wurde halt auch über bestimmte Sachen, Themen, wie wo aus unserer Sicht Nachsteuerungs- bedarf gab bei der Barrierefreiheit, die wurden dann den Bietern so vorgetragen mit der Bitte, das dann entsprechend auch zu korrigieren, wenn dort Sachen durch unseren fachlichen Berater als mangelhaft oder als nicht so wie gewünscht umgesetzt bewertet wurden. Hat es da eigentlich eine Veränderung in dem Vergaberecht gegeben oder war diese Vorgehensweise immer möglich? Ich meine zu erinnern, dass es da eine Novellierung gegeben hat in der Vergangenheit. <v Stefan Schnürer, Ministerium für Energieinfrastruktur und Digitalisierung>Ja, da gab es was. Jetzt muss ich gestehen, da ich selber ja kein Vergaberechtsexperte bin, bin ich da jetzt nicht ganz im Bilde, wann da diese Möglichkeit halt mit aufgenommen wurde in das Vergaberecht. Aber wir haben tatsächlich wirklich diesen, wenn man so will "Joker" gezogen zusammen in Abstimmung mit unseren Rechtsanwälten und der Vergabekammer, dass wir sagen konnten: "Okay, der Preis ist sicherlich immer noch ein wesentliches Kriterium, aber wir können das mehr in das Thema Qualität steuern, ohne immer nur sagen zu müssen, auch als Land in dem Fall, wo wir die Ausschreibung machen, es muss immer das günstigste Angebot werden." Da konnten wir uns klar ein Stück weit abgrenzen. Wir haben uns entschieden, die gesamte Teststellung quasi in dieser erweiterten Richtwert-Methode als Zuschlagskriterium auszuwählen. Wenn man jetzt das Thema Barrierefreiheit noch einen höheren Stellenwert einräumen möchte, hätte man sogar auch rein das Abstellen auf das Abschneiden in diesem Testbogen zum Zuschlags-Kriterium machen können. Das ist zulässig im Vergaberecht. Also man muss im Prinzip quasi mit den Firmen zusammen und das sind ... müssen Spielregeln sein. Die müssen klar vorher formuliert werden. Wir hatten dann ein Dokument, das nannte sich Bewerber- und Bieter-Bedingung und da ist das haarklein aufgeführt worden. Das wird dann bekanntgegeben, zusammen mit den weiteren Vergabeunterlagen. Und da konnte jeder Bieter quasi transparent reingucken und sagen "Okay, das sind die Spielregeln. Darauf lasse ich mich ein, wenn ich mich hier beteiligen möchte." Und da sah man dann halt auch "Okay, es kann sein, dass mein günstiges Angebot nicht das wird, das den Zuschlag bekommt, weil hier die Teststellung ein höheres Wertungskriterium ist oder ein Zuschlagskriterium ist." Und da hätte man natürlich auch noch mal reinschreiben können, tatsächlich "Abschneiden der Feststellung in Fragen der Barrierefreiheit" ist das Zuschlagskriterium, wenn sozusagen die Firmen sich in einer bestimmten Range bewegen, um halbwegs gleichwertig zu sein. Ja, vielleicht können Sie unseren Zuhörerinnen und Zuhörern dann zum Abschluss noch mal so ganz kurz in wenigen Stichworten zusammenfassen: Worauf sollte man achten bei der Angebotsbewertung und Auswahl? <v Stefan Schnürer, Ministerium für Energieinfrastruktur und Digitalisierung>Also bei der Angebotsbewertung empfiehlt sich wirklich, die abgeforderten Kriterien testen zu lassen und zu testen und auch das Test-Prozedere klar zu beschreiben. Testbögen vorab bereitzustellen, denen auch mitzuteilen und auch sich Test-Personal auch entsprechend zu sichern, dass dann diese Anforderung testen kann. Wir haben unsere Bewertung, also rein "ja / nein", die Fragen der Barrierefreiheit durch einen fachlichen Prüfer bewerten lassen. Man hätte natürlich zusätzlich noch die Umsetzung durch weitere Anwender, die Betroffene sind, wir hätten weitere Kolleginnen und Kollegen einbinden können, die dann diese Kriterien der Barrierefreiheit auch noch mal persönlich mit testen und dafür vielleicht sogar Punkte vergeben können, so dass man dazu kommt, dass man wirklich dann auch angebotsentsprechend abklopft in einer Teststellung. Und was immer wichtig ist aus meiner Sicht ist diese Verhandlungsphase hinten dran, dass man wirklich die Möglichkeit hat, weil in dem Moment will die Firma ja noch sozusagen einen Auftrag haben und ist sehr gewillt allem entgegenzukommen. Das hat auch unser rechtliche Berater in einem Live-Protokoll auch entsprechend mit alles aufgeführt. Die ganzen Punkte und dort ist man im Gespräch mit den Bietern. Und wir konnten dann noch sagen hier die Punkte, die Punkte, die Punkte sind festgestellt worden, da ist das Thema Barrierefreiheit noch nachbesserungsbedürftig. Setzt das bitte um, sonst seid ihr raus. Und dann hat man natürlich von denen das bekommen. Ja, okay. Und muss dann natürlich im Rahmen des Vergabeverfahrens natürlich dafür sorgen, dass diese Punkte dann auch umgesetzt werden. Das Verfahren ist jetzt in der Position noch nicht zu Ende, sondern unser fachlicher Berater wird auch noch mal, obwohl das Vergabeverfahren abgeschlossen ist, jetzt im Rahmen unseres technischen Piloten eingebunden werden und wird auch Sachen nachtesten und noch mal das ganze Thema der Barrierefreiheit entsprechend auf den Tisch bringen und durchtesten, bevor wir eine endgültige Abnahme des Produktes erklären. Also da haben wir noch mal - sage ich mal - so einen zusätzlichen Punkt eingezogen, um dieses Thema noch mal in den Fokus zu bringen. Ja, da würde ich sogar gerne ergänzen wollen. So hatte ich Sie in Ihrem ersten Beitrag in der Episode #09 verstanden, dass dieser Experte auch selbst ein Betroffener sein kann. Das heißt, zum Beispiel ein Sehbehinderter oder Blinder. Das heißt, wenn man die Mitarbeiter nicht im Unternehmen hat, um diese Barrierefreiheit als Betroffener zu prüfen, ist es durchaus möglich und sinnvoll, sich diese Prüfung extern einzukaufen. <v Stefan Schnürer, Ministerium für Energieinfrastruktur und Digitalisierung>Auf jeden Fall! Unser fachlicher Berater in der Barrierefreiheit selbst ist stark sehbehindert gewesen. Und Sie glauben gar nicht, was das für ein Vertrauen aufbaut, auch gegenüber den Interessenvertretung. Wenn man im Prinzip jemanden hat an seiner Seite, der selbst Betroffener ist, weil sie dann wissen, dass ist jemand, der kümmert sich genau um die Anliegen, die wir auch haben, der versteht unsere Anliegen, weil er selbst Betroffener ist. Und er ist natürlich auch in der Lage, dann wirklich auch unter diesen Gesichtspunkten entsprechend die Tests auch durchzuführen und hat natürlich auch ein Gewicht, wenn er sagt: "Okay, ich als Betroffener stelle hier fest der Screenreader, also die Software, mit der man quasi dann die Sprachausgabe für das Programm ermöglicht, das funktioniert an den Stellen einfach noch nicht. Da muss was nachgebessert werden, oder aber die Tastatursteuerung ist nicht an allen Elementen möglich. Dann ist das halt auch so und dann muss das korrigiert werden. Und das hat wie gesagt für uns einen sehr großen Mehrwert gehabt, dass wir da jemanden hatten an der Seite, der nicht nur fachlich im Gebiet unterwegs ist, sondern selbst auch Betroffener war an der Stelle. Ja! Ja, ganz herzlichen Dank wieder für diese sehr starke Ausführlichkeit in Bezug auf die Angebotsbewertung und Auswahl. Ich kündige noch Ihren dritten Beitrag an, da gehen wir noch mal ein bisschen vertieft auf die Prüfung der Kompetenz des Anbieters und die Qualitätssicherung ein. Und dieser Beitrag, der wird ausgestrahlt in der Episode #13 und ich freue mich drauf, dass wir uns dann wieder hier hören und sprechen. <v Stefan Schnürer, Ministerium für Energieinfrastruktur und Digitalisierung>Ja, die Freude ist ganz auf meiner Seite. Vielen Dank. Danke! Vielen Dank an Stefan Schnürer und Detlef Girke für die Unterstützung des Projekts durch Ihre Beiträge. Hier nochmals der Hinweis auf unsere Shownotes. Sie finden dort neben den Hintergrundinformationen zu unseren Gesprächspartnern grundsätzlich umfangreiche Quellenangaben und interessante Tipps rund um die Beiträge und Themen dieser Episode. In der nächsten Episode spricht Michael Große-Drenkpohl vom Inklusionsamt Arbeit des Landschaftsverbands Westfalen-Lippe, kurz LWL, mit Oliver Nadig, Studium der Psychologie und Informatik in Marburg und tätig als Rehabilitations- lehrer für EDV und elektronische Hilfsmittel sowie Mitglied im Fachausschuss für Informations- und Telekommunikations- systeme, kurz FIT. Sie geben Tipps für Entwicklerinnen und Entwickler zu der Frage: Wie bekommt man einen Einstieg in das Thema Barrierefreiheit? Im anschließenden Gespräch erneut mit Stefan Schnürer vom Ministerium für Energie, Infrastruktur und Digitalisierung in Mecklenburg-Vorpommern unterhalte ich mich mit ihm über die Prüfung der Kompetenz des Anbieters sowie die Qualitätssicherung im Rahmen von Ausschreibungsverfahren. Wir freuen uns, wenn wir auch mit den heutigen Beiträgen Ihr Interesse geweckt haben. Abonnieren Sie diesen Podcast und teilen Sie ihn mit Ihrem Netzwerk und folgen Sie uns auf Facebook oder Twitter. Lernen Sie uns gerne noch besser kennen und besuchen uns dafür auf unserer Webseite unter www.projekt-ideskmu.de. Bei offenen Fragen oder neuen Fragen, die sich ergeben haben, senden Sie uns gerne eine Nachricht. Wir freuen uns darauf. Das war die Episode #12 der Podcast Serie KLARTEXT FÜR IT OHNE BARRIEREN zu dem Projekt IDESKMU. Mein Name ist Nadia David. Vielen Dank für Ihr Zuhören!