Who this is for: Businesses digitising a manufacturing process, connecting existing systems or commissioning industrial software in Italy.
An industrial software project may include licences, development, machine connections, data migration and ongoing support. Describing everything as one item makes both the operational outcome and a scheme-specific expense review harder to understand.
Start with an operational question: which decision or activity should the software make possible? That defines functions, system boundaries and tests. The funding discussion can then examine a clear investment, rather than a general promise to digitise the business.
Describe one complete use case
Choose a concrete situation: tracing a batch, identifying a stoppage, receiving an order or comparing a production reading. Identify who uses the information, where it comes from and what action it enables. A dashboard alone is insufficient if nobody can explain how its indicators are generated and used.
For batch traceability, for example, identify the origin of the batch code, the processing event, its link to a machine and how the history will be retrieved. This is an illustrative scoping example, not a claimed customer result. Its purpose is to make the requested function testable and understandable.
Separate the project's financial components
Ask the supplier to distinguish one-off purchases, development undertaken for the project and charges continuing over time. A subscription may bundle several services. The description should support an assessment rather than assuming that every component receives the same treatment simply because it appears on one invoice.
Scroll horizontally to see every column.
| Component | Question to clarify | Deliverable to connect |
|---|---|---|
| Licence | Rights, duration and users | Functions made available |
| Development | Scope and handover | Specific functions delivered |
| Integration | Systems and interfaces involved | A verifiable data exchange |
| Migration | Source data and checks | Transferred and reconciled information |
| Recurring service | Price, term and service commitments | Continuity after launch |
Distinguish digitisation from research activity
Software appears within the scope of some instruments, including Nuova Sabatini, subject to specific conditions. That does not make every licence, development task or subscription eligible. The item must be reviewed alongside the business, intended use and rules of the selected programme.
Custom software and research are not interchangeable terms either. MIMIT's R&D credit page points to dedicated technical definitions and criteria. Describe any experimental uncertainty separately from ordinary configuration or integration instead of assigning one convenient classification to the whole project.
References: MIMIT — Beni strumentali, Nuova Sabatini · MIMIT — Credito d’imposta ricerca, sviluppo, innovazione e design
Clarify access, data and responsibility before accepting a quote
Identify the existing systems involved and who can authorise access to their information. Review available interfaces, data quality and connection conditions with technical owners. An apparently simple function may require additional work if the existing equipment or software does not expose the information assumed by the proposal.
Discuss ownership or usage rights in deliverables, data export, backups and update management within the agreed scope. These are points to resolve with suppliers. Do not assume they are included merely because the proposal describes a platform or complete solution. Record who owns each unresolved question before finalising the budget.
Connect acceptance tests to the intended result
Prepare acceptance scenarios that operational users can understand. For each, define starting data, an action, an expected result and how the outcome will be recorded. Include missing or incorrect information explicitly. Verification should not rely solely on a presentation in ideal conditions using a carefully prepared dataset.
Retain versions, acceptance records and connections to invoiced activities according to the selected scheme's requirements. Studio Dinamico helps coordinate technical definition with the investment assessment, making costs and dependencies visible before project documentation becomes an exercise in reconstructing what was originally intended.
Before assessing software support
- Describe at least one use case with a user, information source and action.
- Separate licences, development, integration and recurring expenses.
- Identify existing systems, interfaces and owners of access permissions.
- Clarify usage rights, export and support after launch.
- Define acceptance tests connected to the functions being purchased.
Common questions
Does bespoke software automatically count as R&D?
No. Customisation alone does not establish R&D status. Describe the work actually performed and assess it against the scheme's criteria, separating any experimental aspects from routine activity.
Are software subscriptions always excluded from funding?
There is no universal answer. The service included, period and selected measure need review. Keep recurring charges separate and understandable in the budget without assuming either inclusion or exclusion.
Sources and further reading
Apply this to your project.
Which information or capability is missing from your process? Start there to define the software, integration and investment questions worth reviewing.
Discuss your industrial software