Agenda :
OCTO organise le jeudi 26 janvier 2012 à partir de 8h45 un petit-déjeuner gratuit, à Eurosites George V « Tablettes : passons à l’ère du post-PC ».
Avec la participation de BNP Paribas Fortis, ARVAL et AXA.
Pour vous inscrire cliquez ici . Découvrez le descriptif de l’évènement et les intervenants dans ce billet.
En moins de 2 ans les tablettes se sont imposées partout. Elles ont cannibalisé le marché du PC et tué celui du netbook !
Internet, mails, réseaux sociaux, actualités ou jeux. Ceux qui ont essayée la tablette l’ont adoptée.
Rapidité, légèreté, simplicité, autonomie et prix sont au coeur de ce succès.
Vos entreprises ont l’opportunité d’épouser cette révolution et de faire évoluer leurs métiers, services et applications en tirant pleinement partie des tablettes. Les exemples ne manquent pas : outils d’aide à la vente, applications RH, bureau mobile, contrôle qualité in situ, documentation ou encore formation.
Et vous, quels usages faites ou ferez-vous des tablettes ?
Cet article fait partie d’une série de trois articles, dans laquelle nous allons définir ce qu’est un système mutualisé, expliquer les enjeux d’un tel système et nos recommandations pour démarrer sa construction, le pérenniser et en assurer la gouvernance. Nous nous attacherons à étayer nos explications de retours d’expériences.
Evaluer l’opportunité de lancer un projet de mutualisation et définir le périmètre d’un tel système n’est pas simple et doit faire l’objet d’une analyse en amont qui prend en compte plusieurs variables comme la valeur métier/sectorielle, l’homogénéité des processus dans les entités, etc. Dans ce contexte, l’article part de l’hypothèse que l’opportunité de mutualiser les processus de plusieurs entités de l’entreprise a été identifiée et que la décision de construire un système mutualisé est prise.
Pour réussir à mettre en place un système mutualisé, il faut non seulement réfléchir aux contraintes intrinsèques de la solution mutualisé mais aussi à celles liées au contexte de l’entreprise et à son organisation. Ceci dans le but de concevoir une solution unique faisant converger les processus tout en offrant suffisamment de souplesse pour permettre la subsidiarité nécessaire à chaque entité.
La construction d’un tel système représente un vrai challenge et un jeu de forces qui n’est pas simple à gérer. Néanmoins le projet peut être mieux maitrisé si dès le démarrage nous prenons en compte les éléments suivants :
Cet article est le deuxième d’une série de trois articles, dans laquelle nous allons définir ce qu’est un système mutualisé, expliquer les enjeux d’un tel système et nos recommandations pour démarrer sa construction, le pérenniser et en assurer la gouvernance. Nous nous attacherons à étayer nos explications de retours d’expériences.
Cet article est le premier d’une série de trois articles, dans laquelle nous allons définir ce qu’est un système mutualisé et les enjeux d’un tel système, donner nos recommandations pour démarrer sa construction, le pérenniser et en assurer la gouvernance.
Un système mutualisé est un système implémentant des processus et des fonctions communes à plusieurs entités. Ainsi, des systèmes multi-entité, multi-pays, multicanal de distribution à destination de populations d’utilisateurs différentes et multi-ligne de marché sont des systèmes mutualisés. Par exemple, les systèmes suivants sont des systèmes mutualisés :
La problématique des systèmes mutualisés a déjà été abordée par OCTO lors de l’Université du SI : Les SI multi-entité.
Signal sonore de fermeture des portes
- Ah salut ! Tu prends la ligne 7 toi aussi ? Alors c’est pour bientôt la mise en prod’ ?
- M’en parle pas, c’est dans 10 jours.
- Dis donc je vois passer une tonne de mails sur le projet..
- Oui, on n’a pas accès au bug tracker du client donc il nous envoie les bug reports par mail.
- Mince, ça en fait un paquet!
- Tout est relatif. Il y a surtout des demandes d’évolutions. Heureusement, Hubert monte au créneau pour renégocier ça avec le client.
(Lire la suite…)
C’est drôle, on sait tous qu’il n’y a pas, en informatique, de « silver bullet ». L’idée qu’une solution technique va tomber du ciel — ou du carquois d’un consultant — relève du voeu pieu, du deus ex machina, voire de la pensée magique.
Vous n’avez probablement pas obtenu vos diplômes parce que soudain quelques jours avant l’épreuve, vous avez trouvé LA technique idéale de mémorisation.
Vous savez que, statistiquement, l’EuroMillion n’enrichit pas ses clients (sinon les riches joueraient à l’EuroMillion).
Mais si vous êtes développeur, chef de projet, directeur d’études ou DSI, en revanche, vous êtes déjà probablement tombé dans le piège d’un nouvel outil ou d’une nouvelle technologie en vous disant : « Cette solution innovante va probablement marcher; en tout cas il le faut absolument (ou: en tout cas j’en ai vraiment envie). Je signe. »
(Lire la suite…)
A l’époque où je ne connaissais pas encore la démarche Test Driven Development, mon travail connaissait des hauts et des bas:
[Journal de bord - ca 1998]
Mon approche manquait de discipline. Je revoyais en profondeur mon design, sans savoir si le programme marchait ou non. Je cherchais mes erreurs avec un débogueur — cela prenait des heures. Croyant mon programme presque fini, je passais mes tests et découvrais que c’était loin d’être le cas. Mon moral aussi jouait les montagnes russes, passant de l’euphorie (“je suis génial!”) à la rage impuissante (coup de poing sur la table). Pas de quoi inspirer confiance à mes coéquipiers ou mon chef de projet.
(Lire la suite…)
En présentant les tests fonctionnels automatisés chez un client la semaine dernière, plusieurs questions ont été soulevées. La principale était celle-ci:
- Pourquoi écrire ces tests FitNesse/GreenPepper alors que j’ai déjà des tests unitaires JUnit qui couvrent la même fonctionnalité ?
La question est justifiée. Voici quelques éléments de réponse, tirés de nos échanges sur les mailing-lists OCTO…
Dans ce billet, nous nous basons sur un expérience vécue de mise en place d’une méthodologie (Scrum) sur un projet de développement, pour analyser un piège qui, selon nous, guette toute organisation désireuse de s’améliorer via l’adoption d’une méthodologie : le piège de l’Artefact.
