 |
BPM: 프로세스 경영과 정보기술의 미래 하워드 스미스.피터 핀가 지음, 류명재 외 옮김/시그마인사이트컴 |
2005년 1월 19일에 읽은 책이다. 내 자신의 이력서를 들여다보니, 참 이것저것 많이 쑤신 듯 하다. 어찌보면 내가 엔지니어처럼 보이기도 하고 말이다. 그래서 좀 바꿔야 겠다는 생각이 들었다. 나는 _____ 이다. 의 빈 칸에 나는 엔지니어, 강사가 아니라 나는 사업가라는 단어를 넣고 싶다. 이것은 단순히 즉흥적으로 생각한 것이 아니라 오래 전부터 나는 엔지니어나 강사로서는 내 인생을 채워나가고 싶지는 않았기 때문이다.
엔지니어로 나가려면 얼마든지 나갈 수 있고, 강사로서는 기회도 꽤나 있었지만 나는 경영을 택했다. 그리고 힘들더라도 그게 나에게는 맞는 일이라고 생각했고, 거기에 한 번도 의구심을 가져본 적은 없다. 힘들 때는 수도 없이 많았으나 힘듦이 계속될 수록 나는 새로운 것들을 느끼고 배우기 때문에 그게 헛된 시간은 아닐 것이다. 이러한 와중에 이 책을 접했을 때, 내가 지금의 내 상태로서 뭔가를 채워야할 것이 생겼다는 것이다.
IT 그것도 나는 엔지니어 자격증만 많은 듯 하다. CFPS 를 제외하고는 어찌보면 다 엔지니어 자격증이다. 나는 엔지니어가 아니다. 다만 기술을 알고 싶어했을 뿐이다. 그런데, 이 책을 보면서 내 생각이 많이 바뀐 것이 예전부터 IT 라는 기술을 활용한 경영이나 비즈니스는 염두에 두었지만 내가 비즈니스와 기술의 접목이라는 부분에서는 많이 간과하고 있었던 부분이 많은 듯 하다.
IT 공부와 영어 공부는 맥락은 갖지만 공부 방식이 다르다. 또한 같은 문과 계열이지만 어학 공부와 경영 공부는 다르다. 또한 회계 공부도 조금씩 차이가 있다. 그 중에서 내가 경영은 경험이다라고 생각했던 착각 속에 지난 날들을 지내온 것은 아닌가 하는 생각을 하게 만든 책이다. 경험도 중요하다. 허나, 적어도 IT 를 알고 그것도 단순히 IT Trend 나 흐름이 아니라 기술을 아는 내가 경영이라는 것에 IT 를 접목한 많은 다른 것들을 도외시하고 더 중요한 것을 놓치고 있지 않았나 하는 생각이 든다.
어쨌든 BPM 정말 매력적이다. 조사해보니, 핸디소프트 BPM 솔루션 인정받고 있다. 핸디소프트... 지순기... 어떻게 살고 있을라나 궁금하다. 연락처라도 있었으면 좋겠는데, 아쉽게도 없다. 어쨌든 꼭 이러한 공부들이 사업을 하려는 나에게 경영을 하고자 하는 나에게 도움이 된다라고 할 수는 없겠지만, 시간이 있을 때 공부하는 것이 좋겠고, 공부해서 실이 생기는 경우는 없다. 있다. 너무 생각이 많아져서 추진력이 떨어질 수 있다는 것. ^^
어쨌든 경영을 공부해야겠다는 생각이 들었다. 그리고 내가 현재 상태에서 남들과 차별화시키면서 터득할 수 있는 것이라면 이런 IT + 경영 관련 쪽이 아닌가 한다. 갑자기 다 때려치우고 Techno MBA 가고 싶다. 그러나 지금 나는 내 객관적인 능력이 조금 떨어진다 생각한다. 경험과 공부 아직은 더 투자해야할 때가 아닌가 한다.
이 책의 방대한 내용을 다 옮기기에는 힘들 듯 하고, 그 중에서 읽어볼 만한 내용 샘플로 정리해둔다. 이것만 읽고도 책을 읽어보고 싶다는 생각이 든다면 읽어보길 바란다.
p38
경영환경의 요구는 조직이 대응적 활동이나 예측적 활동에서 모두 유연하기를 강요하고 있다. 조직은 각 계층에서 정보를 기초로 의사결정을 내릴 수 있어야 하며, 전술과 전략이 균형을 이루고 예상하지 못한 변화에도 대처할 수 있어야만 한다. IT는 로직에 기초한 문제해결 방법이기 때문에 구현된 시스템의 품질은 설계자의 생각과 능력에 의존할 수밖에 없으며 설계자가 다양한 시나리오를 예측해야만 하는 문제해결 방법이다.
조직은 변화하는 상황에 맞춰 정보를 획득하고 실행할 수 있는 창의적인 매개체를 요구하고 있지만, IT는 시나리오 안에서 사전에 정의된 절차에 따라서만 대응하며, 예기치 못한 상황에 직면했을 때에는 즉각적으로 대응하지 못하는 경직된 시스템을 제공할 뿐이다. 변화가 일어나면 IT는 새로운 상황에 대한 대응절차가 만들어질 때까지 작동하지 못한다.
이 단절은 비즈니스 접근 방법을 수집하여 이를 시스템 기능으로 변환하는 현재의 기술중심적 방식의 한계에서 기인한다. 업무 매니저와 업무 분석가 그리고 시스템 분석가와 프로그래머 등 프로세스의 모든 참가자들이 사용하는 현격히 상이한 용어와 사고의 틀도 이 문제의 한 가지 원인이 된다.
혼란의 또 다른 원인으로 시간 효과가 있다. 업무 접근 방법 하나가 처음 제기되면 사업에 미치는 영향을 고려하기 위해 반복적인 검토가 이루어진다. 대부분의 경우 상세한 업무내용이 작성되어 확정되기 전에 이미 그 변화를 위한 기술적인 사양이 작성된다. 프로그램 안에 반영된 변화에 대한 상세하고 테크니컬한 표현 안에는 업무 측면에서 생각하는 변화의 특성이 충분하게 고려되지 않는 경우가 종종 발생한다.
그 결과 새로운 프로세스를 구현하기 위해 만들어진 컴퓨터 프로그램은 정작 업무 매니저와 업무 분석가가 이해하기 어려운 내용이 되어 버린다. 일단 프로세스가 컴퓨터 프로그램으로 구현되면 프로세스의 소유권은 영원히 IT 부서로 넘어 간다. 이로 인해 선문선답을 주고 받는 일련의 현상이 벌어진다. "비즈니스 프로세스"의 표현, 설치, 최적화, 관리에 참여하는 각 참가자들 사이에서 "프로세스"에 대한 정의도 서로 다른 의미가 되어 버린다. 이러한 단절을 해소하고 오늘날 기업들이 겪고 있는 IT와 관련된 어려운 국면을 타파하기 위해여 패러다임의 전환과 같은 어떤 계기가 요구되고 있다.
p254
ERP는 그 자체만의 강점이 있으나 ERP의 폐쇄형 구조 때문에 경영팀에서 비즈니스를 관리할 수 있도록 하는 기초적인 접근방법을 처리하는 데는 실패하였다. ERP 는 엉성한 IT에 대한 해법이었고, 이로 인해 우리는 깊숙이 파묻힌 비즈니스 규칙의 "엉키고 혼란스러운 자체 개발 해법"을 여전히 파묻혀 있는 비즈니스 규칙의 "잘 정립된 폐쇄형 시스템"으로 변경하였을 뿐이다. 이것은 일부 표준화 이슈들을 해결해 주었으나 막대한 비용 문제를 야기하였으며, 우리의 핵심역량으로 우리 자신을 차별화하는 능력조차 잃게 하였다.