I was reading the A Process Flow for Introducing and Disseminating A Business Process Change and its comments and was especially interested in Marilyn Pratt‘s comments: “Functional consultants are gradually moving out of an application specific silo-think to a more horizontal process-think and there are some that see that as the role of a BPX, bridging not only IT and business but also bridging to a more cross-functional horizontal way of thinking (process across applications and functions). “
This is an excellent point but I started considering what is the current reality based on the existing SAP toolset. If these cross-functional processes are going to brought to life, what environment will be used (assuming that the processes involve human interaction)? Probably Guided Procedures (GP). (The discussion of whether BPX themselves GP or another more technical role are going to be design processes using has this task is a matter of another blogSOA Project Overview – Building Composites – Roles and Skills ).
If we are talking about large organizations, there are probably multiple GP designers working on different processes. If there no guidelines in place, this design environment will at some point become chaotic and inefficient. Thus, there must be some structure in the GP design- and runt-time environments; otherwise, the costs involved with maintaining this environment will be exorbitant.
Other goals involve the need to reduce complexity for those individuals using this environment. This is critical, because as Enterprise SOA and BPM become more popular, the number of processes with their associated objects will increase dramatically. Thus, it is necessary to consider theseissues before user start creating processes.
This blog is a first attempt to describe such guidelines.
Caveat 1: I would love to have this blog be full of best practices about how Guided Procedures (GP) should be used in a large organization. However, the use of GP in an Enterprise SOA environment is still relatively new; therefore, this blog can just contain suggestions and ideas on how this environment should look like.
Caveat 2: This blog is based on the current GP environment (I am currently using SP8) and of course doesn’t reflect future developments. I would like to emphasize that I think GP is a great tool with lots of potential. However, there are definitely areas that need to be improved in order to assure its usefulness in larger organizations.
What are the important factors that influence the use of Guided Procedures (GP) in a large organization? Let's consider a company that has more than two organizational units (divisions, etc.). These units have separate processes; have processes that are shared by each other (global processes) and processes that are the responsible of one unit but involve other units. This organizational structure might also be based on regional units (for example, units based in Europe, Asia, Africa and North America).
The assumption is also that these units are all sharing one Web Application Server (WAS) including portal. I will discuss distributed GP scenarios in a later blog.
In this blog, I will also compare the GP design and runtime environments with the Portal Content Directory (PCD). My first portal was an Enterprise Portal V 5.0 and I have worked with many versions of the SAP environment since then. I have learned the importance of structure and usage guidelines in association with the PCD and I think that similar guidelines are also necessary for GP usage. As this blog will describe many of the important characteristics of the PCD that are useful in large organizations, are not currently available in GP. I will describe these shortcomings as well as propose workarounds.
If you look at GP, there are three main user types that are involved There are end-users who have no access to design or runtime environments - these are users who are involved in processes usually via UWL but have usually have no ability to design or create tasks. (Of course, a company policy could be that “end–users” can use the GPRuntime as well but I am assuming that this not the case). The Runtime role is used to execute guided procedures actions. The Designtime role enables you to build guided procedures. Most of the comments in this blog refer to the Designtime environment.
A quick aside: In daily operations, an interesting question concerns which users have the runtime role? These users can initiate processes for which they have permissions. Since there are some processes (for example, vacation request, absence request, etc.) that are relevant for all users, do all users have this role?
There are other roles, especially those dealing with administrative tasks (transports, monitoring, etc.), that might be affected by such organizational structures but they will not be discussed in this blog.
What areas should be considered when using GP in an organization with more than two divisions/regions?
Folder structure
In order to physically separate the processes and their respective components of the two units described in our initial scenario, there should be two folders at the root level (Sales, Manufacturing, Finance, etc.) plus a third folder that is called "Global". This last folder includes the processes that are accessible to all individuals in all divisions. Subfolders should be separated into themes. Themes could be project based or of a more general nature. The lowest layer is broken into the following categories. Callable Objects, Blocks, Actions, Content Packages. These folders include the objects of the appropriate nature. Processes are placed directly in the theme or project folder level.
This structure is also used in the examples provided by SAP.
Another idea might be the use of a utility folder that includes those elements that are theme-independent and might be shared between processes or divisions. The question whether this utility folder would be at the root level or within a specific unit's folder is also valid. There are other related questions (common to most environments where re-use is important) that would must be answered. For example, who maintains these utility elements? Do they originate from units themselves or some organization that is independent of organizational structure? These are interesting questions that every organization must answer for itself based on its experience with software re-use.
Roles
Information regarding GP roles has been described in Setting up Roles for CAF, GP and Visual Composer as well as in the SAP Help pages. The question is how to relate these roles that are actually organizational structure independent (this is obvious as SAP could never deliver roles that are specific for a certain company or type of company) to the needs of this organization.
I think the roles that are more important are those associated with particular rights and permissions.
Dependent on which roles an individual has, the GP UI is influenced. Inasmuch as it is currently not possible to use non standard roles to influence the UI, this decision must be made in a way that is independent of the organizational structure - that is relevant for all units. This means that all those involved must agree on what functionality should be available for a certain type of user – suggesting that there is agreement on what an “expert” or “advanced user” means.
There are currently two UI characteristics that can be influenced:
- A global decision must be made regarding which callable objects are available to which designtime user type. This is performed with the Manage permissions screen (configure the permission level, you go to the Administration Workset and open General / Manage Permissions.).
- A global decision must be made regarding which UI functionality is available to which designtime user type. This is performed with the Manage permissions screen (configure the permission level, you go to the Administration Workset and open General / Manage Permissions.).
Each organizational unit must categorize its users into these different designtime types. This categorization is not easy and is based on subjective characteristics that may not be equal between units with different corporate cultures. (Of course, a centralized corporate unit may be responsible for all GP designwork but as the number of processes increase and the desire for some organizational units to be more responsible for their own processes develops, then this might not be acceptable).
In addition, each unit needs to have its own roles that are domain-specific and relate to those roles used in processes.
Permissions
If you have various folders that belong to different organizational units, then it is currently not possible to limit access at a folder level via permissions. This means that the entire folder structure is visible to users who may not have access to the objects contained in the folders. Of course, it is possible to place permissions on GP objects (as I will describe below) to limit their visibility, but the visibility / presence of these folders themselves gives users the ability to place their objects in the folders of other units / themes that may be inappropriate (from an organizational perspective).
If you look at the PCD (as an example of successful implementation of authorization usage), it is possible to place permissions on folder objects to limit access. This is one characteristic that has proven its importance in a number of projects / organizations.
At the GP object level (Processes, Block, Action, etc), it is possible to limit access based on permissions (In the default configuration, you need the GP Expert User Role to be able to see the permissions tab). For example, one division might limit access to processes to just design users from its division (SalesGPDesigners, etc.) . I would suggest using Groups instead of Roles to deal with such permission related topics. Thus, divisions users from other divisions can not see (and thus use) these elements. Of course, if process re-use is desired than other policies are necessary.
For a description of these permissions, see the SAP Help description.
Other considerations / points for improvements
- It is currently possible to publish processes from the Personal Folder into any other folder in the GP environment. This functionality is currently not revocable. This might lead to the problem that the created folder structure could be subverted leading to chaotic structures as well as potential security hazards based on the malicious / unintentional publishing of processes.
- In order to better structure the GP content, mandatory naming conventions should be used. In the PCD, there is the possibility to create suffixes as well as IDs. This is is currently not possible in GP. Therefore, an optional use of terms should be used. For example, Blocks begin with BL, Actions with AC, etc. (I am not to happy with this convention but currently I can’t think of any better suggestion) Further information regarding the Organizational unit may be useful in the Object Name. This may also help increase the quality of re-use scenarios, when it is necessary to know who developed / maintains these elements.
- Search functionality in GP presently limited to folder structures. Users must manually hunt through folders to find the elements desired. Better search functionality is necessary to be able to share process elements and as process usage increases with the resulting increase of elements to dig through. I think the ability to search for certain object types like in the PCD would be useful. Furthermore, the ability to search for ID, name, description, etc would be also quite valuable. (I am planning a blog on searching in an Enterprise SOA environment soon to describe my ideas on this topic in more detail)
Summary
As I mentioned at the beginning of the blog, I think that GP is a great tool that has a lot of potential. In my opinion, it plays an important part of Enterprise SOA strategy for SAP. Thus, it is critical to discuss the issues that relate to its usage in a real setting. I hope this blog leads others to explore related areas. I am currently in the process of writing other blogs in this area in order to achieve this goal.
2 Comments
