Gobernabilidad de Datos

La gran cantidad de datos que están entregando los procesos de negocios de las empresas son una fuente de información que puede ayudar a la generación de valor, mediante el apoyo a la toma de decisiones con elementos cuantitativos, confiables y oportunos. Esta necesidad de utilización de los datos para generar información relevante requiere el establecer un conjunto de definiciones, reglas y procesos que regulen como serán tratados los datos, a este conjunto se le denomina Gobernabilidad de Datos.

Se entiende por Gobernabilidad de Datos al ejercicio —acciones- del proceso de toma de decisiones y de autoridad en materias referidas a los datos. Es un sistema de derechos de decisión y de accountability para procesos relacionados con información, ejecutado conforme a modelos acordados que describen quién puede hacer acciones con determinada data y en cuales circunstancias, utilizando métodos previamente definidos.

Cuando nos referimos a Gobernabilidad de Datos podemos estar refiriéndonos a:

  • Estructuras de la Organización.
  • Reglas (políticas, estándares, normas, reglas de negocio).
  • Derechos de decisión (establecer cómo decidir y quién decide).
  • Responsabilidades / Accountabilities.
  • Procesos relacionados con la operación de los datos.

Los objetivos típicos de un programa de Gobernabilidad de Datos son:

  • Habilitar una mejor toma de decisiones.
  • Reducir la fricción operacional (tener una fuente única de datos reconocida por toda la organización).
  • Proteger las necesidades de los interesados —stakeholders- en sus datos.
  • Capacitar a los directivos y a los colaboradores para que adopten enfoques comunes en materia de datos.
  • Generar el entendimiento —cultura- que los datos son un activo de la empresa.
  • Crear procesos estándares y repetibles.
  • Reducir los costos y aumentar la eficacia mediante la coordinación de esfuerzos.
  • Garantizar la transparencia de los procesos.

Marcos de Referencia para la Gobernabilidad de Datos.

Para la gobernabilidad de datos existen varios marcos de referencia —framework-susceptibles de utilizar, como ser:

  1. DMBOK – Data Management Book of Knowledge. Provee los detalles específicos para definir, implementar y operar la Gestión y la Utilización de Datos. [1]
  2. TOGAF – The Open Group Architecture Framework. Define el proceso para la creación de una arquitectura de datos como parte de la arquitectura general de una empresa. Puede ser un precursor para implementar la Gestión de Datos. [2]
  3. COBIT – Control Objectives for Information and related Technology. Entrega la Gobernabilidad de Datos como una parte de la Gobernabilidad general del área Tecnologías de la Información. Tiene un modelo para determinar el grado de madurez que tienen los procesos de Gestión de Datos en uso en una organización. [3]
  4. DGI Data Governance Framework. Es un marco de referencia simple para generar la Gobernabilidad de Datos y, provee una estructura lógica para clasificar, organizar y comunicar actividades complejas de toma de decisiones y la ejecución de acciones  relacionadas con los datos de una empresa. [4]

Componentes del DMBOK

En mi opinión una buena opción es la DMBOK, ya que es un marco de referencia para la Gobernabilidad de Datos bien articulado y generado por la organización DAMA – la Data Management Association International fundada en 1980. DAMA Internacional es una organización de voluntarios que se rige por una Junta Directiva Ejecutiva. Los directores son votados por un mandato de 2 años y pueden presentarse a la reelección. El DMBOK es el producto de esfuerzos colaborativos internacionales dedicados a proporcionar la tan necesaria orientación sobre cómo gobernar y administrar los datos y los activos de información.

El modelo DMBOK se muestra en la figura siguiente:

gobernabilidad-de-datos-1

Principios Rectores del Gobierno de Datos

A continuación incluyo los Principios Rectores de la Gobernabilidad de Datos del Data Governance Institute. Estos principios es conveniente considerarlos en todos los programas, procesos y proyectos de Gobernabilidad Datos. Son los principios que ayudan a las partes interesadas —stakeholders– a unirse para resolver los tipos de conflictos relacionados con los datos que son inherentes a cada organización y a establecer de manera exitosa la Gobernabilidad de Datos en la empresa.

1. Integridad. Los participantes en la gestión de datos practicarán la integridad en sus relaciones mutuas. Serán veraces y colaboradores al discutir los lineamientos, restricciones, opciones e impactos en las decisiones relacionadas con los datos.

2. Transparencia. Los procesos de Gobernabilidad de Datos y su gestión serán transparentes. Debe quedar claro para todos los participantes y auditores cómo y cuándo se introdujeron políticas, reglas y controles en los procesos relacionados con los datos.

3. Auditoría. Las políticas, reglas, procesos y controles relacionados con la Gobernabilidad de Datos serán auditables. Se dispondrá de documentación para respaldar los requisitos de auditoría correspondientes a la conformidad —compliance.

4. Responsabilidad. La Gobernabilidad de los Datos definirá las responsabilidades de las decisiones, procesos y controles relacionados con los datos multifuncionales.

5. Stewardship. La Gobernabilidad de Datos definirá las responsabilidades de las actividades de Stewardship que son responsabilidades asignadas individualmente, así como las responsabilidades del grupo de los Data Stewards.

6. Controles y Saldos. La Gobernabilidad de Datos definirá las responsabilidades de una manera que introduzca controles y equilibrios entre equipos de negocios y tecnología, así como entre aquellos que crean / recopilan información, quienes la administran, quienes la utilizan y quienes introducen estándares y requisitos de conformidad.

7. Normalización. La Gobernabilidad de Datos introducirá y apoyará la estandarización de datos de la empresa.

8. Gestión del Cambio. La Gobernabilidad de Datos apoyará las actividades proactivas y reactivas de Gestión del Cambio para los valores de datos de referencia y la estructura / uso de datos maestros y metadatos.

En los negocios, stewardship se puede traducir como “conciencia fiduciaria”. Sterwardship es la responsabilidad personal de cuidar la propiedad o los asuntos financieros de otra persona. Este concepto también es utilizado de una manera más general para referirse a la responsabilidad de cuidar algo que no le pertenece a uno.

Aunque stewardship implica realizar algunas actividades de management, stewardship hace énfasis en la responsabilidad sobre recursos y propiedad ajenos.

Nivel de Madurez de la Gobernabilidad de los Datos

A fin que puedan establecer en que estadio se encuentra su empresa en cuanto a la Gobernabilidad de los datos incluyo la escala siguiente. El determinar en que Nivel de Madurez se encuentra su empresa le ayudará a definir un proyecto que le permita a su organización ir avanzando en su Gobernabilidad de Datos. [5]

 Nivel  Nombre  Características
1 Informal
(Piensa Localmente, Actúa Localmente)
 Existen unas pocas reglas y políticas relacionadas con la calidad y consistencia de los datos. Hay mucha redundancia en los datos, distintas fuentes, formatos y registros.

Existe el riesgo que datos erróneos puedan provocar una mala toma de decisiones o pérdidas de oportunidades.

2 Reactivo
(Piensa Globalmente, Actúa Localmente)
Este el estado inicial de la Gobernabilidad de Datos. Existe mucha actividad y esfuerzo relacionados con la reconciliación de inconsistencias, imprecisiones y datos poco fiables.

Se tienen avances y más experiencia a nivel departamental —gerencias.

3 Proactivo(Piensa Globalmente,       Actúa Colectivamente) Es muy difícil llegar a este nivel. La empresa debe entender el valor de contar con una visión unificada de la información y del conocimiento. La empresa comienza a pensar en desarrollar la Gestión de Datos Maestros —Master Data Management (MDM). Ejemplos: Datos de Clientes, Proveedores, Productos, Repuestos, etc.

La empresa está aprendiendo y preparándose para el nivel siguiente. Está en desarrollo un cambio cultural en la organización.

4 Gobernado
(Piensa Globalmente, Actúa Globalmente)
La información esta unificada en todas las áreas de la empresa. Se cuenta con una estrategia y metodología para la gestión de los datos.

Se ha producido un cambio cultural en la empresa. Los colaboradores han integrado la idea que la información es un activo clave de la empresa.

Cómo Comenzar con la Implementación de la Gobernabilidad de los Datos

Primero es necesario detectar si en su organización existe algún conflicto con los datos, por ejemplo: planes de cuentas contables son distintos, la información de clientes es inconsistente, los existen códigos de repuestos distintos para un mismo elemento, los datos están desactualizados, entre otros.

Establecidos cuales son los elementos con mayor conflictividad se puede iniciar un plan para estandarizar los datos en cuestión, esto es que los mismos campos, reglas de negocios, códigos y semántica sean los mismos para toda la organización.

El plan debe necesariamente contar con el patrocinio de un Ejecutivo de primera línea, ya que inevitablemente se presentarán situaciones en que cada quién defiende sus intereses, señalando que sus definiciones deben ser asumidas por toda la organización, y éste Ejecutivo podrá ayudar a consensuar posiciones en el interés de toda la organización.

Para que el plan funcione es necesario planificarlo como un proyecto, asignando un Jefe de Proyecto y los interesados de las distintas áreas que tienen que ver con los datos en cuestión. El proyecto tendrá las fases siguientes:

  • Identificación de los usuarios y usos de los datos en cuestión.
  • Establecimiento del estándar para los datos en cuestión.
  • Ajuste de los programas —software– en caso de ser necesario.
  • Ajuste de los datos al nuevo estándar, donde corresponda.
  • Capacitación de los Usuarios.

Toda la actividad relacionada con los datos es parte del proceso de negocios MDM —Master Data Management– o Gestión de Datos Maestros; que considera, por lo general, los datos de: Clientes, Proveedores, Materiales y Cuentas Contables. [6]

Referencias

[1] https://www.dama.org/content/body-knowledge

[2] http://www.opengroup.org/subjectareas/enterprise/togaf

[3] http://www.isaca.org/cobit/pages/default.aspx

[4] http://www.datagovernance.com/the-dgi-framework/

[5] http://www.nascio.org/EA/ArtMID/572/ArticleID/190

[6] https://en.wikipedia.org/wiki/Master_data_management

Soporte para Usuarios de Procesos de Negocios – Parte IV Mejoramiento

Introducción

Esta es la cuarta y última parte de la serie “Soporte para Usuarios de Procesos de Negocios”, dijimos anteriormente que este soporte se compone de cuatro servicios, como muestra la figura siguiente:

Soporte 1

en la Parte I de esta serie de artículos señalamos que necesidades de mejoramiento de los Procesos de Negocios se originan por:

  • Mejoras al proceso de negocio.
  • Nuevas reglas de negocios.
  • Cambios legales.
  • Nuevos procesos.

El Mejoramiento / Innovación comprende todas las iniciativas de los Usuarios que permiten mejorar la operación de sus respectivos procesos de negocios, en cuanto a la generación de más valor y más calidad. Estas iniciativas son evaluadas de acuerdo a criterios técnicos y económicos, y son incluidas en un Portafolio de Proyectos o Backlog o Lista de Pendiente, para su eventual implementación.

Se asume que el Mejoramiento es medible cuantitativamente por medio de un Indicador de Performance (KPI), éste está previamente definido y mide si el proceso está operando dentro de los rangos esperados. Luego para medir el impacto del Mejoramiento basta con medir el KPI antes de implementar el Mejoramiento y después de algún tiempo que Mejoramiento está en operación y, comparar ambos resultados.

Hoy están disponibles varias metodologías para BPI, como ser: Lean, Six Sigma, BPR, Kaizen, etc. Muchos autores reconocen que éstas están basadas en herramientas y técnicas ya establecidas, y que por consiguiente BPI es “cualquier mejor práctica que mejora los procesos / operaciones en cuanto a reducir el desperdicio, agilizar el flujo y que permite obtener un mejor entendimiento de los clientes y del proceso propiamente tal”  [1].

Desperdicio, en BPI es cualquier acción, material o elemento, del proceso de negocios, que no aporta a la generación de valor.

¿En qué consiste el Mejoramiento de Procesos de Negocios?

Es un aspecto del Desarrollo Organizacional (OD), en el que una serie de acciones son tomadas por el dueño de un proceso para identificar, analizar y mejorar procesos de negocio existentes dentro de una organización para alcanzar nuevas metas y objetivos, como el aumento de beneficios y rendimiento, reducción de costos, simplificación de las operaciones, mejoras de calidad de los productos y servicios y, nuevos elementos para capacitación de los usuarios. [2].

Del párrafo anterior se desprende que para el Mejoramiento de Procesos de Negocios – Business Process Improvement (BPI)- existen metodologías pero, en nuestras organizaciones es común que se resuelva de acuerdo a la experiencia y preferencias de quien esté responsable del Mejoramiento, y a menudo se confunden los requerimientos de Mejoramiento con  los de Mantenimiento.  El artículo continuará haciendo énfasis en la necesidad de contar con una metodología.

Definición de Metodología

Según busineessdicctionary.com:

“Es un sistema de principios o normas de los que se derivan métodos o procedimientos específicos que pueden utilizarse para interpretar o resolver diferentes problemas, en el ámbito de una disciplina en particular. A diferencia de un algoritmo, una metodología no es una fórmula, sino un conjunto de prácticas”.

Según el diccionario de la RAE:

  1.  f. Ciencia del método.
  2.  f. Conjunto de métodos que se siguen en una investigación científica o en una exposición doctrinal.

Según Wikipedia en español:

La metodología hace referencia al camino o al conjunto de procedimientos racionales utilizados para alcanzar el objetivo o la gama de objetivos que rige una investigación científica, una exposición doctrinal o tareas que requieran habilidades, conocimientos o cuidados específicos. Con frecuencia puede definirse la metodología como el estudio o elección de un método pertinente o adecuadamente aplicable a determinado objeto.

¿Por qué es necesario aplicar el Mejoramiento de Procesos de Negocio?

Este análisis podemos iniciarlos a partir de la afirmación que “toda obra humana es perfectible” [3]; por consiguiente, salvo casos especiales, un proceso de negocios siempre es susceptible de mejorar.

Un segundo aspecto a considerar es que hoy difícilmente existen empresas medianas, grandes y muy grandes que no tengan Sistemas Informáticos en uso. Esto significa que tienen herramientas que apoyan la ejecución de los Procesos de Negocios, luego la habilidad de estructurar el uso –diseño del proceso- de esta herramienta, más el conocimiento y capacidad de las personas en aplicarlo en el día-a-día establecen la generación de valor del proceso.

Por tanto, si la empresa dispone de un software, ERP u otros, esta herramienta estará también en uso en otras empresas y, probablemente, en algún competidor. Por ejemplo: Manager, en  PYME y SAP, en empresas grandes y muy grandes. Entonces, si mi empresa usa el mismo software –herramienta- que mi principal competidor ¿Cómo genero una ventaja competitiva?

Siendo más hábil que mi competencia, en la implementación y ejecución de mis Procesos de Negocios, y en la utilización de la herramienta Software.

Esto es lo que debe llevarnos a revisar una y otra vez el cómo ejecutamos nuestros Procesos de Negocios, para detectar oportunidades de mejoramiento que nos generen más valor.

Otra forma de analizar el uso de las herramientas es reflexionar sobre los casos siguientes y establecer la analogía con el software:

  • Si Ud. tiene una caja de óleos y pinceles, ¿Significa que tiene la habilidad para usarlos como un artista? ¿Todos los artistas pesan los mismo en el mercado del arte?
  • En una orquesta sinfónica hay varias filas de violines, y existe el Primer Violín. ¿Por qué, si todos saben tocarlo?

Se puede generalizar que la herramienta ayuda pero no hace la diferencia, ésta la hace quien mejor la utiliza, quien es más diestro, más hábil, más conocedor.

Metodologías Disponibles

La tabla siguiente contiene las características de las metodologías disponibles para el BPI, más conocidas [4].

Descripción ¿Cuándo se utiliza? Foco
Lean
Es una forma de trabajar que identifica y elimina las acciones y costos innecesarios con el fin de entregar más valor y mejor servicio.
  • Cuándo es necesario obtener resultados rápidamente
  • Cuándo se necesita disminuir tiempos de entrega y mejorar la calidad
  • Proceso
  • Cliente
  • Reducción de defectos
  • Reducción de desechos, desperdicio.
Six Sigma
Un enfoque estructurado para la solución de problemas, basado  en datos y estadísticas
  • Para reducir costos o aumentar el volumen.
  • Cuándo la organización tiene madurez en la captura y análisis de Datos.
  • Cuándo se dispone de los datos correctos y del tiempo necesario para hacer el análisis.
  • Cuándo se dispone de gente debidamente capacitada en Six Sigma.
  • Procesos
  • Clientes
  • Reducción de defectos
BPR
Es un enfoque de transformación de actividades o tareas mediante cambios al proceso
  • Cuando el área TI tiene la mayor posibilidad de conducir el cambio.
  • Procesos
Kaizen
Un enfoque para hacer mejoramientos incrementales de manera continua, creando más valor y menos desperdicios.
  • Cuando se necesita obtener resultados rápidamente.
  • Cuando el equipo de personas pertinente puede coordinarse para hacer una operación relámpago.
  • Procesos
  • Clientes
  • Reducción de defectos
  • Reducción de desechos, desperdicio.
Benchmarking
Es una comparación con una organización externa para visualizar y desarrollar mejores prácticas.
  • Cuando se dispone del tiempo necesario para analizar la información de performance de otras organizaciones.
  • Cuando otras estrategias de mejoramiento son necesarias.
  • Procesos
  • Clientes
  • Reducción de defectos
  • Reducción de desechos, desperdicio.
TQM
Es una forma de trabajaren la que todos los participantes se centran en la calidad, propiciando el éxito a largo plazo a través de la satisfacción del cliente.
  • Cuando re-enfocarse en las necesidades del clientes es necesario.
  • Cuando están en uso sistemas de gestión formales.
  • Procesos
  • Clientes
  • Reducción de defectos
EFQM
Es un marco –framework– organizacional diseñado para mejorar la competitividad utilizando los conceptos fundamentales de TQM.
  • Cuando las auto-evaluaciones y las revisiones de pares son ejecutadas periódicamente
  • Procesos
  • Clientes
  • Reducción de defectos

Propuesta de una Metodología

Mi proposición es una lista de tareas a ejecutar en secuencia, me parece que son válidas para empresas de distinto tamaño, la diferencia se da en la disponibilidad de recursos, es sabido que las PYME tienen considerablemente menos recursos que las empresas grandes; no obstante la necesidad de ser más competitivo y de generar valor es la misma.

A = Aclaración   O = Objetivo  E: Entregable

Tarea 1: Mapa de Procesos de Negocios [5].

  • A: Es necesario tener un “plano de la casa antes de hacer las mejoras”.
  • O: Identificar los procesos de negocios de su empresa.
  • E: Sólo una página que muestre gráficamente sus procesos end-to-end.

Tarea 2: Identificación de Oportunidades de Mejoramiento.

  • A: Asuma que tiene los recursos para hacer todas la mejoras posibles, haga esto personalmente y con el apoyo de sus colaboradores o socios o consultores.
  • O: A partir del Mapa de Procesos identifique, usando su experiencia, cuáles son los mejoramientos posibles en cada uno de los procesos de negocios.
  • E: Una planilla Excel con una lista que tenga las columnas: Procesos, Mejoramiento, Valor esperado del Mejoramiento en dinero (monto Mensual), Valor esperado en Calidad del producto o del servicio (ojalá medir con una estadística o en encuesta).

Tarea 3: Selección y Priorización.

  • A: Aquí es dónde Ud. pone las fichas, haga su mejor apuesta.
  • O: Ordenar la planilla, creada en la Tarea 2, conforme a la combinación de los criterios de Valor, Calidad y a su experiencia.
  • E: Planilla ordenada por prioridad, tal que el primer elemento de la lista tiene la prioridad máximo.

Tarea 4: Ante-proyecto.

  • A: Esta actividad es fundamental para que pueda verificar si está en condiciones su empresa de hacer el mejoramiento.
  • O: Ensaye con la oportunidad que clasificó en primer lugar y determine grosso modo, lo siguiente:
    • Solución conceptual o idea general sobre cómo hará la implementación del mejoramiento.
    • Estime los recursos de personas que necesitará para ejecutar, tanto los internos como los externos.
    • Para los recursos internos verifique si tienen real disponibilidad y conocimien-tos para emprender el mejoramiento.
    • Identifique los riesgos que puede tener este mejoramiento, por ejemplo: oposi-ción interna al cambio, distracción de recursos claves, etc.
    • Genere un calendario y, en lo posible un CANVAS.
    • Haga una estimación de costo.
  • E: Documento con las anotaciones de sus conclusiones para cada uno de los puntos del Plan y/o Hoja o formulario CANVAS[6].

Tarea 5: Decisión de Ejecutar.

  • A: Es el momento del compromiso, si este no se logra es mejor postergar para otra ocasión.
  • O:
    • Analice los pros y los contras de ejecutar o no ejecutar.
    • Asegúrese de realmente disponer de los recursos económico y humanos.
  • E: Comunicación a los interesados sobre la decisión de ejecutar, en caso que esta es la decisión. Informar el alcance, objetivos, fechas de inicio y término más el nombre del Líder del Proyecto de Mejoramiento.

Tarea 6: Proyecto de Implementación.

  • A: Comprende todas las actividades para modificar el Proceso de Negocios de acuerdo a los mejoramientos identificados.
  • O: Aplicar alguna metodología de ejecución de proyectos.
  • E: Los entregables de la metodología.

Algunas consideraciones respecto a esta metodología:

  • El gran beneficio de aplicar, a los distintos tipo de necesidades, una metodología es que ayuda a actuar sistemáticamente, con un cierto orden que permite ir conociendo en profundidad la necesidad y la forma de resolverla.
  • Otro beneficio, es que facilita el trabajo en equipo, ya que todos tienen para su conocimiento las mismas “Reglas del Juego”.
  • Aplicar esta metodología en una PYME significa que los dueños y gerentes son los principales protagonistas.
  • Para el caso de una empresa grande será su área de Tecnologías de la Información (TI) quién por medio de los procesos de Gestión de Demanda y Comités TI liderará las actividades del Mejoramiento.

Definiciones

  • Backlog, o Lista de Pendientes, es la acumulación de actividades o tareas o compromisos que están pendientes de hacer.
  • CANVAS, es un diagrama para describir un modelo de negocio y consiste en nueve módulos básicos que reflejen la lógica que sigue una empresa para conseguir ingresos. Estos nueve módulos cubren las cuatro áreas principales de un negocio: clientes, oferta, infraestructuras y viabilidad económica.
  • Desperdicio,  es todo aquello que no agrega valor al proceso, por ejemplo: residuos, basura, despilfarro, derroche, pérdida de tiempo. En inglés: waste.
  • Proceso de Negocio, Es un conjunto de tareas relacionadas que al completarla permiten entregar un servicio o producto a un cliente. También se define como un conjunto de actividades y tareas definidas, que cuando se ejecutan exitosamente satisface un objetivo de la organización o empresa.
  • End-to-End / Extremo-a-Extremo, es una característica de un Proceso de Negocios hace hincapié en todo el trabajo –tareas- que se debe hacer para lograr el objetivo del proceso. Por lo tanto, de extremo a extremo significa “desde el principio hasta el final” [7].

Bibliografía 

[1] Dr. Zoe Radnor, Associate Professor (Reader) in Operations Management Warwick Business School, University of Warwick, UK.

[2] https://en.wikipedia.org/wiki/Business_process_improvement

[3] https://books.google.cl/books?id=CedJt8C0abYC&pg=PA326&dq=origen++de+la+afirmación+toda+obra+humana+es+perfectible&hl=en&sa=X&ved=0ahUKEwjBo6eO75jOAhXLk5AKHRt3DCEQ6AEIHDAA#v=onepage&q=origen%20%20de%20la%20afirmación%20toda%20obra%20humana%20es%20perfectible&f=false

[4]  https://www.york.ac.uk/admin/po/documents/AIM%20Review%20of%20Business%20Process%20Improvement%20Methodologies%20in%20Public%20Service.pdf

[5] https://msaffirio.wordpress.com/2008/05/22/mapa-de-negocios/

[6] http://www.emprendedores.es/gestion/modelo-3

[7] http://bpm.com/bpm-today/blogs/968-what-is-end-to-end-process

Soporte para Usuarios de Procesos de Negocios – Parte III Capacitación

Introducción

Esta es la tercera parte de la serie “Soporte para Usuarios de Procesos de Negocios”, dijimos anteriormente que este soporte se compone de cuatro servicios, como muestra la figura siguiente.

Soporte 1

en la Parte I de esta serie de artículos señalamos que los tópicos claves de la Capacitación de Usuarios en Procesos de Negocios son:

  • Capacitación en el proceso asignado.
  • Capacitación en las funciones correspondientes al rol
  • Capacitación en las transacciones para ejecutar las funciones asignadas.

Por tanto, el análisis siguiente está circunscrito a la capacitación de los usuarios en la operación de Procesos de Negocios, tanto en sus aspectos de procedimientos, reglas de negocios y software asociado [1].

¿Para qué se Necesita el Soporte en Capacitación de Usuarios?

  • Para asegurar el uso eficaz y productivo de los procesos de negocios.
  • Para hacerse cargo que la gente cambia –rota- de posición de trabajo o de empresa.
  • Empoderar y mejorar la satisfacción de los Usuarios.
  • Minimizar los requerimientos de Soporte Funcional.
  • Facilitar la Gestión del Cambio.
  • Preservar el Activo Conocimiento.

¿Cuál es el Ámbito de la Capacitación de Usuarios en Procesos de Negocios?

En mi concepto la Capacitación en Proceso de Negocios debe considerar los elementos siguientes:

  • Establecer los “cursos” asociados a un Rol.
  • Generar y mantener actualizado el Material de Capacitación.
  • Ejecutar periódicamente los “cursos”.
  • Monitorear el desempeño de los Usuarios.
  • Mantener un registro y estadísticas de la capacitaciones.

Por otra parte, para poder ejecutar lo elementos antes indicados es necesario contar con los recursos humanos necesarios. Las personas que gestionan la Capacitación tienen que tener dedicación exclusiva  a su función y, los generadores de materiales más los instructores pueden ser de dedicación parcial.

En cuánto a qué área asignar la responsabilidad por la Capacitación, esta es deseable que dependa de Recursos Humanos, según señalan las mejores prácticas[2].

Definición de Cursos

A partir del Mapa de Procesos de la Empresa se puede establecer el conjunto de procesos para los que se necesita establecer un programa de capacitación, por ejemplo: Producción, Abastecimiento, Recursos Humanos, etc.

Una vez seleccionado un procesos principal o macro-proceso, identificar los roles que en el participan. Y, para cada rol establecer que funciones / tareas le corresponde ejecutar. Por otra parte, es necesario considerar que un Proceso de Negocios tiene, para los Usuarios, un flujo, reglas de negocios y transacciones (componentes del software o sistema computacional). Así la definición de curso tiene la estructura siguiente:

  • Rol
  • Nombre del Curso
  • Macro Proceso
  • Lista de Funciones / Tareas por Proceso –Subproceso
  • Flujo
  • Reglas de Negocio
  • Lista de Transacciones

Esta definición es la Especificación del Cursos, a partir de ella se tiene que planificar la generación del Curso (Análisis, Diseño, Construcción, Prueba).

Material de Capacitación

El Material de Capacitación [3] tiene que tener en consideración los siguientes objetivos:

  • Enseñar tanto los aspectos operacionales como los computacionales del proceso, el primero se refiere a procedimientos, reglas de negocio, organización, operación, etc. Mientras que el segundo trata los elementos del software, transacciones.
  • El curso debe apoyarse en un ambiente computacional, similar al ambiente productivo / real, que permita ejecutar ejercicios a los alumnos.
  • Dado que los Proceso de Negocios evolucionan, es necesario actualizar el Material de Capacitación en sincronía con los cambios en los Procesos.

Por consiguiente los materiales necesarios de producir para UN curso son:

  • Descripción del Curso, es una especificación que describe el propósito del curso, su contenido, duración, pre-requisitos, los roles a los que aplica.
  • Manual de Procedimientos, flujo, reglas y excepciones, Este documento contiene la descripción del procesos, la de sus funciones, reglas de negocios, diagramas y la identificación de los roles.
  • Uso del Software y Transacciones, material para explicar el funcionamiento del software / transacciones, que apoya la operación de un Proceso de Negocios. Por lo general es una presentación con copias de la pantallas más indicaciones de uso.
  • Manual para el Instructor, instructivo para la persona que dictará el curso, debe incluir la descripción detallada del proceso y de los ejercicios que harán los alumnos.
  • Guión-scriptpara generar el ambiente computacional para los ejercicios, la generación del ambiente computacional para la ejecución de los cursos debe estar automatizada lo más posible, debido a que con cada ejecución de los cursos se alteran los datos y a que la generación del ambiente propiamente tal es compleja.

Definiciones

  • Curso, para la los efectos de la Capacitación de Usuarios en Procesos de Negocios el curso se debe asimilar a un Curso-Taller [4], donde este consiste en presentar un material (la teoría) y, en seguida, practicar la aplicación de este material (los ejercicios en la computadora).
  • Proceso de Negocio, es un conjunto de tareas relacionadas que al completarlas permiten entregar un servicio o producto a un cliente. También se define como un conjunto de actividades y tareas definidas, que cuando se ejecutan exitosamente satisface un objetivo de la organización o empresa.
  • Procedimiento, es una secuencia fija, que define paso a paso las actividades o tareas o funciones (con un inicio y término claramente establecidos), que se debe ejecutar en el orden establecido para obtener el resultado deseado. Es útil contar con una representación gráfica del Procedimiento.
  • Regla de Negocio, es el conjunto de normas, definiciones, rutinas o prácticas que se aplican para operar un negocio y obtener los resultados deseados. Son las guías que determinan como se lleva el día-a-día de las operaciones. Para el caso de Procesos de Negocios las Reglas de Negocio tienen que estar formalmente definidas.
  • Cargo, se refiere a una posición de la estructura organizacional –organigrama- que se asigna a una persona. Un mismo cargo puede estar asignado a varias personas.
  • Rol, es un conjunto de tareas necesarias para ejecutar una o varias funciones. Los roles se asignan a las personas.

Bibliografía

[1] http://www.gestiopolis.com/la-importancia-de-la-capacitacion-y-motivacion-dentro-de-la-empresa/

[2] https://www.apqc.org/knowledge-base/download/361282/PCF_Ver_7.0.2%20%28CIP%29%20rev.pdf – 7.3.4  Develop and train employees (10473), page 15

[3] http://es.wikihow.com/desarrollar-materiales-de-capacitación

[4] http://www.gwp.org/Global/GWP-SAm_Files/Publicaciones/Hacer-talleres-gu%C3%ADa-para-capacitadores-esp.pdf

 

 

 

 

 

 

 

Soporte para Usuarios de Procesos de Negocios – Parte II Infraestructura

Introducción

Este artículo corresponde a la segunda parte de la serie “Soporte para Usuarios de Procesos de Negocios”, dijimos que este se compone de cuatro servicios, como muestra la figura siguiente.

Y también dijimos que  el Soporte Infraestructura incluye el soporte a los componentes de hardware y software básico que tiene asignado el Usuario, como ser: PC, comunicaciones, sistema operativos, aplicaciones de productividad, correo, impresoras, scanners, hand held, smartphones, tablets ycontinuidad de los servicios TI.

¿Para qué se Necesita el Soporte Infraestructura?

El objetivo de este Soporte es asegurar que la Infraestructura de TI tenga los niveles de disponibilidad, sin interrupciones, que el negocio necesita. Cada empresa establece los niveles de soporte en función de los riesgos que puede tolerar, así algunas empresas tienen necesidades 5/8 (5días a la semana con 8 horas diarias) y otras 7/24 (7 días a la semana con 24 horas diarias).

Los elementos que generalmente se incluyen en la Infraestructura TI:

  • Plataforma de Hardware
  • Software de Sistemas
  • Software de Base de Datos
  • Redes / Comunicaciones

Es necesario distinguir que el Soporte de Infraestructura tiene una parte visible para los usuarios y otra que es opaca, es decir es visible solo cuando se produce una falla.

Así se tiene que el Soporte de Infraestructura que es Visible para los Usuarios es el referido a:

  • Hardware: Desktop, NoteBook. Tablets, Smartphone, impresoras, etc.
  • Software: Sistema Operativo Desktop / Notebook, Aplicaciones, Office, Browser, etc.
  • Redes: Enlaces, Internet, WIFI, etc.

Por su parte la infraestructura Opaca a los Usuarios, dado que atiende requerimientos técnicos propios de la operación de un sistema computacional, que son responsabi-lidad del área Informática. Los elementos que considera son:

  • Hardware: Servidores, Unidades de Almacenamiento de Datos, Equipos de Comunicaciones, Impresoras, UPS, etc.
  • Software: Sistemas Operativos Servidores, Administradores de Bases de Datos, Software para Redes, Programas para Monitoreo, Sistemas para Virtualización, Seguridad,etc.
  • Redes: Firewalls, Routers, Switches, Video, Wireless, Seguridad, Cloud etc.

Organización del Soporte de Infraestructura [Visible]

De acuerdo a lo señalado en el párrafo anterior se tiene un soporte de infraestructura Visible y otro Opaco, nos referiremos sólo al Visible puesto que, es el que se entiende con los Usuarios.

Mesón de Ayuda

Por lo general es un servicio provisto por un Call Center junto con equipo de Técnicos –Field Support. Este servicio de puede ser provisto con recursos propios de la organización o mediante la contratación de servicios a un tercero.

El Call Center recibe los requerimientos de los Usuarios, sea por medio de una llamada telefónica o un eMail, identifica al Usuario, registra su requerimiento, le asigna un código de identificación –ticket-, lo clasifica, si puede resuelve el problema o si no lo deriva a un Técnico.

En algunas operaciones este Call Center además de aceptar los requerimientos para atender problemas de Infraestructura, acepta también requerimientos de Soporte Funcional.

Field Support[1]

Es un equipo de Técnicos, especialistas en los elementos de hardware, software y redes que conforman el equipamiento de un Usuario típico. Es común que este servicio sea provisto al Usuario en su lugar de trabajo –in situ, en los días, horarios, prioridades, tiempos de respuesta y tiempos de solución convenidos en los SLA pertinentes.

Este equipo puede estar compuesto por personal del área Informática o por empresas proveedoras de servicios.

Operadores

Para los caso que un determinado proceso de negocios requiera operar con sistemas computacionales con o sin intervención de usuarios, y en horarios fuera de oficina, fines de semana, feriados, etc. Por ejemplo: Preparación de despachos a clientes, generación de informes de cierres contables, traspaso de información desde un sistema productivo a uno de Business Intelligence.

Este tipo de procesos necesita la supervisión de un técnico responsable del monitoreo de una infraestructura computacional, este es el Operador[2]. El puede intervenir directamente sobre los trabajos que se están ejecutando en algún servidor en el que funciona el software que sustenta los procesos de negocios.

Los usuarios responsables de este tipo de proceso, a menudo denominados procesos batch o de fondo o background, comprueban si éste terminó correctamente, en caso de problemas de ejecución contactan a los Operadores. A su vez los Operadores monitorean las ejecución de los procesos batch y, en caso de problemas se comunican con los Usuarios responsables.

También es usual que los Operadores atiendan requerimientos de Usuarios que surgen en horarios en los cuales no opera el Mesón de Ayuda, por ejemplo: un fin de semana.

Acuerdos de Nivel de Servicio (SLA)

Los Acuerdo de Nivel de Servicio, comúnmente denominados SLA (Service Level Agreement) [3] por su denominación en inglés, consisten  en:

  • Un acuerdo, formal o informal, entre el Negocio (Usuarios) y el Área de Informática o bien entre el Área de Informática y un Proveedor de Servicios (Comunicaciones, Cloud, etc.).
  • Los SLA se definen, con el detalle de su alcance, en algún tipo de documento, como ser un contrato de prestación de servicio, un memorándum o un procedimiento.
  • El SLA aplica a servicios explícitamente definidos.
  • El SLA tiene una expresión numérica, que se refiere a un rango entre un valor mínimo y uno máximo que se usa para medir performance.
  • Los SLA pueden estar compuestos por varias métricas de performance que se corresponden con los niveles de servicio acordados.
  • También puede incluir acuerdos sobre solución de problemas, obligaciones del Cliente / Usuarios, garantías, recuperación de desastres –planes de contingencia- y, condiciones para dar término al SLA.

Ejemplos de SLA

  • Cantidad y porcentaje de incidentes que interrumpen la operación de los procesos de negocios críticos.
  • MTTA (Mean Time To Attend), tiempo medio desde que se registra un incidente hasta cuando el Técnico toma contacto con el Usuario.
  • MTTR (Mean Time To Recover), tiempo medio desde que el Técnico comienza a tratar el problema hasta cuando lo resuelve a satisfacción del Usuario.
  • Uptime, porcentaje del tiempo efectivo de funcionamiento de un sistema respecto al tiempo de funcionamiento programado.
  • Porcentaje de incidentes resueltos de acuerdo al SLA.

Definiciones

  • Mesón de Ayuda. En inglés Help Desk, es un conjunto de recursos tecnológicos y humanos, para prestar servicios con la posibilidad de gestionar y solucionar todas las posibles incidencias de manera integral, junto con la atención de requerimientos relacionados a las Tecnologías Computacionales.
  • Field Support. Son las personas técnicas que reparan , mantiene, e instalan una variedad de productos de software y hardware. Son los responsables de ayudar a los clientes en sus necesidades de problemas con su equipamiento computacional o con la instalación de nuevos elementos. Es la persona responsable de monitorear y controlar los sistemas que constituyen la infraestructura computacional de una empresa. Sus responsabilidades incluyen la detección de problemas de software y hardware, el monitoreo de los procesos batch, el mantenimiento y mejoramiento de la performance y de la disponibilidad de los servidores y la red computacional. También en algunas empresas agregan las labores referidas a: generación de respaldos –backups-, cuidado de la sala de computadores y proveer apoyo a los usuarios, en particular a los procesos batch o a situaciones que ocurren cuan el Mesón de Ayuda está fuera de servicio.
  • Proceso Batch[4]. En inglés batch processing, o modo batch, o proceso de fondo, o procesamiento por lotes corresponde a la ejecución de un programa sin el control o supervisión directa del usuario (que se denomina procesamiento interactivo). Este tipo de programas se caracterizan porque su ejecución no precisa ningún tipo de interacción con el usuario. Generalmente, se utiliza en tareas repetitivas sobre grandes conjuntos de información, ya que sería tedioso y propenso a errores realizarlo manualmente.

Bibliografía

[1] http://aim.learnlink.org/00/10/07/00/book.htm
[2] http://whatis.techtarget.com/definition/computer-operator
[3] https://en.wikipedia.org/wiki/Service-level_agreement
[4] https://es.wikipedia.org/wiki/Procesamiento_por_lotes

 

 

 

 

Soporte para Usuarios de Procesos de Negocios – Parte I Soporte Funcional

Una vez implementado un proceso de negocios —cuando ya está en uso­­— es necesario asegurar que éste se utiliza conforme a su diseño, es decir que, cada función es ejecutada de acuerdo a su flujo, roles y reglas de negocio.

La práctica nos señala que de no mediar acciones específicas la ejecución del proceso se altera o cambia, en el uso del día-a-día; sea por motivos de ambigüedad en las definiciones, por falta de entendimiento y motivación, por rotación de las personas y/o, por razones y gustos de las personas que los ejecutan. Por tanto las preguntas que me hago son[1]:

  1. ¿Qué hacer para que un proceso de negocios sea utilizado de acuerdo a su diseño por períodos prolongados, asumiendo que se tiene rotación de la gente?
  1. ¿Qué hacer para mejorar el proceso de negocios, de manera que aumente la generación de valor y la satisfacción de sus usuarios?

Para la primera pregunta mi proposición es:

  • Contar con un servicio de Soporte a Usuarios, que atienda sus problemas de uso, que proponga y habilite soluciones de ínterin –workaround– para situaciones críticas, que resuelva problemas de software (errores de programas, cambios de parámetros y errores de sistemas), y que ayude a identificar oportunidades de mejoramiento o innovación.
  • Establecer programas de capacitación que se realicen periódicamente, tanto para acoger a los nuevos usuarios, como para perfeccionar a los antiguos.
  • Habilitar auditorias o seguimientos de ejecución para todos los procesos de negocios, independientemente si están o no relacionados con la Contabilidad.

Requerimientos de Soporte

La lista siguiente identifica los requerimientos de Soporte más comunes que tiene un usuario:
Soporte 3


Soporte de Procesos de Negocios

Como se desprende de la tabla anterior son varios los tópicos para los cuales un Usuario necesita Soporte, a saber: uso del proceso, uso de las transacciones, tratamiento de las emergencias, disponibilidad de la infraestructura, capacitación y mejoramiento / innovación de su proceso [1].

El Soporte de Procesos de Negocios es indispensable para optimizar la utilización de los Sistemas Informáticos y de los Procesos de Negocios, que se logra con:

  • Mecanismo para resolver oportunamente los problemas que se presenten. ⇒ Soporte Funcional.
  • Plataforma computacional y de comunicaciones que opere con los niveles de servicio requeridos por el negocio ⇒ Soporte Infraestructura.
  • Usuarios conocedores de sus procesos de negocios y de las herramientas informática que usan. ⇒ Capacitación.
  • Facilidad para generar modificaciones a las funciones existentes y/o para incorporar nuevas funciones. ⇒ Mejoramiento Contínuo / Innovación.

Para organizar la prestación de estos servicios los agruparé de la siguiente forma:

Soporte 1

  • Soporte Funcional: incluye soporte al de Uso del Proceso, soporte al Uso de la Transacciones (Software), y apoyo para Emergencias. Una extensión de esta definición es la provista por COBIT [2] para el proceso DSS02 Manage Service Requests and Incidents:

“Proveer respuestas efectivas y oportunas a los requerimientos de los Usuarios y resolver todo tipo de incidentes. Restaurar el servicio / operación normal, registrar y satisfacer los requerimientos de los Usuarios; y documentar, investigar, diagnosticar, escalar y solucionar los incidentes.”

  • Soporte Infraestructura: incluye el soporte a los componentes de hardware y software básico que tiene asignado el Usuario, como ser: PC, comunicaciones, sistema operativos, aplicaciones de productividad, correo, impresoras, scanners, hand held, smartphones, continuidad de los servicios TI, etc.
  • Capacitación: me refiero a la capacitación formal que debe tener cualquier usuario al cual se le asigna uno o varios roles a ejecutar, en el marco de un proceso de negocios. Dejo explícitamente excluidas las opciones del learning by doing y el auto-aprendizaje.
  • Mejoramiento / Innovación: comprende todas las iniciativas de los Usuarios que permiten mejorar la operación de sus respectivos procesos de negocios. Estas iniciativas son evaluadas de acuerdo a criterios técnicos y económicos, y son incluidas en un portafolio de proyectos o backlog, para su eventual implementación[3]

 

I: Soporte Funcional

A continuación desarrollaré el tópico Soporte Funcional, en artículos posteriores trataré el Soporte de Infraestructura, Capacitación y Mejoramiento / Innovación. El desarrollo lo haré al modo socráctico, atendiendo a las siguientes preguntas:

  • ¿Para qué se necesita el Soporte Funcional?
  • ¿Cómo organizar el Soporte Funcional?
  • ¿Qué modelo usar para proveer el Soporte Funcional?
  • ¿Cuáles son los Objetivos del Soporte Funcional?
  • ¿Cómo medir el cumplimiento de los objetivos del Soporte Funcional?

¿Para qué se Necesita el Soporte Funcional?

Para mejorar la utilización de los Sistemas Informáticos asociados a los Procesos de Negocios, esto significa:

  • Aumentos de productividad.
  • Generación de valor (ROI).
  • Mejor calidad de vida para la Usuarios.
  • Imagen positiva del Área de Sistemas.
  • Mejor disposición al cambio.

¿Cómo Organizar el Soporte Funcional?

En forma esquemática, para que una persona pueda operar un proceso de negocios o parte de uno, necesita:

  • Elementos Generales
    • Roles
    • Soluciones Ínterin
    • Emergencias
    • Planes de Contingencia
  • Elementos Funcionales
    • Funciones
    • Procedimientos
    • Reglas de Negocios
    • Documentación de los Procesos de Negocios
  • Elementos Informáticos
    • Transacciones
    • Software
    • Documentación de los Sistemas

Por consiguiente, entiendo por Soporte Funcional al “conjunto de personas y procesos que ayudan al Usuario a superar una dificultad o problema, en cualquiera de los tópicos de la lista anterior”.

Por otra parte, la habilitación de una estructura de soporte debe tener en cuenta para su implementación la complejidad de los problemas a resolver y el costo de los profesionales que los resuelven, al respecto un par de comentarios:

  • Mientras más complejo es el problema mayor es el tiempo necesario para resolverlo.
  • Mientras más complejo es el problema se necesita un profesional con mayores conocimiento y, por ende con un costo mayor.
  • La práctica nos indica que los problemas simples son entre un 50 a 60% de los problemas formalmente reportados. [4]

Teniendo en cuenta los comentarios –hipótesis- anteriores es que resulta conveniente establecer un modelo de Soporte Funcional con profesionales con distintos perfiles y experiencias y con un mecanismo de escalamiento.


¿Qué modelo usar para proveer el Soporte Funcional?

Un modelo que se usa frecuentemente es el que considera que una parte de los problemas es resuelto por un colaborador del negocio, cuyo foco es resolver los tópicos relacionados con el “uso” u “operación” del proceso de negocio, a este profesional se le denomina Key User, asumimos que el resolverá la mayor parte de los problemas pero no todos; y, el soporte que el presta lo denominamos Soporte Nivel 1.

Todos los problemas que el Key User no pudo resolver los transfiere –escala– al Soporte Nivel 2, que es provisto por un Consultor de Soporte cuyo foco es resolver en el menor tiempo posible el problema, sea con una solución de ínterin –workaround– o una solución definitiva, normalmente recibe el 40% de requerimientos reportados y resuelve el 75% de ellos.

Aquellos requerimiento que el Consultor de Soporte no resuelve, que corresponden, aproximadamente, al 10% de los requerimientos reportados, son escalados al Soporte Nivel 3, que es prestado por un Consultor Funcional, cuyo foco es encontrar la solución definitiva y se espera que resuelva todos los problemas que le llegan.

En resumen, para atender los requerimientos de Soporte Funcional de procesos de negocios recomiendo utilizar un modelo con tres niveles de atención, partiendo por el Nivel 1, cuyo énfasis es resolver problemas de uso que se le presentan a un Usuario. El Nivel 2 está para tratar los requerimientos que el Nivel 1 no pudo resolver y su foco es diagnosticar y generar soluciones de ínterin. A su vez el Nivel 3 está para atender los requerimientos que el Nivel 2 no pudo solucionar “definitivamente” y su objetivo principal es corregir errores informáticos, es decir bugs.

Soporte 2
Ejemplo de Modelo para Entregar Soporte Funcional

Esquemáticamente tenemos:


¿Cuáles son los Objetivos del Soporte Funcional? y ¿Cómo medir el cumplimiento de los objetivos del Soporte Funcional?

Desde la perspectiva de la imagen que pueda tener un Área Informática, de cualquier empresa, en mi experiencia, esta se establece por la opinión que los Usuarios dan sobre los procesos y sistemas, con los que operan habitualmente y, el Soporte que se les preste. Comúnmente, los Jefes y Gerentes se forman una opinión sobre éstos mediante una comunicación del tipo word of mouth[5], con sus respectivos colaboradores. Esto lleva a que si el Área de Informática no cuenta con procesos formales y medibles el trato con sus Clientes se hace muy complicado pues, se basará en percepciones y no en realidades.

Como todo proceso el Soporte Funcional, para Usuarios de Procesos de Negocios, debe tener un conjunto de objetivos nítidos y acordes con las necesidades del negocio. Como asimismo un conjunto de parámetros o resultados a medir. La necesidad de contar con los Objetivos y las Mediciones formalmente definidas y sistemáticamente medidas, es para dar una base objetiva del rendimiento del proceso en cuestión y superar la toma de decisiones basadas en percepciones y/o reclamos estridentes.

Tanto ITIL como COBIT proveen una lista amplia de objetivos y mediciones (indicadores o KPI) para el proceso de Soporte Funcional, a modo de ejemplo incluyo la tabla siguiente:

 

Ejemplo de Indicadores de Performance para el Soporte Funcional
Ejemplo de Indicadores de Performance para el Soporte Funcional

Responsabilidad del Usuario

Cuando un Usuario pide ayuda, cualquiera que sea la necesidad y el mecanismo para solicitarla, el tiene las responsabilidades siguientes:

  • Esta haciendo la petición de soporte después de haber intentado por todos los medios a su disposición resolver su problema, entiéndase: manuales, guías, consultas en Internet, consultas a colegas y ayudas help en línea.
  • Haber recibido oportunamente la capacitación para operar con el proceso de negocios para el cual está pidiendo ayuda.
  • Tiene recopilados todos los antecedentes que describen su problema, idealmente es capaz de reproducirlo a voluntad.
  • Ha establecido el impacto real que genera su problema a su persona, a su proceso, a su área organizacional y, a su empresa.

Prioridades

Se entiende que los distintos requerimientos de soporte difieren en el impacto que producen al negocio, entendiendo que para el Usuario el impacto será siempre muy alto, por el efecto personal que le provoca. Pero no necesariamente es así para su empresa.

La priorización de los requerimientos tiene su justificación en el impacto económico al negocio que pueda provocar un problema en algún proceso de negocios. A mayor impacto económico, mayor prioridad.

Por otra parte, mayor prioridad significa mayor costo en la solución, pues es necesario asignar recursos con más experiencia y conocimientos y, también podrá ser necesario involucrar mayor cantidad de personas.

Soporte 04
Ejemplo para asignar Prioridades

A continuación incluyo un tabla, a modo de ejemplo, para priorizar los requerimientos de Soporte.


Definiciones
  • Usuario: en Tecnologías del Información el término Usuario –Usuario Final, User, End User– se emplea para identificar a las personas para quienes se desarrolló un producto de hardware o software. Esta denominación se ha extendido a las personas que operan un determinado proceso de negocios.
  • Key User: es un Usuario que tiene un conocimiento profundo en un determinado dominio funcional, incluyendo los procesos de negocios de éste, ha trabajado o está trabajando con Consultores en proyectos de implementación referidos a su dominio. Y, es a la primera persona a quien deben contactar los usuarios que tengan preguntas o problemas concernientes a su dominio de conocimiento funcional y de procesos.
  • Consultor de Soporte: son Key User, Analistas o Profesionales con una amplia experiencia en la utilización de los procesos de negocios de su empresa -procedimientos y sistemas-. Están 100% de su tiempo asignado al área de Soporte, y proveen el Soporte Nivel 2.
  • Consultor Funcional: son consultores expertos en los componentes sistémicos de los procesos de negocios de de su empresa, principalmente de algún ERP. Pertenecen, normalmente, a la Gerencia de Proyectos. Atienden los requerimientos de Soporte Nivel 3.
  • Incidente: La Information Technology Infrastructure Library (ITIL) lo define como “cualquier evento que no es parte de la operación habitual de un servicio que causa, o puede provocar, una interrupción o una reducción de la calidad del servicio˝ .[6]
  • Problema: ITIL lo define como “la causa desconocida de uno o más incidentes, a menudo identificados por el resultado de incidentes similares”.

Bibliografía

[1] businessdictionary.com > customer support http://www.businessdictionary.com/definition/customer-support.html
[2] COBIT 5 Proccess Reference Guide
[3] Business Process Improvement Framework and Representational Support, Azeem Lodhi, Veit Koppen, and Gunter Saake https://scholar.google.com/scholar?q=Business+Process+Improvement+Framework+and+Representational+Support&hl=en&as_sdt=0&as_vis=1&oi=scholart&sa=X&ei=sYkqVefAIIKiNrqhgJAG&ved=0CBsQgQMwAA
[4] https://blog.bufferapp.com/10-customer-experience-metrics-every-successful-company-tracks
[5] http://en.wikipedia.org/wiki/Word_of_mouth
[6] https://iaonline.theiia.org/auditing-the-incident-and-problem-management-process

 

[1] Nota: Este tema del Soporte lo trataré en una secuencia de publicaciones en mi blog http://www.msaffirio.wordpress.com