Análisis de Requisitos Técnicos: Procesos y Procedimientos PDF

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ális...

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. 2. 3. Realizar un análisis de uso para determinar la carga esperada en la implementación. Crear un conjunto de casos de uso que modelen la interacción típica del usuario con la implementación. 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. Análisis de requisitos técnicos: procesos y procedimientos 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. Análisis de requisitos técnicos: procesos y procedimientos 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 requisitos técnicos: procesos y procedimientos 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 requisitos técnicos: procesos y procedimientos Análisis de uso. En la siguiente tabla se enumeran los aspectos a considerar al realizar un análisis de uso. Análisis de requisitos técnicos: procesos y procedimientos Análisis de requisitos técnicos: procesos y procedimientos 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. Análisis de requisitos técnicos: procesos y procedimientos 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. Análisis de requisitos técnicos: procesos y procedimientos Requisitos del sistema. 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. Análisis de requisitos técnicos: procesos y procedimientos Requisitos del sistema. 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. Análisis de requisitos técnicos: procesos y procedimientos Requisitos del sistema. Cualidades del sistema que afectan la implementación. 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. Análisis de requisitos técnicos: procesos y procedimientos Requisitos del sistema. Cualidades del sistema que afectan la implementació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. Análisis de requisitos técnicos: procesos y procedimientos 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 a largo plazo 02 Planificación ERP a mediano plazo 03 Planificación ERP a corto plazo 04 Control de la Actividad de Producción Planificación ERP a largo, mediano o corto plazo 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 largo, mediano o corto plazo 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 largo, mediano o corto plazo 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. Planificación ERP a largo, mediano o corto plazo 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 costos ocultos de un sistema de gestión? ¿Cuáles son los costos de mantenimiento? ¿Cuál es el costo de un ERP? 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. ¿Cuál es el costo de un ERP? ¿Cuáles son los costos ocultos de un sistema de gestión? 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. ¿Cuál es el costo de un ERP? ¿Cuáles son los costos ocultos de un sistema de gestión? 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. ¿Cuál es el costo de un ERP? ¿Cuáles son los costos ocultos de un sistema de gestión? 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ál es el costo de un ERP? ¿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. ¿Cuál es el costo de un ERP? ¿Cuáles son los costos de mantenimiento? 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. ¿Cuál es el costo de un ERP? ¿Cuáles son los costos de mantenimiento? 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. ¿Cuál es el costo de un ERP? ¿Cuáles son los costos de mantenimiento? 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. ¿Cuál es el costo de un ERP? ¿Cuáles son los costos de mantenimiento? 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.