Given the complexity and size of MetroAccess operations, the integrity of the databases that “power” it on a day to day basis is a critical issue.
We already witnessed the kind of chaos corrupted data can cause to the system - when MV Transit was importing data from the previous contractors, Logisticare, prior to taking over the contract, DC ParaTransit Info was sounding loud warnings to WMATA that there were major omissions and discrepancies in the database information being transferred. Unfortunately, these warnings went unheeded, but the flawed database migration was noted as one of the reasons for the abysmal transition period that gained such negative attention at the beginning of MV’s term.
So we at DC ParaTransit Info are concerned at recent events which, if not isolated incidents, may indicate that the computer system currently used for MetroAccess (Trapeze) is working with, or even generating, inaccurate data.
What’s in a (phone) number?
One of the founders of DC ParaTransit Info and a MetroAccess Rider, has a “subscription” trip - a pick up each morning, monday through friday, to go to work. This recurring trip has been in place for several years without major difficulties. The IVR “phone number at pick-up” (automatically called when the driver announces his arrival at the pick-up location) is, and always has been, the rider’s home phone number.
However, at some point during the beginning of Inauguration Week, something changed inside the Trapeze database that stores the “phone number at pick-up”, changing it across all subscription trips to this rider’s work phone number. So, the end result is that when the ride arrives at the house to take the rider to work, the MetroAccess automated call is made to the rider’s work instead..
According to the online reservations web site for riders, all subscription trips had changed to the incorrect number. Additionally, two non-subscription trips that were booked by MetroAccess themselves for recertification purposes also showed the incorrect phone number.
The matter was raised with MetroAccess, and a dispatch supervisor attempted to change the “Phone number at pickup” field. The supervisor’s screen apparently showed that change as having been made, although the web site still reflected the wrong phone number. The trips after that attempt to remedy the situation, unfortunately, still called the wrong phone number.
This was then brought to the attention of MetroAccess in email, and we were informed after investigation that this was an issue with an “alternate IVR” field, and that the number had been changed to the correct number once more, which we verified through the web site which this time showed the correct number once more.
Only … At some point, without rhyme, reason, or warning, it appears Trapeze itself reverted the “Phone number at pickup” for the rider back to the incorrect work number.
This resulted in another pick-up phone call going to the wrong number, and a no-show being placed against the rider. In some instances, the change affected the reminded call the night before, which has (since this latest reversion) also gone to the wrong number.
This is deeply troubling behaviour by Trapeze.
Based on our observations to date, and the information telling us of the “alternate IVR” field, we have some ideas as to why this situation has occurred, although none of them are very “good” scenarios from a data integrity perspective.
At this stage, we at DC ParaTransit Info (who are ourselves database and systems professionals) are leaning towards this as being the most plausible explanation
It may be that somewhere in the system, it looks at the pickup numbers in this (pseudocode) manner:
If primary pickup number is not empty
and
alternate number field is empty
use
primary number
else if
alternate number field is not empty
use
alternate field regardless of whether or not there is anything in the primary field.
In effect, a conditional that says “if there’s anything in the alternate field, use that instead of the primary regardless of the data in the primary field.”
We are obviously unable to say with certainty if this is the case, and have asked MetroAccess to escalate this to a “formal” report of a bug in their system in order to get those who can properly analyze the behaviour of Trapeze to investigate. We have yet to hear if this is being done on the requested “formal” level, though.
Why is this so deeply troubling?
As MetroAccess has now tried to change the “Phone number at pickup” twice, yet the number has reverted back to incorrect data afterwards, it raises the spectre that MetroAccess is unable to override the database, instead the database overrides changes MetroAccess makes, in at least one field’s case.
This also raises the additional risk that, if this is not an isolated issue, the software is capable of making changes to trip and customer data without MetroAccess’ knowledge unless it is brought to their attention. This would imply that there is no auditing (or at least no review) of changes made to existing information in the database.
Even if this is simply a case of the “alternate IVR” field overriding the default “Phone number at pickup” field, it would mean the only way to bypass this behaviour would be for those with access to edit that field in the database at MetroAccess remember to “blank” or null the alternate IVR field.
We’re unsure of the purpose of the alternate IVR field, but the most likely purpose, to change that number for trips as a one-off change or as a backup number, would only make sense under this model if it was only applied for one trip, automatically resetting to blank after the trip has been completed - which obviously is not the behaviour observed.
Whilst it may be easy to attempt to dismiss this first issue we raise as being “cosmetic” or otherwise non-critical, the data field being incorrect and constantly reverting may not be all that “critical” - but the idea that trapeze can make changes to parts of the data records, apprently without any way for MetroAccess to notice such changes, raises questions as to what other data records might Trapeze be able to change, again without MetroAccess being able to notice (or rectify?).
Other Computer Oddities
There are two other issues with the MetroAccess database(s) that DC ParaTransit Info is currently monitoring:
2+2 = ?
In one, a rider is still trying to obtain information as to why two trips from November 2008 that should have been covered under the “trip credits” awarded as part of the Settlement Agreement last year were both charged for as fares paid to the driver on boarding the vehicle, as well as being deducted from the rider’s trip credits.
The Magic 8-Ball On Silicon Chips
The third issue we’re aware of currently is the “bidding” system used when you reserve a trip. This issue strangely only seems to apply to trips booked to take place on a friday. When you give your requested pickup time, Trapeze automatically backs the “bid” pickup time back 30 minutes.
For example, if you request a pickup at 2pm, Trapeze will offer you a pickup at 1:30pm, with the pick-up window between 1:15pm and 1:45pm.
This seems to be the case if the rider makes the reservation online, or through the reservation agents. The 30 minute time period does seem to indicate this issue may be flawed logic in the “30 minute window” concept within Trapeze, but we’re at a loss to come up with a reason why this happens for trips that are reserved for fridays alone.
Metrics
Given that Trapeze is, we believe, responsible in large part for generating the metrics (statistics) given to WMATA to measure service performance, any potential corruption of data will have a “knock on” effect, because those statistics form the basis for many decisions regarding the service - especially given recent comments in the news regarding WMATA desiring to reduce MetroAccess service levels due to rising costs.
If such decisions are going to be based in any way on the statistics Trapeze generates, especially “no-show” statistics, then it is critical that the data be audited beforehand to ensure it is reliable and complete. The service has been adversely affected several times in the past as a result of bad numbers, whether they be incorrect trip statistics to woefully-underestimated projected ridership levels.
It also raises other questions
- How many riders have had no-shows placed against them because of a failure of IVR to notify them their transport has arrived at the pick-up point?
- Assuming the rider is able to call “Where’s my ride?”, how would this kind of issue affect on-time performance statistics?
- How many riders have been left stranded for hours, blamed for failing to be at the pick-up point, when the error may be the result of Trapeze changing data or how it processes that data, and the knock-on effect to the IVR phone calls?
- How many riders are unable to log in to their “MetroAccess Account” web page to verify if they have been given the full number of credited trips that were part of the Settlement Agreement?
Conclusions
We strongly recommend all MetroAccess riders to log into the Web site at https://macs.mvwmata.mvtransit.com/passweb/hiwire?.a=pHome (https://macs.mvwmata.mvtransit.com/508/hiwire?.a=pHome for the text only version) and check their upcoming trips contain the correct “Phone number at pickup” data.
We also recommend riders log in and check their “MetroAccess Account” status to ensure that the information is correct, especially with regards to the trip credits that were part of the Settlement Agreement from 2008. You can check your “MetroAccess Account” at https://www.eztransport.com/WMATA/MembersPortal/default.asp.
DC ParaTransit Info would appreciate any information other riders can offer regarding these issues, or if they’ve encountered other problems with inaccurate data within the MetroAccess system. If riders have been subjected to no-shows that were the result of them not getting an automated phone call when their transport arrived, we recommend appealing that decision with MetroAccess as soon as possible, as well as recording the time, date, and any other information regarding that trip.
Until we can be assured of the integrity of the data stored in, and generated by, Trapeze, it’s only prudent to find ways we, as riders, can keep Trapeze and the statistics it generates “honest”.
Categories: MetroAccess , WMATA | Tags: MetroAccess, WMATA | By: .
Print This Post