[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가 주도하는 표준 비즈니스 프로세스 모델링 기법이다. [본문으로]
저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
블로그코리아에 블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 [수정/삭제] [답글]

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

댓글을 남겨주세요.

[Windchill 10] 분산처리 Form Processor 퀴즈

Posted at 2010.08.27 09:24 // in Bender // by MOOVA 무바㏇
2010:08:27 09:02:24

위의 그림은 Command Processor Pattern으로 작성된 Windchill JCA Form Processor의 트랜젝션 생명주기이다.
내부 트랜젝션은 녹색 사각형으로 표현되어 있고, 외부 트랜젝션은 파란 사각형으로 표현되어 있다.

Windchill에서는 분산환경 제체때문에 메소드서버의 외부 호출과 내부 호출에 대한 용도가 객체 생명주기에 각기 다른 영향을 미친다
(jotm과 같은 간단히 처리할 수 있는 라이브러리를 적용하면 분산환경에서 트랜젝션을 쉽게 분할할 수도 있지만..)

문제1. 전형적인 아키텍쳐 패턴인 CommandProcessor가 예가 될 수 있는 이 생명주기에서 디비와 객체간의 매핑을 시작하고 끝낼 때, 객체가 load되는 시점과 refresh되는 시점, clear되는 시점은 어느 부분인가?

문제2. 위의 Form Processor에서 Delegate를 적용하려면 JCA의 어떤 부분을 조작하여야 하는가?

힌트

<objecttype name="part" class="wt.part.WTPart">
   <action name="createPartWizard">
       <command class="com.ptc.core.components.forms.CreateItemFormProcessor" method="execute" windowType="popup"/>
   </action>
</objecttype>


문제 3. 문제2에서 delegate를 적용할 때 Delegate가 트랜젝션 생명주기에 미치는 영향 범위에 대해서 설명하라.

참고 : Delegate적용시 시퀀스다이어그램


원리를 알자.

JCA 프로젝트를 뛴 그들에게 퀴즈를 낸 것이니 다른 도메인분들은 Pass해도 좋습니다.

( 기술적인 접근은 다르지만 원리는 항상 모두 같다는게 포인트.)



저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
블로그코리아에 블UP하기

댓글을 남겨주세요.

[Windchill Security] Domain ACL 참고.

Posted at 2010.08.18 10:00 // in Bender // by MOOVA 무바㏇

위의 문서에서 Spring Security의 Domain ACL을 학습하는데 좋은 감을 얻을 수 있습니다. 챕터 10 Administering Access Control편을 봐주세요.

Permission

Description

Read

Determines the right to know the existence of the object and view it.

Modify

Determines the right to change the attributes of an object, as well as other characteristics that are part of the object definition. (For example, you have the right to modify the description attribute for a group, as well as remove a user from that group.)

Create

Determines the right to create an object.

Revise

Determines the right to revise an object. Revising creates a new version of the object at the same level as the original in the version tree. For example, you can create Revision B from Revision A.

New View Version

Determines the right to create a version for a specific view.

Delete

Determines the right to delete an object.

Change Permissions

Determines the right to change the ad hoc permissions that others have.

Users, groups, or organizations granted the Change Permissions permission are allowed to change the ad hoc permissions of others to the permissions they themselves have or to a subset of the permissions they have.

Administrative

Determines the right to perform certain administrative tasks. (For example, this gives you the right to break a lock or change an object's owner.)

Full Control (All)

Determines full control. A user, group, or organization with the Full Control (All) permission has all rights currently defined and any defined in the future. Therefore, when new permission types are defined, you do not have to write rules that specifically grant them to principals with full control.

 

2010:08:18 07:29:53

위의 그림은 Windchill의 ACL 편집기중 일부입니다. Type에 각 도메인 클래스들이 목록화되어 있고 이것에 대해 상태나 퍼미션을 지정합니다. 앞장에서 설명한 [Spring Security] Domain ACL 실무판 의 결론은 바로 위와 같은 메니저를 만들기 위한 튜로리얼이라고 해도 무방합니다. 제가 엔지니어들에게 기회가 되면 Wnidchill에 대한 학습을 권하는 것은 오픈소스에 녹아 있는 여러가지 가치 있는 공학 패턴과 사상이 들어 있기 때문에 기술적인 안목을 넓힐 수 있다는데 그 의의를 둘 수 있습니다.

Windchill은 그 외에도 비즈니스 프로세스,워크플로우, MDA기반의 애자일 설계, 기민한 UI조립(OOTB), CBD, UML, 프로젝트 메니지먼트, PLM/PDM, ORM, 신 MVC, 웹 프레임웍, 분산처리 환경, 대용량데이터베이스, 객체지향 설계(OOAD) 등 무수히 많은 사상이 녹아 있는 제품입니다. 또한 개발자에서 컨설턴트로 업그래이드하실 분들에게 강추한번 때리고 싶은 영역입니다.

이 단락은 Windchill을 홍보하는 것이 아닌 Windchill의 학습이 얼마나 많은 가치를 엔지니어에게 줄 수 있는 지 설명하기 위함이고, 또한 좋은 사상은 언제나 오픈소스나 타 벤더회사들이 모방하고 발전시키기 때문에, 자바가 태어났던 시절부터 같이 커온 Windchill이라는 색다른 영역에 대한 사상을 기회가 되면 한번 경험해 보시면 좋겠다는 취지로 작성하였습니다. ( Windchill의 분산처리 환경은 RMI와 EJB가 나오기 이전부터 발전시켜온 영역중에 하나입니다.) 단 기타 오픈소스처럼 한번 학습하고 바로 쉽게 이해할 수 있는 수준의 사상은 아니기 때문에 Windchill에 대한 경험과 학습은 많은 노력이 필요합니다. 하지만 노력뒤엔 언제나 밝은 웃음이 기다리고 있겠죠:)


2010:08:18 07:37:00
PTC 소식지 - http://communities.ptc.com/
저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
블로그코리아에 블UP하기

댓글을 남겨주세요.

[OSLC] Cloud에서 Collaboration을 지원하다.

Posted at 2010.05.20 20:39 // in Bender // by MOOVA 무바㏇


개발자의 협업에 대해서 검색하던중 협업에 대한 기술표준 단체를 발견하게 되었습니다.
Open Services for Lifecycle Collaboration (OSLC)는 소프트웨어 개발의 라이프 사이클 전반의 협업을 촉진하기 위한 기술표준 책정을 위한 단체입니다.



사실 개발자끼리의 협업도 중요하지만 폭넓은 의미의 협업을 생각해보면. 1. 개발자끼리의 협업 2. 고객과의 협업 3. 관리자와 개발자의 협업 등을 포괄할 때 라이프 사이클 전반이라는 의미가 살아난다.

  
1. Uniform Access
획일화된 접근을 가능하게 합니다. Requirement, Test Case,Defect등을 URL로 공개하는 기술입니다.
Open API와 같이 특정한 규격의 URL 포멧으로부터 공통된 접근방식을 취하자는데 있습니다.
이것은 사내의 소프트웨어 뿐만이 아니라 외부의 접근 및 분산화된 시스템에 존재하는 다양한 데이터를 취급할 수 있는 기술기반이 됩니다. 
 
2. Common Data Format

벤더의 시점에서는 변경관리, 문서관리, 형상관리등 각각의 시스템 정보를 공통으로 연계할 수 있는 방법을 찾을 것입니다. 예를 들어 A사의 요구관리 시스템으로부터 나온 추적성 정보를 B사의 변경관리에서 수용하고 변경가능하게 데이터를 통일화 한다면 추가적인 협의 없이 규약된 데이터 포멧을 취급할 수 있습니다. 또한 C사의 테스트케이스 툴로부터 A사의 요구관리 데이터를 추적하고자 할 때 데이터의 포멧이 공통되어 있다면 이 또한 추가적인 비용이 들지 않겠죠. OSLC는 각 기술영역에 소프트웨어 데이터를 처리하는하는 것을 전제로 공통의 데이터 포멧을 규약화 하려 하고 있습니다.
 
적용대상 영역은 다음과 같습니다. Product Lifecycle Management도 포함되어 있습니다. Windchill Data Format도 차 후 논의 될 듯 합니다.

Architecture Management (subscribe)
Automation - Build/Deploy (subscribe)
Asset Management (subscribe)
Change Management (subscribe)
Product Lifecycle Management (subscribe)
Quality Management (subscribe)
Reporting (subscribe)
Requirements Management (subscribe)
Software Configuration Management (subscribe)
Software Estimation and Measurement (subscribe)



3. REST Architecture

REST아키텍처 채용을 추진하고 있습니다. 클라우드와 비슷한 모델이라 볼 수 있고, 장소와 상관없이 툴을 은폐하고, 여과하며 검색할 수 있는 아키텍처입니다. 일반적으로 URL 베이스의 상태변이와 전달을 기준으로 삼는데 Uniform Access와도 관련이 깊습니다.



기존의 ALM은 정보의 공유만을 초점을 맞추고 있습니다. 데이터의 정확성이나 공통된 규약에 관해서는 미진했던 것이지요. 각 Management Tool에서 산출된 데이터를 어떻게 추적할 것이며 용이하게 만들 것인가? 라고 하는 것이 앞으로의 과제가 될 듯 합니다.

Open Service Blog : http://openservices.wordpress.com/
저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
블로그코리아에 블UP하기
  1. Favicon of http://minimonk.net BlogIcon 구차니

    2010.05.20 23:37 신고 [수정/삭제] [답글]

    음.. 위에꺼가 멀 의미하는지는 모르겠지만
    일종의 이슈트래커/버그트래커 와 비슷한 개념인가요?

    회사에 TRAC이나 mantis를 도입하려다가 계속 미루고 있는데(저의 게으름으로..)
    써본적 있으신지요?

    • Favicon of http://moova.tistory.com BlogIcon MOOVA 무바㏇

      2010.05.23 08:45 신고 [수정/삭제]

      베이스는 이슈트래커를 바탕으로 전개된다고 생각하면 될 것 같아요. 하지만 다른 부분이 있다면 좀 더 넓은 개념이 되지 않을까 싶습니다.

      협업이라고 한다면 개발자끼리, 고객끼리, 관리자끼리 이렇게 여러 분류를 둘 수가 있는데, 프로젝트에서 관리되는 모든 라이프 사이클을 '인터넷 기반에 로그를 남겨 사람들끼리 쉽게 쓸 수 있는 호환가능한 데이터 포멧을 구축하자'.. 정도의 개념이랄까요?

      한 기업에 Trac과 같은 버그트래킹시스템과 KnowledgeTree와 같은 지식연동 시스템, SalesForce.com과 같은 CRM시스템을 같이 쓴다고 가정하면 나중에라도 위의 3사가 제공해 주는 데이터 포멧을 연동해야 할 일이 생길 것입니다.
      그럼.. 데이터가 다르니 연계작업이나 커스터마이징을 해야하고 그렇다면 또 다른 추가적인 비용이 들어가겠죠. 이런 불편함을 어느정도 규격화해 차 후 발생하는 비용을 줄이자~라고 하는 의도로 보이는군요:)

      Redmine과 Jira는 실제 프로젝트에서 사용해 본적이 있습니다. 단 울며겨자먹기 식으로 윗선에 보여주기 위한 액션일 뿐이였지만..ㅎㅎ. 실제로 이슈트래커를 사용하기 위해선 스토리점수라던지, 요구정제 기법이라던지 정제된 방법론을 프로젝트를 위해서 병행할 때 그 효용가치를 높일 수 있더군요.

  2. Favicon of http://halfenif.tistory.com BlogIcon 머샤머샤

    2010.05.27 06:58 신고 [수정/삭제] [답글]

    "Mylyn Enables Agile ALM for Eclipse"라는 글입니다.
    http://pr-usa.net/index.php?option=com_content&task=view&id=349940&Itemid=95

    3월 후반에 본 글인데, Mylyn의 성장과 OSLC에 대한 내용도 담고 있습니다.

    제가 기억하기에 이전에 아파치 재단에서 진행하고 있는 ALF도 있었습니다만... :)
    IBM이나 MS나 Open환경 보다는 자신이 모두 제공하려고 하죠 :)-

    아! 그리고 트랙백감사합니다.

    • Favicon of http://moova.tistory.com BlogIcon MOOVA 무바㏇

      2010.05.30 10:29 신고 [수정/삭제]

      유용한 링크감사합니다. Eclipse의 Mylyn은 이제 개발자들에게 협업에 있어서 빼놓을 수 없는 추적용 커넥터인듯합니다. 많은 프로젝트 방법론 툴이 요구사항부터 코드레벨까지 추적할 수 있는것도 대단한 장점이지만 모든활동을 로그화 하자는 OSLC의 사상도 대단한것 같습니다.
      (보내주신 Link에 나오는TaskTop,Jira,TeamForge/ScrumWorks,Redmine과 같은 툴을 실제 프로젝트에서 써봤는데 그 효용성은 글쎄요..입니다. 왜냐하면 툴을 먼저 도입하기 전에 사람들의 활동을 체계화 하는게 더욱 중요할 듯 싶습니다. 너무 구속하는것도 역효과일것 같군요:)

  3. Favicon of http://halfenif.tistory.com BlogIcon 머샤머샤

    2010.06.01 19:56 신고 [수정/삭제] [답글]

    구속 보다는 팀의 문화를 만들어 가는 것.

    요즘 진행하는 컨설팅에서는 이런 대화를 자연스럽게 진행 할 수 있어서 행복합니다. :)

    팀원들이 자신의 문화를 진화시키려는 의지를 가지고 있는데, 좋은 도구가 있다면 더욱더 도움이 되겠지요. 창의적이고 열성적인 팀은 간단한 제로보드 하나만 가지고도 얼만든지 협업이나 팀문화를 아름다운 수준으로 달성 할 수 있을듯합니다.

    뭐. 그런거라 생각이 드네요.

    • Favicon of http://moova.tistory.com BlogIcon MOOVA 무바㏇

      2010.06.01 22:21 신고 [수정/삭제]

      공감이 가는 내용이네요. 획기적인 툴을 사용하더라도 팀원들이 의지가 없으면 그 툴을 사용하지 않음만 못하더군요. 창의적이고 열성적인 팀 흔치 않지만 그들은 무에서 유를 만들어내는 자질이 있는 것 같습니다.~ 댓글 달아주셔서 감사합니다.

댓글을 남겨주세요.

제조업이 해야할 과제 PLM

Posted at 2010.01.26 12:58 // in Bender // by MOOVA 무바㏇
얼마전 삼성의 사업중 일부분으로 PLM패키지를 자체 양산한다는 정보와 프로젝트 소식이 들렸다.
자체 PLM을 제품화하여 원가,비용절감을 통해서 생산성을 극대화 하고자하는 목적이 보인다.
하지만 PLM은 지극히 컨설팅영역부터 시작한다. 단순 노무가 아니란 점이다. PLM패키지 연구소부터 제품개발을 시작한다면 이해를 할 수 있는 부분이지만 단순히 SI성 사업으로 패키지화한다는 것이 작은 문제점으로 대두되고 있다. 안타까운 것은 PLM 컨설팅 영역은 자체 기업에서 승화할 수 있는 영역이 아니다. 보다 낳은 전문적인 기업과 같이 병행해야 할 문제이다. 단순히 PLM을 SI성 개발로 생산하고자 하는 목표는 PLM의 제일 중요한 요소를 간과시 하고 있을 뿐더러, 가장 중요한 요소를 빠뜨리고 있지는 않나 생각해본다. PLM의 제일 중요한 요소는 컨설팅영역이니까 말이다.



PLM의 궁극적인 도입 목적은 무엇일까?
기존에 획일적인 제조 방법은 저 생산성, 비 효율적인 관리, 제조가격의 거품화를 낳은 단순 노무의 성격이 강했다.

그런 제조 산업이 1990년대 중반 PDM을 만난다. 사실 PDM이란 단어가 PLM이라고 불리운지 꽤 지났다. PLM의 발전은 기업체에서 사용하는 application의 발달로부터 생겨나기 시작했다.

기업체에서는 제품의 라이프사이클 기간 동안 진행되는 여러 activity를 계획하고 관리하는데 일반적인 소프트웨어 프레임워크를 활용해왔다. 그러던 것이 생산성과 효율성을 고려하면서부터 PLM에 대한 솬심을 갖게 되었다. PLM은 이제 CPC나 PDM의 요소를 포괄하고 있다. 왜냐하면 가치사슬간의 협업을 연결하고 지원하는 것은 제품 라이프사이클의 activity에 없어서는 안 될 중요한 일부분이 된 것이다.

다음은 PLM도입을 하면서 기대할 수 있는 목적이다.

대외적 요인 :
1. 제조환경의 변화 : 부품 공용화 및 모듈화, 제품개발기간 단축 요구, 유연한 생산체계 구축 요구
2. 구매정책의 변화 : 효율적 공급정책 구축, 구매비용 절감
3. 기술정보 환경의 변화 : CAD 환경의 변화, 기술정보 표준화 및 데이터베이스화 요구

대내적 요인 :
1. 비효율적 관리 : 잦은 설계 변경, 기술문서 유효본 관리 공용품 설계 변경
2. 독자적인 정보 시스템 : 기간 시스템 간의 고립화
3. 협업 체계구축
4. 고객중심개발
5. 더욱 빠른 시장 출시
6. 수익성제고
7. 혁신적인 기술의 선적용
8. 품질 균질화
9. 고객 요구의 다양화로 제품 수명주지 지속 단축
10. 다양한 제품 개발이 요구되는 시장주도로의 경영환경 변화
11. 가치 사슬 및 프로세스상의 협업의 필요성 강화
12. 품질 요구사항 증가


기업이나 개인은 어떤 대상에 대해서 가치를 발견하여야 관심과 투자를 한다. 기업에게는 한정된 자원활용과 이윤추구라는 환경에서 단지 일반적인 관심이 아니라 비즈니스적 가치를 발견하여 관심과 투자를 한다.
이러한 경향은 PLM이라는 비즈니스 영역에서도 적용된다. 초기에 ERP가 PLM보다 시장에서 성공한 것은 ERP의 비즈니스 가치에 대해서 기업이 더 점수를 주었기 때문이며, PLM비즈니스 영역에서는 PLM의 가치에 대해서 충분하게 설득하지 못하였기 때문이다.

PLM의 가치는 기업의 생존전략에서 제품중심가치로 생각한다는 것이다. 이전에도 기업은 제품의 중요성에 대해서 인식하였으나 PLM가치의 재발견은 기업이 이제는 제품중심으로 살아 남아야 한다는 것에 인식을 같이 한다는데 있다.

1. PLM의 가치분류

PLM의 가치는 4가지로 분류할 수 있다.

1. PLM 비즈니스적가치(PLM Business Value)
   1.1 기업중심의 가치
   1.2 시장중심의 가치
   1.3 고객중심의 가치
2. 목적 가치(추구)
   2.1 Think, Make, Use
3. 영역가치
4. 활동가치(PLM Activity Value)

PLM에서 가치를 정의하지 않고 PLM 비전과 전략을 말할 수 없다. 가치를 정확하게 정의하고 가시화하는 것이 PLM 전략의 시작이다.

그림1. PLM의 가치사슬과 평가

2010:01:26 11:56:59


PLM의 도입효과는 제조산업이 특화되면서 더욱 중요하게 되었다. 도입효과는 효과분석 그리고 성과측정 평가정보전달 그리고 수정 보완의 절차를 가진다. 효과분석에서 가장 중요한 것은 PLM가치에 대한 평가일 것이다. PLM의 다양한 가치 안에 효과를 분석하고 이러한 자료를 적절하게 사용한다면 PLM도입의 가장 큰 이익을 볼 수 있다 하겠다.
그렇다면 PLM가치를 어떻게 발견할 수 있을까? PLM가치분석을 통해서 발견할 수 있다.
PLM 가치사슬은 무엇인가? 그리고 왜 필요한 것인가? PLM가치사슬의 목적은 정확한 전략과 목표를 발견하고 지속적으로 관리하는 것이다. 가치사슬에서 가장 먼저 하여야 할 것은 PLM선행으로 PLM가치사슬의 절차라고 말할 수 있다.

2. PLM의 핵심은 PDM

PLM은 CAD/CAM/CAE나 데이터베이스보다 비교적 새로운 기술이다.

       그림2. PDM 시스템 범위
2010:01:26 12:20:02

PDM은 PLM시스템의 핵심부분이다. PDM시스템은 제품 개발관련 개발자료나 기업의 다양한 관련자료를 관리한다. PLM시스템은 제품의 전체 수명주기 동안의 모든 제품관련정보나 프로세스를 관리하는 시스템이다.
PDM시스템의 특징은 자료 저장소(Vault), 정보개체관리(Item Management), 전자폴더(Electronic Folder), 업무흐름(Workflow)라는 비교적 생소한 개념을 가진다. 이것들은 실세계에서 발생하는 복잡한 관리대상과 프로세스를 전산세계에서 간편하게 구현할 수 있다. 또한 이러한 특징은 PLM에서도 같은 방식으로 적용하고 있다.

PDM시스템은 객체지향형 데이터베이스이다. PDM시스템은 모든 것을 객체로 관리하며 제어한다.
(PLM이 객체지향형 시스템과 가장 궁합이 맞는 이유 -- 소프트웨어, 어플리케이션 관점)
이러한 관리대상 객체를 시스템에서 정보개체 또는 아이템이라고 하며, 이러한 아이템을 생성하고 관리하며 자료 저장소라는 객체에 저장한다. 또한 업무흐름객체는 이러한 아이템들을 이용한 프로세스가 가능하게 해 준다. PDM시스템에서 가장 중심이 되는 것은 저장고라는 개념이다. 전자 저장소 또는 자료 저장소 (Data vault)라고 하는데, 다른 컴퓨터 응용으로 생성한 데이터는 파일을 PDM시스템의 자체정보를 첨가하여 저장되는 가상적인 공간이다.


3. PLM의 기본기능

PLM시스템은 핵심 PDM과 다양한 제품 수명주기시스템의 결합이다.

1. 개발문서관리
제품개발에서 생성되고 필요한 정보개체를 관리하며 안전한 중앙저장소에 저장하고, 메타데이터를 이용하여 이력관리와 추적을 하여주는 기능이다.

2. 제품구조관리
개발자가 생각하고 있는 제품의 구조에 대한 정보를 그대로 구현할 수 있다.

3. 부품정보관리
사용자가 설계한 부품 중 유사한 것을 그룹화하여 분류할 수 있어 부품지식의 재사용을 할 수 있으며, 기업이 지속적인 부품에 대한 지식을 축적할 수 있게 하여준다.

4. 프로세스관리
기업의 업무흐름 자동화를 이용하여 정확한 시각에 정확한 정보를 정확한 사용자에게 전달하여 줄 수 있다.

5. 변경관리
새로운 자료 생성이나 설계변경 정보를 전자적 결재 시스템을 통하여 승인을 요청하고 받을 수 있다. 결재 시 이와 관련된 데이터를 첨부 파일 형태로 관리할 수 있어서, 고객, 시장 또는 관련규정이나 조직으로부터 제품에 대한 변경 요청이 있을 경우 빠르고 적절하게 응답할 수 있는 기능이다.

4. 형상관리
프로세스관리와 제품구조관리의 기능과 결합되어 제품의 형상 또는 구성을 관리할 수 있게 해 준다. 따라서 개발이 진행됨에 따라 변화하는 제품 형상을 관리할 수 있다. 제품 구조를 시각으로 정의하여 설계, 생산 단계에 따라 다른 시각을 볼 수 있는 기능을 제공한다.

그 외 PLM기본기능

개발문서관리
제품구조관리
부품정보관리
프로세스관리
변경관리
형상관리
기술지원기능


4. PLM의 확장 기능

PLM의 확장기능은 다음과 같은 분류를 정하고 있다.

설계검증(Digital Mockup/Digital Validation)
요구관리(Requirement Management)
사업관리/일정관리(Program/Project Management)
전략구매(Sourcing)
상품전략관리(Portfolio Management)
제품사양관리(Configurator)
디지털생산(Digital Manufacturing)
서비스공학(Service Engineering)
협업(Collaboration)
자료시각화(Visualization)

5. PLM 관련 지식

업무에 컴퓨터를 이용하면서부터 이제는 각종 정보를 디지털 데이터의 형태로 작성하게 되었다.
3차원 CAD시스템이 만들어 낸 형상 정보가 들어있는 솔리드 모델 파일, 3차원 모델이 평면에 투영된 형상에 치수와 가공방법등을 적어 넣은 2차원 CAD도면 파일, 그림을 넣어 작업 방법에 대해서 설명하는 워드프로세서로 작성한 문서 등, 수많은 정보가 서로 연관 관계를 가지면서 중복되어 뒤죽박죽이다. 디지털 데이터와 파일이 오히려 생산성 향상에 장애가 되고 있다.

1) 제품개발기법
제품을 개발하는 방법론은 PLM지식에 많은 영향을 주었다. 초기에 영향을 주었던 것은 동시공학(Current Engineering)과 시스템 공학(Systems Engineering)이며, 다양한 기법들이 지속적으로 연관되어 발전되고 있다. 현재에는 DFSS나 QFD는 물론 공리적 설계(Axiomatic Design)와 PLM의 CNM(Customer need Management)영역에서 적용하려는 시도를 볼 수 있다.

2) 객체지향 개념
객체지향 기술은 PLM분야에 결정적인 역할을 한다. 관계형 데이터베이스 기술로 관리하기 어려웠던 분야까지 가능하게 만들었다. 대부분의 PLM시스템은 객체지향정보기술에 의존하고 있다. (PLM시스템이 객체지향기술로 승화할 수 있는 부분을 강조) , PLM시스템에서는 보통의 자료관리 시스템보다 복잡 다양한 자료관리를 하여야 하기 때문에 객체지향기술이 매우 적합하다. PLM시스템이 객체지향형 데이터 관리 시스템이며, PLM시스템을 구성하고 관리하는 모든 아이템 관리는 객체지향 기술의 원칙을 그대로 사용하고 있다.
특히 PLM Big 4중 하나인 PTC의 Windchill은 UML기술과 자바의 분산환경처리를 동시에 지니고 있으며, UP프로세스와 MDA방법론을 적용한 유일한 성공적인 제품 모델이다. PLM시스템이 객체지향형 데이터 관리 시스템이며, PLM시스템을 구성하고 관리하는 모든 아이템 관리는 객체지향 기술의 원칙을 그대로 사용하고 있다. PLM/PDM의 개념을 이해하는데 객체지향 개념은 매우 중요하다. P
(기술적으로 패턴지향, 아키텍트관점 지향이라는 점에 주목할 필요가 있다.) PLM/PDM시스템의 모든 것이 객체이며, 이 시스템은 객체를 생성, 복사,제어 관리하는 시스템이다.

저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'Bender' 카테고리의 다른 글

[Windchill Security] Domain ACL 참고.  (0) 2010.08.18
[OSLC] Cloud에서 Collaboration을 지원하다.  (6) 2010.05.20
제조업이 해야할 과제 PLM  (2) 2010.01.26
Windchill9.0 Debug Mode Guide  (0) 2009.12.17
Windchill Document Library ENG  (0) 2009.12.09
Windchill 관련 공유 문서  (0) 2009.11.04
블로그코리아에 블UP하기
  1. Favicon of http://blog.daum.net/sejnp BlogIcon 희망

    2010.09.17 12:16 신고 [수정/삭제] [답글]

    ㄹÅㄷ⒨ 좋은 글 감사합니다.
    모든 은혜에 감사드립니다.
    늘! 건강과 행복이 깃드시기를 기원합니다.
    건강 지킴이 내 병은 내가 고친다

  2. Favicon of http://www.7english.sm.am BlogIcon 100배빠른영어★클릭하세요

    2010.09.26 21:47 신고 [수정/삭제] [답글]

    영어공♬부㈇ 좋은 글 감사합니다<7개 공식으로 100배 빠른 영어공부<100배빠른영어공식★선택하세요

댓글을 남겨주세요.

Windchill9.0 Debug Mode Guide

Posted at 2009.12.17 16:07 // in Bender // by MOOVA 무바㏇

작성일 : 2007년 여름.
저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
블로그코리아에 블UP하기

댓글을 남겨주세요.

Windchill Document Library ENG

Posted at 2009.12.09 20:53 // in Bender // by MOOVA 무바㏇
Winchill의 기본 라이브러리입니다. 7버전을 쓰는 곳이 많더군요. 10 나온지도 꽤 된것 같습니다.
이쪽은 한글 문서가 별로 없기 때문에 장벽이 좀 높습니다. 일반 오픈소스랑은 사뭇 다릅니다.
대게 오픈소스와 + Windcihll 이라는 블랙박스 영역을 조합해서 사용하곤 합니다만,,
좀 다른 세계입니다.
이번 Windchill product가 버전업되는 관계로 오픈소스들이 windchill기본 라이브러리로 채택되었다고 합니다. 구글기술 눈여겨보신분들이 windchill 10에 접근하시면 좀 빠르실듯.

(  Java, 분산환경, UML-Rose,Workflow,lifecycle - bp,BOM,part,drm,cad관련,비즈니스 컨설팅,쥬니어 컨설팅, 기술 컨설팅,제품 컨설팅, 제품 임플리먼트 영역에 해당합니다. )























저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
블로그코리아에 블UP하기

댓글을 남겨주세요.

Windchill 관련 공유 문서

Posted at 2009.11.04 23:45 // in Bender // by MOOVA 무바㏇

STX에 있을 때 나름대로 영어공부한다고 공부하면서 
따로 번역해 둔 Windchill JCA Part Document입니다.
(번역료는 받지 않았음.)

친한 분들에게 뿌렸었는데 유용히 잘 쓰고 있다는 소식을 듣고 공유차원에서 블로그에 올려둡니다.
Windchill쓰시는 분들 유용하게 쓰시길.


저작자 표시 비영리 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
블로그코리아에 블UP하기

댓글을 남겨주세요.

[PTC(Windchill) Shared Document] JCA Quick Start Guide

Posted at 2009.02.02 02:07 // in Bender // by MOOVA 무바㏇

Windchill 9.0 JCA Quick Start Guide 입니다. (Windchill domain분들에게)

첨부된 파일은 미완성본입니다.
완성본이 필요하신분은 이메일로 연락바랍니다. paradozz@paran.com


신고
크리에이티브 커먼즈 라이선스
Creative Commons License
블로그코리아에 블UP하기

댓글을 남겨주세요.

[PTC(Windchill) Shared Document] Winchill9.0 + Ibatis 연동

Posted at 2009.02.02 01:44 // in Bender // by MOOVA 무바㏇

Windchill9.0을 도입한 프로젝트에서
작성한 Windchill JCA 와 IBATIS 연동 가이드입니다.





신고
크리에이티브 커먼즈 라이선스
Creative Commons License
블로그코리아에 블UP하기

댓글을 남겨주세요.

Windchill JMX Support

Posted at 2008.02.13 18:49 // in Bender // by MOOVA 무바㏇
사용자 삽입 이미지

Windchill을 띄우고 다른 커맨드 창으로 jconsole을 타이핑하면.

다음과 같은 swing창이 뜹니다. 이미 windchill 9.0에서 jmx Mbean server를 제공해 줍니다.

MBeanServer, Mbean등 다른 오픈소스에서 사용하고 있는 GBean이나 Mbean server등의 모니링도 서포트 해 줍니다. 예전에 모니터링 관련해서 Windchill의 인프라를 어떻게 웹이나 클라이언트로 해야할까 고민을 했는데. 9.0부터는 이미 jmx server를 준비해놨군요. 나중에 참고해야겠습니다.

사용자 삽입 이미지

Summary

사용자 삽입 이미지


Memory


사용자 삽입 이미지

Threads

사용자 삽입 이미지

Classes

사용자 삽입 이미지

Mbeans

사용자 삽입 이미지

큐가 몇개인지 프로세스가 몇개인지 감시할 수 있습니다. Windchill admin에 직접 접속하지 않아도 해당 value property값들을 직접 수정할 수 있습니다.

신고
크리에이티브 커먼즈 라이선스
Creative Commons License
블로그코리아에 블UP하기

댓글을 남겨주세요.

파이어폭스에서 빠른 Windchill

Posted at 2008.01.23 17:07 // in Bender // by MOOVA 무바㏇

windchill9.0에서는 MS Explorer보다 FireFox에서 더 '빠른 브라우저 로딩 속도'를 체험할 수 있었습니다. 기술력에 맞게 웹브라우저의 표준을 따르는 것 같고,  fireFox에서도 오류없이 잘 돌아 가는 것을 볼 수 있습니다

firefox에서 두배는 빨라진 느낌입니다. 시원시원합니다.

Windchill9.0에서부터는 웹 표준규격을 따릅니다.

사용자 삽입 이미지




신고
크리에이티브 커먼즈 라이선스
Creative Commons License
블로그코리아에 블UP하기

댓글을 남겨주세요.

티스토리 툴바