TO-BE 분석이란 AS-IS 분석과 비슷한데,
AS-IS분석이 현재의 업무 프로세스를 분석하는 것을 의미하다면,
AS-IS분석이 현재의 업무 프로세스를 분석하는 것을 의미하다면,
TO-BE 분석이란 미래에 구현하고자하는 업무 프로세스를 정의하는 분석이다.
TO-BE 분석도 크게 3가지로 나누어지는데
첫번째가 TO-BE 프로세스 목록 작성이고,
두번째가 TO-BE 프로세스 체계도 작성 그리고
세번째가 TO-BE 프로세스 정의서를 작성하는 일련의 작업이다.
첫번째의 TO-BE 프로세스 목록 작성이란
SAP의 ERP에서 업무를 1레벨, 2레벨 등으로 레벨별로 구분하여 세부업무에 대한 레벨은 하위 레벨로 정하여 최하위 레벨과 SAP의 T-CODE(트랜잭션코드)를 매칭하는 작업을 하는 것이고,
두번째의 TO-BE 프로세스 체계도 작성이란 SAP 기준으로 업무가 어떤 체계의 구조를 가지고 있는지에 대하여 계층구조 형태로 업무를 분류하는 작업을 말하여,
세번째의 TO-BE 프로세스 정의서란 SAP 기준으로 업무의 흐름에 대하여 Flow Chart 형태로 업무를 정의하는 작업이다.
TO-BE 분석도 크게 3가지로 나누어지는데
첫번째가 TO-BE 프로세스 목록 작성이고,
두번째가 TO-BE 프로세스 체계도 작성 그리고
세번째가 TO-BE 프로세스 정의서를 작성하는 일련의 작업이다.
첫번째의 TO-BE 프로세스 목록 작성이란
SAP의 ERP에서 업무를 1레벨, 2레벨 등으로 레벨별로 구분하여 세부업무에 대한 레벨은 하위 레벨로 정하여 최하위 레벨과 SAP의 T-CODE(트랜잭션코드)를 매칭하는 작업을 하는 것이고,
두번째의 TO-BE 프로세스 체계도 작성이란 SAP 기준으로 업무가 어떤 체계의 구조를 가지고 있는지에 대하여 계층구조 형태로 업무를 분류하는 작업을 말하여,
세번째의 TO-BE 프로세스 정의서란 SAP 기준으로 업무의 흐름에 대하여 Flow Chart 형태로 업무를 정의하는 작업이다.
TO-BE 분석에서 중요한 것은 각 모듈별로 TO-BE 프로세스를 작성을 하였으면 통합 프로세스에 대하여 설계해야 한다는 것이다. 의료원 프로젝트팀에서는 통합 프로세스 설계에 대한 논의가 많이 있었다.
특히 대학회계 EPR를 추진할 때 참여하였던 PI 중심으로 전체 의료원 업무에 대한 통합 프로세스를 작성해야 한다는 주장이 많았다. 이는 대학회계에서 발생되었던 문제가 의료원 전체 EPR를 구현하면서 다시 발생되지 않도록 하자는 배경과 함께, 전체적 밑그림을 알아야 PI들이 TO-BE 프로세스를 올바로 정의하여 ERP를 좀더 완벽하게 구현할 수 있으리라 믿었기 때문이다.
하지만 우리 의료원은 통합 TO-BE 프로세스에 대한 논의가 있었지만 이는 단지 몇몇의 얘기로 끝나고 말았다.
내가 시간이 흘러 지금까지 안타까워하는 것이 바로 이부분이다. 그 때 통합 프로세스에 대하여 모든 모듈 PI들이 모여서 정의했었다면 멋있는 작품이 탄생하지 않았을까 하는 안타까움이 남는 부분이다.
특히 대학회계 EPR를 추진할 때 참여하였던 PI 중심으로 전체 의료원 업무에 대한 통합 프로세스를 작성해야 한다는 주장이 많았다. 이는 대학회계에서 발생되었던 문제가 의료원 전체 EPR를 구현하면서 다시 발생되지 않도록 하자는 배경과 함께, 전체적 밑그림을 알아야 PI들이 TO-BE 프로세스를 올바로 정의하여 ERP를 좀더 완벽하게 구현할 수 있으리라 믿었기 때문이다.
하지만 우리 의료원은 통합 TO-BE 프로세스에 대한 논의가 있었지만 이는 단지 몇몇의 얘기로 끝나고 말았다.
내가 시간이 흘러 지금까지 안타까워하는 것이 바로 이부분이다. 그 때 통합 프로세스에 대하여 모든 모듈 PI들이 모여서 정의했었다면 멋있는 작품이 탄생하지 않았을까 하는 안타까움이 남는 부분이다.
ERP 프로젝트를 구현하고자 하는 분들에게 여기서 한마디 조언을 해 드리고 싶다. 내용은 무슨 일이 있더라도 각 모듈별로 TO-BE 프로세스 분석이 끝났으면 꼭 통합 프로세스에 대한 정의를 각 모듈 PI들이 모두 모인 가운데 밤을 새워서라도 꼭 설계하라는 것이다.
내가 속해 있는 의료원에서도 못했는데 왜 참견 하냐는 말을 한다면 할 말이 없다. 하지만 이것은 아주 중요한 것이다. 프로젝트를 어떻게 구현하는가에 대한 가장 초보적 단계이자 타 모듈에 대한 입장을 청취할 수 있는 기회이면서, 그리고 데이터가 어떻게 내 모듈로 들어와서 어디로 가고 나중에 어떻게 되는지를 알 수 있기 때문이다. 이런 데이터의 흐름을 파악한 상태에서 TO-BE를 설계한다면 자연스럽게 BPR이 되는 것이고, 프로젝트를 구현하는데 있어서 타 모듈 PI가 왜 저런 주장을 하는지 이해를 할 수가 있다.
그럼으로 자연스럽게 커뮤니케이션에도 자기주장보다는 서로의 업무 개선을 위해 조언을 할 수 있는 밑바탕이 된다.
내가 속해 있는 의료원에서도 못했는데 왜 참견 하냐는 말을 한다면 할 말이 없다. 하지만 이것은 아주 중요한 것이다. 프로젝트를 어떻게 구현하는가에 대한 가장 초보적 단계이자 타 모듈에 대한 입장을 청취할 수 있는 기회이면서, 그리고 데이터가 어떻게 내 모듈로 들어와서 어디로 가고 나중에 어떻게 되는지를 알 수 있기 때문이다. 이런 데이터의 흐름을 파악한 상태에서 TO-BE를 설계한다면 자연스럽게 BPR이 되는 것이고, 프로젝트를 구현하는데 있어서 타 모듈 PI가 왜 저런 주장을 하는지 이해를 할 수가 있다.
그럼으로 자연스럽게 커뮤니케이션에도 자기주장보다는 서로의 업무 개선을 위해 조언을 할 수 있는 밑바탕이 된다.
내가 예산관련 부분에 대하여 TO-BE 프로세스에 대하여 분석하고 정의한 것은 SAP CO 교육을 마치고 또한 CO 컨설턴트 자격을 취득한 이후에 하게 되었다.
이 때 나는 CO(관리회계) 모듈을 이용하여 예산관리를 하는 것보다 FM(예산관리) 모듈을 이용하는 대학회계와 병원회계를 모두 구현하는 것이 의료원에서 요구하는 방법에 적합하다는 결론을 내렸다. 이는 FM 모듈에서는 각각의 상태(STATUS)에 대한 예산집행 관리가 가능하지만 CO에서는 최종 FI(재무회계)에서 처리한 데이터만 받기 때문에 프로세스 차원에서의 예산관리가 힘들다는 결론을 내렸다. 그리고 이는 아마도 내가 대학회계에서 FM 모듈을 사용하였던 경험이 있었기 때문에 모듈간 비교를 통한 장단점을 비교하여 FM모듈을 예산관리 모듈로 선택할 수 있었다고 생각되어진다.
이 때 나는 CO(관리회계) 모듈을 이용하여 예산관리를 하는 것보다 FM(예산관리) 모듈을 이용하는 대학회계와 병원회계를 모두 구현하는 것이 의료원에서 요구하는 방법에 적합하다는 결론을 내렸다. 이는 FM 모듈에서는 각각의 상태(STATUS)에 대한 예산집행 관리가 가능하지만 CO에서는 최종 FI(재무회계)에서 처리한 데이터만 받기 때문에 프로세스 차원에서의 예산관리가 힘들다는 결론을 내렸다. 그리고 이는 아마도 내가 대학회계에서 FM 모듈을 사용하였던 경험이 있었기 때문에 모듈간 비교를 통한 장단점을 비교하여 FM모듈을 예산관리 모듈로 선택할 수 있었다고 생각되어진다.
앞에 서술한 AS-IS 분석에서 설명했듯이 여기서 나는 L사의 팀장 및 컨설턴트와 마찰을 빚게 된다. 내가 예산관리를 CO 모듈을 사용하지 않고, FM 모듈을 이용하여 구현하겠다고 얘기하면서 TO-BE 설계를 하자, FM 모듈을 사용하겠다고 의료원측에서 처음부터 얘기를 하지 않았기 때문에 FM 모듈에 대하여 L사는 지원해 줄 수 없다는 선언을 나에게 하였다. 나는 황당하기도 하고 예전에 나에게 했던 얘기와 완전히 틀리기도하여 마음이 많이 상한 상태에서 L사의 팀장과 설전을 벌려야한 했다. 결국 의료원측의 ERP 팀장과 L사의 컨설턴트의 의견을 조율한 결과 CO 모듈에서는 의료원에서 요구하는 방향으로 예산관리를 할 수 없으므로 FM 모듈을 이용하는 것이 좋을 것 같다는 결론이나 L사의 팀장이 추후 FM 모듈에 대한 컨설턴트 지원을 약속하여 나는 TO-BE 설계를 완성할 수 있었다.
출처 : 블로그 (확인되는데로 올리도록 하겠습니다.)
