Instrucciones Formulación de Proyectos EVALTIC 2022-1

INSTRUCCIONES
PARA LA
FORMULACIÓN DE
PROYECTOS TIC
EVALTIC 2022
Eficiencia, calidad y alineamiento estratégico de los proyectos TIC
[] mayo 2021
Versión 01
ÍNDICE
ÍNDICE 1
1. CONTEXTO GENERAL 2
1.1. INTRODUCCIÓN 2
1.2. CONTEXTO 2
2. OBJETIVOS DEL PROCESO EVALTIC 4
3. ACTORES DEL PROCESO 5
4. ETAPAS DEL PROCESO 7
4.1. DIFUSIÓN Y CAPACITACIÓN 7
4.2. FORMULACIÓN DE PROYECTOS 7
4.3. EVALUACIÓN E ITERACIÓN 8
4.4. CIERRE 9
4.5. ANÁLISIS Y SEGUIMIENTO 9
5. ¿CÓMO FORMULAR CORRECTAMENTE? 10
5.1. INSTRUCCIONES GENERALES 10
5.2. INSTRUCCIONES TI ESPECÍFICAS 13
5.3. CAUSALES DE EVALUACIÓN NEGATIVA 18
5.4. COMPLETAR FORMULARIO DE IDENTIFICACIÓN DE PROYECTOS TI 19
5.5. INGRESAR AL APLICATIVO DE DIPRES 21
6. CONTACTO E INFORMACIÓN 22
7. ANEXOS 23
ANEXO N°1: PROCESO DE DESARROLLO DE SOFTWARE 23
ANEXO N°2: INTERFAZ DIPRES-EVALTIC 27
ANEXO N°3: FORMULARIOS OFICIALES «FORMATO PROYECTOS TI» 31
1
1. CONTEXTO GENERAL
1.1. INTRODUCCIÓN
Una vez más dentro del marco presupuestario anual, la Dirección de Presupuestos
(DIPRES) y la División de Gobierno Digital (DGD) del Ministerio Secretaría General de la
Presidencia, han definido el proceso de formulación de proyectos de Tecnologías de la
Información y la Comunicación (TIC). Este proceso está dirigido a las Instituciones con el
fin de promover la transparencia, el buen uso de los recursos asignados por el Estado a
Tecnología, fomentar proyectos que sean un aporte tanto para la gestión interna de las
instituciones como para la entrega de un mejor servicio a la ciudadanía, e impulsar el uso
de tecnologías emergentes.
Las presentes instrucciones están dirigidas a todos los organismos públicos y

principalmente a aquellos funcionarios responsables de la «Formulación de Proyectos» -
que debe involucrar un trabajo conjunto de las áreas de finanzas y tecnología -, con el fin
de comunicar en detalle la metodología y uso de la plataforma que apoya este proceso.
1.2. CONTEXTO
Durante los últimos 4 años se ha generado un proceso dedicado y complementario a la

formulación presupuestaria, mediante una metodología ad hoc de formulación y revisión
de proyectos tecnológicos del Estado cuyo resultado, de apruebo o rechazo, es una
recomendación técnica vinculante a la asignación de recursos por parte de DIPRES para
la ejecución presupuestaria 2022.
El proceso ha tenido mejoras incrementales año a año, destacando:
● Diseño e implementación de una plataforma para acompañar el proceso de

EVALTIC, donde cada institución debe ingresar su formulación, la cual es revisada,
generando observaciones y recomendaciones de cada iniciativa.
2
● Avance en la instalación de una cultura de formulación en el marco de este proceso
en las instituciones públicas, logrando un mayor compromiso de las instituciones
participantes e incrementando el número de participantes:
○ Proceso 2018: 64 Instituciones con 322 proyectos presentados.

○ Proceso 2019: 96 Instituciones con 663 proyectos presentados.
○ Proceso 2020: 157 Instituciones con 1.423 proyectos presentados.
○ Proceso 2021; 150 Instituciones con 1.547 proyectos presentados.
● Ha fortalecido un proceso participativo de evaluación entre las instituciones del

Estado, ya que existe un primer proceso de revisión cruzada, donde cada
institución designa evaluadores para la revisión de proyectos de otros servicios
públicos no relacionados, dedicando horas de su jornada a dicho proceso. Con
esto se ha logrado cumplir con los objetivos de cobertura del proceso,
considerando iteraciones de revisión posteriores para obtener la evaluación final.
A continuación, se puede ver cómo ha variado el número de participantes en los
distintos procesos:
○ Proceso 2018: Sin información disponible.

○ Proceso 2019: 26 Evaluadores desde mayo a junio.
○ Proceso 2020: 75 Evaluadores desde mayo a junio.
○ Proceso 2021: 85 Evaluadores desde mayo hasta julio.
La experiencia de años anteriores ha consolidado la importancia de este proceso, dando

señales claras a los organismos públicos sobre su relevancia e impacto concreto en las
decisiones de gasto. Para la formulación presupuestaria 2022, el número de participantes
deberá lograr una cobertura del proceso del 100% de las iniciativas tecnológicas del
Estado. Adicionalmente, ChileCompra sigue participando durante el proceso en el marco
del seguimiento de los proyectos, al incorporar como exigencia en el proceso de compra
por parte de las instituciones, ya sea al momento de presentar sus órdenes de compra o
3
licitaciones, el ingreso y validación del código del proyecto en el marco del proceso de
Formulación de EVALTIC.
Con todo lo anterior, el proceso EVALTIC se ha posicionado como la instancia por

excelencia para la formulación de proyectos tecnológicos con cobertura del 100% de las
instituciones, fortaleciendo el seguimiento y control en la etapa de ejecución de los
proyectos tecnológicos, incrementando la eficiencia y alineamiento estratégico del gasto
en materia de transformación digital, además de proveer datos para la toma de decisiones
basadas en la evidencia.
2. OBJETIVOS DEL PROCESO EVALTIC

 Optimizar el gasto en tecnologías del Estado, a fin de incrementar la eficiencia del gasto
implementando acciones que permitan aprovechar las economías de escala y de red
asociadas al uso de tecnologías digitales.
 Alinear estratégicamente el gasto público en proyectos tecnológicos del Estado con los
objetivos, lineamientos y estándares establecidos en la ley de transformación digital del
Estado1 y las iniciativas impulsadas en dicho marco legal.
 Incrementar la calidad de los proyectos de tecnología mediante un proceso de
formulación de proyectos estandarizado cuyo foco es la generación de valor público y la
optimización del uso de los recursos asignados.
 Generar información para la toma de decisiones en materia de transformación digital en
base a evidencia.
 Incrementar los mecanismos de control de la correcta ejecución de los proyectos por parte
de las instituciones, así como la correcta ejecución de los recursos facilitando la detección
y reporte oportuno de posibles desviaciones en el uso de los recursos asignados a los
proyectos.
1
https://digital.gob.cl/transformacion-digital/ley-de-transformacion-digital/
4
3. ACTORES DEL PROCESO
Las responsabilidades en este proceso son complementarias ordenándose de la siguiente
manera: DIPRES, es la responsable de determinar las etapas y plazos de la formulación
presupuestaria; DGD colabora en la coordinación del proceso, en el establecimiento de
criterios técnicos y vela por la alineación con los aspectos legales y normativos que se
aplicarán en las evaluaciones; ChileCompra aporta información necesaria para la
realización del seguimiento a los proyectos; y finalmente los organismos públicos que
designan evaluadores cuya contribución es clave para el éxito del proceso.
En este proceso se pueden distinguir 3 perfiles distintos: Formuladores, Evaluadores y

Supervisores:
● Formuladores, son los encargados de definir los proyectos TIC de sus instituciones y
subirlos a la plataforma EVALTIC. Dependiendo del resultado de la evaluación de cada
proyecto, deberán complementar, ingresar información adicional o reformular proyectos,
en instancias excepcionales de iteración o reconsideración. Finalmente, son los
encargados de coordinar con su respectivo Sectorialista presupuestario la disponibilidad
de los recursos para la ejecución de los distintos proyectos. Para la formulación de
proyectos debe existir una buena comunicación y coordinación estrecha entre las áreas
de finanzas y las áreas de tecnología de la institución. El área de finanzas es la responsable
de la elaboración y presentación del presupuesto a DIPRES, mientras que las áreas de
tecnología son las responsables de la definición y ejecución de los proyectos TIC. Es crítico
que se establezcan instancias formales de coordinación entre las áreas de Finanzas,
responsables del área de TI y el Coordinador de Transformación Digital de la Institución,
para así integrar los lineamientos estratégicos institucionales, las directrices de Gobierno
Digital y disponibilidad presupuestaria.
Si bien, formalmente son las áreas de Administración y Finanzas quienes presentan la

formulación presupuestaria de la institución, para el proceso EVALTIC se requiere contar
5
con la participación activa del Coordinador de Transformación Digital. El Coordinador de
Transformación Digital es quien juega un rol estratégico apoyando a las áreas de
administración y finanzas, incorporando en la formulación de sus proyectos tecnológicos,
los lineamientos y estándares que emanan de la Ley N°21.180 sobre Transformación
Digital del Estado y de la División de Gobierno Digital (DGD) del Ministerio Secretaría
General de la Presidencia en la materia.
● Evaluadores, son el Jefe junto con profesionales del área TI de los distintos organismos
públicos. Son los responsables de revisar y evaluar proyectos de otras instituciones que
les son asignados. En base a la experiencia de cada uno de ellos, junto con los criterios
definidos en la instrucciones, emiten una recomendación de “sin objeción técnica”, “sin
objeción técnica con observaciones” o de rechazo. Los evaluadores desempeñan una
función crítica y de alta responsabilidad, por cuanto su recomendación técnica será
vinculante a la asignación de recursos por parte de DIPRES, para la ejecución
presupuestaria 2022.
A partir del proceso de formulación presupuestaria 2022, cada institución deberá designar
a lo menos tres profesionales del área TIC para ser evaluadores, que corresponderán al
Jefe TI y a dos profesionales que le reporten directamente a éste.
● Supervisores, corresponden a funcionarios de la DIPRES y la DGD, encargados de velar

por la coordinación, plazos y correcta operación del proceso y plataforma, apoyando en
la resolución de problemas y dudas que puedan tener los Formuladores y Evaluadores.
También son los encargados de mantener la configuración de la plataforma y del proceso
de seguimiento posterior.
6
4. ETAPAS DEL PROCESO
El proceso de Formulación de Proyectos TI para el Presupuesto (PPTO) del año 2022,
consta de las siguientes etapas:
4.1. DIFUSIÓN Y CAPACITACIÓN
Esta etapa comprende la socialización del proceso y las capacitaciones. En la divulgación

se pretende entregar la información relevante del proceso que comprende las fechas
relevantes y lo que se espera de cada institución referente a la Evaluación de Proyectos TI
(EVALTIC). En esta etapa se realizan dos tipos de capacitaciones:
i) Dirigidas a los Formuladores, responsables de ingresar las fichas de proyectos a la

plataforma EVALTIC provista por DIPRES y
ii) Dirigidas a Evaluadores, encargados de revisar y calificar cada ficha de proyecto y
generar una recomendación basada en los criterios que se detallan más adelante
en esta guía.
La Difusión y Capacitación se llevará a cabo en el siguiente período:
07-05 / 28-05 - Oficio del Director de Presupuestos donde se indica el inicio del proceso
de formulación presupuestaria, y solicitud de designación de Evaluadores de proyectos.
4.2. FORMULACIÓN DE PROYECTOS
La formulación de proyectos es la base del proceso de EVALTIC, ya que es en ésta donde

la institución debe identificar y describir correctamente cada proyecto TI que está
planificando realizar para el año presupuestario correspondiente, en él se deben incluir
los proyectos nuevos, los de continuidad operacional y los de arrastre, es decir los
7
proyectos que ya fueron aprobados en años anteriores, que ya están en marcha y
requieren de presupuesto para continuar.
Dado los plazos acotados del proceso de formulación/evaluación, es muy importante que
las instituciones hagan el esfuerzo por presentar lo antes posible sus iniciativas en la
plataforma de EVALTIC, ya que mientras antes se presente una iniciativa para su
evaluación, permitirá recibir las retroalimentaciones de parte de los Evaluadores con el
tiempo suficiente para que puedan ser corregidas o mejoradas las formulaciones,
evitando así que los Evaluadores tengan que evaluar todo en un corto periodo con las
consecuentes demoras en la entrega de las retroalimentaciones y posteriormente no tener
plazo para realizar las correcciones sugeridas a los problemas detectados en caso de
rechazo. Esto apunta a hacer el proceso más fluido y contar con el tiempo suficiente para
entregar proyectos de mejor calidad y evitar los rechazos de los proyectos.
La Formulación de Proyectos se llevará a cabo en el siguiente período:
10-05 / 30-06 – (Preliminar) Comenzará en cuanto la plataforma quede disponible y

configurada, además de entregadas las credenciales a los Formuladores.
4.3. EVALUACIÓN E ITERACIÓN
El proceso de evaluación corresponde a la etapa en la cual los distintos Evaluadores,

asignados a los proyectos presentados en la plataforma, proceden a analizar y generar
recomendaciones, basados en los criterios técnicos, de Instrucciones Generales e
Instrucciones TI Específicas, detallados en los puntos 5.1 y 5.2 respectivamente, de la
presente guía.
Durante el periodo en que las instituciones formulan sus proyectos, los Evaluadores
comienzan la revisión de los proyectos que van ingresando en forma progresiva, y en los
casos en que un proyecto revisado tenga observaciones o esté derechamente rechazado,
pero dentro del plazo de evaluación, la institución formuladora puede realizar las
8
correcciones y/o ajustes a un proyecto y volver a presentarlo. A esta instancia se le
denomina «iteración», donde el Formulador ajusta o corrige errores con el objeto de
presentar nuevamente la iniciativa para que ésta sea reevaluada.
La Evaluación e Iteración se llevará a cabo en el siguiente período:
24-05 / 07-07 - (Preliminar) Comenzará en cuanto se hayan subido las primeras

solicitudes y hayan sido asignadas a los Evaluadores.
4.4. CIERRE
El proceso de cierre corresponde a una etapa formal en que Formuladores y Evaluadores

ya no pueden seguir trabajando sobre los proyectos. En esta instancia, sólo los
supervisores del proceso trabajan en la emisión de las recomendaciones e informe con
los resultados de la evaluación, el cual es entregado al Director de la DIPRES y a los
sectorialistas de DIPRES, quienes finalmente asignan los recursos a las instituciones.
El Cierre se llevará a cabo en el siguiente período:
30-06 / 09-07 - (Preliminar) El cierre se realiza en 2 etapas, primero se cierra el proceso

de Formulación, donde sólo se seguirá evaluando aquellas solicitudes que están
pendientes y casos especiales, posteriormente se cierra el proceso.
4.5. ANÁLISIS Y SEGUIMIENTO
El proceso de análisis y seguimiento corresponde al período en el cual se realiza el análisis

de los proyectos presentados, y se seleccionan aquellos para los cuales se deberá
conformar un directorio de seguimiento integrado por Gobierno Digital y Hacienda. Este
período se extiende entre el fin del actual proceso presupuestario y el inicio del nuevo
proceso.
9
El Análisis y Seguimiento se llevará a cabo en el siguiente período:
09-2021 / 03-2022 - Se procederá a hacer un análisis de la data contenida en la base

de datos para obtener la información relevante del proceso y retomar el seguimiento a
los proyectos destacados de las diversas instituciones.
5. ¿CÓMO FORMULAR CORRECTAMENTE?

5.1. INSTRUCCIONES GENERALES
Se deberán presentar absolutamente todas las licencias de software, proyectos en curso

y nuevas iniciativas relacionadas a Tecnologías de Información y Comunicaciones (TIC), en
las que participe o tenga algún grado de responsabilidad el Departamento TIC o el
Coordinador de Transformación Digital de la Institución, e independiente de la fuente de
financiamiento, subtítulo y programa al que se imputará el gasto. Los proyectos de
continuidad incluyen todas las licencias de software vigentes, servicios de mantención o
cualquier tipo de contrato de bienes y servicios TIC a los que la Institución necesita dar
continuidad el próximo año.
Existe un conjunto de principios generales de formulación que deben ser considerados

por las instituciones, debiendo adherir a ellos entendiendo que no todos son aplicables
a ciertos proyectos. Se evaluará positivamente aquellos proyectos que cumplan con los
siguientes principios:
5.1.a. Coordinación interna: la institución deberá definir el equipo

responsable de la correcta formulación y oportuna presentación de los
proyectos TI en la plataforma EVALTIC, que al menos deberá ser integrado
por el Jefe de Administración y Finanzas, el Jefe TIC y el Coordinador de
Transformación Digital de la Institución. Lo anterior, con el objetivo de
10
integrar los lineamientos estratégicos institucionales, las directrices de
Gobierno Digital y los criterios presupuestarios entregados por DIPRES.
5.1.b. Equipos de trabajo: Conformados por un equipo de profesionales

de áreas con responsabilidad institucional, con competencias técnicas
demostrables, objetivos estratégicos del servicio bien definidos y que
tengan una clara identificación de los actores involucrados en el proyecto.
5.1.c. Enfoque ciudadano: Proyectos que fortalezcan la misión del

servicio y aporten a la eficiencia de sus procesos. Los proyectos deben
apuntar a mejorar las prestaciones del servicio, con el objetivo final de
entregar valor al ciudadano, incluyendo estrategias de protección de datos
personales.
5.1.d. Gestión de Cambio: Proyectos donde se explicite claramente la

estrategia de cambio, objetivos que se quieren alcanzar, capacitación y
empoderamiento de usuarios, beneficios esperados, entre otros.
5.1.e. Estado Basado en Datos: Los proyectos deben fomentar y

entregar herramientas para que se puedan gestionar políticas públicas
basadas en evidencia y datos. Las plataformas presentadas deben
especificar el tipo de reportabilidad, visualización y herramientas en
general que permitan tomar decisiones basadas en los datos.
5.1.f. Metodología de proyecto: La metodología del proyecto debe

estar bien definida y ser reconocida como estándar internacional, además
de contener hitos con entregables bien definidos.
5.1.g. Alineamiento con la Ley de Transformación Digital: Toda

iniciativa que esté directamente enfocada a la implementación de la Ley de
Transformación Digital (ley N° 21.180), y que pueda demostrar dicha
alineación, ya que, no toda iniciativa de digitalización corresponde a la Ley.
11
5.1.h. Infraestructura: Estrategias de infraestructura tecnológica como
sistema integrado y no una colección de iniciativas desarticuladas, “cloud
first” que priorice la operación y respaldo en la nube y elimine la
dependencia de hardware y sala de servidores en cada servicio público,
escalables y elásticas cuando se requiera, tanto para plataformas legacy o
se basen en nuevas tecnologías como Machine Learning, BI, IoT, geo-
referenciación, etc.
5.1.i. Simplificación: Proyectos que reutilicen plataformas de otras

instituciones, utilicen plataformas disponibles en Gobierno Digital
(https://digital.gob.cl/plataformas-transversales/), proyectos que eliminen
sistemas legados, que brinden eficiencia presupuestaria, que consoliden
plataformas y que interoperen desde su origen.
5.1.j. Gobernanza: Los proyectos e iniciativas que consideren

consultorías o desarrolladores externos deberán dividirse por etapas y
conformar un Directorio compuesto por integrantes del mismo servicio o
de otro servicio no relacionado. Cuando se trate de proyectos e iniciativas
de alto impacto, entendidas como, proyectos emblemáticos del programa
de gobierno, proyectos transversales que impactan a muchos ciudadanos
y/o involucran a varios organismos del Estado, y/o su costo está por sobre
el millón de dólares, la Dirección de Presupuesto solicitará la conformación
de un Directorio integrado por representantes de la institución y por
contrapartes de Gobierno Digital y Hacienda. El servicio responsable del
proyecto deberá reportar periódicamente los avances de cada etapa y
obtener el V°B° de dicho Directorio antes de continuar con la siguiente
etapa del proyecto.
5.1.k. Plazo: Considerando los constantes avances y cambios que se

presentan en el rubro de la Tecnología, el período máximo de
implementación de un proyecto no deberá superar el año presupuestario,
12
salvo casos excepcionales. Los proyectos que superen un año de plazo
deberán ser justificados en detalle, con hitos identificables respecto de las
etapas de desarrollo y con entregables bien definidos.
5.1.l. Información presupuestaria asociada: La información financiera

asociada a los proyectos presentados deberá ser referenciada con la
estructura de la formulación presupuestaria. Se deberá indicar el subtítulo
y programa presupuestario de imputación asociado. Si el proyecto será
imputado a más de un subtítulo o programa se deberán especificarse los
montos que se imputarán a cada uno.
5.1.m. Nuevas tecnologías: Iniciativas que involucren migración a nuevas

tecnologías, o implementen nuevas tecnologías como IA, Machine
Learning, Blockchain, BI, IoT, georeferenciación, etc .
5.1.n. Estrategia de Compras: Estrategias de compras

compartimentados, es decir, evitar contratos paragua donde se mezclan
proveedores o tecnologías que no tienen sinergias entre ellas con largos
polinomios de evaluación. Para todo proyecto donde los criterios de
evaluación sean cumplir con requerimientos técnicos mínimos y una vez
cumplidos éstos se evaluará el criterio de precio buscando la eficiencia en
los procesos de compras, serán ponderados positivamente.
5.2. INSTRUCCIONES TI ESPECÍFICAS
Los cambios que ha traído la pandemia respecto a cómo nos relacionamos y

comunicamos es profunda y llegó para quedarse. Las instituciones deben adaptar sus
plataformas y servicios de comunicaciones para esta nueva realidad. Se deben aplicar
criterios específicos de eficiencia en el Estado y masificar el uso de estándares y buenas
prácticas en TI con indicadores medibles y conocidos. Los criterios específicos son los
siguientes:
13
5.2.a. Compra o Arriendo Equipamiento Computacional: La
renovación o compra de equipamiento tipo Desktop, Notebook o All-In-
One debe:
 Justificar la cantidad total solicitada, identificando los tipos de usuarios y

sus roles.
 Definir la Gama de cada equipo, que debe estar ajustada a la función y
cargo de quien será asignado el equipo.
 Evaluar financiera y operacionalmente la modalidad de arriendo a 36 meses
versus la compra de los equipos.
 Considerar todo el software que será instalado (licencias de Sistema
operativo, antivirus, ofimática, etc., si vienen incluidas en el precio debe
especificar que es así) para evaluar el precio final y compararlo con el
arriendo. Debe adjuntar en el proyecto un inventario de los equipos
actuales, con al menos versión de sistema operativo, mes/año de
adquisición, RAM, disco duro, procesador, formato (equipo/notebook).
 Indicar si la Institución cuenta con un contrato de arriendo vigente asociado
al requerimiento específico. En caso de que así sea, se deberá indicar el
número de equipos y la fecha de vencimiento del contrato.
5.2.b. Compra/Renovación de Licencias para Equipamiento

Computacional: Para las licencias de ofimática o de colaboración se debe
especificar la cantidad de usuarios por perfil de licenciamiento según la
licitación Convenio Marco ID 2239-28-LR20. Adicionalmente, realizar un
inventario de las licencias vigentes, así como su nivel de uso por instalación
dentro de la institución y su fecha de expiración actual. Cabe recordar que
otras instituciones están realizando compras similares, por lo que se
reforzará la agregación de demanda para realizar una compra coordinada,
o mediante un Convenio Marco, optimizando el uso de los recursos
públicos. En este sentido, la dirección que se debe adoptar es de eliminar
infraestructura de servidores on premises e ir moviéndose a la nube de
alguna de las alternativas disponibles por Convenio Marco.
14
Se debe indicar si la Institución cuenta con licencias vigentes asociadas
al requerimiento específico. En caso que así sea, se deberá indicar el
número de licencias y la fecha de vencimiento de éstas.
5.2.c. Compra/Renovación de Licencias de Infraestructura

Servidores/Cloud: Para compra/renovación de licencias de servicios cloud
(IaaS, PaaS, SaaS, entre otros), ya sea en infraestructura propia,
externalizada o nube, se debe especificar claramente la cantidad de
servidores y su función específica/url, y si los volúmenes de acceso en
particular son para el cumplimiento de una ley específica. Adicionalmente,
realizar un inventario de las licencias, así como su nivel de uso por
instalación dentro de la institución y su fecha de expiración actual.
5.2.d. Compra/Renovación de Infraestructura de Data Centers: De no

ser posible una migración a la nube y se deban mantener en servidores
legacy o particulares, estos deberán considerar migraciones o traslados a
proveedores especialistas (housing especializado). En base a lo anterior, no
se aceptarán proyectos de mejora, ampliación o construcción de Data
Center o salas de servidores en dependencias del Estado. Todo proyecto
para alojar, tanto en infraestructuras compartidas como exclusivas, si así lo
amerita, deben estar costeados como una compra especialista a
proveedores reconocidos del mercado y justificados en detalle.
5.2.e. Compra/Renovación de Infraestructura de Comunicaciones:

Respecto de la telefonía fija, no se aceptarán proyectos de renovación de
telefonía ya sea análoga o IP. Sólo se podrán presentar renovaciones de
planes de minutos y proyectos para dar continuidad a los anexos, que
deban ser conectados con las plataformas de colaboración que la
institución tenga implantadas tipo IP Cloud. Con la adopción de las
herramientas de colaboración y plataformas de videollamadas, los
teléfonos fijos sólo serán aceptados para centros de atención telefónica
15
ciudadana, teléfonos que durante los últimos 12 meses del presente
tengan uso mensual superior a 750 minutos promedio, así como para
secretarias y gabinetes.
Respecto de los enlaces de comunicaciones, éstos deben asegurar soporte

para los nuevos comportamientos, movilidad y multimedia, por lo que los
proyectos deben establecerse con KPIS de usuarios por enlace para
establecer criterios claros de solicitudes de anchos de banda tanto de
subida como de bajada.
5.2.f. Ley de Transformación Digital:
 Cumplimiento de guías, directivas y leyes: Cumplir con las guías entregadas

por la División de Gobierno Digital, instructivos y Guías de ChileCompra,
Instructivo Presidencial sobre Transformación Digital y Ley de
Transformación Digital.
 Ejes de transformación digital: Se debe identificar si la iniciativa responde a

alguno de los ejes de la estrategia de transformación digital, estos son:
 Identidad Digital: en particular si la plataforma tiene o se subirá al Uso
de Clave Única para la autenticación de usuarios.
 Cero Papel: Por medio de la optimización y digitalización de procesos
internos, con foco en la interoperabilidad, comunicación electrónica,
gestión documental, firma electrónica, y uso de la plataforma
DocDigital (https://doc.digital.gob.cl/).
 Cero Filas: Esta política busca disminuir o eliminar las filas para las
personas que interactúan con el Estado. Su foco está puesto en permitir
a las personas la interacción en línea, ya sea digitalizando trámites o
mejorando sustantivamente la experiencia en los trámites existentes.
Desarrollos de FrontEnd: Para trámites y servicios de cara al ciudadano,
es obligatorio, salvo justificación contraria, lo siguiente:
○ Que sea desarrollado “Mobile First” (responsivo). Dada la
penetración del uso de dispositivos móviles es que este
16
criterio toma suma importancia sobre todo en los
desarrollos de cara a las personas.
○ Debe indicar si el proyecto responde al “Plan de
Digitalización” ·declarado en el Registro Nacional de
Trámites (https://tramites.gob.cl/).
○ Debe considerar el actualizar o publicar en ChileAtiende.
Se deben seguir los lineamientos y estándares que emanan de la Ley

21.180 y de la División de Gobierno Digital (DGD) del Ministerio
Secretaría General de la Presidencia, con el fin de avanzar en la
transformación digital del Estado. Más detalles de la estrategia de
transformación digital pueden ser revisados en el sitio de la DGD
(https://digital.gob.cl).
5.2.g. Se debe tener en cuenta en todo momento al formular nuevos

proyectos el alcance de la Ley de transformación Digital2 (ley N°21.180),
por lo tanto, la Interoperabilidad debe ser un foco prioritario en los
proyectos.
5.2.h. Las Instituciones deben siempre evaluar el uso de las plataformas

compartidas como «ClaveÚnica», «Simple», «FirmaGob», «datos.gob.cl».
5.2.i. En el caso de desarrollos de servicios de Autoatención se debe

implementar la utilización de la ClaveÚnica y realizar la integración con
ChileAtiende.
5.2.j. Para los desarrollos que vayan a iniciar, debe considerar siempre:
 Debe cumplirse con lo establecido en la definición del proyecto,

independiente de quién realice el desarrollo (interno o proveedor externo),
esto es, lograr los objetivos y por lo tanto se debe tener objetivos claros,
alcanzables y medibles.
2
https://digital.gob.cl/transformacion-digital/ley-de-transformacion-digital/
17
 Siempre debe optar por la compra de proyectos por sobre la contratación
de HH para desarrollos internos.
5.3. CAUSALES DE EVALUACIÓN NEGATIVA
El no cumplimiento de los criterios mencionados anteriormente, dan origen a un conjunto

de motivos de objeción técnica o de rechazo a los proyectos presentados:
a. No cumplimiento con los criterios de compra establecidos, según lo indicado

en las Instrucciones para la ejecución de la Ley de Presupuestos.
b. Oportunidad o problema no debidamente analizado, es decir, no se
identificaron las causas y efectos del problema identificado, no se definió la
situación actual, no se evaluó qué pasaría en caso de no darle solución al
problema, entre otros.
c. La solución no resuelve el problema identificado.
d. No muestra beneficios, es decir, el proyecto no tiene el enfoque ciudadano
descrito en la presente guía, no se define una estrategia asociada a la gestión del
cambio, el proyecto no involucra nuevas tecnologías, entre otros.
e. No hay resultados tempranos, es decir, el proyecto no apunta a desarrollos
ágiles, que permitan ir viendo resultados del proyecto y ajustar la dirección o
detectar problemas a tiempo.
f. Productos mínimos viables, no uso de metodologías ágiles.
g. No tiene plan bien definido o calendario de hitos identificables.
h. No diferencia debidamente inversión y/o costos recurrentes, es decir, no se
especifica qué corresponde a los costos de implementación del proyecto, y qué
corresponde a costos de mantención, entre otros.
i. No cumplimiento de los criterios indicados en la sección “5.2. Instrucciones
TI Específicas”.
j. Sus costos están sobreestimados.
k. Sus costos están subestimados.
18
l. No aplica política Cloud First o Cloud Smart, es decir, se debe partir desde el
diseño del proyecto, pensando en modelos “cloud”.
m. No muestra equipo de proyecto, es decir, no se especifican los actores
interesados y sus roles, que aseguren que el proyecto cuenta con el respaldo
institucional.
n. No seguir las directrices de la presente guía o no utilizar el formulario oficial
completo («Formato de Proyecto Nuevo, Formato de Proyecto de Arrastro o
Proyecto de Continuidad operacional»), incluidos como anexos en la
presente guía.
o. Mala caracterización de los proyectos, es decir, que no se especifiquen las
tecnologías o líneas tecnológicas que abarca el proyecto.
5.4. COMPLETAR FORMULARIO DE IDENTIFICACIÓN DE

PROYECTOS TI
En este proceso de formulación de proyectos TI se utilizarán 3 formularios para

caracterizar cada uno de los tipos de proyectos que las instituciones deben ingresar en la
plataforma. Estos tipos de proyectos son:
5.4.a. Proyectos nuevos: corresponden a toda iniciativa nueva de las

instituciones, que no se relacionan con la continuidad operacional, se debe
distinguir claramente este tipo de proyecto del resto, ya que de otra
manera puede afectar a la institución por recibir recomendación de
rechazo. Estos proyectos incluyen también aquellas adecuaciones de
sistemas ya operativos a los cuales hay que agregar nuevas funcionalidades
o adecuaciones a nuevas realidades tecnológicas o cambios legislativos
que impliquen adecuaciones de los sistemas. Desde el año 2021 se agregó
una caracterización de proyectos, la cual apunta a la correcta clasificación
dentro de los ámbitos que tocará cada proyecto, además se usará dentro
19
de la evaluación si realmente los proyectos corresponden a lo declarado
en la caracterización, si no es así los proyectos pueden ser rechazados, por
esto es importante ser riguroso con dicha caracterización y declararlo
abiertamente en la descripción o alcance del proyecto.
5.4.b. Proyectos de continuidad operacional: en este tipo de proyectos

se deben identificar todos aquellos que impliquen renovación de equipo,
licencias, mantención de sistemas ya existentes y todo lo relacionado para
tener en óptimo funcionamiento la operación ya existente en la Institución,
esto implica corrección de problemas o aumentos de capacidades, pero no
nuevas funcionalidades, la contratación de HH para la administración de
sistemas, BD, etc. Los desarrollos de nuevos módulos o nuevas
funcionalidades no deben ser considerados dentro de este tipo de
proyectos, deben ser ingresados como proyecto nuevo.
5.4.c. Proyectos de Arrastre de años anteriores: corresponden a

aquellos requerimientos realizados en años anteriores, que fueron
aprobados en procesos anteriores y que cuenten con código entregado
por el sistema EVALTIC, y que para este proceso ya se encuentran en
implementación desde en el segundo año hacia adelante. Este tipo de
proyectos deberá hacer mención al código de proyecto original, de manera
que ya no será necesario el ingreso de toda la información del proyecto,
solo lo correspondiente a la etapa del proyecto en que se encuentren y
vayan a realizar. Si un proyecto no cuenta con el código entregado por la
plataforma deberá obligatoriamente ser ingresado como un proyecto
nuevo, y hacer ver que el proyecto viene de iniciativas anteriores ya
aprobadas, indicar el año en que se encuentra y cuántos años le quedan
para terminar.
Todos los formularios se encuentran contenidos en el Anexo N°2 de esta guía,

adicionalmente se encontrarán disponibles en la plataforma dispuesta por DIPRES que
20
también contendrá toda la documentación relevante para el proceso. Esta será
comunicada durante el período de capacitaciones y al momento de informar el inicio del
proceso a los respectivos jefes de servicio.
5.5. INGRESAR AL APLICATIVO DE DIPRES
Para ingresar a la plataforma de la Dirección de Presupuestos (DIPRES) debe tener

definido su Usuario y Clave, estos serán proporcionados por la DIPRES al personal de la
Dirección Administrativa y Financiera (DAF) de cada institución, el cual será el responsable
de ingresar las solicitudes al sistema, en caso de que la DAF estime necesario, solicitará
nuevas credenciales o compartirá las credenciales con los responsables de la Formulación
de los proyectos.
Para Ingresar a la plataforma dispuesta por DIPRES se deben seguir las indicaciones del
Anexo N°2 de este documento.
Al completar el formulario de identificación de proyectos, se le asignará un código

identificador de proyecto único, el cual será generado por la plataforma y se compone de
la siguiente manera:
AAAA.MM.IIIIII. XX
Donde AAAA corresponde al año del proceso presupuestario, MM corresponde al código

DIPRES del Ministerio, IIIIII corresponde al código DIPRES de la institución y finalmente XX
corresponde a un correlativo ascendente por cada proyecto presentado.
Ejemplo: 2021.05.000563.01
Proceso año presupuestario 2022, MINISTERIO DEL INTERIOR Y SEGURIDAD PÚBLICA,

SUBSECRETARÍA DE DESARROLLO REGIONAL Y ADMINISTRATIVO y corresponde al
primer proyecto presentado.
21
Se debe tener en cuenta que este código será solicitado por ChileCompra en los sucesivos
procesos de compra y deberá ser agregado, ya que eventualmente DIPRES procederá a
validar dicho código contra lo que se está comprando.
6. CONTACTO E INFORMACIÓN
Para realizar consultas, resolver dudas, problemas e inquietudes, se habilitó la casilla de correo
evaltic@dipres.gob.cl, las cuales serán respondidas a la brevedad posible.
22
7. ANEXOS
ANEXO N°1: PROCESO DE DESARROLLO DE SOFTWARE
Cualquier modelo de proceso para el desarrollo de software debe contener al menos cinco macro
actividades: comunicación, planificación, modelado, construcción y puesta en operaciones.
Naturalmente, durante este proceso, también se aplica un conjunto de «actividades generales»:
seguimiento y control de proyectos, gestión de riesgos, garantía de calidad, gestión de la
configuración, revisiones técnicas y otras.
Comunicación: La base del éxito de un proyecto está dada por establecer los canales e instancias
de comunicación entre todos los involucrados (cliente, stakeholders, etc.). Lo anterior, asegura
que cualquier proyecto avance de la manera adecuada. El objetivo de esta macro actividad es
comprender los objetivos de todas las partes interesadas del proyecto, recopilar requisitos que
ayuden a definir las características y funciones del software y fomentar el compromiso con el
proyecto.
Planificación. Un proyecto de desarrollo de software siempre es complejo y la actividad de

planificación ayuda a reducir esta complejidad: creando un plan de proyecto de software que
guiará al equipo, definiendo el trabajo de ingeniería de software al describir las tareas técnicas
que se realizarán, los riesgos probables, los recursos que se requerirán, los productos de trabajo
que se producirán, el cronograma de trabajo y una estimación del esfuerzo.
Modelado. Se crea un modelo para comprender el panorama general, es decir, cómo se verá
arquitectónicamente, cómo encajarán e interactuarán las partes constituyentes y muchas otras
características. Dependiendo de la necesidad, este modelo se refinará cada vez con mayor detalle
en un esfuerzo por comprender mejor el problema y especificar el cómo se va a resolver.
Construcción. Esta actividad combina la generación de código (manual o automatizada) y las

pruebas necesarias para descubrir errores en el código.
23
Puesta en operaciones. El software, ya sea como una entidad completa o como un incremento
parcialmente completado, se entrega al cliente, quien evalúa el producto entregado y
proporciona retroalimentación basada en su evaluación acorde a sus criterios de éxito.
Otro aspecto importante en el proceso de software es el flujo de las macro actividades, este flujo
describe cómo las actividades del modelo, es decir, las acciones y tareas que ocurren dentro de
cada actividad del modelo están organizadas con respecto a la secuencia y el tiempo. Existen
diferentes flujos de las macro actividades:
El flujo de proceso lineal, que ejecuta cada una de las cinco actividades del modelo de manera
secuencial, comenzando con la comunicación y culminando con la implementación.
El flujo de proceso iterativo, que repite una o más de las actividades antes de pasar a la siguiente.
El flujo de proceso evolutivo, que ejecuta las actividades de manera «circular». Cada circuito a
través de las cinco actividades conduce a una versión más completa del software.
El flujo de proceso paralelo, que ejecuta una o más actividades en paralelo con otras actividades,
por ejemplo, el modelado de un aspecto del software podría ejecutarse en paralelo con la
construcción de otro aspecto del software. Independiente del flujo que se opte por aplicar en el
desarrollo de un software, es que se recomienda aunar las macro actividades en cuatro fases
definidas, para así plasmarlas en los formularios de EVALTIC:
 Fase de idea. El objetivo de la fase inicial es establecer un caso de negocio para el sistema.
Debe identificar todas las entidades internas y externas (personas y sistemas) que
interactuarán con el sistema y definir estas interacciones. Luego, se utiliza esta información
para evaluar la contribución que el sistema haría al negocio, a la visión-misión y objetivos
de la organización o el impacto que generaría en la ciudadanía. Si esta contribución es
menor, el proyecto puede cancelarse después de esta fase.
 Fase de elaboración. Los objetivos de la fase de elaboración son el desarrollar una
comprensión del dominio del problema, establecer un marco arquitectónico para el
sistema, desarrollar el plan del proyecto e identificar los riesgos clave del proyecto. Al
completar esta fase, se debe tener un modelo de requisitos para el sistema, que puede
ser un conjunto de casos de uso en UML, una descripción de la arquitectura y un plan de
desarrollo para el software.
24
● Fase de construcción. La fase de construcción implica el diseño, la programación y las
pruebas del sistema. Algunas partes del sistema se desarrollan en paralelo y se integran
durante esta fase. Una vez completada esta fase, se debería tener un sistema de software
en funcionamiento y la documentación asociada que esté lista para entregar a los
usuarios.
● Fase de transición. La fase final se ocupa de trasladar el sistema de la comunidad de
desarrollo a la comunidad de usuarios y hacer que funcione en un entorno real. Esto es
algo que se ignora en la mayoría de los modelos de procesos de software, pero, de hecho,
es una actividad costosa y a veces problemática. Al completar esta fase, se debe tener un
sistema de software documentado que funcione correctamente en su entorno operativo.
Es necesario indicar que en base a la experiencia de años anteriores con EVALTIC, se manifiesta
de manera reiterada que proyectos de desarrollo de software se presenten integrando todas las
fases anteriores. Esto aumenta enormemente el riesgo de éxito del proyecto y a su vez, es muy
difícil justificar el presupuesto solicitado, aumentando así la probabilidad de ser rechazado o de
sufrir iteraciones entre el Formulador y los Evaluadores que requieren una mejor comprensión
del problema o lograr tener conocimiento de los detalles faltantes.
Generalmente, la «fase de idea» se debe efectuar de manera interna en la organización (ya que
es la propia organización que conoce «el qué») y en base al resultado positivo de esta fase, se
debe efectuar la «fase de elaboración» («el cómo»).
Nuestra recomendación es que los proyectos sí sean presentados para la «fase de elaboración»
y sean detallados en EVALTIC como proyectos por sí mismos, utilizando el formulario para
proyectos nuevos.
Posteriormente los insumos obtenidos de esta fase serán utilizados para un proyecto que aúne
la «fase de construcción» y la «fase de transición» o para dos proyectos para cada una de las fases
siguientes («construcción» y «transición»). Este proyecto o proyectos, serían, por lo tanto,
proyectos de arrastre y deberá usarse el «formulario para proyectos de arrastre de años
anteriores».
25
Naturalmente lo ideal es que cada fase (elaboración, construcción y transición) se presente como
proyecto en sí mismo, ya que las empresas consultoras se especializan en las diversas fases del
desarrollo de software, o en las diversas «actividades generales» y es muy difícil que una empresa
tenga el «know-how» de todas las fases y actividades, por lo que por lo general subcontratarían
estos servicios o efectuarían una Unión Temporal de Proveedores para así cumplir con los
requisitos de la adquisición.
26
ANEXO N°2: INTERFAZ DIPRES-EVALTIC
Los pasos básicos para comenzar a subir proyectos TIC a la plataforma EVALTIC, son los
siguientes:
i. Ingresar a la página web de DIPRES y seleccionar el link «Acceso Restringido» resaltado

en amarillo en la imagen.
ii. Luego debe Ingresar su Usuario y contraseña en la página y seleccionar el Proceso y luego
hacer click en el botón
27
Donde se le presentará una pantalla similar a esta:
28
Luego se les presentará una información sobre el proceso (imagen anterior), ahí Ud. deberá dar
«Click» sobre el Botón continuar y se le presentará la siguiente pantalla:
Ahí ya está a punto de ingresar a la plataforma de EVALTIC, solo debe hacer «Click» sobre el
botón «Evaluación de Proyecto TIC»:
Ahora se le presentará la bandeja de proyectos, donde se le mostrarán todos los proyectos que
su Institución esté ingresando.
29
iii. Al desplegarse la Bandeja de entrada de proyectos, crea una nueva solicitud, ingresando
los datos que se solicitan y subiendo el FORMATO DE PROYECTO con todos los detalles
requeridos, además de cualquier otro documento/anexo que se estime relevante adjuntar
para una mejor comprensión del proyecto presentado. Se debe considerar que:
● Subir el FORMATO DE PROYECTO TIC es obligatorio;
● Subir otros documentos de apoyo es opcional;
● Todo documento debe ser enviado única y exclusivamente a través del sistema.
iv. La ficha de ingreso permite ir guardando la información subida, lo que permite editar el
proyecto por partes. Tras el envío de la solicitud ya no podrás editarla.
30
ANEXO N°3: FORMULARIOS OFICIALES «FORMATO
PROYECTOS TI»
Existen tres formularios oficiales de proyectos, uno para cada tipo de proyectos, que son
Proyectos Nuevos, Proyectos de continuidad operacional y renovación equipo o licencias y
Proyectos de continuación o arrastre de años anteriores.
A continuación, se entrega el formato para cada uno de estos formularios, los cuales también
serán entregados por separado para que sean completados por las instituciones.
A) FORMULARIOS PARA PROYECTOS NUEVOS:
FORMATO NUEVO PROYECTO TIC
El formato de documento “Formulación Nuevo Proyecto TIC” que se deberá subir

obligatoriamente a la plataforma EVALTIC, es el que se sigue a continuación. (NO SE ADMITIRÁ
OTRO TIPO DE FORMATO QUE PRESENTE EL SOLICITANTE, EL NO USARLO IMPLICARÁ QUE
LA SOLICITUD SERÁ RECHAZADA.)
En todas las respuestas debe ser preciso y entregar un resumen, no es necesario extenderse, si
desea entregar mayores antecedentes hágalo en documentos adjuntos distintos de éste y sólo
haga referencia a ellos acá.
Identificación del Solicitante
Servicio
Ministerio
31
Nombre del
Proyecto
Área Responsable
Jefe de Proyecto Nombre e-mail
Formulador Nombre e-mail
1. Resumen Ejecutivo (breve descripción del problema u oportunidad, descripción técnica de la

solución, recursos y costos involucrados, relación e interoperabilidad con sistemas/licencias
existentes, contribución a mejorar procesos y servicios de la institución, plazo de ejecución). Este
resumen debe luego ser copiado en el campo “Objetivo General Resumido” del formulario de la
plataforma EVALTIC. Este resumen debe ser ejecutivo y con foco en los aspectos tecnológicos del
proyecto.
2. Justificación del proyecto
2.1. Problema u oportunidad de mejora detectada
A. Identificación clara y detallada del problema u oportunidad. Si es un problema que

se quiere resolver, se deben identificar además todas las causas de éste. En la
solución propuesta, se debe indicar cómo ésta aborda la causa del problema(s).
32
2.2. Justificación de la propuesta de solución como la mejor alternativa
Todas las respuestas deben ser cortas, precisas y con foco en los aspectos técnicos
de la propuesta,. Si necesita extenderse hacerlo adjuntando los archivos que estime
pertinentes, como anexo a este documento para que el evaluador pueda revisarlos.
A. Describir soluciones alternativas, en caso de haber realizado Benchmark o estudios

de mercado. Otras soluciones posibles. Si y solo si no existen soluciones
alternativas, se deben explicar las razones por las cuales no existe solución
alternativa.
B. Descripción de la solución propuesta. Esta descripción debe ser breve y suscrita
exclusivamente al ámbito tecnológico.
C. Motivo por el cual se optó por la solución propuesta. Como complemento a la letra
A. se debe explicar los motivos por los cuales se opta por la solución en desmedro
de las alternativas planteadas. Esta explicación debe ser corta y precisa.
D. Resultados esperados en los procesos intervenidos y en los usuarios directos e
indirectos asociados al problema u oportunidad identificada. (ahorros en tiempo y
costos, beneficios tangibles, entre otros)
E. Pertinencia de la solución planteada (considerando la normativa y marco legal
vigente, oportunidad, capacidades instaladas de la institución, viabilidad técnica y
política en el tiempo, etc.)
2.3. Sostenibilidad de la propuesta
A. Compromiso de la institución proponente (acciones o iniciativas implementadas

con anterioridad en relación al problema u oportunidad identificada).
B. Compromiso de otros actores relevantes. Si procede, agregar qué otros actores
externos a la institución apoyan este proyecto y cómo lo hacen.
C. Coordinaciones / complementariedades con otras iniciativas y/o instituciones. En
base a los instructivos del Ministerio de Hacienda que insta a la realización de
compras coordinadas explicar qué esfuerzos se han realizado en esta línea.
33
3. Proyecto
3.1. Caracterización del proyecto
A. Tipo. Especificar si este proyecto corresponde a proyecto dirigido a la aplicación

de la Ley de transformación Digital, Interoperabilidad, etc.
Debe tener en cuenta que esta caracterización debe ser precisa y técnicamente
acotada. Esto será revisado y contrastado con el contenido del proyecto y puede
ser motivo de rechazo el poner caracterizaciones que no correspondan o que
falten.
Nueva Norma3
Clave Única
Simple
Alineamiento estratégico
Lineamientos de Gobierno Digital FirmaGob
RNT
DatosGob
Interoperabilidad
Gestión Documental Digitalización documentos
3
Corresponde a la implementación de un cambio normativo o legal que obligue a modificar los
procesos o sistemas para poder cumplir con ella, ej.: Ley de Transformación Digital. Es importante que
se consideren acá todos los proyectos que estén relacionados con la aplicación de la nueva ley de
Transformación Digital (Ley N° 21.180)
34
Archivística
Envío electrónico a Archivo

Nacional
Ciberseguridad
Manejo de datos personales
Datos sensibles
Privacidad de datos
Datos estratégicos
Procesos, datos secretos
B. Tecnologías. Especificar si este proyecto utilizará la “Nube”, si no lo hace se deberá

justificar y acompañar del plan que tiene la institución para moverse a la “Nube”,
si utilizará Inteligencia Artificial, Machine learning, etc.
I.A.
Data Warehouse
Business Intelligence
Tecnologías emergentes Blockchain
Georeferenciación
IoT
Otra
Nube Pública
35
Privada
Híbrida
No Nube Justificación y plan a futuro
Housing Local
Housing externo
Datacenter
Hosting
Storage
Ver Instrucciones para la Formulación de Proyectos, sección

“Como Formular Correctamente” punto 5.2.d
3.2. Objetivos
Los objetivos presentados en este documento deben ser claros y precisos. Si el formulador
estima necesario extenderse en la explicación, se recomienda entregar documentos adicionales
como anexo.
A. General (Impacto en la misión de la institución).

B. Específicos (etapas y resultados esperados)
3.3. Plazos
Deben considerarse los hitos relevantes dentro del proyecto y a aquellos que se les hará
seguimiento y control.
A. Calendario de Hitos identificables.

B. Etapas, productos entregables y plazos.
36
3.4. Bienes y servicios a contratar
Los bienes y servicios a contratar deben estar claramente identificados, no se aceptarán

ambigüedades, si se indican que se adquirirán licencias éstas deben ir claramente identificadas
por su código, cantidad, usuarios y modo de adquisición (compra o arriendo), lo mismo para el
hardware, se deben identificar claramente cuántos, de qué modelo y/o tipo se requieren adquirir.
Para el caso de la contratación de HH deberá proceder a la identificación de las HH que se
requieren y en qué funciones. Identificar claramente el perfil, la cantidad de cada uno y el costo
unitario por perfil.
A. Identificación del tipo de bienes y servicios a contratar.

B. Propuesta de planificación de compras. Para ello se debe utilizar estrategias de
compras compartimentados, es decir, evitar contratos paragua donde se mezclan
polinomios de evaluación. Para todo proyecto donde los criterios de evaluación
sean cumplir con requerimientos técnicos mínimos y una vez cumplidos éstos se
evaluará el criterio de precio buscando la eficiencia en los procesos de compras,
serán ponderados positivamente.
37
3.5. Presupuesto del proyecto.
Para un proyecto de N años de duración. (ES IMPORTANTE QUE TODOS LOS VALORES SEAN
EXPRESADOS EN MILES DE PESOS (M$) (TIPO DE CAMBIO USD$1 = $720), SI NO SE
CUMPLE CON ESTO, EL PROYECTO SERÁ RECHAZADO. SI TIENE TRASPASOS DEBE INDICAR
LA SUMA TOTAL ASOCIADA AL AÑO CORRESPONDIENTE Y EN EL RECUADRO DESTINADO
PARA ESTE EFECTO INDEPENDIENTE DEL SUBTÍTULO DE DONDE PROVENGAN).
Subtítul
Tipo de costo Ítem Año 1 Año 2 … Año N Subtotales
o
0 0 0 0
Sum
Traspasos 0 0 0 0
Traspasos
0 0 0 0
0 0 0 0
Costo de
implementaci 29 0 0 0 0 Sum 29
ón (CAPEX)
0 0 0 0
0 0 0 0
Costos
operacionales 22 0 0 0 0 Sum 22
(OPEX)
0 0 0 0
Sum año Total

Sum año 1 … Sum año N
2 Proyecto
Total (M$)
38
Subtítul
Tipo de costo Ítem Año N+1
o
Traspas 0
os
Costo 0
recurrente 0
22 0
A. Detallar sólo para los subtítulos e ítems necesarios (descripción y cuadro resumen).
a. Los traspasos corresponden a los montos que recibe la institución en
relación al proyecto (ejemplo Subtítulo 24), debe poner la sumatoria total
asociada a este proyecto para el año correspondiente.
b. CAPEX: gastos de capital, que se ejecutan ya sea para adquirir un activo
fijo o para añadir valor a un activo existente. Para nuestros fines,
corresponderán a los costos de implementación del Proyecto TIC.
c. OPEX Costos operacionales que podrían generarse durante la ejecución

del proyecto.
d. Subtítulo 22: Bienes y Servicios de Consumo
e. Subtítulo 29: Adquisición de activos no financieros

f. En caso de que el gasto deba ser imputado a otro subtítulo presupuestario,
se deberá especificar en esta sección, justificando la pertinencia de ello.
B. Costo recurrente: Corresponde a los costos operacionales y de mantención que

tendrá la solución una vez que entre en producción o régimen normal, no
39
corresponde a los costos involucrados durante la duración del proyecto. Incluye
mantenciones y/o soportes posteriores a la puesta en producción.
3.6. Organigrama de Proyecto
A. Organigrama asociado al proyecto y breve descripción de funciones, debe incluir

los Stakeholders, Product Owners, Jefes de proyecto, etc. No identificar a las
personas, sólo indicar sus cargos o roles. Esto debe estar relacionado con lo
declarado en el punto 2.3 letra A de este documento.
B. Seguimiento al proyecto. Identificar la metodología que se utilizará para mantener
control y seguimiento del proyecto. Esto está directamente relacionado con lo
declarado en el punto 3.3, ya que lo declarado ahí debe hacérsele seguimiento.
4. Riesgos
Describa brevemente si existen riesgos asociados al proyecto. Los riesgos descritos deben estar
asociados a la EJECUCIÓN del proyecto. No es necesario hacer una entrega de la matriz de
riesgos del proyecto, pero si declarar los más relevantes y de mayor impacto posible en el
proyecto.
B) FORMULARIO PARA PROYECTOS DE CONTINUIDAD OPERACIONAL Y RENOVACIÓN DE

EQUIPAMIENTO O LICENCIAS
FORMATO PROYECTO DE CONTINUIDAD y LICENCIAS
El formato de documento “Formulación de Continuidad y Licencias”, debe ser utilizado en todas

aquellas iniciativas donde esté involucrada la continuidad operacional, mantención evolutiva,
renovación de equipamiento y/o licencias. Para éstos casos el documento que se desarrolla a
continuación es el que deberá ser ingresado obligatoriamente a la plataforma EVALTIC (NO SE
40
ADMITIRÁ OTRO TIPO DE FORMATO QUE PRESENTE EL SOLICITANTE, EL NO USARLO
IMPLICARÁ QUE LA SOLICITUD SERÁ RECHAZADA.)
Todas las respuestas deben ser claras y precisas. Si el formulador estima necesario extenderse en
la explicación, se recomienda entregar documentos adicionales como anexo y sólo hacer
referencia en el campo que corresponda del presente formato.
Servicio
Ministerio
Tipo de Proyecto ___ Continuidad ___ Renovación/Adquisición ___ Renovación o
(marque con una X) Operacional de Licencias Adquisición de

Equipamiento
Área Responsable
41
1. Resumen Ejecutivo (breve descripción del problema u oportunidad, descripción técnica de la
solución, recursos y costos involucrados, relación e interoperabilidad con sistemas/licencias
existentes, contribución a mejorar procesos y servicios de la institución). Este resumen debe luego
ser copiado en el campo “Objetivo General Resumido” del formulario de la plataforma EVALTIC.
Este resumen debe ser ejecutivo y con foco en los aspectos tecnológicos del proyecto.
2. Justificación del proyecto
2.1. Problema u oportunidad de mejora detectada
B. Identificación clara y detallada del problema u oportunidad. Si es un problema que

se quiere resolver, se deben identificar además todas las causas de éste. En la
solución propuesta, se debe indicar cómo ésta aborda la causa del problema(s).
2.2. Justificación de la propuesta de solución como la mejor alternativa
A. Describir soluciones alternativas, en el caso de compra de equipamiento debe

haber evaluado a los menos la opción de arriendo y compararla con la compra.
B. Motivo por el cual se optó por la solución propuesta, especificando claramente las
razones para escoger una u otra opción.
C. Ahorros y beneficios cuantificables.
D. Pertinencia de la solución planteada (considerando la normativa y marco legal
vigente, oportunidad, capacidades instaladas de la institución, viabilidad técnica y
política en el tiempo, etc.)
2.3. Sostenibilidad de la propuesta
A. Compromiso de la institución proponente (acciones o iniciativas implementadas

con anterioridad en relación al problema u oportunidad identificada).
B. Compromiso de otros actores relevantes. Si procede, agregar qué otros actores
externos a la institución apoyan este proyecto y cómo lo hacen.
C. Coordinaciones / complementariedades con otras iniciativas y/o instituciones. En
base a los instructivos del Ministerio de Hacienda que insta a la realización de
42
compras coordinadas explicar qué esfuerzos se han realizado en esta línea, en caso
que aplique.
3. Proyecto
3.1. Caracterización del proyecto
A. TipoDebe tener en cuenta que esta caracterización debe ser precisa y técnicamente
acotada. Esto será revisado y contrastado con el contenido del proyecto y puede
ser motivo de rechazo el poner caracterizaciones que no correspondan o que falten
Obsolescencia
Aumento de Parque
Renovación licencias en uso actuales
Mantención evolutiva
Otros
Si especificó “Otros”, debe identificar claramente a que corresponde.
3.2. Objetivos
como anexo.
C. General (Impacto en la misión de la institución).

D. Específicos (etapas y resultados esperados).
3.3. Plazos
43

B. Etapas y plazos.

requieren y en que funciones. Identificar claramente el perfil, la cantidad de cada uno y el costo

C. En el caso de la compra o arriendo de equipamiento se debe especificar claramente
las funciones para las cuales será destinado y el perfil del usuario al que será
asignado en el caso de equipamiento de escritorio.
D. Para el caso de la compra de servidores, deberá justificar claramente cuál es el
motivo por el cual compra en lugar de arrendar un hosting o servicios en la nube.
44
Para este tipo de proyectos no es necesario poner lo proyectado a años posteriores. (ES
IMPORTANTE QUE TODOS LOS VALORES SEAN EXPRESADOS EN MILES DE PESOS (M$)
(TIPO DE CAMBIO USD$1 = $720), SI NO SE CUMPLE CON ESTO, EL PROYECTO SERÁ
RECHAZADO. SI TIENE TRASPASOS DEBE INDICAR LA SUMA TOTAL ASOCIADA AL AÑO
CORRESPONDIENTE Y EN EL RECUADRO DESTINADO PARA ESTE EFECTO INDEPENDIENTE
DEL SUBTÍTULO DE DONDE PROVENGAN).
Tipo de costo Subtítulo Ítem Total
Traspasos Sum Traspasos
Costo de
implementación 29 Sum 29
(CAPEX)
Costos operacionales Sum 22

22
(OPEX)
Total Proyecto
Total (M$)
45
b. CAPEX: Gastos de capital, que se ejecutan ya sea para adquirir un activo fijo
o para añadir valor a un activo existente. Para nuestros fines,
c. OPEX: Costos operacionales que podrían generarse durante la ejecución

del proyecto.

3.6. Organigrama de Proyecto
A. Organigrama asociado al proyecto y breve descripción de funciones, debe incluir

los Stakeholders, Product Owners, Jefes de proyecto, etc. No identificar a las
personas, solo indicar sus cargos o roles.
B. Seguimiento al proyecto. Identificar la metodología que se utilizará para mantener
control y seguimiento del proyecto.
4. Riesgos
proyecto.
46
C) FORMULARIO PARA PROYECTOS DE ARRASTRE DE AÑOS ANTERIORES
FORMATO PROYECTO DE ARRASTRE
El formato de documento “Formulación de Proyecto de Arrastre” que se deberá subir

obligatoriamente a la plataforma EVALTIC, es el que se sigue a continuación. (NO SE ADMITIRÁ
OTRO TIPO DE FORMATO QUE PRESENTE EL SOLICITANTE, EL NO USARLO IMPLICARÁ QUE
LA SOLICITUD SERÁ RECHAZADA.)
Este formulario es para uso exclusivo en proyectos que hayan sido presentado en procesos
anteriores de EVALTIC, por lo tanto, si no ha sido presentado anteriormente no debe utilizarlo y
deberá presentarlo en formulario de proyecto nuevo. Para presentar debe contar además con el
código original del proyecto entregado por la plataforma, para esto debe consultar en la
plataforma, puede revisar esto en la guía del formulador de proyectos. Al ingresar en la
plataforma el código del proyecto, el formulario digital vendrá precargado con la información ya
ingresada, Ud. solo deberá completar y/o actualizar lo que corresponda.
Servicio
Ministerio
Nombre del
Proyecto
Identificación ID proyecto original Año de avance

Proyecto Original
47
Deberá ingresar el código de proyecto que da origen a esta iteración anual, además del año de
avance al que se está solicitando el presupuesto. En caso de no contar con esta información, hacer
una referencia al proyecto original: nombre, año inicio.
1. Proyecto Original y estado actual. Debe entregar una referencia al proyecto original del cual
éste es una iteración anual o continuación. Se debe describir el estado de avance circunscrito a
aspectos tecnológicos, problemas encontrados y solución propuesta a c/u de ellos, la etapa que
se va a cubrir con esta iteración, hitos a alcanzar, productos o servicios ya entregados y resultados
esperados para esta etapa.
2. Proyecto
2.1. Características del proyecto
A. Tipo. Especificar si este proyecto corresponde a proyecto dirigido a la aplicación

de la Ley de transformación Digital del Estado (Ley N° 21.180), Interoperabilidad,
etc.
B. Tecnologías. Especificar si este proyecto utilizará la “Nube”, si no lo hace se deberá
justificar y acompañar del plan que tiene la institución para moverse a la “Nube”,
si utilizará Inteligencia Artificial, Machine learning, etc.
48
2.2 Objetivos
como anexo.
E. General (Impacto en la misión de la institución).

F. Específicos (etapas y resultados esperados)
2.3. Plazos

B. Etapas, productos entregables y plazos.

requieren y en qué funciones. Identificar claramente el perfil, la cantidad de cada uno y el costo

49
Para un proyecto de N años de duración, debe identificar los costos correspondientes al año de
avance del proyecto para el cual solicita el presupuesto. (ES IMPORTANTE QUE TODOS LOS
VALORES SEAN EXPRESADOS EN MILES DE PESOS (M$) (TIPO DE CAMBIO USD$1 = $720),
SI NO SE CUMPLE CON ESTO, EL PROYECTO SERÁ RECHAZADO. SI TIENE TRASPASOS DEBE
INDICAR LA SUMA TOTAL ASOCIADA AL AÑO CORRESPONDIENTE Y EN EL RECUADRO
DESTINADO PARA ESTE EFECTO INDEPENDIENTE DEL SUBTÍTULO DE DONDE
PROVENGAN).
Tipo de costo Subtítulo Ítem Año actual Subtotales
Traspasos 0 Sum traspasos
0
Costo de
implementación 29 0 Sum 29
(CAPEX)
0
0
Costos
operacionales 22 0 Sum 22
(OPEX)
0
Total (M$) Sum actual Total Proyecto
50
Costos pendientes del proyecto:
Tipo de costo Subtítulo Ítem Año + 1 … Año + N Subtotales
0 0 0
Traspasos 0 0 0 Sum Traspasos
0 0 0
0 0 0
Costo de
implementación 29 0 0 0 Sum 29
(CAPEX)
0 0 0
0 0 0
Costos
operacionales 22 0 0 0 Sum 22
(OPEX)
0 0 0
Sum año +
Sum año + 1 … Total Proyecto
Total (M$) N
b. CAPEX: gastos de capital, que se ejecutan ya sea para adquirir un activo fijo
o para añadir valor a un activo existente. Para nuestros fines,
51
c. OPEX Costos operacionales que podrían generarse durante la ejecución
del proyecto.

B. Costos Pendientes, que corresponden a los costos proyectados faltantes hasta el

fin del proyecto.
3. Riesgos
proyecto.
52

Instrucciones Formulación de Proyectos EVALTIC 2022-1

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Instrucciones Formulación de Proyectos EVALTIC 2022-1

Cargado por

Copyright:

Formatos disponibles

INSTRUCCIONES

Las presentes instrucciones están dirigidas a todos los organismos públicos y

Durante los últimos 4 años se ha generado un proceso dedicado y complementario a la

El proceso ha tenido mejoras incrementales año a año, destacando:

● Diseño e implementación de una plataforma para acompañar el proceso de

○ Proceso 2018: 64 Instituciones con 322 proyectos presentados.

● Ha fortalecido un proceso participativo de evaluación entre las instituciones del

○ Proceso 2018: Sin información disponible.

La experiencia de años anteriores ha consolidado la importancia de este proceso, dando

Con todo lo anterior, el proceso EVALTIC se ha posicionado como la instancia por

2. OBJETIVOS DEL PROCESO EVALTIC

En este proceso se pueden distinguir 3 perfiles distintos: Formuladores, Evaluadores y

Si bien, formalmente son las áreas de Administración y Finanzas quienes presentan la

● Supervisores, corresponden a funcionarios de la DIPRES y la DGD, encargados de velar

4.1. DIFUSIÓN Y CAPACITACIÓN

Esta etapa comprende la socialización del proceso y las capacitaciones. En la divulgación

i) Dirigidas a los Formuladores, responsables de ingresar las fichas de proyectos a la

La Difusión y Capacitación se llevará a cabo en el siguiente período:

4.2. FORMULACIÓN DE PROYECTOS

La formulación de proyectos es la base del proceso de EVALTIC, ya que es en ésta donde

La Formulación de Proyectos se llevará a cabo en el siguiente período:

10-05 / 30-06 – (Preliminar) Comenzará en cuanto la plataforma quede disponible y

4.3. EVALUACIÓN E ITERACIÓN

El proceso de evaluación corresponde a la etapa en la cual los distintos Evaluadores,

La Evaluación e Iteración se llevará a cabo en el siguiente período:

24-05 / 07-07 - (Preliminar) Comenzará en cuanto se hayan subido las primeras

El proceso de cierre corresponde a una etapa formal en que Formuladores y Evaluadores

El Cierre se llevará a cabo en el siguiente período:

30-06 / 09-07 - (Preliminar) El cierre se realiza en 2 etapas, primero se cierra el proceso

4.5. ANÁLISIS Y SEGUIMIENTO

El proceso de análisis y seguimiento corresponde al período en el cual se realiza el análisis

09-2021 / 03-2022 - Se procederá a hacer un análisis de la data contenida en la base

5. ¿CÓMO FORMULAR CORRECTAMENTE?

Se deberán presentar absolutamente todas las licencias de software, proyectos en curso

Existe un conjunto de principios generales de formulación que deben ser considerados

5.1.a. Coordinación interna: la institución deberá definir el equipo

5.1.b. Equipos de trabajo: Conformados por un equipo de profesionales

5.1.c. Enfoque ciudadano: Proyectos que fortalezcan la misión del

5.1.d. Gestión de Cambio: Proyectos donde se explicite claramente la

5.1.e. Estado Basado en Datos: Los proyectos deben fomentar y

5.1.f. Metodología de proyecto: La metodología del proyecto debe

5.1.g. Alineamiento con la Ley de Transformación Digital: Toda

5.1.i. Simplificación: Proyectos que reutilicen plataformas de otras

5.1.j. Gobernanza: Los proyectos e iniciativas que consideren

5.1.k. Plazo: Considerando los constantes avances y cambios que se

5.1.l. Información presupuestaria asociada: La información financiera

5.1.m. Nuevas tecnologías: Iniciativas que involucren migración a nuevas

5.1.n. Estrategia de Compras: Estrategias de compras

5.2. INSTRUCCIONES TI ESPECÍFICAS

Los cambios que ha traído la pandemia respecto a cómo nos relacionamos y

 Justificar la cantidad total solicitada, identificando los tipos de usuarios y

5.2.b. Compra/Renovación de Licencias para Equipamiento

5.2.c. Compra/Renovación de Licencias de Infraestructura

5.2.d. Compra/Renovación de Infraestructura de Data Centers: De no

5.2.e. Compra/Renovación de Infraestructura de Comunicaciones:

Respecto de los enlaces de comunicaciones, éstos deben asegurar soporte

5.2.f. Ley de Transformación Digital:

 Cumplimiento de guías, directivas y leyes: Cumplir con las guías entregadas

 Ejes de transformación digital: Se debe identificar si la iniciativa responde a

Se deben seguir los lineamientos y estándares que emanan de la Ley

5.2.g. Se debe tener en cuenta en todo momento al formular nuevos

5.2.h. Las Instituciones deben siempre evaluar el uso de las plataformas

5.2.i. En el caso de desarrollos de servicios de Autoatención se debe

 Debe cumplirse con lo establecido en la definición del proyecto,

Tipo de Proyecto _ Continuidad _ Renovación/Adquisición ___ Renovación o