개요
본 컨설팅 영상 스크립트는 건설 프로젝트의 기성금 관리 및 수익 계산 시스템 구축에 대한 심층적인 논의를 담고 있습니다. 총 공사 금액에 따른 수익 계산부터 기성금의 정의, 한도 설정, 실제 지급액 관리, 그리고 인력 투입 결정에 이르는 전반적인 재무 관리 프로세스를 다룹니다. 특히 노션(Notion) 기반의 데이터베이스 시스템을 활용하여 기성금, 공수, 생산성 데이터를 효율적으로 관리하고 자동화하는 방안을 모색합니다. 건설 현장의 특성을 반영한 실무적 문제점과 그 해결책을 제시하며, 데이터 입력의 정확성과 시스템의 유연성 확보에 중점을 둡니다.
주요 학습 포인트
•
건설 프로젝트 수익 및 기성금 관리의 핵심 개념과 실제 적용 방식
•
기성금 한도 설정 및 실제 지급액 연동을 통한 재무 관리 효율화
•
공수(工數) 및 면적 데이터를 활용한 건설 프로젝트 생산성 측정 방법
•
노션 데이터베이스 기반 시스템에서의 데이터 입력, 권한 관리, 중복 문제 해결 전략
•
건설 현장 특성을 반영한 월별 보고서 자동화 및 프로젝트 완료 처리 프로세스
요약
1. 건설 프로젝트 수익 계산 및 기성금 기본 개념
•
핵심 요점: 1. 프로젝트 수익 계산 방식과 기성금의 정의 및 처리 원칙이 논의되었다.
◦
부가 설명:
▪
수익과 차익은 동일한 개념으로, 총 공사 금액에서 합계를 뺀 값으로 계산된다. 이때 총 공사 금액은 물량 서브에서 나오는 금액을 기준으로 기성금을 입력해야 한다.
▪
기성금은 건설사가 실제로 받은 돈을 의미하며, 받을 것으로 예상되는 금액이 아닌 실제 지급 기준으로 선입력 처리의 필요성이 강조되었다.
▪
프로젝트 수익이 2,000만 원, 비용이 1,500만 원일 때 실제 수익 500만 원에 따라 알바 투입 여부를 결정하는 예시를 통해 수익의 실질적 활용 방안이 제시되었다.
▪
수익 계산 방식을 "수익에서 기성금을 빼는" 방식으로 조정하여 더 적절한 결과를 얻을 수 있다고 판단했다.
◦
중요 참고사항:
▪
건설사가 기성 성과급의 최대 한도를 미리 정해놓기 때문에, 이를 입력할 수 있는 별도 속성이 필요하며, 이는 보통 1,000만 원에서 1,500만 원 사이로 설정된다.
▪
기성금 한도는 예상 금액이며, 이를 위해 수동 입력이 가능한 별도 항목을 추가할 필요성이 논의되었다.
2. 기성금 관리 시스템 및 데이터 처리 방식
•
핵심 요점: 2. 건설 프로젝트의 기성금 한도 관리, 실시간 업데이트, 그리고 시스템 내의 데이터 흐름에 대한 구체적인 구현 방안이 논의되었다.
◦
부가 설명:
▪
기성금이 건설사에 실제로 입금되면 시스템에서 받은 금액을 입력하여 상태를 변경하는 방식을 제안했다. (건설사 기성금 유무에 따라 실제 금액 또는 한도 입력)
▪
기존 알바 투입 공수 섹션에 기성금 한도라는 금액 속성을 시스템에 표시하여 혼란을 방지하고 의사결정 자료로 활용하는 방안이 검토되었다.
▪
기성금 관련 데이터는 팀별이 아닌 전체 프로젝트에 대한 데이터로 분류되어야 하며, 월간 리포트로 이동시키는 구조 변경이 필요하다고 논의되었다.
▪
기성금은 한 달에 한 번씩 지급되는 방식으로, 월별 단위로 관리해야 하며, 초기에 일별로 설정했던 것을 월별로 변경하기로 했다.
◦
중요 참고사항:
▪
기성금은 프로젝트 초반에 결정되며 이후 잘 변경되지 않는 특성을 가지고 있으며, 통상적으로 1,500만 원 이상 지급하려고 하지 않는 것이 일반적인 방침이다.
▪
데일리 리포트 작성 시 기성금 한도와 건설사 정보를 먼저 입력하고, 직접 받는 돈인 기성금은 나중에 입력하는 항목으로 분류된다.
3. 생산성 측정 및 면적 기반 공수 계산
•
핵심 요점: 3. 건설 프로젝트의 생산성 측정 방식과 면적 데이터를 활용한 공수 계산 시스템 구축 방안이 심층적으로 논의되었다.
◦
부가 설명:
▪
생산성은 수익을 공수로 나누어 계산하며, '측정 공수'와 '실 공수' 두 가지 모두를 기준으로 생산성을 각각 별도로 산출하기로 결정했다.
▪
팀별로도 생산성 지표를 산출할 필요가 있다고 논의되었으며, 1공수당 얼마의 수익을 창출했는지를 원(돈) 단위로 측정하는 방식이다.
▪
작업 일지와 작업 진행률이 연계되어 물량과 공수 계산에 활용되는 시스템 구조를 설명했다. 특히 "회배"는 제곱미터를 의미하는 건설업계 용어이다.
▪
평방미터 면적을 누적 공수로 나누어 생산성을 계산하고, 면적 관련 수치는 소수점 두 자리까지 표시하여 월별로 집계하여 생산성을 측정한다.
▪
일 공수당 60평방미터가 목표 기준으로 설정되어, 하루에 한 명당 달성해야 하는 면적 생산성 지표로 활용된다.
◦
중요 참고사항:
▪
실공수에서 면적을 가져와 계산하는 작업을 진행했으나 처리 속도가 느려지는 문제가 발생했으며, 이를 최적화하는 방안이 필요하다.
▪
기존 '면적' 항목을 '일 공수당 면적'으로 명칭을 변경하여 실공수 항목에도 적용하고, 향후 가이드 작성을 통해 사용자 이해도를 높일 계획이다.
4. 데이터베이스 및 시스템 운영 개선
•
핵심 요점: 4. 노션 기반 데이터베이스 시스템의 입력 방식, 권한 설정, 그리고 데이터 중복 문제 해결을 위한 논의가 진행되었다.
◦
부가 설명:
▪
데이터베이스 아이디는 한번 생성되면 변경되지 않으므로, 속성 추가 시 아이디 문제보다는 필터링 방식이 중요하게 다뤄졌다.
▪
데이터베이스 아이디를 직접 입력할 수 없는 제약으로 인해 작업에 어려움이 발생하며, 필터링 과정에서 데이터를 가져오지 못해 라인에 필터링을 적용하다 보니 두 개씩 중복으로 생성되는 현상이 나타났다.
▪
월간 리포트와 기성 완료 처리를 위해 각각 버튼 형태의 입력 시스템을 구성해야 하며, 기성 완료를 클릭하면 입력된 내용이 모두 사라지는 기능이 작동한다.
▪
기성전원 규칙이 설정되면 상위 값을 가져와서 클릭할 때 연결된 하위 항목까지 함께 변경되거나 사라지는 연동 구조로 작동한다.
◦
중요 참고사항:
▪
목표 공수 항목은 수정하면 안 되는 중요한 데이터로, '내용 편집 허용'이 아닌 '읽기 전용' 권한으로 초대해야 한다는 의견이 제시되었다.
▪
재목적서 정보 입력을 사모님에게 요청했으나, 순차적으로 진행되지 않고 아는 정보만 무작위로 입력되어 수동 처리의 필요성이 발생했다.
5. 인건비 및 단가 조정과 프로젝트 완료 처리
•
핵심 요점: 5. 작업자 단가 조정, 인건비 정산 내역 확인, 그리고 프로젝트 기성금 완료 처리 시스템에 대한 논의가 이루어졌다.
◦
부가 설명:
▪
작업자 단가를 23만 원에서 29만 원으로 조정하고, 식대는 1만 원으로 통일하기로 결정했다. 알바 공수 단가도 29만 원으로 통일 적용된다.
▪
건설사는 팀을 구분하지 않고 하나의 단위로 보는 반면, 재하도급업체는 팀별로 평가가 필요한 상황이므로, 기성금을 정확하게 쪼개는 기준이 필요하다는 문제가 제기되었다.
▪
6월과 7월분 서류는 서로 다른 방식으로 입력해야 하며, 6월분 서류는 7월 말에 입력할 수 있다고 확인했다.
▪
프로젝트의 실공수 입력 및 도급 금액 입력이 완료되면 "기성 완료" 버튼을 통해 해당 프로젝트의 완료 처리를 할 수 있다.
▪
기성이 완료된 프로젝트는 더 이상 화면에 표시할 필요가 없다고 합의하여, 해당 항목이 자동으로 시스템에서 사라지도록 설정할 예정이다.
◦
중요 참고사항:
▪
현재 시스템에서는 관리자 공수가 빠져 있어서, 관리자 공수와 날짜를 입력한 후 기성 완료 처리를 해야 한다. 관리자 공수는 데일리 방식으로 처리된다.
▪
기성금 관리에서 확인해야 할 항목은 기성금, 건설사, 날짜, 기성 상태이며, 한도는 확인할 필요가 없다고 최종 결정되었다.
6. 목표 공수 관리 및 시스템 자동화 한계
•
핵심 요점: 6. 목표 공수 산정의 중요성, 자동화 시스템의 한계, 그리고 Make(메이크)를 활용한 데이터 관리 방안이 논의되었다.
◦
부가 설명:
▪
목표 공수를 정확히 산정해야 잔여 공수 문제를 해결할 수 있지만, 총 공사 금액 정보 공개에 제약이 있어 산정이 어려운 점이 확인되었다.
▪
Make(메이크)를 활용하여 목표 공수를 104.5에서 617로 설정하고, 매일 목표 공수와 현재 값을 비교하여 차이가 있을 경우 자동으로 업데이트하는 로직이 제안되었다.
▪
하지만 목표 공수가 지속적으로 증가할 때 발생할 수 있는 시스템 문제에 대한 우려가 제기되었으며, 모든 항목이 변동될 수 있다면 데이터를 직접 입력하는 방식이 고려되었다.
▪
목표 공수 변경은 총 공사 금액과 연동되어 함께 달라지므로, 물량과 서브(하도급) 각각에 별도의 목표 공수와 다른 단가를 설정해야 한다.
◦
중요 참고사항:
▪
기존에 구축된 시스템을 Make로 연동하여 데이터를 끌어오는 작업이 핵심 관건이며, 팀별 성과급 지급을 위한 KPI 시스템은 구현 가능하지만 오류 발생 시 전체 시스템에 문제가 생길 수 있어 최종적으로 진행하지 않기로 결정했다.
▪
목표 공수 변경에 따라 데이터베이스와 연관된 시스템 틀 전체를 수정해야 하는 상황이 발생하며, 이는 단순한 작업이 아닌 복잡한 시스템 수정으로 이어진다.
7. 프로젝트 관리 시스템 개선 및 향후 계획
•
핵심 요점: 7. 프로젝트 일정 조율, 매뉴얼 및 영상 제작을 통한 업무 효율화, 그리고 시스템 기능 개선에 대한 논의가 진행되었다.
◦
부가 설명:
▪
예상하지 못한 추가 계약 발생으로 인해 새로운 업무가 생겼고, 이로 인해 일정 관리가 어려워져 랭킹 작업 등 주요 업무의 날짜를 미리 조율해야 하는 상황이 발생했다.
▪
매뉴얼을 제공하여 입력 방법을 안내하고, 대리님이 화면 캡처와 녹화를 진행하여 수치의 의미와 설명을 영상으로 제작하는 방식으로 업무를 분담하기로 했다.
▪
8월 19일과 20일을 주요 업무 진행일로 결정하고, 화자가 참석할 수 없는 날에는 김도경 과장이 대신 업무를 담당하기로 하는 등 프로젝트 일정을 조율했다.
▪
현재 작업 중인 프로세스를 완성한 후 영상 매뉴얼을 제작할 예정이며, 영상 촬영이 완료되면 마지막에 영상으로 한 번 더 시스템 테스트를 진행하기로 했다.
◦
중요 참고사항:
▪
초반 시스템 세팅 작업은 반드시 대리와 함께 진행해야 하며, 가이드 작성을 통해 새로운 항목들에 대한 이해도를 높일 필요가 있다.
▪
컨설팅 요청과 관련하여 데이터베이스 구축에 대한 이해도가 부족한 분들이 있어 복잡한 상황이 발생하고 있음을 언급했다.
