archivo

Archivos Mensuales: junio 2009

Es muy importante visitar a clientes y potenciales clientes. Que sepan que sigues existiendo aunque haga tiempo que no trabajas con ellos, que sepan que sigues evolucionando, ganando proyectos y consiguiendo casos de éxito.

Estas visitas tienen por regla general la característica de que en poco tiempo tienes que intentar que tu empresa se luzca, en aspectos que le resulten de interés al cliente (si no hay un orden del día marcado o una temática concreta hay que saber adaptarse o interpretar a lo que el interlocutor o interlocutores están interesados) y además sin parecer prepotente o pedante (casi mejor marcharte sin nada, que dejando al cliente o posible cliente con una mala sensación).

Un aspecto muy importante es intentar que la reunión sea para intentar cubrir una necesidad que no tiene cubierta el cliente, si vas por ejemplo a vender al cliente un sistema que resuelve una determinada problemática de negocio y el cliente ya tiene uno que resuelve dicha problemática y está contento, lo mejor es que te ahorres la visita. Por eso a veces es mejor, si se puede, conseguir una primera reunión sin más objetivo que conocer al posible cliente y a partir de ahí plantear una nueva reunión (si realmente interesa) sabiendo por donde se puede intentar conseguir algo.

Si el objetivo no es conseguir una venta a corto y medio plazo y lo que quieres es simplemente mantener el contacto con el cliente o el posible cliente, sí que se puede enfocar una reunión más generalista y de marketing.

Ser un buen comercial es muy complicado, supongo que como todo, habrá parte que lo dará el rodaje y el aprendizaje, pero creo que gran parte del éxito de un comercial viene de serie con él, es decir, se tiene esa cualidad o no se tiene, es cuestión de instinto. Por este motivo, porque los buenos comerciales no se fabrican en serie, están tan bien cotizados en el mercado.

Por regla general nos encontramos con que en muchas organizaciones existen procedimientos que se dictan como reglas generales y que después al no estar suficientemente detallados son interpretados de diferente forma en función de quien lo esté aplicando.

No tener homogeneizado un mismo procedimiento en toda la organización es tremendamente improductivo, además de no garantizar que ante una misma circunstancia todos actuén de la misma forma, lo cual provoca inseguridad jurídica si el procedimiento tiene repercusiones legales.

Si un procedimiento no está reglado en detalle y cada cual lo interpreta a su forma y además lleva mucho tiempo funcionando así, es tremendamente complicado plantear una solución homogénea si no es a través de una instrucción de la dirección de la organización. Por tanto, la homogeneización procedimental requiere sin duda el apoyo de la alta dirección de la organización, la cual debe ser consciente de que si quiere eficiencia debe tomar medidas para conseguirlo.

Además de la instrucción que describa con detalle cómo es el procedimiento y que obligue a hacerlo como se indica es necesario un proceso de gestión del cambio para que todos los implicados comprendan cómo se debe ejecutar el procedimiento y entiendan lo necesario e importante que era el proceso de homogeneización de procedimientos.

Hace poco un amigo me preguntó que si me sonaba eso que había escuchado por ahí y que se llamaba “Teoría de la decisión milticriterio discreta”. Le respondí de forma parecida a como me lo explicaron a mi, cuando lo escuché por primera vez:

“Imagínate que hay varias posibles soluciones u opciones entre las cuáles poder elegir, pues bien la teoría de la decisión multicriterio discreta sería algo así como abrir una hoja de cálculo, poner en cada fila las distintas posibles opciones, en cada columna distintos parámetros por los que valorar la opción y darle un valor a la opción para cada uno de esos parámetros, los cuáles no tienen por qué tener el mismo peso. Después sumas los resultados teniendo en cuenta el peso y la que tenga más puntos gana.”

Evidentemente a esta definición habría que aclararle muchas cosas, ya que la Teoría de la Decisión Multicriterio Discreta tiene una importante base teórica por detrás, pero básicamente el objetivo es ese, servir de instrumento para la toma de decisiones cuando hay más de una opción que elegir y hay más de un criterio que contrastar, es decir, tendremos varias opciones, hay que elegir una, hay diversos indicadores sobre los que valorar cada opción y en base la puntuación de los indicadores se escoge la mejor opción. En cierto modo es lo que solemos hacer los seres humanos cuando tenemos que tomar una decisión trascendente, ver los pros y contras de las diversas opciones y elegir la que creemos mejor.

El la teoría de la decisión multicriterio discreta, al tener una base teórica por detrás se tienen en cuenta más detalles, por ejemplo, si hay un criterio en el que las distintas opciones empatan o casi empatan, se podría tomar la decisión de anularlo o asignarle una ponderación inferior a la inicialmente asignada, lo mismo al revés, es decir, si hay un criterio donde las distintas opciones presentan valores dispares podría tomarse la decisión de incrementar su ponderación.

Asimismo, existen diversas técnicas para elegir la mejor opción en función de la valoración de los diversos criterios, como por ejemplo, en lugar de una suma ponderada, considerar como mejor opción aquella que gane en más criterios o utilizar mecanismos de selección más complejos como Electre y Promethee.

No son muchas, desgraciadamente, las pruebas de aceptación que he realizado sobre aplicaciones que han estado bajo mi responsabilidad.

¿Por qué?

1) Pues porque los usuarios no te responden, es decir, preparas en un entorno de preproducción la aplicación y después pasan de probar y no puedes tener el producto parado indefinidamente.

2) Los plazos de entrega lo han impedido.

La gran ventaja de las pruebas de aceptación es que permite que el producto se ponga en explotación con grandes garantías ya que permite depurar errores e incluir algunos cambios (mínimos eso sí, dado el estado de avance del proyecto). Estos cambios además se pueden realizar sin afectar a la producción del usuario.

La no realización de pruebas de aceptacion implica que la primera etapa de detección de errores y pequeñas mejoras se da en el entorno de explotación con todo lo que ello implica: necesidad de realizar los cambios con más urgencia, interrupción del proceso de producción del usuario, etc… y ya lo he dicho muchas veces: las prisas son malas consejeras.

Intenta por todos los medios que se realicen pruebas de aceptación y antes de ellas, que los usuarios vayan viendo cómo se va realizando el proyecto, con ejemplos de funcionamiento de algunas pantallas e incluso antes, un prototipo.

Lo tengo visto y comprobado, si existen dos tareas, una es la principal y otra se considera auxiliar y falta tiempo, sobra trabajo o ambas cosas, se terminará priorizando la tarea principal, dejando en segundo plano o abandonando la auxiliar.

Eso pasa con la documentación de los proyectos de desarrollo de software, donde la línea principal es la construcción del producto y la creación de la documentación una línea secundaria que si se puede se hace mejor o peor y si no se puede pues se deja un lado.

Para evitar este asunto hay que integrar el proceso de generación de la documentación dentro de la línea principal, es decir, la construcción y eso se puede conseguir de una manera bastante racional haciendo uso de herramientas CASE, donde además resulta bastante sencillo realizar un mantenimiento de los diferentes modelos con los que se esté trabajando.

Va a existir documentación que se generará extra-CASE y que se tendrá que hacer por los medios tradicionales, como por ejemplo, las actas de las reuniones, los manuales de usuario, etc…, pero al integrarse el esfuerzo documental en la línea central del desarrollo de software, asumir este tipo de documentación adicional resulta mucho menos pesado.

Hace unos meses en una reunión donde se proponía el desarrollo de un gran sistema que gestionaba un proceso importante de mi organización, el cual también existía en el resto de organizaciones que comparten el mismo paraguas institucional, uno de los participantes de la misma dijo que los sistemas centralizados estaban obsoletos, anticuados y que lo que molaba eran los sistemas distribuidos, es decir, que cada entidad de la organización gestionase su instancia del proceso como quisiera y después al final se consolidase la información en el sistema central.

Yo no soy a priori partidario de los sistemas centralizados ni de los sistemas distribuidos, creo que hay que estudiar primero el problema, la infraestructura tecnológica que le puede dar soporte y después buscar la mejor solución.

En el caso del sistema que se debatía en la reunión, la solución sencilla es la construcción de sistemas independientes que alimentasen al gran repositorio central, sin embargo presentaba dos inconvenientes que eran importantes tener en cuenta: Al ser un proceso horizontal en la organización hay muchos subprocesos comunes, esto se hace más patentes si subimos la escala y en lugar de la organización tomamos como referencia la institución, esto implicaba repetir la implementación de un mismo subprocesos en distintos sistemas de información, además si no existe una visión común de los mismos, en cada organización o departamento se le puede dar una solución distintas, con la inseguridad desde el punto de vista jurídico que eso conlleva, el coste de implementación (repetir varias veces la solución a un determinado problema) y de mantenimiento. Otro problema importante es la duplicación de datos en repositorios distintos, lo que puede provocar problemas de coherencia en el caso de que los mecanismos de sincronización no estén debidamente ajustados, tengamos en cuenta que en el caso del sistema que nos ocupa debería tener información alfanumérica, cartográfica y documental (y en gran volumen).

Por todo lo anterior yo defendía una solución centralizada, la cual era más complicada de desarrollar ya que necesitaría de instrumentos normativos que obligase a los distintos departamentos a trabajar de una determinada manera y además requería poner a un mayor número de personas de acuerdo. La solución no obstante sería mixta en algunos aspectos, ya que probablemente por motivos de rendimiento, podría ser recomendable que cada organización o departamento manejasen, como mínimo sus propios repositorios cartográficos y documentales, implementándose por tanto los procedimientos de sincronización oportunos.

¿Qué pasó finalmente? Pues que un proyecto tan ambicioso requería forzosamente una gran inversión económica y en la época en la que estamos no está el horno para muchos bollos. Supongo que algún día se retomará y espero que con una solución centralizada.

Afrontar un proyecto de reingeniería de procedimientos en una organización, con el objetivo de simplificarlos, unificar procedimientos con características comunes, etc… puede resultar algo tremendamente complejo.

¿De dónde puede proceder esa complejidad? Pues como suele pasar en proyectos de esas características, es decir, si el proyecto simplemente fue una idea brillante de alguien, que además consiguió respaldo para lanzarlo, pero después no cuenta con el apoyo y seguimiento continuo de la dirección de la organización, no se conseguirá nada (algo parecido a lo que expliqué en su momento en los posts dedicados al Plan de Sistemas y que pasa con cualquier proyecto que tenga unas características horizontales), ya que conseguir una reingeniería de procedimientos implica un esfuerzo importante: conseguir consensos, modificar normativas internas en la organización o incluso legislación en el caso de Administraciones Públicas, mover mucha gente que incluso se encuentran en distintas localizaciones geográficas, etc… Ese esfuerzo solo se conseguirá, como he comentado si la dirección de la organización lo toma como un proyecto propio y consiguen por la vía del diálogo, de la imposición normativa y el seguimiento constante, que cada departamento de la organización tome el proyecto como una tarea más de sus competencias ordinarias y colabore desde el principio, hasta el final.

Por otro lado, un proyecto de estas características nunca debe estar liderado desde informática, en cualquier caso el Departamento de informática puede participar si se quiere como consultor de apoyo, debido a la experiencia que siempre han tenido estos departamentos en la implementación de procedimientos en sistemas informáticos (que en cierto modo siguen un proceso de reingeniería, para adaptar la problemática del mundo real a un programa de ordenador). La coordinación y dirección técnica de estos trabajos debe venir por el área legislativa de la organización, la cual debe tener expresamente encomendado el trabajo por la dirección de la organización y haberla dotado de los medios oportunos para realizar este trabajo.

En muchos casos, es interesante contar con un apoyo de una empresa consultora externa especialistas en estos temas, ya que puede facilitar mucho el trabajo, eso sí, he dicho especialistas (y eso no es sencillo, ni barato encontrarlo) y por supuesto esos especialistas tampoco deben ser informáticos.

En resumidas cuentas, son muchos los ingredientes que se deben sumar para que una reingeniería de procedimientos que afecte a todo el ámbito de una organización pueda llegar a buen fin. De no ser así, mejor ni plantearse el realizarla o bien planteárselo como un proyecto a largo plazo que se vaya haciendo departamento a departamento de la organización. En este segundo caso, también es necesario la dirección y respaldo continuo de la dirección de la organización.