INTEGRACIÓN DE UN MODELO DE REFERENCIA DE …todos los elementos del MRPGC en las fases...

“V Taller Internacional Las TIC en la Gestión de las Organizaciones”

INTEGRACIÓN DE UN MODELO DE REFERENCIA DE PROCESOS DE GESTIÓN DE CONOCIMIENTOS EN LA METODOLOGÍA DE

DESARROLLO DE SOFTWARE SCRUM

INTEGRATION OF A THE REFERENCE MODEL OF KNOWLEDGE MANAGEMENT PROCESSES IN THE SCRUM SOFTWARE DEVELOPMENT

METHODOLOGY

Royer David Estrada Esponda1,

1 Universidad del Valle, Colombia, [email protected]

RESUMEN: El conocimiento es el principal activo de las organizaciones que desarrollan software, en conse-cuencia dichas organizaciones están llamadas a emprender las acciones necesarias para posibilitar que dicho conocimiento transite de una dimensión individual a un conocimiento de naturaleza organizacional. La investiga-ción realizada posibilito la integración del Modelo de Referencia de Procesos de Gestión de Conocimiento y la metodología de desarrollo de software SCRUM, dicha integración tiene como propósito facilitar la Gestión de Conocimiento en los procesos de desarrollo de software y soporte a usuarios en compañías de la industria del software o equipos especializados de organizaciones que sin ser de dicho sector desarrollan y mantienen su propios sistemas informáticos. El método utilizado para la investigación tuvo un alcance exploratorio y descripti-vo, apelando por enfoques cualitativos y cuantitativos en una organización Colombiana, que siendo del sector de la Salud, desarrolla y soporta sus sistemas informáticos. Adicionalmente a la integración, el autor presenta un referente metodológico para su puesta en marcha. Finalmente, se destaca que la integración permitió incorporar todos los elementos del MRPGC en las fases características de la metodología SCRUM, bajo la sombrilla de factores habilitadores del propio Modelo de Referencia de Procesos y la administración de configuración del software.

Palabras claves: Gestión de Conocimiento, Ingeniería de Software, Soporte a usuarios, Modelo de Referencia de Procesos.

ABSTRACT: Knowledge is the main asset of organizations developing software; consequently these organiza-tions are called to take the necessary actions to enable that knowledge to move from an individual dimension to knowledge of an organizational nature. Research conducted enabled the integration of Reference Model Process Knowledge Management and development methodology SCRUM software, this integration aims to facilitate kno-wledge management in the process of software development and user support in companies’ software industry or specialized teams of organizations that, without being part of sector mentioned, develop and maintain their own computer systems. The method used for the research had an exploratory and descriptive scope, appealing for qualitative and quantitative approaches in a Colombian organization, which being of the Health sector, develops and supports its computer systems. In addition to the integration, the author presents a methodological reference for its implementation. Finally, it stresses that integration possible to incorporate all the elements of MRPGC in the characteristic phases of SCRUM methodology, under the umbrella of the own enablers Process Reference Model and configuration management software.

Estrada, R. “Integración de un Modelo de Referencia de Procesos de Gestión de Conocimientos en la metodología de desarrollo de Software SCRUM”


Keys words: Knowledge Management, Software Engineering, User Support, Process Reference Model.

1. INTRODUCCIÓN

El 54% de empresas en América Latina desarrollan su propio software [1], dichos desarrollos buscan soportar los procesos operativos e incluso procesos estratégicos al interior de las organizaciones.

Paralelamente, no utilizar herramientas TIC1 para apoyar la ejecución de las tareas operativas, así como soportar las estrategias organizacionales resultaría inapropiado en tiempos de cambios cons-tantes y regulaciones gubernamentales que oca-sionan frecuentes variaciones en la forma de pre-sentar la información, entrega de informes y demás actividades inherentes a las dinámicas productivas de las organizaciones.

En esta dirección se encuentran afirmaciones tales como: “Hoy en día, las empresas se enfrentan al hecho de sobrevivir a los constantes cambios tecno-lógicos, al mismo tiempo que atienden los deman-dantes y dinámicos requerimientos que implica la operación de un negocio” [1].

Por otro lado, y teniendo en cuenta la gran propor-ción de compañías que desarrollan su propios sis-temas informáticos o herramientas TIC, resulta imperioso destacar que el desarrollo de software requiere un uso intensivo del conocimiento, cuando esta actividad se desarrolla en forma colectiva para atender objetivos de la misión organizacional y sus procesos productivos, se convierte en objeto de estudio del campo de las Ciencias de la Administra-ción [2].

De igual manera, el proceso de desarrollo de soft-ware y las actividades de soporte a usuarios requie-ren además de procedimientos, herramientas y recursos técnicos, un personal profesional capaci-tado para posibilitar el desarrollo y mantenimiento efectivo de los sistemas de información, de igual modo requiere de individuos con las capacidades necesarias para realizar tareas de soporte a usua-rios, para este último particular, dichas novedades de soporte se presentan, por razones asociadas a defectos en la utilidad funcional de los sistemas informáticos, que están claramente relacionados con el proceso de ingeniería de software que se lleva a cabo, pero también asociados a errores o dudas de los usuarios en la utilización de dichos

1 Tecnologías de la información y la comunicación

sistemas.

Con base en lo anterior, y teniendo en cuenta que el personal es uno de los recursos fundamentales para el adecuado desenvolvimiento de las activida-des específicas de desarrollo de software y soporte a usuarios, preocupa que para el caso de Colombia el déficit de profesionales en Ingeniería de software y afines asciende a una cifra de 15.000 vacantes [3], lo cual sin lugar a dudas invita a reflexionar a las compañías en cómo capitalizar el conocimiento de dicho círculo de profesionales, anticipándose a di-námicas propias del mercado, específicamente la oferta y la demanda, de hecho, se considera que desde el 2016 el problema de escasez de talento TI2 crece exponencialmente3. Paralelamente se encuentra información con proyecciones similares sobre la realidad de tal sector, en la medida que se prevé que para el 2018 el déficit llegará a 90.000 vacantes [4].

Con base en lo anterior, “no prestar suficiente aten-ción a la GC en la industria de software sería equi-valente a que la gestión del dinero no fuese una prioridad para los bancos y demás empresas del sector financiero” [5], lo cual aplica también para organizaciones que sin ser de dicha industria cons-truyen sus propias soluciones informáticas.

Asimismo, y teniendo en cuenta que la Gestión de Conocimiento (GC) otorga valor a las compañías en la medida que dicha gestión permite la capitaliza-ción del recurso más valioso para las empresas, y además que existe una clara diferencia entre los sistemas de información y los sistemas de gestión de conocimiento, debido a que los primeros recopi-lan los flujos de procesos al interior de las organiza-ciones, mientras que los segundos proveen infor-mación en contexto para apoyar a los agentes deci-sores en la realización de sus tareas [6], resulta conveniente presentar los resultados de la investi-gación documentada en [7], donde se expone la integración del Modelo de Referencia de Procesos de Gestión de Conocimiento versión 1.0 (MRPGC v 1.0) propuesto en [5] y la metodología de desarrollo de software SCRUM descrita en [8].

Dicha integración se tradujo en un modelo de GC

2 El término TI es indistinto al término TIC 3http://www.fiti.gov.co/Images/Recursos/brecha-de-

talento-digital-en-colombia-infosys-eafit.pdf

http://www.fiti.gov.co/Images/Recursos/brecha-de-talento-digital-en-colombia-infosys-eafit.pdfhttp://www.fiti.gov.co/Images/Recursos/brecha-de-talento-digital-en-colombia-infosys-eafit.pdf



para la formalización, el aprendizaje, trasmisión, cuidado y aprovechamiento del conocimiento inhe-rente a los procesos de desarrollo de software y soporte a usuarios llevados a cabo en organizacio-nes desarrolladoras de software (ODS) u organiza-ción que sin ser de dicho sector desarrollan sus propios sistemas informáticos a la medida o herra-mientas TIC de diversa naturaleza para apoyar su operación y/o estrategia organizacional.

En esa dirección, el presente documento expone inicialmente una breve síntesis conceptual, luego presenta la metodología que posibilito la integración del modelo de referencia de procesos y la metodo-logía de desarrollo de software mencionados ante-riormente en un contexto productivo particular, des-pués expone el modelo de GC en detalle y el marco metodológico propuesto para su incorporación, fi-nalmente se presentan las conclusiones producto de la integración mencionada.

2. MARCO CONCEPTUAL

En [9] se define la Gestión de Conocimiento como la capacidad de administrar eficazmente los flujos de conocimiento al interior de la organización para garantizar su acceso y reutilización permanente, con lo cual se estimula la innovación, la mejora de los procesos de toma de decisiones y la generación de nuevos conocimientos.

Además, se encuentra que “la gestión del conoci-miento ha significado un cambio de paradigma en la implementación de estrategias innovadoras para la obtención de ventajas competitivas que garanticen la sostenibilidad de las empresas en un mundo ca-racterizado por la incertidumbre y el cambio cons-tante” [9].

Adicionalmente en [10] se encuentra que la defini-ción de Gestión de Conocimiento aún está incom-pleta y es objeto de discusión por comunidades académicas. Sin embargo, en dicho trabajo se en-cuentra que tal constructo puede ser definido como un conjunto de procesos sistemáticos (identificación y captación del capital intelectual; tratamiento, desa-rrollo y compartimiento del conocimiento; y su utili-zación) orientados al desarrollo organizacional y/o personal y, consecuentemente, a la generación de una ventaja competitiva para la organización y/o el individuo.

Con base en lo anterior, se destaca que a pesar que el concepto no está claramente definido y más bien se apela por enfoques reduccionistas cuando a él se refieren, hay una característica o consecuen-cia claramente identificada y tiene que ver con la obtención de ventajas competitivas gracias a la transformación de conocimientos individuales en

conocimientos organizacionales.

Por otro lado, debido a que en el ámbito del desa-rrollo del software continuamente se busca elaborar productos de mayor calidad con el propósito de aportar al logro de ventajas competitivas, generar una mayor satisfacción en clientes, ya sean internos o externos y aportar a las metas, programas y pla-nes estratégicos establecidos por las organizacio-nes que lo utilizan, aparece el concepto de Modelos de Referencia de Procesos (MRP), estos son mar-cos de trabajo aceptados y usados por ODS con el fin de soportar sus prácticas y costumbres organi-zacionales, incluso en [5] se menciona que dichos modelos son utilizados por la industria de software para el diseño, implementación, evaluación y mejo-ra de los procesos de las organizaciones, pues es-tos contienen la especificación de los procesos que deberían implementarse para lograr mayores nive-les de capacidad y madurez.

En consonancia con lo anterior, en [5] se propone un MRP en el ámbito de la GC para ODS en el con-texto Colombiano. La Tabla I presenta cada uno de los elementos de dicho MRP con el propósito de poner en contexto al lector en relación con uno de los componentes que fue parte de la integración presentada en este trabajo.

Tabla I: Elementos del MRPGC V1.0

Proceso Descripción

Identificación de Conoci-miento

Mantener registros actualizados con datos de identificación de los conoci-mientos organizacionales y del entorno que sean relevantes para la generación de valor en la organización.

Aplicación de Conocimiento

Utilizar los conocimientos organizacio-nales, capacidades de las personas o equipos de trabajo y conocimiento codificado, para generar valor en la organización.

Evaluación de Conocimiento

Definir necesidades y metas de desa-rrollo del conocimiento organizacional con base en mediciones periódicas de su estado, resultados, efectos e impac-to sobre la organización.

Transferencia de Conoci-miento

Proporcionar los conocimientos organi-zacionales necesarios para satisfacer necesidades de conocimiento de per-sonas o equipos de trabajo dentro de la organización, o de organizaciones del entorno.

Adquisición de Conocimiento

Obtener conocimientos en el entorno que sean relevantes para la organiza-ción.

Creación de Conocimiento

Producir conocimientos relevantes para la generación de valor en la organiza-ción.

Codificación Construir unidades de conocimiento



de Conoci-miento

codificado de diversa naturaleza, es-tructura, contenido y formato; en las que se registran, sistematizan, combi-nan, expresan, representan o docu-mentan los conocimientos organizacio-nales para facilitar su organización, clasificación, almacenamiento, locali-zación y uso.

Protección de Conocimiento

Evitar pérdidas, usos ilegales o no autorizados de los conocimientos orga-nizacionales, con la implementación de medidas de protección y control.

Además de la presentación explicita de cada uno de los propósitos de los elementos del MRPGC v1.0, en [5] se menciona la relación entre componentes y los factores habilitadores de los mismos, que garan-tizan en alguna medida su incorporación en la orga-nizaciones que deseen usar tal modelo.

Por otra parte, el MRPGC fue construido para ser usado en contextos de determinación de capacida-des de procesos o en mejora de procesos de GC en el ámbito organizacional o de unidades dentro de una organización [10], lo cual implica que es aplica-ble en áreas funcionales que desarrollan software a la medida para las organizaciones a la que pertene-cen.

Finalmente, SCRUM fue propuesta por Ken Sch-waber de manera conjunta con Jeff Shuterland, además dichos autores fueron parte de los firman-tes del manifiesto de desarrollo ágil, de igual modo también han mejorado y extendido la versión inicial de SCRUM para empresas desarrolladoras de soft-ware y organizaciones TI. En [8] se describen las siguientes fases de SCRUM:

Pre-juego

Juego

Pos-juego

La primera fase consiste en la definición de la nue-va versión de un producto o sistema basado en el conocimiento que se tiene de los requisitos de los clientes, además permite la estimación del plan y su costo, por otra parte en la misma fase y a la luz de la arquitectura del sistema se diseña cómo los re-querimientos de los clientes serán implementados para la satisfacción de nuevos escenarios de nego-cio, que una vez sistematizados redundaran en la operación de las organizaciones o en el cumpli-miento de las metas que motivaron un nuevo desa-rrollo de software. En la fase de Juego se desarrolla una nueva versión funcional del sistema, software o herramienta TIC, teniendo en cuenta variables como el tiempo, los

requerimientos, la calidad, los costos y la compe-tencia, la interacción con estas variables define el final de cada fase, Además existen múltiples es-fuerzos que generalmente son iterativos e incre-mentales para dotar paulatinamente al sistema de las capacidades previstas para solucionar un pro-blema, satisfacer una necesidad o aprovechar una oportunidad.

Finalmente, la fase de Pos-juego consiste en la preparación de la versión, compilar la documenta-ción final y realización de pruebas en escenarios pre-productivos.

3. CONTENIDO

2.1 Metodología

Teniendo como principio que la GC es una variable dependiente y que el propósito de la presente inves-tigación requirió conocer las variables independien-tes que la determinan en un escenario particular, se inició esta investigación por una etapa de explora-ción, de hecho en [12] se mencionan que la investi-gación exploratoria tiene entre otros objetivos abor-dar un problema de investigación poco estudiado o problemas que nunca han sido objeto de estudio, para el contexto particular donde se desarrolló la investigación, no se encontró ningún estudio sobre el conocimiento que circula alrededor de los proce-sos de desarrollo de software y soporte a usuarios, con el fin de poder establecer si era necesario adoptar un modelo de GC. También, en [13] se menciona que uno de los propósitos de la investiga-ción exploratoria es posibilitar el diagnóstico de una situación.

Al mismo tiempo, se desarrolló una investigación cuantitativa y cualitativa, en la medida que se utili-zaron instrumentos de recolección de información en el marco de ambos métodos, tales como en-cuestas semiestructuradas con análisis cualitativos de resultados, por medio de la utilización de escalas tipo Likert; adicionalmente, se usaron los 8 proce-sos y las 40 variables del MRPGC v 1.0 como ins-trumento de valoración cualitativa, para la evalua-ción de los procesos del área funcional donde se desarrolló la investigación, con el propósito de esta-blecer la situación actual en relación con la gestión de conocimiento antes de proponer un modelo para ello.

La combinación de los dos métodos buscó sacar provecho de sus bondades y atender dos escena-rios diferentes, primero, el determinar cuál es la percepción sobre los trabajos que se realizan por el equipo encargado de desarrollar software y brindar soporte a usuarios, para ello se definieron variables



relacionadas con la inducción, el soporte a usuario y el mantenimiento o desarrollo de los sistemas in-formáticos. En segundo lugar, con la evaluación o auditoria del área se conoció de manera detallada cuál es la realidad de los procesos a la luz de la GC, así como sus productos o evidencias relacionadas; adicionalmente, otra razón para su combinación fue que “los dos métodos pueden vigorizarse mutua-mente, brindando cada uno lo que el otro no puede dar” [12].

En consecuencia con lo anterior y atendiendo a las siguientes precisiones:

La investigación cualitativa trata de identificar la naturaleza profunda de las realidades, su sistema de relaciones, su estructura dinámica. La investiga-ción cuantitativa trata de determinar la fuerza de asociación o correlación entre variables, la generali-zación y objetivación de los resultados a través de una muestra para hacer inferencia a una población de la cual toda muestra procede [14].

Es pertinente mencionar que se contempló utilizar el método cuantitativo con el ánimo de generalizar cuál es la percepción de los empleados de la orga-nización, sobre la labores realizadas en el área fun-cional donde se desarrolla software y se da soporte a usuarios, por otra parte desde la óptica cualitativa se conoció en detalle cuales son los procesos desa-rrollados por los funcionarios en dicha área y cómo estos últimos entienden la influencia de la GC en tales procesos.

Una vez finalizó la etapa exploratoria de la investi-gación, y por ende se tuvo un diagnóstico sobre las costumbres y prácticas orientadas a la GC en los procesos de desarrollo de software y soporte a usuarios, se dio inicio a una etapa descriptiva, la cual consistió en la recopilación de datos que des-criben los acontecimientos y luego organiza, tabula, representa y describe la recopilación de datos [13].

Paralelamente, en [13] también se encuentra que la descripción surge después de una exploración crea-tiva, por tanto se describió la realidad del área fun-cional de una organización de la salud sin ningún tipo de manipulación de las variables que allí se

identificaron, con el fin de comprender el estudio cualitativo y sus implicaciones; por lo anterior, en esta etapa de la investigación se realizó una revi-sión documental y observación participante que fue posible gracias a la experiencia del investigador en componentes de desarrollo de software y como estos se ponen en marcha en una ODS, así pues se verificaron repositorios, entornos de desarrollo y los procedimientos realizados por los colaboradores.

Por otra parte y una vez se finalizó la etapa descrip-tiva, se procedió a iniciar nuevamente una explora-ción con el fin de determinar las variables a consi-derar para la construcción del plan de incorporación del modelo de GC resultante. Esto último porque se consideró importante prever la ruta de incorporación respetando las características, restricciones y políti-cas de la organización y el área donde se aplicó el estudio. La Figura 1 ilustra el esquema de la inves-tigación.

Adicionalmente y con el propósito de estructurar la investigación se establecieron 3 fases, cada una de ellas esta descrita en la Figura 2 y además señala la relación de cada una de las fases con cada uno de los enfoques investigativos presentados en la Figura 1.

Figura. 1: Enfoque de la investigación



Figura. 2: Fases de la investigación

Las fases de la investigación dan cuenta de un en-foque sistémico con el fin de propiciar la reproduc-ción de iniciativas que busquen hacer uso del MRPGC v1.0 en sus dinámicas productivas en rela-ción con el desarrollo de software y la asistencia o soporte a usuarios, sin embargo vale la pena desta-car que en el contexto donde se realizó la investiga-ción no fueron identificados modelos de GC en ope-ración, aunque si, herramientas TIC para la codifi-

cación de conocimiento en repositorios centraliza-dos. La Tabla II señala el marco lógico de la investi-gación, donde se destaca principalmente, cada una de las actividades, herramientas y técnicas utiliza-das para poder integrar el MRPGC v1.0 y la meto-dología de desarrollo SCRUM en un área específica que desarrollo software a la medida y es responsa-ble de la asistencia o soporte a usuarios.

Tabla III: Marco Lógica de la investigación

Enfoque Fase

Evaluación Modelado Incorporación

Exploratorio

Observación parti-cipante

Revisión docu-mental

Verificación de procedimientos

Consulta a exper-tos (colaboradores del área)

Uso del MRPGC v1.0 para evaluar el estado de GC en el área

Diseño estadístico

Instrumento de va-loración de per-cepción

Realimentación cons-tante

Consulta a expertos

Descriptivo

Tabulación de resulta-dos

Análisis de resultados

Consulta a expertos (in-ternos y externos)

Análisis Jerárquico de

Revisión documental

Verificación de procedimientos

Elaboración del plan metodoló-gico para la incorporación.



Procesos (AHP)

Elaboración del modelo

Resultado

Diagnóstico del estado actual de GC en el área objeto de estudio

Modelo de GC Plan de incorporación del modelo de GC conforme a las políticas, restricciones y características del área objeto de estudio

En [5] se encuentra cómo el MRPGC v1.0 fue usa-do en un estudio exploratorio en ODS con el propó-sito de conocer el estado de los procesos de GC en ODS Colombianas. Así pues, dicho referente fue indispensable para diagnosticar el estado de los procesos de GC en un área específica, sobre todo cuando en [10] se comenta que el modelo no sólo es aplicable a ODS, sino también para grupos de desarrollo específicos, esto se traduce en una exce-lente alternativa para ese 54% de empresas Lati-noamérica que desarrollan sus propias soluciones informáticas o herramientas TIC.

Además, desde lo metodológico se aporta a los planteamientos encontrados en [5], en relación con la necesidad que según dicha investigación implica llevar a cabo estudios piloto con el MRPGC a nivel interno de las organizaciones, con el propósito de contar con referentes metodológicos que brinden elementos concretos para ayudar a las empresas en la implementación de los procesos.

Una vez se conoció el estado actual de los procesos de GC en el área objeto de estudio, fue necesario usar una herramienta para apoyar la toma de deci-siones sobre cómo debería integrarse cada uno de los procesos en el marco metodológico SCRUM, de hecho en [5] se menciona que “la asignación de prioridades para implementar los procesos de GC no reveló acuerdos significativos entre los partici-pantes, con excepción del proceso de Identificación de Conocimiento”, por tanto se menciona que resul-ta necesario abordar trabajos futuros con el fin de determinar un “orden sugerido de implementación”.

Por lo anterior se usó el análisis jerárquico de pro-cesos (AHP) con el fin de conocer objetivamente qué tan importantes resultaron ser cada uno de los procesos del MRPGC para los colaboradores del área objeto de estudió [15].

Finalmente, la evaluación de la percepción, para la cual fue fundamental el enfoque cuantitativo, nece-sario realizar un diseño estadístico y elaborar un instrumento de recolección de información, servirá como métrica para posibles evaluaciones Ex-pos en

profundidad, con el propósito de valorar la mejora de los procesos una vez el modelo de GC sea apropiado por grupos específicos que usen un en-foque ágil de desarrollo de software.

La evaluación de la percepción no es un requisito para la integración del MRPGC V.1.0 en un marco metodológico de desarrollo de software específico; sin embargo, resultó valiosa para proponer un inte-gración en la medida que se obtuvo información sobre debilidades y fortalezas del grupo, unidad o área objeto de estudio y como estas podrían ser reducidas y potenciadas desde la mejora de proce-sos que se prevé con la implementación de un mo-delo de GC.

2.2 Resultados

Con base en la metodología SCRUM, la evaluación de un contexto específico por medio del MRPGC v. 1.0, los datos sobre la percepción que tienen los clientes sobre dicho contexto, la revisión bibliográfi-ca realizada y teniendo en cuenta que la GC contri-buye a la materialización de procesos de mejora-miento continuo que conducen a su vez a la obten-ción de ventajas competitivas, se propuso el si-guiente modelo para la gestión de conocimiento.

El modelo presentado en la Figura 3 muestra una clara simbiosis entre la metodología de desarrollo de software SCRUM y el MRPGC v. 1.0, en conse-cuencia, el modelo propuesto está compuesto por 3 componentes y 8 elementos, los primeros asocia-dos a las fases de la metodologías SCRUM y los segundos correspondientes a los procesos del MRPGC v 1.0. Adicionalmente dichos componentes y elementos están soportados por los factores habi-litadores del MRPGC v 1.0 y la Administración de la Configuración del Software (ACS), esta última se-gún [16] es una actividad sombrilla, puesto que eventos de cambio pueden ocurrir en cualquier momento y por tanto se deben desarrollar activida-des a la luz de la identificación del cambio, su con-trol, su implementación de manera adecuada y su reporte a todos los interesados.


Figura. 3: Modelo de GC

Un componente adicional para soporte a usuarios se incluye justo después de la fase de pos-juego, debido a que en dicha fase se desarrolla lo que se conoce como lanzamiento final, es decir, el software es puesto en operación. A continuación se descri-ben cada uno de los elementos y los componentes del modelo.

2.2.1 Componentes del modelo

Pre juego: Consiste en la identificación de estánda-res y tecnologías a utilizar en el desarrollo o satis-facción de una necesidad de software, adicional-mente es indispensable para alinear los objetivos del área o grupo desarrollador a la luz de sus solici-tudes, con los objetivos organizacionales por medio de la planeación, con el fin de generar valor por medio de la priorización de actividades y necesida-des a satisfacer.

Juego: En este componente se concentran las actividades técnicas orientadas al cumplimiento de los objetivos del área o grupo desarrollador, dichas actividades son entonces la codificación de rutinas o programas, análisis y diseño de pruebas y el se-guimiento de rituales o rutinas de entregas y reali-mentaciones constantes. Para este último particular se debe tener en cuenta que las metodologías de desarrollo de software como SCRUM generalmente se adaptan a las necesidades del equipo desarro-llador y en consecuencia deben surtir procesos de refinamiento y maduración para efectivamente adaptarse a la realidad de un área o grupo especí-

fico.

Pos-Juego: En este componente se cuenta con nuevas funcionalidades o funcionalidades actualiza-das a partir de mantenimientos para mejora, adicio-nalmente se genera documentación, procesos de integración y pruebas finales de las funcionalidades nuevas o actualizadas. En consecuencias se genera el escenario para la codificación de conocimientos en unidades de conocimiento previamente construi-das, adicionalmente se facilita la creación de cono-cimiento de naturaleza organizacional y se promue-ve la adquisición de conocimiento que previamente ha sido evaluado. Finalmente y después del proce-so de evaluación se determina qué medidas de control y protección son añadidas al conocimiento que lo requiera.

Soporte: Una vez nuevas funcionalidades o fun-cionalidades actualizadas son liberadas, se em-prenden actividades de soporte o apoyo al software, la cual consiste en disponer de un conjunto de acti-vidades de ingeniería de software “que ocurren después de que éste se entregó al cliente y de que se puso en operación” [16].

2.2.2 Elementos y su relación con los componentes

Una vez los procesos del MRPGC fueron incluidos de forma explícita en la dinámica metodológica



SCRUM, se materializa un nuevo marco de trabajo para adelantar actividades de desarrollo de software y la mejora de actividades referentes al soporte a usuarios, por ello, a continuación se describen cada uno de los elementos del modelo en el contexto de dicho marco.

Identificación: Consiste en la identificación del conocimiento relevante para el área, incluyendo problemas asociados al funcionamiento de los sis-temas informáticos para proceder a catalogar las acciones y por ende poner en contexto las acciones de los componentes sucesores. Ubicado en el componente de pre-juego porque en dicho compo-nente es donde se planifica las actividades a desa-rrollar, la priorización de las mismas y por tanto la identificación de conocimiento técnico y meta cono-cimiento resultan fundamentales para los compo-nentes sucesores.

Aplicación: Consiste en la aplicación de conoci-miento de individuos o equipos de trabajo con el ánimo de cumplir los objetivos propuestos, ubicado en el componente juego, porque en dicho compo-nente es donde se realizan las actividades de desa-rrollo o mantenimiento de software, así como las actividades relacionadas con diseño y pruebas de software.

Transferencia: La transferencia de conocimiento depende de su naturaleza, si este se encuentra codificado en unidades de conocimiento se debe establecer procedimientos para su consulta, sino es así la interacción entre individuos aportará a la difusión del conocimiento, en ambos casos el cono-cimiento deberá ser evaluado para determinar si añade valor al área. Se ubica en el componente de juego porque es aquí donde la metodología SCRUM plantea reuniones o feedbacks para la realimenta-ción e incluso evaluación de estado actual de los objetivos y adicionalmente porque es donde se apli-can capacidades individuales y grupales.

Evaluación: Consiste en determinar si el conoci-miento está alineado con los objetivos y propósitos del área o grupo desarrollador, para este particular deben establecerse métricas o indicadores que permitan evaluar ello. Ubicado en la etapa de juego porque es necesario para la transferencia de cono-cimiento y necesita de la aplicación del mismo para identificar si efectivamente es coherente con los objetivos del área. Lo anterior permitirá definir me-tas de desarrollo de conocimiento.

Codificación: Consiste en la construcción de uni-dades de conocimiento que posibiliten el almace-

namiento, clasificación y posterior localización del conocimiento organizacional, si dichas unidades conocimiento existen en la actualidad deben enton-ces usarse para tal fin. Ubicado en el componente pos-juego porque es allí donde después de la eva-luación realizada en la etapa predecesora hay cer-teza sobre qué conocimiento debe ser objeto de codificación o no.

Creación: Consiste en la creación de conocimiento que añada valor al área o la actualización de cono-cimiento existente a partir de las experiencias susci-tadas por los individuos o grupos de trabajo en el componente juego. Dichos conocimientos deben atender necesidades de conocimiento identificadas en procesos de evaluación y por ello este elemento se ubica en el componente de pos-juego, ya que allí es posible identificar tales características y las ac-ciones o pasos necesarios para crear efectivamente conocimiento.

Protección: Consiste en la agregación de medidas de protección y control a todo el conocimiento que sea susceptible de ello, para identificar si es nece-saria la protección se debe atender los resultados del proceso de evaluación, en tal momento será posible identificar si es relevante o no añadir tales controles para evitar usos desaconsejados, indebi-dos y pérdidas del conocimiento. Se ubica en el componente de pos-juego porque es allí donde se conoce con mayor nivel de detalle si se cumplen o no las características para añadir protección o con-trol a cierto tipo de conocimiento. Aquí se podría considerar añadir por ejemplo: medidas de autenti-cación, copias de seguridad, creación de perfiles, agregación de medidas de control físico, etc.

Adquisición: Consiste en apropiar conocimientos del entorno que sean significativos para el área, en este caso dicho conocimiento puede ser traducido en meta-conocimiento o conocimiento propiamente técnico, en cualquier caso es necesario evaluar el conocimiento con el fin de determinar si el conoci-miento a apropiar realmente está asociado con metas de desarrollo del conocimiento y por tanto otorga el valor esperado al área. Por lo inmediata-mente anterior este elemento se ubica en el com-ponente pos-juego.

Todos los elementos que forman parte del modelo son significativos para el componente soporte, lo anterior ya sea porque las actividades desarrolladas en cada uno de los componente pueden ser en sí solicitudes de soporte a la luz del mantenimiento del software o porque cada uno de los elementos gene-ra valor para el área por medio de cada una de sus características y productos de conocimiento, lo cual



se traducirá en un mejor servició para todos los clientes de los servicios en ejecución.

2.2.3 Factores habilitadores del MRPGC v 1.0 y ACS

Cada uno de los elementos según el MRPGC v. 1.0 cuentan con factores habilitadores que posibilitan su efectiva materialización, a continuación se presen-tan los factores comunes en todos los elementos:

Cultura organizacional: Como bien se señala en [5] muchos modelos de referencia de procesos se limitan a desarrollar iniciativas a la luz de la GC sin considerar todas las capacidades organizacionales de GC que existen, en consecuencia podría decirse que la GC de dichos MRP corresponden a una GC de primera generación, es decir se limitan a em-prender actividades para su captura, almacena-miento y localización y no consideran que la cultura organizacional debe brindar un ecosistema adecua-do que genere confianza, el establecimiento de una cultura clara, una comunicación abierta y una filoso-fía de colaboración y apoyo [17].

Liderazgo: En [17] se comenta que el liderazgo es un factor organizacional que influye significativa-mente en la GC, en consecuencia planten dos esti-los de liderazgo, uno de corte más flexible y pros-pectivo y otro de naturaleza rígida e impositiva. Los autores indican que la selección de un enfoque u otro depende de los aspectos de GC de conoci-miento que se quieran potencializar. Por tal motivo el área, sin desconocer su estructura debe aplicar dependiendo de sus necesidades de conocimientos enfoques que posibiliten la organización de colabo-radores auto-gestionados de forma parcial o total; o en caso contrario adoptar posiciones fijas para el establecimiento de metas a la luz de las GC.

Soporte de la alta dirección: Todos los factores que influyen en la constitución de una GC, tales como la cultura organizacional, el liderazgo, la es-tructura de la organización y otros, requieren que la alta dirección comprenda que sin su respaldo tales factores no serán fructuosos en la materialización de una GC que permita entonces la plena gestión del recurso más importante de las organizaciones en la sociedad a la que asistimos, es decir, el cono-cimiento.

Otros factores están asociados a cada uno de los procesos, o en el contexto de esta investigación a los elementos del modelo, por tal motivo es indis-pensable contar con MRP para que sirva de guía en la aplicación y puesta en marcha del modelo aquí presentado.

Por otra parte, la ACS reúne capacidades tecnológi-cas y de conversión, de hecho el análisis en [5] señala con claridad que los MRP que consideran tales procesos a la luz de una GC coinciden en dichas capacidades.

En consecuencia, es posible apreciar que la ACS facilita la identificación del conocimiento que debe ser transferido (Tecnología) y la forma en la que debe ser organizado y estructurado de manera tal que se facilite su distribución y uso dentro de la organización (Conversión), así pues, se destaca que el grupo encargado del desarrollo en donde se realizó la investigación cuenta con un sistema de control de versiones para todo lo relacionado con la programación de los sistemas informáticos, pero es preciso mencionar que la ACS no sólo hace refe-rencia a este tipo de controles, dicho de otra mane-ra, el control de versiones es una parte de la ACS, y por ende es necesario comprender como bien se dijo en la presentación del modelo que la ACS es una actividad “sombrilla” que es trasversal a todo el proceso de ingeniería de software y sólo acabaría si dicho software sale de operación.

2.2.4 Dinámica para incorporar el modelo de gestión de conocimiento pro-puesto

Una vez el modelo de GC fue definido, se procedió a identificar qué variables deben ser tenidas en cuenta para su posterior implementación y constan-te evaluación. La Figura 4 expone la estrategia de incorporación que consiste en cuatro fases, la pri-mera de ellas relacionada con el diagnóstico del estado actual de GC, la segunda y tercera relacio-nadas con actividades de preparación e incorpora-ción, y finalmente como cuarta fase la constante e iterativa evaluación de los procesos que influyen en la GC en la labores de desarrollo de software y so-porte a usuarios.


Figura. 4: Metodología para la incorporación del GC

4. CONCLUSIONES

El modelo propuesto integra la metodología de desarrollo de software SCRUM y el MRPGC v 1.0 en un solo modelo, por tanto se hace un aporte innovador y creativo a la comunidad académica y sobre todo a los equipos de desarrollo de software pertenecientes a ODS que constantemente están en busca de iniciativas y actividades de mejora para la maduración de sus procesos.

También, es pertinente comentar que a pesar que el MRPGC v. 1.0 está orientado tanto a ODS, como a áreas al interior de organizaciones no dedicadas precisamente a ello, fue necesario y seguramente será necesario para estudios futuros, la contextuali-zación del instrumento de evaluación del estado de implementación de procesos de GC, con el fin de lograr una mayor comprensión y garantizar una mejor consistencia y análisis de sus resultados.

Por otra parte, la revisión bibliográfica permitió iden-tificar que la GC en ODS es un tema de discusión y con gran variedad de aportes desde diferentes perspectivas, así pues, fue posible comprender los sesgos de los MRP convencionales y más utilizados en la actualidad en relación con los procesos de GC, ya que dichos modelos de referencia entienden el conocimiento desde una óptica instrumental (GC

de primera generación) y no abordan la GC desde la mirada del capital humano (GC de segunda gene-ración) y desde el significado del capital humano e instrumental (GC de tercera generación).

De igual modo, la investigación que se desarrolló puede servir como elemento de referencia para ODS de diferente naturaleza que quieran implemen-tar los procesos del MRPGC v. 1.0 en sus organiza-ciones, teniendo como agregado que en el contexto de la presente investigación se utilizó una metodo-logía de desarrollo ágil, enfoque mayoritariamente aceptado y utilizado en la industria del software.

Finalmente y a pesar que el diagnóstico realizado al área de trabajo objeto de estudio mostró que no se están cumpliendo completamente con los procesos de GC propuestos en el MRPGC v 1.0, es necesario destacar que en dicha área siguen en la actualidad un método que indudablemente otorga resultados positivos (según el ejercicio de determinación de la percepción realizado) para la operación de la com-pañía. Sin embargo, es indispensable considerar este trabajo como un referente para la mejora con-tinua y la maduración de sus procesos, con el áni-mo de regularizar indicadores, aumentar los niveles de desempeño y mejorar continuamente la satisfac-ción de los clientes o usuarios de las soluciones informáticas o herramientas TIC a la medida.



5. AGRADECIMIENTOS

El ejercicio investigativo que concluyó en formula-ción de un modelo de Gestión de Conocimiento no hubiera sido posible sin el apoyo de la Clínica San Francisco S.A del municipio de Tuluá en el Valle del Cauca, Colombia; gracias a dicha compañía fue posible proponer el modelo. De igual modo el ejer-cicio se facilitó gracias a la ayuda de la Universidad del Valle, específicamente el programa de posgrado de Maestría en Administración, sin su ayuda, infra-estructura y docentes no hubiera sido posible desa-rrollar las habilidades para entender las implicacio-nes de un estudio como el presentado en esta po-nencia.

6. REFERENCIAS BIBLIOGRÁFICAS

1. Medina, C.: Desarrollo interno de software: Una alternativa para optimizar su inversión en TI. IDC Vendor Spotlight, (13096). México, 2013.

2. Carrillo, L. y Orozco, O.: La administración de conocimientos en las organizaciones que desa-rrollan sistemas de información: Análisis de la con-cepción de conocimiento. XVII Congreso Interna-cional de Contaduría, Administración e Informática. México, D.F., México, 2012.

3. Correa, T.: Preocupante déficit de Ingenie-ros en Colombia. ElTiempo.com. Recuperado de: http://www.eltiempo.com/estilo-de-vida/educacion/panorama-de-los-ingenieros-en-colombia/16402298. 2015.

4. Molano, D.: Industria de las TIC necesita más ingenieros. Revista Dinero. Recuperado de:http://www.dinero.com/pais/articulo/mercado-laboral-ingenieros-sistemas-colombia/199380. 2014.

5. Galvis, E.: “Modelo de Referencia de Pro-cesos de Gestión de Conocimiento aplicable a Or-ganizaciones Desarrolladoras de Software del Con-texto Colombiano”, Tesis de doctorado. Universidad Nacional de Colombia, Bogotá, Colombia, 2015.

6. Meroño, A.: Tecnologías de información y gestión del conocimiento: integración en un sistema. Revista Economía Industrial. pp. 107 - 116, 2004.

7. Estrada, R.: “Modelo de gestión de cono-cimiento para los procesos de desarrollo de softwa-re y soporte a usuarios en la clínica san francisco S.A de Tuluá”, Tesis de maestría, Universidad del Valle, Tuluá, Colombia, 2017.

8. Schwaber K.: SCRUM Development Pro-cess. Springer-Verlag, London, 1997.

9. Angulo, R.: “Gestión del conocimiento y aprendizaje organizacional: una visión integral”, Informes Psicológicos, 17(1), pp. 53 - 70, 2017. http://dx.doi.org/10.18566/infpsic.v17n1a03

10. Rodríguez, D.: Modelos para la creación y

gestión del conocimiento: una aproximación teórica. Educar, Barcelona, España. ISSN: 0211-819X, 2006.

11. Galvis, E.: Modelo de Referencia de Pro-cesos de Gestión de Conocimiento para Organi-zaciones Desarrolladoras de Software de Colombia MRPGC v 1.0, 2015.

12. Cazau, P.: Introducción a la Investigación en Ciencias Sociales. Tercera ed. Buenos Aires, Argentina, 2006.

13. Abreu, J.: Hipótesis, Método & Diseño de Investigación. Daena: International Journal of Good Conscience, 7(2), pp. 187-197, 2012.

14. Fernández, S y Pértegas, S.: Investigación cuantitativa y cualitativa. Unidad de Epidemiología Clínica y Bioestadística, TR: CAD ATEN PRIMARIA, La Coruña, España, 2002.

15. Estrada, R.: “Análisis jerarquico de pro-cesos para la implementación de un modelo de referencia de procesos de gestión de conocimiento en el ámbito del desarrollo de software”, artículo en sometimiento, 2017.

16. Pressman, R.: Ingeniería de Software, un enfoque práctico. México, México: McGraw-Hill In-teramericana. Séptima edición, 2010.

17. Encalada, J., Mercado, L. y Ojeda, Ruth.: Propuesta de un instrumento para conocer las acti-vidades de gestión del conocimiento y los factores organizativos que la influyen. XVII Congreso Inter-nacional de Contaduría, Administración e Informáti-

ca. México, D.F., México, 2013.

7. SÍNTESIS CURRICULAR DEL AUTOR

R.D. Estrada-Esponda, recibió el título de Tecnólogo en Siste-mas de Información e Ingeniero de Sistemas en la Universidad del Valle de Colombia, en los años 2011 y 2014 respectiva-mente; Adicionalmente es Magíster en Administración de la misma institución de educación superior, actualmente se desempeña como profesor ocasional tiempo completo en la universidad del Valle sede Tuluá y es desarrollador de software con una experiencia laboral de más de 3 años en dicha activi-dad. Pertenece al programa interinstitucional para el fortaleci-miento de la investigación y el posgrado del pacífico como in-vestigador y además fue instructor nacional seleccionado para los Clubes de Ciencia de Colombia 2017. Sus intereses en investigación incluyen la Ingeniería de Software, Gestión del Conocimiento, Educación y User Experience. ORCID: 0000-0002-6849-1278

http://www.eltiempo.com/estilo-de-vida/educacion/panorama-de-los-ingenieros-en-colombia/16402298http://www.eltiempo.com/estilo-de-vida/educacion/panorama-de-los-ingenieros-en-colombia/16402298http://www.eltiempo.com/estilo-de-vida/educacion/panorama-de-los-ingenieros-en-colombia/16402298http://www.dinero.com/pais/articulo/mercado-laboral-ingenieros-sistemas-colombia/199380http://www.dinero.com/pais/articulo/mercado-laboral-ingenieros-sistemas-colombia/199380

INTEGRACIÓN DE UN MODELO DE REFERENCIA DE …todos los elementos del MRPGC en las fases...

Documents

Transcript of INTEGRACIÓN DE UN MODELO DE REFERENCIA DE …todos los elementos del MRPGC en las fases...