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.