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

Abbiamo un grosso problema dove lavoro e il suo nome è "personalizzazione". Disponiamo di un vecchio sistema software (10+ anni) che i nostri reparti IT e contabili precedentemente adoravano personalizzare. Da qualche parte lungo la linea questo software ha iniziato a diventare molto difettoso. Quindi, sono stato assunto dopo la maggior parte della personalizzazione.

Quasi tutti i problemi che ho riscontrato con il sistema sono il risultato diretto della personalizzazione; tutto ciò che cambiamo rischia di rompere il software finanziario critico per l'azienda. Eppure il dipartimento contabilità continua a suggerire cambiamenti (perché abbiamo sempre detto di sì!) E sembra esserci scarso rispetto per quanto possano essere efficaci i cambiamenti.

Alcuni cambiamenti non causano problemi; i moduli possono essere (e sono pensati per essere) personalizzati nel software del fornitore, possiamo spostarci nei campi dei moduli, rimuoverli, ecc. Ma per ogni innocua personalizzazione del genere suggeriscono anche cambiamenti come le procedure memorizzate e i trigger per manipolare i dati nel database per l'applicazione del fornitore.

Di recente (a malapena) li ho fatti smettere di tentare di importare clienti da un programma del fornitore a un altro poiché le informazioni erano completamente incompatibili. Il mio problema con come è stato risolto è perché ho scoperto che il sistema non funzionava sul lato utente; il compito era più complicato di quanto pensassero, quindi si arresero. Indipendentemente da quanto sia facile l'attività lato utente, l'operazione che desideravano non avrebbe dovuto essere eseguita.

Come posso comunicare che cambiare il funzionamento di questo sistema comporta dei rischi, in particolare quando è in gioco la validità dei dati? Sono un nuovo assunto (6 mesi) ed è diventato lo status quo, ma sta rischiando la validità dei nostri dati finanziari e dei nostri contratti di supporto - una volta che il supporto del venditore sente "X è stato personalizzato" che dà loro molte ragioni sostenerci o dirci che è colpa nostra.

Il rischio / rendimento dei sistemi di personalizzazione è quello di fornire un vantaggio competitivo che consenta alla tua azienda di offrire qualcosa di diverso rispetto alle altre aziende del 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, fornire più funzionalità o fare più soldi.

Il fatto che io comunichi in queste situazioni è che è un compromesso. Nel fare queste modifiche a un sistema, l'organizzazione sta sviluppando la propria base di conoscenza interna / competenza dei propri sistemi che non saranno in grado di fare facilmente senza. Questa base di conoscenza interna deve essere meglio gestita e organizzata in modo tale da poter tracciare e gestire questi cambiamenti. Significa anche che potrebbe invalidare i contratti di supporto del fornitore e altri aspetti che le risorse IT utilizzate dall'azienda per questo processo.

Il rischio più grande di cui parlo sono gli aggiornamenti di versione al software del fornitore quando un'azienda adotta questa filosofia di gestione dei dati. Questo è uno dei rischi più probabili in cui qualcosa si romperà. La società deve comprendere i compromessi in corso 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 sia responsabile dell'azienda per rendersi conto che stanno creando un ambiente che ha ancora ulteriori dipendenze da uno specialista interno che apporta modifiche a questi sistemi.

Per l'analogia con l'auto, non è il meccanico che deve sapere quali cambiamenti vengono apportati a un'auto, è il proprietario che deve capire che potrebbe richiedere meccanici speciali, più denaro o perdita di quel servizio per un periodo di tempo. Educare il proprietario è la chiave di questa conversazione.

Comunicare agli abitanti dell'ufficio? Vorrei andare con analogie.

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

Sei il meccanico incaricato di mantenerlo in funzione. Il database è il motore. L'intero sistema è l'auto. I ragionieri guidano la macchina. Il simpatico coniglietto che i ragionieri si sono sfidati a perdere è un personaggio umlaut nel cognome di un nuovo cliente. Il palo della luce attorno al quale hanno avvolto la loro auto è l'insetto critico che è stato introdotto quando volevano aggiungere una palla da discoteca all'interno dell'auto.

Altri hanno fornito alcuni buoni esempi dell'uso di analogie e altro linguaggio per rispondere alla domanda principale, che era "Come posso comunicare che cambiare il modo in cui funziona questo sistema ha dei rischi, in particolare quando è in gioco la validità dei dati?"

Ma sulla base del tuo chiarimento sul modo in cui ti viene assegnato il compito, non sono sicuro che qualsiasi analogia ti aiuterà nella situazione - non sembra davvero che le persone fraintendano ciò che stanno chiedendo, ma piuttosto che a loro non importa. Sono stato lì - probabilmente siamo stati tutti lì - e in queste situazioni tendo a fare uno sforzo maggiore per essere perfettamente chiari sui problemi, piuttosto che metterli in termini intesi come insegnare piuttosto che avvertire .

Concentrati su ciò che puoi fare, che non sta cambiando da solo le menti di tutti coloro che chiedono personalizzazioni che mettono a rischio l'integrità dei dati e i contratti di supporto del fornitore, ma parla invece direttamente al tuo CTO (e, a sua volta, al CFO) e di essere molto chiaro per quanto riguarda le questioni a portata di mano.

In particolare:

• Chiedi al tuo CTO o CFO (o chiunque lo detenga) di vedere il contratto di servizio con il venditore, perché (e direi queste parole) ti viene chiesto di eseguire attività che potenzialmente violano il contratto e vuoi essere in grado di evidenziarlo nel rapporto di fattibilità dell'attività. Potrebbero non dartelo, ma dire quelle parole ha spesso fatto capire alle persone in quelle posizioni che sei serio e che la situazione è potenzialmente seria.

• Se fai ottenere una copia del contratto, poi, quando si scrive il rapporto compito di fattibilità, citare direttamente da esso quando c'è una violazione chiara.

• Se non si ottiene una copia dell'accordo, rendere le prenotazioni molto chiare su come la modifica potrebbe mettere la società in una cattiva posizione per quanto riguarda il rapporto con il venditore.

• Se la tua preoccupazione non è problematica a causa dell'accordo del fornitore ma è "semplicemente" problematica a causa degli effetti a cascata del cambiamento, delinea il significato di questo: se è così disordinato come dici, allora probabilmente ne hai solo uno o due punti elenco prima di poter utilizzare la riga "e caderà come un castello di carte".

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

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

La tua più grande sfida è convincere gli utenti a cambiare il loro modo di pensare. Devono fornirti il ​​problema o il requisito. Ad esempio, abbiamo bisogno che i dati si spostino da qui a qui .

Dovresti essere tu a implementare la soluzione con il minor rischio / maggior guadagno, e sei tu che puoi farlo in un modo che aiuterà a prevenire futuri problemi di sviluppo.

Aiuteranno anche alcuni controlli sotto forma di firma o requisiti dell'utente, quindi la firma dello sviluppo fornito. Se l'utente deve assumersi una certa responsabilità / responsabilità per ciò che sta chiedendo, potrebbe pensarci un po 'di più.

Sembra che tu stia insinuando che la tua scelta è tra un'implementazione rischiosa di un requisito aziendale o nessuna. Raramente è in bianco e nero. Ho difficoltà a credere che i contabili stiano chiedendo direttamente le procedure memorizzate, ma se lo sono, devi dare loro quello che significano invece di quello che stanno chiedendo. Scopri quali sono i requisiti aziendali, quindi trova il modo meno rischioso per implementarlo.

Se il tuo fornitore non fornisce i ganci di cui hai bisogno per implementare in sicurezza i requisiti richiesti dai tuoi utenti, allora quel problema è con il fornitore, non con i tuoi utenti.

Fondamentalmente stai sviluppando software e come tale hai bisogno di una metodologia di sviluppo. Come sono documentate le modifiche? Testato? Distribuito al QA? Distribuito alla produzione? ecc. Penso che se inizi a elaborare una metodologia e i costi ad essa 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.