그룹 재무총감이 월말에 가장 시간을 많이 소요하는 작업은 대개 연결재무제표를 작성하기 위한 것입니다.각 자회사에 대한 Excel 회수 촉구: 과목 기준이 일치하지 않고, 고객 코드도 제각기 다르며, 내부 거래가 완전히 상계되지 않았습니다. 근본 원인은 재무 부서가 노력하지 않아서가 아니라,다중 주체 환경에서 통일된 조직, 권한 및 마스터 데이터 기반의 부재——각 자회사는 정보의 사일로로, 그룹은 ‘사후 조립’만 할 수 있다.
다중 주체 관리의 전형적인 애로점
- 조직 경계가 모호하다: 법인, 관리 단위, 이익센터, 원가센터를 혼용하여 사용하고 있어 보고서의 차원이 맞지 않습니다.
- 권한을 일괄적으로 제한하거나 전면적으로 개방하는 경우: 자회사가 그룹 뷰를 볼 수 없거나, 그룹이 자회사 세부 정보를 수정할 수 있어 갈등이 발생합니다.
- 주 데이터 분열: 동일한 고객이 서로 다른 자회사에서 서로 다른 코드를 가지고 있으며, 동일한 재료의 명칭과 규격 표기 방식이 일관되지 않아 구매와 재고 분석을 통합하는 것이 불가능합니다.
- 내부 거래는 상쇄하기 어렵다: 연계 판매, 자금 거래, 서비스 정산에 대한 시스템 기록이 없어, 합병 시 수작업으로 대조해야 합니다.
- 시스템 침묵: A 자회사는 특정 ERP를 사용하고, B는 또 다른 시스템을 사용하며, 그룹의 BI는 ODS 계층만 연동하여 강제로 데이터를 변환할 수밖에 없습니다.
비즈니스는 어떻게 나누어질까요: 조직, 권한, 주요 데이터의 3계층으로 구성됩니다.
조직 모델
권장 계층화:그룹 → 법인 주체(회사) → 사업 단위/사업부 → 부서 → 직무. 법인 주체는 다음에 사용됩니다법정 보고서와 세무; 비즈니스 단위는 사용됩니다관리 보고서 및 평가; 부서는 사용됩니다권한 및 승인 흐름. 한 사람은 여러 조직에 소속될 수 있지만(예를 들어 두 개의 자회사에서 동시에 임원을 겸임하는 경우),데이터 소유권명확히 해야 할 점은: 이 주문과 이 비용이 어느 법인, 어느 BU에 속하는지입니다.
권한 체계
채택하여RBAC + 데이터 범위: 역할 정의를 통한 기능 권한 설정(승인 가능 여부, 주요 데이터 수정 가능 여부); 데이터 범위에 따른 조회 및 작성 권한 경계 설정(자체 법인 내, 자사 BU 내, 그룹 전체의 읽기 전용, 법인 간 접근 시 권한 부여 필요). 핵심 원칙:
- 기본 최소 가시성: 자회사 사용자는 기본적으로 자사만 볼 수 있으며, 그룹 사용자는 집계를 확인할 수 있고 하위 항목으로의 드릴다운은 감사 기록이 남아야 합니다.
- 주 데이터 분급 유지 관리: 그룹급 주요 데이터(고객 그룹 계정, 그룹 재료)는 그룹 주요 데이터 담당자만 수정할 수 있으며, 자회사급 확장 필드는 자회사에서 유지보수할 수 있습니다.
- 주체 간 비즈니스에 대한 명시적 권한 부여: A 회사는 B 회사의 재고를 판매하며, 내부 거래 규칙과 양측의 조회 가능성을 설정해야 하므로 공유 계정에 의존해서는 안 됩니다.
주 데이터 거버넌스
핵심 주데이터 도메인:고객, 공급업체, 재료, 계정과목, 조직, 직원. 각 도메인 정의: 코드 규칙, 필수 속성, 유일성 제약, 변경 승인, 적용 버전. 그룹 고객의 ‘1고객 1코드’: 자회사가 입력 시먼저 그룹 라이브러리를 검색합니다., 일치하면 참조하고, 미일치 시에는 신규 승인을 진행합니다. 재료에 대해서도 동일한 원칙을 적용하여, ‘동일 품목에 여러 명칭’으로 인해 MRP와 구매가 통합되어 왜곡되는 것을 방지합니다.
어떻게 설계할 것인가: 테넌트, 계정 세트 및 통합 아키텍처
단일 데이터베이스 다중 테넌트 대 다중 데이터베이스 연합
단일 데이터베이스 다중 테넌트: 하나의 시스템,org_id데이터를 격리하여, 그룹의 강력한 관리와 높은 표준화 수준에 적합합니다.다중 재고 연합: 각 자회사의 독립된 인스턴스를 활용하며, 그룹 차원에서는 통합 플랫폼이나 MDM을 통해 동기화합니다. 이는 자회사의 자율성이 높고 기존 시스템의 이전이 어려운 경우에 적합합니다. 선택은 합병 보고서의 실시간성 요구사항, 자회사의 IT 역량, 규제상의 분리 요건 등에 따라 결정됩니다.
내부 거래 및 합병
시스템은 다음을 지원해야 합니다:내부 판매 주문, 내부 구매, 내부 정산가, 거래 대조. 합병 보고 엔진은 규칙에 따라 내부 수익/비용/거래를 자동으로 식별하고 상계 분개를 생성합니다(또는 합병 시스템으로 내보냅니다). 거래 차원의 기록이 없으면, 합병은 언제나 수작업으로 엑셀을 이용해야 합니다.
승인 및 프로세스는 주체를 넘나듭니다
그룹 차원의 제도(예: 자본지출, 중대 계약) 승인 체계는 법인을 넘나들 수 있습니다: 발기인 자회사 → 사업부 → 그룹 기능 부서 → 그룹 고위 경영진. 프로세스 엔진은 이를 지원해야 합니다.조직별 라우팅, 그리고 승인자는 자신의 데이터 범위 내의 영수증 세부정보만 볼 수 있습니다.
어떻게 적용할 것인가: 분기별 추진 로드맵과 검수
분할 결제를 권장합니다
- 조직 및 권한 기반: 법인/BU/부서 트리가上线되고, RBAC + 데이터 범위가 정상적으로 작동함.
- 그룹 주 데이터: 고객과 자재에 대해 1고객 1코드/1물품 1코드를 적용하며, 자회사는 이를 연동하여 활용합니다.
- 내부 거래: 연계 구매·판매 및 왕래 대장 정산 기능이 출시되었습니다.
- 합병 보고서: 내보내기 상쇄 템플릿에서 시스템의 반자동 방식을 거쳐 완전 자동화까지.
검수 기준
- 신규 고객이 어느 자회사에서 생성될 때,중복률 검사발효되었으며, 그룹 계정은 연계 조회가 가능합니다.
- 자회사 사용자권한을 초과할 수 없습니다다른 법인 내역을 확인하십시오(보안 테스트 통과).
- 내부거래 명세서 및 연결상계 대차대조표 초안원클릭으로 내보낼 수 있습니다., 재무 수기 표와의 차이 < 약정 임계값.
주체 간 협업의 전형적인 시나리오
그룹 내 A 회사가 생산하고 B 회사가 판매할 때, 시스템은 다음을 지원해야 합니다:내부 이전 가격(주체 간의 부당한 이익 이전으로 인한 세무 리스크를 방지하기 위해),공유 재고 가시성（B는 판매 약속 시 A의 완제품 가용량을 확인할 수 있다.）통합 고객 뷰(그룹 계정이 어느 자회사에서 주문을 하면, 이전 주문을 연계하여 조회할 수 있습니다.) 이러한 업무 환경에서 이메일로 조율할 경우 응답 시간이 며칠 단위로 소요되지만, 통합된 조직과 주 데이터 기반을 구축하면 시간 단위로 단축할 수 있습니다.
또 다른 일반적인 요구사항은그룹 구매 집중: 집중 구매 계약, 분산 수령, 법인별 정산. 설계 시 명확히 해야 할 사항은 다음과 같습니다: PO는 누가 발주하고, 수령은 누가 확인하며, 송장은 누가 매칭하고, 결제는 누가 개시하는지—이 네 가지 단계에서 세 개의 법인이 관여할 수 있으므로, 프로세스 라우팅은 반드시 조직도에 따라 자동으로 업무를 배정해야 하며, 인력이 수동으로 @ 해당 회계 담당자를 지정해서는 안 됩니다.
흔히 발생하는 실수
조직 트리만 있고 데이터 범위는 없습니다.: 기능 권한은 생겼지만, 데이터는 여전히 그룹 전체에서 노출된 상태입니다.주 데이터의 운동식 정리: 출시 전에 급하게 통일을 진행했고, 출시 후에는 유지보수 담당 부서가 없어 석 달 만에 다시 혼란스러워졌다.자회사의 변화 저항을 간과하다: 그룹 코드 강제 적용이 저항을 받고 있어, 이에 대한 인센티브와 전환 매핑 테이블이 필요하다.합병은 재무만 담당하고 업무는 검토하지 않습니다.: 비즈니스 주요 데이터가 정확하지 않으면, 합산 수치가 아무리 정확하더라도 경영 의사결정을 뒷받침할 수 없습니다.
그룹의 다주체 디지털 지능화 목표는 ‘자회사의 유연한 경영’과 ‘그룹의 가시성 및 관리 가능성’이 동일한 규칙 하에서 공존하도록 하는 것이며, 이는 끝없는 보고서 추심 전쟁을 의미하지 않습니다.
Shandong XYN Information Technology Co., Ltd.(XYN Tech)는 그룹형 기업을 대상으로 다중 조직의 CRM, 주 데이터 관리 및 합병 보고서 관련 디지털 지능형 시스템을 제공합니다. 자세한 내용은 아래를 참조하십시오.xynadmin.com。