Founded in 1950, Otsuka Chemical Co., Ltd. has built its chemicals business around contributing to the global environment and to richer everyday life. The company supplies materials and components that meet a wide range of needs across the automotive, electrical and electronic equipment, housing, and medical sectors.
In 2020, Otsuka Chemical set up an MI Preparation Office to bring Materials Informatics (MI) into the company, and adopted miHub®︎ later that same year. We spoke with Oozono, head of the MI Promotion Office, about what led to the decision and where the team is heading next.
Background to Adopting MI
A Rapidly Shifting Market for the Chemicals Industry
Could you tell us about your role and main responsibilities?
I'm with the MI Promotion Office, which sits within the IT Planning Department. As the name says, our job is to drive Materials Informatics forward inside the company. Broadly, the office has two missions: accelerating the launch of new products through MI, and supporting the competitiveness of our existing product lines.
What challenges were you facing before adopting miHub®︎?
Before I get to our internal issues, let me set the scene with what's happening across the industry. As everyone knows, this is a VUCA era — volatile and fast-moving — and end-product requirements are becoming far more varied. As a materials manufacturer, we feel the demands placed on us diversifying in step with that.
At the same time, product life cycles keep shrinking. Customers now routinely ask us to bring a proposed solution within six months, and material development timelines have compressed accordingly. In the past, plenty of partners were willing to stick with us for three or four years of joint development even when the target properties weren't yet met. That world is gone — we now have to put the materials the market wants on the table much faster.
Performance alone is no longer enough to win acceptance. New products now have to be launched with the SDGs, carbon neutrality, environmental impact, and responsible supply chains all factored in — and that has pushed up the difficulty of R&D another notch.
On top of that, players from emerging economies — China first and foremost — are multiplying. They're skilled at throwing large teams at a problem, and sheer headcount lets them push products that meet target properties out the door quickly. Even a low hit rate produces home runs eventually if you take enough swings, and that kind of brute-force development is intensifying competition on a global scale.
Taken together, these shifts have made development dramatically harder than it used to be. I'd imagine every chemical materials company is wrestling with the same thing.
Breaking Free of R&D Driven by Intuition and Experience
Against that industry backdrop, what challenges were specific to Otsuka Chemical?
As I said, development has become much harder over the past few years, but our own R&D process had stayed essentially the same. Most of the work was still riding on the knowledge, experience, and intuition of whichever researcher happened to be on the project.
For better or worse, you're anchored to what's worked before, so you only explore a narrow corner of the search space. When local optimisation happens to fit the project, things move fast. But if the answer lies outside the range of your knowledge, experience, and intuition, you can spend three or four years and still never reach the target properties.
And while new-material development gets harder, we also have to deal with raw-material price hikes and ageing plant — issues driven by the external environment. So alongside new product development, we have to keep existing businesses competitive to secure earnings, which makes it hard to free up people for fundamental research. Two issues stood out: success in R&D depended too heavily on the individual, and we couldn't secure enough people for fundamental research.
Objectives and Workflow of Implementing miHub®︎
Building an MI-Enabled R&D Capability with miHub®︎
What led you to adopt miHub®︎?
It was getting harder to deliver the materials customers wanted on the timelines they needed using our conventional R&D set-up, so building a capability that could take a new approach became urgent. We started by piloting MI to see how much it could improve R&D efficiency. At that point we had no in-house data scientists specialising in MI, so we needed to lean on an MI vendor's analytical expertise for both the pilot and the capability build.
To speed up fundamental research, we specifically looked for software that could optimise experimental conditions — but every option we found only handled a single objective variable.
A great many of our projects ask us to develop a material that simultaneously hits three, four, or five property targets. A material that's outstanding on just one property doesn't solve the customer's problem — we need to develop materials that strike a good balance across multiple properties. So we'd been looking for a tool that could optimise several objective variables at once. miHub®︎ was the one that did it, and that's why we adopted it.
The proposed support package also went well beyond pre-sales: regular post-adoption meetings on each analysis project, with advice drawing on deep analytical expertise and a large body of practical know-how. That gave us the confidence to commit.
How We Use miHub®︎, Step by Step
How do you actually use miHub®︎ day-to-day?
Materials development always starts from a problem, so we begin by agreeing on what that problem is. The researcher on the project briefs us on what material the customer wants and what technical issue they're trying to solve, and we align on the goal we're aiming at.
Next, the data scientists absorb the domain knowledge. Walking through the dataset together, the researcher shares their working hypotheses, the prior insights behind them, and the domain-specific constraints. This builds a shared vocabulary between researcher and data scientist, which makes it possible to design an analysis plan that both sides genuinely buy into. We see this as the key step for dramatically raising the project's chance of success.
Once the analysis plan is agreed, we move to the analysis itself. We don't just feed data into miHub®︎ and report 'here's what came out'. The data scientists go as far as they can into why a given condition is being recommended, then combine the researcher's knowledge, experience, and intuition with the insights coming from the MI side. The conditions both sides are convinced by are the ones we actually take into the lab.
By running this 'recommend conditions — evaluate' cycle several times, we narrow in on a material that hits the target properties.
The process of using miHub®
Results and Organizational Impact After Implementation
Development Workload Roughly Halved — Significant Efficiency Gains
What impact has miHub®︎ had so far?
I'd point to two angles. First, from the data analyst's point of view, both the quality and the speed of what we can propose have improved noticeably. The software is easy to use and the outputs are easy to organise, so the time from analysis to a proposal we can put in front of the researcher has shortened significantly.
From the researcher's side, miHub®︎ recommends conditions they would never have evaluated before. It surfaces fresh angles that don't come from prior knowledge, experience, or gut feel — the sort that get an honest 'wait, really, that one?' out of the researcher — and that has been hugely effective at stripping out their biases.
When we actually evaluate one of those conditions and the result is good, you often hear 'ah, so this is what's happening — you can get the property even in this region too'. That gives the team new insight and a fresh hypothesis to work from. The upside has been substantial.
The quantitative results are proprietary, so I can't share specifics, but our sense is that there have been cases where we developed a material in roughly half the usual time. A broad sweep of the search space also lets us cut out unnecessary experiments, which has clearly contributed to significant gains in development effort.
Sustained, Cyclical Use Cuts the Workload in Half Again
miHub®︎ has already made a big dent in our development timelines, but there's an interesting follow-on story. After we used miHub®︎ last year to develop a material that met a customer's needs, a new project came in with the same basic material composition and the same property targets in kind — only the target values were different. Because the materials and property types matched, we could carry the existing dataset straight over into the new analysis, and that has produced results startlingly fast.
Last time it took us seven rounds of 'recommend — test' before we reached a material that met the target. This time, building on the previous data, we already had a material that met the property targets by the second cycle. Astonishingly fast.
The previous miHub®︎ project got us to a new material in roughly half the conventional effort; this one looks set to come in at around a quarter. Cases like this convince us that miHub®︎'s impact on development workload grows the more consistently you use it.
Sceptical Researchers Now Leaning In
What kinds of changes are you seeing inside the organisation?
The positives are as I described. Inbound interest from researchers has been strong. Those who haven't yet tried MI are saying 'I want to run an experiment with miHub®︎, let me try it', and those who have already tasted what MI can do are coming back with 'do my next project too'. The response has been very positive.
That said, we still have issues. We hear things like 'I'm not sure what data to prepare' or 'getting the data in order is hard work', so we want to tackle this not just as an MI problem but as part of digitalising the R&D function more broadly.
On the negative side, the enthusiasm itself can backfire: some people start treating MI as a magic wand — 'use MI and the results just come' — and hand off projects without sharing domain knowledge or committing to work together.
By the end of last year we'd run analyses on 15 projects, of which four led to a solved problem. We don't hit the target on every one. For the ones that didn't pan out, we need to do an honest post-mortem on why and use that to find the patterns that lead to success.
Future Outlook for MI Utilization
Why We Stay with miHub®︎: Strong Support That Delivers Results
Why do you continue to use miHub®︎?
On the functional side, it's simple: miHub®︎ is the only tool that handles multi-objective analysis. And the internal track record we've built up with it is another big reason we stick with it.
The support is the other reason. They really listen to what users think and where users get stuck, work through the analysis results together with us, and ship product updates from the user's perspective. That's what gives us the confidence to keep using it.
And as I keep coming back to — being able to plan experiments with the researcher's biases stripped out has been hugely effective. On real projects, researchers have told us about the conditions we finally settled on, 'I would never have considered this before'. Pulling the best property values out of data-driven recommendations, with fewer experiments along the way, is genuinely valuable.
Putting Data to Work as Corporate Strategy
What do you want to take on next with MI?
Mastering MI isn't the goal in itself. Our corporate philosophy talks about continuing to create original materials that enrich people's lives around the world — that's the goal. To keep delivering on that, I want to support our researchers so they can do more creative work.
To get there, we need to surface every bit of data we hold internally and build the environment that lets us use it strategically. Pulling that consolidated data together, analysing it, and producing new insight from it is something we'll keep working on. At the same time, internal data alone has a ceiling, so we also need to think about how to bring in data from outside the company.
Leading the Industry by Building a Data Ecosystem
When you say external data, what sort of thing do you mean?
Typically that means publicly available databases — there are plenty of reported examples of teams drawing on molecular data, patents, and academic papers to feed their own R&D. But what I most want to do is share experimental, development, and marketing data across the whole supply chain, customers included. In other words, build a data ecosystem.
For example, we naturally hold the property data for any new compound we develop. Customers run their own evaluations using our new material and hold those measurement results. If we could link the customer's measurements with the property data on our new material and analyse them together, we believe we could help the customer hit their own target values far more efficiently.
In practice, sharing data between companies is far harder than that, and we know there are several hurdles to clear — but it's a goal we'd like to get to one day.
How practical this turns out to be, I can't say. But linking data across companies to form a data ecosystem could be one way to take Japan's materials industry — already a leading industry — and put it in an even firmer position. So I'd like to push this forward in partnership with people both inside and outside the company.
Key Success Factors for Building an MI Organization
How a 'No Results Required' Policy Produced Results
Finally, any advice for people setting up an MI organisation of their own?
Honestly, we're still very much in learn-as-we-go mode, so I can't claim to lecture anyone. But let me share what we've taken away from roughly two years of working on MI.
The MI Promotion Office started life as the MI Preparation Office, and the Preparation Office was set up under a clear policy of 'no results required'. From where we sat, that was an enormous help.
Assigning people to a new team means payroll and operating costs. Once you're putting a budget against something, it's natural to expect concrete returns — shorter materials development cycles, cost-saving proposals, that kind of thing.
But the executive who set up the MI Preparation Office gave us a different mission: 'I won't ask you for results. In return, I want you to think through, exhaustively, whether MI is technically useful, whether it fits our company, and — if it does — how we actually put it into practice.' That meant we could focus solely on answering those questions.
Having that framing put in place top-down was a genuinely good policy, so I'd say it's essential to start by setting a policy that lets the team explore without being measured on results.
Sharing Domain Knowledge Between Analysts and Researchers Is Essential
On the practical side, I'd say sharing domain knowledge matters more than anything else. Deciding which parameters to use as explanatory variables while absorbing the domain knowledge, and building the dataset together as you go — that's what keeps a project from going off the rails.
Just analysing whatever dataset lands on your desk, without thinking about it, almost never yields an optimum. As you run several rounds of 'recommend — test', the small adjustments and the new hypotheses you build along the way are what matter. Without shared domain knowledge it becomes a numbers game, the researcher receiving the output can't see where to take the work next, and a project run that way is almost certain to stall.
Once domain knowledge is properly shared, you can have the conversations that really move things — analytical tweaks like 'we took explanatory variables X-1 and X-2 you gave us, multiplied them into a single parameter, and the accuracy went up', or debates like 'the recommended conditions are running counter to our current hypothesis — why?'. Those are non-negotiable.
Suggesting a different variable to try is only possible if you actually hold the domain knowledge, so it pays to dig into the field thoroughly until you and the researcher share a common vocabulary. Once that level of collaboration is in place, the odds of success climb sharply — which is why we treat domain-knowledge sharing as critical.
Just Start: The Real Feedback Only Comes from Doing It
Any advice for companies that don't have data scientists in-house?
You could start by getting people to a point where they can write Python, then move on to statistics and machine learning, and that approach is fine — but it takes a lot of time. We tried that path ourselves and found it badly inefficient. From experience, I think bringing in outside partners to work alongside you is the essential approach.
Of all the data-analysis software out there, miHub®︎ is probably the best place to start. It tends to produce results, of course, but more than that: the interface makes it easy to run an analysis, the output files are easy to read and organise, and the whole process — running MI and interpreting what comes back — is straightforward. That helps you build a clearer picture of MI as a whole. And because you get strong support from a dedicated data scientist as you go, you build up your own analysis know-how at the same time.
You don't need to understand machine learning. You don't need to know what Bayesian Optimisation is. Just try it. Then, working through the results with experts, figure out what a winning pattern looks like for using MI in your own R&D. That, I think, is the best first step into adopting MI.
Thank you very much to the team at Otsuka Chemical Co., Ltd. for generously sharing their time and insights.
*Note: The information presented here is current as of the time of the interview.
You can download more details about miHub®, our SaaS-based Design of Experiments (DoE) platform, for free from the link below.
Click here to request information on miHub®
For any other inquiries regarding Materials Informatics (MI), please feel free to contact us at the email address below.
Business Development Department, MI-6 Ltd. bd@mi-6.co.jp
