Key Insights and Decisions

Going into this week, here were the two hypotheses we intended to examine:

 

1. Would OVE checks being partially automated be both feasible as well as increase accountability and accuracy to a significant enough degree where Marines would be willing to switch from the paper based system.

 

Our biggest concern with changing how Marine’s operate their inventory/OVE checks is that whatever technology solution we implement, while it may save time and money, will not be adopted because it could be more inconvenient than paper. This meant when we asked OVE officers if they could get behind a technology, we specifically addressed this issue. The biggest gap between tech and paper was the difference in typing versus handwriting. To address this, what will need to do is minimize the instances where writing is necessary. So a solution we raised that was received well was simply making everything checkboxes, as in inventory there are not too many times where you would need to write extensively.

The next concern is how do we make this applicable to both the environment at Lejuene where internet is extremely slow and unreliable as well as in country where there is no internet service. Obviously this requires doing everything locally and transmitting information physically. One solution that we believe would certainly work because it is already being used is a scanner technology that reads relevant information from barcodes and can be scanned directly into fields in GCSS. These fields are all public knowledge and the Marine Corps already has them. Our solution would utilize this by taking any relevant information processed by the application and converting it into a barcode. Then having the OVE officers take the device at lunch or the end of the day to their CO who scans in all of these barcodes to get the relevant information.

 

1. How could we most effectively (in terms of most time saved, mistakes prevented, and flexibility/durability) improve the LTI reporting system.

By utilizing the aforementioned scanning technology, would could have maintainers scan a code with their tasks for the day, use our app to update them as the do them, the have the QC clerk scan each person’s barcode at the end of the day into GCSS. The design for this seemed to be the most well received by both the actual users as well as the COs who we would need by in from. The app would certainly save time and mistakes, but what remains to be discovered is whether or not it alone would be significant enough to be embraced by COs.

 

Next Couple Weeks: We will design the flow of two apps. One that solves the LTI issue and one that solves OVE checks. We will present both to our contacts in 2nd TSB and hopefully get constructive feedback on whether or not they would like us to actually build a working version. GySgt List was very eager to have us use his company for a trial. He has four scanners ready and if we were to pursue the scanner technology we could use them to effectively use our app. Many of the members of his platoon have experience working with his scanner app, we believe it is most likely to be adopted there and will hopefully continue to spread throughout the Marine Corps if it is successful.

 

Interviews

 

Michael Jelen:

• Blockchain
  • Add an augmenting layer via blockchain API
  • Would cost more network resources
    • Not all are as intensive as Bitcoin bc it’s a private blockchain
    • Search up consensus algorithms
  • Shipping Industry
    • Maersk
      • Signed up with IBM to use blockchain
    • Starbucks
      • Wanted to use blockchain to verify coffee beans for fair trade, specific regions and farmers, specific date
    • Walmart
      • Food safety
    • Lot more manual, could benefit from blockchain
    • Who’s shipping, who owns the containers, etc. is on paper or PDF
      • Being emailed around the port
    • Add scanners/sensors
      • Ex: temp scanner in produce
• Scanners
  • How to maximize efficiency? Still need people to go out there
  • Inventory
    • RFID, machine could move around the room and check on everything
    • Sort of like Vault from Team 5
  • Maintenance
    • Scanner app, just take them off paper
• Dashboard
  • Tableau
  • Composite Readiness Score of some kind

 

Scott Frederick:

• ITPR, MC Forces Systems Command, extra approval layer
  • Procurement
    • New system/idea/concept
      • PMC (procurement money), 3yr money
      • RDT&E (research development tools & equipment), 2yr money
      • DoD FMR (financial management readiness manual)
        • USN’s; USMC 7300B
    • Commander (BG) will go to comptroller and tell him he wants to buy this new product
      • Comptroller will create an initiative slide
        • Breakdown purpose, cost, etc.
        • Take that and next palm submission (in one atm, this won’t happen until next year)
          • Palms happen every year for every unit,
        • Then gets routed up to P&R (programs and resources) at the Pentagon
    • Pentagon
      • If approved, MC HQ will program that money to 2nd MLG
      • When 2nd MLG gets money they can get money
      • Need contract to tie the money to the product (need contractor to do that)
        • Part of the contract will have an ITPR #
    • ITPR
  • Contract Mechanisms
    • Need to be an approved contractors
    • DUNS #
    • Need to create an LLC (48hrs in NC), get a DUNS # (30 days), then work with an RCO officer to get the contract done
      • Can’t do any of this until money is distributed
      • UNLESS general wants to free up money from elsewhere
  • Would take 12-36 months by his guess
  • OMMC (day to day money), PMC (investment money, 3yr), RDT&E (research money, 2yr)
  • Deployment
    • IT implementation template
      • RCO (resource contracting officer)

GySgt Hinds:

 

• Provided information as to the role of an Operations Chief: checking what operators do, verify that missions are being run and that there are drivers for missions
• Uses GCSS, MOL and TCPT on a daily basis, and often has to enter the same information twice every day
• Believes that all systems (GCSS and MOL) are supposed to talk through MCTIMS and thinks that this is the ideal world. Wants to just be able to use MCTIMS
• Has to validate all equipment every three months, and believes that a scanner would make this process much smoother and easier

 

MSgt Lemus:

• Demonstrated the MMR auditing tool, it works sometimes but doesn’t measure the things the CG and higher command want to see.
• What is really needed is something that can go line by line through the MPR and flag discrepancies.
• A General went through a TSBs MPR and took their readiness from a 90+ to a sub 50.

 

GySgt List:

• Scanner to Keyboard Emulator technology is how we
• The major factors in determining what he will use are how durable and flexible it is. For example, it needs to be able to work with no internet as well as withstand people messing around with it.
• OVE Checks – showed us the OVE room as well as which tools he thinks a scanner would be helpful for. Our goal for the day
• LTIs – This is his biggest pain. Maintainers need to debrief their parts as well as updated the status on their tasks but they don’t so if we could help fix that, we could dramatically change the flow of the maintenance floor.
• Workflow – Introduced us to a group of Marines who walked us through the workflow

 

Capt. Baker:

• Is working to understand the problem better. Wants us to continue working but is nervous about roadblocks.
• She will work to free up GCSS IT people for us.
• Believes our best bet is TCPT as it is Marine Operated.

 

LCpl Hernandez (Mechanic), Cpl De Silva (QC), and LCpl Casillas (floor chief):

• • Collectively walked us through process of service request
  • Mechanic examines vehicle, finds an issue, issues a service request (all of this is written on paper and reported to floor chief

 

• Floor chief directs QC to examine vehicle and determine if a service request is needed

 

• QC examines vehicle and takes paper notes on what services he recommends for the repair process/if a repair is needed
• QC inputs information from check into GCSS with

 

LCpl Lawrence (OVE Officer) and LCpl Batton (OVE Officer):

• Walked through the process of performing OVE checks:
• Showed us the paperwork they fill out when a check is performed on the equipment for each vehicle.
• Simple checklist
• Confirmed that a scanner application would be useful in performing the OVE checks

 

LCpl Garrett and LCpl Mark:

• Determines where service requested parts are stored
• Uses Gunny List’s technology everyday, says it cut down his work from 8 hours to 1 hour.
• Information relevant to his job is contained in a barcode that he scans, the data is then taken from an excel sheet and the appropriate field is populated in GCSS

 

Sgt Zyglov:

• Helped us diagram flow of how an MPR is generated and what can be done with it
• Many different formats to export to, most important to us is Excel
• The Excel sheet contains the next date available field also, this is the most relevant to TCPT.

 

SSgt Christ (Head Dispatcher), Sgt Thomas, Sgt Hess, Sgt Howie (Dispatchers):

• Walked us through the process of updating personnel information and vehicle status in TCPT
• Confirmed the capability of TCPT to import excel spreadsheets for both personnel and vehicles but unable to determine whether importing updates different fields in TCPT. This highlighted an issue we had heard before, no one understands how these cool features work. TCPT has all these awesome capabilities but if no one knows how to use them it’s pointless.
• Reinforced the number of redundancies within GCSS and TCPT- there are multiple areas where they enter the same information
• Confirmed that connecting systems would lead to huge reduction in the time spent using TCPT and GCSS
• Suggested automating process from MOL to TCPT first since MOL is marine owned

 

Cpl Murphy:

• Walked us through how a 3400 sheet works
  • There is a barcode and QR code associated with every part.
  • These can be scanned into a computer with the ID Innovator.
  • This information is placed in the input of GCSS and uses keyboard emulation to do this.
• Showed us how he thinks we could potentially utilize the same technology for any maintenance app