REINGENIERIA DE PROCESOS Y LA TECNOLOGÍA

Como ya sabemos hablar de reingeniería de procesos es hablar de cambios radicales en los procesos de negocio. La integración adecuada entre personas, procesos y tecnología es un requisito clave a cumplir en este tipo de proyectos ya que esta integración permitirá el logro de los objetivos estratégicos y por el ende la generación de valor.  

Actualmente la tecnología se transforma en un facilitador clave para llevar a cabo la reingeniería de procesos de negocio (BPR, Business Process Reingeniering). Ahora el dilema o el principal problema se encuentra al momento de elegir la tecnología que nos llevara rumbo hacia la empresa soñada. El CIO o Lìder Tecnológico se enfrenta normalmente a una avalancha de opciones tecnológicas disponibles actualmente en el mercado.  Ahora que pasa cuando la tecnología(llámese plataforma y todos sus aplicaciones) elegida no es la adecuada para la organización. ¿Cuál sería el resultado del proyecto de reingeniería? ¿Cual es el impacto que tiene una mala elección de las TIC en los objetivos estratégicos de la organización?

Como líderes de proyecto la pregunta a resolver es ¿como eliminar/mitigar estos riesgo? ya de por si el escenario donde nos desarrollamos es bastante complicado debido a la variabilidad causada por las tantas ofertas,cambios en tecnológicos e innovaciones en el mercado, por lo que  esta pregunta se vuelve el mayor problema a resolver.

Quería recomendar en base a mi experiencia a las personas que implementan proyectos de reingeniería, que al momento de elegir alguna infraestructura/plataforma evalúen dos factores claves que son dejado de lado debido a que normalmente los factores mas considerados o que determinan la elección entre una tecnología u otra  es el factor económico, dejando de lados otros factores muy importantes. Estos factores se definen en el modelo TAM (Modelo de Aceptación Tecnológica) el cual a la fecha es un modelo muy aceptado. Los factores a los cuales se hace referencia en este modelo son la Facilidad de Uso Percibida y Utilidad Percibida de la tecnología, estos dos factores que parecen deberían ser tomados en cuenta por sentido común, muchas veces no son la práctica común debido a diversos factores (políticos, económicos, legales, intereses particulares, conocimientos,  etc.). Tal como lo menciona el modelo estos 2 factores tienen una relación directamente proporcional en la Intención de uso del sistema por parte de las personas quienes son las que finalmente sufrirán por una mala elección tecnológica.  

Solo para finalizar quisiera tomar un párrafo de una entrevista realizada a  Steve Jobs, en el cual indica que la motivación que tuvo para hacer una serie de innovaciones, era la de proporcionar a las personas herramientas que les permitieran incrementar o potenciar sus habilidades. Creo que de eso se trata finalmente.

“Si es simple, no lo compliquemos. Si es complicado, hazlo simple”.

TAM:

·   Utilidad Percibida (PU): Grado en el que una persona estima que el uso de un determinado sistema mejoraría su rendimiento en el trabajo.

·   Facilidad de uso Percibida (PEOU): Grado en el que una persona cree que el uso de un sistema particular está libre de esfuerzo.

·   Intención hacia el Uso (BI): Grado en el que una persona ha formulado planes conscientes para desarrollar (o no) alguna conducta futura. 

CADENA CRÍTICA

La cadena crítica también es conocida como CCPM de las siglas en inglés Critical Chain Project Management (Gestión de proyectos mediante cadena crítica), dicha metodología fue presentada en el año 1997 por Eliyahu M. Goldratt en su libro "Cadena crítica" el cual alcanzo un éxito en ventas y creando un mercado de consultoría e implantación de dicha metodología en diferentes empresas y organizaciones de todo el mundo.

Normalmente las estimaciones con respecto a la duración  de las actividades del proyecto tratan de protegerse de factores externos e internos que podrían afectar el desarrollo del mismo, por lo que las estimaciones de tiempo que se consideran en el cronograma normalmente terminan con la siguiente ecuación =  “tiempo pesimista + factor de protección (colchón)” alargando sobremanera la duración del proyecto y los costos, reduciendo las posibilidades de que el cliente ejecute el proyecto. De esta manera el que ejecuta el proyecto intenta reducir la incertidumbre que se presenta al ejecutar un proyecto por primera vez, pero no se gestiona la misma.

Ahora la pregunta que nos hacemos es, si hay tanta protección en cada actividad  ¿Por qué no terminan a tiempo, con las especificaciones originales y dentro del presupuesto original?

Eliyahu M. Goldratt responde esta pregunta y lista una serie de mecanismos en los cuales se  desperdicia la protección o los famosos colchones de tiempo en las actividades: 

• El síndrome del estudiante: como no hay prisa, comenzamos en el último minuto.

• La ley de Parkinson: el trabajo se expande para llenar todo el tiempo disponible.

• Tareas múltiples en una misma área o persona.

• La dependencia entre pasos consecutivos y paralelos causa que las demoras se acumulen y los adelantos se desperdicien (teoría de restricciones).

Y buena las ya  clásicas medidas conocidas aplicadas por todos para poder lograr los “objetivos del proyecto”:

• Aumentar el número de “horas extras”.

• Aumentar el número de trabajadores.

• Salir del presupuesto.

• Reducir las especificaciones originales.

• Reducir el período de pruebas.

• O, alguna combinación de las anteriores.

El método más tradicional para determinar la duración del proyecto es la del camino crítico (CPM), el cual identifica las dependencias entre las tareas que conforman el camino crítico. Sin embargo, el CCPM además de identificar las dependencias entre las tareas también identifica las dependencias entre los recursos necesarios.

Esto resuelve los problemas de disponibilidad de recursos, identificando los recursos que son cuello de botella y planificando en función de estos para prevenir posibles conflictos. Vamos a tener en cuenta la perspectiva de los recursos, porque serán una limitación real al abordar los proyectos. De hecho, el CCPM tiene la base de la teoría de las limitaciones (TOC).......................................

GENERACIÓN DE IDEAS y LOS GRUPOS DE MEJORA

Para la solución de problemas complejos en las organizaciones enfocadas a la calidad, surgen los grupos de mejora, que son equipos de trabajo dedicados a la mejora constante de la calidad, sin embargo estos grupos de mejora normalmente no siguen una adecuada metodología, lo normal es que se invierta tiempo en largas reuniones sin objetivos definidos. Otra problemática en este tipo de reuniones es la falta de creatividad que se observa durante una sesión de lluvia de ideas y esto se evidencia en la cantidad y calidad de alternativas generadas las cuales casi nunca tienen una cuota de innovación o que no salen los parámetros establecidos. Un comportamiento típico que se evidencia en las reuniones de grupo es el del “destructor(es)” que se enfoca en  eliminar a toda costa las alternativas propuestas, casi nunca se detienen a pensar un poco  en generar nuevas alternativas o buscar lo positivo de las que se han generado(como podría funcionar), y esto se podría deber a varias causas: la primera es que las alternativas de solución propuestas no son suyas, la segunda de las causas es que es lo único que saben hacer (parte de una educación donde se ha mutilado la creatividad "Ken Robinson"), la tercera es que esta forma de actuar es una forma fácil de “parecer” inteligente, la cuarta, relacionada a la segunda es que se encuentran en su zona de confort, la quinta que están mas interesados en el fracaso del proyecto, la jerarquía que tienen en la organización y así sucesivamente…

Así que tenemos que lidiar con varias cosas, la falta de creatividad, la fuerte negatividad, la falta de metodología, la falta de liderazgo, la falta de participación, y la desmotivación generada en el grupo debido a los malos resultados.

Quería recomendar una técnica y/o metodología  que me ha ayudado muchísimos para la solución de problemas complejos,  esta es los Seis sombreros para pensar (en inglés Six Thinking Hats) que presenta Edward de Bono en su libro del mismo nombre las cual esta muy relacionada a la metodología DMAIC de Six Sigma para la mejora de procesos pero desde un punto de vista mas dinámico como un sistema vivo o en movimiento como el lo llama.

Algunas de las ventajas con respecto al uso de esta metodología/técnica  es que se ahorra más de un 40% del tiempo en las reuniones, equilibra las intervenciones de sombrero negro(personas negativas), reserva tiempo para la creatividad y la exploración exhaustiva de la situación y se pueden definir objetivos metas claras de manera conjunta con respecto a las ideas.

REGLAS PARA ADMINISTRAR TI BASADOS EN TPS (SISTEMA DE PRODUCCIÓN TOYOTA)

Como las oportunidades de obtener ventajas estratégicas a partir de la TI están desapareciendo  rápidamente, a muchas empresas les convendría reevaluar como invierten en TI y en la gestión de sus sistemas.
El Sistema de Producción Toyota (TPS) posee varios principios que fácilmente pueden ser tomados en cuenta por los responsables de Tecnologías de Información (CIO) al momento de tomar decisiones con respecto a la adquisición y operación de las TICs en la organización.
Aquí presento algunas reglas basadas en el Sistema de Producción Toyota(Lean Manufacturing) que aplican al entorno de IT dentro de la Organización.

- Las tareas estandarizadas son el fundamento de la mejora continua y de la autonomía del empleado
Estandarice sus procesos:
Los técnicos en muchos casos poseen conocimiento especializado(conocimiento tácito) de  los sistemas sobre los que opera la organización, estas personas son las únicas que conocen las actividades a realizar para solucionar un problema y/o realizar una configuración, esto podría significar un riesgo para la continuidad del negocio, transforme ese conocimiento tácito del empleado(Know how) a conocimiento explícito(procedimientos, guías de usuario). Establecer una cultura de registro, como parte  de una Gestión del Conocimiento, beneficiará a la organización.

- Use solo tecnología fiable y absolutamente probada que dé servicio a su gente y a sus proceso:
No, lidere siga a otros:
La ley de Moore garantiza que mientras más se espera para hacer una compra de TI, más se obtiene. Al esperar, se disminuye el riesgo de comprar algo tecnológicamente fallado o condenado a quedar rápidamente obsoleto. En algunos casos, tiene sentido estar en la frontera, pero esos casos son cada vez más raros, a medida que las capacidades de la TI se van homogenizando.

- Elimine las actividades que no general valor al proceso
Gaste Menos : 
Según algunos estudios, las empresas que más invierten en TI rara vez registran los mejores resultados financieros. Resulta cada vez más difícil conseguir ventajas competitivas invirtiendo en TI, pero es cada vez más fácil que una empresa se vea en desventaja en costos. La gran mayoría de los empleados que usan PCs sólo utilizan un pequeño número de aplicaciones sencillas-procesador de texto, hojas de cálculo, correo electrónico y navegación en la red. Estas aplicaciones están tecnológicamente maduras desde hace años. Requieren solo una parte del poder computacional de los microprocesadores actuales. Sin embargo las empresas siguen distribuyendo versiones nuevas de hardware y software a todos sus empleados en muchos casos inducidos por los vendedores.
A mi entender todos los principios del Sistema Toyota(Lean) aplican a un entorno de IT, y es una  buena base para tomar decisiones,  espero  que puedan revisar estos principios y aplicarlos como guías para la toma de decisiones.

PLANEMIENTO ESTRATEGICO DE TECNOLOGÍAS DE INFORMACIÓN

El riesgo de incorporar tecnología de información (TI) se ha incrementado en las organizaciones. Esto se debe principalmente a que la planeación y la planeación estratégica, prácticamente no existen. Las tendencias actuales de desarrollo de TI en el mercado, se han caracterizado por esforzarse en automatizar el "desorden". Muy poco esfuerzo es puesto en especificar la estrategia de negocios y en construir un modelo de la organización, como precursores en la determinación de requerimientos de TI. Las aplicaciones son construidas para satisfacer metas a corto plazo o problemas inmediatos, produciendo islas de TI a lo largo y ancho de todas las áreas funcionales. La necesidad de un plan de TI es clara, pero el proceso para lograrlo no es obvio

La PETI (Planeación Estratégica de Tecnología de Información) es ampliamente reconocida como una herramienta para ordenar los esfuerzos de incorporación de TI. Establece las políticas requeridas para controlar la adquisición, el uso y la administración de los recursos de TI. Integra la perspectiva de negocios/organizacional con el enfoque de TI, estableciendo un desarrollo informático que responde a las necesidades de la organización y contribuye al éxito de la empresa. Su desarrollo está relacionado con la creación de un plan de transformación, que va del estado actual en que se encuentra la organización, a su estado final esperado de automatización, esto, en concordancia con la estrategia de negocios y con el propósito de crear una ventaja competitiva.

¿Alcance del Proyecto o Alcance del Producto?

Al inicio de mis actividades en la ejecución de proyectos, tenía varias dudas con respecto al alcance del proyecto y el  alcance del producto.

Quería compartir con ustedes algunas recomendaciones para definir el alcance del producto y el proyecto que nunca me fallan:

El alcance del producto: lo podemos entender como las características o funcionalidades que tendrá el producto o servicio que se obtiene como resultado de un proyecto. Personalmente asocio el alcance del producto  a los siguientes cuestionamientos: ¿qué necesidad hay que satisfacer? ¿Qué características deberá tener el producto y/o servicio para satisfacer esas necesidades? ¿Las características del producto y/o servicio que tenemos identificadas satisfacen los requisitos del cliente?

Dentro de los requisitos del cliente y que forman parte del alcance del producto también tenemos los requisitos de costos y tiempos.

El resultado de un proyecto puede ser un producto y/o servicio, el producto puede ser tangible o intangible.

El alcance del proyecto: por su parte son las actividades o trabajo que deben llevarse a cabo para poder entregar el producto o servicio con las características o funcionalidades requeridas de acuerdo a los requisitos dados por el cliente o la organización ejecutante. Es decir, es todo el esfuerzo que debe realizarse para cumplir con el alcance del producto. Entre las distintas actividades que incluye el alcance del proyecto se pueden encontrar, por ejemplo: gestión de tiempos, gestión de costos, adquisición del personal necesario, gestión de calidad, gestión de proveedores, etc. 

Para lograr un producto y/o servicio de alta calidad recomiendo lo siguiente:

• Especialización: Desarróllate en un determinado mercado, como dirían muchos maestros: “se especifico” identifica las necesidades de ese mercado y como satisfacerlas de la mejor manera. Por ejemplo si te vas a dedicar a realizar páginas web deberías de tener identificado la  mejor estructura para mostrar contenido, las áreas de mayor visualización por el cliente, la comunicación, el diseño y la colaboración de esta manera podrás generar valor real para el cliente.

• Prototipos: Para el caso del software deberías crear maquetas, prototipos, todo esto  en base a estándares y buenas prácticas con respecto al producto y/o servicio a crear, así facilitaras la toma de requisitos del cliente y eliminarás o mitigaras los riesgos asociados a esta actividad que es una de las mas importantes.
• Peter Senge en la quinta disciplina recomienda  la creación de micromundos(pilotos) donde se puede experimentar y probar las funcionalidades hasta que se tenga un buen entendimiento de lo que se requiere para satisfacer las necesidades del cliente.
• Estandarización: Trata de eliminar la variabilidad con respecto a tu producto maneja una base sólida sobre la cual basas la ventaja competitiva de tu producto, así no dependerás de gente muy experimentada ni especializada y tendrás mayores probabilidades de éxito con respecto al producto generado en el proceso.
• Documentación: La gestión del conocimiento trata de traducir el conocimiento tácito a conocimiento explicito, esto te dará mayor confianza y te permitirá capitalizar el conocimiento de tu personal como principal activo de tu organización.
• Mejora Continua: Los problemas o las quejas del cliente son oportunidades de mejora, analiza la causa raíz de los problemas, planifica acciones para eliminar las causa, ejecútalas, evalúa los resultados, de obtener resultados exitosos implementa  las nuevas práctica, políticas, etc. o de lo contrario inicia nuevamente el proceso de mejora.
• Innovación: Crea una cultura de innovación dentro de tu organización.

Finalmente como conclusión la idea es llevar el mejor producto del mundo  al cliente, esto requiere mucho trabajo al inicio, pero realmente vale la pena.

¿Para qué Documentar?

Durante una de mis experiencias de estandarización de procesos, me encontré con un área bastante reacia al cambio(el jefe), la cual argumentaba que su proceso era bastante ágil y no necesitaba documentar sus actividades ya que las mismas se guiaban con un checklist, en donde de manera rápida el empleado sabía que tareas realizar. Su argumento me pareció bastante válido en un escenario de un proceso bastante maduro y con personal con un alto nivel de conocimiento y experiencia en la ejecución de las actividades que dicho sea no era el caso, así que le pedí que me mostrara su checklist y me explicará a detalle cada actividad que figuraba en el checklist, su explicación con respecto a las tareas de cada actividad me pareció bastante tenue, se  quedaba en el ¿Qué hacer? pero no llegaba a detallar de forma clara el ¿cómo? ni  el ¿Por qué?, no sabía sustentar el valor que cada actividad generaba en el proceso y no tenía claro cómo actuar ante situaciones que requerían tomar alguna decisión. Luego programe entrevistas con  cada trabajador y le pedí a cada uno  que me explicara cada actividad del proceso,  para mi sorpresa cada trabajador tenía una interpretación diferente de la actividad y cada uno la ejecutaba a su modo (formatos personalizados (colores,letra,etc), diferentes canales de comunicación, diferentes habilidades técnicas, retrabajos, reprocesos, cuellos de botella por cada trabajador, etc).  Luego de hacer el levantamiento de información en el Gemba (área de trabajo) y la poca predisposición para la estandarización del proceso por parte de la jefatura. Tuve que informar a la alta  dirección del estado del proceso del área en mención y generar una  crisis( "eliminar la situación de éxito"  ) uno de los principales puntos de  la exposición  para generar la crisis fue  el conocimiento como activo más importante de la organización y la nula consideración que se tenía del mismo en el área. Quisiera compartir algunas buenas prácticas al momento de  participar en proyectos de estandarización de procesos y para documentar procedimientos.

• Capacitar al equipo del proyecto involucrado en Mejora de Procesos: el trabajo se vuelve complicado si las personas no conocen los conceptos y las actividades asociados a la mejora de procesos.

• Documentar la situación inicial del proceso e incluir  evidencias de lo que se encontró al inicio, esto te servirá para dar mayor credibilidad  a todas las mejoras que se han logrado con la estandarización.


• Involucrar en el diseño del proceso a los principales actores  del proceso (dueño y personal que va a ejecutar las actividades), esto se llama involucrar de manera activa al equipo del proyecto y lograr el compromiso.


• Cambio, si encuentras resistencia al cambio, pueden ser por muchos factores uno de ellos es el miedo del personal, genera confianza en el equipo de trabajo antes de iniciar tus labores de campo.


• Define métricas e indicadores simples, muchas veces estas métricas definidas al inicio cambian durante el ciclo de mejora continua del proceso.