책에서 HBR을 보다가 원문이 궁금해서 찾아봤다.

Not All Groups Are Teams: How to Tell the Difference
출처: Jon R. Katzenbach and Douglas K. Smith, <The Discipline of Teams>, Havard Business Review

What makes the difference between a team that performs and one that doesn't?

1. working group의 특징
• Strong, clearly focused leader
• Individual accountability
• The group’s purpose is the same as the broader organizational mission
• Individual work products
• Runs efficient meetings
• Measures its effectiveness indirectly by its influence on others  (such as financial performance of the business)
• Discusses, decides, and delegates

2. team의 특징

• Shared leadership roles
• Individual and mutual accountability
• Specific team purpose that the team itself delivers
• Collective work products
• Encourages open-ended discussion and active problem-solving meetings
• Measures performance directly by assessing collective work products
• Discusses, decides, and does real work together

* team의 필수 5가지 요소
1. A meaningful common purpose that the team has helped shape.
2. Specific performance goals that flow from the common purpose.
3. A mix of complementary skills.
4. A strong commitment to how the work gets done.
5. Mutual accountability.

대부분의 팀은 아래 3가지로 분류할 수 있다고 한다.
1. Teams That Recommend Things. (무언가를 추천하는 팀)
• For a team whose purpose is to make rec-ommendations, that means making a fast and constructive start and providing a clean handoff to those who will implement the recommendations.  
2. Teams That Make or Do Things. (무언가를 실행하는 팀)
• For a team that makes or does things, it’s keeping the specific performance goals in sharp focus. 
3. Teams That Run Things. (무언가를 관리하는 팀)
• For a team that runs things, the primary task is distinguishing the challenges that re-quire a real team approach from those that don’t. 

업무에 따라서는 working group이 team보다 더 효율적일 수 있다. 특히 무언가를 관리하는 팀에서는...
어쩌면 팀에 대한 오해는 조직에서 팀제를 도입하면서 본래 팀의 의미보다는 하나의 하위 조직으로 이름만 붙인 데에서부터 시작되었는지도 모르겠다.

높은 성과를 내는 조직을 만든다는 것은 참 어려운 일이다. 그것이 team이든 working group이든...
세상 일이 모두 사람이 가장 문제이고 핵심이다.


온라인에서 데이터의 흐름은 오프라인에서 유통되는 상품의 흐름 구조와 유사한 점이 많은 것 같다. 원자의 세계에 존재하는 메타포들이 비트의 세계로 확장됐기 때문인 듯 하다. 그래서, 가끔 떠오르는 것들을 확인하려고 Supply Chain Management & Logistics 책들을 보게 된다. 그러다가 postpone 전략이 눈에 띄어, 이에 대해 포스팅한다.
- 엉뚱하게도, 검색에서 'postpone 전략' 키워드로 유입되는 경우가 있는데, 이 키워드가 오픈웹투컨(Open Web2Con) 2006 후기 포스팅에 포함되어 있다. SCM의 postpone 전략과 블로거뉴스의 gatekeeping 사이에 유사한 점이 있어 보인다는 내용의 메모라서, postpone 전략과는 관련성이 떨어지는 포스팅이다.

1. SCM에서의 Postpone 전략

 수요는 항상 불확실성을 띄기 마련이다. Supply Chain Management 에서는 이러한 변동 리스크를 관리하기 위해서 여러가지 방법을 사용하게 되는데, Postpone 전략도 그 중에 한 가지이다.

이 전략은 다양하게 변화하는 수요에 기민하게 대응하기 위해, 변동부분을 적용하는 단계를 프로세스 상에서 뒤쪽에 배치하는 방법이다. Postpone 전략에도 몇 가지 방법이 있는데, '정보의 통합'과 '프로세스의 모듈화'가 핵심일 것이다.

Postpone 사례는 여러가지가 있는데, 아래 베네통의 사례를 옮겨 적어 보았다.

<물류및공급체인관리> 281페이지 中에서... (이 책 정보 보기)
[사례 9-5]
 베네통(Benetton)은 1982년에 세계에서 가장 많은 울(wool)의 소비자로서, 수많은 점포에 스웨터를 공급하는 메이저 업체이다. 패션산업은 소비자 기호가 빠르게 변한다. 그러나 장기간의 생산리드타임 때문에 점포소유자는 빈번하게 스웨터가 그들의 점포에 출시되기 전에 미리 7개월의 물량까지 울(wool)스웨터에 대한 주문을 하여야 한다. 울(wool) 스웨터 제조공정은 대표적으로 털실을 받아서, 염색하고, 의류부분을 생산하고, 그러한 부분을 완전한 스웨터로 결합시키는 작업으로 구성되어 있다. 불행하게도 이것은 소비자 기호 변화에 대응하기 위한 유연성이 거의 없다.
 이러한 문제를 다루기 위해서, 베네통은 스웨터가 완전하게 조립되기까지 의류염색을 연기하는 생산공정으로 바꾸었다. 따라서 컬러 선택은 더 많은 예측과 판매정보가 취득될 때까지 늦출 수 있었다. 염색공정의 연기 때문에 털실구매와 생산계획은 특정한 스웨터/컬러 결합에 대한 예측보다도 오히려 제품군에 대한 합쳐진 예측을 기초로 한다. 이러한 바뀐 공정은 스웨터 생산을 약 10% 더 비싸게 생산하게 하고 새로운 장비구매와 근로자의 재교육을 필요로 한다. 그러나 베네통은 향상된 예측, 더 낮은 잔여재고 그리고 많은 경우에서 더 높아진 판매를 통해 많은 보상을 받았다.
: Signorelli, S., and J. Heskett. "Benetton (A)." Harvard University Business School Case (1984) Case No. 9-685-014

2. 온라인 컨텐츠에서 Postpone 전략

 Online Contents에서도 사용자의 needs 변화와 관련된 가공은 되도록이면 마지막부분에서 처리하는 것이 좋을 듯 하다.
검색서비스도 이런 관점에서 볼 수 있을 듯 하다. 지금의 우리나라의 통합검색은 컨텐츠 생성시부터 컨텐츠 출처별로 고정되어 구분해서 저장하고 보여주는 방식이다. 이는 사용자 쿼리 변화에 대응하기 위한 유연성을 떨어뜨리고 있는 요인이 되고 있으며, 여기에서 통합검색의 한계가 드러나는 것은 아닐까?
또한, 서비스되기 이전에 이미 컨텐츠 형태가 결정되어, 서비스에서는 가공이 불가능한 경우도 있고, 정보들은 각 프로세스마다 산재되어 있는 경우가 많아서, 사용자를 위한 서비스에 대응하기 매우 어렵다.

3. 소프트웨어 개발에서 Postpone 전략

 최근에 메일을 주고 받다가 접하게 된 Lene Software Development에서도 비슷한 부분을 이야기하는 듯 하다. 여기에서는 가능한 의사결정을 지연시키고 전체를 보라고 이야기한다. 두 가지 방법 모두 프로세스의 agility와 flexibility를 높이기 위한 방법이라는 공통점이 있다. (참조URL: Lene Software Development from Wikipedia)

위 방법들이 필요한 이유는 의사결정 환경이 불확실성을 지니고 있으며, 이에 빠르게 대응하는 데에 효과적이기 때문이다.
이 방법들은 정보를 통합하여 불확실성의 변동을 줄인다. 그리고, 프로세스 모듈화를 통해서 의미있는 프로세스를 분리시킨 후, 기민하고 유연함이 필요한 모듈은 늦추어서 전체 프로세스의 front-end에 배치하는 것이 필요하다. 정보의 통합도 어렵지만, 프로세스 모듈화도 어려운 요소이다. 프로세스 내부에 실제 업무를 하는 사람들이 엮여 있기 때문이다. 베네통 사례에서도 보면 생산비용이 증가하게 되고, 새로운 장비구매, 근로자의 재교육 등이 필요하게 된다. 또한, 염색을 지연시킬 수 있는 기술이 필요하다는 것도 알 수 있다. 하지만, 전체적으로 보면 각 프로세스의 대기시간을 줄이고 고객의 요구에 기민하게 대처해 더 큰 이득을 볼 수 있다.

의류 생산을 하든, 소프트웨어 개발을 하든지간에, 항상 현실세계의 불확실성을 인정하고 기민하게 대응하는 것이 중요하다는 생각을 했다.

+ Recent posts