기고 | CRM 비즈니스 프로세스가 정말 워크플로우일까?

CRM 시스템은 워크플로우, 승인 프로세스, 다른 비즈니스 프로세스의 집행 기능을 제공한다. 그러나 어떤 기능을 사용해야 하는지 명확하지 않은 경우가 있고, 지나치게 엄격한 집행을 하다 보면 사용자 만족도에 큰 문제를 초래한다.

기업의 일부 비즈니스 프로세스는 아주 철두철미해야 한다. 엄격한 정책을 적용하고, 기계적이고 순차적으로 작업을 이행해야 한다. 그러나 모든 비즈니스 프로세스를 아주 엄격히 순차적으로, 또는 규칙적으로 적용할 필요는 없다.

CRM 애플리케이션의 일부 영역에서는 아주 유연한 워크플로우가 필요하기도 하다. 특히 판매 주기 동안에는 직원들이 통제할 수 없는 아주 중요한 단계들이 있다. 이에 일부 예제가 될 만한 비즈니스 프로세스를 살펴봐, 관련 CRM 기능과 이행 방법을 설명하고자 한다.



승인 프로세스
관리와 문서 업데이트, 타임아웃, 승인, 단계적 확대, 위임 등이 수반되는 전통적으로 엄격한 워크플로우다. 이에 해당하는 예로는 주문 배치, 가격 산정, 신용 점검, 특별 계약 조건, 주문 이행, 고객 지원 확대, 가입 갱신 등을 들 수 있다. CRM의 경우, 판매 프로세스에서 주문 종료와 이행 영역에 대부분의 사례가 집중돼 있다.

이중 일부 비즈니스 프로세스는 여러 단계를 꼼꼼하게 관리해만 한다. 하지만 융통성이 필요한 상황도 있다. 융통성이 필요한 부분은 요청이 잦은 부분이 될 것이다. 한계점에 대한 관리 우선, '복제한' 비즈니스 프로세스 인스턴스의 취소 및 재개, 기록 해제 요청, 예외의 변경 등이다. 이런 변경 요청을 승인하느냐와는 상관 없이 기록이 필요하다. 애널리스트가 비즈니스 프로세스의 해당 영역에서 문제를 해결하도록 하기 위해서다. 이런 적법한 변경 요청이 과다하다면, 보다 정교한 (세부적인 하위 기준이 많은) 승인 프로세스가 필요하거나, 아예 다시 설계를 해야 할 수 있다.

워크플로우와 트리거 시퀀스(Trigger Sequences)
그러나 승인 프로세스가 너무 가혹해 진짜 문제가 발생하는 경우도 있다. 직렬로 함께 연결된 일련의 워크플로우나 트리거를 확보하는 것만으로도 한층 느슨하게 쌍을 이뤄 적정한 비즈니스 프로세스를 구현할 수 있을지도 모른다. (세일즈포스닷컴과 다른 CRM 시스템을 살펴보기 바란다. 워크플로우와 트리거가 동일 객체에 섞여 있어서는 안 된다. 레이스와 같은 상황이나 무한 루프를 초래할 수 있기 때문이다.)

정규 승인 프로세스를 대체하기 위해 일련의 워크플로우를 사용하면 명백히 특정 승인 단계가 지연된 경우에도 비즈니스 프로세스를 진행할 수 있는 일종의 우회가 가능하다. 이는 고객 지원과 서비스 프로세스에서 공통적으로 필요한 부분이다. 예를 들어, 교체 부품 주문과 관련된 비즈니스 프로세스에 출하에 앞서 신용 점검이 필요하다면, 워크플로우는 주문을 수집해 물류 센터의 신용 점검 대기 영역에 집어 넣은 후, 신용 점검이 완료된 경우에만 출하를 할 준비를 하도록 할 수 있다. 그리고 워크플로우에 이런 유연성을 더하면 승인이 지연되는 경우에도 주문 처리 속도를 빨리 할 수 있다.

이메일이나 업무 스레드
전통적인 워크플로우 시스템은 티켓이나 트랜잭션 문서, 또는 다른 형태의 업무 지정을 통해 업무 소유자 전반에 걸친 업무 흐름을 관리한다. 사용자가 업무를 마무리 지으면, 티켓/ 문서/ 업무 상태를 갱신하고, 다음 사람에게 업무를 이관하는 형태이다.

그러나 일부 비즈니스 프로세스, 특히 지식 종사자와 관련된 프로세스나, 테스팅/측정 주기 동안의 프로세스에서는, 사용자가 업무를 완료하기 전까지 다음 단계를 알 수 없는 때가 많다. '다음 티켓'을 사전에 한정할 수 있다면, 현재 작업자는 다음 작업자를 위해 구체적인 단계를 작성할 필요가 있다. 워크플로우 시스템은 이런 '다음 단계 작성' 업무를 사용자에게 지정할 수 있다. 사용자가 스스로 의미 있는 방식으로 업무를 지정하는 것이다. 또 종종 이메일을 통해 세부 내용을 알리곤 한다.

이런 이슈가 바뀌는 때는 업무 담당자가 시스템 접근 권한을 가지고 있지 않을 때다 (담당자가 로그인을 하지 않아서거나, 회사가 CRM 라이선싱 비용을 아끼기 위해서).  즉 사용자가 시스템 내부에서 업무를 수령하거나 갱신하기가 불편하기 때문에, 사용자에게 다음 업무를 통보하는 더 나은 방법으로 이메일이 쓰이는 경우가 많다.

이런 상황이라면, 워크플로우 시스템은 마감시한을 관리하고, 이메일을 상기시켜주는 메커니즘이나 '누가 책임을 맡았는지' 추적하는 매트릭스 이상으로 활용되어야만 한다. 어찌됐든 동시에 발생하는 활동이 있거나 재 업무가 요구되는 비즈니스 프로세스라면(예, 굴착이나 인증 시험 통과) 엄격한 워크플로우 시스템이 적합할 것이다.
 

상태 시퀀스
비즈니스 프로세스는 너무나도 많다. 특히 판매 주기의 초기나 고객이 관여하는 프로세스일수록 그렇다. 따라서 순서 별 단계를 정확히 알기란 불가능하다. 최악의 경우, 분명한 상태를 나타내주는 지표 대신 진척 상태를 모호하게 설명하는 가이드라인을 갖는데 그칠 것이다. 단계가 순서대로 발생하지 않을 수 있다. 동시에 일어날 수도, 통제 범위를 벗어날 수도 있다. 이 경우, 전통적인 워크플로우는 지나칠 위험이 있다. 따라서 정말로 알아야 할 부분은 '업무가 어디에 있는지에 대한 스스로의 믿음'이다.

이와 관련된 전형적인 예로는 마케팅의 잠재고객 확보와 판매의 관찰/수요 분석 단계를 들 수 있다. 어떤 CRM 시스템에서든, 이는 사용자가 최선으로 판단해 수동으로 진척시키는 상태 항목으로 표시된다. 어느 때나 특정 잠재 고객을 프로세스의 앞, 또는 뒤로 이동시킬 수 있다. 따라서 각 상태의 의미에는 논쟁의 여지가 많을 수 있다. 결정적이고 효율적인 시스템이라고 보기는 힘들다. 하지만 현실을 반영한다 할 수 있다.

이런 프로세스들이 장기간 지속되면(예, 9개월간의 판매주기, 9주간의 고객 탑재), 실제 워크플로우를 가질 수 없다 하더라도 워크플로우 개념을 활용할 필요가 있다. 특히 다음을 지켜야 한다:

• 활동 마감 시한
•'각 단계에서 머무는 시간'을 분석하고 너무 길어질 경우 이에 대한 경보
• 활동 침체에 대한 대한 경보 (예, 시간을 초과한 거래, 진행하다 중단 또는 되돌아가기, 가치 하락)
• 업무 파이프라인을 설명하는 보고서, 특히 '트레이닝 과정 만료'나 '분기별 11주 이후 출장 금지' 같은 병목에 집중

우리는 적용할 수 있는 일관된 규칙과 순서, 일정이 있는 비즈니스 프로세스를 선호한다. 하지만 현실은 그렇지 못한 활동들로 가득 차 있다. 만약 할 수 있다면, 모든 것을 비즈니스 프로세스로 특성화 해야 한다. 최소한 모델을 가질 수 있기 때문이다. 그러나 적합한 수준의 워크플로우 원칙을 적용해야 한다. 사용자(또는 고객)들이 지나친 집행으로 정신을 못 차리는 상황에 빠지는 것을 막기 위해서다.

* David Taber는 프렌티스홀 북이 발간한 ‘세일즈포스닷컴의 성공 비밀’을 쓴 저자이자 세일즈포스닷컴의 인증을 받은 컨설팅 기업 세일로직스의 CEO다. ciokr@idg.co.kr