260623 메딕스 내부 위클리
2026년 6월 23일 공유
최종 컨펌은 바꿔주기로 함. 우선 완료된 것부터 진행하기로 함. (회의 중 긴장감 언급됨) 형업도 4개에 대한 존재 조건 확인 중. 치크 공간 기사는 윗분들께 보고 후 전달 대기 중. 메딕스의 핵심 수익 구조는 제약사를 대신해 영업을 수행하는 것이며, 최종적으로 약국에서 약이 판매되어 처방이 완료되어야 수익이 발생하는 구조임. 또한, 도매 매출 자료와 약국 처방 데이터를 대조하여 실제 처방량과 도매 매출 간의 정합성을 확인하는 과정이 중요하게 다뤄짐 (예: 특정 상품의 처방액과 도매 매출액 비교). 특히 비병원 연계 방식의 경우, 병원 연계와 달리 처방 데이터 정합성 확인이 어려워 별도의 관리 방식이 필요함. 회의 중 특정 상품들의 매출 및 달성률 데이터가 언급됨 (일부 상품은 300만 원 수준의 저조한 매출을 보이나, 다른 상품은 800만 원 매출에 90-100% 달성률을 기록하는 등 편차가 큼). 또한, 달성률 80%를 기준으로 정산 기준이 달라짐. 80% 이상일 경우 해당 달성률을 기준으로 계산하며, 80% 미만일 경우 도매 매출 자료를 기준으로 정산함. 최근 데이터 정합성 확인 과정에서 B&A 건이 중복 등록(A와 B로 각각 등록되어 합산됨)되어 매출이 800만 원으로 잘못 집계된 사례가 확인됨. 수수료 체계와 관련하여, 병원별 또는 품목별로 추가 인센티브를 설정하는 방식이 논의되었으며, 제약사가 CSO에 지급하는 수수료 구조 내에서 병원별/품목별 기본 수수료 설정 필요성에 대한 논의가 진행됨. 또한, 품목별로 수수료율을 다르게 적용하는 방안(예: 특정 품목은 30%, 다른 품목은 27%, 21%, 42% 등)이 논의되었으며, CSO가 특정 병원에 영업할 때 해당 병원과 품목에 맞는 수수료율이 적용되는 구조임. 특히 동일한 품목이라도 병원별로 예외 수수료율이 적용될 수 있음(예: A병원에서는 특정 수수료율이 적용되나, B병원에서는 기본 수수료율이 적용되는 등 병원별 차등 적용). 추가로 인센티브 산정 및 정산 시 달성률에 따른 차등 적용과 최종 정산 기준(80% 기준 등)에 대한 논의가 지속됨. 시스템 로직 설계 시 복잡성을 고려하여, 'Yes/No' 플로우 차트 등을 활용해 단계별로 세분화하여 설계할 필요성이 언급됨. 수수료율 논의 중 30% 수수료율 사례가 언급되었으며, 이에 대한 기준으로 3%가 설정됨. 또한, 매출이 저조한 경우(예: 300만 원 수준)에는 증빙이 어려울 경우 해당 매출에 대해 수수료를 추가로 지급하는 방식이 논의됨. 정산 로직이 복잡하므로, 달성률 80% 기준 여부에 따라 수수료 산정 기준을 명확히 구분하여 정리하는 것이 중요함. 정산 과정에서 확인해야 할 데이터와 변수가 많아 시스템 설계 시 정산 로직의 복잡성을 관리하고 단계별로 세분화하는 것이 핵심임. 현재 시스템(엑셀 기반)의 한계로 인해 복잡한 계산 로직을 구현하는 데 어려움이 있음이 언급됨. 인센티브 산출 및 정산 내역서 발행 프로세스에 대한 논의가 이어짐. 정산 내역서 발행 후 세금계산서 발행 및 메일 발송 프로세스가 필요하며, 세금계산서의 경우 CSO 측에서 메딕스로 역발행하는 구조임. 송금은 우리은행 API를 활용하되 실제 송금 실행은 담당자가 직접 수행하는 방식으로 논의됨. 또한, 세금계산서 발행과 관련하여 나이스(NICE) 및 국세청 API 연동 가능성이 언급됨. 추가로, 월별 정산 내역 조회 기능을 통해 특정 월에 어떤 CSO에게 얼마가 지급되었는지 등 지급 이력을 관리할 계획임. 개발 일정과 관련하여, 프론트엔드 개발 가능 시간이 약 3주 정도로 예상됨에 따라, 기획/디자인/백엔드 선행 작업의 필요성이 강조됨. 이에 따라 업무 우선순위를 명확히 설정하여 순차적으로 진행하기로 함. 우선순위가 확정되면 이를 바탕으로 WBS(Work Breakdown Structure)를 작성할 예정임. 메딕스가 제약사에 정산금을 청구할 때, 제약사는 메딕스가 제출한 증빙 자료를 검토하여 실제 처방 내역과 대조한 뒤, 인정되지 않는 항목(수익 차이 등)을 제외하고 최종 정산 금액을 확정하는 프로세스가 확인됨. 이 과정에서 발생하는 수익 차이나 마진 정산 등 정산금 산정 시 발생하는 차액에 대한 처리 방식도 논의됨. 특히 메딕스가 CSO에게 지급하는 수수료 총액에 메딕스의 중간 마진(예: 10%)을 가산하여 제약사에 청구하는 방식이 언급됨. 또한, 제약사로부터 미수령한 정산금(예: 과거 미수금)을 추후 정산 시 합산하여 청구하는 등 정산금 트래킹의 중요성이 강조됨. 현재 엑셀로 관리하여 발생하는 누락 및 트래킹의 어려움을 해결하기 위해 시스템화가 필요함. 또한, 시스템 내 목표 관리 및 흡수율 관리 기능에 있어, 병원별 흡수율 조회 등 관점의 차이를 반영한 분석 기능이 논의됨. 또한, 시스템을 통해 특정 품목이나 유통상의 매출 변화 추이를 분석하여 이상 징후(품절, 데이터 오류 등)를 파악하는 기능이 논의됨. 또한, 거래처별 여신 한도 관리 기능이 논의됨. 신성(제약사)으로부터 매출 데이터를 API로 연동받아, 설정된 여신 한도를 초과하거나 로직에 어긋나는 이상 징후가 발생할 경우 이를 알림으로 제공하는 모니터링 화면 구축이 검토됨(단, 신성 측의 API 제공 여부에 따라 구현 범위가 달라질 수 있음). 추가로, 거래처 정보 관리와 관련하여 API를 통해 거래처 정보를 조회하고 시각화하는 기능이 논의되었으며, 로그 관리 기능은 추후 과제로 미뤄짐. 내일(회의 다음 날)은 개발 업무를 우선적으로 진행하기로 하였으며, 관련 문의 사항은 언제든 소통하기로 함.
회의 중 사적인 대화(결혼 관련 언급 및 라면/음식 취향, 식사량에 대한 잡담)가 이어짐. 동나리 차장, 강신우 주임, SPEAKER_01을 포함한 4명 간의 신뢰 확인. 또한, 시스템의 한계와 AI 도입의 어려움, 그리고 진급 관리(위주복)에 대한 언급이 있었음. 향후 업무 관련 문의나 확인이 필요한 사항은 메딕스 외부 슬랙 채널을 활용하여 통합 관리하기로 함.
주요 메뉴 구성: 로그인, 대시보드, 거래처 관리(CS 처리 포함 - 병원 내 약품 영업 가능 여부 문의 및 메딕스 확인 절차: 병원 내 해당 약품 계약 CS 존재 여부 확인, 제약사 직접 영업 병원 확인 등. 제약사가 직접 영업하는 주요 병원의 경우 메딕스에서 영업 불가 여부를 검토하여 CS에 답변 제공), 손목 관리, 무통 관리(웹포드 매칭), EDI 관리(OCR을 통한 데이터 업로드 기능 포함 - 도매 매출 자료가 포함된 엑셀 업로드 시 메일 제목과 발신자를 통해 도매 업체를 식별하며, 수기 업로드가 필요한 경우를 대비한 보조 기능 및 업로드 시 1차 검증 프로세스 포함. EDI 접수/도매 매출 입력/수요 분석/지급액 산정/매출 분석 프로세스, 정상물 기준 조회 기능 포함 - 정산월 기준 조회 시 정산월을 필터로 설정하여 해당 월을 확인하며, 처방월 기준 조회 시 EDI 처방전 기준, 정산월 기준 조회 시 업로드하는 정산월 기준으로 구분. 조회 시 정산월 또는 처방월을 필터로 선택하여 기준을 설정함), 매출 관리(금액 매출 등록), 흡수율 관리, 지급 관리(정산 내역 조회 포함), 인센티브 관리(기본 수수료 외에 영업 성과에 따라 추가로 지급되는 인센티브 설정 및 관리 기능 포함. 병원별 또는 품목별로 추가 인센티브를 설정하는 방식 논의), 제약사 청구관리, 실피관리(기능 변경), 목표관리(목표 설정 및 달성률 확인 - 내부 임직원 대상의 목표(CSO 계약 수, 매출 목표 등)를 월별/연간/중기별로 설정하는 메뉴로 구성하며, 설정된 목표는 대시보드에 연동하여 시각화할 예정), 협력 서포터블 관리(공지사항 게시, 카탈로그 기능 - 취급 약품 목록 확인 및 제품 PDF 카탈로그 업로드/관리 기능 포함. 또한, CP(Compliance Program) 관련 월간 모니터링 및 분기별 교육 자료 등을 게시하는 기능 포함. 향후 설문조사 기능 도입 전까지는 게시판 형태로 운영 예정), 임직원 관리(신세 설정 포함), 시스템 설정(권한 관리, 부서 관리 포함), CP관리, 해당성, 포털관리, 레포트(CSO 대시보드, 변형, 품목 관리, 기관별 EDI 내역 조회 포함 - 기획 완료되어 지난주 넘어옴. 단, 변형과 품목 관리는 아직 미전달 상태로 현재 엑셀로 정리 중. 기존 레포트에 포함하려던 내용들이 각각의 메뉴로 분리됨. CSO 대시보드는 기존 기획/디자인을 유지하며 탭 구조로 현황과 CS 처리 기능이 추가될 예정. CS 처리는 테이블 형태로 구현 검토 중이나, 기본 정보나 현황 페이지에 카드 섹션으로 추가하는 방안도 논의됨. 품목 관리의 경우 예외 수술(예외 처리)을 적용하는 품목에 대한 기능이 필요함. 특히 특정 상황에서 예외 수수료를 적용하는 품목들을 모아서 조회할 수 있는 화면이 필요하며, 해당 화면에서는 병원, CSO, 품목별로 예외 수수료 적용 내역을 확인할 수 있어야 함. 이 예외 수수료 및 예외 포인트 관련 건은 품목 관리 메뉴 내에 포함하는 것이 아니라, 별도로 추출하여 조회할 수 있는 화면 구성을 논의 중임. 디자인상의 품목-병원 정보와는 별개로 관리될 예정. 기관별 EDI 내역 조회는 실무자가 5월, 6월 등 특정 월에 올라온 EDI 내역을 기간별로 조회하여 확인하는 용도로 사용됨. 해당 조회 기능은 김고인 주임, 박초희 주임 등 실제 입력 실무자들이 특정 월의 데이터를 모아 확인하거나, 관리자들이 지난 1월부터의 데이터를 병원별로 조회하는 등 기간별/병원별 데이터 확인 용도로 활용됨. 또한, 기관별 조회는 추이를 파악하기 위한 목적이 크며, 월별 조회를 통해 데이터 오류를 빠르게 잡아내는 용도로도 활용될 예정임. 특히 기관별 EDI 내역 조회 시, 기존의 '병원별 약품 처방 내역' 확인 방식에서 역으로 '특정 병원에 연계된 약품 목록'을 확인할 수 있는 기능에 대한 니즈가 확인됨. 추가로, 약국을 기준으로 연계된 병원들의 제품별 처방 내역을 역으로 조회하는 기능도 논의됨(약국에서 제품별 처방 내역을 확인하고자 하는 니즈 반영 - 소비자가 여러 약국에서 처방받을 수 있는 상황을 고려하여, 약국을 기준으로 처방 내역을 역추적하는 기능. 약국은 여러 병원과 연결될 수 있으므로, 약국 기준으로 연결된 병원들이 어떤 약을 몇 개 처방하여 어디에 맞는지 확인하고자 함). PC보드. (설 연휴 중순까지 목표 설정 및 시스템 구축 예정). 업무 프로세스는 EDI 접수, 도매 매출 입력, 수요 분석, 지급액 산정, 매출 분석 순으로 진행됨. 현재 ERP 핵심 업무에 대한 상세 설명이 진행 중이며, 대시보드와 거래처 관리부터 논의 시작. 거래처 관리와 관련하여, 매출이 저조한 경우 2개월 정도 지켜본 후 계약 해지 여부를 결정하거나 CSO(영업대행사)를 통해 민원이 들어올 경우 해당 거래처로 배정하는 프로세스 논의됨. 또한, 문의 채널과 관련하여 기존 혁명성 포털 외에도 전화, 메일, 카톡 등 외부 채널을 통한 문의 비중이 높아 이를 통합 관리하는 방안이 논의됨. 특히 CS 문의 시 문의 시점, 답변 시점, 답변 결과 등 히스토리를 관리하고, 문의 처리 상태를 신호등(주황, 노랑 등) 형태로 시각화하여 관리하는 기능이 중요하게 논의됨. 신호등 기능은 초록불(가능), 노란불(계약은 되어 있으나 매출 저조), 빨간불(불가능) 등으로 구분하여 보여줄 것을 요청함. 유기스트 관련 내용도 언급됨. 거래처 관리 내 CS 처리 기능의 위치에 대해서는 추가 논의가 필요함. EDI 관리 시 CSO가 계약이 불가능한 규모의 병원을 올리는 경우에 대한 예외 처리 프로세스도 논의됨. 특히 CSO가 계약 불가능한 병원/약품 정보를 올렸을 경우, 메딕스 측에서 해당 CSO에게 직접 연락하여 계약 여부를 확인하고 잘못 등록된 건인지 확인하는 절차를 포함함. 만약 CSO가 잘못 등록했다고 하면 해당 건을 삭제하고, 계약이 되어 있는데 통보가 안 된 경우라면 메딕스를 통해 CSO 관리 계약서 및 부속 계약서를 체결하는 절차를 진행함. 또한, 계약 미체결 건을 CS별로 구분하지 않고 전체 EDI 데이터에서 모아서 관리할 수 있는 별도 메뉴 구성이 논의됨. 특히 이 메뉴는 제약사와 CSO 간의 신규 계약서 및 부속 계약서를 일괄 발송하기 위한 목적으로 구축될 예정임. 시스템 복잡도와 관련하여, 사용자 교육의 중요성이 강조됨. 특히 실무 담당자 채용 시(예: EDI 담당자) 시스템 교육이 필수적이며, 신규 입사자에게는 코어 넥(Core-NEC) 시스템을 익히는 교육을 우선적으로 진행하여 업무 연속성을 확보해야 함. 시스템이 복잡할 수밖에 없는 한계가 있으나, 최대한 시스템을 쉽게 구축하여 신규 입사자의 빠른 업무 적응을 돕는 것이 최선의 대안으로 논의됨. 추가로, 특정 병원에 대해 예외적으로 품목을 공용으로 사용할 수 있게 열어주는 '예외 품목 병용' 기능에 대한 논의가 진행됨. 예외 수수료 적용 품목은 병원별로 개별 확인하는 방식이 아닌, 전체 내역을 한 번에 조회할 수 있는 화면 구성이 논의됨. 또한, 병원별 EDI 내역 조회 시 특정 병원에 연계된 약품 목록을 확인하는 방식에 대해, 소비자가 해당 약품을 어떻게 활용하는지에 대한 관점도 논의됨. 소비자가 여러 약국에서 처방받을 수 있는 상황을 고려하여, 약국을 기준으로 처방 내역을 역추적하는 기능이 논의됨. 이러한 메뉴 구성의 증가는 현장 실무자들의 다양한 분석 니즈를 반영한 결과임. 수동으로 엑셀 작업을 하는 대신 시스템을 통한 자동화가 필요함. 미연계 약국(병원과 연계되지 않은 약국)의 경우, 월별 매출액은 도매 매출 자료를 통해 확인하는 방식으로 논의됨. 병원 관리와 관련하여, 병원들을 그룹화하여 관리하는 방안이 논의됨. 시스템 메뉴가 지속적으로 늘어나는 이유는 새로운 기능을 추가하기보다, 기존 데이터를 활용하여 실무자의 분석 니즈에 맞게 조회 방식을 다양화하고 자동화하려는 목적이 큼. 지급액 산정의 기준은 CSO가 보고하는 EDI 자료를 기반으로 함. 또한, CS 처리 기능을 협력사 포털로 이동 및 관리하는 방안이 논의됨. 또한, 신성(제약사)으로부터 매출 데이터를 API로 연동받아, 설정된 여신 한도를 초과하거나 로직에 어긋나는 이상 징후를 실시간으로 파악하고 알림을 제공하는 모니터링 화면 구축이 검토됨(단, 신성 측의 API 제공 여부에 따라 구현 범위가 달라질 수 있음). 추가로, 시스템 내 데이터 조회 시 기획 관리, 디자인, 현악 확인 필요 여부 등을 구분할 수 있는 필터 기능 도입이 논의됨.