이아나이ERP 검토: 설계변경 영향 미리보기와 AI 재무 승인

공식 홈페이지가 설명하는 설계변경 영향 미리보기

이아나이ERP 공식 홈페이지는 부품 변경의 영향이 닿는 BOM, 판매주문, 진행 중인 작업지시서와 원가를 승인 전에 보여준다고 설명합니다.

참고 근거: [s1]

AI Financial Officer 문서가 설명하는 사람의 승인

이아나이ERP의 AI Financial Officer 문서는 되돌릴 수 없는 재무 조치에는 사람의 승인이 필요하다고 설명합니다.

참고 근거: [s2]

3. 샘플 데이터는 비슷한 예시보다 경계가 드러나는 예시로 준비하라

구매자 데모에서 가장 먼저 무너지는 부분은 샘플 데이터의 설계다. 보기 좋은 예시를 늘어놓는 것보다, 어떤 정보가 들어오면 어디까지 검토해야 하는지가 선명한 예시를 준비해야 한다. 예를 들어 부품 변경을 다룬다면, 하나의 변경이 여러 검토 대상에 어떻게 닿는지 보여 주되, 서로 다른 판단이 섞이지 않도록 사례를 분리하는 편이 낫다. 반대로 너무 복잡한 예시는 설명이 길어질 뿐 판단 기준을 흐릴 수 있다. 재무 제안도 마찬가지다. 금액이 큰 제안과 작은 제안을 나누기보다, 되돌릴 수 있는 제안과 되돌릴 수 없는 제안을 분리해 두어야 승인 필요 여부를 비교하기 쉽다. 즉 샘플 데이터는 실제 업무를 그대로 흉내 내는 자료가 아니라, 무엇이 검토 범위이고 어디서 사람이 개입해야 하는지를 드러내는 기준표에 가깝다. 데모 전에 이 기준표를 먼저 만들면 설명이 흔들려도 핵심 질문은 유지할 수 있다.

4. 역할 분리는 권한표보다 먼저 질문 순서를 정하는 일이다

역할 분리를 확인할 때는 누가 어떤 권한을 갖는지보다, 누가 먼저 무엇을 묻고 다음 사람에게 무엇을 넘기는지가 더 중요하다. 실제 도입 검토에서는 설계 담당자, 생산 담당자, 원가 담당자, 승인자가 같은 정보를 보더라도 질문의 순서가 다를 수 있다. 이 순서가 정리되지 않으면 데모가 길어질수록 설명은 많아지지만 책임은 흐려진다. 재무 제안도 같다. 작성자, 검토자, 승인자, 보류 판단자가 각각 어떤 질문에 답해야 하는지 미리 정리해 두면, 어떤 단계에서 판단이 바뀌어야 하는지 확인하기 쉬워진다. 이때 중요한 것은 한 사람이 모든 답을 대신할 수 있는지보다, 역할마다 확인해야 할 항목이 서로 겹치지 않는지다. 데모 중에는 화면 구성이나 메뉴 이름을 적는 데 시간을 쓰기보다, 각 역할이 반드시 확인해야 하는 질문이 무엇인지 적어 두는 것이 더 실무적이다. 그렇게 해야 나중에 운영 단계에서 누가 무엇을 보고 판단해야 하는지 정리할 수 있다.

5. 증거 기록은 남는다는 말보다 다시 검증할 수 있어야 한다

증거 기록을 볼 때는 기록이 저장되는지보다, 나중에 같은 판단을 다시 검토할 수 있는지가 핵심이다. 부품 변경이든 재무 제안이든, 중요한 것은 사건이 있었다는 사실 자체보다 그 사건을 어떤 근거로 판단했는지를 재현할 수 있느냐이다. 따라서 데모에서는 누가 어떤 이유로 판단했는지, 그 이유가 어떤 형태로 묶이는지, 이후 다른 사람이 보아도 맥락이 이어지는지를 물어야 한다. 기록이 많아도 찾기 어렵다면 감사나 내부 점검에 쓰기 힘들고, 기록이 단순해도 질문이 명확하면 충분할 수 있다. 그래서 기록 확인은 양의 문제가 아니라 연결성의 문제로 보아야 한다. 구매자는 데모에서 기록 화면이 예쁘게 보이는지보다, 승인·거절·보류의 차이를 다시 설명할 수 있는 흔적이 남는지를 확인해야 한다. 이 질문이 준비되어 있으면 “기록이 있다”는 말만으로는 통과하지 않고, 실제 운영에 필요한 수준의 검증이 가능한지를 판단할 수 있다.

6. 승인·거절·보류는 세 갈래가 아니라 서로 다른 원칙이다

승인, 거절, 보류를 한 화면에서 함께 보더라도 세 결과를 같은 기준으로 묶어서는 안 된다. 승인 시나리오에서는 어떤 근거가 충족되면 통과되는지, 거절 시나리오에서는 어떤 조건이 충족되지 않아 멈추는지, 보류 시나리오에서는 어떤 추가 확인이 필요한지를 각각 따로 확인해야 한다. 부품 변경의 경우도 변경 영향이 보였다고 해서 곧바로 승인 가능한 것은 아니다. 영향 범위가 허용 가능한지, 누가 최종 판단을 하는지, 누락된 항목은 없는지까지 물어야 한다. 재무 제안도 마찬가지다. 되돌릴 수 없는 조치인지 먼저 확인해야 하는지, 금액이 큰지 작은지가 우선인지, 예외 승인 경로가 있는지 등을 순서대로 점검해야 한다. 데모에서는 세 결과를 하나의 흐름처럼 보지 말고, 각 결과가 서로 다른 판단 원칙을 요구하는지 확인하는 편이 좋다. 그렇게 해야 자동화가 편의를 위한 것인지, 통제를 위한 것인지 구분할 수 있다.

가상 사례의 입력값과 기대 결과를 미리 적기

예를 들어 가상의 조립품 A에서 규격이 다른 부품 B로 교체한다고 가정해 보세요. 사례 표에는 교체 전후 부품 번호, 샘플 주문 번호, 변경 시점, 검토 대상에 포함시키고 싶은 기록을 적습니다. 비교용으로 변경과 무관한 주문을 한 건 더 준비하면 데모에서 어디까지 검토 대상으로 삼을지 물어보기 좋습니다. 원가 검토가 필요하다면 예상 변동을 계산할 때 사용한 단가와 수량을 따로 적고, 시연 결과와 수치를 바로 비교하지 말고 두 계산이 같은 전제를 쓰는지부터 살펴보세요. 재무 사례는 이와 별개의 가상 데이터로 준비합니다. 최종 기록을 변경하는 요청 하나와 설명이나 검토만 필요한 요청 하나를 나란히 놓고, 각각 어떤 역할이 판단해야 하는지 팀 내부 기준을 먼저 씁니다. 승인 없이 진행을 시도하는 예제도 넣을 수 있지만 운영 데이터에는 영향을 주지 않는 테스트 환경을 사용하고, 어떤 결과를 확인해야 합격으로 볼지 미리 합의하세요.

7. 확인할 질문은 기능 목록보다 예외 상황에서 만든다

좋은 데모 질문은 기능 목록을 따라 적는 데서 나오지 않는다. 실제로는 예외 상황에서 질문이 더 선명해진다. 예를 들어 부품 변경이 있었는데 일부 항목은 영향이 있고 일부는 영향이 없다면 어떻게 보이는지, 검토 도중 다른 부서가 추가 의견을 넣으면 기존 판단과 어떻게 연결되는지, 승인자가 바뀌면 이전 검토 내용이 이어지는지 같은 질문이 예외를 드러낸다. 재무 제안도 비슷하다. 금액은 작지만 되돌릴 수 없는 조치인지, 금액은 크지만 되돌릴 수 없는 조치는 아닌지, 보류 후 다시 올릴 때 이전 근거가 남는지 등을 물어야 한다. 이렇게 준비하면 시연이 일반 소개인지 실제 운영 검증인지 구분하기 쉽다. 특히 설명이 많을수록 질문은 더 구체적이어야 한다. 무엇이 보이는가보다 어떤 경우에 다시 확인해야 하는가를 묻는 편이 실무에 가깝다. 데모는 제품 소개가 아니라, 예외를 다루는 방식이 실제 업무와 맞는지 확인하는 자리라는 점을 잊지 않는 것이 좋다.

시연 결과를 도입 판단으로 옮기는 방법

시연이 끝나면 검토표를 두 장으로 나누고 각 질문의 결과를 확인, 미확인, 추가 시연 필요로 기록해 보세요. 답변이 구두 설명에 머물렀다면 확인으로 표시하기보다 어떤 입력을 바꾸고 어떤 결과를 다시 볼지 정해 두는 편이 좋습니다. 예를 들어 가상 부품 변경을 다시 실행할 때는 동일한 부품 번호와 변경 사유를 쓰고, 다른 생산 상태를 가진 작업을 한 건씩 추가해 결과의 차이를 질문할 수 있습니다. 별도의 재무 예제에서는 같은 제안을 승인 역할과 검토 역할로 각각 열어 어떤 판단 정보가 제시되는지 묻고, 데이터에 변화가 있었다면 테스트 전후 값을 대조해 보세요. 어느 경우든 결과를 추정으로 채우지 말고 실행한 사람, 시각, 입력 조건과 다음 담당자를 같은 행에 남깁니다. 판단이 유보된 항목에는 다음 시연에서 반드시 확인할 질문과 통과 기준을 붙이면, 다른 팀이 기록만 보고도 검토를 이어갈 수 있습니다.

실무 질문

공급업체 설명 근거