Friday, February 10, 2006
What can Enterprise Architects learn from Ford and GM?
Most folks get it twisted when it comes to learning from Ford and GM. Many are of the belief the problem originated from misaligned currencies, government susidies, energy prices or other things in the big picture don't really matter. Others have recently jumped on the whole retirement program in that GM and Ford have too many North American retirees for current workers to support because both companies have lost half of their North American market share over the past 25 years and have hired hardly any new workers in a quarter century which many believe is the cause. Reality states this is more of the effect. The root cause of the crisis lies in a clash of two business architectures, and the better architecture is winning...
The lean product development process as used at Toyota, permits a company to produce vehicles with fewer hours of engineering and fewer months of development time with fewer defects while investing less capital and making customers happier. The key tools are the chief engineer concept, concurrent set-based design (which is simultaneous as well). Lean approaches encourage high speed prototyping with trade off curves so that re-invention is avoided. It’s not an accident that Toyota was able to hear the voice of the customer first with regard to hybrids or that the Prius has more new technology than any vehicle in a generation and not only was developed very quickly but also has been rated th most reliable vehicle sold in the U.S. These were predictable outcomes of the lean development process.
Enterprises need to align with lean development processes for software development as well. They should seriously consider having each and every employee read aloud before starting their day, the agile manifesto in order to have the right mental model. Likewise, they should stop rationalizing keeping around legacy systems as rationalization is a trap.
Agile approaches involves managers at every level posing the key problems that need to be solved and asking the teams they lead to develop and implement the answers. This practice of asking the correct questions rather than providing the correct answers (which high-level bosses can never know in any case) is perhaps the starkest contrast between lean thinking and orthodox mass production / traditional management practices.
If one were to study Toyota, the agile practices were not just within IT but were implemented pervasively in all areas of the ecosystem. If you have agile software development, but not agile procurement, agile infrastructure, agile human resources and so on, you are setting yourself up for mediocrity.
Another practice that Toyota does really well unlike most EAs is that they equally understand not only the importance of brand, they have actually taken deliberate steps to reduce / simplify market offerings. They don't tell their customers they do everything and don't customize every product to meet every demographic. Branding adds costs. Consider the additional expense of having Buick, Pontiac, Saab, Saturn, GMC when they are all pretty much the same thing...
Stop wasting time branding internal processes that are clones of things done elsewhere for cheaper. No, don't get it twisted, I am not rationalizing outsourcing but rather the marketing efforts many enterprise architects do in order to sell their IT efforts to the business. Customizing the IT message for each business customer can feel like it will lead to success in the short term but this too is a trap. This would be simply repeating the mistakes of Ford and GM...
| | View blog reactionsThe lean product development process as used at Toyota, permits a company to produce vehicles with fewer hours of engineering and fewer months of development time with fewer defects while investing less capital and making customers happier. The key tools are the chief engineer concept, concurrent set-based design (which is simultaneous as well). Lean approaches encourage high speed prototyping with trade off curves so that re-invention is avoided. It’s not an accident that Toyota was able to hear the voice of the customer first with regard to hybrids or that the Prius has more new technology than any vehicle in a generation and not only was developed very quickly but also has been rated th most reliable vehicle sold in the U.S. These were predictable outcomes of the lean development process.
Enterprises need to align with lean development processes for software development as well. They should seriously consider having each and every employee read aloud before starting their day, the agile manifesto in order to have the right mental model. Likewise, they should stop rationalizing keeping around legacy systems as rationalization is a trap.
Agile approaches involves managers at every level posing the key problems that need to be solved and asking the teams they lead to develop and implement the answers. This practice of asking the correct questions rather than providing the correct answers (which high-level bosses can never know in any case) is perhaps the starkest contrast between lean thinking and orthodox mass production / traditional management practices.
If one were to study Toyota, the agile practices were not just within IT but were implemented pervasively in all areas of the ecosystem. If you have agile software development, but not agile procurement, agile infrastructure, agile human resources and so on, you are setting yourself up for mediocrity.
Another practice that Toyota does really well unlike most EAs is that they equally understand not only the importance of brand, they have actually taken deliberate steps to reduce / simplify market offerings. They don't tell their customers they do everything and don't customize every product to meet every demographic. Branding adds costs. Consider the additional expense of having Buick, Pontiac, Saab, Saturn, GMC when they are all pretty much the same thing...
Stop wasting time branding internal processes that are clones of things done elsewhere for cheaper. No, don't get it twisted, I am not rationalizing outsourcing but rather the marketing efforts many enterprise architects do in order to sell their IT efforts to the business. Customizing the IT message for each business customer can feel like it will lead to success in the short term but this too is a trap. This would be simply repeating the mistakes of Ford and GM...
