Enterprise Resource Planning

정보시스템 특강 -1999학년도 2학기 Enterprise Resource Planning 문 태 수 동국대학교 상경대학 정보산업학과

목 차 • 통합정보시스템 구축의 필요성 • 정보시스템 기획(ISP)시의 고려사항 • ERP(Enterprise Resource Planning)의 개념 • ERP (Enterprise Resource Planning)의 구축 • CALS와 ERP • ERP and Modeling

통합정보시스템 구축의 필요성 1. MIS에서의 ERP의 개념과 위상 SIS Unstructured EIS DSS MIS ERP IRS Account Production TPS & Financing Marketing & Personnel Structured Procurement & Sales 1

통합정보시스템 구축의 필요성 2. 업무 부서(기능)과 업무 프로세스, 정보 흐름의 관계 부서 1 부서 2 부서 M 업무흐름 프로세스 1 프로세스 2 프로세스 N 2

통합정보시스템 구축의 필요성 3. 기존 IS의 업무 분석 방법 1) 부서내의 기능과 사용중인 정보(데이터,문서, 도면) 그 자체, 사용자 요구사항만을 면담과 질문서를 통해 파악 2) 전사적인, 부서간의 업무 프로세스와 정보의 흐름(교환 및 공유) 파악 부재 4. 기존 정보시스템 설계및 구현 동일한 정보(데이터, 문서, 도면)의 중복관리 데이터베이스 또는 파일 시스템 데이터베이스 또는 파일 시스템 부서간, 업무 프로세스간 정보의 흐름(교환 및 공유) 단절 독립 시스템(모듈) 1 독립 시스템(모듈) 1 부서간 정보 및 업무 프로세스의 표준화 부재 부서(기능) 1 부서(기능) 2 3

통합정보시스템 구축의 필요성 5. 업무 프로세스 중심의 통합정보시스템 구축 (1) 1. 전사적인(부서내 및 부서간의) 업무 프로세스와 정보 흐름 모델링 2. 표준화( 정보와 업무 프로세스) 3. BPR & 정보시스템/인프라 재구축 4. 통합 데이터베이스(데이터 통합) 5. 인터페이스(응용프로그램 통합) 중앙 데이터베이스 서버 통합 데이터베이스 (IDB) 사용자 PC 응용 프로그램 클라이언트 통합 시스템(모듈) 1 통합 시스템(모듈) 2 부서내 프로세스 1 부서간 프로세스 2 부서간 프로세스 3 부서내 프로세스 4 부서(기능) 1 부서(기능) 2 부서(기능) 3 4

통합정보시스템 구축의 필요성 통합 데이터베이스 관리 서버 6. 업무 프로세스 중심의 통합정보시스템 구축 (2) 분산 데이터베이스 서버 본사 데이터베이스 현장 데이터베이스 사용자 PC 응용 프로그램 클라이언트 통합 시스템(모듈) 1 통합 시스템(모듈) 2 부서간 프로세스 2 부서간 프로세스 3 부서내 프로세스 4 부서내 프로세스 1 부서(기능) 1 부서(기능) 2 부서(기능) 3 5

정보시스템 기획(ISP)시의 고려사항 1. 정보시스템 기획(ISP)의 필요성 정보시스템 기획의 미비 정보관리상의 문제 시스템개발상의 문제 필요정보의 파악 미비 정보의 표준화 미비 비호환적 시스템 개발 원 인 국부적 시스템 개발 개발자 위주의 시스템 개발 필요정보 부재 정보축적량 비대 정보공유 능력 저하 정보의 중복 관리 정보관리 비용 증가 결 과 정보교환/공유 능력 저하 시스템 만족도 /활용도 저하 다종, 단명 시스템 6

정보시스템 기획(ISP)시의 고려사항 2. 통합정보시스템 도입시의 문제점 1) 변화에 대한 저항 (1) 한 부서에서 사용하는 정보시스템 교체에도 많은 저항과 제약조건 (2) 기업내 모든 부서의 관련 정보시스템을 새롭게 교체할 때의 반발 2) 시스템 패키지만 사면 현업에 바로 적용할 수 있다는 오해 (1) 통합정보시스템 패키지의 적용은 전사적 표준화와 프로세스 개선활동이 전제 (2) 전사 표준과 개선된 프로세스에 따른 조직 개편 (3) 하드웨어 및 네트워크 안정성 및 보안 점검 (4) 데이터베이스 서버 튜닝 (5) 서버 운영 및 관리자 선정 (6) 시스템 사용자 교육 (7) 광범위한 사용자 층을 대상으로 한 클라이언트 GUI 및 소프트웨어의 Customizing 3) 전사 표준과 프로세스 개선 작업 이후 시스템 구현 단계에서의 지연 (1) 신 프로세스 정의 팀의 업무 스펙과 시스템 개발 팀의 개발 스펙간의 괴리 (2) 패키지의 수정/보완작업(Customizing)으로 인한 지연 7

정보시스템 기획(ISP)시의 고려사항 3. 통합정보시스템 도입시의 문제점 해결 방안 1) 최고 경영자의 적극적 지원과 강한 의지 (1) 정보화 성공의 열쇠는 최고경영층 의지에 달려 있음 (2) 변화에 대한 저항과 막대한 시스템 구축비(초기투자비용) (3) “바꾸되 철저히 바꿔보자, 극단적으로 마누라와 자식만 빼놓고…” (4) “컴퓨터를 과거와 같이 부분적인 업무에 국한해서 쓰면 오히려 효율이 떨어질 수도 있음. 컴퓨터를 쓰고 안쓰고가 문제가 아니라 어떻게 쓰느냐가 중요함” (5) “돈이 얼마가 들어도 정보화는 같은 방향으로 같은 시스템으로 한다” 2. 업무 프로세스 분석 및 개선 과정에서 전산부문과 현업의 실무자급인 중간관리자 (대개 대리급)를 전담요원으로 함께 투입 (1) 실제 시스템을 사용할 사용자 조직이 제대로 받아들일 준비가 되지 않으면 실패함 (2) 프로젝트 진행과정 중 발생하는 문제를 현업출신이 판단, 해결 (3) 개선이 필요한 업무는 이들이 현업부서원들과 의견을 교환한 후에 대안책을 제시 (4) 패키지 도입시 Customizing등에 대한 신속한 의사결정 가능, 구축시간 단축 (5) 전담요원은 프로젝트 팀으로 인사발령, 합류전 담당 업무에서 완전히 벗어나야 함 8

정보시스템 기획(ISP)시의 고려사항 3. 통합정보시스템 도입시의 문제점 해결 방안 3) 프로젝트 감리기관의 선정 (1) 감리기관으로 하여금 시스템 공급자와 구축 기업간에 의견충돌이 발생할 경우 이를 조정, 대변하는 역할을 함 (2) 의견합의 및 방향제시 4) 지금까지 대부분의 국내 프로젝트에서의 문제점: (1) 전산요원 중심의 팀 구성 (2) 현업에서 차출되더라도 전담요원이 아니라 필요시에만 참가함 (3) 현업업무에 별로 중요치 않은 인원이 참가함 9

정보시스템 기획(ISP)시의 고려사항 4. BPR의 실패 원인 1) 변화에 대한 저항 (1) 최고경영자의 적극적 지원과 강한 의지 부재 (2) 조직 구성원들의 변화에 대한 두려움 - 실직에 대한 위협 - 신기술에 대한 학습 - 기존 업무방식 선호 2) BPR과 정보시스템과의 연계 실패 (1) BPR = 업무 프로세스 개선 + 정보시스템 개선 (2) BPR에 의해 도출된 개선 업무 프로세스(TO-BE 프로세스)를 지원할 수 있는 정보시스템, 제도 및 관리방법의 개선이 따르지 못했음 (3) 기존의 정보시스템 개발방법(자체개발)으로는 구축 시간이 많이 소요되고, 그 기간동안 사용자의 요구사항이 변화됨 (4) BPR팀과 정보시스템 개발팀과의 갈등 존재 (적당한 선에서 타협한 시스템으로 종결됨) 10

정보시스템 기획(ISP)시의 고려사항 5. BPR과 정보시스템(IT)의 연계 방안 1) BPR과 정보전략기획(Information Strategy Planning: ISP)의 연계 2) BPR과 기업내 전사적 통합정보시스템(ERP 및 PDM)의 연계 3) BPR과 기업간정보시스템(IOS, EDI, CALS 및 EC)의 연계 11

ERP(Enterprise Resource Planning)의 개념 1. ERP의 개념 - 전사적 자원관리, 新경영정보시스템 1) ERP 패키지의 범위 경영정보(재무, 회계, 인사, 영업) +생산정보(생산/공정, 구매, 재고, 물류) 2) 특성 (1) 유연성(모듈의 부분적인 선택) (2) 확장성(향후 다른 모듈 추가, 신기술 추가 Version Up 용이) (3) 통합성(모듈간 정보의 교환/통합, 기존시스템 및 타제품과의 인터페이스 용이) (4) 최적성(패키지의 업무 프로세스와 정보모델이 가장 합리적, 표준적이라는 가정) (5) 혁신성(패키지와 기업의 업무 프로세스 및 정보모델간의 적합과정 필요) (6) 신속성(빠른 구축기간 및 변경) (7) 장기적 전산투자비용 절감(초기 투자비가 많지만, 구축 후 유지보수비용이 적음) 12

자체발주 자재입고 제품출고 대금청구 구매 구매요청 창고관리 재고관리 매입채무 외상매입 인사급여 자재입고 제품출고 생산 생산계획 MRP 공정관리 원가계산 총계정 원장 영업 수 주 출 하 매출채권 외상매출 회계/인사 발 주 납 품 ERP(Enterprise Resource Planning)의 개념 2. ERP 시스템의 구성도 13 13

ERP(Enterprise Resource Planning)의 개념 3. 정보시스템 기획, BPR 및 ERP 구축 방안 최신의 정보기술 선진 프로세스 도입 ERP 정보기술 인프라 BPR 정보시스템 전략계획(ISP) 14 13

ERP(Enterprise Resource Planning)의 구축 1. 통합정보시스템 구축의 3가지 방안 1) 자체 개발 (1) 도입 가능한 또는 도입할 만한 수준의 ERP패키지가 없을 경우 (2) 사용자의 요구사항이 비교적 정형화되어 있어서 장기간의 개발과정동안 변화가 적은 경우 (3) 자체 기술수준으로 개발가능하며, 기존 시스템과의 통합을 위한 인터페이스 개발이 용이한 경우 (4) ERP적용시 20-30%이상의 Customizing이 필요한 경 (Customizing에 따른 시간 및 비용의 증가와 BPR 효과의 저하) (5) 업무성격/절차가 투명하지 않은 경우 (ERP자체의 특성상 변칙적인 처리가 곤란하기 때문) (6) 경쟁력 우위를 위한 독자적인(차별화된) 기능이 요구될 경우 15

ERP(Enterprise Resource Planning)의 구축 1. 통합정보시스템 구축의 3가지 방안 2) 요소기술별 패키지 도입 과 자체개발 병행 (1) ERP 패키지로 제공되지 않는 업무에 대해 독자개발이 요구될 때 (2) ERP 패키지로 제공되지 않는 부분적인 요소기술에 대해 구현이 쉽지 않지만, 많은 S/W 벤더들로부터 다양한 패키지가 제공되는 경우 (CAD, 적산S/W 등) (3) 시스템간의 인터페이스 개발이 용이한 경우 16

ERP(Enterprise Resource Planning)의 구축 1. 통합정보시스템 구축의 3가지 방안 3) 통합 ERP 패키지 도입 (1) 도입할 만한 수준의 ERP패키지가 존재할 경우 (2) 보유하고 있는 기술수준으로 개발 및 시스템 통합이 어려울 때 (3) TO-BE의 기능이 ERP 패키지와 70-80%이상 일치할 경우 (4) 업무성격/절차가 투명한 경우 (5) 사용자의 요구사항이 변화가 심한 경우 (6) ERP 패키지내의 선진 프로세스를 적용함으로써 큰 효과가 기대되는 경우 17

ERP(Enterprise Resource Planning)의 구축 2. 자체개발과 ERP 패키지 도입의 장단점 비교 장점 단점 • 초기투자비가 적음 • 자사의 고유업무에 적합한 • 시스템 구성이 가능 • 자사의 know-How축적 가능 • ERP 업체에 종속성 배제 • 개발기간이 장기간 소요 • 신기술 적용에 많은 전문인력의 • 투입이 요구됨 • 과다한 유지보수 비용 자체개발 • 상대적으로 높은 초기투자비 • 도입초기 단계이므로 아직 국내 • 성공사례가 없음(건설업은 전무함) • 선진 업무 프로세스의 수용 및 • 적용의 어려움 • 경영환경 및 기술의 변화 수용 시에 • 하나의 ERP 업체에 완전 종속됨 • BPR을 통한 업무개선 효과 • 전사적인 시스템 통합 • 표준화에 의한 유지보수비 절감 • 개발기간의 단축 • 경영환경 및 기술의 변화 수용 • (ERP 패키지 개발업체가 계속 • 업그레이드한다는 가정하에) ERP 패키지 도입 18

ERP(Enterprise Resource Planning)의 구축 3. ERP 패키지 도입 및 구축시의 문제점 1) 외부환경요인 (1) 패키지의 Customizing을 최소화하려는 공급사와 Customizing을 요구하는 고객사와의 이해의 폭을 줄이는 것 (2) ERP 구축시에 투입되는 외국의 컨설턴트와의 의사소통 및 문화적 차이 문제 (3) 국내 전문 컨설턴트의 절대적 부족 (4) 과다한 컨설팅 비용 (현재 ERP 컨설턴트들의 가격은 계속 상승하는 추세) (5) 단순한 가격비교만으로 컨설턴트의 능력과 자질을 판단하기 어려움 (6) 아직 성공적인 사례를 찾기 어려움 (7) 우리 기업이 새로운 정보기술(개방형 클라이언트/서버, 객체지향 기술 등)을 수용하는데 인색함 (8) 한국형 표준 업무 프로세스(Best Practice)의 정의도 미진함 19

ERP(Enterprise Resource Planning)의 구축 3. ERP 패키지 도입 및 구축시의 문제점 2) 내부환경요인 (1) 부서간 갈등 (2) BPR과 ERP 구축의 동시진행 과정에서 발생하는 조직개편 및 프로세스 재설계 권한 이양 문제(프로젝트 관리위원회의 결정으로 해결) (3) 프로젝트에 투입된 인력의 사후보장 문제 (프로젝트 종료후 현장중심으로 재배치) (4) 사내 전산부서의 반대 (전산부문 종사자들은 ERP적용 후 자신들의 위치가 단순 운영자로 전락하지 않을까 우려함, 그러나 ERP 구현 작업을 통해 새로운 지식을 배우고 숙련 가능) (5) 프로젝트팀 구성 및 책임(기능별로 혼합편성) (6) 시스템 구축 전 전사 업무 프로세스 및 데이터의 표준화의 필요성 인식 부족 (7) 값비싼 외국 컨설턴트들을 꼭 써야하느냐의 문제 (8) 교육에 대한 투자 (9) 최고경영자 및 경영진의 이해와 인내 (10) 지금의 ERP 기반이 향후 CALS/EC등에 적합한 환경 제공에 대한 확인 (11) 막대한 시스템 구축비(초기투자비용) 20

ERP(Enterprise Resource Planning)의 구축 4. 한국형 ERP 패키지 및 표준 업무 프로세스의 필요성 상거래 관행과 기업 환경의 차이 한국형 ERP 및 표준적 BPR 필요성 정보기술 인프라의 차이 회계처리 제도, 상법, 노동관계법 등의 차이 21

ERP(Enterprise Resource Planning)의 구축 4. 한국형 ERP 패키지 및 표준 업무 프로세스의 필요성 1) 상이한 상거래 관행 및 기업환경 (1) 패키지 내부의 선진 외국 업체와 우리 기업의 업무 프로세스 및 정보모형 차이 (2) ERP 패키지들이 개발된 유럽과 미국에 비해 업무 프로세스의 세분화 미흡 (3) 각 업무간 책임과 권한에 대한 규정 미흡, 비정형적 통제수단의 활용 (4) 하도급 관계의 발달 등 (5) 한국형 표준 업무 프로세스(Best Practice) 개발 필요 22

ERP(Enterprise Resource Planning)의 구축 4. 한국형 ERP 패키지 및 표준 업무 프로세스의 필요성 2) 상이한 회계처리 제도, 상법, 노동관계법 등 (1) 우리의 회계처리 방식이 상대적으로 복잡 (2) 투명성의 부족 (3) 어음거래의 일반화 (4) 경영정보시스템과 생산/시공정보시스템의 연결고리 기능으로 모든 기능(모듈)이 회계정보를 바탕으로 통제를 받으므로 외국산 ERP 패키지 도입의 최대 걸림돌 23

ERP(Enterprise Resource Planning)의 구축 4. 한국형 ERP 패키지 및 표준 업무 프로세스의 필요성 3) 상이한 정보인프라 상황 (1) 아직도 메인프레임 중심의 중앙집중식 전산환경과 독립적인 시스템으로 운영 (2) 대기업은 클라이언트/서버환경과 개방형 시스템으로 이전 (3) 중소기업/협력업체는 정보인프라 취약 (4) 부족한 정보 인프라에서도 수행될 수 있는 ERP패키지가 필요 24

프로젝트팀/추진위원회 구성 • 경영환경의 이해(내/외부환경, 전략, 주요성공요인) • 프로젝트의 목표, 범위, 절차 및 중장기 일정 수립 기 획 • 현행(AS-IS) 분석 (프로세스, 데이터, 정보인프라, 조직) • 문제점 및 요구사항 분석 • 전사 데이터 표준화 • (ERP 패키지 선정) • 개선안(TO-BE) 도출 • GAP분석(GAP 리스트 작성) • 도입 모듈 및 우선순위 결정 • 세부 실행계획 수립 정보전략기획 (ISP) 요구분석 및 개념설계 • 데모 시나리오(프로토타이핑용 프로세스) 작성 • 기초 데이터 정의, 준비 • 프로토타이핑 및 데모 실시 상세설계 및 프로토타이핑 • 정보인프라 재구축 • 시스템 적용, Customizing(수정 및 보완), 개발 • 기존 시스템과의 인터페이스 개발 • 기존 데이터의 컨버전 • 시스템 관리 및 보안 방안 수립 시스템 적용/개발 • 사용자 매뉴얼 작성 • 사용자 교육 • 각 부문별 관리 및 평가 지표 설정 • 운영, 관리 및 평가 사용자 교육, 운영 및 평가 ERP(Enterprise Resource Planning)의 구축 5. ERP의 구축 과정 25

ERP(Enterprise Resource Planning)의 구축 6. ERP 패키지 선정 기준 1) 기능 (1) 기업의 특화 분야(업종)에 필요한 전체 모듈(Total Solution)의 제공 여부 (2) 각 모듈들의 연계성/통합성 (3) 기업의 현행 업무 프로세스와 패키지의 업무 프로세스와의 합치성(GAP 분석) (4) Customizing의 용이성 (5) 추가모듈(EDI접속모듈, Workflow, Groupware, 시뮬레이션 모듈 등) 제공 여부 (6) 기존 또는 새로 보완될 시스템과의 호환성 (7) 사용 용이성과 한글화 및 안정성 (8) 제품의 국제화(다국어, 다중 통화 지원) 2) 정보기술 (1) 기존 정보인프라/시스템(관리 시스템 및 데이터베이스)과의 유사성/합치성(GAP분석) (2) 플랫폼(하드웨어 및 운영체제) 독립성, 개발/Customizing 언어 및 개발환경(CASE) (3) 소프트웨어의 향후 전략(기능의 확장성, 업그레이드 및 최신 정보기술의 적용 계획) (4) 향후 CALS/EC 등에 적합한 시스템 26

ERP(Enterprise Resource Planning)의 구축 6. ERP 패키지 선정 기준 3) 서비스 및 기술지원 (1) 벤더와 협력 컨설팅 업체의 및 기술지원 경험 및 능력(컨설팅, 구현, 교육, 유지보수) (2) 제품의 유지보수 계약 조건 4) 사용자 분포 및 활용실태 (1) 제품 및 업체의 브랜드 이미지 (2) 지역별, 산업별 사용자 기업(Reference Site)의 수 및 활용실태 27

ERP(Enterprise Resource Planning)의 구축 7. 개선안(TO-BE)의 3가지 대안 1. 업무의 일부를 패키지에 맞춤 - 가장 바람직한 BPR(Process Improvement)과 Customizing 2. 업무 전체를 패키지에 맞춤 - Best Practice에 맞추는 혁신적 BPR(Breakthrough) 3. 패지지를 업무에 맞춤 - BPR을 하지 않음 28

현행 분석(모델링) 현행 (AS-IS) 문제점/요구사항 패키지 분석 및 선정 (현업과 패키지 비교) 벤치마킹 (Best Practice) 요구분석 및 개념설계 GAP 리스트 작성 전사 데이터 표준화 개선안 및 도입모듈 선정 세부실행계획 수립 개선 (TO-BE) 상세설계 및 프로토타이핑 ERP(Enterprise Resource Planning)의 구축 8-1. ERP/BPR 방안 (1) - 자체 현행 분석 후 패키지 선정 표준화,BPR, ERP 구축 동시 수행 29

패키지 분석 및 선정 (현업과의 간략 비교) 벤치마킹 (Best Practice) 현행 분석(모델링) 현행 (AS-IS) 문제점/요구사항 요구분석 및 개념설계 GAP 리스트 작성 개선안 및 도입모듈 선정 개선 (TO-BE) 전사 데이터 표준화 세부실행계획 수립 상세설계 및 프로토타이핑 ERP(Enterprise Resource Planning)의 구축 8-2. ERP/BPR 방안 (2) - 패키지 선정 후 벤더가 현행 분석 표준화,BPR, ERP 구축 동시 수행 30

현행 분석(모델링) 현행 (AS-IS) 문제점/요구사항 자체 개선안 도출 요구분석 및 개념설계 패키지 분석 및 선정 (현업 및 개선안과 패키지 비교) 벤치마킹 (Best Practice) 및 개선 (TO-BE) 전사 데이터 표준화 GAP 리스트 작성 및 조정된 개선안 도출 세부실행계획 수립 상세설계 및 프로토타이핑 ERP(Enterprise Resource Planning)의 구축 8-3. ERP/BPR 방안 (3) - 자체 개선안 도출 후 패키지 선정 표준화,BPR, ERP 구축 동시 수행 31

ERP(Enterprise Resource Planning)의 구축 8-4. 3가지 ERP/BPR 구축 방안의 장.단점 비교 1. ERP/BPR 방안 (1) - 자체 현행 분석 후 패키지 선정(대기업 형) 1) 기업의 현행 업무, 정보인프라 및 요구사항에 가장 적합한 패키지 선정 가능 2) 업무분석 단계의 컨설팅 비용 절감 3) 분석 요원들의 Know-How 축적 4) 분석단계에서 벤더와 협력 컨설팅 업체의 인력 및 Know-How 활용 못함 2. ERP/BPR 방안 (2) - 패키지 선정 후 벤더가 현행 분석(중소기업 형) 1) 업무 분석단계부터 벤더와 협력 컨설팅 업체의 인력 및 Know-How 활용 2) 방안 (1)보다 컨설팅 비용 증가 3) 선정된 패키지가 현행 업무, 정보인프라 및 요구사항에 가장 적합하지 않을 수 있음 3. ERP/BPR 방안 (3) - 자체 개선안 도출 후 패키지 선정(대기업 형) 1)기업의 현행 업무뿐만 아니라 개선안에도 가장 적합한 패키지 선정 가능 2) 업무분석 단계의 컨설팅 비용 절감 3) 분석 요원들의 Know-How 축적 4) 자체 도출된 개선안과 패키지와의 Customizing에 상대적으로 조정이 더 필요함 5) 상대적으로 구축기간이 더 길어질 수 있음 6) 일반적으로 벤더가 이런 형태의 구축 계약을 하지 않으려 할 수도 있음 32

ERP(Enterprise Resource Planning)의 구축 9. PDM(Product Data Management) - 제품(시설) 개발(설계) 통합정보 시스템- 1) 기존의 제품 개발 및 설계 관련 독립 기능 시스템 (1) CAD, CAPP(Computer-Aided Process Planning) (2) 설계정보관리시스템(EDB, EDM, 문서관리시스템, 도면관리시스템, BOM 정보시스템, 제품구조관리, 형상관리 시스템 등) (3) Workflow 시스템 2) PDM과 ERP는 대상 업무 프로세스(적용 범위)와 요소기술만 다를 뿐 전사적인 통합정보시스템으로서의 앞에서 언급한 여러 가지 공통된 특징들을 가짐 3) PDM과 ERP의 통합 (1) PDM(설계 및 시공)과 ERP(건설 및 시공)의 통합 을 이루어만 진정한 기업내 전사적 통합정보시스템과 설계 및 시공회사간의 기업간 통합정보시스템의 구축됨 (2) 통합 기술: 데이터 및 업무 프로세스 표준화, 통합 데이터베이스, 시스템 인터페이스 (3) 시스템 인터페이스 모듈: - 설계부문에서 제품/시설의 구조를 나타내는 E-BOM의 정보를 생산/시공 부문에서 제품/시설의 공정 관련 정보를 나타내는 M-BOM의 형태로 변환 - 문서/도면 교환을 위한 Workflow/전자결재, EDI, Groupware 모듈 33

CALS와 ERP 1. CALS의 종합적인 정의 제품/시설의 생애주기상의 단계별 업무 프로세스에 관련된 기업내 및 기업간에 표준화된 정보를 전자적으로 교환/공유하는 산업정보화 전략이자 통합시스템 1) 업무 프로세스- BPR, 동시공학(Concurrent Engineering) 2) 기업통합- 기업내 통합(Intra-Enterprise Integration), 기업간 통합(Inter-Enterprise Integration), 가상기업(Virtual Enterprise) 3) 표준화- STEP, IGES, CGM, RASTER, SGML, EDIFACT, CITIS, IETM, IDEF 4) 전자화- Paperless화 (전자상거래: Electronic Commerce) Networking (LAN, WAN, Intranet, Extranet, VPN) 5) 정보의 교환/공유- 시스템 통합 6) 산업정보화 전략- BPR, 최첨단 정보기술의 사용, 국제표준의 사용, 정보의 교환/공유, 법/제도 7) 통합시스템- 기업내 통합시스템 (ERP), 기업간 통합시스템 (EDI/EFT, CITIS), 기업내 및 기업간 공통 (IDB, PDM) 34

CALS와 ERP 2. CALS와 EC의 차이 광의의 CALS/EC (Commerce At Light Speed: 광속의 전자상거래) 협의의 CALS (Continuous Acquisition &Life Cycle Support) (특정한 기업/기관 사용자) 협의의 EC (Electronic Commerce) (불특정 다수) Internet 전자상거래 (전자지불, 가상쇼핑몰, 가상은행, 가상증권, 홈뱅킹, 에이전트) IDB(기업내/기업간) PDM(기업내/기업간) CITIS(기업간) IETM (ERP: 기업내) EDI/EFT/(Email) Network Infrastructure (LAN, WAN, Inter/Intra/Extranet) Security 35

CALS와 ERP 3. CALS의 추진 역사 1) 1980년대 (1) 미 국방성(방위산업 및 군수기술)에서 시작 (2) 협의의 CALS 개념만 존재(아직 EC개념은 시작되지 않았음) 2) 1990년대 (1) 미 국방성: CALS와 EC/EDI를 구분 (즉, 협의의 CALS와 협의의 EC) (2) 미 상무성(민간기술, 특히 제조업)으로도 이전: 광의의 CALS/EC (3) 미 연방정부(FIPS표준), 에너지성, 운수성, 항공우주국 등에서도 거국적인 착수 (4) 일본(통산성, 방위청, 우정성, 건설성, 특허청, 후생성, 대장성): 협의의 CALS (5) 한국(정통부, 통산부, 국방부, 건교부, 조달청): 광의의 CALS/EC 36

CALS와 ERP 3. CALS의 추진 역사 3) 미 국방성 내의 CALS 전문부서 (1) CALS & EDI Office --> CALS Office와 EC Office로 분리 (2) CALS(국방조달/지원용 기술 정보)와 EC/EDI(일반상거래/비즈니스 정보)를 구분 (3) CALS-MIL(기술 정보) 표준 (4) 기타 JEDMICS, DISA 등 4) 미 민간기업의 CALS 추진조직 (1) CALS-ISG(Industry Steering Group): 260개회사, 1000명의 자원봉사자 (2) 광의의 CALS/EC (3) CALS-STD(기술 정보 + 일반상거래 정보) 표준 (4) 기타 ECRC, NIIP, CIAG 등 37

CALS와 ERP 4. CALS의 표준 1) 제품 모델 표준 (1) STEP: 제품의 형상/설계도면(2차원, 3차원) 및 기술 정보 (ISO 표준에 따름) (2) IGES : 제품의 형상/설계도면(2차원, 3차원) 정보만 포함 2) 그래픽 파일 포맷 표준 (1) CGM : 2차원 벡터(수치) 그래픽 파일 포맷 (2) RASTER(CCITT Group 4): 2차원 래스터(화상/이미지) 그래픽 파일 포맷 3) 문서 파일 포맷 표준 (1) SGML: 텍스트 및 그래픽 파일(CGM, RASTER)을 포함한 문서의 구문 규칙 표준 (문서의 종류별로 정형화되지는 않음) (2) EDIFACT: 문서의 종류별로 정형화된 상거래/비즈니스 문서의 구문 규칙 표준 (X.435나 MIME 같은 통신 표준은 CALS표준으로 정의되지 않음) 38

CALS와 ERP 4. CALS 표준 4) 가이드 및 절차 표준 (1) CITIS: 정부와 기업간의 정부조달 시스템(CITIS)에 필요한 기능 및 요구사항 정의 (2) IETM: 대화형 전자식 운영/정비 매뉴얼(IETM)을 만들기 위한 절차 및 방법 정의 5) 구축 방법론/모델링 방법론 표준(FIPS표준) (1) IDEF0: 업무 프로세스 모델링 (2) IDEF1, IDEF1x: 정보/데이터 모델링 39

CALS와 ERP 5. CALS/EC 기반의 ERP 구축 1) 제품/시설 원가절감 효과 (1) ERP(기업내 통합) 30%, CALS/EC(기업간 통합) 70% (2) 70%의 시간과 비용요소가 기업의 외부(즉, 기업간) 프로세스에서 발생 (3) 특히 건설업은 하나의 프로젝트에 관련된 기업/기관의 수 및 프로세스가 복잡 (4) 이러한 관련 조직들간의 빈번한 커뮤니케이션(정보의 생성과 전달)과 호환성 (5) 타 산업에 비해 상호 교류되는 정보의 종류도 다양하고 양도 많음 (6) 또한 건설 프로젝트의 프로세스 방식에 있어서도 전통적인 설계-시공 분리방식, 설계-시공 일괄 입찰 방식(턴키 방식),CM방식(민자 방식) 등 다양하기 때문에 정보의 교류 방식도 복잡해짐 (7) 따라서 기업간 통합 시스템인 CALS/EC를 도입했을 때의 투자효과는 타 산업에 비해 상대적으로 높다고 할 수 있음 2) CALS와 EC의 국제 표준을 수용한/수용할 시스템(패키지) 도입 및 개발 3) Internet, Inranet, Extranet, VPN(Virtual Private Network) 등의 최신 기술 수용 40

CALS와 ERP 5. CALS/EC 기반의 ERP 구축 4) 분석 및 설계시 사용할 모델링 방법론 (1) 현행(AS-IS) 및 개선안(TO-BE)의 분석(모델링)에 CALS와 BPR에서 가장 많이 사용되고 있는 미 연방정부표준(FIPS)인 IDEF 방법론 사용이 바람직 (2) 한국과 일본의 건설CALS 마스터플랜 구축을 위한 업무 프로세스 모델링 기법으로 IDEF가 사용됨 (3) Journal of Construction Engineering and Management에 발표된 논문에서도 CICS 구축을 위한 최적의 모델링 기법으로 IDEF0를 선정 (4) 단, SAP의 R/3를 도입할 경우에는 ARIS를 사용하는 것이 바람직 (5) 다른 패키지들은 자체 모델링 방법론이 없으므로 IDEF적용이 바람직 5) IDEF(Integration Definition)와 ARIS(ARchitecture for Information Systems) (1) IDEF: IDEF0: 활동 모델링 (프로세스 + 프로세스간의 데이터흐름 + 조직 + WBS) IDEF1, 1x - 데이터 모델링 (데이터/문서의 속성 및 관계, 데이터베이스 모델링) IDEF3 - 프로세스 모델링 (프로세스간의 순서, 동시공학 모델링) IDEF3 ~ IDEF14 (2) ARIS: 독일 대학의 Scheer 교수에 의해 개발되어 SAP사 R/3의 모델링 방법론의 근간 Function View - 기능/활동 계층도(WBS) Data View - 데이터 모델링 Organization View - 조직도 Control View - 기능/활동 모델링 + 프로세스 모델링 41

Control Output Input Activity A1 Mechanism(부서/조직, 정보 시스템, 인적자원, 하드웨어 등) 업무 프로세스 Activity A11 Activity A12 정보(데이터, 문서, 도면)와 제품/시설의 흐름(교환, 공유) ERP and Modeling 1. IDEF0 Modeling - 하향식 작업 분해(Top-Down Activity Decomposition) - 42

ERP and Modeling 2. IDEF 모델링의 필요성 및 가치 (1) 1) 업무분석 및 설계(현행 및 개선안) 단계에 사용 (1) 현행 업무 프로세스, 데이터 및 요구사항 파악시 사용하던 기존 방식은 경험을 바탕으로한 질문서를 준비하여 담당자들과의 면담을 통해, 가능하면 현업에서 사용하고 있는 양식들을 보면서, 이 양식을 이용하여 어떤 경우에 어떤 내용을 누구에게 전달하는가 같은 질문을 통해서 파악함 (2) 파악한 결과는 주로 면담을 기록하여 정리하는 방식을 주로 사용 (3) 그러나 면담결과를 기록한 것만으로는 현행 업무 프로세스를 충분히, 체계적으로 파악하기도 어렵고, 얼마나 이해했는지 담당자로부터 검증받기도 어려움 (4) 또한 정보 측면에서도 정보의 흐름을 보기보다는 정보 그 자체만을 보게 됨 2) IDEF 모델의 가치 (1) 업무 프로세스 상에서 병목현상을 일으키는 곳을 찾아서 개선안 도출 (병목현상: 작업을 지연시키는 작업, 정보를 다시 종이에 옮겨적는 추가적인 작업, 정보를 중복해서 입력하는 작업등 비효율적, 불필요한 작업방법이나 절차 등) (2) 현재의 업무 프로세스를 쉽게 이해할 수 있는 단순한 그림으로 표현함으로써 그것을 보고 관련자들이 개선을 위해 토론할 수 있는 객관적인 수단을 제공함 43

ERP and Modeling 2) IDEF 모델의 가치 (계속) (3) 통합정보시스템 구축시 가장 어려운 부분이 사용자 요구사항이 프로젝트 진행 중에 변화하는 것인데, 때로는 이런 부분을 명확하게 기술하지 못하여 개발자와 사용자간에 분재의 씨앗이 되기도 하는데, IDEF 모델을 사용하여 그 변화된 요구사항을 그림에 객관적으로 표현할 수 있음 (4) IDEF0 (활동, 프로세스) 모델로부터 프로세스 상에서 어떤 정보가 어떻게 생성 및 사용되고, 유통되고 있는가(정보의 흐름)를 파악할 수 있다. (5) 면담을 통해 문서나 양식이 담고 있는 정보 그 자체만을 분석하여 구축한 정보시스템은 많은 정보를 담을 수 있는 그릇은 될 수 있을지 모르지만, 정작 정보시스템 사용자들이 작업을 하는데 있어서 필요한 정보를 구하고 다음 사람 에게 필요한 정보를 전달하는 정보자동화의 도구로서 정보시스템은 되지 못함 (6) 통합 또는 독립 정보시스템을 도입하였으나 사용자들로부터 좋은 평가를 받지 못하고 활용되지 못하고 있다면, 그 원인은 바로 업무 프로세스 및 원활한 정보의 흐름을 지원하는 정보시스템의 인식이 부족했기 때문 3) IDEF0 활동/프로세스 모델과 작업흐름(Workflow) 모델의 차이 (1) IDEF0: 각 활동/프로세스(Cross Functional Activity)간 정보(데이터, 문서, 도면)의 교환 및 공유 (2) Workflow: 각 부서/기능(Function) 및 작업자(Object)간 정보의 교환 44

현행 IDEF0 업무 프로세스 모델 문제점(병목현상) 및 요구사항 파악 개선 IDEF0 업무 프로세스 모델 프로세스 들간의 정보의 흐름(교환 및 공유), 관련 조직, 관련 정보시스템 관련 프로세스들을 Grouping하여 관련 정보시스템(상위, 하위 모듈)을 구성 정보시스템 들간의 정보(데이터, 문서, 도면)의 흐름(교환 및 공유)로 변환 데이터의 교환 및 공유 문서, 도면의 교환 및 공유 IDEF1x 데이터 모델 Workflow 모델 통합정보시스템(ERP, PDM) 통합 데이터베이스 Workflow, EDI, Groupware ERP and Modeling 3. IDEF 모델링을 이용한 BPR과 통합정보시스템(IT)의 연계 45

Enterprise Resource Planning