Dokumentverwaltung

[TigerLilly]

Zitat von dummzeuch:

Was glaubst Du, wie viele in der öffentlichen Verwaltung (aber natürlich auch in Unternehmen) eingesetzte Programme entstanden sind? Da wurde kein offizielles Projekt durchgeführt, da hat ein engagierter Mitarbeiter was zusammengebastelt.

Ich weiß, ich bin in meinen Projekten oft genug mit sowas konfrontiert (und hab selber auch schon sowas entwickelt). Stichwort "historisch gewachsen". Grundsätzlich spricht da gar nix dagegen, aber das funktioniert - vor allem langfristig! - nur dann gut, wenn es ein gutes Projektmanagement gibt (= Doku, Risikoabschätzung, Verträge, uvm). Sonst gilt allzu oft: Gut gemeint ist nicht gut getan.

An Stahlis Beispiel: Wem gehört der Sourcecode, wenn er das in seiner Freizeit entwickelt? Öffentliche Einrichtungen sind an eine Vielzahl von Vorschriften gebunden (state-of-the-art im Prozess, DSGVO, Geschlechterneutrale Sprache, Barrierefreiheit uvm) - kennt Stahli die alle und kann sie berücksichtigen? Öffentliche Einrichtungen werden auch gern mal geprüft + solche Sachen werden dann oft zu einem "Wie kann man nur?". Weniger, weil das Ding nicht funktioniert, sondern weil so viele Rahmenbedingungen nicht berücksichtigt wurden.

Für eine öffentliche Einrichtung würde ich überdies glauben, dass ein "Entwickeln in Freizeit" durch einen Mitarbeiter gar nicht zulässig ist. Aber das müsste man prüfen.

[Sinspin]

Zitat von TigerLilly:

An Stahlis Beispiel: Wem gehört der Sourcecode, wenn er das in seiner Freizeit entwickelt? Öffentliche Einrichtungen sind an eine Vielzahl von Vorschriften gebunden (state-of-the-art im Prozess, DSGVO, Geschlechterneutrale Sprache, Barrierefreiheit uvm) - kennt Stahli die alle und kann sie berücksichtigen? Öffentliche Einrichtungen werden auch gern mal geprüft + solche Sachen werden dann oft zu einem "Wie kann man nur?". Weniger, weil das Ding nicht funktioniert, sondern weil so viele Rahmenbedingungen nicht berücksichtigt wurden.

Für eine öffentliche Einrichtung würde ich überdies glauben, dass ein "Entwickeln in Freizeit" durch einen Mitarbeiter gar nicht zulässig ist. Aber das müsste man prüfen.

Das sind alles Gründe warum es in Deutschland mit der Digitalisierung einfach nicht vorrangeht und alles viel zu teuer wird. Man schießt sich permanent ins Bein oder in wichtigere Körperteile.
In anderen Ländern klappt das viel besser. Findet man Fehler behebt man sie einfach. Nutzt jemand eine Lücke aus um sich zu bereichern, schließt man die Lücke und der Übeltäter geht in einen Knast der seinen Namen verdient!
Dieses jahrelange gezerre um Entscheidungen mit zig Beratern die nur Geld verheizen gibt es nicht. Man berät sich, kommt zu einem Ergebnis, es wird umgesetzt! Später erweitert und angepasst.
Klar knackt und knirscht es immer mal. Aber dafür läuft schonmal was!

Stahli, Deutschland sehe ich definitiv nicht mehr als Land in dem eigeninitiative belohnt wird. Aber, wenn Du eh schon Programme für die Stadtverwaltung geschrieben hast, und das als Auftrag ausführen kannst, warum dann nicht? Nur solltest du dir überlegen was für dich dabei rumkommt und wieviel du in das Projekt zu investieren willst. Es gibt sicher schönere Dinge mit denen man sich beschäftigen kann.

Wie ist das wenn man sowas als Ehrenamt macht? Kann man dafür an die Wand gestellt werden wenn was schief läuft? Oder eine Ein-Mann GmBH und alle Werte auf die Frau übertragen?

[stahli]

Ohne mein "AW" könnten wir unsere Abfallentsorgung nicht so durchführen wie wir es aktuell tun.
Das ist ein Bindeglied verschiedener Datenbestände und gleicht diese miteinander ab, erstellt Fehlerprotokolle und verwaltet unsere Vorgänge (Wer bearbeitet gerade was?).

Die digitale Dokumentverwaltung wäre der nächste Schritt.
Ich muss damit ja selbst arbeiten, weiß also was gebraucht wird. Mit Standardsoftware wäre ich (vermutlich) nicht glücklich.
Hätte natürlich Vorteile, aber der Aufwand, die konkret an die eigenen Bedürfnisse und Wünsche anzupassen, wäre vermutlich nicht geringer, als selbst ein Tool zu schreiben.

Gegenüber 1993 habe ich auch schon etwas dazu gelernt.
Ich weiß noch, dass ich damals extra Bücher gelesen habe, was SQL ist.
Natürlich ist mir jetzt auch klar, dass man eigentlich anders arbeiten sollte, als eine BDE-Tabelle über TTable an ein DBGrid zu binden.
Aber von der Nutzung her ist das schon ideal auf uns zugeschnitten.
Wenn ich nicht wüsste, was dadrin alles quer läuft, würde ich es als nahezu perfekt bezeichnen.

Meine Chefin hat zwar immer gesagt: "Machste wieder Spielemätzchen!" aber ihr war dann schon klar, was uns das Tool bringt.
Also die Eigeninitiative war schon sehr wichtig und hilfreich für uns.

Das ist sicherlich auch der Grund, dass mein Vorschlag jetzt zumindest erst mal positiv aufgenommen wurde.
Mals sehen, was draus wird.

Werde jetzt doch schon mal nebenbei mit FB und IBExpert beschäftigen. Mal sehen, ob ich da wieder rein finde...

[himitsu]

Bei uns waren Anfangs die Dateien in der Datenbank, aber das wurde auch recht schnell zu groß, auch vom Backup her bissl unpraktisch, auch falls mal irgendwann mit der Software oder Firma was nicht mehr geht ... einige Kunden wollten gern gewisse Dateien rechtssicher auf einem WORM-Laufwerk haben.

Natürlich wäre ein gutes Grundgerüst, einer seit vielen Jahren von Vielen entwickelten und stabilen Platform, eigentlich besser, auch wenn man sie dann (erstmal) nur versteckt im Hintergrund nutzt und nach außen seine eigenen Schnittstellen in der eigenen Software hat.
Allerdings sind hier auch grade die guten großen Player auf dem Markt nicht gerade "günstig" zu haben.

Aber es kann dennoch nicht schaden, wenn du dennoch mal einen Blick riskierst, denn auf der anderen Seite kannst dir so erstmal etwas Arbeit sparen
und auch von Seiten der Haftung einen Teil abgeben.
open source dms

Wir hatten damals Datasnap benutzt, um die Dateien zwischen Server und Client zu übertragen (weil es in unserem Delphi schon enthalten war, außerdem war es cool und modern nagelneu und sowas muß immer gleich rein ),
aber da gibt es auch andere Komponenten, bis hin zu einem kleinen sebstgebauten REST-Server.
Es wäre sogar möglich die Dateien in einem "Dateisystem" zu speichern, welches eine Dateiübertragung anbietet, wie z.B. FTP/SFTP/FTPS, WebDAV, SMB, AFP, NFS, ActiveDirectory, ...

Also die Dateien in der Datenbank verwalten und die Daten irgendwo anders abzulegen. (bei uns hatte ich da noch einen MD5-Hash der Dateien in der DB mit gespeichert, um die Daten verifizieren zu können, auch wenn das aktuell noch nicht gemacht wird, aber man könnte es ... nur so als Idee, wenn du auch "selber" was bauen willst)

PS: EMS ginge inzwischen auch, falls man mit der Lizenzierung zurecht kommt, wobei es auch nur ein "aufbemotztes" Datasnap ist, inkl. Benutzerverwaltung usw.


Ich hatte Datasnap damals nur mit binärer Datenübertragung, denn es nutzt intern "noch" DBExpress zur Verwaltung und auch zur Datenübertragung, aber man kann auch via REST verbinden, was ich jetzt nachgerüstet hatte (der Client konnte es schon, via Property umstellbar, auch wenn im Code hardcodiert und nicht aus der Config geladen, aber im Server damals "ausversehn" weggelassen) und schon kann eine neue WebApp direkt mit der bestehenden Infrastruktur reden.

[stahli]

Der Vorteil einer Nutzung vom d.3 wäre ja, dass da ein Speichertool eines großen Players genutzt würde mit allem Zipp und Zapp.

Man könnte sich dort einloggen, die Dokumente suchen und neue speichern.
Insofern wäre das rechtliche alles abgefrühstückt - zumindest gehe ich davon aus, dass das von der IT und Stadt geklärt ist.

Mein Tool wäre dann lediglich ein Vermittler, der die Schlüssel und Suchbegriffe auf komfortable Weise zusammenstellt und diese dem d.3 zusammen mit dem Dokument übergibt.
Jedenfalls stelle ich mir das so vor - und das wäre eine praktikable Lösung.

Ich werde jetzt statt dem d.3 während der Entwicklung erst mal eine Datenbank nutzen (d.3 quasi simulieren).
Wenn das funktioniert, kann ich dann drängeln und einen Zugang zum echten d.3 ... äh ... erbitten.

Ist, glaube ich, ein ganz guter Weg.

[jobo]

Ich finde das klingt teilweise etwas schief. Dein Tool als "Vermittler" scheint mir genau der richtige Ansatz, aber DB zum Simulieren und dann.. wäre m.E. falsch.

- ein OpenSource DMS mit den schon erwähnten Standardschnittstellen (REST Web Services, WebDAV, CMIS, ..)zum "Simulieren" bzw. als Ersatz zum endgültigen System (also mangels d3 @home),
- eine DB als Datenspeicher für die "Vermittlungsdaten", nicht simuliert, sondern als finale Implementierung

sowas würde ich mir da vorstellen. Im Reigen der Systeme wäre Deins dann ein Workflow Tool, das auch entsprechend nur Workflowdaten hält(DB) und sicher einige oder viele Komfortfunktionen bietet..

Wenn man es schön machen will, würde man intern vielleicht gegen ein Interface programmieren, das die Dokumentverwaltung anbindet und verschiedene Protokolle bedient/bedienen kann.

[stahli]

Mein Tool müsste die Metadaten verwalten und Filterfunktionen zur Verfügung stellen.
Das kann ich 1:1 fertig stellen.

Dann brauche ich eine Funktion SpeichereDokumentMitFolgendenVerknüpfungsdaten() und eine GibMirDokumenteZuFolgendenVerknüpfunbgsdaten().
Die können beide erst mal auch einfach auf eine DB zugreifen. Das würde ich erst mal möglichst einfach halten wollen.
Ich sehe keinen Vorteil, dafür etwas Komplizierteres aufzubauen.

Später kann man die beiden Funktionen dann natürlich ausbauen bzw. anpassen.

[TiGü]

Vielleicht wäre es sinnvoll, wenn du dich mit der Möglichkeit beschäftigst, dich als Plugin/App in das bestehende System einzuklinken.

https://www.d-velop.de/app-builder-werden/

Du musst das ja nicht in deren Store zum Verkauf anbieten, aber so kannst du alle Schnittstellen von d.velop nutzen.

[stahli]

Wie geht Ihr mit eMails um?


Hier wird Outlook genutzt und das ist gesetzt.
Standardmäßig wird bei Antworten oben geschrieben und darunter der vorherige Mailverkehr zitiert.

Später wird dann die Mail ggf. ausgedruckt und abgeheftet. Dann stimmt natürlich die gedruckte Reihenfolge chronologisch nicht mehr.

Neuen Text unter dem Zitat zu schreiben ist nicht praktikabel und ja auch völlig untypisch.


Mit einem eigenen eMail-Client könnte man bestimmte Tags definieren, die helfen könnten, die Mails zu interpretieren und neue Abschnitte zu erkennen. Dann hätte man so etwas wie einen Chatverlauf mit eigenständigen Beiträgen ohne Zitate von alten Beiträgen).
Das ist aber unrealistisch.


Was machbar wäre, wäre die "gedruckten bzw. gescannten" eMails einfach visuell zu zerschneiden.
Der Bearbeiter, der die gescannten Seiten zu Dokumenten zusammenstellt (wie hier angedeutet: https://www.delphipraxis.net/1470347-post6.html) könnte ggf. einfach händisch schnell den zitierten Kram in einer eMail "abschneiden".

Das wäre also eine Zusatzfunktion, dass man nicht nur ganze Seiten speichert, sondern bei Bedarf auch nur Teile daraus.

Wie geht Ihr mit dem Problem um (unter dem Aspekt, dass einfach Outlook alltagsgemäß und mit Zitaten genutzt wird)?

[jobo]

In meiner Welt arbeitet eine Behörde bevorzugt mit Formularen. Für den Endkunden vielleicht häufig unglücklich, aber das Formular, das Ergebnis definiert ja im Grunde eine verfügbare Dienstleistung, ein "Produkt", was vermutlich das Ziel einer Sachbearbeitung ist, die die Mitarbeiter durchführen und der Kunde anfragt. Also muss die Email irgendwie nach und nach aggregiert werden, bis alle Infos, Termine, Kosten, Durchlaufstellen usw. geklärt sind.
Eine formlose Emailkommunikation dann sicher im Sinne des Kunden, wenn dabei keine Informationen verloren gehen und Vorgänge nach Möglichkeit beschleunigt werden können.
Im Extremfall (negativ) landet man in der Emailverarbeitungskette des Amtes und bekommt alle internen Weiterleitungen und Anfragen brühwarm mit. Lustig, nervig, wie man's nimmt.
Da diese Anwendungsfälle unbekannt sind, würde mir ganz allgemein sowas vorschweben:
Original Emails unberührt lassen, bei der Bearbeitung Markierungen anlegen und mit Schlagwörtern zu "erfüllt", "offen", "Termin" usw zu versehen. Die Markierungen werden als Extrakt in ein separates Dokument (oder Datenbank) übernommen und können beliebig nachbearbeitet und weiterverwendet werden, z.B. reportet, chronologisch oder umgekehrter Ausdruck, Übernahme in die Antwort, etc..
Eine Optimierung im Sinne von Ausschneiden und Platz sparen halte ich für sehr Fehleranfällig. Ein Sachbearbeiter sollte im Zweifel immer Zugriff auf Originaldokumente haben (jede einzelne Email) und im Idealfall alles per Extrakt, Artefakt greifbar haben, was ja wohl auch eine Hauptfunktion von DMS ist.