상황
같은 정보인데, 시스템마다 다른 값이 살았다
고객 정보, 주문 상태, 재고 수량. 한 시스템에서 바꾸면 다른 곳도 바뀌어야 하는데 담당자가 CRM, 시트, ERP를 오가며 같은 값을 손으로 다시 입력한다.
한 곳을 깜빡하면 시스템마다 다른 값이 산다. 어느 게 맞는지 몰라 고객에게 틀린 정보를 안내하고, 재고가 맞지 않아 사고가 난다.
고객 정보, 주문 상태, 재고 수량. 한 시스템에서 바꾸면 다른 곳도 바뀌어야 하는데 담당자가 CRM, 시트, ERP를 오가며 같은 값을 손으로 다시 입력한다.
한 곳을 깜빡하면 시스템마다 다른 값이 산다. 어느 게 맞는지 몰라 고객에게 틀린 정보를 안내하고, 재고가 맞지 않아 사고가 난다.
동기화 안 된 값 하나가 실제로 무엇을 무너뜨리는지, 숫자로 보면 이렇다.
"한 곳 바뀌면 연결된 데 전부 무조건 자동 덮어쓰면 되지 않나?" 이 유혹부터 검토했다.
무조건 덮어쓰기는 위험하다. 잘못 입력된 값, 충돌하는 두 변경을 그대로 전파하면 오히려 모든 시스템이 틀린 값으로 오염된다. 변경을 감지해 반영하되, 충돌·민감 변경은 확인을 거쳐야 한다.
"한 곳의 변경을 감지해 연결된 시스템에 반영하는" 90%를 자동화한다. 충돌하거나 민감한 변경은 확인 대기로 표시하고, "무엇을 진실로 삼을지" 10%만 사람이 쥔다.
네 단계를 따라가 보세요. 마지막, 충돌 판단만 사람의 몫입니다.
어느 시스템에서 무엇이 바뀌었는지 잡아낸다.
그 값이 반영돼야 할 연결 시스템을 찾는다.
연결된 곳에 전파하고 충돌·불일치를 표시한다.
대부분 자동 반영된 상태에서, 충돌·민감 변경만 사람이 쥔다.
말로 하면 여기까지다. 이제 직접 눌러보세요. 아래는 데모 데이터로 만든 실제 동작 화면입니다.
한 곳의 변경이 연결된 시스템에 자동 반영됩니다. 두 곳이 충돌하는 변경은 지어내 덮지 않고 확인 대기로 남습니다.
같은 정보, 동기화 전과 동기화 후. 바뀐 건 데이터가 아니라, 하나의 진실을 지키는 능력이다.
연결된 반영은 이미 됐고, 충돌만 사람이 판단한다. 시스템마다 다른 값 대신, 어디를 봐도 같은 진실이 산다.
