Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

24/11/2008

Travailler le dimanche

La question du travail dominical agite nos députés, l'Eglise catholique, et les commentateurs.

Il m'arrive de travailler le week-end et la nuit. Je viens même de passer deux week-ends de suite chez un client (d'où mon silence sur ce blog : on ne peut pas être partout !!)

La mission consistait en diverses mises à jour logicielles et matérielles. En jargon informatique, on parle d'upgrade. Pour être plus précis, ce client fait tourner son entreprise avec SAP : prototype du progiciel dévoreur de budget pour certains, facteur clé de l'efficacité industrielle pour d'autres.

Quoi qu'il en soit, toute la production de cette entreprise, depuis l'approvisionnement jusqu'à la distribution chez ses clients est sous le contrôle de SAP. Une opération lourde, de remplacement ou d'upgrade de composants logiciels suppose l'arrêt du service, et ne peut donc s'effectuer qu'en heures non ouvrées, pour ne pas pénaliser l'activité ordinaire de l'entreprise.

Opérations techniques et planning

Voici le programme de ces deux week-ends :

  • 8 et 9 novembre :
    • Remplacement de serveurs
    • Upgrade de l'Operating System (Solaris 8 vers Solaris 10)
    • Upgrade de la base de données (Oracle 9.2 vers Oracle 10.2)
    • Tests et recettes SAP au niveau fonctionnel et technique
  • Lors de premier week-end, SAP n'est pas modifié. Il s'exécute dans la même version au dessus d'un socle technique différent
  • Temps de travail :
    • Samedi 8 novembre : de 8h à 22h30
    • Dimanche 9 novembre : de 9h à 16h
    • J'ai fait le week-end tout seul
    • Temps de travail en heures non ouvrées: 22 heures

 

  • 14-15-16 novembre
    • Upgrade SAP de la version 4.6C vers la version ECC6
  • Temps de travail et planning :
    • Vendredi 14h : Préparation de l'opération et dernière mise au point
    • Vendredi 14 21h : Démarrage de la sauvegarde
    • Samedi 15 à partir de minuit : Démarrage de l'upgrade SAP
    • Dimanche 16 novembre à 5h30 du matin : Fin de l'upgrade
    • Dimanche 16 à 6h : Lancement de la sauvegarde
    • DImanche 9h : Fin de la sauvegarde - Tests techniques et fonctionnels jusqu'à 14h
    • Dimanche 18h : Retour à la maison
  • Nous étions deux lors de ce deuxième week-end
  • Temps de travail en heures non ouvrées pour chacun : 21 heures

Aspects réglementaires et financiers

Dans mon entreprise, ce type de mission est basée sur le volontariat. Sachant que nous ne sommes pas très nombreux à avoir des compétences SAP, on a vite fait le tour des volontaires potentiels. Disons qu'on s'arrange entre nous, et que le management nous laisse nous débrouiller. Au cours d'une année, il faut compter une petite dizaine d'opérations de ce type.

Il est en principe interdit d'effectuer plus de onze heures consécutives, qui doivent elles-mêmes être suivies d'un repos de onze heures également. Dans notre cas, ce type de réglementation n'est pas applicable ; il n'est d'ailleurs pas appliqué. J'ai travaillé du vendredi 14 heures jusqu'au samedi matin à 7 heures du matin avec une  pause d'une heure pour le dîner.

Financièrement, les interventions en heures non ouvrées sont facturées double au client. Dans le cas des opérations des deux week-ends, la proposition est de :

  • Samedi 8 novembre : Upgrade Oracle = 1 jour x 2 = 2 jours (le dimanche ne sera pas compté, car il est dû à des problèmes techniques)
  • Upgrade SAP du 14 au 16 novembre = 40 heures = 5 x 8 heures x 2 = 10 jours
  • Une journée normale (ou tranche de 8 heures) est facturée 1250 Euros + 150 Euros de frais de déplacement
  • L'ensemble des deux week-ends a donc été facturé (1250 x 12) + (150 x 6 )  = 15 900 Euros
  • En heure ouvrée, le même nombre d'heures aurait été facturé (1250 x 6) + (150x6) = 8400 Euros

En ce qui nous concerne, nous sommes payés en heures supplémentaires 250 Euros bruts par tranche de 4 heures non ouvrées. Cela fait un total de 64 heures. 64 heures divisées par 4 donnent 16 x 250 Euros = 4000 Euros bruts, au prorata des heures supplémentaires de chacun.

L'opération reste bénéficiaire pour mon employeur qui facture le double. En principe, le doublement de tarif lui est très largement profitable puisqu'il verse 2x250 Euros bruts pour une surfacturation qui est supérieure à 1000 Euros (1250 dans ce cas de figure). Dans notre exemple, la différence ne lui pas autant favorable du fait du premier week-end qui ne sera pas totalement facturé au client, mais qui devrait m'être payé aux heures effectivement réalisées (Normalement !!)

Quelques réflexions

Les prix de journée peuvent paraître exhorbitants. Ce sont pourtant les tarifs ordinaires pour ce type d'intervention. A ma connaissance, un consultant Oracle ou SAP est souvent facturé 1400 Euros la journée, 1800 dans certains cas. Pour des missions d'administration technique de longue durée, une SSII sera plutôt entre 600 et 800 Euros suivant le profil.

On doit noter que ce type d'intervention est extrêmement stressant. Une erreur de manipulation ou une mauvaise préparation peut mettre en péril l'ensemble de la manipulation, qui devra être reportée dans le meilleur des cas, ou qui nécessitera un retour en arrière toujours périlleux, ou même mettre au chômage technique l'ensemble de l'entreprise en cas de grave problème.

A titre personnel, je ne refuse pas ce genre d'interventions (même si ce type de tâche technique ne fait plus partie de mon activité ordinaire). Elles font un complément  de revenus nonnégligeables, et il n'y en a jamais plus d'une par mois. Par ailleurs, j'ai la faculté d'organiser mon temps de travail de manière assez libre. Voilà pourquoi je suis prêt à travailler certains week-ends, ou certains soirs quand il y a besoin. Pendant des périodes moins chargées, je m'autorise des journées moins pleines sans que l'on vienne compter mes heures. C'est une confiance réciproque, profitable à  mon employeur comme à moi-même.

Je ne suis pas du tout certain que cela soit valable pour tous ceux qui sont menacés d'une extension légale des journées de travail jusqu'au dimanche, telle que les discussions actuelles le prévoient. Les opérations d'upgrade informatiques que je viens de décrire font partie des travaux de maintenance qui se font, par nature, lorsque l'activité ordinaire est arrêtée. Je ne vois aucune valeur à généraliser ces travaux aux tâches qui peuvent être effectuées en heures ouvrées. Tout ce qu'on peut en attendre est un léger effet sur l'emploi et une hausse des prix non négligeable. Tout cela, à condition que ces heures soient rémunérées en heures supplémentaires, ce qui n'est assurément pas garanti si cette pratique se généralise.

Le repos du dimanche a été rendu obligatoire par une Loi du 18 novembre 1814, supprimé en 1880, puis rétabli en 1906. Nous vivons sous ce régime depuis un siècle, cela n'empêche pas les trains de rouler le dimanche, ni d'avoir du courant éléctrique, d'être soigné en cas de besoin, ou d'effectuer des opérations de maintenance. La suppression de cette journée aurait des effets négligeables sur le plan économique et catastrophiques sur le plan social comme sur le plan symbolique des valeurs.

14/12/2007

Faire de l'audience avec les ERP

Impossible, répond Robert Scoble qui se demande pourquoi le logiciel d'entrepise n'est pas sexy. Michael Krigsman, Dan Farber, Dennis Howlett, Anshu Sharma, Sadagopan, Craig Cmehil, et d'autres lui répondent que l'objectif de ce type de logiciel n'est pas d'être attirant mais efficace et fiable. Nick Carr ne voit pas pourquoi un ERP devrait être rébarbatif sous prétexte qu'il traite de processus d'entreprise et n'est pas orienté grand public.

A vrai dire, il y a peu de chances que la gestion de la logistique et des finances deviennent quelque chose d'un peu sexy. Ce sont juste des process d'entreprise complexes. Là où Nick Carr a raison, c'est quand il dit qu'un processus complexe peut être habillé et présenté de manière un peu plus conviviale. C'est d'ailleurs ce que tente de faire SAP, en intégrant dans son portail des règles de navigation issues du Web grand public. Néanmoins, il n'y a aucun moyen de rendre convivial un calcul de besoins ou une balance comptable, rébarbatifs quel que soit l'habillage que l'on puisse y mettre.

 Cette discussion n'est pas neuve, entre la pratique des outils grand public qur tout le monde utilise chez soi par plaisir, et les outils professionnels que l'on subit dans l'entreprise par nécessité. Et le débat fait rage sur les blogs anglophones ( rien en France à ma connaissance ). Sauf que ce n'est pas exactement ce que dit Robert Scoble. Voici ses propos :

"let’s look at the business of journalism or even of blogging. We’re paid to deliver page views. Advertisers call it “CPM” (cost per thousand viewers). Now, what’s going to get more of you interested? Consumer software that you actually have a role in adopting or purchasing or enterprise software where some CIO somewhere else in your organization decides on? I know that when I talk about enterprise software the numbers of viewers just don’t show up. So, tech bloggers quickly learn that if they talk about enterprise software they aren’t going to get many advertising impressions."

"Regardons les revenus du journalisme ou même des blogs. Nous sommes payés pour être vus. Les annonceurs appelent ça le CPM ( coût par milliers de visiteurs ). Qu'est-ce qui va vous intéresser le plus ? Du logiciel grand public pour lequel vous avez réellement un rôle, dans l'adoption ou l'achat, ou du logiciel d'entreprise  pour lequel c'est le CIO ou n'importe qui d'autre dans l'entreprise qui décide ? Je sais que lorsque je parle de logiciels d'entreprise, le nombre de lecteurs ne va pas augmenter. Ainsi, les bloggers qui parlent de technologie apprennent vite que si l'on parle de logiciels d'entreprise, ils ne vont pas avoir beaucoup de publicité ".

Ce qui est bien avec les Américains, c'est qu'ils ne se cachent pas derrière leur petit doigt. L'ERP c'est chiant, nous dit Scoble. A chaque fois que j'en parle j'ai une baisse d'audience, donc de pubs, donc de revenus, donc j'en parle le moins possible. Ou alors pour créer une bonne polémique comme celle-ci qui va m'attirer des lecteurs. Je ne sais pas si vous vous intéressez au design des ERP ( sans doute pas beaucoup ). Mais si vous vous intéressez à la question de la gratuité, de la publicité et de l'indépendance d'Internet, cette petite anecdote est bien éclairante. Il faut faire de l'audience. Donc, vus des blogs, Internet et l'informatique en général se réduisent aux outils grand public. On ignore ce qui se passe derrière le rideau, qui représente quand même largement autant de milliards et façonne nos vies de manière aussi décisive.

Je continuerai à en parler de temps en temps. Tant pis pour le bloguimat. De toutes façons, je n'ai pas de pub et je suis gratuit. Je suis libre.

05/12/2007

Les nouveaux rythmes vus par SAP

Entendu lors d'une conférence SAP ces quelques chiffres :

  • Une fusion-acquisition d'entreprise toutes les 20 minutes
  • Un nouveau produit toutes les 3,5 minutes
  • Un container expédié toutes les 0,1 secondes

 

Et la future nouvelle génération d'utilisateurs :

  • n'a jamais acheté un enregistrement sur CD
  • aura joué à des jeux video depuis toujours
  • est sur Internet depuis l'âge scolaire
  • a eu une adresse mail avant leur numéro de téléphone personnel
  • télécharge du logiciel et ne l'achète pas ( sauf les jeux video )
  • a une durée d'attention moyenne de 6 à 8 minutes, comparée à leurs parents qui sont plus proches de 20 minutes

Ce chiffre de 6 à 8 minutes est d'ailleurs paradoxal, puisque dans le domaine des jeux video, il est beaucoup plus important. Tous ceux qui ont des enfants ont pu constater ( et déplorer ) les heures qu'ils y passent avec passion et donc avec attention. Mais ce n'est pas la même attention, naturellement.

En tous cas, le lourd vaisseau SAP a pris conscience que l'on changeait d'époque, mais sa base installée est encore plus lourde que lui. Le virage SOA a du mal à prendre.

J'en parlerai dans un prochain billet.

20:52 Publié dans ERP | Lien permanent | Commentaires (0)

04/06/2007

Petite histoire (personnelle) de l'éthanol

    L'agriculture n'est plus seulement une source d'alimentation. Une alimentation à destination des animaux comme des hommes. C'est aussi, et depuis longtemps, une source de matière première pour l'industrie. Mais cette autre destination, même ancienne, est restée très longtemps marginale. Il s'agit des plantes à fibres comme le chanvre ou le lin, dont la récolte est destinée à l'industrie textile et papetière.

    Aujourd'hui on a pris conscience de la nécessité de compléter l'approvisionnement énergétique à base de pétrole, avec la production de biocarburants. Ce sont principalement l'éthanol, que l'on fabrique à partir de l'amidon des céréales (blé ou maïs), ou directement à partir du sucre de betteraves ou de canne. On utilise aussi le diester issu d'oléagineux comme le colza et le tournesol. Il reste enfin une autre source d'énergie, aujourd'hui quasiment pas exploitée, à base de sous-produits des céréales : la paille.

    L'éthanol ou bioethanol est tout simplement l'alcool éthylique que l'on trouve dans toutes les boissons alcoolisées et que l'on obtient à partir de la fermentation du sucre. Ce procédé est connu depuis la nuit des temps. Le sucre est présent naturellement dans la betterave et dans la canne à sucre. Pour fabriquer de l'éthanol à partir de céréales (blé ou maïs), il faut "casser" la molécule d'amidon contenue elle aussi naturellement dans ces céréales. Un grain de blé contient 2/3 d'amidon et 1/3 de protéines.

    Une tonne de blé donne 370 litres d'éthanol et 350 kg de drêches. Les drêches sont ici considérées comme des déchets, même si elles constituent une excellente alimentation protéinée pour les animaux. Calculé à l'hectare cela donne  3200 litres d'éthanol et 3,1 tonnes de drêches. 

    Pour la betterave, une tonne donne 7500 litres d’éthanol. Un hectare produit 7500 litres et 3,5 tonnes de pulpes ( en matière sèche)

 

    Voici le processus d'obtention du bioéthanol :

 

medium_ethanol-fabrication.2.jpg

     

 

C'est en ce moment, en 2007, que le prix du blé explose et que l'on se met à construire des unités de production. C'est ainsi que la société Tereos  a construit cette année deux unités de production. A Origny dans l'Aisne pour une capacité de 240 000 tonnes à partir de betteraves et à Lillebonne en Seine Maritime pour la même capacité à partir de blé.

    Parfois les bonnes idées mettent du temps à se réaliser. Dans une autre vie, comme on dit, j'étais agriculteur. La production d'éthanol était déjà discutée à la fin des années 80. J'étais responsable de la section "Grandes Cultures" pour ma région de Basse Normandie au sein du C.N.J.A (Centre National des Jeunes Agriculteurs). La crise de l'énergie était déjà là, la surproduction agricole aussi. Nous fondions de grands espoirs dans ces nouveaux débouchés industriels. J'ai eu l'occasion de participer à de nombreuses études sur la chimie du blé. Car l'éthanol n'est pas la seule utilisation possible. Déjà à cette époque, la société Roquette était  très active en fabricant de nombreux produits à haute valeur ajoutée pour les industries alimentaires, pharmaceutiques ou cosmétologiques. Comme quoi l'action syndicale ne se résume pas toujours à des revendications catégorielles un peu bornées...

    La production d'énergie à partir de l'agriculture n'est donc pas une idée nouvelle. Il y a vingt ans, que la filière qui se met en place aujourd'hui, aurait pu démarrer. Mais il n'y avait pas encore assez d'urgence, et beaucoup de progrès restent à accomplir, en particulier pour le bilan énergétique :  une étude plus complète est disponible ici (pdf).

En résumé :

"- le rendement énergétique (énergie restituée / énergie non renouvelable mobilisée) pour les filières de production d’éthanol de blé et betterave est de 2 à comparer avec le rendement pour la filière essence de 0,87.
- Le rendement énergétique des filières ETBE de blé et betterave est voisin de 1 contre un rendement de la filière MTBE de 0,76.
- Enfin, les filières huiles végétales présentent un fort rendement énergétique de 4,7 pour l’ huile de colza et 5,5 pour l’ huile de tournesol, et proche de 3 pour les filières EMHV à comparer avec le rendement du gazole de 0,9."

     Ce bilan est calculé en prenant en compte toute l'énergie non-renouvelable nécessaire à la fabrication du produit final. En ce qui concerne l'essence, c'est l'énergie nécessaire à l'extraction, le raffinage et le transport. Pour le bio-éthanol, on compte la culture (consommation des engins agricoles, engrais) et, de la même manière, la fabrication, le transport et la distribution. Ce rendement de l'éthanol est actuellement de 2. Des projections permettent d'espérer un rendement supérieur à 3 dès 2009.

    Pour cela, et en ce qui concerne le blé, l'agriculteur devra prendre en compte l'aspect énergétique de sa pratique culturale :

- Choisir les variétés les plus riches en amidon et les plus énergétiques. Ce ne seront pas les mêmes que les variétés boulangères
- Moins d'engrais azotés, coûteux en énergie et qui renforce le taux de protéines. C'est l'inverse du résultat recherché dans la culture du blé boulanger. Deux pratiques culturales vont cohabiter.
- Eviter le plus possible le labour. C'est la technique culturale la plus consommatrice d'énergie ( et de temps ). Les techniques de semis direct sont de plus en plus répandues. Elles ont aussi l'avantage de favoriser le stockage de carbone dans le sol ( jusqu'à 200 kg par ha et par an). Par là, elles contribuent aussi à la lutte contre l'effet de serre.

    C'est le deuxième avantage du bio-éthanol, et sans doute le plus décisif. En plus d'être une énergie renouvelable, c'est aussi une énergie propre. C'est la conjonction de cet avantage écologique et de la hausse irréversible des prix du pétrole qui font décoller une technologie prête depuis 20 ans, mais à des conditions économiques alors inacceptables.

- Aujourd'hui, le bio-éthanol et l'essence ont le même prix de revient hors taxes à 70$ le baril
- On considère que le CO2 émis lors de la combustion de l'éthanol est équivalent au CO2 consommé par la photosynthèse de la plante. Le bilan est donc nul, sauf à compter les émissions intermédiaires lors des processus de fabrication-transport et distribution de l'éthanol.
- Dans ces conditions, on considère que l'éthanol réduit les émissions de CO2 des 4/5 par rapport à l'essence

    C'est une belle idée que l'on étudiait à la fin des années 80 dans les commissions syndicales du C.N.J.A. Je retrouve aujourd'hui cette industrie de l'éthanol dans mon métier de l'informatique et de SAP. Voilà une boucle un peu originale mais assez savoureuse.

13/12/2006

L'informatique à 3 vitesses

 

Quelques  mois

Le Web3 fait l'actualité. J'ai dit tout le bien que je pense de cette initiative. Ca me permet de ne pas ignorer que parmi les projets sérieux, il y aura inévitablement un lot de mode, de fugace et d'éphémère . Le monde Web3 va à la vitesse d'un Youtube et de son succès fulgurant en moins de 18 mois.

D'après la classification de l'IT d' Andrew McAfee dont j'ai déjà parlé ici, le Web3 est dans la sphère du Network IT:

"Network IT. (NIT) provides a means by which people can communicate with one another. Network technologies include e-mail, instant messaging, blogs, and groupware like Lotus Notes."

Plusieurs années

medium_WTC_september.2.jpgRetour à une autre réalité de ce même XXIème siècle :

- 11 septembre 2001 : Une grande administration française prend conscience que son informatique est localisée sur un seul site, vulnérable  à n'importe quelle attaque ou catastrophe naturelle
- On y réfléchit pendant 2 ans avant de lancer un premier appel d'offre en fin 2003
- Deux ans d'études, d'avant-vente pour sélectionner la "short list" entre les différents soumissionnaires
- Encore un an pour affiner les différents projets
- Novembre 2006 : Nous gagnons l'appel d'offre avec notre partenaire
- Le planning prévoit la mise en oeuvre de ce projet sur 2007 et 2008 pour une 
                         recette finale en 2008

Il s'agit de mettre en place un PRI (Plan de Reprise Informatique) pour cette administration, lui permettant de continuer son activité et ses services en cas de catastrophe comparable au 11 septembre. De septembre 2001 à fin 2008, il se sera écoulé 7 ans entre la prise de conscience du besoin, jusqu'à  la recette finale de l'ensemble des procédures et des technologies supportant ce plan de secours. Ce monde lent est celui de l'Enterprise IT :

"Enterprise IT. (EIT) is the type of IT application that companies adopt to restructure interactions among groups of employees or with business partners. Applications that define entire business processes, such as CRM and SCM—as well as technologies, such as electronic data interchange, that automate communications between companies—fall into this category."

C'est toujours de l'IT, de l'informatique, mais est-ce bien le même métier ? Ce secteur de l'IT est devenu tellement central et énorme qu'il est sans doute appelé à se sectoriser, entre activités qui autont finalement peu de choses à voir entre elles, et qui surtout ne vivront pas sur les mêmes cadences.

Le plus gros acteur de l'EIT est l'allemand SAP. Le "SAP Investor Symposium" s'est déroulé à Las Vegas la semaine dernière, précédant de peu notre Web3 national. C'est pas VideoGag sur Youtube qui tiend la vedette! L'assistance a eu droit à une présentation sur un nouveau module fonctionnel : le GRC (Governance Risk and Compliance), la gestion des normes comme Sarbanes Oxley ou de réglements européens au niveau de la gestion des risques, de l'environnement ou du traitement des déchets :

"GRC ASPs increased 63% year-on-year
GRC is experiencing 15% quarter-over-quarter customer growth (2,000 GRC customers)"

C'est pas franchement sexy, on n'est sûrement pas dans le droit en écriture pour tout le monde, mais la croissance se fait aussi sur une activité ultra réglementée comme celle-ci.

SAP a aussi parlé de GRC (Gestion de la Relation Client) , Aaaargh!!! c'est pas le même...,Il s'agit en fait de CRM (Customer Relationship Management) et de l'annonce d'un portage du module CRM en mode hébergé (chez IBM d'ailleurs).

medium_doudou_mammouth_laineux_gd.3.jpgLe 2 février dernier, SAP annonce son intention de devenir lui aussi un fournisseur de logiciel distribué comme un service (Software as a Service)
Le 7 décembre à Las Vegas, lors de cette présentation aux analystes financiers, Shai Agassi l'un de ses dirigeants refait la même annonce
On attend la prochaine grand' messe SAP pour que l'on nous confirme, que oui décidément, SAP croit à ce modèle.


Pendant ce temps, Oracle, ou plutôt Larry Ellison s'apprête à récupérer sa mise de fonds dans NetSuite, le grand concurrent de SalesForce, un des pionniers du modèle SaaS, dont j'ai déjà parlé dans ce blog. En fait, les deux mammouths de l'informatique d'entreprise sont juste à l'affut pour voir si cette architecture va vraiment décoller. On ne vit pas au même rythme dans le monde de l'EIT, et le ticket d'entrée est beaucoup trop élevé pour que l'on puisse avoir la mauvaise surprise de se faire dépasser par un nouveau Google.

 

Microsoft unplugged

C'est ce qui pourrait arriver à Microsoft, le roi du troisième secteur :

"Function IT. (FIT) includes technologies that make the execution of stand-alone tasks more efficient. Word processors and spreadsheets are the most common examples of this IT category."

La sortie de Vista, après tant de retard, signe sans doute la fin d'un style, et d'une méthode de développement Software. D'après le SeattleTImes, Vista aura coûté 10 milliards de $ pour 10 000 personnes impliquées  et 5 ans de développement. Microsoft ne pourra plus se permettre ce type de gabegie.

La Function IT avec  Microsoft se situe entre l'Enterprise IT et le Network IT. Ses incursions dans l'Enterprise IT avec GreatPlains ou avec Navision  n'ont pas convaincu. En revanche, sa suite Live représente désormais une offre cohérente pour le Network IT.

La vraie bataille se jouera sur le front de la bureautique. Difficile de prévoir si la bureautique continuera à vivre sur son rythme pluriannuel actuel ou si elle s'exécutera dans le mode de changement frénétique à la Web 2.0, ou 3, ou 6. Pour réconcilier tout le monde, il se pourrait bien que cette apparente dichotomie se résolve par le mode déconnecté.

Une annonce intéressante de ce Web3 a sans doute été la sortie de "SocialText Unplugged" : du wiki qui permet de travailler en mode déconnecté puis de se synchroniser. C'est depuis longtemps le mode de fonctionnement des PDA (Palm Pilot et autres) et des téléphones.

 

Voila sans doute un avenir possible, et fécond pour le poste de travail.

17/10/2006

La fusée SalesForce

Premier étage de la fusée : Architecture Multi-Tenant


Salesforce.com jouit d'un succès impressionnant dans le monde du SAAS (Software As A Service). Le tableau ci-dessous venant du journal du Net montre qu'ils atteignent des chiffres comparables aux grands du secteur, les SAP, Oracle et Siebel (maintenant dans le même giron).



Les éditeurs de progiciels CRM dans le monde en 2005
(en millions de dollars)

Acteur

CA 2005

PdM 2005

CA 2004

PdM 2004

Evolution

SAP

1 474,7

25,9%

1 232,8

24,6%

+19,6%

Siebel

966,1

17,0%

908,3

18,1%

+6,4%

Oracle

367,5

6,4%

416,2

8,3%

-11,7%

Salesforce.com

280,7

4,9%

158,0

3,2%

+77,7%

Amdocs

276,4

4,9%

225,9

4,5%

+22,3%

Autres

2 332,6

40,9%

2 071,7

41,3%

+12,6%

Total

5 698,0

100,0%

5 012,8

100,0%

+13,7%



Son modèle d'architecture Multi-Tenant correspond bien aux besoins de sa clientèle PME. Cette architecture se caractérise par un partage des ressources matérielles et logicielles suivant différents modèles:

Hébergement partagé

  • On partage juste l'hébergement, les m² et les Kilowatts. En dehors de ça, mon application est autonome sur son ou ses serveurs.

Partage de serveurs et de disques

  • On partage le serveur et ses ressources CPU mémoire, mais mon application est autonome sur ce serveur. Autrement dit, mes données ne sont pas mélangées avec celles de mon voisin. Je suis dans ma base de données avec mon applicatif. Je ne partage qu'un serveur et son Operating System, ainsi que des moyens de stockage

Partage de l'instance logicielle

  • On partage tout, y compris l'applicatif et la base de données. Mes données sont dans les mêmes tables que celles de mon voisin; c'est l'applicatif qui me donne l'accès à mes données en masquant celles de mon concurrent.

  • Suivant les modèles logiciels, on peut configurer l'isolation des données par des systèmes de schémas ou par des mécanismes de filtre, ne permettant l'accès qu'à ses propres données. Dans un contexte différent, SAP permet, depuis longtemps, ce type de filtrage, par son système de mandant, qui rajoute automatiquement une clause « where » à tous les accès à la base de données.

    Si vous codez un « SELECT truc FROM machin » le runtime ABAP rajoutera automatiquement un « WHERE MANDT=<mon client de connexion> »

C'est évidemment ce dernier type de partage qui est le plus intéressant. Si l'application est bien architecturée, on peut bénéficier d'économies d'échelle importantes.

  • Des équipements dédiés sont dimensionnés pour pouvoir supporter des pics de charge. Ils sont rarement utilisés à plus de 15 à 20% en fonctionnement nominal.

  • A l'inverse, le partage de pool de serveurs et de stockage permet de lisser ces pics de charge entre les différents « tenants » (les différents « locataires »).

  • Si en plus, tout le monde partage le même code, la scalabilité devient maximale.

 



Salesforce.com a donc trouvé un bon modèle logiciel et économique qui permet d'exploiter cette désormais fameuse «Long Tail ». Le coût global d'un SAP ou d'un Oracle est souvent trop élevé pour un marché de petites PME.

 




Il reste alors un marché que ces gros éditeurs ne peuvent atteindre. Si je le baisse le coût unitaire, je peux attaquer ce marché. C'est le marché de Salesforce.com et de ses concurrents : NetSuite, ou SugarCRM.






Si Salesforce.com peut attaquer ce marché, c'est bien que cette architecture Multi-Tenant permet des économies d'échelle importantes, au niveau de la fourniture et de l'exploitation des infrastructures matérielles. Les coûts de projet sont également réduits par rapport à la mise en oeuvre d'un gros ERP comme SAP.

Tout ça paraît trop facile, et si les coûts sont faibles, c'est aussi que la palette fonctionnelle de SalesForce est loin de la richesse, donc de la complexité, et donc du coût d'un SAP ou d'un Siebel.

Deuxième étage : une place de marché logicielle



SalesForce a démarré en tant que fournisseur de solutions CRM, et parmi celles-ci les plus simples à mettre en oeuvre, c'est dire l'automatisation des forces de vente.

Avec sa plate-forme APPExchange, il a inventé et réussi à promouvoir un nouveau modèle. Cela représenterait 500 000 souscripteurs et 400 applications. C'est une place de marché logicielle, où l'on peut souscrire à des applications écrites par SalesForce ou ses partenaires. Il suffit donc de faire son marché dans le catalogue en ligne, de tester, et d'installer l'application de son choix.

DreamTeam est un exemple de ce type d'application. Elle permet le partage de projets, de calendriers et de documents. L'application est hébergée dans l'infrastructure de SalesForce. Elle est compatible avec Microsoft Project et Outlook.

Les conditions de prix sont disponibles sur le site:

« DreamTeam is free for individual use, $10 per user month for the Professional Edition, and $35 per user month for the Enterprise Edition.

Please contact us for more information.
Email:
dreamteam@dreamfactory.com
Phone: 1-888-399-DREAM (3732)

Pricing is also available at http://www.dreamfactory.com/dreamteam/ »






Certains contestent ces chiffres, ou en tous cas s'interrogent sur la qualité de ces applications:

« If we look at this “ecosystem” of 350+ applications, what is the breakdown? What might a stricter taxonomy look like? I recently compiled a list of these 350+ applications (I came up with 343, but I may have missed 8+) to do a little investigation. I found some wonderful tidbits of information. Did you know that at the time I retrieved the data (week of October 2, 2006)…

  • 24% of all listed applications were built by Salesforce.com rather than by partner vendors

  • that 6 out of the 8 (that’s right, 75%) “Most Popular” applications are apps built by Salesforce.com and that are free.

  • many of these apps extend the Salesforce.com main application functionality in ways that would traditionally classify the said “app” as a “plug-in” (Seriously, would anyone classify Clippy or the Microsoft Equation Editor as applications, or analogously would you buy a “song” on iTunes that was a Snare Drum Loop?) »



Troisième étage : le lancement d'Apex

L'annonce d'Apex la semaine dernière est le troisième étage de la fusée. La plate-forme Appexchange est maintenant ouverte à tous ceux qui souhaitent développer, avec le langage Apex déjà utilisé par SalesForce et ses partenaires.

SalesForce met à disposition son infrastructure technique et logicielle, chacun peut y développer ses propres applications dans ce langage. SAP a senti le danger et commence à sortir les canons. Je ne suis pas sûr que leur comparaison avec les autres langages (ABAP, PL/SQL ou PeopleCode) soit le vrai sujet. Les connaisseurs apprécieront ici la présentation technique de ce mélange de Java et d'appels SQL.

A l'évidence, personne n'a besoin d'un langage applicatif de plus, et cet Apex n'a rien de particulièrement renversant. Les difficultés que SAP ne manque pas de souligner par rapport à sa propre expérience sont tout à fait réelles. Il est probable que SalesForce sous-estime volontairement?, la marche entre son jeu d'applications actuelles et la mise à disposition d'un ERP complet. Mais l'attaque de SAP est hors sujet.

La nouveauté n'est pas là, mais bien dans cette initiative, qui tente de créer un écosystème, en invitant ses utilisateurs à créer de la valeur et à la déposer sur son site, pour les mettre à disposition de la communauté. Voilà qui est très tendance, et furieusement Web 2.0.

Il ne s'agit plus de partager des vidéos ou des photos de famille. On ne se contente plus de quelques commentaires sur tel film ou tel livre. SalesForce veut créer une communauté du même type pour les applications business. Par la même occasion, il part le premier pour établir un nouveau standard d'ERP sur le Web.

Le moins que l'on puisse dire est que le lancement est réussi. Les partenaires comme les concurrents (SAP en tête) ont bien senti qu'il se passait quelque chose de radicalement nouveau sur le marché de l'ERP et peut-être même de l'industrie du logiciel.

Cela fait longtemps que certains prévoient la venue de l'Utility Computing, consistant à se brancher sur une puissance informatique sur le réseau. On voyait bien le rôle des constructeurs, des éditeurs et des hébergeurs dans ce modèle. On n'avait sûrement pas prévu le rôle tout à fait majeur que prendront les utilisateurs dans la création et la diffusion de l'intelligence applicative.

Le PDG de SalesForce, Marc Benioff, n'oublie pas de faire du business (il faut quand même payer 10 000 dollars pour faire certifier une application par SalesForce). Sa personnalité tonitruante, et la capacité de SalesForce à exécuter cette stratégie impeccable ont créé les conditions nécessaires pour que d'autres s'engouffrent dans ce qui apparaît déjà comme un un nouvel âge.