--- schema_version: "1" id: f59eca75e9c4bdc2610d59f61eb67a177569b7b7857b1ed5ebaae8611752ab34 title: Kostensteuerung und Entscheidungsfindung – Muster collection: architect version: current locale: de-de portal_url: https://docs.salesforce.com/architect/current/de-de/well-architected/guides/resource-and-cost-optimization-governance-patterns.md canonical_url: https://architect.salesforce.com/docs/architect/de-de/well-architected/guide/resource-and-cost-optimization-governance-patterns.html source_site: architect.salesforce.com content_type: documentation content_hash: d8b481c679bca12fce95a1045b7bfa244f3d4c5eac09ce0eb2d9e83333fa698f products: - Gut strukturiertes Framework - Architect Site Content Repo --- # Kostensteuerung und Entscheidungsfindung – Muster Erfahren Sie mehr über die gut durchdachte [Ressourcen- und Kostenoptimierung](/docs/architect/de-de/well-architected/guide/resource-and-cost-optimization.html) → [Kostenüberwachung und -verwaltung](/docs/architect/de-de/well-architected/guide/resource-and-cost-optimization.html#cost-monitoring-and-governance) ## Kostenüberwachung und Sichtbarkeit **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | **Setup** → Unternehmenseinstellungen → Systemübersicht
**Berichte und Dashboards** → Ordner für die Kostennutzung | ✅ **Muster**: Erstellen eines Dashboards für Führungskräfte mit einer jährlichen Salesforce-Investition von 2,1 Mio. EUR, verteilt auf 1.200 Lizenzen (wöchentlich 68 % aktiv), 450 GB Speicher (72 % Kapazität) und 15 Sandbox-Instanzen (11 aktiv genutzt)
✅ Dashboard zeigt Optimierungs-Opportunities im Wert von 400 000 EUR in inaktiven Lizenzen und nicht verwendeten Sandbox-Instanzen durch betriebliche Kennzahlen an | | **Berichte und Dashboards** → Dashboard für Investitionen
**Setup** → Unternehmensinformationen | ✅ **Muster**: Investitions-Dashboards zeigen Ausgaben nach Geschäftseinheit oder Kostenstelle, Sandbox- und Umweltkosten nach Entwicklungsteam, Produktzusatzkosten mit Auslastungskennzahlen
✅ Projektausgaben auf der Grundlage aktueller Wachstumstrends, die Diskussionen über Budgetverantwortung und Zuteilung ermöglichen | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | **Buchhaltungssystem** → Nur Rechnungsdatensätze | ⚠️ **Antimuster**: Das Finanzteam hat eine Rechnungssichtbarkeit, die die Gesamtausgaben anzeigt, aber keine operativen Kennzahlen, die Nutzungsmuster oder Optimierungsmöglichkeiten aufzeigen
⚠️ Kann inaktive Lizenzen, nicht verwendete Sandbox-Instanzen oder Kapazitätsverschwendung ohne operative Dashboards nicht identifizieren | ## Budgetsteuerungen und -benachrichtigungen **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | **Berichte und Dashboards** → Warnungen zum Lizenzbudget
**Setup** → Lizenzzuteilungen | ✅ **Muster**: In Lizenzbudgets werden Zuteilungsziele nach Abteilung mit Warnungen bei Kapazitätsnähe festgelegt
✅ Verhindern, dass unkontrollierte Bereitstellungen Budgetüberschreitungen verursachen, die nur zum Verlängerungszeitpunkt durch Proactive Monitoring erkannt werden | | **Setup** → Speicherbelegung → Benachrichtigungsregeln
**Flow** → Automatisierung von Speicherwarnungen | ✅ **Muster**: Automatische Benachrichtigungsauslöser bei 70 % Speicherauslastung mit 4-monatiger Vorlaufzeit für die Implementierung der Archivierungsstrategie vor Erreichen der Obergrenzen
✅ Verhindert das Löschen von Notfalldaten oder teure Überziehungsgebühren durch proaktive Benachrichtigung mit angemessener Antwortzeit | | **Systemübersicht** → API-Nutzungswarnungen
**Ereignisüberwachung** → API-Schwellenwertwarnungen | ✅ **Muster**: API-Budgets verfolgen den Verbrauch anhand von Obergrenzen mit Warnungen bei Beispielauslastungsschwellenwerten wie 70 % und 85 %
✅ Aktivieren der proaktiven Optimierung anstelle von reaktiven Notfallreaktionen, nachdem Obergrenzen zu Integrationsfehlern oder Benutzerunterbrechungen führen | | **Setup** → Sandbox-Verwaltung → Budgetsteuerungen
**Flow** → Genehmigung der Sandbox-Anforderung | ✅ **Muster**: Sandbox-Budgets steuern die Verbreitung von Umgebungen durch Zuteilungsobergrenzen und Genehmigungsprozesse für zusätzliche Umgebungen
✅ Verhindern, dass Teams unbegrenzte temporäre Umgebungen erstellen, die ohne Begründung in einen dauerhaften Status übergehen | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | **Keine Budgetkontrollen** → Unkontrollierte Ausgaben | ⚠️ **Antimuster**: Keine Lizenzbudgets oder Genehmigungsworkflows, die eine unbegrenzte Bereitstellung über Abteilungen hinweg ermöglichen, ohne dass Ausgabenmuster sichtbar sind
⚠️ Budgetüberschreitungen bei Verlängerung festgestellt, wenn die Gesamtausgaben die geplanten Investitionen aufgrund unkontrollierten Wachstums um 30-40 % überschreiten | | **Keine Speicherbenachrichtigungen** → Reaktive Überschüsse | ⚠️ **Antimuster**: Während der Verlängerungsverhandlungen festgestellte Speicherüberschreitung, die sofortigen Kauf zum Premiumpreis erfordert, ohne Zeit für die Archivierungsauswertung
⚠️ Fehlende Vorwarnung, die die Archivierungsimplementierung ermöglichen würde, bevor Überschüsse auftreten, was zu 2-3x höheren Kosten führt | ## Kostenzuteilung und -rückbuchung **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | **Berichte und Dashboards** → Showback-Bericht
**Berichte** → Kosten nach Geschäftseinheit | ✅ **Muster**: Vierteljährlicher Showback-Bericht zeigt, dass Sales Cloud 45 % der Lizenzinvestitionen verbraucht, Service Cloud 30 % und Operations 25 %
✅ Ermöglicht Führungskräftediskussionen darüber, ob die Investitionsverteilung mit Geschäftswertprioritäten und strategischen Fokusbereichen übereinstimmt | | **Finanzsystem** → Zuteilung der Kostenerstattung
**Berichte** → Zuteilung der Abteilungskosten | ✅ **Muster**: Zuteilungsregeln verteilen die Kosten angemessen: Lizenzkosten nach Benutzerabteilungszuweisung, Sandbox-Kosten nach Inhaber des Entwicklungsteams
✅ Integrationskosten, die nach Geschäftsprozessen unter Inanspruchnahme von Integrationsservices zugeteilt werden, Entwicklungskosten durch Anfordern der Projektfinanzierungsquelle | | **Berichte und Dashboards** → Sandbox-Kostenbericht
**Setup** → Sandbox-Nutzung nach Team | ✅ **Muster**: Sandbox- und Umgebungskosten, die vom eigenen Entwicklungsteam zugeteilt werden und die eine direkte Rechenschaftspflicht für die Umgebungsverwaltung schaffen
✅ Teams sehen ihre Sandbox-Investitionen, die fundierte Entscheidungen in Bezug auf Umweltanforderungen und Lebenszyklusverwaltung ermöglichen | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | **Nur IT-Budget** → Keine Sichtbarkeit der Geschäftseinheit | ⚠️ **Antimuster**: Alle Salesforce-Kosten, die dem IT-Budget ohne Sichtbarkeit der Geschäftseinheit zugeordnet sind
⚠️ Geschäftsbeteiligte behandeln die Plattform als "kostenlos" und stellen Anfragen ohne Diskussionen über Kostenbewusstsein oder Investitionspriorität | | **Keine Nutzungsattribution** → Kann nicht optimiert werden | ⚠️ **Antimuster**: Gesamtausgaben sichtbar, aber keine Zuordnung zu Geschäftseinheiten, Projekten oder Teams, was Optimierungsentscheidungen unmöglich macht
⚠️ Kann nicht identifizieren, welche Investitionen einen Wert liefern und welches Budget ohne anteilige Renditen verbraucht wird | ## FinOps und kostenbewusste Kultur **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | **Zusammenarbeit** → FinOps Team
**Besprechungen** → Monatliche Kostenüberprüfung | ✅ **Muster**: Die funktionsübergreifende Zusammenarbeit zwischen Finanz-, Architektur- und Geschäftsbeteiligten stellt sicher, dass bei Kostenentscheidungen der Geschäftswert und die Ausgabenauswirkung berücksichtigt werden
✅ FinOps bringt Finanzwissen in Architekturdiskussionen und technisches Verständnis in die Budgetplanung ein, um ausgewogene Entscheidungen zu treffen | | **Kalender** → Optimierungsüberprüfungen
**Prozess** → Regulärer Rhythmus | ✅ **Muster**: Kontinuierlicher Optimierungsrhythmus mit monatlicher Anomalieüberprüfung, vierteljährlicher Auslastungsüberprüfung und jährlicher umfassender TCO-Bewertung
✅ Regelmäßige Überprüfungszyklen verhindern Kostenabweichungen und validieren, dass das Ausgabenwachstum dem Wachstum des Geschäftswerts entspricht, durch systematische Analysen | | **Tools** → Lizenzkostenrechner
**Architektur** → TCO-Modelle | ✅ **Muster**: FinOps-Team stellt Architekten einen Lizenzkostenrechner zur Verfügung, der die Auswirkungen verschiedener Lizenztypauswahlen auf die TCO anzeigt
✅ Ermöglicht kostenbewusste Designentscheidungen während der Architekturphase, statt Kosten nach der Bereitstellung zu ermitteln, wenn Änderungen teuer sind | | **Schulung** → Kostenbewusstseinsprogramm
**Dokumentation** → Richtlinien zur Kostenauswirkung | ✅ **Muster**: Schulung zum Kostenbewusstsein stellt sicher, dass Teams verstehen, wie sich architektonische Entscheidungen auf die Gesamtbetriebskosten auswirken
✅ Architekten entwerfen bessere Lösungen für die Balance zwischen Fähigkeit und Investition; Entwickler schreiben eine effizientere Automatisierung unter Berücksichtigung von Obergrenzen und API-Verbrauch | | **Automatisierung** → Kostenüberwachungsskripts
**Dashboards** → Automatisch generierte Berichte | ✅ **Muster**: Automatisierte Überwachung von Auslastung, Optimierungsmöglichkeiten und Ausgabenberichten reduziert den manuellen Aufwand
✅ Skalen mit organisatorischer Komplexität ohne lineares Wachstum der Mitarbeiterzahl, wodurch das Kostenbewusstsein über die wachsende Plattform hinweg gewährleistet wird | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | **Nur jährlich** → Keine Feedbackschleife | ⚠️ **Antimuster**: Kostensichtbarkeit beschränkt auf Diskussionen über die jährliche Verlängerung ohne Feedbackschleife
⚠️ Architekturteams können Ausgabenmuster in der Entwurfsphase, in der Änderungen am kostengünstigsten sind, nicht nachvollziehen oder optimieren | | **Isolierte Entscheidungen** → Keine funktionsübergreifende Eingabe | ⚠️ **Antimuster**: Architekturentscheidungen ohne Finanz-Input, Budgetentscheidungen ohne technisches Verständnis
⚠️ Ergebnisse von Lösungen, die das Budget überschreiten, ohne geschäftliche Begründung oder Budgetkürzungen, die Funktionen beseitigen, die einen wichtigen Wert bieten | | **Keine Kosten Bildung** → Uninformierte Entscheidungen | ⚠️ **Antimuster**: Teams treffen Architekturentscheidungen, ohne die Auswirkungen auf die Kosten zu verstehen, da keine Schulung oder Sichtbarkeit vorhanden ist
⚠️ Ansammeln von Abfällen durch Tausende von Mikroentscheidungen, die einzeln geringfügig erscheinen, sich jedoch zu erheblichen Ausgaben addieren | ## Integration von Architekturüberprüfungskosten **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | **Dokumentation** → Architekturentscheidungsdatensatz
**Prozess** → ADR-Vorlage | ✅ **Muster**: Architekturentscheidungsdatensatz für Kundenportal enthält Lizenzanalysen: 10.000 externe Benutzer mit Kunden-Community Plus-Lizenzen (6 $ pro Benutzer monatlich = 720 $ jährlich)
✅ Vergleich mit benutzerdefinierter Webanwendung mit API-Integration (250 000 EUR anfänglich + 50 000 EUR jährliche Wartung); empfohlene benutzerdefinierte Anwendung mit 2-jähriger Amortisation | | **Governance** → Überprüfungsgremium für Architektur
**Prozess** → Kostenüberprüfungskriterien | ✅ **Muster**: Architekturüberprüfungsgremium enthält Kostenperspektive sowie funktionale und nicht funktionale Anforderungen, die zu besser abgestimmten Investitionsentscheidungen führen
✅ Kosten sind ein Beitrag zu Architekturentscheidungen, die sicherstellen, dass Organisationen angemessen in wichtige Funktionen investieren und gleichzeitig Abfall vermeiden | | **Dokumentation** → Abschnitt 'AS-Kosten'
**Vorlagen** → TCO-Projektion | ✅ **Muster**: Aufnehmen der Kostenauswirkungsbewertung in Architekturentscheidungsdatensätze, die wichtige Designentscheidungen dokumentieren
✅ Anforderung einer TCO-Projektion für Lösungen, die definierte Investitionsschwellenwerte überschreiten (100 000 EUR oder Organisationsrichtlinie) mit dokumentierten Annahmen | | **Prozess** → Lizenzauswirkungsüberprüfung
**Architektur** → Premium-Funktionsanalyse | ✅ **Muster**: Bewerten der Lizenzauswirkungen während des Lösungsdesigns, um zu bestimmen, ob für das Design Premium-Lizenzen oder Add-Ons erforderlich sind
✅ Bewerten Sie die Auswirkungen der Integrationskosten, bevor Sie sich auf Muster festlegen, die sich auf den API-Verbrauch oder die Middleware-Lizenzanforderungen auswirken | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | **Keine Kostenbetrachtung** → Notfall-Neugestaltung | ⚠️ **Antimuster**: Architektur, die ohne Kostenüberlegung konzipiert wurde und bei der Implementierungsplanung feststellt, dass ein vorgeschlagener Ansatz eine Investition von 720 Tsd. US-Dollar pro Jahr erfordert
⚠️ Verursacht eine Notfall-Neugestaltung unter Zeitdruck mit schlechteren Ergebnissen als bei der kostenbewussten Gestaltung von Anfang an | | **Nach-Design-Kostenerkennung** → Verschwendeter Aufwand | ⚠️ **Antimuster**: Architektur abgeschlossen, bevor Kostenanalyse das Budget um das Dreifache überschreitet
⚠️ Verschwendeter Designaufwand und verzögerte Bereitstellung bei Teamumgestaltungen innerhalb der Budgetbeschränkungen, die vom Projektstart bekannt waren | ## Build vs Buy Decision Framework (Framework für Build vs. Kaufentscheidung) **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | **AppExchange** → Lösungsbewertung
**Analyse** → TCO-Vergleich | ✅ **Muster**: Auswertung der Lösung zur Dokumentgenerierung: AppExchange-Option für 15 EUR pro Benutzer monatlich (180.000 EUR pro Jahr für 100 Benutzer) im Vergleich zur benutzerdefinierten Entwicklung bei der ersten Erstellung von 800.000 EUR + Wartung von 150.000 EUR pro Jahr
✅ AppExchange bricht auch in 5 Jahren ab, da die Bereitstellung schneller und das Risiko für die Rohstofffunktion geringer ist | | **AppExchange** → Strategisch vs. Rohstoff
**Architektur** → Funktionsklassifizierung | ✅ **Muster**: Bei AppExchange erworbene Warenfunktionen (Dokumenterstellung, elektronische Signatur, Adressanreicherung), bei denen Lösungen ausgereift sind, mit starken Überprüfungen
✅ Eigener Preisalgorithmus, der benutzerdefinierte Wettbewerbsvorteile bietet und die vollständige Kontrolle über die Roadmap und die Differenzierung bietet | | **Tabellenblatt** → 3-5 Jahre TCO-Modell
**Analyse** → Kostenprognose | ✅ **Muster**: Erstellen von TCO-Modellen, die 3-5 Jahre Gesamtkosten projizieren und ein vollständiges Investitionsbild über die anfänglichen Ausgaben hinaus zeigen
✅ AppExchange enthält ein konsolidiertes Jahresabonnement, aber eine Wartung. Die benutzerdefinierte Anwendung erfordert eine einmalige Entwicklung plus 15-20 % jährliche Wartung | | **Integrationsanalyse** → Benutzerdefiniert vs. Plattform
**TCO** → Integrationsvergleich | ✅ **Muster**: Benutzerdefinierte Integrationsentwicklung: $150K Initial Build + $30K Annual Maintenance + Team-Lernkurve im Vergleich zur MuleSoft-Lizenz: Jährliche Integrationszustellung in Höhe von 750.000 EUR + schneller
✅ MuleSoft bietet wiederverwendbare Muster über alle Integrationen hinweg und reduziert so die Integrationskosten bei wachsendem Portfolio | | **Dokumentation** → Build vs Buy ADR
**Prozess** → Evaluierungs-Framework | ✅ **Muster**: Architekturentscheidung Datensatzdokumente zur Erstellung und zum Kauf mit Bewertungsmatrix zur Gewichtung von strategischem Wert, TCO, Zeitachse, Funktionen und Beendigungskosten
✅ Erstellt einen Überprüfungspfad für zukünftige Neubewertungen, wenn sich Anforderungen ändern oder sich die Anbieterlandschaft ändert | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | **Immer erstellen** → Verschwendete Entwicklung | ⚠️ **Antimuster**: Erstellen einer benutzerdefinierten Dokumenterstellungslösung, da "Entwickler verfügbar sind" ohne Modellierung der 5-Jahres-TCO
⚠️ AppExchange bietet einen besseren Wert für die Rohstofffunktionalität; bei der benutzerdefinierten Entwicklung wird Kapazität für nicht differenzierte Funktionen verschwendet | | **Immer kaufen** → Fehlende Unterscheidung | ⚠️ **Antimuster**: Erwerb aller Funktionen von AppExchange, einschließlich strategischer Differenzierer, da "schneller bereitzustellen"
⚠️ Mitbewerber, die dieselben AppExchange-Lösungen verwenden, profitieren von denselben Funktionen und eliminieren so Wettbewerbsvorteile durch Plattforminvestitionen | | **Einzelbesprechungsentscheidung** → Keine Analyse | ⚠️ **Antimuster**: In einer einzelnen Besprechung getroffene Entscheidung zwischen Build und Kauf basierend auf dem anfänglichen Kostenvergleich ohne systematische Auswertung oder Dokumentation
⚠️ Fehlende strategische Wertbewertung, TCO-Projektion, Zeitachsenanforderungen, Fähigkeitsbewertung und Ausstiegskostenanalyse | | **Unvollständiges Kostenmodell** → Verborgene Kosten | ⚠️ **Antimuster**: Erstellen einer benutzerdefinierten Integration, da "wir bereits Entwickler haben" ohne Modellierung der Wartungslast von 5 Jahren
⚠️ Wartung verbraucht in der Regel 15-20 % der anfänglichen Entwicklungskosten pro Jahr plus Plattformkompatibilitätsaufwand, der in der ursprünglichen Entscheidung nicht sichtbar ist | ## Systematische Auswertung des Entscheidungs-Frameworks **Muster** | Wohin schauen | Wie gut aussieht | | --- | --- | | **Prozess** → Strategische Wertschätzung
**Analyse** → Differenzierungsmatrix | ✅ **Muster**: Systematisieren von Build- und Kaufentscheidungen durch konsistente Auswertung, um Ad-hoc-Entscheidungen auf der Grundlage unvollständiger Analysen zu verhindern
✅ Strategischer Wert zuerst bewerten: Zentrale Wettbewerbsdifferenzierer rechtfertigen benutzerdefinierte Investitionen; Rohstofffunktionen begünstigen den Kauf bewährter Lösungen zu niedrigeren Gesamtkosten | | **AppExchange** → Überprüfung der Lösungsreife
**Analyse** → Anbieterstabilitätsprüfung | ✅ **Muster**: Bewerten verfügbarer AppExchange-Optionen zur Überprüfung der Lösungsreife, Kundenbewertungen, ISV-Stabilität, Funktionsausrichtung und Preismodellen
✅ Unausgereifte Lösungen mit wenigen Kunden bergen ein höheres Risiko; Priorisieren bewährter Lösungen mit strengen Überprüfungen und stabilen Lieferantenfinanzen | | **Tabellenblatt** → Sensitivitätsanalyse
**TCO** → Annahmedokumentation | ✅ **Muster**: Modell 3-5 Jahre TCO für tragfähige Optionen einschließlich aller Kostenkategorien: Lizenzen/Abonnements, Implementierungsaufwand, Wartungsaufwand, Erweiterungsentwicklung, Plattformkompatibilität
✅ Verwenden Sie Tabellenblätter, die eine Sensitivitätsanalyse für Annahmen ermöglichen, die zeigt, wie sich das Ergebnis ändert, wenn Wachstumsraten oder Auslastung von Prognosen abweichen | | **Zeitachse** → Marktzeitanalyse
**Strategie** → Bewertung der Zeit bis zum Wert | ✅ **Muster**: Bewerten der Zeitachsenanforderungen, die zeigen, dass die benutzerdefinierte Entwicklung je nach Komplexität Monate bis Jahre erfordert, während AppExchange in Wochen bereitgestellt wird
✅ Marktzeiteinteilung kann trotz höherer langfristiger Kosten die Kaufentscheidung beeinflussen, wenn Wettbewerbsdruck oder Geschäftschancen sofortige Möglichkeiten erfordern | | **Analyse** → Exit Cost Evaluation (Ausstiegskostenauswertung)
**Risiko** → Anbieterbindungsbewertung | ✅ **Muster**: Bewerten Sie die Ausstiegskosten und das Risiko der Anbieterkonzentration und fragen Sie, wie schwierig der Wechsel ist, wenn sich die ausgewählte Option als unzureichend erweist.
✅ Berücksichtigen Sie das Risiko der Übernahme oder Einstellung von Lieferanten und die Übertragbarkeit von Lösungen, wenn sich die Anforderungen ändern, und bevorzugen Sie niedrigere Austrittskosten für strategische Flexibilität | | **Fähigkeit** → Ehrliche Bewertung
**Team** → Wartungskapazitätsüberprüfung | ✅ **Muster**: Überlegen Sie, ob die Organisationsfähigkeit ehrlich ist und ob benutzerdefinierte Lösungen langfristig gewartet werden können.
✅ Benutzerdefinierte Lösungen erfordern ständige interne Fachkenntnisse für Wartung und Weiterentwicklung. Organisationen ohne diese Funktion sollten trotz potenziell höherer Kosten kaufen | **Antimuster** | Wohin schauen | Wie schlecht sieht | | --- | --- | | **Kein Framework** → Inkonsistente Entscheidungen | ⚠️ **Antimuster**: Build vs Buy Decisions variieren je nach Projektteamvoreinstellungen ohne einheitliche Bewertungskriterien
⚠️ Einige Teams bauen immer, andere kaufen immer, was zu architektonischer Inkonsistenz und suboptimalen Gesamtinvestitionen auf der Plattform führt | | **Alles erstellen** → Undifferenzierter Aufwand | ⚠️ **Antimuster**: Alles benutzerdefinierte erstellen, weil "wir die Kontrolle haben wollen" ohne zwischen Rohstofffunktionen und strategischen Unterscheidungen zu unterscheiden
⚠️ Verschwendet Entwicklungskapazität für nicht differenzierte Funktionen, die ausgereifte AppExchange Lösungen zu niedrigeren Gesamtkosten bieten | | **Nur Anfangskosten** → unvollständige Analyse | ⚠️ **Antimuster**: Entscheidung, die ausschließlich auf dem ursprünglichen Kostenvergleich basiert: "AppExchange kostet 20.000 EUR, benutzerdefinierter Build 150.000 EUR, also erstellen wir"
⚠️ Fehlende Gesamtbetriebskosten von 3 bis 5 Jahren für die Anzeige der benutzerdefinierten Lösung – anfängliche Kosten von 150.000 $ + jährliche Wartung von 30.000 $, während AppExchange die gesamte Wartung im Abonnement beinhaltet | | **Optimistische Funktionen** → Fehlgeschlagene Wartung | ⚠️ **Antimuster**: Bei Auswahl einer benutzerdefinierten Entwicklung wird davon ausgegangen, dass das Team die Lösung trotz fehlender aktueller Kapazitäten oder Fachkenntnisse beibehalten kann.
⚠️ Technische Schulden häufen sich an, wenn die Wartung zurückgestellt wird; die Lösung wird schließlich nicht mehr wartbar und erfordert einen teuren Austausch |