Diseño e implementación de is. Transferencia del sistema de información a operación comercial

Detalles Publicado: 14/07/2018 21:24 : se consideran las etapas básicas de la implementación de sistemas de información corporativos. Además, se realiza una descripción general de los documentos de diseño de cada una de las etapas, y también se demuestra la dependencia de los datos de una determinada fase de los documentos de las etapas posteriores.
Descargar PDF.
Palabras clave: Documentos del sistema ERP, documentar la implementación de sistemas de información corporativos, documentar sistemas de información, documentos en el sistema de información, documentación del proyecto sistemas ERP, documentación de trabajo IP, documentación técnica CEI, regulaciones sistema de información, documentos reglamentarios para el diseño de sistemas de información, documentos de implementación de software, documentos de implementación de sistemas de información, etapas y documentos de implementación de productos de software, operación de prueba de sistemas de información, GOST R 54869-2011, ANSI PMBoK.

Ciertamente, la más deprimente de todas las situaciones posibles es la incertidumbre. El desconocimiento de lo que sucederá a continuación en el tema que te preocupa tiene un efecto extremadamente negativo. El proceso de implementación de un sistema de información corporativo (en adelante SIC) no es una excepción. Digamos que acaba de unirse a un equipo de proyecto sin experiencia laboral ni conocimientos teóricos. Al completar tareas específicas, somos como "gatitos ciegos" esperando las emociones del mañana. Otro ejemplo no menos ilustrativo: un consultor resuelve una gama estrictamente limitada de tareas durante varios años, sin querer entender para qué procesos superiores son relevantes. En tales casos, no debería sorprendernos que de repente la tarea se haya completado "ayer". Para excluir lo anterior, es necesario comprender claramente la secuencia de etapas de implementación del CIS y los documentos elaborados en cada una de las etapas.

Meta y tareas

El propósito de este trabajo es considerar las etapas básicas de la implementación de los sistemas de información corporativos para asegurar un mejor proceso de implementación. Lograr este objetivo requiere resolver las siguientes tareas:

una revisión de la literatura sobre la implementación del CIS;
consideración de las etapas básicas de la implementación del CIS;
Análisis de los documentos del proyecto y sus dependencias de las etapas.

1. Descripción general de los enfoques para la implementación de sistemas de información corporativos.

Un sistema de información corporativo está representado por un conjunto de sistemas de información (en adelante SI) que definen un área temática determinada. Existen varios enfoques para la implementación de IS, que también son aplicables para la implementación de CIS (Fig. 1). Comencemos la revisión con el enfoque declarado por el estado. Estamos hablando de estándares de la industria, en particular, GOST R 54869-2011, así como internacional estándar iso 21500. Los documentos contienen una descripción de las etapas de la gestión del proyecto desde el proceso de inicialización hasta su finalización, independientemente del tipo de sistema que se implemente. Por tanto, es posible utilizar estos estándares para la implementación de sistemas técnicos, de información y corporativos. Código conocimientos profesionales sobre gestión de proyectos, presentado por ANSI PMI PMBoK, regula los procesos de planificación, ejecución, verificación e impacto desde la etapa de inicio hasta la finalización del proyecto. De manera similar a GOST R 54869-2011 e ISO 21500, se puede utilizar para gestionar la implementación. varios tipos sistemas.

Arroz. 1.

SAP, Accenture y Microsoft utilizan, respectivamente, las metodologías Accelerated SAP (en adelante, ASAP), Accenture Delivery Methods (en adelante, ADM), así como Microsoft Dynamics Sure Step (en adelante, MDSS), al implementar soluciones CIS empaquetadas. Los enfoques se centran exclusivamente en la implementación de proyectos de implementación de CIS. En los enfoques discutidos anteriormente, se utiliza principalmente un esquema en cascada para introducir CIS. Este esquema se caracteriza por una estricta dependencia temporal de la implementación de las etapas del proyecto. Trabaja para este escenario Sólo podrá ejecutarse si se han implementado todas las actividades de la fase anterior del proyecto. El nombre de las etapas varía de un enfoque a otro, sin embargo, el contenido del trabajo no cambia. Por lo tanto, es muy posible formar lista única tanto operaciones como documentos preparados. Resumamos el resultado del análisis de los enfoques para la implementación del CIS mediante una lista de etapas típicas de la implementación del proyecto (Fig. 2).

Arroz. 2.

2. Documentos de proyecto de las etapas típicas de implementación del proyecto.

En la sección anterior, se identificaron etapas típicas de la implementación de proyectos para la implementación de la CEI, incluyendo

preparación del proyecto;
diseño;
implementación;
preparación para la operación piloto (en adelante, OPE);
AIRE LIBRE;
transición a operación productiva (en adelante - PE)

y que son comunes a las metodologías y estándares ASAP, ADM, MDSS. Se permite la ausencia de una etapa de PEA, luego las fases 4 y 5 del proyecto proporcionarán preparación para la PE y la PE, respectivamente. Consideremos con más detalle los documentos de cada una de las etapas (Fig. 3).

Arroz. 3.

2.1. Etapa de preparación del proyecto.

La etapa inicial del proyecto de implementación del CIS es la preparación. En el contexto de esta fase, se formulan metas y objetivos, así como se preparan plantillas de documentos y un cronograma ampliado del proyecto. El documento principal de la etapa es el estatuto que define los objetivos del proyecto, además de contener el alcance funcional, organizativo, técnico y metodológico del proyecto. Además, el documento describe a los participantes en el proyecto y establece el procedimiento para coordinar la documentación del proyecto. Se está preparando un concepto de formación para el equipo del proyecto, incluida una propuesta de enfoque para la formación del equipo de implementación CIS del cliente. Aquí se forman las plantillas de documentos que se utilizan para preparar la documentación en las etapas posteriores del proyecto. El alcance del proyecto contenido en la carta es necesario para determinar el momento del proyecto. Estos últimos se reflejan en un plan ampliado del cronograma, que luego se perfecciona para cada fase. Por tanto, la carta es el documento dominante de la etapa de preparación.

2.2. Etapa de diseño

Una vez completada la preparación del proyecto, pasamos a la etapa de diseño del sistema. La calidad, interconexión y detalle de las soluciones diseñadas son el factor determinante para el éxito de la implementación del CIS. Los errores cometidos en la etapa de diseño son difíciles de eliminar. El inicio de la fase de diseño va acompañado de la preparación de materiales de formación y un plan de formación para el equipo del cliente. El concepto previamente formado de formación del equipo del proyecto contiene sólo el contenido superficial de estos documentos. Además, el equipo de proyecto del cliente, junto con los especialistas del contratista, participa en el estudio de los procesos comerciales del cliente. El resultado del análisis del proceso son los requisitos funcionales y técnicos del sistema que se está diseñando.

Los requisitos del cliente se comparan con una solución CIS estándar (análisis de ajuste) para identificar déficits funcionales (análisis GAP). Un déficit funcional requiere la finalización del sistema, para lo cual se están preparando especificaciones de desarrollo que contienen el planteamiento del problema y el vector de solución propuesto. Se está desarrollando el concepto de roles y poderes, que define la lista de roles de usuario y las reglas para su creación y asignación a los empleados. La funcionalidad CIS estándar, las especificaciones de desarrollo y el concepto de roles y autoridades son necesarios para tomar decisiones de diseño. Las soluciones de diseño contienen los procesos comerciales del cliente en los modelos "tal cual" y "tal como será", indicando mejoras del sistema y roles de los usuarios.

Las soluciones de diseño se crean sobre la base del análisis Fit / GAP de los requisitos funcionales y técnicos del cliente. La experiencia en proyectos muestra que las soluciones se forman con mayor frecuencia para el proceso comercial de cada cliente. Además, las soluciones para mantener datos maestros, estructura organizativa y migración se destacan por separado. La cuestión de la migración de datos históricos del sistema se considera por separado en el concepto correspondiente. El concepto incluye una descripción del enfoque de migración de datos, los mecanismos de migración utilizados según las decisiones de diseño y el plan de migración propuesto. En esta etapa también se crean conceptos para la capacitación del usuario final y la transición al uso del sistema. El concepto de formación de usuarios determina el orden y el calendario previsto de la formación, los materiales de formación necesarios, así como la lista de ejercicios a realizar.

El concepto de transición al uso del sistema describe el procedimiento para aplicar la nueva solución CIS y el funcionamiento del sistema anterior, establece una lista de pasos para permitir a los usuarios trabajar con la nueva solución y define un conjunto de operaciones manuales realizadas. por especialistas técnicos de la CEI. Todos los documentos creados en esta etapa están interconectados. Las soluciones de diseño se pueden atribuir a las más documentos importantes, ya que son la base para la implementación del sistema, capacitación de usuarios, migración de datos y transición a la aplicación de la solución CIS propuesta.

2.3. Fase de implementación

La implementación del sistema se realiza de acuerdo con los documentos elaborados en la etapa de diseño. Los errores de diseño conducen inevitablemente a un ajuste y refinamiento incorrectos del sistema, razón por la cual la fase de diseño es tan esencial. Siguiendo las decisiones de diseño, las especificaciones de desarrollo y el concepto de roles y poderes, se implementa el sistema, se preparan descripciones de las configuraciones realizadas, la implementación técnica de las especificaciones y la configuración de roles y poderes, respectivamente. Las operaciones no incluidas en la descripción de la configuración realizada requieren la entrada manual por parte de especialistas del CIS. Por lo tanto, se proporciona una descripción de dichas operaciones en las instrucciones para la transición al uso del sistema, cuya referencia está contenida en el concepto correspondiente.

Según el concepto de migración de datos, en esta etapa se prepararon e implementaron soluciones de diseño en la CEI. Aquí también se preparan instrucciones, incluida una descripción de los procedimientos para cargar y controlar datos, así como ejemplos de plantillas de carga. El sistema personalizado y modificado se utiliza para pruebas internas. Las pruebas las llevan a cabo especialistas del CIS basándose en escenarios de pruebas funcionales. Los escenarios contienen ejercicios que reflejan los procesos comerciales de las soluciones de diseño. El propósito de las pruebas funcionales es verificar la corrección del trabajo. programas individuales. Las pruebas de integración, a diferencia de las pruebas funcionales, le permiten considerar la exactitud de la interacción de los programas involucrados en un solo proceso comercial.

En las pruebas de integración participan tanto los especialistas CIS como los usuarios clave del cliente. Los errores de pruebas funcionales y de integración se registran en el registro de problemas para su posterior resolución de problemas. La cantidad de errores en el registro de problemas es indicativo del profundo conocimiento de los requisitos comerciales del cliente. Si el registro contiene también Número grande críticas, existe una alta probabilidad de que el proyecto sea suspendido (ya que los comentarios deben resolverse antes de la etapa OPE).

2.4. Etapa de preparación para la operación piloto.

La implementación del sistema está completa y el registro de problemas contiene una pequeña cantidad de comentarios. Los preparativos para el OP están en marcha. La tarea principal de esta etapa es la capacitación de los usuarios finales. Se están preparando instrucciones para los usuarios finales (en el contexto de procesos u operaciones comerciales). Además, a partir de ellos se forman escenarios de formación de usuarios, que se incluyen en el plan de formación final. El plan de aprendizaje previsto se creó anteriormente en el contexto del concepto de aprendizaje. La formación de usuarios se lleva a cabo en condiciones cercanas a las reales. Por tanto, es necesario preparar una lista de participantes y asignarles roles reales para completar los ejercicios de prueba. Las capacitaciones son una especie de prueba del sistema, actualizando así el registro de problemas.

Además, se analizan los comentarios recibidos durante la formación. La continuación del proyecto es posible si el registro de problemas contiene comentarios que no obstaculicen la implementación de la OPE. En este caso, se elabora una lista de usuarios que participan en la OPE y se asignan los roles necesarios. Se está elaborando un plan para la transición al uso del sistema en modo OPE, que incluye una lista de los pasos necesarios para garantizar el funcionamiento del CIS y los plazos para su implementación. Los pasos específicos del plan contienen enlaces a operaciones de las instrucciones para la transición al uso del sistema. El plan de migración de datos es similar al plan de transición al uso del sistema, sin embargo, contiene enlaces a instrucciones para la migración. El cliente proporciona el llenado y validación de datos en las plantillas de descarga. La etapa de preparación finaliza con la introducción de los usuarios en el sistema para la realización de la OPE, así como con la migración de datos maestros y variables.

2.5. Etapa de operación piloto

La producción piloto le permite probar el rendimiento del sistema en operaciones comerciales reales utilizando datos históricos del sistema anterior. La carga de datos variables en la etapa de preparación de la OPE se limita a un período. Por tanto, lo primero que hacen los usuarios en el sistema es comprobar la correcta carga de los saldos. A continuación, los empleados ingresan movimientos de materiales y transacciones de cuentas basándose en documentos primarios de un período determinado. Los comentarios de los usuarios cuando trabajan con el sistema se registran en el registro de problemas. La etapa OPE finaliza con el cierre del período en los módulos de logística, contabilidad y control.

2.6. Fase de transición de producción

La finalización exitosa de la etapa OPE nos permite hablar de la transición a PE. La condición principal para la transición es la ausencia de comentarios en el registro de problemas y la actualización de toda la documentación del proyecto en función de los resultados de la corrección de los comentarios. Al igual que en la etapa de preparación para la OPE, se están preparando listas de usuarios del sistema, planes para la transición a PE y migración de datos. Se están completando las plantillas de carga de datos. Una vez creados los usuarios en el CIS, habiendo completado todas las operaciones del plan de transición y la migración de datos, se comienza a trabajar en el modo PE. A partir de este momento, los comentarios y problemas que surjan son resueltos por el equipo de atención al cliente. En las etapas de implementación, preparación para la OPE y OPE, los errores del sistema se registraron en el registro de problemas y los especialistas del contratista los corrigieron.

3. Dependencia de los documentos elaborados de las etapas del proyecto.

Los documentos de diseño son aprobados por el cliente en la etapa de diseño. En el futuro, durante las fases de implementación, preparación para la OPE y OPE, los comentarios del cliente sobre el prototipo implementado del sistema se reflejan en el registro de problemas. La corrección de las observaciones del registro de problemas consiste en actualizar y reaprobar los documentos, así como reconfigurar y demostrar el sistema al cliente. La siguiente figura muestra el flujo de documentos para los procesos de diseño, capacitación, transición del sistema y migración de datos (Figura 4). Supongamos que, según los resultados de la capacitación, se reveló que uno de los escenarios de capacitación contradice los requisitos. ¿Cuáles son las consecuencias?

Arroz. 4.

En primer lugar, casi todos los documentos están sujetos a cambios, desde las decisiones de diseño hasta los escenarios de capacitación del usuario final. En segundo lugar, es necesario corregir tanto los documentos sobre la transición al uso del CIS como la migración de datos. Finalmente, en tercer lugar, volver a ejecutar la capacitación de los usuarios finales. Costos laborales tan importantes surgen debido al hecho de que, por un lado, los procesos de diseño, capacitación, transición al uso del sistema y migración están rígidamente interconectados, por otro lado, cuanto más tarde se formulan comentarios, más difícil y caro es eliminarlos. Es por eso que la calidad de las soluciones de diseño determina el éxito de la implementación del CIS.

Resultados y conclusiones

Los principales resultados del trabajo son la consideración de metodologías para la implementación del CIS, la identificación de etapas típicas de implementación del sistema, así como la revisión de la documentación del proyecto y la dependencia de los documentos de las fases del proyecto. Un análisis de las metodologías de implementación de SI permitió destacar las fases de preparación, diseño, implementación, preparación para la OPE, OPE y transición a PE del proyecto, que son típicas independientemente del estándar o metodología de gestión de proyectos elegidos. La descripción de la documentación de diseño se realiza para cada etapa típica de la implementación de CIS y se presenta claramente en forma de diagrama de cascada (Fig. 3). Dado Breve descripción documentos y el procedimiento para su preparación. La atención se centra principalmente en el propósito de los documentos, no en su contenido.

Se muestra la dependencia de los documentos de las fases del proyecto. Se ilustra que un cambio menor en un documento requiere actualizar los documentos utilizados para preparar el original (Fig. 4). Esto aumenta enormemente la complejidad del trabajo. Una descripción detallada de los trabajos típicos en cada fase del proyecto, el análisis de la documentación del proyecto y la identificación de los principales requisitos para el contenido de los documentos determinan de manera similar la dirección prometedora para futuras investigaciones.

Literatura

GOST R 54869-2011. Gestión de proyectos. Requisitos de gestión de proyectos. - M.: Standartinform, 2011. - 10 p.
Zandhuis A., Stellingwerf R. ISO 21500. Orientación sobre gestión de proyectos. Una guía de bolsillo. - Países Bajos: Van Haren Publishing, 2013. - 148 p.
ANSI/PMI 99-001-2014. Una guía para los conocimientos sobre gestión de proyectos (Guía PMBOK). – Pensilvania: Instituto de Gestión de Proyectos, 2013 – 589 p.
Marca H. Implementación de SAP R/3 con ASAP: la guía oficial de SAP. - Nueva Jersey: Sybex Inc., 1999. - 591 p.
Kress R. Administrar TI como una empresa: una guía paso a paso para la TI interna de Accenture - Ely: IT Governance Publishing, 2012. - 140 p.
Shankar C., Bellefroid V. Microsoft Dynamics Sure Step 2010. - Birmingham: Packt Publishing, 2011. - 360 p.
Diseño de sistemas de información: tutorial/ Gvozdeva T.V., Ballod B.A. - Rostov n / D.: Phoenix, 2009. - 508 p.
Kovalev S., Kovalev V. Secretos negocios exitosos: procesos de negocio y estructura organizativa. – M.: BITEK, 2012. – 498 p.
Stepanov D.Yu. Descripción general de los procesos comerciales de logística en el ejemplo de la actividad de adquisiciones de una empresa // La logística hoy. - 2014. - v.65, núm. 5. – c.208-228.
Stepanov D.Yu. Formación de requisitos universales para programas de usuario al preparar una especificación para el desarrollo ABAP // Problemas reales de la ciencia moderna. - 2014. - v.78, núm. 4. – c.258-268.

Implementación

Es difícil dar consejos sobre la implementación del código del módulo, ya que cada desarrollador tiene algunos hábitos y su propio estilo de desarrollo de código. Al implementar un proyecto, es importante coordinar el grupo(s) de desarrolladores. Todos los desarrolladores deben cumplir con estrictas reglas de control de pruebas de código fuente. El equipo de desarrollo, una vez recibido el borrador técnico, comienza a escribir el código de los módulos, en cuyo caso la tarea principal es comprender la especificación. El diseñador especifica lo que se debe hacer y el desarrollador determina cómo hacerlo.

En la etapa de desarrollo, existe una estrecha interacción entre diseñadores, desarrolladores y grupos de evaluadores. En el caso de un desarrollo intensivo, el evaluador está literalmente "vinculado" al desarrollador, siendo en realidad un miembro del equipo de desarrollo.

El diseñador en esta etapa actúa como un “libro de referencia ambulante”, ya que constantemente responde a las preguntas de los desarrolladores sobre las especificaciones técnicas.

Muy a menudo, las interfaces de usuario cambian durante la fase de desarrollo. Esto también se debe al hecho de que los módulos se muestran periódicamente al cliente. Las solicitudes de datos también pueden cambiar significativamente.

Cabe señalar que para el montaje de todo el proyecto debe existir un lugar de trabajo exclusivo. Estos módulos se envían para su prueba. La interacción entre un tester y un desarrollador sin una transferencia centralizada de partes del proyecto es aceptable, pero solo si es necesario verificar urgentemente algún tipo de edición. Muy a menudo, la fase de desarrollo y la fase de prueba están interconectadas y se ejecutan en paralelo. El sistema de seguimiento de errores sincroniza las acciones de los evaluadores y desarrolladores.

Durante el desarrollo, se deben organizar repositorios constantemente actualizados de módulos de proyecto listos para usar y bibliotecas que se utilizan al ensamblar módulos. Es deseable que el proceso de actualización de los almacenes esté controlado por una sola persona. Uno de los repositorios debe ser para módulos que pasaron las pruebas funcionales y el otro para módulos que pasaron las pruebas de enlace. El primero son los borradores. El segundo es algo a partir del cual ya es posible ensamblar el kit de distribución del sistema y demostrarlo al cliente para realizar pruebas de control o pasar cualquier etapa del trabajo.

La documentación se crea durante todo el proceso de desarrollo. Una vez que un módulo ha pasado la prueba de enlace, se puede documentar. Si los módulos cambian con frecuencia, la descripción sólo se inicia cuando el módulo se vuelve más o menos estable.

Procesamiento de resultados de diseño.

En la etapa de desarrollo, por regla general, se vuelve a comprobar la atomicidad de las funciones, así como la ausencia de duplicaciones.

Es deseable que la matriz "función-entidad" ya se haya construido en la etapa de diseño. En realidad, esta es una representación formalizada de lo que la empresa está tratando de hacer (funciones) y qué información debe procesarse para lograr el resultado (esencia). Dicha matriz le permite verificar los siguientes puntos:

si cada entidad tiene un constructor: una función que crea instancias de la entidad (crear);
si hay referencias a esta entidad, es decir, si esta entidad se utiliza en algún lugar (referencias);
si hay cambios en esta entidad (actualización);
si cada entidad tiene un destructor: una función que elimina instancias de entidad (eliminar).

A menudo, el papel del destructor lo desempeña un conjunto de programas de archivo de datos. A menudo, en los sistemas de información, la información simplemente se acumula. Esto solo está permitido si, durante todo el período de acumulación de información (y de hecho, durante toda la vida útil del sistema de información), sus características de desempeño cumplen con los requisitos del cliente. En la práctica, esto es algo extremadamente raro. Esto se debe principalmente al crecimiento de los volúmenes de información procesados. Cabe señalar que en este caso no se puede confiar únicamente en la potencia del DBMS o del hardware, ya que métodos tan extensos para mejorar el rendimiento dan un aumento de velocidad estimado bajo. De hecho, la tarea de prueba más probable es que el sistema o sus partes individuales respondan al crecimiento en el volumen de datos procesados. En este caso, el grupo de prueba crea un módulo para generar datos (incluso abstractos), selecciona un conjunto de consultas para las cuales las características de velocidad son críticas, luego se toman medidas y se determina la dependencia de la velocidad de ejecución de la cantidad de datos para cada uno de los Se trazan las consultas. Una acción tan sencilla evitará errores graves en el diseño e implementación del sistema de información.

La especificación de los módulos debe realizarse en la etapa de diseño, lo que a menudo simplemente se ignora en proyectos reales. Y en vano: debido a una implementación mal concebida de los módulos, se pueden perder todas las ventajas del esquema de la base de datos. Entonces, al descuidar las especificaciones de los módulos, se corre el riesgo de introducir en el sistema de información:

crecimiento descontrolado de los volúmenes de datos;
Solicitar subprocesos con una probabilidad inherentemente alta de conflicto, o solicitar subprocesos que se ejecutarán "para siempre" (intentar ejecutar un subproceso, detectar un conflicto y revertir todas las acciones, volver a intentarlo, etc.) debido a subprocesos en conflicto;
sistemas de mezcla y módulos de interfaz;
duplicación de módulos;
errores en la ubicación de la lógica empresarial;
falta de implementación o implementación incompleta de las funciones del sistema requeridas por el cliente.

Esta no es una lista completa de los problemas que se descubrirán en la etapa de pruebas complejas, o al poner el sistema en funcionamiento, y tal vez incluso durante el funcionamiento del sistema (cuando los módulos realmente comiencen a usarse).

Además, la ausencia de especificaciones de los módulos no permitirá evaluar con precisión la complejidad de cada módulo y, como resultado, determinar la secuencia de creación de módulos y distribuir correctamente la carga de trabajo del personal. La situación habitual en tal caso es “alguien está esperando a alguien”, mientras el proceso de creación de un sistema de información se detiene.

Módulos del sistema

Muchas veces es necesario considerar un gran número de procesos de servicio o soporte que no están directamente relacionados con la función comercial formulada. Por regla general, se trata de funciones del sistema disponibles en cualquier sistema de información, como por ejemplo:

administrador de colas o programador de tareas;
administrador de impresión;
medios para acceder a datos y crear consultas ad hoc (a menudo son generadores de informes);
gestión de directorios y otros recursos del sistema de archivos;
copia de seguridad automática;
recuperación automática después de una falla del sistema;
medios para regular el acceso de los usuarios al sistema (que consisten en un medio para crear usuarios y un medio para asignarles privilegios);
medios para establecer el entorno para el usuario del sistema de información;
un medio para cambiar la configuración del usuario (incluida la contraseña);
herramienta de gestión de aplicaciones;
Entorno del administrador del sistema de información.

Algunas de estas funciones deben ser realizadas por el sistema operativo, pero si funcionará en un entorno heterogéneo, entonces no hay garantía de que a los usuarios les guste la presencia de diferentes interfaces en diferentes sistemas operativos. Idealmente, todas las aplicaciones cliente deberían ejecutarse en el mismo sistema operativo, pero en la práctica, los desarrolladores a menudo tienen que lidiar con todo un "zoológico" de diferentes estaciones de trabajo en la casa del cliente, resultado de varios intentos de automatizar el negocio. El objetivo del desarrollador es llevar el sistema al estado más homogéneo, o al menos hacer que las estaciones de trabajo del usuario final sean similares.

La tarea de crear un sistema de información en un entorno heterogéneo aumenta significativamente los requisitos para los desarrolladores de código y para la herramienta de desarrollo elegida. Esto es especialmente cierto para el desarrollo de módulos del sistema. Se debe prestar atención a los módulos cuya implementación de código depende de Sistema operativo. Dichos módulos deben asignarse por separado para cada uno de los sistemas operativos en grupos, por ejemplo, Win98, WinNT, etc. Los módulos de cada grupo deben tener interfaces de intercambio estrictas: los datos que transmiten y reciben están estrictamente definidos, cualquier desviación de las especificaciones es punible. Ninguno de los módulos fuera de este grupo puede utilizar otras llamadas que no sean interfaces de intercambio. De esta manera, los módulos dependientes del sistema operativo quedan aislados de otros módulos.

En términos generales, la práctica de aislar los módulos del sistema mediante una regulación estricta de sus interfaces de intercambio minimiza significativamente el costo de la corrección de errores y el soporte del sistema. Además, también facilita las pruebas, es decir, la detección y depuración de errores. La otra cara de la cuestión es que los requisitos para el código de la interfaz para el intercambio de módulos del sistema están aumentando considerablemente. Esto es lo que se depuró en primer lugar y debería funcionar con mucha claridad.

Herramientas de monitoreo del sistema de información.

Si el sistema de información es grande, entonces se debe considerar la tarea de administrarlo desde una estación de trabajo. Es necesario cuidar no sólo del usuario final del sistema de información, sino también del personal que lo atenderá. Se debe prestar especial atención al monitoreo de áreas críticas del sistema de información, ya que a menudo es más fácil prevenir una falla que corregir sus consecuencias. El seguimiento se refiere a aquellas tareas cuya necesidad de resolver el cliente, por regla general, no piensa y que suelen estar ausentes tanto en el estudio analítico como incluso en el diseño. La necesidad de herramientas de monitoreo se hace evidente sólo en la etapa de puesta en funcionamiento del sistema, y esta necesidad es mayor cuanto más complejo es el sistema y más secciones críticas contiene.

Los desarrolladores y diseñadores deben evaluar la complejidad del sistema. Si se toma la decisión de escribir una herramienta compleja de administración y seguimiento que no está prevista en los términos de referencia, entonces, en este caso, los términos de referencia deben cambiarse y no ser guiados por el cliente. En un sistema complejo, todavía es necesario realizar un seguimiento de los procesos críticos. Es muy difícil introducir tales herramientas en un sistema ya terminado, ya que los monitores a menudo reciben datos iniciales de módulos del sistema de un nivel bastante bajo. Tampoco aquí se puede prescindir de cambios en el esquema de la base de datos y no hay garantía de que dichos cambios no degraden el rendimiento del sistema.

El desarrollo de monitores es una clase de tareas bastante específica: por un lado, deben procesar una cantidad suficiente de información y, por otro lado, no deben afectar significativamente el funcionamiento de otros componentes del sistema de información. Esto obliga a los desarrolladores a abordar el diseño de monitores con mucho cuidado y escribir el código de sus módulos con mucho cuidado.

Interfaces

Las interfaces de usuario final son lo que más critica el cliente, ya que son estas partes del sistema de información las que puede evaluar de forma más o menos cualificada; normalmente sólo las ve. Esto significa que las interfaces son el elemento del sistema de información que se cambia con más frecuencia en la etapa de implementación.

Los componentes de un sistema de información que cambian con frecuencia deben aislarse de los componentes que rara vez cambian, de modo que un cambio no implique otro. Una técnica para este aislamiento es aislar las solicitudes de datos de la interfaz, de la siguiente manera:

cada una de las solicitudes está codificada con un identificador o "cerrada" mediante una función específica del sistema;
el desarrollador de la interfaz no sabe nada sobre la solicitud de datos, excepto los parámetros de los atributos de selección: su tipo y, posiblemente, el número de filas de la selección;
el manejo de errores en las solicitudes de datos es un módulo separado;
El manejo de errores en la interpretación de resultados de consultas también es un módulo separado.

Al procesar los resultados de las consultas de datos, también debe Atención especial prestar atención a las cuestiones de correspondencia entre los tipos del lenguaje anfitrión y el DBMS, incluidas las cuestiones de la precisión de los tipos numéricos, ya que su representación en diferentes DBMS varía significativamente. Además, preste atención a las consultas de datos que utilizan funciones específicas del sistema operativo, como funciones de palabra y byte de valor de atributo (por ejemplo, estas funciones funcionarán de manera diferente en Intel y SUN SPARC). Los tipos de datos se pueden convertir explícitamente en la consulta mediante funciones de conversión y funciones integradas de DBMS, o en funciones del programa de aplicación. No para todos los DBMS, la conversión de tipos implícita da el mismo resultado, por lo que si el sistema de información utiliza datos de varias bases de datos controladas por diferentes DBMS, entonces se deben evitar las conversiones de tipos implícitas.

También deberías establecer reglas bastante estrictas para la apariencia de las interfaces de usuario. Se debe crear la impresión de un estilo único para todos los componentes del sistema de información.

Versiones de bases de datos

En la mayoría de los casos, la primera versión de la base de datos del proyecto se crea con bastante rapidez; se trata de la implementación de una estructura completamente normalizada, que se obtiene en la etapa de análisis. El objetivo principal de esta base de datos es proporcionar prototipos, demostraciones y algunos experimentos por parte de desarrolladores y diseñadores.

Los scripts para crear una base de datos y llenarla con datos de inicio también son el código fuente del sistema de información y se le aplican reglas de control de versiones. Cabe señalar que mantener las versiones de la base de datos a nivel de script es aún más fácil que a nivel de las herramientas de carga y descarga de datos proporcionadas por el propio DBMS, ya que en la gran mayoría de los casos dichas herramientas no pueden proporcionar varias funciones simples pero necesarias:

controlar qué objetos de datos y datos están en los objetos de descarga A y B, y cargar solo la "diferencia" de A y B en la base de datos (realizar una actualización de versión);
compruebe si los cambios que tienen lugar en los objetos de carga C y D entran en conflicto con el objeto de carga A (versiones fusionadas).

Las herramientas CASE tienen herramientas de control de versiones del esquema de la base de datos, algunas tienen configuraciones que le permiten controlar también los datos de inicio. Esto hace posible utilizar estas herramientas para proporcionar versiones de bases de datos.

Es más confiable controlar las versiones del código fuente de los activadores y procedimientos almacenados utilizando el mismo sistema de control de versiones que se adopta para almacenar los textos fuente del propio proyecto.

Colocación de la lógica de procesamiento.

Una de las cuestiones de diseño importantes es la forma de ubicar la lógica empresarial de procesamiento de datos: colocarla (y qué parte) en el servidor en forma de procedimientos almacenados, paquetes, activadores y otras restricciones de integridad directamente en el servidor de la base de datos, o en la forma de funciones en el cliente (en parte del software del cliente). La ubicación de las reglas de interfaz y de datos se especifica exactamente: las primeras siempre se encuentran en el cliente, las segundas en el servidor. Las reglas de lógica empresarial en los DBMS modernos se pueden colocar tanto en el cliente como en el servidor. Considere uno de los ejemplos de la regla comercial más simple:

El valor en el campo del formulario de pantalla lo ingresa el usuario, no se selecciona de la lista, pero el conjunto de valores válidos está estrictamente limitado (por ejemplo, dos o tres valores diferentes).

Por un lado, el usuario requiere una respuesta inmediata del sistema ante un error de entrada de datos, por otro lado, los valores en el campo de la base de datos que sean diferentes a los especificados (dos o tres) no son válidos. De hecho, en esta situación se deben implementar dos reglas. La regla de datos en este caso se organizará como una restricción de verificación, y la regla de interfaz que prohíbe ingresar valores distintos a los especificados repetirá exactamente la regla de datos, pero se implementará en el nivel de la interfaz de usuario. Parecería que implementar un formulario con una lista en este caso es la solución ideal, pero la mayoría de los operadores prefieren el conjunto en el formulario, especialmente si la longitud del valor de entrada es pequeña. Los formularios con una gran cantidad de listas son difíciles de procesar para los usuarios finales. En el caso de un valor establecido en un formulario, también se debe tener cuidado de convertir el caso de las cadenas de caracteres (donde el caso no es significativo) a mayúsculas o minúsculas, en el nivel de interfaz del programa de aplicación.

Plantillas

El uso de plantillas y bibliotecas para crear módulos "similares" es una práctica bastante común. Qué usar en este caso (objetos, clases o bibliotecas) lo decide un grupo específico de desarrolladores. En la mayoría de los casos, no tiene sentido dictar la forma de desarrollo, porque el desarrollador escribe el código de la forma que sabe o está acostumbrado. Estos momentos suelen estar controlados por el director del proyecto.

En cualquier proyecto, la copia de código está prohibida, ya que esto conduce a la aparición de diferentes versiones del mismo código en diferentes fragmentos del programa de aplicación y, como resultado, a errores difíciles de detectar y corregir. Se debe establecer una regla estricta: se utiliza una llamada a función, no una copia de ella en el código; cualquier desviación de esta norma es punible.

Pruebas

Como se mencionó anteriormente, los equipos de prueba pueden participar en las primeras etapas del desarrollo del proyecto. Las pruebas exhaustivas en sí deberían destacarse como una etapa de desarrollo separada. Dependiendo de la complejidad del proyecto, probar y corregir errores puede llevar un tercio, la mitad o más del tiempo de desarrollo de todo el proyecto.

Cómo proyecto más difícil, mayor será la necesidad de automatización del sistema de seguimiento de errores. Un sistema de este tipo proporciona las siguientes funciones:

almacenamiento del mensaje de error (con información obligatoria sobre a qué componente del sistema pertenece el error, quién lo encontró, cómo reproducirlo, quién es responsable de solucionarlo y cuándo debe solucionarse);
un sistema de notificación sobre la aparición de nuevos errores, sobre un cambio en el estado de los errores conocidos en el sistema (por regla general, son notificaciones por correo electrónico);
informes sobre errores reales por componentes del sistema, por intervalos de tiempo, por grupos de desarrolladores y desarrolladores;
información sobre el historial del error (incluido el seguimiento de errores similares, el seguimiento de la recurrencia de un error);
reglas para acceder a errores de determinadas categorías;
Interfaz de acceso limitado al sistema de seguimiento de errores para el usuario final del sistema de información, que se utiliza como interfaz para el intercambio de información entre el usuario y el servicio. apoyo técnico sistemas.

Estos sistemas eliminan muchos problemas organizativos, en particular la notificación automática de errores.

En realidad, las pruebas del sistema se pueden dividir en varias categorías:

pruebas de módulos independientes: ya se utilizan en la etapa de desarrollo de los componentes del sistema y permiten rastrear errores de componentes individuales;
pruebas de conexiones entre componentes del sistema: se utilizan tanto en la etapa de desarrollo como en la etapa de prueba y le permiten monitorear la interacción correcta y el intercambio de información entre los componentes del sistema;
prueba del sistema: es el criterio principal para la aceptación del sistema. Como regla general, este es un grupo de pruebas que incluye pruebas independientes, así como pruebas de enlace y modelo. Esta prueba debe reproducir el funcionamiento de todos los componentes y funciones del sistema, su principal objetivo es la aceptación interna del sistema y la evaluación de su calidad;
Prueba de aceptación: se utiliza cuando el sistema se entrega al cliente. En este caso, los desarrolladores a menudo subestiman los requisitos del sistema en comparación con la prueba del sistema y, en general, está claro por qué esto está justificado;
pruebas de rendimiento y carga: están incluidas en la prueba del sistema, pero merecen una mención especial, ya que este grupo particular de pruebas es el principal para evaluar la confiabilidad del sistema.

Las pruebas de cada grupo incluyen necesariamente pruebas de simulación de fallos. Aquí se comprueba la respuesta de un componente, de un grupo de componentes, del sistema en su conjunto ante fallos del siguiente tipo:

falla de un componente separado del sistema de información;
falla de un grupo de componentes del sistema de información;
falla de los principales módulos del sistema de información;
falla del sistema operativo;
Fallo "duro" (fallo de energía, discos duros).

Estas pruebas permiten evaluar la calidad del subsistema para restaurar el correcto estado del sistema de información y sirven como principal fuente de información para desarrollar estrategias para prevenir las consecuencias negativas de fallas durante la operación industrial. Como regla general, esta es la clase de pruebas que los desarrolladores descuidan y luego enfrentan las consecuencias de las fallas en un sistema de producción.

Otro punto importante del programa de prueba de sistemas de información es la disponibilidad de generadores de datos de prueba. Se utilizan para realizar pruebas de funcionalidad del sistema, pruebas de confiabilidad del sistema y pruebas de rendimiento del sistema. La tarea de evaluar las características de la dependencia del desempeño de un sistema de información del crecimiento del volumen de información procesada no puede resolverse sin generadores de datos.

Operación y mantenimiento

La operación de prueba anula el proceso de prueba. Como regla general, el sistema no se pone en funcionamiento de forma completa, sino de forma gradual.

La puesta en servicio se realiza en al menos tres fases:

acumulación de información;

alcanzando la capacidad de diseño.

La carga inicial de información inicia un círculo bastante estrecho de errores, principalmente problemas de discrepancia de datos durante la carga y errores propios de los cargadores, es decir, lo que no se rastreó en los datos de prueba. Estos errores deberían corregirse lo antes posible. No sea demasiado vago para instalar una versión de depuración del sistema (a menos, por supuesto, que se le permita implementar todo el complejo de software que acompaña a la depuración del sistema de información en el sitio). Si es imposible depurar datos "en vivo", entonces tendrá que simular la situación y rápidamente. Requiere probadores muy calificados.

Durante el período de acumulación de información aparecerá la mayor cantidad de errores cometidos durante la creación del sistema de información. Como regla general, se trata de errores relacionados con el acceso multiusuario. A menudo, en la etapa de prueba, no se presta la debida atención a estos errores, aparentemente debido a la complejidad del modelado y al alto costo de las herramientas de automatización de procesos. pruebas sistema de información en condiciones de acceso multiusuario. Algunos errores serán bastante difíciles de corregir, ya que son errores de diseño. Ninguno de los mejores proyectos está inmune a ellos. Esto significa que, por si acaso, es necesario reservar tiempo para localizar y corregir dichos errores.

Durante el período de acumulación de información, se puede encontrar la famosa “caída de base”. En el peor de los casos, resulta que el DBMS no puede soportar el flujo de información. Si está bien es solo que los parámetros de configuración están mal. El primer caso es peligroso, ya que es bastante difícil influir en el fabricante del DBMS y al cliente realmente no le gustan los enlaces al servicio de soporte técnico del DBMS. No es el fabricante quien tendrá que resolver el problema de la falla del DBMS, sino usted: cambiar el esquema, reducir el flujo de solicitudes, cambiar las solicitudes mismas; En general, hay muchas opciones. Es bueno que el tiempo de recuperación de la base de datos se ajuste al planificado.

Cuando el sistema alcanza su capacidad de diseño, en un conjunto exitoso de circunstancias, se trata de la corrección de una serie de errores menores y, en ocasiones, de errores graves.

Otros enfoques de desarrollo de aplicaciones

Normalmente, los usuarios finales y la dirección sienten que el proceso de diseño ha fracasado porque no hay componentes disponibles en el mercado para "sentir". A menudo el cliente insiste en llevar a cabo la fase de implementación del proyecto antes de lo previsto para obtener algún resultado y demostrarlo lo antes posible. En tal caso, existe una fuerte tentación de optar por el desarrollo acelerado de aplicaciones (ADD) o el desarrollo colaborativo de aplicaciones (CDA). Estos métodos implican desarrollar un prototipo funcional y luego demostrarlo a los usuarios. Los usuarios marcan lo que les gusta y lo que no. El diseñador finaliza el prototipo teniendo en cuenta los comentarios realizados, tras lo cual vuelve a demostrar lo sucedido. Etcétera. El proceso se repite hasta que a los usuarios les gusta lo que ven y el prototipo se convierte en una aplicación funcional. Generalmente hay un límite de tiempo y un número de iteraciones; de lo contrario, los usuarios estarán perfeccionando el prototipo para siempre. En teoría, esto le permite obtener el sistema que los usuarios requieren. En la práctica, este enfoque del desarrollo de aplicaciones está plagado de serios problemas.

Toda la atención se centra en las pantallas, y lo que se refiere a las reglas de procesamiento de datos y las funciones del sistema queda detrás de escena. Existe la tentación de empezar a trabajar con informes, mientras que un informe no es un producto inicial, sino un producto derivado del sistema de información.
Los usuarios creen que si se acuerda la versión prototipo, entonces el módulo estará listo. De hecho, puede ser simplemente una imagen con un conjunto de "códigos auxiliares" para llamar a funciones del sistema e interactuar con otros módulos.
Los módulos están diseñados de forma aislada unos de otros (probablemente la mayoría de ustedes se han encontrado con programas de contabilidad donde cada estación de trabajo es autónoma y las funciones a menudo están duplicadas). La consecuencia de esto son las contradicciones de módulos, la duplicación de funciones y datos, que sólo pueden revelarse al probar un complejo de módulos.
La funcionalidad crece paralelamente en varias direcciones, lo que significa que la estructura de la base de datos debe controlarse estrictamente. Con RRP, el esquema de la base de datos se convierte en un depósito de chatarra donde las tablas se "moldean" apresuradamente, lo que da como resultado un conjunto de datos inconsistentes y duplicados.
La documentación cuando se utiliza el método ERP, por regla general, está ausente, o más bien, se olvida la necesidad de documentar el sistema, ya que se crea la ilusión de que el usuario ya comprende lo que está sucediendo. Cuando la aplicación empieza a funcionar de forma diferente a lo que el usuario espera, surgen muchos problemas.
El manejo de situaciones excepcionales para cada módulo se realiza de forma independiente.
Un sistema completo, por regla general, no funciona, lo más probable es que se trate de un determinado conjunto de estaciones de trabajo automatizadas, interconectadas apresuradamente.

Los métodos ERP y PSA no siempre se pueden utilizar, pero sólo si:

el alcance del proyecto y los requisitos comerciales están claramente definidos, no cambian y el proyecto en sí es pequeño;
el proyecto no depende de otras herramientas de automatización empresarial, la cantidad de interfaces externas con las que debe lidiar es limitada;
el sistema se centra en las pantallas, el procesamiento de datos y las funciones del sistema son una pequeña parte, la conveniencia de las pantallas es uno de los cinco factores más importantes para el éxito del proyecto;
Los usuarios están altamente calificados y a priori evalúan positivamente la idea de crear nuevo software.

Sin embargo, la ERM es mejor para desarrollar partes pequeñas y preferiblemente autónomas del proyecto.

Actualmente, se ha intentado introducir otra forma de escribir rápidamente un proyecto: el método de programación extrema. Los principios de este enfoque se discutirán a continuación.

Etapa de planificación (juego de planificación). A partir de las valoraciones realizadas por los programadores, el cliente determina la funcionalidad y el plazo de implementación de las versiones del sistema. Los programadores implementan solo aquellas características que son necesarias para las características seleccionadas en una iteración determinada.

Como resultado de tal decisión, el desarrollo del sistema permanece "entre bastidores", como resultado de lo cual, durante el desarrollo, es necesario construir "stubs" y reescribir el código. No está claro por qué el cliente determina el plazo de implementación, porque en realidad es responsabilidad directa del equipo de diseño. El cliente, por lo general, sólo puede expresar sus deseos en cuanto al tiempo (“lo quiero en tal fecha”), pero sólo el diseñador puede determinar el plazo (“se puede hacer en no menos de tal o cual tiempo”). ”).

Cambio frecuente de versiones (pequeños lanzamientos). El sistema se pone en funcionamiento a los pocos meses del inicio de su implantación, sin esperar a la resolución definitiva de todos los problemas planteados. Se pueden lanzar nuevas versiones a intervalos que van desde diarios hasta mensuales.

Todo está bien, excepto una cosa: es imposible probar un componente más o menos complejo en tanto tiempo. En realidad, el cliente actúa como probador beta. En este caso, puede ver que los desarrolladores están trabajando e incluso solucionando errores. Sin embargo, surgen preguntas razonables: ¿vale la pena dedicar al cliente al flujo de trabajo y es necesario experimentar? sistema de trabajo? Además de lo dicho, cabe señalar que un principio similar difícilmente se puede implementar para partes del proyecto que requieren trabajar en modo 24 horas al día, 7 días a la semana.

Metáfora. La visión general del sistema se define mediante una metáfora o un conjunto de metáforas en las que el cliente y los programadores trabajan juntos.

Por un lado, este postulado no parece malo, pero por otro, ¿tiene sentido dedicar al cliente a los asuntos internos del grupo de desarrollo? Lo que concierne a la vista general (interfaces, informes, etc.) puede efectivamente ser competencia del cliente, pero cuando estamos hablando sobre las características de la implementación de ciertos componentes, el cliente difícilmente puede ser útil debido a su falta de conocimiento necesario.

Proyecto simple (diseño simple). En cada momento, el sistema que se está desarrollando realiza todas las pruebas y admite todas las relaciones definidas por el programador, no tiene código duplicado y contiene el mínimo número posible de clases y métodos. Esta regla se puede expresar brevemente de la siguiente manera: "Formule cada pensamiento una vez y sólo una vez".

Esta idea también es buena, pero no concuerda del todo con el principio de escribir código rápidamente. ¿Quizás deberías pensar primero en cómo hacer tal o cual módulo, un grupo de módulos, y solo entonces comenzar a escribir código?

Pruebas Los programadores escriben pruebas unitarias todo el tiempo. En conjunto, estas pruebas deberían funcionar correctamente. Para los pasos de una iteración, los clientes escriben pruebas funcionales que también deben funcionar correctamente. Sin embargo, en la práctica esto no siempre es posible. Para tomar la decisión correcta, es necesario comprender cuánto costará enviar un sistema con un defecto conocido de antemano y compararlo con el costo de retrasar la reparación del defecto.

Cuando los propios programadores escriben pruebas (especialmente en condiciones de tiempo extra), estas pruebas no son completamente funcionales y, más aún, no tienen en cuenta las características del trabajo multiusuario. Los desarrolladores normalmente no tienen tiempo suficiente para realizar pruebas más avanzadas. Por supuesto, es posible construir un sistema de desarrollo de tal manera que las mismas personas participen en todo, pero aún así no debes convertir el proyecto en un análogo del programa de televisión "Director for Yourself". A lo dicho hay que añadir que las pruebas de sistemas no se limitan en modo alguno a pruebas de componentes (unidades); No menos importantes son las pruebas de interacción entre ellos, lo mismo se aplica a las pruebas de confiabilidad del trabajo. Sin embargo, el método de Programación Extrema no prevé la creación de pruebas de esta clase. Esto se explica por el hecho de que dichas pruebas en sí mismas pueden representar un código bastante complejo (esto es especialmente cierto para las pruebas que imitan el funcionamiento real del sistema). Esta tecnología tampoco tiene en cuenta otra clase importante de pruebas: las pruebas del comportamiento del sistema con un aumento en el volumen de información procesada. Con una alta tasa de cambio de versión, es tecnológicamente imposible realizar una prueba de este tipo, ya que para su implementación se requiere un código de proyecto estable y sin cambios, por ejemplo, dentro de una semana. Estos tiempos generalmente no están garantizados debido a turno frecuente versiones. En este caso, deberá suspender el desarrollo de componentes o crear una versión paralela del proyecto durante la prueba, que permanecerá sin cambios, mientras que la segunda cambiará. Luego deberás realizar el proceso de fusionar el código. Pero en este caso habrá que volver a crear la prueba, ya que los métodos de programación extremos simplemente no permiten el desarrollo de herramientas que permitan predecir el comportamiento del sistema ante determinados cambios.

Reelaboración del sistema (refactorización). La arquitectura del sistema está en constante evolución. El proyecto actual se transforma, al tiempo que se garantiza que todas las pruebas se ejecuten correctamente.

Aquí es donde comienza la diversión. Extreme Programming supone que siempre es posible rehacerlo y sin gran coste. Sin embargo, la práctica demuestra lo contrario.

Programación en pareja. Todo el código del proyecto está escrito por dos personas que utilizan el mismo sistema de escritorio.

Surge la pregunta: ¿alguien ha visto dos programadores completamente idénticos, cada uno de los cuales, además, al final de la jornada laboral tendría tiempo de escribir documentación para un socio? ¿Es posible encontrar programadores gemelos que estén de acuerdo en todo?

Y lo más importante, ¿por qué necesitamos un par de programadores así? La razón, en general, es simple: no todo el mundo puede soportar el alto ritmo de trabajo impuesto durante la programación extrema, la salida de personal es inevitable. Una pareja así puede proporcionar algún tipo de seguro: si uno renuncia, tal vez el segundo ponga fin al asunto. Es cierto que el resto caerá en un plazo aún más ajustado; después de todo, la cantidad de trabajo seguirá siendo la misma y no habrá ningún suplente, al menos durante algún tiempo. A esto le sigue un proceso natural de transferencia de información a un nuevo suplente, lo que nuevamente lleva tiempo. Y así sin fin.

Integración continua (integración continua). El nuevo código se integra en el sistema existente como máximo en unas pocas horas. Después de eso, el sistema se vuelve a ensamblar en un todo y se ejecutan todas las pruebas. Si al menos uno de ellos no se realiza correctamente, los cambios realizados se cancelan.

Este postulado es al menos controvertido, ya que no está claro quién corregirá los errores, no sólo locales, sino también inducido codigo erroneo. Después de todo, en esta etapa no se deben realizar pruebas complejas; además, los cambios permanecen incluso si se detecta un error. Al mismo tiempo, Extreme Programming no proporciona un sistema de seguimiento de errores.

Propiedad colectiva. Cada programador tiene la oportunidad en cualquier momento de mejorar cualquier parte del código del sistema, si lo considera necesario.

¿Esto te recuerda a la anarquía? ¿Cómo encontrar al autor de los cambios en este caso? Al desarrollar un gran proyecto, ¿alguien se encontró con un “experto en todos los oficios” y cuánto tiempo podría resistir un “artesano” así en su lugar de trabajo? Así es, no mucho.

Cliente con participación constante (cliente presencial). Un cliente que está en el equipo de desarrollo durante el período de trabajo en el sistema.

Esto, por supuesto, es bueno, pero el objetivo no está claro: ¿dedicar al cliente a la esencia del asunto o convertirlo en coautor? Es poco probable que sólo el cliente encuentre un especialista tan altamente calificado.

Semana de 40 horas (semanas de 40 horas). La duración de las horas extraordinarias no podrá exceder de una semana laboral. Incluso los casos individuales de horas extraordinarias, repetidos con demasiada frecuencia, son una señal de problemas graves que requieren atención urgente.

Como muestra la práctica de la programación extrema (a pesar de una serie de ejemplos positivos dados por los partidarios de este método), las horas extras con este enfoque son la regla, no la excepción, y la lucha contra los problemas en este caso es un fenómeno constante. Se intensifica durante el período de sustitución de la versión actual en bruto del producto por otra versión, también en bruto. El cliente iniciado en el proceso experimenta en sí mismo todos los encantos de la manifestación de errores del sistema. ¿Durante cuánto tiempo cree que el cliente tendrá suficiente paciencia en esta situación? Necesita que el sistema funcione...

Espacio de trabajo abierto (espacio de trabajo abierto). El equipo de desarrollo está ubicado en una sala grande rodeada de salas más pequeñas. En el centro del espacio de trabajo hay ordenadores instalados en los que trabajan parejas de programadores.

Además, todo esto, a juzgar por los principios anteriores, debe ubicarse en el territorio del cliente, ya que éste participa muy activamente en el proceso de desarrollo. Surge la pregunta: ¿es realista una combinación tan afortunada de circunstancias?

Nada más que reglas. Los miembros del equipo de Extreme Programming están obligados a seguir las reglas anteriores. Sin embargo, estas no son más que reglas y el equipo puede cambiarlas en cualquier momento si sus miembros han llegado a un acuerdo de principio sobre los cambios realizados.

Quizás, al final, se desarrolle una regla útil: "primero piensa, luego haz". En este caso tendremos un esquema muy parecido a una "cascada". Por alguna razón, los partidarios de la programación extrema están convencidos de que cuando se utiliza la "cascada" y sus clones, el ciclo de desarrollo debe ser largo. No está claro cuál es el motivo de tal confianza. Después de todo, no está prohibido dividir el proyecto en etapas. Por alguna razón, se cree que la planificación será necesariamente única y sin cambios, aunque en realidad esto no es cierto, incluso en el caso de una "cascada".

Como resultado, obtenemos un método que es potencialmente altamente adaptable a los requisitos del proyecto altamente cambiantes, pero al mismo tiempo no está exento de una serie de deficiencias graves. Esta última circunstancia no nos permite recomendar este método a la aplicación para proyectos que exigen una seguridad de trabajo alta o al menos suficiente.

ComputadoraPrensa 2” 2002

No hay nada más difícil, peligroso e incierto que liderar la introducción de un nuevo orden de cosas, porque cada innovación tiene enemigos ardientes que vivieron bien a la antigua usanza y partidarios lentos que no están seguros de poder vivir en el nuevo. .
N. Maquiavelo

Y ahora la parte interesante y llena de creatividad, proyección, creatividad y creación del proyecto llega a su fin. Comienza el duro día a día de defender tu decisión en un ambiente real empresa específica, y lo que no es menos importante, todo está también dentro del marco de la legislación vigente.

Para comenzar producto vendido debe desplegarse en equipos preparados para organizar su operación de prueba.

1. Despliegue del sistema en el sitio de prueba.

De acuerdo con la arquitectura tecnológica diseñada, reflejada en la documentación, se adquieren servidores, equipos de comunicación y otros, así como el software del sistema. Los componentes del sistema de información se montan en un único complejo de software y hardware, en los lugares donde está previsto su uso industrial.

En vista de que en proyectos mayores, se trata de una gran cantidad de equipos en los que el software se encuentra disperso en nodos, nodos e incluso nubes, entonces este proceso debe ir acompañado de documentación a gran escala. Por ejemplo, la documentación técnica incluye tablas con direcciones de servidores, lugares de trabajo, métodos de acceso, etc. Para la representación visual se utilizan diagramas de componentes, que permiten comprender la ubicación de los nodos de la red, la distribución de los componentes de su interacción, etc. Pero aún deben determinarse las medidas que regulen todo tipo de cambios en la infraestructura, que permitan eliminar las consecuencias de fallas de varios elementos del sistema.

Figura 19. Un ejemplo de descripción técnica de la etapa de implementación.

Todo esto es extremadamente importante, ya que en la siguiente etapa en estos sitios operativos habrá muchos especialistas del equipo de implementación y soporte, y no tienen que buscar la información necesaria para el trabajo cada vez en fuentes diferentes, incluso bien informadas. . Por lo tanto, la documentación debe mantenerse actualizada y modificarse simultáneamente con cambios en la configuración del sistema, cambios solución arquitectónica etcétera.

No está de más que en los lugares de “combate” para el funcionamiento industrial del sistema se instalen bancos de pruebas que simulen un trabajo cercano al real. Bueno, de repente habrá comentarios que requieren el lanzamiento de nuevos lanzamientos. Por supuesto, todos son profesionales, personas responsables y todo eso, pero es mejor realizar las actualizaciones primero en un banco de pruebas. Así que por si acaso.

Mientras tanto, el 90% del tiempo ya ha pasado volando...

2. Capacitación del personal del cliente para trabajar con el sistema de información.

Como se ha mencionado repetidamente, en proyectos grandes se presta especial atención a la calidad de la documentación, incluidas las instrucciones para los usuarios del sistema. La mayoría de las veces, las instrucciones para el usuario se dividen en segmentos por tipo de actividad, especialización, etc. Esto le permite centrarse en puntos importantes del documento y no cargar a los usuarios con información innecesaria.

Dado que en la formación puede participar un número importante de diferentes empleados del cliente, que, a su vez, para garantizar la continuidad de los procesos de negocio, no pueden formarse al mismo tiempo, por lo que deben formarse en diferentes deberes funcionales y para otros buenas razones, es necesario planificar cuidadosamente el proceso de formación del personal. También es útil dividir a los alumnos en grupos en categorías que requieran el uso de diferentes aproximaciones y profundidad de la formación, en función de su nivel de preparación inicial. Como resultado, el programa de formación elaborado debe acordarse con todos partes interesadas, y aprobado por la dirección del cliente como obligatorio.

Y advertimos en la fase de diseño que formar al personal del cliente no sólo es una tarea muy responsable, sino también muy laboriosa…

3. Identificación de falencias y defectos del sistema de información

Muy a menudo, en proyectos grandes, probar la versión final no revela todas las áreas problemáticas de la solución. La razón de esto puede ser: enormes cantidades de datos en condiciones reales de "combate", la manifestación de combinaciones únicas de reglas comerciales en procesos comerciales reales, las características de operación de equipos específicos, combinaciones específicas de componentes del sistema, equilibrio de carga entre distribuidos. nodos, etc

A menudo, la situación se complica aún más por el hecho de que la introducción de nuevos sistemas en las etapas iniciales no elimina en modo alguno la necesidad de trabajar en sistemas antiguos. Es decir, los usuarios duplican datos en ambos sistemas. A veces es necesario migrar datos existentes y actualizados desde repositorios obsoletos a otros nuevos, y la estructura y formato de la información suele ser muy, muy diferente. Por ejemplo, si no hay suficiente información en la nueva estructura de datos para completar los detalles requeridos, se completan con algunos datos asignados "por defecto" y luego los usuarios los ajustan manualmente. Y esto es sólo una pequeña fracción de lo que tienes que afrontar en proyectos reales.

Un tema aparte son las soluciones de integración en las que pueden ocurrir fallas en una cadena utilizando varios componentes desarrollados por dos, tres o más equipos. Es extremadamente difícil encontrar culpables en esta situación, ya que los defectos ocurren con mayor frecuencia en la unión de los elementos de integración, debido a inconsistencias identificadas durante la implementación. Y aquí es importante no buscar culpables para castigarlos, sino acordar de manera rápida y constructiva concesiones conjuntas por parte de los desarrolladores de los componentes unidos y resolver el problema de manera efectiva.

Teniendo en cuenta todo lo anterior, la etapa de operación de prueba suele estar llena de arrebatos emocionales y reclamos mutuos, tanto entre los equipos de desarrollo como con los clientes. En este caso, es muy importante el papel de los arquitectos y analistas de sistemas, quienes deben localizar rápidamente el problema, proponer una solución y coordinarla con todas las partes interesadas. Para realizar dicho trabajo, además de las habilidades profesionales básicas, también es necesario tener talento de negociador y conocimientos de los conceptos básicos de gestión.

Mientras tanto, hemos llegado al final del tiempo asignado para el proyecto...

4. Coordinación de cambios en el proceso de implementación del sistema de información.

Si el funcionamiento de algunos módulos funcionales del sistema de información no satisface de manera crítica las necesidades y expectativas del cliente, y se encuentran soluciones para superar estos problemas, entonces es necesario solucionarlos y acordar con el cliente.

La etapa de acordar una nueva solución es muy importante, al menos por dos razones.

En primer lugar, si el volumen de implementación de los cambios excede las cantidades prometidas para riesgos similares en el plan del proyecto, es necesario concluir acuerdos adicionales o el equipo de artistas trabajará con pérdidas. A menudo se pide a los artistas que realicen cambios rápidamente, pero dicen que los tendremos en cuenta y pagaremos el trabajo en ellos más tarde, en un solo paquete. Pero, de hecho, estos casos generalmente conducen al hecho de que el cliente luego olvida por completo sus promesas y anuncia el trabajo realizado: la corrección de sus propios errores por parte de los artistas.

En segundo lugar, cualquier cambio en algunos componentes del sistema puede implicar un cambio inevitable en los componentes interdependientes, lo que requiere un análisis cuidadoso y, posiblemente, un rediseño de toda la cadena de subsistemas. De lo contrario, es inevitable que se produzcan defectos en el funcionamiento del sistema en su conjunto. Esto puede manifestarse, por ejemplo, en la falla del módulo de un equipo de artistas adyacente, y el cliente ya los declara hackers y estafadores. La verdad seguramente saldrá a la luz, pero el colono permanecerá.

Y parafraseando a Jerzy Leca: “Cuando llegamos al final del tiempo asignado, sonó un golpe desde abajo…”

Como el tiempo está vencido, es necesario negociar con el cliente y convencerlo de que él tampoco fue un regalo en el proyecto y que parte de la culpa es de él.

5. Perfeccionamiento del sistema de información en base a los resultados de la operación de prueba.

Si durante la operación de prueba se toman y acuerdan decisiones sobre la realización de cambios en el sistema de hardware y software desarrollado, entonces, en base a ellas, se establecen tareas para que los ejecutores las implementen. Se repite el proceso descrito en la Sección Parte 3. Implementación de la decisión de diseño. Pero…

Si en la etapa de diseño del sistema discutimos el impacto negativo del uso completo de la metodología Scrum (1) en proyectos grandes, entonces en esta etapa encaja perfectamente. Esto se nota especialmente en proyectos en los que el producto entregado al cliente no le conviene en la mayor parte de los indicadores. En otras palabras, es hora de entrar en pánico y, muy rápidamente, "precipitarse" de realizar cambios en un producto que ya está siendo explotado.

En rigor, ha llegado el momento en que son relevantes las siguientes condiciones:

El cliente ya ha comenzado a trabajar con el sistema, se le ha asignado tiempo para ello y ahora comprende claramente lo que realmente necesita. Por lo tanto, está dispuesto a trabajar en estrecha colaboración con el equipo de artistas y lo necesita con urgencia;
En su mayor parte, la documentación ya está lista y sus modificaciones y adiciones ya no se pueden realizar tan rápidamente, sino que se pueden redactar a posteriori en función de los resultados de una implementación exitosa.
Las mejoras se producen principalmente en módulos, subsistemas y circuitos separados, que cuentan con un equipo específico de ejecutantes responsables del segmento. Por lo tanto, la comunicación entre usuarios y desarrolladores ya está localizada y es fácil establecer comentarios de alta calidad;
Las mejoras y correcciones deben realizarse muy rápidamente, en pequeñas colas con la transferencia del resultado al cliente, que está de vital interés en ellas;

Es muy importante que, al final, la documentación del proyecto esté completamente alineada con las innovaciones y que el equipo pueda encontrar fácilmente en ella una solución actualizada para el análisis y diseño de cambios posteriores.

Figura 20. - La etapa de implementación del sistema de información.

Sin comentarios…

6. Transferencia del sistema de información a operación comercial

Cuando durante la operación de prueba se resuelven todas las cuestiones controvertidas y malentendidos sobre cómo debe funcionar el sistema implementado y cómo corresponde al contrato para su desarrollo, las partes firman actos sobre la implementación del contrato. El cliente realiza el pago total del trabajo realizado. Se podrá dar por cumplido el contrato para el desarrollo e implementación del sistema de información.

La implementación pasa a la fase de operación comercial. Estas relaciones suelen estar reguladas legalmente por un acuerdo separado o acuerdo adicional para apoyar la operación industrial del sistema. En el marco de este contrato se podrán realizar trabajos preventivos para diagnosticar el funcionamiento de los componentes del sistema, su interacción, eliminación de averías menores, etc.

7. Resumen de la sección

La etapa de implementación del sistema de información es el momento de la verdad de todo el proceso de su producción y marcará el inicio del período más difícil para todos los participantes del proyecto. Puede incluir las siguientes actividades:

Implementación del sistema en el sitio de operación industrial, incluido el suministro de equipos, instalación del software del sistema, instalación de la versión actual del sistema que se está implementando, etc.;
Capacitación de usuarios para trabajar con el sistema, incluidos administradores, especialistas en mantenimiento de equipos, etc.
Identificación y eliminación de deficiencias y defectos identificados durante la operación de prueba.
Coordinar los cambios en el funcionamiento del sistema y adecuarlo a las obligaciones contractuales;
Firma de documentos sobre el cumplimiento de obligaciones contractuales. Realizar un pago completo por el trabajo realizado;
Poner el sistema en operación comercial;

La introducción de SI corporativo, desarrollado de forma independiente o comprado a un proveedor, suele ir acompañada de una interrupción (rediseño) de los procesos de negocio existentes en la empresa. Tenemos que reconstruirlos para que cumplan con los requisitos de los estándares y la lógica del sistema que se está implementando. Observamos de inmediato que la introducción de la propiedad intelectual resuelve una serie de problemas técnicos y de gestión, pero genera problemas asociados con el factor humano.

La introducción de un sistema de información, por regla general, facilita enormemente la gestión de una empresa, optimiza los flujos de información internos y externos y elimina los cuellos de botella en la gestión. Sin embargo, una vez que el sistema se ha instalado con éxito, "se ha puesto en funcionamiento" y ha demostrado su eficacia, algunos empleados se muestran reacios a utilizar IS en su trabajo. Como resultado de la reingeniería, queda claro que algunos empleados duplican en gran medida el trabajo de otros o no son necesarios en absoluto. Además, la introducción del CIS va acompañada de una formación obligatoria, pero, como se muestra experiencia rusa No hay tantos que quieran volver a capacitarse. ¡Romper viejas habilidades e inculcar otras nuevas es un proceso largo y difícil!

Debe quedar claramente claro que la propiedad intelectual corporativa está diseñada para simplificar la gestión de la organización, mejorar los procesos, fortalecer el control y proporcionar beneficios competitivos. Sólo desde este punto de vista es posible evaluar los beneficios de su implementación.

Siguiendo esta lógica, queda claro que aunque el SI corporativo generalmente tiene como objetivo proporcionar a todos los usuarios la información necesaria, gestionar el desarrollo y la implementación del CIS es prerrogativa de la alta dirección de la empresa. ¿Entienden esto los líderes?

Aquí también tenemos que lidiar con estereotipos tenaces. "¿Por qué necesito un sistema empresarial si de todos modos la empresa va bien?" "¿Por qué romper algo si todo funciona?". Pero la mayoría de las veces no es necesario romperlo. En la primera etapa, solo es necesario formalizar y transferir de manera competente y correcta los procesos identificados dentro de los cuales vive la empresa al SI corporativo. Tal formalización sólo perfeccionará y pulirá los descubrimientos exitosos de marketing y producción, optimizará el proceso de gestión y control y permitirá que se realicen cambios específicos en el futuro.

Introducción de un nuevo IS - proceso difícil que dura desde varios meses para los SI pequeños hasta varios años para los SI de grandes empresas distribuidas con una amplia gama de productos y un gran número de proveedores. El éxito de un proyecto para el desarrollo (o adquisición) e implementación de SI depende en gran medida de la disposición de la empresa para llevar a cabo el proyecto, el interés personal y la voluntad de la dirección, un programa de acción real, la disponibilidad de recursos, personal capacitado. personal y la capacidad de superar la resistencia en todos los niveles de la organización existente.

Hasta la fecha, se ha desarrollado un conjunto estándar de métodos para implementar la propiedad intelectual. La regla principal es realizar las fases obligatorias en secuencia y no saltarse ninguna de ellas.

Los siguientes factores son críticos para la implementación:

disponibilidad de objetivos de proyecto claramente definidos y requisitos de propiedad intelectual;

disponibilidad de una estrategia para la implementación y uso de la propiedad intelectual;

· realizar un estudio previo al proyecto de la empresa y construir modelos "tal cual" y "tal como será";

planificación del trabajo, recursos y control de la implementación del plan de implementación;

participación de la alta dirección en la implementación del sistema;

· realizar trabajos de implementación de SI por parte de especialistas en integración de sistemas junto con especialistas de la empresa;

seguimiento periódico de la calidad del trabajo realizado;

· recepción rápida de resultados positivos, al menos en parte de los módulos SI implementados o en el proceso de su operación de prueba.

Antes de iniciar el desarrollo de un proyecto de implementación, se debe:

· formalizar al máximo los objetivos del proyecto de implementación de PI;

estimar el mínimo costos necesarios y partidas de gastos;

· establecer una alta prioridad del proyecto de implementación sobre otros proyectos en curso;

Dar al director del proyecto tanta autoridad como sea posible;

· realizar una labor educativa masiva con el personal de la empresa para acercar a todos la importancia y necesidad de los cambios venideros;

· desarrollar medidas organizativas para la aplicación de nuevas tecnologías de la información;

distribuir responsabilidad personal en todas las etapas de implementación y operación piloto.

También es necesario definir Areas funcionales Implementación de módulos del sistema de información:

· gestión organizacional;

apoyo organizativo y administrativo;

gestión de procesos comerciales;

gestión, planificación, finanzas y contabilidad;

· gestión de personal;

Gestión de documentación;

· Gestion de logistica;

Gestionar las relaciones con los clientes y el entorno externo.

Además de lo anterior, es necesario establecer requisitos tecnológicos para la implementación de SI:

plataforma del sistema - implementación y adaptación solución lista desde el fabricante o desarrollo bajo pedido de acuerdo con las especificaciones técnicas del cliente;

Integrabilidad: los datos se almacenan y procesan en un único espacio de información; esto garantiza su integridad, coherencia, fiabilidad y reutilización; el sistema puede incluir tecnologías y aplicaciones recientemente desarrolladas y ya utilizadas;

adaptabilidad: el sistema se configura de acuerdo con los requisitos del cliente y las características del campo de información del cliente;

distribución: el sistema puede funcionar eficazmente en divisiones y sucursales de la empresa geográficamente remotas;

· escalabilidad: el sistema puede implementarse como un marco que contiene módulos básicos y complementarse de acuerdo con los requisitos de un entorno externo e interno cambiante.

Las principales fases de la implementación del sistema de información.

Fase "Trabajos preliminares de preparación del proyecto de implementación del IP". Durante la encuesta previa al proyecto de la empresa, se recopila información detallada sobre la organización estructural de la organización, las relaciones funcionales, el sistema de gestión, los principales procesos comerciales, los flujos dentro de la empresa (flujo de control, flujo de documentos, flujo de datos, Work Flow, Cash Flow), necesarios para construir modelos apropiados y selección de objetos para automatización. Se estiman los plazos, recursos, tipos y volúmenes de trabajo, la variedad y costo del software, hardware y telecomunicaciones, el costo de la capacitación del personal, etc.

Fase "Preparación del proyecto". Una vez finalizada la primera fase, se lleva a cabo la planificación preliminar y la formación de los procedimientos de lanzamiento del proyecto:

· formación de grupos de proyectos y de expertos;

distribución de poderes y responsabilidades;

determinación de requisitos organizativos y técnicos para el proceso de implementación;

aclaración de especificaciones y expectativas del cliente;

· formación del grupo de implantación, formado por especialistas de la empresa del cliente.

Por alguna razón, a menudo se pasa por alto el último punto, muy importante, al elaborar un plan de implementación. ¡Pero el éxito de todo el proyecto depende en gran medida de ello! Una vez iniciado el financiamiento, el proyecto se considera lanzado para su ejecución.

Fase “Estudio conceptual del proyecto”. Durante esta fase:

se forma y aprueba un diseño conceptual;

· se logra una comprensión inequívoca y obligatoria de las intenciones de todos los participantes del proyecto con respecto al SI implementado;

· aclara y concreta las metas y objetivos del proyecto;

se determinan las dimensiones del prototipo del sistema;

· se acuerdan el plan de trabajo consolidado, la secuencia de las etapas y las condiciones de la operación de prueba, los indicadores de planificación, financieros y de presentación de informes;

Sin embargo, todas las acciones anteriores sin fallar documentado, acordado y aprobado por todas las partes interesadas y responsables.

Fase "Implementación del proyecto". Durante el trabajo de implementación principal, se crea, instala y configura el entorno del sistema, se determinan los procedimientos de administración del sistema y se instalan los principales sistemas y aplicaciones de software y hardware. El sistema establece las estructuras organizativas, de personal, organizativas y funcionales de la empresa utilizando unidades organizativas como una sucursal, departamento, departamento, grupo de trabajo etc.

Se realiza la instalación, configuración y configuración de redes e instalaciones de telecomunicaciones, se transfieren datos del anterior sistemas locales y la formación de interfaces con sistemas heredados y externos. En este caso, todos los modelos, planos, productos de software en funcionamiento y documentación creados se colocan en el repositorio de un extremo a otro del proyecto de implementación (Fig. 3). Una parte importante de este repositorio es el sistema de documentación formado en el marco del proyecto (Fig. 4).

Se están resolviendo los problemas sistémicos de seguridad del funcionamiento del sistema en modo multiusuario. Se crean aplicaciones, plantillas, informes, formularios de acceso de clientes, se distribuyen poderes de usuario. Todos los sistemas se están probando en "modo combate" con la participación de todas las partes interesadas.

Una vez finalizada la fase de implementación, el proyecto de implementación se considera completado. Se pone en funcionamiento el sistema de información.

7. Factores de éxito y razones del fracaso de las implementaciones de propiedad intelectual

modelado reingeniería de información empresarial

Según las estadísticas mundiales, sólo un tercio de los proyectos de desarrollo e implementación de sistemas de información tienen éxito. No se sabe nada sobre estudios similares en Rusia, pero parece que aquí las cosas son aún peores.

Un proyecto exitoso se completa a tiempo, dentro del presupuesto planificado y se logran los resultados previstos. ¿Qué pasa con otros proyectos? O se prolongan mucho más de lo esperado y requieren cada vez más financiación, o se crea un sistema automatizado que nadie necesita y nadie quiere ni puede trabajar con él.

Los proyectos fallidos son muy similares entre sí. Parecen copiarse unos a otros, jugando el mismo escenario. Años de observación de malas prácticas me llevaron a escribir algunas reglas para que los líderes empresariales los ayuden a evitar las más errores comunes en la implementación de la automatización de la gestión empresarial. Son igualmente adecuados para proyectos de automatización de presupuestos, contabilidad de gestión, gestión de producción y otros campos. gobierno corporativo.

Cabe recalcar que estos consejos están dirigidos principalmente a la alta dirección de la organización, es decir, al propietario o director general de la empresa, quienes actúan como ?clientes? cambios en el campo del gobierno corporativo, incluida la creación de sistemas automatizados. ¿Malentendido por parte de personas de alto nivel? su papel en tales proyectos es la principal razón del fracaso de tales empresas.

Primero. Definir el propósito del proyecto.

Según las mismas estadísticas, el setenta por ciento de los proyectos fallidos lo fueron debido a la incertidumbre de sus objetivos. En otras palabras, el resultado final no estuvo claramente definido desde el principio.

Un ejemplo de la práctica. El jefe del servicio de tecnología de la información de un gran holding recibe del director general la tarea de implementar un sistema automatizado para proporcionar al más alto nivel de la dirección corporativa información oportuna y confiable. CIO en busca software adecuado para resolver las tareas, se refiere a consultores. A nuestra pregunta sobre qué problemas impulsaron a la dirección de la empresa a implementar un sistema automatizado, se da la siguiente respuesta:

Falta de un formato unificado para la presentación de datos de contabilidad de gestión.

Falta de normativa para la formación de informes de gestión.

falta de un entorno de información unificado

Está claro que los dos primeros?problemas? no están relacionados con la automatización, y esta última no supone un problema, ya que la existencia de un ?entorno de información unificado? en sí mismo no uso práctico no representa.

El conocimiento de la situación real de la empresa nos llevó a comprender que existe un problema al delegar los poderes del director de la corporación a los gerentes de las unidades de negocio. Debe solucionarse con la ayuda de un control basado en una planificación periódica y una contabilidad de gestión, así como con la correcta motivación de los directivos. En otras palabras, ¿deberíamos hablar primero de establecer procesos de gestión a nivel corporativo, y sólo después? sobre la automatización de estos procesos. Al darse cuenta de esto, los líderes de la empresa ahorraron mucho dinero al abandonar la automatización inútil.

Una comprensión profunda de los objetivos del proyecto puede llevar al rechazo de su implementación o al aplazamiento de sus plazos debido a la revisión de prioridades.

Los objetivos de automatización deben formularse no en términos de ventajas técnicas sino en términos de intereses comerciales. Se pueden definir, por ejemplo, de la siguiente manera:

· reducción de existencias en el almacén debido a una planificación más exacta de la producción y las compras;

Reducir cuentas por cobrar soporte de información trabajar con deudores;

· implementación de un mayor número de proyectos de inversión debido a la exclusión de operaciones rutinarias realizadas por administradores calificados.

Esta definición de objetivos le permitirá comprender por qué está haciendo esto, cuánto está dispuesto a pagar para resolver estos problemas y, muy importante, obtener criterios de éxito del proyecto con los que pueda evaluar los resultados finales.

Segundo. Abrir un proyecto

Implementación de un sistema automatizado. es un proyecto estratégico de la empresa. Deberá ser abierta por orden del Director General. La orden define los objetivos y plazos del proyecto, nombra un director de proyecto.

Un ejemplo de la práctica. El director de un gran banco encarga al director de gestión financiera que se encargue de implementar un sistema presupuestario. A pesar de que ha pasado más de un año desde el nombramiento, el director designado no comprende qué poderes tiene en relación con este encargo, qué resultados y en qué plazos se esperan de él. El proyecto parece existir, pero las cosas no avanzan.

En otras palabras, ¿es necesario entender claramente de qué se trata el proyecto? es una estructura organizacional completa, creada temporalmente dentro de la organización para lograr objetivos bien definidos.

El líder designado por el director general forma el equipo del proyecto. Debe incluir jefes de departamento y especialistas interesados en el resultado final y competentes en el área temática del proyecto. Entonces, si se implementa un sistema de presupuestación, el equipo del proyecto está formado por gerentes y especialistas de servicios financieros y de TI, así como representantes de los departamentos de producción y ventas. El director del proyecto debe ser un directivo que ocupe una posición más alta en la estructura organizativa de la empresa que cualquier miembro del equipo del proyecto.

Tercero. Dotar de recursos al proyecto.

Recursos clave Es dinero y gente. Por tanto, es necesario aprobar el presupuesto del proyecto.

Calificación recursos necesarios- no es una tarea fácil y, sin embargo, en la etapa de justificación del proyecto es importante comprender qué presupuesto se considera aceptable para el desarrollo. tecnologías de gestión e introducción de un sistema automatizado. El caso es que la solución a cualquier problema es un triángulo: dinero - tiempo - resultado. Si el resultado deseado está definido con precisión, entonces es posible calcular el tiempo necesario para lograrlo y el presupuesto. Si no hay una idea clara de qué es un "buen resultado" (es decir, los objetivos del proyecto no están definidos con precisión), entonces puede partir del presupuesto y resolver el problema de esta forma: cuál es el máximo efecto de gestión. ¿Se puede lograr si se invierte una determinada cantidad en establecer procesos de gestión e implementación de tecnologías de la información?

Además, es importante destinar una parte del tiempo de trabajo de las personas involucradas en el proyecto a realizar trabajos relacionados con la implementación del sistema. ¿De lo contrario?¿volumen de negocios? arruinar el negocio. Es una práctica generalizada que se asignen empleados para implementar nuevo sistema controles ?opcionales?. Dado que su carga de trabajo principal no se reduce, consideran el trabajo adicional como un hobby o como una carga molesta, dependiendo de su grado de interés. Esta actitud es bastante natural, porque la dirección de la empresa, tras haberles confiado tareas no remuneradas trabajo extra, demostró su propia actitud hacia ella, como algo secundario.

Control por recursos humanos El proyecto consiste en presupuestar el tiempo de los artistas. La contabilidad del tiempo real invertido es necesaria no sólo para una remuneración adecuada de los artistas, sino también para una evaluación correcta de los costes del proyecto.

Cuatro. Cuida la motivación

Motivación- un elemento clave de la gestión, por lo que se debe considerar cuidadosamente el esquema de motivación para los ejecutores del proyecto. No tienen por qué ser grandes bonificaciones por la implementación exitosa del sistema.

Muy a menudo, la introducción de un nuevo sistema de gestión ayuda a mejorar el estatus de los participantes en este trabajo y aumenta su nivel profesional. Se trata de incentivos muy importantes. El caso es que las personas creativas consideran el trabajo como un medio para incrementar su capital intelectual. Estos especialistas son los más valiosos para cualquier negocio relacionado con la innovación.

Es importante que el gerente que forma el equipo del proyecto comprenda correctamente las expectativas de los ejecutores asociadas con el éxito de este negocio. Podría ser carrera, aumento salarial, adquisición de nuevos conocimientos, alcanzar nuevas alturas en el crecimiento profesional.

Quinto. Apoyo de la gerencia

El éxito sólo es posible si el proyecto cuenta con el firme apoyo de la alta dirección de la empresa. Si CEO considera que la introducción de un sistema automatizado- Esto es sólo un negocio de servicios de TI, entonces no saldrá nada bueno de ello.

implementar tecnologías de la información- significa no sólo instalar programas en los lugares de trabajo. Dichos proyectos están asociados con un cambio en los procesos de trabajo y gestión, redistribución de responsabilidad y autoridad. Estos cambios a menudo entran en conflicto con los intereses de determinados jefes de departamento y empleados. El resultado es un sabotaje o una oposición abierta al cambio. Por tanto, el responsable de la organización debe mostrar claramente de qué lado está y, si es necesario, aplastar la resistencia con mano firme, apoyando al equipo del proyecto.

Sexto. Dividir el proyecto en etapas.

Lo mejor es un proyecto a largo plazo"cortar en pedazos", y no pasar a la siguiente etapa sin asegurarse de que las tareas de la etapa anterior estén completamente completadas. Es muy importante determinar cuál debe ser el resultado de cada etapa del proyecto.

Así, por ejemplo, cuando se trata de crear un sistema automatizado de gestión presupuestaria, se recomienda la secuencia de pasos que se muestra en la figura.

Puede pasar a la siguiente etapa solo después de que se cumplan las tres condiciones siguientes:

· el equipo del proyecto ha desarrollado un entendimiento común de los resultados de la etapa;

· este entendimiento se formaliza en forma de documento;

Los resultados de la etapa son aceptados por el cliente, es decir, el responsable de la empresa.

Este enfoque permite controlar los riesgos del proyecto, avanzando progresivamente hacia el objetivo previsto.

Séptimo. Gestionar objetivos y expectativas.

Los objetivos del proyecto pueden ajustarse o incluso cambiarse significativamente en el transcurso del trabajo. Esta es una práctica común. La situación cambia, nuestra comprensión de la situación cambia y llegamos a la conclusión de que nuestras opiniones anteriores están obsoletas o eran erróneas. Por lo tanto, es necesario volver periódicamente (en cada etapa del proyecto) a los orígenes. y examinar críticamente todas las premisas subyacentes.

Y el último. Es necesario tener el coraje de cerrar el proyecto si queda claro que ha llegado a un callejón sin salida. El director de proyecto que inició la terminación de un proyecto desesperado merece aliento como director responsable que evitó el despilfarro de fondos empresariales.

Fase "Preparación del proyecto". Una vez finalizada la primera fase, se lleva a cabo la planificación preliminar y la formación de los procedimientos de lanzamiento del proyecto:

formación de grupos de proyectos y de expertos;

distribución de poderes y responsabilidades;

determinación de requisitos organizativos y técnicos para el proceso de implementación;

aclaración de especificaciones y expectativas del cliente;

formación del grupo implementador, formado por especialistas de la empresa del cliente.

Fase “Estudio conceptual del proyecto”. Durante esta fase:

se forma y aprueba un diseño conceptual;

se logra una comprensión inequívoca y obligatoria de las intenciones de todos los participantes del proyecto con respecto al SI implementado;

se aclaran y concretan las metas y objetivos del proyecto;

se determinan las dimensiones del prototipo del sistema;

se acuerda un plan de trabajo ampliado, una secuencia de etapas y condiciones para la operación de prueba, indicadores de planificación, financieros y de presentación de informes;

Al mismo tiempo, todas estas acciones son necesariamente documentadas, acordadas y aprobadas por todas las partes interesadas y responsables.

Arroz. 3. Contenido aproximado del repositorio del proyecto de implementación.

Se lleva a cabo la instalación, configuración y configuración de redes e instalaciones de telecomunicaciones, se transfieren datos de sistemas locales anteriores y se forman interfaces con sistemas heredados y externos. En este caso, todos los modelos, planos, productos de software en funcionamiento y documentación creados se colocan en el repositorio de un extremo a otro del proyecto de implementación (Fig. 3). Una parte importante de este repositorio es el sistema de documentación formado en el marco del proyecto (Fig. 4).

Arroz. 4 Composición aproximada de la documentación sobre el proceso de implementación de SI.

Una vez finalizada la fase de implementación, el proyecto de implementación se considera completado. Se pone en funcionamiento el sistema de información.