AS-IS 분석
AS-IS 분석이란 현재의 업무 프로세스를 분석하는 것을 말한다. 이는 크게 3가지로 나누어지는데 첫 번째가 AS-IS 프로세스 목록 작성이고, 두 번째가 AS-IS 프로세스 체계도 작성 그리고 세 번째가 AS-IS 프로세스 정의서를 작성하는 일련의 작업이 수반이 되어진다. 첫 번째의 AS-IS 프로세스 목록작성이란 업무를 대분류, 중분류, 세분류, 프로세스 설명 등을 엑셀 등을 이용하여 목록을 작성하는 것이고, 두 번째의 AS-IS 프로세스 체계도 작성이란 업무가 어떤 체계의 구조를 가지고 있는지에 대하여 계층구조 형태로 업무를 분류하는 작업믈 말하여, 세 번째의 AS-IS 프로세스 정의서란 업무의 흐름에 대하여 Flow Chart 형태로 업무를 정의하는 작업이다.
AS-IS 분석은 앞에서 얘기한 부서의 Needs 분석 자료를 가지로 AS-IS와 Needs간의 Gap 분석을 통하여 구현하고자하는 ERP의 이슈들을 도출하는 자료가 된다. 또한 나중에 TO-BE 분석 자료를 가지고 AS-IS와 TO-BE간의 Gap 분석을 통하여 구현하고자 하는 전체적인 ERP 틀이 잡혀지기 때문에, 시간도 많이 들어가는 반면 아주 중요한 분석 자료가 된다. 이 AS-IS 분석은 컨설턴트들이 어떤 조언이나 방향을 얘기해 줄 수 있는 부분이 아니며, 단지 어떤 형태의 틀로 위의 3가지를 작성해야 하는지에 대해서만 알려준다.
실질적으로 AS-IS 분석은 PI들이 많은 노력과 시간을 보내는 부분 중에 하나다. 그리고 컨설턴트들이 프로젝트를 추진하는 업체를 판단하는 자료가 되기 때문에, 어떤 부분에 대해서는 PI들이 컨설턴트들에게 조언을 해주어 우리 회사의 프로젝트가 성공적으로 구축될 수 있도록 유도해야하는 부분도 있다. 그리고 AS-IS 분석을 잘 해 놓으면 나중에 구현하고자하는 분석인 TO-BE 분석을 하는데 큰 어려움 없이 TO-BE 분석을 할 수 있다. 그러므로 시간이 많이 든다고 하여도 프로젝트를 추진하는 업체의 PI들이 공을 많이 들여 만들어야 하는 것이다. 의료원의 PI들은 7월말에 SAP 모듈별 교육 일정이 잡혀져 있어서 늦은 시간까지 AS-IS 분석을 해야만 했다.
나의 경우는 AS-IS 분석을 하면서 과연 CO(관리회계) 모듈을 통해서 의료원에서 요구하는 예산부분을 구현할 수 있는지 궁금했다. 의료원의 특수성인 대학회계 부분과 병원회계 부분에 대하여 나의 느낌은 병원회계는 몰라도 대학회계 부분은 CO 모듈을 통해서 예산부분을 구현할 수 없다고 생각이 되었다. 이는 대학회계의 경우는 예산통제가 절대적으로 필요한 부분이라 CO에서 구현하는데 무리가 있다는 판단이었다.
그래서 CO 모듈 컨설턴트에게 대학회계의 예산관리는 FM(Fund Management) 모듈을 사용하겠다는 의사를 밝혔다. 그리고 컨설턴트도 대학예산의 특수성이 있기 때문에 CO 모듈보다는 FM 모듈이 적합할 것이라는 의견을 주었다. 또한 병원회계에 대해서도 SAP에서 CO 교육을 받아본 후 예산관리를 CO 모듈을 사용할지 FM 모듈을 사용할지 결정하겠다는 의사를 밝혔다. 그리고 컨설턴트 회사인 L사의 ERP 팀장으로부터도 예산관리를 하는데 있어 CO 모듈을 사용하던, 아니면 FM 모듈을 사용하던 문제가 되지 않는다는 답변을 얻었다. CO 모듈을 사용하여 예산관리를 하고자 하는 경우 USER EXIT를 통하여 예산통제가 가능하고, FM 모듈을 사용하면 FM 모듈자체가 예산관리 모듈이기 때문에 문제가 되지 않는다는 답변이었다.
내가 왜 예산관리에 대하여 CO 모듈을 사용할지 FM 모듈을 사용할지에 대하여 칸설턴트에게 한 얘기를 서술하는가는 나중에 이것이 컨설턴트와 L사의 ERP 팀장과의 마찰의 원인이 되고, 추후 얘기를 서술할 것이기 때문이다.
TO-BE 분석
TO-BE 분석이란 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 분석에서 중요한 것은 각 모듈별로 TO-BE 프로세스를 작성을 하였으면 통합 프로세스에 대하여 설계해야 한다는 것이다. 의료원 프로젝트팀에서는 통합 프로세스 설계에 대한 논의가 많이 있었다. 특히 대학회계 EPR를 추진할 때 참여하였던 PI 중심으로 전체 의료원 업무에 대한 통합 프로세스를 작성해야 한다는 주장이 많았다. 이는 대학회계에서 발생되었던 문제가 의료원 전체 EPR를 구현하면서 다시 발생되지 않도록 하자는 배경과 함께, 전체적 밑그림을 알아야 PI들이 TO-BE 프로세스를 올바로 정의하여 ERP를 좀더 완벽하게 구현할 수 있으리라 믿었기 때문이다. 하지만 우리 의료원은 통합 TO-BE 프로세스에 대한 논의가 있었지만 이는 단지 몇몇의 얘기로 끝나고 말았다. 내가 시간이 흘러 지금까지 안타까워하는 것이 바로 이부분이다. 그 때 통합 프로세스에 대하여 모든 모듈 PI들이 모여서 정의했었다면 멋있는 작품이 탄생하지 않았을까 하는 안타까움이 남는 부분이다.
ERP 프로젝트를 구현하고자 하는 분들에게 여기서 한마디 조언을 해 드리고 싶다. 내용은 무슨 일이 있더라도 각 모듈별로 TO-BE 프로세스 분석이 끝났으면 꼭 통합 프로세스에 대한 정의를 각 모듈 PI들이 모두 모인 가운데 밤을 새워서라도 꼭 설계하라는 것이다. 내가 속해 있는 의료원에서도 못했는데 왜 참견 하냐는 말을 한다면 할 말이 없다. 하지만 이것은 아주 중요한 것이다. 프로젝트를 어떻게 구현하는가에 대한 가장 초보적 단계이자 타 모듈에 대한 입장을 청취할 수 있는 기회이면서, 그리고 데이터가 어떻게 내 모듈로 들어와서 어디로 가고 나중에 어떻게 되는지를 알 수 있기 때문이다. 이런 데이터의 흐름을 파악한 상태에서 TO-BE를 설계한다면 자연스럽게 BPR이 되는 것이고, 프로젝트를 구현하는데 있어서 타 모듈 PI가 왜 저런 주장을 하는지 이해를 할 수가 있다. 그럼으로 자연스럽게 커뮤니케이션에도 자기주장보다는 서로의 업무 개선을 위해 조언을 할 수 있는 밑바탕이 된다.
내가 예산관련 부분에 대하여 TO-BE 프로세스에 대하여 분석하고 정의한 것은 SAP CO 교육을 마치고 또한 CO 컨설턴트 자격을 취득한 이후에 하게 되었다. 이 때 나는 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 설계를 완성할 수 있었다.
출처 : http://blog.empas.com/kimppa0/12023139
출처 : http://blog.empas.com/kimppa0/12023139
'공부방 > 개발관련&IT용어.. 등등;' 카테고리의 다른 글
| [기타] 국가별 통화코드 (0) | 2015.04.08 |
|---|---|
| [공통] ASCII Code표 (0) | 2013.11.25 |
| [일반] 말콤 글래드웰의 스파게티 소스에 관해서.. (0) | 2010.08.24 |
| [분석] USECASE (0) | 2010.02.23 |
| [개발] 프로트타이핑(ProtoTyping) (0) | 2010.02.22 |