Manage Operations For SAP For Retail - Workforce Management 3.0

BP_MO_for_SAP_for_Retail_Workforce_Management_V30.doc 22.04.
2009
Best Practice
Manage Operations for SAP for Retail
Workforce Management 3.0
Dietmar-Hopp-Allee 16
D-69190 Walldorf
CS STATUS
customer published
DATE VERSION
Dec-13 2008 3.0
SOLUTION MANAGEMENT PHASE SAP SOLUTION
Operations & Continuous Improvement Best Practices for Solution Operations
TOPIC AREA SOLUTION MANAGER AREA
Application & Integration Management Business Process Operation
Best Practice
Manage Operations for SAP for Retail Workforce Management
2009 SAP AG - BP_MO_for_SAP_for_Retail_Workforce_Management_V30.doc page 2/77
Table of Contents
1 Management Summary 4
1.1 Goal of Using This Best Practice 4
1.2 Alternative Practices 4
1.3 Staff and Skills Requirements 4
1.4 System Requirements 5
1.5 Duration and Timing 5
1.6 How to Use This Best Practice 6
1.7 Best Practice Procedure 6
1.7.1 Preliminary tasks 6
1.7.2 Monitoring concepts 6
1.7.3 Business Process Monitoring in SAP Solution Manager 7
1.7.4 Monitoring types for Business Process Monitoring in SAP Solution Manager 8
1.7.4.1 Application monitor 8
1.7.4.2 Background job 9
1.7.4.3 ABAP dump collector 9
1.7.4.4 Dialog performance 10
1.7.4.5 Application log 12
1.7.4.6 Analysis and monitoring tools 13
1.7.4.7 Monitoring activities 14
1.7.4.8 Notifications 15
1.7.5 Business Process Monitoring process 17
1.7.6 Legend 17
2 Business Process Monitoring for Workforce Management 18
2.1 Sample WFM Scenario 19
2.2 Business Process: Employee Maintenance 19
2.2.1 Business process step 1: Personnel actions/receiving employee master data 20
2.2.1.1 Description 20
2.2.1.2 Monitoring requirements 21
2.2.1.3 Monitoring objects in SAP Solution Manager 22
2.2.1.4 Further monitoring objects 23
2.2.2 Business process step 2: Maintain employee profiles 23
2.2.3 Business process step 3: Maintain work areas and qualifications 27
2.2.4 Business process step 4: Maintain schedule rules 29
Best Practice
2.2.5 Business process step 5: Maintain time-off requests 32
2.2.5.2 Monitoring requirement 32
2.3 Business Process: Business Forecast and Workload Modeling 34
2.3.1 Business process step 1: Adjust actual volume data 35
2.3.2 Business process step 2: Performing the initial forecast calculation 38
2.3.3 Business process step 3: Update volume forecast 44
2.3.4 Business process step 4: Apply budgetary constraints 48
2.3.5 Business process step 5: Approve forecast 54
2.4 Business Process: Scheduling 56
2.4.1 Business process step 1: Scheduling creation 58
2.4.2 Business process step 2 and 3: Scheduling maintenance and analysis 65
2.4.3 Business process step 4: Schedule posting 72
3 Further Information 74
3.1 Troubleshooting 74
3.2 Related Best Practice Documents 74
Index of Figures 75
Index of Tables 76
Best Practice
1 Management Summary
1.1 Goal of Using This Best Practice
This Best Practice helps you set up a Business Process Monitoring concept for your SAP for Retail Workforce
Management solution. The concept aims at defining procedures for business process-oriented monitoring and
error handling, and escalation procedures for your Employee Maintenance, Forecasting and Scheduling
business processes. These procedures intend to ensure a smooth and reliable flow of this core process so
that your business requirements are met.
This Best Practice gives orientation for defining suitable application-oriented monitoring objects in order to
detect any irregularities or deviations from an ideal business process flow or to detect error situations
concerning a core business process at an early stage.
This Best Practice follows the recommended approach of SAP to use SAP Solution Manager for monitoring
functionalities whenever possible. But even if you do not use SAP Solution Manager we recommend to follow
the procedures described in this document as much as possible in order to ensure a smooth and reliable flow
of your business processes as well as an appropriate response in case of unforeseen errors.
1.2 Alternative Practices
You can have SAP experts deliver this Best Practice on-site by ordering an SAP solution management
optimization (SMO) service for SAP business process management (BPM). This service is exclusively
available within SAPs support engagements SAP MaxAttention and Safeguarding. If your company currently
does not have any support engagement with SAP, it is also possible to get assistance by SAP experts from
SAP Consulting. In this case, please contact your local SAP Consulting representative.
1.3 Staff and Skills Requirements
To implement this Best Practice, you require the following teams:
Appli cation management team
This team creates the ERP Business Process Monitoring concept and consists of experts from several areas
of your company:
Business department
Solution support organization (for example basis support or application support)
Implementation project team
Busi ness process operati ons team
The business process operations team will be responsible for applying the resulting procedures derived from
implementing this Best Practice. It includes the following groups:
Persons designated to perform business process-oriented monitoring and to ensure that the process runs
smoothly (e.g. the business process champion for each business process)
All parties in your solution support organization and IT department involved in monitoring focused on the
application aspects (application support, development support, job scheduling management)
Best Practice
SAP technology operations team
This team comprises all those in your solution support organization and IT department involved in monitoring
focused on the system administration side (program scheduling management, software monitoring team,
system administration team including the system administrator)
Busi ness process champion
The business process champion is a person in the business department that is responsible for the successful
execution of a given business process. He or she coordinates all activities necessary for the business
process and, therefore, is usually responsible for the escalation paths in case of problems. Often this role
serves as a second level in the escalation procedure if the application monitoring team needs to escalate an
issue.
More information about roles and responsibilities of these teams can be found in the super-ordinate Best
Practice for General Business Process Management, which you can obtain through SAP Solution Manager or
the SAP Service Marketplace, quick link / BPM.
Necessary or useful trai nings
SM300 Business Process Management and Monitoring
E2E300 End-to-End Business Process Integration and Automation Management
EP120 SAP Enterprise Portal Development
1.4 System Requirements
In order to monitor business processes running in your SAP for Retail solution via SAP Solution Manager, the
SAP Basis release of the systems to be monitored has to be at least 4.6C. To have all described monitoring
objects available in SAP Solution Manager, the add-on ST-A/PI01L has to be installed on the SAP for Retail
system.
1.5 Durati on and Timing
Durati on
Creating a Business Process Monitoring concept can take approximately one week per business process.
Implementing the Business Process Monitoring concept might take approximately another week.
Timing
The best time to apply this Best Practice is during the planning phase or during the implementation phase of
your SAP solution.
Best Practice
1.6 How to Use This Best Practice
Here you find a brief description of how you should proceed in using this document:
Read through the Best Practice for General Business Process Management, available on the SAP Service
Marketplace. The document explains the procedures to be used to create a general Business Process
Management concept. This includes the definition and documentation of the core business processes,
definition of monitoring objects, definition of monitoring activities including error handling procedures,
monitoring tools and monitoring frequencies, the definition of communication and escalation procedures and
the assignment of responsibilities.
At the beginning of chapter 2 you will find a typical flow chart of the core business process explained in this
Best Practice. It is intended to be used as a guideline for writing down your company-specific process
documentation.
In chapter 1.7.4 you will find further information relevant for more than one scenario. In case information from
the generic part is relevant for a specific business process step in one of the scenarios, you will find a clear
link to the corresponding chapter of the generic part.
1.7 Best Practice Procedure
1.7.1 Preliminary tasks
Before performing this Best Practice, ensure that you perform the following preliminary tasks or checks in the
system:
Complete all installation and post-installation actions and procedures, including customizing
Ensure that the initial download has been successfully executed
Apply all SAP recommendations from SAP service sessions and any SAP recommendations resulting
from customer problem messages
Implement all current SAP support packages upon availability
1.7.2 Moni tori ng concepts
The monitoring procedures proposed for each business process step are the core of this Best Practice. The
monitoring procedures help you ensure that the technical processes meet the requirements for stability,
performance and completeness. These procedures cover the monitoring for five areas:
Error monitoring
Performance monitoring
Throughput monitoring
Backlog monitoring
Data consistency monitoring
For each of the business process steps, you will find the following information:
A detailed functional description of the process step
Identifiedmonitoring requirements for the process step
Defined monitoring objects, alerts and selection criteria
Description of error handling procedures and restartability
Best Practice
General monitoring activities that are valid for all or most scenarios are described in the generic part in
chapter 1.7.4. Recommendations for performance monitoring can also be found in this chapter. The
performance of the most important steps of your core business processes should be monitored on a regular
basis. The monitoring procedure for performance monitoring of all steps that are executed in an SAP for
Retail Workforce Management solution is generally the same. Therefore, you will only find specific
performance monitoring recommendations on selected business process steps.
1.7.3 Business Process Monitoring in SAP Solution Manager
Business Process Monitoring (BPMon), as part of Solution Monitoring means the proactive and process-
oriented monitoring of the most important or critical business processes, including the observation of all
technical and business application-specific functions that are required for a steady and stable flow of the
business processes.
The core business processes that are implemented in an SAP for Retail Workforce Management system or
other software and operated by a company are of particular importance, and Business Process Monitoring is
intended to ensure a smooth and reliable operation of the business processes and, thereby, that the core
business processes meet a companys business requirements in terms of stability, performance, and
completeness. SAP Solution Manager provides a graphic to visualize a companys (distributed) system- and
solution landscape and all related business processes. By using Business Process Monitoring, it is possible
to define and customize alert situations from the basic set of configurable alerts provided by SAP Solution
Manager. These alerts are then visualized as green, yellow and red alert icons for each individual business
process step in the graphical business process representation. Business Process Monitoring is intended to
detect critical situations and respond to them as early as possible in order to solve problems as fast as
possible.
SAP Solution Manager also offers extended functionality for error handling and problem resolution. By the
definition of contact persons and escalation paths, Business Process Monitoring can be integrated into the
companys overall strategy for business process management and solution management within their solution
support organization.
In general, Business Process Monitoring includes the solution-wide observation of:
Business process performance (key performance indicators)
Background jobs (Job Scheduling Management tasks)
Business application logs (such as any error log, general application log, due list logs, etc.)
Data transfer via interfaces between software components
Data consistency
Technical infrastructure and components required to run the business processes
Required periodic monitoring tasks
For further details on Business Process Monitoring, please refer to http://service.sap.com/bpm.
Best Practice
1.7.4 Moni tori ng types for Business Process Moni toring in SAP Solution Manager
Monitoring types are part of the functional scope of Business Process Monitoring as it is available in SAP
Solution Manager. The below mentioned monitoring types are available:
Application monitor (throughput and backlog indicators, interface monitoring, data consistency checks,
mass activity monitors, due list log, MRP key figures, user exit)
Background jobs (jobs running on SAP systems with an SAP basis)
Dialog performance (dialog transaction performance)
Update error (V1 and V2 update errors from SM13 for specific transactions and programs)
Due list log (messages for deliveries and billings)
Application log (messages from the application Log SLG1)
Document volume (based on table call statistics in ST10)
Other CCMS monitor (all alerts that are configured in the CCMS alert monitor)
Depending on what is executed during a specific business process step, the relevant monitoring types must
be selected. In order to receive detailed information on how to set up the monitoring objects in SAP Solution
Manager, please refer to the documentation available at http://service.sap.com/bpm. In the following
chapters, monitoring types that are relevant for this Best Practice document are introduced shortly.
One prerequisite for setting up Business Process and Interface Monitoring inSAP Solution Manager is that all
business processes and business process steps are maintained in the respective solution that contains all
affected system components. If you want to learn more about how to set this up, please turn to
http://help.sap.com SAP Solution Manager Basic Settings.
1.7.4.1 Application monitor
The application monitor is just one of many different monitoring types within the Business Process Monitoring.
The latest monitoring objects are only provided if the latest ST-A/PI plug-in is installed on the satellite system.
The service tool for ST-A/PI is available via the SAP Service Marketplace quick link / i nst al l at i ons
Entry by Application Group Plug-Ins SAP Solution Tools ST-A/PI.
Please ensure that ST-A/PI is installed on the SAP Solution Manager system and on the respective
satellite. In case of problems refer to SAP Note 915933.
The throughput and backlog indicator functionality available as of ST-A/PI 01J * is only working properly
with ST-SER 700_2007_1. This is due to changes in the underlying architecture.
More detailed information about the different application monitor functionalities and a detailed description on
how to define self-written monitoring collectors for the user exit are explained in the following documents
respectively (http://www.service.sap.com/ Alias BPM Media Library):
Setup Guide Application Monitoring
Setup Guide Interface Monitoring
Setup Guide User Exit
Best Practice
1.7.4.2 Background j ob
The background job monitoring should be part of a Job Scheduling Management concept. Go to
http://service.sap.com/solutionmanagerbp, topic area Business Process Operati ons to find the Best
Practice for Job Scheduling Management. Because of several restrictions regarding background job
scheduling, e.g. time restrictions, restriction of hardware resources (CPU, main memory, ), or existing
dependencies between different activities (e.g. invoices can only be created after the corresponding goods
issue is posted, or backorder processing and material requirements planning should not run at the same time)
it is very important to ensure the stable run of background jobs. A cancelled background job should be
identified as soon as possible in order to react as fast as possible. Therefore it is also necessary to define
restart procedures and escalation paths.
Monitoring obj ects
Before setting up monitoring, the monitoring objects must be clearly defined. A monitoring object is a single
background job or a group of background jobs. There are four different possibilities to identify a special back-
ground job or a group of background jobs. This information needs to be maintained in the sub-node
Background Job below a business process step.
A detailed description of what kinds of alerts make sense or what kinds of alerts are possible is provided in
the Best Practice for Background Job Monitoring with SAP Solution Manager document, which can be found
on the SAP Marketplace http://service.sap.com/solutionmanagerbp, topic area Business Process Opera-
tion.
1.7.4.3 ABAP dump collector
The dump collector provides monitoring features for alerting on occurrences of ABAP dumps of specified
runtime errors and collects statistical data of ABAP dumps for reporting reasons.
Monitoring obj ects
The monitoring object is an ABAP runtime error. This runtime error can be specified via the runtime error
name, the user who is responsible for the runtime error, the client on which the runtime error occurs or the
program that leads to the runtime error.
Monitoring alerts
Possible alert types are the Number of ABAP Dumps (Delta) all dumps since the last collector run and
Number of ABAP Dumps (Reporting) all runtime errors of specified type, client and program for this day or
for the previous day.
Best Practice
Figure 1: Alert type Number of ABAP Dumps (Delta)
1.7.4.4 Dialog performance
Dialog performance implies the monitoring of the dialog transaction performance of any transaction in the
SAP system. This can be a standard transaction or a custom-developed transaction.
Monitoring obj ects
The monitoring object is the transaction itself. The customizing has to be done in the Dialog Performance
node. The Transactions table lists all transactions that are already configured to that business process step.
The relevant transactions need to be selected for monitoring. It is also possible to add or to remove
transactions within the Add/Remove Transactions table. The monitoring can be performed per SAP
instance. To this end, select the respective instances in the SAP Instances table, which lists all instances that
are maintained for a system. The Alert Types table shows the dialog response time and all parts of the
response time that can be monitored, like queue time, load and generation time, database request time and
the front-end response time. Select those times that are relevant for monitoring. After saving this node, a sub-
node Performance Alerts will appear where you can enter the threshold values.
Best Practice
Figure 2: Monitoring objects Dialog performance
Monitoring alerts
Each table in the Performance Alerts sub-node corresponds to an alert type chosen in the higher-level node,
and lists the combinations of specified transaction code and SAP instance.
For each combination of transaction code and instance that you want to include in the monitoring, specify the
threshold values resulting in alert messages for GREEN to YELLOW, YELLOW to RED, RED to YELLOW,
and YELLOW to GREEN.
Since the monitoring object for performance monitoring is created on the satellite system, it might be possible
that the object already exists there. Therefore you can load the current threshold values from the respective
systems via the Load threshol ds from <XYZ> button, with <XYZ>representing the SID. If successfully
retrieved for an SAP instance, the values are filled in columns. If no active settings for the threshold values
were found for a certain transaction code, default values are set (indicated in column Default). To transfer the
threshold values for a single line from right to left, the Copy icon can be used. To transfer all at once (all
thresholds for all columns and tables) there is an additional Copy all button.
Figure 3: Monitoring alerts - Dialog performance
Best Practice
1.7.4.5 Application log
The application log provides an infrastructure for collecting messages, saving them in the database and
displaying them as a log. At runtime, situations can arise in application programs that must be brought to the
attention of the user. These are usually errors. It can also be useful to report a successful completion. The
information that arises is called a message. A set of messages is a log. A log usually also has header
information (log type, creator, creation time, etc.). A transaction can generate several logs. The application
log is not written consecutively but as a whole at one point in time.
Monitoring obj ects and al erts
The application log allows an application- or object-oriented recording of events. An object and any sub-
object that belongs to it classify each event. The analysis of the logs is similarly object- (or sub-object-)
oriented. The name of an object (or sub-object) can be found in transaction / nSLG1 together with all other
information specific to that log.
Figure 4: Monitoring objects and alerts Application log
It is possible to monitor the total number of messages belonging to an object. For each object, the number of
messages that raise a YELLOW alert and the number of messages changing from YELLOW to RED must be
maintained.
It is also possible to monitor specific messages that are considered as critical in the N of Critical Messages
table. To configure the monitoring of critical application log messages, select the relevant object-sub object
combinations. For each of these combinations, you can specify the message type, the message ID and the
message number as well as the threshold values for the number of critical messages that are supposed to
result in changes fromGREEN to YELLOW and fromYELLOW to RED can be specified. It is also possible to
use wild cards.
Best Practice
Figure 5: Monitoring alerts Application log/Critical messages
1.7.4.6 Analysi s and monitoring tools
It is possible to specify analysis transactions or URL addresses (including file directories) per monitoring
object. In case of analysis transactions these should be used to analyze errors or problems either locally in
SAP Solution Manager system (Call Option 1) or directly in the respective satellite systems (Cal l Option
2). Per default some standard transactions are maintained. For instance, transaction SM37, that provides a
job overview in an SAP system, is maintained for background jobs, and transaction SLG1, which is used to
have a look into the application log.
It is also possible to add new transactions. These can be standard transactions or transactions written by the
customer.
Figure 6: Analysis and monitoring transactions
Best Practice
On the second tab strip, you can specify an URL that should be called in order to further analyze the given
problem. This is especially interesting if you have knowledge documents that are linked to a portal. You can
define a short text and the URL.
For Web pages to be called, specify the full URL, e.g. http://help.sap.com. For content available on file
servers specify the full file path, using the nomenclature: file://\\\<server>\..., for instance,
file://\\\server1\operations_documents\operations-handbook.txt
Figure 7: Analysis and monitoring URL
When using the monitoring during a Business Process Monitoring session, the specified transactions or URLs
are available as buttons within a business process step. When you press these buttons, for instance
, you jump directly into the corresponding transaction, either in SAP Solution
Manager (here: SAT) or the connected satellite system (here: CT1), for further analysis.
In case of URLs, the button (e.g. ) contains the short text (limited to 20 characters)
from the setup session and opens the defined URL in a new browser window.
1.7.4.7 Moni tori ng acti vi ties
Monitoring activities should be set up for every monitoring object within a business process step. All
monitoring objects defined within a business process step are listed there. To ensure effective monitoring and
efficient problem resolution, assign responsibilities and define problem resolution procedures as described in
the following table. Some information has been taken from the previous Solution Support Organization node.
Monitoring Team Defines the team that is responsible for monitoring the relevant monitoring object.
Use value help F4.
Person Resp. Defines the person who is responsible for monitoring the monitoring object. Use
value help F4.
Frequency Describes how often the responsible person should process the required monitoring
activity.
Start Ti me Describes at which time the responsible person should process the required
monitoring activity.
Best Practice
Problem Indicator A description about what indicates a problem.
Error Handling Describes how to react on problems or errors, i.e. how to solve the problem or
correct the error.
Escal ation Path Describes the escalation path in case that the person responsible could not solve the
problem. Persons who can be contacted should be maintained here.
You can enter additional information related to this business process step in the tables Monitoring
Acti viti es, Error Handling, Restart of Step and Escalation Path. That information is valid for the whole
business process step and help users who have to carry out the monitoring and who are not familiar with that
particular business process.
1.7.4.8 Noti fications
You can set up notifications for the whole business process or for each business process step individually.
There are two types of notifications: Workflow notifications and support notifications. Workflow notifications
allow sending messages to a specified recipient in case of alerts, for instance, an e-mail or SAPOffice mail.
Support notifications allow setting up a service desk message in case of an alert. The information entered for
the service desk message serves as a template. The service desk message can be created manually or
automatically.
On business process level, you can define notifications for the whole business process, i.e. as soon as the
business process gets an alert status, notifications will be triggered. Alternatively, notifications can be defined
for every monitoring type individually, e.g. all alerts related to background jobs of the business process are
forwarded to a defined e-mail address.
Notifications defined on business process step level will overrule the configuration made on business process
level for this particular step.
Workflow notification
Sender Must be a user within in the monitoring client of SAP Solution Manager. This user
can even be a system user without any roles or profiles, but the user must have a
valid e-mail address which the used mail server knows.
Recipient Address Depending on the recipient type, the recipient name is required. This can be any e-
mail address, an SAP user name in the same system, a remote SAP name or a
shared distribution list. In case of an SMS you need to enter SMS:<cell phone or
pager number>.
Reci. Type There are currently five different recipient types: U (e-mail), K (for SMS and pager),
B (SAP user name), R (remote SAP name) and C (shared distribution list).
No. of Yellow Alerts Number of YELLOW alerts that can occur before an automatic notification is
triggered
No. of Red Alerts Number of RED alerts that can occur before an automatic notification is triggered
Best Practice
Max Wai t Time [h] Once the maximum wait time [hours] has elapsed, a notification is created even if
the thresholds are not exceeded.
RED Onl y To restrict this mechanism only to red alerts, the flag in column RED Only must be
set.
Detai led Triggers a long text for e-mails or SAPOffice mails, e.g. name of the solution, name
of the business process step, )
Support notifi cations
Priori ty Defines the priority of the support notification.
Queue Defines the support component on which the message is put. This component
must exist within the service desk.
Processor Defines a default processor who should process the message. The processor must
be known within the service desk and must be SAP user name defined as a
business partner with role employee.
Text Template Text templates can be defined that will then be available for service desk
messages manually created for alerts.
Automatic Support notifications will be created automatically depending on the alert
thresholds.
Reporter Necessary if service desk messages are created automatically. Must be a SAP
user name defined as a business partner with role general.
Num of YELLOW
Alerts
Necessary when service desk messages are created automatically, e.g. after ten
yellow alerts a service desk message should be created.
Num of RED Alerts Necessary when service desk messages are created automatically, e.g. after five
red alerts a service desk message should be created.
If in addition to Queue, Processor, Priori ty and Reporter either one of the columns Num of YELLOW
Al erts or Num of RED Alerts is filled with a value, the automatic support notification creation is
configured. In case that both columns are filled with a value, the automatic support notification creation
works with a logical OR operation. Hence, with the figures in the table above the system would create a
support notification if there are either more than nine yellow alerts or more than four red alerts for which
no support notification has been created yet.
Best Practice
1.7.5 Business Process Monitoring process
For a successful and efficient Business Process Monitoring, you have to define a process for implementing
your monitoring concept. This includes the definition of the roles and responsibilities involved. You need to
define who is supposed to carry out which activity within the process and how communication between the
different roles within the support organization is supposed to take place.
A Business Process Monitoring concept has to be tightly integrated with the support organization. This
includes the integration with the Incident- and Problem Management processes and the Change
Management process. These processes have to be adjusted to the Business Process Monitoring concept so
that communication and escalation procedures defined within these processes support the Business Process
Monitoring concept. This includes the final communication of open alerts to SAP.
Wherever communication connected with Business Process Monitoring happens outside these support
processes, separate communication and escalation paths and procedures have to be defined.
Please see the separate Best Practice for General Business Process Management for further details.
1.7.6 Legend
This symbol indicates a paragraph from where you can navigate to another chapter of this document
for a more detailed information on a topic.
This symbol indicates a paragraph from where you can navigate to another document within the SAP
Service Marketplace for a more detailed information on a topic.
Best Practice
2 Busi ness Process Monitori ng for Workforce Management
Workforce Management (WFM) performs the complex process of creating optimum employee schedules by
leveraging employee skill sets and balancing workload and weighted variables such as payroll requirements,
budgetary objectives, employee availabilities, workplace rules, regulatory requirements and performance
standards. WFM is a Web-based application that can stand alone on SAP NetWeaver, SAP Enterprise
Resource Planning (SAP ERP) or serve as an integrated application to SAP ERP Human Capital
Management (SAP ERP HCM). The application is delivered with nine standard Web template reports that you
can use as they are or modify via SAP NetWeaver Business Intelligence to meet your needs. Workforce
Management is integrated with SAP Enterprise Portal with configurable role-based access (manager,
employee, supervisor, corporate executive); with SAP NetWeaver Business Intelligence for centralized
reporting; and holds key integration to SAP ERP HCM where hiring and scheduling processes can be
streamlined. Workforce Management is comprised of four major business processes which include employee
maintenance, business forecasting, labor scheduling and managing time. This Best Practice document will
focus on three of the four business process and describe in greater detail monitoring possibilities for
employee maintenance, forecasting, and scheduling.
Figure 8: Business processes in WFM
Best Practice
2.1 Sample WFM Scenario
Cosmetics Inc. is a mid-size specialty retailer that sells cosmetics, fragrances, jewelry, vitamins, skin care
and hair care products in the United States. Store teams range from 25 employees in smaller stores to 75 in
larger locations. It is no easy task to ensure employee coverage levels to accurately match changing
customer demand was no easy task. The company previously managed employees by a manual scheduling
system that was time-consuming, inconsistent across all stores, and very biased leading to organizational
inefficiencies and inadequate customer service levels. To address these issues, Cosmetics Inc. acquired
WFM delivered on SAP NetWeaver to streamline the process of scheduling store staff and improve customer
service levels. Employees are maintained in a third-party HR system and are imported into SAP through a
standard employee master data interface. To forecast adequate workload for each store respectively, key
volume drivers, such as items sold, and transactions are loaded from the point-of-sale system. Schedules are
processed centrally and maintained at the store level by the store manager.
The following core business processes were used.
1. Employee maintenance (managing employee master data)
2. Forecasting (forecasting schedule and workload)
3. Scheduling employee
The following chapters take you through these three core business processes step by step, explaining where
and how you can identify focus points for Business Process Monitoring. For each business process step, the
most effective ways for Business Process Monitoring in the context of the example are highlighted. Currently,
WFM-specific Business Process Monitoring objects are not contained in SAP Solution Manager.
2.2 Business Process: Employee Maintenance
In WFM, the employee maintenance business process defines how employees are to be maintained for
scheduling once they have been hired or imported into the system. WFM either uses HR master data loaded
from a third-party HR system, SAP ERP HCM, the Personnel Action Portal iView of WFM, or replicates
manually created data in SAP Business Partner. Despite the method used to import employees, all
employees must have a business partner created. SAP Business Partner (SAP BP) is the entry point to view
or modify employees in WFM. The SAP BP application is a component of SAP NetWeaver and contains
master data (name, address, date of birth, etc.). WFM utilizes the SAP BP component to represent
employees (persons) within an organization. In WFM, the business partner must be assigned to a position
within an organizations hierarchal structure viewable as an employee of the store within the WFM portal.
With this assignment the user is available for scheduling.
After the employee has been imported into WFM, a combination of required employee HR master data and
supporting data supplied directly from the employees is needed to complete the employees profile in WFM.
Once created, WFM employee profiles are visible for review and modification through the portal user interface
(UI). Required end-user entered employee data points include:
Employee availability
Assign work areas
Assign schedule rules
Time-off requests
Best Practice
Figure 9: Business process Employee maintenance
2.2.1 Business process step 1: Personnel actions/recei vi ng employee master data
2.2.1.1 Description
Employee master data can be initiated from varying sources: the Personnel Administration iView of WFM,
SAP ERP HCM, or a third-party HR system. Client requirements define how employees are imported to
WFM.
The Personnel Action iView allows WFM end users to process SAP ERP HCM or HR employee personnel
actions and update the employee master data via WFM. The functions that this iView enables: Hi re, Update,
Transfer, Terminate, and Re-Enter (Rehire). The use of SAPs standard WFM employee transfer IDocs
updates the employee master data record in SAP ERP HCM or the HR source system. The HR system then
has to use another IDoc transfer to transmit any relevant changes to the HR data to the WFM system.
Employee master data from a third-party HR system have to transmit similar data changes in the IDoc format
used by SAP ERP HCM. In this way, you can rely upon the existing inbound processing to guarantee that the
WFM business partner database is maintained correctly.
Landscapes where SAP ERP HCM and WFM reside on the same box are considered a WFM best practice
and do not require the Personnel Acti ons iView. WFM and SAP ERP HCM have many integration points
that enable employees hired into SAP ERP HCM to be replicated to WFM. Upon activating the integration
between the two systems and maintaining key configuration settings, standard personnel actions become
seamless, allowing end users to proceed to business process step 2, the Profile iView, to maintain employee
WFM-related settings.
Best Practice
Scenario-specifi c sample
Due to hardware constraints, Cosmetics Inc. decides that HR and WFM must reside on different boxes.
Personnel Action view is used to hire, update, transfer, terminate and rehire employees.
2.2.1.2 Moni tori ng requi rements
Error monitoring
Monitoring can be performed in the enterprise portal, by inspecting Personnel Actions views, and also in the
HR system to ensure modifications made via the Personnel Actions iView have been updated in both
systems. This includes monitoring the data transfer between the systems via IDoc processing.
When you use WFM as an entry point for employee data, you need to monitor the subsequent Employee
iViews Profi le, Work Areas & Quali fications, Schedule Rules and Time-off Request (described in
subsequent business process steps) to ensure population of required fields for employee scheduling.
An employee at Cosmetics Inc. has just accepted a promotion to another store location. The employees
current manager wants to complete the transfer via the Personnel Acti on iView. Upon submitting the
transfer, the manager will need to check the corresponding screens in HR or SAP ERP HCM to ensure that
the changes in position, pay, and location were updated there too.
Figure 10: Changing employee master data
Best Practice
Utilizing the standard inbound and outbound IDocs to pass HR master data to and from HR or SAP ERP
HCM residing on different logical systems allows for other data or processing capabilities to be performed as
well between WFM and SAP ERP HCM. Users can monitor the IDocs by using the IDoc monitoring function-
nality in SAP Solution Manager or manually on satellite system via transaction WE05.
2.2.1.3 Moni tori ng objects in SAP Solution Manager
Monitoring Object Sel ection Criteria Alert Analysis
Tool on
Satellite
System
Moni tori ng
Frequency /
Data Coll ection
Outbound IDoc:
HRMD_ABAWFM
Basic Type: HRMD_ABAWFM
Status:
Error and intermediate statuses for
outbound processing, e.g.:
29 (error status) - Error in ALE
service.
Employee
data is not
transferred
from WFM
to HCM
WE05 Depending on
business needs
(every 15
minutes once
per day)
Inbound IDoc:
HRMD_ABA01
Basic Type: HRMD_ABA01
Status:
Error and intermediate statuses for
inbound processing, e.g.:
51 (error status) - Application
document not posted
52 (intermediate status) -
Application document not fully
posted
56 (error status) - IDoc with errors
added
Employee
data is not
transferred
from WFM
to HCM
WE05 Depending on
business needs
(every 15
minutes once
per day)
Tabl e 1: Personnel actions/receiving employee master data Monitoring data in SAP Solution Manager
When monitoring IDocs, the status of the IDoc will dictate what actions need to be taken:
IDoc in error status (red light): Click once on IDoc number to read text diagnosing the error. After error has
been corrected, you may reprocess the IDoc.
IDoc in processing (yellow light): No action is needed if further processing takes place as expected. If the
intermediate status lasts longer than usual, an erroneous behavior is indicated. In this case, investigate
the root cause and correct the error.
IDoc successfully processed (green light): No action is needed.
Best Practice
2.2.1.4 Further moni tori ng objects
Monitoring Object Selection
Criteria
Alert Anal ysis Tool on
Satelli te System
Monitoring
Frequency /
Data Collection
Personnel Actions
iView
WFM Portal
Employee tab
Personnel Actions
performed in WFM
are not reflected in
the third-party HR
system
WFM enterprise portal
(manual check):
WFM Portal
Employees
Personnel Acti on
Weekly/for each
instance: Hire,
update, transfer,
terminate, re-hire
Tabl e 2: Personnel actions/receiving employee master data Further monitoring data
2.2.2 Business process step 2: Mai ntain employee profiles
2.2.2.1 Description
Users can maintain several employee master data fields within the WFM portal. The Empl oyee Profile iView
displays basic employee information such as the employees hire/start date, employee type, default settings
group (FT/PT status), date of birth, employee number, cost class, and termination date. The Default Settings
Group field can be maintained manually by the user or configured to correspond with updates made in the
HR system. The Replacement Eligible feature, when activated, indicates that the employee is eligible to
replace shifts of other employee or for added coverage during schedule modification. The Repl ace and Add
Coverage functionality will list any employee who has this feature active and is available to cover the
selected shift. Other fields that can be modified include Cost Class, Hire Date, Start Date, and Termination
Date. When interfacing to an HR system that supplies this data, you can disable these fields by activating the
Date Lock flag within the RFC destination to HR configuration. All other fields in this iView will be grayed out
to prevent direct user modification. Updates or adjustments to the iView information must be performed in the
HR system of record and imported to WFM via the WFM employee maintenance standard interface.
Cosmetics Inc. hires a new employee. The data is entered into the HR system. In the portal, some WFM-
specific information needs to be maintained.
Error monitoring
The initial monitoring is done in the enterprise portal by inspecting the Profile iView to ensure that basic HR
data was imported properly to WFM. For all correctly created employees, the Profile tab displays an
employee profile.
Scenario specifi c sample
A new employee has been hired and the WFM administrator must check the employee profile for accuracy.
Best Practice
Figure 11: Maintaining employee profiles
New hires and employee master data modifications should appear in the portal in minutes if the integration
between HCM or third-party HR and WFM works properly. If you notice that an employee is missing from the
employee list, you need to check the box beside New Employees Only to get the corresponding list.
Figure 12: Checking new employees profiles
The list displaying the new employees indicates that an error was made during the hiring process. In such
cases, HR master data (such as hire date) is missing, which prevents the employee profile from creating
properly. Manually entering Hi re Date and Start Date and saving will remove the employee from the New
Employees Only list and make the profile visible in the general list. If a majority of employees is displayed in
the New Employees Only list, it is best to find the root cause for the problem rather than manually correcting
the profiles.
In addition, check if the RFC interface WFA_EMP_DATA_MODIFY works properly. It is used to maintain:
WFM global attributes (hire date, start date, termination date)
General WFM attributes (such as default settings group and cost class)
Work area assignments for an employee
Schedule rules (availability, preferences and set/fixed shifts)
Best Practice
Work rules
Contract rule
Employee time-off requests
It is best practice to call the RFC interface WFA_EMP_DATA_GET, which retrieves all of the attributes main-
tained by WFA_EMP_DATA_MODIFY. Errors resulting from this interface are stored in table ET_RETURN,
which resides in WFA_EMP_DATA_MODIFY and WFA_EMP_DATA_GET interface. Object ET_RETURN
can be checked to determine if the interface failed.
If integrated with SAP ERP HCM, verify that both, HCM-PA to WFM integration and SAP BP integration, are
enabled. Another issue that can result in an incomplete employee profile is that the WFM agent profile update
failed during the hiring process. In that case the employee will appear in the portal without a start and hire
date and will only be visible in the New Employees Onl y list. You can correct this error by manually entering
the start and hire date and saving the profile. You can also delete and recreate the agent relationship utilizing
the agent update program created during the BP conversion process.
Figure 13: Error WFM agent profile update failed
It is necessary to monitor the time elapsed from hiring an employee in HR until the data is visible in WFM.
A new employee has been hired and the data entered in HR but the data is not immediately displayed in
WFM.
Best Practice
Monitoring Object Selection Cri teri a Al ert Analysis Tool
on Satelli te
System
Moni tori ng
Frequency/Data
Col lecti on
Outbound IDoc
HRMD_ABAWFM
Basi c Type:
HRMD_ABAWFM
Status:
Error and intermediate
statuses for outbound
processing, e.g.:
29 (Red light) - Error
in ALE service.
Employee data is not
transferred from
WFM to SAP ERP
HCM
WE05 Depending on
business needs
(every 15
minutes once
per day)
Inbound IDoc
HRMD_ABA01
Basi c Type:
HRMD_ABA01
Status:
Error and intermediate
statuses for inbound
processing, e.g.:
51 (red light) -
Application document
not posted
52 (yellow light) -
Application document
not fully posted
56 (red light) - IDoc
with errors added
Employee data is not
transferred from
WFM to SAP ERP
HCM
WE05 Depending on
business needs
(every 15
minutes once
per day)
Function modules
WFA_EMP_DATA_
GET and
WFA_EMP_DATA_
MODIFY
(depending on the
interface technology
used, tRFC or qRFC
monitoring can be
used in SAP
Solution Manager)
RFC destination Any of the following
is not updating
properly:
WFM global
attributes (Hire
Date, Start Date,
Termination Date)
General WFM
attributes (such as,
Defaul t Settings
Group and Cost
Class)
Work area
assignments for an
employee
Schedule rules
(Availability,
Preferences and
Set/Fixed Shifts)
Work rules
Contract rule
Employee time-off
requests
tRFC
processing:
SM59
qRFC
processing:
SMQ1, SMQ2
Depending on
business needs
(e.g. once per
day or once per
week)
Tabl e 3: Maintain employee profiles Monitoring objects in SAP Solution Manager
Best Practice
intermediate status lasts longer than usual, an erroneous behavior is indicated. In this case, investigate
the root cause and correct the error.
2.2.2.4 Further moni toring obj ects
Monitoring Object Selecti on
Criteria
Al ert Anal ysis Tool
on Satellite
System
Monitoring
Frequency /
Data Col lecti on
Business partner created N/A Employee does
not appear in the
WFM portal.
Transaction BP Verify BP
number created
for each
employee
Profil e iView WFM portal
Employee tab
Profile
N/A WFM enterprise
portal
For each:
New hire
Employee
basic
information
modification
Transfer
Termination
RFC Select Trace:
RFC Trace
Select Trace
Function:
Activate Trace
N/A ST05 When errors are
detected from
the employee
profile, an RFC
trace may point
to the error.
Tabl e 4: Maintain employee profiles Further monitoring objects
2.2.3 Business process step 3: Mai ntain work areas and qualifi cations
2.2.3.1 Description
The Work Areas & Quali fications iView allows you to assign one or several work area(s) to an employee so
they can be scheduled. Default Setti ngs Group, Cost Cl ass, and Employee Group are also visible in the
Work Areas & Quali ficati ons iView. The Pay Rate field can be visible to or hidden from the store level user
via Roles & Authorizations.
A work area defines the job that the employee will be scheduled to work. A work area can be given a
numerical rank if the employee has been assigned to multiple work areas. The rank defines the order in which
the work areas should be considered for scheduling for that employee during schedule calculation.
Best Practice
In Work Areas & Qual ifications iView the employee can be assigned a proficiency rating which defines what
skill level the employee holds within a particular work area. The Shared Empl oyee feature in WFM allows
specific employees to work in multiple store locations. The Work Area Reluctance Profile will define, for
scheduling purposes, what priority the rank of the work areas should be scheduled.
Cosmetics Inc. stores #1 and #2 would like to use the Shared Employee feature within WFM. They noticed
that employees that meet the requirements for sharing do not show up on both store schedules.
Error monitoring
Each employee must have at least one work area assigned although multiple work areas can be assigned
based on the configuration and business requirements.
The WFM administrator must ensure that the requirements for the Shared Employee feature are active:
The employees home store must have the Shared Employee feature active.
The employees home store must have the Replacement Eligibl e feature active
The schedule for the home store must be posted before the employee will appear for scheduling in the
shared location(s).
If multiple shifts can be worked in multiple locations, then the May work in multiple locations i n same
day flagged must be active.
After schedule calculation, the WFM administrator noticed that an employee did not display any scheduled
hours on the schedule, nor did they display under a specific work area in the portal.
Monitoring
Obj ect
Selection
Criteria
Alert Analysis Tool
on Satelli te
System
Moni tori ng
Frequency/Data
Col lecti on
Function Modules
WFA_EMP_DATA
_GET and
WFA_EMP_DATA
_MODIFY
(depending on the
interface
technology used,
tRFC or qRFC
monitoring can be
used in SAP
Solution Manager)
RFC
destination
Any of the following does not update
properly:
- WFM global attributes (Hi re Date,
Start Date, Terminati on Date)
- General WFM attributes (such as,
Defaul t Settings Group and
Cost Class)
- Work area assignments for an
employee
- Schedule rules (Availabi lity,
Preferences and Set/Fixed
Shifts)
- Work rules
- Contract rule
- Employee time-off requests
tRFC
processing:SM
59
qRFC
processing:
SMQ1, SMQ2
Depending on
business needs
(e.g. once per
day or once per
week)
Tabl e 5: Maintain work areas and qualifications Monitoring objects in SAP Solution Manager
Best Practice
2.2.3.4 Further moni toring objects
Monitoring Object Selecti on
Criteria
Al ert Anal ysis Tool
on Satellite
System
Moni tori ng
Frequency/Data
Col lecti on
Work Area & Qual ification
iView
WFM portal
Employee tab
N/A WFM Portal
Employee
Work Area &
Quali fications
Weekly, when new
hires/re-hires are
entered
Whenever work
area additions or
modifications are
needed
RFC Select Trace:
RFC Trace
Select Trace
Function:
Activate Trace
detected from the
work area and
qualifications view
an RFC trace may
point to the error.
Tabl e 6: Maintain work areas and qualifications Further monitoring objects
2.2.4 Business process step 4: Mai ntain schedule rules
2.2.4.1 Description
Employee scheduling rules can be maintained in the Schedule Rules iView in the WFM portal. Schedule
Rules allows you to enter employee availabilities, preferences, fixed and set shifts. Availability start and stop
times are entered manually by day in either standard or military time. Rotations can also be defined in this
iView if employees have rotating availabilities and/or schedules. WFM will automatically assign the rotation
settings to a specific schedule week, based on the number of rotations in the list and the settings position in
the list. WFM will reference the information in this view during the schedule calculation to schedule the
employees within their availability and shift settings.
Work rules are used by WFM during schedule creation to ensure the resulting shifts meet the schedule goals
for the employee while complying with company policy and legal requirements. Examples include: Minimum
or maximum number of hours per day or week, maximum days per week, allow overtime, maximum hours per
period (contract), etc. Work rule templates are preconfigured and assigned to each employee to provide
default settings that meet the company policy and legal requirements. Contract work rules are used more
commonly in union environments and enable scheduling constraints for minimum and maximum scheduled
hours over a period of time.
If the schedule calculation or modifications made to a schedule break any of these rules, schedule exceptions
will be generated. The manager can then modify the schedule to remove the exception or decide to ignore
the exception. When assigning the work rules for a given employee, you also need to consider the employee
type (FT, PT) or age qualification (Minor).
Best Practice
Cosmetics, Inc is preparing to open a new location and needs to maintain availabilities and work rules for all
employees prior to grand opening.
The initial monitoring is done in the enterprise portal by inspecting the Schedule Rul es iView to ensure
availability and work rules are maintained.
Error monitoring
Employee availability must be maintained for each employee. If employee availability is left blank, the WFM
scheduler will not create a schedule for that employee.
Work rules must be maintained for each employee to constrain the min/max hours of work per day or per
week according to company guidelines. For example, a part-time employee should receive fewer hours than
a full-time employee. If you notice that this is not the case, you should check the work rules assigned to the
employee in question (Employees Schedul e Rul es Work Rules):
Figure 14: Checking work rules
Positions that require a fixed shift must be maintained to prevent erratic schedules. It is best practice to
maintain fixed shifts for managers and any other positions that require coverage that is not dependent upon
customer demand.
A company may have the philosophy that a manager should be present at all times to assist customers and
store associates. To ensure consistent coverage, use a fixed shift. Otherwise, WFM will schedule the
manager to coincide with store demand, producing a very erratic schedule.
Best Practice
Figure 15: Maintaining shifts
Monitoring Object Sel ection
Criteria
Alert Analysi s Tool
on Satel lite
System
Monitoring
Frequency /
Data
Collection
Function modules
WFA_EMP_DATA_GET
and WFA_EMP_DATA_
MODIFY
(depending on the
used, tRFC or qRFC
monitoring can be used in
SAP Solution Manager)
RFC
destination
Any of the following is not
updating properly:
WFM global attributes (Hire
Date, Start Date,
Termi nation Date)
General WFM attributes
(such as, Def ault Settings
Group and Cost Cl ass)
Work area assignments for
an employee
Schedule rules
(Avail abili ty, Preferences
and Set/Fi xed Shifts)
Work rules
Contract rule
tRFC
processing:
SM59
qRFC
processing:
SMQ1, SMQ2
Depending on
business needs
(e.g. once per
day or once per
week)
Tabl e 7: Maintain schedule rules Monitoring objects in SAP Solution Manager
Monitoring Object Sel ection Criteria Alert Anal ysis Tool on
Satelli te System
Monitoring Frequency /
Data Collection
RFC Select trace: RFC trace
Select trace unction:
Activate trace
N/A ST05 When errors are detected
from the Schedul e Rul es
view an RFC trace may
point to the error.
Tabl e 8: Maintain schedule rules Further monitoring objects
Best Practice
2.2.5 Business process step 5: Mai ntain time-off requests
2.2.5.1 Description
Time-off requests allow the user to manage planned absences for scheduling and projected payroll planning
purposes. Requests can be made for a specific time period of a day, a full day, a number of days or a
number of hours. Comments associated with an employee time-off request can also be entered. A time-off
request will modify employees availability by making them unavailable for scheduling without modifying their
permanently entered availabilities. The time-off request can be processed for paid and un-paid time off. Paid
benefit time-off requests are only used in WFM for pre-payroll calculations and schedule costing purposes.
Figure 16: Maintaining time-off requests
Employee submits a time-off request to their manager to attend jury duty.
2.2.5.2 Moni tori ng requi rement
The initial monitoring is done in the enterprise portal by inspecting the Time-off Requests iView.
Error monitoring
Errors displayed in this view are usually user errors. Time-off requests may have been entered incorrectly
and need to be modified.
Best Practice
The store manager has just entered a time-off request for an hourly employee and realized that they assigned
the wrong absence type.
Submitted time-off requests are listed for each individual in the Ti me-off Requests table. The absence type
is listed as a hyperlink displayed in blue. To modify data associated with the absence type, click on the
hyperlink to view the time-off request details. To remove a time-off request, place a check in the box beside
the absence type and press the Remove button.
Monitoring Object Selection
Criteria
Alert Analysis Tool
on Sat el lite
System
Monitoring
Frequency/Data
Collection
Function modules
WFA_EMP_DATA_
GET and
WFA_EMP_DATA_
MODIFY
(depending on the
used, tRFC or qRFC
Monitoring can be
used in SAP
Solution Manager)
RFC
destination
Any of the following is not
updating properly:
WFM global attributes (Hi re
Date, Start Date,
Terminati on Date)
General WFM attributes (such
as, Default Settings Group
and Cost Class)
Work area assignments for an
employee
Schedule rules (Avai labil ity,
Preferences and Set/Fixed
Shifts)
Work rules
Contract rule
tRFC
processing:
SM59
qRFC
rocessing:
SMQ1, SMQ2
Depending on
business needs
(e.g. once per day
or once per week)
Tabl e 9: Maintain time-off requests Monitoring objects in SAP Solution Manager
Monitoring
Obj ect
Sel ection Criteria Alert Anal ysis Tool on
Satellite System
Monitoring Frequency / Data
Collection
Select trace function:
Activate trace
N/A ST05 When errors are detected from
the Schedule Rules view, an
RFC trace may point to the error.
Select trace function:
Activate trace
N/A ST05 When errors are detected from
the Schedule Rules view, an
RFC trace may point to the error.
Tabl e 10: Maintain time-off requests Further monitoring objects
Best Practice
2.3 Business Process: Business Forecast and Workload Modeling
WFM includes a forecasting engine that builds staffing demands based upon recent history, variable and
fixed activities, corporate labor targets, and other requirements. Forecasts are created to calculate the
expected overall business volume and workload. The process uses a stores activity together with parameters
and other historical information to establish trends. The user, store or corporate user, then has the oppor-
tunity to tune this data to ensure that it accurately reflects the current business situation. Once the volume
forecast is generated, WFM projects the workload, the number of employees needed per work area for each
quarter hour. Forecast creation is generally the first step when creating a new schedule week.
The steps and processes that comprise forecast and workload creation are:
System maintains historical indicator data Historical indicator data is stored in a database for access
during forecasting the workload
Select week to schedule User selects schedule week
Select forecast parameters The forecast parameters determine the indicators that will be used to create
the workload
Submit forecasting calculation request The request will be put in a queue at corporate for calculation
Monitor status of forecast request A status of the forecast request will be listed in the portal for review by
the location
Review forecast Once the forecast has been successfully calculated, the location manager can review
the forecast for adjustments
Review workload The location manager can also review the workload for adjustment
Modify forecast to reflect location variables After the location manager makes adjustments, the forecast
must be resubmitted for forecasting and approval
Monitor of status of forecast calculation request
Review and approve workload
Figure 17: Business process Business forecast and workload modeling
Best Practice
2.3.1 Business process step 1: Adj ust actual vol ume data
2.3.1.1 Description
The volume data to be used for forecasting and workload modeling is defined in WFM and linked to variable
activities or tasks. Each variable activity will have a labor standard defined to indicate the time it takes to
complete the task. This setting is used in the forecasting of the demand. Fixed activities are also defined and
will be accounted for in the forecast of the demand.
Volume data is based upon recent history derived from POS systems, traffic counters, merchandising
systems (markdowns, price changes), and financial plans. This data is typically stored and maintained in a
data warehouse system such as SAP NetWeaver BI at the corporate level. The data is imported into WFM via
various means: RFC, IDoc or manual entry. Import of data via RFC or IDoc is controlled by the corporate
office. Manual entry of data is typically performed at store level. Manually entered data can include the
number of markdowns expected for the week, cartons expected from a shipment, etc. This data is entered
prior to forecast calculation to ensure the appropriate workload and employees will be scheduled to handle
these tasks.
Once the data is imported, you can further tune the data to reflect changes in the stores business or
expected new business for the scheduled week. For instance, the mall where the store is located is promoting
a sidewalk sale. The data that is imported may not meet the expected requirements of the sale. You can
adjust the data prior to forecast to reflect the expectations of the sale in order to ensure that the store will be
scheduled appropriately for it.
Data is imported via corporate defined process and systems (i.e. POS system, traffic counter, etc.).
The initial monitoring is done in the enterprise portal by inspecting the iViews in the Forecasts tab.
Error monitoring
Successfully imported data is displayed in the WFM portal in the Forecasts Revi ew/Modi fy Forecast
iView. You can review the graph or the numeric values to verify whether or not the data that was imported is
accurate. WFM will utilize the volume data imported into the system when calculating the demand. If incorrect
data was loaded to the system, then the issue can be directly reflected in the forecasted demand.
Errors in the data will be reflected in the graph or statistics of the Review/Modify Forecast iView in the
Forecasts link.
Best Practice
Figure 18: Reviewing forecast data
When the user accesses the Revi ew/Modify Forecast iView, no actual data displays.
Discrepancies in the data should be traced back to the original source(s) the POS data for the store, traffic
counter data, manually entered values, etc. You will have to contact a resource at corporate to determine why
no data has been imported for the selected indicator.
The data displayed in the Revi ew/Modify Forecast iView does not reflect the volume expectations for an
upcoming sidewalk sale.
You can adjust the indicator values by entering specific values or a percentage change so that the data will
reflect the expected change in workload for the sale. Once the changes are saved, the adjustments will
immediately be reflected in the statistics as well as in the graph. You can further review and tune the
adjustments until the results meet the expected needs of the sale.
Best Practice
Figure 19: Modifying volume data
Monitoring Object Selection Cri teri a Al ert Analysi s Tool
on Satel lite
System
Moni tori ng
Frequency/Data
Col lecti on
Function module
WFA_FORECAST_SAMP
LE_SET (depending on the
interface technology used,
tRFC or qRFC monitoring
can be used in SAP
Solution Manager)
RFC destination Forecasting
data did not
import to
WFM
tRFC
processing:
SM59
qRFC
processing:
SMQ1, SMQ2
Depending on
business needs
(e.g. once per
day or once per
week)
WFM forecast data import
inbound IDoc:
IDOC_INPUT_WFAFCHV
Basi c Type: WFAFC_A01
Status: Error and
intermediate statuses for
inbound processing, e.g.:
51 (red light) - Application
document not posted
56 (red light) - IDoc with
errors added
62 (yellow light) - IDoc
passed to application
68 (green light) - Error-
no further processing
N/A WE05 Depending on
business needs
(every 15
minutes once
per day)
WFM forecast data import
outbound IDoc:
IDOC_INPUT_WFAFCPV
Basi c Type: WFAFC_A01
Status:
29 (Red light) Error in
ALE service.
N/A WE05 Depending on
business needs
(every 15
minutes once
per day)
Tabl e 11: Adjust actual volume data Monitoring objects in SAP Solution Manager
Best Practice
intermediate status lasts longer than usual, an erroneous behavior is indicated. In this case investigate the
root cause and correct the error.
2.3.2 Business process step 2: Performing the i niti al forecast calcul ation
2.3.2.1 Description
The initial forecast provides the first impression of how data is calculated based on the imported data and the
configured parameter settings. There are two critical steps when generating a forecast calculation:
1. Determine forecast parameters
2. Submit the forecast for calculation
Once data has been imported and adjusted, and manual entries have been made, the next step is to
determine the forecast parameters for the selected schedule week. Those parameters allow a great deal of
flexibility in the variables that can be selected to influence the forecast outcome. They also provide a means
to create a more accurate demand for the specific locations.
Figure 20: Determining forecast parameters
Best Practice
Forecast templates can be used when a given week has similar forecast attributes as another week. When
you create a forecast based on a forecast template, the system uses the same forecast parameters as those
within the template week. You can then fine tune the forecast as needed for the new week. Forecast
templates are often used for recurring billing cycles or weeks with regular promotions.
When WFM is initially configured, you also configure the method of forecasting, either weighted average or
trended forecast. These methods influence what data will be used for forecast calculation and the importance
of the data that is being used.
Special History can be used for forecasting weeks that are not reflected by recent history. This might be the
case for days or weeks with sales events or holiday sales, i.e. the week of Christmas. Use the Tagged History
tab of the Forecast Parameters iView. Similar day/week volume information is selected and used for
forecasting.
Use Copy History to influence the forecast calculation. Copy History copies the actual data from the
selected day or week and assigns it to the adjusted form of the indicator for the forecasted week. When Copy
History is used, you want the adjusted value for the day or week to be the actual value from some other day
or week. This might be the case when a specific sale event occurs every three months. You can then choose
the transaction history from the previous sale to generate a volume forecast for the next sale.
The creation of the forecast is also defined by company-specific processes in order to meet corporate labor
targets. WFM can accommodate multiple scenarios, including:
Generating a forecast to meet pre-determined payroll targets (forecast and workload generation with a
budgetary constraint)
Generate a forecast using engineered labor standards to identify the workload/payroll target (forecast and
workload generation without a budgetary constraint)
Once the forecast parameters have been established, you can calculate the forecast. You can configure the
calculation of the forecast to run as a batch process in the background, without store managers execution, or
to be manually kicked off by individual stores. The batch calculation is configured via the Calcul ation Batch
parameter and identifies the locations to be included in the process. The forecasts are submitted through
standard SAP job processing. The manual process is submitted by the user via Forecasts Calculate
Forecast.
The end result is a labor demand representing forecasted service requirements for scheduling the right
person, at the right place, at the right time.
The user generates a forecasted demand for a new schedule week. Volume data for the location is present
for the specific location. Tasks (activities) have been configured. Budgets have been defined.
2.3.2.2 Moni tori ng requirements
The initial monitoring is done in the enterprise portal by inspecting the iViews contained in Forecasts
Calculation Status. This view will report the progress of the forecast and return a final status.
Users with higher level access to the WFM system can also monitor the status of a forecast in the WFM
Calculation Servi ces iViews.
Best Practice
Error monitoring
The status of a forecast calculation can be monitored for errors in the Forecast link in WFM or via the WFM
Calculation Servi ces link.
Forecast calculation is initiated manually by the location manager or a corporate user.
Error and status monitoring is performed in the Calculation Status iView in the WFM portal. This view will
report the progress of the forecast and return a final status.
Figure 21: Checking the calculation status for forecast progress
Clicking on the status will reveal the cause of an error or warning message for the forecasting calculation.
The information provided determines the steps you need to perform to produce a successful calculation.
Figure 22: Messages for calculation status for forecast progress
Best Practice
Forecast calculation is initiated by batch processing at corporate.
Error and status monitoring is performed in the WFM Cal culation Services iView in the WFM portal. It offers
a number of tabs that report the progress of the forecast and return a final status. In the Calculations Services
tab, you can access log files which can be used for troubleshooting by SAP Development.
Figure 23: Accessing forecast calculation log files
Best Practice
The Requests tab displays the requests that have been generated. The information provides the status of the
requests.
Figure 24: Requests tab in WFM Calculation Services
Best Practice
The Batch Requests tab displays any batch processes that have been configured and initiated.
Figure 25: Batch Requests tab in WFM Calculation Services
Backlog moni tori ng
SLG1 can be used to determine errors and warnings, however, the information that is provided is limited. The
information that is found in SLG1 should be provided when entering an OSS message.
Monitoring
Obj ect
Sel ection
Criteria
Alert Analysis Tool
on Sat el lite
System
Monitoring
Frequency / Data
Collection
Application log Object: WFA
Subobject: *
External ID: *
When errors and/or warnings are
generated.
SLG1 Weekly
ABAP runtime
errors
N/A When the following occurs:
Error: could not call RFC ..
This error indicates an RFC short
dump occurred.
ST22 Daily
Tabl e 12: Performing the initial forecast calculation Monitoring objects in SAP Solution Manager
Best Practice
Monitoring
Obj ect
Selecti on
Criteria
Alert Analysis Tool on
Satell ite System
Monitoring Frequency/
Data Col lecti on
Forecasts link Calculation
Status link
Provides success,
warning or error
status
Enterprise portal
Link provides
additional data for
resolving
warnings and
errors.
Weekly, as forecast are
submitted for
calculation.
WFM Calcul ation
Services link
Calculation
Services tab
Calculation times
out.
Calculation run
time is too long.
Calculation status
is error.
Enterprise portal
Log files available
for review if a
problem is
uncovered
Weekly, as forecasts are
submitted for
calculation.
WFM Calcul ation
Services link
Requests tab Status column:
Error
Enterprise portal Weekly, as forecasts are
submitted for
calculation.
RFC Select Trace:
RFC Trace
Select Trace
Function:
Activate Trace
detected, RFC trace
may point to the error.
Tabl e 13: Performing the initial forecast calculation Further monitoring objects
2.3.3 Business process step 3: Update volume forecast
2.3.3.1 Description
Once the initial forecast is generated, you can adjust the forecast to ensure volume forecasts are accurate
and to account for any last-minute campaigns or events that might impact the locations business but were
not included in the historical data upon which the forecast was generated. For example, the user can increase
sales to accommodate for a one-day sale, thereby creating a proportional increase in workload.
In order to increase sales at the beginning of the week, corporate has decided to have a special brand
promotion on Monday and Tuesday of the forecasted week. They expect a 10% increase in sales for those
two days. The location manager accesses the Review/Modify Forecast iView and enters a 10% increase for
Monday and Tuesday of the schedule week. The manager saves the changes, and then resubmits the
forecast for calculation by selecting the Update Forecast button.
Best Practice
Error monitoring
Once the percentage change has been entered in the appropriate fields, the adjusted data should reflect the
change. The manager can monitor the re-calculation by viewing the Calculation Status iView.
The location manager has entered and saved a change to the forecasted data in the Review/Modify
Forecast iView.
There are no errors when making adjustments to the indicator data. The user needs to verify that the changes
are reflected in the Adjust Data field for the selected day(s).
Figure 26: Updating volume forecasts
The location manager has resubmitted the forecast to be recalculated with the new changes.
Error and status monitoring is performed in the Calculation Status iView in the WFM portal. This view will
report the progress of the forecast and return a final status.
Best Practice
Figure 27: Checking the progress of the volume forecast
Clicking on the status will reveal the cause of an error or warning message for the forecasting calculation.
The information provided will determine the steps you need to perform in order to produce a successful
calculation.
Figure 28: Messages for calculation status of the volume forecast
Once the forecast has been calculated, the manager can review the changes to the workload in the
Workload iView to verify the changes have been applied.
Best Practice
Backlog moni tori ng
SLG1 can be used to determine errors and warnings, however, the information that is provided is limited. The
information that is found in SLG1 should be provided when entering an OSS message.
Monitoring
Obj ect
Selecti on
Criteria
Satell ite System
Data Col lecti on
Application log Object: WFA
Subobject: *
External ID: *
When errors
and/or warnings
are generated.
SLG1 Weekly
Tabl e 14: Update volume forecast Monitoring objects in SAP Solution Manager
Monitoring
Obj ect
Sel ection Criteria Al ert Analysi s Tool on
Satel lite System
Monitoring
Frequency/Data
Col lecti on
Forecasts link Cal culation
Status link
Provides success,
warning or error
status
Enterprise portal
Link provides additional
data for resolving
warnings and errors.
Weekly, as forecasts
are submitted for
calculation
Forecasts link Workl oad link Forecasted data is
missing at the
organization,
department or
work area level.
Enterprise portal
Provides verification
that adjustments have
been successfully
applied.
Weekly, as forecasts
are submitted for
calculation
RFC Select trace: RFC
trace
Select trace
function: Activate
trace
detected, RFC trace
may point to the
error.
Tabl e 15: Update volume forecast Further monitoring objects
Best Practice
2.3.4 Business process step 4: Apply budgetary constraints
2.3.4.1 Description
Once the initial forecast is complete or the forecast has been updated and the workload has been reviewed,
the store user may directly adjust the workload to meet payroll budgetary constraints. The Budgetary
Constraints iView allows direct workload adjustments to meet payroll budgetary targets. Only weekly
adjustments to the payroll targets are allowed in the Budgetary Constraint iView, and the workload is
adjusted proportionally while retaining the forecasted activity pattern. Adjustments can be made to hours,
projected payroll dollars, project payroll percent to forecasted sales, and projected sales per labor hour.
Figure 29: Applying budgetary constraints
Managers can apply budgetary constraints to the workload for a specific forecasting week by location,
department or work area in order to ensure the system generates schedules that meet the locations business
requirements. Budget constraints allow the user to adjust the workload in order to keep the cost of a schedule
generated by the system within the locations budget. Once there is a schedule created, however, managers
can no longer adjust the budgetary constraint values.
The adjustment type for budgeting Hours, Payroll , Payroll Percent, Sal es Per Hour is defined and
configured during the initial configuration of Workforce Management.
Best Practice
Users can also adjust the overall forecast and workload at the highest levels of their area of responsibility,
such as region-wide adjustments, and the changes roll up or trickle down through all stores or locations within
the organizational structure. The indicators for these roll-up adjustments are defined and configured during
the initial configuration of WFM.
The store manager is required to change the labor hours to meet the budgeted hours for the location. The
manager enters the new hours in the Adj usted Hours field of the Budgetary Constraints iView.
2.3.4.2.1 Changes to forecast indicators
When the district manager makes a change to the forecast indicators and saves it, the change is reflected in
the Forecast Adjustment iView and will also appear in each of the store-related Forecasting iViews.
Changes can be made at the organization unit level or department level.
Error monitoring
As soon as the district manager saves a change, the screen changes to the Status iView. WFM applies the
change to the stores assigned to this district. Error and status monitoring is performed in the Status view. It
will report the progress of the forecast change and return a final status.
The district manager increases the forecast gross indicator for Saturday.
Best Practice
Figure 30: Changing forecast indicators
Clicking on the status will reveal locations that were adjusted as well as the cause of an error or warning
message for the forecasting calculation if the status Error is displayed. For the location that has the error,
expanding the line will provide information that will determine the steps that the user or corporate will need to
perform in order to produce a successful calculation.
Figure 31: Message for calculation status of volume adjustment
The district manager can also view the change made for each of the locations by selecting the organization
from the tree view. The display will verify that the changes have been applied to the selected location.
Best Practice
Figure 32: Reviewing the volume adjustments per location
2.3.4.2.2 Changes to the workload
When the district manager makes a change to the workload and saves it, the change is reflected in the
Workload Adjustment iView and will also appear in each of the store-related Workload iViews. The
manager can adjust hours, estimated payroll, estimated payroll percentage or sales per hour.
Figure 33: Selecting the adjustment type
Best Practice
Error monitoring
When the district manager makes the change and saves, the screen will change to the Status iView. WFM
applies the change to the stores assigned to this district. Error and status monitoring is performed in the
Status view. It will report the progress of the forecast change and return a final status.
District manager increases the workload hours for Saturday.
Figure 34: Changing the workload
Best Practice
Clicking on the status will reveal locations that were adjusted as well as the cause of an error or warning
message for the forecasting calculation if the status displays Error. For the location that has the error,
expanding the line will provide the information that determines the steps that the user or corporate need to
perform in order to produce a successful calculation.
Figure 35: Message for calculation status of workload adjustment
The district manager can also view the change made for each of the locations by selecting an organization
from the tree view. The display will verify that the changes have been applied to the selected location.
Figure 36: Reviewing the workload adjustments per location
Best Practice
Monitoring
Obj ect
Selection
Cri teri a
Alert Analysi s Tool
on Satel lite
System
Moni tori ng Frequency /
Data Coll ection
Forecasts
link
Budgetary
Constraints
link
Data is missing at the
organization, department
or work area level.
submitted for calculation
Forecasts
link
Workload
link
Forecasted data is missing
at the organization,
department or work area
level.
Forecasted workload is too
low or too high.-
Roll-up
adjustments
Forecast
adjustments
Forecasted data is
missing.
Adjustments are not rolling
up to the departments
correctly.
Enterprise portal Weekly, when forecasting
has been completed for the
locations in the district/
region and prior to perfor-
ming schedule calculation
Roll-up
adjustments
Workload
adjustment
Forecasted data is
missing.
Adjustments are not rolling
up to the departments
correctly.
Enterprise portal Weekly, when forecasting
has been completed for the
locations in the district/
region and prior to perfor-
ming schedule calculation
Tabl e 16: Apply budgetary constraints Further monitoring objects
2.3.5 Business process step 5: Approve forecast
2.3.5.1 Description
Approving the forecast allows to proceed to the next step in the WFM process. There are two methods of
approving a forecast. The first one is to make sure that the forecast and any budgets have been applied to
the forecast. Typically, a location is designated a date at which this information and the process need to be
completed.
The second method is to use Schedule Track, which provides a step-by-step guide to creating a final
schedule. The forecasting section provides an Approve Forecast link that you can select to approve the
forecast and proceed through the remaining steps of the process.
Best Practice
Figure 37: Approving a forecast
The manager approves the forecast so that the workforce management process can proceed.
Forecast must be approved in order for the process to continue. Check for errors in the approval process.
Monitoring
Obj ect
Selecti on
Criteria
Alert Anal ysis Tool on Satell ite System Monitoring
Frequency / Data
Collection
Schedule
Track
Forecast
Approve
Forecast
Schedule
track fails
to update
Enterprise portal
Check box appears next to Approve
Forecast and the process moves to
the following item in the process
Weekly, after
forecasts have been
analyzed and
adjusted
Tabl e 17: Approve forecast Monitoring objects in SAP Solution Manager
Best Practice
2.4 Business Process: Schedul ing
Workforce Management uses optimization technology to produce the most effective and efficient schedule
that meet customer demand and aligns with corporate operational objectives, employee work rules and
absences. The calculation architecture is scalable to accommodate small, medium and large stores within the
company hierarchy. Flexible maintenance capabilities allow you to update the schedule as needed to support
changes in business volume. Scheduling optimization considers the following:
Fixed and flexible staffing
Work rules and priorities (min/max hours per shift or week, max OT allowed, consecutive days worked,
etc.)
Scheduled events such as training, store meetings, etc.
Meal and break allocations as defined by corporate
Employee proficiencies and qualifications
WFM generates schedules using a complex set of calculations that takes absolute, hard and soft constraints
into account. Absolute constraints are business requirements that must not be violated. WFM will not violate
an absolute constraint during the schedule calculation process. However, the system cannot prevent a user
from manually violating an absolute constraint.
Absolute constraints are:
Work area eligibility
Capacity
Availability
Hard constraints are work rules that must be adhered to. WFM rarely violates a hard constraint unless
adhering to a hard constraint causes a violation of a higher ranking hard constraint or an absolute constraint.
Hard constraint rules include:
Fixed shifts by employee
Maximum number of shifts
Consecutive days off
Disallowed shift length
Minimum/maximum hours per shift
Maximum OT per shift
Maximum hours per segment
Minimum hours per segment
Schedule events
Once absolute and hard constraints are accommodated, the system uses a cost/penalty value that the
customer assigned in configuration to determine which soft constraints will be adhered to and which are ok to
violate. WFM will only violate a soft constraint if honoring it would result in the violation of an absolute or hard
constraint. To grant a specific soft constraint a higher status than other soft constraints you will need to
assign cost values according to company priorities. The higher the cost/penalty value the higher the priority.
Soft constraints include:
Allocate filler
Minimum average proficiency
Qualified workload
Shift characteristic
Best Practice
Seniority preference
Minimize pay
Workload importance
Quarter hour importance
Work area importance
Work area reluctance
There are five iViews maintained within the Schedules tab. Daily and Weekl y iViews allow you to view
schedules at a daily and weekly granularity. On the Individual iView, you can make temporary changes to
the following employee settings: Availability, work rules, work area assignments, and fixed shifts. Changes
made on the Individual iView are valid only for the effective period set by the user.
Scheduled events such as store meetings, training time, etc are maintained on the Events iView. Employees
will not be scheduled to work in a work area during the time they have a scheduled event. Activities that are
not directly linked to a work area are maintained as events and can be defined for current or future weeks.
You can specify the effective week, day of week, frequency, end date, start and end times. You can also
select specific employees to attend the event.
Schedule calculation via the Cal culation iView kicks off the scheduling optimization engine. Employee
profiles are matched to forecasted workload to find the best employee to meet work area and work rule
requirements.
Figure 38: Steps of the scheduling business process
Best Practice
2.4.1 Business process step 1: Scheduling creation
2.4.1.1 Description
Schedule creation is the third step in the WFM business process workflow. WFM uses data from volume and
demand forecast, and employee-specific information to create schedules. The schedule should only be
calculated after demand and volume forecasting have been adjusted to comply with store service levels,
productivity and fiscal goals. Scheduling optimization considers work rules, work area priorities, scheduled
events, meal and break allocations, employee skills, pay rates, preferences, and availabilities to produce the
most effective schedule that meets store demands and corporate objectives.
Employee has been hired; HR data and WFM-specific data is maintained. After forecasting, the employee is
then scheduled to meet workload demands.
The initial monitoring is done in the enterprise portal by inspecting the iViews contained within the Schedules
tab.
Error monitoring for schedule creation is done from the Cal culations iView and the WFM Calculation
Services tab. Prior to schedule creation, the following scenarios must be examined.
The store manager makes an adjustment to an employees work area assignment and does no longer find
the work area assigned listed for future weeks.
Figure 39: Individual iView
In the Individual iView, the user can make temporary changes to the following employee settings: Availability,
work rules, work area assignments, and fixed shifts. Changes are valid only for the effective period set by the
user. The most common issue is that this view is confused with the permanent schedule view maintained in
the Employee iView. The difference is that Effective Date: 01/20/2008, Vali d For
1
Week is listed at the
top of the page. This indicates that changes made here are only temporary. At the end of the Vali d for
period, the employee schedule settings will revert back to the permanent data stored in the Employee iView.
Best Practice
A training event needs to be communicated to specific store employees. To accommodate this request, the
store manager will create an event via the Events iView, that is then displayed on the employee schedule.
Figure 40: Creating events
All events must be created utilizing the Events iView and entered prior to schedule calculation.
Events represent activities that are not associated with a work area. Events are staff training, store meetings,
and so on. You can enter a user-defined event name, select the day of the week the event shall occur, select
the frequency, end date and start/end time. When you click the Show Employees button, a listing of all
employees in the store will be displayed where you can select those employees you want to invite to the
event. Previously created events will be listed as hyperlinks in the Event List on the Events iView. To modify
a previously created event, click on the hyperlink to view the details and modify.
After an event has been created in the Events iView it can also be modified from the Individual iView, on the
Events tab. Event modifications completed from the Individual iView will not be retained if the schedule is
recalculated. The original event entered via the Events iView will remain and the modified version will be
erased during the schedule calculation. If recalculation of schedules is normal it is best to enter and maintain
events exclusively from the Events iView.
Best Practice
Figure 41: Events in the Indivi dual view
The WFM administrator calculates a schedule manually and also via a batch.
The user can calculate a schedule at various levels: organization (location), department and work area.
Choosing the location level will calculate a schedule for every employee within that location. If you select the
department level, only the schedules for employees assigned to that department will be calculated. Likewise,
if the Work Area is chosen, only employees assigned to that work area will have a schedule calculated. It is
best practice to calculate schedules in batches to avoid manual errors. When manual execution is needed,
please take note that you are calculating schedules at the selected level only.
The Calculation iView also provides you the option to lock an employee. If it is necessary to recalculate a
schedule and you do not want to recalculate the schedule of all employees, you may choose to lock specific
employees. The Lock feature does not lock events. It is necessary to review scheduled events after each
schedule calculation.
Figure 42: Calculating schedules manually
Best Practice
Prior to submitting a calculation you can press the Pre-analysi s button to display potential exceptions.
Messages from the pre-analysis can be expanded to view detailed diagnosis and procedures to correct the
exception. Pre-analysis can be utilized to minimize exceptions prior to schedule calculation.
Figure 43: Pre-analysis results
Once you press the Submit to Calculate button or a batch job is executed to start the scheduled optimization
process, the calculation batches will be accepted and then queued.
Figure 44: Calculation
The calculation status is displayed in a list with a column that displays one of the statuses Accepted, In
progress, Completed, Cancel ed, Canceling, Error, Completed with warning or Canceled by warni ng.
Canceled processes or error statuses are displayed as hyperlinks that provide information regarding the
failure. Once they are corrected you will need to re-calculate.
Alert profiles may be assigned to manager roles through the path SAP IMG Retail Workforce Management
Operational Settings Define Calculation Alert Profile to notify them that the calculation request has been
submitted, an error occurred or the calculation was a success. The following alert profiles are available:
Best Practice
WFA_SUBMIT_ALERT When active, the users with the corresponding role receive an alert informing
them that the system has received a calculation request.
WFA_ERROR_ALERT When active, it indicates that the system has encountered one or more errors
during processing. The user can then fix the errors in order to resubmit the
request.
WFA_SUCCESS_ALERT When active, the users with the corresponding role receive an alert informing
them that the system has successfully completed the calculation processing.
Figure 45: Calculation status
If the schedule used in the previous week was effective and showed minimum exceptions, you can copy it to
future weeks. Press the Copy Schedule link and select the week to schedule. The week copied is per default
the preceding week.
Figure 46: Copying schedules
Best Practice
Performance Monitoring
It is imperative that the WFM administrator checks the status of batch calculated schedules for failures.
Schedules for hundreds of stores are batched and calculated overnight.
Calculation batches may fail if there are too many locations within a batch. Calculations may also fail if the
time allotted for calculation is exceeded before the calculation process has been completed. Once a location
fails within a batch, the locations preceding the failed location will also fail. It is best to create multiple
calculation batches containing no more than 100 locations in each batch.
Figure 47: Batch requests
Best Practice
To determine which locations failed within the batch and to see the individual processing times, you can view
the Requests tab of WFM Cal culation Servi ces. Note the hyperlink RWR_SCHED_PLUS1 in the lower
section; it is the name of the batch processing that location.
Figure 48: Analyzing batch requests
Monitoring
Obj ect
Selection
Cri teri a
Satellite System
Data Collection
Schedules link Calculations
Status Link
Provides
success, warning
or error status
Enterprise portal
Link provides additional
data for resolving
warnings and errors.
Weekly, as schedules are
WFM Calculation
Services Link
Requests tab Status column:
Error
Enterprise portal Weekly, as schedules are
submitted for calculation.
WFM Calculation
Services Link
Batch Requests
tab
Status column:
Error
Enterprise portal Weekly, as batch schedules
are submitted for calculation
Tabl e 18: Scheduling creation Further monitoring objects
Best Practice
2.4.2 Business process step 2 and 3: Schedul ing maintenance and analysi s
2.4.2.1 Description
The schedule has been calculated, and now the maintenance and analysis phase can start. The maintenance
phase entails reviewing the schedule, correcting scheduling exceptions, and making edits to the schedule.
The Store 600 schedule calculation process was completed with warnings. The store manager knows that
schedule exceptions are monitored by corporate and therefore must take steps to minimize the number of
schedule exceptions prior to schedule posting.
The initial monitoring is done in the enterprise portal by inspecting the Daily, Weekly, or Individual iView
contained within the Schedules tab.
Error monitoring for schedules is done at the daily, weekly, or individual employee level.
Schedule calculation completed with warnings that indicate work rule constraints were broken and need to be
corrected. Not all exceptions must be corrected. It is the managers responsibility to decide which exceptions
are allowable.
While viewing the schedule for individual employees, a yellow triangle listed beside the name is an indication
of an exception in the corresponding schedule calculation.
Figure 49: Identifying exception in Schedules view
Click on beside the employee name to view a list of issues and resolutions.
Best Practice
Figure 50: Analyzing the exceptions summary
Employees assigned to multiple work areas will be displayed in all work areas assigned. Shifts within the
selected work area are represented by the dark blue segments. The lighter blue segment indicates that an
employee is scheduled in a different work area than the one you are viewing. By placing your cursor over a
shift segment you may perform edits by extending or shortening the bar. In the exception sample, Donna
Milone is scheduled more than the maximum hours allowed in a shift. This exception can be reconciled by
shortening her shift segment.
Figure 51: Shortening a shift segment
Below is a table of possible schedule exceptions and solutions:
Employee Excepti ons Solution
Scheduled more than the
maximum hours allowed in a shift
Check if the maximum hours per shift work rule is correctly defined.
Edit schedule to decrease the number of hours scheduled.
maximum hours allowed in a week
Check if the maximum hours per week work rule is correctly defined.
maximum hours per shift on a
weekend
Check if maximum hours per shift on a weekend work rule is correctly
defined.
Edit schedule to decrease the number of hours scheduled on a
weekend.
Best Practice
Employee Excepti ons Solution
maximum days allowed in a week
Check if maximum days per week work rule is correctly defined.
Edit schedule to decrease the number of days scheduled.
maximum consecutive days
Check if maximum consecutive days work rule is set appropriately.
Edit schedule to decrease number of consecutive days scheduled.
Scheduled less than the minimum
hours required in a week
Check if the minimum hours per week work rule is defined correctly.
Check that the employee is available to work the minimum hours per
week.
Check if business need is sufficient to schedule the employee.
Check if employee is available to work when there is business need.
Edit schedule to increase the number of hours scheduled.
Scheduled outside availability Check if availability and work rules are not in conflict.
Verify if availability maps to fixed/set schedules or rotations.
Check availability constraints to ensure schedules are within
availability.
Edit schedule to be within availability constraints.
Scheduled outside work area
hours
Verify if work area configuration is accurate.
Check if demand falls within work area hours.
Check availability and work rule minimums.
Scheduled for overtime hours Verify employee is eligible for overtime.
Check availability for scheduled period.
Edit schedule to eliminate overtime.
Exceeds the maximum overtime
hours allowed in a day
Check if maximum overtime hours per day work rule is defined
correctly.
Exceeds the maximum overtime
hours allowed in a week
Check if maximum overtime hours per week work rule is defined
correctly.
Edit schedule to decrease the number of overtime hours scheduled for
the week.
Tabl e 19: Possible schedule exceptions and solutions
The WFM user can decide to allow any schedule exception created. When encountering an exception, check
that the exception is correct. Work rules entered into configuration need to be verified for accuracy.
Exceptions are specific and need specific actions to be alleviated. For example, the scheduled more than the
maximum hours allowed in a shift exception instructs you to check the maximum hours per shift work rule is
defined appropriately.
Best Practice
In the portal, go to Workforce Management Schedules Individual Work Rules. Donna Milone is
assigned work rule TA_FT_NONEDIT, which allows 8 hours per shift defined as a maximum. The WFM user
needs to verify that Donna Milone is assigned the correct work rule. If the employee is assigned the correct
work rule, verify that the values assigned to the work rule are correct. If the values are accurate, the schedule
exception is appropriate and needs to be corrected to comply with corporate approved work rules.
Figure 52: Checking work rules
If the employee is assigned an incorrect work rule, go to Workforce Management Employees Schedule
Rules Work Rules to assign another work rule. Permanent changes to an employee are done from the
Employee view. Changes made on the Schedule view are only effective for a temporary period.
It is possible that a work rule was entered incorrectly into configuration. Work rules are not editable from the
portal. Configuration for work rules is found via the path SAP IMG Retai l Workforce Management
Schedule Settings Work Rules. Enter the correct value(s) into configuration, press Save. Changes will be
displayed in the portal as soon as configuration updates are scheduled.
In the Daily view, you have the following modification options:
Add Segment
Swap
Replace
Add Coverage
Clear
Add Breaks
Best Practice
Figure 53: Daily view
Add Segment allows you to add a shift segment to cover understaffing.
Check the box beside the name and press the Go button to add a segment to an employee. In the sample
below, a segment was added to Abel Garreau.
Figure 54: Adding a segment to an employee
Best Practice
To accommodate an employees sudden change in availability you can swap an employee shift with another
employee shift within the same work area.
Select the two employees you want to swap shifts for. Press the Swap button.
Figure 55: Swapping shifts
The replace functionality is used to find employees to replace an unplanned absence.
Select the employee you want to replace, and press Repl ace. A listing of employees eligible for replacement
will appear. Select an employee from the list to replace the absent employee. You may also select the
Absence Type of the person being replaced. Press Determine Potenti al Exceptions to see if the new em-
ployee will cause a schedule exception. If not, press Apply Segment(s) to add the employee to the schedule.
Figure 56: Replacing employees in case of absence
Best Practice
Add Coverage allows you to find employees to cover a specific time frame.
Press the Add Coverage button. Drag and extend the shift segment to the time frame that you need to cover.
Press the Replace button to find employees available to cover that time frame.
Figure 57: Finding employees to cover a specific time frame
Select an employee from the list to cover the time frame selected. Press Determine Potenti al Exceptions to
see if the new employee will cause a schedule exception. If not, press the Apply Segment(s) button to add
the employee to the schedule.
Figure 58: Adding new shift elements to a selected employee
Clear is used to remove a shift segment. Select the employee(s) that need to have their shift removed. Press
the Clear button to remove their shift segment.
Figure 59: Removing a shift segment
Best Practice
When a segment is added manually, you must also add a break manually. Select the employee and press the
Add Breaks button. Breaks are not optimized when added manually. The user must allocate the break
placement to ensure it aligns to corporate guidelines.
Figure 60: Adding breaks manually
Monitoring
Obj ect
Selecti on
Criteria
Alert Analysis Tool on Satellite System Monitoring
Frequency / Data
Collection
Schedules link Daily or
Weekl y iView
Schedul e
Excepti ons
icon
Enterprise portal
Icon provides information regarding
schedule exceptions and how to
reconcile them
Daily or weekly,
after schedule has
been calculated
Tabl e 20: Scheduling maintenance and analysis Further monitoring objects
2.4.3 Business process step 4: Schedule posting
2.4.3.1 Description
Schedule maintenance and analysis is complete. Posting a schedule signals to corporate that all
modifications are complete and the schedule is ready to be processed.
The store manager agrees to the schedule and wants to post it inside the store. To post a schedule, simply
check the box beside the wordPost and press Save.
Figure 61: Schedule posting
Best Practice
Monitoring Object Sel ection Criteria Alert Analysi s Tool on
Satel lite System
Monitoring Frequency /
Data Collection
Schedules link Weekl y iView
Post check box
Schedule
posting fails to
save
Enterprise portal Weekly when schedule
analysis/changes have
been made.
Tabl e 21: Schedule posting Monitoring objects in SAP Solution Manager
Best Practice
3 Further Information
3.1 Troubleshooti ng
If executing this Best Practice did not produce the desired results:
Use the comprehensive problem solving and server testing information in the WFM 3.0 Installation Guide.
Alternatively, see SAP Note 1032669. This note contains all notes produced for WFM 3.0 SP02 feature
pack. See also SAP Note 1068936, which contains all notes produced for WFM 3.0 SP03 service pack.
Search customer messages and SAP Notes with the component CA-GTF-WFA.
If you experience slow reaction times within the portal, it may be due to a lack of space allotted to run the
software. The official WFM sizing documentation may be accessed by going to: Service.sap.com SAP
Support Portal Quick Links Sizing SAP NetWeaver SAP NetWeaver in Detail Solution Life-
Cycle Management Hardware Sizing Sizing Guidelines Solutions & Platform Sizing WFM
3.2 Related Best Practice Documents
There are several other Best Practice documents that relate to this Best Practice document. They are
available on SAP Service Marketplace at https://service.sap.com/solutionmanagerbp. These documents are:
Best Practice General Business Process Management: This document explains the procedures you
should use to create a general Business Process Management concept. This includes the definition and
documentation of the core business processes, definition of monitoring objects, definition of monitoring
activities including error handling procedures, monitoring tools, monitoring frequencies, the definition of
communication and escalation procedures and the assignment of responsibilities.
Best Practice ALE Monitoring: This Best Practice helps you set up an Interface Monitoring concept with
the focus on ALE monitoring for your SAP solution. This document will outline possibilities on how to
optimally monitor ALE-based interfaces manually as well as automated by using SAP Solution Manager.
Both monitoring approaches aim to detect any irregularities or deviations or to detect error situations at an
early stage.
Best Practice Job Scheduling Management: This Best Practice provides a detailed description of what
SAP recommends as a standardized formal process to support a job request process, including an end
user job request form and an approval process. This integrated process will avoid error-prone and time-
intensive manual processes of copying redundant data from one data source to another (for example, MS
Excel to job scheduling tool).
Best Practice SAP Business Process Management for ERP Logistics: This Best Practice helps you set up
a Business Process Monitoring concept for your SAP ERP solution. The concept aims at defining
procedures for business process-oriented monitoring and error handling and escalation procedures for
your companys ERP core business processes. These procedures intend to ensure a smooth and reliable
flow of the core business processes so that your business requirements are met.
Best Practice Background Job Monitoring with SAP Solution Manager: This Best Practice will help you to
set up background job monitoring properly in the Business Process Monitoring framework of SAP Solution
Manager.
Please note that these documents are also available in the SAP Service Marketplace using alias RunSAP
Run SAP Best Practices.
Best Practice
Index of Figures
Figure 1: Alert type Number of ABAP Dumps (Delta) 10
Figure 2: Monitoring objects Dialog performance 11
Figure 3: Monitoring alerts - Dialog performance 11
Figure 4: Monitoring objects and alerts Application log 12
Figure 5: Monitoring alerts Application log/Critical messages 13
Figure 6: Analysis and monitoring transactions 13
Figure 7: Analysis and monitoring URL 14
Figure 8: Business processes in WFM 18
Figure 9: Business process Employee maintenance 20
Figure 10: Changing employee master data 21
Figure 11: Maintaining employee profiles 24
Figure 12: Checking new employees profiles 24
Figure 13: Error WFM agent profile update failed 25
Figure 14: Checking work rules 30
Figure 15: Maintaining shifts 31
Figure 16: Maintaining time-off requests 32
Figure 17: Business process Business forecast and workload modeling 34
Figure 18: Reviewing forecast data 36
Figure 19: Modifying volume data 37
Figure 20: Determining forecast parameters 38
Figure 21: Checking the calculation status for forecast progress 40
Figure 22: Messages for calculation status for forecast progress 40
Figure 23: Accessing forecast calculation log files 41
Figure 24: Requests tab in WFM Calculation Services 42
Figure 25: Batch Requests tab in WFM Calculation Services 43
Figure 26: Updating volume forecasts 45
Figure 27: Checking the progress of the volume forecast 46
Figure 28: Messages for calculation status of the volume forecast 46
Figure 29: Applying budgetary constraints 48
Figure 30: Changing forecast indicators 50
Figure 31: Message for calculation status of volume adjustment 50
Figure 32: Reviewing the volume adjustments per location 51
Figure 33: Selecting the adjustment type 51
Figure 34: Changing the workload 52
Figure 35: Message for calculation status of workload adjustment 53
Figure 36: Reviewing the workload adjustments per location 53
Figure 37: Approving a forecast 55
Figure 38: Steps of the scheduling business process 57
Figure 39: Individual iView 58
Figure 40: Creating events 59
Figure 41: Events in the Individual view 60
Figure 42: Calculating schedules manually 60
Figure 43: Pre-analysis results 61
Figure 44: Calculation 61
Figure 45: Calculation status 62
Best Practice
Figure 46: Copying schedules 62
Figure 47: Batch requests 63
Figure 48: Analyzing batch requests 64
Figure 49: Identifying exception in Schedules view 65
Figure 50: Analyzing the exceptions summary 66
Figure 51: Shortening a shift segment 66
Figure 52: Checking work rules 68
Figure 53: Daily view 69
Figure 54: Adding a segment to an employee 69
Figure 55: Swapping shifts 70
Figure 56: Replacing employees in case of absence 70
Figure 57: Finding employees to cover a specific time frame 71
Figure 58: Adding new shift elements to a selected employee 71
Figure 59: Removing a shift segment 71
Figure 60: Adding breaks manually 72
Figure 61: Schedule posting 72
Index of Tables
Table 1: Personnel actions/receiving employee master data Monitoring data in SAP Solution Manager 22
Table 2: Personnel actions/receiving employee master data Further monitoring data 23
Table 3: Maintain employee profiles Monitoring objects in SAP Solution Manager 26
Table 4: Maintain employee profiles Further monitoring objects 27
Table 5: Maintain work areas and qualifications Monitoring objects in SAP Solution Manager 28
Table 6: Maintain work areas and qualifications Further monitoring objects 29
Table 7: Maintain schedule rules Monitoring objects in SAP Solution Manager 31
Table 8: Maintain schedule rules Further monitoring objects 31
Table 9: Maintain time-off requests Monitoring objects in SAP Solution Manager 33
Table 10: Maintain time-off requests Further monitoring objects 33
Table 11: Adjust actual volume data Monitoring objects in SAP Solution Manager 37
Table 12: Performing the initial forecast calculation Monitoring objects in SAP Solution Manager 43
Table 13: Performing the initial forecast calculation Further monitoring objects 44
Table 14: Update volume forecast Monitoring objects in SAP Solution Manager 47
Table 15: Update volume forecast Further monitoring objects 47
Table 16: Apply budgetary constraints Further monitoring objects 54
Table 17: Approve forecast Monitoring objects in SAP Solution Manager 55
Table 18: Scheduling creation Further monitoring objects 64
Table 19: Possible schedule exceptions and solutions 67
Table 20: Scheduling maintenance and analysis Further monitoring objects 72
Table 21: Schedule posting Monitoring objects in SAP Solution Manager 73
Best Practice
Copyright 2009 SAP AG. All Rights Reserved
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG.
The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries,
zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM
Corporation.
Oracle is a registered trademark of Oracle Corporation.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix
Systems, Inc.
HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts
Institute of Technology.
J ava is a registered trademark of Sun Microsystems, Inc.
J avaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by
Netscape.
MaxDB is a trademark of MySQL AB, Sweden.
SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their
respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All
other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves
informational purposes only. National product specifications may vary.
The information in this document is proprietary to SAP. No part of this document may be reproduced, copied, or transmitted in any form
or for any purpose without the express prior written permission of SAP AG.
This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This document
contains only intended strategies, developments, and functionalities of the SAPproduct and is not intended to be binding upon SAP to
any particular course of business, product strategy, and/or development. Please note that this document is subject to change and may
be changed by SAP at any time without notice.
SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of the
information, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind,
either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-
infringement.
SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that
may result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence.
The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you may
access through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide any
warranty whatsoever relating to third-party Web pages.

Manage Operations For SAP For Retail - Workforce Management 3.0

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Manage Operations For SAP For Retail - Workforce Management 3.0

Загружено:

Авторское право:

Доступные форматы

BP_MO_for_SAP_for_Retail_Workforce_Management_V30.doc 22.04.

Вам также может понравиться