miércoles, 28 de octubre de 2015



Gestionar sin recursos

En ese esfuerzo temporal que supone un proyecto (según el PMBOK) pueden pasar muchas cosas, entre otras, que no sea tan temporal, ya que puede convertirse en una eternidad sobre todo cuando te quedas sin presupuesto,  sin  recursos o sin patrocinador.
 
No sólo de “voluntarismo”  vive un proyecto, que no debería, ya que es un engranaje con sus hitos, certificaciones y demás controles para evaluar desvíos y cambios de alcance.
 
Pero cuando nos quedamos sin gas es cuando empezamos a ser imaginativos. Lanzamos mensajes disimulados de que todo marcha bien y que se trata  sólo de un ajuste, de una reestructuración o que vamos a reforzar el equipo (este último es de nota).
 
La putrefacción empieza desde dentro, aunque la carcasa, lo que se percibe desde fuera, la apariencia está intacta. Poco a poco se ralentizan los desarrollos y las entregas se dilatan. La calidad disminuye y las excusas empiezan a florecer.
 
La cosa pierde color (como dice la canción de RF) y ya se muestran los primeros síntomas de que algo no marcha bien.
 
Los que estamos dentro ya percibimos el olor desde el principio y nos miramos unos a otros preguntándonos cómo vamos a conseguir cumplir con nuestros compromisos.
 
Si no podemos mantener el equipo y hacemos duros ajustes, los que se quedan ya saben lo que les espera, más esfuerzo y taparse la nariz o buscar en otro sitio. Desbandada, el riesgo número uno.
 
Además todo esto es altamente contagioso y el desánimo y los roces empiezan a surgir de forma natural entre los equipos.
 
Hasta aquí el panorama no es muy alentador pero no todo tiene que terminal mal.
 
Los que llevamos mucho en esto ya hemos pasado por pesadillas de este tipo y de todo se sale, aunque sea dejando unos cuantos cadáveres.
 
Ahora es cuando en este post os doy las soluciones y las enumero. No es tan fácil, platear el problema es más sencillo.
 
En un anterior post “Recuperar la confianza en un proyecto” hago algunas reflexiones sobre esta situación aunque tampoco vais a encontrar la enumeración de las soluciones, eso sí creo que es interesante leerlo.
 
Es obligado hacer un plan en el que tengamos claro algunos puntos esenciales:
 
·         Hasta dónde podemos llegar y qué podemos cerrar con garantías (que nos queda de gas).
·         Replanificar sí o sí en base a nuestros recursos. Seamos objetivos, muy objetivos y de paso objetivemos.
·         Hacer un plan de comunicación interno, que no cunda el pánico y externo (vender la replanificación).
·         Anteponer la calidad a la cantidad. No hacerlo es un error habitual en estas situaciones.
·         Informar claramente a nuestros Stakeholders (o a los que podamos).
·         Por su puesto buscar la financiación en la empresa o incluso en el cliente (si podemos justificar un cambio de alcance o un interés común entre ambas partes).
 
De todos los males que puede sufrir  un proyecto es el presupuestario el que más daño hace. Es un cáncer rápido y letal incluso para los proyectos que marchan bien.
 
Mi consejo es centrarse en el objeto presupuestario, es conveniente reservar nuestros esfuerzos en un único objetivo conseguir financiación.
 
Cuando he trabajado con centros de coste me ha tocado peregrinar por comités tediosos y poco resolutivos a los que he llegado con replanificaciones, excusas de cambio de alcance o malabarismos verbales.
 
También he conseguido presupuesto en el “mercado negro” o mercadillo diría, jugando con los CECO,s bianuales, traspasos de tarifa ente JP,s AF,s y demás perfiles y por supuesto en el regateo con otras áreas proveedoras, en general poco glamuroso.
 
Por concluir, dependiendo de la organización, estrategia y criticidad el proyecto (por no hablar del interés de la empresa) tendremos más apoyos para conseguir nuestro objetivo. Y aquí es muy importante llegar con un plan para dar confianza y sobre todo con un claro y motivador mensaje interno de cara a nuestro equipo que es, en definitiva, el único capaz de transformar una mala situación en un éxito profesional. 

miércoles, 26 de agosto de 2015



Estás en una empresa analógica o digital?
En el sistema de información de una empresa existe una capa “CORE” donde básicamente se procesa toda la actividad del negocio, gestionamos los servicios que prestamos y los facturamos.

¿Pero qué compartimos con nuestros clientes?  ¿Cómo participan?
En la mayoría de los casos nuestra relación con el cliente es unidireccional,  desde la empresa al cliente. Informamos de un estado o del resultado de una petición pero el cliente no se ve involucrado, no participa activamente, dentro de nuestro proceso de negocio.
Cambiar a una relación bidireccional para que el cliente forme parte de nuestro proceso a través de un canal digital es lo que hace que debamos adaptar nuestro “viejo” sistema de información.
Algunas empresas se han dado cuenta de que este cambio no es una cuestión de marketing o de reputación en la red ni de impulsar nuevos productos. Es y será un elemento diferenciador frente a la competencia.
El ecosistema entre empresa y cliente está cambiando y es cada vez más exigente sobre todo por parte del cliente que está evolucionando muy deprisa hacia el canal digital, punto de encuentro, en el que debería converger con la empresa.
El usuario/cliente digital es práctico y directo cuando se trata de resolver una situación y quiere surfear por nuestra empresa desde cualquier lugar y en cualquier horario. Quiere la información actualizada y no esperar a que le llamen o le indiquen el próximo paso  y  lo más importante, no sólo consume, también participa y cambia el proceso en base a sus necesidades.
No pensemos sólo en el usuario tradicional (pre-digital) que está en fase de aprendizaje, sino en las nuevas generaciones que han crecido digitalmente y que han asumido de forma natural el canal digital. Son nuestros inmediatos clientes y no se conforman con rellenar un formulario en la web o consultar el estado de su reserva.
¿Están nuestros sistemas tecnológicos y nuestras organizaciones preparadas para dar este tipo de servicio?
En la mayoría de los casos las grandes empresas tradicionales siguen manteniendo sus viejas aplicaciones y han resuelto las nuevas añadiendo capas con interfaces de intercambio de información que han salvado alguna situación pero que han comprometido el futuro.
Las empresas de nueva andadura o tipo Startups ya han enfocado su modelo de negocio a la empresa digital. Lo tienen más fácil porque no necesitan migrar su sistema.
Recibir notificaciones sobre la reserva de hotel, un vuelo, la cita del médico o el aviso para recoger el coche del taller, no forma parte de un proceso digital, son notificaciones off line.
¿Quién puede abordar y patrocinar un cambio tan complejo?
Está capacitado el área de TI para abordar una estrategia digital o sigue existiendo una brecha entre TI y negocio.
La famosa frase de “los árboles no nos dejan ver el bosque” se puede aplicar al día a día en las áreas de tecnología que sufren constantes evolutivos, correctivos e incidencias, encontrándose contaminados por los procesos actuales que imposibilitan, quizás, liderar este cambio.
Una nueva figura,  la del Chief Digital Office” (CDO) puede ser la clave siempre que sea independiente del área tecnológica y que cuente con el apoyo de la dirección de la empresa, del CEO por ejemplo,  para posibilitar la transformación de la empresa analógica a digital.
Así que pensemos cómo podemos guiar a nuestro cliente desde el minuto uno en un proceso digital “End to End” cuando se produce una contratación, una reclamación o un siniestro.
Como usuario de una compañía médica me gustaría acceder a mis  resultados médicos y compartirlos con el especialista/s, vía videoconferencia por ejemplo,  que me los explicasen y me dieran la información sobre el tratamiento y las recetas para los medicamentos, un certificado médico,  concertar una nueva cita para más pruebas si procede y consultar el detalle de la factura o las coberturas de mi póliza. Todo online, sencillo y amigable de tal manera que me permita, a modo de ejemplo, ampliaciones de póliza en el momento o acceder a centros de rehabilitación cerca de mi domicilio  o de otro lugar donde me encuentre y que se puedan  organizar en función del tratamiento, que los pueda reservar y elegir al profesional que me interesa.
Si se produce un accidente con mi coche me gustaría localizar la grúa más próxima ver in situ los talleres concertados o gestionar el coche de sustitución al momento sin necesitar contactar con la compañía, a través de mi dispositivo móvil,  por ejemplo.

Una vez iniciada la reparación debería de tener acceso al informe pericial y contactar directamente con el perito para aclarar posibles dudas, conocer el estado de la reparación y  solicitar información en línea al responsable y a las condiciones de mi póliza y/o contratar servicios adicionales, solicitar alguna prestación o en caso de asistencia legal tener acceso y estar informados de las vistas en el Juzgado.  

En caso de lesiones u hospitalización igualmente acceso a todo el expediente médico compartirlo con el tramitador y gestionar posibles indemnizaciones.

Algo perfectamente posible pero que resulta complicado hacerlo de forma integral e independiente por parte del cliente.

Es decir, podemos dejar que el cliente participe de nuestro sistema de información generando nuevas actividades en nuestro proceso de negocio. 

El cambio de una empresa analógica a digital no es sólo tecnológico, es organizativo y estructural. Requiere flexibilizar y cambiar radicalmente la forma de trabajar y entender el negocio.
 

jueves, 14 de mayo de 2015

La tecnología llave de la rentabilidad en los proyectos BPO

 
Los gastos de personal en los que incurre un proyecto de BPO pueden ser elevados pero sobre todo es la necesidad de competir en el mismo ámbito, digamos “local” sin posibilidad de deslocalizar por temas operativos o legales, lo que hace que las tarifas se encuentren muy ajustadas frente a la competencia. Siendo así, ¿qué marca la diferencia?, ¿qué hace que podamos ajustar un variable competitivo por servicio?

En estos años de crisis si algo hemos sufrido, entre otros temas, han sido los constantes ajustes en la tarifa de los servicios que prestamos a nuestros clientes. Nuestra reacción ha sido siempre, en gran media, aplicar los avances técnicos y cuestionar el proceso. 

La premura y oscilación de la producción junto con la indisponibilidad de recursos, rotación o curva de aprendizaje hace que el desvío del proyecto/servicio pueda terminar con el ya ajustado margen.

Como todo proceso productivo el arranque y ajuste inicial del servicio puede acarrear sobrecostes, sobre todo si el volumen inicial no justifica inversiones tecnológicas para agilizar los tiempos y garantizar la calidad.

Los servicios que se llevan prestando hace tiempo son en los que más debemos hacer foco tecnológico, ya que conocemos sus riesgos, tenemos experiencia y podemos estar más cómodos para experimentar.

El elemento diferenciador frente a la competencia es la aportación de soluciones innovadoras, en base a la experiencia y conocimiento, en el tratamiento y procesamiento de los servicios externalizados.

Es necesario aplicar de forma precisa los avances tecnológicos para “eficienciar” los procesos.

Utilizar sistemas de reconocimiento digital (OCR), para la localización de información o técnicas para el reconocimiento de firmas entre otras hace que la rentabilidad del servicio mejore y la confianza del cliente en la calidad del servicio también.

Podemos pensar que el uso del “Cloud” o el Big Data pueden ayudarnos a mejorar la calidad de nuestros procesos. ¿Podemos ampliar y flexibilizar el servio con nuestros clientes? Está claro que la respuesta es SI.

¿Podemos ayudar en el back-service de la Banca 3.0? ¿Qué tecnología precisa? En los procesos actuales tratamos grandes volúmenes de documentación de toda su actividad, podemos añadir los metadatos que se precise y catalogar toda su información en apenas horas, ¿es suficiente? Si aplicamos los algoritmos del Big Data, de forma racional, en esa coctelera inmensa de datos desestructurados podemos ayudar a resolver ciertas cuestiones, buscar tendencias o aplicar reglas de negocio para campañas, por ejemplo.

No debemos cuestionar el tipo de tecnología frente al tipo de BPO que realizamos, es un error. La tecnología no tiene apellidos y tenemos que explorarla para adaptarla a nuestras necesidades e incluso proponer nuevos servicios derivados de un avance tecnológico en cualquier sector.

No se trata sólo de “informatizar” o “mecanizar” procesos el uso de la tecnología debe de ser catalizador de nuevos servicios y propuestas innovadoras para los clientes.

Cómo podemos mejorar la rentabilidad de los servicios y trasladar al cliente un mejor precio, haciéndonos más competitivos y mejorando la calidad.

Mediante un proceso continúo de mejora. No demos por estabilizado un servicio, apliquemos “nuevas” formulas.
  • Cuestionar los procesos, La rutina a la larga mata la eficiencia del proceso. Busquemos un tercero con experiencia en otros procesos y que lo cuestione. Puede sorprendernos. 
  • Comunicación con el cliente. Seguimos haciendo algo, por inercia, que ya no le interesa al cliente o su modelo ha cambiado. Podemos mejorar mucho si revisamos y actualizamos las necesidades del servicio. 
  • Buscar la tecnología adecuada. Todos los días salen al mercado nuevas propuestas de tecnología, Hard&Soft en diferentes sectores, seamos imaginativos. Podemos aplicar robótica o redes sociales al BPO ¿Por qué no?
Sólo las empresas que tengan claro que deben aplicar altas dosis de tecnología, arriesgando incluso, en los entornos de BPO-BTO pueden competir con garantías y hacerse hueco en las nuevas y exigentes necesidades que demandará el cliente.

martes, 10 de febrero de 2015

 

El Arte de la definición funcional


Dejando de lado las metodologías ágiles donde la interacción es constante (entre desarrollador/cliente)  y donde se ven "in situ" los avances, se hace necesario establecer la forma de comunicar el  qué queremos hacer cuando el alcance es de mayor calado e implica mayor número de interlocutores. 

Aunque el debate sobre el desarrollo incremental versus funcional tradicional es interesante sería mejor tratarlo en otro post. 

Presentar una documentación funcional  que el cliente entienda y que recoja  el alcance y las actividades a desarrollar, que sea claro y suficiente para trabajar por parte del área técnica es, por decirlo de alguna manera, un milagro.  
 
Dos mundos muy diferentes condenados a entenderse si queremos tener éxito en nuestro proyecto. En el centro como interlocutor de ambas partes está la definición.

El documento entregable al cliente podría ser un “Documento de Descripción de Requisitos” (DDR) en el que deberíamos tener en cuenta: 

Qué debe de contener. 

Debe contener una enumeración de todos los requerimientos del proyecto por tipos, con su codificación, versionando y sus dependencias con otros.

Además debe enumerar todos los elementos necesarios para la trazabilidad y versionado del documento (control de cambios). El objetivo es poder seguir históricamente la evolución de cada uno de los requerimientos, número de versiones trabajadas, cambios realizados, participantes o comentarios añadidos. 

El documento debe de adaptarse al “core” de negocio y debe de mantener la esencia de la definición.  

Debemos tener presente siempre el que es lo que queremos hacer, todo lo que se salga de esta línea no debe de describirse y todo lo que no esté en la definición no existe y no se trata en el proyecto.

Qué no debe incluir.

El cómo y el con qué son elementos, en mi opinión, que no deben aparecer ni insinuarse en un documento de definición.

La forma de cómo se va a desarrollar la solución, para abordar el que de la definición funcional, debe de quedar fuera del alcance del DDR.

Por ejemplo, definir un “Proceso de recuento del ranking de popularidad”.

En este caso desarrollamos la definición, el qué, pero no debe trascender el cómo lo vamos a calcular. Esta información aparecerá en otros documentos como DDS, DRT, o en la Micro o Macro de la Arquitectura en el catálogo de software si hablamos de reutilización de código.

Con qué,  No vamos a indicar lenguajes, base de datos, plataformas o tecnologías.

Tampoco debemos utilizar terminología técnica que pueda confundir al cliente.

Hay que evitar en  la medida de lo posible, las listas de valores o los usuarios nominativos dentro de la definición ya que estos pueden cambiar y nos obligaría a cambiar el documento y su versión. Utilicemos otros documentos para estas configuraciones dinámicas.

¿Podemos definir mejor?

Debemos realizar definiciones atómicas de cada requerimiento.

Pocas líneas, párrafos cortos y directos, expresados de forma clara y  sencilla, ajustadas y acotadas al requerimiento que estamos tratando.

Tratar cada requerimiento uno a uno sin mezclar funcionalidades.

El enunciado de cada requerimiento debe de ser claro y único. Es muy importante, “lo que hace es lo que hace y nada más”, si es necesario desglosarlo en varios, hagámoslo. Si intuimos que puede cambiar, mayor motivo para aislarlo y acometer los cambios por separado.

Por ejemplo, un enunciado de un requerimiento no podrá ser “Marcar usuario como más valorado en la comunidad y mostrar el ranking de reputación dentro la comunidad”. Está claro que son dos requerimientos “Marcar” y “Mostrar”. Además no debemos desarrollar parte del requerimiento en el propio texto del enunciado.

Quedaría por ejemplo “Asignar valoración de Usuario” y “Asignar ranking de Usuario”.

En cada uno de ellos se desarrollará las condiciones y tipos de marca y valoración, y sólo en estos requerimientos y en ningún otro se tratarán estos aspectos.

Podremos vincular o asociar funcionalidades dentro de un requerimiento si en el desarrollo del mismo lo consideramos necesario.

Un requerimiento se define una única vez y no puede aparecer en otra parte del documento.

Podemos apoyarnos en maquetas visuales (imitando metodologías ágiles) que podemos mostrar al usuario (interacción visual), sobre todo cuando se trata de una interacción con aplicativos, pantallas o flujos de BPM.

La colaboración del área de “experiencia de usuario” es fundamental para conseguir una buena ergonomía y usabilidad del producto.

Estas maquetas se pueden adjuntar a los requerimientos que se vean afectados pero siempre indicando que es “LowFidelity” y nunca será un compromiso de lo que vamos a desarrollar. Para esto podremos construir una maqueta “HighFidelity” que deberá ser aprobada por el cliente y supervisada por experiencia de usuario para garantizar la calidad de su usabilidad y cumplimiento con las normas de arquitectura funcional.

Firma del cliente

Este esfuerzo de colaboración y de descripción  con sumo cuidado de qué queremos hacer tiene como objetivo la firma del cliente y el compromiso por parte del proveedor.

Este aspecto es,  según mi experiencia, un paso casi tan complicado como la oferta comercial, ya que en este momento se tiene el detalle de lo que vamos a construir y estamos solicitando el compromiso al cliente.

Algunas veces moverse en la indefinición suele “ayudar” más al cliente que al proveedor.

Conclusión

Al final nada de esto sirve si no somos capaces de redactar de forma clara, precisa y ordenada los requerimientos funcionales y el alcance de nuestro proyecto.

El documento funcional es además un documento contractual  con el cliente pero también con las áreas internas o terceras ya que es punto de partida del resto de actividades, planificación, evaluación de riesgos, viabilidad financiera, gestión recursos, arquitectura técnica y un sin fin de documentos que se basan en un DDR.

Dos riesgos latentes en una definición son las “Indefiniciones” y/o las “interpretaciones”.

Si aparecen en el documento es porque no hemos sido capaces de cerrar la funcionalidad (requerimientos) y/o el alcance (objeto del proyecto) y en este caso, todo el esfuerzo en la definición y el valor del documento (DDR) que podamos darle se desvanece y puede generar importantes sobrecoste y fricción entre las partes.

Seamos flexibles, no olvidemos que se trata de “interacciones funcionales” que se revisan constantemente, no se trata de acertar a la primera.

Una vez “cerrada” la definición proseguimos con el procedimiento de desarrollo con sus ciclos de trabajo y certificación y  en paralelo preparemos una nueva versión y recojamos los cambios de los requerimientos. Como comentaba, intentemos ser flexibles sin que sea necesario competir con las metodologías ágiles.  

No es un proceso sencillo requiere mucha práctica, enfoque y capacidad de síntesis. En definitiva no es necesario escribir un bestseller.

domingo, 4 de enero de 2015


Generador de espacios virtuales temporales en entornos colaborativos


Hace algún tiempo tuve la oportunidad de dirigir un proyecto en el sector bancario cuyo objetivo era dotar de un espacio de trabajo temporal a equipos multidisciplinares y geográficamente  dispersos.

No es  extraño que en los  proyectos actuales  sea necesario poner en contacto a personas de distintos lugares o países con diferentes responsabilidades, todo ello  enmarcado  en una actividad temporal. Como indica la propia  definición de  proyecto “un esfuerzo planificado, temporal y único realizado para crear productos o servicios únicos que agreguen valor o provoquen un cambio de  beneficios”.

Además de ser un esfuerzo temporal y único debemos añadir la inmediatez a la hora de organizar un equipo en un breve espacio de tiempo para iniciar los trabajos. De lo contrario no sería competitivo.

¿Cómo podemos poner a trabajar de forma coordinada a un equipo que se encuentra en diversas ubicaciones, con distintas franjas horarias, con diferentes responsabilidades y actividades?

Los espacios de colaboración son áreas virtuales que están dotadas de funcionalidades enfocadas a nuestras actividades y objetivos, que nos permiten registrar actividades, cargar  documentación,  notificar  eventos, calendarios, planificación de hitos, contactos, versionado y trazabilidad del entorno entre muchas otras posibilidades, tantas como sea necesario para realizar nuestro trabajo según su naturaleza.

La filosofía de trabajo de un entorno de este tipo difiere en mucho del que podemos utilizar de forma tradicional, correos electrónicos, carpetas compartidas, etc. Nos permite compartir   de forma centralizada un repositorio de información con todo el conocimiento del proyecto evitando islas. Los integrantes del grupo no tienen información en local (en sus dispositivos) y no se producen pérdidas de información si un miembro abandona el grupo.

Acceder a un espacio de colaboración es acceder al conocimiento del proyecto, a su histórico a tener contacto  a través de este medio con sus integrantes y a asegurar que toda su actividad quede registrada, mediante versionado de la documentación, ciclos de aprobación, auditoría de procesos o notificaciones por eventos a los miembros del equipo.

No es lo mismo preparar una actuación para la  adecuación de una ley o normativa bancaria que  una selección para RRHH o  un proyecto de TI o de relaciones internacionales. Cada uno de los espacios requerirá unos flujos de procesos, un tipo de calendario, documentación específica, auditoria de seguridad, indicadores de actividad, etc.

La operativa a seguir con un “Aprovisionador de Espacios de Colaboración” es la de identificar el tipo de espacio a generar y configurar cada uno de ellos:

• Con una funcionalidad común y/o específica para acometer la actividad o proyecto.
• Con un dimensionamiento, número de integrantes, volumetrías, accesibilidad, etc.

Una vez decidido el espacio que mejor se adapta a nuestras necesidades, y en pocas horas, podemos tener un entorno disponible en cualquier sitio y accesible desde cualquier dispositivo, listo para empezar a colaborar de forma organizada y segura.

Finalizado ese esfuerzo temporal, ese espacio virtual puede desaparecer, disolverse una vez conseguido su objetivo: crear productos o servicios únicos que agreguen valor o provoquen un cambio beneficioso.

Dependiendo del número de espacios a gestionar necesitaremos una herramienta que nos permita gestionar los entornos de trabajo, su seguridad, borrado, notificaciones, dimensionamiento, etc.

Las empresas requieren entornos dinámicos de trabajo, rápidos y flexibles que se creen y se destruyan, como sus productos, alineados con las necesidades de negocio, disponibles en horas para hacer frente a la competencia.