개방 루프 프로세스가 비즈니스에서 정보 흐름을 방해하는 방법

나는 경력을 쌓는 동안 상당한 양의 비즈니스 프로세스 재설계를 수행했으며, 내가 찾은 가장 큰 문제는 항상 동일하다는 것입니다. 바로 개방 루프 비즈니스 프로세스입니다. 개방 루프 프로세스는 대부분 책임이 여러 사람과 여러 부서에 나누어져 있기 때문에 발생합니다. 새로운 장비에 대한 요청과 함께 R&D에서 시작되는 정보 흐름은 재무 및 구매를 거쳐 조직 경계를 벗어나 공급업체(여기서 여러 부서를 차례로 거치게 됨)로 이동한 다음 결국 다시 입고 및 구매로 이동할 수 있습니다. , 운 좋게도 흐름을 시작한 R&D 그룹.

각 단계에서 커뮤니케이션이 중단될 가능성이 있으며 프로젝트 관리자는 이러한 위험을 완화해야 합니다. 비즈니스 프로세스에 구축된 정보 흐름이 예외를 포착한 다음 처리하도록 명시적으로 구조화되어 있지 않으면 훨씬 나중에 또는 전혀 감지되지 않을 때까지 실패가 감지되지 않습니다. 일부 정보 흐름 장애는 상대적으로 중요하지 않은 항목이 올바르게 주문 또는 전달되지 않는 결과를 낳지만, 다른 장애는 조직에 막대한 비용을 초래하거나 업무상 중요한 활동에 지연을 초래할 수 있습니다.

개방 루프는 수백만 달러의 비용이 들 수 있습니다.

요점을 설명하기 위해 먼저 더 이상 추적할 수 없는 수억 달러의 장비에 세금을 내고 이 불필요한 비용을 없애고자 했던 대규모 제약 회사에 대해 이야기하겠습니다. 우리 프로젝트는 많은 근본적인 프로세스 결함을 발견했습니다. 이 모든 결함으로 인해 연간 최대 수천만 달러의 불필요한 세금이 추가되고 실수로 같은 것을 여러 번 주문하는 데 훨씬 더 많은 비용이 소요됩니다.

책임 영역 간의 일방적인 의사 소통

모든 대규모 조직과 마찬가지로 책임은 사일로에 있었습니다. 제조 부서의 누군가는 장비 X가 필요하므로 재무 부서에 알리고 구매 주문(PO)이 생성됩니다. 주문하면 PO가 공급업체에 전송됩니다. 앞으로 1년까지 X가 입고되고 배달됩니다. 수신은 제조 및 재무에 알립니다. 재무 부서는 자산 태그를 발행하고, 수신은 X에 뺨을 때립니다. X는 생산 라인에 배치되고 모든 것이 정상입니다.

제외하고는 모두 좋지 않습니다. 처음에는 직원들이 왔다 갔다 하고, 같은 역할의 다른 누군가가 9개월 전에 X를 주문했다는 사실도 모른 채 X를 주문하기 쉽습니다. 재무팀은 이 주문이 중복되었다는 것을 알지 못합니다. 그들은 단순히 또 다른 X가 필요하다고 가정하므로 다른 PO가 생성되고 다른 주문이 이루어집니다. 그 외에도 실수로 과도하게 주문하지 않더라도 보유하고 있는 항목을 빠르게 잊어버릴 수 있습니다.

X가 아마도 필 피니시 라인인 복잡한 장비라고 가정해 봅시다. 20개의 주요 구성 요소로 구성되어 있으며 모두 사용 기간 동안 여러 번 교체됩니다. X의 한 부분에 아무렇게나 붙인 자산 태그는 마모로 인해 사라집니다. 설상가상으로 자산 태그가 제 시간에 수신에 도달하지 않아 적용조차 되지 않을 수 있습니다. 그 후에는 아무도 X를 추적하는 방법을 알지 못하므로 수명이 다했을 때 X를 폐기하는 방법을 모릅니다. 세금 관점에서 X는 여전히 작동하는 과세 대상 항목입니다.

20년이 넘는 기간 동안 이것은 중요하지 않은 방식으로 수익에 타격을 주기 시작할 것입니다. 또한 재무 부서는 ERP 시스템의 한 부분을 자산 지정자 세트와 함께 사용하는 반면 제조 부서는 자산 지정자 세트가 다른 완전히 별도의 ERP 모듈을 사용하고 있습니다. 연말이 되면 아무도 두 세트의 수치를 일치시킬 수 없으며 감사관은 왜 자본 장비와 관련하여 수천만 달러 또는 수억 달러의 불일치가 발생하는지 의문을 제기하고 있습니다.

이것은 일련의 개방 루프 비즈니스 프로세스에서 발생하는 고전적인 문제입니다. 개방 루프는 프로세스 흐름 라인을 따라 명시적인 확인 지점을 구축하지 않는 경우입니다. 위의 예에서는 실패가 보장된 개방 루프 프로세스가 너무 많았습니다.

양방향 정보 흐름 생성

문제를 해결한 방법은 다음과 같습니다. 우리는 처음부터 끝까지 모든 중요한 프로세스 흐름을 모델링했습니다. 우리는 모든 열린 루프를 식별했습니다. 그런 다음 처음부터 이러한 루프를 한 번에 하나씩 닫는 간단한 방법을 설계했습니다.

1단계

제조에는 X가 필요하므로 재무에 PO를 개설하도록 요청합니다. 이제 재무팀은 24개월 전 X에 대한 이전 주문의 세부 정보를 제공하여 확인을 위해 제조와 확인합니다. 실수로 주문이 중복되는 것을 방지합니다.

2단계

제조 부서에서는 수명 기간 동안 교체될 X의 구성 요소에 대한 분석을 재무 부서에 제공합니다. 재무 부서는 각 구성 요소에 대한 자산 태그를 생성하고 제조와 확인합니다. 두 ERP 모듈 모두 구성 요소별로 일치하는 자산 태그로 채워져 자산 수명 주기 전반에 걸쳐 추적이 가능합니다.

3단계

수신은 재무에 통지하고, 재무는 제조에 통지합니다. 자산 태그 배치는 각 태그가 올바른 구성 요소에 배치되었는지 확인하기 위해 제조의 책임자가 수행합니다. 모든 태그/구성 요소는 두 ERP 모듈에 대해 재확인됩니다.

4단계

구성 요소가 교체될 때마다 Manufacturing은 재무부에 알리고 해당 구성 요소에 대한 새 자산 태그가 생성되어 Manufacturing에서 새 구성 요소에 배치한 다음 두 ERP 모듈에서 확인됩니다. 그런 다음 재무 부서는 장부에서 오래된 구성 요소를 제거하는 프로세스를 시작하고 제조는 GMP(Good Practice Guide) 폐기 프로세스를 거칩니다. 폐기가 끝나면 Manufacturing은 자산을 장부에서 제외할 수 있도록 재무에 알립니다.

세부 사항은 이 단순화된 예보다 약간 더 복잡하지만 요점은 분명합니다. 길을 따라가는 모든 단계에서 명시적인 확인과 확인이 있습니다.

비상 조치 보장

다른 프로젝트에서 저는 서비스 회사가 고객 만족도를 향상시키는 데 도움을 달라는 요청을 받았습니다. 그들의 비즈니스는 모두 청구 처리에 관한 것이었으며 입찰에서 낙찰되지 않을까 걱정했습니다. 또한 낙찰된 입찰에서 고객의 불만으로 인해 손실 계정 비율이 너무 높았습니다.

다시 한 번 개방 루프 프로세스였던 문제의 핵심을 식별하는 데는 며칠 밖에 걸리지 않았습니다. 잠재 고객이 입찰을 요청하면 계정 관리자는 내부 시스템을 사용하여 입찰 구성 책임자에게 클라이언트 요구 사항 개요를 보냅니다. 그런 다음 입찰 작성자는 입찰을 생성하여 클라이언트에게 전달합니다. 바라건대, 클라이언트는 일반적으로 입찰 작성자가 다음 버전에 구축할 원하는 수정 사항으로 결국 응답할 것입니다. 어느 시점에서 클라이언트는 입찰을 수락하고 회계, 송장 발행 및 온보딩 팀 브리핑에서 새 고객 계정을 생성합니다.

첫 번째 문제는 입찰 생성자로부터 계정 관리자에게 명시적인 확인이 없었기 때문에 때때로 입찰가가 생성되어 제시간에 전송되지 않았고 아무도 그것에 대해 알지 못했다는 것입니다. 이것은 내부 시스템에 입찰 마감일을 표시하는 필드가 없었고 입찰 작성자가 끊임없이 과로했기 때문에 입찰 제출이 너무 늦었기 때문입니다. 비즈니스의 열악한 정보 흐름으로 인해 이러한 상황은 결코 표면화되지 않았습니다.

그 후 입찰 수정 사항이 계정 관리자에게 전송되지 않았습니다. 이것은 클라이언트가 마침내 점선에 서명했을 때 온보딩 팀에 브리핑한 사람이 계정 관리자였기 때문에 중요했습니다. 종종 브리핑은 클라이언트가 실제로 수락한 입찰가가 아니라 계정 관리자의 초기 이해를 기반으로 했습니다.

계약이 시작되면 클라이언트 문서가 도착하여 처리 풀에서 해당 주에 처리하도록 할당된 팀 구성원에게 전달되었습니다. 접수 확인이 명확하지 않아 처리 결과가 나오지 않는 이유를 고객이 묻기 전까지는 아무도 모르게 서류가 분실될 수 있었다.

처리된 문서가 클라이언트에게 다시 보내졌을 때 수신 확인이 없었기 때문에 누군가가 부재에 대해 불평하기 시작할 때까지 누락된 문서는 볼 수 없게 되었습니다.

주요 이벤트 확인

입찰 프로세스의 각 단계에서 명시적 확인을 구축했습니다. 우리는 시스템 결함에 대한 해결 방법을 만들었으며 필요한 날짜 및 후속 입찰 수정을 포함하여 모든 중요한 정보를 캡처했습니다. 우리는 회사 내, 회사와 클라이언트 간의 비즈니스의 모든 정보 흐름에 대해 명시적인 확인 및 확인을 구현했습니다.

예를 들어 고객이 문서 패키지를 보내면 이제 고객 계정 관리자에게 이메일을 보내 이를 알립니다. 고객 계정 관리자는 청구 처리에서 이를 책임 당사자에게 전달합니다. 3일 이내에 문서를 받지 못하면 경고가 발생합니다. 문서가 수신되면 수신 확인 이메일이 클라이언트에게 전송되었습니다. 회사에서 처리된 문서를 고객에게 다시 보낼 때도 그 반대였습니다.

대부분의 고객이 미국 우편을 사용하여 하드카피 문서를 앞뒤로 섞기 때문에 각 단계에서 명시적 확인을 사용하는 폐쇄 루프 프로세스는 손실된 문서를 신속하게 식별하고 상황을 수정하기 위한 조치를 취할 수 있음을 의미했습니다.

설계 예외 처리 절차

예외 처리 절차를 합리적으로 간단하면서도 효과적인 방법으로 구성할 수 있는 방법을 알아보기 위해 내가 원인 조사에 주력하는 과학 연구 조직의 CIO였을 때 겪었던 또 다른 실제 사례를 살펴보겠습니다. 노화와 노화 관련 질병의 원인.

NIH가 자금을 지원하는 모든 연구 기관에는 여러 개별 연구실이 있으며, 각 연구실은 PI(Principal Investigator)가 운영하고 다양한 하위 과학자와 박사후 연구원으로 구성되어 있습니다. 어느 시점에서 PI는 새로운 다중 챔버 시약 트레이가 필요하므로 Post-doc 중 한 명에게 필요한 요청을 생성하도록 요청합니다. Post-Doc은 요청을 생성하고 이를 재무 부서에 이메일로 보내 PO 제기를 요청하고, PI가 요청이 전송되었음을 인지하도록 PI를 참조합니다. 한편, PI는 특정 날짜까지 확인을 받지 못한 경우 요청 상태를 확인하도록 상기시키는 자동 달력 알림이 설정되어 있습니다. 이것은 post-doc이 필요한 요청을 생성하거나 보내는 것을 잊어버린 경우에 대비한 안전 장치(failsafe) 메커니즘을 보장합니다.

이제 Post-doc도 마찬가지로 정해진 기간 내에 PO가 제기되었다는 확인을 받지 못한 경우 재무 부서에 체크인하라는 자동 일정 알림이 있습니다. 재무 부서에서 PO를 제기하면 Post-doc은 공급업체에 전송되었다는 확인 이메일을 받고 Post-doc은 이 확인을 PI에 전달합니다.

이 단계에서 PI 또는 사후 문서는 또 다른 자동 일정 알림을 설정하여 일정 기간 내에 공급업체로부터 아무 응답이 없는 경우 누군가가 공급업체에 확인하여 PO 수령 및 발송물 발송을 확인합니다. 주문한 장비.

공급업체가 PO 수신을 확인하고 발송 알림과 함께 항목을 발송한다고 가정하면 이는 PI 또는 사후 문서로 전달됩니다. 그런 다음, 예정된 수령일로부터 3일 후에 최종 캘린더 알림을 설정하여 품목이 나타나지 않을 경우 공급업체에 연락하여 발생한 상황을 추적하고 품목을 올바르게 배송할 수 있도록 합니다. 항목이 계획대로 도착하면 사후 문서가 재무에 알리고 조직에서 자산 태그를 사용하는 경우 이 프로세스 세트를 시작할 수 있습니다.

모든 단계에서 명시적인 확인이 필요하며 주요 프로세스 흐름이 중단된 경우 수정 조치가 발생하도록 하는 하위 프로세스를 사용할 수 있습니다. 매달려 있거나 확인되지 않았거나 지원되지 않은 상태로 남아 있는 것은 없습니다. 모든 사람이 무엇이 필요하고 일이 잘못될 경우 어떻게 해야 하는지 알고 있기 때문에 임시 조치가 필요하지 않습니다.

SQL에서 폐쇄 루프 프로세스 생성 학습

좋은 프로세스의 본질은 트랜잭션 일관성을 보장하기 위해 SQL 기반 관계형 데이터베이스가 설계된 방식과 매우 유사합니다. 작업이 완료된 것으로 가정하려면 모든 작업을 확인해야 합니다. 모든 양방향 통신에는 프로세스의 일부로 명시적인 확인이 내장되어 있어야 하며, 확인을 받지 못한 경우 올바른 조치가 취해지도록 하기 위해 개발된 하위 프로세스가 필요합니다. 성공적인 프로젝트 관리자는 폐쇄 루프 프로세스를 만들어 비즈니스의 정보 흐름을 개선하고 조직에서 많은 시간과 비용을 절약해야 합니다.