In this blog I will provide an overview on the IS-U workflow design highlights, illustrating very high level functional and technical sides of the workflow design. There are many resources, wikis, and SAP Help documents readily available that provide deep-dive insights on the technical aspects of the workflow implementation. I will site some useful links as necessary.
Before we proceed further, please read this fine print. All the views provided below are my personal opinion and doesn't necessarily reflect my employer's. I work for my employer as a Consultant with a focus in Utilities Industry but every customer's requirement is unique and you should definitely seek for professional opinion before making your business decisions. Treat the inputs in this blog series as just opinions, nothing more, nothing less.
With the Business workflows, SAP enables to co-ordinate the business process flows across different application within an IS-U implementation. A workflow is a model of specific set of business activities that are performed in background or acted upon by a user or set of users called Agents. Automating the set of business process is the primary motivation behind setting up and designing the workflow system.
Few rationales behind choosing a workflow design to achieve the desired business process flow in an IS-U/ CCS implementation:
Rationale |
|
Functional Modelling
During the blueprint phase, the business processes are defined and the activities within the processes are established. The functional area such as Front Office, FI-CA, Device Management, Billing and Plant Maintenance etc. defines these activities required within the processes. These sub-processes are then mapped in the workflow as tasks/activities, which can be executed in sequential or parallel based on the desired design functionality. The workflow thus essential consists of these tasks/activities that overlap among different functional areas and that are executed in background or involve agent interaction from different departments.
The above are a representative steps in the Business process with their functional category. The steps and the corresponding category may differ depending upon the Business processes, design facets and the team structure.
The organizational structure and hierarchy determines the Users/Agents involved in the workflow processes so that the workflow tasks get appropriately assigned to the staff members of the respective department. If the Organizational Management component is used for HR purposes, then the same plan and structure can be used for Workflow user assignment.
Based on the defined roles and the user hierarchy, the workflow tasks get directed to the user inbox automatically, notifying the Supervisors/ Leads on the task assignment. The appropriate level of access and authorizations are set for the Supervisor and the User.
An example workflow – Technical Perspective
In an actual design the workflow incorporates many more steps and handles special cases and scenarios with complex use of conditions, forks, steps and activities as per the Business design.
Standard Workflow templates:
Standard workflow templates could be used as starting point in the workflow design. SAP provides with a list of standard workflow templates that could be copied, adjusted or enhanced further to meet the Business requirements.
Transaction: PFTC (Tools -> Business Workflow -> Development->Task). F4 help on Task Name and view the list of workflow templates under the Application Components. Workflows specific to IS-U Application can be found by searching ISU* in the task name.
SAP recommends the copy and adjustment of the templates for implementing the workflows. The steps for the procedure can be found in the SAP help link Adjust/Copy Workflow Template.
BORs: Business Object Repositories
SAP provides IS-Utilities specific business object types, interface types, methods and events defined and described in the Business Object Repository (BORs). BORs can be accessed through transaction SWO1 (Path -> Tools ->ABAP Workbench->Overview->Business Object Browser).
Some of the objects that are regularly used during the IS-U implementations:
BILLDOCAUT | DEVLOC | ISUCONTACT | MOVEINDOC |
BILLINGDOC | DISACTION | ISUCONTRCT | MOVEINOUT |
BUDBILPLAN | DISCONNECT | ISUCRMCNCT | MOVEOUTDOC |
BUDBILPLNH | DISCOUNT | ISUDEVINFO | MTRREADDOC |
CCPSJUMP | INSTLN | ISUPARTNER | MOVEINDOC |
CONNOBJ | ISUACCOUNT | ISUSDORDER | PORTION |
DEVICE | ISUACCTCLS | ISUSERVICE | PREMISES |
DEVICETYPE | ISUADDRESS | ISUSMORDER | PRICE |
PRINTDOC | RATE | RATECAT | ……. |
More standard SAP delivered BORs can be found in the transaction SWO1 (Tools →ABAP Workbench → Development→ Business Object Builder); under the application Components IS-U (SAP Utilities).
Events
The Business Objects are provided with components called Events. Events can be defined as trigger points within the object and in many cases represents the state of the object at a given instance.
For example, the MOVEINDOC object has specific events whose functions identify the state of the MOVEINDOC.
Object Type | Event | Function |
MOVEINDOC | Created | Move-in document created |
MoveInDateChanged | Move-in date changed | |
Cancelled | Move-in document cancelled | |
BudgetBillingPlansFailed | Budget billing plan could not be created |
.
When the Move-In process is initiated, standard programs in SAP handle the trigger of the events.
There are scenarios where the standard objects does not suffice the implementation requirements, in such cases
- The standard object can be enhanced by adding new Events, Methods, attributes etc. SAP provides the Delegation mechanism, technique of replacing an original object type by its subtype to which additional events may be added. SAP does not allow changes to the original objects types rather Delegation should be used.
- Custom Objects (SWO1) can be implemented with the required methods, events.
- Custom Class (SE24) Objects can be implemented with the required functionality.
Event Firing
Standard SAP code fires the events for the Business Objects state change during the processes. Events can also be fired through custom codes during the workflow design. Custom events are triggered when there is a change in the state of the object.
As example, when the customer makes a payment, FI-CA exits (events) executed during the run of the Payment transactions FP05 or FP25 can be used to fire the workflow event and initiate the Reconnection workflow.
An event can be triggered using the function module SWE_EVENT_CREATE or SAP_WAPI_CREATE_EVENT. The SAP Help link elaborates on the creation of the customer specific event creations Event Creation.
Workflow-Event linkage
Workflows are linked to the events and may be triggered in reaction to an event. As the event is fired, a workflow maybe initiated, cancelled, terminated or continued. For example when a MOVEINDOC- CREATED event is fired, the Move-in workflow is triggered and initiates a welcome letter to the Business Partner as one of the process.
The linkages between the Workflow and the Business Object / Class event is established in SAP through event linkage configuration in transaction code SWE2. The configuration requires the Object and event details and the Workflow is linked to the event as a Receiver.
The relevant entry gets created in the event linkage table when a workflow is defined in the workflow builder transaction code SWDD (Workflow Builder). However, for customization purposes, we may create or change entries in the linkage table. More details on the event linkage and configurations can be found in the SAP help Using Linkages.
Workflow Development
Relevant tutorials and details workflow development workbench can be found in the below SAP help link: Business Workflow - Tutorials
Agent Determination for Notification
Business tasks within the workflow involve User actions for the execution of certain processes. Agent determination is a significant step to determine the User or set of users involved in the undertaking the actions on the tasks. Agent determination and integration with workflow provides means for assigning work items to organizationally suitable employees, in addition responsibilities and authorizations are managed efficiently, and bottlenecks are avoided.
SAP provides the mechanism of Rule and Role Resolutions for agent determination and the easy integration with Business workflows. When defining the single step tasks in the workflow it requires specifying the particular agents or recipients by their role in the following instances:
- Agent for task
- User Action
- Wait Steps
Other instances such as recipient on completion of task, missed latest start date, missed end date etc. requires assignment of possible agents. Specifying a role or rule is just one of several methods that can be used to specify the agents responsible and the recipients. Below drop down lists the options in binding with the workflows.
SAP help below details the Role and Rule resolutions: Rule Resolution, Role Resolution
The Organization structure, hierarchy and responsibilities are few of the factors considered in defining the Roles and in identifying the set of users to be mapped for a specific task.
As examples,
- A group of Collections Representatives would receive the notifications for Dunning during the Disconnection and Reconnections or Move-In processes.
- Device Management and Plant Maintenance admins would receive the alerts for Service Notifications.
Workflow: Error Handling
As the workflow executes the tasks in the background or agent mode, often it encounters errors and these errors have to be appropriately handled. Various error handling mechanism provide tools for further analysis and monitoring. The following depicts possible ways of handling/monitoring workflow errors in IS-U settings:
EMMA/ BPEM cases provide one-stop shop for handling errors and exceptions in the business process. It further provides means for statistical information, case management and error analysis.
ECRMREPL is another possible lookout for errors in the business process that involves workflows. This transaction provides good leads for failure analyzing the processes initiated out of CRM.
In the force-out scenarios from the CRM system, often the contract account or Installation gets into locking in ECC when Move-In and Move-Out workflows in ECC and BDOCs in CRM attempts to change the objects at the same time. The BADi ECRM_CRM_DOWNLOAD in ECC provides few methods that could be used effectively for the Move-In/ Move-out and CRM system
Email Notification is a common mechanism of notifying the users of the relevant department with the appropriate messages for the workflow step failure. It becomes essential to define the user roles and authorization depending upon the desired hierarchy structure in the organization.
Workflow: Monitoring
SAP workflow development tools provide extensive list of transaction codes for Workflow Monitoring and Performance Analysis.
There are online resources and wikis available on these topics put by experts.
http://wiki.scn.sap.com/wiki/display/ABAP/Useful+Transactions+in+SAP+Workflow by Chidanand Chauhan
Post implementing the workflows it becomes essential to monitor the SAP workflows and manage the exceptions and failures and to ensure smooth running of the Business processes.
Logs and traces provided by SAP help in monitoring the status of the workflow, appropriate delivery of the notifications to the staff members/ users, actions taken on the notifications. A workflow Administrator regularly monitors the workflow logs (SWIA); the Event traces (SWEL - switched on only when necessary) and notifies the appropriate IT department leads on the workflows that are not processed successfully.
The role setup as per the organization structure helps ensure that the deadlines are not missed and the supervisors are appropriately informed. The logs provide the list of possible agents for acting on a task.
- SAP Managed Tags:
1 Comment