비즈니스 프로세스에 Kanban을 구현할 계획이신가요? 시작하는 곳은 다음과 같습니다. 칸반 시스템: 정의, 시작 위치, 구현 방법, 주요 원칙

Kanban 방법, 기본 용어 및 적용 분야에 대해 가능한 한 간략하게 설명합니다.

우리는 Kanban 방법과 기본 용어 및 적용 분야를 최대한 간략하게 설명했습니다.

1. 칸반 방법이란 무엇입니까?

칸반 방법은 작업을 개선하기 위한 방법입니다. 무엇을 하든지 칸반 방법을 실천하면 업무를 더 잘 수행할 수 있다는 가설이 있습니다. 칸반의 관점에서 볼 때 이는 고객의 기대에 더 잘 부응할 수 있음을 의미합니다.

IT 관리 도구인 Kanban은 Microsoft(2005)와 Corbis의 David J. Anderson에 의해 소개되었습니다. 그리고 이 방법은 2007년에 널리 보급되어 명명되었습니다.

2. Kanban Method와 Toyota Kanban은 같은 것입니까?

(가장 큰 카드). 확실히 그런 것은 아닙니다. Toyota 공장의 Kanban은 린 제조 방식이며, 이를 정의하는 원칙은 "적시"라는 개념입니다. 관리 용어로서 Kanban은 실제로 Toyota에서 나왔습니다. 일본어로 번역된 이 단어는 "신호" 또는 "카드"를 의미합니다. 자동차 공장에서는 이러한 카드를 사용하여 한 단계에서 다음 단계로 필요한 부품 수와 부품 수에 대한 정보를 전달했습니다.

간단한 예를 살펴보겠습니다. 우리는 "적시에" 자동차 3대를 만들어야 합니다. 즉, 특정 단계에서 필요한 부품 수를 미리 정확하게 결정할 수 있으며, 마지막부터 이 자동차를 만드는 데 필요한 부품 수를 꺼내서 다음 질문에 답할 수 있습니다. 필요합니까?”, “바퀴는 몇 개입니까?”, “엔진은 몇 개입니까?” 등등. 따라서 우리는 남은 부품의 형태로 잉여 예비 부품을 생성하지 않고 창고, 물류 및 기타 비용을 절약합니다.

칸반 방식 역시 '적시'라는 개념을 고수하지만, 도요타 공장과 달리 여기서는 지적 작업에 대해 이야기하고 있습니다. 즉, 프로그래머의 코드나 마케터의 아이디어는 최종 제품이나 서비스로 바뀔 때까지 일반인이 만지거나 볼 수 없습니다. 따라서 칸반 방법은 지적 작업의 흐름을 시각화하고 미완성 작업의 양을 줄이는 데 사용됩니다. 이로 인해 최종 소비자에게 균일하고 예측 가능한 서비스 제공 속도가 달성됩니다.

3. Kanban 방법을 IT 외부에서 사용할 수 있습니까?

예. Kanban 방법은 창의적이고 지적인 작업의 흐름을 시각화하는 데 적합합니다. 그러나 서비스 패러다임의 프리즘을 통해 사용하는 것이 훨씬 더 효과적입니다. 당신이 봉사로서 무엇을 하는지 살펴보세요. 서비스가 제공되기까지 작업은 어떤 단계를 거치나요? 고객의 기대에 따라 서비스가 제공된다는 것을 어떤 기준으로 이해합니까? 이것이 칸반 방법을 사용하는 출발점입니다. 칸반 실무자들은 이 시점을 "지금 가지고 있는 것부터 시작하라"고 부릅니다.

4. 칸반은 스크럼과 비슷합니까?

아니요. 스크럼은 엄격한 규칙과 경계가 있는 프레임워크입니다. 스크럼 내에서는 다양한 도구와 방법론을 사용할 수 있지만 스크럼에 필요한 것을 포기하면 더 이상 스크럼으로 간주될 수 없습니다. 칸반은 일련의 관행과 원칙을 갖춘 방법이자 도구입니다. 모든 관행, 일부 관행을 사용할 수도 있고 전혀 사용하지 않을 수도 있습니다. 칸반에는 무엇이 칸반이고 무엇이 칸반이 아닌지에 대한 엄격한 개념이 없습니다. 그러나 현명한 관행 활용은 최고 품질의 서비스를 제공하고 고객 기대치를 충족하는 데 크게 도움이 될 수 있습니다.

5. 칸반에는 가치가 있나요?

예. 투명성, 균형, 협업, 고객 중심, 흐름, 리더십, 이해, 합의, 존중이라는 9가지 항목이 있습니다.

6. 칸반의 원칙에 대해 글을 쓰셨습니다. 그들은 무엇인가?

Kanban에는 변경 관리 원칙이라고도 하는 기본 원칙이 있습니다.

1. 지금 가지고 있는 것부터 시작하세요.
2. 진화론적 발전에 동의합니다.
3. 모든 수준에서 리더십 개발을 장려합니다.

Kanban 방법은 서비스 패러다임에 속하므로 다음 원칙을 준수합니다.

1. 고객의 요구와 기대를 알아보세요.
2. 작업을 관리하고 사람들이 작업을 정리하도록 하세요.
3. 성과를 향상시키기 위한 규칙을 개발합니다.

7. 칸반의 관행은 무엇입니까?

그 중 6개도 있습니다:

1. 시각화.
2. 완료되지 않은 작업을 제한하십시오.
3. 작업 흐름을 관리합니다.
4. 명시적인 규칙을 사용하십시오.
5. 피드백 루프(케이던스)를 도입합니다.
6. 개선하고 발전하세요.

이는 업무를 개선하고 서비스 품질을 향상시키는 데 사용하는 직접적이고 실용적인 기술입니다.

8. 오, 케이던스! 칸반의 케이던스는 무엇입니까?

케이던스는 음악에서 나온 용어입니다. 칸반 방식에서는 리듬을 의미합니다. 케이던스는 피드백 루프이기도 한 정기 회의입니다. 규칙성은 작업 흐름의 흐름에 리듬을 설정합니다. 7가지 케이던스:

1. 칸반 회의(매일). 여기서는 차단된 작업의 상태에 대해 설명합니다.
2. 대기열 채우기 회의(보통 2주마다). 우리는 서비스로서 우리가 할 일에 대한 책임을 집니다.
3. 납품 계획 회의(보통 2주마다). 우리는 이행된 의무를 다시 반환합니다.
4. 서비스 검토 회의(보통 2주마다). 측정항목을 사용하여 서비스 품질과 필요한 경우 개선 방법을 논의합니다.
5. 운영 회의(보통 한 달에 한 번). 관련 서비스와 측정항목의 상호작용 품질에 대해 논의합니다.
6. 위험 검토 회의(보통 한 달에 한 번) 차단된 작업이 서비스 운영에 미치는 영향을 측정항목을 통해 논의합니다.
7. 전략 검토 회의(보통 분기별) 우리는 측정항목을 통해 전략의 변화를 논의합니다.

9. 봉사강좌에 대해 들은 적이 있습니다. 이게 뭔가요?

Kanban은 서비스 클래스를 사용하여 특정 유형의 작업, 고객의 우선 순위를 지정하거나 지연 비용과 같은 비즈니스 영향을 완화합니다. 지연 비용은 서비스 제공 지연으로 인해 발생한 이익 손실 또는 비용입니다. 예를 사용하여 지연 비용과 해당 서비스 클래스의 영향을 살펴보겠습니다.

1. 속성 수업 – 응급처치-소생술. 전용 차선으로 운전합니다. 문제 해결을 미룰 시간이 없습니다. 최대한 빨리 필요합니다.
2. 고정 날짜 클래스 – 특정 기간이 지나면 지연 비용이 급격하게 증가합니다. 예: 시작일이 고정된 연방법 형태의 프로젝트. 제 시간에 도착하지 않으면 면허를 잃을 위험이 있습니다.
3. 표준 클래스 - 지연 비용은 시간에 비례하여 증가합니다. 바로 하면 즉시 이익을 얻을 수 있습니다. 오랫동안 하면 오랫동안 이익을 얻을 수 있다.
4. 무형 클래스 - 우리가 수행하지만 이 작업은 뚜렷한 이익을 가져오지 않으며 지연 비용은 천천히 증가합니다. 예를 들어, 집 청소. 정기적으로 청소할 필요는 없지만 반년이 지나면 철저한 청소를 해야 합니다.

10. 지표는 어떻습니까? 서비스의 효율성을 측정하는 방법은 무엇입니까?

Kanban 방법에는 작업 흐름의 문제, 서비스 처리량, 실행 시간, 잠금 해결 시간, 주기 시간 및 서비스 처리량 등의 질문에 답할 수 있는 측정항목이 있습니다. 작업 유형이 배포됩니까? 이를 통해 서비스 관리자는 축적된 데이터를 기반으로 서비스 품질 개발 및 개선에 대한 결정을 내릴 수 있습니다.

11. Kanban을 구현하는 동안 어떤 어려움에 직면하게 됩니까?

주요 과제는 모든 수준의 사람들에게 Kanban 관행의 가치, 즉 시각화 및 진행 중인 작업 제한을 설명하는 것입니다. 사람들은 지적 작업의 양을 보지 못하기 때문에 자신이 노출되는 부하를 이해하기 어렵습니다. 그러나 예를 들어 뇌는 이두근과 동일한 근육입니다. 체육관을 상상해 보세요. 들어와서 바에 있는 무게를 확인합니다. “좋아요, 너무 적네요. 그리고 지금은 너무 많습니다. 하지만 이게 딱 맞아요!” 같은 방식으로 두뇌를 다루어야 합니다. “이것은 큰 작업이고 이것은 작은 작업이며 일반적으로 나는 많은 일을 맡았습니다. 짐을 제한하겠습니다.” 모든 수준에서 엔드투엔드 작업 흐름을 시각화하고 진행 중인 작업의 양을 제한하면 지식 작업에 대한 끌어오기 원칙을 만들고 그 결과가 고객에게 균등하게 흐르게 됩니다.

12. 칸반 방식에는 어떤 프로그램이 있나요?

그들도 많이 있습니다. 우리는 해당 방법을 위해 특별히 개발된 전문적인 것만 나열합니다. 우리의 마음은 러시아 개발 Kaiten에 주어졌습니다. 그 외에도 TargetProcess, SwiftKanban, LeanKit 등도 있습니다.

13. 이미 칸반 방법을 사용하고 있는 회사는 어디입니까?

러시아에는 Alfa-Bank, Home Credit Bank, Pochta-Bank, Dodo Pizza, HeadHunter, Clever 등이 있습니다. 외국: Wargaming, Microsoft, Automotive IT, Blizzard Sports, Dr Dobb's, Siemens, Tupalo. 이 목록은 오랫동안 계속될 수 있습니다.

14. 또 중요한 게 있나요?

예. 마지막으로 칸반 방법에서 두 가지 역할의 중요성에 주목하고 싶습니다. 서비스 제공 관리자와 서비스 요청 관리자가 있습니다. 첫 번째는 공급 흐름의 장애물을 제거하는 역할을 합니다. 두 번째는 많은 고객의 서비스 요청 흐름을 관리하는 것입니다. 이 두 역할이 파트너로서 함께 일하는 것이 매우 중요합니다.

15. 알겠습니다. 이해합니다. 조직에서 Kanban 구현을 어디서 시작해야 합니까?

조직에서 Kanban 구현을 시작하기 위해 S.T.A.T.I.K 도구를 사용합니다. – Kanban 사용에 대한 체계적인 접근 방식입니다. 이에 대한 자세한 내용은 인터넷에서 읽을 수 있습니다. 하지만 이 도구를 비즈니스 게임 형식으로 가르치는 교육에 참여하는 것이 좋습니다. 귀하의 서비스(조직)를 예로 들어 전투 상황에서 이후에 사용할 칸반 시스템을 설계할 수 있습니다.

Agile 방법론에 대한 트레이너이자 컨설턴트, Scrumtrack.

좋은 오후에요

테스트 팀 코디네이터로서 저의 직업적 관심 중 하나는 소프트웨어 개발 방법론입니다. 현재 소위 Agile 방법론, 특히 Scrum 및 Kanban이 점점 인기를 얻고 있습니다. 부도덕한 "트레이너"는 "과장된" 용어를 사용하며 세미나와 인증("인증된 스크럼 마스터", "인증된 제품 소유자" 등)은 비약적으로 성장하고 있습니다.

대부분의 부도덕한 기사와 교육에서는 모든 방법론이 의사소통 문제를 즉시 해결하고 개별 팀 구성원을 무능함에서 즉시 구해 주는 마법의 묘약으로 제시됩니다. 일반적으로 문제를 정확하게 해결하는 데 도움이 됩니다. 올해 저는 인적 자원 관리 기술 학위를 가지고 벨로루시 주립 대학의 석사 과정에 입학할 예정이며, 가장 일반적인 소프트웨어 개발 방법론의 적용 가능성과 장단점을 자세히 고려할 계획입니다.

작업 과정에서 나는 방법론적 도구에 대한 오해와 잘못된 해석, 맥락을 고려하지 않고 유행하는 방법론을 사용하는 경우를 자주 접했습니다. 기사를 읽은 후 문제는 지역적 문제보다 전역적이라는 것을 깨달았습니다. 오늘 저는 Kanban의 역사, 기본 원칙 및 가능한 적용 범위에 대해 조금 살펴볼 것을 제안합니다.

용어의 역사

칸반(Kanban)은 20세기 60년대 도요타에서 생산과 관련하여 사용되기 시작한 일본어 용어이다. 이 원칙은 컨베이어 생산 방법과 생산 시 개별 기술 작업을 수행하는 다양한 속도를 기반으로 합니다. 나는 그것을 내 손가락으로 설명하려고 노력할 것입니다. 모든 생산에는 주요 생산(“주 컨베이어”)과 추가 생산(“추가 컨베이어”)이 있습니다. 최종 제품의 생산 속도는 메인 컨베이어에 의해 설정되는 반면, 추가 컨베이어는 제품 출시 속도를 높일 수 없지만 필요한 부품이 제때 출시되지 않으면 속도가 느려질 수 있습니다.

또한 생산 중에 우선순위가 변경될 수 있습니다. 예를 들어, 왼쪽 거울을 생산하는 스테이션은 20개, 오른쪽 미러를 생산하는 스테이션은 10개를 생산하는 반면, 조립 라인에는 15대의 차량이 있고 두 유형의 미러가 15개가 필요한 것으로 나타났습니다. 측정항목의 충돌이 있습니다. 생산량이 양적으로 감소하지는 않았지만(추가 컨베이어가 제 시간에 30개의 제품을 생산함) 여전히 생산이 중단될 위험이 있습니다. Kanban은 이 문제를 해결하도록 설계되었습니다.

가장 간단한 형태의 칸반에는 두 가지 간단한 규칙이 포함되어 있습니다.

• 생산 스테이션에는 부품 생산 계획(“백로그”)이 있습니다. 계획은 우선순위에 따라 정렬되며 언제든지 변경될 수 있습니다(예를 들어 너무 많은 왼쪽 미러를 생산하는 스테이션은 가능한 한 빨리 오른쪽 미러로 전환할 수 있어야 합니다).
• 스테이션에서 동시에 수행되는 작업 수는 제한되어 있습니다(즉, 동시에 지정된 수만큼의 미러를 생성할 수 없음). 이러한 제한은 스테이션의 생산 속도와 계획 변경에 대한 응답 속도를 제어하는 ​​데 필요합니다.

현재 시제

최근 Kanban은 소프트웨어 제작 분야에서 많은 인기를 얻고 있습니다. 일부 팀에서는 이 방법론이 매우 유용하다고 생각하고 일부 팀에서는 이를 "화물 숭배"로 사용합니다. 경험적 경험에 따르면 순수 Kanban은 제품 팀("핵심 파이프라인" 읽기)에는 적합하지 않지만 다음과 같은 지원 팀에는 적합합니다.

• "계획"은 중요하지 않지만 변화에 대한 대응 속도가 중요한 소프트웨어 지원 그룹
• 개발 팀과 별도로 작업하는 테스트 팀
• 지원 서비스;
• "비필수 산업"의 다른 예.

이와 별도로 Kanban은 명확한 계획이 없지만 적극적으로 개발에 노력하고 있는 스타트업에서 잘 작동한다는 점에 유의해야 합니다. 나는 소프트웨어 개발에 Kanban을 사용하는 예를 고려해 볼 것을 제안합니다. 보기 흉한 일러스트에 대해 미리 사과드립니다. 한 명의 개발자로 구성된 팀이 소규모 프로젝트를 진행하고 있다고 상상해 봅시다. 개발 계획(백로그)은 작업 우선순위에 따라 정렬되며, 진행 중인 작업의 팀 제한은 1개입니다.

프로세스를 관리하기 위해 프로젝트 관리자는 다음을 수행할 수 있습니다.

1. 작업 중인 작업 수에 대한 제한을 변경합니다.
2. 가능한 한 빨리 수행되도록 더 높은 우선순위(예: p0)의 작업을 추가합니다.

작업 과정에서 작업이 차단되는 경우(호스팅이 중단되거나 필요한 프레임워크가 다운로드되지 않는 등)가 발생할 수 있습니다. 일반적으로 차단된 작업은 백로그로 반환되고 우선순위가 가장 높은 새 작업이 선택됩니다. 업무 성격과 팀 유형에 따라 한도가 늘어나거나 줄어들 수 있습니다. 예를 들어, 개발자는 등록 양식을 작성하고 새 서버를 배포하는 과정을 동시에 볼 수 있습니다. 그러나 작업 완료 시간이 필요한 시간보다 짧은 경우 프로젝트 관리자는 한도를 줄이거나 팀을 늘릴 수 있습니다. 따라서 적절한 관리를 통해 Kanban은 특정 팀에 가능한 최고 작업 속도, 변경 사항에 대한 최대 응답 속도를 제공하는 동시에 방법론 지원에 대한 "비용"을 줄입니다. 글쎄, 그게 다야! 칸반은 쉽지도, 단순하지도 않습니다. 매우 간단합니다!

제품 팀에서 사용할 때 Kanban의 제한 사항은 다음과 같습니다.

• 이 방법은 대규모 팀(5명 이상)에서는 잘 작동하지 않습니다.
• 순수한 형태의 Kanban은 다기능 팀과 잘 작동하지 않습니다. 저것들. 스크럼과 달리 테스트와 개발을 한 팀에서 결합하는 것은 어렵습니다. 더 나은 아이디어는 프로세스를 별도의 관리자와 백로그가 있는 개발 "스테이션"과 테스트 "스테이션"으로 나누는 것입니다.
• 그 역사와 특성으로 인해 Kanban은 장기 계획을 위한 것이 아닙니다.

결론

결론적으로, “누가 더 멋있는가”라는 원칙에 따라 어떤 방법론을 비교하는 것은 생산적이지도 않고 건설적이지도 않다는 점을 덧붙이고 싶습니다(Captain Obvious). 각각의 다소 일반적인 방법론에는 장점, 단점 및 적용 한계가 있습니다. 또한 애자일 방법론은 본질적으로 팀 구성원의 팀워크와 경험에 더 큰 요구를 합니다.

주제에 관심이 있다면 계속해서 칸반에 대해 좀 더 자세히 살펴보고, 이어서 스크럼과 RUP를 조각과 그림으로 정리할 것을 제안합니다.

좀 더 자세하고 명확하게 보실 수 있습니다.

칸반 - 그게 뭐죠? 칸반 카드에는 얼마나 많은 흥미로운 정보가 포함되어 있으며, 이 방법은 생산에서 어떤 기능을 수행합니까? 이 기사에서는 칸반의 효과적인 사용을 위한 규칙을 자세히 설명하고 특정 예를 사용하여 해당 카드를 사용하는 방법에 대한 명확한 설명도 제공합니다. 또한 자료를 숙지한 후에는 Kanban 보드가 필요한 이유, 생산 외에도 이 방법을 사용하는 것이 바람직한 영역 및 이에 대한 좋은 대안이 될 수 있는 것이 무엇인지 배우게 됩니다.

개념의 본질과 방법의 주요 특징

오늘날 재고 보관 비용이 증가하는 분명한 추세를 볼 수 있는데, 이는 칸반 시스템을 포함하는 "즉각적인" 재고 관리 단지가 형성되는 주된 이유입니다. 일본어로 번역하면 "kanban"은 "태그", "배지"를 의미합니다. 이 용어는 풀 시스템에서 제품의 생산 또는 제외(양도)에 대한 허가 또는 표시를 제공하는 정보의 방법으로 사용됩니다.

정보 전달을 위해 제시된 옵션을 사용하면 정보 카드를 사용하여 특정 생산 주문을 다음 단계에서 이전 단계로 이전함으로써 린 생산 라인을 완벽하게 관리할 수 있습니다.

이러한 생산적인 시스템의 개발자는 Toyota Motors입니다. 그는 제시된 아이디어를 JIT 방식을 실제로 구현하려는 최초의 시도 중 하나로 설명합니다. 칸반 시스템에 따르면 생산은 다음 규칙에 따라 수행됩니다. 기업의 부서에는 주문을 완료하는 데 필요한 특정 수량과 명확하게 정의된 기한에 따라 자원이 공급됩니다.

프로세스 세부정보

제시된 방법의 계획은 매우 간단하지만 생산 프로세스 구성에 매우 효과적인 영향을 미칩니다. 자원 측면에서 기업의 부서를 공급한 후 진행 중인 작업에 필요한 양에 대한 자세한 계산이 수행됩니다. 이는 두 번째 단계에서 직접 이루어져야 합니다(따라서 완제품의 주문은 최종 단계입니다). 과정). 마찬가지로 두 번째 단계에서는 특정 양의 반제품에 대한 요청이 이전 단계로 이루어집니다.

따라서 특정 현장의 생산 규모는 다음 생산 단계의 요구에 따라 형성됩니다. 근처에 위치한 생산 공정의 각 두 단계 사이에 이중 유형의 연결이 설정되는 것이 논리적입니다.

1. n번째 단계부터 n-1까지 진행 중인 작업의 필요한 양을 요청(“풀링”)합니다.
2. n-1단계부터 n단계까지 필요한 물량만큼 물적 자원을 보냅니다.

정보 전송 도구

칸반이 무엇인지 더 잘 이해하려면 이 시스템에서 정보를 전송하는 도구가 두 그룹으로 분류되는 특수 카드라는 점을 이해해야 합니다.

1. 생산 주문과 직접적으로 관련된 도구입니다. 이런 종류의 카드에는 생산 공정의 이전 단계에서 생산해야 하는 부품 수가 먼저 표시됩니다. 생산 n단계에서 n-1단계로 보내지며 이들 현장에 대한 생산 프로그램을 개발하는 주된 이유가 됩니다.
2. 선택 도구에는 이전 조립 단계에서 가져와야 하는 필수 자재 자원(반제품, 자재, 부품 등이 포함될 수 있음)의 양에 관한 정보가 포함되어 있습니다. 이런 종류의 카드는 생산 과정의 n-1단계부터 n번째 단계까지 실제로 받은 자원량을 표시합니다.

카드는 기업의 내부 인프라뿐만 아니라 협력을 지원하는 지점이나 기업 간에도 순환될 수 있다는 점에 유의하는 것이 중요합니다.

칸반을 사용하는 효과적인 방법 - 칸반이란 무엇입니까?

Toyota Motor Corporation의 사장인 Taiichi Ohno는 칸반 카드를 최대한 효율적으로 사용하기 위한 여러 가지 원칙을 개발했습니다.

• 생산 활동의 후속 작업에서는 이전 작업에서 카드에 표시된 부품의 양이 제거됩니다.
• 앞에 있는 생산 작업은 특정 카드에 표시된 수량과 순서에 따라 부품 생성에 따라 수행됩니다.
• 카드 없이 만들 수 있는 부품은 없습니다. 이 조항을 통해 과잉생산과 제품의 과도한 이동을 줄일 수 있습니다. 따라서 유통되는 카드의 양은 최대 인벤토리 양과 같습니다.
• 카드는 제품 제조를 위한 주문입니다(제품은 어떤 경우에도 해당 카드에 부착되어 있습니다).
• 결함이 있는 부품은 후속 공정으로 넘어갈 수 없습니다. 이 조항을 통해 가능한 한 결함이 없는 제품을 생산할 수 있습니다.
• 카드 수를 줄이면 민감도 수준이 높아집니다. 따라서 기존 문제가 밝혀지고 재고에 대한 효과적인 통제가 수행됩니다.

카드 사용의 특징

결과적으로 칸반 관리는 특수 카드를 사용하는 특정 계획에 따라 수행됩니다. 따라서 사용 중에 해당 시스템의 절대적인 가시성과 최대한의 안전성을 보장하기 위한 요구 사항이 완전히 구현되어야 합니다. 즉, 카드 분실 및 혼합이 완전히 제거됩니다.

전문가들은 칸반 시스템에 최대의 생산성을 제공할 수 있는 효과적인 도구를 개발했습니다. 이 방법의 보드는 직원이 직장에서 여러 가지 도구를 사용하는 경우가 많기 때문에 활성 카드를 수집하는 장소 역할을 합니다. 따라서 제조업체로 이동하는 카드는 제어 보드에 배치됩니다. 그리고 새로 받은 카드 도구가 "시작" 필드에 도달하면 해당 부품 번호의 전체 카드 세트가 전송되어 추가 생산 프로세스를 수행합니다.

Kanban 방법을 사용하면 어떤 이점이 있나요?

이를 사용하는 기업은 매일 물적 자원을 공급받습니다(종종 하루에 여러 번). 이를 통해 연중 약 100~300회 정도 생산 재고를 완전히 업데이트할 수 있습니다. Kanban을 MRP 또는 MAP와 같은 시스템과 비교하면 이 경우 업데이트가 약 10배 더 자주 발생합니다.

생산성이 낮은 다른 방법에 비해 절대적인 이점을 보여주는 예를 통해 칸반 방법을 평가하는 것이 좋습니다. 따라서 Toyota Motors Corporation은 1976년에는 하루에 세 번, 1983년에는 10분마다 많은 생산 현장 중 하나에 자원을 공급했습니다.

칸반은 슈퍼마켓과 협력할 때 자주 사용됩니다(이 목적을 위해 특별히 형성된 재고). 따라서 소비자는 위에서 언급한 바와 같이 제품의 양을 나타내는 선택 칸반을 슈퍼마켓에 보내고 슈퍼마켓은 지정된 수의 제품을 그에게 전달합니다. 동시에 슈퍼마켓은 보충 칸반을 공급자에게 보낸 후 공급자는 제품을 슈퍼마켓으로 옮깁니다.

방법의 기본 요소

칸반 시스템의 가장 중요한 구성 요소는 다음과 같습니다.

1. 카드뿐만 아니라 생산, 운송 또는 공급 일정과 기술 지도를 포함하는 정보 단지입니다.
2. 필요에 대한 통제와 전문적으로 직접적으로 관련된 복합체입니다.
3. 전체(TQM) 및 선택적(Jidoka) 제품 품질 관리가 가능한 복합체입니다.
4. 생산의 절대적인 평준화를 보장하는 단지입니다.

제시된 요소를 함께 사용하면 가장 짧은 생산 주기, 높은 수준의 자산 회전율(재고 포함)을 달성할 수 있을 뿐만 아니라 생산에 대한 보관 비용을 제거하거나 최소화하고 최고 품질을 달성할 수 있습니다. 생산 공정의 각 단계에서 제품을 생산합니다.

시스템의 단점과 사용 결과

다른 개발과 마찬가지로 적시 시스템에도 몇 가지 단점이 있습니다. 첫째, 특정 제품의 생산 단계 간에 높은 수준의 일관성을 구성하는 것이 어렵습니다.

둘째, 생산 과정이 중단되어 제품 판매가 중단될 위험이 큽니다. 그럼에도 불구하고 문제의 방법 적용과 관련된 세계 관행에 대한 상세한 분석에 따르면 제시된 시스템을 사용하면 생산 재고를 절반으로, 재고를 8% 줄일 수 있으며 운전 자본 회전율을 크게 가속화하고 , 당연히 완제품의 품질이 향상됩니다.

칸반의 사용은 생산 프로세스에서 끝나지 않는다는 점에 유의하는 것이 중요합니다. 따라서 시스템은 사무실 및 프로젝트 활동, 프로그래밍(칸반 개발의 전체 복합체가 있음)뿐만 아니라 개인적인 결과(개인 유형의 칸반)를 달성하는 데 적극적으로 사용됩니다.

칸반 시스템은 1950년대 Toyota Corporation의 생산 라인에서 시작되었으며 이후 사무실로 옮겨져 프로젝트 관리자에게 중요한 도구가 되었습니다.

실천의 무한한 유연성과 직원의 자기 조직화 기회 덕분에 다른 접근 방식이 효과가 없었던 효율성을 달성할 수 있었습니다. 카드 자체가 시스템의 전화 카드가 된 경우입니다. Kanban을 구현한 조직에서 내부 통화로 자리 잡았습니다.

기원

린 제조 개념과 마찬가지로 칸반 시스템도 Toyota 관리자가 개발했습니다. 시스템 작성자인 일본인 엔지니어 Taiichi Ono는 구매자가 필요한 상품을 직접 선택하는 미국 슈퍼마켓의 운영 원리에서 영감을 받았습니다. Toyota Corporation에서 "슈퍼마켓"의 역할은 창고에서 수행되었습니다.

그곳에서 신호 카드(이것은 "칸반"이 일본어에서 문자 그대로 번역되는 방식)입니다. 작업자는 신호 카드를 교환하여 자신의 손으로 생산 공정을 규제했습니다.

카드는 부품이 담긴 용기에 부착되었습니다. 이 태그에는 부품의 수와 수량, 어느 부서에서 부품을 보냈는지, 부품이 도착해야 하는 위치에 대한 정보가 포함되어 있습니다.

기계 설치 및 조립에 직접 참여한 작업자(다운스트림)는 창고 요청과 함께 "칸반"이 부착된 컨테이너에서 부품을 가져왔습니다. 카드가 제거되었고 빈 상자와 함께 운송인이 창고로 옮겨졌습니다. 그곳에서 또 다른 직원은 이미 생산된 예비 부품에 대한 정보가 포함된 태그인 생산 "kanban"이 부착된 예비 부품이 담긴 새 컨테이너를 준비했습니다.

생산 칸반은 창고에 대한 요청 칸반으로 대체되었으며 업스트림 부품 생산 라인으로 보내졌습니다. 따라서 카드에 표시된 부품 수만큼 정확하게 생산되었습니다. 새 예비 부품이 담긴 컨테이너는 조립 라인의 운송업체로 옮겨졌습니다.

칸반 원칙

Toyota 관리자는 6가지 시스템 형성 규칙을 공식화했습니다.

1. 다운스트림 작업자는 칸반에 표시된 만큼 정확하게 창고에서 부품을 제거합니다.
2. 업스트림 담당자도 카드에 따라 엄격하게 예비 부품을 공급합니다.
3. 칸반 없이는 아무것도 생산되거나 이동되지 않습니다.
4. Kanban은 항상 부품에 부착되어야 합니다.
5. 결함이 있는 부품은 시스템에 사용되지 않습니다.
6. 칸반 카드 수를 줄이면 경영진이 변화에 더 효과적으로 대응할 수 있습니다. 하지만 꼭 필요한 경우가 아니면 설정된 카드 수를 변경하면 안 됩니다.

칸반(Kanban)은 "풀(Pull)" 시스템입니다. 이는 대기 비용을 없애는 지속적인 흐름과 과잉 생산의 위험을 줄이는 최소 WIP(재공품) 사이의 균형을 만듭니다. RVP는 카드를 사용하여 규제됩니다. 카드 번호는 고정되어 있으며 카드에 있는 지침은 다운스트림 수행자를 안내합니다.

필수 태그의 규칙은 에너지 보존 법칙과 유사하게 작동합니다.

RVP 한도는 판매 수준과 현재 프로세스의 통계적 변화에 따라 계산되는 칸반 카드 수에 비례하여 작성됩니다. 최대 태그 수(시스템의 동일한 "에너지")는 언제든지 RVP의 상위 수준을 고정합니다. RVP는 또한 당김 원리에 의해 제한됩니다. 즉, 상부 흐름의 생산 속도는 하부 흐름의 속도에 따라 달라집니다.

그래프는 시스템의 기본 요소 중 하나가 카이젠 문화임을 보여줍니다. 자율적인 프로세스와 표준 변형을 통해 경영진은 지속적인 관리에서 벗어나 직원 성과 개선에 집중할 수 있습니다.

IT에 칸반 적용

Kanban은 계속해서 생산 라인에 가치를 제공하는 동시에 소프트웨어 세계에도 진출했습니다.

마감일, 설명 또는 프로세스 번호 및 수행자 이름에 대한 정보가 포함된 카드만 이제 예비 부품이 있는 컨테이너가 아닌 줄이 있는 열이 있는 보드에 부착됩니다.

• 백로그 - 완료해야 하는 작업
• 현재 개발중인 과제
• 완료되었지만 아직 테스터에게 전송되지 않은 작업
• 테스트 부서로 이전할 준비가 된 작업
• 프로젝트 관리자(PM)가 검토하는 작업
• 완료된 작업

일반적으로 열 위에 숫자가 기록됩니다., 이는 그 안에 있는 최대 프로세스 수를 나타냅니다. 백로그 한도는 선행 시간에 따라 계산됩니다. 시스템에 진행 중인 작업이 5개 있고 각 작업을 완료하는 데 평균 1일이 걸리는 경우 백로그는 5개로 제한될 수 있습니다.

위의 구조는 엄격하지 않습니다 - 프로젝트의 세부 사항에 따라 즉석 연설자가 추가될 수 있습니다.종종 작업을 실행하기 전에 작업 준비 상태에 대한 기준을 결정해야 하는 칸반 시스템이 있습니다. 그런 다음 영어로 호출되는 두 개의 열이 나타납니다. 지정하다(매개변수 지정) 및 실행하다(일을 시작하다).

• 더 우선순위 큐가 있는 열을 추가할 수 있습니다.수행자는 시간이 없을 때 이 특정 작업 열을 비운 다음 다른 작업을 수행해야 합니다.
• 완료되지 않은 작업은 백로그로 반환되거나 구성표에서 삭제됩니다.

• 칸반은 멀티태스킹을 장려하지 않습니다. 하나의 실행자에 대해 프로세스 제한이 설정됩니다.

• 여러 번 시작한 작업보다 완료된 작업이 더 좋습니다.

• 첫 번째 작업이 차단된 경우 두 번째 작업을 수행할 수 있습니다.
• 작업을 완료하는 데 걸리는 시간은 균형을 이루어야 합니다.기간이 너무 짧으면 품질에 영향을 미칩니다. 제한이 과도하게 확장되면 팀 리소스가 낭비되고 프로세스 비용이 증가합니다.

예를 들어 태블릿이나 대형 모니터가 아닌 모든 곳에서 Kanban 보드를 사용하는 이유는 무엇입니까? 시스템 팬이 이 질문에 대답하면 일반 보드에는 두 가지 장점이 있습니다. 간단하고 시각적 제어 기능을 제공합니다. 변경이 쉽고 팀 구성원 간의 촉각적, 사회적 상호 작용을 제공합니다.

칸반의 장점과 단점

칸반에는 다음과 같은 장점이 있습니다.

1. 계획 유연성. 팀은 현재 업무에만 집중하고, 업무의 우선순위는 관리자가 정합니다.
2. 개발 프로세스에 팀 참여도가 높습니다. 정기적인 회의와 투명한 프로세스, 자기조직화의 기회를 통해 직원들은 단결하고 진정한 관심을 보입니다.
3. 주기 기간이 더 짧습니다. 비슷한 스킬을 여러 명이 가지고 있으면 지속시간이 줄어들지만, 한 명만 있으면 병목현상이 나타난다. 따라서 직원들은 지식을 공유하여 주기 시간을 최적화해야 합니다. 그러면 팀 전체가 중단된 작업을 시작하고 원활한 흐름을 복원할 수 있습니다.
4. 병목 현상이 적습니다. RVP 한도를 사용하면 주의력 부족, 사람 또는 기술 부족으로 인해 발생한 병목 현상과 문제 영역을 빠르게 찾을 수 있습니다.
5. 시계. 모든 작업자가 데이터에 액세스할 수 있으면 병목 현상을 더 쉽게 발견할 수 있습니다. Kanban 팀은 카드 자체 외에도 일반적으로 제어 및 누적 흐름 그래프라는 두 가지 일반 보고서를 사용합니다.

실제로 시스템은 비핵심 생산 영역에서 잘 작동합니다.

• 소프트웨어 지원 또는 헬프 데스크 팀.
• Kanban은 명확한 계획 없이 스타트업을 관리할 때 잘 작동하지만 개발이 적극적으로 진행되는 경우에 적합합니다.

Kanban에는 다음과 같은 단점도 있습니다.

1. 5명 이상의 팀에서는 시스템이 제대로 작동하지 않습니다.
2. 장기 계획을 위한 것이 아닙니다.

스크럼과의 차이점

애자일 칸반과 마찬가지로 스크럼은 유연한 방법론이며 IT 분야에서도 자주 사용됩니다. 그들 사이의 차이점은 언뜻 보면 명확하지 않습니다. 예를 들어 두 접근 방식 모두 백로그가 있다는 점 등 많은 유사점이 있습니다.

	스크럼	칸반
속도	고정된 기간의 반복 가능한 스프린트	지속적인 공정
릴리스 릴리스	프로젝트 관리자(제품 소유자)의 승인 후 각 스프린트가 끝날 때	중단 없이 또는 팀의 재량에 따라 흐름이 계속됩니다.
역할	제품 소유자, 스크럼 마스터, 개발팀	PM이 이끄는 팀, 경우에 따라 민첩한 칸반 트레이너가 참여
주요 지표	팀 속도	리드타임
변경 수용 가능성	스프린트 중 변경 사항은 작업 추정이 잘못될 수 있으므로 바람직하지 않습니다.	변화는 언제든지 일어날 수 있다

IT 분야의 적용 사례

Microsoft에서 바로: Kanban이 소프트웨어 개발에 데뷔했습니다.

정보 기술 산업에서 칸반 원칙이 사용되기 시작한 것은 불과 10여년 전입니다. 소프트웨어 개발자를 위한 Kanban의 주요 대중화자 중 한 명인 David Anderson은 2005년에 Microsoft에 컨설팅을 제공했습니다. 그들은 내부 응용 프로그램의 오류를 제거한 XIT Sustained Engineering 부서의 작업에 불만족했습니다. 보고 연도 초에 이 부서는 해당 부서에서 최악이었습니다. 백로그가 허용 크기를 5배 초과했으며, 요청 1개를 처리하는 데 걸리는 시간이 5배에 달했습니다. 선도적인 시간- 보통 5개월 정도 걸렸어요.

새로운 PM은 Anderson의 상담을 통해 9개월 만에 문제 부서의 생산성을 155% 높였습니다. 리드타임이제 5주가 되었고 백로그가 정상 크기로 돌아왔으며 작업의 정시 완료율이 90%로 설정되었습니다. 이 모든 결과는 신입 직원의 개입을 최소화하면서 달성되었으며 직원은 동일한 방법을 사용하여 소프트웨어 오류를 계속 수정했습니다. 작업을 조직하는 접근 방식만 변경되었습니다.

흥미로운 사실: XIT의 판도를 바꾸려고 했던 프로그램 관리자 Dragos Dumitriu는 Anderson의 책에 매료되었습니다. 놀랍게도 그는 전날 직장을 구한 Microsoft 자체에서 소프트웨어 Kanban의 이데올로기를 만났습니다. Dumitriu는 Anderson에게 그의 작업을 도와달라고 요청했고 후자는 그의 책의 원칙을 실행하는 데 동의했습니다.

Dumitriu는 백로그에 80개의 요청이 누적된 세 명의 개발자와 세 명의 테스터로 구성된 부서를 찾았습니다. PM 자신은 ASP 기술 작업 능력, SQL Server를 사용한 관리 및 MS Project Server에 대한 지식이 요구 사항에 포함되어 있기 때문에 임시로 임명되었습니다. 상사들은 이 직책을 프로그래밍 방법을 알고, 보고서를 작성하고, 백로그 로드를 예측해야 하는 "기술자"로 보았습니다. 당시에는 인상적인 데이터 배열이 수집되면 부서의 문제가 식별될 것이라고 믿었습니다. Dumitriu는 그런 "기술자"가 아니었습니다.

그러나 그와 Anderson은 XIT의 성과를 분석하기 시작하면서 부서의 속도에 부정적인 영향을 미치는 주요 요인을 신속하게 식별했습니다.

• 요청 실행 결과(ROM)를 예측하는 데 너무 많은 시간이 걸렸습니다. 개발자와 테스터 모두 필요한 계산, 코드 검토 및 완전한 문서화를 수행하는 데 하루 종일 시간을 투자해야 했습니다. 평균적으로 하루에 한 건의 요청이 접수되었습니다. PM의 추정에 따르면 부서 생산성의 40%가 ROM에 소비되었습니다.
• 더 높은 가치를 지닌 요청에 우선순위가 주어졌습니다. XIT는 주문 비용으로 자금을 받았습니다. 요청의 우선 순위는 부서 관리자와 고객, 즉 다른 부서의 관리자와의 회의에서 매달 논의되었습니다. 현재 속도로 백로그가 폭증하면서 한 달에 6~7개의 요청만 처리되었을 때 시간이 지남에 따라 다른 요청의 우선순위가 끊임없이 바뀌었습니다. 그들 중 다수는 다음 달과 같지도 않은 인상적인 "나중"을 위해 연기되었습니다.
• ROM 단계에서는 요청의 절반이 제거되었습니다. 그 중 일부는 규모가 너무 커서 다른 부서로 이전할 프로젝트로 재인증을 받았고, 다른 일부는 너무 비용이 많이 들어 취소되었습니다. 일부 요청은 구현 시간이 너무 길어서 개발에 반영되지 않았습니다. 따라서 부서 생산성의 40%가 요청 분석에 사용되었으며 그 중 50%가 거부되었습니다. 노동력의 약 15~20%가 낭비됐다.
• 요청에 대한 준비 작업은 구현이 시작되기까지 몇 달 동안 지속될 수 있습니다. 이 시간 동안 ROM 단계의 계산이 손실되거나 잊혀질 수 있습니다. 특히 분석을 시작한 동일한 개발자가 구현을 수행하지 않은 경우에는 더욱 그렇습니다.

문제가 있는 Microsoft 부서를 위한 Kanban 솔루션

1. Dumitriu와 Anderson은 ROM 단계를 포기하는 것에 대해 경영진 및 고객 관리자와 대화를 해야 한다고 주장했습니다. 계산은 구현 직전에 동일한 수행자가 수행했습니다. 즉, "신선한" 상태로 유지되었습니다.
2. 요청사항에 대한 우선순위화는 월례회의가 아닌 상황에 따라 전화나 이메일을 통해 이루어졌습니다. 백로그의 80개 작업을 고객에 따라 정렬했습니다. 후자는 먼저 완료해야 할 주요 쿼리를 강조하라는 요청을 받았습니다.
3. XIT 자금이 고정되었습니다.
4. 요청 비용은 더 이상 고려되지 않습니다.
5. PM은 칸반 보드에 버퍼를 입력했습니다. 개발자는 승인된 작업과 완료된 작업이라는 두 영역에서 작업을 수행했습니다. 버퍼에 6개의 요청이 있었고 5개가 작업에 사용되었습니다. "테스트 대기 중" 버퍼에서 선택된 테스터입니다. 코드 변경이 필요하지 않은 일부 작업은 개발자를 우회하여 종료되었습니다. 요청을 단일 작업 프로세스로 분할함으로써 PM은 상황을 더 잘 제어할 수 있을 뿐만 아니라 고객에게 투명성을 제공할 수 있습니다. 버퍼의 도입으로 리드 타임이 단축되었습니다. 예측 가능한 시스템 하에서 고객은 다음에 누구의 요청을 버퍼링해야 하는지 더 잘 결정할 수 있습니다.
6. 요청이 너무 크거나 비용이 많이 드는 경우 즉시 결정이 내려졌습니다. 개발자가 15일 이내에 작업을 완료할 준비가 되었거나 변경 사항이 그만한 가치가 있다고 확인하면 규모나 비용에 관계없이 요청이 수락되었습니다.
7. PM은 부서의 흐름을 관찰한 후 업무량이 많은 개발자를 위해 직원 구조를 바꿔야 한다는 결론에 도달했습니다. 변경 사항은 2:1 비율로 수행되었습니다. 4명의 개발자와 2명의 테스터가 XIT에서 작업을 시작했습니다.

2005년 말에 부서의 생산성은 155% 증가했습니다. XIT의 작업을 더욱 개선하기 위해 두 명의 직원(개발자 한 명과 테스터 한 명)을 고용했습니다. 백로그의 요청 수가 10개로 줄어들었고, 한 개발자가 분기당 11개의 요청을 지속적으로 처리하기 시작했습니다. 이전에는 11개였던 것에 비해 분기당 평균 56개의 요청이 완료되었습니다. 요청 비용은 7,500달러에서 2,900달러로 감소했습니다.

Corbis에서의 지원

Microsoft에서 성공을 거둔 Anderson은 2006년에 새로운 과제를 해결하기 시작했습니다. 이제 그는 아직 MS를 떠나지 않은 Bill Gates의 또 다른 회사인 Corbis에서 근무했습니다. Corbis의 활동 중 하나는 사진 라이센스였습니다. 당시 약 35,000장의 이미지 데이터베이스를 보유한 세계에서 두 번째로 큰 사진 스톡이었습니다.

Anderson의 임무는 회사의 주요 릴리스를 가속화하는 것이었습니다. 퇴사 간격은 3개월이었고, 더 길어질 수도 있다. 출시 계획을 논의하는 데만 2주가 걸렸습니다. 2주마다 마이너 릴리스나 업데이트가 릴리스되도록 준비해야 했습니다. 동시에 주요 자원은 주요 프로젝트 작업에 투입되어야 했습니다.

Anderson이 매일 팀과 소통하는 Corbis 사무실에 Kanban 보드가 나타났습니다. PM의 목적은 프로세스에 대한 시각적 제어를 개선하고, 자기 조직화를 촉진하며, 수행자의 개인적 책임감을 높이는 것이었습니다. Kanban 시스템은 또한 관리 감독을 줄이고 생산성을 높이는 것을 목표로 했습니다.

다양한 색상의 카드와 그래프 외에도 보드에 "휴지통"이 나타 났으며 너무 큰 작업은 휴지통으로 보내졌습니다.

공식 사진

David J Anderson의 소프트웨어 시스템 엔지니어링 지속을 위한 칸반 시스템

칸반 시스템은 흐름이 원활하지 않은 곳과 지연이 발생하는 소위 병목 현상을 명확하게 보여줍니다. 팀과의 빠른 토론은 현재 문제를 파악하는 데 도움이 되었습니다. 예를 들어 테스트는 3일 동안 진행되어 출시 날짜에 부정적인 영향을 미쳤습니다. 세 명의 직원이 팀을 이루어 시간을 하루로 줄이는 방법을 찾았습니다.

병목 현상은 자원 제한이나 인력의 생산성으로 인해 작업 흐름이 급격히 감소하는 회사의 운영 계획이나 알고리즘의 한 부분입니다. 인력 부족, 인터넷 불량, 이사의 휴가 등으로 인해 작업 완료가 차단되거나 느려집니다.

Kanban 카드 한도는 경험적으로 두 번 설정되었습니다. "개발 준비 완료" 열에서 제한이 늘어났습니다. "테스트 준비 완료"라는 새로운 열도 있습니다. 다운스트림에 대한 많은 요청이 잘못 구성되어 불필요한 시간이 낭비되었습니다. 이에 PM은 상부 흐름의 작동을 점검한 결과 오류를 발견했다.

요청을 처리하는 데 100일이 걸릴 수 있었지만 계획대로 여전히 2주마다 릴리스가 나오기 시작했습니다. 호의 내용에 대한 결정은 게재 5일 전에 이루어졌습니다. Microsoft XIT 부서의 경우처럼 계산 방식은 생산성을 위해 포기되었습니다. 작업의 우선순위는 "지연 비용" 또는 리소스 가용성에 따라 결정되었습니다.

칸반 시스템은 Anderson이 목표를 달성하는 데 도움이 되었을 뿐만 아니라 팀의 분위기도 향상시켰습니다. 공동 논의와 프로세스 가시성 덕분에 직원들은 서로에 대한 신뢰를 쌓았습니다. 직원들도 카이젠, 즉 지속적인 개선의 실천에 동참했습니다.

칸반 방법론은 무엇이며 시간 내에 작업을 완료하는 데 어떻게 도움이 됩니까?

지속적인 멀티태스킹과 많은 수의 고객이 있는 상황에서는 조만간 모든 시스템이 과부하 상태가 됩니다. 마감일을 놓치기 시작하고 기대가 충족되지 않으며 시스템이 혼란에 빠지게 됩니다. 오늘 저는 칸반과 같은 방법론에 대해 알아볼 것을 제안합니다. 이 접근 방식은 자원을 효과적으로 할당하고 모든 문제를 해결할 것을 약속합니다. 점검 해보자.

칸반 역사의 순간

카반 아이디어의 기초는 Toyoyta Motors에 의해 발명되었습니다. 한 자동차 제조사는 생산라인의 부적절한 재고배분과 생산능력으로 인해 막대한 손실을 입고 있었습니다. 일부 생산 단계는 유휴 상태일 수 있었고 일부는 과부하되었습니다.

1959년에는 라인의 모든 섹션의 균형을 맞출 수 있는 생산 관리 시스템이 제안되었습니다. 기본 원칙은 각 단계에서 작업자가 필요한 부품 수를 담은 카드를 게시하고 이를 라인으로 전달하는 것이었습니다. 생산 라인을 따라가는 각 작업자는 이전 작업에서 카드에 할당된 만큼의 부품을 정확하게 가져갔습니다.

이렇게 하면 모든 부품에 카드가 있고 잉여가 있을 수 없습니다. 결과적으로 해당 지역의 재고가 증가하지 않았고 이후의 각 작업자는 필요한 부품 수를 정확하게 받았습니다.

칸반이 무엇인지 공식화하고 이를 인터넷 제품 개발에 적용해 보겠습니다.

Kanban은 정보 카드를 사용하여 생산의 모든 단계에서 주문을 전달하는 린 제조 관리 시스템(일본어: "신호"/"카드")입니다. 간단히 말해서, 우리는 아이디어부터 매장 선반에 출시되기까지 제품의 전체 경로를 추적합니다.

위는 칸반 보드입니다. 이는 작업 상태를 표시하는 주요 도구입니다. 주요 원칙: 특정 작업이 생산 프로세스의 어느 단계에 있는지 확인합니다. 또한 모든 영역에서 시간이 추적됩니다. 즉, 시스템에서 언제든지 " "를 찾아 작업할 수 있습니다.

프로젝트의 특성에 따라 열 수를 직접 결정합니다. 이것이 제품이 거치는 주요 단계라는 것이 중요합니다. 위의 예는 온라인 제품이 거치는 주요 단계의 플러스 또는 마이너스입니다.

방법론의 적용 범위는 매우 넓습니다. 칸반은 프로젝트 구현, 영업 관리, 생산 라인, IT 개발, 심지어 자신의 삶을 정리하는 데에도 사용됩니다.

읽기를 방해해서 죄송합니다. 내 텔레그램 채널에 가입하세요. 새로운 기사 발표, 디지털 제품 개발 및 성장 해킹 등 모든 것이 있습니다. 너를 기다리고있어! 계속하자...

칸반 원칙

• 작업의 시각적 표시. 모든 과제는 카드 형태로 제시되어야 하며 보드에 반영되어야 합니다. 작업 상태를 업데이트하는 것은 매우 중요합니다. 예를 들어, 개발자가 코드를 준비하고 테스트를 위해 제출한 경우 작업 카드는 해당 열로 이동해야 합니다. 따라서 모든 팀원은 언제든지 작업이 어느 단계에 있는지 확인할 수 있습니다.
• 생산의 각 단계에서 WIP(진행 중인 작업 또는 동시에 수행된 작업) 열에 대한 제한이 있습니다. 시스템이 조만간 작업 흐름에서 "막히지" 않도록 하려면 제한 사항을 설정해야 합니다. 예를 들어, Analisis 열(분석) 위의 칸반 보드에는 2명의 직원이 근무하고 있으며 그들은 2개 이상의 작업을 처리할 수 없습니다. 시스템의 후속 단계가 유휴 상태이므로 더 많이 로드할 필요가 없습니다. 열 제한사항은 경험적으로 선택됩니다.
• 완료되지 않은 작업에 집중하십시오. 작업이 포함된 보드를 볼 때 우선 하나 또는 다른 열에 "걸려 있는" 작업에 주의를 기울이세요. 단계 중 하나에 가장 많은 시간이 걸리는 경우 가능하면 리소스를 재분배하거나 인력을 추가해 보십시오.
• 지속적인 개선. 시스템의 로드 밸런싱을 완료하면 전체 프로세스를 모니터링하기가 더 쉬워집니다. 주기 시간(작업이 별도의 열에 표시되는 시간, To do에 들어간 순간부터 완료가 해제될 때까지의 시간)을 측정합니다. 시스템의 로드를 변경하고 모든 단계를 완료하는 데 걸리는 시간을 줄입니다.
• 세부 사항에주의하십시오. 예를 들어, 개발자가 정기적으로 작성하는 코드가 테스트를 통과하지 못하고 수정을 위해 반환되는 경우 더 높은 품질의 제품이 테스트되도록 개발 품질을 향상시킬 수 있는 옵션이 있을까요?

칸반 접근 방식은 이상적으로 보일 수 있지만 그 원칙이 결과를 낳는다고 확신합니다. 우선 방법론을 상황에 맞게 조정한 다음 시스템을 다듬어야 합니다.

칸반 도구

또는 칸반 보드를 유지 관리할 위치입니다.

• 엑셀 테이블
• 스티커가 붙은 보드
• 또 다른 환상...

실제로 옵션이 많이 있습니다. Google에서 검색하여 영감을 얻을 수 있습니다. 가장 중요한 것은 이 보드가 있고 프로세스의 모든 참가자가 현재 작업에 무슨 일이 일어나고 있는지 볼 수 있다는 것입니다.

칸반 보드의 예

벽에 걸린 보드가 있는데, 각 작업이 스티커 메모에 반영되어 있습니다.

아니면 Trello와 같은 클라우드 서비스일 수도 있습니다.

작업에 어떤 도구와 옵션을 사용할지에 대해 여러 가지 의견이 있지만 이는 대부분 취향의 문제입니다. 다양한 솔루션을 시도해보고 가장 마음에 드는 솔루션을 선택하세요. 요점은 칸반을 사용하기 시작하고 가능한 가장 아름다운 보드를 사용하는 데 얽매이지 않는 것입니다.

제 생각은 오프라인에서 브레인스토밍이나 사례 작업을 할 때 스티커가 있는 일반 보드가 잘 작동한다는 것입니다. 하지만 일상적인 작업에는 물론 Jira, Kanbantool, Trello 등과 같은 클라우드 솔루션을 사용해야 합니다. 여기에서 전체 팀은 작업에 댓글을 추가하고 열별로 이동하는 등의 작업을 수행할 수 있습니다.

뉘앙스/생각

인터넷 제품에 대해 이야기하면 칸반이 작동하고 도움이 되고 개선되지만 고려해야 할 여러 가지 우려 사항이나 뉘앙스가 있습니다.

• 대부분의 경우 열에 WIP 제한을 도입하면 프로젝트 관리 팀이 약간 겁을 먹을 수 있습니다. 결국, 개발자나 예를 들어 테스터가 동시에 해결할 수 있는 작업 수를 어떻게 확인할 수 있습니까? 제한사항을 도입했는데 그들이 그냥 가만히 있으면 어떻게 될까요?

사람이 완전히로드되지 않은 경우 이는 나쁘지 않습니다. 그는 완료된 작업을 연구 및 분석하고, 단점을 찾아 수정하고, 심지어 휴식을 취할 수도 있습니다. 또한 프로세스의 다른 부분(열)에서 동료를 도울 수 있습니다. 자세한 내용은 아래를 참조하세요.

• kanaban 전문가에 따르면 이 시스템은 다기능 팀에서 이상적으로 작동합니다. 뭐, 그런 일이 없으면 가서 동료를 도우세요. 사실, 개발자가 테스터가 될 수 있고 그 반대의 경우도 가능하고 시스템 설계자가 디자이너를 도울 수 있는 팀을 구성하려면 많은 돈을 투자해야 하는데 그만한 가치가 있습니까?

물론, 팀원들이 서로에게서 배우고 무슨 일이 생기면 어떤 식으로든 도움을 줄 수 있다는 것은 좋은 일입니다. 하지만 이 조건을 충족하려면 근처 어딘가에 앉아서 지속적으로 소통하는 소규모 팀이 필요합니다. 대규모 프로젝트에서는 이러한 경험 교환을 재현하기가 어렵습니다.

그래서 조용한 시간이 있으면 기술을 연마하려는 경향이 더 큽니다. 당신이 한 일을 살펴보고, 어떻게 개선할 수 있는지 생각해 보고, 유용한 기사를 읽어보세요. 사람은 컨베이어 벨트의 톱니바퀴가 아니라 살아있는 유기체입니다.

총

우리는 칸반 방법론을 살펴보았으며 이제 이를 프로젝트에 적용하는 방법을 이해하셨기를 바랍니다. 프로세스를 주요 단계로 나누고 얻은 지식을 기반으로 시스템을 최적화하십시오.