업무의 stagnation, 조만간 조직의 변경이 있을 것 같다. 계속 그래왔던 것 처럼… <일요일 출근하다 우연히 만난 친구의 말..>
조직의 변화로 얻을 수 있는 것은 프로세스의 변화로도 얻을 수 있다. 이 때의 프로세스는 정형화 되어야 하며 발전하여야 한다. 이런 프로세스를 운영한다는 가정하에서 급작스런 물리적 구조 변경이나 프로세스의 혁신의 ROI보다 점진적인 진화를 위한 Process management 의 ROI가 더 높다는 것은 이미 알려진 사실이다.


점진적인 프로세스의 진화는 항상 최신의 trend를 위해 최적화를 추구하기 때문에 공백 기간 없이 조직구조의 최선의 상태를 유지할 수 있다. 동시에 조직 변경, 성능, 품질 등 모든 면에서 예측이 가능한 관리와 사용할 수 있는 리소스와 해야 할 타스크들의 관계, 그리고 기타 운영에 관한 모든 것을 지속적 유기적으로 관리가 가능하기 때문에, 급변하는 IT환경에 효과적으로 대응할 수 있다. 변화하는 환경과 요구사항에 대해서 조직의 변화는 필연적이다. 그러나 그 변화에 따른 비용과 변화를 통해 얻고자 하는 효과는 쉽게 예측할 수 없으며 많은 경우 Hacking syndrome1)의 고리를 벗어나기 힘들다.

BPM을 왜 구축해야하는가? ITO, 경영 목표 달성, 재무 투명성, 등등등 수없이 많은 이유가 있지만 가장 본질적인 것은 바로 변화에 대한 요구를 수용하기 위함이 아닐까 한다. 프로세스는 관리와 동시에 진화가 되어야 한다. BPM기반의 프로세스는 변화에 대한 요구를 어느순간 추월할 수 있다. 어떻게 그것이 가능 하냐구? BPM기반의 정형화된 프로세스는 기존의 알 수 없었던 변화에 대한 요구까지도 물위로 올려 주기 때문이다. 위 그림의 타임라인에서 변화에 대한 요구는 BPM이 고려되지 않았을 때의 타임라인이다.

BPM과 기반 기술 연관성

BPM은 어디서 불쑥 나온 개념이 아니다.
유럽쪽에서는 1980년대 이후부터 꾸준히 그 개념이
정립이 되고 있었고 많은 상용 소프트웨어들이 나름의 방식대로 업무의 흐름을 자동화 하고 있었다. 최근에는 많은 단체에서 웹서비스를 비롯하여 표준들이 나오면서 어느정도 공식화된 틀을 갖추어 가고 있는 중이다.

위 그림은 ebXML에 BPSS가 있는 것 처럼, 웹서비스에 BPEL이 있고, 이와 흡사한 많은 스펙들이 존재함을 나타내고 있다. 이중 마이크로소프트와 IBM이 필두로 해서 만들어진 BPEL이 가장 탄력을 받고 있으나 BPM 본연의 기능을 모두 구현 및 달성하기에는 무리가 있다.

BPM을 다른 이름으로 워크플로우라고도 하는데 WfMC라는 단체에서는 XPDL과 WfXML/ASAP를 내놓고 있다. 아마 가장 활발히 활동하는 단체가 아닐까하는데 이곳에서 나름대로 데이터, 리소스, 업무 흐름을 모두 아우르는 표준을 만들어 나가고 있는 것 같다.

BPM 시작하면서

최근에 이슈가 되고 있는 BPM은 역사적으로 매우 오래 전부터 많은 사람들의 관심사였다. 산업혁명 이후 급격하게 복잡해진 비즈니스 프로세스에 대해서 지속적으로 관리의 필요성에 대해서 많은 사람들이 공감했으며, 이를 위해 경제적, 공학적, 철학으로 많은 접근 방식이 시도되었다. 최근의 움직임은 비즈니스 프로세스를 시스템화 하여 좀더 과학적이고 체계적인 관리를 가능하게 하려는 것으로 소위 말하는 BPMS의 도입과 그 활용 안이 널리 퍼지고 있다.

기업환경에서 일반적인 프로세스라는 것은 지금까지 매우 임시적인 것이었다. 즉 누구의 손을 거쳐 일을 어떻게 진행하겠다라는 지침이 있기는 하되 명시적이지 않고 서로간의 대략적으로 지켜야 할 약속 같은 경우가 많았다. 업무지침 혹은 업무의 흐름도라는 이름으로 문서화되어 있기는 하지만 엄격하게 지켜지는 경우는 드물었다. 이런 환경에서 소위 말하는 자동화 시스템이 도입되면서, 다수의 단위 업무들이 자동화 되기에 이르렀다. 이를 위해서 기업들은 지금까지 많은 비용을 쏟아 부었으며 현재도 단위 업무의 자동화에 많은 노력을 기울이고 있다. 단위 업무의 자동화는 곧 전체 업무의 자동화로 이어졌고 이는 곧 사람간 협업, 부서간 협업, 기업간 협업으로 나타나게 되었다. 좁은 의미의 협업이라는 것은 비즈니스 프로세스의 공동 실행으로 좀더 효율적으로 업무를 진행하고자 하는 것이다. 이 바탕을 정보 시스템이 받쳐 주고 있었다.

한때 BPR(Business Process Reengineering) 열풍이 불었던 것도 이러한 시스템을 좀더 효과적으로 도입하기 위해서 기존의 프로세스를 분석해서 임의적인 프로세스 중 문제가 되는 부분을 짚어내고 더 나은 방법을 시스템적으로써 제공하고자 했기 때문이다. 특히 BPR은 지금까지의 사람이 주가 되었던 비즈니스 프로세스를 정보 시스템이 중심이 되어서 좀더 효과적으로 구현하고자 하기 때문에, 그 프로세스가 완전히 바뀌어야 한다는 사상을 가지고 있다. 즉 지금까지의 정보 시스템이 정보를 어떻게 가공하여 저장하고 공유하는가에 초점을 맞추었다면 이제는 프로세스를 어떻게 가공하여 사람에게 제공하느냐에 초점이 맞추어 지고 있다.

ISP(Information Strategy Plan)이 많이 도입된 배경도 크게 다르지 않다. 소프트웨어 시스템으로 지원이 되어야 할 단위 시스템의 분량이 많아 지면서 무언가 체계화된 방법이 필요했고, 이 체계화된 방법을 통해서 기업의 IT담당자들이 참고할만한 지침이 필요했다. 이런 목적으로 어떻게 정보시스템을 구축할 것이며 이를 어떻게 이용할 것인지에 대해서 비전과 전략을 가지고 접근하고자 했던 것이다. 엔터프라이즈 아키텍처(EA)역시 비즈니스 영역과 정보 시스템영역의 관계를 좀더 체계적으로 정의해주는 하나의 프레임워크라고 할 수 있겠다.

이제 이런 IT와 비즈니스에 대한 요구사항을 연결해 주는 체계가 생겼으면 어떻게 프로세스를 정보화하는데 초점을 맞추어야 할 때이다. 어떻게 프로세스를 명시적으로 만들 것인가, 만들어진 프로세스가 최적을 경로를 말하는지 어떻게 분석할 것인가 그리고 최적의 프로세스를 어떻게 기존의 프로그램들과 엮어서 현업의 종사자들이 사용하게 할 것인가? 등, 기존의 방식으로는 해결하기 힘든 많은 이슈들이 있다.