Mario Saffirio

El paso del tiempo conlleva la evolución del software, esto lo vemos en la práctica con la aparición de nuevas versiones de los sistemas. El proceso de poner al día el software existente es de larga data y se denomina actualización –upgrade-. En general, las actualizaciones de software incluyen correcciones a fallas de programación –bugs- y adiciones de nuevas funciones.

Cuando nos referimos a actualizaciones de software, que soportan procesos de negocios, lo que más interesa de la actualización es la disponibilidad de nuevas funciones, que pueden dar un mejor soporte al negocio. A la actividad de incorporar las nuevas funciones del software a la operación de una empresa la denominamos Actualización Funcional, a la actividad de instalar una nueva versión de software la llamamos Actualización de Software o Actualización Técnica [1].

El objetivo de la Actualización Funcional es tomar ventaja de las nuevas funciones del software y de aprovechar la ocasión para revisar el grado de alineamiento de los procesos de negocios con la estrategia de la empresa.

¿Por qué hacer una Actualización Funcional?

A menos que estemos en la etapa de crear un nueva empresa, siempre nos encontraremos en presencia de un conjunto de programas y sistemas que soportan los procesos de negocios.

En muchas ocasiones las empresas después de operar con un sistema optan por reemplazarlo por otro distinto, casi siempre de otro proveedor. Esta decisión da origen a los proyectos de Implementación, es decir se reemplaza un sistema por otro. En este artículo nos referiremos a que la empresa no cambiará su actual sistema, sino que hará una incorporación sistemática de las nuevas funcionalidades del software a sus procesos de negocios, en donde sea pertinente.

Luego, las razón para hacer un proyecto de Actualización Funcional es cuando se necesita sincronizar los procesos de negocios con las funcionalidad del software disponibles en la nueva versión del mismo.

Por consiguiente, las preguntas a responder son:

• ¿Cuáles son las necesidades del negocio no cubiertas por el sistema informático?
• ¿Cuáles son las necesidades del negocio parcialmente cubiertas por el sistema informático?
• ¿Qué necesidades cubren las nuevas funciones del software disponible?

Por si a caso, los “sistemas” fabricados con MS Excel no son sistemas en el contexto de este artículo.

También es común que se realicen Actualizaciones de Software sucesivamente –sin modificar los procesos de negocios-, y ahí surge la Actualización Funcional como una necesidad de incorporar al uso diario las nuevas funciones del software, a esta acción también suele llamársele Optimización del Uso.

Requisitos para una Actualización Funcional

En primer lugar es necesario tener instalado y operativo el software actualizado a la versión más nueva o la que nos parezca adecuada. Este e pre-requisito técnico es fundamental, ya que es evidente que necesitamos operar con las nuevas funcionalidades del software que este pone a disposición en las versiones más recientes.

El segundo elemento a considera es el Análisis de Brecha o Gap, éste nos indicará cuales procesos de negocios es necesario actualizar con cuales funciones del software.

Para este análisis es preciso diferenciar nítidamente entre negocio y proceso de negocio. Donde negocio es el conjunto de actividades que debe realizar una empresa para dar satisfacción a sus objetivos empresariales, por ejemplo: comprar, producir, vender, contabilizar, etc. Y, proceso de negocios es la actividad –del negocio- que es soportada por un sistema compuesto por elementos de software y procedimientos [2]. De aquí se desprende que la Actualización Funcional se refiere a los procesos de negocios.

El Análisis de Brecha, que consiste en establecer cuales son los procesos de negocios necesarios de actualizar con las nuevas funcionales disponibles en el software, tiene a mi juicio tres grandes actividades:

1. Determinar el Mapa del Negocio, tener la lista de las actividades que la empresa debe realizar para dar satisfacción a sus objetivos empresariales. Este mapa debe incluir el nivel de desarrollo informático para cada una de las actividades (Implementado, NO Implementado, Parcialmente Implementado), la figura siguiente muestra un ejemplo de mapa al estilo SAP.
2. Establecer cuales son las funciones de software que es necesario incorporar al negocio.
3. Hacer la comparación entre el modelo en uso –as is – y el modelo deseado –to be- Esta comparación establece la diferencia –gap- que es preciso satisfacer mediante la Actualización Funcional.

La conveniencia de ejecutar un proyecto Actualización Funcional estará determinada por el Análisis de Brecha, si éste señala que existen aspectos de los procesos de negocios que son susceptibles de soportar con las nuevas funcionalidades del software, entonces tendremos la justificación técnica para proceder.

Aspectos a Considerar

Un proyecto de Actualización Funcional solo es posible cuando la empresa ya tiene un nivel de madurez y experiencia en la utilización de software para soportar sus procesos de negocios. En general este tipo de proyectos se da en empresas que operan con ERP, CRM, SCM, etc. provisto por alguno de los grandes fabricantes de software, como ser Oracle o SAP. De manera que nos estamos refiriendo a empresas de tamaño grande y que por lo tanto tienen los recursos económicos y humanos para sustentar proyectos que requieren:

• Procesos de Negocios formalizados, es decir modelados de acuerdo a la disciplina y herramientas de BPM –Business Process Management [3].
• Gobernabilidad, cumplimiento de normas, políticas y certificaciones (ISO 9000, IFRS, Sarbanes-Oxley, etc.)
• Personal capacitado para modelar procesos de negocios.
• Planificación y Gestión de Proyectos, este proyecto de Actualización Funcional normalmente involucra a muchas áreas de la empresa y requiriere de recursos económicos y humanos importantes, no es raro que tenga una duración de más de un año, por lo tanto es imprescindible contar con una ademada planificación, ojalá disponer de una PMO (Project Management Office) [4]
• Este es un proyecto para su área de proyectos no para su área de mantenimiento.

Referencias

[1] HP introduces SAP upgrade and management services

[2] http://es.wikipedia.org/wiki/Proceso_de_negocio

[3] Business Process Management 101: The Basics of BPM and How to Choose the Right Suite

[4] Why You Need a Project Management Office (PMO)

El término Analítica -componente de Business Intelligence- describe como las empresas recopilan y analizan datos con el fin de generar mejores decisiones y para optimizar los procesos de negocios. Luego en estricto rigor el término debe precisarse agregando la palabra negocios, entonces se tiene Analítica de Negocios, naturalmente nos referiremos a ello usando solo la palabrea Analítica. Es importante considerar que las actividades referidas a la Analítica están creciendo rápidamente en los negocios, en las agencias gubernamentales y en las organizaciones sin fines de lucro, por la simple razón que para optimizar los procesos de negocios no basta con la información financiera – contable, se requiere información sobre el estado del negocios y es este tipo de información el que puede proveer la Analítica.[1]

Desde un punto de vista de la lengua castellana el diccionario de la Real Academia Española dice:

analítico, ca.(Del gr. ἀναλυτικός). 1. adj. Perteneciente o relativo al análisis. 2. adj. Que procede descomponiendo, o que pasa del todo a las partes.

Ámbito de Acción
La Analítica trata con grandes cantidades de datos, con el análisis estadístico y cuantitativo, con modelamientos explicativos o predictivos y, con mecanismos para la toma de decisiones. Los resultados de la Analítica puede usarse como input para que los humanos tomen decisiones; también existen sistemas que automáticamente toman decisiones con un mínimo de intervención humana. En las empresas la analítica, junto con el acceso a los datos y la generación de reportes, es un subconjunto de la Inteligencia de Negocios (BI) [2].

El análisis de los datos –Analítica- es fundamental para el éxito y sobrevivencia de las empresas. Muchas de las decisiones de negocios de las empresas se fundamente o basan, al menos en parte, en los datos disponibles. Así se tiene que hoy el análisis de datos es central en la toma de decisiones como ser: tácticas de marketing, tácticas de ventas, estrategias de inversión, selección de proveedores, personal, planes de investigación, etc.

Para ejemplificar en términos prácticos el ámbito de acción de la Analítica les incluyo la visión de la empresa Business Object / SAP, en la que aparecen conceptos como Performancece Management. Scoredcard, Business Intelligence, etc. que serán motivo de otros artículos.

El Proceso de Negocios Analítico
A continuación se mencionan las funciones o tratamientos principales de la Analítica:

• Monitoreo y Evaluación de la Performance, Excepciones y Tendencias. La mayoría de los gerentes en su actividad diaria frecuentemente monitorean y evalúan que las cosas vayan según lo esperado, o el comportamiento es de acuerdo a una tendencia conocida. Gran parte de la tecnología Analítica disponible es para soportar este tipo de funciones, como por ejemplo la herramientas de BI y, las siempre presente hojas de cálculo.
• Análisis Estratégico, incluyendo Planificación, Presupuestación, Forecasting y. Análisis de Inversiones. Cuando un gerente no está preocupado de asuntos del corto plazo, el probablemente está trabajando en la estrategia del largo plazo – proyectos, pronósticos (forecast), presupuestos, inversiones potenciales, etc. Las hojas de cálculo son herramientas muy utilizadas para la planificación y presupuestación.
• Análisis Estadístico. Este tipo de análisis trata con tendencias y correlaciones, utilizando técnicas más poderosas que la simple aritmética de las herramientas típicas de monitoreo. existen paquetes especializados para este tipo de análisis como ser los de data mining. Por otra parte estos sistemas tienen cada día mejores interfaces de usuarios que hacen que su utilización sea posible para usuarios estadísticos o no estadísticos. [3]

Condiciones para establecer la Analítica en un Organización
Como siempre cada vez que se desea incorporar una nueva forma de hacer las cosas se necesita la confluencia de personas, conocimientos y tecnología, y se dá por subentendido que sin datos no hay Analítica, para el caso de la Analítica se precisa:

• Alta Gerencia Comprometida: Incorporar la Análitica, en su sentido amplio, a los negocios implica cambiso en la cultura, los procesos, el comportamiento y las habilidades de los empleados. Tales cambios ponen presión a los ejecutivos superiores –senior executives- que están interesados en la analítica y en mejorar el rendimiento de los negocios.
• Conocimiento amplio y habilidades prácticas en el uso de datos: Es muy importante contar con una base amplia de empleados con habilidades para tratar con los datos –data-savvy- o que puedan rápidamente adquirir esta habilidad. Esto implica reclutar, capacitar y compensar a quienes tiene las habilidades para la Analítica, este tipo de gente se requiere especialmente en los niveles gerenciales. A la vez es indispensable determinar donde estas habilidades pueden generar valor para la organización y, también visualizar en que área se necesitarán en el futuro.
• Procesos de Negocios Ágiles: La Analítica parte por establecer la “Verdad ünica”, esto significa que no existen conflictos en la interpretación de los datos oficiales de la compañía. esto implica generar una visión integrada de los datos en toda la organización, de modo que una métrica signifique lo mismo para todos los empleados, independiente de su posición en la estructura organizativa.. Esta condición muchas veces implica un gran trabajo de re-diseño de procesos de negocios entre las distintas filiales o unidades que componen una compañía.
• Tecnología para capturar, clasificar y generar información[1]: Se necesita una infraestructura tecnológica potente para poder almacenar y operar con los datos, hoy esta infraestructura es provistas por variados proveedores con soluciones para empresas de distintos tamaños, y aquí aplica la regla que el volumen determinar la complejidad del problema, de modo que la solución para Analítica para una empresa que procesa miles de registros al mes es más simple y de menor costo que aquella que procesa millones de registros por mes. En resumen, la plataforma tecnologíca para Analítica debe proveer tiempos de respuesta breves a los usuarios Analistas, pues de otro modo el sistema simplemente no es utilizado por estas personas.

Analítica vs. Operación
¿Cuál es la diferencia entre Analítica y Operación? El punto más relevante son los datos. Los datos operacionales, o transaccionales, son mayoritariamente atómicos (detallado) por su parte los datos analíticos son sintetizados a partir de los datos operacionales [4].

Por otra parte la aplicaciones que soportan la operación –transaccionales- comúnmente se han construido para satisfacer necesidades específicas de un área de la organización –hoy este enfoque esta cambiando a proceso de negocios- lo que significa que la información se almacena en compartimentos estancos, es lo que también se denomina “silo de información” y, se tiene que la aplicación analítica requiere “todos” los datos disponibles, esto es tiene que tener la capacidad de integrar datos independiente de su origen o del silo donde están almacenados.

Es claro, que también existe un factor de especialización. De hecho un sistema transaccional incluye reportes y, es posible que genere informes estadísticos y de gestión; sin embargo, esto no lo convierte en un sistema analítico. Este último cuenta con mecanismos específicamente diseñados para el almacenamiento estructurado y para el análisis de los datos.

Factores que afectan la Analítica
Hasta antes que existiera la Internet y la ingeniería de procesos de negocios, las organizaciones disponían de ventas de tiempo, para la toma de decisiones, muy grandes comparadas con los estándares actuales. Esta situación implica que los datos para la toma decisiones tienen que estar disponibles en el sistema analítico tan pronto se registran en el sistema transaccional, por ejemplo si un gerente necesita evaluar la rentabilidad de un cliente tiene que disponer de los datos al momento de hacer su análisis y no puede esperar hasta el próximo cierre contable [5]

Un aspecto crítico de los sistemas Analíticos es su capacidad de respuesta, es decir el tiempo que media entre una petición de datos –consulta- y la obtención de los datos pertinentes. Por su puesto el tiempo de respuesta es función de la complejidad de los parámetros de selección y de la cantidad de datos, a mayor complejidad y cantidad mayor tiempo de respuesta, que puede ir de minutos a horas. Para mantener una operación dentro de estándares adecuados a las circunstancias de cada empresa es necesario tener en cuenta tres factores principales: el dimensionamiento de la infraestructura computacional, la capacidad de los Consultores Funcionales –especialistas informáticos- y el nivel de habilidades y conocimiento que tengan los usuarios analistas, en el uso de las herramientas analíticas.

Referencias
[1] http://en.wikipedia.org/wiki/Business_analytics.
[2 ]Davenport, Thomas H.; Jeanne G. Harris (March 2007). Competing on Analytics: The New Science of Winning. Harvard Business School Press.
[3] Baker, Stephen (January 23, 2006). “Math Will Rock Your World“. BusinessWeek. Retrieved on 2007-09-19.
[4] Neil Raden, An Analytics Manifesto, January 2006.[5] Curt A. Monash, Analytic Business Processes: The Third Generation, November 2004.

[1] Información, son datos seleccionados y clasificados que tienen utilidad y sentido para alguien.

El éxito de cualquier compañía está muy ligado al buen funcionamiento de los Procesos de Negocios y consecuencialmente al desempeño del responsable de dichos procesos, es decir al Dueño de Procesos de Negocios o Business Process Owner. Dado que este es un cargo o posición que recién está tomando mayor relevancia es necesario conocer con claridad las razones que hacen necesario éste y, cual su ámbito de acción y de responsabilidad.

En estricto rigor siempre ha existido la función Dueño de Proceso de Negocios, en efecto normalmente el jefe de un área es responsable de los procesos que su unidad ejecuta, así se tiene que el Jefe de Bodegas es dueño del proceso de ingreso, almacenamiento, custodia y salida de los ítems. Por su parte el Gerente Comercial es responsable del proceso de Ventas. Y, así sucesivamente. Esto se corresponde con los Sistemas de Información, luego el Jefe de Bodega es responsable del Sistema de Inventario, el Gerente Comercial es responsable del Sistema de Ventas, y etc.

La forma de organización a la que hace referencia el párrafo anterior se caracteriza porque existe una relación directa entre el organigrama y, los procesos de negocios y, los sistemas de información. Gráficamente se tiene:

El advenimiento de los ERP, cualquiera sea su tamaño, rompe la relación entre el organigrama y los sistemas de información debido a que amplia el concepto Proceso [1], en el sentido que ahora aplica a un conjunto amplio de acciones que producen un resultado de negocios; por ejemplo: el Proceso de Ventas (Order to Cash) incluye todas las acciones desde la venta propiamente tal (nota de venta) hasta la Cobranza (depósito en el banco del pago), pasando por la verificación del estado de la cuenta corriente, preparación del despacho, la facturación, despacho, etc. Esto se puede visualizar de la siguiente manera:

Esta nueva realidad la tienen todas las empresas que ya cuentan con un ERP, si no es tomada en consideración implica una utilización sub-óptima del ERP, por la simple razón que cada Jefe de Unidad continuará velando por la optimización de los resultados –performance- de su área, tal como lo ha hecho siempre. Esta situación lleva a lo que se denomina desalineamiento del proceso de negocio. Esto es que las partes del proceso están optimizadas pero, el proceso en su conjunto no. Lo cual generá la necesidad de contar con una persona que vea el proceso integralmente, es decir que tenga la visión holística. Y, de aquí surge la posición Dueño de Proceso de Negocios.

Definición
La asociación Six Sigma tiene la definición siguiente:

• Dueño de Proceso de Negocios es el responsable del diseño y performance del proceso. Es accountable por dar soporte a la operación  y de la identificación de las oportunidades de mejoramiento [2].

Por su  parte la www.processdriven.org tiene la definición: 

• El Dueño de Proceso de Negocios es el responsable del diseño del proceso, pero no de la operación del mismo. Es además responsable de los mecanismos de medición y feedback del sistema, de la documentación del proceso y, de la capacitación de las personas que participan en la ejecución. En última instancia es el responsable del mejoramiento del proceso [3].

En el libro Business Process de Peter Keen y Ellen Knapp la definición es: 

• Dueño de Proceso de Negocios es una denominación utilizada para identificar a la persona que es responsable de un proceso hasta donde la autoridad otorgada lo permita [4].

Implicancias
Al analizar las definiciones de Dueño de Procesos de Negocios nos encontramos con una serie de implicancias que impactarán a las empresas, a saber: es necesario reconocer que la implementación de este cargo requiere de una estructura organizacional matricial, ya que una dimensión es la de los actuales jefes de línea y la otra dimensión la introduce el Dueño de Procesos de Negocios al tener responsabilidad sobre el proceso global.

• Implica la habilitación de procesos únicos para toda la empresa, esto provoca un impacto fuerte en la jefaturas, ya que es habitual que cada jefe tenga un proceso habilitado según sus criterios y preferencias.
• Resalta la necesidad de contar con procesos modelados a nivel corporativo, con particular énfasis en los mecanismos de medición de performance.
• Obliga a definir el área que será responsable de los procesos de negocios a nivel corporativo, años ha correspondía a Organización y Métodos.

Descripción de Funciones
Con el fin que se forme una idea práctica de esta función a continuación incluyo la traducción de un aviso para el cargo de Procure to Pay Process Owner (BPO) publicado en www.careerbuilder.com

Objetivos Generales

El Procure to Pay Business Process Owner (BPO) es el responsable del diseño global de los procesos de negocios y sistemas críticos relacionados con las áreas de  Abastecimiento y Cuentas por Pagar. El BPO lidera un equipo de consultores y líderes funcionales de negocio en el diseño e implementación global de los procesos y sistemas para  Abastecimiento y Cuentas por Pagar. El BPO es responsable ante el nivel ejecutivo de generar beneficios para el negocio, mediante el mejoramiento de estos procesos y la ejecución de los proyectos pertinentes.

Funciones Esenciales

1. Gestionar y ejecutar proyectos o partes de proyectos de acuerdo con los plazos y los presupuestos.
2. Responsable ante los ejecutivos superiores de la definición de los beneficios para el negocio que se obtendrán mediante el mejoramiento de los procesos y la ejecución de los proyectos y, de ayudar a la operación a obtener los beneficios esperados.
3. Desarrollar e implementar el mejoramiento continuo de los procesos.
4. Junto con los Usuarios Claves de Negocios, en una modalidad de acción permanente y de liderazgo de este grupo, es responsable de: definir, priorizar y ejecutar los mejoramientos de los procesos / sistemas.
5. Asegurar diseños globales adecuados mediante la interacción con los lideres funcionales de negocios más las acciones necesarias para obtener la decisiones adecuadas.
6. Analizar los procesos de negocios, las necesidades y las funcionalidades disponibles en las aplicaciones para establecer la solución adecuada y para determinar las brechas –gap- en funcionalidades.
7. Definir y documentar, con el apoyo de los consultores disponibles, los requerimientos de los procesos de negocios que permitirán establecer la configuración óptima de las aplicaciones.
8. Exponer al equipo de procesos de negocios el proceso de implementación (Metodología) y explicarles como otros equipos interactuaran durante la implementación de un proyecto.
9. Entender los flujos de los procesos claves y las dificultades que conllevan. Comprender las necesidades tanto del negocio como de los sistemas / procesos.
10. Demostrar gran habilidad para el análisis y la solución de problemas correspondientes a situaciones complejas y, contar con la capacidad de proveer soluciones alternativas.
11. Entregar resultados en los plazos y con los alcances programados.
12. Comunicar efectivamente al equipo de procesos de negocios la visión general de los proyectos, su enfoque y sus objetivos, para establecer expectativas razonables y para contar con apoyos durante la ejecución.
13. Contribuir en el desarrollo de la arquitectura de la solución.
14. Documentar sistemáticamente los direccionamientos, decisiones y acciones críticas.
15. Trabajar con e Equipo de Sistemas para diseñar y testear conversiones, interfaces, modificaciones y nuevas funciones.
16. Conducir conference rooms pilots para la implementación del proceso Procure to Pay.
17. Facilitar la delegación de la toma de deciones y la accountability a los niveles más bajos posibles.
18. Relacionarse con los interlocutores válidos –stakeholders- y con los ejecutivos pertinentes según corresponda a las distintas fases de los proyectos (ej.: ante-proyecto, revisiones de avances, situaciones críticas, escalamiento, etc.)
19. Desarrollar y proponer soluciones, factibles y razonables, a las brechas funcionales –gap- de los sistemas.
20. Establecer metas y  buscar su cumplimiento activamente.
21. Tener respeto tanto para con los ejecutivos como para el personal a cargo o del que participa en los equipos de trabajo.
22. Anticipar los cambios y preparar a su equipo para una transición suave mediante una planificación adecuada, expectativas razonables y una comunicación clara.
23. Ser considerado como un experto por sus pares. Con capacidad para mantener actualizado y en aumento sus conocimientos.
24. Supervisión permanente de los plazos y compromisos que su equipo debe cumplir.
25. Demostrar a su equipo de proyecto que tiene un conocimiento completo de las funcionalidades que tiene la aplicación.
26. Contribuir con el desarrollo y ejecución de la capacitación de los usuarios finales.
27. Dar soporte al Equipo de sistemas para el desarrollo de los guiones de test.
28. Responsable de proveer algún nivel de soporte durante la operación a régimen de los sistemas –post Go Live- principalmente mediante la orientación a los recursos de soporte y el análisis del negocio.

Requerimientos para el Cargo

1. Formación universitaria o equivalente lograda en el desempeño laboral.
2. 5 a 7 años de experiencia profesional en las áreas funcionales de Abastecimiento y Cuentas por Pagar.
3. Dominio de la terminología de procesos de negocios, prácticas del negocios y, de las regulaciones legales relativas al proceso de negocios en cuestión.
4. Experiencia significativa en los aspectos funcionales del ERP.
5. Experiencia en la gestión y ejecución de proyectos para generar mejoras en un proceso de negocios.
6. Experiencia con las herramientas para la implementación de proyectos del proveedor XYZ.
7. Especialización en los siguientes módulos del ERP:
   • PO - Compras
   • I- Proveedores
   • AP – Cuentas por Pagar
   • Inv - Inventario

Referencias
[1] http://msaffirio.wordpress.com/2006/05/07/bpm-business-process-management/
[2] http://www.isixsigma.com/dictionary/Process_Owner-436.htm 
[3] http://www.processdriven.org/process_owner.html
[4] http://www.peterkeen.com/recent/books/extracts/emgbp010.htm 

Si hacemos con Google una búsqueda para Software Factory encontraremos que en Sudamérica existen muchas empresas que así se denominan; sin embargo, casi ninguna explica cual es su proceso de fabricación del software, y este me parece que es esencial conocerlo de antemano a objeto de calibrar la calidad del software que puedan generar. Las referencias de clientes y proyectos anteriores son una condición necesaria pero no suficiente, por la simple razón que Ud. no sabe si la misma gente que trabajó en los proyectos que le presentan como exitosos trabajarán también para Ud. Por tanto lo que una fábrica de programas tienen para garantizar su calidad y capacidad es la disposición a  firmar contratos con SLA (Service Level Agreement).

Modelos de Operación de la Fábrica de Programas
La Fábrica de Software refiere al proceso de producir programas con rapidez y calidad a través de procesos conocidos, repetibles y gestionables, y principalmente, mejorables de modo continuo, no sólo por la incorporación de técnicas y herramientas en el desarrollo del software, sino también porque se mantiene constantemente el foco sobre el  proceso de producción y de cada uno de los pasos que esto acarrea. El término fábrica indica un compromiso a largo plazo, esfuerzos integrados - por encima de proyectos individuales- para mejorar las operaciones relativas al software.[1]

La Fábrica de Software es un tipo de tecnología generativa cuyo fin es reducir la complejidad del software y, a la vez, simplificar su producción. Esto se logra mediante: 

1. La abstracción de los aspectos complicados del software.
2. La producción en serie del software.

 Es decir, la Fábrica de Software es la transición desde la producción artesanal, artística, de software a una producción industrial semi-automatizada, que asegura la calidad y el mejoramiento continuo usando especificaciones formales, metodologías, estándares, y teniendo una mirada permanente en la evolución de la tecnología. [2] A continuación, incluyo un modelo, a modo de ejemplo, de una Fábrica de Software estructurada en base a un Modelo de Madurez de tres niveles. 

Nivel de Madurez

• Indicadores de la Producción de Software

Repetible           

• Complejidad de la Producción de Software: La Fábrica de Software aplicaun enfoque de producción sistemático y repetible.
• Conciencia sobre el Proceso: Prácticas individuales y de uso común –diseñadas- son aplicadas, esto es que la arquitectura (operacional) de la Fábrica de Software no está totalmente definida.

Gestionada 

• Complejidad de la Producción de Software: Se aplica a la Fábrica de Software un enfoque reflexivo y adaptativo, la fábrica cuenta con una arquitectura establecida y administrada, se opera con un enfoque de líneas de producción.
• Conciencia sobre el Proceso: Un arquitecto desarrolla la visión de largo plazo de los metamodelos y de las herramientas a utilizar, la producción del software es predictiva, porque está bajo control. 

Optimizado

• Una realimentación –feedback- continua contribuye al mejoramiento de la capacidad de producción y del ROI.

La Conexión con el Mantenimiento
En toda organización grande que cuente con componentes de software como ERP, CRM, SCM, etc. existen al menos dos necesidades que implican desarrollo de software:

 En cuanto a los beneficios, es necesario evaluarlos cuantitativamente, y para este efecto es necesario establecer contractualemente un SLA (Service Level Agreement) [3], esto es un acuerdo de niveles de servicios pre-definidos. Según el IEEE los SLA se deben establer foco es áreas específicas como ser: calidad del producto, calidad del proceso, calidad de la post-procucción, etc.[4].

Conviene tener en consideración que entre un contrato tradicional de servicios y un SLA existe una diferencia sutil pero sustnacial, los SLA son también servicios, pero son distintos contractualmente, ya que un SLA define más detalladamente el requerimiento, en términos de incentivos y penalidades que se obtienen por el cumplimiento o incumplimiento de niveles de servicios establecidos cuantitativamente, por ejemplo: tiempos de respuesta, tamaño del backlog, etc.. 

Referencias

[1] http://cuartageneracion.blogspot.com/2006/04/cuando-software-factory-no-es-una.html

[2] http://www.softmetaware.com/oopsla2004/langlois.pdf

[3] http://en.wikipedia.org/wiki/Service_Level_Agreement

[4] http://findarticles.com/p/articles/mi_m0SVI/is_3_11/ai_n13821992/print

Como primera definición entenderemos que un workflow se refiere a un mecanismo computacional que permite controlar una secuencia de acciones o un procedimiento que ejecutan varias personas. En general cuando se modela un proceso de negocios, supongamos que usamos un modelo EPC, se definen las interacciones entre eventos, tareas (transacciones) y personas. Pero, no se considera explícitamente la secuencia de ejecución en términos de responsables y plazos. Así se tiene que puede estar perfectamente modelado y operativo, por ejemplo, un proceso de cobranza en un sistema computacional, no obstante este no controla una secuencia de ejecución, lo que normalmente se establece mediante un procedimiento “administrativo”, con esto estamos señalado que es primero un elemento externo al proceso “computacional” y segundo que es un conjunto de actividades no controladas computacionalmente y por tanto es manual. Luego haciendo un análisis informal podemos decir que la implementación de un proceso de negocios habilita la “herramienta” y el procedimiento estable el “uso” de la herramienta.  Y, es aquí donde surge una dificultad técnica y práctica. Técnica porque la implementación de un Proceso de Negocios es un proyecto y el mecanismo de control de ejecución es otro, que precisa de la generación de un Workflow. Y, práctica porque las personas deben ocupar de manera adecuada la herramienta para obtener los resultados de negocios y porque se necesita tener cierta seguridad que las cosas se hacen según un diseño predeterminado (o normativa). 

Definición de Workflow
El concepto de workflow en la historia moderna se remonta a 1912 cuando F. Taylor  y a H. Gantt,  juntos iniciaron el estudio de la organización racional de trabajo, referido al ámbito de la manufactura. Sin embargo, la acepción que nos interesa es la referida a sistemas informáticos de modo que incluyo la que utiliza la workflow.org, que dice

 “Workflow es la automatización de un proceso de negocio, sea parcial o totalmente, durante el cual documentos, información o tareas son pasados desde un participante[1] a otro para la ejecución de otra acción, de acuerdo a un conjunto de reglas procedurales” [1]  La Relación Transacción – Workflow Un Workflow debe permitir establecer un mecanismo de control que permita asegurar una secuencia de acciones y que estas acciones las ejecuten determinadas personas en un plazo pre-establecido. Nótese que me estoy refiriendo a los workflows donde participan personas, Human WorkFlow, también existen los System WorkFlow, donde no ya participación de humanos y que antes llamábamos Batch. En el diagrama siguiente podemos observar los elementos básicos que conforma un workflow: 

Este diagrama esta basado en los diagrama de Petri, que muestran Acciones, en este caso Transacciones, eventos y esperas. Claramente esa es una sobre-simplificación de la realidad ya que:

• No muestra las personas que ejecutan las acciones
• Muestra como una unidad transacciones y eventos cuando en la práctica las transacciones las ejecuta un programa, por ejemplo el ERP, y el control de eventos y espera los maneja el software denominado precisamente Workflow.

Por tanto una manera más realista de representar esta relación puede ser:

En este diagrama se evidencia que la activación de los eventos (evt) y de las transacciones (Trx) son activados por las personas (Operador), y que los tiempos de espera (Wait) dependen de las personas, esto es cuando terminan o comienzan una acción.

También este diagrama nos permite distinguir que existen tres ámbitos de software distintos:

• El Sistema Transaccional, que son los ERP, CRM, o cualquier sistema que opera las transacciones, p.ej.: definir un nuevo cliente, registrar una orden de compra, hacer un registro contable, etc.

• El Sistema de Control de Secuencia, este es el que permite establecer el flujo de operación o workflow, identificando los Operadores, los eventos que activan las operaciones siguientes, los tiempos de espera y la verificación de condiciones de ejecución (Autorizaciones, V°B°, verificación de límites, plazos de ejecución, etc.), A este componente se le demonina Workflow, aunque como se vé no tiene todos los elementos para operar.

• Mecanismo de Comunicación, se refiere a la comunicación entre el Sistema transaccional y el Sistema de Control de Secuencia. Hoy se esta implementado por medio de los WEB Services.

 Modelo de Workflows
Considerando que en un workflow intervienen personas y muchos componentes de software es dable esperar que un sistema de está naturaleza es complejo, a modo de referencia incluyo el modelo desarrollado por la Workflow Management Coalition [2], esta organización en la que participan a desarrolladores y universidades está operando desde 1993. 

Aplicación de los Workflows
Las aplicaciones o usos de workflows que indico a continuación corresponden a situaciones que he experimentado en mi quehacer profesional y por tanto son limitadas. En todo caso estas definiciones pueden ayudar a determinar el alcance funcional de algún software que se esté evaluando. 

Workflows Consuetudinarios, son las secuencias de operación que se establecen simplemente por el uso y la costumbre. 

Woorkflows Manuales, son los que se establecen en un documento que contiene reglas, secuencias de operaciones, listas de datos posibles, identificación de los V°B°, etc. y también incluyen un diagrama de flujo del proceso. Este tipo de documento es lo que se llama Procedimiento. En este procedimiento pueden intervenir sistemas computaciones como ser: correo electrónico, planillas de cálculo, ERP, etc. El primer caso que recuerdo de este tipo de worflows fue el de Ordenes de Compra de Importación que se implemento usando correo electrónico en Sonda en la década de los 80. 

Workflows Implícitos, estas son secuencias de operación que la lógica de un sistema sugiere utilizar, normalmente corresponden a un proceso de negocios, por ejemplo la secuencia: Cotización à Nota de Venta à Picking à Despacho à Factura à Pago. Los llamo implícitos porque permiten establecer una secuencia entre una transacción y la siguiente, pero no controlan que persona es responsable de ejecutar cada transacción y en que período de tiempo. Casos como este los ví en  algunos sistema ERP como Microsoft Solomon (hoy es Dynamics) y SAP Business One. 

Workflow Documentales, estas son secuencias típicamente relacionados con un documento, sea para la aprobación de su distribución o para autorizar algún tipo de operación. Por ejemplo: autorizar la publicación de una nueva norma, definir la creación de un nuevo código de productos. Estos workflow se generan con el soporte de algún software como ser Lotus, SAP KM, etc. que básicamente controlan la secuencia de ejecución y operan sobre un formulario, el que van pasando de persona en persona, sea para completar datos o para dar autorizaciones (V°B°). 

Workflow de Aplicaciones, son aquellos que vienen incluidos en una aplicación con secuencias pre-establecidas y con la posibilidad de parametrizarlos, esto los he encontrado en los ERP y son los que claramente corresponde a un workflow según lo plantean las organizaciones que están definiendo los estándares para los workflows, Estos se encuentra en sistemas como  SAP ECC. 

Workflow ad-hoc, estos son los que una organización puede utilizar para diseñar y construir a la medida, se supone que la ventaja competitiva las corporaciones hoy la obtienen por medio de la innovación en sus procesos de negocios, es decir en la manera como ejecuta sus operaciones. y es aquí donde entran con fuerza los Workflows porque con ellos es posible establecer secuencias de operación controlables y medibles. Actualmente estoy con un grupo de colegas explorando SAP Guided Procedures para desarrollar estos Workflows ad-hoc. 

Nota: Las referencias a productos corresponden a los que he utilizado y utilizo en mi trabajo profesional.   

Referencias
[1] Workflow definition http://www.e-workflow.org/ 
[2] Workflow Management Coalition  WFMC http://www.wfmc.org/about/welcome.htm

[1] Participante es igual a recurso humano o recurso máquina.