Process

The process boundaries are setup in such a way that there is flexibilty as to where to enter and where to exit. The development project within WeDefine will follow these same steps and the input requirements and output deliveries will be clearly defined upfront. The decision to continue with the next process step can be determined as late as at time of review of the the previous step results.

Ideation

In the Ideation step, we will first, together with you, accurately define the problem we are trying to solve. The objective here is to find the root problem. When this is established, we will start the creative search for solutions. This is usually done via brainstorm sessions. Here no idea is initially too crazy. Going from these “too far out there” ideas to more realistic solutions is a good process to make us consider the scope of what the solution should contain. Think of things like: future connectivity, for instance expansion into cloud or ease to maintainability and evolution of the product and service. Smart choices here will make future development conduct more naturally and with much less effort and disruption of your orginisation.

Architecture

Architecture definition is vital step in the design process. To go from a high level block schematic into more and more detail of the technical implementation. Hereby guarding the scope of the desired solution. During this step we are already keeping the eventual feasibility of the design in mind. Feasibility in this context is very broad. It runs from availability of components and possible compatible replacements to choosing interfaces which make future developments a possibility. Setup a system in a modular fashion, so parts can be reused and maintainability increases. All while keeping an eye on cost and performance ofcourse. We aim to make every design as sustainable as possible, focussing on durability and a prolonged product life cycle.

Proof of concept

Proof of concept, this is where we will actually get our hands dirty. All the previously made plans and assumptions have to be proven in this step. To do so, mockups will be build to do measurements. If possible simulations will be run on processes. Application of materials and components are verified for performance and durability. At the end of this step, all possible doubt of feasibilty of the project should gone.

Prototype

A product is never a entity on its own. It usally communicates to the outside world. To other machinery or maybe to an end user, or both. To verify the proposed solution in all its functionality in reference to this outside world, a prototype must be build. how far the prototype is already similar to the production product, is agreed upon between you and us. It also depends on what is to be learned from putting the prototype in to action.

Product

If done correctly, the prototype and its derived feedback learnings implemented, will make up the “real” product. Here everything comes together. And we will take care of everything. This is about the details. Are implementations going to give problems in automated production? How will the product be programmed in production, and how tested? But also more elementry things as: tracking of revisions and allowing for updates. And again, sustainability plays a big role here for us. From material choices up to the ethical consiussness of suppliers. We will take care to comply with any certification needed.

Production

In the “product” step we already made many provisions to ensure product production to be fully covered. But this is seen from the product itself. Ofcourse there is also the production line with all its assembly steps. Think of steps like running an automated functional test on your product, or doing configuration on certain settings. Serial numbers can be assigned automatically and product revision control can be easily linked to this. Communication between the productionline and the product is key here. Set it up flexible such that the total system is easily extended and also used for future products.