Physical Process Model

Post Reply
Rick.Allen
Posts: 23
Joined: 21 Jun 2012, 18:08

I am attempting to Model the Enterprise from top-down and bottom up. We have numerous manual activities and unrealized potential integration between application/processes.

My Business Process models render correctly with the appropriate roles, organizations, supporting applications.

However, I am struggling with the Physical Process Model

1. In the Physical Process catalogue, Processes are listed multiple times. This does not happen with the Business catalogues. I can get a single entry per Process when the Business Process has only one organization listed in Performed by Organizations. The entry must also be performed by a Group Actor to have its name listed in the Physical Process Catalogue otherwise the name is blank.

2. Workflow Steps are appearing as per my expectations, but I cannot reliably see the Performing Roles

3. Primary Business Actors sometime appear and I assume it is the set of Actors from the Workflow Steps

4. Reports produced. How are they modeled to appear? I have some Information Representation appearing.

5. Upstream / Downstream Systems. How are they modeled to appear?

6. Triggers: Do appear as expected.

When complete, I then want to use EA for Change Management purposes and display the results in a format suitable for business users.

Thank you for any assistance.

Regards, Rick
Rick Allen
Enterprise Resource Planning (ERP) Analyst
Hamilton Police Services, Ontario, Canada
User avatar
neil.walsh
Posts: 444
Joined: 16 Feb 2009, 13:45
Contact:

Hi Rick,

When you say Physical Process Catalogue, which view do you mean?

Can you send a sample URL(s) (can be http://localhost/blah) so we can see which xsl file(s) you're looking at.

Can you detail where you're expecting to see the various bits and we can advise. It maybe that you're hoping to see various aspects in a single view where they may actually be represented across a range of different views. It's rare that a single view shows an end-to-end definition of a single class. Though it's possible to do this, we try to create views that make sense as a more manageable bundle of relevant knowledge of an object.

We have some improvements coming to the process views which better support roles, decisions and information. These are scheduled for the v5 release due later this year.

Cheers

Neil
Rick.Allen
Posts: 23
Joined: 21 Jun 2012, 18:08

Attached is an example of the catalogue with expanded processes
Physical Cat 2.JPG
The Physical Process Model view with comments
Physical Cat 2.JPG
You do not have the required permissions to view the files attached to this post.
Rick Allen
Enterprise Resource Planning (ERP) Analyst
Hamilton Police Services, Ontario, Canada
User avatar
neil.walsh
Posts: 444
Joined: 16 Feb 2009, 13:45
Contact:

Thanks for the screenshots. I'll take a look at this and get back as soon as possible.
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

A Physical Process is a combination of the Business_Process that is being performed along with the Actor that is performing it and the role that they are playing when they perform this process. For these to complete all the elements on the out-of-the-box Views, you need to make sure that you have an ACTOR-TO-ROLE-RELATION defined for the Physical Process.

If you have many different Actors performing the same [Logical] Business Process (e.g. playing different roles or multiple people / teams performing it), each of these is a separate Physical Process and this is likely to be what’s behind the repeated items on the catalogue.

I’ve had a look at the core_bl_physproc_workflow_model.xsl View template and it is looking to pull any Actor-to-Role from the Physical Process (and the sub-processes) and is not picking either Group or Individual. It may be that in the catalogue, the View is only picking up Group Actors. In the core_bl_physproc_list_by_domain.xsl View, it is doing so. If you want to show Individuals in there as well, you can easily tweak the View query to include Individual Actors as well. (Line 33 of the View). Let me know if this is something you’d like help with.

For Actors to appear on the process flow, there needs to be an Actor-to-Role defined against the sub-steps defined in the “Contained Physical Sub Processes” slot on your Physical Process.

We need to ‘mirror’ and refine these sub-process definitions because at the Physical Process layer we are defining which Actors and which Role they are playing when they are performing the processes that we defined in the Business_Process instances and process flows. However, we only need to collect the relevant Physical Processes in that slot - we don’t need to re-define the flows.

The Reports Produced is indeed driven from the Information Representations. However, the connection between the Process and this information is a little subtle. The approach is that the Process produces the information via a supporting application and this view will show all information produced by the Physical Process and all its subprocesses via all the applications that are used to support each.
We define these using a couple of relationship classes. We can do this from either end - application and information or from the process end. In this case, let’s do it from the process.

1. From the Physical Process, we create a new instance of the Physical Process to Application to Information relationship, in the slot that is labelled: “Supporting Information”

2. From this new form, create a new Application to Information relation in the slot labelled “Information from Application”.

3. On this 3rd new form, select the Information Representation for the report that is produced in the “Information Used” slot and the Application that is providing that information in the “Application” slot. This Application_Provider, by the way, can be a spreadsheet, any scale of system or even a paper form if that’s what’s happening in the real world.

In terms of Automating Applications (those that fully automate the business process), there’s a specific slot on the Physical Process in which we capture these - “Physical Process Automated By”. However, you’ll notice that what’s here is not a complete application but the “function(s)” of that system. You can think of these as the functional components of the application in question.

The upstream / downstream systems for this particular view are quite detailed in terms of what they are using to determine this, in that it is evaluating the applications that update the data elements that are used to produce the information representations. This is certainly something that we’ve used with success but it requires a certain level of detail to be captured:

For the upstream applications (those that have contributed to the production of the Information Representation, either directly or indirectly):
For each of the relevant Information Representations it navigates the knowledge base as follows
Info Rep — consists of Info Rep Attributes—> Info Rep Attribute—uses—> Data Rep Attributes—updated by—> Application Function —provided by—> Application Provider

The downstream applications are those that are using the Information that is produced. Again, this particular View takes a high fidelity approach that does require some more complex modelling. What it does is to find all the Information that is CREATED by all of the Application Function Implementations that automate this process. (pause for breath!)
Then, it looks for all the Application Providers that consume this Information that is CREATED, that is, in their Application Provider to Information Representation relationship, they are marked as READing it. Note that this is also done at the Application Function Implementation level and then the ‘containing’ Application Providers of this set of functions are found.

With both upstream and downstream applications, both Application Providers and Composite Application Providers are returned BUT it filters out ‘integration’ solutions to only show those Applications that have been classified in the “Business Application” taxonomy.

(Note that we define the Update, Read, Delete or Create on that Application Provider to Information Representation relationship.)

We recognise that this particular part of the View requires some complex modelling but what it gives us is a very accurate view (pardon the pun) of what is going on in terms of the applications that are influencing the Information that is being reported and the systems that are using that. We get a lot of benefit and how we manage the complexity and scale of the modelling task is via spreadsheets and the Essential Import Utility, where we can automate the creation of these relationship classes.

It may be that you can find a way to capture enough of this to meet your needs in terms of getting the View working (e.g. create a single information representation attribute for each representation, connected to the relevant data attribute etc.), then you can use the View as it stands. However, our intention with these Views is to provide something that is hopefully useful out-of-the-box whilst also showing something of what is possible along with examples (you can see all the queries in the XSL) of how to approach this.

The idea of the Views is that they are quick to define and build so that you can show what you need to show your stakeholders, so it’s OK to take a copy and build your own variant of the out-of-the-box View.

If you need to show something a bit different (perhaps somewhat simpler) in terms of the Applications that are contributing to the creation of the Information Representations and the Applications that are consuming this, without all the data attribute aspects, then taking a slightly simpler approach with the modelling (you may already have everything that’s required) with an extended / modified version of this View would probably be a better way forward - certainly in terms of maintaining the content of the knowledge base model! And we’d be happy to help you with that.

I hope this have helped clear up a few questions without totally confusing things when it got to the Upstream / Downstream systems.

Jonathan
Essential Project Team
Richard
Posts: 7
Joined: 06 Sep 2017, 09:59

Greetings

how do you display workflow steps, being struggling for a while

Regards
Richard
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Hi,

Is your question about how to capture the workflow (process flow?) of a business process / business activity etc?
Or is it about how we render those within a View?

I hope my long post, above, explains most of the meta model rationale and how to capture these things. In summary, though, a Physical Process does not have a workflow or process flow associated with it. Rather, that is defined at the Business Process / Business Activity that the Physical Process is "realising". I can help to think of a Physical Process as really a relationship instance connecting the Business Process (Activity) with the Actor who is performing that process, whilst playing a particular role.

In terms of creating the flow diagram - which is about capturing the dependencies between the steps in the process - we have a graphical paradigm (very simple and neutral of any specific notations) for doing so, which the Views then use to generate a graphical rendering, e.g. using UML Activity Diagramming - but it could be any notation.

For many scenarios that are specifically about Workflow, these models provide the components to capture the workflows, including capturing the events that might trigger steps in the flow and the events that are raised during the execution of the flow. We associate the Roles that are required to perform each step with the definition of each process/activity that is used in that flow. Then, with the Physical Processes, we are then connecting the specific Teams, Individuals (using Group Actor or Individual Actor, respectively) to capture the facts that, e.g. "Team A performs this workflow".

If you have workflow technology in your organisation, this can still be captured in these process definitions. Any step in the process (each step is another Business Process/Activity, and each step in a Business Activity is either another Activity or a Task) can be performed by a team, individual or be fully automated by an Application. This Application might be a configured "flow" in a Workflow platform or any other application in your architecture.

Hopefully, the above helps but let me know more about what you need to capture, what you mean by "workflow".

Jonathan
Essential Project Team
Post Reply