Moregate

Projekte, Anfragen und Wissen — auf Ihrem Server.

Drei Anwendungen für die tägliche Arbeit im Team: ein Vorgangssystem mit Sprints und Zeiterfassung, ein Wiki für alles, was dabei an Wissen entsteht, und ein Service Desk für die Anfragen Ihrer Kunden. Sie laufen auf einem Linux-Server in Ihrem Netz. Wenn Ihnen der Betrieb zu viel ist, übernehmen wir ihn.

Version 3.0 mit lokaler KI – Ihre Daten bleiben sicher, auch beim Einsatz von KI.

Drei Anwendungen, die voneinander wissen

Jede ist für sich nutzbar und wird einzeln lizenziert. Zusammen teilen sie Anmeldung, Benutzerverzeichnis und Verweise: Eine Wiki-Seite zeigt den Stand der Vorgänge, ein Vorgang verlinkt die Dokumentation, und aus einer Kundenanfrage im Service Desk wird ein Vorgang, ohne dass jemand abtippt.

MGProject

3.0.2

Vorgänge, Sprints und Zeiten in einem System

Ein vollständiger Issue-Tracker für Teams, die Projekte, Support und Entwicklung nicht auf drei Werkzeuge verteilen wollen. Vorgangstypen, Workflows, Felder und Masken definieren Sie selbst — ohne dass jemand anderes entscheidet, wann sich daran etwas ändert.

  • Vorgänge und WorkflowsEigene Vorgangstypen, Statusübergänge, Bedingungen und Nachbedingungen. Felder, Feldkonfigurationen und Masken pro Projekt.
  • Scrum und KanbanBacklog, Sprints mit Ziel und Laufzeit, Board mit Swimlanes, Burndown und eine Planungsübersicht über alle Projekte hinweg.
  • Service-Desk-AnbindungTickets aus MGService oder Jira Service Management werden zu Vorgängen und behalten ihre Herkunft — auch wenn ein Vorgang beim Sprintabschluss geteilt wird.
  • ZeiterfassungArbeitszeiten am Vorgang, Kommen/Gehen mit Tagesjournal, Auswertung nach Person, Projekt und Zeitraum.
  • Suche und AuswertungDie Abfragesprache MQL, gespeicherte Filter, Dashboards mit Gadgets und Berichte mit PDF- und CSV-Export.
  • AnbindungenAnmeldung über Entra ID und Passkeys, Bitbucket-Projekte und Repositories an Epics, Import bestehender Jira-Projekte mit Vorgängen, Sprints und Zeitbuchungen.

MGWiki

3.0.2

Das Wissen des Teams an einem Ort

Ein Wiki mit Bereichen, Seitenbäumen und Versionsständen. Gedacht für Dokumentation, die neben der täglichen Arbeit entsteht und deshalb schnell zu schreiben sein muss.

  • SchreibenEditor mit Tabellen, Bildern, Codeblöcken und Vorlagen. Jede Änderung erzeugt eine Version, Stände lassen sich vergleichen und zurückholen.
  • StrukturBereiche, verschachtelte Seitenbäume, Labels und eine Volltextsuche, die auch Anhänge erfasst.
  • MakrosInhaltsverzeichnis, Seitenlisten, Hinweisboxen, Statusmarker, Diagramme und Einbindungen aus MGProject.
  • ZusammenarbeitKommentare, Erwähnungen mit Benachrichtigung, Beobachtungslisten und Entwürfe, die niemand sonst sieht.
  • Öffentliche HilfeseitenAusgewählte Bereiche als schlanke, lesbare Hilfe-Site veröffentlichen — ohne Anmeldung für Ihre Kunden.
  • RechteBerechtigungen pro Bereich und pro Seite, Anmeldung über Entra ID oder lokal, Lesemodus für abgelaufene Lizenzen.

MGService

3.0.5

Ein Service Desk mit Portal, Queues und SLA-Uhren

Ein eigenständiger Service Desk für Teams, die Anfragen von Kunden annehmen statt eigene Vorhaben zu verwalten. Kundenportal, Warteschlangen, SLA-Uhren und ein Postfach, aus dem Tickets entstehen. Aus MGProject hervorgegangen und ihm zum Verwechseln ähnlich — der Unterschied liegt darin, wofür es gedacht ist.

  • KundenportalEine schlanke Oberfläche für Ihre Kunden: Anfrage stellen, Stand verfolgen, antworten. Mit Live-Chat, wenn es schnell gehen soll.
  • WarteschlangenOffene, zugewiesene, unbearbeitete Anfragen — je Projekt frei zusammengestellt, mit Trefferzahl in der Leiste und Bearbeitung direkt in der Zeile.
  • SLA-UhrenErstantwort, Lösung und Wartezeit beim Kunden, jeweils gegen das Ziel, das am besten passt. Angehalten, solange der Kunde am Zug ist.
  • Postfach-AbrufEin Microsoft-365-Postfach wird abgerufen; aus jeder Mail wird ein Ticket, aus jeder Antwort ein Kommentar daran — genau einmal, auch wenn zwei Abrufe zusammenfallen.
  • Kunden und OrganisationenAnfragen lassen sich mit Kollegen teilen, Organisationen bündeln, wer was sehen darf.

Warum der eigene Server die ruhigere Wahl ist

Der Wechsel in fremde Rechenzentren hat viele Teams Geld und Kontrolle gekostet. Diese sechs Punkte hören wir am häufigsten von Kunden, die zurück ins eigene Haus wollen.

Ihre Daten bleiben in Ihrem Haus

Vorgänge, Anhänge, Kundenanfragen und Zeiten liegen in einer PostgreSQL-Datenbank, auf die nur Sie Zugriff haben. Kein Auftragsverarbeitungsvertrag, keine Drittlandübermittlung, keine Diskussion im nächsten Audit.

Keine Migration, die Ihnen jemand vorgibt

Sie bestimmen, wann eine neue Version eingespielt wird — und ob überhaupt. Ein Update ist ein Aufruf von deploy.sh und dauert rund eine Minute; Konfiguration und Datenbank bleiben unangetastet.

Läuft auch ohne Internet

Fertigung, Labor, abgeschottetes Netz: Die Anwendung braucht nach der Installation keine Verbindung nach außen. Lizenzen werden offline geprüft.

Kalkulierbare Kosten

Eine Lizenz je Nutzerstaffel statt einer Rechnung, die mit jedem Preismodellwechsel neu ausfällt. Was Sie einmal lizenziert haben, läuft weiter.

Bescheidene Anforderungen

Ein Linux-Server mit zwei Kernen und 4 GB RAM trägt beide Anwendungen für ein Team von fünfzig Personen. Betrieb als systemd-Dienst hinter Ihrem vorhandenen Reverse Proxy.

Sie kommen jederzeit wieder heraus

Vollständiger Export nach CSV und JSON, Anhänge als Dateien, die Datenbank ist Ihre. Kein Format, das nur wir lesen können.

Bei Ihnen oder bei uns

MGProject gibt es in beiden Varianten. Die Anwendung ist dieselbe — es geht allein darum, wer den Server pflegt. Sie können später wechseln, in beide Richtungen, mit Ihren Daten.

MGWiki läuft derzeit ausschließlich on-premise. Eine Cloud-Variante ist in Vorbereitung.
On-Premise Sie betreiben es selbst Moregate Cloud Wir betreiben es für Sie
Wo die Daten liegen Auf Ihrem Server, in Ihrem Netz In unserem Rechenzentrum in Deutschland
Betrieb Ihre Administration Wir: Updates, Backups, Monitoring
Zugriff von außen Nur so weit, wie Sie ihn öffnen Über HTTPS, auf Wunsch IP-beschränkt
Updates Sie entscheiden, wann Nach Ankündigung, im Wartungsfenster
Anbindung ans AD Über Entra ID, mit Abgleich des Verzeichnisses Über Entra ID
Anpassungen am System Vollständig, bis hinunter zur Datenbank Über Konfiguration und Schnittstellen
Kosten Je Nutzer und Laufzeit, als Abo Je Nutzer und Laufzeit, dazu eine feste Betriebsgebühr
Start deploy.sh auf einem Linux-Server Umgebung steht am nächsten Werktag
Paket herunterladen Cloud-Zugang anfragen

Installation und Update

Jedes Paket bringt ein deploy.sh mit. Es legt Dienstbenutzer, Verzeichnisse, virtuelle Umgebung und systemd-Dienst an, bindet die Anwendung an localhost und prüft am Ende selbst, ob sie antwortet. Derselbe Aufruf ist später das Update: Code und Abhängigkeiten werden erneuert, Konfiguration und Datenbank bleiben unberührt.

Voraussetzungen
Linux mit systemd, Python 3.9 oder neuer, PostgreSQL oder SQLite. Zwei Kerne und 4 GB RAM reichen für ein Team von fünfzig Personen.
Betrieb
Die Anwendung hört nur auf 127.0.0.1. Für TLS und die öffentliche Adresse setzen Sie Ihren vorhandenen Reverse Proxy davor — HAProxy, nginx oder Apache.
Anmeldung
Lokale Konten, LDAP oder Entra ID. Zwei-Faktor mit TOTP oder Passkey ist eingebaut.
Lizenz
Eine signierte Lizenzdatei je Installation, offline geprüft. Läuft sie ab, schaltet das System in den Lesemodus — es sperrt Sie nie aus.

Einmal in Ruhe ansehen?

Registrieren Sie sich, und wir richten Ihnen eine Testumgebung ein oder schicken Ihnen eine Lizenz für Ihre eigene Installation.