개요
이 영상 스크립트는 건설업체 서우HR이 공수 관리의 비효율성과 수익성 예측의 어려움을 해결하기 위해 노션(Notion) 기반 자동화 시스템 구축을 논의하는 컨설팅 과정을 담고 있습니다. 현재 엑셀 중심의 수기 관리 방식은 데이터 입력의 부정확성, 실시간 현황 파악의 한계, 복잡한 정산 과정 등의 문제를 야기하고 있습니다.
컨설턴트는 워크플로우 분석의 중요성을 강조하며, 이를 바탕으로 체계적인 데이터베이스 구조 설계 및 자동화 방안을 제시합니다. 논의의 핵심은 건설 현장의 특수성(물량 기반 계약과 인건비 기반 실제 투입의 불일치, 다양한 공정 및 작업 단위, 현장별 데이터 관리 등)을 고려한 맞춤형 노션 시스템을 구축하여, 공수 데이터의 정확성을 높이고, 실시간으로 수익성을 추적하며, 관련 업무를 자동화하여 궁극적으로 업무 효율성을 극대화하는 데 있습니다.
주요 학습 포인트
•
건설업 공수 관리의 문제점 및 노션을 활용한 해결 방안 모색
•
워크플로우 분석을 통한 체계적인 데이터베이스(DB) 설계 방법론
•
건설 현장 특성을 반영한 노션 DB 구조화 (공정, 현장, 작업일지, 목표 공수, 물량 등)
•
실시간 수익성 분석 및 예측을 위한 데이터 관리 전략
•
노션 자동화(Make/Integromat 등 활용)를 통한 업무 효율화 아이디어 및 구현 논의
•
데이터 접근 권한 관리 및 민감 정보 보호를 위한 노션 활용 방안
•
복잡한 정산 및 리포팅 과정을 노션으로 간소화하는 방법론
요약
1. 컨설팅 목표 및 현재 워크플로우 분석의 중요성
•
주제: 건설업 공수 관리 및 노션 자동화 시스템 구축 컨설팅 시작
•
핵심 요점:
1.
워크플로우 분석 우선: 컨설팅의 첫 단계는 현재 업무 흐름(워크플로우)을 상세히 파악하고 분석하는 것입니다. 이는 데이터베이스 구조 설계의 기초가 됩니다.
•
헤드헌팅 업체의 ATS(자원 관리) 시스템 구축 사례: 프로젝트 수주 -> 후보자 선택 -> JD 메일 발송 -> CV 발송 등의 프로세스를 분석하여 시스템화.
•
치과 채용 프로세스 사례: 채용 과정의 흐름을 분석하여 데이터베이스 구조화.
2.
데이터베이스 구조화: 분석된 워크플로우를 기반으로 노션 데이터베이스를 어떻게 구성할지 결정합니다.
3.
작업 방식 결정: 워크플로우 분석 후, 컨설턴트가 직접 고객사 노션에 초대되어 페이지를 제작할지, 또는 자동화 구축을 위해 워크스페이스 계정을 받아 작업할지 결정합니다.
•
부가 설명:
◦
고객사(서우HR)는 플렉스(Flex) 기반으로 업무가 진행되고 있음을 어렴풋이 파악하고 있으며, 이에 대한 상세 설명이 필요합니다.
•
중요 참고사항:
◦
정확한 워크플로우 분석이 선행되어야 효과적인 노션 시스템 설계 및 자동화 구축이 가능합니다.
2. 건설업 공수 관리 현황 및 문제점 (수익성 분석의 어려움)
•
주제: 건설업 특유의 공수 관리 방식과 수익성 분석의 핵심 문제점 설명
•
핵심 요점:
1.
계약 방식과 실제 투입의 불일치: 전문 건설사는 건설사로부터 물량(면적 기반)으로 금액을 받지만(예: 1만 제곱미터를 2억에 계약), 실제 작업 팀에게는 인건비(공수 x 단가)를 기준으로 비용을 지급합니다.
•
이로 인해 계약 금액과 실제 지출 비용 간의 차이가 발생하며, 이것이 수익성 분석의 핵심입니다.
2.
수익성 예측의 필요성: 계약된 금액(예: 1억 5천) 내에서 인건비를 지출해야 하지만, 실제 투입 인건비는 변동 가능(예: 6천만 원 또는 4천만 원)하여 팀별로 차액(수익 또는 손실)이 발생합니다.
•
목표는 이 수익성 차이를 정확하게 계산하고 실시간으로 예측하는 것입니다.
3.
실시간 예측의 중요성: 손실이 발생하는 경우, 월말 정산 시점에서는 이미 늦어 대응이 어렵습니다. 따라서 작업 진행 중 실시간으로 수익성을 예측하고 대응할 수 있는 시스템이 필요합니다.
•
부가 설명:
◦
공수: 작업에 투입된 인력의 양 (예: 1명이 하루 일하는 것을 1공수).
◦
단가: 1공수당 책정된 비용 (예: 20만 원).
◦
인건비 = 공수 x 단가.
◦
고객사는 여러 팀(예: 팀1, 팀2)에게 작업을 분배하고, 각 팀의 인건비 합계가 계약금보다 적어야 수익이 남는 구조입니다.
•
중요 참고사항:
◦
물량 기반 계약과 인건비 기반 실제 지출 사이의 괴리가 건설업 수익성 관리의 핵심 과제입니다.
◦
손실 발생 시 즉각적인 대응을 위해 실시간 예측 시스템이 필수적입니다.
3. 공수 및 물량 데이터 기록 시점 및 방식
•
주제: 공수 및 물량 데이터 기록 시점, 방법 및 실시간 확인 요구사항
•
핵심 요점:
1.
공수 및 작업 기록: 매일 투입된 인원(공수)과 수행한 작업 내용(공사 작업)이 기록됩니다.
•
예: 오늘 2명이 알폼보 작업을 했다는 사실을 당일 알 수 있음.
•
이를 통해 작업 진행 상황을 실시간으로 파악 가능.
2.
실시간 수익성 확인 요구: 월 단위 정산이 아닌, 사실상 실시간으로 공수 및 작업량에 따른 수익성 변화를 트래킹하고 싶어합니다.
•
프로젝트 기간 중 중간 점검이 아니라, 초기부터 지속적인 확인을 원함.
3.
작업 구간의 세분화: 전체 물량(예: 2,500)은 여러 세부 작업 구간(예: 층 A1 알콘 보, 알콘 슬래브 등)으로 나뉘며, 각 구간마다 물량이 할당됩니다.
•
각 세부 작업 구간의 진행 상황을 모니터링하여 전체 프로젝트의 수익성에 미치는 영향을 파악해야 합니다.
•
부가 설명:
◦
공수 기록은 익일 작업 계획에도 영향을 줄 수 있습니다.
◦
현재는 월별로 계산하지만, 데이터 자체는 실시간으로 집계될 수 있는 구조입니다.
◦
돈의 실제 지급은 프로젝트 완료 후 일괄적으로 이루어지지만, 데이터는 계속 누적 관리됩니다.
•
중요 참고사항:
◦
정확한 실시간 데이터 기록이 수익성 예측의 정확도를 높이는 핵심입니다.
◦
세분화된 작업 구간별 관리가 필요합니다.
4. 기존 엑셀 기반 공수 및 생산성 관리 방식 설명
•
주제: 현재 사용 중인 엑셀 기반의 공수 및 생산성 관리 시스템 소개
•
핵심 요점:
1.
총 공사 금액 확정: 1제곱미터당 단가를 설정하여 총 공사 금액을 확정합니다. 이 금액 내에서 공사를 완료해야 수익이 발생합니다.
2.
목표 생산성 및 목표 공수 설정:
•
목표 생산성: 1공수당 달성해야 하는 최소 생산 금액 (예: 32만 원, 이 중 3만 원이 이익 목표). 인건비, 투입비 등이 포함된 개념.
•
목표 공수: 총 공사 금액을 목표 생산성으로 나누어, 전체 프로젝트를 완료하는 데 필요한 총 공수를 산출합니다. (예: 8,438 공수)
3.
실제 투입 공수 및 잔여 공수 관리:
•
실제 투입된 공수를 기록하고, 목표 공수에서 차감하여 잔여 공수를 관리합니다.
•
실제 생산성 = 실제 작업 가치 / 실제 투입 공수. 이것이 목표 생산성(32만 원)에 미치지 못하면 손실 발생.
4.
인건비 계산: 개인별/공정별 단가(형틀 공정 등)에 실제 투입 공수를 곱하여 인건비를 계산합니다.
•
부가 설명:
◦
엑셀 시트에는 총 공사 금액, 목표 생산성, 목표 공수, 실제 투입 공수, 잔여 공수, 실제 생산성, 예상 수익 등의 항목이 포함됩니다.
◦
실제 투입 공수는 매일 누적되어 기록됩니다.
•
중요 참고사항:
◦
목표 생산성 달성 여부가 수익성을 좌우하는 중요한 지표입니다.
◦
엑셀 데이터는 실시간 투입 공수 변화에 따라 동적으로 업데이트됩니다.
5. 현장 데이터 입력의 문제점 및 공수 계산의 모호성
•
주제: 현장에서 실제 투입 공수 및 작업 진행률 입력 시 발생하는 문제점과 공수 계산의 애매함
•
핵심 요점:
1.
입력 시간 소요 및 부정확성: 실제 투입 공수 입력에 시간이 오래 걸리고, 현장 관리자의 눈대중으로 기록되는 경우가 있어 데이터의 정확성이 떨어집니다.
2.
작업 진행률 입력 누락: 작업 진행률을 제대로 기록하지 않아 정확한 트래킹이 어렵습니다. (이로 인해 내부적으로 갈등 발생)
3.
공수 계산의 모호성:
•
1공수 = 1명이 하루 8시간(예: 오전 7시~오후 5시, 식사시간 1시간 제외) 근무.
•
"4명이 반나절 작업하여 2공수"와 같이 기록되는 경우, 실제 작업 시간이나 효율성을 정확히 반영하기 어려움. (4명 x 4시간 = 16시간 = 2공수)
•
이는 실제 투입 인원과 기록된 공수 간의 불일치를 야기할 수 있으며, 눈대중으로 판단하는 경향이 있습니다.
4.
현장 입력 방식: 노션에 익숙하지 않은 현장 작업자를 위해 출력 일지(수기 작성 양식)를 제공하고, 이를 바탕으로 사무실에서 입력하거나, 노션 버튼을 통해 직접 입력하는 방식을 혼용합니다.
•
부가 설명:
◦
모든 정보(특히 공수)가 눈대중으로 기록될 가능성이 있어 데이터 신뢰도에 문제가 생길 수 있습니다.
◦
작업 완료율이 100%가 아니어도 월별 임금 지급을 위해 작업률을 산정해야 하는 상황이 발생하며, 이때 유보금을 설정하거나 다음 달로 이월하는 등의 복잡한 처리가 필요합니다.
•
중요 참고사항:
◦
정확하고 일관된 데이터 입력 체계 마련이 시급합니다.
◦
공수 계산 기준을 명확히 하고, 현장 작업자들이 쉽게 입력할 수 있는 인터페이스 제공이 중요합니다.
6. 노션 데이터베이스 구조 논의: 공정, 현장별 DB 관리 방안
•
주제: 공정 종류에 따른 DB 구성 및 현장별 데이터 관리 방식 논의
•
핵심 요점:
1.
공정 종류: 현재 주요 공정은 형틀, 알폼(알루미늄폼) 두 가지이며, 추후 해체정리 등이 추가될 수 있습니다.
•
형틀: 나무로 거푸집을 만드는 방식. 복잡한 건물 모양에 유연하게 대응 가능. 해체 후 정리 작업 필요.
•
알폼: 알루미늄으로 제작된 규격화된 폼. 아파트처럼 반복적인 구조에 적합. 조립이 간편하고 해체 정리가 거의 불필요.
2.
데이터베이스 분리 vs. 통합:
•
현재 방식: 현장별(예: 안양 테일)로 데이터베이스(형틀 출력일지, 형틀 작업일지, 알폼 출력일지, 알폼 작업일지, 목조 공사 등 5개 DB)를 분리하여 관리.
•
문제점: 새 현장 발생 시마다 DB를 복제해야 하며, 이 경우 데이터가 정형화되지 않아 다른 DB와의 연동 및 자동화(메이크 등)에 어려움 발생.
•
제안: 모든 데이터를 하나의 DB로 통합하고, '현장' 속성을 추가하여 구분하는 방식. (예: 형틀 작업일지 DB 하나에 모든 현장 데이터 포함)
3.
데이터 접근 권한:
•
현장 관리자는 자신의 현장 페이지만 접근 가능.
•
전체 관리자는 모든 현장 데이터 접근 가능.
•
수익성 관련 민감 정보는 특정 관리자만 접근.
•
부가 설명:
◦
'알품 출력 일지' 등은 현장명 + 작업 종류로 구성된 DB 이름입니다.
◦
각 현장마다 유사한 패턴의 DB 5개가 반복되는 구조로 사용 중입니다.
◦
통합 DB 사용 시, 특정 현장 작업자가 다른 현장 데이터를 보지 못하도록 권한 설정이 중요합니다.
•
중요 참고사항:
◦
데이터베이스 구조는 확장성, 자동화 연동성, 권한 관리를 모두 고려하여 설계해야 합니다.
◦
초기 설계가 잘못되면 추후 수정이 매우 어렵습니다.
7. 노션 입력 방식 개선 및 데이터 통합 가능성 검토
•
주제: 현장 데이터 입력 방식 개선(노션 폼 활용) 및 DB 통합 시 권한 문제 해결 방안
•
핵심 요점:
1.
현장 입력 방식의 어려움: 현장 관리자들은 컴퓨터 사용이 익숙하지 않아, 현재는 수기 일지를 제출하거나 사무실 직원이 대신 입력, 또는 노션 페이지 내 버튼을 통해 제한적으로 입력합니다.
2.
노션 폼(Form) 활용 제안: 데이터 입력을 노션 폼으로 표준화하면, 현장 작업자들이 DB 직접 접근 없이 필요한 정보만 입력하게 할 수 있습니다.
•
폼 제출 시 생성자를 특정 관리자로 지정하고, 각 작업자는 자신이 입력한 내용만 보거나 제한된 정보만 볼 수 있도록 설정 가능.
•
이를 통해 여러 현장의 데이터를 하나의 DB로 통합하면서도 권한 문제를 해결할 수 있습니다.
3.
DB 통합의 이점: 형틀, 알폼 등 공정별 DB를 하나로 합치고 '공정' 속성으로 구분하면 DB 개수를 크게 줄일 수 있습니다. (예: 출력 DB 1개, 작업일지 DB 1개)
4.
기존 데이터 마이그레이션: 시스템 구축 시점을 기준으로, 과거 데이터는 기존 방식대로 두고 새로운 시스템에는 신규 데이터부터 입력하는 것을 권장합니다. (과거 데이터 이전은 매우 복잡함)
•
부가 설명:
◦
현장 작업자들은 주로 핸드폰으로 노션 사용법 영상을 보고 버튼을 눌러 입력합니다.
◦
현재 '출력 이름'(작업자 이름)은 색상으로 팀을 구분 (빨간색: 관리자, 파란색: 개인, 기타색: 팀 소속, 회색: 과거 작업자)하고, 팀장은 이름 뒤에 '공짜'를 붙여 표시합니다.
•
중요 참고사항:
◦
노션 폼을 사용하면 입력 편의성과 데이터 정형화를 동시에 달성할 수 있습니다.
◦
DB 통합 시, 속성 설계를 통해 기존의 복잡한 분류 체계를 단순화할 수 있습니다.
8. 출력일보와 작업일지 데이터 연동 및 공수 계산 로직
•
주제: 출력일보(출근부)와 작업일지(실제 작업내역)의 구분 및 데이터 연동, 공수 계산 방식
•
핵심 요점:
1.
출력일보 vs. 작업일지:
•
출력일보: 해당 날짜에 몇 명이 출근했는지(총 공수)를 기록. (사람 중심)
•
작업일지: 출근한 인원들이 어떤 세부 작업을 얼마나 수행했는지를 기록. (작업 중심)
•
출력일보의 총 공수와 작업일지에 기록된 각 작업별 공수의 합이 일치해야 하나, 다를 수도 있음 (예: 13명 출근(13공수), 5개 작업을 13명이 나눠서 수행).
2.
데이터 연동: 작업일지에 기록된 공수 데이터가 목표 공수 DB의 '누적 공수'로 자동 합산되도록 구성하는 것이 목표입니다.
3.
공정 시각화: 형틀(나무 거푸집), 알폼(알루미늄 거푸집) 작업 방식을 시각 자료(유튜브 등)를 통해 이해를 돕습니다.
•
알폼은 규격화되어 있어 레고처럼 조립하므로 반복 작업 시 도면 없이 작업 가능. 형틀은 작업자의 판단과 기술이 더 요구됨.
•
부가 설명:
◦
'출력'이라는 용어는 건설 현장에서 '출근' 또는 '인원 투입'을 의미합니다.
◦
하나의 '출력일보'(날짜별 총 공수)에 여러 개의 '작업일지'(세부 작업별 공수)가 연결될 수 있습니다.
•
중요 참고사항:
◦
데이터 입력 오류(예: 날짜 필드 삭제)는 폼 기반 입력 및 권한 설정을 통해 방지할 수 있습니다.
◦
현장에서 입력 정확도를 높이는 것은 시스템의 성공적인 운영에 매우 중요하지만, 이번 프로젝트 범위에서는 고객사 내부적으로 해결할 문제로 간주합니다.
9. 전체 워크플로우 및 노션 시스템 구성안 논의
•
주제: 프로젝트 수주부터 정산까지의 전체 워크플로우 및 이에 따른 노션 DB 구성 및 자동화 지점 논의
•
핵심 요점:
1.
건설 프로젝트 워크플로우:
•
영업 (수주) -> 도면 요청 -> 물량 산출 (수익성 검토) -> 단가 설정 (m²당 단가, 인건비 등) 및 계약 -> 인원 투입 -> 현장 작업 정보 입력 (출력일보, 작업일지) -> 사무실 서류 작업 및 수익성 지속 확인 -> 월말 제출 서류 작성 및 건설사 제출 -> 건설사로부터 노무비 명세서 및 대금 수령 -> 근로자에게 임금 지급.
2.
노션 DB 자동 입력 지점:
•
현장에서 매일 입력하는 출력일보 및 작업일지 데이터.
•
이 데이터를 기반으로 목표 공수 DB의 누적 공수 자동 업데이트 및 수익성 실시간 계산.
3.
데이터베이스 구성 (잠정):
•
출력일보 DB (형틀, 알폼, 철거 등 공정별 또는 통합)
•
작업일지 DB (형틀, 알폼, 철거 등 공정별 또는 통합)
•
목표 공수 DB (프로젝트의 각 태스크별 목표치 관리)
•
물량 DB (추가 논의 필요)
4.
단가의 복잡성: 작업(거푸집 크기 등), 공정(형틀, 해체 등), 계약 주체(건설사 지급 단가, 우리가 하청 주는 단가), 단위(면적당, 인원당)에 따라 단가가 매우 다양하여 DB 설계 시 반영 필요.
•
부가 설명:
◦
고객사는 매월 1일부터 누적되는 수익성을 실시간으로 확인하고 싶어합니다.
◦
현재 엑셀로 관리 중인 복잡한 월간 수익률 보고서(작업 완료율, 지급률, 팀별 수익금 등 포함)를 노션에서 구현하거나 연동하는 방안 모색.
•
중요 참고사항:
◦
단가 체계가 복잡하므로, 이를 어떻게 DB에 구조화하고 계산 로직에 반영할지가 핵심 과제입니다.
◦
기존 엑셀의 복잡한 로직(VBA 등)을 노션으로 완전히 대체하기 어려울 수 있으며, 데이터 추출 후 엑셀에서 후처리하는 방안도 고려될 수 있습니다.
10. 세부 데이터베이스 설계: 목표 공수, 물량, 단가 관리
•
주제: 목표 공수, 물량, 단가 관련 데이터베이스의 세부 항목 및 연동 방안 심층 논의
•
핵심 요점:
1.
목표 공수 DB의 역할: 개별 작업(태스크)별로 목표 공수, 누적 공수, 공수 차이, 잔여 공수, 작업 진행률 등을 관리합니다.
•
누적 공수는 작업일지에서 자동으로 합산되어 반영.
•
잔여 공수가 마이너스(-)가 되면 시각적 경고(예: 빨간색 표시) 필요.
2.
물량 DB의 필요성: 각 작업 구간별 물량(면적, 개수, 길이 등)과 단가를 관리하여 총 공사 금액 및 목표 공수 산출의 기초 데이터로 활용.
•
물량 DB에 입력된 값을 기반으로 목표 공수 DB의 목표 공수가 자동 계산되기를 희망.
3.
단가 정보 관리의 복잡성:
•
건설사로부터 받는 단가 vs. 우리가 팀에게 지급하는 단가.
•
작업별, 층별, 팀별로 단가가 다를 수 있음 (예: 장동민 팀장 단가 45만 원, 일반 인부 20만 원).
•
이러한 다양한 단가 정보를 어떻게 DB에 저장하고 수익성 계산에 반영할지가 중요.
4.
데이터 접근 권한 문제 재확인: 도면팀은 물량 및 단가 정보를 입력하지만, 현장 근로자는 민감한 금액 정보를 보면 안 됨. 이를 위해 DB를 분리하거나, 특정 속성을 숨기는 기능이 필요하나 노션의 기본 기능으로는 한계가 있음 (숨김 해제 가능).
•
부가 설명:
◦
작업 진행률은 현장의 눈대중으로 입력될 가능성이 높아, 정확도 확보 방안이 필요.
◦
엑셀에서는 복잡한 수식과 피벗 테이블로 관리되던 내용들을 노션의 관계형 DB와 롤업/수식 기능으로 구현 시도.
◦
팀별 단가 차이, 특히 알폼 작업에서 재하도급을 주는 경우 단가 구조가 더욱 복잡해짐.
•
중요 참고사항:
◦
민감 정보(단가, 금액 등)의 접근 권한 제어는 노션 시스템 설계 시 매우 중요한 고려사항입니다. 외부 솔루션(예: 우피) 사용도 검토 대상.
◦
복잡한 단가 체계를 반영하기 위해 별도의 '단가 마스터 DB' 구축이 필요할 수 있습니다.
11. 데이터베이스 통합 및 권한 관리 심화: 현장별 페이지 구성
•
주제: 여러 DB(출력일보, 작업일지, 목표공수 등)를 현장 중심으로 통합하고, 현장별 접근 권한을 설정하는 방안
•
핵심 요점:
1.
현장 DB의 필요성: 각 현장(예: 마곡, 휘경, 안양 등)을 고유하게 식별하고, 현장별 데이터를 집계/분석하기 위해 '현장 DB'를 별도로 구성합니다.
•
현장 DB에는 현장 코드, 현장명 등의 정보가 포함됩니다.
2.
현장별 페이지 구성 및 필터링:
•
각 현장마다 전용 노션 페이지를 만들고, 해당 페이지 내에는 그 현장과 관련된 데이터(출력일보, 작업일지 등)만 보이도록 필터를 적용합니다.
•
현장 총괄 담당자는 자신의 현장 페이지만 접근하고 데이터를 입력/조회할 수 있습니다.
3.
데이터 입력 흐름 및 권한:
•
현장 작업자는 자신의 현장 페이지 내에서 출력일보, 작업일지를 입력합니다. (폼 사용 대신 페이지 내 직접 입력 방식 선호)
•
사무실(도면팀 등)에서는 물량 정보, 목표 공수 등을 입력합니다.
•
민감한 정보(단가, 전체 수익성 등)는 사무실 관리자만 접근 가능한 별도 DB 또는 뷰에서 관리합니다.
4.
공개용/비공개용 DB 분리 전략: 현장 작업자가 보는 DB(또는 뷰)와 사무실 관리자가 보는 DB를 분리하여, 동일 데이터 소스를 사용하되 보여주는 정보의 범위를 다르게 설정합니다.
•
예: '목표 공수 (현장용)' DB와 '목표 공수 (사무용)' DB를 만들어, 사무용에는 단가/금액 정보를 포함하고 현장용에는 제외. 데이터는 자동화(Make 등)로 동기화.
•
부가 설명:
◦
현장 총괄 담당자를 노션의 '사용자' 속성으로 지정하고, 페이지 공유 시 '자신이 담당하는 항목만 보도록' 설정하여 권한 관리 가능.
◦
하나의 마스터 DB를 두고, 각 현장 페이지에서는 필터링된 뷰(View)를 제공하는 방식으로 구성.
•
중요 참고사항:
◦
페이지 내 필터링 방식은 폼 사용을 어렵게 만들 수 있으므로, 입력 편의성을 고려한 UI 설계가 중요합니다.
◦
자동화 도구(Make)를 사용하여 공개용 DB와 비공개용 DB 간의 데이터 동기화 및 관계 설정을 정교하게 구축해야 합니다.
12. 노션 자동화(Make) 설정 및 세부 로직 논의
•
주제: Make(구 Integromat)를 활용한 노션 자동화 설정 및 구체적인 데이터 처리 로직 논의
•
핵심 요점:
1.
자동화 대상 작업:
•
현장 작업자가 '입력 완료' 버튼 클릭 시, 해당 데이터(출력일보/작업일지)와 연결된 '목표 공수 (사무용)' DB에 관련 정보(페이지 ID 등)를 업데이트하고 관계를 설정합니다.
•
작업일지에 입력된 공수를 '목표 공수' DB의 '누적 공수' 필드에 자동으로 합산합니다.
•
'물량' DB 입력 완료 시, '목표 공수' DB에 관련 데이터(수량, 단가 제외)를 이전하고 목표 공수 자동 계산.
2.
데이터 매칭 로직: 서로 다른 DB 간의 데이터를 연결할 때, '작업 이름'과 '현장 이름'이 모두 일치하는 경우를 기준으로 관계를 설정합니다. (현장이 달라도 작업 이름이 같을 수 있기 때문)
3.
데이터 타입 변환: 관계형으로 연결된 페이지 ID는 URL 형태로 표시되므로, 이를 텍스트로 변환하여 비교하거나 다른 필드에 저장하는 작업이 필요할 수 있습니다.
4.
작업 진행률 업데이트: 동일 작업이 여러 날에 걸쳐 진행될 경우, 가장 최근에 입력된 작업 진행률을 해당 작업의 최종 진행률로 간주하여 '목표 공수' DB에 반영합니다.
5.
Make 시나리오 비용: 작업일지 한 줄 입력 시마다 Make 시나리오가 실행될 가능성이 높으므로, 월간 작업량에 따라 Make 유료 플랜 비용이 발생합니다. (평균 4~5개 작업, 월 5만원 내외 예상)
•
부가 설명:
◦
목표 공수 계산 시 소수점 처리 기준(예: 한 자리까지 표시, 두 번째 자리부터 버림)을 명확히 해야 합니다.
◦
Make 시나리오 실행 상태는 로그를 통해 확인할 수 있으며, 오류 발생 시 디버깅이 필요합니다.
•
중요 참고사항:
◦
필드명 변경 시 Make 자동화 시나리오에 오류가 발생할 수 있으므로, DB 설계 확정 후 필드명 변경에 신중해야 합니다.
◦
데이터가 많아질수록 노션 페이지 로딩 속도가 느려질 수 있으므로, 효율적인 DB 구조와 쿼리 사용이 중요합니다.
13. 알폼 작업의 복잡한 단가 구조 및 DB 추가 설계 필요성
•
주제: 알폼(Alform) 작업의 재하도급으로 인한 복잡한 단가 구조와 이를 반영하기 위한 DB 추가 설계 논의
•
핵심 요점:
1.
알폼 작업의 단가 분할: 알폼 작업의 경우, 특정 작업을 여러 팀(예: 알폼 1팀, 알폼 2팀)에게 재하도급을 주며, 각 팀마다 다른 단가를 적용합니다.
•
예: 특정 작업에 대해 건설사로부터 받는 단가는 정해져 있지만, 내부적으로는 알폼 1팀, 알폼 2팀, 그리고 형틀팀(알폼 작업 지원 시)에게 각각 다른 금액으로 분배.
•
이 분배된 금액의 합이 건설사 지급 단가와 일치하거나, 차액이 회사의 수익 또는 예비비가 됨.
2.
DB 추가 설계 제안: 이 복잡한 단가 구조를 반영하기 위해 기존 '물량 DB' 또는 '목표 공수 DB' 하위에 서브(Sub) DB를 만들어 팀별 단가 정보를 관리해야 합니다.
•
기존 방식의 한계: 엑셀에서는 여러 줄의 데이터를 합산하여 상위 항목에 표시하지만, 노션의 기본 관계형 DB 구조로는 이러한 계층적 합산(부모-자식 관계에서의 자동 롤업)이 원하는 방식으로 직접 구현되기 어려움.
•
서브 DB의 역할: 각 작업(물량 또는 목표 공수)에 대해 여러 팀의 단가 정보를 개별 레코드로 저장하고, 이 서브 DB의 값들을 합산하여 원래 작업의 총비용 또는 수익을 계산.
3.
데이터 흐름: 현장 작업일지 입력 -> (자동화) -> 목표 공수 서브 DB와 연결 -> 목표 공수 서브 DB의 값들이 합산되어 목표 공수 메인 DB에 반영.
•
부가 설명:
◦
형틀 작업은 일반적으로 단가 구조가 단순하여 서브 DB까지 필요하지 않을 수 있지만, 알폼은 필수적입니다.
◦
세팅층(초기 조립 구간) 작업은 난이도가 높아 별도 단가 협상이 이루어지기도 합니다.
◦
월간 리포트 DB도 추가하여, 각 월별로 집계된 데이터를 바탕으로 최종 보고서를 생성할 수 있도록 구성.
•
중요 참고사항:
◦
노션에서 ERP 수준의 복잡한 계층적 데이터 구조 및 계산 로직을 구현하는 것은 상당한 전문성과 DB 이해도를 요구합니다.
◦
데이터는 최소 단위로 분리하여 저장하고(Input DB), 필요한 형태로 가공하여 보여주는(Output/Report DB) 방식이 권장됩니다. 외부용/내부용 단가 정보도 이러한 원칙에 따라 분리 관리 가능.
14. 컨설팅 마무리 및 향후 진행 계획
•
주제: 당일 컨설팅 주요 내용 정리 및 다음 단계 진행 계획 안내
•
핵심 요점:
1.
주요 논의 사항 복기: 알폼 작업의 복잡한 팀별 단가 구조와 이를 위한 서브 DB 필요성, 인건비 관리 DB의 필요성 등이 주요 쟁점으로 남았습니다.
2.
인건비 관리의 중요성: 정확한 수익 계산을 위해서는 총 공사 금액에서 실제 투입된 인건비를 빼야 하므로, 인건비(개인별 단가, 팀별 단가 등 포함)를 관리하는 DB와 계산 로직이 필수적입니다.
•
현재는 대표의 지침에 따라 알폼/형틀별 대략적인 인건비 단가를 적용하여 수익을 계산하고 있으나, 더 정교한 관리가 필요.
3.
추가 논의 필요: 단가 및 인건비 관련 DB 구조와 계산 로직은 복잡성이 높아, 다음 컨설팅 세션(내일 원격 진행 예정)에서 더 구체적으로 논의하기로 합니다.
4.
노션 계정 및 자동화 툴(Make) 준비: 컨설턴트가 실제 시스템 구축 작업을 진행하기 위해 고객사 노션 워크스페이스 접근 권한(멤버 초대) 및 Make 계정 정보 공유가 필요합니다.
•
부가 설명:
◦
고객사는 최종 결과물을 엑셀로도 추출하여 보고해야 하는 요구사항이 있으므로, 노션에서 데이터를 쉽게 복사/붙여넣기 할 수 있는 형태로 페이지를 구성할 예정입니다.
◦
DB 설계 시, 어떤 정보가 내부용이고 어떤 정보가 외부 공개용인지 명확히 구분하여 접근 권한 및 정보 표시 수준을 조절해야 합니다.
•
중요 참고사항:
◦
성공적인 노션 시스템 구축을 위해서는 초기 DB 설계 단계에서의 심도 있는 논의와 고객사의 적극적인 참여가 매우 중요합니다.
◦
구축 과정에서 지속적인 테스트와 피드백을 통해 시스템을 개선해나가야 합니다.
