Come posso comunicare i rischi di alterare il software del fornitore?

Il rischio / la ricompensa dei sistemi di personalizzazione è di fornire un vantaggio competitivo che consente alla tua azienda di offrire qualcosa di diverso rispetto alle altre aziende nel tuo spazio.

Le organizzazioni più grandi con cui ho lavorato traggono un vantaggio competitivo dalla personalizzazione e in quella mentalità, le fanno fare le cose in modo più efficiente, forniscono più funzionalità o fanno più soldi.

Il fatto che io comunichi in queste situazioni è che si tratta di un compromesso. Nell'apportare queste modifiche a un sistema, l'organizzazione sta sviluppando la propria base di conoscenze interne / competenze dei propri sistemi che non saranno in grado di fare facilmente. Questa base di conoscenze interne deve essere mantenuta e organizzata in modo migliore, in modo che questi cambiamenti possano essere monitorati e gestiti. Significa anche che potrebbe invalidare i contratti di supporto del fornitore e altri aspetti che le risorse IT che l'azienda utilizza per questo processo.

Il rischio maggiore di cui parlo è l'aggiornamento della versione al software del fornitore quando una società adotta questa filosofia di gestione dei dati. Questo è uno dei rischi più probabili in cui qualcosa si spezzerà. L'azienda deve capire i compromessi che vengono fatti e tutti devono essere coinvolti nel processo necessario per supportarli.

Per la tua cultura, puoi introdurre un'analogia o una filosofia, ma hai bisogno di qualcuno che è responsabile per il business per rendersi conto che stanno creando un ambiente che ha anche ulteriori dipendenze da specialisti aziendali interni che apportano modifiche a questi sistemi.

Per l'analogia dell'auto, non è il meccanico che ha bisogno di sapere quali modifiche vengono apportate a un'auto, è il proprietario che deve capire che potrebbe essere necessaria una meccanica speciale, più denaro o perdita di quel servizio per un periodo di tempo . Educare il proprietario è la chiave per questa conversazione.

Comunicare agli abitanti dell'ufficio? Andrei con le analogie.

Dì loro che tutti questi cambiamenti stanno trasformando la tipica berlina domestica a 4 porte in un'auto straniera esotica. Ogni volta che lo porti nel negozio meccanico, dalla messa a punto, alla luce schiacciata, alla revisione della trasmissione, sarà più costoso. "Non abbiamo le parti, solo il rivenditore con una conoscenza speciale può toccarlo, abbiamo provato, ma il manuale è in tedesco".

Sei il meccanico incaricato di tenerlo in esecuzione. Il database è il motore. L'intero sistema è l'auto. I ragionieri guidano la macchina in giro. Il simpatico coniglietto che i contabili hanno dovuto perdere è un personaggio di umlaut nel cognome di un nuovo cliente. Il palo della luce che hanno avvolto la loro auto è il bug critico che è stato introdotto quando volevano aggiungere una palla da discoteca all'interno dell'auto.

Altri hanno fornito alcuni buoni esempi di utilizzo di analogie e altri linguaggi per rispondere alla domanda principale, ovvero "Come posso comunicare che cambiare il modo in cui funziona questo sistema comporta dei rischi, in particolare quando è in gioco la validità dei dati?"

Ma sulla base del tuo commento chiarificatore su come l'incarico ti arriva, non sono sicuro che nessuna analogia ti possa aiutare nella situazione - non sembra proprio che le persone fraintendano ciò che stanno chiedendo per, ma piuttosto che a loro non importa Sono stato lì - probabilmente ci siamo stati tutti - e in queste situazioni tendo a fare uno sforzo maggiore per essere perfettamente chiaro riguardo ai problemi, piuttosto che metterli a confronto in termini per insegnare piuttosto che warn .

Concentrati su ciò che puoi fare, che non cambia da solo le menti di tutti coloro che chiedono personalizzazioni che mettono a rischio l'integrità dei dati e i contratti di supporto dei fornitori, ma invece parla direttamente al tuo CTO (e, a sua volta, il CFO) ed essere molto chiari sulle questioni in discussione.

In particolare:

• Chiedi al tuo CTO o CFO (oa chi lo detiene) di vedere il servizio contratto con il venditore, perché (e direi queste parole) sei tu viene chiesto di eseguire attività potenzialmente in violazione del accordo e vuoi essere in grado di indicarlo nel tuo compito rapporto di fattibilità. Potrebbero non dartelo, ma dicendo quelli le parole hanno spesso reso la gente in quelle posizioni meglio capirlo sei serio e la situazione è potenzialmente seria.

• Se fai ottieni una copia del contratto, quando scrivi il rapporto di fattibilità del compito, citalo direttamente quando c'è una chiara violazione.

• Se fai non ottieni una copia del contratto, quindi rendi le tue prenotazioni molto chiare su come il cambiamento potrebbe mettere l'azienda in una cattiva posizione per quanto riguarda il rapporto con il venditore .

• Se la tua preoccupazione non è problematica a causa dell'accordo del venditore ma è "semplicemente" problematica a causa degli effetti a catena del cambiamento, spiega cosa significa: se è così caotico come dici tu, allora tu probabilmente hai solo uno o due punti elenco prima di poter usare la linea "e si rovescia come un castello di carte".

In breve, fai ciò che puoi per indicare in modo molto chiaro e conciso il problema e i suoi effetti anche a un passo o due lungo la linea. Che tu abbia già l'opportunità di mettere un rapporto di fattibilità di fronte ai decisori è una buona cosa; non hai la struttura o il supporto di gestione (o ethos) per dire "Ho bisogno che tu firmi questo dicendo che capisci che questa è una cosa brutta e non la raccomando e non sarò responsabile degli effetti di questo cattiva decisione "(come se tu fossi un venditore e loro fossero un cliente), ma puoi ancora mettere un sacco di cose sulla carta che dimostrano che stai considerando ciò che è nel migliore interesse dell'azienda e delle sue risorse.

Se ti stanno dicendo di implementare procedure e trigger memorizzati, hai un importante problema di processo aziendale.

La tua più grande sfida è far sì che gli utenti qui cambino il loro modo di pensare. Devono essere in grado di fornirti il problema o il requisito. Ad esempio, abbiamo bisogno di spostare dati da qui a qui .

Dovresti essere tu a implementare la soluzione con il minor rischio / maggior guadagno, ed è tu chi può farlo in un modo che possa aiutare a prevenire futuri problemi di sviluppo.

Alcuni controlli sotto forma di disconnessione dell'utente o requisiti, e quindi anche l'approvazione dello sviluppo consegnato aiuterà. Se l'utente deve assumersi delle responsabilità / responsabilità per quello che sta chiedendo, potrebbe pensarci un po 'di più.

Sembra che tu stia implicando che la tua scelta è tra un'implementazione rischiosa di un requisito aziendale o del tutto assente. Raramente è in bianco e nero. Ho difficoltà a credere che i contabili stiano chiedendo direttamente le stored procedure, ma se lo sono, devi dare loro ciò che significa invece di ciò che stanno chiedendo. Scopri qual è il requisito aziendale, quindi scopri il modo meno rischioso per implementarlo.

Se il tuo fornitore non fornisce i ganci necessari per implementare in modo sicuro i requisiti che gli utenti desiderano, allora il problema è con il venditore, non con i tuoi utenti.

Stai fondamentalmente sviluppando software e in quanto tale hai bisogno di un metodo di sviluppo. Come vengono documentate le modifiche? Testato? Distribuito al QA? Distribuito alla produzione? ecc. Penso che se inizi a venire con un metodo e i costi associati inizieranno a capire. Forse i costi sono ben giustificati e devi solo implementare una procedura in modo che l'auto non si avvolga mai attorno a un palo della luce.