Companies are increasingly offshoring product engineering work - and this trend is seen across most hi-tech and manufacturing verticals. Most companies today are not even averse to offshoring core product components and technologies to capable vendors. But are they getting the true benefits of offshore product engineering? Are the benefits of systems engineering outsourcing significantly greater than discrete project/ component/ competency based offshoring? Are there risks in systems engineering outsourcing which offset the value delivered?

Abstract

The session focuses on the reality of changing offshore System Engineering among the global companies and what they consider while deciding their engineering operations. Panelists shared their experience on systems engineering offshoring and with the engineering service providers. Panelists conclude that the huge talent pool and domain expertise, led by mature offshoring experiences are the main driving factors that are driving engineering jobs to India and other offshoring destinations.

Discussion

Sandeep Kumar: Welcome to the session on offshore systems engineering a myth or a reality. I am very pleased to have our distinguished panel with us. I would request the panelist to spend a couple of minutes introducing themselves, a bit about their background, their company, the kind of work they do at their organizations and the kind of work they are either doing from the offshore product engineering perspective or looking to do.

What we would want to achieve here is to see it comes to systems engineering and product development rather than a discrete outsourcing. What does it take to do an end-to-end system, and why have some people taken the leap of faith to do it here in India and why are some people sitting on the fence. Let me just ping Michael at Juniper. You know the engagement model that we have and it is drastically different from what we have done, say, with you in the past. Can you talk a bit about what we are doing and why the mechanism here?

Michael Frendo: I think it is important to look a little bit at the history. What happened with my experience with HCL in my previous role before joining Juniper was we did in fact take that leap of faith when I arrived in my previous company. There were a lot of skepticisms with respect to working with HCL. The interesting story that I would like to relate is that I asked my team what's the issue with the team in Chennai they just said that they were not productive and just can't seem to get things done.

About a month later, I came here and met with the team in Chennai and asked them about their issues. They said we could be more productive if we have little bit more equipment here. I went back to my engineering team there and explained to them the Chennai team's grievances, and what my leaders back in US told me was that we don't want to send them any more equipment because they are not very effective. Finally, I asked the team in the US to take all the equipment in all our labs which were not being used and ship it over there, along with my key engineering leaders. Within six months, it was pretty much a turnaround.

Sandeep Kumar: So Michael, what changed in your next organization? Why did it not go through the same cycle where you first outsourced the street pieces started small, grew over a period of years and then thought about doing full productization. Now, here, we are doing full product engineering. What changed?

Michael Frendo: What changed was really the maturity and knowledge base. I think what's happened in India over the last 10 years is that the engineering team here has learnt. There's a better exchange of information, more end-to-end ability to deliver, and more understanding of the process. What we found was that if you do go and do things that are more end-to-end and more self-contained, you have an accelerated or multiplier effect on the ability to deliver because you are enabling the team to operate relatively independently.

Sandeep Kumar: Zahid does the work that you do in your captive differ in terms of product development versus what you would have confidence of doing outside? Is there any differentiation that you see happening now or in the future on that?

Zahid Hussain: We started four years ago with the offshore development center with one of our partners with HCL. In the beginning, a few things happened that were just plain wrong. But we learnt. So about two years ago, we started making a shift away from this team extension model to more of a model we said: provide more ownership to the teams, let them have larger modules, larger pieces and complete them on their own, monitor the deliverable but don't manage the team. Then all of a sudden things started working. Now you asked the question about the captive. If I had to compare the captive with the ODC, understand that there is a timing issue, because we started the captive now with all those learning in mind. We had all the understanding about how do you go ahead and build. And now we say, okay, when we are going to build captive datacenters, not so much of a difference in relation to skill sets, people, and mindset. There is the element of bringing somebody into certain corporate culture and compensating them in the way that the company that you belong to compensates them and being involved in the growth path in their careers. You don't do such things when you are typically involved with the ODC model. So there is a difference in that way. But I think the learning that we got was that early on let that captive team get as much ownership as they possibly can get and build critical mass, build the right leadership structure, but give them ownership as opposed to try and manage them remotely.

Sandeep Kumar: Ashwin if you were to, a kind of, take a leap of faith and do an end-to-end product would you rather do it in a captive or in an outsourced ODC kind of a model?

Ashwin Ballal: I heard Shiv talk about leap of faith and it comes with the leap of faith but then there needs to be strong management, commitment and accountability. We are increasing and thank you HCL you have done your share. But you will continue to be pushed and then there are domains of expertise that we would continue to push so that we could do end-to-end solutions. To answer your question whether systems engineering is a myth or not or reality I think it's more towards reality. That's what we want t o do. At least at KLA-Tencor we are committed and as a result of which I am here now in India to actually drive some of these things. But I think it's not something that can be done completely out of a captive. The captive is there for a certain reason because we have got IP associated with our tools. There are certain things that will absolutely categorically stay within the captive. But there is plenty of room for our partners to also build on, but there are deficiencies in our partners today. I think there needs to be an investment in specific domains. And I am looking forward to that as an engagement with our partners as to how do we develop these domains. First, identify the domains that we have and the gaps in it, and then start filling them up. So that's the view that there is the collaborative environment where the captive will play its role.

Sandeep Kumar: Paul now that you've been talking to some people evaluating, offshore product engineering for some of your product. Where do you stand? Are you seeing that you can do full products? What is your view as you are in the middle of this evaluation?

Paul Mears: In terms of how we want to do our overall development and what we are looking at, initially, we are probably looking at a very isolated maybe smaller project that's going to be more of low risk from a development standpoint, but could be higher risk for a business standpoint. That first project maybe something that we deploy in China. As many of you are aware, doing business in China you really get one shot to do it right. If you mess it up first time you probably aren't coming back.

Sandeep Kumar: So is it going to be a full system or is it going to be components of it would be done?

Paul Mears: It's actually going to be components of a system. Basically it's a data collection type device that would be used for monitoring, gathering information on what consumers purchase.

Sandeep Kumar: So Mr. Kim over to you. What is your take on what the panel is saying?

Stephen Kim: I think when we say offshore versus onshore it depends on the viewpoint. If you are trying to consolidate operations, you would encounter HR problems and other problems as well. What you need to do is offshore engineering. In offshore engineering, you have cultural difference and you need to make sure who your partner is and the transparency in the partnership. So the key issue here is when we go onshore or offshore system engineering, we need to really make a good decision in choosing the partner.

Sandeep Kumar: I just want to build on that. In terms of capabilities, Ashwin, you brought out a point about industries and so on. Are we saying that you are seeing a trend which is uniform across industries or is there any industry specific things in offshore, you know, being able to do entire system development and step like that?

Ashwin Ballal: As you look at the panel itself today, each one is somehow interconnected, and all of them at the end have to be put together as a system. When I look at the system it's the end-to-end where we talk about the complex field of Semiconductor manufacturing 24/7. These wafers need to run through our tools, which mean that the wafer handling automation is required. That basically would enable us to understand what the domains are whether it's in optics, mechanical, or robotics, and what kind of algorithms is required. So there are domain gaps and a number of challenges that are coming our way, but we are getting better and better. As Zahid said, it's increasing the ownership and releasing command in control from the US. One of the core competences for KLA-Tencor is optics and the interaction of the Laser. We don't have that capability here and additionally we don't have these domestic markets. So that's an interesting concept where I think there's a role for both the captive and the partners to see and figure out what domains need to be worked on.

Zahid Hussain: I don't think it is an issue of, can India give us some engineering. It is an issue of timing: How long will it take? What's the level of investment? I think just from my experience through it, you should expect that your first couple of attempts will fail; at least, it won't be a spectacular success.

Michael Frendo: No, I don't think it has to fail. If you walk in to a place and they don't have the domain and the skill set and you throw a project at them and expect them to get the capabilities overnight, it's not going to happen. If the teams don't work together well, if you don't put the communication in place, don't build the critical mass and don't give ownership, and if everything has to happen across time zones, then you are going to fail. But you don't have to fail.

Sandeep Kumar: Vijay, from the aerospace domain, can you talk about your experience in system engineering out of India?

Audience: In system engineering, one has to be willing to invest, invest not only in terms of money but in time and engineering support, and if you don't, you will fail. Your support from engineering organization and from management is also extremely important. The other thing is that no matter how complex the system is if you cannot break it up into smaller chunk as a trial with the offshore center then you are unlikely to succeed. You have to be able to identify subsystems within it. For example very first project what we did was we had a small unit data memory module. We started as an end-to-end product development, developed the original concept, and passed it on to HCL for fabricating the electronics, schematics, etc. Well, we failed, because we were not able to provide the support that was needed to make it happen. Eventually we succeeded, but it took a while. So all I am saying is you as a company if you don't invest, you will not be successful.

Sandeep Kumar: What are the risks that you see Zahid if you were to move to doing, say, full next generation director in India? It doesn't matter whether it is captive or HCL. What do you see as the risks in doing that? What stops you from doing that and what would take you to go there?

Zahid Hussain: It's definitely possible because there is a whole set of domain knowledge that exists at one place. You have got to figure out how to transfer that to another place. So the issues are particulars of the domain and if you are willing to go through a learning ramp with that team on, let's say, critical time-to-market, make or break your business kind of product. So I think that's the piece that you then have to move to India or any offshore. If you don't have the stomach for long term you just shouldn't be in the game. And so to go and say take a director, let's say, complicated, really high performance mission critical networking system without having gone through a couple of cycles is you are betting your company and you'll probably lose your job.

Michael Frendo: We have reached the stage at Juniper. We are not moving things to India. We are creating things in India because we have got the critical mass of people here that are capable of doing that. I think that's little different. When I talked about the project we were working with HCL, we didn't move our project then either. It actually is a brand new project that we are creating. It's a new area where they need to gain domain and we need to gain domain as well. And it's kind of an interesting thing, because we were both learning together in that space, and we were building a system together.

Stephen Kim: I think all of us are converging to the same thing. Getting back into the history of the automobile industry, when TATA started automobile industry in India, there were many skeptics. But it took time and effort for them to get to where they are right now in India. Likewise, it took time and effort for Korean organizations like Hyundai to be where they want to be. I think there should be effort from the both sides to create partnership and make system engineering work.

Question and Answers

Sandeep Kumar: I just want to pick on Ravi. You have been in this business for long. Can you talk about any broad trends that you are seeing in this? Are you seeing any trend at all? Or is it the same as what you used to do earlier?

Audience: It is interesting that we are talking about how to do it if we should do it. Fifteen years ago at Nortel I risked my career in moving our lifeline product to India to a third party provider. But it took about five years when we could give the entire responsibility to the provider, not just one product, the whole product line. From then on they have grown. What I am witnessing now is with more and more of this experience coming in, in India. That people can actually accelerate this, and in our company at least on couple of product lines we can see them take it right from an MRD, completely own it to actually do customer support and with nobody in our company really spending any significant time helping them do that. So their domain knowledge is increasing, the experience set is expanding. All you have got to do is select a team with some experience and put people who care, who nurture, who train, and who make this happen. Don't just toss it over to them.

Sandeep Kumar: Anyone in the audience with any question on this.

Audience: Hearing the gentlemen talking about developing stuff, new stuff together with HCL and possibly other Indian companies, the question I would make would be how do you handle IP rights for new products that come from these kinds of relationships? Which are the models that you use to one side protect your core IP stuff and on the other side to give some room as I think you have to give it to HCL to develop its own IP stuff?

Michael Frendo: From our perspective we protect IP through contracts because that's how you protect IP and that's true whether you are working with the third party company or you happened to have people who work for you, because people leave your company all the time and take knowledge with them. Our relationship with HCL over the years has always been very strong around the IP. The IP belongs to the company that's paying for the development. It tended to belong to us, and in fact even got patents out of our relationship, because the people who are working at HCL were working on our products and the patents they generated in fact went through a company. But I think that comes down really as a contractual question more than anything because there is relatively strong patent protection here in India which by the way is not sure everywhere and we don't treat other countries necessarily the way we treat India because they have been very proactive in India at a government level in terms of creating IP protection. It's actually not same everywhere. But that's how we have done it.

Question: I am Mark Gilbert from Aircraft Braking Systems. We went into partnership with HCL. We identified various engineering tasks that could be outsourceable from the easiest to the most difficult. And it seems like the most difficult ones were the ones that interact with the customer. I would like you to share how you dealt with that particular issue when you have a whole product line being designed to the customer requirements offshore, their interaction with the customer.

Ashwin Ballal: KLA-Tencor does it through its global development center. We have actually application engineers that support the customers from India. And so that along with the development team gets the development team to a different level. So they can now start developing products. I have heard a lot about people saying we will wait for the MRD to come from the US and then we will start building products. The intent here is that the MRD will also be developed here in India, and then the products would come out. So that's an avenue we have taken. We have got a lot of applications engineers, a lot of customer information that's residing currently with us that we do share with the US. Here's an example where the reverse is happening where requirements are going from India into the US so that they develop the next generation products. So that model has worked for us very well.

Zahid Hussain: So we haven't quite reached that stage in what we were doing. The requirements are still coming from the US, because that's were the bulk of the customer interaction is. However, with our partnership with HCL we will have people from HCL onsite so that early on in the conception process, in the feature definition process, they are part of it, enabling them to communicate that back to the teams in India. But we haven't gotten to the point where requirements are really coming out of the India teams. That said we get to a point we say here the teams in HCL, for example, are very aware of the product, requirements about the product and in fact how the company is doing. Our partners are looking at the entire product and, in fact, ask business savvy questions. So it's not like 'here's your requirement back', but there's at least a full product understanding that wants to be developed in that. That's our part of the transferring of ownership. So the more ownership we can transfer, the more contacts they have about the overall product, the more they can go ahead and innovate in that way. Getting the customer interaction piece of it with an ODC is a very difficult thing. At least we found that so far.

Sandeep Kumar: I have a couple of other questions related to this. So we have heard a lot about the emergence of say Asia, more specifically India and China. Is that driving any of your context? What you want to do in terms of offshore-led system development?

Paul Mears: There's a huge advantage from a duty standpoint, because if organizations import a meter from the US or from other countries they pay a huge duty for that cost of that meter. So the ability to actually design and build a measurement device or a meter in India has a big advantage from that standpoint. So it could really help that part of the company.

Stephen Kim: We want to find embedded system integrators to work with us to create hardware using our chip so that they can market. With regards to system engineering, in Korea and Taiwan there is no domestic market. But they have done development of system side products, and they have exported them, whereas in India and China, there is a huge domestic market. So you can actually create your own plan and start selling within the country. That will give you edge for producing any systems or whatever you are trying to produce. My feeling is that in India and China the transformation and development is moving steadily. You cannot stop it. The key issue is how do you partner with Indian partners or how do you want to come in and put your own captive lines and produce for India market. So I think as a company CEO I need to really look at these types of things and to decide on where do we move our operations or what kind of partner we want to select.

Concluding notes

Ashwin Ballal: My perspective is systems engineering is possible from India. But my comment would be that we have got to get out of the instant gratification syndrome that we have and also be patient in terms of the capabilities as we develop and evolve. There's an opportunity for the partners to invest in the domains so that all of the things don't have to be done by our global development center. Then, of course, there is a management with the US, and there is an issue of how we manage that situation and go through these growing pains. And like Zahid said it's not a question of if but it's a question of when.

Zahid Hussain: I think that you have to be prepared to deal with some of the pain for the first couple of years, and if you are expecting that there are going to be short term cost gains and budget benefits, I think you are mistaken. I think that it's going to take a while to see a lot of the benefit of it. You have got to be in it for a few years and learn. I think the things that we have learnt or our takeaways are don't manage team from the US, try to give as much ownership early as you can, and be willing to take some risk. You are going to get a lot of resistance; especially, if you are moving an existing product line, you have to move pieces of it over. If there are new things that you are doing, I think those will work better, starting them up over there versus trying to transfer something over. And again if you are faint of heart on this, you shouldn't get into it.

Paul Mears: This has been very beneficial for me from the standpoint of things to watch out for and some of the pitfalls. I know that from some of the systems engineering we have done in the US, if you don't have adequate project management and infrastructure, it's just a failure. I suspect it would be the same thing for offshoring as well. So this has been very beneficial just from getting the different aspects and learnings from some of the people, because the last thing I want to do is make the same mistakes.

Michael Frendo: I think that in our case we are relatively lucky that we have got past lot of the pain stage that people are talking about. Our business has been here a long time. Having said that bigger faster cheaper, bigger faster cheaper, bigger faster cheaper, which is the business ring, certainly a lot of the draw in India 10 years ago was around cheaper. But that's changing. It's changing because the market is changing and India's becoming a market in its own right. It's about being bigger, faster, and cheaper. However you are going to get there, the easiest path, for a while and probably still is for some while, is to go offshore. The next cheaper is going to be something else and we just are going to have to continue to do that because the technology business is about Moore's law. It's about bringing price down and we are where we are. India has come a long way. We have all got a long way to go.

Stephen Kim: It is apparent that system engineering very much exists in India. I don't doubt that. One last comment on this conference, I really appreciate being here and learning, but instead of saying explore and transform, we should look at the transformation first and then how to explore the transformation situation next.