Home / FAQs / Softwareprojektstart und Programmauswahl
QUESTION & ANSWER

Wie sollten Low Code, Open Source Systeme und Custom Development ausgewählt werden?

Low Code eignet sich für Prozesse, die klar, veränderlich und plattformfähig sind, um höhere interne Anwendungen abzudecken; Open-Source-Systeme eignen sich für reife Produkte, die durch Konfiguration und Sekundärentwicklung die Nachfrage befriedigen können; die Entwicklung von Projekten anpassen, die für differenzierte Prozesse, komplexe Integration, Leistung oder höhere Produktkontrollanforderungen geeignet sind. Die Auswahl erfolgt mit einem Vergleich der Gesamtkosten und der Ausstiegskapazität für drei bis fünf Jahre und nicht nur mit dem ersten Preis. Unternehmen können auch Kombinationswege verwenden, so dass verschiedene Technologien die am besten geeignete Geschäftsgrenze einnehmen können.

Beantworten Sie die Frage.

Geben Sie zuerst Schlussfolgerungen, die für die Entscheidungsfindung verwendet werden können

Der Mindestcode ist die Bestätigung von Autorisierung, Export und Plattform-Lock-In; Open-Source-Prüfungen für Lizenzen, Communities, Upgrades und Sekundärgrenzen; passt sich an die technische Qualität, die Personalkontinuität und die Codeübernahme an.

DECISION FACTORS

Welche Bedingungen müssen vor der Entscheidungsfindung festgelegt werden?

Die gleiche Frage kann in unterschiedlichen Geschäfts-, Daten- und Projektphasen unterschiedliche Antworten haben, und es wird vorgeschlagen, die folgenden Bedingungen zu überprüfen und die gemeinsamen Ergebnisse im Internet in ihre eigenen Projekte einzuarbeiten.

Inwieweit Kernprozesse mit Standardprodukten übereinstimmenKünftige Änderungshäufigkeit und interne WartungskapazitätDelegation von Autoritäten, Cloud-Ressourcen, Upgrades und langfristigen KostenQuellcode, Daten, Schnittstellen und Portabilität
ACTION STEPS

Vorgeschlagene Reihenfolge des Vorschusses

01

Zuerst werden wir uns über das Ziel und die Grenze im Klaren sein.

Definieren Sie Geschäftsanforderungen, Unterschiede und nicht-funktionale Anforderungen.

02

Validierungsschlüsselabhängigkeit

Validierung der Abdeckung der Plattform, Open Source und Anpassungsprogramme.

03

Entwicklung bewertbarer Ergebnisse

Kostenschätzungen für Bau, Abonnement, Upgrade und Wartung für drei bis fünf Jahre.

04

Stellen Sie sicher, dass Sie den nächsten Schritt mit den tatsächlichen Ergebnissen entscheiden.

Wählen Sie eine Gruppe, die akzeptabel ist, skalierbar ist und einen Ausstiegspfad hat.

PRACTICAL EXAMPLE

Wie verstehen Sie es im eigentlichen Geschäft?

Beispiel zur Erläuterung der Beurteilungsmethode

Der Geschäftsgenehmigungsprozess kann schnell mit niedrig codierten, Client-Services können auf Open-Source-Arbeitslistensystemen basieren und einzigartige Preismaschinen werden angepasst und entwickelt und durch API verbunden. Der Kombinationsansatz ist oft sicherer als die Einführung einer Technologie, die alle Bedürfnisse abdeckt.

COMMON RISKS

Die einfachste Grube, auf die man treten kann.

Low Code als Nullentwicklung und Nullwartung

Open-Source-System ohne Rücksicht auf Lizenz- und Upgrade-Kosten nutzen

Custom Development hat keine Dokumentations-, Test- und Übernahmeanforderungen

ACCEPTANCE

Wie sollen wir am Ende empfangen und bestätigen?

Der technische Auswahlbericht sollte die funktionale Abdeckung, Lücken, Prototypenergebnisse, Autorisierung, Leistung, Sicherheit, Integration, Wartung und Ausstiegsoptionen enthalten.

Bei der Vorbereitung auf die Kommunikation mit Lieferanten oder internen Teams empfiehlt es sich, aktuelle Prozesse, repräsentative Muster, bestehende Systeme, Planungszeit und Budgetniveaus mitzunehmen. Zunächst werden die unbekannten Elemente eindeutig gekennzeichnet und dann wird die Entscheidung für Diagnostik, PoC, Feststreckenprojekte oder laufende Forschung und Entwicklung getroffen, was in der Regel zuverlässiger ist als eine direkte Forderung nach einem Preis und einer Dauer ohne Grenzen.

Ihre Projektbedingungen unterscheiden sich von den oben genannten Beispielen?

Betriebsziele, bestehende Systeme, Stichproben und geplante Zeit könnten zusammengetragen werden, bevor Berater vorläufige Entscheidungen in Bezug auf tatsächliche Grenzen treffen könnten.

Assoziierte Projektberater