Voici ce qu'il faut savoir sur le compromis lié à l'imprimé zébré.
La version sur siteOpenText prend en charge la génération d'étiquettes Zebra (ZPL). Ce n'est pas le cas de la Cloud Edition ne le prend pas en charge. Si l'impression Zebra fait partie de votre processus, prévoyez-le avant de migrer.
OpenText est une plateforme CCM performante. Les déploiements sur site prennent en charge depuis longtemps la sortie ZPL — le langage utilisé par les imprimantes thermiques Zebra — dans le cadre d'une large gamme de canaux de sortie. Qu'il s'agisse d'étiquettes pour les entrepôts, la logistique, les environnements cliniques ou les ateliers de production, la solution sur site est en mesure de les gérer.
Il en va tout autrement pour l'édition Cloud. La sortie ZPL n'est pas prise en charge. Si votre organisation utilise l'impression d'étiquettes Zebra dans le cadre de ses processus documentaires ou de communication, cette fonctionnalité ne sera pas transférée lors de votre migration vers OpenText .
Ce n'est pas un détail insignifiant. Pour les organisations où l'impression d'étiquettes revêt une importance opérationnelle, il s'agit d'une lacune qui nécessite un plan avant le début de la migration — et non après.
Pourquoi ce problème apparaît-il tardivement dans les projets de migration ?
L'impression des étiquettes relève généralement de la responsabilité des services opérationnels, et non de l'équipe chargée de définir le périmètre de la migration vers le CCM. Le volet CCM se concentre sur les documents destinés aux clients : lettres, relevés, factures, envois numériques. Les étiquettes sont considérées comme un enjeu logistique, géré par une équipe distincte, qui utilise souvent une infrastructure antérieure à la plateforme CCM.
Il en résulte que les fonctionnalités ZPL sont considérées comme une caractéristique actuelle d'Exstream sur site, que l'édition cloud est évaluée en fonction des aspects de la production de documents qui importent le plus à l'équipe de projet, et que les lacunes en matière de production d'étiquettes ne sont détectées que tardivement — parfois alors que la planification de la mise en service est déjà bien avancée.
À ce stade, les options qui s'offrent à vous sont généralement peu satisfaisantes : retarder la migration, investir dans un système de gestion des étiquettes distinct, ou accepter une solution manuelle qui réintroduit la complexité opérationnelle que vous cherchiez justement à éliminer.
Ce que cet écart signifie réellement pour votre architecture
Le langage ZPL (Zebra Programming Language) est la norme en matière d'impression thermique d'étiquettes. Il prend en charge tous les éléments nécessaires au processus d'étiquetage : champs de texte variables, blocs d'adresse, numéros de lot, dates de péremption, identifiants de conformité, logos, éléments graphiques de mise en page et, surtout, codes-barres et codes QR générés en natif par l'imprimante.
Lorsque votre plateforme CCM ne peut plus générer de fichiers ZPL, l'une des trois situations suivantes se produit généralement :
- Le processus de gestion des étiquettes est entièrement dissocié de la couche CCM et confié à un système de gestion des étiquettes autonome, ce qui implique une duplication des données, de la logique et du travail d'intégration
- Un développeur crée un générateur ZPL personnalisé qui fonctionne en dehors de la plateforme — ce qui marche tant que ça marche, mais finit par devenir un fardeau en termes de maintenance
- La gestion des étiquettes n'est plus une priorité ou est effectuée manuellement, ce qui est rarement viable à grande échelle
Aucune de ces réponses n'est satisfaisante. La bonne solution consiste à combler cette lacune au niveau de la couche d'intégration, en utilisant un outil spécialement conçu pour ce type d'orchestration de processus.
Comment ENIT Flowbuilder comble cette lacune
ENIT Flowbuilder est une plateforme d'intégration « low-code » spécialement conçue pour ce type d'orchestration de processus. Elle n'est pas limitée à un type de sortie spécifique : elle peut traiter des données structurées provenant de n'importe quelle source et les acheminer vers n'importe quel canal de sortie, y compris un flux ZPL correctement formaté envoyé directement à une imprimante Zebra ou à un terminal de gestion d'étiquettes.
Pour la génération d'étiquettes, un flux Flowbuilder prend entièrement en charge cette fonctionnalité :
- Champs de texte renseignés à partir des données sources — noms, adresses, codes produit, numéros de lot, dates de péremption
- Éléments graphiques et structures de disposition des étiquettes
- Images — logos, icônes de conformité, images de produits — à la résolution adaptée à l'impression thermique
- Codes-barres et codes QR : Code 128, EAN-13, DataMatrix, QR et autres normes courantes
- Sortie ZPL bien formée, prête à être imprimée directement ou transmise en aval
Il est important de noter que cela ne nécessite pas de remplacer OpenText. L'architecture est additive : Communications Cloud continue de gérer la production de documents destinés aux clients, tandis que Flowbuilder prend en charge les canaux que l'édition cloud ne couvre pas. Les deux solutions s'appuient sur le même flux de données en amont. Le fossé en matière de génération d'étiquettes est comblé sans créer de nouveau silo ni nécessiter un investissement parallèle dans une solution de gestion de la communication client (CCM).
Une conversation sur l'immigration qu'il vaut mieux avoir dès le début
Si votre organisation envisage de passer de la version sur site d'Exstream à l'édition cloud — ou si vous êtes déjà en train de le faire —, il est utile de se pencher dès maintenant sur la question de la sortie des étiquettes. Les questions à se poser sont les suivantes :
- Quels processus métier dépendent actuellement de la sortie ZPL d'Exstream sur site ?
- Ces processus sont-ils essentiels au bon fonctionnement de l'entreprise, ou leur volume est-il suffisamment faible pour qu'on puisse les traiter différemment ?
- Quelle est la source des données utilisées pour la génération des étiquettes ? Ces données transitent-elles déjà par votre couche d'intégration ?
- À quoi ressemble un transfert en bonne et due forme de la responsabilité des étiquettes, et qui en est responsable après la migration ?
Il est nettement moins coûteux d'obtenir ces réponses avant la fin de la planification de la migration que de constater cette lacune lors des tests d'acceptation utilisateur.
L'enjeu plus large pour les architectes et les responsables de processus
La migration vers le cloud des plateformes CCM d'entreprise ne se résume pas à un simple transfert de fonctionnalités. Certaines fonctionnalités présentes dans la pile sur site — canaux de sortie, prise en charge des pilotes, modèles d'intégration — peuvent ne pas être disponibles dans la version cloud, et la documentation ne le précise pas toujours clairement.
La prise en charge du format ZPL dans OpenText en est un exemple concret. Le principe s'applique de manière générale : avant de vous engager dans une migration vers une solution de gestion de contenu client (CCM) dans le cloud, comparez vos canaux de diffusion actuels aux capacités réelles de la plateforme cloud, et non à ce qu'en disent ses supports marketing.
Les lacunes existantes peuvent être comblées, mais elles doivent l'être au niveau de l'architecture, avec les outils appropriés en place, avant que la migration ne soit achevée. Il est toujours plus coûteux d'ajouter des fonctionnalités après la mise en service que de les prévoir dès le départ.
ENIT Flowbuilder constitue une partie de cette solution. Si vous travaillez sur ce projet pour OpenText, Quadient, Smart Communications ou toute autre plateforme CCM, nous serons ravis de vous présenter concrètement comment cela s'applique à votre environnement spécifique.
