Esplorare i vantaggi aziendali di SharePoint

Qualcuno nella tua azienda ha mai considerato se stesse ottenendo il massimo valore da SharePoint? A prima vista, questa sembra essere una domanda ridicola. Perché un'azienda dovrebbe implementare SharePoint se non ne ha già determinato i veri vantaggi e il valore complessivo?

Ma nelle mie conversazioni quotidiane con altri tecnici e uomini d'affari sono stupito di quanto spesso non siano in grado di identificare e quantificare il ROI reale che vedono in SharePoint. Ancora più sorprendente è il numero di aziende che non hanno utilizzato completamente il proprio ambiente SharePoint per ridurre i costi aziendali complessivi e aumentare la produttività.

Le specifiche tecniche di SharePoint sono importanti, ma in questo articolo voglio condividere con te di più su ciò che in genere manca nella strategia aziendale delle aziende che utilizzano SharePoint.

Perché usare SharePoint: una visione...

Una domenica dell'inverno del 2009, mi sono seduto al mio posto vicino al finestrino, fissando con impazienza un 747. Stavo andando a San Francisco per partecipare alla mia prima conferenza in assoluto, VSLive.

All'epoca lavoravo in un'importante azienda di cosmetici. Ero entusiasta di partecipare ai corsi di SharePoint a cui mi ero registrato: era uno stack tecnologico relativamente nuovo all'interno dell'azienda e volevo vedere di persona cosa poteva davvero fare SharePoint per l'azienda.

Non sono rimasto deluso. Ho lasciato San Francisco con una tale eccitazione, una sensazione che pensavo fosse scomparsa da tempo dalla mia carriera professionale. Ero così ansioso di tornare in ufficio per discutere di questo straordinario strumento con il mio team... solo per essere riportato alla realtà della mia esistenza come direttore del team Global Information Systems:

[Direttore Esecutivo – GIS] : “Certo, ho sentito parlare di SharePoint. Non vedo di cosa si tratti tutto questo trambusto... Potremmo fare le stesse pagine web all'interno della nostra web farm. Penso che tu stia sprecando il tuo tempo".

[Business Relationship Manager – GIS] : “È semplicemente troppo semplice e brutto. Non sarò mai in grado di venderlo a nessuno dei miei clienti aziendali".

[Senior Developer – GIS] : “Qual è il problema? Non vedo che aggiunga alcun valore. Sembra troppo complicato per lavorarci. Penso che Active Server Pages sia una direzione molto migliore.

L'unico a mostrare anche un minimo di interesse è stato il regista a cui ho riferito direttamente. Non sapeva molto delle tecnologie all'interno di SharePoint, ma sapeva che ero troppo entusiasta di questo per ignorarlo semplicemente.

Mi ha chiesto di organizzare un breve incontro per me per discutere ulteriormente di questa tecnologia. Quell'incontro ci ha portato a progettare un proof of concept (POC) di SharePoint per il nostro senior management che sarebbe poi diventato un componente fondamentale all'interno del dipartimento GIS. Automatizzerebbe e semplificherebbe i nostri nuovi processi del ciclo di vita dello sviluppo del software (SDLC) e aprirà la strada all'adozione da parte dell'azienda di molti vantaggi di SharePoint, catapultandomi al livello di spicco di "The SharePoint Guy". Per i successivi otto anni, avrei trascorso gran parte del mio tempo in azienda utilizzando SharePoint come uno straordinario strumento di produttività a basso costo. Per coloro che volessero ascoltare, avrei migliorato molti processi aziendali e ridotto i loro costi, ma c'erano ancora troppi siti all'interno dell'azienda che erano semplici siti di team con raccolte di documenti. Ero solo una persona che nuotava controcorrente per vendere SharePoint non solo alla mia azienda, ma anche ai livelli più alti dell'organizzazione.

Questo suona familiare?

Negli ultimi nove anni ho osservato che gli usi di SharePoint nella maggior parte delle aziende rientrano in uno dei due scenari di base.

1. Siti del team con librerie di documenti

Questi siti sono generalmente creati dal modello Team e contengono una o più raccolte documenti che possono avere strutture di cartelle molto complicate. C'è pochissimo uso di tipi di contenuto, tag di metadati o flussi di lavoro. I siti sono completamente supportati dalla business unit, i cui membri non hanno una conoscenza formale di SharePoint e non hanno abbracciato il ruolo di "Power User". Il sito è stato creato dall'infrastruttura o dal team di supporto che può generare rapidamente un sito da un semplice ticket di richiesta dell'help desk.

2. Siti completamente personalizzati con una base di codice ampia e complicata

Di solito, si tratta di siti molto più grandi con un pubblico molto più ampio: le intranet aziendali, le risorse umane aziendali e i siti IT aziendali sono i soliti candidati per questo tipo di utilizzo di SharePoint.

Questi progetti di solito iniziano con una grande direzione e aspettative. Sono venduti come un'alternativa a basso costo a molti dei costosi sistemi di gestione dei contenuti (CMS) di fascia alta che l'azienda ha già studiato. Poi, man mano che il progetto va avanti, i requisiti si trasformano e diventano più complicati. Ha bisogno di più codice personalizzato, che alla fine diventa abbastanza complesso da rendere il supporto del codice un problema.

Da qui le cose di solito sfuggono al controllo. Il team di sviluppo ha rinunciato alla premessa di rimanere con funzionalità out-of-the-box (OOTB) con una base di codice limitata. Invece, hanno un approccio completamente personalizzato, che va da pagine master completamente personalizzate a possibilmente un'app ospitata dal provider (PHA) o, come la chiamano ora, un componente aggiuntivo ospitato dal provider.

Riesco già a sentire i sospiri e vedere gli occhi che roteano. "Tony, questi sono approcci di utilizzo perfettamente validi." "Abbiamo entrambi e i nostri utenti adorano i siti e non abbiamo problemi a supportarli". Non sto in alcun modo affermando che nessuno di questi metodi sia sbagliato, né che uno sia vantaggioso rispetto all'altro, ma credo che entrambi gli approcci semplicemente perdano l'opportunità di utilizzare appieno ciò che la piattaforma SharePoint ha da offrire.

Ritengo inoltre che questi due modelli facciano in modo che l'azienda abbia la sensazione che SharePoint sia troppo costoso per quello per cui lo utilizza o che il reparto IT abbia la sensazione di poter semplicemente sviluppare la stessa funzionalità tramite server Web e pagine HTML o un CMS preconfezionato soluzione cloud. In entrambi i casi, sia l'azienda che l'IT hanno la sensazione che SharePoint non sembri lo strumento giusto per le loro esigenze.

Vantaggi di SharePoint andato AWOL?

Per capire meglio dove siamo, dobbiamo fare un passo indietro e rivedere come siamo arrivati ​​qui.

Ti riporterò alla semplice domanda "Come hai saputo di SharePoint?" Dalla mia esperienza personale e dall'esperienza di molti altri leader IT con cui ho parlato, SharePoint come piattaforma tecnica è stata presentata all'azienda dal team dell'infrastruttura con l'assistenza dei loro consulenti Microsoft Enterprise.

Di solito, la prima farm di SharePoint è una sorta di banco di prova che viene fornito all'azienda nell'ambito del contratto Enterprise con Microsoft. A questo punto, la maggior parte delle aziende coinvolge un cliente aziendale e distribuisce la prima raccolta siti con un unico sito del team. Il cliente aziendale ama le raccolte documenti e la possibilità di collaborare e condividere documenti e quindi inizia a utilizzare il sito come parte dei propri processi aziendali.

Questo può sembrare perfettamente accettabile per molti di voi e, in tutta onestà, può essere un valido caso d'uso per SharePoint. Ma una volta che si approfondisce SharePoint, ci si rende conto che è molto più di una semplice piattaforma implementata e supportata dal team dell'infrastruttura: è uno spazio applicativo solido che richiede la stretta collaborazione dell'infrastruttura, dell'architettura aziendale e dei team delle applicazioni.

Non sono una persona "anti-infrastruttura" o una persona politicamente contraria al team dell'infrastruttura, ma senza la collaborazione dei partner corretti sin dall'inizio, si corre il rischio di non comprendere l'intera portata della piattaforma SharePoint e quindi non sono preparati per le strategie aziendali e il piano di utilizzo appropriati. Questa situazione non è esclusiva della piattaforma SharePoint e indica un problema molto più ampio di collaborazione e strategia adeguate, che sta affrontando molti dipartimenti IT.

Il tuo cliente aziendale è la chiave

Troppo spesso, molte organizzazioni tecniche non hanno alcuna strategia aziendale quando si tratta di SharePoint. Hanno semplicemente aggiunto un piccolo processo a quelli esistenti su come richiedere e creare un sito di SharePoint. Potrebbero non includere nemmeno alcun tipo di governance attorno al processo di creazione del sito, il che può portare a un volume molto elevato di raccolte siti e alla fine a un problema di supporto.

Potrebbero esserci conversazioni e informazioni di base sull'uso di alcuni dei concetti più ampi come raccolte siti e ricerca in SharePoint . Ma le discussioni sulla strategia possono diventare molto complicate. Per questo motivo, molte organizzazioni tecniche decidono semplicemente di terminare la loro strategia durante il processo di creazione del sito. Invece, iniziamo lentamente e con le funzionalità chiave di SharePoint di base.

Chi sono i tuoi clienti aziendali? Sono il team tecnico aziendale, il tuo team di marketing regionale o forse il team di ricerca e sviluppo? Come ho affermato in precedenza, l'implementazione di SharePoint viene in genere avviata dal team dell'infrastruttura e quindi si diffonde lentamente nella popolazione dei client aziendali.

In alcuni casi, i tuoi clienti aziendali avranno già sentito parlare di SharePoint in un contesto più semplice quando stanno prendendo in considerazione un'applicazione line-of-business chiave su larga scala, che è il punto in cui di solito inizia il secondo utilizzo di SharePoint. Senza una chiara strategia di adozione aziendale, sarà un viaggio molto lento e arduo per il team tecnico garantire che la propria farm di SharePoint abbia la giusta quantità di adozione e utilizzo.

Nel mio caso, la maggior parte dei siti di SharePoint già creati quando mi è stato presentato SharePoint erano semplicemente siti di collaborazione con raccolte documenti di grandi dimensioni con strutture di cartelle molto complicate e contorte.

Alcuni dei nomi delle cartelle erano in realtà piccole frasi in modo che il team potesse capire esattamente quali tipi di documenti si trovavano nella cartella. Non c'erano tag di metadati, nessun tipo di contenuto, solo semplicemente documenti che si trovavano in cartelle.

L'intero processo di collaborazione è stato la condivisione dei documenti veri e propri. C'era un unico repository in cui tutti potevano condividere documenti e questa era la portata della collaborazione per il team. Questo è ciò che il cliente aziendale ha visto come il più grande valore di SharePoint.

Non c'è da stupirsi che, quando ho iniziato a parlare con le persone dell'azienda, la loro impressione su SharePoint non fosse al massimo entusiasta. Anche alcune delle mie controparti tecniche hanno iniziato a sostenere che avremmo potuto risparmiare una grande quantità di costi se avessimo semplicemente acquistato condivisioni di file per gestire i file e le strutture delle cartelle.

Molte delle funzionalità di base di SharePoint semplicemente non sono state comunicate correttamente alla mia azienda e, in una certa misura, anche al team tecnico. Sono stati venduti su SharePoint come uno straordinario strumento CMS con grandi possibilità per rafforzare la collaborazione e l'innovazione, ma il meglio che siamo riusciti a trovare è stata la condivisione di file.

Durante una delle mie prime interviste all'interno della mia attività, ho scoperto che il motivo di alcune delle lunghe strutture di cartelle era fornire un certo livello di struttura per consentire alle persone di trovare determinati file. L'azienda non era nemmeno a conoscenza delle funzionalità di ricerca di base di SharePoint , per non parlare delle best practice di SharePoint. Avevo bisogno di trovare un modo per coinvolgere i miei clienti aziendali in modo che non solo potessero utilizzare SharePoint in modo più efficiente, ma anche educarli su alcuni dei veri punti di forza della piattaforma.

Presentare un caso aziendale migliore

Sulla base del feedback delle interviste di cui sopra con i clienti aziendali, mi sono reso conto che avrei dovuto ricominciare da capo con l'istruzione. Ma in base alla già grande fattoria di cui disponiamo attualmente, come avrei potuto “ricominciare da capo” quando le cose stavano già andando avanti?

La maggior parte dei siti erano siti di collaborazione in team con raccolte documenti. Quindi ho deciso di iniziare con le raccolte di documenti. Ho chiesto a uno dei miei clienti aziendali di collaborare con me e il mio team alla ristrutturazione delle proprie librerie in un modo che consentisse loro di ridurre al minimo le strutture delle cartelle aumentando al contempo la visibilità per trovare il file giusto che l'utente stava cercando.

Man mano che approfondivamo la struttura di alcuni siti, mi è apparso evidente che le strutture delle cartelle erano in realtà elementi di dati e raggruppamenti dei vari tipi di file su cui il team stava collaborando. Quindi ho deciso di iniziare con una funzionalità di SharePoint molto semplice ma potente: i tag dei metadati.

Ho sempre pensato che uno dei modi più potenti per istruire qualsiasi cliente su una tecnologia fosse semplicemente sviluppare una sorta di POC. Il problema con i POC è che hanno un impatto sui costi. Devi stare attento a non sviluppare completamente un'applicazione per fare in modo che l'azienda decida che non è quello che vuole.

Nel mio caso, il costo era minimo, ma il valore era potenzialmente enorme. Ho deciso di prendere più raccolte documenti, ognuna delle quali aveva 20 o più cartelle separate, e ricrearla come una raccolta documenti con metadati e tipi di contenuto. Piuttosto che cercare di spiegare i tipi di contenuto, è stato più facile mostrare come l'utilizzo di un tipo di contenuto non solo potesse aggiungere alla struttura dei dati, ma anche consentire loro di governare correttamente i metadati aggiuntivi associati a un file.

L'effetto palla di neve

Molti dei file contenevano informazioni importanti e molto utili. L'azienda ha deciso di raggruppare i file utilizzando una struttura di cartelle molto complicata. Ad esempio, avevano una cartella per ciascuno dei loro 15 marchi e all'interno di tali cartelle avevano sottocartelle per marketing, finanza e altre categorie chiave; all'interno di quelle sottocartelle avevano ancora più sottocartelle.

Ciò ha consentito loro di trovare più facilmente uno o più file particolari, piuttosto che dover aprire e visualizzare singoli file. Ma a causa di questa complicata struttura delle cartelle, ora avevano bisogno di un processo aziendale per garantire che ogni file fosse posizionato nella cartella giusta. Come hanno scoperto, il nuovo processo aziendale era semplicemente troppo difficile da gestire e molti file sono finiti nel posto sbagliato.

Questo mi ha permesso di incorporare e spiegare l'uso dei metadati all'azienda. Ho suddiviso la struttura del file in alcuni tipi di contenuto chiave, che abbiamo poi utilizzato per includere elementi di dati chiave, insieme a importanti convalida dei dati. Questo semplice approccio di tipi di contenuto, metadati e convalida dei dati è stato il primo grande successo nel mio viaggio per presentare alla mia azienda un caso aziendale migliore per SharePoint.

Ora che ho avuto l'attenzione dell'azienda, ho deciso di avere una semplice procedura dettagliata della raccolta documenti con le parti interessate chiave. Ho mostrato loro il vero valore dei metadati e dei tipi di contenuto filtrando e ordinando i loro dati.

Con mia grande sorpresa, sono rimasti semplicemente sbalorditi da alcune delle funzionalità di base di SharePoint che non sapevano nemmeno esistessero. Ho quindi deciso di includere una pagina di filtro personalizzata per mostrare loro cosa si poteva fare con una semplice creazione di pagine, web part e filtri.

Sono stato molto attento a non personalizzare completamente nessuna di queste pagine. Volevo usare solo web part OOTB. In questo modo avrebbero una migliore comprensione delle funzionalità di base di SharePoint prima di passare a scenari più complicati. La pagina personalizzata è stata un enorme successo e non avevamo nemmeno discusso delle funzionalità estese che il motore di ricerca avrebbe fornito per loro. Volevo tenere a bada il motore di ricerca fino a quando non avessi avuto una migliore adozione delle basi di SharePoint.

Flussi di lavoro di SharePoint: la chiave

A mio modesto parere, i flussi di lavoro di SharePoint sono stati il ​​fattore più importante nella mia capacità di istruire i miei clienti aziendali e garantire l'adozione e l'utilizzo di SharePoint all'interno della mia organizzazione. I flussi di lavoro sono stati la prima caratteristica che ha attirato la mia attenzione in quel primo VSLive che ho menzionato e hanno contribuito in modo importante al mio primo POC completo di SharePoint che incorporava i nostri processi SDLC.

Quando si tratta di SharePoint, le conversazioni iniziali che ho con i miei clienti aziendali riguardano solitamente i loro processi aziendali. I processi aziendali sono fondamentali per l'utilizzo di SharePoint per aumentare la produttività e ridurre i costi, un aspetto che qualsiasi cliente aziendale è desideroso di discutere.

Come ho detto a molti dirigenti IT senior, posso praticamente garantire l'uso e l'adozione di SharePoint semplicemente attraverso i processi aziendali. Ogni business unit ha processi e la maggior parte di questi processi ha checkpoint o punti di approvazione, ed è qui che i flussi di lavoro tornano utili, sia attraverso l'invio di un'e-mail di approvazione che la creazione di un'attività di approvazione.

Dopo aver convinto un cliente aziendale di come i flussi di lavoro possono migliorare i propri processi e ridurre i costi, lo istruisco su come utilizzare le stesse attività di approvazione per creare accordi sul livello di servizio (SLA) o indicatori chiave di prestazione (KPI).

Quanto sarebbe bello per una business unit capire quanto tempo impiega un documento per essere rivisto e approvato? Potrebbero quindi prendere tali informazioni e adottare una strategia per migliorare il processo generale. Ciò consentirebbe loro di creare KPI per monitorare e governare il processo.

Per mostrare l'impegno dell'alta dirigenza nel miglioramento dei propri processi, potrebbero anche includere i miglioramenti come parte dei loro programmi di obiettivi bonus. Questo è in genere l'home run che convince un cliente aziendale del vero valore che può ottenere attraverso l'adozione e l'uso di SharePoint.

Il futuro

Quando ho sentito parlare per la prima volta di Office 365 e SharePoint Online, ho capito il valore di un ambiente SharePoint ospitato, ma ancora una volta ho faticato a convincere i miei clienti aziendali che questa nuova direzione era la migliore per il loro futuro. Ero entusiasta di sentire parlare di PHA, ma ero anche cauto riguardo al costo potenziale che ciò avrebbe potuto avere dal punto di vista del supporto delle applicazioni.

La mia azienda aveva avviato la direzione di fornitori di sviluppo di terze parti con un modello di outsourcing, che può facilmente portare i fornitori a creare applicazioni aziendali complicate con un grande costo residuo per la manutenzione e i miglioramenti.

Come con ogni modello ospitato, dobbiamo prepararci al cambiamento. Come esseri umani, non ci piace davvero il cambiamento e, come team di supporto tecnico, abbiamo spesso paura del cambiamento e di come influenzerà la capacità del nostro team di andare avanti.

Quando ho sentito parlare per la prima volta della decisione di Microsoft di deprecare InfoPath e poi dell'introduzione di Flow come motore di flusso di lavoro, la mia reazione è stata: "Ci risiamo!" Microsoft avrebbe preso un'altra decisione aziendale che mi avrebbe reso più difficile "vendere" la loro ultima direzione su SharePoint. Quando ho iniziato a rivedere ciò che Flow aveva da offrire, sono rimasto deluso da ciò che ho visto.

Ma Microsoft aveva la sua visione futura e semplicemente non l'ho capita, finché non ho iniziato a vedere alcune delle capacità di Flow per quanto riguarda i punti di integrazione. Flow si integra con molte delle applicazioni esistenti di oggi, ma consente anche a un'azienda di creare i propri punti di integrazione. Questo lo ha reso un attore importante nelle mie discussioni di lavoro sul miglioramento dei processi aziendali attraverso l'integrazione con varie applicazioni line-of-business.

Mobilità

Questo è diventato un argomento di conversazione standard che io, come dirigente tecnico, ho con molti dei miei clienti aziendali. Va bene discutere del responsive web design e di come massimizzarlo per migliorare la loro presenza sul Web mobile. Possiamo anche discutere di come SharePoint utilizza pagine Web reattive per creare una migliore esperienza di SharePoint sui dispositivi mobili. Microsoft ha persino sviluppato un'applicazione mobile di SharePoint. Ma di solito, la discussione va nella direzione di avere un'applicazione mobile autonoma.

Non appena sento le parole "applicazione mobile autonoma", sento il cinguettio di un registratore di cassa: molte applicazioni mobili hanno un'impronta di costo elevata insieme a un modello di supporto specializzato. La mia risposta dal mondo SharePoint è PowerApps.

Come ho fatto in passato, comincio immediatamente a sviluppare un'applicazione mobile PowerApps POC. Utilizza gli elenchi e le raccolte di SharePoint esistenti come origine dati back-end per la mia applicazione. PowerApps è quella che chiamo una piattaforma di sviluppo basata sulla configurazione : consente uno sviluppo molto rapido di applicazioni mobili.

Un utente può semplicemente selezionare l'opzione PowerApps in SharePoint per creare la propria applicazione mobile PowerApps. Crea anche automaticamente molte delle schermate per aggiungere e modificare nuovi elementi in un elenco o in una raccolta. È stato anche testato con tutti gli attuali leader nello spazio dei dispositivi mobili. Ha il suo IDE, insieme a un linguaggio basato sulla configurazione molto semplice che può essere facilmente adattato da uno sviluppatore tecnico o anche da un utente esperto di tecnologia.

Ancora una volta ho un ottimo strumento/funzionalità di SharePoint che posso utilizzare per migliorare l'adozione e l'utilizzo della piattaforma SharePoint. Incorpora questo nuovo strumento con SharePoint e Flow, insieme alle notifiche push e alla possibilità di utilizzare funzionalità intrinsecamente mobili come servizi di localizzazione e telefonate, e PowerApps è diventato il mio nuovo punto di conversazione preferito per discutere con i miei clienti aziendali sull'adozione e l'utilizzo di SharePoint.

In effetti, il mio POC non è stato solo ricevuto con entusiasmo dalla mia azienda, ma a causa del mio utilizzo di funzionalità mobili come i servizi di localizzazione e la navigazione GPS, mi è stato chiesto di presentare la mia applicazione POC all'ingegneria di PowerApps come esempio di cosa si potrebbe fare con il attrezzo.

Da VSLive alle soluzioni SharePoint

Dato che ero seduto al mio posto vicino al finestrino diretto a San Francisco, non avrei mai immaginato come quel semplice viaggio avrebbe avuto un impatto così importante sulla mia carriera tecnica. SharePoint è uno strumento davvero innovativo e collaborativo e Microsoft continua a fornire la propria visione e direzione con SharePoint.

Come tutte le migliaia di soluzioni SaaS o PaaS a nostra disposizione oggi, dobbiamo assicurarci di comprendere veramente come utilizzare al meglio queste soluzioni. Continuando a migliorare i nostri processi aziendali complessivi ea soddisfare i nostri clienti aziendali, SharePoint è diventato uno strumento chiave nel mio arsenale. Attendo con impazienza il futuro e ciò che SharePoint avrà da offrire per me e per la mia attività.