Eine Alternative?

Die Einführung von CRM-Anwendungen ist komplex. Viele vergangene Projekte haben ihre Budgetansätze stark überschritten oder nur eingeschränkt die ursprünglichen Erwartungen erfüllt. Führende Pakete gelten als funktionell stark, sind aber für viele Unternehmen auch überfrachtet, teuer und sehr schwer zu beherrschen. In manchen Fällen wurden Entscheide gegen kommerzielle Pakete gefällt und Eigenentwicklungen implementiert, jedoch auch hier wurde die Komplexität oft unterschätzt.
Mit der zunehmenden Bedeutung und Akzeptanz von Open Source (OS) in vielen Bereichen der IT stellt sich die Frage, ob OS-CRM eine Alternative sein kann.
Es gibt tatsächlich eine ganze Reihe ernstzunehmender Aktivitäten für CRM in der Open-Source-Gemeinde. Gemeinsam mit anderen OS-Projekten ist auch hier der Gedanke einer kooperativen Entwicklung bei freier Verfügbarkeit des Produktes, inklusive Sourcecode für jedermann.
Um die Eignung von CRM-OS-Paketen zu evaluieren, wurde eine Studie erstellt, welche die verschiedenen Initiativen untersucht und mit führenden kommerziellen Paketen vergleicht. Folgende wurden als interessant beurteilt und auf ihre Eignung in realen Projekten untersucht.

Compiere ist eines der ältesten Projekte und hatte seinen Anfang 1999. Es hat seine Stärken bei der Funktionalität und ist relativ reich an Funktionen im Customer-Management, Produkt- und Vertragsmanagement mit sehr guten Schnittstellen in den Bereich Logistik bis hin zur Lagerverwaltung. Case- und Beschwerdemanagement sowie Vertrieb sind bis jetzt nicht oder nur schwach ausgeprägt. Problematisch dürfte die Skalierbarkeit sein. Sowohl Frontend wie Datenbank sind nicht unbedingt performancefördernd implementiert. Es gibt keine 3-Tier-Architektur, die den Einsatz von Distribution, Transaction-Management oder andere EAI-Schittstellen unterstützen würde. Die Im--ple-mentierung basiert auf Java Swing und erfordert eine entsprechende Runtime-Umgebung. Für kleinere Anwendungen bietet es jedoch eine gute Basisfunktionalität.

XRMS, seit 2003 aktiv, beruht im Gegensatz zu Compiere auf einer sehr soliden technischen Plattform. In Perl/PHP unter Eclipse implementiert, bietet es eine saubere Trennung zwischen Applikations- und Datenbankserver. Eine klare, browserunabhängige Thin-Client-Architektur macht XRMS zu einem der ernsthaftesten Player. Das Frontend hat eine intuitive Benutzerführung bei angenehmem Gesamteindruck. Funktionell werden insbesondere Vertriebssteuerung und Marketing-Support inklusive Kampagnenmanagment abgedeckt, andere Bereiche sind eher dürftig.

Hipergate hat seinen Ursprung in Spanien, was sich im User-Interface noch niederschlägt. Funtionell ist es kein klassisches CRM-Paket, sondern hat seine Stärken im Bereich E-Sales und E-Service mit guter Basis im Kundenmanagement. Das Produkt tauchte erstmals 2003 auf und ist auf Grund einer soliden technischen Basis (3-Tier-Architektur basierend auf Tomcat, WLS 8.1.:JSP Implementation, Thin Client, Oracle, MS SQL oder Postgre-SQL als Datenbank) ein guter Startpunkt für eine darauf auf-bauende Eigenentwicklung.

Sugar CRM tauchte erstmals Mitte 2004 auf und überrascht mit einer stark ausgeprägten initialen Funktionalität, insbesondere im Bereich Vertriebssteuerung, Opportunity-Managment, Kundeninteraktion und -korrespondenz. Technisch basiert es auf PHP und My-SQL ist aber nicht unbedingt die Plattform für High-VolumeTransaktionssysteme. Der Einsatz dürfte daher auf kleinere Interaktionsvolumina begrenzt sein. Es ist das einzige Produkt mit klarer Multisprachunterstützung mit klaren GUI-Layout und guter Benutzerführung.

Open-CRX ist ebenfalls eine Neuerscheinung vom August 2004 und hat seinen Ursprung in der Schweiz. Produktsupport wird für den deutschsprachigen Raum kommerziell angeboten. Funktionell ist die Abdeckung noch dürftig und begrenzt sich auf Vertriebssteuerung und Opportunity Management. Technisch beruht das Produkt auf J2EE, basierend auf Open-MDX, arbeitet mit Thin Client oder Dotnet und unterstützt verschiedene Datenbanken, Oracle, DB2, MS SQL, jedoch nicht My-SQL.
Gemeinsam ist diesen Paketen, dass sie in ihrer Funktionalität noch weit hinter dem Umfang zurückliegen, den führende kommerzielle Anbieter wie Siebel, SAP oder Oracle zur Verfügung stellen. Insbesondere gibt es noch wenig industriespezifische Funktionalität, die die Anforderungen beispielsweise der Konsumgüterindustrie oder von Versicherungen abdecken.
Schwächen zeigen sich bei Computer Telephony Integration (CTI), Groupware-Integration (E-Mail, Adressbücher, Terminplaner), Workflow-Management, Document- Management sowie EAI Integration in kommerzielle EAI-Umgebungen. Ein weiteres Problem ist die Skalierbarkeit: Während kommerzielle Anbieter Referenzen mit mehreren Tausend parallelen Anwendern vorweisen können, haben OS-Alternativen dazu nur wenige Angaben. Eine durchaus gute Performance in einer kleinen Testumgebung bringt wenig Aussagekraft für grosse Installationen.
Zumindest für die führenden kommerziellen Anbieter werden daher OS-Lösungen noch keine direkte Bedrohung darstellen und sind keine Alternative für den direkten Out-of-the-Box-Einsatz. Jedoch haben die Pakete eine Basisfunktionalität für Service und Vertrieb, die nutzbar sowie relativ einfach implementierbar ist und sind damit in einigen Fällen eine sinnvolle Alternative.

OS-Pakete sind zumindest dann heute schon eine Option, wenn wegen spezifischer Anforderungen über eine Eigenentwicklung nachgedacht oder nur einfache Ansprüche mit kleinem Budget reali-siert werden müssen. OS-Pakete liefern dazu die Basis, um Kundeninformationen zu erfassen und zu pflegen, Service-Requests entgegen zu nehmen und zu verfolgen oder Vertriebsaktivitäten zu steuern. Die Verwendung dieser Funktionalität kann sowohl Projektkosten als auch das Risiko erheblich verringern.

Da sich Aktivitäten in der Open-Source- Community sehr dynamisch entwickeln, kann für die Zukunft auch im Bereich kommerzieller Software wie CRM oder ERP mit funktionsstarken Paketen gerechnet werden. Damit wird sich die Marktdynamik weiter in Richtung OS-Anwendungen verschieben.

Weitere Informationen

Kriterien für den Entscheid für Open-Source-CRM

Höhe des Budgets: Kleine Budgets profitieren von der lizenzfreien Verfügbarkeit einer Basisfunktionalität in höherem Masse.

Zeitlimite: Da die OS-Pakete noch recht jung am Markt sind, empfiehlt sich bei scharfen Deadlines der Rückgriff auf kommerzielle Pakete, für deren Einführung es Erfahrungen und Projektpäne gibt und oft auch Festpreise möglich sind.

Anbieterabhängigkeit: OS Pakete vermeiden jede Abhängigkeit von einem Anbieter und sind in ihrer Weiterentwicklung so unabhängig wie eine Eigenentwicklung. Die Abhängigkeit bei kommerziellen Anbietern besteht über einen langen Zeitraum und es macht daher nur Sinn, auf etablierte zu setzen.

Funktionsumfang: Welche Funktionalität wird wirklich benötigt, was ist «Nice to have»?
Bieten OS-Pakete diese Funktionalität oder
kann sie einfach dazu entwickelt werden.
Sind komplexe konfigurierbare Workflows tatsächlich erforderlich?

Definition der Geschäftsprozesse: Kommerzielle Pakete verfügen über branchenspezifische Geschäftsprozesse. Besteht auf Anwenderseite eine grosse Unsicherheit, empfiehlt sich die Abstützung auf ein kommerzielles Paket. Sind die Vorstellungen klar, spezifisch und unterschiedlich zum «Industriestandard», fährt man mit OS-Paketen besser.

Qualität des IT Supports: Kommerzielle Pakete haben diesbezüglich klare Anforderungen, die auch mit restriktiven Prozessen im IT-Bereich abgestimmt werden können. OS-Lösungen erfordern mehr Flexibilität bezüglich Beschaffung von Hardware- und Softwarekomponenten, da Voraussetzungen und Abhängigkeiten von Re-lease-levels nicht von Anfang an klar definiert sind.

Technologie-Affinität: OS-Projekte erfordern die Bereitschaft, unübliche Wege zu beschreiten. Die Bereitschaft, Erfahrung aufzubauen und darüber zu reden, ist eine wichtige Voraussetzung.

Vertraulichkeit der Umgebung: OS-Entwicklungen basieren auf dem freien Informationsaustausch mit der Community. Gibt es Einschränkungen, die etwa den Austausch von Code verhindern, kommt man auf Dauer in Schwierigkeiten.

Grösse: Da nur wenig Erfahrungen mit grossen Installationen bestehen, erhöht sich das Risiko bei OS in Umgebungen mit hohen Erwartungen an Verfügbarkeit und Reaktionszeit, beispielsweise bei mehr als 200 parallelen Anwendern. Es gibt bis heute keine dokumentierten Erfahrungen dazu und Lasttests sind erforderlich. Die genannten OS Pakete sind auch nicht besonders Perfomance-optimiert entwickelt um beispielsweise schnelle Querys bei grossen Datenvolumina zu unterstützen.

Integration: Kommerzielle Pakete haben eine klare EAI-Architektur mit dokumentierten Interfaces und teilweise fertigen Schnittstellen zu ERP Paketen. Im OS Bereich sucht man bislang z.B. eine SAP Schnittstelle vergeblich.