Une offre c’est une marque, un produit (ou une famille de produit). Elle a une unité, une cohérence. Elle a une valeur ajoutée par rapport à la concurrence. Elle a un marché, i.e. un ensemble de clients types intéressés par l’offre. Elle a donc une dimension spécifique pour les clients de son marché, que l’on va mettre en avant au moment de démarcher les clients. Pour produire une offre, il faut savoir la produire, et savoir la produire de mieux en mieux (pour être de moins en moins cher). Capitaliser, produire du code réutilisable, voire des modèles de données réutilisable, des livrables type, …
Un collaborateur d’une SSII (à part peut-être les plus seniors ou les managers) se spécialise plus ou moins par plateforme ( jee / .net / php ), voire par produits. Il est naturel de recenser les collaborateurs experts en weblogic portal, ou plus généralement en portail, animer leur réflexion, leurs échanges, leur veille techno, le code réutilisable, les frameworks maison. Naturellement donc les effectifs devraient appartenir à une (ou plusieurs) cellules de veille, cellules archi, … appelons ça « centres de compétences ». Rien ne rend nécessaire de confondre l’offre et le centre de compétence. Un centre de compétence « portail & CMS » pourrait servir plusieurs offres.
Enfin, il y a l’approche manageriale. Chiffre d’affaire, marge, intercontrat. Pour piloter « numériquement » l’activité, il faut des frontières autour d’entités, chacune étant supposée rentable. A la base il y a le projet (avec un chef de projet dont le variable dépend de l’issue du projet), mais dont la durée de vie est limitée. L’entité stable est la « business unit » qui regroupe quelques dizaines de collaborateurs et qui doit être auto suffisante, quitte à « sous-traiter » pour d’autres business unit. A sa tête, un manager, dont le variable dépend (entre autres) des chiffres de la business unit. Les business unit s’empilent (business unit, département, agence, groupe). Il n’est pas évident que les offres doivent toutes être matérialisées par une business unit (avec des collaborateurs exclusivement dédiés). Pourquoi pas une approche matricielle ? Un centre de compétence peut être transverse, aussi (mais difficile alors d’en garantir le budget, la pérénité).
De la claire articulation entre ces 3 concepts (catalogue d’offres, liste des centres de compétence, hiérarchie des business unit) dans une organisation dépend :
- la pertinence de l’action commerciale et d’avant vente sur les offres, et donc leur pourcentage de réussite
- la formation continue, l’émulation des collaborateurs et un faible turnover
- la rentabilité gagnée en focalisant les énergies du management vers la rentabilité d’un périmètre clair
Exemple d’offres : par secteur (l’assurance, les labos pharmaceutiques) et/ou par problématique (le tunning de performance, les applis de gestion de contrat d’assurance)
Exemple de centre de compétences : la mobilité, la « stack » Spring, l’AMOA, la TRA, …
Une approche cohérente serait d’avoir des centres de compétence assez larges, qui contribueraient chacun à un certain nombre d’offres (s’appuyant potentiellement sur plusieurs centres).
Après, reste :
- à trouver la bonne organisation en business unit pour répartir les gens (au moins par centre de compétence, mais ce n’est même pas évident. Mes missions sont variées et couvrent plusieurs centres)
- à mettre en place un suivi quantitatif des offres : investissement, effort de prospection, résultats, chiffre d’affaire, … mais même ça c’est discutable : pourquoi une bu ne prendrait-elle pas le risque d’investir lourdement sur une offre peu viable au début (parce que c’est l’avenir, parce que l’on dispose de la compétence…) en la financant par les autres ?
Tout ceci a surement l’air un peu banal, mais « quand on est dedans », il n’est pas toujours facile d’y voir clair.