IT Life

프로세스 혁신을 성공시키기 위한 조건

2019.05.31 09:30

 

가끔 저의 글을 열심히 보시는 분들을 만날 때가 있는데요. 그분들께서 한결같이 하시는 말씀이 “누구나 전략 기획 고수가 될 수 있다” 연재 글을 통해 공부하신다는 겁니다. 제 글을 꾸준히 읽으신 분들은 아시겠지만, 나름대로 전략 기획자, 컨설턴트(Consultant), 사업 개발(Business Development) 직군을 가지신 분들에게 공통으로 필요한 ‘논리적 사고’, ‘문제 해결 역량’, ‘커뮤니케이션 역량(문서 작성 기법)’ 등을 그동안 연재했습니다.


특수 직군을 가지신 분들의 ‘공통 역량’이라고 하지만, 실제 직장을 다니시는 대부분의 분이 가져야 하는 ‘공통 역량’이라고 해도 과언이 아닐 정도로 기업에서 어떤 포지션이든 성과를 내기 위한 기본적인 역량과 스킬에 관해 이야기했던 것 같습니다. 그래서, 이제 반걸음 더 나아가서 실제 기업 내에서 최근에 빈번하게 진행되는 혁신 Task(과제)를 실행하려고 할 때 필요한 실질적인 역량과 내용을 이야기해 보려고 합니다.



이제는 4차 산업혁명 시대가 언제부터 시작되었는지가 중요하지 않은 시점이 되었습니다. 이제 얼마나 빠르게 그 시대에서 생존하기 위해 변화하고 있는지가 중요한 시점입니다. 아마도 수많은 기업의 경영진들은 이에 대한 고민에 빠져 있을 것이고, 본인들의 생각과 다르게 변화되지 않거나 성과가 나지 않는 현실에 직면해 있을 것입니다.


제가 회사 입사한 시절만 해도 기업의 혁신은 대부분이 “비즈니스 프로세스 혁신”에 기반을 두고 있었습니다. 그리고, 시간이 흘러 프로세스 중에서 수작업을 얼마나 어떻게 시스템화할 수 있는지가 관건이었습니다. 여기서 한 걸음 더 나아간 수준이 “이를 어떻게 자동화(Automation) 할 것이냐?”였습니다.


예를 들면, 종이에 작성하던 것을 시스템 화면에 입력하게 한다든지, 엑셀로 피봇(Pivot)을 한다든지, 다양한 함수를 사용해서 요약 보고서를 만드는 것을 시스템에서 자동으로 보고서(Report)를 만들어 주는 정도의 수준이었습니다.


지금은 AI, 빅데이터, IoT, 블록체인, Cloud, RPA 등 많은 신기술을 활용해서 어떻게 프로세스를 혁신할 수 있는지가 기본이 되어 버렸습니다. 즉, 단순한 자동화가 아닌 사람의 고민을 덜어주는 역할이나 심지어 사람을 대체하는 영역까지 확대되었습니다.


또는 과거에는 현실적으로 불가능했던 상상의 일들이 네트워크 기술과 센서의 발달로 가능하게 된 부분도 많습니다. 이런 시대적 변화에 맞춰 컨설팅 방법론도 자연스럽게 변화되고 통합되어 가게 되었습니다. 물론, 컨설턴트뿐 아니라 대부분 직장인의 공통 역량도 자연스럽게 IT 신기술에 대한 이해를 수용하는 방향으로 바뀌어 가고 있습니다.



과거에 전통적인 경영 혁신 컨설팅인 “PI(Process Innovation)”, “BRP(Business Process Reengineering) ”, “ISP(Information Strategy Planning)” 등이 따로 시행되기보다는 이제 하나의 컨설팅 프로젝트(또는 과제)로 합쳐져 진행됩니다. 즉, 프로세스 혁신과 시스템(정보화) 혁신은 이제 서로 떼려야 뗄 수 없는 관계가 되어 버렸습니다.


그러나, 이번 편에서는 이러한 컨설팅 이론에 대한 부분을 상세하게 다루기보다는 실제로 Task(또는 프로젝트)를 수행하면서 이를 성공시키기 위한 조건을 먼저 이야기하고자 합니다. 그중에서도 현대의 경영 혁신 컨설팅의 핵심이라 할 수 있는 “프로세스 혁신”과 “시스템 혁신”의 두 축 가운데 “프로세스 혁신”을 성공시키기 위한 조건에 관해 이야기하겠습니다. 경영 혁신 컨설팅의 기본 이론과 방법론에 대해서는 다음 편에서 다루도록 하겠습니다.


 (1) “AS-IS 프로세스” 분석에 충실하라.


이 내용은 특별할 게 없는 아주 기본적인 개념인데요. 과거에 제가 작성했던 13편~17편까지의 “문제 해결 프로세스”나 “34편 백종원의 골목식당 속의 디자인 씽킹”을 생각해 보시면 아주 이해하기 쉬울 겁니다.



정확히 문제를 인지하기 위해서는 현재 상황을 정확히 파악하는 것이 중요합니다. 간혹 보면, To-Be를 정의하는 것이 결국 과제(또는 프로젝트)의 목표이기 때문에 AS-IS를 적당히 하려는 경향이 있습니다. 또는, 해당 과제에 참여한 인원들이 AS-IS를 이미 잘 안다고 착각하는 경우가 있습니다.


그러나, 현행 파악을 하는 것은 옷의 첫 단추를 잠그는 것과 같습니다. 첫 단추가 잘못되면, 그 이후는 전부 다 잘못될 수밖에 없는 것입니다. 그래서, 가능한 한 충실하게 분석하는 것이 중요합니다.


 (2) “충분한 자원”을 투입해야 한다. 특히, “현업”


경영 혁신, 프로세스 혁신 등의 과제(또는 프로젝트)를 진행할 경우 대부분의 회사가 충분한 자원을 투입하지 못하는 경우가 허다합니다. 특히, 현업 인력이 특히 심한데요. 최근의 이러한 과제들은 상당 부분 각 기업의 IT 부서에서 과제를 주도하는 경우가 많습니다. 이렇다 보니, 현업들은 자신들의 과제가 아니라고 생각하거나, 현업 조직의 리더들이 인력을 해당 과제에 보내는 것을 꺼리는 경우가 많습니다.


어찌 되었든 현업들은 각자 조직의 목표를 가지고 움직이는데 이런 과제에서는 우수한 인력을 차출하려는 경향이 강해 자신들의 목표 달성에 차질을 빚거나 어려움을 겪을 것을 우려하기 때문입니다. 이러한 상황들이 이해되지 않는 것은 아니지만, 충분한 인력 자원이 투입되지 않을 경우, 제대로 과제 수행하기가 어려울 수 있기 때문에 현업 조직들의 협조가 필수적이라고 하겠습니다.


물론, 현업 이외에 컨설턴트와 IT 인력들이 함께 투입되지만, 실제 업무를 직접 수행하고 있는 현업들이 충분하게 참여해서 적극적으로 의견을 개진해야 좋은 결과물을 얻을 수 있게 됩니다. 현업 인력 투입 없이 진행한 사례를 몇 번 보았지만 이런 경우, 대부분 최종 결과물이 나왔을 때 현업들의 호응을 얻지 못해 과제가 좌초되거나 이를 기반으로 구현된 시스템 활용도가 낮아 실패 사례로 남게 됩니다.



그리고, 현업을 ‘파트타임(Part-time)’으로 투입하겠다고 하는 조직들도 있습니다. 그러나, 이런 경우, 현실적으로 과제(또는 프로젝트)에 전혀 도움이 되지 않습니다. 과제에 투입되는 현업의 경우, 기존 업무에서 탈피해서 순수하게 과제에 집중할 수 있어야 좋은 결과를 기대할 수 있습니다.


그리고, 과제를 진행하는 장소도 현업 부서와 물리적으로 떨어진 장소로 잡는 것이 좋습니다. 혹자는 현업 부서와 가까운 곳에서 하면 오며 가며 물어볼 수 있어서 좋다고 생각할 수 있으나 현실은 과제에 투입된 인력도 자꾸 불려갈 수 있다는 큰 단점이 있어 장소 선정도 신중해야 할 필요가 있습니다.


정말 현실적으로 충분한 현업 인력이 확보되지 않아 현업 부서의 도움을 받아야 하는 경우라든가 과제 특성상, 현업 부서와 지속적인 커뮤니케이션이 요구되는 경우가 아니라면 과제에 투입된 인력들이 과제에만 집중해서 일할 수 있는 장소를 선택하는 것이 좋습니다.


 (3) 각자 작업하지 말고, “함께 하거나 커뮤니케이션을 자주 하라”


실제 과제에 투입되어 작업하다 보면, 투입된 현업 및 IT 인력들 대부분이 이러한 과제 경험이 없거나 많지 않기 때문에 컨설턴트에게 의지하는 경향이 많습니다. 그래서, 많은 경우에 대부분 작업을 컨설턴트나 IT 인력들이 해 주기를 바라는 현업들이 많은데요. 마치 자신들은 최종 검토나 하는 사람으로 착각하는 이들도 있습니다.


그런데, 앞서도 언급했지만, AS-IS 프로세스를 충실히 분석해야 하는데, 현업, IT 인력, 컨설턴트 세 그룹 중에서 AS-IS 업무 프로세스를 가장 잘 이해하고, 상세하게 알고 있는 사람은 누구일까요? 여기서, IT 인력이나 컨설턴트들은 외부 인력들이 투입되는 경우가 대부분이므로, 실제 AS-IS 프로세스 하에서 직접 업무를 수행하고 있는 현업들보다 잘 안다고 할 수 없습니다.



반면에 현업들은 자신들이 알고 있는 내용을 모두가 이해할 수 있는 언어로 도식화하거나 정리하는 데는 익숙하지가 않은(미숙하다는) 단점이 있습니다. 그래서, 현업들이 더더욱 이러한 작업을 적극적으로 하지 않으려고 합니다. 이러한 현업의 특성을 잘 이해하고 과제에서 역할을 부여하는 것이 중요합니다.


컨설턴트, IT 인력, 현업들이 각자가 제일 잘하는 영역을 기반으로 역할 분배를 해서 과제를 수행해야 합니다. 그리고, 어느 한 그룹이 전체를 잘하지 못하기 때문에 상호 간 커뮤니케이션과 협업의 마인드를 가지고 과제에 참여하는 것이 중요합니다.


특히, 각자의 역할이 있지만, 과제에 참여한 모든 인력은 자신들이 가지고 있는 역량이나 역할과 무관하게 동일한 목표(과제 목표)를 가지고 있다는 점을 잊어서는 안 됩니다. 상호 간 커뮤니케이션과 협력 없이 각자의 역할에만 충실하게 된다면, 최악의 경우, 현업은 “바다”로 가고, IT 인력은 “산”으로 가고, 컨설턴트는 “사막”으로 향해 앞만 보고 열심히 가고 있을 수도 있습니다. 그러다가 한참을 간 후에 서로를 쳐다보고 서로 어이없어 하는 경우가 왕왕 있습니다.


필자가 직접 겪었던 케이스를 살펴보면서 커뮤니케이션과 협력이 왜 중요한지를 함께 이해하고자 합니다. “A 회사”의 AS-IS 프로세스를 정의하는 단계에서 컨설턴트, IT 인력, 현업이 모두 투입되었는데(물론, 충분한 자원이 투입되지는 않았지만), 현업들이 자신들은 프로세스를 정의하는 데 자신이 없다며, 컨설턴트와 IT 인력들이 정의하면 자신들은 검토하겠다고 빠져 있었습니다.


시작부터 문제가 있죠? 제가 앞서 “충분한 자원을 투입해야 합니다”에서 설명한 소극적인 현업의 나쁜 사례가 이미 발동하고 있었습니다. 그런데, 문제는 그게 전부가 아니었습니다.


아래 그림처럼, 프로세스 정의를 하는데 전체 Level을 5개로 나누고, 상위 프로세스(L1~L3) 정의는 컨설턴트들이 작업하고, 하위 프로세스(L4~L5)는 IT 인력들이 작업한 후에 이를 병합하는 방식으로 프로세스 정의하려 했습니다. 그런데, 아래 그림1에서 제가 “엘로우 카드(경고)”를 준 내용처럼 프로세스 각 Level 간의 기준이 명확하지 않은 상태에서 컨설턴트와 IT 인력들이 분리 작업을 한 것이 문제의 발단이 되었습니다.


l 그림1. AS-IS 프로세스 정의서 작성 방식의 나쁜 예


제가 위의 그림1에는 그리지 않았지만, Level 1의 메가 프로세스(Mega Process)는 Value Chain(영업, 고객 관리, 제조•생산, SCM•물류 등)을 기준으로 나누기 때문에 각각 메가 프로세스의 하위 프로세스를 담당하는 사람들은 모두 다르게 됩니다.


그래서, 이들 간에도(즉, 컨설턴트이지만 각각 다른 메가 프로세스를 담당하는 개별 컨설턴트들 간에도) 프로세스의 Level에 대한 기준을 상호 간 Consensus 하지 않은 상태로 각각 작업했다면 레벨이 서로 다르게 정의되는 문제가 생길 수밖에 없는 것입니다.


더욱이, 컨설턴트와 IT 인력들이 현업 수준의 업무 프로세스 이해도를 가지고 있다면 문제가 없겠지만, 보편적으로 볼 때, 컨설턴트들은 아주 일반적이고 공통적인 상위 레벨의 업무 프로세스 정도를 이해하고 있습니다.


IT 인력들은 전체 업무 프로세스를 이해하고 있다기보다는 시스템상에 구현된 기능 레벨로 이해하고 있어서 반드시 개별 작업 전에 서로 간의 커뮤니케이션을 통해 각각 레벨의 기준을 합의하고 작업을 하거나 아니면 함께 모여서 작업을 하는 것이 높은 품질을 유지하고, MECE 적 결과물을 얻을 수 있어 위의 사례처럼 재작업하는 시간을 획기적으로 줄일 수 있는 방법이라 하겠습니다.


여기에서 필자가 생각하는 가장 효율적인 방법은 각각 메가 프로세스 단위로 배정된 현업, IT 인력, 컨설턴트 세 그룹이 함께 모여 Level2(프로세스 체인)를 정의하고, 정의된 프로세스 체인 중에서 하나를 선택해서 세 그룹이 함께 논의하며 작업(정의)을 합니다.(1차 각 단위 Mega process 별로 프로세스 레벨 간 기준을 Consensus 하고)


매일 작업 된 내용을 퇴근 전에 전체 메가 프로세스에 배정된 인원들이(또는 각 Mega Process 대표들이) 모두 모여 각자의 레벨 수준을 맞추는 리뷰 회의를 진행하게 되면(2차 Mega Process 간의 프로세스 정의 기준을 Consensus 하게 되면) 작업 초기에 빠르게 프로세스의 각각 레벨 수준을 전체가 합의(Consensus) 할 수 있어 이후 개별적으로 작업을 진행하더라도 재작업을 크게 줄일 수 있게 됩니다.


즉, 다시 요약하면, 가급적 작업 초기에 함께 모여서 논의, 작업, Review를 반복함으로써 빠르게 작업 기준을 전체 과제 참여자가 Consensus 할 수 있도록 하는 것이 중요합니다. (이런 방식으로 해당 기업의 프로세스 레벨 기준을 정의하는 것이 경험상 가장 합리적)


l 그림2. 프로세스 정의 작업 방법 좋은 예


 (4) “프로세스 혁신 주체가 Ownership”을 가져야 한다.


이미 앞에서 언급했지만, 현업들이 업무 프로세스 혁신의 주체가 되어, 오너십(Ownership)을 가지고 과제에 임해야 함에도 현실은 그렇지 않은 게 문제입니다. 그러나, 앞에서처럼 과제에 투입된 현업들에 초점을 두고 이야기하고자 하는 것이 아니고, 실제 현업 조직과 그 조직의 임원 관리자들이 관심을 가지고 오너십(Ownership)을 가져야 한다는 것입니다.


필자가 많은 기업들의 프로세스 혁신 사례를 듣고, 경험한 것 중에서 가장 깔끔하게 성공한 사례를 잠깐 소개하고자 합니다. 국내의 “D 기업”인데요. 이 회사의 경우, 짧은 기간에 전체 회사의 프로세스를 혁신하고, 이를 단기간에 시스템 혁신까지 이뤄낸 보기 드문 케이스입니다.


이를 성공적으로 이끈 여러 가지 요인들이 있겠지만, 필자의 시각에서 볼 때, 가장 핵심적인 이유는 바로 프로세스 혁신의 주체인 현업 조직들의 적극적인 참여가 있었기 때문이라고 감히 말씀드릴 수 있겠습니다. 그렇다면, 제가 앞서 현업들은 자기의 본연의 목표 달성에 집중하기 위해 이러한 과제에 적극 참여하기를 꺼린다고 이야기를 했는데, 도대체 “D 기업”은 어떻게 이런 게 가능했을까요?


정답은 CEO의 관심과 Top-down 방식의 책임 부여 때문이었습니다. 현업들이 스스로 했으면 더 좋았겠지만, 이 회사도 초기에는 다른 기업들의 현업들과 다를 바 없었습니다.



그런데, 이에 대한 보고를 받으신 CEO께서 현업 조직의 임원들(각 업무 영역별 최고 임원들)을 모으시고, 이번 과제에서 도출된 To-Be 프로세스에 각 업무 임원들이 Sign(승인)을 하고, 추후 시스템 구축 후 프로세스나 시스템 문제를 제기할 경우, 면보직을 포함 강력하게 문책하겠다고 선언했습니다. 그리고, 여기에 더해 이번 혁신 성과를 각 현업 조직과 임원들의 평가 지표에 포함하겠다고 했습니다.


과거에는 초기에 현업들이 나 몰라라 하다가 시스템으로 구현이 되면, “이게 잘못되었다.”, “도대체 누가 프로세스를 이렇게 정의했냐?” 등등의 비난을 쏟아 내며, 그때야 자신들의 요구 사항을 한꺼번에 이야기해서 모두를 정신적 혼란에 빠뜨리는 경우가 비일비재했습니다.


그런데, 이제 “D 기업”에서는 CEO의 강력한 지시로 과제 초기부터 적극적으로 참여해 의견을 개진했고, 당연히 과제에도 우수한 인력들을 배치하여 이들이 실제 과제를 주도하도록 하였습니다. 그래서, 단 기간에 글로벌 규모의 회사 전체 업무 프로세스와 시스템을 한꺼번에(빅뱅 방식으로) 혁신할 수 있었습니다.


 (5) 조직, 제도•법, 사람, 기술 등을 고려해라.


마지막으로 프로세스 혁신을 성공시키기 위해서는 단순히 현업 입장에서만 업무를 바라볼 것이 아니라 조직적인 측면, 법과 제도, 그리고 이를 수행하는 사람, 심지어 이를 자사 직원들이 해야 할 것인지, 아니면 아웃소싱을 주는 것이 좋은지까지 고려하면서 정의하는 것이 좋겠습니다. 특히, 법과 제도는 회사 내 전문조직이나 외부 전문기관을 통해서라도 정확하게 확인하는 게 중요합니다.


특히, 여기에서 절대로 빠지면 안 되는 것이 바로 “IT 기술(Technology)”입니다. 이 IT 기술을 활용하는 수준은 기업마다 다른데요. 각자의 업무 프로세스 혁신을 이룰 때 각 기업의 준비 상황이나 업무의 유형 등을 고려해서 어느 단계를 적용할 수 있는지를 선택해야 합니다. (그림3 참조)


당연히, 최고 단계의 “Intelligent”를 적용하는 것이 좋겠지만 현실적으로 이를 위해서는 이를 뒷받침해 줄 수 있는 데이터, 이를 구현할 수 있는 기술, 그리고 이를 운영할 수 있는 인력과 체계가 준비되어 있어야 가능한 일입니다. 그리고, 한 번 구현했다고 되는 것이 아니라 수없이 많은 시행착오를 통해 정교화가 이루어져야 합니다.


l 그림3. IT 기술 활용 단계


최근 “4차 산업혁명”이다 “디지털 혁신”이다 이런 용어들이 범람하면서 “Autonomous”와 “Intelligent”라는 용어를 너무 쉽게 갖다 붙이는 경향이 있는 것 같습니다. 그러나, 실제 뜯어보면, Automation 수준이거나 초기 Autonomous 수준인 경우가 대부분이었습니다.


한 번에 모든 Step을 건너뛰고 단번에 Step 4(Intelligent)로 갈 수 있는 기업은 이 세상에 존재하지 않습니다. 또한, 그렇게 해 주겠다고 하는 기업이 있다면 “영업 멘트”라고 생각하시면 됩니다. 솔직히, 주위에서 고객사들이 가끔 이런 영업 멘트에 속아서 프로젝트(또는 과제)에 큰돈을 투자했다가 실패하고 실망하는 것을 몇 번 보았습니다. 문제는 그걸로 끝나는 것이 아니라 이 실패 트라우마로 적기에 혁신을 위한 투자를 하지 못해 시장에서 경쟁력을 잃을 수 있다는 점입니다.


실제는 각 단계 단계를 거치면서 데이터와 경험을 축적하고, 이를 기반으로 다음 단계로 발전할 수 있는 겁니다. 즉, 중•장기적인 발전 방향(또는 로드맵)을 바탕으로 이미 호흡을 가지고 발전시킬 수 있다는 것입니다.


만약, 상담원을 5,000명 고용하고 있는 기업이 어느 날 갑자기 상담원 2,000명을 “Intelligent Agent(Robot)”로 대체하겠다고 발표를 할 경우, 필자는 이를 Fact로 받아들이지 않습니다. 그냥, 마케팅 활동(기업 홍보성 활동)으로 치부합니다.


만약, 이 기업이 과거부터 여러 시스템 혁신 활동을 통해 수많은 시도를 하고 Step 2, 3단계에서 충분한 경험과 데이터를 축적하였다면 가능하겠지만, 이런 사전 활동 없이 이를 선언하였다면, 이는 당장 현실화할 수 없기 때문입니다. 이런 경우, 제대로 된 기업이라면 향후 5년 후에 현재 5,000명 수준인 상담원의 약 30%를 “Intelligent Agent(Robot)”로 대체하기 위한 중•장기적인 투자 계획과 로드맵을 발표했을 겁니다.



정리하자면, 프로세스 혁신 과제를 할 때, 기업의 환경, 업무 특성들을 고려해 중•장기 관점의 IT 기술 활용 계획이 함께 고려되어야 합니다.


이번 편에서는 기업이 프로세스 혁신을 성공시키기 위한 조건에 관해서 설명해 드렸는데요. 다음 편에서는 실질적으로 프로세스 혁신을 위한 방법론에 관해 이야기해 보겠습니다.


감사합니다.


글 l 김영주 총괄컨설턴트 l LG CNS 블로거


['누구나 전략 기획 고수가 될 수 있다' 연재 현황]

 

[1편] 전략적 사고의 중요성

[2편] 문제 해결을 위한 자질과 기본 원칙

[3편] 문제 해결을 위한 기본 원칙

[4편] 문제 해결 방법•논리적 사고 기법

[5편] 커뮤니케이션 역량의 중요성

[6편] 창의적인 사고방식

[7편] 창의적인 사고 기법 #1

[8편] 문서 작성의 오해와 진실

[9편] 창의적인 사고 기법 #2

[10편] 문서 작성 훈련법

[11편] 내 생각 출력법

[12편] 문서 작성 프로세스

[13편] 문제 해결 프로세스 #1

[14편] 문제 해결 프로세스 #2

[15편] 문제 해결 프로세스 #3

[16편] 문제 해결 프로세스 #4

[17편] 문제 해결 프로세스 #5

[18편] 경쟁력 분석 도구

[19편] 잘못된 분석은 잘못된 전략을 낳는다.

[20편] 환경 및 기술 분석 도구

[21편] 고객 중심 사고

[22편] 거시적 환경분석과 4P

[23편] 내부 역량 분석 #1

[24편] 내부 역량 분석 #2

[25편] 디지털 시대엔 전략 기획 역량은 필수?

[26편] 2017년을 보내며 전략 기획 재조명

[27편] '업무 속의 전략 기획' #1 전략적 회의록 작성

[28편] '업무 속의 전략 기획' #2 목표 달성 방법

[29편] '업무 속의 전략 기획' #3 미래 역량과 의사소통의 중요성

[30편] 기술에 앞서 문제에 집중하라.

[31편] 초심을 잃지 않은 Amazon

[32편] 브로슈어(Brochure) 직접 만들기

[33편] ‘초청장' 파워포인트로 만들기

[34편] 백종원의 골목식당 속의 ‘디자인 씽킹’
[35편] 
고수의 팁 ‘공감’과 ‘검증’

[36편] 신사업 정책 #1

[37편] 신사업 정책 #2

[38편] 신사업 시 재무 분석 #1

[39편] 신사업 시 재무 분석 #2

[40편] 함정에 빠진 Digital Transformation 회피 방법

[41편] 기업이 놓치기 쉬운 가트너의 메시지

[42편] 장기 목표 달성을 위한 전략•전술 수립하기

[43편] 올해의 목표와 달성 전략 수립하기

[44편] 기본에 충실하라

[45편] 전략 기획자가 본 기업의 인사 전략(HR)은?

[46편] 기업 전략에서 ‘이거 두 가지’는 이제 그만!!!

[47편] 프로젝트를 성공시키는 단 한 가지

[48편] 프로세스 혁신을 성공시키기 위한 조건


* 해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 LG CNS 블로그에 저작권이 있습니다.

* 해당 콘텐츠는 사전 동의없이 2차 가공 및 영리적인 이용을 금하고 있습니다.



Posted by IT로 만드는 새로운 미래를 열어갑니다 LG CNS
위로