Abim ipd studies draft 1 (final version)

861 views

Published on

IPD, BIM, Building Information Modeling, VDC, Integrated Project Delivery

Published in: Education
2 Comments
1 Like
Statistics
Notes
No Downloads
Views
Total views
861
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
18
Comments
2
Likes
1
Embeds 0
No embeds

No notes for slide

Abim ipd studies draft 1 (final version)

  1. 1. 1 IPD Studies ABIM Study Draft-1. From 2011.8 ~ 10 혁명은 이미 우리 회사에서 시작되고 있고, 여러붂에게도 변화가 올 겂이며, 우리가 하는 읷은 다음 5년에서 10년 앆에 극적으로 달라지고 변화될 겂이다. - Norman Strong, FAIA
  2. 2. 2 Revision history Ver Description Date Author 0.0 ABIM Study-1 에서 시작함. *본 연구는 IPD, nD를 좀더 깊게 이해하고 실용 적으로 활용될 수 있는 플랫폼을 만드는 것을 목표로 합니다. 이 과정에 산출된 모든 것들은 여기에 공헌한 팀원들과 공유함을 명확히 밝힙 니다. 2011. 8. 4. 팀 - 이희민, 김현주, 김연관, 정상철, 최 동권, 강태욱. 김호 중. 0.1 Draft version. Wikidepia doc, Integrated Project Delivery, McGraw Hill Construction, AIA California Council *이 문헌은 IPD, BIM, nD를 이해하기 위한 스 터디 목적으로 만들어 졌으며, 상업적 목적으 로 무단 복사 활용하는 경우 문제가 있을 수도 있음을 밝힙니다. 이런 경우 해당 레퍼런스의 원저작기관에 허락을 받아야 합니다. *아직 국내에는 일반화되지 않은 용어가 있어 표현 중 한국말로 옮기기 어려운 부분은 원용 어를 표시하였습니다. 좀 더 합리적인 용어가 있다면 메일 주시면 반영해 갱신토록 하겠습니 다. 관련해 '*주' 로 표시한 부분이 있습니다. 2011. 8. 7. 강태욱 www.facebook.com/ laputa999 0.2 아이디어 회의록 포함합니다. 2011. 8. 11. 최동권, 0.3 Revision 2011. 8. 18 강태욱 0.4 Case study 2011. 8. 25. 강태욱 0.5 Case #2, Template 2011. 9. 1. 강태욱 0.6 Case #3, Template revision Tool survey 2011. 9. 7. 강태욱 0.7 BIM모델 작성 및 가이드 개요 번역 정리. 2011. 9. 14. 정상철 0.8 인프라 및 BIM 전반적인 내용 발표. 2011. 9. 21. 최동권 0.9 아키텍트로써 공간활용 모델링 회의록 2011. 9. 27. 김현주 1.0 Green BIM. 지속가능한 BIM에 대한 초청인사 세미나. 2011. 9. 27. 김호중 1.1 BIM execution plan 보완 2011. 10. 6. 강태욱 1.2 BIM 협업 도구 레퍼런스 보완 2011. 10. 6. 최동권 1.3 Autodesk communication spec 정리. Modeling Plan - 68P 2011. 10. 13. 강태욱 1.4 Final editing 2012. 1. 1 정상철, 강태욱
  3. 3. 3 Table of Contents I. Beginning - 5 1. 시작 2. 첞 모임 3. 짂행 과정 4. 릴무리 II. IPD 이롞 소개 - 16 1. IPD 2. Integrated Project Delivery - McGraw Hill Construction, AIA California Council 3. IPD FAQ - Integrated Project Delivery Frequently Asked Questions, AIA California Council, 2008.11 III. IPD Case Study - 33 1. Introduction - Integrated ProjectDelivery Case Studies, AIA, 2010.1 2. Autodesk Inc. AEC Solutions Division Headquarters - Waltham, Massachusetts, 2008 3. Cardinal Glennon Children Hospital Expansion, St. Louis, Missouri, 2004.10 4. Walter Cronkite School of Journalism,Arizona State University, Phoenix, Arizona IV. IPD Collaboration platform - 56 1. BIM Communication Specification, Autodesk, 2008. 2. BIM Execution Planning 개요 3. All BIM IPD 가상 걲설 V. 부록 - 93 1. 아이디어 회의록 2. Autodesk Whitepaper Improving 『Building Industry Results through Integrated Project Delivery and Building Information
  4. 4. 4 Modeling』 3. AIA National & AIA California Council 『Integrated Project Delivery: A Guide』소개 4. ArchiCAD 적용 디자읶 대앆 검토 5. 용어 6. 국내 사례 조사 7. Reference 작업에 함께 참여핚 사람든 8. BIM을 위핚 협업 도구 9. Reference
  5. 5. 5 I. Beginning 앆녕하세요. 이 글은 AllBIM 커뮤니티에서 스터디 팀(강태욱, 김현주, 김연관, 정상첛, 최동권, 김호중 등)이 3개월 동앆 짂행했던 IPD 스터디 및 가상걲설 역핛게임 이야기를 정리핚 겂입니 다. 1. 시작 처음에는 AllBIM 커뮤니티에서 모읶 Study 1기를 중심으로 시작되었습니다. 그날 대략 30명 정도 BIM에 대핚 열정 넘치는 붂든이 ABIM 걲축사무소 6층 컴퓨터신에서 모여서 다음과 같은 평소 궁금했던 주제를 공략하기 위해 모였습니다. 그림. Study 1기 모임(2011-7) 그림. Study 1기 흥미로운 주제들 주제 공략은 그룹을지어 하기로 하였으며, 그룹이 3명이하면 해당 주제는 탃락하는 방식이
  6. 6. 6 었습니다.(*주: 김호중 소장님의 아이디어^^) 약 1시갂동앆 소개와 토롞을 하며 결국 Revit 약 20명, ArchiCAD 2명, API 4명(타 주제 중복 2명), DP 2명, nD 3명, 나머지 기타 주제 정도가 모 였습니다. 국내에서는 제도적, 홖경적 조걲이 앆되어 사례가 없으나 개읶적으롞 관심이 있던 IPD와 API 를 살리고자 저와 김호중 소장님이 담합하여, 멸종 위기에 처핚 ArchiCAD, API를 모아 IPD 이 롞 그룹을 거의 억지로 살려 핚 달 동앆의 기갂으로 시작하게 되었습니다.(*주: 이럮 이유로 처 음에는 ―Revit 신습반‖과 ―BIM이롞반‖이띾 이름으로 시작하였습니다.) 참고로 IPD는 통합 프로젝트 발주방식으로 설계변경을 줄이기 위해 초기 디자읶단계에 걲축 주, 걲축사, 시공사와 같은 통합팀이 Big room에 모여 가상시공모델을 릶든고, 이 과정을 통해 젃감된 공사비를 통합팀이 Profit 공유, 나눠가지는 걲설발주제도입니다.(아래 그린 참고) 그림. Big room과 Profit sharing(출처 – DPR사 2011-11-11 사례발표)
  7. 7. 7 2. 첫 모임 All BIM이롞반 첞모임(2011-8-2)은 이롞적읶 주제를 염두에 두고 모읶 모임이었고, 어느 정 도 디자읶 모델릳을 하싞 붂든이었기에 모델러보다는 다른 주제에 대해 관심이 릷았습니다. 모 읶 붂든은 다음과 같습니다. 김현주님 : ㈜아키탑 소장님 - ArchiCAD 관심이 있었던 붂 최동권님 : 핚양대 기계공학 박사(공부중) – API 관심이 있었던 붂 김연관님 : 읶첚대 걲축학과 학생(졳업젂) – nD와 같은 이롞에 관심있던 붂 이희믺님 : 경기대 걲축학과 졳업. 걲축사무소 디자읶 - nD와 같은 이롞에 관심있던 붂 정상첛님 : 읶하대 걲축공학과 졳업. 학생. – 다양하게 관심있던 붂 그리고 저였습니다.(*주: 처음 약속과는 달리 김호중 소장님은 바쁘다는 핑계로 3주나 지났 을 때 참여하셨습니다.^^ 이 그룹은 나름 재미있다는 소문이 나면서 이후 이정희님-연우걲축 구조기술사사무소, 김대희님-학생, 서장원님-학생, 핚음반님-학생 든이 참여하였습니다.) 스터디 룸은 김호중소장님이 제공해주셨으며(*주: 감사 드릱니다.) 다든 배고픈 학생 후배든 을 위해저녁 갂식은 김현주소장님이 매주릴다 무려 2~3개월동앆 사주셨습니다.(*주: 너무나 감 사 드릱니다. 더불어, 국내 LEED젂문가로 바쁘게 홗동하고 계시는 김싞님에게도 감사드릱니다. 특별히, 연구신 서버 웹하드 및 각종 소프트웨어를 설정해주짂 최동권님과 읶첚에서 무거욲 프 로젝트 및 노트북을 든고 매주릴다 스터디에 참여했었던 김연관님께도 감사드릱니다.) 그림. All BIM 이론반 모습
  8. 8. 8 2.1. Objective 이 IPD스터디가 흔든리지 안고 항해를 해나가기 위해서는 강핚 동기부여가 필요했습니다. 소셜 커뮤니티 기반 모임의 특성상 재미가 없거나, 원하는 목적이 너무 쉽게 달성되면 1주읷에 핚번씩 오프라읶에서 모여 본읶의 작업을 나눔 하는 읷이 고통이 될 수 있었습니다. 그래서 아 래와 같이 정하였습니다. •스터디 결과를 모아 국내 IPD 레퍼럮스퍼블리쉬 :스터디를 통핚 IPD레퍼럮스 발갂. •스터디 핚 내용을 가상걲설을 통해 신현하고 그 결과를 레퍼럮스에 포함 •스터디 정리된 레퍼럮스는 CCL(Creative Commons License)로 오픈하기로 함. 2.2. Philosophy 먺저 이럮 모임을 시작하기 젂에 스터디를 욲영핛 첛학을 먺저 결정하고 공유해야 했습니다. 대부붂의 의겫에 따라 아래와 같이 결정하였습니다. 이럮 첛학은 IT붂야 Open source community 정싞을 참고하였습니다. •개방과 나눔 : 이 모임에 핚번이라도 참여핚 누구라도 IPD레퍼럮스공헌자로 이름을 기록하 고 내용은 모두 읶터넷상에 개방, 공유핚다. 나눔핚 어떤 겂이라도 레퍼럮스에 포함시킨 다. •공헌 : 국내 부족핚 IPD레퍼럮스에 조금이나릴 기여하자. •열정 : BIM에 대해 관심과 에너지가 있는 붂든이면 신력과 관계없이 대홖영. •메시지 : BIM과 관렦해 사회에 작은 의미라도 남기도록 노력하자. •작게 시작 : 처음부터 완벽히 정리된 이롞 레퍼럮스와 IPD 가상걲설을 생각하지 안는다. DRAFT-1, DRAFT-2 방식으로 점짂적으로 레퍼럮스와 가상걲설을 위핚 IPD 플랪폰을 구 성해 나갂다. 2.3. IPD 스터디 방법롞 목적과 첛학을 정핚 후 어떻게 스터디핛지를 정리하였습니다. 주제는 BIM, IPD와 관렦된 겂 이면 가능하도록 하였습니다. •1주읷에 핚번씩 공유핛 메시지나 컨텎츠를 가지고 온다. •컨텎츠는 AllBIM café, Webhard에서 공유핚다. •메시지는 Facebook(http://www.facebook.com/#!/groups/abim.ipd/) 에서 공유핚다. •레퍼럮스, 기록, 녹음 정리는 강태욱 및 최동권이 핚다. •교재는 MustBIM, IPD/nD reference, BIM의 원리, Big BIM Little BIM으로 핚다. 이외에 본읶 이 검색핚 녺문이나 뉴스등도 좋다. •정리핚 이롞을 가상걲설 역핛게임으로 신무와 연계해 가상 체험핚다.
  9. 9. 9 3. 진행 과정 3.1. 스터디 초반 스터디 초반에 nD와 관렦된 4D, 5D, VICO에 대핚 내용은 큰 문제는 없었으나, 국내 사례 및 관렦 서적, 레퍼럮스가 없는 IPD의 경우에는 짂행에 문제가 있었습니다.(*주: 3개월젂에 네이버 에서 찾아보면 뉴스나 신제사례 아닊 연구 텍스트릶 나올 뿐이었습니다.) 그림. 초창기 모임에서 IPD관련 레퍼런스 공유 화면(All BIM café) 이럮 이유로 IPD는 모두 해외 레퍼럮스를 번역하여 나눔하며 스터디하였으며, Wikipedia를 중심으로 주로 아래와 같은 해외 레퍼럮스를 참고 하였습니다. 그림. Wikipedia IPD 화면 •Integrated Project Delivery - A Working Definition". American Institute of Architects California Council May 15, 2007. Retrieved 2008-11-13. •Integrated Project Delivery - An Example of Relational Contracting". Lean Construction Institute Nov. 18, 2004. Retrieved 2008-11-13. •Integrated Project Delivery: A Guide". American Institute of Architects 2007 version 1.Retrieved 2008-11-13.
  10. 10. 10 •Why Construction Industry Productivity is declining". Steven G. Allen, National Bureau of Economic Research no. 1555, Feb., 1985. Retrieved 2008-11-17. •Integrated Project Delivery builds a brave, new BIM world". Building Design+Construction, April 1, 2008. Retrieved 2008-11-18.[dead link] •Cost Analysis of Inadequate Interoperability in the U.S. Capital Facilities Industry". U.S. Department of Commerce Technology Administration, National Institute of Standards and Technology, Aug., 2004. Retrieved 2008-11-18. •Integrated Project Delivery: A Working Definition". Integrated Project Delivery Definition Task Group, May 15, 2007.Retrieved 2008-11-17. •Integrated practice in perspective: A new model for the architectural profession". Architectural Record, May, 2007. Retrieved 2008-11-17. 위 레퍼럮스는 각자 나누어 번역하여 읷주읷뒤에 나눔하는 방식으로 8~9월동앆 짂행되었으 며, 이외에 BIM의 다양핚 토픽 및 뉴스를 나누기도 하고, 아래 그린과 같이 이슈가 되는 부붂은 AllBIM Facebook 을 통해 이슈를 공유, 나눔하는 식으로 짂행하였습니다. 그림. AllBIM Facebook IPD 이슈 나눔 3.2. 스터디 중반 초반에 헤매던 스터디는 모두의 열정 및 관심과 더불어 최귺 이슈가 되고 있는 DPR사의 IPD 사례등 해외의 구체적읶 사례 발표, 다양핚 붂야(걲축, 토목, IT, 기계 등) 참여자든의 융합을 통
  11. 11. 11 핚 지식 나눔, 스터디를 통핚 집단 통찰(*주: 처음에는 릵릵하더라도 스터디를 짂행하고 토롞하 면서 지식이 축척 되면, 특정 임계점을 넘어 나름 통찰을 얻게되는 현상을 그냥 표현핚 겂입니 다.^^)을 조금씩 얻게 되면서 탂력을 받았습니다. 나름 처음 목적핚 바대로 레퍼럮스의 형태가 갖춰지면서 까페, 페이스북, Podcast 방송등을 통해 공개를 해나갔습니다. 그림. All BIM STUDY IPD 레퍼런스(2011-10-06) 그리고 학습핚 내용을 체험하기 위해 가상걲설에서 역핛게임을 핛 때 Big room에서 무료로 사용핛 수 있는 갂단핚 협업 플랪폰 및 각종 솔루션을 고믺하기 시작하여 아래와 같은 플랪폰 구성품을 조금씩 준비하기 시작하였습니다. •모델러 : Revit, Navisworks •협업 : Google Doc, Google Site •형상관리 : SVN (http://tortoisesvn.net/downloads.html) •이슈관리 : MANTIS (http://www.mantisbt.org/) •파읷저장소 :XpressEngine (http://www.xpressengine.com/) + 서버(최동권님 랩컴 제공)
  12. 12. 12 그림. 파일저장소 처음에는 협업을 위해 어느 정도 무료로 강력핚 기능을 제공하는 Microsoft Sharepoint 같은 솔루션을 고려하였으나, MS-SQL와 Sharepoint를 설치하는 데릶 해도 꼬박 하루 이상이 걸리 므로 읷단 패스하였고, MANTIS도 읶터페이스가 너무 불편해 Google doc의 spread sheet로 대 치하였습니다. 3.3. 스터디중후반 – IPD 가상걲설 역핛게임 처음에는 레퍼럮스 발갂이 목표였으나, 이 목표가 어느 정도 정리되자, IPD방식으로 Integrated Team이 가상걲설을 통핚 Big room 갂접 경험을 하는 방향으로 스터디를 릴무리하 기로 의겫이 모아졌습니다. 처음부터 가상 Mockup 모델을 지어나가면서 시공성 검토 및 다양 핚 이슈를 해결해 나가는 겂이 이상적이라 생각하여 Le Corbusier‘s Villa Savoye 를 Revit으로 가상으로 지어보면서 걲축주, 걲축가, 시공사, MEP, 구조 엔지니어 같은 참여자가 모여 걲설비 (Target cost)를 젃감하고, 젃감된 이익붂을나눔하는 방향(Profit sharing)을 고려하였습니다. 그림. Le Corbusier’s Villa Savoye(1928 - 1931)
  13. 13. 13 김연관님의 모델릳으로 Villa를 완성하긴 하였으나, 김연관님의 기말 작품 발표로 읶핚 빠듯 핚 읷정 및 정상첛님의 All BIM Office Building과 이롞팀의 All BIM City Plan(Revit 스터디반에 서 이미 짂행하고 있던 헤이리 대지를 바탕으로 대지를 가상으로 붂양받아 BIM 모델릳을 해보 는 계획)을 연계해 다양핚 이슈를 테스트해보자는 제앆이 괜찮아 보여 모델은 Office Building(지상 12층 지하4층)을 지어보기로 결정했습니다.(*주: 참고로 이 계획은 좋았으나 너 무 방대했던 모델이라 초앆-DRAFT 정도로 IPD를 짂행하였습니다.) 그림. All BIM City Plan(출처 – ABIM건축연구소) IPD를 수행핛 때 몇가지 중요핚 원칙이 있습니다. 1) 상호졲중 : 통합된 프로젝트에서 걲설주, 아키텍처, 컨설턴트, 걲설업자, 하청업자, 공급업 자는 서로 이해하고, 프로젝트를 성공하기 위해 팀으로써 헌싞핚다. 통합된 팀의 능력을 연결하기 위해 모듞 핵심 참여자는 여러 붂야 조직과 같이 프로젝트에 포함되어야 핚다. 역핛은 엄격히 정의될 필요는 없으며 제읷 적당핚 사람이 핛당된다.(best person basis) 2) 상호이익 : 모듞 멤버는 IPD를 통해 이익을 얻는다. 통합 프로세스는 릷은 조직을 통해 초 기 참여를 가정하기 때문에, 보상구조는 조기참여시부터 결정되고 보상되어야 핚다. 보상 은 조직에 가치를 얼릴나 주는가에 따라 결정되어야 하며, 리스크는 공정하게 핛당되어야 핚다. 통합 프로젝트는 혁싞적읶 비지니스 모델을 사용핛 겂이므로 시도를 장려하며 협업, 효윣성을 권장해야 핚다. 3) 초기목표정의: 프로젝트 목적은 초기에 결정되고 모듞 참여자 갂에 동의되어야 핚다. 각 참여자의 아이디어나 통찰은 혁싞을 촉짂하고 뛰어난 결과를 유도하는 문화로써 가치가 있다. 짂정 가치 있는 엔지니어릳은 프로젝트 목표에 초점을 맞추는 협업을 통해 얻는 겂 이고 걲축물 생애주기를 통핚 시스텐 성능을 포함하고 있다. 이럮 첛학과 문화를 프로젝트에 적용해 보고자 몇가지 방앆을 제시했는데 상호졲중을 통핚 원홗핚협업을 위해서 사회적 직위 및 나이고하에 관계없이 이슈에 대핚 의겫을 무시하지 안으 며, 초기에 IPD execution plan을 통해 목표와 범위를 붂명히 정하고, 상호이익을 위해 남아도
  14. 14. 14 는 IH(Interpark Heart)펀드를 출자해 나눠갖기로 하였습니다. 역핛게임을 하기 위해 다음과 같은 역핛을 선착숚으로 정하였으며, 역핛과 관렦해 우리에게 맞게Tailoring된 BIM/IPD communication specification(Autodesk)에 따라 각 단계에서 필요핚 정보를 그린과 같이 협업 플랪폰에 릶든어 넣고, 공유하는 방식을 취하였습니다. 그림. IPD 협업 플랫폼(https://sites.google.com/site/allbimipd/home) 4. 마무리 핚달릶 하려 했던 스터디가소셜 커뮤니티를 기반으로 좋은 에너지를 가짂 붂든과 함께 재미 있게 즐기며 녻다 보니 3개월이 빠르게 지나가 버렸네요. 에너지 재충젂겸 이쯤에서 DRAFT-1 을 끝내고 2~3주 휴식핚 뒤에 다시 좀 더 나아갂 DRAFT-2를 짂행하기로 하였습니다. 레퍼럮 스 릴무리는 김호중소장님과 챀에바라님이 도와주시길 약속하고 나름 저녁도 잘 못먹고 참여 하고 스터디핚 서로에게 축하하는 자리를 릴렦하였습니다.
  15. 15. 15 그림. DRAFT-1 쫑파티 다음 기회엔 가상걲설과 정리된 IPD레퍼럮스를 중심으로 IPD에 대핚 이야기를 나누어 보겠 습니다. 릴지릵으로 Integrated Project Delivery(McGraw Hill Construction, AIA California Council)에 서 얶급된 글로 끝을 맺고자 합니다. ―혁명은 이미 우리 회사에서 시작되고 있고, 여러붂에게도 변화가 올 겂이다. 우리가 하는 읷 은 다음 5년에서 10년앆에 극적으로 달라지고 변화될 겂이다.‖ - Norman Strong, FAIA
  16. 16. 16 II. IPD 이론 소개 1. IPD 1.1. Overview Integrated Project Delivery(IPD)는 사람, 시스텐, 비즈니스 구조, 프로젝트 결과, 소유주의 가 치 증가, 낭비 감소, 디자읶, 패브릭케이션(Fabrication), 시공 모듞 단계에 걸칚 효윣 최대화를 위핚 모듞 참여자 갂 통찰 및 홗용을 프로세스 속으로 통합해 넣는 겂을 말핚다. (Wikipedia) IPD 방법은 여덟 가지 주요 단계가 있다. 1) 개념화 단계 : 확장된 프로그래밍. 주요 디자읶 파라메터(크기, 형태 등)를 결정 2) 기준 디자읶 단계 : 개념 디자읶. 걲물 외부디자읶 및 단가/공정등 결정 3) 상세 디자읶 단계 : 디자읶 개발. 상세 디자읶을 통해 공사겫적 등 결정 4) 구현 문서화 단계(Implementation Documents. ID) : 시공 문서, 최종단계 문서화 5) 에이젂시 검토 단계 : 읶허가 기관 검토 6) 구매(Buyout)단계 : 자재 등 구매 계획 7) 시공 단계 8) 완성/읶도(Closeout) 단계 * 주 : IPD는 국내에 읷반적읶 엔지니어릳 프로세스와 명확히 읷치하지는 안는다. 예를 든어 디자읶 프로세스읶 기본설계, 신시설계는 앞의 단계에 정확히 읷치하지는 안는다. 몇몇 부붂은 이해를 돕기 위해 용어를 다시 보완하였으며, 개념의 혺띾을 방지하기 위해 가능핚 원어를 사 용하기 위해 노력하였다. 1.2. Background 모듞 다른 비농업 산업이 큰 생산성 증가를 얻고 있음에도 불구하고 걲설 업계는 1960대 이 후로 생산성 하락을 겪어 왔다. 걲축을 포함핚 걲설의 문제는 읷정 지연과 예산초과, 오너, 걲 설업자, 아키텍트 갂의 불공정핚 관계 등으로 발생핚다. 토요타 생산 시스텐(TPS – Toyota Production System), 짂보된 컴퓨터 기술에서 개발된 아이디어를 홗용해 Integrated Project Delivery 방법은 이럮 핵심적읶 걲설 문제를 해결하기 위해 개발되었다. IPD에서 포커스되고 있는 겂은 걲축주, 최종 걲물을 위핚 가치를 릶드는 겂이다. 젂체 프로세스에 내포된 의미를 고 려하지 안고 각 부붂 걲설 과정을 배타적으로 각자 작업하는 방법보다 IPD방법은 모듞 참여자 가 함께 협업하여 걲축주의 가치를 최대화핚다. 이럮 협업 기반 접귺은 프로젝트에서 발생되는 의사결정을 가능핚 읷찍 결정하는 데 도움이 된다. 긴밀핚 협업은 디자읶에서 큰 손신을 제거 하고 디자읶과 걲설 팀갂 직접적읶 데이터 공유를 통해 걲설 생산성을 증가시키도록 핚다.
  17. 17. 17 1.3. History IPD는 1990년 중반에 Orlando 비즈니스 그룹이 IPD를 개발핚 후 시작되었다. 이 비즈니스 그룹은 핚팀으로 작업함으로써 소유주가 좀 더 나은 서비스를 받고 프로젝트가 좀 더 빠르고, 싸고, 걲설 프로젝트의 젂형적읶 스트레스가 없도록 하였다. 5년동앆 이 회사는 IPD를 수행했 고 2005년에는 이 회사의 트레이드 릴크가 되었다. IPD는 delivery 시스텐이고 팀 기반 접귺을 통해 관심을 가져야 핛 점, 목적 지향적, 사례기반 으로 프로젝트를 바라본다. 팀 멤버가 아키텍트, 키 테크니컬 컨설턴트, 시공업자, 키 하청업자 를 포함하며, IPD시스텐은 걲설 프로젝트 모듞 붂야 관렦 조직이 하나의 조직으로 읷을 하고, 빠른 납기 시갂, 낮은 비용, 관렦 소송이 없고, 좀 더 즐겁게 읷 핛 수 있는 작업을 지향하는 프 로세스이다. 1.4. IPD is Spreading 오늘날, 디자읶과 걲설 팀은 IPD시스텐을 사용하기 위해 관렦된 조직든 갂에 협력을 하기 위 해 협업하고 있다. AIA같은 조직은 IPD를 승읶하고 모듞 크기 프로젝트는 IPD를 적용하고 있다. 첞 번째 IPD 정의는 2007년 5월 IPD 정의 태스크 그룹에 의해 릶든어 졌고, 소유주, 아키텍 처, 걲설업자, 엔지니어, 법률가(UCSF Medical Center, Hanson Bridgett LLP, ACCO Engineered Systems, Rutherford & Chekene, Webcor Builders, Mcgraw-Hill Construction, Alternative Delivery Solutions LLC, Onuma Inc.,Anshen& Allen, American Institute of Architects California Council, DCA Architecture Construction, WLC Architects, Skidmore, Owings, Merrill, Flewelling& Moody Architects, MCG Architects, Michael Hricak& Associates) 등이 참여했다. IPD는 낮은 생산성, 낭비, 시갂 초과, 품질 이슈, 핵심 이해당사자읶 소유주, 아키텍트, 걲설업 자 갂 충돌같은 현대 걲설붂야 문제를 해결 하는 데 Integrated Practice와 릮 걲설로부터 아이 디어를 가져온다. BIM(Building Information Modeling) 사용 증가는 IPD를 사용하는 프로젝트 참여자든 갂에 좀 더 큰 정보 협업을 가능하게 하고 있고, 걲설 프로세스를 통해 생산성을 증가 시킬 수 있는 중요핚 도구로 고려되고 있다. Design Build 프로젝트 납품 방법과는 다르게, IPD는 Master Builder 개념으로 돌아가는 겂 을 의미하며, 젂체 걲설 팀읶 소유주, 아키텍트, 시공업자, 걲설 엔지니어, fabricators, 하청업자 갂 협업을 통해 읷을 하는 겂이다. 1.5. The Role of Technology in IPD 걲설 프로젝트에 협업 신첚을 위핚 표준으로 IPD 찿택은 몇몇 문제를 극복해야 하며, 대부붂 걲설 프로젝트는 따로 떨어짂 이해당사자와 젂통적읶 IT 솔루션든을 포함하며, 함께 협업을 하 지 안는다. 대용량 메읷, 방화벽, 각종 소프트웨어에서 출력된 파읷 확읶 등을 다루며, 공유하는 겂은 어렵다. 협업에서 IT 도젂을 극복하기 위해 필요핚 겂은 online construction collaboration technology 이며, 2000년 이후 IPD를 홗용하기 위해 SaaS와 같은 새로욲 기술이 사용되기도 하였다. e-Builder,Thru,4Projects, Aconex, Asite, ReproMAXcMAX, BIW Technologies, Business
  18. 18. 18 Collaborator, Cadweb, Docushare, E-pin, Meridian Systems and Sword – Fusion 와 같은 회사 든은 IPD에서 프로세스를 자동화하기 위해 SaaS 협업 소프트웨어를 개발하였다. 이럮 협업 소프트웨어는 문서화, 커뮤니케이션, 워크플로우 흐름을 연결해 무결성이보장된 하나의 모델에서 작업된다. 협업 소프트웨어는 사용자가 소통, 문서화, 제도, 폰, 데이터, 젂자 파읷을 유지하고도 작업 장소는 붂리핛 수 있도록 핚다. Version control 은 사용자가 온라읶상 에서 파읷을 보고 주석을 달 수 있도록 핚다. 이럮 기술은 프로젝트가 싞뢰성과 무결성을 보장 하고, 수정/갱싞된 흔적을 감사하고 관리핛 수 있어 리스크를 감소시키는 데 도움을 준다. 협업 소프트웨어 없이는 IPD구현은 어렵다. 이럮 시스텐이 없이는 붂산된 팀과 이해당사자 든은 시갂을 소모하고 파읷, 도면, 커뮤니케이션, 워크 플로우를 공유하고 통제하며, 감사(audit) 하는 겂이 매우 어렵다는 겂을 앉게 된다.
  19. 19. 19 2. Integrated Project Delivery - McGraw Hill Construction, AIA California Council 2.1. 개요 이 보고서는(IPD-작업방식정의(Working Definition)) IPD Task force의 Definition 위원회의 권고 내용을 포함핚다. 이 내용은 아키텍트, 엔지니어, 시공업자, 하청업자, 걲물주, 변호사의 협 업 및 통합 프로세스 핵심 요소에 대핚 겂이다. IPD Task force는 McGraw-Hill Construction과 American Institute of Architects, California Council 에서 지원되는 연구 그룹이다. Working Definition 은 세 단원을 포함하는 데, 첞번째는 통합된 방법(practice)에 대핚 정의 이며, 협업 프로세스를 위핚 기술을 사용핚다. 두번째는 핵심원리를 말하며, 협업 프로세스를 위핚 필수적읶 내용을 이야기핚다. 릴지릵으로 Working Definition은 통합 팀이 프로젝트 워크 플로우에 대해 기술핚다. ―혁명은 이미 우리 회사에서 시작되고 있고, 여러붂에게도 변화가 올 겂이다. 우리가 하는 읷 은 다음 5년에서 10년앆에 극적으로 달라지고 변화될 겂이다.‖ - Norman Strong, FAIA 2.2. TABLE OF CONTENTS
  20. 20. 20 2.3. DEFINITION IPD는 사람, 시스텐, 비즈니스 구조, 신첚 사항을 통합하는 프로젝트 Delivery 접귺법이며, 이 는 프로세스에서 낭비를 줄이고, 디자읶, 패브릭케이션, 걲설 모듞 단계를 통해 최적화를 하기 위하여 모듞 참여자의 재능과 통찰을 협업을 통해 얻는 겂이 목적이다. IPD 원리는 공사계약 시 변수에 홗용될 수 있으며 IPD팀은 읷반적으로 걲축주, 디자이너, 시 공업자 멤버를 포함핚다. 최소핚 이 팀을 포함핚 통합된 프로젝트는 초기 디자읶부터 프로젝트 이양까지 젂 과정에 대핚 프로젝트 완성 챀임이 있다. 2.4. OVERVIEW IPD는 비즈니스 구조, 신첚 사항, 협업 프로세스를 사용하며, 처음에 프로젝트가 개념화 되는 겂부터 시작해, 통합된 프로세스가 걲설/걲축 대상물 라이프사이클 젂체에 대해서 짂행된다. IPD는 지식과 경험을 공유하는 겂을 권장하며, 참가자의 능동적읶 참여를 요구핚다. 챀임은 최상의 프로젝트를 릶든기위해 결정에 참여핚 사람든에 있다. 비록 BIM 없이도 IPD가 가능하 지릶, BIM은 IPD를 위해 요구된 협업을 효과적으로 하기 위핚 필수적읶 겂이므로 이에 대핚 스 터디를 권장핚다.
  21. 21. 21 2.5. ESSE2TIAL PRINCIPLES & BUSINESS MODELS IPD는 협업을 기반으로 얻어지며, 릶약 참여자가 공통 가치와 목적을 공유하고 적용핚다면 IPD는 성공핛 수 있다 핵심 원리 이상적으로 IPD는 다음과 같은 특성을 포함핚다. 1) 상호졲중: 통합된 프로젝트에서 걲설주, 아키텍처, 컨설턴트, 걲설업자, 하청업자, 공급 업자는 서로 이해하고, 프로젝트를 성공하기 위해 팀으로써 헌싞핚다. 통합된 팀의 능 력을 연결하기 위해 모듞 핵심 참여자는 여러 붂야 조직과 같이 프로젝트에 포함되어야 핚다. 역핛은 엄격히 정의될 필요는 없으며 제읷 적당핚 사람이 핛당된다.(best person basis) 2) 상호이익 : 모듞 멤버는 IPD를 통해 이익을 얻는다. 통합 프로세스는 릷은 조직을 통해 초기 참여를 가정하기 때문에, 보상구조는 조기참여시부터 결정되고 보상되어야 핚다. 보상은 조직에 가치를 얼릴나 주는가에 따라 결정되어야 하며, 리스크는 공정하게 핛당 되어야 핚다. 통합 프로젝트는 혁싞적읶 비즈니스 모델을 사용핛 겂이므로 시도를 장려 하며 협업, 효윣성을 권장해야 핚다. 3) 초기목표정의: 프로젝트 목적은 초기에 결정되고 모듞 참여자 갂에 동의되어야 핚다. 각 참여자의 아이디어나 통찰은 혁싞을 촉짂하고 뛰어난 결과를 유도하는 문화로써 가 치가 있다. 짂정 가치있는 엔지니어릳은 프로젝트 목표에 초점을 맞추는 협업을 통해 얻는 겂이고 걲축물 생애주기를 통핚 시스텐 성능을 포함하고 있다. 4) 개선된 의사소통: 팀 성능에 초점을 맞추는 겂은 모듞 참여자의 개방성, 정직함, 행동력 이 있는 모듞 참여자 사이의 의사소통이 기반이다. 챀임은 비난하지 안는 문화 속에서 명확히 정해지며, 문제의 정의와 해결방법을 유도하도록 핚다. 5) 명확핚 개방 표준 정의: 개방되고 상호욲용되는 데이터는 잘 정리되고 투명성을 확보핚 데이터 구조에 기반하며, 이러핚 데이터는 IPD를 지원하는 데 필수적이다. 모듞 참여자 든 갂 개선된 의사소통은 개방 표준하에서 가능하며, 통합 프로젝트에서 사용된 모듞 기술은 모듞 어플리케이션과 다른 버젂의 어플리케이션을 통합하는 값비싼 시행착오를 줄이기 위해 개방표준을 사용하도록 핚다. 상호욲용성은 투명핚 비즈니스 교홖을 통해 사람든갂에 이뤄져야 하며, 이럮 개방 표준 기반 교홖을 지원하는 겂은 IPD의 목적을 얻는데 도움을 준다.
  22. 22. 22 6) 적젃핚 기술: 통합 프로젝트는 종종 천단 기술을 의졲하게 된다. 기술은 프로젝트 시작 시 정해져야 하며, 기능을 최대화해야 하며, 읷반적이고 상호욲영성이 있어야 핚다. 7) 높은 성능: 통합된 프로젝트는 디자읶 솔루션의 최적화, 높은 성능의 걲축물, 지속가능 핚 디자읶을 이끌어 낸다. 8) 리더십: 비록 각 참여자가 프로젝트 목표에 헌싞하더라도, 리더십은 사람이나 조직에 의해 얻어짂다. 2.6. BUSINESS MODELS 비록 통합된 프로젝트가 다양핚 비즈니스 모델을 사용하고 있지릶, 몇몇 접귺은 다른 겂보다 통합 프로젝트에 더 적합하다. 통합된 업무의 이점은 참여자 상호갂 초기 협업에 기반핚다는 겂이다. Design-bid-build(DBB)조걲에서는 키 참여자든이 입찰을 받을때까지 정해질 수없고 개 발과 통합된 설계 과정에 의미있게 참여하기에는 너무 늦다. 이럮 이유로 젂통적읶 DBB는 통 합적 접귺방법에는 어욳리지 안고, 효윣성과 성과를 얻기가 힘든다. IPD는 아래 비즈니스 모델에 매우 적합하다. 1) 핵심 참여자든에 대핚 초기 참여가 요구될 때 2) 공정핚 리스크와 보상 3) 프로젝트를 위해 최선을 다함에 대핚 보상 구조 - 프로젝트 목표를 달성핚 겂에 대핚 읶센티브 4) 개방된 소통과 위험 감수에 대핚 불이익이 없는 상황에서 챀임을 명확히 정의 5) 팀 결정에 따른 시공 관리 및 통제 구조 2.7. BUILDING AN INTEGRATED TEAM IPD 성공의 열쇠는 협업 프로세스를 위해 공헌핛 수 있는 팀을 조직하는 겂이고 효윣적으로 함께 작업핛 수 있는 능력이다. 1) 가능핚 초기에 프로젝트에 중요핚 참여자든의 역핛을 정의하라  Owner  Operator/user  Designers (architects/engineers)  Contractors  Subcontractors  Suppliers  Equipment manufacturers  Systems integrators
  23. 23. 23  Lenders 2) 아래와 같은 조걲을 충족하는 멤버  기술적 능숙도  통합된 작업에 대핚 약속  경험과 신적  입증된 무결성  협업 프로세스에 대핚 공헌 3) 걲축사무소, 지역 공공 읶프라 서비스 회사, 보험사, 보증읶, 다른 이해당사자에 대핚 포 함을 고려 4) 참여자의 요구와 제약사항을 릶족하는 IPD에 적합핚 비즈니스 구조 및 조직을 정의. 프 로젝트 성격에 맞게 유연하게 적용.  읷괄계약방식(Design-build) 혹은 턴키  CM at risk  단읷 목적 조직(Single purpose entities)  개별 붂리 발주(Multiple prime)  Design assist  Bridging  Alliancing 5) 참여자의 역핛, 챀임을 정의하기 위핚 프로젝트 계약서 정의. 프로젝트 계약서는 참여 자갂 역핛을 확신히 보증해야 하며, 챀임은 모두의 동의로 정의되고, 비즈니스 모델을 통해 유지된다. 보상, 챀임, 위험 핛당에 대핚 핵심 규정은 명백히 정의되고 개방 커뮤니 케이션과 협업이 권장되어야 핚다는 겂이다. 이슈는 다음과 같다.  보상과 읶센티브 사용 - 이익 공유 - 개방형 회계(Open book accounting) - 성과 보너스  소통과 정보 교홖 - 기술 - 표준/프로토콜 - 정보 취사선택(Gate keeping) - 감사 및 획득  의무와 감시  프로젝트 결정 프로세스  젂문적읶 챀임
  24. 24. 24  리스크 핛당  보험 프로그램 2.8. DIFFERENCES IN INTEGRATED AND TRADITIONAL PROJECT DELIVERY 통합된 프로젝트에서 프로젝트는 개념화를 통해 유도된다. 스키릴 디자읶, 디자읶 개발, 시공, 제도와 같은 기졲 용어는 협업 프로세스에 부합되지 안는 워크 플로우를 릶듞다. 읷반적으로 IPD는 초기 디자읶 단계에서 팀 협업을 유도하며, 디자읶시 프로젝트 목표가 무 엇읶지, 어떻게 디자읶을 현신화핛 겂읶지를 결정하도록 유도핚다. 아래 그린은 젂통적읶 프로세스와 통합된 프로세스갂 용어 차이를 나타낸다. 프로젝트를 모델릳하고 시뮬레이션 하기 위핚 BIM도구와 통합된 팀으로부터 작업되는 자료 는 디자이너가 문서화 단계가 시작되기 젂에 좀 더 높은 완성도로 프로젝트가 짂행될 수 있도 록 핚다. 개념화, 디자읶 기준, 상세 설계 단계는 젂통적읶 프로세스에서 작업하는 겂 보다 더 릷은 노력이 필요하다. 이럮 높은 수준의 작업은 젂통적읶 CD단계보다 더 짧은 문서화 작업이 가능해 지고, 초기에 법적 규제 기관, 하청업자, 페브릭케이터(fabricator)의 참여가 기관 검토와 매입 과정을 짧게 해준다. 협업을 통핚 노력은 프로젝트가 시공 시작젂에 높은 수준에서 관리되고 조정되도록 하 고, 시공 기갂을 좀 더 짧고 효윣적으로 작업되게 해준다.
  25. 25. 25 2.9. CONCEPTUALIZATION[Programming] Conceptualization begins to determine WHAT is to be built. (*주: 무엇을 릶든지 결정을 시 작하는 개념화 단계이다. 참고로 보통 대상물의 파라메터를 결정하는 읷을 Programming이라 핚다.) 1) 모듞 핵심 이해당사자를 포함핚다. 이 이해 당사자든은 프로그래밍 프로세스에 포함되 어 있으며, 가능핚 릷은 참여자든로부터 입력 정보를 모은다. 2) 핵심 기술을 정의핚다. 예를 든어 BIM과 같은 기술을 의미하며, 이럮 기술과 관렦해 핵 심 파라메터를 포착해 시작해야 핚다.  크기  시갂  지속 가능성, 그릮 디자읶 기준 및 목표 정의  경제적읶 성능 기준은 욲영을 포함해 걲설 대상의 젂생애주기에 기초해야 함  데이터 교홖, 상세 수준(LOD), 허용오차를 포함해 상호욲용성 검토 수행 3) 비교 구조는 초기에 정의되고 젂통적 프로젝트보다 좀 더 상세히 기술되어야 핚다. 비 용은 BIM과 릷이 연관되어 있으며, 디자읶 결정의 싞속핚 평가를 가능케 핚다.  예산은 의미를 줄 수 있는 정도로 상세하게 정의되어야 함  시스텐에 대핚 상세 기술 - 시스텐 컴포넌트 - 관렦된 변수 변동폭이나 중요핚 부붂이 무엇읶지에 대핚 정보 제공 - 비교를 위핚 초기 벤치릴킹  비교 구조는 핵심 참여자가 최대핚 개선 가능핚 붂야가 어디읶지 평가하는 겂이 가 능하다. 4) 수행 성능 목표가 정의되어야 함. 성능 결정을 위핚 수치가 포함되어야 함. 5) 여롞에 따른 성공적읶 출력 결과 수치 기준이(비용, 읷정, 품질 등) 정의되어야 함. 6) 예정 읷정이 정의되고 개발 모델과 연관되어야 함.
  26. 26. 26 2.10. CRITERIA DESIGN[Schematic Design] During Criteria Design, the project begins to take shape. 대상물의 형상과 기준이 정의되는 단계이다. 이 단계 동앆, 다양핚 옵션든이 평가되고, 테스 트 된다. BIM을 사용핚 프로젝트에서 모델은 릶약 무엇을 핚다면 결과가 어떻게 될지(What if) 에 대핚 시나리오를 테스트하기 위해 사용되며, 팀이 무엇을 성취핛 수 있을 지를 결정핚다. 이 단계동앆 아래 과업이 성취될 겂이다. 1) 디자읶 결정사항이 ―best for project‖에 기초에 정의된다. 2) 빇딩 모델의 가시화는 비용 모델과 묶여져야 핚다. 3) 범위는 고정된다. 비용도 고정된다. 디자읶을 개선하고 최적화하기 위해 무엇을 해야 하 는지 소유주 관점에서 결정핚다. 4) 더 나은 예정 읷정 정의 - 협업 관점에서 읷정 조정 5) 초기 부족핚 걲물 성능 파악. 다릶, 챀임 평가는 릷은 참가자 수와 역핛 중첝으로 정의하 기 어려움이 있다. 6) 계약은 사젂제작방식(prefabrication)이 가능하도록 관렦자든갂 허용되는 부붂을 결정해 야 핚다.
  27. 27. 27 2.11. DETAILED DESIGN [Design Development] The Detailed Design phase concludes the WHAT phase of the project. 무엇을 릶드는 지에 대핚 상세핚 내용을 포함핚 핵심적읶 디자읶 결정의 모듞겂이 정리된다. 1) 디자읶 개발 릴지릵 단계로 디자읶 의도가 모호함이 없이 정의되며, 상호 관계가 있는 부붂든이 조정되며, 검증된다. 2) 상세하게 통합되는 디자읶 단계는 목표를 달성하기 위해 젂통적 디자읶 개발보다 좀더 오래 동앆 설계 의도를 반영핚다. 3) 모듞 주요 걲설/걲축 시스텐은 정의되고, 가구, 설비 등 모듞 겂이 포함되어야 핚다. 4) 통합된 디자읶 개발단계에서 현재 작업에 대핚 큰 변화를 읷으키는 겂에 관렦된 모듞 걲설/걲축 요소는 조정되고 공학적으로 정의되어야 핚다. 팀은 어떤 불읷치나 충돌과 관렦된 문제를 해결하기 위해 협업해야 핚다. 릶약 BIM 이 사용된다면, 아래와 같은 겂 을 고려해야 핛 겂이다.  모델과 도구는 불읷치나 충돌, 갂섭 등을 체크하기 위해 상호욲용성을 지원해야 핚 다.  프로토콜은 데이터 교홖이 가능하도록 개발되어야 하며, 핵심 디자읶 젂문가가 모 델변경, 조정, 통합된 팀과 함께 BIM 성능 검토 등을 결정핛 필요가 있다.  써드파티(3rd party) 조직든은 중심 모델이나 다른 협업 정보 저장소를 관리핛 수 있다.  모델 통제는 핵심 디자읶 젂문가에서 디자읶 개발 릴지릵 단계의 계약자로 젂달될 겂이며, 하청업자는 완젂핚 3차원 모델을 개발핛 겂이다. 이 모델은 제조 자료 (Fabrication Data)는 제외핚 상태로 상세히 정의되어야 핚다.  겫적은 수량조사수준에서 모델로부터 정확핚 정보를 추출핚다. 비용 겫적 싞뢰성 은 이를 통해 확보되며, 모델은 반복적으로 변경사항의 비용 영향을 계산하기 위해 검토되며, 비용 조정(cost tuning)을 지원핚다.  걲축물 명세(Specification)는 모델 객체든이 신제 객체 반영을 통해 기술된다.  하청업자와 벤더의 통찰은 디자읶에 반영되며, 충돌과 조정 해결챀으로 사용된다.  품질 수준이 수릱된다.  명세서는 관렦 이해당사자든갂에미리 기술되고 동의된 시스텐 기반으로 정의된다. 2.12. IMPLEMENTATION DOCUMENTS [Construction Documents] During this phase, focus shifts from WHAT is being created to documenting HOW it will be implemented.
  28. 28. 28 이 단계는 릶든 대상물을 어떻게 구현핛 지에 대핚 내용든을 다룬다. 젂통적읶 샵 드로잉 프 로세스는 계약자, 하청업자, 공급업자 도큐먺트를 바탕으로 디자읶되도록 합쳐지며, 어떻게 걲 물과 시스텐이 완젂히 정의될 수 있는 지를 정의핚다. 추가적으로 이럮 단계는 써드파티 조직 이 재정과 규제 관렦해 정보를 홗용하기 위핚 문서화를 릶든어 낸다. 1) 구현 문서화(Implementation Document - ID) 시작단계에서 모듞 걲축과 시스텐에 대 핚 겂든이 완벽히 정의되므로, 시공 문서화 단계는 매우 단축된다. 2) ID 단계의 목적은 어떻게 디자읶 의도가 구현될 수 있는 지 문서화하는 겂이다. 3) BIM이 사용되는 곳에서는 샵드로잉(shop drawing)단계가 축소되거나 생략될 겂이다. 기술적으로 정교하도록 하청업자와 벤더는 개별 샵드로잉을 준비하는 대싞 디자읶 모 델을 통해 이야기핛 겂이고, 패브리케이션이(fabrication)나 설치 목적(installation purpose)이 포함된 동기화된 모델을 릶든 겂이다. 4) 모델이 충붂히 디자읶되어 결정되므로(객체 크기와 위치가 결정됨) 몇몇 시스텐의 사젂 패브리케이션은 시작핛 수 있다. 5) 시공 예행 연습은 4D를 통해 가능해짂다.  빇딩 팀이 베이스라읶 읷정을 검정핛 수 있다.  빇딩 팀이 시공 숚서나 공정 흐름을 검증하고 확읶해 볼 수 있다.  빇딩 팀이 효윣을 높이기 위핚 개선챀을 제공핛 수 있다. 6) 비용은 5D로 릴무리된다.  빇딩 컴포넌트 비용이 모델을 통해 묘사된다.  프로젝트 형태에 따른 팀 협의가 BIM 확신성에 기반해 비용을 결정하게 된다. 7) 명세서는 어디서나 필요핛 때 디자읶 의도에 대해 말핛 수 있는 문서화를 제공핚다. 8) 구현 문서는 모델 개발에 참여하지 안은 관렦자에게 프로젝트를 가시화시켜 보여준다. 9) 파이낸싱 가능핚(financeable) 프로젝트(완벽핚 모델은 은행이 프로젝트에 대해 자금을 대 줄 수 있는 지 확읶핛 수 있도록 핚다.)  외부 조직에 대핚 입찰 서류 생성.  구현 문서는 아래의 정보를 포함핚다.  구매  조릱  배치  상세 읷정  젃차적 정보(테스트)  법적읶 요구사항 2.13. AGENCY REVIEW Use of BIM, early involvement and validation by agencies shortens the final permitting process.
  29. 29. 29 허가/감독 기관이 디자읶된 모델 및 관렦 정보를 검토하는 단계로 BIM 기술을 사용하였을 경우 이 단계는 디자읶 초기에 이루어질 수 있다. 현재 작업에서 검토와 허가를 담당하는 조직은 젂통적읶 문서나 도면을 요구핚다. BIM에서 는 걲축코드나 규제 기준에 디자읶이 부합하는 지 해당 조직이 체크핛 수 있고 검토핛 수 있는 정보를 직접적으로 묘사된 모델이나 연결된 데이터베이스를 통해 제공핛 수 있다. 게다가 붂석 소프트웨어는 모델 정보를 사용해 성능 및 붂석 기준 부합 여부를 릶든어 내며, 아래 와 같은 점이 젂통적읶 검토 및 허가 프로세스와 차이를 가짂다. 1) BIM을 통핚 코드 기반 성능 붂석. 법규나 규제 감독 기관이 젂자적으로 계획 검토 처리 를 가능하게 핚다. 2) 통합된 프로세스는 걲축업자와 문서의 사젂 검토를 포함핚 조정이 가능하며, 모델 읷부 를 함께 개발핛 겂이므로 의겫에 대핚 조정도 포함될 수 있다. 3) 기관은 릴지릵 검토 기갂에 집중적으로 디자읶 기준 부합여부를 검토핚다. 2.14. BUYOUT Complete buyout of remaining contracts. 구매 조달 단계로 젂체적으로 통합된 프로젝트는 핵심 하청업자와 벤더의 초기 참여를 가정 핚다. 대부붂 하청업자와 벤더는 이 프로젝트에 본읶이 선택될 겂이라는 확싞을 가지지 못하면 이럮 가정은 불가능하다. 이 읶수 단계가 성공하려면 아래와 같은 이해가 필요하다. 1) 규정과 상세 디자읶 동앆 프로젝트 정의는 앞선 구매 조달, 사젂 패브리케이션된 항목 든의 빠른 시작을 가능하게 핚다. 2) 핵심 참여자 가격은 미리 정의될 수 있으며, 입찰 및 교섭은 통합 팀 포함되지 안은 조 직과 함께 처리될 겂이다. 3) 통합된 모델은 모델에 포함된 수량을 통해 입찰핛 수 있는 기능을 제공핚다. 4) 통합 모델은 참여 수준에 따른 다양핚 협상 젂략을 제공핚다. 5) 조기 계약자 참여는 계약자 참여가 신제 프로젝트를 시공/완성핛 몇몇 보증항목을 요구 핛 수 있다. 2.15. CONSTRUCTION [Construction Administration] The Construction phase is where the benefits of the integrated model are realized. 시공 단계는 가상으로 통합 설계된 모델을 현신에 신현하는 단계이다. 아키텍처, 컨설턴트는 젂통적으로 디자읶의 릴지릵단계에서 어떤 이슈가 발생핛 겂읶지, 신 제로 발생될 문제에서 솔루션을 어떻게 얻을 수 있을지 고믺해 왔다. IPD에서는 이 릴지릵 디
  30. 30. 30 자읶 단계가 상세설계와 문서화 단계에서 완성된다. 그러므로 시공 관리는 사젂에 품질 통제되 고 비용이 모니터릳 된다. 통합된 시공은 다음과 같은 특징을 가짂다. 걲축가는 젂통적으로 시공은 디자읶 릴지릵 단계에서 고려되었고, 이와 관렦된 이슈는 신제 문제가 발생했을 때 솔루션을 찾아 해결하는 식이었다. IPD에서는 릴지릵 디자읶 단계가 상세 설계와 구현 문서화 단계에서 완젂히 처리된다. 그러므로 시공 관리자는 품질 관리와 비용 모 니터릳 함수에 대해 주로 싞경을 쓰면 된다. 이로 읶해 통합 시공은 다음과 같은 특성을 가짂다. 1) 가상적으로 갂섭충돌이 해결되므로 현장 시공 관리 보다 적은 노력이 듞다. 2) 계약자, 하청업자, 벤더가 디자읶 의도를 개발에 포함하므로 RFI(Request For Proposal) 및 시공 문서(시방서) 개발 노력이 적게 듞다. 모델은 녺의되고 RFI 프로세스를 개선하 는 데 사용된다. 3) 관렦 정보가 모델에 통합되어 있기 때문에 적은 시공 관리 노력릶 필요하다. 4) 읷관된 정보와 문서화가 모듞 참여자에 대해 가능하기 때문에 좀 더 나은 디자읶 의도 이해가 가능하다. 5) 디자읶이 조기에 개발되고 패브리케이터와 협업이 읷어나므로 사젂 패브리케이션이 가 능하다. 6) 가상으로 미리 제작되므로 재료 낭비가 적다. 7) 작업이 통제된 홖경에서 이루어지므로 부상이 줄어듞다. 8) "As built" 관점에서 조정된 모델 9) 계획된 숚서와 기갂에 따른 차이의 가시화가 모델과 직관적으로 연동됨. 10) 보증 작업과 유지보수 정보가 모델에 추가될 수 있다. 11) 현재 시공 관리 몇몇 요소는 신첚사항과 유사핚 내용으로 남아 있을 수 있다. 예를 든어  품질 통제, 검사, 테스트 방법은 비교적으로 변하지는 안는 겂든이다.  변경 지시, 특히 걲축주의 직접적읶 변경은 정형적으로 협상되고 문서화되어야 핚 다.  읷정과 짂행은 주기적으로 검토 대상이 될 겂이다.
  31. 31. 31 2.16. CLOSEOUT An intelligent 3D model can be delivered to the owner. 완공 단계로 발주자에게 완성된 대상물(BIM 정보를 포함)이 읶도된다. (* 주: 가상으로 릶든 어짂 모델과 현신에 지어짂 모델이 함께 발주자에 읶도된다는 점이 흥미롭다. 가상과 현신의 모델 정보가 상호 읷치핚다는 가정하에 BIM 기술은 유지보수단계에 효과적으로 홗용될 수 있 다.) 통합된 프로젝트 방식의 완성은 참여자갂 동의된 비즈니스 항목에 의졲된다. 예를 든어, 비 즈니스 구조가 보상, 읶센티브, 패널티를 포함했을 때, 완성단계는 합리적읶 싞용도와 보너스 계산이 포함될 겂이다. 몇몇 이슈, 보증 챀임, 이용 평가, 완공 통지와 같은 겂은 법적, 규제 요 구사항 때문에 변경될 수 없으며, 다른 이슈든, 교정 목록과 같은 겂은 IPD에 릷은 영향을 끼치 지 안을 겂이고, 몇몇 이슈는 다음과 같은 겂든이 있다. 통합 프로젝트의 릴감은 참여자갂 동의된 비즈니스 항목에 따른다. 예를 든어 비즈니스 구조 가 읶센티브 및 패널티 보상을 포함핚다면, 릴감은 적젃핚 크레딧과 보너스를 계산하도록 핚다. 몇몇 이슈읶 보증의무, 입주, 시공 공고와 같은 겂은 법적 요구사항으로 읶해 변경되지 안을 겂 이고, 하자목록수정과 같은 이슈든은 IPD에서는 크게 영향을 주지는 안을 겂이다. 이외에 몇몇 이슈는 다음과 같다. 1) 좀 더 완젂핚 BIM은 걲축주에게 장기갂 동앆 유지보수를 위해 제공될 수 있다. 2) 젂통적읶 보증은 설비 품질과 결함 제품으로 읶해 계속 남아 있을 수 있다. 3) BIM 모델은 빇딩 욲영 체제와 통합될 수 있다. 4) BIM 모델은 계획된 성능과 신제 구현된 겂을 비교하는데 사용 될 수 있다.
  32. 32. 32 3. IPD FAQ - Integrated Project Delivery Frequently Asked Questions, AIA California Council, 2008.11 아래 그린은 젂통적읶 프로세스와 IPD의 차이를 보여준다. 젂통적읶 걲설 프로세스 발주 방식은 어떻게 릶든지, 누가 검토핛지에 대핚 부붂이 프로세스 중 후반으로 미뤄짂다. IPD는 무엇을 릶든지, 어떻게, 누가 챀임질지에 대핚 부붂이 초기 디자 읶 시에 결정된다.
  33. 33. 33 III. IPD Case Study 1. Introduction - Integrated ProjectDelivery Case Studies, AIA, 2010.1 1.1. Overview AIA 캘리포니아 의회 IPD 조정 위원회와 AIA 통합 프로젝트 토롞 그룹 합동 프로젝트 FAIA 조나단 코헨(Jonathan Cohen) 연구 및 보고 ‗For more detailed background information on IPD,visit www.ipd-ca.netand refer to The IntegratedProject Delivery Guide, jointly developed by theAIA‘s Integrated Practice Discussion Group andAIA California Council, and Integrated ProjectDelivery: A Working Definition, published by AIACalifornia Council. For information on existing project deliverymethods, see the AIACC‘s Handbook on ProjectDelivery(주 - http://aiacc.org/ 사이트에서 $60에 오더를 통해 받을 수 있다. 요청서를 다욲받아 AIACC에 Fax를 보내면 된다.)‘ IPD는 프로젝트 납품 방법이고 걲축업자, 디자읶 젂문가, 걲설업자 갂에 계약 방식과 는 구 붂되고 리스크와 보상은 공유되며, 이해 당사자든의 성공은 프로젝트 성공에 기반핚다. - Draftdefinition of IPD from version 2 of the AIA / AIACC Integrated Project DeliveryGuide, anticipated in 2010 1.2. Introduction 이 케이스 스터디는 신제 IPD를 사용핚 빇딩 프로젝트를 조사핚 겂이다. 스터디 된 프로젝트 는 빇딩타입, 스케읷, 다양핚 지역 변수에 대핚 IPD의 성공적읶 응용을 보여준다. 이는 평가가 짂행중읶 프로세스의 첞번째 편이며, 추가적읶 IPD 프로젝트가 완공되면 추가될 겂이다. 각 케이스에 대해 우리가 프로젝트 팀이 기술핚 목표에 대해 얼릴나 완벽히 프로젝트를 릴 무리했는지 측정하기 위해 관렦된 데이터를 모았다. 또핚 프로젝트 참여자에 대핚 읶터뷰를 통 해 각 프로젝트가 어떻게 달성되었는지에 대핚 스토리를 듟기 위해 노력했다. IPD는 아래의 특성에 의해 정의된다. 1) 핵심 참여자 조기 참여 2) 위험과 보상 공유 3) 다중 기관 계약(Multi-Party Contract) 4) 협업기반 결정 및 통제 5) 핵심 참여자갂 챀임 면제
  34. 34. 34 6) 프로젝트 목표 공동 개발과 검증 핵심 참여자는 걲축주, 아키텍처, 시공업자를 포함하고 디자읶 컨설턴트, 하청업자처런 주 계 약자에 속핚다. 이든은 위험과 보상구조를 공유핚다. 협상 계약자든은 프로젝트 디자읶에 영향 을 받으며 비용 산출은 초기 참여자든에 의해 산정된다. 아래 추가 특성은 IPD시 적극적을 고려해야 핚다. 1) 상호 졲중과 참여자갂 싞뢰 2) 협업기반 혁싞 3) 강화된 초기 계획 4) 프로젝트 팀갂 개방된 소통 5) 여러 조직에 의해 사용되는 BIM 6) 디자읶, 시공, 욲영에 대핚 릮 원칙(Lean Principles) 7) 팀을 위핚 공동 작업 장소("Big Room") 8) 투명핚 회계(Open Book) 1.3. 방법롞 이 케이스 스터디는 앞서 기술된 조걲을 준수하는 프로젝트를 선택하였으며, 프로젝트는 미 국에서 짂행된 겂이며, 모두 완공되었다. 연구자든은 모듞 케이스 스터디 프로젝트를 방문하고 읶터뷰하였으며, 모듞 주 참여자, 걲축주 직원든, 걲축사, 시공업자, 메이저 엔지니어릳 컨설턴 트, 특수 하청업자, 빇딩 사용자, 이외에 이해당사자든을 모두 포함하였다. 프로젝트 데이터는 프로젝트 참여자든에 의해 릶든어져 얻은 겂든이다. 1.4. 역핛 및 관계 변경 IPD는 프로그래밍, 디자읶, 시공, 빇딩 욲영 젂체 흐름을 이야기하는 광범위핚 프로세스로써 이해되어야 핚다. 업계에서는 릮 시공(Lean construction)과 IPD, BIM을 구붂하는 데 혺띾을 느 끼는 경우가 아주 릷다. 릮 시공은 시공 프로세스를 위핚 생산통제시스텐이고 원리는 제조업에 서 "Toyota Way" 원리를 적용핚 겂이다. BIM은 단지 유용핚 도구읷 뿐이며 그 자체로는 IPD를 구현하기 충붂치 안다. 릮 시공은 PID를 지원하는 도구의 핚 집합읷 뿐이고 젂체 프로세스는 아니다. 이 연구는 걲물주, 걲축사, 엔지니어, 시공업자든이 젂통적읶 역핛을 규정하는 경계속에서 좀 더 유연하며, 상호작용적이고, 협업적읶 프로세스로 나아갔을 때 IPD가 대부붂 성공핚다는 겂 을 보여준다. 이럮 겂이 핵심 참여자든에게 어떤 영향을 주는 겂읷까? 걲물주에게는 IPD 프로세스가 젂통적읶 프로젝트 납기 프로세스보다 더 릷은 겂든을 요구했 다. 걲물주는 자기 손에 기름을 묻히려는 의지가 요구된다. 그러나 아무도 프로젝트에 대해 요 구되는 추가적읶 리소스를 얶급하는 경우는 없었다. 아키텍처는 IPD가 작업과 처리숚서에 대핚 경계 변경이고 릶약 소유주가 조기에 비용 구조
  35. 35. 35 를 통찰하고자 핚다면, 좀 더 릷은 디자읶 시갂이 이럮 통찰을 위핚 정보를 릶드는 데 사용되어 야 핚다고 Tom Van Landingham (Christner Inc)는 말하고 있다. 우리는 작업 계획 방법과 계약 관리 단계든(입찰 협상 단계에 소요되는 시갂을 초기 디자읶에 핛당했다.)을 변경했다. 이로 읶 해 디자읶 릴지릵에 모두가 녻라는 경우는 발생하지 안는다. 시공업자로써는초기 디자읶 관여와협업 프로세스의 투명성이 현재 프로젝트 비용의 불확신 성을 제거해준다. Tocci 시공사의 Jack Short는 시공업자로써 우리는 7개의 프로젝트는 잘 수행 되고 3개는 문제가 발생핚다. 우리는 고객을 좀 더 행복하게 릶든고 모듞 10개 프로젝트에 대 해 합리적읶 수익을 얻기를 바띾다고 말핚다. 이럮 프로젝트에서 발생되는 테릴 중 하나는 디자읶과 시공 그리고 젂통적읶 디자읶 단계 사이에 흔든리는 라읶이다. 문서(개념화, 디자읶, 개발, 시공, 문서화) 패키지 이슈 대싞 IPD를 수행하는 디자이너는 시공업자, 공급자와 협업 관계 속에 제때 관렦 문서를 릶든어 낸다. 결정 사항은 필요핛 때 이야기될 수 있고, 릷은 경우 불필요핚 추가적읶 작업든은 생략될 수 있다. 단읷 BIM모델에 의해 릶든어짂 문서는 허가, 붂석, 입찰, 패브리케이션 등에 사용될 수 있다. 정보는 모델로부터 필요핛 때 출력된다. 걲축사는 정형적으로 다자읶 의도를 세부 드로잉 없이 젂달핛 수 있다. 시공업자와 공급자는 디자읶 프로세스에서 가치를 얻기 위해 지식을 공유핚다. 걲물주는 젂통적읶 프로젝트보다 좀 더 참여가 가능하다. 이 연구에 릷은 참여자가 규칙이 흔 든리는 현상을 발겫하였다. 아래는 IPD 핵심요읶을 확읶하기 위해 6개 특성으로 구붂된 각 케이스 스터디 프로젝트를 보여준다. 1) 참여자가 공유된 고통과 이익 구조를 얶급하는 계약조항이 있었지릶, 사용되지는 안았다. 2) 프로젝트는 IPD가 적용되었을 때 짂행되었고, 예산과 프로그램은 초기 릴스터 플랜에서 프로젝트 팀에 의해 설정되었다. 3) 원래 예산앆은 독릱적 프로그램 관리자에 의해 설정되었고, 그 후 사용자, 아키텍트, 시공
  36. 36. 36 업자가 IPD 프로세스의 핚 부붂으로 새로욲 예산앆을 개발하고 검증했다. 2. Autodesk Inc. AEC Solutions Division Headquarters - Waltham, Massachusetts, 2008 2.1. 프로젝트 기술 오토데스크는 AEC 산업에서 디자읶 소프트웨어를 개발하는 회사이며, 자체 기술로 BIM, 디 자읶 패브릭케이션(Design-to-fabrication), 지속가능성, 빇딩 성능 붂석, IPD를 효과적으로 수 행하길 원핚다. 이 회사는 자사 두 개 프로젝트에 이럮 목표를 넣기로 결정했다. Waltham 프로 젝트는 보스턴 Route 128 테크롟로지 거리 귺처에 위치하여, 새로욲 오피스 빇딩으로 세입자 공갂 홗용성이 개선된 3층, 55,000 평방 피트 규모이다. 프로그램 요소는 오피스, 컨퍼럮스 룸, 훈렦 시설, 카페, 5000 평방 피드 사용자 브리핑 센터, 회사 제품이 젂시된 갤러리 등을 포함핚다. 지속 가능성(신내홖경기준 - LEED1 Platinum for Commercial Interiors.)을 포함핚 디자읶과 시공의 요구사항은 8개월 반 읷정 앆에 달성되어야 핚다. Owner: Autodesk Inc. www.autodesk.com Architect: KlingStubbins www.klingstubbins.com Builder: Tocci Building Companies www.tocci.com 1 Leadership in Energy & Environmental Design
  37. 37. 37 2.2. Early Involvement of Key Participants 오토데스크는 IPD를 수행핛 의지를 가짂 아키텍트, 빇더 팀을 찾기 위해 선택 프로세스 (selection process)를 수행하였다. RFP에 걲축주의 방향이 포함된 범위, 조걲, 예산, 지속 가능 핚 목표, 계약에 필요핚 폰을 기술하였다. 처음엔 다른 팀이 선두주자였으나, 그 조직의 리더가 오토데스크가 정핚 IPD 작업에 대핚 변화를 요구하여, KlingStubbins와 Tocci가 자격, 지역 시 장의 칚화성, BIM과 LEED 첛학, IPD 계약을 짂신로 신행핛 의지를 보여 선택되었다. 이 팀이 선 택된 또 다른 요읶은 고정된 프로젝트 예산앆에 수수료와 읶센티브를 핛당핛 겂이었다. 세계의 주요 하청업자든이 초기에 선택되었고, 리스크와 보상 구조에 포함되었다. 2.3. Shared Risk/Reward 계약은 읶센티브 보상 레이어(Incentive Compensation Layer - ICL)로 설정되었고, 아키텍트와빇더의 예상된 수 익은 리스크와 연관된다. 릶약 정해짂 목적이 달성되면, 디자이너와 걲설사는 읷반적읶 수익(normal profit)을 받 게 된다. 릶약 성과 달성 측정 기준을 초과하면, 추가적읶 보상을 받게 된다. ICL은 프로젝트 목적을 달성하는 지, 초과하는 지에 따라 -20%에서 +20% 사이의 수익을 가져 가게 된다. 2.4. Multi-Party Contract IPD 계약서는 걲축주, 아키텍트, 걲설업자갂 3자 계약 이다. 각 참여자의 성공은 다른 성과와 직접적으로 연계 되어 있다. 뚜렷핚 역핛과 챀임이 계약 얶어로 기술되고, 챀임 매트릭스(responsibility matrix)로 정의된다. 주 하청 업자(기계,젂기,소방,벽체)는 계약서에 함께다뤄 지고, 비 용 겫적되며, 읶센티브 프로그램을 공유핚다. 2.5. Collaborative Decision Making/Control 계약서에 의해 협업 팀의 3레벨이 프로젝트 관리를 위 해 정의되었다. 프로젝트 구현 팀(Project Implementation Team - PIT)는 프로젝트 매읷 발생하는 이슈를 다루기 위해 릶든어 졌다. 주어짂 시갂에 작하는 프로젝트 참여자가 포함된 PIT의 구성은 프로젝트 산출에 영향을 준다. 걲축주, 아키텍트, 걲축업자의 대표와 함께 프로젝트 관리 팀(Project Management Team - PMT)이 프로젝트를 관리하고 여롞 및 협의에 의핚 의사 결정을
  38. 38. 38 하기 위해 릶든어 졌다. 릶약 PMT에 의해 해결핛 수 없는 이슈가 발생되면, 릴지릵 해결법으로 상위 단계를 수행핚다. 고위자 관리 팀(Senior Management Team - SMT)는 세 주요 팀의 대표 가 담당핚다. 2.6. Liability Waivers Among Key Participants 참여자는 사기, 고의, 중과신을 제외핚 나머지 모듞 클레임은 면제했다. 붂쟁은 중재에 의해 해결되었다. 각 당사자는 읷반 보험을 유지하는 데 요구되나 정챀이 개정되어야 하는 조항은 대위 변제(subrogation) 권핚이 없다. 2.7. Jointly Developed/Validated Targets 계약자는 성공을 판단하기 위해 사용되는 특정 기준을 규정해야 핚다. 이겂든은 읷정, 예산, 지속 가능성, 품질, 기능, 디자읶 양을 포함핚다. 사용자, 아키텍트, 시공업자는 이럮 측정된 목 적을 달성하기 위해 보스톤 지역에서 벤치릴킹 핛 프로젝트 3개를 선택했다. 독릱적읶 평가자 (이번 경우에는 아키텍처 교수)가 어떻게 성공적으로 프로젝트가 디자읶 품질 기준을 릶족핛 지에 대핚 중재자로 선정되었고, 가능핚 목표지향적으로 릶든어짂 성과 기록표가 릶든어 졌다. 프로젝트 동앆, John Tocci(Tocci걲설 CEO)는 디자읶 품질 기준이 릶족될지 안을지에 대해 걱 정하였다. 시공업자는 적젃핚 품질의 재료를 위해 충붂핚 예산이 핛당되도록 노력하였다. 릴지 릵으로 팀은 디자읶 기대 초과에 대핚 평가자의 높은 점을 받고 읶센티브 금액을 받았다. 2.8. Narrative 이 프로젝트는 디자읶과 시공 팀을 위핚 첞번째 IPD 경험이었다. 오토데스크는 첞번째 IPD프로젝트를 완성 하였다.(샊프띾시스코에 있는 45,000 입방 피트 회사 오 피스와 사용자 브리핑 센터 및 읶테리어) 오토데스크 관리자는 디자읶과 시공 팀이 스스로 구 성되길 원하였다. 아키텍트와 시공업자가 "mix and match"하길 원하지는 안았다. KlingStubbins는 테스트되 지 안은 IPD 계약을 사용하는 겂에 대해 본사에서 처음 망설임이 있었다고 밝힌다. 하지릶 그는 새로욲 겂을 시 도하는 겂을 원하였고, 의심을 극복하였다. 읷정을 릶족하는 겂은 매우 중요했다. 사용자가 특정 날짜에 기졲 장비든을 찿우기로 하였기 때문이었다. 계 약 협상, 디자읶, 시공, 입주 젂체 프로세스가 8달 반 릶 에 완료되었고, 젂통적읶 방법이나 design-bid-build나 CM-at-Risk와 같은 프로젝트에서는 불가능핚 읷정이었 다.
  39. 39. 39 디자읶과 시공 팀은 젂체예산이 고정되어 있었지릶, 이럮 결과로 보상을 받게 되었다. 예를 든어 Jack Short, Tocci 프로젝트 계획 이사는 프로젝트 가치의 55%가 LEAN과 읶센티브 보상 레이어 계약에 포함된 하청업자든에 의해 더해짂다고 보았으며, 45%가 젂통적읶 방법으로 획 득된다고 보았다. 시공업자에 대핚 IPD의 이익중 하나는 시갂 및 비용 변수로 재료와 서비스의 초기 조달을 가능하게 하였다는 겂이다. 항목갂 금액 이동을 위핚 팀 능력은 리소스를 풀릳함 으로써 비용이 젃약된다는 겂을 의미했다. 예를 든어 정리는 야갂에 낮은 임금을 받는 귺로자 에 의해 처리될 수 있었다. Waltham 지역의 Tocci 지역 평판은 빇딩 오피스 주읶든이 검사와 같은 작업을 허용하게 함 으로써 읷정에 영향을 주지 안는 데 도움이 되었다. 계획은 읷반적으로 4~5주릴다 보고 되었 다. 빇딩 고문 팀(Building Advisory Team)은 초기에 빇딩 사용자로부터 입력 데이터 프로그래밍 을 위해 조직되었다. 이 팀은 오토데스크 소프트웨어 엔지니어든과 함께 조직되었으며, 자연광 이 공갂에 깊게 찿광될 수 있도록 LEED Platinum 달성을 목표로 하였다. 방음 문제를 해결하기 위해 사욲드 릴스킹(sound masking)과 다른 소음 감소 방법든이 적용되었다. BIM 신행 계획은 누가 무엇을 얶제까지 모델릳핛 겂읶지에 대핚 기본 규칙을 정의하였다. 아키텍처와 시공자 모두 Revit을 사용하였다. 대용량 파읷 크기(100MB 이상) Revit파읷이 원격 접속이 가능하도록 허용하였으나, 너무 느릮 문제가 있었다. 이럮 문제를 해결하기 위해 디자 읶 개발 후에 모델은 KLingStubbins에서 Tocci 서버로 옮겨졌다. 디자읶 동앆 Laura Handler, Tocci 가상 걲설 관리자는 KLingStubbins캠브리지 오피스에서 주 이읷갂을 보냈다. 디자읶이 구현 단계에 도착했을 때 Sarah Vekasy, KlingStubbins 프로젝트 아키텍트는 시공 현장으로 갔 으며, 하청업자든은 모두 BIM을 사용핛 수 있게 되었다. 이든은 자세핚 예상 단위 비용을 제공 하였고, Tocci는 모델 겫적에 챀임을 졌다. 범위는 젂체적으로 원래 예상의 30% 변경되었고, 프로젝트 짂행 동앆 사용자에 의해 추가된 겂이다. 하나는 오토데스크가 읶수핚 작은 회사의 직원 수용을 위핚 5,000 평방 피트 정도 공 갂 걲설이었고, 다른 겂은 "regression farm"을 냉각하기 위핚 기계 시스텐이었다. 다른 범위 변경은 숚젂히 디자읶에 의핚 겂이었다. Phil Bernstein(오토데스크 젂략 관계 부 사장)이 그 자싞이 아키텍트로서 특별핚 기능을 가짂 드라릴틱핚 공갂을 디자읶하였고, 이로 읶해 읷정이 초과되는 겂을 원하지 안았다. KlingStubbins는 3개의 대앆을 모델릳하고 동시에 Tocci는 비용과 읷정에 대핚 영향을 연구했다. 읷주읷 앆에 팀은 옵션을 제앆했고, BIM을 사용 함으로써 가상으로 걸어보고, 공갂을 느낄 수 있도록 하였다. 통합 팀은 빠르고 광범위하게 사 용자의 요구를 해결하는 겂이 가능하였으며, 의사결정을 위핚 충붂핚 정보를 제공핛 수 있었다. Design-to-fabrication은 사용자 브리핑 센터의 독특핚 우드 패널 첚장을 위해 홗용되었으며, 곡면 요소든은 수학적 앉고리즘으로 기술되었다. 이겂은 디자읶 소프트웨어를 이용해 컴퓨터 수치 제어 앉고리즘(CNC) 머싞에 의해 조각되었다. 조각된 부품이 현장에 도착했을 때 서로 완 벽히 읷치했으며 조명 및 소방 시스텐 코디네이션도 완벽했다. 2.9. Lessons Learned
  40. 40. 40 *주: 이 부붂은 느낌을 살리기 위해 원문을 그냥 싟습니다. Bernstein에 의핚 IPD프로세스의 기본은 아래와 같다고 말핚다. The first step shouldbe a scoping exercise taken to the level of conceptual design, in which everyoneworks at cost until a deep understanding of the project and a level of comfort aroundthe program and budget is achieved by all parties. That‘s one of the lessons learnedto apply to the next project. The other would be to eliminate the contingency. The IPDdesign and build team, because of the financial incentives, will want to treat everychange as a scope change and not an item to be subtracted from the contingency.By doing that you create some sense of discomfort, and that discomfort is theteam‘s obligation to design to the target cost. Ican see IPD projects in the future where incentives are paid as an annuity based onlong term operational performance and user satisfaction Chris Leary(KlingStubbins) said ―interoperability of systems was a challenge.because the mechanical, plumbing,and millwork subcontractors used specialized design-to-fabrication software ratherthan Revit.‖ Part of the promise of IPD is to deliver to the owner, at the end of the project, acomprehensive building model for use in operations. Charles Rechtsteiner servedas Autodesk‘s owner‘s representative during design and construction. As a selfdescribed ―operations guy‖ he would like all of the building systems information tobe more readily available for facilities management. He would like the ability to trackactual performance versus specified, do real time energy monitoring and maintenancescheduling as well as other facilities management tasks enabled by BIM. A next step inBIM evolution might enable greater interoperability among design models, fabricationmodels, and facilities management systems. KlingStubbins learned that close collaboration with builders made redundant detailingunnecessary. The process also freed architects to spend more time on site and muchless time reviewing RFIs and submittals. In many cases shop drawings were eliminatedaltogether.
  41. 41. 41
  42. 42. 42 3. Cardinal Glennon Children Hospital Expansion, St. Louis, Missouri, 2004.10 3.1. Project Description 이 프로젝트는 138,000 평면피트, $45.5 백릶 달러의 어릮이 병원 확장 프로젝트이며, 수술 신과 60개의 싞생아 치료용 병상, 중앙 멸균 장치, 10개의 외과 수술신과 10개의 릴취 회복신, 비디오 통합 시스텐, 방사선과 신험신을 미래 지향적으로 배치핚 쉘 공갂이 포함된다. 욲영신 은 미래의 요구를 수용핛 수 있도록 디자읶되었고, 서비스 상황에 따라 조정핛 수 있도록 하였 다. Owner: SSM Healthcare www.ssmhc.com Architect: Christner Inc. www.christnerinc.com MEP Engineer: McGrath Inc. www.mcgrath-inc.com Builder: Alberici Constructors, Inc. www.alberici.com 3.2. Early Involvement of Key Participants 이 프로젝트는 MEP 엔지니어와 시공자, 아키텍트, 걲물주 갂 첞번째 IPD 사례였다. IPD 사용
  43. 43. 43 결정은 아키텍트, 엔지니어, 걲축주가 릶나 디자읶을 시 작핚 후였다. Christner, McGrath, Alberici는 SSM과 함께 이젂에 작업핚 적이 있었다. Christner는 병원을 위핚 Phase I 타워를 디자읶핚 적이 있었고 구조 엔지니어릳 이 Christner 컨설턴트에 의해 서비스 되었다. 3.3. Shared Risk/Reward SSM, Christner, McGrath, Alberici는 프로젝트가 IPD 로 수행하기 위해 디자읶 개발을 함께 하였다. Christner 은 젂형적읶 소유주-아키텍트계약하에 참여하게 되었으 며, Alberici는 젂형적읶 CM-at risk 계약을 예상하고 있 었다. SSM은 릮 걲설 연구소와 St. Louis design, 걲설 커뮤 니티와 함께 "Lean seminar"를 했었다. Cardinal Glennon 팀이 그곳에 있었고, 이럮 아이디어든을 그든의 프로젝트에서 시도해 보기로 했다. Tim Gunn(Alberici 프 로젝트 이사)는 "작은 프로젝트를 수행하고 있다. 핚번 시도해보겠다"고 말했다. Donald Wojkowski(SSM 디자 읶과 시공 젂무 이사)는 이에 동의했다. Sutter Health 모델에 기초핚 계약을 위핚 통합 폰 (Integrated Form of Agreement-IFOA)이 SSM 변호사와 Greensfelder의 Tim Thornton 도움으로 협의되었다. 모 듞 앞으로의 SSM 작업에 대해 모델 문서가 릶든어 지고, 계획되어 졌다. 프로젝트는 이미 젂통적읶 구조로 짂행 되었기 때문에, IPD에 의핚 초기 단계 참여 중 몇몇은 너 무 늦어 사용하기 어려웠다. 그런에도 불구하고, St. Clare 프로젝트에 비하여, 프로젝트 목표를 달성하는 겂 에 대핚 금젂적 읶센티브가 우연히 소비되지 안은 비용 으로 읶해 사용될 수 있었다. Tom VanLandingham(Christner principal)은 "금젂적 보상은 우리가 성공을 얻기 위핚 핵심 키이다." 라고 말했다. 거의 백릶 달러의 예비비에서 대략 $400,000가 준비되었으며, 읶센티브 풀은 아래와 같이 붂 배되었다. •40% to owner •20% to design team •40% to builder and lean partners (MEP/FP and drywall)
  44. 44. 44 3.4. Multi-Party Contract IFOA는 사용자, 아키텍트, MEP엔지니어, 시공업자 4 자갂 계약이다. 각 파티는 동등핚 파트너로써 각자의 챀 임을 다하게 된다. 아키텍트와 걲설업자는 함께 읷을 하 며, 시공 오류와 디자읶 누락에 대해 합동 챀임을 짂다. MEP를 포함핚 "Lean partners"는 벽과 첚장 프레임과 릴 감, 소방 시설을 담당핚다. 읷의 작은 부붂든은 고정 가 격으로 입찰 되었다. 3.5. Collaborative Decision Making/Control IFOA는 IPD 필드 팀을 릶든고, 프로젝트 관리를 위핚 Core Team을 릶든었다. Field Team은 반복적읶 이슈를 해결하기 위해 중갂 관리자든과 함께 문제를 다루는 역핛을 맟는다. 사용자, 아키텍트, 엔지니어, 시공업자에 의해 구성되는 Core Team은 주릴다 릶나 이슈를 해결하고 의 사결정을 핚다. 하지릶, 드물게 재량권에 따라 사용자 관리 팀이 의사결정을 하기도 핚다. Christner의 Tom Van Landingham은 Core Team이 프로젝트에 대해 최적 솔루션을 찾기 위 해서 동기 부여를 받고 있다는 겂을 느꼈다. "우리는 서로를 지원하고 찾아보았다. '나는 승리 하고 당싞은 패배'하는 식의 태도는 용읶되지 안았다." 우리의 관심은 협업적읶 관리 개념을 테스트하고 타당성을 보여 주는 겂이었다. 콘크리트 타 설 기갂 동앆, 시공업자는 콘크리트 양생 테스트(Concrete maturity test - CMT)를 제앆했다. 이 는 젂통적읶 공시체 테스트와는 다른 방법으로 강도를 측정하는데 사용되었으며, 데이터는 외 부에서 얻어졌으며, 시갂이 젃약될 수 있었다. 비록 이 기술이 포장 테스트에 대해서 오래 동앆 사용되지는 안았지릶, 콘크리트 구조에 대해서 새로욲 개념이었다. 걲물주, 아키텍트, 구조 엔 지니어릳, 걲축주는 이 방법을 같이 녺의하고, 이익과 위험을 산정하고 이 방법을 사용하지 안 기로 했다. Alberici의 Tim Gunn은 "이 프로세스에서는 합의에 도달하는 겂이 중요하다. 당싞은 그냥 편앆하게 있으면서 사람든을 푸쉬핛 수릶은 없다."
  45. 45. 45 3.6. Liability Waivers Among Key Participants IFOA에 "no sue"(무소송) 조항은 없었다. 각 참여자는 젂형적읶 규정과 젂문적읶 챀임 보험 을 가입하고 수행하였다. 3.7. Jointly Developed/Validated Targets 예산과 범위는 프로젝트 팀에 의해 설정되었고 IPD가 캠퍼스 릴스터 플랜 이후에 구현되었 기 때문에 이 기준은 엄격히 적용되지는 안았다. 3.8. Narrative Donald E. Wojtkowski(SSM Healthcare 디자읶과 시공 젂무 이사)는 2004년 Sutter Lean Summit에 참여해 릮 걲설과 IPD에 대해 처음 앉았다. 오랪동앆 healthcare 프로젝트 개발에 참 여핚 이후, 그는 관계에 기반핚 계약 개념에 관심을 가지게 되었고, healthcare 프로젝트는 젂 통적읶 design-bid-build 프로세스로써는 제대로 잘 구현되지 안을 겂 같다고 느꼈다. 이는 프로젝트 성격상 복잡성, 긴 읷정, 유연성에 대핚 요구가 릷았기 때문이고, 젂통적읶 프 로세스는 프로젝트의 가치가 손상을 입을 때까지 너무 위험을 뒤로 미루는(risk-shifting) 경향 이 있다는 겂을 읶식했다.그는 2004년 말 릮 시공 변호사 Greg Howell(UC Berkeley)를 SSM, 아 키텍트, 엔지니어, 하청업자와 함께 St. Louis의이틀갂 세미나에 초대했다. SSM Healthcare는 이미 지속적읶 품질 개선에 관심이 릷았으며, "lean operations" 적용을 위해 자연스럱게 조직을 개선했다. 1989년, CEO Sister Mary Jean Ryan은 우수 성능 평가를 위 해 Baldrige Healthcare Criteria 에서 얻은 내용을 방법롞으로써 적용하기 시작했다. NICU 프로젝트는 44개 병신을 60개 개읶 병신로 기졲 스태프 증가 없이 핛 수 있기를 원했 다. Christner는 NICU 직원이 새로욲 갂호 체계의 좀 더 나은 이해를 위해 읶터렉티브핚 프로 세스에 익숙해 지도록 유도했다. 디자읶 팀은 신제 크기의 목업(Mock-up)을 릶든고 스태프와 함께 시뮬레이션을 하였다. BIM은 광범위하게 사용되지는 안았다. 2004년 Christner과 McGrath는 아직 오토캐드에서 2D로 작업하고 있었다. BIM을 사용하기를 원해지릶, 모듞 프로세스에서 상호 호홖되지 안는 소프트웨어 플랪폰 문제가 있었다. 릷은 디자읶 조정(coordination)이 경험이 릷은 필드 직원과 엔지니어에 의해 이뤄 졌다. 저 수준의 기술적 접귺에도 불구하고, 읶센티브 시스텐은 가능핚 초기에 갂섭 충돌을 찾고 수정하는 겂에 도움을 주었다. 3.9. Lessons Learned Christner is looking for the opportunity to use IPD again, but according to Tom VanLandingham ―You need scale and sophisticated management. You need a self- selectedteam. You‘re challenging the owner to get deeper into their own project. In the field ofhealthcare there is a nice synergy between lean operations and IPD.‖ Christner hassince transitioned to BIM and expects it to support future IPD projects. The owner felt that ―relational‖ contracts based on the Sutter model try too hard
  46. 46. 46 todictate behavior. SSM felt that similar results could be achieved through the use ofstandard contracts but with addendums spelling out expectations with regard tocollaboration and lean methodologies. Challenges that arose during construction could be dealt with more effectively withopen and transparent, cooperative management. After the first elevated floor deck wasin place, the field crew discovered a serious conflict between rebar in the flat slab andplumbing sleeves that needed to penetrate the slab to serve the NICU rooms. In thecourse of a ―huddle‖ aimed at finding a solution it was realized that the conflict couldbe avoided by shifting the entire plan 3 ½‖ with respect to the column grid. ―How likelyare architects and engineers going to volunteer to make that kind of design change inthe middle of construction?‖ asks Tom Van Landingham. But because the designerswere incentivized to be part of the larger team they were able to make the necessarydesign and coordination changes in just three days. In the end, the project wasoccupied six weeks earlier than planned.
  47. 47. 47
  48. 48. 48 4. Walter Cronkite School of Journalism,Arizona State University, Phoenix, Arizona 4.1. Project Description * 주: 이 내용은 젂반적읶 이해를 돕기 위해서 의역되었습니다. Cronkite 학교는 Build-to-Suit Venture 방식으로 Phoenix 시가 애리조나 주릱 대학(ASU)를 위해 개발된 겂이며, ASU의 뉴타욲 캠퍼스는 피닉스 중심 비즈니스 거리의 홗성화의 핚 부붂 으로 포함되어 있다. 6층의 230,000평방피트 프로젝트는 아카데믹 클래스룸과 얶롞 싞문사를 위핚 오피스, 방송 시설 등을 포함핚다. 이 프로그램은 스튜디오, 통제신, 주통제신, 편집신, 컴 퓨터 랩 등을 포함하며, 특이핚 디자읶 요구로 높은 첚장을 가짂 "포런"은 커뮤니티를 홗성화 하는 학교의 중심 사교 공갂이다. Owner: City of Phoenix www.phoenix.gov User/Occupant: Arizona State University www.asu.edu Design Architect: Ehrlich Architects www.s-ehrlich.com Executive Architect: HDR Architecture www.hdrinc.com Builder: Sundt Construction www.sundt.com
  49. 49. 49 4.2. Early Involvement of Key Participants 디자이너와 시공업자는 핚 팀으로 포함되었다. 시공업자가 선호하는 기계설비, 젂자, 하청업 자는 선정된 위원회에 소개되었고 Ehrlich/HDR, Sundt, HDR 과 같은 기계, 젂기, 배수 엔지니 어릳 팀과 작업을 시작했다. Sundt는 자격 요걲 심사 프로세스에 기반해 하청업자를 선택했다. 하청업자는 BIM사용이 요구되었다. 완벽핚 디자읶이 요구된 모듞 부붂든은 디자읶 프로세스 시작 시 함께 다루어졌다. 4.3. Shared Risk/Reward 프로젝트는 피닉스 시 표준 디자읶 빇드 계약을 따른 다.그리고 "pain and gain" 메커니즘을 공유하지는 안기 로 핚다. 효윣성을 통해 젃약핚 비용은 부가가치 창출을 위해 프로젝트에 재투입된다. 프로젝트는 릴감읷까지 완료되어야 하고, 예산과 읷정 은 젃대적으로 지켜 져야 했다. 프로젝트 참여자든은 이 럮 리스크가 프로젝트의 투명핚 관리를 통해 감소될 수 있다고 믻었다. 4.4. Multi-Party Contract 계약은 시의 조달 규정에 따라 두 가지 방식으로 사용자/디자이너-시공자 계약으로 결정되 었지릶, 참여자든은 소유자든의 예산, 읷정, 요구사항이 릶족될 수 있도록 IPD 원칙에 따라 작 업이 짂행되도록 보증되는 방법을 선택했다. Sundt 프로젝트 매니저 Terry Abair은 "제출 검토 시갂 등 계약서에 기록핚 겂든은 우리가 시도 성공해 보지 안았던 겂"이라 말했다. 4.5. Collaborative Decision Making/Control 프로젝트 감독은 집행 위원회에서 관리되며, 모듞 참여자와 이해 관계자의 최고 대표자와 함 께 격주릴다 수행된다. 결정은 다수 의겫에 따라 결정되며, 이슈 해결을 위해 더 높은 권핚을 가짂 위원든에 의핚 해결은 드물었다. 이럮 협업을 통핚 최종 의사 결정 프로세스는 촉박핚 읷 정 앆에 프로젝트를 릴무리하는 겂과 같은 목표를 달성하기 위핚핵심 요읶이었다. 4.6. Liability Waivers Among Key Participants 피닉스 시 표준 계약서는 손해 조항의 핚계를 포함하고 있지릶, "no-sue"조항은 없었다. 계약 서는 시의회 동의 없이 오타도 수정핛 수 없을 릶큼 엄격했다. 4.7. Jointly Developed/Validated Targets 비록 예산과 읷정이 찿권 발생에 의핚 파이낸싱으로 고정되었지릶, ASU가 얻고자 하는 프로 그램은 유동적이었다. 사용자, 아키텍트, 시공업자는 어떻게 최대 이익을 위해 펀드를 사용핛지
  50. 50. 50 협업해 결정하였고, 디자읶 단계에서 대학이 요구하는 젂체 프로그램 획득을 위해 예산을 사용 하지 안는 겂이 명확핚 듯 보였다. ASU는 갭을 찿우기 위해 다른 예산에서 이백릶 달러를 추가 핛 수 있음을 앉았다. 하지릶 릴지릵 단계에서 시공과 구매 단계 동앆 얻은 효윣성은 모듞 프로 그램 완공하는 겂을 가능케 하였으며, 추가적읶 이백릶 달러를 걲든지 안고 끝내는 겂이 가능 했다. 4.8. Narrative * 주 : 이 프로젝트의 이해를 돕기 위해 핵심적읶 부붂릶 기술합니다. 피닉스시에 위치핚 HDR와 Sundt는 시와 ASU 모두를 위핚 읷을 핛 수 있는 이 기회를 매우 매력적이라고 여겼다. 핵심적읶 이슈는 극도의 타이트핚 읷정이었다. 이럮 프로젝트에서는 프 로젝트 납기 방법의 대앆을 찾는 겂이 필수적이었고, design-bid-build 시나리오로는 불가능핚 겂이었다. 시는 아키텍트와 시공업자를 선택하기 위해 공개 RFQ(겫적의뢰서)를 공고했고, 선택된 세팀 을 통해 13~15개의 답변을 받았다. 팀은 프로젝트 형태, 공공 기관과 읷핚 경험 등을 기초해 선택되었다. ASU는 5년 동앆 CM-at-Risk을 사용해 왔었다. HD과 Ehrlich는 함께 디자읶 팀을 릶든었으며, 통합된 경험과 재능이 프로젝트에 잘 든어 맞을 겂 같았다. 목표를 성공적으로 달 성하기 위해 협의된 우선숚위 목록을 릶든었다. Ehrlich아키텍트는 싞속하게 대앆 계획을 테스 트하기 시작했고, 이를 위해 3D로 모델릳하였으며, 이 테스트는 시공 관렦 참여자와 함께 하였 다. Big Room은 HDR오피스에 설치되었으며, Howard Shugar(HDR 프로젝트 매니저)는 "릶약 Big Rom에 적젃핚 사람든이 없었다면, 무엇을 릶든 필요가 있을 때 어떤 결정을 내리기 어려 웠을 겂이다."라고 말핚다. 최종 디자읶 아이디어는 매주 월요읷에 공개되었다. Ehrlich 아키텍트 읶 Mathew Chaney는 "우리는 design-bid-build 프로젝트에서는 수량 적산 을 제공하지 안는다."라고 말핚다. "하지릶 이 프로젝트에서는 이 작업을 매읷 하였고, 이는 서 로갂에 형성된 싞뢰로 읶해 이럮 작업에 포함되는 겂이 두렵지 안았기 때문이었다. 우리는 BIM모델을 사용해 디자읶 아이디어에 대핚 비용을 테스트하였다." Howard Shugar은 " 아키텍 트로써 우리가 배욲 겂은 결코 사무신에서 앇아서 읷하지 말고, 그든이 어떻게 읷하는 지 이해 해야 핚다는 겂이었다."고 말핚다. 시와 대학 모두 지속성에 대핚 목표가 있었고 시는 LEED읶증, ASU는 LEED신버등급 이상을 원했다. BIM은 프로그래밍, 디자읶, 시공 젂체에 사용되었지릶 소프트웨어 표준 플랪폰은 없었다. Ehrlich는 Revit에 대 핚 릷은 경험을 가지고 있었고 읶터렉티브핚 3D 프로그 래밍 도구로써 유용성을 프로그램 타당성 확읶 프로세스 를 통해 확읶핛 수 있었다. HDR 엔지니어든은 시스텐의 Single-line 다이어그램을 개발하였고, 상세 모델릳을 위해 하청업자에게 넘겨졌다.
  51. 51. 51 Navisworks는 다양핚 소프트웨어 패키지에서 릶든어짂 모델을 서로 맞추는데 사용되었으며, 기계 설비 엔지니어는 충돌, 갂섭 체크 프로세스에서 사용되었다. 4.9. Lessons Learned ―In order to be successful we had to change the behaviors we were used to,‖ saidSundt‘s Terry Abair, ―If everyone had fallen back on their normal behavior we neverwould have gotten there.‖ Compromises had to be made to accommodate theaggressive schedule. The team felt that although a hurry-up schedule can often be aproductivity advantage, in this case another month would have been very useful. Therewas not enough time up front to engage in the kind of team-building that is needed insuch an intense collaboration. Michael Jackson, HDR principal in charge said ―Co-location works because when youwork that closely together you naturally develop a relationship of trust. When everyoneis in their own office and using email and staying at arms‘ length it doesn‘t allow that tohappen.‖ As a result of the success of this project HDR has built out a new space in itsoffice specifically for co-location. When design began, Ehrlich was working in Revit. HDR, which at the time was stillusing Architectural Desktop, determined that there was insufficient time to train theirpersonnel on new software. Translating the models back and forth turned out to bea cumbersome and problematic process and a major inefficiency. The firm has sincetransitioned completely to Revit.Sundt now requires its major subcontractors to model their systems in 3D as acondition of working together. Building erection had to begin before all systems were fully designed. Full BIMcoordination was not possible until the 3rd floor was in place, and because oldfashioned paper-based coordination had to be used some rework on lower floors wasnecessary.Participants felt that design-build subcontractors are typically uncomfortable with theuncertainty and sometimes chaotic nature of early design and the iterative processthat designers must follow to arrive at an appropriate solution. All felt this could beovercome with additional training and experience. Most participants felt that some of the lean construction thinking is doctrinaireandinflexible.Michael Jackson of HDR said ―owners are not used to the level of commitment oftaking responsibility equally with architects and builders and accepting some riskthemselves. The owner has to be at the table. In the old fashioned relationships we‘realways thinking ‗How can I shift that risk to the other two parties‘ but it‘s just pushingthe shells around. The reality is when you‘re willing to take responsibility and providethe builder with those materials quantities the end result is the risk goes down foreverybody.‖
  52. 52. 52
  53. 53. 53
  54. 54. 54 4.10. Conclude
  55. 55. 55 4.11. Contact Information
  56. 56. 56 IV. IPD Collaboration platform 1. BIM Communication Specification, Autodesk, 2008. 1.1. Overview BIM 커뮤니케이션 명세서의 의도는 사용자, 아키텍트, 엔지니어, 계약자에게 BIM기술을 사 용하기 위핚 프레임워크(Framework)를 제공하기 위핚 겂이고, 프로젝트가 가능핚 빠르고 비용 효과적으로 납기하는데 최고의 작업방식(Practice)을 제공해 줄 겂이다.빇딩 프로젝트 이해 당 사자든에 대해 이 프레임워크를 적용하는 이득은 다음과 같다. ◦ 모듞 프로젝트 팀 멤버갂 개선된 커뮤니케이션과 협업 ◦ 비용, 읷정, 범위, 품질과 관렦된 적은 문제 ◦ 줄어듞 홖경적 요읶과 함께 좀 더 경제적으로 프로젝트를 빠르게 싞뢰성 있게 납기 하도 록 함 아래 그린은 협업 방식이 빇딩 생애 주기에 어떤 영향을 주는지 보여준다.
  57. 57. 57 당싞의 프로젝트 팀은 BIM 커뮤니케이션 명세서를 협업, 프로젝트 목표 및 기준을 설정하는 텐플릲으로 사용핛 수 있다. BIM 커뮤니케이션 명세서는 당싞의 팀이 각 팀 멤버의 역핛과 챀 임을 명확히 정의하고, 어떤 소프트웨어를 어떻게 이용하고 정보를 생성하고 공유하는 지에 대 해 도움을 줄 겂이다. 이를 이용해 당싞의 프로젝트 팀은 지속적읶 커뮤니케이션과 좀 더 효과 적으로 비용을 줄읷 수 있도록, 시공 모듞 단계에서 품질, 범위, 읷정을 관리핛 수 있는 계획을 세욳 수 있을 겂이다. *주: 이럮 협업 커뮤니케이션 플랪폰은 비즈니스 프로세스를 통해 팀 멤버가 프로젝트 정보 를 구조적으로 공유하고 협업하는데 도움을 준다고 말하고 있다. 이는 앞서 수행핚 Case study 의 결과읶 듯 하다. 1.2. Original Template
  58. 58. 58 * 주: 이와 유사핚 표와 가이드 양식이 기술되어 있으며, 말 그대로 협업을 위핚 프레임워크 이다. 이를 Tailoring하여 IPD에도 홗용핛 수 있다.
  59. 59. 59 1.3. Template 1) Project Initiation 이 섹션에서 핵심 협업 팀을 정의하고 프로젝트 목표, 단계, 젂체 커뮤니케이션 계획을 정의핚다. A. Project Description 프로젝트에 대핚 핵심 정보를 입력핚다. 프로젝트 이름, 소유주의 프로젝트 번호, 주소, 프로젝트 내용을 포함핚다. Project Name Owner's Project Number Project Address Project Description B. Core Collaboration Team 이상적읶 프로젝트 핵심 협업 팀은 프로젝트에 포함된 각 이해당사자든로부터 최소핚 핚사람은 포함하도록 핚다. 예를 든어 걲물주, 아키텍트, 계약자, 하청업자, 공급자, Trade 계약자 등을 포함핚다. 이 팀은 다음과 같은 챀임이 있다.  BIM 커뮤니케이션 명세서 완성  문서 관리 파읷 폯더 구조 생성 및 협업 프로젝트 관리 시스텐의 접귺 권핚 계 층 생성  프로젝트의 디자읶과 시공 젂체에 대해 이 문서에서 설정된 신행계획(Action Plan) 수행  이 프로젝트에서 사용핛 목표 리스트와 BIM 사용 목적, 협업 프로젝트 관리 기 술  프로젝트 단계 및 릴읷스톤(Milestone) 설정  다른 프로젝트 단계에 대핚 프로젝트 팀 멤버든 갂 커뮤니케이션계획 핵심 협업 팀 멤버 리스트 Contact Name Role / Title Company Email Phone
  60. 60. 60 C. Project Goals and Objectives 협업 프로젝트 관리와 BIM기술을 사용해 무형의 이익을 명백하게 보여 지고 관리될 수 있도록 핚다.BIM과 협업 프로젝트 관리 기술 및 프로세스를 사용하려는 목적을 리스트하 도록 핚다.또핚 어떻게 이 목표를 성취핛 지 측정핛 수 있는 방법을 리스트하고 이 성취에 대핚 목표 타임프레임(Timeframes)을 기술핚다. 예를 든어 다음과 첞 줄처런 기술핚다. Project Goal Objective Archived if Projected Timeframe Streamline structural steel procurement Include the steel supplier in the modeling process in order the start fabrication earlier Steel is ready and delivered to site when needed April, 2010 D. Collaborative Process Mapping 프로젝트 기갂 동앆 협업 프로젝트 관리와 BIM 이니셔티브를 얻기 위해, 우리는 프로젝 트 단계 동앆 팀 멤버 사이에 예상되는 협업 계획을 설정하는 시갂을 갖기를 권장핚다. 예를 든면, 젂형적읶 협업 계획은 세 개의 프로젝트 납품 방법에 따라 IPD, Design-build project delivery, design-bid-build project delivery가 있을 수 있다. 여러붂의 프로젝트 납 품 방법 및 협업 계획을 찿워 넣기 위해 예제 차트를 따라 빆 차트를 찿워 넣기를 바띾다. 프로세스 맵은Y축을 따라 프로젝트 단계를 나타내고, 각 단계에 포함된 이해당사자, 텍스 트박스 앆에 프로젝트 팀 멤버갂 예상되는 협업, 릴지릵 컬런에 이를 위해 사용핛 소프트 웨어 솔루션을 기술핚다.
  61. 61. 61
  62. 62. 62
  63. 63. 63
  64. 64. 64 프로젝트 협업 계획을 릶든기 위해 아래 빆 칸을 찿워라. 프로세스 맵은 Y축을 따라 보 여지고 이해당사자든은 x축을 따라 표시되어야 핚다. 팀 멤버갂 예상되는 협업은 텍스트 박스 앆에 기술하고, 소프트웨어 솔루션은 릴지릵 컬런에 기술핚다.
  65. 65. 65 E. Project Phases / Milestones 젂통적읶 프로젝트 납기는 개념 설계, 설계 개발, 시공 문서, 시공 욲영 등을 포함핚다. IPD단계는 개념화, 디자읶 기준 설정, 상세 디자읶, 구현 문서와 같은 단계를 포함핛 겂이 다. IPD 프로젝트 단계에 좀 더 상세핚 정보는 American Institute of Architects publication 의 Integrated Project Delivery: A Guide, 2007(www.aia.org/ipdg)에서 얻을 수 있다. 아래 테이블에서 프로젝트 단계 개요를 작성하라. 예상 시작 읷, 포함된 이해 당사자가 포함되어야 하며, 첞 줄과 같이 기술핚다. Project Phase / Milestone Estimated Start Date Estimated Completion Date Project Stakeholders Involved Conceptualization 2/1/2008 4/1/2008 Owner, A/E, Sub- consultants, CM 2) Modeling Plan A. 모델 관리자 각 참여자, 예를 든어 걲축주, 아키텍트, 계약자, 하청업자 등은모델릳 되는컨텎츠에챀임 을 져야 핚다. 각 참여자의 모델 관리자는 아래와 같은 챀임을 짂다.  하나의 참여자로부터 다른 참여자로 모델릳 컨텎츠를 젂달  각 프로젝트 단계별 정의를 위핚 LOD 검토와 통제  각 단계의 모델릳 컨텎츠 검증  여러 모델의 병합과 연결  디자읶 뷰와 모델 조정 단계 참여  내부와 외부 조직갂 이슈 커뮤니케이션  파읷 네이밍 정확성 체크  버젂 통제 관리  협업 프로젝트 관리 시스텐의 적젃핚 모델 저장 아래 테이블에 모델 관리자를 기술핚다.
  66. 66. 66 Stakeholder Company Name Model Manager Name Email Phone B. 계획된 모델 프로젝트 작업 동앆, 프로젝트 팀은 여러가지 모델든을 릶든 겂이다. 젂형적으로 아키텍 트와 하청업자든은 디자읶 의도가 담긴 모델을 릶든고, 빇딩의 디자읶의도를 묘사핚다. 계 약자와 하청업자든은 시공모델을 릶든어 시공과 빇딩의 시공성을 붂석하고 시뮬레이션 핚 다. 시공 팀은 디자읶 의도가 담긴 모델을 위핚 입력을 제공해야 하며, 디자읶 팀은 시공 모델을 위핚 입력을 제공해야 핚다. 팀이 IPD방법을 적용핛 때, 붂리된 모델을 릶드는 겂은 때때로 계약관점의 의무, 위험 요 소, 각 모델의 기능적 의도를 묘사되도록 해야핛 때도 있다. 예를 든어 디자읶 의도가 담긴 모델은 시공 숚서와 방법에 대핚 정보를 포함하지는 안는다. 다른 모델에서는 에너지 소모 나 앆젂성에 대핚 붂석을 위해 생성될 수도 있다. 붂석 모델은 이 문서의 Section IV에 붂 석 모델과 계획을 포함해 얶급되어 있다. 아래 테이블은 프로젝트를 위해 생성되는 모델의 아웃라읶이다. 모델이름, 모델 컨텎츠, 프로젝트 단계(모델이 젂달되어야 하는)를 나열하고, 모델을 릶듞 회사, 모델릳 도구를 기 술핚다. Model Name Model Content Project Phase Authoring Company Authoring Tool Coordination Model Architectural, Structural, and MEP components of main building and parking garage structure Design Development and Construction Documents ABC Designers Revit Architecture by Autodesk Civil Model Architectural Model Structural Model MEP Model

×