Explorer les avantages commerciaux de SharePoint

Quelqu'un dans votre entreprise s'est-il déjà demandé s'il tirait le meilleur parti de SharePoint ? À première vue, cela semble être une question ridicule. Pourquoi une entreprise mettrait-elle en œuvre SharePoint si elle n'a pas déjà déterminé ses véritables avantages et sa valeur globale ?

Mais dans mes conversations quotidiennes avec d'autres personnes techniques et commerciales, je suis étonné de la fréquence à laquelle ils sont incapables d'identifier et de quantifier le retour sur investissement réel qu'ils voient dans SharePoint. Encore plus étonnant est le nombre d'entreprises qui n'ont pas pleinement utilisé leur environnement SharePoint pour réduire le coût global de l'entreprise et augmenter la productivité.

Les spécificités techniques de SharePoint sont importantes, mais dans cet article, je souhaite partager avec vous plus d'informations sur ce qui manque généralement à la stratégie commerciale des entreprises qui utilisent SharePoint.

Pourquoi utiliser SharePoint : une vision…

Un dimanche de l'hiver 2009, je me suis assis sur mon siège près de la fenêtre, regardant avec impatience un 747. Je me dirigeais vers San Francisco pour assister à ma toute première conférence, VSLive.

À l'époque, je travaillais dans une grande entreprise de cosmétiques. J'étais ravi d'assister aux cours SharePoint auxquels je m'étais inscrit : il s'agissait d'une pile technologique relativement nouvelle au sein de l'entreprise et je voulais voir par moi-même ce que SharePoint pouvait vraiment faire pour l'entreprise.

Je n'ai pas été déçu. J'ai quitté San Francisco avec une telle excitation, un sentiment que je pensais avoir depuis longtemps disparu de ma carrière professionnelle. J'avais tellement hâte de retourner au bureau pour discuter de cet outil incroyable avec mon équipe… seulement pour être ramené à la réalité de mon existence en tant que directeur de l'équipe Global Information Systems :

[Directeur Exécutif – GIS] : « Bien sûr, j'ai entendu parler de SharePoint. Je ne vois pas pourquoi tout ce remue-ménage… Nous pourrions créer les mêmes pages Web au sein de notre propre ferme Web. Je pense que vous perdez votre temps.

[Responsable Relations Entreprises – GIS] : « C'est juste trop simple et moche. Je ne pourrai jamais vendre cela à aucun de mes clients commerciaux.

[Senior Developer – GIS] : « Quel est le problème ? Je ne le vois pas ajouter de valeur. Cela semble bien trop compliqué à travailler. Je pense que Active Server Pages est une bien meilleure direction.

La seule personne à montrer ne serait-ce qu'un peu d'intérêt était le directeur à qui je relevais directement. Il ne connaissait pas grand-chose aux technologies de SharePoint, mais il savait que j'étais bien trop excité à ce sujet pour simplement l'ignorer.

Il m'a demandé d'organiser une courte réunion pour que je discute un peu plus de cette technologie. Cette réunion nous a amenés à concevoir une preuve de concept (POC) SharePoint pour notre haute direction qui deviendrait éventuellement un élément central au sein du département SIG. Cela automatiserait et rationaliserait nos nouveaux processus de cycle de vie de développement logiciel (SDLC) et ouvrirait la voie à l'entreprise en adoptant de nombreux avantages SharePoint, me catapultant au niveau éminent de "The SharePoint Guy". Au cours des huit années suivantes, j'ai passé une grande partie de mon temps dans l'entreprise à utiliser SharePoint comme un formidable outil de productivité à faible coût. Pour ceux qui écouteraient, j'améliorerais de nombreux processus métier et réduirais leurs coûts, mais il y avait encore trop de sites au sein de l'entreprise qui étaient de simples sites d'équipe avec des bibliothèques de documents. J'étais juste une personne, nageant en amont pour vendre SharePoint non seulement à mon entreprise, mais aux niveaux les plus élevés de l'organisation.

Cela vous semble-t-il familier ?

Au cours des neuf dernières années, j'ai observé que les utilisations de SharePoint dans la plupart des entreprises se présentent dans l'un des deux scénarios de base.

1. Sites d'équipe avec bibliothèques de documents

Ces sites sont généralement créés à partir du modèle Team et contiennent une ou plusieurs bibliothèques de documents qui peuvent avoir des structures de dossiers très compliquées. Les types de contenu, les balises de métadonnées ou les workflows sont très peu utilisés. Les sites sont entièrement pris en charge par l'unité commerciale, dont les membres n'ont aucune compréhension formelle de SharePoint et n'ont pas adopté le rôle d'"utilisateur avancé". Le site a été créé par l'équipe d'infrastructure ou de support qui peut rapidement générer un site à partir d'un simple ticket de demande d'assistance.

2. Sites entièrement personnalisés avec une base de code importante et compliquée

Généralement, il s'agit de sites beaucoup plus grands avec un public beaucoup plus large : les intranets d'entreprise, les sites RH et informatiques d'entreprise sont les candidats habituels pour ce type d'utilisation de SharePoint.

Ces projets commencent généralement avec une grande direction et des attentes. Ils sont vendus comme une alternative peu coûteuse à de nombreux systèmes de gestion de contenu (CMS) haut de gamme et coûteux que l'entreprise a déjà étudiés. Ensuite, au fur et à mesure que le projet avance, les exigences se transforment et se compliquent. Il a besoin de plus de code personnalisé, qui finit par devenir suffisamment complexe pour que la prise en charge du code devienne un problème.

À partir de là, les choses deviennent généralement incontrôlables. L'équipe de développement a abandonné l'idée de rester avec des fonctionnalités prêtes à l'emploi (OOTB) avec une base de code limitée. Au lieu de cela, ils ont une approche entièrement personnalisée, allant de pages maîtres entièrement personnalisées à éventuellement une application hébergée par un fournisseur (PHA) ou, comme ils l'appellent maintenant, un complément hébergé par un fournisseur.

Je peux déjà entendre les soupirs et voir les yeux rouler. "Tony, ce sont des approches d'utilisation parfaitement valables." "Nous avons les deux et nos utilisateurs adorent les sites et nous n'avons aucun problème à les prendre en charge." Je ne prétends en aucun cas que l'une ou l'autre de ces méthodes est mauvaise, ni que l'une est avantageuse par rapport à l'autre, mais je crois que les deux approches manquent simplement l'occasion d'utiliser pleinement ce que la plate-forme SharePoint a à offrir.

Je crois en outre que ces deux modèles donnent l'impression aux entreprises que SharePoint est beaucoup trop cher pour l'utilisation qu'elles en font, ou que le service informatique a le sentiment qu'il aurait pu simplement développer la même fonctionnalité via des serveurs Web et des pages HTML ou un CMS en conserve. solution cloud. L'une ou l'autre opinion donne à la fois l'impression à l'entreprise et à l'informatique que SharePoint ne semble pas être l'outil adapté à leurs besoins.

Avantages de SharePoint Gone AWOL ?

Afin que nous puissions mieux comprendre où nous en sommes, nous devons prendre du recul et revoir comment nous en sommes arrivés là.

Je vais vous ramener à la simple question « Comment avez-vous entendu parler de SharePoint ? D'après mon expérience personnelle et l'expérience de nombreux autres responsables informatiques avec qui j'ai parlé, SharePoint en tant que plate-forme technique a été présenté à l'entreprise par l'équipe d'infrastructure avec l'aide de leurs conseillers Microsoft Enterprise.

Habituellement, la première ferme SharePoint est une sorte de banc d'essai qui est donnée à l'entreprise dans le cadre de son accord d'entreprise avec Microsoft. À ce stade, la plupart des entreprises font appel à un client professionnel et déploient leur première collection de sites avec un seul site d'équipe. Le client professionnel adore les bibliothèques de documents et la possibilité de collaborer et de partager des documents. Il commence donc à utiliser le site dans le cadre de ses processus métier.

Cela peut sembler parfaitement acceptable pour beaucoup d'entre vous et, en toute honnêteté, peut être un cas d'utilisation viable pour SharePoint. Mais une fois que vous plongez un peu plus dans SharePoint, vous vous rendez compte qu'il s'agit de bien plus qu'une simple plate-forme que l'équipe d'infrastructure a implémentée et prend en charge : c'est un espace d'application robuste qui nécessite la collaboration étroite des équipes d'infrastructure, d'architecture d'entreprise et d'application.

Je ne suis pas une personne « anti-infrastructure » ​​ou une personne politiquement opposée à l'équipe d'infrastructure, mais sans la collaboration des bons partenaires dès le début, vous courez le risque de ne pas comprendre toute la portée de la plate-forme SharePoint et donc ne sont pas préparés aux stratégies commerciales et au plan d'utilisation appropriés. Cette situation n'est pas unique à la plate-forme SharePoint et pointe vers un problème beaucoup plus vaste de collaboration et de stratégie appropriées, auquel sont confrontés de nombreux services informatiques.

Votre client commercial est la clé

Trop souvent, de nombreuses organisations techniques n'ont absolument aucune stratégie commerciale en ce qui concerne SharePoint. Ils ont simplement un petit processus ajouté à ceux existants sur la façon de demander et de créer un site SharePoint. Ils peuvent même n'inclure aucune sorte de gouvernance autour du processus de création de sites, ce qui peut entraîner un très grand volume de collections de sites et éventuellement un problème de support.

Il peut y avoir une conversation et une formation de base sur l'utilisation de certains des concepts plus larges tels que les collections de sites et la recherche dans SharePoint . Mais les discussions sur la stratégie peuvent devenir très compliquées. Pour cette raison, de nombreuses organisations techniques décident simplement de mettre fin à leur stratégie au processus de création de site. Au lieu de cela, commençons lentement et avec les fonctionnalités de base de SharePoint.

Quels sont vos clients professionnels ? S'agit-il de l'équipe technique de l'entreprise, de votre équipe marketing régionale ou peut-être de l'équipe R&D ? Comme je l'ai indiqué précédemment, la mise en œuvre de SharePoint est généralement lancée par l'équipe d'infrastructure, puis elle se répercute lentement sur la population des clients professionnels.

Dans certains cas, vos clients professionnels auront déjà entendu parler de SharePoint dans un contexte plus simple lorsqu'ils envisagent une application métier clé à grande échelle, là où commence généralement la deuxième utilisation de SharePoint. Sans une stratégie d'adoption commerciale claire, l'équipe technique aura un parcours très lent et ardu pour s'assurer que sa ferme SharePoint a la bonne quantité d'adoption et d'utilisation.

Dans mon cas, la plupart des sites SharePoint déjà créés lorsque j'ai découvert SharePoint étaient simplement des sites de collaboration avec de grandes bibliothèques de documents avec des structures de dossiers très compliquées et alambiquées.

Certains des noms de dossier étaient en fait de petites phrases afin que l'équipe puisse comprendre exactement quels types de documents se trouvaient dans le dossier. Il n'y avait pas de balises de métadonnées, pas de types de contenu, simplement des documents assis dans des dossiers.

L'ensemble du processus de collaboration était le partage des documents réels. Il y avait un référentiel unique où tout le monde pouvait partager des documents et c'était l'étendue de la collaboration pour l'équipe. C'est ce que le client commercial considérait comme la plus grande valeur de SharePoint.

Il n'est pas étonnant que, lorsque j'ai commencé à parler avec les gens de l'entreprise, leur impression de SharePoint était au mieux peu enthousiaste. Même certains de mes homologues techniques ont commencé à affirmer que nous pourrions économiser beaucoup d'argent si nous achetions simplement des partages de fichiers pour gérer les fichiers et les structures de dossiers.

De nombreuses fonctionnalités de base de SharePoint n'étaient tout simplement pas communiquées correctement à mon entreprise et, dans une certaine mesure, même à l'équipe technique. Ils ont été vendus sur SharePoint comme un outil CMS incroyable avec de grandes possibilités pour renforcer la collaboration et l'innovation, mais le meilleur que nous ayons pu proposer était le partage de fichiers.

Au cours de l'un de mes premiers entretiens au sein de mon entreprise, j'ai découvert que la raison de certaines des longues structures de dossiers était de fournir un certain niveau de structure pour que les gens trouvent certains fichiers. L'entreprise n'était même pas au courant des capacités de recherche de base de SharePoint , et encore moins des meilleures pratiques de SharePoint. J'avais besoin de trouver un moyen d'engager mes clients commerciaux afin qu'ils puissent non seulement utiliser SharePoint de manière plus efficace, mais aussi les éduquer sur certains des atouts réels de la plate-forme.

Présenter une meilleure analyse de rentabilisation

Sur la base des commentaires des entretiens ci-dessus avec des clients commerciaux, j'ai réalisé que je devrais tout recommencer avec l'éducation. Mais sur la base de la ferme déjà grande que nous avions actuellement, comment allais-je pouvoir "recommencer" alors que les choses avançaient déjà ?

La plupart des sites étaient des sites de collaboration d'équipe avec des bibliothèques de documents. J'ai donc décidé de commencer par les bibliothèques de documents. Un de mes clients professionnels a accepté de travailler avec moi et mon équipe pour restructurer leurs bibliothèques de manière à leur permettre de minimiser les structures de dossiers tout en augmentant la visibilité de la recherche du bon fichier que l'utilisateur recherchait.

Au fur et à mesure que nous approfondissions la structure de certains sites, il m'est apparu évident que les structures de dossiers étaient en fait des éléments de données et des regroupements des différents types de fichiers sur lesquels l'équipe collaborait. J'ai donc décidé de commencer par une fonctionnalité très basique, mais puissante, de SharePoint : les balises de métadonnées.

J'ai toujours pensé que l'un des moyens les plus puissants d'éduquer un client sur une technologie consistait simplement à développer une sorte de POC. Le problème avec les POC est qu'ils ont un impact sur les coûts. Vous devez faire attention à ne pas développer complètement une application pour que l'entreprise décide que ce n'est pas ce qu'elle veut.

Dans mon cas, le coût était minime, mais la valeur était potentiellement énorme. J'ai décidé de prendre plusieurs bibliothèques de documents, chacune contenant au moins 20 dossiers distincts, et de les recréer en une seule bibliothèque de documents avec des métadonnées et des types de contenu. Plutôt que d'essayer d'expliquer les types de contenu, il était plus facile de montrer comment l'utilisation d'un type de contenu pouvait non seulement ajouter à la structure des données, mais aussi leur permettre de gérer correctement les métadonnées supplémentaires associées à un fichier.

L'effet boule de neige

De nombreux fichiers contenaient des informations importantes et très utiles. L'entreprise a décidé de regrouper les fichiers en utilisant une structure de dossiers très compliquée. Par exemple, ils avaient un dossier pour chacune de leurs 15 marques, et dans ces dossiers, ils avaient des sous-dossiers pour le marketing, la finance et d'autres catégories clés ; dans ces sous-dossiers, ils avaient encore plus de sous-dossiers.

Cela leur avait permis de trouver plus facilement un ou plusieurs fichiers particuliers, plutôt que d'avoir à ouvrir et à afficher des fichiers individuels. Mais en raison de cette structure de dossiers compliquée, ils avaient désormais besoin d'un processus métier pour s'assurer que chaque fichier était placé dans le bon dossier. Comme ils l'ont découvert, le nouveau processus métier était tout simplement trop difficile à gérer et de nombreux fichiers se sont retrouvés au mauvais endroit.

Cela m'a permis d'intégrer et d'expliquer l'utilisation des métadonnées à l'entreprise. J'ai décomposé la structure du fichier en quelques types de contenu clés, que nous avons ensuite utilisés pour inclure des éléments de données clés, ainsi qu'une validation de données importante. C'est cette approche simple des types de contenu, des métadonnées et de la validation des données qui a été le premier succès majeur de mon parcours pour présenter à mon entreprise une meilleure analyse de rentabilisation pour SharePoint.

Maintenant que j'avais l'attention de l'entreprise, j'ai décidé d'avoir une présentation simple de la bibliothèque de documents avec les principales parties prenantes. Je leur ai montré la vraie valeur des métadonnées et des types de contenu en filtrant et en triant leurs données.

À ma grande surprise, ils ont été tout simplement impressionnés par certaines des fonctionnalités de base de SharePoint dont ils ignoraient même l'existence. J'ai ensuite décidé d'inclure une page de filtre personnalisée pour vraiment leur montrer ce qui pouvait être fait avec une simple création de page, des composants WebPart et un filtrage.

J'ai fait très attention à ne personnaliser entièrement aucune de ces pages. Je voulais utiliser uniquement des composants WebPart OOTB. De cette façon, ils auraient une meilleure compréhension des fonctionnalités de base de SharePoint avant que je ne passe à des scénarios plus compliqués. La page personnalisée a été un énorme succès et nous n'avions même pas discuté des capacités étendues que le moteur de recherche leur fournirait. Je voulais attendre sur le moteur de recherche jusqu'à ce que j'aie mieux adopté les bases de SharePoint.

Flux de travail SharePoint : la clé

À mon humble avis, les flux de travail SharePoint ont été le facteur le plus important dans ma capacité à éduquer mes clients commerciaux et à assurer l'adoption et l'utilisation de SharePoint au sein de mon organisation. Les flux de travail ont été la première fonctionnalité qui a attiré mon attention lors de ce premier VSLive que j'ai mentionné, et ils ont été un contributeur majeur à mon premier POC SharePoint complet qui incorporait nos processus SDLC.

En ce qui concerne SharePoint, les premières conversations que j'ai avec mes clients commerciaux portent généralement sur leurs processus métier. Les processus métier sont essentiels à l'utilisation de SharePoint pour augmenter la productivité et réduire les coûts, ce dont tout client commercial est impatient de discuter.

Comme je l'ai dit à de nombreux cadres supérieurs de l'informatique, je peux pratiquement garantir l'utilisation et l'adoption de SharePoint simplement par le biais de processus métier. Chaque unité commerciale a des processus, et la plupart de ces processus ont des points de contrôle ou des points d'approbation, et c'est là que les flux de travail sont utiles, que ce soit par l'envoi d'un e-mail d'approbation ou la création d'une tâche d'approbation.

Une fois que j'ai convaincu un client commercial de la façon dont les flux de travail peuvent améliorer ses processus et réduire ses coûts, je l'informe ensuite sur la façon dont il peut utiliser ces mêmes tâches d'approbation pour ensuite créer des accords de niveau de service (SLA) ou des indicateurs de performance clés (KPI).

Serait-il formidable pour une unité commerciale de comprendre combien de temps il faut pour qu'un document soit examiné et approuvé ? Ils pourraient alors prendre ces informations et adopter une stratégie pour améliorer le processus global. Cela leur permettrait ensuite de créer des KPI pour surveiller et gouverner le processus.

Pour montrer l'engagement de la haute direction à l'amélioration de leurs processus, ils pourraient même inclure les améliorations dans le cadre de leurs programmes d'objectifs de bonus. C'est généralement le coup de circuit qui convainc un client commercial de la véritable valeur qu'il peut obtenir grâce à l'adoption et à l'utilisation de SharePoint.

L'avenir

Lorsque j'ai entendu parler d'Office 365 et de SharePoint Online pour la première fois, j'ai compris la valeur d'un environnement SharePoint hébergé, mais encore une fois, j'ai eu du mal à convaincre mes clients professionnels que cette nouvelle direction était la meilleure pour leur avenir. J'étais ravi d'entendre parler des PHA, mais j'étais également prudent quant au coût potentiel que cela pourrait avoir du point de vue du support des applications.

Mon entreprise avait commencé par suivre la direction de fournisseurs de développement tiers avec un modèle d'externalisation, ce qui peut facilement amener les fournisseurs à créer des applications métier complexes avec un coût résiduel important pour la maintenance et les améliorations.

Comme pour tout modèle hébergé, nous devons nous préparer au changement. En tant qu'êtres humains, nous n'aimons vraiment pas le changement, et en tant qu'équipes de support technique, nous avons souvent peur du changement et de la façon dont il affectera la capacité de notre équipe à aller de l'avant.

Lorsque j'ai entendu parler pour la première fois de la décision de Microsoft de déprécier InfoPath, puis de l'introduction de Flow en tant que moteur de flux de travail, ma réaction a été : « C'est reparti ! Microsoft allait prendre une autre décision commerciale qui rendrait plus difficile pour moi de « vendre » leur nouvelle direction SharePoint. Alors que je commençais à examiner ce que Flow avait à offrir, j'ai été déçu par ce que j'ai vu.

Mais Microsoft avait sa vision de l'avenir, et je ne l'ai tout simplement pas comprise, jusqu'à ce que je commence à voir certaines des capacités de Flow en ce qui concerne les points d'intégration. Flow s'intègre à de nombreuses applications existantes d'aujourd'hui, mais il permet également à une entreprise de créer ses propres points d'intégration. Cela en a fait un acteur majeur dans mes discussions commerciales sur l'amélioration des processus commerciaux grâce à l'intégration avec diverses applications métier.

Mobilité

C'est devenu un sujet de conversation standard que j'ai, en tant que cadre technique, avec bon nombre de mes clients commerciaux. Il n'y a rien de mal à discuter de la conception de sites Web réactifs et de la manière de l'optimiser pour améliorer leur présence sur le Web mobile. Nous pouvons également discuter de la manière dont SharePoint utilise des pages Web réactives pour créer une meilleure expérience SharePoint sur les appareils mobiles. Microsoft a même développé une application SharePoint mobile. Mais généralement, la discussion se dirige vers une application mobile autonome.

Dès que j'entends les mots « application mobile autonome », j'entends le bruit d'une caisse enregistreuse : de nombreuses applications mobiles ont un coût élevé ainsi qu'un modèle de support spécialisé. Ma réponse du monde SharePoint est PowerApps.

Comme je l'ai fait par le passé, j'ai tout de suite commencé à développer une application PowerApps POC mobile. Il utilise des listes et des bibliothèques SharePoint existantes comme source de données principale pour mon application. PowerApps est ce que j'appelle une plate-forme de développement basée sur la configuration : elle permet un développement très rapide d'applications mobiles.

Un utilisateur peut simplement sélectionner l'option PowerApps dans SharePoint pour créer sa propre application mobile PowerApps. Il crée même automatiquement de nombreux écrans pour ajouter et modifier de nouveaux éléments dans une liste ou une bibliothèque. Il a également été testé avec tous les leaders actuels dans le domaine des appareils mobiles. Il possède son propre IDE, ainsi qu'un langage très simple basé sur la configuration qui peut être facilement adapté par un développeur technique ou même un utilisateur expérimenté averti.

Une fois de plus, j'ai un excellent outil/fonctionnalité de SharePoint que je peux utiliser pour améliorer l'adoption et l'utilisation de la plateforme SharePoint. Intégrez ce nouvel outil à SharePoint et Flow, ainsi que des notifications push et la possibilité d'utiliser des fonctionnalités intrinsèquement mobiles telles que les services de localisation et les appels téléphoniques, et PowerApps est devenu mon nouveau point de conversation préféré pour discuter avec mes clients professionnels de l'adoption et de l'utilisation de SharePoint.

En fait, mon POC a non seulement été accueilli avec impatience par mon entreprise, mais en raison de mon utilisation de fonctionnalités mobiles telles que les services de localisation et la navigation GPS, on m'a demandé de présenter mon application POC à l'ingénierie PowerApps comme exemple de ce qui pourrait être fait avec le outil.

De VSLive aux solutions SharePoint

Alors que j'étais assis sur mon siège près de la fenêtre en direction de San Francisco, je n'aurais jamais pu imaginer à quel point ce simple voyage aurait un impact aussi important sur ma carrière technique. SharePoint est un outil véritablement innovant et collaboratif, et Microsoft continue de concrétiser sa vision et sa direction avec SharePoint.

Comme toutes les milliers de solutions SaaS ou PaaS dont nous disposons aujourd'hui, nous devons nous assurer que nous comprenons vraiment comment utiliser au mieux ces solutions. Continuant d'améliorer nos processus d'affaires globaux et de satisfaire nos clients d'affaires, SharePoint est devenu un outil clé dans mon arsenal. J'attends avec impatience l'avenir et ce que SharePoint aura à offrir pour moi et mon entreprise.