Achieving a decent level of CMMi certification is difficult without improving. It's even more difficult due to the great variety of measures u can choose, all with different goals as I explained a while ago talking about Productivity. Further more, the impact of an arbitrary list of measures probably doesn't add up significantly enough. So now what? Well, choose!
Just like a bespoke application is best maintained in releases, improving ur delivery lines should be done with the same approach. In fact, it can be seen as an application like all the others in all aspects after all. And just like maintaining ur bespoke software, a set of coherent measures aimed at one specific goal delivered on time would make most impact. So limiting a release in a time box with a specific theme is a good solution. Next release a different thema and so on. May be important ones like "saving costs" will come back a little more often than the other themes .
To start with a definition: "Industrialization is implementing measures to produce faster, cheaper, easier or better (I'll skip the definition of "better" here ) products or services". Of course the goals are equivalent: a better time-to-market, more margin and/or volume, higher quality. There is nothing against it and even more, ignoring the chances to industrialize, will cause a loss in marketspace. Protectionism is of no use in a free market unless one can keep a monopoly a bit longer for a better position in the next round but that will cost a lot of money (or you have to be country with some laws to do so ).
Even Rembrandt was industrializing with having his students filling in colors or irrelevant reproducable details of his paintings. His paintings didn't become less valuable and he was able to produce more of them.
The old question about should the solution be bought or hand crafted, slowly became a little more complex. It is good practice to re-use components you already have. Today in an Open Source world it's a clever thing to look on the net for a component somebody else already made. And may be there are some parts in the application that can be generated. A good Software Architect designs the application answering the question: "Can I buy, re-use, free-use or generate or should I make this component from scratch?". It's not that easy because every choice has it's consequences. For instance, for every component u've made urself, u should at least have a clear idea of it's quality. A piece of software from the net however, might be tempting to use but can cause long testing an debugging hours.
The last decade or so while trying to get projects under control, managers tend to focus onto the methological aspects. Meanwhile technical specialist took the freedom to adopt new fancy tools. Nobody seemed to have in mind that it's often not a matter of what has to be done and why, when and by whom but more HOW. So I think somewhere in the process, we've lost the connection between the method and the tool. Even in the "definition"of a Software factory (People, Process, Technology) this seems to be a bit hidden away in all 3 aspects.
An average projectmanager often assumes to have everything under control assigning tasks "by-the book". Desigers and engineers get going with their fancy tools happy as childs. At least a little while nobody seems to have noticed that the quality of the work is constantly at stake. Why? Because a software architect "forgot" how to design a database, a programmer how to structure his code, a designer how to specify a use case in a way it's understanable, consistent, compleet and transferable.
Techniques are the real building blocks in every profession. Imagine the construction of a bridge with a team of welders not really knowing what they are doing. You don't want your mission critical application built like that, do you?
In the world of IT there seems to be a strong aversion against everything that brings an image of industrialization of software engineering. Our profession loves to surround itself with the aura of almost mystic creativity. And indeed, one could argue that building software proportionally takes a lot more designing than may be building a bridge. Funny enough, almost every professional experienced the shortcomings of not having standards, so everybody favors some kind of method, standard tools and techniques. But, the minute the discussion goed in the direction of: "OK, let's set up a software factory", people duck behind their "special project" coz that one is not suitable for standardized stuff.
They seem to miss that a software factory (or assembly line, delivery line, projectcenter etc.) is still all about people. As a matter of fact, whathever you do about the process or technology part, focus on improving people's capabilities will improve productivity more, at least in the first few stages. Additionally, every change in process or technology has it's people component like education or coaching.
That finally brings me to the question: "What is a Software Factory". Well to me it's a simple: "A coherent and managed set of accelerators each consisting of a people, process, technology ánd governance component". And preferably "service-oriented" so that u can take an accelerator out easily and replace it by another. In practice it's a bit more complicatied than that but at least u should give it a try. Examples r easy to find: 24*7 available infrastructure, standardized development process, coaching-on-the-job, a test-tool. offshore, etc. etc.. In short anything that improves productivity from any angle.
Achieving a decent level of CMMi certification is difficult without improving. It's even more difficult due to the great variety of measures u can choose, all with different goals as I explained a while ago talking about 
.
) products or services". Of course the goals are equivalent: a better time-to-market, more margin and/or volume, higher quality. There is nothing against it and even more, ignoring the chances to industrialize, will cause a loss in marketspace. Protectionism is of no use in a free market unless one can keep a monopoly a bit longer for a better position in the next round but that will cost a lot of money (or you have to be country with some laws to do so 
). 
The old question about should the solution be bought or hand crafted, slowly became a little more complex. It is good practice to re-use components you already have. Today in an Open Source world it's a clever thing to look on the net for a component somebody else already made. And may be there are some parts in the application that can be generated. A good Software Architect designs the application answering the question: "Can I buy, re-use, free-use or generate or should I make this component from scratch?". It's not that easy because every choice has it's consequences. For instance, for every component u've made urself, u should at least have a clear idea of it's quality. A piece of software from the net however, might be tempting to use but can cause long testing an debugging hours. 
The last decade or so while trying to get projects under control, managers tend to focus onto the methological aspects. Meanwhile technical specialist took the freedom to adopt new fancy tools. Nobody seemed to have in mind that it's often not a matter of what has to be done and why, when and by whom but more HOW. So I think somewhere in the process, we've lost the connection between the method and the tool. Even in the "definition"of a 
In the world of IT there seems to be a strong aversion against everything that brings an image of 
