생산에서 긴급 조달은 드물게 자생적으로 발생합니다. 그 원인은 생산 계획의 변경, 소모 기준의 오류, 공급자의 지연, 장비의 고장 또는 적시 전송되지 않은 요청일 수 있습니다. 이러한 요청이 일반 프로세스에 포함되지 않고 처리될 때 복잡성이 시작됩니다: 전화로, 메신저에서, 분산된 표와 개인적인 서신을 통해 이루어집니다.
결과적으로 승인된 계획은 더 이상 작업 기준이 되지 않습니다. 조달자는 가장 시끄러운 요청으로 관심을 전환하고, 창고는 상충되는 지시를 받고, 관리자는 이미 부족이나 초과 지출이 발생한 후에 결과를 보게 됩니다. 이때 긴급성은 항상 중요성을 의미하지는 않는데, 단일한 시스템이 없다면 위기 상황에서의 필요와 불충분한 계획을 구분하기 어렵습니다.
비계획 조달의 위험
- 재고 및 개방된 발주 확인 없이 주문이 중복됨;
- 단일 상태 부재로 인한 승인 지연;
- 변경 이력 없이 공급 계획의 수동 수정;
- 공급자를 위한 불분명한 우선순위와 불완전한 맥락;
- 이탈 원인과 주체를 빠르게 파악할 수 없음;
- 불완전한 데이터에 기반한 예산, 기한 및 위험에 대한 결정.
주요 과제는 신속성과 통제를 결합하는 것입니다. 생산에서는 빠른 응답이 필요하지만, 가속화가 리미트, 승인 경로 및 정당화 확인을 포기하는 것을 의미해서는 안 됩니다. 규칙이 프로세스에 내장되어 있지 않으면 회사는 정말로 중요한 필요를 지연시키거나 혼란스러운 비용을 초래할 수 있습니다.
OpenBox가 요청을 관리 가능한 프로세스로 되돌리는 방법
신청 관리 프로그램에서 긴급 필요는 규정, 책임자 및 단계가 포함된 객체로 등록됩니다. 사용자는 무엇이 필요한지, 어떤 부서나 생산 과제를 위한 것인지, 수량과 기한은 어떤 것인지 지정합니다. 필요에 따라 긴급성의 이유를 기록하고 증빙 자료를 추가합니다.
서신 대신 통일된 요청
모든 요청은 지정된 형식을 통과하여 변경 이력을 저장합니다. 조달자는 작성자, 우선순위, 기한, 승인자, 관련 항목 및 현재 상태를 확인할 수 있습니다. 이는 확인 요청 수를 줄이고 исходные 데이터를 확인하지 않고 조달을 시작하는 일을 방지하는 데 도움이 됩니다.
규칙에 따른 라우팅
요청은 부서, 금액, 카테고리, 필요 유형 또는 긴급성 기준에 따라 전달할 수 있습니다. 표준 및 비계획 요청에는 서로 다른 라우팅이 설정됩니다. 긴급 요청에 대해서는 반드시 근거와 필요한 관리자 참여를 지정해야 할 수 있습니다. 이렇게 하면 예외가 묵인되는 것이 아니라 통제 가능한 프로세스의 일부로 남게 됩니다.
공급 계획과의 연계
관리자는 전반적인 그림을 얻습니다: 무엇이 계획되어 있는지, 무엇이 추가되었는지, 어떤 요청이 승인되고, 어떤 것이 이미 조달로 이첩되었는지를 확인합니다. 변경 사항은 로컬 파일에 사라지지 않고 필요의 역사 일부가 됩니다. 이로 인해 주문뿐만 아니라 그 원인에 대해서도 논의할 수 있습니다…
현재 프로세스를 조사하고 하나의 요청 유형에 대한 파일럿 경로로 시작할 수 있습니다. 이를 통해 실제 작업에서 접근 방식을 테스트하고 필요한 규칙을 결정하며 확장을 위한 기반을 준비할 수 있습니다.