E Notificaciones en Uruguay IM0001-PDF-SPA

Caso: IM0001
Versión: 21/11/2020
Caso
e-Notificaciones
en Uruguay
ISSN 123-456-789
El año 2013 avanzaba y Juan Moreno, CEO de Kepler Ltda. (nombre comercial INTEGRADOC),
tenía mucho en qué pensar. Había obtenido la adjudicación para construir una solución de noti-
ficaciones y comunicaciones electrónicas de escala nacional de un proyecto de la Agencia de Go-
bierno Electrónico (AGESIC) del Uruguay. Pasada la euforia inicial, se daba cuenta de lo apretado
de los tiempos y lo mucho que estaba en juego. En los próximos días habría que tomar decisiones
claves. Mientras hacía su rutina de natación, les daba vueltas una y otra vez en su mente:
No tenemos margen de error. La meta comprometida por contrato para 2013 es com-
pletar cinco instalaciones exitosas en organismos de Uruguay.
Este proyecto es muy importante para nosotros, AGESIC y el gobierno; hay compromi-
sos asumidos con un organismo internacional. Para nosotros, a corto plazo representa
un ingreso relevante. A largo plazo representa la oportunidad de seguir creciendo en el
Uruguay, y generar un caso de referencia en Latinoamérica.
Es nuestra gran oportunidad de afianzar una plataforma de trabajo para varios años por
venir, con una visibilidad inédita para nuestro software en organismos públicos y en la
ciudadanía en general del Uruguay.
Este es mucho más que un proyecto grande y nos jugamos gran parte de nuestro futuro
en lo que resolvamos estos próximos días.
Este caso fue preparado por los profesores Pablo Sartor y Juan Moreno de IEEM Escuela de Negocios, Universidad de Montevi-
CRÉDITOS deo. Los casos de enseñanza se desarrollan únicamente como base para la discusión en clase y no pretenden servir de avales, fuentes de datos
AUTORIA primarios, o ejemplos de una administración buena o deficiente. Esta publicación fue editada por la Facultad de Administración de la Universi-
dad de los Andes y para pedir copias o solicitar permiso para reproducir materiales, póngase en contacto con coleccion.cladea@gmail.com.
Copyright © 2020 IEEM Escuela de Negocios, Universidad de Montevideo. Ninguna parte de esta publicación puede ser reproducida,
almacenada en sistemas de recuperación, que se utiliza en una hoja de cálculo, o transmitida en cualquier forma o por cualquier medio, elec-
trónico, mecánico, fotocopia, grabación, o de otra manera sin el permiso del propietario del copyright.
This document is authorized for use only in DEL SOLAR, EDUARDO's GESTIÓN DE OPERACIONES - 2022- 1 at Universidad de Lima from Oct 2022 to Apr 2023.
Caso: IM0001
ANTECEDENTES
En el año 2012, la AGESIC (véase Anexo 9, Extracto del sitio web de AGESIC) elaboró el pliego
para la adquisición de una solución completa de Notificaciones y comunicaciones electrónicas que
pudiera tener alcance nacional. Esta solución estaba alineada con la Agenda Digital del Uruguay
(2011-2015) aprobada por el Poder Ejecutivo en noviembre de 2011 (véase Anexo 8, Objetivo
08 de la Agenda Digital Uruguay 2011-2015), que contaba con la fuerza política gobernante de
mayoría parlamentaria en el periodo 2010-2015.
Esta solución debía permitirles a las entidades que la utilizaran notificar los actos administrativos
en cualquiera de los trámites y servicios que involucra a las entidades públicas notificadoras. Es
decir, que potencialmente todas las entidades públicas pudieran utilizar un sistema informáti-
co único, que proveyera un mecanismo común y 100 % electrónico para notificar y comunicarse
con otras entidades públicas, personas físicas y personas jurídicas. En la Figura 1 se resume el
funcionamiento solicitado de la solución.
Un ejemplo concreto: un conjunto de microempresas del sector calzado que quiere exportar sus
zapatos a otro país y aprovechar una exención fiscal disponible. Para ello, cada una presenta su
solicitud al Ministerio de Industria, y este la analiza. Una vez aprobada, el ministerio redacta una
“notificación” formal, en la que autoriza la exención fiscal para esa empresa. En lugar de que cada
representante de la microempresa deba ir personalmente al ministerio a darse por notificada y
firmarla (esto requeriía desplazamientos desde diferentes lugares del país), el nuevo sistema per-
mitiría enviar esta notificación formal, firmada electrónicamente, al domicilio electrónico de cada
microempresa. El mismo mecanismo se repetirá para cada exportación, para cada microempresa,
cada año. El sistema funcionará con otros ministerios o entidades de Gobierno que deban enviar
notificaciones y comunicaciones a personas físicas, jurídicas y entidades públicas, quienes ten-
drán un único domicilio electrónico donde recibirlas, independiente del emisor.
A finales de 2012, se había producido el acto de recepción y apertura de las seis ofertas para esa
licitación, y en febrero de 2013 se le adjudicó a Kepler Ltda. el proyecto. Una característica rele-
vante del llamado era que, además de proveer la solución, se debía implantar el proyecto en cin-
co organismos (véase Anexo 2, Extracto del pliego de condiciones). Luego seguiría la estrategia
de expansión gradual de la solución, que iría incorporando organismos adicionales cada año. Las
primeras entidades eran importantes, pues en ellas se ganaría experiencia y avanzaría en la curva
de aprendizaje para luego expandirse a las demás.
Demoras en la adjudicación dificultaban alcanzar la meta de cinco instalaciones en 2013, pero

esta era innegociable porque así estaba comprometida por AGESIC ante sus organismos de fi-
nanciación internacionales, que eliminarían futuros fondos si esta etapa no se cumplía a cabali-
dad. En el proyecto, a este compromiso se le llamaba “las metas”, y debían cumplirse sin excusas.
Por esto, era vital configurar un cronograma de ejecución de las implantaciones, que deberían
comenzar a tener el software listo y terminar antes de fin de 2013. Al lograr un funcionamiento
p. 2 razonable, la adopción por los destinatarios finales (receptores de las notificaciones) no era un
Caso: IM0001
problema para Kepler, en cuanto los organismos serían los responsables de promoverla (y una
vez puesta en marcha, los receptores tendrían la opción conveniente de adherir al nuevo sistema).
La implantación en cada organismo era un proyecto en sí mismo. Se requería una intensa gestión
del cambio organizacional, para lograr que las personas adoptaran la nueva forma de trabajo, y
se empoderaran de una herramienta electrónica que sustituyera el soporte papel con el que ha-
bían trabajado durante muchos años. Para ello, se conformaron equipos de implantación multi-
disciplinarios (véase Anexo 6, Estimación de esfuerzos por cada implantación), que realizaban
diferentes tareas necesarias para lograr una implantación exitosa, liderados por los expertos en
cambio organizacional que se sumaron al equipo de informáticos para este proyecto (descrito más
adelante). Conformar estos equipos era una parte del desafío en sí mismo, así como mantenerlos
unidos y cohesionados durante todo el proyecto. Y configurar un cronograma de ejecución de las
implantaciones, que deberían comenzar luego de tener el software listo y terminar antes de fin
del año 2013, era otro desafío. Con el equipo “aceitado”, se estimaba que una implantación po-
dría realizarse en un par de semanas.
La adjudicación preveía que los servicios asociados a la solución (garantía, soporte, actualiza-
ción) se extendieran durante varios años más, a efectos de acompañar la adopción paulatina de
la solución por los restantes organismos públicos.
Administradores
Destinatarios
Entidades
notificadoras
Notificaciones
Personas Personas
electrónicas físicas jurídicas
Entidades
públicas
Entidades
Funcionarios públicas
publicos
Sistemas Auditores Mesa

externos de ayuda
Figura 1. Esquema de funcionamiento de la solución
Fuente: Pliego de Condiciones LP 6/12, AGESIC
p. 3
Caso: IM0001
EL OFERENTE
Kepler Ltda. era una empresa de software uruguaya especializada en la gestión de procesos de ne-
gocios (Business Process Management: BPM), trámites y documentos electrónicos, con clientes
de mediano y gran porte en el sector privado y público. Las soluciones provistas por la empresa
típicamente integraban software “paquete”, servicios de consultoría especializada en automatiza-
ción de procesos de negocios, gestión del cambio organizacional para adoptar las nuevas herra-
mientas, desarrollo de software a medida cuando es necesario (por ejemplo, para integrar otros
sistemas informáticos), etc. En la mayoría de los casos, se trataba de proyectos de mediano y gran
porte. En el ámbito público, la empresa contaba con una amplia trayectoria en Latinoamérica
con organismos de gobierno en países como Uruguay, Chile, Panamá, Perú y otros. Casi el 50 %
de su facturación provenía de ventas al sector público.
El último producto de Kepler, llamado INTEGRADOC, se proponía como solución de base para
el proyecto de e-Notificaciones. En el sitio web de la empresa se definía este producto así:
INTEGRADOC es un producto de gestión documental, que permite modelar procesos de

negocios basados en documentos, automatizarlos y analizarlos para su mejora. Gestio-
na flujos de trabajo y trámites electrónicos, integrando documentos, personas y procesos,
para aumentar la eficiencia de su empresa (BPM: gestión de procesos de negocios). En
el ámbito público, INTEGRADOC es un instrumento fundamental de gobierno electró-
nico, incluyendo el domicilio electrónico para los ciudadanos.
El producto era reconocido a nivel nacional y había obtenido varios premios. Había sido insta-
lado en un gran número de organismos públicos para mejorar su propia operación. Pero, si bien
algunos de ellos eran de gran porte, las soluciones estaban acotadas a la operación específica de
cada entidad en particular; límite que, como ya se expuso, desaparecía en el marco del proyecto
de e-Notificaciones.
A partir de sus más de 10 años de experiencia trabajando con organismos públicos, Kepler conocía
muy bien su forma de trabajo y cómo relacionarse con los funcionarios a fin de que los proyectos
tuvieran éxito. Para tener aún más garantías en este proyecto, incorporó a una consultora con la
que tenía antecedentes, especializada en gestión del cambio organizacional, mitigando así el ries-
go relativo a los asuntos relacionados con eventuales resistencias al cambio en los organismos. A
esto también contribuía que AGESIC hubiera buscado cinco organismos cuyos jerarcas estuvie-
ran muy alineados con las metas del gobierno, y fortalecer así el factor “apoyo de la dirección”.
p. 4
Caso: IM0001
Gerente general
(Juan Moreno)
Gerente de proyecto
(Marcelo Sosa)
Gerente de desarrollo Gerente de implantación

Gerente de servicios
(Cristian Mastrantono) (Martín Fros)
Consultores de gestión Administración

Diseño y arte
del cambio y operaciones
Desarrolladores Capacitadores Soporte 1a. línea
QA y testing Comunicaciones Soporte 2a. línea
Figura 2. Organigrama del equipo de Kepler involucrado en el proyecto
A corto plazo, este proyecto tenía un impacto directo en la facturación y rentabilidad de la compa-
ñía. Si bien el proyecto tenía diferentes etapas, el importe anual representaba más del 15 % de la
facturación anual de Kepler. La empresa estaba saneada económicamente. Fallar en este proyecto
no la haría quebrar, pero supondría un golpe fuerte, y, sobre todo, cerraría puertas a un camino
de crecimiento muy prometedor. Además, el costo de oportunidad de perder un año completo
focalizado en un proyecto que luego no tuviera éxito le haría perder pie con sus competidores.
En este proyecto, el éxito era atractivo también a largo plazo. Ser el primer proyecto a escala na-
cional de la empresa y del producto implicaba:
≈ La necesidad, ineludible, de ejecutarlo con éxito. Constituiría una “vitrina” a nivel nacio-
nal irremplazable, fortalecería la relación con la AGESIC y sentaría bases para el trabajo
de los próximos años al expandirla a todo el país.
≈ Abrir una puerta de entrada en otros organismos, que luego de utilizar las notificaciones
electrónicas pudieran aplicarlas a otros procesos de negocios.
≈ Ser una referencia para otros gobiernos de Latinoamérica, muchos de los cuales conta-
ban con iniciativas de gobierno electrónico, a los que una solución de estas característi-
cas les sería de interés.
p. 5
Caso: IM0001
La contracara era el riesgo para Kepler, si la ejecución no tenía exito. En tal caso, naturalmente la
AGESIC quedaría en una incómoda posición ante los organismos internacionales, y eso amena-
zaría las posibilidades de Kepler de seguir creciendo en clientes del gobierno uruguayo. Además,
existía un riesgo financiero alto, dado que, como todo proyecto de largo aliento, Kepler debería
financiar un equipo especializado hasta producir entregables que le generaran ingresos (véase
Anexo 5).
LÍNEA DE TIEMPO
Los eventos, en resumen, se sucedieron así:
≈ 2010: AGESIC define como proyecto estratégico las e-Notificaciones y lo incluye en la

Agenda Digital del Uruguay 2011 – 2015.
≈ 2011: AGESIC incluye las e-Notificaciones como meta de gestión.
≈ 2012, octubre: AGESIC construye pliego y publica la licitación.
≈ 2012, diciembre: apertura de ofertas. Kepler Ltda. postula su herramienta INTEGRA-
DOC, y compite con otros oferentes nacionales e internacionales.
≈ 2013, febrero: se notifica la adjudicación a Kepler Ltda.
≈ 2013, marzo: comienza el proyecto.
EL PROCESO DE NOTIFICACIÓN Y EL DOMICILIO
ELECTRÓNICO
Cada notificación electrónica debe redactarse, revisarse y luego enviarse al destinatario, quien
puede leerla y finalmente confirmar su recepción. En cada una de estas etapas, trabajan perso-
nas diferentes sobre la notificación. Cada una hace una parte del trabajo, al cabo del cual se pasa
la notificación a la siguiente persona que debe trabajar con aquella.
La solución tenía dos grandes componentes:
≈ El proceso de notificación / comunicación.

≈ El domicilio electrónico donde el destinatario recibe el documento.
El primero de ellos correspondía a la entidad pública que generaba la notificación o comunica-

ción, y que lo haría según un determinado proceso de negocio asociado. En este, participaban
principalmente funcionarios de la entidad pública, y estos eran un número acotado y pequeño,
aun en los organismos más grandes. La Figura 3 resume esquemática y simplificadamente este
p. 6 proceso (véase Anexo 4, para el proceso detallado).
Caso: IM0001
El proceso de las notificaciones electrónicas era ideal para implementarse mediante una
solución de gestión de procesos de negocio (BPM; véase Anexo 11, La gestión de procesos de
negocios (BPM)) como INTEGRADOC. Una ventaja del uso de un software de BPM reside en el
modelado visual de los procesos: “Es como dibujar cajitas y flechas en el pizarrón, eso lo
podemos hacer nosotros mismos”.
Entidad notificadora
Creación Puesta a
Admisión Entrega
y envío disposición
Destinatario
Figura 3. Proceso de notificación
Fuente: Pliego de condiciones LP 6/12, AGESIC
El segundo concepto correspondía al de domicilio electrónico del destinatario. Naturalmente, de

estos domicilios podrían existir cientos de miles, potencialmente millones, correspondientes a
cada persona física, cada persona jurídica y cada entidad pública del país. El desafío tecnológico,
en este caso, se centraba en la robustez (es decir, que estuviera siempre disponible) y escalabili-
dad (es decir, que al agregarse más y más usuarios, el sistema los soportara sin que su funciona-
miento se degradara de forma relevante). Se consideraban tiempos aceptables de respuesta los
inferiores a 300 milisegundos (es decir, que ante una acción, el sistema demore menos de 0,3
segundos en devolver el resultado correspondiente). Para el primer año, considerando que sola-
mente se implantaría en cinco entidades públicas, se estimaba que el total de usuarios con domi-
cilio electrónico no sobrepasaría los 500.
Al respecto, se consultó al ingeniero Cristian Mastrantono, gerente de desarrollo de Kepler Ltda.

Era el responsable del equipo de ingenieros que desarrollaría la solución, así como de sus aspec-
tos técnicos y en particular de la arquitectura de la solución, es decir, de la forma en que se cons-
truiría y sus consecuencias en el futuro. Al respecto, el ingeniero explicaba:
Existen dos alternativas viables que el equipo técnico está evaluando en relación al do-
micilio electrónico:
≈ Utilizar un módulo ya desarrollado y acoplado al producto base. Estimamos en la fábri-

ca de software que realizar los ajustes y afinar el funcionamiento insumiría un mes de
p. 7 trabajo de un programador asignado a ello full time.
Caso: IM0001
≈ Desarrollar un módulo nuevo, que exclusivamente resuelva la operación del domicilio

electrónico, desacoplado del producto base. En este caso estimamos que realizar el desa-
rrollo e integrarlo al resto de la solución insumiría 960 horas, perfil programador senior.
Funcionalmente para el usuario, ambas alternativas son equivalentes. Pero la solución de des-
acoplar el domicilio electrónico tiene una ventaja adicional: la posibilidad de escalar con mayor
facilidad, dado que permite de una forma más elegante agregar más servidores, en lo que se co-
noce como una “granja de servidores”, a medida que es necesario atender a más usuarios, man-
teniendo los tiempos de respuesta del sistema controlados. Por el contrario, tiene el riesgo de
implicar un desarrollo de software desde cero, debiendo agendar tareas de análisis, diseño, pro-
gramación, testing e integración… Todas estas tareas deben finalizar antes de comenzar la primera
implantación del software, dado que el domicilio electrónico es parte fundamental de la solución.
El siguiente diálogo entre Mastrantono y el gerente financiero de Kepler, Abel Perezínczy, ilustra
las tensiones relacionadas con el problema de separar el domicilio electrónico del producto base:
≈ Mastrantono:
Desde el punto de vista de la ingeniería del software, la robustez del sistema y las posi-
bilidades de escalar en el futuro, la opción de separar es muy superior…
≈ Perezínczy:
Entiendo perfectamente, pero estamos hablando de un costo relevante, que en un caso

no estaría presente, y en el otro sí. Estamos hablando de que este importe reducirá di-
rectamente el resultado anual, dado que la facturación será la misma en cualquiera de
las dos opciones.
≈ Mastrantono:
Pero, justamente, el punto es que no se puede mirar solamente el aspecto financiero.

¿Cómo te imaginas que les diré a mis ingenieros que hagan una solución subóptima?
≈ Perezínczy:
Bueno, ese ya no es mi problema, pero si fuera yo, ni mencionaría que existe la opción
2… Además, está el tema del plazo, está muy ajustado. Introducir nuevos desarrollos
aumenta el riesgo y sabemos que luego de ello vienen pedidos de más presupuesto para
la ejecución.
p. 8
Caso: IM0001
≈ Mastrantono:
Si alguno del equipo se va, formar un nuevo ingeniero con la experiencia que tiene el
equipo actual es tanto o más caro y, definitivamente, llevará más tiempo.
EL MARCO LEGAL
Las notificaciones electrónicas requieren un marco legal que a la fecha no existía en el país, y en el
que trabajaba un equipo de asesores legales. Naturalmente, esta nueva redacción debería sortear
el proceso de aprobación hasta constituirse en normativa legal vigente, incluidos revisores jurídi-
cos y también políticos. Al no contar con la redacción definitiva de este decreto, no se conocían los
detalles específicos de cómo debería ser el procedimiento en el sistema. Más allá de los aspectos
tecnológicos, el decreto reglamentaría cómo el software debería funcionar; no tenerlo en cuenta
podría llevar a construir un software que no sirviera para nada al no atender lo reglamentado.
Por ejemplo, uno de los aspectos que el decreto determinaría era cuándo y cómo considerar como
notificado a un destinatario. ¿Al ponerle la notificación a disposición? ¿Al acceder (login) al siste-
ma? ¿Al efectivamente abrir la notificación en el sistema? Todas las alternativas tenían ventajas
y desventajas. Y además el mecanismo que se definiera debía ser coherente con las notificacio-
nes por escrito, que seguirían vigentes (por ejemplo, telegrama colacionado) y que convivirían
con las electrónicas. Naturalmente, el comportamiento del sistema debía reflejar estas definicio-
nes, por lo que debería implementarse, testearse y aprobarse antes de la primera implantación.
Si el decreto no era aprobado en 2013, Kepler estaría protegido por no tratarse de un incumpli-
miento propio. Esto era muy improbable por la importancia del proyecto, pero sí podría suceder
que el decreto se promulgara tarde, lo cual generaría complicaciones relevantes a Kepler y for-
zaría una implementación bajo presión. Se debía tomar una decisión sobre si esperar a su re-
dacción, o realizar ciertas asunciones que permitieran completar el desarrollo, con el riesgo de
que no cumplieran cabalmente con el decreto una vez aprobado, y hubiera que rediseñar algu-
nas partes del software.
LAS PARTICULARIDADES DEL PROCESO EN CADA
ORGANISMO
El proceso de notificación era común a todos los organismos, pues se basaba en el procedimiento
administrativo del país. En el Anexo 4 (Detalle del proceso Notificaciones electrónicas en for-
mato BPMN) se presenta el detalle del proceso en notación BPMN1, extraído del pliego de con-
diciones. Sin embargo, la experiencia marcaba que en cada organismo siempre habría detalles
1
BPMN significa Business Process Management Notation. Es una notación gráfica que, mediante diagramas, permite describir procesos de ne-
p. 9 gocios. BPMN es un estándar internacional de la OMG.
Caso: IM0001
que serían diferentes a los de otros. Por ejemplo, un proceso en el Ministerio de Industria desti-
nado a notificar a grandes empresas industriales puede ser bastante diferente de un proceso en
la Dirección General Impositiva para notificar a profesionales independientes. Sin contradecir
el proceso “genérico” de notificación, estos detalles podían motivar modificaciones para cada or-
ganismo, a efectos de atender sus particularidades. Había que decidir si proveer un proceso de
notificación genérico e igual para todos los organismos o si se permitiría incluir particularidades
a cada organismo.
El proyecto implicaba una cargada actividad conjunta con los funcionarios notificadores para que
estos adoptaran la nueva operación 100 % electrónica, lo cual remplazaría las notificaciones y
comunicaciones en papel a las que estaban habituados. Se preveía que durante estas actividades
los funcionarios plantearan y solicitaran pequeños ajustes al proceso de notificación, de modo
de ajustarlo a su forma de trabajo. Considerando que se contaba con una herramienta de BPM,
que permitía modelar los procesos (y no programarlos), sería posible técnicamente instrumentar
estos ajustes. Claro que eso implicaría no tener un proceso genérico para todos los organismos,
sino uno particular para cada organismo.
Juan reflexionaba así con su equipo:
La solución es una, común a todos. Y este aspecto es fundamental para que pueda ser re-
plicada en muchas entidades y lograr una rápida expansión a todo el país, sumando va-
rios organismos cada año. Una orden directa de la jerarquía facilitaría seguir esta línea.
Por otro lado, el apoyo de los usuarios es fundamental. Sin ellos, no hay proyecto exito-
so. Y sabemos bien que los usuarios pedirán cambios y ajustes para su operación parti-
cular. Ignorarlos drásticamente generará rechazo al nuevo sistema. Más aún contando
con una herramienta en la que se pueden “dibujar” procesos.
Para los primeros organismos, hay previstas aproximadamente 200 horas de analistas
de procesos, destinados a configurar el producto de forma adecuada, debiendo decidir
si usar esas horas en un plan de implantación genérico, afinado y altamente replicable,
o en su defecto atender las solicitudes de cada entidad…
¿UNA SEXTA IMPLANTACIÓN COMO COBERTURA?

El equipo sabía que la meta de cinco instalaciones era binaria: se cumplía o no se cumplía, sin
grises. Al construir la matriz de riesgos del proyecto, se habían identificado varios elementos que
podrían impedir la implantación en alguno de los organismos:
≈ Riesgos tecnológicos: por ejemplo, que la infraestructura disponible en el organismo no

p. 10 fuera suficiente o no estuviera actualizada como para ejecutar la solución, o que no to-
Caso: IM0001
dos los funcionarios involucrados tuvieran acceso a una firma electrónica, o que esta no
funcionara en sus computadores, etcétera.
≈ Que no se lograra el apoyo jerárquico necesario y que el organismo revisara la decisión
de avanzar con la implantación eventualmente deteniendo la implantación o directa-
mente abandonándola.
≈ Que no se lograra el apoyo de los usuarios, y que esto redundara en atrasos y mayores
esfuerzos de gestión de cambio, poniendo en riesgo la meta de finalizar en 2013.
≈ Que el organismo presentara necesidades particulares para el software, que no hubieran
sido contempladas en el pliego, ni en la oferta (es decir, en la estimación de esfuerzos,
plazos y precios), y que estas fueran ineludibles.
≈ Y el más importante: “etcétera”. Podría haber innumerables imprevistos, algunos de
ellos fuera del control de AGESIC, de Kepler y del organismo, que impidieran finalizar
con éxito la implantación en un organismo.
En este contexto, se analizaba la opción de incorporar una sexta implantación adicional a modo
de cobertura. Al respecto, Moreno tenía el siguiente diálogo con el ingeniero Marcelo Sosa, quien
desempeñaba el papel de gerente del proyecto de INTEGRADOC:
≈ Moreno:
Sé que es muy difícil lo que te voy a preguntar, pero con el equipo que contamos, y asu-
miendo que el marco legal se defina a tiempo, ¿cuál es la probabilidad de que un orga-
nismo finalice a tiempo?
≈ Sosa:
Nuestro equipo tiene experiencia, y el desarrollo del software es desafiante pero viable;
si me pedís un número, te diría que en cada uno tenemos un 95% de chances de termi-
nar a tiempo.
Claro está que esta sexta implantación no estaba cotizada por Kepler. Y el proyecto estaba pla-
nificado y ajustado para cinco implantaciones, con una dedicación comprometida full time del
equipo del proyecto.
Adicionalmente, el perfil de los profesionales del equipo de trabajo era altamente especializado,
y funcionar óptimamente trabajando juntos era un aspecto relevante. Esto hacía muy difícil in-
tegrar personas que no se conocieran previamente entre sí y hubieran demostrado ser eficaces
en proyectos altamente demandantes con un cronograma ajustado (véanse Anexo 6, Estima-
ción de esfuerzos por cada implantación, y Anexo 7, Esbozo del plan de ejecución incluido en
el pliego licitatorio).
p. 11
LA ÚLTIMA PILETA
Juan dio la última vuelta americana y se prestó a nadar los últimos 25 metros con velocidad. Ya en
la ducha, rememoraba la última charla con Marcelo Sosa, involucrado directo y altamente compro-
metido con el éxito del proyecto. En ese ámbito, Sosa le agregaba un condimento a la reflexión que
no debía pasar por alto:
El equipo está muy motivado con el nuevo proyecto y en particular con el desafío técnico
que plantea. En un sector sin desempleo, retener a los talentos en el equipo es un desafío
diario, y desarrollar una solución con tecnología de última generación es un punto positi-
vo. Pero con los plazos del proyecto no podemos permitirnos perder a ningún miembro del
equipo. Remplazarlo generaría una sobrecarga en el resto y un atraso en el desarrollo que
pondría en riesgo el éxito del proyecto.
p. 12
ANEXO 1. Cinco razones
principales por las que los
proyectos de BPM fracasan
Sección de El autor Peter Schooff en el libro Passport to Success in BPM”2 identifica cinco razones principales
Anexos por las que los proyectos de BPM fracasan:
1. Tratar a BPM como un proyecto, como algo externo a la operación diaria de la compañía.
BPM debe verse como una disciplina de mejora continua que nunca finaliza, y que se aco-
pla a la operativa diaria.
2. Comunicación pobre. Esto afecta cualquier actividad en la compañía, y las iniciativas de BPM
no son una excepción. Usualmente, las cosas se ponen realmente mal cuando falta apoyo
de los usuarios, de la dirección o no se encuentran los sponsors adecuados, o falta claridad
sobre los roles, responsabilidades y beneficios que se obtendrán de la iniciativa.
3. Tratar a BPM como un proyecto de IT. BPM no es una tecnología, es una disciplina de ne-
gocios, que puede estar soportada por tecnologías, pero con las que no es suficiente. Hay que
involucrar a IT; pero sobre todo al dueño de cada proceso en cada línea de negocios. Estos
últimos son los responsables finales del éxito de cada iniciativa.
4. Falta de compromiso. Las iniciativas de BPM pueden requerir recursos adicionales para te-
ner éxito. Es preciso contar con el compromiso a nivel ejecutivo, y que este genere el marco
de trabajo adecuado, y que además se traslade a los demás niveles de la compañía.
5. Mala arquitectura de negocio, con unidades que funcionan como silos independientes. La
real ganancia al modelar y automatizar procesos de negocios es integrar diferentes áreas
en un proceso único de principio a fin.
p. 13 2
Passport to Success in BPM (Edited by Layna Fischer. 2014, Future Strategies Inc.).
ANEXO 2. Extracto del pliego
de condiciones
Sección de Licitación Pública Nacional No. 6/2012 - AGESIC (Agencia para el Desarrollo del Gobierno de
Anexos Gestión Electrónica y la Sociedad de la Información y del Conocimiento)
PARTE I - ESPECIFICACIONES GENERALES
1. Antecedentes
La Agencia para el Desarrollo del Gobierno de Gestión Electrónica y la Sociedad de la Información

y del Conocimiento (en adelante, AGESIC) se propone la adquisición de un Sistema de Notificacio-
nes y Comunicaciones Electrónicas que permita la composición y envío de notificaciones fehacien-
tes y otras comunicaciones a los interesados en trámites administrativos realizados con el Estado.
Los objetivos buscados con este sistema están alineados con los objetivos propuestos por la Agenda
Digital del Uruguay 2011-2015, aprobada por Decreto del Poder Ejecutivo No. 405/011 de 23 de no-
viembre de 2011, en especial con los siguientes:
≈ Objetivo 7. Modernización de la gestión pública.

≈ Objetivo 8. Acceso electrónico a la Administración Pública como derecho ciudadano.
≈ Objetivo 9. Un Estado integrado.
En este marco, se buscan los objetivos generales de gestionar y facilitar el uso de herramientas de
tecnologías de la información, para permitir la optimización tanto de recursos como de costos, en
soluciones transversales y de interoperabilidad a nivel de Gobierno electrónico, así como simplifi-
car la relación de personas físicas y jurídicas con el Estado, mediante la recepción de notificaciones
y comunicaciones por nuevos canales de comunicación, aprovechando las oportunidades que brin-
dan las nuevas tecnologías.
2. Objeto del llamado
Contribuyendo al objetivo estratégico de modernizar y extender la disponibilidad y uso de trámites y

servicios, AGESIC se propone incorporar a la Plataforma de Gobierno Electrónico (PGE) una solución
de Notificaciones y Comunicaciones Electrónicas, que les permita a los organismos de la Adminis-
tración Pública notificar, comunicar e intercambiar información electrónicamente con toda perso-
na física, jurídica, organizaciones y organismos públicos, entre otros (en adelante, destinatarios).
Asimismo, como parte del llamado se deberá personalizar dicha solución e implantarse en dos (2)
pilotos de ejecución y en por lo menos tres (3) organismos adicionales.
La solución debe ser integrable con otros componentes de la Plataforma de Gobierno Electrónico y
p. 14 con otros sistemas de los diversos organismos a través de los mecanismos…
ANEXO 3. Análisis primario
realizado por el equipo técnico, según
datos estimados a partir de soluciones
con similar arquitectura integrada
(sin separar el domicilio electrónico)
Sección de
Anexos
Carga Tiempo respuesta
Usuarios Documentos
estimada (ms)
- - - 100,00
100,00 1.500,00 150.000,00

109,00
200,00 3.000,00 600.000,00

118,00
300,00 4.500,00 1.350.000,00

127,00
400,00 6.000,00 2.400.000,00

136,00
500,00 7.500,00 3.750.000,00

145,00
600,00 9.000,00 5.400.000,00

154,00
700,00 10.500,00 7.350.000,00

163,00
800,00 12.000,00 9.600.000,00

172,00
900,00 13.500,00 12.150.000,00

181,00
1.000,00 15.000,00 15.000.000,00

190,00
1.100,00 16.500,00 18.150.000,00

209,00
1.200,00 18.000,00 21.600.000,00

230,22
1.300,00 19.500,00 25.350.000,00

254,50
1.400,00 21.000,00 29.400.000,00

266,00
1.500,00 22.500,00 33.750.000,00

306,43
1.600,00 24.000,00 38.400.000,00

344,00
1.700,00 25.500,00 43.350.000,00

393,00
1.800,00 27.000,00 48.600.000,00

462,00
1.900,00 28.500,00 54.150.000,00

571,00
2.000,00 30.000,00 60.000.000,00

780,00
p. 15
p. 16
Sección de
Anexos
Proceso de notificaciones electrónicas
Creación y envío de notificación Admisión y puesta a disposición Entrega de notificación
Crear Enviar Enviar Recibir acuse de estado

notificación notificación notificación notificación
Acuse vencida
Entidad notificadora
Acuse puesta Plazo vencido Acuse leída Acuse notificada
Notificación
a disposición
Puesta a Entrega de Generar constancia

Admisión ¿Requiere acuse NO
disposición notificación de notificación
Recibir de recibo?
electrónicas
Notificaciones
solicitud
de lectura Recibir acuse
SÍ
notificación de recibo
Aviso Notificación Constancia de

notificación
Acceder a bandeja Leer Realizar acuse Recibir constancia

formato BPMN
ANEXO 4. Detalle del proceso
Notificaciones electrónicas en
Recibir aviso
de Entrada notificación de recibo de notificación
Destinatario
¿Requiere acuse
de recibo?
Fuente: Pliego LP6/2012 – AGESIC.
ANEXO 5. Remuneraciones
sector TI en Uruguay
Sección de Cifras en USD: la cotización en 2014 rondaba los 19 pesos uruguayos (UYP) por dólar
Anexos estadounidense (USD).
Medias
Categoría laboral
Mínima Media Máxima
Gerencias de 1er. nivel (funcionales o

4.267 4.787 5.859
de udds de negocios)
Líder/Coordinador/Gerente de
3.337 3.611 4.137
proyecto
Analista Sr (>5 años de experiencia) 1.998 2.454 2.798
Analista Jr 1.131 1.362 1.622
Administrador de base de datos 1.133 1.385 1.689
Programador Sr 2.743 3.222 3.744
Programador Jr 1.367 1.753 2.163
Testing 994 1.310 1.550
Ejecutivo comercial 1.745 2.140 2.768
Soporte (de redes y PC, Mainframe,

864 1.171 1.615
Unix)
Desarrollador/Diseñador web 716 897 1.168
Secretarias 709 822 962
Administrativos (contabilidad,
980 1.255 1.886
finanzas)
Fuente: Cámara Uruguaya de Tecnologías de la Información – (CUTI)
p. 17
ANEXO 6. Estimación
de esfuerzos por cada
implantación
Sección de Tarea Horas

Anexos
Personalización de la aplicación, instalación y configuración
Configuración básica del sistema para un organismo 120
Configuración de un tipo notificación en un organismo 80
Gestión del cambio organizacional
Diagnóstico del organismo 120
Ajuste Plan para el organismo 120
Ejecución en un organismo 300
Gestión de las comunicaciones
Ejecución del Plan de comunicaciones en un organismo perfil 1 o 2. 320
Capacitación
Ejecución del Plan de capacitación en un organismo perfil 1 o 2. 320
p. 18
p. 19
Sección de
Proveedor Mes Mes Mes Mes Mes Mes Mes Mes Mes MesAnexos
Renglón Item
Responsable 1 2 3 4 5 6 7 8 9 10
Inicio AGESIC y Proveedor

Instalación y configuración Proveedor
Administración, operación, soporte Proveedor
Aceptación RI AGESIC
Desarrollo de RNI Proveedor
R1 Aceptación RNI AGESIC
Pruebas performance y carga AGESIC
Mesa de ayuda Proveedor
Administración funcional Proveedor
Dos años de garantía Proveedor
Desarrollo y mantenimiento de aplicaciones Proveedor
Ajuste Modelo implantación Proveedor
Gestión del cambio - Piloto 1 Proveedor
Capacitación - Piloto 1 Proveedor
Comunicación - Piloto 1 Proveedor
Gestión del cambio - Piloto 2 Proveedor
R2 Capacitación - Piloto 2 Proveedor
Comunicación - Piloto 2 Proveedor
en el pliego licitatorio
ANEXO 7. Esbozo del
plan de ejecución incluido
Hito puesta en marcha - Piloto 1 AGESIC y Proveedor

Hito puesta en marcha - Piloto 2 AGESIC y Proveedor
Marcha blanca - Piloto 1 Proveedor
Marcha blanca - Piloto 2 Proveedor
Tres implantaciones Proveedor
R3
Marcha blanca Tres implantaciones adicionales Proveedor
Fuente: Pliego LP6/2012 – AGESIC.
ANEXO 8. Objetivo 08
de la Agenda Digital
Uruguay 2011-2015
Sección de
Anexos
Ilustración 9. Extraído de Agenda Digital Uruguay 2011-2015 (AGESIC)
p. 20
ANEXO 9. Extracto del
sitio web de AGESIC
Sección de
Anexos
Fuente: www.agesic.gub.uy; visitada en febrero de 2014
p. 21
ANEXO 10. Extracto de
Resolución número 009/2013
de AGESIC: Adjudicación
Sección de
Anexos
DIRECTOR EJECUTIVO
III) que procede atender a la recomendación de la Comisión Ase-

sora de Adjudicaciones y, en su mérito, adjudocar el presente llamado a la firma
mencionada, en los términos referidos.
IV) que la División Administración, Recursos Financieros y Mate-
riales de AGESIC ha expedido la constancia de afectación del crédito, de confor-
midad con lo dispuesto por el artículo 27 de la ley 17.243 de 29 de junio de 2000;
V) que se ha realizado el previo control de cumplimiento de lo es-
tablecido en el artículo 3 de la Ley Nº 18.244 de 27 de diciembre de 2007;
VI) que se cuenta con la intervención preventiva del Tribunal de
Cuentas ante la Presencia de la República, sin observaciones.
ATENTO: a lo esxpuesto, a lo establecido en el Texto Ordenado de Contabilidad

y Administración Financiera (TOCAF), aprobado por Decreto Nº 150/012 de 11
de mayo de 2012, a lo dispuesto en la Resolucón de Presidente de la República
Nº 747/009 en 03 de agosto de 2009, y demás normas concordantes aplicables;
EL DIRECTOR EJECUTIVO DE AGESIC
- en ejercicio de atribuciones delegadas -
RESUELVE:
1º Adjudicase la Licitación Pública Nº 06/2012 para la adquisición de Solución

de Notificaciones y Comunicaciones Electrónicas, a la firma Kepler Ltda., por
un monto de hasta $10.165.992 (pesos uruguayos diez millones ciento sesenta y
cinco mil novecientos noventa y dos con 00/100) IVA incluido y de hasta UDS
117.120 (dólares estadounidenses ciento diecisiete mil ciento veinte con 00/100)
IVA incluido, de acuerdo al siguiente detalle:
Ilustración 11. Extracto de Resolución de AGESIC adjudicando la licitación
p. 22
ANEXO 11. La gestión de
procesos de negocios (BPM)
Sección de Un proceso de negocio es una secuencia de actividades que se realizan en una organización, para
Anexos lograr alguno de sus objetivos. Por lo general, en un proceso de negocio trabajan varias personas,
y cada una hace una parte del todo necesario. Se suelen representar mediante modelos de proceso,
como el ilustrado en el Anexo 4, basado en el estándar BPML, que facilitan:
≈ Su comprensión y análisis por diferentes personas, que pueden o no conocer los detalles
operativos.
≈ Documentar y comunicar adecuadamente cómo funciona nuestro proceso, permitiendo in-
terpelar si es la lógica deseada o una diferente sería más eficaz y eficiente.
≈ Identificar cuellos de botella y oportunidades de mejora, a partir de la medición objetiva de
cómo está funcionando el proceso.
Una vez modelado el proceso, el siguiente paso es automatizarlo, con un sistema de gestión de pro-
cesos de negocios (Business Process Management System, simplemente BPMS, o Workflow Mana-
gement System). Es decir, instrumentar esa definición del proceso en un sistema informático que
nos permita que cada etapa del trabajo llegue a la persona que debe hacerlo de forma automática.
Continuando con el caso de las notificaciones, una vez que una de estas se redacta, revisa y envía, la
siguiente etapa en el proceso es que la notificación sea puesta a disposición del destinatario para que
la lea, y considerarlo notificado; sin que se la tengan que enviar manualmente en papel, o llamarlo
por teléfono para avisarle y que se traslade al organismo a “darse por notificado”.
El sistema de gestión de procesos de negocios (BPMS) “sabe” que luego de que aprueba y envía la
notificación, debe entregarla al destinatario, quien podrá accederla en su Bandeja de pendientes o
Bandeja de entrada. Este es el lugar donde el usuario va a buscar el trabajo que se le ha enviado
desde la etapa anterior del proceso. Y una vez que el usuario haga su trabajo, la instancia de proceso
sobre la que trabajará, seguirá el proceso definido e irá a la Bandeja de entrada del siguiente parti-
cipante del proceso.
Además de manejar las Bandejas de entradas, automatizar el proceso permite:
≈ Crear nuevas instancias de procesos por diferentes vías. En las notificaciones: crear nuevas
notificaciones manualmente (por un funcionario), crear nuevas notificaciones a partir de
otros sistemas (interconectados), etcétera.
≈ Para cada una de esas instancias, facilitar la colaboración de las personas que tiene que hacer
su trabajo en cada etapa, y también de aquellas que necesitan estar al tanto o solo consul-
tar en qué está determinada instancia de proceso. En el caso que nos ocupa, otros funcio-
narios podrían saber en qué estado está determinada notificación, si ya fue entregada, si ya
fue leída, etcétera.
p. 23
Sección de ≈ Controlar los plazos (deadlines) para que ninguna instancia se “duerma” en una etapa de-
Anexos terminada. Ejemplo: después de determinado tiempo de entregada la notificación al desti-
natario, este se considera notificado.
Naturalmente, todas las instancias de proceso (en este caso las notificaciones) se guardan en el sis-
tema, se registra su historia (quien la redactó, cuándo fue aprobada, etc.), y toda la documentación
relacionada (diferentes versiones de esta, constancias de entrega al destinatario, etc.). Por ende,
en un único sistema tendremos toda la información relevante de todas las notificaciones emitidas.
Luego de haber automatizado el proceso con un sistema de gestión de procesos de negocios, y utili-
zarlo un par de meses, surge la necesidad de medir los procesos e identificar:
≈ Cuántas instancias hay en cada etapa (es decir, cuántas notificaciones están en proceso de
ser emitidas, y cuántas en cada etapa).
≈ Definir alertas con tiempos máximos en cada etapa (¿cuánto puede detenerse una notifica-
ción en cada etapa hasta su entrega?)
≈ Saber, a ciencia cierta, cuánto trabajo tiene cada persona en su respectiva etapa (¿cuántas
notificaciones procesa cada funcionario por semana?)
Las herramientas de medición en un sistema de gestión de procesos de negocios permiten emitir

informes y reportes, que muestren las cantidades de instancias, los tiempos en cada etapa y la pro-
ductividad de cada persona en el proceso. A estas medidas se les denomina indicadores clavs de ren-
dimiento del proceso, o simplemente KPI (por su sigla en inglés). A partir de estos KPI, se pretende
tener un diagnóstico objetivo de cómo están funcionando los procesos, eliminando las subjetivida-
des y percepciones derivadas del trabajo manual sobre las instancias de procesos, basado en correos
electrónicos u hojas de cálculo.
La última etapa que propone la disciplina de BPM es optimizar los procesos de negocios. Es decir, in-
troducir las mejoras derivadas del análisis anterior para mejorar el proceso, y volver a iniciar el ciclo
de mejora continua, realizando los cambios en el modelo del proceso para así mejorar su eficiencia
y eficacia. Dependerá de la herramienta (el BPMS) y del equipo de trabajo, si estos ciclos se pueden
ejecutar de forma ágil y reiteradas veces (lo cual es el objetivo de toda mejora continua).
Los principales involucrados al establecer una gestión por procesos de una organización no tienen
por qué ser personas de Tecnologías de la información o Informática. De hecho, en la mayoría de las
iniciativas de BPM, quienes lideran suelen ser los gerentes generales, de operaciones, de adminis-
tración, de organización y métodos. Aunque, por supuesto, como toda implantación de tecnología,
el visto bueno y soporte de TI es fundamental para el éxito de la iniciativa.
p. 24

E Notificaciones en Uruguay IM0001-PDF-SPA

Cargado por

Información del documento

Título original

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

E Notificaciones en Uruguay IM0001-PDF-SPA

Cargado por

Copyright:

Formatos disponibles

Caso: IM0001

Demoras en la adjudicación dificultaban alcanzar la meta de cinco instalaciones en 2013, pero

Sistemas Auditores Mesa

Figura 1. Esquema de funcionamiento de la solución

Fuente: Pliego de Condiciones LP 6/12, AGESIC

INTEGRADOC es un producto de gestión documental, que permite modelar procesos de

Gerente de desarrollo Gerente de implantación

Consultores de gestión Administración

Desarrolladores Capacitadores Soporte 1a. línea

QA y testing Comunicaciones Soporte 2a. línea

Figura 2. Organigrama del equipo de Kepler involucrado en el proyecto

≈ 2010: AGESIC define como proyecto estratégico las e-Notificaciones y lo incluye en la

EL PROCESO DE NOTIFICACIÓN Y EL DOMICILIO

La solución tenía dos grandes componentes:

≈ El proceso de notificación / comunicación.

El primero de ellos correspondía a la entidad pública que generaba la notificación o comunica-

Figura 3. Proceso de notificación

Fuente: Pliego de condiciones LP 6/12, AGESIC

El segundo concepto correspondía al de domicilio electrónico del destinatario. Naturalmente, de

Al respecto, se consultó al ingeniero Cristian Mastrantono, gerente de desarrollo de Kepler Ltda.

≈ Utilizar un módulo ya desarrollado y acoplado al producto base. Estimamos en la fábri-

≈ Desarrollar un módulo nuevo, que exclusivamente resuelva la operación del domicilio

Entiendo perfectamente, pero estamos hablando de un costo relevante, que en un caso

Pero, justamente, el punto es que no se puede mirar solamente el aspecto financiero.

LAS PARTICULARIDADES DEL PROCESO EN CADA

Juan reflexionaba así con su equipo:

¿UNA SEXTA IMPLANTACIÓN COMO COBERTURA?

≈ Riesgos tecnológicos: por ejemplo, que la infraestructura disponible en el organismo no

PARTE I - ESPECIFICACIONES GENERALES

La Agencia para el Desarrollo del Gobierno de Gestión Electrónica y la Sociedad de la Información

≈ Objetivo 7. Modernización de la gestión pública.

2. Objeto del llamado

Contribuyendo al objetivo estratégico de modernizar y extender la disponibilidad y uso de trámites y

100,00 1.500,00 150.000,00

200,00 3.000,00 600.000,00

300,00 4.500,00 1.350.000,00

400,00 6.000,00 2.400.000,00

500,00 7.500,00 3.750.000,00

600,00 9.000,00 5.400.000,00

700,00 10.500,00 7.350.000,00

800,00 12.000,00 9.600.000,00

900,00 13.500,00 12.150.000,00

1.000,00 15.000,00 15.000.000,00

1.100,00 16.500,00 18.150.000,00

1.200,00 18.000,00 21.600.000,00

1.300,00 19.500,00 25.350.000,00

1.400,00 21.000,00 29.400.000,00

1.500,00 22.500,00 33.750.000,00

1.600,00 24.000,00 38.400.000,00

1.700,00 25.500,00 43.350.000,00

1.800,00 27.000,00 48.600.000,00

1.900,00 28.500,00 54.150.000,00

2.000,00 30.000,00 60.000.000,00

Creación y envío de notificación Admisión y puesta a disposición Entrega de notificación

Crear Enviar Enviar Recibir acuse de estado

Puesta a Entrega de Generar constancia

Aviso Notificación Constancia de

Acceder a bandeja Leer Realizar acuse Recibir constancia

Fuente: Pliego LP6/2012 – AGESIC.

Gerencias de 1er. nivel (funcionales o

Analista Sr (>5 años de experiencia) 1.998 2.454 2.798

Analista Jr 1.131 1.362 1.622

Administrador de base de datos 1.133 1.385 1.689