Procedimientos recomendados para el sistema empresarial: notas del producto

Estas notas del producto forman parte de nuestra colección "Desde las trincheras". En el documento se describen los procedimientos recomendados de funcionamiento de los sistemas corporativos en general (incluidos Microsoft Project Server). Indica cómo. Anque los sistemas corporativos intentan proporcionar una interfaz fácil de usar al nivel de usuario, a menudo resultan muy complejas la tecnología y la infraestructura necesarias para proporcionarlos. Así pues, estas notas de producto describen cómo esta complejidad requiere que el usuario utilice los procedimientos recomendados que le supongan la mejor oportunidad para mantener un alto grado de fiabilidad en su sistema empresarial.

Para descargar la versión de Word de estas notas de producto, consulte Procedimientos recomendados de administración empresarial.

Para ver más notas de producto, consulte las notas de producto "Desde las trincheras".

Procedimientos recomendados de administración empresarial

Generalmente escribo sobre sistemas de gestión de partes de horas o proyectos empresariales y la fase de desarrollo más común sobre la que suelo hablar en estos sistemas suele ser la fase de selección o configuración: hablamos de la perspectiva estratégica. Este artículo hace más referencia a los procedimientos de funcionamiento y no es exclusivo de sistemas de proyectos o partes de horas empresariales como Microsoft Project Server. En vez de eso, hace referencia a los sistemas empresariales en general, aunque el tema central puede relacionarse con casi todas las implementaciones de Project Server.

Cuando nos encontramos con sistemas de Project Server ya implementados o hablamos con clientes existentes, a menudo realizamos preguntas sobre cómo se ha implementado la organización y cómo se soporta el sistema y su entorno. Cuando comenzamos en el sector, eran conversaciones sencillas, ya que el software de proyecto que instalábamos podía residir en el ordenador del usuario final y el mantenimiento del sistema siempre era un concepto local. Actualmente, este caso se sucede en contadas ocasiones. Los sistemas corporativos resultan sencillos a nivel de interfaz o pantalla, donde los usuarios finales pueden acceder a las funciones mediante un navegador web que tiene el aspecto de cualquier otra página. Aunque estos sistemas parezcan tan sencillos de cara al público, su cara oculta es verdaderamente compleja. La tecnología necesaria para mostrar esa interfaz probablemente contará con varias capas, en función de las distintas fuentes de la tecnología y la infraestructura y (por si no fuese suficiente) es posible que se deba actualizar constantemente.

No obstante, existen ciertos procedimientos recomendados básicos que le proporcionan la mejor oportunidad de mantener un alto grado de fiabilidad en su sistema empresarial.

Búsqueda de propietario

De hecho, hay que buscar dos propietarios, ya que cualquier sistema de empresa exitoso tiene un propietario empresarial y un propietario técnico. Solo si el propietario empresarial es un ejecutivo del departamento de TI y el sistema empresarial sirve en primer lugar a ese departamento, ambos propietarios pueden ser el mismo. Así pues, veamos esto en dos partes:

Búsqueda del propietario empresarial

Esta persona debe ser una persona del nivel ejecutivo o jefe de administración que tenga interés en los resultados del sistema de administración de proyectos. Las ventajas que proporcione el sistema o los retos empresariales que el sistema deba superar serán beneficios y retos que afecten directamente a este ejecutivo. Antes de que alguien lo mencione; no, por lo general no puede ser un comité o varias personas.

La responsabilidad tiene que recaer en alguna parte y ello casi siempre significa en una persona. Esta persona también podría ser el patrocinador ejecutivo de la implementación del sistema, aunque no es necesario. A menudo el patrocinador ejecutivo no es el propietario ejecutivo final de un sistema de empresa.

Incluso después de que el proyecto de implementación finalice, el propietario empresarial seguirá poseyendo el sistema y, cuando ya no se necesite, deberá identificarse otro propietario empresarial que se comprometa con el sistema. De lo contrario, se debería retirar el sistema.

Búsqueda del propietario técnico

En sistemas de nivel empresarial, un solo técnico no es suficiente. Recuerde que los sistemas empresariales dependen de varias capas de tecnología. El propietario técnico debe ser un administrador con suficiente experiencia o un ejecutivo del departamento de TI capaz de interactuar de inmediato con los propietarios del resto de capas de tecnología. Estas pueden incluir, entre otras capas, el personal con experiencia que posea la base de datos de SQL Server, el servidor de la base de datos donde SQL Server está instalado, los servidores de aplicación donde está instalado Project Server, la red, el servidor o granja de servidores de la red, la conexión a Internet, el cortafuegos, Active Directory y los servidores de Exchange, los servidores o sistemas de seguridad y la imagen del sistema que funciona a nivel de cliente. Alguien con experiencia debe poder representar el sistema empresarial ante estos administradores que controlan el resto de aspectos del entorno.

Sea resoluto

Asegúrese de que Project Server a) tiene un propósito y b) está cumpliendo con su propósito. ¿Suena obvio? Pues no lo es. Con demasiada frecuencia se adquieren sistemas corporativos por razones incorrectas, y la tarea de buscar un propósito para el que aplicar el sistema corresponde a una persona de TI. La persona que apruebe el propósito empresarial del sistema debe ser el propietario empresarial, aunque también pueden tenerse en cuenta otras personas. Durante años he realizado la misma pregunta a los ejecutivos: "¿qué decisión de negocio no puede tomar ahora, o solo podría tomar con dificultad, cuya creación estuviese capacitada por la implementación de este sistema?" Cuando se establezca el requisito empresarial (nótese que no hablo de la funcionalidad deseada), asegúrese de que el sistema empresarial realmente cumple este requisito. Me encuentro con una gran cantidad de usuarios que tienen una gran lista de funciones, pero que no entienden demasiado lo que quieren lograr con ellas.

A medida que la organización evoluciona, hay que asegurarse de que el propietario empresarial revisa este concepto básico. La implementación de un sistema de empresa como Project Server puede alterar radicalmente la empresa en la que se implementa, por lo que no resulta sorprendente descubrir que los requisitos que la organización espera del sistema puedan cambiar.

Es habitual entrar en una organización varios años después de la adopción e implementación de Project Server y percatarse que es imposible encontrar a alguien que sepa de su importancia para la organización. El sistema sigue en marcha solo para asegurarse. Se está trabajando en ello por inercia, pero su objetivo ha quedado en el olvido y los ejecutivos que se benefician de ello a diario no se percatan del origen de dicho beneficio.

Entre en la arquitectura de su empresa

Recuerdo que hace varios años fui con un empleado del personal técnico a la ubicación de un cliente descontento. La instancia de Project Server que tenían instalada estaba provocando todo tipo de problemas. Cuando nos encontramos en persona, solicitamos entrevistar a varios empleados del personal técnico, rastreando el sistema por sus capas. Cuando llegamos a la capa de base, nos encontramos una sorpresa. La versión de SQL Server instalada en el sistema estaba en un ordenador de un usuario final en lugar de en uno de los servidores de base de datos estándar de la organización. Cada vez que se reiniciaba, se apagaba o se instalaba algo en el ordenador, la base de datos dejaba de estar disponible. Esto afectó, literalmente, a cientos de usuarios finales.

Se trataba de una organización de gran tamaño, por lo que el problema no era la falta de servidores empresariales o de infraestructura de apoyo. En este caso, se pudo solucionar el problema fácilmente. Aunque ciertamente fue una buena lección. ¿El sistema que está implementando se está tejiendo en la infraestructura corporativa existente en la que la organización puede haber realizado un gran esfuerzo para que sea estable, fiable y segura?

Realice copias de seguridad

Lo sé. Es una tontería, ¿verdad? Pues sorprendente y lamentablemente no lo es. Las copias de seguridad de los sistemas empresariales pueden ser ciertamente complejas, puesto que dependen de varios aspectos del sistema que deben copiarse a la vez. Hablamos, claro está, de los datos básicos, pero también de los metadatos y los datos de configuración de la implementación. También es el caso de los datos relacionados de sistemas suplementarios que pueda haber para complementar el sistema y que puedan formar parte del mismo esquema de copia de seguridad. Cuando pensamos en Project Server, tenemos que pensar en realizar una copia de seguridad no solo de las bases de datos de proyecto, sino también de la base de datos del servidor de SharePoint. En las versiones de Project Server anteriores a 2010 es posible que se deba realizar una copia de seguridad de la plantilla global. Incluso ahora, es posible que los elementos de las plantillas estén ubicados en ordenadores individuales.

Y no es suficiente con una copia de seguridad. Cuando los sistemas cambien o se actualicen, realice al menos una restauración de la base de datos. Recuerdo que, hace unos años, me encontraba con un cliente al que ayudamos a diseñar su estrategia de copias de seguridad. Apagó el servidor, sacó el disco duro, puso uno nuevo, nos miró y dijo "Aquí. El disco duro se ha roto. Este es un disco duro recién formateado. Restaure mi Project Server". Me quedé de piedra con esta petición. Cuanto más lo pensaba, más me daba cuenta de lo chocante que resultaba que nunca nadie lo hubiese pedido antes. Así pues, realice una prueba de restauración al menos una vez. Por cierto, pudimos restaurar el sistema, pero no volvió a trabajar tan limpiamente como imaginábamos y tuvimos que actualizar nuestros procedimientos de copia de seguridad.

Prueba/Producción

"Todo el mundo es un escenario y todos los hombres y mujeres meros actores", dijo Shakespeare hace mucho tiempo. En este caso, el escenario sería la fase de prueba, una fase clave para cualquier sistema empresarial. Cuando el sistema esté en fase de producción, puede que desee probar nuevas configuraciones, añadir nuevas personalizaciones, probar nuevos informes, enlaces, campos u otros cambios. Dispondrá de actualizaciones y ampliaciones que deberá probar en primer lugar en un entorno de desarrollo o prueba antes de que se incorpore a los usuarios en el entorno de producción. Algo tan básico como una actualización del explorador o de la base de datos puede hacer que el sistema empresarial entre en un bucle, por lo que hay que asegurarse de conservar y mantener un entorno de pruebas independiente del entorno de producción. Con los servidores virtuales de hoy en día este paso resulta más sencillo que hace unos años. Se puede clonar un entorno entero fácilmente desde el sistema de producción, pero en función de su implementación, a veces resulta más fácil decirlo que hacerlo. Recuerde que pueden haber muchas partes distintas del rompecabezas tecnológico a las que se puede hacer referencia aunque haya copiado todo el contenido del servidor.

Supervisión, supervisión y más supervisión

Hay muchos puntos de supervisión que se pueden usar para controlar un sistema empresarial. En primer lugar, es fundamental garantizar que Project Server está disponible para los usuarios finales y, posteriormente, también es esencial comprobar que el personal técnico adecuado recibe notificaciones cuanto antes cuando no se cumple la primera condición. Afortunadamente, hay muchas herramientas en el mercado para garantizar que el sistema es funcional y que se encuentra disponible que permitirán avisar automáticamente al personal técnico, incluso si los usuarios finales todavía no se han percatado del problema. Pero hay otros aspectos de supervisión que también son importantes. Es bueno inspeccionar y mantener un registro de la salud de la aplicación, incluida la cantidad de memoria que se está utilizando, la cantidad de CPU que ocupa, los errores que el sistema pueda indicar, aunque se haya recuperado sin ayuda, cualquier reinicio del servidor obligatorio y el estado de salud relevante de otros elementos de la infraestructura técnica. Por ejemplo, saber que la que IIS está experimentando problemas técnicos podría ser muy importante para mantener la disponibilidad de su aplicación empresarial.

Incluso los pequeños cambios son cambios

La tecnología en la que se basa Project Server cambia a diario. Es imposible evitar todos estos cambios. El sistema operativo de Windows Server suele recibir actualizaciones cada pocos días, SQL Server puede recibir actualizaciones cada pocas semanas. Los sistemas operativos de cliente Windows, sus detectores de virus, cortafuegos e Internet Explorer y sus complementos suelen recibir actualizaciones de forma periódica. Cualquier parte de la cadena entre los datos y el usuario final es un posible punto de rotura de la aplicación, de modo que hay que crear una estructura para gestionar los cambios en cualquier punto de la tecnología.

Esto puede ser un desafío, ya que muchas aplicaciones empresariales distintas pueden depender de aspectos similares de las tecnologías. Hace tiempo tuvimos un cliente que actualizó inocentemente Project Server y descubrió que había apagado todo el entorno de SharePoint Server. Claramente se había producido un error en la manera de aplicar la actualización de Project Server/SharePoint Server. Si bien había copias de seguridad completas y los datos no se habían perdido, el proceso de actualización no estaba preparado para realizar una recuperación instantánea y sus efectos fueron devastadores, ya que fueron necesarios varios días para completarla.

En otra organización, tuvimos un cliente que había realizado una actualización a otra aplicación empresarial y descubrió que era absolutamente necesario que todos los usuarios actualizaran su versión del explorador solo para percatarse de que otras aplicaciones empresariales que ya estaban en uso no eran compatibles con la versión del explorador más reciente. Como dice el refrán, se había metido entre la espada y la pared. Al final, tuvo que anular la actualización del sistema empresarial y esperar hasta que las aplicaciones empresariales se renovasen con una nueva actualización del navegador web.

A veces es mejor parecer integrado que estar integrado

Las demostraciones de ventas siempre hacen que la integración de varias herramientas parezca sencilla. Los datos empiezan aquí y acaban allí. Establecer un vínculo entre herramientas de gran flexibilidad como Project Server y otros sistemas empresariales como los de Finanzas/ERP es bastante complicado y siempre recomendamos que ambos sistemas se encuentren en fase de producción y sean estables antes de enlazarlos. Sin embargo, una vez que se ha comenzado, es todavía más importante supervisar cualquier cambio en ambos sistemas para asegurar que sigan trabajando juntos correctamente.

Con cualquier actualización de los sistemas puede haber cambios en los datos, modificaciones en la estructura o requisitos técnicos distintos. Puede que también haya nuevas características y ventajas, pero debe asegurarse de que la funcionalidad de vinculación existente se comprueba en el entorno de pruebas antes de implementarlo en la producción.

Documente, documente y vuelva a documentar

Las personas que estaban presentes durante la selección y la implementación de Project Server no permanecerán para siempre en los mismos cargos. De hecho, si hicieron un gran trabajo, es probable que se hayan marchado a administrar la próxima implementación que necesite la organización. Por ello, es fundamental documentar las decisiones de configuración, las ventajas previstas, las expectativas de funcionamiento y los parámetros que se utilizaron para tomar dichas decisiones. En el futuro, otras personas echarán un vistazo al sistema y se preguntarán: "¿qué estaban pensando para crear esto?" Asegúrese de que la respuesta queda por escrito.

Los documentos del sistema empresarial deberían ser documentos "vivos" que se renovasen con cada actualización, cada cambio de propietario empresarial o técnico, o cualquier cambio de importancia en la estructura operativa o en los requisitos empresariales.

Observe antes de lanzarse

Es nuestro consejo para aquellas personas que se adentran en un lago de aguas turbias por primera vez. ¿Es profundo? ¿Hay piedras justo debajo de la superficie? Los sistemas de gestión de proyectos empresariales como Project Server pueden recopilar elementos de datos complejos en un solo lugar donde las decisiones tomadas sobre esos datos sean más eficaces y las ventajas derivadas de dichas decisiones supongan una gran diferencia para la organización. Pero antes debe preparar el terreno para garantizar que está trabajando con su sistema empresarial del modo en que pueda obtener las ventajas que necesita sin exponer a su organización a grandes costes y riesgos que puedan empañar el valor de dichas ventajas.

Sobre el autor

Chris Vandersluis es presidente y fundador de la empresa HMS Software, establecida en Montreal, Canadá, un asociado certificado de Microsoft. Cuenta con unos estudios en Economía en la Universidad McGill y más de 30 años de experiencia en la automatización de sistemas de control de proyectos. Es miembro del Project Management Institute (PMI) y participó en la creación de las secciones de Microsoft Project Users Group (MPUG) en Montreal, Toronto y Quebec. Entre las publicaciones en las que ha escrito Chris se encuentran Fortune, Heavy Construction News, Computing Canada Magazine y PMNetwork de PMI; también es columnista habitual en Project Times. Es profesor de Administración avanzada de proyectos en la Universidad McGill y a menudo es ponente en actos de asociaciones de administración de proyectos de Norteamérica y el resto del mundo. HMS Software es el proveedor del sistema de control para los proyectos de TimeControl y es asociado de la solución Microsoft Project desde 1995.

Puede ponerse en contacto con Chris Vandersluis por correo electrónico: chris.vandersluis@hms.ca

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

Ampliar sus conocimientos
Explorar los cursos
Obtener nuevas características primero
Únase a los participantes de Office Insider

¿Le ha sido útil esta información?

¡Gracias por sus comentarios!

Gracias por sus comentarios. Quizá le interese ponerse en contacto con uno de nuestros agentes de soporte de Office.

×