R/3 Organizational Management allows you to configure and define objects and relationships to create non-hierarchical views of your organization. These views go across departmental and business lines and they provide more efficient reporting, task management, and resource planning. You can use matrix organizations in R/3 to display large, complex organizations or small, project-based groups.
Key Concept
The use of matrix organization structures in businesses of all sizes is not a recent phenomenon. Case studies on the design and use of matrix hierarchies date back to the 1960s and early 1970s when companies such as Xerox, General Electric, and Dow Corning were among the first to tout the benefits of cross-functional, matrix-driven organizational structures. For these large conglomerates, the allocation of key resources and functional roles across multiple business lines allowed greater productivity with fewer resources, which ultimately translated into a more favorable bottom line.
Many businesses have turned to a matrix organization structure to track use of resources across traditional functional, departmental, and product line boundaries. A matrix can also map micro-organizations such as project and team structures within an overall organizational structure. In both cases, a main goal is to save money by avoiding duplication of effort.
With all the possible uses for matrix organizational structures, I’m going to address two questions: What is a matrix organization structure and how can you use R/3’s Organizational Management functionality to depict it? Then I’ll show you how to configure a simple product-based matrix.
What Is a Matrix?
A traditional organizational structure is typically built in a top-down hierarchy. The power in the organization resides at the top and the lines of responsibility flow from the top to the bottom throughout the individual branches of the structure. In this type of organizational design, responsibility for different business functions is usually not shared outside of major business sectors or divisions. In addition to the clear chain of command, a traditional structure has stronger departmentalization and narrower spans of control. This leads to duplication in skills and responsibilities across the organization.
Figure 1 shows an example of a hypothetical product organization viewed through a top-to- bottom organizational structure. Note the duplication of core functional skills across each product line.
Figure 1
Example of traditional product line organization structure
A matrix organization eliminates this duplication of skills and responsibilities by identifying functions or common components that are shared by multiple divisions, projects, or products. An organizational chart that allocates skills or resources across the sectors or divisional components as needed portrays the cross-functional nature of this organizational design. It creates a multi-functional team approach rather than a group of somewhat redundant functional skill sets. Figure 2 shows an example of a product-based matrix organization.
Figure 2
Example of a product-based matrix organization
Matrix organizations provide clear accountability within a specific business function and allow more efficient allocation of specialized skills across the entire business. By taking advantage of the shared services and skills and not having to develop and manage those skills themselves, the divisional or product line organizations can better focus on their core business objectives. This last point was one of the original driving forces behind the development and popularization of matrix organizations. Today, matrix organizations are used to describe more than just the product-based organization shown in these examples. For example, many IT project managers use smaller matrix-style structures for project and team organizations to track skills, tasks, and resources across multiple projects to ensure skills and resources are used properly.
Building a Matrix in SAP R/3
A matrix structure in R/3 does not replace the organizational hierarchy. Instead, it supplements that structure by allowing you to display and report on relationships and task assignments among entities that do not normally appear in the day-to-day organizational setup. R/3 uses organizational objects, relationships, and evaluation paths to create the matrix structure. You choose which objects — custom or standard — and relationships define that output. As an example, I’m using R/3 Release 4.6C to build and use a product-based matrix to reflect my hypothetical example in Figures 1 and 2. You can do it in three steps.
Step 1. Define your matrix type. Because many different types of matrices are possible, you must first define what type of matrix structure you wish to build. Matrix types define the two dimensions of the matrix, including which object types make up each axis and which evaluation path you use to read the existing structure to form the matrix. Finally, you specify the relationship between the two dimensions that indicates their inclusion in the matrix. R/3 comes predelivered with a standard matrix type of Legal, but for my example, I created a new type called Product Line.
To create a new matrix type, access table T779M via IMG menu path Personnel Management>Organizational Management>Matrix Organization> Define Matrix Types (Figure 3). You first enter a name and text description for your custom matrix type.
Figure 3
Creating a new matrix type in table T779M
Next, define the two elements that make up the structure. Think of the vertical and horizontal axes of the matrix, which are the two fundamental building blocks from which you display and report on the structure. If you think of the matrix in spreadsheet terms, dimension 1 objects form the rows, while dimension 2 objects make up the columns. In my example, I’m using organizational unit (Object type O) and an object type called Product Line (custom Object type Z9). This allows me to assign specific organizational functions to multiple product lines. Standard relationship B401 identifies to which product lines the organizational units are assigned.
You may need to create custom objects, relationships, or evaluation paths when building a matrix. You can build custom objects such as the Z9 Product Line object in table T777O via transaction code OOOT (IMG menu path Personnel Management>Personnel Development>Basic Settings>Maintain Object Types).
Relationships are unique three-character alphanumeric codes that define the interaction between two different objects, whether they are objects of the same type or two different types. You configure relationship codes in table T778V via transaction code OOVK (IMG menu path Personnel Management>Personnel Development>Basic Settings>Maintain Relationships). Because product line is a custom object, configuration must specify the allowed relationships between the organizational unit and the product line. You do this through the Allowed relationships option in table T778V.
Evaluation paths contain a series of instructions that tells R/3 to look for particular object relationships and report back the results or to use the results in a predetermined manner. R/3 contains a large number of predefined evaluation paths in table T77AW. However, if your matrix reporting requirements necessitate a structure view that is not contained in these predefined evaluation paths, you can create a new evaluation path by accessing table T77AW. You do this via transaction code OOAW (IMG menu path Personnel Management>Personnel Development>Basic Settings>Maintain Evaluation Paths).
Step 2. Establish valid relationships among all objects to be included in your matrix. For the desired objects to appear in your matrix, they must contain valid relationships linking them as you indicated when you configured your matrix type. In my example, I specified relationship A/B 401 to link organizational units and product lines. I used standard object maintenance transaction PP01 to link them prior to viewing the matrix.
Step 3. Use transaction PPMS to display your matrix. Once you have defined your matrix and established relationships among the requisite objects, you can view the matrix structure using transaction PPMS or access the matrix via standard R/3 menu path Human Resources> Organizational Management>Organizational Plan>Matrix. When you access transaction PPMS (display) or PPME (change), a dialog box asks you to specify either a matrix type or a variant or to use the standard selection screen that is not specific to any type (Figure 4). Setting a variant saves you time if you frequently display or report on the same matrix view.
Figure 4
Access matrix organization dialog box
Tip!
Choose your validity dates carefully when creating your object relationships. You need to specify a validity period when viewing or changing the matrix structure, so the dates in your object relationships dictate which appear in your matrix output.
The matrix selection screen (Figure 5) allows you to specify your desired Matrix type, Object ID for each dimension in your matrix, and the Validity period for the display. If you leave an object ID blank for a dimension, all objects that are related to the other dimension object are included in your output. You also have the option of viewing each dimension individually in hierarchy format or viewing the matrix itself.
Figure 5
Specify the desired Matrix type, Object ID for each dimension in your matrix, and the Validity period for the display in the matrix selection screen
After entering selection parameters, press F8 or click on the execute icon. The output you requested, Structure dimension 1, Structure dimension 2, or Matrix view, will appear. Figure 6 is an example of the matrix view. As you can see in the output for the product-based matrix I created, the units in dimension 1 are the rows while the product line objects make up the columns. At each intersection between organizational units and product lines in the matrix, validity dates indicate a valid relationship. A blank box means that the two objects that intersect at that spot have no relationship in the validity dates you specified in the selection screen. From within the matrix view, you can also toggle back and forth between dimension view and matrix view as well as refresh the output.
Figure 6
Display view of product-based matrix
Examining the output in Figure 6, you see that the same organization shown in traditional hierarchy in Figure 1 has been transformed into a matrix structure. The functions that had previously existed in each product line are now shared functions across product lines. Figure 6 also shows that not all functions need to be in all product lines.
A.J. Whalen
A.J. Whalen has successfully combined more than two decades of global business expertise with in-depth experience in the strategic development, management, and delivery of large-scale projects and education for SAP ERP HCM. Prior to his current role as SAP Marketing Director at Velocity Technology Solutions, he served as lead consultant for several global SAP implementations and engagements as well as an SAP Conference Producer for Wellesley Information Services. A.J. has been invited to speak at nine annual SAP educational events and holds an MBA degree from the Stern School of Business at New York University.
You may contact the author at whalen.aj@gmail.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.
