Considérations pour l’automatisation d’un processus spécifique lors de votre Transformation numérique.
De façon générale, un plan TI de transformation numérique se déroulera en plusieurs étapes et touchera plusieurs aspects de l’organisation. Par exemple :
- Implantation ou remplacement d’un CRM
- Implantation ou remplacement d’un ERP
- Implantation ou remplacement d’un système de gestion
- Automatisation d’un processus spécifique via un développement sur mesure
- Création d’un entrepôt de données
- Implantation d’une plateforme ou d’une couche de sécurité
Votre plan de transformation numérique considérera peut-être pas tous ces aspects car chaque organisation a son budget, ses priorités, ses capacités, son échéancier, etc.
Dans notre dernier billet, portant sur la transformation numérique, nous avons identifié 9 considérations dans le remplacement de votre CRM et nous avons terminé en indiquant que chez Analystik, notre rôle est souvent d’automatiser des fonctions de l’entreprise suite à la création d’une opportunité.
La vraie nature de l’automatisation d’un processus spécifique
Dans ce billet, nous étudierons le cas d’une organisation qui a transféré son CRM dans Salesforce et qui désire maintenant procéder à l’automatisation d’un processus, ce qui implique de développer une fonction spécifique à l’entreprise afin de répondre à un besoin d’affaires spécifique.
Encore une fois, plusieurs éléments doivent être pris en considération dans cette opération :
- Qui seront les utilisateurs de cette fonctionnalité ?
- Quels liens seront nécessaires avec les systèmes en place ?
- La taille de la fonctionnalité ?
- La sauvegarde des données…
- Dans quel environnement technologique le développement doit-il être exécuté ?
- La fonctionnalité doit-elle être disponible en mobilité ?
- Est-ce que la fonctionnalité accède à des données sensibles ?
- La gestion de la sécurité
Prémisse à l’automatisation d’un processus spécifique
Pour détailler chacun de ces points, prenons l’exemple d’une organisation qui désire automatiser la fonctionnalité d’émission d’une lettre d’offre pour le financement d’une pièce d’équipement.
En aval de cette opération, un compte avait été créé dans Salesforce et deux contacts avaient été associés à ce compte. Une opportunité est maintenant créée dans le CRM pour ce client et quelques données financières sont saisies (donc le module opportunité du CRM a été personnalisé aux besoins de l’entreprise).
Le client accepte verbalement la proposition du représentant et lui demande une proposition de financement. Pour faire cette demande, de nouvelles données doivent être saisies dont certaines au niveau du module de génération de la lettre d’offre et certaines dans d’autres systèmes d’entreprise.
Donc, détaillons les éléments énumérés ci-haut :
-
Qui seront les utilisateurs de cette fonctionnalité ?
Cette question est importante, car on ne voudra pas acheter des licences CRM supplémentaires pour des usagers qui utiliseraient seulement le module de génération de la lettre d’offre.
Si ce sont les mêmes utilisateurs que le CRM, alors il faut déterminer si la gestion des rôles et permissions du CRM suffisent à contrôler l’accès aux diverses sections de la fonctionnalité à développer.
-
Liens nécessaires avec les systèmes en place
L’interconnectivité avec les systèmes d’entreprise en place est une considération importante surtout si nous avons opté pour une solution CRM Cloud qui est hors de l’environnement TI de l’organisation. Des « ponts » doivent être créés avec les systèmes d’entreprise et selon les règles de sécurité en place, ces ponts ne seront pas toujours faciles à construire…
Dans notre exemple, nous avons besoin de saisir des données financières dans un des systèmes d’entreprise dans le but d’obtenir une cote de crédit.
Une fois la lettre d’offre acceptée, les données devront aussi être transférées dans un autre système, responsable de gérer le prêt.
Plus les systèmes d’entreprise sont récents, plus il est facile de créer des interfaces performantes et sécuritaires. Malheureusement, ce n’est pas souvent le cas et le développement des « connecteurs » peut s’avérer ardu.
-
La taille de la fonctionnalité ?
Le but ici est de nous aider à déterminer où et dans quelle technologie devrait être développée la nouvelle fonctionnalité.
Dans notre exemple, le besoin est la génération d’une lettre d’offre, par contre, la vision est l’automatisation de plus en plus complète du processus de financement. Donc la taille de cette fonctionnalité aura une propension à devenir de plus en plus grande.
-
La sauvegarde des données…
Dans le point 2 ci-dessus, nous avons indiqué que des données doivent être saisies, d’autres doivent provenir des systèmes d’entreprise.
La quantité de données qui seront nécessaires, la vision des fonctionnalités à développer (taille) ainsi que la sécurité nécessaire pour certaines de ces données influenceront le choix de l’entrepôt de données.
Plusieurs organisations sauvegardent les données dans le CRM sans avoir trop analysé cet aspect. C’est une erreur, car malgré la grande flexibilité d’un CRM, celui-ci n’offre pas la puissance d’une base de données comme SQL.
Dans notre exemple, considérant la vision et la quantité de données nécessaires, vous comprendrez qu’une base de données indépendante du CRM a été privilégiée. Dans ce cas-ci, une BD SQL « on the premises » mais qui aurait tout aussi bien pu être un service SQL Cloud.
-
Dans quel environnement technologique, le développement doit-il être exécuté ?
Le développement sera-t-il fait directement dans le CRM ou dans du code propriétaire à l’entreprise ?
Dans le cas où la fonctionnalité à développer serait « collée » au CRM ou bien que celle-ci serait de la personnalisation du CRM, le choix est facile à faire ; on développe la fonctionnalité dans le CRM.
Par contre, comme nous avons déjà mentionné antérieurement, trop d’entreprises entament des développements d’envergure dans leur CRM et deviennent « prisonnières » de celui-ci et parfois même d’une version de celui-ci.
Vous comprendrez que dans le cas de notre exemple, le choix était fixé d’avance pour plusieurs raisons :
- La vision des fonctionnalités à développer est large
- L’organisation ne veut pas devenir prisonnière de son CRM et des évolutions futures de celui-ci
- Des données critiques doivent être conservées
- À échéance, un plus grand nombre d’utilisateurs que ceux qui ont accès au CRM sera nécessaire
Malgré que le CRM soit Salesforce, l’environnement TI de l’organisation est Microsoft, il est impératif de développer du code propriétaire qui appartienne à l’organisation avec une technologie permettant les évolutions futures et dont les spécificités ne nécessiteront pas des « tours de passe-passe » à programmer.
-
La fonctionnalité doit-elle être disponible en mobilité ?
Bien sûr, aujourd’hui un grand nombre d’applications sont Web et pour plusieurs, une bonne application Web sera aussi Mobile. Cela est effectivement vrai pour une application simple qui manipule peu de données et qui ne possède pas de règles d’affaires complexes.
Selon notre expérience, pour bien répondre aux besoins « mobiles », il est souvent préférable de programmer seulement les fonctionnalités qui doivent vraiment être mobiles, de manière à offrir une bonne expérience client autant à l’utilisateur Web qu’à l’utilisateur mobile.
-
Est-ce que la fonctionnalité accède à des données sensibles
Une fonctionnalité qui doit manipuler et entreposer des données sensibles, comme un numéro d’assurance sociale, doit être programmée en tenant compte de normes plus strictes, son développement ne s’exécutera pas de la même façon.
Est-ce qu’on veut que la donnée soit cryptée ; dans la base de données ? Lors des transferts entre la BD et l’écran de l’usager ? Est-ce que cette donnée sera effacée automatiquement pour un client inactif depuis plusieurs années ? Qui peut avoir accès à cette donnée ? Avec quels droits ?
-
La gestion de la sécurité du processus
Les environnements TI sont de plus en plus complexes et on retrouve souvent des environnements hybrides chez nos clients ; « on the premises », « Cloud », « Web », « Mobile » ou « Windows ».
Nous avons tous entendu parler ces derniers mois de données volées, et ce dans des organisations de grande renommée.
La sécurité est maintenant beaucoup plus qu’une bonne architecture du mécanisme de login / password et une bonne gestion des rôles et permissions.
On doit retrouver la gestion de la sécurité dans toutes les étapes du processus de développement logiciel, de la définition des besoins au déploiement de la solution.
En même temps, on désire faciliter la tâche aux usagers ; on ne voudra pas qu’un usager qui vient de se « loger » dans son CRM doive se reloguer pour effectuer une fonctionnalité hors CRM.
On ne voudra pas non plus qu’un petit futé, inscrive manuellement une adresse URL pour accéder à une fonctionnalité qu’il n’aurait normalement pas accès s’il avait été dans l’application.
On ne voudra pas non plus ouvrir le « firewall » de l’application mobile qui veut venir chercher des données dans les systèmes d’entreprise.
Ce ne sont là que quelques exemples; le niveau de sécurité nécessaire de l’organisation dictera les risques « acceptables » et imposera les limites quant aux données ou fonctionnalités qui peuvent être exposées.
CONCLUSION
Encore une fois, les 8 éléments traités dans ce billet ne donnent qu’un aperçu vous permettant d’amorcer votre virage numérique. En espérant que cela vous permettra de poser les bonnes questions aux différents intervenants impliqués dans votre projet.
Bonne Transformation numérique !