La selección del proceso de trabajo con el uso intensivo del conocimiento se ha realizado sobre la base de criterios de índole económica, técnica y de reacciones humanas, considerando los factores que sustentan la situación problémica formulada a partir de la caracterización preliminar, en este caso particular, será el de diseño y desarrollo de software, sustentado en los factores siguientes:
• La variabilidad del comportamiento de la productividad del trabajo.
• Los relacionados con la OT en ese proceso.
• La ausencia de tecnologías de soporte a la GC. 3.2 Etapa II: Registro del proceso
Mediante la utilización del mapa de proceso inter-funcional se registra la distribución de las actividades de diseño y desarrollo del software, mostrándose en el Anexo 4.
En el área de negocios se realiza la siguiente actividad:
• Entrevista con el cliente: En la entrevista inicial con el cliente se le brinda toda la información relacionada referente a la capacidad tecnológica disponible en la empresa para acometer el pedido; así como también se determinan las necesidades de dicho cliente.
En el área de desarrollo tiene lugar el proceso fundamental compuesto por las actividades siguientes:
• Recepción de las solicitudes: El subgerente de desarrollo en esta actividad comprueba si existe capacidad de tiempo, material y personal para desarrollar el software.
• Especificaciones: En esta actividad el desarrollador o especialista fija todas las especificaciones que debe tener el producto final.
• Asignación del proyecto: El subgerente de desarrollo determina la composición del equipo ad hoc destinado a acometer el proyecto.
• Entrevista con el cliente: Esta actividad es realizada por el subgerente de desarrollo, el desarrollador y negocios con el cliente en ella se puntualizaron los objetivos, el cronograma de trabajo es viable y si corresponde con el plazo de entrega del producto final y las herramientas seleccionadas son compatibles con la tecnología que posee el cliente.
• Análisis de requisitos: El especialista define todos los requisitos del proyecto y se logra una adecuada comunicación con el cliente. Se definen los requisitos funcionales y los no funcionales del sistema.
• Acta de aceptación de la etapa: En esta actividad el subgerente de desarrollo elabora un acta de aceptación donde se plantea que se cumplieron todos los requisitos del proyecto.
• Oferta el producto: Si el cliente está de acuerdo con la oferta, definida por los requisitos funcionales y no funcionales del software, se elabora el documento formal que ampara legalmente el contrato.
• Asignación de tareas: En esta actividad el especialista asigna todas las tareas que conformará el proyecto a desarrollar.
• Programación: El desarrollador programa el proyecto con todas las tareas asignadas para la realización del mismo. En esta actividad se obtiene el código fuente que soporta el modelo de diseño realizado, la arquitectura del sistema y toda la funcionalidad y especificaciones definidas en la definición del proyecto. Deben proponerse además componentes desarrollados para la codificación del sistema y que puedan ser reutilizados en la codificación de otros sistemas.
• Chequeo del cumplimiento de las etapas: En esta actividad el subgerente de desarrollo y el jefe de proyecto determinar si las etapas se cumplen en tiempo y forma.
• Pruebas del producto: La siguiente actividad es realizada por el especialista que desarrolla el software en la misma se ejecutan las pruebas que fueron correctamente diseñadas o seleccionadas y tienen en cuenta todas las variantes de posibles fallos o errores de proyecto. La validación adecuada de cada resultado de cada actividad a los estándares de la empresa, verificar la funcionalidad del sistema contra los requerimientos del cliente, verificar el código fuente para detectar errores y validar adecuación a los estándares de codificación; así como validar el producto respecto a nuestros atributos de calidad. Esta disciplina se comienza a establecer desde el inicio del proyecto, al tener identificados los requisitos del software, para poder probar la arquitectura seleccionada, así como elaborar los casos de prueba al tener especificados los casos de uso.
• Implementación por el cliente: Esta actividad es desarrollada por el cliente la misma prueba el software durante un período de tiempo de un mes para ver si cumple con los requisitos pedidos por el cliente.
• Acta de aceptación del producto: En esta actividad desarrollo y calidad firman el acta de aceptación del producto con el cliente en la misma se registran todos los fallos que se originan durante la implementación.
3.3 Etapa III: Análisis del proceso
PasoI: Determinación de la dependencia de información
Para identificar la dependencia e influencia relativa de la información entre las actividades se ha utilizado la Matriz de la estructura de diseño como se muestra en la figura No 3.1.
Figura No3.1.Dependencia relativa de información entre actividades. Fuente: elaboración propia
Se observa que desde las actividades 1, 3, 5, 6, 7 y 8 se demanda por igual la mayor información por el resto de las actividades del proceso, lo cual indica que el volumen de trabajo en ellas es mayor, por lo que deben estudiarse a mayor profundidad en cuanto a la asignación de recursos humanos, materiales y tiempo durante la ejecución del proyecto para poder lograr un flujo de trabajo equilibrado. Esto se muestra en la tabla No3.1 donde aparecen los valores porcentuales de influencia y dependencia relativa de información entre las actividades.
A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 A13 A14
A1 A2 • A3 • • A4 • A5 A6 • • • A7 • A8 • • • A9 • • A10 • • • • • • • • • A11 • • • A12 • • A13 • A14 •
Nivel de dependencia Nivel de influencia A1 - 14.29 A2 4.76 9.52 A3 9.52 14.29 A4 4.76 9.52 A5 - 14.29 A6 14.29 14.29 A7 4.76 14.29 A8 14.29 14.29 A9 9.52 9.52 A10 42.86 9.52 A11 14.29 4.76 A12 9.52 4.76 A13 4.76 4.76 A14 4.76 -
Tabla No 3.1. Niveles de dependencia e influencia de conocimiento entre actividades. Fuente: elaboración propia
Paso II: Modelado genérico de actividades
Para el desarrollo de esta actividad se seleccionado a la actividad 6, aunque se la autora plantea que esta herramienta debe aplicarse a todas las que componen el proceso de trabajo bajo análisis.
Para el modelado de la actividad 6 (análisis de requisitos) se solicitaron la asistencia de miembros del equipo de proyecto. Se pudo identificar los dominios de conocimiento y otros objetos presentes en la actividad; así como elementos específicos del análisis de requisitos, y la experiencia generada en las mismas, lo que se muestra en la figura No3.2.
En este diagrama se observa como se combinan los tres tipos de objetos: orden recurso y producto. El conocimiento organizacional aplicado en el análisis de requisitos se identifica los otros recursos portadores humanos, bases electrónicas de conocimiento y documentos necesarios para el desarrollo del trabajo en la actividad, definiéndose así disponibilidad de forma tácita o explícita.
En el análisis de requisitos se requiere la aplicación de procesos de ingeniería de la información para obtener todos los objetos manejados por los procesos del cliente a diferentes niveles, así como los procesos que intervienen en la modificación y/o control de dicha información.
Tiene como objetivo crear una base de entendimiento entre el cliente y los miembros de los equipos de trabajo del proyecto. Para ello es necesario definir los requisitos funcionales y no funcionales del sistema y actualizar o crear el glosario de términos
Análisis de
requisitos Objeto estadon+1(catálogo de requisitos, modelo de casos de uso, glosario de termino y modelado de casos de prueba) Recurso: Subclase (dominio del conocimiento) Metodología para el desarrollo del software: Metodología Rational Unified Process (RUP) Unified Modeling Language (UML) Objeto estado n (Contrato con el cliente) Orden (Metas del conocimiento) Nivel de madurez del proceso de GC Recurso: Subclase (portadores del conocimiento) Los especialistas en desarrollo del software (Especialista B en Informática)
Recurso: Subclase (base de conocimiento) Documentos electrónicos del (UML).
Figura No3.2. Modelado genérico de la actividad de análisis de requisitos Fuente: elaboración propia
que permita una comunicación fluida. La documentación de esta actividad debe constituir la base para las pruebas de aceptación final del sistema por parte del cliente, así como para las pruebas internas de calidad, por lo que esta definición tendrá que ser validada por todas las partes implicadas en el desarrollo. Los desarrolladores de software deben poseer conocimientos de la Metodología Unified Modeling Language (UML), lenguaje de modelado creado por Rational Unified Process. La documentación que se obtiene en esta actividad es el catálogo de requisitos, especificación de caso de uso, modelo de casos de uso, modelo de caso de prueba y glosario de términos.
Paso III: Madurez de la Gestión del Conocimiento
Para determinar el nivel de desarrollo en que se encuentra la formulación de metas relacionadas con el conocimiento en esta actividad destinadas a brindar soporte a ella y las otras actividades del proceso de trabajo a través de la implementación de iniciativas de GC, se administró la lista de chequeo a un grupo de interés de siete personas relacionadas con el proceso de desarrollo. Se trata de determinar el nivel de desarrollo alcanzado por la organización objeto de estudio práctico. Los resultados de la lista de chequeo se muestran a continuación en la tabla No 3.2:
Área de resultado clave Iniciativa de Gestión del Conocimiento Implementada % No implementada % Formación en GC 7 100 0 - Gestor en GC 7 100 0 - Sistema de estimulación vinculado a la GC 5 71.4 2 28.57 Comunidades de Práctica (CoP) 2 28.57 5 71.4 Personas Red Social 2 28.57 5 71.4 Diagnósticos de procesos de la GC 4 57.14 3 42.85 Estrategias de GC 5 71.4 2 28.57 Sistemas de soporte a la CoP 1 14.28 6 85.71 Procesos Diseño de procesos de la GC 1 14.28 6 85.71 Contenido Mapa de conocimientos 0 - 7 100
Políticas de GC 0 - 7 100 Métodos para medir el Capital Intelectual 0 - 7 100 Diagnósticos de sistemas basados en el conocimiento 0 - 7 100 Procedimientos para distribuir el conocimiento 1 14.28 6 85.71 Tecnología Nivel de utilización de software para la GC 0 - 7 100
Tabla No 3.2 Resultados de la aplicación de la lista de chequeo. Fuente: elaboración propia
Los resultados obtenidos de la lista de chequeo muestran el criterio del grupo relacionado con las iniciativas implementadas por área de resultado clave. A partir de la tabla se observa que en sólo en el área personas, y en específico, la existencia de un gestor en GC y de acciones de formación en este campo alcanzaron un 100 % de acuerdo entre los respondientes.
Este resultado (sólo dos iniciativas) sitúa a la empresa en el nivel de madurez
mínimo (caótico) de acuerdo con la escala que establece del modelo de madurez,
por lo que la organización deberá elaborar un plan de implementación de iniciativas por etapas para ir alcanzando progresivamente niveles superiores de desarrollo en la implementación de procesos de la GC que faciliten la generación, almacenamiento, transferencia y aplicación del conocimiento en el diseño y desarrollo de software. La ausencia de un proceso de la GC provoca que el conocimiento organizacional que se genera en la ejecución de tareas y actividades permanezca en estado tácito, como propiedad exclusiva de quienes son sus portadores humanos.
3.4 Etapa IV: Presentación de los resultados y propuesta de soluciones Paso I: Mapa situacional detallado
Para el registro integrado de la información cuantitativa y cualitativa del diagnóstico se elaboró el MSD que aparece en la Figura No 3.3.
Los pasos para elaborarlo son los siguientes:
Definición de los nodos de decisión. Están constituidos por aquellos factores que pueden ser diseñados o re-diseñados y que son controlables por Desoft S.A. Entre ellos están la organización del proceso de trabajo, la implementación de iniciativas de GC y la organización de su proceso.
Definición de los nodos meta. Están formados por aquellos factores que reciben una relación directa y de influencia con los nodos de decisión. Entre ellos se encuentran la existencia de una demanda de información entre actividades del proceso de trabajo.
En este mapa se representan los resultados cuantitativos y cualitativos obtenidos de la aplicación de las herramientas descritas en pasos anteriores. También se ilustra la información cualitativa que revela relaciones de proporcionalidad entre un elemento y otro del grafo.
51 Iniciativas en áreas de resultados clave Procesos Personas Contenido Tecnología Nivel 1 (caótico) Dependencia de información en las actividades Procesos de la GC Disponibilidad de conocimiento organizacional + Imponen la necesidad de Aplicación del conocimiento en el proceso de trabajo Eleva - R e duc e - + + Su falta reduce - Organización del proceso de trabajo + Ausencia de Eleva Necesidad de 4.76-42.86 %
Paso II: Informe de diagnóstico
La dependencia de información entre actividades del proceso se encuentra en un rango de 4,76 a 42,86 % lo cual impone la necesidad de revisar la organización del proceso de trabajo en relación a la secuencia de tareas y la asignación de recursos, además de la necesidad de implementar iniciativas de GC que contribuyan a facilitar su proceso, que a su vez aumentan la disponibilidad de conocimiento en el proceso de trabajo.
La dependencia de información entre actividades está elevando proporcionalmente la necesidad de implementar iniciativas que permitan diseñar y organizar procesos de la GC y que faciliten la disponibilidad oportuna al conocimiento por los actores que lo requieran. Como se comprobó, el desconocimiento de lo que significa la GC y sus beneficios potenciales es una causa fundamental de que no se hayan implementado esas iniciativas en las cuatro áreas de resultados clave, encontrándose en el nivel 1 o caótico, una consecuencia de la disminución de la disponibilidad del recurso y por lo tanto, su nivel de aplicación en el proceso organizacional de diseño y desarrollo de software.
Los elementos de análisis anteriores permiten afirmar que se requiere una integración bajo un enfoque de la Gestión del Conocimiento Orientada al Proceso para tomar decisiones de diseño o re-diseño de procesos organizacionales con el uso intensivo del conocimiento para lograr optimizar los esfuerzos de mejoramiento. Como se ha mencionado ya, se requiere que el proceso de la GC esté alineado de forma cíclica con las actividades del proceso de diseño y desarrollo de software.
Conclusiones parciales
1. La aplicación del procedimiento general en el objeto de estudio práctico permitió constatar su factibilidad como herramienta para el diagnóstico técnico-organizativo del proceso de diseño y desarrollo de software desde un enfoque de la Gestión del Conocimiento. Ello contribuyó a validar la hipótesis formulada en esta investigación.
2. Con la aplicación de herramientas de modelación gráfica del proceso organizacional y de análisis del proceso se pudo registrar y analizar la secuencia de actividades y determinar los factores técnico-organizativos que contribuyen a la no disponibilidad oportuna del conocimiento y las afectaciones de la productividad.
3. La utilización de la Matriz de la Estructura de Diseño permitió determinar las relaciones de dependencia entre actividades del proceso organizacional seleccionado; mostrando qué actividades tienen demanda del recurso conocimiento y desde cuáles este les puede ser suministrado. 4. La evaluación del estado de madurez de las áreas de resultados clave
que soportan el diseño e implementación de procesos de la GC, encontrándose éste en el nivel 1 o caótico.
5. El uso del mapa situacional detallado ha permitido representar la información cuantitativa y cualitativa de manera integrada y estructurada, mostrando las relaciones de proporcionalidad existente entre los elementos de análisis derivados en las etapas anteriores del procedimiento.
Conclusiones generales
Los resultados de esta investigación permiten arribar a las conclusiones siguientes:
1. La revisión bibliográfica realizada reveló la necesidad de integrar los campos de la Gestión del Conocimiento y la Organización del Trabajo en aras de lograr un enfoque global de mejoramiento en organizaciones con procesos de trabajo con uso intensivo del conocimiento.
2. La utilización de un enfoque de modelado genérico permitió considerar al conocimiento organizacional como uno de los recursos necesarios para llevar a cabo actividades del proceso de trabajo y la necesidad de implementar iniciativas de Gestión del Conocimiento que brinden soporte a sus actividades.
3. En el contexto de la investigación realizada en esta tesis, quedó demostrado que el diagnóstico técnico-organizativo del proceso de diseño y desarrollo de software en la empresa Desoft S.A. División Villa Clara requiere de una integración de factores de la Gestión del Conocimiento y de diseño del proceso organizacional, para lo cual es necesario un enfoque metodológico que contenga varias etapas de análisis y modelado de ambos campos. Por una parte, sustenta al problema científico formulado en esta tesis y por otra, confirma que la propuesta de un procedimiento que establezca las relaciones entre los procesos organizacionales y el proceso de la GC constituyen una herramienta que contribuye a elevar la comprensión del objeto de estudio teórico.
4. La aplicación del procedimiento general propuesto permitió determinar cuáles son los factores de diseño en la empresa Desoft S.A. División Villa Clara que debe dársele atención priorizada en aras del mejoramiento del proceso seleccionado de manera. De esta forma se comprobó la hipótesis de investigación formulada.
Recomendaciones
Como parte de la continuidad de este trabajo se recomienda:
1. Utilizar el procedimiento general propuestos como una herramienta de diagnóstico en la actividad de Organización del Trabajo en el objeto de estudio práctico.
2. Extender el modelado genérico al resto de las actividades del proceso de desarrollo, con el objetivo de determinar los recursos necesarios en cada una de ellas.
3. Desarrollar e implementar iniciativas de Gestión del Conocimiento por áreas de resultado clave para alcanzar niveles de madurez superiores que contribuyan al mejoramiento de su proceso, lo cual es una necesidad en esta organización dada su naturaleza intensiva en conocimiento.
Bibliografía
1. Akiyama, M. & Kamata. (2004)Methods engineering and workplace desing, pp540. 2. Al-Gharaibeh, R.S. (2007): The effect of information structuring on analytical
knowledge acquisition. Tesis en opción al grado científico de Ph.D., Graduate School of Management, Kent State University, EE.UU.
3. Artiles. (2007) Dimensión humana de la Gestión del Conocimiento,pp6 4. Artiles. (2007) Gestión del Conocimiento, pp1.
5. Bailey & Barley. (2005) Toward post-Industrial Engineering, p. 2.
6. Bailey & Barley. (2005) Return to work: Toward post-industrial engineering, IIE Transactions, EE.UU.
7. Bechky (2006) Talking about machines, thick description, and knowledge work, p.2.
8. Blaya Inmaculada (2006).Tomado de Gestión de procesos. Oficina de Gestión y Control de la Calidad .Universidad Miguel Hernández UPM.
9. Brodner. (2000)Op.cit, pp14-15.
10. Browning. (2001)Applying the Design Structure Matrix to System Descomposition and Integration Problems: A Review and New Directions, pp 1-2.
11. Carrión Juan y Fabián Ramirez.www.gestiondelconocimiento.com.
12. CITMA: Bases para la introducción de la Gestión del Conocimiento en Cuba, p. 8. 13. Conallen, J. (2000) Building Web-Applications with UML; Addison-Wesley.
14. Cuba MinRex. (2005)La informatización en Cuba
15. Cuesta. (2005). La Organización del Trabajo en la GRH, pp 2. (Formato digital)
16. De Vries. (2006)A new process improvement approach for management
consultancy organizations ,pp 50-58
17. Dimensión humana de la Gestión del Conocimiento, p. 6. 18. Economía Basada en el Conocimiento, pp. 137.
19. El Factor Humano y la Gestión del Conocimiento en la Empresa Desoft S.A.
20. García, J. (2000) .Un proceso basado en UML para aplicaciones de gestión, Facultad de Informática, Universidad de Murcia.
21. Gärtner, T. & Neuhöfer Computer-based cooperation and teamwork, Chair of
Industrial Engineering and Ergonomics, RWTH Aachen University, p. 4. 22. Gärtner, T. & Neuhöfer. (2007)Modeling and optimizing workflows. 23. Heisig, Alwert y Ulbrich, (2002).Toward post-Industrial Engineering, p.2. 24. Introducción al estudio del Trabajo (OIT) , (1992),pp 88 y pp99-102
25. Jacobson, I. y otros. (2000). El Proceso Unificado de Desarrollo de Software, Addison Wesley, Madrid, España.
26. Knowledge Management maturity model. VISION Project: Next-Generation
Knowledge Management, p. 9.
27. Larman, Craig. (1998).Applying UML and Patterns: An Introduction to Object- Oriented Analysis and Design and Iterative Development, Prentice Hall.
28. Marsán. (1987)Op.cit, pp242-243
29. Moliner, E. (2003). Softmétodo V 1.0, Softcal.
30. Niebel.Ingenieria Industrial: Métodos, tiempo y movimiento. Tomo1, pp28-49. 31. Pin González Enrique, Mercedes L. Zenea Montejo, Felipe H. Herrera Torres
Profesores del Grupo de Teoría y Técnicas de Dirección de la Facultad de Ciencias Económicas de la Universidad Agraria de La Habana y Consultores gerenciales asociados al Centro internacional de la Habana. (2004- 2005).Producción, Procesos, Operaciones.www.Gestionpolis.com.
32. Propuesta de estrategia para la Introducción de la Gestión de la Información y la