Anders, Analyzing differing definitions is a good practice. Complementing that practice is trying to be specific (and exhaustive, if necessary) regarding the context(s) in which the definition is intended to be used, the scope of those contexts, and for what purposes within that context scope. That way, someone can’t tout “best practices” without specifying within which contexts those practices are best, and why – which brings us back to ontology evaluation! J Hans From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Anders Tell
Sent: Saturday, March 23, 2013 7:57 AM
To: Ontology Summit 2013 discussion
Subject: Re: [ontology-summit] Capability Hans, Thanks for the clarification on the use of resource. I often encounter similar inclusions of Resource. Some just talk about Value to someone, some add Economical value and some include VRIO characteristics (valuable, rare inimitable, org embedded). All these extra qualifications on an Entity entail Specific capability definitions. Some of these additional axioms, assumptions are useful and some are not. A problem with incorporating a Valuable Resource is the case where an Entity, that is necessary, for a (cap-)ability is not "considered as" or "known to be" valuable. Some of these "unknown" can actually be the main driver of an ability. Such entities are sometimes called Assymetries, and can be a source of competitive advantage. These kinds of variations in (cap-)ability definition is a key reason why I always try to strip down definitions into their bare bones in order to be able compare them On Mar 21, 2013, at 11:16 PM, Hans Polzer wrote:
I’m using resource in the sense of something of economic value – labor, capital/equipment, or raw material (water, fuel, land, etc.). The reason this is an issue in capability definition and actualization is that an organization may have a capability in terms of know-how and process institutionalization, but lack the amount of staff or equipment, etc. to achieve the desired level of effect. This can be addressed through force, cooperation, or commerce. For example, a government might seize the needed resource – such as airplanes and aircrews – to achieve the desired/needed airlift capability. Or it might ally with another government (like many European governments do that lack their own airlift resources). This often happens in operations such as disaster relief. Or it might contract with civil airlines for some number of aircraft and crews. An interesting hybrid model is the Civil Reserve Air Fleet (CRAF) program in the US, where civil airlines agree to make some portion of their resources available if the government declares an emergency. For commercial contexts, dynamic supply chains, partnerships, consortia, and the like can be mechanisms that allow organizations to dynamically scale capabilities. Cloud computing is an example of this in the IT capability domain. Certainly in some contexts, capability can be discussed or defined without any specific means of realizing/actualizing the capability. More likely, it is left to those responsible for actualization to make any arrangements for resources proximate in space and time to the point of need. I’m reminded that US Army supply officers roamed Bosnia and Croatia with attaché cases of money (and suitable weapons) in the late 1990’s to buy diesel fuel for tanks (including Russian tanks) on the local economy. In that case, they were leveraging local resources of fuel, fuel transport, and fuel pumping/storage facilities to achieve force projection (and protection) capabilities. But some missions/organizations may be unwilling to accept the risk/cost associated with dynamic acquisition of resources required to achieve essential capabilities. A lot of the debate around outsourcing, globalization, corporate re-engineering, and the like, centers on this issue of control, risk, cost, and lately, greenhouse gas emissions, associated with decisions concerning how to resource/actualize capabilities of organizations. Regarding the related issue of aggregating and composing capabilities, keep in mind that the same “little capabilities” can often be used to achieve different “big capabilities”. Airlift is usually not an end in itself, but used to achieve a variety of other capabilities, such as disaster relief, force projection, or merchandise distribution. Similarly, fuel distribution capabilities can serve to support a wide range of other capabilities. Specialization and economies of scale also enter into the issue of quantification of capabilities. For example, in the earth-moving domain investment in specialized equipment can significantly improve earth moving capability, at least for some portions of the earth-moving domain scope, for the same amount of capital investment. Put another way, a few very large trucks can be more fuel/labor efficient and faster, than lots of smaller trucks of comparable aggregate earth moving capability. This is true for airlift as well, by the way, but both examples do have scale limits, and there are clearly operational contexts in which the reverse might be true because of the nature of what has to be moved and where it is (i.e., how it is geo-spatially distributed). Hans, an interesting specific example of use of (cap-)ability. I have very little to comments on it, it seems resonable. Altough in Sweden we dont often discuss air lift capabilities. The example is in my view a specific treatment of the simple concept of capability, with a few extra assumptions attached to it, such as inclusion of Resource, one of those heavily overloaded terms with multiple senses. In not sure in which sense you are using it though. Why should it be considered as specific? - Inclusion of resource in the definition. In many cases a capability statement does not need/ not desired to include any specific references to/consideration any actual realizing entities,structure and/or mechanisms. Specific/ concrete/ detailed/ realising aspects could however be added later by other people in an organisation. Maybe in a specification - realisation chain of work. Different people in an organisation usually are interested in different questions, solutions, work and artifacts. Which questions that are relevant often depends on their work perspectices. The big - litte (cap-)abilities is an interesting topic. Some authors seems to work with/prefer one kind of (cap-)ability only, some two (capability-capability configuration), some use a specification-realisation pattern at multiple levels, some use a support relation between (cap-)abilities. As you mention, it is a challenge to get the questions (and answers) right at suitable levels in an organisation and their work perspectives. On Mar 21, 2013, at 1:57 AM, Hans Polzer wrote: The concept of capability being discussed here includes the notion of resources, not just “know how”, whether codified or institutionalized via formal business processes or not. Admittedly, “core competence” as applied to, say, an enterprise, carries with it some notion of resource availability to execute that competence. However, capability includes some quantification of that competence, which entails some resource availability or access necessary to effect the desired level/quantity of results/effects. That’s what I was alluding to in my earlier email about the challenges associated with aggregating “little” capabilities into “big” capabilities in a quantifiable way. My rhetorical question of “what is the airlift capability of the US” was intended to illustrate this challenge, as well as to point out the context sensitivity associated with possible answers to the question. This rhetorical question also begs the question of why the implicit selection of air transportation is appropriate, and entails a certain level of process specification, i.e., you have to get “stuff that is to be lifted” to and from wherever airlift is available, unless the specific airlift is insensitive to location (not entirely true, even for helicopters or airships). And it also had some implicit capability context/scope limits in that some things are simply too big/unmanageable or too heavy to lift by available/feasible airlift technology. By the way, this is not an idle example – it’s come up repeatedly in real world scenarios in the not too distant past. Thanks for examples of capability definitions. What you referer to are specific definitions/use of capabilities, there are plentiful of them, each with its own theme and (often silent) assumptions, axioms. Im interested in (cap-)ability in a more general sense. Taking the first definition as an example and breaking it down. "A Capability is a description of an ability to do something in terms of expertise and capacity to that meets the needs of the organizational mission." - Capability is a description - doing in terms of expertise -- meet needs of organisational mission This definition contains at least 6 parts, where 2 fits into a general sense of Capability. The rest of the parts are specifics. these kinds of specifics differ from author to author, making it difficult to compare (cap-)ability definitions. By the way: "meet the needs of organisational mission" is often associated with another kind of Ability - Competence or Core Competence, where ability is requisite or adequate. On Mar 19, 2013, at 1:39 PM, Pavithra wrote: Andres,
A Capability is a description of an ability to do something in terms of expertise and capacity to that meets the needs of the organizational mission.
A Capability is used as the unit of change in strategic portfolios and Capability Increments (TOGAF9) are used in programme and project portfolios.
Open Group addresses Capability-Based Planning here - http://www.opengroup.org/architecture/togaf9-doc/arch/chap32.html
A business process begins with a mission objective and ends with achievement of the business objective..
Hope that helps,
Pavithra
Hi,
Capability or ability is an interesting concept to study these days. Its an old concept but a new kid on the block when it comes to design of frameworks for various purposes. Unfortunately most authors use different definitions. Rather often without including a discussion of assumption and uses.
Is (cap-)ability "is the ability to do something", "what an organization does to deliver value to its stakeholders", or related to a feature" or a " function" or a "service", yes it can be, but other 'specific' definitions are possible.
In Financials Times one can find the following sentences:
- "Athens' ability to stay course in doubt"
- "This EU move has the ability to take the City down"
- "Apple believes it has the management talent and capability to do a big deal, he says."
Here it becomes obvious that many kinds of abilities are of interest to many, in many different perspectives, other than in IS/IT, Military, and some strategic planning approaches.
A common problem voiced in literature and by practitioners is how to differentiate (cap-)ability from "process" and "function". This confusion may be related to that many use process or functional analys & design techniques when creating (cap-)ability structures. These kinds of capabilities falls in the "performing" category of (cap-)abilities, i.e. the result/outcome is "performing/executing" some process/function.
However other kinds of (cap-)abilities are of interest, that are a couple of steps removed from features, and performing. e.g. "ability to fulfill some goals", "ability to set right price", "ability to create a confortable home that customers desire to live in", are all abilities of interest (in some work perspectives).
Are all (cap-)abilities designed - No.
Some abilities may emerge over time. Maybe a chain of bakeries discover that several employees are good at playing football so that they can start team in division 3. Or that some employees are excellent at designing windows display, and that this (cap-)ability can be sold to neighboring shops.
Do strategist always want to "design" their organisation? - No. Not all strategist believe fully in the design school.
Is there always a intention associated with all abilities? A short answer would be No.
>From a design perspective some unintentional abilities may emerge.
>From a complexity point of view, a subject that possess an ability may be too complex to analyse or understand, e.g. country or large organisation.
>From human point of view and larger scale systems it may be impossible to identify who's intention that have an impact on an ability.
The results /outcome from an ability can be observed without explicit knowledge, understanding about what processes brings about the results/outcome.
On the other hand some (cap-)abilities may be identified, defined, desired and intentionally build, acquired, leverage. etc.
Can an ability be sold, bought or acquired? Yes and no, some abilities are specified in simple terms, as being able to use a word processor or write a letter. Some may be organisationally embedded, distributed and difficult to remove or replaced with a better realization, e.g. Set Right Price. In knowledge intensive processes people and teams play an important role and may not be so easy to break up.
All in all (cap-)ability may seem as simple concept but its use complicates the picture.
Regards
/anders
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2013/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2013
Community Portal: http://ontolog.cim3.net/wiki/
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2013/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2013
Community Portal: http://ontolog.cim3.net/wiki/
|
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2013/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2013
Community Portal: http://ontolog.cim3.net/wiki/ (01)
|