How the World’s No.1 Photoresist Maker, TOK, is Building a Data-Driven R&D Culture Through Materials Informatics

TOK is a chemicals manufacturer whose flagship product is photoresist — the light-sensitive material essential to semiconductor manufacturing. We hold the world's leading share in photoresists, and the micro-patterning enabled by these materials is what makes ever-smaller, more densely integrated semiconductors possible. That technical achievement is, in turn, the material foundation behind the evolution of digital devices: smaller smartphones, longer battery life, faster communications. At the heart of photoresist-based semiconductor processing is lithography. We develop and supply materials with reactivity tuned to each lithography technology, including EUV (extreme ultraviolet) lithography for the most advanced nodes, in order to meet our customers' relentless demand for higher performance. Our greatest strength is the value we create through our customer-intimacy strategy. The essence of it is that, however difficult the challenge, we never simply say 'it can't be done'. Instead, we work side by side with the customer to find out how it can be done. Rather than offering products one-way, we sit down with customers in a co-creation style, trading ideas and tackling technical walls head-on. That posture is, we believe, the single biggest factor behind the strong trust we have built with customers and our current leading share.

At the time, the challenge had two sides: keeping pace with a rapidly shifting market, and a sense of urgency about our own internal culture. The product cycles for semiconductors represented by AI servers, smartphones, and GA devices have accelerated dramatically, and we — as a supplier underpinning that — are expected to develop faster than the market itself moves. Among younger people on the front lines especially, a strong awareness had already taken hold inside the company that R&D needed to be upgraded with digital technology, and that the existing development methods were running into limits.

That said, precisely because we had the track record of being the world's No. 1, a mindset of 'the way we've always done it is the right way' was deeply rooted internally, and the bar for stepping into change was high. We could feel the urgency — that at this pace we wouldn't keep up with our customers — but adopting a new technology with no guarantee of success required real caution, both psychologically and operationally. On top of that, the trade-off between time and resources was itself a major obstacle to change. We had begun working on MI in-house, but we couldn't honestly say we had enough specialist talent or know-how to support use across the entire Development Division, let alone the whole company. We wanted to apply it to live business and produce results straight away — but we didn't have the time to train people up from scratch.

It started with a referral from senior management, who had been impressed by a seminar at a trade show. With miHub®, engineers on the front line can practise MI by embedding it directly into their day-to-day R&D, so we had high hopes that it would address our challenges and be usable across the organisation. We also saw a clear difference from other tools: the usage scenarios on the ground were concrete, and the product was developed with a strong emphasis on the know-how of 'how to use it'. Its strong fit with composition optimisation — the core of our work — was another deciding factor.

The final push came from the response inside the company. In a survey after an MI-6 talk we held before adoption, many people told us 'I want to start using MI right away' or 'knowing that MI is being used in the same R&D area as ours made me realise we need to take this on too'. Making the front line's awareness of the issue visible in this way was a decisive element in the decision.

What stayed with me most from the talk was a success story in resist development — my own field — where MI had actually been put to work. I was genuinely surprised to learn that the things I think about during everyday work could be done on miHub®, and without any programming knowledge.

I'd always assumed you needed programming knowledge to really use a tool like that. With miHub®, my view shifted to 'this is something our department can absolutely put to use — I want to take it on'.

What resonated with me strongly was the point about the risk of over-reliance on individuals. It's not unusual for an in-house MI tool to wither away once the person behind it transfers or leaves the company. So the argument that the best move is not to insist on building it ourselves, but to bring in software that is continuously improved and supported by specialists, made complete sense to me. I came away convinced that this would let our developers focus on the more creative side of materials development.

If only a small group of us pushed MI forward in isolation, it would be very hard to ripple that change out across the whole company and start a genuine organisational movement. That's exactly why we wanted to draw on MI-6's deep know-how and activate work in parallel across different departments and themes.

To achieve that, we decided we needed end-to-end support that would lift digital transformation (DX) and MI activity across the entire Development Division, and we chose to bring in miHub® combined with coaching as that support framework. Being able to say with confidence — about our open questions and concerns — that 'this set-up can solve them' was the major trigger for moving to adoption.

For the MI rollout team, we adopted a 'pair structure' in which veterans support younger members. The idea was that the younger people — the ones with the appetite to try new things and change the status quo — would draw out the words and know-how of experienced veterans, so it could be made visible inside miHub®. By assigning these complementary roles, we set out to resolve the technical-handover dilemma that many companies face.

We also deliberately recruited members from a range of departments, to demonstrate that MI can be applied regardless of field. A secondary benefit was that the project created horizontal connections between people who don't normally cross paths.

In terms of how the work ran, we used the outputs and open issues as the basis for discussion with MI-6 — going deep on questions like 'what would get us a better result next time?' and 'what was the reasoning behind each round of trial and error?'. Once a direction was set, we ran experiments and analysis against it for a month, then went back into the next discussion. The project moved forward in that cycle.

First, the coaching lowered the psychological barrier to using the tool. miHub® gives you a lot of freedom in how you set up an analysis, which sometimes meant we agonised over 'what's the optimal configuration?'. Concrete advice on the tendencies of each setting and on 'which one is right this time, and why' cleared up that hesitation. We were able to feed sharp advice into our experiments and run a really effective cycle — that was the most valuable part.

No matter how many times we came back with questions in the regular meetings, the responses were always quick and thorough, and the team stayed with us until we genuinely understood. That kind of close support helped us enormously. Tidying up our internal data took far more time than we'd expected, and the early going was hard, but we kept at it through trial and error and ended up introducing a customer to a composition sample we wouldn't have come up with on our own.

R&D is, by nature, the business of arriving at success through a lot of failure — and the experience reminded us that even with MI, results come from stacking up the process. That is the essence of R&D, and we felt it again.

Unlike the other teams, we were applying MI to process analysis, and I was nervous about that at first. But MI-6 would suggest concrete analysis approaches, and we in turn would actively propose ideas like 'what if we set up these variables?'. Through that back-and-forth of detailed discussion and action, things ran smoothly.

I had actually felt for a long time that there was a problem with the state of our data internally. We had so many success stories, but the underlying data wasn't being organised, accumulated or put to use, and I wanted to fix that. With so many variables, optimisation itself is still very much a work in progress, but I feel a real sense of progress with the way MI lets us visualise data. In particular, being able to turn the 'intuition' of our senior colleagues into visible data has deepened my own understanding, and the quality of how I explain things to others and run data-based discussions has improved markedly.

miHub® is an extremely good fit for our department. The cleaning solutions and similar products we work with have relatively simple compositions, and small tweaks to the formulation translate directly into performance — so MI-based optimisation works very well here. Actually using it convinced me that everyone in the department can put it to work.

At the same time, I think that if we had brought in the tool on its own, we would have stalled partway. Every time you use MI, new questions come up, so the coaching — working through it with regular guidance from MI-6 — was essential to making MI stick. It also gave me a good reason to put my own questions and goals into words.

Once we'd taken the coaching advice on board and gone through the miHub® analysis results in detail, my view changed substantially. Conditions that experience told us 'wouldn't change anything' or 'wouldn't work' turned out, in fact, to have a major effect on the outcome. Trends that overturned our received wisdom started to show up. I came to see MI not simply as an efficiency tool, but as a platform that gives engineers new perspectives and lets them grow as engineers. The picture is: MI raises engineers' capability, and as a consequence, the development work itself gets better.

On top of that, the very act of collecting individuals' data so it could be consolidated into miHub® pushed internal data consolidation forward in one go. To my mind, that secondary effect — DX advancing alongside the MI rollout — is actually the biggest outcome of all.

We're now moving into the phase of rolling MI out across the whole division, and this time we're the ones doing the teaching. Drawing on what we learned — and on the hard parts we worked through ourselves — I want to take a leading role in spreading MI and making it stick.

When we reported our case at a recent internal poster session, a lot of colleagues turned up, from across departments. Many said things like 'if it can be used for process analysis too, I want to try it' — you can feel interest building inside the company.

Going forward, we'll broaden the scope beyond process analysis, combining it with composition data as well. The key here is something we picked up from the coaching: putting the intent behind an analysis set-up into words. I plan to explain logically why we choose a given variable, and to make it widely understood that the same approach can be applied to other themes in our own department.

Inside the department, there's still a sceptical voice that says 'it's faster to think it through myself than use MI'. It's exactly those people I want to show what MI is really worth — I genuinely want to move them.

This experience really brought home that standardising the format of the data we accumulate, division-wide, is essential to using MI more efficiently. From here, I want to share what we learned through the coaching, expand MI use, and get new technologies and samples to our customers more quickly.

My focus is on keeping the flame of MI alive. Up to now, the coaching has set the pace for us; from here on, the question is whether we ourselves can keep MI moving and sustain it. I want to drive it forward under our own steam, and show the people around us both sides of what MI delivers — short-term wins and the longer-term growth of our engineers — in balance.

My plan is to spread miHub® across the whole department and lift it into a departmental habit, and eventually into a culture. Once the cycle of accumulating and sharing experimental data takes hold, each person's analysis skills will improve as a direct result. Longer term, we're also planning to roll it out to our overseas sites. Up to now, having separate development sites has made information sharing difficult, but miHub® can get us past that wall. I have high hopes for it as a platform for genuine global collaboration.

Our overseas colleagues are interested in MI too, and we share information with them on a regular basis. Going forward, I plan to visit them in person to walk through the rollout, and to make sure what we've learned reaches our teammates at the overseas sites.

I'll also be the one doing the coaching from now on. I learned a great deal from how attentive MI-6's support is, and from the way they make it easy to bring things up — I want to follow that example and take responsibility for the work, including the overseas side. The immediate priority is making data visible through miHub®, but on how to embed and sustain MI inside the company beyond that, I'd very much like to keep learning from MI-6.

With this round of coaching, we made a deliberate point of building results across a diverse set of fields. Seeing tangible outcomes nearby has spread real enthusiasm for MI across the company, and inquiries are now reaching me from other departments in real time. I'm genuinely pleased that this group has gone out as 'ambassadors' for change and carried MI further.

As a company, we have set ourselves a goal of developing digital talent by 2030. The members who went through this project have, at the very least, gained the confidence to stand up and say 'I am a digital professional'. They are the catalyst for change, and the first shoots of that talent development have come through here. From here, I'm counting on them to grow those shoots, scatter the seeds among the people around them, and steadily widen the bench of digital talent.

I believe the common language of engineers is numbers. Across barriers of language, generation, country and company, numbers are something we can all talk in. That's exactly why I'd like miHub® to be more than an analysis tool — to take on the role of a communication platform where numbers are the shared language. MI, in that sense, is itself one form of that communication.

With miHub® as that base for activating communication, we want to grow a new culture across the whole organisation.

Another thing: because MI-6 has so many people with hands-on R&D experience, we feel they understand what we're up against at a deep level. Through the way they anticipate and act before we even raise a request, and through quick, sincere responses, we've felt just how attentive the support is — to the point where you find yourself thinking, 'they really will walk alongside us this closely?'

The wider world tends to talk only about success stories, but I believe that failure is reproducible. So that we don't fall into the same ruts, what we'd really value is hearing the failure stories — the ones that don't usually make it into public view. We look forward to MI-6's continued, attentive support as we grow this new culture.