모든 프로세스가 서로 다른 도구에 흩어져 있을 때

판매는 한 플랫폼에서, 교육은 또 다른 플랫폼에서 이루어집니다. 보고서는 스프레드시트에 있고, 소통은 여러 채널에 흩어져 있습니다. 관리 정보는 또 다른 별도 시스템에 있습니다.

하나씩 놓고 보면 각 도구는 제 역할을 잘하고 있을지도 모릅니다. 특정 시점의 아주 구체적인 필요를 해결하기 위해 도입된 것일 수도 있습니다.

문제는 그다음에 찾아옵니다.

회사가 성장하면 프로세스는 더 이상 따로 움직이지 않습니다. 정보가 한 부서에서 다른 부서로 이동하기 시작하고, 하나의 업무가 이전 업무에 의존하며, 여러 팀이 의사결정을 위해 같은 데이터를 참조해야 합니다.

이 시점에서 진짜 과제는 더 이상 도구를 충분히 갖추는 것이 아닙니다.

모든 도구를 하나로 연결된 운영의 일부로 만드는 것입니다.

하나의 필요를 해결한다고 전체 프로세스가 해결되는 것은 아닙니다

어떤 플랫폼은 설계된 목적에 맞게 완벽하게 작동할 수 있습니다.

문제는 프로세스가 그 플랫폼 밖에서도 이어질 때 나타납니다.

판매 기록은 관리 부서로 전달되어야 합니다. 한 플랫폼에서 변경한 내용은 다른 플랫폼에도 반영되어야 합니다. 보고서는 여러 시스템에 저장된 정보에 의존합니다. 한 팀이 다른 부서가 관리하는 데이터를 확인해야 합니다.

그리고 한 지점에서 다음 지점으로 넘어가는 사이에 추가 업무가 생기기 시작합니다.

정보 내보내기, 파일 업데이트, 데이터 복사, 기록 검증, 일치 여부 확인, 또는 변경 사항이 제대로 반영되었는지 수작업으로 확인하는 일 등입니다.

이런 작업 하나하나는 그다지 복잡해 보이지 않습니다.

하지만 매일 반복되는 프로세스의 일부가 되면 운영에서 상당한 비중을 차지하기 시작합니다.

보이지 않는 업무도 운영의 일부입니다

두 시스템이 서로 소통하지 않으면, 대개 누군가가 그 일을 대신하게 됩니다.

한 플랫폼에서 다른 플랫폼으로 정보를 옮기는 사람일 수도 있습니다. 보고서를 취합하는 팀일 수도 있습니다. 다리 역할을 하는 스프레드시트일 수도 있습니다. 업데이트를 확인하기 위한 이메일일 수도 있습니다. 혹은 모든 것이 일치하는지 확인하기 위해서만 존재하는 일련의 내부 점검일 수도 있습니다.

이런 활동은 프로세스 다이어그램에 나타나지 않는 경우가 많습니다.

그래도 시간이 들고, 주의가 필요하며, 정보의 양이 늘어날수록 함께 늘어납니다.

운영은 계속 돌아가지만, 원래 따로 작동하도록 설계된 도구들을 연결하기 위해 작은 수작업에 점점 더 의존하게 됩니다.

정보가 흩어져 있으면 일관성을 잃을 수 있습니다

같은 데이터가 여러 곳에 존재할 때 또 다른 영향이 나타납니다.

영업팀에 한 가지 버전이 있고, 관리팀에 또 다른 버전이 있습니다. 지원팀에 세 번째 버전이 있을 수 있습니다. 추적용 스프레드시트에 네 번째 버전이 있을 수도 있습니다.

정보가 자주 바뀌지 않을 때는 그 차이가 눈에 띄지 않을 수 있습니다.

하지만 업데이트가 잦아지면 중요한 질문이 생깁니다.

어떤 버전이 맞는 걸까요?

문제는 반드시 사람이나 업무의 질에 있는 것이 아닙니다.

많은 경우 그 원인은 아키텍처에 있습니다.

같은 데이터를 여러 플랫폼에서 수작업으로 업데이트해야 한다면 일관성을 유지하기가 더 어려워집니다. 그리고 관련된 시스템이 많을수록 확인해야 할 지점도 많아집니다.

분산은 팀의 경험에도 영향을 미칩니다

기업의 디지털 경험은 고객만을 위해 존재하는 것이 아닙니다.

내부에도 존재합니다.

매일 운영 안에서 일하는 사람에게는 도구 사이를 끊임없이 오가는 일이 당연하게 느껴질 수 있습니다.

정보를 찾기 위해 한 플랫폼을 열고, 세부 사항을 확인하기 위해 다른 플랫폼을 열고, 다시 처음 플랫폼으로 돌아가 기록을 업데이트한 뒤, 또 다른 채널로 변경 사항을 알립니다.

전환 한 번에 걸리는 시간은 몇 분에 불과할 수 있습니다.

그 영향은 같은 과정이 수십 개의 프로세스, 사람, 근무일에 걸쳐 반복될 때 드러납니다.

그래서 디지털 운영을 개선한다는 것이 항상 새로운 기능을 추가하는 것을 의미하지는 않습니다.

때로는 애초에 필요하지 않았어야 할 단계를 없애는 것을 의미합니다.

통합이 반드시 단일 플랫폼을 쓴다는 뜻은 아닙니다

모든 운영을 하나의 시스템에서 관리하는 것이 편리한 경우도 있지만, 그것만이 질서 있는 기술 생태계를 구축하는 유일한 방법은 아닙니다.

많은 기업에는 전문화된 솔루션이 필요합니다.

차이는 그 솔루션들이 어떻게 함께 작동하느냐에 있습니다.

여러 도구로 구성된 인프라도 명확한 연결, 정보가 어디에 저장되는지에 대한 규칙, 정보를 공유하기 위한 정해진 프로세스가 있다면 효율적으로 작동할 수 있습니다.

따라서 회사가 몇 개의 플랫폼을 사용하는지 묻는 것과 함께, 다음을 생각해 보는 것이 도움이 됩니다.

업무를 중복하지 않고 플랫폼 간에 정보가 이동할 수 있나요?

어떤 시스템이 기준 기록을 보유하는지 명확한가요?

각 팀이 일관된 정보를 참조하고 있나요?

같은 데이터를 다시 입력하지 않고도 하나의 작업이 다음 프로세스로 이어질 수 있나요?

도구의 수만으로 복잡성이 결정되지는 않습니다.

복잡성을 만드는 것은 도구 간 연결의 부재입니다.

새로운 도구는 생태계 전체를 바꿉니다

새로운 필요가 생기면, 이를 해결할 플랫폼을 찾는 것이 자연스러운 반응인 경우가 많습니다.

하지만 기능만 평가하면 의사결정의 중요한 부분을 놓칠 수 있습니다.

도입한 이후에 어떤 일이 일어날지도 따져 봐야 합니다.

어떤 정보를 받아야 할까요?

어떤 데이터를 생성할까요?

누가 그 정보를 확인해야 할까요?

어떤 시스템과 소통해야 할까요?

새로운 수작업 단계가 생기지는 않을까요?

기존 프로세스를 대체할까요, 아니면 워크플로에 또 하나의 지점을 더할 뿐일까요?

질문은 더 이상 이것만이 아니게 됩니다.

“이 도구가 우리가 필요한 일을 해 주는가?”

대신 이런 질문이 됩니다.

“이미 가진 모든 것과 어떻게 함께 작동할 것인가?”

이 차이는 기술을 평가하는 방식을 완전히 바꿉니다.

기술에도 아키텍처가 필요합니다

기업을 디지털화한다는 것은 플랫폼을 쌓아 가는 것이 아닙니다.

시스템, 정보, 프로세스가 함께 작동할 수 있는 구조를 만드는 것입니다.

때로는 기존 도구를 통합하는 것을 의미합니다. 다른 경우에는 연결을 자동화하거나, 프로세스를 재정비하거나, 운영의 핵심 부분을 중앙화할 수 있는 솔루션을 개발하는 것을 의미합니다.

훌륭한 도구를 갖추고도 여전히 분산된 방식으로 운영되는 기업이 있을 수 있습니다.

기술은 독립된 솔루션의 모음으로 작동하기를 멈추고 하나의 생태계처럼 움직이기 시작할 때 더 큰 가치를 만듭니다.

도구를 하나 더 추가하기 전에, 어쩌면 물어야 할 질문은 무엇이 부족한가가 아닐지도 모릅니다.

무엇을 더 잘 연결해야 하는가일지도 모릅니다.

Disruptive Studio는 개별 기능만이 아니라 그 기능이 운영의 나머지 부분과 어떻게 함께 작동해야 하는지까지 고려하여 기술을 구축합니다.

여러분의 디지털 생태계는 연결되어 있나요, 아니면 그저 많은 도구로 이루어져 있을 뿐인가요?