New SQTR / SET Module

[Eclipse]

Prior to the implementation of Phase II, there were conversations in my group claiming that paper STQRs were going away. I guess the only benefit of the new system then is to ensure the CAP IDs used are in fact from authorized evaluators, instead of having to rely on a personnel authorization letter.

We've had those too - people seem to confuse "paperless" with "documentless".  CAP is moving towards the former, but will never be past the latter (at least not in the near-term).

The new systems raises a different issue which is more attention required by the SETs themselves in tracking what they have done.  If you are randomly signing off
1 or 2 people a year . you'll probably remember them, but if you're an active SET, you may be working with dozens a year across hundreds of tasks.

Time to fire up a GDoc and keep a log.  The hardcopy SQTR will also serve as a backup "reminder" for SETs that forget they met a member.

Heck, the simple ability to verify a given member is actually an SET and is current in a specialty (via 101 card) is huge.  I can't tell you how many times
we've had CC's or "back in the day-ers" who though they could evaluate things based on "I used to" or their business care.  Nothing worse then telling
a member they wasted their time because their SET hasn't been current for a decade, or never was.

We've been advising our members to request to see the 101 >before< staring the evaluation, and not to bother if the member cannot verify their status immediately.
That and to get their things entered ASAP - it's not unheard of for a member to leave CAP after being quite active.   If you sit on entering information, the system
is going to disallow entry for anyone who "ain't no 'mo".

[EMT-83]

Prior to the new SQTR and Skills Evaluations module, it was a requirement in Florida Wing to scan an initialed/signed paper SQTR and upload it into eServices Ops Quals. Does anyone know if that's still a requirement?

That's not just Florida, that's 60-3, and nothing's changed in that regard.

I don't see anything in 60-3 to support this.

[Eclipse]

CAPR 60-3, Dec 2012:

Page 7
(f) It is not necessary to maintain paper or electronic Specialty Qualification
Training Records (SQTR) once qualifications are approved in Ops Quals on-line. Members are
encouraged to still maintain complete records of SQTRs and external training as many task
requirements and courses overlap specialties and without proper documentation the member may
need to re-demonstrate tasks when working towards other qualifications.

i.e Until they are approved, they are required to be maintained online.  No ESO worth his business card (regardless of level) is going to approve qualifications
with supporting documentation.

Units. Each unit must:
(1) Ensure individuals satisfy all applicable requirements before approving a
member's SQTR, and maintain all documentation required for issuance either on paper or
electronically. Documentation should be kept in a CAPF 114, if not stored electronically.

I suppose if a unit wanted to create a separate electronic storage area for things locally,
they could, but why they would want to when putting them in OPS Quals fills the need
and negates the requirement to have individual 114's is beyond me.  Likewise the 114, per se,
isn't required, but the unit is required to have them stored somehow coherently.

[EMT-83]

I'll agree that scanning and uploading the SQTR is one acceptable method of compliance. I do not see where it's required.

[Eclipse]

What other option is there?

[Storm Chaser]

What other option is there?

One could interpret it to mean the electronic SQTR in Ops Qual.

[Eclipse]

What other option is there?

One could interpret it to mean the electronic SQTR in Ops Qual.

How?  Up until the most recent upgrade, there was zero validation whatsoever - members simply entered
any valid number.  That's not substantiation of anything.

[Storm Chaser]

What other option is there?

One could interpret it to mean the electronic SQTR in Ops Qual.

How?  Up until the most recent upgrade, there was zero validation whatsoever - members simply entered
any valid number.  That's not substantiation of anything.

Agree; and that's why we have been using the signed paper/scanned SQTRs. Now that we have an electronic way of validation, one could interpret this new system as compliant with the requirement in CAPR 60-3.

[Eclipse]

Agree; and that's why we have been using the signed paper/scanned SQTRs. Now that we have an electronic way of validation, one could interpret this new system as compliant with the requirement in CAPR 60-3.

Once it's fully working, I would agree - or certainly that's the direction this upgrade intended.

A good SET should be doing these sign-offs in real-time directly on an tablet or PC, or close to it.  Some better task entry screens, or
mobile apps would be a boon to that effort.

[Storm Chaser]

Agree; and that's why we have been using the signed paper/scanned SQTRs. Now that we have an electronic way of validation, one could interpret this new system as compliant with the requirement in CAPR 60-3.

Once it's fully working, I would agree - or certainly that's the direction this upgrade intended.

A good SET should be doing these sign-offs in real-time directly on an tablet or PC, or close to it.  Some better task entry screens, or
mobile apps would be a boon to that effort.

That's how certain schools such as Alabama Wing Emergency Services School (WESS) record tasks completed. WESS does not normally provide signed SQTRs, which in the past has created some headaches in FLWG since they do require it. We have since worked out some of these issues.

I wish it was economically feasible to have tablets or PDAs to log these tasks in real-time. With many members currently owning tablets and smart phones, perhaps NHQ could develop a mobile app to meet this need.

[JeffDG]

I wish it was economically feasible to have tablets or PDAs to log these tasks in real-time. With many members currently owning tablets and smart phones, perhaps NHQ could develop a mobile app to meet this need.

NHQ doesn't need to develop anything.  They just need to get out of the way of members who would develop these things entirely on their own to make their jobs easier.

Remember back last summer when NHQ said they had a "high priority project" to provide a temporary interface from IMU into WMIRS until they could develop their own IMS?  The claim was that it would be done in September...well, still nothing.

The issue is, NHQ is not interested in any ideas they didn't come up with themselves.  So, you'll see mobile apps after all their current pet projects are done, and people forget that someone outside of NHQ might have suggested it.

EDIT:  Here's the announcement of the high-priority project:  https://www.capnhq.gov/news/Documents/IMU_Interface_Update.pdf

The NHQ IT team is working on the new WMIRS/IMU interface as a high priority project. With National Board rapidly approaching, this interface may not be completed until sometime in September. We recognize this imposes some disruption to operations, and ask for your understanding that security concerns needed to be addressed. The interface will allow data transfer within the rules and security requirements necessary to assure system integrity.

[Storm Chaser]

I wish it was economically feasible to have tablets or PDAs to log these tasks in real-time. With many members currently owning tablets and smart phones, perhaps NHQ could develop a mobile app to meet this need.

NHQ doesn't need to develop anything.  They just need to get out of the way of members who would develop these things entirely on their own to make their jobs easier.

I don't disagree with the latter part of this statement. But there's something to be said about having a standardized system. Not every unit have the resources to come up with their own effective solutions.

[JeffDG]

I wish it was economically feasible to have tablets or PDAs to log these tasks in real-time. With many members currently owning tablets and smart phones, perhaps NHQ could develop a mobile app to meet this need.

NHQ doesn't need to develop anything.  They just need to get out of the way of members who would develop these things entirely on their own to make their jobs easier.

I don't disagree with the latter part of this statement. But there's something to be said about having a standardized system. Not every unit have the resources to come up with their own effective solutions.

Not saying they need to.  The point of an API into the national system is that interoperability would be automatic, as the end result would be standardized in OpsQuals for instance.  You're just building a tailor-made user interface to make the data entry easier.

If NHQ would simply publish an API for secure access, then members would rapidly fill the void.  I would bet there would be multiple apps for doing SQTR entry and signoff within one week...then the good ones will spread like wildfire, the crappy ones (the type I would develop for instance) would wither and die.

Members could easily collaborate on projects with tools like Sourceforge or Google Code for more extensive projects (like IMS).  There are lots of members out there who have extensive experience not only developing applications, but others with extensive experience with managing development projects across the globe.

The issue right now is:  If something is built, NHQ will do everything they can to block its access.  That means that you will spend more time and effort getting around the roadblocks than you will actually building functionality. 

If you build an API, the developers will come.

[Storm Chaser]

^ I like the idea of an API, but CAP shouldn't depend on units doing their own thing. Not every unit is going to have software developers available to build those apps.

[JeffDG]

^ I like the idea of an API, but CAP shouldn't depend on units doing their own thing. Not every unit is going to have software developers available to build those apps.

I'm not saying that units should do it.  If you built such an app, for what earthly reason would you make it so specialized that only your unit could make use of it.

Open the API and let members build them and share them organization wide.  We could get it done, and NHQ could stop [censored]ing that they don't have the resources to do it.

[Tim Medeiros]

I wish it was economically feasible to have tablets or PDAs to log these tasks in real-time. With many members currently owning tablets and smart phones, perhaps NHQ could develop a mobile app to meet this need.

NHQ doesn't need to develop anything.  They just need to get out of the way of members who would develop these things entirely on their own to make their jobs easier.

Remember back last summer when NHQ said they had a "high priority project" to provide a temporary interface from IMU into WMIRS until they could develop their own IMS?  The claim was that it would be done in September...well, still nothing.

The issue is, NHQ is not interested in any ideas they didn't come up with themselves.  So, you'll see mobile apps after all their current pet projects are done, and people forget that someone outside of NHQ might have suggested it.

EDIT:  Here's the announcement of the high-priority project:  https://www.capnhq.gov/news/Documents/IMU_Interface_Update.pdf

The NHQ IT team is working on the new WMIRS/IMU interface as a high priority project. With National Board rapidly approaching, this interface may not be completed until sometime in September. We recognize this imposes some disruption to operations, and ask for your understanding that security concerns needed to be addressed. The interface will allow data transfer within the rules and security requirements necessary to assure system integrity.

ENTIRELY NOT TRUE (in regards to the bolded comment).  I will say this here and now, the DDR reporting restricted application was developed initially by me as a college project, I sent it to them, they tweaked it to work with their systems and improved the interface and published it.  The main hurdle in all of that was that IT was NOT given the ability to set the priority on their projects.  That matter is still a fact actually, factor that in with the fact that they also support the corporate systems, and are only a 4 man shop (in regards to devs), that's 4 people supporting an organization of approximately 61,000 individuals (not to mention outside customers such as 1AF/Office of SAF/etc) with projects ranging from simple personnel tracking (seeing if they are current) to point of sale interfaces to systems like WMIRS and software that Corp employees utilize.  I should also note, the IT shop was recently hit with a downsize, so things are also going to take even longer than before.

With that said, I can honestly understand why they would shy away from allowing any joe schmoe access to the systems interface.  With everything done in house at NHQ they can ensure that the various applications and such would actually get supported and are up to their standard of quality and meet various requirements, there is NO guarantee in that regard when it comes to member created and controlled software.

This is not to say that I don't agree with allowing us "member devs" help them out a bit and lighten their workload, I'm saying that I understand their apprehension.

[Storm Chaser]

^ I like the idea of an API, but CAP shouldn't depend on units doing their own thing. Not every unit is going to have software developers available to build those apps.

I'm not saying that units should do it.  If you built such an app, for what earthly reason would you make it so specialized that only your unit could make use of it.

Open the API and let members build them and share them organization wide.  We could get it done, and NHQ could stop [censored]ing that they don't have the resources to do it.

Or better yet, why not have a group of software developers volunteer their time to NHQ and, through collaboration and coordination with the appropriate national IT and Ops staff, develop a national system with mobile apps for all to use.

If everyone is allowed to develop their own solution and share it, who's going to be responsible for maintenance? Who's going to be readily available to fix bugs or to add new features? What about training? Unit A uses App X, but Unit B uses Y. Now they have to work together for a particular incident or exercise, but their systems are different; maybe even incompatible.

The bottom line is that while there could be benefit to having an open API for talented developers to use, a unified, standardized system, with scalability and expandability baked into it, would be a better solution for all. This system needs to be maintainable and it must have resources available to do so.

[Eclipse]

The last thing we need is more homegrown crap, API or otherwise, because that just leads to inevitable arguments about "who's system is the 'standard' ", etc.

With that said, what NHQ does need to do is get more proactive about bringing in volunteer IT pros to their projects and support teams.

There are entire Operating Systems maintained on a purely volunteer / free basis, we should be able to get a few relatively "simple" (in the grande scheme) systems implemented
in the same way. 

There's far too much "not invented here" syndrome in these areas.

[arajca]

National IT has a long list of projects that, IMHO, teams of committed volunteers could knock out, if asked and given the access.

To minimize disruptions to active systems, set up a development server that is identical to the live system, but has very limited access to the development teams only. Set designated beta test periods so that all development will stop for a one week period while selected users test the system and report back. With in a year or two, the backlog could be completed, or at least significantly reduced.

[JeffDG]

The last thing we need is more homegrown crap, API or otherwise, because that just leads to inevitable arguments about "who's system is the 'standard' ", etc.

With that said, what NHQ does need to do is get more proactive about bringing in volunteer IT pros to their projects and support teams.

There are entire Operating Systems maintained on a purely volunteer / free basis, we should be able to get a few relatively "simple" (in the grande scheme) systems implemented
in the same way. 

There's far too much "not invented here" syndrome in these areas.

Why must everything be standardized?  Seriously, excessive standardization most often leads to mediocrity.  Building a one-size-fits-all system leads to a boatload of compromises and leads to a behemoth of a tool.

IMU is a prime example.  It's incredibly powerful, but because of that, it has a lot of checks and complexity that you now have to adapt work processes to in order to make it work, making it a bit of a drain on the small mission.  With an open and secure interface, people could build their tools to their scale and their missions.  All NHQ should care about is that they get their data in the format they require, and that's the entire purpose of the API.