자동화: 직접 만들기, 소프트웨어 구매 또는 컨설턴트? Make-vs-Buy 결정

대부분의 중견기업 자동화 프로젝트는 기술 때문에 실패하지 않습니다. 너무 일찍, 잘못된 숫자를 근거로 내려진 결정 때문에 실패합니다: 직접 구축할 것인가, 기성 소프트웨어를 구매할 것인가, 아니면 컨설턴트를 고용할 것인가?

세 가지 방법은 각각의 순간에 유효합니다. 그러나 "Make or Buy" 질문은 두 가지가 확정되어야만 신뢰성 있게 답할 수 있습니다: 어느 프로세스를 건드릴지 알고 있어야 하고, 그 프로세스가 당신에게 연간 얼마인지 유로로 알고 있어야 합니다. 바로 이것이 Flowrefy 방법의 O-단계 임무입니다. 이 글은 그 뒤에 있는 의사결정 논리를 제공합니다. 도구 간 비교가 아니라, 실제로 구축, 구매, 위임이 갈라지는 경계값을 제시합니다.

순서를 먼저, 그런 다음 결정

Flowrefy 방법은 프로세스당 네 단계의 순환입니다: FLOW의 Find(가장 비용이 큰 병목을 찾기), Lay bare(유로로 수치화하기), Optimize(정리하고 정확히 하나의 지렛대 선택하기), Wire & Watch(구현하고 다시 측정하기).

Make-vs-Buy는 순수한 O-단계 질문입니다. 그리고 O-단계에는 철칙이 있습니다: 먼저 정리하고, 그다음 소프트웨어를 구매하십시오. 이 순서를 바꾸면 혼란을 자동화하게 됩니다. 더 빠르고 더 비싸게요.

당연해 보이지만 그렇지 않습니다. 중견기업의 전형적 흐름은 이렇습니다: 누군가 박람회에서 도구를 보고, 영업이 훌륭하고, 예산이 마련됩니다. 6주 후에는 이전에 명확히 정의된 적 없는 프로세스를 구현하는 소프트웨어가 가동됩니다. 결과는 광택 있는 인터페이스를 가진 비싼 정체입니다.

따라서 무엇을 구매하거나 구축하기 전에 두 가지 전제가 충족되어야 합니다:

1. 병목이 확정되어야 합니다. 정확히 하나의 프로세스, 다섯 개가 아닙니다. 이것이 "주기당 한 병목" 원칙입니다.
2. 병목은 유로로 수치화되어야 합니다. 현재 상태의 연간 비용을 알아야 투자를 정당화할 수 있습니다. 이것이 원칙입니다: 유로로 말할 수 없다면 만지지 마십시오.

두 항목이 충족되지 않으면 Make-vs-Buy 논의는 성급합니다. 그 경우 F-와 L-단계로 돌아가야 합니다. 병목을 수치화하는 방법은 FLOW-Prozesskosten-Analyzer에서 확인하십시오.

세 가지 방법을 솔직하게 나란히 두기

계산을 시작하기 전에, 옵션이 실제로 의미하는 바를 냉정하게 정의합니다. 판매 방식과는 다릅니다.

직접 구축 (Make)

No-Code/Low-Code 플랫폼, 자체 스크립트, 내부 개발자를 사용해 자동화를 구축합니다. 로직을 완전히 소유하며 언제든지 수정할 수 있습니다. 대가로 유지보수, 업데이트, 지식을 부담하며 인적 리스크를 떠안습니다. 구축한 사람이 떠나면 이해도 종종 함께 사라집니다.

기성 소프트웨어 구매 (Buy)

프로세스를 대체로 반영하는 표준 솔루션을 임대합니다. 설정이 빠르고 공급자가 유지·개발·지원합니다. 대가로 조직이 소프트웨어에 맞춰야 합니다. 특수 사례에서는 한계에 부딪히며, 라이선스 비용은 사용자나 거래량과 함께 불쑥 증가할 수 있습니다.

컨설턴트 고용

컨설턴트는 네 번째 길이 아니라, 다른 두 길의 가속기이며 대개 일회성입니다. 내부에 병목을 정확히 수치화할 지식이 부족하거나, 마이그레이션이 일회성으로 복잡할 때 유용합니다. 위험한 상황은 최종적으로 내부에서 유지할 수 없는 블랙박스가 남는 경우입니다. 그러면 단순히 볼륨 문제를 의존성 문제로 바꾼 셈입니다.

진짜 결정을 좌우하는 세 가지 크기

직감과 공급자 매력은 잊으십시오. Make-vs-Buy 결정은 세 가지 측정 가능한 요소에 달려 있습니다.

1. 표준화 수준

프로세스가 얼마나 개별적인가요?

• 높이 표준화됨(급여 계산, 뉴스레터 발송, 티켓팅, 정형화된 송장 승인): 수천 개 회사가 똑같은 문제를 겪습니다. 여기에는 저렴한 성숙한 소프트웨어가 있습니다. 구매하세요. 직접 구축은 바퀴를 다시 발명하는 것입니다.
• 부분적으로 특수함(핵심은 표준이지만 세 가지 특이한 규칙이 있는 경우): 표준 툴을 기본으로 하고 작은 연결 브리지를 내부에서 구축하는 혼합형이 적절합니다.
• 매우 개별적이거나 경쟁우위 요소(프로세스 자체가 시장에서의 차별화 포인트인 경우): 표준 소프트웨어는 낯선 논리를 강요합니다. 이 경우 자체 구축이 분명히 우수할 수 있습니다.

경험칙: 표준인 것은 구매하고, 당신을 독특하게 만드는 것은 구축하거나 구축해서 인수합니다.

2. 볼륨

프로세스는 얼마나 자주 실행되나요?

볼륨은 고정비가 정당화되는지를 결정합니다. 자체 개발은 초기비용이 높고 한계비용이 낮습니다. 구매한 라이선스는 초기비용이 낮지만 사용자나 거래에 따라 계속 비용이 늘어납니다.

• 낮고 드문 볼륨: 자체 구축은 거의 이득이 없습니다. 초기 투자가 회수되지 않습니다. 구매하거나 아예 두지 마십시오.
• 높고 일정한 볼륨: 자체 구축이 경제적입니다. 고정비가 많은 실행에 분산되고, 지속적인 라이선스 비용은 수년간 부담으로 작용합니다.

3. 3년 총소유비용(TCO)

대부분의 사람들이 실패하는 지점입니다: 라이선스끼리만 비교하고 진짜 비용을 간과합니다. Total Cost of Ownership는 3년 동안 발생하는 모든 비용입니다.

구매 시 계산 항목:

• 라이선스 및 설정 비용
• 예상 볼륨 증가를 반영한 36개월 분의 지속 비용
• 데이터 마이그레이션 및 설정
• 직원 교육
• 내부 운영·유지 관리 노력

구축 시 계산 항목:

• 일회성 개발 시간(시간 × 내부 시간당 비용, 솔직하게 추정)
• 연간 유지보수(경험칙: 구축비용의 연 15~25%)
• 호스팅 및 인프라
• 인적 리스크(구축자가 떠나면 드는 비용)

이 두 합계만 비교 가능합니다. 유지보수와 교육을 포함하면 결정은 흔히 뒤집힙니다. 양쪽 방향으로요.

때로는 둘 다 아닌 결론이 나옵니다. 예시 분석 AN-2026-03(구성된 예시, 고객에서 수집된 것이 아님)에서는 워크플로우 자동화에 대해 18.000유로 제안이 있었습니다. 서명 전에 프로세스를 계산해보면:

[
  { "label": "Einführungskosten (Buy)", "value": "18.000", "unit": "€", "tone": "critical" },
  { "label": "Ersparnis an Arbeitszeit", "value": "4.000", "unit": "€/Jahr" },
  { "label": "Amortisation", "value": "> 4", "unit": "Jahre", "tone": "critical" },
  { "label": "Durchlaufzeit", "value": "-7", "unit": "%", "note": "12,8 → 11,9 Tage" }
]

세 번째 결론은 때때로 둘 다 해당하지 않습니다. 이 사례에서는 병목이 공급업체 쪽에 있어 내부에서 해결할 수 없었습니다. 구매한 도구도 구축한 도구도 소용이 없었습니다.

네 가지 질문으로 정리된 의사결정 논리

병목과 유로 값이 정해졌다면, 다음 네 질문을 순서대로 처리하십시오.

질문 1: 이것이 표준 프로세스인가요? 예이고 매우 표준화됨 → 강한 구매 성향. 질문 3으로 이동. 아니오, 매우 개별적임 → 질문 2로 이동.

질문 2: 내부에 구축하고 3년간 유지할 능력이 있나요? 예 → 구축은 현실적 옵션입니다. 질문 3으로 이동. 아니오 → 표준툴을 프로세스에 맞추거나, 일회성 구축과 내부 지식 이전을 위해 컨설턴트를 고용하세요. 인수인계 없는 블랙박스는 절대 허용하지 마십시오.

질문 3: 3년 TCO는 직접 비교했을 때 어떻게 되나요? 두 합을 계산하세요. 차이가 20% 이내라면 거의 항상 구매가 유리합니다. 위험이 작고 시작이 빠르기 때문입니다.

질문 4: 책임자가 떠나면 무슨 일이 발생하나요? 해결책이 한 사람에게 의존하면 구축안에는 리스크 할증을 반영하세요. 또는 컨설턴트에게 계약상 문서화 및 인수인계를 요구하십시오.

설명용 계산 예시

논리를 체감할 수 있도록 하나의 예시 시나리오를 계산합니다. 예시는 가상의 설명을 위한 것이며 실제 고객 사례를 나타내지 않습니다.

직원 60명의 기계 제작 업체가 F-단계에서 제안서 작성 프로세스를 가장 비싼 병목으로 식별했습니다. L-단계에서 비용을 산출하니 세 명이 주로 수작업으로 제안서를 작성하고 연간 인건비로 대략 40.000유로가 묶여 있었습니다.

O-단계에서는 먼저 정리했습니다: 템플릿을 통일하고 가격 논리를 문서화했습니다. 그다음에 Make-vs-Buy 질문이 나왔습니다:

• 구매(CPQ 표준 소프트웨어): 연간 약 9.000유로 라이선스, 여기에 설정과 교육비. 3년 TCO 약 35.000유로. 문제는 특수 가격 논리가 70%만 맞는다는 점입니다.
• 구축(내부 No-Code 구성기): 일회성 약 18.000유로, 연간 유지보수 약 4.000유로. 3년 TCO 약 30.000유로. 장점: 가격 논리가 100% 맞음. 위험: 지식이 한 사람에게 의존함.

합계가 가까워서 결정은 가격 논리의 높은 개별화 수준이었습니다. 표준 툴로는 부족하므로 구축하기로 결정했지만, 인적 리스크를 줄이기 위해 문서화된 인수인계를 포함하기로 했습니다. 귀사의 구체적인 우위는 전적으로 수치에 달려 있습니다. 그래서 계산기가 있습니다.

정확히 하나의 지렛대를 바꾸고 다시 측정하십시오

어떤 결정을 하든, 사이클당 정확히 하나의 지렛대만 바꾸세요. 동시에 도구를 사고, 다른 프로세스를 개편하고, 스크립트를 여러 개 작성하지 마십시오. 세 가지를 동시에 바꾸고 개선을 보면 어떤 조치가 효과였는지 알 수 없습니다. 어떤 것은 개선이고 어떤 것은 돈 낭비였을 뿐일 수 있습니다.

W-단계(Wire & Watch)에서는 L-단계에서 산출한 동일한 유로 값을 다시 측정하십시오. 이것이 주장 대신 실제 전/후 비교를 제공합니다. 바로 이것이 Flowrefy 방법을 흔한 "우리가 뭔가 자동화했어요"식 설명과 구별합니다.

Make-vs-Buy 방향이 정해지면 No-Code 플랫폼 선택에 대해 더 깊이 보고 싶다면 Beste No-Code-Tools 개요가 도움이 됩니다. 또한 구매나 구축 전에 그 단계가 자동화 가능한지 점검하고 싶다면 Prozesse automatisieren: Beispiele 글에서 실질적 출발점을 찾을 수 있습니다.

각 결정 전의 간단 체크리스트

• 병목이 확정되었는가: 정확히 하나, 다섯 개가 아님
• 현재 비용이 연간 유로로 수치화되었는가
• 프로세스가 먼저 정리되었는가, 혼란을 자동화한 것은 아닌가
• 표준화 수준을 정직하게 평가했는가
• 볼륨(프로세스 실행 빈도)을 알고 있는가
• 유지보수 및 교육을 포함한 3년 TCO를 양쪽에 대해 계산했는가
• 인적 리스크를 평가하고 필요시 할증이나 인수인계로 보완했는가
• 컨설턴트 사용 시 문서화와 인수인계를 계약에 명시했는가

모든 항목에 체크가 되어야만 결정이 직감 이상의 신뢰를 갖습니다.

다음 단계: 무료 FLOW 진단

Make-vs-Buy 질문은 그것이 기반한 숫자만큼만 신뢰할 수 있습니다. 이미 병목을 알고 있다면 결정은 계산 문제로 바뀝니다: 표준화 수준, 볼륨, 3년 TCO를 서로 비교하면 됩니다. 현재 프로세스 비용은 Prozesskosten-Rechner에서 계산할 수 있습니다. 이 수치가 두 길을 비교하는 기준값입니다.

아직 어떤 프로세스가 가장 비싼지, 또는 그 비용이 얼마인지 모른다면 한 단계 앞서 시작하십시오. 무료 FLOW 진단은 가장 비용이 큰 병목을 찾고 이를 유로로 번역하도록 도와드립니다. 먼저 측정하고, 그다음 정교화하십시오.