Soziotechnisches Lastenheft

Was ist das?

Lastenhefte sind ein Medium zur Beschreibung von Anforderungen an ein zu entwickelndes digitales (Unterstützungs-)System. Diese nach Kriterien strukturierte Anforderungsliste wird mit dem Entwickler abgestimmt, der seine Umsetzungsschritte in einem Pflichtenheft an den Auftraggeber zurücksendet. Lastenhefte beschreiben relativ umfassend technische Voraussetzungen, Zielsetzungen und Rahmenbedingungen, die bei der Entwicklung zu berücksichtigen sind. Soziotechnische Lastenhefte erweitern die ingenieurwissenschaftlich geprägten Kernkomponenten um einen „sozialen” Aspekt: Sie bedienen sich der Grundgedanken des soziotechnischen Systems. Dazu gehören die Arbeitenden mit ihren individuellen Qualifikationen und ihren individuellen und gruppenbezogenen Bedürfnissen.

Was soll erreicht werden?

Soziotechnische Lastenhefte bedienen sich der Grundgedanken des soziotechnischen Systems. Dieser Begriff beschreibt, dass Arbeitssysteme aus mindestens zwei Teilsystemen bestehen – einem sozialen und einem technischen System (vergleiche Ulich 2005, S. 194 ff.). Während die Anforderungen an das technische Teilsystem mit Hilfe herkömmlicher Lastenhefte vergleichsweise gut beschrieben werden können, werden die sozialen Vorbedingungen und Auswirkungen der Systementwicklung hierbei nicht berücksichtigt. An dieser Stelle setzt die Ergänzung des „herkömmlichen” Lastenhefts um die soziotechnische Komponente an, um Vorerfahrungen, Expertenwissen, Anforderungen und Wünsche der zukünftigen Systemnutzer besser zu berücksichtigen und in die Anforderungsdefinition einfließen zu lassen.

Die Erstellung soziotechnischer Lastenhefte bietet sich insbesondere dort an, wo Auswirkungen technischer Innovationen mit Veränderungen der Arbeitsaufgabe einhergehen können. Bei Digitalisierungsvorhaben im Produktionsbereich ist das nahezu immer der Fall.

Wer macht das?

Ein soziotechnisches Lastenheft wird von projektverantwortlichen Mitgliedern des Kern- oder Projektteams initiiert und vorbereitet. Es können auch Führungskräfte beziehungsweise das Führungsteam des Bereichs beteiligt sein, in dem das Unterstützungssystem zum Einsatz kommen soll. Unbedingt einzubeziehen sind die Beschäftigten dieses Bereiches. Darüber hinaus können auch Unternehmensexterne, beispielsweise Lieferanten oder – wie im APRODI-Projekt – Forschende aus den beteiligten Instituten, mitwirken.

Wie macht man das?

Voraussetzungen

Voraussetzung ist die Erhebung von Anforderungen mit einer partizipativen Methode. Interviews der verantwortlichen Führungskräfte über das einzuführende System sind ein guter und notwendiger Einstieg. Die Sicht der Mitarbeitenden sollte aber in jedem Fall zusätzlich einbezogen werden. Beobachtungsinterviews sind eine sinnvolle Methode hierfür. Mit ihnen können Situationen im Handlungsablauf identifiziert werden, in denen das System unterstützen kann. Die Ergebnisse der Beobachtungsinterviews können dann als Grundlage für die Anforderungsdefinition dienen.

Gleichzeitig ist im soziotechnischen Lastenheft das betriebliche Zielsystem zu beschreiben, das von dem zu entwickelnden (Unterstützungs-)System betroffen sein wird. Jede Veränderung des bestehenden Arbeitssystems findet in einem Spannungsfeld statt. Dieses besteht im besten Fall aus sich stimmig ergänzenden Anforderungen – in der Regel widersprechen sich die Anforderungen aber zumindest teilweise. Das Bewusstsein darüber muss vorhanden sein. Denn einander widersprechende Anforderungen müssen unter Beteiligung der Interessengruppen gegeneinander abgewogen werden.

Methode

Die Schritte des Handlungsablaufs, die bereits in der vorgelagerten Erhebung identifiziert wurden, werden in tabellarischer Form aufgeschrieben. Jedem Vorgang werden Besonderheiten zugeordnet, die sich aus dem Handlungsablauf ergeben und die beim Entwickeln der Lösung zu berücksichtigen sind. Im nächsten Schritt werden die Anforderungen an die Lösungsentwicklung beschrieben – orientiert am Zielsystem. Daraus lassen sich vier Typen von Anforderungen unterscheiden:

• Handlungsbezogene Anforderungen: Wie kann das zu entwickelnde System die Zielgruppe in ihren Handlungsabläufen unterstützen?
• Organisationsbezogene Anforderungen: Wie kann die Arbeitsorganisation der Einheit unterstützt werden, in der der betrachtete Beschäftigte tätig ist (Team, Gruppe, Abteilung etc.)?
• Technikbezogene Anforderungen: Welche Schnittstellen zu weiteren IT-Systemen (zum Beispiel Management Executive Systems oder ERP-Systeme wie SAP) müssen bedacht werden?
• Umfeldbezogene Anforderungen: Welche Regularien sind von dem System betroffen? Wie kann die Einhaltung von Vorgaben sichergestellt werden?

Abschließend werden klärungsbedürftige Punkte notiert.

Nachdem die offenen Punkte geklärt sind und die Anforderungen weiter geschärft wurden, kann eine Priorisierung der Anforderungen in Muss-, Soll- und Kann-Kriterien stattfinden. Das dient der Vergewisserung, welche Funktionalitäten des Systems unabdingbar sind und wo Verhandlungsspielraum mit dem zu beauftragenden Entwickler besteht.

Ausblick

In der klassischen Softwareentwicklung werden häufig Kriteriensysteme genutzt, die eine vergleichsweise exakte Beschreibung der Anforderungen nahelegen (zum Beispiel ANSI IEEE 830, IEEE 29148-2011). Alternativ – und dieser Weg soll mit dem soziotechnischen Lastenheft beschritten werden – lassen sich Anforderungen auch in agiler Weise beschreiben:

• Anstelle einer zeitintensiven vollständigen Beschreibung der Anforderungen sollen diejenigen Funktionalitäten beschrieben werden, die zum gegenwärtigen Zeitpunkt bekannt sind – im Wissen, dass sich Anforderungen im Laufe eines Entwicklungsprozesses ändern können.
• Die Formulierungen sollen sich an den Anwendern orientieren. Dazu bietet sich ein Vorgehen mit Hilfe sogenannter User Stories an: Man definiert Rollen, aus denen heraus die Anforderungen der jeweiligen Zielgruppe des Systems beschrieben werden. Dabei gilt das Format „Als «Rolle» möchte ich «Ziel», um «Nutzen». In der Praxis könnte eine User Story so aussehen: „Als Werker möchte ich eine Hilfestellung für den Montageablauf von Produkten, die ich noch nie montiert habe, um Produkte schneller und flexibler montieren zu können.”
• Statt Funktionalitäten nach Wichtigkeit und/oder Stabilität zu bewerten, werden sie nach ökonomischem Nutzen und Risiko priorisiert.