Gestión Financiera de los Servicios TI
Presupuestos
La elaboración de presupuestos TI tiene como objetivos principales:
- Planificar el gasto e inversión TI a largo plazo.
- Asegurar que los servicios TI están suficientemente financiados.
- Establecer objetivos claros que permitan evaluar el rendimiento de la organización TI.
Los presupuestos realizados pueden tener diferentes horizontes temporales. Pueden ser a corto plazo, incluyendo los
costes de los servicios prestados en la actualidad, o resultar de una proyección sobre la evolución prevista del negocio en dos o más años.
Aunque no existe una única manera de realizar un presupuesto TI son métodos habituales:
- Presupuesto incremental: el presupuesto se realiza en base al histórico
de presupuestos anteriores, adaptándolos a las modificaciones en los costes
y el desarrollo de nuevas tecnologías, y teniendo
en consideración la aparición de nuevas líneas de servicios.
- Presupuesto "desde cero": se replantea toda la estructura de costes
e inversiones a partir de una "hoja en blanco" en base a los servicios prestados
en la actualidad y las expectativas de crecimiento en el periodo presupuestado.
Para que estos presupuestos sean realistas y sirvan realmente de referencia a la organización TI es necesario identificar
previamente todos los elementos de coste.
La estimación de los costes asociados a esos elementos no es siempre una tarea sencilla y a menudo influyen factores
externos que no se hallan bajo el control directo de la organización TI, como por ejemplo el aumento del precio
de las licencias del software, etc.
Es imprescindible que los presupuestos tengan en cuenta estas incertidumbres y se muestren precavidos al respecto
para evitar que se conviertan en papel mojado al menor vaivén del mercado.
Desde mi experiencia ITIL
Incidente: Evento individual que puede registrarse con un usuario afectado. Ejemplo :"No tengo red"
Problema: Causa principal de uno o varios eventos. Si el CAU está bien montado, los incidentes se irán asociando al Problema y cuando este se resuelva se cerrarían los incidentes. Ejemplo: "Fallo de red. Se ha bloqueado un switch en la zona de Administracion."
En mi empresa, deberíamos usar el concepto de RCA ( Root cause analysis ) pero desgraciadamente no hay responsables designados y claro...
Saludos
Marcar mensaje como inapropiado
Por jbarea 13/05/2009
Gladys, la diferencia a nivel técnico es que ante un incidente puedes dar una solución alternativa (wokaround) mientras que el problema que la originó sigue existiendo y requiere de un analisis mas complejo.
Ejemplo:
Un usuario reporta que de que después de que el equipo de desarrollo haya hecho una implementación, un informe de ventas sale descuadrado.
En este caso la "incidencia" se soluciona realizando la marcha atras a la implantación, es decir, volviendo a la versión anterior.
Sin embargo la causa persiste aunque el usuario ya puede trabajar. El problema sería la revisión del código antes de volver a implantarla.
Además podriamos relacionarlo con la gestión del cambio, ya que se trata de un incidente Post-Implantacion.
Un saludo
Marcar mensaje como inapropiado
Por Joxan 27/05/2009
Necesito saber que es exactamente o cómo se define que un Problema sea Proactivo. Es difícil de comprender en una gran instalación.
Marcar mensaje como inapropiado
Por JULIO G B 24/08/2009
En el caso PIR, ¿Qué sucede si los resultados no son positivos?, en caso de no serlo, ¿volvemos a solicitud de cambio?.
Marcar mensaje como inapropiado
Por Gabriel 29/08/2009
En una unidad de gestión de calidad de los servicios como puedo implementar la gestion de problemas?
Marcar mensaje como inapropiado
Por Patricia 22/09/2009
JULIO G B: del conocimiento que tengo, un problema se considera proactivo, cuando se abre como resultado del análisis de datos colectados por ejemplo de herramientas de monitoreo. Un ejemplo puede ser que un disco duro empieza a reportar eventos de redirección de bloques, lo cual puede inicialmente no causar incidentes pero luego de que se sigan generando estos mismos eventos es un síntoma de que el disco probablemente falle. En este caso el análisis de estos eventos, invita a generar un problema de manera proactiva, con el fin de determinar la real causa raíz y decidir cual es la mejor forma de solucionarlo.
Marcar mensaje como inapropiado
Por MVALENCIA 07/10/2009
alguien sabes cuantas lineas de soporte tendria el servis desk y que procesos intervendrian..
gracias
Marcar mensaje como inapropiado
Por vanesa 04/11/2009
Por su naturaleza la gestion de problemas es un control de tipo "preventivo" o "correctivo" Gracias de antemano por sus amables comentarios.
Marcar mensaje como inapropiado
Por Una duda 19/01/2010
Se que una mesa de servicios mínimo debe cubrir los siguientes procesos:
Gestion de Incidentes, Gestion de Problemas, Atencion de requerimientos, Gestion de la configuracion y Gestion de cambios,pero hay quienes hasta dicen que con los primeros 3 es suficiente. En mi experiencia creo que son estos 5.
Yo manejo mi línea de soporte en 3 niveles: nivel 1 analista de la mesa de servicios, nivel 2 especialista, nivel 3 Proveedor externo.
Saludos.
mirtha Sacnite Gutierrez Lopez
Marcar mensaje como inapropiado
Por Any 13/05/2010
Hay un problema bien grande que se puede presentar...
Y es cuando no se le informa a los usuarios de la compañia del alcance del centro de servicios..y lo pueden tomar hasta como PBX-recepcionista para que le comunique personal...
Es bien importante que los usuarios conozcan..pero hay empresas que no lo creen y a los ultimos que le comunican es al usuario y quienes pagan los platos rotos son el recurso humano que contesta los telefonos...ya que tienen que aguantar muchas veces la groseria de los usuarios....
Marcar mensaje como inapropiado
Por Lucia 25/05/2010
me parece que todo inicia como un incidentes... y posteriormente a su registro, este puede ser un un pedido de servicio o, un error conocido o un problema...
Marcar mensaje como inapropiado
Por María 10/09/2010
