Quand un établissement financier procède à l'acquisition d'une banque, trois modèles d'intégration informatique s'offrent à lui: l'intégration complète dans le système central, l'intégration de systèmes de base entièrement décentralisés au moyen d'une comptabilité consolidée ou une solution intermédiaire. Lorsqu'en 2005, la Banque Julius Baer rachète Ferrier Lullin, Ehinger & Armand von Ernst et Banco di Lugano à UBS, elle opte pour la première solution, abandonnant les différentes configurations informatiques des trois banques privées. L'ensemble des données et des transactions est donc transféré sur sa plateforme informatique de manière à créer une unité homogène appliquant des processus unifiés à l'échelle du groupe. Ce dernier fonctionne désormais comme une seule banque avec un seul système informatique et un ensemble de processus unique.

Au moment où elle reprend les trois banques privées, la Banque Julius Baer se trouve au beau milieu d'un projet de migration du système central. La question se pose donc de savoir s'il faut d'abord achever la migration de l'ancien système - essentiellement développé en interne - vers Avaloq puis procéder à la migration des autres banques ou s'il est préférable d'interrompre le projet de migration afin d'intégrer les nouvelles banques au système existant. Compte tenu de sa stratégie de croissance, la Banque Julius Baer opte pour la seconde solution et stoppe l'introduction d'Avaloq. Au cours des dix-huit derniers mois, elle a en effet doublé les volumes et, en rachetant les trois banques privées, tutoie désormais les plus grands. Et avec cette augmentation, il n'est pas garanti que l'application standard, initialement développée pour de petites banques, soit encore efficace.

La première étape du projet d'intégration consiste à définir la plateforme cible. Jusque-là, les trois nouvelles banques utilisaient chacune leur solution standard alors que la Banque Julius Baer avait recours à une solution essentiellement développée en interne. C'est finalement cette dernière qui est retenue en raison de sa modularité. Le système central repose sur un calculateur mainframe IBM sur lequel tournent les applications bancaires - pour la plupart programmées en Cobol - telles que la gestion des comptes et des dépôts, les opérations sur titres ou le trafic des paiements. Parallèlement à la migration, la décision est prise de mettre au point un nouveau système frontal pour les conseillers à la clientèle dont la première version est introduite à l'automne 2007. L'environnement est complété par des systèmes satellites tels que le programme SAP pour la comptabilité et le système de gestion de l'information ainsi que différents systèmes de négoce. Avec des systèmes décentralisés, la modularité offerte par le système mainframe, qui assure une fiabilité hors pair, n'aurait pu être obtenue qu'au prix d'une complexité quasi ingérable.

L'étape suivante avait pour objet de définir des procédures aussi standardisées que possible pour toutes les étapes des trois intégrations, de l'analyse de la situation de départ jusqu'aux dernières opérations de finalisation. L'intégration en soi s'est faite en trois parties: la première banque était entièrement intégrée neuf mois seulement après l'annonce de la fusion, la deuxième et la troisième respectivement trois et neuf mois plus tard.

Avec du recul, il apparaît que certains facteurs ont été déterminants pour la réussite d'une opération aussi complexe. Premièrement, l'équipe dirigeante s'est intéressée de près à l'intégration des trois banques tout le temps qu'a duré le projet et lui a toujours accordé la plus haute priorité. Le comité de pilotage était ainsi composé des membres de la direction de toutes les banques impliquées, ce qui lui a permis de prendre très rapidement les décisions nécessaires. Ensuite, il était important de communiquer une vision claire avec un plan et un calendrier bien définis. Au début, les banques à intégrer, qui considéraient dans certains cas disposer des meilleures solutions informatiques, ont contesté la décision d'apporter aussi peu de changements que possible aux processus standards. Mais toutes les adaptations critiques pour l'exploitation commerciale ont été systématiquement retenues et implémentées dans le système informatique.

Le facteur humain a lui aussi joué un rôle décisif. Il est en effet indispensable de disposer d'une équipe de projet compétente et motivée, de déléguer les tâches à des équipes de taille réduite en veillant à leur accorder les compétences requises. Ainsi, des représentants de toutes les unités opérationnelles et de l'informatique, mus par un esprit d'entraide, ont continuellement travaillé en étroite collaboration et l'équipe de projet a pu prendre elle-même bon nombre de décisions. L'intégration en trois temps s'est également révélée judicieuse raison de l'optimisation des processus qu'elle a autorisée d'une intégration à l'autre. En outre, l'actualisation des données dans une phase préliminaire du projet a permis de garantir la qualité des données avant la migration effective de celles-ci vers le système de la Banque Julius Baer. Enfin, l'utilisation des structures et processus existants a sensiblement atténué le risque de migration.

Plus d'un an après la fin de l'intégration, il apparaît clairement que la Banque Julius Baer a fait le bon choix. L'intégration a en effet été terminée en respectant tant le calendrier que le budget et sans provoquer ultérieurement le moindre problème inattendu. Et la forte augmentation des volumes de transaction a été absorbée sans difficulté: alors que les volumes ont doublé, le traitement de fin d'année n'a pas pris plus de temps qu'à l'accoutumée.