관련글 모음프로그램 개발자 입장에서 ERP(Enterprise Resource Planning)나 CRM(Customer Relationship Management) 시스템을 이야기 하다보면 마치 거대한 산을 앞에 두고 있는 느낌이 있다. 가도 가도 나오지 않는 정상 처럼, 저 깊숙한 계곡에는 무엇이 있는지 알 수 없는 것처럼 다양한 업무 프로세스와 법규 그리고 다양한 기술이 녹아 있는 ERP/CRM 시스템을 산으로 느끼는 것은 어찌보면 당연하다 할 수 있을 것이다. 이번 글에서는 많은 비용과 위험을 수반하는 ERP도입을 공개 소프트웨어 기반으로 수행하는 것에 대해서 이야기 해볼까 한다. 최근의 ERP 패키지들은 내부에 재무/회계, 생산, 인사, 물류, 자산관리 뿐만아니라 CRM 기능을 통합하려는 경향이 있으므로 ERP/CRM으로 분리하지 않고 아래 에서는 그냥 ERP라 지칭할까 한다.
1. 왜 오픈 소스 ERP/CRM 인가?
2. 중소기업용 오픈소스 ERP Postbooks(xTuple)
3. 중소기업용 오픈소스 ERP Postbooks 설치하기
그런데, 왜 오픈 소스 ERP 인가?
ERP 패키지는 일정 규모 이상의 모든 기업에 꼭 필요한 필수적인 시스템이긴 하지만 동시에 각 기업별로 서로 다른 업무 형태를 가지고 있기 때문에 동일한 브랜드의 ERP 시스템을 도입하더라도 각 기업별로 조금씩의 차이를 갖는 특성이 있다. 그래서 아래의 그림처럼 ERP 적용 과정을 보면 현재와(As is) 나아갈 방향(To be) 또는 패키지와의 차이를 분석하는 Gap analysis 단계를 반드시 포함하게 된다.
ERP 시스템이 복잡하고 규모가 크다고 해서 패키지 형태의 ERP를 도입하는 방법만 있는 것은 아니다. 많은 경우 패키지를 구매하여 자신의 기업에 맞도록 조정하는 형태로 프로젝트가 진행되기도 하지만, 중소 기업의 경우에는 기업의 전산 담당자가 기업에 꼭 필요한 기능만을 직접 개발하는 경우도 있다. 그렇지만 두가지 접근 방법 모두 사용자가 무엇을 필요로 하는지, 기업에 꼭 필요한 기능은 무엇인지 찾는 작업이 상당히 어렵고, 설사 찾더라도 추후 조직의 변화와 시장 환경의 변화등에 따른 변경 요구, 고비용, 실패 위험, 사용자 불만족 등 개발 및 도입 위험성이 상당하다고 할 수 있다.
외산 ERP의 경우 국내 업무 환경에 잘 맞지 않거나 사용자의 변경 요구사항이 적절하게 수용되지 않는 등의 이유로 기존 투자 비용에도 불구하고 국산 ERP 패키지로 전환하는 사례가 있거나, 거꾸로 기업의 글로벌화가 진행됨에 따라 국내/국외지사의 통합 ERP 구축 과정에서 외산 ERP로 전환하는 사례도 있다. 자체 개발 ERP의 경우에도 당장 노출되는 필요(Needs) 기반으로 개발하다보니 시스템 전체적인 아키텍처의 안정성과 확장성에서 떨어지고 최신 기술이나 업무 프로세스 적용에서도 뒤쳐져 결국 상용 ERP 패키지를 도입하는 상황에 이르기도 한다.
상용 ERP를 구매하는 방법을 통해서 자체 개발의 위험성을 저감시키고, 최신 기술과 좋은 모델을 받아들이고 신속한 설치와 장기 유지보수 위험을 줄이는 효과도 있지만, 현실적으로 고비용으로 기업에 맞도록 커스터마이징 작업도 쉽지 않으며 사용자는 제품 공급 기업에 의존적인 상태에 빠질 수 밖에 없다. 또한 각 벤더들은 이상적인 프로세스를 기반으로 패키지를 개발하기 때문에 현실과는 괴리가 클 수 있고, 제품 내부의 기능을 파악하고 익숙해 지기 위해서는 비용 지불이 선행되어야만 하며, 변경 요인이 있을때 소스를 손댈 수 없다는 한계가 있다. 또한, 공급 업체가 지속적인 서비스를 제공하지 못하는 경우 고객이 리스크를 그대로 떠안을 수 밖에 없다.
이렇게 ERP 자체개발과 상용 제품 도입등에서 발생할 수 있는 여러가지 문제를 해결할 수 있는 대안이 바로 오픈 소스 ERP/CRM 솔루션이다.
사용자는 비용을 지불하지 않고 바로 코드를 확보하여 패키지에서 제공하는 기능들이 자신의 기업에 맞는지 확인해 볼 수 있으며, 만약 대부분의 기능이 자신의 기업에 맞다면 상용 제품 설치와 같이 빠른 설치가 가능할 것이며, 전혀 맞지 않다면 바로 포기해도 연관 위험성은 전혀 존재하지 않는다. 수정이 필요하다면 직접 필요한 기능들을 적용할 수 있으며 개발 커뮤니티를 통해 다양한 도움을 받을 수도 있다. 소스 코드가 있기 때문에 장기적인 지원 서비스 부재에 따르는 위험성도 줄일 수 있다.
오픈소스 ERP를 도입한다고 해도 위의 "ERP implementation life cycle" 과정은 거의 그대로 진행되야 한다고 보아야 하므로, 일단 외산 및 국산 상용 ERP가 무엇이 있는지 살펴보고, 추천할 만한 오픈소스 ERP에는 무엇이 있는지 찾아볼까 한다.
국산 ERP 솔루션
- K.System
영림원 소프트랩, http://www.ksystem.co.kr
출처 : 제품소개서 - 더존 iCUBE
더존, http://www.duzon.co.kr
출처 : 제품소개서
외산 ERP 솔루션
- SAP R/3
SAP AG, http://www.sap.com
출처 : brainart.eu - Oracle ERP
Oracle, http://www.oracle.com
출처 : innova.co.th
오픈소스 ERP 솔루션
- ERP5
http://www.erp5.com
Python-Zope기반의 ERP
- Apache OFBiz
http://ofbiz.apache.org
Java/Web 기반(윈도우에서 손쉽게 빌드 및 실행 확인 가능)
다양한 기능을 포함하고 있는 범용 ERP
- Opentaps
http://www.opentaps.org/
ERP, E-Commerce, CRM, SFA 기능들을 포함하고 있다.
Toyota, IBM 등 좋은 Reference(http://www.opentaps.org/about-opentaps/case-studies)
- Compiere
http://www.compiere.com/
공개 버전과 상용버전의 차이가 조금 있다.
- Xtuple(OpenMFG) postbooks
http://www.xtuple.com/, http://sourceforge.net/projects/postbooks/
주요 개발 환경 : Qt, C++, JavaScript, PostgreSQL
SF.net 배포용과 상용 버전을 구분해서 배포하고 있고 기능은 큰 차이 없음
DBMS가 내장된 형태로 윈도우 버전으로 배포하고 있어 사용해보기 용이하다.
오픈 소스 ERP 검토시 꼭 고려해야할 사항은 무엇일까?
- 사용자 규모, 예산 등 상용 ERP 도입시 검토하는 일반적인 사항에 대해서 추진 여부에 대한 냉철한 판단이 필요하다.
(ERP 도입은 IT 기술과 함께 업무 프로세스의 변경을 수반한다) - 오픈 소스 ERP가 만능이 아니다. 초기 구축 비용에는 큰 차이가 있지만, 유지보수에 투입되는 비용은 비숫할 수 있다.
- 현재(As-is)와 향후 방향(To-be) 사이의 차이 분석(gap analysis)을 통해 ERP 시스템에 바라는 Wish list 작성이 필요하다.
(구체적이고 명확한 사용자 요구 사항 추출은 ERP 패키지 선택에 있어 중요한 지렛대 역할을 한다) - 오픈 소스 ERP 패키지에 사용하고 있는 기술이 개발자 커뮤니티에서 충분한 사용자를 확보하고 있는 안정된 기술인가?.
- 오픈 소스 ER의 커뮤니티가 활동적이고 지속인 업데이트가 이루어지고 있는가?
- 설치 및 삭제가 간단하여, 기능 확인 및 사용자 반응을 살피는데 어렵지 않은가?
- 기능 추가 및 변경, 적용 과정이 복잡하지 않은가?
- 국산 오픈 소스 ERP가 전무하고 대부분 외산인 관계로 국내 실정과는 거리가 있는데 이 부분을 수용할 수 있나?
- 선택한 오픈 소스 ERP를 기반으로 우리 회사의 요구 사항을 반영할 수 있는 개발자 또는 개발 회사가 근처에 있는지?