Metodología para la identificación de inputs y outputs de procesos de negocio en un entorno colaborativo

La identificación de inputs y outputs es un aspecto de vital importancia en el modelado de procesos de negocio, estando además muy ligado a la definición del sistema de información que soporta la ejecución de los procesos.

Se propone una Metodología para la identificación y modelado de inputs y outputs de Procesos de Negocio en un Entorno Colaborativo.

Las inputs y outputs de procesos de negocio, se han abordado desde diferentes disciplinas de trabajo: Gestión de Procesos de Negocio, Arquitecturas de modelado empresarial o la  Ingeniería de Requisitos Software. En un entorno colaborativo los procesos de negocio tienen una serie de diferencias respecto a los procesos de negocio tradicionales. Por una parte

la ejecución de las actividades del proceso son responsabilidad de dos o más entidades (empresas, cadenas de suministro o redes), y con ello la problemática del sistema que da soporte a los procesos y el sistema de información asociado, por otra parte las relaciones colaborativas transforman el modo de compartir información entre entidades.

                                              

En el ámbito de la Gestión de Procesos de Negocio se proporcionan técnicas y herramientas que consideran inputs y outputs de los procesos. Algunas de estas técnicas son (Aguilar-Saven, 2004): Flow chart, Diagramas de flujo de datos (Data Flow Diagrams-DFD), Diagramas de actividades y roles (Role Activity Diagrams-RAD, Diagramas de interacción de roles (Role Interactions Diagrams-RID), Diagramas de Gantt, IDEF (Integrated Definition for Function Modelling), Redes de Petri coloreadas (Couloured Petri-net-CPN), Métodos orientados a objetos (Object Orientation-OO) o Técnicas de Workflow. Las arquitecturas de modelado empresarial se acercan al modelado de procesos de negocio utilizando para ello distintas vistas de modelado. Cada vista focaliza y trabaja en una par te específica del modelo de empresa integrado (Toh, 1999).

 

Cada arquitectura de modelado propone sus propias vistas de modelado, por ejemplo: AIMOSA (Vistas de Organización, Recursos, Información y Función), GRAI-GIM (Vistas del

Sistema Físico, Decisional, de Información y Funcional), PERA (Arquitectura de Organización y RR.HH., del Sistema de Información y del Equipo de Producción), GERAM (Vistas de Organización, Recursos, Información y Función), ARIS (Vistas de Función, Datos,

Organización y Control). Las inputs y outputs de los procesos se han abordado principalmente desde la vista funcional y la vista de información (Melao y Pidd, 2000). Por último, la Ingeniería de Requisitos software permite identificar los elementos que necesitan ser representados en los modelos cuya finalidad sea el diseño de un sistema de información, y que por tanto, consideran explícitamente la relación de los procesos de negocio con los sistemas informáticos.

 

La Ingeniería de Requisitos trata de comprender las necesidades exactas de los usuarios del sistema software, para traducir tales necesidades en instrucciones precisas y no ambiguas las cuales podrían ser posteriormente utilizadas en el desarrollo del sistema.

 

Las distintas disciplinas de trabajo, proporcionan diferentes herramientas de modelado e incorporan, en muchos casos, sus propias metodologías (Cuenca et al., 2006). Las metodologías de modelado de proceso son dependientes del modelo a desarrollar. Desde una perspectiva global, la información relevante para documentar un proceso contiene la definición del objetivo, alcance, términos y definiciones, responsabilidad y autoridad, actividades que se llevan a cabo, inputs y outputs, indicadores, recursos, infraestructura e interrelaciones con otros procesos (Arrascaeta, 2005, y Athena, 2004). Lin y Polenske (1998) presentan un modelo de inputs y outputs del proceso de producción. Este modelo proporciona una descripción matemática de las inputs y outputs existentes en el proceso de producción con el fin de proporcionar información para la toma de decisiones, donde la actividad productiva de una empresa es considerada como un conjunto de procesos de producción que combinan diferentes factores para producir resultados. Sin embargo, este enfoque no tiene en cuenta las relaciones entre el proceso y sus clientes y proveedores.

 

Cheng-Leong et al. (1999) diferencia dos tipos de inputs y outputs: de información y de material. En un contexto de cadena de suministro el modelo SCOR (Supply Chain Operational

Reference Model) se utiliza para mejorar la comunicación entre las empresas de la cadena de suministro y sus sistemas de información (Athena, 2004).Albino et al. (2002) proponen un enfoque basado en inputs y outputs de procesos de producción, utilizado para desarrollar modelos específicos que investiguen los flujos entre procesos de producción, ya sea de una cadena de suministro global o de una parte de la cadena. Hernández et al. (2008) distinguen entre flujos de producto (inputs y outputs a los procesos de transformación), flujos de información (inputs y outputs a los procesos de transformación de la información) y flujos de decisión (procesos de decisión y sus relaciones).

 

La identificación de inputs y outputs de un proceso es un requerimiento a cumplir en el modelado de procesos de negocio, sin embargo las propuestas analizadas no detallan cómo se debe realizar. Esto justifica la necesidad de una metodología que ayude a la identificación y análisis de inputs y outputs de procesos de negocio.

Metodología propuesta para la identificación y modelado de Inputs y Outputs de procesos de negocio en entorno colaborativo

 

Mediante la metodología se identificarán inputs y outputs de proceso desde el punto de vista del flujo de la actividad que se desarrolla. En este sentido, las inputs son transformadas o utilizadas durante la actividad para producir una salida u output. La metodología propuesta sigue una aproximación a los procesos de arriba abajo (Top-Dow) de forma que se identifiquen, en este orden, los inputs y outputs de los procesos, de los subprocesos y de las actividades.

 

Los pasos a seguir para cada proceso, subproceso o actividad son:

 

1. Identificar el proceso, subproceso o actividad: es preciso identificar inequívocamente el  proceso, subproceso o actividad sobre el que se realizarán los siguientes pasos de la metodología.

2. Identificación de outputs (resultados): se deben diferenciar las outputs del proceso que proporcionan valor al cliente, de otras outputs del proceso consecuencia de la actividad de transformación de las inputs en las outputs de valor:

 

a) ¿Qué outputs (resultados) de valor para el cliente proporciona el proceso?

b) ¿Qué otras outputs genera el proceso como consecuencia de la trasformación de las inputs?

 

Para cada output:

 

2.1. ¿Se trata de una output de información o material?: los procesos pueden proporcionar outputs de información o de objetos materiales. En la metodología se entiende que pueden aparecer:

 

— Output de datos o información: datos o información que son producidos por la actividad o proceso.

— Output de objetos (o materiales): objetos que son producidos por la actividad o proceso.

 

2.2. ¿Quién es el cliente o destinatario?: La output del proceso está justificada al proporcionar valor a un determinado cliente (2a).

 

En el caso de otras outputs como consecuencia del proceso de transformación (2b) es posible hablar de destinatario de la output.

 

2.3. Especificación de la output: es necesario especificar la output con el objetivo de identificarla claramente según su propia naturaleza, y desde la perspectiva del destinatario de dicha output. Esto último condiciona el hecho de que la output tenga o no el valor esperado por el cliente:

 

2.3.1. ¿Cuál es la especificación de la output desde la perspectiva del cliente o destinatario?

2.3.2. ¿Cuál es la especificación correspondiente a su propia naturaleza según se trate de  información u objeto?

 

3. Identificación de las inputs: Las inputs al proceso pueden ser de diferentes tipos. IDEF0 incluye en su modelo de proceso los siguientes elementos básicos que pueden ser entendidos como inputs al proceso: autoridad (descripción, especificación o justificación de un proceso), control (condiciones que activan el proceso), inputs (objeto que entra al proceso), y  mecanismos (recursos que utiliza el proceso).

 

En la metodología propuesta se identifican únicamente las inputs que entran en el proceso para ser transformadas o utilizadas con el fin de producir una output.

 

Para cada input:

 

3.1. ¿Se trata de una input de información o material?: en la metodología se entiende que pueden aparecer 2 tipos de inputs:

 

— Input de datos o información: Datos o información que son transformados o utilizados por la actividad o proceso para producir una output.

 

— Input de objetos (o materiales): Objetos que son transformados o utilizados por la actividad o proceso para producir una output.

 

3.2. ¿Quién es el proveedor u origen?: una información necesaria en la identificación de las inputs es el proveedor u origen que proporciona la input, en el caso de que se tengan establecidas o se desee establecer algún tipo de relación.

 

3.3. Especificación de la input: es necesario especificar la input con el objetivo de identificarla claramente según su propia naturaleza, y desde la perspectiva de la actividad que transforma o utiliza dicha input, ya que, esto último condiciona el hecho de que la input cumpla los  requerimientos necesarios en la actividad para transformarse en una output:

 

3.3.1. ¿Cuál es la especificación de la input desde la perspectiva de la actividad?

3.3.2. ¿Cuál es la especificación correspondiente a su propia naturaleza según se trate de información u objeto?

About justindeveloper

I am MCP (Microsoft Certified Professional). MCTS (Microsoft Certified Technology Specialist) and MCPD (Microsoft Certified Professional Developer), also I am SAP Business One Certified!! Desarrollando desde el IDE de Visual Studio NET 2003 hasta ahora con el Visual Studio NET 2010. Desde Microsoft SQL Server 2000 hasta ahora con el Microsoft SQL Server 2008 R2 y tambien con SharePoint, desde WSS 3.0 y MOSS 2007 y ahora familirizandome con el Sharepoint Foundation 2010 & Sharepoint Server 2010. The software development will follow being every time more wonderful!
This entry was posted in Uncategorized and tagged , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s