|
|
|
To
Overview of Composite Applications Edition
| Print version | |
Related Links |
|
| Using Prototypes | |
| Prototype-Based xApps Design Process | |
| SAP xApp Knowledge Network – From the Idea to the Product | |
Background Links |
|
| SAP Developer Network | |
By Annette Haeussler, SAP AG – October 20, 2003
As the need of companies to drive greater productivity from their employees increases, employees are still expected to stay motivated, well trained, and aligned with the mission and goals of the corporation. However, our customer workshops revealed that breakdowns often occur and that the following pain points are a continuous challenge for companies:
SAP xApps Employee Relationship Management (ERM) delivers employee-centered solutions that empower people to be more productive. Like all SAP cross applications (xApps), xKN (Knowledge Network) and xEPM (Employee Process Management) target the customer needs by not starting from a transactional business scenario but rather from a people-centric work process. Collaborative activities and their artifacts are offered within the context of the corresponding business scenario to help employees to work and collaborate efficiently in a complex people and information network. ERP functionality, such as transactions and analytics, and collaborative services are integrated as needed to support this business scenario. The result is a software product that directly addresses individual and collaborative needs and creates a synergetic value significantly beyond traditional applications.
Because all employees can use SAP xApps ERM immediately without having to attend expensive and time-consuming training classes, it provides immediate benefits to an organization. In the following, the process from vision to the final xEPM product is described.
With the help of the central GBUX Design Group, the GBUX attaches great importance to usable designs. From numerous site visits, usability tests, reviews, evaluations, customer activities, and brainstorming sessions, the idea for xEPM was born:
What if you could set up, execute, monitor and manage business processes? If you could leverage your employees' productivity? If you could guarantee consistent, intuitive, and best-practice business processes in your company? If you could manage your process portfolio? If you could measure employee-centric business processes? If you could make it easier for your employees to set up and execute business processes in their daily work?
A product that answers the questions above should offer a flexible, highly functional workflow environment that enables users without specialized software development skills to easily set up and execute collaborative business processes by providing reusable templates, assisting users with data proposal and allowing ad-hoc changes at runtime.
As stated in the very first edition of the Design Guild – in the Article "What Does User Integration Mean for Software Design?" – it is important that new design ideas are tested with users to ensure that the design truly fits the users' needs. User input can and does help to settle design issues and lead to improvements in the design.
The product definition of xEPM began in fall 2002, when SAP xApps ERM was established. In the first weeks, we devoted our time to brainstorming sessions, discussions, and visualizing the ideas and concepts by means of wireframes and PowerPoint-based prototypes. The design was iterated and reviewed continuously based on the feedback from the prototype.

Figure 1: Wireframe SAP xEPM
After gaining a sound shared understanding of the general product concept, the next step for our mixed team of designers, product management, and developers was to create an early HTML prototype that reflected the concept and that helped in assessing whether the product really matched the customers' needs. This prototype was first shown at the HR/FI Congress 2002 in Karlsruhe, Germany and was embraced with extremely positive feedback from our customers. The prototype was tested in parallel internally in different areas by the central xApp design group. We all gathered valuable input for improvements and feedback about possible business areas in which this tool might be helpful.

Figure 2: First SAP xEPM Prototype
Using the prototype and feedback, our developers and product management started writing a specification for our new product SAP xApp EPM. In parallel, we redesigned parts of the prototype to adapt it to the functionality described in the specification. The redesigned prototype was tested again at ASUG 2003 in New Orleans, United States.
The new application SAP xApp EPM focuses on improving employee productivity by streamlining frequently occurring tasks – with a powerful and flexible tool for defining and managing workflows. At the same time, it is as well suited to everyday work processes, such as arranging meetings and travel bookings, as it is to longer term work procedures.
It fully integrates with existing enterprise-wide employee directories, ensuring the right person is selected for each task. At each step of a particular process, the relevant team members are automatically alerted about the jobs assigned to them. Additional messages and any relevant documents can be attached and the intuitive user interface allows for modifications to be made at any time. If, for example, users do not have the time, they can simply delegate a task to an equally capable colleague. And if a process becomes too complex to manage, it can be split into a number of smaller sub-tasks.
The user interface also allows process owners to track the status of each activity, enabling them to monitor whether work is completed on time. Process managers also benefit from improved transparency. They can quickly identify any inefficient areas and initiate corrective measures. In this way, companies can accelerate day-to-day work, while encouraging the ongoing, collaborative improvement of their processes.
New procedures can be defined by administrators, business owners, or end users with very little implementation effort and a rapid return on investment.
The part of the xEPM that supports the execution, but not the definition, of business processes is called runtime. A runtime example for a process that can be implemented using xEPM is "New Hire Provisioning" as shown in Figure 3. In this example, a new employee is integrated into the team. This involves requesting a user for him, selecting a workspace, ordering equipment, inviting him to team meetings, and so on.
Figure 3: Screenshot – Runtime Example xEPM (taken from updated prototype)
The UI differentiates phases (which are sequential and similar to a milestone) and steps belonging to that phase. Steps define the task someone has to complete. Steps can be sequential or parallel and optional or mandatory. Every step has a processor who is responsible for completing the task. The processor can choose from several ad-hoc steps that are contextual to the current step. Figure 3 shows how the processor can also delegate the step to somebody else.
The action that is linked to a step is a reusable component in itself. A room booking for example can be reused in several process templates, such as "Organize Meeting," "Plan Workshop," and so on.
The design time, the configuration part of xEPM, is a Web-based tool for modeling processes by editing predefined templates or by creating new templates. Figure 4 shows the predefined process template of "New Hire Provisioning" in the design time.
Figure 4: Screenshot – Designtime Example xEPM
Our prototype-based design methodology enforced by the xApp Design Group meant additional effort at the beginning and required some "openness" toward new ways of implementation. But the result was worth it: The early involvement of the design group in the development allowed our product managers to show the prototypes to customers and get their feedback on missing features in an early state – even early enough to add additional features to the product. Product management also used usability tests and walkthroughs for raising interest in potential customers. Our developers used the prototype as a kind of living specification (including the user interaction) or to cross-coordinate requirements and work packages between different development teams.
Ultimately, our final success will be measured by the acceptance from our users, who will get a tailored product that supports them in completing their tasks efficiently and that they really enjoy working with.