여러 직무를 가진 구성원들이 하나의 조직 안에 없다 보면 내부적으로 발언권이 커지게 되는 직무가 나타나기 마련이다. 이는 회사마다 또는 조직 책임자의 성향에 따라 달라질 수 있다. 개발자가 개발에 집중하는 것이 아니라 기획과사업에 대한 다양한 의견을 쏟아낸다든지 , 디자이너가 개발자의 의견을 무시하고 디자인 방향을 잡는 식의 현상이생길 수 있다는 것을 말한다. 이러한 시행착오를 이기 위해서는 조직을 꾸릴 때부터 직무별 역할과 책임을 명확하게 선포하고, 이를 서로 간에 인정하게끔 해야 한다. 즉,
고의 전문가들이 모인 만큼 서로의 실력을 인정해주고 믿는문화를 만드는 것이 중요하다. 그리고 당연한 얘기겠지만각 직무 담당자가 해당 직무를 실행하는 데 필요한 의사 결점은 직접 나서서 한다는 공감대가 있어야 한다.
- P111
이때 이들 지원 조직을 기존 프로세스에 따라 실행하도록 두게 되면 담당자가 자주 바뀌거나 IT에 대한 이해가 전혀 없는 사람이 DX 프로젝트를 일종의 내부의 관리 규정이로 좌지우지하려고 드는 경우가 있다. 이러한 비효율적 전행을 방지하기 위해서도 경영진은 지원 조직에 있어 별도의DX 전담 인원을 배치해주는 주는 것이 좋다.
- P112
그런데 마치 자신들을 대신해서 DX 조직을 새롭게만들었다고 생각한다. 그러면 기존 조직은 겉으로는 협력하는 것 같지만 실상은 자신들의 영역을 빼앗기지 않으려고 강한 거부 반응을 보인다
- P116
기존 사업 조직 입장에서도 그동안 구축한 IT 시스템이나 데이터가 자신들의 소유가아니라 회사의 자산임을 정확히 이해하고, 이를 활용하여회사의 지속적 성장을 이뤄내는 것이 중요하다는 것을 정확히 인식해야 한다. - P118
즉 사업 고민을 하는 시간을 보고서 꾸미는 것으로 허비하지 말라는 뜻이다. 외국 기업들중에서도 파워포인트 중심의 보고가 아니라 일종의 스토리텔링을 중시하는 곳들이 많다. - P121
이를 위해서는 아직 디지털화가 되지 않고 수작업으로 관리되는 파일부터 우선적으로 디지털화하도록해야 한다.
- P127
어떤 일이든 안되는 이유 100 가지는 누구나 쉽게 이야기할 수 있다. 문제없는 조직, 문제없는 프로젝트는 없기 때문이다. 안되는 이유만 찾는 분위기에서는 사실상 혁신이 불가능하다. 그래서 안 되는 이유보다 되는 이유 한가지라도찾아내는 것이 필요하다. 만일 내부의 강점과 약점을 너무나 잘 활고 있고, 조직에 익숙한 사람이 중심이 되어 DX를실행하게 된다면 이는 혁신이 아니라 진화의 수준에 그치고말 컨이다. 기존의 조직 책임자와 구성원들이 내놓는 진화모델은 상당한 안정감을 주는 특징이 있지만 우리가 진짜하려는 혁신은 아님을 인정해야 한다. - P130
다음으로 프로젝트 관리자가 있다. 보통 PM이라고 불리며, 이들은 정의한 제품을 주어진 일정과 비용, 그리고 한정된 리소스 자원을 가지고서 만들어나가는 역할을 담당하다. 즉, 실행 과제를 하나의 프로젝트로 보고 이들 프로젝트의 일정과 범위를 기간 내에 맞추기 위해 스케줄링과 단계별 업무를 추적, 관리하는 역할을 담당한다. - P140
그러나 가끔 실행 중간에 어려움이 봉착하게 되는데 바로 각자의 R&R 에 너무 충실하여 아주 열심히 자기주장을 하는 경우이다. 특히 각자의 전문성을 지니고 있는 인력이 모여있는 프로젝트팀이라면 더더욱 자주 발생하는 문제이다. - P143
|