Every software vendor explains how to use their software to save money. It is all about saving money. And it is true, the introduction of certain IT systems has made it possible to produce vast quantities of products faster and or better.
Here, a significant change has occurred over the last few years due to corresponding logistics systems, machine control systems, warehouse management systems, etc.
Here attention is paid to the concatenation of the systems with meticulous attention, interfaces are coordinated with each other, and the warehousing with all the components and the corresponding control over the version of the corresponding object is viewed and controlled with vigilance by the controllers.
In contrast to production, in which all artefacts are subject to very harsh control, development is often in the status of:
(Without invalidating any of those young genii, that are often better than companies)
I will list a few points which burn every moment more money in your company, as you can save with a super-optimized production chain hereinafter ever.
Everything that is designed incorrectly in the development - for whatever reason - costs extra money in production. Esp. if you develop series products, every little design mistake is a cost driver in the production, no matter whether that mistake it is about building the appropriate machine(more complex), or to carry out the corresponding incoming goods inspection(more often or harsher), or to regularly monitor the supplier.
Basically, the development process does not differ from the production process. There is one significant difference, you do not know in advance how the product will be finally looking, you are still in development.
But development also has to be handled like in production.
Is standard in every production plant
In development, incoming goods inspection is rather neglected.
Sales want to sell and promises the blue of the sky.
Customer demand is already accepted without knowing what is needed.
As part of the agile development, we forget often that one has to still satisfy the customer and when they go into a normative environment, that is where they manufacture products subject to which any Regulatory rules, I can only warmly warmly recommend to the input documents to their customers really.
with this instruction, a huge outcry would arise in the production, strangely not in the development.
When discussing with the customer during development, you just create a few functional models and then you think you can develop that as a serial product.
The relevant requirements of the (external or internal) customer, neither in a pre-serial development or in the pure prototypes and development phase are written down or even documented. Something is just being developed.
The basic researching is not a problem, the problem is that no one documents the relevant requirements as well as his thoughts somewhere.
Even the typical accounting protocols are often not even available.
This is still the holy grail of development.
I can already hear the opposition of the team leads and supervisor and as well the developer stating that they are not the people who document.
While this is generally true that they are developers, however in each, in each, I repeat, in each and every book, in every lecture, in any standard engineering-process calls for documentation.
Nowhere is stated that you need to write a good novel, but you have to document.
This is also true in the agile world. There, too, there are basically "Epics "user stories and any test cases with which one checks his request. In this case, the so-called "definition of done " should be used.
In each production process, you would check whether the components that you receive have even survived the test of the latest station. Nobody would come up with the idea to machine a plastic component with a woodworking tool, or a steel component with a plastic tool, and would return the component and say "does not fit".
This process of incoming goods inspection in development is called:
In itself nothing is difficult, it is just some work. If you do not sit down and do not consider if you have a requirement that is achievable at all, which is technically well defined, etc., and which one can also check (verification criteria), then you will never get a reasonable product.
In every production process you do that, and it's often easier to judge here, and in development you say:
"I do not need a review, it works fine" - only to find out that your successor colleagues have trouble like mad.
In any case, huge amounts of money are burnt because of not following the basic principles of any engineering approach.
While the above review is a process performed by human beings, there is an obstacle to burning money and that is even more serious.
Almost every project manager I know fights so that he - mostly via a so-called "project management office" - brings together the data of development and keeps consistent. (Which de facto NEVER works out)
Each development discipline has its own tools, whether it's requirements management, project management, testing, etc.
Data consistency and traceability of artefacts in development is not given and leads to chaos and extra stress.
Here, the communication between the individual departments, regardless of any personal interference, is significantly limited.
Conway's law in 1967 stated that product quality is compromised to the extent that communication in the business does not work.
If you have so-called tool breaks, then you always have a communication break there.
If you can not manage to be consistent across the entire development, the bomb explodes in development and later in the production.
You get some parts delivered and you do not know what it is and where it belongs, and you have to assemble these data regularly by hand. I think every production planner each controller would here end up with his hand up over the head and quickly remedy that situation.
In development, this inconsistency seems to be an accepted structure.
There are tools such as Kovair that allow you to synchronize their data in real time across your development toolchain.
If anyone says that synchronization would not have to be across the various tools, then you know that this person wants to make sure that you spend significantly more money on the development, produce worse products, and whatever.
If you manage to optimize your data from the customer's initial quoting phase, through the development process, to production and getting the data consistent, no matter what tools are used, that's going to be a daunting task for you Worrying to really integrate the existing Toollandschaft among themselves in the process, as well as to adapt the corresponding process. But once you've done that once the data is consistent, it will be significantly easier to make something better in less time with more fun.