Partner-Facing Service Management Reports is a description of a scheduled report, prepared for each separate partner institution, that shows their use of the service while demonstrating reliability and value to contacts at the partner institution.

Communication

Sign-up is not required for participation in this Interest Group.  If you would like your interest to be known, you can add yourself to the list of participants (below).  Communication on this topic occurs in the APTrust Community Group.  To post, you’ll need to join that group.  To post on this subject, choose the tag “Best-Practices.”

Details

As a new technology service provider, AP Trust needs to adopt practices that show a mature service culture to their partners. This means clear and regular communication about how each partner institution is using their service, what they have paid, and what expectations they may have for reliability, scheduled downtimes, and performance. Examples of service management reports are easy to find in industry, most often combined with a bill. They show the client that they have received the level of service that they are paying for. Mobile phone companies use their bills to lay out alternate plan options and add-ons. Banks and brokers send a statement that lists every transaction and helpful metrics. These instruments help the client take stock and plan their next move. Lastly, the report can be a place to highlight opportunities for enhanced services, based upon customer data. At AP Trust we have been firmly embedded with the partners through the service development process. The report helps us to quantify the parts of the service that are built and in operation. It helps to distinguish the existing production service from future plans and development. Another key feature of this report is that it creates a moment during which all the key staff at the partner institution can see their holdings and progress. Much of the information in the report will be available in other forms via the user interface. However, a report will help make the service usage and status a matter of regular discussion between technical, content and administrative roles at each institution. For this reason I think a quarterly report makes sense. That will give the partners a mid-term report between partner meetings. Another report might preceed each partner meeting by a week or so.

Partner-Specific Components of the Report

• Usage or Transactions – quantify each transaction, list in date order
  • Ingest transactions (object count, cumulative file size, success/failure)
  • Restore transactions (object count, cumulative file size)
  • Deletes, etc..
  • Preservation metrics (integrity checks performed, file repairs performed)
• Holdings Metrics
  • Total unique bags
  • Total tombstoned bags
  • Total unique files and sizes
  • Redundant copies and where they are stored
  • Total storage used
• Service Calls and Incidents
  • itemized list of service contacts with partner staff
  • Problem indicators:
    • partner transfer speeds are lower than average
    • no new partner transactions
• Cost accounting and billing
  • What the partner has paid
  • Costs incurred by consortium
    • Share of overhead costs
    • Storage
    • Machine time
  • Pricing model and current partner charges
  • Projections for partner charges based on usage scenarios
    • if you maintain your current ingest rate, you will pay this much next year, year after, etc..
    • If you double your ingest rate, you will pay this much next year, year after, etc..

Other Components

• Changes to the service
  • New features, improvements (software changes, etc..)
  • Improvements to performance (network speed for transfers, for example)
  • Improvements to operating model (news about customer service)
  • New partners
• Service Quality Metrics
  • Scheduled service maintenance windows (period past and upcoming)
  • Availability metric (total uptime outside of these service windows)
  • Average bag transfer speeds, sufficient for partner time estimates on upcoming ingests
  • Average bag ingest and restore speeds

Building the Report

• You don’t want to build most of this information by hand. If you can manage it, the whole report should be generated.
• You can generate some the data points above from your Solr and Fedora, but you will have to build some of it with longer running processes. I think you’d want to build the report data up in a document store, like MongoDB. That way general and partner-specific metrics can be combined and you can incrementally add data.
• When all the data is built, then you can have a separate rendering step to perform layout into PDFs (and possibly static web pages)
• Since a key use of the report is local conversation at the partner institution, a printable form is a good idea.
• Send out to all partner contacts.