Your SlideShare is downloading. ×
ERM ticketing system
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

ERM ticketing system

644

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
644
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • From a vendor glossy: All about the flow ¾ of this process is about acquisitions! Discover through access at least
  • A Disjointed database Status indicator, overlayed on access mngmt page License page Contacts page Notes page, with reminders Vendor statistics page Weak connections between pages No sense of flow in the system 2009 Marketing quote
  • Standardized: Scattered e-resource acquisition process    Centralized: Information needed: funding formula (often complex for expensive e-resources), type of order (content + access, subscription only, etc) license contact person for vendor, subjects for addition to databases page, any local notes, availability of MARC records No central place to store information needed for e-resource acquisition    Transparent: Lack of transparency for bibliographers
  • Standardized: Scattered e-resource acquisition process    Centralized: Information needed: funding formula (often complex for expensive e-resources), type of order (content + access, subscription only, etc) license contact person for vendor, subjects for addition to databases page, any local notes, availability of MARC records No central place to store information needed for e-resource acquisition    Transparent: Lack of transparency for bibliographers
  • We did not need to purchase separately. In order to encourage wider adoption, Digital Library department gave me administrator access with full rights to create and administer new projects.
  • Default JIRA workflow – Open, In Progress, Resolved, Closed Issue goes through same set of steps each time, in a single direction through the department Each unit has been assigned a distinct role with every issue in JIRA, creating a more cohesive workflow cycle of an electronic resource.    Payments department also notified when an issue transitions from Ordering to Electronic Resources to prompt Payments that a resource is ready to be paid, or an invoice may need to be claimed.
  • Results rely on triage manager to start new purchase along acquisition process   Information added along the way, such as purchase order number by Ordering department
  • Statuses allow progression of incident to be shown in Confluence wiki without direct attribution to staff member. Selectors can show whose hands the issue is in, without feeling that one person is the problem.
  • Payments dept: notification of order placed and po #, allowing them to pay invoices in hand or find more information when they receive invoice. If they note when invoice is paid, e-resources will know when access should begin Recent developments:  end of the year rush worse than ever,  Tech Support starting to use JIRA,
  • Already set up JIRA projects for new proxy requests and for MARC record loading. Currently working on setting up workflow for purchasing microfilm and moving newspaper to auxiliary storage. Drupal forms will allow tighter control over form details and functionality without need to request help from Digital Library at every turn
  • Note not intended for single ejournals or standing order titles
  • Requires basic information & needs analysis Portions formerly missing in emailed requests, and field limits match listing tool “ Front loads” request for metadata we used to try to track down later in the process DB description, Subject/Type choices* Submission begins tracking process
  • Key features – Decision support system Invites group participation in evaluation Increases objectivity in decision making Need to add pricing info
  • Includes only those license points we negotiate Allows any collection librarian to complete license review (and collaboration as necessary)
  • Key features Collection librarian chooses applicable steps and notes necessary detail Acquisition staff completes steps individually Clear tabular view shows what remains to be done
  • Not lost in someone’s email or printed on someone’s desk Available to requestor community
  • Transcript

    • 1. Tracking electronic resources acquisitions: Using a helpdesk system to succeed where your ERMS failed Charleston Conference 2009
      • Xan Arch Electronic Resources and Technology Librarian
      • Acquisitions Department
      • Stanford University Libraries
      • Jason Price, Ph.D.
      • Science Librarian
      • Head of Collections & Acquisitions
      • Claremont Colleges' Library
    • 2. The ERMS promise - 2005 FLOW CHART
    • 3. What was delivered “ With [our ERMS] we have all the information in one place” http://www.weewonderfuls.com/2006/02/huh.html Licenses Contacts Notes Status indicator Reminders Access info
    • 4. Reality of Claremont’s e-resource acquisitions workflow
    • 5. Some key advantages of using a ticketing system for ERA
        • Designed to track ‘issues’ through stages to resolution
        • Structures ‘metadata’ relating to an issue and shares it with others enabling coordination
        • Flexible enough to allow a customized set of steps for each issue & distributed implementation
        • Collects email trail relating to each ‘issue’
    • 6. Stanford’s solution Xan Arch Electronic Resources and Technology Librarian Stanford University Libraries
    • 7. Selector License Negotiations Ordering Unit Payments Activation Cataloging Tracking our orders What we had: Defining our process
    • 8. What we needed: Defining our problems
    • 9.
      • Enterprise-level bug tracking software from Atlassian
      • Already in use in our Digital Library department
      Finding a solution
    • 10.
      • Each order goes through the same steps
          • In Progress – Licensing
          • In Progress – Ordering
          • In Progress – Electronic Resources
          • In Progress – Metadata
      • JIRA notifies the department or individual by email when they are required to act on an issue
      Standardized: Solution
    • 11.
      • The web form
      Centralized: Solution
    • 12.
      • Display in Wiki
      Transparent: Solution
    • 13. JIRA Workflow - Acquisitions
    • 14.
        • Completely in place in Acquisitions department
        • Less established in Collections, some selectors initiating orders through webform, others still sending email
        • Some types of purchases still ambiguous – major database renewals, new e-journals
        • Recent developments have pushed adoption further along
      A work in progress
    • 15.
        • Use of JIRA for other projects in Acquisitions
        • Moving webform to Drupal forms
      The future
    • 16. Questions ?
    • 17.
      • Claremont’s solution: eRATS in Footprints by Numara
      • Jason Price
      • Claremont Colleges’ Library
      • Claremont University Consortium
    • 18. Claremont’s eRATS was designed to address specific problems:
      • In order of importance:
      • Delays (or loss!) due to dropped communication
      • Incomplete listing/activation of resources
      • Standardization of required metadata
      • Lack of transparency as to resource progress
    • 19. Tracking-system supported workflow
    • 20. Stage 0: Resource request form
    • 21. Stage 1: Under Review
    • 22. Tracking-system supported workflow
    • 23. Stage 2: In negotiation
    • 24. Tracking-system supported workflow
    • 25. Stage 3: Pending activation Resource fully available 3 Resource fully implemented Acquisition staff implements 2 Collection librarians determine 1
    • 26. Next steps
      • Beta – then implementation
      • Configure public display of progress
      • Design Acq reports (delivered from Footprints)
      • Output to ERM?
    • 27. Summary / Overview
      • “ Smart” Checklist
        • Periodic required decisions as stage changes
        • Shared in real time
      • Workflow-based
        • Each update noted in history entry & encourages indication of next step
        • Issues can be assigned to one or more people for the next action(s)
      • Information repository
        • ‘ Issues’ (resource records) can send and receive email
        • Stored as one text field—fully searchable
        • Appropriate metadata extracted into fixed fields as available

    ×