CRM Extension 2. Anlauf + Desktop Version

[christian.kolb]

EDIT: Für alle die dieses Thema zum ersten Mal lesen:
Im Verlaufe des Themas hat sich einiges geändert, die Desktop App ist nicht mehr aktuell. Ihr könnt also getrost ab diesem Beitrag anfangen zu lesen.

Hallo Zusammen,

der eine oder andere hat vielleicht die CRM Extension Themen gelesen. Die Erweiterung hatte ich ja aus Zeitgründen verschoben, bzw. abgegeben. So weit ich weiß wird sie im Moment allerdings nicht weiterentwickelt.

Ich habe mich dazu entschieden die Arbeit daran wieder aufzunehmen. Allerdings mit einem anderen Ansatz.

Die Daten sollen alle in einer Contao Installation gehalten werden und auch über Contao angezeigt werden können. Die Pflege der Daten soll aber (vorerst) nur über eine Desktop Applikation geschehen. Die Verbindung zur Installation soll über SOAP erstellt werden.

Eigentlich wollte ich die Desktop Applikation für Windows mit C# (.NET 4.0) entwickeln. Da ich damit aber die Kollegen mit Mac und Linux ausschließen würde, denke ich darüber nach sie mit Java zu entwickeln.

Für den Anfang dachte ich daran folgende Elemente zu implementieren:

• Kunden (ID + Nummer)
• Adressbuch (Verbindung zu Kunden)
• Aufgaben
• Rechnungen
• Rechnungserinnerungen (Meldung über die Desktop App)

Die zentralen Fragen die sich jetzt stellen sind folgende:

• Habt ihr generell Interesse an einem solchen System? (gerade wenn die meisten wahrscheinlich bereits ein CRM im Betrieb haben)
• Mit welchem Betriebssystem arbeitet ihr? (Besteht Interesse an einer Java Version?)
• Würdet ihr das System testen? (Habe weder einen Mac noch Linux)

Freue mich über eure Meinungen und Vorschläge.

Gruß
Christian

[christian.kolb]

Naja meiner Meinung nach gehört Java auch eher in die Server Welt

KnowHow-Technisch wäre ich mit Java zwar besser dran, aber GUI-Technisch kommt Java halt bei weitem nicht an .NET ran. Die haben einfach mehr und die besseren Components.

Die Frage ist, lassen sich die Components auch alle unter Mono ausführen und ist Mono bereits auf dem Stand von .Net 4.0. Ich hab noch nie mit Mono gearbeitet. Und gibt es Mono oder etwas ähnliches auch für Mac oder schießen wir die Mac User damit komplett ab? (Einfach ignorieren sollte man sie ja nicht )

Gruß
Christian

[christian.kolb]

"WPF - no plans to implement"

Schon das erste richtig große Problem bei Mono gefunden. Es unterstützt kein WPF. Damit wären schonmal die Linux und Mac User gekickt.

Gruß
Christian

[christian.kolb]

Warum braucht man bei einem CRM Swing? (geht ja auch mit AWT)
Wenn, dann schon gescheit.

Aber wir sind ein bisschen von der eigentlichen Fragestellung abgekommen.

• Generelles Interesse?
• Betriebssystem?
• Testing?

Gruß
Christian

[christian.kolb]

Du weißt schon: Swing und AWT = Java ; Windows Forms und WPF = .NET

Gibt einige Components die es so nicht gibt, wie z.B: RibbonBar

Natürlich bracht man das nicht, aber wenn, dann möchte ich das schon gescheit (schön) machen

Gruß
Christian

[Dani]

Das Interesse ist sicherlich da. Ich bin auch gerade an einem CRM dran (ohne Desktop-Anwendung), bin aber noch nicht sicher, ob ich sie kostenlos zur Verfügung stellen werde. Bei mir geht es jedoch nicht allzu schnell vorwärts.

[lindesbs]

Mal eine allg. Frage : Was verstehst Du/Ihr unter einem CRM ?
Ich verstehe sowas wie dies hier darunter : http://de.wikipedia.org/wiki/Custome..._CRM-Anwendung

Momentan sind die meisten Dinge eigentloch auch mit den vorhandenen Erweiterungen problemlos loesbar. (isotope & catalog)

Und vor allem : Wozu braucht man dann noch eine extra DesktopAnwendung ? Welchen Teil soll dann Contao noch bringen ? Wie soll die Kommunikation zw. den System erfolgen usw.

[soweit_ok]

Grundsätzlich hätte ich Interesse an einem CRM für Contao. Sofern es nicht standalone wäre bzw. nur dem allg. Beziehungsmanagement dienen könnte, sondern ideal auch mit BE- u. FE-Benutzern/Mitgliedern korrespondieren. So ist es vermutlich auch gedacht, oder? Dann hätte es einen echten Mehrwert für Betreiber größerer kommerzieller Portale auf Basis von Contao. Ja, ich hatte mal in dem CRM-Thread gelesen, ist aber schon zu lange her, mich noch an Details zu erinnern.

Dein Ansatz bzgl. einer Desktop-Applikation ... weiß nicht recht, ob mich das begeistert. Bei den Entwicklern gängiger CRM-Lösungen geht die Reise eher weg von Desktop-Anwendungen. Auf der anderen Seite braucht es für sinnvolles Arbeiten mit einem CRM unbedingt eine gute Performance. Bedingt durch die Konzeption für einen ganz anderen Einsatzzweck kann man die Contao-Reaktionszeiten für ein CRM eigentlich knicken, auch ohne den Flaschenhals "Internetzugriff". Und vielleicht lassen sich mit einem Desktop-Programm Schnittstellen zu anderen Desktop-Applikationen einfacher bedienen.

Na ja, "Adressbuch" ist eine recht schlichte Umschreibung für die relativ komplexe Funktionalität, welche allein dieses Objekt bräuchte. Es müsste ja nicht nur auch die Relationen von Ansprechpartnern und deren Profilen enthalten, sondern auch mit einem komplexen Beziehungsmanagement verknüpfbar sein (Daten, Workflows, Dokumente und Personen). Termine und Ereignisse benötigen Filter und Trigger, die auch über anwenderdefinierte Felder erweitert werden können sollten. Von der Ereignishistorie bis hin zu automatisiertem Kontaktmanagement inkl. Wiedervorlagen hättest Du Dir im Hinblick auf ernstzunehmende CRM-Funktionen viel vorgenommen. Das Gute daran ist aber, dass bereits auf dem Weg dorthin diverse zugehörige fertiggestellte Module bereits sinnvolle Anwendung finden könnten.

Dass ein Contao-CRM jenseits der Interaktion zwischen Portalbetreiber und dessen Kunden/Interessenten in größerem Umfang eingesetzt würde, bezweifle ich eher. CRM-Daten sind ein hochsensibler Bereich und wichtiges Unternehmenskapital. Niemals würde ich die in einem Portal verwalten, in dem andere als die eigenen Leute Administrator-Rechte/Zugriff haben.

Als weitere Ideen-Vorlage lad Dir vielleicht mal das CRM "Julitec" runter. Ist proprietär, jedoch recht preisgünstig und die auf 500 Kunden limitierte Vollversion kostenlos erhältlich. Ich hab lockeren Kontakt mit der Anbieterfirma. Sie sind dort sehr freundlich und wenn man nett am Telefon fragt, mailen sie einem inoffiziell auch kostenlos einen Download-Link für eine Extension mit einigen sehr nützlichen Zusatzfunktionen, wie die Verknüpfung benutzerdefinierter Felder mit Formeln a la Excel. Jedenfalls haben sie das bei mir gemacht als Ergebnis eines interessanten Gesprächs.

Julitec gefällt mir als Anwender mit überschaubaren Bedürfnissen funktional sehr gut und verfügt zudem auch über Projektmanagement-Features und Workflows. Die Basisfunktionen sind wirklich intuitiv anzuwenden. Leider nicht Opensource, doch m. E. eine wesentlich interessantere Entwicklungsvorlage als bspw. vtiger - zwar ziemlich mächtig, aber mir viel zu aufgebläht und man konfiguriert sich fast blöde, bloß um es soweit abzuspecken, dass es sinnvoll einsetzbar wird. Der zu erwartende Customizing-Aufwand zählt bei CRM nunmal zu den wesentlichen Entscheidungskriterien für einen Einsatz.

Wie schon angedeutet, würde mich eine gut mit den sonstigen Features wie der Rechteverwaltung zusammenwirkende Contao-CRM Extension weniger universell als speziell mit der Zielrichtung auf Marketing und Kundenverwaltung größerer Portale interessieren. "Eierlegende Wollmilchsäue" gibt´s schon genug. Auf Schnickschnack wie selbstwählende Telefon-ToDo-Listen könnte ich gut verzichten. Email-Anbindung und Dokumentenverwaltung sollten aber schon sein.

Nun frag ich mich aber, warum Du das Rad neu erfinden willst, statt ein ausgereiftes bestehendes CRM gut in Contao zu integrieren. Erschlösse auch gleich einen weit größeren Interessentenkreis. Könnte vielleicht z. B. durchaus die Opensource-Lösung vtiger sein. Nach meinem Geschmack etwas oversized, aber ließe sich ja für den Zweck customizen. Oder auch ein erschwingliches kommerzielles wie Julitec.

Ich verwende Linux und WindowsXP, meine Tochter Apple. Kann´s noch nicht versprechen, wie ich zeitlich bestellt bin. Im Fall eines für mich interessanten Fortgangs Deines Projekts bin ich jedenfalls grundsätzlich bereit zum testen. Und auch zum Nachdenken. ;-)

[christian.kolb]

Die Beschreibung entspricht dem was ich mir unter einem CRM vorstelle.

Es lässt sich tatsächlich das meiste mit Catalog und Co darstellen, diesen Weg bin ich auch zuerst gegangen (deshalb habe ich die CRM Extension auch nicht mehr weiterentwickelt).

Vielleicht hätte ich erst meine Vorstellung bzw. Anforderungen erklären sollen

Ich bin angestellter Fachinformatiker und habe mich Nebenberuflich zusätzlich Selbstständig gemacht. Mit meinem kleinen Unternehmen setzte ich Internetauftritte mit Contao um. Und für diese benötige ich ein CRM. Jedes CRM das es bereits gibt ist total oversized. Alles was ich benötige ist eine Kundenverwaltung (mit Adressen), eine ToDo Liste und eine Verwaltungen der Rechnungen die ich stelle. Ich arbeite nicht jeden Tag durchgehend für mein Unternehmen und logge mich dem entsprechend nicht täglich in ein CRM System ein. Trotzallem muss ich an wiederkehrende Rechnungen erinnert werden.

Wenn ich das CRM für eine Zielgruppe erstellen würde, dann wären es wohl die Freelancer und Freiberufler. Mit meinen beiden Berufen habe ich für das CRM nicht extrem viel Zeit und könnte das niemals so groß wie z.B. vtiger aufziehen. Abgesehen davon, dass man das nur machen kann wenn man es kommerziell vertreibt oder es in einer Gruppe entwickelt, wäre das wie schon gesagt total oversized.

Die Desktop App könnte im Autostart liegen und sich melden wenn eine Rechnung zu schreiben ist oder ein ToDo ausläuft. Man müsste sich nicht immer in das CRM bzw. Contao einloggen um Daten zu ändern, hätte sie aber zentral zur Hand auch wenn man unterwegs ist. Mit Extensions wie Catalog lässt sich viel machen, aber es lassen sich nicht alle Beziehungen darstellen, außerdem wird es ab einem bestimmten Grad doch kompliziert ein neues Element einzupflegen. Gerade wenn man z.B. eine Rechnung erstellt und diese einpflegen möchte (einloggen, Rechnung hochladen, neuen Eintrag anlegen). Mit einer Desktop App könnte man eine erstellte Rechnung per DragnDrop in die App ziehen, ein paar Daten eingeben und den Rest übernimmt die Applikation.
In einem vollständigen CRM übernimmt die Rechnungserstellung das CRM und startet womöglich noch mehrere Workflows oder einen E-Mail Versand.

Die CRM Extension wird nie an die bekannten CRM Systeme herankommen und das ist auch nicht das Ziel. Wer also nach einem solchen System für Contao sucht ist hier leider falsch. (Das hätte ich aber auch am Anfang sagen sollen)

Selbstverständlich kann das System wachsen und wenn ich die Zeit finde werde ich auch gerne Wünsche der Community in die Extension einfließen lassen. Wenn die Extension mal größer werden sollte und jemand diese kommerziell weiterentwickeln möchte, wäre ich auch sicher bereit den Quellcode für eine kleine Spende weiterzugeben

Aber das ist Zukunftsmusik.

Wie gesagt das System wird, vorallem am Anfang, klein sein und höchstwahrscheinlich für die meisten Poweruser uninteressant sein. Trotzallem würde mich auch deren Meinung interessieren.

Das ganze soll halt so klein und schnell zu bedienen sein wie möglich. So könnte ich mir die GUI vorstellen:



Deshalb auch WPF, mit Java ist sowas gar nicht möglich (außer mit Flamingo, aber auch das kommt bei weitem nicht daran)

Gruß
Christian

[ku-ma-122]

Ich finde die Idee prima.

Mal zurück zu der Frage nach der Entwicklungsumgebung ... Mir fällt da spontan Titanium ein. Eine tolle kleine Software die sicher einige kennen ist schon damit entwickelt worden: Wunderlist!

Komplett plattformunabhängig

[soweit_ok]

Dann solltest Du Dir für die Agenturkunden tatsächlich mal Julitec runterladen und installieren. Hindert Dich ja nicht daran, uns trotzdem eine schnuckelige Contao-Extension zu stricken.

Ist wie gesagt in der kostenlosen Version auf die Verwaltung von max. 500 Kunden beschränkt. Doch mehr wirst Du mit Deiner nebenberuflichen Agentur wohl vorläufig nicht haben. Unterhalb dieser Kunden können natürlich beliebig viele Ansprechpartner angelegt werden. Rechnungsverwaltung ist vorhanden und alles andere angesprochene ebenfalls sehr ausgereift und praxisgerecht. Da braucht nichts angepasst werden wie bei vtiger. Installieren und gleich mit der Stammdateneingabe loslegen. Oder per CSV-Import.

Hab natürlich nix von der Produktempfehlung, arbeite halt nur sehr gerne mit diesem nach meinem Geschmack echt tollen Programm.

[christian.kolb]

@ku-ma-122:
Titanium sieht interessant aus, aber gerade in den Programmiersprachen des Desktop Teils habe ich nur wenig Erfahrung.
PS: Welches Betriebssystem hast du denn?

@soweit_ok:
Das System sieht ebenfalls interssant aus (abgesehen von der GUI ). Aber ich hätte schon gerne eine Verbindung zu Contao. Contao soll nicht nur eine Plattform zum Speichern der Daten, sondern eben auch zur Präsentation sein. So dass sich Kunden z.B. einloggen können und ihre Projekte betrachten können (Wenn Projekte auch implementiert sind).

Eine weitere Idee:
Die Desktop Applikation wird gar nicht zur Datenpflege genutzt, sondern als Schnittstelle zu anderen CRM Systemen. Das diese die Daten exportieren und über die App an Contao übertragen. Da kommt es natürlich stark darauf an, welches CRM viel genutzt wird und wie groß das Interesse daran ist, die Daten in Contao zu präsentieren.

Gruß
Christian

[stefan-at-work]

ist die Entwicklung nicht plattformübergreifend auch mit Adobe Air denkbar?

[christian.kolb]

@stefan-at-work
Ja bestimmt, aber genauso wie mit Titanium sind es auch dort die "falschen" Programmiersprachen.

Gruß
Christian

[soweit_ok]

Ja, eben darauf wollte ich hinaus ... Contao als Schnittstelle zum CRM und Präsentationsschicht zu verwenden. Das Rad von Grund auf innerhalb Contao neu zu erfinden, böte zwar schneller einige viell. auch zu anderen Zwecken verwendbare Funktionalitäten, würde andererseits womöglich aber recht lange dauern, bis mal was herauskäme, das die Bezeichnung "CRM" verdient.

Wo die Datenhaltung stattfiinden sollte bzw. wie sie verteilt wäre und welche Vor-/Nachteile eine zumindest teilweise redundante Datenhaltung mit Synchronisation böte, respektive das Datenmodell der Anbindung, dass sollte man m. E. zunächst lediglich als Grobkonzept dargestellt werden. Wobei man ja in dieser Phase noch alternative Modelle entwerfen und vergleichen kann.

Falls Du klären möchtest, inwieweit bei Julitec Interesse an einer Contao-Anbindung besteht, hier die Kontaktdaten:
Nico Ardelean, Kundenbetreuung Julitec GmbH, Fon +49 9131 97911-10, ardelean@julitec.de

Der vermittelt Dir ggf. auch Ansprechpartner unter den zuständigen Entwicklern, um die techn. Machbarkeit und API´s zu besprechen.

Ansonsten finde ich OpenSource CRM wie vtiger durchaus überlegenswert, denn die Customizing-Möglichkeiten sind da eindeutig besser und es sollte so eigentlich gut gelingen, ein für die Contao-Integration gut passendes praxisgerechtes Paket zu schnüren. Kommerzielle Software böte widerum über den Hersteller Kontakt zu einer Kundenbasis, die nicht erst kompliziert überredet werden bräuchte, sich auch mit Inkaufnahme von Kosten für eine solche Anbindung zu interessieren. Deine Idee geistert mir seit Jahren immer mal wieder durch den Kopf. Für kleine bis mittlere Budgets ist sowas bis heute meines Wissens nämlich noch nicht zu haben. Und für große Budgets könntest Du dann gleich mal die Eignung des Database Abstraction Layers von Contao auch für Oracle testen. Hätte ich immer noch gute Kontakte, war dort lange als PM tätig. Aber das wird nix, denn die verhökern lieber ihr eigenes Bundle ("Oracle CRM" und "Oracle Portal").

Na ja, die Idee hatte ich also auch schon - freilich ohne Priorität, denn in anderen Projekten sah und sehe ich bislang letztlich interessantere finanzielle Potenziale. Wollte ich jede vermeintlich brauchbare meiner Ideen realisieren, müsste ich mindestens 500 Jahre leben.

[soweit_ok]

@stefan-at-work

Noch nie davon gehört, hab eben mal die Webseite besucht. Klingt auf den ersten Blick nicht uninteressant, auch unabhängig von dieser Contao Erweiterungsidee. Hast Du schon Erfahrungen damit gesammelt bzw. konkrete Vorhaben damit realisiert?

[christian.kolb]

@soweit_ok
Erstmal vielen Dank für deine Anregungen, aber das ist mir schon wieder zu groß.
Eine Schnittstelle zu einem bestehenden CRM (sei es vTiger, Julitec oder sonst eins) zu realisieren, bedeutet es so vollständig wie möglich umzusetzen. Dafür habe ich allerdings keine Zeit. Ich werde mir die Zeit dazu nehmen meine Anforderungen umzusetzten und ggf. die, die aus der Community kommen. Aber mehr ist nicht drin. Selbstverständlich hätte es sehr viele Vorteile an ein bestehendes System anzukoppeln, aber dazu habe ich schlicht und einfach nicht die Zeit.

Ein Datenmodell werde ich auf jeden Fall erstellen. Dieses könnte ich hier gerne zeigen und diejenigen die sich für das Projekt interssieren könnten Vorschläge für Änderungen machen.

Ich habe so den Eindruck, dass MAC User Contao im Unternehmen einsetzen. Diese Gruppe wird höchstwahrscheinlich bereits ein CRM im Einsatz haben. Liege ich damit richtig? Bzw. gibt es MAC User mit Interesse an dem CRM?

Das CRM wird auf jeden Fall aus zwei Teilen bestehen: Contao Modul + Desktop App. Weshalb ich kein bestehendes CRM anbinden möchte habe ich ja nun schon ausführlich beschrieben .

Die Entscheidung die noch aussteht ist: Java oder .NET?
Für Java spricht eigentlich nur die Plattformunabhängikeit. Die spielt allerdings auch nur eine Rolle wenn auch User außerhalb von Windows an dem CRM interesse hätten.

Deshalb nochmal die Fragen vom Anfang:

• Welches Betriebssystem?
• Interesse?

Gruß
Christian

[backbone]

AspectJ/Java <-

[smung0r]

Also ich bin definitiv gegen .NET. Ich benutze einfach kein Windows mehr ( ausser wenn ich was im IE testen muss ) Mit Mono hätte ich aber auch kein Problem. Java fänd ich persönlich noch am besten. Ich denke da gibts auch noch ein paar Entwickler mehr als bei .NET. Was Spricht eigentlich gegen C++? Dort gibts auch noch QT

[Bandyt]

Also ich bin definitiv gegen .NET. Ich benutze einfach kein Windows mehr ( ausser wenn ich was im IE testen muss ) Mit Mono hätte ich aber auch kein Problem. Java fänd ich persönlich noch am besten. Ich denke da gibts auch noch ein paar Entwickler mehr als bei .NET. Was Spricht eigentlich gegen C++? Dort gibts auch noch QT

Und wo ist der Unterschied .Net zu Mono? Das eine ist eine Implementierung des Anderen für Nicht-Windows-Systeme... (Um mal klugzuscheißen )
Ich halte .Net für eine gute Basis.

Grundsätzlich würde ich aber empfehlen erstmal mit der Arbeit am CRM zu beginnen (Oder ein bestehendes System zu integrieren) und dann erst mit der Desktop-Anwendung zu beginnen. Gerade wenn ein CRM neu entwickelt werden soll, dürfte das schon genug Zeit in Anspruch nehmen...

[christian.kolb]

@backbone:
Ich versteh ehrlich gesagt nicht ganz wozu AspectJ gut sein soll und was für einen Mehrwert es in dem System hätte.

@smung0r:
Jetzt haben wir bald alle Programmiersprachen durch Abgesehen von Python habe ich auch bereits mit jeder etwas gemacht, aber wirklich gut beherrschen tue ich (im Desktop Bereich) Java und C#. Auch bei C++ hätte ich nicht die nötige Erfahrung, dass am Ende ein schönes System dabei heraus kommt. Qt ist zwar eine geniale Bibiotek, aber meiner Meinung nach leider auf einem sterbenden Ast (aber das ist wieder ein anderes Thema)

@Bandyt:
Mono ist tatsächlich nicht viel anderst als .NET, nur hinkt es leider hinterher und kann nicht mit WPF umgehen. Wenn ich .NET einsetzte, dann auf jeden Fall mit WPF.
Was meinst du mit "Der Arbeit am CRM beginnen"? Zu Beginn wird Contao erst einmal als Datenablage herhalten, das heißt die Arbeit am CRM wäre die Datenmodellierung und die Arbeit das Datenmodell nach Contao zu bringen. Ein Teil davon habe ich bereits, da ich ja schon einmal ein CRM im Contao gestartet habe. Das ich kein bestehendes System integrieren werde habe ich schon oft genug geschrieben.

@alle drei:
Keiner von euch hat geschrieben welches Betriebsystem er nutzt, könntet ihr mir das noch schreiben

@all:
Wer hätte an der Schnittstellen-Funktion des CRM interesse? Also daran, Teilmengen aus einem anderen CRM in Contao zu übertragen und diese dort zu präsentieren? Und wenn ja, mit welchem System?

Gruß
Christian

[smung0r]

<-- Linux
<-- kann Java programmieren

wäre vielleicht nicht schlecht ne Umfrage zu starten. Geht das hier im Forum?

[xchs]

wäre vielleicht nicht schlecht ne Umfrage zu starten. Geht das hier im Forum?

Ja, kann man machen.

[soweit_ok]

@christian.kolb

Also ich finde, die Wahl der Entwicklungsumgebung sollte sich an den Implementierungsanforderungen orientieren und nicht umgekehrt. Sofern nicht von Entwicklerseite her von vornherein eine Festlegung auf bestimmte Sprachen/Tools gegeben ist. Ist diese Festlegung an ein Betriebssystem (Windows) gebunden, wozu dann überhaupt etwas anderes diskutieren.

Zunächst brachtest Du Plattformunabhängigkeit in die Diskussion, beharrst dann aber auf .net. Auf den Vorschlag von Mono als Alternative brachtest Du den Einwand, es könne nicht mit WPF umgehen. Das stimmt, jedoch ist stattdessen das WPF-ähnliche Silverlight Framework verfügbar. Mag sein, dass es derzeit nicht an WPF heranreicht - kann ich nicht beurteilen, weil ich beides nicht kenne. Jedenfalls dient es lediglich zur Entwicklung der Benutzeroberfläche und wird wohl beides für eine brauchbare reichen. Sorry, das empfinde ich als eine am Zweck eines CRM vorbeigedachte Gewichtung. Obgleich es nie mein Schwerpunkt war, hatte ich schon ein paar Mal das "Vergnügen", das Bid-Management für große CRM-Projekte übernehmen zu müssen. Schwerpunkt war dabei stets die Anpassbarkeit der Datenstrukturen des Systems an die Kundenanforderungen - über Benutzeroberflächen wurde nichtmal gesprochen.

Wenn Du also ein eingeschworener Windows-Entwickler bist, dann mach es doch so. Deine Desktopanwendung muss doch garnicht plattformunabhängig sein, da die meisten Unternehmen eh Windows-Clients einsetzen und Linux nur serverseitig. Und Mac kannst Du dafür ruhig außen vor lassen, wen interessiert das schon für ein CRM. Und letzlich kann man Dein Desktopprogramm auch unter Linux und OS X in einer VM benutzen.

Den zweiten Widerspruch brachtest Du mit der Frage auf´s Tapez, ob es als eigenständiges CRM fungieren sollte oder als Schnittstelle zu einem bereits bestehenden. Vorschläge dazu hast Du anschließend damit abgebügelt, aus Zeitgründen auf keinen Fall auf ein bestehendes aufzusetzen. Und heute fragest Du schon wieder "Wer hätte an der Schnittstellen-Funktion des CRM interesse? Also daran, Teilmengen aus einem anderen CRM in Contao zu übertragen und diese dort zu präsentieren? Und wenn ja, mit welchem System?".

Sorry, das verstehe ich nicht. Zunächst mal geht´s ja um den Entwurf des Datenmodells. Und das geschieht entweder mit Fokus auf zumindest für die Synchronisation Fremdsystem-Kompatibilität oder halt nicht. Vor dem Datenmodell steht m. E. außerdem erstmal der Entwurf des Use-Case.

Nach meinem Eindruck wärest Du gut beraten, vorgenannte grundlegende Aspekte erstmal im Sinne einer Vorgabe zu überdenken. Dann kann man sich über die konkreten Kernanforderungen unterhalten. Oder eben umgekehrt und eine Kompatibilitätsprüfung erst nachrangig. Die ist immerhin keine Kleinigkeit, denn selbst bei Open Source Systemen ist das Datenmodell zumeist nicht so dokumentiert, ohne aufwändiges Reengineering durchzublicken, wie man darauf aufsetzen oder es auch nur per Schnittstelle bedienen kann. Gerade standardisierte Schnittstellen sind, wenn überhaupt, meist noch recht kümmerlich vorhanden. So kann man z. B. bei Julitec meines Wissens bislang nur Rechnungsdaten nach Excel exportieren, ansonsten Stamm-, aber keine Bewegungsdaten im/exportieren und eine Synchronisation ist nur mit Outlook umgesetzt. Und ich fürchte, bei anderen CRM sieht es damit nicht viel anders aus.

Ich werde den Thread mal weiterverfolgen. Weil er mir allerdings momentan noch zu sehr in die Breite läuft, klinke mich jedoch am besten an dieser Stelle erstmal solange wieder aus, bis ein konkretes Grobkonzept vorliegt.

[christian.kolb]

@soweit_ok
Vielleicht habe ich mich zu schammig ausgedrückt, ich versuch es noch einmal:

Ich beherrsche zwar einige Programmiersprachen, aber nur ein paar wenige richtig gut. In der Desktop Welt sind das .NET(C#) und Java. Die Wahl zwischen den beiden Programmiersprache ist einzig und allein abhängig von der Betriebssystemnutztung derjedenigen, die das System einsetzten wollen. Deshalb auch die Frage nach der Interesse und des Betriebssystems.

Wenn es hauptsächlich Interesse in der Windows Welt gibt, dann werde ich mit .NET entwickeln. Da ich aber nicht auf dem alten WinForms System aufsetzten werde, bedeutet dies allerdings, dass Linux und Mac User das System nur über eine Windows VM zum laufen bekommen werden (ich bezweifel stark das jemand für so ein kleines System extra eine VM aufsetzten wird). Falls es aber Interesse von Linux und Mac Usern geben sollte werde ich mit Java entwickeln, würde aber die Hilfe von denen zum testen der App benötigen. Vielleicht ist Silverlight (Moonlight) eine Alternative, aber auch damit habe ich zu wenig Erfahrung.

Den zweiten Widerspruch brachtest Du mit der Frage auf´s Tapez, ob es als eigenständiges CRM fungieren sollte oder als Schnittstelle zu einem bereits bestehenden.

Es gibt dort kein entweder oder. Es soll an sich ein eigenständiges kleines CRM sein, dessen Daten in Contao abgelegt werden und dessen Datenpflege über die Desktop App geregelt werden soll. Contao dient hier zum einen als "Datenbank" und zum anderen dazu, über Module die CRM Daten zu veröffentlichen. Zusätzlich könnte das CRM als Schnittstelle zu anderen CRM Systemen dienen. Das bedeutet nicht, dass das CRM auf den Daten oder dem System aufsetzt, sondern lediglich, dass es die Daten, die sowohl in meinem CRM als auch im "verbundenen" CRM vorhanden sind, in Richtung Contao exportiert werden könnten. Dies wäre allerdings nur eine Möglichkeit und es handelt sich dabei lediglich um die Teilmenge der Daten. Selbstverständlich müsste es dort eine extra Anbindung an jedes System geben. Wie gesagt, eine Option und nur wenn genügend Interesse an einer Anbindung bestehen würde.

Falls es tatsächlich keine Schnittstellen für verschiedene Systeme geben sollte, dann wird es an diese eben keine Anbindung geben.

Du denkst bei allen Anforderungen viel zu groß. Es soll ein kleines System sein, welches langsam wachsen wird. Es ist auch gut möglich, dass es für die meisten viel zu klein wäre und sie doch lieber auf ein bereits bewährtes CRM setzen möchten. Aber das ist genau das, was ich hier heraushören möchte.

Gruß
Christian

[soweit_ok]

Es ist auch gut möglich, dass es für die meisten viel zu klein wäre und sie doch lieber auf ein bereits bewährtes CRM setzen möchten. Aber das ist genau das, was ich hier heraushören möchte.

Ich denke, das kann man schlecht verallgemeinern und kann nur jeder für sich entscheiden. Für meinen Bedarf bzgl. der allg. Kundenakquise und -betreuung wäre alles was Du in überschaubarem Zeitraum entwickeln könntest, viel zu klein.

Was nicht bedeutet, ich hätte keine Verwendung für eine auf Contao zugeschnittene Spezialanwendung. Was ich persönlich prima innerhalb eines Contao-Portals brauchen könnte, wäre eine auf den Kundenstammdaten aufsetzende Kommunikations- u. Vorgangsverwaltungslösung zum strukturierten Management aller diesbezüglich anfallenden Aufgaben. So wäre jeder Kunde inkl. der ihm zugeordneten Ansprechpartner und Aufgaben innerhalb des Gesamtprojekts praktisch ein Mini-Projekt. Idealerweise wären bereits vorhandene Module wie Helpdesk oder BE-Aufgaben sowie Mailversand damit verknüpfbar. Mit Filtern ließen sich Workflows generieren, z. B. kundenbezogene Wiedervorlagen/Terminkalender/Statusberichte. Die Rechteverwaltung sollte insoweit erweitert werden, dass Portaladmins konfigurieren können, welche Informationen auch zur Kundenseite hin transparent sein sollen.

Nee, ich glaube nicht, dass ich zu groß denke. Sondern praxisorientiert im Rahmen meines persönlichen Bedarfs. Der kann natürlich bei jedem CRM-Nutzer anders gelagert sein, doch wie die Bezeichnung Kundenbeziehungsmanagement schon ausdrückt, liegt der Fokus wohl kaum auf banalem Banner-Management oder einer minimal erweiterten Mitgliederverwaltung für Sportvereine etc., sondern auf dem Handling einer größeren Kundenbasis, die jeweils auch nicht nur 5 Euro monatl. einbringen. Wenn die Erweiterung das nicht leistet, fände ich den Begriff CRM nicht zutreffend und wir reden nicht über dieselbe Sache. Sooo komplex wie Standard CRM ist das ja auch garnicht, sondern eher für die ganz spezielle Anforderung der Portalkundenverwaltung. Zumindest hatte ich Deinen Plan als spezialisierte Anwendung in dieser oder ähnlicher Art verstanden. Ebenso wäre bspw. auch eine dezentrale Agenturlösung zur Verwaltung von Contao-Projekten vorstellbar. Deshalb schrieb ich ja auch, erstmal sollten Use Cases entworfen werden. Wie auch immer die dann aussehen könnten, ohne die Möglichkeit von Workflows und Vorgangsverfolgung wäre es kein CRM, sondern bloß eine Stammdatenverwaltung. Wenn wir uns darüber einig sind, wäre jedenfalls sicher, dass wir uns alle über dieselbe Sache unterhalten.

Logisch, dass Du Dich für ein neben-nebenberufliches Vorhaben möglichst nicht extra in eine neue Programmiersprache und/oder neue Frameworks einarbeiten willst. Ist ja auch okay, wenn das die Vorgabe ist. Nur ist dann eben auch eine darauf bezogene Diskussion überflüssig.

[christian.kolb]

Sondern praxisorientiert im Rahmen meines persönlichen Bedarfs.

Entwickel ich etwa für dich?

Workflows und ähnliches wären bestimmt interessante Erweiterungen für ein CRM innerhalb von Contao, aber diese kommen sicher erst später (wenn überhaupt). Zuerst wird es sicher erst einmal eine Stammdatenhaltung mit bestimmten Optionen sein. Ob man das dann CRM nennen kann, ist Ansichtssache. Hast du einen besseren Titel? Bin offen für alles

Logisch, dass Du Dich für ein neben-nebenberufliches Vorhaben möglichst nicht extra in eine neue Programmiersprache und/oder neue Frameworks einarbeiten willst. Ist ja auch okay, wenn das die Vorgabe ist. Nur ist dann eben auch eine darauf bezogene Diskussion überflüssig.

Darüber habe ich nie eine Diskussion gestartet. Die einzige Frage die ich gestellt habe, war die nach dem Betriebssystem und nach der Interesse. Frameworks standen doch nie zur Debatte

Deshalb weiter die einfachen Fragen:

• Betriebssystem?
• Interesse?

Gruß
Christian

[soweit_ok]

Hihi, Du bist ja lustig. Nö, natürlich entwickelst Du nicht für mich. Den "persönlichen Bedarf" zu nennen, bezog sich bloß auf Deine Frage nach dem Interesse, welches sich ja eben meist daran orientiert. Und aus der Summe aller derartigen Nennungen kannst Du eine Gewichtung ableiten als Entscheidungshilfe, was Du implementieren willst. Also als Beitrag zu Deiner Recherche, welche unterschiedlichen Wünsche die User mit einer solchen Erweiterung gern abgedeckt sehen würden. Schließlich erwarte und schrieb ich nicht, dass dies speziell meine sein müssen.

Was die Namensgebung angeht, ich finde immer die Bezeichnung am besten, welche die Leistungsmerkmale der Erweiterung am zutreffendsten umschreibt. Nicht als Wertung gemeint, doch mit einem CRM hat Deine Vorstellung zumindest der ersten Ausbaustufe vielleicht noch nicht so wahnsinnig viel gemein und "Kundenverwaltung" oder auch "Kundenvorgangsverwaltung" würde es womöglich eher treffen. Aber warten wir doch erstmal ab, bis Dein konkreter Projektplan und das Grobkonzept vorliegen. Nur - da Du Dein Vorhaben im Thread nunmal als CRM bezeichnetest, ist es nicht verwunderlich, wenn typische CRM-Features angesprochen werden.

[legalstuff]

Also grundsätzlich besteht Interesse!
System Linux (Ubuntu 10.04),
derzeitiges CRM Julitec, da Kundendaten bei uns möglichst nicht kpl. ins Internet sollen.

Da größere Firmen schon Probleme mit Datensicherheit haben (egal aus welchem Grund), aber die "Begehrlichkeit" an solchen Daten nimmt einfach ungemein zu.
Und wir möchten einfach keinem Kunden erklären müssen, warum z.B. Bankdaten, oder auch nur e-Mails in falsche Hände geraten sind.


Wenn hier eine Möglichkeit besteht, z.B. aus Julitec, eine Schnittstelle zu den für den Kunden interessanten Informationen der Zusammenarbeit aktuell sehen zu können, OK, aber halt nicht alle Daten aus dem CRM.

Software ist NIE Fehlerfrei, Compiler sind es schon nicht. Die vielen Adobe, Java und MS - Bugs der letzten zeit zeigen es.

[soweit_ok]

Also grundsätzlich besteht Interesse!
Da größere Firmen schon Probleme mit Datensicherheit haben (egal aus welchem Grund), aber die "Begehrlichkeit" an solchen Daten nimmt einfach ungemein zu.
Und wir möchten einfach keinem Kunden erklären müssen, warum z.B. Bankdaten, oder auch nur e-Mails in falsche Hände geraten sind.
Wenn hier eine Möglichkeit besteht, z.B. aus Julitec, eine Schnittstelle zu den für den Kunden interessanten Informationen der Zusammenarbeit aktuell sehen zu können, OK, aber halt nicht alle Daten aus dem CRM.

Exakt dasselbe schrieb ich weiter oben auch schon, doch offensichtlich sind die diesbezüglichen Einschätzungen wohl unterschiedlich. Wenn man bereits aus der Praxis kennt, wie extrem insbesondere große Unternehmen aus guten Gründen heute die Kontaktdaten ihrer Mitarbeiter nach außen abschirmen (ohne Vertrauenszertifikat bekommst du außer von ihm persönlich nicht mal die Emailadr. eines Ansprechpartners, geschweige denn eine Telnr.), kann man sich wahrscheinlich eher vorstellen, dass dieses Verhalten mehr und mehr auch auf den Mittelstand übergreift.

Macht deshalb das Vorhaben eines kleinen CRM für Contao nicht überflüssig. Ich bin halt nur davon überzeugt, dass Kunden in der Onlinedatenbank überwiegend nur öffentlich unbedenkliche Daten zur Speicherung freigeben würden. Speichert man ohne deren Wissen nicht explizit freigegebene, insbesondere Bewegungsdaten und das würde mal gehackt, dann wäre vermutlich der Teufel los. Praktisch alle nennenswerten CRM-Hersteller haben meines Wissens den Ansatz: Daten im Intranet und nur die Präsentation auch im Web, z. B. für den dezentralen autorisierten Zugriff auf segmentierte Datasets durch Vertriebsaußendienst und Kunden.

Julitec entwickelt übrigens gemäß einer Auskunft vom letzten Jahr ebenfalls ein Web-Interface mit dem genannten Konzept. Wie der akt. Stand dabei ist, weiß ich momentan nicht.

[legalstuff]

Bei Julitec habe ich nur ein Problem, es lässt sich problemlos unter Ubuntu installieren, doch leider (das WINE) findet es dann den OpenOffice-Writer nicht.

Ob es inzwischen mit Libre-Office zusammenarbeitet ist mir nicht bekannt.

Aber wir kommen hier vom Thema ab.

[soweit_ok]

Ja, damit kämen wir wirklich zu weit vom Thema ab und sollten wir nicht weiter vertiefen. Nur eben noch soviel ...

Weil ich mir an WINE mitunter selber schon die Zähne ausbiss, verwende ich es schon lange nicht mehr. Bei mir läuft Julitec in einer Windows VM. Denn Du es so machst, könntest Du darin auch ein zusätzliches OpenOffice installieren, das seine Dateien in einem Shared Folder mit kompatiblen Filesystem ablegt, damit Du auch unter Linux darauf zugreifen kannst. Vielleicht gibt´s elegantere Lösungen, aber eine andere weiß ich nicht.

[Sebastian]

HI

Es wäre nett, wenn ihr derartige Diskussionen über andere Software vielleicht privat führen könnte.
Hier soll es nur um eine CRM-Extension für Contao gehen, was der Threadersteller ja nun auch schon einige Male kundgetan hat.

Sebastian

[soweit_ok]

HI
Es wäre nett, wenn ihr derartige Diskussionen über andere Software vielleicht privat führen könnte.
Hier soll es nur um eine CRM-Extension für Contao gehen, was der Threadersteller ja nun auch schon einige Male kundgetan hat.
Sebastian

Na klar, ist okay und hatten wir aus dem Grund auch schon selbst angemerkt, dass Probleme mit anderer Software vom Thema abkommen. Nehme ich als berechtigte Kritik natürlich an.

Davon mal abgesehen hatte der Threadersteller nach dem Wunsch nach Schnittstellen zu anderen CRM sowie konzeptionellen Aspekten gefragt. Nach meinem Verständnis zählte deshalb auch die vergleichende Betrachtung anderer Systeme jenseits des "heiligen" Contao ebenso zum Kontext wie die Debatte, welche Programmiersprachen und Frameworks am besten zur Entwicklung des lokalen Clients geeignet seien - gleichfalls "andere" Software. Aber lass uns das am besten nicht weiter vertiefen. Ich halte meine Klappe und gut ist.

[ku-ma-122]

@ku-ma-122:
Titanium sieht interessant aus, aber gerade in den Programmiersprachen des Desktop Teils habe ich nur wenig Erfahrung.
PS: Welches Betriebssystem hast du denn?

Ich benutze Mac OSX

Ein bisschen schade, dass diese Disskussion so ausschweift. Hoffentlich lässt Du dich dadurch nicht von Deinem Vorhaben abbringen ...

[christian.kolb]

@ku-ma-122:
Meine Motivation wäre nicht sehr hoch, wenn ich mich von sowas von meinem Vorhaben abbringen lassen würde

Allerdings hat sich mein Vorhaben, unabhängig von den Beiträgen hier, ziemlich geändert. Ich habe auf der Contao-Konferenz mit einigen Leuten gesprochen und die meisten Meinungen waren die selben:
Desktop App eigentlich eine tolle Idee, aber verlangsamt natürlich die Entwicklung und birgt ein zusätzliches Sicherheitsrisiko. Außerdem hatten ein paar Mac User Probleme mit der Ribbon Navigation (da es nicht zum einheitlichen Design von Mac passt) was ich auch verstehen kann.

Die Desktop App wird jetzt also erst einmal wegfallen und die Bearbeitung der Inhalte wird doch in Contao stattfinden. Damit entspricht die Erweiterung doch eher der Idee der ersten Version. Abgesehen von einem wichtigen Detail. Ich habe vor das CRM viel mehr mit den bestehenden Contao Modulen zu verdrahten. Kunden => Mitglieder, Termine => Events, Tasks => Aufgaben (Todos) (vielleicht fällt euch auch noch mehr ein).

Ich bin momentan so richtig motiviert und werde deshalb gleich durchstarten. Das heißt ich bräuchte auch bald ein paar Tester die mich unterstützen. Jetzt bin ich ja mal auf Feedback und Resonanz gespannt

Gruß
Christian

[schumja]

@ku-ma-122:
Ich bin momentan so richtig motiviert und werde deshalb gleich durchstarten. Das heißt ich bräuchte auch bald ein paar Tester die mich unterstützen. Jetzt bin ich ja mal auf Feedback und Resonanz gespannt

Gruß
Christian

Da bin ich sofort dabei wenn es ums testen geht, da mir bisher die auch z.T. shcon genannten Programme nicht wirklich gefallen

[soweit_ok]

Ich würde mich ebenfalls gern zum testen anbieten. Momentan ginge es leider nur lokal, mein akt. Vorhaben geht erst in ca. 2 Mon. live. Dein neuer (alter Ansatz) und auch, soweit praktikabel, bestehende Contao-Module einzubinden, gefällt mir wesentlich besser.
Zwischenzeitlich sind mir auch noch ein paar Ideen dazu gekommen, die viell. auch Dir und anderen gefallen könnten, ich weiß es nicht ...

• Wenn die Kundenverwaltung in die Benutzer u. Benutzergruppenverwaltung integrierbar wäre und für FE-Einsatz auch an die Mitgliederverwaltung.
• Wenn zu den Kunden und beliebig vielen derer Ansprechpartner jeweils ein Profil angelegt werden könnte. Idealerweise vielleicht sogar mit konfigurierbaren Feldern und auch Grafiken (Fotos, Logo etc.). So könnte man die Anwendung auch universeller einsetzen und ein "Kunde" könnte dann ebensogut ein Vereinsmitglied, Community-Mitglied oder sonstwas sein. Bzw. der "Kunde" ebenso eine Einzelperson wie auch eine Gruppe mit Membern sein.
• Wenn man denen auch verbundene Pages und evtl. Inhaltselemente zuordnen könnte. Da Seiten bei Bedarf geschützt werden können, ließen sich so mit Bordmitteln sogar ganz simpel Dokumenten- u. Projektstrukturen angelegen.
• Wenn auch noch ein internes Nachrichtensystem dafür verfügbar wäre.
• Wenn man ohne Template- und/oder CSS-Eingriffe ggf. nicht benötigte Teile wie z. B. "Rechnungen" oder "Aufgaben" ausblenden könnte. Zu sehen, was man für den jeweiligen Zweck nicht braucht, irritiert ja bloß.

Es wäre viell. nicht unbedingt schlimm, wenn der Oberbegriff so etwas universeller einfach "Beziehungsmanagement" lauten würde und nicht nur speziell "Kundenbeziehungsmanagement, oder?

[christian.kolb]

Hallo Zusammen,

hier mal der aktuelle Stand + ein bisschen Planung:

Konzeptionell ist folgendes geplant:

1. Mitglied kann zum Kunden werden
2. Projekte können angelegt werden (Kunde 1 : * Projekt)
3. Leistungen können angelegt werden (Leistung * : 1 Projekt)
4. Leistungstypen können angelegt werden (Leistungstyp 1 : * Leistung)

Um ein Mitglied zu einem Kunden zu machen ist nur ein Klick notwendig:




Alle Kunden werden im Backend mit ihren Projekten und deren Leistungen aufgelistet:


(Das Icon bei jeder Leistung wird im Leistungstyp definiert)

Aktuell lassen sich Kunden komplett verwalten und die Datenbank ist für die anderen Elemente vorbereitet. Alle Daten aus dem Screenshot kommen aus der Datenbank sind allerdings noch manuell eingetragen.

Nächste Schritte:

• Verwaltung der Projekte, Leistungstypen und Leistungen
• Adressen zu Kunden hinzufügen (möglicherweise lässt sich der Adressenteil von Isotope nutzen, werde Andreas diesbezüglich anschreiben)

Ideen:

• Durch die Auflistung der Leistungen könnten Rechnungen direkt daraus generiert werden.
• Momentan enthält jede Leistung den Preis der für die Leistung berechnet wird, mögliche Zusatzattribute wären Abrechnungsintervall und Leistungsdatum
• Da es sich ja schnell um einige Projekte und Leistungen handelt wird die Übersicht bestimmt schnell unübersichtlich. Deshalb sollten alle Kunden und Projekte jeweils auf- und zugeklappt werden können.

Meinungen und Kommentare erwünscht

Gruß
Christian

[christian.kolb]

Guten Abend Zusammen,

es gibt ein kleines Update.

Inzwischen können auch Projekte und Leistungen über die Kundenansicht angelegt werden:



Die Leistungstypen können über die Einstellungen gesetzt werden:



Ein Leistungstyp:



Nächster Schritt:

• Adressen verwalten

Idee:

• Weitere Felder für Projekt wie z. B. Projektleiter (Contao Benutzer)

Wie zuvor Kommentare, Meinungen oder auch Feldvorschläge erwünscht

Gruß
Christian