MM
I'm looking for some advise on whether it's best practice to have a system task in a customer lane. The scenario is the customer is going online to apply for something, so in my process, the customer step through a screen flow of the question sets. Some questions are display based on the customer's profile and the determination is done in the back ground by the online system. I represent that determination with a system task, instead of doing a throw and catch to the pool that own the system.
What is our thought on this, is this a no-no because the system does not belong to the customer? or is this process, an exception to the rule?
Hello,
What is your goal of modelling? Are you modelling a workflow process?
If so, "customer application" is a single user task, because I imagine the customer works on this application in one go (even if it is multiple screen pages). Your implementation of the user task will use some backend services (possibly upon switching from one questionnaire page to the next or even within the page for looking up something, searching the catalogue etc.). But I would not model screen flows as separate user tasks.
If you are just loading some data from the customer profile, which your user task is supposed to work with during the "interview", you could load the customer profile in a system task before the user task and do the technical processing of the "customer application" after that user task. No problem with placing them in the lane of the user unless you have special technical conventions to obey. You recognize by the type "Service task" that it is not the user doing anything there.
Personally I think BPMN is not very suitable for describing screen flows. Modern user interfaces are too flexible. The idea of a description as a process is not adequate there. Consider the user interaction as "atomic" from a business point of view. Maybe assign some screen navigation model to the user task in order to add descriptions of your screens within the user task.
Thank you for your reply M.
The goal to provide enough information about the customer interaction with a department, it may be via face to face or using the online portal to service their needs.
Can you please explain what you mean when you refer to a "customer application"? Are you suggesting that a 'Customer Application' lane is added to customer pool?
I also like your suggestion of assigning the customer to a screen navigation model, what model type would you recommend to use this screen navigation model?
Hello Muy,
your case was "the customer is going online to apply for something". That's what I call the "Customer application" - you will be more specific what the actual "something" is. So the name of the user task will be something like "<something> application" or "Apply for <something>", whatever your naming convention is.
You place the user task in the Lane "Customer" or "Applicant" or whatever you call that role. In the Function allocation diagram assigned to your user task you could associate a screen object "<something> application" with the task. And to that object you can assign either "Screen navigation" model type, which gives you an overview of your screen flow or directly a "Screen design" model. In the latter one you can do a bit of rough lay-outing of your screen and associate functionalities with your screen elements or data elements displayed and to be entered. See the attached examples. Some ARIS users also change the symbols of the UI objects to resemble real UI elements and get an even better layout impression in the "Layout" column of the screen design model.
Enterprise BPMN Collaboration diagram:
Function allocation diagram assigned to the first user task. Contains a Screen symbol representing your wizard.
Screen navigation model showing the context how you navigate between the screens of the wizard.
Screen design model connecting UI elements (center) with data attributes (left) and functionalities (right). Data attributes may occur in data models, the functionalities may be collected with the application as to be implemented features.
If you only have one screen, you may omit the screen navigation model.
