Wie kann ich die Risiken einer Änderung der Anbietersoftware kommunizieren?

Wir haben ein großes Problem, wo ich arbeite, und der Name ist "Anpassung". Wir haben ein altes (über 10 Jahre altes) Anbietersoftwaresystem, das unsere IT- und Buchhaltungsabteilungen zuvor gerne angepasst haben. Irgendwann wurde diese Software sehr fehlerhaft. Dann wurde ich nach dem Großteil der Anpassung eingestellt.

Fast jedes Problem, das ich mit dem System festgestellt habe, ist ein direktes Ergebnis der Anpassung. Alles, was wir ändern, kann die geschäftskritische Finanzsoftware beschädigen. Die Buchhaltungsabteilung schlägt jedoch weiterhin Änderungen vor (weil wir immer Ja gesagt haben!) Und es scheint wenig Respekt für die Auswirkungen von Änderungen zu geben.

Einige Änderungen verursachen keine Probleme. Formulare können (und sollen) in der Hersteller-Software angepasst werden, wir können uns in Formularfeldern bewegen, sie entfernen, ect. Für jede harmlose Anpassung schlagen sie jedoch auch Änderungen wie gespeicherte Prozeduren und Trigger vor, um Daten in der Datenbank für die Herstelleranwendung zu bearbeiten.

Ich habe sie kürzlich (kaum) dazu gebracht, nicht mehr zu versuchen, Kunden von einem Anbieterprogramm in ein anderes zu importieren, da die Informationen vollständig inkompatibel waren. Mein Problem damit, wie das gelöst wurde, ist, dass ich fand, dass das System auf der Benutzerseite nicht funktionierte; Die Aufgabe war komplizierter als gedacht und sie gaben auf. Unabhängig davon, wie einfach die benutzerseitige Aufgabe ist, sollte die gewünschte Operation nicht ausgeführt worden sein.

Wie kann ich mitteilen, dass eine Änderung der Funktionsweise dieses Systems Risiken birgt, insbesondere wenn es um die Gültigkeit von Daten geht? Ich habe eine neue (6-monatige) Anstellung und sie ist zum Status Quo geworden, aber sie gefährdet die Gültigkeit unserer Finanzdaten und unserer Supportverträge - sobald der Support des Anbieters hört, dass "X angepasst wurde", gibt dies keinen Grund mehr um uns zu unterstützen oder uns zu sagen, dass es unsere Schuld ist.

Das Risiko und der Nutzen von Customizing-Systemen besteht darin, einen Wettbewerbsvorteil zu schaffen, der es Ihrem Unternehmen ermöglicht, etwas anderes als die anderen Unternehmen in Ihrem Umfeld anzubieten.

Die größeren Organisationen, mit denen ich zusammengearbeitet habe, erzielen einen Wettbewerbsvorteil durch Anpassung und in dieser Denkweise lassen sie die Dinge effizienter erledigen, mehr Funktionen bereitstellen oder mehr Geld verdienen.

Die Tatsache, dass ich in diesen Situationen kommuniziere, ist, dass es ein Kompromiss ist. Indem die Organisation diese Änderungen an einem System vornimmt, entwickelt sie eine eigene interne Wissensbasis / Expertise für ihre Systeme, auf die sie nicht ohne weiteres verzichten können. Diese interne Wissensbasis muss besser gepflegt und organisiert werden, damit diese Änderungen nachverfolgt und verwaltet werden können. Dies bedeutet auch, dass Herstellersupportverträge und andere Aspekte, die von den IT-Ressourcen des Unternehmens für diesen Prozess verwendet werden, ungültig werden.

Das größte Risiko, über das ich spreche, besteht in Versions-Upgrades von Anbietersoftware, wenn ein Unternehmen diese Datenverwaltungsphilosophie anwendet. Dies ist eines der wahrscheinlichsten Risiken, bei denen etwas kaputt geht. Das Unternehmen muss die Kompromisse verstehen, die gemacht werden, und jeder muss mit dem Prozess einverstanden sein, den es braucht, um sie zu unterstützen.

Für Ihre Kultur können Sie eine Analogie oder Philosophie einführen, aber Sie benötigen jemanden, der für das Geschäft verantwortlich ist, um zu erkennen, dass er eine Umgebung schafft, die noch mehr von internen Geschäftsspezialisten abhängig ist, die Änderungen an diesen Systemen vornehmen.

Für die Auto-Analogie ist es nicht der Mechaniker, der wissen muss, welche Änderungen an einem Auto vorgenommen werden, sondern der Besitzer, der verstehen muss, dass es spezielle Mechaniker, mehr Geld oder den Verlust dieses Service für einen bestimmten Zeitraum in Anspruch nehmen kann. Die Aufklärung des Eigentümers ist der Schlüssel zu diesem Gespräch.

Mit Bürobewohnern kommunizieren? Ich würde mit Analogien gehen.

Sagen Sie ihnen, dass all diese Änderungen Ihre typische viertürige inländische Limousine in ein exotisches ausländisches Auto verwandeln. Jedes Mal, wenn Sie es in die Mechanikwerkstatt bringen, von der Einstellung über das zerbrochene Licht bis zur Überholung des Getriebes, wird es teurer. "Wir haben die Teile nicht, nur der Händler mit Spezialkenntnissen kann das anfassen, wir haben es versucht, aber das Handbuch ist in deutscher Sprache."

Sie sind der Mechaniker, der dafür verantwortlich ist, dass es läuft. Die Datenbank ist der Motor. Das ganze System ist das Auto. Die Buchhalter fahren mit dem Auto herum. Der süße kleine Hase, den die Buchhalter aus der Fassung gebracht haben, ist ein Umlautcharakter im Nachnamen eines neuen Kunden. Der Lichtmast, um den sie ihr Auto gewickelt haben, ist der kritische Fehler, der eingeführt wurde, als sie eine Discokugel in das Auto einbauen wollten.

Andere haben einige gute Beispiele für die Verwendung von Analogien und anderen Sprachen geliefert, um Ihre Hauptfrage zu beantworten: "Wie kann ich mitteilen, dass eine Änderung der Funktionsweise dieses Systems Risiken birgt, insbesondere wenn es um die Gültigkeit von Daten geht?"

Ich bin mir jedoch nicht sicher, ob eine Analogie in dieser Situation hilfreich sein wird, da Sie klargestellt haben, wie die Aufgabenstellung zu Ihnen führt. Es scheint, dass die Leute nicht wirklich falsch verstehen, wonach sie fragen, aber eher, dass es ihnen egal ist. Ich war dort - wir waren wahrscheinlich alle dort - und in diesen Situationen bemühe ich mich eher , die Themen klar zu formulieren , als sie in Begriffen auszudrücken, die eher lehren als warnen sollen .

Konzentrieren Sie sich auf das, was Sie tun können. Dies ändert nicht im Alleingang die Meinung aller, die nach Anpassungen fragen, die die Datenintegrität und Supportverträge von Anbietern gefährden, sondern spricht direkt mit Ihrem CTO (und damit auch dem CFO) und seinem Wesen sehr klar in Bezug auf die anstehenden Fragen.

Speziell:

• Bitten Sie Ihren CTO oder CFO (oder wen auch immer), den Servicevertrag mit dem Anbieter einzusehen, da Sie (und ich würde sagen, diese Worte) aufgefordert werden, Aufgaben auszuführen, die möglicherweise gegen die Vereinbarung verstoßen, und die Sie ausführen möchten in der Lage sein, dies in Ihrem Durchführbarkeitsbericht zu verdeutlichen. Sie geben es Ihnen vielleicht nicht, aber wenn Sie diese Worte sagen, haben die Leute in diesen Positionen oft besser verstanden, dass Sie es ernst meinen, und die Situation ist potenziell ernst.

• Wenn Sie tun , um eine Kopie der Vereinbarung erhalten, dann , wenn Sie Ihre Aufgabe Durchführbarkeitsbericht schreiben, zitiere aus es direkt , wenn es eine klare Verletzung ist.

• Wenn Sie nicht eine Kopie der Vereinbarung bekommen, dann reservieren Sie ganz klar , wie sich die Änderung des Unternehmens in einer schlechten Position in Bezug auf die Beziehung zu den Lieferanten setzen könnte.

• Wenn Ihr Anliegen aufgrund der Vereinbarung mit dem Anbieter nicht problematisch ist, aber aufgrund der Kaskadeneffekte der Änderung "einfach" problematisch ist, skizzieren Sie, was dies bedeutet: Wenn es so chaotisch ist, wie Sie es sagen, haben Sie wahrscheinlich nur ein oder zwei Aufzählungszeichen, bevor Sie die Zeile "und es wird wie ein Kartenhaus stürzen" verwenden können.

Kurz gesagt, tun Sie, was Sie können, um das Problem und seine Auswirkungen noch ein oder zwei Schritte weiter klar und deutlich herauszustellen. Dass Sie die Möglichkeit haben, den Entscheidungsträgern bereits einen Machbarkeitsbericht vorzulegen, ist eine gute Sache; Sie haben nicht die Struktur oder Managementunterstützung (oder das Ethos), um zu sagen: "Ich muss das unterschreiben. Sie verstehen, dass dies eine schlechte Sache ist, und ich empfehle es nicht und werde nicht für die Auswirkungen verantwortlich sein schlechte Entscheidung "(wie wenn Sie ein Verkäufer und ein Kunde wären), aber Sie können immer noch eine Menge Dinge auf Papier bringen, die zeigen, dass Sie überlegen, was im besten Interesse des Unternehmens und seiner Vermögenswerte ist.

Wenn Sie aufgefordert werden, gespeicherte Prozeduren und Trigger zu implementieren, liegt ein schwerwiegendes Geschäftsprozessproblem vor.

Ihre größte Herausforderung besteht darin, die Benutzer hier dazu zu bringen, ihre Meinung zu ändern. Sie müssen Ihnen das Problem oder die Anforderung mitteilen. Zum Beispiel brauchen wir Daten, die von hier nach hier verschoben werden .

Sie sollten es sein, die die Lösung mit dem geringsten Risiko / dem größten Gewinn implementiert, und Sie können dies auf eine Weise tun, die dazu beiträgt, zukünftige Entwicklungsprobleme zu vermeiden.

Eine gewisse Kontrolle in Form von Benutzer-Abmeldungen oder -Anforderungen und anschließendem Abmelden der gelieferten Entwicklung wird ebenfalls hilfreich sein. Wenn der Benutzer Verantwortung / Verantwortlichkeit für das, was er verlangt, übernehmen muss, kann er etwas mehr darüber nachdenken.

Sie scheinen zu implizieren, dass Sie die Wahl zwischen einer riskanten Implementierung einer Geschäftsanforderung oder gar keiner haben. Es ist selten so schwarz und weiß. Es fällt mir schwer zu glauben, dass Buchhalter direkt nach gespeicherten Prozeduren fragen, aber wenn dies der Fall ist, müssen Sie ihnen mitteilen, was sie bedeuten, anstatt was sie verlangen. Finden Sie heraus, was die geschäftlichen Anforderungen sind, und finden Sie heraus, wie Sie sie am wenigsten riskieren.

Wenn Ihr Anbieter nicht die erforderlichen Hooks bereitstellt, um die von Ihren Benutzern gewünschten Anforderungen sicher zu implementieren, liegt das Problem beim Anbieter und nicht bei Ihren Benutzern.

Sie entwickeln im Grunde Software und benötigen daher eine Entwicklungsmethode. Wie werden Änderungen dokumentiert? Geprüft? Zur Qualitätssicherung eingesetzt? Für die Produktion eingesetzt? usw. Ich denke, wenn Sie anfangen, eine Methodik und die damit verbundenen Kosten zu entwickeln, werden sie anfangen zu verstehen. Vielleicht sind die Kosten gerechtfertigt und Sie müssen nur ein Verfahren implementieren, damit sich das Auto nie um einen Lichtmast wickelt.