This blog focuses on how to leverage the knowledge held, created, shared in an organisational context; with the objective of fostering creativity and innovation for competitive advantage. Leveraging your organisational knowledge relates to Knowledge Management, organisational learning, human capital development, social media/networks strategy, multi-channels Customer Relationships Management (CRM)
Search This Blog
08 July 2014
Traditional KM has lost the plot
But where does this valuable knowledge resides/originates from? It resides/originates with/from the minds of an organisation’s extended workforce (employees, contractors, strategic partners) (*). What organisations therefore need is for this extended workforce to share this knowledge as easily as possible, in order for any valuable knowledge to be used at the right time by anyone anywhere anytime. In other words, what is needed is an organisational culture conducive to such pervasive knowledge sharing: A collaborative culture. This is particularly important for organisations thriving on continuous innovation.
So, considering the above, one would think that the KM community should have been not only welcoming but indeed driving social collaboration. Social collaboration is about facilitating (to the point of commoditising it) and encouraging (rewarding/recognising) the sharing of valuable expertise, knowledge, insight, ideas, across the organisational natural and artificial borders (geographical, functional, hierarchical, operational, etc…) or in other words, breaking down the “knowledge silos”.
Strangely though, a large number (I think the majority although I do not have any verified data to support this) of KM professionals did not directly contribute to the introduction of social collaboration within their organisation (even less took the lead for it) and once implemented, refused to accept it as a part of KM. It is as if they are collectively stuck in a worldview where KM requires well defined and rigorous structures and processes in order to deliver any value.
The value of a given piece of knowledge is context-dependent. In other words, its value is realised when an individual - or a group of individuals – applies it the right way in the right place at the right time. The larger the Organisation, the more difficult it is to expand and replicate throughout the Organisation the value generated by traditional KM within specific business units or activities. The only way to unlock and leverage the dormant valuable knowledge throughout the organisation is to provide integrated collaboration tools for everyone and establish a collaborative culture. The former consumerizes knowledge sharing internally, and the latter normalises it through adapted behaviours and recognition and reward mechanisms.
An Organisation’s KM community must be fully aligned with social collaboration initiatives because they are the best equipped professionals – in terms of experience and expertise - to make these initiatives realise their full potential soon enough to gain significant competitive advantage.
(*) A relatively popular school of thought considers that knowledge can in fact only reside in our minds. Once we attempt to extract it and code it for sharing and re-use, it becomes information. If philosophically this view is worth debating, in a business context, it does not help anyone understand better the challenges faced by KM. On the contrary it tends to confuse the issue so I personally prefer assuming that valuable knowledge can indeed be passed on in a coded (written) form.
29 April 2010
There should be no box to begin with!
"[Derek Chesire believes] that 'out of the box' thinking does not exist: there simply should be no box to begin with".
Yes absolutely! I like this simple way to put it. I suppose what he really meant is that out of the box in fact does exist but is mostly ineffective at generating innovation and competitive advantage.
An organisation with a culture not conducive to creativity where knowledge sharing and spontaneous collaboration is not encouraged and rewarded, will eventually feel the need to ask from its employees to "think outside the box" in the hope that some good ideas will come out of the exercise. Out of the few good ideas that might come out, only very few of them (if any) will lead to an innovative implementation. This is because this process (idea through to implementation) requires an environment where mistakes are not only permitted but encouraged, where work outside initial job description and spontaneous collaboration is natural and rewarded.
When an organisation with an organisational culture not conducive to knowledge-sharing and creativity ask its employees to be creative, it is a bit like asking a group of junior mechanics to build a racing car from a pile of spare-parts, without the authorisation to collaborate with one another! You might obtain a car eventually but very unlikely competitive.
It's much more effective to let the group of mechanics organise themselves as a team and let them work out what they can build together. That way, they could come up with the next F1 concept car!
04 March 2010
TCS KM maturity model and implementation methodology
Their maturity model for an Organization is as follows:
1. Initial - Organization has no formal processes for using organizational knowledge effectively for business delivery.
2. Intent - Organization realizes the potential in harnessing its organizational knowledge for business benefits.
3. Initiative - Organization have knowledge-enabled their business processes and are oberving its benefits and business impacts.
4 - Intelligent - Organization has matured collaboration and sharing throughout the business processes that results into collective and collaborative organisational intelligence.
5. Innovative - Organizational knowledge leads to consistent and continuous process optimisation giving it a business edge.
If the speed at which an Organization go through the stages will vary greatly, the authors do stress that an Organization must go through these stages in this order and they are "no shortcut" to the innovative level, and they are absolutely right. A young company with the right leaders might start at level 3 but would need to go through level 4 before reaching 5.
Having said that, what is important to understand here is less the number of levels and their definitions, but more the fact that a KM strategy cannot be underestimated and will involve a difficult journey requiring strong leadership, committed resources and patience.
The authors are also correct in identifying the 3 main building blocks (or "pillars") of Knowledge Management:
- People and Culture (the "soft" pillar)
- Technology (the "hard" pillar)
- Process (the "glue" pillar)
Minimal information is given about the SIGMARG implemenation strategy (for obvious reasons) but you would expect it to rely on a set of benchmarking tools to assess the current state of the 3 pillars, followed by a roadmap of how to take them through the maturity levels. For the most important (in my view) pillar "People & Cutlure", my list of cultural traits not conducive to knowledge-sharing could be such a tool to assess the corporate culture for instance: the more of the 20 traits relate to your Organization, the deeper it is stuck at level 1. I would expect a level-5 Organization not to have a single of these traits.
The next pillar in importance is the Process pillar. This is primarily to ensure that KM is embedded in all business processes and not considered as an additional activity on top of the regular daily activities. This is not a simple endeavour and will require process re-ingeneering. Ideally, the Organization needs to become process-based instead of function-based.
Then only comes the technology pillar to facilitate the cultural and process changes by making them pervasive and time-resistant.
07 May 2009
The knowledge challenge (for outsourcing companies)
28 April 2009
Innovation is a priority, so why not KM?
24 August 2008
Insightful Knowledge
05 May 2008
Sustaining an Innovation Culture
- Executive Leadership
- Skills Development
- Innovation Infrastructure
- Network for Innovation Mentoring & Facilitation
- Internal Promotion
25 March 2008
On having a “fostering innovation” culture
17 March 2008
"The Google Enigma"
05 March 2008
“Forming an ‘inside-out’ company is the secret to innovation in business”
29 February 2008
The importance of culture when implementing new technology
19 January 2008
It was about SOA all along! Chapter 7
[Continuation of my commented reading of Andy Mulholland’s book: “Mashup Corporations. The End of Business as Usual”].
Chapter 7 is about the “typical” barriers to implementing SOA throughout an organization. The authors added this chapter in the 2nd edition following a suggestion by Avrami Tzur (VP of SOA at HP). I will start by saying that I was a bit disappointed with this chapter: it does literally focus on the specific resistance to SOA without considering the probable more generic reasons for this resistance. But maybe it’s me again expecting cultural issues to be mentioned everywhere! At least, this chapter has the merit of existing. I am sure Avrami was far from being the only one noticing the need for addressing this topic after reading the 1st edition of the book.
This chapter deals with the fears and needs of technologists - used to a “develop and control” centralized infrastructure – that are being asked to adapt to SOA and the flexibility, openness and informality that comes with it. These fears and needs would typically raise questions such as:
- How do I know what services are available for me to use?
- How do I know exactly what each service does?
- What happens when a service I am using is changed or upgraded?
- What happens when I have to debug an application based on services?
- How does the new world of services fit and interoperate with existing IT systems? Etc,…
Five rules are then proposed to encourage adoption of SOA:
- Use visibility to reduce fear, build trust
- Put it in writing
- Extend existing management processes to SOA
- Support new pattern of collaboration
- Provide incentives for SOA adoption
The authors do introduce these rules as enablers of communication and knowledge sharing. I agree. However, if your organisation has a command and control culture where knowledge sharing is not the norm (I take you back to my 16 traits of such a culture) following these 5 SOA adoption rules won’t be enough. But maybe it could be argued that a “command and control” organisation would not initiate a SOA in the first place (now that could be a topic for a lively debate).
The authors do explain that the << adoption of SOA do reflects an evolution in the skills and systems of a company >> ( I would like to add that it reflects an evolution in the organisational culture as well). This evolution is made of 3 stages: Integration, Architecture and finally Operations. I finally noted that successful SOA adoption will rely on 3 groups of people: the Enterprise Architects or designers, the Providers or builders of services, and the Consumers of these services.
09 January 2008
It was about SOA all along! Chapter 6
Chapter 6 is about “Internal IT” or the effect the SOA transformation can/should have on the internal IT department/functions. With the help of a meeting with all the managers of the fictitious company Vorpal’s IT department, it explains that a SOA does not only support the informal edges of the organisation but also the formal transactional hub. What unifies it all are “the processes that flow through the business” and link “the informal processes at the edge” with “the more formal controlled processes at the hub”. It is therefore important (in order to successfully become a service-oriented organization) to adapt the company’s functional structure. The functions must mirror the key business processes that SOA has formalized.
The authors then suggest a new structure for Vorpal’s IT department. Below are the original (standard) structure followed by a new service-oriented structure:
Old:
End-user support
Development
Infrastructure (CTO)
ERP
Engineering
New:
· Composition (about defining the common services)
· Services Creation (about development of the services)
· Disruptive Innovators (about the creation of new services)
· Consolidation (about the link with the core systems)
· Services Repository (about keeping track of all the services available)
The authors do make it clear that this is only a suggested structure and that each organization would adapt it to suit their needs.
And then reorganizing the IT department around SOA is only a start. The whole organization structure should be reviewed. For example, I can see new cross-functions between sales, marketing and public relations departments: Services to a specific customer group could benefit from having a function (an individual or a team even) pulling resources from these 3 departments to better satisfy these customers no-less specific needs.
30 December 2007
It was about SOA all along! Chapter 5
With the family reunion of the Christmas break, I have only managed to complete Chapter 5. In my defence, it is probably the most important chapter of the book judging from the powerful messages it conveys. The following chapters seem to be only about some of the consequences of taking on the challenge defined in this chapter: “Creating a Program of Service Enablement”. The authors describe such a program in terms of three levels or steps:
1. Designing a Single Service.
2. Designing Systems of Services.
3. Service-Enabling your Enterprise Applications.
According to the authors, no company has yet (at the time of writing) reached level 3! This is probably still true but I wonder if a company like Google that seems to have been implementing step 2 for years now, is not already well into service-enabling its core applications (and maybe they were designed as such from the beginning). In any case, what is implied here is that the first companies to successfully reach (and complete) step 3 are likely to be the success stories in the coming years.
The chapter starts with a wonderful email sent by the CEO of the fictitious company Vorpal. She writes to all the staff to involve them in building a new service-focused culture. The goal is to foster technological innovation throughout the company and “take shadow IT out of the shadows”. Once again, I’m not aware of many CxOs (let alone CEOs) with such an open-mind on new technologies and the courage to initiate and lead the drastic cultural change that a SOA demands. Such forward-looking leadership is indeed a must for a successful SOA implementation.
Chapter 5 describes 5 rules for successful SOA implementation. I want to comment only on the first two:
This chapter’s first rule is about promoting Shadow IT. The authors are quick to note that it is not a new phenomenon. Probably since IT was provided to people to do their work, most of them would work out their own “tools, procedures and workarounds” to increase efficiency at doing their job. Most importantly, this personal or team innovation is done without the IT department (official) involvement and in most cases even without it’s knowledge. This unofficial but productive IT is what the authors define as Shadow IT. I will quote their conclusion on this topic: “Failure to embrace and support Shadow IT in the long run means wasted resources, and inability to maximize the value of your company’s collective candlepower, and lost opportunities”.
The second rule is “Institute a Service Culture”. This is for me the cornerstone of an SOA implementation. The author only give this rule half a page but a lot more is implied. Service-enabling an Organization means adapting its internal culture. “Creating a lifecycle process in which services are made, reported, judged, and finally supported by IT, is essential to maximizing the potential of your homegrown and ecosystem-developed services.” I would add that all this creativity and innovation resulting in productive services must be formally recognized and rewarded. New pay, rewards and even promotion mechanisms will be needed to foster Shadow IT.
Going back to the second level of a Service Enablement Program introduced above, the authors give a brief but useful explanation of how to build a good set of services. In a nutshell, [each service must be] “sufficiently granular to allow for easy reuse; good design is decomposing process steps into a suite of services that can be orchestrated to solve the business need in question, while allowing for recombination.” This implies a potentially large number of services that will then need to be cleverly referenced, tracked and maintained.
The last comment I will make on this chapter refers to its last section (before a set of real life examples) titled “Rethinking Your Architecture”. SOA implementation will eventually (when reaching the level 3) mean a completely new organisational physical structure, and not just limited to IT but hierarchies and departments as well. When embarking seriously on the SOA adventure, you must be ready for significant no-turning-back – sometimes painful - changes that will transform your Organization.
19 December 2007
It was about SOA all along! Chapter 4
17 December 2007
It was about SOA all along! Chapters 2 & 3
12 December 2007
It was about SOA all along!
31 August 2007
European organizations are failing to effectively create and manage their intellectual capital
22 May 2007
Sarkozy’s goal-driven government structure
Nicolas Sarkozy, the newly elected French President, is completely rearranging the Cabinet as it has never been done before. He is grouping departments together under the same boss (minister) that never worked together. He is also breaking up departments for the first time. The central principle is a very clever one: The Cabinet’s departments are formed on the basis of their main goal and purpose, no longer on the basis of their functional relationships. For example, the goal of transforming France into a “Green” country requires departments such as “Environment” and “Energy” to be joined together (the “Energy” would have usually been managed by the Economy and Finance” dept). Another example is to remove the management of visas from the Interior department, and associate it with the dept responsible for “Integration” and “National Identity” to form a new dept for Immigration. The goal here is clearly to have a more holistic approach to the issues related to immigration. Whether or not we agree on these political goals is not my interest here. I am however intrigued by the implications of these drastic departmental changes for the civil servants affected. The media have already reported a lot of mostly worried comments from some managers, and the point in common I could identify was anticipated problems due to cultural differences! Here we go again with the importance of Organizational Culture but this time in the Public sector. Another significant impact due to some redundancy in activities will be a reduction in the workforce. The most telling case is the one affecting the separation of the “Labor” dept from the “Economy & Finance”, and its association with the “Social Relations” dept. In the Labor dept, you typically find the ones who came out of the French civil servants schools with the top marks. They are usually very good in math, very rigorous and methodical. In the Social Relations dept, it could hardly be more the opposite! They usually graduated with the lowest marks, have more “artistic” mindsets (rather than scientific) and have better communication skills. Both sides clearly have no idea how they are going to work together! Nicolas Sarkozy’s idea here is to give them a common goal of improving labor issues, with the realisation that it will require a combination of economic and social changes. For example, one of the objectives announced is to level the salaries between men and women within two years (today in France, men can be paid up to 40% more than women for the same job)! It will be very interesting to see how all these departments learn how to work together. These collaborations will need to be rapidly effective and efficient for the new Government to meet its objectives and convince the French people that it is on the right track. I wonder if someone will think of calling on the services of Knowledge Management consultants. I now come to the point I really wanted to make here: does this goal-based organizational approach make sense for a private company? We could start with an example: consider the strategic goal to “set a rate of annual increase of say +20% for retail customer loyalty”. For simplification, that is the number of existing customers purchasing at least once each year (I am assuming a luxury goods industry here). Typically, such an objective would be given to the Retail department. Some other departments such as Marketing might also be made aware of it and asked to assist. Now, what would it mean to adopt Sarkozy’s approach? You would need to think out of the box and regroup together under the same leader various departments or teams (parts of departments). I can suggest the following list for this example (but this exercise is very context-dependant, so each situation can demand a different organization) :
- The Retail department
- The part of the Customer Service department (After-sales services) specifically dealing with Retail customers (as opposed to wholesale).
- The part of the marketing department focusing on the retail market.
- The Public Relations department.
- The Press department.
Possibly, you could even include individuals or teams from some of the shared services departments that usually devote most of their time for Retail matters. I can think possibly of:
- Information Systems (IS) support professionals. For example, the team supporting the CRM application, a key tool for such a customer-focused objective.
For the shared services, the question to ask is: “will the individuals or teams concerned add more value by being integrated into this new “Super Retail dept” or by remaining closely linked with all the other teams within their respective department?” You should really consider this from a Knowledge sharing point of view. For an IS support Analyst to report to the Retail Director would undoubtedly facilitate his/her understanding of the business needs and deliver tailored support. However, from this point on, he/she ceases to be a shared resource and the cooperation with the rest of the IS department is then seen as secondary. In other words, this makes sense if the workload generated by the Retail department’s IS requests justify this IS Analyst to be full-time focusing on them. So then, supposing a Company implements this goal-driven organization, isn’t there a risk to have to re-organize too often when the strategy changes? Yes, but I don’t see this as a risk if this process of reorganization becomes engrained in the Company’s culture. The whole Organization must be built on principles of flexibility: flexible structure, flexible processes, flexible roles. This implies in turn a knowledge-sharing culture. Employees need to be used to share knowledge across departmental boundaries. In fact, there should be no internal boundaries when it comes to knowledge sharing (except for what needs to remain confidential). Such flexibility of course wouldn't typically suit more an Organization operating in a fast-moving/fast-changing market, but it could be argued that all markets are changing increasingly faster in this flatter World. Peter-Anthony Glick
http://leveragingknowledge.blogspot.com