Mario Saffirio

Si hacemos con Google una búsqueda para Software Factory encontraremos que en Sudamérica existen muchas empresas que así se denominan; sin embargo, casi ninguna explica cual es su proceso de fabricación del software, y este me parece que es esencial conocerlo de antemano a objeto de calibrar la calidad del software que puedan generar. Las referencias de clientes y proyectos anteriores son una condición necesaria pero no suficiente, por la simple razón que Ud. no sabe si la misma gente que trabajó en los proyectos que le presentan como exitosos trabajarán también para Ud. Por tanto lo que una fábrica de programas tienen para garantizar su calidad y capacidad es la disposición a  firmar contratos con SLA (Service Level Agreement).

Modelos de Operación de la Fábrica de Programas
La Fábrica de Software refiere al proceso de producir programas con rapidez y calidad a través de procesos conocidos, repetibles y gestionables, y principalmente, mejorables de modo continuo, no sólo por la incorporación de técnicas y herramientas en el desarrollo del software, sino también porque se mantiene constantemente el foco sobre el  proceso de producción y de cada uno de los pasos que esto acarrea. El término fábrica indica un compromiso a largo plazo, esfuerzos integrados - por encima de proyectos individuales- para mejorar las operaciones relativas al software.[1]

La Fábrica de Software es un tipo de tecnología generativa cuyo fin es reducir la complejidad del software y, a la vez, simplificar su producción. Esto se logra mediante: 

1. La abstracción de los aspectos complicados del software.
2. La producción en serie del software.

 Es decir, la Fábrica de Software es la transición desde la producción artesanal, artística, de software a una producción industrial semi-automatizada, que asegura la calidad y el mejoramiento continuo usando especificaciones formales, metodologías, estándares, y teniendo una mirada permanente en la evolución de la tecnología. [2] A continuación, incluyo un modelo, a modo de ejemplo, de una Fábrica de Software estructurada en base a un Modelo de Madurez de tres niveles. 

Nivel de Madurez

• Indicadores de la Producción de Software

Repetible           

• Complejidad de la Producción de Software: La Fábrica de Software aplicaun enfoque de producción sistemático y repetible.
• Conciencia sobre el Proceso: Prácticas individuales y de uso común –diseñadas- son aplicadas, esto es que la arquitectura (operacional) de la Fábrica de Software no está totalmente definida.

Gestionada 

• Complejidad de la Producción de Software: Se aplica a la Fábrica de Software un enfoque reflexivo y adaptativo, la fábrica cuenta con una arquitectura establecida y administrada, se opera con un enfoque de líneas de producción.
• Conciencia sobre el Proceso: Un arquitecto desarrolla la visión de largo plazo de los metamodelos y de las herramientas a utilizar, la producción del software es predictiva, porque está bajo control. 

Optimizado

• Una realimentación –feedback- continua contribuye al mejoramiento de la capacidad de producción y del ROI.

La Conexión con el Mantenimiento
En toda organización grande que cuente con componentes de software como ERP, CRM, SCM, etc. existen al menos dos necesidades que implican desarrollo de software:

 En cuanto a los beneficios, es necesario evaluarlos cuantitativamente, y para este efecto es necesario establecer contractualemente un SLA (Service Level Agreement) [3], esto es un acuerdo de niveles de servicios pre-definidos. Según el IEEE los SLA se deben establer foco es áreas específicas como ser: calidad del producto, calidad del proceso, calidad de la post-procucción, etc.[4].

Conviene tener en consideración que entre un contrato tradicional de servicios y un SLA existe una diferencia sutil pero sustnacial, los SLA son también servicios, pero son distintos contractualmente, ya que un SLA define más detalladamente el requerimiento, en términos de incentivos y penalidades que se obtienen por el cumplimiento o incumplimiento de niveles de servicios establecidos cuantitativamente, por ejemplo: tiempos de respuesta, tamaño del backlog, etc.. 

Referencias

[1] http://cuartageneracion.blogspot.com/2006/04/cuando-software-factory-no-es-una.html

[2] http://www.softmetaware.com/oopsla2004/langlois.pdf

[3] http://en.wikipedia.org/wiki/Service_Level_Agreement

[4] http://findarticles.com/p/articles/mi_m0SVI/is_3_11/ai_n13821992/print

Como primera definición entenderemos que un workflow se refiere a un mecanismo computacional que permite controlar una secuencia de acciones o un procedimiento que ejecutan varias personas. En general cuando se modela un proceso de negocios, supongamos que usamos un modelo EPC, se definen las interacciones entre eventos, tareas (transacciones) y personas. Pero, no se considera explícitamente la secuencia de ejecución en términos de responsables y plazos. Así se tiene que puede estar perfectamente modelado y operativo, por ejemplo, un proceso de cobranza en un sistema computacional, no obstante este no controla una secuencia de ejecución, lo que normalmente se establece mediante un procedimiento “administrativo”, con esto estamos señalado que es primero un elemento externo al proceso “computacional” y segundo que es un conjunto de actividades no controladas computacionalmente y por tanto es manual. Luego haciendo un análisis informal podemos decir que la implementación de un proceso de negocios habilita la “herramienta” y el procedimiento estable el “uso” de la herramienta.  Y, es aquí donde surge una dificultad técnica y práctica. Técnica porque la implementación de un Proceso de Negocios es un proyecto y el mecanismo de control de ejecución es otro, que precisa de la generación de un Workflow. Y, práctica porque las personas deben ocupar de manera adecuada la herramienta para obtener los resultados de negocios y porque se necesita tener cierta seguridad que las cosas se hacen según un diseño predeterminado (o normativa). 

Definición de Workflow
El concepto de workflow en la historia moderna se remonta a 1912 cuando F. Taylor  y a H. Gantt,  juntos iniciaron el estudio de la organización racional de trabajo, referido al ámbito de la manufactura. Sin embargo, la acepción que nos interesa es la referida a sistemas informáticos de modo que incluyo la que utiliza la workflow.org, que dice

 “Workflow es la automatización de un proceso de negocio, sea parcial o totalmente, durante el cual documentos, información o tareas son pasados desde un participante[1] a otro para la ejecución de otra acción, de acuerdo a un conjunto de reglas procedurales” [1]  La Relación Transacción – Workflow Un Workflow debe permitir establecer un mecanismo de control que permita asegurar una secuencia de acciones y que estas acciones las ejecuten determinadas personas en un plazo pre-establecido. Nótese que me estoy refiriendo a los workflows donde participan personas, Human WorkFlow, también existen los System WorkFlow, donde no ya participación de humanos y que antes llamábamos Batch. En el diagrama siguiente podemos observar los elementos básicos que conforma un workflow: 

Este diagrama esta basado en los diagrama de Petri, que muestran Acciones, en este caso Transacciones, eventos y esperas. Claramente esa es una sobre-simplificación de la realidad ya que:

• No muestra las personas que ejecutan las acciones
• Muestra como una unidad transacciones y eventos cuando en la práctica las transacciones las ejecuta un programa, por ejemplo el ERP, y el control de eventos y espera los maneja el software denominado precisamente Workflow.

Por tanto una manera más realista de representar esta relación puede ser:

En este diagrama se evidencia que la activación de los eventos (evt) y de las transacciones (Trx) son activados por las personas (Operador), y que los tiempos de espera (Wait) dependen de las personas, esto es cuando terminan o comienzan una acción.

También este diagrama nos permite distinguir que existen tres ámbitos de software distintos:

• El Sistema Transaccional, que son los ERP, CRM, o cualquier sistema que opera las transacciones, p.ej.: definir un nuevo cliente, registrar una orden de compra, hacer un registro contable, etc.

• El Sistema de Control de Secuencia, este es el que permite establecer el flujo de operación o workflow, identificando los Operadores, los eventos que activan las operaciones siguientes, los tiempos de espera y la verificación de condiciones de ejecución (Autorizaciones, V°B°, verificación de límites, plazos de ejecución, etc.), A este componente se le demonina Workflow, aunque como se vé no tiene todos los elementos para operar.

• Mecanismo de Comunicación, se refiere a la comunicación entre el Sistema transaccional y el Sistema de Control de Secuencia. Hoy se esta implementado por medio de los WEB Services.

 Modelo de Workflows
Considerando que en un workflow intervienen personas y muchos componentes de software es dable esperar que un sistema de está naturaleza es complejo, a modo de referencia incluyo el modelo desarrollado por la Workflow Management Coalition [2], esta organización en la que participan a desarrolladores y universidades está operando desde 1993. 

Aplicación de los Workflows
Las aplicaciones o usos de workflows que indico a continuación corresponden a situaciones que he experimentado en mi quehacer profesional y por tanto son limitadas. En todo caso estas definiciones pueden ayudar a determinar el alcance funcional de algún software que se esté evaluando. 

Workflows Consuetudinarios, son las secuencias de operación que se establecen simplemente por el uso y la costumbre. 

Woorkflows Manuales, son los que se establecen en un documento que contiene reglas, secuencias de operaciones, listas de datos posibles, identificación de los V°B°, etc. y también incluyen un diagrama de flujo del proceso. Este tipo de documento es lo que se llama Procedimiento. En este procedimiento pueden intervenir sistemas computaciones como ser: correo electrónico, planillas de cálculo, ERP, etc. El primer caso que recuerdo de este tipo de worflows fue el de Ordenes de Compra de Importación que se implemento usando correo electrónico en Sonda en la década de los 80. 

Workflows Implícitos, estas son secuencias de operación que la lógica de un sistema sugiere utilizar, normalmente corresponden a un proceso de negocios, por ejemplo la secuencia: Cotización à Nota de Venta à Picking à Despacho à Factura à Pago. Los llamo implícitos porque permiten establecer una secuencia entre una transacción y la siguiente, pero no controlan que persona es responsable de ejecutar cada transacción y en que período de tiempo. Casos como este los ví en  algunos sistema ERP como Microsoft Solomon (hoy es Dynamics) y SAP Business One. 

Workflow Documentales, estas son secuencias típicamente relacionados con un documento, sea para la aprobación de su distribución o para autorizar algún tipo de operación. Por ejemplo: autorizar la publicación de una nueva norma, definir la creación de un nuevo código de productos. Estos workflow se generan con el soporte de algún software como ser Lotus, SAP KM, etc. que básicamente controlan la secuencia de ejecución y operan sobre un formulario, el que van pasando de persona en persona, sea para completar datos o para dar autorizaciones (V°B°). 

Workflow de Aplicaciones, son aquellos que vienen incluidos en una aplicación con secuencias pre-establecidas y con la posibilidad de parametrizarlos, esto los he encontrado en los ERP y son los que claramente corresponde a un workflow según lo plantean las organizaciones que están definiendo los estándares para los workflows, Estos se encuentra en sistemas como  SAP ECC. 

Workflow ad-hoc, estos son los que una organización puede utilizar para diseñar y construir a la medida, se supone que la ventaja competitiva las corporaciones hoy la obtienen por medio de la innovación en sus procesos de negocios, es decir en la manera como ejecuta sus operaciones. y es aquí donde entran con fuerza los Workflows porque con ellos es posible establecer secuencias de operación controlables y medibles. Actualmente estoy con un grupo de colegas explorando SAP Guided Procedures para desarrollar estos Workflows ad-hoc. 

Nota: Las referencias a productos corresponden a los que he utilizado y utilizo en mi trabajo profesional.   

Referencias
[1] Workflow definition http://www.e-workflow.org/ 
[2] Workflow Management Coalition  WFMC http://www.wfmc.org/about/welcome.htm

[1] Participante es igual a recurso humano o recurso máquina.

En general quienes trabajamos en el Área Informática estamos de acuerdo que el Conocimiento [1] es un asunto de la mayor importancia  y, ya muchos ejecutivos se hacen la pregunta:¿Cómo mantener un conjunto de conocimientos en el Área Informática independientemente de la rotación de su personal y que además crezca?  El Conocimiento es el insumo base para desarrollar las funciones de cualquier profesión, esto por la simple razón que las máquinas y las herramientas, en alguna parte de la cadena, las operan las personas.Y, por tanto se necesitan personas que “sepan” usar las herramientas y las máquinas. 

En toda profesión existe un conocimiento disponible en distintos medios: libros, manuales, carreras universitarias o técnicas, cursos, postgrados, e-learning, certificaciones y un largo etcétera. Este tipo de conocimiento se denomina Conocimiento Explícito [2]. 

Por otra parte también se sabe que no basta con tener el conocimiento teórico – el que obtenemos del Conocimiento Explícito. A este ingrediente faltante le llamamos práctica, experiencia, trayectoria, etc. e implícitamente estamos diciendo que la persona sabe porque ya lo ha hecho. Esto es la persona ha tenido la ocasión de poner en práctica su Conocimiento Explícito. Sucede que en el proceso de aplicar un conocimiento a una situación real se aprende pero, también hay actividades que por el solo hecho de realizarlas generan conocimiento, por ejemplo para aprender a andar en bicicleta es necesario intentarlo de otra manera no resulta. Este tipo de conocimiento surgido de la práctica, normalmente se genera sin que seamos concientes de él, por eso se le denomina Conocimiento Tácito [3].  

Por tanto para establecer cualquier estrategia para la retención del Conocimiento tenemos que tener en consideración la existencia de estas dos categoría de Conocimiento. Y, entonces resulta claro la retención del conocimiento pasa por: 

• El traspaso del Conocimiento Explícito a las personas.
• El traspaso del Conocimiento Tácito de una persona a otras personas.
• La transformación del Conocimiento Tácito en Explícito.

 Para establecer un método que permita retener el conocimiento del personal de Informática y a la vez incrementarlo necesitamos responder a las siguientes preguntas 

• ¿Qué entenderemos por Activo Conocimiento?
• ¿Cuáles son los componentes de inventario de conocimientos relevantes para el Área Informática?
• ¿Cómo modelar la generación de Conocimiento?

 Capital Intelectual y Activo Conocimiento
Muchos investigadores han reconocido el Capital Intelectual, que consiste en elementos medibles no financieros e información relacionada, capaz de generar valor a la empresa. De hecho lo definen como: “conocimiento, experiencias, habilidades, y activos soft asociados, en vez del capital físico o financiero”. Por esto el Capital Intelectual es un poderoso activo de la empresas que les permite generar valor y ventaja competitiva [4]. Por tanto podemos decir que el Conocimiento es un activo del Capital Intelectual. 

En el campo de los negocios y la contabilidad un Activo es un recurso económico que se controla mediante una entidad (cuenta contable por ejemplo), la que registra el resultado de una transacción ya realizada (pasado) o de un evento que podrá significar beneficios económicos futuros. En otras palabras un Activo es un recurso que le brinda beneficios a una empresa.

De la definición anterior podemos postular que el conjunto de conocimientos que tiene y aplica el grupo de personas del Área Informática produce beneficios económicos a la empresa mediante la creación y operación de sistemas informáticos. Luego el Conocimiento de las Personas del Área Informática es un Activo, sino contablemente al menos es claro desde la perspectiva de los negocios.

Inventario Relevante
Asumiendo que el Conocimiento es un activo relevante para el Capital Financiero, nos interesa a su vez establecer cuales son los componentes o categorías de conocimiento que son significativas para el quehacer Informático,  la siguiente lista es una primera aproximación y requerirá de un análisis posterior más exhaustivo. 

• Habilidades para la ejecución de tareas: Conocimiento Tácito, capacidades comunicacionales, trabajo en equipo, liderazgo, entrepreneurship, etc..
• Capacidades Personales, formación profesional (Ingeniería, Contabilidad, Negocios, etc.), experiencia laboral (Programación, Consultoría, Dirección de Proyectos, Modelamiento de Procesos de Negocios, etc.). Tecnología (Lenguajes de Programación, Herramientas de Software, ERP, CRM, etc.)
• Conocimientos Procedurales, se refiere al conocimiento reglamentado de toda organización, como ser: normas –implícitas y explícitas, procedimientos, reglamentaciones, metodologías, leyes, etc.

 Modelo de Generación y Retención de Conocimiento

El elemento esencial de cualquier organización son las personas que la integran, la figura siguiente muestra las tres dimensiones del conocimiento [5], el eje y corresponde al conocimiento que posee un individuo o de un grupo. El eje x señala la clasificación del conocimiento tácito - explícito. Y, el tercer eje  representa si el conocimiento es externo o interno a la organización.

  Luego el modelo de generación y retención de conocimiento debe consistir en mecanismos que posibiliten los siguientes traspasos: 

• Conocimiento Individual al Grupo
• Conocimiento Tácito a Explícito
• Conocimiento Externo a Interno

 Un modelo que trata esto es el Modelo SECI  [6], según este modelo la creación de conocimiento es un proceso continuo de interacciones dinámicas entre el conocimiento tácito y el explícito. La espiral se agranda en la medida que se mueve a través de los distintos niveles de la organización, y pueden provocarse nuevas espirales de creación de conocimiento.

La explicación de los cuadrantes de este modelo es:

Socialización, es el compartir conocimiento tácito por medio de la comunicación cara a cara o el compartir experiencia. Un ejemplo es la relación maestro – aprendiz.

Externalización, Consiste en desarrollar los conceptos que están latentes en el conocimiento tácito, en otras palabras es la codificación del conocimiento tácito que permite su comunicación.

Combinación, es la combinación de varios elementos de conocimiento explícito, esto es en la aplicación del conocimiento para, por ejemplo, construir un prototipo.

Internalización, Está fuertemente relacionada con el learning by doing, es el conocimiento explícito que se hace parte de un individuo y por lo mismo se convierte en un activo de la organización 

Colofón
Entendiendo que la necesidad de generar y retener conocimientos en un Área Informática es muy importante, que es posible asumir que un porcentaje sustantivo del conocimiento del área está en la mente de sus integrantes (75% conocimiento tácito [5]), que la rotación de personal cada vez es mayor y que la carencia de conocimiento relevante impide al Área de Informático realizar su cometido. Resulta necesario transformar modelos como el SECI u otros en prácticas o metodologías que permitan, al interior del Área de Informática, generar una dinámica que produzca la transformación del Conocimiento Tácito en Explícito.

En la práctica hoy están disponibles las herramientas necesarias para crear una metodología ad-hoc para las necesidades del Área Informática, de hecho es mi interés trabajar en su desarrollo y, aprovecho de invitar a quienes interese el tema a contactarme para explorar posibilidades.

Referencias

[1] Teoría del Conocimiento / Epistemología http://www.monografias.com/trabajos/epistemologia2/epistemologia2.shtml

[2] Donald Broadbent § Implicit and explicit learning  http://www.bps.org.uk/publications/thepsychologist/search-the-psychologist-online.cfm?fuseaction=inc_getFile&ID=437&Publication_ID=1

[3] Conocimiento Tácito http://en.wikipedia.org/wiki/Tacit_knowledge

[4] A Model for the Value of Intellectual Capital  Canadian Journal of Administrative Sciences,  Sep 2006   http://findarticles.com/p/articles/mi_qa3981/is_200609/ai_n17192256/pg_1 

[5] Knowledge in Organizations Definition, Creation, and Harvesting,  Smita Kothuri, May, 2002 , http://gseweb.harvard.edu/~t656_web/Spring_2002_students/kothuri_smita_knowledge_in_orgs.htm

[6]  SECI Model, Nonaka & Takeuchi, http://www.12manage.com/methods_nonaka_seci.html

Toda empresa tiene una determinada infraestructura computacional y esta por razones físicas tiene un limite para  las prestaciones que pueda proveer, así se tiene la capacidad del procesador, la memoria principal RAM y el espacio en disco. Este conjunto de ítems determina el performance o rendimiento, de modo que si aumenta la cantidad de usuarios o necesita almacenar más datos, necesariamente tendrá que aumentar el tamaño de su infraestructura, esta es la solución del Maquinazo. O, en vez de ampliaación ver una mejor forma de utilización del equipamiento disponible, esta es la alternativa del Análisis.

Para el desarrollo de este artículo intentaré responder la preguntas siguientes:

• El origen del problema
• Performance de la Infraestructura Informática
• La Solución Maquinazo
• La Solución Análisis
• El factor de escala y la alternativa adecuada

El origen del problema
Las empresas para mantenerse en el mercado necesitan desarrollar estrategias de crecimiento, cualquier sea la que elijan: aumento de la participación de mercado, mayor cobertura, globalización, mejoramiento de la calidad de servicio, incorporación de nuevas líneas de negocios, etc. lleva indefectiblemente a la necesidad de aumentar la capacidad de la infraestructura computacional, esto porque agregó nuevo personal, nuevas locaciones, nuevas transacciones y un largo etcétera.

Pero, también existe un crecimiento que podríamos denominar vegetativo, este ocurre básicamente porque independientemente del crecimiento originado por un desarrollo estratégico el negocio igual puede crecer, entonces se contrata más personal, se necesita guardar más información en línea, la autoridad impone nuevas regulaciones. Y, entonces la infraestructura debe ampliarse para dar satisfacción a la nueva realidad.

En resumen, su infraestructura, si su negocio crece, crecerá también. Y, aquí Ud. ya se estará preguntándose hasta donde puedo sacar más partido a la infraestructura actual o en cuanto debo hacerla crecer. Cualquiera sea su decisión tiene un costo asociado importante.

Performance de la Infraestructura Informática
Performance se refiere a rendimiento, en el caso que nos ocupa se refiere al de la infraestructura computacional. El rendimiento tiene dos caras: una objetiva que normalmente se asocia al tiempo que ocupa la ejecución de una determinada tarea y la otra corresponde a la percepción o evaluación que hacen los usuarios respecto a la respuesta, en tiempo, que entrega la infraestructura computacional que están utilizando, muchas veces ésta es una apreciación subjetiva.

Pero, además de medir o asociar la performance de la infraestructura computacional en términos de tiempos de respuesta ante un requerimiento, también es necesario considerarla en relación al Riesgo, esto es que implica para el negocio que en una determinada circunstancia la infraestructura computacional no entregue los resultados que de ella se esperan, por ejemplo: no se puede facturar, despachar, etc. Los Riesgo claramente son dependientes de las características del negocio de cada empresa, de modo que es necesario evaluar en su merito que significa Riesgo de negocio para su empresa, establecer el valor económico del mismo y ahí definir cual es la performance necesaria de la infraestructura computacional para minimizar el riesgo.

También los niveles de performance tienen relación con el porcentaje de tiempo que está operativa la infraestructura respecto a los tiempos programados para su operación, en inglés corresponde al concepto denominado SLA –Service Level Agreement.

La Solución Maquinazo
Este término lo escuché por primera vez a Germán Garib, para referirse a la solución de un problema de performance mediante la compra de hardware, sin mediar un análisis de alternativas de optimización del uso de la infraestructura disponible. Supongamos que se tienen problemas porque la generación de ciertos informes toma mucho tiempo, y los usuarios están reclamando. Solución: cambiar el procesador por uno más rápido.

El Maquinazo es una solución válida que toma en cuenta el síntoma del problema pero, no su causa. Y, dado que hoy el hardware, es aparentemente, barato se opta sin mayor cuestión por la compra de los equipos adicionales necesarios o en el extremo por el reemplazo.

La Solución Análisis
Así como el Maquinazo apunta al síntoma el Análisis tiene que ver con la causa que genera los niveles de performance indeseados. Por lo mismo es una actividad sistemática que deben ejecutar especialistas para:

1. Determinar el origen de la pérdida de performance o si quiere del consumo excesivo de recursos por parte de un determinado proceso.
2. Buscar y poner operativa una solución que haga que el proceso en cuestión se ejecute con un menor uso de recursos.

Por lo general esta alternativa resuelve, como es lógico, temporalmente el problema y, además provee fundamentos para una ampliación de la infraestructura computacional.

El factor de escala y la alternativa adecuada
Si bien el problema de performance se presenta en todas la empresas, independientemente de su rubro y tamaño, la solución adecuada siempre dependerá del costo de la solución y de lo significativo que es éste en relación a los Ingresos de la empresa.

También podemos establecer que un Análisis de Performance tendrá un costo importante, más aún teniendo en consideración que se necesitan profesionales altamente calificados.

Teniendo en cuenta los considerandos anteriores, podemos establecer:

 Costo de la Mejora = Costo del Análisis + Costo del Maquinazo

Y, el criterio para ejecutar la mejora es cuando

 Costo de la Mejora << Beneficio de la Mejora 

Luego, usaremos el Maquinazo directamente cuando tenemos la certeza que el Análisis es muy costoso para la situación a resolver. Y, usaremos el Análisis cuando el Maquinazo tenga un costo que consideramos demasiado alto y que el costo del Análisis es considerablemente menor que el costo del Maquinazo.

En resumen, siempre tendremos que evaluar si la alternativa es el Maquinazo, el Análisis o ambas.

Trataré en esta artículo la Solución de Problemas que se presentan en un ambiente informático, es decir problemas que tienen que ver con el software o con el uso del software, para la COBIT esta función corresponde a la DS10 Gestión de Problemas [1].

Luego en este artículo se trata el tema sobre como el área de informática debe organizarse para tratar la Solución de Problemas,  para ver métodos para la solución de problemas revisar en este blog  el artículo  “Solución de Problemas de Operación de un ERP”. 

Este artículo corresponde al cuarto y último de la serie “El Soporte, El Mantenimiento y la Solución de Problemas”

Diferencia entre Soporte y Solución de Problemas
El proceso DS8 Administrar la mesa de servicios e incidentes de la COBIT dice “El Soporte debe responde de manera oportuna y efectiva a las consultas y problemas de los usuario TI “, en otras palabras debe hacerse cargo de la necesidad inmediata del usuario, dejando muchas veces la solución del problema técnico de fondo para otra oportunidad y otro grupo de especialistas. Es para la búsqueda de la solución del problema técnico de fondo donde entrar a tallar la Solución de Problemas y en el marco de la metodología COBIT es el proceso DS10 Gestión de Problemas.

Procedimiento de Escalamiento
No todos los problemas tienen el mismo de grado de dificultad, de hecho la mayor parte de los problemas que recibe el mesón de ayuda son simples; los que personal con una capacitación adecuada puede resolver. Por otra parte, los problemas complejos necesitan personal con mayor experiencia y capacidades técnicas, y, que además es personal más caro y escaso. Por eso resulta conveniente organizar la solución de problemas por niveles, de modo que el nivel de partida o nivel 1 atiende soluciones problemas típicos, el nivel 2 o soporte provee la atención personalizada y los niveles 3 y superiores se concentren en la solución de problemas técnicos de mayor complejidad, que además toman más tiempo resolver. El proceso que organiza esta forma de trabajo se llama Escalamiento.

Al igual que en los artículos anteriore les incluyo un Copy / Paste de lo que propone para la solución de problemas la COBIT, que corresponde al proceso “DS10 Gestión de Problemas” [1]. Una efectiva administración de problemas requiere la identificación y clasificación de problemas, el análisis de las causas desde su raíz, y la resolución de problemas. El proceso de administración de problemas también incluye la identificación de recomendaciones para la mejora, el mantenimiento de registros de problemas y la revisión del estatus de las acciones correctivas. Un efectivo proceso de administración de problemas mejora los niveles de servicio, reduce costos y mejora la conveniencia y satisfacción del usuario.

Control sobre el proceso TI de:
Administrar de los problemas,

que satisface el requisito de negocio de TI para:
garantizar la satisfacción de los usuarios finales con ofrecimientos de servicios y niveles de servicio, reducir el retrabajo y los defectos en la prestación de los servicios y de las soluciones.,

enfocándose en:
registrar, rastrear y resolver problemas operativos; investigación de las causas raíz de todos los problemas relevantes y definir soluciones para los problemas operativos identificado,

Se logra con:

- Realizando un análisis de causas raíz de los problemas reportados

- Analizando las tendencias

- Tomando propiedad de los problemas y con una resolución de problemas progresiva

y se mide con:

-  Número de problemas recurrentes con impacto en el negocio

- Porcentaje de problemas resueltos dentro del período de tiempo solicitado

-  Frecuencia de los reportes o actualizaciones sobre un problema en curso, con base en la severidad del problema

DS10.1 Identificación y clasificación de problemas Implementar procesos para reportar y clasificar problemas que han sido identificados como parte de la administración de incidentes. Los pasos involucrados en la clasificación de problemas son similares a los pasos para clasificar incidentes; son determinar la categoría, impacto, urgencia y prioridad. Los problemas deben categorizarse de manera apropiada en grupos o dominios relacionados (por ejemplo, hardware, software, software de soporte). Estos grupos pueden coincidir con las responsabilidades organizacionales o con la base de usuarios y clientes, y son la base para asignar los problemas al personal de soporte.

DS10.2 Rastreo –seguimiento- y resolución de problemas El sistema de administración de problemas debe mantener pistas de auditoría adecuadas que permitan rastrear, analizar y determinar la causa raíz de todos los problemas reportados considerando:

DS10.3 Cierre de problemas Disponer de un procedimiento para cerrar registros de problemas ya sea después de confirmar la eliminación exitosa del error conocido o después de acordar con el negocio cómo manejar el problema de manera alternativa.

DS10.4 Integración de las administraciones de cambios, configuración y problemas Para garantizar una adecuada administración de problemas e incidentes, integrar los procesos relacionados de administración de cambios, configuración y problemas. Monitorear cuánto esfuerzo se aplica en apagar fuegos, en lugar de permitir mejoras al negocio y, en los casos que sean necesarios, mejorar estos procesos para minimizar los problemas.

Referencias

[1] Cobit 4.0,

http://www.isaca.org/AMTemplate.cfm?Section=Overview&Template=/ContentManagement/ContentDisplay.cfm&ContentID=22940

[2] Ejemplo de Procedimiento de Escalamiento http://www.niehs.nih.gov/guide/policies/escalate.htm