Oft sind vorhandene Rechnungsprogramme, CRM oder ERP viel zu starr aufgebaut und damit zu umst\u00e4ndlich. Wenn ein Veranstaltungsteilnehmer automatisch nach Buchung eine Rechnung erhalten soll, man im System diese aber erst m\u00fchsam h\u00e4ndisch anlegen muss, verschenkt man hunderte Arbeitsstunden.<\/p>\n\n\n\n
Das vorhandene ERP-System mit den Rechnungsdaten h\u00e4ndisch zu f\u00fcttern ist oft so aufwendig, dass dieser Schritt komplett unwirtschaftlich ist. Deshalb lohnt sich f\u00fcr viele die Investition in eine Individualsoftware<\/strong>. Ein separat programmiertes Rechnungssystem in Verkn\u00fcpfung mit der Buchungslogik automatisiert den Abrechnungsschritt wie gew\u00fcnscht.<\/p>\n\n\n\n Dieser Weg ist allerdings mit einer hohen Investition verbunden. Eine Individualentwicklung ist nicht billig und beschr\u00e4nkt sich aus Kosten- und Budgetgr\u00fcnden meist nur auf die notwendigsten Funktionen. Eine Vollkommenheit wie beim Funktionsumfang des ERP-Systems wird man damit nicht erreichen.<\/p>\n\n\n\n Die wesentlich sinnvollere Methode ist hier, die vorhandenen Funktionen des ERP weiterzunutzen und den invidividuellen Teil in ein Portal-Projekt auszulagern. Die R\u00fcck-Verbindung zum ERP findet dann \u00fcber eine sogenannte API-Schnittstelle statt.<\/p>\n\n\n\n Vorteil ist, dass man auf die etablierte Rechnungslogik des ERP zur\u00fcckgreifen kann, diese aber durch eine automatische Ausl\u00f6sung \u00fcber die API ansteuern kann. Nachteil ist der immer noch vorhandene Medienbruch zwischen ERP und dem Zusatzprogramm.<\/p>\n\n\n\n Die deutlich elegantere Variante ist, wenn man das ERP durch z.B. Skripting an seine Bed\u00fcrfnisse anpassen kann. Damit kann man den zu automatisierenden Ablauf direkt ins ERP einprogrammieren. Man bekommt alles in einem System und die Erweiterungen f\u00fcgen sich nahtlos ins Gesamtsystem ein.<\/p>\n\n\n\n Ein Manko ist die Softwarepflege und Updatef\u00e4higkeit. W\u00e4hrend der Hersteller nur seine Kernfunktionen pflegt, muss man die Erweiterungen nach jedem Update pr\u00fcfen und gegebenenfalls anpassen.<\/p>\n\n\n\n Beherrscht das ERP\/CRM Workflow-Modellierung, kann man den gew\u00fcnschten Automatisierungsschritt \u00fcber einen Editor hinzuf\u00fcgen. Dieser neue Ansatz nennt sich No-Code<\/strong>. Doch obwohl man keinen Code an sich mehr verwendet, ist die Programmierung solcher Workflows immer noch eine Experten-Arbeit.<\/p>\n\n\n\n Vorteil am No-Code-Ansatz ist auch, dass dieser offiziell vom Hersteller unterst\u00fctzt wird und somit Update-sicher ist. Nachteil ist, dass man trotzdem noch einen Experten ben\u00f6tigt, um das Verhalten zu programmieren. Zudem erlauben Workflow-Programmierungen nur einen kleinen Teilbereich zu programmieren. Da das System nicht frei programmierbar ist, ist die Menge der umsetzbaren F\u00e4lle begrenzt.<\/p>\n\n\n\n In der Entwicklung von Software hat sich mehrere Jahrzehnte lang das Objektorientierte<\/strong> Paradigma als dominante Philosophie zur Software-Strukturierung gehalten. Dabei wird Software in kleine Module, sogenannte “Klassen” gekapselt, um auch von gr\u00f6\u00dferen Teams, die miteinander kommunizieren, entwickelt werden zu k\u00f6nnen. Das Ziel war auch, wiederverwendbaren Code zu entwickeln, den man modular immer wieder zusammensetzen kann, doch gerade dieses Ziel erreichte die Objektorientierte Programmierung nie.<\/p>\n\n\n\n 2016 gab es dann die erste praktikable Umsetzung einer Featureorientierten Programmiersprache<\/strong>, die es erlaubt, updatef\u00e4hige ERP- und CRM-Erweiterungen direkt als eigene Module zu entwickeln. Damit sind v\u00f6llig neue Softwarekombinationen m\u00f6glich wie z.B. CRM+ERP, ERP+DMS, aber auch ERP+Portal.<\/p>\n\n\n\nKombination Portal+ERP<\/h2>\n\n\n\n
Skript-anpassbare ERP-Systeme<\/h2>\n\n\n\n
ERP\/CRM-Systeme mit integriertem Workflow-Management<\/h2>\n\n\n\n
FOP – Featureorientiertes Programmieren als neuartiger Ansatz, anpassbare Software zu bauen<\/h2>\n\n\n\n
Launix FOP ERP – All-In-One-Systeme Portal&ERP in einem<\/h2>\n\n\n\n