Einige CRMs und ERPs sind bereits in Module aufgeteilt. Ein Modulsystem ist eine tolle Idee, aber die Umsetzung ist meist ungünstig.
Module sind zu grob – friss oder stirb
Ein absolutes Negativ-Beispiel in diesme Bereich ist das Tine2.0-CRM. Es ist zwar in Module unterteilt, will man aber das CRM-Modul aktivieren, müssen alle anderen Module aktiviert sein. Darunter auch die Warenwirtschaft, die wir ja gar nicht brauchen.
Aspektorientierte Programmierung, Featureorientierte Programmierung
Ansätze aus der Wissenschaft gibt es schon: Sogenannte Code Weaver „weben“ quasi Code anhand von Regeln zusammen. Das Programm ist in Aspekte bzw. Features unterteilt, die man bei der Konfiguration einfach aktivieren oder deaktivieren kann. So ist es mögkich, dem einen Kunden das CRM mit PDF-Angebotserstellung auszuliefern, dem anderen ohne.
Beschreibungslogik als Basis für Feature Oriented Programming
Wir bei Launix haben einen Codegenerator entwickelt, der auf Basis logischer Formeln arbeitet. Dieser ermöglicht es uns, individuell programmierte Projekte zum Bruchteil des Preises anzubieten. Besonders wiederkehrende Elemente wie die Kundenliste in der Unternehmens-Software sind bisher ein extremer Arbeitsaufwand gewesen, da jeder Kunde andere Feinheiten implementiert haben will.
Durch ein deskriptives System ist es möglich, eine Software anhand von „Fakten“ zu beschreiben. Fakten können beispielsweise sein, dass ein Hauptmenü auf der linken Seite stehen soll. Ein anderer Fakt wäre, dass jeder Kunde eine Anschrift besitzt. Ein System von Implikationsregeln sorgt anschließend dafür, dass sich das Programm selbst programmiert.
Comments are closed