Hi all,
Last week we attended Executive IT event organized by Management Events in Helsinki. The event had approximately 350 delegates attending + an additional 150 vendor representatives. We had 30 scheduled meetings with delegates. Additionally we had a chance to discuss with another 30 delegates during the day. Our customer Lassila & Tikanoja gave a case presentation about business driven enterprise architecture project that we had done jointly during H2 2013. Presentation topic was “Towards business driven solutions using enterprise architecture”. Despite the late time after 4 PM and six parallel presentations the topic attracted over 100 delegates to the audience. Once again I want to thank Petri Kuismin for the excellent presentation.
Based on all dialogues during the day it became obvious that the interest and need for business driven enterprise architecture is high and constantly growing. Why is that? There are probably several factors but here is my main thoughts. First of all the economy has been tough in the western world since the financial crises in 2008. Traditionally there has been an upswing shortly after the crisis and companies have gotten back to the usual growth path without any radical development programs. The world, however, has changed. Six years later we are still waiting for economic growth. It seems that companies have finally realized that this time the economic growth may not come as before and rescue them but they have to take their destiny in to their own hands. In practice it means that companies must achieve more with less. In order to do that business driven enterprise architecture has proven to be a good approach. Another important factor for the genuine interest towards QPR’s business driven enterprise architecture must be the customer maturity. Enterprise architecture as such is not a new thing. However, it has and still often is misused for describing technical architecture work. That is neither business driven or enterprise level approach. It definitely has not delivered the expected business outcome and benefits. Most of the customers have already had these bad experiences from IT focused projects that didn’t deliver the expected results and were ignored by the business. Now they are looking for alternative approaches and vendors “who get it”. After they here about QPR's business driven approach and methodology the response is very positive “This is exactly what we have been looking for”.
Matti Erkheikki
http://www.linkedin.com/pub/matti-erkheikki/2/302/b35
Insights and expert views on Enterprise Architecture, Automated Business Process Discovery/Process Mining, Performance Management and much more.
Friday, March 28, 2014
Saturday, March 22, 2014
Processes or competences, which one is more important?
Dear friends,
This time I'm addressing the ever so interesting discussion about whether processes or competences are more important.
An organization needs to establish a balance between the amount of effort invested in competence development and in process development. This balance is very important, since both require continuous renewal and maintenance, costing money. Overspending or underspending in either of these is equally detrimental; it is money wasted forever without proper return.
The issue is not, whether one should emphasize processes or people, but to understand the dependency of business results on the integrated whole. Enterprise architecture being a rather novel approach, there is still quite often leadership in place, having rather vague idea how to integrate the process and competence viewpoints. However, because of their scale and complexity, for most global industry sectors, a systematic approach like enterprise architecture is not only desirable, but an outright necessity. For the early adopters, it may even be a competitive advantage, but in the end, mastering enterprise architecture, as a business capability among others, will become a basic requirement to compete.
Processes are part of the organization’s memory, and as such should provide the accumulation of best practices and knowledge about how people should work together to achieve the business objectives. In this sense processes organize work in a top-down manner. Competences of the people, on the other hand, should cover the skills, practices, and disciplines at the level of executing the individual personal activities, approaching and integrating with the process in a bottom-up manner. There is no black and white definition of where exactly processes and competences meet each other, so some prudent judgment is needed.
The location of the borderline is influenced by the availability of trained staff, or the average level and distribution of competence among the employees. The lower the average level of competence with respect to the requirements of the work roles, the more detailed process models are needed. For work roles and their individual activities requiring high degree of consistency and quality, and the employees at the same time having inconsistent or inadequate education and experience, you need to provide detailed step-by-step work instructions, train the employees to apply them correctly, measure, and follow up the execution, and provide immediate and direct feedback for learning and continuous improvement purposes. In other words, effective performance monitoring and coaching is needed. As tedious and energy consuming as it sounds, there is no other way, no magic that can cover the gap between competence and process, just hard work. This supports consistent performance by reducing variance caused by unavoidable disturbing factors like attrition and random differences in individual competence levels and performance.
Organizations in technology industries tend to have a pyramid-like competence & resource base: the higher the competence requirements of the job, the smaller number there is of these jobs. For example, there needs to be roughly one system architect for every 20 to 30 design engineer. It takes around 10 to 20 years to become a good system architect, after graduating from the university with an MSc in engineering or an equivalent degree, provided diverse post-graduate work experience and a good coach. But having made it, a system architect does not need much handholding for the processes. He is the one that has the most profound understanding about the processes and is even capable of providing formal designs of process architecture and improvements, whenever needed.
It is typical of the high volume work roles with relatively low qualification requirements to have higher attrition rate than the work roles having higher qualifications. This is a statistical axiom, since typically positions with higher qualifications are awarded to people with more experience resulting from a longer career in the company, and having also demonstrated process competences, among others, vital for the organization. You can’t count on this for the entry level roles. This said, I have never seen an organization overspending in competence development of people at the lower job grades.
As a summary, when designing and documenting your processes, you have to consider the competence level of available people, and decide whether to cover the gaps between processes and competences by continuous investment, in either more detailed process models, or more competence development, or both. You need then to agree on competence and performance level standards and expect people to meet them, but not to blindly assume that everybody does. Monitoring and coaching is needed to ensure consistent performance on the job.
Jaakko Riihinen
Senior Vice President
Products and Technology
QPR Software Plc
fi.linkedin.com/in/jaakkoriihinen/
This time I'm addressing the ever so interesting discussion about whether processes or competences are more important.
An organization needs to establish a balance between the amount of effort invested in competence development and in process development. This balance is very important, since both require continuous renewal and maintenance, costing money. Overspending or underspending in either of these is equally detrimental; it is money wasted forever without proper return.
The issue is not, whether one should emphasize processes or people, but to understand the dependency of business results on the integrated whole. Enterprise architecture being a rather novel approach, there is still quite often leadership in place, having rather vague idea how to integrate the process and competence viewpoints. However, because of their scale and complexity, for most global industry sectors, a systematic approach like enterprise architecture is not only desirable, but an outright necessity. For the early adopters, it may even be a competitive advantage, but in the end, mastering enterprise architecture, as a business capability among others, will become a basic requirement to compete.
Processes are part of the organization’s memory, and as such should provide the accumulation of best practices and knowledge about how people should work together to achieve the business objectives. In this sense processes organize work in a top-down manner. Competences of the people, on the other hand, should cover the skills, practices, and disciplines at the level of executing the individual personal activities, approaching and integrating with the process in a bottom-up manner. There is no black and white definition of where exactly processes and competences meet each other, so some prudent judgment is needed.
The location of the borderline is influenced by the availability of trained staff, or the average level and distribution of competence among the employees. The lower the average level of competence with respect to the requirements of the work roles, the more detailed process models are needed. For work roles and their individual activities requiring high degree of consistency and quality, and the employees at the same time having inconsistent or inadequate education and experience, you need to provide detailed step-by-step work instructions, train the employees to apply them correctly, measure, and follow up the execution, and provide immediate and direct feedback for learning and continuous improvement purposes. In other words, effective performance monitoring and coaching is needed. As tedious and energy consuming as it sounds, there is no other way, no magic that can cover the gap between competence and process, just hard work. This supports consistent performance by reducing variance caused by unavoidable disturbing factors like attrition and random differences in individual competence levels and performance.
Organizations in technology industries tend to have a pyramid-like competence & resource base: the higher the competence requirements of the job, the smaller number there is of these jobs. For example, there needs to be roughly one system architect for every 20 to 30 design engineer. It takes around 10 to 20 years to become a good system architect, after graduating from the university with an MSc in engineering or an equivalent degree, provided diverse post-graduate work experience and a good coach. But having made it, a system architect does not need much handholding for the processes. He is the one that has the most profound understanding about the processes and is even capable of providing formal designs of process architecture and improvements, whenever needed.
It is typical of the high volume work roles with relatively low qualification requirements to have higher attrition rate than the work roles having higher qualifications. This is a statistical axiom, since typically positions with higher qualifications are awarded to people with more experience resulting from a longer career in the company, and having also demonstrated process competences, among others, vital for the organization. You can’t count on this for the entry level roles. This said, I have never seen an organization overspending in competence development of people at the lower job grades.
As a summary, when designing and documenting your processes, you have to consider the competence level of available people, and decide whether to cover the gaps between processes and competences by continuous investment, in either more detailed process models, or more competence development, or both. You need then to agree on competence and performance level standards and expect people to meet them, but not to blindly assume that everybody does. Monitoring and coaching is needed to ensure consistent performance on the job.
Jaakko Riihinen
Senior Vice President
Products and Technology
QPR Software Plc
fi.linkedin.com/in/jaakkoriihinen/
Thursday, March 20, 2014
QPR blog - watch this space
QPR will be blogging soon. Read expert views of Enterprise Architecture and Automated Business Process Discovery and much more...
Subscribe to:
Posts (Atom)