5 of 5 people found this helpful
Great list here!! Thanks Naji Abdallahi for starting this discussion. We're just getting into DWP Advanced and started using DWP Catalog to start managing our services. We haven't created any services in DWP Catalog but are either using "SRM as-is" services or "DWC import" by importing the SRDs into DWC. Here are some differences we've encountered:
- To address one of the biggest differences (the elephant in the room), there is a high learning curve and a substantial time investment in the inital setup to create DWP Catalog services that integrate back with ITSM as there isn't any out-of-the-box workflow provided, e.g. you'll have to create the Workflow to create Work Orders, Incidents, Change Requests, etc. Not to mention, if you use the SR Type field to pass information back to the Work Orders that will be used by the support users, you'll have to setup the workflow to do that as well when the WO is created. Since this is a BMC product, one would think that some basic integration/workflow to ITSM would already be in place and just need to be tweaked/updated per customers' environment.
- Entitlements or Virtual Marketplaces are still a bit quirky to work with - the advanced qualifications that you are able to do in SRM isn't possible in DWP Catalog
- One small item that was recently brought up was the lack of support for HTML codes in DWP Catalog especially for font colors and such, which really makes instructions stand out for the customers - from what we've seen, instructions seem to be coded to be understated/greyed
- Regarding #4 in the initial list above, data being stored on another server/database - it doesn't make our reports writer very happy, as it is yet one more spot to report from especially if the customers/management want metrics related to the Services requested; oh and good luck trying to get specific details about the request especially when data from the fulfillment tickets are needed, we already do joins within the ITSM tables, now we'll have to do joins between databases
- With SRM, you can enable the End User Process View, which is helpful in tracking where in the process the current ticket is in - not sure if this is possible in DWP Catalog, as imported SRDs do not display this
These are just some of the items we've noticed, that I can remember. As I said earlier, we're just getting into DWP Advanced and started using DWP Catalog. We're still heavily using SRM services and have imported a little over half (85/151) into DWP Catalog. Still haven't created a purely DWP Catalog service as we didn't want to drastically change the support user and customer experience (REQ#'s, notifications, etc.).
Hope that helps!!
I am agree with all the points that Sonny mentioned, we still use the DWC import from the SRD rather than create the workflow manually in the Digital Workplace Advanced, My thought is it's easier for admin to create the request using the service request designer wizard in midtier then import it into DWC then we just need to activated it for using this.
Please advise , is it better for us still do the import things or we create service request through the DWC?
2. About the separate database, it will hard for the administrator if we want to create reports that need information between service request that created in the DWC and the fulfillment.
3. About the end user process view, it's really a good feature that can provide for the requester sight about where is the current status for his request but it's not provided in the DWC.
3 of 3 people found this helpful
Ricky, The only issue with creating with SRM and then importing is that you need to maintain SRM and you need to reimport when you make any changes. So I would seriously consider creating any new Services in DWPC. Just use import to get the existing SRDs into the DWPC Admin site.
Not being able to Smart Report on the DWPCat database could have a couple of workarounds:
- Create an AR System View Form that references the DWPCat database. View Forms can point to any table on any local or remote DB server, if configured.
- Import the data into the ARsystem DB using Pentaho Spoon jobs.
And Process View:
- If you need to check on process for troubleshooting reasons as an admin, use this technique DWP Catalog: What’s happening to my services?
- If you are looking for this for end users, then as Sidhdesh Punaskar answered in another thread, that is not a feature we have... yet. Vote here Introduce Service Request Process View for MyIT/Smart IT
Regarding Entitlements (which Emmanuel mentions) it is worth knowing that ANY selection field on the CTM:People form can be used to define a rule. Even new, custom selection fields that you might populate with a custom Filter. You do need to make sure the entitlements cache is up to date, but that also applies to OOTB rules.
2 of 2 people found this helpful
For the Process View :
From my point of view either in SRM and in DWP, it is not a good idea to show the back office workflow to end-users.
As an End-user, i don't care if my request creates WorkOrder (i do not even know what is this thing...), Change, Incident or Ticket in another tool. As an End-User i need a user friendly information at which step my request is.
With DWPC you can have this :
- From the 19.05 version, you have the Progess Bar with the DWPC Request Status (Submitted Approval, In Progress, Completed)
- In your DWPC Workflow you manage the status of the request by using the Set Service Request Status. You can adjust the Status Reason field : it is a free text.
- I think, you can do something like :
* when a Work Order is created, you adjust the Status Reason field with (for example) : "You are at the step 1 of 3. The group assigned id, ...."
But, the Process View should be in SmartIT for troubleshooting and for the ServiceDesk to answer to the end-user to "What's happen with my Request XXXXX"
An other difference betwwen SRM and DWP : in DWP you can only have 1 question in the generated survey
1 of 1 people found this helpful
@Sebastien, Fully agree with you on not showing end users the process. I used to systematically hide this in SRM for all SRDs outside of testing. So the fact it is gone from DWP is good news for me.
It gives out ticket IDs that they could start to quote instead of the Request ID, and like you say, we do not want end users getting involved in the perhaps complicated workflow inside the Service. Now that workflow could be with other connectors, such as REST and AD it is even less wise to share that with end users.
And the setting of Status Reason field is a very good way of giving end users more feedback on progress, as would be creating a comment on the Service Request for end users with the Create Activity Log for Service Request element. Using that, plus the 19.05 progress bar should be enough info for end users to know what is happening.
A workaround to Smart IT users not being able to see the process would be to make sure they are Agents in DWP Catalog, so that they can see the Service Requests Report that also has the Process View. We could create a Smart IT URL Action in Screen Configuration to make a shortcut to the report to help a bit. We have to be careful though, because ITSM multitenancy does not go into DWP Catalog. They would see ALL service requests.
1 of 1 people found this helpful
A few more key differences that have come to my attention
- DWP Catalog Workflows can use the Create Activity Log For Service Request to add information viewable as a Comment by clients in DWP. SRM has no means of doing this without using Process Designer.
- DWP Catalog workflows can update the Status of the request at any point, and add Status Reason for DWP users to read.
- SRM has AIFs but DWP Catalog has no real equivalent for Services created natively rather than imported from SRM.AIFs are able to hold tables and other input interfaces built in Developer Studio.
- There is no Reopen option in DWP Catalog services, although there is for SRDs in SRM and imported SRDs. Idea submitted https://communities.bmc.com/ideas/20847
- DWP Catalog can show USED BY assets on the My Stuff > My Items page and allow for creating of requests from there as actions. These actions can retrieve the name and reconciliation IDs of the CI to pass to into the Affected Asset field on an incident.
And a simple workaround to ensure that Smart IT users can work our which Order ID and Request ID is related to the fulfilment tickets would be to include that data in the Summary mapping, or any other field. Like this: