Gran parte de los ERP’S (Enterprise
Resource Planning) 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.
Por División Consultoría
de Evaluando ERP
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.
Fuente