¿Cómo debemos evaluar "Construir vs. Comprar" para un sistema ERP?

Desarrollar una lista Pro vs. Con es un comienzo; sin embargo, para una decisión de esta magnitud, se necesita un poco más de rigor. En otras palabras, su análisis debe estar en la línea de beneficio versus costo versus riesgo y debe cuantificar estas tres categorías en la medida de lo posible. Puede descomponer cada uno como desee y puntuar en los niveles más bajos y puede aplicar pesos si lo desea.

Estos son los pasos que usaría:

Generar los criterios bajo cada categoría de beneficio, costo y riesgo; Realizar talleres con las PYMES técnicas y empresariales correspondientes; iterar puntuaciones; Realizar talleres para validar cuál salió mejor.

Es un proceso iterativo y la puntuación es más subjetiva de lo que nos gustaría; sin embargo, debe comenzar en alguna parte y si utiliza suficientes PYME en la puntuación, los extremos se nivelarán. Tenga cuidado con los prejuicios y las agendas ocultas y controle esas cosas lo mejor que pueda.

Chancho, bienvenido al PMSE! Le recomendamos que consulte la Guía de los fundamentos de la gestión de proyectos, 5.ª edición, sección 12, que se titula "Gestión de adquisiciones de proyectos", y específicamente la sección 12.1.2.1, titulada "Análisis de fabricación o compra".

Tiene múltiples soluciones a considerar, no solo Build vs Buy.

Con respecto a Comprar, deberá considerar varias opciones de compra diferentes;

1. Análisis de brechas de sus procesos y objetivos comerciales en comparación con una serie de productos ERP (todos son diferentes, con un ajuste natural a diferentes verticales)
2. Modelos de entrega (iterativos o big-bang)
3. Combinaciones de los mejores productos más pequeños en lugar de un único ERP
4. Costos ocultos, como el costo de implementación, personalización, gestión de cambios y contratos continuos de mantenimiento y soporte.

Con respecto a Build, deberá considerar varias opciones de solución diferentes;

1. Opciones de plataforma/tecnología/UX (nube, local, cliente grueso, web, móvil o una combinación)
2. Plan de lanzamiento (iterativo corto frente a big-bang) y la diferente velocidad de retorno de la inversión que proporciona

La buena/mala noticia es que ni siquiera debería comenzar esta investigación hasta que haya enumerado y analizado todos sus procesos, en la medida suficiente para que pueda hacer 1) Análisis de brechas detallado contra al menos 2 dos productos ERP y también Análisis de brechas contra un solución basada en la integración ("Una combinación de los mejores productos de su clase más pequeños") (que a menudo es mejor que un ERP, con un retorno de la inversión más rápido y mejor ajuste a las necesidades)

Terminará con un resumen de análisis de brechas de las opciones de Producto o Desarrollador asignadas a los procesos (imagínese una gran hoja de cálculo grande). Luego deberá evaluar el tamaño y el costo de cerrar las brechas, lo que generalmente requiere que los proveedores y las empresas de desarrollo se comprometan estrechamente con usted. Si alguna solución tiene menos del 70 % de ajuste listo para usar, probablemente deba desecharse de inmediato.

En pocas palabras, creo que ninguna solución ERP se ajustará a sus necesidades desde el primer momento. He estado haciendo esto durante 25 años y este es SIEMPRE el caso.

Entonces... Gap Analysis es la clave, y espere muchas opciones para elegir.

¡Buena suerte!

Recientemente guié a mi equipo a través de una pregunta similar. Aquí hay un enfoque híbrido que utilicé que considera la lógica típica de compilación o compra y los casos con un método de resolución de problemas basado en equipos: .

Por supuesto, las preguntas habituales de costo/ROI y velocidad/precisión son importantes. Pero es posible que desee hacer una planificación de riesgos un poco más proactiva. Para esto empleo lo que a HBR le gusta llamar el "pre-mortem".

Investigación realizada en 1989 por Deborah J. Mitchell, de Wharton School; Jay Russo, de Cornell; y Nancy Pennington, de la Universidad de Colorado, descubrieron que la retrospectiva prospectiva (imaginar que un evento ya ocurrió) aumenta la capacidad de identificar correctamente las razones de los resultados futuros en un 30 %.

Aunque muchos equipos de proyecto se involucran en el análisis de riesgos previo al lanzamiento, el enfoque retrospectivo prospectivo de la autopsia ofrece beneficios que otros métodos no ofrecen. De hecho, la autopsia no solo ayuda a los equipos a identificar problemas potenciales desde el principio. También reduce el tipo de actitud maldita-los-torpedos que a menudo asumen las personas que están sobreinvertidas en un proyecto. Además, al describir debilidades que nadie más ha mencionado, los miembros del equipo se sienten valorados por su inteligencia y experiencia, y otros aprenden de ellos. El ejercicio también sensibiliza al equipo para detectar señales tempranas de problemas una vez que el proyecto se pone en marcha. Al final, una autopsia puede ser la mejor manera de eludir cualquier necesidad de una autopsia dolorosa.

Puede leer más aquí: http://hbr.org/2007/09/performing-a-project-premortem

Depende del presupuesto que quieras permitir, el alcance que quieras cubrir y el número de usuarios. Si solo desea cubrir finanzas/contabilidad, será difícil tener la calidad del software existente. También puede ser difícil cumplir con las normas contables de su país. Si elige un software existente, aún puede desarrollar la interfaz con su herramienta de ventas.

Ventajas de la solución de proveedor:

• Normas fiscales y contables cubiertas
• Soporte y continuidad de la solución
• Oportunidad de revisar su proceso y mejorar

No veo una buena razón para desarrollar un software desde cero para un proceso que se repite en la mayoría de las empresas.

Si solo está interesado en la parte financiera/contable del sistema, sin duda buscaría un programa que haga precisamente eso y nada más, como Exact Online. Los sistemas ERP están desarrollados específicamente para un entorno de producción, y por lo que he visto, cuantas más opciones tiene un programa, más complejo es y más difícil de implementar, incluso si no usa otros módulos del sistema. .

Casi todos los sistemas ERP (y otros de administración de empresas) que se precien tienen posibilidades de vincularse con otros programas. Esto es casi siempre el resultado de la colaboración entre las empresas: consulte con su empresa de software actual qué sistemas son compatibles y utilizados por sus otros usuarios. Esto también ilustra una desventaja con la construcción de su propio sistema: tendrá que trabajar con ciertas partes del software existente si desea que su nuevo sistema funcione junto con su paquete existente. (Lo he solucionado antes con volcados de datos fe, ¡pero no se lo recomendaría a nadie!)

Solo recomendaría un sistema ERP completo si planea implementarlo en toda una empresa (de producción). Buscaría un sistema hecho a la medida si necesita algo muy simple, de lo contrario, los beneficios de contar con el soporte de la compañía de software podrían superar las desventajas.