[Pansophy] AUPPS-FAB-HHOM-ASSY R2 for review

Thu Feb 2 12:28:12 EST 2023

Hi Valerie,

That sounds good. Some small changes to the word file in Step 10 (they are highlighted).

Thank you for the help with this

Naeem
________________________________
From: Valerie Bookwalter <bookwalt at jlab.org>
Sent: Thursday, February 2, 2023 12:17 PM
To: Naeem Huque <huque at jlab.org>
Cc: pansophy <pansophy at jlab.org>; Tony Reilly <areilly at jlab.org>; Ed Daly <edaly at jlab.org>
Subject: RE: AUPPS-FAB-HHOM-ASSY R2 for review

Naeem,

We have a process in place for “record” corrections as worked out with Jacob for ISO. We will use this method to update your current “records” from R1 to R2 when the new traveler is uploaded. No data will be loss or need to be re-entered. I hope this helps.

Valerie

From: Naeem Huque <huque at jlab.org>
Sent: Thursday, February 2, 2023 12:07 PM
To: Valerie Bookwalter <bookwalt at jlab.org>
Cc: pansophy <pansophy at jlab.org>; Tony Reilly <areilly at jlab.org>; Ed Daly <edaly at jlab.org>
Subject: Re: AUPPS-FAB-HHOM-ASSY R2 for review

Hi Valerie,

I am not opposed to a revision but, as I understand it, this will not make the current instances of the travelers function. Those already have data in them and need these changes to function.

Thanks,

Naeem

________________________________

From: Valerie Bookwalter <bookwalt at jlab.org<mailto:bookwalt at jlab.org>>
Sent: Thursday, February 2, 2023 11:55 AM
To: Naeem Huque <huque at jlab.org<mailto:huque at jlab.org>>
Cc: pansophy <pansophy at jlab.org<mailto:pansophy at jlab.org>>; Tony Reilly <areilly at jlab.org<mailto:areilly at jlab.org>>; Ed Daly <edaly at jlab.org<mailto:edaly at jlab.org>>
Subject: RE: AUPPS-FAB-HHOM-ASSY R2 for review

Naeem,

I am attaching R2 of your traveler for your review.

Valerie Bookwalter

Jefferson Lab, ACCEL

SRF Operations

SROPS Software Systems Group

1-757-269-5802 (OFFICE – currently working offsite)

From: Valerie Bookwalter <bookwalt at jlab.org<mailto:bookwalt at jlab.org>>
Sent: Thursday, February 2, 2023 11:36 AM
To: Naeem Huque <huque at jlab.org<mailto:huque at jlab.org>>
Cc: pansophy <pansophy at jlab.org<mailto:pansophy at jlab.org>>; Tony Reilly <areilly at jlab.org<mailto:areilly at jlab.org>>; Ed Daly <edaly at jlab.org<mailto:edaly at jlab.org>>; Jacob Harris <jharris at jlab.org<mailto:jharris at jlab.org>>; Valerie Bookwalter <bookwalt at jlab.org<mailto:bookwalt at jlab.org>>
Subject: RE: AUPPS-FAB-HHOM-ASSY sn modified HHOOKSN

Naeem,

First, I need to let you know that I had to recant the changes to your traveler as just fixing the “typo” does not fix the problem you are having. I will explain later.

If a revision is made to a traveler, then it will only apply to future instances of that traveler, correct?

That is correct and hasn’t changed since travelers were first introduced in 2001. Therefore, it is so important the travelers are reviewed and approved prior to our uploading to the web. We do have a way of updating the revision on previously entered information, which still meets our ISO records requirements.

Could you please send an excerpt from our traveler procedure which states that new revisions need to be made for typos in a traveler?

This is not just a “typo”. This is an actual form input field and affects many aspects of the Pansophy system including database changes. Additional changes are needed in the database, hence the need for a new revision. You and your reviewers signed this version of the traveler as being accurate and correct. Once the approval process is completed and the traveler uploaded to the web any change requires a new revision. This has been standard practice since 2001 and followed by all work centers and projects.

I would like to be working against rules that we have in writing and approved, and not ones that are made up as we go along.

To imply that the Software Team does not work within standards, nor consider the affect these changes have to traveler authors underestimates the amount of time and thought put into producing the traveler system and supporting SRF Operations as a whole.

Making the process more arduous will make authors less likely to fix instructions on travelers that are incorrect or unclear, choosing to instead just let people know verbally or by email. This is how mistakes can happen on the floor. If we want this system to work smoothly, we can't add obstacles without looking at the bigger picture.

This is a very good reason why authors and approvers should be carefully selected and that each should read, review, and correct any mistakes in a traveler prior to approval. This is also, now, a part of SRF OPS quality management system that work control documents fall to project coordinators and work center leads to ensure accuracy and completeness. To state that, because the software team will not “fix your typo”, will cause obstacles and mistakes on the floor, seems a bit exaggerated for this discussion and may be better discussed separately.

If this is currently spelled out in the procedure, then I would request our management to review it for a revision.

If you feel we have somehow made this an arduous problem and feel it necessary to update our procedures, then feel free to contact Tony and have him address this with me.

If you would like to create a new revision of your traveler with the updated entry field, then we can work to expedite its approval and upload to the web. This is the standard processing for a traveler and the best way to keep the database and all related files correlated and correct. This is followed by all projects and work centers. For expediting the process, I have already generated a R2 for your traveler.

In the future, if a new project is being started, the inclusion of the Software Team in the WCD list and Acronyms sooner can help to mitigate such problems. The PRIMeS entry of components and acronyms is not directly reflected in the Traveler system, as I have spoken to you about before. We, the software team, are working on ways to better align the two systems and create a way to look for such “typos” when travelers are converted, so that we might catch such things sooner in the process. If you would like to help us in setting up such a system, then I would gladly hear any ideas and proposals you have which can help. The “fabrication projects” vary from “production projects” and we are working to come up with solutions and ideas to better support these types of projects. I have already spoken with Tony about this need for growth in the Software Systems, again you support in this discuss would be appreciated.

I hope this answers any questions you may have had, and I personally hope that we can find a way to work together to make “this system” as smooth as possible for all involved.

Valerie Bookwalter

Jefferson Lab, ACCEL

SRF Operations

SROPS Software Systems Group

1-757-269-5802 (OFFICE – currently working offsite)

From: Naeem Huque <huque at jlab.org<mailto:huque at jlab.org>>
Sent: Wednesday, February 1, 2023 11:47 AM
To: Valerie Bookwalter <bookwalt at jlab.org<mailto:bookwalt at jlab.org>>
Cc: pansophy <pansophy at jlab.org<mailto:pansophy at jlab.org>>; Tony Reilly <areilly at jlab.org<mailto:areilly at jlab.org>>; Ed Daly <edaly at jlab.org<mailto:edaly at jlab.org>>; Jacob Harris <jharris at jlab.org<mailto:jharris at jlab.org>>
Subject: Re: AUPPS-FAB-HHOM-ASSY sn modified HHOOKSN

Hi Valerie,

If a revision is made to a traveler, then it will only apply to future instances of that traveler, correct? If so, that won't work for me as the changes are needed to make the current instances function properly, and they are already in progress. I don't have any plans of opening new travelers for this portion of the project.

Could you please send an excerpt from our traveler procedure which states that new revisions need to be made for typos in a traveler? If this is not an actual requirement, then it seems a lot of extra work for a lot of people to make a change that does not affect the intent of the traveler (this includes the initiator as well as your group and the work center leads/techs reviewing the traveler). I can understand holding off on typos that just affect clarity, but that too has its drawbacks. Making the process more arduous will make authors less likely to fix instructions on travelers that are incorrect or unclear, choosing to instead just let people know verbally or by email. This is how mistakes can happen on the floor. If we want this system to work smoothly, we can't add obstacles without looking at the bigger picture.

My feedback for the Pansophy Request Form is that it should include an entry for something like this. It would be a way to track and formalize such changes. I believe this is the common-sense way to proceed, without causing work stoppages.

If this is currently spelled out in the procedure, then I would request our management to review it for a revision. I would like to be working against rules that we have in writing and approved, and not ones that are made up as we go along.

I apologize that there is a (several) typo in the traveler. While I try to make it as accurate as possible, they do happen from time to time, and I am sure I'm not the only one making them.

Thanks,

Naeem

________________________________

From: Valerie Bookwalter <bookwalt at jlab.org<mailto:bookwalt at jlab.org>>
Sent: Wednesday, February 1, 2023 9:38 AM
To: Naeem Huque <huque at jlab.org<mailto:huque at jlab.org>>
Cc: pansophy <pansophy at jlab.org<mailto:pansophy at jlab.org>>; Tony Reilly <areilly at jlab.org<mailto:areilly at jlab.org>>; Ed Daly <edaly at jlab.org<mailto:edaly at jlab.org>>
Subject: AUPPS-FAB-HHOM-ASSY sn modified HHOOKSN

Naeem,

I have completed your request to change HHOOKSN to HOOKSN.

I did this behind the scenes,  however we can not continue to work this way.

In the future, especially when data fields are wrong, a new revision must be generated.

This is the only way to ensure the entire system is kept in sync and keeps us straight in our ISO Records management.

Valerie

[cid:image001.png at 01D93700.51D96670]

Valerie Bookwalter

Jefferson Lab, ACCEL

SRF Operations

SROPS Software Systems Group

1-757-269-5802 (OFFICE – currently working offsite)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/pansophy/attachments/20230202/6a017896/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16765 bytes
Desc: image001.png
URL: <https://mailman.jlab.org/pipermail/pansophy/attachments/20230202/6a017896/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AUPPS-FAB-HHOM-ASSY-R2 - NH.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 551101 bytes
Desc: AUPPS-FAB-HHOM-ASSY-R2 - NH.docx
URL: <https://mailman.jlab.org/pipermail/pansophy/attachments/20230202/6a017896/attachment-0001.docx>