Procesos de negocio

Una de las entregas del trabajo final es el modelo de procesos de uno de los procesos transversales  de las empresas en las que trabajamos, y pues la herramienta de modelado ya la tenemos y es BPM, pero tenemos claro qué es un proceso de negocio y cómo se construye?

En este blog quiero dar unos breves aportes que encontré y considero que nos pueden servir para que el diagrama del proceso de negocio presentado tenga la información necesaria para construir el modelo de información.

Proceso de negocio: “Un conjunto estructurado, medible de actividades diseñadas para producir un producto especificado, para un cliente o mercado específico. Implica un fuerte énfasis en CÓMO se ejecuta el trabajo dentro de la organización, en contraste con el énfasis en el QUÉ, característico de la focalización en el producto”, [Davenport 1993]

Entonces debemos tener claro que para representar nuestro modelo de negocio debemos identificar las actividades del proceso (y como consejo del profesor si una actividad no tiene activos de información no debería estar representada el modelo), los responsables y la secuencia de cómo se ejecutan las mismas en nuestra organización.

Y para qué modelamos esto?, pues conclusiones y justificaciones en internet hay muchas y después de leer varias llego a estas conclusiones:

• Representar el modelo actual me da un panorama de la eficiencia de los procesos y me permite realizar mejoras a los mismos.
• Evidenciar si hay flujos de información que afecten varias áreas me permite saber si hay brechas y como puedo mejorar esa comunicación para que la ejecución de los procesos sea efectiva.
•  Como principio de los que trabajamos en empresas certificadas en ISO 9000, mejorar los procesos para obtener calidad vista como la satisfacción del cliente.
• También representamos la trazabilidad del sistema, porque evidenciamos el modelo trasversalmente en la empresa.

Esta era una breve reseña para entender que vamos a visualizar en nuestros proyectos finales y sobre todo para que lo representado tenga coherencia y le genere valor a las empresas donde trabajamos, el tema de representación del modelo de negocio lo pueden ubicar en los blogs de los compañeros y les recomiendo una herramienta que se llama Bizagi y es muy intuitiva y sencilla de manejar así que una vez representado ese modelo a trabajar fuertemente en el modelo de información.

Una lección más

A dos clases de terminar este curso de Modelado de la información quiero compartir la experiencia de lo que ha sido cambiar el chip en cuanto al tema de aprendizaje, como lo manifesté en uno de mis primeros blogs, la mentalidad de las notas y de tener unas condiciones para entregar un trabajo eran la motivación en cada clase cuando hacia el pregrado, por eso el primer día la estrellada fue muy brava.

Sin embargo, esta última clase termine de concluir que el objetivo de los cursos en la especialización es aprovechar al máximo el aprendizaje y la experiencia antes que la nota, y la idea de hacer un modelo de lo aprendido en las diferentes asignaturas me parece una locura, pero técnicamente eso es lo que hemos estado realizando cada sesión, recibiendo información que si para nosotros ha sido interesante pues tenemos nuestros activos de información disponibles para realizar un buen modelo de información  (aunque la realidad no se pueda representar en su totalidad).

El día que el profesor indicó que debíamos modelar la empresa, yo  ya estaba preparando mi pelea para decir que cómo se le ocurría, que eso era imposible pero hoy puedo decir que tengo herramientas para realizar este proyecto, y sobre todo para entender que el objetivo no es la evaluación de la asignatura si no comprobar que las herramientas para modelar brindadas en el curso quedaron claras y que ya entendemos que es un modelo y que somos capaces de realizar proyectos de este tipo en nuestras empresas generando valor, y adicional que debemos aplicar el principio “Divide y Vencerás” porque la idea no es realizar en una iteración todo el modelo, si no trabajar un proceso en el cual cada iteración agrega algo que mejorará nuestro modelo.

Así que este cambio de mentalidad lo puedo aprovechar con el resto de asignaturas, identificando dónde puedo aplicar cada una de esas herramientas que me están brindando y sobre todo pensar que aunque la evaluación es una calificación de la materia, el objetivo es aplicar los conocimientos de manera práctica y tener estrategias que permitan replicar estos conocimientos en mi vida laboral. 

Introducción a UML

En la actualidad el activo más importante de las organizaciones es la información, y para realizar modelos de información existen herramienta que nos permite estandarizar, comprender mejor la totalidad del sistema, visualizar e identificar cómo funcionará el sistema, y el comportamiento de sus actores.

Para esto podemos utilizar el lenguaje unificado de diagrama o notación (UML) que sirve para especificar, visualizar y documentar esquemas de sistemas de software orientado a objetos. UML no es un método de desarrollo, lo que significa que no sirve para determinar qué hacer en primer lugar o cómo diseñar el sistema, sino que simplemente ayuda a visualizar el diseño y a hacerlo más accesible para otros. UML está controlado por el grupo de administración de objetos (OMG) y es el estándar de descripción de esquemas de software. 

UML se compone de muchos elementos de esquematización que representan las diferentes partes de un sistema de software. Los elementos UML se utilizan para crear diagramas, que representa alguna parte o punto de vista del sistema, se puede representar los siguientes diagramas

• Diagrama de casos de uso que muestra a los actores (otros usuarios del sistema), los casos de uso (las situaciones que se producen cuando utilizan el sistema) y sus relaciones.
• Diagrama de clases que muestra las clases y la relaciones entre ellas.
• Diagrama de secuencia muestra los objetos y sus múltiples relaciones entre ellos.
• Diagrama de colaboración que muestra objetos y sus relaciones, destacando los objetos que participan en el intercambio de mensajes.
• Diagrama de estado muestra estados, cambios de estado y eventos en un objeto o en parte del sistema.
• Diagrama de actividad que muestra actividades, así como los cambios de una a otra actividad junto con los eventos que ocurren en ciertas partes del sistema.
• Diagrama de componentes que muestra los componentes de mayor nivel de la programación
• Diagrama de implementación que muestra las instancias de los componentes y sus relaciones.
• Diagrama de relaciones de entidad que muestra los datos y las relaciones y restricciones entre ellos.

 
https://docs.kde.org/trunk4/es/kdesdk/umbrello/uml-basics.html

Los silos en la empresa

Como mencione en el blog anterior, en la empresa estamos trabajando en un proyecto de arquitectura empresarial, y uno de los beneficios que genera esta metodología es romper los silos, porque aunque las empresas tienen objetivos estratégicos y una sola misión y visión, las áreas trabajan desarticuladas y cada una apunta para lados diferentes.

Los silos son grandes contenedores cilíndricos utilizados en la agricultura para almacenar granos, y representan elementos aislados donde no hay transferencia de nada entre sí mismos. Y su analogía con las empresas responde a áreas en las que se aíslan los procesos y no se genera trasferencia de información a los demás.

En las áreas muchas veces el trabajo en equipo es excelente y trabajan eficientemente sus labores, sin embargo, cuando se requiere cooperación con las otras áreas se empiezan a presentar inconvenientes y la gente no brinda información generando reproceso o muchas veces procesos y almacenamiento de información repetidos en diferentes áreas.

El inconveniente de los silos se refleja en los flujos de información, porque para la toma de decisiones la información fluye hacia arriba y luego baja a nivel del silo donde las tareas deben ser ejecutadas gracias a la falta de comunicación entre las áreas de esta manera la organización se vuelve lenta y pierde su actividad.

Es por esto que la cultura organizacional debe cambiar y esto implica cooperar, crear sinergias y asignar recursos a los silos. El reto está en desarrollar estructuras organizativas que ayuden a superar el poder y la mentalidad de estas unidades organizativas y lograr que la estrategia tenga éxito, ya dimos un paso adoptando la arquitectura empresarial, ahora el reto está en lograr romper esos silos claramente identificados en la organización.

Implementando Arquitectura Empresarial

En la organización que trabajo se realiza cada año la planeación estratégica y cada área debe proponer sus planes estratégicos para el año, este año adicionalmente se debía proponer un plan estratégico a 3 años y nuestra propuesta para la compañía fue implementar Arquitectura Empresarial para alinear tecnología a sus objetivos.

Pero cómo hacerlos ver la necesidad y los beneficios de usar la arquitetura empresarial? pues con una expectativa alta por su aprobación, se les indico cuál era el problema de sus sistemas de información, que podian hacer para mejorar y que beneficios tendrían si se implementaba esta metodología.

El principal problema dentro de la compañia es que cada una de sus areas es una isla, tienen sus sistemas de informacion y en algunos casos sus procesos involucran tecnología pero no aprovechan los recursos con los cuales se cuentan ej. SharepPoint, los procesos de las áreas no se articulan, es común que cada área pida desarrollos y recursos tecnológicos para completar sus procesos, y cuando se realiza el desarrollo se dan cuenta que solo cubría un pequeño proceso del área pero no se relaciona con los procedimientos de la misma, y peor aún, se repiten procesos dentro de las áreas por ende se realizan desarrollos repetidos.

Por esta razón este es un concepto clave que abordamos para evolucionar en nuestro uso de la tecnología,  "La Arquitectura Empresarial es una metodología que, basada en una visión integral de las organizaciones, permite alinear procesos, datos, aplicaciones e infraestructura tecnológica con los objetivos estratégicos del negocio o con la razón de ser de las entidades. En general, dentro de la Arquitectura Empresarial se identifican seis componentes: Estrategia, gobierno de TI, información,  sistemas de información, servicios de tecnología, uso y apropiación. Su principal objetivo es garantizar la correcta alineación  de la tecnología y los procesos de negocio en una organización, con el propósito de alcanzar el cumplimiento de sus objetivos estratégicos. " (http://www.mintic.gov.co/gestionti/615/articles-5322_Revista_pdf.pdf)

Dentro de los beneficios estan:

• Definir los planes estratégicos de la organización
• Integrar la información que se encuetra en silos
• Alinear todas las áreas de la organización
• Identificar oportunidades de integración y rehuso de aplicaciones y recursos 
• Establece trazabilizad entre procesos, datos, aplicaciones e infraestructura tecnológica.
• Optimizació de procesos. 
• Impulsa el desarrollo de TI de la organización.
• Capacidad de responder rápida y acertadamente ante retos y oportunidades que presenta el mercado, los cambios tecnológicos y cualquier otra circunstancia proyectada o inesperada

Con estos argumentos nuestro proyecto tuvo una gra acogida en la dirección, y ahora mi jefe y yo trabajamos en esta implementación, no ha sido secillo porque aunque los procedimientos y planes estratégicos de la compañia estan claros, estamos trabajando fuertemente en la integración de los procesos y en hacerle ver a las áreas los beneficios que pueden obtener al hacerlo, llevamos 4 meses en la primer fase de definicion de arquitectura de procesos y trabajamos en cumplir nuestra planeación. 

De quién es la culpa?

En mi trabajo como desarrolladora es muy común que nos hagamos enemigos de los analistas de  pruebas y escuchar al final “Eso falla porque el de pruebas no probó ese módulo”, sin embargo,esta fue una de esas semanas donde quisiera que mi mundo de hadas y duendes funcionara a las mil maravillas.

Solo cuando el software falla en producción es que recapitulamos la necesidad de garantizar la calidad de software desde diferentes aspectos porque a veces los errores que dejamos pasar a producción nos pueden salir muy costosos. No seamos trascendentales, fue un piloto del proceso con el software de producción.

Y es en estos casos donde todo lo que podía fallar, fallo. Y Justo en estos días que estaba leyendo la 25010 e identificando las características que se deberían tener en cuenta para garantizar la calidad del desarrollo que se publicó en producción. Pero para no extenderme tanto voy a dar un ejemplo de lo que se debe garantizar y cómo respondió en la prueba, no todo es malo hay cosas a favor de mi equipo de trabajo.

Adecuación Funcional: El sistema tenía desarrollados los módulos que pidió el usuario pero no estaba instalada una de las funcionalidades que permitían realizar una lectura de datos a través de la cámara, y eso era parte del piloto a realizar. Punto en contra

Eficiencia de Desempeño: Este es un sistema para trabajar con Tabletas Windows, y estamos hablando de manipular una gran cantidad de registros, por ese lado las pruebas realizadas cumplieron y en el piloto el desempeño se logró, contando que es un ambiente desconectado y de sincronización. Punto a nuestro favor.

Compatibilidad: Resulta que el desarrollo se hizo para un tipo de Tablet, no les doy detalle de las tabletas porque las compramos todas, ya no hay en el mercado, pero se agotaron por ende nos tocó utilizar otras Tablet, y ahí otra vez empezamos a padecer, la aplicación no se ejecuta de la misma manera en esas Tablet. Falló la interoperabilidad. Punto en contra

Usabilidad: Se aceptan todas las críticas, si efectivamente la usabilidad de una Tablet es terrible, es difícil utilizar las aplicaciones, los campos de selección, las listas, los botones. Y es que este fue un mundo nuevo para nosotros y aunque se trató de aportar la mejor experiencia de usuario, es complicado. Punto en contra, pero no todo es malo, nuestra capacidad de aprendizaje hacia el usuario fue buena, la aplicación es fácil de aprender y es muy intuitiva, adicional la protección contra errores de usuario es alta pues las validaciones están contempladas desde un principio, suena cruel pero es a prueba de usuarios finales. Punto a nuestro favor.

Fiabilidad: y ahí sí saco pecho, este es un proceso que se ha realizado varios años, y con las lecciones aprendidas se puede de dar un grado de madurez a esta aplicación (la empresa donde trabajo no es perversa, tenemos reconocimiento en el mercado pero hay que mejorar cositas). De igual manera suena loco, pero es un proceso que se realiza en zonas de difícil acceso, por esta razón se ha montado un esquema desconectado que replica información cuando se cuenta con Internet por ende la disponibilidad y la tolerancia a fallos esta controlada. Punto a nuestro favor.

Seguridad: Esas si las aplicamos todas, la aplicación trabaja usuarios y perfiles con contraseñas seguras e información encriptada, es confidencial. La integridad de la información se garantiza con la edición de información solo cuando se requiere. se guarda traza de todas las acciones en la BD por eso se garantiza el no repudio y la responsabilidad. Punto a nuestro favor.

Mantenibilidad: Acá si hay un 50:50 de cumplimiento de nuestra aplicación, las modificaciones en la aplicación generan un alto impacto en el desarrollo, pero mas que de instalación de movilidad, la rehusabilidad si se aplica porque si o si los componentes como el acceso a la cámara de la tablet, los reportes y algunas otras cosas se utilizan en toda la aplicación como la bimetría, son componentes fijos que solo se llaman desde donde se necesiten. La capacidad de ser probado se cumple porque al ser desconectado se garantizan ambientes de pruebas que no afectan la integridad de la información. en cuanto a la capacidad de ser modificado no se puede garantizar po que aunque es un desarrollo en capas, aun son muy dependientes los cambios y pueden afectar el correcto funcionamiento de la aplicación. punto a favor y punto en contra.

Portabilidad: Esta caracteristica la seguimos probando, porque hasta el momento hemos hecho instalaciones y solo en dos tablet no ha funcionado, sin embargo, si vamos a instalar la aplicacioes en equipos con W8.1 no habria mayor inconveniente en la ejecucion de las funcionalidades, al ser una aplicacion de escritorio se puede instalar y desinstalar sin problema, pero al ser un desarrollo especifico aún no se puede remplazar con productos similiares.

Este es el resumen de las características de calidad al desarrollo que realizamos el la empresa para el proyecto y la lección aprendida es que cuando trabajen con desarrollo hay que dejar de echarse culpas con el de pruebas (la culpa siempre es de la vaca, pero esta historia la dejaré para otro blog), tengamos una visión más amplia y como ya conocemos estas normas de SQuaRe podemos empezar a contemplar estas características; las herramientas están, calidad de datos 25012, pasos para la evaluación de calidad 25040, ahora es cuestión de aplicarlas y de preocuparnos más por la calidad de Software, créanme en mi trabajo ya empecé a cambiar la visión de mis compañeros.