GIZ SYSTEMS / SPREADSHEET TO MODEL

엑셀을 옮기기 전에, 예외부터 읽습니다

열과 수식만 옮기면 사람의 판단은 파일에 남습니다. 실제 예외 한 건에서 업무 모델을 찾는 방법.

아키텍처 개념도
Giz Systems 아키텍처 개념도

아키텍처 개념도

“이 엑셀을 웹으로 만들어 주세요.” 요구사항은 간단해 보입니다. 그런데 담당자는 빨간 셀을 보고 거래처에 전화하고, 메모에 적힌 입고 예정일을 바꾸고, 특정 주문을 집계에서 제외합니다. 이 판단이 빠진 채 입력 화면만 옮기면 새 시스템 옆에 또 다른 엑셀이 생깁니다.

마지막으로 수정한 행을 함께 봅니다

첫 인터뷰에서는 빈 양식보다 실제로 수정했던 행 한 개를 봅니다. 무엇이 바뀌었는지, 왜 바꿨는지, 누구에게 확인했는지, 그 뒤 어떤 일이 일어났는지 묻습니다. 숨긴 열, 셀 메모, 색의 의미도 이때 드러납니다.

예를 들어 자재 부족 관리표의 “입고일”은 시스템의 예정일일 수도 있고, 담당자가 협력사에 전화해 확인한 날짜일 수도 있습니다. 두 값이 다르면 최신 날짜 하나로 덮어쓰기보다 출처와 확인 시점을 함께 남기는 편이 판단에 도움이 됩니다.

한 행을 업무 기록으로 바꾸는 여섯 가지

정의할 것 자재 부족 업무의 예
식별자 어느 품목·공장·주문에 대한 부족인가
사실과 출처 ERP의 발주 수량, 창고의 가용 재고, 협력사의 입고 확인
기준 시점 재고 조회 시각, 계획 버전, 입고일 확인 시각
판단 긴급 운송, 대체 품목 검토, 생산 순서 변경
책임과 상태 검토 담당자, 승인자, 대기·확정·완료 조건
근거 선택한 이유, 대안, 관련 메일·문서

모든 메모를 구조화할 필요는 없습니다. 계산·검색·승인에 쓰이는 정보는 필드로 정의하고, 사람이 설명해야 하는 맥락은 기록으로 남깁니다.

예외는 범위 밖에 두지 않습니다

정상 처리와 함께 “품목을 찾지 못함”, “확인한 입고일이 다시 변경됨”, “두 사람이 동시에 수정함”을 한 번씩 따라가 보세요. 화면에서 막혔을 때 누가 판단하고 어디에 기록할지가 정해져야 현업이 별도 파일로 빠져나가지 않습니다.

기존 엑셀과 새 시스템은 같은 입력·기간·단위로 대조합니다. 차이가 나면 수식 오류, 누락, 수동 보정 중 무엇인지 분류합니다. 기존 결과가 항상 정답은 아니지만 차이에는 설명이 있어야 합니다.

첫 완료 기준은 파일 수보다 업무의 완결입니다

파일을 없애는 것은 활동 지표입니다. 담당자가 예외를 접수하고, 필요한 사람의 결정을 받고, 조치 결과를 확인했는지가 업무의 완료 기준입니다. 엑셀 내보내기나 임시 분석이 필요한 일까지 금지할 이유는 없습니다. 공식 상태와 결정 근거가 어디에 남는지를 일관되게 유지하면 됩니다.

첫 적용 범위는 한 팀의 반복 업무 하나로 정하세요. 인터뷰 자료에는 최근 정상 사례 한 건, 예외 사례 몇 건, 쓰던 파일, 원천 데이터 담당자를 포함합니다.

이 흐름을 업무 앱으로 구성하는 방법

이 아티클이 유익하셨나요?

엔지니어링 팀 및 비즈니스 동료들과 공유해 보세요.

LinkedIn 공유 ↗

X (Twitter) ↗

링크 복사

전체 인사이트

구축 견적에 운영의 끝까지 담는 법

같은 납기 준수율이 부서마다 다른 이유

다음 단계

가장 복잡한 업무 하나를 가져오세요.

현재 쓰는 파일과 시스템, 바꾸고 싶은 일을 함께 살펴보겠습니다.

도입 상담하기 ↗