1. NATIONAL GALLERY AUSTRALIA Movement Request System (MRS)

2. More than 160,000 works of art across four main areas: Aboriginal & Torres Strait Islander art, Australian art, Asian & Pacific art and International

3. Overview The requirements The users CSRS pre-existing system Assessing the options The result Requirements for a new DAMs system Post release Lessons learnt The long term goal?

4. The requirements scale of requests often larger than actual capabilities to complete tasks in one time, ability for requests to be received and progress tracked from start to completion ability to manage requests for works stored at multiple sites and destinations ability to plan ahead or keep track of the back log and document the resources required minimise time spent on communication via emails or meetings

5. Meet the users Requestors: enter new requests for movements of art works Art handlers: action movement requests and relocate art works Max Dupain, Mr and Mrs Larry Adler, 1936, National Gallery of Australia, Canberra, purchased 1982

6. Requestors They want to request works of art for a number of different reasons, they don’t necessarily understand the complexities of tracking parts / or works in EMu. John Bainbridge, An invitation: London Transport poster, National Gallery of Australia, Canberra, Gift of the estate of Garry Anderson 1995

7. Movement Tasks Truck runs (External Movements) 1-2 runs per week Internal Movements Receiving new acquisitions Receiving incoming loans Movements to and from conservation Movements to and from imaging Movements to and from display Movements to and from packing Movements to and from storage Joyce Allen, Family at work, 1973, National Gallery of Australia, Canberra, Gift of the artist 1986

8. Art handlers Spend most of their day handling art works to meet the demands of NGA internal requests They rely on the system to receive and manage the incoming requests Harold Cazneaux, Tired horses: from "Frensham Book", 1934, National Gallery of Australia, Canberra, Gift of the Cazneaux family, 1981.

9. CSRS pre-existing system Collection Services Request System (CSRS) Originally developed in 2004 for the imaging department to assist with digitisation workflows, later expanded to include: Conservation Loans Packing Movement How the CSRS works: SQL Server Access DB Connects with Emu

10. Assessing the options CSRS? EMu? IMu? Mobile devices? Wifi? Graham Lightbody, Pipi Storm Computer Days, 1981, National Gallery of Australia, Canberra, purchased 1990

11. CSRS no longer sustainable In-house bespoke system, no longer supported SQL Server back-end Access database front-end Connects with EMu’s standard libraries (APIs) Reports printed straight to printer not screen Requester can’t search or review requests

12. EMu client solution EMu as the solution? (from 2012) TASKS tab So close, but… Spread across different modules, o no single list of tasks o no ability to relate task to each other or an over-arching project (exhibition) Not in all modules Would need serious customising

13. EMu client solution EMu as the solution? (from 2012) Scheduled Internal Movements (New EMu feature) Close but… All works on the one movement must have the same destination Our requestors would have to split works into requests for each destination (not very practical) All works on the one movement will be updated at the same time (no partial completions)

14. EMu client solution EMu as the solution? (from 2012) An EMu client solution won’t be perfect because: most users don’t understand EMu, and so most users don’t “love” EMu CSRS is not an amazing interface – but it has colour! CSRS was purpose built – limited functionality, less overwhelming, seen as “easy” to use. Result: An EMu Requests Module might work but probably not perfect.

15. IMu IMu as the solution? (from 2012) users wanted an easy interface one place to see all upcoming tasks, “to do list” ability to track statistics on completed tasks potential for IMU to provide a task-specific layer over standard EMu client functionality Honoré Daumier, Ungrateful country, you won't get your hands on my work!, 1840, National Gallery of Australia, Canberra, Gift of Orde Poynton Esq. CMG 1994

16. The result web interface (Released November 2013)

17. The result Requests module (Released November 2013)

18. Auxilary Parts Holders Art works Paintings & Objects Textiles Works on Paper Display Imaging The result

19. Requirements for a new DAMs system (2012) DAMs to manage: New digitization tasks Image ordering workflows Publishing workflows Charles Blackman, Newspaper man, 1953, National Gallery of Australia, Canberra, purchased 1977

20. Requestor feedback post release MRS was first released in November 2013 In April 2014 a survey aimed at “Requestors” proved feedback was positive, 95% found the MRS to be an improvement on the previous CSRS system, they agreed the interface was easier to use. This feedback gave us confidence the system was a success in meeting the objective to replace and improve the pre-existing system.

21. Art handler feedback Wifi connectivity restricted mobility between spaces Timeout of web sessions The system could not cope with the scale of requests Generally they preferred to use the functionality they are familiar with in the EMu interface Users discovered bugs with the interface, they were losing confidence in trusting the system

22. Testing post release Wifi connectivity issues Timeout of web sessions The system could not cope with the scale of requests – we disabled it Encouraged the art handlers to use the Requests module in EMu and we designed customised reports to suit their needs it proved difficult to trace audit trail of MRS in EMu

23. MRS development release 1.5 (2014) Bugs and issues with subrequests fixed Wifi connectivity improved Timeout sessions extended The system improved to cope with the scale of requests – we minimized the data the system was attempting to load, but still not responsive enough could take up to 4 minutes to load the “my requests” page for some users

24. MRS – Lessons Learnt development of a new IMu solution requires an iterative approach documentation of requirements based on user centric design and testable functionality Preference for EMu module vs web interface mobile devices and wifi access not always practical IMu audit trail and security Speed and performance Information lifecycle

25. IMu Development – Lessons Learnt Challenges of documenting requirements, specifications and testing Challenges of writing requirements with testable functionality, limitations of expertise and communication in development phase Negotiating resources post release (NGA’s project funding model not generally set up for ongoing software development)

26. The long term goal? workflow management Critical Path New acquisitions Permanent Gallery changeover Internal exhibition Outward Loan –Requested: record in Emu –Movement to Conservation –Condition Assessment –Movement to Imaging –Photographed –Mountcutting? Framing? Packing? –External Movement –Arrival –Condition assessment These could all be subrequests, each with their own IMU interfaces.

27. For more information: Contact Giselle Stanton Assistant Registrar – Storage and Documentation giselle.stanton@nga.gov.au Contact Mark Bradley Assistant Registrar – Storage and Documentation mark.bradley@nga.gov.au