Betriebliche Informatik zur Jahrtausendwende
Betriebsorganisatorisches
Übungsbeispiel zum Thema
„Ablauforganisation und
Mitarbeitermotivation“
HTL für Organisation und
Datenverarbeitung / Leonding
Mayer Otto, 3AAD 1999/2000
Version 3. Dez. 1999, 10:00 Uhr
Vorwort:
Als Thomas Morus im 16. Jh. von einer neuen nicht-absolutistischen Gesellschaftsform in Form eines Reiseberichts öffentlich träumte (Insel Utopia), weckte er in Menschen Gedanken nach Veränderung. Diese Veränderung wurde letztlich sogar herbeigeführt, jedoch erst Jahrhunderte später; für Morus war es das Ende, er wurde hingerichtet, die Zeit war noch nicht reif dafür.
Erstarrte Strukturen aufzubrechen ist eben ein schwieriges Unterfangen und fordert Opfer. Oftmals bedarf es eines Auslösers, der wachrüttelt, und das festgefahrene Wechselspiel zwischen konservativen und progressiven Kräften wieder mit Dynamik belebt und neue Chancen für Veränderungen bringt.
Die Arbeitswelt ist nach wie vor von einer technischen Betrachtungsweise der Arbeitskraft Mensch durchwoben. Monetäre Bewertungsmodelle abstrahieren nach Menge, Aufwand und Kosten, korrelieren dort mit direktem wirtschaftlichen Nutzen – z. B. Geld (Gewinn) – und bestimmen so unmittelbar betriebswirtschaftliches Handeln. Ein solcher abstrakter Ansatz übergeht mangels Zugänglichkeit das große Umfeld nicht-monetärer Gütekriterien und verfärbt Entscheidungsgrundlagen.
Menschen sind aber keine Maschinen, sie leben, haben Freiheit im Handeln, sind in gewisser Weise abgesichert und haben individuelle Vorstellungen von Arbeit. Es wird dort ein großer Teil von Lebenszeit und Emotionen verlebt und ist für viele ein Bestandteil persönlicher Sinnerfüllung. Betriebliche und persönliche Bedürfnisse einander näher zu bringen, wird zum Mittelpunkt der Arbeitsplatzgestaltung.
Dieser Beitrag betrachtet exemplarisch ein typisches Umfeld im Bereich Informatik als innerbetrieblichen Dienstleister eines Fertigungsbetriebes mittelgroßen Umfangs von hoher Computerabhängigkeit. Dabei werden unter Bedachtnahme auf allgemeine psychologische Verhaltensmuster die vorhandenen Motivatoren beleuchtet und ggf. ablauforganisatorisch angepaßt. Das Ergebnis ist eine umfassende Beschreibung einer hypothetischen Ablauforganisation und soll als Denkanstoß dienen.
Inhaltsverzeichnis:
1 Betriebsorganisatorische Aufgabenstellung................................ 3
2 Motivation.................................................................................................................... 3
2.1 Exemplarische Demotivatoren................................................................................................................................. 3
2.2 Exemplarische Motivatoren...................................................................................................................................... 6
3 Aufbauorganisation............................................................................................. 7
3.1 Abteilungsbereiche.................................................................................................................................................... 7
3.2 Stellen.......................................................................................................................................................................... 7
3.2.1 Fachabteilung (Informatikkunden).................................................................................................................. 7
3.2.2 LeiterIn des Bereichs Informatik und
Organisation...................................................................................... 8
3.2.3 ProjektleiterIn..................................................................................................................................................... 8
3.2.4 OrganisatorIn..................................................................................................................................................... 8
3.2.5 LeiterIn, MitarbeiterIn der Abteilung
Systemtechnik.................................................................................. 8
3.2.6 LeiterIn, MitarbeiterIn der Abteilung
Benutzerservice................................................................................ 8
3.2.7 EntwicklungskoordinatorIn (Leitung
Programmierung).............................................................................. 9
3.2.8 SoftwareentwicklerIn......................................................................................................................................... 9
4 Ablauforganisation für informatische
Anforderungen........ 10
4.1 Fachabteilungsbereiche.......................................................................................................................................... 10
4.1.1 Geschäftsfälle mit Bedeutung für den
Informatikbereich.......................................................................... 10
4.1.2 Beurteilung der
Kommunikationsschnittstellen.......................................................................................... 11
4.2 Leitung EDV und Organisation............................................................................................................................ 11
4.2.1 Koordinative Geschäftsfälle (Auszug)......................................................................................................... 11
4.2.2 Bewertung der
Kommunikationsschnittstelle............................................................................................. 11
4.3 EDV-OrganisatorInnen für Linienaufgaben
und Projektmanagement......................................................... 12
4.3.1 Geschäftsfälle................................................................................................................................................... 12
4.3.2 Beurteilung der
Kommunikationsschnittstellen.......................................................................................... 14
4.4 Bereich Softwareentwicklung............................................................................................................................... 15
4.4.1 Geschäftsfälle................................................................................................................................................... 15
4.4.2 Beurteilung der
Kommunikationsschnittstellen.......................................................................................... 19
4.5 Bereich Systemtechnik.......................................................................................................................................... 19
4.6 Bereich Benutzerservice....................................................................................................................................... 19
5 Zusammenfassung................................................................................................ 19
1 Anhang......................................................................................................................... 20
1.1 Grundlagen und Entwicklung der
Motivationslehre......................................................................................... 20
1.1.1 Human-Ressource-Modell............................................................................................................................. 20
1.1.2 Harzburger Führungskonzept........................................................................................................................ 21
1.1.3 St. Gallener Führungsmodell.......................................................................................................................... 21
1 Betriebsorganisatorische Aufgabenstellung
Die Informatikabteilung eines technischen Fertigungsbetriebs dient der Aufrechterhaltung des Rechnerbetriebs (System, Netzwerk, Software), Datenbank- und Benutzerbetreuung sowie der Softwareentwicklung. An die Inhaber der Stellen dieses Bereichs werden hohe Anfordernungen gestellt, Einarbeitungszeiten dafür belaufen sich auf mehrere Monate und erfordern risikobehaftete Kostenaufwände für Schulungen. Gleichzeitig besteht im Informatikbereich ein Arbeitskräftemangel und im Zuge dessen eine hohes Maß an Personalfluktuation durch Abwerbeversuche von außen.
Zur Abdeckung der Bedarfe an EDV-Leistungen für die Routine und Projekte soll eine Organisationsform erarbeitet werden, die neben einer hohen Produktivität auch ausreichend Motive zur Selbstidentifikation der Informatik-Mitarbeiter enthält und somit Fluktuationstendenzen entgegenwirkt.
Die vorgeschlagenen organisatorischen Maßnahmen sollen in einem vernünftigen Rahmen liegen, hinsichtlich des Effekts glaubwürdig und auch umsetzbar erscheinen.
2 Motivation
Eine Verringerung der Fluktuationsrisiken erfordert angesichts Abwerbetendenzen von außen eine Steigerung der Motivation und Selbstindentifikation von Mitarbeitern. Traditionelle Mittel wie vertraglich erschwerte Dienstauflösungen, Konventionalstrafen, verlorener Abfertigungsanspruch oder auch Gehaltserhöhungen mögen einen gewissen Ansatz in dieser Richtung zwar abfedern, mittelfristig bringt aber eine Anregung und Förderung von Selbstmotivation bessere Ergebnisse.
Es gibt eine Faustregel in der Geschäftswelt, die besagt, daß man jeden verlorenen Kunden mit 10fachem Aufwand wiedergewinnen muß. Daraus leitet sich auch letztlich ab, daß der Kunde „König“ ist. Mit hochqualifizierten Mitarbeitern verhält es sich ähnlich. Im Falle eines Ausscheidens reißen sie ein großes Loch auf, das kurzfristig nicht, oder nur mit hohem Aufwand zu schließen ist. Im Falle einer Realisierung eines Total Quality Managements (TQM) wird im Extremfall sogar der Kollege zum „König“ (= interner Kunde), um über „besserer Qualität“ die Effektivität betrieblicher Einheiten zu steigern. Natürlich kann eine Organisationsmaßnahme nicht verhindern, daß jemand die Firma verlassen möchte. Die persönlichen Bedürfnisse und Ziele sind zu verschieden und mitunter auch nicht mit den betrieblichen in Einklang zu bringen.
Ein motivierter Mitarbeiter stimmt seine Ziele mit denen des Betriebs teilweise ab. Deshalb ist es auch günstig, wenn das Arbeitsumfeld den persönlichen Neigungen entspricht (Stellenbesetzung) und mit der Persönlichkeitsentwicklung mitwächst (Karriereplanung). Neben dieser eher grauen Theorie gibt es noch das tagtäglich Erleben am Arbeitsplatz, das großen Einfluß auf innere Werte wie Zufriedenheit, Wohlbefinden u. s. w. hat.
2.1 Exemplarische Demotivatoren
Nachstehend werden einige Beispiele von Demotivatoren aus der Praxis und ihre möglichen Hintergründe dargestellt.
2.1.1.1 Dauerstreß
Kurzfristige Streßspitzen fordern Körper und Geist und regen zur Leistungssteigerung an. Gemeisterte Aufgabenstellungen festigen auch Zusammengehörigkeitsgefühl von Teammitgliedern.
Mit sukzessiver Übernahme solch außergewöhnlicher Leistungen in die Planvorgabe werden die Reserven zeitlicher und emotionaler Art enger, bis der menschliche Körper auf diesen Zustand zu reagieren beginnt (Kreislaufprobleme, Nervosität, Angst, Magengeschwüre) und in Folge Motivation in Frust umschlägt. Neben chronischen Krankheitsbildern führt ein solcher Dauerzustand zu einem individuell negativen Leitbild als Sackgasse, die auf Mitarbeiter über das Betriebliche hinaus einwirkt.
Das Arbeitspensum bzw. die Qualität sackt unter den Wert bei Normallast ab.
2.1.1.2 Unrealistische Terminzusagen
Termine dienen der zeitliche Koordination von Vorgängen und stellen die Basis einer effizienten Ressourcenplanung dar. Enge Termine lösen Streß aus; Menschen werden veranlaßt, aus sich herauszugehen und ihr Reservepotential zu mobilisieren, sofern ein solches noch vorhanden ist.
Termine entstehen beispielsweise als Ergebnis einer Planungstätigkeit oder aus verbindlichen Vorgaben (Kaufvertrag, Behördentermin), kurzfristiger Marktlage bzw. Wunschvorstellungen einzelner.
Unkoordinierte Terminzusagen lösen eine risikobehaftete Ressourcenplanung aus und folgern mitunter Zeitüberschreitung bis hin zu monetären Verlusten.
Werden Abteilungsbereiche auf Dauer mit mehreren solchen gleichzeitig tangiert, besteht auch kaum die Möglichkeit einer echten Kompensation. Eine scheinbare Lösung ergibt sich über eine gewisse Zeit durch Hinauszögern (Methode „Loch auf, Loch zu“) oder geht auf Kosten von Qualität, oftmals mit Spätfolgen verbunden.
2.1.1.3 Unklare Dringlichkeit
Eigenverantwortliche Tätigkeit benötigt Rahmenbedingungen. Mit steigender Zuständigkeit vermehrt sich der Koordinationsaufwand. Ab einem gewissen Ausmaß, speziell bei abteilungsübergreifenden unkoordinierten Bedarfen, versagen einfache Planungsmethoden. Angesichts eines mißbrauchten Superlativs von Dringlichkeit (dringend, sehr dringend, super dringend, ultra-dringend u. s. w.) ist das wahre Dringende nicht mehr erkennbar.
Bei konkurrenzierender Dringlichkeit ist Ressourcenmangel offensichtlich und es ist bei fehlenden Kompensationsmöglichkeiten zu erwarten, daß das Plansoll nicht erreicht wird, trotz aller Bemühungen. Das so entstehende Dreiecksverhältnis zwischen Planung, Dringlichkeiten und Dienstleister bewirkt für letzteren in jedem Fall: einer der internen Kunden bekommt das benötigte nicht oder in verminderter Qualität („Termin rettender Schnellschuß“).
Vorprogrammierter Unmut unabhängig vom Grad des Geleisteten ist für jeden auf Dauer frustrierend und hat in Zuge von Demotivation einen Leistungs- bzw. Qualitätsrückgang zur Folge.
2.1.1.4 Fehlende Schiedsinstanz bzw. Handlungsregeln
In einer Matrixorganisation mit gleichzeitigen Bedürfnissen aus Linie und Projekt ist ein Kampf um Ressourcen und somit ein Konflikt vorprogrammiert. Bereichsübergreifende Interessen und an sich nicht unmittelbar vereinbare Ziele werden dabei durchaus emotional ausgetragen. Bei nicht klar definiertem überbetrieblichen Interesse wird ein solcher Konflikt in der Hierarchie nach unten getragen, wo er auf Unverständnis stößt und Arbeitsleerläufe und Desorientiertheit von Mitarbeitern verursacht.
2.1.1.5 Unklare Aufgabenstellung
Qualität ist in der Informatik schwer meßbar, eine fehlerfreie Software ist definitionsgemäß nicht möglich, Testaufwände werden so weit getrieben, als sie für die Aufgabenstellung in einem vernünftigen Rahmen stehen.
Qualität von Softwareprodukten entsteht nicht beim Testen, auch nicht beim Programmieren, sondern bei der Planung. Dieser Tatbestand ist bekannt und zentrales Anliegen der Fachrichtung Software-Engineering.
Planerische Schnellschüsse rächen sich in aller Regel und verursachen Verluste an Zeit und Geld, je später sie erkannt werden. Darüber hinaus demotivieren sie Mitarbeiter, die mit solchen Spezifikationen auf halben Wege quasi wieder von vorne anfangen müssen, oder angesichts von Terminzwängen in ein ungeliebtes Flickwerk verfallen und sich dafür auch noch rechtfertigen müssen.
2.1.1.6 Verletzender Umgang mit Fehlern
Fehler passieren bei Mensch und Maschine. Irrtum, Unwissenheit und hohe Komplexizität lassen in der Informatik die Fehlerquellen nicht völlig ausschließen. Sogar Großkonzerne mit wie Microsoft oder SAP haben trotz großer Anstrengungen teilweise massive Probleme mit ihren Produkten.
Jeder gefundene Fehler gehört im EDV-Bereich analysiert um daraus zu lernen. Jeder Zeitaufwand für eine Exekution scheinbarer Verantwortung und Zuständigkeit ist es nicht wert, wenn es dabei nur um Schuldzuweisung oder Freisprechen einzelner geht.
Vielmehr handelt es sich bei Software meist um kollektive Fehler. Sie nisten sich etwa in der Planung ein, überdauern Entwicklung, Test und Freigabe, und verursachen einen Schaden. Jeder Beteiligte hätte die Gelegenheit gehabt, den Schaden zu vermeiden und dort gehört auch der Hebel angesetzt, etwa umfassendes Qualitätsdenken mit sichtbaren Indikatoren wie
Ø klare Festlegungen
Ø umfassende Dokumentation
Ø ausreichende Information für Beteiligte
Ø gelebte Teamarbeit
Ø nachvollziehbare Abnahmetests
Ø ordentliche Versionsgebarung (Änderungsdienst)
2.1.1.7 Verantwortung ohne Befugnis
In modernen Führungmodellen wird neben Aufgaben auch Verantwortung delegiert. Dieses Prinzip gibt Mitarbeitern die Gelegenheit zur Mitgestaltung, der Antrieb zum Handeln, setzt sie aber auch unter Druck.
Wird dieser im Übermaß gesteigert, ist Überforderung die Folge. Der oder die Betroffene wird mangels Befugnis zum isolierten Einzelkämpfer: von „oben“ wird gefordert, nach „unten“ kann praktisch nichts delegiert werden.
Das ständige erfolglose Erbitten von Ressourcen trägt Konflikte nach unten – mit der selben Erfolglosigkeit – und demotiviert gesamte Einheiten. Rechtfertigungen nach „oben“ steigern sich emotional bis zu persönlichen Auseinandersetzungen und vergiften die Zusammenarbeit ganzer Bereiche.
2.1.1.8 Kurzfristige Karriereplanung
Karriereplanung ist etwas Langfristiges und für jeden Mitarbeiter eine durchaus persönliche Angelegenheit. Jeder Mensch trägt auf seine Art so etwas wie eine Vision des eigenen kleinen Werdegangs in sich. Jeder einzelne ist wiederum eingebettet in ein soziales Umfeld bestehend aus Gesellschaft, Familie sowie die Stätte des Schaffens. In solch ein hochkomplexes System wird ein Einzelner praktisch hineingeboren und hat in aller Regel allenfalls die Möglichkeit kleiner Veränderungen durch Entscheidungen an gewissen Schaltpunkten des Lebens.
Berufsentscheidungen bewirken große Veränderungen im Leben eines Einzelnen: man bekommt Geld, kann sich etwas leisten, hat Zeit für sich oder nicht mehr, kann das private Umfeld neigungsbezogen gestalten (oder nicht), kann ein persönliches Ziel erreichen (oder verbaut sich den Weg dorthin) u. v. a. m.
Die Praxis in der Berufswelt berücksichtigt bei der Karriereplanung langfristige persönliche Ziele von Mitarbeitern nur am Rande. Sie werden statt dessen auf akute betriebliche Bedürfnisse ausgerichtet und lösen so in Menschen angesichts eines Karriereangebots als Fremdmotivationsversuch innere Konflikte aus.
Kurzfristig getroffene Entscheidungen erlauben Betroffenen keine ausreichende Werteinschätzung und machen die Sache zu einem Glücksspiel. Eine häufige Folge ist nach kurzer Phase der Euphorie die zu späte Erkenntnis von neigungsbezogenen Nachteilen (z. B. mangelnde Eignung, keine Freude an neuer Tätigkeit) oder Unvereinbarkeiten im Umfeld (Konflikte durch geänderten Lebensstil, sinkende Selbstachtung). Ein solcher Aufstieg entpuppt sich dann als Gegenteil, ein Mitarbeiter wird frustriert bzw. bricht aus.
2.1.1.9 Mangelnde Hilfestellungskapazitäten
Die Informatik ist ein Fachbereich, der für ein professionelles Umsetzen von Aufgabenstellungen ein hohes Maß an Spezialisiertheit notwendig macht. So manche Aufgabe übersteigt die augenblickliche Qualifikation eines Bearbeiters und würde ein Hinzuziehen von versierten Fachkollegen sinnvoll erscheinen lassen.
Wenn alle unter Termindruck stehen ist eine solche Hilfeleistung genauso unwahrscheinlich wie sie selbst eine Betroffener auch kaum geben könnte. Hilferufe enden so oft in Alibihandlungen oder zirkulierenden Verweisen auf sog. „eigentliche Zuständigkeit“. So passieren durch ungewolltes Einzelkämpfertum und unzureichende Qualifikation letztlich Fehler infolge unüberlegten Handelns und schuldige Verursacher ernten auch noch Vorwürfe, etwa warum man sich nicht genauer erkundigt hätte.
2.2 Exemplarische Motivatoren
Es liegt leider in der Natur des Menschen, das weniger gute zuerst zu sehen. In Kontrast dazu seien hier auch mögliche Motivatoren dargestellt, die von Mitarbeitern individuell empfunden werden:
Ø interessante und herausfordernde Aufgabenstellung
Ø zeitgemäße EDV-Ausstattung
Ø gute Zusammenarbeit mit Kollegen (Teamgeist)
Ø fachliches Ansehen im Umfeld
Ø Erreichung von Zielen
Ø Lob durch andere
Ø extrinsische Anreize
Ø Selbstbestätigung
3 Aufbauorganisation
Es besteht im Beispielbetrieb bereits eine hierarchische und historisch gewachsene Aufbauorganisation. Die geltende Unternehmensstrategie beläuft sich in Richtung hoher Individualität und Qualität seitens des Produkts nach Gesichtspunkten höchstmöglicher Wirtschaftlichkeit gefertigt.
Die vorhandene Aufbauorganisation ist nicht Bestandteil von Veränderungen und wird hier für das Verständnis mit Schwerpunkt auf die Softwareentwicklung kurz dargelegt. Auf die Hierarchien wird nicht näher eingegangen.
3.1 Abteilungsbereiche
Es gilt die klassische Bereichsgliederung nach Fertigung, Vertrieb und Verwaltung. Der Bereich Informatik und Organisation ist der Verwaltung unterstellt. Er gliedert sich in die Unterbereiche Benutzerservice, Organisation, Programmierung und Systemtechnik (alphabetische Reihung). Die dort praktizierten Führungsstile sind demokratischer bzw. kooperativer Natur und aufgabenbezogen konzipiert (Management by Exception).
3.2 Stellen
3.2.1 Fachabteilung (Informatikkunden)
Anwender eines EDV-Systems sind im Rahmen der Linienorganisation als Kunden der Informatik anzusehen. Die Bedürfnisse der Fachbereiche sind die Abbildung betrieblicher Abläufe bzw. Geschäftsfälle für eine möglichst reibungslose und risikoarme Abwicklung.
Langfristige Änderungen (z. B. neues Produkt, geänderte Gesetzeslage etc.) werden als Projekte initiiert und über Organisatoren koordiniert. Kurzfristige Problemfälle, etwa SW-Mangel, sind von hoher Priorität und bedürfen einer raschen Behandlung durch Organisatoren.
3.2.2 LeiterIn des Bereichs Informatik und Organisation
Schaffung von Rahmenbedingungen für den Bereich, Erstellung von Planvorgaben, Kontrolle, Bericht an Geschäftsleitung u. v. a. m.
3.2.3 ProjektleiterIn
Formulierung von Projektzielen (Detailausarbeitung, Machbarkeitsanalyse, Projektauftrag)
Projektorganisation (Aufbau, Ablauf, Strukturierung der Projektgruppe)
Projektplanung (Termine, Kosten, Ressourcen, Information)
Projektsteuerung (Koordination, Kommunikation, Entscheidungen etc.)
Projektkontrolle (Wirtschaftlichkeit, Berichterstattung)
Anforderungen und Fähigkeiten: Teamfähigkeit, Durchsetzungsvermögen, hohe Frusttoleranz, vernetztes Denken, Handlungsorientiertheit, Zukunftsorientiertheit, Generalist, ökonomisches Denken
3.2.4 OrganisatorIn
Zuständige Person für Teilbereiche einer Anwendung, etwa Materialwirtschaft, Produktion
Vertreter für die Bedürfnisse aus der Linienorganisation
Ansprechperson für Anwender aus Fachabteilungen
Koordination und Durchführung von Schulungen
Durchführung von Systemeinstellungen
Erarbeitung org. Anweisungen für die Abwicklung von Geschäftsfällen
Dokumentation
Aufrechterhaltung der Datenkonsistenz (Stammdaten)
Planung von Einführung- bzw. Umstellungsprojekten
Koordination, Test und Freigabe von internen bzw. externen Programmierarbeiten
u. v. a. m.
Notwendige Qualifikation: betriebswirtschaftlicher Überblick, allg. Datenbank und u. U. Programmierkenntnisse, Kommunikations- und Präsentationstechnik, Expertenwissen in Anwendungsmodulen.
Einarbeitungszeit: 2 – 4 Monate (subj. Schätzung), Spezialschulungen
3.2.5 LeiterIn, MitarbeiterIn der Abteilung Systemtechnik
Aufrechterhaltung des Rechnerbetriebs (Hardware, Systemsoftware, Datenbank)
Datensicherung
Bereitstellung benötigter Rechnerressourcen an Arbeitsplätzen
Wartung des standortübergreifenden Netzwerks
Systemwartung
Konzeption künftiger Entwicklungen
u. v. a. m.
Notwendige Qualifikation:
Einarbeitungszeit:
3.2.6 LeiterIn, MitarbeiterIn der Abteilung Benutzerservice
Konzeption künftiger Entwicklungen
Erprobung neuer Software bzw. Releases
Konzeption und Betreuung des PC-Netzwerkes
Erstellung von Individuallösungen mit PC-Programmen
Installation und Wartung von Endrechnern
Bereitstellung von Druckerressourcen
Wartung von PC-Programmen
Benutzerbetreuung, Schulung
u. v. a. m.
Notwendige Qualifikation:
Einarbeitungszeit:
3.2.7 EntwicklungskoordinatorIn (Leitung Programmierung)
Konzeption künftiger Entwicklungsvorhaben
Beratung bei neuen Vorhaben (Machbarkeit, Seiteneffekte, Risiken)
Vorgabe von Programmierstandards
techn. Aufbereitung von Sachanforderungen (Lösungsweg, Standardisierung)
Aufwandschätzung, Terminkoordination
Kontrolle, Überwachung, Zeitabrechnung, Qualitätsverantwortung
Koordination externer Programmiertätigkeit
u. v. a. m.
Notwendige Qualifikation: umfassenden Überblick über Rechner, Datenbank und laufende Anwendungen, sehr gute theor. und prakt. Informatikkenntnisse, Projektkoordination
Einarbeitungszeit: > 4 Monate (subj. Schätzung), Spezialschulungen
3.2.8 SoftwareentwicklerIn
Programmerstellung nach vorgegebener Spezifikation
Wartung bestehender Programme (Fehlerbehebung)
Fehleranalyse bei gegebenen Anlaß
Erweiterung bestehender Programme nach Spezifikation
Systemrecherchen bei fehlender oder unzureichender Spezifikation
Änderungen an Systemprogrammteilen
Überprüfung und Wartung von Rechnerkopplungen (Datentransfer)
Erstellung und Wartung von Dokumentation
Testen von Programmen
Einarbeitung in neue Aufgabenbereiche
u. v. a. m.
Notwendige Qualifikation: allg. Programmierkenntnisse (Algorithmik), Beherrschung des Programmierumfelds (Werkzeug, Sprache), Kenntnis des Anwendungsumfelds (sachlich und informatisch)
Einarbeitungszeit: 2 – 4 Monate (subj. Schätzung), Spezialschulungen
4 Ablauforganisation für informatische Anforderungen
Aus den Zuständigkeiten der einzelnen Stellen sowie Aufgabenstellungen im Zuge betriebswirtschaftlicher Vorgänge ergeben sich typische innerbetriebliche Geschäftsfälle, die in weiterer Folge basierend auf bereits bestehende Abläufe dargestellt werden.
Im Sinne einer Total-Quality-Denkweise werden innerbetriebliche Querkontakte mit Betonung auf Qualität an den Kommunikationsschnittstellen zur Vermeidung unnötigen Mehraufwands bzw. Leerlaufs geformt. Weiters werden vorprogrammierte Reibungspunkte durch entspr. Priorisierungsregelungen emotional entschärft.
Arbeitskulturelle Aspekte lassen sich nicht anordnen geschweige denn irgendwie organisatorisch regeln. Eine solche Führungsaufgabe ist nicht Bestandteil dieses Konzepts.
4.1 Fachabteilungsbereiche
Für übliche Geschäftsfälle liegen entsprechende Organisationsvorschriften auf. Die Abwicklung derselben zieht teilweise die elektronische Datenverarbeitung mit ein. Daraus entstehende Mangelsituationen realer oder vermeintlicher Art werden entsprechend abgehandelt,
4.1.1 Geschäftsfälle mit Bedeutung für den Informatikbereich
4.1.1.1 PC arbeitet nicht
Kontrolle der Anschlüsse, Faktenerhebung (betroffener Bereich, andere Kollegen), ggf. Einbeziehung des Fachbereichskoordinators, Hinzuziehung des Benutzerservice mit hoher Priorität
4.1.1.2 Drucker arbeitet nicht
Kontrolle der Anschlüsse, Faktenerhebung (andere betroffene Benutzer, alle Anwendungen, oder nur DB); ggf. Einbeziehung des Fachbereichs-Koordinators, ggf. vorübergehende Benützung eines Alternativdruckers, Rückfrage bei Benutzerservice (gar kein Ausdruck), Systemtechnik (kein DB-Ausdruck); in Zweifelsfällen Rückfrage beim Organisator zur Priorisierung weiterer Schritte
4.1.1.3 DB-Anwendung arbeitet nicht
Faktenerhebung (andere betroffene Benutzer, mehrere Anwendungen); Rückfrage bei Systemtechnik oder Organisator.
4.1.1.4 Unerwartete Reaktion einer Anwendung
Hinzuziehen des Fachkoordinators, Sachverhaltsrecherche anhand bestehender Organisationsvorschriften und Richtlinien, Rückfrage bei Organisator mit hoher Priorität
4.1.1.5 Neuer Mitarbeiter, Änderung von Benutzerrechten
Schriftliche Anforderung in Form eines Emails an Fachorganisator bzw. bei entspr. techn. Ausgereiftheit und Befugnis direkt bei zuständigen Stellen unter Verwendung des aufliegenden elektronischen Formblatts.
4.1.1.6 Erkannte Dateninkonsistenz im Umfeld systemübergreifender Datenbanken
Dateninkonsistenz ist etwas Schwerwiegendes. Gerne tut sich ein erkannter Fehler als Spitze eines Eisberges auf. Eine falsche betriebswirtschaftliche Entscheidung kann monetäre Folgen nach sich ziehen.
Beim Zusammenspiel mehrerer Rechner ist ein höheres Maß an Risiko gegeben. Die Organisationsvorschrift geht auf allgemeine Fälle diesbezüglich ein (Organisator) und legt entspr. Maßnahmen fest (Bearbeitung durch wen, Folgerisiken). Außergewöhnliche Fälle werden dem Organisator mitgeteilt, Standardfälle entsprechend der Organisationsvorgabe behandelt.
4.1.1.7 Nicht ausreichend abbildbare Geschäftsfälle
Geschäftliche Sonderfälle werden über den Organisator abgewickelt.
4.1.1.8 Neuanforderung
Fachbereichszuständige definieren gemeinsam mit dem Organisator eine Art Projektauftrag, der ggf. unter Beiziehung anderer Bereiche (Organisatoren, Informatik) konkretisiert und realisiert wird. Dabei werden auch entspr. Abnahmekriterien festgelegt.
4.1.2 Beurteilung der Kommunikationsschnittstellen
Anhand definierter Prioritätsstufen und Zuständigkeiten werden in möglichst vielen Fällen gleich die richtigen Stellen bzw. Abteilungen tangiert. Organisatoren schafften dafür ein entspr. Regelwerk und bearbeiten die Ausnahmefällen (Lösungswege, Beschaffung von Ressourcen).
4.2 Leitung EDV und Organisation
Es wird hier lediglich auf Belange rund um hier zitierte Abläufe eingegangen.
4.2.1 Koordinative Geschäftsfälle (Auszug)
4.2.1.1 Vergabe von Eskalationsberechtigungen, Kontrolle
Eskalationen sind ein relativ unbürokratischer Weg zum kurzfristigen Freimachen von Ressourcen (siehe 4.3.1.10). Zur Vermeidung von Mißbrauch dieser offiziell höchsten Priorität wird der Berechtigtenkreis gezielt ausgewählt.
Über jede angestoßene Eskalation langen Emails in CC ein zum Zwecke der Kontrolle. Im Wiederholungsfall des Mißbrauchs sind entsprechende Maßnahmen zu setzen (Steuerung).
4.2.1.2 Entscheidung bei Gleichzeitigkeit von Eskalationen in einem Bereich
Bei sinngemäßer Handhabung dieses Dienstweges ist ein solcher Geschäftsfall eher unwahrscheinlich. Gegebenenfalls liegt Mißbrauch von Eskalation oder ein massiver Ressourcenengpaß vor und erfordert auch ohne Eskalation eine entsprechende Steuerung (siehe 4.2.1.1).
4.2.2 Bewertung der Kommunikationsschnittstelle
Die Leitung gibt offiziell die Eskalation als Priorisierungsinstrument bekannt und definiert dafür Berechtigte. Danach wird die Leitungsstelle bzw. deren Stellvertreter diesbezüglich nur noch kontrollierend tangiert. Zu diesen Zweck langen Emails als CC bei Auslösung, Abschluß einer Eskalation und in Sonderfällen ein. Sie erfordern wenig Mehraufwand im Sinne von Arbeitszeit, geben aber ausreichend Information zur Wahrnehmung von Kontrolle und Steuerung.
4.3 EDV-OrganisatorInnen für Linienaufgaben und Projektmanagement
4.3.1 Geschäftsfälle
4.3.1.1 Anfrage aus Betreuungsbereich
Solche Anfragen haben eine u. U. hohe Priorität, wenn dadurch Arbeitsstillstand oder die Gefahr eines Schadens besteht (siehe auch 4.3.1.2). Die Behandlung von solchen Anfragen gehört zu den direkten Aufgaben eines Organisators und wird in entsprechender Dringlichkeit abgehandelt.
Wiederholte Anfragen werden als Themen für Schulungen oder Organisationsvorschriften gesammelt.
4.3.1.2 Eingang einer Fehlermeldung
Der Inhalt einer Fehlermeldung ist grundsätzlich mit hoher Priorität zu behandeln. Nach Klärung des Sachverhalts wird entsprechend gehandelt, z. B.
Ø Stoppen von Bearbeitungen im Fachbereich
Ø Rückfrage beim Hersteller und Hot-Line Service
Ø Behebung durch Systemeinstellungen
Ø Definition eines „Workarounds“ für Fachbereich, temporäre Org.-Vorschrift
Ø Anstoßen eines Projekts
Ø Auslösen einer internen Eskalation
4.3.1.3 Sonstige Anfragen, Beratung
Als Experten ihres Zuständigkeitsbereichs sind Organisatoren auch Ansprechstellen im Falle von realen bzw. vermeintlichen Wechselwirkungsproblemen mit anderen Systembereichen. Speziell bei bevorstehenden Änderungen an Einstellungen kann dadurch Schaden infolge unerwarteter Nebeneffekte verhindert werden. Die Verhinderung von Schaden rechtfertigt den Aufwand der Vorbeugung.
4.3.1.4 Erstellung und Wartung von Ablaufregeln
Organisationsvorschriften sind wichtige Dokumente und Begründen die Abwicklung von Geschäftsfällen in den Fachabteilungen. Diese werden in einer für den Einsatzort verständlichen Sprache verfaßt und sollen für Standardfälle den Organisator entlasten. Analoge Dokumente gibt es hinsichtlich gelegentlich vorkommende Sonderfälle für Fachbereichs-Koordinatoren.
Jede Änderung bzw. Erweiterung in der Handhabung einer EDV-Anwendung wird dokumentiert, damit dieses Regelinstrument nicht an Aussagewert verliert. Dazu gehört auch eine Weiterleitung an die Fachbereiche einschl. zuverläßigem Austausch und Verlautbarung von Änderungsdetails.
4.3.1.5 Vergabe von Berechtigungen
Durch Befragung wird das notwendige Berechtigungsprofil erarbeitet, dokumentiert und im System abgebildet bzw. in Auftrag gegeben.
4.3.1.6 Aufbereitung von Fachthemen
Der Organisator wird stets mit Neuem konfrontiert und es liegt weitgehend an ihm, sich darauf soweit vorzubereiten, daß von ihm entschiedene von Weitblick und guter Qualität sind.
Zur Wahrnehmung einer solchen Verantwortung wird anhand einer Vorschau künftiger Entwicklungen und Zuständigkeiten ein allfälliger Mangel prognostiziert und dementsprechend eingeplant, welche Maßnahmen dagegen getroffen werden (Schulung, Literaturanschaffung, Selbststudium, In-House-Schulung, Gründung Arbeitskreise).
4.3.1.7 Schulung
Diese Art von Unterweisung stattet mehrere MitarbeiterInnen des Fachbereichs gleichzeitig mit den notwendigen Kenntnissen aus, die für die Abwicklung der Routinearbeit erforderlich sind. Schlüsselpersonen wie Fachbereichskoordinatoren erhalten spezielle Schulungen und entlasten ggf. den Organisator.
Die Weitergabe von Wissen in Zusammenhang mit einem Anwendungsumfeld ist auch für beigezogene Dienstleister von Interesse und wird in Form von Informationsveranstaltungen schwerpunktmäßig weitergegeben - z. B. an die Softwareentwickler.
Das Vorbereiten von Schulungen bedarf didaktischen Feingespürs und exzellenter praxisnaher und getesteter Schulungsunterlagen. Die Schulungsabwicklung selbst erfordert u. a. intensive Koordinationsanstrengungen (Termin, Raum).
4.3.1.8 Änderungen am System
In komplexen Systemen ist jede Veränderung von Einstellungen kritisch. In entspr. Testszenarien wird die neue Einstellung auch hinsichtlich unerwarteter Reaktion geprüft. Zusätzlich wird das ev. betroffene Umfeld beleuchtet bzw. werden die entspr. Zuständigen beratend beigezogen. Ein besonderes Augenmerk gilt dabei den eigenentwickelten Programmen, die womöglich auf solche Veränderungen falsch oder gar nicht reagieren.
4.3.1.9 Erkannte urgente Ausnahmesituation
Im Hintergrund stehen wesentliche Mißstände wie hochgradiger Systemausfall, Blockierung hochsensibler Abläufe ohne Möglichkeit eines Workarounds, Gefahr in Verzug durch mögliche schwerwiegende Folgefehler.
Es wird eine interne Eskalation zum kurzfristigen Freimachen von Ressourcen ausgelöst (siehe 4.3.1.10)
4.3.1.10 Fehlermeldung an Entwicklungsabteilung
Vor einer solchen Meldung wird das Systemumfeld auf allfällige andere Ursachen überprüft. Dabei erhobene Erkenntnisse über Ursachen bzw. Begleiteffekte oder Entstehung des Mangels werden niedergeschrieben und gemeinsam mit einem nachvollziehbaren Testfall der Entwicklungsabteilung bekanntgegeben. Dabei wird auf allfällige Risiken bei der Wiederholung des Beispieles hingewiesen bzw. ein Termin für eine gemeinsame Recherche vereinbart.
4.3.1.11 Auslösen einer Eskalation
Zum Auslösen einer internen Eskalation bedarf es einer Situation von hohem Schweregrad. Dieser kann sowohl real als auch vermeintlich sein. Das Auslösen wirkt ähnlich wie beim Feueralarm: Menschen lassen alles andere liegen und helfen im Sinne des übergeordneten Unternehmenszieles.
Eine Eskalation dient dem Freimachen von Ressourcen in akuten Fällen. Berechtigte können davon eigenverantwortlich Gebrauch machen und sich so hinsichtlich höchster Priorität entsprechend artikulieren.
Es bedarf dafür eines elektr. Formblatts. Darin wird neben administrativer Kenndaten (Name, Datum etc.) kurz die Bedarfsstellung umschrieben. Dieses wird an die betreffende ausführende Stelle und in CC an die Informatikleitung gesendet. Alles weitere wird mit der ausführenden Stelle ohne Dienstweg direkt abgewickelt.
Nach Abschluß wird vom Auslöser der Eskalation dieselbe zurückgezogen und im Formular endberichtet (Status, Aufwand, Ergebnis).
4.3.1.12 Spezifizierung von Anforderungen, Koordination
Im Falle von nicht direkt umsetzbaren Sonderaufgaben wird eine Anforderung spezifiziert und in erster Instanz die Aufgabenstellung und das gewünschte Ziel dargelegt. Falls vorhanden, werden auch mögliche Lösungswege dargelegt.
Technisch ausgereifte Spezifikationen werden an die Entwicklungsabteilung weitergeleitet. Andere werden mit Hilfsstellungen aus Fachbereichen, Hersteller (Hot-Line etc.) oder externe Beratung vervollständigt und dann weitergeleitet. Zur Spezifikation gehört auch eine Festlegung von Abnahmekriterien in Hinblick auf inhärente Problemzonen der Anwendung bzw. Schwächen des Lösungsweges.
Zur Koordination von Anforderungen gehört weiters eine Erörterung des Anwendungsumfeldes falls der zugeteilte Bearbeiter darin nicht versiert ist. Organisator und Entwickler treten während der Bearbeitung in eine enge Zusammenarbeit. Dabei stellt der Organisator zeitgerecht Testfälle bereit und entscheidet während der Entwicklung erkannte Problemzonen.
4.3.1.13 Projektbetreuung
Im Falle delegierter Projektkoordination liegt es teilweise am Organisator, daß durch Abstimmung von Ressourcen und Bereitstellung von Informationen ein reibungsloser und termingerechter Fortgang des (Teil-)Projekts ermöglicht wird.
Es obliegen ihm so auch die Aufgaben der Kontrolle und Steuerung, welche gegebenenfalls den Projektleiter entlasten und entsprechende Befugnisse erforderlich machen.
4.3.1.14 Abnahme von Neuentwicklungen und Korrekturen
Nach Bereitstellung des Prototyps einer Neuentwicklung führt der Organisator anhand bereits vorhandener Kriterien intensive Tests durch. Ggf. wird das Testszenarium aufgrund vom Programmierer mitgeteilter Schwachzonen erweitert bzw. durch diesen vorgeschlagen. Für eine Delegierung von Abnahmetests werden die entsprechenden Kriterien der Fachabteilung detailliert in einer verständlichen Sprache bekanntgegeben; die Freigabeverantwortung verbleibt beim Organisator.
Die Freigabe erfolgt in Form eines nachvollziehbaren und ablegbaren Dokuments. Darin werden u. a. Abnahmetestfälle bzw. prinzipielle Vorgangsweisen beim Testen dargelegt (z. B. Zusammenfassung des Schriftverkehrs, Verweis auf Nebendokument bzw. als Beilage).
4.3.2 Beurteilung der Kommunikationsschnittstellen
Der Organisator bestreitet prinzipiell einen Vielfrontenkrieg und benötigt ein hohes Maß an Belastbarkeit, Breitbandwissen, beziehungsorientierten Neigungen und Selbstorganisation. Der Alltag ist permanent streßgeladen, gilt es ja „ Unmögliches doch noch zu ermöglichen“.
Organisatoren schöpfen in der Hauptsache die Motivation aus intrinsischen Werten: Zusammenarbeit mit anderen, Gruppenerleben, Erreichen von Zielen, zufriedene Kunden, reibungslose Abläufe, Lob, sich abgebildet wissen u. s. w. Schwerwiegende Demotivatoren sind Auseinandersetzungen persönlicher Art und fehlende Rückendeckung im eigenen Lager.
Mögliche Verbesserungen an Schnittstellen sind ein geregelter Ablauf an Reibungspunkten. Sie schaffen klare Voraussetzungen und Erwartungshaltungen, sowie verlagern bei Konflikten Feindbilder an die eigentliche Kompetenz.
Für wirklich akute Notfälle erlaubt eine Eskalation eine ausreichende Artikulierung mit entsprechender Rückendeckung aller Beteiligten.
4.4 Bereich Softwareentwicklung
4.4.1 Geschäftsfälle
4.4.1.1 Eingang einer Eskalationsanforderung
Unter Annahme einer bedachten Handhabung dieses Priorisierungsinstruments sollte ein gleichzeitiges Zusammentreffen mehrerer Eskalationen an einer Stelle nicht die Regel sein. Gegebenenfalls entscheidet die Leitung allfällige Konflikte.
Eine Eskalation erfolgt in Form eines Emails basierend auf einem Vordruck und stammt von einem Eskalationsberechtigten bzw. dessen Stellvertreter. Sie muß bevorzugt gehandhabt werden. Es wird umgehend ein Bearbeiter nominiert bzw. es steht durch dokumentierte Zuordnungen bereits ein solcher fest. Dieser beendet umgehend die momentane Arbeit nach Maßgabe anliegender Risiken und tritt mit dem Auslöser der Eskalation zur Behandlung des Notfalls in eine enge Verbindung. Bei Bedarf werden weitere Personen unter dem Titel derselben Eskalation zugezogen. Allfällige Verzögerungen, Leerläufe, ideelle bzw. materielle Verluste sind durch das übergeordnete Interesse ausreichend rückengedeckt.
Nach Beendigung der Eskalation erfolgt eine Rückmeldung an den Auslöser mit CC an die Leitung anhand des Auslösedokuments unter Bekanntgabe des Ergebnisses, Aufwandes in Stunden bzw. Tagen und allfällige Konsequenzen – etwa Terminverzögerungen, Arbeitsleerlauf.
4.4.1.2 Eingang einer Anforderung
Jede Anforderung wird abteilungszentral registriert (Bezeichnung, Ansprechpartner, Status, Terminwunsch etc.) und mit einer laufenden Bearbeitungsnummer versehen. Je nach Vorhandensein einer Abteilungskoordinationsstelle werden Eingänge an diese weitergeleitet sofern keine Pauschalbereitstellung von Ressourcen für eine Aufgabengattung vereinbart wurde.
Nach Festlegung von Bearbeiter und Terminierung kommt die Aufgabe in die Warteschlage des betreffenden Bearbeiters. Kurzfristige Aufgaben werden explizit bekanntgegeben, längerfristige in Monatsprojektplänen disponiert.
Der Antragsteller erhält ehest eine Rückmeldung in Form einer Email als Bestätigung des Einlangens. Weitere Recherchen und Rückfragen erfolgen unter dieser Registrierungsnummer und sind so rasch und eindeutig zuordbar.
4.4.1.3 Teilnahme an Besprechungen
Entwickler stehen für begonnene Arbeiten mit Antragstellern in einer innigen Verbindung. Sie sind auch verpflichtet, für geplante Aufgaben einen kurzen Statusbericht abzugeben bzw. Ergänzungen entgegenzunehmen.
Beratende Tätigkeiten werden für Komponenten des Zuständigkeitsbereichs im Einzelfall kurzfristig nach Terminabsprache wie eine Anfrage abgewickelt und dokumentiert. Bei Überschreiten des Ausmaßes einer Kleinigkeit und Fehlen terminlicher Freiräume wird der Anfragepunkt in die allg. Warteschlange gestellt.
Berechtigte Antragsteller können in Notfällen von einer Eskalation Gebrauch machen.
4.4.1.4 Priorisierung von Aufgaben
Eskalationen haben unumstritten die höchste Priorität gefolgt von dringenden Arbeiten seitens der Koordinationsstelle. Weitere Prioritäten werden unter Vermeidung von Leerläufen und zeitvergeudenden Arbeitsunterbrechungen gehandhabt. Zur Entscheidung jeweils nächster Bearbeitungen werden visualisierende Werkzeuge eingesetzt und in Zweifelsfällen mit der Koordinationsstelle besprochen.
4.4.1.5 Bearbeitung von geplanten Aufgaben
Projektpläne regeln mittelfristige Aufgabenstellungen und deren vorgesehenen Fertigstellungstermin. Sie ermöglichen den Bearbeitern einen gewissen Überblick und Freiraum der Zeitdisposition unter Nutzung allfälliger Synergien artverwandter Aufgabenstellungen.
Eine Aufgabe wird erst mit Bereitstellung einer Spezifikation in Angriff genommen. Nicht termingerechtes Einlangen einer Spezifikation verzögert das Vorhaben durch zusätzliche Recherchen bzw. verspäteten Beginn der Bearbeitung. Solche Verzögerungserwartungen werden dem Antragsteller sowie der Koordinationsstelle mitgeteilt. Bei Bedarf wird ein klärendes Auftragseingangsgespräch zwischen Fachabteilung und Systementwickler(n) vereinbart.
Unzureichende bzw. fehlerhafte Spezifikation (z. B. unerwartete Nebeneffekte) stellen u. U. eine allfällig gestellte Aufwandsschätzung in Frage. Ein solcher Sachverhalt impliziert eine Verzögerungsrisiko und wird ehestens dem Antragsteller sowie der Koordinationsstelle mitgeteilt.
Ein fertiggestellter Prototyp wird soweit getestet, als Testfälle bzw. Wege zur Durchführung von Tests bekanntgegeben wurden. Mit Erfüllung dieser Mindestqualität an den Prototyp wird an den Organisator übergeben, die Aufgabenregistrierung wird auf „abgeschlossen“ gesetzt. Bis zur Freigabe bzw. Einlangen von Mängelmeldungen wird die Aufgabe eingefroren.
Mit eingehenden Meldungen zu Mängeln wird die Arbeit wieder aufgenommen. Sollten dargelegte Mängel in Widerspruch zur Spezifikation stehen, liegt ein Planungsfehler vor und ist im breiteren Rahmen zu diskutieren. Unter Umständen wird der gesamte Programmentwurf und eine gegebene Zeitaufwandschätzung in Frage gestellt. In solchen Fällen werden Auftraggeber und Koordinationsstelle entspr. informiert.
Eingebrachten Ergänzungen größeren Ausmaßes versteckt als Mangel werden bei nicht gegebener terminlichen Freiräumen als neue Aufgabe in die Aufgabenwarteschlange gestellt.
Ohne Freigabe wird prinzipiell kein Programm freigeschaltet, allenfalls auf nachvollziehbaren Wunsch als Zweitfassung. Die Vergabe allfälliger Berechtigungen ist Aufgabe des Organisators.
4.4.1.6 Bearbeitung von ungeplanten Aufgaben
Solche Aufgaben werden kurzfristig eingebracht, ohne oder mit Eskalation. Letztere müssen umgehend in Angriff genommen werden, andere nach Maßgabe laufender Arbeiten bzw. angegebener Termine bzw. Dringlichkeiten.
Ein Großteil solcher Aufgaben betrifft Mängelbehebungen an System oder eigenentwickelten Programmen. Je nach Grad der Spezifiziertheit beginnt die Tätigkeit mit Recherchen anhand eines Mängelbeispieles gefolgt von der Analyse des Umfelds und Interpretation der Wirkung bzw. der Abweichung derselben von der erwarteten. In Absprache mit dem Veranlasser der Aufgabe werden ggf. gesammelte Erkenntnisse gemeinsam besprochen und weitere Schritte entschieden.
Bei unerwarteter Ausdehnung des Bearbeitungsaufwandes wird die Koordinationsstelle beigezogen bzw. vom Antragsteller eine Eskalation ausgelöst.
Erledigte Bearbeitungen werden nach Freigabe durch den Antragsteller in der Aufgaben-Eingangsverwaltung durch entsprechenden Status als „erledigt“ gekennzeichnet; bei Verzögerungen seitens des Antragstellers durch den entspr. Zwischenstatus „abgeschlossen“.
4.4.1.7 Betreuung von externen Beratern
Die zugeordnete Kontaktperson schult den externen Berater hinsichtlich der geltenden Richtlinien, bereitet notwendige Unterlagen vor und übergibt die beigestellte Spezifikation bzw. erklärt in einem persönlichen Gespräch die Aufgabenstellung und deren Rahmenbedingungen. Für allfällige technische Einzelheiten stellt sich der Betreuer kurzfristig zur Verfügung. Fachliche Einzelheiten werden vom Berater ggf. über den Organisator abgewickelt.
Mit Fertigstellung des Prototyps werden die bereitgestellten Testbeispiele gemeinsam mit dem Berater erprobt. Weiters werden die Programme durchgesehen (technische Abnahme), allfällige Ergänzungen, Qualitätsmängel bzw. Nichteinhaltungen von Richtlinien besprochen und deren Berichtigung koordiniert.
Im Falle zu kurz geschätzter Aufwandszeiten übernimmt der Betreuer den bisherigen Arbeitsstand für eine allfällige Fortsetzung bzw. Fertigstellung.
Für die Abnahme ist der Organisator zuständig, eine allfällige Administration koordiniert der Entwicklungsbetreuer.
4.4.1.8 Benutzerdefinition für In-House entwickelte Anwendungen
Zutrittsberechtigungen zu sensiblen Daten sind eine heikle Angelegenheit. Die Vergabe erfordert Kompetenz und Verantwortung, d. h. es soll sich nicht jeder selbst seine Rechte geben können. Telefonische Anforderungen werden wegen der fehlenden Nachvollziehbarkeit nicht entgegengenommen.
Antragsteller (vorzugsweise Organisatoren) erhalten ggf. ein elektronisches Formular zugesandt (liegt auch auf), in das die wesentlichen Kenndaten (Name, Referenzbenutzer, Zielanwendung) verbindlich eingetragen werden. Anhand des dort abgebildeten Formularflusses werden ggf. weitere Stellen für fortgesetzte Definitionen angestoßen (dezentrale Abwicklung). Ein Antragsteller erhält Mitteilung über erledigte (Teil-) Durchführungen. Erledigte Benutzerdefinitionen werde als Dokumentation gesammelt für spätere Recherchen.
Neben der Erteilung von Rechten gibt es auch die Rücknahme derselben, die analog abgewickelt werden.
4.4.1.9 Einarbeitung in neuen Fachbereich
Im Idealfall nimmt ein Mitarbeiter zeitgerecht an einer Kursveranstaltung teil. Eine andere Möglichkeit ist ein autodidaktes Einlesen, Einweisung durch andere oder das direkte Erproben anhand von Beispielen. Jede dieser Varianten benötigt Zeit und Ruhe, damit der Lernende sich dem Thema ordentlich widmen kann.
Als Abschluß einer Einarbeitung wird eine Zusammenfassung erstellt und einer größeren Gruppe schriftlich zugänglich gemacht bzw. präsentiert (interne Informationsnachmittage).
4.4.1.10 Weitergabe von Wissen
Im dynamischen Umfeld von EDV-Anwendungen ist es enorm wichtig am laufenden zu sein. Manche Kenntnisse werden autodidakt erworben, manche kommen über externe Berater herein und im Idealfall besuchen KollegInnen Kurse. Solches Wissen wird überblicksmäßig aufbereitet und in organisierten Informationsnachmittagen in Form von Kurzvorträgen mit Diskussion einem größeren Mitarbeiterkreis zugänglich gemacht.
Diese Unterlagen werden als interne Dokumentation aufbewahrt und können so auch neuen Mitarbeitern zugänglich gemacht werden.
4.4.1.11 Dokumentation
Zur Entwicklungsdokumentation zählen Spezifikation, Spezifikationsergänzungen, Schriftverkehr und die Kommentare im Coding. Auf alle diese ist zur Erzielung höchstmöglicher Qualität besonderer Wert zu legen.
Im Falle terminlicher Engpässe werden noch nicht erbrachte Qualitätsarbeiten als offene interne Anforderungen eingeplant um nicht vergessen zu werden.
4.4.1.12 Fehleranalyse
Jeder Fehler größeren Ausmaßes wird untersucht auf Hintergründe des Entstehens (Denkfalle, unbekannter Hintergrund, Folgefehler, Fehleinschätzung, Qualifikationsmangel. u. s. w.; siehe SW-Qualitätssicherung) und im Fehlerhandbuch wertfrei sowie anonym dokumentiert. Es ist nicht Aufgabe dieses Instrumentariums, Mitarbeiter zu bewerten sondern irreführender Sachverhalte für alle offenzulegen. Denkfallen werden in entspr. Richtlinien übertragen und breit verlautbart.
4.4.1.13 Zeitabrechnung, Aufwandserhebung
Die Erfassung von Aufwandszeiten stellt für Neuentwicklungen ein wichtiges Planungsmittel dar. Mit Hilfe von Analogieschlüssen und Schwierigkeitsgewichtungen lassen sich bei realistischer Zeitregistrierung von vergangenen Projekten plausible Planvorgaben für künftige erstellen.
Zu diesen Zweck werden Aufgaben gegliedert in:
Ø gesondert verrechnete Arbeiten nach außen
Ø Neuerstellungen
Ø Wartungsarbeiten
Im ersten Fall ist die Notwendigkeit einer Abrechnung offensichtlich, es geht um echt fließendes Geld. Andere Arbeiten werden intern pauschal verrechnet und deren Aufzeichnung bewirkt nur insofern etwas, als abgeleitete Kenngrößen aktiv in die Ablaufkontrolle und –steuerung mit einbezogen werden.
Neuerstellungsparameter tragen zur Schätzung von Planvorgaben bei. Aufwände werden gesammelt und bei Abschluß verdichtet und endbewertet hinsichtlich Umfang, Schwierigkeitsgrad und Entwicklungsfortgang (Planungsqualität etc.).
Für Wartungen gelten eigene Aufwandsskalen; je nach Komplexität des Umfelds sind - verglichen mit Coding von Neuentwicklungen - Faktoren von 5 bis 100 aufzuschlagen. Eine administrative Vermischung von Neuentwicklung und Wartung macht somit wenig Sinn. Im Extremfall werden Wartungen zu Neuentwicklungen (siehe oben).
Wartungen werden ohne große Aufwandsangabe als Aufgaben registriert. Zur Steuerung und Kontrolle gibt es die Parameter Kundenbezug (Kontaktperson, Abteilung), Bearbeitungspriorität, Status („offen“, „abgeschlossen“, „erledigt“) sowie Datum des Auftragseingangs, Bearbeitungsbeginns und Fertigstellung.
4.4.2 Beurteilung der Kommunikationsschnittstellen
Das Fortführen eines hohen Gütelevels der Planung schaffen Qualität und Zufriedenheit aller Beteiligten. Klare Prioritäten vermeiden Konflikte im Falle unerwarteter Zusatzaufgaben.
Aufliegende Dokumentation erlaubt rasches Handeln durch Überblick und effektive Einbeziehung von Zusatzpersonal.
Eine Abkehr von Einzelkämpfertum hin zu gemeinschaftlichen Teamdenken schafft ein harmonisiertes Miteinander und so eine motiviertes Arbeitsumfeld.
4.5 Bereich Systemtechnik
Es liegen keine Erhebungen vor
4.6 Bereich Benutzerservice
Es liegen keine Erhebungen vor
5 Zusammenfassung
Die diesem Vorschlag einer Ablauforganisation zugrundeliegenden Prinzipien lassen sich auf einige wenige Leitgrundsätze zurückführen und sich dadurch auch relativ leicht umsetzen. Es werden dadurch vorprogrammierte Reibungspunkte durch klare Vorgaben und Hebung der Informationsqualität entschärft und dadurch Konflikte leichter bewältigbar. Darüber hinaus liegt es an den leitenden Stellen, festgefahrene Verhaltensmuster durch glaubwürdige und sichtbar gelebte Grundsätze wieder in Gang zu setzen und ihnen die nötige Polung im Sinne einer Mitarbeitermotivation zu geben.
Leitgrundsätze:
Ø Definition klarer Prioritätsgrundsätze
Ø Möglichkeit einer unbürokratischen Abwicklung dringendster Notfälle (Eskalation)
Ø Arbeitsplanung in schaffbaren Größenordnungen mit Stellenbezug
Ø Sichtbarmachung geleisteter Arbeit
Ø Messung von Leistung anhand erledigten Arbeiten
Ø Anstreben hoher Arbeitsqualität zur Reduzierung von Fehlern bzw. Wartungsaufwänden
Ø Zeitzuteilung für Qualitätsarbeiten (Test, Dokumentation, Hilfestellungen)
Ø Frühwarnsystem für Zeitüberschreitung
Ø Mindestqualitätskriterien an Kommuniktionsschnittstellen (TQM)
Ø Klare Abnahmekriterien, Zuständigkeit und Nachvollziehbarkeit
Ø Ausstattung von Mitarbeitern mit erforderlichen Befugnissen
Ø Förderung umfassenden Wir-Denkens, gelebte Teamarbeit
Ø Verstärkung aufgabenspezifischer Weiterbildung
Ø Abhaltung interner Schulungsnachmittage zur Weitergabe von Wissen
Quellennachweis
Weinberg, G. M.: Systemdenken und Softwarequalität, Wien: Hanser, 1994,
ISBN 3-446-17713-2
Wegenberger, Josef: Leistung steigern durch Teamarbeit, Wien: WEKA, 1999,
ISBN 3-7018-4506-9
Wegenberger, Josef: Gute Gespräche fördern Mitarbeiter, Ziele vereinbaren Mitarbeiter führen Visionen umsetzen, Wien: WEKA, 1998, ISBN 3-7018-4135-7
Chroust, G.: Modelle der Softwareentwicklung, Wien: Oldenburg, 1992, ISBN 3-486-21878-6