Support for itemized invoices

Idea created by tom.halang on Aug 12, 2016
    Under review

    ITSM (Catalog, SDM, APM, PAM) is a powerful combination of products – especially for MSPs like GISA.

    In the case of MSPs chargeback of services provided is one important pillar of the business.

    It is easy generating invoices of services or subscriptions requested, but most of the MSP's customers require a more transparent data on their bills.

    At GISA data in asset portfolio management is used for creating invoices.

    This data is resulting from the documentation within request fulfillment.

    Here an example:

    From Service Catalog an end user requests a desktop service along with additional
    options which is documented in APM and used for invoicing as data feed to SAP.



    The above is

    • custom made
      • requires ongoing maintenance
    • mainly documented manually
      • requires manual time consuming tasks
      • is error prone
    • not sufficient for MSP customers, because the original service is missing
      • not transparent to the customer
    • not efficient, because change or disposal of a previously requested service Need investigation and manual change of data
      • requires manual time consuming tasks
      • is error prone

    The goal is to have all data available for providing invoices like the following:



    This could be achieved by establishing a deeper integration between Service Catalog, SDM
    and APM, while using PAM for Automation.



    The above would be

    • upgrade safe
      • limits maintenance to regression testing
    • mainly documented automatically
      • saving time and effort, especially with higher volumes at MSPs
      • reliable, traceable and without human error
    • transparent to the customer, because invoices contain requested services and resulting assets
    • centrally administered
      • fulfillment rules are not in the head of human fulfillers, but in data relationships within Service Catalog
    • Support IMACD-automation
      • Change or disposal of a previously requested service can be performed based on existing data with relationships between service assets and assets
      • Assets can be automatically removed from inventory when the Service is cancelled
      • saving time and effort, especially with higher volumes
    • reflecting both,
      • the current status of all Services requested and resulting assets
      • and the history of all services already cancelled with resulting assets using a
        "cancelled" status

    As stated above: this would be achievable with a deeper integration of Service Catalog, SDM and APM.

    Service Catalog data model needs to be extended for a deeper data integration to APM and SDM and needs to hold data for controlling fulfillment workflows.



    How did you realize requirements like this?