“이 회사는 체계가 없어.”라는 말을 정말 많이 하는데요.
비단 초기 스타트업뿐만 아니라 이제는 성장해 대기업에 가까워진 곳에서도 많이 들리는 이야기인 것 같습니다.
여기서 ‘체계'란 무엇을 의미하는 걸까요?
실제 상황에 따라 다르겠지만, 일반적으로는 프로세스가 없고 그때그때 주먹구구식으로 일이 진행될 때 보편적으로 사용되는 것 같아요.
조직에 정해진 프로세스가 없다면, 우리는 체계 없이 일할 수밖에 없는 걸까요?
개인적으로는 그렇지 않다고 생각합니다. 물론 어느 정도 한계가 있을 수도 있겠지만, 우리의 역할 범위 내에서도 충분히 체계를 갖춰서 일할 수 있는 방법이 있습니다.
바로 프로세스적으로 생각하고 일하는 것인데요.
오늘 콘텐츠를 보고 나면 기존에 설명하지는 못했지만 이미 알고 있고 그렇게 해 오던 부분일 수도 있을 것 같아요.
하지만 일종의 개념적 틀로서 이를 이해하고 나면 동료나 상사, 혹은 다른 이해관계자와 커뮤니케이션할 때 정말 유용하게 적용할 수 있을 거예요. 또한 실제로 문제를 해결하는 과정에서도 그렇고요.
이런 맥락에서 오늘 콘텐츠에서는 크게 두 가지 프레임워크를 소개하려고 해요. 아래 내용을 보시면 아시겠지만, SIPOC는 IPO에 Supplier와 Customer가 추가된 개념이에요. 조금 더 고객 중심적인 관점이 적용되었다고 할 수 있어요.
- IPO : Input - Process - Output
- SIPOC : Supplier - Input - Process - Output - Customer
개념 자체는 매우 간단해서 정말 매우 쉽게 이해하고 실천해 보실 수 있을 거예요! (하지만 실천은 조금 어려울지도....!?)
프로세스란?
사실 우리가 하는 모든 일은 프로세스라고 봐도 무방할 정도여서, 프로세스에 대한 명확한 이해는 우리가 우리의 역할을 스스로 정의하고 수행하기 위해 필수적으로 이해해야 하는 요소 중 하나라고 할 수 있어요.
기본적으로는 단순한 일이든 복잡한 일이든 결국에는 프로세스로 표현될 수 있어요. 업무를 프로세스로 가시화한다고 이해해 주시면 좋을 것 같아요.
- 단순한 일은 프로세스에 관련되어 있는 역할이 적고, 병렬적으로 진행되는 프로세스가 적거나 각 프로세스의 내부 단계가 단순할 거예요.
- 복잡한 일은 프로세스에 관련되어 있는 역할이 많고, 병렬적으로 진행되는 프로세스가 많거나 각 프로세스의 내부 단계가 복잡할 거예요. 혹은 계속해서 반복되는 프로세스일 수도 있고요.
그러면 프로세스로 생각하고 일하는 것은 무엇을 의미할까요?
기본적으로 우리가 수학 시간에 배운 함수와 비슷하다고 생각하시면 될 것 같아요.입력, 처리, 출력으로 구성되어 있는 것이죠. 아마 개발이나 엔지니어링 혹은 제조업에서 업무를 하시는 분들에게는 매우 익숙한 개념일 수도 있을 것 같아요.
이와 관련해서는 아래 목차에서 프레임워크를 소개하며 더 자세히 이야기해 보도록 하겠습니다.
하지만 프로세스가 우리의 모든 것을 해결해 주지는 않는다는 것을 명심해야 해요.
- 프로세스의 기본 구조는 단순하다는 장점이 있지만 통제하는 것(명확한 인과관계를 가정함)에 초점을 두고 있어요. 따라서 프로세스에 너무 의존하면 필연적으로 발생한 회색 지대에서 과도한 마찰과 지연이 발생하거나 업무를 수행하는 과정에서 발생하는 상황(변수)에 유연하게 대처하지 못할 수도 있고요.
- 프로세스대로 일하는 것이 성과를 보장해 주지는 않아요. 프로세스는 결과(Outcome)가 아니라 산출물(Output)에 초점을 맞추고 있어요. 그렇기에 ‘일을 했는가?’에는 답할 수 있지만, ‘기대치에 부합하게 일을 했는가?’에는 답할 수 없어요. 따라서 산출물이 결과(성과)로 이어지고 있는지를 모니터링하는 것도 중요해요. (물론 이 또한 프로세스로 관리할 수는 있겠지만...)
프로세스로 생각하고 일하는 방법
인트로에서 말씀드린 것처럼 오늘은 IPO와 SIPOC 두 개의 프레임워크를 소개해 드릴 텐데요. 내용 자체는 매우 단순한 편이어서 쉽게 이해하고 활용해 보실 수 있을 것 같아요.
먼저 IPO의 경우 “Input - Process - Output”으로 매우 단순하게 구성되어 있는데요. 여기에서 Process는 여러 위계 혹은 병렬적인 다른 프로세스들이 포함될 수 있어요. 그래서 실제로 시각화된 모습은 조금 복잡할 수도 있죠.
- Input : 프로세스의 시작을 위해 필요한 정보, 리소스
- Process : 일이 처리되는 과정, 즉, 업무 활동(activity)의 집합 (누가, 언제, 어떻게, 무엇을 가지고 ...)
- Output : 프로세스가 종료된 시점에서의 상황 혹은 산출물 (업무의 결과물)
위의 내용에서 알 수 있는 것처럼, 프로세스를 정의하기 위해서는 명확한 인풋과 아웃풋을 정의할 수 있어야 해요.
개인적으로는 최종적인 아웃풋을 먼저 정의하고, 아웃풋을 만들어 내기 위해 무엇이 필요한지를 되짚어가며 프로세스를 설계하거나 개선하는 편이에요.
- 먼저 업무의 목적, 목표에 따라 필요한 최종적인 아웃풋을 정의해요. 아웃풋은 경우에 따라 다르지만 제품이나 서비스, 혹은 다른 프로세스에 필요한 인풋일 수도 있어요.
- 아웃풋을 만들어 내기 위해 필요한 선행 작업(활동)과 인풋을 정의해요. 이 과정에서는 아웃풋을 기준으로 역순으로 차근차근 탐색할 수도 있고, 기존의 업무나 프로세스를 바탕으로 재조정하거나, 필요하다고 판단되는 활동을 나열하고 이를 정렬할 수도 있어요. 다양한 방법이 존재할 수 있을 거예요.
- 결과적으로 프로세스는 선후관계가 있는 활동의 집합으로 정의되고, 그 안에서 활동에 필요한 인풋과 아웃풋이 또 정의될 수 있어요. 즉, A → B → C 라는 활동이 정의가 되었다면, A 활동을 위한 인풋과 A 활동의 결과물(아웃풋)이 정의되고, A 활동의 결과물이 다시 B 활동의 인풋으로 정의될 수 있겠죠. A 활동을 위한 인풋을 전체 프로세스의 인풋으로 정의될 것이고, C 활동의 아웃풋은 전체 프로세스의 아웃풋으로 정의될 거예요.
- 그리고 마지막으로(사실 병렬적으로 이루어져야 하는 작업이기는 하지만) 해당 활동을 누가 수행할 것인지를 정의해야 해요. 즉, ‘누가 해당 활동의 아웃풋을 만들 것이냐'의 문제인 것이죠. 이 과정을 통해 조직 내에서 R&R이 설정되는 거예요.
말은 간단하지만, 이 안에서 피드백되는 구조(루프)가 존재할 수도 있어요.
예를 들어, 고객을 통해 주문 제작 상품을 만드는 프로세스라고 했을 때, 고객이 제품 요구사항을 입력하고, 내부에서 검토한 후, 고객에게 견적을 발송하고, 고객이 견적을 검토하고, 공식적으로 발주를 넣는 프로세스가 있을 수 있을 거예요.
내부에서 고객의 요구사항을 검토하는 과정에서 추가로 필요한 정보가 있다면 다시 입력을 요청하도록 할 수 있어요. 또 고객이 견적을 검토하고 추가로 필요한 사항이나 요구사항이 있다면 다시 요구사항을 수정하거나 다시 견적서를 작성하는 일이 필요할 수도 있을 거예요.
이런 프로세스가 설계되고 작동할 수 있다면, 웹이나 앱을 통해 제품의 형태로 고객에게 서비스될 수도 있어요. 온라인 커머스 플랫폼이나 배달 플랫폼을 생각해 보시면 이해가 더 빠를 것 같아요. 이 과정에서 자동화(혹은 전산화)할 수 없는 활동은 전화나 문자(채널톡 같은)를 활용하기도 하고요.
요약하면 프로세스로 생각하고 일하는 것은 다음과 같은 요소를 고려해야 하는 것이죠.
- 무엇을 기대하는가? : 최종적인 아웃풋에 대한 정의
- 아웃풋을 만들어 내기 위해 무엇이 필요한가? : 인풋과 프로세스에 대한 정의 (프로세스 내부의 활동에 대한 인풋과 아웃풋 정의 포함)
- 각 활동을 누가 수행할 것인가? : 역할과 책임(R&R)의 정의 (이 과정에서 소요시간 혹은 기간, 장소 등 필요한 다른 요소도 함께 고려해요.)
그러면, SIPOC는 무엇이 다른 걸까요? 앞에서 소개하면 IPO에 S(Supplier)와 C(Customer)가 추가된 프레임워크인데요. 풀어서 이야기하면 누구(공급자)에게, 무엇(인풋)을 받아서, 어떤 활동(프로세스)를 통해, 무엇(아웃풋)을 만들어서, 누구(고객)에게 전달할 것인가를 표현할 수 있는 도구에요.
본질적으로는 IPO와 동일하지만 공급자와 고객을 고려해, 더 큰 그림(넓은 관점)으로 업무를 시각화할 수 있는 것이죠.
- Customer(고객) : 아웃풋이 전달되는 대상인 고객을 명확하게 정의함으로써 더욱 목적(모든 비즈니스 프로세스는 고객에게 가치를 전달하기 위해 존재하는 것이에요.)에 부합하도록 프로세스를 설계하거나 개선할 수 있도록 해줘요. 즉, 인트로에서 이야기한 프로세스의 한계(결과(Outcome)를 보장하지 않음)를 보완할 수 있는 요소이기도 하죠.
- Suppier(공급자) : 일반적으로 인풋을 제공하는 이해관계자를 의미해요. 만약 제조 혹은 유통, 식품과 같은 산업에서 원재료를 공급하거나, 부품을 제공받는 것이 포함될 수 있어요. 우리가 업무를 수행하기 위해 필요한 이해관계자를 더 명확히 정의한다는 관점에서 바라볼 수 있을 것 같아요.
어떻게 활용할 수 있을까?
프로세스를 정의하는 것은 기본적으로 업무를 시각화하고 다른 사람들(이해관계자, 동료 등)과 협업하기 위함이고, 더 나아가 업무를 자동화하는 데에도 활용할 수 있어요. (그 결과가 플랫폼과 같은 서비스나 제품일 수도 있고요.)
프레임워크는 그 프레임워크를 그대로 활용하는 것이 중요하다기보다는, 목적에 맞게 사용하는 것이 가장 중요하다고 생각하는 편이에요. 따라서 프레임워크가 제공하는 이점을 명확히 이해하고 그 이점을 활용하는 것이 중요하죠.
따라서 어떤 경우에는 특정 요소가 생략될 수도 있고, 시각화한 결과도 아래와 같이 다양할 수 있어요.
지난번 작성한 전략기획에서 성과관리 시스템을 설계하면 생기는 일에서 작성한 성과관리 프로세스 내용도 다시 한번 보시면 좋을 것 같기도 합니다!
오늘 소개한 프로세스로 생각하고 일하는 방법은 다양한 상황에 적용해 보실 수 있을 거예요. (프로세스를 구축하거나 개선할 때는 당연히 활용할 수 있겠죠? 🤣)
- 역할과 책임을 정의할 때
- 복잡한 업무를 가시화할 때
- 프로젝트를 기획할 때 등
모든 문제가 프로세스로 해결되지 않으며 모든 업무가 프로세스를 따라 진행될 수 있는 건 아니지만, 프로세스의 관점에서 업무와 문제를 바라보는 연습을 통해 나의 역할과 범위, 그리고 성과를 정의하는 것은 물론 문제를 해결하는 역량 또한 발전해 나갈 수 있지 않을까 싶습니다.
🙏🏻 오늘의 콘텐츠가 일상의 수많은 고민들 중 하나라도 해결할 수 있는 실마리가 되어주었기를 바랍니다.
💌 오늘의 콘텐츠가 도움이 될 것 같은 사람이 주변에 있다면 공유해 주세요!
👂🏻 콘텐츠에 대한 의견이나 보고 싶은 콘텐츠가 있다면 편한 방법으로 말씀해 주세요! (댓글도 환영!!)
• email : hakguan.b@gmail.com
• instagram : https://www.instagram.com/strategy4every/
• thread : https://www.threads.net/@strategy4every
• 오픈카톡 : https://open.kakao.com/o/gQ8ni1og
댓글
의견을 남겨주세요