Seis señales de advertencia más de que su proyecto tecnológico podría fallar

Dans la première partie de cet article, j'ai discuté de certains des pièges courants pour les administrateurs système qui sont soudainement entraînés dans des projets bien trop tard dans le jeu. Reconnaître ces signes avant-coureurs peut vous aider à anticiper si un projet est en dificultad. Aquí, en la segunda parte, continuaré con los seis signos restantes y le proporcionaré una lista de verificación que puede usar para mejorar su vida como administrador del sistema.

Integración, una historia solitaria

Muchos POC se enfocan correctamente en el nuevo producto que trae muchas cosas buenas. Se realizan pruebas limitadas solo para ver cómo se integra el nuevo producto con algunos de los productos de software heredados. Muy pocos productos viven sus vidas de forma aislada, por lo que se esperan muchos problemas de integración y dependencia, y no solo en una capa de primer nivel, sino también en una capa de segundo y quizás incluso de tercer nivel. Estas complejidades profundas y enredadas rara vez se prueban durante el POC. Espere que las pruebas de integración se centren en aquellas que son obvias y probablemente ya forman parte del nuevo producto de software. En producción, se debe integrar la pila compleja de software heredado, se deben desarrollar medios de comunicación o se deben inventar soluciones alternativas complejas.

Los administradores del sistema controlan todas las API en el panorama tecnológico. Junto con los propietarios y desarrolladores del sistema, se pueden revisar y explorar el impacto y las posibilidades.

Potencia y velocidad

Con los servicios en la nube, es fácil obtener rendimiento en todo el mundo y los servicios pueden recuperar más recursos cuando sea necesario. Parece que todos nuestros problemas con sistemas lentos y largos tiempos de respuesta se han ido para siempre. Como administrador de sistemas, sabe que las nuevas soluciones deben interactuar no solo con uno, sino probablemente con varios sistemas back-end que pueden estar ubicados en uno o más centros de datos. Esto significa que incluso si la nueva solución es ultrarrápida, la velocidad real está determinada por la rapidez de la comunicación con y entre los sistemas de back-end. Si esto no se prueba correctamente en el POC, seguramente aparecerá en producción.

Los administradores de sistemas, en colaboración con los desarrolladores, pueden proporcionar experiencia del mundo real para anticipar el rendimiento esperado y también indicar qué cambios podrían ser necesarios para cumplir con las expectativas de nuevos productos de software.

NIH - No inventado aquí

Esta sección analiza la política interna de la empresa de tratar de introducir un nuevo producto en la empresa. El hecho de que a un departamento se le ocurrió la idea y a otro no, puede ser suficiente para generar animosidad y actividad contraproducente. Lo mismo ocurre con TI que llega demasiado tarde en el proceso, lo que puede llevar a centrarse en encontrar fallas en lugar de soluciones.

Los administradores de sistemas deben tener el aplomo y la visión para ver más allá de estas cosas y ceñirse a los hechos. Al final, es la contribución más valiosa la que impulsa el proyecto.

El servicio de asistencia no sabe nada

Cuando la solución está en producción y el proveedor acaba de cerrar sesión, las rutinas diarias se dejan en silencio en el escritorio del administrador del sistema. Alrededor de este tiempo, alguien se da cuenta de que sería bueno informar a la mesa de ayuda que hay una nueva solución en producción y que deben cuidarla. Entonces, todo lo que tiene que hacer es enviar algunos documentos y el servicio de asistencia técnica se encargará del resto. Por supuesto, esto no es razonable. El administrador de la mesa de ayuda (subcontratado o interno) debe garantizar la disponibilidad y la documentación suficientes del sistema (CMDB, directorios, flujos de trabajo, contratos de soporte, etc.) y programar la capacitación del equipo del servicio de soporte.

El soporte localizado en diferentes idiomas y zonas horarias también podría estar en la agenda. Entonces, como administrador del sistema, probablemente sea responsable de configurar o reestructurar las cuentas y los grupos que necesitan acceso a la nueva solución. Si aún no lo ha hecho, es probable que deba crear un desafío de primera respuesta para que el equipo de soporte realice un seguimiento para ayudarlos a identificar posibles problemas técnicos.

El servicio de asistencia puede ayudar si puede, lo que significa que debe participar en el POC para asegurarse de que esté listo cuando el nuevo software entre en producción.

La solución es tan intuitiva.

Siempre que la formación no se considere necesaria, sabe que la organización de soporte (y usted como administrador del sistema) sufre las consecuencias. Además, no existe un plan sobre cómo implementar la solución en la organización o cómo garantizar que la organización adopte y utilice de manera efectiva la nueva solución. La mesa de ayuda se beneficiará de la formación de un grupo de superusuarios regionales o locales que, a su vez, pueden brindar soporte inicial a los usuarios locales. También es una excelente manera de crear comunidades localizadas en torno a la nueva solución. El desafío de no educar a los usuarios también es que sus expectativas van de todo a nada, lo que ejerce aún más presión sobre los administradores y desarrolladores de sistemas.

Como administrador del sistema, debe asegurarse de que los límites del nuevo producto de software estén definidos; de lo contrario, deberá admitir la conectividad móvil en una región y las soluciones de fax en otra.

no salió nada

Están llegando nuevas soluciones, pero las aplicaciones más antiguas no se están retirando. Esto significa que cualquier producto anterior que proporcione parte o la mayor parte de la funcionalidad proporcionada por la nueva solución permanece dentro de la organización y se sigue utilizando.

Entonces, en lugar de un desafío con una nueva solución, ahora tiene varias. La comunidad de usuarios está inevitablemente dividida entre la solución antigua y la nueva. Esto significa que la nueva solución también ha contribuido a la complejidad y confusión, sin mencionar el costo. Soporte, licencia, respaldo, antivirus, etc. debe funcionar por duplicado para admitir ambas soluciones que proporcionan la misma solución o una similar.

Desde la perspectiva del administrador del sistema, es importante hacer preguntas al principio del proceso sobre qué soluciones se retirarán como resultado del uso de la nueva solución de software. Esto brinda un mejor equilibrio y ayuda a mantener el panorama técnico actualizado.

Envoltura

Los nuevos productos de software son excelentes y tienen el potencial de hacer avanzar todo el negocio y proporcionar muchas ventajas competitivas. Si se implementan de manera incorrecta, pueden causar confusión y demoras. La solución podría traer sorpresas financieras desagradables y costos vertiginosos. También podría aumentar la complejidad y agregar una carga de trabajo innecesaria.

Uno de mis puntos clave es que, como administrador del sistema, debe participar desde el inicio de un proyecto de implementación de software para ayudar a su organización a evitar muchas de las advertencias descritas en este documento. Hay potencialmente más problemas, y algunos específicos de su negocio, pero con este documento puede al menos rastrear algunos de los eventos más importantes y potencialmente dañinos.

Los dejo con una lista de verificación de advertencia para proyectos de TI. Agregué mi propia puntuación subjetiva a cada elemento de línea para que pueda sumar y ver dónde terminan sus proyectos actuales. Las acciones sugeridas siguen la lista de verificación.

Lista de verificación de advertencias de proyectos de TI:

❏ El administrador de TI y/o del sistema no está involucrado por adelantado [2 points]
❏ Proyecto activo por más de 6 meses sin administrador de sistema/SME involucrado [2 points]
❏ Cambios sustanciales al producto original [2 points]
❏ Cambios no documentados [1 point]
❏ La localización (zona horaria e idioma) no forma parte del POC [1 point]
❏ Análisis de riesgos y oportunidades no realizado [1 point]
❏ Falta el análisis financiero de la producción a gran escala [1 point]
❏ La prueba no refleja la producción [2 points]
❏ POC convertido en producción [10 points]
❏ Sin cambio a producción [2 points]
❏ Falta de planificación de la gestión del ciclo de vida [1 point]
❏ Copia de seguridad no tenida en cuenta [1 point]
❏ Antivirus no tenido en cuenta [2 points]
❏ No se tiene en cuenta la seguridad, no interviene el servicio de seguridad [5 points]
❏ Integraciones no completamente probadas o ni siquiera posibles [2 points]
❏ La política no se inventa aquí [1 point]
❏ Mesa de ayuda desinformada [2 points]
❏ No se requiere capacitación del usuario [1 point]
❏ No sale nada [5 points]

Mi opinión sobre el proyecto de TI en base a la puntuación acumulada:
0 - 5 Accione los elementos de línea que generaron puntos y el proyecto debería funcionar bien
5 - 10 Esto dolerá, pero el proyecto se puede salvar con un esfuerzo significativo
> 10 Tire del freno de inmediato o el costo se disparará hasta el colapso inevitable

Artículos de interés

Subir