From: Hirohide Yamada <hyamada@dd.catv.ne.jp>
Sorry for the late response to this, but this email was sticking in my
mind. When we want to apply the ABC model to an existing organization
whose objective is to make the business more efficient in pursuit of the
bottom line, I come across with the same issue as you do.
Lets suppose that all of a sudden, we recognize that there is a serious
attack coming to the people on the earth from a planet in the universe.
In this situation, what we need to do is to operate the existing
organizations as it is to keep the economical system working for our food,
but also everybody has to protect earth from the attack from the universe.
This activity has to be incorporated into day to day activities so that what
we do day to day should also add value to help earth from other planet.
To me, C level activities in different level has to do with directing our
day to day activities to help protect earth from the attack from the planet
in such a way that it also help run the existing economical system.
We of course must be strategically smart collectively and need DKR. Then
what would be the functions and organization of the DKR and how would
ABC model and NIC be organized?
Hirohide Yamada, Astec Inc.
Eric Armstrong wrote:
>
> From: Eric Armstrong <eric.armstrong@eng.sun.com>
>
> My view of things so far, is that the B-level activity says "if we get
> people together,
> they'll work more efficiently". The idea is then to put people near each
> other. Of
> course everyone can't be near everyone else, so we have to choose which
> people
> are near each other, sharing common areas and lunch rooms and so forth.
>
> A company might put marketing next to development, or marketing may be
> placed
> close to sales, or executives next to the shop floor -- whichever
> arrangement the
> company things will bring the best results is the arrangement they
> choose. It's an
> improvement that's undertaken for the beneficial effect on productivity.
>
> The question I asked myself was: "If making common areas and lunchrooms
> is a
> B-level activity, then would be a C-level activity in the same arena?" I
> only
> came up with one answer, although there may be better possibilities. The
> answer
> I saw was that "improving our ability to improve" would be tantamount to
>
> investing in an infrastructure that made it possible to change physical
> adjacency
> easily, in order to put marketing in contact with developers for a
> while, and then
> later "redress the balance" by putting them close to sales for a while.
>
> My intuition (a tricky thing) tells me that the semi-ludicrous notion of
> "offices on
> skids" captures the essence of what it means to "improve our ability to
> improve".
> Any such endeavor must, to my mind, involve a reorganization or a
> restructuring
> or a change in the way we do things.
>
> Suppose Citigroup develops a DKR, for example, as they aim to do. Making
> it
> "work" requires workers contributing to that repository from around the
> globe,
> allow "best practices" to surface through comparison, and changing the
> culture
> so that contributing to the repository and choosing a better solution
> offered by
> someone else is rewarded so well that people are not tempted to hold on
> to their
> own solutions with a death grip, in order to achieve advancement. Those
> are not
> easy things to achieve!
>
> But the important point in all that is the notion "improving your
> ability to improve"
> requires *change* -- fundamental, basic, gut-wrenching change to the way
> the
> organization does things. If for no other reason than the cost of change
> itself,
> organizations are understandably reluctant to make "hard wire" C-level
> activities
> as part of their organization. The goal of a flexible, self-reinventing
> organization
> may be laudable in theory, but one suspects that the economic cost of
> continual
> change would be outweighed by costs that are continually occurred, but
> never
> fully paid back by the improvements they make possible.
>
> That analysis could turn out to be wrong if the business climate were to
> accelerate
> to such a degree that *only* a continually self-reinventing corporation
> can
> survive. But I suspect that there is an upper limit to the amount of
> change that
> humans can tolerate and still be productive, and it seems to me that we
> are
> approaching that limit.
>
> So, unless there is a notion of "improving the ability to improve" that
> does not
> involve fundamental change, or the tolerance for change is greater than
> I think
> it is, I simply do not see C-level activities becoming a "central" part
> of any
> organization, anytime soon.
>
> For the technical subsection of the colloquium, our A-activity is
> producing a DKR.
> The B-activity is improving our ability to kick one out. If we worry
> about
> C-activities, we'll be reinventing ourselves too often to get anything
> done, so like
> every other organization, I suspect that our efforts stop at the
> B-level.
>
> *However*, the DKR we produce represents a C-level improvement for other
>
> organizations. Although they are unlikely to invest in creating such a
> thing, they
> are likely to use it. Our A-activity, then, is their C-activity. That
> has been the
> history of business interactions for the last several centuries, and I
> don't see that
> model changing anytime soon, for the reasons mention.
>
> But another reason an organization is unlikely to invest in a C-activity
> like
> creating a DKR is that it is outside their area of expertise. The cost
> for them
> is much higher than for an organization which is devoted to that goal.
> The
> lack of expertise reduces the chance of intrinsic success (it may not
> work
> at all) as well as extrinsic success (other products may be better).
>
> We have seen in the software world that it almost uniformly better for a
> company
> to use "off the shelf" software, instead of developing it in house
> (whenever software
> exists that will do the job). The costs of documentation, technical
> support,
> maintenance are simply too high. The reason is the size of the market.
> An "in house"
> project has one company paying for it. A commercial product has many
> companies
> paying for it. The extra income allows the commercial product to expand
> and add
> features that in house products rarely have time for, if ever. The
> result is that, even
> if they start out with similar levels of functionality, in 5 years a
> commercial product
> is typically far ahead in features and functionality.
>
> When you add up the cost of change, the smaller user base over which to
> defray
> expenses, the lowered chance of success, the higher risk of failure, and
> the lowered
> risk of acceptance, investing in C-level activities appears to be a very
> foolhardy
> adventure for any organization that hopes to succeed.
>
> To relate it to our current endeavor: If our A-activity is producing a
> DKR, and our
> B-activity is finding better tools (better programming libraries, and
> development environments, for instance), then our C-activity is
> developing a framework that lets
> us plug in the development environment of the week -- whatever is latest
> and greatest
> and will let us achieve maximal productivity.
>
> However:
> a) The cost of changing development environments is an additional
> learning
> curve for each of us. (If we change too frequently, we derive no
> benefit
> at all.)
> b) The cost of developing some sort of "meta framework" that will even
> *allow*
> us the change development environments and libraries will suck up
> resources
> that we could have devoted to DKR production.
> c) We are unlikely to succeed in that endeavor. It opens up a
> squirrel's nest
> of problems that will require the devoted attention of many people
> to solve.
> And even if we solve the technical problems, it is not all clear
> that anyone
> would really want the solution.
>
> Admittedly, I'm arguing from the standpoint that C-level activities as
> *part* of an
> organization don't make much sense. So the example I conceive has a
> natural
> tendency to prove that point. As a human being, I'm wired that way.
>
> A useful counter example, then, would be a C-level activity that *does*
> make
> sense for us. Can anyone think of one? If so, are sure it's not really a
> B-activity?
>
> ------------------------------------------------------------------------
> GET A NEXTCARD VISA, in 30 seconds! Get rates as low as 0.0%
> Intro or 9.9% Fixed APR and no hidden fees. Apply NOW!
> http://click.egroups.com/1/937/2/_/444287/_/952380784/
> ------------------------------------------------------------------------
>
> Community email addresses:
> Post message: unrev-II@onelist.com
> Subscribe: unrev-II-subscribe@onelist.com
> Unsubscribe: unrev-II-unsubscribe@onelist.com
> List owner: unrev-II-owner@onelist.com
>
> Shortcut URL to this page:
> http://www.onelist.com/community/unrev-II
------------------------------------------------------------------------
GET A NEXTCARD VISA, in 30 seconds! Get rates
as low as 0.0% Intro APR and no hidden fees.
Apply NOW!
http://click.egroups.com/1/975/2/_/444287/_/953223867/
------------------------------------------------------------------------
Community email addresses:
Post message: unrev-II@onelist.com
Subscribe: unrev-II-subscribe@onelist.com
Unsubscribe: unrev-II-unsubscribe@onelist.com
List owner: unrev-II-owner@onelist.com
Shortcut URL to this page:
http://www.onelist.com/community/unrev-II
This archive was generated by hypermail 2b29 : Thu Mar 16 2000 - 08:31:37 PST