Individuelle Softwareentwicklung aus der Türkei für Ihr Unternehmen

Prozessregeln in Software überführen

Individuelle Softwareentwicklung beurteilen wir zunächst anhand der Entscheidungspunkte Ihrer Geschäftsabläufe, nicht anhand der Anzahl der Oberflächen. Wer eine Bestellung annimmt, unter welchen Bedingungen sie abgelehnt wird, was bei unzureichendem Lagerbestand geschieht und wie nachträgliche Korrekturen erfasst werden, bildet den Ausgangspunkt der Konzeption. Wenn Mitarbeitende dieselbe Aufgabe auf unterschiedliche Weise erledigen, muss vor der Automatisierung eine gemeinsame Regel festgelegt werden. Andernfalls verbreitet die Software Unklarheiten schneller, statt sie zu lösen.

In der Anforderungsanalyse arbeiten wir mit Beispieldokumenten, anonymisierten Datensätzen und alltäglichen Ausnahmefällen. Zum Umfang gehören neben dem regulären Ablauf auch stornierte Vorgänge, fehlende Angaben, falsche Preise und unberechtigte Anfragen. Für jedes Modul halten wir das erwartete Ergebnis, die Benutzerrolle und das Verhalten im Fehlerfall schriftlich fest. So wird aus einer allgemeinen Funktionsliste ein Projekt mit messbaren Abnahmeszenarien.

Wenn ein Standardprodukt den Bedarf erfüllt, ist die Entwicklung eines neuen Systems nicht zwingend notwendig. Individuelle Entwicklung ist dann sinnvoll, wenn unternehmensspezifische Entscheidungsregeln, unterschiedliche Datengrenzen zwischen Organisationen oder von bestehenden Produkten nicht abgedeckte Abläufe dies erfordern. Im ersten Gespräch legen wir gemeinsam fest, welche Bestandteile erhalten bleiben, welche sich ändern und warum dies notwendig ist.

Berechtigungen, Transaktionsintegrität und Releaseplanung in Webanwendungen

Eine Verwaltungsanwendung, die über den Browser erreichbar ist, besteht nicht nur aus mobilgerechten Oberflächen. Eine ausgeblendete Schaltfläche bietet keine Sicherheit; der Server muss bei jeder Anfrage prüfen, ob die betreffende Person den jeweiligen Datensatz lesen oder ändern darf. Wir bilden die Grenzen zwischen Niederlassungen, Abteilungen und Kundenkonten in den Datenabfragen ab. Auch indirekte Zugriffe über Listen, Exporte und Dateidownloads unterliegen denselben Regeln.

Wenn mehrere Personen am selben Datensatz arbeiten, planen wir den Umgang mit Änderungskonflikten. Statt dass ein veraltetes Formular neuere Informationen überschreibt, erhält die betreffende Person Gelegenheit zur erneuten Prüfung. Vorgänge, die mehrere Tabellen betreffen, werden so gestaltet, dass ein Abbruch keine inkonsistenten Ergebnisse hinterlässt. Externe Folgeaktionen wie der Versand von Benachrichtigungen können nach Abschluss des Hauptvorgangs ausgeführt werden.

Bei der Releaseplanung betrachten wir Anwendungsversion, Datenbankänderung und Rückkehr zur vorherigen Version gemeinsam. Eine Sicherung, deren Wiederherstellung nicht erprobt wurde, ist allein noch kein ausreichender Nachweis. Die Abnahme umfasst deshalb auch eine beispielhafte Wiederherstellung, Berechtigungsprüfungen und die Untersuchung häufig genutzter Abfragen mit dem vorgesehenen Datenvolumen. Die Barcodeeingabe durch das Lagerpersonal stellt andere Anforderungen an die Oberfläche als ein detaillierter Bericht für die Geschäftsleitung.

Kundenidentität und Vertriebshistorie im CRM

Bei einem CRM-Projekt geht es zunächst nicht darum, einen Kundenstammsatz anzulegen, sondern Datensätze desselben Kunden aus verschiedenen Kanälen korrekt miteinander zu verknüpfen. Eine Telefonnummer ist nicht in jedem Fall ein verlässliches Identifikationsmerkmal; eine gemeinsam genutzte Firmentelefonnummer oder geänderte Kontaktdaten können zu falschen Zusammenführungen führen. Wir definieren, wer Datensätze zusammenführen oder trennen darf und wie die Historie erhalten bleibt.

Verkaufschance und Kundendatensatz haben getrennte Lebenszyklen. Für einen Kunden können mehrere Verkaufschancen gleichzeitig bestehen; eine verlorene Verkaufschance erfordert nicht die Löschung des Kunden. Angebotsrevisionen, freigegebene Preise und Wechsel der zuständigen Vertriebsmitarbeitenden bleiben nachvollziehbar. Die Phasen der Vertriebspipeline sind nicht nur farbige Spalten, sondern werden durch Übergangsbedingungen und erforderliche Angaben gestützt.

Besonders wichtig ist, auf welches Datum sich Berichte beziehen: Je nach Erstellungs-, Abschluss- oder Zahlungseingangsdatum können die Ergebnisse unterschiedlich ausfallen. Wir erstellen keine Kennzahlen, bevor sich das Team auf die Definitionen geeinigt hat. Um Webformulare, Anrufprotokolle und Nachrichtendienste an den CRM-Ablauf anzubinden, können Sie unsere Integrationslösungen nutzen. Dabei wählen wir zweckgerechte Datenfelder aus, statt unnötige personenbezogene Daten zu kopieren.

Bewegungsdaten in ERP und Vorbuchhaltung

In einer Software für Lagerbestand und Kontokorrentkonten reicht ein einzelnes Feld zur Änderung des aktuellen Saldos nicht aus, um die Ursachen der Vorgänge zu erklären. Zugänge, Abgänge, Inventurdifferenzen, Retouren und Umbuchungen werden als getrennte Bewegungsdatensätze modelliert. Wird ein Beleg storniert, kann er mit einer Korrekturbuchung verknüpft werden, statt die Historie zu löschen. So kann das Buchhaltungsteam eine Zahl rückwirkend nachvollziehen.

Einheit, Verpackungsumrechnung, Variante und Lagercode eines Produktstammsatzes werden zu Beginn geklärt. Bei Produkten, die kartonweise eingekauft, aber einzeln verkauft werden, prüfen wir die Umrechnung sowie Rundungsregeln und Regeln für negative Bestände anhand von Testfällen. Auch die Transportzeit zwischen mehreren Lagern ist ein eigener Prozessstatus; es wäre nicht korrekt, die Ware gleichzeitig in beiden Lagern als verfügbar auszuweisen.

Eine Verwaltungsoberfläche für die Vorbuchhaltung ersetzt nicht die Verantwortung für die ordnungsgemäße Buchführung. Gemeinsam mit den zuständigen Mitarbeitenden legen wir fest, wo Finanz- und Betriebsdaten zusammengeführt werden und welches Programm maßgeblich ist. Bei der ersten Migration werden Eröffnungssalden und Bewegungssummen abgeglichen; die bisherige Datenquelle wird erst stillgelegt, wenn Abweichungen geprüft und freigegeben sind. Für Zusammenhänge zwischen Produktionsschritten, Materialverbrauch und fertigen Produkten kann zusätzlich unser Ansatz für den Industrie- und Produktionssektor betrachtet werden.

Mandantengrenzen und Abonnementstatus in SaaS-Produkten

Bei der SaaS-Entwicklung definieren wir die Datengrenzen jedes Unternehmens, bevor wir die Abonnementoberfläche gestalten. Die Unternehmenszuordnung erfolgt nicht im Vertrauen auf einen vom Benutzer übermittelten Parameter; Mitgliedschaft und Berechtigungen werden auf dem Server geprüft. Dateien, Berichte, zeitgesteuerte Aufgaben und Suchergebnisse müssen derselben Trennungsregel folgen. In den Abnahmeszenarien untersuchen wir mit zwei getrennten Unternehmenskonten, ob unternehmensübergreifende Zugriffe möglich sind.

Tarifwechsel, fehlgeschlagene Zahlungen, das Ende einer Testphase und die Kündigung eines Abonnements gehören zum täglichen Produktbetrieb. Ob sie den Zugriff sofort oder erst zum Ende des Abrechnungszeitraums verändern, wird durch schriftliche Produktentscheidungen festgelegt. Was mit bestehenden Daten eines Kontos beim Erreichen einer Nutzungsgrenze geschieht, welche Exportrechte bestehen und wie die Reaktivierung erfolgt, bleibt nicht offen. Ein Zahlungsmodell wird erst zugesagt, wenn die Möglichkeiten des Zahlungsanbieters geprüft sind.

Die erste Veröffentlichung sollte einen vollständigen, eigenständig nutzbaren Anwendungsablauf enthalten. Während wir die Grenzen für spätere Erweiterungen festlegen, werden Sicherheit und Datenintegrität nicht auf später verschoben. Bei Anwendungen mit mobilem Zugriffsbedarf wird die Entwicklung mobiler Apps als eigener Bedarf neben dem Produktkern geplant; für die Produktpräsentation gilt dies entsprechend für das Webdesign.

Preissichtbarkeit und Bestellfreigabe im B2B-Portal

Preise im Händlerportal können auf anderen Regeln beruhen als öffentlich sichtbare Katalogpreise. Händlergruppe, Vertrag, Produktkategorie, Währung und Bestellmenge können den Preis beeinflussen. Die Rangfolge dieser Regeln bestimmen wir anhand von Beispielbestellungen. Es muss klar sein, zu welchem Zeitpunkt der im Portal angezeigte Betrag im Bestelldatensatz festgeschrieben wird und ob bei einer Preisänderung eine erneute Bestätigung durch den Kunden erforderlich ist.

Die Anzeige des Kontokorrentsaldos und die Berechtigung zur Bestellung auf Zahlungsziel werden voneinander getrennt. Aufgrund eines Kreditlimits, eines ausstehenden Zahlungseingangs oder einer erforderlichen Freigabe durch den Vertrieb kann eine Bestellung im Entwurfsstatus verbleiben. Stornierungen, Teillieferungen und Produktänderungen müssen den Unterschied zwischen dem ursprünglichen und dem endgültigen Bestellbetrag nachvollziehbar machen. Die zum Zeitpunkt des Vorgangs gültige Adresse und die Geschäftsdaten werden unabhängig von späteren Änderungen am Kundenstammsatz aufbewahrt.

Bei der ERP-Anbindung sind der Eingang einer Bestellung und ihre Annahme durch das ERP unterschiedliche Status. Die Meldung, die der Händler auf der Oberfläche sehen soll, wird entsprechend gestaltet. Lösungen, die auch den Verkauf an Endverbraucher abdecken, können gemeinsam mit einer E-Commerce-Infrastruktur betrachtet werden; Händlerberechtigungen und geschlossene Preislisten werden jedoch nicht mit dem Ablauf eines öffentlichen Shops vermischt.

Kapazität, Dauer und Überschneidungsregeln bei Reservierungen

Ein Reservierungssystem setzt nicht nur farbige Felder in einen Kalender. Für denselben Zeitraum müssen möglicherweise mehrere Ressourcen wie Räume, Personal, Geräte oder Fahrzeuge verfügbar sein. Auch Vorbereitungs- und Reinigungszeiten beeinflussen die Kapazität. Wenn mehrere Personen gleichzeitig denselben freien Zeitraum auswählen, muss die endgültige Entscheidung auf dem Server unter Wahrung der Transaktionsintegrität fallen; dass zwei Browser unabhängig voneinander eine freie Zeit anzeigen, begründet noch keinen Reservierungsanspruch.

Das Verhältnis zwischen der Dauer einer vorläufigen Reservierung und dem Zahlungsergebnis wird gesondert definiert. Wir legen fest, wie mit einer nachträglichen Meldung über eine erfolgreiche Zahlung für eine bereits abgelaufene vorläufige Reservierung umgegangen wird. Zeitzonen, Leistungen über Mitternacht hinweg, Feiertage und Urlaubszeiten des Personals werden in die Testdaten aufgenommen. Stornierungsrechte und Erstattungen beruhen auf betrieblichen Entscheidungen; die Software setzt diese durch verständliche Status um.

Ein in eine bestehende Website integrierter Reservierungsablauf und eine eigenständige Verwaltungsoberfläche für den operativen Betrieb erfüllen unterschiedliche Nutzungsanforderungen. An den Beispielen einer Website für Autovermietungen und einer Website für Kliniken und Arztpraxen lässt sich erkennen, warum dieselbe Kalenderlogik unterschiedliche Ressourcen- und Informationsgrenzen benötigt.

Wie vergleichen wir Standardsoftware und individuelle Entwicklung?

Beim Vergleich betrachten wir nicht nur den Anschaffungspreis, sondern auch die langfristige Tragfähigkeit des Betriebs. Bei Standardsoftware prüfen wir den Updateprozess, den Datenexport, die Zugriffsberechtigungen und die zulässigen Anbindungen. Bei individueller Entwicklung berücksichtigen wir die Ressourcen für Analyse, Betrieb, Sicherheitsupdates und veränderte Anforderungen. Kein Ansatz ist von sich aus wartungsfrei oder ohne laufende Kosten.

Eine häufig geprüfte Option besteht darin, das vorhandene Buchhaltungsprogramm beizubehalten und unternehmensspezifische Annahme- und Planungsabläufe separat zu entwickeln. Dabei wägen wir den Umfang der Umstellung, den Lernaufwand für Mitarbeitende und das Risiko einer doppelten Datenverwaltung gemeinsam ab. Statt die Entscheidung allein an der Benutzerzahl oder dem Namen einer Technologie festzumachen, begründen wir sie anhand realer Geschäftsbeispiele.

Entwicklungspartner anhand von Abnahme- und Übergabenachweisen auswählen

Beim Angebotsvergleich ist neben einer funktionierenden Demo auch wichtig, wie die Lieferung abgenommen wird. Im Voraus sollte feststehen, wer welche Szenarien prüft, damit ein Modul als abgeschlossen gilt, welche Fehlerschweregrade gelten und wie mit offenen Feststellungen umgegangen wird. Die Erwartungen der Projektleitung können sich von denen der täglichen Anwender unterscheiden; deshalb beziehen wir auch die Personen in die Abnahmegruppe ein, die die operativen Aufgaben ausführen.

Bei unseren vertraglich geregelten und in Rechnung gestellten individuellen Softwareprojekten gehören die Übergabe des Quellcodes, der Datenbankstruktur und der Installationsinformationen zum Übergabeumfang; hier werden auch die Bedingungen für ein Jahr technischen Support nach der Übergabe festgelegt. Lizenzen von Drittanbieterkomponenten werden separat erläutert. Neue Funktionswünsche werden von Fehlern im abgenommenen Verhalten unterschieden; die nach Ende des Wartungszeitraums fortbestehenden Verantwortlichkeiten werden gesondert besprochen.

Die Übergabedokumentation sollte nicht nur aus einer Dateiliste bestehen. Umgebungseinstellungen, Aufgaben, Zugriffsverantwortliche und Wiederherstellungsverfahren werden erläutert; vertrauliche Werte werden getrennt von offen zugänglichen Dokumenten aufbewahrt. Die sichtbaren Funktionen veröffentlichter Projekte können Sie auf unserer Referenzseite ansehen. Da jedes Projekt einen anderen technischen Umfang hat, wird nicht vorausgesetzt, dass sämtliche Funktionen einer Referenz automatisch auch im neuen Projekt enthalten sind.