Consultoria TI – Página 3 – aníbal goicochea

SAP Support, no me digas que visite “Idea Place”

Si tenemos un problema en la implementación de un producto SAP, una de las reacciones inmediatas sería escribir un mensaje OSS a SAP Support. Escrito el mensaje la confirmación de recepción, usualmente, es inmediata, pero dependiendo de la explicación de nuestro problema podemos recibir los siguientes tipos de respuesta:

Respuesta a la solución. La incidencia es conocida, nos brindan la solución o workaround a través de documentación y notas SAP.
Se transfiere al equipo de desarrollo. La incidencia es nueva, nos solicitarán acceso a nuestros sistemas, ficheros logs, capturas de pantalla y cualquier evidencia adicional que explique el problema y permita su replicación.
Se trata de consultoría. SAP Support nos indica que no estamos comunicando un fallo en el producto y que nuestro problema o duda se resuelve con la contratación de un servicio de consultoría. Para quedarnos sin respuestas útiles, evitemos formular preguntas del tipo “¿Cómo se hace?”.

Visite “Idea Place”. Hemos consultado por una funcionalidad que teníamos en versiones anteriores o asumíamos que debería existir, SAP Support nos informa que la característica consultada no está incluida y que podríamos sugerirla en Idea Place, el portal que creo SAP en 2011 para recoger las ideas o sugerencias de los usuarios para mejorar sus productos. Suena muy bien, pero la posibilidad para que la funcionalidad sea considerada y desarrollada es muy remota e imprecisa. Ante esta respuesta no quedará más que buscar una solución temporal (workaround) o resignarse a no tenerla, mientras tanto, podríamos pedir a todo el mundo que entre a Idea Place y vote por nuestra sugerencia de mejora.

Referencia: ideas@sap.com y https://ideas.sap.com/

«Muchos jefes para tan pocos indios»

“Las empresas de servicios profesionales, con su insistencia en el desarrollo de carreras profesionales, llegan a curiosas situaciones de pirámide invertida: un becario, dos seniors, tres gerentes y cuatro socios. Así no es extraño que el becario vaya con la lengua fuera porque sus brazos son los únicos sobre los que recaen la infinidad de planes de tantas cabezas pensantes”

Esta entrada podríamos decir que nos ha ayudado Gabriel Ginebra, autor del recomendable libro “El japonés que estrelló el tren para ganar tiempo”, del que utilizamos algunos extractos de su obra:

El párrafo anterior bien podría ser un ejemplo de expresiones tan populares como las siguientes:

Uno trabajando y nueve mirando
Sobran gestores, faltan hacedores
Muchos jefes para tan pocos indios

“… Hay empresas tan ricas que producen dos productos paralelos y sin ninguna relación: un producto que la gente compra y con el que ganan dinero, y otro producto (declaraciones, reuniones, programas de calidad) sin relación alguna con el anterior, que nadie compra…. Hemos descuidado el negocio y estamos centrados en actividades como medir, planificar o controlar. Todos queremos dirigir, porque trabajar es más cansando.”

La consultoría informática nos obliga a mantenernos al día de la innovación tecnológica y en profundizar en aquello que consideramos nuestra especialidad, para de este modo brindar el mejor servicio a nuestros clientes. La gestión es importante, pero si a la consultoría informática nos dedicamos, quizás la proporción promedio para todos los niveles de un equipo debería ser 50% para cada una de estas habilidades (gestión y conocimiento tecnológico), sabiendo lo que se debe hacer y quizás haciéndolo, contribuiremos a la eficiencia, reduciendo las casi siempre improductivas reuniones y documentos de coordinación.

“Bien o bonito, lo hago otro día”… Cuando la calidad no es importante

Hace unos días culminé con unas sesiones de SAP Business Intelligence, y como es lógico, en la última sesión tocaba “examen”, eso sí, con todo el material a su disposición (como en la vida real), incluyendo Google. En los últimos minutos, revisando los trabajos, me percato de algunas soluciones “originales”, brindaban el resultado solicitado, pero de aquella forma que nunca quisiéramos encontrar si nos tocara modificarlo. Al exigir una explicación, se me indica que “hace lo que he pedido” y “que bien o bonito, ya lo haría otro día”… Plop!… Lo curioso de esta anécdota, es que respuestas similares ya la hemos escuchado en la “vida real”.

Hace unos días culminé unas sesiones de SAP Business Intelligence, y como es lógico, en la última sesión tocaba “examen”, eso sí, con todo el material a su disposición (como en la vida real), incluyendo Google. En los últimos minutos, revisando los trabajos, me percato de algunas soluciones “originales”, brindaban el resultado solicitado, pero de aquella forma que nunca quisiéramos encontrar si nos tocara modificarla. Al exigir una explicación, se me indicó “hace lo que he pedido” y “que bien o bonito, ya lo haría otro día”… Plop!… Lo curioso de esta anécdota, es que respuestas similares ya la hemos escuchado en la “vida real”.

La culpa de esta situación, en parte fue mía, porque sólo me limité a indicar lo que quería (alcance) pero no detallé nada sobra la forma, especialmente lo relacionado a la calidad. Algo similar sucede en los requerimientos de los proyectos informáticos, se señala lo que se desea pero no los criterios mínimos de calidad que debe tener la solución, para medianamente garantizar su mantenimiento y evolución. Más “pecado” tiene cuando la calidad se olvida en la implementación de soluciones de Business Intelligence o Corporate Performance Management (CPM o EPM) las cuales van dirigidas a mejorar la eficiencia de los procesos de negocio.

Dar por su supuesto que la calidad será parte de la solución, sería un error. Tal vez sea porque se reducen los costes y los plazos, pero parece que hacer las cosas bien se considera una pérdida de tiempo. Para que esto no te suceda, te sugerimos que en el alcance de tu proyecto, especifiques lo siguiente:

Todos los entregables (documentos y solución en sí), deberían estar regidos por estándares de calidad oficiales o adaptaciones de las mismas.
Especificar los procedimientos para asegurar que la calidad de integra en la solución. Por ejemplo, se podría definir una planificación de auditorías y como se actuará con el resultado de ellas.
Señale como se controlará la calidad, indicando las métricas, tolerancias y responsabilidades.

En una coyuntura tan dinámica o cambiante, de poco servirá una solución que nos brinde el alcance solicitado y que por problemas de calidad, sea rígida o poco flexible a ser modificada o evolucionada.

Las funciones de un PMO

La “unidad de gestión de proyectos” (Project Management Office”, PMO) es la oficina responsable de centralizar y coordinar la gestión de proyectos dentro de una empresa. Constituida normalmente en forma de comisión o departamento, el objetivo principal de una PMO es mejorar la tasa éxito de los proyectos, estandarizando y apoyando las prácticas de gestión dentro de la organización, a través de la siguientes funciones:

Estándares, procesos y mejores prácticas. Define y facilita los protocolos, procedimientos y plantillas de gestión con el fin de lograr coherencia entre los proyectos.
Requisitos de certificación y reglamentarios. Respalda y controla el cumplimiento de los requisitos que apoyan a los objetivos de la empresa.
Metodología. Brinda apoyo y asesoramiento sobre técnicas de gestión de proyectos.
Herramientas e infraestructuras. La PMO se responsabiliza del despliegue de aplicaciones informática, plantillas, formularos y de la disponibilidad de repositorios para la elaboración y almacenamiento de los documentos de los proyectos
Recursos compartidos y comunicaciones. Administra al grupo de gestores de proyectos. En ocasiones, es responsable de la asignación de recursos y de coordinar la comunicación entre ellos.
Asesoramiento y capacitación. La PMO asesora, lidera y forma a los gestores de proyectos para que contribuyan a mejorar las tasas de éxito.

Referencia: ISBN 9788441532250

«Esto es» como «este otro»… o la comodidad de «encontrar» similitudes entre las cosas

Estas son algunas expresiones que hemos escuchado en el mundo de la consultoría informática. Nadie quiere complicarse, pero se «peca» en el afán de simplificar todo con el fin de convencer y no entrar en detalles que quizás por desconocimiento se trata de evitar. No pretendemos asustar a nadie, sino de afrontar cada reto tecnológico con todo el conocimiento necesario para identificar las verdaderas posibilidades y limitaciones, y de este modo, gestionar adecuadamente su implementación.

BPC es como Excel,
La 10 es como la 7.5,
BusinessObjects es como MicroStrategy,
Una migración a BW sobre HANA es como cualquier otra migración… Plop!!!

La necesidad de simplificar, resumir, asociar, catalogar o clasificar es parte de la naturaleza humana, pero dependiendo en qué contexto se formule, su utilidad o inutilidad tendrá un impacto directo sobre las cosas que se hagan. Si se trata de la implementación de un producto SAP podemos señalar las siguientes premisas:

Ningún producto es similar a otro producto SAP, al de otro fabricante e inclusive las diferencias pueden ser importantes entre las versiones del mismo producto.
Difícilmente un producto SAP podrá llevar la etiqueta de producto terminado. La innovación es constante y en muchas ocasiones la madurez o estabilización del producto se logra cuando el producto es liberado y lo comienzan a utilizar los usuarios.
Las fortaleza de un producto son conocidas desde un inicio, pero muchas de las debilidades o limitaciones se descubren durante los períodos de implementación.

Las similitud informática no existe y menos entre SAP HANA con relación a la tecnología del pasado, y más aún, si sabe que SAP HANA presenta novedades constantemente.