Rabbit

MRP는 처음엔 마법처럼 보였다 - 자재가 자동으로 계산되는 원리

2026-09-09T13:00:01Z

안녕하세요. Rabbit입니다. 생산 파트에서 일하다 보면 늘 같은 계산에 시달립니다. "이 제품 100개 만들려면 부품이 몇 개 필요하지? 재고는 얼마 남았고, 언제 발주해야 납기에 맞지?" 이걸 매번 손과 엑셀로 계산하다 보면 실수가 납니다. 어떤 자재는 모자라 라인이 멈추고, 어떤 자재는 남아 창고에 쌓이죠. 그런데 SAP의 MRP는 이 계산을 한

PP를 처음 만난 날 - 생산계획부터 실적까지, PP가 하는 일

2026-09-02T10:10:30Z

안녕하세요. Rabbit입니다. 프로젝트에서 제가 맡은 건 PP, 생산 모듈이었습니다. 처음 이 단어를 들었을 때는 막막했습니다. BOM, Routing, MRP, 생산오더, CNF. 단어들이 각각 따로 떠다니는 것 같았거든요. 그런데 시간이 지나며 알게 됐습니다. 이 개념들이 사실은 하나의 흐름으로 이어져 있다는 것을. 그 흐름이 머릿속에 자리잡자,

시스템이 바뀌어도 사람은 그대로였다 - 변화관리, 도입 후 왜 더 힘들어지는가

2026-08-31T10:00:07Z

안녕하세요. Rabbit입니다. SAP를 도입하면 바로 업무가 편해질 거라 기대했습니다. 그런데 오픈 첫 주, 현장은 오히려 더 혼란스러웠습니다. "예전이 훨씬 편했는데." 여기저기서 이 말이 나왔습니다. 시스템은 최신이 됐는데, 정작 사람은 아직 준비되지 않았던 겁니다. 그 간극을 메우는 일이 변화관리였습니다. 도입 초기엔 오히려 일이 늘어난다 새

컷오버, 그 30시간을 잊지 못한다 - 롤백과 데이터 불일치의 현장 기록

2026-08-06T11:00:01Z

안녕하세요. Rabbit입니다. 계획은 완벽했습니다. 시스템도 세팅되었고, 데이터 이전 순서도 문서로 정리됐고, 팀원 모두 자기 역할을 외우고 있었습니다. 그런데 자정이 넘어가자 하나씩 어긋나기 시작했습니다. 재고 목록과 실제 수량이 안 맞고, 일부 데이터가 엉뚱하게 넘어가고. 컷오버 개요 글에서 계획을 이야기했다면, 이 글은 그 계획이 현장에서 어떻게

컷오버가 시작되면 되돌릴 수 없다 - 오래된 시스템과 작별하던 밤

2026-08-04T11:00:01Z

안녕하세요. Rabbit입니다. 오랫동안 운영해온 동네 맛집이 새 건물로 이전한다고 생각해보세요. 수개월 공사 끝에 새 주방이 완성됐습니다. 이제 남은 건 하나, 문을 열고 손님을 맞는 것. 그런데 이게 간단하지 않습니다. 기존 재료를 새 냉장고로 옮기고, 직원은 새 동선에 적응하고, 단골에게 새 위치를 알려야 합니다. 이전하는 그날 하루, 모든 게 동

UAT, 진짜 주인이 처음 시스템을 써봤다 - 현업이 직접 돌려본 그 순간

2026-07-30T11:00:02Z

안녕하세요. Rabbit입니다. 프로젝트가 막바지에 다다르면, 컨설턴트와 개발자는 자신감이 붙습니다. "이만하면 됐다." 기술적으로는 거의 완벽한 시스템이 눈앞에 있으니까요. 그런데 이 시스템에서 매일 일할 진짜 주인은 따로 있습니다. 현업 사용자입니다. UAT는 그 주인이 문을 열기 전 직접 써보고 "좋아, 이제 열어도 되겠다"고 사인하는 마지막 관문

통합 테스트에서 처음으로 전부가 연결됐다 - 각자 만든 것이 하나로 맞물리던 날

2026-07-28T11:00:02Z

안녕하세요. Rabbit입니다. 프로젝트를 하다 보면 이상한 순간이 옵니다. 각 팀이 자기 부분을 다 만들었다고 하는데, 정작 합쳐보기 전까지는 이게 진짜 돌아가는지 아무도 확신하지 못하는 순간. 단위 테스트로 부품 하나하나는 검증했습니다. 그런데 부품이 다 좋아도, 그것들이 하나의 흐름으로 이어지지 않으면 시스템은 돌아가지 않습니다. 통합 테스트는 그

단위 테스트를 건너뛴 대가는 컸다 - 작은 것 하나가 전부를 흔들 때

2026-07-23T11:00:03Z

안녕하세요. Rabbit입니다. 프로젝트를 하다 보면 통합 테스트 단계에서 갑자기 이런 말이 나오곤 합니다. "이 기능이 왜 이렇게 나오죠? 분명히 개발했는데." 그 기능을 만든 개발자를 찾으면, 개발자 입장에서는 제대로 만들었다고 합니다. 그런데 다른 기능과 붙이고 나니 오류가 납니다. 원인을 찾다 보면 결국 부품 하나의 문제였습니다. 미리 검사했어

프로토타입을 보고서야 같은 그림을 봤다 - 말로 한 요구사항이 실제와 달랐던 아유

2026-07-21T11:00:05Z

안녕하세요. Rabbit입니다. 프로젝트 도중에 이런 말을 들은 적이 있습니다. "저희가 요청한 건 이게 아닌데요." 개발이 한참 진행된 뒤였습니다. 돌이키기엔 이미 늦은 시점이었고, 팀 전체가 밤을 새워 수습에 들어갔습니다. 그 경험 이후로 프로토타입 테스트의 중요성을 몸으로 이해했습니다. 시범 매장을 먼저 차린다 프로토타입 테스트는 본격 개발

Fit/Gap, 맞는 것과 안 맞는 것 사이 - 본격 개발 전에 반드시 거쳐야 했던 그 단계

2026-07-16T11:00:04Z

안녕하세요. Rabbit입니다. 프로젝트 초반에 이런 질문을 받았습니다. "우리 회사가 원하는 기능, SAP가 얼마나 기본으로 줄까요?" 단순해 보이는 질문이었는데, 막상 답을 찾기 시작하니 생각보다 복잡했습니다. 회사마다 일하는 방식이 다르고, SAP 표준이 그걸 다 커버하지는 않으니까요. 그 질문에 답하는 과정이 바로 Fit/Gap 분석이었습니다.

PI가 그린 그림, 구축이 읽은 도면 - 같은 문서를 두고 우리는 다른 질문을 했다

2026-07-14T11:00:07Z

안녕하세요. Rabbit입니다. 구축 프로젝트가 시작되고 첫 회의에 들어갔을 때였습니다. 책상 위에는 제가 PI 때 만든 문서가 놓여 있었습니다. 몇 달을 들여 그린, 우리 회사가 앞으로 이렇게 일하면 좋겠다는 그림. 저는 그게 자랑스러웠습니다. 그런데 그 문서를 펼쳐 든 구축 컨설턴트의 첫 마디는 제 예상과 달랐습니다. "이거, 표준으로 되나요?"

SAP 구축 프로젝트에 던져졌던 날 - 기술보다 소통이 먼저였던 현장 이야기

2026-07-10T03:31:19Z

안녕하세요. Rabbit입니다. PI가 끝났습니다. 우리가 앞으로 어떻게 일할지, 그 그림이 문서로 정리됐습니다. 그리고 곧바로 구축 프로젝트가 시작됐습니다. 저는 그 그림을 들고 다시 그 자리에 앉았습니다. 이제 실제 시스템을 만드는 단계였죠. 설레기도 했지만, 솔직히 말하면 겁이 더 컸습니다. 그림을 그리는 것과 그걸 짓는 건 전혀 다른 일이었으니까

PI 담당이라는데, 뭘 해야 하죠 - 시스템보다 먼저 바뀌어야 했던 것

2026-07-10T03:59:10Z

안녕하세요. Rabbit입니다. 프로젝트 초반, 저는 'PI 담당'으로 지정됐습니다. Process Innovation. 프로세스 혁신이라는데, 솔직히 막막했습니다. 저는 시스템을 만드는 사람도 아니고, 개발을 아는 것도 아니었으니까요. 생산관리 현업으로 일하던 사람이 갑자기 무엇을 혁신하라는 건지 감이 안 왔습니다. 그때는 몰랐습니다. 그 자리가 왜

SAP 도입 첫날, 아무도 설명해주지 않았다 - 현업 생산관리에서 SAP 구축 멤버가 되기까지

2026-07-10T03:18:50Z

안녕하세요. Rabbit입니다. 생산관리로 일하던 어느 날, 회사에서 SAP를 도입하기로 했습니다. 발표가 나던 날, 회의실 분위기는 조용했습니다. 다들 표정은 평온했지만, 속으로는 저와 비슷한 생각을 하고 있었을 겁니다. 'SAP가 뭐지?' 물어볼 수도 없었습니다. 모르는 게 나만인 것 같았으니까요. 그리고 얼마 뒤, 저는 PI 담당으로 지정됐습니다