en:app:010ini:0090offtea

Dashboard Office - Teamleader

Transaction OFFTEA

This transaction is the central element of the “Management Dashboard” module and provides an overview of the daily business of a team or department by means of various bar graphs and pie charts.

This transaction is particularly suitable for teamleader with a limited number of users and who are at least engaged in daily business part of the time.

In this 'dual' function, a teamleader must be able to identify which tasks were directly assigned to him (for instance, high-volume releases) along with the current workload of each individual team member assigned to him. If necessary, the teamleader will need to take control in order to avoid bottlenecks in resources owing to (un)planned absenteeism of individual users of his team and to redistribute business to other users or teams in the event of overload.

If “Service Level Agreements” (SLAs) were agreed with clients, then the teamleader needs to ensure that such SLA's are not violated.

A department head responsible for several teams within the organizational structure of the bank may use this transaction to obtain an overview of the daily business of the individual teams. If no group is selected in the “Group” field, then an overview of all user groups will be displayed.

If this transaction is registered as a start transaction in the user's profile, the system will automatically start the transaction after login. In order for this transaction to be used in a sensible manner, a permanent update process of data sets is necessary via the “Manager for interactive Queue Entries” transaction.


The transaction screen is composed of various diagrams.

In the “User Group” field, the user group of the registered user according to “User Profile” is defaulted. The users displayed in the diagrams are also the users assigned to this user group, whose login profile has additionally been released.

All elements of the bar graphs and pie charts contain hints that appear when the cursor points to a particular element.

The color coding of the user group and of the individual users is configurable. In the transaction “Maintaining User Groups” a color family may be selected for the user group in the “Color for Charts” field. In the transaction “Maintaining User Profiles” a color variant may be selected in the “Color” field from the color defined for the user group.

This setting causes all queue entries assigned to the user to be displayed in the defined color. If no color has been defined for a user, then these entries will be displayed in the diagrams in gray.

There are various types of “Selecting pending Queue Entries”, e.g. Incoming, Outgoing, Release, For Correction, or Diaries. If only queue entries of a certain type are to be assigned to a user, then an appropriate restriction may be defined to this end via the “Application profile” field in the “Maintaining User Profiles” transaction. For instance, the application profile may be used to ensure that a teamleader only receives queue entries of the type 'Release'.

Clicking on an element enables various transactions to be started or actions triggered. Which these are in each case is explained for each diagram in the following sections.

Top 5 To Do entries for the user:

This table displays the open queue entries assigned to the user logged in. Double-clicking an entry automatically started the processing transaction, and the user can process the queue entry directly.

Incoming Messages:

In this pie chart, the incoming messages from the user group (team) are shown along with the distribution to the individual users, with the external margin representing the sum total of incoming messages assigned to the team and the inner circle showing the assignment to the individual users of the team. The hint or clue contains information on how many messages are involved. Incoming messages that are assigned neither to a user group nor to a user are displayed as red elements in the pie chart.

Action when clicking an element: The transaction “Selecting pending Queue Entries” is started and the exact incoming messages of the team or the selected user are displayed that match the selection. These may now be viewed, forwarded or taken up and processed.

Entries in Progress:

In this bar chart, all queue entries are displayed that are ready for processing for the user group. Each queue type (e.g. Incoming, Paused, Release, For Correction or Diary etc.) is shown as a separate bar or column. If queue entries of a certain type are assigned to a user, then these will be displayed as a smaller or larger block within the bar graph, depending on the number of such entries.

The view in this graph is merely unit-related and provides information on the volume but not on the foreseeable processing time.

Action when clicking an element: The transaction “Selecting pending Queue Entries” is started and the exact queue types of the selected user are displayed that match the selection and may now be viewed, rerouted or taken up and processed.

Remaining Working Hours Today:

This bar graph shows the workload distribution of the individual users within the team. There is a colored bar graph for each user in the team that identifies the effort-related depiction of the individual queue entries and shows in the gray bar in the background how much working time is currently still available to the user for processing purposes. By comparing the colored bar (“what does the user still need to complete today”) with the gray bar (“how much time is still available to the employee today”), the teamleader is soon able to detect an overload and can intervene in a targeted manner. If the “Manager for interactive Queue Entries” is active, then the redistribution will be automated as far as possible.

In addition to the colored bar for the user's queue entries, there can also be a white bar. This designates queue entries that are already available today but are only scheduled for processing on the following business day. (For instance, these could be diaries if the transaction “Manager for interactive Queue Entries” was configured in such a manner that a queue entry is to be created for a diary x days before the date of the diary in question).

Action when clicking an element: The transaction “Queue Handling” is started and the exact queue entries to match the selection are displayed for the user selected. The teamleader can now assign queue entries to some other user or user group. Irrespective of whether the “Manager for interactive Queue Entries” is active or not, the teamleader can proactively redistribute individual queue entries. These are then designated as having been manually redistributed and are no longer redistributed automatically.

The times provided for processing of a queue entry are derived from the basic times set in the “Maintaining System Configuration”. If nothing else is defined, these times apply to each business transaction processed. If a more detailed definition of processing times is required, then these settings can be specified in the “Maintaining Service Level Agreements” transaction.

Determining working time:
The working time available to the user today is derived from the following settings:
In the transactions “Maintaining Entity Groups” and “Maintaining Entities”, the usual daily working times of an Entity Group/ Entity can be defined. These also apply to the individual users of this entity unless otherwise defined in the user's profile. For part-time employees or users who are not engaged in the department 100%, it is recommended that the relevant working times be defined in transaction “Maintaining User Profiles” so that the workload distribution to these employees can be made in line with the working time available.

In addition to the 'usual' office hours of the bank or the working times of the user, the application also takes account of (un)planned leaves of absence of a user owing to illness/vacation or advanced training. These can be recorded in the “Maintaining User Absence” transaction. This transaction can be started by clicking the user code in the 'Remaining Working Hours Today' diagram.

If there are more than 10 users in a team, then the display of entries per user becomes difficult to follow. Accordingly, it is recommended to make appropriate team allocations.

SLA Check:

This bar diagram shows the work orders of a user group ranked according to urgency.

For each work order (order set) there is a target time that may be derived e.g. from a customer order placed, with which a “Service Level Agreement” (SLA) was arranged or the diary date has been reached.

The SLA Check is reflected in the bar graph in the colors green, yellow and red. “Green” shows non-critical work orders that can be processed according to schedule. “Yellow” designates work orders that are critical and in danger of being violated, and “red” shows those work orders that are past due.

The report data on which the individual diagrams are based is configured via the “Maintaining Chart Definitions” transaction. A test of the chart configuration is possible via the “Test Chart System” transaction.

Transaction Panels

Team



Datafields

Datafield Description
External Key cf Appendix A, Table USG field EXTKEY
Streamgrid To do List This streamgrid shows the queue entries of the user(s)/ user group(s).

The list of results can be filtered by using the above checkboxes and the 'settings' icon.


Acknowledgment



Datafields

Datafield Description
External Key cf Appendix A, Table ACK field EXTKEY
Object Type cf Appendix A, Table ACK field OBJTYP
Object INR cf Appendix A, Table ACK field OBJINR
Sub-ID for Object (e.g.SMHINR) cf Appendix A, Table ACK field OBJSUB
Sending Service cf Appendix A, Table ACK field OUTSRV
Service for Incoming Acknowledgment cf Appendix A, Table ACK field ACKSRV
Class of ACK (in the Object) cf Appendix A, Table ACK field CLA
Status cf Appendix A, Table ACK field STA
Additional NACK Information cf Appendix A, Table ACK field NACSTM


Diary Details Panel



Datafields

Datafield Description
Transaction to be Called cf Appendix A, Table DIA field FRM
Coded Reason cf Appendix A, Table DIA field COD
Entry Done (Nonspace = Entry Done) cf Appendix A, Table DIA field DONFLG
Diary Date cf Appendix A, Table DIA field DAT
Name cf Appendix A, Table DIA field NAM
Infotext cf Appendix A, Table DIA field INFTXT
Responsible User cf Appendix A, Table DIA field OWNUSR
Responsible Group cf Appendix A, Table DIA field OWNUSG
Entered by cf Appendix A, Table DIA field USR
Automatic Processing cf Appendix A, Table DIA field AUTFLG
Do not automatically set to Done cf Appendix A, Table DIA field DELNOTFLG


en/app/010ini/0090offtea.txt · Last modified: 2023/01/02 19:42 (external edit)