Dokumentverwaltung

[stahli]

Hallo Gemeinde,

ich habe das Ok für den Aufbau eines Dokumenten-Verwaltungssystems. Bedingung ist die Nutzung des vorhanden d.3ecm

Ich will mal die Umstände etwas zusammenfassen und Euch bezüglich grundsätzlicher Meinungen und Erfahrungen fragen.
(Wird daher etwas ausführlicher.)


Arbeitgeber:

Ich arbeite bei der Stadtverwaltung, nicht als Programmierer. Vor 25 Jahren habe ich mit Delphi und der BDE ein Projekt zur Verwaltung unserer abfallwirtschaftlichen Vorgänge aufgebaut.
Das sollte schon lange mal erneuert werden, was aber jeweils wieder aus organisatorischen Gründen gescheitert ist.

Jetzt möchte ich zumindest mal unsere Post digital verwalten, die wir aktuell in 300 Ordnern sammeln (bzw. in 600, da der Entsorgungsbetrieb auch nochmal Ordner hat).

Ich habe jetzt das Ok, ein solches Projekt anzugehen.

Ich darf auch meine Delphi 10.4 Prof - Lizenz nutzen, sowohl vom Arbeitgeber aus als auch von Emba aus (hatte ich schon mal abgeklärt, sofern nur ich selbst damit programmiere).

Bedingung ist vom Arbeitgeber her, dass ich keine einfache Datenbank nutze, sondern das vorhande d.3 (aus Sicherheitsgründen). Welche Schnittstellen es genau gibt, muss ich noch abklären. Den zuständigen Kollegen konnte ich noch nicht sprechen.
Ich denke aber mal, dass das grundsätzlich machbar sein wird. Hat damit jemand von Euch mit dem d.3ecm (und Delphi) Erfahrungen?


Unser Projekt:

Mein Programm heißt "AW" (für AbfallWirtschaft).

Wir verwalten damit zu allen Grundstücken diverse Daten zur Abfallentsorgung, u.a. auch Eigentümer und Verwalter (Kunden).

Ich will realisieren, dass man bei der Arbeit im AW (das alte Programm ist halt aktuell noch gegeben) über Knopfdruck die Post für das aktuelle Grundstück und/oder Kunden bzw. Verwalter aufrufen kann.
Diese würde in einem zweiten Programm "AwPost" dargestellt und verwaltet werden. Das d.3 soll als reines Lager (also quasi dumme Datenbank) genutzt werden.
AwPost soll die Zuordnung der Dokumente zu den Projektdaten (Straße, HausNr, Grundstücksnummer, Objektnummer, SchuldnerKdNr, VerwalterKdNr...) vornehmen.

Was ich nicht will ist, dass man in das d.3 wechselt und dort nochmal nach dem Grundstück oder dem Kunden suchen muss.
Gar nicht akzeptabel wäre, im d.3 ein Dokument zu speichern und dabei die Zuordnungen händisch vernehmen zu müssen. Das können durchaus mal 20 oder 30 Zuordnungen pro Dokument sein.

Wenn die Post digital verwaltet werden soll, muss also ein Tool existieren, das die Herstellung der Verküpfungen vereinfacht und auch die Suche von Dokumenten je nach aktueller Arbeit im Haupt-Projekt ermöglicht.

Weiterhin wäre ein kleines „Ticketsystem“ erforderlich, mit dem man die Post zur Bearbeitung an bestimmte Mitarbeiter weiter verteilen kann.

Das wäre halt mein Part.

Natürlich wäre es gut, ein komplettes neues AW aufzubauen, das AwPost integriert, aber das ist erst mal unrealistisch. Also ist ein zweites Tool erforderlich.

AwPost könnte aber, wenn es denn genutzt wird und funktioniert, in ein späteres neues AW eingebunden werden. Insofern wäre die Arbeit jetzt nicht umsonst.


Datenstruktur:

Wir verwalten grundsätzlich Grundstücke mit Grundstücksnummern:

12345 | Hamburger Str. 1
12346 | Hamburger Str. 2

Zu jedem Grundstück gibt es ggf. mehrere Entsorgungsobjekte:

12345000 Wohngrundstück
12345001 Bäcker
12345002 Fleischer
12346000 Wohngrundstück
12346001 Versicherungsbüro

Weiterhin gibt es Kunden mit Kundennummern:
0034567 Müller
0045678 Meier
0054356 Hausverwaltung Schulze

Zu jedem Entsorgungsobjekt gibt es einen Schuldner und ggf. einen abweichenden Verwalter (jeweils eine Kundennummer).

Ein Dokument kann mehrere Objekte betreffen und mehrere Kunden.

Z.B. kann Müller an Meier 30 Grundstücke aus 5 Straßen verkaufen und Schulze kann gleichzeitig als Verwalter eingesetzt werden. In dem Fall müssten dem Dokument also 30 Objektnummern 3 Kundenummern zugeordnet werden.

Mein Tool hat die Aufgabe, diese Arbeit zu optimieren. Das muss extrem einfach gehen, sonst macht die Arbeit niemand.



Meine Überlegung:

Ursprünglich hatte ich gedacht, einfach eine Datenbank zu nutzen (wie Holge es vor einiger Zeit mal gezeigt hat).

Das Tool könnte einen Ordner überwachen und alle Dokumente, die darin landen, automatisch importieren.

Ein Mitarbeiter könnte die Post erst mal an die zuständigen Bearbeiter „verteilen“ (also die betreffenden Mitarbeiter ankreuzen).

Diese könnten im AW ein Objekt raussuchen und „Objekt und Kunden zuordnen“. So würde die Zuordnung hergestellt. Weitere Zuordnungen könnte man nachholen.

Später könnte man das Objekt wieder im AW auswählen und über „Post anzeigen“ wieder an das Dokument gelangen.

Insofern wäre das nicht zu kompliziert.

Man könnte auch eine kleines Thumnail und einen Plaintext (nach OCR) speichern.


d.3ecm:

Jetzt hieß es, dass das d.3 zwingend zu nutzen wäre.

Ich weiß so viel, dass das OCR unterstützt und sogar Gesichter erkennen kann usw, was allerdings für uns nur teilweise interessant ist.

Ob und wie man das von Delphi aus nutzen kann, weiß ich noch nicht.

Ich werde das diese Woche mit unserer IT besprechen.




Wenn jemand von Euch diesbezügliche Meinungen oder Erfahrungen hat, dann gerne her damit…


Gruß Stahl

[Ghostwalker]

Moinsen,

Also..mit Stadtverwaltung hab ich zwar jetzt keine Erfahrungen (außer denen, die jeder Bürger schon mal hatte). Aber mit DMS hatte ich schon zu tun.

Aus meiner Erfahrung kann ich da sagen, das es im wesentlichen 2 Punkte gibt:

1. Zuordnung (wie du schon so schön ausgeführt hast)

Hier auf alle Fälle genau Abklären, nach welchen Regeln/Kriterien ein Dokument zu den anderen Daten zu geordnet werden muß. Diese Zuordnung würd ich dann auf alle
Fälle kapseln vom Rest, denn, auch wenn jeder jetzt sagt, so und so isses Richtig. In 2 Monaten schaut die Welt ganz anders aus

2. Verschlagwortung

Neben der reinen Zuordnung, würd ich zusätzlich Schlagworte für jedes Dokument vergeben, so das der Anwender über eine SuFu schnell an ein bestimmtes Dokument gelangen kann.

Bsp. Anwender sucht nach der Rechnung vom 12.12.1999 für Herrn Müller. Da will der Anwender nicht erst alle Objekte des Herrn Müller raussuchen und dann die passenden Rechnungen.

[Pfaffe]

Ist das nicht ein Fall für eine Standardsoftware?

-- Ich arbeite bei der Stadtverwaltung, nicht als Programmierer. Vor 25 Jahren habe ich mit Delphi und der BDE ein Projekt zur Verwaltung unserer abfallwirtschaftlichen Vorgänge aufgebaut.
-> Ist die Nachfolge geklärt?

-- Jetzt möchte ich zumindest mal unsere Post digital verwalten, die wir aktuell in 300 Ordnern sammeln (bzw. in 600,
-> Gesetze wie Datenschutz usw.?

[freimatz]

stahli, da hast Du ein Fass aufgemacht. Und da unten da wird es sehr klebrig.

Zitat von Ghostwalker:

Moinsen,

Also..mit Stadtverwaltung hab ich zwar jetzt keine Erfahrungen (außer denen, die jeder Bürger schon mal hatte). Aber mit DMS hatte ich schon zu tun.

dito bei mir.

Schau mal das an https://www.bitfarm-archiv.de/dokume...versionen.html. Da gibt es auch eine Open-Source wo Du auch Code anschauen kannst.

[Uwe Raabe]

Ich habe auch schon d3 angebunden, allerdings die Web-Version. Dort läuft das über eine REST-Api.

[TiGü]

Ganz ehrlich: Mach es nicht selbst!!!

Du bindest dir nur Probleme ans Bein und die Stadtverwaltung steht doof da wenn du länger krank bist, Burnout hast vom ständigen neuen Feature-Wünschen seitens der Kollegen oder in (Früh-)Rente gehst.

Dann müssen deine zukünftigen Kollegen und/oder Nachfolger irgend so eine informationstechnische Sonderlösung reverse engineeren und verstehen oder ganz entsorgen plus Datenrettung aus X Jahren.

Ich kenne jetzt nur dieses Produktvideo von denen (https://www.youtube.com/watch?v=5gJjdmAJcE8), aber die Software kann doch schon recht viel, integriert sich überall, hat nen Haufen Schnittstellen, bietet ein Webbrowser Frontend und ihr habt anscheinend eh schon eine Lizenz von denen.

Es wäre schlauer und ggf. billiger mit den Anforderungen an den Sales/Vertrieb von d.3ecm heranzutreten und fragen, ob man eure Anforderungen in deren Software abbilden kann.
Und wenn zwei, drei Dinge fehlen: Wie aufwändig und teuer wäre es das nachzurüsten?

[IBExpert]

Unter der Vorgabe "d.3 muss zwingend benutzt werden" würde ich das Projekt auch eher komplett ablehnen.

Nicht das das d.3 unbedingt schlecht sein muss, ich kenne es nicht, aber bei dem was ich unter "DMS programmieren"
verstehe, fällt es ziemlich sicher nicht, was man dir da zugesteht.

Es wird darauf hinauslaufen, ohne ende mehr oder wenig gut dokumentierte API Funktionen zu suchen,
diese versuchen einzubinden, lahme Reaktionszeiten deinen Anwendern zu erklären, ohne das du da
was für kannst und was noch viel schlimmer ist, irgendwann wollen die anwender nur simple Änderungen
oder Erweiterungen am User Interface haben und du wirst leider immer wieder sagen müssen: geht nicht
(oder auch ich weiss nicht wie das geht, weil es nirgendwo dokumentiert ist). und irgendwann
wird d.3 vielleicht mal d.4 und du kannst alles in die Tonne hauen oder der ganze Laden wird
aufgekauft und von ELO ersetzt oder sonstwem, der dann die Plattform einstellt.

Die ganzen Vorteile, die eine Eigenentwicklung haben kann, sind unter der Vorgabe eigentlich schon
vernichtet.

Stadtverwaltungen sind da sicherlich noch schlimmer als Konzerne, daher ist mein liebster
Kundenkreis für Individualsoftware immer der Inhaber-geführte Mittelstand, bei dem ich mit dem
Entscheidungsträger am Tisch sitze und ihm erkläre, wie das zu machen ist, ohne das der mir erklärt,
wie ich das technisch lösen soll.

Ich wäre da auch sehr vorsichtig wie die meisten hier, bevor du irgendwelche Zusagen machst.

[himitsu]

Wir haben bei uns das DMS selbst gebaut.
* zuerst war es eine Tabelle mit den Dokumenten als BLOB
* später wurden die Dokumente auf die Festplatte ausgelagert, inkl. Verwaltung verschiedener Rootpfade je Dokumenttyp (mit speziellen Behandlung für z.B. Versionierung oder Archivierung auf Worm-Laufwerken)
* es war aber auch schon möglich auch Werlinkungen zu externen Dateien zu haben
* und zuletzt wollte ein Kunde mehr, so das wir nun noch eine öffentliche API bereitstellten, wo sich aktuell ELO und nun auch das neue WebProjekt dranhängen können
* Anfang mehr auf ELO ausgelegt, aber nun etwas verallgemeinert, denn wer weiß was in Zukunft kommt
* also hauptsächlich machen wir es noch selbst und ELO zieht sich eine Kopie, bzw. kann Änderungen zurückspielen
** und ob die Dateien nun bei uns liegen oder als Verlinkung auf ein Verzeichnis von ELO umgeleitet werden (über die alten Dokumentenverlinkung), ist fast egal

[jobo]

Ich sehe die d3 Vorgabe auch sehr kritisch.

Ein DMS kann für mich Dokumente verwalten, archivieren, durchsuchen, verschlagworten, rausmailen, per Mail annehmen usw. (gesetzteskonform archivieren, Zugriffsrechte und der ganze Kram)
sowas in der Art, dafür ist es da.
Klar, d3 ist kein Krauter, es kann mehr. Aber will man das?

Aber darauf Business Cases aufzubauen, wie Du sie beschrieben hast, macht 0 Sinn.
Du kannst ein Tool bauen, das alle Business Cases abfackelt und dabei Dokumente gemäß ID sucht oder anlegt oder updated und diese Links verwaltest Du in Deinem Tool mit. Fertig.

Für Dein Tool verwendest Du eine normale Datenbank, wie sich das gehört.

Wer hat die d3 Vorgabe gemacht? Ein Fachmann? Welches Fach? Ein Einkäufer, ..?

@gleich d3 selber fragen: Die machen bestimmt irgendwas, aber sicher nicht preiswert. Und man muss wahrscheinlich bei den Verträgen höllisch aufpassen, dass deren Individual-Lösung die Versionswechsel der eigenen Plattform halbwegs überlebt.

@Schnittstellen:
Es gibt DMS Schnittstellen, die produktunabhängig sind. Die muss/wird d3 auch unterstützen. Das wäre m.E. der beste Ansatzpunkt.

[TiGü]

Zu Bedenken:

Wenn ich dein Profil richtig lese, bist du nur bei der Verwaltung angestellt und nicht verbeamtet.

Es besteht immer die Gefahr, dass das Projekt deinerseits scheitern könnte und dann kann es vielleicht ganz schnell sein, dass im nächsten Budgetplan kein Posten mehr für dich einkalkuliert wurde.

Wäre mir zu heiß.

Denk dran:
"Nobody ever got fired for buying IBM" (IBM für Marktführer/Standard/fertige Lösung)