Copyright © 2003 Americas’ SAP Users’ Group SAP Workflow Implementation Management Dale Davis...

Copyright © 2003 Americas’ SAP Users’ Group

SAP Workflow Implementation Management

Dale Davis Jones: IBM Business Consulting Services

Martin Maguth: dolphin IT-Project & Consulting Corporation

5/19/2003

Agenda

1. Introduction

2. Project scoping

3. HR integration

4. User integration

5. Security

6. Quality Assurance

7. Roll-out preparation & implementation

8. Post-production support

9. Q&A

Agenda

1. Introduction1.1. What is Workflow/Webflow?

1.2. Critical Success Factors

2. Project scoping

3. HR integration

4. User integration

5. Security


7. Roll-out preparation & implementation


9. Q&A

Introduction – Definition “Webflow/Workflow” (1/2)

“Workflow is the automation and simplification of business processes supported by information technology.”

Reference: Windows NT Journal 1997

Introduction – Definition “Webflow/Workflow” (1/2)

Executive Sponsorship

Business Requirements Analysis

Managing Expectations

Scope Control

Process Design

Effective Testing

Training

Change Management

Introduction – Critical Success Factors

Agenda

1. Introduction

2. Project scoping2.1. Issues and challenges

2.2. Things to consider

2.3. Solution approaches

3. HR integration

4. User integration

5. Security


7. Roll-out preparation and implementation


9. Q&A

Project Scope - Issues & Challenges

Process selection

Requirements gathering

Project Sizing

Risk Management

Project Scope - Things to Consider

What process should we select ?

What does the process really look like ?

Does the current process need redesign?

What are the requirements from the business side ?

Are we gathering requirements from business process subject matter experts?

How much time should we allocate for the project ?

Project Scope - Solution Approaches (1/4)

1st level process selection:

Highly structured

High degree of coordination

Several users involved

Range of activities

Routine, similar tasks

2nd level process selection:

ROI

System support

User support


Requirements gathering:

Perform VERY detailed, critical process analysis

Ongoing involvement of KEY functional decision makers

Encourage users to evaluate and design business process

Expectation management:

Define measurements for project success

Basic workflow education of functional users early on

Make NO promises you might not be able to fulfill

Explain the solution CLEARLY as EARLY as possible


Preliminary Analysis

Design Test Implement

Test Cases DefinedUser Acceptance Test with Security Profiles

Completed

Key Deliverables

Processes & Outputs DefinedResponsibilitiesIdentified

Org Plan CreatedProcess WalkthroughCompletedSizing Completed

Key Deliverables Key Deliverables

Task Breakdown CompleteBOR Objects Identified

Agent Assignment Logic Defined

Functional Spec CreatedDetail Design Document

Flow Modelled and Function Tested

with Process Analysts

Key Deliverables

End User Training DeliveredWF Objects & Org Plans transportedProduction UsersAssigned to Organizations

Set Exit Criteria for each project phase

Based on Clearly Defined Deliverables


Agenda

1. Introduction

2. Project scoping

3. HR integration 3.1. Issues and challenges



4. User integration

5. Security




9. Q&A

HR integration – Issues & Challenges

Organization Structure Maintenance

Managing HR Relationships

Organization Plan Ownership

Transporting Organization Plans

HR integration – Things to Consider

Who owns the maintenance of the Organization Plan? Is HR implemented or planned for future implementation?

Is an Organization Plan necessary?

How volatile are the business organizations?

Where should Organization updates be performed?

HR integration – Solution approaches (1/5)


Organization Plan Ownership : Ownership can be a sensitive issue, but HR usually has much more

stringent rules regarding the organization

The workflow team is responsible for maintaining the organization plan when only workflow organizations exist in the system

The HR team owns the maintenance of all organization plans if HR org plans are being used This usually applies even if HR was implemented after workflow

If HR is part of the initial deployment strategy, collaborate with the HR team on the organization design to avoid conflicts and rework

If HR is deployed later, some workflow org plan redesign may be needed

Regardless of who owns the maintenance, strong communication between the teams is critical

Organization Plan Ownership Survival Kit : Educate the HR team on Workflow use of the organization plan

and the impact to workflow when it changes

Gain agreements that HR org changes are communicated and visible to the workflow administrator

Agree on a turn around time for agent assignment updates


Is the Org Plan really necessary? HR module does NOT need to be implemented

If you need flexibility and choices in your agent assignment then the org plan is the way to go

But you don’t need an org plan, if you keep your agent assignments simple You can use distribution lists, responsibilities, custom tables and function

modules

You can also assign tasks to security roles


Designing for Org Changes: Define a maintenance plan for your org structure

Preferred method: Create all org structures in development and transport structural updates to production Assign agents to positions in Production System

Block agent assignment overrides using transaction OOCR

Plan ahead for organization growth and create extra empty positions during the initial deployment

Alternative approach After initial deployment perform all organization updates in production

Use ALE to keep development systems in synch


Agenda

1. Introduction

2. Project scoping

3. HR integration

4. User integration4.1. Issues and challenges



5. Security




9. Q&A

User integration – Issues & Challenges

Workitem delivery

Integration of SAP and non-SAP users

User support

User integration – Things to consider

How do we get the workitem to the users ?

How do we integrate non-SAP users ?

How many workitems are we expecting ?

What are the processing times ?

Do we need a workflow administrator ?

User integration – Solution approaches (1/4)

Workitem delivery options: SAP workplace

Email inbox

Internet inbox

SAP workplace with notification to email or internet inbox

Non-SAP workflow engine


Arguments: High volume SAP users (> 5 -10 WIs/day) ALWAYS access WIs

via SAP workplace

Low volume SAP users SHOULD access WIs via SAP workplace whenever possible; email notification possible

High volume non-SAP users MUST get SAP access

Low volume non-SAP users MAY use other means of participation in the workflow

=> Use SAP workplace whenever possible to avoid interface and performance issues !


User support: YES, you need an administrator (... and not just as a user ID in

the workflow basis configuration)

Train the administrator BOTH as technical AND as functional user

Workflow is often time critical, so carefully select the administrator’s authorization profile


Agenda

1. Introduction

2. Project scoping

3. HR integration

4. User integration

5. Security & Authorization

5.1. Issues and challenges






9. Q&A

Security and Authorization – Issues and Challenges

Workflow runtime system customizing

WF-BATCH ID authorizations

Workflow administrator basis authorizations

Workflow Users and Office Communication

Security and Authorization – Things to consider

How do you ensure that WF-BATCH id has sufficient authorization?

Should the workflow administrator be allowed to configure the workflow runtime system?

Who will do workflow archiving?

Is there a conflict if a workflow administrator is also a developer?

What workflow authorizations should be given to which users?

Security & Authorization - Solution Approaches (1/5)

Survival Kit: Avoid making the system so secure that no work flows Make friends with your security administrator

Give them a demo of workflow runtime system customizing Show them why the logical destination is needed

Be prepared to meet them half way

Explain that WF-BATCH is a background id

Show that users cannot execute transactions for which they are not authorized through workflow

Explain why workflow Archiving is necessary

Repeat the above steps with the Basis team


WF-BATCH id creation and authorization This is a background id : It needs to be able to do whatever the

workflow developer and workflow runtime system asked of it

Keep it simple give it SAP:ALL and SAP:NEW or equivalent authorization

Document in the Basis team’s desk procedures that locking this id is really not a good idea

Ensure that whoever sets up this id includes the RML communication type with all of the parameters filled in

This makes sending mail much easier

Someone needs to be able to maintain this password in production or at minimum synchronize the password with the Workflow local destination password


WF-Administrator Authorizations: YES, the WF-Administrator should configure the workflow runtime

system They are responsible for the smooth running of production workflows

Monitoring the RFC logs is a necessary part of their job

They need to start workflows in production if necessary

The WF administrator should do the workflow archiving unless Basis will follow the workflow archiving procedures to the letter

Unless Security team is going to maintain office functions for workflow users on demand then the workflow admin should do it

Workflow Development & Administration could be viewed as a Separation of Duties conflict - Train an administrator


Workflow Users: SAP workflow users need access to office functions

Business Workplace access is key

Give all workflow users the same basic workflow profile At minimum workflow users need to be able to execute, display and forward workitems

Add special authorizations to selected user groups Super users may need access to assign agents to org structures or to view workflow

logs


Agenda

1. Introduction

2. Project scoping

3. HR integration

4. User integration








9. Q&A

Quality Assurance – Issues and challenges

Development Standards

Test Strategy

Transport Considerations

Post System Maintenance Validation

Quality Assurance – Things to consider

Are your developers trained in workflow design ?

Do you have self documenting workflows?

Does your test strategy include testing with production level profiles?

Have you provided end users with enough training to test effectively?

What transport sequence should you use?

Do you have validation checklists for after transports or after scheduled basis system activity?

Quality Assurance – Solution approaches (1/5)

Setting Standards for Development: Ensure development team is trained in workflow

development and configuration

Define naming conventions for workflow objects

Establish clear coding and configuration guidelines

Ensure workflows are documented completely including within the workflow template description where possible

Provide guidelines for documenting object type code

Ensure workflows are generated prior to transport

Perform formal development signoff including users


Winning Test Strategies: Design test cases that test both positive and negative scenarios

Validate workflow runtime system and run workflow diagnostics before beginning test

Test for exceptions

Document test case results thoroughly

Test with ids that have production level profiles not just super ids


Transport Considerations: Verify transport sequence listed by basis team matches

yours

Ensure all workflow objects are generated prior to transport

Check transport logs after transport for errors

For BOR object types, ensure custom message classes for method exceptions are also transported

Run diagnostics on workflows after transports using SWU7

Set up entries in org override table using OOTR to block agent assignment overrides


Post System Maintenance Validation: Multi Development System Landscape

Prepare a post system restore checklist for the basis team to ensure correct workflow object ownership

You want to ensure that correct number range Prefix is assigned to correct development client

Test and Production Systems After a homogeneous client copy

Check runtime system using transaction SWU3

Check workflow number ranges

Check event type linkage tables for event linkage

Run diagnostics using SWU7 & SWUD


Agenda

1. Introduction

2. Project scoping

3. HR integration

4. User integration








9. Q&A

Roll-out prep and implementation – Issues and challenges

Roll-out strategies

User and administrator training

Go-Live support

Should we roll-out as a pilot or to the whole user community ?

How much should we invest in training ?

How should we train users ?

When should we train users ?

Do we need go-live support ?

Roll-out prep and implementation – Things to consider

Roll-out prep and implementation – Solution approaches (1/3)

Pilot roll-out: VS.

Roll-out to small, targeted user group

Pro’s: Quick go-live, more qualified feedback, more transparency, change management, low risk

Con’s: Sometimes tough to determine pilot users and scenarios, longer go-live, more training, slower ROI

Complete roll-out:

Roll-out to entire user community

Pro’s: Condensed training, quicker ROI, one phase go-live

Con’s: Change management, go-live support, less transparency, high risk


Training:

Spend a LOT of time on user training

Make sure users are comfortable with technology, terminology, and workflow engine

Use user acceptance test to reinforce training

Provide administrator with technical AND functional training

Go-Live support:

Make sure administrator understands EVERYTHING

Provide administrator with documentation on troubleshooting and archiving

Have workflow developer onsite during initial phase of go-live


Agenda

1. Introduction

2. Project scoping

3. HR integration

4. User integration





9. Q&A

Monitoring & Reporting: See how users actually use

workflow within the first 6 months of implementation

Check for workflows that are not being processed for extended periods This may be an indicator of a

education gap

Ensure users know who their support contacts are and are using them

Check that archiving schedule is aligned with actual production workitem volumes

Change Management: Use same validation

procedures as initial deployment after post production transports

Ensure fast path transport approval process is in place to manage Org Plan growth

In R/3 releases prior to 4.6, generate a new version of your workflow in development after your production transport to ensure version integrity

Educate users on changes that are being applied before they are applied

Post-production support

Support

Some Closing Thoughts: Workflow projects can be fun and rewarding learning experiences for

project managers, users and developers when done well

High user acceptance, almost always drives requests for more workflows

Misconceptions are the thief of workflow project time EARLY overview training for sponsors, users, project managers, security and

basis is key

Don’t guess: Get expert help at least initially when determining scope, schedule and budget

Hire an experienced consultant

Read ‘Practical Workflow for SAP’ by Rickayzen, Dart, Brennecke and Schneider

There is a WEALTH of information to be found in this book

Communicate key design points often to users

Copyright © 2003 Americas’ SAP Users’ Group SAP Workflow Implementation Management Dale Davis...

Documents

Transcript of Copyright © 2003 Americas’ SAP Users’ Group SAP Workflow Implementation Management Dale Davis...