miércoles, 19 de noviembre de 2014

¿Por qué no uso Gantt para seguimiento y control de mis proyectos?

En variadas reuniones y eventos en los que conversamos sobre la problemática del desarrollo de software en el Perú, siempre observo el rostro de desconcierto de Jefes y Gerentes de Proyectos al escuchar esa afirmación. La alta dependencia de un diagrama Gantt y quizás el día a día de su intenso trabajo, probablemente no les permite explorar otras herramientas de seguimiento y control de sus proyectos que puedan ser más efectivas para este fin.
El diagrama de Gantt fue desarrollado por Henry Gantt en 1910 mientras enfocaba su trabajo en la construcción de Buques durante la Primera Guerra Mundial. Durante sus más de 100 años de existencia se han agregado pocas características a su versión original. Lo que sí es indudable es el uso masivo entre las personas que tienen que ver con la Gestión de Proyectos, convirtiéndolo casi en un estándar de facto para el seguimiento de las actividades del Proyecto.
El desarrollo de software tradicional y el sistema Push
Tradicionalmente, el desarrollo de software se ha basado en un modelo “Push” de flujo de trabajo en donde las tareas son planificadas y programadas. Esto es, tan pronto como cualquier tipo de tarea es identificada, tal como “Crear Prototipo” o “Solucionar el Bug”, es asignado a un individuo. Un Jefe de Proyectos y el equipo viven y mueren con el Gantt.
Hay algunos inconvenientes con los que uno se encuentra en el día a día trabajando con un Gantt como por ejemplo presentar un diagrama de Gantt extenso en un documento, prácticamente no se llega a notar el contenido perdiendo su valor como herramienta visual. Otra cosa que sucede frecuentemente es que no refleja la realidad del proyecto. En un proyecto de software los cambios son constantes, mantener actualizado el diagrama Gantt se vuelve tan tedioso que termina siendo obsoleto continuamente.
Un sistema “Push” también introduce conflictos. Se toma el Gantt como un contrato que fija los plazos y utilización de recursos lo cuales hay que cumplir a como dé lugar. El objetivo muchas veces no llega a ser la entrega de valor a través de un producto de software de calidad, sino el cumplimiento del  cronograma Gantt. El resultado creo que todos lo conocemos: pocas veces se cumple lo establecido y el tiempo de ciclo termina siendo más largo.
Kanban y el Sistema Pull
La alternativa al Sistema Push es el Sistema Pull. En un Sistema Pull el trabajo no es planificado ni programado, el trabajo ingresa al flujo en base a la disponibilidad. Kanban es un ejemplo de un sistema Pull. Este se basa en un sistema de producción que dispara trabajo solo cuando existe capacidad para procesarlo.
Kanban permite la visualización de todo el proceso de desarrollo, mediante un tablero físico, generalmente, públicamente asequible. Esto permite, entre otras cosas, entender mejor el proceso de trabajo actual, conocer los problemas que puedan surgir y tomar decisiones, mejorar la comunicación entre todos los interesados/participantes del proyecto y hacer los futuros procesos más predecibles. Un tablero Kanban, se divide en columnas las cuales representan un proceso de trabajo.
Otra característica de Kanban es el uso de un WIP (Work in Progress o trabajo en curso) que consiste en acordar anticipadamente la cantidad de ítems que pueden abordarse por cada proceso (es decir, por columnas del tablero). El principal objetivo de establecer estos límites es el de detectar cuellos de botella los cuales representan el estancamiento de un proceso determinado que llevan a alargar los plazos de entrega.
¿Porque no uso Gantt para el seguimiento y control de mis proyectos?
Regresando a la afirmación original, en mis equipos de trabajo hemos dejado de usar diagramas de Gantt desde hace un tiempo y solo se generan cuando hay que mostrar hitos del proyecto (sprints) u otra información relevante a los interesados del proyecto.
Para el seguimiento y control del avance de requerimientos y actividades utilizamos herramientas como “Team Foundation Server” que incorpora un tablero Kanban para el seguimiento del proceso de desarrollo. Sin embargo, hay que resaltar que para que esto sea efectivo se planifican “ciclos cortos” de entrega de entre dos a tres semanas de duración, al término del cual se entrega un incremento o avance del producto de software.
Kanban Team Foundation Server Peru
El uso de prácticas agiles, así como herramientas tales como el tablero Kanban, nos ha permitido tener una mejor visibilidad y efectividad en el manejo de los ciclos de entrega del producto de software en nuestros proyectos. ¿Qué inconvenientes encuentras tú con los diagramas de Gantt ?
Fuente : http://agiland.pe/blog/por-que-no-uso-gantt-para-el-seguimiento-y-control-de-mis-proyectos/ 

martes, 23 de septiembre de 2014

ASP.NET Web Forms o MVC ¿ Cual encaja en nuestra necesidad ?

Este pequeño y humilde artículo tiene el propósito darles a conocer un poco más las tecnologías de desarrollo web que proporciona Microsoft. Si no lo hiciste todavía, te recomiendo que leas Entendiendo el ecosistema de desarrollo web de Microsoft.
Hoy voy a escribir sobre la diferencia entre ASP.NET Web Forms y ASP.NET MVC, que a muchos nos debe pasar, y no sabemos que herramienta elegir para nuestro proyecto, obviamente existen muchos criterios, reglas, escenarios, etc en el cual debemos elegir el mas indicado, con un objetivo que desarrollemos y entreguemos un producto de calidad, un producto que sea compatible, escalable, es lo que debemos entregarle a nuestro cliente y/o usuarios.

Bueno espesemos a explicar un poco,  MVC de ASP.NET no viene a sustituir las aplicaciones de WebForm sino completarlas para aportar una serie de ventajas, por ejemplo:
  • Separar aun más la representación de la lógica de negocio
  • Facilitar las técnicas de desarrollo test driven development
  • Facilitar las técnicas de Inversion of Control (IoC)
  • Mayor grado de parametrizacion/instrumentación de la solución
  • Permite evitar el modelo Postaback del ASP.NET
Como resultado general las mejoras descritas aportan:
  • mayor productividad,
  • agilidad en la respuesta al cambio de requerimientos,
  • fiabilidad y solidez en las aplicaciones.

Trasfondo

Hace mucho tiempo, con la ayuda de tecnologías como Visual Basic y Visual C++, Microsoft habilitó la creación de interfaces gráficas de forma rápida, con lo cual, los programadores podían enfocarse más en el negocio que en el diseño de las interfaces de usuario.
Esas tecnologías eran limitadas a las aplicaciones de escritorio, en el aspecto web, Microsoft sólo ofrecía ASP.
Cuando hablamos de web y escritorio, hay que considerar dos cosas:
  1. Cómo se administra el estado?
  2. Cómo funciona el pedido/respuesta?
Las aplicaciones web funcionan sobre el protocolo HTTP, el cual es un protocolo sin estado. A diferencia del escritorio, no hay variables que se preserven y no hay una programación completa manejada por eventos. Como en el escritorio, la web espera la entrada de un usuario, pero cada interacción actúa como un pedido nuevo al servidor.
En base a este escenario, Microsoft presentó ASP.NET Web Forms, manteniendo el desarrollo de aplicaciones rápido y la facilidad de aprendizaje.

¿Qué es ASP.NET?

ASP.NET es un framework de aplicaciones web creado por Microsoft, construido sobre el CLR (Common Language Runtime). Permite crear aplicaciones web dinámicas utilizando lenguajes como C# o Visual Basic.NET.

¿Qué son los Web Forms?

Los Web Forms aparecieron para solucionar los problemas que tenía la tecnología ASP clásica. Se creó un nuevo nivel de abstracción sobre la web sin estado, simulando el modelo con estado de los Windows Forms. Se introdujeron conceptos como postback (un envío desde la misma página) y ViewState (un objeto que almacena los valores de los controles durante los postbacks) y se redujo la cantidad de código a escribir.

Ventajas

  • Los Web Forms contienen controles de servidor ricos: ASP.NET detecta el navegador del usuario y genera HTML y JavaScript apropiado para él. Además, controles como el GridView o el ListView, contienen funcionalidad para enlazar datos.
  • ViewState: Normalmente los controles no retienen los valores entre los pedidos al servidor, pero en los Web Forms esto se logra guardando el último estado conocido en un campo oculto denominado ViewState.
  • Programación manejada por eventos: Microsoft introdujo la programación manejada por eventos, con la cual, los desarrolladores no tenían que apoyarse sobre los métodos POST y GET para las interacciones con el servidor. Haciendo doble click sobre un control, se genera un bloque de código que manejará el evento de dicho control en el servidor; sin que el desarrollador tenga que saber qué es lo que ocurre.
  • Desarrollo de aplicaciones rápido: Con los controles de servidor + el modelo manejado por eventos + ViewState, el desarrollador queda abstraído de muchas de las complejidades, con lo cual programa más rápido.
  • Curva de aprendizaje pequeña: Es posible hacer aplicaciones con muy poco conocimiento de HTML y JavaScript.

Desventajas

  • Unit Testing: El Code Behind (archivo que contiene código a ejecutarse en el servidor) termina conteniendo muchos manejadores de eventos, lo cual hace que el unit testing automático sea una tarea imposible.
  • Performance: ViewState se convirtió en una solución para varios problemas de ASP, pero como se guarda en la misma página hace que el tamaño de la misma se incremente y se reduzca la performance general.
  • Reutilización: El código incluido en el Code Behind de un Web Form no es fácilmente reutilizable en otro.
  • Poco control sobre el HTML: Muchas veces no está muy claro cuál es el HTML que resultará de la utilización de los controles, lo cual hace complicada la integración con frameworks como jQuery.
  • SEO: No se generan URLs amigables, lo cual afecta el SEO de la página.
  • Trabajo en paralelo: Como cada Web Form está atado a su Code Behind, no es recomendable que dos desarrolladores trabajen al mismo tiempo en estos archivos.

ASP.NET 4.0

ASP.NET 4.0 introdujo varias mejoras que solucionaron varios de estos problemas.
  • ViewState: Se provee la forma de desactivar o controlar el tamaño del ViewState.
  • URL Routing: Utilizando URL Routing se pueden crear URL amigables
  • ID: Hay mejor control sobre el ID de los elementos, para mejorar la integración con frameworks de JavaScript.

¿Qué es MVC?

MVC es un patrón de arquitectura de software, no es un concepto nuevo, ni está creado por Microsoft. Por las dudas, me gustaría explicar estas palabras que acabo de utilizar:
  • Patrón: Un patrón es una solución a un problema en un contexto.
  • Patrón de arquitectura: Son patrones de diseño de software que ofrecen soluciones a problemas de arquitectura de software, tienen un nivel mayor de abstracción que los patrones de diseño. Describen los elementos y el tipo de relación que tienen junto con un conjunto de restricciones sobre cómo pueden ser usados. Expresan un esquema de organización que consta de subsistemas, sus responsabilidades e interrelaciones.
La intención detrás de MVC es la de separación de responsabilidades. Las partes que componen el modelo MVC son:
  • Modelo: Maneja los datos y es independiente de las otras partes del MVC.
  • Vista: Es la representación del modelo de datos. Puede ser una página, un archivo Excel, un pdf, etc. La vista sólo conoce al modelo.
  • Controlador: Maneja la interacción del usuario y la lógica de entrada. Es el encargado de obtener el modelo y entregárselo a la vista.
ASP.NET WebForms vs ASP.NET MVC

¿Qué es ASP.NET MVC?

ASP.NET MVC es un nuevo framework para aplicaciones web creado por Microsoft, diseñado bajo la idea de la separación de responsabilidades y la posibilidad de implementar el testing. No posee ni ViewState, ni controles de servidor.

Ventajas

  • Arquitectura de proyecto: Al estar fuertemente implementada la separación de responsabilidades, también tenemos una arquitectura del proyecto ordenada.
  • Desarrollo manejado por tests: Los controles son clases separadas, por lo cual, es posible hacer test automáticos.
  • Reutilización: Los controles no están atados a una vista, por lo cual pueden ser reutilizados.
  • Performance: Las páginas son mucho más livianas comparadas con los Web Forms.
  • Control total del HTML: Como no existen los controles de servidor, la única opción es utilizar los controles HTML, por lo que sabemos cómo se terminará renderizando la página. La integración con librerías JavaScript es realmente simple.
  • Soporte para trabajo en paralelo: Al estar todo realmente separado, es posible que un desarrollador esté trabajando en una vista, mientras otro esté en el controlador y un tercero esté en el modelo, sin que interfieran entre ellos.
  • SEO, URL Routing y REST: Las características de routing permiten utilizar interfaces REST.
  • Extensión: Soporte para múltiples motores de vistas como aspx, razor, etc.
  • Características preexistentes de ASP.NET: Como está construido sobre el framework ASP.NET, provee características como autenticación, caching, session, etc.

Desventajas

La principal desventaja de ASP.NET MVC es que presenta una curva de aprendizaje mucho más importante, por lo cual, puede ser muy difícil para los desarrolladores que recién están empezando.

¿Cuál es mejor?

Ambas tecnologías pueden ser la mejor, todo depende de los requerimientos, el problema dado y el conocimiento que tenga el equipo de desarrollo. Lo que es importante saber, es que una tecnología no suplanta a la otra.
Existen unos factores que pueden hacernos decidir por una o por otra:
  • Quiero desarrollar la aplicación de forma rápida: ASP.NET Web Forms
  • Quiero poder hacer Unit Testing: ASP.NET MVC
  • Mi equipo tiene conocimiento de Windows Forms: Van a aprender mucho más rápido a utilizar Web Forms que MVC.
  • Mi equipo no tiene conocimientos de las tecnologías Microsoft: Si ya utilizaban JSP, Ruby On Rails, etc. MVC es la elección.
  • El uso de JavaScript va a ser importante: Si se va a utilizar mucho JavaScript, MVC es más adecuado.
  • No tengo mucho conocimiento de tecnologías web: ASP.NET Web Forms

Resumen

Hoy profundizamos un poco más en las tecnologías Microsoft, para poder discernir cuál es la que mejor se adapta (o adaptará) a nuestras necesidades. 

viernes, 15 de agosto de 2014

¿Qué es entiendes de Procesos?

Definición de proceso..
 
 
Es habitual hablar de proceso, de secuencia de actividades, de que involucran inputs y outputs y todo ese conjunto de conceptos conocidos por muchos. Para el analista, la identificación de sus elementos es más útil que el concepto en sí. Aquí presentaré una definición básica de lo que es un proceso y de los elementos que lo componen, a la luz de la óptica con la que se viene trabajando en este tratado.
 
Proceso es el conjunto de actividades o tareas, mutuamente relacionadas entre sí que admite elementos de entrada durante su desarrollo ya sea al inicio o a lo largo del mismo, los cuales se administran, regulan o autorregulan bajo modelos de gestión particulares para obtener elementos de salida o resultados esperados . Las entradas al proceso pueden ser iniciales o intermedias. Asimismo, los resultados o salidas a lo largo del proceso pueden ser intermedios o finales. La presencia e interacción de los elementos que lo componen conforman un sistema de trabajo, al cual puede denominarse “Sistema de gestión del proceso”. Gráficamente se puede entender lo anterior así:
 
Dentro del proceso, hay un tratamiento de entradas de diversos tipos en cada actividad o tarea agregándoles valor, de tal manera que se cumplan los requerimientos o necesidades del cliente interno o externo.

Cabe indicar que, el propósito del diseño de un proceso de servicio es que se contribuya en cada una de sus actividades con una cuota de valor (léase Cadena de Valor de Porter) y que de esta cadena se genere finalmente una contribución de valor mayor que el experto denomina "margen". En este sentido, los procesos deben agregar valor entre etapa y etapa, subproceso o subproceso o entre operaciones. Estamos hablando de servicios y también de procesos de manufactura, bajo una concepción de gestión positiva tal y como debe hecerlo un gerente, administrador o alguien encargado de manejar procesos.
No obstante a ello, existen procesos en los cuales, cada etapa resta valor. ¿Cómo es eso?. Veamos.
 
Formulemos la pregunta: ¿existen procesos que no agregan valor final al resultado?. En principio no todo proceso tiene porque agregar valor, citemos por ejemplo a los procesos degenerativos en el cuerpo humano, enfermedades como Alzeimer, Espondiloartropatías, esclerosis múltiple, cáncer, etc.
Estos son procesos autoregulados (seguramente por alguna condición seronegativa, es decir, que el mismo organismo lo genera y no puede controlar teniendo que recurrir a ayuda externa). Ciertamente, estos son procesos que escapan al àmbito empresarial y de gestión de servicios, pero clarifica 100% lo que se quiere dar a entender: una empresa puede tener alguna enfermedad, es decir, tener procesos degenerativos.
En este punto quiero ser claro en lo siguiente: si bien existen procesos que no agregan valor como los que mencioné antes, es cierto que este "fenómeno" o esta "enfermedad" puede darse también en una organización, una empresa y también en un proceso de servicio. ¿Cómo?. Veamos.
Cuando se habla de cultura organizacional se toma en cuenta entre muchos elementos a los valores, costumbres o hábitos de sus trabajadores. Buenos hábitos contribuyen con la creación de valor en las actividades de la empresa y por ende, en la creación de valor de todos sus procesos. Pero, si el personal contribuye con hábitos malos como por ejemplo, llegar temprano, marcar tarjeta y salir media hora a tomar desayuno por ahí, asistir a las reuniones sólo para criticar y no aportar, hablar mal de los compañeros, ser burlón con algunas personas, ser soberbios, no comunicar a sus empleados las decisiones de la semana o los temas prioritarios en agenda, no saludar a los compañeros o no acordarse de las necesidades de su personal, entre otras cosas más (propias de las relacionse humanas), constituyen actos y conductas que NO AGREGAN VALOR, a pesar que van construyendo y moldeando procesos de cultura organizacional en la empresa: a la larga, el comportamiento interno en tu organización estará compuesto por procesos de relaciones humanas que no posean valor, más bien, degradan o degeneran a la cultura deseada afectando nocivamente al desempeño del recurso humano (falta de motivación, descontento, falta de condiciones adecuadas interpersonales en cantidad mínima o suficiente, sentimientos de rivalidad, celos profesionales, quejas manifiestas o conflictos declarados, muestras de indiferencia, mal trato y humillación evidentes, entre otros).
 
NI que decir si estos procesos internos acaban por ser externos y tengan que llegar al cliente o usuario final. Imaginemos el trato y conducta del personal de servicio hacia los clientes bajo las condiciones de los ejemplos citados.
 
Otro caso es cuando se planifica mal y como resultado de ello no se tiene cómo medir los avances, se generan reuniones para "reprogramar" o "reformular" los planes, las tareas, y en peores casos hasta los objetivos. Se generan discusiones bizantinas que buscan un consenso sin tener un criterio común previo, consumiéndose hasta horas de dar vuelta y vuelta a un mismo tema.
 
En este tipo de reuniones ¿hubo valor?. Si miramos comprativamente entre el antes y el después, cualquiera de los participantes en dichas reuniones dirá que sí se está agregando valor al proceso de planificación (claro, sí forma parte del mismo). Pero si miramos con ojos de gerente, la cosa cambia. Porque cuando existen procesos estratégicos como los de planificación, no podemos darnos el lujo de estar como el cangrejo (hacia adelante y hacia atrás), menos aún cuando el tiempo es recurso irrecuperable y peor aún si se trata de servicios. Si el gerente o la alta dirección no comprende este hecho y supone que TODO retroceso es por algo bueno, seguramente requiere que le digan que la organización o área que dirige está compuesta de procesos que están DESVALORIZANDO su gestión. Escuchando esto, tal vez podría comenzar a reflexionar.

Volviendo al tema y por ello, en el gráfico mostrado, apuntamos a procesos, subprocesos u operaciones que sólo agregen valor. Esa es nuestra meta al diseñar o rediseñar procesos de servicios como analistas o consultores.
Mencionaré algunos ejemplos de procesos guiándonos siempre de la clasificación de producto presentado en artículo del 18 de enero. Recordemos que siempre debemos partir de conocer cuál es el resultado del proceso, es nuestro objetivo a donde queremos llegar. Los resultados de un proceso pueden ser:
 
- Bienes tangibles
- Bienes intangibles
- Servicios
 
Veamos algunos ejemplo de procesos, en función a su resultado:
 
Para producir Bienes tangibles:
 
  •  Fabricación de papel
  •  Fabricación de pastas y fideos
  •  Elaboración de libros escolares
  •  Fabricación de cerveza
  •  Elaboración de leche pasteurizada
  •  Fabricación de embutidos
  • Construcción de carreteras y puentes
  • § Construcción de inmuebles
  • § Producción de energía eléctrica
  • § Producción de gas licuado
  • Para producir Bienes Intangibles:
  • § El Aprendizaje por parte de los alumnos
  • § El Aprendizaje – experiencia de parte de los padres de familia en un hogar
  • § La Adaptación de un niño adoptado en una familia
niño adoptado § La Adaptación de un empleado en un nuevo trabajo
§ La Reinserción en la sociedad de un ex convicto
§ El Enamoramiento entre dos personas de diferente sexo
jj § La Automotivación para lograr un mejor desempeño
§ El Liderazgo y acercamiento personal bajo técnicas de coaching ontológico
§ El Desarrollo y evolución de la familia
§ El Desarrollo y crecimiento de una PyME
§ La Capitalización y aprovechamiento del talento humano en una empresa
§ La Alfabetización lograda en la población de una comunidad andina
Para servicios:
- Proceso de Selección de personal
- Proceso de Enseñanza escolar a lo largo de los 10 meses
- Proceso de Enseñanza universitaria de pre grado
- Procesos de Adiestramiento y capacitación específica a personal de una empresa
- Procesos de Planificación, Organización y ejecución de procesos electorales
- Procesos de Compras y adquisiciones de bienes y servicios estatales
- Proceso de Organización de eventos
- Proceso de Distribución de energía eléctrica
- Proceso de Distribución de pastas y fideos
- Proceso de Distribución de libros escolares
- Proceso de Administración de obras de infraestructura víal terrestre (carreteras, puentes)
- Proceso de Ventas de proyectos de construcción civil
- Proceso de Asistencia Técnica para la realización de elecciones internas de una organización
- Proceso de Ventas de seguros de vida
- Proceso de Ventas de soluciones y aplicativos informáticos.
sahk § Procesos de servicios de salud
§ Procesos de Supervisión de negocios y comercialización
§ Procesos para el Transporte de valores
§ Procesos de Seguridad Integral (física, material, de intangibles)
§ Procesos de Servicios de Entretenimiento
§ Procesos de Servicio de Consultoría empresarial
Nótese una distinción importante. Cuando nos referimos a la producción de energía eléctrica, es decir, al proceso que ocurre en una central hidroeléctrica estamos hablando de un bien tangible como resultado de ese proceso (la energía eléctrica es un bien físico, es materia). Cuando nos referimos a la distribución de energía eléctrica digamos en una ciudad, estamos hablando ya de un proceso de servicio: cómo hacer llegar esa energía eléctrica a la población bajo ciertas condiciones y mediante una tarifa determinada.
Definiendo adecuadamente el resultado asociado al proceso en análisis podemos ver de manera más clara si el proceso es o no de un bien físico, no físico o si se trata de un servicio. Asimismo, para cualquiera de estos ejemplos podremos aplicar el diagrama antes mostrado. Con él se podrá identificar a cada uno de sus elementos y así proceder a un análisis efectivo.
ELEMENTOS DE UN PROCESO
En todo proceso se distingue una serie de elementos o componentes fundamentales. No hay proceso que no cuente con alguno de estos elementos. Lo que si puede ocurrir que existan procesos en los cuales sus elementos no han sido identificados correctamente.
Ø Entradas.
Ø Subprocesos, operaciones o tareas
Ø Salidas, resultados o productos
Ø Clientes (internos, externos)
Ø Sistema de monitoreo, control y evaluación
Ø Responsable del proceso
Las entradas se dividen en recursos o insumos.
Recursos:
Financieros.
Humanos.
Espacio físico (plaza e infraestructura).
Energía.
Software y aplicativos informáticos.
Equipamiento (tecnología dura).
Información (cuantitativa y cualitativa).
Conceptos, modelos de gestión, políticas, procedimientos y formas de proceder (tecnología blanda).
Especificaciones del cliente (requisitos).
Marco legal.
Servicios.
Bienes no materiales (condiciones, facilidades, seguros).
Insumos:
Materias primas.
Bienes materiales (Datos cuantitativos y cualitativos en medios transportables).
1. ENTRADAS
1.a. Recursos
Sin ellos no podría iniciarse, desarrollarse ni terminarse el proceso en su integridad. Los recursos proporcionan las facilidades para desarrollar las operaciones o tareas del proceso. Pueden ser tangibles (materiales) o intangibles (no materiales). Se les puede agrupar en los siguientes tipos:
cuadro
1.b. Insumos
Un insumo es todo bien material que va a ser procesado (ensamblado o transformado). La data sin procesar, contenida en medios magnéticos (CD, USB) o en forma electromagnética, constituyen insumos. Ejemplo: Materias primas que deban ser procesadas.Papel para las oficinas.Personas (cuando se trata de procesos de capacitación o formación);Data e información en medios transportables para ser procesada.
Las entradas, tanto recursos como insumos, pueden ser iniciales o intermedias. Serán iniciales si es que se incorporan con el inicio del proceso. Serán intermedias si es que se van incorporando durante el desarrollo del proceso.
2. SUBPROCESOS, ACTIVIDADES U OPERACIONES
Los subprocesos, actividades, operaciones o “tareas”, también son procesos de “menor jerarquía”, pues, de manera individual o colectiva, también hacen uso de los recursos transformándolos o agregándoles valor dentro del sistema de gestión particular.
La realización de un subproceso, actividad u operación constituye servicio en desarrollo, es decir, una acción que está produciéndose y siendo “consumida” de manera simultánea. Al término de ello, se tendrá a un servicio consumado asociado a un bien tangible o a un bien intangible.
Todo subproceso, actividad u operación como parte del proceso delimitado para nuestro análisis, atenderá a un cliente interno a excepción de la última operación a lo largo de la cadena del proceso pues atenderá al cliente final del proceso en si.
Estos subprocesos, actividades u operaciones pueden aparecer y trabajar individualmente sirviendo al proceso en algún punto del mismo (recordemos un Diagrama de Operaciones de Proceso DOP para un material).
3. SALIDAS, RESULTADOS O PRODUCTOS
Las salidas (outputs), resultados o productos, que genera el proceso, pueden constituir entradas de un siguiente proceso cuando el cliente es interno, o constituir el producto final (bien o servicio) cuando el cliente es externo. En resumen, y como se indicó anteriormente, los resultados o productos pueden ser bienes o servicios:
§ Servicios consumados
§ Bienes materiales (bienes tangibles)
§ Bienes no materiales (bienes intangibles)
Las salidas también pueden ser intermedias o finales. Serán intermedias si es que corresponden a productos resultantes durante el desarrollo del producto, y finales si es que corresponden a productos resultantes al final del proceso.
4. CLIENTES
Los resultados o salidas de un proceso se dirigen a las personas, áreas o procesos Clientes o Usuarios. El término cliente denota a quien se atiende “una o más de una vez”. El término usuario denota a quien “usa” o “se beneficia” del servicio o bien que resulta del proceso). Ambos términos pueden ser considerado como lo mismo si es que cumplen el mismo papel (Un análisis en mayor profundidad es el presentado en el articulo anterior en el presente blog).
Dependiendo de su aparición durante el proceso y de cómo se ha definido su alcance, los clientes o usuarios pueden ser internos o externos. Son internos si forman parte del sistema de gestión del proceso y externos si no forman parte de ese sistema.
5. SISTEMA DE MONITOREO, CONTROL Y EVALUACIÓN
Las actividades, operaciones o tareas dentro de todo proceso, requieren contar con criterios, instrucciones e instrumentos para:
Detectar probables irregularidades y medir el desempeño del proceso en sus puntos críticos.
Controlar, corregir o suprimir las irregularidades.
Evaluar el desarrollo del proceso y sus implicancias.
El monitoreo permite “estar atento” al desarrollo de nuestro proceso, de nuestro producto o servicio y de saber cómo está percibiéndolo el cliente. Para ello, necesitaremos instrumentos de medición que permitan “medir” estos avances, desarrollos o evoluciones.
No sólo basta con monitorear, hay que tomar las medidas correctivas. Aquí aparece el control es decir, “corregir” lo que está ya en marcha. Esto significa “enderezar” lo que vemos que se está torciendo. ¿Cuánto enderezar?, esto lo dirá la medición que obtengamos en la etapa anterior correspondiente al sistema de monitoreo.
Luego de monitorear (estar al tanto y medir), controlar (ajustar, corregir) debemos evaluar, es decir, extraer conclusiones relevantes sobre el impacto, el resultado, el desarrollo y hasta del diseño de nuestro servicio. Por lo general, las evaluaciones de proceso de servicio se hacen luego de terminado los calendarios de cumplimiento de planes operativos estableciéndose periodos para tal fin (trimestrales, semestrales, anuales), pero siempre coinciden por lo general con el termino de algún periodo de sustentación.
6. RESPONSABLES
Los responsables de la ejecución del proceso, son las áreas o personas involucradas en el cumplimiento de cada una de las actividades u operaciones de acuerdo a los objetivos, funciones y procedimientos acordados para tal fin.
Si quiere tener mayor conocimiento de procesos, visite mi otro blog:
pulse AQUI
Notas:
(1): La palabra proceso viene del latín processus, que significa avance y progreso.
(2): Se puede hablar de resultados esperados cuando estos son predecibles. Hay hechos no predecibles e incontrolables que afectan a nuestros procesos (cambios en el marco legal o en el entorno macroeconómico o social de un proyecto). La gestión eficaz en la actualidad debe prever estos hechos con un grado de seguridad que minimice el riesgo implícito.

martes, 12 de agosto de 2014

Identificacion De Procesos De Negocio

Para poder identificar correctamente cuáles son los requerimientos de un proyecto, es necesario conocer las características del negocio en el que se inserta. En el proceso de desarrollo del software la modelación del negocio adquiere mayor importancia por el impacto que tiene la utilización de las nuevas tecnologías. Este trabajo describe algunas reglas que ayudan a identificar procesos de negocio.

El punto de partida es la propuesta de RUP y se incluyen recomendaciones

y ejemplos derivados de su aplicación en diferentes entornos.

INTRODUCCIÓN

Un proceso de desarrollo de software es ..." el conjunto de actividades necesarias para transformar los requerimientos del usuario en un sistema informático".
1 Un proceso define quién está haciendo qué, cuándo y cómo alcanzar un determinado objetivo.
Obtener los requisitos funcionales que se derivarán en un producto de software nuevo o la
mejora de uno existente, requiere de un estudio de la organización. Este estudio está contemplado dentro del flujo de trabajo de Modelamiento del negocio, desarrollándose la mayoría de sus actividades dentro de la fase de concepción (o inicio).

En este trabajo se toman como referencia los libros clásicos que describen RUP, 1-3 aunque es importante señalar que en esta literatura esta es una de las áreas de conocimiento cuya descripción no es suficiente para la modelación. La identificación de los procesos de negocio es una actividad que resulta difícil de ejecutar por que los criterios aquí incluidos pueden servir de referencia.

Los 
resultados que se presentan parten del análisis de dos años de experiencia en la enseñanza de esta temática.

MODELACIÓN DEL NEGOCIO

Un sistema, por pequeño que sea, generalmente es complicado. Por eso se necesita dividirlo en piezas si se pretende comprenderlo y gestionar su complejidad.

Esas piezas se pueden representar 
a través de modelos que permitan abstraer sus características esenciales. De ahí, que en el campo84 Industrial del software también resulte útil la creación de modelos que organicen y presenten los detalles importantes de problemas reales que se vinculan con el sistema informático a construir.

Estos modelos deben cumplir una serie de propiedades, entre ellas la de ser coherentes y relacionados. Uno de los modelos útiles previo al desarrollo de un software es el modelo del

negocio.

PROCESOS DE NEGOCIO

El modelo del negocio describe el negocio en términos de casos de usos del negocio, que corresponde a lo que generalmente se le llama procesos.

El modelo de casos de uso del negocio es un modelo que describe los procesos de un negocio (casos de uso del negocio) y su interacción con elementos externos (actores),  tales como socios y clientes, es decir, describe las funciones que el negocio pretende realizar y su objetivo básico es describir cómo el negocio es utilizado por sus clientes y socios. 

Implica la determinación de 
los actores y casos de uso del negocio. Con esta actividad se
pretende: Identificar los procesos en el negocio, definir las fronteras del negocio que van a modelarse, Definir quién y qué interacturán con el negocio y crear diagramas del modelo de

casos de uso del negocio.

IDENTIFICACIÓN DE PROCESOS DE NEGOCIO

Para identificar los procesos de negocio es muy importante tener en cuenta que deben generar un valor para el negocio o mitigar los costos del negocio.

1. Clasificación de procesos de negocio.

Para encontrar casos de uso del negocio se pueden clasificar los procesos de negocio en tres categorías:

Núcleo: Considere qué valor reciben los actores del negocio
primarios y más importantes: los clientes. Busque los procesos
del negocio respondiendo a la pregunta: ¿cuáles son los servicios
básicos que un cliente recibe del negocio?

Soporte: Contiene las actividades que no benefician al cliente
directamente. Para identificarlos se pueden buscar actividades
como las siguientes: desarrollo y mantenimiento de personal, de
las tecnologías de información y de la oficina, seguridad y
actividades legales.

Gerencial: Estos procesos se encuentran bucando los
procesos que tienen que ver con el manejo del negocio en su
coonjunto. Normalmente se relacionan con el actor propietario.
Busque actividades como las siguientes. Desarrollar y
poporcionar información sobre el negocio a los dueños e
inversionistas, preparar las metas del presupuesto a largo plazo,

etcétera.

2. Identificación de funciones

Otra manera de encontrar los casos de uso del negocio es que los expertos del dominio describan cada actividad en el negocio existente, y entonces se agrupan estas actividades en procesos de negocio.