Open-Source-Ticketsystem für ein 8-köpfiges Team: Lohnt sich das oder holt man sich nur Ärger ins Haus?

Rechnet mal den Stundensatz eures Entwicklers gegen. Wenn er nur 4 Stunden im Monat damit verbringt, das Ding aufzusetzen, zu konfigurieren und Fehler zu suchen, kostet das intern schon so viel wie die Jahreslizenz der Cloud. Und was ist, wenn er kündigt? Wer betreut den Server dann? Holt euch definitiv die Cloud-Lösung.

Verrennt euch nicht in Open-Source-Fanatismus. Entwickler lassen gern alles auf eigenen Servern laufen, weil es für sie ein nettes Spielzeug ist. Aber wenn Kundenmails im Spam landen oder der Server abraucht, tragt ihr den Schaden. Wenn Servermanagement nicht euer Hauptgeschäft ist ist ein selbst gehostetes Ticketsystem nur unnötiger Ballast.

Wir haben das in unserer 10-Mann-Agentur mit Open Source probiert. Im ersten Jahr stand der Support dreimal komplett still – wegen Serverabsturz, zerschossener Postfach-Synchronisation und einem Softwareupdate. Super peinlich vor den Kunden. Am Ende sind wir zur Cloud gewechselt: Kostet 200 EUR im Monat, aber wir haben seit zwei Jahren komplett unsere Ruhe.

wie sieht es aus wenn man das Open-Source-System nicht selbst aufsetzt, sondern als Managed-Paket vom Hoster nimmt – bleibt der Wartungsaufwand dann trotzdem an einem hängen?

Weg von der Sammel-Mailbox ist absolut richtig mit 8 Leuten über ein Postfach zu arbeiten ist pures Chaos. halt aber es gibt bei SaaS-Lösungen doch Einsteigertarife für 12–15 EUR pro Nutzer. Plant einfach 100–120 EUR im Monat für 8 Leute ein und spart euch die Kopfschmerzen.

in deutschland sind die dsgvo-strafen echt kein witz. wenn ihr das open-source-system nicht suber absichert und kundendaten leaken habt ihr richtig ärger am hals und die cloud-anbieter bringen die compliance halt schon fertig mit.

Der Tenor hier ist eindeutig: Auch wenn die Software bei Open Source kostenlos ist, fressen der operative Aufwand und die Wartung den Spareffekt im Vergleich zu fertigen Cloud-Lösungen komplett auf. Wenn Serveradministration nicht euer Kerngeschäft ist, fahrt ihr mit einer fertigen Lösung am besten.

Beim Umsetzen gibt es drei Dinge zu beachten. Ein Change-Request-Prozess verlangsamt die Arbeit nicht, sondern beschleunigt sie.

Kein Prozess ohne Dokumentation verbessert sich, weil man nicht weiß, was man verbessern soll. Korrigiert mich, falls ich falsch liege.

An diesem Punkt widerspreche ich dir. Wenn der Umfang wächst, müssen entweder Zeit oder Budget wachsen. Eine dritte Option gibt es nicht.

Absolut. Wenn ich noch etwas hinzufügen darf: Schreibe bei Entscheidungen auch das Worst-Case-Szenario auf, nicht nur das Beste.

Das war's, entschuldige, wenn ich zu lang war.

Danke fürs Schreiben.

das habe ich auch erlebt.

Letztes Jahr haben wir fast genau dasselbe erlebt. Wenn der Umfang wächst, müssen entweder Zeit oder Budget wachsen. Eine dritte Option gibt es nicht.

Das Teuerste an übernommenen Systemen sind unbekannte Abhängigkeiten. Wenn ihr das Ergebnis hier postet, hilft es auch anderen.

Notiert, danke. Bei uns war der größte Zeitfresser die Unklarheit darüber, wer entscheidet.

Das allein zu versuchen, ist der teuerste Weg.

Wenn wir ins Detail gehen: Wenn ihr es zum ersten Mal macht, fangt klein an, die Skalierung kommt später.

In den ersten drei Monaten läuft alles gut, die Probleme tauchen im vierten Monat auf. Das ist meine Meinung, ich behaupte nicht, dass es absolut richtig ist.

Hier habe ich einen Einwand. Der Zahlungsplan sollte an die Projektphasen gekoppelt sein nicht an den Kalender.

Das ist meine Meinung ich behaupte nicht, dass es absolut richtig ist.

Die obige Antwort bringt es auf den Punkt. Wer bei ticketsystem open source hetzt, stolpert alle an derselben Stelle.

Jedes „schauen wir uns später an“ in Meetings bedeutet nicht kalkulierte Arbeit. Das ist meine Meinung, ich behaupte nicht, dass es absolut richtig ist.

Letztes Jahr haben wir fast genau dasselbe erlebt. Je schwerer es ist, eine Entscheidung rückgängig zu machen, desto langsamer solltet ihr sie treffen.

Aus Erfahrung weiß ich das.