안녕하세요 구독자 님
주간 SaaS 는 B2B SaaS 비즈니스 모델과 기술 아키텍처 설계를 일 로 하는 사람들이 한 주가 배움의 과정에서 만난 좋은 SaaS 기술 및 SaaS 비즈니스 관련 콘텐츠를 모아 짧은 요약과 함께 제공하는 뉴스레터 입니다.
주간 SaaS 뉴스레터는 SaaS 기술 과 SaaS 비즈니스 팀 모두가 SaaS 마인드셋을 갖추는데 도움이 되는 콘텐츠들로 채워집니다.
구독자 님 주변에 SaaS 와 관련된 좋은 콘텐츠를 찾고 있는 SaaS 기술 팀, SaaS 비즈니스 팀이 있다면 주간 SaaS 메일을 포워딩 해주세요 🙏🏼
호기심을 바탕으로 늘 배움을 멈추지 않는 마음으로 주간 SaaS 시작 합니다.
엔터프라이즈 B2B 애플리케이션을 만들 때 고려해야 하는 것들
“비즈니스 엔터프라이즈 애플리케이션을 만들때 고려해야 하는 주요 사항들은 무엇이 있을까?"
라는 질문이 Hacker News 에 올라온 적이 있습니다. 120개 가 넘는 댓글이 달렸는데 내용들이 하나 같이 주옥 같습니다.
댓글들을 살펴보면서 다시 한번 느끼지만 비즈니스 관점과 기술적인 관점 모두가 필요한 것 같습니다.
먼저 댓글 가운데 제 개인적으로 인상 적인 것들을 아래 추려 봤습니다. 제 개인적인 Pick 이니까 직접 한번 쭉 살펴 보시기를 추천합니다.
댓글 중에도 비슷한 언급이 있지만 책 어디에서도 찾을 수 없는 현실적이고 좋은 Tip 들이 같습니다. 저희도 매일 일을 하며 경험하고 관찰하는 내용들 같습니다. B2B 소프트웨어를 만들고 계시는 분들 이라면 꼭 댓글 하나하나 읽어보시면 좋겠습니다.
▼
댓글 1
약 15개월 동안 SaaS 소프트웨어의 기술 및 제품 책임자 경험을 바탕으로 답변 합니다.
- Buyer가 누군지 명확하게 정의할 필요가 있음. 일반적으로 User와 Buyer는 다릅니다.
- SSO, 가급적 SAML 제공
- 보안에 관해서는 OWASP top 10 를 준수하고 앱 보안에 대한 보장을 받아야 합니다.
- RBAC를 구현하세요. 관리자 사용자를 쉽게 추가/관리할 수 있도록 하세요.
- 샌드박스에서 데모 계정을 설정하고 가능한 한 실제와 가까운 데이터로 채우세요. 세일즈 프레젠테이션이 매우 쉬워집니다. 사용자 대신 제품이 말하게 하세요.
- 처음부터 멀티테넌시를 고려하세요. 나중에 추가하기가 어렵습니다.
- 도메인별 규정 준수 요구 사항을 찾아보고 처음부터 이를 구축하세요. SOC 2와 같은 요구 사항도 나쁘지 않습니다. 이 과정에서 적절한 보안 공급업체를 통해 제품을 테스트하고, 우선 순위가 높은/중간 순위의 문제를 해결하고 인증서를 발급받도록 협력하세요. 이는 고객과의 신뢰를 구축합니다.
- 보고서 기능 제공. 일반적으로 관리자는 많은 보고서를 요구합니다. CSV/Excel 다운로드를 제공하고 스프레드시트 소프트웨어에서 직접 작성하도록 하는 것이 가장 좋습니다.
- 사용자는 실수를 할 수 있으므로 항상 소프트 삭제를 사용하세요. 몇 달 후에 언제든지 하드 삭제를 할 수 있습니다.
댓글 2
저는 엔터프라이즈 SaaS 회사를 공동 설립한 경험이 있습니다.
- 관리자가 사용자를 쉽게 추가할 수 있도록 하는 것에 동의하지 않습니다. 그보다는 IDP 플로우를 사용하여 사용자 생성을 할 수 있도록 하세요.
- 가장 큰 문제는 판매입니다. 이 소프트웨어는 구매가 아닌 판매입니다. 세 가지 구성 요소(별로 중요하지 않은 사용자, 챔피언, 경제적 구매자)가 있는 모든 영업 프로세스에는 유능한 영업 담당자가 필요합니다. 솔직히 말해서, 대다수의 B2B/미드마켓 또는 엔터프라이즈 기술 기업은 뛰어난 영업 사원이 창업자로 있지 않으면 죽습니다. 그 이유는 소프트웨어가 기본적으로 작동하지 않는 동안 처음 10개의 거래를 판매해야 하기 때문입니다.
- 현실적으로 기술력은 매출보다 덜 중요합니다. 이전에 구축된 적이 없는 것을 구축할 가능성이 거의 없기 때문에 기술 리스크는 판매 및 실행 리스크보다 훨씬 낮습니다. 즉, 기본적으로 새로운 관련성 기술을 사용하여 훨씬 더 나은 검색 엔진을 구축한 Google과는 다릅니다. 거의 모든 미드 마켓 또는 엔터프라이즈 SaaS 제품에는 새로운 기술이 포함되어 있지 않습니다. (고품질 구현을 구축할 필요가 없다는 말은 아닙니다. 물론 구축할 필요가 있습니다. 하지만 "우리가 이것을 구축할 수 있을까 / 작동하게 만들 수 있을까"가 가장 큰 리스크인 경우는 거의 없습니다.)
댓글 3
정말 확실한 답변입니다. 저는 "구매자를 파악하라"고 강조하고 싶습니다. 우리는 문제에 대한 해결책이 있다고 생각했습니다. 최종 사용자로부터 문제에 대한 해결책이 있다는 말을 들었습니다. 제품 가격에 대한 가치도 잘 알고 있다고 생각했습니다. 하지만 실제 구매자는 최종 사용자가 생각한 것과는 전혀 다른 방식으로 제품을 평가했고, 특히 전환 비용 등을 고려하면 그 가치는 엄청나게 낮았습니다.
댓글 4
무시하는 것은 아니지만, 저라면 B2B/엔터프라이즈 제품의 기술적 측면은 나중을 위해 남겨두겠습니다. 가장 중요한 문제는 영업 프로세스/GTM 전략을 수립하는 것입니다. 다른 사람들이 언급했듯이 문제/산업에 대해 잘 알고 기업에 판매한 경험이 있는 사람과 파트너 관계를 맺는 것이 도움이 될 것입니다. 이것이 회사의 핵심 역량이 될 것임을 명심하세요(많은 돈을 벌고 싶다면). 기술 책임자의 업무는 단순히 제품을 제작하고 배송하는 것보다는 컨설팅과 비슷할 것입니다. 혼자서 일을 진행한다면, 고치고자 하는 비즈니스 프로세스에 관련된 많은 사람들과 대화하여 그들이 왜 지금과 같은 방식으로 일을 처리 하는지 구체적으로 이해해야 합니다. 때때로 개발자로서 회사의 문제를 기술적인 문제로 보는 경향이 있지만, 실제로는 조직/정치/사회적인 문제일 가능성이 높습니다. 아직 많은 것을 만들지 말고 보여줄 수 있는 시각적 프로토타입을 만들어 데모/통합/테스트 비용을 청구하세요.
댓글 5
맨 위에서 언급한 내용은 정말 좋은 내용이 입니다. 저는 제조 분야의 엔터프라이즈 SaaS 스타트업에서 엔지니어링을 책임지고 있습니다. 여기에 몇 가지 사항을 추가하고 싶었습니다:
- 소프트웨어 통합: 엔터프라이즈 소프트웨어는 백지 상태에 배포되는 경우는 거의 없습니다. 회사에서 사용하는 수많은 기존 소프트웨어가 있을 것이고, 이 소프트웨어와 통합 하기를 원할 것입니다. 가장 일반적으로 Salesforce와 같은 CRM이나 SAP, Oracle과 같은 ERP가 있습니다. 고객에게 프레젠테이션을 할 때는 고객이 어떤 기존 소프트웨어 도구를 사용하는지 알아보고 궁극적으로 통합할 수 있는 기회가 있는지 알아보는 것이 좋습니다. 이렇게 하면 나중에 소프트웨어를 제거하기가 매우 어려워지고 통합을 피하려는 경쟁업체와 차별화할 수 있습니다. 통합을 염두에 두고 아키텍처를 설계하는 것은 좋은 생각입니다.
- 감사 로그: 업계에 따라 규정 준수/감사에 대한 강력한 요구 사항이 있을 수 있습니다. 기업은 플랫폼에서 수행된 모든 작업이 감사되고 나중에 필요에 따라 검토할 수 있도록 하려고 할 것입니다.
- 온프레미스 배포와 클라우드 배포: 자체 하드웨어와 소프트웨어를 운영하는 특정 클라이언트는 시스템에 배포할 수 있는 실행 파일만 전달해 주기를 원할 수 있습니다. 반면에 클라우드에 올인하여 Azure, AWS 또는 GCP와 같이 잘 알려진 클라우드에 배포하는 한 눈 하나 깜짝하지 않는 회사도 있습니다. 점점 더 많은 기업이 프라이빗 클라우드로 전환하면서 자사 클라우드 계정(주로 Azure - 엔터프라이즈 시장에서는 Microsoft가 훨씬 더 강력한 입지를 확보하고 있음)에 배포해 달라고 요청하고 있습니다. 이러한 요청을 처리할 준비를 하세요. 경우에 따라서는 클라우드 계정에서 SaaS를 제공하도록 푸시할 수 있지만 항상 그런 것은 아닙니다.
- IT 부서: 엔터프라이즈 기업에는 기술적인 관점에서 조달 프로세스가 원활하게 진행되고 모든 기술 요구 사항을 준수하는지 확인하는 IT 부서가 항상 존재합니다. 이들의 주요 임무는 나중에 기술/규정 준수 문제로 인해 누구도 그들을 비난하지 않도록 보장하는 것입니다. 영업 프로세스에서 이들을 배제하지 마세요. 영업팀은 판매를 승인할 권한은 없지만 판매를 차단할 권한은 분명히 있습니다. 나중에 병목 현상이 발생하지 않도록 이들과 긴밀히 협력하고 강력한 동의를 얻어야 합니다.
댓글 6
2개의 성공적인 엔터프라이즈 앱(1개는 판매되었고, 1개는 현재 1억 달러 이상의 가치를 지니고 있음)을 구축하고 실패한 다른 앱도 개발해본 사람으로서
- 지금 걱정해야 할 것은 고객이 앱을 정말로 원하고 필요로 하는지 여부뿐입니다. 엔터프라이즈 SaaS 제품의 99%가 실패하는 이유는 기능이 누락되었기 때문이 아니라 바로 이 때문입니다.
- SSO, 통합, 감사 추적 등과 같은 모든 엔터프라이즈 기능은 고객이 요청할 때 구축할 수 있으며, 이는 대부분 해결되는 문제입니다. 이러한 문제는 엔지니어링 문제이고 여러분이 엔지니어이기 때문에 매력적인 문제로 보이겠지만 이러한 문제는 무시하고 비즈니스 문제에 집중하세요. "내 앱이 고객의 절실한 요구를 해결해 주는가?". "엄마 테스트"를 읽고 이 질문에 답하는 마음가짐을 가지세요. 지금 중요한 것은 그것뿐입니다.
첫 번째 SaaS 회사 Concur 이야기
해외 SaaS 시장의 역사를 종종 찾아 봅니다. 우리보다 이른 시기에 시작된 SaaS 시장에서 기업들이 겪었던 변화의 과정과 새로운 성장의 과정을 통해 배울 수 있는 부분이 분명 많이 있을거란 생각 때문 입니다.
아마도 지금 우리의 SaaS 시장이 지금 소개하는 아티클이 작성된 시점의 미국 SaaS 시장의 시점과 비슷하지 않을 까 싶습니다.(우리가 더 느릴 수도 있고요).
2015년에 작성된 이 아티클은 지금은 이름만 대면 알만한 글로벌 SaaS 회사의 드라마틱한 비즈니스 모델 변신의 성공 과정을 이야기 합니다. SaaS 모델이 주는 가치를 정확히 보여주는 사례라고 생각 됩니다.
한글로 요약 했습니다. 하-지-만 주인공 회사가 보여준 아름다운 성장 그래프 곡선은 원문에서 꼭 확인해보시기를 추천 합니다.
▼
이 회사는 최초의 SaaS 스타트업은 패키지 소프트웨어 회사로 시작했습니다. 컴퓨터 소프트웨어 상점에서 플로피 디스크와 CD-ROM으로 소프트웨어를 판매하던 이 회사는 처음으로 모델을 변경하여 기업에 직접 소프트웨어 라이선스를 판매하기 시작했습니다. 이 회사는 1998년 이 모델로 상장 했습니다. 그러나 2001년 주가가 폭락한 직후 이 스타트업의 시가총액은 800만 달러에 불과했습니다.
그로부터 이 비즈니스는 다시 진화하여 브라우저만 있으면 누구나 액세스할 수 있는 소프트웨어를 판매하는 순수 SaaS 비즈니스가 되었습니다. 13년 후, 2014년에는 연간 6억 달러 이상의 매출을 올렸고, 사상 최대 규모의 SaaS 인수합병으로 83억 달러에 SAP에 매각 되었으며, 매출과 현금 흐름 손익분기점을 모두 달성한 몇 안 되는 SaaS 기업 중 하나가 되었습니다. 그 회사는 출장 및 경비 비즈니스인 Concur 입니다.
SaaS의 역사는 그리 길지 않습니다. 하지만 Concur의 역사는 몇 가지 이유로 SaaS 역사에서 중요한 기업이라고 할 수 있습니다. 첫째, 이 회사의 창립자들은 끈기와 인내를 가지고 끈질기게 노력하여 궁극적으로 시장 카테고리를 정의(개척)하는 회사를 만들었습니다. 둘째, Concur의 역사는 라이선스 소프트웨어와 SaaS 비즈니스 모델의 극명한 차이점을 보여 줍니다.
위의 차트는 1995년부터 2014년까지 세 기간에 걸친 Concur의 매출을 나타낸 것입니다. 각 시대(CD, 라이선스, 클라우드)는 음영 처리되어 있습니다. 라이선스 소프트웨어 비즈니스로 전환하면서 약 2백만 달러의 매출을 올렸습니다. 그 후 Concur는 2001년 SaaS 판매로 전환하기 전까지 5년 동안 약 4,100만 달러로 빠르게 성장했습니다. Concur는 2005년에 클라우드로의 완전한 전환을 완료했습니다. 그 후 2014년에는 매출이 7억 달러 이상으로 급증했습니다.
Concur의 총 마진은 클라우드 시대 후반에 가장 높았습니다. CD 시절에는 소프트웨어를 디스크에 기록하고, 포장하고, 배송하고, 상자를 입고하고, 소매점에 지불하는 수수료로 인해 총 마진이 40% 이하로 떨어졌습니다. 라이선스 모델은 총 마진을 60% 이상으로 높였습니다. 라이선스 시대에는 전문 서비스(교육 및 사용자 지정)가 비즈니스의 매출 원가(COGS)의 대부분을 차지했습니다. 클라우드 시대에는 규모의 경제를 통해 2010년에 약 72%의 역대 최고 총 마진을 달성할 수 있었습니다.
Concur는 SaaS로 전환한 후 매출 대비 순이익이 -100% 미만인 비즈니스에서 순이익 흑자 비즈니스로 전환했습니다. 또한 거의 동시에 비즈니스는 현금 흐름 손익분기점 에 도달했습니다. 현금 흐름 손익분기점과 순이익 흑자라는 두 가지 목표를 모두 달성하는 것은 결코 쉬운 일이 아니며, 이는 회사의 비즈니스 모델의 강점과 경영진의 규율을 입증하는 증거입니다.
저는 Concur의 설립자이자 CEO인 Steve Singh에게 회사의 역사에 대해 이야기를 나눴는데, 그는 이렇게 말했습니다.
"우리는 현금 흐름이 플러스가 되는 것만으로는 충분하지 않다고 판단했습니다. 또한 수익을 내고 싶었습니다. 비즈니스에 큰 규율을 강요합니다... 흑자를 내면 우리가 잘하지 못하는 모든 것이 드러납니다. 우리가 잘하는 것과 함께 약점에도 집중할 수 있다면 우리는 경쟁자가 이길 수 없는 기업이 될 것입니다."
한 번의 주요 비즈니스 모델 진화에서 살아남는 기업은 극소수에 불과합니다. Concur는 두 번의 변화를 겪은 후에도 번창하여 탁월한 재무 성과를 기록하고 있으며, 처음부터 창업자가 주도하는 기업이라는 점에서 매우 이례적입니다.
Supply Chain 소프트웨어 로드맵
Supply Chain 소프트웨어 시장은 Vertical 영역으로 대중에게는 낯설 수 있는 분야 이기도 합니다. 하지만 그 규모와 성장성은 다른 어떤 시장 보다도 높게 평가 됩니다. 실제로 많은 스타트업들이 AI/ML 기술을 바탕으로 뛰어들고 기존 Big logo 기업들도 As a Service 형태로 서비스를 진화해 나가고 있는 치열한 시장 입니다.
특히나 AWS는 지난 2022년 Re:invent에서 머신러닝 기반의 AWS Supply Chain 이라는 비즈니스 애플리케이션을 As a Service 형태로 출시 해서 세간의 이목을 끌기도 했습니다. (*형이 거기서 왜 나와 느낌이랄까요?)
오늘 소개하는 이 글은 Supply Chain 소프트웨어 시장 분석과 함께 Supply Chain 소프트웨어에 대한 분석과 로드맵을 보여주고 있습니다. 관심있는 분들 혹은 업계에 계신 분들은 시간 내어 보셔도 좋을 것 같습니다. 참고로 다음 유튜브 영상을 통해 확인할 수도 있습니다.
▼
21년 기준 supply chain SW TAM은 $25B. 2027년까지 $50B 성장 예상 (CAGR 11.7%)
(*글로벌 물류, 공급망 산업은 $11T, CAGR 5%)
2020년 맥킨지 조사에 따르면 미국의 엔터프라이즈급 물류사의 50%가 여전히 이메일가 스프레시트 조합에 의존하여 supply chain 워크플로어 운영
supply chain SaaS opportunity driver는
- 글로벌 공급망 충격이 빈번하게 발생하며 많은 기업들이 supply chain resilience를 올리는 것이 비즈니스 우선순위에 두고 있음(맥킨지 조사에 따르면 엔터프라이즈 supply chain 리더들 중 93%가 이렇게 응답 했다고함)
- 증가하는 디지털화 작업: 공급망 데이터 생성 방법과 저장 위치 가 점점 디지털화되고 현대화 되고 있음. 아직까지 많은 공급망 데이터들이 사일로화 되어 온프렘에 저장되어 있어 데이터를 통한 인사이트를 얻기 어렵지만(데이터간 통합 분석의 어려움), 점점 클라우드로 옮겨가며 이를 해결하는 모습
흥미롭게 지켜볼 supply chain SaaS 의 카테고리들.
- Digital Infrastructure
- Workflow automation and optimization tools
- Supplier intelligence
- Developer platforms
이번 주간 SaaS 여기서 마무리 합니다. 이번 주간 SaaS 에서 다룬 콘텐츠에 대한 여러분의 의견이 궁금합니다. 아래 👇🏽댓글에 남겨 주세요. 함께 토론하며 배움을 확장하면 좋겠습니다.
의견을 남겨주세요