1편에서 AI 서버가 MLCC를 얼마나 삼키고 있는지, 왜 0201·고용량 패키지가 먼저 말라붙는지를 봤다. 그 글의 결론은 세 가지였다: 재고를 잡아라, 다변화해라, 스펙을 풀어라. 이번 편은 그 다음이다. 견적서에 “sorry, no stock"이라고 적혀 돌아왔을 때, 발주 라인에서 실제로 통하는 것들을 순서대로 펼쳐본다. MLCC — 손톱보다 작은 이 칩 하나가 발주서를 24주 묶는다. 1. 거절에는 네 가지 얼굴이 있다 공급사가 “없다"고 할 때, 사실은 네 다른 상황을 한 단어로 뭉갠 것이다. 대응이 완전히 다르다. ...
대시보드를 다 만들고 일주일쯤 지난 어느 월요일, 저는 또 메신저로 “이번 주 입고 현황 좀 정리해줄래요?” 라는 요청을 받았습니다. 화면은 멀쩡히 돌아가고 있었습니다. 숫자도 맞았습니다. 그런데도 사람들은 여전히 저에게 물었고, 여전히 각자 엑셀을 만들고 있었습니다. 그날 알았습니다. SCM 자동화의 진짜 적은 SAP도, 데이터도, 코드도 아니라는 걸. ‘잘 만들었지만 아무도 안 쓰는 것’ — 이게 내부 도구가 죽는 가장 흔한 방식입니다. 이번 3편은 그래서 기능 이야기를 잠시 멈추고, 사람을 대시보드 안에서 일하게 ‘강제’하는 설계와, 그 설계에서 역산한 개발 체크리스트를 다룹니다. ...
지난 1편에서는 “추출 → 저장 → 표현” 3단계로 SCM 자동화 대시보드의 큰 그림을 그렸습니다. 이번 2편은 그중 가장 사고가 잦은 첫 단계, ‘추출’ 만 깊게 파봅니다. 결론부터 말하면, 추출은 화려하지 않지만 여기서 한 번 삐끗하면 뒤의 모든 숫자가 거짓말이 됩니다. 그래서 저는 이 단계에 가장 많은 안전장치를 넣었어요. 코드를 직접 타이핑하지 않고 AI에게 설계를 맡긴 비개발 실무자의 시선에서, 무엇을 조심해야 했는지 풀어봅니다. 이 글에서 알 수 있는 것: ✅ 왜 ‘추출’이 파이프라인에서 가장 위험한 단계인지 ...
“이번 주 입고 현황 한 장으로 정리해줄래요?” 이 한 마디에 SAP 화면 여러 개를 오가며 엑셀을 갈아 쓴 적, 있으시죠. 저도 매주 월요일 아침마다 같은 일을 반복하다가, 결국 AI 도구로 SCM 자동화 대시보드를 직접 만들기로 했습니다. 이 글은 개발자가 아닌 구매 실무자가, AI 어시스턴트에게 설계를 맡겨 만든 사내 SCM 대시보드 구축기 1편입니다. 첫 편은 큰 그림 — 데이터가 어디서 어디로 흐르고, 무엇이 어떻게 화면에 뜨는지 — 만 다룹니다. 이 글에서 알 수 있는 것: ...
