BPM

급변하는 비즈니스 프로세스를 고착화된 코드에서 분리하십시오. 대기업에게는 기존 업무 베테랑들의 프로세스를 자산화하여 지속가능한 비즈니스의 기반을 구축하고, 중소기업에게는 우리기업만의 프로세스 혁신과 통제를 통한 생산성과 표준화된 품질을 확보하십시오. uEngine BPMS 는 OMG 국제표준인 BPMN 2.0 을 지원하여 기업의 프로세스를 관리하고 지속적인 개선을 수행할 수 있도록 하는 프로세스 혁신 기능과 소셜 네트워크 기반의 포털을 통하여 창의적인 프로세스 협업을 가능하게하는 두가지 통제와 혁신의 관점의 UI/UX 를 통합하는 UI를 제공합니다. 기업은행, LG 디스플레이, SK 텔레콤 등 굴지의 금융과 통신 기업에서 검증된 uEngine BPMS를 통한 혁신 사례를 만드시기 바랍니다.

Github FaceBook Manual Guide

uEngine 제품 그룹

       
제품 설명 프로세스
모델링 및
정의보기
프로세스
모니터링
프로세스
실행
워크플로우 분석 / 통계 확장기능 다운로드 데모보기
uEngine BPMS 업무 프로세스
관리
제품다운로드
제품소개서
퀵스타트
사용자메뉴얼
데모보기
(uEngine 3.0)
uEngine BRMS 룰엔진 를 모델러
uEngine 전자결재 전자결재
그룹웨어
결재선 편집기와
기안기
데모보기
uEngine JMS 업무 메뉴얼
지식관리
제품소개서
     사용자메뉴얼    
     브로셔    
데모보기
uEngine PMT 프로세스
모니터링툴킷
     제품소개서
     사용자메뉴얼    
Process Codi 소셜BPM 기업용
SNS 서비스
     제품다운로드
     브로셔    
데모보기
Process Mobi 모바일
클라이언트
모바일
클라이언트
     브로셔    


왜 유엔진에서는 BPM 제품을 오픈소스화 한 것인가요?

유엔진 BPM 프로젝트는 기존 고가의 라이센스 비용으로만 접할 수 있던 BPMS 제품을 오픈소스 형태로 제공하고, 이를 적용하기 위한 교육과 컨설팅 서비스를 제공함으로써, 컨설팅 비용 중심의 예산구조를 통한 충실한 교육과 내재화 달성, 소스코드의 제공을 통한 고객 요건에 중심을 둔 충실한 커스터마이징, 다수의 서비스 채널을 허용합니다.


BPMS 도입 필요성

다양한 시스템(Groupware, EDM, KM 등)의 도입을 통하여 업무 경쟁력을 강화하려 했지만 업무의 중복성과 통일성 결여 그리고 특히 협업 차원에서 각 시스템간의 연계성이 떨어짐

관리자

도대체 업무가 어디까지 진행되고 있는 거야?
내 부하직원의 업무 스케줄이 어떻게 되나?
지난번에 지시한 사항이 반영되고 있나?

업무 담당자

여러 시스템에 관여된 업무화면을 한 곳에서 처리할 수 없을까?
한번 입력한 내용을 또 입력해야 하나?
전체 업무가 어떻게 흘러가는 거지?
이 업무를 어떻게 처리하는지 모르겠어.

시스템 관리자

시스템 간의 통합에 너무 많은 비용이 들어 간다.
요구변경이 너무 잦아서 매일 야근해도 작업량은 늘어만 가고 요청자(고객)들은 불평만 계속 늘어만 간다.

BPMS 도입 효과

BPM 시스템이 업무간의 전이를 담당하여 개인별 평균 업무 생산성이 향상되고, 조직 업무 규정에 대한 공통언어인 프로세스를 통하여 빠른 업무 파악이 가능하며, 업무 자겁 오류 또한 감소 효과가 뚜렷함

관리자


부하직원에게 요청한 사항을 실시간으로 모니터링 가능해짐
위험 혹은 예외 경우를 보다 빠르게 포착 가능해짐
보다 효과적인 프로세스 진행을 위해 단위업무를 재할당 할 수 있음

업무 담당자


수행해야 할 업무가 찾아 들어오므로 어떻게 업무를 수행하는지 알 필요 없음
업무 진척상황을 보고 할 필요 없음
프로세스에 대한 보다 빠르고 폭넓은 이해가 가능해짐

시스템 관리자

비즈니스 프로세스를 어플리케이션과 분리함으로써 빠른 개발 가능
비즈니스 프로세스에 대한 변경을 바로 반영함으로써 실시간 기업 구현이 가능해짐
보다 프로세스지향적이고 어플리케이션 통합 지향적인 시스템 아키텍처로의 발전이 촉진됨



유엔진 BPM은 어떠한 아키텍처적 장점이 있습니까?

BPM도입에서의 고려사항 중 기술적인 내용과 관계있는 사항은, 얼마나 용이하게 커스터마이징 가능한가와 우리 조직 시스템 환경에 부담없이 쉽게 융합될 수 있느냐, 입니다. 이러한 커스터마이저빌리티와 리스크 낮은 융합을 위해 유엔진BPMS의 아키텍처는 “객체지향 컴포넌트 프레임워크”의 접근방식인 IoC (제어권의 반전)과 “설계의 재사용”의 컨셉을 적용하고 있습니다.

이는, 조직도 찾기 로직의 분리, 액티비티 유형의 컴포넌트 인터페이스화, 엔진상 발생 이벤트의 리스너 등의 컴포넌트 인터페이스를 제공하여 BPM Hot-spot 서비스(고정부위)와 BPM 커스터마이징 빈발요소(가변부위)를 정제한 경계를 형성하며 고정부위의 서비스로서, 리플렉션을 통한 액티비티 컴포넌트 UI의 자동생성, 인스턴스 데이터의 관리, MQ처리, OLAP분석처리등의 기능을 기반 제공함으로서 개발자로 하여금 BPM 기반 개발에 있어 BPM하부 기술에 대한 어떠한 고민도 하지 않더라도 커스터마이징을 용이하게 하는 접근방식입니다.

이러한 접근방식은 이미 Spring Framework 등, 다양한 프레임워크에서의 접근방식을 BPM기반 시스템 개발의 영역에 대입한 것으로, 일반적으로 패키지 기반으로만 제공되어 Server/Client 방식의 연계만을 허용하는 BPM제품에서의 리스크를 대폭 줄이고 가용성을 최대화하는 기술적 기반이 됩니다.


Zero Code &

Extensible Vocalbulary

모델링이 곧 실행 프로세스
단일 툴을 통한 통합
업무관리자에 의한 프로세스 복구
사용자 설정을 통한 통계 분석 개발
확장적 업무

기능적으로 유엔진 BPM은 어떠한 차별점이 있습니까?

BPM적용을 한번 해보신 고객들을 다음과 같은 불평들을 하나같이 하십니다.

프로세스 모델링을 현업이 할 수 있다고 했는데, 너무 어려워서 IT의 도움을 결국 받을 수 밖에 없다. 자체적으로 프로세스를 개선할 수 있다는 이야기는 아무래도 못믿겠다.
한번 흘러간 프로세스의 단계는 도대체 복구라는 것이 불가능하다. 신이 아닌 이상, 업무적으로나 기술적으로나 어떻게든 프로세스의 진행을 뒤로 돌릴 수 없는 BPM제품은 결국 못쓴다.

업무의 흐름은 생각보다 복잡하다. 때때로 모델링시에 예측하지 못했던 동적인 상황이 벌어지는데, 이를 설계할 방법이 없어서 결국은 프로그래밍으로 해결해야 하는 순간, 이 프로세스는 현업에 의해 개선이 불가능해지는 "대수술"의 과정을 밟게 된다. 요약하자면, 

1. 사용자에 의한 프로세스 모델링이 불가능하다 
2. 롤백이 지원되지 않는다 
3. 동적인 프로세스의 유연성이 지금까지 BPM제품들의 주요한계점이었다는 것입니다. 

이러한 것들이 지원되지 못하는 것을 유엔진은 다음과 같은 기능들로 뛰어넘고 있습니다:

사용자는 업무를 마음껏 그리고자 하는 "미술가"이며, BPM은 이러한 미술가를 위해 다양한 색의 "페인트"를 제공해야 한다는 것입니다. 
그런데 이때 어떤 BPM은 색의 3원색만을 제공하여 "사용자가 알아서 색을 섞어서 사용하시라"는 접근을 한다면, 물론 최고의 미술가가 되기위해 사용자는 노력해야만 할것입니다. 
하지만 현업을 위해 최대한 다양한 의미의 비즈니스적인 색체를 띤 컴포넌트들을 쉽게 컴포넌트로 만들어 낼 수 있고 이를 현업이 사용하는 환경 (BPM에서는 프로세스 모델링을 위한 액티비티 타입 유형이 됩니다)에 쉽게 추가할 수 있는 "디자인타임 개발 프레임워크"의 제공이 중요하다는 것입니다. 앞서 설명된 것처럼, 유엔진의 컴포넌트 프레임워크는 기술적인 단위 기능의 컴포넌트를 BPM의 라이프사이클에서 유용하도록 디자인 타임의 자동 생성 및 포장기능과 인터페이스를 제공하여 이러한 "지속적인 프로세스 개선"을 위한 "지속적인 액티비티 표현력 개선"을 지원합니다.
무심코 "프로세스"라고 우리가 칭하는 것에는 다양한 대상들이 존재합니다. 사람과 사람간의 문서의 전달만을 고려한 "워크플로우", 시스템과 시스템간의 데이터 전달 과정인 "EAI 프로세스", 비즈니스 파트너와 파트너간의 "B2Bi 프로세스", 룰의 해석과정을 나타난 "디시젼 프로세스", 혹은 단순히 웹페이지들의 전이과정을 나타내는 "페이지플로우"... 이러한 것들은 사용자는 사실 그 명명조차 구분하지 못합니다. 
왜 이들을 분리하여 다른 모델링 도구에서 설계하고 다종의 엔진에서 수행하여야 합니까? 그리고 이러한 것들을 기술적으로 연결함에 있어서 한계점은 왜 그렇게 많이 존재합니까? 현업이 그리고자 하는 프로세스는 이러한 다양하게 기술적으로는 다른 유형의 프로세스를 하나의 툴에서 그리고자 하고 하나의 도구에서 실행되는 추상적인 모습을 당연히 떠올립니다. 그것이 BPM이라고 생각하는 것이 사용자 입장에서는 당연한  것입니다. 이러한  통합 모델링과 실행기능을 "End-to-End프로세스 지원" 이라고 합니다. 이러한 End-to-End 프로세스 지원이 어려운 이유는 단일 소프트웨어 벤더가 혼자서 이모든 프로세스 유형을 지원할 SW를 경쟁력있게 만들 수 없기 때문입니다. 그래서 대형 SW벤더들은 여러 경쟁력있는 해당 영역의 제품들을 M&A하여 엮기도 하지만, 아키텍처적으로 갑자기 통합하려 들면 소화가 잘 안됩니다. 유엔진은 최고의 오픈소스 제품들을 소스코드의 깊은 레벨에서부터 통합하여 유엔진의 통합 모델링 환경에서 Workflow - EAI - B2Bi - Decision Tree - Page Flow를 통합 모델링, 실행하는 것을 지원하는 몇 안되는 제품입니다.

BPM의 업무 진행의 복병은 한번 커밋해버린 지난 단계의 업무를 때때로 복구하길 원한다는 것입니다. 물론 BPM엔진이 지난 일에 대해 모든 것을 기억하고 그것을 정확히 복구해주면 가능하겠지만 프로세스가 실질적으로 설계된 모습을 모면, 외부 데이터베이스에의 접근등 BPM이 알아서 할 수 없는 권한밖의 일들또한 모델링이 되기 때문이 이를 복구한다는것은 아주 어려운 일입니다. 
현존하는 기술로서 이를 지원하기 위한 기능으로 "Compensation Handling"혹은 "Business Transaction"이라는 기법이 있는데, 이는 미리 프로세스 설계시에 순차흐름시 동작하는 change에 반대되는 복구 로직을 pair로 작성하는 것입니다. 유엔진은 BPEL4WS에 정의된 compensation handling framework를 지원하여 이러한 복구로직에 대한 이벤트 핸들링 처리를 지원합니다.
업무 담당자의 수나 어떤 데이터의 수에 따라 동적으로 프로세스 일부의 병렬건수가 동적으로 늘어나거나 줄어들고 그로인한 결과 데이터의 배분과 취합 또한 자동화되어야 하는 아주 복잡한 이슈가 현업에서는 아주 빈번히 발생합니다. 이를 유엔진은 GUI설정과 동적 프로세스 변수 배열처리의 기능을 통해 최대한 쉽고 용이하게 현업이 이러한 멀티플인스턴스(Multiple Instances)를 구현할 수 있도록 지원합니다.
이외에도, 유엔진 3.0에는 "집단지성기반의 사용자에의한 자생적 프로세스 개선" 기능, 웹에서 별도 설치 전혀없이 MS Office의 모든 기능을 수행가능한 순수 자바 오피스 "u-Office"내장, 다양한 Web 2.0 도구들을 통한 KM2.0과 BPM2.0의 통합 등의 혁신적인 기능들이 지속적으로 추가되어가고 있습니다.

이러한 월등한 기능적 우월성이 가능한것은 유엔진은 단일 SW회사의 일부 "머리"들이 고집스럽게 혼자서 만드는 제품이 아니라 많은 컨소시엄 참여기업들의 개발참여와 사용자들의 수많은 버그신고 등에 의해 자생적으로 집단지성에 의해 성장하는 제품이기 때문입니다.


(참고자료)
좋은 BPMS가 가져야 하는 속성 (Ismael Galimi-The founder of BPMI.org)
모델링이 곧 실행 프로세스 (Zero Coding)
단일 툴을 통한 통합 (End-to-End Process Modeling)
업무관리자에 의한 프로세스 복구 (Compensation Handling)
사용자 설정을 통한 통계 분석 개발 (Native BAM)
확장적 업무 표현력 (Extensible Vocabulary)

License

uEngine Open Source License : LGPL

주요 오픈소스SW 라이선스 비교            
  무료 이용가능 배포 허용가능 소스코드 취득가능 소스코드 수정가능 2차적 저작물 재공개 의무 독점SW와 결합가능
GPL O O O O O X
LGPL O O O O O O
MPL O O O O O O
BSD Licence O O O O X O
Apache Licence O O O O X O

1) 2차 저작물이 재 공개 의무가 있으나 저작물이 전체가 아닌 (“독점SW와 결합가능” 항목에 의하여) 유엔진 내의 필요에 의하여서 수정한 부분만 sf.net 등에 공개하면 됩니다.

2) 주로 유엔진 내의 설정파일 수준에서 수정이 이루어지기 때문에 소스코드 변경이 발생치 않으나, 관리자 화면의 스플래시 화면 수정의 요건이 발생할 수 있습니다.

3) 2차 저작물의 어떠한 내용도 재 공개를 원치 않은 경우 “듀얼라이센싱” 정책에 의거하여 상용화(소스비공개 권한 획득) 라이센싱을 구매할 수 있습니다.

4) 무비용으로 유엔진을 사용하고자 하는 경우:

5) 소스코드를 보호하고자 하는 경우:

출처 한국 저작권 위원회: http://www.olis.or.kr/osslice/guideViewComp.do



uEngine BPM Video

BPM 기본


BPM의 개념


uEngine 사용자 가이드 동영상


01 다운로드 및 설치 02 기본메뉴설명 03 기초모델링 04 폼기반업무 05 조건분기
06 루프 07 서브프로세스 08 데이타베이스 09 룰프로세스 10 멀티플인스턴스
11 이벤트핸들링 12 보상핸들링 13 영업수주프로세스


실전예제 - 업무 프로세스와 교육 프로세스의 통합


업무&교육 프로세스 통합


실전예제 - 대고객 만족 프로세스


기업 AS 프로세스 1 기업 AS 프로세스 2


실전예제 - SW 개발/관리 프로세스


프로세스 실행 오버뷰 프로세스 모델링 오버뷰 유연한 프로세스 관리 기법


유엔진 아키텍처


유엔진 프로세스 모델정의 1 유엔진 프로세스 모델정의 2
uEngine Customization 1 uEngine Customization 2 uEngine Customization 3
엔진 내부 해부 1 엔진 내부 해부 2 엔진 내부 해부 3


유엔진 개발환경 셋팅


디버깅 및 소스 분석 1 디버깅 및 소스 분석 2
이클립스 설정 1 이클립스 설정 2
logo