PYCOH-MNT: Mantenimiento Hotelero

January 30, 2014

En el invierno de 2012 una cadena de hoteles canaria me contactó para crear una solución que diera soporte a su equipo de servicio técnico en las tareas de mantenimiento.

El Problema

La gestión de las incidencias y de las tareas asociadas al departamento de mantenimiento giraban en torno a una hoja de papel diaria que mantenían en recepción con diversos campos:

Lugar Hora Parte de Avería Reparado por Observaciones
Apto./Secc. HH:mm Código1 Descr. libre o normalizada Nombre Texto libre

P.ej. si un miembro del personal o un cliente detectaba una avería, debía telefonear a recepción para dar parte; si en recepción estaban ocupados, el parte no quedaba registrado y había que acercarse a recepción o seguir telefoneando. Eventualmente la incidencia se registraba en la hoja de incidencias.

A continuación debía comunicarse la avería al operario de mantenimiento, especialmente si la incidencia era importante, lo cual acarreaba una dificultad similar a la del alta del parte ya comentada. Si el operario necesitaba consultar los detalles debía telefonear o acercarse en persona a recepción, y lo mismo al resolver la incidencia para actualizar la hoja.

Hoja empleada para la gestión del servicio técnico antes de informatizar el proceso.
Hoja empleada para la gestión del servicio técnico antes de informatizar el proceso.

Así comenzaba una gestión ineficiente del servicio técnico, que proseguía con crecientes dificultades. Al final del día la hoja debía archivarse y prepararse una nueva para el día siguiente, trasladando las incidencias no resueltas a la nueva hoja.

El enfoque descrito causaba varios problemas; entre otros:

  • centralización y dependencia en el personal de recepción para registrar, mantener y transmitir las incidencias;
  • retraso o desatención de incidencias por defectos en la comunicación;
  • inconveniencia de requerir a los empleados de mantenimiento pasar por recepción para consultar o actualizar la hoja de incidencias;
  • dificultad para estructurar el histórico de incidencias y obtener informes basados en él;
  • imposibilidad de auditar las operaciones de alta, modificación y resolución de partes de trabajo;
  • ilegibilidad de la hoja de incidencias por la caligrafía y las correcciones;
  • falta de campos de información adicionales y de normalización.

La Solución

Para dar respuesta a las necesidades de esta empresa, desarrollé la aplicación web PYCOH-MNT alojada en la nube y ofrecida en la modalidad de SaaS (Software-as-a-Service) con un modelo de negocio basado en la subscripción, e.d. el pago de una cuota periódica daba las empresas acceso a la aplicación mediante una conexión a internet.

Acceda a las aplicaciones IDM y MNT mediante las cuentas de demostración:

Usuario Clave Rol
demo DemoPass1 propietario
demo2 DemoPass2 trabajador

Con miras al desarrollo de un conjunto de aplicaciones –que denominé PYCOH, decidí desarrollar PYCOH-IDM, una aplicación independiente para la gestión de identidades y cuentas de usuario.

Listado de tareas mostrado por la aplicación web PYCOH-MNT.
Listado de tareas mostrado por la aplicación web PYCOH-MNT.

Todas las aplicaciones del conjunto PYCOH están federadas en la autenticación mediante el protocolo SAML2 (Security Assertion Markup Language 2.0), proporcionando servicios de Single Sign On y Single Logout; e.d., una vez autenticado, el usuario accede a cualquier aplicación del conjunto sin tener que dar sus credenciales nuevamente.

Asímismo, las aplicaciones del conjunto se pueden comunicar entre sí mediante Web Services. Esto permite, p.ej. que los perfiles de personas que se crean en IDM estén disponibles en todas las demás aplicaciones.

Algunos detalles técnicos

Para desarrollar las dos primeras aplicaciones, IDM y MNT, elegí la plataforma Yii para PHP. Había leído buenas opiniones sobre Yii y, después de todo, PHP no me parece tan mal: al ser tan popular, hay muchas librerías y herramientas disponibles y la mayoría de los proveedores de alojamiento lo soportan.

Al principio desplegaba la aplicación –probé en un servidor de alojamiento compartido y también en la IaaS (Infrastructure as a Service) AWS de Amazon– con la ayuda de Phing, la herramienta de construcción basada en Apache Ant. Ideé mi propio mecanismo en base a unas plantillas y unos ficheros de configuración específicos de cada entorno en el que quisiera desplegar. Con Phing sustituía los valores de las plantillas de fuentes y scripts según el entorno objetivo, compilaba la documentación con LaTeX, creaba el árbol de ficheros y finalmente generaba un archivo comprimido listo para subir al servidor. En el servidor lo descomprimía y ejecutaba los scripts incluidos para la instalación.

Pero entonces decidí probar la PaaS (Platform as a Service) Heroku, donde se encuentran alojadas las aplicaciones actualmente. Cuando se suben cambios en el repositorio ejecutando git push, Heroku despliega automáticamente la aplicación y ejecuta el comando composer update. Esto de Composer era nuevo para mí, y me hizo reconsiderar mis métodos: el cambio de Phing a Composer simplificó enormemente el despliegue de las aplicaciones y me mostró un enfoque nuevo del que me beneficiaré en el futuro independientemente de que use Composer o no.


  1. Código: Cl (Cliente), Ca (Camarera/o), Go (Gobernanta), Di (Dirección)

Archivos