{"id":23,"date":"2026-07-20T15:56:53","date_gmt":"2026-07-20T15:56:53","guid":{"rendered":"https:\/\/simonbeyer.de\/?page_id=23"},"modified":"2026-07-21T20:42:53","modified_gmt":"2026-07-21T20:42:53","slug":"arbeitsweise","status":"publish","type":"page","link":"https:\/\/simonbeyer.de\/index.php\/arbeitsweise\/","title":{"rendered":"Arbeitsweise"},"content":{"rendered":"\n
\n
\n

Softwareentwicklung und digitale Prozessgestaltung<\/p>\n\n\n\n

Meine Projekte beginnen nicht mit einer m\u00f6glichst langen Funktionsliste, sondern mit dem zugrunde liegenden Arbeitsprozess: Wer ben\u00f6tigt welche Informationen? Wer darf sie sehen oder ver\u00e4ndern? Welche Schritte m\u00fcssen nachvollziehbar dokumentiert werden? Erst daraus entstehen Datenmodell, Berechtigungen, Oberfl\u00e4che und technische Umsetzung.<\/p>\n\n\n\n

Ziel ist nicht m\u00f6glichst viel Eigenentwicklung, sondern eine nachvollziehbare L\u00f6sung, die vorhandene Plattformfunktionen sinnvoll nutzt und ihre Grenzen offen dokumentiert.<\/p>\n<\/div>\n<\/div>\n\n\n\n

\n
\n

Reale Abl\u00e4ufe als Ausgangspunkt<\/h2>\n\n\n\n

Am Anfang steht die fachliche und organisatorische Kl\u00e4rung. Ich zerlege einen Ablauf in beteiligte Rollen, Eingaben, Zust\u00e4nde, Entscheidungen, Ausgaben und Dokumentationsanforderungen. Dabei unterscheide ich zwischen dem tats\u00e4chlichen Bedarf, bestehenden Gewohnheiten und Funktionen, die lediglich technisch m\u00f6glich w\u00e4ren.<\/p>\n\n\n\n

Anforderungen werden so formuliert, dass sp\u00e4ter \u00fcberpr\u00fcfbar bleibt, ob sie umgesetzt wurden. Offene Fragen, Annahmen und noch nicht entschiedene Punkte werden getrennt dokumentiert.<\/p>\n\n\n\n

Dokumentations- und Nachweispflichten<\/p>\n\n\n\n

Ziel und Nutzen des Prozesses <\/p>\n\n\n\n

beteiligte Rollen und Verantwortlichkeiten <\/p>\n\n\n\n

ben\u00f6tigte und nicht ben\u00f6tigte Daten <\/p>\n\n\n\n

Bearbeitungsschritte und Statuswechsel <\/p>\n\n\n\n

Ausnahmen und Fehlerf\u00e4lle <\/p>\n<\/div>\n<\/div>\n\n\n\n

\n
\n
\n
\n

Zugriff folgt Aufgabe und Verantwortung<\/h2>\n\n\n\n

Rollen- und Berechtigungsmodelle sind f\u00fcr mich kein nachtr\u00e4gliches Detail. Bereits vor der Umsetzung wird gekl\u00e4rt, welche Rolle welche Informationen sehen, anlegen, bearbeiten, freigeben, exportieren oder l\u00f6schen darf.<\/p>\n\n\n\n

Dabei geht es nicht nur um technische Zugriffssperren. Berechtigungen m\u00fcssen zur tats\u00e4chlichen Verantwortung passen, verst\u00e4ndlich administrierbar sein und \u00c4nderungen m\u00f6glichst nachvollziehbar machen. Besonders bei Besch\u00e4ftigten-, Schul- oder Assistenzdaten ist eine gro\u00dfz\u00fcgige Vergabe von Rechten keine neutrale Vereinfachung.<\/p>\n<\/div>\n\n\n\n

\n
\n

Typische Pr\u00fcffragen<\/strong><\/h2>\n\n\n\n