4 - ERP Analisis, Planificacion y Costo

Análisis de
requisitos técnicos:
procesos y
procedimientos
- Análisis de uso
- Casos de Uso
- Requisitos del sistema
- Sistemas tolerantes a fallos
Análisis de requisitos técnicos: procesos y procedimientos
Este tema describe algunos de los procesos y procedimientos que se producen durante el
análisis de requisitos técnicos, que comienza con los documentos de requerimientos
creados durante la fase de análisis de negocio.
Utilizando como base los requerimientos de negocio, se pueden seguir los siguientes pasos:
1. Realizar un análisis de uso para determinar la carga esperada en la implementación.

2. Crear un conjunto de casos de uso que modelen la interacción típica del usuario con la
implementación.
3. Crear un conjunto de requisitos de sistema que se derivan de los requerimientos de
negocio, de los casos de uso y del análisis de uso efectuado.
Los casos de uso son también los cimientos sobre los que se diseña la arquitectura lógica,
que, junto con los componentes del sistema, forman el escenario de despliegue. Más tarde,
este se transformará en una entrada para la fase de diseño de la implementación.
La siguiente imagen muestra la relación entre la fase de requisitos técnicos, el análisis de
negocio, el diseño lógico y las fases de diseño de la implementación.
La fase de análisis de negocio contiene entradas de requerimientos empresariales para la
fase de requisitos técnicos.
Estas entradas se aplican al análisis de uso, a los casos de uso y a los requisitos del sistema.
Los casos de uso proporcionan entradas a los requisitos del sistema y a la arquitectura lógica,
mientras que el análisis de uso brinda entradas a la arquitectura lógica, una vez en la fase de
diseño lógico. Cabe destacar que los requerimientos empresariales de la fase de análisis de
negocio también brindan información sobre lo que se le pedirá al sistema.
Los requisitos del sistema y la arquitectura lógica forman un escenario de

implementación.
Ahora bien, al igual que con el análisis de negocios, no existe una fórmula mágica para
evaluar requisitos técnicos que genere el análisis de uso, los casos de uso y los requisitos
del sistema.
Análisis de uso.
El análisis de uso implica identificar a los distintos usuarios de la implementación que se está
diseñando y determinar sus patrones de uso.
La información recopilada proporciona una idea de las condiciones de carga esperadas y se

utiliza posteriormente para determinar los requisitos de rendimiento y otros parámetros
del sistema. La información de análisis de uso también es útil cuando se asignan
ponderaciones a los casos de uso.
Siempre que sea posible, durante el análisis del uso, se debe entrevistar a los usuarios,
investigar los datos existentes sobre los patrones de utilización y recabar información
de los constructores y administradores de los sistemas anteriores.
Análisis de uso.
En la siguiente tabla se enumeran los aspectos a considerar al realizar un análisis de uso.
Casos de Uso.
Los casos de uso modelan la interacción típica del usuario con la implementación que se está
diseñando y describen el flujo completo de una operación desde la perspectiva de un usuario
final. Priorizar el diseño en torno a un conjunto completo de casos de uso asegura un enfoque
que se adapta a la evolución de la empresa en la entrega de la funcionalidad esperada.
Cada caso de uso puede incluir estimaciones cuantitativas sobre el comportamiento del
usuario que pueden ser utilizadas luego para determinar los requisitos del sistema con
respecto al rendimiento, la disponibilidad y otras cualidades del servicio.
Así, los casos de uso se convierten en el punto de partida para diseñar la arquitectura
lógica.
A menudo se asignan pesos relativos a los distintos casos de uso, con los que representan
las tareas de usuario más comunes como los de más alta ponderación. La ponderación de los
casos ayuda a determinar los requisitos del sistema.
Los casos de uso se pueden describir en dos niveles:

- Diagramas de casos de uso: representación gráfica de las relaciones entre actores y casos
de uso.
- Informes de casos de uso: descripciones de casos de uso individuales, incluyendo flujos
primarios y alternativos de eventos.
Requisitos del sistema.
Los requisitos del sistema describen la calidad de servicio que debe proporcionar un software
desplegado para cumplir con los requerimientos empresariales, a los que se llega mediante
el análisis del negocio. El análisis de requisitos técnicos exige una comprensión del dominio
empresarial, los objetivos empresariales y la tecnología del sistema subyacente.
Los siguientes conceptos muestran las cualidades del sistema que se usan a menudo para
especificar los requisitos.
Gestión de requerimientos de un ERP

La gestión de requerimientos establece lo que el sistema ERP debe hacer en cuanto a
procesos, consultas, reportes, alarmas, interfaces, restricciones de seguridad y otros
elementos que la organización necesite. Es por ello que, si no se identifican de manera
correcta, el software no proporcionará al usuario la funcionalidad esperada. Además, si no
se especifican de manera clara y completa, no se conocerá el alcance del sistema ni será
posible estimar la dimensión real del proyecto ERP.
Cualidades del sistema que afectan la implementación.
Disponibilidad
La disponibilidad es una forma de especificar el tiempo de actividad de un sistema
desplegado. Es decir que es una medida de la frecuencia con que los recursos y servicios son
accesibles para los usuarios finales, a menudo expresada como el tiempo de actividad de un
sistema.
Por lo general se mide como un porcentaje de tiempo en que el sistema es accesible a los
usuarios. El tiempo restante (tiempo de inactividad) puede deberse a fallos del hardware,
software, la red o diversos factores, como la pérdida de potencia, que hacen que esté
inactivo. En la mayoría de los casos, el tiempo programado para el servicio (mantenimiento y
actualizaciones) no se considera tiempo de inactividad.
La disponibilidad se mide normalmente por el número de “nueves” que puede lograr. Por
ejemplo, el 99% de disponibilidad es de dos nueves. La especificación de nueves adicionales
afecta de manera significativa la disponibilidad de la implementación.
La siguiente tabla muestra el resultado de agregar más nueves de disponibilidad a un sistema
que se ejecuta 24x7 durante todo el año, lo que supone un total de 8760 horas.
Capacidad latente
La capacidad latente se define como la capacidad de un sistema para manejar el uso de
carga de pico inusual sin recursos adicionales.
Desempeño
El desempeño se mide por el tiempo de respuesta y latencia con respecto a las condiciones
de carga del usuario.
Escalabilidad
La escalabilidad hace referencia a la posibilidad de añadir, con el paso del tiempo, capacidad
y usuarios a un sistema desplegado. Suele implicar la adición de recursos al sistema, pero no
debe requerir cambios en la arquitectura de implementación.
Seguridad
La seguridad se obtiene de una compleja combinación de factores que describen la integridad
de un sistema y sus usuarios. Incluye la autenticación y autorización de los usuarios, así
como el transporte inmune de la información.
Utilidad
La utilidad se refiere a la facilidad con que se puede administrar un sistema desplegado e
incluye tareas tales como monitoreo, reparación de problemas esporádicos y actualización
de componentes de hardware y software.
Interrelación
Las cualidades del sistema que afectan la implementación están estrechamente
interrelacionadas. Los requisitos de una cualidad del sistema pueden incidir en los requisitos y
el diseño de otra. Por ejemplo, niveles más altos de seguridad pueden afectar el rendimiento,
lo que a su vez comprometería la disponibilidad. Asimismo, la inclusión de servidores
adicionales para solucionar problemas de disponibilidad incrementaría los costos de
mantenimiento.
La comprensión de cómo las cualidades del sistema están interrelacionadas y de los

compromisos que se deben hacer es la clave para diseñar un sistema que satisfaga con éxito
los requisitos del negocio y respete sus limitaciones.
Sistemas tolerantes a fallos
Los requisitos de disponibilidad de cuatro o cinco nueves por lo general requieren un sistema
que sea tolerante a fallos, capaz de continuar con el servicio incluso durante un fallo de
hardware o software. Por lo general, la tolerancia a fallos se logra mediante la redundancia en
hardware (como CPUs, memorias y dispositivos de red) y en softwares que proporcionan
servicios clave. Cuando un componente de hardware o software no es respaldado por otros
redundantes, una falla resulta en la pérdida de servicio en el sistema.
Al diseñar un sistema tolerante a fallos, se debe identificar posibles puntos de fallo

individuales y eliminarlos.
Estos sistemas pueden ser costosos de implementar y mantener, por lo que debes asegurarte
de entender la naturaleza de los requerimientos de negocio con respecto a la
disponibilidad y considerar las estrategias y costos de las soluciones que cumplan con esos
requisitos.
01 Planificación ERP Planificación ERP a largo,
a largo plazo mediano o corto plazo
02 Planificación ERP
a mediano plazo
03 Planificación ERP
a corto plazo
Control de la Actividad de
04
Producción
Planificación ERP a largo, mediano o corto plazo
Existe la concepción errónea de que el ERP es un sistema de planificación de producción a
largo plazo y de que por eso las órdenes de trabajo (OTs) se emiten desactualizadas. Para
aclarar esto, es importante recurrir a las definiciones de APICS (The Association for
Operations Management), la organización líder en administración de la producción.
Planificación ERP a largo plazo.

Aunque la planificación estratégica puede ponerse en un nivel superior, resulta esencial
elaborar un “plan de negocios”, que refiere a aquellas variables que hacen a la capacidad
productiva y a la determinación de instalaciones (tamaño y ubicación), productos y procesos.
Planificación ERP a mediano plazo
Se trata de la construcción de un “plan de operaciones y ventas” acordado entre todos los
sectores de la empresa. Consiste en un proceso de negocios realizado a nivel agregado
o por familia de productos:
✓ Marketing aporta la inteligencia de mercado y la demanda proyectada.

✓ Ventas añade la demanda real.
✓ Producción informa la capacidad disponible.
✓ Finanzas agrega los requerimientos financieros.
✓ Recursos Humanos provee el talento humano.
¿Cómo juega el ERP para planificar a mediano plazo? Pues depende del tipo de ERP. Lo que
hace falta en este punto es un software con capacidad de análisis del tipo “qué pasa si” o
what if. Por ejemplo, si se venden “x” unidades de la familia tal de productos e “y” de la otra,
¿cuántas horas de máquina hacen falta, cuánta materia prima, personal, etc.?
Planificación ERP a corto plazo
Se trata del “programa maestro de producción”, que se obtiene gracias a la integración de
herramientas específicas que calculan cuántos ítems de cada tipo se producirá y cuándo con
el objetivo de cumplir con lo acordado con los clientes.
Esto último se encuentra, claro está, íntimamente ligado a la disponibilidad de los materiales,
lo que requiere una “planificación del requerimiento de materiales”. Para ello, debe
agregarse el listado de materiales necesarios para fabricar cada producto (por lo general
conocido como BOM o Bill of Materials) y los tiempos en que se consigue cada uno (lead
times). Esta es otra de las ventajas del ERP, además de su esencial relación con el manejo
de inventario.
Control de la Actividad de Producción
Finalmente, llegamos al último eslabón, que, como su nombre lo indica, no es una parte de la
planificación, sino de la ejecución. En efecto, es crítico para el sistema de gestión contar con
información actualizada para obtener un resultado exitoso.
A modo de conclusión, debemos recordar que es habitual que la parte más dificultosa de la
implementación de un ERP sea la planificación y el control de la producción, en
especial en las pymes. Hay un motivo ineludible, que es el hecho de que ese aspecto es el
más personal de cada empresa, pero hay otro que es perfectamente evitable: la falta de
comprensión por parte de ambos lados, implementadores y personal de planta, de lo que
significa planificar la producción.
¿Cuál es el costo de un ERP?
¿Cuáles son los ¿Cuáles son los

costos ocultos costos de
de un sistema de mantenimiento?
gestión?
Un ERP... ¿a qué se asemeja su compra? Mucho se ha escrito al respecto. Hay quienes
aseguran que se parece a la adquisición de una casa, otros a la de un coche. Incluso hay
quienes piensan que no se trata de una compra y que incorporar un ERP en la empresa es
comparable a un proyecto de ingeniería civil, como puede ser la construcción de una
planta industrial. Aunque esta comparación resulta relevante para entender mejor de qué se
trata un proyecto de implementación de ERP, en este punto nos centraremos en el costo del
ERP.
Cuando las empresas están por contratar un sistema ERP, suelen emplear una considerable
cantidad de tiempo en negociar el precio de la licencia, sin prestar atención a otros costos,
tales como mantenimiento, soporte, implementación, actualizaciones y el valor del tiempo de
las personas de la organización que estarán involucradas en el proyecto.
¿Cuáles son los costos ocultos de un sistema de gestión?

Con frecuencia las expectativas poco realistas de la empresa usuaria con respecto al costo
de un ERP es el primer error en el que se incurre al planear la implementación. Sin un
presupuesto sensato, es decir, cuando se subdimensiona el capital, se termina recortando la
partida de actividades que forman parte de los factores críticos del éxito y así se traza la ruta
hacia una finalización no feliz.
Según los datos que Evaluando ERP recoge en sus estudios, en América Latina, las
empresas prevén invertir de un 1,50 % a un 2 % de sus ingresos en proyectos de ERP
cuando comienzan el proceso de evaluación y selección. Sin embargo, la mayoría de las
veces la inversión real es mayor a la prevista.
Parte de esta brecha es consecuencia de la subdimensión del costo de un ERP. Las
estimaciones, con demasiada frecuencia, no incluyen los gastos ocultos asociados con las
implementaciones de un ERP, como los recursos internos, consultores externos,
actualizaciones de hardware y otros elementos necesarios para el éxito del proyecto.
Por lo general, la estimación del costo de un ERP que realizan las empresas usuarias es una
proporción de 1:1 entre las licencias de software y los costos de aplicación técnica.
Es decir, U$D 1 de inversión para la implementación por cada U$D 1 invertido en software.
No obstante, al concluir los proyectos, se observa que esta aproximación no es del todo
correcta. Basados en nuestra investigación, una relación más cercana estaría en el rango
de 1:3 o incluso 1:4. En otras palabras, cada dólar que se destina a licencias de software ERP
requiere una inversión de tres a cuatro dólares para la implementación total.
En lugar de hablar del costo del ERP, deberíamos pensar en el costo del proyecto, es decir
en la suma del software y las tareas de implementación, adaptación, capacitación, migración
de datos, etc.
Durante los pasados doce años, en Evaluando ERP hemos elaborado un observatorio de la
demanda, en otras palabras, un dispositivo para recopilar la información de las compañías
que tienen proyectos de software empresarial. De las 3500 empresas que contactamos, en el
80 % de los casos hablamos con las personas que estaban realizando la búsqueda de
software para la compañía y les consultamos sobre las razones por las que deseaban
cambiar de sistema o incorporar un software ERP, cuáles eran las áreas que más lo pedían,
qué gerencia de la organización tenía presupuestado el proyecto, cuál era el monto asignado
a la inversión, cuántos usuarios tendría el nuevo sistema, etc.
En conclusión, el costo de un proyecto ERP no debería superar el 2% de la facturación

de una empresa.
¿Cuáles son los costos de mantenimiento?
Cargo anual de licencias
Desde hace muchos años, se acepta que, para tener acceso a actualizaciones y nuevas
versiones de los productos, el cliente debe abonar un costo conocido como “Cargo anual de
soporte y mantenimiento” o “Fee de licencias”, que oscila entre el 15 % y el 30 % del precio
de lista del producto.
Es muy importante distinguir entre el precio del contrato y el precio de lista. El primero suele
ser menor que el segundo y surge de una negociación de precios entre comprador
y vendedor. En cambio, es muy poco probable que la empresa proveedora negocie el
concepto sobre el que se aplica el cargo anual de mantenimiento. En casi todos los
casos, el fee se calcula sobre el precio de lista.
La contraprestación para el cliente es muy amplia, aunque los servicios que incluye en su
mayoría son:
✓ actualizaciones o nuevas versiones del producto;
✓ extensión del período de garantía;
✓ seguro de reinstalación ante robos, catástrofes o problemas en los soportes
tecnológicos.
Cargo anual de licencias
Por lo general, la empresa vendedora exige el pago del cargo anual para ofrecer cualquier
otro servicio sobre la aplicación, dado que, si los clientes no actualizan el producto, a partir de
determinado momento, se le hace muy difícil al proveedor ofrecer soporte sobre una versión
vieja del software. Por eso es común observar en los contratos compromisos de soporte
durante una determinada cantidad de años (por ejemplo, dos o tres años de antigüedad) o
hasta una determinada versión (por ejemplo, N-3, siendo “N” la versión más reciente).
Garantía
Al igual que con cualquier producto (por ejemplo, automóviles o electrodomésticos), todos los
ERP incluyen un determinado período de garantía de una cantidad de meses.
Mantenimiento correctivo
El mantenimiento correctivo se relaciona con los problemas que surgen en la aplicación por
errores de uso (por ejemplo, carga equivocada de transacciones con efecto fiscal), problemas
de registro relacionados con la infraestructura (como dificultades en la grabación en la base
de datos o interrupción en la impresión de una factura) o bien simples consultas acerca de
cómo llevar a cabo ciertas operaciones con el sistema.
Mantenimiento evolutivo
El mantenimiento evolutivo se refiere a pequeños cambios en las reglas de negocio que una
organización suele requerir, como modificaciones en formatos de impresión, autorizantes de
transacciones, niveles o roles de seguridad.
En general, el mantenimiento evolutivo incluye una cantidad de horas estimadas cubiertas. De

esta forma el proveedor pueda prever la carga de trabajo que es capaz de afrontar
mensualmente. Sin embargo, se debe tener en cuenta que, a diferencia de los insumos de
producción, las horas/hombre no son acumulativas: se consumen o se pierden.
Mantenimiento de la infraestructura
Uno de los componentes fundamentales para el mantenimiento de la infraestructura es el
mantenimiento de la base de datos de la aplicación. Por lo general el proveedor de ERP no
realiza esta tarea a menos que lo incluya específicamente en el contrato.
Mantenimiento de la infraestructura
Es importante tener en cuenta que un motor de base de datos Oracle, Microsoft SQL, MySQL,
DB2 o Postgres, por citar los más populares, es un producto de software; por lo tanto,
requiere un mantenimiento que comprende tanto copias de respaldo (backup) como detalles
de datos de auditoría, revisión de mensajes de error, cuidado de balanceo de carga y otros.
Esta tarea suele encargarse a especialistas certificados y con dedicación exclusiva. Es decir
que se trata de personal altamente calificado y capacitado cuyo costo es mayor que el
de otros recursos.
Usos combinados
Algunos proveedores, sobre todo los más pequeños, tienen la exclusividad en todas las
tareas de mantenimiento de la aplicación. Otros, con frecuencia los más grandes, solo
mantienen exclusividad sobre el cobro del cargo anual y el soporte de última línea, mientras
que dejan a libre elección el manejo de, mantenimiento evolutivo, que por lo general es el que
mayor cantidad de horas requiere. Esto permite mejores opciones al momento de comprar los
productos o servicios asociados, ya que no existe una situación de monopolio.
Los cambios hacia nuevas versiones
Como se explicó antes, con el pago del cargo anual, el proveedor entrega una actualización o
una nueva versión del producto con cierta frecuencia, usualmente al menos una vez al año.
No obstante, la instalación de la versión actualizada no es una cuestión trivial y suele ser
necesario plantear un proyecto para su ejecución. De acuerdo con el tipo de producto y el
caso específico de implementación, la tarea puede ejecutarse en horas, semanas o meses.
En definitiva, esto se traduce en tiempo y dinero.
En el caso de implementaciones complejas, con mucho desarrollo hecho a medida, la tarea

se complica notablemente, pues hay que realizar las pruebas necesarias para validar la
compatibilidad de las personalizaciones (“customizaciones”) con la nueva versión.

4 - ERP Analisis, Planificacion y Costo

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

4 - ERP Analisis, Planificacion y Costo

Cargado por

Copyright:

Formatos disponibles

Análisis de

1. Realizar un análisis de uso para determinar la carga esperada en la implementación.

Los requisitos del sistema y la arquitectura lógica forman un escenario de

La información recopilada proporciona una idea de las condiciones de carga esperadas y se

Los casos de uso se pueden describir en dos niveles:

Gestión de requerimientos de un ERP

La comprensión de cómo las cualidades del sistema están interrelacionadas y de los

Al diseñar un sistema tolerante a fallos, se debe identificar posibles puntos de fallo

Planificación ERP a largo plazo.

✓ Marketing aporta la inteligencia de mercado y la demanda proyectada.

¿Cuáles son los ¿Cuáles son los

¿Cuáles son los costos ocultos de un sistema de gestión?

En conclusión, el costo de un proyecto ERP no debería superar el 2% de la facturación

En general, el mantenimiento evolutivo incluye una cantidad de horas estimadas cubiertas. De

En el caso de implementaciones complejas, con mucho desarrollo hecho a medida, la tarea

También podría gustarte