Alignment from Policy to Application - 3

Business Processes is the key layer in the Human Capital Architecture. It is where HR people work, it is the context or domain where all the integration across the macro HC Architecture is designed to be effected in a micro context (in each business process). It is therefore important that the HR Organisation adapt Business Process Management (BPM) as a preferred standard management practice. 

To repeat my favourite statement in this context: HR People work in HR Processes delivering HR Customer Results, using HR Applications.

It follows that the design, documentation and implementation of well-designed HR business processes are perhaps the single most important Key Performance Area for the HR Architect. There cannot be any talk of an integrated, macro Human Capital Architecture when the integration is not established on the micro or business processes layer. The specific method to design HR business processes should duplicate the macro Human Capital Architecture Framework, this is the origins of the "Process Architecture" methodology.

To establish BPM, the HR Architect's first port of call is to assist the HR Director to disseminate the comprehensive People Value Chain into dedicated Process Areas and allocate a specific HR Process Owner to each of these areas. The number of areas that are identified in such manner is not important, the allocation of full accountability for the management of the process areas, is. From a HR service delivery perspective, the process area dissemination can also be based on HR Transactional processes and Talent Management processes - as meta-level categories.

HR Transactional business processes include Organisation Management, Personnel Administration, Time Administration, Travel Administration and Payroll Administration. The content represented within Organisation Management within the information system or application layer form a foundational basis for integration across the People Value Chain. Therefore it is important to identify and include here all those HR business processes that executes job analysis, job profiling, competencies, etc.

Talent Management business processes include those processes relating to the acquisition, skills training and development, performance management, career & succession planning, employee wellness, employee relations, etc.

From a HR service delivery model and channels perspective, it is crucial to first decide and design the specific new HR operational model and channels that will form the foundation for the delivery of services via HR business processes, before embarking on the business process design work, if not, the processes will have to be redesigned when the new structure is decided upon and implemented. To determine which processes will be delivered through which structure - for example will this be a Shared Services process, a Center of Expertise process or a Business Partner (HR Operations Team) process, should ideally also be facilitated beforehand during the implementation of the new service delivery structure or HR operational structure.

The HR Architect must guide the HR business processes design and implementation efforts within the HR organisation, and will work hard to to ensure a standard design methodology (Process Architecture), standard documentation templates for the Business Process Description Document, standard tools used in the design such as MS Visio, as well as a standard workshop format, for example ensuring that the specific HR Process Owner, the Process Team members, the HR Business Process Consultant and the Functional Information Systems Consultant is present during the design workshops. 

Line Managers should be present, representing the operations customer group, but due to operational requirements or time constraints, this role could be facilitated by the HR Architect. There are several advantages of having the functional systems consultant (such as a SAP HCM Consultant) as part of the  business process design team and workshop. The HR Process Owner and his/her team get the opportunity to ask the systems consultant questions relating to the functionality available in the application as well as how specific functionality will enable a specific HR business process or part thereof.

The goal of the above-mentioned workshops is to analyse and redesign all possible HR business processes, whether currently in existence or not. When taking a HR Process Team through an As-Is business process analysis workshop before addressing the redesign, creates a very positive change effect as it introduces the team to process-centric thinking and principles of integration.

As the new redesigned business processes will form a significant part of the business blueprint for the configuration and implementation of the HR information system, the formal approval of the new business processes by the Process Owner is essential. Should the HR information system be implemented already, but lacks integration with the HR business processes, then the new business processes (integrated with system functionalities) will form a substantial business case for the re-implementation of the HR information system - in the majority of cases, HR business processes were not developed as basis for the business blueprint for the configuration and implementation of the HR information system.

In summary:

• The focus of the design and integration of HR business processes is on empowering the HR people (service delivery teams) to design their new way of work;
• Their active participation in this design work, contributes significantly to the expansion of their knowledge, the visibility of their customers (both internal and external) as well as the insight into where and how the HR information system aligns with their work;
• The introduction of BPM as a management practice afford the HR people with regular opportunities for continuous improvement and innovation, therefore contribute to the active engagement of them in their work;
• Teams work in processes and small teams are the building blocks for successful transformation;
• It offers them the opportunity to assist in the simplification and lessening of the complexities in the work domain when considering things such as information systems;
• It shows them how the execution of their work process influences the quality of HR data & information and therefore makes a direct impact on the quality of HR services to the business; and
• it makes visible and material the customer results that the process teams deliver and ensures positive feedback loops from the HR customer groups to the HR process team.   

Alignment from Policy to Application - 2

The development of  Data Models and Templates as the second component that requires purposeful alignment and integration and is an essential work that the HR Architect must execute. This is especially relevant in the case of highly integrated HR information systems such as SAP. Although these systems are pre-programmed or pre-developed systems, they do not automatically contain data templates and content that need to be designed and built during the planning or business blueprint phases of the implementation project.

There are basically two parts to the design and development of data models and templates. The first is the Data Model Design that does not require any information system work, therefore lies in the domain of business or HR. The second part is the Data Model Design that will require information system work, and will require the attention of functional system consultants.

For purposes of this discussion, I will use the Integrated Job Profile as an example - to be sure, it is a very relevant example. In SAP, the integrated job profile is a highly integrated data model that integrates with almost all the Talent Management functionalities, but it is compiled within SAP from a number of tables, that are built from a number of catalogues and therefore one cannot talk of a single job profile template in SAP.

Building an integrated data model that supports and enables the Talent Management activities starts with workshops with the specific HR teams responsible for the Talent Management business processes. The objective of the workshops should be to design and document the integrate Talent Management data model and to do a data breakdown structure that identifies all the key components of the integrated job profile such as the tasks, qualifications, competencies, etc. and documenting those in catalogue format for capturing into SAP.

When the non-system data model has been designed and approved by HR, the HR Architect must engage with the functional system consultants who will, in context of the catalogues, determine how the integration will be achieved on the data layers using the standard system functionality available. This will see the identification and configuration of "services" from the integrated job profile to the various talent management areas such as Career & Succession Management, Training & Development, etc.

Alignment from Policy to Application -1

The objective of aligning the different dimensions present within the HR organisation necessitates the adoption of an integrated HR service delivery perspective. This perspective is made practical by using an architecture approach when attempting to establish said alignment. One of most daunting challenges facing the HR architect is to ensure that there is deep integration between the HR policy layer and the specific HR information system in use. Even more daunting is the work required to establish the above-mentioned alignment when the HR information system is not yet implemented.

The opportunity presenting itself in the latter scenario (when preparing to implement a HR information system) must not be overlooked in the face of the above-mentioned challenge. Should the alignment be achieved just before the blueprint phase of the implementation project, the more successful the system implementation will be - something that is not at all guaranteed, even if the most prudent process is followed to select the implementation services partner.

The HR architect's first priority is to discover all the HR and related policies that are present in the organisation. Making an assumption that all policies are updated and available in a central repository with easy access, is exactly that - an assumption. More often than not, HR and related policies are not updated and lack documented version control confirmation, could differ substantially in format,  and there could be a lot of duplicate policies, etc. Each individual HR policy should be confirmed and signed-off by the specific policy owner who officially has the authority and allocated accountability for policy development and implementation. 

This work could form the basis for the first facilitated workshops with all the relevant policy owners in HR. Should there be policies that are outdated or not enforced for some reason, the HR architect must request that the policy owner engages with the necessary stakeholders and finalises the specific policy via the governance process.

Therefore, part of this first stage in the alignment could be to decide and document a HR policy documentation management strategy and governance process in the instance where such strategy and process are not in operation.

Taking the offical People Value Chain as reference, the HR architect must now ensure that a set of Business Rules are designed and documented for each individual HR policy. A Business Rule has two perspectives: one is an information system perspective that governs the way in which the content of the policy via the business rule will be represented in the information system environment; the second perspective is a behavioural perspective that directs the behaviour of people when executing their activities associated with the specific policy. The latter perspective is known as the traditional "policy and procedures" in HR, but has since been replaced  by business processes.

The format for the documentation of business rules should be standardised to ensure efficient governance and version control that should in turn, be aligned with the governance and version control of the HR policies as indicated above. For each rule developed, there should a risk assessment and consequence of non-compliance to the rule.

Developing System Rules from the Business Rules is essential as system rules will direct people's behaviour  with the information system, specifically regarding the capturing and maintenance of data. As indicated in a previous post, the integrity of HR data is of utmost importance to ensure the quality of HR services. When conducting workshops to discuss and develop Business Rules, it is important that the policy owner, the process owner and the system consultant be present to actively contribute to the developement of such rules.

The HR architect must initiate and drive the development of business rules and must ensure that all business rules are considered during the development of system rules. The system consultant must indicate in each individual system rule whether the information system will automatically guide the HR user to capture data via a specific manner or convention, but if not, then it is imperative that a system rule must be developed with a risk and governance portion attached to it.

The importance of the systematic development of business rules cannot be overstated. Initiatives around Governance, Risk and Compliance (GRC) in the HR domain must be dealt with as a priority. There are a number of HR policies that carries substantial risks to the organisation in the case of non-compliance. The development, documentation and migration of business rules into the information system via well-developed  system rules as well as into the business processes will ensure the day-tot-day complicance to all HR policies.

Next: Alignment from Policy to Application - 2, looking at the Data Models and Templates.