Caracas, 15 de Enero del 2014 El plan estratgico tecnolgico no es un cambio de sistemas o aplicaciones, es un cambio radical en la plataforma tecnolgica que

tendr un enorme impacto en la organizacin: en su cultura, conocimiento, procesos y gente. Por lo tanto si bien la transformacin tecnolgica es responsabilidad de jefe tecnolgico, debe haber compromiso de los lderes o ejecutivos en la ejecucin de este. Este compromiso debe estar basado en el conocimiento y entendimiento del impacto que el plan tendr en sus reas de responsabilidad. La magnitud del alcance en el primer ao del plan estratgico tecnolgico es de casi un 70% Vs un 30% en el resto de los siguientes aos. Por lo que la disciplina y rigurosidad con que se deba tratar su ejecucin para asegurar el xito son indispensables. Para la convivencia de el BAU durante este primer ao deben ser definidos claramente los criterios que gobernarn esta convivencia, pues los recursos con que se cuentan son limitados adems que se debe tener un estricto control de qu se sigue modificando en los legacies y hasta cuando; esto dependiendo primero de los niveles de inversin que implican dichas modificaciones Vs los ingresos asociados; y segundo de el impacto que dicho cambio genere en la ejecucin del plan. La direccin tecnolgica debe asegurar que tiene alineados a todos aquellos que son aliados indispensables en este gran cambio. La identificacin de estos aliados y su nivel de participacin debe estar claro y confirmado el compromiso y su participacin. Los aliados son tanto externos (proveedores) como internos (unidades de apoyo: finanzas, compras, Recursos Humanos, Infraestructura). No se deben despilfarrar ni tiempo ni energa en esfuerzos puntuales o no alineados, por lo que debe haber coherencia en marcar claramente el inicio, las etapas, la participacin de aliados, Unidades de negocio, Unidades de operacin (Red/operaciones; Sistemas/Telco/ Movilnet). Debe generarse el plan maestro del proyecto con un nivel suficiente de detalle que permita confirmar alcance y fechas compromiso. Debe estar clara la estrategia de implementacin: utilizar lo que ya se tiene Vs caja cerrada; pues para cada caso el impacto es o de tiempo o en procesos. La definicin de los lderes de proyectos es indispensable para la primera etapa de desarrollo de los planes detallados y conformacin de equipos de trabajo. Debe estar clara la metodologa de proyecto a ser utilizada, los estndares de comunicacin, reporte y escalacin.

Considero que las actividades que deben ser iniciadas urgentemente para acelerar y tomar pista en el despegue este ao son: Elaboracin del plan maestro Identificacin de los lderes de los proyectos y macro actividades principales Conformacin de los equipos de trabajo Establecimiento de metodologas de trabajo y estndares /herramientas a utilizar: project?, 5. Ubicacin fsica Vs el dimensionamiento del equipo de proyecto por etapas 6. Definicin de participacin de aliados externos (integradores /proveedores de plataforma /proveedores de productos) e internos (Compras, RRHH, Infraestructura, operaciones) 7. Comunicacin del plan y su participacin a los aliados (int/ext) 8. Estrategia de convivencia con el BAU 9. Estrategia de implementacin (implantacin con procesos estndares de la herramienta o utilicemos lo que tenemos?) 10. Definicin de la fecha y Preparacin del kick off Otras actividades importantes: 1. Estrategia de migracin de datos (actuales, histricos); de plataformas (consolidacin: que tenemos que necesitamos(remos) y como la utilizamos /conectamos para obtener eficiencia) 2. Identificacin de reas de alto impacto dependiendo de las posibles fechas de entrada a produccin Vs los eventos principales de dichas reas (ej: Finanzas y cierre de fin de ao) 3. Shut down de sistemas quin, como y cuando (paralelo? o flash cut?) 4. Estrategia del conocimiento: reas sobre las cuales queremos mantener el control en casa Vs que hacemos en outsourcing. (esto impacta la estrategia de entrenamiento y por lo tanto la participacin de RRHH y proveedores) 1. 2. 3. 4.

En mayor Detalle: Plan Maestro: Debe contemplar algunos puntos de chequeo importantes como: Compra de mquinas. Compra de herramientas de depuracin de programas, de control de cambios, de control de versiones. Estrategia de Backup. Tunning de la aplicacin / Pruebas de volumen. Entrenamiento de personal del proyecto. Creacin de ambientes: Desarrollo, Conversin, Pruebas, Produccin. Estrategia de Conversin. Desarrollo de programas de Conversin. Pruebas de Conversin. Limpieza de Datos. (Elementos de datos crticos, limpieza de datos). Definicin de Procesos del Negocio.

Aprobacin de procesos del negocio. Diseo general y detallado de las soluciones. Configuracin del CRM. Configuracin del CFM. Pruebas Tcnicas integradas Pruebas Funcionales: Con datos simulados o con datos reales. Si es con los ltimos, implica que los programas de conversin deben estar listos para aportar estos datos. Integracin de Sistemas. (CRM y CFM con Facturacin). Preparacin de entrenadores. Entrenamiento de Usuarios. Estrategia. Esquema de comunicacin interna y externa de los cambios. Estrategia de salida de Sistemas. (ASAP, SISCOM, CBSS, SISE, OACSE, SRL, Stellar, etc). Sustitucin de PC, por cambio de tecnologa.

Puntos de criticidad que tienen alto impacto en las configuraciones: Lmite de Crdito: Debe ser migrado al facturador. No se puede configurar todas las funcionalidades que posee el actual lmite de Crdito. El Facturador generar alarmas que deben ser convertidas en acciones, en el sistema que manejar la Gestin de los clientes, en el sistema de Corte y Reconexin, etc. Jerarqua de Cuentas: Es necesario determinar la cantidad de niveles en las que se convertirn los clientes actuales. Esto incide directamente en los elementos a configurar y el intercambio que hay que tener entre el CRM y el Facturador. Importante determinar como ser el proceso de cambios de jerarqua y el retiro de elementos de una jerarqua. Manejo de las Ordenes de Servicio: El manejo de O/S es un tema importante para el Facturador, ya que al mismo hay que indicarle en que orden se deben aplicar los cambios de perfil, de campaas, de promociones. Este manejo debe estar en el CRM, pero entendemos que el manejo de O/S no es tema de esta fase del proyecto. Sin embargo, en algn sitio hay que hacer este manejo de O/S. Consulta de Facturas: Es un tema que impacta el performance de las aplicaciones, cuando se trata de facturas de clientes comerciales o corporativos. Hay que tomar en cuenta este tema en el tunning de las aplicaciones. Catlogos de P&S: El catlogo del CRM, debe contener la vista comercial, tcnica y de Facturacin. El proceso de cmo mantener sincronizado este catlogo con el catlogo del Facturador y del Aprovisionador, es el tema que hay que resolver. Tunning de la Aplicacin: Para el CRM, el punto difcil de resolver es como simular los datos de prueba para entonar la aplicacin. Como saber que ancho de banda necesitamos en nuestra red pblica, para que no colapse. Para el CFM, hay que validar como simular que muchos usuarios estn pagando en un mismo instante y ver como afecta las transmisiones bancarias simultneas. Para el XI, es fundamental someterlo a stress, con mensajes similares a los que ocurrirn en produccin. Producto de las entonaciones, pueden presentarse cambios en las

BD (Reorganizaciones), que pueden incidir en la forma en que se ha configurado el Sistema. Concepto de Cliente / Cuenta: Es uno de los temas mas polmicos entre el CRM y el Facturador. Hay que encontrar las diferencias de conceptos entre Cliente / Cuenta que puedan existir entre estas dos aplicaciones y en caso de diferencias, establecer en que aplicacin es mas conveniente para el negocio, cubrir la brecha de la diferencia. Formato de Factura: El formato de Factura de Cantv, tiene un nivel de detalles, que si queremos conservar, tal vez esto influya en la forma en que se debe configurar el CRM. Esto se debe a que el Facturador necesitara que sus datos le sean enviados en forma muy detallada y ordenada, a objeto de que se puedan presentar tal como lo exijan las UNs. Transferencias de nmeros: Es una actividad de la Red, que genera O/S masivas que deben llegar a todos los sistemas para efectuar los cambios pertinentes. El CRM, como es el generador de O/S, debe contemplar este tipo de movimiento, que aunque no es producto de una operacin de atencin al cliente, genera cambios en los nmeros de servicios de los clientes. Contratos: Algunos de nuestros clientes corporativos adquieren paquetes de servicios de datos a travs de contratos de servicios, que llevan dentro de si, formas de pagos, penalizaciones, cortes y activaciones. Hay que definir en donde (aplicacin) y como se manejarn estos contratos.

RN: En adicin al excelente anlisis de Carlos, hay tres aspectos que deben ser considerados para el xito del plan y de los cuales ya hemos conversado: Negocio: o Prioridades. Es crtico que el negocio fija las prioridades entre el Plan Tecnolgico (PT) y el BAU ya que, como sabemos, no tenemos recursos para atenderlos a ambos. Sin embargo, la fijacin de una alta prioridad para el PT no garantiza que tengamos capacidades para atender a ambos, PT + BAU, por lo que propongo fijar una capacidad para el PT que no compita con BAU. Adicionalmente, debemos negociar con el liderazgo del PT la posibilidad de recursos para contratar capacidad adicional. o Funcionalidad. Debemos apoyar al PT en asegurar que la funcionalidad que se entregue no sea inferior a la actual. Existe dudas - al menos yo tengo dudas - en cuanto a que la estrategia de implementar los procesos standard de SAP pueda garantizar totalmente la funcionalidad actual. Este es, probablemente, el rea donde mas valor podamos aportar por la visin global del negocio que se tiene tanto en Facturacin como en Sistemas.

Humano:

o Amenaza: Hay que trabajar la percepcin de amenaza que el PT tiene sobre el personal, en especial, de sistemas. Aunque no se puede garantizar la permanencia de todo el mundo, mientras mas claro se tenga la visin de futuro una vez implantado el PT, mejor podemos manejar estas percepciones negativas. o Respeto: Hay que ser mas asertivo en exigir trato igualitario. No es aceptable que no se contesten mails ni llamadas, ni las horas de los compromisos. Tambin hay que aclarar con el PT el tema de los recursos que se han movido desde Sistemas y las relaciones de jerarqua y/o reporte entre el personal del PT y nuestro personal en aquellos casos en que as lo amerite.

Organizacin: o Modelo de gobierno: Aparte de lo sealado por Carlos respecto a los planes y actividades, es necesario definir un modelo de gobierno para llevarlos a cabo. Dado el alcance y lo complejo del PT, la sola figura de lder de proyecto no garantiza que todos los esfuerzos estn alineados. El modelo que hemos empleado, antes en SIF y luego en FAST, Steering Committee y Working Committee nos ha dado buenos resultados.