Skip to Content
Product Information

SAP ‘ Z Process Re-Engineering’ – Enhance the productivity of the implemented solution

Before reading this blog, ask below questions.

  1. Can you get Z process details in 15 minutes from the system for all modules?
  2. Are Z process unorganized in system?
  3. Are Errors for Z process not captured since inception of program?
  4. Documents related to Z process are difficult to find and understand?
  5. As a consultant, are you facing problem in understanding Z process and its documents despite KT?

If response to any of the above question is affirmative than go through this blog. This might help you.

Overview

Purpose of this blog is to describe the ’Process Re-Engineering’ concept, its solution, its benefits and all other aspects related to it. This blog is just a recommendation to enhance the productivity of the implemented solution.

Sap is a value creating ERP which provides best platform to meet any business requirement. Its upon implementing partner, consultant and the client to leverage its benefits. If unplanned, badly designed and poorly executed, it may create huge problems.

Disclaimer: This concept is neither implemented nor tested for any client. This idea I came across  with my experience on large clients and thought of sharing to community. This could help someone, somewhere in our SAP fraternity.

Below is the Scope of the blog.

  1. Problem
  2. Test
  3. Components of Z Process
  4. Solution
  5. Benefits
  6. Efficiency Check

Let’s start to understand the whole process.

  1. Problem

I encountered this problem in large clients. In large clients, we often encounter problems with Z processes. There may be clients where more than 80% of process are Z. I have developed/implemented many Processes and those are easy to implement. But problem arises when

  • Documents related to this process are unavailable/scattered in drives.
  • There are no linkages of the process with the available documents.
  • Documents updating process is irregular/incomplete.
  • And many more problems could be there.

During initial days of project, KT is scheduled for specific period. Along with KT, documents are shared for all topics/processes. KT is completed and actual execution begins. Issues for Z Process begins and following problems are faced:

  • How to trace the issue?
  • From where to initiate the analyses of the incident?
  • To check the documents shared during KT (which are always incomplete. Something is always missed out).
  • Or Search document in the drive
  • or Search in past email.
  • or connect with some other consultant for help.
  • or received new documents which were not explained in KT.
  • or no overview for Dependant process

Here is the actual problem. With such a huge platform of SAP, why things are scattered? Why things are not at one place? Millions are spent to implement and support SAP, but still there is unnecessary struggle to trace the relevant information for the process. Client is unable to derive maximum benefits out of SAP. Client is still frustrated and dependant on specific person for documents. Why this happens? Go to next step.

2. Test

To understand the above problem, carry out below test to check if SAP implementation is creating expected value to the client. If responses are negative, then idea to analyse existing system and to carry out ‘Process Re-engineering’ project should be considered.

  • How many Z Process are there in your module?

If response is received in 10 to 15 minutes or reasonable time with the list of Z Process, means things are better and under control. If responses are like ‘We need to check drive, or we need to send email to all teams, or we need to connect to so and so person who worked in this project for so long’ then optimum solution isn’t implemented.

After 5,10,15 years of implementation if no real time information is available for number of Z Process and its document, programmes, tcode, FS, TS, its unacceptable. Things should be under control in organised way.

  • Which document (FS or TS) is related to which process?

If response received is ‘See the document shared or Search the drive and read the document’. This is again negative. Most of the drives are unorganized. In most cases, naming convention for this document are not standard and this leads to problem for linking the document with its respective process. We need information with one click at one location.

  • Which programme is attached to a Tcode?

Connect with technical team or check in the system or in transaction code. Negative.

  • How many errors are received since inception?

No records. Trust me this can be captured and improved. This is the most important aspect of Zprocess. If similar error is received 3 years back for this process, where is the record?

If you observe above questionnaire, this indicates that things are unorganised. This unorganized approach has leaded to less efficiency, less productivity on the part of consultant, implementing partner and the client. Maximum benefits are not derived. Everything should be at one place and at one location.

  1. Components of Z Process

To understand/implement solution, knowledge of the following components of Z Processes is must. This may differ from client to client.

  1. Transaction code and description.
  2. Programme name
  3. Functional Specs
  4. Technical Specs
  5. Dependant entries.
  6. Error resolution
  7. Test Data
  8. Video recording.
  9. Status
  10. User Manual
  11. Flow chart.
  12. …………could be many more.

Are above components centralised?

In most of large organisation where Z processes are implemented, above components are scattered. This is the root cause for all problems. SAP standard problems, errors and updates are taken care by Certified consultants. But for Z processes, due to mismanagement things may go out of control or need additional time to trace document and resolve the issue.

Implement the below simple solution and derive maximum benefits of SAP.

4 Solution

‘Process re-engineering’ solution can be implemented with below 2 approaches.

  1. Simplified/Centralised approach

Create one Z table (with tcode) with below columns. Collate all information at one place as shown below. This is just an example and can be adapted from organisation to organisation. Complete information of all process is stored in one table. FS, TS, error since inception, User manual, Test data and any other information. With this solution there will be no need to access drives, folders, emails. No need to connect to Technical team for programme name. Any issue received; it can be easily traced with respective process. This will give a centralised control and view for entire process. Create executable button, means once you click on it will take to execution screen. For e.g. Transaction field. Click on it and will take to execution screen.

Module Process name Transaction code Programme name FS document TS Document Dependant Master data Error Library Test Data Process Video Recording

Status – Active/

Inactive

FI GL ZFBL3N Customised report Uploaded Uploaded NA Executable Uploaded Uploaded Active

Most important is Error Library. Once error is received, it should automatically flow to Error Library. There should be minimum 2 columns. Error and its resolution. For the error received, it should not allow to execute the next run of programme, until resolution column is populated with solution implemented. In long run this will create database with all errors and resolution time will be quicker.

    2. Unified transaction code approach.

This is a creative solution in line with above solution. Only presentation will differ.

Create one transaction as ‘Process’ or any other tcode. Cover all existing process in that transaction code. This is a unified approach. See below example.

Create one Transaction as ‘Process’ (this may differ….). It should take to below screen with main process. FI, SD, MM, PP and PM.

Note: SAP screen is unavailable as solution isn’t developed so PPT was used to explain this concept. Consider below screenshots as SAP screen.

Click on FI above. It should give you below output.

Click on Process 1. It should give below component at one place. This is just an example and can be adapted from organisation to organisation.

If you notice, all above information in any organisation may be scattered. Searching the document, linking with the programme, identifying errors since inception etc. is cumbersome. Consultants, during initial days in support project spend maximum time in above activity. Now all information is at one  place. If organised approach is adopted, consultant can start working immediately and maximum benefits can be derived in long run.

5 Benefits

Following are the benefits of process re-engineering project.

  1. Centralised Repository of all information related to each process.
  2. Better control and ease of access.
  3. Simplified approach.
  4. Reduced KT time.
  5. No more scattered searching for the documents.
  6. No need of drives to store documents.
  7. Faster learning and execution for each process.
  8. Prompt tracing and resolution of error.
  9. Controlled updating of FS/TS documents.
  10. Visual overview of transaction processing leading to ease in conceptualising the process.
  11. Higher productivity and job satisfaction for consultants and employees.
  12. Could result in Reduction in attrition.
  13. Enhanced productivity for IT department. Can divert focus to other critical areas due to controlled process.
  14. Realtime information for existing processes by all concerned parties.
  15. Reduced maintenance cost.
  16. Less dependency on highly experience consultant resulting in cost saving.
  17. Could lead to job satisfaction.
  18. ………and could be many more.

6 Efficiency Check

Post implementation of above solution, carry out Efficiency Test. Note below points.

  1. Tickets
    1. Identify issues taking more resolution time. Categorize those in A, B and C. A is highest number of issues received, B is moderate, and C is least.
    2. Post implementation check if the numbers are declining.
  2. Resolution time.

Compare the resolution time before/after of this solution.  Take the test data and compare the effectiveness.

3. Consultant dependency.

Routine errors captured in Error Library with solution will help end users to understand the problem in advance. This will allow SAP consultants to focus on more important task. Check if users can identify problem without the help of Consultant.

For e.g. Cost Center not in Asset Master. New user will check the Error Library and understand the actual problem.

With this even if one customer is benefited, than writing of this blog is worth for me.

I hope you like this document.

Regards

Zunaid

 

 

2 Comments
You must be Logged on to comment or reply to a post.