CARDS2 Discussions: Difference between revisions

From AquaWiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 2: Line 2:
* Conversation: creating a new application to replace a legacy one should include workflow and policies. Applying a new application/solution to the same rough/outdated workflows and polices will result in a bad product, or no real gains from the previous system aside from being new. A new solution should enable workflow and policy efficiencies.  
* Conversation: creating a new application to replace a legacy one should include workflow and policies. Applying a new application/solution to the same rough/outdated workflows and polices will result in a bad product, or no real gains from the previous system aside from being new. A new solution should enable workflow and policy efficiencies.  


* A major goal should be to eliminate as much printing of paper copies as possible, what's the point of an accounting system if it's second to a mess of printed papers. (A serious problem at DHS)
A major goal (at dhs at least) should be to eliminate as much printing/scanning of paper copies as possible, what's the point of an accounting system if it's second to a mess of printed papers.


* Certain equipment short-titles need to have required software version. Software version needs to be a gated value that's recorded only at the COR level, so that CAMs can select from a list of appropriate values. This will prevent garbage data from being inputted to CARDS. Really all serious details of a Short-title should be gated, bad values to include allowing CAMS to enter incorrect short-titles should be prevented. CAMs regularly fat finger STs when bringing an item back in from a national account.  
* Certain equipment short-titles need to have required software version. Software version needs to be a gated value that's recorded only at the COR level, so that CAMs can select from a list of appropriate values. This will prevent garbage data from being inputted to CARDS. Really all serious details of a Short-title should be gated, bad values to include allowing CAMS to enter incorrect short-titles should be prevented. CAMs regularly fat finger STs when bringing an item back in from a national account.  

Revision as of 16:17, 16 December 2022

  • Conversation: creating a new application to replace a legacy one should include workflow and policies. Applying a new application/solution to the same rough/outdated workflows and polices will result in a bad product, or no real gains from the previous system aside from being new. A new solution should enable workflow and policy efficiencies.

A major goal (at dhs at least) should be to eliminate as much printing/scanning of paper copies as possible, what's the point of an accounting system if it's second to a mess of printed papers.

  • Certain equipment short-titles need to have required software version. Software version needs to be a gated value that's recorded only at the COR level, so that CAMs can select from a list of appropriate values. This will prevent garbage data from being inputted to CARDS. Really all serious details of a Short-title should be gated, bad values to include allowing CAMS to enter incorrect short-titles should be prevented. CAMs regularly fat finger STs when bringing an item back in from a national account.
  • CAMs should be able to perform Relief of Accountability, Reports of Possession, Removal and Addition of Account Users, Corrections, <More things>. However these actions should work as a request, accompanied with justification. The COR Admins would be notified of the requests and could approve the request/deny with justification or escalate to incident.
  • We need a deeper insight on the steps that happen leading up to an incident. CARDS2 should have a incident management system, rather than having account fill out a pdf. users would be able to mark items within the system as things that need to be investigated, similar to how kmi operates.
  • User enrollment should also be rolled into CARDS2; the current process causes too much disconnect and doesn't provide visibility to all members of the COR. The challenge here will be working with documents, as a wet signature is required, and protecting PII.
  • Is it possible to have API Integration with the GEM or Vines? There would be tremendous benefit if CARDS2 could push directly into those platforms, or pull equipment status ie sw version

Build an additional system that acts as a universal GEM or Vines, I've tinkered with lackluster powershell scripts to ease KG upgrades, and I think it would be doable to build a tool that performs like GEM or Vines

  • Gated high > low notifications is a must.
  • For asymmetric key, is there a way "CARDS2" could create a platform/equipment package, so when key is downloaded it's easier to associate after the fact for things not connected to a GEM/Vines or if a homegrown gem/vines is out of the picture.