Dokumentverwaltung

[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 von 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.

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.