• FR
  • EN
  • NL
  • DE
AEROW
  • AEROW
    • Le Groupe
    • La vie chez AEROW
  • Nos Offres
    • ECM
    • Digital
  • Nos Implantations
    • AEROW SWISS
    • AEROW BENELUX
    • AEROW ECM WORLD LTD
  • Nous Rejoindre
  • Contacts
  • Partenaires
    • BOX
    • NUDGE APM
    • APPDYNAMICS
    • DYNATRACE
    • MICROFOCUS – HPE
    • Neotys
    • OPENTEXT
    • MICROSOFT
  • COMMUNICATION
    • Le BLOG
    • Nos Vidéos
  • AEROW
    • Le Groupe
    • La vie chez AEROW
  • Nos Offres
    • ECM
    • Digital
  • Nos Implantations
    • AEROW SWISS
    • AEROW BENELUX
    • AEROW ECM WORLD LTD
  • Nous Rejoindre
  • Contacts
  • Partenaires
    • BOX
    • NUDGE APM
    • APPDYNAMICS
    • DYNATRACE
    • MICROFOCUS – HPE
    • Neotys
    • OPENTEXT
    • MICROSOFT
  • COMMUNICATION
    • Le BLOG
    • Nos Vidéos

Tag : Sharepoint

Powell 365 : Concentrateur de productivité

by Zaira Banguyon 30 août 2017in Consultant, ECM

Avec le récent partenariat conclu entre AEROW et Expertime dans la cadre de la solution Powell 365, j’ai eu la grande opportunité de porter le premier projet de mise en place d’une « digital workplace » SharePoint pour un client spécialisé dans l’assurance en ligne, découvrez en quoi Powell 365 peut révolutionner la conception de vos intranets (…)

Continue Reading
[IMG] SharePoint_BI

La BI dans SharePoint

by Zaira Banguyon 19 mai 2017in Consultant, Decision

SharePoint est un outil collaboratif ayant de multiples fonctionnalités, une méconnue est la brique BI. En effet, on retrouve plusieurs outils dans SharePoint permettant de rendre la BI plus coll…

Continue Reading
Webinar_K2

[WEBINAR] : Comment répondre à vos enjeux métiers en environnements Microsoft avec K2 ?

by Zaira Banguyon 21 mars 2017in ECM, ECM WORLD LTD No comment

K2 édite une plateforme « Low-code » pour concevoir et faire évoluer sans développement des applications basées sur les processus métiers. AEROW vous propose un Webinar sur le thème : « Comment répondre à vos enjeux métiers en environnements Microsoft avec K2 ? », animé par Guillaume Macouin et Nathalie Poidevin.

Continue Reading
Connecteurs_O365_Img

Comment utiliser les connecteurs Office 365 ? Exemple avec un connecteur pour TeamMood

by Zaira Banguyon 24 février 2017in Consultant, ECM, ECM WORLD LTD, GSO

Fonctionnement, limites, et un exemple de ce qu’on peut en faire.

Quelques mots sur Office 365

Résultat de recherche d'images pour "office365"Pour ceux qui pensent encore que la suite Office se résume à Word, Excel et PowerPoint pour faire de belles présentations ou rédiger ses documents, cet article pourra vous faire changer d’avis. Office 365 regroupe maintenant plusieurs applications et outils permettant à une équipe de collaborer sur des documents, des notes ou encore de créer des chaines de discussions autour de certains sujets. Cette collaboration se base sur la notion de groupes ou d’équipe (Office 365 Groups and Teams).

 

Les connecteurs Office

Microsoft a annoncé récemment la sortie des connecteurs Office 365 (Office 365 Connectors), une nouvelle expérience de collaboration qui permet à des services externes d’interagir avec les groupes Office365.

Actuellement, les connecteurs permettent de faire des Push vers Office Groups ou vers Microsoft Teams, donc la possibilité de recevoir des notifications et du contenu depuis l’extérieur vers son espace de collaboration Microsoft, et être au courant des événements importants sur ces outils sans quitter son espace de travail et sans devoir se connecter sur plusieurs services dans la journée.

·       Sur Office Groups le connecteur envoie une notification sous forme d’une nouvelle conversation.

·       Sur Microsoft Teams le connecteur démarre une discussion sur un Canal (Channel) qui peut être par exemple dédié à un sujet bien précis.

L’équipe peut ensuite discuter autour de la notification si nécessaire ou aimer la publication.

Notre Cas d’utilisation : Intégration de TeamMood dans Office 365 à l’aide d’un connecteur.

Il était une fois chez AEROW GSO

Chez AEROW GSO on utilise TeamMood depuis un moment, ce service permet aux membres de l’équipe de donner un Feedback anonyme sur la journée passée sous forme de Moods en smiley (Bonne Journée, Journée normale, mauvaise journée…). Il est ensuite possible de consulter les statistiques sur le site pour suivre les résultats de l’équipe.

Nicolas, le créateur de TeamMood nous a rendu visite à AEROW Toulouse, nous est alors venu l’idée de créer un connecteur Office 365 pour TeamMood.

Vu que nous utilisons Office Teams et Office Groups comme espaces de travail collaboratifs pour nos projets client et pour nos activités internes, nous avons pensé qu’il sera utile de recevoir les statistiques TeamMood des derniers jours directement sur Microsoft Teams, nous donnant ainsi la possibilité de les commenter pour éventuellement identifier un problème ou au contraire voir que tout va bien.

Donc c’était une opportunité de tester le fonctionnement de ces nouveaux connecteurs et vérifier les possibilités offertes, les limites et les difficultés d’intégration.

 

Et Comment ça fonctionne ?

·       Les connecteurs Office 365 sont basés sur des « WebHooks », pour ne pas rentrer dans des détails complexes, on peut dire que c’est une sorte d’API Microsoft qui permet de souscrire à des événements déclenchés par des services externes et de recevoir du contenu depuis ces services.

·       La communication avec un connecteur Office 365 est unidirectionnelle : De l’application externe vers Office. Il est donc possible de déclencher des notifications ou d’envoyer du contenu vers Groups ou Teams, mais le connecteur ne peut pas envoyer d’informations vers les services externes.

·       Les données arrivent avec un format (JSON) qui décrit comment le contenu doit être affiché sur Teams ou Groups, l’affichage personnalisé est appelé « Connector Card ». Il est possible d’afficher du texte évidemment mais aussi des images, des boutons d’action ou des liens web.

·       Pour activer un connecteur dans Groups ou dans un Channel de Microsoft Teams, il est possible de l’ajouter depuis Office Store, il est aussi possible que le service externe intègre un bouton qui ressemble à celui ci-dessous, pour se connecter directement à Office, et sélectionner le groupe souhaité depuis n’importe quelle page web. Quel que soit la méthode utilisée, Office renvoie ensuite quelques informations au service externe comme l’URL à appeler pour envoyer vers le connecteur le contenu à afficher.

Difficultés et limites

Nous nous sommes rendus compte durant la construction du connecteur qu’il y a certaines limites à leur utilisation, surtout au niveau du visuel, nous avons dû revoir le design du « Connector Card » à plusieurs reprises, car à chaque fois c’était soit impossible à réaliser, soit l’affichage dans Teams est très loin de ce qui est prévu par la documentation Microsoft. Voici alors les limites actuelles du système :

·       Certaines fonctionnalités d’affichage ne sont pas encore disponibles sur Teams, le rendu est parfois non stable, l’affichage des Cards sur Outlook (Groups) reste par contre très correct.

·       La personnalisation de l’affichage du contenu est assez limitée, il n’est pas possible par exemple d’utiliser de l’HTML ou du CSS spécifique pour le personnaliser.

·       Il n’est pas possible de récupérer le contexte actuel pour afficher des informations spécifiques par utilisateur.

La solution retenue

Après quelques itérations voici à quoi vont ressembler les notifications envoyées par TeamMood vers Office 365, le service est en cours de développement et sera bientôt disponible.

Rendu du message sur Groups (Via Outlook)

Rendu du message sur Microsoft Teams.

Nous pouvons remarquer que ce dernier est plus basique par rapport à Outlook, Teams est encore à ses débuts et les choses risquent d’évoluer très vite dans le futur.


Conclusion

Nicolas, étant un expert des méthodes de Lean Startup, nous avancerons doucement mais sûrement dans l’adoption et l’amélioration de l’intégration Office 365 et TeamMood avec les utilisateurs clés de TeamMood. L’occasion pour nous de parfaire nos compétences sur un cas concret qui permet d’imaginer et d’exploiter divers types d’intégration. Et bien-sûr avec le plaisir de rendre service dans un échange de bons procédés.


–

Article rédigé par Mohamed El Hattami, Ingénieur Logiciel chez AEROW GSO

Continue Reading
Visu_Post

PowerShell DSC sans modération !

by Zaira Banguyon 31 mai 2016in Non classé

DSC en deux mots

Vous cherchez un moyen d’automatiser vos installations SharePoint ? Vous en avez marre de répéter 50 fois les mêmes actions, et vous commencez à avoir des crampes aux doigts à force de configurer vos services applicatifs à la main ? DSC (Desired State Configuration) est fait pour vous ! Et cerise sur le gâteau, c’est du PowerShell !

Selon la Bible technet, DSC est « une plateforme de gestion en PowerShell » (hum). « Il permet le déploiement et la gestion des données de configuration pour les services et l’environnement sur lequel ces services doivent s’exécuter. ». Pour faire simple, DSC permet d’appliquer une configuration spécifique sur un environnement donné (e.g. IIS et ASP.NET 4.5 sur un Windows Server 2012 R2). Il est important de noter qu’un script DSC est idempotent, c’est-à-dire qu’il peut être joué autant de fois qu’on le souhaite et que le résultat final (i.e. la configuration appliquée) sera toujours le même.

DSC dispose de deux modes de fonctionnement : Push et Pull. Le premier consiste à « pousser » ponctuellement une configuration sur un ou plusieurs serveurs. Le Pull repose sur un service web qui va être consommé par des machines afin de s’assurer qu’elles sont dans l’état de configuration attendu, et appliquer cette configuration le cas échéant.

Les ressources DSC

La force de PowerShell DSC réside dans les modules qui le composent. Ces modules (ressources DSC) sont les briques qui permettent d’appliquer la configuration désirée. On dispose déjà de certaines ressources DSC par défaut (e.g. File pour faire une simple copie de fichier, ou encore WindowsFeature pour rajouter des rôles / fonctionnalités à un serveur). En plus de cela, une vaste communauté portée par l’équipe PowerShell Microsoft (https://github.com/PowerShell) rédige et maintient des ressources DSC spécifiques qui permettent d’enrichir les modules intégrés par défaut (ex :xComputerManagement pour renommer un serveur ou le joindre à un domaine, ou encore xActiveDirectory pour créer un AD ou des utilisateurs de domaine).

Et SharePoint dans tout ça ?

Comble du bonheur, il existe une ressource DSC spécifique pour SharePoint (https://github.com/PowerShell/xSharePoint/tree/dev). Ce module est particulièrement abouti, et permet l’installation de SharePoint 2013 / 2016 de bout en bout avec en prime la possibilité de configurer les services applicatifs, les web apps, site collections… etc. Le GitHub xSharePoint (lien ci-dessus) dispose par ailleurs d’exemples qui permettent d’appréhender simplement l’outil. De plus, les développeurs qui prennent part au projet sont très réactifs, et n’hésiterons pas à vous répondre si vous leur soumettez des bugs / requêtes !

Le mot de la fin

J’ai eu l’occasion de tester à plusieurs reprises AutoSPInstaller, qui permet de scripter l’installation et la configuration de SharePoint. C’est un super outil, il est important de le mentionner. Mais pouvoir intégrer l’installation de SharePoint au sein d’un « workflow » DSC, standardisé, qui permet, en outre, d’installer un AD, de créer des comptes de services, et d’installer SQL Server (pour une VM de développement par exemple), je dois le dire, est un plaisir de fin gourmet.

 

Antoine Larzilliere

Un article rédigé par Antoine Larzilliere, consultant SharePoint au sein d’AEROW GSO.

Retrouvez l’article original sur Linkedin.

Continue Reading
besoin

Le Besoin, ce petit mot qui vous veut du bien

by Zaira Banguyon 28 décembre 2015in Annonces, Consultant, Digital, ECM, ECM WORLD LTD

L’étude du « besoin » est une notion que l’on retrouve de manière récurrente dans la relation client/fournisseur. Elle est la première étape – et de loin l’une des plus importantes – d’un projet et ne doit surtout pas être négligée. 

Cette étape permet notamment d’identifier précisément le travail à faire correspondant à des attentes métiers et peut déterminer le succès ou l’échec d’un projet.
Néanmoins il n’est pas rare de rencontrer des difficultés lors des expressions de besoin car il existe parfois un décalage entre ce qui est dit et ce qui est compris, c’est ce décalage qui peut engendrer ce type de situation :

 

 

Un besoin, c’est quoi ?

Oui, cette notion peut sembler quelque peu basique, mais il est important de comprendre ce qu’est un besoin dans le cadre d’un système d’informations.

« Un besoin représente la traduction d’une nécessité fonctionnelle constituant un gain de valeur relatif pour la ou les personnes qui en font l’expression »

Lorsque l’on parle de besoin, il faut nécessairement parler de VALEUR, celle-ci peut être totalement objective ou totalement subjective, néanmoins elle doit toujours motiver le besoin.
Avoir une valeur ajoutée nécessite la quantification de celle-ci d’un point de vue métier : diminuer un risque d’erreur, gagner X minutes de traitement …
Un besoin correctement exprimé n’est lié à aucune technologie, car les solutions et les technologies changent mais les besoins, eux, restent.

Et avec SharePoint, ça se passe comment ?

Dans un premier temps, il faut se pencher sur la façon dont SharePoint est souvent amené dans l’entreprise. En effet le choix de SharePoint est souvent issu de réflexions autour de grands domaines génériques tels que :

  • La gestion électronique de documents
  • Les outils collaboratifs
  • Les réseaux sociaux
  • …

Le choix de SharePoint est donc fait avant même de connaitre les besoins réels des utilisateurs car sa souplesse de configuration permettra de répondre à nombre de projets dans l’entreprise. Dans ce contexte, nous pouvons voir des directions métier réfléchir de la manière suivante :

« J’ai vu dans un autre service qu’on pouvait faire telle ou telle chose avec SharePoint, je vais donc trouver un besoin pour pouvoir exploiter cette fonctionnalité aussi ! »

On peut comprendre dans ce cas que les utilisateurs et les directions soient frustrées de ne pas utiliser pleinement les capacités de l’outil. Mais cela ne signifie pas forcément de se créer des nouveaux besoins car SharePoint est capable de vous faire gagner du temps mais également de vous en faire perdre.

En effet, SharePoint, contrairement à une solution entièrement développée de A à Z ne pourra répondre à 100% de vos besoins. Il sera alors temps de faire descompromis !

Un besoin doit toujours conditionner le moyen, jamais l’inverse. Il faudra donc trouver un juste milieu entre les possibilités de l’outil et vos besoins.

  • Si il y a beaucoup de développements spécifiques à implémenter, peut-être que SharePoint n’est pas l’outil idéal ou que vous ne traitez pas le besoin fondamental.
  • Si, en revanche, vous vous efforcez d’utiliser toutes les fonctionnalités de SharePoint, peut-être que vous vous éloignez des besoins réels de vos utilisateurs.

Dans les deux cas, le fait de s’éloigner de la réalité de travail quotidien des utilisateurs risque de freiner très fortement l’adoption de votre solution.
Il est également important d’accompagner les personnes en charge de l’expression des besoins afin qu’elles ne se cantonnent pas à répondre à un simple inventaire des besoins, un « Quoi » (Ex : « J’ai besoin de sites de gestion de projet ») sans préciser le « Qui » et le « Pourquoi ».

Une question de point de vue

Une bonne définition des besoins prend du temps, y compris sur SharePoint. Elle est rarement efficace lorsqu’elle est faite sur un coin de table. C’est d’autant plus vrai dans les grandes entreprises. Malheureusement plus elles sont importantes plus les veilles habitudes ont la vie dure, il faudra donc batailler sur ces explications avec votre client :

  • Prendre du temps en début de projet pour « retravailler » ses besoins afin d’avoir quelque chose d’exploitable. Ce temps est rarement prévu dans les enveloppes budgétaires d’un projet, le challenge est de justifier que cette phase « d’audit » devra être facturée.
  • Le temps alloué à cet exercice permettra de réaliser une solution qui répondra précisément aux besoins métier et donc de faire des économies de budget et de temps.
  • Rester au plus près du standard de l’outil vous conférera plus d’agilité
  • L’implication et la disponibilité du client lors de cette phase est primordiale.

19787c6

 

Article rédigé par Kévin REVEL, Project manager and SharePoint expert chez AEROW.

Retrouvez cet article sur Linkedin : Lien vers l’article

 

Continue Reading
figures-1010678

SharePoint, développements et performance

by Zaira Banguyon 23 décembre 2015in BENELUX, Consultant, ECM, ECM WORLD LTD, SWISS No comment

SharePoint, développement et performance ne sont pas des concepts incompatibles. S’il n’est pas rare que « fin de projet » rime avec « chantier d’optimisation » ou encore « taskforce », cela résulte plus souvent de manquements durant la conception que de la technologie en elle-même.

Une chose est sûre (et cela est applicable à tout projet logiciel) : la performance se réfléchit, se pense et se conçoit dès le début.

Définir les critères d’acceptabilité de la performance

La première action à mener est de qualifier la performance par des critères objectifs et chiffrés. C’est ainsi que des indicateurs tels que « temps de réponse de pages » (comprendre le temps que met l’application à envoyer une page à votre navigateur), en utilisation normale ou en pic de charge, doivent être définis en amont de toute activité. Ils constitueront les critères d’acceptabilité de la performance de l’application.

Définir l’utilisation de l’application

Une fois ces objectifs établis, il conviendra d’établir des hypothèses qualifiant l’activité attendue pour l’application. En effet, un portail intranet pour 50 utilisateurs n’impose pas les mêmes précautions que la mise en place d’un site internet world wide affichant plus de 100 000 visiteurs uniques par jour.

On cherchera alors à définir :

  • Combien d’utilisateurs cibles utiliseront l’application
  • La répartition sur une journée « type » des utilisateurs de l’application
  • Les usages auxquels est destinée l’application (recherche, affichage de pages, contribution documentaire, etc…)
  • En somme, tout ce qui doit permettre de conceptualiser et d’anticiper l’usage de l’application, et les différents services pour lesquels une attention particulière devra être apportée.

En général, suite à ces travaux, on pourra définir l’architecture de la plateforme, ou plus simplement : Combien de serveurs, quels rôles pour chaque serveur, etc…

La communication entre IT et Développeurs : indispensable

Etablir des relations entre équipe IT (appelés communément « infras ») et équipe projet (appelés les « dévs ») est un atout pour assurer la cohérence de votre projet. Chaque équipe a son expérience, ses activités, ses idées préconçues sur l’autre équipe… et pourtant leurs expertises sont complémentaires.

Ne demandez pas à un développeur de parler I/O disque, ne demandez pas à un IT de parler JQuery… mais sensibilisez chacune des parties aux contraintes de l’autre, et vous serez surpris par le nombre d’écueils qui seront évités.

En résumé, impliquer chacune des parties dès la phase de conception, créer des vecteurs de communication dépassant les phases de validation, permettre l’échange sans jugement de valeur: Etablir une synergie entre ces expertises couvrant l’ensemble des tenants et des aboutissants de votre projet.

L’architecte : pièce maitresse de votre projet

Il n’existe pas une seule définition du rôle d’architecte.

Je le résumerais ainsi : Garant de la cohérence de tous les aspects techniques de votre projet ; du respect des contraintes, des objectifs et des attentes du métier.

Concrètement, quel doit être le rôle de votre « architecte » pour la performance ?

Il ne peut pas tout savoir, c’est vrai. Il ne peut pas tout concevoir, c’est sûr. Mais il doit être capable de comprendre, de voir, d’anticiper… Il est indispensable, par exemple, qu’il puisse, à partir d’une expression de besoins (qui parfois se traduiront par des spécifications fonctionnelles…), prédire quelles seront les briques mises à contribution, les points d’attention, les risques.

In fine, il doit mettre en corrélation « usages de l’application », « hypothèses d’utilisation », « expression de besoin », « technologie », et ainsi définir l’architecture la plus à même de satisfaire à tous ces aspects.

Connaître SharePoint, rechercher l’efficacité et être pragmatique

Si votre lecture vous amène jusqu’à ces quelques lignes, vous avez pu vous apercevoir que tout ce qui est expliqué ici peut s’appliquer à n’importe quel projet applicatif, à n’importe quelle technologie.

Parlons donc un peu « SharePoint ».

Encore et toujours, deux faces d’un même projet : Infrastructure et Développement.

Deux chantiers liés, présentant des dépendances, et devant donc être cohérents, en particulier durant la phase de conception.

Le design d’une infrastructure SharePoint doit prendre en compte les développements qu’elle va héberger. Inversement, la conception d’une application ne peut pas faire abstraction de l’infrastructure sur laquelle elle repose.

Mon expérience m’amène à penser que la conception de l’application doit être initiée en amont. C’est elle qui permettra d’identifier les contraintes et les besoins de la plateforme tels que les services SharePoint nécessaires (ex : la recherche) et la manière dont ils seront sollicités. Par exemple, une ferme hébergeant une application de type « Search Driven Architecture » (application conduite par la recherche) ne présentera pas la même architecture qu’une application de GED collaborative, disposant d’un centre de recherche.

L’un des facteurs fondamentaux devant assurant la performance de votre application : être pragmatique, à la recherche constante d’efficacité.

Cela se traduira par :

  • Challenger les expressions de besoin présentant un risque technique, dans le but d’assurer leur criticité au regard des impacts potentiels,
  • Assurer son devoir de conseil lorsque l’on anticipe qu’une fonctionnalité native du produit ne sera pas en mesure de répondre à l’usage envisagé,
  • Ne pas hésiter à penser la mise en œuvre de scénarios fonctionnels pouvant atteindre les limites du produit sur une brique tierce,
  • Penser à des mécanismes de cache applicatif (mémoire, cache redis, base SQL, etc…)

Enfin, pour parler purement SharePoint, espérer tirer le meilleur parti de la technologie sans discuter de concepts tels que Blob Cache, Object Cache, Ouput Cache est illusoire. D’ailleurs, au-delà d’en discuter, connaître leur opportunité, leurs contraintes, leurs limites… et en quoi ils vont influencer la conception des développements.

Valider la performance

Enfin, comment valider la performance ?

Quel que soit votre choix, vous vous devez de disposer d’un outillage vous permettant de procéder à différentes campagnes de tests de charge et performance.

SharePoint étant un progiciel, reposant sur une infrastructure, il sera nécessaire d’établir une base de référence. On entend ici le fait de procéder à l’exécution d’une campagne de test, présentant un plan de montée en charge similaire à vos hypothèses, mais ne sollicitant que des composants « standards » du produit sur un environnement vierge de toute application développée.

Vous aurez ainsi :

  • Etabli un bilan de santé de l’infrastructure, hors de toute couche applicative supplémentaire, et donc valider ses performances
  • Une grille de comparaison utile lorsque vous procéderez à des campagnes de tests sur votre application
  • Vous pourrez ensuite mener les campagnes de tests et analyses nécessaires pour estimer si vos ambitions de performance sont atteintes.

Si cette démarche n’exclut pas de devoir conduire des « chantiers d’optimisation » en fin de projet, mon expérience, basée sur la mise en œuvre d’applications reposant sur SharePoint à destination de plus de 50.000 utilisateurs aux quatre coins du monde (organisme d’état, grand groupe français dans le domaine du luxe, …), m’amène à la considérer comme un garde-fou permettant d’éviter de nombreux écueils. Elle assure surtout de ne pas avoir à « tout refaire » à deux semaines de l’ouverture en production.

 

GuillaumeVincent

 

Article rédigé par Guillaume VINCENT, Software Architect chez AEROW.

Retrouvez cet article sur Linkedin : Lien vers l’article

Continue Reading
donatienlow

SharePoint : La noblesse du support et de la formation

by Zaira Banguyon 19 décembre 2015in Annonces, Consultant, ECM, ECM WORLD LTD No comment

SharePoint, logiciel collaboratif par excellence, a su au fil des années, devenir un outil indispensable pour les entreprises.

Cependant, en se réclamant accessible et destiné à tous, force est de constater que tous les utilisateurs n’ont pas les mêmes besoins, ni connaissances. Il ne suffit pas d’installer SharePoint pour que son utilisation soit adoptée. C’est l’erreur à éviter, et cette dernière coûte chère en termes de rentabilité et crédibilité. Pour cela il faut revenir à ce qui fait la force de votre entreprise : le collaborateur

Ce qui intéresse le collaborateur c’est de comprendre ce que peut lui apporter ce « nouveau » logiciel. Est-ce qu’il va améliorer son quotidien, ou au contraire le ralentir dans ses activités ?

  • Un plan de communication efficace abordant les aspects techniques et fonctionnels de SharePoint est à prévoir.
  • La définition et la formation des Key Users permettront un relais, une communication descendante de qualité.
  • De plus, une cellule de support dédiée à SharePoint se révélera un atout majeur pour accompagner et faire grandir vos utilisateurs, sur le court, moyen et long termes, cela dans le but de garantir une plus grande satisfaction et productivité.

Plus un logiciel se veut grand public, plus le besoin en support et en formation sera présent. Si le roi se nomme SharePoint, le support et la formation en sont sa cour.

 

by DONATIEN REGURON, Consultant chez AEROW.

Continue Reading

Breaking News

Catégories

  • Actualités
  • Aerow
  • Annonces
  • BENELUX
  • Consultant
  • Decision
  • Digital
  • ECM
  • ECM WORLD LTD
  • GSO
  • Non classé
  • Performance
  • Solutions
  • Studio A
  • SWISS
  • Tests
  • WAPSI

Étiquettes

AEROW AEROW Decision AEROW ECM AEROW Performance agile android Application BI Big Data BigData Business Intelligence Cloud consultant data Data Management DataWarehouse Decision Decisionnel Digital dynatrace ECM ERP GED HTML ios JAVA Microsoft mobile Neoload Neotys Office Office 365 Partenaires performance Performance applicative reporting SAP Sharepoint software Solutions Sql stress test Testing Test performance WAPSI


AEROW est une Entreprise de Service Numérique, créée en 2004 par Marc Wolff et Jérôme Pechot, spécialisée en Conseil, Intégration et Gestion de l’information des entreprises.

Nos Pôles & Offres

  • ECM
  • Digital
  • Decision
  • Studio A
  • Performance
  • Solutions

Nous Retrouver

  • Paris
  • Toulouse
  • Suisse
  • Belgique
  • Ile Maurice

Nous contacter

  • 53 rue François 1er, 75008 PARIS
  • +33.1.42.25.29.31
  • contact@aerow.fr

copyright © 2015 Studio A by AEROW | Mentions légales

Notre site aerow.fr utilise des cookies pour vous offrir une navigation personnalisée, adaptée, pertinente et pour améliorer votre confort d’utilisation. Cliquez sur « Politique relatives aux liens hypertextes et cookies » pour en savoir plus sur l’utilisation des cookies et vos droits, en tant qu’utilisateur, à avoir le contrôle sur l’utilisation de certains cookies sur notre site. En cliquant sur le bouton « Accepter », vous nous donnez votre consentement pour l’utilisation des cookies. Politique relative aux liens hypertextes et cookies.