Maßgeschneidertes CRM & individuelle Software: Wann man in Ägypten selbst entwickelt

Ein Handelsunternehmen in Kairo zahlte 14 Monate lang für Zoho CRM, bevor jemand die Workarounds zusammenrechnete: drei parallel laufende Tabellen, eine Teilzeitkraft zur Abstimmung dieser Daten und Vertriebsmitarbeiter, die das System komplett ignorierten, weil es ihren Verkaufsprozess nicht abbildete. Die Kosten dieser „kostenlosen" Lösung lagen bei weit über 400.000 EGP pro Jahr an verlorener Produktivität. In diesem Moment hört die Build-or-Buy-Frage auf, theoretisch zu sein.

Wann Standard-CRM die falsche Antwort ist

HubSpot, Zoho, Odoo und Salesforce sind wirklich gute Produkte – für die Anwendungsfälle, für die sie entwickelt wurden. Probleme entstehen, wenn ein Unternehmen einen untypischen Vertriebsprozess hat, regulatorische Besonderheiten aufweist oder betriebliche Abläufe folgt, die die Entwickler nie vorhergesehen haben.

Zeichen dafür, dass Sie an die Grenzen gestoßen sind:

• Sie pflegen eine Tabelle neben dem CRM, weil das CRM eine entscheidende Funktion nicht beherrscht.
• Ihr Team hat Automatisierungen innerhalb der Plattform gebaut, die niemand mehr vollständig versteht.
• Der Anbieter hat die Preise erhöht und Sie sitzen in der Falle, weil eine Migration unmöglich erscheint.
• Ihr Arbeitsablauf umfasst arabischsprachige WhatsApp-Konversationen, die Kundendatensätzen zugeordnet werden müssen – und die Integration kostet pro Monat mehr als Ihre Miete.

Für Unternehmen mit wirklich standardisierten Prozessen – eine Beratungsfirma, die Leads verfolgt, ein SaaS-Unternehmen, das Testphasen verwaltet – ist eine Standardlösung oft die richtige Wahl. Individuelle Software ist eine Kapitalinvestition, kein automatisches Upgrade.

Der Entscheidungsrahmen für Build-or-Buy

Bevor eine einzige Zeile Spezifikation geschrieben wird, sollten vier Fragen ehrlich beantwortet werden:

1. Ist der Prozess ein Wettbewerbsvorteil? Wenn Ihre Angebotslogik oder Ihr Kunden-Onboarding etwas ist, das Mitbewerber nicht einfach kopieren können, lohnt es sich, dies in eigener Software zu besitzen. Handelt es sich um Standard-Administration, kaufen Sie eine Lösung.
2. Wie viele manuelle Übergaben hat der aktuelle Prozess? Zählen Sie sie. Wenn es pro Transaktion mehr als fünf sind, ist der ROI einer Automatisierung wahrscheinlich real.
3. Was kostet ein schlechter Monat voller Reibungsverluste? Beziffern Sie das – Arbeitsstunden, Fehler, verzögerte Rechnungen. Wenn diese Zahl größer ist als ein Build-Angebot auf drei Jahre gerechnet, haben Sie Ihre Antwort.
4. Haben Sie intern jemanden, der das System verantwortet? Individuelle Software ohne internen Verantwortlichen wird innerhalb von 18 Monaten zum Ladenhüter.

Wie man ein individuelles System spezifiziert, ohne es zu übertechnisieren

Der teuerste Fehler bei individueller Software ist nicht der Stundensatz – es ist das detaillierte Entwickeln der falschen Lösung. Ein phasenweiser 90-Tage-Ansatz funktioniert besser als eine vollständige Spezifikation im Voraus.

Phase 0: Probleme erfassen, keine Feature-Liste

Beginnen Sie damit, zu dokumentieren, was heute tatsächlich nicht funktioniert. Nicht, was das System Ihrer Meinung nach können sollte – sondern was konkret versagt, wie oft und was es kostet. Ein zweistündiger Workshop mit den Mitarbeitern, die die Arbeit täglich erledigen, bringt mehr nützliche Anforderungen zutage als ein monatelanges Brainstorming auf Führungsebene.

Phase 1: Nur den Kernprozess entwickeln

Identifizieren Sie den einzelnen Arbeitsablauf, der durch Automatisierung alles verändert. Entwickeln Sie genau diesen. Setzen Sie ihn 30 Tage lang in der Praxis ein, bevor Sie etwas hinzufügen. Das ist keine Agile-Methodik um ihrer selbst willen – es ist der einzige zuverlässige Weg herauszufinden, dass das, was Sie spezifiziert haben, und das, was Sie tatsächlich brauchten, zwei verschiedene Dinge sind.

Phase 2: Integrationen erst nach dem stabilen Kern einbauen

Verbindungen zu Buchhaltung, ERP oder WhatsApp Business herzustellen, bevor der Kern stabil ist, verdoppelt regelmäßig Zeit und Kosten. Integrationen fördern Sonderfälle zutage – und Sonderfälle brauchen eine stabile Kernlogik, um gelöst zu werden.

Integrationsmuster, die in der MENA-Region tatsächlich funktionieren

Individuelle interne Tools in Ägypten und den Golfstaaten müssen typischerweise mit drei Kategorien externer Systeme verbunden werden:

• Buchhaltung / ERP: QuickBooks, Sage oder lokal gehostete ERP-Systeme. REST-APIs funktionieren bei modernen Versionen gut; ältere Systeme benötigen oft eine Middleware-Schicht oder zeitgesteuerte Batch-Synchronisierung statt Echtzeit-Webhooks.
• WhatsApp Business API: Dies ist der Kanal, über den die meiste B2C- und sogar B2B-Kommunikation in Ägypten tatsächlich stattfindet. Die Meta Cloud API ist zugänglich und gut dokumentiert, aber das Einbinden von WhatsApp-Konversationen in CRM-Datensätze erfordert sorgfältiges Datenmodellieren – besonders wenn mehrere Mitarbeiter denselben Kunden betreuen.
• Behördliche Datenschnittstellen und Compliance-Feeds: Ägyptische Unternehmen, die mit Zoll, Steueramtsintegrationen oder WPS-Gehaltsexporten arbeiten, benötigen Integrationen, die arabische Zeichenkodierung korrekt verarbeiten und mit API-Instabilität umgehen können. Bauen Sie Wiederholungslogik von Anfang an ein.

Wenn Ihr Unternehmen auch mobilfähige Betriebsabläufe hat, kann dieselbe API-Architektur, die ein individuelles CRM antreibt, auch eine mobile App versorgen – es lohnt sich, den Überblick zur mobilen App-Entwicklung in Ägypten zu lesen, wenn das auf Ihrer Agenda steht.

Häufige Fallstricke bei individueller Softwareentwicklung

Projekte scheitern auf vorhersehbare Weise. Die schmerzhaftesten Fehler:

• Scope-Creep als Anforderungsermittlung getarnt. Jeder Stakeholder fügt „nur noch eine Kleinigkeit" hinzu, bis aus dem MVP ein vollständiges ERP geworden ist und sich der Zeitplan verdreifacht hat.
• Keine UAT-Umgebung. Tests in der Produktivumgebung sind eine reale Praxis, die echte Unternehmen betreiben – und tief bereuen.
• Falsch modellierte Berechtigungen von Anfang an. Rollenbasierte Zugriffskontrolle nachträglich in ein bestehendes Datenmodell einzubauen kostet etwa dreimal so viel, wie es in der ersten Woche gekostet hätte.
• Das erste Angebot als Spezifikation betrachten. Ein Anbieter, der auf Basis einer vagen Beschreibung anbietet, wird niedrig kalkulieren, um den Auftrag zu gewinnen, und den Umfang später ausweiten. Holen Sie zwei oder drei Angebote auf Basis derselben schriftlichen Spezifikation ein.
• Kein Datenmigrations-Plan. Die Übertragung historischer Daten aus Tabellen oder Legacy-Systemen wird konsequent unterschätzt – planen Sie mindestens 15 % der Gesamtprojektkosten dafür ein.

Was Wartung wirklich kostet

Individuelle Software ist kein einmaliger Kauf. Ein realistisches Wartungsbudget beträgt 15–20 % der ursprünglichen Entwicklungskosten pro Jahr und umfasst:

• Abhängigkeits- und Sicherheitsupdates (nicht verhandelbar)
• Fehlerbehebungen aus realen Sonderfällen (immer mehr als erwartet)
• Kleine Funktionserweiterungen mit der Geschäftsentwicklung
• Infrastrukturkosten (Hosting, CDN, Datenbank-Backups)

Ein für 500.000 EGP entwickeltes System sollte 75.000–100.000 EGP pro Jahr im Budget haben, um betriebssicher zu bleiben. Unternehmen, die darauf verzichten, enden mit einem System, das funktioniert – bis es plötzlich nicht mehr funktioniert, meistens an einem Freitagabend vor einem Feiertag.

Wo Workflow-Automatisierung ihren Platz hat

Nicht jedes interne Tool muss ein vollständiges CRM sein. Manchmal ist die renditestärkste Investition eine gezielte Automatisierung: automatische Angebotserstellung aus einer Produktdatenbank, Weiterleitung von Genehmigungsanfragen per E-Mail oder WhatsApp oder die Synchronisierung von Lagerbeständen zwischen einem Lagerverwaltungssystem und einem Online-Shop. Diese können oft in Wochen statt in Monaten entwickelt werden und liefern schneller messbaren Nutzen.

Der Test: Wenn ein Mensch dieselbe Kopier-und-Einfüge- oder Dateneingabeaufgabe mehr als 20 Mal pro Woche erledigt, ist sie automatisierbar – und die Rechnung geht fast immer auf. Teams bei ProgMine haben Genehmigungszyklen von 18 auf 3 Tage reduziert, ohne mehr zu tun als eine saubere Benachrichtigungs- und Weiterleitungsschicht auf bestehenden Daten einzuführen.

HR- und Betriebssysteme: Eine verwandte Entscheidung

Unternehmen, die diese Analyse für ihr CRM durchführen, stehen oft gleichzeitig vor derselben Frage bei HR und Zeiterfassung. Die Dynamik ist ähnlich, das Compliance-Risiko jedoch höher – ägyptisches Arbeitsrecht und WPS-Anforderungen lassen wenig Raum für Improvisation. Falls das auf Ihrer Liste steht, behandelt der HR-Software-Leitfaden für Ägypten, was vor der Entscheidung für eine Plattform – ob individuell oder nicht – geprüft werden sollte. Für Betriebe mit mehreren Standorten lohnt sich ein gesonderter Blick auf die Enterprise-HR-Besonderheiten in Ägypten.

Bereit für ein Gespräch?

Wenn Sie einen Prozess haben, der offensichtlich nicht funktioniert, aber nicht sicher sind, ob eine individuelle Entwicklung wirklich die Antwort ist, ist ein 45-minütiges Gespräch mit jemandem, der solche Systeme gebaut hat und Ihnen ehrlich sagt, wann eine Standardlösung ausreicht, meist das Nützlichste. Nehmen Sie über die ProgMine-Kontaktseite Kontakt auf – bringen Sie Ihre Tabellenanzahl und Ihre monatlichen Reibungskosten mit, und wir finden gemeinsam den richtigen Weg.