When Your Product Breaks, You Need to Own It. Here's How.
실수는 발생하며, 기업은 이를 이해합니다. 그들이 절대 이해하지 못하는 것은 뭔가 잘못되었다고 이야기하지 않을 때입니다. 투명성이 핵심입니다.
SaaS가 주류가 되면서, 모든 규모의 기업들은 SaaS 공급자에게 신뢰할 수 있고 고품질의 솔루션을 제공해 줄 것을 의존하고 있습니다. 이 의존성은 이제 SaaS가 기업 운영의 모든 측면을 지원하는 만큼 정말로 "임무에 필수적"입니다. 다운타임이 발생하면 비즈니스에 재앙적인 영향을 미칠 수 있습니다.
물론, 이는 새로운 개념은 아니며, 소프트웨어는 수십 년 동안 임무에 필수적인 비즈니스 프로세스를 지원하기 위해 구축되어 왔습니다. 차이점은 SaaS의 경우 기업이 더 이상 소프트웨어의 운영에 대한 통제를 갖고 있지 않다는 것입니다. 이제 그것은 공급자의 책임입니다. 온프레미스 소프트웨어 비즈니스에 있었던 우리는 오랜 시간 전에 이 교훈을 배웠습니다. 우리는 애플리케이션 개발 비즈니스에 있었지만, 지금은 애플리케이션 _배포_ 비즈니스에 있습니다. 저는 Boomi의 온프레미스에서 SaaS로의 전환 초기 단계에서 운영 팀에 대한 개념이 없었던 기억이 납니다(왜 그게 필요했겠습니까?) 그리고 그걸 처음부터 만들어야 했습니다.
그래서 기업들은 이제 공급자에게 더 많은 의존성을 가지게 되었고, 그들은 단순히 가치 있는 지속적인 제품 혁신을 제공할 것뿐만 아니라, 이러한 기능의 제공과 애플리케이션의 지속적인 운영이 영향을 미치지 않고, 성능이 뛰어나며 신뢰할 수 있도록 보장해야 합니다.
이 과정에서 실수가 발생하게 마련입니다. 제품이 확장되면 아키텍처의 허점이 드러나며, 이것이 중단으로 이어질 수 있습니다. 버그가 릴리스에 도입됩니다. 하드웨어 업그레이드가 계획대로 진행되지 않습니다. 이 모든 것이 중단으로 이어질 수 있으며, 비즈니스에 상당한 영향을 미칠 수 있습니다.
다시 말하지만, 이러한 실수는 결코 새로운 것이 아닙니다. 새로운 것은 누가 실수를 하고 있느냐입니다. 온프레미스 시절에는 IT 부서로 가서 문제를 소리치기만 하면 문제가 해결되곤 했습니다. 당신은 당신의 문제 상태를 직접 확인할 수 있었습니다. 요즘은 당신의 앱이 작동을 멈췄다는 것 외에는 아무것도 알지 못합니다. 언제, 왜, 누가 문제를 해결하고 있는지, 또는 언제 해결될지를 모릅니다.
이것이 Boomi의 온프레미스에서 SaaS로의 전환에서 제가 배운 가장 큰 교훈입니다: 투명성입니다. 이는 가장 중요한 개념이며 귀사의 전체 직원의 DNA의 일부가 되어야 합니다. 기업은 일이 터진다는 것을 이해합니다. 내 말을 오해하지 마세요, 당신은 세계적 수준이어야 하고, 같은 실수를 두 번 반복하지 않도록 해야 합니다. 하지만 실수는 발생하며, 기업은 이를 이해합니다. 그들이 절대 이해하지 못하는 것은 뭔가 잘못되었다고 이야기하지 않을 때입니다. 고객이 그렇게 열심히 쌓아온 신뢰를 잃는 더 빠른 방법은 없습니다.
여기 Boomi에서 고객 위기를 성공적으로 관리하기 위해 알아낸 몇 가지 방법이 있습니다:
- 적극적이어야 합니다. 고객이 중단에 대해 이야기하면, 이미 진 것입니다.
- 중단을 소유하십시오. 문제가 발생할 경우, 최대한 빨리 실수했음을 인정하세요. 무엇이 잘못되었는지 아직 알 필요는 없지만, 무언가 잘못되었다는 것을 알게 되는 즉시 이를 소통해야 합니다 뭔가 잘못되었습니다. 1번을 참조하세요.
- 자주 업데이트를 제공합니다. 업데이트가 "아직 작업 중입니다"라는 간단한 것이더라도 괜찮습니다. 업데이트 빈도는 문제의 영향과 애플리케이션의 중요성에 따라 다릅니다. 완전히 중단되어서 고객이 수익을 올릴 수 없을 경우에는 매 15분마다 업데이트를 제공해야 합니다.
- 업데이트에 다음 업데이트를 제공할 시점을 적고, 그 시점을 소통하십시오.
- 재가동되면 즉시 이를 소통하고, "원인 및 시정 조치" 보고서를 제공하겠다고 약속하십시오. 문제를 유발한 것은 무엇이며, 다음 번에 같은 일이 발생하지 않도록 하기 위해 어떤 시정 조치를 취했는지 알려주십시오.
- 추가 사항: 당신이 의존하는 공급자가 다운된 것이 원인이라면, 그렇게 말해도 괜찮지만, 고객에게는 전혀 아무런 의미가 없다는 것을 깨달아야 합니다. 그들은 당신이 그들에게 애플리케이션을 제공하는 사람으로 여기며, 사용하는 3자 공급자가 무엇인지에는 신경 쓰지 않습니다. 그들은 당신이 어떻게 해서 당신의 앱이 발생한 문제를 다시 반복하지 않도록 할지를 알고 싶어합니다.
이러한 단계를 따르면, 고객에게 여러분이 그들의 우선사항이라는 것을 보여주게 될 것이며, 문제가 발생할 경우 항상 알려줄 것임을 보여주고, 배달을 지속적으로 개선할 수 있는 프로세스를 가지고 있음을 보여줄 것입니다. 이는 고객과의 장기적인 관계에 크게 기여할 것입니다.
SaaS가 주류가 되면서, 모든 규모의 기업들은 SaaS 공급자에게 신뢰할 수 있고 고품질의 솔루션을 제공해 줄 것을 의존하고 있습니다. 이 의존성은 이제 SaaS가 기업 운영의 모든 측면을 지원하는 만큼 정말로 "임무에 필수적"입니다. 다운타임이 발생하면 비즈니스에 재앙적인 영향을 미칠 수 있습니다.
물론, 이는 새로운 개념은 아니며, 소프트웨어는 수십 년 동안 임무에 필수적인 비즈니스 프로세스를 지원하기 위해 구축되어 왔습니다. 차이점은 SaaS의 경우 기업이 더 이상 소프트웨어의 운영에 대한 통제를 갖고 있지 않다는 것입니다. 이제 그것은 공급자의 책임입니다. 온프레미스 소프트웨어 비즈니스에 있었던 우리는 오랜 시간 전에 이 교훈을 배웠습니다. 우리는 애플리케이션 개발 비즈니스에 있었지만, 지금은 애플리케이션 _배포_ 비즈니스에 있습니다. 저는 Boomi의 온프레미스에서 SaaS로의 전환 초기 단계에서 운영 팀에 대한 개념이 없었던 기억이 납니다(왜 그게 필요했겠습니까?) 그리고 그걸 처음부터 만들어야 했습니다.
그래서 기업들은 이제 공급자에게 더 많은 의존성을 가지게 되었고, 그들은 단순히 가치 있는 지속적인 제품 혁신을 제공할 것뿐만 아니라, 이러한 기능의 제공과 애플리케이션의 지속적인 운영이 영향을 미치지 않고, 성능이 뛰어나며 신뢰할 수 있도록 보장해야 합니다.
이 과정에서 실수가 발생하게 마련입니다. 제품이 확장되면 아키텍처의 허점이 드러나며, 이것이 중단으로 이어질 수 있습니다. 버그가 릴리스에 도입됩니다. 하드웨어 업그레이드가 계획대로 진행되지 않습니다. 이 모든 것이 중단으로 이어질 수 있으며, 비즈니스에 상당한 영향을 미칠 수 있습니다.
다시 말하지만, 이러한 실수는 결코 새로운 것이 아닙니다. 새로운 것은 누가 실수를 하고 있느냐입니다. 온프레미스 시절에는 IT 부서로 가서 문제를 소리치기만 하면 문제가 해결되곤 했습니다. 당신은 당신의 문제 상태를 직접 확인할 수 있었습니다. 요즘은 당신의 앱이 작동을 멈췄다는 것 외에는 아무것도 알지 못합니다. 언제, 왜, 누가 문제를 해결하고 있는지, 또는 언제 해결될지를 모릅니다.
이것이 Boomi의 온프레미스에서 SaaS로의 전환에서 제가 배운 가장 큰 교훈입니다: 투명성입니다. 이는 가장 중요한 개념이며 귀사의 전체 직원의 DNA의 일부가 되어야 합니다. 기업은 일이 터진다는 것을 이해합니다. 내 말을 오해하지 마세요, 당신은 세계적 수준이어야 하고, 같은 실수를 두 번 반복하지 않도록 해야 합니다. 하지만 실수는 발생하며, 기업은 이를 이해합니다. 그들이 절대 이해하지 못하는 것은 뭔가 잘못되었다고 이야기하지 않을 때입니다. 고객이 그렇게 열심히 쌓아온 신뢰를 잃는 더 빠른 방법은 없습니다.
여기 Boomi에서 고객 위기를 성공적으로 관리하기 위해 알아낸 몇 가지 방법이 있습니다:
- 적극적이어야 합니다. 고객이 중단에 대해 이야기하면, 이미 진 것입니다.
- 중단을 소유하십시오. 문제가 발생할 경우, 최대한 빨리 실수했음을 인정하세요. 무엇이 잘못되었는지 아직 알 필요는 없지만, 무언가 잘못되었다는 것을 알게 되는 즉시 이를 소통해야 합니다 뭔가 잘못되었습니다. 1번을 참조하세요.
- 자주 업데이트를 제공합니다. 업데이트가 "아직 작업 중입니다"라는 간단한 것이더라도 괜찮습니다. 업데이트 빈도는 문제의 영향과 애플리케이션의 중요성에 따라 다릅니다. 완전히 중단되어서 고객이 수익을 올릴 수 없을 경우에는 매 15분마다 업데이트를 제공해야 합니다.
- 업데이트에 다음 업데이트를 제공할 시점을 적고, 그 시점을 소통하십시오.
- 재가동되면 즉시 이를 소통하고, "원인 및 시정 조치" 보고서를 제공하겠다고 약속하십시오. 문제를 유발한 것은 무엇이며, 다음 번에 같은 일이 발생하지 않도록 하기 위해 어떤 시정 조치를 취했는지 알려주십시오.
- 추가 사항: 당신이 의존하는 공급자가 다운된 것이 원인이라면, 그렇게 말해도 괜찮지만, 고객에게는 전혀 아무런 의미가 없다는 것을 깨달아야 합니다. 그들은 당신이 그들에게 애플리케이션을 제공하는 사람으로 여기며, 사용하는 3자 공급자가 무엇인지에는 신경 쓰지 않습니다. 그들은 당신이 어떻게 해서 당신의 앱이 발생한 문제를 다시 반복하지 않도록 할지를 알고 싶어합니다.
이러한 단계를 따르면, 고객에게 여러분이 그들의 우선사항이라는 것을 보여주게 될 것이며, 문제가 발생할 경우 항상 알려줄 것임을 보여주고, 배달을 지속적으로 개선할 수 있는 프로세스를 가지고 있음을 보여줄 것입니다. 이는 고객과의 장기적인 관계에 크게 기여할 것입니다.
Experience the power of the Guru platform firsthand – take our interactive product tour
투어 신청
