Einer Pressemitteilung des Unternehmens, mit der auch das Bild des wütenden Chefs verbreitet wurde, kann man entnehmen, dass Fehler und Probleme in der neuen Software für das Chaos verantwortlich wären. Sicherlich gibt es bei der Einführung neues Software immer Situationen, in denen Fehler auftreten, die zuvor trotz intensiver Tests nicht entdeckt worden sind. Aber wie kann es kommen, dass durch die Umstellung auf eine neue Software ein ganzes Unternehmen ins Schleudern gerät.

Wenn ein Einzelner über Jahrzehnte eine Software betreut

Ein Satz im FAZ-Bericht gibt einen interessanten Hinweis. Dort heißt es:

Während aber die alte IT auf Cobol-Basis von einem einzigen Mitarbeiter am Laufen gehalten wurde, hakt es jetzt an allen Ecken und Enden

Was so klingt, als sei die alte Software um vieles besser gewesen als das neue System, verweist in Wirklichkeit darauf, dass die Probleme womöglich eher in der Vergangenheit liegen. Oft werden nämlich in Unternehmen tatsächlich individuelle Lösungen von einzelnen Experten über Jahrzehnte gepflegt, erweitert, verändert, ergänzt. Auf Zuruf und oft dringend wird immer wieder an einzelnen Modulen programmiert, werden Algorithmen für spezielle Fälle angepasst, wird hier und da noch eine Besonderheit eingebaut.

Es entsteht ein unübersichtliches System, von dem niemand mehr weiß, was es wirklich tut, was davon überhaupt noch gebraucht wird und unter welchen besonderen Umständen welche spezielle Bedingung zu einem einzelnen Ergebnis führt. Am Ende weiß jeder nur: Es läuft irgendwie, und so, wie es läuft, ist es auch gewollt.

Solche Systeme sind nur selten dokumentiert, die Geschäftsanforderungen stehen nirgends als im Programmcode, keiner weiß noch, welche Anforderungen wann zu welcher Funktion beigetragen haben.

Wenn ein neues System spezifiziert wird

Leider erinnert sich auch keiner an diese vielen Einzelfälle und Besonderheiten, wenn es an die Anforderungsanalyse für das neue System geht. Da werden oft nur die Standardfälle beschrieben, die vielen Ausnahmen werden eher zufällig aufgeführt. Dass der alltägliche Geschäftsprozess vor allem aus Ausnahmen besteht, will da nur selten jemand wahrhaben. Es herrscht das Prinzip Hoffnung: Wenn wir das neue System erst mal haben, gibt es diese Ausnahmen vielleicht auch nicht mehr.

Die Ernüchterung folgt in der Praxis, wenn die gewohnten, optimierten und vertrauten Geschäftsprozesse auf die neue Software treffen, die von all den Ausnahmen nichts weiß. Dann fällt den Mitarbeitern plötzlich auf, dass in diesem speziellen Fall ja jene Ausnahmebedingung gilt, dass man ja vor Jahren den einzigen Programmierer gebeten hatte, in der Situation die Schnittstelle so anzupassen, dass jenes Feld ja manchmal doch einen anderen Wert enthalten kann usw. usf.

Gerade für Altsysteme endlich ein Anforderungsmanagement einrichten

Ob die Probleme bei Liqui Moly von dieser Art sind, weiß ich nicht. Aber die Geschichte sollte jedem, der mit jahrzehntealten “gewachsenen” Software-Lösungen arbeitet, eine Lehre sein: Endlich ein Anforderungsmanagement einzurichten, das möglichst auch rückwirkend alle Spezialfälle, Besonderheiten, Anpassungen, Änderungen und Erweiterungen am System Stück für Stück dokumentiert. Auf dieser Basis kann man bei der Einführung einer neuen Lösung dann zweierlei machen:

1. Vollständige Anforderungsdokumentationen für die neue Software erstellen
2. Für Spezialfälle, die von der neuen Software nicht abgedeckt werden, rechtzeitig Änderungen in den Geschäftsprozessen vornehmen.

Und dann klappt es auch mit der neuen Software.

Der Beitrag Macht neue Software alles schlimmer? erschien zuerst auf INDAL Software-Spezialist.

Checkliste Web-App vs. Native App

Die folgenden Fragen sollen helfen, die richtige Entscheidung zwischen Web-App und nativer App zu treffen. Dabei sind die Empfehlungen, die aus den Antworten folgen, oft nicht eindeutig. Am Ende ist eine Zusammenschau nötig, wenn nicht irgendeine der Fragen zu einem KO-Kriterium für die eine oder die andere Technologie wird. Beginnen wir mit der komplexesten Frage:

Muss die Arbeit auch ohne ständige Verbindung zum Server möglich sein?

Wenn während der Arbeit ständig Daten vom Server benötigt werden, oder wenn dort ständig Daten abgelegt werden müssen, ist sowohl eine Web-App als auch die native App geeignet. Umgekehrt liegen die Dinge jedoch anders. Soll die App auch im Funkloch, also ohne Verbindung zum Internet funktionieren, ist zunächst die native App zu bevorzugen. Sie kann quasi unbegrenzt Daten lokal speichern und lässt sich natürlich, einmal installiert, auch ohne Netzverbindung aufrufen. Wenn die Serververbindung wieder steht, werden die Daten einfach übertragen. Gute Beispiele sind hier die Apps der Social-Media-Netzwerke, die das inzwischen wunderbar können.

Allerdings sind Web-Apps, die auf HTML5 basieren, auch in der Lage, Daten zwischenzuspeichern, sodass auch mit ihnen eine Weiterarbeit ohne Internetverbindung in gewissem Umfang möglich ist.

Beispiel: INDAL hat eine Web-App zur Kontrolle von Messtationen entwickelt, die oft an Orten ohne stabile Internet-Verbindung stehen. Bevor der Kontrolleur die Station aufruft, lädt er die Daten, dann gibt er vor Ort die aktuellen Werte ein – wenn die Internet-Verbindung wieder da ist, werden diese übertragen.

Wenn ohnehin ständig auf Daten aus dem Netz zugegriffen werden muss, spielt dieses Kriterium keine Rolle – dann sind Web-App und native App gleich gut geeignet.

Wird die Hardware des Smartphones oder Tablets benötigt?

Benötigt die Anwendung Zugriff auf Kamera, Mikrofon, Geo-Lokalisierung, Beschleunigungssensor und andere Teile der Hardware des Smartphones oder Tablets? In diesem Fall ist die native App zu bevorzugen. Mit ihr kann optimal auf diese Komponenten zugegriffen werden.

Allerdings ist es nicht so, dass eine Web-App da völlig “machtlos wäre”. Das Fotografieren oder das Ermitteln der aktuellen Position etwa ist auch von einer mobilen Webseite aus möglich. Hier muss man also genau untersuchen, was man braucht.

Müssen verschiedene Plattformen (iOS, Android) unterstützt werden?

Wenn man überhaupt nicht weiß, ob der Benutzer mit einem iPhone oder einem Android-Smartphone unterwegs ist, dann muss für jede Plattform eine gesonderte native App erstellt werden. Das macht die Sache teuer, zumal man die App dann auch noch via App-Store bereitstellen muss (in jedem Fall bei iOS, bei Android ist das nicht zwingend nötig). Will man diese Kosten sparen, bleibt nur die universelle Web-App – die natürlich auch in den verschiedenen Browsern, die auf den Smartphones und Tablets installiert sein können (Opera, Safari, Google Chrome), ausgiebig getestet werden müssen.

Allerdings ist es gerade bei Business-Anwendungen möglich, genau festzulegen, auf welchem Endgerät die App zum Einsatz kommt. Dann muss nur für diese Plattform entwickelt werden.

Beispiel: INDAL hat die eigene Projektzeitererfassung als Android-App entwickelt. Wer ein Android-Smartphone oder Tablet hat, kann diese nutzen, die anderen Mitarbeiter nutzen die Web-App.

Weiteres Beispiel: Für einen Kunden, dessen Vertriebsmitarbeiter eine Vielzahl von Verkaufs- und Vertragsdaten immer dabei haben wollen, wurde eine Android-App entwickelt. Die Vertriebsmitarbeiter wurden mit den passenden Geräten ausgestattet. Die Daten laden sie sich rechtzeitig vor dem Kundenbesuch auf das Tablet – so benötigen sie während des Gesprächs keine Internet-Verbindung.

Fazit

Es gibt noch einige weitere Fragen, aber die obigen drei helfen am besten bei der Entscheidung, ob eine Web-App oder eine native App für eine Business-Anwendung die richtige Lösung ist. Auf beiden Wegen ist es möglich, leistungsstarke Anwendungen für Geschäftsprozesse zu implementieren.

Weitere Informationen zur Entwicklung von Android-Apps bei INDAL finden Sie hier.

Der Beitrag Mobile Geschäftsanwendungen – Web-App oder native App erschien zuerst auf INDAL Software-Spezialist.

Aus der Erfahrung von fast 25 Jahren individueller Softwareprojekte kann ich sagen, dass dieses Thema von vielen Auftraggebern unterschätzt wird. Dabei gibt es in jeder Phase des Projekts Datenschutzrelevante Herausforderungen.

Es genügt nicht, eine Geheimhaltungsvereinbarung zu unterschreiben

Viele meinen, es sei mit einer schriftlichen Vereinbarung getan, in der sich der Software-Dienstleister verpflichtet, mit den Daten, die er vom Kunden erhält, ordentlich umzugehen. Hier werden oft seitenlange Standardverträge unterschrieben – und auf der Basis glaubt man dann, im Projekt alle möglichen Echtdaten verwenden zu können. Aber so einfach ist das nicht. Denn eine Vereinbarung zwischen Softwareentwickler und Auftraggeber erlaubt es beiden noch lange nicht, Daten von Kunden, Lieferanten und Mitarbeitern des Auftraggebers im Projekt zu verwenden. Außerdem ist es ohnehin besser, dass solche Daten gar nicht erst im Projekt auftauchen, als dass man sich darüber verständigt, aufpassen zu wollen, dass diese Daten nicht „in falsche Hände geraten können“.

Deshalb sollten sich Softwarehaus und Auftraggeber gleich zu Beginn des Projekts darüber verständigen, wie die notwendigen Informationen bereitgestellt werden können, ohne dass Echtdaten im Projekt verwendet werden. Das kostet Aufwand und der muss im Budget und im Zeitplan berücksichtigt werden – aber unterm Strich tut man das Richtige.

Genau genommen muss das Thema aber schon beachtet werden, bevor überhaupt ein Vertrag unterschrieben wird. Wenn der Kunde dem Lieferanten beschreiben will, was er überhaupt mit dem Projekt erreichen will, braucht er Beispiele: Dokumente, die gegenwärtig verwendet werden, Listen, die verarbeitet werden sollen, und so weiter. Überall sind Daten von Kunden und Mitarbeitern zu sehen. Oft werden diese Informationen dem (potentiellen) Vertragspartner schon im ersten Gespräch vorgelegt oder zum Zwecke des besseren Verständnisses des Themas übermittelt.

Jedem sollte klar sein, dass ein solcher Umgang mit Daten nicht in Ordnung sein kann, selbst wenn der potentielle Dienstleister zuvor eine Erklärung unterschrieben hat in der er sich verpflichtet, die übergebenen Daten geheim zu halten. Also muss schon vor Vertragsschluss ein gewisser Aufwand getrieben werden, Daten zu anonymisieren und unkenntlich zu machen.

Datenschutz während der Anforderungsanalyse und der Software-Spezifikation

Oft werden für die Anforderungsanalyse und die Softwarespezifikation realistische Beispieldaten gebraucht, sei es in Form von Dokumenten, die durch das System später erzeugt werden sollen, Screenshots von Systemen, die bereits mit den Daten arbeiten, oder Listen und Berichten, die die benötigten Daten enthalten. Es führt kein Weg daran vorbei: Diese Daten müssen anonymisiert werden. Das muss natürlich auf eine Weise geschehen, dass wichtige Informationen für die Softwarespezifikation nicht verloren gehen – und deshalb ist die Sache auch hin und wieder aufwändig. Nur selten wird der Aufwand, der hier getrieben werden muss, in das Zeit- und Kostenbudget dieser Projektphase eingeplant.

Natürlich kann ein professioneller Software-Dienstleister bei der Anonymisierung der Daten unterstützen. Wie werden Namen und Adressen unkenntlich gemacht, ohne dass die Information verschwindet, um was für Daten es sich handelt? Darin hat ein Softwarehaus natürlich Erfahrungen.

Test mit produktionsnahen Daten – Anonymisierung ist nötig

Dies umso mehr, als sich der Aufwand ja lohnt, denn für die Testphase des Projekts werden ohnehin produktionsnahe Daten gebraucht – also muss man Wege finden, Echtdaten zu anonymisieren. Ein Konzept zur Bereitstellung von Testdaten sollte ohnehin schon in der Spezifikationsphase entstehen. In dieses Konzept muss das Thema Anonymisierung und Pseudonomisierung mit einbezogen werden. Meistens lohnt es sich, dafür ein paar automatische Routinen zu schreiben, denn für die Tests werden Testdatensets mit unterschiedlichem Umfang und Ausprägungen benötigt.

Ob für die endgültigen Abnahmetests Echtdaten verwendet werden können, hängt vom Einzelfall ab – wie wird wo getestet, wer hat Zugriff auf die Ergebnisse, und wie wichtig ist die Erkennbarkeit von „echten Daten“ im Fachtest? Immer, wenn Testergebnisse an den Lieferanten übergeben werden, müssen diese aber anonymisiert sein – somit ist fraglich, ob es sinnvoll ist, mit Echtdaten zu arbeiten.

Ein weiterer Aspekt, der mit dem Datenschutz im Sinne der DSGVO wenig zu tun hat, ist der Schutz von Geschäftsgeheimnissen. Wer in Softwareprojekten, vor allem in Tests, mit anonymisierten oder pseudonomisierten Echtdaten arbeitet, muss sich darüber im Klaren sein, dass die Daten hinsichtlich der Geschäftsvorfälle immer noch „echt“ sind – Umsatzzahlen, Produktinformationen oder Geschäftsstrukturen lassen sich daraus immer noch ableiten. Natürlich sollten Kunde und Lieferant einander vertrauen, aber manchmal geraten solche Daten auch durch Unachtsamkeit in falsche Hände. Ein Bewusstsein für die Vertraulichkeit solcher Daten immer wieder zu schaffen, sollte selbstverständliche Aufgabe von Management und Projektleitung sein.

Der Beitrag Wie organisiert man Datenschutz im Softwareprojekt erschien zuerst auf INDAL Software-Spezialist.

So weit – so gut. Aber als Geschäftsführer dieses Unternehmens, der gleichzeitig Philosoph ist, kann ich bei dieser etwas oberflächlichen Betrachtung nicht stehenbleiben.

Digital, das bedeutete bekanntlich ursprünglich: Ja oder Nein, Wahr oder Falsch, 1 oder 0. Wir wissen, dass irgendwo tief in den Computern, mit denen wir die Digitalisierung vorantreiben, immer noch das elektronische Schaltprinzip und die einfache mathematische Logik des Ja-oder-Nein gilt. Aber darüber sind viele Schichten von Software gelegt, und an der Benutzeroberfläche, so scheint es, ist nichts mehr digital: Da gibt es Nachkommastellen, Texte, Bilder, viele mögliche Werte.

“Digitalisierung” – das scheint nur noch ein Wort zu sein, ein Synonym für “Computernutzung” oder “Vernetzung im Internet”, und scheint nichts mehr mit der ursprünglichen Bedeutung zu tun zu haben. Aber dieser erste Eindruck trügt, das merkt man immer, wenn man bei der Anforderungsanalyse und der Softwarespezifikation etwas genauer hinschaut. Noch immer treffen wir da wichtige Ja-Nein-Entscheidungen, und noch immer müssen wir uns ständig zwischen Wahr und Falsch entscheiden.

Digitalisierung von Geschäftsprozessen, das müssen wir zunächst mal ganz klar eingestehen, bedeutet, die unendliche Vielgestaltigkeit der realen Vorgehensweisen und Abläufe auf ein paar Standard-Prozesse abzubilden, Ausnahmen zu verbieten, Normen zu setzen.

Das hat viele Vorteile. So kann man verlangen, dass wichtige Stammdaten von Kunden bereits am Anfang eines Bestellprozesses angelegt werden. Damit ist man sicher, dass die Daten auf jeden Fall im System sind, wenn sie gebraucht werden.

Auf der anderen Seite, das hat wohl schon fast jeder erlebt, ist man auf diese Weise den eingeschränkten Optionen der Software ohnmächtig ausgeliefert, ob man der Benutzer oder der Betroffene ist. Digitalisierung bedeutet, eben auch “Alles oder nichts”. Mal etwas kurz am Rand notieren, ein Wort dahin schreiben, wo eine Zahl hingehört, etwas schon mal aufnehmen oder halbfertig beiseite legen, all das ist nach der Digitalisierung oft nicht mehr möglich.

Wir müssen die Rede von der Digitalisierung ganz wörtlich nehmen, und die Konsequenzen im konkreten Fall ehrlich und offen beurteilen. Nur so ist es möglich, die Chancen zu nutzen und die Risiken zu beherrschen. In einer digitalen Welt, in der es nur noch Schwarz und Weiß, aber kein Grau und schon gar kein Regenbogenspektrum mehr gibt, will ja dann doch niemand leben. Wir müssen unsere Software so gestalten, dass sie mehr erlaubt als verbietet.

Der Beitrag Geschäftsprozesse digitalisieren – Chancen und Risiken erschien zuerst auf INDAL Software-Spezialist.

Jede Entscheidung während des Entwurfs und der Programmierung einer Software ist eine Spekulation über die Zukunft.

Weiterlesen auf heise Developer

Der Beitrag Über spekulierende Softwareentwickler erschien zuerst auf INDAL Software-Spezialist.

Weiterlesen bei heise Developer

Der Beitrag Große Kategorien oder kleine Differenzen erschien zuerst auf INDAL Software-Spezialist.

Der Prototyp sollte einen Durchstich durch alle Schichten der Anwendung realisieren, somit etwa das Lesen und Schreiben von Daten, die Businesslogik und die Oberfläche umfassen. Allerdings muss hier genauer hingesehen werden. Wenn z.B. die GUI verschiedene Typen von Funktionen umfasst, sollte jeder Typ im Prototypen repräsentiert sein, Masken ebenso wie die Programmsteuerung und Reports. Das Gleiche gilt für die anderen Schichten der Anwendung.

Der Prototyp soll zeigen, wie die Migration erfolgen kann, und das betrifft zweierlei:

1. Wie wird aus den Architekturzusammenhängen der Altanwendung die Architektur der zukünftigen Anwendung? Wenn die Altanwendung z.B. eine Client-Server-Anwendung ist, die in eine Webumgebung migriert werden soll, dann ist damit zumeist auch eine neue Anwendungsarchitektur verbunden. Ein Prototyp ist also immer auch Architekturprototyp.
2. Wie kann der Code der Altanwendung möglichst systematisch (automatisch oder nach engen Programmierrichtlinien) in die neue Architektur übertragen werden? In der Regel ist das mit einem Refactoring der Businesslogik verbunden. Der Prototy sollte es erlauben, strikte Anweisungen für die “Umarbeitung” einer Anwendungsfunktion auf die neue Plattform zu definieren, oder sogar Codegeneratoren zu konzipieren, die aus dem alten Code den neuen erzeugen – wenigstens zum großen Teil.

Schließlich sollte ein Migrationsprototyp möglichst auch ein Oberflächenprototyp sein. An der Oberfläche muss eine Applikationsmigration immer den größten Spagat vollbringen: Einerseits soll der Anwender die vertrauten Funktionen ohne weiteres intuitiv wiederfinden, andererseits hat er zumeinst auch eine Erwartung, wie eine Anwendung in der neuen Umgebung auszusehen hat. Eine PC-Anwendung hat bestimmte typische Oberflächenelemente, die eine Web-Applikation nicht oder anders implementiert – und umgekehrt. Ein Oberflächenprototyp kann zeigen, wie die vertrauten Elemente sich plausibel in der neuen Umgebung wiederfindenlassen – Migration von Anwendungen ist immer ein bisschen so wie behutsame Fassadensanierung, man möchte modernisieren, aber den vertrauten Charme auch bewahren.

Der Beitrag Migrations-Prototypen erschien zuerst auf INDAL Software-Spezialist.

Gut ist, wenn die Entwicklungsaufwände, welche in die Software seit ihres Bestehens geflossen sind, bekannt sind, etwa durch die Stundenerfassung in der Softwareentwicklung. Von der Entwicklung der ersten Version sollte der Aufwand für die Anforderungsanalyse separiert werden. Sodann werden die einzelnen Releases sowie die Wartungsaufwände daraufhin bewertet, zu welchem Anteil sie Neuentwicklung von Funktionalität waren und welcher Anteil Änderungen der bestehenden Software waren. So erhält man eine erste Vorstellung davon, was eine Neuentwicklung der gleichen Anforderungen kosten würde.

Dieser Gesamtaufwand ist in Entwicklungsaufwand und Testaufwand zu separieren. Während der Entwicklungsaufwand im Migrationsprojekt durch Wiederverwendung zum Teil erheblich reduziert werden kann, ist der Testaufwand kaum zu reduzieren. Allenfalls bei der Erstellung von Testfällen kann Aufwand gespart werden, wenn auf bestehende Dokumente zurückgegriffen werden kann.

Im nächsten Schritt widmet man sich dem Thema Wiederverwendbarkeit. Wenn die verwendeten Entwicklungswerkzeuge auf der Zielplattform ebenfalls verwendet werden können, kann man beurteilen, ob Teile des Codes (eventuell nach einem Refactoring) wiederverwendet werden können, das gilt nicht nur für Programmiersprachen, sondern auch für Frameworks, Reportingtools u.a.

Im Allgemeinen ist allerdings das Migrationsprojekt mit einem Versionswechsel bei den Werkzeugen verbunden. Wenn man zu dem Ergebnis kommt, dass z.B. 70% des Codes wiederverwendet werden kann, beträgt die tatsächliche Einsparung in der Entwicklung wahrscheinlich weniger als 50%, abhängig von der Weite des Versionssprungs, der Sauberkeit der Architektur und der Codequalität.

Die ursprünglichen Aufwände der Anforderungsanalyse können nicht vollständig abgezogen werden, da während der verschiedenen Releases oft die Anforderungen nur unvollständig dokumentiert und aktualisiert worden sind. Ein intensiver Review ist geboten, und das Motto “Der Code ist die Dokumentation” führt oft zu lückenhafter oder falscher Umsetzung in der neuen Software.

Alles in allem sind die Aufwände für eine Migration oft höher als erwartet. Es ist gut, eine Top-Down-Schätzung, wie hier kurz skizziert, an den Anfang zu stellen, und gegen eine Bottom-Up-Schätzung, die auf einer Stückliste (Object Points, Function Points o.ä.) basiert, zu verproben. Das zeigt frühzeitig nicht nur, welches Budget, sondern auch, welcher Zeitrahmen für die Migration einzuplanen ist.

Der Beitrag Wie kalkuliert man ein Migrationsprojekt? erschien zuerst auf INDAL Software-Spezialist.

In jedem Fall stellt sich die Frage, wie weit der Anbieter in die fachlichen Details und Geschäftsprozesse des Kunden eindringen sollte. Häufig sagt man, dass es gut und sogar notwendig ist, dass der Softwaredesigner, vielleicht sogar der Entwickler, die betroffenen Vorgänge beim Kunden versteht und seine Ziele, die letztlich die Erfolgskriterien des Projekte sind, nachvollziehen kann. Aber ist das wirklich immer nötig? Und anders herum: reicht das immer aus?

Versteht der Entwickler viel von den Verfahren und Prozessen des Kunden, hat er etwa Branchen-Know-How, dann birgt das durchaus auch Gefahren. Häufig vermutet der Kunde, dass er Details nicht mehr erklären muss, und auch der Entwickler glaubt nach wenigen Hinweisen schon, dass “alles klar” ist. Auf dieses Weise kann es in Details zu Flüchtigkeitsfehlern kommen, die erst im produktiven Betrieb bemerkt werden.

Eine klare Aufgabentrennung, in der der Kunde ein Anforderungsdokument zu erstellen hat, das es nicht erfordert, dass der Entwickler sich überhaupt mit der Fachlichkeit beschäftigt, scheint dann die Lösung zu sein. Allerdings entstehen auf diese Weise selten optimale Lösungen. Die Vorstellungen, die sich der Kunde von der Software macht, sind manches Mal nur mit viel Aufwand umsetzbar, auf der anderen Seite kann der Entwickler aus anderen Projekterfahrungen heraus Lösungen anregen, auf die der Kunde gar nicht kommt. In so einem Moment wird der Entwicklungspartner zum Berater.

Damit eine solche Partnerschaft gelingt, muss sie allerdings richtig strukturiert werden, und auch die Entscheidungs- Verantwortung muss klar definiert sein. Insbesondere muss vertraglich klar geregelt sein, wie sich die Ergebnisse der Beratung auf die Definition der Erfolgskriterien und auf das Projektbudget auswirken, sonst sagen die Projektbeteiligten am Ende: “Die Zusammenarbeit war sehr schön, und wir haben uns gut verstanden – leider ist das Projekt nicht zu einem erfolgreichen Ende gekommen…”

Der Beitrag Wie viel Beratung ist gut? erschien zuerst auf INDAL Software-Spezialist.

Ein Beispiel: In unserer Software SceddyPro werden natürlich auch die Regelungen des Arbeitszeitgesetzes berücksichtigt, und zwar schon in dem Moment, in dem der Benutzer die bevorzugten Schichtmuster vorgibt. Soll die Software nun verbieten, dass Muster definiert werden, in denen die Zeit zwischen zwei Schichten kürzer ist, als nach dem Gesetz erlaubt, oder soll nur eine Warnung angezeigt werden?

Wir haben uns dafür entschieden, dem Benutzer einen Hinweis zu geben, wenn er die gesetzlichen Vorgaben verletzt, ihm jedoch die Entscheidung zu überlassen, ob er streng nach dem Gesetz plant oder nicht.

Die Situation ist mit der eines Autofahrers vergleichbar, dem das Navigationssystem anzeigt, welche maximale Geschwindigkeit zulässig ist. Theoretisch wäre es denkbar, dass das System unmittelbar dafür sorgt, dass diese Vorschrift auch eingehalten wird. Auch wenn eine solche technische Lösung von manchem gewünscht wird, lehnen die meisten Fahrer sie ab. Einerseits trauen wir der Technik nicht zu, für jede Veränderung der konkreten lokalen Verkehrsvorschriften immer die aktuellen Daten ins Auto übertragen zu können, ganz davon abgesehen, dass das Navigationsystem auch Fehler machen kann. Andererseits kann es Ausnahmesituationen geben, in denen wir selbst entscheiden müssen, welche Geschwindigkeit wir fahren müssen.

So ist es auch im Fall einer Personaleinsatzplanungslösung wie SceddyPro. Einerseits ist trotz Softwarewartung und Aktualisierungsservice nicht sicher, ob die Software jeden Fall und jede Veränderung der Regelungen sofort enthalten kann. Andererseits, und das ist noch wichtiger, muss der Planer selbst in jedem Moment entscheiden können, wie er das Personal plant. Für die Einhaltung der Vorschriften ist er verantwortlich, und wie er dieser Verantwortung gerecht wird, muss er auch selbst entscheiden.

Zurück zu obigem Beispiel: ein Mitarbeiter wird für die Spätschicht und die Frühschicht am Tag darauf eingeplant. Die Ruhezeit dazwischen entspricht nicht den Vorschriften.  Der Planer vereinbart mit dem Mitarbeiter deshalb, dass er die Spätschicht etwas früher verlässt und etwas später zur Frühschicht kommt und dann entsprechend länger bleibt. Damit wird die Regelung eingehalten, das aber bei der Planung im System schon zu berücksichtigen, würde einen großen Aufwand bedeuten.

Zumeist ist, so zeigt sich an diesem Bispiel, eine Softwarelösung dann der praktischen Situation am besten angemessen, wenn sie dem Benutzer die Entscheidung über die konkrete Regeleinhaltung überlässt. Denn gearbeitet wird nicht in der Software, sondern am tatsächlichen Arbeitsplatz, und da passiert manches, was sich unsere Softwareweisheit kaum träumen lässt.

Der Beitrag Verbieten oder Warnen? erschien zuerst auf INDAL Software-Spezialist.