Comment from Jason Suguna Kumar

Jason Suguna KumarSupportIndividual
Summary: Jason Suguna Kumar, an ERP consultant and systems architect, supports the modernization of Bureau of Transportation Statistics (BTS) data to better serve enterprise systems. He argues that BTS should provide higher-frequency data products, RESTful API endpoints, and standardized metadata schemas to enable real-time operational planning and AI-driven analytics in supply chain and transit management.
FEDERAL REGISTER PUBLIC COMMENT Enterprise ERP Integration Perspective on Transportation Data Modernization Docket ID: DOT-OST-2026-1387 I am a Senior Enterprise Systems Architect and ERP Consultant with more than seventeen years of experience designing integration frameworks that connect ERP platforms, legacy systems, operational technology, supply chain infrastructure, and AI-enabled automation tools. My practice spans municipal transit payment modernization, consumer goods manufacturing, cooperative retail distribution, and healthcare enterprise systems. I submit this comment to offer the perspective of a practitioner who builds the enterprise infrastructure through which transportation and supply chain data is consumed, reconciled, and acted upon. Regarding supply chain data frequency and operational relevance (Question 2): Supply chain operations in manufacturing and distribution depend on reliable transportation data as an upstream planning input. At Lindt & Sprüngli Canada, I have worked across ERP environments processing between 20 and 33 million retail transactions annually, connecting inventory, procurement, distribution, and financial systems. Through an earlier engagement supporting a mainframe-to-ERP migration for Federated Co-operatives Limited, I worked across a network of 160 co-operative organizations spanning 1,600 locations. In both environments, freight movement data from sources such as BTS would improve the accuracy of inventory planning models and supply chain forecasting. Current BTS data products are aggregated at intervals that do not reflect operational realities for manufacturers and distributors who reconcile inventory against shipment timelines on a daily or weekly basis. BTS should develop higher-frequency data products for freight flow and commodity movement that support operational planning cycles, not only annual statistical reviews. Regarding transit data and municipal enterprise systems (Question 2, continued): In my current engagement at the City of Guelph, I am designing the integration architecture that connects transit fare-collection terminals, payment processor APIs, and municipal ERP systems into a unified real-time environment serving approximately 7.9 million annual rider trips. Transit agencies making service and budget decisions need continuous operational data, not periodic aggregated summaries. BTS should consider publishing higher-frequency transit ridership and operational cost indicators that municipalities can integrate directly into financial planning and ERP environments. Regarding API compatibility for enterprise consumption (Question 9): The most significant integration barrier across all my engagements is data delivery format. BTS currently provides data primarily as static downloadable files, which require manual extraction, transformation, and loading before they can be consumed by ERP platforms or integration middleware. My work connecting Oracle JD Edwards EnterpriseOne, SAP S/4HANA, and enterprise middleware platforms to external data sources consistently encounters this bottleneck. RESTful API endpoints with standardized schemas would allow enterprise systems to consume BTS data directly, eliminating the transformation layer that currently makes real-time or near-real-time consumption impractical for operational use. Regarding AI and automated analytics integration (Question 10): Enterprise AI tools for demand forecasting, inventory reconciliation, and financial automation require consistently structured, machine-readable inputs. In my work implementing accounts receivable automation at Lindt & Sprüngli through HighRadius, and in designing an automated inventory reconciliation system that reduced monthly close processing time from three days to under one hour and eliminated approximately two million dollars in annual inventory write-downs, the structure and consistency of upstream data inputs was the primary factor determining what automation was feasible. BTS datasets are inconsistent in field naming, unit definitions, and temporal granularity across product lines. Standardizing metadata schemas across BTS product lines and publishing data dictionaries in machine-readable formats would substantially improve BTS data usability as an input for AI-assisted supply chain analysis, demand forecasting, and financial reconciliation in enterprise environments. These observations reflect constraints I encounter directly when building enterprise integration architectures across manufacturing, distribution, and public-sector transit environments. BTS data has meaningful potential to improve supply chain planning, transit operations, and enterprise decision-making, but that potential is constrained by delivery mechanisms and data structures that have not kept pace with how modern ERP and AI-enabled enterprise systems consume and act on information.

View on Regulations.gov