An automotive OEM acting simultaneously as customer and Tier2 is becoming increasingly more common … [+]
getty
Wait, what?? Customer as supplier doesn’t make any sense.
And yet it does.
Automotive manufacturers are increasingly moving towards projects that involve co-development: a Tier 1 supplier is sourced as the system developer, but the OEM provides code and/or components developed in-house as part of that overall system. And there are a variety of deep-seeded business reasons why this oxymoronic duality will continue into the future: 1) cybersecurity updates must be coordinated centrally , 2) user interface changes should be common across suppliers and need not be double-developed, 3) valuable intellectual property may be protected, and 4) reflashing of software after vehicles are sold and its associated protocols may be managed easier.
However, for all its pros, such business and development arrangements rarely work out smoothly. Frequently, such automotive launches feel like Rosanne Barr or Borat singing the national anthem: the statement of work is technically met, but the experience isn’t desirable for anyone. Yet, there are a few success stories amongst the chaff, and they usually involve eyes-wide-open-special-attention to these three elements: team of teams coordination, timely system requirements and effective supplier monitoring.
The only way to be coordinated is to actively manage the project with a shared understanding of the … [+]
getty
Team of Teams Coordination
Imagine a relay race where four runners have a time they must meet. The entire success hinges upon each runner monitoring and adjusting his/her pace, handing off the baton per the agreements, and transparency on the collective achievement of the goal. That’s the very essence of various flavors of “Team of Teams” coordination (e.g., Scaled Agile Framework®) which Sergej Weber of predicted for Forbes will be “rolled-out [more] between companies in 2021.” Realizing such a prognostication would be a good thing since these co-development projects go sour with the traditional opaqueness between customer and supplier. Deadlines are missed in a surprise fashion. Content of deliveries doesn’t match expectations. Dependencies become rushed, flawed or delayed due to non-standard firefighting.
Well-written, timely System Requirements are typically an issue for any automotive project, but the … [+]
getty
Timely System Requirements
Saying “thou must explain what it’s supposed to do” sounds like motherhood and apple pie: such things are obvious and other alternatives are heresy. However, many co-development projects – which are inevitably the ones where quality goes south – involve the customer’s engineers stating, “You need not worry about what the system shall do. We will provide the functional software that you as the supplier shall integrate.” This strategy, though, has significant flaws. “The supplier is often held accountable for system qualification,” states Peter Abowd, CEO of Kugler Maag Cie North America. “They can only do this efficiently, and with the highest quality, by having system requirements at a suitable time frame, using those to create a logical architecture and qualifying that the product’s performance against the known, intended functions.”
Too often the OEM will hear no evil from their end until agreeing to undergo the engineering rigor … [+]
getty
Effective Supplier Monitoring
Speaking of heresy, referring to any part of the customer as a Tier 2 supplier is typically a non-starter. But, in reality, in the midst of asking to contribute to the underlying software that’s almost what the customer is requesting, and they are fully aware that a dysfunctional supply base can destroy a project. So not only do such projects need the project management mentioned above to create transparency of progress to the deadlines, but all of the supplier monitoring interfaces and rigor need to be established for a healthy outcome. How will change management occur? How will problem resolution be handled along with escalations? What is the quality assurance plan? Where will the latest code, specifications, etc. be managed and available? When these ways of working are not defined explicitly upfront, mayhem ensues.
And the craziest part: if the customer doesn’t permit the supplier to do effective monitoring of itself, the supplier gets dinged for doing a bad job of supplier monitoring, the project becomes discombobulated and everyone ends up unhappy.
So enter into these agreements with eyes wide open. And keep them open.
