I have been advocating for online submission for years, but starting with the other end of the submission.
I had envisioned the first step being the Certifier completing an online cert form, then pushing the "Submit" button. That would trigger an email to both the Vice-chair, and the Registrar. This way, if the VC was out of town, the Registrar would be able to review in a timely manner. The VC would click "Reviewed" when they were done, which would trigger an email to the Registrar, informing of the new cert ready for upload.
When the cert had been reviewed by the VC and accepted by the Registrar, the Registrar would click "Accepted", which would upload the cert, and update the online database. This final step is a vast difference than what happens now, and would require a revamp of the USATF database and map system. That is the big hurdle right now.
However, it recently dawned on me that one of the benefits of using the Excel workbook as a Certifier is the ability to store and quickly re-use measurer info and also race contact info. Doing this online would necessitate the USATF db capturing all measurer and race contact info for the entire country. Yes, the db can handle it, but one of the benefits of storing that info is so we don't have permutations of the measurer name, such as Ken/Kenny/Kenneth or Bob/Rob/Robert. For measurers, this is a great tool. For all of the nationwide race contacts, though, it becomes cumbersome sorting through all the "Jeff"s, for instance, to find the correct person from the list. Now, it would likely take less of the Certifier's time to type the race contact's info into the form, than to pick from a huge list. As a certifier, this just made automation more time-consuming than using my own Excel form with just my own state's list of race contacts.
Further, the current system sends certs from the Certifier to the VC via email, or snail mail. Some certifiers still aren't digital, although those are fewer each year. We will have all certs submitted to the Certifier via email, soon. The new system will have to incorporate a "Reject" feature, so that the VC or Registrar can reject a submission online, which would notify the Certifier of the rejection. The Certifier would then fix the problem and re-enter all cert info to resubmit, which may (depending on design) issue a new certificate number. Would the old number get re-used? If not, there would be a gap in the sequence, which is not acceptable. In the interest of submitting certs to the Registrar in sequence, this reject process would likely create a gap in submissions, even if the old number was still used.
My point of all of this is, over the past few years as I have been working through this, from identifying the scope of the project, through pseudo-coding, I have found one recurring hurdle. When identifying how an entry into a field will be handled, it comes down to "it depends". We have too many circumstances where an answer is not cut-and-dried, and may take some additional communication between parties, to come to an acceptable resolution. If the VC initially rejects a cert, clicks "Reject", then the certifier explains why that was entered, the cert number will have been rejected. With everything automated, that is not acceptable.
So, I have decided that our process is so unique, and while most submissions follow a defined process, not all courses/certs fit neatly into an automated process. If we are going to automate, we don't want to have back-doors built in so the Registrar can override some aspect. That is then putting burden back on the Registrar, defeating the purpose of automation.
I am not going to pursue automation until we have a large consensus that we are ready to automate. I am willing to listen to suggestions, but I will be on the side of shooting down all ideas, in the name of being sure that when we are ready to begin, we have covered all of the potential hurdles. Once we have overcome all hurdles, we can then begin designing a system, starting at the "submission to Registrar" stage of the process.
