의류부자재 관리솔루션 - 진보상사 업무 전산화

가. 요약

  • 기간 및 인원
    • 2024.02 ~2025.03
    • 총 2명: 
      본인 PM/서비스기획/DB설계 1명 IT기획/C#개발 1명

  • 내용
    • 진보상사의 백오피스 시스템으로 의류부자재(라벨, 행택, 가죽) 통합 관리 솔루션
    • 견적품관리, 수주관리, 발주관리, 재고관리 구현
    • 각종 장부 및 수기 출력물 전산화
  • 결과
    • 2025.03 완료. 유지보수 진행중
    • 2023.01 ~ 2023.12 처음 진행했으나, 프로젝트가 지연되어, 프로젝트 리셋.
      인원 축소 및 사용 환경을 웹에서 윈도우로 변경하여 새롭게 진행 및 완수.

  • 역할
    • 업무 인터뷰, DB설계, DB프로시저 작성, 화면설계, 테스트

  • 경험
    • 프로젝트 관리, 트랜잭션 로그 백업 구현, 네트워크 구성, 호스팅 및 코로케이션 리서치,

나. 제품

진보 API의 특장점 (패키지 ERP 프로그램과 비교시) 

복잡한 주문제작품도 등록 및 조회 가능

  • 단순한 품목 관리를 넘어, 주문제작품의 상세 스펙(이미지포함) 저장 가능


  • 제품 도안와 샘플 이미지를 함께 관리


수주/발주/입출고/마감을 단 하나의 화면에서 입력

  • '진보상사'의 업무 스타일을 반영한 '수발주 프로세스' 개념 도입


  • 템플릿과 같이 주문서를 양식으로 저장하여 사용


  • '프로세스 정보' 화면을 통해, 한 제품을 만들기 위한 여러 발주를 한 화면에서 처리


전체 메뉴 (29개 메뉴)

  • 기준정보 (13)
    • 사용자관리, 메뉴권한관리
        ㄴ 사용자 계정관리, 권한그룹 관리, 권한그룹별 메뉴접근 관리
    • 코드관리
        ㄴ 각종 콤보박스 값 관리
    • 견적품타입, 견적품사양
        ㄴ 주문제작품 상세스펙 관리
    • 자재품목, 창고
        ㄴ 자재정보 관리, 입출고 기준창고 관리
    • 수금통장관리, 거래처등급관리
        ㄴ 계좌정보 관리, 매출액 기준 거래처 등급 관리
    • 수발주타입, 수불타입, 계정, 수발주프로세스
        ㄴ 주문/수불/계정 타입 관리, OneStop 프로세스 관리
  • 거래처 (4)
    • 거래처그룹관리, 거래처관리
        ㄴ 거래처그룹 및 거래처 등록 및 조회
    • 견적품리스트, 견적품정보
        ㄴ 주문제작품 등록 및 조회
  • 수주 (5)
    • 수주리스트, 수주정보
        ㄴ 수주 등록 및 조회
    • 프로세스리스트, 프로세스정보
        ㄴ 수주/발주/입출고/마감 등록 및 조회
    • 수금장부
        ㄴ 수금 등록 및 조회
  • 발주 (3)
    • 발주일괄등록, 발주일괄관리
        ㄴ 발주/수불/마감 등록 및 조회
    • 송금장부
        ㄴ 송금 등록 및 조회
  • 재고 (2)
    • 입출고관리
        ㄴ 수불 조회 및 삭제
    • 현재고관리
        ㄴ 재고 조회, 기타입출고, 재고이동
  • 개발자관리메뉴 (2)
    • 화면정보관리
        ㄴ 메뉴 순서, depth, 버튼 설정
    • 헤더정보관리
        ㄴ 그리드 컬럼명, 순서, 폭, 정렬, 키인여부 설정

다. 역할

업무분석



DB 설계

DB 네이밍 룰

ERD 일부

전체 ERD

Figma 프로토타입

Figma 링크



DB 프로시저 작성

프로시저리스트

트리거 구현


교육 및 피드백


프로그램 학습 자료 (문제지)

라. 2023년 실패 분석

  • 기간 및 인원

    • 2023.01 ~ 2023.12
    • 총 4명: 기획 및 DBA 1명(본인), 백엔드개발자 1명, 프론트엔드개발자 2명

  • 중단 이유

    • 당초 예상했던 프로젝트 기간(1년)이 지난 시점에서, 전체 50% 완료
    • 프로젝트 일정 관리가 어렵고, 나머지 50% 작업에 대한 완료시기를 예상하기 어려움
    • 마지막 2개월간 프로젝트 속도를 높이고자, 1)작업별단위시간관리 2)업무용메신저사용 3)업무환경변화 등을 시도했으나 뚜렷한 변화가 보이지 않음

  • 실패 원인

    • 인력 부족
      • 프로젝트 매니저 (부재)
        : 처음 일해보는 사람들과 진행한 점, 토요일에만 대면 회의가 가능한 점 등으로 매니저의 필요성이 높아졌다. 예상치 못한 이슈가 터졌을 때, 상황을 지휘할 사람이 없어 전체 작업이 중단되는 일이 잦았다. 

      • IT 기획자 (부재)
        : IT 인프라를 구축하는 일에 생각보다 많은 시간을 소비했다. 백엔드와 프론트엔드 사이에 개발 방법을 결정할 때에도 중재할 사람이 없어 서로가 속앓이 하는 일이 있었다.

      • 서비스 기획자 (본인)

      • DB 관리자 (부재)
        : SQL 쿼리를 최소화하는 ORM 개발 방법이라고 하여, DB업무가 적을 것으로 예상했다. 그러나, 데이터베이스 구조가 복잡해 질수록 어쩔 수 없이 쿼리를 사용하는 일이 생기면서, DB업무에 할애하는 시간이 많아졌다.

      • 디자이너 (부재)
        : 주로 디자이너와 협업해 왔던 프론트엔드 개발자 입장에서는 기획자와 화면 디자인을 의논하는 것이 익숙치 않았다.

      • 백엔드 개발자 (1명)

      • 프론트엔드 개발자 (2명)

    • 업무 시스템 부재
      • 업무 프로세스, 의사소통, 표준화
        : 몇 명은 본업이 있고 몇 명은 평일에 작업하다 보니, 필요할 때 의사소통 할 수 없었다. 또한, 각자 프로젝트 초기에 자신의 모듈이나 함수를 만들어 일을 수월하게 하려 하는데, 각종 인터페이스의 표준화 합의 없이 진행하다 보니, 자신의 모듈이나 함수를 수정하고 오류 잡는 일이 잦았다. 

  • 대안

    • 대안1, 프로젝트 개선
      • 온라인 회의 추가, 회의 미참석시 벌칙 도입
      • 디자인 라이브러리 사용. 라이브러리 기반으로 화면 재설계

    • 대안2, 프로젝트 전체 재개발 (선정)
      • 윈도우APP 개발과 웹 개발로 분리.
      • 윈도우APP 개발 완료 후, 웹 개발 진행