Wednesday, August 17, 2011

Questions and Answers

Please elaborate on the background of the Human Capital Architecture?
The development of the Human Capital Architecture started with fundamental questions such as "How will the Information Age change our world, how will the economy change and how will organisations be impacted as a result?" - and subsequently: "How will the role of HR change in this new context?"

 These questions and the search for their answers started a journey of almost ten years during  which some questions were answered, new questions emerged, were answered again and subsequently all that became known culminated into a practically applicable model and methodologies and finally tested during business advisory consulting projects at client companies.

 Why the term “architecture”? Where does it come from?
The Human Capital Architecture is based on the theoretical models and principles of Enterprise Architecture (EA). Enterprise Architecture is described in Wikipedia as: “…a rigorous description of the structure of an enterprise, its decomposition into subsystems, the relationships between the subsystems, the relationships with the external environment, the terminology to use, and the guiding principles for the design and evolution of an enterprise. This description is comprehensive as it includes enterprise goals, business functions, business process, roles, organisational structures, business information, software applications and computer systems.”

Within an architecture approach there are key concepts to adapt that ultimately provides the reason for such an approach and also guides the efforts during the design and implementation of a Human Capital Architecture:
  • Alignment;
  • Integration;
  • Change; and
  • Time-to-Value
 The fusion of the modern, global network organisational structure, distributed management functions and essential relationships (suppliers, customers, shareholders, partners and employees) with information and communication technologies, necessitates a systems view (as in systems theory) of all the subsystems and their dynamics in order to achieve deep integration between them and in the process make the inherent complexities more manageable.

This “systems view” of the network enterprise is achieved through the systematic use of EA frameworks, tools and methodologies.

 Why is an “architecture” approach useful for HR?
The inherent complexities of matching the HR strategic mandate and talent services demand with an efficient service delivery organisation, makes the transformation of HR extremely challenging. A new approach that adequately meets these challenges was found within the domain of Enterprise Architecture, and by adopting the principles of EA to create a "domain" HR architecture; a business-oriented model for the successful transformation of HR has emerged.

When the HR function isolates itself from established business-based, management practices such as customer centrality, business process management, continuous improvement, adoption of information systems, master data management and information management (business intelligence); then it does not mirror the rest of the enterprise to which it is supposed to deliver quality services. 

Does Human Capital Architecture only support Talent Management execution?
No, Human Capital Architecture describes, implements and maintains all possible activities within the comprehensive People Value Chain or commonly known as the Employment Life Cycle – literally from budgeting and planning a position in the organisation structure, to the exit interview.

 Who will be responsible for the Human Capital Architecture in an organisation?
The first step towards the establishment of a Human Capital Architecture is the appointment or allocation of a HR Architect. As a HR initiative, the HR Architect should report to the Head of HR, alternatively to the Chief Enterprise Architect of the organisation.

To be successful, the HR Architect needs to be actively involved in the following architecture “layers”, but only from the design, implementation and maintenance points of view:  
  • HR Strategy and Strategic Objectives Development;
  • HR Service Delivery Models and Service Delivery Channels, such as HR Portal, Self-Service, Shared Services, Centres of Excellence or Expertise, HR Business Partners;
  • HR Service Delivery Teams Structure;
  • HR Business Processes Design (HR Transactional and Talent Management);
  • HR Data & Information Structure (Business Rules, System Rules, Data Templates);
  • HR Applications (ERP grade HRIS such as Workday, SAP, Oracle, etc.) and 
  • HR Technology Infrastructure.
 Is this not a role for the IT department or its Business Analysts?
Similar to the HR function, IT has a clear service delivery mandate as a support function to business. From this perspective, IT serves HR within a service-based relationship and in accordance with a specific mandate that guides their services to HR in context of an agreed-to implementation roadmap over time.

In addition, the IT department normally focus on providing specific guidance with regard to the overarching Enterprise Architecture that are designed to describe and execute the Enterprise Business Strategy as an integrated system, as well as the specific ICT strategy that are a subsystem of the above-mentioned EA. 

Some companies have also chosen to remove the Enterprise Architecture responsibility from the IT department and have allocated it to the highest level or management function responsible for Business Strategy and Execution. By nature non-HR subject matter experts, the IT department cannot and should not carry the ownership for the design, implementation and maintenance of the Human Capital Architecture.

 Traditionally Business Analysts work with identifying business requirements for purposes of developing information systems for the business – in most functional areas. With pre-programmed information systems such as the ERP-types, Business Analysts are usually involved with the design of the business blueprint, ensuring the ERP consultants incorporates the business context via processes in the said business blueprint documentation. 

Again, giving the HR department ownership of its Human Capital Architecture necessitates the insight from a HR subject matter expertise. To be sure, Business Analysts do have very valuable skills that could and should be used during the design of the Human Capital Architecture, but the role of the HR Architect is much more evolved.

 What are the competencies for a HR Architect?
In our experience the HR Architect should have had a substantial HR generalist career of at least 10 years (as a minimum) – the combination of HR subject matter expertise and business maturity is essential, as is solid experience as a HR Business Partner providing valuable insight into what and how to deliver HR services to Operational Business Units.

The above-mentioned experience should then be complimented with hands-on exposure to initiatives such as Business Process Management (BPM), Continuous Improvement (Six-Sigma, etc.) and the implementation of HR information systems (Integrated ERP-types such as Workday, SAP, Oracle).

Although the role requires an “unique” combination of skills, training and experience, success will depend on the personal ability to use systemic thinking to make connections between things and concepts that do not seem to be related nor integrated off-hand. 



Monday, August 23, 2010

Babylon Revisited

Peter Block's words on transformation includes the terrific statement that all transformation is linguistic, meaning also that all transformation is indeed social of nature.

Visiting Jaap Schekkermann in Zoetermeer in 2007 hearing him say that all data contains language objects and that language represents one of the greatest challenge for any Enterprise Architect.

Reading the Gilbane Research on Multilingual Communications as a Business Imperative, confirming the rise in explicit customer demand in numerous global markets for content in their language of choice, as well as the importance of relevancy that ultimately drives the customer experience.

When customers request service or discuss their buying decisions, the linguistic moment of truth appears. Should there be a significant disconnect between the language that the customer uses to articulate his/her wishes and that of the person presenting the product or providing the service, chances are that the sale will be lost.

Businesses articulate their strategies and objectives using a specific combination of words that linguistically builds definitive meanings. In turn, strategic objectives are "translated" into scorecards and policies that are transformed into business rules that guides the structuring and documentation of things like business processes and activities. Business rules are also the basis upon which system rules and formulas are created to ensure that data captured into the system is captured according to those rules.

From an information systems perspective, the language objects in the modern ERP-type applications contain dictionaries with terminologies that have been selected by the developers of the application, not necessarily those used by their clients. The specific definition and subsequent meaning of the terminologies embedded in the language objects of the data might therefore radically differ from the terminologies that are commonplace in a specific business and generally understood to have a specific context and meaning - as expressed or embedded in the business rules.

Using HR information systems (ERP) as an example, the term "headcount" for the executive management team might carry a distinct definition and shared understanding, but for the stakeholders reading the company's annual report, it could have a different definition, and for management and HR teams it could again refer to a specific formula used when calculating Full-time Equivalent (FTE).

How to solve this dilemma?

Enterprise Architects work hard to ensure the standardisation of things like the technology infrastructure, the applications platform and the business processes and therefore when facing the challenge to standardise the language throughout the architecture, they might be hard-pressed or inclined to take the data dictionaries in the application(s) as the standard, thereby converting the comprehensive language of the business and its customers to a system-based language.

When faced with this specific dilemma recently, a client company went back to the drawing board and made business (and in this case, the HR department) fully accountable for the compilation of a HR Data Dictionary that identifies, defines and contextualises or make relevant all the HR terminologies that are typically in use within the company on a day-to-day basis. In addition, the company hired the services of consultants to add a "best practice" or "good practice" approach to the effort. To ensure the standardisation across the architecture, the company then expanded the business-oriented HR data dictionary to include and match the corresponding language objects in the data of their HR applications.

The nature of customer services is integrated information, and quality of customer services is measured against the consistency and reliability of those services. It follows then that the same quality measurements apply to a business's data and information. To achieve this, yet another dimension has become evident, that is the alignment and consistency of meaning of the language objects used in the total architecture - from the application to the presentation layer at the user interface, right through to the customer.

Tuesday, May 25, 2010

Its not about the system

The HR teams at client companies usually have very specific and elaborate requirements for a Human Resources information system. Working with client companies one often gets the distinct impression that such clients view the new HR information system to be the complete and comprehensive answer to most of their HR service delivery challenges and problems.

To be sure, most ERP-type HR information systems do have rich functionality and in terms of its programming principles are horizontally (end-to-end business processes) highly integrated. The combination of robust functionality and integration capabilities on the data layer, makes such systems extremely attractive, especially given the fact that HR is forever trying to satisfy its own and that of its customers' need for updated and validated HR related information across the people value chain.

Furthermore, ERP-type HR information systems are a lifetime commitment and it is an expensive  venture, both from a licensing as well as an implementation point of view, substantially increasing the expectations that the HR team(s) have of such an integrated HR information system. Also, increasing service delivery demands from operations place additional pressure on HR to take the initiative to invest in an information system that could deliver the HR services reliably and consistently.

Usually the HR business requirements mirror its current organisation and activities, focusing firstly on the HR Transactional process areas such as Personnel Administration, Time Administration, Payroll Administration and Employee Benefit Administration. Next follows the requirements around the typical Talent Management processes such as Recruitment, Training and Development; Career and Succession Planning, Performance Management, Employee Relations and Employee Health and Safety.

In both the Transactional and Talent Management areas clients often require Self Service functionality. There is a substantial number of Employee Self Service and Manager Self Service functionalities that, when successfully implemented, empower individual employees and operations managers to apply for, approve and execute (via workflow designs using role based authorisation profiles) HR related activities and services.

The implementation of HR information systems is often the first step in the redesign of the HR organisation in context of "HR Transformation". Because of this, the information system agenda usually includes the establishment of HR "best practices" across the HR organisation, and this is regularly sold as "part of the package" by the sales people of the software vendor or the implementation partner. However, HR "best practices" lies within the domain of the HR subject matter experts, and they are more often than not, not part of the software vendor's team nor that of the implementation partner.

The point of the above-mentioned analysis is that  HR's view on a HR information system  as the primary driver for HR Transformation, creates extremely high expectations of the functionalities of the system in context of their HR business requirements and assumes far too much in respect of the HR subject matter knowledge of the software vendor as well as the HR subject matter knowledge of the implementation partner.

When planning the procurement and implementation of a HR information system, the HR Architect need to take cognisance of the following considerations to ensure attention and action is given to the fundamentals:
  • The implementation of a HR information system is an important component of a HR Transformation program, but the planning and execution of activities focusing on the larger HR Transformation program should be the first step, not the implementation of the system;
  • The Transformation program needs to start with the transformation of the HR strategy to determine strategic objectives that have business context, that are not isolated from the rest of the business, and should be focused on building organisation capabilities that support the business objectives and that support continuous innovation;
  • Any business transformation program should have a business case with a baseline cost visibility - there must be an investigation on the current "cost-of-delivery" of the HR organisation to determine a operating cost baseline that will be used to evaluate the financial implications in respect of cost savings that will be achieved through the implementation of the HR transformation program;
  • As soon as business ratifies the new HR strategy, planning should start on the discussions and consulting relating to most ideal HR service delivery organisational model and channels - this can be achieved through a HR Architecture Assessment that will determine - in as much detail as needed - the exact current state of the HR organisation, as well as in context of the newly designed HR strategy; 
  • The findings or results of the above-mentioned HR Architecture Assessment will be the basis upon which the redesign of the HR organisation will be modelled. As the said assessment covers all the critical architecture dimensions, the results of the assessment will contain most of the critical decision support indicators for the next phase;
  • The Transformation of the HR organisation to mirror the larger business transformation (to increase competitiveness) is easily the most complex and challenging work that awaits the HR Architect. Some of the aspects and areas involved in this enormous task are as follows:
    • Determine the KPI's and Metrics in respect of the HR strategic objectives;
    • Determine the HR Service Delivery Dimensions and Service Levels - HR services are by nature integrated information, therefore the categorisation or profiling of the workforce according to their HR needs, information system access and geographical location(s) will be essential, as will be the identification of the range of service rendered to each of these (customer) groups;
    • Confirm all the HR activities that will constitute the official People Value Chain;
    • Disseminate the People Value Chain into high-level HR business processes;
    • Convert the chosen HR Service Delivery Model into a HR Organisation Structure and allocate new HR Team roles with Key Performance Areas (KPA's) that supports the new structure;
  • Design the new detailed HR business processes as part of the first phase (Blueprint) of the implementation of the HR information system, using an integrated process architecture methodology for the design of the individual HR processes.
  • Configure the HR information system according to detailed functional specification that are a derivative of the individual HR business processes, ensuring that there are close integration between the HR policies, business rules, system rules and business processes with the HR information system or application.
From the above-mentioned, it is clear that HR Transformation is not about the HR information system - in fact the application can at best be a sub-system of the comprehensive and elaborate HR Architecture. As the principal designer of the HR Architecture, the HR Architect must take control of and plan the design of each sub-system of the said HR Architecture as well as to ensure that deep integration between all the various architecture layers is achieved.

    Sunday, May 16, 2010

    We dont "do" change

    In South Africa there is currently an advertising campaign for one of the local beer brands that features Louis Gossett Jnr who teaches young men to "keep it real" - referring to authentic manly behaviour - and in the process he advertises the specific beer brand.

    In some of the ads, Louis uses the words "we don't do..." and then adds the specific unmanly behaviour, such as "pink drinks" or calling roadside assistance when confronted with a flat tire, etc.

    Far too many change management programmes we see today are characterised by a "we do change" approach, as if change (management) is something external to a business transformation or an information systems implementation project. If we think we can "do" change as something we are "doing to" the specific programme or project, change management will never be more that project communication and "balloons and sweets".

    Organisational, team and individual change are serious - very serious.Taking the current global trend of employee disengagement, Change Practitioners must have a deep understanding of what they are dealing with in the first instance before designing and promoting a change programme that has absolutely nothing to do with assisting individuals, teams and therefore the collective organisation to adopt to the impact of the specific intervention at hand.

    People regard their employment in a serious light especially when considering the impact of the current global economic downturn - a lot of people have lost their jobs and have suffered as result. So when people are subjected to interventions that potentially could alter or negatively impact their employment and their lives, these interventions must be handled in such a way that their fears and expectations are handled with integrity.

    The test of integrity is the one that asks: how would I have preferred this change be handled if my job or position was affected by this project?

    Whilst spending the past month or so on a SAP implementation project, I have again realised how great the irony is when considering the fact that businesses would spent literally millions on acquiring software as well as on contracting with implementation partners, then would have one "Change Practitioner" as part of the project team to "do Change Management". In no way does this makes any good business sense!

    The problem with having a budget for an intervention such as an information system implementation and giving the CIO or IT Manager accountability for controlling the budget, will most surely result in an emphasis on the expenditure for licenses and implementation strategy, whilst expenditure on the "soft stuff" will ultimately needs to be "motivated" and "closely monitored", whilst it is the "soft stuff" that will ensure the success of the implementation.

    Transformation and use of information systems changes the way people work in the organisation and it is serious - both from a organisation culture point of view and from a productivity point of view. When people are purposefully involved in, and actively made part of the design process in redesigning their new way of work, positive change happens and it is usually lasting.

    Well-known case studies such as the Harley Davidson Story has proven that when leadership and management realise that they do not have all the answers, and that their behaviours are inflating the organisational problems, then something powerful has happened, paving the way for successful business transformation.

    In my experience working in and with organisations over the past 20 years, purposeful (and truthful) Employee Participation remains the single most important contributor to positive organisational change.

    So what are those Leadership and Management behaviours that could be called "Change Killers"?
    • Lack of leadership when it comes to understanding people and the impact of organisational change on them in context of their work and their engagement;
    • Western type "command and control" management styles - I think, you do;
    • Viewing employees as "resources" that could be exploited in pursuance of profit;
    • The view that introducing information systems will automatically result in an increase in productivity;
    • Thinking that it is the functionality of of the information system that makes it a business fit as opposed to the reality that information systems are essentially social systems in the first place;
    • Using the implementation of information systems to drive organisational transformation;
    • No budget for the redesign of business processes when implementing information systems.
    Can you think of more examples of leadership and management behaviours?

    Tuesday, May 11, 2010

    Release the Kraken!

    Using an ERP implementation as the primary driver for Business Transformation will most probably have the same impact on the organisation as did the Kraken on the people of Argos in the movie Clash of the Titans.

    To be sure, Business Transformation and the implementation of ERP-type information systems does share a common objective and is driven by the same force, namely an increase in competitiveness.

    In the information age, competitiveness stems from the flexibility or agility of the organisation to adapt to rapid change - more specifically this flexibility is essentially the inherent ability of the organisation's entire system of means or architecture to respond quickly and appropriately to changes (and therefore opportunities) in its business environment - irrespective of the the nature of the changes.

    Contrary to popular belief, it is not necessarily the organisation's business processes that determine the measure of organisational flexibility, but the organisation's ability to continuously process data and information within context of their business activities and to take appropriate business decisions based on the information gains.

    As knowledge is the capacity to act, the centrality of  the organisational information processing competence for purposes of continuous knowledge-processing and knowledge-creation cannot be overstated. 

    The success of using the implementation of ERP-type information systems as the primary driver for business transformation has yet to be confirmed. In fact research on multi-factor productivity has not determined a correlation between the investment in information systems and an increase in productivity. However, what research has shown is that where organisational restructuring or redesign was done before the system implementation, a significant productivity gains have been achieved.

    In my experience, where client companies have integrated their system implementation with a well-designed business consulting programme to redesign their organisation and a new way of work in the organisation, a high level of awareness and understanding have built the basis for in-depth understanding and change readiness.

    Where business transformation is only driven by the CIO with a restricted and systems focused budget, the ERP "Kraken" will create havoc amongst the affected people of the organisation. Where an integrated and expanded programme of organisational redesign - using an architecture approach - is launched that also includes the implementation of new information systems, then a high level of positive organisational change is achievable.

    The ultimate objective should always be to empower people to work in business processes delivering quality services to customers using applications - such as ERP systems.


    Thursday, March 25, 2010

    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.   

    Wednesday, March 24, 2010

    The Shoes of the Shoemaker


    It is the old irony of the shoes of the shoemaker. My experience with working with HR teams in assessing their organisations has led to some conclusions as to the underlying reasons for HR's lack of insight into their own internal operational performance and positioning:
    • In the industrial mode of development HR took the role of ensuring that people as resources are adequately prepared to be applied as such in the production processes - in the information age the mode of development is knowledge (acting upon knowledge itself - the process of innovation) and so a number of HR organisation are still trying to "satisfy" the operations people with industrial-type "resources" thinking and service delivery;
    • As opposed to the operational departments they serve, traditionally HR does not have a well-established culture of customer centrality - in fact some HR people do not see themselves in a service capacity at all - they maintain the "industrial psychology" profile that reinforces a view that they are highly specialised and academically astute people that are somewhat irritated with service demands from the operations managers;
    • In some HR organisations, the view is that the risks are too high to let “non-HR specialists” such as production team leaders take responsibility for any HR process or activity. The result is that HR almost always heavily overburdened with demand which it cannot cope with in turn, resulting in negative employee satisfaction as problems / needs are not dealt with professionally;
    • The HR organisational structure in some cases still reflects a fragmented or silo-type structure with recruitment “department”, a training unit, the OD “department” and so on. These department very seldom interact with one another, there is no coherent synergy in their service delivery to the customer groups and each has an elaborate costly structure and budget, making it slow and non-responsive as a support organisation;
    • HR people are not up to date with the positive impact that a management practice such as Business Process Management could have for their own organisation – again, whilst their customer groups in manufacturing have embraced BPM and continuous improvement programmes such as Six Sigma a long time ago,  HR is still today slow to adopt to BPM – and they pay the price in respect of the quality of their service delivery;
    • Information systems or applications create a lot of discomfort for HR people. I have found myself numerous times trying to create some level of professional co-operation and productive collaboration between the HR and the IT teams. They are often at each others throats, blaming one another for the lack of validated HR data & information. HR often does not take accountability for their information system nor the quality of their data & Information, resulting in endless business blueprint scope changes that result in non-standard and ill-disciplined system behaviour;
    • Lack of knowledge and experience with the interface between people, processes and systems within the HR skills set makes it very difficult for them to plan and execute the transformation of their own operations into a fully integrated HR service delivery organisation.
    HR Transformation cannot be successful without an integrated view of the totality of the HR organisation before, during and after the transformation project. It simply has to adapt to its own specific domain architecture (the Human Capital Architecture) as a precursor on its journey to become an agile and business-focused embedded support organisation.

    Tuesday, March 23, 2010

    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.





    Tuesday, March 16, 2010

    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.

       





    Monday, March 15, 2010

    The essential HR architecture





    What is the key to the delivery of an integrated Talent Management service to the customer groups of HR?

    Most businesses today have a good articulated human capital strategy today, but they cannot deliver on it due to shortcomings with HR structure, HR people, HR processes and HR technology. This is the domain of architecture and the key performance area for the HR Architect.

    Systemic thinking, complexity and integration are important concepts for the HR architect and HR practitioners must endeavour to try to master the fundamentals of these concepts and how they affect our current thinking on the HR organisation.


    The concept of information as it relates to HR services is a connection we need to understand:
    • The nature of customer services is integrated information - if you think about it, it is either statistics, trend analysis based on statistics, reports such as those presented to the Department of Labour, advice based on information, certain  results based on predetermined and configured analytics, etc.
    • The quality of customer services is measured against its consistency and reliability. Consistency is the regularity with which the services are rendered, and the availability or the easy and effortless access available to the particular service. 
    • Reliability is the measure of the relevancy of the service provided to the problem or need at hand, specifically to what extent the service has solved the specific problem that the customer had.
    • Therefore to ensure quality of HR service delivery, the HR organisation's quest for integrated information across all its operations becomes extremely important as the basis for its professional service delivery to business.
    • All customer groups of HR - including the HR teams themselves - demand the same integrated information from the HR organisation, and their demand is very specific - the service must be delivered with consistency and must be reliable!
    • In IT language, we talk of data integrity - the measure of the "cleanliness" of the data we work with in the information system. When the data captured into the system is done by not following specific data conventions (rules/standards), or the master data records are not adequately maintained and distributed, then the integrity of the data is questionable, and if that is the case, there is a negative impact on the quality of the integrated information, and subsequently also on the quality of HR services.
    • Whatever the HR activity in context of HR transactional services or Talent Management services, care should be taken to make sure that there are representative data sets that are captured and completed in the information system as the material basis of HR service deliver.
    The concept of Business Process Management (BPM) in context of information and HR service delivery is another link we need to explore:
    • My favourite mantra when talking on BPM is as follows: "People work in processes delivering customer services using applications" - to make this statement more relevant to HR, it looks like this: "HR People work in HR processes delivering HR customer services using HR applications".
    • One of the central ideas in the above-mentioned statement is that it is all about PEOPLE and their work processes, not the other way round. HR people need to be empowered with the responsibility and accountability to redesign their own work processes (according to predetermined design standards). 
    • Substantial positive change effects and "buy-in" are gained when HR teams are intimately involved with the redesign of their work.
    • There are volumes and volumes written on the concept of Business Process Management. For HR, it is an area that is neglected as a key knowledge and skills area. In order for HR service delivery to be designed, build and delivered professionally, adoption to the BPM concept is not an option any more.
    • A Business Process could be described as a (logical) sequence of activities. From a service delivery perspective, a business process delivers specifically identified (and agreed-to) customer results. 
    • There could be a number of "internal" customers as part of a process, and there should be external customers identified with a number of deliverables or customer results per individual process delivered. Should internal or external customer groups and customer results not be identified, then we cannot readily talk of a business process.
    • From an information perspective, well designed and documented business processes are vital "channels" or vehicles for the capturing of data. It is when HR business processes are executed, in sequence, that data according to certain rules are captured, maintained and distributed. It follows then that where HR business processes across the people value chain do not exist, or if those that do exist are poorly designed and executed, the existence of validated HR data and information will be highly unlikely.
    • The integration between the HR business processes and the enabling HR computerised information system(s) or applications is crucial as it provides the worker (the HR process worker) with an integrated work design where the specific HR business process guides the execution of the task activities whilst the worker is using the HR information system at the specific interface points. (The lack of integration between the business process layer and the applications layer in the architecture is more than often responsible for the lack in data integrity and misuse of the system!).
    •  The business process layer is where all dimensions of the architecture come together because it is where people work.
    The connection to, and influence of HR applications on the quality of HR data & information, HR business processes and therefore on HR service delivery are likewise important concepts to understand:

    • The "best-of-breed" HR applications are modular, but fully integrated information systems such as SAP and Oracle (Peoplesoft). These types of applications have been developed to ensure that data are created, combined and integrated across the comprehensive people value chain that contains all the HR business processes.
    • Pre-programmed and integrated HR applications provide the best possible enablement for all the HR services via business processes to the business as it enhances the adoption to standardisation functionality. In contrast, when the HR information system landscape consists of disparate (unrelated or different) applications, HR will experience a lack of integration on the system, data and process layers in the architecture, as well as spend a significant amount of money, time and energy on ensuring systems interface and alignment of data.
    • During the business blueprint phase, the HR information system is "designed" - please note: not developed or programmed (in the case of SAP and Oracle) - and this is the most important phase of an implementation project as the final approved design or prototype will be carried forward during the subsequent phases of the implementation project, and finally becoming the reality when the system is live.
    • When using well designed HR business processes for the basis of the business blueprint, a substantial and significant milestone have been achieved as integration between HR data and information, HR business processes and the functionalities of the application will be guaranteed.
    • The mere existence of HR business processes and an integrated HR application does not mean that an integrated HR organisation is operational. The objective of following an architecture approach is to ensure that at the level of design, all components or layers of the architecture are integrated.

    Tuesday, March 9, 2010

    What is Knowledge?

    As with many concepts in the post-modern society, both in academia and in practice there are ongoing philosophical debates on the definition of the concept of "knowledge" - in context of scientific knowledge.

    One area of the debate focuses on the classic definition of knowledge as "Justified True Belief" - accordingly, a statement must meet three criteria in order to be considered knowledge: it must be justified, true, and believed.

    However, this definition has seen elaborate challenges and there is yet to be a universally accepted version of this classic definition.

    I was introduced to Nico Stehr's definition of knowledge by Prof.Johann Kinghorn, Chair of the Department of Information Science and Director of the Centre for Knowledge Dynamics and Decision-Making at the Stellenbosch University. Stehr holds that knowledge per definition, is a capacity for action. As such, knowledge is in economic terms, more often than not socially contextualised - "knowledge enables an actor in conjunction with control over the contingent circumstances of action, to set something in motion...knowledge always requires some kind of attendant interpretive skills and a command of the situational circumstances".

    Stehr elaborates further: "If sold, knowledge enters the domain of others, yet remains within the domain of the producer. Knowledge constitutes a basis for comparative advantages. The power knowledge offers is mainly linked to a control over additions to knowledge, not the general stock of knowledge. In this century, knowledge becomes an immediately productive force".

    When Stehr indicates that knowledge has to be made available, interpreted and linked to local circumstances, he also see this as a job performed by experts, counselors and advisors. It is this group of people that further developes the "additions" or "incremental" knowledge untill it can be interpreted (by them for other?) within specific contexts or situations.

    Jane Gilbert, Chief Researcher at the New Zealand Council for Educational Research, wrote an article with the title: "'Catching the Knowledge Wave' Redefing Knowledge for the Post-Industrial Age", published by the Canadian Education Association, wherein Gilbert refers to French philosopher Jean-Francois Lyotard who, in his book titled "The Postmodern Condition" (1979) argued that in the future (now), knowledge will be important, not as it was in the past in its relation to truth, reason and certainty, but for what he calls its "performativity", its energy or ability to do things, its use-value.

    Lyotard emphasises the role of knowledge in innovation when he says that knowledge will be mobilised on a as-and-when needed basis (situational) to produce innovative new products. Learners will be encouraged to develop an understanding of an organized stock of public and/or professional knowledge ("old" knowledge), not to add to it, but to pursue its performance - its "performativity" - that is, to apply it to new situations, to use it and replace it in the process of innovation.

    I do not know whether or not Lyotard and Stehr were in contact with each other or the extent to which the one was influenced by the work of the other, but it seems as if they agree, or at least in part, that knowledge and action are interdependent. Lyotard indicates to the fact that in the knowledge society, existing knowledge, not new knowledge, is applied (in new contexts) during the process of innovation, by anyone, not only experts ("expert individuals will be far less important"), counselors and advisors - as according to Stehr.

    In her article, Gilbert also refers to Manuel Castells and his work on the information age. According to Gilbert, Castells says that knowledge is no longer thought of as a "thing", a kind of matter produced by human thought and then codified in disciplines or by expert individuals. Rather it is now understood as being like energy, something defined by its effectiveness in action, by the results it achieves - a dynamic, fluid and generative force, or a capacity to do things.

    For Castells, knowledge is now something that causes things to happen; it is produced collaboratively by teams of people, something that happens in the relationships between those people. It is a process, rather than a product, it is constantly changing, evolving, flowing, and re-generating itself into new forms.

    Gilbert enthusiatically notes: "Knowledge is now innovation, innovation is quality, and quality control is knowledge management".

    Nico Stehr, "Knowledge as a Capacity for Action". Paper presented at OECD Workshop "New Indicators for the Knowledge-Based Economy", Paris, France June 19-21, 1996

    Jane Gilbert, "Catching the Knowledge Wave" Redefining Knowledge for the Post-Industrial Age. Education Canada Vol. 48 (4). Copyright: Canadian Education Association, 2008

    Friday, March 5, 2010

    The Tenth Fleet

    I recently read an article by Paul Furber in a local IT publication - ITWeb Brainstorm Magazine, Volume 9, Issue 06, February 2010, [itweb.co.za] with the title "People: the forgotten power-house for change" wherein Malcolm Gladwell, author of Blink, The Tipping Point and Outliers uses the story of the US Navy's Tenth Fleet to illustrate the power of people that could change the way organisations do business. Malcolm Gladwell told this story whilst speaking on the power of real-time analytics during an IBM conference in the US.

    I liked this article because it spoke directly to what I believe the true mandate of HR is in the information age - to assit the organisation to create, share and apply knowledge continuously - also known as the process of innovation.

    Malcolm Gladwell mentioned the fact that when the US was losing millions of tons of shipping to the German U-Boats in World War 2, the Navy urgently started to look for solutions to the problem. The conclusion of its investigative efforts indicated to the fact that it had adequate intelligence capacity in the operational theatre - it was breaking enemy communication codes, it tracked the U-Boats successfully, and interrogated enemy captives, but it had nobody that tracked these sets of information, integrated it and then made sense of it! To make matters worse, they did not share the information they already had throughout the all the structures and commands of the Navy.

    So the Navy put together the Tenth Fleet - it still exists - an information analytics group that gathers this information and interprets it. When this unit started to master the integration of the various information they received, within weeks the battle for the Altantic seas was won and the US controlled that Ocean therein untill the end of the war.

    What makes the story important is that it wasn't about leadership or resources or knowledge but about setting up a group that could make sense of the information and by using social power to communicate it effectively to that organisation. Malcolm reminded the attendees of the conference that they were the Tenth Fleet of their organisations - they could reframe their problems, leverage their social power and commmunicate their knowledge to others, then transformation becomes possible.

    HR organisations can be transformed by the HR people themselves if they accept full ownership of their customers, the quality of their services, their business processes, their data & information as well as their applications. Only then will they be able to create or combine, share and apply knowledge to the benefit of the organisation as a whole.

    HR cannot possible try to fulfil a more strategic role/ mandate if it has not taken full accountability for its comprehensive architecture and the integration of the various dimensions or layers in that architecture!

    Thursday, February 25, 2010

    The evolving organisation

    The organisation as we used to know it has changed. Dramatically. Due to the fundamental changes visible in the information age, organisations wishing to compete in the global economy, will be finding themselves in a semi-permanent state of transition in an effort to remain competitive in the new informational global economy.

    So how exactly has it changed? To compete in the global economy (remember that the global economy is still capitalist of nature/type) organisations are changing into a NETWORK - Castells calls it the Network Enterprise.

    Lets consider for a moment the concept of a network, or the network logic - in this context (societal/organisational):
    • Dominant functions and processes are organised around networks;
    • Networks are the new social forms and structures of our society;
    • They (networks) modifies the processes of production, experience, power and culture;
    • They consist of a set of interconnected nodes;
    • Networks are open structures, able to expand without limits;
    • They are enacted/ enabled by information technologies;
    • They integrate new nodes (entities) as long as those node share the same values and performance goals; and
    • Examples of networks are the council of ministers in the political network of the European Union (or African Union for that matter) and the coca fields, bush laboratories, landing strips and drug lords in the global drug networks, the recruiters, trainers, camps and arms dealers and buyers in the network of terrorists or mercenaries.
    So the network (for whatever the reason it has been formed) is the most flexible of form and structure to be able to exist and operate in a global economic, societal and organisational context. 

    For its success, a network is dependent on the extent to which all entities that are part of that network actively share and function in accordance with the ultimate goal of the network. To facilitate the cohesion/ cooperation between the entities of the network, a CEO of the network takes on a FIGUREHEAD role- he uses the connectedness between the entities in the network to continuously represent and communicate the vision and objectives of the network as a whole.

    Manuel Castells* discuss his definition of the Network Enterprise as follows:
    "To define more precisely the network enterprise, I need to recall my definition of organization: a system of means structured around the purpose of achieving specific goals...In a dynamic, evolutionary perspective there is a fundamental difference between two types of organizations: orgnizations for which the reproduction of their system of means becomes their main organizational goal, and organizations in which goals, and the change of goals, shape and endlessly reshape the structure of means...I call the first type of organizations bureaucracies, the second type, enterprises. On the basis of these conceptual distinctions, I propose what I believe to be a potentially useful definition of the network enterprise: that specific form of enterprise whose system of means is constituted by the intersection segments of autonomous systems of goals."

    Using Castells definition of the organisation as a network, a number of question arise as to the dynamics and performance of this network enterprise. In essence, the network enterprise transforms information signals into commodities by processing knowledge - this is the process of innovation (which, in my view, is the real mandate of HR...).

    The network enterprise is the appropriate form of organisation in the information age because:
    • ...it is able to generate knowledge and process information efficiently;
    • ...it is able to adapt to the variable geometry of the global economy;
    • ...it is flexible enough to change it means as rapidly as it goals change; and
    • ...to continuously innovate as innovation becomes the most competitive productivity weapon.
    From the above-mentioned discussion the picture becomes clear, the organisation form in the information age is a network which becomes the actual operating unit, not the individual organisation any longer. This network consist of electronically enabled or supported network of interconnected RELATIONSHIPS between Suppliers, Customers, Owners (Shareholders), Partners and Employees (SCOPE).

    In these relationships (during the act of relating) there happens an interaction, a sharing of free flowing of data, information, ideas, images and knowledge across the nodes or entities of the network. Performance of the network according to its goals, depends heavily on the connectedness - the ability of the network to facilitate clear "noise-free" communication between the network entities - as well as the consistency inherent in the network of the entities that share the same goals and objectives of the network.

    To this I want to repeat the extent to which the Leadership (multiple) of the network assimilates the role of figureheads - representing and continuously emphasising the overarching goal and objectives of the network.

    *Manuel Castells, The Information Age: Economy, Society and Culture, Vol.1-3



    A Case in point....2


    Using an architecture approach to assess or analyse the lack of integration  between HR strategy and policies, HR service delivery model and channels, HR people, HR business processes, HR data  and information and HR applications (such as SAP HCM), provides one with a very productive systemic view on the HR organisation's operations.

    Let’s consider some of the results of the architecture assessment that was done for the client company that I have mentioned in my previous post (with the same name): 

     HR Service Delivery Quality: A new HR service delivery model was implemented consisting of a HR Shared Services Center, 4 Centers of Expertise as well as the HR Operations Teams situated at the various operations. The responses from the operations managers (line) as the primary customer group of HR, indicated that the new service delivery model did not seem to be "working" as the quality (consistency and reliability) of the new levels of the HR services were disappointingly lower as before the implementation of the new model. 

    One aspect that surfaced consistently in the responses, was that the line managers regarded the local (operational) HR team as their first line of service delivery, and that they were of opinion that these HR teams are somewhat disempowered in their own new model due to an over-reliance on the service delivery from the Centers Of Expertise (CoE) and the HR shared service center. 

    HR Business Processes: The current state of the HR standard operating procedures and the alignment thereof in an end-to-end integrated process context as well as its integration with the functionalities of the HR information systems, indicated to a lack of close alignment or integration that impacted negatively on the current service delivery capacity of the various HR Teams in the new model, with the result that the customers of HR do not view the current quality of service delivery in general as sufficient to match their needs.

    Our analysis of the HR standard operating procedures was that they did not comply to the "best practice" process architecture design used for HR business processes. Key architectural dimensions were missing such as specific customer results, service levels, identification of customer groups, process activities, business rules, relevant policies, partners, suppliers, etc. In addition, no integration between the process activities and the supporting or enabling HR applications was documented.

    HR Data and Information: Our analysis of the current state of the HR information layer in the architecture indicated to the fact that real-time information exchange across the HR business processes and service delivery organisations was virtually non-existent. As a result, it was difficult to see how the complex HR environment could be managed effectively and services efficiently delivered through processes to the customer groups via predetermined service scenarios.

    When we examined the quality of HR data and information that were used across the new HR service delivery structure, and also how the respective HR teams gained access to HR information they needed to serve their customers, as well as the information-dependent service delivery needs of the HR customer groups; our conclusion was that the new HR organisation suffered greatly from invalidated, duplicated and outdated data and information. The current practices around the creation, maintenance and distribution of HR master data across the various applications as well as across the new HR service delivery model, were problematic and harmful to the quality of the HR data and information.

    HR Information Systems/ Applications: The current state of HR information systems at the client was characterised by a confusing muddle of disparate or dissimilar applications of which a significant number was home-grown and custom developed. This was aggravated by an extremely limited use of the SAP HCM system that has almost been systematically made redundant by wrongful information system practices. Our system audits also indicated to the elaborate and costly customisation of the SAP HCM system to such an extent that the system became a liability to the service delivery efforts of the HR organisation.
     
    I have tried to show how (in broad terms) a well-timed Human Capital Architecture Assessment as illustrated above, provides a credible basis for determining what the exact state of the current Human Capital Architecture is. This is a very important step to take as a planning mechanism for the HR Transformation journey. The level of detail per architecture layer that can be gained as well as the visibility of the lack of integration between the various architecture layers provides the content of the interventions and mandate of the HR Transformation Team.