Propuesta de innovación VehiAlpes

Para esta iteración, la propuesta está encaminada hacia las dos fuerzas de negocio: Venta (v) y Postventa (p). Para cada una  se propone una opción innovadora, con base en una perspectiva de poder, en la cual VehiAlpes asume el control de la información de clientes, ofreciendo beneficios a sus socios.

Para venta se propone cotización y venta a través de móvil, y para postventa, un portal corporativo CRM ERP, inspirado en el modelo del portal de Audi Colombia, para la propuesta de mecánica prepagada. Los esfuerzos para la implementación y entrega de la solución se encmainarán principalmente en esta alternativa.

En la entrada después de esta, se modelan algunos procesos usando BPMN.

Procesos Vehialpes

Registro de clientes (Pagina web)

Consulta de clientes

Garantía de clientes

Comentarios en la implementación de proyectos BPM.

El BPM como disciplina de administración ofrece un medio para alcanzar los objetivos estratégicos bajo una visión centrada en los procesos. Al igual que otras disciplinas como la reingeniería de procesos (BPR), la administración de la calidad total (TQM) y Six-Sigma, que tienen un común el mismo propósito, BPM no es el santo grial, pues al igual que las anteriores su implementación en las organizaciones es un problema difícil.

En principio BPM requiere de procesos funcionales, que puedan ser optimizados. En este sentido BPM potencia la eficiencia solo si ya hay eficacia. Lo anterior representa un aspecto primario a la hora de evaluar la implementación de un proyecto BPM.

Cuando se tiene alguna certeza de la eficacia de los procesos, el siguiente aspecto se deriva de la pregunta ¿Por dónde empezar? Una causa frecuente de fracasos en las iniciativas BPM, se deriva de no contar con claridad en este punto. Es común sub-dimensionar o sobre-dimensionar el alcance de los proyectos BPM, lo que deriva a percibir un valor no correlacionado con el esfuerzo invertido y el incumplimiento de los objetivos. En este sentido establecer los objetivos de forma clara y realizable dado un presupuesto de recursos es de vital importancia.

Otro aspecto clave gira alrededor de la gente. La administración del cambio es una parte integral del BPM. La razón está en que son las personas las que finalmente implementan e interactúan con los procesos. Muchos problemas a la hora de aplicar BPM sobre los procesos deriva de la resistencia de la gente al cambio; no importa que tan bien diseñada y alineada es la estrategia del proyecto BPM, si la gente se opone el proyecto finalizará bajo tierra.

Jeston y Nelis, en observación de la dificultad y complejidad de BPM, proponen un marco (framework) metodológico para la adopción del BPM como disciplina organizacional. Este marco consta de diez fases: Estrategia Organizacional, Arquitectura de procesos, despegue, entendimiento, innovación, personas, desarrollo, implementación, realización de valor y desempeño sostenible. Las anteriores dan en general un tratamiento iterativo a los proyectos BPM, buscando su consolidación en la organización hasta hacer del proceso parte de la rutina organizacional y enfatizando en el mejoramiento continúo como capacidad objetivo.

En mi opinión, el marco propuesto por Jeston y Nelis, integra la administración del cambio como una parte integral del BPM, pero debería abordarse con mayor profundidad, pues no ofrece una metodología más detallada para construir estrategias en este sentido. Como bien lo indican los autores, la administración del cambio es un proceso transversal a las fases de marco y cuya misión es permitir el avance, en particular en la fase de implementación, en la cual el proceso representa el mayor impacto. Así mismo puntualizan en la importancia de involucrar a los stakeholders que son impactados por el proyecto.

El involucrar a los stakeholders y empoderar a las personas en la organización son estrategias generales claves en la administración del cambio. Aunque es fácil decir que esto es lo que hay que hacer, en mi experiencia lograr estos puntos es increíblemente difícil y creo que ahí esta una de las debilidades del marco, pues no explica cómo abordar estos problemas. Creo que en este sentido es imperativo entender las posiciones de los stakeholders y las personas en la organización y estimar que implica para estos la realización del proyecto.

El cambio implica desbalances entre los aportes y las retribuciones que espera cada stakeholder. Ejemplos en los cuales las personas en la organización no sentirán motivación para ayudar al cambio son la inserción de nuevas responsabilidades, el incrementar su exposición al riesgo o simplemente quedar en una posición que a su criterio es desfavorable frente a otros en su mismo nivel. Creo que en un proyecto BPM se debe integrar este tipo de análisis e incluir la negociación como una fase adicional anterior al despegue del proyecto. Lo anterior esta dado por la necesidad de definir y asegurar compensaciones adecuadas y consensuadas frente al impacto derivado del cambio y así lograr la aceptación y participación proactiva (ponerse la camiseta) de los involucrados, mitigando enormemente los riesgos.

BPMN Method & Style

Para aprender BPMN en detalle pueden existir muchas formas distintas de lograrlo. Pagar cursos, tomar cursos en la web, comprar libros, buscar manuales, etc. Lo valioso del aporte que se hace en esta lectura es como tomar en cuenta la práctica de alguien quien ya ha sufrido con la implementación y como solucionar y dar un mejor enfoque a esos problemas con los que se puede uno enfrentar día a día.

Existe un problema grande que se refleja en la perdida de semántica entre un proceso en BPMN y su implementación en un lenguaje de orquestación de procesos como BPEL. Se supone que esto es uno de los problemas que se pretende resolver en la versión 2.0 de la especificación. Personalmente no he tenido oportunidad de verlo en acción pero al menos la promesa de valor es bastante interesante. Existían problemas en la traducción entre un proceso escrito en BPMN y su contraparte en BPEL pero era aún mas fuerte el problema de hacer la conversión a la inversa, en otras palabras, era casi imposible.

En BPMN 2.0 es posible ejecutar el proceso sin necesidad de hacer una conversión a BPEL, esto lo he visto personalmente a modo de demo en IBM BPM 7.5 que recoge lo mejor del mundo de WebSphere Process Server y WebSphere Lombardi.

BPM para todos

-Buenas, deseo aplicar al cargo de "Business Developer" -¿Tiene 5 años de experiencia en "foundation" para TI en arquitecturas de procesos? -No, no tengo. -¿Qué experiencia tiene? -5 años de Java, patrones de diseño, Test Driven, Web Services. -Gracias, después lo llamamos.

 Igual, todos somos administradores, todos somos empresarios, manejamos una empresa, aunque sea un proyecto de vida, unas aspiraciones, cosas que queremos conseguir, es empresa, organización, objetivos, procesos. Pero no todos somos administradores por profesión, o por vocación, no todos estudiamos administración, o hemos hecho los cursos de economía, gestión, etc, o no tenemos la visión "visionaria", a futuro, de negocio, de oportunidades, o no nos expresamos en el "jargon" de administración, en términos de organización, objetivos, procesos.

 ¿Cuánto hay que adentrarse en el mudo de la administración? ¿Saber BPM puede ayudar? ¿También saber BPMN? Desde el punto de vista de estudio, y personal, hasta el maestro en ciencias de computación, e ingeniería de información en la organización, con experiencia en negocio, empresa, más que saber BPM, requiere un recorrido en administración, en hacer negocios, hacer empresa.

 Aunque BPM, su notación, su aplicación a los negocios, implique gente del mundo de la información, todavía es muy del dominio del mundo de los negocios. La esencia, el sentido de BPM, es muy de organización, está dedicado a la organización, a su estructura, como entidad que tiene objetivos, procesos. BPM es denso, redundante, aplicado incorrectamente, por no ser comprendido juiciosamente, por adquirir la cultura "de la calle", de ser algo de tecnología, y por darse a conocer "para todos", sin bases de administración.

 En este viaje por BPM, está muy bien comenzar por desmitificarlo, como algo de tecnología. BPM no necesariamente es algo que usa tecnología. Puede aplicarse BPM sin tecnología, pero no se puede, sin sintonizar con administración, o negocios. Saber BPM puede ayudar, si se complementa con saber de administración, tener bases, expresarla. Es positivo, fabuloso, conocer BPM, expresar procesos, con un saber de negocios claro, saber a qué se refiere un "foundation", un "proceso en una organización", así como en un juego, ubicando cada cosa en su lugar, sin que todo acerca de organización, procesos, se vuelva borroso, redundante, o avasallante.

 En BPM el sentido es mejorar, hacerlo con sentido común. Pero sin disposición, o tiempo de complementarlo con saberes de administración, todavía no es comprendido correctamente, y un método muy costoso, y peligroso. Ya pasó hace mucho la era de los negocios orientados al producto, estamos en el presente de la competencia agresiva, y hay necesidades de negocios sostenibles. BPM es para administradores, y para todos, si se comprende juiciosamente.