Integration with procurement system

[a_cutler2]

I'm looking for some details on what is possible regarding integrating App Broker (with ServiceNow) with a procurement system. A new customer currently has a very manual process in place for requesting/deploying software and they are looking to help with automating the portion of the process that deals with requesting software where there isn't currently an available license. They are currently using Coupa which I believe can be integrated, but I'm hoping for some more detail on how that workflow would look. Would a request that requires buying a license simply generate an email that would create a ticket in Coupa, and then that would manually require the purchase, manual deployment and manual closing of the ticket? Is there any way to use App Broker to bring the end user requesting this software to the right Punch Out in Coupa? 

[jdempsey · Accepted solution]

Flexera Services has done a custom integration with Coupa for another customer.  I believe it was about 6 weeks of effort, but now that we've done it once, it would hopefully take less time to repeat that.  Having said that, I'm sure there are multiple ways to do an integration and probably varying degrees of automation.  For the implementation we did, we were importing charge code data from Oracle (same source that was feeding Coupa) and prompting the requester to select the proper charge codes during checkout.  After submission, we validated the charge codes that were selected and sent the requester an email notification if the codes were invalid for that request (and paused the workflow until they were corrected).  Once charge codes were properly validated, a purchase request would be automatically created in Coupa and assigned to the buyer team.  The buyer team would update some of the required data in the purchase request and route for budgetary approval within Coupa (this was in addition to manager approval in App Portal).  App Portal would monitor the purchase request looking to see if it was approved (PO generated) or rejected.  If rejected, the request would be rejected/canceled in App Portal.  If approved, the PO number was captured in the App Portal request notes and deployment of the software started in SCCM.

All of this was implemented with a set of PowerShell scripts hitting the Coupa REST API's.  It may be possible to do an integration via emails as you suggested, but I don't really know.  The Oracle import was done with a scheduled PowerShell script picking up CSV dumps from a network share (populated by a nightly dump from Oracle) and writing the data to custom tables in the App Portal database.  The charge code selection was done with a custom popup dialog triggered from the questionnaire page of the checkout wizard by clicking on a hyperlink in the question label (this part could have potentially been done using a web service-populated drop-down list question if request-on-behalf was not allowed).

[jdempsey · Accepted solution]

Flexera Services has done a custom integration with Coupa for another customer.  I believe it was about 6 weeks of effort, but now that we've done it once, it would hopefully take less time to repeat that.  Having said that, I'm sure there are multiple ways to do an integration and probably varying degrees of automation.  For the implementation we did, we were importing charge code data from Oracle (same source that was feeding Coupa) and prompting the requester to select the proper charge codes during checkout.  After submission, we validated the charge codes that were selected and sent the requester an email notification if the codes were invalid for that request (and paused the workflow until they were corrected).  Once charge codes were properly validated, a purchase request would be automatically created in Coupa and assigned to the buyer team.  The buyer team would update some of the required data in the purchase request and route for budgetary approval within Coupa (this was in addition to manager approval in App Portal).  App Portal would monitor the purchase request looking to see if it was approved (PO generated) or rejected.  If rejected, the request would be rejected/canceled in App Portal.  If approved, the PO number was captured in the App Portal request notes and deployment of the software started in SCCM.

All of this was implemented with a set of PowerShell scripts hitting the Coupa REST API's.  It may be possible to do an integration via emails as you suggested, but I don't really know.  The Oracle import was done with a scheduled PowerShell script picking up CSV dumps from a network share (populated by a nightly dump from Oracle) and writing the data to custom tables in the App Portal database.  The charge code selection was done with a custom popup dialog triggered from the questionnaire page of the checkout wizard by clicking on a hyperlink in the question label (this part could have potentially been done using a web service-populated drop-down list question if request-on-behalf was not allowed).

[jdempsey]

I should add that this does have licensing implications on the Coupa side.  Normally, you would have people going into Coupa to submit purchase requests.  Each of those users would require a Coupa license that grants them permissions to do what they need in the tool.  Since this integration would be eliminating the need for that user access by having a single service account hitting API's, the customer had to make some arrangement with Coupa for how that would be licensed.  I don't know the details of that arrangement, since I wasn't involved in those discussions, but I suspect it may be some kind of a transaction-based fee.  I would probably start with that conversation before deciding whether or not to head down this path.

[a_cutler2]

Thanks this is excellent information. For validating the charge code after the user submits the request, how was that validation performed? Was it a manual part of the process? 

[jdempsey]

The charge code validation was fully automated through PowerShell.  We added some business logic to check that the codes were valid based on the business rules populated from Oracle (e.g. is the code valid for software purchase, is the request being submitted within the valid date range for the code, is the code valid for the requester's organization, etc.).  Then we attempted to submit the purchase request to Coupa, and if we got an error code back, we could put the request back into the "loop" and surface the error to the requester.

[a_cutler2]

Follow up question for this custom integration with a procurement system - does the integration you did previously simply draft a PR with the procurement system, or does it/can it do an actual integration with punch outs? For this customer they use Coupa. 

[jdempsey · Accepted solution]

I keep hearing people use the term "punch outs", but I still have no idea what that really means.  Can you put that into layman's terms?

App Broker does not directly integrate into other catalogs (in either direction).  We don't implement OCI (Open Catalog Interface), and there is no automated feed of catalog data between systems.  The integration we did uses a generic catalog item in Coupa (for "App Store Software") and simply drafts a PR for that item and submits it (assigned to Coupa buyer for manual review/updates).  Details (publisher, product name/version, estimated cost, requester, Ship To address, charge codes, etc.) are added into the description or added as an attachment.  The buyer makes any updates (e.g. select reseller, update actual cost, etc.) that are necessary before submitting it for financial approvals.  Within App Broker, we monitor the status of that purchase request (via script added to On Check Status event).  If the PR goes back into a "Draft" state, that means it was rejected by an approver, so we reject/cancel the request in App Portal.  If the PR is linked to a purchase order (PO), we add the PO number to the request notes in App Broker and then continue to the deployment of the software.

[a_cutler2]

Thanks Jim. From what I understand punch outs make it so the traditional methods of purchasing are no longer needed (getting on the phone or working with a person). It's a connection between a buyers procurement system and a sellers e-commerce site that helps suppliers provide real-time catalog information to buyers. So basically a shopping cart style of experience with a real time pricing and availability on the back end.