Seven stages of chemical technology from creativity to industrialization (Issue 31/Total 100)--Common traps in technology research and development

Thread Content

This post was last edited by xiouxingzhe on 2026-6-11 11:49 The seven stages of chemical technology from creativity to industrialization (Issue 31/100 in total) - Technology R&D: Common traps, fellow seafarers: Hello everyone! The content of the third phase, from the 19th to the 30th issue, talks about proof of concept, catalyst screening, condition optimization, separation exploration, continuous small-scale test, pilot scale-up, sensitivity experiment, and data packet quality. Instead of moving forward with new content in this issue, let’s stop for a moment and talk about some of the pitfalls that are most likely to be stepped on at this stage. Some of these pits I have fallen into myself, and some I have seen others fall into. I don't write this to appear smart - on the contrary, it is precisely because I have stepped on the pit that I know where the pit is and how deep it is. 1. Premature optimization This is the number one trap in the technology research and development stage. What is premature optimization? Before the proof of concept was solid, and it was uncertain whether the reaction could be reproduced stably, we began to adjust the temperature, mixing ratio, and conduct orthogonal experiments, hoping to find the "optimal yield." I've seen more than one team make this mistake. The small test device had just been set up and the first batch of experiments showed that the yield was acceptable. The team was very excited and immediately started optimizing. After several rounds of optimization, the yield has indeed improved, and everyone feels that the direction is right. But later it was discovered that the "improvement" had little to do with optimization measures - it was just that the operation was becoming more and more proficient, the raw material batches happened to be better, and the ambient temperature happened to be in the optimal range. After changing a batch of raw materials, changing an operator, and changing a season, the yield dropped back again. The previous "optimization" was in vain and also misled the subsequent enlargement design. The order cannot be messed up. First ask "can it" - whether the concept has been verified and whether the reaction can be reproduced stably. Ask "how good" again - conditional optimization finds the operating window. Finally, we asked about “saving more”—whether energy consumption can be reduced and costs can be suppressed. Don’t jump to the next step without confirming the previous step. Everyone understands this truth, but when it comes to actual implementation, the pressure of project progress and the team's eagerness to produce results can easily make people skip a step. How to prevent it? My own approach is to set a clear "passing standard" for each stage. The passing criteria for proof of concept are: The core reaction can occur, and the results are stable three times. The passing standard for conditional optimization is: Operating windows for key variables were determined and boundary conditions tested. The passing criteria for the separation plan are: There are laboratory validation data for the primary solution and a preliminary evaluation for the backup solution. Once the standard is reached, move on. If the standard is not met, it doesn’t matter who says it is “almost”. 2. Blindly amplifying the second common trap is more costly than the first. The data from the pilot test are very good, investors are optimistic about it, and the owners are urging it to start pilot testing as soon as possible. The team could not bear the pressure and hastily started the design and construction of the pilot plant before fully accumulating data from the small trial and carefully analyzing the amplification rules. What's the result? The pilot plant was built, but it was discovered that the yield dropped significantly after the reactor was scaled up. Why drop? It’s unclear—because no amplification sensitivity analysis was done during the pilot stage, it was not clear whether the reaction system was sensitive to mixing, heat transfer, or residence time. The pilot plant was scaled up based on geometric similarity, but geometric similarity is not the controlling factor of this system. The data from the pilot test did not meet expectations, but the device has been built and the money has been spent. Renovation? Another round of money to invest. Continue to use it? The data deviation is too large to support subsequent design. The root of this trap is not technology but management. The technical team knew the risks, but faced the urging of investors and management, they did not clearly explain the risks and did not accurately convey the message that "the preparations that should be done have not been completed yet." When management sees good pilot data, they instinctively want to accelerate progress - that's their job. The responsibility of the technical team is not to obey the management's rhythm, but to truthfully assess and clearly communicate technical risks. How to prevent it? Before starting the pilot test, conduct a pilot decision review. The contents of the review are those discussed in the previous issues 26 to 28.: Have you done any amplification law analysis? What amplification sensitivity experiments were done in the pilot stage, and what else must be done on the pilot plant? What is the assumption of the amplification criterion? What are the consequences if this assumption is not true? How are the scale and plan of the pilot plant determined? If you cannot answer these questions clearly, you will not be able to take the pilot test. 3. The "liability" of data management This trap is relatively hidden, but the trouble it causes is often exposed only at a later stage, and when it is exposed, it is too late to remedy it. The pilot phase generates a large amount of data - daily operation records, analysis reports for each batch, data comparison before and after each process adjustment, and recording and analysis of each abnormal event. These data may be jotted down in a notebook, written on a whiteboard, or recorded in the operator's mobile phone memo at the project site. The project team thinks "we all remember it", but in fact the data is scattered among different people, different devices, and different formats. When it comes time to do packet summarization, problems arise. The running data for a certain day could not be found - the notebook was soaked in water. The original record of a certain key parameter was missing - I thought "this is not important" at the time and didn't remember it. Root cause analysis of an abnormal event - I did the analysis at the time but did not write it down. Now I only remember that "it was probably a problem with the catalyst", but I can't tell what the specific problem was. This is the "liability" of data management - the time saved in recording and sorting is paid back in double the time later. What's worse is that some debts cannot be repaid - once the data is lost, it is lost forever, and you can only re-experiment to replenish it, or enter the next stage with uncertainty and increase safety margins in the design. How to prevent it? Before starting the pilot test, a data management system must be established. In what format should the experimental data be recorded, where should it be stored, and who will review it. Standard template for operational logs - what must be recorded for each shift. The recording requirements for abnormal events must include three levels: description of the phenomenon, preliminary analysis, and handling measures. Rules for data archiving - how to name original data files, how to classify and store them, and how to back them up. These may seem trivial, but it is these trivial things that determine the quality of the data packet. The most important and core output of pilot tests is data, not products. If you skimp on time in data management, you're cutting corners on your most important output. 4. Don’t stop when it’s time to stop. There are two key stop-loss nodes in the technology research and development stage, as mentioned in Issue 19. The first one is after the proof of concept is completed. The reaction cannot occur or the product signal is extremely weak - it is time to stop. The second is after the small trial continuous run is completed. Continuity doesn’t work in this system—it’s time to stop, go back to the intermittent route, or reassess the direction. But at these two nodes, many projects failed to stop decisively. Why? Because "I have already invested so much", because "Maybe I will break through if I try again", because "I can't explain to the leader if I stop". Each of these reasons is understandable, but none of them should be a reason to continue. Sunk costs cannot be used as a basis for decision-making. This principle has been mentioned repeatedly in Issue 11. If you saw the results of this experiment for the first time today without any upfront investment, would you continue? If the answer is no, it's time to stop. There is another situation that is more subtle - not "can't do it", but "can do it but the economics are questionable". The reaction can occur and the yield is not bad, but the cost is much higher than the existing route. At this time, many people will continue to move forward with the hope that "costs can be reduced by optimizing." Optimization may reduce costs, but it may not. If it cannot be reduced, the time and money you continue to invest will be a net loss. My suggestion is: For this kind of situation where "it can be done but the economics is doubtful", set a clear verification period-for example, two to three months-and focus on solving the problem. If there is no breakthrough when the cycle arrives, decisively pause. Don’t let “try again” turn into “keep trying.” 5. Several mental pitfalls In addition to the pitfalls in the above four methods, there are several mental pitfalls worth mentioning. One is the mentality of "this time is different from last time". I have been working on projects for many years. Whenever I encounter a problem, my first reaction is often "this time is a special situation." It is true that every project has its particularities, but the common rules are more important than individuality. If you feel that "the last experience is not applicable" every time, you will never be able to accumulate reusable experience. Another is the mentality of “hide the data if it’s not good enough”. There are always some unsatisfactory aspects in the data generated from pilot tests - the yield of a certain batch is low, a certain working condition is not stable, and a certain sampling error occurs. When some teams make data packages, they will selectively exclude these "unsightly" data and only display the best performance. This approach may make the report look better in the short term, but it will do great harm in the long term. The excluded "unsightly" data is precisely the key information that reflects the real fluctuations and potential problems of the process. Covering them up is tantamount to laying hidden dangers for subsequent designs. Another is the mentality of "the pilot test is just for the small trial". The purpose of some teams conducting pilot tests is not to provide data for subsequent engineering design, but to prove to investors or leaders that the results of pilot tests can be amplified. Once this positioning is deviated, the operation of the pilot test becomes a performance - only running the optimal working conditions, only displaying the best data, without exploring boundaries or exposing problems. Such a pilot test is equivalent to doing it in vain. Next issue preview No. 32: Para-phenylenediamine Continuous Flow Case - From Laboratory to Pilot Test Now that we have discussed the methods and pitfalls, the next issue will conclude the third phase with a real case. The continuous flow process of p-phenylenediamine, the complete process from the small test in the laboratory to the pilot test - what problems were encountered, how to solve them, and what extent the data package was finally achieved. This is a case of original innovation. There is no existing experience to refer to, and many pitfalls are encountered for the first time. Expand next issue.