From Two People to Company-Wide Adoption: Combining Analytical and Organisational Support to Embed MI

Sanyu Rec operates across four business areas — electrical and electronic materials, semiconductor materials, construction and civil engineering materials, and various industrial adhesives and composite materials. In each, we develop, manufacture and sell formulated resins tailored to that field, such as industrial adhesives and coatings.

Our strength is the ability to meet a wide range of needs without being tied to any single field, application or process — drawing on deep understanding of diverse material properties and the know-how built up over more than half a century of developing some 2,000 products.

We also put significant effort into new product development and opening up new markets, and within the Development Department, the Materials Development Group is responsible for the R&D of the new technologies and materials that make this possible.

From selecting materials through deciding on processes, you could say there are as many "answers" that meet the required specifications and reach mass production as there are people working on them. We had long seen it as a problem that we weren't really pushing to identify which method delivers the best performance and the most efficient production — in other words, our product development wasn't optimised.

To stay competitive, we knew we needed to use modern IT to deliver both more efficient product development and a system in which data accumulates naturally as a by-product of the work. Around 2020, when I took over the Development Department, I began drawing up plans to reform our development process.

At around the same time, I was studying computational (simulation) chemistry, AI and MI in a part-time doctoral programme, and I was transferred to the Development Department with a mandate to develop and adopt new technologies. Those two things together kicked off our MI initiative.

What I learned in graduate school convinced me that materials development from here on has to fuse theory, computation and experimental chemistry to keep up — and that this isn't about whether we can do it, but that we have to, or we'll fall behind globally. I shared that conviction and sense of urgency with Ishii, and we started investigating how to adopt MI.

With nearly 2,000 products, we simply can't share or keep track of all the relevant information, which leads to waste — things like, "It would have been faster to improve this existing product, but we went a different way" or "We've got several very similar products with different formulations." I hoped MI and machine learning could resolve that and let us develop more efficiently and in less time.

We gathered information on applications and research institutions using "machine learning" as our keyword, and on cost grounds decided to start with an in-house approach.

I only had what I'd picked up in university lectures and no hands-on experience, so I learned Python and spent about a year building mathematical models on a low-cost no-code programming platform.

Along the way, two problems became clear. First, our data is fragmented because each customer brings different applications and bespoke requirements, so it's hard to gather enough data on any one thing. Second, building a mathematical model for a single property takes so much time and effort that we couldn't possibly cover the full range of required properties. Looking for ways to solve this, we arrived at Bayesian Optimisation.

It looked useful for our R&D, but I judged that understanding the underlying mathematics of Bayesian Optimisation and writing the code myself would be too hard, so we went back and looked at adopting a tool.

What particularly appealed to us about miHub® was that you can start applying MI with a small amount of data and no coding, and that you get hands-on support from data scientists. During the trial we also saw it deliver predictions and formulation suggestions at speed that the model I'd spent a year building simply couldn't produce — that demonstration of scale and speed was the deciding factor.

To embed MI use across the company, we focused on producing a concrete success and publicising it. The topic we chose affected the durability of the finished product — something the company had debated for years, where we had some theory but no full explanation. Roughly speaking, the question was, "A harder adhesive bonds more firmly, but it becomes weaker under temperature changes of the bonded parts. So what hardness is optimal?"

Working on this topic, we started combining Torigoe's CAE simulation expertise with MI — running virtual experiments and feeding the results back into MI-based materials design.

Early on, just coordinating with other departments to run physical experiments ate up a lot of time. With virtual experiments we could keep everything inside our own group, and the work jumped forward. Because the topic was a problem shared across the company, the results drew a lot of attention and interest in MI started to spread.

What really got people excited was the result — performance improved by doing the exact opposite of what our in-house know-how suggested. We pulled together the veterans who'd worked on this topic over the years and presented the simulation. All sorts of opinions came out based on personal experience, but in the end the simulation matched the actual test results. I still remember how surprised everyone was.

miHub® is straightforward to operate — one training session is enough to find your way around, and after seeing one or two themes through to the end I think you can use it independently. That said, I came to realise there's more know-how in how you use it than I'd expected. How well you fold your own knowledge and experience into the MI settings, and how you revisit your data and redesign experiments based on what MI suggests, really change both the results you get and how quickly you reach your goal.

With that in mind, I've come to see MI not as something mechanical that leaves no room for your own thinking, but as a good partner for experimentation — a big shift from the impression I had before we adopted it.

It's the same as how anyone can use an internet search, but some people are good at it and some aren't.

I had my own worries at first — would adopting MI make people unnecessary, would we just end up doing whatever MI told us? But it's the opposite: people working together with MI can aim higher than either could alone, so I'd rather set those worries aside and use it actively.

We did start with very little data, but as we've cycled through experiments the results have got better each round. I genuinely feel the progress, and I'm expecting that as more experimental data builds up we'll be able to reach our goals even faster.

As part of our outreach, we're running study sessions aimed mainly at younger staff. Some of them have started using MI proactively in their own experiments. It's gradual, but it really is spreading.

We have an organisational culture where people don't resist new things and, given a prompt, will go and look into them properly themselves. I think that's helping uptake along.

A major change is that, with MI, we're now seeing ideas I'd never have come up with on my own, and several different approaches to the same goal.

We've also had several cases where challenging projects that used to take one or two years, or that had stalled for a long time, were completed within a few months. And the fact that these results are coming out of younger members' own initiative is another sign of how effective MI is.

Another welcome change is that discussions during product development have become livelier and run more smoothly. The miHub® version updates in particular have made information much easier to read at a glance, and we now see team members debating around the graphs and trying out new approaches.

When I was building machine-learning models on my own, I really only looked at whether the accuracy was high or low. Working with Torigoe, we now actually discuss things — "this result is missing such-and-such consideration," "this looks just like the formulation I kept failing on as a junior," "the recommended conditions are starting to line up with what we know." That's made the work much more interesting, and it's exactly why I feel so strongly about the value of active discussion.

Taking MI's output and analysing and discussing it further makes the work more engaging and faster, surfaces things we'd been missing, raises the quality of our thinking, and so accumulates know-how. That cycle is where I see both the benefit and the necessity of using MI.

There were stretches where one or two of us had to handle everything from analysis to experiments, so having someone we could turn to for advice was a huge help.

What I appreciated in particular is that MI-6 brings chemistry knowledge as well as data science, so we didn't have to spend ages explaining — they grasped what the problem was internally and proposed solutions, and the conversation moved at a good pace.

In the early stages we relied on them for the analysis side of things — advice on interpreting results, answering questions and so on. As the work progressed, we also started consulting them on how to embed MI use across the organisation.

There were times when we couldn't get other departments on board and things stalled, but they advised us on how to run the initiative itself, and we're grateful that this kept us moving forward steadily.

When you consider that they don't just provide the tool but back you up with data science professionals across both the analytical and organisational adoption sides, it's genuinely a worthwhile investment.

First, I'd like to see discussions get even more lively, with MI at the centre — and I'm looking to miHub® to act as a communication tool for the team.

If we can share how MI is being used internally more broadly, I think more people will start using it as one of their tools, and better ways of using it will emerge. The first stage, I'd say, is to reach a state where that shift resolves both technical problems and issues in our development workflow, so product development runs more smoothly.

Beyond that, as adoption spreads, I'd like to build an environment where each group in the department has self-driven power users of MI, and where their numbers keep growing. With that in place, I want to shape a way of working in which we use MI to respond to customer requests immediately, and adapt how we use it to take on tougher problems.

The end state, as I see it, is that we stop making a big deal of "MI" or "AI" and simply use them day to day as useful tools, as a matter of course. As we do, clean, reusable data piles up over time, and that opens the door to other MI techniques. By analogy, just as order emerges from each individual acting on their own initiative — what's called self-organisation — I'd like the same kind of self-organisation of optimal data to emerge across the data we accumulate, woven together by people and MI. That's the ideal I want to work toward.