Procedimientos recomendados de sistema empresarial

Este artículo forma parte de nuestra colección "From the Trenches". Describe los procedimientos recomendados operativos para sistemas empresariales en general (incluido Microsoft Project Server). Explican cómo, a pesar de que los sistemas empresariales se esfuerzan por proporcionar una interfaz fácil de usar en el nivel de usuario, la tecnología y la infraestructura necesarias para lograrlo suelen ser muy complejas. También describen el modo en que esta complejidad requiere el uso de algunos procedimientos recomendados básicos que le ofrecen una buena oportunidad de mantener un alto grado de confiabilidad en el sistema empresarial.

Para descargar la versión de Word de este artículo, consulte Procedimientos recomendados de administración empresarial.

Para ver más artículos, consulte las notas del producto "Desde las trincheras".

Procedimientos recomendados de administración empresarial

En su mayoría escribo sobre sistemas de administración de hojas de horas empresariales o proyectos empresariales, y la fase más común de implementación de la que hablo con estos sistemas sería la fase de selección o configuración: hablar de la perspectiva estratégica. Este artículo trata mucho más sobre las prácticas operativas y no es específico solo para sistemas de parte de horas empresariales o de proyectos como Microsoft Project Server. En su lugar, se trata de los sistemas empresariales en general, aunque el tema puede relacionarse con casi todas las implementaciones de Project Server.

Cuando encontramos sistemas de Project Server ya implementados o hablamos con clientes existentes, a menudo hacemos preguntas sobre cómo la organización implementó y ha admitido el sistema y su entorno. Cuando comenzamos en el sector, estas eran conversaciones sencillas porque el software del proyecto que se instalaría siempre residía en el EQUIPO del usuario final, y el cuidado del sistema siempre era un concepto local. En estos días, rara vez es el caso. Los sistemas empresariales son sencillos en el nivel de interfaz o de presentación, donde los usuarios finales normalmente pueden acceder a la funcionalidad a través de un explorador web en lo que se parece a cualquier otra página web. Tan sencillo como estos sistemas podrían estar delante es tan complejo como en la parte posterior. La tecnología necesaria para mostrar esa interfaz probablemente tiene numerosas capas, depende de varios orígenes para la tecnología y la infraestructura, y (si eso no es suficiente) probablemente se esté actualizando todo el tiempo.

Sin embargo, hay algunos procedimientos recomendados básicos que pueden proporcionarle la mejor oportunidad de mantener un alto grado de confiabilidad en el sistema empresarial.

Búsqueda de un propietario

De hecho, tenemos que dividirlo en dos propietarios porque cualquier sistema empresarial exitoso tiene tanto un propietario empresarial como un propietario técnico. Solo cuando el propietario de la empresa es un ejecutivo en el departamento de TI y el sistema empresarial es principalmente para ese departamento, los propietarios pueden ser los mismos. Por lo tanto, vamos a tomar esto en dos partes:

Búsqueda de un propietario empresarial

Esta persona debe ser una persona de nivel ejecutivo o de alta dirección que tenga un interés adquirido en los resultados del sistema de gestión de proyectos. Los beneficios que el sistema debe ofrecer o los desafíos empresariales que el sistema debe superar tendrán que ser beneficios y desafíos que afecten directamente a este ejecutivo. Y, antes de que alguien lo diga; no, normalmente no puede ser un comité o varias personas.

La responsabilidad tiene que estar en algún lugar y eso casi siempre significa una persona. Esta persona también podría ser el patrocinador ejecutivo para la implementación del sistema, pero podría no serlo. A menudo, el patrocinador ejecutivo no es el propietario empresarial final de un sistema empresarial.

Incluso una vez finalizado el proyecto de implementación, el propietario de la empresa seguirá siendo el propietario del sistema y, en caso de que ya no lo requiera, debe identificarse otro propietario de la empresa y confirmarlo en el sistema o retirar el sistema.

Búsqueda de un propietario técnico

En el caso de los sistemas de nivel empresarial, solo tener un técnico disponible es insuficiente. Recuerde que los sistemas empresariales dependen de muchas capas de tecnología. El propietario técnico debe ser un gerente o ejecutivo suficientemente alto en el departamento de TI que pueda interactuar inmediatamente con los propietarios de esas otras capas de tecnología. Esto puede incluir personas de la tercera edad propietarias de la base de datos de SQL Server, el servidor de bases de datos en el que está instalado SQL Server, los servidores de aplicaciones en los que está instalado Project Server, las redes, el servidor web o la granja de servidores, la conexión a Internet, el firewall, los servidores de Active Directory y Exchange, los servidores o sistemas de seguridad y la imagen del sistema operativo de nivel de cliente. Alguien de alto nivel debe ser capaz de representar este sistema empresarial a aquellos administradores que controlan otros aspectos del entorno.

Ser intencionado

Asegúrese de que Project Server a) tiene un propósito y b) está cumpliendo su propósito. ¿Suena obvio? No lo es. Con demasiada frecuencia, los sistemas empresariales se adquieren por una razón incorrecta y es a alguien de TI a quien corresponde buscar un propósito al que aplicar el sistema. La persona que firma con el propósito empresarial para el sistema empresarial debe ser el propietario de la empresa, aunque otros podrían estar implicados. Siempre hago a estos ejecutivos una pregunta que he usado durante años: "¿Qué decisión empresarial puede tomar ahora o solo puede hacer con gran dificultad, la toma de la que se habilitará mediante la implementación de este sistema?" Una vez que se haya establecido el requisito empresarial (tenga en cuenta que no he dicho la funcionalidad deseada), asegúrese de que el sistema empresarial cumple realmente ese requisito. Me encuentro con mucha gente que tiene una lista de compras de funciones pero poco comprensión de lo que están tratando de lograr con ellos.

A medida que la organización evoluciona, asegúrese de que el propietario de la empresa vuelve a este concepto básico. Solo la implementación de un sistema empresarial como Project Server puede modificar fundamentalmente la empresa en la que se implementa, por lo que no es de extrañar que los requisitos de la organización para un sistema puedan cambiar.

Es habitual entrar en una organización varios años después de la adopción y la implementación de Project Server solo para encontrar a alguien que sepa por qué es importante para la organización. El sistema está en uso para estar seguro. Se está llevando a cabo por inercia, pero el propósito se ha perdido y los ejecutivos que se benefician de él cada día no se dan cuenta de dónde proviene ese beneficio.

Introducción a la arquitectura empresarial

Hace varios años recuerdo ir con uno de nuestros técnicos a la ubicación de un cliente molesto. La instancia de Project Server que se habían instalado ellos mismos provocaba todo tipo de problemas. Mientras estábamos allí en persona, pedimos entrevistar a un número de personal técnico, rastreando el sistema a través de sus capas. Cuando llegamos a la capa de base de datos, nos quedamos atónitos. En lugar de ser uno de los servidores de base de datos estándar de la organización, la versión SQL Server en la que habían instalado el sistema estaba en el equipo de un usuario final. Cada vez que se reinician, apagan o instalan algo en el equipo, la base de datos deja de estar disponible. Esto afectó literalmente a cientos de usuarios finales.

La organización era grande, por lo que no faltaba la infraestructura ni los servidores empresariales en los que confiar. En este caso, el problema se corrigió fácilmente. Sin embargo, fue una buena lección. ¿El sistema en el que se está implementando se está entrelazando en la infraestructura corporativa existente en la que la organización puede haber dedicado un enorme esfuerzo a ser estable, confiable y segura?

Hacer una copia de seguridad

Lo sé. Esto es tonto, ¿verdad? Increíblemente y desafortunadamente no lo es. Los sistemas empresariales pueden ser notoriamente complejos para realizar copias de seguridad, ya que pueden depender de varios aspectos del sistema de los que se va a realizar una copia de seguridad al mismo tiempo. Por supuesto, están los datos básicos, pero también los metadatos y los datos de configuración de la implementación. Y los datos relacionados de sistemas auxiliares que puedan tener que coincidir con el sistema pueden tener que formar parte del mismo esquema de copia de seguridad. Cuando pensamos en Project Server, tenemos que pensar en la copia de seguridad no solo de las bases de datos del proyecto, sino también de la base de datos de SharePoint Server. En las versiones de Project Server anteriores a 2010, es posible que debamos hacer una copia de seguridad de la plantilla global. Incluso ahora puede haber elementos de plantillas que se encuentran en equipos individuales.

Y simplemente hacer copias de seguridad no es suficiente. Cuando los sistemas cambien o se actualicen, realice una restauración de base de datos al menos una vez. Recuerdo que hace años estaba con un cliente para el que habíamos ayudado a diseñar una estrategia de copia de seguridad. Él cerró el servidor, sacó el disco duro, puso en otro disco duro y luego nos miró y dijo "Allí. El disco duro se ha bloqueado. Es un disco duro recién formateado. Restaure mi Project Server." Me tomaron de vuelta, pero más porque me di cuenta de lo buena que era una solicitud, y cuanto más lo pensé, más me di cuenta de lo impactante que era que nadie había hecho la solicitud antes (o desde). Por lo tanto, realice una prueba de restauración al menos una vez. Pudimos restaurar ese sistema por cierto, pero no volvió tan limpio como sospechamos que lo haría y tuvimos que actualizar los procedimientos de copia de seguridad.

Ensayo/producción

"Todo el mundo es un escenario, y todos los hombres y mujeres simplemente jugadores", dijo Shakespeare hace mucho tiempo. En este caso, la fase se trata más sobre el almacenamiento provisional y eso es clave para cualquier sistema empresarial. Una vez que el sistema esté en producción, querrá probar nuevas configuraciones, agregar nuevas personalizaciones, probar nuevos informes, vínculos, campos y otros cambios. Tendrá actualizaciones y actualizaciones, y todas ellas se deben probar primero en un entorno de ensayo o desarrollo antes de que se infligan a los usuarios en el entorno de producción. Algo tan básico como una actualización del explorador o una actualización de base de datos puede producir sistemas empresariales para un bucle, así que asegúrese de mantener y mantener un entorno de ensayo independiente de un entorno de producción. En este día y en la era de los servidores virtuales, esto puede ser más fácil de lo que podría haber sido en el pasado. Ahora se puede clonar un entorno completo desde el sistema de producción, pero puede ser más fácil decirlo que hacerlo en función de cómo se haya implementado. Recuerde que se puede hacer referencia a muchas partes diferentes del rompecabezas de tecnología aunque haya copiado un servidor completo.

Supervisión, supervisión, supervisión

Hay muchos puntos de supervisión que se pueden usar para supervisar un sistema empresarial. En primer lugar, es esencial asegurarse de que Project Server esté disponible para los usuarios finales y de que el personal técnico adecuado reciba una notificación lo antes posible si no está disponible. Afortunadamente, hay muchas herramientas en el mercado para garantizar que el sistema es funcional y disponible que puede notificar automáticamente al personal técnico incluso si los usuarios finales aún no se han dado cuenta del problema. Pero hay otros aspectos de la supervisión que también son importantes. Es bueno mantener un reloj y un registro del estado de la aplicación, incluida la cantidad de memoria que está usando, la cantidad de CPU que está ocupando, los errores que el sistema puede haber notificado incluso si se recuperó de ellos mismos, los reinicios del servidor requeridos y el estado pertinente de otros elementos de la infraestructura técnica. Saber, por ejemplo, que IIS tiene problemas técnicos puede ser muy importante para mantener la disponibilidad de la aplicación empresarial.

Incluso los cambios pequeños son cambios

La tecnología en la que se basa Project Server cambia día a día. Es imposible evitar todos estos cambios. El sistema operativo Windows Server suele recibir actualizaciones cada pocos días, SQL Server pueden recibir actualizaciones cada pocas semanas. Los sistemas operativos cliente de Windows individuales, sus escáneres de virus, firewalls e Internet Explorer y sus complementos obtienen actualizaciones de forma periódica. Cualquier parte de la cadena entre los datos y el usuario final es un punto potencial en el que la aplicación puede dividirse, por lo que cree una estructura para administrar los cambios en toda la pila de tecnología.

Esto puede ser un desafío, ya que muchas aplicaciones empresariales diferentes pueden depender de aspectos similares de la pila. Teníamos un cliente que actualizaba inocentadamente Project Server hace un tiempo solo para descubrir que todo el entorno de SharePoint Server se ha derribado. Es evidente que se ha producido un error en la aplicación de la actualización de Project Server o SharePoint Server. Aunque había copias de seguridad completas y no se perdió ningún dato, el proceso de actualización no tenía un aprovisionamiento de reversión instantánea y, por lo tanto, los efectos eran devastadores, ya que tardaron días en revertirse.

En otra organización, teníamos un cliente que había actualizado otra aplicación empresarial para descubrir que requería que todos los usuarios actualizara su versión del explorador solo para descubrir que otras aplicaciones empresariales que ya estaban en uso en la empresa no admitían la versión más reciente del explorador. Era la roca y el lugar difícil. Al final, tuvieron que revertir la actualización del sistema empresarial y esperar a que todas las aplicaciones empresariales pudieran avanzar con una nueva actualización del explorador.

A veces es mejor tener un aspecto integrado que estar integrado

Las demostraciones de ventas siempre facilitan la integración de varias herramientas. ¡Hey presto, los datos comienzan aquí y terminan ahí! Establecer un vínculo entre herramientas altamente flexibles como Project Server y otros sistemas empresariales como Finance/ERP es lo suficientemente difícil, y siempre recomendamos que ambos sistemas estén en producción y sean estables antes de que se establezcan los vínculos. Una vez que están en curso, sin embargo, es aún más importante supervisar los cambios de los dos sistemas con la mente de asegurarse de que seguirán vinculen correctamente.

Con cualquier actualización de cualquiera de los sistemas, puede haber cambios de datos, cambios de estructura o requisitos técnicos diferentes. También puede haber nuevas características y ventajas posibles, pero asegúrese de que la funcionalidad de vinculación existente se pruebe en el entorno de ensayo antes de que se implemente en producción.

Documento, documento, documento

Las personas que estaban allí cuando se seleccionó e implementó Project Server no estarán en esos roles para siempre. De hecho, si hicieron un gran trabajo, no administrarán la siguiente implementación empresarial que necesita la organización. Por lo tanto, es esencial documentar las decisiones de configuración, las ventajas proyectadas, las expectativas operativas y los parámetros que se usaron para tomar esas decisiones. En el futuro, otros verán este sistema y se rascarán la cabeza diciendo: "¿Qué estaban pensando?". Asegúrate de decirles.

Los documentos del sistema empresarial deben ser documentos vivos que se actualicen con cada actualización, cada cambio en el propietario empresarial o técnico, o cualquier cambio importante en la estructura operativa o en los requisitos empresariales.

Mira antes de saltar

Es el consejo que le damos a la gente buceando en un lago turbio por primera vez. ¿Es superficial? ¿Hay rocas justo debajo de la superficie? Los sistemas de administración de proyectos empresariales, como Project Server, pueden incorporar elementos de datos complejos en un lugar donde las decisiones basadas en esos datos pueden ser más eficaces y las ventajas de esas decisiones pueden hacer una profunda diferencia en una organización. Pero debe hacer su tarea para asegurarse de que está operando el sistema empresarial de forma que pueda obtener los beneficios que necesita sin exponer a su organización a los costos y riesgos que pueden eliminar rápidamente el valor de esos beneficios.

Autor

Chris Vandersluis es el presidente y fundador de Montreal, HMS Software, un asociado certificado de Microsoft con sede en Canadá. Tiene una licenciatura en economía de la Universidad McGill y más de 30 años de experiencia en la automatización de sistemas de control de proyectos. Es un miembro de larga data del Project Management Institute (PMI) y ayudó a encontrar los capítulos de Montreal, Toronto y Quebec del Grupo de Usuarios de Microsoft Project (MPUG). Entre las publicaciones para las que Chris ha escrito se incluyen Fortune, Heavy Construction News, la revista Computing Canada y PMNetwork de PMI, y es columnista regular de Project Times. Enseña administración avanzada de proyectos en la Universidad McGill y a menudo habla en las funciones de asociación de administración de proyectos en Norteamérica y en todo el mundo. HMS Software es el editor del sistema de mantenimiento de tiempo orientado al proyecto TimeControl y ha sido asociado de soluciones de Microsoft Project desde 1995.

Chris Vandersluis puede ser contactado por correo electrónico en: chris.vandersluis@hms.ca

Si desea leer más artículos relacionados con EPM de Chris Vandersluis, consulte el sitio de orientación de EPM de HMS (https://www.epmguidance.com/?page_id=39).