What is important in doing codeshare (3)

Partnerships between airlines are common more than ever. Each partner has its own perception of how the best synergies can be reached in a partnership. This belief is usually based on their own experience, the available knowledge, established processes and used tools. But in a partnership, both parties have to act as team together to be successful and to generate the ideal synergies for all parties.

In a series of several articles in our LSY blog, we’ll illuminate the various business steps how both partners can generate the best advantages out of their mutual partnership.

Today’s topic
Episode 3: IATA standard format

In the previous episode, the sender-receiver-model in communication was mentioned already. The sender must encode the message (or data) and the receiver reacts with decoding the received data. If sender and receiver are not speaking the same language, it causes problems in the communication.

Reflected to schedule data exchange, the format for communication is clearly defined by the IATA standard. It describes the exchange of schedule data in standardized formats: ASM (Chapter 5), SSM (Chapter 4) and SSIM (Chapter 7).

SSIM is usually used for bulk schedule data, e.g. the complete schedule of an airline. SSM and ASM are usually telex message formats, whereby ASM is usually used in the operational period for a single-dated schedule information. In contrast, SSM is usually used for schedule information outside the operational period and might contain a collection of schedule changes.

If a standard is defined, there sould be no problems in schedule data exchange, shouldn’t it? Well, it is not that easy…

Unfortunately, the IATA standard definitions are highly complex and in some areas really difficult to understand. The reason is not that people who defined the IATA standard did a bad job; the reason is that the business backgrounds have so many different requirements making the definition of a common standard also complex.

One easy example: A lot of airlines are planning their schedules in Local Time - they don't care about the timings of the own flights in UTC. However, they have partners doing the same job for their schedules, but in UTC. If now both parties want to align their schedules among each other, e.g. in a codeshare agreement, it leads inevitably to conflicts in the synchronization process.

Another example: There are still airlines exchanging their schedules in Excel format. A standard is not defined to exchange schedule data in Excel format. Excel is a powerful tool and allows a extremly flexible combination of columns. Excel is surely a nice tool to create (user-defined) reports with schedule information; but it is no tool to exchange schedule data in "free-text" format between any two systems respectively airlines.

Supporting IATA SSIM standard is a must for any system used in the relating processes. Syntactical and logical correctness according to IATA standard should always be considered. In addition, a system should be able to handle with slight modifications in order to support the best practice methods in business processes. And if there are (slight) deviations from the IATA standard available, a system should detect and highlight these ones to the user. How to (re-)act in the specific case depends on the underlying business process of the airline or the parties involved.

Related links:

Previous blog(s):
Episode 1: Reference data as backbone
Episode 2: Schedule data exchange

To be continued soon with Episode 4: Correct reflection and setup of agreement

Leave a comment

Mandatory input is marked *. Your email address will not be published.

Kontakt