análisis del impacto organizacional en el desarrollo de un
TRANSCRIPT
UNIVERSIDAD VIRTUAL
Escuela de Graduados en Educación
Análisis del impacto organizacional en el desarrollo de un
sistema integral de información y procesos
TESIS
Que para obtener el grado de:
Maestro en Ciencias de la Información y Administración del Conocimiento
Presenta:
Rodrigo Abb Romo Lorenzo
Asesor:
Maestra Patricia Carranza Garza
Ciudad de México, D.F., México Mayo, 2008
Para Ana Laura y Sofía, quienes me
ayudaron con paciencia infinita a
terminar con la tarea de Sísifo.
Análisis del impacto organizacional en el desarrollo de un
sistema integral de información y procesos
Resumen
El desarrollo de sistemas de información implica distintos costos para la organización que los emprende. Estos costos pueden ser suficientes para hacer fracasar un proyecto determinado si alcanzan cierto límite. Una corriente en ascenso en la literatura sobre estos desarrollos apunta a la necesidad de atender los aspectos sociales y organiza-cionales tanto o más que los técnicos propiamente dichos para explicar las causas de estos fracasos. El caso del Sistema Integral de Información y Procesos de la Procuraduría Federal del Consumidor es un ejemplo que se ubica en los extremos de un modelo de explicación que tiene en cuenta los aspectos mencionados en la forma de una caracterización del impacto organizacional. El lugar inusual del Sistema en el modelo se debe a la magnitud de sus costos organizacionales y el éxito moderado que ha obtenido a pesar de ellos. El análisis de este caso pone de relieve la incorporación de nuevas variables, como la sensibilidad al impacto organizacional, para mejorar la capacidad del modelo. De esta manera, es posible explicar la ubicación poco común del desarrollo de ese Sistema dentro de los parámetros contemplados.
ÍNDICE
Antecedentes 1
Antecedentes de la investigación 1 Preguntas de investigación 10 Objetivos de la investigación 11 Justificación de la investigación 11 Limitaciones de la investigación 14 Organización del trabajo de investigación 15
Marco teórico 16
Fuentes y definiciones 16 El desarrollo de sistemas y su impacto organizacional 23
Metodología 39
Modelo del caso de estudio 39 Disponibilidad de información 43 ¿Cómo se desarrolló el SIIP? 47
Análisis de los datos 58
Caracterización del impacto organizacional en PROFECO 58 Nuevas variables para explicar el caso del SIIP 74
Conclusiones 85
A) Hallazgos principales 85 B) Futuras investigaciones 89
Referencias 91
Apéndices 95
LISTA DE FIGURAS
Figura 1: Modelo del Ciclo de Desarrollo de Sistemas, conforme el estándar del IEEE. 19 Figura 2: Caracterización del impacto organizacional del desarrollo de un sistema 36 Figura 3. Esquema del caso de estudio conforme al modelo de la Harvard Business School. 40 Figura 4. Esquema del caso de estudio. Adaptación del modelo de la Harvard Business School al caso del
desarrollo del SIIP. 42 Figura 5: Calendario original propuesto para el desarrollo del SIIP. 48 Figura 6: Esquema conceptual del funcionamiento del SIIP 50 Figura 7: Calendario final del desarrollo del SIIP 56 Figura 8: Comparación de los elementos de un desarrollo exitoso y el caso del SIIP 59 Figura 9: Relación entre impacto organizacional y éxito de un proyecto de desarrollo de sistemas 76 Figura 10: Ubicación del caso del SIIP en la relación impacto organizacional vs éxito del proyecto 77 Figura 11: Introducción de la apreciación del impacto organizacional 78 Figura 12: Cambios en la inclinación del eje de apreciación 79 Figura 13: Ubicación del caso del SIIP con el cambio en la inclinación del eje de apreciación del impacto 80 Figura 14. Movimiento de la curva de relación impacto vs éxito debido al efecto de la sensibilidad al
impacto 82 Figura 15. Incorporación de todas las variables y la ubicación del caso del SIIP en el modelo 83 Figura 16: Síntesis de la comparación de los elementos de un desarrollo exitoso y el caso del SIIP 85
APÉNDICES
Apéndice A 95 Apéndice B 114 Apéndice C 128
CAPÍTULO 1
ANTECEDENTES
Antecedentes de la investigación
La Procuraduría Federal del Consumidor (PROFECO) surgió en los años setenta
como una atención del gobierno federal al sector sindical para defender a los
trabajadores en sus relaciones comerciales con los proveedores. Este origen le imprimió
a las acciones de PROFECO un carácter profundamente paternalista y tutelar, porque se
concebía al consumidor como un ente débil y desamparado al cual el Estado debía cubrir
con su manto protector, especialmente en el entorno de una economía cerrada como la
de entonces.
Este arreglo institucional funcionó con sus altibajos durante veinte años
aproximadamente. Sin embargo, la PROFECO se convirtió rápidamente en el
patrimonio de grupos políticos que la utilizaron como plataforma de avance personal
hacia nuevos puestos en el gobierno federal. La cercanía de la PROFECO con la gente
común y corriente, en cuyo perfil socioeconómico se podía encontrar un terreno fértil
para el clientelismo más simple –como por ejemplo, solución de quejas a cambio de
lealtades políticas-- hizo muy atractiva esta organización para propósitos múltiples,
excepto el propio desarrollo de PROFECO.
2
Inmediatamente después del cambio del Partido Revolucionario Institucional por
el Partido Acción Nacional en diciembre de 2000, los nuevos titulares de las
instituciones de gobierno en México comenzaron la tarea de averiguar cómo funcionaba
el aparato burocrático del país, cómo estaba organizado, quiénes lo formaban y qué
redes de intereses había. PROFECO no fue ninguna excepción.
En poco tiempo, fue posible saber que en PROFECO había una pequeña multitud
de redes de interés formada por los grupos de individuos que cada Procurador anterior
había dejado en la institución durante sus gestiones respectivas. Estos individuos
mantenían vínculos con el pasado y balanceaban sus lealtades con el régimen en curso,
no siempre a favor de este último.
Desarticular esa red de intereses no fue fácil ni estuvo completa sino hasta los
cambios de delegados de la administración actual, la gran mayoría de los cuales ocurrió
en 2007. En cualquier caso, fue hasta la conclusión de las negociaciones de las reformas
a la LFPC en 2004 que la influencia de estos grupos se relajó lo suficiente para permitir
el avance en la modernización de PROFECO, limitada a partir de entonces por las
propias torpezas de la institución.
El modelo de gestión pública en PROFECO pertenecía al pasado que la vio surgir.
Se trataba de un cuerpo público sin una cultura de “rendición de cuentas”, entrega de
resultados o mediciones adecuadas. La inercia de cumplir con ciertas tareas de manera
cotidiana se escuda detrás del mito de la bondad de la institución, apenas detrás de los
bomberos y la Cruz Roja en la opinión pública. La PROFECO tiene una opinión
3
favorable entre los ciudadanos y permite el desahogo de muchas pequeñas frustraciones
relacionadas con el consumo. Pero la incidencia en el mercado y en las prácticas de
comercialización es todavía pequeña. El Informe de Labores 2001 (PROFECO, 2002), el
primero elaborado en PROFECO con la intención de reportar realmente los números de
la gestión, señala que apenas 8% de los individuos que tienen un problema en su
relación con los proveedores va a PROFECO para recibir ayuda. El resto de los
consumidores se arregla como puede o se resigna a limitar sus pérdidas.
A finales de los años noventa y principios del Siglo XXI, PROFECO era una
institución atrasada, tanto en lo tecnológico como en su marco normativo. PROFECO
era una institución de papel y el sonido de las máquinas de escribir era el dominante en
las oficinas. Entonces no se había escuchado hablar de organización de información ni
mucho menos de sistemas. En PROFECO se podía observar la obsolescencia de sus
procesos y servicios, además de estar abrumada por una multitud de inercias
institucionales.
El Libro Blanco (PROFECO, 2006), que es el documento oficial que recopila los
aspectos más relevantes sobre el desarrollo del SIIP, hace un recuento del estado que
guardaban las cosas al principio del sexenio. El Libro Blanco menciona la situación
informática previa a la concepción del SIIP y señala la limitación informática que
explicaba el rezago tecnológico de la PROFECO. Entre los puntos más importantes de
este rezago está el 82% de obsolescencia del inventario de equipo de cómputo, el cual,
además, era muy escaso. Apenas unas 400 computadoras para 4000 elementos de
4
personal, aproximadamente.
El Libro Blanco (PROFECO, 2006) también menciona un inventario de los
sistemas que estaban en funcionamiento antes del SIIP. Estos sistemas eran registros
limitados que no se llamaban hojas de cálculo porque el simple hecho de no estar
elaborados en paqueterías como Excel, sino en bases de datos primitivas y muy mal
aprovechadas, de acuerdo con Galván (N. Galván, Comunicación personal, 23 de
noviembre de 2006). Además, que estos sistemas se utilizaban de manera optativa lo que
significa, en realidad, que el uso de la herramienta era esporádico y que no estaban
conectados entre sí, lo que impedía severamente su efectividad. La ausencia de
supervisiones reales a los procesos tiene, todavía, inmerso al sector gubernamental en el
mundo de las "acciones" en vez de la evaluación de "resultados", como correspondería a
una institución menos rezagada.
No había una red interna, ni tampoco servidores poderosos. Las delegaciones de
PROFECO, eran oficinas alejadas de lo que ocurría en las oficinas centrales. La
comunicación ocurría con singular torpeza y los costos de telefonía de larga distancia
eran muy altos.
Como antecedentes administrativos, en PROFECO no había administradores de
proyectos profesionales, por lo que el proyecto de desarrollo más grande en la historia de
la institución se manejó con un gran componente de improvisación y aprendizaje a lo
largo del desarrollo.
El presupuesto de la PROFECO no era tampoco un asunto menor. La PROFECO
5
se había manejado hasta entonces con un presupuesto de escasos 600 millones de pesos.
La titular de la Procuraduría fue capaz de negociar el aumento hasta los 800 millones,
sin contar el dinero adicional que recibió para cubrir parte de las cuentas del SIIP, que
contó con el apoyo de los Secretarios de Economía que se sucedieron durante el periodo
del desarrollo.
Tal vez el factor más importante del cambio de administración en 2000-2001 fue
que los nuevos funcionarios no pertenecían a los grupos cuyos intereses estaban
profundamente enraizados en la institución y que sus lealtades ya no se manifestaban del
modo acostumbrado en los últimos veinte años. Este cambio de responsables permitió
hacer dos cosas, básicamente: desanudar la red de intereses y cambiar al personal atado
al pasado; y, en segundo lugar, avanzar con más o menos acierto hacia una
modernización tecnológica y normativa integral en la institución.
La identificación de estas necesidades coincidió con la adopción de un enfoque
diferente al tradicional de la política de protección al consumidor. PROFECO se
concibió a si misma como la institución encargada de corregir las fallas del mercado que
llevan a los consumidores a ubicarse en un lugar desventajoso en sus relaciones de
consumo debido a las asimetrías de información que tiene frente a un proveedor. Dicho
de otra manera, la PROFECO intentaría equilibrar la poca información que posee el
consumidor respecto de la que tiene en abundancia un proveedor, con el fin de mejorar
la posición del primero en su relación de consumo con el segundo.
Lo anterior significó adoptar un enfoque preventivo de la protección al
6
consumidor, algo inusual para gobierno federal, acostumbrado a reaccionar antes que
adelantarse a los acontecimientos. Sin embargo, por las mismas disposiciones de Ley y
posicionamiento institucional en el conocimiento del público, PROFECO sigue llevando
a cabo sus tareas de autoridad cuando arbitra las inconformidades de un consumidor que
se queja en contra de un proveedor, adoptando un enfoque coercitivo de la misma
política pública.
Con este cambio en la concepción de la PROFECO, para sus mandos superiores
fue patente la necesidad de seguir una estrategia doble para sacar a la institución del
anquilosamiento y proyectarla, si no al Siglo XXI, por lo menos a la era electrónica. Era
urgente modernizarla en lo tecnológico y actualizar su marco normativo para subsanar
los grandes huecos que había en la Ley Federal de Protección al Consumidor (LFPC). La
segunda tarea se llevó a cabo a partir de 2002 y culminó el 16 de diciembre de 2003
cuando, después de un proceso exitoso de cabildeo, se aprobaron las reformas a más del
75% del texto de la LFPC.
La tarea de modernizar tecnológicamente a PROFECO, por su parte, era un reto
muy grande. Se comenzó con introducir las computadoras en la institución y la cuestión
del Sistema Integral de Información y Procesos (SIIP) apareció al mismo tiempo que la
compra de equipo de cómputo. El SIIP es nada menos que una plataforma informática
que integra todos los procesos sustantivos de la institución bajo un mismo esquema, con
la intención de agilizar la respuesta en la atención al público y mejorar
considerablemente el conocimiento que la institución obtiene de sus propias acciones.
7
Este sistema integral contempla módulos de explotación de información y organización
de archivos, con el fin de sustentar y documentar adecuadamente la actuación de la
autoridad.
Desde el punto de vista organizacional, el SIIP llevaría a PROFECO a ser una
institución moderna. Personal que nunca había usado una computadora trabajaría dentro
de un sistema. Mandos que realizaban, cuando mucho, informes con estadística básica se
concentrarían en realizar minería de datos y explotación de información. Las
delegaciones de PROFECO en la República estarían conectadas al sistema central y
realizarían sus trabajos en línea. Buena parte de la consulta interna de información
cotidiana se llevaría a cabo en la página de Intranet de la institución y se construiría la
infraestructura necesaria para soportar todo lo anterior.
Para PROFECO, pasar de la idea a la ejecución probó ser algo muy complicado.
No hubo obstáculo en el que no se cayera. Las resistencias al cambio fueron patentes
desde el primer minuto del proyecto; la cuestión de infraestructura todavía afecta a
muchas delegaciones y el uso de la información del SIIP todavía no es una realidad
manifiesta. De llevar un proceso en papel tuvieron que pasar a definir requerimientos
con ingenieros que frecuentemente dan por sentado que los usuarios hablan y dominan la
jerga informática. Hubo grandes lagunas de comunicación durante la etapa de diseño, lo
que cobró su factura al momento de estabilizar el desarrollo. Además, si el problema era
fuerte en oficinas centrales, en las delegaciones cada detalle se amplificaba varias veces.
Las oficinas regionales de PROFECO todavía están mucho más limitadas que sus
8
contrapartes en la Ciudad de México y para ellas fue todavía más difícil, especialmente
porque no pudieron participar en las etapas previas. La definición de todo siempre se
hizo del centro. La consecuencia fue un plazo extendido, tal vez demasiado, de la etapa
de mantenimiento del sistema. Pero el proyecto avanzó a pesar de todo ello. El apoyo de
la Secretaría de Economía, primero, y de la Secretaría de Hacienda, después,
permitieron cubrir aceptablemente los costos adicionales que encarecieron el proyecto,
no sin pasar por negociaciones complicadas con la firma desarrolladora del sistema.
De acuerdo con el Libro Blanco, la PROFECO comenzó en 2001 un proceso
acelerado de adquisición de equipo de cómputo e infraestructura tecnológica para estar
en condiciones de emprender el desarrollo del SIIP. Con esos esfuerzos se logró
disminuir el nivel de obsolescencia del equipo a 21% con la incorporación de 925
computadoras, 10 servidores de red y 226 impresoras a los inventarios de la institución.
También se adquirió un conmutador y comenzó el análisis de los sistemas vigentes y
cómo homologar su información con miras al desarrollo del SIIP. Durante 2002 se
adquirieron los servidores de alto desempeño para albergar el SIIP y más equipos
individuales para continuar con la modernización de las computadoras existentes. Con la
instalación de toda esta infraestructura se abrió la puerta para la licitación del desarrollo
del SIIP.
Actualmente, en PROFECO se organiza la información conforme a un mismo
esquema, sin que importe su imperfección. Se trata de una manera homogénea de
organizar archivos, introducir datos. Se utilizan las mismas herramientas para hacer el
9
análisis de los procesos y las estadísticas ya no se elaboran para el solaz de funcionarios
particulares. El cambio en la cultura laboral ha echado raíces después de cuatro años de
trabajo intenso.
Por primera vez, la información se está convirtiendo en un activo valioso para
PROFECO. Más allá de los discursos oficiales y de los informes periódicos, los mandos
superiores comienzan a administrar sus procesos con información dura en la mano, en
vez de utilizar opiniones con sustento exclusivo en la experiencia y en la capacidad de
observación. Los indicadores que siempre habían existido en los informes de labores
ahora surgen directamente de la información que se genera en los procesos, en vez de la
imaginación de los funcionarios. PROFECO tiene la oportunidad de convertirse, en un
futuro cercano, en una organización capaz de aprender rápidamente de sus acciones y
ajustar sus actividades para mejorar los servicios que proporciona. Por lo menos ha
hecho un esfuerzo considerable para establecer las bases sobre las cuales podrá avanzar
hacia etapas más sofisticadas en la administración de su información.
Este esfuerzo de desarrollar el SIIP implicó presiones considerables en toda la
estructura de PROFECO. Comprender el entorno organizacional es extremadamente
importante para entender lo que ocurrió con el SIIP. Quién tomó las decisiones y por
qué, con base en qué información, es la tarea más compleja. En gobierno no hay todavía
la costumbre de documentar adecuadamente las decisiones y éstas suelen seguir más una
lógica individual que un proceso de toma de decisión clásico, como lo establecería algún
modelo específico. La camaradería, el favoritismo y, en general, las prácticas
10
deformativas de la administración pública, toman aquí su mayor relevancia. De allí la
importancia de entender qué oficina hizo qué y cuándo; quién dirigía qué parte del
proyecto y qué rumbo siguieron sus acciones.
De allí surge la necesidad de documentar la información más básica sobre el
desarrollo de este sistema de información y de analizar el impacto que tuvo en la
PROFECO.
Preguntas de investigación
Las preguntas para el caso de estudio de Profeco son las siguientes:
• ¿El desarrollo del SIIP tuvo un impacto organizacional en PROFECO?
• ¿En qué consistió ese impacto y cómo se caracteriza?
• ¿Qué diferencias hay entre el modelo de impacto organizacional y este caso
de estudio?
• ¿Qué experiencias arroja este caso de estudio?
11
Objetivos de la investigación
Una vez enunciado lo anterior, es necesario dejar en claro cuál es la pretensión de
este trabajo de investigación.
1.- Recopilar los detalles sobre el desarrollo del SIIP.
2.- Señalar las observaciones más relevantes.
3.- Comparar estos fenómenos contra un modelo que establece relaciones entre el
impacto organizacional y el éxito de un desarrollo de sistemas.
4.- Ampliar la explicación original del modelo al establecer nuevas hipótesis
5.- Ofrecer un nuevo modelo de explicación.
6.- Sugerir la evaluación del nuevo modelo, así como recomendar la investigación de
otros casos de estudio que confirmen la validez de las nuevas hipótesis o las refuten.
Justificación de la investigación
La literatura sobre sistemas de información es muy abundante y detallada en lo que
se refiere a iniciativa privada e industria. En el sector gubernamental, por el contrario,
hay pocos textos que hayan analizado lo que ocurre y las transformaciones que las
instituciones federales, por lo menos, están experimentando en los últimos años. Para el
12
caso de PROFECO, la situación todavía es más especial, porque el desarrollo de su
sistema de información comenzó como el primero en su tipo en América Latina, de
acuerdo con la propia empresa Oracle (“Crea Profeco”, 2006). Cabe aclarar que no se
trata de decir que no había sistemas en América Latina, sino un desarrollo integral de las
características del SIIP.
En el sector gubernamental habrá cada vez más desarrollos de sistemas y, donde
ya los hay, se tenderá hacia la integración. La experiencia de PROFECO puede ser
sumamente importante para otras organizaciones que estén analizando los pasos a seguir
para modernizarse.
El caso de estudio es atractivo por varias razones. La primera de ellas, porque se
trata de una inversión sin antecedentes en la historia de una institución relevante en el
sector económico del gobierno. Otra razón es que PROFECO es un ejemplo de lo que
ocurre cuando se transita de una institución atrasada, con poca infraestructura
tecnológica y con un personal poco preparado, en una organización radicalmente
distinta. Una razón más es que un proyecto de esa magnitud y naturaleza era
prácticamente desconocido en gobierno federal. Adicionalmente, el desarrollo del SIIP
implica una conceptualización completamente distinta de la información que genera una
institución gubernamental. Más allá de una modernización informática ambiciosa, el
SIIP tiene como uno de sus objetivos cambiar por completo la manera como la
institución lleva a cabo sus procesos y utiliza su información. Las herramientas de
explotación de información revolucionarán la tarea de análisis que, hasta la fecha, se
13
realiza de manera rudimentaria o improvisada.
Ahora bien, en la literatura sobre sistemas de información se pasa fácilmente por
alto que en México hay muchos sectores que no cumplen siquiera con el mínimo que
esta literatura considera como requisitos básicos. Esto se debe a que en su mayoría
proviene de países industrializados, en los que la interacción de sistemas, la
codificación, resguardo y aprovechamiento de la información se remonta incluso hasta el
siglo antepasado (como un ejemplo significativo, el New York Times ya ofrece la
consulta electrónica de todos los artículos que ha publicado desde 1851).
En este sentido, es posible entrever, en un escenario no muy lejano, que el
gobierno en este país se va a convertir en el proveedor confiable de información útil y
actualizada. Mientras más desarrollos de sistemas haya en gobierno, se podrán llenar
más fácilmente los huecos de información que median entre censos, del mismo modo
como se impulsará una cultura de información que actualmente no existe. Tanto la Ley
Federal de Transparencia como la creación de archivos y el desarrollo de sistemas serán
el fundamento de muchas investigaciones futuras.
De manera adicional, un proyecto de esta naturaleza también puede dar una buena
idea sobre lo lejano o cercano que está gobierno federal de lo que establecen los modelos
modernos de administración de conocimiento. Y no es una explicación trivial, porque la
modernización tecnológica en el gobierno federal es un asunto muy reciente. Todavía no
se olvidan los días en los que todo se realizaba con máquinas de escribir. Para
PROFECO, notablemente, ese momento es tan cercano como 2002, cuando las
14
computadoras se extendieron a todo el personal y no sólo a unos cuantos funcionarios.
Todo ello hace del estudio de este caso un retrato muy real y humano sobre el reto de
trasladar una institución desde el atraso a una plataforma de punta, especialmente
cuando no se aplican de manera generalizada las metodologías que la iniciativa privada
tiene por costumbre llevar a cabo en su búsqueda de innovación y mejores ganancias.
Limitaciones de la investigación
Los esfuerzos de más de dos mil personas a lo largo de cuatro años son
demasiados como para registrarlos en todo detalle. No hay memorias institucionales que
hayan compilado la historia del desarrollo del SIIP. Los expedientes que están bajo la
custodia de la Dirección General de Informática de PROFECO se refieren al registro de
los entregables del proyecto y no hay documentos de análisis sobre las implicaciones
organizacionales del desarrollo del SIIP. En consecuencia, este caso de estudio depende
de los testimonios de personas clave, así como los del propio autor, en virtud de su
posición como observador de todo el proceso de desarrollo y participante directo en el
desarrollo de varias de las etapas y módulos del SIIP. Este aspecto testimonial es
importante porque se trata de consignar en un registro información que de otro modo no
habría modo de recuperar. Además, se trata de aprovechar un momento en el que la
propia institución está haciendo un ejercicio de memoria con motivo del cambio de
administración para hacer un estudio sobre uno de los primeros casos de desarrollo de
15
sistemas integrales en el gobierno federal.
Este caso de estudio tampoco se concentró en hacer una auditoría de procesos ni
una evaluación sobre lo que es capaz de hacer el SIIP. Únicamente analizará el impacto
organizacional que tuvo el desarrollo del SIIIP para las oficinas que forman la
PROFECO.
Organización del trabajo de investigación
La información que está en los archivos de PROFECO únicamente cubre los
aspectos contractuales del proyecto. Por ley, esta información debe estar disponible para
cualquier persona que desee consultarla. Adicionalmente, la PROFECO elaboró un
Libro Blanco con miras a la entrega-recepción de la administración entrante. Este
documento sintetiza lo que se encuentra en los archivos de diversas unidades
administrativas.
Sin embargo, no toda la información se encuentra en documentos. Un desarrollo
así habría sido muy deseable, pero muchas reuniones y decisiones no están asentadas en
ningún registro. Por lo tanto, fue de gran importancia entrevistar a las personas que
fueron críticas en los procesos y obtener de ellas su testimonio sobre el desarrollo del
Sistema que de otra manera no podrían obtenerse, a pesar de que no hay manera de
contrastar sus opiniones con evidencia de otras fuentes.
16
CAPÍTULO 2
MARCO TEÓRICO
Fuentes y definiciones
Es oportuno mencionar algunos aspectos relacionados con la bibliografía
consultada para analizar este caso de estudio.
Encontrar información sobre el mundo de las computadoras y los sistemas de
información no es difícil. Con frecuencia en los tiempos de Internet, es más fácil
perderse en el océano de información que discriminar fuentes útiles de las que no lo son
tanto. Los diccionarios dedicados a la terminología de computadoras y sistemas son
abundantes y de fácil acceso, aunque a veces sus ediciones son costosas y no siempre
están disponibles en los centros de estudio para su consulta o al alcance del presupuesto
de los alumnos que quisieran tener una consulta más extensa en sus domicilios
particulares. Como ejemplo se pueden mencionar el Standard Glossary of Software
Engineering Terminology (IEEE, 1990); la. Guía de los Fundamentos de la Dirección
de Proyectos (Project Management Institute, 2004) y los distintos títulos de la Blackwell
Encyclopedic, como el de Davis, G. B. (1999).
Los artículos y libros que los especialistas publican sobre los temas relacionados
con los sistemas de información son una fuente más que abundante para cubrir todos los
17
aspectos del contenido de una investigación como ésta. Buena parte de esos textos
proporcionan puntos de vista frescos sobre definiciones generales y profundizan en los
detalles que una obra de referencia global no puede alcanzar. En el caso específico de
este trabajo, sobresalen los artículos de Avison y Powell (2001) y Keen (1981), así como
los de Gurbaxani y Whang (1998) y Mahmood y Becker (1985), por mencionar unos
cuantos ejemplos.
Con todas estas referencias es posible crear un mínimo glosario de definiciones
que permita entender los términos bajo los cuales se revisó el caso de estudio.
El mejor punto de partida es empezar por la definición misma de sistema. De
acuerdo con el IEEE (1990), se entiende por sistema una colección de componentes
organizados para cumplir con una función específica o un conjunto de funciones. Un
paso más adelante de esta definición tan amplia es la de un sistema de información que,
según Senn (2005) es el medio por el cual los datos fluyen de una persona o
departamento hacia otros y puede ser cualquier cosa, desde la comunicación interna
entre los diferentes componentes de la organización y líneas telefónicas, hasta sistemas
de cómputo que generan reportes periódicos para varios usuarios. Los sistemas de
información proporcionan servicio a todos los demás sistemas de una organización y
enlazan todos sus componentes en forma tal que éstos trabajen con eficiencia para
alcanzar el mismo objetivo.
Más allá de las concepciones genéricas o teóricas sobre sistemas, un aspecto que
será extremadamente importante a lo largo de este trabajo sobre el SIIP es el Ciclo de
18
desarrollo de sistemas. De nueva cuenta, el IEEE (1990) señala que el ciclo de desarrollo
de software es el periodo de tiempo que comienza con la decisión de desarrollar un
producto de software y termina cuando el software es entregado. El ciclo incluye
típicamente las etapas de requerimientos, diseño, instrumentación, pruebas y, cuando es
necesario, instalación y chequeo final.
De esta definición se desprenden las que corresponden a cada fase o etapa.
1.- Definición de requerimientos, en la que el usuario --de manera genérica, no
individual-- pone en blanco y negro lo que desea que el software haga.
2.- Diseño, que es la etapa cuando el ingeniero en software determina la
arquitectura del producto, sus componentes, interfaces y cómo va a funcionar.
3.- Implantación, en la que se integran todos los elementos anteriores y se eliminan
los errores para dejar funcionando el producto.
4.- Prueba, que es la etapa en la que se pone a funcionar el producto con usuarios
reales para evaluar el desempeño real de la aplicación. En esta etapa se encuentran las
conocidas pruebas alfa y pruebas beta, para revisar los últimos detalles del programa
antes de su liberación.
5.- Instalación y revisión final o checkout, en la que se revisa una vez más que el
producto funciona satisfactoriamente para los usuarios.
19
Algunas etapas de este ciclo pueden repetirse o traslaparse en determinado
momento. Asimismo, hay distintos estilo de programación para llevar a cabo este
proceso y corresponden a la metodología y estrategia del desarrollador. Hay grandes
discusiones en la literatura de este género respecto a determinar qué estilo o modelo es
más eficiente y preciso. Pero los detalles de este aspecto corresponden propiamente
dicho a la política de calidad del desarrollador y, momentáneamente, ésta no alcanza a
entrar en el caso que nos ocupa.
El esquema de un ciclo de desarrollo de software se puede apreciar en la Figura 1.
Figura 1: Modelo del Ciclo de Desarrollo de Sistemas, conforme el estándar del IEEE.
Para el caso del SIIP y PROFECO, una etapa crítica fue la del Análisis de
requerimientos. El IEEE (1990) la define como el proceso de estudiar las necesidades
del usuario para llegar a una definición de requerimientos del sistema, hardware o
20
software. En su segunda acepción, se trata del proceso de estudiar y refinar los requisitos
de sistema, hardware o software. Aquí es conveniente señalar que en esta etapa se
reúnen los equipos de ingeniería con los distintos usuarios y se ponen de acuerdo sobre
qué va a hacer el sistema en detalle y cómo lo va a hacer. Más tarde se podrá apreciar
que, en esta etapa tan importante, los usuarios deben tener muy claro qué le van a exigir
al sistema que desarrollen los ingenieros de software. Se trata de un ejercicio en el que
ambos grupos deben hablar el mismo idioma, que es el de los programadores, para que
se pueda desarrollar un sistema. Se han hecho muchos esfuerzos para tratar de establecer
un lenguaje en común, pero en la práctica debe contarse con un interlocutor capaz de
mediar entre las partes y alcanzar los acuerdos que permitan avanzar en el proyecto.
De acuerdo con la Figura 1, antes de entregar el sistema a los usuarios finales se
llevan a cabo distintas pruebas para asegurar la integridad y buen funcionamiento del
producto. A estas pruebas se les conoce como Pruebas de sistema que no son, de acuerdo
con el IEEE (1990), más que las actividades en las que un sistema o componente es
ejecutado bajo condiciones específicas, los resultados son observados o registrados, y
una evaluación es hecha sobre algún del componente del sistema. Hay de varios tipos y
los más conocidos se ubican en la jerga de la industria como alfa y beta. Las pruebas alfa
se realizan únicamente para comprobar la funcionalidad general del componente y las
pruebas beta son liberaciones provisionales de los componentes para que los usuarios
puedan reportar los detalles menores que deben corregirse.
Ahora bien, el SIIP, desde su concepción inicial, incluye varios módulos que
21
introducen algunos conceptos adicionales a tomar en cuenta. Se trata de la
administración documental y la Inteligencia de Negocios. Asimismo, a lo largo de la
investigación también aparecerán los conceptos de administración de proyectos y el
impacto organizacional que tiene un sistema.
La administración documental no se refiere a la documentación del proyecto en sí
mismo, que pertenece al desarrollo del sistema. Se trata de la herramienta con la cual la
Coordinación de Archivos de PROFECO y los responsables de Archivos de Trámite y
Concentración de todas las unidades administrativas llevarán a cabo la gestión de sus
expedientes, tanto los que se generan desde el SIIP como los que se elaboran de manera
manual. Esta tarea de archivos se realiza conforme a los estándares internacionales en la
materia y bajo los lineamientos normativos del Instituto Federal de Acceso a la
Información y el Archivo General de la Nación. Las características de este módulo del
SIIP se detallarán en el capítulo siguiente.
La inteligencia de negocios es un término que se ha revolucionado en los últimos
años, aunque la idea no es nueva. El concepto, en su versión más sencilla, se refiere
simplemente a la recolección, análisis y presentación de la información de un negocio,
con el propósito de apoyar la toma de decisiones (Power, 2007). Es un concepto
íntimamente relacionado con el “Data Warehousing” que es, de acuerdo con Davis
(1999), una colección de datos obtenida de múltiples programas, archivos, bases de
datos, encontradas a lo largo de una organización en sus sistemas, almacenados en una
forma consistente y estructurada.
22
Esa información, cuando se analiza y presenta adecuadamente para el proceso de
toma de decisiones, es la inteligencia de negocios. Sus tres elementos críticos son los
datos de los procesos, el análisis especializado y la visualización para el nivel jerárquico
más alto de una organización.
Respecto de la administración de proyectos, el Project Management Institute
(2004) la define claramente como la aplicación de conocimientos, habilidades,
herramientas y técnicas a las actividades de un proyecto para satisfacer los requisitos del
proyecto. Se trata, en palabras muy sencillas, de la planeación, control y seguimiento de
lo que se necesita para alcanzar el objetivo de un proyecto. Un concepto adicional es el
del producto entregable —muy importante en la historia del SIIP— y que es, de acuerdo
con la misma fuente, cualquier producto, resultado o capacidad de prestar un servicio
único y verificable que debe producirse para terminar un proceso, una fase o un
proyecto. A menudo se utiliza más concretamente en relación con un producto
entregable externo, que es un producto entregable sujeto a aprobación por parte del
cliente o patrocinador del proyecto. Estos entregables son los elementos de
comprobación de avance más importantes. Esto último es especialmente cierto para el
caso del SIIP, porque en ellos gravitó el peso de las responsabilidades legales del
contrato, de las auditorías y del cierre de las etapas.
El impacto organizacional, por su parte, no es más que el cambio que enfrenta una
organización al desarrollar un sistema de información, de acuerdo con lo que establece
Keen (1981) y utilizan Gurbaxani y Whang (1998) y Mahmood y Becker (1985), entre
23
otros.
En resumen, una organización que decide desarrollar un sistema de información
pasa por un ciclo de desarrollo de software, que consiste en varias etapas (definición,
diseño, implantación, prueba y chequeo final). Este desarrollo se controla con las
técnicas de la administración de proyectos, con énfasis especial en el seguimiento de los
entregables. Para el caso del SIIP, el resultado es un sistema que integra sus procesos
sustantivos con la administración de los expedientes y el uso de la información de los
procesos en la inteligencia de negocios, todo lo cual generó un impacto específico en su
estructura, procesos y recursos humanos.
El desarrollo de sistemas y su impacto organizacional
Los sistemas de información y las ciencias computacionales han caminado de la
mano desde el comienzo mismo de la informática. Pero a mediados de los años ochenta
empezó a ser posible establecer algunas diferencias. Esa pequeña distancia ha ido
aumentando hasta tener ahora una disciplina completamente diferenciada de las ciencias
computacionales. Mucho tiene que ver la enorme revolución en las comunicaciones, la
computadora personal e Internet. Como ilustran Avison y Powell (2001), con una
imagen muy interesante, los sistemas de información, con la espalda apoyada en una
24
computadora, miran hacia el mundo en su conjunto, mientras que las ciencias
computacionales están en el mismo lugar, pero miran hacia el interior de la
computadora. Dicho de otra manera, los sistemas de información incluyen tópicos muy
importantes más allá de los aspectos meramente tecnológicos, tales como el impacto que
tienen en los negocios, organizaciones y sociedades, mientras que las ciencias
computacionales están enfocadas hacia el avance de la computadora como una
tecnología en sí misma.
Además, Avison y Powell argumentan que el estudio de los sistemas de
información necesariamente pasa por un enfoque multidisciplinario que ha ido
madurando en los últimos años y se ha establecido con firmeza tanto en la academia con
el entorno organizacional. Como ejemplos de este cambio se pueden mencionar los
ajustes en los programas de estudio de las universidades e incluso su estructura, con la
aparición de departamentos especializados en el tema, así como el traslado de la mayor
parte de la literatura de las revistas de ciencia computacional hacia las de negocio y
administración. La proliferación de conferencias, congresos regionales, boletines
informativos y sitios de Internet son también evidencia de este fenómeno.
En esta evolución se han discutido, principalmente, las metodologías para
desarrollar sistemas y para criticar el tradicional modelo de cascada. Los sistemas han
crecido desde aplicaciones aisladas hasta sistemas integrados, de sistemas contables a
sistemas para la toma de decisiones. Se han estudiado los efectos de los sistemas en el
ambiente laboral, en la moral de los empleados y en el empleo, en términos generales.
25
Recientemente, el tema que ocupa a la literatura es el impacto de la integración global
que implica Internet y los rumbos que puede tomar esta integración. Sin embargo, se ha
logrado mantener un consenso aceptable sobre la definición básica de un sistema de
información.
Otro aspecto de la literatura sobre sistemas de información es que su cuerpo
bibliográfico ha madurado desde que pudo separarse de las ciencias computacionales.
No es que esté cobrando la relevancia necesaria para darle raíces sólidas, lo que para
otras disciplinas relacionadas, como la administración del conocimiento, todavía es una
especie de ansiada carta de naturalización. Para los sistemas de información es un hecho
que ya quedó atrás. Como lo mencionan Banker y Kauffman (2004), el estudio de los
sistemas de información, en su plena madurez, se concentra en cinco grandes áreas que
demuestran claramente la profundidad que se ha alcanzado en el ámbito académico. Se
estudian modelos teóricos para la toma de decisiones, para el comportamiento de las
redes de todo tipo; se analizan los detalles de lo que denominan “Economía de la
Información” y cómo se usan y comparten los datos; se utilizan todas las metodologías
imaginables y las relaciones con otras disciplinas y áreas de conocimiento está
igualmente establecida y documentada.
El entorno académico fue receptivo a este tema y respondió con intensidad a los
retos que se señalaron al comienzo de los años noventa. El estudio de la práctica y la
teoría es un elemento común en la enseñanza de los sistemas de información.
Pero América Latina, a pesar de la salud académica de los sistemas de
26
información, no es la fuente de este progreso. Como en tantos otros terrenos, los países
que conforman esta región del mundo siguen los pasos de los países industrializados
como sumergidos en una especie de somnolencia que les impide, en términos generales,
adelantarse a la discusión. Mientras aquellos se preocupan por analizar si el paradigma
de los sistemas de información enfrentará cambios radicales en los decenios por venir,
en América Latina todavía se lucha por tener una cobertura aceptable del uso de
computadoras. Si la literatura sobre sistemas de información da por sentado que éstos
existen y que lo importante es analizar su grado de éxito o fracaso, o determinar su
madurez o, incluso, medir la capacidad de sabiduría que pueden alcanzar, en América
Latina no se puede hacer lo mismo por la simple razón que los sistemas de información
todavía no son endémicos. En gobierno, por ejemplo, todavía hay una multitud
considerable de procesos que se llevan a cabo sin la intervención de sistemas de
información, lo que no es más que una manera muy cuidadosa de decir que todavía se
trabaja en muchos lugares a mano y con lápices. Es probable que esta situación todavía
sea más numerosa que los procesos que sí ocurren en el ambiente controlado de un
sistema. No hay estadísticas disponibles debido a esos mismos hechos. En el caso de
PROFECO, por adelantar un comentario, se puede apreciar esta circunstancia y su
transición hacia un cambio.
En este sentido, algunas premisas básicas de trabajos de investigación que podrían
considerarse rebasadas por el tiempo, mantienen una vigencia completamente
inesperada. Un texto de principio de los años ochenta, escrito por supuesto en una
máquina de escribir mecánica, previo a la explosión del uso y cobertura de las
27
computadoras que todos conocemos, previo a Internet y la revolución en las
comunicaciones, tiene afirmaciones sobre un campo tan volátil como las computadoras
que todavía suenan válidas. Bastan un par de ejemplos.
Rubén Prieto Díaz y Stephen Wilson (1981) sostienen que un sistema de cómputo
—nótese la cercanía de los conceptos— tiene el potencial de grandes beneficios pero
para mercados como América Latina puede tener impactos negativos en los entornos a
los que afecta. Dicen que en lugares donde el desempleo es alto o difícil de conseguir, la
instrumentación de un sistema de cómputo puede expulsar a las personas de sus trabajos
y estas últimas pueden no encontrar otra fuente de empleo porque simplemente no hay
vacantes disponibles. Después se verá que esto ocurrió en el caso de PROFECO.
En otro ejemplo, Prieto Díaz y Wilson señalan que el entorno integral en el que se
mueve un sistema de cómputo no tiene las mismas características de infraestructura que
un país industrializado. Esto quiere decir que a pesar que una organización adquiera sus
computadoras y haga lo posible por distribuirlas en toda su estructura y comunicarlas
entre sí, enfrentará problemas con las líneas telefónicas, cortes en el suministro de
energía eléctrica, además de la persistencia de las prácticas en el servicio preexistentes a
las computadoras. También ocurrió en PROFECO.
Un ejemplo más. Es conocido que la información procesada por las computadoras
facilita la toma de decisiones de los elementos superiores de la jerarquía organizacional.
Pero si estos últimos no tienen idea de cómo usar la información, el valor de esos datos
es nulo. Si las habilidades de administración son escasas, como ocurre en América
28
Latina, el costo de aprender a usar el sistema es muy alto, lo que implica un riesgo muy
grande de fracasar en su implantación. Como en el punto anterior, acaba de ocurrir en
PROFECO.
Otro de los detalles que pueden apreciarse en el caso de América Latina es el
consumo de software comercial preelaborado muy por encima del desarrollo propio en
los sistemas. Todavía es muy frecuente que una institución deba adaptarse a un
programa específico y no al revés. La transformación de muchas organizaciones
respecto de sus sistemas de información tiene marca y etiqueta. Es el sello del cambio,
en vez de encontrar sólidos desarrollos internos. Este punto parece ser un poco más
borroso en los últimos años, toda vez que algunas instituciones académicas en México
han hecho esfuerzos notables por mejorar sus carteras de formación de profesionales en
el desarrollo de sistemas y las organizaciones han sido más receptivas a las ventajas del
desarrollo propio.
Pero esta circunstancia de caminar detrás de las pautas de los países
industrializados tiene sus aspectos positivos. En primer lugar, están los factores de
economía de escala, como se pueden encontrar en los reportes de la Asociación
Mexicana de Internet, (AMIPCI, 2007). América Latina crece con rapidez precisamente
porque antes no había computadoras, infraestructura de comunicaciones y acceso a
Internet. En segundo lugar, aunque se establecen nuevas formas de dependencia frente a
los países industrializados, también se aceleran los ciclos en los que se aprende de los
errores y limitaciones de los paradigmas que se utilizan. También se acelera el uso de la
29
información de referencia, como las bibliotecas digitales, en franca aceptación de las
bondades de la “sociedades del conocimiento”, como mencionan Hilbert y Katz (2003).
Todo lo anterior lleva a detenerse a recapitular un poco sobre los modelos de
desarrollo de sistemas de información que se han utilizado en los últimos decenios. El
más importante, precisamente por ser el modelo clásico, la referencia obligada, el
esquema más simple y general, es el que está descrito en el glosario del IEEE y que se
mencionó con anterioridad. Esa secuencia de pasos en cascada para desarrollar un
sistema tiene todos los elementos básicos y ordenados que hacen que un modelo
funcione. Sin embargo, uno de sus problemas principales es que se trata de un esquema
rígido y lineal, como sostiene Pardo, y que realmente no corresponde a la manera como
realmente se trabaja en un proyecto de este tipo. Las revisiones frecuentes, los cambios
de intención y de muchos otros factores, llevaron a aplicar el mismo esquema, pero con
iteraciones de revisión y programación que llevan a mejores resultados. Estos modelos, a
los que se conoce como espirales, son complejos de administrar, pero se adaptan un
poco más a la forma real de trabajo de las oficinas.
Con los años han ido surgiendo distintos modelos, propuestas y estilos de
programación, cada una con sus méritos y, posiblemente, cada vez más adentrada en las
profundidades de la ingeniería de desarrollo de software. Sin embargo, todas estas ideas
no han terminado de solucionar un problema que permea a esta Industria. No importa
qué modelo se utilice, una gran mayoría de proyectos de sistemas de información
terminan en un fracaso, aunque técnicamente sean correctos. Pardo (2002) señala
30
algunos datos interesantes al respecto. Conforme a sus hallazgos, en Estados Unidos, tan
solo 40% de los desarrollos de sistemas de información alcanzan resultados
satisfactorios, con sólo 10% de los fracasos vinculados a factores técnicos. En Canadá
hay estudios que señalan un porcentaje de 70% de fracasos, y en Malasia la cifra es de
60%. En estos últimos casos, el factor humano es el elemento más relacionado con los
fracasos.
El dilema, entonces, puede enunciarse de la manera siguiente. Uno de los
elementos que más sobresale en este diagnóstico es la observación que los factores
humanos son tanto o más importantes que los tecnológicos. Tan es así que,
frecuentemente, cuando un sistema falla, la causa se encuentra más en problemas como
la falta de planeación, mala comunicación, controles inapropiados, poca capacitación y
la resistencia al cambio que en los aspectos tecnológicos del sistema. Ahora bien, de
acuerdo con la definición de Senn (2006), un sistema es un conjunto de componentes
que actúan entre sí para lograr un objetivo común, en términos simples y sencillos. Pero
el punto central que hay que aclarar es que hay una cantidad considerable de elementos
que no implican un contenido tecnológico y que, frecuentemente, la literatura
especializada los da por sentado o no los considera en su importancia verdadera.
Las diferencias de visión que hay entre los usuarios y el personal encargado de
desarrollar un software determinan en gran medida el éxito o fracaso de una aplicación,
como lo señalan los estudios que se enfocan en el impacto organizacional.
Los sistemas de información son herramientas que ayudan a los usuarios a realizar
31
sus trabajos y compartir la información que generan en sus actividades. De allí que
Avison y Powell (2001) señalen que los Sistemas de Información no son lo mismo que
Tecnología de la Información. Las personas están tan involucradas como las
computadoras en un sistema de información y no todas las partes del sistema están
automatizadas.
La discusión se puede enunciar en términos del tránsito de un punto, al que puede
compararse como positivista, similar a la economía clásica, de acuerdo con Pardo
(2002), hasta otro que responde al nombre de constructivista. Este tránsito ilustra el
movimiento de péndulo que hay desde entender el desarrollo de sistemas de información
desde el punto de vista exclusivo de los ingenieros de software, hasta plantear el otro
extremo; diseñar el sistema desde el punto de vista de los usuarios. Pero no se puede
soslayar la importancia de compartir un idioma en común con los ingenieros de
software, toda vez que, al final de la historia, el sistema debe desarrollarse con las
herramientas de estos últimos. Avison y Powell (2001) sostienen la importancia que han
adquirido estos enfoques “sociotécnicos” sobre los puramente técnicos. Es posible que
las estadísticas de los próximos años arrojen datos suficientes para determinar si un
enfoque da mejores resultados que otro. En cualquier caso, en un proyecto donde
participan dos grandes grupos, es preferible tomar en cuenta las necesidades de ambos
en vez de dejar el balance de los asuntos cargados hacia un lado de la balanza.
El diagnóstico general que han hecho estos autores sobre los factores que inciden
en el fracaso de los desarrollos de sistemas, encuentra una cantidad considerable de
32
elementos organizacionales que deben tomarse en cuenta. Si en un proyecto se los
identifica claramente y se los incorpora de manera adecuada en la planeación, según este
argumento, será más fácil llegar a un resultado exitoso.
Una vez que se acepta la existencia de los factores organizacionales en un
desarrollo de sistemas de información, es necesario describir la manera en que estos
factores inciden en los proyectos de informática.
Keen (1981) identifica la inercia como uno de los primeros obstáculos que
enfrenta el desarrollo de sistemas. Los individuos que pertenecen a una organización
tienen la tendencia a preferir que las cosas permanezcan como están y se resisten a los
cambios radicales y súbitos. En ese sentido, la inercia “social” respecto de los sistemas
de información se caracteriza de la siguiente manera:
1) La información es sólo un componente pequeño de los procesos
organizacionales de decisión;
2) El procesamiento de información humano es empírico y descansa sobre
simplificaciones;
3) Las organizaciones son complejas y el cambio debe ser incremental y
evolucionista; se evitan los grandes saltos e incluso se resisten;
4) La información no es meramente un producto intelectual, sino un recurso
político cuya redistribución por medio de los sistemas de información afecta los
intereses de grupos particulares.
33
Para esos grupos a quienes se les puede afectar con la redistribución de
información —y, por lo tanto, de poder-- los sistemas de información son entes
amenazantes e innecesarios. Son una invasión a su esfera de influencia y las técnicas que
traen aparejadas consigo —como la evaluación de sus resultados y el monitoreo de sus
actividades— no sirven mas que para criticar su trabajo.
La simplificación coloquial de “la información es poder” es muy apropiada en este
contexto. Keen (1981) señala que la información es un recurso que simboliza el estatus,
aumenta la autoridad y determina las relaciones dentro de una organización. Es un
elemento de poder. Como los sistemas redistribuyen la información, rompiendo
monopolios en el proceso, construir una base de datos se convierte en un movimiento
político.
Keen (1981) menciona que el diseñador del sistema debe detenerse a preguntarse
quién es el dueño de la información, con quiénes va a compartirla, cuál va a ser el
impacto de esa redistribución y cómo afectará las relaciones de influencia, autoridad y
comunicación. Otro aspecto que debe considerarse es que esa redistribución de
información está relacionada con la autonomía de los departamentos que forman una
organización, porque su influencia puede sustentarse en que tienen un monopolio sobre
ciertos datos.
Por ello, en la planeación de un proyecto de esta naturaleza se deben incorporar
estos elementos, si no es que deben ser los primeros a tomar en cuenta. En este sentido,
de acuerdo con Keen (1981), el desarrollo de sistemas de información es un asunto
34
también político, incluso más que técnico en ocasiones. Si se acepta ese principio, los
mecanismos organizacionales funcionan de manera natural. El problema —como ocurre
en sintonía con asuntos que pueden constatarse en la prensa mundial— es que el
concepto de lo “político” está ahora mucho más asociado a los términos de corrupción,
ineficiencia y rezago, además de ser lo que más puede oponerse a un enunciado racional,
como las cuestiones de ingeniería. Sin embargo, la política, en su raíz más pura, es el
arte del compromiso, de generar apoyos donde no los hay y crear consensos que apoyen
cambios específicos.
Es necesario aceptar la naturaleza política de la información y que una autoridad
adecuada, capaz de comprender este hecho, debe ser la encargada de administrar el
cambio social que implica el desarrollo de sistemas.
Ahora bien, los autores de estos estudios ofrecen una receta sobre los elementos
que facilitan el éxito del desarrollo de sistemas. Los resultados que obtuvieron en sus
investigaciones les dieron la confianza para sostener que los pasos del desarrollo de
sistemas no deben ignorarse y que los elementos no técnicos sino organizacionales
deben incorporarse adecuadamente en la planificación del proyecto. Pardo y Scholl
(2002) lo establecen con toda claridad cuando dice que si no se atienden estos
elementos, se transita por un atajo hacia el fracaso.
La gran utilidad de estas recomendaciones es que pueden utilizarse para elaborar
un esquema contra el cual se puede contrastar la experiencia de PROFECO. De esta
manera es posible establecer un marco de referencia para ponderar el impacto
35
organizacional que tuvo el desarrollo del SIIP en PROFECO.
Sin embargo, es necesario hacer una acotación muy importante. Los distintos
autores ofrecen con frecuencia distintas métricas, muy específicas (como el caso de
Gurbaxani), para medir toda suerte de detalles en los casos de estudio. Sin embargo, esas
métricas suelen estar fuera del alcance de la evidencia disponible para el caso de
PROFECO. Esos estudios presuponen un manejo de la información cuidadoso y
sofisticado, con multitud de fuentes y grandes presupuestos de investigación, todo ello
inexistente en PROFECO. La naturaleza de la evidencia disponible es fuertemente
testimonial y gran parte de la documentación o no existe o no se apega a los estándares
de la industria. Por ello, no tiene sentido proponer un esquema de contraste demasiado
apegado a variables matemáticas. El caso de PROFECO fallaría en todas ellas o no
habría modo de obtener resultados válidos. Es posible que estudios posteriores puedan
avanzar mejor en este sentido, cuando más y mejor evidencia esté disponible o no se
tengan que establecer los mínimos sobre el caso.
Por ello, un esquema de los conceptos que los distintos autores identificaron como
claves para comprender el impacto organizacional del desarrollo de sistemas de
información, permite tener una especie de lista, de “check list”, para responder de qué
manera PROFECO atendió a las recomendaciones y qué obtuvo como resultado de
acercarse o no a ese marco de referencia.
El esquema puede agruparse en tres grandes apartados en los que se acomodan las
recomendaciones de los autores, conforme lo expusieron en sus distintos artículos. Estos
36
apartados se aprecian en la Figura 2.
Figura 2: Caracterización del impacto organizacional del desarrollo de un sistema
1) Administración del cambio. Prácticamente hay consenso en los autores
respecto de este apartado. Un elemento que se repite constantemente en la literatura y
que autores como Pardo lo establecen explícitamente, es la necesidad de administrar el
cambio que implica el desarrollo de un sistema de información, con especial énfasis en
los elementos no técnicos. Esto se traduce en la necesidad de contar con un liderazgo en
la organización que pueda entender las relaciones que hay entre los elementos técnicos y
sociales y servir de árbitro y moderador de las diferencias. Esto mismo exige tener una
estrategia definida para administrar ese cambio.
37
Como se mencionó antes, no hay modo de alcanzar esta meta si no consideran a
los bandos involucrados en un desarrollo de este tipo, que generalmente se dividen de
manera gruesa en usuarios y desarrolladores. Si ambos no están profundamente
involucrados en todas las etapas, pero principalmente en la de análisis y diseño, el
resultado suele ser que el grupo de desarrolladores acaba por elaborar un sistema a su
propio gusto, con los desencuentros que esto implica con los usuarios. Además, en este
apartado es importante considerar qué tan capaz fue la administración de PROFECO de
sustraerse a las tentaciones de saltarse etapas para cumplir con fechas de entrega y
rendición o promoción de resultados.
2) Diseño de sistema desde un punto de vista sociotécnico. Aquí debe
considerarse las tareas aceptadas en la industria para cubrir todos los aspectos que debe
cumplir el sistema. Debe haber un estudio previo de los procesos y una investigación
sobre las mejores prácticas vigentes. En este apartado caben las tareas típicas del
departamento de informática, de analizar las estructuras de datos y su reconstrucción a
partir del análisis y rediseño de los procesos a incorporar en el sistema. Por último, y no
menos importante, es necesario desarrollar un lenguaje común con el que puedan
entenderse todos los involucrados, con los detalles que se mencionaron antes.
3) Cambio del flujo de información en la estructura. En este lugar se ubican las
evaluaciones, estimaciones y consideraciones que implica modificar la manera en la que
38
se usa la información en una organización. Se debe evaluar el impacto que tiene cambiar
el flujo de los datos y, en consecuencia, el poder que controlan los distintos
departamentos, así como el cambio en la toma de decisiones que implica una
reestructuración de esta índole.
39
CAPÍTULO 3
METODOLOGÍA
Modelo del caso de estudio
De acuerdo con Hernández Sampieri et al (2006) sobre la metodología para
estudios de caso, el modelo de la Harvard Business School (HBS) se adapta mejor a las
características del desarrollo del Sistema Integral de Información y Procesos (SIIP) de
PROFECO.
Como se puede apreciar en la Figura 3, el modelo establece una serie de pasos que
deben seguirse para completar un caso de estudio.
40
Figura 3. Esquema del caso de estudio conforme al modelo de la Harvard Business
School.
41
Este modelo contempla que, una vez identificado el caso a estudiar, se deben
investigar los antecedentes del caso, con la finalidad de ubicar el contexto en el cual se
desarrolla. Después se debe conseguir el permiso de la organización para que el
investigador pueda recorrer las instalaciones, obtener la información, preguntarle a los
individuos. En una palabra, obtener el acceso a toda la información que es relevante para
el caso.
El siguiente paso dentro del flujo de la HBS es realizar la investigación
propiamente dicha. En este momento es cuando se recopila toda la información posible
directamente de sus fuentes, se documenta el factor humano individual relacionado con
el caso y se hace un esfuerzo por convencer a la institución que es benéfico para sus
intereses que su personal participe en la investigación. El flujo continúa hacia el detalle
adicional de la investigación con la visita de campo. Las entrevistas, la comprobación
visual y las notas de campo son fundamentales en esta etapa, sobre todo para corroborar
algunas de las hipótesis o puntos de interés que se hayan identificado durante la revisión
de los documentos e información disponible. De esta manera se obtiene un conocimiento
global sobre el caso.
Una vez cumplido lo anterior, se procede a analizar los resultados, evaluar la
información obtenida y elaborar las conclusiones del caso. Por último, se elabora el
reporte, que puede tener sus particularidades específicas.
42
Para el caso de PROFECO, el uso del modelo de la HBS quedaría conforme a la
Figura 4.
Figura 4. Esquema del caso de estudio. Adaptación del modelo de la Harvard
Business School al caso del desarrollo del SIIP.
43
Disponibilidad de información
La cuestión de obtener la información suficiente y adecuada para desarrollar
cualquier investigación es de primordial importancia. En el caso de un proyecto federal
es todavía más importante, toda vez que México está atravesando por un cambio
fundamental en la información que fluye entre gobernante y gobernados. Hay pocos
cambios tan importantes en el gobierno federal en los últimos años como el que se
refiere al acceso a la información pública. Lo que antes era un atrevimiento pensar,
desde el punto de vista ciudadano y, por extensión, académico, era pedirle información a
una entidad gubernamental. Ahora hay instrumentos legales para solicitarla y obtenerla
en un plazo específico de tiempo. La Ley Federal de Transparencia y Acceso a la
Información Pública Gubernamental (2002), es la que establece las condiciones y reglas
para permitirle a un ciudadano conocer la información en poder de su gobierno.
Sin lugar a dudas, esta Ley es un elemento que el gran público está comenzando a
utilizar con todas sus potencialidades para conocer a profundidad las acciones que lleva
cabo un gobierno. El efecto organizador no acapara los titulares de la prensa, pero tiene
efectos inmediatos en la conservación de los documentos. El acceso a la información
pública le deja muy pocos espacios a una institución para negar los datos que posee.
Desde luego, está la cuestión de la calidad de esos datos, porque nunca había sido
prioritario para las instituciones de gobierno tener buena información, pero lo que no
pueden impedir es el acceso a ellos.
44
Otro aspecto novedoso de la relación entre gobierno y ciudadanos es que el marco
jurídico de Transparencia tiene, entre otras consecuencias, que los sujetos obligados (las
entidades de gobierno) generen memoria institucional. A estas alturas es difícil concebir
que una organización no haga esto último, pero se trata de una actividad completamente
nueva para gobierno y PROFECO no se escapa de esta realidad. Cada vez más, debido a
la organización de sus archivos (antes de estas leyes no había organización obligatoria),
se generan los elementos de una memoria institucional.
PROFECO, como sujeto obligado de la Ley Federal de Transparencia, ha realizado
grandes esfuerzos para organizar su información. Incluso, para el caso específico del
SIIP, la PROFECO ha tenido que dar el acceso en varias ocasiones a la información en
su poder, así como al expediente mismo del proyecto. En cualquier caso, este marco
legal permitió obtener documentos que pocas veces alcanzan la luz pública, no por el
contenido delicado de sus contenidos, sino por el simple desorden con que se realizan
muchas tareas.
Adicionalmente, el Instituto Federal de Acceso a la Información Pública (IFAI) y
la Secretaría de la Función Pública obligaron a las entidades de gobierno a elaborar
"Libros Blancos" de sus procesos fundamentales o proyectos principales con el objeto de
rendir cuentas en el cambio de administración 2006-2007. Para el caso del SIIP, el
proyecto más ambicioso de infraestructura y modernización en la historia de PROFECO,
se tomó la decisión de elaborar un "Libro Blanco" con el objeto de tener una herramienta
de referencia inmediata sobre los pormenores del proyecto y facilitar la rendición de
45
cuentas. Este Libro Blanco se terminó en septiembre de 2006.
Este documento, a pesar de sus limitaciones y carencias, es un elemento
fundamental para comprender lo que ocurrió con el SIIP a lo largo de cuatro años de
desarrollo. Como también se hizo mención antes, la práctica de documentar proyectos
todavía es novedosa en Gobierno Federal y, por tanto, sujeta a gran cantidad de
improvisaciones y errores. El Libro Blanco del SIIP no es ninguna excepción. Lo
primero que hay que entender es que se trata de un documento elaborado ex post facto.
Esto significa que la Dirección General de Informática lo elaboró al final del desarrollo
y teniendo en cuenta únicamente los fines de rendición de cuentas y atención de
observaciones del Órgano Interno de Control. Nunca tuvo la intención de ser la historia
documental del SIIP, aunque durante los últimos meses de 2006 esa Dirección General
hizo un esfuerzo considerable por documentar todo el proyecto, así fuera sólo para
cumplir con los objetivos de rendición de cuentas.
El Libro Blanco está lleno de imperfecciones notables y grandes simplificaciones.
Pasa por alto, entre muchas otras cosas, los detalles que implicó cumplir grandes hitos
del proyecto. El elemento humano brilla por su ausencia y el flujo de los
acontecimientos se describe con unos cuantos saltos generales. En ocasiones, el
contenido de las descripciones no es homogéneo y varias etapas del SIIP reciben un
tratamiento muy superficial o poco claro. No tiene esquemas que expliquen las
transformaciones que estaban teniendo lugar, ni siquiera una línea de tiempo sobre el
cumplimiento de los plazos del proyecto.
46
Y, sin embargo, ilustra mucho. Durante años, obtener información de este tipo era
impensable para las organizaciones de gobierno. El día de hoy, se encuentra disponible
en las páginas de Internet, en las secciones que obliga la normatividad de Transparencia
para tal efecto. El valor verdadero del Libro Blanco es que se refiere a expedientes y
registros que no van a desaparecer con la ventura de un cambio de administración, como
sucedió demasiadas veces en la historia inmediata de nuestro país. No importa lo
limitado y humilde que haya sido el esfuerzo del personal de PROFECO, lo valioso es
que existe un documento que contiene las referencias mínimas fundamentales para
entender qué ocurrió dentro de la institución en un periodo crítico de su existencia.
Además de estos documentos están los informes que PROFECO produce de
manera anual y que, para el periodo de desarrollo del SIIP, contienen referencias
constantes al proyecto. También fue posible obtener algunos documentos específicos
para documentar algunos aspectos particulares, tales como documentos relativos al
cabildeo de las reformas a la Ley Federal de Protección al Consumidor (2002-2003) o
los documentos que reportan las negociaciones con Unisys ante la Secretaría de la
Función Pública después del incumplimiento de los plazos para el desarrollo del SIIP.
Las entrevistas realizadas para documentar el caso del SIIP no tuvieron una
orientación estadística sino testimonial. Es prudente volver a mencionar, como se apuntó
al principio de este documento, que el aspecto testimonial es igual de importante que la
parte documental propiamente dicha, especialmente porque de otra forma se perderían
datos que no tienen un soporte documental, consignándolos a un registro permanente, y
47
porque arrojan mucha información sobre aspectos críticos del sistema que de otra forma
no se podrían conocer.
En este caso de estudio fue posible entrevistar a los individuos más involucrados
con el desarrollo del SIIP. Aunque el número de entrevistas no es elevado, incluye los
testimonios relacionados con los problemas de alta gerencia del desarrollo; la visión de
conjunto del proyecto; el entorno institucional en el que se llevó a cabo; las experiencias
de los usuarios principales; y la aplicación de las lecciones aprendidas al desarrollar
nuevos módulos para el sistema.
Las preguntas conductoras de las entrevistas se concentraron en obtener las
impresiones sobre el método con que se desarrolló el sistema, el grado de
involucramiento y actuación de las distintas áreas, así como una apreciación sobre los
resultados obtenidos y su propia participación en el proyecto.
¿Cómo se desarrolló el SIIP?
A finales de 2002 se abrió la licitación para el desarrollo del SIIP y el 20 de
diciembre se firmó el contrato con Unisys de México para “…la implantación de un
sistema integral de información y procesos (SIIP) para la automatización de las
funciones sustantivas y administrativas de la PROFECO, integrado en cuatro etapas,
48
cuya vigencia abarcaba del 20 de diciembre de 2002 al 31 de diciembre de 2003, por un
monto de 7’437,696.30 US dólares de los Estados Unidos de América” (Procuraduría
Federal del Consumidor, 2006b).
Unisys proporcionó un calendario de trabajo inicial que puede apreciarse en la
Figura 5.
Figura 5: Calendario original propuesto para el desarrollo del SIIP.
No hay documentos que expliquen con base en qué métricas o experiencias previas
Unisys aceptó un calendario tan apretado, tomando en cuenta la naturaleza del proyecto.
49
Como referencia, en la propia Coordinación de Asesores, durante el primer semestre de
2003, se llevó a cabo el desarrollo de un sistema para un solo proceso, el de atención de
solicitudes de transparencia, y ocupó seis meses de trabajo muy bien coordinado entre
programador y usuario, sin interferencias, sin sistemas preexistentes, sin resistencia al
cambio y únicamente para atender las necesidades de una docena de usuarios
adicionales. El SIIP incluiría, básicamente, más de la mitad de la operación de
PROFECO, además del manejo documental y el control de archivos, con 2500 usuarios
concurrentes cuando menos y operación en toda el territorio nacional.
La Figura 6 muestra el esquema de funcionamiento del SIIP, de acuerdo con lo
mencionado en el Libro Blanco (PROFECO, 2006).
50
Figura 6: Esquema conceptual del funcionamiento del SIIP
El Libro Blanco (2006) define el objetivo del SIIP como "contar con información
oportuna y veraz para la toma de decisiones, a través la implantación de una Plataforma
Informática Integral que agilice, eficiente y de transparencia a los procesos sustantivos y
administrativos de la Procuraduría Federal del Consumidor.
Las palabras clave son "integral" y "procesos sustantivos y administrativos". Se
trata de introducir prácticamente todo lo que hace PROFECO en una misma plataforma
informática. De allí la noción de "integral". El enunciado se traduce en un sistema dentro
del cual todas las oficinas de PROFECO en el territorio nacional llevan a cabo las tareas
51
para las que están facultadas, además de su administración. Los números son realmente
considerables, porque PROFECO, de manera global, atiende cientos de miles de asuntos
al año en sus distintas modalidades y el SIIP tiene la intención de proporcionar un
"paraguas" informático que lo cubra todo por completo.
La composición del SIIP comprende, actualmente, tres sistemas sustantivos (el
Sistema de Administración de Recursos, el Sistema de Servicios, y el Sistema Jurídico),
el módulo de Administración Documental y el de Inteligencia de Negocios.
Los tres sistemas sustantivos intercambian constantemente la información que se
genera a lo largo de los distintos asuntos que atiende la institución de manera cotidiana.
En el sistema administrativo se encuentran, principalmente, los procesos
financieros de PROFECO. Gran parte de los trámites burocráticos que rodean la vida
cotidiana de los servidores públicos de PROFECO todavía están fuera del SIIP, en este
sentido. Pero al menos el manejo de la nómina, las cuentas bancarias institucionales, los
seguros y algunos procesos de recursos humanos ya están automatizados.
El sistema de servicios es uno de los más importantes de PROFECO y requiere
una pequeña descripción. De acuerdo con la Ley Federal de Protección al Consumidor
(Procuraduría Federal del Consumidor, 2004a), si un consumidor considera que sus
derechos han sido violados, puede acudir a PROFECO para buscar un resarcimiento.
PROFECO tiene establecidos diferentes mecanismos para sentar ante la mesa de
negociación a los proveedores con los consumidores y sirve de mediadora. Este proceso
de conciliación ha hecho de PROFECO una presencia conocida entre la población. Tiene
52
una calificación pública de 8.3, semejante al de la Cruz Roja o los Bomberos, según lo
establece el Informe de Labores 2005 (Procuraduría Federal del Consumidor, 2006b).
Este proceso es el que se encuentra ahora dentro del SIIP. Con frecuencia
intervienen otros procesos institucionales. La atención de quejas, dependiendo del
camino jurídico que siga, puede transitar hacia el módulo jurídico del SIIP o, incluso,
enviar determinados elementos al área de verificación --cuyo proceso todavía no se
incorpora al SIIP-- para iniciar sus propios procedimientos en otro sistema institucional.
El módulo jurídico comprende, en este momento, los juicios de nulidad y amparo
que se promueven en contra de los actos de autoridad de PROFECO. En este módulo se
lleva todo el control de estos juicios y se vincula con los procedimientos sustantivos,
tanto en la parte de Servicios como en Verificación, que les dan origen.
La administración documental, por su parte, es un espejo archivístico de lo que
ocurre en los procesos sustantivos. Esta parte del SIIP descansa sobre estándares
internacionales en materia de archivos y en un software reconocido en el mundo de
habla hispana, conocido como Albalá, donde se registran las fichas de los documentos
que se generan en el SIIP. Este mismo software se usa en los procesos que no están
dentro del SIIP y permite tener un manejo homogéneo de todos los archivos
institucionales.
Por último, otra de las características del SIIP es la parte de explotación de
información. Es la parte más novedosa e importante, estratégicamente, para la
institución, aunque esta importancia está profundamente vinculada con el entendimiento
53
individual que los mandos superiores de PROFECO tengan sobre la plataforma
informática y la relevancia que le den al uso de los datos. La Inteligencia de negocios
(BI) es un conjunto de aplicaciones que se utilizan para adquirir, proporcionar acceso y
analizar la información sobre los procesos de una organización.
Unisys completó exitosamente las dos primeras etapas de su calendario propuesto,
que comprendieron la adquisición de licencias y la configuración de servidores, tareas
que por su naturaleza ocurrieron fuera de la vista de los usuarios en PROFECO.
La tercera etapa correspondió al desarrollo del módulo de administración de
recursos y también se cumplió en tiempo. Hay poca información disponible para saber
qué ocurrió con la definición de requerimientos de este módulo y cómo entró en
operación, pero los problemas no estaban relacionados con el desarrollo del SIIP, en
términos generales. En primer lugar, el uso del dinero en un sistema es muy similar y las
cuentas tienen que cuadrar igualmente para todos, así que no hay muchos lugares para
las dudas. Fue más la resistencia a dejar de lado otras herramientas, más fáciles de
manipular —con todas sus implicaciones— que un sistema con el SIIP lo que estuvo
escuchándose en los pasillos de la institución, pero el módulo funcionó aceptablemente
bien.
La siguiente etapa, que implicaba la parte de recursos humanos y materiales, no
pudo completarse a tiempo y se firmó un convenio modificatorio para extender los
plazos hasta agosto de 2004 y reestructurar el resto del proyecto en ocho etapas. La
etapa cuatro concluyó en diciembre de 2003 y la etapa cinco en mayo de 2004.
54
Pero a partir de este momento comenzaron los verdaderos problemas. El mismo
Libro Blanco menciona que en el primer semestre de 2003 (un error evidente, porque los
cambios fueron hasta el primer semestre de 2004 y porque la persona encargada de la
elaboración del documento no estuvo en PROFECO cuando ocurrieron estos
acontecimientos) se reemplazaron varios servidores públicos de mando cuya
participación en el proyecto era determinante para el desarrollo en tiempo del mismo, ya
que eran los responsables de revisar y aprobar el levantamiento de flujos de trabajo de
diversos módulos del sistema. Los servidores públicos que sustituyeron a los salientes
necesitaron de un periodo adicional de tiempo para revisar, corregir y aprobar los flujos
de trabajo y requerimientos antes citados (Procuraduría Federal del Consumidor, 2006).
Pero esos “varios servidores públicos de mando” eran nada menos que la propia
titular de la institución y buena parte de sus colaboradores de primera línea. Su renuncia
en marzo de 2004 llevó al cambio del Coordinador General de Administración,
responsable oficial del desarrollo del SIIP; al Coordinador General de Planeación,
supervisor de facto del avance del SIIP; y de otros funcionarios como el Subprocurador
de Verificación y la Directora General de Delegaciones. De una manera poco visible, la
responsabilidad del desarrollo del SIIP cayó en manos de los mandos de rango
jerárquico inmediato inferior, para no abandonar este lugar hasta el final del proyecto.
Unisys no pudo cumplir las fechas de entrega para las etapas seis y siete y tuvo
que enfrentar una complicada ronda de negociaciones en la Secretaría de la Función
Pública para modificar de nueva cuenta las fechas de entrega. No se modificaron los
55
alcances ni el monto del proyecto, por lo que Unisys recibió un golpe fuerte por estos
retrasos.
Las etapas seis y siete, que comprendieron los procesos más relevantes del
desarrollo hasta ese momento, fueron retrasándose otras dos veces más, hasta que
finalmente se entregaron el 7 de noviembre y el 12 de diciembre de 2005. Los procesos
que comprendieron estas etapas fueron los de la Subprocuraduría de Servicios y los de
administración documental, además de los faltantes en la parte de recursos.
La última etapa comprendió el Sistema Jurídico Contencioso y la parte final de
inteligencia de negocios. Las fechas de entrega de esta etapa se fueron ampliando, al
igual que las anteriores, para estar lista en septiembre de 2006 por lo que respecta a
Jurídico y en febrero de 2007 lo que correspondía a inteligencia de negocios. La entrada
de la nueva administración de PROFECO a partir de diciembre de 2006 no tuvo mayor
efecto en la conclusión del SIIP.
La línea de tiempo del desarrollo del SIIP quedó, finalmente, como se puede
apreciar en la Figura 7. En ella se puede apreciar que el proyecto concluyó con cuatro
años de retraso respecto de la fecha original propuesta.
Figura 7: Calendario final del desarrollo del SIIP
Para cumplir con todas estas expectativas, PROFECO pagó un precio
considerable. De acuerdo con el Libro Blanco, la institución erogó por concepto de
desarrollo del SIIP un total de USD$7,438,023 que, en moneda nacional, asciende a más
de 78 millones de pesos.
58
CAPÍTULO 4
ANÁLISIS DE LOS DATOS
Caracterización del impacto organizacional en PROFECO
Es posible contar la historia de cualquier acontecimiento con tantos detalles como
se puedan tener a la mano. En el caso del SIIP, la secuencia de eventos permite
comprender de modo general el tamaño de proyecto que significó para PROFECO. Sin
embargo, la cuestión principal sigue siendo determinar el impacto organizacional y
cómo caracterizarlo.
Para responder a las dos primeras preguntas de investigación de este caso de
estudio, se hizo lo siguiente.
En el marco teórico, después de revisar la literatura al respecto, se propuso un
esquema simple para comparar los elementos más críticos que los especialistas en la
materia ponderan respecto del impacto que tiene un desarrollo de sistemas en una
institución. Hay que añadir que este esquema tiene elementos que se concentran en los
aspectos negativos de ese impacto, toda vez que la idea de impacto organizacional está
vinculada al hallazgo del fracaso de un gran número de proyectos. Al final de la jornada,
si un desarrollo fue exitoso, hay un claro impacto positivo en la organización, pero el
dilema, como lo expresó Pardo (2002), se encuentra en los proyectos que fallan y no en
59
los que alcanzan su meta.
Los autores como Avison y Powell, Pardo y Keen encontraron elementos que se
repetían en las historias de proyectos que fracasaron y elaboraron su argumentación a
partir del supuesto que, si se tenían en cuenta esos factores, las posibilidades de tener
éxito en un proyecto de desarrollo de sistemas eran mucho más altas.
La Figura 8 muestra la comparación entre lo que establece el modelo como la guía
a seguir para un desarrollo exitoso y lo que ocurrió en PROFECO.
Figura 8: Comparación de los elementos de un desarrollo exitoso y el caso del SIIP
60
El detalle de los hallazgos es como sigue:
Liderazgo del proyecto
a) El compromiso (commitment) de la alta gerencia, al principio del
proyecto, se construyó a pesar del poco convencimiento de una parte considerable
de los mandos superiores en PROFECO. Tan es así, que el área de Verificación se
mantuvo deliberadamente al margen del proyecto, aunque por razones que van
más allá de lo tecnológico y lo jurídico. La Subprocuraduría Jurídica, por su parte,
tenía la intención de involucrarse lo menos que pudiera o hasta que no tuviera otra
opción, de acuerdo con García (H. García, Comunicación personal, 25 de abril de
2007)
b) El peso del proyecto se inclinó hacia la Subprocuraduría de Servicios y no
se mantuvo vinculado a la cabeza de la institución. Esto tuvo por consecuencia
mantener el liderazgo indispensable para llevar el proyecto a su conclusión, pero
marcadamente a favor de los intereses de un área específica, en vez de la
institución en su conjunto. El estado de cosas llevó a un deterioro en las relaciones
personales de los mandos superiores, que resintieron este aumento del poder de un
área. Los modelos de la literatura suponen que el desarrollo de un sistema tiene la
tendencia a redistribuir el poder y que este problema se tiene que atender desde la
etapa de diseño. Pero este efecto imprevisto del aumento en la posición de la
61
Subprocuraduría de Servicios tuvo no sólo el efecto opuesto a la redistribución de
poder, sino que tampoco pudo imaginarse en la etapa de diseño, a pesar de sus
imperfecciones.
c) PROFECO como institución pudo mantener el liderazgo mínimo
indispensable para concluir el desarrollo del SIIP, a pesar de los cambios
profundos en sus niveles jerárquicos superiores, de acuerdo con Jasso (Á. Jasso,
Comunicación personal, 24 de octubre de 2006). Esto pone sobre la mesa algunos
elementos para discutir el punto que establecen en la literatura sobre el
compromiso de la cabeza de la institución.
Combate a la inercia institucional
a) Como se puede apreciar en las entrevistas, PROFECO no atendió
adecuadamente este tema durante todo el desarrollo. Los esfuerzos principales se
realizaron por medio de la oficina del Asesor Especializado en Recursos Humanos,
que llevó a cabo un programa de “sensibilización al cambio” al que los
involucrados en el proyecto recuerdan con unanimidad por su falta de eficacia,
como mencionan Jasso y Galván (Á. Jasso, Comunicación personal, 24 de octubre
de 2006; N. Galván, Comunicación personal, 23 de noviembre de 2006).
b) La consecuencia no planeada de esta circunstancia fue que la unidad
62
administrativa más involucrada en el desarrollo del SIIP tomó el control y
desarrollara su propio esquema de capacitación. Utilizaron alguno de los
resultados de la capacitación general sobre el cambio y aplicaron distintas
estrategias para sacar adelante la capacitación del personal que iba a usar el
sistema (Á. Jasso, Comunicación personal, 24 de octubre de 2006).
Involucramiento de los usuarios en las etapas de análisis y diseño
a) Unisys no hizo lo suficiente para considerar los elementos sociotécnicos
en su definición de requerimientos. El personal de PROFECO, por su parte, tenía
muy poca experiencia para definir estos últimos adecuadamente (Á. Jasso,
Comunicación personal, 24 de octubre de 2006; N. Galván, Comunicación
personal, 23 de noviembre de 2006).
El problema se puede explicar con claridad. Unisys, después de no encontrar
el eco suficiente en el personal de PROFECO, tomó la decisión de determinar casi
unilateralmente los requerimientos para ese módulo. Al personal de esa empresa lo
motivaban las fechas y posiblemente una genuina aceptación de que ellos sabían
hacer sistemas y los usuarios de PROFECO no tenían la menor idea de ello. Pero
las bases de licitación simplemente decían que el desarrollo tenía que satisfacer al
usuario y ese fue exactamente el argumento que PROFECO utilizó en contra de
Unisys. Su propuesta simplemente no servía para el flujo de trabajo en PROFECO.
63
Y el trabajo tuvo que comenzar de nuevo. Los tiempos, que eran imposibles de
cumplir conforme a las reglas establecidas, se enmascararon detrás de una etapa de
mantenimiento y estabilización notablemente larga (Á. Jasso, Comunicación
personal, 24 de octubre de 2006).
b) Unisys aparentemente no aplicó metodologías para definir los
requerimientos o las aplicó con muy poco rigor. La práctica de documentar el
desarrollo mejoró con el tiempo y con la necesidad de no repetir los errores del
primer año de trabajo (Á. Jasso, Comunicación personal, 24 de octubre de 2006).
c) De igual forma que con el aspecto del liderazgo, se pueden observar dos
grandes momentos en el involucramiento del personal de PROFECO en la
definición de requerimientos. El primero de ellos, justo al comienzo, se caracteriza
por la ausencia y la ignorancia, inclusive de los propios procesos. El segundo,
cuando cambia el centro de gravedad del proyecto, muestra un grado de
participación total del personal de la Subprocuraduría de Servicios, una definición
clara de las metas y los objetivos, lo que llevó a la conclusión exitosa del
desarrollo a pesar de los retrasos.
Control de las presiones del entorno
a) PROFECO y Unisys tuvieron que hacer el sistema básicamente dos veces,
64
por falta de entendimiento y por querer saltarse etapas del plan. El cumplimiento
de fechas de entrega arbitrarias, que no tienen sustento en estimaciones de tiempo
serias, es causa de innumerables problemas y retrasos notorios. La duración de las
etapas de mantenimiento y estabilización son la evidencia más clara de este
problema. Más allá de la rigidez del esquema de cascada del IEEE para desarrollar
sistemas, las consecuencias de no seguir lo establecido en un plan, si este último
está bien hecho, son patentes.
b) Tanto Unisys como PROFECO entendieron aceptablemente rápido que no
sirve de nada apresurar las etapas y que, en realidad, no hay manera de obtener
buenos resultados al saltarse pasos en el proceso de desarrollo. Pero tuvieron que
jugar con la terminología legal que los afectaba a ambos y, en este sentido,
pudieron atenerse a lo estrictamente estipulado en la licitación, mientras ambas
partes corregían sus distintos errores de inicio con el proyecto. No se trataba de un
asunto menor, debido al involucramiento del Órgano Interno de Control y la
Secretaría de la Función Pública, pero el entendimiento en la manera de trabajar al
que se llegó benefició a ambas partes.
El segundo grupo del esquema es el que toma en cuenta una de las tesis centrales
recurrentes en la literatura revisada. El desarrollo de cualquier sistema debe tomar en
cuenta muchos elementos no tecnológicos y que están profundamente relacionados con
el entorno en el que se desenvuelve una institución, sus costumbres, sus relaciones
65
políticas, la distribución del poder y el balance de fuerzas. Esta terminología suele ser
ajena para los ingenieros de software, pero están en el centro de los elementos que, de no
tomarse en cuenta, pueden llevar al fracaso a cualquier proyecto, como quedó
establecido en el marco teórico.
Estudio previo de los procesos
a) Unisys y PROFECO trabajaron en un principio con una visión
simplificada y limitada de los procesos de la institución. No hay la menor duda que
Unisys trabajó de cerca con el personal de PROFECO para conocer los procesos
que debían incluirse en el SIIP. Pero desde el principio hubo factores que
desvirtuaron en gran parte los esfuerzos en esta área. Uno de ellos se detalló un
poco más arriba, con la definición de requerimientos para el sistema. Posiblemente
Unisys —de nueva cuenta, en un terreno especulativo debido a la falta de
evidencia— consideraba que, por lo menos, PROFECO debería tener bien
identificados sus procesos. Nada más lejos de la realidad. En fechas tan tardías
como el segundo semestre de 2007 se pudo tener en PROFECO una
documentación estandarizada de los 70 procesos que hay en la institución, esto es,
seis meses después de concluir el desarrollo del SIIP. Las áreas tenían esquemas
generales que no cubrían los detalles cuya inclusión en el sistema era obligatoria.
Todo indica que Unisys desconocía esta circunstancia.
66
b) PROFECO y Unisys decidieron incorporar todos los procesos de una vez
y no tomar una aproximación más gradual, durante el segundo momento de
liderazgo del proyecto (Á. Jasso, Comunicación personal, 24 de octubre de 2006).
No le servía de nada a la institución tener algunos procesos en el SIIP y otros por
fuera. Esta aceptación llevó a esas ampliaciones de alcances y al movimiento del
calendario.
c) Unisys dio por sentado que la información inicial que obtuvo sobre los
procesos de PROFECO era la necesaria para desarrollar todo un sistema. A partir
de este error se siguen los otros, todos ellos compartidos.
Investigación sobre las mejores prácticas vigentes
a) En PROFECO no se hizo un estudio previo sobre las mejores prácticas
vigentes. (Á. Jasso, Comunicación personal, 24 de octubre de 2006; N. Galván,
Comunicación personal, 23 de noviembre de 2006). La idea de documentar y
referirse a las mejores prácticas no es muy frecuente en gobierno. Las instituciones
de gobierno no compiten con nadie; no hay funciones que tengan competidores
(por ejemplo, no hay dos instituciones de gobierno que atiendan las quejas de los
consumidores) y , por lo tanto, no hay incentivos claros para apegarse una mejor
67
práctica. La adopción de alguna de estas últimas depende, en gran medida, de la
idea personal que el titular en turno tenga sobre la administración de un proceso.
Ocasionalmente, si los procesos en cuestión tienen contacto con el exterior, hay
mayores incentivos para adoptarlas, pero si la cuestión pública a la que se refieren
es estrictamente local, es poco frecuente recurrir a ellas.
b) En el caso del SIIP no hubo rediseño de procesos y todavía no se aprecian
todas las consecuencias de esta circunstancia específica. Los abogados no suelen
imaginar procesos que tengan menos pasos que los actuales. Y tampoco es una
actitud gratuita. Las instituciones de gobierno, a diferencia de las privadas, están
constreñidas a tener sus procesos explícitos en algún instrumento legal, por lo que
tampoco tienen la misma flexibilidad para adaptarse que puede tener una empresa.
Las facultades expresas implican también procesos explícitos que no se pueden
modificar unilateralmente.
c) No se aprovechó la oportunidad de nuevas legislaciones para mejorar los
procesos. Basta un ejemplo. La Ley Federal de Transparencia tiene una serie de
requerimientos cuando se trata del manejo de datos personales. Los encargados de
diseñar los flujos de trabajo para el SIIP no consideraron eliminar peticiones
reiterativas de este tipo de datos, a pesar de la carga adicional de trabajo y
responsabilidad que ello implica. Lo que se hacía de una manera ineficiente en
papel se tradujo a una versión electrónica, aunque con más control, información y
velocidad.
68
Análisis detallado de los flujos de trabajo y estructuras de datos;
reconstrucción de las estructuras de datos
a) Este trabajo lo hizo a conciencia el equipo de la Dirección General de
Informática. La limitación era el estado que guardaba la información en los
sistemas previos al SIIP. La DGI trabajó varios años para rescatar lo posible de los
distintos “sistemas” que había. (N. Galván, Comunicación personal, 23 de
noviembre de 2006).
La cantidad de datos faltantes era muy grande. Buena parte de los retrasos
vinieron a consecuencia de tener que homologar los datos para su traslado al SIIP.
PROFECO, en ese sentido, tiene dos conjuntos de estadísticas. El primero,
que concentra los datos antes del SIIP; y el segundo, que comienza a partir del
término del despliegue nacional del SIIP. Los dos son incompatibles entre sí. Para
la plataforma de información estratégica —actualmente en diseño— no hubo
manera de incorporar de manera confiable datos de PROFECO previos a 2007.
Los resultados con información de años previos tienen lagunas, datos
inconsistentes y series incompletas. Las comparaciones tienen demasiados
supuestos y esa plaga persigue las cifras oficiales de la institución desde el primer
momento.
69
b) Unisys y PROFECO hicieron su tarea en este aspecto, pero la información
preexistente estaba en tan mal estado que prácticamente no hubo impacto en
dejarlas de lado. Todo lo contrario: ya no hay tantas fuentes de datos como
unidades administrativas uno pueda encontrar en la estructura, cada una con cifras
que no cuadran con las de otra. Se trata también de un comienzo fresco en
términos de estadísticas.
Desarrollo de habilidades para el entendimiento común entre usuarios y
desarrolladores
a) Como se pudo apreciar en otros conceptos, hubo dos tiempos en esta
ecuación. Al principio, que es consistente con los problemas en la definición de
requerimientos y en el involucramiento del personal, estas habilidades que forman
un lenguaje común no existían en el caso de PROFECO. Salvo los cuadros
superiores y colaboradores cercanos a la Procuradora Bracho, no había personal en
PROFECO que supiera o tuviera conocimiento sobre el desarrollo de sistemas.
Este corpus de datos, experiencias e información no cobró forma sino hasta el
segundo momento de liderazgo (Á. Jasso, Comunicación personal, 24 de octubre
de 2006). Conforme se pudieron absorber esos elementos, se desarrollaron las
habilidades. Dicho de una manera más simple, el personal en PROFECO tardó dos
años en entender el propósito del SIIP. Cuando fue posible entender para qué iba a
70
servir, los errores de apreciación resultaron demasiado grandes y hubo que rehacer
la plana. De manera virtuosa, la lección aprendida con tantas complicaciones no se
desperdició. Cuando se llevó a cabo el desarrollo del módulo jurídico, toda esta
experiencia acumulada entró en juego y el módulo se hizo más rápido, con menos
errores y con más madurez que el resto del SIIP (Á. Jasso, Comunicación personal,
24 de octubre de 2006; H. García, Comunicación personal, 25 de abril de 2007).
Las personas encargadas de esta tarea llegaron al extremo de tener avances
notables en la explotación de información, lo que no deja de ser un valor para la
plataforma de información estratégica.
El tercer grupo en el esquema se refiere a los efectos profundos que suelen tener
por consecuencia los desarrollos de sistemas, especialmente porque están directamente
relacionados con el uso de la información.
Evaluación de la redistribución de la información
a) En PROFECO no se hizo ninguna evaluación sobre el cambio en los flujos
de información. La definición de requerimientos para inteligencia de negocios se
hizo en las primeras etapas del desarrollo, durante 2003. Aunque se resolvió
aceptablemente la cuestión tecnológica respecto de la compatibilidad de los datos
71
en cada uno de los módulos, en fechas tan tardías como el segundo semestre de
2007, varios meses después del cierre del proyecto, se puso sobre la mesa la
cuestión de la información estratégica. Esto ocurrió a insistencia de la
Coordinación de Asesores, oficina que quedó a cargo de esta plataforma a partir
del mes de mayo de 2007. Los análisis sobre esos datos comenzaron en agosto del
mismo año y constituyen un proyecto que tardará todavía un par de años en
completarse.
b) El desarrollo del SIIP no contempló la redistribución de la información y
Unisys se limitó a cumplir las exigencias de reportes que le hizo la
Subprocuraduría de Servicios.
Es importante recordar uno de los puntos específicos que mencionaba Keen a
propósito de la inercia institucional. La información no es simplemente un
producto intelectual sino un recurso político, cuya redistribución a lo largo de un
sistema de información nuevo afecta los intereses de grupos particulares. Como
menciona Keen (1981), el procesamiento humano de información tiende a ser
simple, empírico, no analítico y, de manera general, poco efectivo. En
consecuencia, los sistemas formales de información son vistos como una amenaza
y algo que no se necesita. Son una invasión del mundo de los usuarios que ven sus
características novedosas como una crítica para ellos mismos.
Para los cuadros superiores de PROFECO se ha tratado de una gran verdad
porque, en general, el flujo de información hacia el titular de la institución pasa
72
por el filtro de la jerarquía en la que el nivel inmediato inferior sólo informa lo que
le conviene o prefiere que vea el nivel superior. De esta manera, el titular sólo
conoce la información que su jerarquía quiere que conozca, lo que demuestra
claramente la inercia institucional que menciona Keen. La información es un bien
político y no se comparten los datos porque se convierten en una crítica a quienes
los poseen.
Sin embargo, los cambios que puedan introducirse en esta manera de
entender las cosas son pausados, dado que no todos los procesos institucionales
están dentro del SIIP y la información de todos ellos se deben incorporar
gradualmente a la plataforma de Oracle para permitir su procesamiento en las
herramientas de inteligencia de negocios.
Evaluación de la redistribución del poder dentro de la estructura
a) En PROFECO no se evaluaron los efectos de la redistribución de poder
(Á. Jasso, Comunicación personal, 24 de octubre de 2006). El desarrollo del SIIP
resintió constantemente los cambios de personal, especialmente los de nivel
directivo, porque cada uno de ellos traía nuevas definiciones, nuevos
requerimientos, nuevos ajustes, lo que retrasaba el avance del proyecto.
73
Evaluación de la redistribución de la toma de decisiones
a) No hay evidencia de que en PROFECO haya analizado la redistribución
de la toma de decisiones. Pero aquí es importante hacer un comentario. En
Gobierno no funciona de igual manera la toma de decisiones que la iniciativa
privada o la industria. La toma de decisiones no se mueve conforme al modelo
sólo porque haya un redistribución de los datos. Es muy cierto que los jefes de
departamento están comenzando a tener mayor información en sus manos, pero el
marco institucional y las jerarquía rígidas todavía son un cerco importante para
este reacomodo. Todavía las decisiones minúsculas de operación pasan por los
escritorios de los directores, en vez de estar delegados en otros niveles jerárquicos.
Y en esta ecuación hay muy poca atención a los elementos que Gurbaxani señaló
en su esquema. PROFECO no tiene un esquema de costos para la toma de
decisiones y no los resiente por las mismas razones que se expusieron sobre el
mapeo de los procesos. La decisión es el acto supremo de la autoridad y no se trata
de una actividad propiciadora del negocio, como se entiende en la literatura sobre
el tema.
Todos los elementos anteriores permiten responder a las primeras dos preguntas de
investigación. Como lo muestra la Figura 8, sí hubo un impacto organizacional al
desarrollar el SIIP y se caracteriza de esa manera.
74
Nuevas variables para explicar el caso del SIIP
La siguiente pregunta de investigación plantea si hubo diferencias entre el
esquema propuesto y los resultados encontrados en el caso de estudio.
Conforme al esquema de la Figura 8, el impacto organizacional de desarrollar el
SIIP habría sido tan grande que su fracaso era el único resultado posible. El esquema, sin
embargo, no proporciona ninguna escala o graduación ni tampoco una manera de
evaluar el camino que llevó al SIIP a tener un impacto organizacional alto.
El hecho que no se puede explicar con el esquema es que el SIIP se encuentra
operando actualmente y sus administradores están contemplando la incorporación de
nuevos módulos y servicios para la plataforma. Entonces, la pregunta es ¿por qué no fue
un fracaso?
El desarrollo del SIIP expone tanto la necesidad de ajustar el modelo para mejorar
su capacidad heurística como la gran distancia que hay entre encontrar elementos para
una explicación y elaborar un modelo que explique un fenómeno. Como todo avance en
ciencia, es inevitable pasar por un conjunto de pruebas y errores que permitan ajustar los
términos del modelo y lograr con eso explicaciones cada vez más precisas.
El primer hallazgo de esta investigación fue encontrar que, en términos generales,
el desarrollo del SIIP cumplió con casi todos los errores posibles que se señalan en la
literatura y que habrían garantizado su fracaso. En este sentido, el modelo original
75
únicamente sirve para decir que el desarrollo SIIP tuvo un gran impacto organizacional
en PROFECO. El argumento siguiente era señalar que, como consecuencia de lo
anterior, el proyecto habría fracasado. Pero el proyecto encontró la manera de concluir
de una manera exitosa. Esto pone sobre la mesa una discusión muy interesante.
La última pregunta de investigación se refiere a nuevos elementos que pudieran
encontrarse en el caso de estudio. La diferencia con el esquema original señalada
anteriormente proporciona la oportunidad adecuada para esbozar una modificación al
modelo que, con base en la literatura sobre el impacto organizacional, explique la
situación del SIIP, incorpore los hallazgos mencionados y sirva como una herramienta
para medir mejor el impacto que tiene un desarrollo de sistemas en una organización.
En la revisión de la literatura sobre el impacto organizacional ha quedado claro
que hay una relación entre los elementos señalados en la Figura 8 y el éxito o fracaso de
un proyecto de desarrollo de software.
Esta relación, enunciada en el marco teórico, proporciona dos puntos extremos,
apenas un principio y un final. Pero esa esquematización es algo rígida y no explica el
caso del SIIP. Básicamente, establece que un desarrollo de software será exitoso si se le
añade la dosis adecuada de liderazgo y se cuidan los elementos sociotécnicos. Por el
contrario, si no se atienden esos elementos, el proyecto fracasará con toda probabilidad.
El gran mérito es vincular estos dos conceptos. Por mencionar la importancia,
Mahmood y Mann (1993) señalan que hay muy pocos estudios que vinculen el
desarrollo de la infraestructura tecnológica con el impacto organizacional.
76
Es válido entonces hacer un ejercicio y extenderse sobre las posibilidades del
modelo, con el objeto de explorar conceptualmente qué pasaría si se incorporaran otras
variables como las que se encuentran en el caso del SIIP.
En la Figura 9 se puede apreciar el primer paso de esta conceptualización. La
relación entre el impacto organizacional y el éxito de un proyecto de desarrollo de
sistemas se establece en la curva, de modo tal que a mayor impacto organizacional, es
menor el éxito del proyecto. Aquí se sigue la argumentación del modelo original,
representada por las posiciones del caso fracasado (A) y el caso exitoso (B)
respectivamente.
Figura 9: Relación entre impacto organizacional y éxito de un proyecto de desarrollo de sistemas
77
El caso del SIIP claramente pone de manifiesto que es necesario incluir más
elementos en el análisis, toda vez que se trata de un caso donde el proyecto tiene éxito
de manera moderada a pesar de su altísimo impacto organizacional, como se puede
apreciar en la Figura 10.
Figura 10: Ubicación del caso del SIIP en la relación impacto organizacional vs éxito del proyecto
Para poner el modelo original en movimiento hay que empezar a jugar con los
elementos. En primer lugar, si se mide el cuidado con el que la directiva de una
78
institución atiende (es decir, aprecia) los aspectos de liderazgo del proyecto, cambios en
la redistribución de poder, planeación adecuada, etc. y lo trasladamos a la gráfica, se
puede introducir un elemento de apreciación del impacto organizacional por parte de la
directiva de la institución, como se puede ver en la Figura 11.
Figura 11: Introducción de la apreciación del impacto organizacional
La inclinación de este eje tiene que ver con la calificación de esa apreciación. Si
una directiva le concede gran importancia a los factores del éxito y los trata en
79
consecuencia, la inclinación bajará hacia el eje donde medimos el éxito. Si, por el
contrario, esta apreciación es muy ligera o limitada, la inclinación aumentará hacia el eje
donde medimos los costos. La Figura 12 muestra estos cambios en la inclinación.
Figura 12: Cambios en la inclinación del eje de apreciación
La introducción de esta variable al modelo permite mover el eje de apreciación
hasta encontrar el caso del SIIP, como se ve en la Figura 13.
80
Figura 13: Ubicación del caso del SIIP con el cambio en la inclinación del eje de apreciación del impacto
Como lo señalan Jasso y Galván Zamora (Á. Jasso. Comunicación personal, 24 de
octubre de 2006 y N. Galván Zamora, Comunicación Personal, 23 de noviembre de
2006) en PROFECO hubo poca consideración por los elementos que determinan el
impacto organizacional. De esta manera, la inclinación del eje aumenta hasta estar
acorde con la ubicación del caso del SIIP. Sin embargo, este punto todavía está lejos de
la curva que establece la relación entre impacto y éxito. Todavía falta incluir un
81
elemento para que la explicación sea completa y el modelo funcione.
Una vez resuelta la cuestión de cómo aprecia la directiva el impacto
organizacional, hay que detenerse en la sensibilidad que tiene una organización respecto
del impacto organizacional. El caso del SIIP muestra una evidencia muy sorprendente.
Hay organizaciones, especialmente en el gobierno, que pueden ignorar o dejar de lado el
impacto que un desarrollo puede tener en su organización. No importa si en el proceso
se pierden miles de personas o si se redistribuye el balance de poder entre las distintas
unidades administrativas. El proyecto concluye exitosamente a pesar de su impacto. ¿Por
qué?
Las empresas tienen un punto de partida muy diferente que una institución de
gobierno a la hora de plantearse un desarrollo de sistemas. Tiene que usar un
presupuesto que proviene de sus ganancias, esperan un retorno muy concreto de su
inversión en el menor tiempo posible, lo que se manifiesta en el calendario de entregas
del proyecto. En principio, se preocupa de no perder capital humano a causa del
desarrollo y trata de reubicar al personal en otras funciones. En el caso de gobierno, el
presupuesto no depende de las ganancias o el desempeño, sino del dinero que el
Congreso le adjudique en el presupuesto global. Normalmente es cuando menos igual al
del año anterior. El retorno está más orientado a las ganancias políticas que resultados
concretos de gestión, el calendario de desarrollo varía con frecuencia (y conveniencia) y
no hay competencia en el mercado que presione para acelerar los resultados, como se
aprecia en línea de salir a operación sin que el sistema se encuentre completamente
82
estabilizado (Á. Jasso, Comunicación personal, 24 de octubre de 2006). El capital
humano, a pesar de su importancia, es reemplazable por la siempre abundante demanda
por puestos públicos.
Todo lo anterior es evidencia muy clara que la empresa y el gobierno responden de
manera distinta a las exigencias de su entorno. Esa respuesta se mide como sensibilidad
al cambio organizacional. En términos de la conceptualización, los cambios de la
sensibilidad se manifiestan en el traslado de la curva a lo largo del eje de la apreciación,
como se puede ver en la Figura 14.
Figura 14. Movimiento de la curva de relación impacto vs éxito debido al efecto de la sensibilidad al impacto
83
Entonces, finalmente, encontramos el punto en el que se cruzan todas las variables
y el caso del SIIP. Es el punto donde convergen la poca apreciación del impacto
organizacional, la baja sensibilidad a este impacto, que arroja como resultado un
desarrollo exitoso a pesar de la magnitud del impacto organizacional, exactamente en la
ubicación donde esperaríamos que estuviera el caso del SIIP. La Figura 15 muestra este
resultado.
Figura 15. Incorporación de todas las variables y la ubicación del caso del SIIP en el modelo
84
El modelo propuesto demuestra que hay una forma racional de acomodar las
variables de manera que todas estén relacionadas entre sí. No hay datos fuera del
esquema, como ocurrió con la primera comparación entre el SIIP y el modelo original.
Este modelo contempla la explicación del problema desde un punto de vista
conceptual y partir de los elementos que sugiere la evidencia del desarrollo del SIIP. En
este sentido ayuda a responder a las inquietudes de saber por qué a PROFECO no le
afectaron tanto los elementos que habrían hecho fracasar el desarrollo del SIIP, y por
qué PROFECO tampoco resintió demasiado su propia falta de atención al “paquete
sociotécnico” y los demás elementos. La primera inquietud se atiende con la idea de la
sensibilidad al impacto organizacional mencionada antes y la segunda mediante la idea
de la apreciación consciente de la directiva del proyecto sobre los elementos del impacto
organizacional.
Estos dos aspectos, como si fueran las partes conscientes e inconscientes de un
mismo problema, son los que ponen en movimiento y concilian las variables que
menciona la literatura y aparecen en la evidencia del SIIP. Pero escapa del alcance de
este trabajo desarrollar las métricas específicas para corroborar los resultados. El modelo
es, finalmente, una hipótesis elaborada a partir de una observación para explicar el éxito
de un desarrollo de sistemas a pesar del alto nivel de impacto organizacional.
85
CAPÍTULO 5
CONCLUSIONES
A) Hallazgos principales
La figura 16 muestra una síntesis de la comparación entre los puntos principales
propuestos por el modelo y los resultados obtenidos en el caso del SIIP.
Figura 16: Síntesis de la comparación de los elementos de un desarrollo exitoso y el caso del SIIP
86
Como se puede observar, lo primero que resalta el la gran cantidad de valores
negativos que hay en el caso del SIIP. Estos valores negativos muestran que en la
PROFECO hubo un impacto organizacional muy considerable al desarrollar el SIIP. De
acuerdo con el modelo, la expectativa normal con estos resultados era que el desarrollo
fracasara.
El impacto organizacional en PROFECO se caracterizó por elementos en el
liderazgo que abren la puerta a discusiones sobre los límites del concepto o la necesidad
de establecer mejores categorizaciones; un manejo del cambio inadecuado; poca o nula
investigación sobre mejores prácticas; conocimiento deficiente de los propios procesos;
y poco o nulo análisis sobre los cambios que implicaba la redistribución de poder en el
sistema y en los flujos de información.
A pesar de lo anterior, el desarrollo del SIIP concluyó y el sistema se puso en
marcha, lo que constituye la medida más elemental de éxito. Esta situación abre la
puerta para incorporar nuevos elementos que expliquen la ubicación del caso del SIIP
dentro de lo esperado en el modelo.
En la evidencia disponible sobre el SIIP debía haber elementos capaces de ampliar
la explicación del modelo. El análisis de la información mostró que la PROFECO
resintió los efectos del impacto organizacional de una manera diferente a la prevista en
el modelo. Las entrevistas a los distintos funcionarios mostraron que la institución, a
pesar de incurrir en grandes costos, continuó con las tareas del desarrollo hasta llegar a
87
término. Esto indica claramente que PROFECO tiene una sensibilidad menor al cambio
y que por eso pudo resistir los efectos nocivos de sus fallas y errores en la medida
suficiente para concluir el proyecto y ponerlo en marcha.
La evidencia encontrada en las entrevistas también permite señalar que los
elementos directivos de una organización tienen una influencia importante sobre el
impacto organizacional en la medida que son más o menos conscientes sobre cómo
afectará un desarrollo de sistemas a la organización. Dejando de lado la discusión sobre
el liderazgo, cuando menos uno de los mandos superiores de la PROFECO tenía bajo
control el proceso de desarrollo del SIIP, aunque esto fuera parte de una agenda personal
y tuviera como consecuencia el aumento de la influencia de una unidad administrativa
sobre las otras. Esto tuvo como consecuencia que el impacto organizacional estuvo
contenido hasta el término del proyecto y parte del costo se trasladó a otras áreas, no
directamente involucradas con el desarrollo del sistema. Esta variable se enuncia como
apreciación del impacto.
Al incorporar las dos variables, sensibilidad y apreciación, al modelo de impacto
organizacional previsto en la literatura, se explica adecuadamente el caso del SIIP.
Ambas variables mitigaron el efecto del impacto organizacional en PROFECO y
permitieron a la institución concluir el proyecto y ponerlo en uso.
Esta ampliación propuesta al modelo de impacto organizacional es una hipótesis
muy atractiva porque, de confirmarse la validez de los nuevos supuestos y de
establecerse las métricas adecuadas, se puede convertir en una herramienta o una técnica
88
que permita a los desarrolladores de sistemas medir la posibilidad de éxito de un
proyecto dentro de una organización.
Esto tiene una incidencia directa en el problema que mencionaba Pardo (2002)
sobre la abundancia de los fracasos en el desarrollo de sistemas de información y que
afecta enormemente a esta industria.
Un comportamiento que no contempla el modelo es cuando a una organización
simplemente no le importan los costos, el tiempo o las modificaciones estructurales para
llevar a cabo un proyecto, además de tener problemas de todo tipo a lo largo de todo el
proyecto. Los elementos hallados en la evidencia apuntaban hacia un fracaso en el
desarrollo y el SIIP hoy está funcionando y se utiliza en todas las oficinas regionales de
la PROFECO, lo que es la medida más elemental de éxito de un sistema.
En resumen, PROFECO tuvo la mayor parte de los impactos organizacionales
contemplados por la literatura y, sin embargo, fue capaz de llevar su proyecto a término.
Esto abre la puerta para discutir cómo se debe medir el impacto organizacional y si hay
otros factores que deben tomarse en cuenta en el modelo.
El modelo original no contempla graduaciones distintas de cualquiera de los
elementos identificados como críticos para el éxito. En el caso de PROFECO, por
ejemplo, hubo una ruptura de este liderazgo, un traslado de la responsabilidad del
desarrollo hacia un cuadro jerárquico inferior y, de todas maneras, se completó el
sistema. Esto lleva a discutir el mínimo de liderazgo que se necesita para llevar el
proyecto a buen término y no solamente “liderazgo” a secas. El ajuste propuesto al
89
esquema original le proporciona movimiento a los que eran valores estáticos. Lo
atractivo es que se pueden incluir, en principio, los ejemplos de cualquier tipo de
organización y salvar la brecha que hay entre comprender proyectos en la industria y
proyectos de gobierno.
B) Futuras investigaciones
Algunas tareas de investigación que pueden seguirse a partir de este punto, toda
vez que la evidencia apunta a la necesidad de obtener mejor información sobre lo que se
hace en nuestro país a propósito del desarrollo de sistemas.
A. Llevar a cabo investigaciones de otros casos de desarrollo de sistemas, tanto
exitosos como fracasados, para comprobar si el modelo enunciado es capaz
de sostener sus premisas.
B. Desarrollar las métricas que podrían medir las variables señaladas en el
modelo propuesto.
90
C. Si nuevas investigaciones establecieran que el modelo es capaz de explicar el
éxito o fracaso de un desarrollo de sistemas, habría que desarrollar un
coeficiente que permita medir la posibilidad actual de éxito o fracaso en un
momento dado en cualquier proyecto de desarrollo de sistemas.
91
REFERENCIAS
Asociación Mexicana de Internet (AMIPCI). (2007). Usuarios de Internet en México
2007. Recuperado el 27/02/2008 en www.amipci.org.mx
Avison, D., Fitzgerald, G., & Powell, P. (2001). Reflections on information systems
practice, education and research: 10 years of the Information Systems Journal.
Information Systems Journal, 11, 3-22.
Banker, R. D. & Kauffman, R. J. (2004). The Evolution of Research on Information
Systems: A Fiftieth Year Survey of the Literature in Management Science.
Management Science, 1-40.
Crea Profeco buró de información commercial (2006, 19 de mayo). El Universal,
Finanzas. Recuperado el 18/04/2008 en www.eluniversal.com.mx
Davis, G. B. (1999). The Blackwell encyclopedic dictionary of management information
systems. Malden, Mass: Blackwell Business.
Eckerson, W. W. (2006). Performance Dashboards. Measuring, Monitoring and
Managing your Business. Hoboken, New Jersey: John Wiley & Sons.
Fuxman, A., Giorgini, P., Kolp, M., & Mylopoulos, J. (2001). Information Systems as
Social Structures. ACM, 10-21.
Gurbaxani, V. & Whang, S. (1998). The Impact of Information Systems on
Organizations and Markets. Communications of the ACM, Enero 34(1), 59-73.
92
Hernández Sampieri, R., Fernández Collado, C., & Baptista Lucio, P. (2006).
Metodología de la Investigación (Cuarta ed.). México: McGraw-Hill.
Hilbert, M. & Katz, J. (2003). Building an Information Society: a Latin American and
Caribbean Perspective. Santiago, Chile: CEPAL. Economic Comission for Latin
America and the Caribbean.
Keen, P. G. W. (1981). Information Systems and Organizational Change.
Communications of the ACM, Enero 24(1), 24-33.
Mahmood, M. A. & Becker, J. D. (1985). Impact of Organizational Maturity on User
Satisfaction With Information Systems. ACM, 5, 134-151.
Mahmood, M. A. & Mann, G. J. (1993). Measuring the organizational impact of
information technology investment: An exploratory study. Journal of
Management Information Systems, 10(1), 97.
Pardo, T. A. & Scholl, H. J. (2002). Walking Atop the Cliffs: Avoiding Failure and
Reducing Risk in Large Scale E-Government Projects. Paper presented at the
Proceedings of the 35th Hawaii International Conference on Systems Sciences.
Patel, D. (2002). Problems, Solutions and Information Systems Development. Paper
presented at the Proceedings of the First IEE International Conference on
Cognitive Informatics.
Power, D. J. A Brief History of Decision Support Systems. version 4.0. Recuperado el
10/03/2007, en http://DSSResources.COM/history/dsshistory.html
93
Procuraduría Federal del Consumidor. (2004a). Ley Federal de Protección al
Consumidor. México: Procuraduría Federal del Consumidor.
Procuraduría Federal del Consumidor. (2004b). Reformas a la Ley Federal de
Protección al Consumidor. Manejo de la comunicación institucional. Mensajes
clave. México: Procuraduría Federal del Consumidor.
Procuraduría Federal del Consumidor. (2006a). Informe de Labores 2005. México:
Procuraduría Federal del Consumidor.
Procuraduría Federal del Consumidor. (2006b). Sistema Integral de Información y
Procesos SIIP. Libro Blanco. México: Procuraduría Federal del Consumidor.
Procuraduría Federal del Consumidor. (2007). Informe de Labores 2006. México:
Procuraduría Federal del Consumidor.
Project Management Institute. (2004). Guía de los Fundamentos de la Dirección de
Proyectos (Guía del PMBOK) (Tercera ed.). NewTown Square, Pennsylvania:
Project Management Institute.
Rayward, W. B. (1995). The Noble Brow of History: The History and Heritage of
Science Information Systems. American Society for Information Science. Bulletin
of the American Society for Information Science, Enero 25(2), 19-22.
Robey, D. (1981). Computer Information Systems and Organization Structure.
Communications of the ACM, Octubre 24, 679-687.
Senn, J. A. (2005). Análisis y diseño de Sistemas de Información (Segunda ed.). México:
McGraw-Hill.
94
Straub, D. W. & Wetherbe, J. C. (1989). Information Technologies for the 1990's: An
Organizational Impact Perspective. Communications of the ACM, November
32(11), 1328-1339.
The Institute of Electrical & Electronics Engineers. (1990). IEEE Standard Glossary of
Software Engineering Terminology (Std 610.12-1990 ed.). Nueva York: The
Institute of Electrical & Electronics Engineers.
The Institute of Electrical & Electronics Engineers. (1990). IEEE Standard Glossary of
Software Engineering Terminology (Std 610.12-1990 ed.). Nueva York: The
Institute of Electrical & Electronics Engineers.
Yahya, A. H. (1993). On the Problems of Information Technology Management in
Developing Nations. ACM, 4, 349-355.
95
APÉNDICES
Apéndice A
Entrevista a la Lic. Ángeles Jasso, Coordinadora de Proyectos de la
Subprocuraduría de Servicios, en la PROFECO
24 de octubre de 2006
Rodrigo Romo 00:00
Mi tesis es precisamente el caso de estudio del SIIP. La experiencia de haber estado cerca del SIIP cerca de seis años no la quiero desperdiciar. Me parece un asunto extremadamente atractivo porque tienes una institución modesta, para decirlo de una manera no agresiva, que de repente salió de la nada y se aventó a decir "yo quiero un sistema grande". Y sin tener el menor conocimiento, como institución, de lo que significaba desarrollar una sistema, a trompicones lo fue sacando. Y al final del día, obtuvo algo. Aprendió algo. Eso es justo la experiencia que quiero retratar. La única pregunta que sí me gustaría empezar haciendo es tú cómo llegaste al SIIP Ángeles Jasso 01:36
¿Por qué llego yo al SIIP? Llego a PROFECO en agosto de 2003. Mi función iba a ser particular de la Subprocuradora. Ve mi curriculum y yo tenía una Maestría y no tenía experiencia en administración pública. Después trabajé en la universidad virtual del ITESM. Yo sí tenía el perfil de "quiero trabajar en el gobierno". Era algo para mi que yo tenía que hacer. ¿Cuándo salí de la Maestría? Llego a PROFECO y me avisan que estoy en PROFECO pero como un tipo de asesor del Coordinador de Proyectos, que era Rafael. Para sacar todos los proyectos que tenía la Subprocuraduría. Rodrigo Romo 02:58
De acuerdo. Rafael entonces estaba abrumado, para decirlo de una manera sencilla. Ángeles Jasso
96
03:05
Sí. Lo que hacemos ahora seis gentes lo hacía él sólo en un principio. Entonces, entro y el primer proyecto que me dan son las conferencias telefónicas y organizar los talleres de mejora de algo que le llamaban SIIP, cualquier cosa que ésta fuera. Me pide Gabriela que haga algunas presentaciones, hago las presentaciones y se da cuenta que tengo un perfil más fácil con las computadoras, después de venir del ITESM, etc. Entro, hago las conferencias, las presentaciones, se las explico a los directores y directores generales, en ese entonces a la misma procuradora, delegaciones. Hago todo esto y aparte empiezo a llevar los asuntos que tenían que ver con todas las áreas y me empiezo a relacionar, por los temas, con los directores y empiezo a conocer la problemática de las direcciones dichas por las direcciones. Y hago un puente de comunicación entre lo que piensa la delegación y lo que le contesta oficinas centrales. Abro ese canal de comunicación con todos los jefes de servicio, porque yo era la que estaba en las conferencias telefónicas y servía de moderador. Esto me hace ver, en general, la problemática de operación de las delegaciones.Tomando ya ese perfil y que no me eran tan indiferentes las computadoras, había realmente un problema en las comunicación entre los programadores y los usuarios y eran batallas campales de dos a tres horas. Verdaderamente batallas porque uno sacaba la Ley y el otro lo que podía hacerse. Rodrigo Romo 05:36
No había manera de entenderlos. Ángeles Jasso 05:36
No había. Me piden que organice nada más las pruebas alfa 1, alfa 2 y en ese entonces estaba el DAT?, que era el grupo director del proyecto, con los asesores externos. Rodrigo Romo 05:58
La gente de San Francisco, ¿no? Ángeles Jasso 05:58
Exactamente. Ellos también tenían choques con los usuarios. Rodrigo Romo 06:13
Las razones normales, las evidentes. El estilo de mando a larga distancia, muy complicado, ¿no? Ángeles Jasso 06:22
A mí en lo particular no me quedaba claro quién eran unos y otros. Ya después, como por enero (2004) me vengo a ubicar que los de San Francisco trabajaban para PROFECO y eran empleados de PROFECO. Yo pensé que eran de Unisys. Eso no
97
importa, fue una confusión por la que pasé. Imaginé que era por la cantidad de desacuerdos que llevaban las áreas, entre unos y los otros. Hay un problema en el que los usuarios no le estaban dedicando el tiempo al sistema. Obviamente por la carga de la operación diaria. Y pues, obviamente, por el coto de poder y de información que te brindaba tener nada más tú el conocimiento y nadie más tenerlo. ERa necesario romper con esa dinámica y la Subprocuradora decide sacarme de lo que yo estaba haciendo para entrar al SIIP, para que hubiera alguien que pudiera decir en qué status estaba el proyecto, tanto del lado del usuario como del proveedor, del consultor. Y que conociera la operación, y dar una opinión jurídica sobre la secuencia de los pasos en el sistema. Hay que llegar a un punto medio. Ése fue mi papel. Entré a todos los flujos, absolutamente a todos. Y los conocía porque los había escuchado en reiteradas ocasiones en las conferencias. Me meto al tema, empiezo a relacionarme con los ingenieros y era dueña de un módulo, que era el de modificaciones, porque era la principal problemática que enfrentamos cuando llegamos. Entonces, cuando voy a la primera prueba alfa 1, veo que el consultor está diciendo una cosa, el usuario está diciendo otra, y nada más no se entendían. Me levanté y les dije "lo voy a poner en un diagrama y creo que así vamos a poder entendernos los dos". Y se los dibujé. "Éste es el paso A, el paso B y el paso C". "Éso es lo que yo necesito. ¿Cómo lo hago? No lo sé. Pero éste es el flujo que yo necesito tener en el sistema. Ok. Ya entendimos. Me empiezo a relacionar con la gente de Unisys y les empiezo a explicar y a empezarles a traducir. Y los de Unisys me adoptan --Por favor no nos dejes-- y me dieron el control. La Procuradora y la Subprocuradora me dieron el control. Rodrigo Romo 09:56
Ése es un punto importante. Ángeles Jasso 09:56
Y tuve que entrar y poner, digamos, el orden necesario para que sucedieran las cosas. Se programaban las reuniones, los usuarios no asistían, los consultores no asistían a la hora, no se ponían de acuerdo, tenían horarios diferentes. Tuve que llegar a negociar con ellos. Ellos comen entre las 1300 y las 1400. (En PROFECO, el horario es de 1500 a 1600) Hagamos los horarios de comida de 1400 a 1600, porque verdaderamente era un caos por los horarios. Lo logramos, empezaron a hacerse las reuniones y viene toda una reingeniería cuando terminamos el alfa 3, porque como nadie se había metido realmente a ver qué estaba pasando, todo mundo decía "Sí", cuando llegamos al alfa 3, vienen los consultoresy dice, para hacerle una presentación a la procuradora, de un prototipo, y vemos que no hay un workflow integrado, lo cual nos trajo un trabajo adicional --y el beta iniciaba el 2 de febero y era 28 de enero--.Todo el trabajo, los directores se opusieron a hacer algo así, se tuvo que negociar con Unisys sin tocar las bases. "Yo no te pedí esto", pero los usuarios lo aprobaron, pero los usuarios no tenían el conocimiento de la herramienta. Y ahí es cuando entro con más ímpetu. A realmente ver que la herramienta hiciera lo que los usuarios querían, no lo que le hicieran creer al usuario que ya estaba listo.
98
Ángeles Jasso 12:17
En el inter, se publican las reformas a la Ley. Como si no fuera suficiente, salen publicadas las reformas a la ley, las cuales no podíamos incluir en el esquema hasta que no estuvieran publicadas y se tiene que hacer un trabajo de todas las plantillas para poder ajustar los cambios, que nos traían flujos nuevos, atribuciones nuevas, procesos nuevos, actualizaciones de contratos, entra la dirección de Contratos de Adhesión a la Procuraduría, por lo tanto, entra al SIIP, se queda un poco rezagado lo de jurídico, porque jurídico lo incluía todo el flujo y empiezan a meter otros flujos como supervisión, promecabise, atención de inconformidades, y empieza hacerse de un flujo pequeño, a flujos y más flujos que eran necesarios para la operación. Porque no podíamos dejar la operación de una queja y todo lo demás manual. Rodrigo Romo 13:38
Tú entraste ya cuando el SIIP estaba echado a andar, en el sentido de empezar con lo que había disponible. Una de las grandes preguntas que siempre he tenido es ¿por qué no se adoptó un enfoque más gradual? ¿Por qué, si tú no tenías a una PROFECO o ala gente de PROFECO lista para desarrollar un sistema así, por qué no adoptaste un enfoque intermedio y empezaste por diseñar pequeños procesos en sistemas pequeños, susceptibles de integrarse después, para transmitirles un conocimiento mínimo de qué significa tener y trabajar en un sistema, antes de aventarse a una cosa tan cara, tan complicada, tan difícil de desarrollar como el SIIP. Ángeles Jasso 14:43
Yo tengo mi punto de vista. Cuando uno lo conceptualiza uno ve "Vamos a hacer el flujo de la queja y la conciliación". Solamente hacer esas dos cosas implicaba una serie de ramificaciones impresionante. Porque qué pasaba si el proveedor venía o no venía, si el consumidor venía, se notificó, no se notificó, da convenio, no da convenio. Eran una serie de combinaciones y resultados que te podían llevar a caminos completamente distintos, que ya estaban y se tenía pensado meter en un sistema. Pero qué pasa cuando una vez que ya conoces la herramienta y preguntas qué más me puede dar. Y empezamos entonces a ver que íbamos a dejar cosas manuales. Me refiero manuales a que se tenían que atender fuera del sistema. Una de las cosas que se planteó en el sistema es que todo tenía que estr dentro del sistema, porque ya teníamos el antecedente del SISEQ, que cosas que se atendían fuera del sistema jamás entraba al sistema. Rodrigo Romo 16:11
Exactamente. Sin control. Ángeles Jasso 16:11
No queríamos que para lo mismo. Yo cuando ya llego y empiezo a tener este
99
dilema. Lo meto o no lo meto. Era adentro o fuera. Si lo dejas afuera, va a ser manual. ¿Sabes cuándo lo van a meter? Nunca. Entonces te va a dar un resultado a medias. Va a ser mucho trabajo. Vas a volver a salir a un desarrollo nacional, para volver a salir, no hay el tiempo, el presupuesto y los recursos para poder volver a hacer algo así, con un periodo de tiempo de un año. Entonces, qué vamos a hacer. Mételo. Lo tienes que meter. De verdad lo que tengo que meter. Y tienes que sacar una versión 1. Si tú no logras sacar una versión 1, el proyecto no funciona. Sí se dejaron cosas para después, como el Módulo de Contatos de Adhesión, como el Módulo de Jurídico, la cumplimentación, pero uno cree que se pueden ir uniendo como que fácilmente. En mis dos experiencias de unir contratos de adhesión y jurídico a lo que ya había, fue espantoso. Porque aunque uno piense que es como que muy sencillo hacer que empate con lo que ya había, no es cierto. Rodrigo Romo 17:54
¿Pero por qué no era compatible? Vamos, debía haber, o quiero imaginarme que se determinó la compatiblidad de las plataformas, de la estructura. Ángeles Jasso 18:09
La plataforma era la misma. ¿Cuál fue el problema? Lo desarrolló gente distinta. Eso sí causó un verdadero problema. Rodrigo Romo 18:18
¿Unisys no estaba usando una metodología? Ángeles Jasso 18:20
No hubo una metodología. Deja tú. Hubo una metodología para revisar algo. Llegaba alguien nuevo y lo volvía a cambiar. Llegaba un equipo nuevo de Unisys, porque los que hicieron el nuestro no podían desarrollar el de jurídico porque realmente necesitaban terminar el nuestro, y aún así dentro de la misma empresa, del subcontratista, hubo cinco consultores distintos. Cada uno lo hizo distinto. Ya cuando llegamos a querer hacer lo mismo todos, ya estábamos muy adelantados. Por qué, porque faltó esa visión integral desde el principio. "A mí no me importa. Tú y tú lo hacen así". Había un roce muy fuerte entre las áreas. Y esos tipos no se hablaban. No trabajaban juntos. Y en eso, no te queda otra. O trabajas juntos o trabajas juntos porque no voy a hacer un procedimiento para ti y otro para él. NO lo voy a hacer. Llegamos a salvar esa parte de los procesos comunes. Pero la lógica de cada uno. Te doy un ejemplo. Tienes la asesoría, en solicitudes de servicio, queja, conciliación domiciliaria, conciliación personal y conciliación telefónica, seis solicitudes de servicio distintas. Para PIL solo hay una. Y tienen lógicas muy distintas. La conciliación es mucho más dinámica y el PIL es muy lineal. Entonces luego luego se ve quién hizo qué, tanto en personas de PROFECO como en personas de los consultores. Rodrigo Romo
100
20:13
Ahora. Viene la otra pregunta entonces. ¿Y quién estaba haciendo reingeniería de procesos en PROFECO? Porque un punto clave en esta historia es tú no puedes convertir en electrónico lo que estás haciendo el día sólo por el mismo hecho. O sea, tienes que pensar en si voy a pasarme a un sistema distinto, qué muevo y ajusto de mi proceso. ¿Qué cosa tendría que cambiar de normativas, qué cosas cambio de mi manera de pensar, cómo ajusto para sacarle el mayor provecho y disminuir el número de pasos? Ángeles Jasso 20:51
Eso se empieza a hacer desde que llegó Gabriela. No había una normatividad de la Subprocuraduría. Se encontraron 480 documentos que se recopilaron de todas las delegaciones para saber cuál era la normativa. Había normatividad contraria. Rodrigo Romo 21:13
A ver. No entiendo. Ángeles Jasso 21:14
Oficios circulares. Se junta todo eso. Y a la par con los mismos recursos. Era un trabajo que tenían que hacer los mismos que estaban haciendoel sistema. No había de otra manera. Porque era el mismo director, el mismo jefe de departamento, el experto en proceso y el experto en la parte normativa. Tenías un problema de recursos, porque en lo que se estaba haciendo el SIIP, se estaban sacando las reformas a la ley, se estaban haciendo los tutorials y la normatividad mínima con las áreas. Se hace todo este trabajo y se empiezan a quitar pasos y se empieza a utilizar el paperless. Oye, si ya te va a llegar por el sistema, usa el sistema. Quítalo. "¡Cómo! ¿Voy a quitar el oficio!" "Quítalo". "No lo voy a quitar". "Quítalo". Y se quitó. Rodrigo Romo 22:15
¿Contraloría no puso peros en este momento? Ángeles Jasso 22:17
No. Porque todo lo hicimos de la mano con Contraloría. Les enseñábamos, los invitábamos. Contraloría participó en los (inaudible) ¿altcoms?en los betas. Oye, esto no me gusta. Oye esto no está bien. Trajimos a las delegaciones. A ver, ésto lo usas o no lo usas. No. Trajimos a los mejores. De ahí salió Edgar Olvera. De esa búsqueda de conferencias telefónicas, cambios normativos y SIIP, tienes un director ahora que empezó como notificador en San Juan del Río. Pero fue realmente conocer a todas las delegaciones y saber qué era lo que estábamos haciendo. Fue un trabajo paralelo. La normatividad junto con el diseño. Pero aún así, había bemoles dentro del procedimiento que se hacían de forma distinta por áreas.
101
Rodrigo Romo 23:15
Ok. Saltan a la vista dos cosas. Una, Unisys no aplicó metodologías estandarizadas, en donde no hubiera cambios. Dos, dónde estuvo la administración de Unisys de proyecto. Porque una administración del proyecto lo menos que esperas es cuadrar estas historias. ¿Dónde estaba? Vives en una institución que funciona de manera departamentalizada, entonces Informática estaba administrando la parte informática estrictamente hablando, pero la parte de la organización, y me refiero en términos de la institución, quién administraba esa historia. Estaban desarrollando un sistema sin haber hecho la tarea. Ángeles Jasso 24:02
Salieron las dos al mismo tiempo. Rodrigo Romo 24:09
A eso me refiero. Allí es donde se nota de inmediato que no estaba planeada esta situación. Ángeles Jasso 24:12
Se veía que íbamos a superar las reformas a la ley y el sistema al mismo tiempo. No hubo primero las reformas y luego el sistema. No. Se inició la administración y se dijo "Vamos a hacer esto, esto y esto". Las reformas a la ley, sistemas, RP, CRM. Y luego se pregunta uno ¿por qué un CRM? Lo mas cercano que he escuchado de por qué un CRM porque al final de cuentas el CRM era lo más parecido y porque ganó la licitación. Cuando inició el CRM aquí en PROFECO, el CRM no estaba conceptualizado para gobierno. A lo largo de los años, el concepto evolucionó y Oracle comenzó a hacerle enfoques al gobierno. Cuando nosotros lo iniciamos era un Customer Relationship Management. Oracle lo que hace es un "Citizen Relationship Management". Con PROFECO hace y mete dentro del CRM las plantillas digitales o inteligentes, como les llamaban en su momento. Oracle no lo tenía. No había en ningún momento la parte de "papelito habla". Nunca. En gobierno, el "papelito habla", nos guste o no nos guste. Y hay una formalidad jurídica que tenemos que cumplir. Oracle inicia entonces las plantillas al CRM. Ve que PROFECO lo hace, que utiliza sus grupos no como un workflow natural, sino que es un desarrollo aparte y empiezas a hacer validaciones por estados de tareas y no por estado de soluciones de servicio. Y por referencias, cosa que Oracle nunca había hecho. Entonces, en todo fuimos pioneros. En implementar un CRM a nivel nacional, en implementar un CRM con esta cantidad de clientes, en implementar un CRM que utilizara el business suite de Oracle pero que se hiciera un desarrollo tan complejo aparte. Y por qué, porque lo necesitaba el cliente. Porque lo que te vendieron fue que el sistema se parametrizaba a la necesidad del cliente. Y la necesidad del cliente, afortunadamente, estuvo muy clara desde el principio. Yo necesito algo que me permita pasos, yo necesito documentos y yo necesito darle seguimiento a un caso.
102
Rodrigo Romo 27:30
¿Cuándo viste esos documentos? Ángeles Jasso 27:34
¿Cuándo vi esos documentos? Rodrigo Romo 27:35
Esa definición tan clara, porque no estoy tan seguro que haya una definición tan clara. Ángeles Jasso 27:39
Ah. Viene de las bases de licitación y el documento de requerimientos. Si yo aprendo del SIIP es porque me se toda la bibliografía del SIIP. Bases de licitación y los requerimientos son muy claros en decirte qué necesitábamos que hiciera. Que era lo que iba a hacer sistemas, lo cual no les gustó mucho a mis amigos de Unisys porque como ellos ya han cambiado, ellos no los conocen muy bien o no han tenido tiempo de meterse a leerlos. A veces se les olvidaba que soy abogada. "¿Dónde dice? Aquí dice que debes entregarme una parte. ¿Cómo nada?" Rodrigo Romo 28:20
Para eso te contrataron Ángeles Jasso 28:24
Tú me tienes que entregar una plantilla. Y había una sección como de ocho o diez requisitos los que dicen exactamente qué es lo que necesitaba PROFECO. A lo largo de esta historia se empiezan a negociar unos por otros. Por ejemplo, en un principio estaban las encuestas, se quitan las encuestas pero se mete el módulo de supervisión. ¿Ya tenemos un animal de este tamaño y no lo vamos a supervisar? Antes no nos lo permitían. Tenía que ir y decirles "pues desarróllalo". Hay módulos que efectivamente hoy no están funcionando porque no se han utilizado, porque estamos en la estapa de estabilización. Cosas que ya están terminadas todavía no se utilizan, porque no se ha dado el caso, porque se pensó tanto en lo que podría pasar y nos fuimos mucho a la excepción. Fue lo que nosotros le bajamos. Cuántos casos te llegan al año de eso, dos. Rodrigo Romo 29:32
No puedes meter la realidad entera a un sistema. Ángeles Jasso 29:33
No. Nos fuimos por el 80-20. Verdaderamente nos fuimos al 80-20.
103
Ángeles Jasso 30:59
Sí, sí hizo falta coordinación, sí hizo falta planeación, sí hizo falta ver el tamaño del monstruo que se estaba llevando a cabo. Yo si les hes preguntado "¿Qué nadie lo vio?". Creo que fue un problema de recursos. Tenían a la misma gente haciendo todo. Al mismo administrador del proyecto tenía que ver las cuestiones contractuales, las cuestiones de vigencias y no había el equipo o la infraestructura humana y tecnológica para hacerlo. No había un Dirección General de Informática sólida. Se ha estado formando conforme a las necesidades y a punta de no quitar el dedo del renglón en el tema de recursos. Cuando nosotros éramos Matute y nosotros. Y aparte teníamos que administrar el sistema que estaba operando. Porque la operación nunca se detuvo. No dijimos "cerramos la cortina seis meses". No. Nunca. Era en tus ratos libres cuando veías el sistema (SIIP). Al sistema se le tuvo que dedicar horas y horas y horas hombre para sacarlo. A costa de la salud de la gente, del tiempo de la gente, de la vida personal de la gente. Si fue mucho el esfuerzo que se estuvo realizando para poder llegar a un producto. Al final de cuentas era la línea "Esto tiene que salir" y tiene que salir bien. Porque si ya le estás invirtiendo en tiempo, tiene que funcionar. Hay muchos sistemas que, me explicaban, que le invertías muchísimo dinero y al mes afuera, porque no funcionó. Entonces sí se tuvo mucho cuidado de ver que el sistema cumpliera con la necesidad de la operación. Esa sí fue una premisa en cualquier momento. Esto tiene que ir acorde con la operación. Si no va acorde con la operación, va para atrás y lo vuelven a hacer. Eso sí se cuidó mucho y creo que eso sí se cumplió. El sistema opera, te permite un flujo. Le faltó orden, planeación, lo que tú quieras. Jaló. Y eso sí era mucho el énfasis de "pregúntale al que lo hace", "pregúntale a quien lo va a operar". Haz pilotos con la gente antes de que te salgas a un despliegue nacional. Esa parte y la capacitación fue muy importante y también se le invirtió muchísimos recursos y tiempo a la capacitación. A la planeación de la capacitación, a los materiales de capacitación. Más de un año. Rodrigo Romo 34:44
Esa parte estuvo más controlada. Ángeles Jasso 34:44
Sí. Esa parte se empieza a planear un año antes de salir al piloto. Ya era un control más de la Subprocuraduría. Y la Subprocuraduría le metió muchísimo, porque vimos el efecto ERP. Al ver qué había estado fallando en el ERP, pues no. Por ejemplo, Jurídico tomó lo que había fallado con nosotros. Rodrigo Romo 35:30
A Jurídico ya le tocó planchada esta historia y se encargó de enredarla de más. Ángeles Jasso 35:36
104
Sí hubo una etapa de aprendizaje. Las plantillas que se hicieron con Jurídico son las mejores que hay. Porque traen la experiencia de Jurídico, la experiencia de nosotros y ya habíamos aprendido a hacerlo. Cuando iniciamos esto, nadie habíamos hecho algo así, al menos por el lado del usuario. Por el lado de informática me queda claro que no era su primer proyecto, pero sí era su primer proyecto de una dimensión así y una institución como nosotros. Rodrigo Romo 36:26
Tu mayor obstáculo fue esa organización. ¿Cómo encontraste las limitaciones de delegaciones --son muy famosas-- para echar a andar el SIIP? Ángeles Jasso 36:37
La clave aquí fue cómo nos ayudaba el delegado. Si el delegado iba a la capacitación, la gente adoptaba más rápido el sistema. Invariablemente. Si el delegado no iba a la capacitación, nos costaba más trabajo. ¿Qué me encontraba en las delegaciones? Falta de capacitación, falta de equipo de cómputo, eso siempre ha habido y hasta ahorita siempre hay rotación de personal. Terminaste de capacitar y otra vez se fue el que habías capacitado. Mientras estuvo el despliegue lo pudimos subsanar, ahora mi termómetro es la "Línea SIIP". Era crucial para el termómetro con las delegaciones. Si las delegaciones no tenían algo para decirme que yo estaba mal, esto tampoco iba a funcionar. Rodrigo Romo 37:41
¿Qué tan rápido reacccionaba y qué tan bien recibía oficinas centrales las críticas de una delegación cuando no le encontraba la cuadratura al círculo? Ángeles Jasso 37:51
Había dos maneras. La mayoría eran quejas de "no funciona, no sirve". Y tardamos en que nos dijeran "Ok. Dímelo a mí. Ya te fuiste a quejar con el Procurador, ya te fuiste a quejar con la Coordinación de Delegaciones, ya te pusiste a hablar pestes. Dímelo a mí. Porque si no nunca voy a saber la magnitud del problema. Y empezamos a incentivarlos a que nos lo dijeran por el SIIP. Se hacían reuniones, Gaby hablaba con ellos, yo hablaba con ellos. Fue una labor de meses de que la gente nos dijera qué estaba mal, que no funcionaba. Y fueron correos, observaciones, que a la fecha siguen, pero que se van haciendo con prioridad de acuerdo con lo que más te pega en la operación. Sí fue al principio difícil, porque venía el enfrentamiento con la delegación de decirles que nos íbamos a tardar una semana. Hubo delegaciones que lo tomaban bien, hubo delegaciones que no. Lo que pasa es que, en general, la actitud era positiva. Me quejo, pataleo, te digo que no, pero lo hacían. A regañadientes. Y mucho era la línea que dio el Procurador. La verdad, si no hubiera habido las cabezas dando la línea y el seguimiento, no hubiéramos podido. Necesitamos el trabajo del administrativo, de coordinación de delegaciones, de informática y el de nosotros. Entonces sí hicimos que trabajaran, a muchas gentes, para que esto saliera. Y lo mejor fue que se sintieron más atendidas.
105
La gente decía "No, no, no, que vuelva el SISEQ". Y les decía ¿Cuándo te habían dado una capacitación así? ¿Cuántos años llevas en PROFECO? Veinte. ¿Cuándo se tomaron la molestia de venirte a decir cómo era? Dos semanas. No una, dos semanas. Nunca. Y le bajaba una poco la guardia a la delegación. Pero también se trabajó en un programa de manejo del cambio. Rodrigo Romo 41:06
¿Pero qué tan bien estuvo eso? (El programa de Recursos Humanos) Ángeles Jasso 41:13
¿Sabes para qué sirvió ése? Para darnos cuenta dónde estábamos parados. A mí, en lo personal, cuando hicieron los Focus Groups, me sirvió para darme cuenta dónde estábamos parados. Por qué estaba la gente disconforme, por qué la gente no quería hacerlo. Por qué la gente realmente dijo no lo hago y no lo voy a aceptar. Ponte tú que se hizo el programa promoviendo el cambio, dinámicas que quién sabe si se hicieron en la delegación. A mí en lo personal me sirvió para hacer la estrategia sobre cómo le iba a llegar a la delegación. Dónde estaba yo parada para poder llegar a la delegación. Yo sé qe tu problemática es ésta y ésta. Ya te permitió tener un tablero de riesgos. Nos hicieron un tablero de riesgos. Nos dijeron "éstos van a ser tus riesgos. Úsalos bien". Y para hacer la planeación de la capacitación se agarró esa información y se dijo "no vamos a hacer que la gente se sienta a un lado". No vamos a quitarle horas a la gente de su descanso. No nos vamos a meter en decirles que tienen que estar hasta las seis de la tarde, porque algunos trabajan hasta las tres y no nos vamos a meter en distraerlos de una operación. Si no hubiéramos hecho eso, quién sabe cómo se nos hubiera ocurrido y no hubiera resultado. No digo que salió excelente, pero salió bien. Rodrigo Romo 42:59
Se obtuvo resultados Ángeles Jasso 42:59
Al menos no fue un desastre. Y era lo que platicabas con la persona que hizo el estudio, que me fue a entrevistar la semana pasada. A mí me sirvió y a Gabriela le sirvió para poder armar la estrategia. Rodrigo Romo 43:22
Eso lo hicieron ustedes o Recursos Humanos, porque estaba la estrategia global. Ángeles Jasso 43:28
Había trabajos para RH y había trabajos para Servicios, porque eran entregables distintos.
106
Rodrigo Romo 43:35
Entonces la realmente válida era la de Servicios. Ángeles Jasso 43:37
Se hicieron Focus Groups para el ERP y Focus Groups para Servicios. Rodrigo Romo 43:40
La que yo había visto que era la general, francamente...Un esquema muy limitado. Ángeles Jasso 43:49
Esa no la vi. Hubo una primera encuesta. Esos resultados sí los vi. Después para Servicios hicieron Focus Groups. [inaudible] se metió con gente de Delegaciones. Haz de cuenta. Los traíamos para el Beta o el Alfa y los pasábamos con Rosa Isabel (CGA), para que fuera la misma gente la que dijera "Nombre, está horrible, no nos gusta. ¿Qué le ves de malo al sistema? Nombre, está horrible, muchas pantallas, está muy complicado, no nos gusta, quítalo". [inaudible] En base a eso se hizo el programa de capacitación, porque eso te vas a encontrar en todas las delegaciones. Rodrigo Romo 44:57
En todas y cada una. Ángeles Jasso 44:57
No va a haber una que va a llegar y "Sí, sí, dámelo". No. No lo hubo, pero al menos ayudaron. Rodrigo Romo 45:06
Ahora viene el punto número 2. ¿En algún momento tenían o se contempló -porque no era exclusivo de ustedes-- lo que se llama asegurar la calidad del sistema? Esto es, tú luchaste a brazo partido, gritos, sombrerazos, mordidas, golpes para sacar el sistema. Ya salió el sistema, chueco o derecho, salió. Ahora. ¿En algún momento planearon ya que esté funcionando esta cosa lo van a hacer trepar los niveles de calidad de la norma internacional, por ejemplo, el CMM que te da la madurez de tu sistema? Tú desarrollas por acá, ya lo tienes funcionando, ahora tienes que evaluarlo conforme la mejor norma. ¿Lo tenían contemplado, tenían alguna meta prevista al respecto? Ángeles Jasso 46:01
Yo no la conozco. No sé si la había. La verdad no la conozco. Lo de calidad que vimos, por ejemplo, fue cuando entramos a lo del Premio Innova, que también vimos que hay que hacer algo sobre la calidad. ¿Está certificado o no está
107
certificiado? Es la pregunta básica. Tu sistema está certificado o no. No. La libramos, pero te soy sincera, porque Oracle está. La E-Business suite cumple con ciertos estándares internacionales ya de por sí. No exactamente lo de PROFECO, pero sí le pedimos la documentación a Oracle oye, pues yo me imagino que tú, una empresa de clase mundial, debes tener como que algún tipo de certificación. Rodrigo Romo 46:56
Ok. Ahí si es al revés. Microsoft está certificado para muchas cosas. Ángeles Jasso 47:13
No. No está ahorita. Rodrigo Romo 47:13
Es un punto importante primero porque es donde está basado el sistema famoso de entrada. Buena parte del Innova es eso. No que alguien que haya participado en el desarrollo de un proceso certificado, no, sino que tú sistema cumpla con las características de un modelo. Ángeles Jasso 47:36
Lo que documentamos e hicimos fue el sistema cumplió con la Agenda de Buen Gobierno. Porque es un proceso transparente, porque venía la calidad, porque venía profesional, que cueste menos, digital y no me acuerdo qué más. Rodrigo Romo 47:57
Ok. Cumplía con la Agenda de Buen Gobierno Ángeles Jasso 47:57
Con esa Agenda de Buen Gobierno cumplió. Uno de los puntos era y realmente cumplió con un estándar internacional. La respuesta fue no. No el sistema como tal. Lo que se hizo, por ejemplo, lo que nos recomendaron fue métete a las cartas compromiso y empieza a tener mediciones de tu sistema. Lo cual tampoco es completamente cierto, pero no hay ahorita un trabajo de decir ahorita voy a meter. Estamos viendo si salimos del Innova y de ahí a meternos a otro lío, porque la verdad, como te digo, si tú me preguntas cuál fue el principal problema del sistema, los recursos. Porque es la misma gente que hace lo mismo. Rodrigo Romo 48:56
Pero eso al mismo tiempo te da. Quiero decir, un grave problema que tuvo PROFECO, global, fue el famoso retiro voluntario. De repente fue un torpedeo espantoso de gente que, independiente de la calidad de su trabajo tenía un conocimiento específico, y que con esta salida masiva, indiscriminada, PROFECO
108
perdió de repente ese saber hacer, las cosas elementales. Entonces, si tú tenías a gente trabajando en el SIIP y se te fueron por retiro voluntario, entonces tuviste que volver a empezar en muchos aspectos. Eso sí te afectó también. Ángeles Jasso 49:30
Bueno. En procedimientos, otro de los Directores Generales. Cada vez que llegaba alguien, Unisys temblaba. Ya me lo van a cambiar, ya me lo van a cambiar. Y fue lo que se dijo no. Se trataba de llevar una línea. Oye, ven. Me gusta tu comentario, pero too late. Ya está hecho. Sí era un problema. Hasta cuando se van los consultores de Unisys. Porque la curva de aprendizaje de informática fue altísima. La curva de aprendizaje de informática y de servicios fue muchísima. Rodrigo Romo 51:10
Es un punto muy importante Ángeles Jasso 51:10
Por ejemplo, con Jurídico no pasó. Rodrigo Romo 51:20
Ya vino cuando estaba toda la comida servida. Y aun así se enredaron ellos solos. Ángeles Jasso 51:26
La persona de informática estuvo sentada a la par de servicios. Rodrigo Romo 51:36
Jurídico se empezó a desarrollar el año pasado. De hecho, a mediados-finales del año pasado. Ángeles Jasso 51:40
Y un gran problema fue que la gente de informática de PROFECO nunca se involucró con el desarrollo del SIIP. Y cuando te digo nunca fue nunca. Y te digo, no porque no hayan querido. Se hizo una dirección de área, se contrató a un grupo de gente, se contrató para que fueran los líderes de cada uno de los módulos. El año pasado. En agosto del año pasado se contrata a la gente que va a ser la encargada de PROFECO de llevar el sistema. Antes no se pasó otra cosa. Rodrigo Romo 52:25
También ya fue el propio aprendizaje del desarrollo. Pero al mismo tiempo eso te lleva a entender por qué el proyecto tardó tanto en desarrollarse. Pero ya es un desfase inaudito [inaudible].
109
Ángeles Jasso 52:40
Hubo una falta de recursos impresionante. Rodrigo Romo 52:45
Y de reglas del juego. De recursos me queda claro, finalmente. Pero de reglas del juego claras. Ángeles Jasso 52:54
También cambiaron. Por ejemplo. Cada coordinador general administrativo traía unas reglas del juego. La línea siempre era la misma, pero a final de cuentas el encargado es el coordinador general administrativo, de todo el pastel. Entonces, todo este pastel tuvo varias cabezas. Rodrigo Romo 53:17
Demasiadas, de hecho. Ángeles Jasso 53:17
Varios betunes. Cada cambio en el administrativo, en la coordinación general, claro que le pegó. Por supuesto que le pegó, porque era esa visión integral. Yo te puedo decir lo que pasó en servicios. Me enteré lo que pasó en ERP. Viví lo que pasó en Jurídico porque me metieron. Pero esta integración con Jurídico yo me metí en octubre y la terminamos en junio. Rodrigo Romo 53:52
Sí, porque ya estaba hecho. Salvo sus propias limitaciones porque fueron también la más rápida. Básicamente era la misma historia. Ángeles Jasso 54:07
Sí hubo un proceso largo de octubre a junio para dar un resultado. Y fueron fines de semana y todo, como en Servicios. Porque tenían diferente visión, diferentes cabezas, y en Unisys tambien hubo diferente visión y diferentes cabezas. Pasamos por Carlos Jada, pasamos por Sergio García, pasamos por Michel [inaudible], pasamos por Eric Ramos y ahora con Carlos Ayala. Lo que sí fue importante y creo que es importante destacar es que aun y cuando hubo cambios en la administración a nivel Procurador, no se dejó de trabajar en el SIIP. Lo único en lo que no se dejó de trabajar en la institución fue en el SIIP. Porque el cambio de María Eugenia se da cuando estamos en pruebas. Imagínate. María Eugenia se va en marzo y estábamos en plenas pruebas de caso de uso. Nos dieron el aviso de se va la Procuradora. Toda la gente así. Me volteo y les digo "Ya. Recupérense. Despierten. Al beta, vámonos". "¿Cómo que vámonos?" No sabemos quién va a venir, no
110
sabemos si lo van a echar a volar. Tenemos entregables con Unisys. Eso no nos dejó flojear. Eso no nos lo permitió porque había entregables en los que incurríamos en reponsabilidad si no lo hacíamos. Y eso sí nos separó. Y cuando llegó el Procurador, afortunadamente fue en la misma línea. Eso la verdad sí nos ayudó un montón. Rodrigo Romo 56:00
Sí, claro. Ángeles Jasso 56:00
Fue la misma línea. Tú le tienes que dedicar lo que le tengas que dedicar. Tiempo, lo que le tengas que dedicar. Y no pasó a segundo plano. Rodrigo Romo 56:18
También es una cuestión de tiempos. En las primeras etapas de desarrollo estaba en segundo plano. Mientras más te acercaras a la producción aquella cosa iba a emerger, le gustara o no. Entonces a María Eugenia le toca en segundo plano y a Carlos le toca la operación real. Son dos actitudes distintas. Ángeles Jasso 56:44
A eso súmale integrar hasta las áreas. A tener módulos en BI como Albalá que atravesaban las áreas. Eso fue también cierto. En lo que yo estaba haciendo la solicitud de los flujos también te llegaba tienes que hacer la signatura topográfica. Y tienes que dar los campos para la tabla intermedia de Albalá. ¿Y yo por qué? Pues porque eres la única que ya lo tiene arriba. ¿Y yo por que? Porque tienes que hacerlo. Y también nos tocó sentarnos con recursos humanos para ver al momento que íbamos a entrar al despliegue cómo íbamos a dar de alta a los usuarios. Rodrigo Romo 58:07
Fíjate. Ahí sí hago un apunte. Faltó la coordinación de CGA. La parte operativa de Unisys con informática estaba muy clara, y mal que bien dominada con Néstor, la bronca era el resto de la coordinación institucional. Allí resulta, te cuento el detalle, que estaba establecido el módulo de acervo documental y a Guillermo le avisaron que era el líder de ese proyecto materialmente un año después de echarlo a andar. Yo estaba sentado en esa misma mesa cuando fue eso. ¿Qué clase de organización? ¿Cómo me puedo poner de acuerdo con las áreas que ya van avanzadas en el SIIP, con la definición de requerimientos que va desde antes y tienen la amabilidad de avisarme un año después? Ángeles Jasso 59:12
Lo mismo le pasó a Miguel Ángel Arreola. ¿Que yo soy el encargado de qué? De BI. ¿No sabías? La bronca es que existía con Carlos Jaime toda una Coordinación
111
de Planeación para eso y para tener un centro único de datos. Y orgánicamente viene en tu estatuto y allí está. "¿Cuándo se dijo eso?" Cuando se lo presentaron al Procurador estaban las cabezas de todos los módulos. Hace como tres o cuatro meses se lo dijimos. Rodrigo Romo 1:00:15
Le tocó barato, tres o cuatro meses. A Guillermo le tocó un año después. Ángeles Jasso 1:00:24
No. HACE tres o cuatro meses se lo dijimos. Ángeles Jasso 1:00:28
Había un área que era la encargada del manejo del cambio, había un area que era la encargada de la capacitación. Había un área...A nosotros la verdad lo omitimos y la hicimos nosotros. Si nos esperábamos a que nos lo dijeran iba a ser muy difícil. No lo hubiéramos logrado. La verdad. Ángeles Jasso 1:02:03
Sí ha sido difícil. Efectivamente. Rodrigo Romo 1:02:08
Muy improvisada la organización global. Muy echado a andar antes de decirle a la gente lo que tenía que hacer. Y eso obviamente implica unos retrasos espantosos en lo que entiendes de qué se trata la historia. Ángeles Jasso 1:02:24
Y deja tú. Cada cambio de cabezas nos costaba a las dos partes. Porque lo que ya se había definido para uno, o sea el último cambio de Unisys los tuvimos con BI en enero. Todo lo avanzado que ya teníamos se fue a volar y vuélvele a explicar. Rodrigo Romo 1:02:54
Hubo un momento de una renegociación brutal entre PROFECO y Unisys. Ángeles Jasso 1:02:57
2005. Rodrigo Romo 1:03:00
Ahí en qué etapa estaban ustedes. ¿Cómo les pegó esa historia? Porque fueron muy tensos. Otro poco y el ejército interviene.
112
Ángeles Jasso 1:03:10
2004. Diciembre de 2004. En ese entonces, habíamos terminado las betas. En septiembre-octubre. Y teníamos que haber tenido para diciembre el sistema listo para entrar a producción. Lo cual era sinceramente imposible. Tanto que te das cuenta que lo hicimos hasta mayo. Rodrigo Romo 1:03:40
Cinco meses después. Ángeles Jasso 1:03:43
Exactamente. Y se terminaron las fases de beta pero sí hubo un reajuste de hacer bien lo que se habia hecho a medias. O sea, terminar las pruebas beta no significaba que ya estuvieras listo. Terminan las pruebas beta quería decir que ya estabas listo lo que teníamos que llegar. Entonces, la verdad, esto fue un problema implementarlo. Porque "Ya. Ya me dijiste lo que quiero. Ya te lo enseñé cómo va a funcionar. Ya te di las observaciones. ¿Dónde están? Y ahora vuélveme a decir que todo lo que dije ya está. Lo cual la verdad no fue nada sencillo. Y en ese entonces hay un cambio en la administración del proyecto de servicios. Se va y dejan a otro chavo que ya estaba. Pero éste hacía las veces de la cabeza del genio y tenía que hacerla de project manager, cosa que tampoco había hecho antes. No había sido project manager y ahora tenía que meterse en todos esos asuntos de la negociación y programar las soluciones. También fue difícil. Pero aún así salimos en mayo. Rodrigo Romo 1:05:18
Sí. No fue tanto tiempo después. Ángeles Jasso 1:05:21
Pero seguimos en mayo, la verdad porque ya era revisar que lo último quedara. Dígase usuarios, dígase procedimiento de dar de alta las delegaciones en el sistema. Rodrigo Romo 1:06:18
Han tenido una etapa no inusualmente, pero si extremadamente larga de mantenimiento. Ángeles Jasso 1:06:35
Muchísimo. ¿Cuál era la prioridad? Salir. Salir en el menor tiempo posible. Hubo muchas omisiones por eso. Muchísimas. Rodrigo Romo 1:06:46
113
Demasiadas ambiciones. Ángeles Jasso 1:06:50
Pero hemos tardado más de un año en estabilizarlo. Rodrigo Romo 1:06:59
No me extraña. Ángeles Jasso 1:07:00
No es lo mismo probarlo con treinta gentes que probarlo con trescientas. Rodrigo Romo 1:07:06
No, no es igual. Ángeles Jasso 1:07:07
Créeme. Una parte de pruebas de stress. Ángeles Jasso 1:07:55
Lo cual la verdad también me dio muchas experiencias de que ya no me vieran la cara. En qué sentido? El experto te dice no se puede. Cuando no tienes ni idea le dices "Ok. No se puede" Y le crees. Pero cuando ya empiezas a ver, "¿Cómo que no se puede? Sí se puede, pero te tardas más tiempo, me vas a hacer invertir más recursos, te cuesta más trabajo, pero de que se puede, se puede". Y yo ya aprendí algo. Siempre se puede. Dejas de hacer ciertas cosas por el impacto que puedes tener.
114
Apéndice B
Entrevista al Ing. Néstor Galván Zamora, Director General de Informática de la
Coordinación General de Administración, en la PROFECO
24 de octubre de 2006
Rodrigo Romo 00:00
¿Cómo llegaste al SIIP? ¿O cómo te cayó el SIIP a ti? ¿Cómo te enteraste, o sea, en qué momento te cayó el paquetito tremendo? Néstor Galván 00:20
Bueno fue en 2001, cuando se tomó la determinación por parte de la Procuradora. Habían tenido un análisis previo antes de que yo entrara a PROFECO. Entonces vieron que una de las necesidades más fuertes de PROFECO era la problemática de la información. Había bastante información o hay muchas fuentes de información pero no había un sistema que te integrara esa información, que te administrara esa información y sobre todo que pudieras explotarla. Rodrigo Romo 00:54
¿De quién era esa idea? ¿Alguien se lo vendió específicamente a la Procuradora? Néstor Galván 01:00
Quien empezó este proyecto fue la gente de Ergo. Ellos platicaron con la Procuradora y ella dijo que vamos a hacer un ejercicio de reingeniería. ¿Te acuerdas de Alternativas en Economía? Rodrigo Romo 01:19
Tiempo hace. Néstor Galván 01:19
De ahí nace. La cuestión era ver cómo estaba la Procuraduría. El problema es que este ejercicio de Alternativas no fue muy afortunado. Pero lo que sí se vio la necesidad de hacer una modernización de tipo, vamos a llamarlo, de todo la estructura de información de la Procuraduría. Entonces, para hacerlo, necesitabas tener sistemas de información robustos.
115
Rodrigo Romo 01:50
Entonces a tí te llegó la invitación a echar a andar el SIIP Néstor Galván 01:59
Sí. Me dijo [referencia personal] "Oye traemos un proyecto muy interesante". Yo creo que en ese momento no teníamos ni idea de la magnitud. Yo estaba en Secofi. Muy tranquilito, ahí, desarrollando páginas de Internet, desarrollando sistemas y me voy para acá. Y la cuestión era que se tenía que crear una Dirección General de Informática, que no había. De entrada. Y entonces se crea la figura de la Dirección General para administrar este proyecto, que también es una decisión medio aventurada, porque viéndolo en retrospectiva necesitabas una oficina específica para eso. Porque el proyecto era inmenso. Rodrigo Romo 03:01
Nunca se creó una oficina específica. Néstor Galván 03:04
No. Digo, sí armamos una dirección de área que iba a administrar la parte documental, la parte logística. Pero nada más. Entonces la forma. Poner en orden la información de PROFECO. Rodrigo Romo 03:31
¿Cómo te fue cayendo el veinte del tamaño de lo que ibas a necesitar para desarrollar el SIIP? Esto es, cuando empezaron con la licitación. Néstor Galván 03:41
Cuando se empezaron a armar las bases de licitación. Rodrigo Romo 03:43
Ahí te cayó el veinte del tamaño del monstruo. ¿Lo hicieron Sergio y tú? Néstor Galván 03:47
No. Bueno, participamos Sergio y yo por un lado, pero también la gente de Ergo. Porque ellos habían venido platicando con la Procuradora, entonces ellos tienen una habilidad, un feeling importante en lo que es precisamente la parte de manejo de información estadística. Entonces, obviamente este es su background principal. Sabes qué, en base a este resultado de nuestro estudio inicial, sí se necesita un sistema que integre la información, porque esto tiene mucha información pero no se captura bien, y mucho menos se explota, y tres, otro problema muy fuerte era que con los sistemas anteriores, como le dicen por ahí, el "cuchareo de datos", el meterle mano a los datos era una cosa de todos los días. Rodrigo Romo
116
04:57
¿Cómo encontrase PROFECO en términos de infraestructura cuando llegaste? Néstor Galván 05:02
De la patada. Digo, había. Tendría que ser justo, habían iniciativas. En su momento hubo iniciativas. Cuando llego yo por lo menos ya había una página de Internet. Se empezaba a consolidar la parte de correo electrónico. Yo ya llegué para ese momento. Rodrigo Romo 05:34
Entonces una cuestión de tiempo. Cuando entramos en 2001 no había computadoras. Mucho menos correo electrónico. Néstor Galván 05:48
Hasta finales de 2001. Rodrigo Romo 05:52
Hasta finales de 2001 es cuando llegaron las primeras máquinas. Por cierto, la cual tengo todavía. A mí si me llama mucho la atención que tienes una institución que no vivía en la época tecnológica, punto. Era una institución de máquina de escribir y papel. Y de repente, casi de la noche a la mañana, la trajeron muy a su disgusto en buena cantidad de casos, a la modernidad. Entonces tienes de entrada esa institución que no te da el ancho para sistemas, por razones evidentes, ni siquiera tenía computadoras, y de repente plantean el SIIP. ¿Ergo no encontró una contradicción en eso? O sea, la decisión estratégica del SIIP se tiene que llegar a sistemas integrados, eso es perfectamente lógico, la bronca es cómo pasas de la prehistoria al Siglo XX. Néstor Galván 07:05
Mira. Definitivamente, yo creo que lo que sucedió es que la información que se tenía, más bien nunca se hizo un ejercicio formal para ver cómo estaba la Procuraduría. En ese sentido, en la parte cultural. Rodrigo Romo 07:31
Aquí debo decirte que la intención de todo esto es saber exactamente qué pasó. O sea, al final del día, tienes una institución que era prehistórica y mal que bien está ahora con sistemas. Tiene un SIIP. Invirtió millones de pesos en infraestructura, millones de pesos en desarrollar una cosa nueva, cosas que realmente le hacen mucho beneficio a la institución. El proyecto fue muy tortuoso, muchos obstáculos, muchos problemas, muchas cosas que todavía no se alcanzan, pero al final de la historia, el balance a fuerzas es PROFECO se benefició. Eso es muy claro. Pero lo importante de esto es aprender todo lo que no ocurrió como debía. Néstor Galván 08:19
De entrada sí hubo un problema muy fuerte de un verdadero ejercicio de la percepción, más bien
117
para tener una percepción verdadera de cuál era la situación del personal de PROFECO. Y yo creo que aquí hay una serie de causas por lo que sucedió esto. Y a qué me refiero. Yo creo que si nos remitimos a aquellos años, al inicio, nos encontramos que por ejemplo había un Subprocurador que llevaba veinte años, entonces, había desde mi punto de vista, ya se había hecho una cultura de "amarrarte a poste y no soltarlo". Entonces, ¿cómo le haces? Bien fácil. Empiezas a generar tu coto de poder a partir del supuesto conocimiento y necesidad de la gente. Por ejemplo, la gente de Servicios nos contaron una vez que platicábamos con ellos, cuando les dijimos qué hacen en el Teléfono del Consumidor, curiosamente se da cuenta de esto Gabriela Hernández, [nos respondieron] el Teléfono es muy importante. Tienen mucho trabajo. Bueno, sí, pero explíquenme qué hacen, hazme una presentación. Y llega ahí [referencia personal] y hace una presentación en Power Point, con una foto de una playa --estás en una institución, ¿no?-- son de un atardecer en una playa para explicarte sobre el Teléfono del Consumidor. Y entonces te empieza a decir las cifras, que tenemos más de dos millones de llamadas atendidas al año. Y tú, "Ah, caray, Interesante". Qué hace, qué tipo de llamadas atienden. Ah bueno, atendemos llamadas de por ejemplo, la gente nos pone el caso de una liposucción, entonces nosotros la apoyamos. Oye, espera, ése no es el propósito del Teléfono. Bueno es que también la gente nos habla para las tareas de los niños. Oye, pero tampoco es el propósito. Bueno, es que tenemos que atender a la gente. Había un tren desencarrilado que ahí seguía, con toda la fuerza. Una dirección completamente equivocada. Por eso regreso a lo que decía. Ya había una cultura de cómo me hago yo de mi [inaudible] a base de situaciones que no son las reales, las verdaeras. Rodrigo Romo 12:06
Ok. La pregunta obligada inmediata es la siguiente. Si no se hizo el estudio sobre la gente de PROFECO, se hizo un estudio sobre la situación de los procesos. Néstor Galván 12:18
Es para lo que se hizo la reingeniería. Rodrigo Romo 12:22
Ahora, ¿una verdadera reingeniería o simplemente un mapeo? Néstor Galván 12:24
Fue un ejercicio previo. Con miras a llevar al reingeniería. Rodrigo Romo 12:34
¿Y qué te encontraste ahí? Néstor Galván 12:34
Había procesos, pero mal definidos, no con una metodología formal. Una vez más la gente se puso su caparazón, se protegió, y desgraciadamente creo que nunca hubo un ejercicio verdadero de análisis del resultado de ese ejercicio. Entonces, por ello, es que realmente se hubiera podido ver que había un problema fundamental ahí. Sabes qué, tenemos un problema estructural fuerte.
118
Sí hay proceos, pero son muy, vamos a llamarlos, muy improvisados, muy caseros. Rodrigo Romo 13:51
Obviamente ningún sistema. Néstor Galván 13:54
Estaba el SISEQ, que era un sistema casero, creo que tenía buena intención pero era una herramienta muy obsoleta, en FoxPro para DOS, ni siquiera para Windows. Rodrigo Romo 14:15
¿Cuántos años tenía el SISEQ? Néstor Galván 14:15
Desde el 1996. Cuando llego yo, y aquí brinco al siguiente punto, dentro de la parte cultural, los cotos de poder estaban de la patada. [referencias personales] La cuestión es que habían cotos de poder. Y era poder con terrorismo. Y era a nivel generalizado, incluso en esa área estaba el área de informática. Rodrigo Romo 15:29
¿En dónde estaba? Néstor Galván 15:29
De entrada, Informática dependía, cuando yo llegué, de DGPOP. Era una dirección más de DGPOP. El poder era tal que incluso llegó a nuestra área, de informática, yo cuando llego me informan, yo llegue en agosto, que se iba a liberar la nueva versión del SISEQ. Ok. Está bien. ¿Ya está listo? Bueno todavía no. ¿Cómo la vas a liberar? Y ya lo dijiste en la reunión de delegados. Es que [referencia personal] ya dijo que tiene que salir. Es más, lo anunicó porque le dijimos que ya íbamos avanzados. A ver. Enséñame los planes. ¿Dónde está la exportación de datos? Es que no lo vimos. ¿Pues qué diseño de sistemas hicieron? Lo que quiero llegar es que había un coto de poder muy grueso, pero en varias áreas. Ahí está la bronca cultural. Entonces había un coto de poder que manejaba todo. Tantos los procesos como la información. Obviamente. El sistema, la nueva versión del SISEQ tenía muchas mejoras pero seguía en la misma dinámica del cuchareo de datos. Entonces pues ahí digamos que no fue muy afortunado el movimiento. Otro coto de poder, Recursos Humanos. Cuando tuve las primeras sesiones sobre el nuevo sistema, obviamente ahí empezaba la resistencia al cambio. Rodrigo Romo 18:22
Una pregunta. ¿Hasta dónde estaba el titular de CGA con esa idea del SIIP? ¿Estaba a favor del SIIP? Néstor Galván
119
18:36
Sí. Pero no podía controlar a sus directores. El problema fue que al inicio faltó permear el proyecto. La bronca fue que no permeó al nivel. La gente, los operativos les dijeron "Ahí viene un nuevo sistema". Vamos a esperar a ver qué pasa. Pero las cabezas no tenían tan claro qué es lo que tenían que hacer. Rodrigo Romo 19:26
Y todavía eran cuadros del pasado. Néstor Galván 19:26
Sí. Rodrigo Romo 19:42
Es difícil. Néstor Galván 19:48
En DGPOP estaba otro de los problemas fuertes también. Una vez más, la parte de información. En este caso, la información presupuestal. Que las áreas no se enteren cómo está su presupuesto. Rodrigo Romo 20:18
Todo un entorno bastante adverso para iniciar esta historia. Néstor Galván 20:24
Sí. Efectivamente un estudio, más profundo, respecto al estatus de cómo estaba la cuestión estructural en PROFECO, eso faltó. Déjame decirte qué es lo que sucede. Por qué tanto aventarse como el Borras. En ese momento, había presupuesto. Entonces, era la disyuntiva desde el punto de vista de planeación. Es que ahorita tengo el dinero. Probablemente el año no. Rodrigo Romo 21:34
¿Cómo reaccionaba la Procuradora ante estos obstáculos? Néstor Galván 21:35
Con todo respeto, no estaba tan enterada. Yo creo que ella descargó el proyecto en CGA, a su vez el titular de CGA en mí. Las golpizas me quedaron a mí, que yo me peleara. En medio de lobos. Aunque respetaban el proyecto, hay un hecho muy interesante, una anécdota. De cuando empiezan a trabajar en la parte del ERP, cómo presenta el titular de DGPOP a la gente de Unisys ante su gente. Ellos van a hacer lo que ustedes les digan. El problema es que desde las bases de licitación se establecía que el SIIP era una herramienta parametrizable, que tiene inmersas las mejores prácticas, y que tienes que adaptarte a él. Desde ahí, te fijas, iba al revés. Otro punto importante, en cuanto al modelo de sistema, y aquí hubieron a lo mejor algunas [inaudible]
120
precisamente por la inercia, era aquí es una nueva manera de hacer sistemas. No voy a traer un ejército de programadores y desarrolladores sino más bien vamos a traer una herramienta prefabricada que vamos a adaptar o parametrizar o que nos vamos a adaptar a ella. Más bien. Rodrigo Romo 24:21
En cualquier caso, era una ganancia para PROFECO. No tienes procesos, que te adaptes a uno no es necesariamente malo. Néstor Galván 24:29
Pero la bronca era que había precisamente los "procesos" basados en un coto de poder. Ahora, en 2001-2002 había un gran sistema. El sistema de nómina. ¿Cuál era la grandiosidad? Que estaba desarrollado en una plataforma tecnológicamente más poderosa que FoxPro que era la base de datos Oracle, desarrollado en SQL. Y este sistema estaba completamente adaptado a las prácticas como las quieras llamar, de PROFECO. Aquí puedo hacer esto, allá puedo mover. Rodrigo Romo 25:35
Te voy a decir. Yo me acuerdo. Por lo menos desde el punto de vista del empleado, era eficiente, porque la parte que es normal cuando tú entras a una oficina de gobierno es que pases tres meses sin cobrar. En lo que alguna entidad le da el golpe a que ya existes. En cambio, yo llegué a PROFECO y a los quince días estaba absolutamente todo resuelto. Me llama la atención porque tengo la percepción, o nunca he tenido mayor problema, salvo estos últimos años por otras circunstancias, con la parte administrativa de la lana. Déjate otra, que son muy claras. Pero lo que se refiere a la paga, la nómina. De hecho, fue más complicado el paso a la otra plataforma. Pero a mí, empleado, me llegaban las cosas en perfecto tiempo y perfecta forma. Néstor Galván 26:34
Definitivamente, esta gente llevaba un buen número de años trabajando. De hecho, el sistema de nómina era reciente para cuando yo entré. Se había desarrollado a finales de 1999, tomando como pretexto. Antes el sistema se ejecutaba en informática. Pero tomando como pretexto el cambio de milenio, hay que hacer un nuevo sistema porque la nómina es lo más importante, porque es el presupuesto más grande de PROFECO y de ahí se cuelgan para hacer el nuevo sistema. Rodrigo Romo 27:22
Pretexto válido. Néstor Galván 27:26
Ahora. Dónde está la parte escabrosa. Rodrigo Romo 27:31
¿Dónde está el catch?
121
Néstor Galván 27:31
Se contrata a un grupo externo para desarrollarlo y luego necesitamos contratarlos en PROFECO para que nos soporten ese sistema. Ahí hay cotos de poder. Hago el sistema para manejarlo como quiera. Rodrigo Romo 28:11
Todavía los últimos coletazos de esas prácticas se vieron en este año, algo así. Néstor Galván 28:20
En marzo. Rodrigo Romo 28:20
Cuando querían salirse del sistema otra vez. Néstor Galván 28:23
Se salieron del sistema. Rodrigo Romo 28:29
Un fantasma que no nos deja. Néstor Galván 28:29
Todo eso tiene que ver con la parte cultural. Rodrigo Romo 28:38
Finalmente, yo me acuerdo desde hace un buen rato, de las primeras presentaciones que yo te vi a ti, tienes previstas las etapas del SIIP y toda esta historia. ¿Qué pasó con eso? ¿Llegaron a un esquema de planeación aceptable? ¿Cuáles eran los supuestos? ¿Cuáles eran las consideraciones de bueno, sobre esta parte no tenemos más información para planificar y como va? Néstor Galván 29:02
Bueno. El proyecto está basado en su origen en la parte de desarrollo de sistemas, en la metodología de Unisys, el famoso "Team Method" Rodrigo Romo 29:22
Entonces sí había una metodología. Néstor Galván
122
29:22
También había una metodología por parte de Oracle. Rodrigo Romo 29:27
Pero ahí me lleva a una pregunta. Una confusión. Ahí te va. Si hay algo que fue muy característico del desarrollo del SIIP, a menos que me equivoque, fue el enorme problema de la definición de requerimientos, porque tienes una institución que no sabe qué son los sistemas y lo pones a trabajar en una definición de requerimientos y a lo largo del proyecto se van dando cuenta de que no era exactamente lo que tenían en mente. Néstor Galván 29:50
No. Pero sabes cuál es el problema ahí. Regresamos al principio. La falta de definición de procesos, real. No existió. Rodrigo Romo 30:18
¿Pero eso no lo habría resuelto una metodología adecuada de definición de requerimientos? Habría brincado en dos minutos. Una metodología de esas te lo habría diagnosticado de inmediato. Néstor Galván 30:37
Sí, pero cuál es la problemática. Lo que te dije hace rato. Tú le dices al consultor los señores van a hacer lo que tú le dices. En tus requerimientos le pones lo que tú quieras. En las bases de licitación, como en todas las bases, en un anexo técnico, se había hecho un trabajo de investigación para ver cuáles eran los procesos con los usuarios para que también el consultor pudiera medir. Se hacen el primer requerimiento con los usuarios. Pero allí entra ese componente que no sé cómo llamar pero es "yo voy a jugar a la mentira que siempre he jugado". Rodrigo Romo 31:33
Ok. Entonces vienen ahí dos puntos importantes. Uno, se aceptó pero al mismo tiempo te liberó, como administrador del proyecto, los cambios de los mandos medios y superiores que hubo en los primeros años. Que fueron rompiendo esos cotos de poder. Néstor Galván 31:49
Pues más o menos. Yo te puedo comentar. Rodrigo Romo 31:54
¿Cómo salió [referencia personal]? Néstor Galván 31:54
Aquí viene un cambio interesante. Vamos a hablar de los cambios. [referencias personales]
123
Llega [referencia personal] y se pone bien la camiseta del proyecto. Néstor Galván 37:43
Ella traía una visión y aquí sí, regresando a la parte cultural, vivió en Estados Unidos, y sabe lo que es este tipo de proyectos. Yo creo que era la única que, como cabeza, se metió en serio. Entonces, cambios dolorosos, pero traía la visión de entrarle al proyecto. Yo creo que también traía, desde mi punto de vista, una característica importante es que ella había trabajado en una empresa de tecnología. Bell y Motorola. Conoce lo que son sistemas. Conoce la parte de tecnología y también conoce la metodología para este tipo de sistemas que, a final de cuentas, están desarrollados para una empresa, y más que otra cosa, para una empresa norteamericana. Néstor Galván 39:10
Creo que fue la primera de los procesos sustantivos en tomarlo en serio. Porque desgraciadamenten en la CGA todavía me lo descargó todo a mí y yo no podía luchar con mis homólogos. [referencias personales] Un punto bien importante a comentar que no te había comentado. Recursos Humanos, el sistema de nóminas. ¿Cuál fue un motivador para la gente de Recursos Humanos, para defender a su sistema? Es éste: tenían ellos como visión, respetable, nosotros tenemos la responsabilidad DEL sistema de Recursos Humanos del Gobierno Federal. A la hora de defenderlo, a capa y espada, los requerimientos estuvieron mal. Y obviamente el "tortugueo", el paso de tortuga fue evidente en la parte del desarrollo. Me comenta la gente de Unisys, llegaban a quejarse. Es que tengo reunión con [referencia personal] y no se aparece. Y el señor está hablando por teléfono. No es la manera de hacer requerimientos, no le interesa. Había "SIIP"'s en informática. EL titular de CGA había dado la instrucción, se bajan de informática, [referencia personal] Yo era el competidor más fuerte para ellos. Eso se acaba de terminar apenas hace un mes. Comentábamos, la parte de las cabezas. Cómo una cabeza, en la parte administrativa, le interesara y que le entrara. La parte de los señores de Jurídico no tenían un sistema. Entonces, lo que llegara era bueno. Había un sistemilla, allí incipiente, pero lo que llegara era bueno. Eso me pasó con Recursos Materiales. Si recuerdas, el SIIP en 2003 sale con Adquisiciones y Presupuesto. Rodrigo Romo 43:00
Ellos iban de gane. Néstor Galván 43:43
Problemática seria. No lo tomaron en serio. No les interesaba. Lo que hicimos fue caminando, ir a las diferentes áreas. Cuando estábamos haciendo las primeras pruebas llegas a un área y le dices al encargado. Estamos viendo esto. ¿Y ahora qué voy a hacer yo? El sistema me va a reemplazar. Y la verdad es que parte del costo de esto es que gente se va a tener que ir. O al menos, quitarla del área. Rodrigo Romo 44:38
Lo cual te lleva a la pregunta forzosa. Cambio y cultura del cambio.
124
Néstor Galván 44:47
No sirvió. Esa es mi respuesta antes que me preguntes. [referencia personal] Rodrigo Romo 44:56
Yo vi que hicieron rondas de capacitación y todo eso. Néstor Galván 44:56
Empezó, pero no hubo un seguimiento. No hubo un seguimiento del manejo del cambio. Ahora, ahí tocas un punto muy importante. Ahí hubo un conflicto de intereses bien grueso. No podías poner al área de Recursos Humanos en la parte de manejo del cambio. Rodrigo Romo 45:27
Claro, porque eran los últimos que querían el cambio. Néstor Galván 45:29
Exactamente. Y aparte, lo que pasaba es que los encargados de las áreas tampoco estaban casados ni con su trabajo. [referencias personales] Néstor Galván 47:18
[Unisys] Su trabajo es integrar, vamos a llamarle subcontratar. Unisys pone el nombre, contrata a quien haga la chamba. Yo creo que al inicio hubo una buena amistad con el proyecto. A finales de 2003 empezó la debacle. Ahora, definitivamente el proyecto en si, por las necesidades, por los requerimientos que pedimos no había experiencia en el país. Esto es, un sistema, un CRM que tuviera un desarrollo del tamaño de PROFECO no existía. Hay que recordar que PROFECO es el primer CRM del Gobierno Federal, de ese tipo. Está por ahí un desarrollo en Presidencia, pero ya en serio, es el primero. Afortunadamente es el que está funcionando. Pero la problemática es que Unisys no evaluó bien a la gente que iba a desarrollar el proyecto. Si bien es cierto que vas a requerir forzosamente especialistas en la herramienta, el problema fue el gerente, el Senior. No hubo un consultor senior que verdaderamente conociera de procesos. Ahí fue un problema serio. Nos trajeron las credenciales, pero desgraciadamente no dio el ancho. Por eso, tuvo que entrar [referencia personal]. Y el trade off fue te hago las bases pero tú haces el sistema de Jurídico. Afortunadamente, los dos temas [inaudible]. Entonces, cuál es el problema. El no contar con la experiencia real para desarrollar un sistema de este proyecto. De las personas que contrataron, porque me queda claro que Unisys ha desarrollado proyectos muy fuertes en el mundo. Rodrigo Romo 49:47
Fue una mala elección de personal. Néstor Galván 49:49
125
Exactamente. Ahí estuvo el problema. [referencias personales] Rodrigo Romo 51:01
¿BD qué estaba haciendo? Néstor Galván 51:03
El CRM, la parte de Servicios. Rodrigo Romo 51:06
¿Lo dejó a la mitad? Néstor Galván 51:06
No. De hecho, lo terminan, pero con muchos problemas. Unisys, me queda claro que para ellos el costo del proyecto ha sido varias veces más de lo que habían contemplado. Rodrigo Romo 51:24
¿Les salió el costo, finalmente? Néstor Galván 51:24
No. Rodrigo Romo 51:26
¿Perdieron lana? Néstor Galván 51:26
Perdieron. Digo, en voz de ellos, pero no me queda la duda. Perdieron. Rodrigo Romo 51:33
Sí, por el tiempo. Néstor Galván 51:33
Por el tiempo. Rodrigo Romo 51:34
Ahí vienen dos problemas. Uno, cambios de personal que afectaron muchísimo a todos, tanto a nostros como a Unisya.
126
Néstor Galván 51:46
¿Personal de PROFECO? Rodrigo Romo 51:46
Personal de PROFECO y personal de Unisys. Hubo cambios en todos lados. Néstor Galván 51:48
Sí. Unisys en este proyecto tuvo un problema muy serio. Técnicamente, cuando empezamos a revisar el CRM, nos damos cuenta de una problemática seria. Que lo que habíamos solicitado esto es, la esencia de un sistema como el que tiene PROFECO, es precisamente el famoso workflow. El flujo de trabajo es lo principal. En las bases les dijimos "le pueden mover a este sistema parametrizable". En 2004, cuando empezamos a hacer algunas pruebas, nos damos cuenta de que faltaba un elemento visual que habíamos visto en las presentaciones que nos hicieron antes de las licitaciones que era ver precisamente de manera gráfica el workflow. Les dijimos ¿dónde está la gráfica? Y ahí empieza otro problema con los consultores que contrató Unisys. La mentira. Es que ahorita no te lo puedo mostrar pero te lo muestro la siguiente semana. Y yo creo que en esa semana se pusieron a ver qué respuesta les vamos a dar. Llega la siguiente semana y la pregunta es ¿dónde está el workflow? Qué crees. La solución que dimos en PROFECO, o para darle solución a PROFECO, hicimos una herramienta que va arriba del workflow. Modificamos el workflow. Espérate, eso no está en las bases. Una discusión que nos llevó ocho meses, en la que yo involucré Oracle y en la que terminó en un ejercicio de pruebas de stress que se llevó a cabo en mayo 2004 una sorpresa enorme. Dijimos que compramos 700 licencias, dimos las características del equipo y Unisys dijo que aguantaba hasta 700 usuarios. Hacemos las pruebas de stress y en el usuario 19 se colapsa la herramienta. Al 0.5% Ni siquiera al medio por ciento de lo que necesitábamos. Empieza la pelea, traen a un DBA para que haga un tuning y ya sube a 90 usuarios. Se decide vamos a salir y ahí viene otro rollo, con las delegaciones. Rodrigo Romo 55:04
Esa es una historia aparte. Néstor Galván 55:04
Las delegaciones también fueron otro martirio. Las delegaciones tenían historias. Cuando se hizo el cambio que te hablé hace un momento, de SISEQ, en 2001, fue una historia de terror. Llegaron instalaron el sistema, les dieron una capacitación de medio día y al día siguiente vas con el nuevo sistema. A ver cómo le haces. Venían resentidos. Les dices viene un nuevo sistema y obviamente ya están con la espada desenvainada. Y el sistema tiene problemas fuertes, de tal forma que en 2004 yo insistí, señores, hicimos todo el estress, hicimos un tuning a la base de dados, falta el tuning a la aplicación. Si bien es cierto que todo se corre en la base de datos, pero también la aplicación tiene su chiste. No voy a hacerte muy largo el cuento. Desde 2005 hasta junio 2006, accedió Unisys a hacer el tuning a la base de datos. Caso de éxito, en este momento, con la herramienta que dimensionamos [referencias personales] el sistema soporta topes de 465 usuarios. Les dijimos que hicieran un tuning. La respuesta de Unisys es que tienes que meterle
127
fierros. La respuesta clásica del consultor. El caso de este tuning tiene raíz en una de las gentes de BD que nos dicen yo conozco a alguien que puede hacer el tuning. Contratamos a esta compañía en Querétaro, especialistas, que no hacen mas que tunnings a CRMs de Oracle. Es su chamba. Llegamos a una reunión --yo en miles de reuniones había dicho esto que te dije-- la introducción de ellos es les vamos a proponer hacer un tuning a la base de datos de este proyecto. De antemano les adelanto, si ustedes tienen planeado derivado de problemáticas que tienen en su CRM la compra de un equipo, les recomiendo que primero evalúen nuestro trabajo al final del proyecto porque probablemente no sea necesario. [referencias personales] Finalmente viene alguien externo y dice lo que tiene que decir, lo que ha sido mi teoría por dos años. Rodrigo Romo 58:28
¿Qué pasó con el conflicto con Unisys? Se tuvieron que ir a pelear hasta Función Pública. Néstor Galván 58:31
La cuestión era puedes hacerle daño al proyecto. Y echarlo a perder. La apuesta del Procurador fue sacarlo. Ahora tenemos otra vez conflictos, pero ahora tenemos 58 delegaciones trabajando con un CRM nuevo, cuando menos, a pesar de lo que diga mucha gente, se hizo esfuerzos, pero por lo menos un reconocimiento ya existe y hubo una revisión, no fue de a gratis, una apuesta a terminar el proyecto. Pudiste tirar el proyecto incluso desde 2003. Sí Unisys, el sabor de boca que me queda es muy amargo, Me impresiona que una transnacional, o una empresa americana, no la levante. Incluso, les llegué a comentar en broma, oigan en Estados Unidos Unisys está haciendo el nuevo sistema de navegación aérea de Estados Unidos. Yo la verdad la voy a pensar para volar en Estados Unidos. Rodrigo Romo 1:00:01
Unisys México es muy distinto a Unisys Estados Unidos. Néstor Galván 1:00:07
La cuestión era, sí le puedes dar en la torre, pero hay que jugárselas. Un proyecto que yo consideraría que ya empieza a tener éxito, yo lo consideraría. Porque hay otros proyectos, por ejemplo, el del IMSS, que nada más era ERP, valió gorro, igual que en Relaciones Exteriores. Acaban de rescindirle a IBM. A lo que voy es que hay un problema fuerte, pero bien fuerte en México, por parte de las transnacionales que no están sabiendo irse con los consultores que deben. A mí no me queda duda que en México hay talento, pero si te vas por la baratija vas a dar un resultado pésimo. [referencias personales] En Gobierno Federal solamente tiene un precedente, el SAT, y en una tecnología obsoleta en un sistema contencioso, y el otro es PROFECO. Rodrigo Romo 1:01:36
Ese es un punto que me sorprende. ¿Realmente PROFECO, con su posición periférica, oficina humilde, etc., realmente tiene ese nivel en términos de sistemas? Néstor Galván
1:01:51
En término de sistemas, sí. La verdad sí tenemos un sistema muy bueno. El elemento que estamos terminando ahorita es Inteligencia de Negocios, ahí está verdaderamente con lo que iniciamos al principio. La explotación de la información. Ahí es donde puedes verdaderamente conjuntar y explotarla.
128
Apéndice C
Entrevista a la Lic. Hilda García, Coordinadora de Proyecto de la Subprocuraduría
Jurídica, en la PROFECO
25 de abril de 2007
Rodrigo Romo 00:00
¿Cuándo te incorporaste a PROFECO? Hilda García 00:11
Para empezar, yo trabaja en la empresa que servía de intermediaria entre PROFECO y Unisys, Ergo. Rodrigo Romo 00:22
Ok. Ergo, con los californianos. Hilda García 00:23
Yo entré en marzo de 2005, con [referencia personal]. Ahora sí que estuve viendo todo desde afuera, porque no era de PROFECO y tampoco era de Unisys. La función que yo tenía era mediar entre lo que pedía PROFECO y lo que quería hacer Unisys. Era decir, o vas mucho para allá, PROFECO, o no se puede hacer en el sistema, o decirle a Unisys sí se puede hacer. Rodrigo Romo
1:01:51
En término de sistemas, sí. La verdad sí tenemos un sistema muy bueno. El elemento que estamos terminando ahorita es Inteligencia de Negocios, ahí está verdaderamente con lo que iniciamos al principio. La explotación de la información. Ahí es donde puedes verdaderamente conjuntar y explotarla.
128
Apéndice C
Entrevista a la Lic. Hilda García, Coordinadora de Proyecto de la Subprocuraduría
Jurídica, en la PROFECO
25 de abril de 2007
Rodrigo Romo 00:00
¿Cuándo te incorporaste a PROFECO? Hilda García 00:11
Para empezar, yo trabaja en la empresa que servía de intermediaria entre PROFECO y Unisys, Ergo. Rodrigo Romo 00:22
Ok. Ergo, con los californianos. Hilda García 00:23
Yo entré en marzo de 2005, con [referencia personal]. Ahora sí que estuve viendo todo desde afuera, porque no era de PROFECO y tampoco era de Unisys. La función que yo tenía era mediar entre lo que pedía PROFECO y lo que quería hacer Unisys. Era decir, o vas mucho para allá, PROFECO, o no se puede hacer en el sistema, o decirle a Unisys sí se puede hacer. Rodrigo Romo
129
00:58
Ahora. ¿Directamente a la parte jurídica? Hilda García 01:03
Directamente a la parte jurídica. Yo nunca entré en Servicios. Mas que en el momento en que hicimos la integración. La integración la hicimos a final del 2005, entre Servicios y Jurídico. Fue algo histórico, por la relación política, que hubiera esa cooperación.Entonces, en diciembre de 2005, Ergo decide dejar PROFECO. Yo no sé la historia real, pero el caso es que deja PROFECO y a mí me proponen quedarme en PROFECO haciendo lo que él hacía, en su lugar y terminando con el sistema. Para ese entonces, el sistema estaba todavía a la mitad. Decidí aceptar. Entro a PROFECO en enero de 2006, propiamente. Llevo un año, cuatro meses, casi cinco. Rodrigo Romo 03:00
Más los ocho meses. Hilda García 03:00
Más los ocho meses con Ergo. Rodrigo Romo 03:35
Ok. Jurídico. ¿Cómo viste Jurídico incorporarse al sistema? Hilda García 03:42
Ok. Rodrigo Romo 03:44
Desde el principio. ¿Qué imaginaban ellos del sistema? ¿Qué obstáculos encontraron, empezando por ellos mismos? ¿Cómo le fueron haciendo para ir entendiendo lo que implicaba incorporarse a un sistema? Hilda García 03:59
Mira. Yo que ví los requerimientos de Jurídico déjame decirte que pidieron muchísimo más de lo que pueden realizar. Los requerimientos de Jurídico y el sistema de Jurídico es un monstruo que implica todas las posibilidades que existían en la Ley, que existían del Código Federal, porque resulta que a mediados de 2006 cambiaron el Código Federal a la Ley de Procedimientos de lo Contencioso Administrativo. Y eso no lo tiene el SIIP. Pero todo lo demás lo tiene. Es un monstruo que tiene todas las posibilidad, de la posibilidad, de la posibilidad. Enorme. Rodrigo Romo 04:48
¿Y qué tan efectivo era plantear el desarrollo así? A lo que me refiero, para replanteártelo. Eso
130
demuestra que tienes a un abogado leyendo la Ley. Típico de ellos. Pero pensando en un sistema, ¿qué tanto crees que estaban entendiendo lo que era la definición de requerimientos? Hilda García 05:11
Yo creo que se fueron más allá. El problema aquí es que la definición del requerimiento nunca la hubiera ideado una mente como [referencia personal] ni aún como [referencia personal]. La ideó toda Ergo. Hizo todos y cada uno de los requerimientos. En su afán de abarcarlo todo, hizo que el desarrollo se hiciera muy lento. El SIIP Jurídico pudo salir mucho antes de lo que salió, mucho menos tiempo. Sin embargo no fue así, porque en lugar de enfocarnos en la operatividad, porque Contencioso hace, sus procesos son muy lineales y son muy repetivivos y el 90% de las ocasiones lo hace así. De una manera, siguiendo el paso del 1 al 5. Muy pocas veces se desvía el punto 1b o al punto 2c. En lo que hacíamos nosotros todo el mapeo de estos puntos, de estas ramitas, nos llevamos muchísimo tiempo. Y ese fue una muy clara cuestión de un obstáculo que podríamos llamarlo en el desarrollo y diseño del sistema. Porque pedimos tanto que llegó el momento en que ninguno de los abogados sabía de dónde jurídicamente salía esto. Sólo [referencia personal]se sabía la Ley al derecho y al revés. Era el único que podía decir "con tal recurso de revisión que se te desecha, pones un recurso de queja y contra eso pones un amparo indirecto y contra eso." ¿Sí me entiendes a qué nivel nos fuimos? Y ese fue un obstáculo que nos tardó mucho tiempo en desarrollarlo. Otra cuestión fueron las plantillas. Tuvimos muchos meses de discusión para ver si las plantillas eran cerradas o abiertas. Entonces hicimos muchas pruebad de unas plantillas cerradas. Unas plantillas jurídicamente cerradas requerían de muchísimos campos que fueran importados al sistema, muchísimas referencias, muchísimas tareas y al final nos dimos cuenta que no se podía sustituir el razonamiento del abogado. A fuerzas las plantillas tenían que estar abiertas. Ya que hicimos ese discernimiento, porque déjame decirte que las plantillas de Servicios eran cerradas, entonces cuando se enteraron que las nuestras iban a ser abiertas dieron un grito en el cielo. Porque les costó un año convencer a los usuarios de que no pueden cambiar las plantillas. Y que llegue Jurídico y que puedes quitarle a la plantilla, pegarle, moverle lo que quieras no hay ningún problema. Entonces ellos de hecho, si tuvimos ese problema de decidir si eran cerradas o abiertas, fue porque ellos decidieron que sus plantillas fueran cerradas. Al final decidimos que fueran abiertas. Ya después que hicimos esto decidimos que la fundamentación en lo que es recurso de revisión administrativo sería automática. Esto es, que el abogado no tendría que capturar cuál es el artículo del estatuto que le corresponde a tal o cual delegación, o el artículo de Ley de Procedimiento Federal Administrativo que le corresponde a tal o cual puesto. Entonces, hacer esta automatización nos llevó fácil medio año, en decir este acuerdo, hacer una matriz que dijera estos acuerdos, con este pueso, en este lugar, dan esto. Y así. Esas cuestiones fueron las que más duras. Y se a eso le aúnas que el personal de jurídico sólo estuvo disponible de seis a nueve durante todo el proyecto. De seis a nueve de la noche era todo lo que trabaja jurídico. No trabajaba ni una hora más en el SIIP. Rodrigo Romo 09:52
Esto me lleva a mí a una pregunta muy específica. Bueno, varias observaciones. La primera es en la experiencia que me tocó a mí. Era my notorio que, en la ignorancia de lo que es un sistema, los abogados estaban haciendo un esfuerzo horroroso creyendo que les iban a quitar el sustento y entonces estaban tratando de meter todo el marco jurídico posible al SIIP, lo cual no es la manera más lógica de resolverlo, pero por pura ignorancia que es válida, también. Pero también me demuestra que no centraron sus esfuerzos en corregir el proceso. Porque precisamente hubo
131
reuniones donde estuve presente, donde tú estuviste, en donde era notorio el mal flujo del proceso. Y que no estaban encontrando cómo convertirlo en electrónico y que funcionara. Entonces, sí me importa mucho saber qué tanto estaban conscientes de que estaban construyendo un sistema, en vez de estar simplemente recitando leyes. En vez de decir simplemente lo hago al día de hoy así. Porque el punto es, no podían llamarse a sorpresa, porque ya había pasado el desarrollo del ERP, ya había pasado el desarrollo de Servicios, y al llegar ellos qué conclusiones sacan de la experiencia previa, de modo tal que entiendan que lo que ellos iban a hacer es diferente y no me parece que tuvieran eso claro. Hilda García 11:31
Mira. Ninguno del personal Jurídico tuvo contacto directo con alguien que hiciera sistemas. Ya no digas PROFECO, en su vida. Ellos habían tenido contacto con Word, con Excel, era mucho. Entonces no tenían ni idea de cómo querían que se viera. Yo creo que más que nada fue una imposición del alto mando "Tienes que hacerlo". De ahí algo que ellos los convenciera a ellos de que lo tenían que hacer. Yo creo que de ahí vino el "bueno, tiene que salir como sea" Y en ese "como sea" fue esto sale mientras no cambie la forma en que yo hago las cosas. Tiene que salir como yo lo estoy haciendo, porque además en Jurídico existe la firme mentalidad de que lo que hacen lo están haciendo perfecto. Y no tienes ningún error. El área de Jurídico siempre tiene el sentimiento y la certeza de que ellos tienen la razón y de que como ellos lo hacen está bien. Entonces, decirles --se intentó, ¿eh?-- como asesor. O sea, yo te estoy hablando porque yo viví dos épocas. La época en que era asesora y les podíamos decir no, no es así, o estás haciendo un doble trabajo, un doble esfuerzo, se podría hacer así. Y en esa época era "no, nosotros lo hacemos bien y lo hemos hecho toda la vida y así hemos salido toda la vida. Entonces, tú como asesor, lo que se hizo en ese momento dejar constancia de que se le ofreció una solución alternativa, se le ofreció que se hiciera de esa manera, pero que el usuario no lo quiso hacer así. Para que cuando el usuario venga y diga "es que no me dijiste" Sabes qué, yo sí te dije, yo te lo documenté. Tú elegiste la otra opción. Esto fue en el tramo cuando fui asesora y les podía decir eso. Cuando yo pasé a ser parte de PROFECO, no me preguntaban. Nosotros lo queremos así y así es. Ya como parte de PROFECO es no preguntes, no cuestiones, lo queremos así. Un ejemplo muy claro que te voy a decir. Cuando nosotros hicimos el juicio de nulidad, las delegaciones se tienen que adherir. Entonces, nosotros propusimos, en ese tiempo que yo todavía era asesora, se propuso que en cuanto se diera de alta el juicio de nulidad, porque comúnmente los juicios de nulidad llegan primero a las delegaciones, se diera de alta en automático el juicio de nulidad en oficinas centrales. Es decir, que los abogados de oficinas centrales ya no tuvieran que capturar lo que ya había capturado la delegación. No lo quisieron, argumentando que las delegaciones tienen muchos errores, que las delegaciones no llevan el juicio de nulidad. Rodrigo Romo 15:08
No es del todo infundando. Hilda García 15:08
No es del todo infundando, pero por ejemplo ahorita hay una doble captura. Ellos capturan toda esa información y Jurídico la tiene que volver a recapturar. Entonces, como esos hay miles. Rodrigo Romo
132
15:36
Yo me acuerdo de varios. Me acuerdo del asunto del control de gestión, que era absurdo, lo de oficialía de partes. Hilda García 15:42
Por ejemplo, haz de cuenta, [referencia personal] nos pedía una cosa así "Saben qué, yo recibo a veces los comunicados dos días antes y les pongo el sello, lo recibo el lunes, pero yo le pongo el sello de recepción del miércoles. Para ellos nunca estuvo mal la forma en que diseñaron. Nosotros como asesores les vimos varios detalles, que ellos nos dijeron cambiar, y se tuvieron que quedar. Al final, el cliente paga. Tú le puedes aconsejar, pero nadie experimenta en cabeza ajena. Entonces, nunca habían hecho un sistema, nunca habían utilizado un sistema y si a eso le aunamos que ellos son perfectos, entonces realmente no hubo un gap entre el To be y como se hace. Y empalmaras el to be con el cómo se hacer y las diferencias y dijeras esos gaps son los que vamos a hacer bien ahora. Rodrigo Romo 16:57
Recordarás el par de reuniones ríspidas al respecto. Hilda García 17:29
De hecho, nosotros le dijimos es que el sistema es un sistema exactamente para eso. Rodrigo Romo 17:37
Para eso. Para que no pongas los sellos de recibido en fechas que no son. Pero bueno. Ok. Ya tenemos claro cuál era el panorama para definir los requerimientos. Lo cual de ahí parte todo. Y de ahí se sigue. Con todo ustedes ya se habían montado en una plataforma probada, entonces los ajustes fueron relativamente pocos. Considerando que a Servicios le llevó varios años, a ustedes les llevó menos tiempo. Hago el comentario, porque desde mi posición, no debería haberlos contemplado en el mapa en un buen tiempo y de repente ya estaban ahí dando lata. ¿Y éstos qué hacen aquí? Finalmente se quitaron de encima todo lo que Servicios ya había hecho. Hilda García 18:31
De hecho, una de las premisas que tenía Unisys cuando llegó decía, es que esto así se hace en Servicios. Por eso no lo podemos modificar. Esa era la premisa que traía Unisys. Rodrigo Romo 18:49
Sí claro. Era barato para ellos. Hilda García 18:51
Es una historia que no sé si te la sepas. Pero Jurídico es un gol a Unisys. Un enorme gol a Unisys. De hecho, Unisys, jurídicamente se le pagó por hacer el ERP, BI, Albalá CRM de Servicios. Entonces, cuando se hizo el CRM de Servicios se dieron cuenta que había un gap,
133
porque Servicios era la única que genera el Acta y regresa el cumplimiento. Pero esa parte es Jurídico. Entonces, ahí, con el pretexto de que hacía falta esa parte de Servicios, nos colgamos nosotros, pero no sólo con el procedimiento que viene de Servicios, sino todo. Rodrigo Romo 19:48
De hecho, ya cuando tienes toda la evidencia documental a la mano, resulta que no fue tan buen negocio para Unisys, en términos monetarios. En términos de aprendizaje, mucho. Ya al siguiente cliente que tengan le aplicarán un montón de restricciones, pero es muy claro que PROFECO le sacó mucho más al contrato con Unisys de lo que ellos hubieran querido. Hilda García 20:15
De hecho, yo creo que esa es la razón por la que hubo tantas conciliaciones y por eso nunca nos fuimos a un proceso de castigar a Unisys realmente. Siempre se le dio puntapiés, no sé, un ligero golpecito, pero jamás un knockout que fuera a rescindir el contrato. Rodrigo Romo 20:37
Claro. Ya los tenías ahí, finalmente. Te estaban haciendo las cosas. Platicando con Ángeles Jasso, me acuerdo que en la definición de requerimientos la palabra mágica era que quedara a satisfacción de Servicios y pues era muy difícil que quedara a su satisfacción. Hilda García 21:15
Si te pones a ver desde esta perspectiva, Jurídico resultó un año y medio más de pagar consultores, de muchas cosas para Unisys. Rodrigo Romo 21:29
Sí. No fue negocio monetario para Unisys, eso es muy claro. A la larga, escasamente habrán podido obtener algún beneficio. Según yo, no. Por lo que cobraron, contra los sueldos de todos los que estuvieron trabajando por tanto tiempo, no estoy muy seguro que hubieran obtenido algo relevante. Salieron en números negros, pero ganaron poco. Hilda García 22:05
Yo creo que el punto más débil que tuvieron ellos fue ser mal integradores. Yo he estado del otro lado, como consultor, y creo que ellos no supieron integrar al equipo de trabajo. A qué me refiero, a que no fue Unisys quien hizo todo el trabajo en PROFECO, sino que Unisys a su vez subcontrató a los españoles para Albalá, a los ticos para el CRM, a no se quién para el ERP, y a otro grupo de mexicanos para el BI, y no supo hacer esa integración entre esos equipos. O sea, ellos deberían de sentarse y decir tú ya hiciste tu parte en el ERP, pero no es suficiente porque esto está ligado al CRM, está ligado al Albalá, tienes que ligarlo. Entonces, lo que pasó aquí --y fue muy claro-- yo ya hice mi parte, dijo cada quién, y nos vamos. Entonces quedaron todos los módulos aislados, como isletas. Rodrigo Romo
134
23:19
Y es Unisys quien tiene que integrarlos, finalmente. Hilda García 23:21
Unisys al final se le pagó por algo que sirviera, no por un Frankenstein, que fue lo que obtuvimos. Rodrigo Romo 23:29
Pero un Frankenstein por culpa de PROFECO. Porque aquí si quiero dejar en claro para Unisys que es culpa de ellos, pero al final del día no fueron capaces de marcarle a PROFECO exactamente qué tenía que dar para darles el producto final. PROFECO se aprovechó de n cantidades de oportunidades conforme fue aprendiendo lo que significaba desarrollar sistemas. Porque tú tienes a PROFECO en el minuto 1, que no tiene la menor idea, escasamente con computadoras diez minutos antes, a la segunda o tercera generación que ya habían agarrado el patín muy bien, de qué se trataba, y Unisys no cambió su postura en ningún momento. Hilda García 24:08
Pero es que se fue, desde el punto de vista del consultor, un error de ellos. Rodrigo Romo 24:14
Claro. Fue un error muy claro de Unisys. Hilda García 24:14
Porque si ellos hubieran integrado, no les meten ningún gol. Hubieran sabido desde el principio que lo de CRM ya se había dado y entonces le pegaba al BI, le pegaba a Albalá, no hubieran aceptado nunca. Nunca hicieron un control de cambios para decir este cambio sí, PROFECO, te cuesta tanto. Entonces fue que PROFECO los vió como un Santa Claus. Rodrigo Romo 24:43
Y se les colgó encima durísimo. [referencia personal] ¿Cómo fue la integración del SIIP Jurídico con el resto? Con el resto de los módulos. Hilda García 25:22
Con el resto de los módulos jurídicos, buena. Me refiero al BI, Albalá. Rodrigo Romo 25:32
¿Están usando BI o todavía no? Hilda García 25:34
135
Todavía no lo estamos usando, en forma, tiene unos detallitos, pero el resto de los módulos de la Subprocuraduría Jurídica, el entendimiento y la integración fueron naturales, porque están bajo un mismo líder, que no permite opiniones distintas [referencias personales]. El problema fue hacer la integración con algo distinto, que no fuera jurídico, esto es, Servicios. La integración con Servicios fue una pesadilla. Políticamente hablando y tecnológicamente hablando. Voy a empezar con la parte tecnológica. Y no es que me guste echar culpas. Pero cuando quisimos hacer la integración, el equipo de Servicios ya se había ido. El equipo de Servicios de Unisys ya se había ido con todo el know how de saber dónde estaban mapeados los campos, cómo estaba hecho el flujo, con todo ese know how se fue. Cuando quisimos hacer la integración y necesitábamos algunos datos de Servicios, resulta que nadie sabía de dónde sacarlos. Y obviamente, la persona que estaba haciendo el CRM Juridico de Unisys, dijo "a mí no me corresponde ni tengo por qué meterme a hacerlo. No tengo ni idea. No voy a leerle el código para ver dónde está, no voy a ver los flujos, no me voy a meter a eso. No lo sueñes. Entonces ahí hubo una discusión muy grande entre Unisys y PROFECO porque Unisys dijo la integración no me toca, ya que vió el paquete y se dió cuenta que los papás del SIIP de Servicios ya se habían ido. Y que los papás de SIIP de Jurídico no querían adoptar ese niño. Después de varias pláticas, se acordó que lo tenían que hacer. El tiempo que les llevó al personal de Jurídico entender el SIIP de Servicios y conectarnos con ellos, fue noviembre 2005, junio 2006. Tranquilamente. Esa, la parte tecnológica. Ahora viene la parte política. La parte política: nadie quería ceder. Yo lo hago así y yo lo hago así. Entre Servicios y Jurídico. No había punto intermedio. Yo lo que siento es que nunca se tomó la opinión de quien lo hace, que es Delegaciones. Rodrigo Romo 28:56
Claro, siempre es el perdedor en toda esta historia. Hilda García 29:02
Yo creo que desde que nació PROFECO es el perdedor. Rodrigo Romo 29:05
El perdedor preferido. Hilda García 29:06
Sí, el preferido. Realmente, ni Jurídico ni Servicios iban a hacer esa parte. Eran las delegaciones, las delegaciones son quienes realizan los actos, quienes resuelven los recursos de revisión, a quienes se les piden las cosas. Rodrigo Romo 29:20
Los que hacen la chamba, pues. Hilda García 29:22
A ellos nunca se les preguntó nada. Se les invitó a las pruebas Alfa, pero para que vieran cómo estaba el sistema funcionando. Con los requerimientos que se habían marcado. Nunca se les
136
preguntó ¿Está bien el flujo? Ellos fueron a verificar que ese flujo funcionara. Eso fue yo creo que un gran problema. Porque si a ellos se les hubiera preguntado a lo mejor ellos habrían podido alzar en este momento que era el más preciso la mano y decir no. No podemos hacer esto porque nos falta eso, y sobre todo ellos que ya tenían la experiencia de Servicios. Rodrigo Romo 30:09
Eso ya lo tuvieron que ajustar después. Hilda García 30:12
No lo hemos ajustado. Rodrigo Romo 30:18
Deja interrumpirte. Son pocas delegaciones las que tienen Jurídico todavía. Hilda García 30:22
¿La plaza? Rodrigo Romo 30:23
Deja la plaza. Que funcionen con jurídico. Hilda García 30:25
La mitad. Es increíble. Rodrigo Romo 30:30
Más de lo que esperaba. Hilda García 30:31
Lo sé. La mitad ya funciona con el SIIP jurídico. 22 no jalan con el sistema. Hubo varias discusiones donde Jurídico decía lo que Servicios debía hacer. Y se hicieron al revés. Lo más claro, te voy a decir un ejemplo. Servicios decía que Jurídico, como asistente en los eventos que le tocaba, tenía que asistir desde el Director General, Directores de Área, y que su asistencia consistía en hacer la misión, hacer la sustanciación del recurso, hacer las pruebas, en pronunciarse sobre la suspensión, todo. A lo cual Jurídico contestó "pues bien, si tú opinas eso yo te contesto con mi estatuto de julio de 2006, dándote facultades para que tú hagas eso". Rodrigo Romo 32:09
Las luchas interburocráticas son maravillosas. Hilda García
137
32:10
De ese nivel estuvo la integración. Fue una lucha política que Jurídico ganó desde mi humilde punto de vista, por la mala. La ganó por la mala, pero yo siento que al final terminamos perdiendo, porque al no darnos cuenta de que ni las delegaciones ni Servicios tenían esa capacidad, realmente las condenamos a un sistema que no pueden utilizar. Es algo que nunca han hecho, se les delegó también todos lo amparos. Antes Jurídico respondía todos los amparos que llegaban, de todas las delegaciones. Y a partir del SIIP se les dijo tú respondes los amparos. Ya no digas que ellos no estuvieran preparados para un sistema. El problema aquí en Jurídico no es el sistema, el problema es el nivel del usuario para entender el proceso de negocio. Si es que se le puede llamar proceso de negocio a esto. El proceso jurídico. Del 90% de las llamadas que tengo son de no sé cómo utilizo el sistema, cómo hago un amparo, cómo contesto un recurso de revisión. Hilda García 34:12
¿Cómo vas a querer construir, y ese fue un problema muy palpable en el módulo de BI, este sistema si todavía no sabes si de donde vas a sacar la información sirve?. Rodrigo Romo 34:29
Porque es muy distinto la definición de necesidad de la cabeza. Es la primera vez, por primitivo, por insuficiente que sea el BI Jurídico, es la primera vez que van a tener cifras. Punto. Hilda García 35:02
¿Sabes por qué no sirve el BI Jurídico? Porque ya sirve, pero no le gustan las cifras a [referencia personal]. Entonces dice no sirve. Está haciendo algo mal el CRM. Y ya lo verificamos y no estamos haciendo nada mal. Las cifras son las que son. Rodrigo Romo 35:25
Ahora, sabes a dónde van a caer esa parte de BI. Con el Procurador. La idea es si tienes una cabeza que diga quiero estas cifras, las áreas no tienen mucha opción mas que proporcionarla. Que eso es muy distinto a iniciativa privada. En IP las áreas están deseando tener la información en todo momento para poder dirigir sus pasos. En gobierno no. Porque la obligación jurídica es primero, antes que la eficiencia en la administración. Eso es tal vez la gran maldición de nuestro país. Porque no te riges contra un criterio de eficiencia sino simplemente se cumple. Hilda García 36:22
¿Y cuánto te cuesta? Rodrigo Romo 36:22
Es inexistente. Tienes que cumplir con lo que te pide la ley, no importa cuánto. La gran diferencia a la hora de desarrollar, porque son filosofías completamente distintas. Por eso a uno le preocupa cumplir con todo el marco jurídico en vez de cumplir con el resultado. Cualquier persona sensata en el planeta, del lado de la IP, habría buscado "si te cubro 90% del asunto, pues
138
es más que suficiente". Y nos la llevamos en dos meses y de ahí en adelante. Pero no podía jurídico entenderlo. Por que no está partiendo del mismo punto de partida. Hilda García 37:12
Este es el problema de BI. No puede salir BI al mundo hasta que no se cuadren las cifras. Y el problema es que no se te van a cuadrar y menos ahora, y es una de las cosas que les he dicho. Estas cifras no te sirven para decir estoy haciendo mal mi trabajo. Digo ¿cómo sabes si este 30% que tú estás ganando contra 70% que estás perdiendo? Ahí mismo el BI te está diciendo que lo estás perdiendo porque es una mala notificación. ¿Qué tienes que ver tú con una mala notificación? ¿Cuándo vas a poder defender una mala notificación? Nunca. ¿Cuándo vas a poder defender un acto que se ve a leguas que deja en estado de indefensión al proveedor? Nunca. Entonces, no te debe dar pena decir estoy ganando el 30% porque ese 30% es el que puedes ganar. El otro 70% no puede. Rodrigo Romo 38:13
Pero ahí hay un problema muy importante. Y es que Jurídico tiene que empezar a entender lo que significan los números. Es una tarea adicional. Hilda García 38:24
Ya se los dije, varias veces. Deben ser la punta de lanza y decir estamos fallando aquí. Qué vamos a hacer. ¿Creamos una oficina de notificaciones o damos otra vez capacitación a las delegaciones? Rodrigo Romo 38:45
Porque le implica a Jurídico entender los números. Ahora que eso es un punto clave si piensas en la definición de requerimientos. Al final del día BI funciona con la información que definiste desde un principio. Hilda García 38:58
Ahora tambien, en Jurídico los números realmente que yo quisiera saber, porque desde mi punto de vista le servirían, son unos seis o siete indicadores. Nosotros tenemos treinta y cinco indicadores. ¿Cómo le puedes sacar jugo a treinta y cinco indicadores? Un indicador que lo ves y dices. Hay indicadores que están siempre en ceros porque hasta ahorita no hemos recibido este tipo de juicios. Rodrigo Romo 39:41
Claro. Si están contemplando el universo jurídico completo, es francamente imposible que te lleguen esas cosas. La excepción no es la regla, por definición. Hilda García 39:53
Y van a quedarse en ceros, años y años.
139
Rodrigo Romo 40:00
Te comento, en el caso de Transparencia, nada más para poner un contraste. La Ley establece un procedimiento de corrección de datos personales. ¿Sabes cuántas solicitudes hemos recibido a la fecha? Ninguna. Cero. ¿Tú crees que en algún momento me preocupé por desarrollar algo para un uso cero? Si llega el caso eventual, lo trataremos de manera manual y se acabó, porque no voy a desarrollar, con el costo que ello implica, una herramienta que no voy a usar. Hilda García 40:36
Eso es. Yo creo que el sistema de Jurídico eso es lo que tiene. Pudo haberse terminado antes. Totalmente. Eso ya pasó y no podemos hacer nada por los requerimientos. Yo cuando llegué ya estaban los requerimientos, antes de 2005. Y ya por eso no se puede hacer nada. Rodrigo Romo 40:57
Eso le tocó a [referencia personal] Hilda García 40:57
Eso sería una muy buena pregunta. ¿Por qué extenderse tanto? Yo tengo una teoría. Muchas veces, cuando estábamos en esas pláticas con Unisys, oía una vocecita que decía "si no lo haces así, te puede caer Contraloría". De hecho, déjame decirte --este es un dato para sorprenderte-- de los casi dos mil requerimientos que hizo jurídico, fueron casi dos mil requerimientos, solamente no se hicieron cuarenta. Rodrigo Romo 41:53
Qué absurdo. Hilda García 42:00
¿Puedes imaginar? El monstruo que es... Rodrigo Romo 42:11
Para un uso cero. Hilda García 42:11
Realmente está sobrado y está sobrado hasta para los propios abogados. Rodrigo Romo 42:21
Por supuesto, porque les están colocando todas las opciones. Hilda García
140
42:27
Cuando empezamos a capacitar había abogados que decían yo no sabía que se podía hacer jurídicamente esto. De hecho, todavía, en delegaciones --ya aquí en oficinas centrales no-- hay abogados que hablan y dicen gracias porque el sistema me dijo qué tenía que hacer. A ese nivel de detalle está diseñado el SIIP Jurídico. Rodrigo Romo 43:10
No me iría con demasiado entusiasmo por ahí, porque puede ser el nivel del abogado. Hilda García 43:11
Hay abogados que te dicen es que tiene mil estados, mil caminos. ¿Por dónde me voy? Y que no sabe y no tuvo nunca idea. ¿Y por dónde me voy? ¿Qué hago? [...] Yo siento que para el nivel de usuarios que había. Rodrigo Romo 44:15
Para la madurez del propio proceso, incluso. Hilda García 44:17
Del propio proceso, yo creo que el SIIP no puede quedar de otra manera. Digo, dentro de las limitantes y las restricciones que tenía. Y no es porque yo sea su mamá, pero fue lo mejor que pudo haber quedado. Ahora, que tienes muchas áreas de mejora, tiene muchas áreas de mejora el sistema. El problema es que para mejorarlo habría que mejorar primero al usuario que lo utiliza. El usuario que lo utiliza debería de saber qué está haciendo. Es como si tú quieres sentar a alguien a hacer un estado de resultados, le pones el sistema y el sistema hace el estado de resultados perfecto, pero él no sabe qué es un gasto y qué es un costo. Jamás, nunca, le va a cuadrar el sistema. Nunca le va a salir un estado de resultados. Y siempre le va a echar la culpa al sistema. Eso es lo que nos pasa aquí. Jurídicamente los abogados no tienen la perspicacia ni el conocimiento para los procesos que están realizando. Cuando quieren llegar al sistema, no lo pueden hacer. No pueden, no lo conciben. Tienen, por ejemplo, hay abogados que me hablan y dicen licenciada, tengo un recurso de revisión del 2003. ¿Cómo lo meto? De entrada, ya si me hacen esa pregunta va a botar en los reportes. En los reportes va a botar que se presentó en el 2003 y se está atendiendo en 2007. Cuando el tiempo calendario era de tres meses. [...]Es hacer el gap entre lo que haces y el to be. El problema es que aquí debería haber un poco de humildad por parte del Jurídico y decir no todo lo hacemos bien. Realmente, por primera vez, integrar a las delegaciones para ver hasta dónde pueden llegar y no. Es un absurdo querer estandarizar a todas las delegaciones a un mismo nivel. No todos están a un mismo nivel. No todas jalan igual. Por eso es decirles vas a tener un funcionamiento a un 100 y otras los vas a tener a un treinta. Y no, no puedes hacer nada por eso. Tú como Jurídico desafortunadamente no puedes hacer nada por eso, y el que lo puede hacer no lo involucras, entonces no hay nada qué hacer. Rodrigo Romo 47:43
Déjame regresarme. ¿Qué tal estuvo la integración con Albalá?
141
Hilda García 47:47
Voy a empezar por el final. Somos la única unidad administrativa hasta donde tengo conocimiento, que utiliza Albalá. Rodrigo Romo 48:13
No es cierto. La segunda. La primera soy yo. Era broma. Hilda García 48:15
Por alguna razón que yo todavía no entiendo Jurídico siempre se quiso deslindar de la responsabilidad de Albalá. ¿Por qué? No lo sé. A diferencia del CRM y del BI. Rodrigo Romo 48:43
Yo tengo un por qué muy claro. Hilda García 48:44
Me convierto en la entrevistadora. ¿Por qué? Rodrigo Romo 48:51
Porque lleva nombre. Es el problema. El tiradero específico de [referencia personal] Lo que no quedaba a la vista por el lado del proceso de jurídico, sí por el lado de archivos. Hilda García 49:29
De hecho, nosotros no teníamos documentación de Albalá. Porque nunca Jurídico se quiso meter a Albalá. No hay ni un líder de proyecto de Albalá. Si ves las carpetas de Jurídico no hay una sola documentación de Albalá. Nada sobre Albalá. Y sin embargo, aún con esa dicotomía, entre Albalá y Jurídico, somos quienes lo utilizan. La verdad es que la integración entre Jurídico y Albalá fue colgarse de Servicios, si Servicios dice que está bien, está bien, fue colgarse si la Coordinación de Asesores dice que está bien, está bien. Aunque Jurídico le hubiera visto alguna opinión, se la reservó. Si ellos la aceptan, bien. Yo no digo nada. Entonces la integración fue de cero. Rodrigo Romo 50:58
Al final del día, la integración del SIIP con Albalá se hizo una sola vez, con Servicios. Por eso no tenía nada que ver con Jurídico. Lo que estuvo en discusión fue lo de la cuestión de oficialía de partes. En un no-flujo de información. Hilda García 51:21
El único problema, ahora que estamos utilizando el Albalá, el problema vino del área de informática. La gente a la que le asignaron el Albalá creo que no era el perfil para el Albalá.
142
Ahorita que estamos utilizando el SIIP y Albalá, quisimos correr nuestro reporte para lo que es el reporte de transparencia. No lo pudieron hacer. La persona que estaba no supo de dónde sacarlo, no tenía ni idea. Quisimos hacer préstamos de archivos, lo único que queríamos era que no dijera Baratz. Que dijera PROFECO y Dirección General de lo Contencioso y de Recursos. Tampoco. Rodrigo Romo 53:01
Pero el problema de fondo allí es cómo estamos para usar Albalá. La parte informática está resuelta, salvo el detalle de la elaboración de informes, que eso se ajusta contra las necesidades del área. Eso no es problema. [referencias personales] [...] No están en condiciones de uso.