I can’t comment on the pricing. I suggest to work with BMC sales team or partner.
Yes, it works with Remedy ITSM on-premise and SaaS, and with Jira on-premise and SaaS. Peter From: ARSList <[email protected]> on behalf of Carl Wilson <[email protected]> Reply-To: ARSList <[email protected]> Date: Wednesday, January 30, 2019 at 3:57 PM To: ARSList <[email protected]> Subject: Re: Remedy <-> Jira Hi Peter, I have a customer interested in this, so have a few questions if I may: - Can you let us know how this is licensed i.e. do you pay for the Helix application as a separate application? - Does it work with on premise ITSM installs to cloud, cloud only, or can you mix and match i.e. on premise ITSM > Integration Management (Helix) > on premise Jira? - Are there transaction based limits i.e. X amount of transactions per month for a set fee, then Y amount above this limit? - Does this use a "polling" system to pick up transactions, or is it real time transaction processing? Cheers, Carl On Wed, 30 Jan 2019, 23:33 Adams, Peter, <[email protected]<mailto:[email protected]>> wrote: Before you embark building this, using the rich set of integration options available with Remedy, I suggest that you check out the new out-of-the-box solution available for Remedy ITSM – Jira integrations: BMC Helix Multi-Cloud Service Management https://www.bmc.com/it-solutions/multi-cloud-service-management.html * Covers incidents, changes, problems and in upcoming release also workorder * Bi-directional integration, i.e. integration can be triggered on either side * Data driven trigger, i.e. you define the conditions which trigger the integration flow * Automated sync of status, comments, attachments * Mapping of multiple Jira user stories into one change request possible * Has full UI integration with Smart IT, not just data exchange * Very easily configurable (flow, field mappings, …) with no-code approach * Can support multiple Jira instances * Reporting option available Plus, you can use the same solution also for many other integration use cases (ticket brokering, ticket consolidation) Note: for BMC Digital Workplace Advanced, there is also an option to directly integrate with Jira from the request fulfillment process. You can use this to create a Jira issue automatically as a result of a service request submittal. Hope that helps, Peter From: ARSList <[email protected]<mailto:[email protected]>> on behalf of BradRemedy <[email protected]<mailto:[email protected]>> Reply-To: ARSList <[email protected]<mailto:[email protected]>> Date: Wednesday, January 30, 2019 at 2:44 PM To: ARSList <[email protected]<mailto:[email protected]>> Subject: Remedy <-> Jira Hello everyone How are things going ? 2019 off to a good start ? I have been tasked with establishing a full integration between JIRA and Remedy (MYIT / ITSM). We are currently running Remedy 9.1 , ITSM 8.1 and MYIT 3.4 and while we do have plans this year to upgrade all our modules to the latest remedy versions, I need to determine how much work / effort is involved in getting a complete integration between these 2 keys systems with the current versions that we have. We understand that we might need to re-work some of the integrations as we upgrade - however as long as we have a starting point then we are good. So my initial thought it so have the following integration and it is a bit high level however it is a starting point: 1. Requester logs into MYIT and logs a request for a issue that they are experiencing. This in turn logs a Incident which is assigned to a support group; 2. The support group determines that this is a BUG and can either assign a incident to a development team or they can create a task in the Incident and assign it to the development team; (If so required, we could also get the MYIT Request to push directly to JIRA if no Incident is needed) 3. Remedy has workflow that is setup to push any tickets assigned to that development team to a JIRA storyboard; 4. When successfully created, a JIRA reference number is pushed back to Remedy and updated on the ticket thus a relationship between the 2 systems; 5. As the JIRA moves through the different life-cycles, the ticket status in Remedy is updated; 6. Any Information or notes added in JIRA are also pushed back to the Remedy ticket which in turn are pushed to MYIT (If Public Work info's) so the requester is kept updated; 7. Likewise, any work info's added in Remedy need to be pushed back to JIRA to keep the developer updated; 8. When the JIRA ticket is completed, we can then automatically log a change request in Remedy, associated it to the JIRA ticket and also associated the change request to the logged Incident. This will let the Requester know that there is a scheduled release date etc; 9. Once the bug fix code is deployed, the JIRA task is closed (Completed), which in turn completes all associated Remedy tickets (Incident, Tasks, Change Requests) with a final work info update to MYIT for the requester to see. How does the above sound ? Have I missed anything ? The key for us is that the 2 systems need to be very interactive with each other as we don't want the development team having to use 2 different systems to do their work. Likewise, we don't want our end users having to log requests in 2 different systems. The key thing is automation and ease of use. Has anyone done anything similar in their company? If so, please can you share how you did it, what challengers you faced or if there are any articles / whitepapers you recommend I read so that we can get this requirement out as efficiently as possible. Any assistance or advice would be greatly appreciated. Regards Brad -- ARSList mailing list [email protected]<mailto:[email protected]> https://mailman.rrr.se/cgi/listinfo/arslist<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailman.rrr.se_cgi_listinfo_arslist&d=DwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=-p3bdWG7vYdkTt7drxJU1lGabyBnkFDsCeyI4HR-08o&m=whPTaYIPTv9k6YFZopGczRyVhTgqvPfVTHWyDuff5iQ&s=vNom9LRXI2lunRzMtddiWbwsSBJIqByyiUSZmVeT9M8&e=>
-- ARSList mailing list [email protected] https://mailman.rrr.se/cgi/listinfo/arslist
