Week 12: Looking Ahead

Key Insights and Decisions

 

The hypotheses we intended to examine this week were:

 

  1. Can we leverage existing technologies as well as our teams technical capabilities to design, develop and deploy Spear.
    1. After discussions with a few professors in the areas we will need help in as well as research into the field. It appears there are many interesting solutions to this problem out there that we can build our product off of. For example, Tamr Inc. is a database connecting company that is developing technology to automatically detect database types. Whatever information about the technology that is publicly available we will implement into our system. Designs and initial features will also be based on existing tools such as the Azure data lake tool.
  2. How can we develop this product in a way that would allow us to start making money and prove our concept while still making progress in final product development?
    1. One method of doing this we imagined, was individually build out solutions for customers on a case by case basis. This would give us experience with many different databases, and when we begin seeing repeating database types, we can implement old solutions. The end goal being creating a swiss army knife of database translations that our product can tap into to detect and translate between databases.

Next Couple Weeks:

  1. Refining our presentation and all of its components.
    1. Building out a UI wireframe for the pitch
    2. First four minutes
    3. Structure of second six minutes
  2. Work with Niebel on deploying in the Marine Corps.
    1. We got a response Monday morning but haven’t heard back since then.
  3. Continue to develop the scope of what we are trying to build.
    1. Talk to professors.

 

Interviews

 

Dr. Carlson

  • OCR – The publicly available Optical Character Recognition technology is roughly 99.99% accurate in transferring records. If we were to implement it in Medicine, we would need to also use Tesseract, Google’s Computer Vision tool, to validate our data.
  • TAMR – Data Integration company that is doing along the lines of what we are hoping to do. Their approach is much more about large scale data siloed integration through a large tool called Unify. They are working to develop a database translation tool that could be useful to us.
  • Azure – Data management tool internal to Databases. A drag and drop application to make writing SQL scripts easier but very limited. Could be a good place to look for inspiration for how to write the code for the tool.
  • Record Linkage – The buzzword for what our tool would be doing. Connecting entities from different Databases that are unrelated as far as the computer is concerned.

Dr. Cory Duncan

  • Emergency Room director in large emergency room in Atlanta. Roughly 175,000 patients move through the three ERs he oversees. His system is on Epic and have access to the patient records of patients who have been to other Epic clinics. He estimates that only about 5% of all patients in the country move through Epic systems.
  • In his specific clinic, about 33% of patients come in and their records are not available. In an emergency room this can be a matter of life and death as they may have certain conditions or allergies that could prove fatal if the surgeons don’t know about them. These records can take anywhere from 30 minutes to a full day to receive depending on how well staffed the clinic with the records is. His guess is four hours per patient.
  • There is an added cost of excess testing and imaging. If a patient comes in without records but says he has a broken arm, they either need to wait for the imaging center to fax it over or, more often, just image the patient again which is expensive.
  • In the private Emergency Rooms he owns in Texas, he estimates every patient comes in and needs records from somewhere else. Which is how he sees the majority of the country working.

Vicky Tamblyn and Kayla Rediner

  • Nurses at Dvorak Eye Clinic in Sauk Rapids, MN. Laughed when I asked if the problem of not having instant access to EMR was relatable for them.
  • They are not connected to Epic, every new patient requires them to get records from a different clinic. Process below:
    • First step is getting patient consent, which involves them mailing out a form, the patient signing it, then sending it back.
    • Next step is getting that signed form to the appropriate resource who has their medical record (past eye clinic, general family practice, etc.)
    • Next step is waiting for that clinic to process their request then fax over the patient records.
    • Next step is entering the information into their system.
  • This process takes roughly an hour of a nurses time combined but that isn’t their major pain point. The biggest issue is accurate information.
  • If a patient is diabetic, but doesn’t tell the eye clinic, they don’t request that information. So when the patient’s general doctor asks for the results of a diabetic eye test, they don’t have the results because they didn’t perform the appropriate diabetic tests.
  • Another example is if the patient is allergic to something that isn’t included in the report they get, and the medication they give them makes their condition worse.

Dr. Chakrabarty

  • Chairman of the ECE Department. Immediately understood the challenges we would run into with this product.
  • The most important aspect of what we are trying to achieve is the patentability of what we could do. His expertise does not involve any of what we are going into, but from a business and technology standpoint, he thinks the best scenario for us is to develop some technology that is patentable as soon as we can. With the idea being it gives us the advantage in the industry we need for funding and would allow us to distribute our technology to anyone without worrying about IP theft.
  • Thinks if we are able to make this useful for the average person he sees many applications of the technology, from building online stores from scratch with a few clicks to creating a version of IFTTT or Zapier that is customizable to non-programmers. The idea being if someone thinks, wow it’d be cool if this did that, it can with a few drags and clicks.
  • Wants me to do this as an Independent Study next semester. Putting me in touch with professors who could help more but also some who may want to sponsor my independent study.

Dr. Board

  • CIO of Duke University. Had the most coherent understanding of what we were trying to do and the challenges we would face. BAA for working with hospitals is the only way to do that stuff. We would be liable for everything the hospital is unless we prove we took industry standard precautions.
  • Three approaches to tool:
    • One is building out capabilities with as many systems as possible, using them as templates next time we encounter it. Problem is we would have to continually maintain our interfaces with the APIs to make sure it works. (Worst Option)
    • One is generating an “API Compiler,” definitely the most interesting option. Would be difficult, but if it works we would have a billion customers in way more areas than this. (Most Difficult Technically)
    • One is connecting directly to a database and reading from that. Issue is proprietary. What stuff is allowed to go through our system? That is the function of an API but if we’re bypassing an API we need to figure out how to only grant access to the fields the information provider wants us to. (Most Difficult Politically)

Pam Welle

  • Nurse at Minnesota Clinic. One of the nurses who actually goes through and gets medical information.
  • Laid out how here clinic does patient reports.
    • Patient makes an appointment, they request from the referring clinic for a fax of a subset of patient records they think is relevant. (About 90% of patients this is necessary for)
    • Depending on the location they request from, this can take anywhere from 30 minutes to an entire day and night. Once it is in, they have to spend 30 minutes or so translating the data from the fax into their system then scanning the records into their chart.
  • Overall she estimates each patient is roughly an hour of a nurses time to transfer information. So potentially way more time than we had originally estimated.

Nikki Lockett

  • Marketing at Whirlpool. Duke grad in Business, worked investment banking.
  • Couldn’t think of any examples at her current company but the job she had before that worked more with graphic designing there was a system for writing comments and they printed off those comments and were then distributed to the designers and the designers had to type in those comments to their system.
  • Other areas she has worked where stuff like this seems likely:
    • HR – Many systems that are responsible for different parts of the company
    • Global Finance – High level positions that see many divisions or regions
    • Acquiring companies – Consulting firms or big companies that are buying others, need Systems Integration. Maybe we simplify this.
  • Not the most helpful but really nice and could be a resource in the future when we have a more refined idea of a product.

Missy Barcelemy

  • Imaging Center Nurse. Their company uses three different EMR systems internally. These systems do talk somewhat but there are a few disconnects.
  • Emphasized how this could be a viral product within clinics as a marketing tool, “Patients won’t want to go to clinics who don’t have you because they’ll be deciding between a place that faxes their information back and forth and a place that is seamless and immediate.”
  • Story about a nurse who had bad headaches for a few weeks, finally got an MRI and it showed a massive blood clot in her neck that could have killed her. They sent her to the appropriate physician who asked her for the images, she didn’t have them because she didn’t think she’d need them since they were in her system. The doctor didn’t have access to their system so her husband had to sit on the phone for thirty minutes with the other clinic trying to get the information over as quickly as possible. Meanwhile, she could have died any second from this.

Mr. Britt

  • Freight Shipment Control Supervisor – his group arranges the commercial shipping needs.
  • Process begins when a unit submits a DD1149 TCM. That comes to his team in the CMOS system (Air Force software). From there his team routes it to the SDDC system from which it goes out to industry for bids. Once those bids come back, his team lets the unit know which provider(s) will be servicing the move.
  • According to Mr. Britt, there are no data transfer gaps in his groups workflow to address. After probing much more closely – “walk me through that step by step”, “where does that data come from” – it became clear that at a minimum TCPT is not connected on the final step.
  • That final step involves his team going into TCPT to enter: #Trucks, Cost, Bill of Lading #, Carrier, Type of Truck. On average, he estimates his team spends 10min/day entering this info into TCPT. The rare large order involving 100 trucks takes much longer but those are few and far between.

Chief Parker

  • Air Mobility Officer II MEF
  • Chief Parker has been the business SME for development of the SSDM system. That system was just started in 2015 so he specifically wrote the specifications so it integrates with the related applications. While there should not be many gaps, he strongly believes he is not going to get entirely what he wanted. He expects that he will not get all he wants from the TCPT connection. The API will likely be able to support tactical movements without a problem. However, he does not believe the API will support all the data fields needed for movements that require Commercial.
  • He walked me through the process of building SSDM. Concept was proposed in 2012. Funded to begin development in 2015. The program office found a contract developer and Parker defined the requirements just as a technical Product Owner / Business Analyst would need to do. He was taken aback by the amount of detail and work involved. Each API takes about a year to deliver from concept through coding. He has been able to work multiple APIs in parallel.

Week 11: Continued Discovery, Technical Assessment

Key Insights and Decisions

The two hypotheses we intended to examine this week were:

Is there enough inefficiency in the EHR hierarchy to warrant further discovery?
After further discovery with Medical Professionals, it appears that this is an even bigger issue than we had originally anticipated. The worst patient scenario for a clinic, the referring clinic not having the same EMR system and not sending along patient records, happens roughly 30 times a day out of 120 patients for a mid-size specialty clinic, or 25% of the time. Each occurance of this takes roughly 20 minutes, meaning this specific instance of copying faxed information over costs a clinic more than 5 hours per day transferring patient records. These are nurses making about $30 an hour. Amounting to over $39,000 a year, for each mid-sized clinic. Extrapolating across the entire country to 25,750 health clinics fitting the description of in and outpatient care, we find the total savings at roughly $1.01 Billion being spent on this specific issue. This is only taking into account 25% of the data transfering they do, meaning we could potentially find more savings within each clinic.

Do we have enough talent in house to manufacture the fundamental technology?
While we are still working on consulting more experts, the conversation with Dr. Yiran Chen has given us the impression it is certainly possible for us to build this technology off of publicly developed programs in Database conversion and Optical Character Recognition.
This project, while as an overall design may be intensive, has very few new components. Simply, we will leverage many existing products to create a more encompassing tool than what currently exists. This means that internally, with the help of some Code Monkeys, we will be able to create a functioning version of this product. More robust and encompassing versions will require at least Junior Developers to complete. So, while we continue consulting Software Experts, we will continue to assess our teams readiness to complete this project.

  1. Next Couple Weeks:
    Continue to address two major areas of concern:
    What technology will be required and how much development will it take. While we are not planning to build a functioning version of this for a few months, we want to continue understanding the framework of what we are designing.
    What specific tasks could we tackle first that would lead to a small stream of revenue as proof our idea has value.
    We will also wireframe a sample UI, one that we would potentially use for initial customer discovery as we continue talking to prospective beneficiaries.

Interviews

Dr. Julie Anderson
Started her own private Primary Care facility. Primary is the major source of referrals, she is much less dependent on other doctors patient notes. The majority of her patients she ends up referring to a specialist, meaning they need her notes.
She is apart of a Conglomerate healthcare system called CentraCare. She uses EPIC as she is apart of this system, and that allows her to very easily send patient notes to other physicians within CentraCare. However she ends up referring about 25-35% of her patients outside of CentraCare meaning she has to share patient notes with other systems.
When this happens she has a nurse scan and fax over her notes to that clinic. However, there are times she either doesn’t know what information is relevant or forgets so she will recieve calls asking for the records or a more detailed version of them.
For her, this is not a huge pain point as she is able to keep a lot of the referrals internal and all her notes are viewable to the internal doctors. But before she wasn’t involved with this large group, this was a frustrating part of her job.
Worried that the large EHR businesses will not want us getting involved.
Next area is where she suggests us looking is Imaging. Will give a contact.

Dr Chris Roth
Radiologist at Duke Hospital and Vice Chair of Information Technology and Clinical Informatics Director of Imaging Informatics Strategy, so deals with EPIC and related systems frequently
EPIC allows for information to easily be passed between clinics/hospitals all on EPIC, but this is not all of the patient information- only information mandated by the ACA and stored in subsystem called EPIC Care Everywhere
Automation may not be the way to go because you don’t want to share all patient information between hospitals
Getting information from clinics/hospitals that don’t use EPIC can be a pain- have to call specific department, ask for files to be transferred and those files often end up getting faxed or given to the patient themselves to deal with
Imaging is a different process, and EPIC can’t transfer imaging. Duke and UNC have a shared system that allows for them to transfer imaging from one place to the other but there is no standard there
HIPAA likely prevents automation of non-EPIC information- have to ask patient permission in order to authorize that transfer and so automation would be difficult

Dr. Billy Willis
CTO of Duke University Health Care System
Duke Hospital along with 70/80% of hospitals use EPIC- transferring information is easy between places that both use EPIC
Additionally all Duke Health Clinics run on the same EMR system as Duke Hospital so despite not using EPIC there aren’t problems transferring data between the two places
Clinics that aren’t part of Duke Health have no standard way of transferring specific patient information. There are programs that can be used but there is no standard
Harmonizing patient information is big in the health care world right now, since more companies are moving to a value service from a fee-for-service so we might run into larger companies trying to block us

Yiran Chen
Ph.D. in Computer Science/ Electrical Engineering. Talked with me for a half hour about this project and what he knows about the spaces we are getting into.
Brother has an RPA firm and knows a bit about what he does, says his firm goes into businesses that think they have a computing problem and then figures out what the problem is, then has a team that builds the software to fix it.
Says it is profitable and that there is plenty of room from what he’s seen. There is high demand, and that is just from people who know that they have a problem that can be fixed. He thinks the majority of people don’t even know that software can solve some of their problems so RPA firms generally aren’t going in to talk to random clients.
The idea of a software tool for creating backend infrastructure is something he hadn’t thought much about, but pointed me to a professor who specialize in DB design.
He wants us to look into OCR by Google and Facebook as potentially free ways of building a Machine Learning app to read in PDFs

Ben Spain
Siloed systems
Have to go all the way to the top to get things to start working
Even generals can’t do much
Contracting for software
Once contract is approved, there’s little recourse
Similar TCPT/MOL situation in USAF
An attempt to put everything on one system back in the 90’s is terrible
Why isn’t there a mandate for products to be integrated?
People writing contracts are not experts
Turnover
Potential legal restrictions
RPA
Loves the idea, happens a lot
Definitely sees a lot of application from the USAF side
Ex: flight scheduling, still doing on paper and then pasted into a computer algorithm
Ex: training, lots of individual training programs as a pilot; each flight has a grade sheet compiled into a grade book; lots of regulation on how those books have to be kept/reviewed; have the review be done automatically + prevent wrong info
Ex: post-flight reports; can technically put in he flew 28 hours and system wouldn’t stop him
Even thought about making and selling his own software
Genesis
VA doesn’t talk to USAF medical records
Print + bring records physically
Ex: saw Dr. twice in Kuwait, those visits recorded in USAF med record

Patrick Nevins
RPA Projects
Helps lead the business in public sector practice
Used a lot in back office (HR, financial management)
Civilian DoD, Health, Justice, etc.
In-House MVP
Find a vendor (can get us names, ???)
Software companies that own the software packages that run RPA
Automation Anywhere, BluePrism, UiPath, CoFax
UI interface/backend looks different for each
Lots of them have free user trial licenses, see how they structure it
Building from ground up
Feasible with talent set (dispatcher problem), just keep it simple
Biggest hurdle would be mimicking client’s environment
Gaining access to systems/information
Funding issue will always be there
What contracts does BG have?
Could have contract that hasn’t reached funding cap
Could be given $ to develop PoC as a part of that larger contract
Would want to find a way to add onto
Deloitte usually tests MVP’s outside of client systems, but still need the correct information to test
Genesis
Look at the VA to see their EMR

Adam Beauregard
Former Aviation Operations officer in US Navy.
Followed up with Adam to go deeper into a couple of off-hand comments he made when I first spoke to him two months ago that now have more relevance.
I asked him about the reason for the white-board containing aircraft status and upcoming missions that he referenced in our original conversation. Initially, he chalked it up to established procedure. Upon probing deeper, that procedure is in response to the fact that the aircraft maintenance system is not connected to the mission planning system. This results in a weekly meeting pattern and the resultant white-board for resourcing missions. The roots and effects are highly analogous to the Marine dispatchers.
Adam also cited that the Navy has 4 personnel-related systems – awards, leave, physical fitness, and overarching central personnel system – that do not communicate well. For example, a person receives an award – it is immediately in the award system but usually takes a couple months to be populated into the central personnel system.

Dale Swink
Director of II MEF MMCC
Dale took the results of our work on TCPT and contacted 10 of his colleagues on our behalf with the goal of generating interest in advancing the TCPT implementation as well as the identifying other potential use cases our solution might address. The roles contacted include – the GCSS program manager, the TCPT program manager, as well as personnel whose roles involve working with other applications Dale is aware of that need a connection to TCPT.
Dale identified the following applications that require manual rekeying or data hand-offs
Cargo Movement Operations System (CMOS), POWERTRACK, MMCC Access database, SSDM, GOPAX, SABERS, Fleet Anywhere, Airforce DD1149 website, ITV.

Douglas Kaminsky
Engineering Lead at MongoDB, previously worked tech at Bank of America and Broadridge
Dual-use
Finance
Lots of information needs to be readily available across platforms to create a “public marketplace” of info within firms
Information is currently difficult to coordinate amongst different teams, causes inconsistency and too much redundancy

Mr. Allen Byrne & Mr. Torres
Byrne
Deputy SPO of Army Support Battalion, 1st Special Warfare Training Group
GCSS-A expert who is intimately familiar with the processes and uses of the system
Business applications/management/reports
Can see anything on GCSS w/ proper permissions
Torres
Supply and maintenance supervisor, very familiar w/ GCSS
Army transitioned to GCSS 3 years ago, seem to have a much more positive experience than GCSS-MC
Phased out all legacy systems (equivalent to TCPT, MCTMS, etc) and now only use GCSS for most things
Since making the transition, supply and maintenance takes 5 steps instead of 3 (for example)
Training is required for all people, and necessary to operate system, but there are help buttons on every GCSS page that walk you through everything step by step (first time hearing of this)
Legacy systems DO talk to GCSS-A, but there are issues with it
Whoever did what we are trying to do messed up the process, data is communicated between systems incorrectly
Both emphasized correct data validation a LOT
Asked if we wanted to visit Fort Bragg and do MVP testing

Connectivity Opens Doors

Key Insights and Decisions

 

Key Decision:

 

  • As we explored both the input and output of relevant logistics information into and out of the maintenance area of the Marine Corps, we realized our goal as a group was becoming extremely spread out. As we began thinking about how we could wrap up two different problem that were connected but still required separate solutions, we came across an article explain a issue similar to ours that finance firms encounter and have hire outside firms to accomplish similar goals to what we have been proposing between GCSS and TCPT. After deliberating as a team, we have decided focusing our remaining few weeks on developing and enhancing the “Connectivity” piece of our teams overall model. This means we are abandoning the idea of a maintenance app for a few reasons.
    • The solutions to the input issue only tackle small parts of it and none of these issues caused enough pain nor solutions caused enough value to make it worth the effort of developing a product to solve just one pain point.
    • A solution that would provide enough value to be worth development would potentially require a significant amount of time to develop as well as would require an amount of cooperation that has seemed to be unreasonable from the 2nd MLG.
    • In the private sector, this idea of connecting isolated systems is perhaps more important than we had originally believed. An industry that was at $250 million in 2016 and is projected to reach over $2 billion in 2021. We may be a bit late to the party, but having worked with the Marine Corps to understand some of the most fundamental issues with systems that do not communicate and understand the value of a flexible solution that could potentially continue to evolve into a valuable tool that requires little technical knowledge to use. We believe this along with the idea that most of the companies who have utilized this service are primarily large cap corporations that have the money to spend on customized services. If we are able to develop a generic solution, we would allow for business of all sizes to benefit from systems that communicate.

 

  • We will spend the remainder of the semester exploring areas (Beneficiary Discovery) of both the public and private world where this appears to be an issue, with the goal of sizing a market and developing an extremely rudimentary version of what could potentially be used outside of the Marine Corps to solve this reoccurring issue.

 

With that being said, the hypothesis we intended to examine this week was:

 

  1. The idea of connecting siloed systems is one that would provide significant value to other areas of the military and civilian industries through saved time, more accurate data, and more timely information.

 

This week, in part because of Spring Break, in part because we changed directions, we were unable to fully attack the areas of the hypothesis we had hoped we’d be able to. However, we were able to look into a few other areas that seem promising for expansion. The one area we have had the most luck in finding beneficiaries on three minus day notice has been healthcare. We have been able to talk with the retired CIO of a hospital, a CTO of a health IT start-up, as well as the head nurse at a private clinic regarding the practice of sharing medical information between clinics, hospitals and other healthcare providers. The overarching idea being that clinics with different Electronic Healthcare/Medical Records (EHRs/EMRs) systems have various but similarly labor intensive processes for keeping patients records updating in their own system. All of which require varying levels of the manual entry of data from another healthcare provider’s system to their own.

Next Couple Weeks:

 

Interviews

 

David Ward:

  • Four different clinics he has worked with has asked if this is an issue his company could solve. While his company is not in this business, he has often noted the demand for this.
  • His understanding of the process:
    • There is one major player in the EMR system business in his area (EPIC), large healthcare groups (conglomerates, hospitals, etc.) are the firms that can
      • Afford it – Many clinics that don’t have the large revenue base either from the government or private practice are unable to pay the large cost of EPICs system.
      • Be payed attention to – There are many specific features smaller clinics or groups need for their specialty, size or simply because they want it. And EPIC does not have the capacity to implement changes into every individual organization and thus reverts to only customizing the larger groups. Therefore, smaller organizations are forced to contract out their work, often resulting in 5-10 EMR systems implemented within even a small community.
  • He was unfamiliar with the specific process of transferring EMR data between clinics but has said he can get us plenty of people who do (including Emily Jacobs, see below)

Emily Jacobs:

  • Overview of patient record transfer:
    • Roughly 5% of the time, the referring clinic/hospital has the same EMR system and in that case all information is perfectly transferred, no paper.
    • Three ways patient information gets from one clinic to another (Keeping in mind that at the other clinic that the patient came from this information has already been entered into their chart.):
      • The referring doctor sends the patient notes over with them (20% of the time). When this happens, the receiving nurse takes the patient information (PDF/Handwritten) and enters it into that patients chart in their EMR system.
      • The patient’s notes are not sent over but the clinic has access to the online system of the other clinic, meaning the nurse logs into the other system, prints off a PDF of the information and then manually enters it into their system. (50% of the time)
      • The patient’s notes are not sent over and the clinic does not have access to the online system of the other clinic. This is the absolute worst scenario for them, they must call the other clinics and request the information. This takes hours and sometimes doesn’t get processed until the next day. Resulting in patients care being delayed as their information on prescriptions, diagnosis, and recommended action are unknown to the receiving clinic and likely the patient as well, as this information is generally technical and requires very specific components such as amount of a certain medication or specific muscle/bone/organ that is injured. (25% of the time)
  • “Certainly one of the most frustrating parts of my job”
  • This is an issue with 95% of patients meaning it is happening from the time they open until close.
  • Has a couple other nurses in her clinic she wants me to talk to.

Capt. Baker:

  • Informed her of our change in direction toward a focus on connectivity. She understands the decision and supports us, she is hoping to get us through the Defense boundaries in order to get our solution implemented effectively.
  • Discussed who we need her to call for military contacts. These will be people we hope to expand our efforts with
    • Medical Group
    • Engineering Support
    • Infantry
    • Special Forces
  • Need her help with TCPT and GCSS
    • Have the project manager of GCSS’s name but need to get in touch with him
    • Need the PM of TCPT
    • Need some sort of IT team to talk with.
  • She is planning on calling them all this week and will hopefully have a few names for us by EOW.

Parker Erickson:

  • Does not work in RPA/tech space; only insight is from a policy perspective
  • Could see RPA being beneficial in a lot of ways
    • Interest groups often have tons of personal data about constituents (name, address, etc.) but lists can be outdated/inaccurate
    • Healthcare ERP
      • Cut need for bloated admin staff / get doctors more patient time
    • From lobbying prospective, attending/scheduling meetings, conducting research, sending/processing emails would be nice to have automated
      • Interns might send the same email to a list of Hill contacts dozens of times
      • Would be helpful to RPA search congress.gov, find appropriate contacts and then email (e.g. letter of support w/ correct office, addressee, etc.)
    • Personally, would like to have expense accounting automated
      • Keep track of receipts, submit to accounting
      • “Pain in the ass”
      • Does at least once a month, can take several hours

Cpt. Trinh

  • Seymour Johnson AFB has made substantial progress since Team 5
    • Revamped workflow
      • Moved pharmacists to filling station
      • Pod system
    • Delegation of hours
      • Call in and activate refills, can’t pick up until next day
      • Refill during off hours
    • Text notification
      • Turned on for refill verification
    • QFlow
      • Still down, not fully integrated
  • RPA
    • USAF already doing this for MDG’s
    • Genesis
      • Cnytrx?
      • DoD did a bid on it 15 years ago to integrate entire medical system
        • Order drugs, verify scripts, can pull medical records from different bases, etc.
      • Currently in Phase 1 (1.5yrs), rolled out around half a dozen bases (USAF, USN, Army)
        • First year rough, bugs fixed and new features added
        • But, if one system goes down, you’re sort of left with nothing
        • Planning on rolling out DoD-wide in 5 years (doubtful)
        • Overall, very positive response

Charlie Covin

  • IT-based communication between hospitals and clinics is a longstanding problem area for basically every area of operation: ordering tests, transmitting results, patient record exchange, payment/reimbursement, scheduling.
  • Communication between institutions is quickly escalating in importance due to the progress made in implementing electronic medical records (EMR). Hospitals/practices have largely put their own houses in order with regards to implementing EMR systems.  Now they are looking externally. There is not an EMR standard. There is also not an intercommunication standard for EMR and other areas. As a result, hospitals and individual practice systems frequently cannot communicate.
  • This is not a sporadic situation as it is not uncommon for a physician with hospital rights to have his practice on a different system than the hospital.

 

Dale Swink

  • Thrilled to hear about the progress on connecting GCSS & TCPT.  He just met the Colonel in charge of GCSS recently and should be able to find the contact info.
  • Because of his group’s work, he is exposed to a number of different systems that do not communicate but should. As a result, he sees lots of “swivel chair” hand-offs between functions. He actually wrote a paper about it and will send it over.
  • At least one of the groups he works with – and requires a swivel chair handoff – uses a Navy system. Chasing this one down could lead to applications within the Navy.
  • He volunteered to circulate a write-up of the dispatcher solution to some of his contacts to surface even more areas in which it might be applicable.

John Myrka

  • Thrilled to hear about the progress connecting GCSS & TCPT.  He has the contact info for the TCPT program manager and will send it over when he gets back to the office.
  • Bridging a one-way connection from GCSS to TCPT is great. It would be even better if you could also go from TCPT to GCSS. (This was news to us!) Turns out motor operations should be entering the vehicle mileage from last service back into GCSS to spark the routine maintenance cycle.  I wondered at why no one had mentioned this in all of my conversations. Our guess is because people just aren’t doing it because of the hassle.
  • John also cited a number of other processes that have inter-system gaps. On the supply side – there is frequently a gap between the Distribution Management Office and Material Distribution Center.  Specifically, only partial data is communicated such as the first line of a crates contents. That means that the Material Distribution Center is aware one of their parts is on the way but has no idea what else is on the way.
  • John also raised additional gaps that took us into potential applications of the scanner technology and app concepts we explored for other areas.  He saw promise in a few different areas particularly for forward operating elements such as MARSOC operating in low bandwidth environments that could not support full GCSS.

Lejuene Trip #2

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

Week 8 – Progress on Phase 2

Key Insights and Decisions

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

 

  1. Would an automated equipment inventory and vehicle checks provide value to Operators and QC Chiefs?

 

It really depends on what we do with it. By simply making the process automated, i.e. some sort of app that just allows them to select from options, we won’t save much time on the floor. However, we would be able to make information much more accurate and be processed faster. As we progress to more sophisticated technology, such as scanning or image recognition, we would be able to significantly cut into the time spent doing this. Every day they have to start every vehicle and they do inventory multiple times a month. If eventually, these processes can take place without 1) time spent by Marines and 2) human error, it would be an incredible achievement and have impacts far beyond the individual companies but would save thousands of hours within companies.

 

  1. Having the ability to upload status’ of vehicles with a mobile device would save time and provide greater reporting accuracy.

There are many applications that a scanner or computer vision project would have in terms of improving the maintenance floors logistics, among which are vehicle checks, service requests, and LTI replacements. The primary beneficiaries differ by area of help but virtually every area of the Maintenance Battalion would benefit from some aspect. In all aspects, we have gotten relatively positive feedback regarding how much they would help, but we need to drill further into how exactly that would be accomplished. The goal eventually would be to combine all of these into a single autonomous system that removes human error and bias from the reporting and assignment process.

 

Next Week: We will be heading down to Camp Lejeune to actually meet with these potential beneficiaries. Our plan is to narrow down on the inventory checking if that proves to be as big of a problem as we believe, however, as we learned last time we were at Lejeune, the issues we believe exist may be a bit off base from what are actually present. So we are hoping to get a closer look at these areas.

 

Gunny List:

  • Wants us down there now. “Can’t understand it until you see it”
  • For barcodes on equipment:
    • He is planning on getting external barcodes and gluing them on or etching them into each piece of equipment.
    • Another option could be to use computer vision. There is a toolbox they use now that does the same thing with tools in a toolbox.
  • For developing an app, whatever we do, the most important thing to think about is what happens when it breaks.
  • GCSS/LTI – Reports for LTIs can be exported to Excel
    • Idea would be to have each shop set up an automatic report generation that automatically gets dropped into a folder. Our program would read from that folder into a mobile platform to output tasks to everyone on the shop floor

 

MSgt Richard:

  • Ops Chief: Been trained on motor vehicle operations since he first came into the Marines. Doles out equipment and personnel for missions.
  • He picks the time to do equipment checks and the Maintenance Chief actually determines what they do.
  • OVE check not really a thing. There is an OVE (SL3) NCO who does it all, this is assigned by Ops. Chief.
  • Has been involved in many conversations for automating parts of what we’re looking at with off the shelf trucks. Data is captured by a piece of paper is the part that needs to be changed. Wasting time by doing it. Also, there is a risk that it doesn’t get discovered.
  • An app that allows people to submit requests in some form would be awesome as what often happens is that many people don’t report things and it doesn’t get reported until 3 or 4 people down the line.
  • Mishap report module and that allow the Dispatcher to update service requests. Our app could make this connect to GCSS. The connection between the two systems is two way.
  • Connecting the systems would be a huge win… Funny we didn’t even have to mention it.

 

Cpl Stotsenberg

  • He is the GCSS specialist for his Motor Ops group.
  • One of the big headaches he has is operations that need to be addressed for several different vehicles such as a new modification.  The request to modify each vehicle has to be done individually and takes 10-15 minutes. It would be great if he could enter the request and associate several serial numbers.
  • OVE checks are done and maintained via paper records that are kept in the vehicle jacket. Supposedly the checks are being done daily.  However, last year he had to order a bunch of miscellaneous equipment over a short time period. This indicated that the checks had not really been getting done properly.
  • Vehicle checks face problems similar to the above.  Recently they found a broken window that likely had been that way for more than 24 hours.  That lead to back tracing through the paper reports to find who had been doing the checks and who had been signing-off on their work.
  • He believes an app to help manage OVE and daily maintenance checks would make things easier for the operator. It would also make things easier for him as reading handwriting for the service requests is often problematic.

 

Scott Frederick

    • Background
      • Used to be a Cobra pilot, became finance (disbursing) officer @1st MLG
      • Speak to Congressional leaders, deal with fiscal inquiries
        • Considered special staff
    • Finance Officer is only at the highest level
      • Can be either disbursing officer + Comptroller
      • Two Types of Finance Officers
        • Comptroller = getting money from Congress, disburse the money down to the units, typically pass money to supply officers
        • Disbursing = quartermaster pays Marines, pays out travel allowances
    • Battle Command Display (requested not to specify which units)
      • USMC and other branches are still using paper to keep track of most things
        • Frederick is aware of some commands in USMC developing readiness dashboards
        • Ex: Commander sticks CAC card into the computer, open up BCD, looks at entire MLG, motor pool will have yellow/green/red code (e.g. air filters, only have five, but system wants 8 at all times)
      • Knows of limited working prototypes developed in-house + private contractors working in this space
    • Advice
      • Look into Yardi
        • The massive company that creates dashboard-type software for the private sector
      • Commercial real estate software
        • Poke around, they have a couple of tools
        • Real estate management is very similar to military readiness
          • Property Management
          • Asset Management.
    • Wing version of MLG’s?
      • MAL’s
        • Cherry Point, NC (jets)
        • New River, NC (choppers)
    • GCSS Programming
      • Best way to contact them is through the MLG, need their approval to speak
    • Network Outages App
      • Everything needs to work in war

 

  • Get a physical output feature of some kind

 

  • A dashboard should print out a physical report that he’s used to seeing
    • Ask CG (or whatever level of leadership) what he’d want on his report + how current

Lt. Chris Gierl

    • Works for Chief of Naval Operations (2mo)
      • “HR consultant” in the Pacific NW
      • Surface, submarine, etc. forces
      • Inherent Resolve works for rescue in F-18
    • Navy F-18 Maintenance/Inventory
      • “X of Y part”
      • Probably more high tech than the Marine Corps
      • UMA (TCPT for USN planes)
        • Each plane has a binder that has the plane’s maintenance history
        • Kept updated and old things cycled out, but papers still kept and backed into the database
        • Haven’t really addressed what would happen if that database became inaccessible; very little trust in IT infrastructure; leadership believes they could survive on their own if need be for a while
      • Not digitized in terms of input

 

  • The app should have the capacity to print from the device, even before upload

 

    • Output
      • Not quite sure how clean it is
      • Can see where parts are and reach out to get it
      • Just used an excel sheet and projected it on the wall for maintenance
    • Connectivity
      • Being on a boat/sub isn’t ideal for connectivity
        • Collect inputs, cache them, and then inputted into the system when the connection returns
        • Becoming more paperless, uploaded to a database, transmitted when possible, paper reports printed out
      • Have had IT people make scripts and optimize systems talking to one another
        • Think just having one system would be helpful
  • Advice
    • Why do two databases? Try and change that, if possible
    • Intermediate game plan
      • What will get us to our final destination? What is step B?
    • Would assume the aviation side of Marines would similar to USN

GySgt. Sanchez (Ops Chief), Sgt. Chris (Chief dispatcher), Cpl Pena (GCSS), Cpl Valez (GCSS Chief), Cpl Gonez (Dispatcher), LCpl Berg (QC), LCpl Michskari (QC), Cpl Miles (QC)

    • Operations Chief
      • Ensure day to day operations are completed effectively
      • Works directly under Cpt. Hatchet (company commander)
      • Oversee GCSS Chief + Chief Dispatcher + QC
    • Preventative Maintenance Check (PM)
      • Take a manual (pictures/checklist) out to the vehicles and go down the list; write down anything out of place
    • OVE
      • Two types of check: one if it’s going on the road vs. one if it’s not
        • Going on Road (TMR)
          • Only need to check 3 pieces of equipment
            • Emergency triangles, first aid kit, fire extinguisher; no matter what
            • Depending on load, more equipment might be needed (e.g. chains for cargo)
          • Checklist records equipment taken on a mission; same form with different things checked off depending on mission
      • Monthly OVE checks
        • Every vehicle/trailer in the motor pool has an inventory sheet/record jacket
        • Inventory sheet has pictures/checklist, work down the list
    • Time Costs
      • Road Check/QC
        • 1 hour/vehicle
        • The purpose is safety, checked 1x before it leaves, 1x after it comes back
        • 15-20/day, 30 min x2
      • PM’s
        • 0.5-1 hour/vehicle
        • 10-15 Marines, all week (400-600 hours)
      • OVE Inventory
        • Depends on the vehicle (15min-2 hours)
        • 10-15 Marines, all week (400-600 hours)
    • Concerns about the Scanner
      • Concerned about getting screwed if the network goes down and they’re relying on an app
      • It would help speed things up, but it still takes a Marine to go out there and physically check; system integration would help several times more (“day and night”)
    • Wants
      • Want vehicle TCPT status updated automatically
      • Want GCSS and TCPT to talk more (our original prototype)
      • Equipment status changes all the time, so it’s incredibly difficult to keep updating the status of everything manually on two systems at once
    • Motor Pool Company Organization
      • Operations Chief
        • Truck Master
          • Chief Dispatcher
            • 2x Dispatchers
        • GCSS Chief
          • Opens and closes all service requests
          • Orders all of the equipment (supply chain)
          • Pena, Williams, Valez
        • QC
          • Heavily engaged in dispatching procedure
          • 3 Marines
      • 1st Sgt.
        • Admin
      • Platoon Commander

 

  • Two motor pool companies (3 driver platoons each, 1 ops platoon each)

 

      • Platoon Sergeant
      • Oversee 55 Marines (drivers, fuel operators, vehicle recovery)
    • XO
      • Admin focus (similar to 1st Sgt.)

1st Lt. Sanchez

  • SMU is the unit responsible for actually delivering equipment needs.
  • Existing solutions for tracking inventory in commercial space such as how Amazon or USPS track inventory could be interesting to compare with. A concern is that the Marine Corps is too unique in how they do things.
  • Image Recognition and Scanning
    • Image Recognition – Only way this would be helpful is if it was actually accurate. — Obviously a goal…
    • Scanning – They need it to be durable and flexible. It needs to be able to withstand any number of problems.
  • For a prototype, try  MWSS or CLB/TSB/ELB because of the amount of gear
    • Each of these segments is responsible for “an insane amount of gear”
    • If we want to try our solution in one place, a company that uses a lot of gear is the perfect place to try it. She would be willing to let us use her company.
  • Engineering vs. Motor Transport
    • Engineering: Bravo in TAM, they handle it better, look there. You can’t just merge it because there are many differences.
    • Motor Transport: Delta in TAM, has always been the worst because of the quantity and type of equipment used.
    • Alpha and Charlie equipment are Comms and Weaponry, much smaller and less volatile. Procedures for handling this equipment is likely not applicable to Delta.

 

MPR Auditing vs. Maintenance App.. Where the Majority of Value Lies

Key Insights and Decisions

Going into this week, we had two hypotheses we intended to examine:

 

  1. Would the ability to have a Maintenance Production Report audited autonomously provide value to a higher level, Quality Control level Marines?

 

It turns out that this sort of tool would primarily provide benefit to the Marine’s in charge of validating the service requests. By scanning through these reports for common discrepancies, we would present the Marine who is responsible for checking (MSgt. Lemus) with flagged items to check over more carefully. He would

 

  1. Having the ability to upload status’ of vehicles with a mobile device would save time and provide greater reporting accuracy.

This is an issue we approached before, one that we believed had a solution. We discovered that even if it is coming, the Marine Corps will not have the infrastructure needed to use it. There are many applications that a scanner would have in terms of improving the maintenance floors logistics, among which are vehicle checks, service requests, and LTI replacements. The primary beneficiaries differ by area of help but virtually every area of the Maintenance Battalion would benefit from some aspect.

 

Next Week: We will need to focus in on hypothesis two and determine which area in that we would first like to pursue. We will also need to decide which of hypothesis one or two would provide the most benefit.

 

Capt. Bender

  • An app that helps the operations side track QC checks would certainly have an impact on the groups with larger motor pools. Far less meaningful to units with only a couple of vehicles.
  • Applicability of the app to aid in the area of assisting readiness in actual deployments is likely a lesser case due to other tech in the pipeline.
  • The concept of an audit tool around the MPR is interesting. It would be a tool for both line managers and back-end managers.
  • Another area ripe for more study is applications of big data analytics. Ultimately, to truly advance this area we concluded data access and security clearance would be required.
  • Significant discussion of parting thoughts and advice and Capt. Bender retires and sponsorship shifts to Capt. Baker.

 

MSgt McLaughlin

  • TCPT expert. He knew about all the different fields that we would need to transfer between systems.
  • TCPT does auto-populate data with Excel sheets but not the date available field that we believed it could. This was the whole point of our idea, so it makes no sense to go down to Lejeune now.
  • TCPT can update the relevant information for the personnel side through excel, however
  • We will not be going down to test anymore, as it is a waste of time, we will instead prep a microservice to present to them that they can take to their vendors to fix or have us install. THere is no way to do it without having some form of access to their APIs.

 

MSgt Lemus

  • MSgt Lemus and GSgt List have spoken and are now on the same page regarding the desired outcome of an auditing tool for the MPR.
  • The tool would highlight shortcomings in various policies and provide concrete evidence for amendments.
  • While less close to his concerns, an app for frontline personnel that reduces the time to updated GCSS while increasing the accuracy and frequency of the updates is certainly powerful.
  • There would also be a significant power in demonstrating a better model for enabling frontline personnel with computing power.
  • Discussed details of the Friday test and visit.

 

GySgt List.

  • Knowledgeable source on many different areas we are examining, however, very eager to show he is different from the rest of the Marine’s, seems like he may be over exaggerating issues because of this.
  • In regards to the Auditing tool:
    • There are tools existing that do this but do it poorly. A tool called CCLM has a readiness rating for each part. Essentially would do what we are trying to do but it is just horrible at doing so. The ratings are very skewed and never really followed, so basing a tool off of this would be inaccurate.
    • Wasn’t a huge fan of the idea until he talked to Lemus after our call.
  • In regards to the Maintenance app:
    • He is working on a tool that will scan in equipment during inventory. It uses the QR codes on equipment to register it.
    • Says if we could make it do even just one of the parts of the maintenance process we would save hundreds of people time.
    • If we want to use the QR codes, he could give us a list of fields contained in the QR code.

 

SSgt. Clemens

  • Truck master in motor pool
  • Has the permissions and ability to export from GCSS and MOL
  • Can export reports from MCTIMS (training sheets and licensing not Excel, but can convert it over?)
  • To modify an entry in TCPT for a vehicle — right now just modify date available and status fields
    • while using TCPT, navigate to tabs at very top → equipment tab → equipment profiles → availability
    • TCPT has no set format because file just sits in the system
    • Date Available field inputted into TCPT for equipment is generated from dispatcher knowledge, NOT in GCSS
  • Can import docs into TCPT but it doesn’t do anything (can just be stored in places)
  • No specific export button in GCSS, just option to run the report
  • Can change user status, manipulate things, but can’t do that in MOL, only in profile on personal account
  • He has unit leader permissions that allows him to modify other profiles

 

MSgt. LeClair

  • Idea for an app to assist preventative maintenance is a big opportunity in his view.  He is Truck Master for 73 trucks. Marines spend 2 weeks of the month conducting preventative maintenance.
  • There are Marines out doing it now in the rain. Ink is bleeding, paper is getting ruined, the Marines are having to recopy everything once they get back inside.
  • If a vehicle needs to be inducted into maintenance, then GCSS needs a service request opened and vehicle availability needs to be changed in TCPT.  Otherwise, if the vehicle passes, there is no computer entry. The completed paper checklist is simply put on file until the next round.
  • An app to assist with OVE (On Vehicle Equipment) is also a major winner.  There are 50-130 pieces of equipment for each of the 73 trucks. They have 4-10 operators a day tasked to conduct OVE checks.  
  • It would also be valuable to supplement the OVE checks with an equipment check-out/check-in process.

 

SSgt. Crady

  • Already existing tool called Maintenance Management Toolbox that scans MMR (similar to MPR but more in-depth) and highlights inconsistencies between parts’ priorities, missing data
  • MMR is a report more for maintenance people; officers (who want more concise information) and people who aren’t familiar with the information on the MMR may find a similar tool for the MPR helpful
  • Noted that a similar tool may be helpful for a counter report, for when mileage has to be updated after a long trip in a vehicle. This information must be updated correctly after such a trip happens

 

Patrick Nevins

  • Does work for the Air Force on logistics, I brought up the idea of the app at the maintenance level and he said if we could accommodate some of the Air Force-specific areas, he could see a bunch of the people he works with benefitting from it.
  • As far as auditing goes, it is one of the biggest issues he has encountered is avoidable errors in reporting maintenance. If we were able to comprehensively understand errors, he sees this as a huge supplement to some of the things he is working on. It also has many commercial applications such as the maintaining of the post office and warehouse items.
  • He thinks that the app would be great but unlikely for us to win the contract for it unless we essentially create the contract. So whenever we end up building it we need to find the acquisitions officer and help him draft the contract.

 

Michael Jelen

  • Works in consulting
  • Working to make Abu Dhabi a smart city, implement ultra-modern infrastructure
    • Less developed than NYc or HK so makes it easier
    • Adopt and implement new technologies
  • Recommends looking into RFID
    • QR codes are good and cheaper, but not as automated
    • Lots of sensors are cheap in making Abu Dhabi a smart city: is this trash can full or not?
    • Look into buying sensors and making your own system around it for inventory
  • Photo recognition packages?
    • Not sure if possible, but recommends looking into it; has gotten a lot cheaper
  • Blockchain
    • Lots of value add for logistics and supply chains
    • Lots of players inputting into one place, not all players need to see all the info

Kati Samerigo

  • GCSS is DOD-wide
    • ERP system (enterprise resource platform)
      • Based off of SAP
    • PeopleSoft (Army is looking towards)
    • Look up GCSS team on Google to get the GCSS/GArmy API’s
  • Workcodes
    • System is German, inflexible, need specific work codes for specific situations
      • G-ARMY had a dictionary that translated all these work codes
  • Army weapons checkout process
  • Parts and Maintenance
    • Property Book Officer (find USMC equivalent); keeps track of higher level inventory/logistics
      • 5988E Form, print it out every week and go to PMCS (preventative maintenance checks and services) and note any deficiencies on the form; when it got turned back into the motor
  • Help USMC talk to GCSS programming team
    • Lots of disconnect between users and programmers
    • Issues often aren’t resolved b/c of disconnect (i.e. cryptic workcodes)
  • Figure out more on how deadlining works; what are the critical equipment list?
    • Army O26 report, the critical equipment list
    • Delve deeper in MPR’s

Capt. Baker

  • Filled her in on projects status and made the decision to not go down Friday.
  • Has very little experience with these systems and the different areas of maintenance that we are hoping to address
  • Sees the benefit of being able to mobilize GCSS. Her main value proposition is the ability to do this remotely. She wants us to explore the idea of how applicable this could be to combat situations.
  • Auditing tool is interesting to her, but she hasn’t noticed as big a problem as we have been hearing. Although she admits she has never worked closely with MPRs so her view may be incomplete.
    • Side Note: We may need help getting her to be responsive. We had to work very hard to get this short time with her. We had a lot of contact with Capt. Bender before and they are in the same position so she should have time to talk with us.

Approval to Test POC, Thinking Ahead to Scooter

Key Insights and Decisions

Going into this week, we had two hypotheses we intended to examine:

       1. We can run a mechanical test of our product live on site to establish a Proof of Concept.

We received immediate approval from Brigadier General Stewart to come down and test with his support. We will be heading down next Wednesday or Friday in order to test our idea.

        2. There are roughly 90 dispatchers across the Marine Corps, these dispatchers spend about 6 hours per day update data across systems. Data that is used in their jobs can be exported and imported from GCSS, MOL, and TCPT.

 

A new estimate from Capt. Bender via General Stewart was approximately 150 dispatchers, increasing our total hours saved to roughly 600. We are maintaining our estimate of six hours per day after multiple confirming interviews. We did not receive a concrete response in regards to Excel capabilities, we will be validating this at Camp Lejeune next week.

        3. While this aspect of bridging TCPT with the other systems will be helpful, we can apply this to many more areas of the Marine Corps.

Through discussions with Christopher List, MSgt McLaughlin, and MSgt Lemus, we have narrowed our focus to two new areas for our next step. The first is an auditing tool for GCSS, that provides feedback on the information Corporals put into GCSS so there is less discrepancy between actual readiness and reported readiness. Another area that we examined was revisiting the Motor Pool floor and actually improving this area in a similar way to how we had originally imagined. Finally, Lt. Pavlo thought that on top of a synchronized TCPT, a field ready TCPT would allow for even more accurate assignment of equipment and personnel as well as give our solution in combat application. Run Rosters are another key takeaway from this week, and we will be exploring them further.

 

Next Week: We will continue pursuing each of our leads on continuing problems, but will also be heading down to Camp Lejeune to conduct a field test of our design.

Capt. Bender

  • Demoed our MVP (Microservice)
    • Thought the CG would be all in for it.
    • Not sure if we will be able to actually implement our solution immediately
    • Liked the idea of a POC via mechanical run through of our solution
  • BG Stewart wants us to “go faster”
    • Plan on going to Lejeune Wednesday the 20th or Friday the 22nd
    • Dry run on site with Dispatchers
  • New Problem sponsor is coming in next week, brief Thursday 15th
  • Wants us to look into areas for our scooter.
  • DRRS may be difficult to penetrate. Security Clearance issues, however using dummy data to bypass this may work.

Lt. Pavlo

  • “That would be the dream” if TCPT spoke to the other three systems
  • Two Dispatchers and a backup
    • One in TCPT and one in field
      • A mobile TCPT would be huge for the field for combat
  • Across MLG, 50 overseers. At least one Dispatcher per overseer
  • Because systems don’t talk, continuous recognition and validation
  • Mobile would be great. Because group may be training, their reflected readiness is likely too high
  • Dispatchers would be training. Currently, you have to task out a person to update this stuff.
  • Currently, if a company goes on a mission. CO briefs higher-ups. MOL gets updated but that’s it.

MSgt McLaughlin

  • Availability of equipment vs. Maintainence readiness
    • This difference leads to differences in readiness
  • TCPT
    • Validates different types of licenses throughout MLG
      • Units don’t update it, so he pulls it and has one Marine update it by going around to each shop and verify.
    • Units don’t have the capability to update TAD advanced licenses.
      • IPAC is supposed to update it
    • MCTIMS connecting to TCPT would be money
    • Assign everything, but hard to identify and forecast to make a run roster
      • Motor pool gets a mission to create run roster
        • You’re driving this vehicle at this time
      • Command sees each motor pools run roster and who is providing support
      • Export TCPT to Excel document that needs to be manually created, nice if the system could create its own roster
      • The current system is a bit finicky, Microsoft Access. Homemade sheet everywhere. Means allocation.
      • Additional work put in, some units hand punch, some use system
        • Less work
        • Consistency
  • TLCM
    • Real-time GCSS tracker

MSgt Lemus

  • The Maintenance Production Report (MPR) frequently contains items that clearly demonstrate information was not properly entered into GCSS.
  • The hypothesis is that these improper entries are having a meaningful impact on readiness reporting. i.e. The readiness number is overly optimistic or pessimistic.
  • A tool that looked at the MPR and applied business logic could identify/flag items that do not appear internally consistent.  This would have two benefits: 1) Serve as a training tool for the mechanics. 2) Increase data accuracy and consequently the accuracy of readiness assessments

GSgt List.

  • Some of the inconsistencies in the MPR are intentional.  E.g. If an operator’s seat on a HumVee needs to be replaced, it is automatically a deadlining issue according to the manual. However, no maintenance chief in the Corps is going to deadline a HumVee that warrants a replacement seat because the seat is ripped.
  • There are other analytical reports and tools available to help ID problems in the maintenance chain. This may lessen the value of a tool that analyzes the MPR.
  • Anything that simplifies data entry into GCSS especially for the mechanics has value. One possibility, when a mechanic picks up a part from the Parts section, a bar code scan of the part could auto-update GCSS that the mechanic is working on that part & vehicle “now”.
  • Would like us to visit him when we come down for our demo

Lt. Reaver

  • Supply Officer: does everything from property management to acquisitions to contracts to managing a unit-level budget
  • Suggest reaching out to G4 (logistics shop) to get an exact # of dispatchers
    • Not sure how many dispatchers there are in the MLG given the variability per unit
    • Pavlo might work in G4 if not, contact Mappin again
  • IT System Approval Timeline
    • Depends on CG’s prioritization of project
    • Lots of front-end paperwork and IT waivers
    • Likely 6mo-1yr, 3-6mo after all testing is completed

SSgt. Clemens

  • Verified information entered from GCSS into TCPT is vehicle availability; confirmed that this is a simple available/not available with an option for comments
  • Confirmed that Staff Sergeants have the capacity to upload documents into TCPT, download from MOL and GCSS
  • Excel documents that are entered into TCPT do not auto-populate the respective fields
    • Automating this would make his life easier in entering information and generating run rosters
  • Licensing information is entered manually. Said that the information in MCTMS is unhelpful and serves no purpose

Cpl. Torres

  • Verified that fields entered into TCPT from GCSS is vehicle availability. Mentioned ability to write comments on the exact status of the vehicle
  • Licensing information is manually entered after receiving a morning report of the status and availability of personnel
  • Confirmed that not everyone has the ability to export information from MOL since this was a capability he could not use
  • Automation in generating a run roster would be a huge help. This report is generated using information from TCPT and GCSS, so there is potential for automatic creation

Sgt Collins

  • Reiterated that information entered from GCSS into TCPT is vehicle availability
  • Estimated around 30 dispatchers, putting in 5-6 hours a day
  • Was not really how Excel works with TCPT
    • you can pull it up as an excel sheet and that’s how you update it (is this what they meant by TCPT generates excel?)
  • Weekly update personnel status for individual Marines in TCPT
  • No one can get excel data from MOL
  • Don’t add new recruits to MOL (they’ll have their own profile), instead manually input it line by line in TCPT
  • Get licensing and availability from individual Marines

Sgt Brown

  • Verified that field entered into TCPT from GCSS is vehicle availability. Mentioned ability to write comments on the exact status of the vehicle
  • TCPT
    • Has the right to generate Excel from, but doesn’t know if you can/how to upload Excel
    • 1-2 hours updating personnel status, 4-5 hours inputting vehicles
    • Inputs licensing gets it from the individuals themselves
  • MOL
    • Receives availability from MOL, leaves it at “available”
    • Can export data from MOL, but he doesn’t
  • GCSS
    • Can’t export data from GCSS, but the truck master can
    • Would like GCSS & TCPT to talk about truck availability
  • MCTMS/MOL
    • No one knows how to use MCTMS or MOL to update licensing
    • Doesn’t see the purpose in using MCTMS/MOL for licensing because he still needs to manually input into TCPT
  • Manually updates roster
  • Would like it if GCSS & MOL generated a run roster
    • Personnel, vehicle serial #, date, time

Capt. Baker

  • Our new problem sponsor
    • Not too familiar with systems we are working with
    • Has many connections to different people in the Marines
  • Pain Points
    • Doesn’t fully understand our problem yet, wants to work with us to figure it out
  • Wants us down 2/22 for the demo.

Progress on Initial Tool

Key Insights and Decisions

Going into this week, we had two hypotheses we intended to examine:

 

  1. The different systems used by the Marine Corps are currently able to communicate with one another

 

We examined this hypothesis by first looking into the features of the different systems (GCSS, MoL, TCPT) and found that they currently have both data import and export capability. However, we found no evidence of this being utilized. This capability to import/export data through Excel makes it easy to transfer information autonomously between systems.

We also heard from our interviewees that the lack of communication going on between systems was a major pain point. We concentrated on the Operations aspect of this, but there were numerous examples of areas in which systems that talked with one another would save hundreds of man-hours a day. Most notably in the Defense Readiness Reporting System (DRRS).

 

  1. That our current MVP would save time on behalf of the user, and create value for leadership as that would consequently save money

 

We examined this hypothesis by asking individuals about how they are currently using the aforementioned systems, how much time they spend doing so, and what their other responsibilities entail. We heard ranging responses regarding these inquiries, with all individuals indicating that they spend anywhere between 1-8 hours a day updating information throughout the systems (with TCPT proving to be particularly inefficient and time-consuming). Their responses also indicated they do not know what they would be doing with the time saved. After estimating the time spent by all Dispatchers combined at the Company level, roughly 6 hours a day. We extrapolated out to the rest of the Marines, estimating 180 man-hours* a day would be saved with an autonomous system for transferring information. On top of this, we discovered the Company Commanders spend approximately 5 hours a week verifying information in TCPT, adding another 30 man-hours** per day across the Marines.

 

Lt. Rodgers

  • IPAC is responsible for the majority of entry into MOL
  • Alpha Roster may have the data but MCTFS (Source data that populates a Marines record, where the data is being updated) also does and could be better
  • Adjunctin chases around paperwork of errors regarding bad information
  • Systems not speaking to each other is a big problem –
    • MRS -> MCTFS
      • Erroneous data
      • Communication breakdown
    • Says probably 8 or 9 other areas this could help
    • DRRS Not automated… sucks to actually update
  • CLB 8
  • Training is a big issue

 

Lt. Ayala

  • 3270
    • Used for getting personal info if someone needs help
    • Pinnacle of Data, baseline data for all marines. IPAC deals with pay, new joins or leaves
    • ODSE is in MOL. What platoon, first last middle, rank, date of rank, primary MOS, gender, Marine Core Code that defines where you are, RUC is used for other stuff also where they are
    • Issues with personnel
    • 17 or 18-year-olds don’t know where to go. So they go to IPAC, but not all of them do.
    • IPAC not we’ll train
    • 3270, Barney style lol, would be nice if it was easier.
  • MOL
    • Leave – 75 or so… backlog of info
    • Alpha report
    • Limited duty
    • Full duty
    • On leave
    • Temp add duty
  • Morning report
    • Works fine
  • New system?
    • Barney style, auto-populating
  • Talk to Alpha Report

 

Sgt Dunn

  • Maintenance Management Report
    • Tells you at each level everything about all equipment
  • Can submit a report every time data is updated
  • Maintenance Production Report
    • Less information can be exported to the spreadsheet
      • Service request #
      • Priority
      • Serial Number
      • Resource Group
        • Ruc and maintenance

Sgt Brown

  • Functions as Chief Dispatcher.
  • Spends about 8 hours a week updating TCPT with info from the GCSS maintenance report.
    • To update TCPT, he is looking at the S/N, Vehicle Type, and Availability.
    • It would likely be adequate if the GCSS update to TCPT occurred hourly.  Ideally, a change in one would automatically update the other.
  • He is not sure how he would use that time if the GCSS updates were automated.
  • Currently, when a mission comes in, he prints the TMR (Transportation Mission Request) and walks it upstairs where the platoon sergeants are located and ask them who has the vehicles and staff to cover the mission. If equipment and personnel availability in TCPT were current, he would not need that conversation.  He would be able to determine how to staff the mission and then just notify the platoon sergeant.
  • He does not update TCPT with personnel availability.  The relies on the platoon sergeants for personnel availability.
  • MOL does not hold licensing information.  Licensing information is maintained in TCPT.
    • Once a quarter, he has the members of the platoon come to him and tell him which licenses they hold.  He updates TCPT on the spot. Usually takes about half a day to complete this task.

 

MSgt Mendoza

  • TCPT-GCSS-MOL
    • His company has two dispatchers who spend 6 hours combined monitoring TCPT for Requests. These dispatchers spend roughly half of this time simply watching GCSS for changes to equipment status, and with an automated system he estimates it would save 3 hours a day for his company simply on the GCSS side.
    • On the MOL side, they do not even update the information in TCPT anymore because it takes so much time. And while it doesn’t take too much effort (30 minutes) to read off the MOL report and analyze who is available, the trouble lies with the effort behind actually getting the request. The people who are using the reports to find available soldiers (Cpl, LCpl, Sgt) don’t have the proper rights to view the MOL reports for the company, so they have to wait for the right people (MSgt, GySgt, MGySgt) to be available to get the report. But with TCPT, they can view any of the data in TCPT and this removes that step.
    • Paraphrasing what he told us: “While it may be useful to combine these systems to save the dispatchers time, the real benefits of merging the systems would come in the form of predicting future capabilities based on all these different things. We would probably see a lot more benefits after linking the systems”

 

Dale Swink

  • Serves as Director of II MEF Movement Control Center – his group of 23-26 people is responsible for all inland transport for II MEF in N. America.  They coordinate both commercial and military transportation.
    • Freight haulers
    • Buses
    • Port Handling services
    • Rail Handling services
  • TCPT is not going away!  This is a rumor they have been trying to quash for a long time.
  • TCPT does have the capability to import data on vehicles, personnel, and licenses via pre-defined templates.  (He provided examples of the shell template files.)

 

John Myrka

  • GCSS trainer and guru
  • GCSS has the ability to output reports in spreadsheet format.
  • He believes MOL has the same.
  • His former employer prototyped a cloud-based system that unified the communication between maintenance and mission resourcing.  The marines shutdown that project.

 

Sgt Collins

  • Dispatcher works with TCPT.
  • He spends 4-5 hours per week updating TCPT with the information from GCSS.
    • He has the maintenance team run the maintenance report a couple times a week.  He then goes line by line and updates TCPT.
    • Specifically, he is updating each truck by S/N for:
      • Date available (when will it be available for service)
      • Status (Available, Op Degraded, Deadlined)
  • When he was based in Quantico, they updated TCPT with GCSS info in the same way.

 

Chet Boyd

  • Uses two new systems Sharepoint and Range Control; both of which do not require information from other systems so automation may not be able to help
  • Problems with a distribution email list
    • People who leave the base, get deployed, don’t want to receive these emails
    • Populating email list with information from MOL could help alleviate this
  • Believes that MOL can export CSV files but was unsure of this

 

Ginny Badanes

  • Course advisor works at Microsoft on a team dealing with government
  • Discussed security regulations regarding our team’s solution (suggested we implement user anonymity in order to surpass security restraints)
  • Mentioned that a dashboard would be a useful product because it would allow higher-ups a more holistic view of operational readiness in a palatable fashion
    • Could connect to team members at Power BI to help with building data visualization

 

Lt. Mappin

  • Finance officer for 2nd MLG
  • Serves as a funding disbursement point at the Group level; involved with “big” picture things
    • Contact later for larger scale questions
  • Had little idea as to the total cost of dispatchers
    • Got contact info for a Logistics and a Supply (purchasing, procurement) officer
    • Logistics should have a clearer idea of dispatcher costs at a more micro level

 

*There are 10 Companies in each MLG that use this system of readiness reporting.  There are three MLGs in the Marines, leading us to 6 * 10 * 3 = 180 man-hours a day for Dispatchers.

**By the same argument, Company Commanders spend 1 * 10 * 3 = 30 man-hours a day Marine Wide. Leading to an estimated 210 man-hours.

Narrowing Focus

Key Insights & Decisions

 

Over the course of the first three weeks, we have documented a host of different issues experienced by personnel in a variety of functional areas. We have also identified a handful of frequently repeating themes as we delved into each.

 

  • Many functions have only a bare minimum of standard procedures or methodologies.  This can have advantages. It certainly has drawbacks. We have encountered multiple instances of reported “issues” where the desired feature/fix already exists.  The person reporting the issue was simply unaware of the feature. Lack of training on the tools, knowledge of best practices, and standardization across units is commonplace.
  • Functional activities – dispatching a truck, ordering a part, compiling readiness, etc. – frequently involve multiple different applications.  In almost every case, the applications do not communicate with one another. An initial lack of out-of-the-box interaction is somewhat understandable given these systems are frequently from different vendors. However, these gaps have existed for years, a state that would not be tolerated in private industry.  The fact that it is tolerated in the military branches – we have seen this in other branches as well – is likely symptomatic of our next item.
  • There are no socialized metrics quantifying the cost of most of the reported issues in terms of time lost, opportunities missed, readiness impact, or basic dollars and cents.
  • Many fundamental issues have a reported fix in the works.  However, this is strictly in the form of rumor. While we have heard of numerous issues with solutions “coming”, no one has yet to pull out a document or presentation outlining the solution and implementation plan for any of them. That is not to say the word on the street is incorrect.  Simply, that it is unverified.

 

In response, we decided to make one narrow issue – lack of communication between TCPT and other systems for key personnel and equipment information – into a case study.  We will quantify the impact, define the solution, determine the timeline for any change already in the works, and assess resultant outcome. Our intention is to not only affect a specific change but also prove a framework for taking a second look at issues that most personnel have simply come to accept as the natural order of the universe.

 

Beneficiaries Interviews —

Stephan Heal:

  • TFSMS – Maintenance system, readiness reporting
  • GCSS has the capability to report readiness in detail
  • TCPT capability is in GCSS
  • AnglicoTech teaches Marines how to properly use GCSS
  • Now the company who does Marine logistics is on board with GCSS
  • Responded well to Front End readiness system
  • Member of the FAS Team (Functional Area Sustainment)
    • The FAS Team is actually outside contractor AnglicoTech.com
    • The FAS Team for Maintenance & Logistics does teach best practices.  However, that does not translate to standardization across shops.

 

Adam Beauregard

  • Former Naval Aviator
  • Now at National Defense University
  • Navy is driven by deployment schedule
    • Deploy:  6-9 mos
    • Ready Alert Stage: 3-6 mos
    • Lower readiness: 6 mos
    • Build-up: 12-18 most
    • Repeat Cycle
  • Sierra Hotel Aviation Readiness Program – software used to upfront flight scheduling and track training events toward readiness
    • Each hour of flight time is applied to a specific training objective required for readiness.
    • When it comes to planning the daily flight schedule, the system does recommend training activities, however, there is no real intelligence to it.  E.g. It might suggest a submarine tracking exercise but is not checking that there is a training area actually available to support that activity.
  • Available aircraft and status tracked via whiteboard (exactly like Marine Motor T units are using whiteboards to track trucks)
  • Adam provided a fantastic paper on Managing Military Readiness.

 

SSgt Brandon Moreland

  • Currently Motor Maintenance Chief of a platoon
  • Direct reports:  QC Chief, Shop Chief, Parts, Tool Room
  • Shop Chief’s mission is to validate equipment is repaired in a timely manner while the QC Chief validates they are repaired correctly.
  • The big pain point for his role is lack of people who know how to use GCSS to assess readiness.  Consequently, he has to go to 2-3 meetings per week to convey readiness information that is available in GCSS.
  • GCSS does not talk to TCPT which means dispatchers are having to hand jam maintenance/truck status from GCSS into TCPT just like they have to hand jam personnel status from MOL to TCPT.  (Need to get this corroborated by dispatch staff.)
  • In his opinion, GCSS does everything they need to get to the point where the technician can have a Toughbook at their station next to a vehicle, order parts like Amazon, enter status updates, etc.  With regard to Motor Maintenance Operations, the gap is that they do not have adequate wireless coverage and Toughbooks w/ wireless capability. Once those are implemented, the necessary training classes are available that lack of GCSS knowledge will not be a hindrance to a fully electronic workflow.  

General Martin Dempsey

  • Need to narrow our report
  • Find an area of readiness that isn’t being analyzed yet.
  • Equipment and Personnel readiness are heavily examined

Sgt Christopher List

  • QR Codes
    • Every piece of equipment has we code embedded with a bunch of info
    • There are two main inventories CLM (Major Machinery) and TS3 (smaller components associated with major machinery). Both happen every quarter, every RO change, every Battalion command change, other random times.
    • It is currently done on paper, serial number and TAM written down for everything. Kept in books
    • He is working on making it upload to a spreadsheet via QR scanner
  • TCPT
    • People spend “a lot” of time updating information manually
    • Confirmed ideas regarding how the systems are connected (MCTMS has certifications needed in TCPT, MOL has personal info needed in both TCPT and MCTMS, GCSS deadline info needed in TCPT)
    • Spend 15-20 minutes per new member of the motor pool. Current status not usually updated in TCPT leads to issue with miss assignments.
    • Some motor pools only have 15 guys so it’s not a big deal but some have a lot more
    • The combined effort for updating all these things is time-consuming
  • TCLM
    • Readiness dashboard for drilling into equipment could be useful for a foundation for the next project
    • Input from DRRS
    • No personal info
  • Future Readiness
    • Thought idea of “recipe” app would be great


Capt. Connor Bender

  • Verification of List’s count on TCPT
  • Having accurate information regarding information on personnel would be valuable in terms
  • Structure
    • Truck Master (MSgt) – Care of vehicles
    • Ops Cheif (MSgt) – Oversee all operational requirements for the company, supervises the Truck Master, OVE and QC.
    • QC (SSgt) – Determines what is and isn’t road worthy
    • Platoon Commander (2nd Lt, Lt) – Answer to exec officer. Oversee troops. Work with Ops Chief and Truck Master. Communicating with Company Commander.
    • Dispatch (Sgt) – Report to Truck Master and Ops Chief.
    • Platoon Sergeant (MGySgt) – Commanding Marines. Inward Facing
  • TCPT –
    • Dispatch doesn’t assign people.
    • Dispatch says run needs to go out. Goes to MSgt and Exec to figure out how to make it happens
  • Cost Analysis
    • Will set us up with Finance Chief
  • TCPT sending report based on current info to Platoon Commanders
  • Master Log, hand jam everything down, type everything in

 

Sgt Cody

  • In QC role on the maintenance side
  • The issue involving an inaccurate transfer of information from maintenance to GCSS
  • Paper gets smudged, parts order in wrong quantities or variety, hand jamming issues
  • Would love a way to be able to order from GCSS on the spot

SSgt Amirado

  • QC on the operations side
  • Pain Points
    • Not using all possible opportunities for training exercises
    • TCPT not being updated properly/in time
  • Determines whether trucks are roadworthy or not.
    • Information from GCSS may not be in TCPT so when he’s looking at trucks that are fine in TCPT but are deadlined in GCSS

Week 3 – Site Visit Leads to Pivot

Beneficiaries Interviews —

GySgt Borbor:

  • Training personnel goes onto MCTIMs to find out who is delinquent on their personal training.
  • Readiness is the Commander’s responsibility but delegated to him
  • Battalion Command asks Company command why Marines aren’t ready, Company command asks Platoon command, Platoon Command asks him.
  • The main problem is not giving Marines enough time to train, procrastination
  • Checks through the list of delinquent Marines for exemptions
  • Pains –
    • A glitch in the system allows Marines who should pass, not pass

 

CWO2 Ploughoff:

  • DRRS – Defense Readiness Reporting Systems
    • Mandated by Congress
    • Goes to Secretary of Defense
    • When you hit submit, it goes directly to the SecDef. This circumvents higher ranks to avoid tampering.
  • DRRS is frequently used by people to forecast readiness when it actual purpose is to portray past readiness level.
  • RG4 – These are the people who handle equipment reporting. (CWO2 Ploughoff – will send Conor a specific contact.)
  • How he compiles DRRS for the MLG
    • He gets a briefing from PPT decks compiled by the subgroups
    • He then briefs the General
    • He uses the PPT he receives to complete the DRRS that he submits.
  • DRRS is not his main job
    • He has to do this on a monthly basis
    • Currently spends one week/mo. on DRRS
    • It took longer when he first started b/c he did not have a sense of the historical readiness state.  Now it only takes a week to understand what has moved over the past month.
    • Typically a person doing DRRS for a given entity is in the position for about a year.

 

Sgt Brett:

  • Showed us the GCSS order form and report
  • Some of the current orders for the motor pool he showed us were over 400 days old when after 100 they are supposed to be scrapped.
  • They found a report that had 5 things listed, but the only maintenance report on the request said nothing was wrong.
  • Manually reads each line of the report into an excel doc to be read by maintainers in determining applying maintenance.

 

Sgt Steven:

  • Showed us MCTIMs, MOL, Marine Net
  • MOL contains all the information about a Marine, including if they are on leave and why
  • MCTIMs takes that information to the level just below the person using it, and compiles all the Marine information, with no differentiation in position.

 

Capt Bender:

  • Presented us with the idea of readiness not taking data from the correct spots
  • In MCTIMs there are a variety of things he needs to check, but for readiness, there is a simple checklist of if they have completed a given exercise in a certain amount of time
  • Didn’t even know that TCPT would be helpful, showed a bit of the disconnect with our problem.
  • Working on a project to track gas usage, could potentially track the production of the maintenance requests for us and examine it for problems.

 

MSgt Lemus:

  • Marine’s who are “available” may not actually be available, they may be office jobs, etc.
  • Some of the reported maintenance requests are marked incorrectly (03, Short Staff)
  • Wants us to look into the idea that some of the readiness reporting could be automated

SSgt Gaugh:

  • Head of a motor pool platoon
  • Reports to the Motor Head with readiness report
  • Doesn’t use GCSS or MCTIMS, decides readiness based on an old system

 

Cpl Koss:

  • Handles the Onboard Vehicle Equipment
  • Uses GCSS to input information about current states of motor pool equipment.
  • Has to manually read information from one area of GCSS to a motor pool spreadsheet

 

Sgt Blomhoff:

  • Quality Control Clerk
  • Determines the status of trucks with an excel report
  • Reads off GCSS reports to determine the status of trucks,

 

GySgt Miller:

  • GCSS Clerk at 2nd Maintenance Batallion
  • GCSS is already usable on the maintenance floor, just doesn’t have the capacity to do so with current equipment (WIFI and Computers)
  • Anyone can input into GCSS, but it takes a bit of practice. So a mobile solution would be usable by anyone assuming they did quick training.

 

Sgt Thomas:

  • TCPT report manager
  • Manually inputs data from MOL to TCPT
  • TCPT is used as a tool that takes in requests for transfer of personnel and equipment between battalions

 

SSgt Moreland:

  • Works with SSgt Macekjo in the Motor Pool
  • Realizes issues with GCSS and new employees, but for the most part, sees the GCSS issues going away as it becomes more integrated
  • Would like the ability to order parts at the truck side. Knows this is possible, just not enough resources.
  • Recognizes the disconnect between operations and maintenance (i.e. GCSS vs. TCPT) not sure, but believes there could be a significant benefit to a connected system.

 

Key Insights —

  • Our previous MVP was tested against multiple potential beneficiaries, all with the same outcomes.
    • They would love the ability to order parts on the spot, not have to write up what they need, hand off the paper and then plug it into GCSS
    • HOWEVER. GCSS Marine Corps already is capable of this on the Marine’s Toughbooks, they just don’t have the number of computers or WIFI capabilities yet. All of this is on the way, meaning any improvements we make will either be replaced or compete with an existing system, not adding any significant value.

 

  • They have five different systems that we know of for keeping track of some form of readiness. These systems are all stand alone, which is fine from a data perspective but means they are just using these systems for bookkeeping and nothing more.

 

  • Readiness is currently reported at the platoon level and this number that they come up with, independently, is passed up to the company level and compiled by another SSgt and then passed up to the MLG level and compiled by a staff NCO. But that number that comes up from the platoon is one: super subjective and nonuniform, 80% readiness in one platoon may not be the same as 80% in another. And two: is very difficult for the CG or anyone else to look further into because they have to go into the platoon level and look through a spreadsheet that keeps this information.

 

  • That spreadsheet is really two spreadsheets, one called an alpha report, it is made from an SSgt going into MCTIMS and figuring out what people in his platoon are available and how much training they’ve received. He also generates a GCSS report which says what vehicles are down and makes edits to the existing spreadsheet contains all the existing equipment and marks stuff down that is out of commission.

 

  • All this readiness data that need to compile these numbers and that the CG wants are available via various systems, (equipment-GCSS, personnel – MCTIMS, availability-TCPT) but computers can do a lot more than just bookkeeping. This data is all out there, being read manually into spreadsheets, sporadically compiled, and then put back into a computer for presentation. We just need to be able to automate one little aspect of the readiness reporting first, then another and eventually all of it.

Key Decisions —

  • We are considering a pivot as our Value Proposition failed and we have more potential to be extremely helpful to the Marines in both saving the time of manually inputting millions of rows on excel sheets a year, as well as the ability to accurately and uniformly report readiness and capabilities.
  • We will need to dive deeper into this issue by talking to some of the platoon leaders who are responsible for reporting their readiness to determine how they currently formulate these numbers.
  • We will need to speak to some of the TCPT clerks as well as the GCSS clerks to understand how we can make them talk to each other.
  • We will need to speak to as many different IT professionals to determine our initial limits on what data they will give us access to.
  • The idea is to automate this at the platoon level, and if successful as well as helpful, begin to automate many of them and eventually all.