straubefamily.de

Seit vielen Jahren beschäftige ich mich mit der Entwicklung von IT-Anwendungen und elektronischen Diensten. Zuerst richtig so mit Quellcode und Technik, zuletzt mit Organisation im Projekt und vor allem mit der Organisation und den Prozessen, die nach Entwicklungsabschluss notwendig sind, damit die Investition in Entwicklung, Hard- und Software dann auch wieder eingespielt wird.
Ich nenne das den "Betrieb". Das hat was mit Organisationslehre, mit Prozessen, Geschäftsmodellen, Betrieb, Sicherheit, Content, Technik, ... und und und zu tun. Eigentlich ist es viel Papierkrieg, aber uneigentlich ist es notwendig und es kann auch spannend sein.

Szenen aus dem Arbeitsleben

Schreib mal das Betriebskonzept ...

 Tatsache, meist fing es mit solch einem Satz an.

Da steht einer vor Ihnen und sagt: Schreib mal das Betriebskonzept! Der Auftraggeber für unseren Dienst will eins haben.

Was ist denn das eigentlich? Definiert steht es nirgends, jeder hat eine andere, aber dafür eine genaue Vorstellung davon. Irgendwie muss das alles ja betrieben werden, nicht?
Der da steht, das ist meist der Projektleiter vom Entwicklungsprojekt für einen elektronischen Dienst. Um die Situation genauer zu beschreiben, noch folgende Sachverhalte (die sagt er auch noch auf mein Nachfragen):
  • Die Mittel im Projekt sind schon fast weg oder überzogen.
  • Es muss nächste Woche Montag beim Auftraggeber präsentiert werden.
  • Geschäftsmodell - weiß ich nicht. Wird's schon geben, aber wir haben keines, zumindest keine Unterlagen.
  • Wer Betrieb machen soll, weiß ich nicht.
  • Standorte? Kundenzahlen? Keine Ahnung.
  • Ich sag Dir noch einen Ansprechpartner, der von der Entwicklung Ahnung hat, aber der ist nicht da und im Stress, weil der auch nächste Woche präsentieren muss.
Könnt ihr das machen?
So oder so ähnlich sind die meisten Projekte reingeschneit.
Mich ärgert das, weil meist ist es dann schon viel zu spät. Softwareentwicklung fast fertig, keiner hat an Betrieb gedacht. Oder erst jetzt, weil es noch irgendwo im Vertrag bzw. Auftrag steht und mit geliefert werden muss.

Dabei ist die Erstellung des Betriebskonzeptes genauso Entwicklungsarbeit wie Design oder Implementierung. Allerdings eben nicht in HTML, C++ oder Java, sondern in Organisation. Aber das kostet genau so viel wie die andere Hälfte einer praxisorientierten, auf einen schnellen Break-Even ausgerichtete Entwicklung.

Spätestens wenn der Auftraggeber mit dem elektronischen Dienst unterm Arm aus unserem Haus marschiert, kann er nämlich ohne Betriebskonzept damit nix mehr anfangen. Wer wird es ihm betreiben? Welche Prozesse sind dazu noch notwendig? Was braucht er noch dafür außer der Entwicklungsumgebung, die ihm die Entwickler freundlicherweise wieder mitgegeben haben? Und was wird der Betrieb kosten? Wie kriegt er jetzt sein investiertes Geld wieder rein? Die Entwicklung wurde ja sozusagen aus dem Kredittopf finanziert.

Nix.
Im Prinzip kann er seine Kiste in die Ecke stellen und vergessen. Glaumses mir, ich hab schöne Kisten in der Ecke stehen sehen!

Ein neuer Mitarbeiter ...

 Ein neuer Mitarbeiter sitzt vor mir. Der Chef hat gesagt, der soll hier mitmachen. Ich hätte gesagt, es gibt gut zu tun bei uns. Allerdings hat der neue Kollege vorher was anderes gemacht.

"? :-o ?"
"Erklär es ihm, arbeite ihn ein."
"Na, gern. Wenn ich nichts anderes machen brauch."
"Vergiss es, die Termine bleiben, wie sie sind! Er kann Dir ja dabei helfen."
"Aber er hat sich noch nie mit dem Thema beschäftigt und bis er drin ist - na, sagen wir - 9 Monate?"

Ja, so geht es; auch so eine berühmte Situation. Was tun? fragte Lenin.

Wie komme ich zu Betriebskonzepten?

Was es ein soll:

 Als das erste Mal so Einer vor mir stand und ein Betriebskonzept wollte, wusste ich auch noch nicht, wie, was und wo.

Die in den folgenden Aufsätzen beschriebenen Zwischenräume zwischen meinen Wissenslücken (schöner Ausdruck, nicht?) habe ich mir in vielen Projekten, aus vielen Büchern und einigen Diskussionen selbst gefüllt. Vieles ausgedacht, manches umsortiert, einiges transferiert.
Inzwischen ist es eine ziemlich feste Struktur, eine Methode, mit der ich ganz gut durch das Betriebskonzeptioniererleben gekommen bin. Na gut, automatisch geht es nie. Bei jeder neuen Aufgabe musste ich wieder neu denken, Gott sei Dank! Das hatte dann auch Rückwirkungen auf meine Struktur, meine Methode. So habe ich sie fortgeschrieben.

Das Schreiben und Malen hatte noch einen Vorteil: Ich konnte dem neuen Kollegen was in die Hand geben und hatte erst mal meine Ruhe. Mit einem Muster aus einem alten Projekt konnte er vielleicht schon das eine oder andere Fragment für unsere laufenden Aufgaben beitragen. Bis es wächst und wir sagen können, nun geh das oder das mal alleine an.

Denn als Studienfach gibt es so was nicht, das lebt neben technischem und organisatorischem Wissen viel von Erfahrung. Auch von Fantasie und Gefühl - komisch, nicht, bei solch einem Thema. Aber manchmal brauchte ich nur die Augen zumachen, mir ein Rechenzentrum vorzustellen und den Leitstand, die kaffeetrinkenden Leute aus der Netzstelle, die papierkarrenden Mädels aus der Druckerei, ... und mir Ausdenken, wie das miteinander spielen könnte. Film im Kopf, Drehbuch schreiben - Prozessbeschreibung machen!

Ich habe auch festgestellt, dass es zu diesem Thema "Betriebskonzepte für elektronische Dienste" wenig Theorie gibt. Doch, gibt es schon, auf verschiedenen anderen Teilgebiete wie
  • Organisationslehre
  • Verwaltung
  • Betriebswirtschaft
  • Projektmanagement
  • Computertechnik und Kommunikation
  • Psychologie
  • Softwaretechnik
  • und und und
Aber zusammengefasst hat es so noch keiner außer vielleicht den Leuten, die die Beiträge zu ITIL (IT Infrastructure Library) erarbeitet haben. Aber ich könnte wetten, die haben es genau wie ich gemacht.

Was es ist:

 Eine Sammlung von Aufsätzen. Ist das nun Wissenschaft?
Mein alter Systemtheorieprofessor Fritsche hat gesagt: "Wissenschaft ist gesammelte Erfahrung". Insofern ist das hier auch Wissenschaft. Andererseits kann jeder mit ein wenig Nachdenken und Strukturgefühl selber auf so was kommen. Da bin ich nicht unbedingt Wissenschaftler. Letztendlich ist es mir auch egal; mir hilft es und es macht Spaß, das aufzuschreiben. Ausserdem hilft mir das Aufschreiben auch, Struktur hineinzubringen und eine Systematik zu finden. Deshalb habe ich das alles in mehrere Teile gepackt. 
Teil 1 ist der hier, die Einführung. Ein teils langweiliger, teils lustiger Vorspann.

In Teil 2 versuche ich Grundlagen darzustellen, die man braucht, wenn man die anderen Teile auch lesen möchte. Der Teil bildet den Rahmen, um das andere alles zusammenzuhalten. Hier erkläre ich Begriffe, denn wenn man miteinander redet, sollten Begriffe vorher klar sein. Naja, oder zumindest halbwegs klar.
Der Teil 3 besteht aus Teilteilen. Dort ziehe ich quer durch die Gebiete des Betriebes, die ich für mich strukturiert habe.
Teil 4 beschäftigt sich mit einem Übergangsthema: Von der Entwicklung zum Betrieb - die Einführung.

In Teil 5 gibt es etwas zur Form, also zur Dokumentation. 
Teil 6 ist auch eines meiner Lieblingsthemen, die bei der Entwicklung gern hinten runtergeschoben werden. Und zwar für beide Richtungen: für die technische und die Organisationsentwicklung. Es geht um Anforderungen und Anforderungsmanagement.
Den Teil 7 halte ich mir noch frei. Da gibt es eine Sammlung von Material, die ich schon lange zu einem eigenen Teil zusammen fügen möchte. Es geht um Geld, Kosten - genauer: um die Betriebskosten. Was kostet Betrieb? Aber da muss ich noch dran arbeiten.
Und Teil 8 sammelt noch mal alle möglichen Informationen und bietet auch Hilfen für die Arbeit an.


Ausserdem habe ich mir im Laufe der Jahre einige Hilfen gebaut. Das sind z. B.  Dokumentenvorlagen, die gleichzeitig eine Art Checkliste sind, einige Berechnungs- und weitere Werkzeuge.

Was es nicht sein soll:

 Eine Lehre. Ein Ideal. Eine Mussvorschrift.

Eigentlich ist es einfach: Denke selbst. Ich will Dir mit der Struktur und meiner Methodik helfen, Deine Aufgaben zu lösen. Ich will helfen, die Entwicklung so zu machen, dass was rauskommt, was wirklich mal Geld einspielt. Etwas, wo vorher an die armen Betriebsstellen gedacht wird, denen hinterher irgendwelche toll entwickelten Produkte, Dienste oder IT-Anwendungen übergeholfen werden, die außer mehr Arbeit nichts einbringen.
Ein krummgerechnetes Geschäftsmodell oder einen rosaroten Business Case kann ich allerdings damit nicht korrigieren.

Immer dran denken: Kritisch sein. Ich muss mit meinen Ideen, Strukturen, Methoden, Aussagen nicht recht haben, andere Sichten sind möglich, in jedem Dienst, in jedem Projekt existieren andere Rahmenbedingungen. Das hier ist EINE Hilfe.

EINE heißt, es sind auch andere möglich.
Und Hilfe heißt Hilfe, nicht Vorschrift.
Denke selbst!

Ach so: Es tut mir leid, aber ich kann Ihnen in der ersten oben beschriebenen Situation - also der Geschichte mit "... muss nächste Woche Montag beim Auftraggeber präsentiert werden." - nicht viel helfen. Wunder dauern eben doch ein wenig länger.
Aber wenn es längerfristig ist oder vielleicht dann beim nächsten Mal ein wenig professioneller gehen soll, dann sind Sie hier richtig.

Etwas Geschäftliches

 Für die Erarbeitung der Aufsätze und die Erstellung der Tools habe ich einige Zeit investiert. Wer das alles genauer und ausfühlicher nachlesen oder benutzen möchte, weil er es für seinen Job braucht, wendet sich bitte an mich. Meine Kontaktdaten sind hier zu finden.

Ich melde mich nach Ihrer E-Mail dann zurück Sie erhalten einen - hoffentlich - klugen Rat, ob es sich aus meiner Sicht für Sie lohnt, in ein, mehrere oder alle Teile der Aufsatzsammlung zu investieren. Was ich nicht möchte (und nicht nötig habe), ist, Ihnen etwas aufzuschwatzen. Ich sende Ihnen dann ein Angebot für die Dinge, die ich Ihnen zusenden kann und würde.


Seitenanfang Homepage Familie Betriebskonzepte

Kontakt Impressum

L. Straube 24.02.2009