Karzin Lab

오늘은 분석 2번째 시간을 가져보겠습니다.

사실 이번시간에는 저번시간에 미리 말씀드린대로 오픈되어있는 ERP를 검색해서 해당 소스들을 분석해 보려 했습니다...만, 제 안 좋은 습관 중 하나가 아직 답도 안잡혀있으면서 답을 먼저 보려고 한다는 점입니다.

항상 답을 먼저 보고나면 흥미를 잃고 그 이후에는 정해진 답이라는 틀에 갇혀 다른 답을 못낸다는 점입니다.

분명 공부를 하기로 했지만, 너무 답에 연연하지 않고 제가 생각하는 답을 찾아서 가는 형식을 취하기로 했습니다.

물론, 제가 원하는 ERP가 추구하는 방향이 기존 ERP와는 많이 달라진다하더라도, 제 자신만의 답을 찾아볼까 했습니다.

(공부에 답이 없다고 생각합니다. 다만, 답이 없는 만큼 답이라고 해도 될 정도로 철저하게 하는게 맞다고 생각합니다.)

여담이 길어졌네요. 여담은 나중에~ 나중에~ 나중으로! 미루고!

오늘의 주제로 돌아가보도록 하겠습니다.

저는 ERP에 있어 가장 중요하다고 생각하는 부분은!

물론 돈(회계)이 가장 중요할 순 있겠지만, 저는 사람(인사)이라고 생각합니다.

사람관리가 잘 되는 회사여야만 회사가 잘 돌아간다는 거죠.

왜 이런 주제랑 다른것같은 이야기를 하느냐? 주제에 일치합니다!

저는 인사가 가장 먼저 개발이 이뤄져야하지 않을까 싶었습니다.

제가 생각하는 인사의 기본적인 정보(사원 기본 테이블)는 다음과 같습니다.

 - 사원 ID (고유해야함) [not null, key]

 - 사원 이름 (중복 가능 - 이름이 같은 사람은 분명 있습니다!) [not null]

 - 사원 생년월일 (중복 가능 - 생일 축하?) [not null]

 - 사원 입사일 (중복 가능 - 입사일로 부터 기간을 계산) [not null]

 - 사원 휴대폰 번호 (중복 불가) [null : 워라벨을 중시하는 현시점에서 연락은 하지 말도록 합시다!]

 - 사원 집 전화 번호 (중복 가능 : 부부일 수 있다. 룸메같이 같은 집에 살 수 있다.) [null : 집전화를 사용치 않는 경우 상정]

 - 사원 집 주소 (중복 가능 : 부부일 수 있다. 룸메같이 같은 집에 살 수 있다.) [null : 워라벨! yeah!]

 - 사원 최종 학력 (중복 가능) [null : 개인정보!]

두번째로 사원의 부서 직급 정보(사원 부서 직급 테이블)입니다. (지금은 인사만 분석하므로 부서, 직급테이블은 나중에 따로 언급하겠습니다.)

 - 사원 ID (고유해야함) [not null, key]

 - 부서 ID (중복 가능)

 - 직급 ID (중복 가능)

세번째로 로그인 권한 정보(사원 로그인 테이블)입니다.

 - 사원 ID (고유해야함) [not null, key]

 - 사원 passwd (보안설정되어있음.) [not null] * 패스워드 정보는 외부에서 볼 수 없습니다.

 - 사원 마지막 로그인 이력 (로그인시마다 업로드, 중복 가능) [not null - 첫 로그인 전이라면 0000년 00월 00일 00시 00분 00초 등으로 초기화]

 - 사원 마지막 로그아웃 이력 (로그아웃시마다 업로드, 중복 가능) [not null, 로그인 이력과 동일]

네번째로 사원 출퇴근 관리 이력(사원 출퇴근 관리 테이블(log))입니다. (야근을 파악 할 수 있습니다.)

 - 출퇴근 정보 (출근, 퇴근) [not null]

 - 날짜

 - 시간

 - 사원 ID

 - 부서 ID

다섯번째로 게시판 권한에 대한 정보(사원 게시판 권한 관리 테이블)입니다.

 - 사원 ID (고유해야함) [not null, 외래key]

 - 마스터 자격 (boolean, true인 경우 모든 게시판의 권한을 가지고 있습니다.) [not null(true or false)]

 - 시스템 관리 게시판 권한 ID (중복 가능) [not null]

 - 인적자원관리 게시판 권한 ID (중복 가능) [not null]

 - 기업 서비스 관리 게시판 권한 ID (중복 가능) [not null]

 - 프로젝트 관리 게시판 권한 ID (중복 가능) [not null]

 - 공급 사슬 관리 ID (중복 가능) [not null]

 - 고객 / 상품 관리 (중복 가능) [not null]

 - 재무 관리 (중복 가능) [not null]

 - 제조 관리 (중복 가능) [not null]

사원 게시판 권한 관리 테이블의 경우 각 게시판 별로 더 쪼개둘 생각입니다.

이런 경우를 상정해 보고 있어 나눴습니다._(모든 인원은 자신의 휴가 관리를 할 수 있으나, 충원이나, 급여관리와 같은 정보는 인사과 혹은 회계과가 아니면 볼 수 없게 하기 위함입니다.)

혹은 읽기 권한이 필요하지만, 쓰기 권한은 필요하지 않은 경우. (높은 직급의 개발자가 아닌사람은 프로젝트 관리에서 쓰기권한이 필요하지 않습니다. 읽기 권한을 통해 프로젝트를 확인할 수 있습니다.)

- 시스템 관리 게시판 권한 ID (고유해야함) [not null, 외래key]

- 사용자 관리 권한 (읽기, 쓰기)

- 시스템 관리 권한 (읽기, 쓰기)

- 환경설정 권한 (읽기, 쓰기)

동일하기 인적자원관리 권한

 - 인적 자원 관리 게시판 권한 ID (고유해야함) [not null, 외래key]

 - 충원(인사관리)

 - 혜택

 - 급여관리

...

등등...

위처럼 게시판마다 권한 ID를 부여하는 이유는 사원 A와 사원 B가 같은 게시판에서 같은 권한을 가지는 경우

같은 게시판 권한 ID를 부여하여 관리하기 용이하기 위함입니다.

마지막으로 사원의 급여 정보 (사원 급여 테이블) 입니다.

 - 연봉 협상일 (기본key (사원 ID와 합쳐 기본key))

 - 사원 ID (기본key (연봉 협상일과 합쳐 기본key))

 - 연봉 정보

 - 기본 월급 정보 (연봉 / 12)

 - 세금 정보

 - 실 수령 월급 정보 (기본 월급 정보 - 세금 정보)

 - 인센티브

 - 추가금액 (야근 등)

연봉협상일 + 사원ID를 기본 키로 한 이유는 기존 연봉협상일에서 현재 연봉협상까지 연마다 쌓여가면서 사원의 연봉이 얼마씩 올랐는지 파악을 가능하게 했습니다.

특히 이렇게 하는 이유중 하나는, 특별히 어느 한사람이 한사람몫 이상의 일을 할 경우, 또 경험자인 경우에 어느정도 씩 추가적인 연봉의 협상이 이뤄졌는지 파악이 가능하게 하기 위함입니다.

아직까지도 파악해야할 부분이 많이 남아있습니다.

실제로 위 정보들중에서는 더 추가해야할 부분도, 빠져야할 부분도 있다고 생각이 듭니다.

계속해서 분석을 통해서 더 다듬어 나갈 예정입니다.

다음은 설계(2)에서 뵙도록 하겠습니다.

설계(2)에서는 ER-다이어그램을 제작하여 기본적인 인사정보의 DB 정보를 살펴보도록 하겠습니다.

>> 문의 등의 정보 제공은 댓글을 달아 주세요.

버전정보

 - v1.0 2018.09.17 배포

 - v1.1 2020.06.12 다원ERP -> Project.다원ERP로 변경