DPS System Problems: Omission of Two-Way Interface Continues to Plague DPS
June 3, 2011 
4 Comments
Note: This is the fourth in a series of posts looking at the concern over the DPS system performance during peak season.
Nearly five years ago, I had my first opportunity to see a demonstration of the new DPS computer system. About 15 industry representatives gathered at SRA’s headquarters in Northern Virginia and got our first glimpse of the system that would become the focal point of this industry. At the conclusion of the demonstration, the attendees were given the ability to vote on the most important change needed to the system in order to make it a success. The one change that received the most votes, by a health margin as I recall, was the implementation of two-way interface for transmitting data between DPS and the industry’s computer systems.
Of course, nearly five years later, the two-way interface has still not been implemented. It has been discussed, prioritized, and promised; but never built. The current thinking seems to be that the present underlying architecture of DPS would not support a two-way interface, so it needs to be replaced before the two-way interface can be added. It appears that the industry’s number one request of DPS for the last five years is still years away from being implemented.
Why is this relevant to the current DPS system problems? The repercussions of the decision not to add that functionality is being felt to this day, and add to the problems currently being experienced by DPS. The process of moving a shipment in DPS requires a lot of data entry by the TSP, and all of that data entry has to be done manually, inside of the DPS system. This TSP data entry accounts for a large chunk of the traffic that DPS must handle, a task it has struggled to do.
Had a two-way interface been added, the load on the DPS servers would be reduced considerably. A computer-to-computer transmission of data is the most efficient transmission method available, with the least amount of load being placed on the server. If the DPS system accepted updates via a two-way data transmission, most TSPs would utilize that option. The required capacity for the DPS server would be reduced considerably, speeding up system response times for remaining manual users of the system, mainly PPSOs and Service Members.
If you are wondering how the web-bots, which are widely used by TSPs, compare to computer to computer transmissions, remember that what a web bot does is mostly mimic a computer user manually making an update. They can be more efficient than a human, but they are not as efficient as a true computer to computer transmission. Web-bots will be covered more extensively in our next post.
Do you think a two-way interface will ever be added to DPS? Why or why not? Please use the comments below to share your opinion.
Related Posts
- New PT User Interface - November 12th, 2007
- DPS System Problems: Attack On the Web Bots - June 7th, 2011
- DPS System Problems: Click Count Limitations Are Threat to Human Users - June 9th, 2011
These are ALL great points. It seems strange that, before construction even started, industry users quickly realized the limitations and workload that the labor-intensive DPS design placed on ALL parties, yet the owner of the very complicated and expensive military procurement system didn’t … and still don’t!
From a systems point of view, it is also extremely dysfunctional to have each of the 600K+ military and civilian service members who receive instructions to move each year from their respective commands to log-in to DPS and register their PCS move AFTER they receive their transfer orders.
Their superiors in the branch of service they represent already know:
who they are (including their name, rank and serial number; height, weight and sex)
the number of members of the family being authorized a transfer
when and where they’re being deployed from and to
the amount that they’re authorized to move based on their rank and orders
the number and frequency of personnel being transferred in the same or complimentary traffic channels
Think about it. The local Pizza Hut, Chinese Carry-Out, or Best Buy Geek Squad crew knows a whole lot more about what a military service member or their family is going to order and what type of logistics hurdles their company can expect to encounter in providing their product or service – BEFORE THEY”RE EVEN CONTACTED – than the commandant of their base or local PPSO does.
And their very efficient, automated and/or self administered procurement systems didn’t take five years and $2 billion dollars to develop.
These are ALL great points. It seems strange that, before construction even started, industry users quickly realized the limitations and workload that the labor-intensive DPS design placed on ALL parties, yet the owner of the very complicated and expensive military procurement system didn’t … and still don’t!
From a systems point of view, it is also extremely dysfunctional to have each of the 600K+ military and civilian service members who receive instructions to move each year from their respective commands to log-in to DPS and register their PCS move AFTER they receive their transfer orders.
Their superiors in the branch of service they represent already know:
- who they are (including their name, rank and serial number; height, weight and sex)
- the number of members of the family being authorized a transfer
- when and where they’re being deployed from and to
- the amount that they’re authorized to move based on their rank and orders
- the number and frequency of personnel being transferred in the same or complimentary traffic channels
Think about it. The local Pizza Hut, Chinese Carry-Out, or Best Buy Geek Squad crew knows a whole lot more about what a military service member or their family is going to order and what type of logistics hurdles their company can expect to encounter in providing their product or service – BEFORE THEY”RE EVEN CONTACTED – than the commandant of their base or local PPSO does.
And their very efficient, automated and/or self administered procurement systems didn’t take five years and $2 billion dollars to develop.
WELL SAID!