- Blueprint de procesos: donde se detalla la estructura funcional del negocio, lo común en esta fase es que por presiones de tiempo en el implementador el nivel de detalle no es el adecuado, son recurrentes en ésta fase frases como: Eso lo detallamos más en la parametrización, esto otro lo podemos ajustar durante las pruebas, estos se puede conectar desde otro sistema de información, no son necesarias banderas de alerta, etc.
- Parametrización de la herramienta: durante esta fase se procede a realizar la personalización del paquete, se habilitan campos de información que se va a emplear, se define la estructura de información dentro de la plataforma (Cosa que se debió haber definido durante el blueprint), se realizan las conexiones a sistemas de información externos. Usualmente durante esta fase, se hacen cambios que cambian el modelo inicial del blueprint y no se documentan, se acomodan los procesos del negocio a los modelos de procesos que por defecto tiene la herramienta bajo la excusa "Es que asi lo maneja el paquete", y en fin empiezan un infierno de cambios que al final cuando el proceso queda sistematizado no se cuenta con la información adecuada para poder gestionar cambios posteriores generando una dependencia del implementador de la plataforma.
- Integración con terceros: Generalmente los implementadores dicen que lo hacen, pero generalmente no miden adecuadamente el alcance del esfuerzo que implica, o las integraciones son punto a punto a nivel de base de datos, generan fallas de sincronización en los datos, etc. Es un punto álgido que se debe tener en cuenta desde el inicio del proyecto que por lo general se pasa por alto.
- Pruebas funcionales: Es la fase que permite que los dueños del proceso verifiquen que lo que necesitan realmente se está reflejando dentro del modelo implementado, es necesario durante esta fase que el usuario funcional tenga la libertad de comprobar que lo que el negocio necesita realmente se encuentra reflejado dentro del sistema.
- Plan de comunicaciones: Este plan inicia en el momento en que la empresa decide implementar un sistema de información, NO al final o a la mitad del proyecto. Ahora, un plan de comunicaciones no es simplemente poner pendones, ni letreros en la empresa, ni discursos o cursos para los empleados. El plan de comunicaciones debe estar enfocado en como cambiar una cultura de trabajo dentro de una organización, para ello debe garantizar que se encuentran "Sponsors" dentro de las áreas funcionales, generar incentivos para el uso de la nueva tecnología, comunicar los beneficios de la nueva herramienta y realmente hacerla útil para la compañía. (No un lastre más)
- Kick off del sistema: Fiesta, vino, todos felices el sistema de información arrancó... y una vez empieza a operar.
- Estabilización : Problemas de calidad de datos y consistencia de la información, auditoría a los procesos parametrizados dentro del sistema, como manejar el error (Si es un proceso de aprendizaje?)
- Pregúntese para que lo quiere, si le va a generar valor a su negocio y como quiere que le genere dicho valor. Que es lo que quiere obtener de ése sistema y téngalo siempre muy claro como "norte" durante el proceso de implementación, porque los Ingenieros de sistemas querrán cambiarlo. (Esto no es como comprar un Excel)
- Identifique donde esta la información va a utilizar, es clave que tenga mucha claridad sobre las fuentes de información y como ésta hace parte de los procesos de su negocio, defina que información es indispensable dentro de su cadena de valor y cual es de soporte. Documente sus procesos asociando la información que fluye por ellos.
- Conozca y tenga claridad sobre sus procesos, en especial de todos aquellos que se soportarán en el sistema de información, identifique cuales procesos por fuera del alcance del sistema de información son insumo o dependen para aquellos que estarán automatizados. Generalmente las parametrizaciones quedan incompletas por la ausencia de éste tipo de información. Su sistema de información TIENE que reflejar su negocio y debe estar debidamente documentado; para ello existen herramientas de análisis de requerimientos que combinan aspectos funcionales con técnicos. (RUP es una de ellas)
- Piense primero en su Arquitectura de información y después en la arquitectura de tecnología, la tecnología es una HERRAMIENTA consecuencia de su estructura de información. Cualquier sistema de información es útil si se cuenta con la suficiente claridad de su uso. Por favor no pongan su negocio a depender de terceros, es absurdo que el ingeniero de sistemas termine definiendo que es lo que su negocio debe hacer.
- Busque quién tiene experiencia en el sector, en especial que el implementador conozca del negocio (Cosa que es casi imposible encontrar, además de ser riesgoso por el conflicto de intereses que pueda generar), es aconsejable realizar una combinación entre Experto funcional del sector y un Implementador técnico, dado que garantiza que no exista una relación de Juez y Parte durante el proceso de implantación. Además, cada cual a lo suyo, es muy costoso para las compañías contratar alguien que tenga ambos roles dentro del proyecto porque: puede implementar lo que más facil le quede, pierde poder de negociación frente al implementador, genera dependencia.
- Sea pesimista, piense que tanto puede crecer su negocio y pregúntese si el sistema puede crecer con él, generalmente todos dicen que pueden crecer de forma ilimitada. Ud lo cree? Piense que el otro año puede cambiar su estrategia y que se pueden enfocar en otro tipo de productos, proyectos o servicios. El sistema soporta los cambios? cuanto costarían esos cambios?
- Asegúrese de contar con "sponsors" dentro de las áreas usuarias, si no los tiene, identifíquelos, impórtelos, haga algo.. porque son la única forma para que la organización adopte la tecnología, de lo contrario se arriesga a trabajar con información basura que poco le ayudará a la gestión de su negocio y a sub utilizar la inversión que acaba de realizar.
- Pruébelo, recompruébelo y vuelva a probar, siempre esté probando la tecnología, cualquier cambio documéntelo, compruebe la calidad de su información, si tiene problemas con ella, implemente controles. Garantice que el sistema le sirve para lo que lo compró, de lo contrario busque ayuda.
- Duden de un vendedor de sistemas de información que desconozca de su modelo de negocios - Cuidado, generalmente quieren vender el paquete y siempre son expertos en medicina, banca, energía, etc. Un mar de conocimientos....
Algunas preguntas para reflexionar: Alguna vez ha sacado su sistema de información en el tiempo en que tenía planeado? ha logrado que todos los procesos hayan quedado sistematizados de forma correcta? ha tenido problemas con re-parametrizaciones? la calidad de sus datos es adecuada? cuenta con reportes de gestión adecuados con su modelo de negocios?
Señores, sus sistemas de información son el CORAZON de su negocio, es una herramienta de gestión única e irrepetible (Se imaginan que todas las empresas funcionaran de la misma forma? como competirían?), refleja cada uno de los procesos y actividades de SU NEGOCIO, si su sistema de información es flexible, escalable y adaptable a las necesidades de cambio de su modelo de negocios han hecho una buena elección. De lo contrario, corren el riesgo de tener a una "sanguijuela" dentro de su compañía que será dificil extirpar mientras ustedes no tengan clara su estructura de información, como se encuentra reflejada dicha estructura dentro de su modelo de negocios y si su sistema realmente le aporta valor al negocio.
Buena suerte con ésta aventura y cualquier cosa, me cuentan.
No hay comentarios:
Publicar un comentario
Por favor sus comentarios acá: :)