53. 시스템 설계의 이해
시스템엔지니어링, 경영과학, Operations, 시스템설계
0. 시작하기전에
이 글은 페친에서 언급된 주제에 대해서 다시 한번 정리 하고자 이렇게 글로 남긴다. 우선, 이 글의 소재가 된 페친분의 질문을 소개 한다.
[질문]
"데이터 기반의 의사결정을 위해서는 산재 되어있는 데이터 통합이 이루어져야 하고 이를 위해서는 표준코드, 기준정보관리가 선행되어야 합니다. 그런데 새로하는게 아니라 기존에 이미 산재되어있는 기준과 코드를 표준화 하는게 여간 어렵지가 않은데요, 어떻게 접근하는 것이 좋을까요?"
이 질문은 얼핏 보면, 데이터기반의 (인사/HR) 의사결정을 위한 기준 설정과 코드 표준화에 대한 이야기 인듯 하지만, 사실상 의사 결정 시스템설계에 관한 이야기이다. 오늘은 그에 대한 이야기를 나누고자 한다.
1. 시스템 (System) 이야기
시스템이라는 것이 사실은 굉장히 광대한 의미로 사용 된다. IT에서의 PC나 서버등을 시스템으로 칭하기도 하고, 자동차에서 엔진같과 같은 요소(component)도 시스템이라고 칭한다. 혹은 의학에서는 신체의 장기들을 시스템이라고 칭한다. 그리고, 이러한 시스템이 경영으로 넘어오게 되면, ERP(Enterpise)나 POS(Point of Sales), Supply Chain System같은 비지니스 요소들을 시스템으로 부르기도 한다. 이처럼 시스템이라는 다양한 의미로 다양한 각도로 사용이 된다. 그래서, 어느 분야에서 어떤 이들이 바라 보느냐에 따라 그 이해하는 정도와 그 의미가 달라진다.
비지니스/경영에서는 시스템은 경영정보시스템(MIS: Management Information System)와 연결이 깊다. 즉, 경영에 사용되는 서버/PC등이 시스템에 해당 된다. 사실, 경영관점에서의 시스템은 ERP나 Supply Chain같이 회사의 캐쉬플로우와 직접적적으로 관련이 있는 시스템들도 있지만, 특정 직군이나 특정 데이터를 위한 시스템들도 존재 한다. 예전에 다녔던 S사를 예를 들어보자. 우선, 전사 개발자들이 사용하는 특허시스템이 있다. 회사의 모든 이들이 사용하는 HR관리 시스템, 해외출장 시스템, 온라인 강의 시스템 등등 수도 없는 시스템들이 존재 한다. 이러한 시스템들의 존재는 회사가 크면 클 수록 더욱더 복잡하고 더욱더 다양해지는 경향이 있다.
여기서 중요한 것 한가지는 시스템이라는 것이 특정 기능을 하는 서버/PC가 아닌, 회사의 경영을 하는 특정 기능을 수행하기 위한 일련의 활동을 의미하기도 한다. 예를 들어, 어떤 의사결정을 위한 시스템이라고 할 때, 상관의 결재 과정을 포함하게 되는데, 이러한 의사 결정을 한다고 했을 때, 결재 시스템을 통해서 디지털화 되어 서버상에서 전자 결재를 통한 시스템이 될 수도 있지만, 굳이 디지털방식이 아니더라도 결재서류를 작성하고, 결재서류를 의사결정자들을 직접 찾아가서 결재를 받고, 이렇게 결재가 완료되는 기안이 실행 되는 일련의 활동 자체가 "시스템"이 되기도 한다. 그리고, 이러한 시스템에는 특정 활동을 완료하기 위한 일련의 절차가 존재하는데, 이러한 일련의 절차를 프로세스(Process)라고 한다.
2. 프로세스(Process) 이야기
프로세스(Process)를 굳이 한글로 쓰자면 "절차" 혹은 "절차묶음"을 의미한다. 그리고, 이러한 프로세스의 또 다른 이름이 바로 오퍼레이션(Operations)인데, 실제로 이 두 단어는 거의 같은 의미로 사용되기도 한다. 어떤 문제를 해결 하거나, 목표를 위한 일련의 활동이 원하는 결과를 내기 위해서는 이를 실행하는 일련의 절차들이 목적에 맞게 배열이 되어야 하는데, 이러한 배열 작업이 바로 프로세스 설계(Process Design)라고 한다. 많은 이들이 프로세스 설계와 시스템 설계(System Design)를 같은 걸로 생각하거나, 혼용해서 사용하는데, 이 둘은 엄연히 다른 개념이다.
자동차(오토 기준)에 시동을 거는 상황을 예를 들어보자. 자동차에 시동을 걸기 위한 일련의 잘차는
1. 운전석에 앉아서,
2. 브레이크 패달를 잡고,
3. 기어는 P로 놓은 상태에서
4. 키를 꼽고,
5. 스타트 버튼을 누른다.
와 같이 된다. 이러한 일련의 절차들을 실행하게 위해서는 운전자, 운전석, 브레이크, 기어, 키, 스타트버튼같은 요소들(components)이 어떠한 관계를 맺으며 연결 되어 있다. 여기서 위에 언급된 일련의 절차를 설정하는 것이 프로세스 설계에 해당하고, 절차실행에 있어 필요한 요소들을 목적에 맞게 묘사하여, 해당 시스템에 대한 설계도를 만드는 작업을 하는 것이 바로 시스템 설계이다.
3. 프로세스를 다루는 학문
한국에서 프로세스나 (일반적인) 시스템을 다루는 학문 분야는 무척 생소 하다. 그도 그럴 듯이, 이러한 프로세스 자체를 다루는 것을 일반화 하기도 어려울 뿐더러, 대부분 프로세스는 해당 분야에 숨겨진 경우가 많기 때문이다. 그래서, 한국에서 프로세스를 다루는 과는 산업공학과에서 오포레이션리서치(Operations Research), 경영학과에서는 경영과학(Management Sciences)정도가 통상적인 프로세스를 다루고, 전자공학과에서 시스템 제어, 화학공학에서 화학공정과 같은 특정한 시스템에 대한 프로세스를 다루는 경우가 전부이다. 하지만, 미국같은 경우는 1990년에 이미 프로세스/시스템을 다루는 학문 분야가 별도의 전공으로 대우를 받았었다. 시스템과 프로세스 자체를 다루는 학문 분야는:
자연과학에서는 Operations Research
공학에서는 Systems Engineering
경영학에서는 Operations Management
라는 이름으로 별도의 학과들이 존재 한다. 아래의 링크는 Ph.D Program을 제공하는 일개(?) 미국 대학교의 링크 이다.
https://orc.mit.edu/academics/phd-operations-research
얼핏 보기에는 다 같은 프로세스 설계/분석(Process/Operation)을 다루는 학문 분야이긴 하지만, 그 이름에 따라 관점이 차이가 존재한다. 이러한 차이가 학문적 방향성을 결정하지만, 실제로 이 학문 분야가 제대로 쓰이기 위해서는 어느 위치에 있던 모든 관점을 다 이해하고 있어야 한다.
전산학과(Computer Sciences)나 컴퓨터 관련 프로그래밍을 하다보면, 코딩을 하는데 코딩을 배우다 보면 한번 즈음 플로우 차트(Flow Chart 혹은 순서도)라는 것을 들어 봤을 것이다. 혹자는 알고리즘(Algorithm)과 플로우차트를 같은 것으로 보는데, 이 둘은 엄밀히 다른 개념이다 (이에 대해서 궁금하다면 댓글을 남겨주길 바란다). 프로세스(분석)과 순서도 모두 어떤 실행을 위한 순서를 나열 한다는 면에서 동일 하지만, 그 목적이 다른데 프로세스 분석(Process Analysis)은 단순히 순서를 나열하는 프로우차트와는 달리, 만들어진 순서의 성능(Performance)을 다루게 된다. 특히, 경영/비니지스에서의 프로세스(Process 혹은 Operation)에서는 이러한 성능 지표를 DCQ라고 한다. 이러한
Delivery time (시간);
Cost (비용);
Quality (품질);
는 Operations Management에서 프로세스를 분석 할 때, 가장 근간에 되는 성능 지표이며, 어떠한 성능지표를 다루느냐에 따라 그 그림이 달라진다.
4. 프로세스 & 시스템
좀더 실질적인 이야기를 해보자. 예를 들어, 프린트센터(일명 복사집)에서 작업을 하는 과정을 생각해보자. 이 복사집은 단순히 프린트 물만 출력하는 것이 아니라, 광고전단지라든지, 담배포장지등도 같이 출력을 하는 곳이다. 이러한 대량 출력을 Package Printing이라고 하는데, 이런 Package Printing의 프로세스는 다음과 같이 설계 할 수 있다.
Packgage Printing Process이러한 프로세스가 만들어지면, 이 프로세스를 경영의 관점(Operations Management)의 관점에서 다음과 같은 질문들을 해볼 수 있을 것이다.
현재의 프로세스는 잘 통제되고 있는가?
주문이 폭발하는 기간(성수기; Peak Season)에는 어떻게 주문을 처리 할 것인가?
현재의 프로세스를 어떻게 하면 향상 시킬 수 있을 것인가?
자동화된 Die-cut machine을 사용한다면, 현재의 프로세스는 향상될 수 있나?
향상 된다면 얼마나 향상 될 수 있나 (혹은 몇 대의 auto die-cut machine이 필요한가)?
물론, 이러한 내용들은 Operations Management 과목에서 가장 처음 배우는 Process Analysis에 관련한 내용이고, 자세하게 다룰려면 한학기 분량이기에 세부적인 내용은 건너뛰도록 하겠다. 재미 있는 것은 이러한 문제를 과학적(Scientific)으로 해결하는 방법이 있고, 공학적(Engineering)적으로 해결하는 방법도 있고, 경영적(Managerial)으로 해결하는 방법 모두가 존재 한다는 점이다. 각설하고, 최적화 된 프로세스는:
. 4대의 Die-cut 기계가 필요하며,
. Color-MIx + Offest Printing은 하나만 있으면 되고,
. 성수기 때는 5명의 인력을 Finishing Touch에 충원해야 한다.
그리고, 다음과 같은 개선된 형태의 프로세스 설계가 가능해 진다.
Improved Process물론, 위의 설계가 유일한 답은 아니면, 상황이나 조건(수요, 각 요소별 용량 등등)에 따라 다영한 개선 프로세스가 만들어질 수 있다. (혹시라도, 위의 예제 자체가 궁금한 독자들은 위의 내용을 다루었던 참고 문허을 남겨 놓을 테니 참고 하기 바란다.
Kim, S.-K. and Candelaria, D., "The Case for Operational Management: Millennium Printing Press Company", International Journal of Teaching and Case Studies 5:3-4 (2014), pp 265-275.
https://www.inderscienceonline.com/doi/abs/10.1504/IJTCS.2014.067807
그리고, 이러한 프로세스는 단순히 위와 같은 경영 절차에 대한 것 뿐만 아니라, 공학에서의 h/w나 s/w를 설계하는데도 중요한 역활을 하게 되는데, 현재 돌아가는 상황을 프로세스화 해서 묘사할 수 있으면, 그에 대한 개선 방향 또한 쉽게 파악이 가능해 진다.
스마트폰을 설계 하던, AI시스템을 설계 하던, 의사결정시스템을 설계하던, 회사의 결재시스템을 설계하던, 어떤 순서의 모음이 필요한 모든 영역에서 프로세스 및 시스템 설계가 바르게 되었을 때는 Process/Operation에서 통상적으로 관통하는 개념(버틀냇, 버든, 회수율, 효율 등등)들과 분석방법론을 그대로 가져와서 적용이 가능하다. 그리고, 이러한 Operations의 개념과 도구들에 대한 이해는 기존의 프로세스/시스템이 아닌, 새로운 프로세스/시스템 설계시에 보다 빛을 바란다. 우리가 미디어에서 한번즈음 들어봤을 식스시그마(6-Sigma)라든지, 린(Lean)이랄지, TPS(Toyota Production System)같은 것들도 그 원류는 프로세스 최적화 향상에 있으며, 그 중에 제품 생산에 특화된 프로세스를 다루는 분야이다. 생산 시스템설계에 대한 내용은 이전에 필자가 적었던 브런치의 글이 있으니, 참고 하기 바란다.
https://brunch.co.kr/@amangkim/95
5. 시스템/프로세스 설계 적용 -- 포인트 레슨
사실, 새로운 시스템 개발이나 도입을 위한 시스템/프로세스 설계는 그 기본적인 내용이 방대할 뿐만 아니라, 케바케인 경우가 많아서 시스템을 적용하고자 하는 해당 분야의 실무를 모르면, 바르게 설계할 수가 없다. 그리고, 더 중요한 것은 아무리 프로세스와 시스템이 제대로 설계되었다고 하더라도, 이를 실무에 적용하는 것은 또 다른 문제 이다. 특히, 기계나 기술 시스템이 아닌, 경영 시스템(ERP, SCM, e-Commence)의 적용에 있어서는 이러한 적용의 문제가 시스템 자체의 분석/설계보다 큰 비중을 차지 하기도 한다.
이러한 관점에 대한 내용을 원래 질문에 언급 되었던 의사결정 시스템의 도입을 기준으로 정리 해볼까 한다.
하나.
데이터 해석에 대한 내용은 차치 하더라도, 결국 담당자가 해당 시스템을 사용(앞으로 쌓일 데이터의 입력 및 담당자/회사 원하는 분석)함에도 추가적인 워크로드나 부담을 느끼지 않도록 설계해야 한다. 위에 언급 했듯이, 최적화 된 시스템과 분석기법이 준비가 되어 있다고 하더라도, 이후 해당 시스템을 사용하는 담당자들이 사용하는데 부담을 느끼거나, 실질적인 데이터가 축적되지 않는다면, 해당 시스템은 무용지물이 되고 만다.
둘.
보통 새로운 의사결정 시스템을 도입할 때, 흔히들 Top-to-bottom 형식으로 사장의 의지에 의해 도입하는 경우가 허다하다. 이 경우 가장 처음 지시 사항이 아마도, 해당 시스템의 적용사례 연구, 즉 벤치마킹이다. 어떤 (상용) 시스템들이 시장에 존재하는지, 실질적인 적용사례는 어떤지 등등. 하지만, 이러한 벤치마킹은 무용지물이라고 보면 된다. 가장 큰 이유는 이러한 방식의 시스템 도입은 다른 회사에서는 동작하지 몰라도 본사에는 "맞지 않는 옷"일 가능성이 높다는 점이다. 회사가 어떤 식으로든지 매출을 내고 돌아간다는 의미는 어떤 형태로든지 회사경영에 필요한 일련의 프로세스와 그 프로세스를 담당하고 있는 담당자들이 존재한다는 거다. 이런 상태에서 특정 프로세스 향상(자동화, 최적화도 같은 의미임)을 위해 시스템을 도입할 때, 기존의 프로세스와 담당자의 workload를 고려하지 않은채로 타사의 적용 방식으로 시스템을 도입할 경우, 이 시스템은 프로세스/담당자와 동 떨어져 버리게 된다.
셋.
벤치마크가 무용지물인 또 한가지 이유는 내부인이 아닌 이상, 타사의 실제 도입효과를 확인하는게 불가능하다는 점이다. 그리고, 결정적으로 성공사례만 있지, 실패사례는 구하는 것자체가 불가능 하다. 타회사의 벤치마킹 정보는 실제 밴치마킹 용이라기보다는 해당 시스템을 팔기 위한 마케팅 자료라고 보는게 보다 타당 할 것이다.
넷.
위에도 잠시 언급 했듯이, 회사가 이미 돌아가고 있다면, 필요한 일련의 활동에 대해서는 담당자와 프로세스(절차의 묶음)가 존재한다. 그리고, 회사의 확장등과 같은 사유로 인해 시스템을 도입하는 방향으로 진행된다. 여기서 중요한 것은 이러한 활동을 위해 사람, 프로세스와 시스템의 발전 순서이다. 의사결정 시스템의 경우도, 가장 먼저 필요한 것은 결정을 하는 사람(즉, 결재권자)이다. 회사작고, 종업원이 얼마 없다면, 사장이 직접 기안을 보고 결재를 하면 된다. 이 또한 기안 → 최종결재 와 같은 간단하긴 하지만, 프로세스를 가지게 된다. 사람이 많아지고, 부서가 많아지면, 이러한 의사결정 라인은 기안 → 부서장결재 → 사장결재와 같은 프로세스를 가지게 되고, 결재된 (물리적으로 서명이 된) 문서가 생성되고, 이러한 문서를 보관할 사물함, 즉, 시스템이 필요하게 되는 식이다. 이후엔 이러한 물리적인 결재 방식이 전자식으로 바뀌고, 이러한 결재 데이터를 보관할 서버라는 시스텡을 도입하게 된다. 즉, 어떤 경영활동이건 이 순서 즉,
사람 → 프로세스 → 시스템
는 절대 변하지 않는다. 그래서, 만약 기존의 프로세스와 확연히 다른 시스템을 도입하고자 할 떄 중요한 것은 해당 프로세스 담당자들이 새로 도입된 시스템을 얼마나 내제화(일상화)되어 있느냐 이다. 즉, 담당자들이 도입된 시스템을 사용하는 일련의 프로세스(새로운 자료를 입력하고, 원하는 지표를 찾아내고, 분석하고, 이를 기반으로 의시결정을 하는 일련의 과정)에 얼마나 빠르게 익숙하고, 편하게 만드냐가 시스템 설계만큼 중요한 요소가 된다. 그리고, 여기서 중요한 것, 제대로된 시스템은 체계화 된 프로세스 위에서만 가능하다. 만약, 체계화된 프로세스가 존재하거나, 기존의 프로세스가 효율적이지 않다면, 해당 프로세스에 대한 개선이 우선이다. 새로운 시스템의 도움은 그 다음 문제가 된다.
프로세스 설계에는 내재화의 과정이 필수이다. 이러한 내재화의 과정은 생각보다 오래 걸린다. 내재화를 한다는 의미는 해당 프로세스를 담당하는 모든 담당자들이 해당 프로세스에 대한 충분한 이해를 하고 있다는 의미이기 때문이다.
다섯.
네번째 레슨과 연관이 있는데, 새로운 시스템 도입시 대부분의 리더들이 하는 가장 큰 실수가 시스템 설계와 프로세스 설계를 동시에 하려 한다는 점이다. 그게 아니면, 시스템을 우선 도입한 후에 관련 프로세스를 만드는 방식을 취하는데, 그렇게 해서는 절대로 해당 시스템 도입이 성공 할 수가 없다. 다시 한번 말하지만, 순서는 사람→ 프로세스 →시스템이다. 이 순서는 뒤바뀌어서도 안되고, 건너 뛰어서도 안된다. 그리고, 이 순서는 중요도와도 일치 하는데, 가장 중요한게 사람, 그 다음이 프로세스, 그 다음이 시스템이다. 시스템이 없어도 프로세스가 체계화 되어 있으면 해당 활동은 원활하게 돌아가고, 프로세스가 없어도 담당자가 신(?)이면, 해당활동이 잘 돌아간다.
여섯.
사람(담당자)가 중요하지만, 가장 큰 위험요소이기도 하다. 예를 들어, 특정 활동을 담당하는 사람이 한명 뿐이고, 그 활동(혹은 업무)을 정확하게 알고 있는 사람이 그 사람 뿐이라고 해보자. 만약, 그 사람이 병가를 내거나, 심지어 퇴사를 하게 될 경우 어떻게 될 것인가? 해당 업무는 마비가 될 것이다. 그렇기에 프로세스적인 적 측면에서는 체계화(여기에는 문서화도 포함)가 필요하고 전자(결재)시스템등이 필요한 것이다.
일곱.
각 회사에 맞는 내제화 된 프로세스가 만들어지면, 시스템 도입을 위해 어떤 데이터들을 디지털화 할지와 이후 데이터 관리를 어느 수준으로 할지가 정해진다. 어떤 의사결정을 할 때 필요한 요소와 자료는 해당 분야와 회사위치에 따라 천차 만별이다. 그래서, 가장 중요한 것은 다른 사람(타사)이 뭘 하는지를 보는게 아니라, 내가 필요한 것이 무엇인지 아는 것이다. "니꼬라지를 알라"는 소크라테스의 명언은 여기에서도 유용하다.
여덟.
데이터기반 의사결정 시스템의 "실질적인 도입"에서 정작 중요한건 "데이타 기반의 의사결정"이 아니라 "시스템"이다. 아무리 뛰어난 의사결정 이론과 데이터가 존재 한다 하더라도 시스템(설계)에 대한 이해가 없다면, 실제로 도움이 되는 시스템의 도입은 불가능하다.
오늘은 글을 이 정도에서 마무리 해야겠다.
[끝]
