ERP 설계의 벽, 어떻게해야 넘을 수 있을까
어떻게해야 ERP 설계를 잘 할 수 있을까에 대한 생각정리
1.
제안서를 쓰기 전에는, 기술적으로 구현이 가능한지 검토를 해야하는 경우가 있다. 그 과정에서 서비스 설계 난이도를 파악하고, 그 핵심을 내가 꿰뚫어볼 수 있는지를 체크하는 편이다. 기획 작업을 한지도 10년이 다 되어가지만, 여전히 쉽지않은 것들 중 하나가 ERP 플랫폼이나. 내부인원부터 시작해서, 업무에 대한 결재, 업무에 들어가는 자재와 서비스 단가, 업무진행에 따른 내부 / 외부업체 정산까지. 실제로 여러 전문적인 지점을 다루게 되기 때문에, '어렵다'는 지점을 자꾸만 생각하게 된다. 물론, ERP 설계는 기획자라면 언젠가 한번쯤 넘어보고싶어지는 커다란 과제들 중 하나다. 실제 ERP 설계 경험을 갖고있는 사람은, 연봉이 4~5천은 거뜬히 넘는다고 보면 된다. 그만큼 난이도가 있는 작업물이고, 그만한 작업기술을 '인정받을만한' 업무이기도 하다.
대부분의 업체는 각자 사용하는 문서규격이나, 실제 업무처리 프로세스가 다르다. 그래서 일반적인 ERP 그룹웨어 등으로는 처리가 되지 않는 경우가 생긴다. 이런 이유에서 자체적인 ERP 플랫폼을 만들게된다. 업체마다 설계 수준이 다르기 때문에, ERP가 무조건 어렵다고 말하긴 어렵다. 다만 내가 이번에 보게된 내용은 인사관리부터 결재관리, 업무 프로세스별 정산까지 포함된 기본 ERP에 가까웠다. 이 서비스를 만들 수 있을 것인가에 대한 지점은, 어떻게든 해결할 수 있을 것이다. 다만 '완성도가 높은 수준'으로 완성시킬 수 있을 것인지가 문제였다. 다른 그룹웨어를 쓰지 못해서, 어쩔 수 없이 쓰는 수준에서 만드는게 아니라. 커스텀한 ERP를 만든 만큼, 상대가 만족할 수 있을만한 수준을제작할 수 있을지. 그 지점이 문제였다.
제안서를 쓰면서도 계속해서 스스로 의문이 들었다. 이걸 작업하려면 뭘 분석해야하나, 어떤 것들을 봐야하나. 실제 레퍼런스 자료가 될만한게 뭐가있나. 그 고민들 끝에 써내려간 제안서는, 그렇게까지 만족스럽지 못했다. 실제 제안작업이 끝나는 순간에도, 내가 이 내용을 제대로 쓴 것이 맞는지. 다른 지점에서 더 고려해야할 지점은 없는지. 스스로 선택한 단어와 문장에 대한 의문들이 가득했다. 다른 사람들도 어떻게든 해내고 있는 거겠지. 자신의 수준에 대해서 의문을 가지면서도, '무엇이 더 나은 방향인지' 고민한 결과가 완성본으로 나온거겠지. 그런 자기합리화에 가까운 생각을 하면서 제안서 자료를 한참동안 뒤적이고있었다. 그러다가 엄청난 괴물을, ERP의 끝판왕을 하나 만나버렸다.
2.
요양기관 업무관리 프로그램. ERP이지만 동시에 의료, 요양기관에서 사용하는 특수기능이 포함된 건이었다. 나는 이 서비스들을 찾아보고나서야 내 한계가 어느정도인지 확실히 깨달았다. 이건 도저히 설계할 자신이 없다는 생각이 먼저 들었기 때문이다. 물론 화면에 펼쳐진 너무 많은 정보에 질려버린 것도 있었지만, 익숙치 않은 의료정보들을 끌어안고 1~2개월 안에 이 모든걸 해낼 자신이 없었다. 기술적으로 구현하기가 어려워서가 아니라, 너무 복잡한 내용들이 많아서 기술검토를 중단하는 일은 거의 없었다. 다만 의료업계나, 요양이라는 특수 분야로 들어가기 시작하면서, 구현난이도가 더 올라갔다는걸 깨닫게됐다.
복합적인 전문 ERP 서비스의 DB 구조를 까보면 대충 이런 모양이 된다일단 뒤로 물러나서, 무엇이 문제인가를 생각해보게됐다. 실제 ERP 레벨로 들어가게되면, 이미 UI설계는 DB설계와 비슷한 수준의 작업이 된다. 그만큼 다뤄야할 정보가 많고, 서로 겹치는 정보들을 여러 단계에 걸쳐서 사용하기 때문이다. 각 사용자 타입마다 갖고있는 정보들을 묶어주고, 서로 겹치는 지점을 확인하다보면 어떻게든 실마리는 나오게될 터였다. 다만 일반적인 서비스 레벨이 아니라, 개인별 근무내역 관리나 내부 운영 회계같은 것들이 들어가기 시작하면 복잡도는 상상을 초월하게된다. 어떤 사람이 무슨 일을 언제부터, 어디까지 했는지. 근무표는 또 어떻고 그것에 대한 정산기준을 어떻게 잡아야하는지. 또 추가근무나 개별 소모품을 사용하는 경우, 내부 재고와 추가재고 입출입에 따른 기록까지 연결시켜줘야한다.
이렇다보니 데이터 테이블들을 정리하다보면 사실상 'DB 스키마'를 그리는 꼴이 되어버리고, 한 곳에서 틀린 로직이 생기면 다른 곳에서 연달아 문제가 발생하게된다. 이런 지점이 ERP 같은 복잡한 프로그램에서는 굉장히 큰 이슈가 된다. 그래서 대부분의 경우 ERP 서비스는 한 명의 기획자가 아니라 2~3명 정도 되는 기획자들이 협업을 해서 만드는 경우가 많다. 그만큼 페이지 수가 많고, 각 데이터가 연결되는 지점들이 많기 때문이다. 심지어 실제 구축시에는 해당 업체에서 기존에 이용중이던 엑셀 문서규격이나, 자체 일지같은 것들의 특성을 반영해야한다. 그러니 문서 하나에서 끝나는 것이 아니라, 각 문서가 갖고있는 모든 정보들을 '실로 꿰어서' - 어떤 것들이 연결되고. 어떤 것들을 자동입력 처리해줄 수 있는지를 파악해줘야한다.
- 문서에서 반복되는 정보는, 한번만 입력하면 자동입력처리되도록 처리
- 문서에서 새로 입력되어야하는 개별 정보는, 단계별로 정리할 수 있도록 템플릿을 제공
- 문서 외부에서 가져올 수 있는 정보는, 특정 액션으로 자동으로 끌어오도록 처리
해야할 일만 생각하면 사실 '양'이 많을 뿐인데. 항상 복합 ERP만 보면 머리가 아파온다. 실제로 이런 작업을, 신입 기획자와 함께 해낼 수 있을지 생각해보니, 뾰족한 답이 나오질 않았다. 결국 내가 선택한 건 '현재 상황에서 구현이 불가능하다'라는 판단이었다.
3.
사실 과거에도 ERP에 대한 지점은 자주 '생각은 했지만, 부딛히기가 어려운' 것들 중 하나였다. 가장 큰 이유는 분석에 드는 시간이 너무 오래걸린다는 점. 그리고 일반적인 상황에선 만들 이유가 없다는 부분이었다. 하지만 정작 내가 팀장급의 업무를 맡게 되면서부터, 그 '어려워서 피했던 것들'을 해내야하는 상황이 되었다. 오히려 그걸 정리해서, 상대가 알기 쉬울 정도로 '설득해줘야' 제안이 성공한다는 거니까. 어찌보면 피할수도 없는 상황이 되어버렸다고 해야할까. 과거에는 피하고싶었던 악몽같은 것들이 눈앞에 다가온 그런 느낌이었다.
차라리 B2B 커머스나 정산 쪽은 단계가 복잡해도 단계라도 명쾌하지. ERP는 그룹마저도 사용자가 직접 만들 수 있어야하고, 결재 라인도 커스텀하게 설정이 가능해야한다. 각 사람이 '어떤 역할'을 해야할지는 정해져있지만, 그 과정을 다시 별도의 관리자가 세팅해야한다는 것. 그리고 그걸 '언제라도 바꿀 수 있어야한다는 점'이 가장 골때리는 지점이었다. 이런 설계적 복잡성 때문에, 왠만한 유료 그룹웨어들도 완성도가 높은 것들을 찾아보기가 어렵다. 그래서 대부분의 대기업들이나, 특수 업종들은 자체적인 그룹웨어를 커스텀하게 만드는 경우가 많다. 자신들의 업무 상황에 맞도록, 옷을 맞추듯 맞춤형 설계를 하는건데. 문제는 내가 그걸 충분히 '이해하고있는지'였다.
실제 대부분의 클라이언트들은 - 자신의 업무에 대해서 '얼마나 제대로 이해하고있는지'를 궁금해한다. 심지어 문제해결책을 그들에게 설명을 해주거나, 더 나은 아이디어를 찾아내주길 원한다. 그런 일이 가능하려면 당연히 ERP를 여럿 분석하고 설계해봤어야 아는건데. 일반적으로 ERP를 '여러개 만들어본 사람'들은 찾기가 힘들다. 그만큼 고급 설계 플랫폼이고, 난이도가 어려워서 그렇다. 그렇다면 결국 이런 지점도 '별도로 공부를 해서 처리를 해야' 경험이 생긴다는 건데. 일반적인 ERP는 내부전용으로 닫혀있는 지점이 많아 매뉴얼 등의 자료를 찾기도 쉽지않다. 그러니 일반적인 문제해결 방법을 찾기가 힘들고, 해결책을 아는 전문가는 적은 상황이 발생하는 것이다.
-
그래서 일단 제안서를 쓰는 레벨에서는 작업을 중단하고, 자료를 좀더 찾아보기로했다. 가능하면 데모화면을 회원가입 없이 확인할 수 있는 동영상이나, 데모 시연 페이지들을 찾기 시작헀다. 그중에 별도 처리없이 바로 기능을 확인할 수 있는 내용들은 링크로 남겨두겠다. 당장은 이 부분이 어떻게 처리될지 잘 모르겠지만, 일단 자료를 좀 더 찾아보면서 단계를 깎아나가는 쪽으로 진행해봐야겠다.
https://www.hiworks.com/cs/demo_done
http://gw5.krinfra.co.kr/checkusr_renew.asp
