Thursday, February 20, 2014

Note about the EMR wicked problem (as seen in France)

Note for myself about the tackling of the EMR wicked problem (as seen in France)

At first sight, healthcare actors and, especially, practitionners didn't spot the actual complexity of the nation-wide EMR program (hospital ERP), that's why they didn't see the need for a competitive approach to tackling this wicked problem.

Both collaborative and authoritative approaches would have failed for such a program. The collaborative approach would have taken dozens of years. The authoritative approach would have garnered too many opposition to succeed.

As a result, the program is a succes yet the approach as been seen as overly complex and costly by many actors.

Friday, August 30, 2013

Passer du temps sur Klout augmente votre score Klout!

Constat : plus je passe de temps sur Klout, plus mon score augmente.
Pas de recette miracle : ce n'est pas parce que je passe du temps sur Klout que mon score augmente, cependant le constat est vrai. Plus je passe de temps sur Klout plus mon score augmente, ce pour deux raisons qui valent aussi bien pour tous les réseaux sociaux (informatiques ou non, d'ailleurs) :
  1. Si je m'y intéresse, si j'y investis mon temps, l'investissement finit par payer. A force de fréquenter le réseau, je vais finir par comprendre ce qui y fonctionne bien. Dit autrement, le réseau est un investissement, on ne peut pas espérer un bénéfice sans fournir un apport. (Correlation does not imply causation, yet it does mean correlation.)
  2. Pour Klout comme pour les autres réseaux sociaux, il faut mettre en place une discipline. Un petit investissement de temps chaque semaine rapporte plus qu'un grand évènement ponctuel. De la même façon, le score Klout augmente plus en investissant progressivement plutôt que par actions d'éclat.

Monday, August 12, 2013

Indicateurs du début de la fin en DSI 2

Suite au succès du premier article, j'en poste un second sur le même thème : ces signaux faibles qu'un DSI devrait apprendre à reconnaître pour éviter le naufrage ou, souvent, l'accumulation d'inertie qui mène au naufrage.
Aujourd'hui, deux petits nouveaux.


Iceberg n°1 : Le ratage d'un tournant métier. Votre entreprise développe une nouvelle activité, c'est une petite branche de l'activité et représentait à peine un pourcent du chiffre d'affaires hier. Vous n'y avez accordé que peu d'attention. Seulement, aujourd'hui, le marché a changé et cette activité représente 35% du chiffre, plus à venir.
Comme vous n'aviez pas donné suffisamment d'attention à cette activité, les relations avec son directeur sont au plus bas et il demande des changements radicaux. Changement de têtes ou... fournisseur externe.

Icerberg n°2 : La gestion des assets (des actifs). Mettre en place une gestion des actifs sur une flotte donnée (PC, smartphones, imprimantes, voitures, bornes WiFi) permet d'en diminuer le coût de 30% très rapidement, et plus avec le temps. Malheureusement, si la gestion des assets s'encroûte, si elle ne suit plus les évolutions récentes et finit par n'avoir que quelques dizaines de pourcents de données à jour, on va droit à l'échec, là encore.
Les projets de gestion des assets ne sont pas des silos applicatifs mais des projets structurants transversaux et doivent faire l'objet d'une attention extrême à leur démarrage. Il s'agit d'un véritable investissement. Investissez sur une gestion opensource, évolutive, avec le personnel correspondant ou bien sur une solution propriétaire mais de fonctionnalités très largement supérieures à vos besoins. Par contre, ne vous lancez pas dans l'utilisation de solutions intermédiaires propriétaires qui vous empêcheront *absolument* de faire évoluer votre gestion des assets.

Sunday, August 11, 2013

Security ROFL 10

10th article of this successful series.

From Kevin Mitnick's Twitter status, this one really made me roll on the floor :

Old Dilbert still applicable in many SMBs security ;-)

A tweet from ISSA_France:
— Gargamel, how did you find our village?
— Google Maps.

Saturday, August 10, 2013

Comparing Salaries: USA vs. France

When you're looking for a job worlwide, it's not easy to compare salaries, taxes and social benefits from one place to the other. However, it's a good time investment to do so, there can be quite surprising results. Herebelow, a comparison of income for the same job advertised for $100,000 in France and in the USA. Although the net salary is lower in France, the whole of salary + benefits is far higher in France than in the US with the same advertised job.
(calculations are for a single, no children, with a sample state tax of 10%, and may not be perfectly accurate, they're made to give a comprehensive view)

USA  Amount France France in €
6,200 $  employer contribution to social benefits 63,139 $ 47,338 €
100,000 $  advertised job salary 100,000 $ 74,973 €
17,250 $  federal income tax as a single 13,365 $ 10,020 €
10,000 $  typical state tax as a single 0 $ 0 €
7,650 $  social benefits 23,001 $ 17,244 €
13,850 $  TOTAL social benefits 86,140 $ 64,582 €
75,100 $  TOTAL net take home salary 63,634 $ 47,709 €
88,950 $  TOTAL salary + benefits 149,774 $ 112,291 €

Friday, August 9, 2013

Short CV, Long CV or LinkedIn?

I've been following Jeff Snyder's Security Recruiter Blog for years now. Jeff is a professional recruiter in the security world, both general corporate security and IT security. He also has a professional security résumé writing service and a job coaching service for security professionals.
We've been talking multiple times about the proper length of a résumé and he recently published an article about it. At the same time, the HBR Network blog also suggested that the CV might be obsolete in a LinkedIn world.

Well, I do think you need both a CV and a LinkedIn profile. I even think you should have two CVs and a LinkedIn profile. I found that arsenal quite useful during my last series of job interviews.

 
The LinkedIn profile is here to attract unsolicited recruiters. It should be full of keywords and a short description of each job you had. It is public and should not contain anything not to be displayed on the public place. If you display too much about your previous employers, your potential future employers might dislike it.
As it will also be consulted by solicited recruiters, it should, if possible, include credibility items, such as recommendations or links to publications that will support your application.

The Short CV is  here to survive traversal of HR services or external non-specialized recruiters. That's the one that should be fashionable enough, give details about your education, training, availability, etc. The professional experience part can be short enough, it should only detail your last job, in terms of responsibilities. This CV must be short, like one or two pages.
As I recently told Jeff, I can confirm this shortness is indispensable if you're applying in Latin European countries (France, Italy, Spain, Portugal, Romania and, to some extent, Belgium and Switzerland). For cultural reasons, the résumé can be a little longer in Germanic countries such as Germany, Denmark, the Netherlands or Luxemburg. Yet not too long.

The Long CV is here to help convince your potential future boss. Bring it during the (first) job interview. An interview is often a short period of time of which little remains but a global feeling. During the interview, you can give that Long CV as a new token, full of details, that will help your potential future boss remember you.
This CV should detail your past accomplishments in every relevant past job, with figures if possible. It can go in the less public areas of what you did to address real-life problems at your previous employers. It's the place to convince your potential future boss you'd be a profitable asset. As your potential future boss will invest time in its reading, he/she will be more keen on putting your CV on top of the pile because of the investment already made on it.

I'm not looking for a job anymore right now but I'd advise any job searcher to try that strategy.

Thursday, August 8, 2013

Indicateurs du début de la fin en DSI

Il y a de ces signes qui ne trompent pas, le navire DSI va droit à l'iceberg. Avec le temps, on apprend à en connaître certains. On devrait pourtant les partager davantage. Ci-dessous un petit florilège.

Il y a cet outil réseau, made in DSI, que j'appelle les SOCKS-étoile-étoile. Les SOCKS ou, dans leur implémentation Microsoft, les Winsocks, ont été développés pour permettre d'offrir un traitement de type "proxy" aux protocoles qui n'ont pas été développés pour être proxyfiés. Très belle attention.
Dans la pratique, une DSI a souvent un proxy pour le web et un firewall pour le reste. Le firewall étant lourd à configurer, on n'y rajoute pas souvent des règles et la DSI "installe les SOCKS" à un utilisateur qui a des besoins réseaux inhabituels. N'ayant pas le temps de les configurer, la DSI établit une configuration de base qui autorise tous les protocoles réseau, vers toutes les destinations (ce que j'appelle étoile-étoile ou *:*), avec la promesse que ce ne sera que temporaire. Sauf que le temporaire devient permanent et que les utilisateurs SOCKS-ifiés se multiplient. A ce rythme, en un rien de temps, le proxy et le firewall sont devenus inutiles et les terminaux des vrais nids à virus.

Il y a ceux dont le nom seul évoque l'échec d'une DSI, comme Microsoft Access. Partant d'une très bonne intention, complémenter le service informatique pour les petits problèmes locaux, les utilisateurs développent des "bases" en Access.
Elles sont développées sans les compétences en développement => Elles deviennent in-maintenables, du vrai Write-Only. Elles sont développées loin des cadres de l'informatique de l'entreprise => Elles ne s'intègrent pas aux processus de la DSI, telles la sauvegarde ou la documentation. Dans le meilleur des cas, elles occasionnent des coûts imprévus gigantesques lorsqu'il faut les intégrer dans un cadre plus sérieux, c'est-à-dire les re-développer depuis zéro. Dans le pire des cas, les services en deviennent dépendants et, quand elles craquent car mal développées et non sauvegardées, elles occasionnent des arrêts de travail de ces services.
Certaines grandes entreprises ont même pris l'initiative d'interdire Access dans toute l'entreprise.

Menace plus insidieuse qu'Access, il y a les outils équivalents à Access. Un exemple : FileMaker Pro. On ne s'en méfie pas car il est cher. On se dit donc que ceux qui l'achètent en feront un usage raisonnable. Point du tout : soit il est utilisé à la DSI et il devient un outil comme un autre, soit il est utilisé par des utilisateurs finaux bien-intentionnés et c'est la rebelote d'Access. Pire encore, devrais-je dire, car les vraies compétences sur pareils logiciels sont plus rares et plus chères que celles sur Access.

Un autre outil vicieux est le tableau croisé dynamique d'Excel. Quelle belle fonctionnalité ! Cet outil permet de faire des calculs, des comptes, des sommes sur des tableaux de données. On lui donne les données, on lui dit quels champs compter, sommer, et il se débrouille... en théorie. C'est un outil magnifique pour la recherche, pour l'analyse ponctuelle de données, mais en aucun cas pour la fabrication de chiffres en production. Il est trop complexe, trop lié à sa représentation à l'écran dans Excel, difficile à manipuler. Résultat, trop souvent on obtient un résultat sans être absolument certain que ce soit le bon. « J'obtiens tel nombre d'occurrences du problème X, mais est-ce en comptant les doublons sur les deux tableaux ou sans les compter ? » Un bon outil théorique mais pas pour la prod.

Sur le plan managérial, il y a un indicateur net d'iceberg droit devant : l'externalisation d'un silo applicatif (cloud ou non). Si c'est un petit silo, ce n'est pas très grave, mais s'il est grand et qu'il est vraiment silo, c'est-à-dire que tant l'application que son infrastructure, sa maintenance et ses évolutions sont externalisés, alors il y a vraiment du souci à se faire : la DSI a un concurrent au sein de l'entreprise.

Un autre indice qui devrait mettre la puce à l'oreille quant à un possible iceberg est l'accumulation de tickets non traités concernant une application donnée. Ces tickets peuvent être minimes, bénins voire obsolètes mais ils renvoient une image négative et leurs auteurs s'impatientent, voire se désespèrent. C'est ce genre d'accumulation qui mène une direction à jeter le bébé avec l'eau du bain concernant un système qui marchait, dans l'ensemble, plutôt bien.

Et puis il y a le manque de plan de continuité. Le principal indice, c'est quand tout le monde parle du PCA mais que personne ne sait par où commencer, que chacun prend ses petites initiatives de son côté mais que personne ne sait qui en est responsable.

C'est un tout petit extrait et j'en rajouterai sans doute.