Estaba leyendo en el blog de Evaluando ERP, algo sobre las desventajas y los problemas relacionados con las implementaciones de un ERP. Estoy completamente de acuerdo con lo que dice el autor, y agregaría que, para evitar estos problemas en la etapa de implementación, lo ideal es, antes de definir el plan de implementación, definir bien las necesidades de la empresa y después convertirlas en requerimientos. Hay que poner mucha atención y tomar en cuenta los procesos claves de la organización, para que la evaluación de soluciones se centre en ellos.
El proceso de evaluación de software de TEC permite asignar prioridad a esos procesos claves de la empresa, para definir así los requerimientos que se usarán para comparar las diferentes soluciones disponibles y determinar cuál de ellas es capaz de satisfacer mejor las necesidades de la organización. ¿Un ejemplo? Las plantillas RFP de TEC.
En pocas palabras, TEC le da la mayor importancia a los procesos claves de la organización que está buscando seleccionar un software empresarial.
Con eso atacamos el desafío de definir y ejecutar un plan de implementación de ERP, que menciona el blog. Sin embargo, queda aquél de cambiar los hábitos de la gente. Si alguien tiene algún comentario o sugerencia, aquí estamos para escucharlos.
Para seguir con el tema la última edición del Boletín de TEC, la gestión del ciclo de vida de los productos (PLM), quería hablarles un poco de este tipo de software y de algunos de los criterios que contiene el Centro de evaluación de PLM de TEC.
En primer lugar, nuestra base de conocimientos de PLM trata los aspectos relacionados con el diseño y la fabricación de productos para industrias tanto discretas como de procesos. Contiene criterios que cubren las áreas de desarrollo de productos y gestión de carteras de productos, gestión del proceso de fabricación, ideación y gestión de requisitos, datos de servicio y cumplimiento normativo. De forma más específica, cubre las áreas siguientes:
El Boletín de TEC del día de hoy publicó un artículo que habla sobre el proceso de selección de software empresarial (de gestión de recursos humanos, para ser exactos). El artículo está muy bueno y contiene mucha información detallada, pero el autor maneja los términos RFI y RFP (solicitud de información y solicitud de propuesta, respectivamente) de forma distinta a la que usamos aquí en TEC. Dice:
“Tradicionalmente, la etapa siguiente del proyecto implicaría enviarles una solicitud de propuesta (RFP, por sus siglas en inglés) a un grupo grande de proveedores de software de gestión de recursos humanos. En esta RFP usted incluiría los requisitos de más alto nivel de su empresa para que los proveedores de software la revisen y le notifiquen si están interesados en competir por su negocio. Read the rest of this entry »
El día de ayer hablaba con una empresa latinoamericana que estaba lista para enviar su RFP (pedido formal de propuesta) a los proveedores de ERP. Me comentaban que el proceso les había tomado meses de análisis, reuniones con usuarios y proveedores,… y generaron un documento que incluía 300 requerimientos! … Les dije que 300 requerimientos es una muestra pequeña de funciones que un ERP incluye. Solamente el módulo de finanzas de un ERP contiene cerca de 860 funciones y características!
Revisemos el contexto: el ERP se convertirá en el flujo de datos de la empresa, tomará datos del plan maestro de producción, el inventario, las ventas y realizará el mapeo de transacciones hacia la contabilidad, los libros mayores y auxiliares. Mas aún, deseamos que el ERP se encargue de administrar los procesos transversales del negocio, las aprobaciones de presupuesto, órdenes de compras, contratos, gestión del personal, etc.
Frente a esto, me comentaron que el trabajo lo realizaron las diferentes áreas y no les fue posible enumerar un mayor número de requerimientos. Que también involucraron a los proveedores para conocer más detalles y funciones que les servirían en su negocio.
En TEC hemos evaluado productos ERP y enumerado las funciones y características a nivel de detalle. Nivel de detalle? Si, es importante documentar a este nivel lo que se requiere, es decir explicar lo que se desea a nivel de unidad funcional para poder cotejar estos datos con las soluciones de proveedores ofrecen.