The functions and features most commonly offered by the major parking and transportation products used in higher education (T2 Systems and Passport), and the HERM business capability each one supports. These are system functions, not HERM capabilities: HERM describes what an institution does; this page describes what a parking and transportation platform does to help it. The platform runs customer and vehicle records, permits, visitor and event parking, gates and license plate recognition, enforcement, citations and appeals, campus shuttles, and fleet and motor pool vehicles. The SIS and HR keep student and employee status, financial posting stays in the ERP or payment gateway, lot and garage work orders stay in the CMMS, and public transit run by others is out of scope. See also the facilities maintenance, dining and finance ERP functions & features. See the HERM Business Reference Model for the full set of capabilities, or its capability wheel.
Shows which parts of the institution a parking and transportation platform supports, where it overlaps other systems, and where it stops.
A function's main HERM home vs others it touches. Features narrow to one capability.
28 HERM capabilities touched, centred on campus transportation management, asset management (fleet) and accounts receivable (fines and payments), plus identity and access, space utilisation, dispute resolution (appeals), payroll, reporting and security.
Wheel to explore, tree to scan every mapping, CSV or JSON to reuse it.
How this was compiled: three AI assistants (Claude, Perplexity and Grok) were each asked to identify the core functions and features of the major parking, transportation and fleet products used in higher education. Their lists were reconciled into this single set. Treat it as a starting point, not a vendor-verified specification.
{{ xwIntro }}
The full hierarchy: areas, functional areas, functions and features, each with its HERM mapping and definition. Select any HERM capability or feature to see its full definition.
Campus services rarely run on one system. Here the same functions and features are mapped to the applications a fictional Example State University actually runs: a vendor core, add-on modules, third-party products, homegrown tools and spreadsheets. Each link records how well the application covers the feature and its role. HERM coverage is then calculated from those links, not mapped by hand.
Also see this ecosystem as a capability × application matrix or a HERM-to-application flow.
Inner rings: area and functional area. Outer ring: one slice per feature, split into bands when more than one application provides it. Marks outside the ring flag gaps (red) and competing systems of record (violet).
{{ fd.desc }}
The executive view. Each bar is the capability’s features, coloured by the best coverage any application gives them. Select a capability for its HERM definition, or an application to see its footprint.
{{ pop.body }}