English (pdf)
Article in xml format
Article references
Automatic translation
Send this article by e-mail
Cited by SciELO 
Cited by Google 
Similars in
SciELO 
Similars in Google 
Permalink
1. Introducción
El análisis y diseño de procesos de negocio tiene el objetivo de concebir y evolucionar el diseño de los procesos, en conformidad con las exigencias y necesidades del contexto actual [1]. Dicho contexto se caracteriza por un desarrollo tecnológico acelerado [2] y otros desafíos provenientes de exigencias del mercado y el entorno [3].
Ciertamente para el análisis y diseño de los procesos es preciso ser consciente del objeto de diseño y los factores que afectan su comportamiento. En el campo de acción de mejora e innovación de los procesos, los modelos de procesos de negocio (MPN) juegan un papel fundamental, ya que tienen la capacidad de ofrecer vistas simplificadas de la realidad del proceso, constituyendo la principal herramienta de análisis y diseño, por lo que la calidad de dichos modelos cobra gran importancia en la literatura científica [4].
La calidad de estos modelos está asociada a la correcta utilización de las reglas gramaticales del lenguaje de representación de los procesos (criterio de calidad de la sintaxis) [5], al valor de uso de dichas representaciones en el trabajo de análisis y diseño (criterio de valor pragmático) [5], y a la consistencia conceptual y a la coherencia con la realidad de los MPN (criterio de calidad semántica) [5].
En la literatura se han desarrollado mecanismos para validar la sintaxis de los modelos de procesos [6]. Asimismo, se han encontrado patrones de modelado que ayudan a decidir, desde el punto de vista pragmático, qué lenguaje de modelado utilizar, de acuerdo a las necesidades de análisis y diseño de procesos [7]. Sin embargo, el criterio semántico sigue siendo una preocupación, pues estudios han mostrado que muchos MPN no son válidos [8-10], ya que no capturan las verdaderas especificaciones de diseño del proceso. Es decir, se representan procesos que no capturan la dinámica real del proceso o que no reflejan la verdadera idea de diseño, mejoras e innovación que se desean implementar, sobre todo cuando se requiere un conocimiento funcional muy especializado [9]. Esta situación se vuelve más compleja con el continuo desarrollo de las capacidades de las tecnologías de la información pertinentes a los procesos; tales tecnologías constituyen factores que dinamizan el cambio e innovación del diseño de los procesos reflejados en los modelos [8].
En tal sentido, la calidad de los MPN ha generado una alta preocupación, ya que las decisiones tomadas sobre la base de modelos que no reflejan la realidad o la necesidad de cambio, conllevan a tomar malas decisiones que afectan el funcionamiento de la organización [8,10]. La brecha entre los MPN y la realidad depende, en gran medida, del conocimiento conceptual del modelador [8-11]. De hecho, los modeladores no tienen el mismo conocimiento para comprender, describir la realidad y tomar decisiones de cuáles conceptos y detalles deben ser capturados y luego representados.
En búsqueda de referentes que estén orientados a resolver las problemáticas antes expuestas, se han identificado modelos que estructuran conocimiento de procesos de negocio a nivel ontológico [12-14]. Entre ellos, la presente investigación privilegia a los que son consistentes con el paradigma de arquitectura empresarial [15,16], porque conceptualizan el conocimiento ontológico que debe ser objeto de análisis dentro del sistema organizacional, integrando perspectivas de procesos de negocio y de tecnologías de la información [17,18].
El conocimiento ontológico es el conocimiento conceptual que describe las invariantes de conceptos y sus relaciones [19], que deben ser tenidas en cuenta durante el trabajo de modelado [19,20], de acuerdo con las prácticas que ya han sido sistematizadas [21].
Los recursos que estructuran el conocimiento ontológico explicitan un sistema de conceptos y sus relaciones en un dominio de conocimiento específico. El conocimiento contenido en estos recursos ha sido validado por comunidades con experticia y experiencia en dicho dominio de conocimiento. Los recursos ontológicos pueden ser expresados en forma de glosario de términos, mapas conceptuales u ontologías computacionales [17].
El conocimiento ontológico guía la obtención de soluciones de modelado de procesos para un contexto específico o situado. El conocimiento situado es el conocimiento conceptual que describe la realidad o circunstancias de una organización específica [22,23] y varía de un contexto a otro [24]. Operar con el conocimiento situado contribuye a concientizar las necesidades de modelado del contexto [25], comprender la lógica que justifica las decisiones de modelado, así como a facilitar la evolución de los modelos ante nuevos cambios del contexto [26].
Al reconocer estos beneficios, el presente artículo tiene el objetivo de proponer y aplicar un método para el modelado conceptual de los procesos de negocio a niveles ontológico y situado en el alcance de la arquitectura empresarial. Para ello, el artículo se estructura en varias secciones. La sección de Métodos describe los pasos que deben seguirse para abordar cada conocimiento conceptual que influye en la calidad de los MPN resultantes. En la sección de Resultados y discusión se presenta un caso de estudio en una empresa proveedora de servicios de informatización, donde se aplican los pasos del método para el modelado conceptual del proceso de generación de ofertas comerciales para el desarrollo de proyectos de software. Por último, se presentan las conclusiones del artículo.
2. Método
2.1 Conocimiento conceptual de procesos de negocio
Para abordar el conocimiento de los MPN desde el punto de vista conceptual se ha tomado como referente el Modelo de Triple Vista (TVM, por sus siglas en inglés) propuesto por [27]. El TVM permite agrupar en tres dimensiones el conocimiento de proceso requerido para el modelado; con este patrón se estructuró el marco conceptual de procesos de negocio (MCPN) mostrado en la Fig. 1.
Seguidamente se describe el conocimiento conceptual de procesos de negocio con alcance de arquitectura empresarial, agrupado en las tres dimensiones del MCPN. Dicho conocimiento fue identificado a partir de la revisión de la literatura científica y recursos ontológicos que abordan el conocimiento de arquitectura empresarial.
En la dimensión de elemento se captura el conocimiento ontológico que conceptualiza los componentes del proceso que son objeto de modelado [27]. En el dominio de los procesos, estos componentes se agrupan en:
Elementos de la arquitectura: conceptualizan los procesos como caja negra, considerando la interacción entre ellos y con su entorno [28].
Elementos de secuencias: estructuran el conocimiento de las actividades, condiciones y coordinaciones que ocurren dentro de un proceso [29].
Elementos de organización: consideran, desde el punto de vista conceptual, los recursos humanos y otros requeridos para la ejecución de las actividades del proceso [29].
Elementos de información: especifican el conocimiento de la arquitectura de información en el alcance del proceso. Los principales conceptos capturados en este grupo son: datos, reportes, formularios e indicadores de control y resultados [30].
La dimensión de restricciones trabaja con el conocimiento ontológico que conceptualiza el dominio funcional con el que opera el proceso. Dicho conocimiento define el comportamiento, las propiedades y relaciones que deben tener los componentes del proceso conceptualizados en la dimensión de elementos [31]. Es decir, cuando se captura el conocimiento funcional asociado a un proceso, se pueden identificar actividades, roles e informaciones que son recurrentes en procesos que operen con el mismo conocimiento funcional. Por ejemplo, en el dominio funcional de venta se pueden identificar los siguientes conceptos: vender, vendedor, factura. Dentro del conocimiento funcional se captura:
Conceptualización funcional: define un conjunto de conceptos y relaciones específico o especializado de un área o dominio funcional [13], lo cual permite enmarcar el conocimiento funcional que será considerado.
Capacidades funcionales: representan lo que los procesos hacen o deben hacer para cumplir sus objetivos y responsabilidades en el marco de un dominio funcional [32],
Capacidades tecnológicas: definen las funcionalidades y servicios que proveen las tecnologías de la información para soportar el desarrollo de capacidades funcionales requeridas por el proceso [33].
Reglas de referencia: son soluciones típicas o recurrentes que implementan tipos de procesos para realizar las capacidades funcionales. Las fuentes de reglas de referencia pueden ser normas, estándares, modelos de referencia, software u otros que la organización decida adoptar.
Por último, la dimensión de intencionalidad está relacionada con el conocimiento situado, orientado a lograr coherencia entre el modelo de proceso que resulte y la realidad donde dicho proceso será ejecutado [31]. Dicho conocimiento depende del conocimiento del modelador y su capacidad para entender el contexto organizacional del proceso. Comprender el contexto depende de los factores considerados y de las partes interesadas que se entrevisten. En tal sentido, dentro de la dimensión de intencionalidad se capturan:
Factores del contexto: ofrecen perspectivas externas e internas desde donde se puede analizar un contexto organizacional. Las perspectivas externas incluyen los elementos del macro-entorno y el micro-entorno, los que consideran regulaciones, clientes, medio ambiente, entre otros [34]. Por su parte, las perspectivas internas coinciden con las capas de la arquitectura empresarial: capa corporativa, capa de negocio, capa de información, capa de aplicaciones software y capa de infraestructura tecnológica. Dichas capas incluyen políticas, estrategias, principios, softwares disponibles, tecnologías existentes, entre otros aspectos [17].
Partes interesadas: reflejan posiciones que se adoptan de cara a un contexto organizacional. Las partes interesadas proveen información sobre variables del contexto desde diferentes puntos de vista, atendiendo a sus preocupaciones, de acuerdo al nivel de involucramiento o afectación que tengan en relación a dicho contexto [35].
Variable del contexto: Cuestiones que caracterizan un contexto organizacional específico, las cuales pueden ser positivas o negativas (problemas, riesgos, oportunidades, necesidades y expectativas) [34].
2.2 Estudio de métodos de modelado conceptual de procesos de negocio
Considerando la importancia de obtener modelos de procesos de negocio con calidad conceptual, se realizó un estudio del estado del arte sobre esta temática. El propósito era identificar el grado de cubrimiento del conocimiento conceptual en los métodos de modelado de procesos de negocio propuestos en la literatura. Para ello se recuperaron 1132 referentes que abordan explícitamente el modelado de procesos, los cuales fueron refinados hasta 353 considerando filtros de actualidad (2015-2019) y procedencia (artículo de revistas y ponencias). Seguidamente se seleccionaron aleatoriamente 57 referencias para el estudio, para un nivel de 95% de confianza.
En el estudio se aplicaron criterios por cada dimensión del marco de conocimiento conceptual de procesos de negocio. Los criterios permiten verificar si la propuesta:
reconoce la necesidad de considerar la dimensión.
conceptualiza el conocimiento de la dimensión.
opera con el conocimiento de la dimensión.
Los criterios fueron evaluados de manera escalonada, es decir que si no cumplía el primero no se procedía para el segundo. La evaluación fue 1, 2 o 3, en dependencia del avance en el cumplimiento del criterio y cero en caso de que no se cumpliera ninguno. Finalmente se calculó un indicador de cubrimiento, considerando la máxima puntuación en cada dimensión. La Tabla 1 muestra las referencias con un grado de cubrimiento por encima de 50%; donde DE es la dimensión de elemento, DR, la dimensión de restricción y DI, la dimensión de intencionalidad.
Puede observarse en la tabla que, de acuerdo con los referentes estudiados, todavía existen brechas para operar con el conocimiento conceptual de procesos de negocio. Ello conduce a problemáticas de calidad en estos modelos, lo que afecta las decisiones de diseño y mejora de los procesos y, en consecuencia, el funcionamiento de las organizaciones.
2.3 Método de modelado conceptual de procesos de negocio
Atendiendo a las problemáticas descritas en el acápite anterior, se ha estructurado el método de modelado conceptual del proceso que se muestra en la Fig. 2. Dicho método considera las tres dimensiones del conocimiento conceptual requerido para obtener MPN con calidad.
El método está orientado a obtener con calidad conceptual los modelos de procesos de negocio. Para ello, cada uno de los pasos opera con el conocimiento ontológico y situado requerido para el modelado de procesos. Sin embargo, durante la actividad de modelado no siempre se abarca toda la conceptualización del proceso; ello depende de qué perspectiva del proceso se desea modelar, atendiendo al objetivo pragmático del modelo, así como de los recursos con que se disponga. Lo que sí se debe garantizar, desde el punto de vista semántico, es que lo que se represente sea consistente con la conceptualización de proceso y coherente con su realidad. De lo contrario el modelo puede carecer de sentido o significado para su uso.
2.4 Identificar necesidades de modelado del proceso de negocio
Antes de iniciar la modelación es preciso identificar las necesidades de modelado para tener idea del alcance del trabajo. Para ello se identifican los procesos que se desean modelar y dónde empieza y termina cada uno. También, de acuerdo al propósito de modelado, se debe determinar qué parte del proceso se desea representar. De este modo se delimita el alcance. Algunos propósitos pueden conducir a representar la secuencia de actividades del proceso, el flujo de información, la interacción entre los actores, los intercambios de información entre procesos, representados éstos como caja negra, entre otros. Cada uno de tales propósitos puede orientar sobre qué aspectos conceptuales deben ser considerados y cuán profundo debe ser el análisis.
Por otra parte, es preciso identificar los dominios funcionales que intervienen en el proceso, el sector organizacional en el cual dicho proceso se desarrolla, los modelos de referencia que serán considerados; todo ello es parte de la conceptualización que debe ser tenida en cuenta para el modelado del proceso.
2.5 Modelar el conocimiento funcional del proceso de negocio
La modelación del conocimiento funcional tiene valor como marco de referencia sobre buenas prácticas del proceso objeto de estudio. Durante este paso se debe adquirir conocimiento funcional, a través de acciones de vigilancia que permitan identificar referentes teóricos y prácticos para el buen funcionamiento del proceso. Existen varias fuentes desde donde se puede adquirir conocimiento funcional del proceso, tales como documentos de la organización, expertos funcionales, literatura funcional y recursos ontológicos.
Este método privilegia la recuperación de recursos ontológicos de los dominios funcionales. Con ello, los modeladores pueden aprender y ser más eficaces en la captura del conocimiento funcional; tradicionalmente se realiza consultando expertos funcionales, quienes no siempre están disponibles, o tienen un conocimiento parcializado.
Para dejar explícito el conocimiento funcional adquirido es importante apoyarse en técnicas y herramientas para la modelación de dicho conocimiento. En la literatura se reconocen los mapas conceptuales, mapas de capacidades, servicio de soporte a las capacidades, entre otros [33].
Dicho conocimiento puede ser desagregado en requisitos funcionales del proceso, expresados en lenguaje natural, de modo que sirva como referencia o lista de chequeo para verificar que el modelo del proceso incorpora los aspectos funcionales que deben ser considerados.
2.6 Modelar conocimiento contextual del proceso de negocio
Otro aspecto relevante para el modelado de los procesos es el contexto organizacional, el cual regula los grados de libertad durante la toma de decisiones de modelado de los procesos. Tener conciencia del contexto organizacional implica la identificación de información relevante de los entornos externo e interno, que deba ser considerada para que los procesos estén en conformidad con su realidad.
Para adquirir conocimiento del contexto se procede a la recuperación de documentos explícitos de dicho contexto organizacional. Dichos documentos pueden ser externos o internos a la organización, recogidos en normas, regulaciones, planes estratégicos, encuestas a clientes, comportamiento de indicadores, entre otros. También es preciso consultar el conocimiento tácito de las partes interesadas al proceso, las cuales pueden ser internas o externas al proceso, tales como: clientes, gobierno, comunidad, directivos, gestores y trabajadores del proceso.
Como resultado de consultar fuentes explícitas y tácitas, se obtiene un volumen de información que debe ser analizado. Para ello pueden utilizarse herramientas de análisis que permitan sintetizar la información proveniente de las diversas fuentes, tales como: Fuerzas de Porter [38], Matriz DAFO [39], AMFE [40], entre otras.
Como resultado del estudio del contexto se identifican las variables del contexto que regulan el modelado de los procesos. Dichas variables constituyen el conocimiento situado asociado a un contexto organizacional específico. Se sugiere que las variables se expresen en lenguaje natural en forma de lista de chequeo, para verificar que quedan resueltas en el modelo de proceso de negocio.
2.7 Modelar el proceso de negocio
Para modelar el proceso de negocio con calidad, atendiendo al conocimiento situado, es preciso resolver los requisitos funcionales formulados y las variables del contexto identificadas. Con el ello se garantiza que el MPN sea coherente con su realidad.
Por otra parte, también es necesario que el MPN sea consistente con el conocimiento ontológico del dominio de los procesos conceptualizado en la dimensión de elemento del TVM. Para representar la dimensión de elemento se pueden utilizar múltiples técnicas y herramientas; tales como: leguaje BPMN [41], matriz CRUD [42], matriz RACI [43].
Luego de definir qué dimensiones del proceso serán objeto de modelado y qué técnicas y herramientas serán utilizadas, se procede a resolver los requisitos funcionales y variables del contexto. Para ello, se propone identificar modelos de referencia que contengan reglas de referencia orientadas a su resolución. Por lo tanto, es preciso consultar fuentes de referencia que ayuden a la formulación de estas reglas. Las fuentes de formulación pueden ser modelos de referencia explícitos (procesos de referencia o tecnologías de referencia) o fuentes tácitas, desde donde se adquieren soluciones formuladas por expertos, o por el propio modelador o miembros de la organización, basados en sus experiencias.
Debe notarse que los modelos de referencia que se identifiquen pueden estar funcionando con éxito en otros contextos. Sin embargo, es posible que cuando se adopten, deban ser modificados para que se adapten al nuevo contexto donde se ejecutarán los procesos objetos de modelado.
2.8 Chequear la calidad semántica del modelo de proceso de negocio
Para realizar esta actividad se han tenido en cuenta indicadores ontológicos e indicadores situados. Los indicadores ontológicos miden la profundidad del estudio para generar los modelos, teniendo como referencia el dominio de conocimiento funcional, contextual y de proceso. Por su parte, los indicadores situados miden cuánto el modelo de proceso resultante cumple con los requisitos funcionales, variables del contexto y soluciones de modelado extraídas de modelos de referencia. La Tabla 2 describe cada indicador.
Los indicadores se miden en porciento y se calculan atendiendo a qué parte del conocimiento ontológico o situado se considera respecto al total que debe ser considerado. Por ejemplo, cuando se modela el contexto para identificar variables de dicho contexto, se estudian diferentes factores considerando las partes interesadas. Sin embargo, puede que durante el estudio algunos factores y partes interesada se omitan, en tal caso el indicador “cubrimiento ontológico del contexto” se afecta por no estudiar algunas perspectivas del contexto que debieron ser consideradas. En este escenario pueden que no se hayan identificado todas las variables del contexto por omisión de perspectivas y el modelo de proceso que se proponga solo va a considerar aquellas variables que sí fueron identificadas.
Para calcular los indicadores se debe tomar el valor total como referencia para cada uno. En el caso del conocimiento ontológico del contexto se han identificado 57 conceptos, considerando factores del contexto, partes interesadas y los tipos de variables del contexto. En el caso del conocimiento ontológico de proceso se han identificado 29 conceptos, atendiendo a las cuatro dimensiones explicadas en la sección 2.1 del artículo. Para el resto de los indicadores, el total depende de los casos específicos donde el método sea aplicado.
3. Resultados y discusión
En esta sección se presenta un caso de estudio desarrollado en la empresa DESOFT, proveedora de servicios de informatización en Cuba. De acuerdo con [44], con el desarrollo de un caso es posible verificar las capacidades del método propuesto en un contexto, comprendiendo de manera intensiva la interacción entre sus distintos componentes. Asimismo, permite el estudio del problema débilmente estructurado que se presenta en la organización, reconociendo a esta como un sistema complejo, donde el recurso humano es esencial para la solución del problema, por su carácter de empresa de servicios.
DESOFT tiene la misión de “Desarrollar y comercializar productos y servicios informáticos integrales asociados a las Tecnologías de la Información, contribuyendo al desarrollo sostenible de la sociedad”.
La empresa está diseñando un servicio de consultoría, para la informatización de las organizaciones cubanas con el sistema ERP ODOO 11. ODOO es un sistema de planificación de recursos empresariales (ERP, por sus siglas en inglés), que permite integrar la información de los diferentes dominios funcionales de gestión empresarial [45].
Sin embargo, varias experiencias de aplicación del servicio han fallado, debido a que no logran introducir los beneficios del sistema (capacidades tecnológicas) en el funcionamiento de las organizaciones. Ello se debe a las siguientes insuficiencias detectadas en el servicio de consultoría:
La documentación de los procesos no se rediseña con la introducción de soluciones informáticas.
El equipo consultor de DESOFT no tiene concebido roles que se dediquen al estudio consciente de los procesos que serán transformados.
El conocimiento de cada experiencia de aplicación del servicio se pierde y no se convierte en activo para futuras aplicaciones.
En tal sentido, DESOFT se ha dado cuenta que necesita gestionar el conocimiento del modelo de referencia del sistema ERP ODOO y el conocimiento de los procesos de negocio que informatizan. En este escenario, el método de modelado conceptual de procesos de negocio propuesto permitiría gestionar el conocimiento requerido por el servicio de consultoría. Para incidir en la mejora del diseño del servicio de consultoría, los directivos de DESFOT han decidido adoptar el ERP ODOO 11 en sus propios procesos, empezando por el proceso de “Generación de ofertas comerciales para proyectos de software”. Es en este proceso donde el método de modelado conceptual de procesos de negocio fue aplicado.
3.1 Identificar necesidades de modelado del proceso de negocio
El siguiente trabajo de modelado está orientado a representar la dimensión de secuencia del proceso. El alcance del proceso se define es su inicio con la solicitud de un servicio por parte del cliente. Dicha solicitud conduce a la conformación de un proyecto de software, para lo cual se estiman los recursos, capacidades y esfuerzos requeridos para ejecutarlo. Con dicha información se elabora una ficha de costo y se emite una oferta comercial, a la que se le debe aplicar las políticas comerciales, en caso de que apliquen, y el margen de ganancia planificado, con lo cual se construye la oferta final al cliente.
De acuerdo con el alcance del proceso, este contiene conocimiento funcional de la gestión comercial y la gestión de proyectos dentro del sector de la Industria del Software. Para la modelación del proceso se ha tomado como modelo de referencia el flujo de trabajo del sistema ERP ODOO, con el cual se quiere informatizar dicho proceso.
3.2 Modelar el conocimiento funcional del proceso de negocio
Para adquirir información funcional del proceso es necesario estudiar el dominio de gestión comercial y el de gestión de proyectos durante la generación de ofertas comerciales en la industria del software. Atendiendo a este alcance se consultaron documentos existentes en la empresa, referentes de la literatura y recursos ontológicos de estos dominios (ver Tabla 3).
Puede verse que existen cuatro recursos ontológicos que conceptualizan diferentes aspectos del dominio funcional del proceso. Estos recursos fueron explorados, para comprender su contenido, haciendo uso de la tecnología expuesta en [46]. Como resultado, se identificaron los conceptos que caracterizan el dominio comercial y el dominio de gestión de proyectos, en el alcance de la generación de ofertas comerciales para la industria del software. En total se identificaron 76 conceptos que conforman la conceptualización funcional del proceso, considerando ambos dominios funcionales. Algunos ejemplos de estos conceptos son: costos, ingresos, software, proyecto, y recursos.
Basado en la conceptualización funcional del proceso se formularon preguntas para entrevistar al personal de la empresa con conocimiento funcional del proceso. A continuación, se muestran algunas preguntas de las 56 que fueron formuladas:
¿Cuáles elementos se deben tener en cuenta para estimar los costos de un proyecto de software? ¿Cuáles capacidades deben ser realizadas en el proceso para estimar dichos costos? ¿Existe alguna capacidad tecnológica que permita agilizar y hacer más precisa su estimación?
¿Cuáles son los tipos de gastos operativos y administrativos que deben cubrirse con el ingreso que genera un proyecto de software? ¿Cuáles capacidades deben ser realizadas en el proceso para estimar dichos gastos? ¿Existe alguna capacidad tecnológica que permita agilizar y hacer más precisa su estimación?
¿Cuáles capacidades deben ser realizadas en el proceso para conformar el precio final de los proyectos de software, de modo que garantice la rentabilidad planificada?
Basados en el conocimiento funcional adquirido, se aplicaron técnicas de modelado de capacidades, lo que permitió abordar diferentes perspectivas funcionales. En la Fig. 3 se muestra una de las técnicas aplicadas para modelar el conocimiento funcional. Consiste en un mapa de capacidades, donde se representan las capacidades funcionales y la jerarquía entre ellas.
A partir de la adquisición y análisis del conocimiento funcional del proceso se formularon 32 requisitos funcionales, los cuales tienen un nivel de cubrimiento de la conceptualización funcional del proceso de un 94,7%. Algunos ejemplos de los requisitos formulados se muestran a continuación.
Recibir solicitudes de los clientes.
Incluir en los costos de proyectos de desarrollo de software el tamaño del código a partir de estimar la cantidad de requisitos que deben ser desarrollados.
Generar tarifas a los clientes, atendiendo a su cultura, involucramiento y estabilidad para asimilar las soluciones propuestas por la empresa.
El 37,5% de los requisitos están resueltos en el diseño actual del proceso de gestión comercial de la empresa; para el diseño deseado se pretende incrementar en un 28.1%.
3.3 Modelar conocimiento contextual del proceso de negocio
Para abordar el conocimiento contextual, se consultaron como fuentes externas documentos emitidos por los organismos reguladores de las funciones que se realizan en el proceso de generación de ofertas comerciales. Dichos organismos son: Consejo de Estado, Consejo de Ministros, Ministerio de Comunicaciones (MINCOM), Ministerio de Finanzas y Precios (MFP), Ministerio de Ciencia, Tecnología y Medio Ambiente (CITMA) y la Oficina Central de la propia empresa. Algunos documentos del contexto consultados se muestran en la tabla 4; abordan factores del contexto tales como regulaciones y normas.
Por otro lado, se consultaron documentos internos que permitieran identificar problemáticas y riesgos del proceso, tales como manuales de riesgos y comportamiento de los indicadores del proceso. Asimismo, se entrevistaron a directivos, trabajadores y gestores del proceso. Para ello se formularon preguntas del contexto, orientadas a factores contextuales. Los debates y entrevistas fueron grabados para luego unificar y sintetizar las variables del contexto que estaban siendo objeto de debate.
Algunas de las preguntas formuladas fueron las siguientes:
¿Existe algún incumplimiento del acuerdo de nivel de servicio?
¿Cuáles son las reclamaciones más frecuentes?
¿Cómo la cultura del cliente beneficia o afecta al proceso?
¿A cuáles estrategias debe estar alineado el proceso?
¿Cuáles restricciones gubernamentales limitan la realización de capacidades del proceso?
¿Qué insatisfacciones existen entre los trabajadores del proceso?
¿Cómo la cultura de los trabajadores beneficia o afecta al proceso?
Finalmente se formularon 24 variables del contexto, de las cuales solo el 37,5% estaban resueltas en el diseño actual del proceso. Algunos ejemplos de estas variables son:
Fluctuación del personal del cliente, lo que limita la eficiencia y sostenibilidad de los intercambios.
No existe claridad de los beneficios que genera un proyecto lo que dificulta la toma de decisiones.
Incremento de costos a causa de la ocurrencia de riesgos no planificados en los costos del proyecto.
La empresa cubre sus gastos con sus ingresos; cumple con los aportes destinados al Estado y reserva recursos para su propio desarrollo y beneficio.
3.4 Modelar el proceso de negocio
En este paso se procede a la modelación del proceso de “Generación de ofertas comerciales para proyectos de software”. Se consideraron los requisitos funcionales formulados para los dominios de la gestión comercial y gestión de proyectos, las variables del contexto cubano y del específico de la empresa, así como el modelo de referencia del sistema ERP ODOO 11.
En este paso se determinó el flujo de trabajo de referencia embebido en el sistema, pertinente al proceso objeto de estudio. Para ello se realizaron estudios de manuales del sistema, así como simulaciones del uso, identificando funcionalidades y flujos de trabajo del sistema con sus alternativas. La búsqueda de funcionalidades fue guiada por la necesidad de satisfacer requisitos funcionales. Como resultado se obtuvo el flujo de trabajo del sistema, el cual se desagregó en 43 reglas de referencia. Algunos ejemplos de estas reglas son las siguientes:
Una solicitud puede estar asociada a un cliente existente o un cliente potencial.
Una solicitud puede ser creada por el usuario a través del sistema interno.
Una solicitud puede ser creada por el cliente a través del sitio web corporativo.
Seguidamente se generó el modelo del proceso desde la dimensión de secuencia, utilizando el lenguaje de modelado BPMN. En la Fig. 4 se muestra dicho modelo, donde se resaltan las actividades relacionadas y justificadas por funcionalidades del sistema. También se especifican los requisitos funcionales que cada elemento del modelo de proceso resuelve. Para identificarlos se emplea la sigla REQ.
3.5 Chequear la calidad semántica del modelo de proceso de negocio
En la Fig. 5 se muestran los indicadores conceptuales del modelo del proceso relacionados con el conocimiento ontológico que debió ser considerado. En el caso presentado solo se modeló la dimensión de secuencia del proceso, lo cual representa 58.6% de todos los elementos de un proceso que deben ser considerados. Para el análisis de los aspectos del contexto solo fueron considerados 49.1% de los factores contextuales y partes interesadas, lo cual significa que en una próxima iteración del modelo es preciso abordar las perspectivas que en este caso no se tuvieron en cuenta, para mejorar la coherencia del proceso respecto a su realidad. En relación a la conceptualización funcional del proceso se cubrió el 94,7 % de los conceptos identificados, lo cual indica que los requisitos funcionales propuestos están acorde a las tendencias funcionales, por lo que pueden funcionar como guía para el modelado del proceso.
Por su parte en la Fig. 6 se muestran los indicadores conceptuales del modelo relacionados con el conocimiento situado. Atendiendo a los resultados, se puede concluir que el modelo de proceso propuesto cubre el 70,8% y 65,6% de las variables del contexto y requisitos funcionales, respectivamente. Ello indica que, aunque el modelo propuesto incorpora mejoras respecto al diseño actual, todavía existen brechas, que deben ser incorporadas para la mejora, en la medida que las condiciones organizacionales así lo permitan.
4. Conclusiones
La validez conceptual de los modelos de procesos de negocio constituye una preocupación de la literatura científica, ya que puede afectar las decisiones sobre el funcionamiento de las organizaciones que tienen a dichos modelos como base. El conocimiento conceptual relevante para el modelado de proceso de negocio en el alcance de la arquitectura empresarial fue agrupado en las tres dimensiones del MCPN: dimensión de elemento, que agrupa el conocimiento ontológico de procesos de negocio; la dimensión de restricciones, que agrupa el conocimiento ontológico asociado al dominio funcional en el que opera el proceso; y la dimensión de restricciones asociado al conocimiento situado del contexto. que justifica las soluciones de modelado de procesos en un momento específico. En base al MCPN, se presenta un método de modelado conceptual de procesos de negocio que ayuda a obtener modelos de procesos más consistentes con el conocimiento ontológico de procesos de negocio y más coherentes con las situaciones reales en las que el proceso se desenvuelve. El método fue aplicado en el proceso de generación de ofertas comerciales de una empresa proveedora de servicios de informatización. Como resultado, se pudo operar con el conocimiento conceptual que cubre el modelo de proceso de negocio obtenido, a través de indicadores a niveles ontológico y situado; los indicadores permiten cuantificar y gestionar la calidad de dicho modelo, al identificarse la brecha conceptual que aún falta considerar.
