Introduccin

A travs de los aos, se han evaluado numerosos intentos de

modernizar sistemas de informacin; se han encontrado grandes
problemas como altos costos, largos retrasos en el desarrollo y
sistemas que no satisfacen las necesidades del usuario.

En muchos casos, estos defectos en el desarrollo ocurrieron por una

inadecuada planeacin detallada para identificar necesidades futuras
y actuales de los usuarios y una prematura decisin a un especfico
diseo que no consider alternativas de solucin o que tan bien
satisficieran las necesidades de los usuarios.

Las complejidades de los sistemas de informacin pueden ser

vastamente diferentes, pero el anlisis determina las necesidades de
informacin de una organizacin para lograr su misin son
esencialmente las mismas sin importar la complejidad del problema.
Organizaciones pblicas y privadas han ideado metodologas para
identificar necesidades de informacin y planificar adquisiciones para
satisfacer esas necesidades. Mientras que las metodologas pueden
ser un poco diferentes cada propone un enfoque estructurado
completo para identificar las necesidades de informacin y analizar
como satisfacer esas necesidades.
 Planificacin de los Sistemas de la
Informacin
El Plan de Sistemas de Informacin tiene como objetivo la obtencin
de un marco de referencia para el desarrollo de sistemas de
informacin que responda a los objetivos estratgicos de la
organizacin. Este marco de referencia consta de:

Una descripcin de la situacin actual, que constituir el punto

de partida del Plan de Sistemas de Informacin. Dicha
descripcin incluir un anlisis tcnico de puntos fuertes y
riesgos, as como el anlisis de servicio a los objetivos de la
organizacin.
Un conjunto de modelos que constituya la arquitectura de
informacin.
Una propuesta de proyectos a desarrollar en los prximos aos,
as como la prioridad de realizacin de cada proyecto.
Una propuesta de calendario para la ejecucin de dichos
proyectos.
La evaluacin de los recursos necesarios para los proyectos a
desarrollar en el prximo ao, con el objetivo de tenerlos en
cuenta en los presupuestos. Para el resto de proyectos, bastar
con una estimacin de alto nivel.
Un plan de seguimiento y cumplimiento de todo lo propuesto
mediante unos mecanismos de evaluacin adecuados.

La perspectiva del plan debe ser estratgica y operativa, no

tecnolgica. Es fundamental que la alta direccin de la
organizacin tome parte activa en la decisin del Plan de Sistemas
de Informacin con el fin de posibilitar su xito. La direccin debe
convencer a sus colaboradores ms directos de la necesidad de
realizacin del plan; de su apoyo de forma constructiva,
mentalizndose de que la ejecucin del mismo requerir la
utilizacin de unos recursos de los cuales son responsables. La
presentacin del Plan de Sistemas de Informacin y la constitucin
del equipo supone el arranque del proyecto y es fundamental que
las ms altas instancias de la organizacin estn implicadas en
ambos, dando el apoyo necesario y aportando todo tipo de medios.
Explicar el plan a las personas de la organizacin y a las unidades
organizativas afectadas sobre las que recaer el Plan, el apoyo de
los altos directivos y la cualificacin de los recursos de las distintas
unidades implicadas, sern factores crticos de xito del Plan de
Sistemas de Informacin. El nivel de detalle con el que se har el
estudio de la situacin actual depender de la existencia de
documentacin actual, de si hay personas que conozcan dicha
documentacin y de la predisposicin a una sustitucin total o
parcial por sistemas de informacin nuevos. En cualquier caso,
como paso previo para detectar aspectos importantes que puedan
afectar a la organizacin, es necesario investigar sus puntos
fuertes, reas de mejora, riesgos y amenazas posibles y hacer un
diagnstico de los mismos. Para la elaboracin del Plan de
Sistemas de Informacin se estudian las necesidades de
informacin de los procesos de la organizacin afectados por el
Plan, con el fin de definir los requisitos generales y obtener
modelos conceptuales de informacin. Por otra parte se evalan
las opciones tecnolgicas y se propone un entorno. Tras analizar
las prioridades relacionadas con las distintas variables que afectan
a los sistemas de informacin, se elabora un calendario de
proyectos con una planificacin lo ms detallada posible de los
ms inmediatos. Adems, se propone una sistemtica para
mantener actualizado el Plan de Sistemas de Informacin para
incluir en l todos los cambios necesarios, garantizando el
cumplimiento adecuado del mismo.

1. Delimitacin del mbito del Proyecto

Resulta esencial determinar el mbito del proyecto al
comienzo del mismo. Han de establecerse de antemano qu
cuestiones han de resolverse durante la realizacin del
proyecto y cules se dejarn fuera. Tan importante es
 determinar los aspectos abarcados por el proyecto como fijar
aqullos aspectos que no se incluirn en el proyecto. Estos
ltimos han de indicarse explcitamente. Si es necesario, se
puede especificar todo aquello que se posponga hasta una
versin posterior del sistema. Si, en algn momento, fuese
necesario incluir en el proyecto algn aspecto que no haba
sido considerado o que ya haba sido descartado, es
obligatorio reajustar la estimacin del coste del proyecto y su
planificacin temporal. Como resultado de la delimitacin del
mbito del proyecto se obtiene un documento breve, de 1
2 pginas, en el que se describe el problema que nuestro
sistema de informacin pretende resolver. Este documento,
denominado a veces mission statement o project charter,
debe existir siempre en todo proyecto. En l se recoger la
descripcin de ms alto nivel de la funcionalidad que tendr
nuestro sistema de informacin, sus caractersticas
principales y sus objetivos clave. Obviamente, este
documento debe formar parte del contrato que se firme con
el cliente en el arranque oficial del proyecto. Adems de ser
breve, una buena descripcin del proyecto debe superar con
xito la prueba del ascensor. Debe estar escrito en un
lenguaje que cualquiera pueda entender, evitando un
vocabulario excesivamente tcnico. Adems, debe recoger
todo lo que le contaramos a un conocido en unos segundos
acerca del proyecto en el que estamos trabajando si nos lo
cruzramos por la calle o nos lo encontrsemos en un
ascensor.
2. Estudio de Viabilidad:
Con recursos ilimitados (tiempo y dinero), casi cualquier
proyecto se podra llevar a buen puerto. Por desgracia, en la
vida real los recursos son ms bien escasos, por lo que no
todos los proyectos son viables. En un conocido informe de
1994 (el informe Chaos del Standish Group), se hizo un
estudio para determinar el alcance de la conocida como
"crisis crnica de la programacin" y, en la medida de lo
posible, identificar los principales factores que hacen
fracasar proyectos de desarrollo de software y los
ingredientes clave que pueden ayudar a reducir el ndice de
fracasos. De entre los proyectos analizados:
Slo uno de cada seis se complet a tiempo, de
acuerdo con su presupuesto y con todas las
caractersticas inicialmente especificadas.
La mitad de los proyectos lleg a completarse
eventualmente, costando ms de lo previsto, tardando
ms tiempo del estimado inicialmente y con menos
caractersticas de las especificadas al comienzo del
proyecto.
Por ltimo, ms de un 30% de los proyectos se cancel
antes de completarse.

Dado que cinco de cada seis proyectos analizados no se

ajustaron al plan previsto, no es de extraar que resulte
aconsejable realizar un estudio de viabilidad antes de
comenzar el desarrollo de un sistema de informacin para
determinar si el proyecto es econmica, tcnicas y
legalmente viable. De hecho, lo primero que deberamos
hacer es plantearnos si la mejor opcin es desarrollar un
sistema informatizado o es preferible un sistema manual.
Algo as debieron hacer los rusos cuando decidieron llevar
lpices al espacio (segn dicen, los americanos gastaron una
fortuna hasta que inventaron un bolgrafo que funcionaba en
ausencia de gravedad).

Antes de comenzar un proyecto, se debera evaluar la

viabilidad econmica, tcnica y legal del mismo. Y no slo
eso, el resultado del estudio de viabilidad debera ajustarse a
la realidad. A Jerry Weinberg, un conocido consultor, se le
ocurri preguntar a los asistentes a una conferencia suya, en
el Congreso Internacional de Ingeniera del Software de
 1987, cuntos de ellos haban participado en un estudio de
viabilidad en el que se hubiese determinado que el proyecto
no era tcnicamente viable. De los mil quinientos asistentes,
nadie levant la mano.

3. Anlisis de Riesgo
Independientemente de la precisin con la que hayamos
preparado nuestro proyecto, siempre se produce algn
contratiempo que eche por tierra la mejor de las
planificaciones. Es algo inevitable con lo que hemos de vivir
y para lo cual disponemos de una herramienta
extremadamente til: la gestin de riesgos, que
tradicionalmente se descompone en evaluacin de riesgos y
control de riesgos.
La evaluacin de riesgos se utiliza para identificar "riesgos"
que pueden afectar negativamente al plan de nuestro
proyecto, estimar la probabilidad de que el riesgo se
materialice y analizar su posible impacto en nuestro
proyecto. Qu sucedera si algn miembro clave del nuestro
equipo abandona la empresa, se va de vacaciones, se pone
enfermo o pide una baja por depresin causada por un
entorno de trabajo hostil? y si al final nos encontramos con
algn problema de compatibilidad del sistema que hemos
desarrollamos con la configuracin de los equipos sobre los
que ha de funcionar? si, inadvertidamente, borramos o
modificamos errneamente algn que otro fichero clave? si
nuestro ordenador se avera? Una vez analizados los riesgos
potencialmente ms peligrosos, podemos recurrir a distintas
tcnicas de control de riesgos. Por ejemplo, podemos
elaborar planes de contingencia para los riesgos que sean
ms probables y de consecuencias ms desastrosas para el
proyecto. O tal vez seamos capaces de eliminar el riesgo de
raz (o mitigarlo) si buscamos alguna alternativa en la que el
riesgo identificado no pueda presentarse (o se presente
 debilitado). Independientemente de la solucin por la que
optemos, el anlisis de riesgos nos ensea que hemos de
dejar un margen para imprevistos previsibles y aadir cierta
holgura a la planificacin de nuestro proyecto. Las hiptesis
barajadas al analizar riesgos potenciales pueden convertirse
en realidad y nunca est de ms dejar algo de margen de
maniobra.
4. Estimacin:
Sin duda, una de las tareas ms peliagudas de cualquier
proyecto de desarrollo de software es la estimacin inicial del
coste de algo que an no conocemos. De hecho, la
realizacin de malas estimaciones ha sido identificada como
una de las dos causas ms comunes del fracaso de un
proyecto de desarrollo de software (Glass, 2003). La otra es
la existencia de requerimientos inestables sujetos a
continuos cambios.
Como dijo Bhr, la prediccin es difcil, especialmente si se
trata del futuro. Adems, la estimacin del coste asociado se
suele realizar en el peor momento posible: al comienzo,
cuando menos conocemos del proyecto y mayor es el
margen del error de la estimacin. Afortunadamente, existen
algunas reglas heursticas que nos pueden ayudar a estimar
con una precisin razonable el coste y duracin de un
proyecto. El arte de una buena estimacin est basado,
fundamentalmente, en la experiencia del estimador. Haber
participado en proyectos de similares caractersticas puede
ser esencial para que seamos capaces de realizar una buena
estimacin. Tambin podemos obtener resultados aceptables
si tenemos en cuenta lo siguiente:
Nunca se ha de realizar una estimacin sobre la
marcha, por mucho que nos presionen. Una respuesta
apresurada slo sirve para pillarnos los dedos y que
despus no podamos cumplir con las expectativas que
nosotros mismos hemos creado. Una estimacin
 siempre ha de ser meditada, tras un estudio
pormenorizado de los distintos factores que pueden
afectar a la realizacin de nuestro proyecto.
La incertidumbre en la estimacin es inevitable, pero
en ocasiones puede reducirse. Cuantos ms datos
histricos recopilemos y ms precisa sea la
informacin de la que dispongamos acerca de nuestro
proyecto, mejor ser nuestra estimacin
Hemos de descomponer nuestro proyecto en tareas de
la granularidad adecuada. El error que se comete al
estimar el conjunto de las actividades del proyecto es
mayor que el que se comete cuando estimamos cada
una de las actividades por separado. Los errores que
cometamos en las distintas estimaciones tendern a
compensarse (la ley de los gr andes nmeros en
accin).
Es muy frecuente subestimar el esfuerzo necesario
cuando descomponemos un problema complejo en
multitud de tareas. Esto se debe a que, durante el
transcurso del proyecto, tambin han de realizarse
otras muchas tareas que probablemente hayamos
olvidado incluir en nuestra estimacin. Adems,
consideradas de forma independiente, las distintas
tareas del proyecto resultan aparentemente ms
fciles de realizar de lo que en realidad son.
Resulta aconsejable utilizar varias tcnicas de
estimacin y contrastar los resultados con ellas
obtenidos. Por ejemplo, podemos realizar una
estimacin en funcin del coste un proyecto similar,
utilizar algn modelo matemtico de estimacin
(COCOMO o similar) y realizar una tercera estimacin
descomponiendo nuestro proyecto en tareas. Si los
resultados obtenidos con las distintas tcnicas de
 estimacin son similares, probablemente nuestra
estimacin sea buena.
5. Planificacin Temporal y Asignacin de Recursos:
Una vez que hemos decidido seguir adelante con nuestro
proyecto, hemos de planificar su temporizacin. Una
planificacin excesivamente detallada (con el proyecto
descompuesto en tareas de un da, por ejemplo) puede
resultar contraproducente. Cualquier error de planificacin
causado por algn imprevisto nos forzar a replanificar el
resto del proyecto, retrasando an ms nuestro proyecto.
Una planificacin por semanas suele ser razonable para
afrontar con comodidad las contingencias con las que nos
vayamos encontrando sin tener que estar continuamente
reajustando el plan del proyecto.
Pase lo que pase, la planificacin del proyecto ha de
reajustarse cada vez que cambien las circunstancias del
mismo. Si no se ha podido terminar una tarea en el tiempo
inicialmente establecido, no nos vale suponer alegremente
que posteriormente se recuperar el tiempo perdido. Los
proyectos se retrasan poco a poco. Debemos aprovechar las
primeras seales de alarma y no esconderlas debajo de la
alfombra fingiendo que todo marcha segn lo previsto.
Tampoco vale decir que algo est casi terminado. O lo est o
no lo est. Si no lo est, el plan ha de ajustarse a la situacin
real del proyecto. Pensar que algo est casi acabado slo
sirve para darnos una falsa sensacin de seguridad. Adems,
el 10% final de algo tiende a requerir el 90% del tiempo, as
que no nos sirve de nada saber que hemos realizado 80% del
esfuerzo si no podemos asegurar a qu parte corresponde el
20% que nos queda (a la que se termina rpidamente o a la
que consume la mayor parte de nuestro tiempo?). Como dice
un viejo adagio: "la primera mitad se lleva el 90% del
tiempo; la segunda, el 90% restante". No use nunca en su
planificacin el hecho de que determinadas actividades del
proyecto estn casi terminadas.
 La planificacin es fundamental en la gestin de un proyecto
de desarrollo de software. Procure siempre mantener su plan
al da. Un plan que no se ajusta a la realidad no sirve de
mucho. Cuando algn retraso indique que posiblemente le
ser imposible cumplir los plazos establecidos, hable con su
cliente. A l le interesa saberlo y, aunque probablemente no
se lo agradezca, a la larga resultar beneficioso y usted
habr cumplido con su obligacin profesional.
6. Anlisis:
Lo primero que debemos hacer para construir un sistema de
informacin es averiguar qu es exactamente lo que tiene que
hacer el sistema. La etapa de anlisis en el ciclo de vida del
software corresponde al proceso mediante el cual se intenta
descubrir qu es lo que realmente se necesita y se llega a una
comprensin adecuada de los requerimientos del sistema (las
caractersticas que el sistema debe poseer).
Por qu resulta esencial la etapa de anlisis? Simplemente,
porque si no sabemos con precisin qu es lo que se necesita,
ningn proceso de desarrollo nos permitir obtenerlo. El problema
es que, de primeras, puede que ni nuestro cliente sepa de
primeras qu es exactamente lo que necesita. Por tanto,
deberemos ayudarle a averiguarlo con ayuda de distintas tcnicas.
Por qu es tan importante averiguar exactamente cules son los
requerimientos del sistema si el software es fcilmente maleable
(aparentemente)? Porque el coste de construir correctamente un
sistema de informacin a la primera es mucho menor que el coste
de construir un sistema que habr que modificar ms adelante.
Cuanto antes se detecte un error, mejor. Distintos estudios han
demostrado que eliminar un error en las fases iniciales de un
proyecto (en la etapa de anlisis) resulta de 10 a 100 veces ms
econmico que subsanarlo al final del proyecto. Conforme avanza
el proyecto, el software se va describiendo con un mayor nivel de
detalle, se concreta cada vez ms y se convierte en algo cada vez
ms rgido.
Es posible determinar de antemano todos los requerimientos de
un sistema de informacin? Desgraciadamente, no. De hecho, una
de las dos causas ms comunes de fracaso en proyectos de
 desarrollo de software es la inestabilidad de los requerimientos del
sistema (la otra es una mala estimacin del esfuerzo requerido por
el proyecto). En el caso de una mala estimacin, el problema se
puede solucionar estableciendo objetivos ms realistas. Sin
embargo, en las etapas iniciales de un proyecto, no disponemos
de la informacin necesaria para determinar exactamente el
problema que pretendemos resolver. Por mucho tiempo que le
dediquemos al anlisis del problema (un fenmeno conocido como
la parlisis del anlisis).
La inestabilidad de los requerimientos de un sistema es inevitable.
Se estima que un 25% de los requerimientos iniciales de un
sistema cambian antes de que el sistema comience a utilizarse.
Muchas prcticas resultan efectivas para gestionar
adecuadamente los requerimientos de un sistema y, en cierto
modo, controlar su evolucin. Un buen analista debera tener una
formacin adecuada en:
Tcnicas de elicitacin de requerimientos
Herramientas de modelado de sistemas.
Metodologas de anlisis de requerimientos
7. Importancia de la Planeacin Informtica:
Los sistemas de informacin son herramientas importantes
para lograr efectivamente los objetivos organizacionales.
Informacin siempre disponible, completa y precisa es
esencial para hacer decisiones fundamentadas y a tiempo.
Informacin no disponible, mezclada entre informacin intil
y un ineficiente procesamiento de datos gasta recursos.
La organizacin debe identificar sus necesidades de
informacin en las bases de una identificacin sistemtica y
anlisis de su misin y funciones a realizar, quien las realiza,
la informacin y datos de soporte necesitados para realizar
las funciones y los procesos necesitados para la estructura
de informacin ms til.
El desarrollo y adquisicin exitosos de un sistema de
informacin deben incluir un proceso riguroso y disciplinado
de obtencin, evaluacin y anlisis de datos antes de
comprometer recursos considerables financieros y humanos
para cualquier desarrollo de sistema de informacin.
 Mientras que implementar este enfoque puede no excluir
todos los problemas de adquisicin de los sistemas de
informacin, este debe producir conocimiento detallado de la
misin y objetivos organizacionales, necesidades de
informacin del usuario y alternativas para direccionar esas
necesidades, y una arquitectura abierta y flexible que es
expandible y puede ser actualizadas para satisfacer
necesidades futuras.
8. El Impacto de no Identificar Sistemticamente la
Necesidades de la Informacin
La importancia de identificar y analizar a fondo y
sistemticamente las necesidades de informacin no se le
pueden dar sobre nfasis. Se ha descubierto a travs de los
aos que adquirir sistemas de informacin cuesta mucho,
toman demasiado tiempo y resultados en sistemas que no
hacen lo que las organizaciones quieren que hagan.
Hay muchos ejemplos de adquisiciones de sistemas de
informacin errneas, una vez analizada la adquisicin del
sistema, los costos pueden incrementarse en un 50% y el
desarrollo tom ms del doble del tiempo estimado, y el
sistema estaba lejos de satisfacer todas las necesidades de
los usuarios.
La planificacin estratgica de los sistemas de informacin
tiene como propsito la revisin del estado actual de la
organizacin, la identificacin de la situacin estratgica
deseada y la planificacin de los proyectos y cambios en la
organizacin necesarios para alcanzar dicho estado deseado,
tpicamente en un periodo de 3 o 5 aos.
Esta actividad debe involucrar a todos los actores relevantes
de la organizacin para conseguir la alineacin de los
objetivos de los sistemas de informacin con los
organizativos.
A pesar que el proceso de creacin del plan de sistemas no
es trivial, como tampoco lo es su posterior despliegue, el
objetivo se puede definir de una manera sencilla: se trata de
analizar el estado actual de las tres dimensiones bsicas de
los sistemas de informacin, identificar su situacin futura
deseada y determinar las acciones necesarias para alcanzar
dicha situacin futura.
Las fases propuestas para la redaccin de un plan
estratgico de sistemas son:

a) Determinar La Estrategia Y Contexto Actual De

La Organizacin
La primera fase del proyecto consiste en asegurar que
cubrir de manera efectiva las necesidades de la
organizacin, y conocer esta suficientemente para
poder determinar posteriormente sus requisitos de los
sistemas de informacin.
El primer paso ser validar el plan de proyectos y
Establecer los antecedentes.
b) Identificar Los Requisitos De Negocio Para Los
Sistemas De Informacin
La segunda fase del proyecto, una vez identificado el
contexto y revisada la informacin disponible sobre la
estrategia y planificacin de la organizacin, es
determinar cules son los requisitos concretos de
negocio a los que pueden contribuir estos sistemas.
 Para identificar dichos requisitos con una visin amplia
y estratgica, deben revisarse las necesidades del
negocio desde varios niveles del anlisis.
c) Determinar El Estado Actual De Los Sistemas De
Informacin
Una vez que se ha revisado el negocio y se han
obtenido sus requisitos, la siguiente fase es determinar
el estado actual de los sistemas de informacin, para
poder analizar posteriormente la efectividad del
soporte ofrecido a partir de sus tres aspectos bsicos:
o Estado de la infraestructura tcnica
o Estado de las aplicaciones
o Estado de la organizacin
d) Anlisis De Necesidades De Los Sistemas De
Informacin
Una vez conocidos los requisitos que el negocio
demanda de los sistemas de informacin y
determinado el estado actual de estos, se debe realizar
su anlisis para identificar cules son los puntos
fuertes a mantener y las debilidades a mejorar.
Para ello puede realizarse un anlisis a los siguientes
niveles:
o Anlisis estratgico de los sistemas de
informacin
o Benchmarking de las prcticas de la
competencia y del estado de la industria IT
o Soporte ofrecido a los compontes de negocio
o Evaluacin de coste/beneficio de las aplicaciones
y los sistemas
El anlisis identificar acciones de mejora,
determinadas en base a las oportunidades
identificadas anteriormente, y se agruparn en los tres
aspectos de los sistemas de informacin anteriormente
vistos:
o Aplicaciones
o Infraestructura
o Organizacin de Procesos
e) Definir La Estrategia Y Plan De Sistemas De
Informacin
La ltima fase de un proyecto de planificacin
estratgica de sistemas es la definicin de la
estrategia y plan de sistemas.
 f) Desarrollar El Programa De Despliegue
Una vez finalizado y aprobado el plan estratgico de
sistemas, se debe desplegar y ello se planifica y
gestiona de manera similar a cualquier otro programa
o proyecto grande.
o Lanzamiento del programa.
o Seguimiento y evaluacin del programa.
Una vez completada la planificacin anual, la actividad
principal es el seguimiento de los indicadores
operativos y de los proyectos en curso, as como la
toma y supervisin de las acciones correctivas que se
abran en base a las desviaciones identificadas. En
paralelo se mantiene la relacin con el cliente interno,
que es el resto de la organizacin, gestionando la
demanda de peticiones generales y de proyectos no
previstos en el plan de sistemas.
9. La Planificacin A Travs Del Anlisis De Vnculos
Primozic et al. (Primozic et al., 1991), en su libro Strategic
Choices, explica su metodologa de planificacin,
examinando los vnculos que las organizaciones tienen unas
con otras con el fin de crear una estrategia para la utilizacin
de canales electrnicos. La metodologa tiene cinco (5)
partes bsicas:
o ENTENDIENDO LAS OLAS DE INNOVACIN. A travs
de stas, se define cmo las TI son usadas, por una
industria y por una empresa.
o APROVECHANDO LAS CURVAS DE EXPERIENCIA. Una
firma que identifica correctamente un nuevo mercado
e instala la tecnologa para explotarlo, se mueve a una
nueva curva de experiencia y obtiene xito.
o DEFINIENDO RELACIONES DE PODER. La gerencia debe
entender primero las relaciones de poder que existen
al momento de crear una estrategia que construya
vnculos electrnicos entre las distintas empresas.
o TRAZANDO SU EMPRESA EXTENDIDA. Una empresa
extendida incluye todos los entes de la propia
 organizacin ms aquellos con los cuales sta
interacta -proveedores, clientes, gobierno, etc.
o PLANIFICANDO SUS CANALES ELECTRNICOS. Estos
canales se enfocan en los componentes de informacin
de los productos, tales como: mercadeo,
administracin, distribucin y servicio al consumidor.
10. Los Enfoques De Resolucin Creativa De Problemas
(Rcp)
Son procedimientos y tcnicas diseadas para resolver
problemas completos de forma creativa. Evolucionando
desde hace dos (2) o tres (3) dcadas, las tcnicas han sido
tiles para mejorar muchos de los enfoques de planificacin
de SI presentados anteriormente.
El esquema ms ampliamente usado para la resolucin de
problemas fue creado por Simon (Simon, 1960), quien
propuso tres (3) etapas:
o Inteligencia. Abarca el reconocimiento del
problema y el anlisis de la informacin del
problema para desarrollar una definicin til de
ste.
o Desarrollo. Es la generacin de soluciones.
o Eleccin. Abarca la seleccin e implementacin
de la solucin.

El modelo ms ampliamente usado de RCP, desarrollado por

Parnes (Parnes, 1977), contiene cinco (5) fases:
o hallando el hecho
o hallando el problema
o hallando la idea
o hallando la solucin
o hallando la aceptacin.

La nica caracterstica de RCP es el uso de actividades de

divergencia-convergencia en cada fase del proceso de
resolucin de problemas; cada fase comienza con una
actividad de divergencia (generacin de ideas, donde las
alternativas son explicadas) y concluye con una actividad de
 convergencia (donde las ideas ms prometedoras son
seleccionadas para futuras exploraciones).

11. El Modelaje Empresarial

Snow (Snow, 1991) indica que la experiencia vivida por la
United Technologies Microelectronics Center, Inc. (UTMC)
ilustra algunas tcnicas que pueden ser llamadas modelaje
empresarial; la historia de UTMC sugiere que cuando hay que
ubicarse a un nivel empresarial, es necesario usar muchas
tcnicas y enfoques al mismo tiempo.
La metodologa se enfoca en los procesos claves del negocio,
teniendo que subdividir la empresa completa en unidades
funcionales.
Entendidos los procesos del negocio, a continuacin se
deben entender y documentar las interrelaciones de los
procesos claves.
A continuacin, la visin de la implementacin es vinculada a
la visin de los procesos a travs de la traduccin de stos
en SI, para despus definir las interrelaciones entre los
sistemas mediante una arquitectura clave de sistemas.
Finalmente, se identifican las diferencias entre el ambiente
actual y el modelo diseado; de esta manera, se identifican
los cambios ambientales que hacen necesario hacer
reingeniera del negocio.
12. Planificacin Tctica De Si/Ti
Dado que la planificacin considera restricciones,
ambigedades, hechos e incertidumbres, qu procesos de
planificacin tctica pueden ser mejores para la funcin de
SI/TI? Qu tipos de actividades son necesarias planificar?
Qu herramientas e informacin soportan la tarea de la
planificacin tctica de SI/TI? Un plan tctico completo
desarrollado a travs de un riguroso proceso responde estas
interrogantes.
El Plan Tctico de SI/TI de una organizacin debe ser:
o Elaborado tanto por el personal de lnea como por la
gerencia responsable de los SI y las TI
o Efectivo
o Detallado a travs de un concienzudo documento que
describa las acciones para la implementacin de la
estrategia. conteniendo lo siguiente:
 Consideraciones Sobre Las Aplicaciones
Es necesario establecer un portafolio de
aplicaciones que consista en un conjunto
completo de programas de aplicaciones que la
organizacin utilice para conducir de manera
automatizada las funciones del negocio. El plan
que trata sobre el portafolio de aplicaciones debe
incluir la seleccin de los proyectos a ser
ejecutados, el cronograma, el control y la
evaluacin de esos proyectos durante la
implementacin.
Operaciones de Sistemas.
Abarcan los procesos para el funcionamiento de
las aplicaciones de la organizacin. Los gerentes
de SI/TI deben planificar las operaciones de
sistemas para satisfacer a los clientes dentro y
fuera de la organizacin. Los elementos de la
planificacin de las operaciones de sistemas son:
Planificacin de nivel de servicio.
Gerencia de problemas.
Gerencia del cambio.
Gerencia de restablecimiento.
Planificacin de capacidad.
Planificacin de redes.
Planes de Recursos.
El plan describe la dependencia crtica de los
recursos disponibles (dinero, equipos, gente y
espacio fsico), a lo largo del horizonte de
planificacin. Los elementos a incluir son:
Planes de equipos.
Planes de espacio.
Planes para la gente.
Planes financieros.
Acciones administrativas.

Acciones Administrativas.
A lo largo del ciclo de planificacin, muchas
acciones administrativas soportan el proceso de
planificacin y la implementacin de los planes
 aprobados. Una lista establecida de reglas y
lineamientos garantiza que las acciones que
queden pendientes estarn dentro de unos
lmites razonables. Es necesario conocer cmo
son los procesos de planificacin que se siguen
en el establecimiento de los planes, al igual que
la forma de cmo controlar, evaluar y corregir la
ejecucin de las acciones planificadas.
Planificacin de Tecnologa.
Los entes organizacionales encargados de SI/TI
tienen la responsabilidad de monitorear
continuamente el entorno para observar los
avances tecnolgicos y mantener a la
organizacin informada de todos los progresos
en esta rea. Los profesionales senior de SI/TI
deben estar al ritmo de los desarrollos del state-
of-art de sus disciplinas; los gerentes de
programacin deben rastrear las tecnologas de
programacin; el personal de soporte de
sistemas y los expertos en telecomunicaciones
deben mantener actualizados sus conocimientos
acerca de la tecnologa, as como mejorar su
experticia. Algunas de las reas que pueden ser
evaluadas durante el proceso de planificacin
son:
Desarrollos de nuevos procesadores.
Avances en los dispositivos de
almacenamiento.
Sistemas de telecomunicaciones.
Sistemas operativos.
Software de comunicacin.
Herramientas de programacin.
Aplicaciones de software disponibles en el
mercado (sistemas off-the-shelf).
Herramientas de gerencia de sistemas.
13. Planificacin Operativa De Si/Ti
Muchas organizaciones han alcanzado xitos en la gerencia
de computacin y de operaciones de redes, debido a la
cuidadosa y sistemtica gerencia de los procesos
operacionales; la adopcin de tcnicas disciplinadas
fortalece considerablemente esta gerencia.
Las operaciones de produccin en SI/TI de una organizacin
son vitales para el negocio y representan la imagen de sta
internamente y, en algunos casos, externamente.
En contraste con las operaciones rutinarias de computacin,
un error u omisin en la planificacin estratgica, que quizs
pueda ser ms devastador para la empresa a largo plazo,
puede no ser aparente en meses o aos. Sin embargo, lo que
pasa hoy o lo que pueda pasar la prxima semana o dentro
de un mes domina la vida de los gerentes de las operaciones
de produccin.
Mucho ms que otros, los gerentes de operaciones de SI/TI
deben contar con procedimientos y disciplinas para cubrir la
amplia variedad de desafos que pueden presentarse. Para
tener xito, los gerentes de operaciones deben usar sistemas
que provean herramientas, tcnicas y procedimientos para
mantener estable, confiable y libre de problemas, las
operaciones.
El corazn de la planificacin operativa de SI/TI est en la
definicin de los acuerdos para la prestacin de un nivel de
servicio en particular, ya que estos son el fundamento para
el grupo que gerencia de manera colectiva los procesos
operativos de SI/TI.
Las distintas disciplinas gerencia procesos conformados por
procedimientos, herramientas y gente organizada, para
conducir las facetas de las operaciones de sistemas de
computacin, bien sea dentro o fuera de la organizacin de
SI/TI, tanto para los sistemas en desarrollo como para los
sistemas en produccin.
Para brindar el mejor servicio al cliente, bien sea de los
sistemas en operacin o de los sistemas en desarrollo, los
gerentes de las operaciones de sistemas deben controlar
todas las actividades relacionadas con los centros de
computacin:
Problemas operacionales, defectos, o errores,
que causen la prdida del nivel de servicio y el
gasto adicional de recursos.
Control de los cambios en los sistemas, es un
aspecto crtico ya que la realizacin de cambios
errados crean problemas y perjudican el servicio.
Control de los cambios en los sistemas, es un
aspecto crtico ya que la realizacin de cambios
errados crean problemas y perjudican el servicio.
Los planes gerenciales para restablecer el
servicio por interrupciones inevitables por
defectos del desempeo de los sistemas o por
eventos externos incontrolables.
Planificacin de calendarios de procesamiento y
entrega de resultados de procesos en lnea o en
batch, a organizaciones clientes.
Mantenimiento del desempeo de los sistemas o
mejora del nivel de servicio a travs de mejoras
en los equipos.
Necesidades de mejorar la capacidad instalada
para acometer demandas de trabajo; esto
requiere que los aspectos 1 a 5 funcionen
correctamente.