Anfragenverwaltung/ Ticketsystem

[steveO_O]

Liebe Community,

ich überlege über die Wintermonate vermutlich würde es aber länger dauern) eine Software für die Verwaltung unserer Anfragen zu schreiben. Wir sind ein kleiner Reiseveranstalter mit ca. 8-10 Leuten im Büro, die phasenweise alle öfter am Tag an der gleichen Exceltabelle rumwerkeln. Das dies nicht ideal, weil Excel nicht dafür gemacht ist, ist klar.
Meine Programmierkenntnisse würde ich als leicht Fortgeschritten beschreiben. Ich weiß, was Funktionen, Listen, Tupel, Dictionaries, Klassen sind. Neu Einarbeiten müsst ich mich in GUI-Themen und vor allem Datenbanken.

Hauptanforderungen wären Aufnahme von Kundenanfragen, Status der Anfrage, Filterfunktionen, evtl. Suchfunktionen, Abgleich mit Datenbanken. Sicherlich gibt es für sowas bereits haufenweise Software. Hauptmotivation für mich wären neben der Kostenersparnis vor allem einiges an Automatisierungs-Potenzial bzw. kleinere Funktionen, zugeschnitten auf unsere Bedürfnisse.

Vom Bauchgefühl her würde ich es mir zutrauen, weil ich auch mal 10 Jahre Entwicklungsingenieur im Maschinenbau war. Dennoch wollte ich nach eurer groben Einschätzung fragen, wenngleich mir bewusst ist, dass das natürlich nur eine grobe Einschätzung aus der Ferne ist:
Wie realistisch ist sowas für mich als 1-Mann-Projekt mit meinen Kenntnissen umzusetzen? Vor allem die Stabilität der Software hätte aller oberste Priorität. Braucht es diesbezüglich jahrelange Erfahrung und Spezialkenntnisse oder kann man sich da in ein paar Wochen einarbeiten?

Viele Grüße
Stefan

[geraldfo]

Als technische Grundlage würde ich Web-Architektur und das Django-Framework empfehlen.

[Sirius3]

Die Anforderung "Stabilität hat aller oberste Priorität" hat bei Eurer Excel-Lösung ja bisher keine große Rolle gespielt

Ob die Aufgabe für Dich bewältigbar ist, oder nicht, kannst Du nur herausfinden, in dem Du anfängst einen Prototypen zu bauen. Guter Ausgangspunkt ist das Django-Tutorial, das eine Schritt für Schritt-Anleitung auch in Datenbanken, Nutzerverwaltung etc. ist.

Was Du nicht machen darfst, ist, Deine Arbeitszeit in Geld umzurechnen, denn dann ist jede andere Lösung deutlich billiger.

[steveO_O]

Ermstal vielen dank für eure Antworten!

Als technische Grundlage würde ich Web-Architektur und das Django-Framework empfehlen.

Was genau meist du damit? Irgendwie scheint es für Web-Architektur mehrere Definitionen zu geben.
Weiß nicht, ob das falsch rüber kam. Die Anwendung soll nicht im Web laufen, sondern auf einem Server liegen, wo es von den KollegInnen genutzt wird. Braucht man dafür trotzdem eine "Web-Architektur" und ein Framework?

Die Anforderung "Stabilität hat aller oberste Priorität" hat bei Eurer Excel-Lösung ja bisher keine große Rolle gespielt
Ob die Aufgabe für Dich bewältigbar ist, oder nicht, kannst Du nur herausfinden, in dem Du anfängst einen Prototypen zu bauen. Guter Ausgangspunkt ist das Django-Tutorial, das eine Schritt für Schritt-Anleitung auch in Datenbanken, Nutzerverwaltung etc. ist.
Was Du nicht machen darfst, ist, Deine Arbeitszeit in Geld umzurechnen, denn dann ist jede andere Lösung deutlich billiger.

Hehe, ja dem darf ich wohl nicht wiedersprechen. Es ist eben eine kleine Firma, die gerade mal mit Excel halbwegs umgehen kann. Die Expertise liegt woanders .
Meinst du dieses https://www.w3schools.com/django/index.php?

[nezzcarth]

Ich glaube, mein Ansatz in dem Fall wäre, mir ein freies Ticketsystem wie Redmine dahingehend anzuschauen, ob man das dafür nicht zurecht biegen kann und die gewünschten Automatisierungen ggf. als Plugin zu realisieren. Redmine gewinnt keinen Schönheitswettbewerb und wird vor allem im Softwareprojektmanagement verwendet, lässt sich aber recht gut anpassen (allerdings wird Ruby/Ruby on Rails verwendet, nicht Python). Hat halt den Vorteil, dass du einen gut abgehangenen, stabilen Kern hast und darauf dann aufbauen kannst.

Wie schon angesprochen, würde man so eine Anwendung, wenn man sie selbst schreibt, heute als (lokale) Webanwendung umsetzen. Und da muss man dann halt diverse Technologien auf einem akzeptablem Stand beherrschen. Sowas als native GUI-Anwendung, die über das Netzwerk kommuniziert, zu implementieren, wäre nach meinem Eindruck etwas aus der Mode.

[geraldfo]

Mit Web-Architektur meine ich, dass die Anwendung eine Web-Anwendung sein sollte.
Es kann trotzdem eine reine Inhouse-Anwendung sein.

[Sirius3]

Nein, nicht irgendeine obskure Webseite, sondern das offizielle Tutorial: https://docs.djangoproject.com/en/5.0/intro/tutorial01/

[steveO_O]

Ich glaube, mein Ansatz in dem Fall wäre, mir ein freies Ticketsystem wie Redmine dahingehend anzuschauen, ob man das dafür nicht zurecht biegen kann und die gewünschten Automatisierungen ggf. als Plugin zu realisieren. Redmine gewinnt keinen Schönheitswettbewerb und wird vor allem im Softwareprojektmanagement verwendet, lässt sich aber recht gut anpassen (allerdings wird Ruby/Ruby on Rails verwendet, nicht Python). Hat halt den Vorteil, dass du einen gut abgehangenen, stabilen Kern hast und darauf dann aufbauen kannst.

Wie schon angesprochen, würde man so eine Anwendung, wenn man sie selbst schreibt, heute als (lokale) Webanwendung umsetzen. Und da muss man dann halt diverse Technologien auf einem akzeptablem Stand beherrschen. Sowas als native GUI-Anwendung, die über das Netzwerk kommuniziert, zu implementieren, wäre nach meinem Eindruck etwas aus der Mode.

Redmine werde ich mir anschauen, wenngleich ich wenig Lust verspüre mich in eine neue Programmiersprache einzuarbeiten. Der Teil mit der Automatisierung würde dann wohl entfallen.

Mit "diverse Technologien" meinst du Web-Anwendungen und Django, oder noch weitere? Ohne es mir im Detail angesehen zu haben (wird nachgeholt), fürchte ich fast, dass der Einarbeitungsaufwand doch etwas zu hoch ist.

Warum genau ist mit "aus der Mode" gemeint? Wirklich nicht mehr empfehlenswert oder einfach nur nicht der heißeste Scheiß? Für eine Firma, die mit 10 Leuten an Excel rumwerkelt könnte es fast schon futuristisch sein^^.

[grubenfox]

Warum genau ist mit "aus der Mode" gemeint? Wirklich nicht mehr empfehlenswert oder einfach nur nicht der heißeste Scheiß? Für eine Firma, die mit 10 Leuten an Excel rumwerkelt könnte es fast schon futuristisch sein^^.

Ich bin zwar nicht gefragt, aber ich neige ja ein wenig zu "nicht der heißeste Scheiß".

* Bei der Web-App darf man sich dann für die GUI mit einer CSS-Bibliothek und JavaScript herumärgern, aber prinzipiell kann man dann mit allen möglichen Geräten (egal ob PC/Mac/Smartphone) mit der Anwendung arbeiten. Hat dafür dann bei exotischen Features von HTML5 oder CCS3 immer die Frage: "wird diese Feature auch von allen relevanten Browsern unterstützt", aber hier sehe ich gerade nichts was solche exotischen Features benötigen würde (ich weiß auch nicht welche eigentlich nur von einem Teil der Browser unterstützt werden. Der Internet Explorer 11 wird bei euch ja wohl nicht mehr im Einsatz sein.)

* Bei der nativen GUI-Anwendung ist man bei der Wahl der nutzbaren Betriebssysteme wohl eingeschränkter, darf sich dann mit den GUI-Bibliotheken und deren Doku und anderen Eigenheiten herumärgern (bei Qt war mal was in Sachen Lizenzen, wxPython nutzt eine C++-GUI Bibliothek und die Doku ist im Zweifel eher für C++ geschrieben, zu Tkinter fällt mir gerade nichts ein... ach doch) und entweder passt die fertige GUI im Aussehen zum Betriebssystem (sieht daher auf einem Mac anders auch als au einem Win-Rechner) oder sie sieht immer identisch aus und passt im Zweifel nicht zu den anderen Anwendungen. Aber wenn ihr alle mit Excel arbeitet, dann ist bei euch wohl nur Windows im Einsatz.

Es hat schon Gründe warum mein letztes GUI-Programm in Python schon über 10 Jahre her ist und ich eigentlich nur noch Kommandozeilen-Anwendungen schreibe... (hauptsächlich der Mangel an Projekten für die sich eine GUI lohnen würde und zum anderen programmiere ich kaum noch in Python... würde aber gerne mal wieder)


Interessant wäre welche Abläufe und Daten so zu erfassen wären bzw. derzeit mit Excel erschlagen werden. In meiner bescheidenen Vorstellung komme ich auf ein paar Auswahllisten (Auswahl von Ländern/Orten/Reiseanbietern/Fluggesellschaften/...), ein paar Textfelder zum erfassen und bearbeiten von Texten, zwei Buttons (einen mit "Daten speichern", einen mit "Vorgang abbrechen"), ... nichts was nicht z.B. mit Tkinter umsetzbar wäre.

Ich glaube der umfangreichere Teil wird all das was im Hintergrund so abläuft. Angefangen mit der Anbindung an eine DB bis ??? (automatischer Datenaustausch mit anderen Systemen zum Buchen von Flügen/Sitzplätzen/Zimmer usw. wäre ein Punkt der mir da in den Sinn kommen würde. Aber das ist sicherlich Zukunftsmusik, jetzt mit eurem Excel macht ihr das aktuell wohl nicht. )

[geraldfo]

Seit ziemlich langer Zeit ist es Standard, Business-Software als Web-Anwendung zu erstellen.
Vorteile:
* Plattformunabhängigkeit; jedes Endgerät mit Webbrowser kann auf die Anwendung zugreifen.
* Ortsunabhängigkeit (man denke an Home-Office oder Außendienst).
* Erst-Installation und Updates müssen nur an einer Stelle (Server) gemacht werden.
* Per API kann mit anderen Webdiensten kommuniziert werden.

Wie schon geschrieben: solange man möchte, kann man den (Web)Server auch Inhouse betreiben.
Wenn man alleine entwickelt, kann man das auf jedem Laptop machen.

Aber:
Es gibt fast unendlich viele verschiedene Konzepte und Technologie-Stacks, um Web-Anwendungen zu bauen.
Vorschlag für Einsteiger: »server side rendering«, HTML, wenig CSS, kein JavaScript.

[kbr]

ich überlege über die Wintermonate vermutlich würde es aber länger dauern) eine Software für die Verwaltung unserer Anfragen zu schreiben. Wir sind ein kleiner Reiseveranstalter mit ca. 8-10 Leuten im Büro, die phasenweise alle öfter am Tag an der gleichen Exceltabelle rumwerkeln. Das dies nicht ideal, weil Excel nicht dafür gemacht ist, ist klar.

Erfahrung hilft natürlich. Aber fang einfach mal, wie bereits empfohlen, mit dem django-Tutorial an https://www.djangoproject.com/. Anschließend kannst du schauen, ob sich die Strukturen der Excel-Tabellen in SQL abbilden lassen. Wenn dir das gelingt, kannst du loslegen. Rudimentäres html und css reichen für einen Protoyp völlig – es soll ja kein Produkt werden, sondern inhouse Verwendung finden; schön machen kannst du später immer noch. Den Zeitaufwand darfst du natürlich nicht gegenrechnen. Aber am Schluß hast du was gelernt und falls die Anwendung dann später auch erfolgreich eingesetzt wird, kann das ein großes Erfolgserlebnis sein. Zudem bist du dann der "King" in der Firma. Sofern die Kollegen so etwas zu schätzen wissen. Falls letzteres nicht zutrifft, dann lass es lieber bleiben.

[grubenfox]

[ich werde mal etwas offtopic, es geht noch um GUIs mit und ohne Web, aber nicht um Reisebüros]
Passenderweise hatte mich vorhin ein Mitarbeiter eines Kunden gefragt ob es geplant sei, die bisherige native GUI-Oberfläche der genutzten Anwendung ein wenig zu modernisieren weil sie doch etwas altbacken aussieht. Eines der Fenster erinnert ihn an Excel. Anwendungen mit ähnlichen Funktionalitäten von anderen Firmen sehen da deutlich moderner aus, sagte er.
Da muss ich mich wohl jetzt doch mal mit Web-Formularen bzw. dem Thema Web-Anwendungen und Python befassen. Falls dann wirklich mal eine Modernisierung der Oberfläche geplant wird, kann ich dann hoffentlich qualifiziert beurteilen ob das auch mit Python machbar ist oder nicht...
Ich glaube ja noch nicht, dass da am Ende für mich ein Python-Projekt rum kommt, aber jetzt habe ich schon mal ein Ziel vor Augen und damit ist auch die Motivation vorhanden.

Seit ziemlich langer Zeit ist es Standard, Business-Software als Web-Anwendung zu erstellen.
Vorteile:
* Plattformunabhängigkeit; jedes Endgerät mit Webbrowser kann auf die Anwendung zugreifen.

Hier gehe ich teilweise mit. Aber es hat schon seine Gründe warum die Kunden die Anwendung meist auf 2-3 breiten Bildschirmen nutzen.
Das zentrale Excel-ähnliche Fenster mit dem Datagrid (und einigen Eingabefeldern) maximiert auf einem der Bildschirme. Und so ein Datagrid, mit vielleicht 30-40 Spalten die der Anwender alle gleichzeitig im Blick haben möchte, hat nun mal ein gewisse Breite. Ich bin nicht sicher ob ich mir das auf einem Tablet oder Smartphone anschauen und nutzen möchte.
Wenn man wirklich zu verschiedene Endgerät unterstützen möchte, dann braucht es wohl bei manchen Fenstern größere Anpassungen an Aufbau und Bedienung derselben.

* Ortsunabhängigkeit (man denke an Home-Office oder Außendienst).

Also ich gehe hier im HomeOffice per VPN (wurde kürzlich gerade auf Tailscale umgestellt) in's Firmennetzwerk und per Remotedesktop dann auf meinen Rechner im Büro und arbeite dann dort mit den lokalen GUI-Anwendungen. Da braucht es keine Webanwendung für. Gut, man spart sich mit einer Webanwendung im Zweifel den RemoteDesktop.

* Erst-Installation und Updates müssen nur an einer Stelle (Server) gemacht werden. Das hat schon vieles an Bord was man so braucht (sowohl programmseitig (also Funktionalität), als auch auf der Doku-Seite (verdammt viel Doku...)).

Ja, dafür...bzw. Zustimmung. Bei unserer Anwendung muss bei der Erst-Installation einmalig auf den Client-PCs des Kunden die Client-Software installiert werden. Danach laufen dann aber alle Updates nur auf und über den Server beim Kunden.
Wobei Stichwort "Client-Software": wenn man jetzt spitzfindig sein möchte, dann könnte man sagen dass bei einer Webanwendung als Erst-Installation auch etwas auf den Client-PCs installiert sein muss: der Browser. Aber ich wüsste jetzt keine Betriebssystem-Installation die ohne Browser daher kommt.

* Per API kann mit anderen Webdiensten kommuniziert werden.

Also hier verstehe ich jetzt nicht was das mit Webanwendungen zu tun haben soll. Wenn ich mir hier die vorliegende native GUI-Anwendung(en) anschaue: wir schreiben und lesen Edifact, JSON, XML und HTML, abgeholt bzw. versendet werden die Daten/Dateien per sftp oder SOAP bzw. REST-API. [Für mich steht und stand das Kürzel API aber auch schon immer für "Application Programming Interface" und ist im Zweifel völlig unabhängig von irgendwelchen Web-Geschichten.]

Aber:
Es gibt fast unendlich viele verschiedene Konzepte und Technologie-Stacks, um Web-Anwendungen zu bauen.
Vorschlag für Einsteiger: »server side rendering«, HTML, wenig CSS, kein JavaScript.

... und im Zweifel einfach, wie schon von den anderen geschrieben, mal mit Django anfangen.

[Sirius3]

@grubenfox: ich arbeite mit einer Web-basierten eMail-Oberfläche, einem Videokonferenzsystem das im Browser läuft. Der Editor zum Programmieren läuft auf einem Remote-Rechner per Browser. Fast ausschließlich läuft also auf meinem Laptop ein Browser. Da ich fast alle Aufgaben automatisieren möchte, frage ich mich immer, welche API steckt hinter der Web-Oberfläche. Manchmal gibt es eine schöne REST-API, mal muß man HTML-Code parsen und für ein paar ganz schlimme Seiten muß man etliche Clicks simulieren, um an das Ziel zu kommen.

[nezzcarth]

Warum genau ist mit "aus der Mode" gemeint? Wirklich nicht mehr empfehlenswert oder einfach nur nicht der heißeste Scheiß? Für eine Firma, die mit 10 Leuten an Excel rumwerkelt könnte es fast schon futuristisch sein^^.

Das war jetzt ja erst einmal nur eine Tendenz von mir, auf Basis der paar Details, die du genannt hast und was m.M.n. nach halt üblich ist. Idealerweise würde man sich hinsetzen, für das konkrete Problem, das du lösen möchtest, eine Anforderungsanalyse machen und sich dann überlegen, wie man das umsetzt. Und es kann ja durchaus auch sein, dass sich für deinen Fall ergibt, dass du tatsächlich mit einer GUI besser fährt.

Wie bei den anderen ja schon durchklang, haben Webanwendungen halt viele Eigenschaften, die diese Variante sehr populär machen: Du hast einen Tech-Stack, den viele Leute beherrschen und zu dem mal viele Infos findet, sowohl Client als auch Server-seitig, es gibt ein standardisiertes Protokoll mit dem Client und Server kommunizieren (HTTP) und typische Architekturen, die man wählen kann, man hat nur einen Server, den man warten muss und Client-seitig wird nur ein Browser benötigt etc.

Bei einer klassischen GUI-Anwendung muss man halt erst einmal gucken: Soll die direkt und ausschließlich mit der Datenbank kommunizieren oder gibt es eine vermittelnde Server-Applikation? Wenn ja, welches Protokoll wird da verwendet? Server und Client müssen separat entwickelt und gewartet werden, man muss ein GUI Framwork lernen (während viele Leute halt schon ein bisschen HTML und CSS können – oder sich in einem halben Nachmittag aneignen können) usw. – haben die anderen ja schon alles gesagt. Aber u.a. aus diesen Gründen ist dieses Modell halt meiner Wahrnehmung nach heute weniger verbreitet. Man muss halt mehr werkeln und sich mehr Gedanken machen und wandelt weniger auf gut beschrittenen Pfaden. Eine Webanwendung ist dafür gedacht, dass die über's Netzwerk funktioniert und Geräte-unabhängig benutzt wird; bei einer GUI-Anwendung muss man sich da erst einmal "hin programmieren".

Hinzu kommt noch: Django ist für die Art von Anwendung, die dir vorschwebt vermutlich gut geeignet, weil es schon viele Komponenten mitbringt, die die Entwicklung wahrscheinlich beschleunigen. Und für die Optik nimmt man halt das CSS- Framework der Woche und dann sieht es auch noch mindestens Okay aus.

[grubenfox]

mir ist noch ein kleiner Punkt eingefallen der ein wenig für die GUI-Anwendung spricht (wurde IMHO irgendwo hier in den letzten 3-4 Monaten auch schon mal angesprochen). Dass im Vergleich die Webanwendung hier Abzüge in der B-Note bekommt, liegt aber vermutlich mehr an mir als an der Webanwendung:
Die GUI-Anwendung muss sich nur um sich selbst kümmern, während die Web-Anwendung im Browser... im Zweifel da noch mehr hat.. oder noch viel mehr hat...

Aber das liegt bei mir vermutlich daran dass ich immer zu viele Browser-Fenster und jedes davon mit zu vielen Browser-Tabs offen habe, was dann insgesamt zu viel zu vielen Browser-Tabs führt. Wenn ich bei unserer Asterisk-Telefonanwendung zwischen 'normalen Betrieb' und 'sofortige Weiterleitung auf die HomeOffice-Nummer' umstelle, dann muss ich beide Buttons und das Eingabefeld für die Tel.nummer immer mehrfach anklicken bis es endlich mal auf meine Klicks und Tastendrücke reagiert.

Aber, wie oben geschrieben, hier vermute ich ja dass es daran liegt dass bei mir im Browser viel zu viel anderes Zeug geöffnet ist und die Asterisk-Seite deswegen so lahm reagiert. Hätte ich nur Asterisk im Browser geöffnet würde die Seite wohl richtig flutschen...
Oder ist die Asterisk-Seite wirklich so sau schlecht und lahm programmiert? Kann da wer was zu sagen? Wer darf sich noch mit Asterisk vergnügen?

[__blackjack__]

@grubenfox: Ich habe auch mit Asterisk zu tun, aber nicht mit der Webanwendung. Nur als Benutzer via Telefon und als Programmierer via API.

[nezzcarth]

@grubenfox:
In modernen Browsern sind Tabs und Fenster durch Sandboxing weitgehend separiert und es gibt, soweit mir bekannt ist, auch ein internes Prozessmanagement mit Priorisierung, Drosselung von Hintergrund-Tabs usw. Ab einem gewissen Punkt machen viele Tabs natürlich schon einen Unterschied, aber ohne weitere Tests würde ich da keine unmittelbare Kausalität annehmen. Und es hängt natürlich davon ab, was deine Hardware so hergibt.

[steveO_O]

Oh, sorry. Ich dachte ich hätte hier geantwortet.

Aus "über die Wintermonate" ist "hoffentlich Mite Februar" geworden. Ich werde mich an eure Tips halten, und mich an das Django-Tutorial wagen. Danke an alle!