[Workflow] 왜 이제와서 BPM인가?

Posted at 2010.08.30 09:02 // in Bender // by MOOVA 무바㏇
인원들이 정리 안 된 어떤 한 프로젝트에서 한 부서의 일을 본의아니게 몽땅 떠 넘겨받아서 처리했을 때의 일이다.
 이 업무는 해당 시스템의 청사진으로 모든 업무와 연계된 모듈이 예상되었다. 해당 정직(을)과 담당자들은 이미 이 업무를 맡기 싫어, 책임을 회피하고 요리조리 빠져나가려는 궁리만 하고 앉아 있었다. 해당 PM도 본인 회사의 시스템 담당자들에 대한 회의가 들어서인지 전적으로 프리랜서들에게만 의지를 하고 있던 상황이었다. 

인계받을 모듈의 규모도 작은 규모가 아니어서 싸인을 하는데만 여러 기업의 입심이 참 대단했었다. 보통 이런 상황에서 기업과 기업의 입장차이때문에 싸인을 마지못해 하는 경우가 많은데, 본인은 그런 상황에서 공식적으로 제대로 일을 한번 해 볼 수 있다는 기쁨 때문에 흥쾌히 그 종이에 싸인을 했다. (정말 돌이킬 수 없엇던 실수를 한 것이다.!)
- 아마 이 싸인으로 중간업체는 많은 돈을 챙겼다고 알고 있다. 본인에게는 콩고물 하나 돌아오는게 없었다.

2010:08:30 08:43:36

"전체적인 그림만 완성하면 난 만족할 뿐..."


이 때 맡아서 진행하려했던 모듈을 살펴보니, 코드와 프로세스는 전혀 정립되어 있지 못한 상황이었다. 이 모듈을 모두가 회피했었던 이유를 난 바보같이 늦게나마 깨달은것이다.
개발자들은 개발자 나름대로의 신공을 부려 각 기능을 제대로 개발했을지 모르겠지만, 큰 그림을 돌봐주는 사람이 없어 각 모듈을 조립했을 때 나왔던 큰 그림은 마치 중요한 부분들이 빠진 찢어진 지도와도 같았다. 현 시점에서 가장 중요한것은 이렇게 흩어져 있고 정리 안 된 것들을 "어떻게 보기좋게 정리를 해고 진행해야 하는가?"에 대한 고민이었다. 이 프로젝트를 실천하기 전 솔루션 엔지이너로 활동한 탓인지 프로세스 정비를 하는것이 유일한 첫째 대안이었다.
아무리 복잡한 업무라도 프로세스만 제대로 정립을 해 준다면, 나머지 구차한 작업들은 모두 한결같이 진행되리라!

해당 프로젝트에선 공식적으로 BPMS를 도입하고 있었지만 해당 업체의 컨설턴트들을 좀처럼 만나볼 수 없었다. 아마도 프로젝트 초반 시안만 작성해주고 떠났다고 본다. BPMS를 쓰지 못한다고 해서 아쉬워할껀 없었고 개인적으로 프로세스 정립하는 툴을 이용해서 5일동안 해당 업무의 프로세스를 정리하고자 했다. 시간도 너무 촉박했고 옆에서 닦달하는 PM은 항상 언제 끝나냐는 강압적인 압박만 지속한 상태다. 자신들이 직원들이 미적지근하게 처리 못 한 것들을 이제와서 정리를 해 주겠다는데 일정만 그렇게 외쳐대니 참으로 안타깝기 그지없었다.
이미 엎지러진 물이니 개인적인 시간을 내어서라도 전체적인 데이터가 흘러갈 수 있는 그림만 완성한다면 난 만족할 뿐이었다.

"개발자도 비즈니스 프로세스를 알아야한다"

그렇다면 프로세스의 정립이 첫 우선순위가 된 이유는 무엇인가?

일반적으로 프로세스라는 것을 생소하게 여기는 개발자가 많다. (TDD나 짝프로그램은 다른 범주이다. 개발자들에게 하려는 목표와 방향을 제시해주고, 실제로 그들이 해야 할 일에 대해서 정립을 했을 때 TDD나 짝 프로그래밍도 가능한 일일것이다. TDD와 BP는 범주가 달라서 따로 설명하지 않겠지만 둘 다 중요한 원리와 사상이 있다.)

프로세스란 결과를 발생시키기 위해 어떤 이벤트에 반응하는 한정된 활동들의 집합이다. 프로세스는 아주 단순한 것에서부터 복잡한 것에 이르기까지 다양하지만, 일반적으로 가치 사슬(value chain)이 가장 상위의 프로세스로 한정짓고 있다. 가치 사슬은 여러개의 비즈니스 프로세스로 구성되어 있고 비즈니스 프로세스는 또 각각의 프로세스로 분류된다. 프로세스는 서브 프로세스를 여러 레벨에 걸쳐 하위에 지니고 있을 때도 많다. 반대로 개별의 프로세스를 정립하면 상위의 프로세스로 그룹핑하고, 더 나아가서 최종적으로 가치 사슬을 나타내는 그룹으로 표현될 수 있다. 이때 주의해야할 것은, 상위 개념의 프로세스가 잘못 재정되면 가치 사슬로 묶여 있는 서브 프로세스들은 한꺼번에 무너지기 쉽상이다.

2010:08:29 19:03:52
가치 사슬

아쉽게도 주먹구구식의 프로젝트에선 위와 같이 비즈니스 프로세스의 정립을 할 시간 조차 없을 때가 많다. 만약 운이좋아 문서에 전체적인 윤곽을 그려낼 수 있으면 그나마 다행이다. 하지만, 항상 시간이 없고 일정은 촉박하다. 이런 일들은 BPMS벤더회사의 컨설턴트들이 해 주어야 하는데 그들은 개발자들이 구현할 때 즈음되면 다들 사라지고 없다. 또한 개발자들은 정리 안 된 거미줄위에 항상 반복되는 코드를 그려댈 뿐이다. 부서전체의 업무가 막장으로 가기전에 어서 빨리 프로세스를 재정립해야만 한다.!
 
"BP를 위한 좋은 도구"

이런 상황에서 도입할 수 있는 것 중에 하나는 간단한 WorkFlow시스템이나 프로세스를 그려줄 수 있는 간단한 도구를 사용하는 일이다. 적절한 BP도구를 사용하면 문서도 알아서 작성해주며, 최종적으로는 코드까지 산출해 준다. (물론 나머지는 개발자의 몫이다.) 필자가 주로 애용하는 BP도구는 Visual Paradigm이나 IBM의 RSA, 또는 Windchill의 Workflow엔진등이다. 물론 이것들은 비싼 라이센스를 지불해야 하기 때문에 정 여력이 없을 때는 OSWorkFlow같은 오픈소스를 사용할때도 있다. (벤더나 엔진은 다르더라도 BPML이라는 표기법은 모든 Workflow엔진에 비슷하게 사용된다. 필자가 항상 강조하는 원리와 기초가 중요하다고 하는 게 바로 이런 부분들 때문이다. 원리와 사상을 알면 어떤 도구나 언어를 사용하더라도 문제될게 없다.)

2010:08:29 19:17:27
OSworkflow의 프로세스 편집기

이 도구들은 복잡한 프로세스를 그림으로 표현할 수 있다는 장점이 있고, 또한 호환 가능한 규격이 이미 표준으로 정해져(BPML,BPEL)[각주:1]있다는데 매리트를 더할 수 있다. 위에 그림은 UML의 액티비티다이어그램과 매우 흡사하다는 것을 느낀다. 프로세스 모델링 표기법중에 UML의 액티비티다이어그램은 얼마전까지 BP의 범주에 포함되었다, 하지만 사실상 지금은 BPMN이 표준으로 자리매김하고 있다.

이렇게 작성된 BPML들은 프로세스 실행엔진에 의해 실행된다.
1. 정확하게 말하면 배포하기 전에 시뮬레이션을 돌려 먼저 비즈니스 프로세스의 오류 유무를 판별하는 작업이 이에 속한다(액티비티와 액터를 포함한 인증과정).
2. 프로세스 실행엔진은 프로세스 인스턴스를 실행하고 시작 이벤트에 의해 인스턴스가 흘러, 종료하면 인스턴스가 소멸된다.
3. 이러한 인스턴스들이 각각의 조건(BRM/BRMS)에 의해 제어당하고 다시 반복자와 접근자를 통해서 다른 비즈니스 프로세스를 호출할 수도 있다.

2010:08:29 19:31:44
windchill의 워크플로우 엔진

예를들어 전문적인 워크플로우엔진을 보유하고 있는 Windchill을 살펴보자. Windchill의 workflow메니저는 이러한 복잡함을 단순한 그림으로 표현하는데 성공을 한 케이스이다. 물론 도메인 특화에 맞게 결재시스템으로 활용하는게 대부분이지만, 실제로 workflow와 BPM은 그 적용범위가 상당해서 결재시스템 이외에도 다양한 비즈니스에 활용될 수 있다.

2010:08:29 19:50:24
BPMN의 일반적인 그림

"BPM을 도입하는데 가장 큰 이점"

BPM을 도입하는데 가장 큰 이점은 민첩성(agility), 가시성(visibility),유연성(flexibility),효율성(dfficiency)이다.

민첩성 : 끊없이 변화하는 고객의 요구사항에 민첩하게 대응하며, 플러그인함으로써 애자일스러워 질 수 있다.

가시성 : 업무담당자들에게 현재 진행되고 있는 인스턴스를 모니터링함으로써 데이터를 단일화하고 다양한 뷰를 시각적으로 이해시킬 수 있다.

유연성 : 복잡한 비즈니스 사항에서 예외적이고 변화적인 처리에 대한 즉각적이고 효율적인 대응력을 가질 수 있다.

효율성 : 워크플로우 자동화로 인한 비즈니스 프로세스의 처리 속도가 향상되고, 경고 및 알림 등의 이벤트에 의해 에러 감소와 관리 업무의 부담을 줄여준다.


"컨설턴트의 기본적인 소양. 비즈니스 프로세스"

개발자에서 컨설턴트로 나아가고자 하는 이들에게 비즈니스 프로세스에 대한 원리와 이해는 필수적이다. 프로젝트가 산으로 가고 있는가? 아무도 전체적인 그림을 잡아주지 않는가? 시간이 없어 단순하게 Copy&Paste만 기다리고 있는가?
구현을 수 없이 해 봤던 어떤 개발자는 이런 BP엔진을 사용한 후, 너무나 편리한 그 사용감 때문에 아예 로직을 짤 때도 별로의 Workflow엔진을 돌리는 취미도 새로 생겼다고 한다.
다양한 Workflow엔진을 습득한 후 비즈니스 프로세스의 원리를 파악해보자. 구현에 대한 사상에서 넓은 의미의 설계영역과 큰 그림을 볼 수 있는 눈이 생기리라 확신한다.

 BPM은 개발의 사고방식을 넘어서 컨설턴트나 아키텍트로 지향하고자 하는 이들에게 권유하고 싶은 종목이다.



참고서적 :
Windchill Workflow tutorial,
Workflow Management models,methods and Systems,
OsWorkflow packt
2010:08:29 20:18:57

  1. 비즈니스 프로세스를 모델링할 때 주로 BPMN이란 표기법을 사용한다. BPMN은 OMG가 주도하는 표준 비즈니스 프로세스 모델링 기법이다. [본문으로]
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기
  1. Favicon of http://moonlgt2.tistory.com BlogIcon 소박한 독서가

    2010.08.30 16:04 신고 [수정/삭제] [답글]

    전문적인 글이네요~ㅎ
    반 쯤만 읽었습니다.
    좋은 하루 되세요~~^^

  2. Favicon of http://ggons.tistory.com BlogIcon 꼰스

    2011.12.28 16:36 [수정/삭제] [답글]

    관리자의 승인을 기다리고 있는 댓글입니다

댓글을 남겨주세요.

티스토리 툴바