Serviços customizados
Espanhol (pdf)
Artigo em XML
Referências do artigo
Enviar este artigo por email
Citado por SciELO 
Similares em
SciELO 
Permalink
I. Introducción
En la actualidad las organizaciones continúan trabajando en la integración de sus funciones y procesos de negocio, de modo que les permita ser eficientes y eficaces, incluso en la distancia y en condiciones de aislamiento [1, 2]. En este sentido, los sistemas de Planificación de Recursos Empresariales (sistemas ERP, por sus siglas en inglés) siguen siendo una opción, que provee las capacidades tecnológicas necesarias para soportar el funcionamiento integrado de la organización [3, 4, 5]. Uno de los sistemas ERP, cuyo uso se ha extendido en los últimos años, se denomina ODOO (también reconocido como OpenERP). Este es un sistema de código abierto que ha llegado a ser la solución tecnológica de varias empresas [6]. Tiene una extensa comunidad usuaria y desarrolladora que continuamente ofrece propuestas de mejora, lo que lo convierte en un modelo de referencia validado por toda la comunidad de práctica que lo usa y lo desarrolla [7]. Alrededor de ODOO se ha logrado el fortalecimiento de la cadena de valor para su implementación. Según su sitio oficial1, tiene 1540 socios implementadores en 143 países del mundo, incluyendo Cuba, con la reciente incorporación de la Empresa de Aplicaciones Informática DESOFT, como socio principal reconocido para la implementación de ODOO en organizaciones cubanas.
ODOO está compuesto por módulos, lo que permite que su implementación en una organización se haga de manera iterativa y escalonada [8]. Estos módulos se hacen coincidir con las áreas funcionales de las organizaciones. Algunos ejemplos son: Gestión de relaciones con los clientes (CRM, por sus siglas en inglés), Ventas, Compras, Facturación, Inventario, Fabricación, Reparación, entre otros [9]. Como es característicos de los sistemas ERP [10],ODOO tiene una base de datos integrada, lo cual permite que los datos sean registrados una sola vez y reutilizados siempre que sea necesario, independientemente de la función de la organización que los demande.
La comunidad de práctica de ODOO reconoce y contribuye al desarrollo de sus capacidades tecnológicas, de modo que tenga valor para fortalecer el funcionamiento de las organizaciones y de sus procesos de negocio [11]. Dichas capacidades tecnológicas agrupan un conjunto de funcionalidades que se desarrollan sobre la base de las buenas prácticas de sus usuarios en relación a las capacidades funcionales que deben realizar los procesos de negocio. En tal sentido, es posible lograr una estrecha relación entre las capacidades tecnológicas y funcionalidades de ODOO,con los procesos de negocio y las capacidades funcionales que deben realizarse en las organizaciones [12].
De este modo, ODOO ha servido como referencia para el rediseño de los procesos de negocio que son soportados por este sistema, debido a que su equipo de desarrollo ha trabajado en crear flujos de trabajo que permitan conectar sus funcionalidades, atendiendo a las necesidades de integración de los procesos en la práctica [12]. Esto es una característica que facilita el trabajo de los analistas de procesos, para comprender el flujo de funcionalidades del sistema y, en consecuencia, rediseñar los procesos que se ajusten a dichos flujos [13].Sin embargo, para poder identificar estas conexiones hay que ser un usuario avanzado de ODOO, debido a que no se han identificado dichos flujos de manera explícita, y en el lenguaje de los analistas de procesos. Para ello se ha reconocido la necesidad de explicitar modelos de referencia que ayuden a transformar el diseño de las organizaciones, como consecuencia de adoptar tecnologías [14].
Para direccionar tal necesidad, el siguiente artículo tiene como objetivo proponer un método para rediseñar procesos de negocio basado en flujos de referencia de ODOO. Con el método es posible que los analistas que han pasado por un entendimiento de ODOO para el rediseño de procesos, dejen explícito los flujos de funcionalidades que han tomado como referencia; también pueden, en caso de existir flujos ya documentados, tomarlos como referencia o hacerle propuestas de mejora. A través del método es posible crear patrones de flujos de referencia del ERP, para ser compartidos y reutilizados por: analistas de procesos, expertos funcionales, usuarios de ODOO y su comunidad de práctica, en general.
El artículo se ha estructurado, además de esta introducción, en una sección de métodos, donde se expone la secuencia de pasos para explicitar o reutilizar flujos de funcionalidades de ODOO que luego sean utilizado como referencia para el rediseño de procesos. Seguidamente se presentan las secciones de resultados y discusión, donde se aplica el método en un proceso clave del pequeño negocio TostoneT y se reflexiona sobre el impacto, respectivamente. Por último, se presenta la sección de conclusiones, seguida de las referencias.
I. Métodos
Para cumplir con el objetivo del trabajo se propone un método para rediseñar procesos basado en flujos de referencia del ERP ODOO. Este método constituye una evolución de trabajos anteriores [7, 13]. Su principal valor radica en que con la aplicación del método se generan dos salidas que pueden ser compartidas como recursos de conocimiento en la comunidad, con valor para el rediseño de los procesos que se deseen automatizar con ODOO. Dichas salidas son las siguientes:
Cadena de capacidades tecnológicas: Constituye la interrelación secuencial de grupos de funcionalidades que puede cruzar las fronteras de los módulos de ODOO. Su valor radica en que es posible visualizar cuál sería el ofrecimiento de un servicio tecnológico de ODOO en el alcance de un proceso real que lo demanda, independientemente de las áreas funcionales que puedan intervenir.
Flujo de funcionalidades de referencia: Los flujos de funcionalidades detallan en un nivel más atómico las capacidades tecnológicas de ODOO. El valor de estos flujos es que sirven como referencia para el rediseño de los procesos, ya que su generación es el resultado de las buenas prácticas de la comunidad usuaria que retroalimenta el desarrollo y mejora de ODOO. Las funcionalidades contenidas en estos flujos pueden convertirse en tareas o actividades del proceso que será automatizado con ODOO.
Los usuarios del método son analistas de procesos, analistas de sistemas o expertos funcionales. Durante la ejecución del método puede suceder dos variantes. Una primera variante es que sea necesario generar la cadena de capacidades tecnológicas y los flujos de funcionalidades de referencia. En este caso es preciso tener conocimiento detallado del funcionamiento de ODOO. En una segunda variante, la cadena de capacidades tecnológicas y el flujo de funcionalidades ya existen, y pueden ser reutilizadas. En este caso, no es obligatorio tener conocimiento profundo del funcionamiento de ODOO, sino que, con tan solo entender las capacidades tecnológicas que ofrece este sistema, sería suficiente para ejecutar el método.
En el método, para la diagramación de la cadena de capacidades tecnológicas, los flujos funcionales de referencia y los procesos de negocio, se propone la utilización de la Notación para el Modelado de Procesos de Negocio (BPMN, por sus siglas en inglés). Dado que BPMN se ha convertido en un estándar para el modelado de procesos, reconocido entre especialistas del negocio y especialistas de tecnologías de la información, se propone su uso para facilitar la compresión de los diagramas, y la asociación entre ellos cuando se requiera reutilizar el conocimiento que contienen. En la tabla 1 se observan los pasos del método.
Tabla 1 Método para rediseñar procesos basado en flujos de referencia del ODOO
| Pasos | Descripción | Herramientas |
|---|---|---|
| Delimitar alcance del estudio. | Para delimitar el alcance se identifica el sector, dado que un mismo tipo de proceso en sectores diferentes pudieran tener diferentes comportamientos. Con ello es posible comprender características funcionales distintivas del proceso para ese sector. Luego se definen las entradas y salidas del proceso, para precisar dónde comienza y dónde termina el proceso que será objeto de estudio. Para representar las entradas y salidas, se puede utilizar un diagrama del proceso como caja negra. | Diagrama del proceso como caja negra. |
| Describir proceso actual. | En este paso es preciso hacer un levantamiento de cómo se ejecuta el proceso actual. El propósito es identificar las actividades claves del proceso, así como problemáticas y oportunidades que debieran quedar resueltas en la nueva propuesta de diseño. | Diagrama de flujo, tabulación o descripción textual. |
| Determinar capacidades funcionales del proceso. | Seguidamente se identifican las acciones que, según la buena práctica funcional, debe realizar el proceso. Para ello es preciso indagar en las experiencias de los ejecutores del proceso y consultar referencias que aborden procesos similares para el sector. También es posible consultar las capacidades que ofrece ODOO para el proceso, ya que también es un proveedor de conocimiento funcional que puede ser reutilizado. | Mapa de capacidades. Consultar metodología propuesta por Pavón, Ortega [13] |
| Asociar módulos de ODOO con las capacidades funcionales. | Seguidamente, de acuerdo con las capacidades funcionales que debe realizar el proceso, se identifican los módulos de ODOO asociados. Para ello es preciso consultar la documentación de ODOO ( |
Matriz de capacidades funcionales con módulos de ODOO Consultar Patrón metodológico 13 propuesto por Buckl, Ernst [15] |
| Identificar/Recuperar cadena de capacidades tecnológicas de ODOO | Luego de tener claridad de los módulos de ODOO, se identifican y se interrelacionan las capacidades tecnológicas de acuerdo a las demandas funcionales del proceso. Para ello es preciso comprender el funcionamiento del sistema y cómo se interrelacionan sus módulos para satisfacer las necesidades del proceso. La interrelación de las capacidades tecnológicas se realizará con BPMN. De cada capacidad tecnológica debe especificarse el módulo al que pertenece, para ello se utilizarán los carriles verticales de BPMN para especificar el módulo y el artefacto de actividades para especificar la capacidad tecnológica. Asimismo, se representarán, a través de los flujos de información, los registros que resultan y/o necesitan una capacidad tecnológica. En caso de que, en iteraciones anteriores del método, se haya generándola cadena de capacidades tecnológicas requerida, entonces en este paso solo se tendrá que recuperar dicha cadena. | BPMN |
| Modelar/Recuperarlos flujos de funcionalidades de referencia de ODOO | En este paso se procede a diagramar las funcionalidades del sistema en forma de flujo, de modo que se visualice la secuencia lógica de dichas funcionalidades. Para generar el flujo de funcionalidades de referencia se utilizará BPMN. De igual manera que en el paso anterior, si los flujos de funcionalidades tecnológicas ya están explícitos, entonces, en este paso solo se deben recuperar los existentes. | BPMN |
| Rediseñar el proceso incorporando funcionalidades tecnológicas | Durante este paso se incorporan las mejoras al diseño del proceso objeto de estudio. Para ello se debe tener en cuenta los flujos de referencia del ODOO generados en el paso anterior. Las funciones contenidas en los flujos de referencia pueden convertirse en tareas del proceso rediseñado. Dichas tareas serían del tipo usuario o servicio (de acuerdo a notación BPMN), lo cual evidencia que es una tarea que es ejecutada a través del sistema. Con ello no solamente el proceso mejora en relación al uso de una tecnología, sino que también incorpora las buenas prácticas de funcionamiento reconocida por la comunidad que utiliza y desarrolla ODOO. | BPMN |
II. Resultado
El método ha sido aplicado en el pequeño negocio TostoneT, que se dedica a brindar servicios de soporte técnico de equipos de cómputo a clientes empresariales e individuales. Este negocio, desde su fundación en el año 2012, ha trabajado en crear y mejorar su sistema organizacional con el propósito de ser más eficiente y eficaz. Para ello, en 2013 proyectó una estrategia de adopción del sistema ERP ODOO [7]. Desde ese entonces comenzó un ciclo de aprendizaje de uso del sistema y de maduración de sus procesos, incorporando poco a poco cada uno de los módulos pertinentes.
A finales del año 2020 se decidió iniciar el 2021 con la versión 13 de ODOO, bajo la estrategia de incorporar otras funcionalidades no implementadas hasta el momento, así como las novedades de esta versión. Uno de los procesos, con cambios significativos para el negocio en esta etapa, fue la gestión de reparaciones a equipos de cómputo. Este proceso en versiones anteriores de ODOO solo usaba el módulo de venta y facturación como mecanismo para registrar los productos y servicios ofrecidos durante una reparación. Sin embargo, los analistas reconocen las capacidades del módulo de reparaciones de ODOO para solucionar problemáticas de este proceso que cada vez más estaban afectando al negocio. Seguidamente se muestra el resultado de aplicar el método en TostoneT.
1. Delimitar alcance del estudio
El proceso seleccionado para el estudio es: la Gestión de reparaciones de equipos de cómputo. Este es un proceso clave de TostoneT, ya que está orientado directamente a los servicios que oferta. En la tabla 2 se muestran los diferentes elementos que contribuyen a definir el alcance del proceso. Se define el sector donde el proceso está enmarcado, las capacidades generales que debe realizar el proceso, así como una ilustración del proceso como caja negra. Esta ilustración indica la entrada del proceso, delimitando su inicio, y las salidas del proceso, lo que representan su fin.
Tabla 2 Descripción del alcance
| Alcance | Descripción | |
|---|---|---|
| Sector | Servicios técnicos | Pertenece a la industria de los servicios. Se caracteriza por el conjunto de acciones realizadas por uno o conjunto de especialistas para prevenir y/o solucionar problemas de una variedad de equipos. |
| Proceso | Gestión de reparaciones a equipos de cómputo | Proceso que inicializa con la solicitud de servicios de reparaciones de los clientes y termina con la entrega de los equipos reparados y la factura del servicio correspondiente. |
| ||
2. Describir proceso actual
Para indagar un poco más sobre el proceso se buscó información explícita que lo describiera, pero no había disponible. Entonces se procedió a realizar entrevistas a los ejecutores del proceso, observar la ejecución del proceso y levantar sus problemáticas y oportunidades. En este paso no se aplicó una técnica de diagramación del proceso actual, debido a que había inconsistencias en el proceso que dificultaban su representación gráfica. Como resultado, se ofrece una descripción genérica que se observa en la tabla 3.
Tabla 3 Descripción actual del proceso de gestión de reparaciones de equipos de cómputo
| Actividad | Propósito | Tipo | Salida |
|---|---|---|---|
| Verificar tipo de soporte que solicita la entidad | Definir concretamente el servicio que solicita el cliente, áreas de la empresa donde recae el servicio y entregar ofertas actualizadas. | Manual | Oferta actual y personalizada |
| Ejecutar diagnóstico | Encontrar el problema que afecta el funcionamiento del equipo, componente o accesorio. | Manual | Problema técnico del equipo |
| Planificar solución | Proyectar una solución de acuerdo con el resultado del diagnóstico. Diseñar una solución en caso de que el soporte sea el diseño de una red en la entidad. | Manual | Decisión sobre la solución |
| Generar orden de trabajo | Detallar en la orden de trabajo los recursos utilizados y los servicios que se brindan. Proyectar el valor del servicio, contabilizando los recursos que se utilizarán durante el servicio técnico | Manual | Orden de trabajo |
| Planificar recursos necesarios | Proyectar el aprovisionamiento de recursos materiales, así como las competencias técnicas para la ejecución del soporte. Planificar la compraventa y la subcontratación de servicios. | Manual | Plan de recursos |
| Ejecutar solución | Solucionar el problema detectado; las posibles soluciones pueden llevar a una reparación o reposición de hardware, o a la instalación de software que recomiende el técnico. Esta actividad puede incluir la instalación de redes, en caso que se demande. | Manual | Equipo reparado |
| Registrar venta | Registrar los servicios realizados para su facturación, y en los que se haya requerido la incorporación de piezas, se registra el movimiento del inventario, de modo que quede actualizado. | Usuario en ODOO | Factura |
Por otro lado, se realizó un levantamiento de problemáticas del proceso, las cuales fueron consideradas para hacer una nueva propuesta de diseño. Las problemáticas identificadas se enumeran a continuación:
1. El cliente no tiene suficiente conocimiento para comunicar sus necesidades.
2. No se comunican las solicitudes de los clientes oportunamente.
3. Elevadas incertidumbres que permita ofrecer precios competitivos a los clientes.
4. Existen limitaciones del cliente empresarial para contratar ciertos servicios a trabajadores por cuenta propia.
5. Los clientes no tienen claridad del importe del servicio hasta que el equipo se repara.
6. Los clientes no valoran los servicios técnicos y se niegan a pagar los precios propuestos.
7. Reclamaciones del cliente por equipos y/o componentes que no fueron reparados.
8. Irregularidades en la disponibilidad de componentes que aseguren la calidad de los servicios de soporte técnico
9. Retraso de las reparaciones por desconocimiento de los compradores de las piezas requeridas.
10. Desconocimiento de los síntomas y problemas que motivaron al cliente la reparación del equipo.
11. Reparación de afectaciones no solicitadas por el cliente.
12. No existe claridad de los técnicos disponibles para reparar los equipos.
13. No existe claridad de las posibles soluciones que pueden ser ofrecidas ante la necesidad de un cliente.
14. No se reconocen los equipos de los clientes existentes en el taller.
15. Desconocimiento de las acciones realizadas a los equipos luego de ser reparados.
16. Pérdida de accesorios de los equipos de los clientes.
17. Entrega de equipos a clientes equivocados.
18. Olvido de equipos que deben ser reparados.
1. Determinar capacidades funcionales del proceso.
Para el levantamiento de las capacidades funcionales, se adquirió conocimiento de las experiencias de los ejecutores del proceso. También se consultaron las prácticas existentes para procesos similares en negocios del mismo sector. Las capacidades de nivel 1 identificadas fueron:
Gestión de clientes: Garantizar una adecuada comunicación y relación con los clientes.
Gestión de venta: Concebir actividades de negociación que contribuya a la rentabilidad del negocio y seguimiento de la trazabilidad de los acuerdos alcanzados.
Gestión de soporte técnico: Garantizar el ofrecimiento de los servicios de reparación de acuerdo a como la buena práctica lo indica, lo que incluye etapas de: diagnóstico, ejecución y prueba.
Seguimiento de equipos: Disponer de capacidades para ejecutar y controlar el movimiento de los equipos.
Gestión logística: Gestionar las necesidades de compra de piezas para las reparaciones y controlar el movimiento de dichos inventarios.
Las capacidades se detallaron hasta un segundo nivel; como resultado se muestra el mapa de capacidades de la figura 1.
2. Asociar módulos de ODOO con las capacidades funcionales.
Atendiendo a las capacidades funcionales del proceso, se identificaron los módulos de ODOO que pudieran soportar dichas capacidades. Los módulos identificados fueron:
CRM: Este es el módulo de Gestión de Relaciones con los Clientes (CRM, por sus siglas en inglés). A través de este módulo es posible gestionar las solicitudes de reparación de los clientes y planificar las fechas en que el servicio puede inicializarse. Con ello se puede contribuir a evitar el olvido de solicitudes.
Reparación: Este módulo tiene funcionalidades para gestionar las órdenes de reparación de los equipos de cómputo. A través de una orden de reparación se puede registrar información relacionada con el equipo y los servicios y precios asociados.
Compras: A través de este módulo se pueden gestionar las órdenes de compra para suministrar las piezas requeridas por los servicios de soporte técnico.
Inventario: A través de este módulo se puede organizar la información de las piezas existentes y seguir la trazabilidad de sus movimientos, desde la compra hasta que sea utilizada en la reparación de un equipo de un cliente.
Facturación: A través de este módulo se gestionan las facturas de clientes y proveedores, con lo cual existe transparencia de las obligaciones de pago de los clientes y de TostoneT.
En la tabla 4 se muestra la matriz de las capacidades funcionales en relación a los módulos del ERP que pueden soportarlas.
Tabla 4 Matriz de capacidades y módulos de ODOO
| Capacidades funcionales | Módulos ODDO | ||||
|---|---|---|---|---|---|
| CRM | Reparación | Compras | Inventario | Facturación | |
| Gestión de clientes | X | ||||
| Gestión de ventas | X | X | |||
| Seguimiento de equipos | X | ||||
| Gestión de soporte técnico | X | ||||
| Gestión logística | X | X | X | ||
3. Identificar/Recuperar cadena de capacidades tecnológicas de ODOO
Para representar la cadena de capacidades tecnológicas, se identificó el servicio que ofrece cada módulo al proceso. Seguidamente se interrelacionaron de acuerdo a las necesidades del proceso. También se identificaron los registros de información de cada módulo. Como resultado, se obtuvo la cadena de capacidades tecnológicas para ofrecer servicios de reparaciones, que se muestra en la Figura 2.
4. Modelar/Recuperar los flujos de funcionalidades de referencia de ODOO
Seguidamente se identificaron las funcionalidades de cada capacidad tecnológica de ODOO. Para ello se consultaron manuales, cursos y publicaciones de ODOO que contenían las funcionalidades requeridas, algunos ejemplos de las fuentes consultadas son las publicadas por: Limantara and Jingga [16] y Pavón González, Puente Baró [17]. También se simuló el uso del sistema con instancias concretas del proceso. Como resultado, se obtuvieron 4 flujos funcionales de referencia.
El primer flujo, como se observa en la figura 3, ilustra las funciones para la gestión de iniciativas y oportunidades de negocio contenidas en el módulo de CRM. En él se ilustra el seguimiento y las acciones asociadas para poder ganar una oportunidad de negocio. En relación al proceso de TostoneT, es posible a través de la gestión de iniciativas y oportunidades gestionar las solicitudes de reparación de los clientes.
El segundo flujo integra los módulos de reparación e inventario (ver figura 4). En él se ilustra todo el ciclo de vida de una orden de reparación y se incluyen, en relación al inventario, la función de generar movimientos de productos. Esto último ocurre cuando una reparación necesita incorporar piezas, además de los servicios de soporte técnico. Para cada orden se indican las piezas incorporadas con su precio y número de inventario, con lo cual es posible seguir la trazabilidad.
El tercer flujo muestra el ciclo de vida de las facturas a clientes. La primera función de este flujo está relacionada con la reparación, ya que es donde se seleccionan las órdenes de reparación que serán facturadas, como se observa en la figura 5. En la factura que se crea, se incorporan automáticamente las piezas y servicios de cada orden de reparación, con sus cantidades y precios asociados.
El cuarto flujo muestra el ciclo de vida para la ejecución de compras de productos a través del sistema, que se refleja en la figura 6. En este flujo participan los módulos: a) compras para las licitaciones y órdenes de compra, b) inventario, para gestionar las recepciones y c) facturación, para contabilizar las obligaciones de pago a proveedores.
1. Rediseñar el proceso incorporando funcionalidades tecnológicas
El proceso de gestión de reparaciones de equipos de cómputo se ha dividido en 4 etapas, para facilitar su estudio. A continuación, se presentan las etapas y las funcionalidades de ODOO incorporadas:
Atención al cliente: El propósito de esta etapa es hacer un primer contacto con el cliente, se reciben y se atienden las solicitudes de reparación, brindando una información primaria a los clientes. En esta etapa están presentes las funcionalidad es de gestión de iniciativas y oportunidades.
Preparación: En esta etapa se planifican los servicios de reparación en relación a otras solicitudes, atendiendo a las prioridades y el tiempo disponible para ello. Para la preparación también se utilizan las funcionalidad es de gestión de iniciativas y oportunidades.
Ejecución: Durante esta etapa se reciben los equipos que serán reparados y se ejecuta el soporte técnico, considerando capacidades de gestión a lo largo del servicio. Además, se despliegan las funcionalidad es gestión de órdenes de reparación y movimiento de inventario, así como la gestión de órdenes de compra y de recepciones de los productos requeridos por los servicios de reparación.
Cierre: Luego de finalizar los servicios de reparación se procede a la etapa de cierre, donde se elabora la factura de los servicios y productos ofrecidos. Los equipos reparados y la factura se le entrega al cliente. Esta etapa contiene las funcionalidades de gestión de facturas de clientes.
A los efectos de este artículo solo se muestran el rediseño del proceso para la etapa 3: Ejecución, y la etapa 4: Cierre. En la figura 7 se muestra el modelo del proceso rediseñado para estas etapas. Por su lado la figura 8 refleja el subproceso Gestión de reparaciones. Las actividades que son de tipo usuario son aquellas que se ejecutan en interacción con ODOO.
III. Discusión
Con la aplicación del método se representó la cadena de capacidades tecnológicas que ofrece ODOO para soportar la gestión de servicios de reparaciones, de manera genérica. Esta es una salida, no solo con valor para el rediseño del proceso que ha sido objeto de estudio en este artículo, sino que también constituye un recurso de conocimiento, que puede ser reutilizado por analistas que deseen adoptar estas capacidades en otros negocios. De esta manera queda disponible para la comunidad. A través de la cadena de capacidades fue posible visualizar la integración del conjunto de funcionalidades del sistema pertinentes al proceso de gestión de reparaciones de equipos de cómputo de TostoneT. Ello permitió tener un mejor acercamiento al conocimiento embebido en el sistema, ya que, en la práctica, todas estas capacidades deben integrarse para ofrecer un mejor servicio al proceso.
Por otra parte, se explicitaron los flujos de funcionalidades contenidas en las capacidades tecnológicas ya identificadas. Tales flujos también se convierten en recursos de conocimiento para la comunidad. Su valor radica en que poseen un conocimiento sobre las prácticas en la gestión de los servicios de reparaciones, que no solo incluye la reparación como servicio, sino también toda la gestión que debe articularse para garantizar la calidad del servicio, desde que el cliente hace la solicitud, hasta que se lleva el equipo reparado y la factura asociada.
Para Tostone T, este conocimiento fue de gran valor, ya que incorporó en su nuevo diseño, prácticas que no tenía implementadas. Muchas de las problemáticas existentes en el proceso tenían como causa raíz, el inadecuado registro de información, falta de asociación de las informaciones manejadas por el proceso, así como insuficientes mecanismos de comunicación. Con los flujos de referencia fue posible identificar qué y cómo debe registrarse la información, así como las relaciones entre ellas para asegurar su trazabilidad, puntos de comunicación de manera interna y con el cliente, y pasos que deben seguirse para asegurar los elementos anteriores. En las figuras de abajo se ilustran los indicadores de rediseño del proceso. Puede verse en la Figura 8 que en la nueva propuesta se tomaron decisiones de diseño considerando el 80% de las problemáticas identificadas en el paso 2. Por su lado en la Figura 9 puede verse un incremento de funcionalidades de ODOO Figura 10 en relación al diseño anterior, lográndose incorporar 26 funcionalidades en la nueva propuesta de diseño del proceso, lo que significa un proceso más informatizado.
Con la puesta en práctica del nuevo diseño en TostoneT, el equipo de trabajo reconoce que existe una mejor coordinación entre los actores que participan el proceso. Algunos de los beneficios reconocidos en entrevistas a los trabajadores, son los siguientes:
Es posible llevar un control del estado de reparación de los equipos, por lo que ha disminuido la cantidad de equipos que no reciben atención por desconocimiento de su existencia.
Se ha agilizado el inicio de la ejecución de los servicios de soporte técnico, dado que se accede más rápido a la descripción de los síntomas de mal funcionamiento que el cliente desea resolver.
No se han dado casos de entregas de equipos a clientes equivocados, lo cual era frecuente en el diseño anterior dejando altos costos de transportación y molestias a los clientes.
Por su parte, los clientes también han reconocido las mejoras del nivel de servicio, entre ellas se destacan las siguientes:
IV. Conclusiones
ODOO es un sistema ERP que tiene embebido un modelo de referencia para la gestión integrada de la organización, lo cual es fruto de las buenas prácticas de la comunidad que lo usa y lo desarrolla. A través del método propuesto en este artículo se logra capturar cadenas de capacidades tecnológicas y flujos funcionales de referencia de ODOO. Dichos recursos de conocimientos pueden ser compartidos y reutilizados por analistas de procesos para hacer propuestas de diseño y mejoras de procesos de negocio que sean informatizados con el empleo de ODOO.
Con la aplicación del método en el proceso de gestión de reparaciones a equipos de cómputo en TostoneT, se logró explicitar la cadena de capacidades tecnológicas para gestionar servicios de reparaciones con ODOO y cuatro flujos funcionales de referencia que incluyen los módulos de: CRM, Reparación, Compras, Inventario y Facturación. Teniendo en cuenta estos recursos de conocimiento para el rediseño del proceso objeto de estudio, se logró hacer propuestas de diseño orientadas a resolver el 80% de las problemáticas identificadas en el proceso. También se logró la incorporación de 26 nuevas funcionalidades de ODOO en el proceso, las que equivalen a un incremento del 83% respecto a las que ya existían.
El nuevo diseño del proceso contribuyó a una mejor coordinación del equipo de trabajo, dado que la información relacionada con el servicio a todo lo largo del proceso, quedaba registrada y accesible para todos. Ello tuvo impacto en la calidad del servicio al cliente, mejorando la capacidad de respuesta, transparencia en la comunicación y reducción de la incertidumbre en relación al servicio.
