Por: Daniel Aisemberg

Gran parte de los ERP’S implementados no contemplan el negocio de los servicios. Tal es así que el software quiere venderlos y facturarlos como bienes físicos sin stock, lo que implica perder una gran parte de la información que involucra ese negocio.

Los primeros ERP’S se desarrollaron para fabricantes y vendedores de bienes tangibles. Por ese motivo hoy se siguen sintiendo los efectos de dicha génesis.

Si bien las empresas de servicios masivos (de telefonía, de electricidad, de gas, etc) y los bancos, accedieron a la informática durante las décadas de los '60 y los '70, incorporaron el concepto de planeamiento de recursos empresariales a mediados de los '90. En el caso de las empresas de servicios profesionales, muchas de ellas implementadoras de ERP, lo hicieron incluso más tarde. De hecho, muchas de ellas siguen utilizando soluciones caseras, o simplemente Excel. A propósito, en nuestro centro de Evaluación ingresan empresas buscando ERP que contemplen la operatoria de empresas de servicios.

Pero cuando estas empresas de servicios profesionales deciden implementar un ERP, se encuentran que la gran mayoría de los mismos no conceptualizan lo que es un servicio. Los ERP’S están muy bien adecuados para vender galletitas, chapa, yogurt o medicamentos, manteniendo su lote, su serie, su fecha de vencimiento, etc.,

Pero a la hora de vender servicios, la mayoría de los mismos quieren venderlos y facturarlos como bienes físicos sin stock, lo que implica perder una gran parte de la información que involucra ese negocio.

El problema fundamental es que la gran mayoría de los ERPS no tienen un concepto definido de servicio, y suelen tener, en el mejor de los casos, un archivo con los títulos de los mismos que pueden ir a parar a un pedido o una factura.

Hacen falta varios elementos para tratar adecuadamente este tema:

El sistema debe conceptualizar los recursos que prestan servicio, y tales recursos deben estar sujetos a un calendario propio. En el caso de tratarse de un recurso humano esto debe estar conectado con el módulo de RRHH de modo, por ejemplo, de anticipar vacaciones o licencias.

El software debe tener especificado qué recursos pueden prestar el servicio, y con que tasa de eficiencia realizan dicha labor. O sea: Si tengo en la compañía el servicio de relevamiento, y el mismo puede ser cumplido por un junior, eventualmente por falta de los mismos podría ser cumplido, incluso con mayor eficiencia, por un semi senior, incluso por un senior o un gerente. Es conveniente que este tipo de relaciones se especifique para casos de emergencia, y pensando que todo esto hoy camina hacia la automatización y la programación automática de los recursos.

Se debe poder generar la solicitud del servicio, de modo de comprometer el calendario de los recursos adecuados, y esto funciona como un pedido de ventas en el caso de venta de bienes. Se especifica claramente cuando, o en que franja de fechas y horarios puede ser prestado el servicio, si se requiere algún tipo de equipo especial, etc.

Se debe poder generar un parte de servicios que informa el cumplimiento del trabajo solicitado, y que funciona como lo hace el remito en la venta de bienes. Este reporta quien, cuando y como se prestó el servicio, si hubo algún resultado especial, algún inconveniente, etc.

Finalmente lo que se debe facturar son los partes de servicio.

Manejando adecuadamente estas estructuras, se puede ir paulatinamente a la asignación automática de recursos a tareas, que sin dudas, será el siguiente paso.