Capitalizing software development costs from SDLC to Agile.

http://itprojectfinancials.com/insights/2011/06/05/capitalizing-software-development-costs-from-sdcl-to-agile/

Par Michael Gentle

Les couleurs de l’argent

L’argent a diverses couleurs, de vert aux États-Unis à toutes les couleurs de l’arc-en-ciel selon les pays. Dans l’informatique, l’argent a seulement deux couleurs: Capex et Opex.

Il y a diverses régulations nationales et internationales et diverses normes comptables (comme FASB et IFRS) qui fixent des directives claires pour Capex versus Opex quand on développe du logiciel pour un usage interne. Notez que ces directives ne dictent pas si les sociétés doivent capitaliser ou pas, seulement les règles qu’elles doivent suivre si elles décident de le faire. Comme nous le verrons plus loin, quelques sociétés capitalisent leur développement logiciel tandis que d’autres le passent en dépenses.

Maintenant, indépendamment d’où se trouve votre service informatique, vous devriez toujours pouvoir comprendre le débat sous-jacent, parce que, au bout du compte, tout se réduit aux chiffres – Capex ou Opex.

Le règne du Capex contre Opex dans l’informatique

Alors que couvrent les règles comptables ? Essentiellement les trois phases suivantes du développement logiciel, basé sur l’approche « Waterfall » ou le Cycle de vie de Développement de Système (System Development Life Cycle : SDLC) (nous parlerons du développement itératif ou agile un peu plus loin) :

Étape préliminaire ou phase d’évaluation de projet, qui établit la faisabilité technique du projet. Ceux-ci sont essentiellement des coûts R&D et sont facturés en Opex, parce que, si le projet s’arrêtait là, il n’y aurait aucun actif duquel parler.
Développement logiciel ou phase de configuration d’application. Tout le développement et travail de configuration ultérieur à la faisabilité technique est du Capex. Le résultat final est un actif, comprenant le logiciel (acheté ou construit), le matériel et l’infrastructure.
Mise en œuvre ou phase de production. C’est de l’Opex parce que ceux-ci sont des coûts de fonctionnement quotidiens.

Maintenant, si seulement c’était aussi simple! Malheureusement, ce n’est pas de la science ni de l’ingénierie (bien que nous aimions souvent penser que c’en est! ). Par exemple:

Des licences d’utilisation d’un logiciel d’entreprise sont du Capex, mais les coûts de maintenance annuels correspondants sont de l’Opex.
L’étude fonctionnelle est de l’Opex et la conception technique est du Capex, mais la frontière entre les deux peut être trouble quand réalisée par des équipes collaboratives.
Les mises à jour de production ou améliorations sont capitalisables, tandis que la maintenance et la correction de bogues ne le sont pas, bien qu’ils comportent tous les deux des coûts de développement. C’est parce que les premières augmentent significativement la valeur de l’actif, alors que les dernières ne le font pas.
Une interface de prise de commande entre ERP et CRM est un coût d’investissement, tandis qu’une interface de migration de données d’ERP à CRM est une dépense. C’est parce que la première est une partie intégrante de l’actif, qui produit une valeur à long terme, tandis que la seconde est unique sans future utilisation alternative.
Les déplacements et voyages sont normalement des dépenses – sauf quand elles font partie d’une Activité Capitalisable!
Un logiciel en tant que Service ou Software as a Service, SaaS est du pur Opex. Même si vous finissez par personnaliser l’application SaaS, les coûts de développement seront toujours de l’Opex parce que vous louez. Vous ne possédez pas l’actif : Il ne se trouve pas sur le bilan de votre société.

Une chose à retenir de ces exemples est que ce n’est pas l’activité en soi qui est Capitalisable (Eg Développement), mais plutôt le Résultat de cette activité et la propriété de l’actif résultant. Ainsi quand nous disons « Le développement et le test sont Capitalisables », ce que nous disons vraiment est qu’ils sont Capitalisables à cause de leur Résultat, parce qu’ils sont utilisés pour construire un actif complètement en votre possession qui produira de la valeur économique à long terme.

Comme vous pouvez voir, il y a beaucoup de place pour l’interprétation, aboutissant aux différences de façons dont les sociétés capitalisent les coûts. Alors comment le manager lambda de projet ou d’application – pour lequel la plupart du susdit est probablement une nouveauté – produit-il des prévisions budgétaires et de coûts appropriées qui puissent résister à un audit ? (Testez votre propre niveau de connaissance avec le Questionnaire suivant).

La réponse principale se trouve dans leur niveau de connaissance financière. Malheureusement, une autre enquête démontre qu’environ 50% des personnes interrogées ne connaissent pas la différence entre Capex et Opex et 80% n’ont jamais eu une quelconque formation financière au cours de leur carrière. Cela peut être atténué dans une certaine mesure par le niveau de support qu’ils obtiennent du service financier et le degré avec lequel les systèmes d’ERP peuvent être configurés pour implémenter automatiquement certaines de ces règles.

Et en ce qui concerne le développement interactif ou Agile ?

Les susdites règles comptables et directives sont basées sur la méthodologie « Waterfall » ou SDLC, et ne peuvent pas être appliquées directement au développement itératif ou agile avec son approche collaborative, des cycles courts et l’absence d’une grande conception en amont. Cela signifie qu’il n’y a aucun jalon de processus clair pour la faisabilité technique, ce qui exige donc une approche différente pour identifier le début de la capitalisation.

Selon FASB, la faisabilité technique peut être basée sur une conception détaillée ou sur un produit qui fonctionne :

Conception détaillée : « La conception dans le détail d’un produit logiciel qui amène la fonctionnalité du produit, ses caractéristiques et les besoins techniques à leur forme la plus détaillée et logique, prêts à être codés ».
Maquette (ou prototype) : « Une version opératoire du produit logiciel qui est réalisée dans le même langage de programmation que le produit final commercialisable, qui fournit toutes les fonctions majeures prévues pour le produit et est prête pour le test de client initial (d’habitude identifié comme un bêta test) »

Dans le développement itératif ou agile, comme l’explique le consultant et spécialiste agile, Craig Larman, la faisabilité technique sera donc atteinte après un certain nombre d’itérations (appelé des sprints dans la méthodologie Scrum) après lesquelles la capitalisation peut commencer. Cela correspondrait au jalon « fin de conception » de Barry Boehm’s Life Cycle Architecture, ou en méthode Rational Unified Process (RUP).

Une autre différence clé entre SDLC et agile est la quantité de coûts de développement qui peuvent être capitalisés, qui sera en général moindre que sous l’approche détaillée de conception SDLC. C’est parce que le développement initial est fait pendant des itérations Antérieures au fait d’atteindre la faisabilité technique, tandis que dans SDLC tout le développement est fait Après la faisabilité technique (ce qui souligne de nouveau le point fait plus tôt que c’est le résultat plutôt que l’activité qui est l’un des critères principaux pour Capex versus Opex). Mais c’est peut-être un point discutable, parce que le développement itératif exige généralement beaucoup moins de temps pour atteindre la faisabilité technique que SDLC, qui est lourdement chargé en amont en Opex avant le début de tout développement.

Dans tous les cas, ceux distinctions agiles versus SDLC ne se voient pas très souvent en pratique, parce que, non seulement le développement agile n’est pas la norme dans les services informatiques, ceux qui le pratiquent ne le font ainsi à une échelle assez grande pour justifier la capitalisation. Et les sociétés qui pratiquent vraiment à grande échelle le développement itératif ou agile sont d’habitude les sociétés de développement qui ne capitalisent pas de toute façon (voir le point ci-dessous).

Capitaliser ou pas, telle est la question

Comme mentionné au début de cet article, quelques sociétés capitalisent leur développement logiciel tandis que d’autres le considère comme une dépense. Qu’est-ce qui commande de telles décisions ?

Nous devrions d’abord faire la distinction entre des sociétés de développement de logiciels (dont c’est le métier fondamental, Eg Vendeurs logiciels) et les sociétés dont le métier fondamental n’est pas cela, Eg construction de biens ou laboratoires pharmaceutiques :

Sociétés de développement de logiciels Comprenez que l’informatique est indiscernable de la R&D – en effet, comme Craig Larman l’indique, historiquement l’informatique s’appelait R&D ou Développement de Systèmes ou Ingénierie. Par conséquent, ils ont fait une comptabilité appropriée tant qu’ils ont été là, souvent ils se sont basés sur l’ingénierie simultanée et des équipes transverses. La norme pour les sociétés de développement de logiciels est de considérer l’informatique comme une dépense (voir l’enquête dans le rapport 2006, , Capitalization of Software Development Costs: A Survey of Accounting Practices in the Software Industry, dans laquelle 146 sur 207 sociétés logicielles n’ont pas capitalisé leur développement logiciel).

Les services informatiques internes Et leurs contrôleurs de gestion ne voient pas GÉNÉRALEMENT l’informatique comme de la R&D; Eg dans un laboratoire pharmaceutique, la R&D c’est créer des médicaments, pas construire du logiciel. Donc la méthodologie SDLC dominante prévaut, avec les méthodes comptables qui se prêtent plus au Règles FASB Capex versus Opex décrites dans cet article. Cependant, cela ne signifie pas que tous capitalisent. Certains le font et d’autres ne le font pas.

Une raison clé de passer des coûts en dépenses, identifiées à la fois par Luigi Paraboschi (VP de Finance à HP à Genève) et Eugene Nisker (PDG de Evident Point Software À Vancouver), est de comptabiliser les coûts plus tôt et donc réduire au minimum le poids fiscal à court terme.

D’autres raisons incluent une combinaison d’un faible coût total de projet, un court temps de service et peu de temps entre la faisabilité technique et l’achèvement du développement logiciel. J’ai interrogé un certain nombre de personnes sur cela en Europe, aux USA et au Canada et leurs réponses sont allées de zéro ou très peu à 50/50 (Suraj Nekram, PDG de SteelGlass Consulting au New Jersey). J’ai personnellement travaillé bien plus avec des services informatiques qui capitalisent qu’avec ceux qui ne le font pas.

Alors qu’il n’y a aucune bonne ou mauvaise façon puisque toutes les deux sont financièrement légales, l’opinion communément admise tient à ce que le CIO « préfèrent » Capex parce qu’il réduit le budget informatique de l’année en cours, tandis que les investisseurs préfèrent Opex parce que l’on peut voir la capitalisation comme une augmentation artificielle des profits de l’année actuelle. En répercutant cette vue, le site Web financier Investopedia, Dans un article sur le cash-flow, dit que l’Opérateur de télécommunications « Verizon a voulu inclure le logiciel capitalisé dans ses dépenses d’investissement » Tandis que « Microsoft classifie avec responsabilité tout développement comme un coût … qui améliore la qualité de son cash-flow des d’opérations » (Le terme Avec responsabilité dit tout …). Pour Luigi Paraboschi, l’accessibilité est un critère clé : si votre compte de pertes et profits peut se le permettre, c’est mieux de considérer l’IT comme une dépense.

En conclusion

Au final, si vous y travaillez dans l’informatique, indépendamment de si votre société capitalise ou pas le développement logiciel, vous devriez toujours pouvoir comprendre la mécanique sous-jacente. Tôt ou tard, quelque part, entre la planification des prévisions d’investissement budgétaires et la gestion et l’imputation des coûts, vous entendrez un CIO, un chef de produit, un directeur de PMO ou un contrôleur de gestion amener ce sujet. Alors, comme le dit la formule consacrée « 1 PM averti en vaut 2 ! »