4. 3
Presentación
El estudio de caso o estudio de casos, como también se le conoce, es una metodología basada en la repre-
sentación de una situación real, problemática y específica. Es utilizado como un instrumento pedagógico
por diversas instituciones educativas y en distintos campos del conocimiento humano. Los estudios de ca-
sos, abren una ventana de oportunidad en el proceso de enseñanza-aprendizaje, a través de la reflexión, el
análisis y la deliberación en torno a un fenómeno determinado.
La Universidad de Harvard en Estados Unidos es considerada como la pionera en el uso de ese método.
Desde principios de siglo pasado lo aplicó con sus alumnos en la enseñanza del Derecho y posteriormente
lo extendió a otras áreas, como la administración y los negocios.
En México, el Instituto Panamericano de Alta Dirección de Empresa (IPADE) adoptó el “Método del caso”
como un instrumento para la formación de sus estudiantes en alta dirección, por lo que los profesores
destinan parte de sus esfuerzos a realizar actividades de investigación para describir situaciones de empre-
sas reales, además de seleccionar libros y artículos para llevar a las aulas lo mejor de los conocimientos
actuales.
Otro hecho significativo que refleja la importancia del uso de esa metodología para fines didácticos en
nuestro país, fue la creación del Centro Internacional de Casos (CIC) del Instituto Tecnológico de Estudios
Superiores de Monterrey (ITESM), entidad encargada de coordinar y vincular los esfuerzos de todos los
campus del sistema y universidades asociadas, con el fin de promover la escritura, difusión y actualización de
casos de calidad relevantes en la realidad latinoamericana.
A casi un siglo de la introducción de esta metodología de enseñanza, su aplicación en el campo de las
tecnologías de la información y comunicación (TIC) parece ser aún incipiente, si se considera el número de
casos de estudio publicados sobre el tema por algunas instituciones educativas, como la Escuela de Nego-
cios de Harvard (Harvard Business School) misma que registra sólo 186 casos relacionados con tecnologías
de la información de un total de 9,728 publicados para su aplicación en 18 disciplinas, destacan también
los 1,630 casos sobre finanzas (16.8% del total)1
.
En el CIC por su parte, 11 de sus 572 casos publicados se refieren a sistemas de información, mientras
que 109 casos corresponden a contabilidad y finanzas2
. En ambas instituciones las publicaciones relaciona-
das con TIC participan sólo de 1.9% del total de sus correspondientes acervos.
Por ello, y en virtud de la creciente relevancia económica y social de las TIC en la vida cotidiana de las
personas y organizaciones en México, es que la publicación de casos de estudio representa un nicho de
oportunidad para que el Infotec avance de manera más eficaz en el cumplimiento de su misión, al pro-
piciar el uso de esta herramienta didáctica para favorecer el desarrollo de habilidades para el análisis de la
información, el conocimiento y la potencialidad de las TIC, en las personas, las instituciones y las empresas
interesadas, a través de la socialización y la revisión crítica de experiencias relevantes.
1 Harvard Business publishing for Educators (2013) Resultados, consultado en: http://cb.hbsp.harvard.edu/cb/web/search_results.seam?Ntx=mode%2
Bmatchallpartial&Ntk=HEMainSearch&N=100021&conversationId=363988
2 Centro Internacional de Casos (CIC) [2013] Casos por área, consultado en: http://cic.gda.itesm.mx/CIC/s/catalog.php?show=areas
5.
6. 5
CONTENIDO
Presentación......................................................................................................................................... 3
Contenido............................................................................................................................................. 5
Introducción.
........................................................................................................................................ 9
Caso 1. Gobiernos locales digitales: acercando el gobierno a los ciudadanos............................. 13
1. Antecedentes...........................................................................................................................................15
2. Instrumentación del proyecto: gobiernos locales digitales (GLD).....................................................16
Desarrollo de la Plataforma GLD.
.........................................................................................................16
Modelo conceptual.
................................................................................................................................17
Portal municipal.
....................................................................................................................................17
Portal de la ciudad digital.....................................................................................................................18
Valor de la plataforma...........................................................................................................................18
Acciones para la promoción y el despliegue de la plataforma..........................................................23
3. Problemática.
...........................................................................................................................................24
Caso 2. Solución tecnológica: enfrentándose a las limitantes de un cliente................................ 25
1. Antecedentes...........................................................................................................................................27
2. La institución.
..........................................................................................................................................27
3. Perfil de Rubén Feldman.......................................................................................................................28
4. Perfil de Carlos Amador.
........................................................................................................................28
5. Descripción de la problemática.............................................................................................................29
6. Resumen de retos a resolver..................................................................................................................29
Glosario.
.......................................................................................................................................................30
Anexo...........................................................................................................................................................31
Caso 3. El camino de los servicios en la nube................................................................................. 33
1. El pasado exitoso para establecer un futuro.
.......................................................................................35
2. Requerimientos y alineación de la alta dirección................................................................................36
7. 6
3. Integración del equipo de trabajo.........................................................................................................36
4. Análisis de elementos.............................................................................................................................36
a) Virtualización de servidores.............................................................................................................37
b) Servicios en la nube (cloud).
..............................................................................................................37
c) Servidores y tecnologías en procesadores.......................................................................................37
d) El Impacto de ITIL.............................................................................................................................38
e) Tercerización de la administración (Outsourcing)...........................................................................38
5. Seleccionar, unir y relacionar................................................................................................................39
Caso 4. Me hackearon, ahora ¿qué hago?.
........................................................................................ 41
La llamada incómoda.................................................................................................................................43
Confirmación del ataque............................................................................................................................43
La investigación.
..........................................................................................................................................45
Caso 5. Guerra cibernética................................................................................................................ 47
1. ¿Guerra cibernética?...............................................................................................................................49
2. Antecedentes...........................................................................................................................................49
3. Peligros potenciales................................................................................................................................50
4. Expectativas a futuro.............................................................................................................................51
5. Experiencias en algunos países.............................................................................................................51
Estados Unidos.
......................................................................................................................................51
México.....................................................................................................................................................52
Irán..........................................................................................................................................................52
6. El escenario a enfrentar.........................................................................................................................52
Referencias..................................................................................................................................................53
Anexo 1........................................................................................................................................................54
Especulaciones sobre origen y ataque.................................................................................................54
¿Qué hace de estas redes más vulnerables?........................................................................................54
8. 7
Anexo 2........................................................................................................................................................55
Eugene Kaspersky..................................................................................................................................55
Referencias..................................................................................................................................................55
Caso 6. Modernización de un centro de datos................................................................................ 57
1. Diagnóstico inicial..................................................................................................................................59
2. El análisis.
................................................................................................................................................59
a. Centro de datos tradicional..............................................................................................................59
b. Centro de datos a la medida.............................................................................................................60
c. Centro de datos en contenedores.....................................................................................................61
3. Factores a considerar para la evaluación de la mejor alternativa......................................................62
4. Momento de decisión.
.............................................................................................................................62
Casos Internacionales.......................................................................................................................... 63
North American Case Research Association, Inc.
Caso 7. Controles en la UCIN........................................................................................................... 65
Introducción................................................................................................................................................67
El Compassionate Care Hospital de Nueva Inglaterra................................................................................68
Consideraciones acerca de la UCIN...........................................................................................................69
Referencias..................................................................................................................................................72
Documento 1...............................................................................................................................................73
IESE Business School-Universidad de Navarra
Caso 8. Google 2012: organizando información en la red............................................................. 77
Resumen ejecutivo: el fenómeno Google.................................................................................................79
Los principios: 1995-2004..........................................................................................................................80
La consolidación del buscador: 2005-2007.
..............................................................................................83
La historia reciente: 2008-2012.
.................................................................................................................85
2008: El año del navegador Chrome....................................................................................................85
9. 8
2009: La comunicación y colaboración online se ve enriquecida con la presentación de Voice y
Wave.
........................................................................................................................................................89
2010: Móviles, China y la lucha contra Microsoft por el mercado de los viajes.
..............................86
2011: Cambios en el algoritmo, almacenamiento de música y alquiler de películas, y el año del Go-
ogle Wallet para compras off-line........................................................................................................88
2012: ¿La batalla por el hardware y las redes sociales?......................................................................89
El modelo de negocio.................................................................................................................................90
Servicios relacionados con la búsqueda...................................................................................................92
Los competidores tradicionales: búsqueda..............................................................................................93
Yahoo!.....................................................................................................................................................94
Microsoft.
................................................................................................................................................94
Cultura corporativa....................................................................................................................................95
1. Pensar de modo no convencional.....................................................................................................96
2. Siempre en beta.
.................................................................................................................................96
3. Innovación continua y ejecución veloz en lugar de perfección absoluta.
.....................................96
4. Google no hace mucho marketing formal.......................................................................................96
5. Crea tus propias reglas......................................................................................................................96
Infraestructura tecnológica.......................................................................................................................97
Gestión de la innovación............................................................................................................................98
10. 9
Introducción
El método de caso como experiencia de aprendizaje.
La revisión de casos con fines académicos, ha sido ampliamente utilizada por diversas instituciones de edu-
cación superior a nivel mundial, Harvard es tal vez la institución más destacada en el uso de esta metodolo-
gía, fundamentalmente en el área de Derecho, a principios del siglo XX, para después extrapolarse a otras
áreas de conocimiento, pero es quizá en el área de la administración de negocios en dónde la metodología
de estudio de casos ha tenido mayor aceptación y éxito.
Entre las razones que lo explican está la naturaleza misma de la administración de negocios que, a di-
ferencia de otras disciplinas, no es una ciencia exacta y la toma de decisiones depende del punto de vista
de quienes son responsables de dirigir el rumbo de una institución, por lo que, sin dejar de lado la base
cuantitativa a considerar, existe un alto porcentaje de aspectos cualitativos que la dirección de la empresa
deberá toma en cuenta para fundamentar su actuación. Aún más, las decisiones en el mundo de la admi-
nistración de negocios, también podrían ser afectadas por las vivencias y experiencias previas del directivo,
al enfrentar situaciones similares.
La metodología de estudio de casos ha tenido gran aceptación en temas relacionadas con los negocios,
en esencia, el análisis no genera soluciones únicas u óptimas, sino más bien, promueve la discusión de ideas
entre los participantes, para buscar alternativas de solución sobre una situación determinada. En este senti-
do el método de casos, se identifica con el enfoque constructivista en tanto que el conocimiento se genera
a partir de la experiencia y de las interpretaciones que realice cada participante.
El método de estudio de casos no tiene que ver con enseñar cómo se aplica una teoría, ni con presentar
ejemplos de soluciones genéricas, más bien, es una herramienta que ayuda a reflexionar sobre cómo en-
frentar problemas en la empresa, es decir, induce a los directivos a razonar sobre situaciones complejas y
concretas, para realizar un diagnóstico y plantear estrategias de solución apropiadas.
Carlos Llano (1996), quien fue un pionero de la aplicación del método de estudio de caso en el Instituto
Panamericano de Alta Dirección de Empresas (IPADE) de la Universidad Panamericana, señaló alguna vez
que es especialmente útil para la enseñanza en los negocios.
Características del método del caso.
A través del método de casos, los participantes tienen la oportunidad de discutir ideas y descubrir por si
mismos nuevo conocimiento acerca de una situación determinada, lo que les puede conducir a decisiones
adecuadas. Precisamente el método de casos implica, por su esencia, un enfoque de trabajo grupal, cuyo
punto de partida es el análisis individual de la situación a resolver.
El método de casos implica también seguir un enfoque estructurado para el análisis de los problemas
en la empresa. El punto de partida es la identificación de hechos significativos, de los personajes involu-
crados en la toma de decisiones y del contexto en que se da la situación. A partir de ahí, los participantes
podrán analizar la información sobre el caso, primero de manera individual, para luego discutir en una
sesión plenaria con el resto de sus compañeros algunas posibilidades de solución. Para que esta fase del
proceso fluya adecuadamente, se requiere de una sesión plenaria en la que participe un conductor, que
normalmente es un Profesor universitario, experto en la temática que abarque el caso, con experiencia en
el mundo real de las empresas y con un conocimiento amplio de la metodología de casos. Como facilitador
deberá también tener la habilidad de formular las preguntas adecuadas que detonen la discusión de ideas
y propicien la generación de nuevo conocimiento entre los participantes. En este sentido, el método de
casos tiene ciertos paralelismos con la mayéutica que utilizaban los griegos desde tiempos inmemorables.
11. 10
| Casos de estudio |
Un objetivo fundamental de la metodología de casos, es el enseñar a pensar y a reflexionar, siguiendo
un proceso estructurado.
Resumiendo: el método de casos parte del análisis de los hechos, para luego sintetizar los principales
problemas detectados y proponer algunas posibles soluciones, evaluando ventajas y desventajas de cada
solución propuesta, para generar, conclusiones significativas entre los participantes.
Desarrollo de habilidades.
La aplicación del método de casos, no sólo sirve como herramienta de apoyo para generar un aprendizaje,
sino que, además, promueve el desarrollo de habilidades entre quienes participan en una sesión de discu-
sión de casos, para:
- Aplicar el pensamiento crítico y reflexivo
- Mejorar la capacidad para la toma de decisiones
- Identificar y establecer relaciones entre los conceptos teóricos y la realidad de una situación determi-
nada.
- Participar en grupos de trabajo
- Respetar la opinión de los colegas
- Desarrollar habilidades de aprendizaje
- Proponer soluciones creativas
- Mejorar la comunicación y la interrelación personal
- Ampliar la visión sobra una situación determinada
Este tipo de habilidades se pueden considerar un valor agregado que podrían alcanzar las personas que
participan en sesiones grupales para la discusión de casos.
Algunas limitaciones del método de estudio de casos:
El Dr. Llano advierte que para que el método estudio de casos se aproveche cabalmente, se requiere
apertura por parte de los participantes y firmeza de juicio. El método no funcionará para quienes carez-
can de la disposición para escuchar opiniones distintas a la suya, o para quienes se han encasillado en
conocimientos teóricos ajenos a la realidad de los negocios. También vale la pena señalar que no todas
las variables existentes en el mundo real están incorporadas en la descripción de un caso de estudio y
por más que éste trate de describir la realidad de una situación, podría haber factores o variables no
incluidos. Sin embargo, en descargo de este último punto, es importante entender que en el mundo
real de los negocios, generalmente el tomador de decisiones no cuenta con toda la información, ni con
el tiempo para recabarla, además de que hay aspectos subjetivos que dependen de la interpretación del
tomador de decisiones.
No todas las situaciones en la empresa son propicias para ser analizadas a través del método de estudio
de casos. En las empresas existen algunos aspectos operativos o de tipo técnico, que por su naturaleza,
pueden ser resueltos aplicando alguna solución o método ya probado, sin necesidad de profundizar en la
reflexión que caracteriza al método que se comenta.
La metodología de estudio de casos no es una panacea, pues para generar un aprendizaje efectivo, se pue-
den y deben combinar distintas herramientas de enseñanza, el método de casos, puede ser útil en algunas
12. 11
[ Introducción]
situaciones, se sugiere complementarlo con la presentación de ejemplos o con la transmisión directa del
conocimiento por parte de los profesores. La naturaleza del problema a tratar será la clave para decidir si
conviene o no aplicar la metodología de estudio de casos.
Beneficios del método
Algunos de los beneficios de la aplicación del método de estudio de casos para el análisis y toma de deci-
siones en las empresas son los siguientes:
• Se integra un conocimiento conjunto a partir del conocimiento individual y de las experiencias pre-
vias de los participantes.
• Se promueve el desarrollo del pensamiento constructivo y reflexivo.
• Se promueve el respeto a las opiniones de los colegas.
• Se amplía la perspectiva individual sobre un problema a resolver.
• Se fortalece el trabajo constructivista.
• Se desarrolla una comunidad de aprendizaje.
• Cada participante es responsable de su propio proceso de aprendizaje.
• Se generan lecciones aprendidas que pueden ser capitalizadas para futuras situaciones.
¿Es válido el uso del método de casos de estudio en el campo de las tecnologías de información (TI)?
Para contestar esta interrogante, conviene identificar los siguientes aspectos:
• El campo de acción de las TI se relaciona con el diseño de soluciones para enfrentar problemas del
mundo real.
• Las soluciones de TI requieren de un proceso de toma de decisiones, tanto de parte del cliente, como
del prestador del servicio.
• A lo largo de los proyectos de TI, comúnmente se presentan situaciones problemáticas que los admi-
nistradores del proyecto tienen que resolver bajo circunstancias no ideales, con recursos limitados
considerando la solución de los imprevistos que pudieran presentarse.
• Las decisiones sobre las aplicaciones de TI para las empresas guardan estrecha relación con con la
complejidad para encontrar soluciones relacionadas con la administración de negocios, en tanto que
el tomador de decisiones debe actuar ante un entorno dónde existen algunos aspectos cualitativos y
diversos puntos de vista, contando en ocasiones con tiempo e información limitados, por lo que se
justifica la metodología de casos para el análisis de ese tipo de situaciones.
Tanto los directores como el personal involucrado en el diseño de soluciones de TI, podrán generar un
aprendizaje significativo si participan en el análisis de casos de estudio de casos, siguiendo las tres etapas
básicas del proceso: análisis individual, reunión grupal y generación de conclusiones (lecciones aprendi-
das) que podrán capitalizarse para futuros proyectos.
13.
14. 13
Caso 1:
Gobiernos locales digitales, acercando el gobierno a los ciudadanos.
El caso se desarrolla con base en los trabajos realizados en el CENETI (Centro Nacional de Estudios de
Tecnología Informática), organismo que ofrece servicios de investigación, información, desarrollo de apli-
caciones, infraestructura y consultoría en tecnologías de la información en México.
El CENETI impulsa las acciones del Gobierno electrónico, el e-gobierno, como una opción de crecimien-
to de los gobiernos municipales y de la población, a través de la digitalización de los procesos administra-
tivos. El resultado esperado es el mejor funcionamiento y la mayor transparencia del sector público frente
a la ciudadanía.
Caso de estudio desarrollado por Carlos Alberto Ricaño Alcalá exclusivamente con fines didácticos. No debe ser considerado como referencia de
gestión adecuada o inadecuada de una situación determinada. (Los personajes y hechos han sido modificados y adaptados de su versión original
para proteger la confidencialidad)
Fecha de elaboración: 09-Nov-12
15.
16. 15
[ Gobiernos Locales Digitales, acercando el gobierno a los ciudadanos. ]
1. Antecedentes
En los municipios mexicanos resulta complejo y prolongado realizar trámites respecto a la generación de
obras y servicios públicos de calidad relacionados con el mejoramiento de las condiciones de vida de la
población, desde la perspectiva de los derechos humanos, el cuidado del medio ambiente y como parte
de una auténtica cultura democrática. La atención y la calidad en el servicio que los municipios otorgan
podrían mejorar de manera sustancial en un marco de descentralización y desarrollo regional, con la par-
ticipación activa de los ciudadanos, y la rendición de cuentas, de las autoridades, de manera responsable,
transparente y puntual.
La ineficiencia de los municipios como servidores públicos se debe, entre otras razones, a que los trámi-
tes de la ciudadanía y su administración interna se realizan aún de forma manual, lo que provoca lentitud,
un amplio margen de errores en la integración de los datos e incluso duplicidad de procesos.
Si bien en algunos casos se ha iniciado el proceso de automatización con la incipiente introducción
del uso de la tecnología, la información no siempre está automatizada ni en línea, se dificulta la toma de
decisiones en forma eficiente y oportuna por las diferentes instancias, además de que se hacen lentas las
actividades de todas las áreas del municipio. Por otra parte, si ya se cuenta con un sistema electrónico, éste
muchas veces no es integral ni amigable. El resultado en uno y otro caso es la ineficiencia y el costo elevado
en la operación de los servicios, la poca transparencia en las operaciones diarias del municipio y la imposi-
bilidad de que el ciudadano siga su trámite en línea para agilizar los procesos de gestión.
Se ha detectado que, en general, las áreas municipales con problemas de trámites y servicios abarcan la
presidencia municipal y las áreas para la atención ciudadana; contraloría; protección civil; seguridad públi-
ca; construcción y obra pública; tesorería; contabilidad; desarrollo social y DIF así como los programas de
apoyo al campo y a la zona urbana; PYMES y desarrollo empresarial y el área jurídica.
El desarrollo sustentable del gobierno requiere de la convergencia de la sociedad. La desconexión entre
ambos arroja frustración, incita a la desconfianza y cancela el desarrollo, es decir, el desarrollo local no es
sólo tarea gubernamental, sino acciones conjuntas entre gobierno y sociedad.
El CENETI, en su carácter de organismo público promotor del e-gobierno planteó el proyecto Gobier-
nos Locales Digitales (GLD), para instrumentar la generalización de uso de las herramientas tecnológicas
de información y comunicaciones (TIC) en los municipios de nuestro país, a partir de la utilización de
diferentes plataformas, básicamente las electrónicas, como los portales y las de colaboración, con el pro-
pósito de lograr la la integración de la actividad gubernamental con los medios electrónicos y propiciar
que los servidores públicos lleven a cabo sus tareas de manera más eficiente y eficaz, en beneficio de los
ciudadanos y de las PyMEs.
La Organización para la Cooperación y el Desarrollo Económico (OCDE, 2005) señala que el e-gobierno
debe estar orientado a beneficiar al usuario, es decir, a los ciudadanos y a las empresas, haciendo que los
servicios electrónicos sean más congruentes con sus necesidades. También propone una distribución mul-
ticanal de los servicios, de manera que se combinen convenientemente los accesos tradicionales con los
electrónicos para garantizar la atención oportuna a todos los usuarios.
Asimismo, esta organización sugiere que la instrumentación del e-gobierno repercuta de manera po-
sitiva en los procesos habituales dentro de la administración, y promueva que se economicen esfuerzos y
costos para que los servicios se brinden de manera más homogénea y con mayor calidad y eficiencia para
los usuarios.
17. 16
| Casos de estudio |
e-gobierno1
en México
Los objetivos del CENETI son: crear espacios de mayor colaboración ciudadana en el ámbito local y regio-
nal; incrementar la eficiencia y la competitividad de los gobiernos locales mediante la adopción y el uso de
las TIC, que implicaran las mejores prácticas en la administración local; mejorar la relación entre los ciuda-
danos y el gobierno, asimismo mejorar los canales de interacción entre los diferentes niveles de gobierno.
Con miras a ello, CENETI realizó un proceso de identificación del grado de desarrollo de los servicios de
gobierno electrónico en el país encontrándose los resultados que se describen a continuación.
2. Instrumentación del proyecto: gobiernos locales digitales (GLD)
La iniciativa de los GLD, tiene al ciudadano como eje rector de los adelantos en TIC que se realicen en los
municipios; por lo tanto, era necesario definir con claridad los papeles y las responsabilidades que tendrían
los involucrados en los procesos con la finalidad de no perder de vista este objetivo, seguir un plan de tra-
bajo y tener conciencia del alcance del proyecto.
Para establecer claramente cómo se realizaría la instrumentación de los GLD, los municipios se clasifi-
caron de acuerdo con el avance en materia de gobierno electrónico en que se encontraban. Asimismo, se
determinaron las fases en que el proyecto se llevaría a cabo en cada municipio y se especificó la infraestruc-
tura y la arquitectura a utilizar, con la finalidad de estandarizar las herramientas.
Si bien la iniciativa tendría que atender el mayor número de municipios, el nivel tecnológico previo de
cada uno determinaría el plan de instrumentación del proyecto; su área y su población serían igualmente
factores decisivos.
El modelo inicial consideraba que el CENETI y su equipo tenían la capacidad de atender siete muni-
cipios durante 2009. Se trataba de un portafolio de servicios básicos al que se añadirían otros, que en su
conjunto cubrirían los requerimientos de los municipios de cualquier nivel.
La arquitectura ancla de negocios que se utilizó fue de código abierto con el fin de mantener costos
competitivos. Por otro lado, se establecieron sociedades tecnológicas con expertos en tales herramientas,
con la finalidad de integrar una solución eficaz y competitiva; todo esto en el marco de un modelo perma-
nente de desarrollo de productos y servicios para los municipios.
Por su parte, la distribución de los servicios y el contacto de primer y segundo niveles se realizarían por
medio de pequeñas y medianas empresas del sector de TIC locales en representación del CENETI, que sería
responsable del aseguramiento de la calidad de los servicios.
Desarrollo de la Plataforma GLD
Para poner en marcha la iniciativa, el CeNETI desarrolló una plataforma tecnológica a partir de herramien-
tas de código abierto que nombró PLATAFORMA GLD.
Objetivo general
Ofrecer servicios de gobiernos electrónicos de forma estratégica para el apoyo y crecimiento del municipio
y la localidad.
Objetivos específicos
• Crear espacios de mayor colaboración ciudadana en el ámbito local y regional.
1 e-gobierno: Se entiende por gobierno electrónico o e-gobierno, el uso de la tecnología, en particular las TIC, como una herramienta del gobier-
no para su administración y para su oferta de servicios a la ciudadanía, lo que constituye una tendencia en las sociedades modernas.
18. 17
[ Gobiernos Locales Digitales, acercando el gobierno a los ciudadanos. ]
• Incrementar la eficiencia de los gobiernos locales mediante la adopción y el uso de las TIC que con-
templen las mejores prácticas en cuanto a la administración local y la participación ciudadana.
• Mejorar la relación ciudadano-gobierno.
• Impulsar la competitividad de los gobiernos locales.
• Mejorar los canales de interacción entre los diferentes niveles de gobierno.
Modelo conceptual
El esquema de gobierno digital debe comprender cuatro pasos fundamentales:
1. Establecimiento de mecanismos tecnológicos de cooperación entre entidades de gobierno para ami-
norar la complejidad a la que normalmente es sometido el ciudadano en sus trámites.
2. Disponibilidad de información sobre procesos de gobierno y automatización paulatina de algunos
aspectos básicos de la relación gobierno-ciudadano.
3. Habilitación de servicios transaccionales gobierno-ciudadano lo que incluiría solicitudes, pagos y
entregas automatizadas.
4. Establecer un sistema de transparencia con base en los pasos previos, y fomentar la participación
ciudadana en la toma de decisiones relativas a la administración pública.
La PLATAFORMA GLD quedó conformada por dos portales: el Portal municipal y la Ciudad digital, cuyas
características y funcionalidades se describen a continuación:
Portal municipal
Su objetivo es facilitar una mejor relación entre los gobiernos y los distintos actores de la sociedad, acer-
cando información útil y estableciendo nuevos canales de comunicación para atender las demandas ciu-
dadanas. Adicionalmente el portal permitirá mejorar la eficiencia de los trámites y servicios que ofrece el
gobierno así como su gestión interna.
Sus principales funcionalidades son: administración de procesos internos o BackOffice (adquisiciones,
compras, recursos humanos, financieros, presupuestales); ventanilla única para trámites al ciudadano; por-
tal para la difusión de las políticas sociales y de gobierno; atención y participación ciudadana; transparencia
y rendición de cuentas; adicionalmente contaba con herramientas interactivas como directorios, calenda-
rios de eventos, administradores de noticias, imágenes y videos, chats, blogs, foros, encuestas y agendas de
servidores públicos.
El esquema de la página principal del Portal en desarrollo por el CeNETI.
19. 18
| Casos de estudio |
Portal de la ciudad digital
El objetivo es promover las relaciones entre todos los actores de la sociedad para generar inteligencia colec-
tiva por medio del empleo de redes sociales; en un solo espacio debe existir información pública dispuesta
de manera ordenada lo que se traducirá en oportunidades para encontrar respuestas a las inquietudes de
todos los integrantes de la comunidad.
En este portal los usuarios generan sus propias cuentas en un esquema de redes sociales: cuenta de usua-
rios, datos personales, actualizaciones, enlaces, fotos, videos, audio, archivo, comentarios, entrada en blog,
texto wiki, publicar e invitar a eventos, publicar en directorio de negocios, proponer y responder temas en
foro, crear comunidades, suscribir a comunidad y a sus actualizaciones, participar en sala de chat, realizar
trámites de gobierno.
De la misma forma se crearon comunidades electrónicas en las que se registraban miembros, actua-
lizaciones, enlaces, fotos, videos, archivos de audio, archivos, comentarios, entrada a blog, wikis, eventos,
asistentes a eventos, directorio de negocios, temas de foros, respuestas de foro, sala de chat.
El esquema de la página principal de la Ciudad Digital:
Valor de la plataforma
El valor que aportó consistía en facilitar la interrelación entre los diversos actores de la sociedad, minimi-
zando las limitaciones geográficas (espacio) y de tiempo. Al impulsar que las relaciones entre actores de la
sociedad se dieran de manera más sencilla y ordenada, se promovió el desarrollo local y regional.
El portal municipal y la ciudad digital aportarían, por medio de la innovación tecnológica, el desarrollo
social, económico y político del municipio o comunidad.
20. 19
[ Gobiernos Locales Digitales, acercando el gobierno a los ciudadanos. ]
Modelo de Negocio
Conforme al mapa de ruta definido para la evolución de la PLATAFORMA GLD, en los años 2009, 2010, 2011
y 2012, podría convertirse en un referente en el e-gobierno municipal:
ESPACIO
TIEMPO
Gobierno
Negocios
Academia
ONGs
Ciudadanos
Gobierno
Negocios
Academia
ONGs
Ciudadanos
VOCACION
BARRERAS
GOBIERNOS LOCALES DIGITALES
Necesidades
ACCESO MULTICANAL
Necesidades
Agosto 2009 Ciudadanía +
Gobierno =
Desarrollo
RETOS EN
EL TIEMPO
Inicio
+ Estrategia
+ Crecimiento
enfocado
+ Valor Estratégico
+ Referente
Posicionamiento Consolidación Liderazgo
2009 2010 2011 2012
ACCIONES
/
RESULTADOS
Portal Municipal y
Ciudad Digital
Administración
municipal
Seguimiento de
trámites
Servicios Públicos
• Diseño de políticas
Públicas
• Colaboración
interpersonal
• Plataforma Regional /
intermunicipal
• Confirmación de
impacto social
• Certificación de
prácticas
• Crecimiento de
plataforma Gobiernos
Municipales
• Investigación temas
especializados con SI
• Plataforma tecnológica
• Alianzas estratégicas
• Modelo Operativo
inicial
• Pilotos Gobierno Local
y Ciudad Digital
Atención
Ciudadana
Automatización de
trámites
Ingresos (Predial,
agua, licencias,
multas)
Pagos en línea
Indicadores de
Gestión
Interoperabilidad
con otras instancias
y niveles de
gobierno
21. 20
| Casos de estudio |
Con el fin de determinar el mercado objetivo para la PLATAFORMA GLD se utilizaron los datos de población
por municipio con que cuenta el Instituto Nacional para el Federalismo y el Desarrollo Municipal, INAFED
(Tomados del portal Web del INAFED, apartado “Enciclopedia de los municipios y delegaciones de México” en
[http://www.e-local.gob.mx/wb/ELOCAL/ELOC_Enciclopedia]):
Total de municipios de la república:.... 2,439
Sin las delegaciones D.F.:...................... 2,423
Sin municipios con menos de
20,000 habitantes.
..................................... 816
Sin municipios con más de 60
60,000 habitantes.
..................................... 723
MERCADO OBJETIVO 723 MUNICIPIOS
Como se observa en la tabla anterior, en una selección simple de municipios entre los 20 mil y 150 mil ha-
bitantes se tenía como mercado objetivo a 723 municipios. Las consideraciones que se tomaron en cuenta
para esta selección fueron: a) los municipios de menos de 20 mil habitantes no contaban con la infraestruc-
tura básica para poder operar la plataforma; b) los municipios de más de 150 mil habitantes normalmente
cuentan ya con soluciones tecnológicas similares a las que ofrece la PLATAFORMA GLD. Inicialmente ningu-
no de estos grupos formaría parte del mercado objetivo.
Para la selección de los municipios candidatos a participar en la primera fase de la iniciativa de Gobier-
no Locales Digitales (GLD), adicionalmente de tomaron en cuenta los siguientes tres criterios:
1) Agenda electoral. Se consideraron aquellos municipios que estuvieran en su primer o segundo año
de gobierno, considerando el aprovechamiento al máximo de los tiempos de cada administración
municipal, relativamente cortos.
2) Población. Se tomaron en cuenta aquellas poblaciones con un número mayor a 75,000 habitantes,
buscando tener un impacto en el mayor número posible de ciudadanos. Esta cifra está en concordan-
cia con la utilizada en estudios sobre portales municipales Web (Sandoval, 2006).
3) Contexto favorable. Se consideraron aquellos municipios que aparecieran en el estudio de Competi-
tividad urbana 2007 del IMCO. En este estudio se identifican 71 zonas urbanas del país que represen-
taban el 59.4% de la población y el 89.4% de la producción total nacional, de ahí la importancia de
tomar ese estudio como punto de partida.
Con estos criterios se filtraron aquellos municipios que se encontraban en su primer o segundo años de go-
bierno, obteniendo una muestra de 1,553 municipios que comenzaron su administración en 2008 o 2009.
Posteriormente, se discriminaron aquellos que tuvieron población igual o mayor a 75,000 habitantes,
obteniendo una muestra de 83 municipios, como punto de arranque para el despliegue de la Plataforma
GLD
Estado Número de municipios
Aguascalientes 1
Baja California Sur 2
Chiapas 10
Guerrero 6
22. 21
[ Gobiernos Locales Digitales, acercando el gobierno a los ciudadanos. ]
Estado Número de municipios
Hidalgo 5
Michoacán de Ocampo 9
Nayarit 2
Oaxaca 4
Puebla 7
Quintana Roo 2
Sinaloa 7
Tamaulipas 9
Veracruz-Valle 19
Total 83
A partir de la selección se diseñó un modelo de financiero que permitiera, como se comentó, el creci-
miento y la sostenibilidad de la plataforma. Este modelo financiero se basó en las siguientes premisas:
• Costos directos: servicios de trámites, portal municipal, ciudad digital, infraestructura, estructura
organizacional del CENETI
• Costos indirectos: fijos, mantenimiento, variables de venta.
• El crecimiento proyectado incluyó incremento de ventas, inflación, incremento salarial, aumento de
estructura organizacional, adquisición de equipo adicional, depreciación.
• La oferta de servicios iniciaría con la versión 1.0
• El servicio se estableció mediante contratos por periodos multianuales renovables de al menos 1 año.
• La proyección de los ingresos y costos se estimó con los costos de renta de la versión 1.0
• Es un modelo financiero que incluyeron únicamente los costos de operación y no los costos de
arranque.
Se desarrollaron tres escenarios con un número distinto de incorporación de municipios por año:
Escenario pesimista 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018
Incremento en ventas nuevas No. GLD 4 15 19 21 21 24 21 24 23 26
Incremento en ventas acumuladas No. GLD 4 19 38 59 80 104 125 150 173 199
Escenario moderado 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018
Incremento en ventas nuevas No. GLD 5 20 21 25 25 34 33 33 39 47
Incremento en ventas acumuladas No. GLD 5 25 46 71 96 130 163 196 235 282
Escenario optimista 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018
Incremento en ventas nuevas No. GLD 7 31 30 34 31 40 35 31 35 41
Incremento en ventas acumuladas No. GLD 7 38 68 102 133 173 208 239 275 316
El planteamiento comercial de la PLATAFORMA GLD hacia los municipios se formuló en un esquema de
Software como Servicio SaaS, (por sus siglas en inglés Software as a Service), lo que presentó ventajas impor-
tantes para los municipios, ya que no requerían realizar inversiones iniciales cuantiosas, ni implementar
infraestructura de cómputo y tampoco requerían personal especializado, ni equipos de soporte para asegu-
rar la continuidad de las operaciones.
23. 22
| Casos de estudio |
Algunas de las ventajas del esquema SaaS fueron:
• Implementación del servicio en seis semanas
• Capacitación en la administración de los portales y en el uso de las herramientas
• Soporte técnico y operativo
• Hospedaje de portales y herramienta de seguimiento en un centro de datos Tier II con disponibili-
dad de 99 %
• Publicación en Internet con una velocidad de 6 Mbps
• Respaldos y seguridad de información
Con un costo de renta mensual de 25 mil pesos se generaron los siguientes escenarios:
Ganancias en valor presente neto
Evolución de ganancias a lo largo de 10 años
(En millones de pesos)
Corrección del ciclo de vida del producto
Año 0 1 2 3 4 5 6 7 8 9 10
50% 100% 100% 100% 100% 100% 100% 100& 90% 75% Tasa
Pesimista -0.458 -10.680 -7.107 -4.533 -1.842 1.377 3.826 7.358 9.140 10.349 3.6%
Medio -0.173 -8.955 -5.701 -2.240 1.142 6.415 11.055 15.752 19.798 22.264 4.4%
Optimista 0.199 -5.220 -1.567 3.405 7.607 14.156 18.996 23.276 25.985 26.572 5.3%
Análisis financiero. Resultados Finales
Con corrección de ciclo de vida
En millones de pesos
VPN ROI (meses) TIR
Pesimista 5.4 109 -2%
Medio 48.3 83 15%
Pesimista 94.1 58 32%
140.000
Pesimista
Medio
Optimista
120.000
100.000
80.000
60.000
40.000
20.000
1
4
7
10
13
16
19
22
25
28
31
34
37
40
43
46
49
52
55
58
61
64
67
70
73
76
79
82
85
88
91
94
97
–
-20.000
-40.000
-60.000
100
103
106
109
112
115
118
121
24. 23
[ Gobiernos Locales Digitales, acercando el gobierno a los ciudadanos. ]
Acciones para la promoción y el despliegue de la plataforma
Con el fin de dar a conocer la plataforma se desarrollaron diferentes estrategias:
• Organización de dos Seminarios en los que por medio de las asociaciones de municipios que hay
en México se invitaron a presidentes y otros funcionarios municipales a participar, principalmente
de aquellos municipios identificados como “punto de arranque”. En los seminarios se impartieron
conferencias relacionadas con la gestión municipal y en una de ellas se presentó la Plataforma GLD.
Ambos seminarios tuvieron muy buena acogida y los participantes mostraron interés por la posible
implementación en sus municipios.
• Se implementó una fuerza de venta interna que generó un calendario de visitas para lograr que los
municipios del “punto de arranque” se subieran a la plataforma.
La tabla anterior muestra una proyección de visitas a los municipios.
• Con el fin de dar más amplitud al esfuerzo comercial, se diseñó un esquema distribución por medio
de Canales, en el que por medio de empresas de TI locales y regionales se pudiera llegar de manera
más eficiente a un mayor número de municipios, además de que el beneficiar a las PyMEs de TIC es
parte de los objetivos del CENETI.
La siguiente figura muestra el concepto del modelo de canales empleado para el despliegue de la platafor-
ma GLD.
25. 24
| Casos de estudio |
3. Problemática
Una vez que se ejecutaron las diferentes acciones de difusión y venta de la plataforma, los resultados no
fueron los esperados. Como se indica en los escenarios presentados, en el escenario pesimista se proyectó
incorporar en los primeros dos años a 19 municipios, cuatro en el 2009 y 15 en el 2010, sin embargo los
resultados fueron:
2009 – 1 municipios
2012 – 4 municipios
Total municipios incorporados en los dos primeros años: cinco
Esto representó apenas el 26% del peor escenario proyectado, lo cual dejó fuera de toda viabilidad al
proyecto.
Semantic Web Builder
Ecosistema Canales
Gobierno
Local
Sociedad
Local
Visitantes/
Turistas
Empresas/
Asociaciones
Educación/
Investigación
Otros
Gobiernos
Eventos,Promoción Empresarial, Asistencia Turística Alertas (SMS mail)
Voz ciudadana Centro de Contacto Bolsa de trabajo Entretenimiento
Consultas ciudadanas, conectividad
Deporte, sociales, Anuncios/Avisos Noticias locales Infomación (Mapas, leyes
y reglamentos, ligas) Medio ambiente Promoción deportiva
Trámites Transparencia Servicios (Predial, Agua, Multas)
Directorios Locales Emergencias Protección Civil Interaccion y comunicacion
con otros municipios con gobiernos estatales y federales
Contabilidad y Tesorería RRHH y Nómina Adquisiciones Almacén Inventarios
Presupuesto
eGob
Red Social
Interrelación
eGob-Sociedad
Portal Municipal Ciudad Digital
Otros Municipios
Gobiernos Estatales
Gobierno federal
Red
INFOTEC
de Soluciones
(Esquema SaaS)
Entorno TIC
local
PyMEs TIC
Plataforma
de interoperabilidad
Canal
PyME
TIC
Canal
PyME
TIC
Canal
PyME
TIC
Canal
Regional
PyME TIC
Contacto
GL
Contacto
GL
Contacto
GL
Gobierno
Local
Sociedad
Local
INFOTEC
Canal Indirecto
Canal Directo
Desarrollo de
Negocio interno
Representantes de
Valor Agregado
2010
2011
2012++
26. 25
Caso 2:
Solución tecnológica: enfrentándose a las limitantes de un cliente.
Durante el primer semestre del año 2011, Rubén Feldman, gerente de desarrollo tecnológico de la empre-
sa Arch&Soft y su principal colaborador Carlos Amador, enfrentaban el reto de dar respuesta a los requeri-
mientos de uno de sus clientes más importantes que había solicitado el desarrollo de sitios o “Portales WEB
Dinámicos”, a realizarse en un tiempo máximo de tres meses. Las especificaciones establecidas por el clien-
te demandaban la inclusión de tecnología vanguardista, novedosa e innovadora pero al mismo tiempo, de
fácil adopción y bajo costo. Rubén y Carlos debían dar respuesta a este requerimiento, sin embargo, sabían
que la tecnología con la que contaba el cliente era obsoleta y la técnica para su uso no era homogénea.
La propuesta debería garantizar el desarrollo de un producto de software de alta calidad, optimizando el
tiempo de desarrollo y su costo. Además, el nivel de cumplimiento para las características de mantenibili-
dad, portabilidad, usabilidad y seguridad debería ser mantenido o preferentemente mejorado, respecto a
las soluciones que Arch&Soft había ofrecido anteriormente. Ante este panorama, Rubén y Carlos debían
encontrar una solución que diera respuesta a estos requerimientos, ya que de no hacerlo, se podría perder
una cuenta que representaba cerca de $20, 000,000 de pesos anuales.
Caso de estudio desarrollado para fines didácticos exclusivamente, por el Ing. Eduardo Zapién Granados y por M. en C. Gustavo Arellano Sandoval
con la colaboración de Daniel Cortés Pichardo, para fines didácticos exclusivamente. No debe ser considerado como referencia adecuada o inade-
cuada de gestión directiva. (Los personajes y hechos han sido modificados y adaptados de su versión original para proteger la confidencialidad)
Fecha de elaboración: 20-09-12
27.
28. 27
[ Solución tecnológica: enfrentándose a las limitantes de un cliente. ]
1. Antecedentes
Durante el primer semestre de 2011, uno de los clientes más importantes de la empresa Arch&Soft solici-
tó el desarrollo de varios sitios o “Portales Web dinámicos” en un tiempo reducido y con especificaciones
complejas, pero comunes a todos ellos. Tales especificaciones demandaban la inclusión de tecnología van-
guardista, novedosa e innovadora pero al mismo tiempo, de fácil adopción y bajo costo. Rubén Feldman,
gerente de desarrollo tecnológico, y Carlos Amador, subgerente de la misma área, debían dar respuesta al
requerimiento, sin embargo, sabían que se contaba con tecnología obsoleta y la técnica para su uso no era
homogénea. La propuesta debía redundar en una mejora tangible y mesurable en términos de calidad,
rapidez de desarrollo y su consecuente impacto en el costo del desarrollo del producto de software. Aunado
a lo anterior, el nivel de cumplimiento para las características de mantenibilidad, portabilidad, usabilidad
y seguridad debía ser conservado, y preferentemente mejorado, respecto al que Arch&Soft había estado
ofreciendo anteriormente. Ante este panorama, Rubén y Carlos debían encontrar una solución que die-
ra respuesta a estos requerimientos, ya que de no hacerlo, se podría perder la cuenta que representaba
cerca de 20 millones de pesos anuales.
2. La institución
Arch&Soft era una institución mexicana de innovación y desarrollo tecnológico, que contribuía a la com-
petitividad de instituciones públicas y de las pequeñas y medianas empresas (pymes), a través del uso
estratégico de las tecnologías de información y comunicaciones (TIC).
Arch&Soft ofrecía servicios de: consultoría; desarrollo de productos y soluciones tecnológicas para el sec-
tor público y privado; formación de capital humano en el uso estratégico de las TIC e investigación aplicada
en temas relacionados con el desarrollo de Internet, nuevas tecnologías, gobierno electrónico y sociedad
de la información.
Los especialistas con los que contaba Arch&Soft se desempeñaban en una variedad de disciplinas como:
- Seguridad en informática (perimetral y software).
- Infraestructura de redes y telecomunicaciones.
- Desarrollo de software a la medida.
- Consultoría en procesos de negocio.
- Investigadores y académicos en tecnologías de la información.
Los tipos de proyectos abarcaban una variedad de sectores entre los cuales se encontraban:
- Sector Financiero.
- Sector Salud.
- Sector Gubernamental.
- Sector Académico.
Las plataformas de desarrollo soportadas por Arch&Soft eran:
- Plataforma J2EE.
- Plataforma .NET.
- Plataforma mobile (Android, IOS, WinPhone y Blackberry).
29. 28
| Casos de estudio |
3. Perfil de Rubén Feldman
Rubén Feldman contaba con más de 10 años de experiencia en el área de diseño, evaluación, síntesis y rea-
lización de arquitecturas de software. Había participado en el proceso de desarrollos de sistemas con RUP1,
MSF2, ICONIX3 y las principales metodologías ágiles; Scrum4 y Extreme Programming5.
Rubén se desarrolló como consultor con UML6, creó varios Framework para distintos ramos de la indus-
tria, poseía conocimiento en las tecnologías de .NET y J2EE. También tenía experiencia en el análisis y
diseño orientado a objetos con UML.
Desde el 2001, Rubén desempeñó roles que involucraban el diseño, análisis, evaluación y construcción
de sistemas de software. Ayudó mediante su conocimiento sobre estándares de calidad, a definir nuevos
procesos y metodologías para la empresa. Sus conocimientos permitierón colaborar en la definición de
las arquitecturas de los proyectos de Arch&Soft. Sus colegas opinaban que su código funcionaba, era muy
bueno y fácil de mantener y que poseía un profundo conocimiento sobre los atributos de calidad que un
sistema de software debía cumplir; permitiéndole crear soluciones al contexto del proyecto.
En el año 2005 diseñó e implementó el sistema de seguridad nacional desarrollado en J2EE, mismo
que se encuentra operando hasta la fecha con las mejores prácticas de diseño en seguridad de sistemas de
software.
En el año 2007 dirigió varios sistemas que utilizan tecnologías no homogéneas, llevando a cabo la solu-
ción de interoperabilidad y operación de los mismos. Definió las políticas y estándares de seguridad con
las que se construyó el sistema.
Durante el año 2009, Rubén impartió diversos cursos, a nivel nacional e internacional, sobre el diseño,
análisis, síntesis y construcción de sistemas de software de alta criticidad. Su papel como instructor y consul-
tor de sistemas ha sido apreciado por diversos clientes.
Hasta el año 2012, se desempeñó como arquitecto jefe en el departamento de arquitectura de solucio-
nes de Arch&Soft.
4. Perfil de Carlos Amador
Carlos contaba con más de cuatro años de experiencia en el diseño, y evaluación de sistemas de software.
Había participado en desarrollos de sistemas como RUP y Extreme Programming. Se había desarrollado como
programador en J2EE y .NET. y se enfocaba a crear soluciones técnicas y poseía suficiente conocimiento en
UML.
Desde el 2006, Carlos desempeñó roles que involucraban el diseño y construcción de sistemas de soft-
ware. Aprovechando sus conocimientos tecnológicos, Carlos ayudó a definir el diseño detallado en plata-
formas J2EE y .NET. Sus conocimientos le permitieron colaborar en la definición de las arquitecturas de los
proyectos de Archi&Soft. Sus compañeros opinaban que su código funcionaba, era bueno y fácil de mante-
ner y que poseía conocimientos sobre los principales atributos de calidad que un sistema de software debía
cumplir y cómo los debía cumplir.
Durante el año 2009, impartió cursos de programación en java a nivel básico, intermedio y avanzado.
Sus conocimientos tecnológicos le ayudaron a capacitar al personal de desarrollo.
Hacia el año 2012, se preparó como líder técnico en el área de desarrollo con tecnología java.
30. 29
[ Solución tecnológica: enfrentándose a las limitantes de un cliente. ]
5. Descripción de la problemática
La problemática inicial del cliente de Arch&Soft incluía diversos elementos a considerar, anunciando de
manera anticipada la solicitud del desarrollo de más de diez sistemas que en su conjunto deberían ser
desarrollados con la misma tecnología, facilitando su mantenibilidad y vigencia tecnológica por al menos
cinco años más. Aunado a lo anterior, estos sistemas tendrían que ser desarrollados en su totalidad, en un
tiempo no mayor a ocho meses.
Una de las mayores expectativas del cliente de Arch&Soft era poder dar (de manera autónoma y perso-
nal) mantenimiento a cada uno de los nuevos sistemas que, adicionalmente, estarían desplegados en sus
propias instalaciones.
El cliente de Arch&Soft argumentaba que todos los sistemas tenían una base en común, dado que todos
ellos (además de estar desarrollados con la misma tecnología) poseían interfaces idénticas de registro, in-
greso y administración de los datos de los usuarios de cada sistema.
El personal del cliente de Arch&Soft había trabajado durante más de ocho años con las tecnologías que,
en su tiempo, eran de vanguardia, sin embargo, al paso de los años, no se realizó ningún tipo de inversión
en la modernización de las mismas. Tampoco se promovieron programas internos de capacitación ni se
concedió tiempo para la auto capacitación.
De lo expuesto anteriormente, el personal del cliente desarrolló una dependencia a las tecnologías que
en un inicio adoptaron y expresaron que no tenían el deseo de adoptar nuevas, ya que consideraban que
esto sería una pérdida de tiempo.
Por otro lado, al igual que en el aspecto tecnológico, los temas relacionados con la infraestructura y las
telecomunicaciones habían sido poco atendidos en los últimos años, por lo que el equipo que se utilizaba
carecía de capacidades físicas que impedían la instalación de software demandante de recursos como me-
moria, procesador y almacenamiento.
Una característica adicional que fue solicitada por el cliente de Arch&Soft era que, con excepción del
software para bases de datos, todo el restante debía ser gratuito y de código abierto. Lo anterior también
incluía el sistema operativo, los servidores de aplicaciones y el servidor de contenido estático.
Finalmente, el cliente de Arch&Soft comentó que, aunque la infraestructura sería mejorada, ello no
ocurriría en el corto plazo y que por ello, los desarrollos deberían tener la capacidad de funcionar co-
rrectamente con independencia de la plataforma en la cual fueran desplegados. De antemano no se sabía
cómo podría evolucionar la plataforma y la gama de posibilidades cubría todo el espectro de plataformas,
es decir, Windows, LINUX, Solaris de 32 o 64 bits, etcétera.
6. Resumen de retos a resolver
Con base en el conjunto de características requeridas por el cliente de Arch&Soft, Rubén y Carlos tenían el
reto de identificar un conjunto de problemáticas a resolver con la finalidad de atender tales necesidades.
En resumen, los retos a enfrentar eran los siguientes:
1) El estado técnico-tecnológico que el cliente poseía no estaba actualizado y muchas de sus tecnologías
habían caído en desuso.
2) Los recursos humanos que el cliente tenía contratados, conocían únicamente las tecnologías legadas
que habían estado trabajando los últimos diez años y para la adopción de nuevas tecnologías requerían
no sólo de una transferencia de conocimientos sino que también se necesitaba tiempo para madurar
tales conocimientos.
31. 30
| Casos de estudio |
3) La infraestructura del cliente (servidores físicos y de software) soportaba versiones antiguas que po-
seían de manera inherente muchos puntos vulnerables, haciéndolos presa fácil de ataques informá-
ticos e impidiendo la instalación de software moderno.
Rubén en posición reflexiva, le señaló a Carlos: “ante este panorama tan complicado, me pregunto ¿cómo podremos
diseñar una solución adecuada para nuestro cliente, cumpliendo con sus expectativas para los portalesWeb dinámicos,
pero, ajustándonos a las limitantes que hemos identificado?”
Glosario
1. RUP
Rational Unified Process en inglés, habitualmente resumido como RUP es un proceso de desarrollo de software
creado por la empresa Rational Software, actualmente propiedad de IBM. Junto con el Lenguaje Unificado
de Modelado UML, constituye la metodología estándar más utilizada para el análisis, diseño, implementa-
ción y documentación de sistemas orientados a objetos.
2. MSF
Microsoft Solutions Framework (MSF) es un conjunto de principios, modelos, disciplinas, conceptos y linea-
mientos para el desarrollo de tecnologías de la información a partir de soluciones de Microsoft. MSF no se
limita sólo al desarrollo de aplicaciones, también es aplicable a otros proyectos de TI como proyectos de
implementación de redes o infraestructura. MSF no obliga al desarrollador a utilizar una determinada me-
todología (Waterfall , Agile ), pero les permite decidir qué método utilizar.
3. ICONIX
Iconix es una metodología de desarrollo de software que es anterior al Rational Unified Process (RUP), Progra-
mación Extrema (XP) y el desarrollo ágil de software. Como RUP, su proceso está basado en UML y casos de
uso pero es más ligero que RUP. A diferencia de los enfoques XP y Agile, Iconix promueve la captura de
suficientes requisitos y documentación de diseño, pero sin abundar en el análisis. El Proceso de esta meto-
dología utiliza sólo cuatro diagramas UML basados en un proceso de cuatro pasos que convierten casos de
uso en código de trabajo.
4. SCRUM
Scrum es un marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e in-
cremental utilizado comúnmente en entornos basados en el desarrollo ágil de software.
5. Extreme Programming
La programación extrema o eXtreme Programming (XP) es una metodología de desarrollo de la ingeniería de
software formulada por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained:
Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que és-
tos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone
más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios
de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de pro-
yectos. Creen que ser capaz de adaptarse a los cambios en cualquier punto de la vida del proyecto es una
aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e
invertir esfuerzos después en controlar esos cambios.
32. 31
[ Solución tecnológica: enfrentándose a las limitantes de un cliente. ]
6. UML
UML, por sus siglas en inglés, Unified Modeling Language, es el lenguaje de modelado de sistemas software
más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un
lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar
para describir un “plano” del sistema (modelo), incluyendo aspectos conceptuales tales como procesos
de negocio, funciones del sistema y aspectos concretos como expresiones de lenguajes de programación,
esquemas de bases de datos y compuestos reciclados.
7. RAD
RAD, por sus siglas en inglés, Rapid Application Development, es una metodología de desarrollo de software
que utiliza una planeación mínima que favorezca la realización rápida de prototipos. El desarrollo RAD
envuelve métodos de desarrollo iterativo y prototipado de software.
Anexo
Este anexo describe el detalle de la infraestructura de software del cliente de Arch&Soft.
La plataforma, de manera invariable, era J2EE soportada por sistemas operativos LINUX con distribución
Redhat 6. La base de datos era Oracle 10g y no estaba permitido utilizar la tecnología de Hibernate, sin em-
bargo, el cliente estaba abierto a evaluar y en su caso, adoptar otras tecnologías asociadas a la plataforma
J2EE.
El servidor de aplicaciones que el cliente poseía era Glassfish 2.0 y en ocasiones llegaba a utilizar Tomcat
7. No existían posibilidades de utilizar un servidor de aplicaciones de paga, como lo es WebLogic.
Respecto a los servidores físicos, éstos poseían una memoria (cada uno) de 24 Gigas en RAM y dos
procesadores Xeon Cuad Core de 3.5 GHz cada uno. El cliente poseía un total de 18 servidores que, si era
necesario, podían ser dispuestos en modo de alta disponibilidad, balanceados por un F5.
33.
34. 33
Caso 3:
El camino de los servicios en la nube
En mayo de 2011, Julio Molina, gerente de la empresa mexicana de tecnología, Funtech, recibió un reporte
sobre el comportamiento de nuevos proyectos que se habían trabajado durante los primeros cuatro meses
del año. El reporte indicó que las capacidades administrativas y técnicas estaban a punto de ser rebasadas,
pues se presentaba un incremento de nuevos servicios solicitados por los clientes y una alta demanda de
renovación de contratos que implicaban requerimientos técnicos diferentes. Funtech, una organización
especializada en servicios de tecnología, había desarrollado proyectos “a la medida” desde el año 1996. A
partir de los resultados del reporte, Julio se reunió con Antonio Bermúdez, director de tecnología en esa
empresa, quien le señaló que tendrían que resolver aspectos como disminución del tiempo de diseño y
entrega de soluciones; diseño de estrategias de implementación de servicios; desarrollo de soluciones inte-
grales; aplicación de las mejores prácticas y estándares en tecnologías de la información; participación del
personal técnico y táctico; tecnologías a utilizar y gobernabilidad tecnológica. Bermúdez resumió los retos
a enfrentar formulando la siguiente pregunta: “¿Cómo integraremos todos estos elementos a través de un
modelo integral?” y le solicitó a Molina que en dos semanas tuviera una propuesta de solución.
Caso de estudio desarrollado por el Ing. Junior Marín, para fines didácticos exclusivamente. No debe ser considerado como referencia de gestión
adecuada o inadecuada de una situación determinada. (Los personajes y hechos han sido modificados y adaptados de su versión original para
proteger la confidencialidad)
Fecha de elaboración: 18-06-12
35.
36. 35
[ El camino de los servicios en la nube ]
1. El pasado exitoso para establecer un futuro
Ante el reto planteado por Bermúdez, Molina recordó dos proyectos de tecnología que habían significado
un reto y que se lograron con esfuerzo, integración y compromiso:
En 1999 el director de una empresa de comunicaciones le planteó a Julio Molina la necesidad de publicar una
página Web en menos de 24 horas. El director entregó un CD con la información necesaria para publicar. El
director comento que el actual proveedor de servicios operaba en Estados Unidos con carencias en condiciones de
acceso a servidores, seguridad y atención para administración. El personal de Funtech se organizó en grupos de
trabajo con expertos en diversas especialidades para atender el requerimiento del cliente: servidores, software, co-
municaciones y servicios de Internet. Se estableció un plan de acción: se definieron versiones de software, tiempos
de instalación del sistema operativo, instalación de aplicaciónes, configuraciones de equipos de comunicación y
ajustes en los servicios de resolución de nombres de dominio. El resultado: Funtech público el portal en 18 horas.
En 2002 el ministerio de educación requería liberar a Internet, dieciocho servicios Web, los cuales es-
taban instalados en treinta servidores, tres de ellos cont enían bases de datos. El equipo de tecnología del
ministerio ya tenia toda la aplicación y software instalado, sin embargo los segmentos de red y configuracio-
nes en el Firewall1
eran responsabilidad del personal de Funtech. De manera inmediata se solicitó realizar
un diagrama del requerimiento, el cual debería contener, dirección IP2
, servicio TCP3
requerido, velocidad
de conexión en red y, sobre todo, la definición de segmentos desmilitarizados y segmentos de contención
de datos.
Con la información integrada, el plan de trabajo revisado y los acuerdos de inicio de configuración, se
logró que en seis horas se realizara una migración de portales de educación que incluía: capas en aplica-
ción, segmentos de red, periodos de tiempo de acceso de administración, usuarios clave de acceso a base
de datos. El trabajo total fue de dos semanas.
Al recordar las lecciones aprendidas que habían dejado estos proyectos, Molina pensó que Funtech era
una organización con una alta capacidad de respuesta ante requerimientos complejos.
Los últimos cinco años habían atendido diferentes clientes con servicios de diseño, implementación y
operación de portales que incluían: la infraestructura de servidores, las tecnologías de respaldos, almacena-
miento de datos de alta velocidad, el software de base de datos, recursos humanos especializados, seguridad
lógica para la protección de los servicios en su publicación a Internet y los esquemas de soporte y mante-
nimiento.
La integración de proyectos de tecnología para portales y servicios Web requería del talento humano
caracterizado por ingenieros y especialistas en diversas áreas de conocimiento. Molina reflexionó, que cada
proyecto realizado en el pasado, tuvo éxito por el talento de las personas que colaboraron para diseñar,
construir e implementar los servicios de Funtech, sin embargo las áreas tecnológicas requerían una inver-
sión en tiempo de aprendizaje, inducción y entendimiento sobre la organización y sus proyectos, debido a
que existía una alta rotación de personal, debido en gran parte poque algunos elementos recibían ofertas
laborales más atractivas.
1 Firewall: Dispositivo que se coloca en una red está diseñado para bloquear el acceso no autorizado, permitiendo al mismo tiempo comunica-
ciones autorizadas.
2 IP: (Internet Protocol), por sus siglas en inglés, Es un protocolo de comunicaciones de datos usado entre un origen y un destino, se usa en la
actualidad en Internet, y por lo general se asigna una dirección IP para identificar a un dispositivo en Internet.
3 TCP (Transmission, Control Protocol), por sus siglas en inglés, es un protocolo fundamental para Internet, se utiliza para establecer conexiones
entre dos puntos. El protocolo garantiza que los datos serán entregados en su destino sin errores y en el mismo orden en que se transmitieron.
TCP da soporte a muchas de las aplicaciones más populares de Internet (navegadores, intercambio de ficheros, correo electrónico)
37. 36
| Casos de estudio |
2. Requerimientos y alineación de la alta dirección
Molina se reunió con Antonio Bermúdez para aclarar los requerimientos del nuevo modelo. La sesión fue
corta, pero Bermúdez fue directo:
“Molina, los tiempos de respuesta para diseñar y entregar propuestas son muy extensos, los ingenieros continúan
diseñando servicios a la medida, prácticamente son artesanales. ¿Por qué no replicar un servicio exitoso en otros
clientes similares? ¿Qué pasa con la estandarización y la interoperabilidad? Requerimos de modernización tecno-
lógica en los equipos de procesamiento de datos. Debemos aprovechar los tres últimos años de experiencia en la im-
plementación y aplicación de las mejores practicas de ITIL. Necesitamos responder a la demanda con soluciones
flexibles. Tienes que integrar al modelo una forma diferente de diseñar y construir los proyectos, quiero que revises
la filosofía de los “servicios en la nube” y su impacto para mejorar nuestras soluciones. No hagamos servicios a la
medida, define una tecnología que sea replicable en nuestros servicios, pero sobre todo orientación a satisfacción
del cliente cumpliendo los acuerdos de niveles de servicio”.
Molina reflexionó sobre los comentarios de Bermúdez y entendió que era momento de definir un mo-
delo que integrara lo mejor de la experiencia de Funtech, las nuevas tecnologías y sobre todo, dar respuesta
a la exigencia de los clientes en los servicios que demandaban. Aunque el desarrollo de modelos de servicio
era común en las actividades de la empresa, el modelo solicitado por Bermúdez, tenía el reto en el conte-
nido, cada elemento de éste debía ser analizado y validado para su relación con el resto.
3. Integración del equipo de trabajo
Molina tenía por delante el reto de plantear el nuevo modelo solicitado por Bermúdez, sin embargo no
era momento de incorporar técnicos relacionados con la operación quienes si bien tenían experiencia, no
contaban con el tiempo necesario para unir las ideas, analizarlas y desarrollar su relación con el entorno
de Funtech. Molina integró su equipo de trabajo con las siguientes personas: Beatriz Lara, especialista en
procesamiento y virtualización, Roberto Rosas, especialista en administración de servicios de TI y virtualiza-
ción, Edmundo Baca, especialista en aplicaciones y en bases de datos y finalmente, Carlos Sosa, especialista
en almacenamiento y soluciones de respaldo.
Los cuatro integrantes del equipo no tenían la función de atender clientes con servicios operacionales
ni de solucionar requerimientos a cualquier hora del día para responder a incidentes. El equipo de trabajo
era diverso pero sabían que los habían elegido para analizar y proponer soluciones.
Se realizaron múltiples reuniones entre Molina y su equipo de especialistas, en las cuales se pretendía
entender la estructura del nuevo modelo de servicio, con el fin de aterrizar los requerimientos y compo-
nentes base que se necesitarían para conformar el nuevo modelo de servicio.
El equipo de trabajo requería construir soluciones tecnológicas flexibles, bajo demanda y eficientes,
para poder responder a los niveles de servicio de los clientes nuevos y actuales.
4. Análisis de elementos
El equipo de trabajo entró en la fase de análisis de los elementos para decidir cuáles formarían parte del
modelo solicitado por Bermúdez. Molina les pidió que fueran críticos, que debatieran las ideas, pero, so-
bre todo, que se concentraran en las necesidades del cliente. Molina solicitó que liberaran las ideas y que
basaran sus comentarios en hechos reales que habían sucedido en Funtech y las lecciones aprendidas de los
proyectos realizados. Los elementos que se valoraron fueron los siguientes:
39. 38
| Casos de estudio |
La administración de sistemas operativos se había incrementado en los últimos cinco años y la fortaleza en
administración de sistemas con Linux Redhat7
y Suse8
había crecido porque todos los periféricos y componentes
eran soportados por esas versiones. Beatriz le comentó a Molina que Funtech había perdido varios especia-
listas con experiencia en UNIX en los últimos 12 meses por lo que los sistemas basados en Linux eran una
mejor opción.
d) El Impacto de ITIL
Funtech había implantado ITIL9
versión 2 desde hacía cinco años, sin embargo tres años atrás ITIL fue
actualizado a la versión 3. Molina planteó al equipo agregar sólo los procesos más importantes. Para ese
momento Beatriz, Edmundo y Roberto habían obtenido la certificación de ITIL versión 3 y su propuesta
era incluir todos los procesos.
La versión 3 de ITIL con un enfoque en la mejora continua de los servicios, basado en el ciclo de vida de
la gestión de los servicios, tenía una orientación hacia el cliente y con descripción de niveles de servicio. La
nueva versión implicaba tener 20 procesos adicionales a los 10 que se tenían en la versión 2.
Molina le comentó al equipo de trabajo la explicación de lo que era un acuerdo de niveles de servicio
para ITIL.
“Un acuerdo de nivel de servicio o service level agreement, también conocido por las siglas ANS o SLA, es un
contrato escrito entre un proveedor de servicio y su cliente con objeto de fijar el nivel acordado para la calidad
de dicho servicio. El ANS es una herramienta que ayuda a ambas partes a llegar a un consenso en términos del
nivel de calidad del servicio, en aspectos tales como tiempo de respuesta, disponibilidad horaria, documentación
disponible, personal asignado al servicio, etc.”, Molina enfatizó que este era el principal objetivo del modelo, “Unir
todos los elementos de manera armónica para poder cumplir un acuerdo de niveles de servicio”
Molina les recordó la ultima frase de Bermúdez en la solicitud:
“Orientación a satisfacción del cliente cumpliendo los acuerdos de niveles de servicio”. Roberto dijo “ahora entien-
do, esto es la práctica de nuestro curso” y puntualizo un ANS identifica y define las necesidades del cliente a la vez
que controla sus expectativas de servicio en relación a la capacidad del proveedor, proporciona un marco de en-
tendimiento, simplifica asuntos complicados, reduce las áreas de conflicto y favorece el diálogo ante la disputa”.
Beatriz tomó el libro del curso de ITIL version3 y comentó “un servicio es una solución, no necesariamente
material, a un problema o una necesidad. Un servicio aporta valor. Un servicio de TI es una solución tecnológica a
una necesidad de negocio”. Molina finalizó la sesión de análisis diciendo “el nuevo Modelo debe tener implícito el
cumplimiento de niveles de servicio y de manera explicita deberá medir cada elemento tecnológico”.
e) Tercerización de la administración (Outsourcing)
La discusión sobre outsourcing para la administración en el modelo fue interesante, Molina proponía que
el nuevo modelo de servicio fuera administrado totalmente por personal de Funtech por lo que comentó:
“Los clientes tienen la confianza en el personal de Funtech”, “la especialización y crecimiento profesional del personal es
una constante”. Carlos y Beatriz estaban definiendo las características del servicio de administración. Molina
agregó que el personal de Funtech se desarrollaba continuamente con laboratorios y material de estudio en
Internet. Sin embargo Carlos y Beatriz exponían las razones de fortalecer las capacidades de Funtech me-
diante el outsourcing, “los servicios administrados permitirían dedicar los esfuerzos de Funtech en temas estratégicos y
sustantivos, documentando las experiencias buenas y malas”.
7 REDHAT Distribución de Linux creada y mantenida por RedHat inc. Red Hat Enterprise Linux
8 SUSE, Distribución de Linux mantenida por Novell.
9 ITIL, Information Technology Infrastructure Library, conjunto de conceptos y mejores practicas para la administración de servicios de tecnologías
de la información.
40. 39
[ El camino de los servicios en la nube ]
Carlos mencionó que en 2011 existió un problema con el correo electrónico por la renuncia de personal
clave, el problema se complicó en mas de 10 horas, en ese momento no teníamos al personal especializa-
do. Beatriz añadió que la solución era sencilla, pero sólo un técnico especializado en el software de correo
electrónico sabría el comando correcto y la configuración especifica. Con este ejemplo, Carlos y Beatriz
querían dejar claro que desde su perspectiva, Funtech no debería profundizar en los temas técnicos, las
tecnologías estaban evolucionando muy rápido y la capacitación de tipo técnico era muy cara. Carlos cerró
su participación diciendo “la opción es outsourcing”. Molina opinó: “Si seguimos tu propuesta Carlos, me parece que
Funtech perderá el control de los servicios y el conocimiento del negocio de nuestros clientes”.
5. Seleccionar, unir y relacionar
Después de haber identificado las posibles opciones a incluir en el modelo, Molina y su equipo de trabajo
tendrían que decidir específicamente qué elementos formarían parte de la solución. Molina les dijo a los
miembros de su equipo: “hemos discutido diferentes aspectos acerca de los posibles elementos que podrían formar parte
del modelo solicitado por Antonio Bermúdez y aunque tenemos opiniones diferentes, ha llegado el momento de ponernos
de acuerdo para decidir con qué elementos nos conviene integrar el modelo tecnológico”.
41.
42. 41
Caso 4:
Me hackearon, ahora ¿qué hago?
Héctor Carrales y Xóchitl Marcial se encontraban reunidos en la sala de juntas del Centro de Transparen-
cia (CT), discutiendo, cómo deberían enfrentar la situación de una posible intromisión a la base de datos
de más de 35 millones de usuarios que estaba bajo la administración del área que Héctor dirigía. Héctor
enfatizaba:
“Xóchitl, nuestro director nos ha citado con carácter urgente, ya que está enterado de la posibilidad de un acceso
a la base de datos que está bajo nuestra custodia y dado que sabemos que es nuestra responsabilidad y reconocien-
do que hemos cometido algunos errores en aspectos de seguridad de la información, es necesario que enfrentemos
esta situación y con un sentido propositivo. Te pido que hagamos un planteamiento que garantice que este tipo de
situaciones no se repetirán en el futuro, tenemos dos horas para darle forma al plan y se que cuento con tu apoyo
incondicional, así que, manos a la obra”.
Estudio de caso desarrollado por el Lic. Eduardo Zepeda Estrada Inspector Retirado de la Policía Cibernética – Policía Federal, para fines didácti-
cos y de aprendizaje exclusivamente. No debe ser considerado como referencia de gestión adecuada o inadecuada de una situación determinada.
(Los personajes y hechos han sido modificados y adaptados de su versión original para proteger la confidencialidad)
Fecha de elaboración: 22-03-12
