728x90
반응형

내부 회계 감사를 위한 ITGC 범위 지정 문서의 표준 템플릿

리소스에는 체크리스트, 업계 관행, 샘플 감사 보고서, 특히 SOX 규정 준수와 관련된 ITGC 범위 정의에 대한 지침이 포함됩니다.

내부 회계 감사의 경우 ITGC(정보 기술 일반 통제) 범위 및 문서 내용에는 일반적으로 다음 영역이 포함됩니다.

1. 액세스 제어: 시스템 및 데이터에 대한 액세스를 승인된 개인으로 제한합니다.

- 사용자 접속 검토

- 비밀번호 정책

- 직원 입사, 이동, 퇴사를 위한 접근권한

2. 변경 관리: IT 시스템 변경 프로세스를 제어합니다.

- 변경 승인

- 변경 사항 테스트 및 승인

- 변경 사항의 문서화 및 추적

3. 운영 제어: IT 시스템의 일상적인 운영과 관련된 절차입니다.

- 백업 및 복구 절차

- 작업 스케줄링 및 모니터링

- 사고관리

4. 네트워크 보안 제어: 전송 중인 데이터의 무결성과 보안을 보호합니다.

- 방화벽 구성

- 침입탐지 시스템

- 네트워크 접근 제어

5. SDLC(시스템 개발 수명 주기) 제어: IT 시스템의 획득, 개발 및 유지 관리를 제어합니다.

- 프로젝트 관리 실무

- 애플리케이션 설계 및 개발 표준

- 구현 후 검토

6. 물리적 및 환경적 통제: 물리적 IT 인프라를 보호합니다.

- 데이터센터 보안 대책

- 환경 제어(예: 화재 진압, HVAC)

7. 정보 보안: 데이터 및 정보 보안에 대한 전반적인 관리입니다.

- 데이터 분류 및 처리

- 암호화 정책

- 보안 인식 교육

문서에서는 재무 시스템, 데이터베이스,

기타 중요한 IT 인프라 구성 요소 등 어떤 시스템과 환경이 적용되는지 식별하여 범위를 정의해야 합니다.

ITGC의 목표, 범위 내 영역과 관련된 위험, 이러한 위험을 완화하기 위해 마련된 통제 수단에 대한 개요가 나와 있어야 합니다.

ITGC 범위 지정 문서는 감사자가 IT 제어 환경을 이해하고 이에 따라 감사 절차를 계획하는 데 기초가 됩니다. IT 환경 및 제어의 현재 상태를 반영하려면 포괄적이고 명확하며 최신이어야 합니다.

다음은 ITGC 범위 지정 문서를 데 도움이 될 수 있는 몇 가지 리소스입니다.

1. [IT 일반 제어 체크리스트 - 방법론]

https://methodology.eca.europa.eu/aware/Documents/IT-general-controls-checklist.docx

이 문서는 시작 시 유용 할 수 있는 체크리스트를 제공합니다.

2. [SOX 404 감사를 위한 ITGC 범위 지정

- ERA]

https://era.library.ualberta.ca/items/08426624-804c-4409-97fb-7c6316c27984/view/f01615cd-b178-4848-bbdf-f79c2109fd0a/Perhar_2008_MISSM.pdf

: 이 문서에서는 ITGC 범위 지정에 대한 현재 업계 관행을 검토

3. [내부 감사 - 오렌지 카운티 감사관-통제관]

https://ocauditor.gov/wp-content/uploads/2017/08/2624-First-Follow-Up-Audit-of-Integrated-Internal-Control-Review-of-the-Auditor-Controller-Accounts-Receivable.pdf

범위 지정 요소를 포함할 수 있는 ITGC 감사 보고서.

4. [IT 일반 제어 - ACCA 글로벌]

https://www.accaglobal.com/content/dam/members-beta/docs/sectors-industries-roles/ia/IT%20General%20Controls.pdf

이 문서 범위 내 시스템을 식별하고 문서를 검토하는 프로세스

5. [SOX를 위한 ITGC 작업 범위 및 정도를 정의하는 방법 | 거버넌스, 위험 관리 및 감사에 대한 Norman Marks]

https://normanmarks.wordpress.com/2010/10/18/how-to-define-the-scope-and-extent-of-work-on-itgc- for-sox/

SOX 규정 준수 범위를 논의하는 블로그

 

2624-First-Follow-Up-Audit-of-Integrated-Internal-Control-Review-of-the-Auditor-Controller-Accounts-Receivable (1).pdf
0.44MB
IT General Controls (1).pdf
0.28MB
IT-general-controls-checklist (2).docx
0.06MB
Perhar_2008_MISSM (1).pdf
0.19MB

'KOREA > 0. 기획' 카테고리의 다른 글

S/T , C/T, T/T 리드타임, 정미시간, 부하시간 용어  (0) 2022.10.27
[프로젝트 도입] 절차서  (0) 2022.05.26
ERP 구축  (0) 2022.04.25
성공적인 Project를 위한 Method  (0) 2022.04.18
[Check List] 시스템 구축 단계  (0) 2022.01.26
728x90
반응형

 ST( Standard Time, 표준시간),
* CT( Cycle Time, 싸이클타임)
* TT( Tact Time, 택트타임)
* LT( Lead Time, 리드타임)
  
<사례1>
* 택트타임    = 1일 작업 투입시간 / (작업수량/1명)
                        즉 2명이서 물건 5개를 만들었다면 480분(1일 8시간) x (5개/2인) = 192 분
 
* 리드타임    = 자재를 투입한 뒤 제품이 나올 때 까지 시간,
                      예를 들어 빵을 밀가루 반죽부터 먹을 수 있는 단계까지
* 싸이클 타임 = 자재는 연속으로 투입되기 때문에 제품 하나가 나오기 시작하면
                      이어서 나오는 다음 제품까지의 시간
 
* 정미시간    = 작업에 순수하게 투입되는 시간(자재 준비 등도 포함됨)
* 표준시간    = 정미시간에 여유율 등을 더한 시간
                       (여유율 : 작업을 하기 위해 피치 못하게 발행하는 시간. 회사 또는 만드는 제품에 따라
                         여유율은 달라 질 수 있음)
<사례2> 
* 리드 타임(A~C)   :  백로그(Backlog) ~ 완료(Done)까지의 시간
                      티켓 생성(요구사항 등록) 시점부터 반영되기까지의 기간 "전체 납기기간"

* 사이클 타임(B~C) : 진행 중(In Progress) ~ 완료(Done)까지의 시간
                    개발 착수 시점부터 반영되기까지의 기간 "순수 개발기간"
 
◈(A)==================◈(B)===================◈(C)
Tiket Created Start Work Tiket Live
* Tiket Created, Tiket Live가 무슨 말인지는 모르겠다.
 
<사례3>

* TACT TIME : 다수의 공정으로 이루어져 있는 벨트 컨베이어의 조립 작업 등에서는
              각 공정의 공정시간을 피치타임(Pitch Time)이라고 하며
              1일의 생산개수 최대시간을 그 공정계열의 택트타임이라고 한다.
 
<사례4>
M.H(Man Hour, 맨아워)
<맨아워>란 3년 이상의 숙련자가 한 시간 동안 할 수 있는 작업분량 이란 의미로 사용된다.
이 는 공정(혹은 라인)을 단위 작업으로 나누어 작업에 필요한 인원인 공수를 산정하고 나서
단위작업의 작업표준시간을 설정하고 특별한 문제가 없이 이를 한 시간 동안 수행하였을 경우
어느 정도의 분량을 할 수 있는 가로 측정된다.
이때 한시간당 생산된 수량을 UPH(Unit per Hour)라고 한다.
 
맨아워를 알기 전에 반드시 알아야 하는 것은 맨아워의 설정과정 전반에 대한 이해와 함께
작업표준시간 산정 방법, 여유율 산정방법, 작업피로율 적용방법등 맨아워 설정을 위한
사전 단계를 알아야 하는 것이다.
 
1. 작업표준시간
   표준화된 작업을 정상적인 숙련도의 작업자가 정상적인 속도(정신적/육체적 무리가 없는 속도)
   로 한 단위의 작업을 완수하는데 필요한 시간이며 이 시간에는 여유시간이 포함되어 있다.
 
(1) 작업표준시간의 구성 (화면이 깨져서..삭제...죄송=>작자의 글, 빙혼이 아님^^)
(2) 정미시간
    가공물을 가공 하는데 소요되는 시간. 즉, 공작기계 및 공구가 완전한 상태로 유지되고
    재료, 공구, 운반구 등의 대기, 작업자의 피로 등을 감안하지 않은 순수 가공시간을 의미한다.
    작업자 정미시간은 실제 작업자의 작업시간을 초시계 등으로 측정하거나
    모답스(MODAPTS)기법(? 생전 처음 들어 봄) 등으로 예측하여 산출한다.
 
* 작업자 동작 분석시 정상적인 숙련도(3년)의 작업자가 수행하였는지?
* 정상적인 속도 (정신적, 육체적 무리가 없는 속도)로 한 단위의 작업을 완수하는지?
* 작업환경의 영향은 없는지?

<빙혼>
  그럼 소기업에서 관리하는 ST나 M.H는 상기 * 3가지에 거의 해당이 안 될 터인데 걱정이다.
 
3. 여유시간
   용변, 물을 마시거나 땀을 닦는 시간 등 인간의 생리적 심리적 요구에 의한 지연과
   작업 중 피로회복을 위하여 소요되는 시간, 자재 불량 등으로 인해 발생되는 지연 시간 등을
   여유시간이라 하고 작업표준시간에 포함된다.
 
※ 피로 여유율 산정방법
①육체적, 정신적 노력, 회복계수 및 단조감 고려법
②작업이 요구하는 육체적, 정신적 조건 및 작업환경 평가법
③에너지 대사율과 노동 강도에 의한 방법
④ILO 여유율(* ILO : 국제노동기구) : 아래 표 참조
 
여유시간은 정미시간에 여유율을 곱하여 산출한다. ILO에서 추천하는 표준 여유율은 8시간
일반적인 작업을 기준으로 작성되어 있음으로 8시간 이상 작업이 수행되거나 교대작업,
야간 작업 시에는 에너지 대사율과 노동강도 평가에 의한 방법을 사용하여야 한다.
 
* 피로도, 회복계수는 고려되었는지?
* 작업 상황에 맞는 여유율이 산정되었는지?
* 8시간 이상 작업, 교대작업, 야간작업은 노동강도 평가를 수행하였는지?
 
<빙혼>
  사장에게 표준시간을 구할 때 여유율을 이야기하였다가 욕 겁나게 먹은 적이 있었다.
  여유는 공장에서 찾지 말고 그냥 보따리 싸서 집에 가서 찾으라고 한다. 고객도 마찬가지이고.
 
  
 
※ 작업표준시간은 정미시간에 여유시간을 합산하여 산출한다. 이 작업표준시간은 개별 작업/
   공정별로 산정되어 있어야 한다. 또한 생산주기시간(사이클타임, 택타임)은 공정/라인의
   개별 작업표준시간 중 가장 긴 작업의 시간으로 한다.
   앞서 제시한 사항과 더불어 작업표준시간 산정시 반드시 확인하고 점검해야 할 사항은
   다음과 같다.
① 동작분석이 객관적이고 체계적으로 수행되는지?
② 평가자가 충분한 교육과 훈련을 받은 경력자인지?
③ 작업자 동작분석시 정상적인 숙련도(3년)의 작업자가 수행하였는지?
④ 정상적인 속도 (정신적, 육체적 무리가 없는 속도)로 한 단위의 작업을 완수하였는지?
⑤ 피로도, 회복계수는 고려되었는지?
⑥ 작업 상황에 맞는 여유율이 산정되었는지?
⑦ 8시간 이상 작업, 교대작업, 야간작업은 노동 강도 평가를 수행하였는지?
⑧ 개별 작업표준시간이 산정되어 있는지?
⑨ 생산주기시간이 바르게 설정되어 있는지?
 
이러한 일련의 사항에 대한 사실 확인과 객관적인 평가결과가 없는 맨아워 협상은
의도된 결론을 벗어나지 못하는 무의미한 시간과 노력의 소비라는 점을 명심 하여야 한다.
 
[출처] 맨아워(M/H) 산정과 모답스(MODAPTS)의 대응방안|작성자 담백승렬
 
<사례5>
  택타임은 가용한 일 생산시간을 일 고객 수요량으로 나눈 값.
  예를 들면, 만약 하루 고객 요구량이 2500개이고, 공장 가동시간이 8시간이라면,
  그 때 택타임은 (8*60*60=28800)/2500=11초가 된다.
  택 타임은 제품이 고객에게 소비되어 지는 시간 간격 즉, 고객의 소비율이다.
  따라서 제품이 생산되어 지는 페이스(시간 간격=속도)이다
  사이클 타임은 한 공정에서 한 사이클의 작업을 완성하는데 소요되는 시간.
  만약 모든 공정의 사이클 타임을 택타임과 동일하게 할 수 있으면 한 개 흘리기가 가능하다.
 
<사례6>
  리드타임은 한대의 기계를 만드는데 필요한 모든 시간을 더한 값이고,
  싸이클 타임은 주기적으로 나올 수 있는 시간이므로 리드타임 >> 싸이클 타임.
  정미시간은 작업을 하기 위해서는 반드시 필요한 시간이 정미시간이므로
  자재와 공구 등의 준비시간이 포함되며 수리 시간은 포함되지 않고,
  표준시간은 이러한 정미시간에 추가적으로 발생할 수 밖에 없는 로스시간을 포함합니다.
  표준시간 >> 정미시간
 
<사례7>
  사이클 타임(Cycle Time)은 일반적으로 작업공정(Process)에서 첫 번째 부품이 들어와서
  작업을 마치고 나간 후 두 번째 부품이 들어오는데 까지 걸리는 시간을 말한다.
  즉, 제품이나 부품 1개를 만드는 데에 걸리는 시간 간격 이다.
  생산현장에서 사이클 타임(Cycle Time)과 택 타임(Takt Time)를 혼재되어 사용되지만
  사실 중요한 것은 어떻게 하면 생산성을 올릴 수 있는가?
  라인 발란스(LOB)가 어떻게 개선되어야 시간당 생산성이 오르는가? 이다.
 
<사례8>
  사이클 타임(Cycle Time)는 나 중심적이며,
  택 타임(Takt Time)은 고객 중심적이다
  예를 들면, 사이클 타임(Cycle Time), 1개를 생산하는데 걸리는 Painting 작업시간으로
  전처리시간(A,10') + 페인팅 작업시간(B, 30') + 건조 시간(C, 20') = 사이클 타임(60')이 된다.
  (Voice of Process)
  이것은 작업공정(Process) 단위에서의 사이클 타임(Cycle Time)을 측정할 수도 있고,
  전체 공정 단위에서의 사이클 타임(Cycle Time)을 측정할 수 있다. 따라서 이러한
  사이클 타임(Cycle Time)을 통하여 해당 작업공정(Process)의 효율을 측정할 수 있다.
  반면 택 타임(Takt Time)은 단위 공정 당의 시간이 아닌 하나의 완제품이 나오기까지 걸린
  시간을 의미한다.
  택 타임(Takt Time)은 고객이 하루 요구하는 수량이 8개라고 가정할 때,
  어느 정도 시간으로 생산을 해야 하는가 이다
  예를 들면, 8개 / 400' = 1개 / 10', 즉 10분에 1개가 생산이 되어야 한다. (?)
  (Voice of Customer)
 
<상기 내용이 이해가 안 가 빙혼이 일부 내용 수정>
  만약 하나의 제품이 A(10'), B(30'), C(20')의 3가지 공정을 거쳐 완성된다면
  이 제품의 택 타임(Takt Time) 혹은 사이클 타임(Cycle Time)은 60’이 된다.
  하지만 A공정의 사이클 타임(Cycle Time)은 10초라고 말 할 수 있지만
  A 공정의 택 타임(Takt Time)은 10초라고 말할 수 없다.
 
<생산성향상> : 
  loss(손실)를 줄이고, 이익을 향상시키는 것.
  한 달에 3,000개만 출하하는 제품을 10,000개를 생산하면
  재고가 증가하여, 자재, 부품의 고정비가 증가하여 결국 향상이 아닌 손실이 됩니다.
  -과거: 같은 시간에 많이 생산하는 것 (소품종 대량생산)
  -현재: 필요한때에 필요한 양만 생산하는 것 (다품종 소량생산)
 
 
<사례9>
  사이클 타임과 택 타임의 개념이 생산성을 향상한다
  자동차회사에서 어떤 차종이 3분에 한대씩 생산된다고 가정하면
  그건 목표시간(즉 택타임)을 3분에 맞췄기 때문입니다..
  공정 / 변경전 / 변경후
  A / 1인 3분 / 1인 3분
  B / 2인 1.5분 / 1인 3분
  C / 1인 6분 / 2인 3분
  생산 / 8시간÷6분=80개 / 8시간÷3분=160개
  즉 많은 공정의 사이클 타임을 조사하여 목표시간을 설정하는 것입니다.
 
<생산실적 집계>
  모든 자료의 기초는 실적집계입니다.
  형식적이 아니라 실질적이고 정확한 집계가 필요합니다.
  전용라인과 범용라인에 따라 다르지만 될 수 있는 한 시간대별로 집계 하는 것이 효율적이며
  다시 말하면 실적집계가 제대로 되지 않으면 아무것도 할 수 없습니다.
   토요다자동차의 생산성향상 첫 번째 TOOL이 <생산현황판>이라는 것을 반드시 명심해야 한다.
 
<FOOL PROOF화>
  “바보도 할 수 있는” 이란 뜻으로 바보를 갔다 놓아도 작업을 할 수 있도록
  공장(공정)을 개선하자는 뜻입니다..
  예를 들어
  * 자재나 부품이 어디 있는지 식별표지를 제대로 갖추고,
  * 생산 수량을 쉽게 파악하기 위해 카운터를 설치하는 등
  일본의 모 자동차 회사는 부품을 조립하는데 부품위치부터 조립위치까지의 최적의 거리를
  발자국 모양으로 표시하여 초보자도 쉽게 작업할 수 있도록 관리하고 있습니다.
  또한 어느 체인점은 쌀을 어느 향으로 몇 번을 씻고 밥을 해야 맛있는지를 표준으로 만들어
  수백 개의 체인점을 관리하여 동일한 맛과 서비스를 제공하고 있습니다..
 
<눈으로 보는 관리>
  예를 들면 재고관리를 프로그램을 운영하여 관리하는 것도 필요 하지만 현장의 재고현황을
  쉽게 파악할 수 있도록 적정 재고 표시를 하여 적정재고 표시량 보다 실제재고의 차이를 쉽게
  파악 할 수 있도록 눈으로 보는 관리체제가 매우 중요합니다.
  결론적으로 생산관리에서 제일 중요한건 생산계획부분입니다.
  많은 item으로 인한 계획수립이 쉽지 않고, 공장물류 개선이 이루어지지 않으면
  생산계획을 수립하더라고 적용하기가 쉽지 않습니다.
  중소기업에서 느낀 생산계획 수립은 대부분 현장 반장 지시로 이루어지고 있었습니다.
  그런데 중요한 것은 누가 하는 것이 아니고 어떤 지식과 교육을 받은 사람이 하는 것이다.
  만일 반장으로부터 계속적인 생산계획 업무를 수행하고자 한다면 반드시 전문적인 교육과
  지식을 갖춰야 하고 그렇지 않으면 말 안 해도 잘 알 것이다.
  또한 생산관리자라 하더라도 현장에서 일하는 시간이 대부분인 중소기업에서는 반장과
  별로 차이가 없다는 것을 느끼는 데 머리와 손발이 할 일을 구분하여 각자의 일에
  최고가 되려고 노력하지 않는다면 절대로 제대로 된 생산관리를 하기는 힘들다는 생각입니다.
  또한 많은 회사들이 ERP도입을 하고 있으나 대부분이 많이 실패하고 있는데 그 이유는
  프로그램 구입이 중요한 것이 아니라 생산현장의 수많은 변수 인자들을 조사하고
  각 회사에 필요하고 적절한 DATA와 인자들을 수집해야만 프로그램을 개발할 때
  성공도 할 수 있고 효과도 나타날 수 있다.
  다시 말하면 DATA BASE화에 집중하고 그 DATA를 이용하여 필요한 정보를 뽑아낼 수 있는
  능력이 먼저 선행되어야 관리시스템 구축이나 프로그램 개발이 가능하다는 것이다.
  FULL LIST도 없는 회사에서 왜 생산계획을 수립 못하냐고 꾸중한다면 그건 아무것도 모르는
  사람입니다.
 
<사례10>
  표준 피치 타임이란?
  생산 목표를 달성하기 위하여 필요한 시간 즉 한 사람당 걸리는 시간을 말한다.
  *표준 피치 타임의 계산법
  작업시간 나누기 생산목표
  28,800 초 % 900 매 = 32초
  900 매의 생산을 위하여서는 한사람의 봉제 가공시간이 32 초씩 걸려야 한다.
  만약에 어느 공정의 가공시간이 85초가 걸린다면 85초를 표준피치시간으로 나누어서
  사람의 인원수를 늘려 주어야 한다. 이 경우는 3사람이 들어가야 생산량을 맞출 수 있다.
   
  *공정분석 후 꼭 표준 피치 타임을 설정하여야만 투입될 인원과 2공정을 합하여 효율성을
  높일 수 있다
  *시간당 몇 장씩 만들어야 된다고 반장들에게 말은 하면서 어떻게 해야 시간당 목표를
  달성할 수 있는 지를 시간으로 말해주어야 한다.
  *시간당 100 매를 만들기 위해서 표준피치 타임이 36초 이다.
  만일 어느 공정이 45초 걸린다면 시간당 생산이 80 매 이상은 생산을 할 수 없다.
  {3600초 나누기 생산목표량 = 표준피치 타임}
  
<빙혼식 관리방법>
  먼저 상기 자료들은 허락도 없이 가져온 것에 주인들에게 무조건 먼저 사과를 드리고
  내용상 빙혼DL 이해가 안 가는 부분과 한글 오타는 빙혼이 수정을 하였음을 말씀드립니다.
  빙혼은 품질관리기사 시험을 볼 때 무진장 표준시간, 부하시간, 정미시간, 가동시간, 리드타임,
  택타임, 피치타임 등 그리고 시방도 보면 알겠는데 또 사용을 안 하면 잊어버린다.
  그래서 빙혼은 빙혼식 용어를 별도로 만들어 관리를 하고 살았다.
  대학교수, 저명한 품질학자, 지도위원/심사원들은 그냥 그들 나름대로 하면 되고
  빙혼은 빙혼 나름대로 하면 된다.
  결론은 <시간 용어>도 결국은 생산성 향상과 품질 향상의 도구일 뿐이다. 
  빙혼공장에서 시작을 하였는데 최고 학력을 지닌 중좐출신 관리자들도 아무런 문제가 없었다.
  빙혼도 처음에 공부도 할 겸 책을 꺼내 모처럼 부하시간, 정미시간을 보니 머리가 아팠다.
  그래도 생산성 향상을 위해서는 시간에 대한 개념을 가르쳐야만 하였고
  회사의 관리 기준을 만들기 위해서는 이런 시간용어에 대한 명확한 기준이 필요하였다.
  그래서 빙혼의 공장에는 누구나 한 번만 들어도 잊어먹지도 않고 외울 필요도 없는
  빙혼식 시간용어를 만들어 지금까지 거의 그렇게 살아왔기에 일반 기업들 관리하고는 다르다.
  무엇보다도 중요한 것은 시간 용어에 대한 정의가 중요한 것이 아니라 실질적인 실행과
  가짜가 아닌 실질적이고 정확한 데이터를 수집하는데 목적을 두는 것이다.
  빙혼이 직접 양식을 만들고 작성하는 방법과 데이터 집계하는 방법까지 다 가르쳤다.
  물론 ERP 같은 것은 생각해 본 적도 없고 엑셀할 수 있는 사람도 회사에 한두 명 밖에 없어
  숙련도가 제일 높았던 꾸냥 둘을 사무실로 데려와 야간수당을 주면서 엑셀도 가르쳤다.
  꾸냥들은 둘이 다 초등학교 졸업을 한 사람들이었지만 일주일만에 데이터를 정리할 수 있었다.
 
<빙혼식 용어정의>
  1. 근무시간
     월급을 주는 시간, 즉 8시 ~ 오후 5시(점심 1시간을 제외한 8시간)
  2. 작업시간
     쉬는 시간 10분 제외할 경우 8시간. 포함하는 경우에는 7시간 40분.
  청소시간 10분을 제외하면 작업시간은 7시간 30분이 된다.
   
  3. 실 작업시간
  : 모델교체, 설비고장, 교육, 정전 등을 제외한 실제 작업을 하는 시간.
  조회, 자재 불출은 작업시간에는 할 수가 없도록 입사 전부터 교육을 시킨다.
   
  4. 유효 작업시간
  : 양품을 생산하는데 투입된 시간
   
  5. 생산성
  (1) 생산성 = 실양품량 / 생산목표량
  (2) 유효 작업시간의 M.H / 작업시간 기준의 M.H
   
  6. 설비가동율 = 실작업시간(설비가동시간)/작업시간(설비가동시간)
   
  7. ST(표준시간)
  (1) 제품 1개 전체 ST
  (2) 애로공정의 ST : LOB 전과 후를 구분
  *설비로 생산하는 경우 C/T(사이클 타임)을 사용하기도 한다.
   
  8. 공수 = EA/M.H, 한 사람이 한 시간에 생산하는 수량
  (1) 애로공정의 ST로 산출, 생산목표량의 기준
  (2) 설비로 생산하는 경우 C/T로 산출
   
  설비종합효율, 생산효율 이런 것은 해 보지도 않았고 할 필요도 전혀 없었다.
  왜? 빙혼도 시험 볼 때만 필요하였지 실 작업에서는 쓸데없는 관리 낭비일 뿐이다.
   
  빙혼은 조그만 공장, 빙혼과 같은 수준의 관리자들하고 일을 하기 때문에
  멋진 용어나 개념, 공식들은 모두 관리 낭비로 생각하고
  꼭 관리자들이 해야 할 것만 사용하여 관리 낭비를 확 줄여버리는 것이다.
   
  데이터는 빙혼이 꼭 필요한 것만 요구하고 실천을 하도록 할 뿐이지
  빙혼이나 관리자나 활용하지 않는 데이터는 작성 자체를 못하게 하였다.
   
  실질적으로 사용하지도 않는 용어나 검토할 시간도 데이터를 없애 버리고 나면
  생산 작업자나 관리자나 모두가 편하고 알기 쉽고 반드시 기록해야만 하는
  데이터 수집을 위한 양식을 제공하여 빙혼이 원하는 정보만을 기록하고 분석하여 관리하였다.
   
  특히 대기업 출신들이 와서 자기들이 사용하던 시스템을 조그만 기업에 입히려고 하지마라.
  사장도 몰라보는 데이터를 만들 생각도 하지 말고 관리자가 이해도 못하는 이상한 용어를
  들먹거리면서 그래도 힘든 관리자나 담당자들을 괴롭히지 않았으면 좋겠다.
   
  6시그마를 비롯한 그 어떤 품질기법도 PDCA 또는 CAPD를 벗어날 수 없다는 것을 보고
  사용도 하지 못할 쓸데없는 품질초식만 잔뜩 늘어놓고 관리자들 눈/뇌/마음을 괴롭히지 말고
  삼재검법 하나라도 제대로 가르쳐서 그 끝을 보게 하면 저절로 품질과 생산성은 향상됨을
  믿기 때문에 타 회사 자료는 거의 필요 없고 모든 회사에 맞춤식 시스템을 수립하는 것이다.
   
택타임? 책에서 보았지만 빙혼이 다녔던 기업은 그런 말 몰라도 생산에 전혀 지장이 없었다.

'KOREA > 0. 기획' 카테고리의 다른 글

내부회계 감사를 위한 준비  (2) 2024.01.03
[프로젝트 도입] 절차서  (0) 2022.05.26
ERP 구축  (0) 2022.04.25
성공적인 Project를 위한 Method  (0) 2022.04.18
[Check List] 시스템 구축 단계  (0) 2022.01.26
728x90
반응형

3번째 직장을 다니면서 절차에 대한 내용을 정리해보았다.

물론 지금은 어설프게 진행하는듯한게 있지만 갈수록 어떠한 내용을 더 더할수도 있고

더 구체적으로도 진행될수 있다.

그 내용

업무진행 Process.xlsx
2.02MB

을 올림

728x90
반응형

ERP 구축에 필요한 내용

1. 조직 구성원 저항에 극복 필요

2. 경영진과 실무진 간 관점 절충

3. 직원의 적극적인 참여유도

4. 명확한 RFP 작성

5. 구축방법론이 있는 ERP 공급사 선정

 

728x90
반응형
 


1. 제품 기능의 정교함과 더불어 경험 많은 컨설턴트 유무 확인

우수한 ERP라는 것의 정의를 내리기는 쉽지 않습니다. 이는 최신 기술이 포함된 것을 의미할 수도 있고 멋있어 보이는 것 일수도 있으나 가장 중요한 것은 기업의 문제점을 해결할 수 있는 솔루션이 제공되는 패키지를 선택하는 것입니다. 그렇지 않는다면 많은 커스터마이징이 필요하게 되며 비용의 증가는 물론 시스템 안정성을 담보하기 어려워 질 수도 있습니다.
 
이를 위해서는 우선 자사의 전체 업무프로세스를 올바로 이해하는 것이 중요합니다. 그리고 개선해야 할 프로세스를 파악한 후 자사의 인력 등 자원 현황에 따라 현실적으로 이를 구현할 수 있는 패키지를 선정하는데 최대한의 노력을 기울여야 합니다. 잘못된 패키지 선정은 ERP 구축 시 다수의 커스터마이징 등을 유발하여 비효율적인 일정과 비용을 발생 시킬 수 있으며 더 나아가서는 예상치 못한 제약으로 인하여 당초 기대했던 목적을 달성하지 못 할 수도 있습니다.
 
예를 들어, ERP 시스템이 원가관리 기능을 지원해야 하는 경우, 단순히 원가가 계산되는 것 자체보다는 얼마나 정교하게 관련 정보들을 반영하여 정확히 산출되느냐가 중요합니다. 이러한 차이를 결정하는 것이 바로 ERP내의 원가 관련 기능의 수준이며 이러한 기능이 부족한 시스템을 선택할 경우에는 기업이 목표로 하는 결과를 얻는데 실패할 것 입니다.
 
하지만, ERP 시스템의 구축은 소프트웨어 개발전문가들만으로 진행되는 것이 아닙니다. ERP 시스템의 구축을 위해서는 기업 현장의 업무를 이해하고 이를 최적화하는 대안을 줄 수 있는 업무전문가가 필요합니다. 또한 ERP 시스템은 단순한 업무용 소프트웨어와 비교할 수도 없을 만큼 내용이 방대하고 섬세하기 때문에 이를 이해할 수 있는 ERP 컨설턴트가 필요합니다. ERP를 선택할 때 패키지 검토는 물론 이러한 능력 있는 컨설턴트의 충분한 지원을 받을 수 있는지도 함께 고려되어야 합니다.




2. 최적의 ERP 구축 추진팀(TFT)의 구성

TFT는 회사의 전체 또는 해당 업무 프로세스를 정확히 파악하고 있고 ERP 구축 과정에서 대두될 수 있는 문제점과 회사에 요구되는 ERP 구축 결과의 모습을 정확히 인지하고 있는 직원들로 구성되어야 합니다. ERP 구축 시 현업 TFT 구성원은 프로젝트의 성패를 좌우하는 매우 중요한 역할을 하게 됩니다. 따라서, 단순히 시간이 가능한 직원을 선발하거나 직급이 낮은 직원에게 떠넘기어 구성하기 보다는 회사에 오래 근무하여 경험이 많으면서 가능하다면 경영관련 지식을 가지고 있는 임직원을 반드시 포함하여 구성하여야 성공적인 프로젝트를 기대할 수 있을 것 입니다.
 
프로젝트 진행 시에는 통상적으로 컨설턴트 및 개발자 등의 공급사의 인원과 구축 기업의 정보를 제공하고 관리하기 위한 현업 TFT가 참여하게 됩니다. 이때 어느 쪽이라도 ERP 구축을 위해 요구되는 적절한 능력이 부족하다면 진행에 많은 어려움을 겪게 되고 잦은 이슈 상황에 직면하게 될 것 입니다. 특히 다른 구성원보다도 공급사의 프로젝트 관리자(PM)와 구축 기업의 현업 프로젝트 관리자가 프로젝트를 진행하기 위한 충분한 자질을 갖추고 있는지의 여부가 전체 프로젝트의 성패를 좌우한다고 해도 과언이 아닐 것 입니다.
 
특히, 현업 프로젝트 관리자는 ERP가 구축되는 기업의 대표로서의 역할을 하면서 공급사 컨설턴트와 지속적으로 소통하고 ERP 공급사와 자사 내부간의 이견을 합리적으로 조율할 수 있어야 합니다. 따라서 이에 걸맞는 충분한 자질이 부족할 경우에는 프로젝트 진행 자체가 어려워 질 수도 있습니다. 다른 모든 조건이 충분하더라도 프로젝트 관리자를 비롯한 TFT 구성원의 자질이 부족하여 프로젝트가 실패하는 경우도 많습니다. 이를 방지하기 위해서는 프로젝트에 대한 관심이 높은 인원으로 TFT를 구성하고 프로젝트 성공에 대한 의지를 높이기 위해 강한 동기부여를 하는 것이 필요합니다.
 
또한, ERP 도입의 목적은 결국 업무 프로세스의 개선이기 때문에 실제 업무를 수행하는 현업의 의견도 매우 중요합니다. 따라서 기존 업무의 비효율적인 부분을 도출하고 효과적으로 개선될 수 있도록 충분한 수의 현업 업무 담당자들을 TFT에 (비상임이라도)포함시켜서 프로젝트 진행 시 적극적으로 의견을 개진할 수 있도록 해야 합니다.


'KOREA > 0. 기획' 카테고리의 다른 글

[프로젝트 도입] 절차서  (0) 2022.05.26
ERP 구축  (0) 2022.04.25
[Check List] 시스템 구축 단계  (0) 2022.01.26
[기획] 메뉴 구조도  (0) 2021.12.07
[기획] 기획하면서 필요한 문서 - 2  (0) 2021.12.07
728x90
반응형

일반적인 정보시스템 구축은 분석(Analysis), 설계(Design), 구축(Construction), 구현(Implementation) 등 4단계 과정을 거쳐 구축된다. 그런데 ERP시스템은 업무프로세스 자체를 개선하는 경영정보시스템이므로 구축 전 사전준비활동(목표수립, 업무분석)부터 시작하여 시스템을 정착하기까지 단계별로 구분하여 수행되어져야 한다.

따라서 일반적인 정보시스템 구축단계 뿐 아니라 사전준비단계 및 안정화단계도 포함하여 감리단계를 구분하였다.

각 단계별 주요 Task 및 산출물과 감리점검항목은 다음과 같다.

계획단계

TASK산출물감리점검항목프로젝트수행계획 수립Kick-Off변화관리실행계획 수립
프로젝트 수행계획서 프로젝트 도입범위 및 계획수립의 적정성 검토
프로젝트 팀 구성의 적정성 검토
현업사용자 참여 구성의 적정성 검토
Kick-Off 보고서
변화관리 실행계획서 변화관리 실행계획 수립의 적정성 검토

분석단계

TASK산출물감리점검항목환경분석인터뷰벤치마킹핵심요소 분석As-Is 분석PI 추친과제 정의변화관리IT
내/외부 경영환경 분석서 프로젝트 비전과 목표 설정의 적정성 검토
프로젝트 비전 및 전략 보고서
인터뷰 계획서 사용자 요구사항 분석의 적정성 검토
인터뷰 결과서
벤치마킹 계획서 벤치마킹 수행의 적정성 검토
벤치마킹 결과서
CSF 및 KPI 정의서 업무 프로세스와 업무기능분석의 적정성 검토
As-Is 분석서
요구사항 정의서
PI 추진과제 정의서 미래 업무프로세스 정의의 적정성 검토
변화관리 실행계획서 변화관리 실행계획의 적성정 검토
IT 구성도 IT 구성의 적정성 검토

설계단계

TASK산출물감리점검항목To-Be기준정보 설계개발 요구사항 작성사용자 교육변화관리이행결과 점검
To-Be 설계서 GAP 분석 및 To-Be 설계의 적정성 검토
기준정보 설계서 기준정보 설계의 적정성 검토
개발요청 List 추가 개발요건의 적정성 검토
사용자 교육 계획서 사용자 교육계획 수립의 적정성 검토
변화관리 진척도 분석서 변화관리 수행의 적정성 검토
변화관리 수행 보고서

구축단계

TASK산출물감리점검항목Prototyping기준정보구축Configuration프로그램 개발통합테스트Data 전환사용자 교육변화관리이행결과 점검
Prototyping 시나리오 프로토타이핑 계획 및 이행의 적정성 검토
Prototyping 결과 보고서
Key Data Element 정의서 모듈 조합의 적정성 검토
기준정보 정의서
Configuration 정의서
개발요청서
통합테스트 통합테스트 계획 수립 및 결과관리의 적정성 검토
통합테스트 시나리오
통합테스트 결과 보고서
Data Migration 계획서/내역서 Data Migration 수행의 적정성 검토
Data Migration Issue List
사용자 교육 매뉴얼 사용자 교육 매뉴얼 작성의 적정성 검토
변화관리 진척도 분석서 변화관리 수행의 적정성 검토
변화관리 수행 보고서

이행단계

TASK산출물감리점검항목테스트사용자 정의사용자 교육시스템 관리 및운영절차 정의Cut Over 정리변화관리이행결과 점검
인수테스트 계획 및 시나리오 인수테스트 계획 및 결과 관리의 적정성 검토
시스템 테스트 결과관리의 적정성 검토
인수테스트 결과보고서
최종 시스템 테스트 결과 보고서
사용자 역할 정의서 사용자 권한 및 역할 정의 적정성 검토
사용자 매뉴얼 사용자 교육 및 매뉴얼 작성의 적정성 검토
시스템 운영 및 관리 절차서 시스템 운영 및 관리절차 수립의 적정성 검토
Cut-Over 계획서 Cut-Over 계획 및 Help Desk 운영계획 수립의 적정성 검토
Help Desk 운영 계획서
변화관리 진척 분석서 변화관리 수행의 적정성 검토
변화관리 수행 보고서

안정화단계

TASK산출물감리점검항목프로젝트 종료
프로젝트 결과 보고서 주요 변경업무 및 개선내용 반영의 적정성 검토
인수인계의 적정성 검토
데이터 및 어플리케이션관리의 적정성 검토
보안정책 수립의 적정성 검토

'KOREA > 0. 기획' 카테고리의 다른 글

ERP 구축  (0) 2022.04.25
성공적인 Project를 위한 Method  (0) 2022.04.18
[기획] 메뉴 구조도  (0) 2021.12.07
[기획] 기획하면서 필요한 문서 - 2  (0) 2021.12.07
[기획] 기획하면서 필요한 단어 문서 -1  (0) 2021.12.07
728x90
반응형

메뉴구조도는 사이트에 구성되어야 하는(혹은 구성되어 있는) 페이지를 트리형태로 표현한 문서로 보통 메뉴 간의 상/하관계와 기능 등을 엑셀로 작업하는 문서입니다.

메뉴구조도는 언제 사용하나요?

메뉴구조도를 작성하는 이유는 다양합니다.

저의 경우에는 벤처기업과 중소기업(SI업체)에 다닐 때 주로 메뉴구조도를 작성하였으며 이유는 다음과 같았습니다.

1) 제안서 작성을 위한 사전조사

2) 시스템(홈페이지) 신규 구축

3) 시스템(홈페이지) 고도화/리뉴얼

SI업체의 경우 새로운 사업에 참여하기 위해 제안서를 작성하는데 이때 가장 기본이 되는 사항은 기존 시스템을 분석하고 이해하여야 합니다.

'현재 ㅇㅇ홈페이지의 구조는 어떻게 되어있는지? 어떤 기능들이 있는지? 어떤 불편함이 있는지?' 등을 분석해야 하는데, 이때 가장 먼저 진행을 해야 하는 부분이 메뉴구조도 작성입니다.

또한, 시스템을 신규 구축하는 경우에도 메뉴구조도를 작성해야 합니다.

현업의 요구사항을 모두 수집 및 분석한 다음에 요구사항 어떤 메뉴에 어떤 식으로 적용시키고 이러한 메뉴들을 어떻게 구성을 하면 좋을지 등을 메뉴구조도에 1차적으로 표현합니다.

메뉴구조가 잘못 세워지는 경우에는 화면설계 등을 할 때 지장이 갈 수 있으므로 꼼꼼하게 메뉴 간의 관계와 사용자 편의성 등을 고려하여 설계를 하는 것이 좋습니다.

메뉴구조도는 어떻게 작성하나요?

메뉴구조도는 딱 정해진 양식이 없습니다.

저 또한 메뉴구조도를 작성하는 목적, 플랫폼 유형, 팀구성원 등에 따라 다르게 작성을 하는 편입니다.

1) 목적

- 신규로 구축해야 하는 시스템인 경우 : 요구사항을 바탕으로 1차적으로 메뉴 구성을 한 뒤, 이러한 메뉴를 다시 그룹화하는 방식으로 진행

- 제안서 작성을 위해 분석하는 경우 : 현재 시스템의 메뉴구조 및 기능을 그대로 작성

- (2개 이상의) 홈페이지를 통합하는 경우 : 각각의 홈페이지의 메뉴구조 및 기능을 1차적으로 작성 한 뒤, 통합 가능한 메뉴와 불가능한 메뉴를 분류

2) 플랫폼 유형

- WEB : 앞에서 설명한 방식대로 메뉴구조도 작성

- APP : 메뉴의 상/하관계를 고려하여 메뉴구조도를 작성하지만 메뉴간의 이동을 할 수 있는 부분을 함께 기재

3) 팀구성원

- 메뉴구조도를 작성할 때 함께 프로젝트를 진행할 팀원들의 이해를 돕기 위하여 각 메뉴의 기능(CRUD)까지 같이 기재하는 경우도 존재

- 참고사항 : CRUD는 데이터베이스 기준으로 개발자분들이 작업을 하는 부분이지만 기획단에서 이러한 부분을 정리해 주는 경우도 있음

: 팀원에 따라 이러한 CRUD를 작성해 주는 것을 좋아하는 사람도 존재하는 반면 월권이라고 생각하는 사람도 존재함

: C - 생성, R - 조회, U - 업데이트, D - 삭제

메뉴구조도 작성 공부하는 Tip

메뉴구조도 작성 공부하는 Tip

1) 대기업 그룹 홈페이지에 접속합니다. (네이버그룹, 삼성그룹, 카카오그룹, CJ그룹, 현대그룹 등)

2) 메뉴들을 다 클릭하면서 메뉴구조도를 1차적으로 작성합니다.

3) 작성한 메뉴구조도와 홈페이지의 '사이트맵'을 비교하면서 자신이 누락한 부분이 있는지 등을 확인합니다.

4) 새로운 파일을 다시 열어 홈페이지의 메뉴들을 다시 작성해봅니다.

5) 이번에는 추가적으로 각 메뉴의 기능들을 '설명' 란에 상세하게 작성을 합니다.

6) 그 이후 해당 메뉴에서는 새로운 값을 등록할 수 있는지? 삭제할 수 있는? 조회만 하는지? 등을 기재합니다.

 

728x90
반응형


1. 요구사항정의서

: 모든 프로젝트에 투입하면 가장 먼저 하는 업무는 요구사항을 수집하고 이를 정리 및 분석하는 것이다. 공공기관 사업을 하는 경우에는 RFP를 참고하여 요구사항을 수집하고 정리하는 것이 좋으며 요구한 내용을 분류하여 정리하는 것이 좋다.

아래 첨부한 이미지는 공공기관 프로젝트를 할 때 작성한 요구사항정의서 문서로 RFP를 기반으로 초기 작성을 하였으며, 회의 과정에서 변경되거나 추가되는 항목은 별도 관리를 하는 방식으로 정리를 했다.

 

 

2. 업무프로세스정의서

: 나는 업무프로세스정의서는 요구사항정의서만큼 중요한 문서라고 얘기하는 편이다.

새로운 시스템을 구축할 때는 현업 담당자들의 업무프로세스를 알아야 더 심도 있는 기획을 진행할 수 있고, 기존 시스템을 리뉴얼할 때에도 현업 담당자들의 업무 프로세스를 익히고 기존 시스템의 프로세스 또한 익혀야 기존 구조의 단점을 쉽게 파악하고 리뉴얼 이후에도 현업 담당자들의 편의성을 보장할 수 있다.

나는 이러한 업무프로세스정의서를 정형화된 문서로 작성하지는 않는 편이다.

아래 첨부한 이미지 2개는 동일한 프로젝트를 진행하면서 작성한 문서이나 각각의 업무 특성에 맞도록 다른 문서 형태로 작성하였다.

 

 

 

 

3. 메뉴구조도

: 이 산출물은 말 그대로 메뉴 형태를 나타낸 문서를 말한다.

내가 기획을 처음 시작했을 당시, 내 사수는 메뉴구조도 양식을 하나 주고 5개의 사이트 메뉴구조도를 그려보라고 했었다. 5개의 메뉴구조를 그려서 보여드리니 각 메뉴의 역할을 간단하게 작성하라고 하셨고 그다음에는 기능(CRUD)까지 작성해보라고 하셨다. 당연히 처음 작성했을 때는 틀린 부분도 많았으나 왜 틀렸는지 등에 대해서 설명을 해주셨던 걸로 기억난다.

이처럼 메뉴구조도 작성은 프로젝트를 구축함에 있어 중요하고도 기본적인 것이라고 표현할 수 있다.

(메뉴구조도의 샘플은 삭제해야 하는 단어가 많아 추후에 업데이트할 예정)

 

4. 화면설계서(스토리보드)

: 기획자들이 실제 현업에서 가장 많이 작성하고 가장 신경을 많이 쓰는 문서가 화면설계서가 아닐까 싶다.

이 문서에는 각종 정책, 프로세스, 와이어프레임, 디스크립션 등 많은 내용들이 포함되어 있다.이 문서를 통해 디자이너, 퍼블리셔, 개발자, QA 등과 소통을 하기 때문에 스토리보드를 최대한 자세하게 작성할수록 다른 업무 담당자들이 쉽게 이해를 할 수 있으며, 책임소재 또한 명확해질 수 있다.

 

5. 회의록

: 단어 그대로 회의에서 주고받은 의견이나 결정된 사항, 특이사항을 기재하는 문서이다. 추가적으로 사람의 기억은 변질되고 요구사항은 계속 변할 수 있으니 회의록은 최대한 꼼꼼하게 작성하고 경우에 따라서는 녹음을 하는 것도 추천한다.(회의 참석자 동의필요)

 

 

이외에도 많은 문서가 있던 것으로 기억하는데 현재 기억이 나지 않는다...

대신 개발자들이 작업하는 문서에 대해서도 문서명만 공유를 해주려고 한다.

 

 

- 개발 산출물 -

현행시스템분석서 / ERD / 테이블정의서 / 공통코드정의서 / 개발표준정의서 / 컴포넌트설계서 / 시스템인터페이스설계서 / 개발환경구축가이드 / 아키텍처정의서 / 성능테스트계획서

 

+ Recent posts