PTC - Problem corners¶
This chapter contains problems seen but not addressed.
Standardization (and Vetting)¶
Asking customers to use standard solutions could help reduce FTE load, for more important work, but how do customers know what DATA recommends as a standard. Additionally standards change and the method choosen to communicate standards should give insight into new development or replacements to allow forward planning. Standards are both h/w and s/w.
Vetting is not a nice job, but offers some degree of control over purchases. I’m sure that Nicola, who takes most of the brunt, would apreciate a DATA review of the procedural problems (already purchased before vetting) and how standardization recommendations are to be handled.
What is out there queries¶
When handling a vetting request or deciding what to buy, or what s/w should be use or developed it is necessary to identify whether it’s a standard, is or is not already integrated, whether there’s a recommended different solution, etc? DATA groups probably have very different answers to the above questions, we should review and improve if needed. Remember new people in DATA or EuXFEL cannot know the answer.
Ancient equipment¶
Integrating equipment that was last used years before, not at XFEL, has not been integrated, has an obsolete interface, may not even work, and will only be used once is a problem. But many instruments and user experiments come with such equipment. DATA access to proposals is needed to recommend a better solution or get early warning is needed.
Many cameras have been integrated, would it not be better to use in house equivalent or better than detectors. How to convince users that it’s an advantage probably means making it easy for them w.r.t. use and analysis.
Missing h/w maintenance, replacement and upgrade strategies¶
Recent cost-estimates have included projects which are known to require later upgrades. Is it a good strategy not to have a path to the required solution not mapped out? This seems particularly true of instrument completion projects where very old ideas are picked up.
Smaract controllers, what is the strategy for eventual standardization? That is one example, but there many. Can there be a strategy without blocking improvements?
Opening a dusty cabinet and finding a spare with a postit saying “possibly faulty” is not a maintenace, repair or replacement strategy. Who should have a strategy and do they?
Difficult relations¶
What’s the answer for personnel requesting work from DATA who consistently do something which is not aligned with DATA norms. How to turn this situation into something profitable?