When using the Application Editor in Essential Cloud you can select Orgs and Bus Procs on the Business Usage tab to show which orgs use this application and which processes they use it for.
When you look at the Application Provider instance in the capture tool the data linking the application to the business process shows up in the slot app_pro_supports_phys_proc which shows as depreciated.
If this is no longer the correct way to link an app to a business process then what is the correct way and what changes can be made to the editor to build the linkage correctly?
How do I handle the existing Application Provider to Business Relationship instances, do they need to be deleted in the future?
Application Editor used Depreciated Slot
Hi Declan,
It was deprecated and then we un-deprecated it a while ago.
The ideal pattern is:
Business Process --> Physical Process (with Org) --> Application Provider Role --> Application, e.g.
Process Invoices --> Finance performing Process Invoices --> Workday as Invoice Generation --> Workday
This is important when we look at rationalisation opportunities.
We used to map directly to applications, but brought in the mapping to services to allow a deeper analysis. We deprecated the old slot when we did this, however, we realised that a lot of people don't do the service mappings immediately, so added the slot back. This means you can have:
Business Process --> Physical Process (with Org) --> Application, e.g.
Process Invoices --> Finance performing Process Invoices --> Workday
A lot of the views will recognise both, e.g. Business Capability Dashboard, but the deeper analysis views, e.g. application rationalisation won't.
The difference is quite important, the latter is a pointer to where there is duplication, e.g. we have 3 HR systems, the ideal will tell you that you have 3 HR systems but also lets you see where they overlap and, more importantly, where they don't. E.g. we have 3 HR systems but unless we replace this specific functionality that exists in one of them then we can't rationalise, this could be something such as a some local regulatory requirement that the system supports.
If you have the data then map via service, if not then map directly. Note in the tab where you map Application to Process (and the same on the inverse tab for a Business Process). If you select 'Don't know' on the pop-up select at the intersection then it creates a direct mapping of physical process to application.
Hopefully that helps explain it
It was deprecated and then we un-deprecated it a while ago.
The ideal pattern is:
Business Process --> Physical Process (with Org) --> Application Provider Role --> Application, e.g.
Process Invoices --> Finance performing Process Invoices --> Workday as Invoice Generation --> Workday
This is important when we look at rationalisation opportunities.
We used to map directly to applications, but brought in the mapping to services to allow a deeper analysis. We deprecated the old slot when we did this, however, we realised that a lot of people don't do the service mappings immediately, so added the slot back. This means you can have:
Business Process --> Physical Process (with Org) --> Application, e.g.
Process Invoices --> Finance performing Process Invoices --> Workday
A lot of the views will recognise both, e.g. Business Capability Dashboard, but the deeper analysis views, e.g. application rationalisation won't.
The difference is quite important, the latter is a pointer to where there is duplication, e.g. we have 3 HR systems, the ideal will tell you that you have 3 HR systems but also lets you see where they overlap and, more importantly, where they don't. E.g. we have 3 HR systems but unless we replace this specific functionality that exists in one of them then we can't rationalise, this could be something such as a some local regulatory requirement that the system supports.
If you have the data then map via service, if not then map directly. Note in the tab where you map Application to Process (and the same on the inverse tab for a Business Process). If you select 'Don't know' on the pop-up select at the intersection then it creates a direct mapping of physical process to application.
Hopefully that helps explain it
