Functional specification – ERP implementation for a machinery manufacturer
This document specifies how the implementation partner will introduce an ERP system for the customer's two sites and 180 employees within a nine-month project. The scope covers materials management, production planning with bills of materials and routings, barcode-supported warehousing, purchasing, an accounting interface and migration from the legacy system.
1. Introduction
The basis for this Pflichtenheft is the customer's requirements specification for materials management, production planning, warehouse operations, purchasing, accounting integration and legacy data migration.
The objective is a controlled ERP go-live after nine months, with both sites operating on one consistent data and process basis.
- The implementation partner is responsible for configuration, extensions required for the agreed scope, interfaces, migration, testing, training support and go-live assistance.
- Customer process owners are responsible for decisions on processes, master data quality, acceptance and business ownership.
2. Solution overview and system architecture
A centrally hosted ERP instance with one company structure and two operational sites will be configured; cloud hosting is assumed until the hosting decision is confirmed (assumption). Site, warehouse, work centre and financial dimensions will be maintained in the ERP.
The solution will provide browser-based access for office users and mobile barcode access for warehouse users. Separate development, test and production environments will be used (assumption).
A relational ERP database will hold master data, transactions, planning data and audit information. An integration layer will exchange accounting data and selected legacy or peripheral data through APIs or secured file transfer, depending on the capabilities of the connected systems (assumption).
- Core modules: materials management, purchasing, inventory, production planning, production execution and warehouse management.
- Security model: role-based access with site and process restrictions.
- Barcode devices will use secured wireless connectivity and communicate with the ERP through the supported mobile application or web service (assumption).
3. Implementation of the functional requirements
The following implementation requirements map the stated customer scope to functional requirements F-01 to F-12. The numbering is a proposed mapping because the detailed customer requirement identifiers were not provided (assumption).
Organisation and two-site structure
Configure one ERP company with two sites, separate warehouses and site-specific stock, purchasing and production parameters. Users will receive access according to their site and role.
Acceptance: The customer creates a purchase order, stock transfer and production order for each site; each transaction shows the correct site and unauthorised users cannot process restricted site transactions.
Material master data
Implement material records for purchased parts, raw materials, semi-finished products and finished machines, including units of measure, procurement type, lead time, planning parameters, warehouse data and status.
Acceptance: A material is created and used in purchasing, stock and production. The system prevents saving when agreed mandatory fields are missing and uses the configured base unit consistently.
Bills of materials
Configure multi-level bills of materials with quantities, units, scrap factors, validity dates, alternatives and revision control. Approved revisions will be selectable by production planning.
Acceptance: A test machine with at least two BOM levels is exploded into the required components, and a future-dated revision is used only from its effective date.
Routings and work centres
Configure work centres, operation sequences, setup and run times, calendars and capacity data for the agreed production areas. Routing revisions will be controlled together with BOM revisions.
Acceptance: A production order receives the correct operation sequence and planned times from the selected routing; changing the routing revision changes new orders but not released orders.
Material requirements planning
Implement planning runs using demand, stock, reservations, open supply, lead times, lot sizes and safety stock. The planning run will generate purchase and production proposals that can be reviewed and converted.
Acceptance: For a defined demand scenario, the system creates the expected purchase and production proposals, shows their supply dates and does not duplicate existing open supply.
Production order execution
Configure production order creation, release, material issue, operation confirmation, completed quantity, scrap and order closure. Material consumption and finished-goods receipt will be posted against the production order.
Acceptance: A test production order can be released, components issued, operations confirmed and finished goods received; the resulting stock and order costs reconcile with the posted transactions.
Barcode warehouse processes
Implement barcode-supported goods receipt, put-away, warehouse transfer, production issue, finished-goods receipt, picking and stock count. Barcode formats and labels will be configured for the agreed materials and locations (assumption).
Acceptance: A warehouse user scans a test item and location for receipt, transfer and issue. The ERP records the correct item, quantity, warehouse and location without manual re-entry of the item number.
Purchasing
Configure supplier master data, purchase requisitions or planning proposals, purchase orders, approval rules, delivery dates, partial receipts and receipt corrections. Supplier prices and lead times will be maintained where available.
Acceptance: An approved purchase proposal creates a purchase order, a partial receipt updates open quantity and the remaining quantity stays visible for follow-up.
Inventory control and traceability
Implement stock by site, warehouse and location, reservations, available quantity, stock adjustments and cycle counts. Lot or serial number traceability will be implemented if confirmed for the relevant materials (assumption).
Acceptance: A stock count difference is posted with an authorised reason, the on-hand balance is updated and the transaction is included in the stock audit history.
Accounting interface
Provide an interface from the ERP to the customer's accounting system for agreed supplier invoices, customer or machine invoices if in scope, tax data, payment terms, cost centres, project dimensions and stock or production postings. The accounting system and technical format are to be confirmed (assumption).
Acceptance: A defined test batch is transferred, rejected records are reported with an error reason, accepted records are not duplicated and totals reconcile with the ERP source documents.
Legacy data migration
Migrate agreed material, supplier, BOM, routing, stock and open transaction data from the legacy system. Data will be extracted, mapped, cleansed, validated in a staging area and loaded through repeatable migration scripts.
Acceptance: Two migration rehearsals and the final migration complete with documented record counts and reconciled stock quantities; all rejected records are listed and resolved or formally accepted by the customer.
Roles, approvals and operational reporting
Configure role-based authorisations for purchasing, warehouse, planning, production and administration, including approval limits where required. Provide standard reports for stock, open purchase orders, production status, shortages and migration reconciliation (assumption).
Acceptance: Test users can perform only the transactions assigned to their roles, approval limits are enforced and each agreed report returns the defined test data.
4. Implementation of the non-functional requirements
The following quality requirements apply to the configured ERP, interfaces and operational procedures. Targets not stated by the customer are implementation assumptions and must be confirmed during design.
Performance
For normal operation, 95% of standard interactive transactions shall return within three seconds and barcode transactions within five seconds, excluding external network or accounting-system delays (assumption).
Acceptance: A performance test with the agreed concurrent user and scanner load meets the response-time targets for at least 95% of measured transactions.
Availability
The production system shall achieve 99.5% monthly availability during agreed operating hours, excluding planned maintenance announced at least two working days in advance (assumption).
Acceptance: Availability is measured from monitoring logs for the first three production months and reported against the agreed target.
Access security
Access shall use unique user accounts, role-based authorisation, password policy and multi-factor authentication where supported by the hosting platform (assumption). Privileged access shall be restricted and reviewed quarterly.
Acceptance: Security testing confirms that a user cannot access unauthorised functions or site data and that privileged access review evidence is available.
Backup and recovery
The production database shall be backed up at least daily with encrypted backups and a retention period of 30 days; target recovery point and recovery time are assumed as 24 hours and eight hours respectively.
Acceptance: A restore test recovers a defined backup into a non-production environment and the result is documented with measured recovery times.
Auditability
The ERP shall record user, timestamp, old value and new value for changes to material master data, BOMs, routings, approvals and stock adjustments where supported by the standard product.
Acceptance: A controlled change is made to each listed object and the audit record identifies the user, time and changed values.
Monitoring and operations
System health, interface queues, failed jobs, database capacity and backup status shall be monitored. Alerts shall be routed to the agreed support team and retained for at least 90 days (assumption).
Acceptance: A test failure of an interface and a backup job generates an alert, creates a support record and is visible in the operational dashboard.
Maintainability
Configuration, extensions, interfaces and migration scripts shall be documented in the project repository. Changes shall be transported from development through test to production using versioned release packages.
Acceptance: A sample configuration change is transported through all environments using the documented procedure and can be traced to an approved change record.
5. Interfaces and migration concept
The accounting interface will use the accounting system's supported API or secured CSV/XML exchange through SFTP. The interface will include mapping tables, validation, duplicate detection, retry handling and an error queue; the exact accounting product and format are not yet known (assumption).
Barcode handhelds and label printers will be connected through the warehouse network. The solution will support the agreed barcode symbology, item labels and location labels; device models, printers and symbology remain to be confirmed (assumption).
The legacy system will be extracted into a controlled staging area using database export or structured files. Migration objects will include material master data, suppliers, BOMs, routings, stock balances and open purchase and production transactions; opening accounting balances are included if confirmed (assumption).
Migration will follow four steps: source profiling and mapping, cleansing and mock load 1, reconciliation and mock load 2, then final extraction and cutover load. The final legacy system will be frozen for transactional changes during the agreed cutover window.
- Every interface will have a technical owner, data owner, schedule, monitoring rule and reconciliation report.
- Interface credentials will be stored in the platform's protected secret store or equivalent secure mechanism.
- No production migration load will be performed without an approved migration result and rollback decision.
6. Data protection and IT security
The implementation will apply data minimisation, purpose limitation, access restriction and defined retention periods in accordance with the UK GDPR or applicable EU GDPR requirements, depending on the customer's legal entities and processing locations (assumption).
Personal data expected in the ERP includes employee user accounts, supplier contacts, customer contacts and approval history. The data inventory, processing purposes, retention periods and lawful basis will be documented with the customer.
- Encryption in transit using TLS and encryption at rest will be required for the ERP, backups and interface transfers.
- Role profiles will follow least privilege; shared accounts are prohibited except for technically justified service accounts.
- Data processing agreements and subprocessor information will be reviewed for the hosting and ERP providers.
- Production data will not be copied to development or test without masking or documented approval.
- Security incidents, access changes and privileged actions will be logged and escalated according to the incident procedure.
- Technical and organisational measures will cover access control, change management, backup, disaster recovery, staff confidentiality, secure disposal and supplier management.
7. Test and acceptance concept
Testing will be risk-based and traceable from customer requirements through configuration, test cases, defects and acceptance evidence. The customer will nominate key users for process validation and formal acceptance.
The acceptance baseline is that all MUST requirements pass, no unresolved severity-one or severity-two defects remain, migration reconciliation is approved and operational documentation and training evidence are available.
- Unit and configuration tests: performed by the implementation team during configuration.
- Integration tests: cover accounting, barcode devices, printers, interface failures and duplicate prevention.
- Migration tests: include two mock migrations with record-count and value reconciliation.
- End-to-end tests: cover procure-to-stock, plan-to-produce, warehouse execution and accounting transfer.
- User acceptance testing: performed by customer key users using agreed business scenarios.
- Performance, security, backup restore and cutover rehearsal tests: completed before go-live.
- Defects will be classified as severity one to four, assigned an owner and tracked to closure or formal acceptance.
8. Project phases, roles and schedule
The project duration is nine months from approved project start to production go-live. The schedule assumes timely customer decisions, availability of key users and no major change in scope (assumption).
The customer will provide a project sponsor, project manager, process owners for materials, purchasing, production, warehouse and finance, key users from both sites and an IT contact. The implementation partner will provide a project manager, ERP consultants, technical integration lead, migration lead and test lead.
- Month 1: project initiation, scope confirmation, solution design, environment setup and requirements traceability.
- Months 2-3: process workshops, organisation design, master-data templates, fit-gap decisions and interface specifications.
- Months 3-5: ERP configuration, reports, roles, barcode process setup, interface development and initial migration preparation.
- Months 5-6: integration testing, migration rehearsal 1, process documentation and defect correction.
- Months 6-7: migration rehearsal 2, end-to-end testing, user acceptance testing and key-user training.
- Month 8: cutover rehearsal, final data cleansing, production readiness review and end-user training.
- Month 9: final migration, go-live, on-site or remote hypercare and transition to support.
9. Operations, support and maintenance
After go-live, the implementation partner will provide hypercare, incident handling, defect correction and knowledge transfer to the customer's support organisation. The detailed service hours, response targets and escalation contacts will be agreed before the production readiness review (assumption).
Support will use a ticket-based process with severity, business impact, affected site, reproduction steps, workaround and resolution recorded for each incident.
- Severity one: production stopped or critical data integrity risk; immediate escalation and continuous coordination until contained (assumption).
- Severity two: major process impairment with an available workaround; prioritised correction under the agreed support SLA (assumption).
- Severity three and four: standard defects, questions and change requests planned through the support backlog.
- Monthly service reporting will include availability, incidents by severity, interface failures, backup status, open defects and completed changes.
- ERP updates will be assessed in a test environment before production deployment; release notes and regression test results will be retained.
- A post-go-live review will be conducted after four to six weeks to agree outstanding actions and the transition from hypercare to normal support (assumption).
To clarify before use
These points and assumptions are open in the example — your initiative needs to settle them.
- Which ERP product, hosting model and deployment location are to be used, and which environments are required?
- What are the names, versions, data formats and ownership responsibilities of the legacy and accounting systems?
- What are the legal entities, chart of accounts, tax rules, currencies and financial dimensions for the two sites?
- Which detailed customer requirement identifiers and process variants must be mapped to F-01 to F-12?
- Which materials require lot or serial number traceability, and what are the required barcode symbologies, handheld devices and label printers?
- What are the expected data volumes, data quality rules, retention requirements and exact migration objects, including open orders and opening balances?
- What are the required purchasing and production approval limits, user roles, site restrictions and standard reports?
- What are the agreed operating hours, availability target, support hours, service levels, customer key-user availability and fixed go-live date?