There is a comparatively simple way for a supplier to reduce the largest cost block in development: vendor lock-in. Lock-in means that the costs saved in the first phase are recouped over the product's lifetime. Lock-in thus leads to hidden costs. Depending on the supplier, this can be in the form of an additional margin added to the product during production and/or by selling changes at inflated prices during the product's lifetime.
In product development, the prerequisite for becoming a "victim" of such a lock-in is that in the initial development contract, you do not secure all rights to all generated intellectual property. Your service provider is then the only one who can produce and customize the device. In addition, your service provider represents a commercial cluster risk for you, as it can be bought out or disappear altogether.
With us, all intellectual property always goes to the customer. You should come back because we have done a good job, not because you have no choice. And: "no lock-in" also leads to transparent cost of the product, you decide yourself if and how to pass on the development costs (NRE: Non-Recurring Engineering costs) to the product.
For developments of complete devices or software (classical or agile) we can give a 5-year warranty after the pilot series on all errors of the specified behavior and on all end-of-life (obsolescence) cases of the components used. We adjust all our work results within typically one month from your notification.
The fine print: The warranty covers defect resolution, i.e. you get a new technical data package (TDP) for your production plus the updated software and hardware data and all related documentation. In order for us to have control over the quality, the warranty expires if you have changed something yourself or if you have chosen a lower quality than the one we proposed during development. In order for us to collect the required quality data for the series, we need a say on the validation and field test phase and access to results thereof.
You have no processes for your functional security projects?
If we develop critical systems for you (functional security and/ or cybersecurity), on request, we can transfer our processes used in the project to you, provided the project has a certain size. You will then have access to our Process Wiki including all templates for the documents and tools used plus all checklists.
You can use these documents as a basis for your own process development ("insourcing" of processes). Normally, you will have to adapt the process assets, because they have to interface with your existing ways of working. Nevertheless, our processes and templates for all artifacts will save you a lot of time and effort when defining your own process landscape for critical projects. Especially since we have carried out a project with you based on these processes, so you have an example of how to use them.
We charge the same rates for project managers and engineers, for all experience levels, and for all functions, so we can put the work into your project and not into complicated billing schemes. We do this because:
The size of the order determines the rate, as large projects result in tighter planning and therefore higher overall capacity usage.
More information about the cost of development projects can be found here.
Quality is a basic principle of our actions, and we invest a lot into it. Particularly because we know that knowledge, i.e. our core competencies, is not just in our heads, but are stored in platforms, processes, checklists and templates.
Because technical competence is an organizational competence, not a personal competence. Organizational knowledge distinguishes us as an engineering company from recruiters who can only offer employee knowledge or experience. With us, the knowledge of the employees is exponentiated with the organizational knowledge, i.e. you get the organizational knowledge, our platform and process assets plus the experience of our employees.
Because a long-term, sustainable partnership with you is important to us, we do not work for your competitors. Unless you want us to, of course. As we are a medium-sized engineering company, it is not necessary for us to have several competitors as clients, another advantage of our size.
We do not believe that source code and schematics are sufficient documentation for product maintenance. We believe in the importance of describing the product architecture and the chosen technical architecture separately, so that others can maintain the product. After all, if this information is only in people's heads, will it still be present in five years? Do you still know why you decided what five years ago?
A second important point seems to us to be that this documentation and, above all, the different versions for production fit together. This means that we operate a strict configuration management for all sources, documents, schemas, but also binaries and Gerber data etc.
For hardware development in particular, we are advocates of frontloading. Frontloading means using both the specialists (i.e. people) and the processes (i.e. rules, reviews...) early in the project, when many design variants can be weighed against each other with relatively little effort. Then, already the first prototype gets developed as series hardware, i.e. with all mechanical constraints, all measures for EMC (Electro-Magnetic Compatibility) and manufacturability. Of course, we do not push this to excess, for reasons of efficiency it does not make sense to really make all details "ready for series production". Therefore, there are usually a few changes for the second prototype and small adjustments for the pilot series.
We do this to prevent errors from the outset (the later an error is discovered, the more expensive it is to fix) on the one hand, and to minimize changes later in the development process on the other.
One effect of frontloading is that a lot of development, calculation and review effort goes into this first prototype. This can lead to nervousness of customers who are used to an approach with "rougher" prototypes, because from the customer's point of view "too much" effort and time is invested in the first prototype: "How do you want to reach the goals, if already the first round takes so long?".
In our experience, the advantages of frontloading outweigh the disadvantages, since already the very first prototype provides feedback on EMC, mechanical integration, industrial design, usability and manufacturability (design for manufacturing/design for test), and thus production readiness can be achieved with one or two additional iterations.
Also software can benefit from frontloading. As the cost of changes and defects increases less over the development cycle, the effect is smaller, which is exploited in "agile" development. Note that the effect of increasing bug fixing costs is only smaller, not zero!
We are asked a lot about which industries we work for, where we specialize. We don't think it would be an advantage to limit ourselves to one or a few industries. Maybe we could get into the projects a little more efficiently?
What would certainly be lost is the transfer of ideas between industries, cross industry innovation. Some solution, which is commonplace in one industry, is a real advance in another. For example, in household appliance software we have implemented control architectures that are standard elsewhere, but have resulted in a massive leap in performance here.
We do not do anything that others can do better, in these cases we work together with other service providers or your specialists. This is because we believe that the most value can be created when specialists on projects join together in temporary networks to solve a specific problem.
This includes the principle that we are ready to work with the partners who have the best fit exactly for your project, not those with whom "we have always worked".
It is important for us to develop your products so, that your end customers like them and they can be produced efficiently. Not so that we have a particularly easy development phase. Therefore we are happy to take over your complete development up to the production launch, up to the zero series. If you wish, we can even take care of production and technical product maintenance according to the zero-cost-of-ownership model.
For you, this has the additional advantage that your own developers are not burdened with the admittedly sometimes not so funny industrialization and production launch phases. Phases that are left to internal developers with some other development strategies.
Projects? Ideas? Questions? Let's do a free initial workshop!
No Comments