¿Qué tipo de criterios son importantes considerar al seleccionar un paquete de software COTS?
- requisitos actuales: ¿qué necesita en este momento? ¿Cuánta Configuración / Personalización sería necesaria?
- requisitos futuros: ¿qué anticipas que definitivamente necesitarás más adelante? ¿Cuál es la hoja de Ruta del proveedor, incluida la frecuencia de lanzamiento? ¿Qué tan caro es alejarse de esta tecnología? ¿Cuánta influencia tienes sobre la hoja de ruta?,
- Implementabilidad: ¿qué plataforma requiere? ¿Cuán difícil es integrarse con los sistemas existentes? ¿Tiene problemas de escalado de hardware? ¿Hay puntos únicos de falla?
- Supportability: ¿Qué hay disponible en términos de formación? Consultoría? ¿Documentación? ¿Comunidad? ¿Qué tan estable es el proveedor? Si el proveedor también está destinado a ser un socio de integración, ¿qué tan alineado está culturalmente?
- Costo: ¿cuánto costará implementar (licencia, alojamiento, personalización), mantener, actualizar, modificar?,
- Capacidad de entrega: (si se requiere personalización o configuración extensa) ¿la personalización se realizará a través de API (buena) o se deberá realizar modificando el funcionamiento interno (mala)? ¿Qué tan difícil es probar el paquete (especialmente de manera automatizada)? ¿Qué tan difícil es automatizar la instalación, la configuración y las compilaciones (los asistentes son malos, las API con scripts son buenas)? ¿Qué tan difícil es configurar el control de versiones Especialmente integrado con su sistema de gestión de configuración existente?,
reduzca la personalización tanto como sea posible otherwise de lo contrario, se verá abrumado por el costo y el esfuerzo de las actualizaciones.
esto sugiere que debe modificar el proceso de negocio para que coincida con el paquete en lugar de viceversa, lo que a su vez sugiere que generalmente no debe considerar paquetes para procesos / capacidades de negocio estratégicos. Esto también sugiere que desea ser muy claro y hacer cumplir los límites para evitar que las características de los paquetes se introduzcan en áreas estratégicas.
solo porque el producto Ofrezca una función, no significa que deba activarla o usarla.,
según Capers Jones, con un 25% de personalización, es más barato a largo plazo construir un sistema personalizado en su lugar y un 15% de personalización es un número más seguro de usar. Si el proveedor es hostil, el número se reduce al 5%.
la personalización o la amplia configuración destacan la necesidad de entregabilidad.
si el paquete es como un appliance (por ejemplo, Microsoft Word), debería funcionar. La selección inicial y las actualizaciones pueden ser más sobre pruebas manuales y exploratorias., Sin embargo, una vez que empezamos a introducir la personalización, entonces la importancia de ser capaz de configurar pruebas automatizadas (así como otras características de desarrollo) crece.
la configuración, especialmente si es extensa, no debe tratarse necesariamente con menos rigor que el desarrollo personalizado.
especialmente con los paquetes típicos de COTS en términos de CRM, ERP, Finanzas, las opciones principales tienden a tener paridad de funciones, lo que significa que generalmente debe centrarse en otros aspectos.
esto podría ser alineación de proveedores, probabilidad, modificabilidad, etc.,
es mejor reducir el compromiso que intentar comprometerse con una decisión perfectamente correcta.
si el paquete no requiere tanto compromiso (por ejemplo, servicio alojado), hemos mantenido opciones para cambiar de opinión más tarde y no tenemos que preocuparnos tanto por tomar una decisión óptima por adelantado.
no elija la tecnología correcta. Elija la tecnología que es más barata para alejarse de.,
Chris Matts
Los factores que aumentan el compromiso son principalmente el tamaño de la inversión inicial y el costo de la migración de datos. El tamaño de la inversión inicial se trata de una falacia de costo hundido que lo convierte en un factor psicológico/político, no Económico.
