Spreadsheet Best Practices: Stop Making These Mistakes — csv-x.com

나는 여전히 누군가가 스프레드시트 셀에 마침표 대신 쉼표를 입력하면서 $2.3백만이 사라지던 날을 기억한다. 나는 중형 투자 회사에서 재무 분석가로 일한 지 3년이 되었고, 우리 팀은 방탄 같은 인수 제안을 제출한 상태였다. 현금 흐름 예측의 소수점 오류는 단순히 거래를 잃게 만든 것이 아니라 고객과의 신뢰를 잃게 했고, 세 사람의 일자리도 위협받게 했다.

그것은 2009년이었다. 그 이후로 나는 포춘 500대 기업에서 끈질긴 스타트업에 이르기까지 모든 이들과 협력하며 데이터 운영 컨설턴트로 15년을 보냈으며, 내가 상상할 수 있는 거의 모든 스프레드시트 재난을 목격해왔다. 나는 80만 달러의 초과 재고로 이어진 재고 오류, IRS 감사가 촉발된 급여 오류, 그리고 수치가 완전히 잘못된 마케팅 예산을 경험했다. 공통된 주제는? 스프레드시트를 비즈니스에 필수적인 도구로서가 아닌 간단한 메모장처럼 다루면서 발생하는 예방 가능한 실수들이다.

대부분의 사람들이 깨닫지 못하는 것은 하와이 대학교의 레이몬드 판코의 연구에 따르면 모든 스프레드시트의 88%에 오류가 있다는 것이다. 라벨의 오타나 사소한 형식 오류가 아닌, 비즈니스 결정을 영향을 미치는 실제 계산 오류다. 유럽 경제 연구자들이 실제 회사의 운영 스프레드시트를 조사했을 때, 셀 수식당 오류율이 0.8%에서 1.8% 사이에 이르는 것을 발견했다. 이는 평균 500-1,000개의 수식을 포함하는 일반적인 재무 모델을 고려하면 작게 들릴 수 있다. 계산해보라: 평균적으로 스프레드시트당 4-18개의 오류가 발생하는 것이다.

나는 스프레드시트 사용을 두려워하게 하려는 것이 아니다. 스프레드시트는 강력하고, 유연하며, 올바르게 사용하면 꼭 필요하다. 하지만 200개 이상의 조직과 상담하며 수천 개의 스프레드시트를 직접 감사한 결과, 아마추어 스프레드시트 사용자와 신뢰할 수 있고 확장 가능한 데이터 시스템을 구축하는 전문가를 구별하는 패턴을 식별했다. 내가 배운 것을 공유하겠다.

기초 문제: 스프레드시트를 데이터베이스가 아닌 문서처럼 다루기

내가 보는 가장 큰 실수—이는 내가 마주치는 심각한 오류의 약 40%를 차지한다고 말할 수 있다—는 사람들이 스프레드시트를 워드 프로세싱 문서처럼 다룬다는 것이다. 그들은 미적 이유로 셀을 병합하고, 시각적 간격을 위해 빈 행을 삽입하며, 색상을 의미를 전달하는 주요 방법으로 사용하고, 관련 데이터를 일관된 구조 없이 여러 탭에 흩어놓는다.

진짜 사례를 들어보겠다. 작년에 나는 "마스터 스프레드시트"라고 부르는 생산 데이터를 추적하는 제조 회사와 작업했다. 이 스프레드시트는 7년간 같은 운영 관리자에 의해 유지되어 왔고, 그녀가 은퇴하자 혼란이 시작되었다. 스프레드시트는 각기 다른 제품 라인을 나타내는 23개의 탭이 있었다. 조직적으로 들린다, 그렇지 않은가? 틀렸다. 각 탭은 완전히 다른 구조를 가지고 있었다. 어떤 것은 A 열에 날짜를 나열하였고, 다른 것은 C 열에 나열했다. 어떤 것은 "제품 ID"를 헤더로 사용하였고, 다른 것은 "SKU" 또는 "아이템 코드" 또는 단순히 "ID"를 사용했다. 시각적으로 보기 좋게 보이게 하기 위해 병합된 셀들이 많아 정렬하거나 필터링을 제대로 할 수 없었다.

그들이 이 시스템을 사용할 수 있는 것으로 통합을 돕도록 나에게 요청했을 때, "2022년 3분기의 총 생산량은 얼마였나?"와 같은 간단한 질문을 확인하기 위해서는 서로 다른 날짜 형식과 열 구조를 가진 23개의 서로 다른 탭을 수작업으로 확인해야 했다. 30초면 끝날 질문이 수작업으로 45분이 걸리게 되었다. 그리고 그 구조가 일관되지 않았기 때문에 자동화할 방법이 없었다.

해결책은 기본 원칙으로 돌아가는 것이었다. 나는 그들이 단일 일자형 데이터 테이블로 추적 시스템을 재구축하도록 했다. 각 행은 하나의 생산 이벤트를 나타냈고, 각 열은 하나의 속성을 나타냈다: 날짜, 제품_ID, 수량, 라인_번호, 교대, 품질_등급. 병합 셀은 없었다. 간격을 위한 빈 행도 없었다. 주 데이터 지표로서 색 코딩도 없었다. 필터링, 정렬, 피벗 및 분석이 가능하도록 깔끔하고 구조화된 데이터만 있었다.

결과는? 그들의 월간 보고 시간은 12시간에서 45분으로 줄어들었다. 그들은 이제까지 대답할 수 없었던 질문들에 대답할 수 있게 되었다. 그리고 그들이 두 년 후에 적절한 데이터베이스 시스템으로 전환했을 때, 그들의 데이터가 이미 적절하게 구조화되어 있었기 때문에 전환은 매끄럽게 이루어졌다.

원칙은 이렇다: 분석하고, 질의하고, 보고해야 할 데이터를 저장하기 위해 스프레드시트를 사용하고 있다면, 문서가 아니라 데이터베이스 테이블처럼 다뤄라. 기록당 하나의 행. 속성당 하나의 열. 일관된 헤더. 데이터 범위에 병합된 셀이 없다. 프레젠테이션 레이어의 예쁜 형식은 따로 저장하라—청결한 데이터 테이블에서 가져오는 별도의 요약 시트나 보고서를 작성하라.

수동 데이터 입력 및 복사-붙여넣기 작업의 숨겨진 위험

나는 한 번 건강 관리 조직의 환자 예약 시스템을 감사하면서 그들의 직원이 예약 소프트웨어에서 Excel로 약속 데이터를 수동으로 복사한 후 다시 그 데이터를 청구 시스템으로 복사하고 있다는 것을 발견했다. 이 과정은 하루에 40-60회, 주 5일 간 반복되었다. 내가 오류율을 계산했을 때—200개의 무작위 항목을 원본 기록과 점검하여—3.2%의 오류율이 발견되었다. 이는 하루에 대략 6-10개의 오류, 연간 1,500-2,500개의 오류에 해당한다.

"가장 비싼 스프레드시트 오류는 충돌하는 오류가 아닌, 잘 작동하지만 내부에 잘못된 숫자가 있는 오류다."

각 오류는 하위 결과를 초래했다. 잘못된 약속 시간으로 인해 의사가 없을 때 환자가 나타났다. 잘못된 청구 코드로 인해 보험 거부와 지불 지연이 발생했다. 잘못된 환자 ID는 HIPAA 위반 및 잠재적인 법적 책임을 야기했다. 해당 조직은 수동 데이터 전송에서 발생한 오류를 수정하는 데 주당 약 15시간을 소모하고 있었다.

수동 데이터 입력의 근본 문제는 단순히 인간이 실수를 저지른다는 것만이 아니다—우리는 예측 가능한 비율로 확실히 실수를 한다. 더 깊은 문제는 수동 프로세스가 확장되지 않고, 효과적으로 감사할 수 없으며, 단일 실패 지점을 만든다는 것이다. 하나의 사람이 스프레드시트를 업데이트하기 위한 "프로세스"를 알고 있을 때, 그들이 아프거나, 휴가 중이거나, 회사를 떠난 경우에는 어떻게 될까?

나는 이 패턴을 수백 번 보아왔다: 누군가가 자신만 사용할 수 있는 스프레드시트 시스템을 구축했다. 그들은 모든 복잡함을 알고 있고, 모든 특수 사례를 기억하며, 제한 사항을 피할 수 있다. 그러다가 회사가 성장하고, 더 많은 사람들이 접근해야 하게 되면, 한 명의 전문가를 위한 시스템은 갑자기 부채가 된다. 데이터가 일관되지 않게 입력된다. 사람들은 서로의 작업을 덮어쓴다. 누구도 현재 버전이 무엇인지 알지 못한다.

해결책은 수동 입력을 완전히 없애는 것이 아닌 경우가 많다—때로는 비현실적이다. 하지만 이러한 관행을 따르면 오류를 획기적으로 줄일 수 있다. 먼저, 데이터 검증을 철저하게 실시하라. 만약 열이 날짜만 포함해야 한다면, 다른 것을 거부하도록 검증을 설정하라. 제품 코드가 특정 형식을 따라야 한다면 이를 강제하는 검증 규칙을 만들어야 한다. 나는 일반적으로 데이터 입력 스프레드시트의 열의 60-80%에 대해 검증 규칙을 설정한다.

둘째, 유효한 값의 제한된 세트를 갖는 모든 필드에 대해 드롭다운 목록을 만들어라. 사람들이 "뉴욕", "NY", "뉴욕", "N.Y."와 같은 다양한 입력을 주주 필드에 입력하지 못하게 하고, 정확히 하나의 선택만 제공하도록 드롭다운을 제공하라. 이는 내가 경험한바에 의하면 입력 오류를 40-50% 줄일 수 있다.

셋째, 가능한 한 데이터를 재입력하는 것보다 가져오는 방법을 사용하라. 대부분의 현대 소프트웨어는 CSV 형식으로 내보낼 수 있다. 데이터 유형과 형식을 유지하며 스프레드시트에 CSV 파일을 올바르게 가져오는 방법을 배워라. 이는 처음 설정할 때 10분이 걸리지만, 수 시간을 절약하고 전체 카테고리의 오류를 제거할 수 있다.

수식 오류: 스프레드시트 신뢰성의 조용한 살인자

내가 컨설팅 경력에서 최소 30회 경험한 시나리오는: 누군가가 200개의 수식을 가진 재무 모델을 구축한다. 그들은 그것을 주의 깊게 테스트하고 결과를 확인하며 모든 것이 완벽해 보인다. 6개월이 지나면 누군가가 데이터 범위 중간에 새로운 행을 삽입한다. 절반의 수식은 새 행을 포함하도록 올바르게 업데이트된다. 절반은 그렇지 않다. 아무도 주목하지 않는다. 왜냐하면 총계는 여전히 합리적으로 보이기 때문이다. 이제 모델은 올바르지 않은 결과를 산출하고 있으며, 누군가가 문제를 발견하는 데는 몇 개월 또는 몇 년이 걸릴 수 있다.