Unbundling the software hairball at Cohu
- Summary:
- Semiconductor test cell and inspection firm Cohu demonstrates how to successfully scrap past technology investments in favor of an all-in Oracle strategy
Whenever I hear about a situation where a firm wants to extricate itself from a hairball software landscape then I am all ears. Cohu Inc, a Poway CA, based test cell and inspection business in the semiconductor market is one such and I recently spoke with Craig Halterman, the firm's CIO.
As background, Cohu has been around for 50 years in a variety of markets but in the last 15 or so years, has focused on the test and inspection segment, largely growing through an acquisition strategy that includes operations in Germany, Switzerland, USA, Japan, Philippines and Malaysia.
Along the way, Cohu acquired a variety of systems including SAP, Glovia and SYSPRO. By 2016, the firm's leadership realized that endeavoring to operate efficiently with this software application landscape was not viable. Halterman explains:
I came in to help leadership figure out what needed to be done. They knew they weren't getting the synergies they expected from the acquisition efforts. They just didn't have the catalysts, which was a systems platform that allow them to work as one company so we started the journey as an effort to become one company from a series of integrations. And we we joke still today about their prior strategy for integration was basically they change their business cards and they change the sign on the building and they call themselves integrated.
That translated into multiple problems. On the one hand Cohu operates as a leading provider in several segments but there was no realistic way for the firm to go to market as one company. There was for example, the risk that in deals, sales people would fall over each other rather than selling in a collaborative fashion. Systems didn't talk to one another and, as is often the case, the definition of even the most basic information such as 'purchase order' was different across the systems.
To make matters worse, each of the systems in use was highly customized and often very old. That meant the knowledge and expertise required to keep those systems running was increasingly concentrated in the heads and hands of a small (and inevitably diminishing) number of 'experts.' This landscape had evolved on the theory of taking basic components and then building out what was needed.
The basic approach
Conventional wisdom would have you think that in those circumstances, you consolidate down to a single system, picking the best of what you have or go for a best of breed approach. Halterman took a different view.
We could have taken (say) a Workday, Salesforce, Oracle/SAP approach but in my view that would leave us with important and potentially costly integrations. Sure, you can look at a single suite and say that it doesn't necessarily equal best in class but that was less important than the ability to standardize across the entire organization in the knowledge that basic information would mean the same thing in every system while allowing us to think in terms of a platform for the future.
Halterman's approach comes with an implied caveat. In making a single supplier choice, buyers must be aware of how the proposed supplier's technical and functional roadmap matches the business journey and its requirements. That made the choice of Oracle an interesting proposition because for example, when Cohu started its journey in the 2017 timeframe, Oracle's supply chain solution was only partially baked.
Our head of HR had gone outside IT and bought Oracle's cloud HCM solution and was getting on just fine. But what impressed me is that Oracle cloud sales is not really sales in the EBS (Oracle Enterprise Business Suite) sense. I'm not a huge fan of sales. Those folk tend to have me running away. In this case, I've been pleasantly surprised. You don't often hear this but I see the Oracle sales team as much more of a partner. And yes, parts were not as advanced as we might have liked at the time but we can always see the way forward.
I asked Halterman to expand on that. He said that Oracle 90-day roadmaps are delivered as promised so there is confidence that they will do as they say. When it comes to customizations, Oracle listens and while customer innovation requests are treated as 'ideas' inside the Oracle customer cloud community, those same requests stand the chance of development where peers see a common need and vote up a particular requirement. On occasion, Oracle has helped Cohu find the right answer where an outlier piece of functionality seemed essential.
At times they have provided us with things that don't seem to be in their economic interest but which do help us. This is a culturally different Oracle to the one with which I am familiar and it makes a big difference in our ability to give the business what it needs.
Change management - the biggie
None of this was possible without a significant change management program and I wondered how that went.
It was recognized that this is going to be a large organisational change, because the collection of systems allowed cultural barriers and the cultural barriers at each site gave us that underlying ability to stop and say, I'm not going to do that. I'm not going to accept change. I'm not going to have a solution that actually unifies us as one company, because that would be giving up what I like.
In common with other firms I've spoken to, the scale and magnitude of the problem was not truly understood and it was assumed that change management could simply be added to the CIO's portfolio because all of the changes included significant technical components so why not add the organizational change element? Halterman understood this was not a winning solution and knew he was not equipped to take on this responsibility.
There were many basic things we didn't know and while we thought we understood our processes, where the commonalities were and where we were starting from scratch, the reality was that important elements were not documented. We leaned heavily on our implementation partner (Insprage) to get this work done.
Big Bang worked
I was surprised to learn that Cohu adopted a 'big bang' approach to implementation rollout. In my experience this carries significant risk. Halterman countered saying that 'big bang' allowed the firm to keep the project under control while continuing with the change management program and at an accelerated pace. This approach forces the pace of change because there isn't the time to consider significant integrations. Instead, it encourages taking the vendor standard wherever possible. But it wasn't without difficulty.
We found that our data was really dirty. So on one hand we had an implementation that was working as described but the data quality was awful. But again, this was an opportunity.
This translated into what Halterman describes as an extension to what was an ambitious 13 month project cycle.
Throughout our conversation Halterman returned to the theme of change and the need to keep as close to industry best practices as defined by Oracle's software. In his view, when taking on a project of this scope, it is the only viable way to regrew and renovate for the future. The way he sees the project, the Oracle implementation is designed to build a platform for the future rather than being an end in itself.
It's definitely stressful to have that conversation when you have one engineer telling another engineer he has to change and he has to do more. He has to do XYZ but in the end, it makes us a better company. It makes us more competitive.
Mindset reset
As always in these conversations I like to discover learnings that can be passed on to others. Here Halterman provided what for me is one of the best takeaways I've heard in a while. Alongside the exhortations to manage change well and data clean up he added this:
We need to get away from our on-premises mindset of putting something in over five years and customizing the hell out of it. Let the software experts provide the solution. In back office, I don't believe there is anything special about what we do and why should there be? I didn't invent GAAP accounting principles or quality and they aren't going to revolutionize whatever function that fits. We want to operate with a platform that extends beyond this year, the next year or the next five years so we can focus on the things where we differentiate.
My take
Who says CIOs are a board room sidecar? A practical and focused take on complex problems is always welcome but Oracle's partnering approach combined with meeting delivery promises and actively helping customers is welcome. The mindset change element requires a willingness on both sides of the table and it is refreshing to see how this company and its team recognized and responded to that need.
To have accomplished the transition but also recognizing that today's environment is not one conducive to old style 'set and forget' approaches to implementation but a journey requiring continuous improvement and attention to detail is equally refreshing. This should act as a clear warning to those firms who believe that their entrenched systems of 10,15 or 20 years heritage are set in stone. They will be left behind, or faced with an ever expanding technology cost base that is not only difficult to maintain but more difficult to justify. This is especially true where the upcoming leadership has been brought up in an 'always on' world and where their understanding of technology is more advanced than those of my baby boomer generation.