SAP PI, 매장만 새로 단장해선 레시피가 안 바뀝니다

안녕하세요, Rabbit입니다! 🐰

레스토랑을 통째로 리뉴얼했습니다. 인테리어도 바꾸고, 홀 POS도 새것으로 교체하고, 주방 설비까지 싹 들어냈습니다. 그런데 이상합니다. 레스토랑은 새것인데 운영은 예전 그대로입니다.

손님 주문은 여전히 종이 메모지로 돌고, 식자재 발주는 담당자 수첩에 의존하고, 하루 매출 정산은 사장이 밤마다 엑셀로 마감합니다.

새 공간 위에서 옛날 방식이 그대로 굴러가고 있는 것이죠.

이것이 SAP 도입 현장에서 가장 많이 반복되는 실패 패턴입니다. 시스템은 바꿨지만 ‘일하는 방식’을 바꾸지 않은 것입니다. SAP PI(Process Innovation)는 바로 이 문제를 해결하는 작업입니다.

PI가 없으면 어떻게 되는가

레스토랑 전체를 리뉴얼하기로 했습니다. 공사 전에 한 가지를 먼저 물어봐야 합니다. “지금 운영 방식에서 진짜 문제가 뭔가요?” 이 질문에 제대로 답하지 않은 채 공사만 마치면 어떻게 될까요.

새 홀이 생겼지만 주문서는 여전히 서빙 직원이 손으로 써서 주방에 전달합니다. 새 POS가 있지만 마감 정산은 사장이 밤마다 엑셀로 합니다. 공간은 바뀌었는데 동선은 예전 그대로입니다.

이것이 SAP 도입 실패의 전형입니다. 시스템보다 프로세스가 먼저입니다.

PI 없이 SAP를 도입하면 SAP는 정말로 ‘비싼 엑셀’이 됩니다. 데이터 입력 창구만 하나 더 생긴 것이고, 기존 수작업은 그대로 남습니다.

PI가 하는 일: 레시피와 동선을 다시 짜는 것

PI(Process Innovation, 프로세스 혁신)는 “지금 이 방식이 정말 최선인가?”라는 질문에서 시작합니다. 더 나은 방식이 있다면 기존 프로세스를 버리고 새로 설계합니다.

레스토랑으로 옮기면 이렇습니다. 설비를 바꾸기 전에, 먼저 이런 질문을 던지는 것이죠.

• 주문이 홀에서 주방으로 전달되는 과정에 불필요한 단계가 없는가?
• 식재료 발주를 수첩에 손으로 적는 것이 최선인가?
• 실적 집계를 사람이 일일이 모아서 입력해야 하는가?

이 질문들을 통해 없애야 할 과정, 자동화할 과정, 순서를 바꿔야 할 과정을 찾아냅니다. 그 결과물이 새로운 프로세스 설계도입니다. SAP는 이 설계도를 담는 그릇입니다.

💡 핵심: PI와 자동화(RPA 등)는 다른 개념입니다. 자동화는 기존 프로세스를 더 빠르게 돌리는 것입니다. PI는 프로세스 자체를 없애거나 재설계합니다. 없애야 할 과정을 자동화하면 낭비를 더 빠르게 만들 뿐입니다.

PI가 없는 현장 vs PI를 거친 현장

레스토랑 운영으로 비교해 봅니다.

PI 전 — 끊어진 흐름

홀에서 손님 주문이 들어오면 서빙 직원이 손으로 써서 주방에 전달합니다. 주방은 그 메모를 보고 조리를 시작하지만, 몇 테이블이 대기 중인지, 식자재 재고가 얼마나 남았는지는 실시간으로 파악이 안 됩니다. 하루 장사가 끝나면 사장이 영수증을 모아 직접 집계합니다.

이 흐름의 문제는 명확합니다. 단계마다 정보가 끊기고, 사람 실수가 쌓이고, 상황을 파악하려면 누군가 일일이 취합해야 합니다.

PI 후 — 이어진 흐름

손님 주문이 홀 POS에 입력되는 순간, 주방 모니터에 자동으로 뜹니다. 식자재 소진 현황은 실시간으로 업데이트되고, 재고가 기준치 아래로 떨어지면 발주 신호가 나갑니다. 하루 매출은 마감 버튼 하나로 정산됩니다.

이 차이를 만드는 것이 PI입니다. SAP는 이렇게 설계된 흐름을 실행하는 도구입니다.

같은 레스토랑, 같은 SAP 시스템이라도 PI를 거쳤느냐 아니냐에 따라 현장의 체감은 완전히 달라집니다.

그림 1. PI 전후 레스토랑 운영 흐름 비교

PI는 어떻게 진행되는가

PI 프로젝트는 일반적으로 세 단계로 진행됩니다.

1단계: 현재 진단(As-Is 분석)

“지금 우리 레스토랑은 어떻게 돌아가고 있는가?” 현업 인터뷰와 업무 관찰을 통해 실제 흐름을 문서화합니다. 어디서 병목이 생기는지, 어떤 작업이 중복되는지, 어떤 데이터가 끊기는지를 파악합니다.

2단계: 목표 설계(To-Be 설계)

“이상적으로 어떻게 일하고 싶은가?” 현행 문제를 기반으로 개선 방향을 설계합니다. 이때 SAP가 제공하는 Best Practice나 업계 표준 프로세스를 참고합니다. 이 단계에서 나온 설계도가 SAP 구축의 기준이 됩니다.

3단계: 실행 설계

To-Be 프로세스를 SAP 시스템 안에서 어떻게 구현할지를 구체화합니다. 어떤 T-CODE를 쓸지, 어떤 화면 순서로 업무가 진행될지, 어떤 권한을 누가 가질지를 정합니다.

⚠️ 주의: PI는 IT 팀이나 컨설턴트만의 작업이 아닙니다. 실제 업무를 가장 잘 아는 현업 담당자가 중심에 있어야 합니다. 현업 없이 설계된 프로세스는 현장에서 동작하지 않습니다.

PI 담당자로 투입됐다면

SAP 구축 프로젝트에서 ‘PI 담당’으로 지정받은 현업 담당자라면 처음에 막막하게 느껴질 수 있습니다. 본인이 시스템을 만드는 사람도 아닌데 무엇을 해야 하는지 모르는 경우가 많습니다.

핵심은 하나입니다. “지금 우리가 하는 이 일, 왜 이렇게 하고 있는가?” 이 질문을 일상 업무마다 던지는 것이 PI 담당자의 가장 중요한 역할입니다. 오랫동안 해왔기 때문에 당연하다고 느끼던 것들 중에, 실은 없애도 되거나 바꿔야 할 것들이 반드시 있습니다.

컨설턴트가 그 답을 알려줄 수는 없습니다. 현업만 알고 있습니다.

Rabbit의 한 끗

SAP PI와 SAP 구축은 다른 프로젝트처럼 느껴지지만, 사실 하나의 흐름입니다. PI가 ‘어떻게 일할지’를 설계하고, SAP 구축이 그 설계대로 시스템을 만드는 것입니다.

순서를 바꾸면 문제가 생깁니다. 시스템을 먼저 만들고 거기에 업무를 끼워 맞추면, 현업은 시스템 때문에 더 불편해졌다고 느낍니다. 반대로 PI가 잘 된 현장에서는 SAP가 실제로 일을 줄여줍니다.

레시피와 동선이 먼저 바뀌어야 새 설비가 의미를 가집니다. 시스템 도입의 성공은 기술이 아니라 설계에서 결정됩니다. 😎

---

더 읽어보기

• SAP 입문, 레스토랑 주방으로 이해하는 통합 두뇌
• SAP 컷오버, 오래된 주방에서 새 주방으로 이사하는 날
• SAP 구축 프로젝트, 새 매장을 여는 다섯 고비