0/40
0 of 40 confirmed
Foundation still being defined
The operating goal may be valid, but source systems, data ownership, policies, or exception handling require further discovery before technical scope is fixed.
This readiness result is directional and should be validated with operations, IT, finance, security, procurement, and the teams that will own exceptions.
Objective and scope 0 Source systems and ownership 0 Data and identifiers 0 Scheduled crew workflow 0 IROPS workflow 0 Policy and exception handling 0 Supplier and booking execution 0 Payments and finance 0 Security and governance 0 Testing and rollout 0 11. Objective and scope 22. Source systems and ownership 33. Data and identifiers 44. Scheduled crew workflow 55. IROPS workflow 66. Policy and exception handling 77. Supplier and booking execution 88. Payments and finance 99. Security and governance 1010. Testing and rollout
1. Objective and scope Begin with one outcome such as scheduled hotel booking, IROPS action execution, deadhead booking, or finance record handoff.
0 of 4 confirmed 1. We have named the first workflow to improve.2. We have documented the operational problem in measurable terms.3. We have identified the airline teams affected by the change.4. We have excluded unrelated workflows from the first pilot.
Next category 2. Source systems and ownership A successful integration cannot rely on two systems both claiming to be the source of truth for the same operating decision.
0 of 4 confirmed 5. We know which system owns the current crew schedule or roster.6. We know which system owns disruption detection and OCC decisions.7. We know which system owns hotel and flight policy.8. We have named an accountable owner for every source feed.
Next category 3. Data and identifiers Identifiers should remain attached from the original airline event through booking, support, audit, and finance records.
0 of 4 confirmed 9. Crew, pairing, duty, flight, schedule, and IROPS identifiers are stable enough to correlate across systems.10. Required dates, airports, stations, and time zones are represented consistently.11. We can provide complete schedule snapshots for the required date window.12. We have a process for detecting missing, duplicated, late, or conflicting data.
Next category 4. Scheduled crew workflow The source system should provide the complete current state for the submitted period rather than an informal list of changes.
0 of 4 confirmed 13. We have defined what event publishes or republishes the schedule window.14. We understand how additions, changes, and removals should affect active travel.15. We have defined the policy for preferred hotels, contract rates, and price limits.16. We know which scheduled outcomes can proceed without manual approval.
Next category 5. IROPS workflow The travel integration should execute an airline decision, not silently become the system deciding whether a crew recovery action is operationally required.
0 of 4 confirmed 17. The airline has a defined source for the disruption event.18. OCC ownership of the operational decision is clear.19. Hotel and deadhead actions can be grouped under one airline-owned disruption reference.20. We have defined which IROPS decisions require human selection or approval.
Next category 6. Policy and exception handling Automation without exception ownership creates faster failure, not a stronger operation.
0 of 4 confirmed 21. Policy rules are documented in an implementable form.22. Price, inventory, and supplier exceptions have named owners.23. Review and failed states have response expectations.24. Teams know when a retry is appropriate and when a new decision is required.
Next category 7. Supplier and booking execution A booking request is not complete until the operating team knows whether the supplier confirmed it and what happens when the state changes.
0 of 4 confirmed 25. Required hotel and flight content sources are understood.26. Contracted hotel rules and fallback inventory are documented.27. Supplier confirmation and booking-state expectations are defined.28. Changes, cancellations, and no-longer-required travel have clear handling rules.
Next category 8. Payments and finance Finance should not have to reconstruct the original crew requirement from an invoice after the operation has moved on.
0 of 4 confirmed 29. The payment or billing method for each workflow is defined.30. Booking records retain the context finance needs.31. Supplier confirmations, contracted rates, and booked rates can be compared.32. The downstream invoice, folio, export, and reconciliation owners are identified.
Next category 9. Security and governance Crew schedule data can reveal where people are expected to work, travel, and rest. Treat the integration accordingly.
0 of 4 confirmed 33. Security and privacy teams understand which crew data will be exchanged.34. Authentication, credential ownership, and access controls are defined.35. Retention, audit, and incident responsibilities are documented.36. Sandbox and production access will follow separate approval controls.
Next category 10. Testing and rollout A pilot should prove the operating model, not just demonstrate that an API request returns a successful response.
0 of 4 confirmed 37. The pilot has a limited and clearly named scope.38. Data validation and exception testing are part of acceptance criteria.39. A parallel-validation or controlled observation period is planned.40. The airline has defined go-live, expansion, pause, and rollback decisions.
Complete this category 