CASO SUBCONTRATACI N DE TERCEROS

CASO SUBCONTRATACIÓN DE TERCEROS
Desde comienzos del desarrollo de programas o “software”, las organizaciones han luchado con la pregunta: Construir o comprar? Es decir, ¿debería una organizacióndesarrollar el software de forma interna (“in-house”) o deberían comprarlo a terceros, como por ejemplo, una compañía de consultoría en programación? Hoy día, miles de compañías de consultoría compitenpor los millones de dólares que genera la industria de subcontratación para desarrollo de software (“outsourcing”).
Muchos ejecutivos creen firmemente que la organización debe enfocarse en la misiónde la organización y no desperdiciar valiosos recursos en el intento de convertirse expertos en desarrollo de “software”. Por ejemplo, una escuela debería enfocarse en la educación y subcontratar parael software que necesiten, como por ejemplo, desarrollar un nuevo sistema de matrícula.
Aquellos opuestos a la subcontratación (“outsourcing”) creen que la organización se beneficia más manteniendoel desarrollo de “software” de forma interna (“in-house”) porque la aplicación es crítica a la misión de la organización. Además, la organización necesita de expertos internos (“in-house”) quecomprenden a cabalidad las procesos internos de la organización en comparación con los programadores subcontratados cuyo único interés es generar dinero por algún proyecto de desarrollo de “software”.
Muchosproyectos grandes de desarrollo de “software” que han sido subcontratados a terceros han fracasado debido a la falta de entendimiento de estos acerca las funciones de la compañía. Hoy día, la mayorparte de las grandes organizaciones utilizan una combinación de subcontratación (“outsourcing”) y desarrollo interno (“in-house”), dejando los proyectos críticos al equipo interno. Aun así, algunasorganizaciones dependen completamente de la subcontratación (“outsourcing”) mientras otras compañías nunca recurren a esto.
a) ¿Es el desarrollo de software interno superior a la subcontratación? ¿Por...