Sie sind nicht angemeldet.

1

Donnerstag, 25. Juli 2024, 14:03

Warum muss die Datenbankumstellung bezahlen?

Hallo zusammen,

wie alle wissen läuft Medical Office aktuell mit einer veralteten bzw. bald nicht mehr unterstützten Datenbank. Wenn ich es richtig verstehe, ist der aktuelle Betrieb mit Firebird eigentlich bereits fahrlässig. Deswegen sollen ale Nutzer auf Maria DB umstellen. Die Kosten für die Umstellung durch meinen IT-Dienstleister muss ich aber bezahlen. In unserem Fall kostet das ca 1000 Euro.

Ich hatte immer gedacht dass ich durch meinen Vertrag mit Indamed eine funktionierende Software gekauft hätte. Ich habe selbst an meiner Praxis-IT nichts umgestellt und ich hatte auch keinerlei Einfluss auf die Wahl der Datenbank. Wie ist die Begründung, dass ich als Kunde die Datenbankumstellung bezahlen muss?

Habe ich überhaupt eine Wahl? Bin ich der Einzige, der das Vorgehen fragwürdig findet?

Grüße
Peter Saupp

2

Donnerstag, 25. Juli 2024, 14:21

Hallo,
Ich finde die oft berichteten 1000€ auch zu hoch, von unserem Partner zum Glück weniger (je nach Datenbankgröße).
Generell finde ich es nachvollziehbar Routinekosten im Wartungsvertrag zu haben und Sonderfälle extra zu bezahlen, beim Installateur mit jährlicher Heizungswartung oder PKW mit Jahreskontrolle das selbe.
Updates wie die App, neue Oberfläche, neue ePA gibt es ohne Extrakosten, das ist bei Mitbewerbern ganz anders, wir mussten früher z.B. mal 300€ für den bundeseinheitlichen Medikamentenplan zahlen, bei Indamed nicht.

Allenfalls könnte Indamed ein noch sparsameres Umstellungs-Procedere erstellen, aktuell zahlt man gefühlt 4 Stunden Fernwartung von denen wohl 2 Stunden warten auf Konvertierung sind. Die Support Partner sind aber selbstständig und kalkulieren selbst, Indamed kann nichts vorschreiben.

LG C.Schnell

3

Donnerstag, 25. Juli 2024, 15:50

Ich denke auch, es wäre fair, wenn man dem Kunden die Wahl lassen würde

  • Umstellung auf eigenes Risiko mit eigenem Kenntnisstand und einer Anleitung. Eventuelle Nacharbeiten macht dann der FLS gegen Stundenlohn
  • Umstellen als Full-Service im Rahmen einer Pauschale. ob die dann wirklich 1000 € betragen muss, darüber lässt sich sicherlich streiten. Das ist das Problem von pauschalen. Für den kleinen Kunden ist es wahrscheinlich zu viel und für die Groß Praxis wahrscheinlich zu wenig

4

Donnerstag, 25. Juli 2024, 16:49

ich behaupte dass ich viel Erfahrung habe, ich hätte die Datenbank nicht ohne komplette Hilfe umgestellt. es gibt zu viele dinge im Nachhinein die zwicken (können). selbst MO deinstallieren ist keine einklick-Lösung.

und etwas im Nachhinein aufarbeiten zu müssen ist intensiver von Zeit und Leistung (ist mein Eindruck in dem Fall). also lieber jemanden nehmen der das dauernd macht in dem Fall. - das meiste ist eh wartezeit - einen Tag am Ende der Woche ist sicherlich nicht verkehrt, vllt ein extra urlaubstag.

ich würde auch über die Kosten diskutieren, und es wäre schön wenn es eine gewisse Transparenz gäbe/Pauschale. System /Server plus Anzahl mobilarbeitsplätze.
ich denke Warten ist zum jetzigen Zeitpunkt nicht verkehrt, bis die Umstellung noch flüssiger läuft gewisse Probleme Lösungen haben.

ich hatte umgestellt, weil ich neugierig war, ich probiere gerne aus, da ich relativ viel von dem ganzen zeug überblicke und zurückstellen könnte. für den Produktivbetrieb würde ich als durchschnittspraxis aber eher noch im funktionierenden System bleiben, bis offiziell empfohlen wird, "bitte alle umstellen".

MarcAllef

unregistriert

5

Freitag, 26. Juli 2024, 01:18

Wir haben umgestellt. Bin sehr zufrieden mit der neuen Datenbank, ABER:
- Die Umstellung lief nicht glatt. In unserem Fall hat der FLS (Ein von mir höchst geschätzer MO-Spezialist von Jupitec) sogar Indamed wegen Fehlern "ins Boot geholt".
- Mit ein paar Tricks ist eine "kaputte" Umstellung kein Thema: Dann arbeitet man eben vorläufig mit der alten DB weiter, und versucht es später nochmal.
- Die Umstellung ist echt NICHT trivial. Es gibt Fallstricke. Sollte man eigentlich nicht in Eigenregie machen.
- Ich habe Verständnis dafür, dass Indamed die Umstellung nicht mit sehr viel Aufwand voll automatisch per Update ausrollt. Wegen der unterschiedlichen Technik bei den Kunden ist das kaum automatisch machbar.
- Die Konvertierung dauert einfach ihre Zeit.
- Ich finde völlig richtig, dass die ausführende Firma den nicht unerheblichen Aufwand eigens bezahlt bekommt.
- Es ist aber wahrscheinlich auch richtig, dass den meisten Kunden die verwendete Datenbank völlig egal ist. Es kommt auf Sicherheit und Performance an. Egal, mit welchem Tool. Und ich bin neugierig, wie Indamed die Kostenabwälzung begründet: Niemand hat verlangt, dass die FB verwenden, oder zu MariaDB wechseln. Wir zahlen ja für die Software-Pflege, da darf meiner Meinung nach der Wechsel eines "internen Tools" einfach drin enthalten sein. Wir zahlen ja auch nichts für ein Java-Update. Ich sehe daher das aktuell schon so, dass die Kosten natürlich dem FLS bezahlt werden müssen, aber bitte von Indamed.

An anderer Stelle wurde mal auf die Compugroup verwiesen: Ich habe gesehen, dass die die Kosten für eine neue Oracle-Lizenz auf ihre Kunden abwälzen. Das kann ich zwar nicht nachvollziehen, aber das kann hier kein Thema sein. Irgendwie ist das zur Zeit "IN"!

6

Freitag, 26. Juli 2024, 12:38

Vielen Dank an alle für die Rückmeldung. V.a der letzte Beitrag spricht mir aus der Seele.

Grüße und schönes Wochenende!

7

Freitag, 26. Juli 2024, 18:14

Ich habe meinen Server auch umgestellt. Die Datenbank war schon vor zwei Jahren umgestellt worden auf Speicherung in Dateisystem. Von daher war die Umstellung jetzt zeitlich relativ schnell erledigt (30-45 Minuten). Allerdings wurden drei Tabellen nicht mit konvertiert, es gab eine Fehlermeldung. Da musste dann wirklich der Second Level Service ran. Zusammen haben wir das denn dann in 15 Minuten erledigt. Allerdings was auch der SLS erstaunt, warum die Tabellen nicht konvertiert wurden, und konnte sich das Ganze nicht erklären. Ich denke mal, es gibt noch Optimierungsbedarf bei der Konvertierung…

Die beiden mobilen laufen noch auf der alten Datenbank, das mache ich dann mal bei Gelegenheit.