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. :kotz: ;-)

Zitat:

Zitat von Ghostwalker (Beitrag 1469430)

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!!! :idea:

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. :wall:

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)

[stahli]

Danke Euch allen!

Die Meinungen gehen ja ganz schön auseinander.

Ich taste mich mal ran (erst mal die Zuordnungslogik) und werde vor allem mit unserer IT sprechen.

[TiGü]

Frag vor allen mal die IT, ob die überhaupt Bock haben eine selbstentwickelte In-House-Lösung zu supporten, wenn du nicht mehr da bist.

[Pfaffe]

Nebeninformation:
"Mit jährlich 20 Millionen Euro in den Jahren 2020 bis 2024 unterstützt das Hessische Digitalministerium die Kommunen bei der Digitalisierung der Verwaltung."
https://digitales.hessen.de/digitale...waltung-hessen
https://digitales.hessen.de/cio/onlinezugangsgesetz-ozg

[bernau]

Zitat:

Zitat von TiGü (Beitrag 1469507)

Frag vor allen mal die IT, ob die überhaupt Bock haben eine selbstentwickelte In-House-Lösung zu supporten, wenn du nicht mehr da bist.

Ich formuliere mal um:

Frag vor allen mal die IT, ob die überhaupt Bock haben eine fremd entwickelte Lösung zu supporten, wenn die Entwicklungsfirma nicht mehr da ist.

Ich habe schon Softwareprojekte bei meinen Kunden gesehen, die von großen Firmen durchgeführt wurden. Immer wenn Änderungen an dem Projekt notwendig waren, dann war der ursprüngliche Entwickler nicht mehr verfügbar und ein neuer Entwickler musste sich tagelang einarbeiten. Das passierte nicht nur einmal, sondern mehrfach. Und das für Stundensätze, bei denen mir die Tränen kommen. Also egal, ob die Entwicklung Inhouse ist oder extern. Man muss immer damit rechnen, dass eine Software nicht weiter supportet werden kann.

Will damit sagen, man kann Stahli nicht grundsätzlich davon abraten und man kann nicht grundsätzlich zustimmen.

Es kommt immer darauf an, was vereinbart wird. Stahli sollte vorher die Grenzen stecken, und den ersten Step machen. Wenn alle zufrieden sind, kann man sich danach wieder an den Tisch setzen und weiteres vereinbaren.

[jobo]

Vielleicht wäre es auch möglich -sinnvoll auf jeden Fall- ein kleines Pilotprojekt zu vereinbaren, statt in die Vollen zu gehen.

Da könnte man API, Laufzeitverhalten, Performance u.a. testen. Und die Gelegenheit nutzen, Kommunikationsbereitschaft und "Performance" der Beteiligten auszuloten (von d3 bis zu den Kollegen und anderen Dienstleistern).

Kleines, festes Budget für einen Abschlussbericht mit Aussagen zu Realisierbarkeit, erwartbaren Aufwänden und Nutzen.
Das böte Dir vor allem die Möglichkeit für einen "fairen" Start und auch einen sauberen Rückzug, wenn sich größere Hürden zeigen.

[haentschman]

Zitat:

Das böte Dir vor allem die Möglichkeit für einen "fairen" Start und auch einen sauberen Rückzug, wenn sich größere Hürden zeigen.

+1 :thumb:

[stahli]

Ja, das meinte ich so mit #11.

Ich werde erst mal ein kleines Projekt mit Datenbank versuchen und die grundsätzliche Funktionalität umsetzen.
Wenn das dann überzeugt, könnte man die nächsten Schritte angehen...

[TigerLilly]

Hmm, ich weiß nicht recht. Machst du das privat oder in deiner Freizeit? Oder ist das eh dein wirklicher Job? Wer macht dann deine jetzige Arbeit?

Ein professionelles Projekt braucht immer ein professionelles Projektmanagement + die Frage ist, wer das übernimmt. Da geht es ja auch um Budgets (Steuergeld!) und Manpower. Das will schon gut geplant sein. Auf ein "mach mal und schauen wir dann" würd ich mich nicht einlassen.

[dummzeuch]

Zitat:

Zitat von TigerLilly (Beitrag 1469840)

Ein professionelles Projekt braucht immer ein professionelles Projektmanagement + die Frage ist, wer das übernimmt. Da geht es ja auch um Budgets (Steuergeld!) und Manpower. Das will schon gut geplant sein. Auf ein "mach mal und schauen wir dann" würd ich mich nicht einlassen.

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. Das stellte sich dann als gut genug oder zumindest besser als die bisherigen Lösungen heraus und wurde eingesetzt. Wenn man Glück hatte, hat rechtzeitig jemand daran gedacht, den Sourcecode zu sichern.

Das muss noch nicht einmal ein echtes Prgramm sein, ein komplexes Excel-Dokument mit ein paar Makros oder eine Access-Datenbank mit ein paar Formularen tut es schon.

Die Leute, die diese Tools entwickelt haben, gehen jetzt so allmählich in Rente und langsam macht sich Panik breit. An sowas sind schon Firmen Pleite gegangen.

[stahli]

Ich würde das teils in meiner Freizeit machen und teils in der Arbeitszeit. Je nachdem, wie es sich eintakten lässt.
So ist auch das eigentliche Projekt (AW) entstanden.

Wenn ich schon mal ein Ok für ein neues AW bekommen hätte, könnten wir sicher schon lange damit arbeiten. Aber so scheitert es seit Jahren an Zuständigkeiten und Absprachen.
Ich will jetzt mal sehen, dass wir etwas voran kommen.

Das grundsätzliche Ok für ein AwPost sehe ich jetzt schon mal positiv. Wenn mir da etwas gelingt (erst mal als Basis) könnte darauf weiter aufbauen.
Ich habe jetzt noch 1 Woche Urlaub und werde nächstes Wochenende erst mal zu Hause FB installieren und schauen, ob ich damit noch zurecht komme. Ist für mich Jahre her.

Wenn ich wieder im Dienst bin muss ich dann mal sehen, dass mich die IT Delphi und FB installieren lässt. Wird aber etwas später werden, da dann erst mal meine Kollegin im Urlaub ist und ich etwas aufarbeiten muss.

[TigerLilly]

Zitat:

Zitat von dummzeuch (Beitrag 1469842)

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:

Zitat von TigerLilly (Beitrag 1469869)

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. :zwinker:
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 :stupid:),
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.

[TiGü]

Ich knabbere gedanklich immer noch an dem Punkt, dass im Jahre 2020 in einer deutschen Behörde/Amt E-Mails ausgedruckt und wieder eingescannt werden.

:shock:

[stahli]

Das tut mir leid.

Derzeit werden sie allerdings i.d.R. nur nach Abschluss eines eMail-Verkehrs ausgedruckt und abgeheftet (archiviert).

Bei meiner Frage ging es jetzt darum, wie ich neben der schriftlichen Post mit eMails umgehen sollte, falls ich so ein Tool tatsächlich umsetzen darf.

Ich kann mir die Welt halt nicht komplett neu machen, sondern nur ein wenig schöner.

[himitsu]

Bei Mails setzen unsere Kunden auf Outlook, also den Server.

Alle eingehenden und ausgehenden Mails müssen über diesen gehen und werden dort dauerhaft (oder so) gespeichert.

[stahli]

Aber wenn etwas einem Vorgang zugehörig ist, muss es auch diesem zugeordnet werden.

Wenn also ein Kunde im Mai zwei Mülltonnen anmeldet und im Juni wieder eine abmeldet muss das irgendwie in dem Vorgang nachvollziehbar sein. Dazu kann man nicht auf einem Mailserver suchen.

Natürlich wäre ein Verwaltungsprojekt super, das gleichzeitig als Mailclient arbeiten würde, aber...

[Uwe Raabe]

Zumindest die Onlineversion von d3 kann aber auch mit MSG-Dateien umgehen.

[generic]

Zitat:

Zitat von Uwe Raabe (Beitrag 1470915)

Zumindest die Onlineversion von d3 kann aber auch mit MSG-Dateien umgehen.

Sollte man aber vorsichtig mit sein, weil abhängig vom Connector werden die MSG auch mal gerne in DGIX umgewandelt.
Das ist ein D3 eigenes Format.

[dbsquar3d]

Zitat:

Zitat von freimatz (Beitrag 1469445)

stahli, da hast Du ein Fass aufgemacht. Und da unten da wird es sehr klebrig. :kotz: ;-)

Zitat:

Zitat von Ghostwalker (Beitrag 1469430)

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.

Moin zusammen,

habe mich hier auch mal angemeldet, da ich vor dem gleichen Problem stehe. bitfarm habe ich mir aus den oben genannten Gründen auch mal genauer angeschaut, bezüglich open source habe ich mich hier mal schlau gemacht. Hast du noch eine andere Alternative für ein DMS gefunden?

[stahli]

Als Datenspeicher ist bei uns d.3 vorgegeben (morgen soll ein Gespräch dazu erfolgen).

Mein Part wäre, die Gliederung und Zuordnung von Schlüsselnummern und Suchbegriffen zu vereinfachen.
Ich will vermeiden, das alles für jedes Dokument händisch eintippen zu müssen.

Hier mal noch ein Thread, der sich mit dem zerteilen von pdf´s befasst: https://www.delphipraxis.net/205030-...-zerlegen.html
So will ich ermöglichen, einen Stapel Post auf einmal zu scannen und das Bündel danach einfach zerteilen und zuordnen zu können.

[codingmind91]

Moin liebe "Delphi-aner",

da ich bei einem neuen Projekt jetzt ebenfalls bei dem Thema Dokumentenverwaltung angekommen bin, habe ich mich hier mal angemeldet, um Erfahrungen austauschen zu können.

Insbesondere was das Thema "Contract Management", also Vertragsmanagement angeht. Bei mir wird es in diese
Richtung gehen. Hat da jemand mit Delphi bereits Erfahrungen machen können? Gerne auch im Open-Source Bereich.

Danke für eure Hilfe :)

[stahli]

Bei uns soll die Aufgabe später weitestgehend im d.3 erledigt werden.
Dazu sieht das d.3 auch eine Script-Option vor, die die Zusammenfassung von Metadaten vereinfachen soll - also quasi das, was ich machen wollte.

Mal sehen, was draus wird. Bestimmt nichts kurzfristiges...

Also thematisch bin ich hier erst mal wieder raus. :-/