Versión para imprimir, PDF y correo electrónico
Imagen de pitano

La estandarización y la regulación son elementos necesarios en un ecosistema abierto que funcione bien.

Durante la última reunión del MaaS-Lab, Pitane Mobility, con sede en Eindhoven, expresó el deseo de incluir la integración de la API TOMP como un componente estándar en las nuevas licitaciones en transporte de taxi y atención médica. Según el empresario de Eindhoven, Gerrit Saey, debemos deshacernos de todas esas navajas suizas para lograr vínculos técnicos entre las partes. 

El sector puede pedir tranquilamente un mismo estándar. Según el presidente Bertho Eckhart, Royal Dutch Transport, el asesoramiento se puede enviar a AIM, pero este último debe decidir sobre la recomendación en sí. El Mobility Procurement Institute (AIM) fue establecido por los interlocutores sociales del sector del taxi (KNV, FNV y CNV) para llamar la atención de las partes que compran transporte sanitario, incluidos municipios, provincias e instituciones sanitarias, sobre temas importantes para el sector. 

En los últimos años, el Ministerio de Infraestructura y Gestión del Agua y varios consorcios han tomado medidas para dar forma a los pilotos de MaaS. En los últimos años, el Ministerio de Infraestructura y Gestión del Agua también parecía apuntar a la "obligatoria" norma técnica (TOMP API), inicialmente a través de una obligación directa con las partes de MaaS que participan en los pilotos, y ahora incluso a través de los responsables políticos municipales que imponer reglas a los proveedores de vehículos compartidos. El objetivo de la API TOMP es crear un sistema 'abierto' en el que muchas partes tengan la oportunidad de desarrollar servicios MaaS.

grandes preocupaciones

Esta obligación es una gran preocupación para el sector del coche compartido, que ven como una gran amenaza para la oferta actual y el crecimiento futuro del coche compartido en los municipios. Esto también dificulta el éxito de los pilotos de MaaS y los clientes (potenciales) también son engañados. Por estas razones, solicitan que no se perpetúe la obligación pretendida.

“El sector no es partidario de exigir la API TOMP como estándar en las licitaciones. Hemos enviado una carta de fuego al respecto para llamar la atención sobre esto”.

proveedor de vehículos compartidos myWheels

Además del mayor desarrollo y prueba de las soluciones técnicas, la creación de un ecosistema de trabajo real es una condición importante dentro de MaaS. La expectativa es que los sistemas MaaS en funcionamiento hagan una contribución positiva a la calidad de vida en las ciudades. Por lo tanto, este punto es la razón principal por la que los proveedores de vehículos compartidos no solo admiten MaaS, sino que también creen que deberían desempeñar un papel importante en él.

objeciones

En uno papel de posición informó previamente a la industria que la API TOMP no está madura y aún necesita mucha experiencia práctica para desarrollarse aún más en un producto estable e implementable. Además, se subestima el impacto técnico, operativo y financiero de la implementación de la API TOMP para los proveedores de vehículos compartidos. Hacer que la API de TOMP sea obligatoria en el futuro amenaza el servicio para los clientes de los proveedores de vehículos compartidos.

Según el sector, la API de TOMP fue desarrollada principalmente por partes de MaaS: “Nosotros, como proveedores de vehículos compartidos, no pudimos o no quisimos participar en este proceso, dado el enfoque elegido. Desbloquear autos a través de terceros es un asunto complejo”. No solo una crítica de la API de TOMP, sino también una visión para el futuro.

toekomst

En general, la mayoría de los proveedores de vehículos compartidos ven un valor agregado en un estándar. Desde este punto de vista, sería bueno permitir que el desarrollo de la API de TOMP continúe y madure con las partes para quienes este es un siguiente paso lógico, como aquellas partes que aún no ofrecen integración (nivel 5) a través de su propias API. . También es importante aprender del primer grupo que ya funciona con API de terceros. 

Una vez que el ecosistema esté en funcionamiento, el incentivo para las otras partes debe ser lo suficientemente grande como para cambiar eventualmente a la API de TOMP. Sería un buen objetivo si la API de TOMP está madura al final de los pilotos y, por lo tanto, es más compatible. Según el documento de posición, actualmente es más importante establecer una colaboración y acelerar los pilotos de MaaS que exigir un estándar técnico.

hay trabajo por hacer

Así que hay trabajo por hacer para ambas partes. La industria puede explicar mejor las objeciones personalmente a TOMP-WG y el grupo de trabajo, a su vez, puede evaluar si el documento de posición escrito en ese momento todavía está actualizado. En resumen, el sector del carsharing afirmó que una obligación de la API TOMP -ciertamente en esta fase piloto- por parte del gobierno o de los municipios sería indeseable, contraproducente y prematura. Por ahora, un compromiso de la API TOMP inmadura llega demasiado pronto. 

Los proveedores de vehículos compartidos apoyan la idea de la estandarización, pero una obligación no es tan inteligente como se defendió anteriormente. “Podemos imaginar que a los municipios les gustaría que se integraran los proveedores de carsharing para que MaaS pueda tomar forma y lograr sus objetivos, pero la forma y la técnica de integración no debería importar”, según el sector. El documento de posición ha sido respaldado por myWheels, SIXT Share, Greenwheels, Juuve y Share-NOW y es aquí leer.

Berto Eckhardt
Bertho Eckhardt - presidente KNV y transporte en autobús Países Bajos
Artículos relacionados:
Transporte al aeropuerto