ERP Business Analyst in Italy

Why Italian ERP projects need written requirements

Italian manufacturers and distributors often run with remarkable efficiency on informal knowledge. The person who has managed administration for decades knows which customers pay by bank receipt and which by transfer, which agent is owed what, and which supplier invoices need a manual check. That knowledge works until the company changes systems, adds a new generation of management or is acquired by a foreign group.

At that moment the company needs a written description of its processes, and the software house will rarely produce one on the client's behalf. Most proposals start from the vendor's standard model and adjust it during configuration. The risk is that local practice is either forced into the standard or added as custom work nobody budgeted for.

As a business analyst I write the description first. I interview the owners, sales, production, purchasing and administration teams, collect real documents and turn what I learn into numbered requirements with priorities and test criteria. The exercise often helps the company agree internally on how it wants to work, which is valuable before any platform is chosen. The method is set out on my requirements gathering page, while the ERP consultant in Italy page covers selection and implementation.

SdI flows, preservation and the commercialista as requirements

Electronic invoicing through the Sistema di Interscambio is part of daily life for Italian businesses, so it has to be described precisely rather than listed as a single module. I write separate requirements for each document type the company issues, such as invoices, credit notes and the self-billing documents used for certain reverse-charge purchases, and for how each is addressed to the recipient, whether by recipient code or certified email.

The return path matters as much. The specification states how delivery receipts, rejections and other notifications appear to users, who acts on them and how a rejected invoice is corrected and resent. For incoming invoices it describes how files are imported, matched to purchase orders or receipts, and posted with the right tax treatment. Digital preservation of invoices and related records is written as its own requirement, including who provides the service and how documents can be retrieved.

The commercialista is a key stakeholder throughout. I ask what they need from the system, such as VAT registers, periodic data or specific exports, and record it as requirements. They confirm tax treatments and current rules; I do not give tax advice. Platform-specific answers are covered on the Odoo in Italy and Zoho in Italy pages.

Collections, export declarations, agents and subcontracting

Some Italian processes look familiar elsewhere but carry local detail that a generic requirement misses. Collections are a good example. Many companies collect from customers through Ri.Ba. bank receipts as well as SEPA direct debits and transfers, so the requirements cover how payment instructions are generated from invoices, presented to the bank, matched when the bank reports back and handled when a receipt comes back unpaid.

Export-led firms bring further needs. Where customers or the company itself use declarations of intent to purchase without VAT under the conditions your advisor confirms, the system has to record them, apply them to the right invoices and track usage. EU trade needs the data for intra-community reporting. I write these needs down and leave the rules themselves to the commercialista.

Sales networks and production complete the picture. For agents I document commission bases, settlement timing, statements and the records your advisors want kept. For manufacturers who send material to outside workshops for machining, finishing or assembly, I describe how goods leave and return, how stock at the subcontractor is tracked and how the work is costed. These flows feed the process maps and a fit-gap analysis that shows which platforms handle them well.

Owners, employee representatives and other stakeholders

Requirement work in an Italian company is as much about people as about processes. In family businesses the owners usually want to approve priorities personally, and sometimes two generations hold different views on how far the new system should change established ways of working. I make those differences visible in the document and help the family reach decisions that are recorded, rather than left to the implementer to guess.

Staff topics need attention too. Systems that record time on production orders, track user activity or could be used to monitor work may require discussion with employee representatives or specific agreements before they are switched on. Whether and how that applies is a question for your labor consultant and legal advisor. I support them by preparing a clear list of roles, the data each role sees and what the system logs.

Data protection under GDPR runs through the whole specification: what personal information sits in the ERP and CRM, which roles can open it and how long it is retained. Payroll typically stays with the labor consultant or a payroll provider, so I define the boundary and the postings that come back into the ERP. Each stakeholder's input is noted against the requirements it affects, which makes later changes easier to trace. The business analysis page describes the wider approach.

English documentation reviewed in Italian by your team

The engagement runs in English, and every deliverable is written in English: the requirements document, the process maps, the fit-gap matrix and the acceptance scenarios. For Italian subsidiaries of international groups and for export managers who deal with foreign customers every day, that is usually comfortable. For the people who will use the system on the shop floor or in administration, the Italian side needs a careful check.

I include a glossary that pairs English terms with the Italian expressions your staff use for document types, statuses, payment methods and production steps. An Italian-speaking key user reviews it, together with any Italian-language artifact such as invoice layouts, delivery note templates and field labels. If the software house needs an Italian version of the specification, your team or the implementer arranges the translation, and the English document stays the reference for scoring and acceptance.

Online workshops are booked in the first half of the Italian working day, when my own day in India is well underway, and each one ends with written notes for review. Chapters are signed off by their owners, and later changes go through a short request log. You can read more about document structure on my BRD consulting page, and the Italy hub summarizes how I support Italian companies.