Guía EvalTIC - Formuladores Proceso 2023

GUÍA PARA LA
FORMULACIÓN DE
PROYECTOS TIC
2023
EvalTIC
Versión 01 | Mayo 2022

0
ÍNDICE
CONTEXTO 2
INTRODUCCIÓN 2
EVOLUCIÓN 2
EVALUACIÓN DE PROYECTOS TIC 4
OBJETIVO GENERAL 4
OBJETIVOS ESPECÍFICOS 4
OBJETIVOS OPERACIONALES DEL PROCESO DE EVALUACIÓN 5
PRINCIPIOS 5
ACTORES DEL PROCESO 6
ETAPAS/PROCESO DEL PROYECTO 7
DIFUSIÓN Y CAPACITACIÓN 7
FORMULACIÓN DE PROYECTOS 7
EVALUACIÓN E ITERACIÓN 7
CIERRE 8
DISCUSIÓN PRESUPUESTARIA 8
¿CÓMO FORMULAR CORRECTAMENTE? 8
PLAZOS 18
CONTACTO E INFORMACIÓN 19
ANEXOS 20
ANEXO N°1: PROCESO DE DESARROLLO DE SOFTWARE 20
ANEXO N°2: INTERFAZ DIPRES-EvalTIC 23
ANEXO N°3: FORMULARIOS OFICIALES «FORMATO PROYECTOS TIC» 27

1
1. CONTEXTO
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) han definido el proceso de formulación de proyectos TIC. Este
proceso está dirigido a las Instituciones con el fin de promover 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 de cara a las personas, e impulsar el uso de tecnologías
emergentes, eficiencia en el gasto y transparencia.
En este proceso en especial se pondrá mayor énfasis en la evaluación de proyectos preparatorios

para la implementación de la ley de Transformación Digital (Ley N°21.180), por este motivo las
instituciones deben prepararse y comenzar con el levantamiento de sus procesos internos y sus
procedimientos administrativos que soportan los servicios prestados por éstas, con el fin de
optimizarlos y hacer más eficiente el compartir información.
También es muy importante recalcar la pronta entrada en vigencia de la Ley de Ley N°21.180 que
hará mandatorio la interoperabilidad de toda aquella información que sea requerida por otras
instituciones con el fin de prestar los servicios a las personas, esta interoperación debe estar
basada en el conocimiento de sus propios procesos internos y sus procedimientos administrativos.
La presente guía está dirigida a los profesionales del área TIC que participarán como Evaluadores
del proceso, con el fin de entregarles los lineamientos y criterios que deben aplicar como parte de
la metodología de evaluación y el uso de la plataforma que apoya este proceso.
1.2 EVOLUCIÓN
Este proceso ha sido implementado durante los últimos 5 años en un trabajo conjunto entre la
Dirección de Presupuestos (DIPRES) del Ministerio de Hacienda y la División de Gobierno Digital
(DGD) del Ministerio Secretaría General de la Presidencia. Para tales efectos, se generó un
proceso especial y complementario a la formulación presupuestaria habitual, mediante una
metodología ad hoc de formulación y revisión de proyectos tecnológicos del Estado, cuyo
resultado es una recomendación técnica de aprobar o rechazar un proyecto a los sectorialistas de
DIPRES, quienes finalmente deciden si se asigna presupuesto al proyecto y bajo qué condiciones.
El proceso ha tenido mejoras incrementales año a año, destacando:

2
● 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.
● 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.
○ Proceso 2022; 168 Instituciones con 2.538 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 varias iteraciones de
revisión 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 a Julio.
○ Proceso 2022: 400 Evaluadores desde Mayo a Julio.
Junto con el apoyo de DIPRES, que ha validado la importancia de este proceso dando señales
claras a las instituciones sobre su relevancia e impacto concreto en las decisiones de gasto, se
espera que el número de participantes crezca hasta lograr una cobertura del proceso del 100% de
las iniciativas tecnológicas del Estado. Adicionalmente, se espera que a contar del proceso
Adicionalmente, ChileCompra ha comenzado a sumarse al 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 licitaciones, el uso del código del
proyecto en el marco del proceso de Formulación de EvalTIC.

3
Las últimas modificaciones implementadas por ChileCompra en su plataforma de adquisiciones
está solicitando el ingresar el código de proyectos asignado por la plataforma EvalTIC para realizar
las solicitudes de compra, éste código es el que al ingresar una solicitud a la plataforma el sistema
lo genera en forma automática y puede ser consultado en cualquier momento dentro de la
plataforma, actualmente este código es optativo para las compras, pero será obligatorio en el corto
plazo, es por esto que se debe proceder a su utilización desde ya. DIPRES procederá a validar si
dicho código está registrado en el sistema, en caso contrario no se autorizará la compra.
Dado el involucramiento de DIPRES, ChileCompra y DGD en conjunto con el crecimiento en la

participación de las instituciones, ha ido formalizando el proceso EvalTIC como la única
herramienta oficial para la formulación de proyectos tecnológicos con cobertura del 100% de las
instituciones, de manera de fortalecer el seguimiento y control en la etapa de ejecución de los
proyectos tecnológicos con el fin de incrementar la eficiencia y alineamiento estratégico del gasto
en materia de transformación digital, así como proveer de información para la toma de decisiones
en el ámbito.
2. EVALUACIÓN DE PROYECTOS TIC

2.1. OBJETIVO GENERAL
Optimizar el gasto del Estado, alineando estratégicamente la inversión en TIC con las estrategias,
leyes e instructivos del Estado, específicamente en materia de transformación digital,
incrementando la calidad de los proyectos de tecnología de las Instituciones, mejorando los
mecanismos de control y generando información para apoyar la toma de decisiones.
2.2. OBJETIVOS ESPECÍFICOS

● 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 estrategia de
transformación digital del Estado1 y las iniciativas impulsadas en dicho marco.
● 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.
1
https://digital.gob.cl/doc/estrategia_de_transformacion_digital_2019_.pdf
4
● 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.
2.3. OBJETIVOS OPERACIONALES DEL PROCESO DE EVALUACIÓN

● Evitar que el Estado financie proyectos tecnológicos que no aportan valor público.
● Detectar necesidades transversales al Estado identificando nuevas oportunidades
para la entrega de servicios compartidos.
● Detectar proyectos estratégicos y proyectos con gastos excesivos.
● Identificar riesgos y retroalimentar las formulaciones para reducir los niveles de
fracaso en los proyectos TIC y mejorar su calidad.
● Detectar duplicidades e ineficiencias.
● Generar conocimiento acerca de los proyectos TIC para registro, análisis longitudinal y
para realimentar a las políticas de gobierno digital.
● Evaluar con bajos costos, las iniciativas formuladas por las instituciones.
2.4. PRINCIPIOS
● Generación de valor para los ciudadanos y usuarios finales: los proyectos TIC deben
generar impacto positivo para los ciudadanos, otras instituciones públicas y otras
entidades favorecidas, ya sea directa o indirectamente, y tanto financieros como no
financieros, en términos de reducción de costos o incremento de la calidad de los
servicios.
● Generación de Valor para la Institución que los formula: impactos financieros directos
en la institución en términos de ahorro en el gasto corriente o de capital, durante todo
el ciclo de vida del proyecto.
● Generación de valor a nivel transversal al Estado: genera beneficios financieros o no
financieros no atribuibles a una sola institución, pero que mejora transversalmente la
administración del Estado aprovechando economías de escala, de red o disminuyendo
costos de transacción, entre las principales.

5
3. ACTORES DEL PROCESO
El proceso de Formulación de Proyectos TIC para el Presupuesto es propiedad de DIPRES. y apoyado
por la DGD, ChileCompra y las distintas Instituciones del Estado. Las responsabilidades en este
proceso son complementarias ordenándose de la siguiente manera: DIPRES como dueña del proceso
de Formulación presupuestaria es la responsable de la fijación de etapas, plazos y la asignación final
del presupuesto; 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 las instituciones como formuladores de proyectos y en algunos casos
aportando como evaluadores.
Este proceso está soportado por 3 perfiles: Formuladores, Evaluadores y Sectorialistas, que cumplen
distintas funciones:
● Formuladores, son los encargados de definir los proyectos TIC de sus instituciones y subirlos a
la plataforma dispuesta por DIPRES. Si fuese necesario, interactuar durante el proceso
haciendo correcciones, como consecuencia de las evaluaciones, mediante las iteraciones.
Finalmente, en las rondas con los Sectorialistas cerrando el presupuesto final que se les
asignará.
Si bien, formalmente son las áreas de Administración y Finanzas quienes presentan la

formulación presupuestaria de la institución, en el proceso específico de EvalTIC, se requiere
contar con la participación activa del Coordinador de transformación digital. El Coordinador es
quien juega un rol estratégico apoyando a las áreas de administración y finanzas, para
incorporar 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 los cuerpo normativos
asociados, además de las orientaciones y directrices de la División de Gobierno Digital (DGD)
del Ministerio Secretaría General de la Presidencia en la materia.
● Evaluadores, son voluntarios de pertenecientes al área TIC de las distintas instituciones con
experiencia en la administración pública, se encargan de revisar proyectos de otras
instituciones que le son asignados, y basándose en los criterios definidos emiten una
recomendación de no objeción técnica o de rechazo Su función es de alta responsabilidad, ya
que su recomendación técnica será utilizada por los sectorialistas en la asignación de
presupuesto.

6
● Supervisores, corresponden a un conjunto de 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 ir surgiendo tanto en las instituciones como
a los evaluadores. También son los encargados de mantener la configuración de la plataforma, y
del proceso de seguimiento posterior.
4. ETAPAS/PROCESO DEL PROYECTO

El proceso de Formulación de Proyectos TIC para el Presupuesto (PPTO) del año 2023, 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
los que se espera de cada institución referente a la Evaluación de Proyectos TIC (EvalTIC). En esta
etapa se realizan dos tipos de capacitaciones:
● Dirigidas a los formuladores, responsables de ingresar las fichas de proyectos a la
plataforma EvalTIC provista por DIPRES.
● 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.
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 TIC 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 proyectos que ya fueron aprobados en
años anteriores, que ya están en marcha y requieren de presupuesto para continuar.
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 y tecnológicos, detallados en los puntos 5.1 y 5.2 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

7
proyecto revisado tenga observaciones o esté derechamente rechazado, pero dentro del plazo de
evaluación, la institución formuladora puede realizar las 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 esta sea reevaluada,
el número de iteraciones está limitado a un máximo de 2 iteraciones.
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.
4.5. DISCUSIÓN PRESUPUESTARIA

Si bien el proceso de discusión presupuestaria es posterior al proceso de EvalTIC, los resultados
de éste impactan de dos maneras en dicha discusión:
● Es un insumo a considerar en la decisión de asignación de recursos a la institución,

atribución exclusiva del sectorialista de DIPRES asignado. Esto significa que un proyecto
rechazado técnicamente podría recibir recursos si a juicio del sectorialista, los beneficios
del proyecto superan con creces una mala formulación.
5. ¿CÓMO FORMULAR CORRECTAMENTE?

5.1. INSTRUCCIONES GENERALES
Antes de ingresar las solicitudes en la plataforma deberá ingresar el inventario de su parque
tecnológico llenando la plantilla dispuesta en la plataforma, es importante que sea lo más preciso
con la descripción del equipamiento y las licencias, de esta manera facilitará la posterior revisión.
Se debe tener en cuenta que no será factible enviar las fichas a evaluación si es que no ha
ingresado dicho inventario. Este inventario se ingresa sólo una vez al comienzo, pero podrá
actualizarlo cuantas veces sea necesario.
Adicionalmente, existe un conjunto de principios generales de formulación que deben ser

considerados por la institución, debiendo cumplir la mayor cantidad posible, se entiende que no
todos son aplicables a ciertos proyectos. Se evaluará positivamente aquellos proyectos que
cumplan con los siguientes criterios:
8
5.1.1. Presentación de proyectos:
● Coordinación interna: la institución deberá definir el equipo responsable de la
correcta formulación y oportuna presentación de los proyectos TIC 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 integrar los lineamientos
estratégicos institucionales, las directrices de Gobierno Digital y los criterios
presupuestarios entregados por DIPRES.
● 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.
● Metodología de proyecto. El diseño y arquitectura deben estar alineados con los
estándares y protocolos TIC internacionales vigentes, con componentes y
entregables bien definidos.
● 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, 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.
● 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 especificar los montos que se imputarán a cada uno.
● 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. Si
la cuantía de los recursos requeridos supera los $ MM 500, al Directorio deberá
sumarse 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.

9
● Caracterización. Los proyectos deberán ser caracterizados adecuadamente dentro
de las opciones que las fichas disponen, una correcta caracterización evitará un
posible rechazo de los proyectos y facilitará la evaluación.
5.1.2. Técnicos generales:
● 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.
● 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.
● 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.
● Ciberseguridad. Es necesario que las Instituciones preparen proyectos en el
ámbito de la Ciberseguridad y Seguridad de la Información, siguiendo las
instrucciones del DS 83 del 2005 del Ministerio Secretaría General de la
Presidencia y lo indicado por el CSIRT en esta materia.
● 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.
● 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.3. Ley de Transformación Digital:
● Alineamiento con la Ley. 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.

10
● Interoperabilidad. Los proyectos que estén orientados a la utilización o
implantación de Nodo disponibilizado por la DGD en virtud de la implementación
de Interoperabilidad por el marco de la Ley N°21.118. Cualquier proyecto de
Interoperabilidad que no esté orientado a la implementación de la Ley de
Transformación Digital, deberá ser justificado claramente. Adicionalmente el uso e
implementación del NODO disponibilizado por la DGD para facilitar la integración
debería ser prioritario.
● Gestores documentales y de expedientes. En línea con lo decretado en la Ley
N°21.180, se debe tener en cuenta que los proyectos de implementación o puesta
en marcha de dichos gestores son prioritarios.
● Levantamiento de procesos. Dada la pronta entrada en vigencia de la Ley de
Transformación Digital, es que las Instituciones deberán identificar sus procesos
internos que soporten su negocio y para esto es que deberán presentar dicho tipo
de proyectos y éstos deberán ser evaluados tomando en cuenta la Ley N°21.180, la
que será su justificación.
5.2. CUMPLIR CRITERIOS TIC/ESPECÍFICOS Y DE COMPRAS

Es necesario que en conjunto con los criterios técnicos generales también se cumpla con los
siguientes criterios específicos, con ellos se pretende lograr una eficiencia en el Estado y masificar
el uso de estándares y buenas prácticas en TI. Estos criterios apuntan específicamente a la
optimización de los proyectos, cumplimiento de las Guías de la División de Gobierno Digital y de
ChileCompra, e implementación del Instructivo Presidencial sobre Transformación Digital y la Ley
de Transformación Digital, que impone la necesidad que las instituciones deban interoperar. Los
criterios específicos a cumplir son los siguientes:
5.2.1. Ley de Transformación Digital, como una fase previa a la implementación de la Ley
N°21.180, las instituciones deberán hacer un levantamiento de todos sus procesos
sustantivos o core y de sus procedimientos administrativos. Para ésto, deberán
presentar proyectos para su documentación o actualización y optimización si procediere,
los cuales serán bien evaluados en la medida que estén bien estructurados y sean
razonablemente cubicados en plazos y costos.
5.2.2. Criterio de compras PC, al igual que todos los años DIPRES entrega lineamientos para
la adquisición de PCs:

11
● Siempre se debe evaluar la modalidad de arriendo a 36 o 48 meses versus la de
compra, por lo que siempre se debe incluir esa comparación.
● Debe estar claramente definida la función/cargo al cual será asignado el equipo o
licencia.
● Debe considerar todo el software que le será instalado (licencias de sistema
operativo, antivirus, ofimática, etc., si vienen incluidas en el precio debe especificar
cada una de ellas) para evaluar el precio final y compararlo con el arriendo.
5.2.3. Compra/renovación de licencias. De igual manera a la compra de equipos, se debe

especificar claramente a qué función/cargo será destinada, según 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.
5.2.4. 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.5. 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/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 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.6. 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

12
para centros de atención telefónica ciudadana, teléfonos que durante los últimos 12
meses del presente tengan bolsa de minutos promedio mensual superior a 750 minutos,
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.7. 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.
5.2.8. 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: La Identidad Digital de Chile, asegura la identificación digital de

las personas, la capacidad de acceder y utilizar los datos personales, de firmar
digitalmente y de compartir información a otras instituciones. Consiste en una
estrategia nacional que permite acceder digitalmente a múltiples servicios y
autorizar el uso de datos personales para interoperabilidad y, con ello, eliminar
cientos de certificados y trabas que generan entidades tanto públicas como
privadas.
● Cero Papel: Esta política busca hacer al gobierno central más eficiente en su
operación, reduciendo la cantidad de procesos realizados manualmente y en
soporte 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.
● Procesos y procedimientos administrativos: Para preparar o implementar la Ley

de Transformación Digital (Ley N°21.180), las instituciones deberán hacer un

13
levantamiento de sus procesos relevantes y sus procedimientos administrativos
afectos a la Ley y los cuerpos normativos asociados.
5.2.9. Otros criterios relevantes. Dentro de la formulación no solo se deben considerar los
criterios anteriormente enumerado, sino que también existen otra serie de éstos que
debe ser considerada:
● Desarrollos de FrontEnd: Para trámites y servicios de cara al ciudadano, es

obligatorio, salvo justificación contraria, lo siguiente:
■ Los desarrollos deben considerar como un factor relevante la accesibilidad,

es decir que sea desarrollado pensando en las personas, para esto deben
aplicarse los instructivos de la SENADIS
(https://www.senadis.gob.cl/descarga/i/3676/documento).
■ Diseñar por defecto en “Mobile First” (responsivo) considerando

características UX para potenciar la usabilidad.
■ Debe incluir marcadores para analítica en las páginas que serán

disponibilizadas para el uso del ciudadano, esto es muy importante para
poder medir el uso real de las plataformas.
● Utilizar el Kit Digital para desarrollos web (https://kitdigital.gob.cl/).
● En caso de requerir de un BPM para la digitalización de trámites (tanto internos

como de cara al cliente), se debe privilegiar el uso de SIMPLE, herramienta BPM
disponible para todas las instituciones del Estado en forma gratuita. En caso de
requerir otro distinto de SIMPLE, se debe justificar claramente el motivo
(https://admin.simple.digital.gob.cl/).
● Debe indicar si el proyecto responde al «Plan de Digitalización» declarado en el

Registro Nacional de Trámites (https://tramites.gob.cl/).
● Debe indicar si el proyecto incorpora la obtención de transacciones asociadas al

uso del servicio, que debe informarse trimestralmente en el Registro Nacional de
Trámites (https://tramites.gob.cl/).
● Se deberán seguir los lineamientos que emanan de la Ley N°21.180 y de la División

de Gobierno Digital (DGD) del Ministerio Secretaría General de la Presidencia, con

14
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).
● Las Instituciones deben siempre evaluar el uso de las plataformas compartidas

como «ClaveÚnica», «Simple», «FirmaGob», «datos.gob.cl».
● 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.
● 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.

b. Oportunidad o problema no debidamente analizado.
c. La solución no resuelve el problema.
d. No muestra beneficios.
e. No hay resultados tempranos.
f. Productos mínimos viables, no uso de metodologías ágiles.
g. No tiene plan o calendario de hitos.
h. No diferencia debidamente inversión y/o costos recurrentes.
i. No cumplimiento de los criterios TIC.
j. Sus costos están sobreestimados.
k. Sus costos están subestimados.
l. No aplica la política Cloud First o Cloud Smart en que aplique.
m. No muestra equipo de proyecto.
n. No utilizar el formulario oficial completo («Formato de Proyecto Nuevo, Formato
de Proyecto de Arrastre o Proyecto de Continuidad operacional»).
o. Mala caracterización de los proyectos.

15
5.4. COMPLETAR FORMULARIO DE IDENTIFICACIÓN DE
PROYECTOS TIC
En este proceso de formulación de proyectos TIC 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.1. 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 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.2. Proyectos de continuidad operacional y renovación de licencias, en este tipo de

proyectos se deben identificar todos aquellos que impliquen renovación de equipo,
licencias, compra de insumos para la operación, aumento de parque en caso de que
corresponda, pagos de cuotas anuales de compras a más de 1 año en to referente a
infraestructura y licencias, climatización, redes, etc.
Toda mantención evolutiva, correcciones de problemas o fallas, agregar nuevas

funcionalidades o desarrollos necesarios para las plataformas de los servicios NO serán
considerados proyectos de continuidad operativa, por lo tanto, deben ser presentados
como proyectos nuevos, considerando las recomendaciones de compra de proyectos en
lugar de contratación de HH para desarrollos internos, esto es en virtud del dictamen de
Contraloría N° E173171 de enero del 2022.
5.4.3. Proyectos de Arrastre de años anteriores, corresponden a aquellos requerimientos

realizados en años anteriores que no corresponden a continuidad operacional ni
renovación de licencias y que fueron declarados con una duración mayor a 1 año y que
fueron aprobados en procesos anteriores, que aún estén ejecutándose y que cuenten con

16
código entregado por el sistema EvalTIC. 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.
Si un proyecto de arrastre supera el plazo para el cual fue definido deberá ser
reingresado como proyecto nuevo indicando las razones de la extensión del plazo del
proyecto original y además indicar en la descripción el código del proyecto original.
Todos los formularios se encuentran contenidos en el Anexo N°3 de esta guía, adicionalmente se
encontrarán disponibles en la plataforma dispuesta por DIPRES que 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. COMO 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

17
Proceso año presupuestario 2021, MINISTERIO DEL INTERIOR Y SEGURIDAD PÚBLICA,
SUBSECRETARÍA DE DESARROLLO REGIONAL Y ADMINISTRATIVO y corresponde al primer
proyecto presentado.
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. PLAZOS
Con intención de preparar el proceso de Formulación 2023, y monitorear el avance de las
instituciones se realizarán las siguientes actividades:
DIFUSIÓN Y CAPACITACIÓN
20-05 - Oficio del Director de Presupuestos donde se indica el inicio del proceso de formulación
presupuestaria, y solicitud de Evaluadores de proyectos.
FORMULACIÓN
25 de mayo / 08 de julio (preliminar) – (Preliminar) Comenzará en cuanto la plataforma quede

disponible y configurada, además de entregadas las credenciales a los Formuladores.
EVALUACIÓN E ITERACIÓN
01 de junio / 08 de julio (preliminar) - (Preliminar) Comenzará en cuanto se hayan subido las

primeras solicitudes y hayan sido asignadas a los Evaluadores.
CIERRE
09 de julio (preliminar) - (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.
ANÁLISIS Y SEGUIMIENTO
septiempre 2022/ marzo 2023 - 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.

18
7. CONTACTO E INFORMACIÓN
Para realizar consultas, resolver dudas, problemas e inquietudes, se habilitaron las casillas de
correo evaltic@dipres.gob.cl y evaltic@digital.gob.cl, las cuales serán respondidas a la brevedad
posible. las cuales serán respondidas a la brevedad posible.

19
8. 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.
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.

20
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.
● 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.

21
● 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 presentan 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, indicando que es un anteproyecto.
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».
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 subcontratación
estos servicios o efectuarán una Unión Temporal de Proveedores para así cumplir con los
requisitos de la adquisición.

22
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 (https://dipres.gob.cl) 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
Donde se le presentará una pantalla similar a esta:

23
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:

24
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.
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.

25
26
ANEXO N°3: FORMULARIOS OFICIALES «FORMATO PROYECTOS
TIC»
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: (separar en anteproyectos,

proyectos y mantenciones)
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 solo
haga referencia a ellos acá.
Identificación del Solicitante
Servicio
Ministerio
Nombre del Proyecto
Área Responsable
Jefe de Proyecto Nombre e-mail

27
Formulador Nombre e-mail
1. Resumen Ejecutivo (breve descripción del problema u oportunidad, descripción de la solución,

costos involucrados, plazo). Este resumen debe ser copiado en el campo «Objetivo General
Resumido» del formulario de la plataforma. Este resumen debe ser ejecutivo y apuntando a lo
netamente tecnológico del proyecto.
2. Justificación del proyecto
2.1. Problema u oportunidad de mejora detectada
A. Identificación clara del problema u oportunidad. En el caso de detectarse un

problema, se deben identificar además las causas de este. En la solución propuesta,
se debe indicar cómo ésta aborda la causa del problema.
2.2. Justificación de la propuesta de solución como la mejor alternativa
Todas las respuestas deben ser cortas y precisas, no es necesario hacer una
descripción profunda de cada uno de los puntos siguientes. Si necesita extenderse
hacerlo adjuntando los archivos que estime pertinentes 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 en el ámbito
tecnológico y no muy extensa.
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 asociados al
problema u oportunidad identificada. (ahorros, beneficios)
E. Pertinencia de la solución planteada (considerando la legalidad vigente,
oportunidad, capacidades instaladas de la institución, viabilidad política, etc.)
2.3. Sustentabilidad de la propuesta

28
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 que otros actores
externos a la institución apoyan este proyecto y como 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.
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, no incluir
caracterizaciones por el sólo hecho de hacerlo, 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 Norma2
Clave Única
Simple
Alineamiento estratégico
Lineamientos de Gobierno Digital FirmaGob
RNT
DatosGob
Interoperabilidad
Digitalización documentos
Archivística
Gestión Documental
Envío electrónico a Archivo
Nacional
Ciberseguridad
2
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)
29
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» o no, utilizará

Inteligencia Artificial, Machine learning, etc.
I.A.
Data Warehouse
Business Intelligence
Tecnologías emergentes
Blockchain
Georeferenciación
IoT
pública
Nube privada
híbrida
Housing Local
Housing externo
Data Center
Hosting
Storage
3.2. Objetivos
Los objetivos presentados en este documento deben ser resumidos y precisos, no son
necesarias las explicaciones profundas de cada uno de los puntos, para esto se recomienda
entregar documentos adicionales donde pueda extenderse en la explicación.
A. General.
B. Específicos (resultados esperados)
3.3. Plazos
Deben considerarse los hitos relevantes dentro del proyecto y a aquellos que se les hará
seguimiento y control.

30
A. Calendario de Hitos
B. Etapas, productos mínimos viables y plazos.
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 y cantidad, lo mismo para el hardware, se deben identificar claramente cuántos, de qué
modelo y/o tipo se requieren adquirir. Igualmente, para el caso de la contratación de HH deberá
proceder a la identificación de las HH que se requieren. 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.
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$, SI NO SE CUMPLE CON ESTO, EL PROYECTO SERÁ
RECHAZADO DE INMEDIATO. 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
Máquinas y equipos 0 0 0 0
Equipos informáticos 0 0 0 0 Sum
Traspasos
Programas Traspasos
0 0 0 0
informáticos
Costo de
Equipos informáticos 0 0 0 0
implementaci 29 Sum 29
ón (CAPEX) Programas
0 0 0 0
informáticos
Costos
Equipos informáticos 0 0 0 0
operacionales 22 Sum 22
(OPEX) Programas
0 0 0 0
informáticos
Sum año Total
Sum año 1 … Sum año N
Total (M$) 2 Proyecto
Tipo de costo Subtítulo Ítem Año N+1

Servicios Básicos 0
Costo Traspasos Mantenimiento y reparaciones 0
recurrente Servicios técnicos y profesionales 0
31
Servicios Básicos 0
22 Mantenimiento y reparaciones 0
Servicios técnicos y profesionales 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
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
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
A. Describa brevemente si existe algún riesgo relevante asociado 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.
1.1.

32
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», que debe ser utilizado en

aquellas iniciativas donde esté involucrada la continuidad operacional, mantención evolutiva,
renovación de equipamiento y/o licencias se deberá ser ingresado obligatoriamente a la
plataforma EvalTIC, el documento se describe a continuación. (NO SE ADMITIRÁ OTRO TIPO DE
FORMATO QUE PRESENTE EL SOLICITANTE, EL NO USARLO IMPLICARÁ QUE LA SOLICITUD
SERÁ RECHAZADA.)
Servicio
Ministerio
Tipo de Proyecto ___ Continuidad Operacional| ___ Renovación/Adquisición de Licencias | ___ Renovación o Adquisición de Equipamiento
Área Responsable
Marcar con una X en la opción que corresponde en el recuadro «Tipo de Proyecto»
1. Resumen Ejecutivo (breve descripción de los que necesita para su ejecución. Este resumen debe
ser copiado en el campo «Objetivo General Resumido» del formulario de la plataforma.
2. Justificación del proyecto

33
2.1. Problema, necesidad u oportunidad de mejora detectada
A. Identificación clara del problema, necesidad u oportunidad. En el caso de

detectarse un problema, se deben identificar además las causas de este. En la
solución propuesta, se debe indicar cómo ésta aborda la causa del problema.
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.
2.3. Sustentabilidad de la propuesta
A. Coordinaciones / complementariedades con otras iniciativas y/o instituciones en

caso de ser necesarias.
3. Proyecto
3.1. Caracterización
A. Se debe especificar las razones por las cuales está adquiriendo equipamiento,
licencias o solicitando HH
Obsolescencia
Aumento de Parque
Renovación licencias en uso actuales
Otros
Si especificó «Otros», debe identificar claramente a que corresponde.
3.2. Plazos
B. Etapas.

34

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.
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$, SI NO
SE CUMPLE CON ESTO, EL PROYECTO SERÁ RECHAZADO DE INMEDIATO. 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

Máquinas y equipos
Traspasos Equipos informáticos Sum Traspasos
Licencias
Máquinas y equipos
Costo de implementación
29 Equipos informáticos Sum 29
(CAPEX)
Licencias
Máquinas y equipos
Costos operacionales Equipos informáticos Sum 22
22
(OPEX) licencias
Servicios de HH
Total (M$) Total Proyecto


35
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.
4. Riesgos
A. Describa brevemente si existe algún riesgo relevante asociado al proyecto. Los riesgos
descritos deben estar asociados a la EJECUCIÓN del proyecto.
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, debe
presentarlo como 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

36
Nombre del Proyecto
Identificación ID proyecto original Año de avance

Proyecto Original
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 le
solicita 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
este es una iteración anual o continuación, describir el estado de avance logrado, problemas
encontrados y la etapa que se va a cubrir con esta iteración.
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» o no, utilizará
Inteligencia Artificial, Machine learning, etc.
2.2 Objetivos
A. General.
B. Específicos (resultados esperados)
2.3. Plazos
B. Etapas, productos mínimos viables y plazos.


37

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$, SI NO SE CUMPLE CON ESTO, EL
PROYECTO SERÁ RECHAZADO DE INMEDIATO. 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 actual Subtotales
o
Máquinas y equipos 0
Equipos informáticos 0
Traspasos Sum traspasos
Programas
0
informáticos
Costo de
Equipos informáticos 0
implementación 29 Sum 29
(CAPEX) Programas
0
informáticos
Costo operacionales Equipos informáticos 0
22 Sum 22
(OPEX) Programas
0
informáticos
Total (M$) Sum actual Total Proyecto
Costos pendientes del proyecto:
Subtítul
Tipo de costo Ítem Año + 1 … Año + N Subtotales
o
Máquinas y equipos 0 0 0
Equipos informáticos 0 0 0
Traspasos Sum Traspasos
Programas
0 0 0
informáticos
Costo de Máquinas y equipos 0 0 0
implementación 29 Sum 29
(CAPEX) Equipos informáticos 0 0 0

38
Programas
0 0 0
informáticos
Máquinas y equipos 0 0 0
Costos
Equipos informáticos 0 0 0
operacionales 22 Sum 22
(OPEX) Programas
0 0 0
informáticos
Sum año +
Total (M$)
Sum año + 1 … Total Proyecto
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,
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
A. Describa brevemente si existe algún riesgo relevante asociado al proyecto y problemas a

los que ya se haya encontrado a lo largo de los años anteriores del proyecto. Los riesgos
descritos deben estar asociados a la EJECUCIÓN del proyecto.

39

Guía EvalTIC - Formuladores Proceso 2023

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

Guía EvalTIC - Formuladores Proceso 2023

Cargado por

Copyright:

Formatos disponibles

GUÍA PARA LA

Versión 01 | Mayo 2022

EVALUACIÓN DE PROYECTOS TIC 4

OBJETIVOS OPERACIONALES DEL PROCESO DE EVALUACIÓN 5

ACTORES DEL PROCESO 6

ETAPAS/PROCESO DEL PROYECTO 7

¿CÓMO FORMULAR CORRECTAMENTE? 8

ANEXO N°1: PROCESO DE DESARROLLO DE SOFTWARE 20

ANEXO N°2: INTERFAZ DIPRES-EvalTIC 23

ANEXO N°3: FORMULARIOS OFICIALES «FORMATO PROYECTOS TIC» 27

Versión 01 | Mayo 2022

En este proceso en especial se pondrá mayor énfasis en la evaluación de proyectos preparatorios

Versión 01 | Mayo 2022

● Avance en la instalación de una cultura de formulación en el marco de este proceso en

○ 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.

Versión 01 | Mayo 2022

Dado el involucramiento de DIPRES, ChileCompra y DGD en conjunto con el crecimiento en la

2. EVALUACIÓN DE PROYECTOS TIC

2.2. OBJETIVOS ESPECÍFICOS

2.3. OBJETIVOS OPERACIONALES DEL PROCESO DE EVALUACIÓN

Versión 01 | Mayo 2022

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

Versión 01 | Mayo 2022

4. ETAPAS/PROCESO DEL PROYECTO

4.1. DIFUSIÓN Y CAPACITACIÓN

4.2. FORMULACIÓN DE PROYECTOS

4.3. EVALUACIÓN E ITERACIÓN

Versión 01 | Mayo 2022

4.5. DISCUSIÓN PRESUPUESTARIA

● Es un insumo a considerar en la decisión de asignación de recursos a la institución,

5. ¿CÓMO FORMULAR CORRECTAMENTE?

Adicionalmente, existe un conjunto de principios generales de formulación que deben ser

Versión 01 | Mayo 2022

Versión 01 | Mayo 2022

5.2. CUMPLIR CRITERIOS TIC/ESPECÍFICOS Y DE COMPRAS

Versión 01 | Mayo 2022

5.2.3. Compra/renovación de licencias. De igual manera a la compra de equipos, se debe

5.2.4. Compra/renovación de licencias de Infraestructura Servidores/Cloud. Para

5.2.5. Compra/renovación de Infraestructura de Data Centers. De no ser posible una

5.2.6. Compra/renovación de Infraestructura de Comunicaciones. Respecto de la telefonía

Versión 01 | Mayo 2022

5.2.8. Ejes de transformación digital. Se debe identificar si la iniciativa responde a alguno de

● Identidad Digital: La Identidad Digital de Chile, asegura la identificación digital de

● Procesos y procedimientos administrativos: Para preparar o implementar la Ley

Versión 01 | Mayo 2022

● Desarrollos de FrontEnd: Para trámites y servicios de cara al ciudadano, es

■ Los desarrollos deben considerar como un factor relevante la accesibilidad,

■ Diseñar por defecto en “Mobile First” (responsivo) considerando

■ Debe incluir marcadores para analítica en las páginas que serán

● Utilizar el Kit Digital para desarrollos web (https://kitdigital.gob.cl/).

● En caso de requerir de un BPM para la digitalización de trámites (tanto internos

● Debe indicar si el proyecto responde al «Plan de Digitalización» declarado en el

● Debe indicar si el proyecto incorpora la obtención de transacciones asociadas al

● Se deberán seguir los lineamientos que emanan de la Ley N°21.180 y de la División

Versión 01 | Mayo 2022

● Las Instituciones deben siempre evaluar el uso de las plataformas compartidas

● En el caso de desarrollos de servicios de Autoatención se debe implementar la

● Siempre debe optar por la compra de proyectos por sobre la contratación de HH

5.3. CAUSALES DE EVALUACIÓN NEGATIVA

a. No cumplimiento con los criterios de compra establecidos.

Versión 01 | Mayo 2022

5.4.2. Proyectos de continuidad operacional y renovación de licencias, en este tipo de