Ero abituato a lavorare per un'azienda in cui ogni app che gli abbiamo fornito portava alla domanda: possiamo esportare questi dati in Excel?

Dopo un po 'ho deciso di sapere perché erano ossessionati dalle esportazioni di Excel per tutto. Si è scoperto che molti dipartimenti avevano una persona esperta in Excel e che poteva scrivere un'app utile per l'analisi dei dati in pochissimo tempo. Queste app si sarebbero diffuse nel dipartimento come un incendio e noi, i tecnici, non sapevamo nemmeno che esistessero.

Perché non sono venuti prima da noi? Perché c'era una reputazione che il team tecnico aveva troppo da fare e, se l'avessero chiesto, avrebbero potuto (se fossero stati fortunati) farlo accodare sei mesi dopo.

Non è stata un'accusa ingiusta e non ci hanno mai chiesto di supportare le loro app Excel, quindi nessuno ha mai pensato che fosse un problema. Quando questi sviluppatori di Excel se ne sono andati, sono sempre riusciti a trovare qualcun altro a prenderlo.

Si potrebbe sostenere che ciò significava che avessimo la priorità in modo errato, che il lavoro importante non era stato fatto. Ma direi che ha liberato gli sviluppatori più pagati per fare lavori più difficili. Cosa può far male?

Ora I vorrebbe vietare il software che aggiorna il database che viene scritto al di fuori del team di sviluppo. E rifiuterei di supportare app scritte al di fuori del team di sviluppo. Ma non proverei a proibire che tutto il software venga scritto dall'azienda stessa, e scriverei volentieri le esportazioni di dati per consentire loro di farlo (a patto che ciò non esponga i dati che non dovrebbero vedere, ovviamente ).

Penso che alle persone manchi il punto generale qui:

If you don't like all the custom development that's going on, forbidding it is solving the wrong problem - you should instead be asking why they're going around IT, not just telling them it's not allowed. Remember that you (IT) exist to help them do their job better, and that people don't use software because it's cool or neat or new, they use it because it solves a problem they have.

Perché queste app vengono create in primo luogo?

In tutti i casi che ho visto, c'è un motivo comune:

I gruppi di imprese danno la priorità ai propri bisogni più alti di quelli con le stesse priorità nel contesto di tutta l'azienda

Il marketing è responsabile solo per il marketing, quindi le iniziative a beneficio dei loro obiettivi sembrano fondamentali per loro, pur essendo considerate fluff per altri gruppi, e tendono ad avere una priorità inferiore quando si tratta di risorse limitate come l'IT. Le prioritizzazioni entrano in gioco solo quando vogliono utilizzare una risorsa condivisa: se mantengono il progetto interamente all'interno del proprio dipartimento, solo il capo reparto deve preoccuparsi del budget e della tempistica.

Non c'è motivo per cui proibire questo tipo di sviluppo, entro limiti ragionevoli - alleggerisce i vincoli sulle risorse condivise (principalmente IT) e consente a ciascun gruppo di potenziare se stesso per risolvere i propri problemi (come le persone esperte in Excel avanzato sono piuttosto comune, poiché questo è un problema comune, la maggior parte dei reparti ne ha almeno uno).

Tuttavia, non ci si può aspettare che tu possa risolvere eventuali problemi derivanti da queste applicazioni o supportarle dopo che lo sviluppatore originale ha lasciato la società. Come menziona un altro postato, questo non impedisce al grande capo di chiedere di supportarlo, ma se si mantiene la sensazione per i tipi di applicazioni o processi personalizzati là fuori, si può avere un'idea di quando qualcosa diventa critico e voi potrebbe aver bisogno di essere coinvolto per portarlo "in-house". Inoltre, se qualcosa si connette e modifica i sistemi che sono sotto il controllo IT, allora l'IT dovrebbe essere coinvolto, se non altro per garantire la sicurezza e l'integrità dei loro sistemi centrali - tuttavia, se è qualcosa limitato al desktop di un utente, perché sentire il bisogno vietarlo?

Ma ecco qualcosa da ricordare: Ogni applicazione personalizzata che è stata sviluppata al di fuori dell'IT corrisponde a un'esigenza che non viene soddisfatta dall'IT . Può esserci una buona ragione per cui non vengono soddisfatti - non è una priorità in azienda, un problema molto specializzato, non buono come altre opzioni, un linguaggio personalizzato che i tuoi IT non conoscono, ecc. - e la mancanza di coinvolgimento IT può essere legittimo, ma queste soluzioni sono state create perché alcuni dipartimenti avevano bisogno che l'IT non potesse (o non volesse) soddisfare.

Cerca di aiutarli a risolvere i loro problemi, e se non hai tempo o risorse, lascia che li risolvano da soli. Mandare una lingua che ha una curva di apprendimento ripida, con l'unico scopo di tenere le persone fuori dalla tua attività, serve solo a migliorare l'atteggiamento elitario che la maggior parte degli utenti aziendali percepisce nell'IT e, alla fine, quel tipo di atteggiamento di élite porta solo a più dello stesso problema, poiché gli utenti hanno paura di avvicinarsi all'IT e sono convinti che l'IT non capisca i propri bisogni o desideri. Apri la relazione: la comprensione di ciò di cui hanno bisogno è l'unico modo per impedire loro di girarti intorno.

Si dovrebbe anche considerare il caso delle società in cui il reparto IT contiene persone incompetenti, mentre l'app nascosta sarebbe creata da uno sviluppatore abile che ha un lavoro non sviluppatore all'interno dell'azienda. Nella mia esperienza, questi casi sono estremamente frequenti.

Immagina di avere un doppio profilo di uno sviluppatore di software e un contabile. Sei assunto come contabile perché questa era un'opportunità per te per ottenere un lavoro ben pagato. Vedi rapidamente che i tuoi colleghi (e ora tu) passano ore a fare cose ripetitive che possono essere fatte in pochi secondi da un programma.

Trascorri alcune sere per scrivere l'app che farà tutto il lavoro. Lo mostri sul tuo laptop personale ai tuoi colleghi e lo trovano molto utile. Si desidera installarlo sui PC aziendali, ma si dovrebbe avere l'accordo del dipartimento IT. Lo chiedi, ma lo rifiutano perché non supportano la tua applicazione.

Non sembra stupido?

A parte questo caso particolare, il problema con il supporto non è molto diverso da quello che molte aziende incontrano con tutti il software, anche uno scritto all'interno del dipartimento IT: se il reparto IT non applica le best practice , il codice sarà male / non documentato, scritto da persone inesperte che non si preoccupano della manutenzione e che hanno lasciato anni fa.

Per concludere, la domanda principale è la redditività . Se a te, al dipartimento IT, viene chiesto di mantenere un'app sviluppata da un impiegato che non comprende le regole di base dello sviluppo del software, non importa quanto sia divertente questo compito, devi comunque farlo se porta un sacco di soldi alla compagnia . Oppure lo riscrivi da zero se è il modo più economico per fare le cose.

Non puoi completamente controllarlo ...

Direi che non puoi mai controllarlo COMPLETAMENTE, dato che i dipendenti avranno sempre mezzi per produrre codice canaglia e diffonderlo con mezzi alternativi. Quindi non è molto utile ossessionarsi troppo su di esso, una volta che hai redatto e applicato alcune regole e processi di base e hai impostato alcuni strumenti.

L'idea è che tu renda il più attraente possibile per le persone rispettare queste regole e utilizzare questi strumenti, piuttosto che rendere così impossibile fare cose nuove che non producono nulla.

Ma puoi creare un ambiente adatto al codice

Molte aziende, spesso molto grandi, lo fanno. Un buon esempio è Google, per il quale i rappresentanti hanno affermato di utilizzare un singolo SCM per l'intera azienda, affinché tutti siano in grado di monitorare e guardare il codice degli altri.

Ti consigliamo di fare quanto segue:

• consente l'accesso pubblico ad alcune aree del tuo SCM,
• semplificare la richiesta di accesso all'integrazione continua e ai server di ispezione continua,
• incoraggiare le persone a creare lavori di compilazione per i loro strumenti.

Il problema è quindi la proliferazione delle tecnologie. Ovviamente, alcuni preferiranno usare X su Y e questo è il momento in cui diventa più difficile inserirli all'interno della tua architettura. Tuttavia, non è impossibile, e se vogliono che il loro codice venga mantenuto avranno probabilmente il miglio in più se, beh, è solo un miglio.

Potresti anche prendere una posizione più arbitraria e decidere che sono permessi solo il linguaggio L e lo Stack S, ma poi otterrai qualche roba da ladro qua e là, quindi ti consiglierei di ampliarlo un po '. Alcuni sistemi CI faranno miracoli con alcuni plugin, se i tuoi dipendenti sono disposti a scrivere un po 'di codice colla o alcuni script di configurazione per farli adattarsi.

Dai alle squadre un po 'di libertà

È importante dare alle squadre la libertà di andare avanti per capricci e avviare nuovi piccoli progetti con cose sperimentali. Li tiene in pugno e tu, oltre a costringerti a considerare queste tecnologie, piuttosto che rimanere bloccato in una pila per sempre finché non ti crea problemi.

Quindi assicurati che abbiano la possibilità di installare i propri sistemi per testare i loro progetti di animali domestici. Ma assicurati che abbiano preso l'abitudine di parlarne con IT.

Parla con IT, coinvolgili

È molto meglio se i tuoi dipendenti sviluppano il riflesso di una richiesta di e-mail all'IT e chiedono loro se possono impostare qualcosa per loro e ospitarli. La maggior parte del tempo verrà rifiutata, ma almeno c'è qualche nozione di controllo e di chi dovrebbe essere responsabile e dà all'IT una certa visibilità sulle richieste dei diversi team.

Una volta che i progetti raccolgono una massa più critica, puoi richiedere di nuovo e loro riconsidereranno. La comunicazione è fondamentale, e devi collaborare con i tuoi team di sviluppatori, consulenti, personale di supporto IT o chiunque abbia a che fare con il codice. Nessuno di loro vuole programmi randagi, quindi è nell'interesse di tutti. È molto più facile far rispettare le regole se le stanno eseguendo personalmente.

Non puoi fermare queste applicazioni "nascoste" perché le persone le fanno per risolvere problemi aziendali reali. Tutto quello che puoi fare è aiutarli a farlo nel modo "giusto". E per "giusto" intendo fare in modo che le app possano essere mantenute dopo che la persona che le ha avviate è partita. Consiglio di utilizzare la lingua suggerita in Up o Out : < em> Ho bisogno che tu documentino questo processo in dettaglio in modo che qualsiasi yahoo possa capirlo un anno dopo la tua partenza. Aiuta con l'impostazione del controllo della versione (e mostra come usarlo), un wiki (per tenere note informali su come il lavoro viene effettivamente svolto) e un semplice sistema di tracciamento dei bug. Se vuoi rendere le cose davvero fluide, imposta l'integrazione continua su un server di riserva (se ne hai una).

Vedrai l'enorme desiderio di integrazione con Excel (o almeno di importazione / esportazione) perché tutte le business school ora insegnano a Excel ed è uno strumento importante utilizzato in molti corsi di business.

Sarbanes-Oxley e una legislazione analoga al di fuori degli Stati Uniti, combinata con le leggi sulla privacy e le procedure e le politiche interne sulla privacy e sicurezza sono il "martello" che può essere usato spesso per bloccare il fenomeno dell'ombra-IT.

Non appena le informazioni identificative personali dei clienti o dei dipendenti (o qualsiasi dato che non vuoi estrarre) inizia a circolare in questi fogli di calcolo, hai un incidente in attesa di accadere.

Allo stesso modo, non appena uno di questi progetti IT skunkworks prende quel foglio di calcolo Excel e lo utilizza come i dati di un'app web rivolta verso l'esterno che viene violato, il CIO e il CEO si precipitano nell'ufficio di chiunque abbia costruito quella app in un weekend in arrivo per spiegare le conseguenze.

E poi c'è il problema che quando si guardano questi sforzi moltiplicati per centinaia (o migliaia) di reparti in un'azienda Fortune 500, si scopre presto che la propria azienda ha oltre 100 database "master" dei clienti. I tuoi clienti iniziano a lamentarsi del fatto che hanno aggiornato le loro informazioni di contatto in un unico posto ma che non è ancora aggiornato in altre 10 o che non sai nemmeno quanto lavoro fai con i tuoi partner di grandi dimensioni perché le informazioni sono distribuite su 10 shadow Database IT.

Tutto ciò dà luogo a onerosi processi di conformità e audit che non sono divertenti per nessuno ma sono i fatti concreti della vita dell'IT in un ambiente aziendale.

Una buona strategia è quella di guardare attraverso tutti i dipartimenti che stanno facendo questo e fare un caso per spostare il loro investimento in IT ombra in IT appropriato, rendendo l'argomento che l'IT può raggiungere un'economia di scala e farlo funzionare in modo più efficiente rispetto all'attuale modello skunkworks distribuito ad hoc. Questo può essere un duro affare in un ambiente in cui i vincoli di budget IT e la velocità di consegna hanno dato origine allo skunkworks in primo luogo, ma combinato con i rischi di audit / fiduciaria può fare un bel colpo a uno a due.

La decisione di scrivere una nuova domanda è spesso basata su un'analisi costi-benefici della richiesta; così come il valore complessivo del business. Il tutto tenendo conto di molti altri fattori, come le risorse IT disponibili, l'ambito della richiesta, gli obiettivi aziendali e la direzione, solo per citarne alcuni. Spesso, una richiesta specifica dei reparti viene negata perché il direttore / direttore di reparto non è riuscito a mostrare un ROI ragionevole o semplicemente non segue il processo stabilito.

Indipendentemente dal motivo, il "dipartimento IT" è spesso il capro espiatorio, anche se la decisione era al di fuori del loro controllo. Quindi, anche se la negazione della richiesta potrebbe non riflettere in modo negativo sul reparto IT, la percezione è spesso completamente diversa.

Nonostante ciò, troverai applicazioni illegali in quasi tutte le organizzazioni commerciali del mondo. Alcuni ben scritti e altri che bene, contengono codice che non dovrebbe mai essere visto alla luce del giorno.

Mentre dovremmo fare tutto ciò che ragionevolmente possiamo soddisfare per soddisfare le esigenze dei nostri clienti interni, ci sono momenti in cui semplicemente non possiamo. Quando ciò accadrà, guarderanno altrove per risolvere il loro problema.

Se il gruppo IT è coinvolto attivamente nel progetto, possiamo richiedere il rispetto dei nostri standard, aiutare il consulente a seguire le linee guida interne di codifica e comprendere le interazioni tra applicazioni e richieste sui nostri sistemi (database, rete, firewall, ... ). Senza questo coinvolgimento saremo colti di sorpresa e impiegheremo molto tempo a cercare di capire perché i nostri sistemi di produzione non soddisfano gli SLA.

Se il reparto IT li ammette e li supporta o meno, possono avere e avranno un impatto diretto in termini di supporto, impegni OLA e SLA che vengono misurati da qualsiasi dipartimento IT.

Sono vietati nella nostra azienda per questi motivi:

• Macro Excel protette da password in cui l'unica persona che conosce la password ha lasciato la società,
• Essere ritenuti responsabili di rapporti errati scritti da persone inesperte, perché è IT '
• Viene chiesto di modificare un rapporto che non abbiamo mai visto o sentito prima.

Capisco che possa essere frustrante per gli utenti quando l'IT è occupata e potrebbero essere inclini a "fare semplicemente da soli". Ma l'IT non può essere ritenuta responsabile di cose che non sa nemmeno esiste, e se nessuno è responsabile per l'IT in generale, allora ci saranno grandi problemi.

Se c'è un problema qui è con il reparto IT.

Non c'è nulla di sbagliato nel permettere alle persone con conoscenze specialistiche di business / dominio di manipolare ed elaborare i propri dati.

Il dipartimento IT deve riconoscerlo e sostenerlo. Fornendo interfacce riutilizzabili, fornendo dati in formati convenienti come EXCEL o Access DB e fornendo strumenti flessibili (COGNOS, Jasper Reports ecc.).

Il reparto IT deve anche ripensare alle sue priorità: è lì per servire l'azienda, non per implementare l'ultima metodologia, o installare l'hardware più sexy.

Una frustrazione che molte aziende, o dipartimenti di aziende, hanno che i loro reparti IT si intromettono e rendono difficile per loro portare a termine il proprio lavoro o fare cose nuove. Questo porta i reparti, che si sentono come se fossero trattenuti dalle politiche IT, per tentare di risolvere i propri problemi. La comunicazione è la chiave. Se i reparti lavorano intorno all'IT, quello che hai veramente è un problema IT. Non può permettersi di essere visto come il nemico. Le aziende, e in particolare i dipartimenti IT, devono rendersi conto che hanno bisogno di lavorare insieme anziché l'uno contro l'altro. Se i dipartimenti comunicano con il proprio personale IT (specialmente quelli che dovrebbero avere supervisione) e comunicano loro i loro bisogni e il modo in cui stanno lavorando per risolvere i loro problemi, l'IT avrà almeno la possibilità di aiutare a risolvere i problemi invece di scoprire dopo Infatti quando una crisi avverrà. Mantieni l'IT nel ciclo.

C'è quasi una necessità valida per questi strumenti speciali, siano essi applicazioni o fogli di calcolo. Un reparto IT ha due scelte. Possono essere attivatori o attivatori. Nella mia esperienza, i disablers perdono perché si intromettono in esigenze aziendali valide e diventano un nemico comune. I fattori abilitanti, d'altro canto, aiutano veramente un'impresa.

Questo non significa che lo sviluppo finanziato dal dipartimento dovrebbe essere dato libero dominio. Alcuni requisiti dovrebbero essere applicati, come i seguenti:

• Tutto il codice deve essere regolarmente impegnato in un sistema di controllo versione gestito dall'IT. L'IT dovrebbe creare liberamente account e directory per renderlo possibile. Potrebbe anche voler fornire qualche istruzione.
• Tutto ciò che riguarda le Informazioni personali (identificazione personale), l'autenticazione, l'autorizzazione, la crittografia, i dati protetti dalla legge oi dati ritenuti critici dall'azienda devono essere coinvolti e approvati da un consulente IT. IT / il consulente dovrebbe fornire assistenza, biblioteche, ecc. Per proteggere adeguatamente l'azienda e allo stesso tempo consentire lo sviluppo di app.
• I database primari dovrebbero essere protetti. A seconda del database, l'accesso in lettura dovrebbe essere relativamente facile da ottenere e scrivere più facilmente. Potrebbe essere necessario che l'IT fornisca account, registrazione o auditing.

L'attivazione ha molti vantaggi.

• L'IT impara di più sulla soddisfazione delle esigenze dei propri clienti. Ciò porta a una migliore definizione delle priorità e condivisione.
• L'IT è visto come un amico e un vantaggio, piuttosto che un problema.
• Sono soddisfatti i reali bisogni aziendali.
• I dati aziendali sono adeguatamente protetti perché l'IT era coinvolto, evitando la necessità di backdoor.
• Gli strumenti di divisione non vengono persi a causa del turnover e possono essere spostati più facilmente nell'IT, se necessario.

Non ho potuto fare a meno di identificarti con te. Il problema che descrivi sembra essere universale, attraversando culture, lingue e continenti.

Le cose che puoi fare:

• Limita la creazione di account di database , chiedendo l'approvazione di un supervisore. Costringendoli ad usare una macchina locale come server di database o scrivendo le app come indipendenti, diminuisce notevolmente la sua utilità.

• Rendi tutti stagisti di carriere correlate all'IT contratti solo tramite IT

• Restrizioni tramite i criteri del sistema operativo installazione del software . Ogni installazione di software deve essere canalizzata attraverso l'help desk IT, richiedendo l'approvazione di un supervisore. In questo modo l'installazione di qualcosa come MS Access, PHP, Visual Basic, ecc. Sarà più difficile da passare inosservata.

• Segnala un criterio che indica che ogni nuovo sviluppo, per poter fornire supporto, deve essere scritto, ad esempio Java, C #, C ++ o qualsiasi altra lingua che richiederebbe una curva di apprendimento ripida . In questo modo riduci l'universo delle persone con "una certa conoscenza della programmazione" per pasticciare.

• I requisiti le persone devono dare un'occhiata alle "soluzioni Excel" in giro per l'azienda, perché riflettono le esigenze IT dell'azienda.

• Implementazione di un data warehouse e un data mining user-friendly e strumento di reporting . In questo modo riduci la necessità di app personalizzate scritte internamente.

Ma non una sola cosa che farai supererà una telefonata da un grande capo , chiamando il responsabile IT e chiedendogli di supportare l'app realizzata da un tirocinante.

Un modo in cui la mia azienda aiuta in questo tipo di situazioni è di non essere indipendente dal linguaggio. Se vuoi che un'app / programma sia considerata, deve essere in una lingua a nostra scelta (java). Potremmo allungare un po 'le regole per alcuni JQuery o js, ma sarebbe necessario che fosse un'applicazione ben composta che rispondesse a un'esigenza critica. Non venire e dire "Ho questa app per PHP che ho bisogno che tu faccia da host per me" perché probabilmente ti verrà consegnata una polizza.

È importante stroncare le cose prima che diventino troppo grandi, perché una volta che è meglio avere qualcuno che puoi dedicare ad impararlo o riscriverlo. Perché una volta che la parrucca al piano di sopra decide che gli piace, probabilmente non te ne sbarazzerai mai più nella mia esperienza.

L'arroganza di Geeks!

In molti casi gli utenti aziendali possono utilizzare gli strumenti per fare cose che gli IT non capiscono. Questo non perché sono intrinsecamente cattivi, ma perché conoscono il business, come funziona e come vorrebbero che funzioni.

Ad esempio, un'azienda di software ha sviluppato un'applicazione per ottimizzare (a costo) l'accesso ai feed di dati di mercato. Come ripensamento hanno fornito un plug-in di Excel in modo che gli utenti potessero accedere all'ultimo prezzo delle azioni tramite un foglio di calcolo. Avanti veloce di un anno e quasi tutti i trader della compagnia per cui lavoravo avevano uno o più fogli di calcolo incredibilmente complessi per supportare la loro strategia di trading. Ogni tanto hanno un problema con le macro e chiedono aiuto a uno dei ragazzi IT, i più rifiutati (e si chiedono perché l'azienda ci odia!). Ho comunque provato e, mentre potevo risolvere problemi tecnici con vari parametri di funzione e riferimenti circolari, posso onestamente dire che non avevo la benché minima idea di che cosa fosse effettivamente l'intero foglio di calcolo. Non perché erano messi insieme male o programmati male, ma perché non avevo le conoscenze o l'esperienza per apprezzare la sottigliezza di ciò che i commercianti stavano cercando di ottenere. Inoltre, stimerei un progetto di 5 anni più un progetto IT per replicare la funzionalità di uno di questi fogli di calcolo in un linguaggio di programmazione "corretto" come un progetto IT standard.