Bugzilla


MYSQL

sudo apt-get install mysql-server mysql-client

Configuración

  • nano /etc/mysql/my.cnf

Asignar los siguientes valores en la línea 52:

  • max_allowed_packet=100M

Agregar una nueva línea, bajo la sección mysqld]

  • ft_min_word_len=2

Crear un usuario en MySQL para Bugzilla:

mysql -u root -p -e

Cambiar db_pass por el valor de la contraseña.

Reiniciar MySQL

sudo /etc/init.d/mysql start

Agregamos un usuario MySQL para Bugzilla:

mysql -u root -p

“GRANT ALL PRIVILEGES ON bugs.* TO bugs@localhost IDENTIFIED BY ‘EXIT$db_pass'”;

APACHE

Crear el archivo bugzilla.con

sudo nano /etc/apache2/sites-available/bugzilla.conf

ServerName localhost

<Directory /var/www/html>

AddHandler cgi-script .cgi

Options +ExecCGI

DirectoryIndex index.cgi index.html

AllowOverride Limit FileInfo Indexes Options

</Directory>

a2ensite bugzilla 

service apache2 reload

a2enmod cgi headers expires

service apache2 restart

 

Historia de Usuario (User Story)


Estructura y Redacción

 

La redacción esta a cargo del Dueño del Producto, o bien, a cargo del Scrum Master para el caso en que el Dueño de Producto no cuente con las habilidades para realizar dicha actividad; en este caso el SM únicamente funge como un “anotador”.

Las Historias de Usuario siguen básicamente la siguiente estructura:

Como nombre del Rol (QUIÉN)  quiero acción (QUÉ)  y así podré objetivo (POR QUÉ)

Hay mucho que decir todavía, sin embargo comprender el objetivo de esta estructura define el éxito o no de la entrega ;)

Aside

Open Bravo

Tags

,


OPEN BRAVO

Amazon Elastic Compute Cloud (Amazon EC2)

Particularmente creo útil el uso de imágenes más que el uso de listados de pasos, razón por la cual a continuación se presenta el proceso de Instalación y Configuración de Amazon EC2:

  1. Seleccionar una imagen de máquina de Amazon (AMI) de plantilla preconfigurada para que entre en funcionamiento de inmediato. O bien crear una AMI que contenga sus aplicaciones, bibliotecas, datos y valores de configuración asociados.Captura de pantalla 2013-06-10 a la(s) 15.13.46
  2. Configurar la seguridad y el acceso a red en su instancia de Amazon EC2.
  1. Seleccionar los tipos de instancias que desee y, a continuación, iniciar, finalizar y supervisar tantas instancias de su AMI como sea necesario, a través de las API de servicio web o la variedad de herramientas de gestión proporcionadas.
  2. Determinar si desea una ejecución en varias localizaciones, utilizar puntos finales de IP estáticos o adjuntar almacenamiento de bloques continuo a sus instancias.
  3. Pagar sólo por los recursos que realmente consuma, como las horas de uso de instancias o la transferencia de datos.

http://ec2-54-224-167-91.compute-1.amazonaws.com/openbravo

Captura de pantalla 2013-06-10 a la(s) 15.13.46

Visualizandose lo siguiente

Captura 2

ERROR COMÚN
  • Software caused connection abort: socket write error

org.openbravo.base.exception.OBException: Exception thrown Exception thrown null
at org.openbravo.dal.core.ThreadHandler.run(ThreadHandler.java:63)
at org.openbravo.dal.core.DalRequestFilter.doFilter(DalRequestFilter.java:103)

Caused by: ClientAbortException: java.net.SocketException: Software caused connection abort: socket write error
at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:369)

REFERENCIAS.


Breve Guía Openbravo ERP

Esta es simplemente una breve guía que muestra un posible escenario para implementar ERP OpenBravo. Cabe mencionar que hacerlo requiere de además skills técnicos, del entendimiento del negocio.

http://prezi.com/osrk5avfyjlf/metodologia-de-implementacion/

.

Deploy to JBoss 7

Tags

, ,


This is a brief technical memory to deploy with JBoss 7, any comments or observations are welcome

REQUIREMENTS

  • To deploy with JBoos 7 requiered install and to configured the environment variables for maven 3 and Java 7

  • This is optional, you can define a goal for maven with:

<build>

    <finalName>project name</finalName>

    <plugins>

      <plugin>

         <groupId>org.apache.maven.plugins</groupId>

         <artifactId>maven-war-plugin</artifactId>

         <version>2.3</version>

         <executions>

            <execution>

               <phase>package</phase>

               <configuration>

                  <webXml>WEB-INF/web.xml</webXml>

               </configuration>

            </execution>

         </executions>

      </plugin>

   </plugins>

  </build>

INSTALLLING JBOSS 7

 

Unpackage the jboss-as-7.0.0.Final.zip in the next location

C:\Development_Tools\JBoss

Configure the JBOSS_HOME with the JBoss path

Generate war file executing the next maven command in the location where is the pom file

  • mvn clean install

 Copy the war file generated from

C:\Development_Tools\EclipseWorkspace\WebsiteServices\target

 To

 C:\Development_Tools\JBoss\jboss-as-7.0.0\jboss-as-7.0.0\standalone\deployments

Copy properties file to next location

 C:\Development_Tools\JBoss\jboss-as-7.0.0\jboss-as-7.0.0\standalone\configuration

 

Modify the standalone.xml adding next sections with proper data:

<system-properties>

        <property name=”service.endpoint.jndi.location” value=”jnp://es-jndi-dev.something.com:8180″/>

        <property name=”website.services.properties.file.location” value=”WebsiteServices.properties”/>

    </system-properties>

<subsystem xmlns=”urn:jboss:domain:datasources:1.0″>

            <datasources>

                <datasource jndi-name=”java:/OracleDS” pool-name=”OracleDS_Pool” enabled=”true” jta=”true” use-java-context=”true” use-ccm=”true”>

                    <connection-url>

                        jdbc:oracle:thin:@name.company.com:1521:WEBDEV

                    </connection-url>

                    <driver>jdbc.driver.OracleDriver

                    </driver>

<new-connection-sql>

select 1 from dual

</new-connection-sql>

<pool>

<min-pool-size>

5

</min-pool-size>

<max-pool-size>

20

</max-pool-size>

<prefill>

false

</prefill>

<use-strict-min>

true

</use-strict-min>

<flush-strategy>

FailingConnectionOnly

</flush-strategy>

</pool>

<security>

<user-name>

WEBDB

</user-name>

<password>

wRuzuf5E

</password>

</security>

<validation>

<check-valid-connection-sql>

select 1 from dual

</check-valid-connection-sql>

<validate-on-match>

false

</validate-on-match>

<background-validation>

false

</background-validation>

<useFastFail>

false

</useFastFail>

</validation>

<timeout>

<idle-timeout-minutes>

45

</idle-timeout-minutes>

<query-timeout>

600

</query-timeout>

</timeout>

<statement>

<track-statements>

TRUE

</track-statements>

</statement>

</datasource>

 

 Finally you can run the bat for JBoss 7.0 with the following command  in this location

C:\Development_Tools\JBoss\jboss-as-7.0.0\jboss-as-7.0.0\bin

 Encrypting datasource password

 export  JBOSS_HOME=/apps/jboss/jboss-as

export CLASSPATH=$JBOSS_HOME/modules/org/picketbox/main/picketbox

-4.0.7.Final.jar:$JBOSS_HOME/modules/org/jboss/logging/main/jboss-logging-3.1.0.GA.jar:$CLASSPATH

java  org.picketbox.datasource.security.SecureIdentityLoginModule  mypassword

Encoded password: -50fa369660ea3144207a6dde3d75616de44

 Define the application policy for the corresponding datasource  

<application-policy name = “WebDBPassword”>

<authentication>

<login-module code = “org.jboss.resource.security.SecureIdentityLoginModule” flag = “required”>

<module-option name = “username”>WEBDB</module-option>

<module-option name = “password”>-50ba369694jfk40la3144207a6df87216de44</module-option>

<module-option name =“managedConnectionFactoryName”>

jboss.jca:service=LocalTxCM,name=OracleDS

</module-option>

</login-module>

</authentication>

</application-policy>

Link

Maven


Instalación

Generar, ajustar y ejecutar el siguiente script; o bien, ejecutar en consola los comandos correspondientes.

#!/bin/sh
export M2_HOME=”/opt/maven”

$M2_HOME/bin $*

 

O bien,

#!/bin/bash
echo “Instalando MAVEN”

chmod 775 /qnue/maven-###/.bin
cd /root
yes | /qnue_data/maven-####.bin
/bin/mv /root/maven-#### /opt
/bin/rm -rv /usr/bin/javac
/bin/ln -s /opt/maven-###/bin/java /usr/bin
/bin/ln -s /opt/maven-###/bin/javac /usr/bin
export MAVEN_HOME=/opt/maven-###
export M2_HOME=/opt/maven-###
export MAVEN_OPTS=”-Xms1024m -Xmx4096m -XX:PermSize=1024m”
export PATH=$PATH:$MAVEN_HOME/bin

 

Algunas anotaciones sobre problemas típicos.

Missing artifact

<dependency>
<groupId>org.testng</groupId>
<artifactId> </artifactId>
<version>5.1</version>
</dependency>

La solución básica es ‘Maven’->’Update Project’, si con esto no se soluciona podemos buscar y encontraremos que tal vez, la versión no está disponible, por tanto no se ha podido actualizar; si con todo, aún no se ha resuelto, dejame saber tu caso.

REFERENCIA.

 

 

Result-Only Work Environment (ROWE)

Featured

Tags

, , ,


En alguna entrevista de trabajo me preguntaban cuáles son las estrategias que uso para llevar con éxito un Proyecto, una de ellas en mi experiencia es, combinar Scrum y llevar a cabo la gestión del proyecto bajo el marco definidos por el PMI; sin embargo, casi siempre es una inquietud de mis entrevistadores, el cómo se logra en una cultura como la mexicana, no tener “mano dura” y con todo lograr que las personas alcancen sus objetivos, algo que comento es que finalmente podemos constatar que la manera “tradicional” no sólo ha generado una crisis en las TIs con porcentajes de más del 80%  de retrasos en la entrega y proyectos inconclusos, lo que originó la necesidad de nuevas metodologías como la de Scrum, que sin entrar en más detalles Scrum toca el tema de fondo, y es la necesidad de personas cualificadas, así es, en qué? ese es otro tema, del cual sólo vale la pena comentar, que un equipo altamente capacitado y pobremente cualificado, está altamente propenso a terminar siendo uno de tantos proyectos con grandes atrasos, muchas otras extras, etc, etc; claro, a menos que éste sea un Proyecto individual, que desde luego no es el caso, razón de más para tomarse unos minutos en evaluar otra dirección en la típica forma de gestionar.
El fragmente del artículo que abajo anoto, apunta a otra de las claves en el éxito de cualquier proyecto, espero se den el tiempo para leer el artículo y dejarme sus comentarios, buen día.

The next generation wants to work this way naturally. They start off entrepreneurial and nimble, and they know how to work fast and communicate globally. Growing up, they did more group project than the rest of did. They know how to drive an outcome.Now, they’re entering an old-fashioned, 20th century system, and what we’re telling them doesn’t fit with how they think and how they move stuff along. Millennials are motivated. If you’re clear with them about what they need to deliver, they’re going to do it every time. But if you say, “Shut up. Get in your cube. And don’t forget to go to the team-building event at 3,” you’re going to lose them.They may stay for a while, but they will be complacent, unmotivated and uninspired. Then, they will start looking elsewhere for a progressive organization. They’re not going to waste their time sitting around for eight hours, just because somebody said that that’s how work is supposed to happen. They will start looking for an organization that’s first and foremost interested in the results they can — and will — deliver.” – Pavao K.

http://www.oracle.com/us/corporate/profit/opinion/022013-jthompson-1910615.html?goback=%2Egde_4636455_member_218426203
 

 

Rendering Dinamic Images [ZK]


Contexto. App Java con ZK, con una BD http://www.postgresql.org/ . He aquí el código,  cualquier duda o comentario con gusto, felices compilaciones!!

LOS CÓDIGOS

SQL

select encode(cattema_banner_header ,''base64'') as bheader, 
 cattema_extc as ext FROM CAT_TEMAS
 WHERE cattema_id = (
select cattema_id 
 from repos_delegacionmunicipio 
 where edo_cve = ' || EDO || ' 
 and mun_cve = ' || MUN || '
)') as p ( bheader text, cattema_extc text);

DAO

StringBuffer query = new StringBuffer();
query.append(“select bheader, cattema_extc from db_gev_temaencabezado_encode( “);
query.append(String.valueOf(edoCve).concat(“, “).concat(String.valueOf(munCve)) );
query.append(” )as p ( bheader text, cattema_extc text)”);
Session session = getSession();
session.beginTransaction();
SQLQuery sqlQuery = session.createSQLQuery(query.toString());
List<HeaderEncodeDTO> result = sqlQuery.setResultTransformer(Transformers.aliasToBean(HeaderEncodeDTO.class)).list();
session.getTransaction().commit();
session.close();
if( result != null && result.size() > 0 ) {

image = (Image)result.get(0); 

arrayBytes = Base64.decode( cadena );

}

BUSISNESS CLASS

image es un Array de bytes.

InputStream mediais = new ByteArrayInputStream( image );

media = new AMedia( fileName, extension, contentType, mediais );

CONTROLLER

Binding de componetes:

window.appendChild( panel );

panel.appendChild( panelChild );

pc.appendChild( frameX );

CONTROLLER

<window id=”win”  border=”none” apply=”${encabezadoControlador}” >

                                    <panel id=”panel”>
                                          <panelchildren >
                                                       <iframe id=”frame/>
                                          </panelchildren>
                                    </panel>
                                </window>

APP CONTEXT

appContext-controler.xml:

<bean id=”encabezadoControlador” class=”FOO.controler.EncabezadoControlador” singleton=”false”>
                         <property name=”loginDAO” ref=”loginDAO” />
</bean>

Continue reading

Link

Protected: Gestión de Problemas

Tags


This content is password protected. To view it please enter your password below:

Link

Gestión de Incidentes


Visión General

La Gestión de Incidentes tiene como objetivo resolver cualquier incidente que cause una interrupción en el servicio de la manera más rápida y eficaz posible.

La Gestión de Incidentes no debe confundirse con la Gestión de Problemas, pues a diferencia de esta última, no se preocupa de encontrar y analizar las causas subyacentes a un determinado incidente sino exclusivamente a restaurar el servicio. Sin embargo, es obvio, que existe una fuerte interrelación entre ambas.

Las propiedades y funcionalidades de la Gestión de Incidentes se resumen sucintamente en el siguiente interactivo:

Introducción y Objetivos

Los objetivos principales de la Gestión de Incidentes son:

  • Detectar cualquiera alteración en los servicios TI.
  • Registrar y clasificar estas alteraciones.
  • Asignar el personal encargado de restaurar el servicio según se define en el SLA correspondiente.

Esta actividad requiere un estrecho contacto con los usuarios, por lo que el Centro de Servicios (Service Desk) debe jugar una papel esencial en el mismo.

El siguiente diagrama resume el proceso de gestión de incidentes:

Aunque el concepto de incidencia se asocia naturalmente con cualquier malfuncionamiento de los sistemas de hardware y software según el libro de Soporte del Servicio de ITIL un incidente es:

Cualquier evento que no forma parte de la operación estándar de un servicio y que causa, o puede causar, una interrupción o una reducción de calidad del mismo”.

Por lo que casi cualquier llamada al Centro de Servicios puede clasificarse como un incidente, lo que incluye a las Peticiones de Servicio tales como concesión de nuevas licencias, cambio de información de acceso, etc. siempre que estos servicios se consideren estándar.

Cualquier cambio que requiera una modificación de la infraestructura no se considera un servicio estándar y requiere el inicio de una Petición de Cambio(RFC) que debe ser tratada según los principios de la Gestión de Cambios.

Los principales beneficios de una correcta Gestión de Incidentes incluyen:

  • Mejorar la productividad de los usuarios.
  • Cumplimiento de los niveles de servicio acordados en el SLA.
  • Mayor control de los procesos y monitorización del servicio.
  • Optimización de los recursos disponibles.
  • Una CMDB más precisa pues se registran los incidentes en relación con los elementos de configuración.
  • Y principalmente: mejora la satisfacción general de clientes y usuarios.

Por otro lado una incorrecta Gestión de Incidentes puede acarrear efectos adversos tales como:

  • Reducción de los niveles de servicio.
  • Se dilapidan valiosos recursos: demasiada gente o gente del nivel inadecuado trabajando concurrentemente en la resolución del incidente.
  • Se pierde valiosa información sobre las causas y efectos de los incidentes para futuras reestructuraciones y evoluciones.
  • Se crean clientes y usuarios insatisfechos por la mala y/o lenta gestión de sus incidentes.

Las principales dificultades a la hora de implementar la Gestión de Incidentes se resumen en:

  • No se siguen los procedimientos previstos y se resuelven las incidencias sin registrarlas o se escalan innecesariamente y/o omitiendo los protocolos preestablecidos.
  • No existe un margen operativo que permita gestionar los “picos” de incidencias por lo que éstas no se registran adecuadamente e impiden la correcta operación de los protocolos de clasificación y escalado.
  • No están bien definidos los niveles de calidad de servicio ni los productos soportados. Lo que puede provocar que se procesen peticiones que no se incluían en los servicios previamente acordados con el cliente.

Clasificación del Incidente

Es moneda frecuente que existan múltiples incidencias concurrentes por lo que es necesario determinar un nivel de prioridad para la resolución de las mismas.

El nivel de prioridad se basa esencialmente en dos parámetros:

  • Impacto: determina la importancia del incidente dependiendo de cómo éste afecta a los procesos de negocio y/o del número de usuarios afectados.
  • Urgencia: depende del tiempo máximo de demora que acepte el cliente para la resolución del incidente y/o el nivel de servicio acordado en el SLA.

También se deben tener en cuenta factores auxiliares tales como el tiempo de resolución esperado y los recursos necesarios: los incidentes “sencillos” se tramitarán cuanto antes.

Dependiendo de la prioridad se asignarán los recursos necesarios para la resolución del incidente.

La prioridad del incidente puede cambiar durante su ciclo de vida. Por ejemplo, se pueden encontrar soluciones temporales que restauren aceptablemente los niveles de servicio y que permitan retrasar el cierre del incidente sin graves repercusiones.

Es conveniente establecer un protocolo para determinar, en primera instancia, la prioridad del incidente. El siguiente diagrama nos muestra un posible “diagrama de prioridades” en función de la urgencia e impacto del incidente:

Escalado y Soporte

Es frecuente que el Centro de Servicios no se vea capaz de resolver en primera instancia un incidente y para ello deba recurrir a un especialista o a algún superior que pueda tomar decisiones que se escapan de su responsabilidad. A este proceso se le denomina escalado.

Básicamente hay dos tipos diferentes de escalado:

  • Escalado funcional: Se requiere el apoyo de un especialista de más alto nivel para resolver el problema.
  • Escalado jerárquico: Debemos acudir a un responsable de mayor autoridad para tomar decisiones que se escapen de las atribuciones asignadas a ese nivel, como, por ejemplo, asignar más recursos para la resolución de un incidente específico.

El proceso de escalado puede resumirse gráficamente* como sigue:

* El escalado puede incluir más niveles en grandes organizaciones, o por el contrario , integrar diferentes niveles en el caso de PYMES

Proceso

El siguiente diagrama muestra los procesos implicados en la correcta Gestión de Incidentes:

Nota: los botones del gráfico permiten acceder a información mas detallada sobre la interrelación con otros procesos TI

Registro y Clasificación de Incidentes

Registro

La admisión y registro del incidente es el primer y necesario paso para una correcta gestión del mismo.

Las incidencias pueden provenir de diversas fuentes tales como usuarios, gestión de aplicaciones, el mismo Centro de Servicios o el soporte técnico, entre otros.

El proceso de registro debe realizarse inmediatamente pues resulta mucho más costoso hacerlo posteriormente y se corre el riesgo de que la aparición de nuevas incidencias demore indefinidamente el proceso.

  • La admisión a tramite del incidente: el Centro de Servicios debe de ser capaz de evaluar en primera instancia si el servicio requerido se incluye en el SLA del cliente y en caso contrario reenviarlo a una autoridad competente.
  • Comprobación de que ese incidente aún no ha sido registrado: es moneda corriente que más de un usuario notifique la misma incidencia y por lo tanto han de evitarse duplicaciones innecesarias.
  • Asignación de referencia: al incidente se le asignará una referencia que le identificará unívocamente tanto en los procesos internos como en las comunicaciones con el cliente.
  • Registro inicial: se han de introducir en la base de datos asociada la información básica necesaria para el procesamiento del incidente (hora, descripción del incidente, sistemas afectados…).
  • Información de apoyo: se incluirá cualquier información relevante para la resolución del incidente que puede ser solicitada al cliente a través de un formulario específico, o que pueda ser obtenida de la propia CMDB (hardware interrelacionado), etc.
  • Notificación del incidente: en los casos en que el incidente pueda afectar a otros usuarios estos deben ser notificados para que conozcan como esta incidencia puede afectar su flujo habitual de trabajo.

Clasificación

La clasificación de un incidente tiene como objetivo principal el recopilar toda la información que pueda ser de utilizada para la resolución del mismo.

El proceso de clasificación debe implementar, al menos, los siguientes pasos:

  • Categorización: se asigna una categoría (que puede estar a su vez subdividida en más niveles) dependiendo del tipo de incidente o del grupo de trabajo responsable de su resolución. Se identifican los servicios afectados por el incidente.
  • Establecimiento del nivel de prioridad: dependiendo del impacto y la urgencia se determina, según criterios preestablecidos, un nivel de prioridad.
  • Asignación de recursos: si el Centro de Servicios no puede resolver el incidente en primera instancia designara al personal de soporte técnico responsable de su resolución (segundo nivel).
  • Monitorización del estado y tiempo de respuesta esperado: se asocia un estado al incidente (por ejemplo: registrado, activo, suspendido, resuelto, cerrado) y se estima el tiempo de resolución del incidente en base al SLA correspondiente y la prioridad.

Análisis, Resolución y Cierre de Incidentes

En primera instancia se examina el incidente con ayuda de la KB para determinar si se puede identificar con alguna incidencia ya resuelta y aplicar el procedimiento asignado.

Si la resolución del incidente se escapa de las posibilidades del Centro de Servicios éste redirecciona el mismo a un nivel superior para su investigación por los expertos asignados. Si estos expertos no son capaces de resolver el incidente se seguirán los protocolos de escalado predeterminados.

Durante todo el ciclo de vida del incidente se debe actualizar la información almacenada en las correspondientes bases de datos para que los agentes implicados dispongan de cumplida información sobre el estado del mismo.

Si fuera necesario se puede emitir una Petición de Cambio (RFC). Si la incidencia fuera recurrente y no se encuentra una solución definitiva al mismo se deberá informar igualmente a la Gestión de Problemas para el estudio detallado de las causas subyacentes.

Cuando se haya solucionado el incidente se:

  • Confirma con los usuarios la solución satisfactoria del mismo.
  • Incorpora el proceso de resolución a la KB.
  • Reclasifica el incidente si fuera necesario.
  • Actualiza la información en la CMDB sobre los elementos de configuración (CI) implicados en el incidente.
  • Cierra el incidente.

Control del Proceso

La correcta elaboración de informes forma parte esencial en el proceso de Gestión de Incidentes.

Estos informes deben aportar información esencial para, por ejemplo:

  • La Gestión de Niveles de Servicio: es esencial que los clientes dispongan de información puntual sobre los niveles de cumplimiento de los SLAsy que se adopten medidas correctivas en caso de incumplimiento.
  • Monitorizar el rendimiento del Centro de Servicios: conocer el grado de satisfacción del cliente por el servicio prestado y supervisar el correcto funcionamiento de la primera línea de soporte y atención al cliente.
  • Optimizar la asignación de recursos: los gestores deben conocer si el proceso de escalado ha sido fiel a los protocolos preestablecidos y si se han evitado duplicidades en el proceso de gestión.
  • Identificar errores: puede ocurrir que los protocolos especificados no se adecuen a la estructura de la organización o las necesidades del cliente por lo que se deban tomar medidas correctivas.
  • Disponer de Información Estadística: que puede ser utilizada para hacer proyecciones futuras sobre asignación de recursos, costes asociados al servicio, etc.

Por otro lado una correcta Gestión de Incidentes requiere de una infraestructura que facilite su correcta implementación. Entre ellos cabe destacar:

  • Un correcto sistema automatizado de registro de incidentes y relación con los clientes
  • Una Base de Conocimiento (KB) que permita comparar nuevos incidentes con incidentes ya registrados y resueltos. Una (KB) actualizada permite:

Evitar escalados innecesarios.

Convertir el “know how” de los técnicos en un activo duradero de la empresa.

Poner directamente a disposición del cliente parte o la totalidad de estos datos (a la manera de FAQs) en una Extranet. Lo que puede permitir que a veces el usuario no necesite siquiera notificar la incidencia.

  • Una CMDB que permita conocer todas las configuraciones actuales y el impacto que estas puedan tener en la resolución del incidente.

Para el correcto seguimiento de todo el proceso es indispensable la utilización de métricas que permitan evaluar de la forma más objetiva posible el funcionamiento del servicio. Algunos de los aspectos clave a considerar son:

  • Número de incidentes clasificados temporalmente y por prioridades.
  • Tiempos de resolución clasificados en función del impacto y la urgencia de los incidentes.
  • Nivel de cumplimiento del SLA.
  • Costes asociados.
  • Uso de los recursos disponibles en el Centro de Servicios.
  • Porcentaje de incidentes, clasificados por prioridades, resueltos en primera instancia por el Centro de Servicios.
  • Grado de satisfacción del cliente.

Caso Práctico

El Service Desk de “Cater Matters” ha recibido una llamada del encargado de suministros del comedor de uno de sus clientes.

Dicho encargado informa de que a pesar de haber solicitado una nueva partida de helados hace unos días a través de la web ésta aún no se ha recibido y apenas quedan reservas en sus frigoríficos

El operador del Service Desk busca en la base de datos de pedidos y confirma que se realizo el pedido hace varios días pero también observa que éste se ha guardado defectuosamente.

El operador intenta desde su puesto repetir la orden pero el sistema sigue fallando.

El operador toma, basándose en los protocolos establecidos, las siguientes decisiones:

  • Evalúa la prioridad: aunque el impacto es bajo, el incidente es urgente pues el cliente necesita rápidamente el suministro.
  • Registra los datos del incidente.
  • Consulta la Base de Conocimiento para investigar si el incidente es consecuencia de un error conocido y cuales son las posibles soluciones temporales
  • Propone una solución temporal al cliente: indica una zona reservada de la web desde la que se pueden realizar pedidos “urgentes” vía email.
  • Contacta con el departamento de sistemas previendo que el incidente pueda repetirse a lo largo de la mañana.
  • Consulta, mediante la aplicación que monitoriza las existencias de almacén, la disponibilidad de los helados solicitados.
  • Tranquiliza al cliente asegurándole que mediante su servicio express recibirá los helados solicitados antes del mediodía.

Por otro lado el departamento de sistemas:

  • Realiza una serie de pruebas y comprueba que, de manera general, el sistema funciona correctamente.
  • No consigue identificar la causa del incidente.
  • Contacta con el Service Desk y propone que se eleve el problema a la Gestión de Problemas pero pre-calificando su prioridad como baja.

El Service Desk recibe la información y determina que:

  • Dado el bajo impacto del incidente y el hecho de que se haya proporcionado al cliente una solución temporal satisfactoria no se requiere un escalado superior.
  • Registra la solución temporal del incidente junto a la información proporcionada por el departamento de sistemas.
  • Da por cerrado el incidente.

Aside

Protected: Gestión de Servicios TI


This content is password protected. To view it please enter your password below: