Summary
Web Process Designer environment is too complex to create a process for a persona with limited technical skills. There is a need for a much simpler No Code tool to configure workflows from pre-defined project-specific components that can be used by someone from Line of Business with no technical skill nor BPMN expertise.
The WorkStream capability of IBM BAW would be in the spirit of what would be required here, but is way too limited to implement the typical workflows that are considered by BPCE.
Note: the requirement described here is high level summary of what would be a No Code environment to create the workflows that BPCE needs. A much more detailled analysis would be required to fully specified the functionalities we would expect from such a tool.
Context
BPCE is using IBM BAW as the foundation for their new Workflow system with the objective to implement their business workflows and orchestrate work from their agents.
A customer request is handled by an instance of a given process which orchestrates the tasks that need to be performed to process the customer request.
Although standard BAW tools are usable by skilled engineers to implement their core business processes, BPCE has 3000+ simpler workflows to build. The vision is to let non-technical people being in charge of configuring these workflows reusing project-specific artifacts (widgets wired to their backend-systems for instance, specific task actions…), listing and configuring the tasks specific to these workflows in a No Code environment with a simple user experience.
A video (in French) of the current system that has been developed specifically is available to illustrate what simple User Experience and No Code means in the context.
Business Requirement
Persona
The target user for such a tool is a person working in a branch of a bank who is in charge to define the workflow that might be specific to his branch or group of branches. He/she is not a technical person and would not be familiar with BPMN or some other process-specific formalism. He/she can use No Code parametrization tools for which he/she would have been trained. The tool would have been configured to expose notions he/she is familiar with in his/her domain.
Management and creation of Workflows
The No Code interface allows a non-technical user to see the workflows that have already been created and to create a new workflow.
Workflows can be organized in domains and sub-domains (similar to the context of folder).
A workflow is in a specific domain controlled by access control rules. A specific access right allows workflow authors to see and create workflows in their domains.
Typical management operations like copying, moving, deleting, exporting, importing… workflows are expected.
The workflow is given an identifier, a name and a description. In BPCE context, a workflow is associated to a specific action that needs to be taken following a customer request. For instance, a customer may request to transfert money to an account outside Europe. A workflow is required to orchestrate various tasks that need to happen to proceed with the transfer. Task can be dispatched to organizational entities and people who need to perform these tasks with their proper job role and access rights.
Workflows might have properties that could be defined globaly. For instance, a workflow could be assigned a “type” (“internal” or “external”), a ”request type” (“collaborator”, “customer”, “non-customer”…), a “time horizon” (how much time the workflow should be archived)…
A workflow is composed of an ordered list of Tasks
Management and creation of Forms
Some context needs to be provided for a given workflow. The context is a set of Data that need to be attached to the workflow. A form associated to a workflow allows to capture data at workflow level and correspond to data available to all tasks.
Forms are defined by the user in charge of creating the workflow. It is represented as a graphical user interface with input fields that allows to input data elements. For instance, some field in a Form can be used to input the customer identifier, his account number etc…
Forms are defined with a simple configuration user interface that allows to add input fields of different types, organize them in sections and position them in the form canvas.
Some input fields are generic, like text fields, phone numbers, drop-downs… Some might be specialized, for instance drop-downs list to select an account among the list of account of the selected customer.
Some elements of a form can be associated to a data source. This data source can be a connection to an external system configured to bring data back from the system or a static data set configured in a CSV file.
Forms can include a section in which documents can scanned and attached to the form.
Management and creation of Tasks
A workflow is made of an ordered list of tasks. Tasks can be regrouped in more granular “steps”. For instance “File Validation” can be a step with “Check ID”, “Check credit history” beeing Tasks in this step.
In the context of a Workflow, the user can define steps and tasks. A Task can be mandatory or optional. A Task can be assigned to an Organization. At runtime, the task will be dispatched to or will be claimed by a participant which is part of this organization. A Task can be flagged to be automatically assigned when it is triggered.
A Task has a type. The list of available task types can be configured.
A Task has a instruction property used to give instructions to the participant who will be assigned to the task.
A Task might have a deadline and an expiration date. A task for which the expiration date is reached might trigger the closure of the workflow.
A Task has start conditions. It can be started when a previous task is completed and/or according to some conditions. Conditions are task management rules that are defined as boolean expressions using the workflow and task variables.
A Task has a list of Actions. Actions can be automatic actions that are triggered when the task is started or manual actions.
An action can be configured and associated a Form that allows to capture data and trigger specific actions.
The definition of tasks and actions described here is a subset of what the final tool would support. For instance how tasks are delegated or transferred between participants, how tasks are claimed or assigned by a supervisor, is not described in this document.
Testing, versioning and deployment of workflows
Once the user has finished to configure a specific workflow, he would like to test it in a SandBox. He would instantiate the workflow on a fictive customer request and would simulate the dispatch and execution of the tasks. The side effects of the workflow would be controlled to not impact real systems and databases.
The workflow system is supposed to send notifications to participants who have been assigned task and to the initiator of the workflow. In test mode, all notifications are sent to the user who is testing the workflow and all tasks are assigned to him whatever the assignment rules that have been defined.
Once the workflow has been tested, the user would like to assign a version and make it available in the list of deployed workflow so that end users can create instances on specific customer requests.
Running a workflow
Once deployed, an agent of a bank can select a specific workflow and initiate it on a customer request. The agent would be presented the Form associated to the workflow to capture data related to the customer request. The completion of the form is triggering the workflow and task instances are created and dispatched to the different organizations impacted by the request. Each organization and staff in this organization have an inbox of tasks to be performed.
A supervisor can select a task and assign it to a member of his staff. An employee can claim a task to complete it.
The initiator of a workflow would be notified when the workflow is completed. He could also check the status of the workflow, see the pending task, remind the different participants of delayed tasks.
What is IHM? Please expand on what you are asking for.