“¿Por qué fracasan los proyectos de Tecnologías de Información (TI) en el Estado Peruano?”, es la pregunta que nos hizo uno de nuestros lectores hace algunas semanas, ello, creemos por el fracaso del proyecto del MEF y que lo difundimos in extenso.
Confesamos que no fue fácil la tarea, varios profesionales nos recomendaron al Ing. Oscar Camacho Carrillo, actualmente director de la firma Consulting & Management S.A.C. Este profesional ha dirigido proyectos de TI en el Perú y todos los países de Centroamérica… a continuación textuales de nuestro entrevistado de turno.
¿POR QUÉ FRACASAN LOS PROYECTOS DE TI EN EL ESTADO PERUANO?
(americasistemas.com.pe. Lima, Perú – 07 de Octubre de 2015) “¿Por qué fracasan los proyectos de Tecnologías de Información (TI) en el Estado Peruano?”, es la pregunta que nos hizo uno de nuestros suscriptores.
Animados por esta interrogante, fuimos en búsqueda de una voz experta, el director de Consulting & Management S.A.C. Ing. Oscar Camacho Carrillo quién ha dirigido proyectos de TI en el Perú y todos los países de Centroamérica, y accedió a ser nuestro entrevistado de turno.
Para el especialista, “el proceso de cada proyecto incluye la gestión, el ciclo de vida, la metodología, los estándares, la ingeniería, la arquitectura, el componente técnico – administrativo, entre otros. Por lo tanto, el proceso falla cuando la ingeniería está mal diseñada o la gestión es pobre”, señaló. En su opinión, las cuatro (4) razones principales por las cuales los proyectos de TI fracasan en el Estado son la mala definición del alcance del Proyecto; la no aplicación de metodologías tanto de desarrollo de software como de gestión de proyectos; la selección de tecnologías en proceso de maduración; y la inadecuada selección de los profesionales.
Con respecto al alcance, que en términos sencillos consiste en definir claramente lo que incluye y lo que no se incluye en el Proyecto, es frecuente ver en las bases o términos de referencia expresiones ambiguas, de “alto nivel” y la ausencia de aquello que no se incluye, lo que más tarde generará solicitudes de aclaración, controversias, adendas y arbitrajes, lo que desgastará a contratantes y contratados, elevará los costos, dilatará las entregas y conducirá al fracaso del Proyecto.
En relación a las metodologías, es común constatar la ausencia de disciplinas como la ingeniería de software, notándose la carencia de métodos y herramientas probados para “entender el problema” y desarrollar el software, así como la escasa planificación de las fases y etapas, lo que suele multiplicar los riesgos del Proyecto, más aún cuando se trata de emprendimientos de mediana o alta complejidad.
Además, no son pocos los casos en que la metodología termina siendo empleada como una máscara formal para cumplir con ciertas normas y requisitos, y no como lo que verdaderamente es, el eje del proyecto.
En cuánto a la condición de madurez de las tecnologías, hemos visto en el Perú varios intentos recientes de adopción de tecnologías, sin que se haya medido antes el impacto que esta incorporación tendría en la estrategia, procesos, sistemas, finanzas y cultura de la organización. Casos emblemáticos son la adquisición del BPM del PRODUCE, el BPM de EsSalud y el BPM/SOA del MEF (recientemente comentado en América Sistemas), donde la dificultad mayor no fue la tecnología misma, sino el escaso grado de conocimiento que tenían de ella los contratantes y los representantes locales de los productos adquiridos.
Sobre este aspecto, Camacho aseguró que éste se constituye en un factor crítico de fracaso cuando se intenta abarcar muchas áreas o procesos organizacionales a la vez, sin antes haber experimentado con un área o un proceso representativo, a modo de piloto, lo que permitirá reflexionar sobre la viabilidad de la tecnología y los desafíos que se habrán de enfrentar respecto a la integración con los sistemas existentes, la performance del sistema, la capacitación de los usuarios, la sostenibilidad del sistema, entre otros aspectos clave.
Finalmente, respecto a la selección de los profesionales, el especialista sostiene que “es un hecho conocido que hoy en día cuesta mucho encontrar profesionales de alto nivel para incorporarlos a proyectos de mediana o alta complejidad, lo que se debe a varios factores entre los que destaca el formativo”. Uno de los efectos de la escasez es el incremento sustancial de los salarios promedio de, por ejemplo, los expertos en Java con buen conocimiento de determinados Frameworks y manejadores de base de datos. La situación descrita conduce, en ocasiones, a trabajar con el experto que se pueda contratar y no necesariamente con el que uno quisiera contar, lo que también multiplicará los riesgos del proyecto.
7 Comentarios
Daniel Valencia
Interesante pregunta de Fácil Respuesta.- Porque el estado no es un ente especializado en atender desafíos de TI (así como de muchas otras áreas)… desde cualquier perspectiva…
La razón es básica; el estado no está modulado para hacerse cargo de nada… así como esta “funcionando”, es absolutamente disfuncional a cualquier encargo y básicamente por cuanto sus motivaciones son políticas y convenencieras no son sanas… el estado está desenfocado, ya no orienta su atención en La Persona/Ciudadano como el cliente final, Objeto – Sujeto del desarrollo, en algún momento se rompió el enfoque.
• Los gobiernos de turno, pusieron al estado a su servicio y no al servicio de los ciudadanos.
• Los Gobiernos de Turno no representan ni al 20% de los ciudadanos.
• Los Representantes se creen autoridades y los servidores públicos se creen funcionarios públicos
Muchos servidores públicos se consideraron autoridades y los trabajadores estatales, antes que atender sus legítimos objetivos y metas (para lo que cada institución fue creada), empezaron a obedecer al gobernante de turno y eso ocurrió:
Cuando los jefes que se designan en el estado son allegados de confianza de los gobernantes, antes que los profesionales que a mérito propio les corresponden los cargos de liderazgo.
Las instituciones como el BID, BM, OMS, etc., todos organismos privados, disfrazados de organizaciones para el desarrollo sin fines de lucro, montaron una fórmula por la cual nos hacen hacer lo “conveniente” a sus intereses económico financieros y no, lo que realmente requerimos o nos importa a los ciudadanos. Razón por la que hasta las entidades supervisoras se hacen de la vista gorda ante tanto improperio.
Igual podrían ganar su dinero más honestamente, pero detrás de esas fastuosas organizaciones, hay grandes capitales protegiendo sus intereses y nos invitan a orientar e implementar sus metodologías o modelos, como si nosotros no tuviéramos profesionales suficientemente capaces de desarrollar o enfrentar nuestros desafíos.
Como verán, al menos desde mi perspectiva, no es un problema técnico, es un problema político y los Técnicos a cargo, no detienen estas aberraciones, porque están procurando o protegiendo “su chambita”…. “Yo sólo estoy poniendo el cascabel al gato”, porque todos los TI que están leyendo esto, saben que es cierto… así que, en conclusión, la respuesta del millón es: LOS PROYECTOS DE TI DEL ESTADO FRACASAN POR INCAPACIDAD POLÍTICA, NO POR INCAPACIDAD TÉCNICA…
Adicionalmente, cada nuevo gobierno o jefe designado “reinventa su versión de la rueda”, cuando tiene capacidad de aportar algo.
Luis Palacios
En mi experiencia de haber trabajado en empresas estatales y privadas, en empresas privadas se trabaja a resultados y si fallas en un proyecto es un indicador para tu no continuidad en la empresa es por eso que no puedes darte ese lujo de fracasar en los proyectos, ya que existe una evaluación de desempeño por parte de la Gerencia de Gestión Humana, sin embargo en el estado peruano una variable muy critica es la política, cada vez que existen cambios en la política, cambian a los funcionarios F8 (Ministros) o F7 (Viceministros) o un director (F6) y traen a su personal de confianza sin cumplir con las habilidades blandas o duras, este es un gran problema en el estado peruano, que no ocurre en las empresas privadas.
Actualmente tenemos las guía de proyectos PMBOK, y revisemos el reporte de CHAOS donde nos señala que a nivel mundial en los últimos 10 años el porcentaje de los proyectos exitosos es del 29% y el resto son fracasos.
Asimismo pregunto a los encargados de proyectos de TI, cuando inician un proyecto, se toman el debido tiempo de evaluar y formular proyectos de TI.
1. Formulación del proyecto (análisis del entorno-FODA, Análisis de funcionalidades, Diagrama causa-efecto, análisis de riesgos, análisis de inversión, análisis de recurso materiales y humanos, análisis de oferta y demanda de software, experiencia de otros sistemas semejantes impementados, entre otros),
2. Evaluación del proyecto (evaluación técnica y funcional, evaluación económica, evaluación legal, evaluación de los recursos, entre otros).
En base a estos resultados recién se deberá realizar la implementación del proyecto, porque en este momento puedes identificar si tu proyecto es factible o no. Si tu proyecto es factible te embarcas en el proyecto y como abordarlo si es muy grande puedes realizar un roadmap, esto lo obtienes de la evaluación funcional.
La gestión del proyecto es una cosa secundaria, porque si se formula y evalúa un proyecto adecuadamente, las posibilidades de éxito son mayores.
Como analogía, si se construye un buen auto (seguridad, comodidad, facilidad, etc.) es mas fácil buscar un buen chofer, pero si no se construyo un buen auto, así busque al mejor chofer no puedo tener la seguridad ya que los frenos pueden fallar debido a que el auto no fue bien construido. Por eso considero una cosa secundaria el control de proyecto, existen muy buenos profesionales en esta materia de control y seguimiento de proyectos.
Por ultimo y como una analogía, No hay que saltarse fases y realizar de frente la implementación del proyecto, porque no puedes identificar y dimensionar la probabilidad de éxito o fracaso del proyecto.
El proyecto es como el nacimiento de un hijo, debe hacerse seguimiento desde el vientre de la madre y no esperemos su nacimiento para conocer si va hacer uno, mellizos o quintillizo, o si sale sano o puede tener enfermedades.
Por ultimo, prefiero invertir 10 o 15 días mas en la formulación y evaluación de proyectos de TI (es necesario tener experiencia), que dedicarle años solucionando los problemas cuando el sistema esta en producción, donde el costo es muy elevado y en el peor de los casos el proyecto es cancelado.
Raúl Zavaleta Vértiz
Estoy de acuerdo en lo que menciona el Ing. Camacho como deficiencias constantes en los proyectos de TI que fracasan en el Estado Peruano. Como aporte menciono lo siguiente :
Sería muy interesante hacer ejercicio similar e identificar las características comunes de los proyectos que no fracasan en el Estado Peruano. Y más interesante aún, identificar las características de los proyectos que sí son exitosos. Lo más probable es que simplemente cumplan con lo exigido en las bases, que por lo general son pobres en varios aspectos. Considero que la forma de medir el éxito de los proyectos de TI en el Estado Peruano, y en general, es medir su impacto en la mejora del desempeño que se obtiene en el área y/o la organización intervenida.
Sería, igualmente muy interesante un ejercicio adicional para identificar las causas de la situación que el Ing. Camacho describe con acertada precisión. Me atrevo a mencionar algunos indicios de causas:
No hay recurso humano especializado local en tecnologías emergentes porque hay muy poca demanda por ellas, justamente porque el recurso humano “especializado” que debería demandarlas tampoco tiene las competencias necesarias. Y recalco lo de competencias, pues información desde internet es solo eso. Cómo romper el círculo vicioso, pues con inteligencia, inversión, plan estratégico..de quién.. ¿de la demanda?. No!! de la oferta.
El deficiente alcance de los proyectos se origina por la forma en que las organizaciones del estado están diseñadas… áreas funcionales con responsabilidades verticales, ignorando la importancia de los procesos transversales a lo largo de a veces casi toda la organización. Es raro que alguien sea el responsable de que el resultado final sea de calidad, Cada quién se ocupa del entregable de su área. y si por alguna razón, el proyecto es de tal importancia que se cuida este aspecto,…toma varios años concretarlo, con el agravante que la tecnología escogida… puede haber cambiado su curva de desempeño.
Las metodologías no se usan, porque los profesionales buscan que certificarse en ellas para mejorar su empleabilidad. Los empleadores no tienen un plan de desarrollo de recurso humano especializado en TIC´s que corresponda a las necesidades estratégicas institucionales. No hacen ningún ejercicio de lo que actualmente se denomina Arquitectura Empresarial. No hay planificación que relacione las capacidades nuevas del recurso humano con las necesidades de los proyectos a emprender en la institución. Se usa el presupuesto de la entidad para mejorar la empleabilidad del profesional.
Propuestas ??… en otro memento.
Humberto Arteaga
El tema de FRACASO de proyectos, no solo se presenta en el sector publico (estado) sino también en el sector privado.
Complementando a lo manifestado por el entrevistado, sobre el tema de “los alcances” y el “perfil profesional”, siempre constituirán factores de fracaso en los proyectos, al menos aquí en el Perú.
Los alcances, por cuanto se requiere de un cierto dominio del manejo de Sistema de Información y su delimitación no es sencillo, el tema se agrava si la entidad no cuenta con los profesionales adecuados. Es muy importante que se entienda que en este punto, el usuario solo indica lo que necesita y es el especialista quien lo debe interpretar y traducir en alcance.
Sobre el perfil de los profesionales, las consultores por lo general buscan la mano de obra barata y estas no siempre son calificadas en cuanto a la experiencia.
En mi opinión, existe otro elemento fundamental en el FRACASO de los proyectos:
Consiste en el error que cometen las organizaciones (públicas o privada) al creer que la solución de sus problemas se acabará al implementar un proyecto informático (desarrollo de software) sin antes haber ordenado la problemática de su Sistema de Información.
Las organizaciones primero deben decidir por implementar un proyecto de mejoramiento de proceso, para ordenar e identificar la integración de su sistema de información (flujo, documento, etc), luego de esto, recién optar por un proyecto para sistematizar sus procesos integrados (aplicativo).
Esta secuencia de pasos, efectivamente genera costos a la organización (dos proyectos), pero será compensado al disminuir los indices de fracaso.
elias ruiz
Hola
Algunos comentarios:
1) Uno de los problemas es el factor humano
El articulo elabora muy bien uno de los factores de este problema, quizá el más importante: el factor humano. Es verdad que es difícil conseguir buenos analistas, arquitectos, programadores, etc. y que uno debe contentarse con lo que encuentra, esto es muy lamentable en realidad.
2) un jalon de orejas
Nosotros, profesionales, debemos tomar cartas en el asunto. Es conocido que muchos de nosotros ENSEÑAMOS en las universidades, asi que hay que hacerlo bien y no solo para “aprobar” a los alumnos.
Pero nosotros también enseñamos en otro ambiente que no pensamos: el centro de trabajo. Debemos enseñar bien a los PRACTICANTES, y también CORREGIR a los colegas cuando no lo hacen bien.
Un jalón de orejas aquí a los profesionales que no hacen bien su labor educativa.
3) el otro problema “oculto”
Es evidente que en la ingeniería de sistemas NO EXISTE UN MARCO TEORICO UNIFORME, existen BUENAS PRACTICAS, como las indicadas por el Gang Of Four, los Four Guys From Rolla, algún libro por allí de RUP, pero hay CIENTOS libros de las nuevas metodologías Agile, XP, Scrum, e infinidad más.
Claro, en este contexto, es muy difícil decirle a alguien si esta bien o esta mal. En ingeniería eléctrica existe la ley de ohm, que relaciona la corriente, la resistencia y el voltaje; en la física existen las leyes del electromagnetismo, una de las cuales dice que por donde pasa una corriente se genera un campo electrico y viceversa; no considerarlas en una instalación eléctrica en una casa o edificio, o en una instalación de cableado estructurado, es una invitacion al fracaso…..pero EXISTE UN MARCO TEORICO DEFINIDO.
Es interesante leer el trabajo practico de Allen Holub (Holub on Patterns) y como se complementa con el trabajo teorico de Gamma, Helm, Johnson y Vlissides (Design Patterns: elements of Reusable Object-Oriented Software), siendo muy incisivo en cómo el marco teorico se complementa con el aspecto práctico, o discutiendo las diferencias entre arquitectos, diseñadores y programadores y porque deben ser personas diferentes…
En la ingeniería de sistemas no existe un ORGANISMO INTERNACIONAL que DETERMINE LAS LEYES DE LA INGENIERIA DE SISTEMAS. incluso, en las universidades y algunos libros o artículos de internet se dice que LA INGENIERIA DE SISTEMAS ES UN ARTE….pero si es un arte, lo que a mi me parece bonito no necesariamente es bonito para otro…como nos pondremos de acuerdo?
…y este es el motivo oculto de este problema con la ingeniería. SE NECESITA FORMULAR LEYES, o en su defecto RECOMENDACIONES, de uso OBLIGATORIO para todos los profesionales de este rubro.
Este medio puede ser super útil para difundir temas de ingeniería y puede ser una suerte de guía para que se promulguen NORMAS TECNICAS PERUANAS DE SOFTWARE.
Conclusion
Para concluir, no sólo el factor humano es responsable de estos fracasos en implementaciones de software, sino que la ingeniería de sistemas no formula LEYES de carácter cientifico, propios de una ingeniería.
Un Abrazo,
Elias Ruiz
Daniel Valencia
Discrepemos sanamente;
A la 1.- Si estas dispuesto a pagar maní o plátanos, los mas probable es que consigas monos… profesionales hay, el problema son los bajos salarios y los buenos salarios, son para “los amigos designados”, que están allí por amigos, no necesariamente ni siempre por buenos profesionales….
A la 2.- Si no hacen bien su trabajo, es sólo cuestión de Ética”, la mediocridad es una interesante competencia en nuestra época, de hecho es adoctrinamiento… si tienes tiempo, en este articulo compartí mi opinión al respecto
https://www.americasistemas.com.pe/basura-entra-basura-sale/
A la 3.- En nuestra época, NO HAY MARCO TEORICO PARA EL DESARROLLO de SOFWARE, existen múltiples metodologías, pero estamos en la era de lo disruptivo, reingeniería de lo cotidiano, hay muchos caminos para llegar a Roma, y mientras mas descubramos, será mejor, en estos temas el mejor Marco Teórico es “open maind”, prospectivo, visionario dime donde estudiaste y te dire que tan preparado estás… eso no significa que el limite que tienes hoy sea tu real límite….era de los desafíos en donde hasta la Ley de OHM es cuestionable por las teorías cuánticas, de hecho la física pura, ya ni lo toma en cuenta…el diseño de patrones con elementos o clases reusables de software orientado a objetos, calificado personalmente como antiguo paradigma severamente observado por elementos orientados a procesos y desde mi perspectiva también observables, pues en 2011 plantee un nuevo paradigma, elementos orientados a la persona… https://www.americasistemas.com.pe/la-urgencia-de-la-identidad-digital/
Saludos Cordiales…
Domingo Ferrari
Cito: Finalmente, respecto a la selección de los profesionales, el especialista sostiene que “es un hecho conocido que hoy en día cuesta mucho encontrar profesionales de alto nivel para incorporarlos a proyectos de mediana o alta complejidad, lo que se debe a varios factores entre los que destaca el formativo”
Podría definir a que se refiere con profesionales de alto nivel por ser ambiguo según sus propias palabras.
Gracias.