D.Wells, Pegasystems: ‘Trop de libertés sont prises avec BPEL’

Régulations

BPM, CRM, ESB? voici un éditeur BPM américain qui n’étend pas ses tentacules et joue la carte du ?pure player? BPM. Entretien avec David Wells, directeur EMEA (Europe Moyen-Orient Afrique) de Pegasystems

Quelles sont vos ambitions ? Le service est-il un levier important pour vous ? En 2005, nous avons réalisé un chiffre d’affaires de 102 millions de dollars. Nous visions 500 millions de dollars fin 2008 en développant trois axes : l’expansion géographique, la proposition de solutions verticales par secteur et/ou métier, et le développement d’un réseau d’intégrateurs et de partenaires. Nous souhaitons rester un éditeur de logiciels. Actuellement, les logiciels représentent 50 % de notre chiffre d’affaires, et l’activité de consultant contribue à hauteur de 35 %. Notre objectif: amener le logiciel à 75 ou 80% de nos revenus. Sur quelles technologies repose votre solution -initialement conçue sur des ‘mainframes’ ? Depuis 1983 et jusqu’en 1996, nous avons déployé notre solution dans le monde financier pour répondre à des besoins complexes de ‘back-office’. Notre logiciel fonctionnait alors sous mainframes MVS et VMS. Puis, nous avons tout réécrit en langage C++ pour les environnements Unix et Windows. En 1998, nous avons aidé AOL à gérer la facturation pour 20.000 abonnés dans le monde. Et d’autres projets de cette importance se sont enchaînés au niveau mondial. Dès 2003, nous avons porté notre plate-forme sous machine virtuelle Java. Nous sommes ainsi devenus indépendants de l’environnement d’exécution, permettant au client de choisir plus librement son environnement technique. Notre moteur Pega Rules Process Commander est désormais 100% orienté “services Web”. En quoi êtes-vous un ?pure player? ? Et pourquoi vos concurrents ne le seraient pas ? Notre philosophie de ‘pure player’ BPM consiste à utiliser un référentiel pour les informations de l’entreprise ou de l’un de ses services, utilisé par des règles incarnant la dynamique de processus métiers adressant les diverses applications et bases de données existantes. Donc, via ce référentiel, des interfaces permettent d’assurer la cohérence du système d’information de l’entreprise ou du département impacté. En revanche, nous restons cantonnés au BPM. Ainsi, notre module CPM sert à interagir avec un logiciel de CRM, et non à le remplacer. De même, nous ne développons pas d’ESB (Enterprise Service Bus), mais nous nous assurons de pouvoir fonctionner avec ceux du marché. Notre objectif consiste à faire communiquer les silos dans lesquels se sont enfermés les services des entreprises, limitant ou inhibant la communication entre applications. Notre promesse : aider l’entreprise à comprendre et à réorganiser ses processus, en conservant une souplesse indispensable pour suivre ses évolutions. Des concurrents, comme Tibco par exemple, proposent effectivement des modules ESB et d’autres des applicatifs ‘métier’. En général, ils viennent du monde du progiciel ou du ‘middleware’, et ne cherchent pas forcément à se positionner comme ?pure player?. Que pensez-vous du standard BPEL (in extenso : Business Process Execution Language for Web Services) ? Ce standard est intéressant et nos produits sont compatibles BPEL. Néanmoins, il illustre assez bien les phénomènes actuels de standardisation. Pour améliorer la productivité de nos clients, nous leur proposons des ‘frameworks’ de processus sectoriels décrivant les meilleures pratiques de leur secteur, qu’ils peuvent ensuite adapter et personnaliser. Pour cela, nous collaborons avec de très grands éditeurs américains. Or, nous constatons que chacun prend de grandes libertés en implémentant les standards, et BPEL en particulier. Toutefois, si la solution répond correctement au besoin du client, n’est-ce pas là l’essentiel ?


Auteur : José Diz
Lire la biographie de l´auteur  Masquer la biographie de l´auteur