J'essaie de savoir pourquoi vous décidez quand faire quoi. Je suis heureux de fournir plus de contexte, mais je veux le rendre général pour l'instant.
J'essaie de savoir pourquoi vous décidez quand faire quoi. Je suis heureux de fournir plus de contexte, mais je veux le rendre général pour l'instant.
Réponses:
C'est trop simplifié, je suppose, mais ce genre de chose vaut pour une ligne directrice générale:
ET:
Si oui, je préfère l'écrire que l'acheter.
Si le coût total de possession du produit (y compris le développement, les tests, la maintenance, le support ou toutes les dépenses connexes) est supérieur au coût du produit et que le retour sur investissement calculé ne compensera pas ce coût, alors vous êtes mieux vaut l'acheter et passer à autre chose.
Éléments à considérer pour une décision de faire ou d'acheter
coût de développement / coût de maintenance vs. coût du produit / coût de contrat de maintenance: bien sûr, c'est la chose évidente, mais ce n'est pas la seule. Par exemple, si je vais utiliser le logiciel non seulement pour ma propre entreprise, mais aussi que je souhaite le vendre à d'autres, alors le calcul est très différent
Disponibilité d'un produit adapté. Pour de nombreux processus métier, il n'existe tout simplement pas de logiciel standard disponible. Ou il y a quelque chose de disponible, mais il ne convient pas, car il contient 100 fonctionnalités dont vous avez besoin de seulement 3 de manière légèrement différente, tandis que 2 autres fonctionnalités importantes manquent.
Veut-on devenir dépendant d'un fournisseur tiers? Les fournisseurs particulièrement petits vous offrent toujours le risque que le fournisseur disparaisse du marché à l'avenir, ou que le développement ultérieur du produit n'aille pas dans la direction dont vous avez besoin. Pour un produit que vous avez sous votre contrôle, vous pouvez mieux orienter la direction du développement.
Quand ai-je besoin d'un logiciel spécifique, et qu'est-ce qui va plus vite: le développer moi-même, ou acheter quelque chose, l'adapter jusqu'à ce qu'il soit adapté à mes processus et le déployer? Acheter quelque chose dans l'étagère peut sembler l'alternative la plus rapide et parfois la moins chère, mais j'ai personnellement vu des scénarios où le développement d'un logiciel exactement pour les besoins d'une entreprise, adapté aux processus commerciaux existants, a fait gagner beaucoup de temps par rapport à l'achat de quelque chose et l'enseignement de plusieurs des centaines d'utilisateurs pour faire leur travail d'une manière nouvelle et différente, que les coûts de développement étaient négligeables.
Tout ce qui a à voir avec la cryptographie. Il y a 100 000 façons de le faire mal et d'exposer votre logiciel à de graves failles de sécurité et seulement quelques façons de le faire correctement. Une expertise élevée est nécessaire pour cela.
Sur le plan personnel, je développe une combinaison étrange de ce que je veux et de ce qui serait intéressant à écrire.
Sur le plan professionnel, @haylem fait un bon point global sur le moment d'acheter par rapport au moment d'écrire. Je dirai qu'il y a un énorme élément qui est négligé: l'opportunité. Pour les grandes entreprises, il est souvent judicieux, à mon avis, d'écrire des applications métier de base personnalisées (pas toutes les applications métier) lorsque cela rend l'entreprise plus agile. Il y a un coût d'opportunité associé à l'achat de logiciels, car votre entreprise (et pas seulement votre informatique) est verrouillée dans la façon dont le fournisseur considère votre domaine.
Pour la plupart des choses, cela n'a pas d'importance. Votre système comptable a intérêt à ne pas être créatif. Votre traitement de texte sera le même que n'importe qui d'autre. Mais les choses qui font de vous peuvent être mieux rédigées en interne afin qu'elles puissent s'adapter à ce que votre entreprise essaie d'accomplir.
Il s'agit, comme presque toutes les autres réponses, d'une décision coûts-avantages:
Il s'agit de savoir si le coût, compensé par les avantages, d'une solution développée sur mesure est inférieur au coût du produit standard.
Il y a aussi des coûts d'opportunité à considérer. Comprenez que ceux-ci ne doivent pas être inclus dans les coûts réels de développement vs achat, mais dans le monde plus large, vous devez les considérer. Si votre personnel de développement interne travaille sur ce seul projet, il ne travaille sur aucun autre projet; cela signifie que s'il y a un autre projet sur la liste qui vous coûte de l'argent chaque jour, ce n'est pas fait, cela pourrait bien être une priorité plus élevée vous obligeant à suspendre ou même à annuler le développement personnalisé et à aller avec le package standard. Cependant, si vous ne réalisez pas ce projet, votre personnel interne est assis sur ses mains, le coût du développeur est irrécupérable; vous payez votre équipe de développement, qu'ils travaillent ou non, donc cela vous coûtera globalement moins cher si vous les utilisez à leur plein potentiel.
Je suppose que vous posez la question dans un contexte professionnel et commercial, et que nous parlons d'une partie majeure de votre système plutôt que d'une bibliothèque unique.
Dans certaines situations, votre organisation peut utiliser un produit standard. Par exemple, peu de gens écriraient leur propre traitement de texte - ils utilisent MS Word, ou OpenOffice, ou autre chose. Idem pour les feuilles de calcul. Notez que vous pouvez "personnaliser" votre traitement de texte avec vos propres modèles ou macros, mais les gens ne le considèrent pas comme une personnalisation. C'est juste "utiliser" le traitement de texte, comme ils le voient.
Il pourrait être possible d'utiliser des systèmes plus complexes de la même manière, des boutiques en ligne aux systèmes ERP. Mais il arrivera un moment où vos concepteurs ou les responsables du développement commercial voudront un changement qui n'est pas inclus dans la norme. Une refonte de la page de paiement, peut-être, ou une nouvelle façon de calculer les offres de rabais.
Si vous le savez depuis le début, votre décision est vraiment de créer ou de personnaliser . Just Buy n'est plus une option. Et même s'il n'y a pas de telles exigences en ce moment, pensez-vous que vos collègues les présenteront plus tard?