Business Matching
Verwenden Sie reale Prozesse, um zu überprüfen, wie viel Kernbedarf das Open-Source-System abdecken kann, nicht nur die Liste der Funktionalität und die Präsentationsseite.
Home / Projektentscheidungshilfe / Customization-Entwicklung und Open Source-Adaption
PROJECT DECISION GUIDEEntwickeln Sie aus null benutzerdefinierten oder Open-Source-System-basierten Anpassungen
Open-Source-Modifikationen sind möglicherweise nicht billiger oder besser überschaubar von Null. Der Schlüssel liegt darin, die Übereinstimmung zwischen bestehenden Open-Source-Fähigkeiten und Zieloperationen sowie zukünftigen Upgrades und Wartungskosten zu beurteilen.
Beantworten Sie die Frage.
Custom Development und Open Source Adaption
Wenn Kernprozesse üblich sind, Open-Source-Projekte ausgereift sind und Lizenzen mit Geschäftsmodellen kompatibel sind, können Open-Source-System-basierte Anpassungen den ersten Zyklus verkürzen; wenn Geschäftsregeln Kernwettbewerbsfähigkeit darstellen, die Strukturbeschränkungen klar sind oder die Tiefe der Anpassungen von Community-Versionen weg verlängert werden können, ist es normalerweise angemessener, von Null anpassbar zu sein.
DECISION FACTORS
Schlüsselelemente, die für die Entscheidungsfindung zu prüfen sind
Zunächst werden die Grenzen der Zurückhaltung und Verantwortung identifiziert, dann werden die technischen Wege und Modalitäten der Zusammenarbeit verglichen.
Lizenzierung und Geschäftsmodell
Beurteilung der zulässigen Grenzen der Nutzung, Änderung, Verteilung, SaaS-Dienste, Marken und vertrauensvollen Komponenten, vorbehaltlich der Überprüfung durch Juristen, je nach Bedarf.
Änderung der Tiefe
Schnittstellen, Marken und eine kleine Anzahl von Prozesserweiterungen sind in der Regel weniger riskant; große Änderungen in Kerndatenmodellen und Grundstrukturen können die Vorteile von Open-Source-Programmen schwächen.
Upgrade-Pfad
Es muss geklärt werden, wer für Community-Versionsupdates, Sicherheitspatches, benutzerdefinierte Zweigstellenkonsolidierung und automatisierte Regressionstests verantwortlich ist.
Teamkompetenzen und Übernahme
Jede Route sollte ausgewählt werden, und es sollten Quellcodes, Bereitstellungsanweisungen, Datenmigration, Schnittstellen und Transportdokumente eingeholt werden.
Gesamtbetriebskosten
Vergleichen Sie die Entwicklung, Lizenzierung, Cloud-Ressourcen, Upgrades, Mobilität, Sicherheit und Personalkosten für mindestens drei Jahre, anstatt sich auf das erste Angebot zu verlassen.
Ausarbeitung von Empfehlungen vor der Mitteilung oder Bewertung
Zielgeschäftsprozesse und DifferentialfunktionenAktivitäten des Open-Source-KandidatenprojektsLizenzen und vertrauensvolle KomponentenStruktur und technisches AnkermatchSicherheitslücken und AktualisierungsmechanismenSekundäre EntwicklungserweiterungspunkteVersionsupgrade und Branch PolicyGesamtkosten von drei Jahren Eigentum
Vorgeschlagener Weg zur Umsetzung
Es wird empfohlen, eine Auswahl- und Lückenanalyse durchzuführen, bei der die Outputnachfrage Matrix, Lizenzrisiko, Anpassungsliste, Modernisierungsstrategie und Kostenvergleich der beiden Strecken umfasst, bevor eine Entscheidung über die Einrichtung eines Projekts getroffen wird.
DECISION WORKSHEET
Customization-Entwicklung und Open-Source-Adaption in durchsetzbare Entscheidungsfindung
Die folgenden Arbeitsblätter helfen Unternehmen, vage Beratung in herstellerbasierte, interne Genehmigung und projektbezogene Eingaben zu organisieren.
Business Matching
Verwenden Sie reale Prozesse, um zu überprüfen, wie viel Kernbedarf das Open-Source-System abdecken kann, nicht nur die Liste der Funktionalität und die Präsentationsseite.
Bleibt der Faktor unsicher, sollte eine Diagnose- oder Kleinvalidierung vorgenommen werden, und es ist nicht angemessen, die nicht variable feste Gesamtpreisspanne direkt einzubeziehen.
Lizenzierung und Geschäftsmodell
Beurteilung der zulässigen Grenzen der Nutzung, Änderung, Verteilung, SaaS-Dienste, Marken und vertrauensvollen Komponenten, vorbehaltlich der Überprüfung durch Juristen, je nach Bedarf.
Bleibt der Faktor unsicher, sollte eine Diagnose- oder Kleinvalidierung vorgenommen werden, und es ist nicht angemessen, die nicht variable feste Gesamtpreisspanne direkt einzubeziehen.
Änderung der Tiefe
Schnittstellen, Marken und eine kleine Anzahl von Prozesserweiterungen sind in der Regel weniger riskant; große Änderungen in Kerndatenmodellen und Grundstrukturen können die Vorteile von Open-Source-Programmen schwächen.
Bleibt der Faktor unsicher, sollte eine Diagnose- oder Kleinvalidierung vorgenommen werden, und es ist nicht angemessen, die nicht variable feste Gesamtpreisspanne direkt einzubeziehen.
Was sollte eine vergleichbare Zusammenfassung der Bewertungen enthalten?
Mindestens die Zielgeschäftsprozesse und Diskrepanzfunktionen, die Tätigkeit von Kandidaten-Open-Source-Projekten, Lizenzen und die Abhängigkeit von Komponenten, Architektur und Technologie stimmen mit der Beschreibung des aktuellen Geschäftsvolumens, der durchschnittlichen Bearbeitungszeit, der wichtigsten Anomalien, der vorhandenen Systeme, der Datenprivilegien, der Abhängigkeit von Dritten und der Zugangsfenster überein. Die gleichen Informationen werden verschiedenen Lieferanten zur Verfügung gestellt und es sind getrennte Beschreibungen von Annahmen, Ausschlüssen, Fragen der Kundenzusammenarbeit, Liefer- und Abnahmenachweise erforderlich, um zu vermeiden, dass nur der Gesamtpreis einer fehlenden Grenze verglichen wird.
So erwartet das Unternehmen, dass das Projekt 160 Arbeitsstunden pro Monat einsparen wird, aber diese Zahl sollte in die Anzahl der Aufgaben, Einmaleinsparungen, Adoptionsraten und manuelle Review-Ratios unterteilt werden. Wenn nur 40 Prozent der Nutzer die erste Periode nutzen oder wenn der neue Prozess den Review-Prozess erhöht, werden die tatsächlichen Vorteile deutlich niedriger sein als die offensichtliche Schätzung.
Vier Arten von Beweisen, die für die Befragung während der Anbieterkommunikation empfohlen werden
Der erste ist der Umfang der Nachweise: Konsistenz der Bedarfsversionen, Geschäftsprozesse, Prototypen, Schnittstellen und Ausschlüsse; der zweite ist der technische Nachweis: ob ähnliche Technologien über zugängliche Strukturen, Codemanagement, Test-, Bereitstellungs- und Fehlermanagementmethoden verfügen; der dritte ist der Personalnachweis: ob die tatsächlichen Teilnehmer, Eingabephasen, Verantwortlichkeiten und Ersatzmechanismen klar sind; und der vierte ist der Liefernachweis: wie Quellcodes, Daten, Kontonummern, Dokumente, Schulungen, Qualitätssicherung und Transport übergeben werden. Es ist normal, dass Lieferanten nicht in der Lage sind, die Vertraulichkeit der Kunden in der Ausschreibungsphase zu gewährleisten, sondern in der Lage sein sollten, ihre eigenen Methoden und die Nachweise, die im Rahmen dieses Projekts entwickelt werden können, zu erläutern.
Es wird empfohlen, Umfangsklarheit, kritisches Vertrauen, Teamkapazität, Durchsetzbarkeit und langfristige Übernahme separat zu bewerten und die Grundlage für jede Punktzahl zu erfassen.
Grundsatz der Beurteilung
Diese Seite bietet einen Entscheidungsrahmen, der kein festes Angebot oder eine Leistungsverpflichtung darstellt.
FAQ
FAQs
Die häufigsten Fragen vor der Zusammenarbeit werden im Voraus klar angegeben.
Ist ein Open-Source-System gleichbedeutend mit frei?+
Die Kosten für Codelizenzen können gleich Null sein, aber für Auswahl, Bereitstellung, Anpassung, Datenmigration, Sicherheit, Upgrade und Transport sind technische Inputs erforderlich.
Wird je mehr Open-Source-Systeme verändert werden, desto besser?+
Die Fähigkeit, Unterschiede durch Plugins, Konfigurationen und Erweiterungen zu erzielen, sollte reduziert werden, indem Eingriffe in Kerncodes reduziert werden, um die Kosten für nachfolgende Upgrades zu senken.
Kannst du es zuerst wiederholen und dann neu schreiben?+
Ja, aber von Anfang an müssen Daten, Schnittstellen und operative Grenzen geplant werden, um nicht gezielt auf die zukünftige Migration ausgerichtet zu sein.
DECISION FAQ
Schauen Sie sich alle 265 Fragen an.Gemeinsame Themen im Zusammenhang mit aktuellen Projekten
Applets, APPs, SaaS und alte Systeme
Sollten Enterprise-Systeme in einer Sekundärphase von Null oder von Open-Source-Systemen entwickelt werden?
Prozesse sind üblich, Open-Source-Produkte sind ausgereift und Lizenzen ermöglichen eine sekundäre Entwicklung. Wenn Geschäftsunterschiede, Einschränkungen der Kernarchitektur oder langfristige Upgrade-Kosten hoch sind, kann es sinnvoller sein, sich von Null zu entwickeln.
Vollständige Antwort ansehenStart von Softwareprojekten und ProgrammauswahlWie 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.
Vollständige Antwort ansehenSoftwareentwicklung und Outsourcing von ProjektenWie viel kostet die Entwicklung von Custom Software normalerweise?
Die kundenspezifische Software hat keinen einheitlichen Preis, der auf der Seitengröße basiert, und die Kosten werden hauptsächlich durch Umfang, Schnittstelle, Daten, Autorität, Leistung und Verantwortlichkeit für die Lieferung bestimmt. Das Managementsystem mit dem gleichen Namen kann ein branchenspezifisches Tool oder eine Verbindung zu Aufträgen, Inventar, Finanzen und multiorganisatorischer Autorität sein. Es wird empfohlen, die ersten geschlossenen Geschäftsschleifen und Empfangs- und Inspektionsgrenzen festzulegen und die Arbeitsbelastung für Produkt, Design, Entwicklung, Test, Bereitstellung und Wartung zu schätzen. Jeder genaue Gesamtpreis, der ohne Kenntnis der Notwendigkeit angegeben wird, wird nur als Marketingreferenz betrachtet.
Vollständige Antwort ansehenStart von Softwareprojekten und ProgrammauswahlDie Softwareanforderungen sind unvollständig, also können wir zuerst eine externe Firma haben, um sie zu bewerten?
Es ist möglich, und wenn die Nachfrage unvollständig ist, zuerst eine begrenzte Bedarfsdiagnose zu stellen, anstatt direkt einen festen Gesamtpreis zu verlangen, ein Unternehmen muss lediglich seinen Geschäftshintergrund, seine Zielgruppe, seine aktuellen Probleme, seine Zeit, um online zu gehen, und seine verfügbaren Budgets angeben.
Vollständige Antwort ansehenRELATED
Vorlage der ProjektbewertungBehalten Sie Ihr Wissen über die Dienste
Relevant
Kommerzialisierung von Open Source Systemen
Verständnis von Auswahl, privater Bereitstellung, sekundärer Entwicklung und langfristigem Upgrade
Für weitere Informationen.RelevantBusiness Software Entwicklung
Verständnis von Geschäftsprozessen bis hin zur Full Source Delivery
Für weitere Informationen.RelevantÜbermittlung ausgewählter Bewertungsinformationen
Zusammenstellung von Zielen, Status und Open-Source-Kandidatenprojekten
Für weitere Informationen.