Die Übersicht über meine Kunden pflege ich momentan mit Excel. Da stehen dann alle Kunden drin, dazu in Spalten die notwendigen Anrufe pro Ausgabe, Zu- oder Absagen, vereinbarten Preise usw. Bei jeder neuen Ausgabe erstelle ich auf Basis der vorhergehenden Tabelle eine Neue (Kundeninfos bleiben, Rest wird gelöscht). So habe ich aber nie einen Gesamtüberblick, wer wieviele Ausgabe belegt hat, wer wann irgendwo was gebucht hat. Hinzukommt, dass ich dieselbe Tabelle auch für die Leipziger Ausgabe habe. Da einige Kunden in DD und L aktiv sind, muss ich das auch doppelt pflegen, obwohl es ja nur 1 Vorgang ist. Hier stößt Excel an seine Grenzen. Da meine aktuelle Kundensoftware auch nicht so das Wahre ist, überlege ich, wie sich das gemeinsam in eine Software packen lässt. Die ganzen fertigen CRM-Lösungen sind meist schweineteuer und man muss für jeden Rechner noch extra Lizenzen kaufen. Kann man sowas in Access programmieren oder macht es hier Sinn, sich eine Online-basierte programmieren zu lassen und diese auf meinen Webserver zu packen? Hätte zumindest den Vorteil, dass mehrere Leute in Echtzeit drauf zugreifen können?

Wer kennt sich aus? Wer hat Ideen?

Ich will mich nicht streiten, aber der 4-Punkte-Weg klingt doch sehr akademisch und wird in den seltensten Fällen funktionieren, so setzt er doch mindestens voraus:

1) Dass der Kunde schon sehr genau weiß was er will
2) In der Lage ist das dem Entwickler auch zu artikulieren
3) Sich die Anforderungen über die Zeit nicht ändern
4) Insgesamt nur sehr wenig Anforderungen existieren

1) und 2) klingt vielleicht banal, ist aber gerade bei Leuten die eher selten Eigenentwicklungen machen (gilt für Entwickler und Kunde) nicht zu unterschätzen. 3) ist sicher nicht gegeben, ansonsten wäre Pulstreiber mit seiner Excel-Tabelle immer noch glücklich, also müssen bei Änderungen der Anforderungen wieder die Programmierer ran. Zu 4) kann man nicht soviel sagen . Und wenn man nicht soviele Features braucht nimmt man halt ein CRM was nicht soviel kann, billiger ist und baut darauf auf.

Von den sonstigen Problemen von Ultra-Low-Budget-Entwicklungen (kaum Tests, daher mehr Bugs über die Zeit, der Programmierer der nach nem Jahr auf seinen Code schaut muss sich da auch erstmal wieder reinfummeln usw.) gar nicht zu sprechen .

Dieser Beitrag wurde von Polygon: 03 Aug 2009, 13:43 bearbeitet