brunch

데이터 게더링(Data Gathering)

시스템은 아무리 잘 구성을 해 두어도 혼자서는 아무것도 하지 못한다. 2025년을 살아가는 우리는 이렇게 이야기할지도 모른다. AI는 개떡같이 말해도 찰떡같이 이해하더라. 그렇지만 2004년의 제조 회사는 그렇지 못했으니 시스템 구축과 동시에 고민해야 하는 건 데이터를 모으는 것이다. H반도체는 가공팀과 조립팀으로 크게 나뉜다. 가공 장비에는 자동화 장비도 있고 그렇지 못한 매뉴얼 장비도 있다. 물론 중간 검사 작업과 조립 작업은 100% 수작업으로 이루어 진다.


요즘에는 어렵다고 생각하지만, 2005년 무렵에는 P본부의 컨설턴트와 함께 S전기를 방문, 데이터를 모으는 방법을 벤치마킹 할 수 있는 좋은 기회가 주어졌다. S전기의 현장에 직접 들어가서 데이터를 어떻게 집계하는지 확인하고, 똑같이 구현할 수는 없겠지만, 중소 기업에서 어떻게 받아들여야 할지, 그리고 구축된 ERP와는 어떻게 연동하는 것이 좋을지?

이제 생산관리팀 스케줄링 담당자는 바코드(Bar Code)를 이용한 프로그램 개발을 고민해야 하는 것이다.


우선 선택한 방법은 정보전략팀 담당자와 업무 미팅을 진행해 보기로 했다. 이 당시 장비회사에서의

풀 수 없는 문제는 “동일한 고객사에 입고되는 2대 이상의 장비의 기초 정보가 다를 수 있다. _ 난제(難題) I” 이다. 이 어려운 문제를 한낱 신입에 가까운 사원이 한번에 해결하기는 어려운 문제였고, 그래서 담당자와의

업무 미팅을 수차례 하면서 찾아낸 방법은 ‘Master Data의 상속’ 이다. 참고로 말하면 이 방법을 네 군데 장비 회사에서 적용을 시도했지만 정보전략팀에서 반영해준 경우는 H반도체가 유일했다.


사실 나는 지금도 ‘Master Data의 상속’이 얼마나 어려운 개발 인지는 알지 못한다. Concept만을 제안하고

제안 사항의 개발을 진행해 주는 것은 정보전략팀의 일이다 보니 프로그램의 개발 난이도를 정확히 알지는 못한다. 지금 와서 생각해 보면 반대했던 사람들도 그 개발 사항이 그만큼 어려웠을 수도 있다. 그렇지 않다면

또다른 이유라고 생각 할 수 있는 것은 H반도체 외에 SY테크, T사, IP사 모두 설계팀이 너무나 작은 단위 조직으로 나누어서 일하다 보니, 업무 방식의 차이를 극복할 수 없는 문제가 있지 않았나 하는 생각이 든다.

-----------------------------------------------------------------------------------------

* AI(Artificial Intelligence): 지능적인 행동을 모방하고, 학습 및 문제 해결을 수행할 수 있는 컴퓨터 시스템 또는 기계를 만드는 과학과 기술 [영어사전]

* Bar Code: 이름 그대로 막대기(Bar)로 된 부호(code)로서 컴퓨터가 판독할 수 있도록 고안된 굵기가 다른 흑백 막대로 조합시켜 만든 코드다. 일반적으로 제품 포장지에 막대와 그 아래의 숫자로 이루어진 표시 방식이 바로 바코드다. 1949년 개발되었다. [나무위키]


그런데 말이다, ‘Master Data의 상속’이라는 것은 단순하게, 도면 정보로만 끝나지 않는다.

결코 적용을 반대했던 회사들의 개발팀에 대한 이야기가 아니다. 이러한 4개사의 연간 영업이익율을 조사해보면 그 차이를 더 잘 알 수 있다는 것이다.


제조회사에서 데이터란 사람에게는 피와도 같다. 물론 현금의 흐름도 좋아야 하지만 기업 내부에서의 데이터 흐름이 원활해야 개선이 필요한 사항을 찾을 수 있다. 그리고 개선 후에도 계속적인 모니터링이 가능하게 되는 것이다.


H반도체에서 생산, 제조 부분의 데이터를 모아서 사용한 방법을 자세하게 표현할 수는 없다. 물론 자세하게

표현한다고 해도 다른 장비 회사에서 사용하기도 힘든 방법이라고 생각한다. 다른 장비회사의 경우 설계, 제조만 하는 것이 대부분 이어서, 도면의 마스터 데이터(Master Data) 관리 문제를 포함해서, 가공품 구매 및 품질검사에서도 업무 범위의 차이가 크다. 결정적으로는 도면관리시스템(ABC-rev1)에서의 리비전과 물류관리 시스템(ABCrev1)에서의 리비전 처리가 상이하다는 것을 시스템의 운영 차이에서도 반영하지 않고 있다.


위와 같은 데이터의 처리에서 발생한 차이는 외주 가공품의 발주 및 입고에서 큰 차이를 보여 주었다. 이 차이는 상용품에서 보다는 가공품에서 큰 차이가 발생한다. H반도체는 사내 가공 시간과 외주 가공 발주 시간이 같다. 같다는 정보는 도면에서 확인할 수 있다. 그렇다면 다른 회사에서는 어땠을까? 조금 아쉽지만 데이터를 비교할 수 있도록 관리하지 못한다. 그렇다면 개선할 수 없는 문제인가? 그렇지는 않다.


너무 깊이 들어가기 전에 다시 돌아와서 쌓인 데이터를 어떻게 활용했을까? 가장 작은 단위로 설비별로 가지고 있는 일의 양의 평가할 수 있다. 다시 말해서 내부에서 처리할지 그렇지 않다면, 외부 자원을 추가로 이용해야 할지를 정량적으로 평가할 수 있다는 것이다. 이것은 내부 자원의 사용율을 최대치에 가깝게 올릴 수 있다는 의미이다. 이러한 평가 기준을 가지고 있지 못한 제조 회사라면 절 때 주주에게 이익을 나누어 줄 수 없다고 생각한다. 아쉽지만 H반도체를 제외하고 SY테크, T사, IP사 모두 평가 기준은 가지고 있지 못했던 것으로 기억한다.



-----------------------------------------------------------------------------------------

* 리비전(Revision): 출도 한 이후에도 수정부위가 계속 생기는데, 자의든 타의든 이미 출도가 된

도면을 수정하면 도면을 보는 모두가 수정이 되었다는 걸 알 수 있게 Revision 을 표기 해야 한다.

* 구매품: 일반적으로 외부에서 사오는 물품, 일반적으로 Revision이 없음

* 가공품: 도면에 따라 직접 가공하여 만드는 물품, 일반적으로 Revision이 있음

keyword
이전 07화기적(Miracle)