image
Betriebliches
Datenmanagement und FMIS
Schriftenreihe, Heft 4/2022

Machbarkeitsstudie
für „Betriebliches Datenmanagement und
Farm-Management-Information-System
(FMIS)“
in sächsischen Landwirtschaftsbetrieben
Berichtsautoren:
Jens Henningsen, Thomas Herlitzius, Thomas Jeswein, Daniel Martini
Philipp Neuschwander, Bernd Rauch, Nils Reinosch, Simon André Scherr, Jan Ole Schroers,
Liv Seuring, Benjamin Striller
Projektleitung
:
Thomas Herlitzius
TU Dresden, Institut für Naturstofftechnik
Professur für Agrarsystemtechnik (AST)
unter Mitarbeit von
Mario Marsch, Tobias Pohl, Nikolaus Staemmler & Klaus Wallrabe
Projektidee und Forschungsprojekt
des Sächsischen Landesamtes für Umwelt, Landwirtschaft und Geologie
Einen besonderen Dank an die gesamte Arbeitsgruppe sowie die beteiligten Landwirtschafts-
und Softwareunternehmen für die vielen wertvollen Anregungen und Diskussionen,
die wesentlich zum Gelingen der Studie beigetragen haben.

Inhaltsverzeichnis
Abstract
........................................................................................................................................ 6
1
Einleitung ....................................................................................................................... 9
1.1
Ausgangssituation in der sächsischen Landwirtschaft ..................................................... 9
1.2
Ziele und Aufgabenstellung der Studie .......................................................................... 10
1.3
Bereitgestellte Materialien ............................................................................................. 11
2
Ausgangslage und Hintergründe ............................................................................... 12
2.1
Landwirtschaftliche Prozesse und Daten ....................................................................... 12
2.1.1
Prozesse ....................................................................................................................... 12
2.1.2
Daten ............................................................................................................................ 15
2.2
Softwaresysteme im landwirtschaftlichen Kontext ......................................................... 25
2.2.1
Katalog Fachsoftware .................................................................................................... 27
2.2.2
Ansätze aus Industrie und Forschung ........................................................................... 36
2.2.3
IT-Infrastruktur ............................................................................................................... 49
2.3
Definitionen und Kernkonzepte ...................................................................................... 53
2.3.1
FMIS ............................................................................................................................. 53
2.3.2
Interoperabilität & Medienbrüche ................................................................................... 54
2.3.3
Datensouveränität ......................................................................................................... 62
3
Wesentliche Ergebnisse ............................................................................................. 67
3.1
Landwirtschaftliche Produktions- und Managementprozesse ........................................ 67
3.1.1
Produktionsverfahrensübersichten ................................................................................ 67
3.1.2
Prozessmodell Düngeprozess ....................................................................................... 69
3.1.3
Ableitung von Prozessklassen ....................................................................................... 73
3.1.4
Prozessmodelle für weitere Prozessklassen .................................................................. 74
3.2
Exemplarische Zielgrößen ............................................................................................. 75
3.2.1
Zusammenhänge .......................................................................................................... 76
3.2.2
Arbeitsproduktivität ........................................................................................................ 77
3.2.3
Betriebszweigauswertung .............................................................................................. 78
3.2.4
Eigenkapitalrentabilität .................................................................................................. 79
3.2.5
Gewinnschwelle ............................................................................................................ 80
3.2.6
Kontostand .................................................................................................................... 81
3.2.7
Kosten- und Leistungsrechnung .................................................................................... 81
3.2.8
Kostentreiber ................................................................................................................. 86
3.2.9
Liquidität ........................................................................................................................ 87
3.2.10
Maschinenparkauswertung ............................................................................................ 89
3.2.11
Vollkosten (je Produkteinheit/je Schlag)......................................................................... 90
3.2.12
Datenverfügbarkeit und Schnittstellen ........................................................................... 93
3.3
Betriebliches Datenmanagement ................................................................................... 98
3.3.1
Konzepte und Hintergründe zum betrieblichen Datenmanagement ............................... 99
3.3.2
Anforderungen an ein betriebliches Datenmanagement .............................................. 109
3.3.3
Fachgespräche mit Softwareanbietern ........................................................................ 111
3.3.4
Lösungsansätze für ein betriebliches Datenmanagement ............................................ 120
3.3.5
Kosten im Kontext betrieblichen Datenmanagements .................................................. 128

3.3.6
Zusammenfassung und Ausblick ................................................................................. 130
3.4
Gesamtbetriebliches FMIS .......................................................................................... 132
3.4.1
Definition und Zielsetzung des FMIS im gesamtbetrieblichen Kontext ......................... 132
3.4.2
Anforderungen an ein FMIS im Rahmen dieser Studie ................................................ 132
3.4.3
Grundlegendes Konzept .............................................................................................. 134
3.4.4
Fachkonzept ................................................................................................................ 135
3.4.5
Evaluierung Fachkonzept ............................................................................................ 142
3.4.6
Technisches Konzept .................................................................................................. 146
3.4.7
Eingrenzung erwartbarer Aufwände ............................................................................ 154
3.4.8
Organisatorisches Konzept .......................................................................................... 160
3.4.9
Konkretisierung durch Pilotierung ................................................................................ 164
3.4.10
Zusammenfassung und Ausblick ................................................................................. 167
3.5
Zusammenfassung und mögliche nächste Schritte ...................................................... 168
3.5.1
Zusammenfassung der Ergebnisse ............................................................................. 168
3.5.2
Ausblick und mögliche nächste Schritte....................................................................... 172
3.6
Handlungsempfehlungen ............................................................................................. 174
3.6.1
Empfehlungen für Landwirte ........................................................................................ 174
3.6.2
Empfehlungen für Behörden, beratende Stellen und landwirtschaftliche
Interessensverbände ................................................................................................... 175
3.6.3
Empfehlungen für Softwareanbieter ............................................................................ 178
4
Zusammenfassung .................................................................................................... 180
5
Glossar ....................................................................................................................... 182
Anhang
.................................................................................................................................... 184
Anhang 1
Informationsblätter ....................................................................................................... 184
Anhang 1.1
Datensouveränität ....................................................................................................... 184
Anhang 1.2
Medienbrüche.............................................................................................................. 184
Anhang 1.3
Cloudbasierte Software ............................................................................................... 184
Anhang 1.4
Datenmanagementvarianten ....................................................................................... 184
Anhang 1.5
Prozesszyklus zur Verbesserung des betrieblichen Datenmanagements .................... 184
Anhang 2
Digitaler Anhang .......................................................................................................... 185
Anhang 2.1
Datenkatalog auf Attributebene für die Data Dictionaries von ISO11783 und ADED ... 185
Anhang 2.2
Katalog landwirtschaftlicher Softwareanwendungen .................................................... 185
Anhang 2.3
Produktionsverfahrensübersichten .............................................................................. 185
Anhang 2.4
Grafische Darstellungen exemplarischer Produktionsprozesse ................................... 185
Anhang 2.5
FMIS-Oberflächen ....................................................................................................... 185

Abbildungsverzeichnis
Abbildung 1:
Regionale Acker- und Grünlandverteilung in Sachsen (Agrarstatus Sachsen) .............. 13
Abbildung 2:
Betriebsgrößenverteilung und Flächenanteile in Sachsen (Agrarstatus Sachsen) ......... 14
Abbildung 3
Beispielhafte Darstellung von Datenarten, Datenquellen und Datennutzen in
landwirtschaftlichen Prozessen ..................................................................................... 16
Abbildung 4:
Zusammenhang Datenstrukturdefinition und Daten für Individuen auf dem Betrieb ...... 18
Abbildung 5:
Beispielhafte betriebliche Softwarelandschaft für einen Gemischtbetrieb ...................... 26
Abbildung 6:
Gegenüberstellung von HBCI/FinTS und PSD2-Schnittstelle ........................................ 35
Abbildung 7:
Überblick ADAPT (rote Pfeile Datenimport von einer Maschine,
blaue Pfeile Datentransfer von FMIS A zu FMIS B) ....................................................... 37
Abbildung 8:
Überblick Agri-Gaia ....................................................................................................... 38
Abbildung 9:
Überblick ATLAS-Netzwerk ........................................................................................... 39
Abbildung 10: Überblick der DEMETER-Referenzarchitektur .............................................................. 40
Abbildung 11: GeoBox-Infrastruktur ..................................................................................................... 43
Abbildung 12: Überblick Architektur in SDSD ...................................................................................... 44
Abbildung 13: Referenz Architektur FIWARE ....................................................................................... 45
Abbildung 14: Beispielhafte Darstellung des ADS mit verschiedenen digitalen Plattformen
und Datenhubs für digitale Zwillinge .............................................................................. 46
Abbildung 15: Zusammenspiel der Nevonex-Partner ........................................................................... 47
Abbildung 16:
Auszug SEGES Dashboard
68
........................................................................................ 49
Abbildung 17: Darstellungsschema Produktionsverfahren ................................................................... 68
Abbildung 18: Schema beteiligte ISOBUS Device Classes .................................................................. 69
Abbildung 19: Prozessklassifizierung................................................................................................... 74
Abbildung 20: Zusammenhänge zwischen Zielgrößen ......................................................................... 76
Abbildung 21: Ökonomische Erfolgsgrößen der Kostenleistungsrechnung .......................................... 85
Abbildung 22: Kostengliederung .......................................................................................................... 92
Abbildung 23: Vereinfachte Darstellung der Funktion eines betrieblichen Datenmanagements
als Mittler zwischen Softwaresystemen ....................................................................... 100
Abbildung 24: Das horizontale Datenmanagement hat die Aufgabe, betrieblich genutzte Soft-
waresysteme miteinander zu verbinden ...................................................................... 101
Abbildung 25: Das vertikale Datenmanagement hat die Aufgabe, Dateninformationen aus betrieb-
lich genutzten Softwaresystemen dem gesamtbetrieblichen FMIS bereitzustellen ...... 102
Abbildung 26: Bilaterale Schnittstellen ............................................................................................... 105
Abbildung 27: Datenrouter ................................................................................................................. 106
Abbildung 28: Datenhub .................................................................................................................... 108
Abbildung 29: Hybrides Datenmanagement....................................................................................... 109
Abbildung 30: Beispielhaftes hybrides Szenario mit verschiedenen Datenmanagementansätzen
in Kombination ............................................................................................................ 123
Abbildung 31: Manuelle Übertragung von Daten zwischen zwei Systemen ....................................... 125
Abbildung 32: Automatische Übertragung von Daten zwischen zwei Systemen ................................ 126
Abbildung 33: Ausschnitt eines realen Düngeprozesses (vgl. Abschnitt 3.1.2) .................................. 126
Abbildung 34: Startseite des FMIS aus der Sicht eines Betriebsleitenden ......................................... 137
Abbildung 35: Gewinn über die Zeit für den Gesamtbetrieb mit Darstellung der IST-Werte
in orange sowie der prognostizierten Daten in beige................................................... 138
Abbildung 36: Anbauverhältnisse sowie Arbeitsproduktivität im Pflanzenbau .................................... 138

Abbildung 37: Durchgeführte Kosten- und Leistungsrechnung für eine Fruchtart .............................. 139
Abbildung 38: Übersicht über gestellte und offene Rechnungen ........................................................ 140
Abbildung 39: Übersicht über die letzten Buchungen ......................................................................... 140
Abbildung 40: Übersicht über den gesamten Maschinenpark ............................................................ 141
Abbildung 41: Übersicht über die Kalenderfunktion des FMIS ........................................................... 142
Abbildung 42
Potentiell einbezogene Quellsysteme je Zielgröße ...................................................... 147
Abbildung 43: Vereinfachte Darstellung des Gesamtszenarios um das FMIS .................................... 150
Abbildung 44: Prozessierung der Daten hin zu Zielgrößen durch verschiedene Funktionen
des FMIS-Dienstes ..................................................................................................... 153
Abbildung 45: Typische Phasen im Lebenszyklus einer Softwareentwicklung ................................... 156

Schriftenreihe des LfULG, Heft 4/2022 | 6
Abstract
Die digitale Transformation in der sächsischen Land- bzw. Ernährungswirtschaft bietet einerseits Chancen,
stellt aber insbesondere landwirtschaftliche Betriebe vor große Herausforderungen. Produktionsprozesse
werden immer stärker verknüpft mit digitalen Daten, deren Erfassung sowie Nutzung in verschiedensten
Softwareanwendungen. Das Angebot landwirtschaftlicher Softwareprodukte wächst und eine Konsolidierung
hin zu wenigen, umfassenden Lösungen ist noch nicht absehbar. In der Praxis sind Landwirtinnen und Land-
wirte der Herausforderung ausgesetzt, Softwarelösungen verschiedener Anbieter und Produktionsbereiche
untereinander zu vernetzen, um anwendungsübergreifende Prozesse bearbeiten zu können. Darüber hinaus
fehlen Softwarelösungen, die eine betriebsweite Übersicht zu relevanten Kennzahlen wie beispielsweise
Liquidität oder Kosten-Leistungs-Rechnung ermöglichen.
Der vorliegende Bericht dokumentiert die Durchführung und Ergebnisse der Machbarkeitsstudie „Betriebli-
ches Datenmanagement und Farm-Management-Information-System (FMIS)“, die sich in das Teilprojekt
„Test- und Demonstrationsfeld betriebliches Datenmanagement und FMIS“ innerhalb des „Themenverbunds
digitale Landwirtschaft“ des Sächsischen Ministeriums für Energie, Klimaschutz, Umwelt und Landwirtschaft
(SMEKUL) einbettet. Ziel dieser Machbarkeitsstudie war es, das Sächsische Landesamt für Umwelt, Land-
wirtschaft und Geologie (LfULG) mit wissenschaftlich fundierten Informationen zu versorgen und eine Kon-
zeption (mit technischer, organisatorischer, zeitlicher und wirtschaftlicher Ausrichtung) für ein Betriebssteue-
rungssystem für landwirtschaftliche Betriebe in Sachsen zu erstellen. Dieses Betriebssteuerungssystem soll
als praktikable IT-Lösung die Unternehmensleitungen der landwirtschaftlichen Betriebe in Sachsen befähi-
gen, ihr Datenmanagement und die von ihnen betrieblich genutzten Softwareanwendungen in medienbruch-
freier Kopplung miteinander in einem geeigneten FMIS betriebswirtschaftlich sinnvoll zu betreiben. Für die
Konzeption eines geeigneten Betriebssteuerungssystems sind deshalb die bereits am Markt vorhandenen
Softwareanwendungen zu berücksichtigen. Des Weiteren soll untersucht werden, welche Betreibermodelle
für solch ein Betriebssteuerungssystem tragfähig sind, unter besonderer Berücksichtigung von marktrelevan-
ten, wirtschaftlichen und organisatorischen Bedingungen für die Landwirtschaft im Bundesland Sachsen. Mit
der Durchführung der Machbarkeitsstudie beauftragt wurde die Professur für Agrarsystemtechnik der Tech-
nischen Universität Dresden. Zusammen mit ihren Unterauftragnehmern – dem Fraunhofer IESE sowie dem
Kuratorium für Technik und Bauwesen in der Landwirtschaft e.V. – wurden umfassende Recherchen und
Analysen zu relevanten Hintergründen, Themen und Aspekten durchgeführt, grundlegende Lösungskonzep-
te erarbeitet und diskutiert sowie mögliche Folgeaktivitäten und Handlungsempfehlungen abgeleitet.
Eine Übersicht schwerpunktmäßig einbezogener Hintergründe zur Ausgangslage ist in Kapitel 2 dokumen-
tiert. Hierzu zählen insbesondere landwirtschaftliche Daten und Prozesse mit Fokus auf den sächsischen
Kontext, landwirtschaftliche Softwaresysteme, Vorüberlegungen zur technischen Infrastruktur für deren Be-
trieb sowie die Diskussion von Definitionen und Kernkonzepten wie Farm-Management-Informationssysteme
(FMIS), Interoperabilität und Datensouveränität.
Kapitel 3 dokumentiert die Studienergebnisse, die sich in verschiedene Darstellungen, Betrachtungen und
Artefakte untergliedern. Die Zielstellung sah die Konzeption eines umfassenden Betriebssteuerungssystems
für landwirtschaftliche Betriebe vor, dass in den Betrieben verwendete Fachanwendungen integriert und
betriebsweit anfallende Daten zur zentralen Darstellung, Auswertung und Analyse bereitstellt. Ein solches
System besteht nach Studiendesign aus einem FMIS mit dazugehörigem Datenmanagement, das betrieblich
genutzte Fachanwendungen integriert. Bereits im Studienverlauf wurde die Konzeption bzw. Schaffung eines

Schriftenreihe des LfULG, Heft 4/2022 | 7
einzelnen, eigenständigen und dedizierten Softwaresystems zum betrieblichen Datenmanagement als nicht
zielführend bewertet, was im Wesentlichen auf die Komplexität landwirtschaftlicher Betriebe und Produkti-
onsprozesse sowie die hohe Varianz im Markt angebotener Softwarelösungen zurückgeführt wird. Eine voll-
umfängliche Interoperabilität in der digitalen Landwirtschaft wurde bisher nicht erreicht. Bisherige For-
schungsaktivitäten, Initiativen und privatwirtschaftliche Angebote brachten oder erarbeiten punktuelle Ver-
besserungen, eine aus Studiensicht zufriedenstellende Situation ist allerdings noch nicht absehbar. Um im
Sinne dieser Studie eine Verbesserung zum aktuellen Stand zu erreichen, wurden in verschiedenen Aktivi-
täten Ergebnisse erarbeitet und durch zusammenfassende Darstellungen ergänzt. Die Ergebnisse lassen
sich wie folgt untergliedern:
Detailanalyse landwirtschaftlicher Produktions- und Managementprozesse zusammen mit Hilfestellungen
für weitere Analysen und Modellierungen (Abschnitt 3.1).
Zusammenfassung und Kontextualisierung betrieblicher Zielgrößen, die im Rahmen dieser Studie in einem
FMIS abgebildet (Abschnitt 3.2) und zur Ableitung von Anforderungen an das Datenmanagement genutzt
wurden (Abschnitt 3.2.12).
Grundlegende konzeptionelle Betrachtungen und mögliche Lösungskonzepte für ein betriebliches Daten-
management sowie der Erfassung und Analyse aktueller Herausforderungen (Abschnitt 0).
Entwurf eines betrieblichen FMIS zusammen mit der Diskussion erwartbarer Kosten und möglichen Be-
treibermodellen (Abschnitt 3.4).
Vorschläge für Folgeaktivitäten zusammen mit Artefakten als Hilfestellung sowie konkreten Handlungs-
empfehlungen für verschiedene Interessensgruppen (Abschnitte 3.5.2 sowie 3.6).
Im Folgenden werden Aktivitäten, Ergebnisse und Schlussfolgerungen aufgeführt, die wesentliche Studien-
ergebnisse zusammenfassen und als Möglichkeiten und Empfehlungen für folgende Aktivitäten genutzt wer-
den können. Eine detaillierte Zusammenfassung der Ergebnisse ist in Abschnitt 3.5.1 aufgeführt.
Bereits in der Aufgabenstellung der Studie wurde der Mangel an umfassender Interoperabilität im Kontext
landwirtschaftlicher Softwarelösungen formuliert, umfassende Recherchen und Analysen zur Ausgangs-
lage stützen diese Feststellung. Auch wenn ein einzelnes, eigenständiges Datenmanagementsystem nicht
als erstrebenswertes Lösungskonzept eingeschätzt wird, können die in Abschnitt 3.3.1.4 vorgestellten und
diskutierten,
grundlegenden Varianten eines Datenmanagements
zur weiteren Konzeption genutzt
werden. Die vorgestellten Varianten sind bilaterale Schnittstellen, Datenrouter und Datenhubs sowie die
Kombination aus diesen, die als hybrides Datenmanagement bezeichnet wird.
Die Konzeption eines Datenmanagements bedarf einer umfassenden Anforderungserhebung, die auf kon-
kreten, abzubildenden Produktions- und Managementprozessen basiert. In dieser Studie wurden exem-
plarische Prozesse analysiert und abgebildet (s. Abschnitt 3.1). Hierzu wurden
eigene Darstellungen zur
Prozessmodellierung
entwickelt, die zur Erfassung von Anforderungen an ein Datenmanagement aus
weiteren Prozessen genutzt werden können.

Schriftenreihe des LfULG, Heft 4/2022 | 8
Zur weitreichenden Interoperabilität zwischen Systemen (vgl. Abschnitt 2.3) ist nicht nur die technische Kon-
nektivität und gleiche Interpretation ausgetauschter Daten notwendig, sondern auch ein
gemeinsames
Prozessverständnis
. Ein solches könnte für die Landwirtschaft ein Schlüssel sein, um die Digitalisierung
von Produktions- und Managementprozessen über Systemgrenzen hinweg medienbruchfrei zu digitali-
sieren. Die Studienergebnisse fassen dazu notwendige Hintergründe, Informationen, Lösungsansätze und
Hilfestellungen an einer Stelle zusammen. Ausgehend von der Prozessmodellierung können relevante Soft-
waresysteme identifiziert werden, dabei unterstützt ein Katalog landwirtschaftlicher Softwaresysteme analog
zu Anhang 2.2. Mittels Datenkatalogen – wie dem in Anhang 2.1 selbst entwickelten – können einzubezie-
hende Daten identifiziert werden. Die Zusammenfassung der Zielgrößenableitung in Abschnitt 3.2 setzt
diese in den Kontext eines betrieblichen FMIS und zeigt auf, welche Datenquellen zur Darstellung und
Auswertung einzubeziehen sind.
In Abschnitt 3.4 wird ein in der Studie entwickeltes
Fachkonzept für ein FMIS
vorgestellt, mittels dem be-
triebsweit ausgewählte Zielgrößen und weitere betriebliche Informationen dargestellt werden können. Hierfür
wurden exemplarische Zielgrößen aus Abschnitt 3.2 einbezogen und notwendige Designs zur Darstellung
konzipiert. Für alle enthaltenen Funktionen wurden realistische grafische Oberflächen gestaltet, die ge-
meinsam mit Landwirten evaluiert wurden (s. Abschnitt 3.4.5). In der Evaluation wurde dem Konzept ein
hoher Nutzwert zugemessen, ergänzend wurden weitere Anforderungen und Wünsche an ein solches FMIS
formuliert. Eine solche betriebsweite und systemübergreifende Lösung ist bisher nicht am Markt vertreten
und kann für Landwirtinnen und Landwirten ein attraktives Lösungsangebot darstellen.
In ausführlichen
Fachgesprächen
mit einer nicht repräsentativen Auswahl von zehn Anbietern landwirt-
schaftlicher Softwarelösungen wurden weitere Perspektiven und Einschätzungen der Gesprächspartner
erhoben, die in Abschnitt 3.3.3 dargestellt wurden. Insgesamt ergab sich ein Stimmungsbild, das Annahmen
und Zielsetzung der Studie grundsätzlich unterstützt, z.T. jedoch verschiedene Meinungen zu Lösungs-
ansätzen, der eigenen Rolle und der Rolle anderer Softwareanbieter ausdrückt. Die detaillierten Informa-
tionen aus den Fachgesprächen können von Akteuren wie dem Auftraggeber genutzt werden, um die
Gesamtsituation detaillierter einzuschätzen und weitere Aktivitäten zu planen.
Prinzipiell sind die technologischen Fähigkeiten gegeben, eine umfassende Interoperabilität in der digitalen
Landwirtschaft herzustellen. Gleichzeitig existiert eine Vielzahl von Ursachen und Gründen, die dies ver-
hindern oder hemmen. Dieser Studienbericht enthält eine umfangreiche Darstellung und Diskussion solcher
Gründe aus verschiedenen Perspektiven (s. die Zusammenfassung in Abschnitt 3.5.1.1) und schlägt
Hand-
lungsempfehlungen für verschiedene Adressaten
vor (s. Abschnitt 3.6). Diese richten sich an Landwir-
tinnen und Landwirte, Behörden, beratende Stellen, landwirtschaftliche Interessensverbände und Software-
anbieter.
Für Landwirtinnen und Landwirte wurden
Informationsblätter zu spezifischen Themen
gestaltet, die dem
Wissenstransfer dienen (s. Anhang 0). Dem Wissenstransfer fällt aus Sicht der Studienergebnisse eine
tragende Rolle in der weiteren Digitalisierung der Landwirtschaft zu. Hierbei geht es nicht nur um das Erler-
nen möglicher Einsatzszenarios digitaler Technologien in landwirtschaftlichen Betrieben, sondern vielmehr
darum, Landwirtinnen und Landwirte zum souveränen Umgang damit zu befähigen. Dazu gehören Themen
wie Datensouveränität (s. Abschnitt 2.3.3), Prozessvorschläge zur Verbesserung des eigenen Daten-
managements wie auch Hintergrundinformationen zum Betrieb betrieblicher Softwaresysteme in Cloud-
Umgebungen (s. Abschnitt 2.2.3).

Schriftenreihe des LfULG, Heft 4/2022 | 9
1 Einleitung
In diesem Kapitel werden Ziele und Aufgabenstellungen der Machbarkeitsstudie beschrieben, deren Ergeb-
nisse in diesem Abschlussbericht zusammengeführt wurden. Nach einer kurzen Darstellung der Ausgangssi-
tuation in der sächsischen Landwirtschaft werden die Projektziele aufgeführt. Zum Abschluss des Kapitels
werden Materialien genannt, die zu Beginn der Studie vom Auftraggeber bereitgestellt wurden.
1.1 Ausgangssituation in der sächsischen Landwirtschaft
Die Digitale Transformation erfasst inzwischen alle Lebens-, Gesellschafts- und Wirtschaftsbereiche. So
auch die Landwirtschaft und die in diesem Sektor tätigen Betriebe. Dabei wird der Zukunftstrend hin zur
digitalisierten Landwirtschaft insbesondere von Prozessen und Lösungen getrieben, die sich mit digitalen
Daten und deren Erfassung und Nutzung beschäftigen. Die agrarwirtschaftliche Bedeutung der Digitalen
Transformation in sächsischen Landwirtschaftsbetrieben liegt also darin, durch den Einsatz datengetriebener
Lösungen den schwierigen Weg zum effizienten Einsatz von Ressourcen zu ebnen und Möglichkeiten zu
finden, wie die Chancen der immer weiter fortschreitenden Digitalisierung erfolgreich genutzt werden kön-
nen.
Aktuell jedoch steht die Landwirtschaft noch vor sehr großen Herausforderungen, auch in Sachsen. Die Be-
triebe sind steigenden Qualitätsanforderungen an Produkte und Verfahren, großem Preisdruck, zunehmen-
der internationaler Konkurrenz sowie hohen Erwartungen im Umwelt- und Tierschutz ausgesetzt. Insbeson-
dere die Dokumentationspflichten der Landwirtinnen und Landwirte nehmen immer weiter zu und die Zeit-
räume, in denen Arbeitsgänge (z. B. Düngung und Pflanzenschutz) nachprüfbar dokumentiert sein müssen,
werden kürzer. Deshalb nutzen die Betriebe immer stärker die entsprechenden digitalen Anwendungen.
Doch hier ergibt sich eine weitere Herausforderung für die Betriebe: Der Markt für Softwareprodukte, mit
denen Daten digital erhoben und verarbeitet werden können, ist inzwischen unübersichtlich geworden.
Die Grundlage der betrieblichen Software bildet die Ackerschlagkartei
1
(für den Pflanzenbau) und das Her-
denmanagementsystem (für die Tierproduktion). Hier könnten Kostenrechnungen schlag- bzw. produktspezi-
fisch erstellt werden. Zwar ist die Kenntnis über die Stückkosten der erzeugten Güter eine wichtige Informa-
tion für das betriebswirtschaftliche Handeln der Landwirte, aber die eigentliche Herausforderung für die
landwirtschaftlichen Unternehmen liegt nunmehr darin, die Daten in ihrer Gesamtheit in die Schlagkartei
oder das Herdenmanagementsystem zu bekommen.
In den sächsischen Landwirtschaftsbetrieben werden zudem unterschiedlichste Softwareanwendungen ein-
gesetzt. Vor allem Daten zur Dokumentation und zur Abrechnung werden zwischen diesen Softwareanwen-
dungen übertragen und ausgetauscht. Hierbei kommt es jedoch zu Medienbrüchen. Insbesondere die Wei-
terleitung der Daten in die Hauptsysteme ist ein großes Problem und erzeugt hohen Arbeitsaufwand bei den
Betrieben. Deshalb ist ein effizientes betriebliches Datenmanagement mit angeschlossenem Farm-Manage-
ment-Information-System (FMIS) für die sächsischen Landwirtschaftsbetriebe essenziell.
Die hier dokumentierte Machbarkeitsstudie „Betriebliches Datenmanagement und Farm-Management-
Information-System (FMIS)“ bettet sich ein in das Teilprojekt „Test- und Demonstrationsfeld betriebliches
1
Fachbegriffe und Abkürzungen sind im Glossar (s. Abschnitt 5) erläutert bzw. aufgelöst.

Schriftenreihe des LfULG, Heft 4/2022 | 10
Datenmanagement und FMIS“ innerhalb des „Themenverbunds digitale Landwirtschaft“ des Sächsischen
Ministeriums für Energie, Klimaschutz, Umwelt und Landwirtschaft (SMEKUL). In diesem Teilprojekt wurden
bereits fünf landwirtschaftliche Betriebe in Sachsen in Bezug auf ihr Datenmanagement und FMIS analysiert.
Im Ergebnis dieser Analyse musste festgestellt werden, dass bei der Nutzung von Daten viele Medienbrüche
auftreten. Probleme bereitet auch die schlechte Vernetzung unterschiedlicher Softwareanwendungen unter-
einander. Der Hauptgrund sind unzureichende, nicht herstellerübergreifende bzw. nicht standardisierte
Schnittstellen. Für die notwendige Betriebssteuerung müssen die landwirtschaftlichen Unternehmen deshalb
oft unterschiedlichste fachspezifische Software gleichzeitig nutzen und ggf. externes Personal beauftragen,
um an alle relevanten Daten zu gelangen. Die landwirtschaftlichen Betriebe stehen somit vor dem Problem,
die zur Betriebssteuerung benötigten Daten jederzeit im notwendigen Umfang und in der erforderlichen Qua-
lität zur Verfügung zu haben.
1.2 Ziele und Aufgabenstellung der Studie
Ziel der hier ausgeschriebenen Machbarkeitsstudie ist es, das Sächsische Landesamt für Umwelt, Landwirt-
schaft und Geologie (LfULG) mit wissenschaftlich fundierten Informationen zu versorgen und eine Konzepti-
on (mit technischer, organisatorischer, zeitlicher und wirtschaftlicher Ausrichtung) für ein Betriebssteue-
rungssystem für landwirtschaftliche Betriebe in Sachsen zu erstellen. Dieses Betriebssteuerungssystem soll
als praktikable IT-Lösung die Unternehmensleitungen der landwirtschaftlichen Betriebe in Sachsen befähi-
gen, ihr Datenmanagement und die von ihnen betrieblich genutzten Softwareanwendungen in medienbruch-
freier Kopplung miteinander in einem geeigneten FMIS betriebswirtschaftlich sinnvoll zu betreiben. Für die
Konzeption eines geeigneten Betriebssteuerungssystems sind deshalb die bereits am Markt vorhandenen
Softwareanwendungen
2
zu berücksichtigen. Des Weiteren soll untersucht werden, welche Betreibermodelle
für solch ein Betriebssteuerungssystem tragfähig sind, unter besonderer Berücksichtigung von marktrelevan-
ten, wirtschaftlichen und organisatorischen Bedingungen für die Landwirtschaft im Bundesland Sachsen.
Der vordringliche Handlungsbedarf aus Sicht des LfULG als Auftraggeber dieser Machbarkeitsstudie besteht
also in der Entwicklung eines praxistauglichen FMIS mit offenen Schnittstellen zu einer Vielzahl von Anbie-
tern und Nutzern. Vor diesem Zielbild ergab sich eine komplexe Aufgabenstellung für die Auftragnehmer, bei
der es darum geht,
a.) mit welchem vorteilhaften technischen Ansatz,
b.) in welchem inhaltlichen Umfang,
c.) zu welchen einmaligen bzw. laufenden Kosten und
d.) mit welchem Betreibermodell
eine bestmögliche Problemlösung erreicht werden kann.
2
Disclaimer
: Im Rahmen der Beschreibung von Softwareanwendungen und der Erläuterung ihrer Funktionsweisen nennen
wir an einigen Stellen dieses Berichts Anbieter bzw. Hersteller entsprechender Produkte. Dadurch ist allerdings keine
Bevorzugung oder Empfehlung dieser Produkte durch die Autoren intendiert.

Schriftenreihe des LfULG, Heft 4/2022 | 11
1.3 Bereitgestellte Materialien
Das LfULG als Auftraggeber dieser Machbarkeitsstudie stellte dem Autorenteam freundlicherweise eine
Reihe von Dokumenten zur Verfügung, die bei der Konzeption und Durchführung der Studie äußerst hilfreich
waren. Einige dieser Materialien sollen hier kurz vorgestellt werden.
Als erstes ist ein Positionspapier des LfULG vom 29.01.2020 zu nennen. Es ist das Ergebnis eines Work-
shops vom 28.11.2019, an dem Landwirtinnen und Landwirte, FMIS-Anbieter und Vertretungen wissen-
schaftlicher Einrichtungen teilnahmen. Ziel dieses Workshops war es, die Anforderungen aus der landwirt-
schaftlichen Praxis zu erfassen, einen Überblick über FMIS-Anwendungen zu bekommen und mögliche
Entwicklungsrichtungen zu bestimmen. In dem Positionspapier wurde u.a. festgehalten, dass die Betriebe in
der Lage sein sollten, ihre Daten jederzeit souverän und digital zu verwalten. Das FMIS, so das Papier, wird
der Betriebsleitung die smarte Leitung eines landwirtschaftlichen Unternehmens (operativ und strategisch)
ermöglichen und ein komplexes, zielgerichtetes Betriebsmanagement unterstützen können. Doch wurde in
dem Papier auch festgestellt, dass ein FMIS nicht pauschal und einheitlich für alle Betriebe entwickelt wer-
den kann, sondern dass es der Anpassung an betriebsspezifische Strukturen bedarf. Festgehalten wurde
auch, dass die Unterstützung der Praxisunternehmen im Bereich betriebliches Datenmanagement und FMIS
zum Bildungsauftrag des LfULG gehört. Die Präsentationen der Organisationen, die an dem Workshop vom
28.11.2019 teilnahmen, wurden uns vom LfULG ebenfalls zur Verfügung gestellt.
Ein zweites Positionspapier wurde vom LfULG am 18.01.2021 vorgelegt. Es ist ebenfalls Ergebnis und Re-
flexion eines Workshops (vom 28.10.2020), bei dem das praktische Datenmanagement in ausgewählten
FMIS-Funktionsbereichen (Warenmanagement, Digitales Agrarbüro, Maschinenmanagement) sowie das
Querschnittsthema Datensouveränität in der Landwirtschaft im Mittelpunkt standen. Das Positionspapier
weist darauf hin, dass die anbieterseitige Weiterentwicklung von betrieblichen Datenmanagement- und
FMIS-Lösungen mit einer hohen Dynamik erfolgt, während anwenderseitig nur 30 % der befragten Betriebe
in der sächsischen Landwirtschaft FMIS-Anwendungen für die Außenwirtschaft nutzen. Auch diese Präsen-
tationen der Organisationen, die an dem Workshop vom 28.10.2020 teilnahmen, wurden uns vom LfULG zur
Verfügung gestellt.
Einsicht wurde auch in einen Untersuchungsbericht bzgl. des Themas Smart Farming im Pflanzenbau des
Lehr- und Versuchsgutes Köllitsch gewährt. Ziel dieser Studie war es, ein Best-Practice-Konzept zu entwi-
ckeln und Handlungsempfehlungen zu formulieren, um die Vernetzung der dort bereits genutzten Software-
systeme weiter auszubauen und die Umsetzung von Smart Farming effizient zu erreichen.
Zudem lagen dem Auftragnehmer aus vier weiteren Projektbetrieben detaillierte Analysen des LfULG zu den
vorhandenen betrieblichen Systemen und den damit verbundenen aktuellen und künftig gewünschten Daten-
flüssen vor.
Weitere hilfreiche Informationen lieferten schließlich zwei Masterarbeiten, in die uns durch das LfULG Ein-
sicht gewährt wurde. Zum einen die Arbeit von Max Eckelmann von der Martin-Luther-Universität Halle-
Wittenberg mit dem Titel „Marktübersicht und Nutzwertanalyse deutschsprachiger Farmmanagement-
Informationssysteme (FMIS)“ sowie die Arbeit von Emilie Heber von der Hochschule für Technik und Wirt-
schaft Dresden mit dem Titel „Entwicklung einer Digitalisierungsstrategie zur Optimierung des Datenmana-
gements eines Landwirtschaftsbetriebes“. Beide Arbeiten stammen aus dem Jahr 2020.

Schriftenreihe des LfULG, Heft 4/2022 | 12
2 Ausgangslage und Hintergründe
In diesem Kapitel beschreiben wir die Ausgangslage und die Hintergründe, an die wir im Kontext dieser
Machbarkeitsstudie angeknüpft haben. Das Kapitel ist in drei Unterabschnitte unterteilt. Zunächst werden
projektrelevante landwirtschaftliche Prozesse und Daten beschrieben. Anschließend werden Softwaresys-
teme im landwirtschaftlichen Kontext und zuletzt Definitionen und Kernkonzepte erläutert, sodass ein einheit-
liches Verständnis über relevante Begriffe, Konzepte und Herangehensweisen in dieser Machbarkeitsstudie
erzielt werden kann.
2.1 Landwirtschaftliche Prozesse und Daten
Die folgenden Abschnitte führen Prozesse und Daten auf, die für die weiteren Arbeiten in dieser Studie rele-
vant sind. Sie bilden die Basis der Betrachtungen zum betrieblichen Datenmanagement und zur Entwicklung
eines betrieblichen FMIS.
2.1.1 Prozesse
Trotz seiner historisch zum Teil großen Landwirtschaftsbetriebe hat Sachsen eine im Bundesvergleich sehr
vielfältige Agrarstruktur. So bewirtschaften ca. 76 % der ungefähr 6480 landwirtschaftlichen Betriebe in
Sachsen weniger als 100 ha
3
. Sieben Prozent der gesamten LF werden von Betrieben mit einer Flächen-
ausstattung bis 50 ha bewirtschaftet, welche einen Anteil von 63 % an allen landwirtschaftlichen Betrieben
haben; s.a. Abbildung 2. Auf der anderen Seite befinden sich 44 % der LF in Nutzung durch Betriebe mit
500 ha und mehr.
4
56 % der landwirtschaftlichen Nutzfläche bzw. 71 % der Ackerflächen werden für Druschfrüchte genutzt.
Während im Mittelsächsischen Lössgebiet der Ackerbau auf fast 90 % der landwirtschaftlichen Nutzfläche
dominiert, spielt in den Mittelgebirgslagen auch Grünland eine erhebliche Rolle, da dort 45 % des sächsi-
schen Grünlands zu finden sind (Abbildung 1).
6
Ungefähr 34 % der sächsischen Landwirtschaftsbetriebe sind spezialisierte Ackerbaubetriebe. Mit 35 % ist
der Anteil der spezialisierten Futterbaubetriebe ähnlich groß, wobei darunter die Milchviehbetriebe knapp
9 % ausmachen. Von den ca. 19 % Verbundbetrieben umfassen 3,1 % Milchviehverbundbetriebe und 2,8 %
Veredlungsverbundbetriebe. Während Schafbetriebe noch 4 % aller Landwirtschaftsbetriebe in Sachsen
ausmachen, spielen Dauerkulturbetriebe (1,2 %), Gartenbaubetriebe (0,8 %) und spezialisierte Veredlungs-
betriebe (1,0 %) zahlenmäßig eine geringere Rolle. Die Verteilung der Betriebsformen spiegelt sich auch in
den bewirtschafteten Flächen wider. 3 % der Flächen werden durch spezialisierte Ackerbaubetriebe bewirt-
schaftet, darunter 27 % spezialisierte Getreidebaubetriebe. 28 % der LF entfallen auf spezialisierte Futter-
baubetriebe, davon wiederum 23 % auf Milchviehbetriebe. 19 % der LF werden von Milchviehverbundbetrie-
3
Statistisches Landesamt des Freistaates Sachsen (Hg.): Betriebsstruktur – Eckdaten für Sachsen. Online verfügbar unter
https://www.statistik.sachsen.de/html/betriebsstruktur-landwirtschaft.html?_cp=%257B%2522accordion-content-
8319%2522%253A%257B%25224%2522%253Atrue%257D%252C%2522previousOpen%2522%253A%257B%2522group
%2522%253A%2522accordion-content-8319%2522%252C%2522idx%2522%253A4%257D%257D, letzter Zugriff am
09.10.2021.
4
Statistisches Landesamt des Freistaates Sachsen (Hg.): Statistischer Bericht: Ausgewählte Strukturdaten
landwirtschaftlicher Betriebe im Freistaat Sachsen, C IV – u/16, 2016. Online verfügbar unter
https://www.statistik.
sachsen.de/download/statistische-berichte/bericht_statistik-sachsen_c-IV-12_agrarstrukturerhebung-strukturdatenxlsx.xlsx,
letzter Zugriff am 09.10.2021.

image
Schriftenreihe des LfULG, Heft 4/2022 | 13
ben als Teilmenge der Verbundbetriebe (30 % der LF) bewirtschaftet; nur 4 % entfallen auf sonstige Be-
triebsformen
5
.
Abbildung 1: Regionale Acker- und Grünlandverteilung in Sachsen (Agrarstatus Sachsen
6
)
5
https://www.landwirtschaft.sachsen.de/regionale-grossenstruktur-landwirtschaftlicher-betriebe-in-sachsen-40201.html,
letzter Zugriff am 04.10.2021.
6
https://www.landwirtschaft.sachsen.de/regionale-acker-und-grunlandverteilung-in-sachsen-40145.html,
letzter Zugriff
am 04.10.2021.

image
Schriftenreihe des LfULG, Heft 4/2022 | 14
Abbildung 2: Betriebsgrößenverteilung und Flächenanteile in Sachsen (Agrarstatus Sachsen
5
)
Im Rahmen der Arbeiten zur Gesamtbetriebskalkulation hat das KTBL auf Basis statistischer Daten Modell-
betriebe für verschiedene Regionen Deutschlands entworfen. An diesen Modellen wurden Berechnungen
verschiedener Zielgrößen, die auch für die hier vorgelegte Studie relevant sind, dargestellt. Hierbei wurde
auch ein Gemischtbetrieb für die Region Sachsen erstellt und charakterisiert. Die in Abbildung 1 und 2 dar-
gestellten Daten der Agrarstatistik spiegeln sich auch in dessen modellhaftem Produktionsprogramm wider.
Vier Produktionsverfahren und daran anknüpfende Prozesse dieses Modellbetriebs sollen daher im Rahmen
der Studie zur Illustration von Abläufen und Sachverhalten bei der Ermittlung der Zielgrößen und zu Aspek-
ten des Datenmanagements genutzt werden, um eine verständlichere Darstellung zu erarbeiten:
Winterweizen: als Beispiel für eine Körnerfrucht, die als Marktfrucht in erster Linie dem Verkauf zur
Verwendung in der Lebensmittelkette dient.
Winterraps: als Beispiel für eine Kultur, die als Ölfrucht mehreren Verwendungen dienen kann und in der
Fruchtfolge Wirkung auf die Bodenfruchtbarkeit entfaltet.
Grassilage: als Beispiel für einen Prozess, der ein Produkt für die interne Weiterverwendung in der
Tierhaltung erzeugt und sich in seinem Charakter und den notwendigen Arbeiten hinreichend von obigen
beiden Ackerbaukulturen unterscheidet.
Milchproduktion: als Beispiel eines Prozesses aus der Tierhaltung, in den verschiedene Produkte
einfließen und der anders organisiert ist als pflanzenbauliche Prozesse.

 
Schriftenreihe des LfULG, Heft 4/2022 | 15
In Abschnitt 3.1 werden diese Produktionsprozesse mit ihren Einzelschritten und Feldarbeiten sowie Bezü-
gen zu weiteren Prozessen skizziert. Darauf aufbauend wird eine weitergehende Analyse einzelner Teil-
schritte innerhalb identifizierter Prozesskategorien bis auf die Ebene der für die Ermittlung von Zielgrößen
notwendigen Attribute innerhalb einzelner relevanter Datenformate durchgeführt.
2.1.2 Daten
Die Erhebung relevanter Daten dient zunächst dem Zweck, sich einen Überblick über das vorhandene Da-
tenangebot zu verschaffen. Wie im weiteren Verlauf dargestellt, ist es mit Blick auf das Ziel der Konzeption
eines FMIS jedoch erforderlich, anschließend in der Lage zu sein, stärker zu fokussieren und dafür zu sor-
gen, dass erforderliche Informationen für die Umsetzung vorhanden sind. Als methodischer Ansatz kann
hierfür eine Katalogisierung relevanter Daten hilfreich sein. Allerdings können Datenkataloge auf unter-
schiedlichen Abstraktionsebenen und in variierender Detailtiefe erstellt werden. Im Folgenden werden meh-
rere in Betracht gezogene Ansätze kurz skizziert. Es wird erläutert, welche dieser Ansätze aus welchen
Gründen wieder verworfen wurden, um anschließend auf das schlussendlich zusammengestellte Informati-
onsmaterial zu den relevanten Daten einzugehen. Eine wesentliche Rolle spielt dabei auch die Abhängigkeit
von und die Verzahnung mit den Zielen, die bei der Erstellung des datenverarbeitenden Systems erreicht
werden sollen – mithin den für die Auswertung geplanten Ziel- und Kenngrößen.
2.1.2.1 Datenkatalog auf Ebene von Datensätzen und/oder -diensten
Kataloge auf Ebene von Datensätzen sind insbesondere im Forschungsdatenmanagement und in der Be-
reitstellung öffentlicher Daten weit verbreitet. Im Internet existieren öffentlich zugängliche Katalogsysteme.
Als prägnante Beispiele können genannt werden:
www.landwirtschaftsdaten.de:
als
Reaktion
auf
die
BMEL-Machbarkeitsstudie
erstelltes
Datenkatalogsystem, das für die Landwirtschaft relevante Datensätze öffentlicher Einrichtungen,
insbesondere auch der Ressortforschungseinrichtungen des Bundes, enthält.
www.govdata.de:
allgemeines Datenportal für Deutschland mit Daten aus allen Bereichen der
öffentlichen Verwaltung
www.publisso.de:
Open-Access-Datenportal der Zentralbibliothek Lebenswissenschaften
www.gdi-de.org:
Datenportal für Inhalte der Geodateninfrastruktur Deutschland
Datensätze und -dienste werden dabei in der Regel mit Standardmetadatensätzen erfasst. Teilweise sind für
die landwirtschaftliche Praxis nützliche Datensätze und Dienste enthalten (z. B. Kartendaten über das Geo-
portal Deutschland, Pflanzenschutzmittelzulassungsdaten inklusive Anwendungsbestimmungen über
www.landwirtschaftsdaten.de
usw.). Ein mit oben genannten Beispielen vergleichbares System aufzusetzen
ist aufwändig und würde den Rahmen der vorliegenden Studie deutlich sprengen. Aber auch eine einfache
tabellarische Auflistung öffentlich verfügbarer Datensätze hilft mit Blick auf die bearbeiteten Fragestellungen
nicht weiter: Die meisten dieser Datensätze haben – wenn überhaupt – nur sehr entfernt einen Bezug zu den
darzustellenden Zielgrößen.
Für die Ermittlung der Zielgrößen sind weitestgehend innerbetrieblich erhobene Daten relevant (s.a. Ab-
schnitt 3.2 zu methodischen Grundlagen zu den betrachteten Ziel- und Kenngrößen). Als Datenspeicher für
solche in dem Betrieb erhobenen Daten werden die im Laufe der Studie näher skizzierten Softwareanwen-
dungen genutzt. Die meisten dieser Anwendungen haben eine eigene Datenverwaltung integriert – jede An-
wendung besitzt also ihr eigenes „Datensilo“. Aufgrund dieser in der Regel vorliegenden 1:1-Beziehungen

image
Schriftenreihe des LfULG, Heft 4/2022 | 16
können „innerbetriebliche Datensätze“ und „innerbetriebliche Softwareanwendungen“ so gut wie immer als
äquivalent angesehen werden. Die Funktion eines Datenkatalogs auf Datensatzebene ist für den innerbe-
trieblichen Bereich daher über den Katalog der Softwareanwendungen abgedeckt. Soweit es anhand von
zugänglicher Information möglich war, sind in dem beiliegenden Katalog auch die für einen Datenkatalog auf
dieser Ebene typischen Informationen zum Datenzugang (Schnittstellen) enthalten und die Inhalte lassen
sich in etwa aus dem Funktionsumfang und der Kategorisierung der Software ableiten.
2.1.2.2 Datenkatalog auf Ebene von Datenkategorien, -paketen oder -dateien
Für einen Datenkatalog auf Ebene von Datenkategorien oder -paketen werden inhaltlich ähnliche oder tech-
nisch gebündelte Daten zusammengefasst im Hinblick auf ihre Quellen und Nutzung betrachtet, wie bei-
spielsweise:
Geodaten
Wetterdaten
Buchungen (für Buchhaltung oder Ackerschlagkartei)
Alternativ oder parallel hierzu kann auch nach Datenformaten, -paketen oder -dateien eingeteilt werden:
ISO11783-Applikationskarte (SOLL)
Shapefile
ISO11783 Prozessdokumentation (IST)
Eine solche Auflistung der Datenarten und die Darstellung ihrer Quellen und Nutzung im Prozess wurde
im Rahmen der Studie in Betracht gezogen. Wie eine solche Darstellung aussehen würde, zeigt beispiel-
haft Abbildung 3.
Abbildung 3 Beispielhafte Darstellung von Datenarten, Datenquellen und Datennutzen in land-
wirtschaftlichen Prozessen

Schriftenreihe des LfULG, Heft 4/2022 | 17
Aus der Abbildung wird ersichtlich, dass ein solches Vorgehen im Rahmen der Ermittlung von Datenflüssen
in Prozessen in landwirtschaftlichen Betrieben im Allgemeinen ohne Bezug zu einem konkreten Betrieb we-
nig hilfreich ist: Prinzipiell können in ganz vielen Prozessschritten die gleichen Kategorien an Daten vor-
kommen. Beispielsweise kann tatsächlich für
jeden
Feldarbeitsprozess eine Applikationskarte erstellt wer-
den. Der Begriff „Applikationskarte“ bezieht sich nicht ausschließlich auf die teilflächenspezifische Ausbrin-
gung von Düngemitteln oder Pflanzenschutz. Bei einigen Bodenbearbeitungsgeräten kann z. B. die Bearbei-
tungstiefe eingestellt werden, Sämaschinen können Saatdichten variieren, und auch für Erntemaschinen
sind teilflächenspezifische Einstellungen von beispielsweise Dresch- oder Schneidwerk grundsätzlich tech-
nisch machbar und denkbar. Gleiches gilt in noch höherem Maße für Shapefiles: Diese können überall zum
Einsatz kommen, wo räumliche Daten genutzt oder erzeugt werden. Darstellungen nach thematischen Kate-
gorisierungen sind von derselben Schwäche geplagt: Geodaten, Wetterdaten und Buchungen sind für prak-
tisch alle landwirtschaftlichen Teilprozesse relevant.
Insgesamt entsteht also eine Darstellung, bei der fast alle Teilprozesse mit fast allen Datenkategorien ver-
bunden sind. Zur Analyse der Datenflüsse in landwirtschaftlichen Betrieben allgemein und zur Ermittlung von
Anforderungen für ein generell anwendbares Datenmanagement lassen sich daher mit dieser Vorgehens-
weise nur begrenzt Erkenntnisse ableiten, da die nötige Granularität und Ausdifferenzierung fehlt. Die tat-
sächliche Ausprägung der konkreten Datenflüsse unterscheidet sich von Betrieb zu Betrieb je nach Maschi-
nen-, Anlagen- und Softwareausstattung und Produktionsprogramm, sodass im Grunde jeder Betrieb seinen
ganz eigenen, individuellen „Datenfingerabdruck“ besitzt. Insofern kann eine Katalogisierung auf Basis von
Datenkategorien sowie eine Zuordnung zu Prozessen für eine einzelbetriebliche Schwachstellenanalyse
durchaus hilfreich sein: So lassen sich für den spezifischen Betrieb schnell Prozessschritte finden, die nicht
gut mit Daten versorgt sind oder wo wichtige Informationen nicht geliefert werden. Für eine einzelbetriebliche
Analyse des Datenmanagements hat diese Art, Daten und ihren Bezug zu Prozessen darzustellen, daher
durchaus ihren Wert.
2.1.2.3 Datenkatalog auf Ebene einzelner Datenstrukturelemente
Für eine differenzierte Sicht ist es also notwendig, in Betrieben vorhandene Daten noch ein wenig detaillier-
ter zu betrachten. Damit wird eine Stufe erreicht, auf der einzelne Elemente von Datenmodellen und Forma-
ten einbezogen werden. Die Begrifflichkeiten unterscheiden sich je nach den angewandten Methoden der
Datenmodellierung von Fall zu Fall. Üblicherweise spricht man dabei aber über folgende Teilaspekte:
Klassen, Objekttypen, Kategorien, Nachrichten oder Entitäten: Dies sind Einordnungen von Realweltob-
jekten anhand ihrer Eigenschaften und daraus resultierende Informationsmodelle, also beispielsweise
„Milchkuh“ (Objekttyp), „landwirtschaftliche Maschinen“ (Kategorie oder Klasse), „HIT-Ausfuhrmeldung“
(Nachricht).
Eigenschaften, Properties, Attribute, Items, Datenfelder, Relationen, Beziehungen: Verbunden mit diesen
Objekten sind Spezifikationen ihrer Eigenschaften (z. B. Traktor --> Motorleistung) sowie ihrer Beziehungen
zu anderen Objekten (z. B. Herde --> Milchkuh).
Datenstandards und Spezifikationen für Datenaustauschformate beschreiben in der Regel diese beiden
Teilaspekte und wie diese in informationstechnische Datenstrukturen abgebildet werden sollen. Beispiels-
weise muss für eine CSV-Datei beschrieben werden, welche Eigenschaft sich üblicherweise in welcher
Spalte befindet.

image
Schriftenreihe des LfULG, Heft 4/2022 | 18
Aufbauend auf den Strukturdefinitionen werden diese in dem landwirtschaftlichen Betrieb „instanziiert“, d. h. die
im Betrieb vorhandenen „Individuen“ werden gemäß den Datenstrukturen entweder in Einzelrecords erfasst
oder die Daten werden über Schnittstellen gemäß den Spezifikationen aus-/eingegeben. Die Abbildung 4 skiz-
ziert diesen Zusammenhang schematisch.
Abbildung 4: Zusammenhang Datenstrukturdefinition und Daten für Individuen auf dem Betrieb
In diesem Kontext soll eine kurze, aber detailliertere Betrachtung der oben umrissenen Konzepte für
ISO11783 sowie für ADIS/ADED erfolgen. Für die beiden Standards wurde beispielhaft ein Datenkatalog auf
Itemebene erstellt, dessen Nutzung ebenfalls erläutert wird und auf den später nochmals zurückgegriffen
wird. Für die technische Umsetzung ist eine solche inhaltliche Betrachtung für alle einzubeziehenden rele-
vanten Datenformate notwendig. Wegen der teilweise beschränkten Zugänglichkeit zur Dokumentation ist
dies jedoch oft nur mit beträchtlichem Aufwand bis hin zum „Reverse Engineering“ möglich. Für die beiden
Formate liegen die hier zusammengestellten Informationen zwar öffentlich vor, dennoch mussten sie mit
einem gewissen Aufwand aufbereitet bzw. aus der Dokumentation extrahiert werden. Ein Verfahren, mit dem
die inhaltliche Analyse von Datenformaten und Standards erleichtert werden kann, wird in Abschnitt 3.2.12.1
beschrieben. Wenn ein gutes Zusammenspiel unabhängiger Systeme erreicht werden soll, sind zudem of-
fengelegte Schnittstellen mit frei zugänglicher und gut auffindbarer Dokumentation unabdingbar.
2.1.2.4 ISO11783
Für den Austausch von Daten von (mobilen) landwirtschaftlichen Arbeitsmaschinen der Außenwirtschaft wur-
de die Norm ISO11783 (ISOBUS) geschaffen. Diese besteht derzeit aus 14 Teilen und spezifiziert eine Reihe
von Teilaspekten, von den physikalischen Eigenschaften und Abmessungen von Steckverbindern an Trakto-
ren und Anbaugeräten über den Verbindungs- und Anmeldeprozess von Anbaugeräten am Bordrechner des
Traktors bis hin zum in diesem Kontext relevanten Datenaustauschformat mit Farmmanagement-Infor-
mationssystemen in den Teilen 10 und 11. Teil 10 spezifiziert ein Datenformat auf Basis der sogenannten

Schriftenreihe des LfULG, Heft 4/2022 | 19
eXtensible Markup Language (XML). Das Format ist so ausgelegt, dass sowohl der Arbeitsauftrag an eine
Maschine übergeben werden kann als auch die Aufzeichnung und Dokumentation zurück an das FMIS über-
tragen werden kann.
Die XML-Spezifikation
7
des World Wide Web Consortium (W3C) unterscheidet im Wesentlichen zwischen
Elementen und Attributen. Elemente können hierarchisch angeordnet werden, also selbst wieder Unterele-
mente besitzen (sog. Kindelemente) sowie Attribute beinhalten. In der Spezifikation für ISOXML sind den
Elementen in der Regel Namen aus drei Großbuchstaben zugewiesen; Attribute werden jeweils mit einem
Buchstaben je Element beginnend bei ‘A’ alphabetisch bezeichnet. Die Bedeutung ist ISO11783 Teil 10 zu
entnehmen. Zentrales Element ist der sogenannte „Task“ (Elementname <TSK>), der einen Arbeitsprozess
auf dem Feld beschreibt. Mit diesem Element sind beispielsweise Beschreibungen der Anbaugeräte („De-
vice“, <DVC>), Arbeiter / Fahrer („Worker“, <WKR>), Schläge, auf denen die Bearbeitung erfolgt („Partfield“,
<PFD>), usw. verknüpft. Die ISO-Norm 11783 definiert auch für Geodaten eigene Kodierungen, die zur Er-
stellung von Applikationskarten genutzt werden können („Point“, <PNT>; „Polygon“, <PLN>; „Linestring“,
<LSG> usw.).
Neben Unterelementen sind in ISO11783 Teil 10 auch die Attribute spezifiziert. Für das <DVC>-Element
wird beispielsweise spezifiziert, dass sich in Attribut C die DeviceSoftwareVersion oder in Attribut E die
DeviceSerialNumber findet oder für das <WKR>-Element in Attribut B der WorkerLastName und in Attribut C
der WorkerFirstName. Insgesamt beinhaltet das in der Norm beschriebene Datenmodell derzeit 57 Elemente
und 264 Attribute.
Die Struktur der ISOXML-Dateien wird neben der Beschreibung im Normendokument in einem XML-Schema
spezifiziert
8
. Die Struktur ist mithin festgeschrieben und ändert sich in der Regel nur bei einer Revision der
Norm im Abstand von mehreren Jahren. Da solche zeitlichen Abstände die Einbindung von Daten von neu
entwickelten Sensoren behindern würden, wurde für die Aufzeichnung von Prozessdaten neben Elementen
und Attributen eine weitere Ebene eingeführt, die sich flexibler erweitern lässt. In einem Data Dictionary
werden für Prozessdaten wie Kraftstoffverbräuche, ausgebrachte Mittelmengen, eingefahrene Erntemengen
usw. Schlüsselnummern definiert. Während der Durchführung der Feldarbeiten können die zugehörigen
Werte dann gemeinsam mit den Schlüsselnummern abgelegt werden – entweder in den XML-Dateien für
gesamte Tasks oder für häufig aufgezeichnete Werte, die in größerer Menge anfallen, zugewiesen zu GPS-
Zeit- und Ortsstempeln für punktgenaue Werte in einer begleitenden, kompakt binär kodierten Datei. Das
Data Dictionary ist öffentlich zugänglich
9
und beinhaltet Stand 21.06.2021 insgesamt 647 Einträge sowie
einige technische Schlüssel und reservierte Bereiche. Außerdem wird auch die Aufzeichnung der Daten vom
CANBUS aus der Automotive-Norm SAE J1939 unterstützt. Werden diese mitgerechnet, können potenziell
18.552 weitere Datenfelder (PGN/SGN) mit aufgezeichnet werden.
10
7
http://www.w3.org/TR/xml11
8
https://www.isobus.net/isobus/file/supportingDocuments
9
https://www.isobus.net/isobus/exports/completeTXT
10
s.
https://www.isobus.net/isobus/pGNAndSPN

Schriftenreihe des LfULG, Heft 4/2022 | 20
Anhang 2.1 enthält eine aufbereitete Fassung des ISO11783 Data Dictionary im Tabellenblatt „ISOBUS DDIs“.
Spalte A weist die Schlüsselnummer und Spalte B die Bezeichnung aus dem Data Dictionary aus. Die weiteren
Spalten wurden über ein Skript durch Textzerlegung erzeugt und ermöglichen es, die Einträge nach verschie-
denen Kriterien zu filtern. Für eine Reihe von Parametern können verschiedene Arten von Werten übertragen
werden: Setpoint als Einstellwert, Maximum, Minimum usw. Für Auswertungszwecke im Nachgang sind Ein-
stellwerte oft weniger relevant; wichtig sind in dem Fall hingegen Gesamtmengen (Total) sowie tatsächliche
(Actual) und momentane (Instantaneous) Werte. Außerdem sind Werte verschiedener Lifetime Totals interes-
sant für die Ermittlung von Kenngrößen im Rahmen der später noch näher skizzierten Maschinenparkauswer-
tung. Über Spalte C lassen sich mögliche Größen filtern, die grundsätzlich von Maschinen normiert geliefert
werden könnten, danach filtern. Spalte D weist die erhobenen Parameter ohne Einheitenangaben und die
Information, ob es sich um Gesamtsummen, Maxima usw. handelt, aus. Hierüber kann also nach gesuchten
agronomischen Werten gefiltert werden (z. B. alle Applikationsraten, alle Erntemengenparameter etc.). Die
folgenden Spalten ermöglichen die Filterung nach sogenannten Device Classes. Diese fassen bestimmte Ma-
schinenkategorien zusammen. Hierüber lässt sich ermitteln, welche Werte beispielsweise für Düngerstreuer
(Fertilizer) normiert und damit grundsätzlich lieferbar sind. Zu beachten ist dabei, dass diese Einträge lediglich
indikativ sind. Im Data Dictionary heißt es hierzu: „Typically used by Device Classes“ – d. h. es kann theore-
tisch Maschinen anderer Device Classes geben, die für diese DDI Werte liefern können, auch wenn hier kein
Eintrag besteht. Die letzte Spalte des Tabellenblattes führt die URL auf, unter der gegebenfalls weitere Infor-
mationen zu einem Eintrag abgerufen werden können. Technische Informationen wie Wertebereiche und Ein-
heiten wurden im Tabellenblatt nicht berücksichtigt, können dort aber aufgefunden werden.
2.1.2.5 ADED
Im Rahmen der ISOagriNet-Initiative wurde versucht, ein ähnliches System wie den ISOBUS für die Innen-
wirtschaft, d. h. im Wesentlichen zum Datenaustausch und zur Vernetzung von Anlagen für die Tierhaltung
(z. B. Klimacomputer, Fütterungsautomaten, Melkanlagen usw.) zu entwickeln. Entstanden sind hierbei die
Agricultural Data Interchange Syntax (ADIS) und das Agricultural Data Element Dictionary (ADED). Das
System ist daher auch unter dem Namen ADIS / ADED bekannt und wird heutzutage unter anderem in der
Zuchtwertschätzung, Milchleistungsprüfung und in der Plattform HI-Tier eingesetzt. Die Arbeiten haben über
die ISO-Normen 11787, 11788 und 17532 Eingang in die Normung gefunden. ADIS / ADED beinhaltet eine
eigene Formatspezifikation, die auf Nachrichten in einem an Datenbankrecords angelehnten Textformat
beruht. Aufbauend darauf wurden später auch Möglichkeiten geschaffen, Daten über Webdienste und Web-
schnittstellen und in diesem Umfeld gängige Formate wie XML oder JSON auszutauschen. Die fachlichen
Inhalte sind ähnlich wie beim ISOBUS in einem Data Dictionary festgehalten. Bis 2018 erfolgte die Pflege
durch den LKV NRW und einige Informationen finden sich auch nach wie vor auf den dortigen Webseiten
11
.
Zwischenzeitlich wurde das Data Dictionary ins DLQ Datenportal übernommen und kann im dortigen Data
Dictionary Manager abgerufen werden
12
. Der Aufbau unterscheidet sich insofern vom Data Dictionary von
ISO11783, als auch die nächste Stufe über den Einzelattributen – hier Items genannt – im Data Dictionary
mit abgebildet wird. Diese nächsthöhere Ebene sind die sogenannten Entities. Letztere haben meist ent-
weder den Charakter von Records, d. h. Datenzeilen, wie man sie auch in einer Datenbank ablegen würde,
11
http://ian.lkv-nrw.de/index.php?id=308
12
https://www.dlqdata.de/ddm/pages/public/dictionarymgmt/dictionaries.xhtml

Schriftenreihe des LfULG, Heft 4/2022 | 21
oder den Charakter von Nachrichten. Jeder Entity sind bestimmte Items – Datenfelder – zugewiesen, wobei
auch Mehrfachzuweisungen erfolgen können, d. h. ein Item kann in mehreren Entities verwendet werden. So
wird z. B. die Rind-ID – die Ohrmarkennummer – naturgemäß in einer ganzen Reihe von Entities für ver-
schiedene Datenaustauschzwecke benötigt.
Das Tabellenblatt „ADED Items“ in Anhang 2.1 beinhaltet eine Aufbereitung des ADED Data Dictionary –
aufgrund des etwas anderen Aufbaus des Data Dictionary jedoch etwas anders aufgebaut als das Blatt
„ISOBUS DDIs“. Auch hier werden Einträge über eindeutige Schlüsselnummern identifiziert, die sich in Spal-
te A finden. Zudem sind englische Kurzlabel und deutsche Bezeichnungen vorhanden. Spalte D weist den
Datentyp aus. Dieser kann bei der Interpretation der in der veröffentlichten Fassung recht knappen Bezeich-
nungen teilweise helfen. Der Datentyp „Code“ weist hierbei darauf hin, dass für das Item eine Codeliste
existiert, d. h. es dürfen nur Werte aus dieser Liste für dieses Datenfeld verwendet werden. Die Codelisten
selbst sind hier nicht mit aufgenommen, können aber über den o.g. Data Dictionary Manager beim DLQ ab-
gerufen werden. Die übrigen Spalten führen die Entities in alphabetischer Reihenfolge auf, sodass sich filtern
lässt, welche Datenfelder beispielsweise für eine Schlachtmeldung an HI-Tier (Entity 882084) zu übermitteln
sind. Das ADED enthält in der Fassung für 2022 insgesamt 1.184 Unique Items und 138 Entitäten.
2.1.2.6 Weitere Datenmodelle und spezifische Formate
Neben den beiden hier detaillierter beschriebenen, standardisierten Datenmodellen für Schnittstellen exis-
tieren eine Reihe weiterer Initiativen und Projekte, die agrarische Datenmodelle entweder für Schnittstellen
oder für Datenbanksysteme entwickelt haben oder deren Modelle eine Reihe für die Landwirtschaft relevan-
ter Objekttypen und Attribute enthalten. So wurde an der Universität Halle im Jahr 2008 im Rahmen einer
Promotionsarbeit ein relationales Datenmodell für die Milchviehhaltung entwickelt, das für wichtige, tat-
sächlich realisierte und relevante Anwendungsfälle die erforderlichen
13
. Dieses beinhaltet 9 Teilverfahren,
37 Prozesse, 46 Merkmalskomplexe, 7 Objekte, 46 Merkmalsgruppen und 500 Merkmale. Im Rahmen des
vom BMBF finanzierten Projekts SimLearn wird derzeit ein ontologiebasiertes Datenmodell entwickelt. Ziel
ist es dabei, Daten für die Entscheidungsunterstützung für Betriebe über Simulationsmodelle, agentenbasier-
te Modellierung und neuronale Netze in variierenden Kombinationen abzubilden. Inhaltlich abgedeckt wer-
den dabei die Themenbereiche Betrieb, Parzellen, Feldfrüchte, Boden, Wetter, Prozesse und Maschinen.
Das Modell besteht derzeit aus 49 Klassen und 611 Properties, die die Modellparameter abbilden. Für eine
Reihe von praktischen Fragen der Betriebsführung sind zudem Geodaten relevant. Öffentliche Geodateninf-
rastrukturen müssen sich dabei an der INSPIRE-Richtlinie der EU orientieren. Eine Analyse, welche Teil-
mengen aus den vorliegenden
14
für Geodatenanwendungen im Betriebsmanagement in der Landwirtschaft
relevant sind, wurde nicht durchgeführt. Eine Reihe der INSPIRE-Themen werden aber berührt. Weil Ab-
standsauflagen im Pflanzenschutz Siedlungen, Landschaftselemente und Gewässer betreffen, sind mindes-
tens diese Bereiche relevant. Das Verkehrswegenetz kommt für logistische Fragestellungen hinzu.
Künftig werden mit der Verbreitung von Technologien wie Sensoren, Remote Sensing über Drohnen und
Satelliten usw. sicher weitere Daten hinzukommen, die jeweils weitere, eigene Attribute beinhalten.
13
Christian Schulze (2008): Hybride Modellierung operativer und analytischer Daten, dargestellt am Beispiel des Precision
Dairy Farming. Dissertation, Martin-Luther-Universität Halle.
14
https://inspire.ec.europa.eu/Themes/Data-Specifications/2892

Schriftenreihe des LfULG, Heft 4/2022 | 22
Außerdem sind für das landwirtschaftliche Datenmanagement Standards der Buchhaltung, wie z. B. der
Kontenrahmen für land- und forstwirtschaftliche Betriebe
15
, der die Kontenschlüssel ausweist, zu berücksich-
tigen. Als Formatspezifikationen sind im Bereich der Buchhaltung die XML Business Reporting Language
(XBRL)
16
und die Formate und APIs der DATEV zu erwähnen. Die DATEV ist ein deutsches Softwarehaus
und IT-Dienstleister für Steuerberater, Wirtschaftsprüfer und Rechtsanwälte sowie deren zumeist mittelstän-
dische Mandanten und ist als eingetragene Genossenschaft organisiert
17
. Die XBRL wurde ursprünglich
dafür konzipiert, Jahresabschlüsse und -bilanzen für die Finanzberichterstattung zu übertragen – beispiels-
weise zur Unterstützung der Offenlegungspflichten für börsennotierte Unternehmen. Durch das einheitliche
Format soll eine bessere Vergleichbarkeit der Daten gegeben sein. XBRL wird durch ein internationales
Konsortium mit nationalen Zweigorganisationen gepflegt und dementsprechend auch in einer Reihe von
Ländern weltweit genutzt. In Deutschland ist gemäß Einkommenssteuergesetz §5b für buchführungspflichti-
ge Unternehmen die Übermittlung der Jahresabschlüsse im XBRL-Format vorgeschrieben. Es existiert au-
ßerdem die Erweiterung XBRL Global Ledger, die über die zusammenfassende Information von Abschlüs-
sen hinausgehend ebenfalls die standardisierte Übertragung auch einzelner Transaktionen/Buchungen und
ihrer Begleitdaten unterstützt
18,19
. Die Spezifikationen des Formates sind komplex, da intensiv auch Quer-
verweise genutzt werden und zu berücksichtigen ist, dass teils national unterschiedliche Taxonomien mit
eingebunden werden müssen. Jedoch sind alle relevanten Dokumente frei und offen ohne Restriktionen der
Nutzung und Weiterverteilung zugänglich
20
. Auf github finden sich eine Reihe an Quellcode-Repositorien mit
Umsetzungen von verschiedenen XBRL-Werkzeugen für unterschiedliche Programmiersprachen und ent-
sprechende Beispiele.
Die DATEV bietet eine Reihe von Produkten, Werkzeugen und Dienstleistungen rund um Buchhaltung und
Rechnungswesen an, hierzu gehören auch Export- und Importschnittstellen und APIs. DATEV hat einen
Entwicklerbereich eingerichtet
21
, für den Zugang ist eine Registrierung notwendig. Die Beschreibung des
DATEV-CSV-Formates ist jedoch aktuell ohne Login zugänglich
22
und auf github ist auch Quellcode zur
Verarbeitung auffindbar. Gemäß den Allgemeinen Geschäftsbedingungen der DATEV
23
unterliegt die Nut-
zung von bereitgestelltem Material und Diensten einer Reihe von Einschränkungen: so ist beispielsweise
eine Weitergabe an Dritte nicht zulässig, und die Anbindung von angebotenen Clouddiensten über automati-
sierte APIs erfordert gesonderte Vereinbarungen. Das Leistungsportfolio der DATEV ist umfangreich und
insbesondere mit Blick auf Funktionalitäten, Nutzungsbedingungen und entstehende Kosten einzelner An-
gebote nur schwer durchschaubar. Für die Schnittstellenlösung DATEVconnect wird für die Überlassung der
15
https://www.datev.de/web/de/datev-shop/material/kontenrahmen-skr-14-fuer-land-und-forstwirtschaftliche-betrieb/
16
https://www.xbrl.org/
17
https://www.datev.de/web/de/m/ueber-datev/das-unternehmen/fakten-und-informationen/
18
https://www.xbrl.org/the-standard/what/global-ledger/
19
https://www.xbrl.org/int/gl/2016-12-01/gl-framework-2017-PWD-2016-12-01.html
20
https://specifications.xbrl.org/
21
https://developer.datev.de/portal/
22
https://developer.datev.de/portal/de/dtvf
23
https://www.datev.de/web/de/media/datev_de/pdf/agb_2018_deutsch_web.pdf

Schriftenreihe des LfULG, Heft 4/2022 | 23
Schnittstellendokumentation beispielsweise ein Überlassungsgebühr von derzeit 25,- EUR pro Monat er-
hoben
24
zudem sind weitere DATEV-Programme notwendig
25
. Für Softwareanbieter ist für die Nutzung be-
stimmter Leistungen die Teilnahme an einem Partnerprogramm Voraussetzung
26
, einige Öffnungen des
DATEV-Ökosystems sind jedoch für 2022 angekündigt
27
.
2.1.2.7 Schlussfolgerungen und Zwischenfazit
Die Überlappung der genannten Datenmodelle wurde wegen methodischer Schwierigkeiten nicht systema-
tisch erhoben, beträgt geschätzt aber wenige % bis ~30 % – zumindest bei den Betriebsstammdaten wie
Betriebsnummern, Adressinformationen usw. sind Ähnlichkeiten in den Datenmodellen offensichtlich. Aber
selbst, wenn es nahezu vollständige Überlappungen geben würde, würde dies für das Datenmanagement
nur bedingt helfen, da keine Zuordnungen und Mappings zwischen Standards vorhanden sind. Je nach Aus-
stattung, Größe, Zielen und Produktionsprogramm fallen in den Betrieben unterschiedliche Teilmengen an
digital erfassten Datenattributen aus verschiedensten Standards, Datenformaten und Spezifikationen an, die
von 0 für nicht digitalisierte Betriebe bis zu potenziell mehreren Tausend für Betriebe mit einer umfassenden
Digitalisierung reichen. Die Daten sind dabei verteilt über Systeme verschiedener Softwareklassen, die ihrer-
seits auch wieder nur jeweils bestimmte Teilmengen verwalten – z. B. nur für den Pflanzenbau, nur für die
Tierhaltung oder nur für die Buchhaltung notwendige Daten. Die Überlappungen führen dabei zu doppelter
Datenhaltung (und ggfs. auch Eingabe), während die nicht überlappenden Bereiche für andere Softwarean-
wendungen nicht nutzbar sind. Dieser Zustand stellt für die Entwicklung eines allgemein anwendbaren be-
trieblichen Datenmanagements eine beträchtliche Herausforderung dar. Ein Datenmanagement muss es
ermöglichen, aus den anfallenden Datenströmen automatisiert die für die Auswertung relevanten Datenfel-
der und zugewiesenen Werte herauszupicken. Bei der Umsetzung ist es daher notwendig, tatsächlich die
Gesamtheit der in den zu betrachtenden Formaten vorhandenen Attribute zu kennen, um eine informierte
Auswahl durch einen Algorithmus überhaupt entwickeln zu können.
In den Abschnitten 3.1.1 und insbesondere 3.2.12 wird aufgezeigt, wie sich durch eine Synthese von Pro-
zessmodellen sowie dem durch die Auswertungsziele (Ziel- und Kenngrößen) gegebenen Datenbedarf aus
dem in einem umfassenden, ausreichend detaillierten Datenkatalog erfassten Datenangebot tatsächlich
relevante Elemente identifizieren sowie Anforderungen und auch mögliche Problemfelder ableiten lassen.
24
https://www.datev.de/web/de/top-themen/unternehmer/weitere-themen/neue-schnittstellentechnologie/datevconnect/
25
https://apps.datev.de/help-center/documents/0904166
26
https://www.datev.de/web/de/ueber-datev/datev-oekosystem/datev-und-partner/datev-marktplatz/infos-fuer-software-
hersteller/
27
https://developer.datev.de/portal/de/node/23201

Schriftenreihe des LfULG, Heft 4/2022 | 24
2.1.2.8 Generelle technologische Aspekte von Datenformaten
Für die technische Ausgestaltung von Datenformaten kann heutzutage auf eine Reihe von Methoden zu-
rückgegriffen werden. Die generelle Problemstellung dabei ist, Zeichenketten gemäß gewisser syntaktischer
Regeln in eine einheitliche, strukturierte Reihenfolge zu bringen, sodass diese über Ein- und Ausgabe-
schnittstellen korrekt und effizient gelesen und geschrieben werden können. Als Forschungsfragestellung
wurde dieses Feld seit den Anfängen der Informatik bereits in den 1950er Jahren bearbeitet. Die theore-
tischen Grundlagen sind mittlerweile gut verstanden und es wird in der Regel heutzutage auf formale Gram-
matiken oder Systeme auf Basis von Schemas zurückgegriffen, die eine weitgehend automatisierte oder
zumindest stark erleichterte Erzeugung von notwendigem Programmcode bei der Entwicklung von Schnitt-
stellen erlauben. Die Bandbreite geht bei textbasierten Formaten von einfachen Ansätzen für tabellarische
Datenauflistungen wie Comma Separated Values (CSV)
28
über an Datenstrukturen in Programmiersprachen
orientierten Systemen wie JavaScript Object Notation (JSON)
29
bis hin zu relativ komplexen Auszeichnungs-
sprachen wie der eXtensible Markup Language (XML)
30
. Eine solche textbasierte Kodierung hat den Vorteil,
dass es möglich ist, Dateien mit einem einfachen Standardtexteditor zu öffnen, zu durchsuchen und zu be-
arbeiten, was bei der Entwicklung von Schnittstellen für Fehlersuche und Prüfung von Strukturen hilfreich
sein kann. Binäre Formate, die Daten maschinennäher aber für Menschen wenig lesbar kodieren, wurden
lange Zeit eher vermieden, gewinnen aber aktuell wieder an Bedeutung, da sich mit ihrer Hilfe Daten teils
deutlich platzsparender und schneller „verpacken“ lassen, was bei großen Datenmengen oder begrenzten
möglichen Datenraten in Netzwerken wichtige Anforderungen sein können. Beispielsweise steht mit pro-
tobufs
31
eine anhand einer Reihe offener Referenzimplementierungen sowie sehr guter Dokumentation und
mit Hilfe von ebenfalls bereitgestellten Werkzeugen zur Erzeugung von Programmcode sehr gut handhab-
bare Technologie zur einfachen Erstellung von sehr kompakt kodierten, binären Datenformaten zur Verfü-
gung. Protobufs werden im landwirtschaftlichen Kontext beispielsweise im AEF EFDI-Format genutzt.
Grundsätzlich ist zu unterscheiden zwischen der Formatspezifikation mittels beispielsweise eines Schemas
und den „Instanzdaten“, also einer Ausgabe eines Softwaresystems in einem Format mit enthaltenen Daten.
Für XML beinhalten letztere zwar implizit auch die Datenstruktur. Dabei müssen aber nicht alle für das Da-
tenformat erlaubten Elemente und Attribute auch tatsächlich vorkommen. Ein XML Schema hingegen be-
schreibt das Datenformat praktisch vollumfänglich mit allen erlaubten Strukturen, teilweise auch einschließ-
lich technischer Details wie Datentypen einzelner Felder. Das eine XML-Format existiert hierbei nicht, son-
dern es gibt verschiedene “Dialekte”: ISOXML beinhaltet andere Elemente und Attribute als beispielsweise
eine DATEV-XML-Schnittstelle, obwohl beide auf der gemeinsamen Syntax XML aufsetzen. Eine vollständi-
ge, korrekte Umsetzung eines solchen Dialektes ist nur anhand des Schemas oder einer vergleichbaren
Spezifikation möglich. Für eine offene Schnittstelle sollten diese Informationen daher bereitgestellt werden.
28
https://www.rfc-editor.org/rfc/rfc4180.txt
29
https://www.json.org/json-de.html
30
https://www.w3.org/TR/xml11/
31
https://developers.google.com/protocol-buffers

Schriftenreihe des LfULG, Heft 4/2022 | 25
Im Allgemeinen stellt die Umsetzung von Programmcode zum Lesen und Schreiben von Formaten gemäß
oben genannter Technologien bei Vorliegen von Spezifikationen wie z. B. Schemas und angemessener
Dokumentation für einen Softwareentwickler heutzutage kein allzu großes Hindernis dar. Gängige Program-
miersprachen bieten häufig schon in den Standardbibliotheken Funktionen und/oder Methoden zur Unter-
stützung des Lesens und Schreibens für CSV, JSON oder XML-Daten. Auch für viele weniger weit verbreite-
te, alternative Datenformate lassen sich oft Bibliotheken finden. Je nach vorgegebener Programmiersprache
und Erfahrung des Entwicklers liegt der Aufwand dafür, beispielsweise Daten in einem der drei genannten
textbasierten Formate grundsätzlich so einzulesen, dass bestimmte Datenfelder extrahierbar sind, zwischen
wenigen Minuten bis zu einigen Tagen. Die Herausforderungen bei der Schaffung von Schnittstellen liegt
heutzutage nicht mehr in der Handhabung des syntaktischen Datenformates und der darin kodierten Daten-
strukturen. Die Repräsentation der Daten im Format spielt zwar im Hinblick auf die sogenannte “Aus-
drucksfähigkeit” oder Expressivität einer Sprache durchaus eine gewisse Rolle, gängige Schnittstellen-
technologien sind mit Blick auf diesen Faktor aber auf recht ähnlichem Niveau. Ein wichtigeres Kriterium
kann tatsächlich der oben angerissene Aspekt der Effizienz der Kodierung sein - für EFDI hat die Über-
legung, dass Telemetriedaten teils über Netze mit geringen Datenraten übertragen werden müssen, bei
der Auswahl der Technologie zur Spezifikation des Formates durchaus eine Rolle gespielt. Dazu wurden
(unveröffentlichte) vergleichende Vorabuntersuchungen mehrerer Formatoptionen sowohl mit Blick auf
erzeugten “Overhead” im Datenvolumen als auch der Performanz der Erzeugung und des Einlesens der
Datenpäckchen durchgeführt.
Der eigentliche Aufwand einer Schnittstellenentwicklung liegt in der Regel vielmehr in der Anbindung an die
interne Programmlogik. Dafür ist es notwendig, die Bedeutung von im jeweils spezifischen Format vorhan-
denen Datenfeldern zu kennen, richtig zu interpretieren und korrekte Zuordnungen zur internen Daten-
haltung herzustellen. Dafür benötigen Entwickler gut lesbare, für eine schnelle Orientierung strukturiert auf-
bereitete und einfach zugängliche Dokumentation. Diesem Aspekt ist daher eine höhere Bedeutung beizu-
messen als der reinen Frage, ob CSV, JSON oder XML genutzt wird. Auch die Heterogenität verschiedener
Schnittstellen spielt eher eine Rolle: für n unterschiedliche Schnittstellen muss auch n-mal die Dokumen-
tation gelesen und verstanden werden. Unterstützt werden kann der Entwicklungsprozess durch formale
Datenbeschreibungen mit semantischen Technologien (höherer Expressivität), die über die Beschreibung
der Struktur eines Datenformates hinausgehen und Zusammenhänge zwischen Datenfeldern und beispiels-
weise auch Mappings zwischen verschiedenen Standards darstellen können.
2.2 Softwaresysteme im landwirtschaftlichen Kontext
Abbildung 5 zeigt die beispielhafte betriebliche Landschaft der Softwaresysteme für einen landwirtschaft-
lichen Gemischtbetrieb als Ausgangssituation für ein Datenmanagement und illustriert die Komplexität des
Gesamtsystems mit seinen vielfältigen Funktionsbereichen von der Ackerschlagkartei bis zum Herdenma-
nagement, hier auch als Systemklassen bezeichnet. Auf dem Markt wiederum wird ein breites Spektrum an
Softwaresystemen angeboten, welche jeweils einer oder mehreren Systemklassen zuzuordnen sind bzw.
je einen oder mehrere Funktionsbereiche in unterschiedlichem funktionalen Umfang umfassen. Die Soft-
wareklassen sind zur Kategorisierung der verschiedenen Anwendungsebenen, die teilweise mit Betriebs-
zweigen übereinstimmen (Pflanzenbau, Tierhaltung), farblich gemäß Legende differenziert. Die im Rah-
men dieser Machbarkeitsstudie gemäß Leistungsbeschreibung zu betrachtenden Softwareklassen sind fett
hervorgehoben.

image
Schriftenreihe des LfULG, Heft 4/2022 | 26
Die Pfeile symbolisieren den Bedarf an Datenaustausch zwischen den verschiedenen Systemen, der aktuell an
vielen Stellen so nicht oder nur eingeschränkt medienbruchfrei realisiert ist. Es handelt sich somit um eine
Darstellung des Ziels der Vernetzung der Softwaresysteme mit einer perspektivischen, idealen Verknüpfung.
Abbildung 5: Beispielhafte betriebliche Softwarelandschaft für einen Gemischtbetrieb
Im Folgenden wird auf die einzelnen Systemklassen von landwirtschaftlichen Softwaresystemen, auf An-
sätze aus Industrie und Forschung im Kontext des Datenmanagements sowie die damit verbundene IT-
Infrastruktur eingegangen.

Schriftenreihe des LfULG, Heft 4/2022 | 27
2.2.1 Katalog Fachsoftware
Die Recherche und Katalogisierung landwirtschaftlicher Softwaresysteme nimmt Bezug auf die für das Daten-
management gemäß Leistungsbeschreibung vorgesehene Grundstruktur von 19 Softwareanwendungen. Ge-
gliedert nach den dort aufgeführten sieben Systemklassen bzw. Funktionsbereichen
Ackerschlagkartei
Precision Farming
Warenmanagement
Flottenmanagement
Buchhaltung
InVeKoS
Banken
erfolgt eine Betrachtung verschiedener typischer Softwaresysteme in Bezug auf
Schnittstellen
Ziel-/Quellensystem (Schnittstelle zu…)
Art der Schnittstelle (API, manuell)
Offene Schnittstelle (Open Source)
Richtung des Datenaustauschs
ausgetauschte Daten (je Import/Export)
Datenformat
Datenart (bspw. Auftrag, Telemetriedaten, georeferenzierte Daten)
Daten (konkrete Information, bspw. aktueller Kraftstoffverbrauch, Schlaggrenze)
relevante Arbeitsprozesse (Fokus auf exemplarische Prozesse, Abschnitt 3.1).
Der Katalog ist diesem Abschlussbericht filterbar digital im Format .xlsx beigefügt. Er ist als Zusammenstel-
lung einiger Vertreter von Softwaresystemen der unterschiedlichen Systemklassen ohne Anspruch auf Voll-
ständigkeit zu betrachten und beinhaltet auch Ergebnisse von Eckelmann
32
. In dieser Machbarkeitsstudie
dient er dem prinzipiellen Überblick über die landwirtschaftliche Softwarelandschaft und die damit verbun-
denen Schnittstellen und Daten als Grundlage für das Datenmanagement. Der Katalog bildet den Stand zur
Bearbeitung dieser Studie ab, Änderungen bzgl. Schnittstellen und ausgetauschter Daten sind jedoch sehr
dynamisch. Er kann als weiterzuführender, zu detaillierender und kontinuierlich zu aktualisierender Vor-
schlag für die Systematisierung landwirtschaftlicher Softwaresysteme mit ihren im Wesentlichen Interopera-
bilität betreffenden Eigenschaften im Hinblick auf Medienbrüche und das betriebliche Datenmanagement
betrachtet werden. Durch die Zuordnung der je Softwaresystem verfügbaren Schnittstellen und Daten zu
relevanten Prozessen, bei denen diese eine Rolle spielen, ergibt sich eine Verknüpfung mit den Prozess-
32
Eckelmann, M. (2020): Marktübersicht und Nutzwertanalyse deutschsprachiger Farmmanagement Informationssysteme,
Masterarbeit, Martin-Luther-Universität Halle-Wittenberg.

Schriftenreihe des LfULG, Heft 4/2022 | 28
darstellungen. Aus den Prozessen, den dabei beteiligten Daten, Softwaresystemen und Schnittstellen folgen
wiederum Aspekte für das Datenmanagement.
Die Dichte der Informationsverfügbarkeit im Katalog der Softwaresysteme nimmt mit steigendem Detailgrad
deutlich ab. Angaben zu den ausgetauschten Daten, insbesondere im Hinblick auf Formate und enthaltene
Informationen sowie deren konkreter Struktur sind nur durch detaillierte Spezifikationen von den jeweiligen
Anbietern zu vervollständigen. Dementsprechend ist auch die Prozesszuordnung mit Unschärfen belegt. Aus
Fachgesprächen mit Softwareanbietern zeigte sich auch, dass sich vereinzelte Schnittstellenangaben nicht
auf eine direkte Datenaustauschmöglichkeit beziehen, sondern unter Umständen einen praxistauglichen
„Workaround“ zum Datentransfer darstellen können.
Im Folgenden werden Softwaresysteme aus den obengenannten Systemklassen charakterisiert.
2.2.1.1 Ackerschlagkarteien
Ackerschlagkarteien sind für Landwirtschaftsbetriebe das zentrale Werkzeug zur schlagbezogenen sowie
gesamtbetrieblichen Planung und Aufzeichnung aller Maßnahmen in der Pflanzenproduktion. Mithilfe der in
Ackerschlagkarteien erfassten Daten kann die Pflanzenproduktion überwacht und optimiert werden. Darüber
hinaus fällt auch die Dokumentation gemäß Cross-Compliance-Richtlinien in den Aufgabenbereich dieser
Softwaresysteme. In der Ackerschlagkartei werden Stammdaten wie eingesetzte Betriebsmittel, Maschinen
und Schläge gepflegt. Hier erfolgt üblicherweise auch die Fruchtfolgenplanung.
Der Katalog der Softwaresysteme umfasst zwölf Ackerschlagkarteien, wobei die reinen Cloudlösungen mit
neun Programmen dominieren. Drei Systeme können lokal installiert oder auch als Webversion oder mobil
eingesetzt werden.
Bei den Ackerschlagkarteien sind im Wesentlichen zu unterscheiden: umfangreiche Systeme großer An-
bieter (bspw. 365FarmNet), die durch offengelegte proprietäre Schnittstellen Partnerunternehmen ermögli-
chen, sich an ihr „Ökosystem“ anzubinden oder Farmfacts mit NEXT Farming, wo Schnittstellen für die Soft-
waresysteme zahlreicher Partnerunternehmen existieren. Ziel ist hier unter anderen auch die nur einmalige
Stammdateneingabe. Lediglich fünf der exemplarisch ausgewählten Ackerschlagkarteien verfügen über eine
Anbindung an den Agrirouter, bei einer Ausnahme ist aktuell nur der Datenimport (Datenempfang) möglich.
Die für die Agrirouter-API spezifizierten Formate werden dabei in sehr unterschiedlichem Maße abgedeckt.
33
Schnittstellen zu verbreiteten Buchhaltungslösungen werden von mehreren Ackerschlagkarteien angeboten.
Eine Exportmöglichkeit von textbasierten Dateien ist die Regel. Strukturen und Informationsgehalte lassen
sich oft nur im direkten Austausch mit den Softwareanbietern zu detaillieren.
33
DKE-Data GmbH & Co. KG (Hg.): Agrirouter - Marktplatz Agrar-Software. Online verfügbar unter: https://my-
agrirouter.com/marketplace/agrarsoftware/, letzter Zugriff am 17.08.2021.

Schriftenreihe des LfULG, Heft 4/2022 | 29
2.2.1.2 Precision Farming
Dem Funktionsbereich Precision Farming (auch Teilflächenmanagement) werden solche Softwaresysteme
zugeordnet, deren Hauptaufgabe es ist, teilflächenspezifische, d. h. ortsdifferenzierte pflanzenbauliche Maß-
nahmen wie Bodenbearbeitung, Aussaat, Düngung und Pflanzenschutz zu planen und durchzuführen. Um
aus georeferenzierten Daten wie Fernerkundungsdaten (UAV, Satellit), Bodendaten sowie Ertragskarten
resultierende teilflächenspezifische Informationen entsprechende standortangepasste Maßnahmen abzu-
leiten, sind agronomische Regeln hinterlegt. Das Spektrum reicht von auf einzelne Maßnahmen wie die Dün-
gung spezialisierte Software (bspw. atfarm für die Stickstoffdüngung) bis hin zu mehreren Maßnahmen um-
fassende Systeme (bspw. agriPORT für Grunddüngung, Stickstoffdüngung, Pflanzenschutz).
Der Katalog der Softwaresysteme umfasst vier Softwarelösungen für das Precision Farming (Cloudlösungen).
Die Herkunft aus der Spezialanwendung zeigt sich auch in einer überschaubaren Vielfalt an Schnittstellen.
Schwerpunkt bilden hier einfache Import- und Exportmöglichkeiten.
2.2.1.3 Warenmanagement
Das Warenmanagement umfasst die Kontrolle und Verwaltung des Bestandes und der Materialflüsse sämt-
licher Betriebsmittel wie Saatgut, Düngemittel (organisch, anorganisch), Pflanzenschutzmittel, Futtermittel
und Kraftstoffe. Zugänge, Verbrauch sowie Verkauf von Betriebsmitteln werden durch entsprechende Soft-
waresysteme erfasst. Ausbaustufen bis hin zu ERP-Systemen beinhalten Funktionen wie Kontrakt-, Auf-
trags- und Lagerverwaltung sowie Rechnungswesen.
Im Kontext des Datenmanagements ist an dieser Stelle auch Software von Wiege- und Tanksystemen
(exemplarisch Bitzer Web Agrar bzw. ForeHB) einzubeziehen.
Der Katalog der Softwaresysteme umfasst aus dem Funktionsbereich Warenmanagement vier Systeme, von
denen je zwei cloud- (Bitzer Web Agrar bzw. ForeHB) und desktopbasiert (LANDWEHR L3, PAARI Titan
Libra) sind, wobei letztere als auf die Bedürfnisse u.a. der Agrarbranche zugeschnittene ERP-Lösungen
eingeordnet werden.
2.2.1.4 Flottenmanagement
Flottenmanagement-Systeme unterstützen Überwachung und Einsatzoptimierung von Maschinen in land-
wirtschaftlichen Betrieben durch Flottenortung in Echtzeit. Teilweise ist die Einbeziehung von Anbaugeräten
und Sensoren oder auch der Austausch von Daten zwischen Maschinen möglich. Flottenmanagement-
Systeme erlauben die Dokumentation und Auswertung von Einsatzdaten wie Zeiten, Flächen, technologi-
schen Parametern und Betriebsmittelverbräuchen. Hardware- und maschinenseitig sind sogenannte Tele-
metrieeinheiten bzw. -verbindungen Voraussetzung für den Aufbau eines Flottenmanagement-Systems.
Neben herstellerspezifischen Systemen gibt es auch Anbieter, die mit ihren Lösungen unter Einsatz eigener
Telemetrieeinheiten (auch Datenlogger) ein herstellerübergreifendes Flottenmanagement anstreben.

Schriftenreihe des LfULG, Heft 4/2022 | 30
2.2.1.4.1
Herstellerspezifisches Flottenmanagement
Zahlreiche große Landtechnikhersteller bieten ein eigenes, cloudbasiertes Flottenmanagementsystem an,
beispielsweise:
AGCO/Fendt: Fendt Connect
CLAAS: Claas Telematics
CNH: AFS Connect™ (Case), PLM™ Connect (New Holland), S -Fleet (Steyr)
Deutz-Fahr: SDF Fleet Management
John Deere: JDLink
Deren Möglichkeiten zum Datenaustausch sind im Wesentlichen durch die Schnittstellen weiterer Anwen-
dungen (z. B. Ackerschlagkartei, Smart Farming-Plattform) aus dem Herstellerökosystem bedingt. Sechs der
hier genannten Systeme (sechs Flottenmanagementplattformen der Hersteller CLAAS/365FarmNet, CNH,
John Deere) lassen sich durch DataConnect miteinander verknüpfen, wobei hier aktuell nur die folgenden
fünf Maschinenparameter übertragen werden können: Maschinenposition, historischer Verlauf der Position,
Dieseltankfüllstand, aktueller Arbeitsstatus und Geschwindigkeit der Maschine.
34
Eine Agrirouter-Anbindung
gibt es derzeit für zwei Maschinenhersteller mit eigenen Flottenmanagementsystemen (AGCO, CNH).
2.2.1.4.2
Herstellerübergreifendes Flottenmanagement
Besondere Bedeutung im Kontext des Datenmanagements hat ein herstellerübergreifendes Flottenma-
nagement. Hierbei können neben GNSS-basierten Daten (Positionen, Richtungen, Geschwindigkeiten) und
motorspezifischen Daten in der Regel nur weitere standardisierte Informationen wie ISOBUS-Daten berück-
sichtigt werden. Prozessspezifische Parameter sind insbesondere bei selbstfahrenden Arbeitsmaschinen oft
proprietär kodiert und somit nicht ohne Weiteres verwendbar.
Beispiele für ein herstellerübergreifendes Flottenmanagement sind das System exatrek der EXA Com-
puting GmbH sowie Odokus mit verschiedenen Datenloggern von Hansenhof electronic.
2.2.1.5 Buchhaltung
Die landwirtschaftliche Buchhaltung umfasst neben der eigentlichen Buchführung als chronologische Auf-
zeichnung von anfallenden Geschäftsvorfällen (wie z. B. Einkauf, Verkauf, Lohnzahlungen, Wertminderun-
gen an Vermögensgegenständen) und damit der betrieblichen Zahlungsströme auch Kostenrechnung (Kal-
kulation), betriebswirtschaftliche Statistik (Vergleichsrechnung) und Planung (Vorschaurechnung). Sie ist
Basis für die Gewinnermittlung sowie den Geschäftsjahresabschluss. Buchhaltungssysteme haben die
Aufgabe, Rechnungen digital zu erstellen und zu verarbeiten sowie den digitalen Beleg-, Daten- und Doku-
mentenaustausch zwischen Landwirtschaftsbetrieb und Steuerberater zu gewährleisten. Die GoBD
35
-
34
Deere & Company (Hg.): DataConnect ist jetzt auf sechs digitalen Plattformen weltweit verfügbar, 02.07.2021. Online
verfügbar unter:
https://www.deere.de/de/unser-unternehmen/news-und-medien/pressemeldungen/2021/june/news-data-
connect.html, letzter Zugriff am 05.10.2021.
35
Grundsätze zur ordnungsmäßigen Führung und Aufbewahrung von Büchern, Aufzeichnungen und Unterlagen in
elektronischer Form sowie zum Datenzugriff (GoBD) – Verwaltungsanweisung des Bundesministeriums der Finanzen

Schriftenreihe des LfULG, Heft 4/2022 | 31
konforme Ablage ist ebenfalls zentrales Element. Auch eine Verknüpfung zum Online-Banking mit Abfrage
von Kontoumsätzen sowie Auslösen von Zahlungen kann enthalten sein.
Fünf der sieben betrachteten Buchhaltungssysteme sind als natives Desktopprogramm erhältlich. Das Spek-
trum reicht von der Software mit Schwerpunkt Belegmanagement für die Belegerfassung und -verwaltung
sowie den Zahlungsverkehr über Anwendungen, die Finanzbuchhaltung, Belegdigitalisierung, -management,
Liquiditätsplanung und Lohnbuchhaltung realisieren bis zu umfassenden ERP-Systemen.
Alle Anwendungen umfassen bereits eine Schnittstelle zum Online-Banking, womit im Zusammenhang einer
Belegdigitalisierung oft auch teilautomatisiert Zahlungen ausgelöst werden können. Typisch ist eine Daten-
austauschmöglichkeit zu ELSTER sowie zu Anbietern von Steuerberatersoftware (z. B. DATEV).
Außerdem bieten einige der betrachteten Softwaresysteme XBRL-Schnittstellen (XML Business Reporting
Language), s. Abschnitt 2.1.2.6.
2.2.1.6 Staatliche Systeme
Zur Abwicklung von Verwaltungsaufgaben (bspw. Beihilfezahlungen), zu Dokumentations- und Kontrollzwe-
cken (Tierhaltung) oder als Dienstleistungsangebot (bspw. Düngebedarfsermittlung) bietet auch der Freistaat
Sachsen Softwaresysteme an bzw. werden staatliche Softwaresysteme von sächsischen Landwirtinnen und
Landwirten genutzt.
2.2.1.6.1
Integriertes Verwaltungs- und Kontrollsystem (InVeKoS)
Das Integrierte Verwaltungs- und Kontrollsystem (InVeKoS) umfasst mehrere EU-Verordnungen als Kontroll-
instrument für die Agrarausgaben der EU.
An dieser Stelle liegt der Bezug auf Artikel 17 der Verordnung (EU) Nr. 809/2014. Demnach sind alle land-
wirtschaftlichen Parzellen zu erfassen, seit 2018 GIS-gestützt (geografisches Beihilfeformular). In Sachsen
stehen den Antragstellenden dafür das InVeKoS Online GIS
36
sowie DIANAweb
37
zur Verfügung.
Sächsische Landwirtinnen und Landwirte nutzen diese Systeme im Wesentlichen zur Bearbeitung und Ein-
reichung ihres jährlichen Antrags auf Direktzahlungen und flächenbezogene Agrarförderung. Hierzu werden
die jeweilig zu berücksichtigenden Flächen (Schläge, ökologische Vorrangflächen, Insekten- und Arten-
schutz-Streifen) angegeben und um weitere Informationen zur Nutzung (wie z. B. Kulturart) ergänzt.
DIANAweb und das InVeKoS Online GIS sind Webanwendungen mit einem Backend. Ein Datenaustausch
mit anderen Systemen kann über manuelle Dateiimporte und -exporte durchgeführt werden.
Ackerschlagkarteien bieten teilweise eine integrierte Exportfunktionalität für InVeKoS, welche die relevan-
ten Informationen im jeweils passenden Dateiformat bereitstellt. Möglicherweise können nicht alle darin
enthaltenen Angaben über die Importschnittstelle von InVeKoS bereitgestellt werden; diese sind dann
manuell zu ergänzen.
36
LfULG (Hg.): Online Geo-Informationssystem (GIS). Online verfügbar unter
https://www.landwirtschaft.sachsen.de/online-
geo-informationssystem-gis-9941.html, letzter Zugriff am 03.06.2021.
37
LfULG (Hg.): Antragstellung mit DIANAweb. Online verfügbar unter
https://www.diana.sachsen.de/index.html,
letzter Zugriff
am 03.06.2021.

Schriftenreihe des LfULG, Heft 4/2022 | 32
Ein Datenfluss von Drittsystemen nach DIANAweb erfolgt üblicherweise nur einmal im Jahr, um ebenjene
Daten für den Antrag bereitzustellen. Datenflüsse aus DIANAweb oder dem InVeKoS Online GIS heraus
sind denkbar, bspw. falls Landwirtinnen und Landwirte Systeme (wie eine Ackerschlagkartei) mit ihren Feld-
grenzen beziehungsweise Schlägen initial befüllen möchten, was allerdings nicht jährlich zu erwarten ist.
InVeKoS Online GIS
Die als Informationsportal bezeichnete Webanwendung InVeKoS Online GIS zur Unterstützung der Bean-
tragung flächenbezogener Direktzahlungen und Agrarförderung ist gegenüber DIANAweb das ältere System,
das Antragstellenden jedoch weiterhin zur Verfügung steht.
In das InVeKoS Online GIS können eigene Daten im ESRI-Shape-Format manuell importiert werden. Die
Daten dürfen in den Koordinatensystemen UTM33, Gauß-Krüger 4 oder Gauß-Krüger 5 vorliegen, innerhalb
des Systems wird mit UTM33 gearbeitet. Für jeden Geometrietyp (Flächen, Linien, Punkte) kann nur eine
Shape-Datei importiert werden bzw. es können nur deren Informationen angezeigt werden.
Eine Exportmöglichkeit besteht für Feldblöcke, gemeinsam mit zugehörigen Landschaftselementen und
ökologischen Vorrangflächen, im Shape-Format in UTM33 (Referenzsystem ETRS89). Es können einzelne
oder mehrere Feldblöcke heruntergeladen werden oder es können gleich alle Feldblöcke für einen ganzen
FBZ- (Förder- und Fachbildungszentrum) oder ISS-Bereich (Informations- und Servicestelle) des LfULG
gemeinsam exportiert werden.
Darüber hinaus können Schläge aus verschiedenen Jahresebenen (Flächen aktuelles Jahr, kombinierte
Schlagebene – bis 2015, qualifizierte Schlagebene – statt KSE ab 2016, Zwischenebene Landwirt) für den
Export (Shape, UTM33) ausgewählt werden.
Je nach Koordinatensystem (UTM33, Gauß-Krüger) und geodätischem Referenzsystem (ETRS89, WGS84)
müssen gegebenenfalls Transformationen ausgeführt werden.
DIANAweb
Das neuere DIANAweb umfasst ebenfalls eine Importschnittstelle (profil inet – WebClient DIANA) für eigene
Geometrien (Polygone, Punkte, Linien) als Shape-Dateien. Diese setzt Geometrien in UTM33 (Referenzsys-
tem ETRS89) voraus, welche als neuer Schlag oder – bei vorhandenen Schlaggrenzen – als ökologische
Vorrangfläche in DIANAweb übernommen werden können.
Neben dem Export einzelner oder mehrerer Schläge im Shape-Format gemeinsam mit verschiedenen Do-
kumenten (u.a. Sammelantrag, Flächenverzeichnis) im XML-Format mit nicht-veröffentlichten Schemas und
Spezifikationen der Struktur (s. auch Abschnitt 2.1.2.82.1.2.4), komprimiert in einer ZIP-Datei, erlaubt DIA-
NAweb auch die Ausgabe des Flächenverzeichnisses inklusive der Anlagen zu ökologischen Vorrangflächen
(EFA, Ecological Focus Area) sowie Insektenschutz und Artenvielfalt (ISA) zur Weiterverarbeitung in Excel.
2.2.1.6.2
Bilanzierungs- und Empfehlungssystem Düngung BESyD
Das Bilanzierungs- und Empfehlungssystem Düngung BESyD ist ein Angebot des Sächsischen Landesam-
tes für Umwelt, Landwirtschaft und Geologie (LfULG). Auf Basis von Microsoft Access wird eine umfangrei-
che Desktopapplikation geboten, die Landwirte bei einer ordnungsgemäßen Bedarfsermittlung, Dokumenta-
tion und Auswertung im Kontext der Düngung unterstützt.

Schriftenreihe des LfULG, Heft 4/2022 | 33
Der Datenaustausch mit BESyD ist ausschließlich über einen dateibasierten Import und Export möglich.
Hierzu wird ein textbasiertes Dateiformat verwendet.
38
Die Dateiinhalte sind proprietär strukturiert. Das be-
deutet: Systeme, die Daten für BESyD bereitstellen oder BESyD-Exporte konsumieren möchten, haben sich
nach den vorgegebenen Formaten, Strukturen und Inhalten gemäß der öffentlich verfügbaren BESyD-
Dokumentation zu richten. Die erforderlichen Informationen sind auf mehrere Textdateien verteilt. Manche
Softwaresysteme im landwirtschaftlichen Bereich, wie die GIS-Schlagkartei 9.0 oder NEXT Farming, unter-
stützen die Erzeugung und Konsumierung ebenjener Dateien. Nichtsdestotrotz müssen Landwirtinnen und
Landwirte alle Datenaustauschschritte manuell auslösen (Export aus Drittsystem, Import bei BESyD, Export
aus BESyD, Import bei Drittsystem
39
). Von Laboren im vorgegebenen Format bereitgestellte Ergebnisse der
Bodenanalyse können in BESyD als Textdatei genau wie in weiteren Dateien enthaltene Informationen im-
portiert werden, wobei keine Datenprüfung erfolgt. Zudem werden wöchentlich aktuelle Wetterdaten und
Prognosen durch das LfULG zum manuellen Import in BESyD als Acces-Datenbank bereitgestellt
40
, welche
auch nur dort nutzbar sind. Mit BESyD berechnete Düngeempfehlungen sind zur Weiterverarbeitung in an-
deren Systemen wie beispielsweise Ackerschlagkarteien oder Precision Farming-Software exportierbar.
2.2.1.7 Banken
Kontostände, Salden und Umsätze von Bankkonten eines Landwirtschaftsbetriebes spielen in der (Finanz-)-
Buchhaltung ebenso eine Rolle wie bei der Zielgrößenermittlung.
Auf diese Informationen kann zum einen aus beliebigen Programmen über eine API zugegriffen werden,
sofern diese dort implementiert ist. Dies wiederum macht sich dedizierte Banking-Software zu Nutze, welche
durch die Bereitstellung entsprechender Schnittstellen den Informationsaustausch zwischen weiteren Sys-
temen und der Bank ermöglicht.
2.2.1.7.1
Banking-Schnittstellen
EBICS
Der Electronic Banking Internet Communication Standard (EBICS) wurde von der Deutschen Kreditwirtschaft
(früher Zentraler Kreditausschuss) entwickelt und ist ein im DFÜ-Abkommen spezifizierter Internet-basierter
Kommunikationsstandard für die Umsetzung aller Geschäftsprozesse wie Lastschriften, Überweisungen,
Abruf von Kontoauszügen und Liquiditätsmanagement. Weiterentwicklung und Pflege des Standards erfol-
gen durch die EBICS-Gesellschaft, deren Mitglieder derzeit die Kreditwirtschaften von Deutschland, Frank-
reich, Österreich und der Schweiz sind.
41
38
Informationen zu BESyD-Import und Export zur Verfügung gestellt durch LfULG: BESyD2021_Datenimportexport.pdf
39
TLLR (Hg.): Düngebedarfsermittlung mit BESyD (Bilanzierung und Empfehlungssystem Düngung) TLLLR Referat 21.
26.02.2021. Online verfügbar unter
https://tlllr.thueringen.de/fileadmin/TLLLR/Themen/Landwirtschaft/Duengung/BESyD_Anleitung_Duengebedarfsermittlung_a
b2021.pdf, letzter Zugriff am 17.08.2021
40
LfULG (Hg.): Wetterdaten für die N-Düngebedarfsermittlung im konventionellen Landbau. Online verfügbar unter
https://www.landwirtschaft.sachsen.de/wetterdaten-fuer-die-n-duengebedarfsermittlung-im-konventionellen-landbau-
20629.html, letzter Zugriff am 17.08.2021
41
Die Deutsche Kreditwirtschaft (Hg.): EBICS - Electronic Banking Internet Communication Standard. Online verfügbar unter
https://www.ebics.de/de/startseite,
letzter Zugriff am 04.06.2021.

Schriftenreihe des LfULG, Heft 4/2022 | 34
HBCI
Bereits 1996 wurde mit dem Homebanking Computer Interface (HBCI) ein offener Online-Banking-Standard
veröffentlicht. FinTS (Financial Transaction Services) ist die Weiterentwicklung von HBCI, wobei eine Unter-
gliederung in der Gesamtspezifikation in die drei Bände Legitimationsverfahren (FinTS Security), Geschäfts-
vorfälle (FinTS Messages) und Finanzdatenformate (FinTS Formats) vorgenommen wurde, um deren Unab-
hängigkeit von dem zugrundeliegenden Protokoll zu gewährleisten. Unterstützt wurden mit dem PIN/TAN-
Verfahren (FinTS PIN/TAN) sowie Bankensignaturkarten (FinTS HBCI) zwei grundlegend verschiedene
Legitimationsverfahren. Durch die PSD2-Richtlinie (s.u.) mit den Vorgaben zur Starken Kundenauthentifizie-
rung ist seit 1. Januar 2021 nur noch das erste Verfahren zulässig.
Inzwischen ist der Standard vollständig in XML spezifiziert. FinTS wird derzeit von mehr als 2000 Kreditinsti-
tuten unterstützt und erlaubt den Zugriff auf viele Kontoarten wie Giro-, Spar- und Kreditkartenkonten.
42
PSD2
Seit Inkrafttreten der Zweiten Europäischen Zahlungsdienstrichtlinie (PSD2) müssen Banken Kontenschnitt-
stellen anbieten. Grundsatz ist das „Open Banking“, wonach von einer nationalen Bankenaufsicht und auf
eigenen Servern operierende zugelassene Dritte über eine kostenlose Bankenschnittstelle im widerrufbaren
Auftrag des Kunden auf dessen Konten (Zahlungskonten) zugreifen dürfen. Diese PSD2-Schnittstelle muss
von solchen Drittdienstleistern im Regelfall genutzt werden und die gleichen Funktionen/Vorgänge zur Ver-
fügung stellen wie die Hausbank, beispielsweise für das Einleiten von Zahlungen oder den Abruf von Konto-
informationen. PSD2 ist kein Standard und umfasst keine technischen Spezifikationen.
43
Die europäische
Initiative „Berlin Group NextGenPSD2“, gegründet von deutschen und österreichischen Kreditinstituten, ar-
beitet jedoch an einem offenen Standard „Access to Account (XS2A) Open Banking Framework“.
44
APIs gemäß PSD2 können sich von Bank zu Bank unterschieden, womit für Drittanbieter ggf. umfangreiche
technische und organisatorische Herausforderungen zu bewältigen wären.
Auf dem Markt existieren zudem bereits Anbieter, die eine universelle API zu einer Vielzahl von Banken für
Drittdienstleister anbieten und im Hintergrund die Kommunikation mit diesen regeln.
45 46
42
Die Deutsche Kreditwirtschaft (Hg.): FinTS. Online verfügbar unter
https://www.hbci-zka.de/,
letzter Zugriff am 28.05.2021.
43
Montz, Markus (2020): Neue und alte Banken-APIs – eine Übersicht. Online verfügbar unter
https://www.heise.de/hintergrund/Neue-und-alte-Banken-APIs-eine-Uebersicht-4907369.html,
letzter Zugriff am 04.06.2021.
44
The Berlin Group (Hg.): PSD2 Access to Bank Accounts. Online verfügbar unter
https://www.berlin-group.org/psd2-access-
to-bank-accounts, letzter Zugriff am 04.06.2021.
45
Fintecsystems (Hg.): Open Banking Plattform. Online verfügbar unter https://fintecsystems.com/open-banking-plattform/,
letzter Zugriff am 28.05.2021.
46
DKB (Hg.): API Store. Online verfügbar unter https://api.dkb.de/store/, letzter Zugriff am 04.06.2021.

image
Schriftenreihe des LfULG, Heft 4/2022 | 35
Abbildung 6: Gegenüberstellung von HBCI/FinTS und PSD2-Schnittstelle
47
Über die genannten Banking-Schnittstellen kann sich prinzipiell jede beliebige Software an die Online-
Banking-Systeme der Banken (Cloudsysteme) anbinden. Da spezielle Banking-Software und häufig auch
Buchhaltungsprogramme (s. 2.2.1.5) diese Schnittstellen bereits umsetzen, ist die Erfordernis von weite-
ren direkten Schnittstellen für einen direkten Abruf von Kontoständen und -umsätzen fraglich.
2.2.1.7.2
Banking-Software
Eine Banking-Software hat prinzipiell folgende Aufgaben:
Datenabruf (Kontostand, Kontoumsätze)
Einsicht in Transaktionen
Auslösen von Transaktionen
Einlesen von Rechnungen
Für die vier Desktopanwendungen des Katalogs der Softwaresysteme sind jeweils Schnittstellen zum Online-
Banking integriert. Neben dem manuellen Transfer von Daten wie Rechnungsinformationen zwischen wie-
teren Softwareanwendungen ist auch der Austausch zur Finanzbuchhaltung mit standardisierten Formaten
oder proprietären, auf verbreitete Buchhaltungssysteme zugeschnittenen Formaten, in der Regel gewährleis-
tet. Der teils automatisierte Export von neu eingegangenen Kontoinformationen aus der Banking-Software
kommt in Kombination mit vordefinierten Ablageverzeichnissen und einem ebenso automatischen Einlesen in
die Finanzbuchhaltung der Funktionalität einer API gleich.
47
Montz, Markus (2020): Neue und alte Banken-APIs – eine Übersicht. Online verfügbar unter
https://www.heise.de/hintergrund/Neue-und-alte-Banken-APIs-eine-Uebersicht-4907369.html,
letzter Zugriff am 04.06.2021.

Schriftenreihe des LfULG, Heft 4/2022 | 36
2.2.1.8 Herdenmanagement
In Anbetracht des ausgewählten Beispielprozesses „Milchproduktion“ wird in die Katalogisierung der Soft-
waresysteme ergänzend auch der Funktionsbereich Herdenmanagement für die Milchviehhaltung auf-
genommen. Als Verwaltungs- und Steuerungssystem für den Tierbestand umfasst es die Dokumentation
und Meldung von Bestandsveränderungen, Gruppenwechseln und Statusbuchungen. Das Herdenmanage-
ment dient zudem der Überwachung der Tiergesundheit sowie Planungs- und Steuerungsaufgaben in der
Tierhaltung.
Der Katalog der Softwaresysteme umfasst exemplarisch fünf Herdenmanagement-Programme, davon drei
cloudbasiert und eine native Desktoplösung. Ein System ist sowohl als Desktopversion als auch als mobile
Version und als Webversion verfügbar. Ähnlich wie bei Ackerschlagkarteien verfügen Anwendungen von
Komplettanbietern für die Innenwirtschaft über nur wenige Schnittstellen, bspw. zu HI-Tier (alle) und zu
den Landeskontrollverbänden (LKV). Reine Softwareanbieter wiederum stellen wiederum ein breites
Spektrum an Schnittstellen zu diversen Stakeholdern, anderen Softwaresystemen und Technik für die
Innenwirtschaft bereit.
2.2.2 Ansätze aus Industrie und Forschung
In diesem Abschnitt werden Ansätze aus der Industrie und Forschung betrachtet und beschrieben, die im
Rahmen des betrieblichen Datenmanagements Anwendung finden können. Die überwiegende Mehrzahl
der Anwendungen bietet allerdings keine direkt einsetzbaren Lösungen, sondern vielmehr Bausteine oder
grundlegende Konzepte zum Aufbau konkreter Datenmanagementsysteme. Folglich richten sich die Be-
schreibungen vorwiegend an Anbieter von Softwaresystemen sowie beratende Stellen und weniger an
Landwirtinnen und Landwirte direkt.
2.2.2.1 AgGateway ADAPT
AgGateway ist eine internationale Non-Profit-Organisation, die mit dem ADAPT (Ag Data Application Pro-
gramming Toolkit) Object Model ein Datenmodell für agronomische Daten entwickelt. Der Schwerpunkt liegt
im Bereich der Außenwirtschaft und insbesondere auf den Funktionsbereichen Ackerschlagkartei und Preci-
sion Farming. Das Datenmodell soll als Standard dienen, um im Rahmen des ADAPT-Frameworks die In-
teroperabilität zwischen Systemen herzustellen. ADAPT-Komponenten müssen in betriebliche Software-
systeme integriert werden und ermöglichen dann durch einheitliche Repräsentationen von Daten den Daten-
austausch über Systemgrenzen hinweg. ADAPT ist Open Source. In Abbildung 7 ist ein schematischer
Überblick über ADAPT gezeigt. ADAPT bietet damit eine Möglichkeit, standardisierte, bilaterale Schnitt-
stellen zwischen einzelnen Softwarelösungen umzusetzen (s. Abschnitt 3.3.1), fokussiert aktuell aber stark
auf den US-amerikanischen Markt. Der Einsatz von ADAPT ist eine Entscheidung, die Softwareanbieter
treffen müssen, ADAPT kann nicht als eigenständige Komponente eingesetzt werden.

image
Schriftenreihe des LfULG, Heft 4/2022 | 37
Abbildung 7: Überblick ADAPT (rote Pfeile Datenimport von einer Maschine, blaue Pfeile Datentransfer von FMIS A zu FMIS B)
48
48
Craker et al. (2018): ADAPT: A Rosetta Stone for Agricultural Data. In Proceedings of the 14th International Conference on Precision Agriculture June 24 – June 27, Montreal,
Quebec, Canada

image
Schriftenreihe des LfULG, Heft 4/2022 | 38
2.2.2.2 Agri-Gaia
Agri-Gaia ist ein Forschungsprojekt unter Leitung des DFKI zur Schaffung eines offenen KI-Ökosystems für
die Agrar- und Ernährungsindustrie auf Basis von GAIA-X. Die Laufzeit ist von Januar 2021 bis Dezember
2023. Im Rahmen des Projekts sollen Schnittstellen und Standards zur Schaffung einer herstellerübergrei-
fenden, dezentralen Infrastruktur für Daten und Algorithmen entwickelt werden
49
. Abbildung 8 zeigt den
schematischen Aufbau der Agri-Gaia-Plattform. Zum aktuellen Zeitpunkt sind Entwicklungen und Ergebnisse
von Agri-Gaia noch nicht absehbar.
Abbildung 8: Überblick Agri-Gaia
50
2.2.2.3 Agricultural Interoperability and Analysis System (ATLAS)
ATLAS wird von dem europäischen Programm Horizon 2020 gefördert. Die Projektkoordination obliegt dem
Fraunhofer IAIS unter Beteiligung relevanter Marktakteure in der Landwirtschaft. Das Ziel ist die Entwicklung
eines offenen, dezentralen und erweiterbaren Dateninteroperabilitätsnetzwerks auf Basis einer serviceorien-
tierten Architektur. Dieses soll ermöglichen, den Mangel an Interoperabilität zwischen Maschinen, Sensor-
systemen und Datenanalysewerkzeugen zu überwinden. Das Projekt ist im Oktober 2019 gestartet und läuft
bis September 2022.
49
s.
https://www.dfki.de/web/forschung/projekte-publikationen/projekte-uebersicht/projekt/agri-gaia/
50
s.
https://www.agri-gaia.de/agrigaia/die-plattform/

image
Schriftenreihe des LfULG, Heft 4/2022 | 39
Schnittstellen werden von Teilnehmern des Netzwerks standardisiert angeboten, damit verfolgt ATLAS den
Ansatz offener Schnittstellen und Datenstandards. Das ATLAS-Netzwerks ist schematisch in Abbildung 9
dargestellt. ATLAS hat nicht zum Ziel, dediziert den Datenaustausch zwischen Softwaresystemen herzu-
stellen – diese Funktionalität müsste von den Softwareanbietern im Rahmen eines ATLAS-Dienstes ange-
boten werden. Das heißt, ein Softwaresystem müsste eine Schnittstelle schaffen, die ein weiteres Soft-
waresystem nutzen kann. ATLAS bietet keine Lösung, die im Rahmen dieser Studie direkt eingesetzt wer-
den kann, es müsste dazu zunächst das gesamte ATLAS-Netzwerk etabliert werden.
Abbildung 9: Überblick ATLAS-Netzwerk
51
2.2.2.4 DataConnect
DataConnect ist eine Lösung zur Herstellung einer Cloud-zu-Cloud-Verbindung zwischen den Anbietern
365FarmNet, Case IH, Claas, John Deere, New Holland und Steyr. Weitere Anbieter können aufgenommen
werden. Im Fokus steht die herstellerübergreifende Nutzung von Maschinendaten, die sich aktuell auf wenige
Telemetriedaten beschränken. Eine Erweiterung um agronomische Daten ist geplant, aktuell aber noch nicht
absehbar. Landwirtschaftliche Betriebe können DataConnect im Rahmen ihrer eingesetzten Herstelleran-
gebote nutzen und Verbindungen konfigurieren, sodass die Daten automatisch zwischen den unterschied-
lichen Cloudsystemen ausgetauscht werden. Die Nutzung durch Landwirtinnen und Landwirte hängt davon
ab, ob die eigenen betrieblichen Softwarelösungen an DataConnect angebunden sind.
51
ATLAS-D3.2-Service-Architecture-Specification. Online verfügbar unter:
https://www.atlas-h2020.eu/wp-
content/uploads/2020/06/ATLAS-D3.2-Service-Architecture-Specification.pdf, letzter Zugriff am 20.08.2021

image
Schriftenreihe des LfULG, Heft 4/2022 | 40
2.2.2.5 DEMETER
DEMETER ist ein Horizon-2020-Projekt unter der Koordination des Waterford Institute of Technology, das
sich mit der Entwicklung eines „Agricultural Interoperability Space“ (AIS) auseinandersetzt. Dabei soll ein
besonderer Fokus auf Datenqualität und IoT-basierter Datenanalyse liegen. Zur Schaffung von Interopera-
bilität wird ein einheitliches Informationsmodell, das sog. „Agriculture Information Model“ (AIM) geformt.
Ein Gesamtüberblick über die DEMETER-Referenzarchitektur befindet sich in Abbildung 10. Die Laufzeit des
Projekts ist von September 2019 bis Februar 2023. DEMETER verfolgt somit einen ähnlichen Ansatz wie
AgGateway mit ADAPT. Zum aktuellen Zeitpunkt ist für DEMETER nicht absehbar, welche konkreten Ergeb-
nisse oder Lösungen aus dem Projekt hervorgehen werden.
Abbildung 10: Überblick der DEMETER-Referenzarchitektur
52
52
D3.1 DEMETER Reference Architecture (Release 1). Online verfügbar unter: https://h2020-demeter.eu/wp-
content/uploads/2020/10/D3.1-DEMETER-reference-architecture_v1.0.pdf, letzter Zugriff am 20.08.2021

Schriftenreihe des LfULG, Heft 4/2022 | 41
2.2.2.6 Offene Software-Plattform für Dienstleistungsinnovationen in einem Wertschöpfungs-
netz in der Landwirtschaft (ODiL)
ODiL war ein Forschungsprojekt unter Leitung des DFKI und wurde im Jahr 2019 abgeschlossen. In dem
Projekt wurden Konzepte für eine dezentrale Dienstleistungsplattform entwickelt, um Daten und Dienste
vereinfacht auszutauschen. Zum aktuellen Zeitpunkt sind keine Folgeaktivitäten bekannt.
2.2.2.7 agrirouter
Der agrirouter ist ein Angebot der DKE-Data GmbH & Co. KG. Es handelt sich dabei um eine Datendreh-
scheibe, die den Nachrichtenaustausch zwischen angebundenen landwirtschaftlichen Softwaresystemen
ermöglicht. Kompatible Systeme werden mit dem Nutzerkonto der Landwirtin oder des Landwirts verbunden
und erscheinen dort als Endpunkte, die Daten miteinander austauschen können. Die unterstützten Daten-
formate umfassen derzeit TaskData, Telemetrie, Bilder, Shapefile, PDF und Video. Die Landwirtinnen und
Landwirte können gemäß ihren Bedürfnissen individuelle Datenflüsse konfigurieren. Betriebliche Software-
systeme können über den agrirouter verbunden werden und Daten miteinander austauschen. Landwirte
können bei der Softwarebeschaffung darauf achten, ob die jeweilige betrieblich genutzte Software an den
agrirouter angebunden werden kann und somit Funktionen zum Datenaustausch bereitstehen.
2.2.2.8 Enterprise Service Bus (ESB)
Der ESB ist ein Ansatz zur Integration verteilter Dienste, bei dem die Systeme über einen gemeinsamen
Kommunikationsbus verbunden werden und so interagieren können. Dieser Kommunikationsbus stellt eine
IT-Infrastruktur bereit, durch die Softwaresysteme miteinander kommunizieren. Prinzipiell realisiert ein ESB
damit einen Datenrouter. Softwareanbieter müssen Schnittstellen hin zum ESB in ihre Lösungen integrieren,
um über den ESB als Infrastruktur mit weiteren Softwarelösungen kommunizieren zu können. Im Kontext des
betrieblichen Datenmanagements kann ein ESB als lokale Komponente eingesetzt werden, um lokal betrie-
bene Softwarelösungen miteinander zu verbinden. Im Rahmen dieser Studie werden lokale Betriebsumge-
bungen eher als kritisch eingeschätzt, da sie zu aufwändig zu betreiben sind und landwirtschaftliche Soft-
warelösungen zunehmend in Cloudsystemen betrieben werden. Damit kann die zum Datenaustausch not-
wendige Verbindung zwischen Systemen über internetbasierte Schnittstellen realisiert werden, was den
Betrieb eines lokalen ESB obsolet macht.
2.2.2.9 Safe FME
FME (Feature Manipulation Engine) ist ein Angebot der Safe Software Inc. und hat im Kern die Funktiona-
lität, Workflows für Daten frei zu gestalten und von der Software durchführen zu lassen. Dazu gehören auch
umfassende Manipulationen der Daten, wie beispielsweise Konvertierungen. Daten-Workflows im Kontext
von FME umfassen den Datenabruf aus einer Quelle, anschließende Transformationen, Konvertierungen
und/oder Validierungen und letztendlich die Datenabgabe bei einer Senke. Über eine Benutzeroberfläche
können die Workflows fast beliebig konfiguriert werden. Mittels Plugins können Transformationen standar-
disiert werden. Betriebliche Softwaresysteme können – entsprechende Schnittstellen vorausgesetzt – von
FME als Datenquelle und Datensenke angesteuert werden. Basierend auf Safe FME könnte ein Datenrouter
(vgl. Abschnitt 3.3.1) realisiert werden, indem einzubindende betriebliche Softwarelösungen über Schnitt-
stellen zu Safe FME miteinander verbunden werden. Allerdings ist Safe FME eine Lösung mit anderer Ziel-
setzung und umfangreichen Funktionen zur Datenvorverarbeitung, die im Kontext eines landwirtschaftlichen
Datenrouters nicht benötigt werden. Als Fazit kann gesagt werden, dass Safe FME zwar grundsätzlich nutz-
bar ist, die Kosten für die Nutzung aber nicht durch die benötigten Funktionen gerechtfertigt sind.

Schriftenreihe des LfULG, Heft 4/2022 | 42
2.2.2.10 Tableau
Tableau ist ein Angebot der Tableau Software LLC. Das Produkt, welches vom Anbieter als „Visual-
Analytics-Plattform“ beschrieben wird, hilft Nutzern, ihre Daten sichtbar und verständlich zu machen. Tab-
leau kann hierzu Daten aus diversen Datenquellen beziehen und erlaubt sodann die grafische Darstellung
sowie Analyse ebenjener Daten. Die grundlegende Technologie, auf der Tableau aufbaut, heißt VizQL und
wurde vom Anbieter patentiert. „VizQL drückt Daten visuell aus, indem Drag-&-Drop-Aktionen über eine
intuitive Benutzeroberfläche in Datenabfragen übersetzt werden.“
53
Im betrieblichen Kontext kann Tableau
beispielsweise bei der Geschäftsanalyse unterstützen. Im Rahmen der Studie wird Tableau als Alternative
zur Pilotierung eines FMIS vorgeschlagen (s. Abschnitt 3.4.9).
2.2.2.11 Microsoft Power BI
Power BI ist ein Angebot der Microsoft Corporation zur Geschäftsanalyse. Selbsterklärtes Ziel ist, interaktive
Visualisierungen und Geschäftsanalysefunktionen mit einer Oberfläche bereitzustellen, die so einfach ist,
dass Endbenutzer ihre eigenen Berichte und Dashboards erstellen können. Die Daten können hierzu aus
einer Vielzahl an Systemen bezogen und anschließend vom Kunden analysiert sowie visualisiert werden.
Darüber hinaus wird mit Power BI Embedded auch eine Möglichkeit für Softwareanbieter bereitgestellt, die
die Funktionen von Power BI in ihre eigenen Anwendungen integrieren möchten und so ihren Endkunden
vorbereitete Analysen und Darstellungen ihrer Daten als Produkt anbieten können
54
. Im Rahmen der Studie
wird Microsoft Power BI als Alternative zur Pilotierung eines FMIS vorgeschlagen (s. Abschnitt 3.4.9).
2.2.2.12 GeoBox HofBox
GEOBOX ist ein von der Landwirtschaftlichen Rentenbank und vom BMEL gefördertes Forschungsprojekt
(Phase I 10/2018 – 12/2020, Phase II ab 1/2021). Dabei wird ein Prototyp für eine standardisierte und resili-
ente Infrastruktur zur dezentralen Datenhaltung und regionalen Vernetzung entwickelt. Inhaltliche Schwer-
punkte konzentrieren sich auf den Pflanzenbau, z. B. die Vorgabe von Datenstrukturen und Vokabularien für
austauschrelevante Informationen, und die Realisierung von Kommunikationsprotokollen und Formularassis-
tenten für den standardisierten Datenaustausch mit Dritten. Abbildung 11 zeigt die GeoBox-Infrastruktur.
Der Betrieb einer „HofBox“ im landwirtschaftlichen Betrieb dient als Datendrehscheibe mit Zwischenspeicher-
funktion. Die Datenbefüllung der HofBox erfolgt manuell über einen Formularassistenten. Der HofBox-
Datenspeicher synchronisiert sich automatisch mit Mobilgeräten und öffentlichen Datenquellen. Interaktion
mit externen Systemen erfolgt dadurch, dass Dritte ihren Datenbedarf als Abfrage an das System stellen.
Dabei können dynamisch nahezu beliebige Datenstrukturen/-formate erzeugt werden, sodass grundsätzlich
eine Vielzahl von Schnittstellenformaten bedienbar ist. Über den GeoBox-Viewer können öffentliche Geo-
basis- und Fachdaten eingesehen werden. Ein weiteres Angebot ist der GeoBox-Messenger zur Nachrich-
tenübermittlung. Da die GeoBox HofBox aktuell noch nicht als Produkt zur Verfügung steht oder final konzi-
piert wurde, kann aktuell noch keine Aussage zur Einsetzbarkeit im betrieblichen Datenmanagement getrof-
fen werden. Es muss auch abgewartet werden, wie privatwirtschaftliche Anbieter auf die konkrete Realisie-
rung reagieren und ob diese bereit sind, notwendige Schnittstellen zur HofBox zu schaffen.
53
s.
https://www.tableau.com/de-de/why-tableau/what-is-tableau
54
Vgl. https://customers.microsoft.com/en-us/story/852447-seges-professional-services-power-bi

image
Schriftenreihe des LfULG, Heft 4/2022 | 43
Abbildung 11: GeoBox-Infrastruktur
55
2.2.2.13 Proagrica agX
agX® ist ein Produkt der LexisNexis Risk Solutions Group, welches unter der Marke Proagrica angeboten
wird. Es handelt sich dabei um eine zentrale Plattform, die die sichere Datenhaltung und Synchronisation
übernimmt. agX setzt im Wesentlichen auf Inhaltsstandardisierung, sieht also gemeinsame, einheitliche
Datenmodelle und -formate vor. Darüber hinaus wird ein Berechtigungsmanagement für das Teilen betriebli-
cher Daten geboten. Über einen Marktplatz für Dienste können zusätzliche Angebote in Anspruch genom-
men werden. Mit Farmplan, Gatekeeper und FarmRite werden im britischen Markt Lösungen im Kontext von
FMIS für Landwirtinnen und Landwirte angeboten, die sich in das Produktportfolio von Proagrica einglie-
dern
56
. Im deutschen Markt sind aktuell keine direkten Angebote von Proagrica verfügbar, die Markteinfüh-
rung ist derzeit nicht absehbar. Die Nutzung von Proagrica-Produkten durch Landwirtinnen und Landwirte
hängt im Wesentlichen davon ab, wie diese im deutschen Markt eingeführt werden und ob weitere Software-
anbieter bereit sind, Schnittstellen zu schaffen. Auch wenn die Nutzung von Proagrica-Produkten als Daten-
hub für weitere Softwaresysteme denkbar ist (vgl. Abschnitt 3.3.4), schätzen wir eine solche Realisierung
aktuell als nicht absehbar ein. Hier kann vermutet werden, dass Softwareanbieter nicht bereit sind, ihre
Systeme an konkurrierende Anbieter anzubinden.
2.2.2.14 SDSD – Smarte Daten, Smarte Dienste
SDSD war ein Forschungsprojekt mit Konsortialführung durch die Maschinenfabrik Bernard Krone GmbH &
Co. KG. Die Projektlaufzeit war von Juni 2017 bis Oktober 2020. „Smarte Daten“ werden durch semantische
Interpretation und Annotation von Rohdaten generiert. Diese wiederum ermöglichen „Smarte Dienste“, die
Landwirtinnen und Landwirten zusätzliche Erkenntnisse und Zusammenhänge aus den Daten zugänglich
machen können. Die Kernkonzepte umfassen beispielsweise Speicherfristen, Zugriffskontrolle, Vokabulare,
55
s.
https://www.dap.rlp.de/Digitales-AgrarPortal/GeoBox-/Infrastruktur
56
s.
https://proagrica.com/products/agx/
und https://proagrica.com/solutions/farm-and-agronomy-solutions/

image
Schriftenreihe des LfULG, Heft 4/2022 | 44
Datenqualität und Datenbereinigung. Die Datenbereitstellung aus den betrieblichen Systemen heraus ist
etwa über den agrirouter möglich. Den Aufbau der SDSD-Architektur zeigt Abbildung 12. Fokus des Projekts
waren landwirtschaftliche Prozesse der Außenwirtschaft, doch die Infrastruktur lässt auch eine Einbindung
weiterer Datenbestände zu
57
. Aktuell sind von SDSD abgeleitete Angebote nicht am Markt präsent, die Etab-
lierung eines auf SDSD aufbauenden Datenhubs wird in der Domäne allerdings diskutiert. Ein solches An-
gebot kann eine Komponente im hybriden Ansatz zum Datenmanagement sein (vgl. Abschnitt 3.3.4), die
Realisierung ist aber mit erheblichen Aufwänden verbunden und aktuell ist noch nicht absehbar, wann sie
erfolgen könnte. Für Landwirte würde sich die Nutzung ähnlich zu DataConnect oder agrirouter ergeben, in-
dem sie Softwarelösungen danach auswählen, ob diese an einen solchen Datenhub angebunden sind.
Abbildung 12: Überblick Architektur in SDSD
58
2.2.2.15 Data Intelligence Hub (DIH)
Der DIH ist ein Angebot der Telekom und richtet sich vorwiegend an Großunternehmen. Im Kontext eines
betrieblichen Datenmanagements könnte es eine Option sein, für Softwaresystemanbieter die Speicherung
von Daten auf dem DIH umzusetzen. Die Telekom evaluiert aktuell die Schaffung von Angeboten im land-
wirtschaftlichen Bereich. Unternehmen können sich zum Datenaustausch über spezielle Konnektoren ver-
binden, die z. B. Aspekte der Datennutzungskontrolle umsetzen. Der DIH basiert auf Konzepten der Inter-
national Data Spaces (IDS)
59
. Für das Datenmanagement direkt im betrieblichen Kontext wird der DIH nicht
als Lösungsvariante eingeschätzt, weshalb im Projekt keine detaillierte Betrachtung vorgenommen wurde.
57
s.
http://sdsd-projekt.de/
und
http://sdsd-projekt.de/download-dir/SDSD_Abschlusspraesentation_200910.pdf
58
SDSD Abschlusspräsentation 03.09.2020, online verfügbar unter
http://sdsd-projekt.de/download-
dir/SDSD_Abschlusspraesentation_200910.pdf, letzter Zugriff am 18.08.2021
59
s. https://dih.telekom.net

image
Schriftenreihe des LfULG, Heft 4/2022 | 45
2.2.2.16 FIWARE
FIWARE ist eine Open-Source-Initiative der FIWARE Foundation und definiert eine universelle Sammlung
von Standards und technologischen Bausteinen für den Aufbau eines „Kontextdatenmanagements“ (bspw.
agronomische, betriebliche Daten). Im Kern der Technologien steht ein Kontextbroker, der Daten über
Schnittstellen entgegennimmt und bereitstellt. Ergänzt durch harmonisierte Datenmodelle wird Interopera-
bilität zwischen angebundenen Systemen erreicht. FIWARE-Technologien können als Open- Source-
Angebote prinzipiell zum Aufbau von Lösungen in Eigenregie genutzt werden, um im betrieblichen Kontext
eine eigene Datenhaltung zu realisieren
60
. Die Referenz-Architektur von FIWARE zeigt Abbildung 13.
FIWARE-Technologie kann grundsätzlich zur Schaffung verschiedener Lösungen im Kontext dieser Studie
eingesetzt werden (bspw. Datenhub oder Datenrouter), hat auf die Lösungskonzeption im Rahmen dieser
Studie aber keinen direkten Einfluss.
Abbildung 13: Referenz Architektur FIWARE
61
2.2.2.17 COGNAC ADS / IDS
Das Forschungsprojekt Cognitive Agriculture (COGNAC, Laufzeit bis 09/2022) untersucht die Möglichkeiten
zur Schaffung eines Datenraums für die Digitalisierung in der Landwirtschaft (Agricultural Data Space, ADS)
und nutzt dabei Konzepte des International Data Space (IDS). Der ADS hat das Ziel, einen interoperablen
übergreifenden Datenraum zu schaffen, in dem beliebige Komponenten des Digitalen Ökosystems Landwirt-
schaft sicher miteinander kommunizieren können. Im Rahmen des Projekts werden digitale Zwillinge für
Ackerschläge erforscht, die eine wesentliche Rolle im betrieblichen Datenmanagement spielen können, indem
sie Datenbestände konsolidieren und diskriminierungsfrei der gesamten Domäne zur Verfügung stellen.
60
s.
https://www.fiware.org
61
s.
https://www.fiware.org/community/smart-agrifood/

image
Schriftenreihe des LfULG, Heft 4/2022 | 46
Dabei ist die Wahrung der Datensouveränität für Landwirtinnen und Landwirte ein Schwerpunkt. Zur Realisie-
rung einer Infrastruktur für digitale Zwillinge werden eigenständige Datenhubs erforscht und vorentwickelt.
Grundsätzlich sind digitale Zwillinge auch für Tiere, Maschinen, Anlagen bis hin zu Betrieben denkbar, wer-
den in COGNAC aber nicht tiefer untersucht. Abbildung 14 zeigt einen exemplarischen Aufbau des ADS, in
dem Datenhubs betriebliche Daten verwalten und nach Wunsch von Landwirtinnen und Landwirten weiteren
Softwaresystemen und Datenplattformen bereitstellen. COGNAC ist ein von der Fraunhofer-Gesellschaft
finanziertes Forschungsprojekt ohne Industriepartner, für potenzielle Projektergebnisse ist derzeit noch kein
Transfer in die Landwirtschaft absehbar.
Abbildung 14: Beispielhafte Darstellung des ADS mit verschiedenen digitalen Plattformen und
Datenhubs für digitale Zwillinge
62
2.2.2.18 SAP Vistex
Vistex bietet als Erweiterungslösung für SAP zwei Funktionskomplexe, SAP Grower Management for Peris-
hables und SAP Farm Management. Das Funktionsangebot ist eng an SAP-Kernfunktionen angelehnt, mit
starkem Fokus auf geschäftliche Prozesse im Bereich Buchhaltung, Warenmanagement und Betriebsma-
nagement. Dieses Angebot wird als Vollangebot gemacht, d. h. das Ziel ist der volle Funktionsumfang inner-
halb von SAP. Es gibt keine Einbindung weiterer Systeme. Agronomische Funktionalitäten sind nicht als
Angebot erkennbar (insbesondere kein Precision Farming). Die Umsetzung erfolgt im Rahmen einer SAP-
Installation, wofür verschiedene Optionen angeboten werden (auf eigener IT, in der Cloud oder hybrid)
63
.
Aktuell ist SAP Vistex nicht auf dem deutschen Markt präsent und eine Eingliederung in die gegebene
Marktsituation ist nicht absehbar.
62
https://www.cognitive-agriculture.de/
63
s.
https://www.vistex.com/de/industries/agriculture/

image
Schriftenreihe des LfULG, Heft 4/2022 | 47
2.2.2.19 Nevonex
Nevonex ist ein Angebot von Bosch und bietet die Möglichkeit, Maschinen und Arbeitsabläufe zu vernetzen
und zu automatisieren. Nevonex ist ein offenes und neutrales IoT-Framework mit dem Ziel, herstellerüber-
greifend Kompatibilität, Interoperabilität und Konnektivität zu verbessern. In der Nevonex-Umgebung wer-
den digitale Dienste zur Verfügung gestellt, die herstellerübergreifend auf den Maschinen installiert werden
können (ähnlich einem Appstore für Smartphones). In der Nevonex-Entwicklungsumgebung werden die
Schnittstellen der angebundenen Partner gesammelt. Somit ist der Entwicklungsaufwand für Hersteller
geringer, da diese nur noch gegen die abstrahierten Nevonex-Schnittstellen programmieren müssen
64
.
Abbildung 15 zeigt Nevonex im Zusammenspiel mit verschiedenen Partnern. Nevonex kann im gesamt-
betrieblichen Datenmanagement eine wesentliche Rolle bei der Maschinenkommunikation übernehmen,
Lücken im Datenmanagement darüber hinaus aber eher nicht adressieren (bspw. bei der Kommunikation
zwischen Ackerschlagkartei und Buchhaltung, vgl. Abschnitt 3.3.1.2).
Abbildung 15: Zusammenspiel der Nevonex-Partner
64
s.
https://www.nevonex.com/de/
und
https://www.youtube.com/watch?v=YQdDG1OJt98

Schriftenreihe des LfULG, Heft 4/2022 | 48
2.2.2.20 SEGES (Dänemark)
SEGES ist das führende landwirtschaftliche Wissens- und Innovationszentrum in Dänemark. SEGES bie-
tet digitale Lösungen, Schulungen, Beratung und Wissensaustausch für den Agrar- und Ernährungssektor
an und stellt die Verbindung zwischen Forschung und Praxis her. SEGES Digital entwickelt Software-
lösungen, um landwirtschaftliche Arbeitsschritte zu optimieren
65
. Ein Beispiel ist das Feldverwaltungs-
programm Mark Online. Es repräsentiert mehr als 80 % der landwirtschaftlichen Nutzfläche Dänemarks
66
.
Neben den üblichen Funktionen einer Ackerschlagkartei können auch ausgewählte Finanzen im Pflanzen-
bau ausgegeben werden
67
.
In Dänemark ist es ebenso wie in Deutschland für landwirtschaftliche Betriebsleitende schwer, einen Über-
blick über die finanzielle Situation des Betriebs zu bekommen. Landwirtinnen und Landwirte verwalten ihre
Daten selbst auf zentralisierten IT-Systemen und müssen die relevanten Daten und Informationen aus ver-
schiedenen Quellen (inkl. der Papierform) zusammenstellen und auswerten. Aus diesem Grund wurde
SEGES beauftragt, ein landwirtschaftliches Buchhaltungssystem zu entwickeln und zu betreiben. Ziel ist es,
die relevanten Daten und Informationen an einem einzigen digitalen Ort zusammenzuführen und zu visuali-
sieren, sodass die Landwirtinnen und Landwirte schnell einen Überblick über die finanzielle Situation des
Betriebs bekommen. Azure wurde für die Backend-Datenverarbeitung und Power BI für die Implementierung
und das Anwendungsportal (Visualisierung) gewählt. Die Wahl fiel auf diese Systeme, da SEGES schon in
vielen Geschäftsbereichen Produkte von Microsoft verwendet. Landwirtinnen und Landwirte können sich
über das Webportal von SEGES einloggen und die gewünschten Informationen aufrufen. Auf mehreren
grafischen Kacheln werden Informationen zu verschiedenen Aspekten der betrieblichen Finanzen dargestellt
und so ein schneller Überblick ermöglicht. Außerdem können weitere Informationen aufgerufen werden, die
zu einem Power BI Embedded Bericht führen. Somit können Landwirtinnen und Landwirte einfach relevante
Kennzahlen überprüfen und den Betrieb entsprechend optimieren
68
. Abbildung 16 zeigt einen beispielhaften
Auszug aus dem SEGES Dashboard für einen Beispielbetrieb.
Die Aktivitäten von SEGES dienen als kontrastierendes Beispiel zum deutschen Markt, da im dänischen
Markt wesentliche Anteile von Betrieben und Ackerflächen in wenigen Systemen verwaltet werden. Das
vereinfacht das Datenmanagement und auch die Entwicklung eines FMIS. Aufgrund der Verschiedenartig-
keit zum deutschen Markt sind Konzepte nur bedingt übertragbar, trotzdem sollten insb. Entwicklungen zu
dem beschriebenen Dashboard bei der Konzeption eines FMIS berücksichtigt werden, um von den Erfah-
rungen von SEGES zu profitieren.
65
s.
https://en.seges.dk/Our-Competencies/Data-driven-management-and-software
66
Bligaard, Jens (2014): Mark Online, a Full Scale GIS-based Danish Farm Management Information System. Special Issue:
Challenge of IT, Innovation and Knowledge. In: International Journal on Food System Dynamics 5(4), S. 190-195.
67
s.
https://www.seges.dk/software/plante/mark-online
68
https://customers.microsoft.com/en-us/story/852447-seges-professional-services-power-bi

image
Schriftenreihe des LfULG, Heft 4/2022 | 49
Abbildung 16: Auszug SEGES Dashboard
68
2.2.3 IT-Infrastruktur
2.2.3.1 Cloud Computing und cloudbasierte Anwendungen im Allgemeinen
Cloud Computing bezeichnet die Bereitstellung und Nutzung von IT-Ressourcen als Dienste über das Inter-
net.
69
Hierbei können im Wesentlichen drei Servicemodelle unterschieden werden: Infrastructure as a Ser-
vice (IaaS), Platform as a Service (PaaS) und Software as a Service (SaaS).
Infrastructure as a Service
ist die niedrigste Abstraktionsstufe des Cloud Computings. Bereitgestellt wer-
den einfache Ressourcen wie Speicher, virtuelle Server und Netzwerkdienste. Für die Installation und den
Betrieb der Systeme ist der Kunde selbst verantwortlich; er bedient sich lediglich der angebotenen Infra-
struktur. Beispiele für solche Angebote sind Amazons Simple Storage Service (S3) und Elastic Compute
Cloud (EC2). Die Zielgruppe des Angebots ist üblicherweise die IT-Betriebsabteilung. Ein Slogan eines
solchen Angebots könnte lauten: „Wir bieten Ihnen Festplatten und Server in der Cloud an, die Sie nach
Belieben nutzen können.“
Hingegen wird im
Rahmen von Platform as a Service
durch den Serviceanbieter eine Umgebung (tech-
nische Plattform) bereitgestellt. Üblicherweise umfasst sie fertige Laufzeitumgebungen und Dienste wie
Datenbanken und Nachrichtensysteme. Der Kunde realisiert und betreibt seine eigenen Anwendungen
unter Zuhilfenahme der bereitgestellten Plattform und muss sich um die Verwaltung der zugrundeliegen-
den Infrastruktur nicht kümmern. Beispiele für solche Angebote sind Pivotal Cloud Foundry und AWS Elas-
tic Beanstalk. Die Zielgruppe des Angebots ist üblicherweise die IT-Betriebsabteilung und ggf. auch Ent-
wickler. Ein Slogan eines solchen Angebots könnte lauten: „Mit unserer technischen Plattform können Sie
Ihre Anwendungen kinderleicht betreiben.“
69
Mell, Peter Mell; Grance, Tim (2011): The NIST definition of cloud computing. National Institute of Standards and
Technology.

Schriftenreihe des LfULG, Heft 4/2022 | 50
Software as a Service
stellt die höchste Abstraktionsstufe des Cloud Computings dar. Hierbei werden
einem Kunden fertige Anwendungen zur direkten Nutzung bereitgestellt. Ein klassisches Beispiel ist die
G Suite von Google, in deren Rahmen u. a. E-Mail-Postfächer, Kalender, Datenspeicher, Office-Anwen-
dungen und eine Konferenzlösung zur direkten Nutzung angeboten werden. Kunden müssen sich weder
um die Entwicklung noch um den Betrieb kümmern. Die Zielgruppe des Angebots sind üblicherweise Un-
ternehmen, Mitarbeitende und Endkunden. Ein Slogan eines solchen Angebots könnte lauten: „Wir bieten
Ihnen fertige Lösungen zur Nutzung an, damit Sie sich auf Ihr Kerngeschäft konzentrieren können.“
On-Demand Self-Service: Die Bereitstellung der Ressourcen ist automatisiert und der Kunde kann
seinen Leistungsumfang „mit wenigen Klicks“ jederzeit selbstständig erweitern oder reduzieren.
Broad Network Access: Die Services sind mit Standardmechanismen über das Internet verfügbar und
an keinen bestimmten Client gebunden.
Resource Pooling: Die Ressourcen des Anbieters liegen in einem Pool vor, aus dem die Kunden durch
Ressourcenzuweisungen bedient werden. Mandantentrennung ist durch geeignete technische und
organisatorische Maßnahmen des Anbieters sicherzustellen.
Rapid Elasticity: Die Ressourcen können schnell und elastisch zur Verfügung gestellt werden, in
manchen Fällen sogar automatisch. Aus Kundensicht scheinen die Ressourcen daher unendlich zu sein.
Measured Services: Die Ressourcennutzung (z. B. Speicher, Rechenzeit, Bandbreite oder Anzahl
aktiver Nutzer) kann gemessen und überwacht werden, was Transparenz für Anbieter und Kunden
ermöglicht. Zudem wird ein Abrechnungsmodell ermöglicht, bei dem Kunden nur die Ressourcen in
Rechnung gestellt werden, die im betrachteten Zeitraum auch tatsächlich in Anspruch genommen
wurden (Pay-per-Use).
Weiterhin können im Allgemeinen vier Bereitstellungsmodelle für Cloud Computing unterschieden werden:
1. Private Cloud: Bei einer Bereitstellung als sog „Private Cloud“ werden die zugrundeliegenden Cloud-
Ressourcen zur exklusiven Nutzung durch eine Institution bereitgestellt. Die Ressourcen können
physisch „On-Premises“ (vor Ort) oder „Off-Premises“ (bei einem Dritten) verortet sein.
2. Community Cloud: Bei einer Bereitstellung als sog. „Community Cloud“ werden die zugrundeliegen-
den Cloud-Ressourcen zur exklusiven Nutzung durch eine Gemeinschaft von Institutionen mit ähn-
lichen Interessen bereitgestellt. Die Ressourcen können physisch „On-Premises“ oder „Off-Premi-
ses“ verortet sein.
3. Public Cloud: Bei einer Bereitstellung als sog. „Public Cloud“ stehen die zugrundeliegenden Cloud-
Ressourcen potenziell jedem zur Verfügung. Die Ressourcen sind physisch stets beim Servicean-
bieter verortet.
4. Hybrid Cloud: Zusammenschlüsse mehrerer Cloud-Infrastrukturen, die für sich selbst eigenständig sind,
werden als „Hybrid Cloud“ bezeichnet. Herausforderung ist die Abgrenzung der unterschiedlichen
Geschäftsbereiche und -prozesse und somit eine saubere Klassifizierung der anfallenden Daten.

Schriftenreihe des LfULG, Heft 4/2022 | 51
5. Nachfolgend werden Vor- und Nachteile des Cloud Computing beschrieben:
Vorteile:
Anschaffungs- und Unterhaltungskosten der genutzten Cloud-Ressourcen können auf eine Nutzerzahl
umgelegt werden, somit ist die Nutzung im Vergleich zum Betrieb eines eigenen Rechenzentrums sehr
günstig. Verschiedene Abrechnungsmodelle erlauben eine hohe Flexibilität, bspw. durch nutzungs-
basierte Abrechnung, es wird nur gezahlt, was tatsächlich beansprucht wurde.
Cloud-Infrastruktur bietet durch vielfältige Schutzmechanismen eine sehr hohe Verfügbarkeit, selbst bei
Ausfällen ganzer Rechenzentren kann schnell auf alternative Standorte ausgewichen werden. Generell
gilt, dass vergleichbare Leistungsfähigkeit und Niveau der Angebote durch einen Eigenbetrieb nicht zu
verhältnismäßigen Kosten realisierbar sind.
Durch ausreichende Kapazitäten und flexible Infrastruktur kann bedarfsgesteuert schnell und dynamisch
aufsteigende und wieder fallende Last reagiert werden (Skalierbarkeit), wodurch stets ausreichend
Rechnerkapazitäten zur Verfügung stehen.
Durch einen typischerweise professionellen Betrieb sind Hardware- und Softwarekomponenten jederzeit
auf neuestem Stand, was die Fehleranfälligkeit und Angreifbarkeit reduziert.
Kunden können sich auf das eigene Kerngeschäft konzentrieren und umfassende Leistungen im Bereich
der IT-Infrastruktur einkaufen.
Nachteile
Softwarelösungen müssen auf einen Cloudbetrieb angepasst sein, das gilt insbesondere für die Bereit-
stellung von Benutzeroberflächen.
Cloudsysteme sind grundsätzlich angreifbar, da sie über das Internet erreichbar sind. Die Sicherung
gegen Angriffe muss vom Cloudbetreiber aber auch von den jeweiligen Softwareanbietern umgesetzt
werden. Zur Minimierung der Angreifbarkeit gibt es Hilfen wie bspw. vom Bundesamt für Sicherheit in
der Informationstechnik (BSI). Der Kriterienkatalog C5 (Cloud Computing Compliance Criteria
Catalogue)
70
spezifiziert Mindestanforderungen an sicheres Cloud Computing, an denen sich
Cloudanbieter, deren Prüfer und Kunden orientieren können. Das Amazon Web Services (AWS)
Rechenzentrum in Frankfurt verfügt beispielsweise über ein entsprechendes Testat.
71
Für cloudbetriebene Dienste gilt grundsätzlich, dass eine funktionierende, stabile und ausreichend
dimensionierte Internetverbindung benötigt wird. Gerade in ländlichen Gebieten mit unzureichender oder
keiner Internetanbindung ist die Verwendbarkeit von Cloudlösungen damit eingeschränkt.
70
https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-
nach-Angriffszielen/Cloud-Computing/Kriterienkatalog-C5/kriterienkatalog-c5_node.html).
71
https://aws.amazon.com/de/compliance/bsi-c5

Schriftenreihe des LfULG, Heft 4/2022 | 52
2.2.3.2 Cloud Computing und cloudbasierte Anwendungen im landwirtschaftlichen Kontext
Nachdem das Thema Cloud Computing und cloudbasierte Anwendungen im vorstehenden Abschnitt allge-
mein betrachtet wurden, erfolgt nachstehend eine Detaillierung im Hinblick auf die Domäne Landwirtschaft
und landwirtschaftliche Betriebe. Üblicherweise kommen Landwirtinnen und Landwirte ausschließlich mit
Cloud-Angeboten des Servicemodells Software as a Service in Berührung, die sie im betrieblichen Kontext
einsetzen. Beispiele für cloudbasierte (SaaS) Anwendungen, die im landwirtschaftlichen Kontext angeboten
werden, sind:
365FarmNet
AgriCircle
agriPORT (Agricon)
DIANAweb
agrirouter (DKE-Data)
HI-Tier
InVeKoS Online GIS
NEXT Farming LIVE (FarmFacts)
Operations Center (John Deere)
Sirrus (Proagrica)
Zur Nutzung cloudbasierter Anwendungen wird im Allgemeinen eine Internetverbindung benötigt, die idealer-
weise stets verfügbar ist (always on). Anbieter können ihre Anwendungen teilweise jedoch auch so gestalten,
dass zumindest ein zeitweises Arbeiten ohne eine Verbindung möglich sein sollte (ggf. mit eingeschränktem
Funktionsumfang). In diesem Zusammenhang sollte genauer untersucht werden, welche konkreten Risiken
und Folgen mit einer gestörten Internetverbindung eines landwirtschaftlichen Betriebs verbunden wären,
wenn dieser cloudbasierte Anwendungen einsetzt.
Cloud Computing stellt aus unserer Sicht eine gute Option zum Betrieb und Angebot landwirtschaftlicher
Softwarelösungen dar. Viele Angebote werden bereits als cloudbetriebene Lösungen umgesetzt und der
Trend geht deutlich weiter in diese Richtung
72
. Vor diesem Hintergrund ist es wichtig, bestehende Schwä-
chen des Modells anzugehen und bspw. die Verfügbarkeit von Internetanbindungen flächendeckend aus-
zubauen. Moderne landwirtschaftliche Systeme werden immer stärker vernetzt sein, d. h. Schnittstellen zu
Softwaresystemen werden unabhängig von der Betriebsform benötigt. Folglich muss eine lokal betriebene
Softwarelösung ebenso mit dem Internet verbunden sein wie eine cloudbetriebene, wodurch auch die
lokale Installation aus dem Internet angreifbar wird. Cloudsysteme bieten zwar eine größere Angriffsfläche,
72
Diese Entwicklung zeigte sich durch vereinzelte Aussagen in den Fachgesprächen mit Softwareanbietern und wird
beispielsweise verdeutlicht durch das ab 2022 durch das LfULG geplante Angebot einer Online-Version seines
Bilanzierungs- und Empfehlungssystem Düngung als webBESyD oder durch Nutzung zusätzlicher Cloudfunktionen auch in
der Desktopsoftware von NEXT Farming
(https://www.nextfarming.de/landwirt/kontakt/support/faq/,
letzter Zugriff am
28.08.2021).

Schriftenreihe des LfULG, Heft 4/2022 | 53
sind in der Regel aber besser auf Angriffe vorbereitet und dagegen geschützt. Hinsichtlich der Leistungs-
fähigkeit und Skalierbarkeit können lokal betriebene IT-Infrastrukturen zu vergleichbaren Aufwänden nicht
mit cloudbetriebenen konkurrieren. Welche Aspekte bei der Entscheidung für cloudbetriebene Softwarelö-
sungen für Landwirtinnen und Landwirte relevant sind, wird im Rahmen der Datensouveränität beschrie-
ben (s. Abschnitt 2.3.3.2).
2.3 Definitionen und Kernkonzepte
Um den Umfang und die erforderlichen Funktionen eines informationstechnischen Systems im Allgemeinen
zu umreißen, ist es zunächst notwendig, sich einen Überblick über die Realweltprozesse zu verschaffen, die
abgebildet werden sollen. Wenn dabei auch gängige Begriffe zur Beschreibung von Systemen verwendet
werden, dann muss sichergestellt sein, dass ein gemeinsames Verständnis der Bedeutung vorliegt, also
Definitionen geschaffen werden.
2.3.1 FMIS
Für die Begriffe „Management-Informationssystem“ im Allgemeinen und „Farmmanagement-Informations-
system“ im Speziellen wurde im Kontext dieser Studie der Versuch einer Definition unternommen. Nach
Watson
73
et al. (1991) versteht man unter einem Management-Informationssystem „… eine organisatorische
Methode zur Bereitstellung von vergangenen, gegenwärtigen und projizierten Informationen auf Basis von
internen Abläufen sowie externen Hinweisen…“. Es soll Entscheidungsunterstützung innerhalb von Unter-
nehmen bieten, indem es kurzfristig wichtige Informationen für Planungs-, Steuerungs- und Unternehmens-
entscheidungen bereitstellt. Diese Funktionen spiegeln sich in den in der Ausschreibung vorgegebenen
Ziel- und Kenngrößen wider, die als ökonomische Kenngrößen in erster Linie auf Handlungen und Ent-
scheidungen im Rahmen der Unternehmensführung ausgerichtet sind. Gleichzeitig existieren spezifische,
teils auch weiter gefasste Definitionen für Farmmanagement-Informationssysteme in der Fachliteratur, z. B.:
FMIS haben sich von einfachen Aufzeichnungen zu hochentwickelten Lösungen entwickelt, die in der
Lage sind, neue Trends zu erfassen. Dazu gehören räumliches und zeitliches Management, verteilte
Sensoren mit Interoperabilität von Messgeräten, zukünftige Internetanwendungen und Webdienste.
74
„… ein umfassendes System zu m Sammeln, Verarbeiten, Speichern und Verbreiten von Daten bzw.
Informationen, die für eine optimale Betriebsführung erforderlich sind“.
75
FMIS = Zentrale für sämtliche digitale, betriebliche sowie agronomische Anwendungen bzw. Techno-
logien, Vernetzung der Teilkomponenten zu einem intelligenten Gesamtsystem.
76
73
Watson, H. J., Carroll, A. B., & Mann, R. I. (Hg.). (1991). Information Systems for Management: A Book of Readings.
Richard D Irwin.
74
Tsiropoulos, Z.; Carli, G.; Pignatti, E.; Fountas, S. (2017): Future Perspectives of Farm Management Information Systems:
Springer International Publishing (Progress in Precision Agriculture), S. 181-200.
75
Tsiropoulos, Z.; Carli, G.; Pignatti, E.; Fountas, S. (2017): Future Perspectives of Farm Management Information Systems:
Springer International Publishing (Progress in Precision Agriculture), S. 181-200.
76
Tsiropoulos, Z.; Carli, G.; Pignatti, E.; Fountas, S. (2017): Future Perspectives of Farm Management Information Systems:
Springer International Publishing (Progress in Precision Agriculture), S. 181-200.

Schriftenreihe des LfULG, Heft 4/2022 | 54
Diese Definitionen beinhalten die Definition eines Managementinformationssystems nach Watson (1991),
legen aber einen zusätzlichen Schwerpunkt auf die Vernetzung von einzelnen Komponenten, wie Sensoren
und Webdiensten, sowohl betriebsintern als auch von außerhalb und durch Dritte bereitgestellt. Für die Stu-
die leitet sich daraus ab, dass für ein vollumfängliches FMIS verschiedene Arten von Prozessen oder Pro-
zessebenen (s.a. Abschnitt 3.1) betrachtet werden müssen:
Produktionsprozesse
Management- und Entscheidungsprozesse
Betriebliches Datenmanagement
2.3.2 Interoperabilität & Medienbrüche
Dieser Abschnitt führt aus, wie die Begriffe Interoperabilität und Medienbrüche im Rahmen der Studie prinzi-
piell definiert werden, auf welchen Ebenen Medienbrüche auftreten können und wie sie sich im betrieblichen
Kontext auswirken können.
2.3.2.1 Definition Interoperabilität
Unter Interoperabilität verstehen wir im Kontext dieser Studie die Fähigkeit zweier Systeme oder Kompo-
nenten, Informationen auszutauschen und die ausgetauschte Information auch zu nutzen
77
. Unabhängige,
heterogene Systeme sollen so nahtlos zusammenzuwirken, um Daten auf effiziente und verwertbare Art
und Weise auszutauschen bzw. dem Benutzer zur Verfügung zu stellen, ohne dass dazu besondere Adap-
tierungen notwendig sind
78
. In der Regel werden bei der Betrachtung der Interoperabilität verschiedene
Stufen oder Ebenen unterschieden (s.
79,80,81
):
Strukturelle Interoperabilität oder Dateninteroperabilität (Konnektivität, Connected Interoperability): Es
besteht eine technische Verbindung (Protokollvereinbarung) zwischen den beteiligten Systemen, sodass
grundsätzlich Daten übertragen werden können. Allerdings sind weder Formate noch Inhalte festgelegt.
Syntaktische Interoperabilität (Functional Interoperability): Es existiert ein spezifiziertes Datenformat,
sodass ausgetauschte Daten von unabhängigen Systemen grundsätzlich eingelesen/geschrieben
werden können. Damit einher geht die Fähigkeit, einzelne Informationseinheiten und Datenstrukturen zu
identifizieren und zu extrahieren.
Semantische Interoperabilität (Domain Interoperability): Den beteiligten Systemen liegt ein gemeinsames
Informationsmodell zugrunde, welches erlaubt, die ausgetauschten Daten korrekt zu interpretieren.
Pragmatische oder organisatorische Interoperabilität (Enterprise Interoperability): Abstimmung von
Prozeduren, sodass die beteiligten Partner und ihre Systeme nahtlos zusammenarbeiten können. Dies
beinhaltet die effiziente Organisation interagierender Prozesse.
77
IEEE Standard Computer Dictionary – A Compilation of IEEE Standard Computer Glossaries, 1990.
78
https://de.wikipedia.org/wiki/Interoperabilit%C3%A4t
79
https://www.sifo.de/files/Poster-10_Interoperabilit%C3%A4t_Schmitz_IF18.pdf
80
https://de.wikipedia.org/wiki/Interoperabilit%C3%A4t
81
https://www.etsi.org/images/files/ETSIWhitePapers/IOP%20whitepaper%20Edition%203%20final.pdf

Schriftenreihe des LfULG, Heft 4/2022 | 55
Auf den verschiedenen Ebenen erwachsen unterschiedliche Anforderungen, um Interoperabilität zu errei-
chen. So erfordert die strukturelle Interoperabilität beispielsweise ein Netzwerkprotokoll. Dies reicht jedoch
noch nicht aus, um syntaktische Interoperabilität zu erreichen. Auf dieser Stufe werden Spezifikationen für
Datenstrukturen und -formate benötigt. Semantische Interoperabilität erfordert eine inhaltliche Beschreibung
der Strukturen – möglichst nicht nur als Spezifikationstexte, sondern in maschinenlesbarer Form. Organisa-
torische Interoperabilität erfordert die Abstimmung auf Prozessebene. Standards und Spezifikationen im
Agrarbereich decken heutzutage in Teilen die Bedürfnisse der beiden untersten Stufen der Interoperabilität
ab. Ansätze für semantische Interoperabilität werden in anderen Domänen bereits produktiv eingesetzt, im
Agrarbereich bislang aber lediglich im Rahmen von Forschungsprojekten erprobt. Organisatorische Interope-
rabilität zu erreichen stellt im Agrarbereich eine besondere Herausforderung dar, da – wie weiter unten dar-
gestellt – die Variabilität von Prozessabläufen hoch ist.
2.3.2.2 Definition Medienbruch
Ein Medienbruch verhindert, dass der Datenbedarf auf der Seite eines datenauswertenden Systems mit
Blick auf die Auswertungsziele angemessen befriedigt werden kann. Dies kann durch eine Verhinderung des
freien Flusses von Daten von einer Quelle an den Ort, an dem eine Verarbeitung oder Auswertung erfolgt,
verursacht sein. Jedoch treten auch Fälle auf, in denen Daten zwar fließen können, aber nicht zur Auswer-
tung geeignet sind, da notwendige Teilinformationen fehlen oder seitens der Quelle in einer Form dargebo-
ten werden, die den Ansprüchen der Auswertung nicht genügt. In der Regel verhindert ein Medienbruch
einen vollautomatisierten Datenaustausch und erfordert einen manuellen Anwendereingriff.
Medienbrüche können auf verschiedenen Ebenen einer geschichteten Kommunikationsarchitektur auftreten
und durch verschiedene Ursachen entstehen, die jeweils getrennt zu betrachten und zu behandeln sind:
Auf physischer Ebene: Physikalische Übertragungsmedien (Steckverbinder, Speichermedien) werden
von den beteiligten Endgeräten nicht unterstützt oder nicht bereitgestellt.
Auf Ebene von Netzwerkprotokollen/der Infrastruktur: Die von der Datenquelle angebotenen Protokolle
werden von der Senke nicht „gesprochen“ oder umgekehrt.
Auf Ebene der Syntax: Daten können zwar auf Protokollebene übertragen werden, das Datenformat der
Quelle kann von der Senke aber nicht eingelesen werden.
Auf Ebene der Semantik: Protokoll und Format werden zwar auf beiden Seiten unterstützt, die beiden
Enden der Kommunikation interpretieren dieselben Strukturen jedoch unterschiedlich.
Des Weiteren kann ein Medienbruch auch durch unvollständige Daten verursacht werden, d. h. alle vier o.g.
Ebenen werden zwar angemessen bedient, aber die Quelle liefert nicht die Daten, die die Senke benötigt,
um bestimmte Auswertungen durchzuführen.
Die einzelnen Fälle sollen im Folgenden kurz anhand von Beispielen aus den betrachteten Prozessen be-
leuchtet werden.
2.3.2.3 Medienbruch auf physischer Ebene
Die Norm ISO11783 spezifiziert auf physischer Ebene in Teil 1 die genauen Abmessungen und Eigenschaf-
ten der Steckverbinder zwischen Traktor und Anbaugerät. An dieser Stelle kommt es daher in der Regel zu
keinen Medienbrüchen. Für die Datenübertragung zum FMIS ist jedoch als Übertragungsmedium derzeit
noch ausschließlich der Übertrag per physischem Speichermedium (USB-Stick, Compact-Flash-Karte)
genormt. Sofern das die Daten empfangende Gerät kein entsprechendes Lesegerät bereitstellt, kommt es

Schriftenreihe des LfULG, Heft 4/2022 | 56
hier zu einem Medienbruch. Ein solcher Medienbruch lässt sich meist kostengünstig durch Beschaffung
entsprechender Adapter beheben. An dieser Stelle sollten aber Aspekte der Datenträgerhandhabung mit
bedacht werden: In der landwirtschaftlichen Praxis sind häufig mehrere Datenträger zur Datenerfassung im
Betrieb unterwegs, die im Büro wieder einzelnen Maschinen und/oder Tätigkeiten wieder zugeordnet wer-
den müssen. Zudem besteht das Risiko eines Verlustes, sodass Daten auch unwiederbringlich verloren
gehen können. Aus dem Grund bieten einige Hersteller Alternativen zur genormten Übertragung per Spei-
chermedium an oder entwickeln diese derzeit (z. B. Agrirouter, Exatrek, Hansenhof). Dabei werden Daten
über das Internet übertragen. Dieser Weg ist jedoch aktuell noch nicht genormt, weshalb dann auf anderer
Ebene dann Medienbrüche entstehen können. Zwischenzeitlich wird jedoch eine Normung bereits in den
entsprechenden Gremien diskutiert.
Als eine Art Medienbruch auf physischer Ebene kann auch der Fall betrachtet werden, in dem Daten nicht
digital, sondern lediglich auf Papier vorliegen oder die Information so kodiert ist, dass sie nicht unmittelbar
verarbeitbar ist (z. B. Audioaufzeichnungen oder freie Notizen). Insbesondere ersterer Fall spielt in der Land-
wirtschaft nach wie vor eine Rolle bei der Verarbeitung von Informationen von Dritten. Beispielsweise geht
es dabei um Laborberichte (Bodenanalysen) oder Abrechnungen. Dies hat – wie später dargestellt – auch
auf die Ermittelbarkeit einiger betrachteter Zielgrößen einen unmittelbaren Einfluss.
2.3.2.4 Medienbruch auf Protokollebene
Datenübertragungsmechanismen zwischen digitalen Systemen von Sensoren bis hin zu Serverplattformen
sind in der Regel geschichtet aufgebaut (z. B. OSI 7-Schichten-Modell
82
, TCP/IP 4-Ebenen-Modell
83,84
). Die
verschiedenen Ebenen/Schichten bilden dabei unterschiedliche Funktionen wie Adressierung von Netz-
werkknoten und -schnittstellen oder den Verbindungsaufbau ab. Für fachliche Anwendungsfälle inhaltlich
relevante Daten werden auf der obersten Ebene in Datenformaten kodiert. Ein Medienbruch kann daher
nicht nur durch Inkompatibilitäten in Formaten, sondern auch in Protokollen einer der unteren Ebenen zu-
stande kommen. Einige der Schichten können heutzutage als hinreichend standardisiert, gut verstanden
und technisch beherrscht angesehen werden, sodass dort keine Medienbrüche mehr auftreten oder diese
mit überschaubarem Aufwand zu beheben sind. Dennoch können auch auf Protokollebene noch Verbin-
dungsprobleme auftreten. Dies kann z. B. die Anbindung von Sensoren aus dem Umfeld des Internet of
Things (IoT) betreffen, die Messwerte sammeln, wie Temperatur- oder Feuchtesensoren in Gebäuden oder
Wetterstationen, und die für die Kommunikation nur begrenzte Hardwareressourcen bereitstellen können –
beispielweise, weil sie auf geringen Strombedarf ausgelegt sind. In einem solchen Kontext kommen dann
auch häufig einfache und effiziente Protokolle wie das am sogenannten Publish-Subscribe-Paradigma ori-
entierte MQTT zum Einsatz. Im Web hingegen hat sich das am Request-Response-Paradigma orientierte
HTTP durchgesetzt, das einen höheren „Overhead“ als Nachteil mitbringt. Dies bedeutet, dass ein gewis-
ser, im Vergleich mit beispielsweise MQTT etwas höherer Anteil des gesamten übertragenen Datenvolu-
mens zur Übermittlung von sogenannten Nachrichtenkopfzeilen genutzt wird und für die ”Nutzlast”, die
82
ITU-T X.200 (07/1994). International Telecommunication Union
83
https://www.rfc-editor.org/rfc/rfc1122.txt
84
https://www.rfc-editor.org/rfc/rfc871.txt

Schriftenreihe des LfULG, Heft 4/2022 | 57
eigentlichen Dateninhalte, nicht zur Verfügung steht. Dafür hat HTTP andere Vorteile wie eine einfache
Erweiterbarkeit. Sofern ein zentraler Datenhub oder Datenrouter das von Sensorsystemen zur Bereitstel-
lung von Daten vorgesehene Protokoll nicht „spricht“, entsteht hier ein Medienbruch. Behoben werden kann
das Problem dadurch, dass zentrale Komponenten von Grund auf multiprotokollfähig ausgelegt werden –
für eine Reihe von IoT-Plattformen verschiedener Hersteller ist das der Fall. Auch für das aktuell in den
ISO-Normungsprozess eingebrachte EFDI-Protokoll zum Austausch von Daten von Landmaschinen wurde
die Auslegung der Nachrichten auf Multiprotokollfähigkeit vorgesehen. Eine Alternative ist der Einsatz von
Gateways, die ohne Veränderung des Nachrichteninhalts auf Protokollebene übersetzen und dann als zu-
sätzliche Komponente in einem Netzwerk betrieben werden müssen. Die Behebung eines solchen Medien-
bruchs erfordert daher Personal mit informationstechnischer Expertise, das sich entweder um das Auf-
setzen und den Betrieb eines Gateways kümmert oder durch Anpassungen am Programmcode von Daten-
erfassungskomponenten Unterstützung leistet. Für hinreichend breit genutzte Protokolle stehen in der Re-
gel zuverlässige und gut ausgearbeitete Bibliotheken in verschiedenen Programmiersprachen zur Verfü-
gung, sodass es häufig ausreicht, einfachen „Glue Code“ einzufügen. Hierbei handelt es sich um relativ
kurze Abschnitte an Programmquelltext, der im wesentlich dazu dient Funktionen untereinander zu ver-
binden, indem Ein- und Ausgabeparameter aneinander angepasst werden.
2.3.2.5 Medienbruch auf syntaktischer Ebene
Ein Medienbruch auf syntaktischer Ebene ergibt sich, wenn für die Kodierung grundsätzlich äquivalenter
oder zumindest ähnlicher fachlicher Inhalte von verschiedenen Systemen unterschiedliche Datenformate
genutzt werden. Typische Beispiele für solche Medienbrüche finden sich im Bereich der Kodierung von Geo-
daten. Die öffentliche Verwaltung ist in Europa gehalten, Geoinformation gemäß der INSPIRE-Richtlinie auf
Grundlage der Standards des Open Geospatial Consortiums (OGC) bereitzustellen. Teil der Spezifikation ist
die Nutzung der Geography Markup Language (GML), die erlaubt, Geodaten auf Basis eines objektorientier-
ten Modells in XML zu repräsentieren. Dabei werden in Application Schemas Objektklassen wie z. B. Ge-
wässer, Verkehrswege und Landschaftselemente mit ihren Eigenschaften definiert, denen Geometrien als
Punkte (Point), Polygone (Polygon) oder Linienzüge (Linestring) zugewiesen werden können. ISO11783-10
als zur Übertragung von Applikationskarten auf Landmaschinen vorgesehener Standard enthält ebenfalls
Elemente, die die Übertragung solcher Daten mit Raumbezug erlauben sollen. Die Darstellung dieser Struk-
turen unterscheidet sich jedoch – obwohl auch XML als textuelles Format genutzt wird – von den in der Ge-
ography Markup Language spezifizierten Strukturen. So werden in ISOXML beispielsweise lediglich 3-buch-
stabige Kurzbezeichnungen für die Elementnamen genutzt (PNT, PLN und LSG) und die Nutzung verschie-
dener Koordinatenreferenzsysteme ist nicht möglich. Neben den beiden o.g. Formaten sind außerdem nach
wie vor Geodaten im älteren, proprietären Shapefile-Format im Umlauf. Das Shapefile-Format besteht aus
einer binären Kodierung der Geometrien in Kombination mit Attributtabellen im dBASE-Datenbankformat.
Neuere Geodienste sehen ein weiteres Format vor – GeoJSON –, das syntaktisch der JSON-Format-
spezifikation folgt. Die geschilderte Variabilität bei den Geodatenformaten führt dazu, dass die in den Forma-
ten enthaltenen grundsätzlich gleichen Datentypen (Polygone, Punkte, Linienzüge) nicht ohne weitere syn-
taktische „Übersetzung“ in den anderen Formaten genutzt werden können. Das heißt, dass beispielsweise
Daten aus einem Dienst der öffentlichen Verwaltung nicht unmittelbar in einem lediglich auf Shapefiles aus-
gelegten GIS-Werkzeug dargestellt werden können oder ein Shapefile nicht direkt als ISO11783-Appli-
kationskarte verwendet werden kann. Die Behebung dieses Medienbruchs erfordert die Programmierung

Schriftenreihe des LfULG, Heft 4/2022 | 58
entsprechender Ein- und Ausgaberoutinen (Parsing/Serializing) sowie Übersetzungsfunktionen für die unter-
schiedlichen Formate. Pauschale Aussagen zum Aufwand sind hier nicht möglich. Dieser hängt von der
Komplexität der betrachteten Strukturen und der Verfügbarkeit entsprechender Werkzeuge und Programm-
bibliotheken ab.
2.3.2.6 Medienbruch auf semantischer Ebene
Ein Medienbruch auf semantischer Ebene entsteht, wenn Bereitsteller und Konsumenten/Nutzer von Daten
unterschiedliche Auffassungen im Hinblick auf die Bedeutung der Daten vertreten oder keinen einheitlichen
Wissensstand hierüber haben. Das führt in der Regel dazu, dass Eignungen und/oder Nützlichkeit für be-
stimmte Anwendungsfälle suggeriert oder angenommen werden, die tatsächlich nicht gegeben sind. An der
Betrachtung der Nachnutzungspotenziale von Flächenreferenz-Geodaten aus dem InVeKoS-LPIS (Land
Parcel Information System) lässt sich dies illustrieren: Die InVeKoS-Verordnung (InVeKoSV) sieht in §3
orientiert an den übergeordneten EU-Verordnungen vier verschiedene Referenzflächensysteme vor:
Feldblock: eine von dauerhaften Grenzen umgebene zusammenhängende landwirtschaftliche Fläche
eines oder mehrerer Betriebsinhaber
Schlag: eine zusammenhängende landwirtschaftliche Fläche, die von einem Betriebsinhaber mit einem von
der Landesstelle vor der Antragstellung für die Zwecke der Antragsbearbeitung festgelegten Nutzungscode
im Sammelantrag angegeben wird
Feldstück: eine zusammenhängende landwirtschaftliche Fläche eines Betriebsinhabers
Flurstück: eine im Kataster abgegrenzte Fläche.
Die Flächengrenzen – Geodaten als Polygonzüge – werden mithin auf unterschiedliche Weise orientiert an
verschiedenen Ausprägungen von Eigentumsverhältnissen, natürlichen Grenzen, administrativen Grenzen
und landwirtschaftlicher Nutzung festgelegt. Die Bestimmung dieser Referenzparzellen für das System zur
Identifizierung landwirtschaftlicher Parzellen obliegt den Bundesländern. Die Interpretation (Bedeutung)
dieser Geodaten kann sich zwischen verschiedenen Ländern also unterscheiden. Damit sind die Daten nicht
mehr „austauschbar“ im Sinne einer unbedingten Eignung für dieselben Anwendungsfälle, d. h. Flächenda-
ten aus Bundesland A können unter Umständen nicht für dieselbe Menge an Anwendungsfällen genutzt
werden wie Flächendaten aus Bundesland B. Geodaten einer Referenzfläche aus dem Feldblocksystem
sind beispielsweise nur bedingt geeignet für die Bearbeitung von Anwendungsfällen wie Berechnung einer
Applikationskarte für den Pflanzenschutz oder Düngeplanung, da in diesem System eine Fläche mehreren
Betriebsinhabern zugewiesen sein kann, die unterschiedliche Anbaustrategien verfolgen. Gleiches gilt für
das Flurstücksystem, aber mit anderem Grund: Katasterflächen können etwa zu einer zusammenhängenden
Anbaufläche zusammengefasst sein. Für eine gezielte Bearbeitung dieser Anwendungsfälle müssen die
InVeKoS-Referenzflächen in einer Reihe von Fällen also geteilt oder zusammengefasst werden. Diese Teil-
flächen oder aggregierten Flächen sind wiederum in der Folge nicht mehr im Kontext des InVeKoS-
Verfahrens direkt als Referenzflächen nutzbar, da sie den gesetzlichen Vorgaben hierfür nicht mehr entspre-
chen. Flächen aus dem Schlagsystem hingegen können für die o. g. Anwendungsfälle gut geeignet sein,
aber wiederum von Einschränkungen für andere Fälle betroffen sein. Der Medienbruch besteht in diesem
Kontext darin, dass Daten nicht unbesehen für bestimmte Anwendungsfälle übernommen werden können –
Automatisierungspotenziale können daher nicht ausgeschöpft werden und der Anwender ist zur Interaktion
gezwungen, muss eine Eignungsprüfung und ggfs. manuelle Anpassungen vornehmen, die die weitere
Nachnutzung dann wiederum einschränken. Medienbrüche dieser Art lassen sich nicht durch einfache tech-

Schriftenreihe des LfULG, Heft 4/2022 | 59
nische Lösungen in den Griff bekommen. Ansatzpunkte finden sich jedoch in expliziter semantischer Daten-
modellierung und -beschreibung. In dem konkreten Beispiel würde man die verschiedenen Flächenreferenz-
systeme in Datenformaten eindeutig und unterschiedlich bezeichnen und in einer parallel geführten Daten-
beschreibung umreißen, dass es sich um zwar von einer gemeinsamen Datenklasse abgeleitete, aber unter-
schiedliche Strukturen handelt. Dies liefert notwendige Kontextinformation und eröffnet die Möglichkeit, für
Anwendungen nur eindeutig passende Daten abzufragen und bei fehlenden oder nicht passenden Daten
angemessen zu reagieren. Die Auswertung dieser Kontextinformation und die Festlegung angemessenen
Verhaltens der Software obliegt der Umsetzung durch die Programmierer der Anwendungen und ist oft nicht
trivial. In der Praxis bleiben bei solchen Medienbrüchen derzeit daher häufig noch gewisse Lücken. Lösungs-
alternativen, die auf dem Grundgedanken der Einigung auf ein einziges, einheitlich interpretiertes Modell
beruhen, sind in der Vergangenheit allerdings auch regelmäßig gescheitert: Unterschiedliche Auffassungen
zur Interpretation von Daten haben oft eine fachliche Berechtigung und notwendige Kompromisse führen
dann auch zu einer Einschränkung der Nutzbarkeit der Daten für verschiedene Anwendungsfälle.
Eine weitere Art eines Medienbruchs, der sich zwischen syntaktischer und semantischer Ebene einordnen
lässt, ist der Medienbruch, der aufgrund unterschiedlicher Kodiersysteme für ähnliche Sachverhalte entsteht.
So wird im InVeKoS-Antragsverfahren die Angabe der angebauten Kulturen gemäß der InVeKoS-Kultur-
codes verlangt. In Angaben zur Zulassung für Pflanzenschutzmittel hat sich jedoch das EPPO-Kultur-
codesystem (ehemals Bayer-Code) etabliert, sodass auch in der Pflanzenschutzberatung darauf Bezug
genommen wird. Die beiden Systeme sind nicht kompatibel. Eine Anbaudokumentation auf Basis nur eines
dieser beiden Systeme kann daher nicht für beide Gruppen von Anwendungsfällen genutzt werden, obwohl
praktisch gleiche fachliche Inhalte zum Ausdruck kommen. InVeKoS-Kulturcodes sind numerisch, während
EPPO fünfstellige Buchstabenkombinationen benutzt. Zudem sind die Codes in verschiedenen Bereichen
unterschiedlich granular und enthalten Spezialfälle (InVeKoS-Codes beispielsweise für Brachen, die in den
EPPO-Codes nicht enthalten sind). Weil dadurch keine 1:1-Zuordnung möglich ist, stößt die gängige, einfa-
che Herangehensweise an solche Übersetzungsaufgaben mit zweispaltigen Zuordnungstabellen schnell an
Grenzen. Ausgefeiltere Systeme können heutzutage auch unterschiedliche Arten von Zuordnungsrelationen
(Ober-/Unterbegriffsrelationen, Verwandtschaft/Ähnlichkeit vs. Identität etc.) ausdrücken; außerdem können
Ähnlichkeiten auch numerisch bewertet werden. Die Erarbeitung und Entwicklung solcher Zuordnungssys-
teme könnte durch überschaubare Maßnahmen deutlich vereinfacht werden. Wenn Daten- und Kodiersys-
temanbieter für die von ihnen vorgegebenen alphanumerischen Codes Mechanismen zur Konvertierung
ihrer internen Identifier in global eindeutige URIs z. B. durch Zuweisung eines „offiziellen“ Präfixes bereitstel-
len würden, könnten Dritte diese Codes referenzieren und selbst – ggfs. auch kollaborativ oder in einem
Community-getriebenen Ansatz – allgemein verwendbare Zuordnungen erstellen. Auch hier muss die Soft-
ware diese Zuordnungsrelationen oder Ähnlichkeitsangaben jedoch auswerten können, und das richtige
Verhalten bei der Übersetzung von unsicheren oder komplexeren Zuordnungen muss durch Entwickler defi-
niert und vorgegeben werden.
2.3.2.7 Medienbruch aufgrund fehlender Daten
Eine weitere Art des Medienbruchs kann sich durch fehlende Daten ergeben. Dabei kann die Datenquelle den
durch die gewünschte Auswertung gegebenen Datenbedarf nicht erfüllen. Da in der Landwirtschaft unzählige
Auswertungsszenarien und -ziele existieren, lassen sich auch eine Reihe von Beispielen hierfür finden. Die
automatisierte Erfassung von Daten zur Bodenbearbeitung scheitert beispielsweise oft an der fehlenden
ISOBUS-Unterstützung der Anbaugeräte. Diese melden sich dann nicht selbstständig am Bus an und die

Schriftenreihe des LfULG, Heft 4/2022 | 60
Landwirtinnen und Landwirte sind dann selbst dafür verantwortlich, die entsprechenden Aufzeichnungen
vorzunehmen oder anzustoßen. Teilweise fehlt auch die Aufzeichnung benötigter Parameter wie Ernte- oder
Ausbringmengen, da hierfür notwendige Sensoren an den Geräten nicht vorhanden sind. Die konkrete Aus-
prägung dieser Art von Medienbruch hängt stark vom Maschinenpark und der Ausstattung des Betriebs mit
automatischen Datenerfassungseinrichtungen ab, kann also betriebsindividuell sehr unterschiedlich ausfallen.
Behebungsmöglichkeiten müssen abhängig von den Auswertungsbedürfnissen des Betriebs analysiert wer-
den und reichen von manueller Eingabe/Nachpflege von Daten über die Montage von zusätzlicher Sensor-
und Aufzeichnungstechnik bis hin zur gezielten Auswahl von Maschinen bei Neuanschaffungen. Werkzeuge
wie die AEF ISOBUS-Datenbank
85
können bei der Orientierung helfen. Diese zeigt anhand definierter Funkti-
onalitätsgruppen, sogenannter TC functionalities (z. B. TC-BAS (basic), TC-GEO (geo-based)), welche Ma-
schinen diese unterstützen. Dies erlaubt zumindest eine erste Einschätzung der Kompatibilität von Geräten
untereinander und einiger Aspekte zum Datenumfang (ob z. B. generell Applikationskarten genutzt oder Geo-
daten mit aufgezeichnet werden können). Auf Ebene einzelner Parameter bleibt die Einschätzung jedoch
schwierig. In Anhang F des Normendokuments zu ISO11783-10 (TC Functionalities and Device Descriptor
Object Pool Definitions) werden zwar für einzelne TC functionalities DDIs genannt, die meisten davon sind
jedoch lediglich „empfohlen“. Eine Forderung, mehr DDIs als verpflichtend zu spezifizieren, ist in diesem Zu-
sammenhang nicht hilfreich, da es in der Regel gute Begründungen für die Optionalität gibt. Eine wesentlich
gezieltere Einschätzung zur Fähigkeit des Geräts, bestimmte Einzelparameterwerte liefern zu können, würde
der Blick in die sogenannte Device Description erlauben. Diese enthält eine maschinenlesbare Beschreibung
der Teilkomponenten eines Geräts sowie der durch diese Teilkomponenten nutzbaren / erfassbaren Einstell-
bzw. Sensorwerte und wird beispielsweise genutzt, um das Terminal automatisiert zur Anzeige korrekter
Werte zu instruieren. Eine Publikation der Device Descriptions durch Hersteller für die von ihnen hergestellten
Maschinen würde helfen, das Auftreten von Medienbrüchen durch fehlende Daten zu verringern. Derzeit
wären hiermit zwar noch eine Reihe praktischer Probleme verbunden: Beispielsweise müssten in einer je
nach Hersteller komplexen Kombination von Modellen, Serien und jeweiligen Softwareständen die richtigen
Beschreibungen ausgewählt werden können und Werkzeuge bereitgestellt werden, um diese menschen-
lesbar aufzubereiten und Landwirtinnen und Landwirte müssten befähigt werden, die Informationen für ihre
Situation zu interpretieren. Diese Schwierigkeiten sind jedoch technisch und durch entsprechende Ausbildung
mittel- bis langfristig lösbar.
Zusammenfassend lässt sich sagen, dass Medienbrüche durch fehlende Daten schrittweise und gezielt be-
zogen auf den Einzelbetrieb reduziert werden können, doch die notwendige Analyse der individuellen Be-
triebsbedürfnisse und die Recherche möglicher Lösungen ist zeitaufwändig.
2.3.2.8 Umgang mit Medienbrüchen
Je nach Ursache eines Medienbruches ist dieser unterschiedlich zu behandeln. Bei der Festlegung der Stra-
tegie spielt zudem die Häufigkeit des Auftretens eine Rolle: Wie oft wird der spezifische Prozess, in dem der
Medienbruch auftritt, ausgeführt? Handelt es sich beispielsweise um ein Antragsverfahren, das einmal im
Jahr durchgeführt wird oder geht es um die während gewisser Phasen potenziell täglich durchzuführende
Planung von Pflege-, Düngungs- oder Pflanzenschutzmaßnahmen? Hiervon abhängig kann entweder eine
85
https://www.aef-online.org/de/produkte/aef-isobus-datenbank.html

Schriftenreihe des LfULG, Heft 4/2022 | 61
vollständige Behebung angestrebt werden oder ein manueller Anwendereingriff weiterhin als akzeptabel
angesehen werden. Eine angemessene Analyse zu diesem Aspekt muss jedoch die Anzahl der Teilneh-
menden an den Kommunikationsprozessen mit einbeziehen. Wenn eine große Anzahl an Teilnehmenden
ein System nur selten nutzen muss, wegen restriktiver Anforderungen des empfangenden Systems dabei
aber jedes Mal beträchtliche Zeit für manuelle Einpflege von Daten wegen Medienbrüchen aufwenden muss,
können in der Summe dennoch beträchtliche, die gesamtwirtschaftliche Produktivität mindernde Aufwände
zustande kommen.
Medienbrüche treten auch in anderen Wirtschaftsbereichen und Fachdisziplinen auf und hängen eng mit
dem Konzept der Interoperabilität zusammen. Bereits existierende, durchdachte Grundsätze und Methoden
zur Erhöhung der Interoperabilität beinhalten teilweise auch Maßnahmen zur Vermeidung von Medien-
brüchen und sollten daher zur Anwendung kommen. Dabei hilft die Orientierung an Postel’s Law als überge-
ordnetem, abstraktem Grundprinzip: „Be liberal in what you accept, be conservative in what you send.“ Die
Gegenseite einer Kommunikation sollte dabei als eine anonyme Entität auf Augenhöhe mit eigenen, unbe-
kannten Interessen betrachtet werden. Daher sollten auch keine Annahmen bezüglich des Nutzens und der
Nutzbarkeit der eigenen Systeme für die Gegenseite getroffen werden mit dem Ziel, die Gegenseite als
Sender zu bestimmten Anpassungen an ihren Systemen zu bewegen. Die Verantwortung für die Interpre-
tation von Daten obliegt der Empfängerseite, die dabei auch soweit wie möglich mit Abweichungen umgehen
können sollte, während in der Bereitstellung von Daten so gut wie möglich beste verfügbare Praktiken be-
folgt werden sollten.
Konkretere beste Praktiken beinhalten zum Beispiel die FAIR-Prinzipien, auf die an anderer Stelle bereits
hinreichend hingewiesen wurde
86,87
und die anderweitig detaillierter beschrieben sind
88
. Diese werden ex-
plizit oder implizit und vollständig oder teilweise von bestehenden Infrastrukturen und Initiativen wie GAIA-X,
INSPIRE oder dem Semantic Web und Linked Data aufgegriffen und umgesetzt. Im Zusammenhang mit
einigen der oben genannten Illustrationen von Medienbrüchen würden die FAIR-Prinzipien beispielsweise
folgende Maßnahmen nahelegen:
Zuweisung von global eindeutigen Bezeichnern in Kodiersystemen anstatt Verwendung lediglich
alphanumerischer Codes (s. auch Abschnitt 2.3.2.6). Allein dieser Schritt vereinfacht die Entwicklung
von Zuordnungssystemen und damit künftig die Interpretation von Daten aus verschiedenen Systemen,
die mit unterschiedlichen Kodiersystemen arbeiten, erheblich.
86
Machbarkeitsstudie staatlichen digitalen Datenplattformen für die Landwirtschaft, S. 146,
https://www.bmel.de/SharedDocs/Downloads/DE/_Digitalisierung/machbarkeitsstudie-agrardatenplattform.html
87
Positionspapier Datenmanagement des Kompetenznetzwerks Experimentierfelder, in Arbeit
88
https://go-fair.org/fair-principles

Schriftenreihe des LfULG, Heft 4/2022 | 62
Nutzung von standardisierten und vollständig offen dokumentierten Protokollen (s. a. 2.3.2.4): Dies ver-
hindert Medienbrüche auf Protokollebene. Diese Herangehensweise hat sich zwischenzeitlich in der
Informationstechnik weitestgehend durchgesetzt. Einige für den Datenaustausch relevante Normen
(z. B. einige ISO-Normen) genügen diesem Prinzip jedoch nach wie vor nicht. Dass sich auch innerhalb
des organisatorischen Rahmens der ISO Wege finden lassen, eine offene Bereitstellung von Spezifika-
tionen zu erreichen, lässt sich an einer Reihe von Normen des ISO JTC-1 oder des OGC (OGC-
Spezifikationen sind sowohl vollständig frei als OGC-Standards als auch als ISO-Normen erhältlich)
ablesen.
Nutzung von Datenbeschreibungen und Beschreibungsstandards: Am Beispiel der Geodaten würde dies
bedeuten, den OGC-Standards und INSPIRE-Richtlinien entsprechende Application Schemas und
Metadatenbeschreibungen zu erstellen sowie entsprechende Codelisten zu nutzen. Der reine Austausch
von Shapefiles genügt den Anforderungen heutzutage nicht mehr. Die Shapefile-Spezifikation definiert
lediglich einen „Container“, der es erlaubt, verschiedene geometrische Datentypen mit einer zuge-
hörigen Datenbank zu verknüpfen. Sie stellt jedoch keine Möglichkeiten bereit Strukturen der Datenbank
oder deren Inhalte zu beschreiben. In Bezug auf frühe Anforderungen an Geoinformationssysteme war
diese Vorgehensweise angemessen, da Nutzende in der Regel fachlich versiert waren und durch Blick
auf die Daten richtige Schlüsse ziehen konnten. Shapefiles richtig zu interpretieren erfordert jedoch
immer zusätzliche Vereinbarungen und/oder Nutzerinteraktion. Mit Blick auf Postel’s Law wäre es ange-
messen, Shapefiles als Dienst- und Systemanbieter entgegenzunehmen und bei Bedarf auch wieder be-
reitzustellen. Auf Eingabeseite sollten dabei aber die Vorgaben so gering wie möglich gehalten werden
und auf Ausgabeseite sollte eine Bereinigung und zumindest eine menschenlesbare Beschreibung aller
dabei ausgegebenen Strukturen und Inhalte erfolgen.
2.3.3 Datensouveränität
Die Datensouveränität
89
ist ein wichtiges Thema für Landwirtinnen und Landwirte und weitere Akteure in der
digitalen Landwirtschaft und gewinnt zunehmend an Bedeutung
90
, da immer mehr Daten erhoben werden
und Prozesse wie Zustände abbilden. In der Landwirtschaft wird häufig der Begriff Datenhoheit verwendet,
den wir als Synonym zum Begriff Datensouveränität betrachten. Wir verwenden in dieser Studie den Begriff
Datensouveränität, da dieser in der Branche der Informationstechnologie weiter verbreitet ist und in eng-
lischsprachigen Texten wörtlich übersetzt Verwendung findet, wenn es um diesbezügliche Themen geht.
2.3.3.1 Rechtlicher Hintergrund
Datensouveränität umschreibt den Wunsch, dass ein Akteur über Daten, die aus seinem Kontext stammen
oder ihn bzw. sein Eigentum beschreiben, frei bestimmen kann. Die Daten selbst können dabei nicht Eigen-
tum des Akteurs sein, da es im deutschen Recht kein Eigentum an Daten gibt
91
. Insofern ist der häufig ver-
wendete Begriff „Dateneigentümer“ rechtlich gesehen falsch, ebenso die Formulierung „die Daten gehören
89
https://www.iese.fraunhofer.de/blog/wie-schafft-man-datensouveraenitaet-in-der-landwirtschaft/
90
Vgl. Bitkom (2019): Positionspapier – Datenhoheit und Datennutzung in der Landwirtschaft, online verfügbar unter:
https://www.bitkom.org/sites/default/files/2019-10/bitkom_positionspapier-zu-datenhoheit-und-datennutzung-in-der-
landwirtschaft_final_191021.pdf, letzter Zugriff am 20.08.2021
91
Vogel, P., (2020). Datenhoheit in der Landwirtschaft 4.0. In: Gandorfer, M., Meyer-Aurich, A., Bernhardt, H., Maidl, F.
X., Fröhlich, G. & Floto, H. (Hg.), 40. GIL-Jahrestagung, Digitalisierung für Mensch, Umwelt und Tier. Bonn: Gesellschaft für
Informatik e.V. (S. 331-336).

Schriftenreihe des LfULG, Heft 4/2022 | 63
einer bestimmten Person“. Aufgrund der kontroversen Diskussion in der Rechtswissenschaft kann auch nicht
davon ausgegangen werden, dass mittelfristig der Rechtsbegriff eines Eigentums an Daten geschaffen wird,
denn dies könnte auch Nachteile mit sich bringen. Der Bedarf an Rechtssicherheit hinsichtlich der Daten-
souveränität in der Landwirtschaft wird auch durch weitere Rechtsnormen wie das Urheberrecht oder die
Datenschutz-Grundverordnung (DSGVO) nicht befriedigend erfüllt, sodass Vogel (2020)
68
schließt mit: „Da
auch aus anderen Rechtsgebieten keine allgemeingültigen Regelungen zu einem Recht an Daten abgeleitet
werden können, ist als Zwischenergebnis festzuhalten, dass die Datenhoheit des Einzelnen derzeit kaum
rechtlich abgesichert ist.“ Zur Vermeidung begrifflicher Konflikte verwenden wir in der nachfolgenden Diskus-
sion den abgeschwächten Begriff des „Dateninhabers“, wenn wir bspw. von Daten zu einem Ackerschlag
reden. Die Landwirtin oder der Landwirt, der bzw. dem dieser Schlag gehört oder die bzw. der ihn pachtet,
sind dann die Dateninhaber.
Der Mangel an einem rechtlichen Rahmen zur Sicherung der Datensouveränität bedeutet aber nicht, dass
es illegitim wäre, bspw. Landwirtinnen und Landwirten die alleinige Verfügungsbefugnis an Daten zuzu-
stehen, die in ihrem Produktionskontext entstanden sind. Aber auch diese Diskussion ist komplex: Wie
verhält es sich beispielsweise, wenn Lohnunternehmer mit ihrer Maschine Arbeiten auf dem Ackerschlag
einer Landwirtin oder eines Landwirtes durchführen und dabei Daten generieren und diese ins Cloudsystem
des Maschinenherstellers überführt werden? Welche Rechte haben Landwirt, Lohnunternehmer oder Ma-
schinenhersteller an den Daten, wenn der Rechtsrahmen das nicht eindeutig klärt? Hier können grundsätz-
lich vertragliche Regelungen zwischen den Beteiligten genutzt werden und konkret definieren, wer mit wel-
chen Daten wie umgehen darf. Dazu zählen bspw. die AGB von Softwareanbietern, die den Umgang mit
verschiedenen Daten im Rahmen der Nutzung der Software regeln. Aber auch diese Option bringt Heraus-
forderungen mit sich: Die Komplexität und Vielfalt der erhobenen Daten und technischen Prozesse ist
selbst für Expertinnen und Experten schwer zu überblicken und damit kaum in einem schriftlichen Ver-
tragswerk formulierbar. Selbst wenn, stellen solche Vertragswerke landwirtschaftliche Betriebe vor große
Herausforderungen, die nicht nur die vertraglichen Inhalte erfassen, sondern auch die potenziellen Auswir-
kungen in dem gesamten digitalen Ökosystem kennen müssen. So zieht auch Vogel (2020)
68
das Fazit:
„Gerade im Verhältnis zwischen internationalen Agrarkonzernen und kleinen Landwirtschaftsbetrieben ge-
stalten sich Vertragsverhandlungen – soweit sie überhaupt stattfinden – jedoch alles andere als ausge-
wogen. Die Möglichkeit der vertraglichen Zuweisung ist demzufolge in vielen Fällen ungeeignet, die Daten-
hoheit des Landwirts zu gewährleisten.“ Anbieter von Maschinen oder Software können und sollten zur
Verbesserung der Lage auf Landwirtinnen und Landwirte zugehen und einfach, fair und transparent dar-
stellen, wie welche Daten genutzt werden und auch welche Folgen das für Landwirtinnen und Landwirte
nach sich ziehen kann. Umgekehrt sollten Landwirtinnen und Landwirte sich selbst befähigen oder Unter-
stützung suchen, um diesen Aspekt der Digitalisierung für sich zu erschließen und entsprechend informiert
und selbstbewusst gegenüber ihren Vertragspartnern agieren zu können.
Um den Begriff der Datensouveränität besser verständlich zu machen, schlagen wir die folgenden definie-
renden Kriterien vor. Dabei sei gesagt, dass die Erfüllung aller Kriterien nicht zwangsläufig das Ziel sein
muss und auch technologisch wie vertraglich nur mit erheblichen Aufwänden erreichbar ist. Zudem sollte die
Verhältnismäßigkeit berücksichtigt werden, denn nicht alle Daten sind gegenüber allen möglichen Interes-
sierten (wie Unternehmen oder staatlichen Stellen) gleich schützenswert und Augenmaß kann dabei helfen,
den richtigen Level an Datensouveränität festzulegen. Das Ziel für landwirtschaftliche Betriebe sollte sein,

Schriftenreihe des LfULG, Heft 4/2022 | 64
die Thematik der Datensouveränität gut und umfänglich einschätzen zu können und für sich selbst das pas-
sende Maß festzulegen, das dann durch den Einkauf und Einsatz entsprechender Technologien umgesetzt
werden kann. Die Kriterien der Datensouveränität sind:
Datennutzung durch Dritte nur mit Zustimmung der Dateninhaber:
Erfasst bspw. ein technisches
System Daten auf einem Ackerschlag, sollen diese Daten nur im Sinne des Dateninhabers genutzt
werden dürfen. Sofern Dritte die Daten nutzen können sollen, müssen Dateninhaber in allen Fällen ex-
plizit zustimmen. Diese Zustimmung kann auch widerrufbar gestaltet oder nach Vorgaben einschränkt
werden, bspw. nur für bestimmte Gruppen oder Akteure, nur für definierte Zwecke, nur im Rahmen defi-
nierter Arbeitsaufträge usw.
Vollständige Transparenz für Dateninhaber über die Nutzung von Daten durch Dritte:
Daten-
inhaber sollte möglich sein, die Nutzung von Daten durch Dritte nachvollziehen zu können. Dazu gehört
auch ein umfassendes Verständnis, für welche Zwecke Daten durch Dritte genutzt werden und welche
Konsequenzen eine Zustimmung zur Datennutzung für den Dateninhaber mit sich bringen könnte.
Möglichkeit für Dateninhaber, Daten in verschiedenen Systemen nutzen zu können (Daten-
portabilität):
Werden Daten erfasst, sind sie häufig zunächst direkt in den Ursprungssystemen nutzbar.
Es muss für Dateninhaber möglich sein, die Daten auch in anderen Systemen nutzen zu können. Die Ur-
sprungssysteme müssen geeignete Möglichkeiten anbieten, damit Daten diskriminierungsfrei exportiert
und übertragen werden können. Daraus kann sich weiter ableiten, dass auch importierende Systeme
verpflichtet sind, geeignete Möglichkeiten zur Übernahme von Daten anzubieten. Das ist bspw. der Fall,
wenn Anbieter von Lösungen die Anbindung externer Lösungen einschränken, um die Nutzung des
eigenen Portfolios zu erzwingen. Solche Fälle sind dann problematisch, wenn diese Anbieter über eine
große Dominanz in Märkten verfügen und die Nutzung ihrer Angebote teilweise unumgänglich ist.
2.3.3.2 Technologische Aspekte
Neben organisatorischen Aspekten und Legitimitätsaspekten werden häufig technologische Aspekte im
Kontext der Datensouveränität diskutiert, insbesondere wenn es um die Datenspeicherung geht. Im Fokus
der Diskussion stehen dabei häufig cloudbasierte Datenspeicher, d. h. IT-Systeme, die sich an Standorten
außerhalb der Landwirtschaftsbetriebe befinden und Daten mit lokalen Systemen im Betrieb über das Inter-
net austauschen. Agronomische Daten bspw. von Ackerschlägen in Sachsen sind in einem solchen Szena-
rio in einem Rechenzentrum in Frankfurt gespeichert, wo auch die Online-Ackerschlagkartei betrieben wird.
Es ist nachvollziehbar, dass solche Szenarios Befürchtungen wecken, dass eigene Datenbestände miss-
braucht oder versehentlich offengelegt werden, und es mag sicherer erscheinen, eigene Daten auf eigener
Hardware im eigenen Betrieb zu verwahren. Umgekehrt sind cloudbasierte Systeme üblicherweise hochpro-
fessionell betriebene und vor allem gegen Ausfälle abgesicherte Infrastrukturen, die im landwirtschaftlichen
Betrieb mit vertretbarem Aufwand nicht ähnlich funktionsfähig umsetzbar sind. Zusätzlich gibt es große
Spielräume, cloudbasierte Systeme auszugestalten: Ein Anbieter einer Online-Ackerschlagkartei kann seine
Software bspw. in Rechenzentren ohne regionale Eingrenzung betreiben, d. h. die Daten des Ackerschlages
könnten in China oder den USA gespeichert sein. Um möglicherweise nachteiligen rechtlichen Regelungen
der jeweiligen Länder zu entgehen, können explizit europäische, deutsche oder ganz konkret definierte Re-

Schriftenreihe des LfULG, Heft 4/2022 | 65
chenzentren genutzt werden. Größere Anbieter können sogar eigene Rechenzentren betreiben, um selbst
die größtmögliche Kontrolle über die Daten Ihrer Kunden zu bewahren
92
.
Neben den Orten zur Speicherung und Verarbeitung von betrieblichen Daten spielt auch die Gestaltung der
Softwarelösung und die Organisation des Betriebs eine große Rolle. So ist es mit aktuell verfügbaren Techno-
logien möglich, Daten in Cloudsystemen in einem Maße abzusichern, dass ein Missbrauch quasi unmöglich
wird. Immer wieder auftretende Meldungen von Datenmissbrauch oder gehackten Systemen zeigen zwar,
dass immer wieder negative Vorkommnisse auftreten, doch steht das in keiner Relation zu den vielen sicher
betriebenen Systemen, die unbehelligt negativer Nachrichten existieren. Gegen Missbrauch von Daten durch
Anbieter genutzter Software oder auch staatliche Stellen spricht zudem der für diese erwartbare wirtschaft-
liche oder politische Schaden, falls der Missbrauch öffentlich wird. Zuletzt muss auch berücksichtigt werden,
dass heutzutage fast alle Systeme über eine Internetanbindung verfügen oder diese zum Betrieb sogar benö-
tigen. Sollte ein Anbieter solcher Systeme entsprechende Absichten verfolgen, wäre der Missbrauch von lokal
gespeicherten Daten ebenso möglich wie ein Cyberangriff auf lokale Systeme durch Dritte
93
.
Eine vollständige und dauerhaft gültige Checkliste zur Einschätzung der Sicherheit von cloudbasierten
Diensten kann unter Berücksichtigung der hohen Dynamik des Themas nur eingeschränkt abgeleitet wer-
den. Folgende Punkte können zur orientierenden Einschätzung herangezogen werden:
Der rechtliche Sitz der Anbieter von Softwarelösung und genutzten Clouddiensten ist in Deutschland
oder der EU. So wird sichergestellt, dass ausschließlich die europäische bzw. deutsche Gesetzgebung
zählt und die Vorgaben der DSGVO eingehalten werden. Ausnahmen sind möglich, indem bspw. eine
Muttergesellschaft im EU-Ausland ansässig ist. In dem Fall sollten Bedingungen zum rechtlichen
Umgang mit Daten detailliert geprüft werden.
Die genutzten Serverstandorte befinden sich ausschließlich in Deutschland oder der EU.
Der Cloudanbieter setzt die Kriterien des „Cloud Computing Compliance Controls Catalogue (C5)“ um
und belegt das durch eine entsprechende Zertifizierung (bspw. ISO/IEC 27001)
Der Cloudanbieter bietet den Betrieb in mehreren, verteilten und redundanten Rechenzentren, so dass
bei einem Ausfall zwischen diesen gewechselt werden kann. Durch ein Backupkonzept wird ergänzend
Datenverlust ausgeschlossen. Dies wird vertraglich definiert in sogenannten „Service Level Agreements
(SLA)“, die Reaktionszeit bei Ausfällen oder minimale Betriebsbereitschaft über ein Jahr zusichern.
Insgesamt sehen wir keine Einschränkungen oder Nachteile hinsichtlich der Datensouveränität von Land-
wirtinnen und Landwirten bei der Nutzung von Softwaresystemen, die cloudbasiert betrieben werden. Diese
bringen eher technologische Vorteile mit sich, die beim Betrieb von Systemen in landwirtschaftlichen Be-
trieben direkt nicht mit vertretbarem Aufwand erreichbar sind. Zwar bestehen Hemmnisse durch unzu-
reichende Internetanbindung von Betrieben oder theoretischen Ausfall der Internetinfrastruktur, doch kön-
nen diese durch organisatorische und technische Mittel weitgehend minimiert werden.
92
Weiterführende Informationen unter:
https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-
und-Empfehlungen/Empfehlungen-nach-Angriffszielen/Cloud-Computing/Kriterienkatalog-C5/kriterienkatalog-c5_node.html
und
https://aws.amazon.com/de/compliance/bsi-c5/
93
Vgl.
https://www.golem.de/news/sicherheitsluecke-solarwinds-veroeffentlichte-passwort-auf-github-2012-152921.html
und
https://www.spektrum.de/news/solarwinds-ein-hackerangriff-der-um-die-welt-geht/1819187

Schriftenreihe des LfULG, Heft 4/2022 | 66
2.3.3.3 Zusammenfassung
Datensouveränität ist ein Thema, das für Landwirtinnen und Landwirte wichtig ist, aber in vielen Aspekten
noch zu unscharf diskutiert wird. Umso wichtiger ist es für sie, einzelne Aspekte möglichst umfassend zu
verstehen, um in der Diskussion mit Vertragspartnern auf Augenhöhe agieren zu können. Wichtig ist das
Verständnis der rechtlichen Situation: Im deutschen Recht existiert kein Eigentum an Daten und außer ver-
traglichen Regelungen zwischen Partnern existiert kein Rechtsmittel, um Datensouveränität für Landwirtin-
nen und Landwirte zu erreichen.
Auch wenn Datensouveränität häufig diskutiert wird, gibt es keine allgemeingültige Definition davon. Folgende
Kriterien oder Anforderungen an Datensouveränität können zum Verständnis beitragen:
1) Datennutzung durch Dritte nur mit Zustimmung,
2) vollständige Transparenz über die Nutzung von Daten durch Dritte und
3) die Möglichkeit für Dateninhaber, Daten in verschiedenen Systemen nutzen zu können.
Im Kontext der Datensouveränität werden cloudbasierte Softwaresysteme zur Speicherung und Verarbeitung
von Daten häufig kritisch betrachtet. Nach unserer Einschätzung bieten diese aber einen Funktionsumfang, der
mit vertretbaren Mitteln im landwirtschaftlichen Betrieb nicht erreicht werden kann. Durch die geeignete Aus-
wahl von Standorten zum cloudbasierten Betrieb und das Ergreifen technologischer sowie organisatorischer
Maßnahmen können Einschränkungen hinsichtlich der Datensouveränität weitgehend verhindert werden.

Schriftenreihe des LfULG, Heft 4/2022 | 67
3 Wesentliche Ergebnisse
In diesem Kapitel werden die wesentlichen, im Projekt erarbeiteten Ergebnisse thematisch strukturiert dar-
gestellt. Abschnitt 3.1 thematisiert landwirtschaftliche Produktions- und Managementprozesse. Abschnitt 3.2
stellt ausführlich dar, wie die im Projekt exemplarisch betrachteten Zielgrößen abgeleitet werden können.
Abschnitt 0 diskutiert grundlegende Aspekte zum Datenmanagement, hier werden Ansätze und Konzepte
eingeführt, Ergebnisse aus Fachgesprächen mit Softwareanbietern dargestellt und Lösungswege aufgezeigt.
In Abschnitt 3.4 wird ein FMIS-Entwurf zu den exemplarischen Zielgrößen entwickelt, dargestellt und die
Evaluierungsergebnisse mit Landwirtinnen und Landwirten beschrieben. Der Abschnitt 3.5 fasst die Ergeb-
nisse der vorherigen Abschnitten zusammen und leitet übergreifende Schlussfolgerungen ab, Abschnitt 3.6
schließt das Kapitel mit zielgruppenspezifischen Handlungsempfehlungen.
3.1 Landwirtschaftliche Produktions- und Managementprozesse
Neben der statischen Betrachtung von Datenbeständen, Ressourcen, Komponenten und Softwareanwen-
dungen ist es bei der Konzeption eines übergreifenden, informationstechnischen Systems notwendig, sich
einen Überblick über die dynamischen Aspekte zu verschaffen. Hierzu gehören:
Prozessabläufe
Erzeugung und Nutzung von Daten
Datenflüsse
Im Idealfall lassen sich anschließend Muster identifizieren, die wiederholt auftreten, oder Teilbereiche zu-
sammenfassen. Die folgenden Abschnitte stellen den Ablauf einer solchen Analyse dar. Bewusst wurden an
dieser Stelle noch keine formalen Methoden der Prozessmodellierung eingesetzt, wie beispielsweise der
Einsatz der Business Process Modelling Language
94
. Solche Modelle beinhalten bereits eine Reihe techni-
scher Details, die eher von einem Blick auf Gesamtsystemzusammenhänge ablenken. In einer späteren
Phase kann es aber sinnvoll sein, Teilsysteme entsprechend auszumodellieren.
3.1.1 Produktionsverfahrensübersichten
Die vier vorausgewählten Produktionsprozesse (s. Abschnitt 2.1.1) wurden zunächst gemäß ihres Verfahrens-
ablaufs mit den notwendigen Teilprozessen skizziert. Die vollständigen Darstellungen finden sich in Anhang 2.3.
Die Abbildungen weisen drei Bereiche auf (s. Abbildung 17):
Eine zentrale Hauptachse, auf der die einzelnen Feldarbeiten im Jahresverlauf mit Angaben zur zeitlichen
Einordnung in Halbmonatsabschnitten bzw. für die Tierhaltung in Arbeitsschritten aufgetragen sind.
Ein darüber angesiedelter Bereich, der die wichtigsten, regelmäßig auftretenden Schnittstellen mit verti-
kalen Prozessen des Betriebsmanagements ausweist. In der Praxis sind wesentlich mehr Verknüpfungen
vorhanden; teils müssen auch ad-hoc Entscheidungen getroffen werden, die hier nicht mit aufgenommen
sind, aber in der weiter unten beschriebenen Detailmodellierung einzelner Teilprozesse.
94
https://www.bpmn.org/

image
Schriftenreihe des LfULG, Heft 4/2022 | 68
Ein darunter angesiedelter Bereich, der die wichtigsten regelmäßig auftretenden Schnittstellen zu
weiteren Produktionsprozessen (horizontale Vernetzung) aufzeigt. Hierbei ist zu beachten, dass alle pa-
rallel laufenden Produktionsprozesse miteinander um Ressourcen konkurrieren. Neben den dargestellten,
auf Flüssen von Prozess-Input/-Output basierenden Zusammenhängen bestehen weitere Abhängig-
keiten, über die sich Prozesse gegenseitig beeinflussen und in denen Informationsflüsse zur Koordination
notwendig sind.
Abbildung 17: Darstellungsschema Produktionsverfahren
In einem nächsten Schritt können beteiligte technische Systeme hinzugefügt werden. In diese Grafiken wur-
den hierbei lediglich die Maschinen aufgenommen. Innerhalb der Teilschritte sind diese nur abstrakt unter
Angabe der ISOBUS Device Classes aufgeführt (Abbildung 18). Sofern ein Datenkatalog erstellt wurde, der
verfügbare Datenattribute den beteiligten Teilsystemen zuweist (s. Abschnitt 2.1.2.4), kann unmittelbar ermit-
telt werden, welche Daten in einem Prozessschritt als Input oder Output erwartet werden können. Mit der
gegebenen Aufbereitung des ISOBUS Data Dictionary könnte beispielsweise die Filterung auf die Device
Classes 1 (Tractors) und 6 (Sprayers) gesetzt werden, um festzustellen, welche DDIs bei Pflanzenschutz-
maßnahmen relevant sein können und in eine der beiden Richtungen übertragen werden können.

image
image
Schriftenreihe des LfULG, Heft 4/2022 | 69
Abbildung 18: Schema beteiligte ISOBUS Device Classes
Sofern eine solche Prozessanalyse in einem Einzelbetrieb durchgeführt wird, können hier auch die tatsäch-
lichen Maschinen aufgenommen werden. Lediglich die Ermittlung nutzbarer Datenattribute (DDIs) stellt hier
eine gewisse Herausforderung dar. Grundsätzlich finden sich diese in der vom Gerät in ISOXML herausge-
schriebenen Device Description – diese ohne spezielle Werkzeuge lediglich mithilfe eines Texteditors her-
auszulesen ist zwar möglich, erfordert aber eine gewisse Sachkunde zum Aufbau des XML-Formats. Eine
vollständige Übersicht lieferbarer DDIs für alle am Markt erhältlichen Maschinen existiert nicht – zumal sich
diese Information auch mit Firmware-Updates von Embedded Control Units ändern kann und für Ausstat-
tungsvarianten variiert. Landwirtinnen und Landwirte, die mit den Begrifflichkeiten von ISO11783 grob ver-
traut sind, könnten auch gezielt bei ihrem Händler anfragen – was die Bedeutung der Ausbildung und des
Wissenstransfers bezüglich solcher Technologien unterstreicht.
3.1.2 Prozessmodell Düngeprozess
Die vorliegenden Abbildungen der Produktionsverfahren bilden bezüglich der Vernetzung von Komponenten
nur Teilaspekte ab. Das Hinzufügen weiterer Elemente und Detailinformationen hätte aber zu einer sehr
unübersichtlichen Darstellung geführt. Daher wurde entschieden, einen einzelnen Teilschritt einer Feldarbeit
herauszugreifen und in größerer Detailtiefe in einer Art Sequenzdiagramm
95
zu analysieren. Dabei wurden
Datenflüsse von und zu Softwareanwendungen eingebunden und Abhängigkeiten mit Prozessen des Be-
triebsmanagements wie beispielsweise Betriebsmittelbeschaffung und mit Prozessen der Ermittlung ökono-
mischer Kenngrößen im Nachgang zur Durchführung des Prozesses berücksichtigt. Das Ergebnis ist die
Grafik zum Düngeprozess in Anhang 2.4.1.
95
s. https://de.wikipedia.org/wiki/Sequenzdiagramm

Schriftenreihe des LfULG, Heft 4/2022 | 70
3.1.2.1 Vereinfachende Grundannahmen
Bei der Erstellung des Modells wurden einige vereinfachende Annahmen vorausgesetzt bzw. bewusst ein-
zelne Aspekte weggelassen, um die ohnehin schon komplexe Darstellung nicht weiter zu überfrachten. Im
Einzelnen sind dies:
Flächen-, Rechte- und Gebäudekosten wurden nicht berücksichtigt: Normalerweise müssten Prozesse
zur Akquise dieser Ressourcen mit berücksichtigt werden, um eine korrekte Kostenleistungsrechnung
durchzuführen (s. Methodische Beschreibung der Kosten-Leistungs-Rechnung in Abschnitt 3.2.7).
Es wurde angenommen, dass die Beschaffung von Betriebsmitteln ausschließlich mit Eigenkapital
erfolgt.
Gleiches gilt für Wartung und Reparaturen. Zudem wurde angenommen, dass die Versicherung „Pflicht“
ist, automatisch abgebucht wird und daher keine Abfrage des Kontostandes notwendig ist.
Teilweise sind mehrere Optionen möglich: Beispielsweise wurde beim Zuwiegen des Düngemittels
angenommen, dass dies über ein Wägesystem erfolgt, um dieses auch im Modell mit einbinden zu
können. Je nach Ausstattung kann die Mengenerfassung/Dosierung bei der Befüllung aber auch über das
Anbaugerät erfolgen.
Die Landwirtin oder der Landwirt fungiert als „Datenrouter/-hub“, d. h. sie bzw. er interagiert mit allen
dargestellten Systemen und nimmt Datentransfers vor. Damit entspricht die Darstellung eigentlich einer
„Worst-Case“-Situation, die aber in der Praxis durchaus – wenn vielleicht auch mit weniger Systemen –
auftreten dürfte. Im Idealfall würde man entweder an neuralgischen Punkten oder dort, wo Lösungen
besonders einfach sind, zu optimieren beginnen und versuchen den Zwang zur Interaktion mit Systemen
für die Landwirtin oder den Landwirt soweit wie möglich zu reduzieren. Weiter unten werden einzelne
Problemstellen und Ansatzpunkte hierfür aufgegriffen.
3.1.2.2 Erläuterungen zur Darstellung
Die Seitenbalken ganz links in der Abbildung fassen Teilprozesse zusammen, Spalte 1 weist entsprechende
Teilprozesse aus. Unterschieden wurde dabei wie folgt:
Ressourcenbeschaffung
Einkauf Traktor
Einkauf Düngerstreuer
Einkauf Düngemittel
Einkauf Diesel
Ressourcen betriebsbereit halten
Reparaturen und Wartung Traktor
Reparaturen und Wartung Düngerstreuer
Versicherungen Fahrzeuge
Prozessvorbereitung und Planung
Bodenprobe
Düngebedarfsermittlung
SOLL-Applikationskarte erstellen

Schriftenreihe des LfULG, Heft 4/2022 | 71
Prozessdurchführung
Düngemittel einfüllen
Traktor betanken
Startzeit/-werte erfassen
Endzeit/-werte erfassen
Restmenge rückführen
Prozessdokumentation
IST-Applikationskarte/ISO11783 Dokumentation
Auswertung
Ökonomisch, Zielgrößen z. B. Kosten
Spalte 2 unterteilt die gegebenen Teilprozesse nochmals in Unterprozesse/Funktionen oder auch Aktivitäten
und Aufgaben. Diese Unterprozesse sind bestimmten Aktivitätsklassen zugewiesen, die jeweils einen ge-
meinsamen Charakter haben und durch die in der Legende beschriebene Farbkodierung ausgewiesen wer-
den. Für komplexe Teilprozesse werden Datenflüsse nicht umfänglich dargestellt, aber eine kurze Beschrei-
bung skizziert diese grob. Die einzelnen Softwareklassen (s. Abbildung 5 u. Abschnitt 2.2) sind in vertikalen,
sogenannten „Swim Lanes“ aufgetragen. Berücksichtigt wurden in dem Beispiel:
Buchhaltung
Banksoftware
Arbeitszeiterfassung
Warenmanagement
Ackerschlagkartei
Precision Farming
Maschine/Embedded Control Unit
Flottenmanagement
BESyD als Beispiel für ein externes System
Wiegesystem
Punkte in der jeweiligen Spalte signalisieren eine Beteiligung des Systems an der Aktivität der entsprechen-
den Zeile als Datenquelle oder -senke. Pfeile deuten die Datenflüsse an, die jeweils mit den (abstrakten)
relevanten Datenfeldern annotiert sind. In unmittelbarer Nähe zur Annotation der Datenfelder finden sich in
rautenförmigen Kästen Angaben zu möglichen Datenformaten. Dabei sind nur Datenformate berücksichtigt,
von denen bekannt ist, dass relevante Inhalte in den Spezifikationen genannt sind. Das heißt, generische
Formate, die prinzipiell für den Datenaustausch in jedem beliebigen Schritt geeignet wären (JSON, XML,
CSV...), aber fachlich unbestimmt sind, werden nicht erwähnt. Blaue Pfeile deuten einen „Datenvorhalt“ an,
d. h. diese Daten werden zu einem späteren Zeitpunkt bei der Auswertung nochmals nachgenutzt. Die Pfade
in die Auswertung sind im rechten Bereich des Schaubildes dargestellt.

Schriftenreihe des LfULG, Heft 4/2022 | 72
Zeilen für Aktivitäten, bei denen in der Modellierung Problembereiche sichtbar wurden, sind rot hinterlegt. Im
Einzelnen wurden in der Analyse folgende Punkte identifiziert:
Bei der Stammdatenerfassung für neue Maschinen ist ein Eintrag praktisch gleicher Attribute an meh-
reren Stellen notwendig. Maschinenstammdaten müssen für Planungszwecke in der Ackerschlagkartei,
im Precision Farming und im Flottenmanagement eingetragen werden. Da der Vorgang nicht besonders
häufig durchgeführt wird, ist dies möglicherweise noch akzeptabel, aber hier könnte durch ein automa-
tisches Propagieren der Daten oder zumindest durch die Verwendung eines gemeinsamen Daten-
formats Abhilfe geschaffen werden.
Das Gleiche gilt bei der Beschaffung von Betriebsmitteln: Hier müssen nahezu gleiche Attribute in
Buchhaltung und Warenmanagement eingetragen werden. Diese Aktivität tritt sicher häufiger auf als die
Beschaffung von Investitionsgütern wie Maschinen. Sofern hier in einem Betrieb nicht bereits Schnitt-
stellen vorhanden sind oder beide Teilsysteme in einer Anwendung integriert sind, kann eine Umsetzung
unter Umständen lohnenswert sein.
Bei Bodenprobenahmen müssen die Analyseergebnisse zur Dokumentation des Düngezustandes der
Flächen in die Ackerschlagkartei eingetragen werden sowie in das Precision Farming-System, wenn dieses
basierend auf den Daten Applikationskarten erzeugen soll. In der Praxis sind die beiden Teilsysteme
teilweise bereits sowieso in eine Anwendung integriert. Sofern aber Betriebe zwei Softwaresysteme hierfür
nutzen (z, B. Schlagkartei und eigenes GIS), kann über eine Integration nachgedacht werden.
Bei der Düngebedarfsermittlung können notwendige Datenfelder aus zwei verschiedenen Systemen
kommen (Ackerschlagkartei oder Precision Farming). Es muss also entweder eine Entscheidung er-
folgen oder Teilmengen müssen zusammengeführt werden. Gleiches gilt bei der Ablage der Ergebnis-
daten. Siehe aber auch die Anmerkung im vorigen Spiegelstrich, die auch hier gilt.
Bei der Düngebedarfsermittlung wird in dem Beispiel auf ein externes System (BESyD) zugegriffen.
Dafür sind unter Umständen manuelle Exporte oder Datenübertragungsprozesse erforderlich. Abhilfe
kann geschaffen werden, indem entweder die Funktionalität in eines der lokalen Systeme der Landwirtin
oder des Landwirts integriert wird oder die Datenübertragung vollautomatisiert wird. Das externe System
„fühlt sich dann an“ als ob es in das lokale System integriert wäre. Dafür ist die Schaffung offener, gut
dokumentierter Schnittstellen sowie deren Umsetzung in Programmcode erforderlich.
Beim Betanken des Traktors wird eine Ressource angezapft, die in drei Systemen Relevanz hat – damit
müssen auch die Daten an drei Stellen eingepflegt werden: in der Buchhaltung und im Warenmanage-
ment um die Änderungen im Gesamtbestand des Betriebsmittels beziffern zu können und im Flotten-
management um maschinenbezogene Verbräuche berechnen und ausweisen zu können.
Das Signalisieren von Start- und Endwerten der Prozessdurchführung ist für eine Reihe von Systemen
relevant: in der Arbeitszeiterfassung mit Blick auf das Personalmanagement; in der Ackerschlagkartei, um
mindestens die Zeitpunkte von Maßnahmen in Buchungssätzen zu erfassen; für die Embedded Control
Unit des Traktors, damit der ISO-Task und die Aufzeichnung gestartet wird und für das Flotten-
management, um zu sehen, welche Arbeiten aktuell ausgeführt werden. Dabei variiert der Echtzeitbedarf.
Der Start des ISO-Tasks erfolgt unmittelbar an der Maschine; für Flottenmanagement und Arbeits-
zeiterfassung ist ggfs. ein gewisser Verzug akzeptabel; für die Ackerschlagkartei reicht es in der Regel
aus, wenn die Daten bei der später erfolgenden Dokumentation mitgegeben werden. Diese Schwach-
stelle kann behoben werden, wenn aktuelle Entwicklungen zur Standardisierung der Echtzeitübertragung
von Telemetriedaten z. B. über das EFDI-Protokoll weiter fortgeschritten sind. Dann wäre eine
automatische Weiterleitung entsprechender Nachrichten an alle Systeme technisch einheitlicher
umsetzbar.

Schriftenreihe des LfULG, Heft 4/2022 | 73
Bei der Ablage der Prozessdokumentation sind eine Reihe von Systemen mit Daten zu bedienen: Tat-
sächliche Verbräuche sind in Buchhaltung und Warenmanagement zu erfassen (wobei hier die
automatisierte Prozessdokumentation möglicherweise nicht die richtigen Werte liefert; s. Diskussion
hierzu in Abschnitt 3.2.12.3). Für die Maßnahme ist ein Buchungssatz für den Schlag in die Ackerschlag-
kartei einzufügen. Das Precision-Farming-System benötigt ggfs. teilflächenspezifische Ausbringmengen
als Grundlage für spätere Prozessplanungen, und dem Flottenmanagement müssen die tatsächlichen
Betriebsstoffverbräuche bekannt gemacht werden. Sofern entsprechende Daten gemäß ISO11783
Teil 10 aufgezeichnet wurden, können diese in alle Systeme einfließen, was allerdings die Umsetzung
der Schnittstelle voraussetzt. Außerdem müssen die Dateien den Systemen zugänglich gemacht werden,
was gegebenenfalls mit manuellen Kopierprozessen einhergeht. Die Umsetzung eines automatisierten
Propagierens der Daten zu verschiedenen Systemen oder zumindest einer zentralen Ablage, auf die von
allen Systemen zugegriffen werden kann, kann hier sinnvoll sein.
Bei der Auswertung der Daten treten eine Reihe von Herausforderungen zu Tage: So muss auf zeitlich
teils Jahre zurückliegende Datenerfassungen aus der Buchhaltung zurückgegriffen werden; die be-
zahlten Preise je Einheit müssen für eine Reihe von Produkten ermittelt werden; die richtigen Werte für
Mengen müssen aus der besten verfügbaren Quelle bezogen werden; ggfs. muss ein Zugriff auf externe
Systeme erfolgen, um Ersatzwerte und Faustzahlen für nicht vorliegende Daten zu beschaffen. Diese
Aspekte werden nach Betrachtung des Datenbedarfs durch die Zielgrößen nochmals deutlicher und
werden daher in Abschnitt 5.1.2.12 später noch vertieft diskutiert.
Nach Fertigstellung eines solchen Prozessmodells steht eine Überprüfung auf Übertragbarkeit auf andere
Prozesse an. Wenn sich generelle Grundprinzipien erkennen lassen, kann dies den Aufwand für eine späte-
re Umsetzung reduzieren, indem gemeinsame Routinen für Prozessklassen implementiert werden. Dabei
lässt sich feststellen, dass Beschaffungsprozesse stets ungefähr identisch ablaufen, sodass die im Block
„Ressourcenbeschaffung“ durchgeführten Analysen auf alle weiteren Teilprozesse innerhalb der Produkti-
onsverfahrensübersichten anwendbar sind. Gleiches gilt für den Block „Ressourcen betriebsbereit halten“. In
weiten Teilen lässt sich auch die Ablage der Dokumentation zu Prozessen als ähnlich in allen Prozessen
betrachten, nur dass unterschiedliche Teilsysteme beteiligt sein können Da ökonomische Auswertungen per
se vom eigentlichen Prozess und den konkreten Objekten abstrahieren, lassen sich auch diese Erkenntnisse
übertragen. Es bleibt die Frage, ob dies auch für Prozessplanung, -vorbereitung und -durchführung gilt.
3.1.3 Ableitung von Prozessklassen
Wenn man die Blöcke Prozessplanung, -vorbereitung und -durchführung für den Düngeprozess betrachtet
und mit Fachwissen abgleicht, das zu anderen Feldarbeiten aus den Produktionsverfahren vorliegt, lässt sich
ableiten, dass Ausbringprozesse generell recht ähnlich ablaufen: Auch für die Ausbringung von Pflanzen-
schutzmitteln oder die Aussaat muss im Vorfeld der Bedarf ermittelt werden, ggfs. werden Applikationskarten
erstellt, und auch hier müssen Mengen vorab eingemessen und unter Umständen Restmengen rückgeführt
oder anderweitig verwertet werden. Was sich im Einzelfall unterscheiden kann, sind die beteiligten Systeme –
so würde man für die Planung der Pflanzenschutzmaßnahme nicht BESyD nutzen, sondern ein anderes
Werkzeug, das beispielsweise die Berechnung von Abstandsauflagen beherrscht. Insgesamt lassen sich
Ausbringprozesse also zusammenfassen. Eine solche Zusammenfassung ist auch für andere Teilprozesse
möglich. Insgesamt wurde das in Abbildung 19 dargestellte Schema entwickelt. Dabei wird unterschieden
zwischen Prozessen, die einen Input in ein Produktionsverfahren darstellen, und solchen, die einen Output
aus einem Produktionsverfahren erzeugen. Beim Input kann es sich nur um einen Input in Form von Arbeit

image
Schriftenreihe des LfULG, Heft 4/2022 | 74
z. B. bei Pflege und Bearbeitungsmaßnahmen handeln oder um einen Input mit Ausbringung von Stoffen.
Separat aufgeführt sind Monitoringmaßnahmen. Prozessklassen der Produktionsprozesse hängen zusammen
mit Prozessklassen des Betriebsmanagements, die insbesondere Einkauf und Verkauf umfassen.
Abbildung 19: Prozessklassifizierung
3.1.4 Prozessmodelle für weitere Prozessklassen
In der Folge wurde für jede der noch fehlenden Prozessklassen ein repräsentativer Teilprozess herausge-
griffen und analog zu dem oben beschriebenen Düngeprozessmodell in seinen Datenflüssen skizziert. Die
schematischen Darstellungen finden sich in Anhang 2.4. Im Einzelnen sind dies:
Datenflüsse Output, z. B. Ernte
Datenflüsse Input ohne Ausbringung, z. B. Bodenbearbeitung
Datenflüsse Monitoring, mehrere Beispiele: Bodenproben, Bestandsbonitur, Unkrautbonitur, Milchprobe
Datenflüsse Tierhaltung

Schriftenreihe des LfULG, Heft 4/2022 | 75
In den letzten beiden Fällen kommt das Herdenmanagement als zusätzlich betrachtetes Teilsystem hinzu.
Da zumindest in der Milchviehhaltung Tiere als Individuen betrachtet werden, kann das Tier auch als zusätz-
liches „datengenerierendes/interagierendes System“ betrachtet werden.
Eine kurze vertiefte Betrachtung sind Prozesse wert, an denen als externer Dritter ein Labordienstleister be-
teiligt ist: für solche Prozesse liegt eine digitale Abwicklung nötiger Datenaustauschprozesse eigentlich nahe,
da auch auf Seiten des Labors in den meisten Fällen ein Datenmanagement in einem sogenannten Laborin-
formationsmanagementsystem (LIMS) erfolgt. Für Milchproben sind im ADED tatsächlich auch Nachrichten-
formate definiert. Für Daten zu Bodenproben und -untersuchungsergebnissen bieten einige der Landwirt-
schaftlichen Untersuchungs- und Forschungsanstalten die digitale Bereitstellung an. Innerhalb von For-
schungsprojekten wurde dieser Anwendungsfall auch bereits umgesetzt (z. B. pre agro II, GeoBox). Zu einer
tragfähigen Standardisierung eines einheitlichen Datenmodells ist es bislang jedoch nicht gekommen. Die
Herausforderungen sind dabei vielschichtig, lediglich ein Aspekt soll hier kurz skizziert werden: Eine Standar-
disierung setzt eine gewisse Allgemeinverwendbarkeit voraus. Daten von Proben, die an verschiedenen Or-
ten gesammelt und von verschiedenen Laboren untersucht wurden, sollten eine gewisse Vergleichbarkeit
aufweisen – auch über mehrere Jahre hinweg. Damit dies gegeben ist, reicht es nicht aus, lediglich Datenfel-
der für die Übertragung der relevanten Zahlenwerte zu definieren – gerade bei Labordaten ist es ebenso
wichtig, entweder umfassende Metadaten zu angewendeten Beprobungsstrategien und Analysemethoden
mitzuliefern oder die Methodik festzuschreiben und dauerhaft einheitlich anzuwenden, damit auch später für
vorliegende Daten noch verlässlich bestimmt werden kann, unter welchen Bedingungen die Werte zustande
kamen. Bei den im Labor bestimmten Gehaltswerten mag dies noch gelingen, aber Ergebnisse landwirt-
schaftlicher Bodenuntersuchungen beinhalten typischerweise auch Gehaltsklassen und Düngeempfehlungen,
deren Wertebereiche sich ändern können
96,97
. Die Übertragung lediglich der damit verbundenen Buchstaben-
kodierungen und Kategorien würde zwar dem Landwirt im aktuellen Moment helfen, ist aber nur einge-
schränkt ”standardisierungsfähig”, weil die Vergleichbarkeit ohne Begleitinformationen nicht gegeben wäre.
Die Begleitinformation muss damit also in die Standardisierung mit einbezogen werden, was den Aufwand der
Erarbeitung und die Komplexität eines Standards erhöht.
3.2 Exemplarische Zielgrößen
Zur Führung seines Unternehmens benötigt der Betriebsleiter Kennzahlen und zusammenfassende Aus-
wertungen. Dies sind Größen, die ihm über die Erreichung bestimmter Produktionsziele Auskunft geben
sollen. Informationslücken bestehen hier insbesondere in Bereichen, die Auswertungen auf Basis von in
verschiedenen Softwaresystemen verteilten (Roh-)Daten erfordern. Unter Anderem betrifft dies beispiels-
weise die Ermittlung gesamtbetrieblicher ökonomischer Kennzahlen unabhängig von Bilanzstichtagen. In
einer Vorabanalyse haben am Projekt beteiligte Landwirte die in den folgenden Abschnitten beschriebenen
Kenngrößen genannt, die sie gerne zur operativen und strategischen Steuerung ihres Unternehmens zeitnah
und digital zur Verfügung hätten. Diese Größen werden kurz charakterisiert, ihre Anwendung, Besonder-
heiten und Berechnung beschrieben und abschließend die Datenverfügbarkeit bewertet. Einige dieser Ziel-
größen werden in dem in Abschnitt 3.4.4 skizzierten Dashboard aufgegriffen und dargestellt.
96
https://llg.sachsen-anhalt.de/fileadmin/Bibliothek/Politik_und_Verwaltung/MLU/LLFG/Dokumente/04_themen/pfl_ernaehr_
duengung/veroeffentlichungen/2019-01_Hinweise_P-DBE.pdf
97
https://www.iva.de/sites/default/files/pdfs/wuerzburg_tagung_2016_zorn.pdf

Schriftenreihe des LfULG, Heft 4/2022 | 76
3.2.1 Zusammenhänge
Die durch die Voranalyse vorgegebenen Zielgrößen können teilweise nicht isoliert voneinander betrachtet
werden. Sowohl die Zielgrößen als auch ihre Zusammenhänge sind in Abbildung 20 dargestellt.
Abbildung 20: Zusammenhänge zwischen Zielgrößen
Dabei fällt insbesondere in Bezug auf die Kosten- und Leistungsrechnung ins Auge, dass:
einige Zielgrößen mehr oder weniger vollständig einfließen: Zum Beispiel deckt die Vollkostenrechnung
praktisch vollständig den Kostenaspekt der Kosten- und Leistungsrechnung ab. Damit entsprechen sich
auch Teilmengen des Datenbedarfs: Wenn die Kosten- und Leistungsrechnung vollständig ermittelbar
ist, dann können auch Vollkosten ermittelt werden.
der Datenbedarf überlappend ist: Für die Ermittlung der Arbeitsproduktivität wird der Zeitaufwand für be-
stimmte Tätigkeiten benötigt. Dieser fließt auch in die Vollkostenrechnung ein, muss aber je nach Aus-
wertungsbedarf anders aggregiert/gruppiert werden.
andere Zielgrößen sich aus denselben Daten, die auch für die Kosten- und Leistungsrechnung benötigt
werden durch Umstellung von Berechnungsformeln ermitteln lassen (z. B. die Gewinnschwelle).
Wegen dieser Charakteristika bot es sich an, die Kosten- und Leistungsrechnung für die detailliertere Ana-
lyse als hochkomplexe Zielgröße auszuwählen. Aufgrund der geschilderten Zusammenhänge lässt sich an
diesem Beispiel in der Konzeption des FMIS weiter unten teilweise mitdarstellen, wie auch andere Ziel-
größen abgeleitet und dem Anwender zugänglich gemacht werden könnten. Als Zielgröße mittlerer Kom-
plexität wurde die Liquidität aufgrund der Wichtigkeit im Tagesgeschäft der Landwirtinnen und Landwirte für
die Vermeidung von Risiken und finanziellen Engpässen ausgewählt. Als Zielgröße niedriger Komplexität
soll der Kontostand detaillierter analysiert werden. Anhand dieser Zielgröße kann die Anbindung von Dritt-
systemen mit Schnittstellen mit geringem, vom Anwendungsfall klar umrissenen Datenumfang und dement-
sprechend möglicher klarer Spezifikation illustriert werden.
Kosten-
Leistungs-
Rechnung
Vollkosten
Betriebs-
zweigaus-
wertung
Eigen-
kapitalren-
tabilität
Gewinn-
schwelle
Kosten-
treiber
Arbeits-
produk-
tivität
Maschinen-
parkaus-
wertung
Kontostand
Liquidität
wählt aus
Leistungen
fixe/variable
Kosten
Vergleich
fließt ein
verwandt
(Zeiten)
Zeit
Teil von

Schriftenreihe des LfULG, Heft 4/2022 | 77
Im Folgenden werden die Zielgrößen kurz bezüglich ihres fachlichen Inhaltes, ihrer Herkunft und ihres Nut-
zens skizziert und ihre Ermittlung wird anhand einiger Beispiele illustriert. Die Datenverfügbarkeit und not-
wendige Schnittstellen werden anschließend übergreifend betrachtet. Bei der Analyse stellte sich heraus,
dass eine gemeinsame Abstraktion angewendet werden kann, mit deren Hilfe sich die Menge zu betrach-
tender Datenattribute aus dem in Abschnitt 2.1.2 dargestellten, recht umfassenden landwirtschaftlichen
Datenraum systematisch einschränken lässt. Gleichzeitig lassen sich daran derzeit mit der Datenbeschaf-
fung verbundene Herausforderungen gut darstellen.
3.2.2 Arbeitsproduktivität
3.2.2.1 Zweck und Anwendernutzen
Die Arbeitsproduktivität gibt an, welche Bruttowertschöpfung im Durchschnitt von jedem Erwerbstätigen
erbracht wird. Sie gibt das Verhältnis aus der mengenmäßigen Arbeitsleistung und dem mengenmäßigen
Arbeitseinsatz wieder. Im Gegensatz zur Produktivität ist die Arbeitsproduktivität eine faktorbezogene Teil-
produktivität, bei der die gesamte Ausbringungsmenge nur dem Produktionsfaktor Arbeit gegenübergestellt
wird. Die Arbeitsproduktivität findet vor allem in der Volkswirtschaftlichen Gesamtrechnung Anwendung,
jedoch misst sie als betriebswirtschaftliche Kennzahl auch die Produktivität von Arbeitskräften in einem Un-
ternehmen.
98, 99
3.2.2.2 Interpretation, Ermittlung und Parameter
Die durchschnittliche Arbeitsproduktivität gibt die produzierte Menge pro eingesetzter Einheit des Faktors
Arbeit an. Die Arbeitsproduktivität gilt als bekannteste und meistgenutzte Teilproduktivität. Das liegt insbe-
sondere daran, dass die eingesetzten Mittel relativ leicht zu ermitteln sind.
100
ä =
Der Kehrwert der Arbeitsproduktivität ist der Arbeitskoeffizient. Der Arbeitskoeffizient beschreibt das Verhält-
nis der Einsatzmenge an Arbeitsleistung zu dem damit erzielten Produktionsergebnis. Er gibt somit an, wie
viel Arbeitsleistung benötigt wird, um eine Gütereinheit herzustellen.
101, 102
Während die Arbeitsproduktivität im Durchschnitt aller Wirtschaftsbereiche eine leicht ansteigende Ten-
denz aufweist, unterliegt die Arbeitsproduktivität der Land- und Forstwirtschaft sowie der Fischerei teil-
weise deutlichen Auf- und Abschwüngen. Zu einem großen Teil lässt sich dies auf die starken Schwan-
kungen der Bruttowertschöpfung der Land- und Forstwirtschaft sowie der Fischerei zurückführen. Leichte
Veränderungen der Erwerbstätigen in der Land- und Forstwirtschaft sowie in der Fischerei beeinflussen
die Entwicklung zusätzlich
.103
98
Springer Gabler Verlag (Hrsg.): Gabler Wirtschaftslexikon, Stichwort: Arbeitsproduktivität
99
https://www.landwirtschaft.sachsen.de/arbeitsproduktivitaet-in-der-landwirtschaft-37245.html
100
https://de.wikipedia.org/wiki/Arbeitsproduktivit%C3%A4t
101
Springer Gabler Verlag (Hrsg.), Gabler Wirtschaftslexikon, Stichwort: Arbeitskoeffizient
102
Woll, Artur (2000), Wirtschaftslexikon S. 37.
103
https://www.landwirtschaft.sachsen.de/arbeitsproduktivitaet-in-der-landwirtschaft-37245.html

Schriftenreihe des LfULG, Heft 4/2022 | 78
3.2.3 Betriebszweigauswertung
3.2.3.1 Zweck und Anwendernutzen
Ziel der Betriebszweigabrechnung ist der horizontale Vergleich von Betrieben und der Betriebszweige. Zu
beantwortende Fragen sind dabei zum Beispiel: Wie können die knappen Flächen, das Kapital und die be-
grenzt vorhandene Arbeitszeit sinnvoll eingesetzt werden oder wie groß sind die kurz- und mittelfristigen
Optimierungsreserven im jeweiligen Betriebszweig? Durch Verteilung der Leistungen und Kosten auf die
jeweils in den Betriebszweigen produzierten Waren wird der Stückgewinn berechnet. Es wird ermittelt wie
weit der Betriebszweiggewinn reicht, um die unternehmerischen Investitionen in Form von eigener Arbeit,
Fläche und Kapital zu entlohnen.
104, 105
3.2.3.2 Interpretation, Ermittlung und Parameter
Der Vergleich erfolgt auf der Basis von IST-Daten, die in der Regel aus der Buchführung stammen. Für
die Stärken-Schwächen-Analyse einzelner Bereiche wird eine Aufteilung der Kosten in Kostengruppen
vorgenommen.
106,107
Einbezogen werden dabei folgende Kosten:
=
+
+
+
+
+
.
mit
K
= Vollkosten
K
d
= Direktkosten
K
ae
= Arbeitserledigungskosten
K
flaeche
= Flächenkosten
K
geb
= Gebäudekosten
K
rechte
= Rechtekosten
K
allg
= Allgemeine Kosten
Bei einem Gemischtbetrieb ist die Optimierung in den verschiedenen Betriebszweigen ein Zusammenspiel
aus produktionstechnischem Geschick auf dem Feld und im Stall mit einem gezielten Geldeinsatz. Die ei-
gentliche Herausforderung besteht darin, Tierwohl, Tiergesundheit, Erhalt natürlicher Ressourcen, produk-
tionstechnische Ziele und die ökonomischen Ziele aufeinander abzustimmen.
104
https://www.lfl.bayern.de/iba/unternehmensfuehrung/119637/index.php
105
Schroers, J. O., Sauer, N. (2011): Die Leistungs-Kostenrechnung in der landwirtschaftlichen Betriebsplanung. KTBL-Schrift
486.
106
Schroers, J. O., Sauer, N. (2011): Die Leistungs-Kostenrechnung in der landwirtschaftlichen Betriebsplanung. KTBL-Schrift
486.
107
DLG (2011): Die neue Betriebszweigabrechnung – Arbeiten der DLG Band 197. DLG-Verlag, Frankfurt

Schriftenreihe des LfULG, Heft 4/2022 | 79
Mit einer verbesserten Datenlage lassen sich einzelbetriebliche Ziele leichter setzen und einhalten. Eine
kontinuierliche Durchführung erlaubt Betrachtungen betrieblicher Entwicklungen und deren Evaluierung.
Über den Vergleich mit dem besseren Viertel möglichst ähnlicher Betriebe wird der Stand des Betriebs er-
mittelt und es werden Zielmarken festgelegt. Der Zeitbedarf für diese Unternehmenssteuerung in wachsen-
den und vielfältigen Betrieben ist derzeit jedoch
108109
3.2.4 Eigenkapitalrentabilität
3.2.4.1 Zweck und Anwendernutzen
Die Eigenkapitalrentabilität gibt an, wieviel Prozent Gewinn bezogen auf das Eigenkapital eines Betriebes
innerhalb einer Rechnungsperiode erzielt wurde. Die Eigenkapitalrentabilität stellt somit den Zinssatz dar,
den ein Unternehmer oder Gesellschafter für seine Investition in das Unternehmen erhält. In Verbindung mit
weiteren Kennzahlen kann sie Hinweise auf die zukünftige Unternehmensentwicklung geben.
110
3.2.4.2 Interpretation, Ermittlung und Parameter
Berechnet wird die Eigenkapitalrentabilität indem der Jahresüberschuss nach Steuern ins Verhältnis zu dem
zur Verfügung stehenden Eigenkapital zu Beginn der Periode gesetzt wird:
ä =
Eine außergewöhnlich niedrige Eigenkapitalrentabilität (EKR) weist oft auf zu hoch angesetzte Aktiva oder
auf unrentabel gebundenes Kapital hin, zum Beispiel in hohen Vorratsbeständen oder nicht mehr betriebs-
notwendigem Anlagevermögen. Eine außergewöhnlich hohe EKR kann durch außerordentliche Erträge
verursacht werden. Wie hoch eine “normale” Rendite sein muss, lässt sich jedoch nicht pauschal festlegen.
Wenn die Unternehmensgewinne mit konstanter Rentabilität reinvestiert werden können, lässt die EKR
Rückschlüsse auf das zukünftige Gewinnwachstum zu.
, 111
Ersetzt ein Betrieb Eigen- durch Fremdkapital steigt die Eigenkapitalrentabilität auch bei gleichbleibendem
Gewinn. Durch den höheren Fremdkapitalanteil steigt die Abhängigkeit von den Fremdkapitalgebern und das
Risiko einer Zahlungsunfähigkeit, da das Fremdkapital im Gegensatz zum Eigenkapital zurückgezahlt wer-
den muss
112
. Die Eigenkapitalrentabilität muss daher immer im Kontext mit dem Anteil der Fremdkapital-
finanzierung und auch der Eigenkapitalausstattung gegenüber Vergleichsbetrieben betrachtet werden.
109
https://www.lfl.bayern.de/iba/unternehmensfuehrung/119637/index.php
110
Peter R. Preißler (2008): Betriebswirtschaftliche Kennzahlen – Formeln, Aussagekraft, Sollwerte, Ermittlungsintervalle.
Oldenbourg Verlag München Wien.
111
https://de.m.wikipedia.org/wiki/Rentabilit%C3%A4t#Eigenkapitalrentabilit%C3%A4t
112
Peter R. Preißler (2008): Betriebswirtschaftliche Kennzahlen – Formeln, Aussagekraft, Sollwerte, Ermittlungsintervalle.
Oldenbourg Verlag München Wien.

Schriftenreihe des LfULG, Heft 4/2022 | 80
Rechenbeispiele
Eine Eigenkapitalrentabilität von 10 % besagt, dass ein Unternehmen auf ein eingesetztes Eigenkapital von
1 Mio. € einen Gewinn von 100.000 € erzielt. Würden dagegen 250.000 € mit Fremdkapital und 750.000 €
mit Eigenkapital finanziert bei gleichem Gewinn, würde das zu einer Eigenkapitalrentabilität von 13,3 %
führen. Zu berücksichtigen sind dann zusätzlich noch die Fremdkapitalkosten, also die Kosten, die durch
die Aufnahme des Kredits anfallen.
3.2.5 Gewinnschwelle
3.2.5.1 Zweck und Anwendernutzen
Die Gewinnschwelle ist die Umsatzmenge, bei der gerade eine Vollkostendeckung eintritt. Erlöse und Ge-
samtkosten einer Produktion oder eines Produktes halten sich mithin an diesem Punkt genau die Waage
und es wird weder Verlust noch Gewinn erwirtschaftet. Die Gewinnschwellenanalyse, auch Break-Even-
Analyse genannt, dient der Ermittlung dieses Punktes.
113
3.2.5.2 Interpretation, Ermittlung und Parameter
Wird die Gewinnschwelle überschritten, entstehen Gewinne; wird sie unterschritten, entsprechend Verluste.
Die Gewinnschwelle kann für ein Produkt (Ein-Produkt-Betrachtung) oder für mehrere Produkte (Mehr-
Produkt-Betrachtung) berechnet werden.
Ausgangspunkt der Gewinnschwellenanalyse sind die folgenden Fragestellungen:
Wie viele Produkte müssen produziert und abgesetzt werden, um die Fixkosten zu decken?
(Ein-Produkt-Betrachtung)
Wie viel Umsatz muss durch die betrachteten Produkte erwirtschaftet werden,
um die Fixkosten zu decken? (Mehr-Produkt-Betrachtung)
Die Berechnung erfolgt mittels folgender Formeln:
×
=
+(
×
)
×
=
+(
×
)+
Zur Ermittlung der Gewinnschwelle werden die Formeln nach der Menge aufgelöst. Wenn noch zusätzlich
ein Gewinn erzielt werden soll, kann die Formel wie angegeben erweitert werden. Als Darstellungsweise für
die Gewinnschwelle bietet sich der Break-Even-Chart an: Er stellt den Zusammenhang von Erlös und Kosten
über die Stückmenge grafisch dar. Auf der Abszissenachse ist die Menge aufgetragen, auf der Ordinaten-
achse der Umsatz oder die Kosten, gelegentlich auch der Gewinn
114
.
113
Karl Lechner, Anton Egger, Reinbert Schauer (2008): Einführung in die Allgemeine Betriebswirtschaftslehre, Ausgabe 24,
Wien: Linde Verlag
114
Marcell Schweitzer, Ernst Troßmann (1998): Break-Even-Analyse - Methodik und Einsatz, Ausgabe 2, Berlin: Duncker &
Humblot Verlag

Schriftenreihe des LfULG, Heft 4/2022 | 81
Rechenbeispiel: Die MusterAgrar AG möchte eine neue Produktionslinie aufstellen und dafür wissen, ab
welcher Stückzahl verkaufter Jungpflanzen sie Gewinn erzielt. Für die Produktion fallen 5.000 € Fixkosten
und 1 € variable Kosten an. Der Verkaufserlös pro Produkt liegt bei 3 €. Somit ergibt sich ein Deckungsbei-
trag von 2 €. Für die Gewinnschwelle teilt man die Fixkosten durch den Deckungsbeitrag und erhält einen
Break-Even-Point bei 2.500 Stück.
3.2.6 Kontostand
3.2.6.1 Zweck und Anwendernutzen
Der Kontostand stellt unmittelbar verfügbares Kapital dar, womit er zu den liquiden Mitteln zählt. Diese
werden in zukünftige Planungen mit einbezogen, da sie einen wesentlichen Teil der Liquidität repräsen-
tieren. Sollten nicht ausreichend liquide Mittel vorhanden sein, muss gegebenenfalls Fremdkapital hinzu-
gezogen werden.
115
Wegen der Nähe zur Liquidität wurde der Kontostand in der FMIS-Konzeption in die Ansichten zu dieser
Zielgröße eingebettet.
3.2.6.2 Interpretation, Ermittlung und Parameter
Alle Berechnungen zum Kontostand erfolgen auf Seiten des Kreditinstituts. Die Ermittlung mit Blick auf die
Einbettung in ein FMIS beschränkt sich daher auf eine Abfrage des aktuellen Standes.
3.2.7 Kosten- und Leistungsrechnung
3.2.7.1 Zweck und Anwendernutzen
Die Kosten- und Leistungsrechnung (KLR) ist Teil des innerbetrieblichen Rechnungswesens und unterliegt
somit keinen strengen Vorgaben. Sie dient in erster Linie als Betriebsführungsinstrument und der internen
Informationsbereitstellung. Sie kann sowohl zur Nachkalkulation vergangener Rechnungsperioden als auch
zur Planung von Produktionsverfahren und zur Ermittlung lang- und kurzfristiger Preisuntergrenzen dienen.
Die Kosten- und Leistungsrechnungen, die für ausgewählte Produktionsverfahren der pflanzlichen und tieri-
schen Produktion ausgeführt werden, dienen der Produktionsplanung im internen Rechnungswesen. Dabei
werden die Kosten nach Art, Stelle und Träger zugeordnet. Somit kann eine produktspezifische Kostenauf-
stellung erfolgen. Voraussetzung ist eine korrekte Kosten- und Leistungserfassung.
116, 117, 118
115
Krumm, M.: Liquidität im landwirtschaftlichen Betrieb. LEL Schwäbisch Gmünd. Landesanstalt für Entwicklung der
Landwirtschaft und der ländlichen Räume Schwäbisch Gmünd.
116
Schroers, J. O., Sauer, N. (2011): Die Leistungs-Kostenrechnung in der landwirtschaftlichen Betriebsplanung. KTBL-Schrift
486.
117
https://de.wikipedia.org/wiki/Kosten-_und_Leistungsrechnung
118
https://daten.ktbl.de/downloads/dslkr/Leistungs-Kostenrechnung.pdf

Schriftenreihe des LfULG, Heft 4/2022 | 82
3.2.7.1.1
Interpretation, Ermittlung und Parameter
Es wird zwischen verschiedenen Systemen der Kostenrechnung und ihren Ausprägungen, die sich inhaltlich
oft überschneiden, unterschieden. Für kurz- bis mittelfristige Entscheidungen bietet sich die Teilkostenrech-
nung an, bei der die Gemeinkosten nicht berücksichtigt werden und nur die Einzelkosten dem Verkaufspreis
gegenübergestellt werden. Für mittel- bis langfristige Entscheidungen wird die Vollkostenrechnung ange-
wendet. Zum Begriff der Vollkosten und der Aufschlüsselung der Kostenpositionen finden sich weitere
Erläuterungen in Abschnitt 3.2.11.
Im Folgenden sind einige Teilaspekte und übliche Vorgehensweisen der Kosten-Leistungs-Rechnung skizziert
119
:
Produkte, Betriebsmittel und Betriebsstoffe
Alle Preise werden ohne Mehrwertsteuer ausgewiesen.
Selbsterzeugte Betriebsmittel (Futtermittel, Einstreu usw.) können mit Marktpreisen bewertet werden.
Preise für Grobfuttermittel können, wenn keine Marktpreise verfügbar sind, auf Basis des Marktpreises
für Heu bestimmt werden.
Wirtschaftsdünger werden mit einem Preis von 0 € bewertet.
Maschinen
Bei der Maschinen- und Anlagenkostenkalkulation ist die Auslastung mit zu beachten. Vereinfachend
kann von einer Auslastung von 100 % ausgegangen werden. Dies entspricht einem jährlichen Einsatz-
umfang an der Auslastungsschwelle.
Für die Maschinen und technischen Anlagen muss während der Einsatzdauer mit einem Restwert kal-
kuliert werden, solange der Abverkauf nach Ende der Nutzung noch nicht erfolgt ist. Eine angemessene
Faustzahl liegt bei der unterstellten Nutzung bei 20 % des Anschaffungspreises.
Die Betriebsstoffkosten enthalten die Kosten für den Antrieb einer Maschine (Diesel, Benzin, Strom).
Kosten für Schmiermittel sind Bestandteil der Reparaturkosten.
In die fixen Maschinenkosten sollten Kosten für die Unterbringung der Maschine in Form von Gebäude-
kosten nach Maßgabe der erforderlichen Abstellfläche eingerechnet werden.
Gebäude
Für Gebäude wird in der Regel der Investitionsbedarf eines neuen, von einem Bauunternehmen erstell-
ten Gebäudes zugrunde gelegt. Melkanlagen, Fütterungs- und Entmistungsanlagen sowie Wirtschafts-
düngerläger sind miteinzurechnen.
Die jährlichen Gebäudekosten beinhalten Abschreibung, Zins-, Unterhaltungs- und Versicherungs-
kosten. Für verschiedene Gebäudeteile können Nutzungsdauern von 30, 15 bzw. 10 Jahren angesetzt
werden. Die Unterhaltung wird entsprechend mit 1 %, 2 % bzw. 3 % des Investitionsbedarfs kalkuliert.
Arbeitserledigung
Die Häufigkeit der Durchführung eines Arbeitsvorgangs muss mitberücksichtigt werden. Arbeiten, die nur
im Abstand von zwei oder drei Jahren durchgeführt werden (z. B. Bodenprobenahmen, bestimmte
Bodenbearbeitungsfeldarbeiten) müssen anteilig umgelegt werden.
Der Arbeitszeitbedarf für Betriebsführungsarbeiten kann je nach Auswertungszielen und -ebene
mitberücksichtigt werden.
119
https://daten.ktbl.de/downloads/dslkr/Leistungs-Kostenrechnung.pdf

Schriftenreihe des LfULG, Heft 4/2022 | 83
Kosten- und Leistungsrechnungen
Je nach Auswertungszielen müssen in die Berechnungen Prämien, wie z. B. Beihilfen für Ökolandbau,
Agrarumwelt- und Klimamaßnahmen (AUKM) sowie besonders tiergerechte Haltungsverfahren einbe-
zogen werden.
Die in der Kosten- und Leistungsrechnung ausgewiesenen Erträge sind Nettoerträge. Von den geern-
teten Bruttoerträgen werden die Masseverluste, die bei Körnerfrüchten durch Trocknung und bei Futter-
pflanzen durch Silierung oder Heugewinnung entstehen, abgezogen.
Kostenkalkulation von Produktionsverfahren
Die Kosten der Produktionsverfahren sind in Kostengruppen gegliedert: Direktkosten, Arbeitserledigungskos-
ten, Gebäudekosten, Flächenkosten, Rechtekosten und Allgemeine Kosten. Auf der Planungsebene Produk-
tionsverfahren werden die Kostengruppen in Einzel- und Gemeinkosten sowie in variable und fixe Kosten
unterteilt. Die Aufteilung ist in Abbildung 22 dargestellt und dient der Systematisierung der Kosten und der
Ableitung der ökonomischen Erfolgsgrößen.
Direktkosten: Direktkosten ergeben sich aus dem Verbrauch von materiellen und immateriellen Betriebs-
mitteln. Für die im Produktionsverfahren eingesetzten Betriebsmittel werden für die Dauer der Kapital-
bindung Zinskosten berechnet. Auf Produktionsverfahrensebene zählen die Direktkosten zu den vari-
ablen Einzelkosten.
Arbeitserledigungskosten: Die Arbeitserledigungskosten umfassen sämtliche Kosten, die im Zusammen-
hang mit der Durchführung von Arbeitsverfahren anfallen. Zu den variablen Arbeitserledigungskosten
zählen die Kosten für Aushilfskräfte, Teilzeitkräfte, Saisonarbeiter, Dienstleistungen und die variablen
Kosten der Arbeitsmittel. Zu den fixen Arbeitserledigungskosten zählen die fixen Kosten der Arbeitsmittel
und die Lohnkosten für ständig beschäftigte Mitarbeitende.
Gebäudekosten: Kosten für Maschinenhallen oder ähnliche Gebäude, die einem Produktionsverfahren
nicht eindeutig zuzuordnen sind, sind Gemeinkosten und werden zu den Allgemeinen Kosten und nicht
zu den Gebäudekosten eines Produktionsverfahrens gezählt. Gebäude, die speziell für ein Produktions-
verfahren genutzt werden, zählen zu den Gebäudekosten eines Produktionsverfahrens.
Flächenkosten: In der Pflanzenproduktion können die Flächenkosten unmittelbar zugeordnet werden.
Sie zählen damit zu den Einzelkosten. Gleichzeitig sind es auch fixe Kosten, da im Gartenbau und in der
Landwirtschaft meist langfristige Pachtverträge abgeschlossen werden. Die Höhe des Pachtsatzes
hängt jedoch weniger vom Produktionsverfahren als vom regionalen Pachtmarkt und weiteren verfah-
rensunspezifischen Bedingungen ab.
Rechtekosten: Rechtekosten entstehen für Liefer- und Produktionsrechte. Lieferrechte gibt es im Zucker-
rübenanbau und der Milcherzeugung. Ein Beispiel für Produktionsrechte sind Brennrechte für Alkohol.
Rechtekosten entstehen, wenn Rechte nachgefragt und handelbar sind, wenn sich also ein Marktpreis
gebildet hat. Die Kosten entsprechen Opportunitätskosten für Verpachtung, wenn die Rechte im Eigentum
des Produzenten sind und der zu zahlenden Pacht, wenn die Rechte gepachtet sind. Da die Rechte in der
Regel langfristig verpachtet werden und die Kosten daher unabhängig von der konkreten Durchführung
eines bestimmten Produktionsverfahrens anfallen, zählen sie zu den fixen Einzelkosten.
Allgemeine Kosten: Zu dieser Kostengruppe werden alle Direkt-, Arbeitserledigungs-, Gebäude- und
Flächenkosten gezählt, die auf Betriebsebene für die Organisation und Verwaltung der Produktion
entstehen, aber einem einzelnen Produktionsverfahren nicht eindeutig zuzuordnen sind. Sie zählen daher
zu den Gemeinkosten.

Schriftenreihe des LfULG, Heft 4/2022 | 84
Kalkulation der ökonomischen Erfolgsgrößen von Produktionsverfahren
Ökonomische Erfolgsgrößen von Produktionsverfahren werden berechnet, indem von der monetären Leis-
tung eines Produktionsverfahrens Teilkosten subtrahiert werden. Der Betrag, der jeweils aus der Differenz
zwischen Leistung und Teilkosten resultiert, dient der Deckung der restlichen Kosten. In Abbildung 21 wer-
den der stufige Aufbau der Kosten- und Leistungsrechnung und die einzelnen ökonomischen Erfolgsgrößen
hinsichtlich ihres Einsatzes und ihrer Aussagekraft erläutert.
Leistung: Die Leistung landwirtschaftlicher Produktionsverfahren ist der monetär bewertete Ertrag der
Haupt- und Nebenprodukte eines Produktionsverfahrens. Die monetäre Bewertung von marktgängigen
Produkten erfolgt über den Marktpreis.
Direktkostenfreie Leistung: Die Direktkostenfreie Leistung entspricht den Leistungen abzüglich aller Direkt-
kosten einschließlich der Zinskosten für das in den Betriebsmitteln gebundene Kapital. Sie dient der
Deckung aller Kostengruppen außer den Direktkosten. Die Direktkostenfreie Leistung ist unabhängig von
der Art der Arbeitserledigung des Produktionsverfahrens, also unabhängig von der technischen Aus-
stattung und weiteren Einflüssen auf die Arbeitserledigungskosten. Die Kennzahl kann in arbeitswirtschaft-
lich ähnlichen Verfahren zur Kalkulation der Wettbewerbsfähigkeit unterschiedlicher Sorten und Qualitäten
herangezogen werden, zum Beispiel verschiedener Arten von Alleebäumen. Weiterhin können einzelne In-
tensitätsstrategien (Dünge-, Pflanzenschutzintensität) hinsichtlich der Leistungs-Kostendifferenz unter-
sucht werden.
Deckungsbeitrag: Der Deckungsbeitrag entspricht der Leistung eines Produktionsverfahrens abzüglich der
variablen Kosten. Die variablen Kosten setzen sich aus den Direktkosten und den variablen Arbeits-
erledigungskosten zusammen und decken die fixen Einzel- und die Gemeinkosten. Der Deckungsbeitrag
ist neben dem Marktpreis und der biologischen Produktivität der eingesetzten Pflanzen (Direktkosten) von
der Technik und dem Standort/Arbeitsort abhängig. Da die anteiligen fixen Kosten nicht berücksichtigt
werden, ist der Deckungsbeitrag unabhängig von der Auslastung der eingesetzten Arbeitsmittel und den
Gemeinkosten des Betriebs. Der Deckungsbeitrag ist ein Maßstab für die relative Vorzüglichkeit von
Produktionsverfahren bei konstanter Kapazitätsausstattung. Die fixen Kosten werden auf Betriebsebene
als „Kostenblock“ behandelt, der durch den Gesamtdeckungsbeitrag gedeckt wird. Der Gesamtdeckungs-
beitrag ist die Summe der Einzeldeckungsbeiträge der Produktionsverfahren.

image
Schriftenreihe des LfULG, Heft 4/2022 | 85
Abbildung 21: Ökonomische Erfolgsgrößen der Kostenleistungsrechnung
120
Direkt- und arbeitserledigungskostenfreie Leistung
Die direkt- und arbeitserledigungskostenfreie Leistung wird berechnet, indem von der Marktleistung die
Direktkosten und die fixen und variablen Arbeitserledigungskosten abgezogen werden. Sie trägt zur De-
ckung der verbleibenden fixen Kosten (Gebäude-, Flächen-, Rechte-, Allgemeine Kosten/Unternehmens-
führung) bei. Da in dieser Kennzahl im Gegensatz zum Deckungsbeitrag auch die fixen Arbeitserledi-
gungskosten (= fixe Kosten der Arbeitsmittel und fixe Lohnkosten) berücksichtigt sind, spiegeln sich in ihr
die Effekte der Auslastung der Arbeitsmittel wider.
Die direkt- und arbeitserledigungskostenfreie Leistung drückt durch die Einbeziehung der fixen Arbeits-
erledigungskosten die Wirtschaftlichkeit von Produktionsverfahren aus – unabhängig von den Eigentums-
verhältnissen der Arbeitsmittel (Eigen- oder Fremdmechanisierung) und der Arbeitsverfassung (ständig
Beschäftigte oder Saisonarbeitskräfte).
120
https://daten.ktbl.de/downloads/dslkr/Leistungs-Kostenrechnung.pdf, S. 4

Schriftenreihe des LfULG, Heft 4/2022 | 86
Die einzelkostenfreie Leistung ergibt sich aus den Leistungen abzüglich aller direkt einem Verfahren zuzu-
ordnenden variablen und fixen Einzelkosten. Dazu zählen neben den Direktkosten und den Kosten der Ar-
beitserledigung auch die Flächen-, Rechte- und Spezialgebäudekosten. Mit der einzelkostenfreien Leistung
sind nur noch die Gemeinkosten zu decken. Kosten von Maschinenhallen werden nicht verfahrensbezogen
ausgewiesen, sondern zu den Allgemeinen Kosten gezählt. Die Einzelkostenfreie Leistung ist der Maßstab
der Wirtschaftlichkeit von Produktionsverfahren unter Berücksichtigung aller direkt zuteilbaren Einzelkosten.
Der kalkulatorische Gewinnbeitrag berechnet sich, indem von der einzelkostenfreien Leistung zusätzlich die
anteiligen Gemeinkosten abgezogen werden. Die Gemeinkosten werden über Schlüssel (z. B. anteiliger
Umsatz eines Produktionsverfahrens am Gesamtumsatz des Betriebs) auf die Produktionsverfahren um-
gelegt. In der Planungsrechnung auf Produktionsverfahrensebene ist dies die Kostengruppe Allgemeine
Kosten. Der Kalkulatorische Gewinnbeitrag ist der Beitrag eines Produktionsverfahrens zur Entlohnung der
unternehmerischen Tätigkeit. In den Planungsbeispielen für Produktionsverfahren werden Gemeinkosten
nicht berücksichtigt. Daher wird auch der kalkulatorische Gewinnbeitrag nicht ausgewiesen.
Kalkulationsmethode für mehrjährige Kulturen
Um Kulturen mit unterschiedlicher Produktionsdauer vergleichen zu können, reicht es nicht aus, die Erfolgs-
größen einzelner Jahre heranzuziehen. Auch eine Betrachtung der gesamten Produktionsdauer führt beim
Vergleich von Verfahren mit unterschiedlich langen Produktionsdauern nicht zu Kennzahlen, die eine Aus-
sage über die ökonomische Vorteilhaftigkeit zulassen. Die Erfolgsgrößen (Deckungsbeitrag usw.) und die
Kosten müssen beim Vergleich von Produktionsverfahren mit unterschiedlicher Produktionsdauer nicht nur
mit Flächenbezug (€/ha), sondern zusätzlich mit einheitlichem Zeitbezug (€/ha . a) unter Berücksichtigung
von Zinseffekten ausgewiesen werden. Zu diesem Zweck werden die Kennzahlen mit der Annuitätenmethode
berechnet. Die Annuitäten entsprechen den Barwerten für Leistungen, Kosten und Erfolgsgrößen, die als
regelmäßige Zahlungsreihe auf die Jahre des gesamten Produktionszeitraums verteilt werden. Produktions-
verfahren mit unterschiedlicher Produktionsdauer können nur anhand der ausgewiesenen Annuitäten hin-
sichtlich ihrer Wirtschaftlichkeit sachgerecht verglichen und bewertet werden.
3.2.8 Kostentreiber
3.2.8.1 Zweck und Anwendernutzen
Ein Kostentreiber ist eine Bezugsgröße oder ein Kostenfaktor, der die Endprodukten zugewiesenen Kosten
beeinflusst. Im Idealfall verhalten sich Änderungen im Einsatz eines kostentreibenden Faktors proportional
zu den Kosten des Endprodukts. Große Kostentreiber sind hingegen Faktoren und Bezugsgrößen, deren
Kosten überproportional zu den Endprodukten zugewiesenen Kosten steigen. Ein Überblick über wesent-
liche Kostentreiber zeigt auf, wo neue Strategien und Planungen nötig sind.
3.2.8.2 Interpretation, Ermittlung und Parameter
Zu den größten Kostentreibern zählen derzeit Energie, Treibstoffe, Strom, Futtermittel aber auch Bauten und
Maschinen. Diese haben sich auch über das Frühjahr 2021 weiter verteuert. Zu den Energiepreisen zählen
unter anderem auch die Kosten für Heizöl sowie die stark ansteigenden Preise für Treibstoff und Strom. In Tei-
len sind auch die Kosten für andere Betriebsstoffe wie Mineraldünger abhängig von den Energiekosten. Ver-
teuert haben sich ferner die Einkaufpreise für Pflanzenschutzmittel, sowie für Saat- und Pflanzgut. Der damit
verbundene steigende Preis pflanzlicher Produkte treibt auch den Preis für Futtermittel nach oben. Kostentrei-
ber können auch Kosten für Rechte und Auflagen sein. Höhere Standards, anspruchsvollerer Umweltschutz
und besseres Tierwohl können neue Investitionen erfordern, bei teilweise gemindertem Ertrag. Von Oktober

Schriftenreihe des LfULG, Heft 4/2022 | 87
2020 bis Januar 2021 verteuerten sich vor allem die Preise für Treibstoffe (+15,9 %), Getreide und Mühlen-
nachprodukte (+13,5 %), Ölkuchen und -schrot (+11,2 %), Heizstoffe (+9,5 %), Mischfuttermittel für Schweine
(+8,8 %) sowie Mischfuttermittel für Geflügel (+7,9 %). Preissenkungen konnten demgegenüber nur bei Dün-
gemitteln (-0,2 %) beobachtet werden. Die Kosten für landwirtschaftliche Bauten sind von 2015 bis 2021 um
mehr als 20 Prozent gestiegen. Die EU-Standards und Auflagen sind für die deutsche Landwirtschaft mit Kos-
ten und entgangenem Ertrag von rund 5,3 Milliarden € oder 315 € je Hektar verbunden. Ein Vergleich der ei-
genen Kostentreiber mit solchen statistischen Daten erlaubt, die eigene Situation einzuschätzen und gegebe-
nenfalls gezielte Maßnahmen zur Kostensenkung in Teilbereichen einzuleiten.
121122123124
3.2.9 Liquidität
3.2.9.1 Zweck und Anwendernutzen
Die Liquidität bezeichnet die Fähigkeit von natürlichen oder juristischen Personen als Schuldner, fällige Zah-
lungsverpflichtungen termingerecht und vollständig erfüllen zu können. Liquidität bezieht sich auch auf die
Verfügbarkeit über genügend Zahlungsmittel. Sie wird genutzt für zukünftige Planung, da sie einen Auf-
schluss darüber gibt, wieviel liquide Mittel in der Planungsperiode verfügbar sind.
125, 126
Die Liquidität ist das Ergebnis der Liquiditätsrechnung (Kapitalfluss-Rechnung). Sie ist ein wichtiges Werk-
zeug zur Planung der verfügbaren finanziellen Mittel und bietet einen Einblick, ob eine geplante Investition
nur durch Eigenkapital finanziert werden kann oder ob Fremdkapital benötigt wird.
127
3.2.9.2 Interpretation, Ermittlung und Parameter
Zur Aufrechterhaltung der Liquidität können Wirtschaftsobjekte wie Vermögensgegenstände (etwa Kassen-
bestand, Bankguthaben, Forderungen, Anlagevermögen) oder unausgenutzte Kreditzusagen verwendet
werden. Wirtschaftsobjekte sind liquide, wenn sie auf einem aktiven Markt jederzeit veräußert werden
können. Liquidität ist deshalb eine Eigenschaft von Vermögensgegenständen und kennzeichnet deren
Geldnähe, also die Möglichkeit, sie direkt oder nach Umwandlung als Zahlungsmittel zu verwenden.
128
Ausgehend von der aktuellen Liquidität (Summe der liquiden Mittel) werden bei der Liquiditätsplanung die
erwarteten zukünftigen Einnahmen und Ausgaben des landwirtschaftlichen Betriebs und des Unternehmer-
haushalts systematisch erfasst und einander gegenübergestellt. Dabei bietet es sich an, eine optimistische
und eine pessimistische Planungsvariante zu erstellen. Innerhalb dieses Korridors wird die Entwicklung der
121
https://www.agrarheute.com/management/betriebsfuehrung/agrarkosten-rekordhoch-betriebsmittel-teuer-noch-nie-579182
122
https://www.agrarheute.com/management/betriebsfuehrung/landwirtschaft-kosten-gehen-decke-550400
123
https://www.bauernverband.de/themendossiers/eu-agrarfoerderung/themendossier/studie-kosten-landwirtschaft
124
https://www.destatis.de/DE/Themen/Wirtschaft/Preise/Landwirtschaftspreisindex-Forstwirtschaftspreisindex/einkaufspreise-
landwirtschaftlicher-betriebsmittel.html
125
Günther Gebhardt, Helmut Mansch (2018): Management und Abbildung von Liquidität und Liquiditätsrisiken. ZfbF-
Sonderheft Band 73/18. Springer Gabler Verlag.
126
Krumm, M.: Liquidität im landwirtschaftlichen Betrieb. LEL Schwäbisch Gmünd. Landesanstalt für Entwicklung der
Landwirtschaft und der ländlichen Räume Schwäbisch Gmünd.
127
Erwin von Beckerath u. a. (Hg.), Handwörterbuch der Sozialwissenschaften, Band 5, 1959, S. 622
128
Erwin von Beckerath u. a. (Hrsg.), Handwörterbuch der Sozialwissenschaften, Band 5, 1959, S. 622

Schriftenreihe des LfULG, Heft 4/2022 | 88
Liquidität im Normalfall verlaufen. Üblicherweise wird für ein Jahr vorgeplant, wobei dieses in einzelne Pla-
nungsintervalle zerlegt wird. In der Praxis haben sich je nach Fragestellung ein- bis dreimonatige Planungs-
intervalle bewährt. Zu einer ersten Orientierung der Ausgaben in den einzelnen Betriebsbereichen kann der
letzte Jahresabschluss herangezogen werden. Bei der Planung ist darauf zu achten, dass die Mengen und
Preise an die neue bzw. erwartete Situation angepasst werden müssen. Die Veränderungen mit den größ-
ten Auswirkungen für den Betrieb sind i.d.R. die Verkaufspreise wie z. B. Milchpreis oder Ferkelpreis sowie
die Betriebsmittelpreise wie z. B. Futtermittel, Düngemittel, Pflanzenschutzmittel. Die meisten anderen Posi-
tionen sind i.d.R. innerhalb der einzelnen Jahre relativ konstant.
129
Es wird unterschieden nach zunehmender Fristigkeit zwischen Liquidität ersten, zweiten und dritten Grades,
auch bezeichnet als Cash Ratio (Barliquidität), Acid Test Ratio (auch Quick Ratio) und Current Ratio. In Ver-
bindung mit Tabelle 1 illustrieren die im Folgenden gegebenen Erläuterungen und Formeln die Berechnung.
Die Liquidität 1. Grades (Cash Ratio) berechnet sich als Quotient der liquiden Mittel zu den kurzfristigen
Verbindlichkeiten., sie gibt an, inwieweit ein Unternehmen seine derzeitigen kurzfristigen Zahlungsverpflich-
tungen allein durch seine liquiden Mittel erfüllen kann. Die Forderungen werden dabei nicht berücksichtigt.
Die Liquidität 1. Grades sollte größer oder gleich 0,2 sein.
ä
1=
895.000
2.200.000 + 575.000
= 0,323
Für die Berechnung der Liquidität 2. Grades (Acid Test Ratio (ATR) oder auch Quick Ratio) werden den
Barmitteln kurzfristige Forderungen und der gesamte kurzfristig in Barmittel umwandelbare Teil des Umlauf-
vermögens hinzugefügt. Dazu gehören Wertpapiere und Aktien soweit vorhanden. Kurzfristige Forderungen
sind in der Regel nicht sofort liquidierbar
130
. Bei einem Wert kleiner 1 wird ein Teil der kurzfristigen Verbind-
lichkeiten nicht durch kurzfristig zur Verfügung stehendes Vermögen gedeckt, wodurch ein Liquiditätseng-
pass entstehen kann. Die Liquidität 2. Grades sollte deshalb größer oder gleich 1 sein.
ä
2=
895.000 + 2.300.000
2.200.000 + 575.000
= 1,151
Die Liquidität 3. Grades (Current Ratio) beinhaltet zusätzlich zu den Barmitteln das Umlaufvermögen inklu-
sive Bestände und Vorräte. Ist diese kleiner als 1, wird ein Teil der kurzfristigen Verbindlichkeiten nicht durch
das Umlaufvermögen gedeckt, das heißt, es muss unter Umständen Anlagevermögen zur Deckung der
Verbindlichkeiten verkauft werden. Daher sollte diese Liquiditätskennziffer immer größer als 1, besser 1,5
sein. Nach der sogenannten „Banker’s rule“ wird sogar ein Wert von 2 gefordert.
ä
3=
895.000 + 2.300.000 + 2.430.000
2.200.000 + 575.000
= 2,027
129
Krumm, M.: Liquidität im landwirtschaftlichen Betrieb. LEL Schwäbisch Gmünd. Landesanstalt für Entwicklung der
Landwirtschaft und der ländlichen Räume Schwäbisch Gmünd.
130
Peter R. Preißler (2008): Betriebswirtschaftliche Kennzahlen – Formeln, Aussagekraft, Sollwerte, Ermittlungsintervalle.
Oldenbourg Verlag München Wien.

Schriftenreihe des LfULG, Heft 4/2022 | 89
Rechenbeispiele s. Tabelle 1:
Tabelle 1: Rechenbeispiele Liquidität
Aktiva
Betrag in €
Passiva
Betrag in €
Anlagevermögen
(Maschinen, Gebäude)
8.500.000
Eigenkapital
(Bankguthaben)
7.400.000
Umlaufvermögen
-
Fremdkapital
-
Vorräte (Diesel, Futter,
Dünger etc.)
2.430.000
Rückstellungen
1.250.000
Forderungen aus
Lieferungen und
Leistungen (Forderungen
für Milch, Weizen etc.)
2.300.000
Verbindlichkeiten aus
Lieferungen und Leis-
tungen (Rechnungen
für Diesel, Futter,
Dünger etc.)
2.200.000
Liquide Mittel
895.000
Bankdarlehen
(< 1 Jahr)
575.000
Bankdarlehen
(> 1 Jahr)
2.700.000
14.125.000
14.125.000
Neben den oben genannten Liquiditäten 1., 2. und 3. Grades wird auch der Cashflow als Kenngröße für eine
Beurteilung der Liquidität auf Basis des Mittelzu- und -abflusses herangezogen. Als Cashflow bezeichnet
man eine betriebswirtschaftliche Kennzahl, bei der Einzahlungen und Auszahlungen innerhalb eines be-
stimmten Zeitraums saldiert werden. Für den Cashflow existiert aber keine einheitliche Definition und Be-
rechnung
131
. Es gibt vielmehr mehrere Möglichkeiten ihn zu berechnen, beispielsweise auf Basis der Bilanz,
der Kosten-Leistungs-Rechnung oder der Zahlungsströme.
3.2.10 Maschinenparkauswertung
3.2.10.1 Zweck und Anwendernutzen
Die Maschinenparkauswertung hilft, die Leistungsfähigkeit und den Zustand der in der Produktion verwendeten
Maschinen zu beobachten und zu beurteilen. Im landwirtschaftlichen Kontext bezieht sie sich meist auf die
mobilen Arbeitsmaschinen der Außenwirtschaft, aber grundsätzlich kann auch die sonstige Maschinen- und
Anlagenausstattung einbezogen werden. Im Kontext eines betrieblichen FMIS sind insbesondere auch die
Kosten je Betriebsstunde von Interesse. Die Maschinenparkauswertung erlaubt dem Anwender damit außer
der Überwachung des technischen Zustandes beispielsweise auch einzuschätzen, ob die Arbeitserledigung
durch einen Dienstleister günstiger wäre und ermöglicht es, bei einer Neuanschaffung gezielter auszuwählen
und Über- oder Untermechanisierungen zu vermeiden.
131
Peter R. Preißler (2008): Betriebswirtschaftliche Kennzahlen - Formeln, Aussagekraft, Sollwerte, Ermittlungsintervalle.
Oldenbourg Verlag München Wien.

Schriftenreihe des LfULG, Heft 4/2022 | 90
3.2.10.2 Interpretation, Ermittlung und Parameter
In eine Maschinenparkauswertung können heutzutage eine Reihe von Sensorwerten mit einbezogen werden
wie zum Beispiel Verbräuche und Durchsätze. Auch wartungsrelevante Parameter wie beispielsweise bei
Häckslern Betriebsstunden seit dem letzten Messerwechsel/-schleifen können teilweise erfasst werden und
dabei helfen, Wartungsintervalle zu kontrollieren. Über die gewonnenen Daten können teils auch Möglichkei-
ten der Optimierungen an Maschineneinstellungen ermittelt werden. Eine effiziente und einfache Auswertung
aller grundsätzlich erhobener Prozessdaten über verschiedene Maschinen und Hersteller hinweg ist aktuell
oft nur eingeschränkt möglich. Über eine Aufarbeitung der Daten können auch Schäden und somit Kosten-
faktoren Produktionsprozessen zugeordnet werden.
Die Erfassung relevanter Größen (Betriebsstunden, ggfs. auch verschiedene Betriebszustände) sind im
ISOBUS möglich; s. a. beiliegende Aufbereitung des aktuellen Data Dictionary. Eine praktische Schwie-
rigkeit ist gemäß Gesprächen mit Systemherstellern die Zuordnung zu Teilprozessen (Straßenfahrt, Feld)
und damit auch zu Produktionsprozessen und Kostenstellen. Für eine Ermittlung der Betriebskosten
reicht es außerdem nicht aus, lediglich die Maschine selbst Daten zu Einsatzzeiten und Betriebsmittel-
verbräuchen aufzeichnen zu lassen. Abschreibungen, Versicherungen sowie Wartungs- und Reparatur-
kosten sind in die Betrachtung mit einzubeziehen. Auch eine stehende Maschine verursacht Kosten.
Maschinen, die nicht ausgelastet sind, weisen relativ betrachtet höhere Kosten je Betriebsstunde auf.
3.2.11 Vollkosten (je Produkteinheit/je Schlag)
3.2.11.1 Zweck und Anwendernutzen
In die Vollkostenrechnung werden sämtliche Kosten mit einbezogen und auf die einzelne Kostenträger
aufgeteilt. So lässt sich die Rentabilität von Produkten oder einzelner Produktionszweige ermitteln und
potenzielle Querfinanzierungen können aufgedeckt werden. Vollkosten schließen alle in einem Unter-
nehmen entstandenen Kosten ein, gleichgültig, wie eng sie mit der Produktion und dem Betriebszweck
verbunden sind.
132, 133, 134
3.2.11.2 Interpretation, Ermittlung und Parameter
Vollkosten lassen sich in Einzelkosten und Gemeinkosten aufgliedern. Einzelkosten können einem Kosten-
träger direkt zugeordnet werden, während die Gemeinkosten nur indirekt über Verteilungsschlüssel umge-
legt werden können.
Der Begriff Einzelkosten wird in der Literatur häufig synonym zu Spezialkosten benutzt. Einzelkosten können
einem Bezugsobjekt (Produkt, Arbeitsmittel, Arbeitsverfahren, Produktionsverfahren, Betriebszweig, Betrieb)
eindeutig zugeordnet werden. Das Kriterium ist allerdings weder trennscharf noch eindeutig, da verschie-
dene Methoden der Kostenzuordnung angewendet werden können (Verursacherprinzip, Beanspruchungs-
prinzip, Durchschnittsprinzip).
132
https://de.wikipedia.org/wiki/Vollkosten
133
Schroers, J. O., Sauer, N. (2011): Die Leistungs-Kostenrechnung in der landwirtschaftlichen Betriebsplanung.
KTBL-Schrift 486.
134
https://de.wikipedia.org/wiki/Vollkostenrechnung

Schriftenreihe des LfULG, Heft 4/2022 | 91
Kosten, die nach dem Beanspruchungsprinzip zuteilbar sind, zählen zu den Einzelkosten. In der Kostenkal-
kulation von Arbeits- und Produktionsverfahren werden die fixen Kosten der darin eingesetzten Gebrauchs-
güter (Arbeitsmittel, Gebäude, bauliche Anlagen) nach dem Beanspruchungsprinzip zugeteilt. Diese Kosten
werden deshalb als fixe Einzelkosten der Arbeits- und Produktionsverfahren ausgewiesen.
Fixe Kosten, auf die das Beanspruchungsprinzip nicht anwendbar ist (z. B. Kosten des Bürogebäudes),
werden zu den allgemeinen Kosten und damit zu den Gemeinkosten gezählt. Auf Betriebsebene ist das
Beanspruchungsprinzip anwendbar, sodass die allgemeinen Kosten Einzelkosten des Betriebs sind.
Die Zurechenbarkeit einzelner Kostengruppen hängt demnach von der Planungsebene ab:
Allgemeine Kosten sind auf der Planungsebene Betrieb Einzelkosten, da sie dem Betrieb eindeutig
zuzuordnen sind.
Allgemeine Kosten sind auf der Planungsebene Produktionsverfahren Gemeinkosten, da sie nicht nach
dem Beanspruchungsprinzip dem einzelnen Planungsgegenstand zuzuordnen sind.
135
=
+
=
+
Mithin gilt
+
=
+
K
= Vollkosten
eK
= Einzelkosten gK = Gemeinkosten
vK
= variable Kosten
fK = Fixkosten
135
Schroers, J. O., Sauer, N. (2011): Die Leistungs-Kostenrechnung in der landwirtschaftlichen Betriebsplanung.
KTBL-Schrift 86.

image
Schriftenreihe des LfULG, Heft 4/2022 | 92
Abbildung 22: Kostengliederung

Schriftenreihe des LfULG, Heft 4/2022 | 93
3.2.12 Datenverfügbarkeit und Schnittstellen
3.2.12.1 Abstraktion und Bezug zu Data Dictionaries und Datenkatalogen
Eine nähere Betrachtung der gegebenen Zielgrößen ergibt, dass sich diese auf eine gemeinsame, in der
Ökonomie entwickelte Abstraktion zurückführen lassen, die zumindest eine zielgerichtete Einschränkung
relevanter Datenattribute ermöglicht. So lassen sich fast alle Zielgrößen auf eine Summe von Menge-Preis-
Produkten (in anderen Worten: das Skalarprodukt eines Mengen- und eines Preisvektors) zurückführen. Im
Einzelnen lässt sich dies folgendermaßen skizzieren:
Vollkosten:
=0
{∀
}:
Für die Ermittlung der Vollkosten sind alle Mengen und Preise
für die in Abbildung 22 dargestellten Kostentypen zu ermitteln und in diese Formel einzusetzen. Zu
beachten ist, dass Mengenangaben nicht nur „Mengen“ als Volumina oder Massen sein können, sondern
auch Zeiten (z. B. für den Arbeitseinsatz) oder Anteile (z. B. Prozentsätze bei Zinsen) und dass eine
passende Auswahl für die gewählte Bezugsgröße (je Produkteinheit, je Schlag...) erfolgen muss bzw. ein
entsprechender Bezug herzustellen ist.
Kostenleistungsrechnung:
=0
{∀
}:
Bei der Kostenleistungsrechnung entspricht eine
Teilmenge der Mengen und Preise denjenigen, die auch für die Ermittlung der Vollkosten notwendig
sind. Zusätzlich werden Leistungen betrachtet. Preise für Kosten erhalten ein negatives Vorzeichen,
Preise für Leistungen ein positives. Auch hier ist die Auswahl geeigneter Werte für den jeweils ge-
wählten Bezugsrahmen erforderlich.
Betriebszweigauswertung:
=0
{∀
}:
In der Betriebszweigauswertung können
grundsätzlich mehrere Größen betrachtet werden, als Rahmen ist hier jedoch ein bestimmter Betrieb-
szweig festgesetzt. Mithin können auch hier die zu beziehenden Daten mit den für die Vollkosten-
ermittlung oder die Kostenleistungsrechnung zu ermittelnden Parametern in Teilen übereinstimmen.
Gewinnschwelle:
0 =
=0
{∀
},
anschließend Auflösung der Formel nach der
Absatzmenge. Gemäß der Formel aus 3.2.5.2 (die eine umgeformte Version der hier gegebenen Formel
darstellt) ist hier insbesondere die Differenzierung nach Fixkosten und variablen Kosten relevant.
Maschinenparkauswertung:
=0
{∀
},
anschließend Division durch die Ge-
samteinsatzstunden. Wie unter 3.2.10.2 beschrieben, reicht es nicht aus, die über den ISOBUS – sofern
die richtigen Datenfelder von der Maschine geliefert werden – leicht ermittelbaren Verbräuche von Be-
triebsstoffen zu erfassen. Es müssen auch Reparaturkosten, Wartung, Versicherung und Abschreibung
einbezogen werden.
Liquidität: z. B. Periodenliquidität:
{∀
ä
}
=0
{∀
ä
}
=0
,
m in der Regel = 1 (jede Rechnung ist verschieden). Liquiditätsmaße lassen sich zwar auf dieselbe Formel
reduzieren, stellen aber dennoch einen Spezialfall dar: Der Datenbedarf unterscheidet sich insofern vom
Datenbedarf für andere Zielgrößen, als hier in der Regel weniger im agronomischen Prozess erhobene
Daten zum Einsatz kommen, sondern viel eher Verbindlichkeiten (Rechnungsdaten) einfließen.

Schriftenreihe des LfULG, Heft 4/2022 | 94
Zu beachten ist dabei, dass sich alle Kenngrößen in der Auswertung auf einen bestimmten Zeitraum beziehen
und die Situation zu einem bestimmten Zeitpunkt widerspiegeln. Für alle Kenngrößen gilt daher: Es fließen nur
die in einem bestimmten Auswertungszeitraum angefallenen Preis- und Mengendaten ein, wobei zu beachten
ist, dass dennoch auf viel früher erfasste Werte zurückgegriffen werden muss: Zum Beispiel erfordert die Be-
rechnung der Abschreibung eines bestimmten Jahres die Kenntnis des Anschaffungspreises, der unter Um-
ständen schon in einem vorherigen Jahr in der Buchhaltung erfasst wurde.
Sofern sich für die in einem übergreifenden FMIS darzustellenden Kenngrößen eine solche Abstraktion wie die
eben skizzierte finden lässt, kann dies erste Schritte in der Umsetzung vereinfachen. Auf Basis vorliegender
Datenkataloge kann gezielt auf die Suche nach Attributen gegangen werden, die unter die entsprechende
Abstraktion fallen: Im konkreten Fall müsste also insbesondere nach Attributen gesucht werden, die Mengen
oder Preise abbilden. Eine maschinenlesbare semantische Beschreibung von Attributen für Datenformate
und/oder in Data Dictionaries über Ontologien könnte diesen Prozess nochmals deutlich vereinfachen, indem
hierüber gezielte Abfragen realisiert werden könnten, im Sinne von beispielsweise: „Gib’ mir alle Datenfelder,
die eine Menge darstellen (z. B. über Abfrage von Größen, die Massen, Volumina oder Zählungen sind)“. Der-
zeit ist jedoch keines der für Agrarstandards verfügbaren Data Dictionaries schon entsprechend aufbereitet.
Die für diese Studie erarbeitete beispielhafte Überführung der ISOBUS DDI Data Dictionaries und des ADED in
ein Excel-Sheet erlaubt, einzelne Aspekte dieses Konzepts aufzuzeigen: So ist es hierüber möglich, über Attri-
bute, die üblicherweise von bestimmten Device Classes im ISOBUS geliefert werden, zu filtern oder nach Ein-
stellwerten (Setpoint), Gesamtsummen (Total), Standardwerten (Default) etc. zu gruppieren. Da aber die Struk-
tur der Data Dictionaries selbst ad-hoc aufgebaut wurde, für die Beschreibung der Attribute kein einheitlicher
Standard genutzt wurde und wichtige Informationen zur Einordnung nicht maschinenlesbar verfügbar sind, ist
eine solche Aufbereitung aufwändig und erfordert z. B. Techniken zur Extraktion der Information aus Texten
oder Webseiten. Dass dies heutzutage auch anders geht, zeigt die Webseite „Linked Open Vocabularies“
136
:
Dort lassen sich rund 80.000 einzelne Datenfelder und Entitäten für 760 Vokabularien des Semantic Web
(Vokabularien entsprechen hierbei im Kern einem Data Dictionary) gezielt und standardübergreifend nach
einer Reihe von Kriterien und Kategorisierungen – z. B. Themenbereiche – filtern. Zudem existiert eine API,
über die solche Abfragen automatisiert erfolgen können. Im Grunde handelt es sich dabei also um einen über-
greifenden Datenkatalog bis zur Ebene einzelner Attribute hinab, der sich in dem Fall einfach realisieren lässt,
weil eine einheitliche, standardisierte Beschreibungssprache (das Resource Description Framework (RDF) des
World Wide Web Consortium) basierend auf einem gemeinsamen Metamodell genutzt wird. Ein solches ein-
heitliches Modell erlaubt einerseits, die Zusammenhänge und Beziehungen zwischen einzelnen Datenfeldern
explizit zu spezifizieren und abfragbar zu machen. Andererseits können analog dazu, wie hier Vokabularien
aus einer Reihe von weltweit verteilten Quellen zusammengeführt wurden, mit sehr überschaubarem Aufwand
auch Datensätze zusammengeführt und einheitlich abfragbar gemacht werden - beispielsweise Buchhaltungs-
daten mit agronomischen Daten. Die Nutzung von RDF (oder kompatiblen Beschreibungsmechanismen/-
sprachen) zur Beschreibung von Agrardatenmodellen würde beträchtliche Interoperabilitätsfortschritte ermög-
lichen, reicht alleine aber nicht aus: Es muss auch die Kompetenz für die Anwendung solcher Modellbeschrei-
bungen in der Softwareentwicklung vorhanden sein.
136
https://lov.linkeddata.es/

Schriftenreihe des LfULG, Heft 4/2022 | 95
3.2.12.2 Ableitung von Anforderungen für FMIS und Datenmanagement
Unter der Maßgabe, dass sich die Auswertungsfunktionen im Wesentlichen auf die o. g. Zielgrößen be-
schränken, bestehen keine hohen Anforderungen bezüglich der umzusetzenden Kalkulationsalgorithmik
an ein FMIS: Es muss im Wesentlichen ein Skalarprodukt bilden können und auf dieses oder auf einflie-
ßende Parameter die Grundrechenarten anwenden können. Bezüglich der Auswahl und des Bezugs (Sel-
ection and Retrieval) der relevanten Parameter, die die Formel befüllen, ergeben sich jedoch eine Reihe
von teils komplexeren Anforderungen. Für die Ermittlung der betrachteten Zielgrößen müssen Parameter-
abfragen an den Datenbestand mindestens nach folgenden Selektionskriterien möglich sein (die Notation
(m, p) steht im Folgenden für Menge-Preis-Paare):
Zeit: „Gib‘ mir alle (m, p), die in einem bestimmten Zeitraum angefallen sind.“
Elemente innerhalb eines hierarchischen Baumes, der die Betriebszweige abbildet: „Gib‘ mir alle (m, p),
die von einem bestimmten Knoten ausgehend abwärts in einem Betriebszweig-Produktionsverfahrens-
Task-/Feldarbeitsbaum erfasst wurden“, beispielsweise Pflanzenbau --> Winterraps --> Ernte.
Der Aufbau des Baumes ist betriebsindividuell verschieden.
Kosten: „Gib‘ mir alle (m, p), die als Kosten kategorisiert sind.“ (z. B. für Vollkosten)
Leistungen: „Gib‘ mir alle (m, p), die zu Leistungen gehören.“ (z. B. für KLR)
Diese Selektionen müssen in beliebig verknüpfbaren Abfragen realisiert werden können, beispielsweise:
„Gib’ mir alle (m, p) aus dem Produktionsverfahren Winterraps im Jahr 2021, die zu Leistungen gehören.“ In
einer praktischen Umsetzung sind weitere Selektionskriterien nützlich, die sich aus weiteren naheliegenden
Anforderungen ergeben, die unter anderem auch in den Fachgesprächen genannt wurden:
Raum: „Gib‘ mir alle (m, p), die in einer bestimmten räumlichen Einheit angefallen sind.“ Diese
Funktionalität ist notwendig, um Auswertungen für einzelne Schläge zu ermöglichen.
Vergleichsdaten: „Gib‘ mir alle entsprechenden (m, p) zu meiner Selektion aus einem Benchmarking-
Datensatz vorliegenden Daten zum Vergleich.“
Zu beachten ist, dass bei der Evaluierung des FMIS-Konzeptes deutlich der Wunsch geäußert wurde,
dass die notwendigen Daten vollständig automatisch und möglichst ohne jeglichen manuellen Eingriff von
den jeweiligen Datenquellen zum FMIS gelangen sollen. Aktivitäten wie das Abspeichern in Exportdateien
und das Laden zum Importieren sind derzeit zwar eine weit verbreitete Herangehensweise, um Daten von
einem System ins andere zu transferieren, doch dies wird als umständlich empfunden und sollte möglichst
vermieden werden. Ein solcher vollautomatischer Datenfluss erfordert beträchtliches Hintergrund- und
Kontextwissen, das zusätzlich zu den eigentlichen Daten formal kodifiziert im Datenmanagementsystem
mit abgelegt sein muss, um obige Abfragen realisieren zu können. Das System muss beispielsweise „wis-
sen“, welche Attribute Mengen oder Preise darstellen; es muss die jeweils erforderlichen Zeit- und Raum-
bezüge herstellen können sowie den betriebsindividuellen Betriebsbaum kennen. Zudem müssen die zu
Zahlenwerten gehörigen Einheiten und die jeweiligen Bezugsgrößen (...pro Jahr, ...pro Tonne etc.) richtig
zugeordnet und gegebenenfalls Umrechnungen durchgeführt werden können. Außerdem muss dem Sys-
tem bekannt sein, welche Daten in welchem Teilsystem vorliegen und abgefragt werden können und ggfs.
woher bei fehlenden Daten Ersatzwerte bezogen werden können – d. h. das Datenmanagement muss
intern eine Art eigenen Datenkatalog führen.

Schriftenreihe des LfULG, Heft 4/2022 | 96
Angesichts der existierenden Vielfalt betriebsindividueller Gegebenheiten im Hinblick auf Produktionspro-
gramm, Geräte- und Systemausstattung ist eine initiale individuelle Konfiguration unumgänglich. Eine Selbst-
konfiguration, bei der das FMIS eigenständig erkundet, welche weiteren Systeme auf dem Betrieb vorhanden
sind und versucht, daraus das betriebliche Setup zu erschließen, erscheint auf Basis der derzeitigen techni-
schen Umsetzungen von Schnittstellen nicht realistisch. Standardisierung hilft nur bedingt, da die eigentliche
Schwierigkeit in der Zusammenstellung betriebsindividueller Subsets liegt.
Einige der sich bei der Umsetzung eines übergreifenden FMIS ergebenden praktischen Herausforderungen
sind anhand von Beispielen im folgenden Abschnitt skizziert.
3.2.12.3 Praktische Bewertung und Herausforderungen
Für die Ermittlung fast aller betrachteten Ziel- und Kenngrößen ist die Beschaffung mehrerer Einzeldaten-
werte aus verschiedenen Systemen notwendig – einzig die Daten zu aktuellen Kontoständen können über
gängige Schnittstellen für Banking-Software abgefragt werden (s. Abschnitt 2.2.1.7).
Für viele Parameter liegen dabei mehrere Auswahlmöglichkeiten vor, und je nach Kontext sind verschiedene
Auswahlen zu treffen. Ein Setzen des Filters im Blatt „ISOBUS DDIs“ in Anhang 2.1 auf DDIs, die gemeinhin
von Düngerstreuern (Device Class 5, Fertilizer) geliefert werden, zeigt beispielsweise, dass es eine Reihe
verschiedener Datenfelder gibt, über die die ausgebrachte Düngemenge ausgedrückt bzw. ermittelt werden
kann:
Actual Volume/Mass Per Area Application Rate (DDI 2, 7)
Actual Volume/Mass Per Time Application Rate (DDI 37, 42)
Total Application Volume/Mass (DDIs 80, 81)
Lifetime Application Total Mass/Volume (DDIs 266, 325)
Actual Application of Nitrogen/Ammonium/Phosphor/Potassium (DDIs 401, 402, 403, 404)
Actual Application Rate of Nitrogen/Ammonium/Phosphor/Potassium (DDIs 433, 437, 441, 445)
Die Maßzahlen weisen dabei unterschiedliche Bezüge (per Time, per Area...) auf, müssen also gegebenen-
falls auf den von der Zielgröße geforderten Bezug umgerechnet werden. Sofern es sich um Lifetime Totals
handelt, muss die Differenz zwischen Start- und Endwerten gebildet werden. Abhängig davon, ob es sich um
eine Flüssigdüngung/Ausbringung von flüssigem Wirtschaftsdünger oder um eine Mineraldüngerausbringung
handelt, muss die DDI für Volumen oder für Masse ausgewählt werden. Welche DDIs nutzbar sind und für
eine bestimmte Auswertung aus dem “Datenpool” selektiert werden sollten, ist also auch vom Kontext ab-
hängig. Damit ein Managementsystem vollautomatisch algorithmisch entscheiden kann, welche Attribute
herangezogen werden können, muss es im Grunde auch „wissen“, welche Düngemittel üblicherweise flüssig
und welche in fester Form appliziert werden. Da keine standardisierte Nomenklatur – d. h. kein kontrolliertes
Vokabular – für das Befüllen der Datenfelder, die das Düngemittel bezeichnen (Product-Element, <PDT>),
im ISOBUS genutzt wird und die Landwirtin oder der Landwirt hier bei der Planung oder am Terminal im
Prinzip beliebige Zeichenketten eintragen kann, ist auch die Zuordnung anhand von Düngemittelnamen für
ein Computersystem eigenständig ohne manuellen Eingriff/manuelle Vorkonfiguration durch den Nutzer
praktisch nicht möglich. Durch eine enge Verknüpfung von ISO-Tasks mit Buchungssätzen in der Schlag-
kartei kann ein gewisser Kontext hergestellt werden. Das Maß, in dem dies geschehen kann ist aber von der

Schriftenreihe des LfULG, Heft 4/2022 | 97
Softwareanwendung abhängig. Für eine Einbettung in Austauschformate von Schlagkarteien gibt es derzeit
keinen allgemeingültigen Standard. Der Bezug geht wieder verloren, sobald die Datensätze zu Übertra-
gungszwecken z. B. für Auswertungen in anderen Softwaresystemen herausgelöst werden müssen.
Die unbesehene Nutzbarkeit einiger Werte für bestimmte Auswertungen ist zudem wegen mangelnder Ge-
nauigkeiten und/oder Unterschieden zu anderen Bestimmungsmethoden nur theoretisch gegeben: Prozess-
Totals können von der Summe der Einzelwerte abweichen; verschiedene Sensoren kommen zu unterschied-
lichen Ergebnissen – z. B. Einzelkornzähler vs. Wägeeinheit; stationäre Waagen sind in der Regel präziser.
Dieser Umstand wurde von einem der Landwirte im Evaluierungsgespräch bestätigt: Er merkte an, dass bei
ihm bei der Ernte alle Anhänger über die Waage gehen, da die Ertragserfassung am Mähdrescher wesentlich
ungenauer arbeitet und/oder aufwändig kalibriert werden muss. Bei gemittelten Werten hängen Unsicher-
heiten in der Bestimmung zudem mit der Stichprobengröße zusammen. Über große Ackerflächen liegen bei in
konstantem zeitlichem Abstand erhobenen Sensorwerten in der Regel (geschwindigkeits- und arbeitsbreiten-
abhängig) mehr Einzelwerte vor als über kleinen Flächen, sodass im Durchschnitt bei großen Flächen oft
zuverlässigere Werte ermittelt werden können.
Für die Ermittlung von ökonomischen Kenngrößen enthält die Buchführung im Prinzip die richtigen Werte. Da
aber üblicherweise abgeschlossene Transaktionen erfasst werden und Abrechnungen für den Verkauf von
Ernteprodukten teilweise erst im Folgejahr vorliegen, lassen sich auf dieser Basis keine tagesaktuellen Kosten-
Leistungsauswertungen erstellen. Ein Datenmanagement, dass die Anforderung von tagesaktuellen Auswer-
tungen erfüllen soll, muss also ad-hoc nach Verfügbarkeit auf Daten unterschiedlicher Qualität zugreifen kön-
nen – auf Preise aus einem Marktinformationssystem wenn beispielsweise der Verkaufspreis noch nicht fest-
steht oder auf ISOBUS-Mengenerfassungen, wenn über Waagen ermittelte Mengen nicht vorliegen. Gegebe-
nenfalls müssen auch Planwerte, Faustzahlen oder Daten aus Vorjahren genutzt werden. Damit sind zwei
Schwierigkeiten verbunden: Das System muss die relative Vorzüglichkeit vergleichbarer Datenattribute ken-
nen, d. h. es muss abhängig von der aktuellen Verfügbarkeit die passendsten Daten auswählen können. So-
fern die Priorisierung verschiedener Datenquellen für alle Auswertungen gleich ausfällt, könnte man die Konfi-
guration hier auch durch den Anwender durchführen lassen: So könnte eine konfigurative Vorgabe für ein
Datenmanagementsystem beispielsweise lauten: “nimm an erster Stelle immer Daten aus dem Wägesystem
und falle nur auf ISOBUS-Mengenerfassungen zurück, wenn erstere Daten nicht verfügbar sind”. Sobald aber
für verschiedene Auswertungen unterschiedliche Datenquellen, möglicherweise mit auch unterschiedlichen
Priorisierungen einzubinden sind, können solche Einstellmöglichkeiten für Anwender schnell unübersichtlich
werden. Damit entstehen entsprechend hohe Anforderungen an die Nutzerführung insbesondere für eine all-
gemein und breiter verwendbare Umsetzung, die zudem eine größere Anzahl potenziell auf landwirtschaft-
lichen Betrieben vorhandener Datenquellen berücksichtigen müsste. Sinnvolle Standardeinstellungen sind
dann unabdingbar und gute Datenbeschreibungen, anhand derer gewisse Heuristiken (z. B. Auswahl anhand
von Genauigkeitsmaßen) umgesetzt werden können, wären hierfür hilfreich.
Neben der Bewertung der Vorzüglichkeit vergleichbarer Datenattribute muss ein System auch die Bezüge
zwischen verschiedenen Datenbeständen herstellen können. Wenn beispielsweise ein Buchführungssystem
für Weizen einen anderen Identifier nutzt als die Schlagkartei oder für eine Maschine einen anderen als das
Flottenmanagement, dann ist eine vollautomatisierte Zusammenführung der Daten zu dieser Kultur bzw.
Maschine aus den Systemen zum Scheitern verurteilt - aber nicht nur das, auch die Zuordnungen vergleich-
barer, äquivalenter Attribute in verschiedenen Systemen selbst muss erfolgen.

Schriftenreihe des LfULG, Heft 4/2022 | 98
Auch in Bezug auf die Ermittlung von Liquiditätsmaßen spielt eine unzureichende Verfügbarkeit aktueller
Daten eine Rolle: Es ist eine bekannte Schwäche der oben beschriebenen Liquiditätsgrade und des Cash-
flows, dass sie regulär erst nach Erstellung einer Bilanz bestimmt werden können.
137
Im alltäglichen Be-
triebsmanagement wäre es jedoch viel wichtiger, in Bezug auf die Liquidität vorausschauend agieren zu kön-
nen und in der Zukunft fällig werdende Forderungen sowie zu erwartende Mittelzuflüsse im Blick behalten zu
können, um kurzfristig Engpässe sowie Chancen erkennen zu können. Praktisch scheitert dies derzeit unter
anderem daran, dass Rechnungen in der Regel nach wie vor häufig auf Papier vorliegen und nicht systema-
tisch digitalisiert werden. Dadurch fehlen wichtige Daten wie Beträge und Fälligkeitstermine. Adressiert wer-
den kann das Problem durch eine durchgängige digitale Erfassung eintreffender Rechnungen. Ein dafür ein-
gesetztes System sollte neben der Schrifterkennung auch die Extraktion der relevanten Informationen und
ihre Überführung in strukturierte Formate wie JSON, XML oder CSV unterstützen. Hierfür sind Systeme am
Markt erhältlich, die sich beispielsweise unter Schlagworten wie „information extraction from scanned in-
voices“ recherchieren lassen. Der Funktionsumfang und mögliche Automatisierungsgrad unterscheidet sich
jedoch erheblich, sodass im Rahmen einer Umsetzung zu prüfen wäre, welche Angebote für die Anwendung
im typischen Büroumfeld im landwirtschaftlichen Kontext geeignet und finanziell realisierbar wären.
3.3 Betriebliches Datenmanagement
Wir beginnen diesen Abschnitt mit der Begriffsklärung des Datenmanagements. Unter Datenmanagement
kann man die Gesamtheit aller technischen, konzeptionellen, organisatorischen und methodischen Maß-
nahmen verstehen, Daten so zu erheben, zu speichern und bereitzustellen, dass sie die Unternehmenspro-
zesse optimal unterstützen.
138
Im Kontext landwirtschaftlicher Betriebe betrachtet das betriebliche Datenma-
nagement alle Systeme, Maschinen und Anlagen, die Daten erzeugen, speichern, bereitstellen und nutzen.
Im Rahmen dieser Studie geht es dabei vor allem um Fragestellungen und Herausforderungen bei der sys-
temübergreifenden Nutzung von Daten. Beispiele:
Eine Erntemaschine erfasst bei der Ernte Ertragsmengen und legt diese als Dateninformation in einem
Cloudsystem des Maschinenherstellers ab. Das Datenmanagement soll die Möglichkeit bieten, dass
diese Daten in einer eigenständigen Ackerschlagkartei genutzt werden können.
Bei einer Applikation von Düngemitteln wird ermittelt, wie viel Dünger auf einem Ackerschlag ausge-
bracht wurde. Das Datenmanagement soll ermöglichen, dass die ermittelte Düngemenge in die Dünge-
dokumentation und in die Buchhaltung übernommen wird.
Verschiedene betrieblich genutzte Softwaresysteme wie Ackerschlagkartei, Maschinenmanagement und
Buchhaltung erfassen und speichern Daten, die zur Berechnung einer betrieblichen Kennzahl in einem
FMIS benötigt werden. Das Datenmanagement soll ermöglichen, dass die Daten aus verschiedenen
Systemen dem FMIS bereitgestellt werden, damit dieses die Kennzahl berechnen kann.
137
s. z. B.
https://www.controllingportal.de/Fachinfo/Kennzahlen-1/liqui1.html?sphrase_id=57518295
138
Vgl. dazu https://de.wikipedia.org/wiki/Datenmanagement und
https://www.storage-insider.de/was-ist-data-
managementdatenmanagement-a-850258/ (letzter Zugriff auf beide am 17.08.2021)

Schriftenreihe des LfULG, Heft 4/2022 | 99
Die Produktions- und Entscheidungsprozesse in der Landwirtschaft sind ebenso vielfältig wie verschie-
denartig und die aufgeführten Beispiele können nur anreißen, welche Aufgaben ein betriebliches Daten-
management übernehmen muss. Im Rahmen dieser Studie wollen wir aufzeigen, was zum betrieblichen
Datenmanagement gehört, welche Kernanforderungen an dieses bestehen und welche Lösungsansätze
diese Anforderungen erfüllen können. Wir legen dabei besonderen Fokus auf ein Datenmanagement, das
die Umsetzung eines gesamtbetrieblichen FMIS (vgl. Abschnitt 3.4) unterstützt. Die folgenden Abschnitte
sollen zunächst das für die Diskussion möglicher Datenmanagementlösungen notwendige Hintergrund-
wissen und relevante Konzepte aufzeigen, um dann mit Vorschlägen für Lösungsansätze den Aufbau
eines gesamtbetrieblichen FMIS vorzubereiten.
3.3.1 Konzepte und Hintergründe zum betrieblichen Datenmanagement
3.3.1.1 Grundlegende Funktion eines betrieblichen Datenmanagements
Wir fokussieren in diesem Abschnitt die Definition des Datenmanagements aus Abschnitt 0: Das betriebliche
Datenmanagement hat die grundsätzliche Aufgabe, Daten aus verschiedenen betrieblich genutzten Software-
systemen systemübergreifend nutzbar zu machen. Mit dem Begriff „System“ abstrahieren wir von spezifischen
Softwarelösungen wie bspw. einer Ackerschlagkartei oder einem Buchhaltungssystem. Maschinen und Sen-
soren betrachten wir nicht als eigenständiges System, sondern als Datenquelle oder -senke, die stets über
zugehörige Softwaresysteme oder auch herstellerfremde Hardware mit eigener Softwareanbindung ange-
sprochen wird. Statt direkt von der Maschine werden Daten über Softwaresysteme der Maschinenhersteller
genutzt; das Gleiche gilt für Wiegesystem, Sensoren usw.
Es gibt folglich verschiedene „Systeme“, die unter Nutzung des Datenmanagements miteinander Daten aus-
tauschen sollen. Das Datenmanagement ermöglicht es dann, dass zwischen einem System A (bspw. Acker-
schlagkartei) und System B (bspw. Maschinenmanagement) Daten ausgetauscht werden können. Das Da-
tenmanagement ist dabei nicht zwangsläufig als eigenständiges Softwaresystem zu verstehen (vgl. Defini-
tion in 3.3), sondern kann auch eine reine organisatorische Maßnahme sein, die verschiedene Softwaresys-
teme einbezieht. Ein Beispiel ist der manuelle Export der Daten aus System A als Excel-Datei und der Import
der Datei in System B. Der gleiche Vorgang kann aber auch über einen Datenrouter erfolgen, der dann
durch ein eigenständiges Softwaresystem umgesetzt wurde. Beides sind Varianten eines Datenmanage-
ments. Abbildung 23 zeigt eine vereinfachte Darstellung der Idee des Datenmanagements als Mittler zwi-
schen Softwaresystemen. In der Abbildung ist neben drei abstrahierten betrieblichen Systemen bereits das
FMIS eingezeichnet, das im Rahmen dieser Studie grundsätzlich konzipiert werden sollte.

image
Schriftenreihe des LfULG, Heft 4/2022 | 100
Abbildung 23: Vereinfachte Darstellung der Funktion eines betrieblichen Datenmanagements als
Mittler zwischen Softwaresystemen
3.3.1.2 Horizontales und vertikales Datenmanagement
Im Rahmen dieser Studie unterteilen wir das Datenmanagement in das horizontale und das vertikale Daten-
management, wobei unser Fokus auf dem vertikalen liegen wird.
Das
horizontale Datenmanagement
umfasst im Wesentlichen die Verbindung zwischen betrieblichen Soft-
waresystemen ohne das gesamtbetriebliche FMIS (vgl. Abbildung 23). Es soll den Austausch zwischen Soft-
warelösungen wie Ackerschlagkartei, Precision Farming, Warenmanagement, Maschinenmanagement,
Buchhaltung usw. herstellen und dabei Medienbrüche zwischen den Systemen minimieren und einfache,
systemübergreifende Arbeitsprozesse ermöglichen. Der Begriff des horizontalen Datenmanagements kommt
daher, dass hier Daten zwischen Systemen auf der gleichen horizontalen Ebene im Kontext von betrieblichen
Produktionsprozessen ausgetauscht werden. Abbildung 24 zeigt in einer schematischen Übersicht die Klas-
sen der Softwaresysteme, die vom horizontalen Datenmanagement betrachtet werden. Hier hat das Daten-
management die Aufgabe, diese Softwaresysteme miteinander zu verbinden, d. h. Datenbestände system-
übergreifend nutzbar zu machen.

image
Schriftenreihe des LfULG, Heft 4/2022 | 101
Abbildung 24: Das horizontale Datenmanagement hat die Aufgabe, betrieblich genutzte
Softwaresysteme miteinander zu verbinden
Das
vertikale Datenmanagement
hat die Aufgabe, dem gesamtbetrieblichen FMIS zur Informationsbereit-
stellung in Entscheidungsprozessen Daten aus den betrieblich genutzten Systemen bereitzustellen. Grund-
sätzlich baut das vertikale Datenmanagement auf dem horizontalen auf, betrachtet aber nur die Elemente,
die für den Informationsfluss hin zum FMIS benötigt werden. Da das FMIS Informationen aus weiteren Sys-
temen nur aufnimmt, muss das Datenmanagement an dieser Stelle keinen Informationsfluss in beide Rich-
tungen gewährleisten, d. h., lesende Schnittstellen in den Quellsystemen können bereits genügen.

image
Schriftenreihe des LfULG, Heft 4/2022 | 102
Abbildung 25: Das vertikale Datenmanagement hat die Aufgabe, Dateninformationen aus
betrieblich genutzten Softwaresystemen dem gesamtbetrieblichen FMIS
bereitzustellen
3.3.1.3 Datenschnittstellen, Medienbrüche und Interoperabilität
Datenschnittstellen (oder vereinfacht Schnittstellen) dienen dem Austausch von Informationen, wobei es men-
schenlesbare- und computerlesbare Schnittstellen geben kann. Menschenlesbare Schnittstellen sind typi-
scherweise grafische Benutzeroberflächen wie bspw. ein Terminal oder die Ackerschlagkartei, es kann aber
auch eine exportierte Excel-Liste oder ein PDF-Report darunter verstanden werden. Unter computerlesbaren
Schnittstellen verstehen wir Datenschnittstellen, über die zwei Softwaresysteme miteinander kommunizieren
können. Hierzu zählen im betrieblichen Kontext nicht nur Softwarelösungen wie Ackerschlagkartei und Buch-
haltungssystem, sondern auch in Maschinen und Anlagen integrierte Softwaresysteme wie bspw. eine Waage
oder das Terminal eines Traktors. Im Kontext des betrieblichen Datenmanagements sind Schnittstellen zum
Austausch von Daten im Rahmen von Produktionsprozessen unabdingbar. Ein Beispiel ist das erfasste Ge-
wicht einer Ernte, das von der Waage in das Warenmanagementsystem übertagen werden muss. Im Bericht
zur Machbarkeitsstudie des BMEL zu staatlichen Datenplattformen wurden Datenschnittstellen im landwirt-
schaftlichen Raum detailliert diskutiert und im Markt verfügbare Angebote dargestellt.
139
139
Machbarkeitsstudie staatlichen digitalen Datenplattformen für die Landwirtschaft,
https://www.bmel.de/SharedDocs/Downloads/DE/_Digitalisierung/machbarkeitsstudie-agrardatenplattform.html

Schriftenreihe des LfULG, Heft 4/2022 | 103
Im Kontext unserer Studie ist in der Diskussion von Datenschnittstellen die Interoperabilität von besonderer
Relevanz, die verschiedene Ebenen aufweist. Für computerlesbare Schnittstellen besteht die Herausforde-
rung darin, diese auf mehreren Ebenen interoperabel zu gestalten, um einen funktionierenden Austausch
bzw. eine erfolgreiche Integration in Prozesse zu erreichen. Abschnitt 2.3.2 diskutiert ausführlich Aspekte
der Interoperabilität mit Hinweisen auf Medienbrüche, die einen erfolgreichen Austausch zwischen Systemen
erschweren. Wir fassen an dieser Stelle die Anforderungen aus der Interoperabilität
140
zusammen, die für
das betriebliche Datenmanagement besonders relevant sind. Die Interoperabilität steigt mit den Stufen:
Stufe 0 – Systeminteroperabilität:
Beschreibt, ob zwei Systeme so miteinander verbunden sind, dass
sie prinzipiell Kontakt zueinander aufnehmen können. Dieser Zustand kann bspw. über eine
Internetanbindung erfolgen. Müssen Daten zwischen Systemen über USB-Sticks ausgetauscht werden,
ist die Systeminteroperabilität nicht gegeben. Zur Interoperabilität auf dieser Stufe gehört, dass zwei
Systeme über miteinander interoperable Schnittstellen verfügen, wie bspw. eine REST-Schnittstelle
141
,
passende Import- und Exportschnittstellen für Dateien usw.
Stufe 1 – Syntaktische Interoperabilität:
Zwei Systeme sind miteinander verbunden und können
prinzipiell Daten austauschen, doch diese werden von den beiden Systemen noch nicht zwangsläufig
gleich verstanden. Ein Beispiel ist der Austausch eines Shapefiles mit agronomischen Funktionen.
Während beide Systeme zwar das Format „Shapefile“ verarbeiten können, gilt hier noch nicht, dass sie
auch die enthaltenen Daten interpretieren können. Auf dieser Stufe fokussiert die Betrachtung auf
gleiche Datenformate, wie bspw. Shapefiles. Weitere Beispiele sind Excel-Dateien, XML usw.
Stufe 2 – Semantische Interoperabilität:
Zwei Systeme können Daten miteinander austauschen und
diese auf gleiche Art und Weise interpretieren. Im Beispiel mit dem Shapefile bedeutet dies etwa, dass ein
Shapefile mit Informationen zum Nmin-Gehalt in Ackerböden von beiden Systemen gleich interpretiert und
verarbeitet werden. Dabei müssen u.a. geografische Informationen (GPS, genauer Ort) und Werte zum
Stickstoffgehalt genau gleich verstanden werden (Art der Beprobung, Einheit des angegebenen Wertes).
Hier spielen Standards zur Beschreibung agronomischer Daten eine große Rolle.
Stufe 3 – Organisatorische Interoperabilität:
Diese häufig auch als pragmatische Interoperabilität
bezeichnete Bedeutung sagt aus, dass über Daten hinaus auch Prozesse von beiden Schnittstellen
gleich verstanden werden, sodass Systeme nicht nur Daten miteinander austauschen, sondern auch in
den Prozessen selbst miteinander interagieren. Ein Beispiel kann eine automatisch ausgelöste Wägung
sein: Mithilfe einer mobilen App eines Warenmanagementsystems könnte bspw. eine Landwirtin oder
ein Landwirt eine Wägung durch die Waagesoftware auslösen, wobei das Ergebnis der Wägung
automatisch in das Warenmanagementsystem übertragen würde. Ein wesentlicher Punkt hier ist das
Verhalten einer Schnittstelle bzw. die Unterscheidung in Schnittstellen, über die Daten ausgelesen
werden können, und Schnittstellen, die aktiv Daten in andere Systeme übertragen oder diese zumindest
über das Vorliegen neuer Datenbestände informieren. Ein praktisches Beispiel: Wird eine Ernte durch-
geführt und Erntemengen sollen aus dem Maschinenmanagement in das Warenmanagementsystem
übertragen werden, gibt es zwei grundlegende Ansätze: Das Warenmanagement löst eine Abfrage auf
140
Angelehnt an
https://www.etsi.org/images/files/ETSIWhitePapers/IOP%20whitepaper%20Edition%203%20final.pdf
141
Zu ReST-Services und Schnittstellen siehe auch Leonard Richardson, Sam Ruby: ReSTful Web Services, O'Reilly.
https://www.oreilly.com/library/view/restful-web-services/9780596529260,
ursprünglich entwickelt in: Roy Thomas Fielding
(2000): Architectural Styles and the Design of Network-based Software Architectures,
https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf

Schriftenreihe des LfULG, Heft 4/2022 | 104
neue Daten im Maschinenmanagement aus und liest diese aktiv in die eigenen Datenbestände ein, oder
aber das Maschinenmanagement kennt den Bedarf an Daten des Warenmanagements und überträgt
die Daten nach der Erfassung automatisch. Man bezeichnet diese beiden Prinzipien auch als Pull-
Prinzip (Abruf von Daten) und Push-Prinzip (aktive Übermittlung von Daten). Während eine Pull-Schnitt-
stelle Daten zum Lesen bereitstellt, muss eine Push-Schnittstelle in der Lage sein, neue Daten in die
eigenen Datenbestände zu integrieren. Es besteht ferner noch die Möglichkeit, beide Prinzipien zu
kombinieren: Sobald die Ernte erfasst wurde, signalisiert das Maschinenmanagement dem Waren-
management, dass neue Daten vorliegen und es ist dann dem Warenmanagement überlassen, diese
Daten per Pull-Prinzip abzurufen.
Die hier aufgeführten Stufen der Interoperabilität können genutzt werden, um aktuelle Zustände im betrieb-
lichen Datenmanagement einzuschätzen und auch, um Zielvorstellungen zu formulieren. Ist eine Stufe nicht
etabliert, kommt es zu entsprechenden Medienbrüchen, die einen automatisierten Austausch zwischen com-
puterlesbaren Datenschnittstellen verhindern.
Häufig ist auch eine Stufe grundsätzlich umgesetzt und der Austausch funktioniert trotzdem nicht, da bspw.
einzelne Werte eines ausgetauschten Datenobjekts verschieden interpretiert werden oder die Interpretation
gar nicht möglich ist. Ein Beispiel wäre, wenn ein sendendes System einem Shapefile einen Wert hinzufügt,
den das empfangende System nicht erwartet und das deshalb die Verarbeitung nicht durchführen kann.
Diese Art von Problemen tritt in der Informationstechnologie sehr häufig auf und kann u.a. in einer nicht
einheitlichen Nutzung von Spezifikationen und Standards oder auch einer fehlerhaften Programmierung
begründet sein.
3.3.1.4 Grundlegende Ansätze
Zur Gestaltung eines betrieblichen Datenmanagements werden in dieser Studie drei grundlegende Ansätze
dafür untersucht, wie ein Datenmanagement organisatorisch und technisch aufgebaut werden kann. Die
Ansätze sind nicht exakt trennscharf und müssen jeweils noch technologisch konkretisiert werden, helfen
aber bei der Diskussion und dienen insbesondere dazu, konkrete Ansätze aus Wirtschaft und Forschung zu
strukturieren. In diesem Abschnitt werden zunächst die drei Ansätze vorgestellt und in eine Systematik ein-
geordnet.
3.3.1.4.1
Bilaterale Schnittstellen
Durch bilaterale Schnittstellen treten zwei Systeme unmittelbar miteinander in Verbindung und können über
diese Daten austauschen (vgl. Abbildung 26). Die Gestaltung der Schnittstellen kann dabei individuell zwi-
schen den Systemen erfolgen oder einem übergreifenden Standard
142
folgen. Bilaterale Schnittstellen sind
aktuell der im betrieblichen Datenmanagement vorwiegend genutzte Ansatz zum Austausch von Daten. Sie
können insbesondere dann sinnvoll eingesetzt werden, wenn nur Bedarf für einfache Schnittstellen zwischen
einzelnen Komponenten im Gesamtsystem existiert. Als alleiniges Lösungskonzept kommen insbesondere
individuelle Schnittstellen nicht in Frage, da die Komplexität insgesamt zu groß wäre. Standardisierte bila-
terale Schnittstellen reduzieren die Komplexität deutlich.
142
Bspw. ISOXML, AgGateway ADAPT oder DataConnect

Schriftenreihe des LfULG, Heft 4/2022 | 105
Vorteile
Flexible und in der Regel schnelle Lösung zur Herstellung einer Verbindung zwischen zwei Systemen
Individuelle Schnittstellen können konkreten Bedarf zwischen zwei Systemen lösen, ohne großen
Abstimmungsaufwand zu erzeugen.
Vergleichsweise niedrige Kosten für die Integration in eine existierende Softwarelösung, wobei das stark
von der jeweiligen Implementierung abhängt. Die Schaffung einer nur lesenden Schnittstelle ist bspw.
deutlich weniger aufwändig als die einer schreibenden Schnittstelle.
Nachteile
Individuelle Schnittstellen bieten tendenziell geringe Wiederverwendbarkeit.
Bei vielen bilateralen Schnittstellen (insbesondere individuellen) entstehen hohe Aufwände bzgl.
Herstellung und Pflege und es gibt tendenziell eine höhere Fehleranfälligkeit aufgrund des hohen
Variantenreichtums und komplexen Gesamtsystems.
Ausufernde Komplexität, falls individuelle Schnittstellen das gesamte betriebliche Datenmanagement
abdecken sollen
Abbildung 26: Bilaterale Schnittstellen
3.3.1.4.2
Datenrouter
Datenrouter dienen als Mittler zwischen Systemen und übernehmen den reinen Datentransport (vgl. Abbil-
dung 27). Außer einer Pufferung von Daten für Transportzwecke speichern sie selbst keine Datenbestände.
Damit sind Datenrouter eigenständige Softwaresysteme, für die Herstellungs- und Betriebskosten anfallen.
Schnittstellen zwischen einem Datenrouter und angeschlossenen Systemen können prinzipiell individuell
gestaltet werden oder standardisiert sein, wobei ein zentraler, standardisierender Datenrouter sich vorteilhaft
auf das gesamte betriebliche Datenmanagement wirken kann, indem Datenbestände und Prozesse harmo-
nisiert werden. Zwar können Funktionen wie Konvertierungen in die Transportprozesse integriert werden,
doch sind diese aufwändig und tendenziell fehleranfällig. Aktuell ist nur mit dem agrirouter ein dedizierter
und eigenständiger Datenrouter in der Landwirtschaft etabliert.
System A
System B
System C
System A
System B
System C
Individuelle bilaterale Schnittstellen
Standardisierte bilaterale Schnittstellen

Schriftenreihe des LfULG, Heft 4/2022 | 106
Vorteile
Entkoppelt Systeme, unterstützt Transportprozesse und entlastet damit angebundene Systeme
Reduziert Varianten notwendiger Schnittstellen, wenn Standardisierung verwendet wird
Softwaresysteme können Aufwände für Standardisierung einsparen (vorteilhaft, wenn diese
eigenen Standards entsprechen).
Nachteile
Tendenziell hohe Kosten für Herstellung und Betrieb
Softwaresysteme müssen sich möglicherweise vorgegebenen Standards anpassen (nachteilig, wenn
diese nicht eigenen Standards entsprechen).
Softwaresysteme müssen empfangene Daten selbst speichern und vorhalten, da sie nicht nach Bedarf
über den Datenrouter abgerufen werden können.
Abbildung 27: Datenrouter
3.3.1.4.3
Datenhub
Ein Datenhub bietet prinzipiell die Funktion eines Datenrouters, ergänzt diese aber um die Speicherung von
Daten (vgl. Abbildung 28). Angebundene Systeme können auf die zentral und einheitlich abgelegten Daten-
bestände zugreifen und diese für eigene Funktionen nutzen; Daten und Applikation werden aber grundsätz-
lich getrennt. Es gibt dabei Spielräume zur technischen Umsetzung: Systeme können einen Hub direkt als
einzigen Datenbestand nutzen oder sie speichern Daten selbst zwischen, betrachten den Datenhub aber
System A
System B
System C

Schriftenreihe des LfULG, Heft 4/2022 | 107
übergreifend als Single Point of Truth
143
. Ein dedizierter, eigenständiger Datenhub ist in der Landwirtschaft
noch nicht etabliert, obwohl verschiedene Forschungsprojekte diesen Ansatz evaluieren und entwickeln
144
.
Ein Datenhub muss nicht zwangsläufig als eigenständige Softwarelösung konzipiert sein; so kann bspw. auch
eine Ackerschlagkartei die Funktion eines Datenhubs für weitere Softwaresysteme übernehmen. Werden
sämtliche betrieblichen Daten in einem Datenhub gehalten, bietet das Vorteile für die Verwaltung der Daten
und bspw. auch für die Konfiguration von Zugriffsberechtigungen, da alle Daten an nur einer Stelle zusam-
mengeführt wurden. Weiterhin können Daten einfach und effizient für Dienstleistungen zur Verfügung gestellt
werden, da grundsätzlich nur auf eine Stelle im betrieblichen Datenmanagement zugegriffen werden muss.
Umgekehrt bringt ein Datenhub einen hohen Aufwand mit sich, einerseits für Umsetzung und Betrieb, anderer-
seits für die angebundenen Systeme, die das Konzept der ausgelagerten Datenhaltung in ihre jeweilige Im-
plementierung integrieren müssen.
Vorteile
Ähnliche Vorteile wie beim Datenrouter
Bietet als eigenständiges Angebot die Chance für Landwirtinnen und Landwirte, ein sehr hohes Maß an
Kontrolle über eigene Datenbestände zu erreichen, da diese unabhängig von landwirtschaftlichen Soft-
wareangeboten verwaltet werden. Ermöglicht dadurch auch ein hohes Maß an Datensouveränität und
bietet die Möglichkeit, Daten dem digitalen Ökosystem einfach zur Verfügung zu stellen.
Ein Datenhub kann weitere Funktionen übernehmen, bspw. Prüfung der Datenqualität, Konvertierung oder
Korrekturen von Datenbeständen.
Ein Datenhub kann Datenbestände mehrerer Datenquellen bzw. Fachsysteme enthalten. Dadurch können
mehr und umfassendere Funktionen auf die Daten angewandt werden wie bspw. betriebszweigüber-
greifende Auswertungen.
Der Zugang für weitere Drittanbieterlösungen wird erleichtert, da keine Abhängigkeit von der Bereitschaft
einzelner Anbieter besteht, Zugang zu eigenen Datenbeständen zu schaffen.
Nachteile
Ähnliche Nachteile wie beim Datenrouter
Sehr hohe Aufwände für Konzeption, Koordination, Umsetzung und Betrieb. Daneben auch hohe Auf-
wände für Softwareanbieter, die die einzelnen Lösungen auf das Konzept der externen Datenhaltung
umstellen müssen.
Kann auf Ablehnung bei Softwareanbietern stoßen, da der Ansatz möglicherweise strategischen Eigen-
interessen der Unternehmen widerspricht
143
Beim Single-Point-of-Truth-Ansatz werden Daten redundant gehalten, d. h. angebundene Systeme halten für die Verarbeitung
notwendige Daten, die sie vom Datenhub bezogen haben. Sofern Ergebnisse erzeugt werden, die für den zentralen
Datenbestand relevant sind, werden diese wieder in den Hub integriert. Der Datenhub ist dann die eine Stelle im Gesamtsystem,
an der der korrekte und aktuelle Zustand der Daten abgelegt ist. Diese Umsetzung wird auch als Master-Slave-System be-
zeichnet und bietet für den praktischen Betrieb eine realistischere Umsetzung als die direkte Einbindung eines Datenhubs als
einzigem Datenspeicher. Letztere Variante benötigt bspw. eine enorm performante und stabile Anbindung zwischen Datenhub
und System, die in der Praxis selten gegeben ist und hohe Anforderungen an die technische Architektur stellt.
144
Vgl. bspw. die Forschungsprojekte SDSD und COGNAC

Schriftenreihe des LfULG, Heft 4/2022 | 108
Kann auf Ablehnung bei Landwirtinnen und Landwirten stoßen, wenn dem Anbieter des Datenhubs nicht
ausreichend Vertrauen entgegengebracht wird
Voraussichtlich keine 100%ige Abdeckung aller betrieblichen Datenbestände erreichbar, da einzelne
Fachsoftwarelösungen weiterhin individuelle Datenbestände halten wollen oder müssen. Möglicherweise
sind auch nicht alle Daten und Prozesse standardisierbar, sodass sie im Datenhub nicht oder nur mit
Mehraufwand abgebildet werden können.
Abbildung 28: Datenhub
3.3.1.4.4
Hybrides Datenmanagement
Statt der Etablierung eines der dargestellten Ansätze zum Datenmanagement kann es zielführender sein,
die Ansätze zu einem Gesamtszenario zu kombinieren und ein hybrides Datenmanagement aufzubauen
(vgl. Abbildung 29). Dadurch bietet sich die Chance, die einzelnen Stärken und Schwächen der verschiede-
nen Ansätze auf die konkreten Bedarfe im jeweiligen Teilbereich des Datenmanagements abzustimmen.
Aufgrund der Komplexität landwirtschaftlicher Prozesse und damit auch der jeweiligen Datenbestände ist es
voraussichtlich zielführender, statt eines sehr umfassenden, dedizierten Datenmanagementsystems mehrere
spezialisierte einzusetzen, also bspw. einen Datenrouter spezifisch für den Pflanzenbau und einen Datenhub
für betriebliche Entscheidungsprozesse. Wichtig ist bei einem solchen hybriden Ansatz, dass die einzelnen
Teilbereiche miteinander vernetzt werden.
System A
System B
System C

Schriftenreihe des LfULG, Heft 4/2022 | 109
Abbildung 29: Hybrides Datenmanagement
3.3.2 Anforderungen an ein betriebliches Datenmanagement
In diesem Abschnitt werden auf höherer Betrachtungsebene Anforderungen an ein betriebliches Daten-
management dargestellt und kurz diskutiert. Die Anforderungen ergeben sich aus den Beobachtungen
zum Status quo im betrieblichen Datenmanagement und aus den Vorgaben aus der Leistungsbeschrei-
bung dieser Studie. Wir führen einleitend Herausforderungen aus dem Status quo an, deren Beantwortung
in Anforderungen an ein Datenmanagementsystem überführt werden können.
Im Rahmen der Studie wurde kein expliziter Anforderungserhebungsprozess durchgeführt, wie er für die
erfolgreiche Umsetzung konkreter IT-Projekte essenziell ist, da diese sehr detailliert konkrete Funktionen
betrachtet. Wir haben vielmehr Herausforderungen grundlegend analysiert und in übergreifende und
grundlegende Anforderungen oder auch Treiber zukünftiger Entwicklungen überführt, die als Basis für
weitere Ausarbeitungen und Detaillierungen konkreter Umsetzungen von Lösungen im betrieblichen Da-
tenmanagement – sowohl dem horizontalen wie auch dem vertikalen – dienen können.
3.3.2.1 Herausforderungen im betrieblichen Datenmanagement
Landwirtschaftliche Betriebe müssen sich in der täglichen Praxis vielen Herausforderungen bei der Arbeit
mit digitalen Systemen stellen. Diese beginnen bei der Auswahl geeigneter Angebote, der Einarbeitung in
neue Systeme und praktischen Problemen und Fehlerbehebungen im Betrieb. Grundlegend für diese
Herausforderungen ist, dass landwirtschaftliche Prozesse, seien es Produktions- oder Entscheidungspro-
zesse, jeweils viele verschiedene Systeme, Maschinen, Anlagen oder Software mit einbeziehen. Wir
haben im Rahmen dieser Studie exemplarische Realweltprozesse detailliert analysiert, um herauszuar-
beiten, welche Teilprozesse existieren, welche Systeme und Maschinen daran beteiligt sind und welche
Daten dabei anfallen bzw. ausgetauscht werden müssen (vgl. Abschnitt 3.1). Die Ergebnisse dieser Ana-
lysen können genutzt werden, um konkrete technische und fachliche Anforderungen herauszuarbeiten
und für die Gestaltung von Lösungsansätzen zu nutzen. So wird dadurch bspw. in der Gesamtheit sicht-
bar, welche Systeme an spezifischen Produktionsprozessen wie bspw. der Düngung beteiligt sind und in
die Anforderungserhebung mit einbezogen werden müssen.
System A
System B
System C
System D
System E
System F

Schriftenreihe des LfULG, Heft 4/2022 | 110
Für das Datenmanagement ziehen wir folgende grundsätzliche Herausforderungen für die weitere Dis-
kussion heran:
Mangelnde Interoperabilität führt dazu, dass Systeme keine Daten austauschen oder in Prozessen nicht
zusammenarbeiten können (vgl. Abschnitt 3.3.1.3). Hierbei ist zu betrachten, ob überhaupt Schnittstellen
zu Systemen existieren, ob Schnittstellen syntaktisch und semantisch miteinander kommunizieren
können und ob Prozesse über Systeme hinweg durchgeführt werden können. Bei betrieblichen Pro-
zessen müssen häufig unterschiedlichste Softwarelösungen, Maschinen und Systeme genutzt werden,
um den Prozess als Ganzes durchzuführen (vgl. dazu Abschnitt 3.1). Ähnlich verhält es sich bei der
Zusammenstellung von Daten und Informationen für betriebliche Entscheidungsprozesse operativer
oder strategischer Natur. Das ist für Betriebe häufig mit großen Aufwänden verbunden, sofern es über-
haupt möglich ist, die benötigten Daten in erforderlicher Qualität und Aktualität zur Verfügung zu haben.
Die Digitalisierung und Nutzung digitaler Systeme ist in vielen Betrieben schon etabliert und ent-
sprechende Kompetenz in den Betrieben besteht bereits oder entwickelt sich. Umgekehrt stellen digi-
tale Systeme teilweise noch zu hohe Anforderungen an die IT-Fachkompetenz, sodass Betriebe bei
der Nutzung digitaler Funktionen oder bei Fehlervorfällen nicht angemessen reagieren können.
3.3.2.2 Anforderungen im betrieblichen Datenmanagement
Aufbauend auf den in der Leistungsbeschreibung gegebenen Herausforderungen formulieren wir einzelne,
konkretere Anforderungen an ein betriebliches Datenmanagement aus. Diese dürfen nicht als vollständig ver-
standen werden, da betriebliche Produktionsprozesse, dazu genutzte Systeme und Daten im Rahmen dieser
Studie nicht in voller Detailtiefe eingebracht wurden. Sie sind vielmehr als grundlegende Anforderungen zu
verstehen, die als Basis für weitere Arbeiten und konkrete Anforderungserhebungen dienen und für die Soft-
wareentwicklung genutzt werden können. Neben den Vorgaben der Leistungsbeschreibung dieser Studie
wurde auf umfassende Vorerfahrungen der Projektbeteiligten, eigene Recherchen und Zwischenergebnisse im
Rahmen dieser Studie sowie die vom LfULG bereitgestellten Vorarbeiten zurückgegriffen (vgl. Abschnitt 1.3):
DMAF1 – Unterstützung horizontaler Prozesse
: Das Datenmanagement muss die horizontalen Pro-
zesse unterstützen, d. h. dass sämtliche an einem Produktionsprozess beteiligten Systeme miteinander
kommunizieren können müssen und in der Lage sein müssen, in diesem Prozess notwendige Daten
untereinander so auszutauschen, dass sie in allen jeweiligen Systemen gleich interpretiert werden. Hier-
zu können Ausarbeitungen wie in Abschnitt 3.1 genutzt werden, um beteiligte Systeme, Daten und Teil-
prozesse zu identifizieren und in die Lösungsgestaltung aufzunehmen.
DMAF2 – Unterstützung vertikaler Prozesse
: Das Datenmanagement muss die vertikale Informations-
bereitstellung unterstützen, d. h. es muss Daten aus unterschiedlichsten, fachspezifischen Software-
systemen zusammenführen und einem gesamtbetrieblichen FMIS (vgl. Abschnitt 3.4) zur Verfügung
stellen. Hierzu können Ausarbeitungen wie in Abschnitt 3.1 und 3.2 kombiniert genutzt werden, um dazu
notwendige Daten und deren Quellsysteme zu identifizieren und in die detaillierte Lösungsgestaltung
aufzunehmen.
DMAF3 – Reduzierung manueller Aufwände
: Das Datenmanagement soll manuelle Aufwände redu-
zieren mit dem Ziel, sämtliche Schnittstellen prinzipiell zu automatisieren. Das heißt nicht, dass alle
Übertragungsvorgänge ohne Interaktion ablaufen, aber manuelle Aktivitäten wie Wechsel von Daten-
trägern (USB, CD), händische Übertragung von Werten usw. sollen wegfallen. In Einzelfällen kann es
Nutzern überlassen werden, ob sie die Übertragung von Daten über Benutzeroberflächen auslösen.

Schriftenreihe des LfULG, Heft 4/2022 | 111
DMAF4 – Umsetzung Datensouveränität
: Das Datenmanagement muss geeignet sein, Datensouve-
ränität für Landwirtinnen und Landwirte herzustellen. Hierbei kann es Variationen bzw. Abstufungen
geben, d. h. nicht alle Merkmale der Datensouveränität müssen umgesetzt werden (vgl. dazu
Abschnitt 2.3.3).
DMAF5 – Kosteneffizienz digitaler Lösungen
: Landwirtschaftliche Betriebe stehen bereits heute unter
hohem Kostendruck und verfügen nur über einen begrenzten Investitionsrahmen für ergänzende
Technologien. Falls erforderlich, müssen zusätzliche Systeme für Landwirtinnen und Landwirte kosten-
effizient umsetzbar sein. Dies gilt auch für Anforderungen, die an eine betriebliche IT-Infrastruktur ge-
stellt werden.
DMAF6 – Cybersecurity
: Unabhängig von der technischen Umsetzung eines Datenmanagements
muss ein Höchstmaß an Datensicherheit erreicht werden, um gegen verschiedene Arten von Cyber-
angriffen Resilienz aufzuweisen. Dazu gehören u.a. nicht berechtigte Zugriffe auf Daten oder die
Störung von Betriebsabläufen (vgl. dazu u.a. BSI C5).
DMAF7 – Flexibilität
: Das Datenmanagement muss so flexibel gestaltet sein, dass neue Schnittstellen
und Systeme einfach, schnell und kosteneffizient integriert werden können. Das gilt ebenso für Än-
derungen an existierenden Schnittstellen und das Umsetzen individueller Anforderungen.
DMAF8 – Robuster Betrieb
: Das Datenmanagement muss einen robusten Betrieb von landwirtschaft-
lichen Softwaresystemen ermöglichen, damit betriebliche Produktionsprozesse insbesondere in zeit-
kritischen Phasen störungsfrei durchgeführt werden können. Hierbei wird als Vorgabe ein störungsfreier
Betrieb an 365 Tagen vor allem in den Zeiten zwischen 5:00 und 23:00 Uhr formuliert.
DMAF9 – Einfache Bedienbarkeit
: Das Datenmanagement muss so gestaltet sein, dass wesentliche
Funktionen von Anwendern ohne IT-Fachwissen bedient werden können und diese auch in der Lage
sind, einfache Fehlerfälle zu erkennen und zu beheben.
DMAF10 – Performanz
: Das Datenmanagement muss verfügbar und ausreichend performant gestaltet
werden, um die Anforderungen der jeweiligen Fachlösungen in ausreichendem Maße zu erfüllen. Dazu
gehört insbesondere auch die Berücksichtigung der notwendigen Konnektivität aller Teilsysteme, was
bspw. von der verfügbaren Internetanbindung oder Funkkonnektivität abhängt.
DMAF11 – Effiziente Datenverwaltung
: Das Datenmanagement muss die Nutzung und Verwaltung
von betrieblichen Daten für Landwirtinnen und Landwirte möglichst einfach gestalten. Dazu gehört bspw.
ein einfacher Überblick über betriebliche Datenbestände, schnelle und aufwandsarme Zusammen-
führung zur Verarbeitung oder einfache Freigabe für zusätzliche Dienstleistungen.
3.3.3 Fachgespräche mit Softwareanbietern
Im Rahmen der Machbarkeitsstudie wurden sehr viele Aspekte des betrieblichen Datenmanagements und der
Informationsbereitstellung durch ein FMIS betrachtet. Um einerseits Erkenntnisse, Konzeptionen und eigene
Ansätze abzusichern und andererseits ergänzende Anregungen, Ideen und Anforderungen aufzunehmen,
wurden Fachgespräche mit zehn Anbietern verschiedener Softwarelösungen durchgeführt. In diesen wurden
für die Machbarkeitsstudie relevante Themenbereiche besprochen und es wurde dabei auch auf die Rolle der
jeweiligen Softwareangebote eingegangen, da diese die Kernelemente im betrieblichen Datenmanagement
darstellen. Die Ansprechpartner wurden so ausgewählt, dass eine möglichst umfassende Abdeckung der in
Abschnitt 2.2 gezeigten Systemklassen erreicht wurde.

Schriftenreihe des LfULG, Heft 4/2022 | 112
Die Gespräche dauerten je ca. eine Stunde und lieferten jeweils wertvolle Ergänzungen und Einsichten in
die Perspektive von Softwareanbietern. Deren Einbeziehung in die Studie und auch in Folgeaktivitäten ist
von hoher Bedeutung, da sie die Akteure sind, die bisher und zukünftig maßgeblich das betriebliche Daten-
management gestalten oder zumindest mitgestalten.
Die Gespräche wurden als semi-strukturierte Interviews durchgeführt. Dabei gibt es keine Liste konkreter
Fragen, die von den Gesprächspartnern beantwortet werden sollen, sondern eher thematische Fragen, die
eine offene Diskussion erlauben. Gesprächspartner auf Seiten der Studie waren Mitarbeitende des Konsorti-
ums, aber keine Vertreter der Auftraggeber. Für die Gesprächsinhalte wurde Anonymität gegenüber den
Auftraggebern und den Leserinnen und Lesern der Studie zugesichert. Inhalte bzw. wesentliche Erkenntnis-
se aus den Gesprächen werden daher in einer aggregierten Form dargestellt, die keinen Rückschluss auf
Gesprächspartner oder Unternehmen ermöglicht.
In den folgenden Abschnitten stellen wir zunächst kurz die besprochenen Themen und Fragestellungen vor
und fassen darauffolgend Kernaussagen zusammen, die aus unserer Sicht relevante Informationen für diese
Studie geliefert haben. Diese Kernaussagen und weitere Gesprächsinhalte werden über die Darstellung
hinaus in verschiedenen Teilen dieser Studie analysiert und eingebracht.
3.3.3.1 Inhaltliche Gesprächsgestaltung
Die folgende Auflistung stellt kurz die in den Fachgesprächen besprochenen Themen vor.
Beschreibung der eigenen Softwarelösung
Einordnung in die passende(n) Systemklasse(n)
145
und Angabe der wesentlichen Funktionen. Damit sollte
erfasst werden, wie sich die jeweilige Softwarelösung im betrieblichen Kontext und insbesondere zum
betrieblichen Datenmanagement verhält.
Einschätzung der Gesprächspartner zum betrieblichen Datenmanagement
Wie werden Probleme und Herausforderungen wie mangelnde Interoperabilität, fehlende Schnittstellen,
Medienbrüche, manueller Aufwand und Fehleranfälligkeit aus Sicht der Gesprächspartner gesehen und
wie sind deren Erfahrungen mit ihren jeweiligen Kunden?
Was sind nach Ansicht der Gesprächspartner die Ursachen und Gründe für die geschilderten Heraus-
forderungen und deren Auswirkungen?
Mit welchen Lösungsansätzen könnten die Herausforderungen gelöst und die Probleme minimiert
werden? An dieser Stelle wurden noch keine Lösungsvorschläge vorgestellt, die im Rahmen dieser
Studie evaluiert werden, sondern die Gesprächspartner sollten eigene Ansätze formulieren.
Einschätzung der Gesprächspartner zum Thema Datensouveränität
Wie ist die Wahrnehmung des Themas Datensouveränität (s. Abschnitt 2.3.3) bei den Gesprächspartnern,
insbesondere aus den Erfahrungen mit den eigenen Kunden? Wie sehen die Gesprächspartner die
digitale Landwirtschaft hier generell aufgestellt und wie bewerten sie Aktivitäten außerhalb ihres eigenen
Unternehmens?
Wie gehen die Unternehmen der Gesprächspartner selbst mit dem Thema Datensouveränität um und
wie sind die eigenen Softwareangebote technisch aufgebaut und umgesetzt?
145
Den Gesprächspartnern wurde dazu die grafische Darstellung der Systemklassen gezeigt (s. Abschnitt 2.2).

Schriftenreihe des LfULG, Heft 4/2022 | 113
Feedback der Gesprächspartner zu den verschiedenen Datenmanagementvarianten
Wie werden die Varianten bzw. Ansätze für betriebliche Datenmanagementlösungen von den Gesprächs-
partnern hinsichtlich der besprochenen Herausforderungen und Probleme bewertet? Können sie Lösungen
dafür sein?
In welcher Rolle sehen die Gesprächspartner die eigenen Angebote und wie bewerten sie die Möglich-
keit der Einbindung in die verschiedenen Varianten? Welche Variante wären bevorzugt?
Falls es zur Umsetzung eines spezifischen Ansatzes käme: Welche Akteure sollten diesbezügliche
Aktivitäten treiben und steuern?
Diskussion verschiedener Aspekte von Schnittstellen mit Fokus auf die eigenen Angebote
Wie sind die jeweiligen Softwareangebote bereits mit Schnittstellen ausgestattet, wie sind diese gestaltet
und wie ist die Bereitschaft, weitere Schnittstellen zu schaffen oder sich einzubringen?
Im Rahmen der Studie sollen auch Kosten für die Schaffung von Schnittstellen betrachtet werden, was
grundsätzlich sehr schwer einzuschätzen ist, wenn keine konkrete Beschreibung existiert. Trotzdem
wurden die Gesprächspartner um eine ungefähre Einschätzung aus ihrer jeweiligen Erfahrung zu den
Aufwänden gebeten, die für die Schaffung von Schnittstellen zu ihren Systemen notwendig sind.
Es gibt verschiedene Möglichkeiten, die Schaffung weiterer Schnittstellen im Rahmen der eigenen
Lösungen finanziell zu gestalten. Dazu gehören a) Integration in die Kernfunktionalität, d. h. die Land-
wirtinnen und Landwirte und weitere Kunden zahlen mit dem Basispreis für die Schnittstellenfunktion, b)
als zur Basisfunktion zubuchbares, aber kostenpflichtiges Modul und c) als Individualentwicklung, die je-
weils von einem Auftraggeber der Schnittstelle zu finanzieren ist.
Einschätzung der Gesprächspartner zu einem gesamtbetrieblichen FMIS als Dashboard
Hierbei wurden keine konkreten Funktionen oder grafischen Ausgestaltungen gezeigt, sondern das grund-
sätzliche Konzept wurde skizziert und die Einschätzung dazu erfragt. Hierbei muss berücksichtigt werden,
dass den Fragen keine konkrete Konzeption zugrunde gelegt wurde und die Einschätzung der Gesprächs-
partner auf den Schilderungen der Befragenden und der Interpretation aus der eigenen Perspektive beruht.
Sehen die Gesprächspartner ein solches Dashboard, das Daten übergreifend zusammenführt und zu
Kennzahlen aggregiert, als sinnvolles, ergänzendes Angebot oder genügen die aktuell verfügbaren
Funktionen?
Wie ist die Bereitschaft, eigene Softwareangebote an ein solches FMIS anzubinden, um Daten zur dor-
tigen Darstellung und Aufbereitung bereitzustellen?
Falls es zur Umsetzung eines solchen FMIS käme: Welche Akteure wären zur Umsetzung und zum
Betrieb geeignet?
Gesprächsabschluss mit offenen Fragen
Diese waren dafür gedacht, Raum für bisher nicht angesprochene Themen zu bieten, die den Gesprächs-
partnern wichtig erschienen:
Zu den in diesem Gespräch besprochenen Themen: Was sollte aus Sicht der Gesprächspartner auf
keinen Fall passieren?
Gibt es Themen oder Aspekte, die den Gesprächspartnern wichtig sind, die bisher aber nicht besprochen
wurden?

Schriftenreihe des LfULG, Heft 4/2022 | 114
3.3.3.2 Wesentliche Kernaussagen
In diesem Abschnitt fassen wir Erkenntnisse aus den Fachgesprächen zu Kernaussagen zusammen, die aus
unserer Sicht wesentlich im Sinne dieser Studie sind. Wir zitieren dabei keine einzelnen Aussagen, sondern
aggregieren diese zu Kernaussagen, die sich an den für uns relevanten Themenblöcken orientieren. Die
Kernaussagen werden ohne eigene Bewertung wiedergegeben und sollen die Einstellung der Gesprächs-
partner reflektieren. Immer wenn sich widersprechende Einschätzungen abgegeben wurden, werden beide
Seiten aufgeführt. Diese Zusammenfassung darf nicht als repräsentative Umfrage verstanden werden, dazu
war die Anzahl der Gesprächspartner zu gering.
3.3.3.2.1
Beschreibung der eigenen Softwarelösung
Funktionsumfang und Angebote:
Da Gesprächspartner von Unternehmen mit Softwarelösungen aller
Systemklassen beteiligt waren, ergab sich eine hohe Vielfalt an Funktionen und Angeboten. Diese
reichen von spezifischen Fachlösungen (wie Precision Farming) bis hin zu sehr umfassenden Soft-
warelösungen, die eine hohe Anzahl der Systemklassen
146
abdecken. Einige Anbieter verfolgen die Stra-
tegie, zum eigenen Angebot ergänzende Funktionen durch Partner hinzuzufügen. Hierzu werden diese
direkt als Funktion in das eigene System integriert oder als Modul hinzugefügt.
Trend zur Cloud: Für fast alle lässt sich festhalten, dass die eigenen Angebote als cloud- bzw. internet-
basierte Lösungen aufgebaut sind oder der Trend klar in diese Richtung geht. Die meisten Anbieter mit
cloud- bzw. internetbasierten Softwarelösungen nutzen dazu IT-Ressourcen, die ausschließlich in
Deutschland betrieben werden und dort klar lokalisiert bzw. einem Standort zugeordnet werden können.
In einigen Fällen werden eigene Rechenzentren betrieben, um die maximale Kontrolle über die IT-Res-
sourcen zu behalten.
Einschätzung zu lokalem Betrieb: Neben cloud- bzw. internetbasierten Angebote existieren weiterhin
Softwarelösungen, die als Desktopversionen betrieben werden können. Es gibt auch Ansätze und Ideen,
die Datenhaltung in die Betriebe zu verlagern, was aber aus technischen und organisatorischen Gründen
kritisch gesehen wird. Die kritische Einschätzung liegt i.W. in der Erwartung, dass zukünftig Systeme
noch stärker vernetzt sein werden, was durch den Betrieb in den landwirtschaftlichen Betrieben selbst
erschwert wird. Weiter wäre so eine schnelle Unterstützung in Problemfällen erschwert und es ist auch
von bedeutend höheren Kosten für Kauf und Betrieb von Software auszugehen.
Ackerschlagkartei als zentrales System: Die Ackerschlagkartei als Softwaresystem wurde mehrfach als
Zentrum der betrieblichen Softwaresysteme formuliert, da sie Kernfunktionen übernimmt und anbietet.
Weitere Funktionen könnten dann als Ergänzungen der Ackerschlagkartei als Kernsystem hinzugefügt
werden. Damit übernimmt sie aus Sicht einiger Gesprächspartner auch die Funktion eines betrieblichen
Datenhubs.
146
Vgl. dazu 2.2

Schriftenreihe des LfULG, Heft 4/2022 | 115
3.3.3.2.2
Herausforderungen und Probleme im betrieblichen Datenmanagement
Die Gesprächspartner konnten die formulierten Herausforderungen und Probleme im betrieblichen Daten-
management aus Kundensicht nachvollziehen, insbesondere negative Erfahrungen in der täglichen Praxis.
Umgekehrt merkten sie aber auch an, dass Ursachen dafür auf Kundenseite existieren oder dass die Wahr-
nehmung häufig schlechter sei als in der Realität, da viele Probleme und Anforderungen bereits gut gelöst
seien. Insgesamt sind die Ergebnisse der Gespräche zu den Herausforderungen im Datenmanagement sehr
vielschichtig und gemischt. Wir strukturieren daher die Kernaussagen in thematische Teilblöcke.
Rolle und Wirken der Softwareanbieter
IT-Kompetenz der Unternehmen
: Es wurde angeführt, dass traditionelle Landtechnikunternehmen
zwar gut in der Landtechnik seien, aber noch nicht über ausreichende IT-Kompetenz verfügten und sich
stärker zu Anbietern digitaler Dienstleistungen wandeln müssten. So seien Maschinen häufig noch nicht
gut in eigene Softwarelösungen einzubinden und gegebene Leistungsversprechen nicht eingelöst.
Insgesamt sei der Markt landwirtschaftlicher Software als Ganzes auch noch relativ jung und eine
höhere technische Reife müsse erst noch erreicht werden.
Schutz des eigenen Geschäftsmodells: In einigen Fällen wurde die Einschätzung geäußert, dass
Maschinen- oder Softwareanbieter die Strategie verfolgen, betriebliche Daten möglichst im eigenen
Kontext zu behalten, um eigene Geschäftsbereiche zu schützen und Einblicke in eigene Technologien
zu verhindern. Demzufolge seien Anbieter nicht bereit, umfassende und offene Schnittstellen zu den
eigenen Systemen zu schaffen. Gesprächspartner forderten hier, dass die individuellen Interessen der
Unternehmen gegenüber den Anforderungen der Landwirtinnen und Landwirte zurückgestellt werden.
So seien Probleme technisch-fachlich zu lösen – es scheitert eher an politischen Gründen. In
Einzelfällen wurde angeführt, dass die Haltung von Daten in der eigenen Software als ein Instrument
der Kundenbindung gesehen wird (Vendor Lock-In).
Fokus auf eigene Kernfunktionen: Gesprächspartner äußerten, dass einzelne Softwareangebote zu
stark auf die jeweilig eigenen Funktionen fokussieren und Prozesse aus dem umgebenden Kontext
vernachlässigen. Insgesamt wurde kritisch eingeschätzt, eine Vielzahl von verschiedenen Systemen für
verschiedene Prozesse in Einklang bringen zu können, während Systeme, die viele Funktionen
abdecken, zielführender sein können. So wurde angeführt, dass Landwirtinnen und Landwirte prozess-
bezogen denken, bspw. beim Düngeprozess. Hier müssten nun Fachsysteme für Maschinen, Dünge-
mittel, Bodenbeprobung, Bedarfsermittlung, Applikationskartenerstellung usw. einbezogen werden, was
zu einem schwer zu gestaltenden Puzzle an Softwaresystemen führe.
Technische, fachliche und organisatorische Herausforderungen und Ursachen
Komplexität landwirtschaftlicher Betriebe:
Eine wesentliche Ursache für die Herausforderungen im
betrieblichen Datenmanagement wird in der Komplexität landwirtschaftlicher Betriebe und deren
Produktions- und Entscheidungsprozessen gesehen, woran sich auch zukünftig nichts ändern wird. Für
die Digitalisierung bringt das ganz verschiedene Schwierigkeiten mit sich: Es muss die hohe Varianten-
vielfalt in Daten und Prozessen abgebildet werden; es gibt Bedarf und Angebot an sehr vielen verschie-
denen Schnittstellen; eine durchgängige Standardisierung wird als nicht umsetzbar eingeschätzt uvm.
Dazu kommt erschwerend die Diversität existierender Systeme wie bspw. behördlicher Schnittstellen auf
föderaler Ebene, wo sich nicht nur die Dateninhalte unterscheiden, sondern auch die Prozesse der
Schnittstellen selbst (so bietet ein Bundesland eine digitale Schnittstelle, während ein anderes für den
gleichen Prozess ein PDF zum Download anbietet, das ausgefüllt zurückgefaxt werden muss).

Schriftenreihe des LfULG, Heft 4/2022 | 116
Diverse Systemlandschaft:
Als sehr herausfordernd wurde die sehr aufwändige Abstimmung zwischen
den vielen Anbietern von Maschinen und Softwaresystemen eingeschätzt. Dies ist an sich ein komplexes
Unterfangen, das von keinem zentralen Akteur gesteuert wird und zusätzlich durch verschiedene, z.T.
widerstrebende Geschäftsinteressen von Maschinen- und Softwareanbietern erschwert bis boykottiert wird.
Beispielhaft aufgeführt wurden verschiedene Lager um aktuell am Markt existierende oder im Aufbau
befindliche Angebote und Initiativen wie ISOBUS/ISOXML mit EFDI, agrirouter und DataConnect. In dem
Kontext wurde auch angeführt, dass sich insbesondere größere Anbieter nicht von anderen Technologie-
anbietern abhängig machen wollen und daher die eigenen Entwicklungen in den Mittelpunkt stellen. Die
Gesprächspartner schätzten die Lage differenziert ein: Einerseits wollen große Unternehmen die eigene
Entwicklungsgeschwindigkeit unter Kontrolle behalten, andererseits wollen sich kleinere Anbieter nicht an die
großen anbinden, da sie sich nicht auf Augenhöhe sehen und so Nachteile befürchten.
Standardisierung:
Die Standardisierung von Daten, Schnittstellen und Prozessen wird als zwiespältig
eingeschätzt. Zwar würde eine durchgängige Standardisierung die Herausforderungen geeignet adres-
sieren, doch sei dieser Zustand nur sehr schwer bis gar nicht herstellbar. Es existierten zu viele Stan-
dards, Anbieter setzten vereinzelt zu stark auf eigene Entwicklungen und Standards und selbst wenn es
Standards gebe, würden diese häufig verschieden interpretiert (bspw. ISOXML). Es fehle ein Standard,
der die gesamte Breite der betrieblichen Prozesse abdeckt und es sei fraglich, ob sich überhaupt alle
Prozesse standardisieren lassen (bspw. bei verschiedenen Methoden zur Buchhaltung). In Einzelfällen
wurde der Gesetzgeber als der Akteur gesehen, der die Standardisierung vorantreiben sollte, wogegen
sich allerdings mehrere Gesprächspartner aussprachen, da Behörden für die Anforderungen im Markt zu
langsam reagierten. Die eigene Entwicklung werde als immer schneller eingeschätzt und daher würden
sich die Akteure immer nur auf einen kleinsten gemeinsamen Nenner einigen. Ansätze wie die von
AgGateway zur Standardisierung von Schnittstellen seien zwar wertvoll, aber vermutlich zu sehr auf den
US-Markt zugeschnitten. Dort sind die betrieblichen Abläufe aber anders als in Deutschland.
Rolle und Wirken von Landwirten
Professionalisierung der Nutzer:
Die Gesprächspartner sehen auch die Nutzer der verschiedenen
Softwarelösungen in der Pflicht, sich intensiver mit der Digitalisierung auseinanderzusetzen und die
Professionalisierung beim Einsatz digitaler Maschinen und Systeme vorantreiben. Praxisprobleme ent-
stünden auch durch Fehler bei der Dateneingabe und -pflege oder beim Einsatz ungeeigneter Systeme,
was insbesondere bei der Kombination von mehreren Systemen zu Problemen führe.
Umgang mit Digitalisierung: Die Gesprächspartner führten aber auch an, dass viele Praxisprobleme und
daraus folgende Mehraufwände zu Frustration und Ablehnung digitaler Systeme bei Landwirtinnen und
Landwirten führten und häufig der Nutzen nicht ausreichend sichtbar werde. Ablehnung entstehe nach
Ansicht der Gesprächspartner aber auch daraus, dass viele Hintergründe unter Landwirtinnen und Land-
wirten nicht gut diskutiert und verstanden sind. So fehle häufig das Verständnis für Datenmanagement
insgesamt und für die Bedeutung von Datensouveränität, wobei es hier ein starkes Gefälle in der Alters-
struktur gebe und jüngere Landwirtinnen und Landwirte sich eher gut mit der Thematik auskennen würden.
Trotzdem führten Vorbehalte dazu, dass digitale Technologien und Systeme nicht so eingesetzt werden,
wie es möglich wäre. Insbesondere die Sorge vor illegitimen Zugriffen durch den Staat (Kontrolle) oder
durch große Unternehmen (hin zum „Landwirtschafts-Google“) wird als Hemmnis gesehen.

Schriftenreihe des LfULG, Heft 4/2022 | 117
Verhandlungsposition von Landwirtinnen und Landwirten: Einige Gesprächspartner sahen Landwirtinnen
und Landwirte nicht gut aufgestellt als Verhandlungspartner auf Augenhöhe mit Anbietern von Maschinen
und Softwarelösungen. Hierbei käme es noch zu häufig dazu, dass sich Betriebe mit unbefriedigenden
IST-Situationen arrangierten. Hier gab es aber auch Stimmen, die anmerkten, dass selbst Pilotbetriebe in
Praxisproblemen erstickten und so wenig Zeit aufbringen könnten, entsprechenden Druck auf Anbieter
auszuüben.
3.3.3.2.3
Mögliche Lösungen für die Herausforderungen im betrieblichen Datenmanagement
Ausbau von Standards:
Auch wenn die Umsetzung und Etablierung branchenweit akzeptierter
Standards als schwer herzustellen eingeschätzt wurde, sehen die Gesprächspartner in Standards für
Schnittstellen und Prozesse eine Chance zur Verbesserung der aktuellen Situation. Dabei sollte statt dem
Aufbau neuer Standards mehr in den Ausbau bereits existierender investiert werden (bspw. ISOXML).
Initiativen wie AgGateway
147
werden grundsätzlich positiv gesehen, hier wurde aber auch vermutet, dass
diese zu sehr auf den US-Markt abzielen, wo sich die betrieblichen Abläufe und Gegebenheiten zum Teil
stark von denen in Deutschland unterscheiden.
Datenhubs als Datenmanagement:
Ein Datenhub als Lösungsansatz wurde differenziert eingeschätzt,
wobei vor allem diejenigen Gesprächspartner diesen Ansatz unterstützen, die ihre eigene Anwendung als
einen Datenhub identifizieren. Für einen eigenständigen, neutralen Datenhub werden zwar ein Interesse
seitens der Landwirtinnen und Landwirte und auch Vorteile für diese angenommen, die Unterstützung auf
Seiten der Gesprächspartner war bis auf wenige Ausnahmen insgesamt aber eher zurückhaltend. Das lag
mit daran, dass dem Aufbau eines solchen Hubs aktuell wenig Chancen auf Erfolg im Markt zugemessen
werden.
Stärkung der Position als Kunde:
Landwirtinnen und Landwirte müssten sich nach Ansicht mehrerer
Gesprächspartner stärker gegenüber Anbietern von Softwarelösungen positionieren und auf die Ein-
haltung gegebener konkreter Leistungsversprechen bestehen. Zu häufig würden sich Betriebe mit einer
unbefriedigenden IST-Situation arrangieren, auch weil ihnen die Zeit fehle, sich damit tiefer auseinander-
zusetzen. Ergänzend zu dieser Einschätzung sollten sich Landwirtinnen und Landwirte stärker mit der Er-
neuerung ihrer Softwarelösungen auseinandersetzen. So sollte insbesondere bei Neuanschaffungen
darauf geachtet werden, dass diese über die gewünschte Interoperabilität verfügen.
Vorantreiben von Lösungen:
Das Vorantreiben von Lösungen egal welcher Art müsse intensiviert
werden und dabei müsse global gedacht werden. Lösungen mit nur regionaler Wirkung werden zu keiner
Verbesserung führen. In Deutschland sollte auf föderaler Ebene harmonisiert werden, besser wäre aber
ein europäischer Ansatz. Es fehle noch ein Akteur oder mehrere, der oder die solche Aktivitäten
vorantreiben.
3.3.3.2.4
Einschätzung der Gesprächspartner zum Thema Datensouveränität
Datensouveränität beim Landwirt:
Es wird von allen Anbietern anerkannt und unterstützt, dass die
Datensouveränität bei den Landwirtinnen und Landwirten liegen soll und die eigenen Angebote auch
dementsprechend gestaltet werden. Zwar formulierten einige Gesprächspartner ein Interesse des
Unternehmens an spezifischen betrieblichen Daten, diese würden aber nicht ohne Zustimmung der
Dateninhaber genutzt werden.
147
https://aggateway.org/

Schriftenreihe des LfULG, Heft 4/2022 | 118
Transparenz bei Datennutzung:
Kunden sollten sich mit den Hintergründen kostenloser Angebote an
Softwarelösungen auseinandersetzen, da hier immer strategische oder geschäftliche Gründe der Anbieter
dahinter stünden. Konkret sahen Gesprächspartner die Gefahr, dass durch die kostenlose Nutzung von
Angeboten in die umfangreiche Nutzung eigener Datenbestände eingewilligt wird, ohne dass Kunden wie
Landwirte die Auswirkungen absehen könnten. Als Beispiel wurde genannt, dass etwa in England alle
Anbieter von Agrarsoftware zu Betriebsmittellieferanten gehören.
Daten als Erlösmodell:
Es gab aber auch Gesprächspartner, die in der Vermarktung eigener Daten
eine Chance für Landwirtinnen und Landwirte sehen, weitere Erlöse zu erzielen. Dazu wird z.T. geplant,
die eigenen Angebote so weiterzuentwickeln, dass sie Erlösmodelle für Landwirtinnen und Landwirte
enthalten sollen.
Cloudbasierte Systeme:
Der Begriff „Cloud“ bzw. „cloudbasiertes System“ wird von den Gesprächs-
partnern als problematisch eingeschätzt, da er suggeriere, dass Daten und Systeme „irgendwo auf der
Welt“ gehalten und betrieben werden. In den meisten Fällen sind die IT-Ressourcen allerdings eindeutig
lokalisierbar und regional eingegrenzt. Die Gesprächspartner befürchteten, dass durch die Verwendung
von Begrifflichkeiten wie „Cloud“ falsche Sorgen und Ängste bei Kunden entstehen könnten. Im Zweifel
sollten sich Kunden genaue Auskunft darüber erbeten, wo die IT-Ressourcen betrieben werden.
3.3.3.2.5
Feedback der Gesprächspartner zu den verschiedenen Datenmanagementvarianten
Varianten des Datenmanagements
: Ein klarer Trend bei der Einschätzung zu den Varianten bilaterale
Schnittstellen, Datenrouter, Datenhub und hybrider Ansatz war in den Gesprächen nicht zu erkennen.
Bilaterale Schnittstellen
wurden prinzipiell als gut funktionierend und etabliert eingestuft, aber auch als
aufwändig und komplex. So sei die bilaterale Abstimmung ein aufwändiger Prozess, der in einzelnen
Fällen auch immer wieder gescheitert sei und sogar zu gerichtlicher Klärung führen könne. Weiter steige
mit der Anzahl bilateraler Schnittstellen die Komplexität des Gesamtsystems, in dem ohnehin schon sehr
viele verschiedene Systeme existieren, die dann mit sehr hoher Variantenvielfalt untereinander ver-
bunden werden müssten. In der Konsequenz seien bilaterale Schnittstellen gute Lösungen für einzelne
Anbindungen, wurden aber nicht als alleinige Lösungsoption betrachtet.
Datenrouter
wurden sehr differenziert einschätzt. Einerseits wird der Ansatz als technisch sinnvoll be-
trachtet, andererseits werden fachlich-organisatorische oder unternehmenspolitische Hürden gesehen:
Unternehmen wollen sich nicht von einem Datenrouter abhängig machen und fürchten um den Verlust
der Eigenständigkeit, die letztlich die eigene Innovationskraft bestimmt. Der Verlust der Eigenständigkeit
wird so begründet, dass man dem Standard und den Vorgaben des oder der Router folgen müsste. Teil-
weise werden die eigenen Systeme in der Rolle eines Datenrouters gesehen.
Ein Datenhub
wurde zwar häufiger als aussichtsreicher Lösungsansatz insbesondere in cloudbasierten
Architekturen genannt, dann aber immer mit dem eigenen Softwareangebot als einem solchen Datenhub.
Grundsätzlich wird die Zusammenführung betrieblicher Daten an einem Ort positiv eingeschätzt. Einige
Gesprächspartner befürchten in dem Zusammenhang aber, dass so ein Monopol des Datenhubbetreibers
und damit eine Abhängigkeit von diesem entstehen könnte, noch stärker als bei einem Datenrouter.
Kritische Stimmen wiesen darauf hin, dass jeder Anbieter der Betreiber eines solchen Datenhubs sein
möchte oder dass ein cloudbasierter Hub zu anfällig für Hackerangriffe sein könnte. Weiter sei die tech-
nische Umsetzung eine enorme Herausforderung.

Schriftenreihe des LfULG, Heft 4/2022 | 119
3.3.3.2.6
Diskussion verschiedener Aspekte von Schnittstellen mit Fokus auf die eigenen
Angebote
Schaffung von Schnittstellen:
Grundsätzlich zeigten alle Gesprächspartner die Bereitschaft, Schnitt-
stellen zu den eigenen Systemen zu schaffen, sofern das im Sinne der Kunden ist. Nur in wenigen Fällen
wurde geäußert, dass auch das Interesse des eigenen Unternehmens berücksichtigt werden müsse.
Häufiger geäußert wurde, dass andere Unternehmen aufgrund eigener Interessen zurückhaltend seien
oder ein Geschäftsmodell darin sähen, sich die Schaffung neuer Schnittstellen vergüten zu lassen und
Preise höher anzusetzen als notwendig.
Prozesse über Schnittstellen:
Schnittstellen stellen nach Aussage der Gesprächspartner nicht immer
nur einfache Zugriffsmöglichkeiten auf einzelne Datenbestände dar, sondern sollten auch hinsichtlich
der Integration in Prozesse betrachtet werden, etwa bei der Auslösung einer Wägung über eine Schnitt-
stelle.
Kosten von Schnittstellen:
Aufwände für die Schaffung von Schnittstellen wurden sehr divers
beziffert. Generell wird die Abschätzbarkeit von Aufwänden für komplexe Anforderungen ohne konkrete
Spezifikation als nicht möglich gesehen, basierend auf Erfahrungswerten wurden aber verschiedene
Aufwandsspannen genannt. Während sehr einfache Schnittstellen ab ein oder zwei Personentagen
Aufwand umgesetzt werden könnten, seien komplexe Ergänzungen und Integrationen nach oben
praktisch offen. Die Einschätzungen von Anbietern umfassender Softwaresysteme deuten eher darauf
hin, dass Ergänzungen in diesen Systemen mit deutlich höheren Aufwänden verbunden sind, typischer-
weise mit mehr als einem Personenmonat Aufwand. Ein Problem dabei sei immer, dass auch Auf-
wände für die Pflege der Schnittstellen zu berücksichtigen seien und diese häufig vernachlässigt
würden, was zu Problemen bei Änderungen auf einer Seite führe.
Finanzierung von Schnittstellen:
Bei der Umsetzung und Finanzierung von neuen Schnittstellen ergibt
sich ein differenziertes Bild. Während manche Anbieter bei ausreichender Nachfrage von Kunden neue
Schnittstellen in das Basisprodukt übernehmen, finanzieren andere Anbieter solche Schnittstellen im
Rahmen kostenpflichtiger Module bis neue Schnittstellen als Individualentwicklung angeboten werden.
3.3.3.2.7
Einschätzung der Gesprächspartner zu einem gesamtbetrieblichen FMIS als
Dashboard
Bedarf an einem FMIS:
Auch die Einschätzung des Bedarfs an einem gesamtbetrieblichen FMIS, das
Daten aus verschiedenen weiteren Softwaresystemen aggregiert und im Rahmen eines Dashboards
darstellt, wurde verschieden eingeschätzt. Grundsätzlich wurde der Bedarf an vergleichbaren Funktionen
als hoch bis sehr hoch angenommen, wobei stark nach Betriebsstruktur und Nutzerrolle unterschieden
wurde. Einzelne Gesprächspartner verneinten den Bedarf über existierende Softwareangebote hinaus
bzw. würden diese eher hin zu einem solchen Funktionsangebot erweitern.
Eigenständige Betriebszweige
: Für große Betriebe wird angenommen, dass diese häufig stark in ein-
zelne Betriebszweige unterteilt sind und diese jeweils nur auf die für sie relevanten Informationen zu-
greifen würden, d. h. dass ein betriebsübergreifendes FMIS oder Dashboard nicht unbedingt sinnvoll
oder nutzenstiftend gegenüber betriebszweigspezifischen, bereits vorhandenen Softwaresystemen
sei. Diese Einschätzung wurde aber nicht von allen Gesprächspartnern geteilt. Insbesondere der Be-
darf der Betriebsleitenden oder der Besitzenden an einem übergreifenden Tool wurde hier als
Gegenposition genannt.

Schriftenreihe des LfULG, Heft 4/2022 | 120
Nutzerrollen:
Auch wurde betont, dass die Vielzahl an Informationen nicht für alle Nutzerrollen in
Betrieben relevant ist bzw. diese nicht auf alle Informationen wie finanzielle Daten Zugriff haben
sollten. In dem Kontext wurde auch die Sorge geäußert, dass ein betriebsübergreifendes Tool zu
komplex sein könne, um realistisch zu sein. Hier wird auch die Hürde gesehen, dass nicht alle
Betriebe einheitliche Abläufe wie bspw. Abrechnungsmethoden haben oder sogar sehr diverse
Prozesse haben. Ein universelles Tool, das alles abbilden kann, wurde vereinzelt als unrealistisch
eingeschätzt. Dies liegt insbesondere an der Komplexität der landwirtschaftlichen Prozesse und der
Diversität existierender Softwaresysteme, wobei hier neben fachlich-technischen Hürden auch die
Schwierigkeit gesehen wird, dass sich Wettbewerber untereinander abstimmen und einigen müssten.
Schaffung von Schnittstellen:
Prinzipiell zeigten alle Gesprächspartner die Bereitschaft, Schnittstellen
zu Daten für ein solches FMIS oder Dashboard bereitzustellen, wenn dies im Interesse ihrer jeweiligen
Kunden wäre. Es wurde in Einzelfällen aber auch deutlich, dass die eigenen geschäftlichen Interessen
dadurch nicht bedroht sein dürfen. Zur Umsetzung hilfreich wäre in einem solchen Fall der Aufbau von
Vertrauen durch die Betreiber und Anbieter eines solchen Systems.
Geeignete Betreiber:
Bei der Frage nach geeigneten Betreibern gab es ein gemischtes Meinungsbild.
Genannt wurden anbieterneutrale Verbände und Organisationen wie die DLG. Andere Gesprächspartner
sahen in der Rolle aber auch privatwirtschaftliche Betreiber, da Wettbewerb die Qualität der Angebote
steigere. Einzig Behörden und staatliche Stellen sollten keine Betreiberrolle übernehmen, auch weil hier
zu große Vorbehalte der Landwirtinnen und Landwirte zu erwarten seien.
3.3.3.2.8
Gesprächsabschluss mit offenen Fragen
Rolle von Behörden:
Auf die Frage, was keinesfalls passieren darf, wurde häufig die Beteiligung von
Behörden und staatlichen Stellen genannt bzw. darauf hingewiesen, dass diese von Landwirtinnen und
Landwirten abgelehnt wird. Behörden sollten nicht im privatwirtschaftlichen Raum aktiv werden und sich
auf die eigenen Systeme und Schnittstellen fokussieren. Vielmehr wurden staatliche Stellen in der Rolle
gesehen, Leitlinien zu definieren, Impulse zu setzen und eigene Angebote wie bspw. Stammdaten zu
verbessern (ein Beispiel ist die Harmonisierung von Stammdaten). Landwirtinnen und Landwirte würden
darüber hinaus Portale von Hoheitsträgern meiden, da hier stets die Sorge vor zu viel und falscher
Kontrolle eine Rolle spielen würde.
Digitalisierung in der Landwirtschaft:
Die Digitalisierung hat nach Ansicht einiger Gesprächspartner
keinen guten Ruf in der Landwirtschaft. Zwar gebe es bereits umfassende Angebote, die auch bei der
Vereinfachung von täglichen Arbeiten helfen, insgesamt aber noch viele Praxisprobleme und negative
Schlagzeilen aus anderen Branchen. Unter zunehmendem Digitalisierungsdruck müsse hier mehr ge-
leistet werden, um Landwirtinnen und Landwirten echte und einfache Lösungen zu bieten, die einen
robusten Einsatz in der Praxis ermöglichen. Die Landwirtschaft sei sehr komplex und werde es auch
bleiben, sodass ein digitaler Vollausbau aktuell unrealistisch sei. Besser wäre hier ein langsames
Wachsen um neue Funktionen.
3.3.4 Lösungsansätze für ein betriebliches Datenmanagement
Nach der konzeptionellen Vorbereitung möglicher Lösungskonzepte in Abschnitt 3.3.1, der Herausarbeitung
von Anforderungen in Abschnitt 3.3.2 und den Erkenntnissen aus den Fachgesprächen mit Anbietern (Ab-
schnitt 3.3.3) werden in diesem Abschnitt mögliche Gestaltungsoptionen für ein betriebliches Datenma-
nagement herausgearbeitet. Das Ziel ist dabei nicht, eine konkrete Spezifikation zur Umsetzung zu erstellen,
sondern vielmehr mögliche geeignete Varianten zu identifizieren und miteinander in Vergleich zu setzen. Die
Ergebnisse sollen dazu genutzt werden können, weitere Aktivitäten bzgl. der Verbesserung des betrieblichen
Datenmanagements zu unterstützen.

Schriftenreihe des LfULG, Heft 4/2022 | 121
Basierend auf den bisherigen Studienergebnissen und unserer Einschätzung kristallisierte sich keine eindeutig
zu bevorzugende Variante für ein betriebliches Datenmanagement heraus. Es konnte nicht eindeutig festgestellt
werden, dass im aktuellen IST-Stand eine konkrete Komponente, also ein spezifisches Datenmanagementsys-
tem, fehlt, vielmehr sind die aktuell verfügbaren Softwaresysteme und Teilbereiche noch nicht ausreichend
aufeinander oder auf die übergreifenden, prozessbezogenen Anforderungen abgestimmt. So wird bspw. ein
Datenhub oder ein Datenrouter keine Verbesserung bringen, wenn die Quellsysteme nicht über entsprechende
Schnittstellen und Integration übergreifender Prozesse verfügen. Die in dieser Studie zu stellende Frage lautet
also weniger, wie ein zu entwickelndes System aussehen muss, sondern vielmehr, was die tatsächlichen Bedar-
fe sind und ob man dafür überhaupt ein eigenständiges, spezifisches Datenmanagementsystem benötigt.
Ein weiterer kritischer Punkt ist die bereits vielfach dargestellte und diskutierte Komplexität betrieblicher Pro-
zesse und damit auch die Komplexität eines betrieblichen Datenmanagements. Anforderungen an ein gesamt-
betriebliches Datenmanagement sind aktuell nicht in vollem Umfang erfasst und es ist fraglich, ob ein Daten-
managementkonzept absehbar alle betrieblichen Prozesse abdecken kann. In den Fachgesprächen wurden
zudem vielfach politische und strategische Hemmnisse zum Ausbau des Datenmanagements genannt, die
zusätzlich zur technisch-organisatorischen Komplexität die Lösungsgestaltung erschweren. An der Stelle muss
auch die Frage gestellt werden, ob diese nicht sogar schwerer wiegen als die technisch-fachliche Gestaltung
und deshalb mindestens gleichgewichtig adressiert werden sollten. Während dieser Abschnitt vorwiegend
technische Lösungskonzepte diskutiert, werden organisatorische Ansätze zur Verbesserung des Datenmana-
gements in Abschnitt 3.5 abgeleitet und zusammengefasst, Abschnitt 3.6 formuliert übergreifende Handlun-
gsempfehlungen hierzu.
3.3.4.1 Eingrenzung des Lösungsraums
Im Verlauf der Machbarkeitsstudie wurden mehrere Ansätze, Aktivitäten und Projekte (vgl. dazu Abschnitt 2.2.2)
berücksichtigt, d. h. analysiert und auf Eignung hinsichtlich des Einsatzes in einem betrieblichen Datenmanage-
ment bewertet. Allein die vergleichsweise große Anzahl an Forschungsprojekten und privatwirtschaftlichen Akti-
vitäten im Kontext der gegebenen Problemstellung zeugt von einer sehr hohen Relevanz des Themas, deutet
aber auch darauf hin, dass mögliche Lösungsansätze nicht eindeutig und schnelle Ergebnisse nicht absehbar
sind. Zudem unterscheiden sich die Aktivitäten durch eigene, spezifische Schwerpunkte.
Forschungsprojekte
Forschungsprojekte und Aktivitäten wie ATLAS
148
, Demeter
149
und International Data Spaces
150
entwickeln
eher Ergebnisse im Rahmen der Infrastruktur, ohne spezifische Datenmanagementlösungen zu konzipieren,
zumindest was die Speicherung von Daten angeht. Bei anderen Forschungsprojekten sind keine aktuellen
Folgeaktivitäten bekannt (SDSD und ODiL), während weitere Projekte wie Agri-Gaia noch in einer zu frühen
Phase sind, um schon konkrete Ergebnisse erzielt zu haben, oder die Entwicklung konkreter Produkte einen
eher langfristigen Zeithorizont aufweist (bspw. COGNAC mit einem Datenhub für digitale Zwillinge). Im Er-
gebnis bleibt für Forschungsprojekte festzuhalten, dass diese interessante und relevante Ansätze für das
betriebliche Datenmanagement untersuchen, aber keine aktuell verfügbaren, alleinstehenden Lösungen
generieren, die im Rahmen dieser Studie als unmittelbarer Lösungsansatz genutzt werden können.
148
https://www.atlas-h2020.eu/
149
https://h2020-demeter.eu/
150
https://internationaldataspaces.org/

Schriftenreihe des LfULG, Heft 4/2022 | 122
Eigenentwicklungen
Ebenfalls berücksichtigt und diskutiert wurden Eigenentwicklungen individueller Betriebe unter Zuhilfenahme
existierender Technologien oder direkt einsetzbarer Softwarekomponenten. Hierzu kommt prinzipiell eine
große Bandbreite verfügbarer Lösungen oder Technologien in Frage. Dazu gehören u.a.:
Enterprise Service Bus als Kommunikationsinfrastruktur zwischen Softwarelösungen
FIWARE als Rahmenframework zur Umsetzung einer digitalen Plattform
Safe Feature Manipulation Engine als Datendrehscheibe mit Konvertierungsfunktion
Ohne an dieser Stelle bereits auf die konkrete Spezifikation einer solchen Lösung einzugehen, muss festge-
halten werden, dass die Umsetzung eines betrieblichen Datenmanagements in Eigenentwicklung aus unserer
Sicht keine realistische Option darstellt. Die Aufwände für Konzeption, Umsetzung, Betrieb und nachfolgende
Pflege der Softwarekomponenten wären sehr hoch und wären für einzelne, auch große Betriebe oder selbst
für einen kleinen Verbund weniger Betriebe nicht verhältnismäßig. Zwar könnten einige wenige Funktionen
eines betrieblichen Datenmanagements leichtgewichtig und kostengünstig umgesetzt werden, doch würde
das keinen wesentlichen Ausbau des IST-Standes mit sich bringen. Grundlegende Lösungen, die die formu-
lierten Anforderungen erfüllen sollen, erfordern tendenziell eine große Anzahl finanzierender Betriebe. Das
kann bspw. über ein Genossenschaftsmodell umgesetzt werden; vgl. dazu SEGES in Dänemark mit 30.000
Eigentümern, wo das Tool Mark Online aufgebaut wurde.
Eine Bezifferung der Aufwände für die Schaffung eines Datenmanagementsystems ist ohne dokumentierte
Spezifikation oder ein Lastenheft nicht seriös einzuschätzen. Aus den Erfahrungen vergangener Projekte
folgt, dass Kosten für komplexe Softwareprojekte regelmäßig unterschätzt werden. Im Kontext des betriebli-
chen Datenmanagements muss berücksichtigt werden, dass zusätzlich mit erheblichen Aufwänden für Koor-
dination und Abstimmungen gerechnet werden muss, da eine Vielzahl an Interessensvertretern eingebunden
werden muss, darunter insbesondere auch die Anbieter von Softwarelösungen, die in das Datenmanagement
integriert werden sollen.
Einbeziehung führender Systeme als Komponenten des Datenmanagements
In den Fachgesprächen wurden mehrmals existierende Softwarelösungen als Datenhub eingeschätzt bzw. es
wurde gesagt, dass diese die Rolle übernehmen könnten. Aus konzeptioneller Sicht spricht nichts gegen
diese Einbindung von Softwarelösungen – es bestehen sogar Vorteile. Da Datenhubs grundsätzlich auch die
Funktion eines Datenrouters erfüllen, können existierende Softwarelösungen also eine aktive Rolle im betrieb-
lichen Datenmanagement übernehmen. Voraussetzung für eine solche Ausgestaltung ist aus unserer Sicht,
dass die Anforderungen an ein betriebliches Datenmanagement berücksichtigt werden und insbesondere
Zugänge zu den Datenbeständen von Landwirtinnen und Landwirten diskriminierungsfrei für weitere Drittan-
bieter zur Erbringung von Dienstleistungen für die Landwirtinnen und Landwirte möglich sind. Für eine solche
Lösung spricht jedenfalls, dass keine Aufwände für ein zusätzliches Softwaresystem entstehen. Gegen eine
solche Lösung spricht, dass dadurch Abhängigkeiten von einzelnen Softwareanbietern entstehen, die ggf. zu
Konflikten führen oder von vornherein verhindern, dass Anbieter bereit sind, sich anzubinden. Wie sich solche
führenden Systeme nun etablieren, hängt letztlich von den jeweiligen Strategien und den übrigen Marktteil-
nehmern ab. Anbieter verfolgen unterschiedliche Ansätze: Manche bieten nur eigene Funktionen, andere
binden Partner unter eigenem Namen ein und wieder andere verstehen sich als offene Ökosysteme.

image
Schriftenreihe des LfULG, Heft 4/2022 | 123
Hybrider Ansatz
Hinsichtlich einer gesamtbetrieblichen Lösung stellt sich die Frage, ob es eine Lösung geben kann, die alle
betrieblichen Anforderungen erfüllt und dabei insbesondere für alle Betriebszweige nutzbar ist. Eine solche Lö-
sung ist nach den bisherigen Erkenntnissen keine realistische Option und wenn überhaupt, dann nur mit unver-
hältnismäßig großem Aufwand realisierbar. Es erscheint sinnvoller, für betriebliche Teilbereiche oder auch Teil-
prozesse jeweils individuelle Formen eines betrieblichen Datenmanagements zu etablieren, um die jeweiligen
Bedarfe abzudecken. Dazu können die in dieser Studie vorgestellten Konzepte und entwickelten Anforderungen
genutzt werden, um entsprechende Lösungen zu spezifizieren. Wichtig ist dabei, sich weniger auf betriebliche
Bereiche als auf betriebliche Prozesse zu fokussieren. Betrachtet man bspw. den Düngeprozess über ein gesam-
tes Anbaujahr, werden die Anforderungen an ein betriebliches Datenmanagement aus diesem Prozess heraus
wesentlich klarer identifiziert werden können, als wenn man ein Gesamtsystem etabliert, in das sich die am Pro-
zess beteiligten Lösungen integrieren müssen. Dieses Vorgehen ist grundsätzlich in der Softwareentwicklung
etabliert, d. h. Lösungen werden aus den konkreten Anwendungsfällen abgeleitet, da nur so die korrekten Anfor-
derungen erfasst werden können. In der Konsequenz bedeutet das, dass statt der Konzeption eines gesamtbe-
trieblichen Datenmanagementsystems ein hybrider Ansatz verfolgt wird, bei dem Teilbereiche von eigenen, indi-
viduellen Datenmanagementansätzen abgedeckt werden, die nach Bedarf miteinander verbunden werden. Ab-
bildung 30 zeigt ein beispielhaftes hybrides Szenario, in dem ein Datenhub als zentraler Datenspeicher sowie ein
Datenrouter im Pflanzenbau existieren. Ein einheitlicher Zugang für die staatlichen sächsischen Systeme verein-
facht Zugriffe auf diese, indem bspw. die Zugriffsschnittstellen zusammengefasst und vereinheitlicht werden.
Abbildung 30: Beispielhaftes hybrides Szenario mit verschiedenen Datenmanagementansätzen in
Kombination

Schriftenreihe des LfULG, Heft 4/2022 | 124
Verfügbare dedizierte Datenmanagementsysteme
Dedizierte Softwaresysteme, die ein eigenständiges landwirtschaftliches Datenmanagement realisieren, sind
am Markt aktuell kaum vertreten. Mit dem agrirouter gibt es einen etablierten Datenrouter, dessen Funktionen
den Fokus auf agronomische Daten legen und der damit im Pflanzenbau ein Baustein für das Datenmanage-
ment sein kann. Proagrica bietet mit agX die Funktion eines Datenhubs mit der Möglichkeit, Algorithmen zur
Datenanalyse zu integrieren und weitere Systeme über Schnittstellen einzubinden. Durch die Kombination mit
weiteren Softwarelösungen wie GateKeeper, FarmPlan und FarmRite ergänzt Proagrica das Angebot um
Softwarelösungen im FMIS-Umfeld, die aktuell in Europa nur in Großbritannien verfügbar sind. Damit bietet
Proagrica ebenso wenig wie bspw. 365FarmNet, John Deere Operations Center oder NEXT Farming ein
eigenständiges, von weiteren Lösungen der jeweiligen Anbieter (Landmaschinen oder eigene Dienstlei-
stungen) unabhängiges Angebot als unabhängiges, dediziertes Datenmanagementsystem.
Betriebsumgebung
Obwohl unter Landwirtinnen und Landwirten häufig Vorbehalte bzgl. cloudbetriebener Lösungen existieren,
schätzen wir diese Betriebsform als insgesamt vorteilhaft ein. Wie in Abschnitt 2.3.3 zur Datensouveränität
diskutiert, ergeben sich durch den Betrieb in externen Rechenzentren keine zwingenden Nachteile in puncto
Datensouveränität gegenüber dem Betrieb auf dem eigenen Hof. Was die Anforderungen bzgl. Skalierbarkeit,
Verfügbarkeit und Performance angeht, hat der Cloudbetrieb klare Vorteile. Durch die Verfügbarkeit hoch per-
formanter Serverumgebungen in zentralen Rechenzentren und die gegebenen Sicherungsmethoden gegen
Störungen können Cloudsysteme eine Betriebssicherheit bieten, die in Betrieben nicht mit vertretbaren Auf-
wänden erreichbar ist (bspw. Notstromversorgung, gekühlte Rechenzentren, zwei redundante Rechenzentren
in räumlich getrennten Bereichen). Daneben werden bereits heute, aber mindestens zukünftig wesentliche
Softwareangebote in Clouds betrieben sein, wodurch sich kein Vorteil aus einer räumlichen Abtrennung der
Daten hin in betriebliche Umgebungen ergibt. Einschränkend wirken einzig die teilweise noch schlecht ausge-
bauten Internetinfrastrukturen, was aber durch Investitionen der öffentlichen Hand und Infrastrukturanbieter
ausgeglichen werden kann und muss. Prozesse müssen einzeln abgesichert sein, sodass etwaige seltene
Ausfälle kompensiert werden können. Das kann z. B. sein, dass zeitkritische Prozesse wie die Ernte ohne die
Verfügbarkeit aller Systeme erfolgen können. Hier müssen Maßnahmen abhängig von den Prozessen getrof-
fen werden. Eine Kaufentscheidung für einen neuen Traktor ist nicht so zeitkritisch wie die Umsetzung einer
Applikationskarte oder Ernte. Eine Lösung kann hier sein, eher auf organisatorische Maßnahmen zu setzen.
Zwischenfazit Lösungsraum
Zusammenfassend lässt sich mit den hier diskutierten Punkten der Lösungsraum eingrenzen. Keine der ge-
zeigten grundlegenden Paradigmen oder auch der im Markt verfügbaren Ansätze stellt unserer Ansicht
nach eine alleinige, eigenständige Lösungsoption dar. In der tatsächlichen Umsetzung erscheint ein hybri-
des Datenmanagement am sinnvollsten, das sich an den jeweiligen Prozessen orientiert und modular auf-
gebaut ist, bspw. betriebszweig- oder teilbereichsspezifisch. Forschungsprojekte untersuchen relevante
Themenaspekte und entwickeln interessante Lösungskomponenten, bieten aber auch keine eigenständigen
oder kurz- bis mittelfristig verfügbaren Lösungen. Manche Forschungsprojekte wurden nach Projektschluss
gar nicht mehr weitergeführt.
Eigenentwicklungen bzw. Individualaufträge können zwar kleinere Vorhaben realisieren, unserer Einschät-
zung nach ist aber ein umfassendes Datenmanagement von einzelnen oder wenigen Betrieben mit verhält-
nismäßigem Aufwand nicht realisierbar. Eigenständige, von weiteren Funktionen unabhängige Softwarean-
gebote existieren im deutschen Markt mit Ausnahme des agrirouters nicht. Da dieser aktuell nur auf den

image
Schriftenreihe des LfULG, Heft 4/2022 | 125
Pflanzenbau ausgerichtet ist, stellt er als Lösung für das Gesamtszenario ebenfalls keine Option dar. Die
weitere Gestaltung wird deshalb nicht umhinkommen, in Betriebszweigen führende Softwaresysteme wie
Ackerschlagkarteien, Herdenmanagementlösungen oder Buchhaltungssysteme als Bestandteile eines be-
trieblichen Datenmanagements zu berücksichtigen. Doch obwohl sich das aus technisch-fachlichen Gründen
als lohnenswerte Option zeigt, gibt es noch wesentliche und relevante Vorbehalte zu berücksichtigen, bspw.
das Risiko, sich von einzelnen Anbietern abhängig zu machen oder das Nichtzustandekommen von Verbin-
dungen durch Vorbehalte der Softwareanbieter.
3.3.4.2 Entwicklung konkreter Lösungsansätze
Aufgrund der bisherigen Betrachtungen wird deutlich, dass eine umfassende Lösungskonzeption nicht ein-
fach herstellbar und vermutlich auch nicht zielführend ist. Vielmehr erscheint es sinnvoll, ausgehend von
betrieblichen Prozessen detaillierte, fachliche Anforderungen zu erheben und zusammen mit den allgemei-
nen Anforderungen in Abschnitt 3.3.2 ein konkretes Anforderungsprofil für ein Datenmanagement zu spezifi-
zieren. In der Softwareentwicklung hat es sich als vorteilhaft erwiesen, bei der Lösungskonzeption von kon-
kreten Anwendungsfällen auszugehen, diese genau zu analysieren und so detaillierte Funktionen der avi-
sierten Softwarelösung zu identifizieren.
In Abschnitt 3.1 werden exemplarische Produktionsprozesse detailliert modelliert und es wird dargestellt,
welche Teilprozesse und -schritte durchlaufen und welche Daten dabei zwischen welchen Systemen ausge-
tauscht werden. Die Prozesse sind ohne Datentransfers zwischen Softwaresystemen dargestellt, d. h. Daten
fließen immer zunächst zur Landwirtin bzw. zum Landwirt und werden von dort in ein Zielsystem übertragen.
Abbildung 31 zeigt einen Ausschnitt der Darstellungen. In dem Beispiel werden Daten (Arbeitszeiten) aus der
Ackerschlagkartei zur Landwirtin bzw. zum Landwirt übertragen (bspw. als grafische Anzeige in der Benut-
zeroberfläche) und diese bzw. dieser gibt diese Daten in das Buchhaltungssystem ein. Ohne Datenmanage-
ment, bspw. über eine direkte Schnittstelle zwischen beiden Systemen, fällt also manueller Übertragungs-
aufwand an.
Abbildung 31: Manuelle Übertragung von Daten zwischen zwei Systemen

image
image
Schriftenreihe des LfULG, Heft 4/2022 | 126
Mit einem Datenmanagement, das beide Systeme über Schnittstellen direkt miteinander verbindet, könnte
der manuelle Aufwand beseitigt werden (vgl. Abbildung 32).
Abbildung 32: Automatische Übertragung von Daten zwischen zwei Systemen
Die detaillierte Analyse erlaubt es dann, alle Datentransfers eines Produktionsprozesses zu identifizieren,
ebenso die beteiligten Systeme. Damit lassen sich, ausgehend von dem Anwendungsfall, alle beteiligten
Schnittstellen und ausgetauschten Daten ermitteln, die für die Konzeption einer Datenmanagementlösung
relevant sind. Abbildung 33 zeigt an einem Ausschnitt des Düngeprozesses, wie in diesem Daten zwischen
Systemen transferiert werden.
Abbildung 33: Ausschnitt eines realen Düngeprozesses (vgl. Abschnitt 3.1.2)
Die letztendliche Konzeption eines realen Datenmanagements gestaltet sich folglich aus den Produktions-
prozessen mit den jeweiligen Anwendungsfällen, die vom horizontalen Datenmanagement unterstützt wer-
den müssen. Um eine solide Konzeption zu erreichen, ist somit die detaillierte Analyse der Prozesse mit
allen jeweiligen Schritten notwendig. Dabei ist es wichtig, nicht nur auf den Austausch eines Teilbereichs zu
schauen, sondern sämtliche am Prozess beteiligten Systeme einzubeziehen.
Anhand des Ausschnittes in Abbildung 33 kann der Prozess der Konzeption exemplarisch wie nachfolgend
beschrieben durchgeführt werden. In diesem Prozessschritt wurde ein Arbeitsauftrag ausgeführt und das
Ergebnis der Arbeiten wird in Form einer Reihe verschiedener Daten bereitgestellt (Arbeitszeiten, ausge-
brachte Mengen, Verbrauch Betriebsmittel, erfolgreiche Erledigung usw.). Diese Daten sollen in verschie-

Schriftenreihe des LfULG, Heft 4/2022 | 127
dene Systeme übertragen werden (Buchhaltung, Arbeitszeiterfassung, Warenmanagement, Ackerschlag-
kartei und Precision Farming). Als konkretes Datenmanagementsystem können prinzipiell alle in Abschnitt
3.3.4.1 aufgeführten Paradigmen realisiert werden. Für diese ist dann zu prüfen, wie die prozessspezifischen
und die allgemeinen Anforderungen (s. Abschnitt 3.3.2.2) umsetzbar sind. Ginge es bspw. nur um diesen
einen Teilprozess, erscheint die Umsetzung eines Datenrouters oder Datenhubs als zu aufwändig, um die
Anforderung nach Kosteneffizienz (DMAF5) zu befriedigen. Einfacher und flexibler erscheint es hier zu sein,
bilaterale Schnittstellen zwischen den Systemen zu schaffen. Aber auch hier gibt es Gestaltungsmöglich-
keiten. Beispiele sind:
Möglichkeit 1: Die Maschine bzw. das Maschinenmanagement übergibt nach Erledigung der Arbeits-
aufgabe alle Daten an die übrigen Systeme über deren jeweilige Schnittstellen. Dazu müssen diese die
Bereitstellung untereinander abgestimmt haben. Sind die Schnittstellen auf Empfängerseite jeweils
individuell umgesetzt und folgen keinem Standard, müsste das Maschinenmanagement die Implemen-
tierung jeder Ackerschlagkartei kennen und umsetzen, was sehr hohe Aufwände mit sich bringen kann.
Sind die Schnittstellen standardisiert, kann das Maschinenmanagement bspw. alle dem Standard folgen-
den Ackerschlagkarteien gleichermaßen einbinden. Ein Vorteil dieser Implementierung ist die Automati-
sierung der Datenübertragung: Das Maschinenmanagement kann gleich nach Abschluss der Datener-
fassung die Übertragung in mehrere Zielsysteme auslösen, wodurch diese die Daten automatisch entge-
gennehmen können und nicht jeweils einzeln das Maschinenmanagement abfragen müssen.
Möglichkeit 2: Das Maschinenmanagement stellt eine standardisierte Schnittstelle zum Auslesen der
Daten bereit, die die jeweiligen Systeme umsetzen. Sofern der Standard auch von weiteren Maschinen-
managementsystemen übernommen wurde, müssen die angebundenen Systeme diese Schnittstelle nur
einmal einbinden. Bei diesem Ansatz müssen nun aber die datenempfangenden Systeme den Zugriff
auf die Daten auslösen und die Schnittstelle des Maschinenmanagements aktiv abrufen. Dies können
sie entweder permanent tun (erhöht die Netzlast und kann die Performance einer schwachen Internet-
verbindung beeinträchtigen) oder auf manuelle Auslösung hin, was bei fünf lesenden Systemen nicht
unerheblichen manuellen Aufwand erfordert und gegen Anforderung DMAF3 verstößt.
In diesem kurzen Exkurs mit zwei verschiedenen Lösungsansätzen wollten wir zeigen, wie man ausgehend
von den realen Prozessen mit allen Teilschritten und den formulierten Anforderungen ein konkretes Konzept
für ein Datenmanagement entwickeln kann. Die Ideen sollten dabei eher das Vorgehen motivieren, als eine
valide Gestaltung eines Datenmanagements für das Prozessbeispiel zu erzeugen. Die Betrachtung eines
einzigen exemplarischen Ausschnittes genügt auch nicht, um ein übergreifendes Datenmanagement konzi-
pieren zu können. Es müssen dazu weitere Teilprozesse und Anwendungsfälle einbezogen werden, um
einerseits den notwendigen Funktionsumfang zu ermitteln und andererseits eine ausreichende Konfidenz
aufzubauen, dass das entwickelte Konzept gesamtbetrieblich tragfähig ist. So wurde hier bspw. argumen-
tiert, dass ein Datenhub oder ein Datenrouter aus Gründen der Kosteneffizienz nicht als Lösungsansatz
gewählt wird. Das gilt aber nur für den Kontext des eher kleinen Prozessausschnittes. Bringt man viele wei-
tere solcher Prozesse in die Anforderungserhebung mit ein, kann sich das anders gestalten und ein Daten-
hub oder Datenrouter plötzlich wieder lohnenswert erscheinen.
In dem Exkurs wurden Anforderungen zur Datensouveränität, Cybersecurity und Performanz nicht adres-
siert, sondern es wurde eher auf Schnittstellen fokussiert. Grundsätzlich sollten alle Anforderungen gleich-
ermaßen betrachtet werden; für einzelne gilt jedoch, dass sie mehr Auswirkungen auf die grundlegende
Konzeption haben als andere. Konkret heißt das, dass bspw. die vorgestellte Schnittstellengestaltung stark
auf Anforderungen wie denen bezüglich Kosteneffizienz und manuellem Aufwand wirken, aber weniger auf

Schriftenreihe des LfULG, Heft 4/2022 | 128
bspw. solche bezüglich Cybersecurity. Letztere hängt stärker von der nachfolgenden technischen Umset-
zung der beteiligten Softwaresysteme ab, d. h., Cybersecurity ist hier für beide Datenmanagementansätze
gleichermaßen erreichbar.
Im Rahmen dieses Abschnittes gehen wir bzgl. der Entwicklung konkreter Lösungsansätze nicht über das
exemplarische Beispiel hinaus. Es wurde diskutiert, dass dazu die Einbeziehung und detaillierte Analyse
weiterer Prozesse und Systeme notwendig ist, die im Rahmen der Betrachtungen hier nicht durchgeführt
wird. Wir wollen in Abschnitt 3.4 eine weiterführende Konzeption eines betrieblichen Datenmanagements
darstellen, das die Anforderungen des gesamtbetrieblichen FMIS adressiert und sich an den exemplari-
schen Zielgrößen ausrichtet (vgl. Abschnitt 3.2).
3.3.5 Kosten im Kontext betrieblichen Datenmanagements
Kosten von IT-Projekten können prinzipiell nur mit detaillierten und konkreten Spezifikationen eingeschätzt
werden, was häufig in Form von Lastenheften formuliert wird
151
. Den Ergebnissen dieser Studie folgend
schlagen wir kein dediziertes Datenmanagementsystem vor, was die Eingrenzung der Kosten für Realisie-
rungen im betrieblichen Datenmanagement insgesamt erschwert. Grundsätzlich gilt, dass für neu zu schaf-
fende Systeme wie einen Datenrouter oder Datenhub enorme finanzielle Aufwände anfallen, während ein-
zelne Schnittstellen vergleichsweise günstig realisiert werden können. In diesem Abschnitt versuchen wir,
erwartbare Kosten zur Schaffung einzelner Schnittstellen einzugrenzen und gehen dabei davon aus, dass
diese im Rahmen bereits existierender Softwarelösungen realisiert werden sollen. Grundsätzlich entstehen
bei der Schaffung von Schnittstellen Aufwände in zwei Softwaresystemen, da diese über die Schnittstellen
miteinander angebunden werden. Das gilt unabhängig davon, ob ein Softwaresystem eine betrieblich ge-
nutzte Fachlösung darstellt oder eine Datenmanagementkomponente.
Aus den Fachgesprächen geht keine eindeutige Aussage zu Kosten zur Schaffung anbieterseitiger Schnitt-
stellen hervor, die Angaben reichen hier von einem Personentag Aufwand bis hin zu nach oben offenen
Kosten. Unserer Einschätzung nach sind zur Umsetzung einer Schnittstelle in einem sauberen Softwareent-
wicklungsprozess mit Dokumentation mindestens fünf bis zehn Personentage anzusetzen, was aber sehr
stark von der Implementierung der Softwarelösung abhängt, zu der die Schnittstelle geschaffen werden soll.
Wesentlich höhere Aufwände bis hin zu mehreren Personenmonaten sind prinzipiell vorstellbar. Beispielhaf-
te und wesentliche Einflussfaktoren bzgl. der Aufwände zur Schaffung einer datenmanagementseitigen
Schnittstelle sind:
Lesende oder schreibende Schnittstelle: eine nur lesende Schnittstelle kann günstiger hergestellt werden
als eine schreibende, da hier nur Daten gelesen und zurückgegeben werden müssen. Bei einer schrei-
benden Schnittstelle müssen eingehende Daten geprüft und korrekt in existierende Datenbestände
eingepflegt werden, was deutlich höhere Aufwände erzeugt. Die Protokollierung von Schnittstellenzugriffen
erzeugt zusätzliche Aufwände, ebenso die Prüfung auf Zugriffsberechtigungen.
Umfang einzelner Schnittstellen: Schnittstellen, über die nur sehr wenige Datenbestände (Einzelwerte bis
hin zu einer einstelligen, nicht strukturierten Anzahl von Werten) ausgetauscht werden, erfordern weniger
Aufwand als solche, über die komplexe Datenstrukturen kommuniziert werden.
151
Detaillierte Diskussionen zu Entwicklungskosten im Rahmen des FMIS befinden sich in Abschnitt 3.4.7

Schriftenreihe des LfULG, Heft 4/2022 | 129
Automatisierungsgrad: Schnittstellen können auf manuelle Interaktion hin Daten kommunizieren (wie
bspw. beim Abruf von Webseiteninformationen aus einem Browser) oder in automatisierte Prozesse
eingebunden sein. Die Automatisierungsprozesse können in Softwarelösungen bspw. so wirken, dass
das Schreiben eines neuen Datums eine folgende Bearbeitung im Datenmanagement auslöst, was die
Umsetzung verteuert.
Standardisierungsaufwand: wird eine noch nicht standardisierte Schnittstelle realisiert, müssen zunächst
Schnittstelle und Datenformat erarbeitet werden. Hierbei entstehen je nach Komplexität der auszu-
tauschenden Datenformate zusätzliche Aufwände.
Nutzung existierender technologischer Komponenten: bestehen bereits technische Vorarbeiten, die zur
Implementierung genutzt werden können, vergünstigt sich die Umsetzung einer Schnittstelle. Dies ist
bspw. der Fall, wenn Open Source-Implementierungen genutzt werden können (bspw. stellt AgGateway
ADAPT bestimmte Implementierungen bereit). Hier gilt aber, dass die bereitgestellten Komponenten zur
eigenen Implementierung passen müssen. Positiv wirken immer eigene bereits implementierte Kompo-
nenten, wenn etwa zu einer bereits bestehenden Schnittstelle eine ähnliche neu geschaffen werden soll.
Die bisherige Diskussion zeigt, dass konkrete Kosten zur Schaffung von Schnittstellen und damit zur Einbin-
dung einzelner Fachsoftwarelösungen ohne detaillierte Spezifikation sehr schwierig abzuleiten sind. Eingangs
wurde argumentiert, dass Schnittstellen auf beiden Seiten von Softwaresystemen geschaffen werden müssen.
Im Rahmen der Kostendiskussion ist also zu klären, wie Schnittstellen auf Anbieterseite finanziert werden
können. Aus den Fachgesprächen ging hervor, dass Anbieter verschiedene Finanzierungsmodelle verfolgen
(Individualentwicklung, Finanzierung als Modul, im Leistungsumfang enthalten). Aus Sicht des Datenmanage-
ments ist die Frage zu beantworten, wie zusätzliche anbieterseitige Aufwände zu tragen sind. Folgt die Argu-
mentation der Forderung nach Datenportabilität im Sinne der Datensouveränität, sollten Landwirtinnen und
Landwirte das Recht haben, mittels Schnittstellen nach Wunsch über ihre betrieblichen Daten verfügen zu
können. Unter der Annahme berücksichtigen wir im Folgenden keine anbieterseitigen Kosten zur Schaffung
von Schnittstellen; diese sind auch zu variierend, um gültige Annahmen treffen zu können.
In Abschnitt 3.4.7.2 werden Kosten für die Schaffung eines FMIS eingegrenzt, die auch die Aufwände
zur Implementierung von Schnittstellen auf Seiten des FMIS thematisieren. Dieser Rahmen kann für die
Einschätzung der Kosten herangezogen werden, die für die Einbindung weiterer Softwaresysteme in ein
Datenmanagement anfallen. Dort wurden je Schnittstelle in der Summe ca. 13 Personentage Aufwand
veranschlagt. In Tabelle 1 der Leistungsbeschreibung wird die Einbindung von insgesamt 19 Software-
anwendungen gefordert. Wir gehen dabei davon aus, dass diese durch internetbasierte, automatisierte
und computerlesbare Schnittstellen realisiert werden und keine manuelle Interaktion wie bspw. der Über-
tragung mittels USB-Stick erfolgt. Werden je Softwarelösung nun 13 Personentage angesetzt, ist insge-
samt mit ca. 250 Personentagen zur Einbindung aller Lösungen zu rechnen. Veranschlagt man je Per-
sonentag 800 bis 1000 €, bewegen sich die Kosten zwischen 200.000 und 250.000 €. Diese Summe
kann sich reduzieren, wenn bspw. standardisierte Schnittstellen umgesetzt werden. Das ist bei Ban-
kensoftwarelösungen der Fall – auch wenn hier verschiedene Standards existieren und diese nicht ver-
pflichtend sind, werden Synergieeffekte dazu beitragen, dass die Aufwände erheblich reduziert werden
können. Wurde also eine Schnittstelle zu einer Bankensoftware mit Aufwänden von ca. 13 Personen-
tagen implementiert, kann die Einbindung einer weiteren Bankensoftware mit geschätzten fünf Personen-

Schriftenreihe des LfULG, Heft 4/2022 | 130
tagen erfolgen. Für das Szenario aus Tabelle 1 der Leistungsbeschreibung ergibt sich damit eine Reduk-
tion um ca. 22.000 €. Für die übrigen Softwaresystemen gehen wir davon aus, dass sie jeweils eigene
Schnittstellen- und Datenformate aufweisen und sich hier keine entsprechende Reduktion ergibt.
Die Kostenfrage hinsichtlich der Einbindung von Softwaresystemen kann noch einmal zusammenfassend
nur dann konkret beantwortet werden, wenn eine detaillierte Spezifikation bspw. in Form eines Lastenheftes
erstellt wurde. Die Schätzungen aus diesem Abschnitt basieren auf unseren Erfahrungswerten aus Soft-
wareentwicklungsprojekten und Angaben aus den Fachgesprächen und sind mit einer hohen Ungenauigkeit
behaftet. Sie bieten allerdings die Möglichkeit, ein Gefühl für erwartbare Kosten zu entwickeln und so ein-
schätzen zu können, welche Aufwände zur Schaffung eines Datenmanagements erwartet werden können.
Tendenziell werden Aufwände für Softwareentwicklungsprojekte immer unterschätzt und anfangs zu niedrig
veranschlagt. Häufig werden „Nebenkosten“ wie für Dokumentation, ausführlichen Anforderungsprozess
usw. vernachlässigt und diese Schritte bei der Umsetzung nicht durchgeführt, was aber nachfolgende
Kosten in Fehlerbehebung und Betrieb erhöht. Regelmäßige Pflegekosten wurden im Rahmen dieses Ab-
schnitts nicht berücksichtigt ebenso wie Aufwände zur Schaffung eines Datenhubs oder Datenrouters, für
die jeweils von wesentlich höheren Gesamtkosten ausgegangen werden muss. Aus eigenen Projekterfah-
rungen schätzen wir Realisierungskosten für das Basissystem eines zu Tabelle 1 der Leistungsbeschrei-
bung notwendigen Datenrouters oder Datenhubs als mindestens siebenstellig ein.
3.3.6 Zusammenfassung und Ausblick
In diesem Abschnitt wurden zunächst grundlegende Konzepte und Hintergründe des betrieblichen Daten-
managements eingeführt und diskutiert. Dabei wurden elementare Funktionen des horizontalen und verti-
kalen Datenmanagements, Datenschnittstellen und grundlegende Paradigmen für die weitere konzeptuelle
Ausarbeitung dargestellt. Im Folgenden werden die allgemeinen Herausforderungen an ein Datenmanage-
ment beschrieben, basierend auf den übergreifenden Anforderungen. Um Lösungsansätze dieser Studie zu
vertiefen und Feedback zu den vorgeschlagenen, grundlegenden Konzepten zu erhalten, wurden Fachge-
spräche mit Softwareanbietern geführt, deren Ergebnisse weit über rein technisch-fachliche Aspekte hinaus-
gingen und einen interessanten sowie relevanten Einblick in unternehmensstrategische und organisatorische
Aspekte erlauben. Hierbei wurde insbesondere sichtbar, dass ein Lösungskonzept nicht allein technisch-
fachliche Aspekte einbeziehen darf und organisatorische Hintergründe und die Rolle sowie Strategien der
verschiedenen Softwareanbieter einbeziehen muss. In einem beispielhaften Prozess wird abschließend
beschrieben, wie durch detaillierte Prozessanalyse und Nutzung der grundlegenden Anforderungen eine
Lösungskonzeption entwickelt werden kann. Wir stellen an dieser Stelle kein konkretes Konzept zur Gestal-
tung eines einzelnen, dedizierten Datenmanagementsystems vor; dazu nähere Ausführungen im Folgenden
und Abschnitt 3.4.

Schriftenreihe des LfULG, Heft 4/2022 | 131
Die folgenden Punkte fassen wesentliche Ergebnisse und Erkenntnisse zum Datenmanagement zusammen
und geben basierend auf unseren Einschätzungen einen Ausblick auf mögliche Folgeaktivitäten dazu:
Fehlen von Voraussetzungen für ein effizientes, betriebliches Datenmanagement:
Auch aus den
Fachgesprächen wurde deutlich, dass landwirtschaftliche Betriebe weiterhin vielen Herausforderungen
und ungelösten Problemen im betrieblichen Datenmanagement ausgesetzt sind. Diese führen zu wesent-
lichen Mehraufwänden in der täglichen praktischen Arbeit. Ursachen dabei sind u.a. fehlende oder nicht
interoperable Schnittstellen zwischen häufig genutzten Softwaresystemen. Fehlende Integration von Soft-
waresystemen in übergreifende Produktionsprozesse oder nicht ausreichende Robustheit führt zu not-
wendigen Fehlerbehebungen, die ohne IT-Fachwissen schwer zu erbringen sind und durch aufwändige
Workarounds erreicht werden.
Technologische Voraussetzungen gegeben, fehlende Koordination:
Technologisch wie fachlich sind
unserer Einschätzung nach ausreichend Wissen und Fähigkeiten in der Landwirtschaft und der IT-Branche
vorhanden, um die Herausforderungen im betrieblichen Datenmanagement anzugehen und eine zum
aktuellen Zustand verbesserte Situation zu schaffen. Es gibt verschiedene Aktivitäten, ob Forschungs-
projekte oder privatwirtschaftliche Initiativen, eine Verbesserung des Gesamtzustands herzustellen. Diese
verfolgen z.T. unternehmensspezifische Interessen und es kommt zu einer nicht ausreichenden Koordi-
nation zwischen Beteiligten, die sich in Extremfällen in einer Lagerbildung manifestiert. Verbesserung kann
eine stärkere Zusammenarbeit der beteiligten Akteure bringen, um Aktivitäten über betriebliche Teilbe-
reiche hinweg aufeinander abzustimmen. Im Bereich der Kommunikation von Maschinendaten übernimmt
bereits die AEF eine solche Rolle, für die betrieblich übergeordnete Koordination fehlen hingegen trei-
bende Kräfte. Auch wenn kein gesamtbetriebliches Datenmanagementsystem angestrebt wird, sollten die
einzelnen Teilbereiche zur Verbesserung übergreifender betrieblicher Prozesse zusammenarbeiten. Im
Fokus steht dabei die Schaffung notwendiger Schnittstellen sowie auf die Nutzung von Standards hinzu-
wirken. In dem Zusammenhang sollten Lücken in der Beschreibung und Dokumentation von Standards,
Schnittstellen und Datenmodellen geschlossen werden. Auch wenn einheitliche Standards die Kommuni-
kation grundsätzlich vereinfachen, ist für die komplexe System- und Anbieterlandschaft keine vollständig
umfassende Standardisierung realistisch. Hier sollten aktuell erforschte Konzepte zur Koexistenz verschie-
dener, aber interoperabler Standards verfolgt werden. Bis hierfür konkrete Lösungen zur Verfügung stehen,
ist die konsistente Nutzung aktuell existierender Standards eine gute Übergangslösung.
Hybrider Ansatz statt einzelnem Datenmanagementsystem:
Ein dediziertes, eigenständiges Soft-
waresystem als zentrales Datenmanagement für alle betrieblichen Anforderungen zeichnet sich aus
unserer Sicht nicht ab. Dies liegt insbesondere in der Komplexität und Verschiedenartigkeit landwirt-
schaftlicher Betriebe und Prozesse und der daraus folgenden stark fragmentierten Marktsituation ange-
botener Softwaresysteme. Zwar würde ein zentrales Datenmanagementsystem wie bspw. ein Datenhub
technische und organisatorische Vorteile bieten (etwa durch Standardisierung und zusammengeführte
Datenbestände), doch wäre die Integration der vielen Softwaresysteme und Prozesse nur mit sehr hohem
Aufwand umzusetzen. Zielführender erscheint uns ein verteilter Ansatz, der zu einem hybriden betrieb-
lichen Datenmanagement führt. Hier werden verschiedene Varianten und konkrete Datenmanage-
mentteilsysteme zu einem logisch gesehen gesamtbetrieblichen Datenmanagement kombiniert, um
spezifische Anforderungen aus den einzelnen betrieblichen Prozesse zu erfüllen. Die Voraussetzung für
eine solche Konzeption ist die detaillierte Analyse und Dokumentation betrieblicher Prozesse, die von
einem solchen Datenmanagement unterstützt werden sollen.

Schriftenreihe des LfULG, Heft 4/2022 | 132
3.4 Gesamtbetriebliches FMIS
Dieser Abschnitt behandelt die Konzeption eines gesamtbetrieblichen FMIS bzw. Dashboards. Nach der
einführenden Zielsetzung werden grundlegende Anforderungen aufgestellt, die noch keine prozessspezifi-
schen Funktionen enthalten. Im Rahmen der Studie wurde ein Fachkonzept entwickelt, das exemplarische
Zielgrößen (vgl. Abschnitt 3.2) in einer grafischen Darstellung repräsentiert. Dieses Konzept wird als Ab-
schnitt vorgestellt und von den Ergebnissen einer Evaluierung ergänzt, in der Landwirtinnen und Landwirten
die grafischen Entwürfe vorgestellt wurden und wo diese Rückmeldung mit ihrer Einschätzung abgeben
konnten. Nach der Diskussion des Fachkonzepts wird in einem technischen Konzept auf hohem Abstrak-
tionsgrad dargestellt, wie ein solches FMIS basierend auf den Ergebnissen zum betrieblichen Datenmana-
gement (vgl. Abschnitt 0) realisiert werden kann. Dazu gehören auch Betrachtungen zum organisatorischen
Konzept (bspw. Betreibermodelle) und zur Eingrenzung erwartbarer Kosten. Als Ergebnis ist keine vollstän-
dig ausgearbeitete Konzeption zur Umsetzung eines betrieblichen FMIS vorgesehen, sondern es soll eine
Basis für auf diese Studie folgende Aktivitäten geschaffen werden.
3.4.1 Definition und Zielsetzung des FMIS im gesamtbetrieblichen Kontext
Abschnitt 2.3.1 diskutiert die Definition von „FMIS“. Dabei wird deutlich, dass es keine einheitliche Definition
gibt und die Funktionen eines FMIS sich je nach Ansatz unterscheiden. Im Kontext dieser Studie fokussieren
wir auf Funktionen zur Bereitstellung von Informationen zur betrieblichen Steuerung, ohne dass das FMIS
selbst steuernde Funktionen, bspw. die einer Ackerschlagkartei, übernehmen soll. Das FMIS wird sozu-
sagen als gesamtbetriebliches Dashboard konzipiert, in dem Informationen über alle betrieblichen Bereiche
hinweg aggregiert und dargestellt werden.
152
Diese Zielsetzung adressiert die Herausforderung, dass Be-
triebsleitungen bzw. betriebliche Mitarbeitende allgemein aktuell auf eine Vielzahl verschiedener Fachsoft-
warelösungen zugreifen müssen, um den jeweiligen Informationsbedarf zu befriedigen. Dieser IST-Stand ist
aufwändig und führt nicht immer zu den gewünschten Ergebnissen, wenn Informationen nicht zusammen-
geführt ausgewertet werden können.
Um die Darstellung von Informationen zu konkretisieren, wurden Zielgrößen ausgewählt, deren Darstellung
die fachlichen Anforderungen an das FMIS bestimmt. Diese Zielgrößen stellen eine exemplarische Auswahl
dar. In der Zielvorstellung eines solchen FMIS sollen prinzipiell beliebige Zielgrößen darstellbar sein, die sich
an den individuellen Informationsbedarfen der jeweiligen Betriebe ausrichten.
3.4.2 Anforderungen an ein FMIS im Rahmen dieser Studie
Die in diesem Abschnitt aufgestellten Anforderungen an ein betriebliches FMIS im Sinne der Definition und
Zielsetzung des vorherigen Abschnitts adressieren die formulierten Herausforderungen und stellen eine
Grundmenge an Anforderungen dar, die von einem solchen FMIS prinzipiell zu erfüllen sind. Sie können in
weiteren konkreten Umsetzungsprojekten zur Konkretisierung genutzt werden, sollten aber nicht als vollständig
oder für alle Projekte gleichermaßen relevant betrachtet werden. Neben den Vorgaben der Leistungsbeschrei-
152
Vgl. dazu die Aktivitäten von SEGES in Dänemark. Hier wird mittels der Microsoft Power BI-Technologie ein Informations-
dashboard konzipiert und entwickelt, das wesentliche betriebliche Informationen anzeigen kann. Zielsetzung und grundlegende
Konzeption können mit denen in dieser Studie verglichen werden, allerdings sind die technischen und organisatorischen Vor-
aussetzungen verschieden. Das Gesamtsystem greift auf umfassende Datenbestände zurück, die bereits in einer Art Datenhub
verfügbar sind.

Schriftenreihe des LfULG, Heft 4/2022 | 133
bung zu dieser Studie wurden umfassende Vorerfahrungen der Projektbeteiligten, eigene Recherchen und
Zwischenergebnisse sowie die vom LfULG bereitgestellten Vorarbeiten (vgl. Abschnitt 2 und insbesondere
3.1.1) eingebracht. Die Anforderungen wurden in Teilen um die Ergebnisse der Evaluierung angepasst oder
ergänzt. Dies hatte aber im Projektverlauf keinen Einfluss auf das in der Evaluierung vorgestellte Fachkonzept.
FMAF1 – Umsetzung betriebsindividueller Informationsbedarfe:
Das FMIS muss so gestaltet sein,
dass der jeweilige Informationsbedarf eines Betriebs erfüllt werden kann. Die Unterscheidung kann bspw.
nach Betriebszweigen erfolgen oder auch nach der Anbindung im Betrieb vorhandener Softwaresysteme
und Datenquellen. Die Informationsbereitstellung ist nach dem jeweiligen Bedarf auszurichten, bspw. eine
Kennzahl oder die Möglichkeit einer Analyse von Zusammenhängen.
FMAF2 – Flexibles Grundsystem:
Um der Komplexität landwirtschaftlicher Betriebe Rechnung zu
tragen, soll das Grundsystem so flexibel gestaltet sein, dass Informationsbedarfe ohne großen Aufwand
individuell konfiguriert werden können. Dazu bietet sich ggf. eine modulare Konzeption an, in der fach-
liche Bereiche unabhängig voneinander abgebildet werden.
FMAF3 – Automatische Zusammenführung von Datenbeständen:
Datenbestände sollen soweit mög-
lich automatisch erfasst und im FMIS bereitgestellt werden, um manuelle Aufwände zu minimieren. Das
Ziel ist die vollständige Automatisierung der Datenbeschaffung.
FMAF4 – Vollständige Einbindung benötigter Daten:
Das FMIS muss zur Darstellung einzelner Infor-
mationen die korrekte, zeitnahe und aktuelle Zusammenführung der dazu notwendigen Quelldaten um-
setzen. Es dürfen keine nicht erkannte Datenlücken auftreten, die zu einer fehlerhaften Darstellung von
Informationen führen.
FMAF5 – Unterstützende Funktionen:
Neben der reinen Informationsbereitstellung sollen unter-
stützende Funktionen ermöglicht werden. Diese richten sich an der jeweiligen Informationsart aus. Bisher
identifizierte Funktionen sind:
Erinnerungsfunktion bei Terminen wie TÜV
Warnung bei Kostenexplosion im Betrieb einzelner Maschinen, bei Liquiditätsengpässen oder bei der
Überschreitung von Kosten zu erwartbaren Erträgen im Pflanzenbau
Angabe von Soll-Kennzahlen und vergleichende Darstellung des IST-Standes
Report-Funktion ausgewählter Informationen (bspw. für den Bericht an Banken)
Internes Benchmarking des aktuellen IST-Standes zu Vergleichszeiträumen
Analysefunktion zur Betrachtung einzelner Sachverhalte (Drill-Down)
FMAF6 – Nachvollziehbarkeit der Darstellungen / Transparenz:
Es soll Nutzern möglich sein, die
Herleitung und Plausibilität angezeigter Informationen zu überprüfen. Das kann bspw. umgesetzt werden,
indem die einbezogenen Daten und Berechnungen dargestellt werden.
FMAF7 – Rollenkonzept:
Das FMIS muss ein Rollenkonzept implementieren, mittels dem Informationen
bedarfsgerecht zusammengestellt werden können und Zugriffe von nicht berechtigten Personen einge-
schränkt werden können.
FMAF8 – Kostengünstige Bereitstellung:
Für die Aufwände für Umsetzung und Betrieb muss der In-
vestitionsspielraum landwirtschaftlicher Betriebe berücksichtigt werden; eine kosteneffiziente Realisierung
ist vorteilhaft. Kosten sollen sich an dem konkreten Nutzen jeweiliger Betriebe orientieren (bspw. durch
ein nutzer- oder funktionsabhängiges Lizenzmodell).

Schriftenreihe des LfULG, Heft 4/2022 | 134
FMAF9 – Einfache Nutzbarkeit:
Das FMIS soll auch für Nutzergruppen ohne explizite Fachkompetenz
einfach nutzbar sein. Dazu gehören bspw. eine einheitliche Nutzerführung oder ein gut verständliches
„Look and Feel“. Eingriffe in die Konfiguration oder Umgestaltung der Informationsdarstellung können an
Personen mit entsprechender IT-Fachkompetenz übertragen werden.
FMAF10 – Verfügbarkeit und Performance:
Das FMIS muss eine sehr hohe Verfügbarkeit (365 Tage,
5:00 bis 23:00 Uhr) erreichen und soll ausreichend performant für eine störungsfreie Nutzung realisiert
werden.
FMAF11 – Unterstützung verschiedener Endgeräte:
Die Darstellung soll auf verschiedenartigen
Endgeräten ermöglicht werden, bspw. auf Tablets oder Desktoprechnern.
3.4.3 Grundlegendes Konzept
Basierend auf den im vorherigen Abschnitt formulierten Anforderungen ergeben sich eine Reihe verschiede-
ner Ansätze, das FMIS gemäß der Zielsetzung zu realisieren. Aus den Fachgesprächen bspw. ergab sich die
Einschätzung, dass vergleichbare Funktionen bereits in einzelnen Softwarelösungen enthalten seien bzw. die
je Betriebszweig führenden Systeme diese übernehmen sollten. Alternativ könnte ein solche FMIS auch als
eigenständige Softwarelösung realisiert werden, die bisher existierende Systeme ergänzt. Beide Optionen
sind valide und möglich; letztlich ist dies eine Entscheidung des Marktes. Für die folgenden Darstellungen im
Rahmen dieser Studie konzipieren wir das FMIS als eigenständige Softwarelösung, um die wesentlichen
Merkmale und Funktionen eigenständig darzustellen und damit auch die Zielsetzung des FMIS als System
zur Informationsbereitstellung hervorzuheben.
Eine weitere Gestaltungsoption betrifft die Umsetzung als Cloudversion oder als Desktopvariante. Nach den
Betrachtungen zur Datensouveränität im Cloudkontext und den Vor- und Nachteilen einer Cloudlösung (vgl.
Abschnitte 2.2.3 und 2.3.3) schlagen wir eine Cloudlösung vor, da diese technisch und organisatorisch ein-
facher, kostengünstiger und mit ausreichend Rechenressourcen umzusetzen ist. Insbesondere die Anfor-
derung nach einer Nutzung auf verschiedenen Endgeräten verlangt eine Umsetzung, in der das System von
mehreren Stellen aus erreichbar ist, was bei einer Umsetzung im Betrieb erheblichen Aufwand erfordern
würde. In dieser Umsetzung bildet die Internetverbindung eine mögliche Schwachstelle, da ohne funktionie-
rende Verbindung keine Nutzung der Lösung möglich ist. Sofern die Anbindung eines Betriebs an das Inter-
net realisiert ist, kann aber im Jahresmittel mit einer sehr hohen Verfügbarkeit gerechnet werden. Je nach
Anbieter können individuelle Vereinbarungen geschlossen werden, die im Störungsfall eine schnelle Behe-
bung zusichern. Darüber hinaus können Internetverbindungen auch redundant ausgelegt werden, sodass
bspw. eine Mobilfunk- oder Satellitenstrecke für den Ausfall einer DSL- oder Glasfaserleitung vorgehalten
wird. Die Kosten hierfür ergeben sich aus den typischen Kosten der Internetprovider, die sich je nach Band-
breite und Leistungsumfang unterscheiden. Eine Satellitenstrecke liegt in etwa in der Höhe eines normalen
Internetzugangs. Alles in allem schätzen wir das Ausfallrisiko einer Internetverbindung als vertretbar ein, und
da Softwarelösungen tendenziell ohnehin cloudbetrieben angeboten werden, würde die Umsetzung des
FMIS auf Betriebsinfrastruktur bei einem Ausfall des Internets wenig Vorteile bringen. Um einen Ausfall den-
noch abzumildern, besteht die Möglichkeit, eine leichtgewichtige Softwarelösung zur Installation im Betrieb
umzusetzen. Diese baut prinzipiell auf der beschriebenen Cloudlösung auf, kann aber auf einem Deskto-
prechner installiert werden und speichert die letzten Zustände der Datenbestände bzw. Zielgrößen. So sind
diese im Störungsfall zwischengespeichert verfügbar, allerdings möglicherweise nicht aktuell.

Schriftenreihe des LfULG, Heft 4/2022 | 135
Für die Konzeption und insbesondere die Berechnung der gewünschten Informationsbereitstellung wurde
angenommen bzw. vorausgesetzt, dass die dazu notwendigen Daten aus den Quellsystemen bezogen werden
können. Auch wenn das für eine gewisse Anzahl der Quelldaten zutrifft, sind aktuell noch nicht alle Vorausset-
zungen dazu geschaffen. Das heißt, dass begleitend zur Konzeption und Entwicklung eines FMIS gemäß der
Zielsetzung der Zugriff auf die notwendigen Quelldaten realisiert werden muss. Dazu muss das Daten-
management entsprechend aufgebaut werden, aber es müssen auch die Quellsysteme integriert werden, was
ggf. zusätzliche Aufwände erzeugt.
Das Grundkonzept des FMIS sieht zusammenfassend ein FMIS-System vor, das als Cloudsystem betrieben
wird. Für Betriebe wird ein eigener Bereich eingerichtet, der über eine Zugangsverwaltung geschützt werden
muss. Für Betriebe können mehrere Zugänge angelegt und so konfiguriert werden, dass jeweils verschiedene
FMIS-Inhalte und -Funktionen angezeigt werden können. Für jeden Betrieb muss individuell konfiguriert wer-
den, welche Fachsysteme eingebunden und welche Zielgrößen sowie Informationen angezeigt werden. Nutzer
können sich über ein Endgerät per Internetverbindung zum FMIS verbinden und dort auf das Dashboard zu-
greifen. Das Dashboard selbst kann als Webseite angeboten werden und ist so mit den üblichen Browsern zu
nutzen. Daten bezieht das FMIS ebenfalls über das Internet von den angebundenen Fachsystemen und wei-
teren Datenquellen, bspw. einem Wetterdienst o