Hola a todos, he estado trabajando en el negocio de TI (en la parte que se ocupa de la creación de sistemas de TI) durante más de 20 años. Quería resumir la experiencia en algunos consejos para el cliente sobre cómo hacer que la automatización de la organización sea un proyecto eficaz y exitoso.
Sobre los objetivos y límites del proyecto.
Comencemos definiendo los objetivos que desea alcanzar implementando un proyecto de TI. En última instancia, TI no es más que tecnología con sus capacidades. Pero la creación de un sistema de información no puede ser un fin en sí mismo. El objetivo debe establecerse en términos de su negocio.
Consejo: Si está pensando en un proyecto de TI a gran escala que cubra muchas áreas de su empresa, asegúrese de que el objetivo se acuerde con la primera persona e incluso con la Junta Directiva, si corresponde. Es mejor atraer la atención de la gerencia al proyecto lo antes posible.
Después de establecer la meta, es necesario decidir qué procesos de actividad se verán afectados como parte de la implementación del sistema de información. La automatización es siempre un proceso de cambio de procesos de actividad. Seguramente todos escucharon la frase "no se puede automatizar un desastre". Y realmente lo es. La implementación de un sistema de información requerirá que defina más claramente los procesos de actividad, los métodos de toma de decisiones, de lo que es posible sin la automatización. Es cierto que, como resultado, obtendrá reglas de trabajo más claras y resultados comerciales predecibles.
La definición de procesos de actividad automatizada es la designación de los límites organizacionales (en términos de personas, departamentos) y funcionales (conjunto de funciones que determinan el proceso) de un proyecto futuro.
Consejo: en el proceso, piense en los límites del proyecto. Muy a menudo, al diseñar un sistema de información, quiero "automatizar este tipo de trabajo, e incluso este". Intenta no permitir esto. Cada nueva característica es una cantidad adicional de trabajo para usted y los contratistas.
Sobre el grupo de trabajo
Después de haber determinado qué procesos afectará el proyecto de TI, ¡necesita un grupo de trabajo! Debe incluir a los empleados de la organización que son responsables de la implementación de los mismos procesos que afectará la automatización.
El grupo de trabajo debe determinar los objetivos comerciales del proyecto y los requisitos funcionales para el sistema de información que desea recibir.
Consejo: Por eso hablé antes sobre la necesidad de alinear los objetivos del proyecto con la primera persona de la compañía. En la etapa de formación del grupo de trabajo, los colegas pueden resistir cambios futuros. Esto es normal! Pero uno debe estar preparado para esto. Por ejemplo, al acordar los objetivos de un proyecto de TI, puede discutir el tema de motivar a los participantes con la gerencia.
Formación de requisitos para un sistema automatizado.
¿Cómo agilizar la discusión sobre tareas de automatización y requisitos funcionales? Hay dos enfoques:
1. Si los procesos que decide automatizar son bastante típicos, puede involucrar a profesionales en la discusión: una empresa de TI que tenga experiencia en la automatización de procesos similares. Le dirán qué tareas se están resolviendo, qué procesos se ven afectados y expresarán los requisitos funcionales. Y solo editas esa lista por ti mismo.
2. Seleccione del grupo de trabajo al principal experto de la industria cuyas actividades se verán más afectadas. Y escriba la primera versión de las tareas y los requisitos funcionales junto con él.
Lo principal es obtener el primer borrador de tareas y funciones, y luego aclararlo, y no esperar a que el grupo de trabajo lo forme. La verdad básica siempre es más fácil de criticar que de inventar.
El siguiente paso es la formación de requisitos técnicos.
Aquí necesita el director de TI de la empresa. Su tarea es proporcionar información sobre cómo realizar adecuadamente un proyecto de TI (en qué servidores, con qué canales de comunicación, bajo el control de qué sistema operativo, en qué lenguajes de programación, utilizando qué productos de software). O brinde requisitos a todo lo anterior, según su comprensión del panorama de TI de su empresa.
Cuando realizamos estos pasos, consideramos que tenemos una tarea técnica para un proyecto de TI.
Selección de contratista
Luego viene el turno de la etapa de organización: la elección del contratista de la empresa. En el mundo moderno, este proceso está organizado como un procedimiento competitivo.
- Si usted es una empresa estatal y el sistema de información se crea a partir del presupuesto estatal, tiene 44 Leyes federales. De hecho, regula todas las reglas de la competencia.
- Si usted es una empresa con participación estatal, entonces actúa de acuerdo con 223 Leyes Federales y sus propios reglamentos de adquisición.
- Finalmente, si es una empresa privada, tiene una declaración de adquisición.
No puede haber un consejo universal. Pero le recomiendo que incluso su disposición de adquisición no lo requiera,
indique el precio máximo inicial del contrato y limite el porcentaje permitido de desviación del mismo . Por qué Sí, debido a todos los requisitos que usted escribió: cada posible postor leerá a su manera. O aparecerá una compañía que decide qué es importante para ella no hacer, sino solo para obtener un contrato.
Bicicleta: una empresa (no puedo nombrar) decidió hacer un recurso de información para todo el país. Esta no es una estructura estatal, y el liderazgo no limitó la bifurcación de precios asequibles, queriendo obtener tantas opciones como sea posible.
75 empresas llegaron a la competencia. El cliente recibió propuestas para la implementación de su TK con un rango de precios de 3 millones de rublos a 300 millones de rublos. Y no pudo tomar una decisión. La competencia fue cancelada, las tareas no fueron resueltas.
Consejo: cuando planifique el momento del proyecto, recuerde que los procedimientos competitivos generalmente demoran aproximadamente un mes.
Digresión sobre los tipos de proyectos de TI
Antes de hablar sobre las características de la implementación de nuestro proyecto de TI, debemos tomar un breve descanso y estipular que los proyectos de TI en realidad son diferentes. Cuales?
Proyectos de infraestructura de TIUn proyecto de TI puede centrarse en construir o actualizar su infraestructura de TI. Lo que se llama coloquialmente "pero compremos servidores e impresoras".
Proyectos de implementación de productos de softwareUn proyecto de TI puede consistir en presentar algún producto de software. Además, tanto "horizontales" como especializadas. Por "producto horizontal" en el mundo de TI nos referimos a un producto que, sin configuraciones adicionales, resuelve la tarea muy específica de automatizar una función específica, que es necesaria para todos los usuarios. Un gran ejemplo de tal producto es Microsoft Word. ¿Todos entendemos que Word es un sistema de información? Pero se acostumbraron al hecho de que se instala simplemente, y es fácil aprender esto. Esto se debe precisamente a que el sistema resuelve un problema limitado: escribir con formato, guardar e imprimir. Y la tarea es universal.
Producto de software especializado. Un ejemplo es un sistema de contabilidad. Tal producto parece tener todas las funciones necesarias para la contabilidad ... ¡Pero! Cada empresa tiene su propio plan de cuentas, análisis de cuentas, participantes en los procesos de aprobación y aprobación de documentos contables ... Es decir, debe configurar el producto de software para su negocio.
Proyectos para desarrollar una solución única y su implementaciónTodavía hay proyectos de TI para la creación e implementación de sistemas de información únicos creados especialmente para su empresa. Y además hablaremos específicamente sobre los detalles de la gestión de proyectos de este tipo.
Consejo: Quiero llamar la atención sobre el hecho de que, incluso si necesita comprar impresoras en su organización, le recomiendo encarecidamente que formule los términos de referencia aproximadamente de la misma manera que le dije anteriormente. Esta es una fuente de ahorro. Dado que, comenzando a comprender por qué no hay suficientes impresoras, puede resultar que tenga muchas impresoras de red, que por alguna razón se usan como "personalmente alguien", y no necesita comprar equipos, sino simplemente cambiar la configuración. Saldrá mucho más barato. Creo que todos estarán de acuerdo conmigo.
Una nota sobre la complejidad del proyecto o los grandes sistemas de información.En el mundo de los sistemas de información corporativos, "grande" se llama un sistema que automatiza más de 10 procesos comerciales. Y si está creando un sistema de este tipo, es especialmente importante que comprenda cómo administrar un proyecto para su creación e implementación.
Implementación del proyecto. Trabajo del cliente
A continuación, hablaremos sobre un proyecto para crear e implementar un sistema de información con funciones únicas y específicas.
La competencia se lleva a cabo y usted tiene un ejecutor de proyectos de TI. Comienza la fase de implementación: en esta etapa, el grupo de trabajo (el que formuló las tareas funcionales) es aún más importante. Solo ahora incluirá representantes del artista intérprete o ejecutante.
Si el contratista es un profesional, sabe que es necesario comenzar el proyecto con una reunión general de todos los involucrados y la aprobación de la
Carta del proyecto . Y realmente lo es. Es la Carta del proyecto que le permite prescribir las reglas para la interacción de los equipos del contratista y el cliente. En TK y el contrato, en contraste con la Carta, generalmente no existen detalles como apellidos responsables de decisiones de diseño muy específicas.
Por lo tanto, es importante que los custodios del conocimiento sobre estas funciones específicas de su organización sean participantes activos en el proyecto. El riesgo de una participación insuficiente de los especialistas de la industria por parte del cliente es que, como resultado, el sistema de TI no tendrá en cuenta los detalles necesarios y, en el mejor de los casos, no podrá implementarlo (los empleados no podrán usarlo), y en el peor de los casos, la compañía simplemente perderá su ventaja competitiva en el mercado que tenía, pero que de repente no estaba automatizada ...
La empresa asociada para el desarrollo del sistema no siempre conoce su negocio. Los analistas expertos y desarrolladores por parte del contratista pueden escuchar atentamente sus deseos y ofrecer soluciones más óptimas en términos de los detalles de la automatización, pero no descubrir cómo llevar a cabo su negocio.
Sobre la gestión del desarrollo de un sistema de información
Quienes se han encontrado con los sistemas de TI probablemente han escuchado los términos
"desarrollo en cascada" (o "cascada") y ágil . Te contaré un poco más sobre la diferencia. Tradicionalmente en el mundo de TI, la estandarización de los enfoques de desarrollo ha llevado a una metodología en cascada para crear soluciones de TI. De hecho, debe admitir que cualquier estandarización tiene un objetivo: quien haga algo, el resultado será exactamente como se planificó. Un enfoque en cascada proporciona esto. Su esencia está en tres palabras: primero diseñaremos, describiremos en los documentos y luego escribiremos el código del programa, verificaremos cómo funciona con los documentos de la tarea técnica y el proyecto técnico, ¡y listo! Lo que querían, lo consiguieron. Parecería conveniente trabajar para todos los participantes del proyecto, tanto el contratista como el cliente. Solo hay un problema: el tiempo. Si bien todos hemos diseñado, el mundo ha cambiado, han aparecido nuevos tipos de actividades en su negocio, la dotación de personal ha cambiado, las áreas de responsabilidad se han redistribuido. Y el sistema en su forma anterior ahora no es realmente necesario.
¿Qué es ágil (o Scram)? Esta es una metodología para crear un sistema de TI en "piezas pequeñas", cuando dividimos la tarea en subtareas que se pueden desarrollar y probar en dos semanas, un mes. Esa es la idea. ¿Cuál es el truco? Es dividir la tarea en "piezas independientes". Por desgracia, eso casi nunca sucede.
Y resulta que ni el desarrollo en cascada ni Agile son una panacea. Entonces, sea lo que sea que se diga, la gestión de proyectos de TI requerirá el uso de ambos enfoques.
Organización del trabajo del lado del cliente, algunos consejos.
1. Antes de comenzar la “automatización de todo”, debe identificar tareas de alta prioridad (un conjunto de procesos donde la falta de automatización dificulta la vida).
2. Discuta dentro de la compañía cómo estos procesos automatizados intercambiarán información con los procesos comerciales relacionados.
Te lo explicaré. Decidió automatizar el flujo de trabajo, y sus colegas se dieron cuenta de que las cartas entrantes de la organización administradora se pierden. Usted toma una decisión: automatizar no todo el flujo de trabajo, sino solo el registro de los mensajes entrantes. En este caso, debe decidir si las entradas se registrarán electrónicamente y las salientes, no, ¿esto le conviene? ¿Y cómo funcionará? Si respondió estas preguntas, siéntase libre de hacer un proyecto para automatizar el proceso de registro de cartas entrantes. Este paso se llama
"Determinación de los límites funcionales del proyecto" . Después, también puede identificar específicamente a los participantes, es decir, los límites organizativos del proyecto y hacer que el proyecto sea visible. Para él será posible aplicar al menos un método en cascada, al menos ágil.
3. Si no se puede asignar un área de automatización tan pequeña, intente este enfoque: busque un contratista en la etapa de redacción de las especificaciones técnicas y ordene no solo especificaciones técnicas, sino también el desarrollo de diseños simples para las partes más importantes del sistema.
Recuerde: es importante garantizar el interés de liderazgo en el proyecto. Muéstrele los diseños de los paneles: cuando aprendan cómo obtener todos los datos para estos paneles claros, será más conveniente tomar decisiones. Esto ayudará a ahorrar años de trabajo y millones de rublos.
Por cierto, es genial crear prototipos de acuerdo con la metodología Agile. Puede resolver, crear, mostrar todo rápidamente y, si es necesario, ajustar las expectativas. De hecho, Agile surgió como una técnica de creación rápida de prototipos, y no en absoluto para crear sistemas de TI industriales y estables.
4. Para que la empresa utilice un determinado sistema de TI que cubra todos los procesos de actividad, el personal necesita un
Comité de Arquitectura permanente. Este es un grupo de sus empleados (esto es obligatorio) que supervisará la creación, el uso, los cambios, las innovaciones en el mercado, es decir, será responsable de la integridad y la ideología común. Por lo general, el comité es administrado por el CIO, pero también se deben incluir especialistas de la industria.
5. En TK, además de los requisitos funcionales y técnicos, siempre se presentan los requisitos de documentación, exactamente qué descripciones del sistema de TI debe proporcionar el contratista. Haga que esta parte de los requisitos sea óptima para su uso futuro.
Recuerde que el contratista puede cambiar, y si el sistema no está documentado, ¡el nuevo contratista comenzará desde cero!
El proceso de crear un sistema por una organización externa no significa que sus empleados "no hagan nada y estén esperando su implementación". Usted y el contratista están discutiendo documentos, decisiones de diseño privadas, resultados provisionales. Esto es importante de entender.
Si esto no se hace, el contratista automatizará sus ideas sobre su negocio, y no sobre el negocio en sí.
Quizás ya quiera hacer la pregunta: "Señor, ¿cuánto tiempo llevará el proyecto tiempo y dinero?". Sobre esto al final del material.
Ahora quiero hablar más sobre las
dos últimas etapas del ciclo de vida de un proyecto de TI: implementación y operación.Organización del proceso de implementación.
Entonces, el grupo de trabajo de gestión del proyecto, junto con el contratista, adoptó el sistema. ¿A dónde lo llevó y qué hacer a continuación?
Tradicionalmente, la primera aceptación significa el comienzo de la
operación de
prueba . A menudo se presta poca atención a este paso. Y él es importante. Idealmente, durante la operación de prueba, usted selecciona a 1-2 personas y las capacita en el sistema: póngalo en el lugar de trabajo (o dé acceso), y comenzarán a realizar parte del trabajo utilizando el nuevo sistema.
Tenga en cuenta que los viejos métodos para realizar sus tareas siguen vigentes. Es decir, ¡los participantes de la operación de prueba hacen doble trabajo! ¡No te olvides de motivarlos!
El propósito de la fase de operación piloto es asegurarse de que sea posible trabajar en el sistema. No da resultados y errores inesperados, es lo suficientemente conveniente para que ella lo use. Si hay errores, inconvenientes, algo más "incorrecto", se registran en el "Diario de la operación de prueba". El contratista debe eliminar los comentarios.
¿Qué hacer si resultó que no se trataba de comentarios mezquinos, sino que se olvidó de todo el proceso? Por desgracia, mi respuesta no va a agradar. Si esto se olvida en la etapa de los TdR, el contratista no corregirá el error por su cuenta. Porque él dirá que "ellos no pidieron esto" y él tendrá razón. Deberá discutir con el contratista la conclusión de un acuerdo adicional al contrato, términos adicionales y dinero.
Después de la operación de prueba, habrá empleados que podrán trabajar en el sistema de TI. Podrán ayudar a sus colegas a aprender una nueva forma de trabajo diario. La operación piloto generalmente dura de 1 a 3 meses.
Después de corregir las deficiencias identificadas por el contratista, el sistema es aceptado para
la operación comercial y se convierte en una solución de combate para hacer negocios. El acto de aceptación en la operación comercial completa formalmente el proyecto de TI.
Dos palabras sobre la capacitación del personal.
Recordamos que algunos de los empleados (participantes en la operación de prueba) ya han aprobado la capacitación organizada por el contratista. ¿Qué hacer con otros empleados?
Necesitan ser enseñados. Puede involucrar tanto a especialistas capacitados como a un contratista en este trabajo. Ambas opciones son aceptables. Solo recuerde que el proceso de aprendizaje siempre es "pagado". O paga explícitamente estos servicios al contratista, o tiene que distraer a su personal del trabajo principal para capacitar a sus colegas.
¿Cómo se puede y se debe optimizar este proceso? Pídale al intérprete que prepare lecciones en video, organice la capacitación en su organización, por ejemplo en su hogar, apruebe la prueba. Si incluye un puesto sobre la necesidad de desarrollar un curso de video con tareas de prueba en el contrato con el contratista, tendrá la oportunidad de capacitar a nuevos empleados durante todo el período de operación.
Otro punto organizativo que es importante recordar al llevar el sistema a operación comercial. Un acto es un acto, pero es importante pensar en el proceso de transición para trabajar en el nuevo sistema. Un ejemplo:
- Usted determina la fecha a partir de la cual se realizan TODAS las operaciones en el nuevo sistema. Por desgracia, la gente no es perfecta. Por lo tanto, le aconsejo que no solo establezca una fecha, sino que también proporcione una herramienta motivadora.
- Como regla general, dicha fecha no es "mañana después de firmar el acto", sino después de un período, generalmente llamado período de transición. Durante este período, la organización vive en dos mundos: el viejo y el nuevo. De hecho, el período de transición es como una operación de prueba extendida, solo con todos los usuarios.
Consejo y cuento: dado que las personas tienden a resistirse a lo nuevo, tenga en cuenta que los empleados no estarán contentos con el nuevo sistema. Dirán que nada está claro y que todo es lento, que con sus propias manos habrían hecho todo hace una hora. No se alarme, y recuerde que el objetivo de la automatización, por desgracia, no siempre es hacerlo "más rápido", sino siempre garantizar una transparencia y una contabilidad completas para todas las operaciones.
Te contaré un viejo pero efectivo ejemplo de motivación para la implementación. Se creó un sistema de gestión de ventas. En la etapa de implementación, los empleados no querían usarlo y continuaron emitiendo todas las facturas manualmente. El director de la empresa emitió un pedido interno: las facturas emitidas y pagadas fuera del sistema no se tendrán en cuenta al calcular la prima del vendedor. El sistema se implementó en 3 (!) Días! Sí, estos tres días fueron un infierno para el artista, se salieron un millón de defectos. Pero, aunque parecería ser un "representante del artista intérprete o ejecutante", le recomiendo encarecidamente que piense en esas formas de motivación.Dejaré la conversación sobre la organización del funcionamiento del sistema la próxima vez. Pero observo que el
mantenimiento del sistema después de la implementación también requiere un acuerdo , preferiblemente con el desarrollador. Este es un tipo de contrato separado que debe determinar cómo contactar al desarrollador si se encuentran errores, y las reglas de comportamiento con el desarrollador si algún proceso ha cambiado (o ha aparecido uno nuevo). Es decir, el contrato prescribe cómo corregir los errores y cómo planea desarrollar el sistema en conjunto. Este tipo de contrato se llama SLA (Service Level Agreement). Insisto en que este es un acuerdo por separado.
Algunas palabras sobre el costo y el tiempo
TI utiliza un enfoque universal para determinar el costo del trabajo, el llamado método de recursos. Se estima qué equipo de especialistas, en qué período de tiempo implementa el conjunto de funciones requerido. : (, ) 1 , 1 -, 1 , 2-3 , 1 «» . 3 . (, ) . . ? -, . hh. , , , …
: , , . . .
-, .
!