fookooflakman | Voir ce message dans le sujet non filtré
akabis a écrit :
Ne n'ai jamais dit ca, surtout que le terme que l'on emploi généralement est non gouvernance mais co-gouvernance des SI donc piloté par les métiers.
Ensuite pour TOGAF je n'ai jamais dit qu'il ne prenait pas en compte l'ensemble des strates de l'entreprise.
Encore une fois il faut lire les choses.
Je dis simplement que c'est un projet d'entreprise ou à chaque strate, il y a un travail à faire:
- non seulement de photographie et je pense qu'un seul outil (en l'occurrence TOGAFF) ne peux couvrir tous les champs car chaque partie à des outils extrêmement performant
- Mais surtout repenser chaque partie pour améliorer la performance globale de l'entreprise, et là encore, ce n'est pas le rôle de TOGAF.
Dans ton exemple, tu surlignes architecture business... je suis désolé mais ce n'est pas TOGAFF qui va t'apporter les outils du management stratégique, discipline qui concerne la stratégie d'entreprise.
Quel est le but de l'outil?
créer une architecture SI orienté business dans le but d'améliorer les performances du SI
Si le process business est mauvais, l'urbanisation des SI ne l'améliorera pas
Par contre, ce que j'ai expliqué depuis le début le fera lui
Le problème, et c'est flagrant chez les techniques, est que tu vois le SI comme la solution alors que ce n'est qu'un outil (si tu ne sais pas planter un clou, tu peux avoir le meilleur marteau du monde... tes clous seront toujours de travers).
D'où l'incompréhension de ce que j'explique depuis le début.
Après tu peux me balancer les liens que tu veux, j'ai une formation initiale technique doublée d'une formation initiale en gestion d'entreprise (IAE). Et en tant qu'ancien manager de transition et DSI, des projets comme celui-ci j'en ai fait quelques uns.
J'essaye juste d'expliquer la différence entre l'outil (le SI) et la solution (les process) et que ce sont bien des disciplines différentes et que ton référentiel Togaf ne peut pas faire pas les 2.
Tu ne veux pas l'entendre et tu veux avoir raison... très bien, que veux tu que je te dise d'autre.
|
Je mets de côté :
- ton argument d'autorité qui n'apporte pas grand chose à la discussion (ok tes diplômes et ton expérience sont chouettes),
- ton souhait de me faire dire que l'IT est magique et résout tous les problèmes sans même que je n'ai esquissé l'ombre de cette idée,
- ton raccrochage aux branches en essayant de parler de stratégie alors que le but de mon argumentation est uniquement de déconstruire ton idée que l'architecte est un pur technicien de l'informatique.
Je tente une dernière approche : ici ça dit bien que des outils comme UML ou BPMN font partie des outils servant l'architecture business.
Non, l'architecte ne se contente pas d'apporter des solutions techniques à des processus métier tout fait. Son rôle est aussi de modéliser les processus et doit donc pouvoir challenger un processus métier.
Et si, justement, il est là pour réconcilier les process métier avec l'évolution du SI sur le plan technique, c'est là tout l'enjeu de ce job.
Cependant, si le responsable/directeur du métier se fourvoie en considérant que l'architecte d'entreprise "n'est qu'un informaticien qui essaie de m'apprendre mon métier, mais quel connard" alors en effet, ça ne sera que rarement productif.
Et réciproquement, s'il est hiérarchiquement rattaché au métier, il se peut qu'il se trouve à parler à un DSI qui se dirait que "ce n'est qu'un utilisateur qui essaie de m'apprendre mon métier, mais quel connard".
Ce rôle n'est probablement pas être très simple à endosser dans certaines organisations.
edit :
Citation :
Quel est le but de l'outil?
créer une architecture SI orienté business dans le but d'améliorer les performances du SI
|
Non, la finalité est d'améliorer les performances du business, le SI n'en est que le support. |
FORUM HardWare.fr
