We are a major museum in northern Germany and are seeking a project-specific, database-driven software solution that combines inventory management and rental functions (including rental services) for a specific project. The project aims to develop a digital platform for the inventory management and rental of exhibition materials - such as furniture, technical equipment, and other resources. This gives rise to the two work packages: “Inventory Management” and “Rental.”
Within the scope of the “Inventory” work package, the platform is intended to enable both the systematic recording and the organization of the institution’s own holdings. The goal is a uniformly structured, searchable database that provides a precise overview of available materials and can be used for the management, categorization, and maintenance of all available equipment items within an institution. This database forms the basis for the platform’s rental function.
The “Rental” work package encompasses the provision of functions for the straightforward handling of rental transactions between the participating institutions. This includes access to the institutions’ inventories and the digital mapping of the entire process, from the initial inquiry through reservation and contract processing to billing. The focus here is always on renting, not on selling exhibition materials. The goal of this function is to simplify and standardize the exchange and shared use of resources. It is important to note, however, that not everything that has been inventoried is available for rental.
In the pilot phase, this project is aimed at museums, exhibition venues, and memorial sites in the region. In the long term, we plan to expand the system and the target audience to include additional private and public cultural and media organizations in the broader region. The platform is to be designed to be accessible, intuitive, and user-friendly, so that access for interested parties and third parties is as low-threshold and attractive as possible.
The user perspective refers to external inventory that is rented via the database and used for a certain period of time. The administrativeperspective refers to one’s own inventory, which is recorded, managed, and rented to other institutions.
The software sought must meet the following requirements:
- General
- SaaS – External hosting must be possible
- Access via web client
- Mobile application – Use on mobile devices
- Browser – Optional feature – should be usable via all standard browsers
- Language settings – Optional feature – German as the default language initially; allow for language changes later if needed
- Interfaces, APIs – Required feature – Integration with existing external systems and databases should be possible
- Communication channels – Required feature – Requests beyond the system, including via workflows
- Inventory Management
The Inventory Management work package consists of the digital recording, management, and querying of the inventory of the facilities. Digital recording involves digitally cataloging an item via a smartphone and tagging it using a QR code or barcode. Management includes processes such as purchases and disposals, as well as, where applicable, maintenance cycles, repairs, and inspections. Retrieval refers to the display of the collected inventory in a clear overview, including specific filter and search options. In the pilot phase, a maximum of up to 10,000 inventory entries is anticipated.
- Administrative Perspective
- Category- and model-dependent specifications (Specs)
- Transferable model specs*, optional feature *= Categories such as size, color, and weight that serve as standards during asset inventory
- Mandatory model specs, optional feature - Indication of which fields are mandatory and must be filled out in all cases
- Upload of photos and files
- Data entry via QR code
- Rental approval
- Report export - Export reports on inventory as .pdf, .csv, .xlsx
- Value lists and standard vocabulary, required feature
- Location management - Define locations where inventory items are located and assign responsible persons
- User perspective
- Grouping based on model names, required feature
- Comprehensive search filters
- Favorites, optional feature
- Display view selection, optional feature - Display either as a list or as tiles
- Rental
The rental process is the heart of the application, but also the most complex part. Rentals must be finalized individually with each participating institution. This can result in differing transport conditions and framework factors. This means: Even if the rental pertains to a single project with the same key data, as soon as rentals are made from different properties, a separate request is required for each participating property. Rentals should be calendar-based to enable transparent scheduling. Double bookings—including in the future planning process - must be systematically prevented.
- Administrative Perspective
- Booking of Own Inventory
- Calendar overview, required function
- Planning status indicator, required function
- Request confirmation
- Issuance process, required function
- Return process, required function
- Special rental processes. Optional function
- User perspective
- Availability check
- Calendar-based project overview, required function
- Detailed project overview
- Project creation, required function
- Sorting of loaned items, required function
- Billing
- Automated invoicing, optional function – an invoice is generated for each completed project; exporting invoices should be possible
- Standardized contracts, required function
- Invoice archive, optional function
- User and contact management
- Within the scope of the pilot project, 12–14 participating institutions are initially planned as users, with at least two people in each requiring their own access. Expansion to additional institutions and/or users must be cost-effective and easily accessible. The system distinguishes between two user levels with different authorization logics. The responsible individuals at each institution assume a dual role as both administrators and users:
- At the backend level, the museums manage their own inventory within a shared central database that contains all objects from all participating institutions. The database is designed so that write and edit permissions are assigned exclusively to the administrators of the respective museum. Each institution can thus only create, edit, or deactivate its own inventory, while the holdings of other institutions are accessible only in read-only mode. This is a central feature of the system: Permissions must be managed in such a way that unauthorized access or misuse of other institutions’ inventory data is prevented, and the security of one’s own data is guaranteed at all times. This approach ensures a clear separation of responsibilities while also enabling consolidated data management across all participating museums.
- At the front-end level, the same individuals act as users by accessing the shared inventory via a user-friendly interface. They can search for objects, create wish lists, and submit rental requests. The search function accesses the entire database, so that results from all participating museums are displayed together - without separate queries for each institution.
- The respective role switch occurs contextually, depending on whether the person is using the backend (administration) or the frontend (search and request). This functionally separates the previous dual role, while the multiple use of individual roles remains possible.
- Additionally, the role of an administrator (Admin) is defined. The Admin has higher-level system rights and is responsible for central user management, role and access configuration, as well as for the overall administration of the platform. Furthermore, the Admin serves as the point of contact for technical and content-related questions, coordinates support and maintenance processes, and ensures a uniform usage system across all participating institutions.
- It must also be possible within a single institution to define responsibilities for specific areas (e.g., in Institution A, User 1 manages the furniture and User 2 manages technical equipment. In this case, User 2 should not have access to User 1’s administrator interface and vice versa, even though both belong to Institution A). Overarching institution profiles include both an overview of the responsible persons and contact details.
- Non-functional requirements
- User-friendliness
- Scalability
- Change history - Required “feature” - when changes are made, it shows who last made the change and when
- Error message, Required “feature”
Inventory management and the rental process based on it form the central foundation for using the digital database and are the focus of the project. Additional process-related requirements will initially be defined internally and do not necessarily need to be implemented by the platform.
At least approximately 30 software workstations (including 1 admin) are required. The system runs on MS Windows. Mobile devices run on both Android and iOS.
A requirements document can be requested via SoftGuide.