Putting Analysis in the Hands of R&D Itself: How MORESCO Embedded Materials Informatics with miHub®

We run five businesses: Specialty Lubricants, Hot-Melt Adhesives, Energy Device Materials, Synthetic Lubricants, and a Materials business supplying ingredients for cosmetics, shampoo and similar products. Our strength is in interface chemistry—the chemistry of what happens between two surfaces—whether that means lubricants that reduce friction or adhesives that do the opposite.

To help our customers run more efficient operations and respond accurately to volatile markets, our lubricants have to evolve alongside the machines they go into. That means continuous R&D, and it also means using digital transformation within R&D itself to improve the speed and precision of our product development.

From around 2020, a growing project pipeline combined with remote-working arrangements during COVID made it hard to run enough experiments, and we needed to make product development more efficient. That was the starting point.As we looked into how to improve efficiency, several issues around how we used data came into focus. Formulation work depended heavily on individual researchers, so veterans' experience and know-how were not being accumulated or passed on. Experimental data was not held in a shared, searchable form either, which meant we could not explore the formulation space efficiently.

Given those issues, we concluded that an R&D DX programme—reshaping our working processes around a data-driven approach—was an important lever for improving development efficiency, and we are now pursuing it company-wide with R&D at the centre.

In response to those issues, Sueyoshi started digitising how we managed our experimental data, and as that effort spread across the company, Konishi—who had joined us as a data analytics specialist—proposed that we make use of MI. That is how it started.

We started with internal study sessions. We pulled people in from each development department and ran them for a year, gradually scaling up. But far from MI adoption moving forward, I could feel participants' enthusiasm for it cooling off.

I enjoyed the sessions—learning about algorithms and so on was genuinely interesting—but I couldn't picture how to actually apply any of it in my own experiments, and I started to feel stuck.

In trying to get our developers to pick up data science skills, we taught fairly specialised material—and ended up raising the barrier to using MI rather than lowering it.

So we changed direction—rather than learning to programme and build machine-learning systems ourselves, we would use SaaS, and we reshaped the sessions around concrete outputs. One session covered Bayesian Optimisation, which works even with small sample sizes, and someone from one of the departments put up their hand to try it.

I ran the analysis and produced the suggested formulations using a third-party tool, and the developers made the prototypes. The suggested formulations turned out to show distinctive performance, which gave us hard evidence of the value of Bayesian Optimisation. That was a real turning point in bringing machine learning into our R&D.

One of the bigger hurdles to using machine learning in development is the question of whether to actually prototype the formulations it suggests. In this case, the developer's curiosity carried them past their experience-based assumptions and they made the prototype—and that, I think, is what unlocked the distinctive performance result.

With that split between analyst and developer, we ended up with a lot of back-and-forth—handing data over, explaining results, and so on. Even if we built Bayesian Optimisation into day-to-day work in that form, we wouldn't get genuine efficiency gains. And for developers to stay motivated and drive their own experiments, it really matters that they do the analysis themselves.

While we were comparing MI tools we asked for a demo of miHub®, and the trigger was really Fujii making a strong case for it. My first impression was that I couldn't see why we would add it on top of the tool we already had, but Fujii told me, "No, we need it. We obviously need it."

By that point I had drifted away from how developers actually feel as I focused on building data-science expertise, whereas Fujii had a clear sense that "unless a tool meets developers on the ground this closely, most of them won't be able to use it."

My impression of miHub® is that it takes specialist knowledge and packages it into a simple, easy-to-follow UI.

You could see the intent everywhere—"to let R&D people do MI analysis themselves"—and that the tool had clearly been designed around developers.

Exactly. With miHub®'s developer-friendly UI, I felt that if you followed the paths and experimental conditions the tool laid out, you could use it without being a data-science specialist. People new to MI wouldn't get lost using it, so I pushed hard internally that we absolutely needed miHub® to make MI use spread. A tool that offers a wide variety of analytical methods looks like it has more on offer, but for someone new to MI it just leaves them wondering what to use and how. miHub® is a SaaS purpose-built not for data analysis as such but for machine-learning-driven experiment planning, and I could really picture it spreading to a lot of our developers.

Having Fujii on the MI rollout team—someone with the developers' real-world instincts, alongside people like me with a data-science background—was vital to spreading MI across all of our developers. Without her acting as a bridge to the developers, I don't think we would have decided to adopt miHub®, let alone been able to picture rolling MI out across the whole company.

We had already brought in another analysis tool before miHub®, so we now use the two based on what each does best. Data scientists draw on their specialist skills with the other tool, while developers run their experiment planning in miHub®, where the interface is intuitive. miHub® is easy for developers to use and lets them plan experiments efficiently without leaning on data-science expertise, so we've set things up so that both sides can collaborate while playing to their strengths.

The hardest part was getting executive approval to adopt miHub® alongside the existing analysis tool. At first we didn't get buy-in, because we couldn't adequately convey our vision for how machine learning would be embedded across the company and built into our workflows, or how miHub® differed from the other tool. To be fair, we hadn't yet thought through clearly how the two tools should be divided up, so the pushback was understandable.

Our MI-6 account team worked hard with us to articulate the case for adoption. Through our discussions we came to appreciate again how important it is for developers themselves to be able to drive their own machine-learning projects, and just how usable miHub® really is. Talking through how to divide up the tools with MI-6 also let us rebuild our internal roadmap for MI: we had been heading towards a step in which we would expect everyone to pick up programming and other digital skills and study algorithms, and we were able to move away from that.

I'm also grateful for the support we had through the budget process. We wanted to roll miHub® out across the entire Corporate R&D Department under a company-wide budget, but the approval bar felt high. We were about to fall back to a partial rollout funded out of each business unit's budget, when the MI-6 account lead spoke frankly: "That fallback is easier, but if the goal is for R&D to drive MI adoption across the company, this approach takes it too far out of R&D's hands." It was reassuring to have someone who understood both the trajectory of the initiative and the position of those of us pushing it forward, and was prepared to back us.

With that support from MI-6, we secured approval to bring miHub® in under the company-wide budget. In the end it was approved in keeping with our culture—"if you want to try something, go and try it"—where new attempts are never simply turned down. We position ourselves as an R&D-driven company, and failure is never treated as something to dismiss. I'll allow myself a little self-praise: it really is a company where it's easy to take on something new.

A lot of manual work has gone away—shaping output data in Python by hand, for example. By following the clear process miHub® lays out, individual developers can now reliably produce experimental data grounded in machine learning on their own. It's software that fits comfortably alongside the experimental and day-to-day work people already have.

With developers able to run their own analyses, we save all the coordination and back-and-forth with a separate analyst.

The impact of miHub® isn't only efficiency—we feel it in the quality of the experiments themselves. With the formulations they have analysed for themselves, developers can confirm "this ingredient is doing the work" or "this property is what matters," and feed that straight into the next step. We've also had genuine new findings, with promising results emerging from formulations surfaced through miHub®. The fact that people new to MI, or new to development, can still apply machine learning to their experiments—that, to me, is where miHub® really stands out.

Working without a PC is unthinkable now, and in the same way I want using miHub® to efficiently arrive at new experimental conditions to become an ingrained habit.

As we work to broaden use and embed it more deeply, what I most want to emphasise is that developers keep growing their own skills while they push for new materials. Machine learning gives you outputs based on the information you put in. I want to make it second nature for everyone—R&D people drive their own experiments, and use machine learning as an effective aid within that process.

Exactly—value only emerges when you combine developers and MI. The richer the developer's domain knowledge, the more powerful the results MI produces. A lot of people get this wrong and think of MI as a magic tool that just hands you the right answer, freeing the developer from having to think. I'd rather we use MI like this: developers bring their domain knowledge to bear on framing the question and interpreting the data, and machine learning provides effective support inside the hypothesis-and-test cycle.

Right now we have each development department nominate one miHub® user, and we're working with them to build MI into our experiment planning process. This is part of growing a culture in which developers take the initiative on machine learning. As one company, we want to keep pursuing what an R&D-driven business should look like.

Underneath it all, I want to make the work of product development more interesting. Rather than using MI just to make work more efficient, I'd like it to help our developers take on more ambitious projects and grow as professionals.

One last thing—as we worked to spread MI within the company, the MI-6 team helped us enormously. Building machine learning into R&D turned out to be much harder than I'd imagined, and very little went the way we expected; I'm grateful for all the support we received.