운영 모델, 운영, 운영, ...

일 이야기입니다. 같은 말인데도, 워낙에 다르게 쓰는 경우들이 있습니다. 대체로 업무 중에 서로간의 이해가 매우 달라지는 경우가 대체로 이런 경우에 발생합니다. 문화의 문제가 아닌데도, 때로는 서로 다른 말을 하며 이해를 달리하다보니 충돌이나 보이지 않는 실망, 갈등이 생기게 됩니다.

 

이러한 커뮤니케이션 미스로 발생하는 사례를 보여주는 것이 이 만화인데, 애시당초 고객은 뒷마당 나무에 타이어 하나 걸어놓고 그네처럼 탈 수 있는 것을 원했던 것이죠. 하지만, 설명 과정에서, 이해하는 과정에서, 만드는 과정에서, 정리하는 과정에서 너무나 다른 결과로 만들어지곤 합니다.

 

같은 나라 말을 씀에도 그러한데, 글로벌 시대를 맞이하여, 단순 용어가 번역을 오가면서 더 여러가지의 뜻으로 이해되는 경우가 생깁니다. 최근에 회의를 하다가 서로간의 오해를 발견한 사례는 '운영' 또는 'Operation'이라는 단어입니다.

 

실제 운영 모델, 운영이라는 단어는 누가 일을 하느냐에 따라 너무 다른 뜻으로 이해됩니다.

* 운영 모델이라는 단어가 특히 그러합니다. 이는 비즈니스모델, 운영모델, 역량모델 등과 엮여서 혼란을 크게 일으킵니다. 아래의 설명은 각기 인터넷 검색에서 나온 문장들입니다.

  - 비즈니스 모델, 사업 모델은 사업 모형(事業模型) 또는 비즈니스 모델(business model)은 기업 업무, 제품 및 서비스의 전달 방법, 이윤을 창출하는 방법을 나타낸 모형이다. (참고)

  - 운영 모델은 사람들이 비즈니스 전략에 설명 된 높은 목표를 달성 하기 위해 함께 작동 하는 방식을 정의 합니다. 운영 모델은 종종 비즈니스 전략의 인력, 프로세스 및 기술으로 설명 됩니다. (참고)

  - 역량 모델(국문 설명) 역량들의 구조화된 집합으로, 조직 구성원들이 높은 성과를 창출하기 위해 필요한 역량을 체계적으로 분류하고 정의한 개념이다. (참고)

 

* 역량 모델과의 착각

그런데 실제로 우리 나라에서 프로젝트를 수행하며 통상 커뮤니케이션되는 운영 모델은, "Capability Model (위와 다른 의미의 역량 모델)이라는 명칭으로 해외 자료에서 검색됩니다. 비즈니스를 수행하기 위해, 각각의 구성 요소를 정의하고, 그에 따른 성숙도나 수준을 정의하여, 진단하고, 그 갭을 메우기 위한 과제를 도출하는 과정에 활용되는 것이죠. 이는 운영 프로세스라는 용어로 또 다른 오해를 불러 일으키며, 진짜 '프로세스'를 개선해야 할 프로젝트가 실제로는 '운영역량'을 개선하는 프로젝트로 진행되는 경우가 많습니다. 게다가 IT나 시스템을 운영하는 입장에서의 IT 운영 모델(ITOM)을 이해하시는 분들에게는 시스템을 운영하기 위해 정의되는 각종 업무 요소들로 이해되기도 합니다. 

 

* 일반 운영 업무, 또는 Daily Operation

시스템이나, 비즈니스 프로세스에 대한 개선이 끝나면, 운영 업무를 논의하게 되는데, 구축이나 전략 수립 이후에, 루틴화된 업무를 진행하는 것을 Daily Operation, 운영 업무 이라고도 부릅니다. "통상 업무"로 불러야 할 것이 "Operation"으로 불리게 되는 것이죠. "마케팅 오퍼레이션"과 같은 용어들이 여기서 비롯합니다.

 

IT 시스템 구축이 끝난 이후, IT 서비스 등을 통해서 해당 시스템 작동이 문제 없이 원활하게 유지되도록 관리되는 것을 운영이라고도 부르고요. 또는 특정 비즈니스 기능의 아웃소싱되는 항목에 대해, 운영 관리 업무라고 부르는 경우도 있습니다. 이를 후자들의 경우, Managed Service라고 표현하는 것이 맞을 것 같아 보입니다.

 

* Sales & Operation

한국에서는 예전에 생산/판매 연계라는 말로 쓰였습니다. 따라서, Sales & Production이라고 해야하겠으나, 물류 관리, 영업 관리 등을 포함해서, 비즈니스의 주요 Function이 기능하는 방식을 operation이라고 정의할 수도 있겠습니다. 통상적으로 이런 용례의 Operation은 생산, 물류, 영업, 창고관리 등을 통칭해서 부르곤 합니다. 

 

이런 류의 오류는 우리의 문서나 용어를 영어로 번역하고, 이후에는 해당 문서를 역 참조하여 다시 국문으로 번역하는 과정 등에서 비롯하는 것으로 보입니다. 업무상 발견하게 된 주된 오류의 포인트에는 이런 것들이 있었습니다.

한국어 용어	보통 번역하는 용어	문제/주요 분석	권장 용어
OO 체계 수립	System Establishment	정말 시스템 개발을 하는 것이 아니면, 시스템이라는 영어 단어는 쓰지 않는 것이 좋습니다.   마찬가지로 "체계적" 이라는 말 역시  "Structured" 정도의 표현이 좋습니다.   '수립'이라고 하지만, 알고 보면,  방안을 짠다든가, 프로세스를 만든다든가 하는 것이 실무입니다.	.... Structure Development
OO 방향성 수립	Direction	영미권 타국 장표에서  잘  안쓰이는 표현입니다. Direction은 지시를 하는 부분이기 때문에, 일단 맞지 않고, 컨텍스트에 따라 여러가지 단어를 선택해야 합니다.	프로젝트의 추진 방향성 --> 목표가 있는 것이므로, Implementation Strategy, Project Strategy "본사의 전략적 방향성을 따라.." --> 본사와 전략적으로 Align 하는 것으로 재해석 개선 방향성 --> Implication for Improvement
구축, 구현	Implementation/ Construction	Construction은 쓰지 않습니다. 건설 현장에서 쓰는 표현입니다.	시스템 구축을 의미할 때는 Build 프로세스를 비롯하여, 무언가 없던 것을 생기게 할 때.. Implementation (새로운 프로세스 포함)
강화(하다)	Strengthen, Reinforce	상황별로 좀 볼 필요가  있습니다. "힘(Power)을 주어" 조직 등에서 뭔가 "Strong"하게 만드는 것이 아니라면, 보통의 경우, "프로세스 강화", "역량 강화" 등의 표현은 "고도화"의 의미를 지닌 Enhance가 더 적절합니다.	Enhance

한국어를 영어로 번역할 때, 또는 영어를 한국어로 번역할 때, '정확하게 이것이 무엇을 의미하는 것인지' 생각하는 것이  그래서 중요합니다. 그렇지 않으면 대부분 복붙하는 장표에 지나지 않습니다. 예전에는 이런 부분에 대해서 상세하게 하나하나 짚느라 밤을 새는 일도 잦았죠. 실전에서 대략 말로 넘어갈 때가 많고 해서, 급할 때엔 세세하게 잘 안보게 됩니다.  그런데, 문제는 이 용어 때문에 발생하는 국가간, 또는 내부간 커뮤니케이션에서의 이슈가 심각하게 많습니다. 일전엔 현업이 무심코 던진 "구축" 한 마디에 여럿이 날밤을 새야 하는 상황이 발생합니다.

 

누구의 말이 맞다 틀리다라는 입장에서 접근하지는 않았으면 좋겠습니다. 각자 자기의 업무에서 써오던 용례가 있기 때문이죠. 하지만, 자기가 하는 말이 절대적으로 옳을 수도 없기 때문에, 상대와 함께 "정확히 원해야 하는 바"가 무엇인지 서로 설명하고 이해하려는 자세가 필요합니다. 이 과정이 상당히 고통스럽습니다. 정말 우리도 모르는 새에 "바벨탑" 공사장으로 끌려온 기분이죠. 하지만, 이 과정을 거치지 못하면, 탑은 커녕 집 한 채도 짓기 어려울 것 입니다.