EVOMATION.DEAGENT VIEW
← Human View
################################################################################
# EVOMATION.DE — AGENT ACCESS GUIDE
################################################################################

DOCUMENT PURPOSE
----------------
You are reading the low-noise agent view for evomation.de.
This AX layer exists for LLMs, browser agents, and automated systems that need a
direct description of domain fit, route purpose, contact paths, and legal or
compliance references.

Entity:    Evomation-Michael Meese e.K.
Domain:    evomation.de
Role:      Custom software, automation, integration, and retrofit-oriented systems
Audience:  Logistics, intralogistics, manufacturing, and adjacent operational teams
Route Locale: de
AX Language: English only

READING RULES
-------------
- Treat this as the canonical low-noise summary for the current page.
- The public human-facing website is available under both /de and /en.
- AX output remains in English on both locale routes.
- Sections are delimited by H2 headers.
- Subsections use H3 and H4.
- Prefer explicit paths over inference.
- Legal identity: /de/impressum/llms.txt
- Privacy / GDPR: /de/datenschutz/llms.txt
- Cookie inventory: /de/cookie-richtlinie/llms.txt

READING MODES
-------------
1. Human View
   Use the public route without modifiers.
   Example: /de/ueber-uns

2. Agent View
   Use the same public route with ?view=agent.
   Example: /de/ueber-uns?view=agent

3. LLM Text View
   Use the locale-prefixed llms.txt route.
   Examples:
   - /de/llms.txt
   - /de/ueber-uns/llms.txt
   - /de/kontakt/llms.txt

ROUTE PATTERN
-------------
For a page at /{locale}/x:
- Human View: /{locale}/x
- Agent View: /{locale}/x?view=agent
- LLM Text View: /{locale}/x/llms.txt

For the locale homepage:
- Human View: /{locale}
- Agent View: /{locale}?view=agent
- LLM Text View: /{locale}/llms.txt

PREFERRED ACCESS STRATEGY
-------------------------
1. Use llms.txt when available for extraction, summarization, routing, or token-efficient reading.
2. Use ?view=agent when you need browser-readable structured HTML with minimal noise.
3. Use the human page only when layout, visual hierarchy, or interaction context matters.

PAGE INDEX
----------
Human View:
  /de  -> homepage
  /de/ueber-uns  -> about and engagement model
  /de/kontakt  -> contact and entry points
  /de/produkte  -> products and tools index
  /de/blog  -> blog index

Agent View:
  /de?view=agent  -> structured homepage
  /de/ueber-uns?view=agent  -> structured about page
  /de/kontakt?view=agent  -> structured contact page
  /de/produkte?view=agent  -> structured products index
  /de/blog?view=agent  -> structured blog index

LLM Text View:
  /de/llms.txt  -> homepage llms.txt
  /de/ueber-uns/llms.txt  -> about llms.txt
  /de/kontakt/llms.txt  -> contact llms.txt
  /de/produkte/llms.txt  -> products llms.txt
  /de/blog/llms.txt  -> blog llms.txt
  /de/impressum/llms.txt  -> legal identity
  /de/datenschutz/llms.txt  -> privacy policy
  /de/cookie-richtlinie/llms.txt  -> cookie policy

DYNAMIC ROUTES
--------------
- Product detail pages live under /de/produkte/{slug}
- Blog article pages live under /de/blog/{slug}
- Industry detail pages live under /de/branchen/{slug}
- Discover valid detail routes from the matching index pages before navigating

################################################################################

Warum Anwender ihre eigene Dokumentation schreiben sollten: Erfahrungen aus der Einführung eines neuen ERP-Systems

Snapshot

Article Metadata

AX Summary

Describes why documentation adoption improves when domain users help write it during ERP rollout instead of receiving it passively from the implementation side. The article focuses on onboarding, operational accuracy, and knowledge capture during system introduction.

Use When

Use when the request involves ERP rollout, change management, user enablement, or documentation ownership during implementation.

Key Points

  • Documentation works better when operational users contribute to it directly.
  • The article is about rollout process and knowledge transfer, not documentation tooling alone.
  • The main benefit is better adoption and more realistic process documentation.

Not Useful When

Not useful when the request is purely about API docs, developer docs tooling, or static documentation site setup.

Section Index

  • H2: Was kann man da tun?
  • H2: Warum Anwender ihre eigene Dokumentation schreiben sollten
  • H2: Das richtige Tooling
  • H2: Herausforderungen bei der Einführung
  • H2: Meine Empfehlung zur Einführung
  • H2: Fazit

Original Article Body (German)

--- translationKey: user-written-documentation title: "Warum Anwender ihre eigene Dokumentation schreiben sollten: Erfahrungen aus der Einführung eines neuen ERP-Systems" excerpt: Was bei der Einführung eines neuen ERP-Systems besser funktioniert, wenn Fachbereiche die Dokumentation nicht nur lesen, sondern mitgestalten. publishedAt: "2025-08-18T08:00:00.000Z" updatedAt: "2026-04-13T08:00:00.000Z" category: best-practices tags: Digitale Transformation How-to Dokumentation author: michael-meese visual: type: image imageAssetPath: /tools/evomation-whatsthedelta-text-diff.png imageAlt: Textvergleich in einer Evomation-Anwendung featuredOnHomepage: true homepageOrder: 1 seo: title: "ERP Prozessdokumentation: Warum Mitarbeiter selbst schreiben sollten | Evomation" description: "Ihr Team hat trotz Schulung Probleme mit neuen Abläufen und Tools? Erfahrungen zeigen: Eigene Dokumentation macht den Unterschied. Konkrete Tipps für die Praxis." --- Nehmen wir an, ein Unternehmen führt ein neues ERP-System ein, sagen wir Odoo. Im Laufe des Projektes werden neue Geschäftsprozesse erarbeitet und geübt. Zum einen, weil Dinge im neuen ERP-System anders funktionieren als im alten System oder weil sich gewisse Dinge überlebt haben und jetzt die Gelegenheit für einen Hausputz genutzt wird. Die Herausforderung dabei: Selbst nach ausgiebiger Schulung fehlt zu Beginn einfach die Routine in dem neuen Werkzeug. Das führt, je nach Persönlichkeit, zu Unsicherheit und Stress, bei der Erledigung alltäglicher Aufgaben. Kommt dann noch direkter Kundenkontakt zu der empfundenen Unsicherheit hinzu, bekommt der eine oder andere schon im Vorfeld Panik. Im Ergebnis wird dann oft auf die neue Lösung geschimpft und die alte über den Klee gelobt - ein schwerer Start für das neue Tool. Hinzu kommt, dass oft keine formalen Geschäftsprozessbeschreibungen oder gar Standard Operating Procedures (SOPs) existieren. Bestehende Abläufe sind nur mündlich überliefert ("Das haben wir schon immer so gemacht") oder existieren in veralteten Dokumenten, die längst nicht mehr zur Realität passen. Wenn dann das neue Tool eingeführt wird, muss vieles gleichzeitig gelernt und angepasst werden - und genau hier entstehen Probleme.

Was kann man da tun?

Ich will es nicht schönreden, die Einführung einer neuen komplexen Software, welche gewohnte Prozesse teilweise grundlegend ändert, ist immer eine Herausforderung für ein Unternehmen und das Team. Aber ich bin fest der Überzeugung, dass man den Geburtsschmerz eines solchen Projektes entschieden mindern kann, wenn man neben ausreichender vorbereitender Schulung dem Team eine einfach zugängliche und praxisnahe Dokumentation zum schnellen Nachschlagen an die Hand gibt.

Warum Anwender ihre eigene Dokumentation schreiben sollten

Statt dass nun ausschließlich Projektleiter oder externe Berater Dokumentationen verfassen, sollten die Anwender selbst die eigene Dokumentation erarbeiten. Das hat mehrere Vorteile: Verständlich in eigenen Worten: Die Erklärungen sind praxisnah und so formuliert, dass das Team sie nachvollziehen kann. Fokus auf das Wesentliche: Anwender wissen, welche Arbeitsschritte wirklich relevant sind, und sparen unnötige Details aus. Erfahrungswissen wird gesichert: Praxisfälle und Sonderlösungen landen in der Doku, nicht nur theoretische Abläufe. Schnell nachschlagbar: Eine gut geführte Dokumentation reduziert Unsicherheit und spart Zeit bei der Einarbeitung. Geteiltes Wissen: Hilft beim Onboarding neuer Mitarbeiter und bei Vertretungen in Abwesenheit. Wissensvertiefung: Wer einen Ablauf erklären muss, versteht ihn selbst noch besser. Dabei sollte einfach und hemdsärmelig mit der Dokumentation begonnen werden, denn Perfektionismus ist auch hier der Feind von einer guten Lösung. Ein Artikel kann zunächst nur aus dem wichtigsten Bulletpoints, einem Screenshot oder einem Link bestehen, Hauptsache, es wird begonnen. Ist das Thema relevant, wird der Artikel mit der Zeit erweitert und verbessert werden. Auch hier gilt: Content is King. Nur wenn ich hilfreichen und sinnvollen Inhalt bereitstelle, wird die Lösung benutzt. Und sinnvoll ist zu Beginn jeder kleine Schnipsel und jede Gedankenstütze zu einem alltäglichen Problem.

Das richtige Tooling

Damit dieses Prinzip funktioniert, muss das Dokumentationswerkzeug einige Anforderungen erfüllen: Einfache Bedienung: Die Hemmschwelle zum Mitschreiben muss gering sein und Abruf des Wissens maximal einfach. Klar strukturierbar: Eine gute Suchfunktion, klare Kategorien und sinnvolle Navigationswege sind Pflicht. Rechtemanagement: Einfacher Zugang, aber Schutz sensibler Informationen. Versionierung: Änderungen müssen nachvollziehbar bleiben. Schnelle Verfügbarkeit: Die Doku muss während der Arbeit leicht erreichbar sein, nicht in einem unübersichtlichen SharePoint-Ordner verstauben. Tools wie z. B. BookStack oder Obsidian bieten hier einen guten Kompromiss: Sie sind einfach genug, um von allen genutzt zu werden, aber flexibel genug, um komplexe Inhalte zu strukturieren.

Herausforderungen bei der Einführung

Nach meiner persönlichen Erfahrung gibt es bei der Einführung häufig ähnliche Widerstände, die überwunden werden müssen: Der Wert und die Sinnhaftigkeit einer eigenen Dokumentation werden zunächst nicht erkannt. Der Aufwand wirkt abschreckend, weil oft das Bild eines umfassenden Kompendiums im Kopf entsteht. Schreibhemmung: Die Sorge, sich vor Kollegen zu blamieren oder bewertet zu werden. Zusätzlich zu diesen eher allgemeinen Anfangshürden müssen aber auch die Rahmenbedingungen passen. Die Erstellung der Dokumentation darf nicht als Nebentätigkeit „irgendwann mal“ stattfinden, sondern sollte Teil der Zielvorgaben sein. Führungskräfte müssen Zeit und Priorität dafür freigeben.

Meine Empfehlung zur Einführung

Ich baue die Erstellung der Dokumentation in der Regel bereits während der Workshops unangekündigt ein. Sobald die ersten Grundlagen vermittelt sind, fordere ich spontan auf, doch jetzt mal die wichtigsten Bulletpoints kurz mit einem Screenshot in einem Artikel zusammenzufassen. In der Regel nehme ich mir dazu kleine einfache Themen, bei denen ich Unsicherheiten bei den Anwendern bemerkt habe. Zum einen kommt so schnell eine kleine, aber kritische Menge an relevanten Artikeln zusammen. Diese Artikel / Themen sind dann häufig bei der nächsten Gruppe oder beim nächsten Workshop relevant und ich fordere zum Nachschlagen in der Doku auf. Darüber hinaus kommt es dann im Team häufig schnell zu einer Ergänzung und Erweiterung der bestehenden Artikel. Dadurch gibt es schnell ein positives Erlebnis und auch Erleichterung bei den Anwendern. Dafür ist aber entscheidend, dass das gewählte Dokumentationstool in jeglicher Hinsicht so simpel wie möglich zu bedienen ist und keine zusätzliche Hürde für die Anwender darstellt. Meine Tipps daher: Die Dokumentation muss parallel zur Arbeit an einem Thema entstehen - nachträglich passiert es eigentlich nie. Führungskräfte müssen die Zeit fürs Mitschreiben freigeben und es nicht als eine Nebensächlichkeit sehen. Manche Anwender sehen den Nutzen erst, wenn die Dokumentation ihnen konkret hilft - daher sofort mit kleinen kritischen Themen beginnen.

Fazit

Bei komplexen IT-Projekten (etwa einem neuen ERP-System) entscheidet oft nicht die Software allein über den Erfolg, sondern die Qualität der internen Wissensweitergabe. Wenn Anwender ihre eigene Dokumentation schreiben, entsteht eine lebendige Wissensbasis, die mit der Praxis wächst. Das mindert Stress, reduziert Fehler, beschleunigt das Onboarding und macht das Unternehmen unabhängiger vom Wissen einzelner Personen. Meine Empfehlung ist daher, dass jedes Unternehmen grundsätzlich seine Standardprozesse dokumentieren sollte und so seine eigenen Standards schafft.

Related Articles