Projekt IT-Schuladministration

Transkript

1 Kanton Zürich Bildungsdirektion Mittelschul- und Berufsbildungsamt Informatikabteilung Mirjam Lehmann & Daniel Stucki Projektleitung IT_Schuladministration Ausstellungsstrasse 80 Postfach 8090 Zürich Telefon / mirjam.lehmann@mba.zh.ch / daniel.stucki@kzu.ch Lieferobjekt Projekt IT-Schuladministration Projektauftrag

2 Seite 2/23 Inhalt 1. Projektdaten IST-Zustand / Problemstellung Projektumfang Vision und Zielgruppen Vision Zielgruppe Ziele Systemziele Projektziele Projektabgrenzung Abgrenzung aus fachlicher und prozessualer Sicht Abgrenzung aus organisatorischer Sicht Abgrenzung aus systembezogener und technischer Sicht Lösungsvarianten und Soll-Architektur Grundsätze Soll-Architektur Lösungsvarianten Grundidee Lösungsaufbau Bevorzugte Betriebs- / Service Modelle Organisation Termine und Meilensteine Kapazitätsplan Kosten- und Budgetplan Wirtschaftlichkeit Risiken Risiken betreffend personellen Projektressourcen Beschaffungsspezifische Abwicklungsrisiken Weitere Abwicklungsrisiken Risiken der Lösung (LR) Entscheide Unterschriften... 23

3 Seite 3/23 Zweck und Abgrenzung des Dokuments Die Themen aus dem Projektantrag werden vertieft und verschiedene Lösungsansätze skizziert. Es wird eine grundsätzliche Aussage getroffen, ob die Lösungsansätze realisiert werden können und zu welchen Bedingungen. Eine Zusammenfassung des Dokumentes fliesst in den Projektauftrag ein. Änderungsgeschichte Version: Datum Autor(en): Bemerkungen und Änderungen V Karin Fischer Draft V Karin Fischer Version für Review PLT V Mirjam Lehmann Anpassungen aufgrund Feedback PA Review V Mirjam Lehmann Anpassungen aufgrund PA-Sitzung V Mirjam Lehmann, Daniel Stucki V Karin Fischer Qualitätscheck V Mirjam Lehmann Anpassung Lösungsvarianten Änderungen akzeptiert, Versionierung abgeschlossen V Mirjam Lehmann Änderungen gemäss Auftrag PA Referenzierte Dokumente Martin Egger Projektinitialauftrag V Mirjam Lehmann Daniel Stucki Machbarkeitsanalyse V Mirjam Lehmann Daniel Stucki Projektplan V Mirjam Lehmann Daniel Stucki Risikokatalog Informatik-Strategie für die Sekundarstufe II Verabschiedet durch die Informatik- Kommission für die Sekundarstufe II am 9. Juni 2011 Zweite Auflage August 2005 Baudirektion und Finanzdirektion Kanton Zürich PosatZH Projektmanagement-Handbuch Verteiler Name: Name:

4 Seite 4/23 1. Projektdaten Projektname Übergeordnetes Programm - Auftraggeber Marc Kummer, Amtschef MBA Karin Fischer, APP (Lead) Projektcoach Reto Wagner, APP Rüdiger Vietze, APP Akt. Projektphase Initialisierung SAP-Sachkonto ( ) Zeiterfassung-Konto Excel Kernprozesse Schuladministration Zugeordnete Teilprojekte Unterstützungsprozesse Schuladministration IT Integration Mirjam Lehmann (MBA) Projektleiter Daniel Stucki (MBA) Projektcontroller Robert Welle, prolan systems ag Qualitätssicherung offen SAP-Leistungsnr. PSP-Nr 7385P RRB/Verfügung 2. IST-Zustand / Problemstellung In der längerfristigen Planung der Informatikabteilung war vorgesehen, die aktuell bei den Schulen der Sekundarstufe II im Einsatz stehende und zentral betriebenen Schulverwaltungs-Applikationen ab 2016 durch eine einheitliche, neue, moderne Schulverwaltungs-Applikation abzulösen. Inzwischen sind nicht nur die Sekundarstufe II, sondern auch Tertiärstufe und gymnasiale Vorbildung in den Fokus gerückt. Beide Applikationen der «Information Manager» (IM) bei den Mittelschulen (MS) und «Eco open» bei den Berufsfachschulen (BFS) - stehen seit über zwölf Jahren im produktiven Einsatz. Eco open wird als Fachapplikation von allen BFS eingesetzt mit Ausnahme der Berufsfachschule für Erwachsenenbildung Zürich, die den IM einsetzt und der gestalterischen BMS Zürich, welche mit Excel arbeitet. Insgesamt werden in 43 Mandanten rund aktive Lernende und Kursteilnehmende mit Eco open administriert. Der IM steht an 18 der 20 MS im produktiven Einsatz und geniesst eine hohe Akzeptanz bei den MS. Der zentrale virtualisierte Betrieb des IM funktioniert gut und Wartung und Support ist für die kommenden Betriebsjahre sichergestellt. Zwei Mittelschulen setzen andere Lösungen ein, und zwar Proplan (KSHP) und eine eigenentwickelte Lösung (KME). Mit Einschreiben vom kündigte die Federas AG (Hersteller von Eco Open), Zürich, den Lizenz- und Wartungsvertrag mit dem MBA auf den In der Kündigung wird verlangt, dass nach Beendigung des Vertragsverhältnisses die Software zurückgegeben oder vernichtet wird. Daraus ableitend wird ein Nutzungsverbot geltend gemacht. Für das MBA und die BFS ist die weitere Nutzung von Eco open bis zur Einführung einer neuen Lösung existenziell. Eco open muss für die BFS voraussichtlich noch bis 2017/18 in Betrieb bleiben. Für die Evaluation, Implementation, Einführung und Migration einer neuen Schulverwaltungslösung werden mit diesem Mengengerüst rund drei Jahre benötigt. Diese Situation zwingt die Informatikabteilung, die Ablöseplanung der

5 Seite 5/23 Schulverwaltungs-Applikationen diesem Umstand entsprechend anzupassen. Eco open muss so rasch wie möglich durch eine neue Schulverwaltungs-Applikation abgelöst werden. Durch den Kauf der Rechte am Quellcode durch die IG-Eco open (Interessengemeinschaft der Eco open-nutzenden) und anschliessender OpenSource-Deklarierung ist der sichere Weiterbetrieb für die verbleibende Nutzungszeit von Eco open inklusive der Wartung und des Supports zwischenzeitlich sichergestellt. Eco open wird jedoch nicht mehr weiterentwickelt. Das Projekt ist damit ein "zwingendes" Projekt um den künftigen Betrieb der Schulverwaltungen sicher zu stellen. Im Rahmen aktuellen Initialisierungsphase wurden die Voraussetzungen geschaffen für den Entscheid, ob das Projekt durchgeführt wird. Vision und Ziele wurden definiert sowie Grobanforderungen erhoben und Lösungsvarianten erarbeitet. Die Ergebnisse der Untersuchung sind in der referenzierten Machbarkeitsstudie zusammengefasst, Risiken sind identifiziert worden und im Risikokatalog ausführlich diskutiert. Die Planung für das Projekt ist im referenzierten Projektplan zusammengefasst Projektumfang Vision und Zielgruppen Vision Mit dem Projekt IT-Schuladministration soll für die Phase Konzeption mit Ablaufschritten Grobkonzept und Submission/Evaluation folgendes erreicht werden: Für die direkte Zielgruppe eine einheitliche, etablierte und zukunftsgerichtete Fachapplikation evaluieren, die alle relevanten Prozesse einer Schuladministration und die Schnittstellen zur bestehenden Systemlandschaft optimal und sicher unterstützt und allen Beteiligten einen spürbaren Mehrwert bringt. Für die Phasen Detailspezifikation, Umsetzung und Einführung wird angestrebt: Den Berufsfachschulen und Mittelschulen eine einheitliche IT- Schuladministrationslösung bereitzustellen Zielgruppe Direkte Zielgruppe Die direkte Zielgruppe sind die Mitarbeitenden der Schulverwaltung ausgewählter Schultypen im Kanton Zürich. Die ausgewählten Schultypen sind in der nachfolgenden Grafik farbig markiert (siehe Abbildung 1) und setzen sich zusammen aus: Mittelschulen (grün markiert) und Berufsfachschulen (blau markiert). Die grau eingefärbten Schultypen sind nicht Teil der Zielgruppe.

6 Seite 6/23 Abbildung 1: Direkte Zielgruppe Erweiterte Zielgruppe Nutzniessende des Projektes IT-Schuladministration (erweiterte Zielgruppe) sind das MBA, Lehrpersonen und letztendlich auch alle Eltern, Schülerinnen und Schüler, Lehrbetriebe und Praktikumsbetriebe, die von einer verbesserten Administration des Schulbetriebes und optimierten Services und Informationen profitieren. 3.2 Ziele Mit dem Projekt IT-Schuladministration werden die nachfolgend aufgeführten Systemziele und Projektziele erreicht. Die angestrebten Qualitätsziele und Wirtschaftlichkeitsziele sind in der Machbarkeitsstudie ausgeführt. Alle Ziele sind konform mit den strategischen Vorgaben aus der kantonalen IT Strategie und MBA Informatikstrategie, u.a. Für gleiche Anforderungen eine Informatik-Lösung. Die Harmonisierung der Schulverwaltungslösung aller Schulen der Sekundarstufe II wird schrittweise umgesetzt. Das Projekt IT-Schuladministration orientiert sich an den Anforderungen und Bedürfnissen der Schulen sowie Verwaltungen und Organisationen in unserem Bildungssystem sowie an den verfügbaren personellen und finanziellen Ressourcen. Die IT-Schuladministrationslösung unterstützt die Schulverwaltungen in einem professionell geleiteten Schulbetrieb im Bereich Administration und Organisation. Die IT-Schuladministrationslösung unterstützt die Schulverwaltungen in der selbstständigen und kostenbewussten Leitung der Schulen. 1 Die Quelle der zugrunde liegenden Grafik: basiert auf

7 Seite 7/ Systemziele Die Systemziele sind in Tabelle 1 zusammengefasst. ID Systemziele Messkriterien 1 Datenhaltung und hoheit Die IT-Schuladministrationslösung verwaltet zentral und sicher schulrelevante Daten (ausser unterrichtsbezogene) und hat die Datenhoheit, wo noch nicht andere Systeme bevorzugt definiert sind (d.h. PULS, SAP, KOMPASS, ZAP). Datensicherheit und Datenschutz sind gewährleistet. 2 Nutzung der Lösung Die IT-Schuladministrationslösung ist ein effektives Instrument zur Unterstützung der Schulverwaltung. 100% des noch zu definierenden Minimalkatalogs an relevanten Daten und Unterlagen sind im System abgelegt. 100% Datenhoheit für die Schulverwaltungsrelevanten Daten (ausgenommen PULS, SAP, KOMPASS, ZAP) Kantonale Standards bzgl. Datensicherheit und Datenschutz sind eingehalten. 100% der wichtigen 2 Kern- und Unterstützungsprozesse und 100% der wesentlichen 3 Leistungen der Schulverwaltung sind unterstützt. Prozessqualität ist erhöht (u.a. Effizienz, Vereinfachung und Standardisierung). Die Integration in die Systemumgebung ist verbessert indem die Anzahl Medienbrüche reduziert wurde. 3 Standardisierung Mittelschulen und Berufsfachschulen arbeiten auf derselben Systembasis. 4 Spezialisierung Die Lösung ist auf die speziellen Bedürfnisse der Mittelschulen und Berufsfachschulen zugeschnitten. 5 Mehrwert und Strategiekonformität Die IT-Schuladministrations Lösung ist a. Einfach in der Benutzung (Usability) b. modern (state-of-the-art Technologie) c. einfach erweiterbar (z.b. modularer Aufbau, offene Schnittstellen) d. zuverlässig e. ortsunabhängig nutzbar f. eingefügt in die bestehende kantonale IT Strategie. Die neue Schuladministrationslösung für Mittel- und Berufsfachschulen im Kanton Zürich basiert auf dem gleichen Softwareprodukt und hat eine einheitliche Basiskonfiguration. Die Parametrisierung kann unterschiedlich sein. 100% der schultypenspezifischen MUSS Anforderungen sind umgesetzt. a. Usability wird seitens Anwender als «gut» 4 bewertet. b. Technologie wird seitens einer IT Fachstelle (z. B. KITT) als «zeitgemäss» beurteilt. c. Erweiterungen sind mit vertretbaren Aufwand umsetzbar d. Hohe Betriebsbereitschaft und Verfügbarkeit e. Ortsunabhängiger Zugriff mit verschiedenen Endgeräten ist möglich. f. Strategiekonformität durch KITT in der Phase Konzept bestätigt. 6 Betrieb Weniger Aufwand im Betrieb seitens 2 schätzungsweise ca. 80% aller Prozesse der Schulverwaltung 3 schätzungsweise ca. 80% aller Leistungen der Schulverwaltung 4 Skala: sehr gut, gut, ausreichend, nicht genügend

8 Seite 8/23 ID Systemziele Messkriterien Der effiziente IT Betrieb der Lösung mit zentralem Support und Unterhalt ist sichergestellt. Tabelle 1: Systemziele des Projektes IT-Schuladministration Projektziele Als Projektziele sind die in Tabelle 2 zusammengefassten Ziele zu erreichen. ID Projektziele Messkriterium Schuladministration auf Seiten MBA und Schulen bei gutem und schnellem Support. Definierte Verantwortlichkeiten für den Betrieb Vereinfachte und standardisierte Betriebsabläufe. Antwortzeit Support mindestens so wie heute. 1 Zufriedene und geschulte Anwender Bewertung der Lösung und Schulung durch die Anwender ist «gut» 5 2 Muss-Anforderungen sind von Anfang an abgedeckt 3 Kurze Einführungszeit und reibungslose Umstellung Tabelle 2: Projektziele des Projektes IT-Schuladministration 100% der Muss Anforderungen sind im ersten Release umgesetzt. Dauer der Einführungszeit wird von Schulen gutgeheissen. Keine betriebskritischen Incidents während der Einführung Projektabgrenzung Abgrenzung aus fachlicher und prozessualer Sicht Lediglich schulunterrichtsbezogene, inhaltliche Prozesse können als irrelevant für das Projekt IT Schuladministration abgegrenzt werden. In welchem Umfang eine Prozessunterstützung durch die IT-Schuladministrationslösung erforderlich ist, wird in der Konzeptphase geklärt Abgrenzung aus organisatorischer Sicht Die bestehenden Schuladministrationslösungen der BFS und MS werden heute von den Mitarbeitenden der Schulverwaltung genutzt. Tabelle 3 zeigt den zukünftigen Benutzerkreis für die neue IT-Schuladministrationslösung auf. Benutzergruppen Rollen Ziel Schulleitung Rektor / Rektorin, Prorektor / Effiziente Schulverwaltung Prorektorin Administration Sekretariate, Prüfungssekretariat, Effiziente Schulverwaltung Sachbearbeitung Adjunkt/Adjunktin Stunden- & Raumplaner Gebäude und Raumdaten prüfen 5 Skala: sehr gut, gut, ausreichend, nicht genügend

9 Seite 9/23 Benutzergruppen Rollen Ziel Administrator IT Support, Reports, Konzeption von Anpassungen Lehrpersonen, Dozenten Fachbereichsleiter, Klassenlehrer, Fachlehrer Noteneingabe, Absenzen, Auskunft erteilen Personalwesen Personendaten prüfen und verifizieren Rechnungswesen Finanzdaten prüfen und verifizieren Facility Management Hausdienste Parkplatzmanagement Internatzimmerverwaltung Kommissionen Fachkommissionen, Schulkommissionen, Zugang zu Kennzahlen Cockpit Prüfungskommissionen MBA Lernende, Eltern (heute via Intranet) Abfragen (Klassenlisten, Zeugnisse) Tabelle 3: Zukünftiger Benutzerkreis der IT-Schuladministrationslösung Über das Intranet können ausgewählte Inhalte der IT-Schuladministrationslösung indirekt für einen breiteren Kreis an Anspruchsgruppen (z.b. Hausdienst, Schulkommission, Kommissionen) zugänglich gemacht werden Abgrenzung aus systembezogener und technischer Sicht Durch die neue IT-Schuladministrationslösung werden die Systeme Eco Open und die aktuelle Installation des Information Manager (IM) (siehe Abbildung 2, blaue Ellipse) abgelöst. Der IM als Produkt ist bei der Evaluation zugelassen. Die favorisierte Lösungsvariante sieht zudem vor, das bestehende Intranet Sek II zusammen mit der Zentralen Plattform Sek II und der von ihr zur Verfügung gestellten Funktionalität (siehe Abbildung 2 grüne Ellipse) abzulösen. Als irrelevant für die Evaluation der neuen IT-Schuladministrationslösung konnten nur Systeme im direkten Zusammenhang mit dem Schulunterricht (inhaltlich) klassifiziert werden.

10 Seite 10/23 Mediothekslösung DMS Raumbewirtschaftung Allg. Ressourcenbew. SAP (xpert.line) inkl. KoRe Stundenplan-SW - Untis... CRM Schlüsselverwaltung Bista / Statistik Eco Open IM PK-Org. (etc.) Tramuda MFP-Abrechnung System Kompass 2 / Kompass 3 Personalprozesse Intranet Sek II LMS - Moodle - Educa2 - Olat... PulsZH Absenzen, Persönliche Dateiablage (File) Maturaarbeiten, Noteneingabe Freifach etc. Anmeldungen, Legidruck, etc. Zentrale Authentisierung (Identity Provider) - Mail & Kommunikationsplattform Zentrale Plattform Sek II Info-BS ZAP Für Lernende + Experten Anrechnungs- & Validierungsverfahren Systemkontext Inventar (Axeba) Homepages der Schulen (Kursausschreibung etc.) Unterricht Abbildung 2: Relevante Systeme im Projektkontext Irrelevante Umgebung Lösungsvarianten und Soll-Architektur Grundsätze Die Grundsätze in Tabelle 4 wurden im Projekt erarbeitet und bilden die Basis für die Lösungssuche für die IT-Schuladministrationslösung. ID Grundsätze 1 Ein führendes System für die Schulverwaltung: Es werden alle relevanten Daten und Unterlagen der Schulverwaltung in der IT Schuladministrationslösung abgelegt, sofern diese noch nicht in anderen führenden Systemen abgelegt sind. Die Beurteilung der Relevanz ist in einer Regelung festgelegt. Das MBA gibt einen Minimalkatalog vor. Damit ist die IT-Schuladministrationslösung das führende System für die Schulverwaltung, nach dessen Informationsbestand sich andere Systeme im Systemverbund richten. Neben der IT-Schuladministrationslösung bestehen weitere führende Systeme. Diese sind PULS, SAP, KOMPASS, ZAP. 2 Digitales Medium: Die Schuladministration erfolgt elektronisch. Die Dokumente müssen primär elektronisch geführt werden. Archivwürdige Dokumente werden dem Schularchiv übergeben. 3 Die Schuladministration (Organisation Rollen / Strukturen, Abläufe, Inhalte) erfolgt aufgrund verbindlicher Regeln die gültig sind für die Zielgruppe. 4 Der Owner von der Lösung in der Projektphase ist das MBA. Die Lösung wird an allen Schulen der Zielgruppe eingesetzt. 5 Offene Informationskultur: Im System ist ein grundlegendes rollenbasiertes Zugriffsschema definiert. Über dieses können alle berechtigten Personen - abhängig von

11 Seite 11/23 ID Grundsätze ihrer Rolle - auf das System zugreifen. Die Zugriffsrechte werden eingeschränkt im Falle von datenschutzrelevanten Dokumenten/Daten oder aus Gründen der Vertraulichkeit. Die Festlegung der Zugriffsberechtigungen erfolgt durch das MBA in Absprache mit den Schulen. 6 Grundzüge der angestrebten Lösung sind Flexibilität (Erweiterbarkeit z.b. vom Datenmodell, Prozessen, verschiedene Einstiegsmöglichkeiten), Offenheit (Admin hat breites Funktionsspektrum und Customizing Möglichkeiten, es kann auf verschiedenen Ebenen auf die Daten zugegriffen werden) und Einfachheit (Übersicht und Anwendung) 7 Verschiedene Sichten auf die Lösung werden unterstützt (z.b. Admin, BFS User, MS User, Weiterbildungs User). 8 Standardisierung: Eine Lösung (gemeinsamer Kern/Basis) für die gesamte Zielgruppe. 9 Die Lösung unterstützt die identifizierten Kern- und Unterstützungsprozesse gesamthaft. 10 Die Lösung muss von der Informatikabteilung des MBA betrieben werden können. Dies schliesst ein externes Housing der Infrastruktur nicht aus. 11 Der (spätere) Betrieb der Lösung wird den Leistungsbezügern durch das MBA in Rechnung gestellt auf der Basis eines transparenten Kosten- und Verrechnungsmodells. Tabelle 4: Grundsätze als Basis der Lösungssuche 4.2 Soll-Architektur Die Soll Architektur ist für alle nachfolgend skizzierten Lösungsvarianten gültig. Aus den Lösungsvarianten heraus ergeben sich lediglich Unterschiede betreffend der folgenden Fragestellungen Für welche Nutzergruppen muss die Benutzeroberfläche und damit auch die Sicherheit bzw. Governance Komponenten der Lösung ausgelegt sein? Benötigt es zukünftig eine Schnittstelle zur bestehenden zentralen Plattform Sek2 oder wird das System und seine gesamte Umgebung mit der neuen IT- Schuladministrationslösung abgelöst? Eine Übersicht der Soll-Architektur für die IT-Schuladministrationslösung ist in Abbildung 3 gezeigt

12 Seite 12/23 Benutzeroberfläche / Client Arbeitsstationen Zugriff über verschiedene Endgeräte (Arbeitsstationen, Telefon, Pads) Schnittstellen SAP KOMPASS IT-Schuladministration Sicherheit / Governance Prozesse Ausbildungs- & Veranstaltungsplanung Zulassungs- / Aufnahmeverfahren & Eintritt Semesterplanung / Semesterwechsel Reporting PULS ZAP Intranet Sek II Import / Export Schnittstelle für spezielle Bedürfnisse Semesterbetrieb Business Regeln Qualifikationsverfahren / BM, Maturaprüfungen durchführen Semesterabschluss Promotionsordnungen Gesetzliche Vorgaben Notenberechnungen Datenstrukturen Lernender Notenstrukturen Zeugnisstrukturen Zugriffskontrolle / Autorisierung Authentifizierung Basis Datenbanken Betriebssystem Abbildung 3: Soll-Architektur IT-Schuladministrationslösung Sie besteht aus folgenden Elementen bzw. Schichten: Benutzeroberfläche / Client (Präsentationsschicht) - In der Präsentationsschicht wird das Aussehen der Benutzeroberfläche mitsamt dem interaktiven Verhalten der Anwendung (Datenausgabe und Dialogführung) implementiert. - Die Benutzung der IT Schuladministrationslösung über verschiedene Endgeräte muss gewährleistet sein. IT Schuladministration (Anwendungsschicht) - In der Anwendungsschicht ist die Business Logik enthalten. Diese beinhaltet die Abbildung der Geschäftsprozesse (Business Workflows) mitsamt seiner Tätigkeiten in der richtigen Reihenfolge und den benötigten Daten, und die zugrundeliegenden Funktionen und Regeln. Schnittstellen (Integrationsschicht) - In der Integrationsschicht ist diejenige Logik angesiedelt, mit der auf Daten und Funktionen in anderen Systemen zugegriffen wird. Basis (Datenhaltungs- und Service-Schicht) - Die Datenhaltungsschicht ist für die Datenspeicherung zuständig. Für die Nutzung der Daten ist es unerheblich wie der Datenzugriff erfolgt.

13 Seite 13/ Sicherheit (Governance) - Alle Sicherheits-Komponenten sollen auf allen logischen Schichten der Architektur genutzt werden können. - Speziell Authentifizierung und Autorisierung können und sollten zur Kontrolle des Zugriffs von Nutzern im ganzen System und auf allen Ebenen genutzt werden. o o Lösungsvarianten Bei der Authentifizierung werden User Zugangsdaten (z.b.: Username / Passwort etc.) überprüft und einem Nutzer zugeordnet, also eine Identität zugeordnet (identifiziert). Dies kann und muss an verschiedenen Stellen geschehen (z.b. Client, Datenbank). Wichtig ist die sichere Weiterleitung von Identitäten, um mehrfache Authentifizierungen zu vermeiden. Bei der Autorisierung geht es darum, identifizierten Nutzern (mit bekannter Identität) selektiv Zugang zu Funktionalitäten von IT- Systemen zu gewähren. Oft verwendet man User, Usergruppen, Rollen auf User- oder Usergruppenebene und die Zuordnung von Rollen zu Rechten. Anhand bewährter, kreativer Methoden wurden systematisch Lösungsmöglichkeiten konstruiert und damit der mögliche Lösungsraum ermittelt und die vier in Tabelle skizzierten Lösungsvarianten abgeleitet. Eine detaillierte Beschreibung der Lösungsvarianten und Abwägung der Vor- und Nachteile ist der referenzierten Machbarkeitsstudie zu entnehmen. Nr. Dimension Variante 1 Nur BFS Lösungsvarianten Variante 2 BFS + MS Minimal Variante 3a BFS + MS Ohne Ablösung Intranet Sek II/ Zentrale Plattform Sek II Variante 3b BFS + MS + mit Ablösung Intranet Sek II / Zentrale Plattform Sek II 1 Zielgruppe BFS BFS +MS BFS + MS BFS + MS 2 Abzulösende Systeme 5 Direkte Anbindung von Umsystemen Eco open Standardschnitt stellen und Zusatzentwicklu ng für wichtige Systeme Tabelle 5: Identifizierte Lösungsvarianten Eco open und IM Ausser Standard- Schnittstellen keine Eco open und IM Standardschnitt stellen und Zusatzentwicklu ng für wichtige Systeme Eco open / IM + Intranet Sek II / Zentrale Plattform Sek II Standardschnitt stellen und Zusatzentwicklu ng für wichtige Systeme Empfehlung: Aus Sicht Projektleitungsteam ist Variante 3b die favorisierte Lösung und konform mit Vision und Zielen. Die Lösungvariante erlaubt nach einer umfassenden Lösung zu suchen und den Markt bestmöglich nach einer geeigneten Lösung zu prüfen um den Nutzen für die Anspruchsgruppen umfassend zu erschliessen. Falls keine Lösung auf dem Markt die Gesamtheit der Anforderungen erfüllt, steht mit Lösungsvariante 3a eine Fallback-Lösung

14 Seite 14/23 bereit und mit Lösungsvariante 1 eine Notlösung nur für die Berufsfachschulen. Der erhöhte Ressourcenbedarf seitens MBA ist frühzeitig zu berücksichtigen. 4.4 Grundidee Lösungsaufbau Um der Vielfalt von Anforderungen zu entsprechen, wird der in Abbildung 4 skizzierte Lösungsaufbau vorgeschlagen. Anforderungskatalog «Basis-Konfiguration» Anforderungskatalog «BFS spezifisch» Anforderungskatalog «Schule xy spezifisch» Anforderungskatalog «Schultyp spezifisch» Anforderungskatalog «MS spezifisch» Funktionalität schulspezifisch Funktionalität Schultyp spezifisch (z.b. WB, GB, FMS, HMS) Funktionalität BFS spezifisch Funktionalität MS spezifisch Funktionalität out of the box 60% Implementierte Anforderungen Funktionalität «Basiskonfiguration» Abbildung 4: Vorschlag für Lösungsaufbau Durch den skizzierten Lösungsaufbau (siehe Abbildung 4) werden folgende Vorteile erreicht Für die Schulen Erprobtes Vorgehen mit verwendbaren Basiskonfiguration insbesondere auch auf organisatorischer Ebene Rasche Einführung der Basiskonfiguration und schultypenspezifischen Erweiterungen Einfach kalkulierbare Kosten im Betrieb Für den Kanton Kantonsweit harmonisierter Release mit koordinierter Weiterentwicklung Zentrale Datenhaltung 4.5 Bevorzugte Betriebs- / Service Modelle Obwohl die beiden Betriebs- / Service-Modelle SaaS und IaaS unter anderem aus finanziellen Aspekten überzeugen können, werden diese aufgrund der zu hinterfragenden Datenspeicherung beim Anbieter und der Abhängigkeit zu demselben nicht empfohlen. Dies begründet sich insbesondere darin, weil in einer Schulverwaltungslösung besonders schützenswerte Personendaten (u.a. AHV-Nr., Lohndaten, Noten) abgelegt werden, welche nur von hierzu berechtigten Stellen eingesehen und bearbeitet werden dürfen. Des

15 Seite 15/23 Weiteren wird beim Modell SaaS die gewünschte Flexibilität hinsichtlich Anpassbarkeit und Parametriesbarkeit nicht unterstützt. Aus soeben erwähnten Gründen werden nur Betriebs- / Service-Modell bevorzugt, welche den erwähnten Ansprüchen gerecht werden und die entsprechenden Risiken minimal sind. Die übrig bleibenden Betriebs- / Service-Modelle ASP, Serverhousing und In-Housing erfüllen diese Anforderungen weitestgehend und werden für die zukünftig zu betreibende Lösung in der engeren Variantenwahl mitberücksichtigt.

16 Seite 16/23 5. Organisation Für die anstehende Phase Konzeption mit den Ablaufschritten Grobkonzept und Submission/Evaluation ist die in Abbildung 5 skizzierte Projektorganisation vorgesehen. Projektcontrolling (PC) Robert Welle, prolan systems ag (extern) Auftraggeber (PAG) Marc Kummer Stv. Martin Egger (VAG) Projektausschuss (PA) Marc Kummer, MBA (Vorsitz) Martin Egger, MBA Niklaus Schatzmann, KFR Otto Schlosser, BFSU Markus aus der Au, BBW Christine Schüpbach Ringli, KZO Werner Stauffacher, BI Peter Schreiber, BI Roman Büchler, BSG (extern) Projektunterstützung Karin Fischer, APP (extern) Reto Wagner, APP (extern) Rüdiger Vietze, APP (extern) Co-Projektleitung Mirjam Lehmann, MBA Daniel Stucki, MBA Teilprojektleitung Unterstützungsprozesse Schuladministration Natascia Tuttobene Andreas Corazza (Stv.) Projektkernteam Teilprojektleitung Kernprozesse Schuladministration Michèle Steiner Daniel Stucki Teilprojektleitung IT Integration Mirjam Lehmann Hansruedi Sommer Team Unterstützungsprozesse Thomas Oechslin, MBA Hannes Schneeberger, MBA Team Kernprozesse Walter Feuchter, BBW Martin Ehrismann, RGZH Team IT Integration Markus Dubach, MBA, Technik Projektteam BMZ Stephan Meyer Annemarie Maag BFSU Claudia Riklin Angela Amato KVZ Matthias Grimm KZU Isabel Zollinger MNG Werner Büchi KSL Harald Pierhöfer BBW Walter Feuchter Hans Jörg Humm Esther Bürgin BSR Kurt Eisenbart Corinne Fankhauser WSKVW Daniela Naef Bürgi Jacqueline Hanselmann KGL Patrick Ehrismann Weitere Nominierungen pendent KZO Thomas Stecher ZAG Maya Nigg Carole Raschle Strickhof Brigitte Meier Annick Schiller KVW Stefanie Künzler BBZ Sladjana Filipovic Katja Burkhard TBZ Beat Hartmann Denise Wagner Martina Capaul Benutzervertreter Mittelschulen Benutzervertreter Berufsfachschulen Erweitertes Projektteam Abbildung 5: Projektorganisation für die Phase Konzeption mit den Ablaufschritten Grobkonzept und Submission/Evaluation

17 Seite 17/23 6. Termine und Meilensteine Tabelle 5 zeigt die geplanten Termine und Meilensteine. MS- Nr. Meilensteinname / Beschreibung Termin geplant 6 Termin angepasst M1 Projektbewilligung M1.1 Grobkonzept M1.2 Submission / Evaluation M2 Konzeptabnahme M3.1 Detailspezifikationsabnahme Pilot M3.2 Detailspezifikationsabnahme Gesamt M4.1 Technische Abnahme Pilot M4.2 Technische Abnahme Gesamt M5.1 Systemabnahme BFS In Abklärung M5.2 Systemabnahme MS In Abklärung M6 Projektabschluss Tabelle 5: Geplante Meilensteine und Termine Termin effektiv Erfüllungsgr ad % Die geplanten Termine stammen aus dem Projekt-Initialisierungsauftrag, welcher am 7. April 2014 genehmigt wurde. Zu diesem Zeitpunkt wurde noch vom Projekt Ablösung Eco open gesprochen. Durch die Ausweitung des Projekts auf die gesamte Sekundarstufe 2 wurde eine Anpassung erforderlich. Damit genügend Zeit für die Erhebung der Anforderungen zur Verfügung steht, wurde der Termin für die Submission/Evaluation in Apsprache mit dem Projektausschuss um ein Jahr nach hinten geschoben. Der Termin für den Projektabschluss wurde um drei Jahre nach hinten geschoben, da ein Rollout bei 40 Schulen realistischerweise mehrere Jahre dauert. 6 Gemäss Projektinitialauftrag SAL Sek2 vom

18 Seite 18/23 7. Kapazitätsplan Tabelle 6 zeigt den benötigten Ressourcenbedarf für das Gesamtprojekt.

19 Seite 19/23 Projekt IT-Schuladministration Enthalten: - Projektkosten: Geschätzte Personalaufwände seitens MBA, Schulen und extern Nicht enthalten: - Lizenzen, Software, Hardware, Material, - Kosten für Betrieb, Wartung, Support, Weiterentwicklung,.. Phase # Monate Kommentar Aufwand (PT) TOTAL MBA Schulen extern Initialisierung Initialisierung 4 Aug-Nov Subtotal Aufwände (PT) Subtotal Kosten Fr. 80'000 Fr. 50'000 Fr. 70'000 Fr. 200'000 Subtotal Durchlaufzeit 4 Konzeption Grobkonzept 6 Dez 14 - Mai Pflichtenheft 5 Jun 15 - Okt Evaluation / Submission 5 Nov 16 - Mrz Abschluss Konzeption und Genehmigung 1 Apr Subtotal Aufwände (PT) Subtotal Kosten Fr. 350'000 Fr. 140'000 Fr. 210'000 Fr. 700'000 Subtotal Durchlaufzeit 17 Detailspezifikation MS + BFS Start Realisierung Detailplanung Spezifikation Funktionen und Prozesse Organisatorisches Detailkonzept, Detailkonzept Funktionen + Prozesse, Detailkonzept Systembetrieb Spezifikation Datenlogistik Datenorganisation, logisches Datenmodell, Datenbankdesign 0.5 Mai Feb - Apr Mai - Juni Spezifikation Technik 4 Jul 16 - Okt Detailkonzepte erstellen für Systemarchitektur, Datenübernahme und - konversion, Datenschutz, Datensicherheit, Standard SW Anpassungen, HWund SW Konfiguration, Sachmittel für Fachbereich, Test, Schulung, Installations und Rolloutplanung Abschluss Spezifikation 0.5 Nov Subtotal Aufwände Subtotal Kosten Fr. 420'000 Fr. 390'000 Fr. 460'000 Fr. 1'300'000 Subtotal Durchlaufzeit 10 Hinweis: Durch Parallisierung von Aktivitäten kann Durchlaufzeit auf 7-8 Monate gekürzt werden Umsetzung Entwicklung 3 Jan 16 - Mrz Systemdokumentation, Programmvorgaben, Datenbank, Softw are, Testplan und Testdaten,Testdokumentation, Jobsteuerung, Betriebshandbuch Rahmenorganisation 2 Apr 17 - Mai Organisationshandbuch, Benutzerhandbuch, Dokumentation Datenübernahme, Einführungsplan und Schulungsprogramm, Projektplanung Testen Technik und Anwendung Testdokumentation,Mängelliste und Abnahmeprotokoll 3 Jun 17 - Aug Subtotal Aufwände (PT) Subtotal Kosten Fr. 270'000 Fr. 2'160'000 Fr. 580'000 Fr. 3'000'000 Subtotal Durchlaufzeit 8 Durch Parallisierung von Aktivitäten kann Durchlaufzeit auf 6-7 Monate gekürzt werden Einführung Systemabnahme 1 fortlaufend ab Testdokumentation, Leistungsvereinbarung, Wartungsvertrag, Mängelliste Sep 17 Praxisbetrieb Schulungen, Projektabschluss Subtotal Aufwände (PT) Subtotal Kosten Fr. 190'000 Fr. 1'000'000 Fr. 670'000 Fr. 1'900'000 Subtotal Durchlaufzeit 2 Achtung: Durchlaufzeit nur pro Schule Subtotal Durchlaufzeit 36 alle Schulen (Annahme: es werden jeweils zwei bis drei Schulen gleichzeitig eingeführt) Betriebaufnahme Betrieb / Wartung 1 fortlaufend ab Mängelliste, Rückbau altes System, Wartungsverträge Nov 17 Change Management Änderungsanträge Subtotal Aufwände Subtotal Kosten Fr. 120'000 Fr. 250'000 Fr. 180'000 Fr. 550'000 Subtotal Durchlaufzeit 3 TOTAL Nettoaufwände (PT) TOTAL Kosten Fr. 1'400'000 Fr. 4'000'000 Fr. 2'200'000 Fr. 7'700'000 TOTAL Durchlaufzeit 78 TOTAL Bruttoaufwände (Nettoaufwände / 0.9) TOTAL Kosten inkl. Risikozuschlag (intern: 1.15, extern: 1.3) Fr. 1'800'000 Fr. 5'100'000 Fr. 3'130'000 Fr. 10'000'000 Tabelle 6: Ressourcenbedarf für das Gesamtprojekt

20 Seite 20/23 8. Kosten- und Budgetplan Gesamtkostenplan (gemäss Basis Kosten- / Nutzenanalyse) Investitionen 2014 / TOTAL Kommentar Externer Aufwand Honorare (APP, mit Phase Fr. 400'000 Fr. 660'000 Fr. 960'000 Fr. 370'000 Fr. 370'000 Fr. 370'000 Fr. 3'130'000 Anbieter) Initialisierung HW / Betriebs-SW (inkl. Einmallizenzen) Applikationssoftware (inkl. Einmallizenzen) Fr. 1'000'000 Fr. 1'000'000 Interner Aufwand mit Phase MBA Fr. 550'000 Fr. 540'000 Fr. 380'000 Fr. 120'000 Fr. 120'000 Fr. 120'000 Fr. 1'800'000 Initialisierung mit Phase Schulen Fr. 240'000 Fr. 500'000 Fr. 2'900'000 Fr. 480'000 Fr. 480'000 Fr. 480'000 Fr. 5'100'000 Initialisierung Betriebsausgaben Wiederkehrende Lizenzen / Wartung 5 Jahre Betrieb Fr. 200'000 Fr. 200'000 Fr. 200'000 Fr. 200'000 Fr. 200'000 Fr. 1'000'000 berücksichtigt Andere Betriebskosten Interne Verrechnung Summe Ausgaben Fr. 1'200'000 Fr. 1'700'000 Fr. 5'400'000 Fr. 1'200'000 Fr. 1'200'000 Fr. 1'200'000 Fr. 200'000 Fr. 12'000' Tabelle 7: Übersicht geschätzte Projektkosten (einschliesslich 5 Jahre Wartung) 9. Wirtschaftlichkeit Mit den nachfolgenden Ausführungen wird der qualititive Nutzen der neuen IT- Schuladministrationslösung grob aufgezeigt. Der quantitative Nutzen wird im Rahmen des Grobkonzepts betrachtet. Der qualitative Nutzen ergibt sich aus: Für die Berufsfachschulen ist die Suche nach einer IT-Schuladministrationslösung zwingend. Nur durch die Evaluation einer neuen Lösung kann die Kontinuität des professionell geleiteten Schulbetriebs im Bereich Administration und Organisation mittelfristig sichergestellt werden. Für die Mittelschulen, die heute mit dem IM eine gut funktionierende und akzeptierte Lösung im Einsatz haben, ist der qualitative Nutzen nicht kurzfristig, sondern eher mittelfristig zu erwarten. Sie werden davon profitieren, dass sie sobald sie dafür bereit sind, auf eine alternative, zeitgemässe Lösung wechseln können, die die Grundbedürfnisse der MS bereits erfüllt. Durch die Harmonisierung der BFS und MS Lösungen wird erwartet, dass Betriebsaufwand auch auf Seiten Schulen gesenkt und der Support für die Lösung verbessert werden kann. Zudem werden für die Zielgruppe Effizienzsteigerungen durch optimierte Prozesse, eine verbesserte Systemintegration, eine zentrale Datenhaltung, den Abbau von Medienbrüchen und Doppelspurigkeiten erwartet. Qualitätssteigerungen in den Arbeitsabläufen werden auch in Hinsicht auf eine selbständigere Arbeitsweise und eine verbesserte Benutzbarkeit erreicht werden können.

21 Tragweite Risikopotential Wahrscheinlichkeit Risikopotential Tragweite Risikopotential Wahrscheinlichkeit Wahrscheinlichkeit 7 Mittelschul- und Berufsbildungsamt Seite 21/ Nr. Risiken Risiken betreffend personellen Projektressourcen Beschreibung / Auswirkung des Risikos AR01 Verfügbarkeit der Mitarbeiter MBA: Nichtverfügbarkeit der MBA Mitarbeiter für die Projektarbeit (Projektleitung, Teilprojektleitung, Teilprojektmitarbeitende, Fachverantwortliche etc.) AR02 Verfügbarkeit der Mitarbeiter Schulen BFS: Nichtverfügbarkeit der Mitarbeiter der Schulen BFS für die Projektarbeit. AR03 Verfügbarkeit der Mitarbeiter Schulen MS: Nichtverfügbarkeit der Mitarbeiter der Schulen MS für die Projektarbeit. AR04 Ungenügende Erfahrung der MBA Mitarbeiter mit ähnlichen Projekten AR05 Fehlende Einbindung aller Anspruchsgruppen AR06 Einführung neue Projektmitarbeitende ist ungenügend Tragweite Nr. Beschaffungsspezifische Abwicklungsrisiken Beschreibung / Auswirkung des Risikos AR07 Keine oder zu wenige oder zu schlechte Offerten AR08 Zu viele Offerten (>10) AR09 Gute Offerte, aber Produkt/Anbieter stellt sich nach dem Zuschlag als falsch heraus AR10 Rekurs Nr. Weitere Abwicklungsrisiken Beschreibung / Auswirkung des Risikos AR10 Projekt wird innerhalb der Linie (Führung) nicht ausreichend unterstützt AR11 Ungenügende Kommunikation innerhalb des Projektes (Team und Anwendervertreter) AR12 Umfang ist ungenügend abgesteckt = gering,<10%, 2 = mittel, 10 bis 50%, 3 = hoch, >50% 8 1 = gering, 2 = mittel, 3 = hoch

22 Tragweite Risikopotential Wahrscheinlichkeit Risikopotential Tragweite Wahrscheinlichkeit Mittelschul- und Berufsbildungsamt Seite 22/23 Nr. Beschreibung / Auswirkung des Risikos AR13 Die Kosten für die Durchführung des Projektes werden nicht verfügt. Der Beschaffung einer neuen IT Schuladministrationslösung wird seitens der Regierung nicht zugestimmt. AR14 Terminplan ist nicht eingehalten: Für die Durchführung der Phase Konzept wird mehr Zeit als geplant benötigt AR15 Kosten sind nicht eingehalten: Für die Durchführung der Phase Konzept wird mehr Aufwand für die externe Unterstützung als geplant benötigt AR16 Abhängigkeiten zu anderen Projekten ist ungenügend berücksichtigt Nr. Risiken der Lösung (LR) Beschreibung / Auswirkung des Risikos LR01 Systemanforderungen sind zu unspezifisch definiert LR02 Systemanforderungen sind zu detailliert definiert LR03 Ungenügende Konsensfindung BFS und MS bzgl Anforderungen an die neue Lösung LR04 Unterschätzter Anpassungsbedarf um Umsysteme anzuschliessen LR05 Unterschätzter Aufwand für die Datenbereinigung und Migration ins neue System LR06 Akzeptanzprobleme bei Endbenutzern LR07 Lösung entspricht nicht den allgemeinen Rahmenbedingungen des KITT und IK-SekII LR08 Kritische Anforderungen können nur mit viel Aufwand in der Lösung umgesetzt werden

23 Seite 23/ Entscheide Stellungnahme durch den Projektauftraggeber Genehmigt Abgelehnt Auflagen / Hinweise Begründung 12.1 Datum, Unterschriften Unterschrift (Auftraggeber/in, Projektauftraggeber/in) Name Datum, Unterschrift (Projektleiter/in) Name Datum, Unterschrift (Linienvorgesetzte/r) Name