이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
구매·조달 수업에서 배운 일반적인 발주 프로세스는 크게 다섯 단계입니다. 구매 요청 접수 → 공급사 선정·견적 비교 → 발주서 발행 → 납기 모니터링 → 입고 확인·마감으로 이어집니다. 각 단계에서 오류가 발생하기 쉬운 지점은 발주서 발행 시 수량·단가 입력 오류와, 납기 모니터링에서 이슈를 늦게 파악하는 경우입니다. 이를 줄이려면 발주서 발행 전 검토 체크리스트와 납기일 기준 자동 알림 설정이 효과적입니다. 학교 실습에서는 소규모 발주 시뮬레이션을 진행했는데, 각 단계를 명확히 구분하고 담당자와 완료 기준을 지정하는 것이 프로세스 안정성을 높인다는 것을 배웠습니다. 실무에서는 ERP 시스템과 연동해 단계별 상태를 추적하는 방식이 표준이라고 이해합니다.
발주 프로세스에서 제가 중요하게 보는 건 요청하는 사람과 승인하는 사람, 검수하는 사람이 나뉘어 있어야 한다는 점입니다. 수업에서 한 사람이 요청부터 승인까지 다 쥐면 통제가 무너진다는 걸 배웠습니다. 그래서 저는 단계를 거치는 것 자체보다, 각 단계의 책임이 누구에게 있는지가 분명한지를 먼저 보겠습니다. 특히 승인 금액 기준이 없으면 큰 발주를 여러 건으로 쪼개 승인을 우회하는 일이 생긴다고 배웠습니다. 그래서 금액대별 승인 권한이 정해져 있는지를 절차의 핵심으로 봅니다. 다만 제 한계도 분명합니다. 실제 ERP에서 이 권한 매트릭스를 어떻게 설계하고 예외를 거는지는 운영해 본 적이 없어, 지금은 통제의 원리를 이해하는 단계입니다. 발주는 단계를 밟는 일이면서, 동시에 누구도 혼자 끝낼 수 없게 나눠 두는 일이라고 봅니다.
발주 프로세스를 단순히 절차대로 처리하는 데서 끝내면 안 된다고 보는 이유는, 같은 문제가 반복되는 신호를 놓치기 때문입니다. 수업 실습에서 발주 건을 다루며, 특정 공급사가 자꾸 납기를 넘긴다면 그건 개별 건의 문제가 아니라 패턴이라는 걸 느꼈습니다. 그래서 저는 발주를 건건이 닫는 데 그치지 않고, 납기 이탈이 잦은 공급사나 자주 수정되는 품목 같은 신호를 모아 보는 절차를 두는 게 맞다고 생각합니다. 그 신호를 미리 잡으면 문제가 터지기 전에 대응할 수 있습니다. 다만 한계도 인정합니다. 이런 패턴 분석은 발주 데이터가 충분히 쌓이고 ERP가 그걸 뽑아 줘야 가능한데, 저는 그 시스템을 직접 운영해 본 경험이 없습니다. 그래서 지금은 개별 처리를 정확히 하면서, 반복 신호를 의식하는 눈부터 기르려 합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 타라TPS 구매 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.