CASPER
CASPER (*Centralized* *Automated* *Sort* *Processes* *Evaluation* and *Reporting* tool) is the end-to-end change management tool for network design change requests across geographies; bringing near real-time visibility to all upcoming changes, establishing reliable communication between FCs and transportation, auditing and remediating launch configuration errors, and ensuring the appropriate information is available for FC leaders make informed decisions.
Siddhant Jain
Amazon Employee
Published Aug 2, 2024
CASPER (*Centralized* *Automated* *Sort* *Processes* *Evaluation* and *Reporting* tool) is the end-to-end change management tool for network design change requests across geographies; bringing near real-time visibility to all upcoming changes, establishing reliable communication between FCs and transportation, auditing and remediating launch configuration errors, and ensuring the appropriate information is available for FC leaders make informed decisions.
For CASPER overview training, please watch this video for more details.
For a more detailed overview of each feature, please visit the CASPER Training Series
CASPER is the one-stop shop for network design change requests across geographies; bringing near real-time visibility to all upcoming changes, establishing reliable communication between FCs and network planning teams, and ensuring FC leaders make informed decisions.
- We surface near real-time visibility of all network design change requests across geographies.
- We consolidate information needed in an easy to use format for teams affecting and affected by the network design management process.
- We standardize network design constraint models used to evaluate change requests.
- We create a direct feedback loop to the network planning teams to ensure no changes requested violate established FC constraints.
- We reduce friction to ensure all changes are approved, rejected, and executed quickly.
CASPER is planned to ingest change requests from TORCH and display the upcoming change requests for FCs. TORCH NA is yet to be launched, until then we have introduced an input portal in CASPER which accepts an excel as input to upload change requests.
In order to standardize the input we have created a template which can be used to add requests in CASPER, sample template can be found here.
- How do we maintain uniqueness among each change request uploaded?
- Until TORCH is launched, all change requests are created using SIMs. Hence we do not have any unique identifier to identify each change request. To resolve this issue we create a hash of FC name, request type, parent sort name, stacking filter, sim link with respect to a change. Ideally this combination should remain static for a change request and should avoid collision. Hash is made case-insensitive i.e the case of the input letters doesn't change the uniqueness of hash.
Any opinions in this post are those of the individual author and may not reflect the opinions of AWS.