상세 컨텐츠

본문 제목

[외산]JD Edwards - 제약 전문 ERP

ERP(전사적자원관리)/ERP이야기

by steve vai 2010. 7. 13. 06:08

본문


어느 회사의 사례이네요.

본인의 생각은 그럴수도 있을 것이고 그렇지 않을 수도 있다고 생각을 합니다.
다만, 이런 경우를 잘 유념해야지 도입을 하는데 후회가 없을 것이라 확신합니다.

문제는 여러 선한 ERP 업체를 이와같은 경우라고 생각을하기에는 문제가 있을 수 있기는 하겠지만 ...
이런 경우는 거의 없다고 보면 될 것 입니다.

늘 말씀 드리지만 외산 ERP의 문제일 수 있다는 생각에 포스트해 봅니다.

문제점은 제 생각이 아니고 해당 링크에서 직접 확인을 해고 시길 ...
그 포스트를 기반으로 생각을 덧붙인 형식이고 언급된 문제점은 본인의 의견이 아님을 재차 발혀둡니다.

JD Edwards의 문제점(원문 링크)

1. 형편없는 UI: ActiveX, RIA, AJAX 등의 지원 없이 인터넷 게시판 수준의 HTML 그리드 사용으로
   리얼타임에 정렬, 컬럼(셀) 크기 수정, 컬럼 위치 변경등 불가하여 현업 및 임원의 원성을 듣게 된다.

: ERP 기능의 핵심은 Grid이라고 누구도 부인을 할 수 없는 것이다.
  ERP의 DB설계 및 컨설턴트의 능력뿐 아니라 UX(사용자 경험)이 부족하다면 ... 입력을 하고 조회하고 보고서를 위한 근거자료를 만드는데 어려움이 있다면 50%가 부족한 것일 것이다.

2. 느려터진 속도: DBMS에 Query를 직접 전달 할 수 없는 구조로 되어 있어 총계를 내기 위하여
   Client PC에서 SUM = SUB + 값 과 같이 라인의 합을 직접 계산해야 한다. 2세대 코볼 프로그래밍에 가깝다.
   다량의 자료 조회시 엄청나게 느린 속도가 나온다.

: 근래 들어서 들은 이야기 인데 Best Practice도 중요하지만 Custom Pratice라는 말도 중요하다고 들었다. 이 말은 고객에게 가치를 주어야 하는 것이 편의성이 아니라 업종의 특수성이라는 이야기를 대변하는 것이다. 컨설턴트의 욕심중 하나는 빨리 프로젝트를 끝내는 것 ... 그게 비중이 높아지면 업체가 느끼는 것은 마음의 불편함일 것이다.


3. 64비트 미지원: 때가 어느 때인데 32비트 서버만 지원한다.

: 32bit라도 DB 설계가 잘 되어 있다면 저런 문제가 없을 것이다. 하지만, 제약 업종은 대체로 거래량이 많기 때문이다. 하지만, 설계, 구조, 기반이 약하다면 64bit아니라 128bit라도 절대로 해결이 안 될 일이다. 하드웨어의 성장속도에 맞추어서 묻어서 갈려는 소프트웨어 개발의 페혜가 존재를 한다.
여기에서 중요한 한마디 "최적화" 이게 잘 되어 있지 않으면 ... 하드웨어가 아무리 좋아도 ... 전체 시스템은 절름발이가 되는 것이다. (아이폰의 예에서 잘 알 수 있다. 모 회사의 스마트폰은 아무리 스펙이 좋아도 운영체제가 최적화가 안 되어 있기 때문에 좋지 않은 것을 봐라.)


4. 국내 환경이 고려 되지 않은 회계: 국내 표준 제무재표 양식(제조원가명세서, 손익계산서등)을 지원하지 않는다.
   원가산정이 엄청 나게 어렵고 실무에서 쓰기에 부적절 하다.

: 기능이 잘 되어 있지 않다는 것 때문에 글로벌 스탠다드에 맞지않다는 이야기를 그대로 받으면 멍청한 사람들이다. 국내의 상황을 잘 이해도 못 하면서 국제화를 진행하자고 이야기하는 컨설턴트가 있다면 "골 아프니 그냥 쉽게 가자."는 이야기이니 잘 알아들어야 할 부분이다. 

5. 유지보수 어려움: 개발 툴의 제한으로 인하여 소스분석이 용이 하지 않다. 특정 변수를 Find로 찾을 방법이 없다.
   소스를 프린터해서 찾아야 한다. 또한 신규 및 수정한 프로그램을 운영 서버에 적용하기 까지 무수한 단계를 거쳐야 한다. 이를 지원 하기 위하여 가뜩이나 부족한 전산실 IT요원 수를 더 늘려야 된다.

: 개발의 역량까지 전달이 될 수 있는 ERP가 잘 맞을 것 이다.
설마 구축이 잘 된 ERP를 다시 건드릴려는 멍청한 사람은 없을 것이다.
Cobol 때처럼 소스를 프린트 한다는 것은 시대 착오적인 기반인 것으로 생각이 된다.
하지만, 설마하는 생각도 가지고 있다.

6. 시스템 구성요소의 복잡성: JAS서버, Deploy서버, ERP서버등 복잡한 구성요소를 가지고 있는데, 로딩 되는 서비스 순서에 민감하여 모든 서비스가 활성화 되어 있는데도 ERP 접속이 안되는 경우가 발생한다.
   또한 배포한 프로그램이 실시간으로 반영 되지 않는다. 얼마나 지나야 현업 사용가능한지는 알 수 없으며
   강제로 반영되게 하려면 별도의 과정을 또 거쳐야 하는 번거로움이 있다.

: 지금 세상이 어떤 세상인데 ... 실시간으로 업데이트 및 배포가 된 내용이 반여되는데 시간이 걸릴까? 설마.. 하는 생각이다.

7. 인쇄(프린터출력)의 복잡성: JDE는 모든 인쇄시 PDF로 1차 변환하여 이를 출력 해야 한다. PDF 전환까지의 과정이 너무 복잡하다. 또 PC 환경에 따라 인쇄가 아예 되지 않는 경우가 있다.

: PDF가 기본 프린트 방식이다.
생각되는 문제 
1. PDF의 유출이 문제이다.
   (파일은 어떤 형태로든 유출이 된다. 아니면 비용이 그만큼 많이 들 것이다.)
2. 사용자의 편의성에 문제가 생긴다.
3. 원래 출력을 많이 안하는 업체는 모르겠지만 증빙이 많이 필요한 유통 업체인 경우 혼선이 생길 수도 있을 것이다. (출력을 보관하는 부서와 PDF만 보관하는 부서 ...)

만약 JDE 도입을 고려하는 업체가 있다면 위 문제점들을 고려해야 할 것이다.

또한 컨설팅 및 개발업체의 선택이 매우 중요하다. JDE로 먹고사는 회사가 국내에 그렇게 많지 않기에 단순히

구축 레퍼런스 숫자만  보지 말고, 반드시 도입업체에 문의 하여 평가를 듣고 판단할 것을 제안한다.

시장에는 질이 좋지 않은 업체가 있다.
: 늘 드리는 말이지만 질이 좋지 않은 업체는 고객을 봉으로 알고 군림할려는 의도를 보인다.  
ERP는 계약하고 나면 "갑"과 "을"이 바뀌고 완료가 되고 나면 돈이 안되면 유지보수까지 할 참이면 노예가 된다. 사이즈가 크고 좋은 제품을 취급하는 업체보다는 적정하고 그래도 고객을 왕은 아니더라도 파트너라고 생각을 해주는 업체가 좋은 ERP 업체이다.
다시 한번 말씀 드리지만 "갑"은 "갑"이고 "을"은 "을" 입니다.
다만, "갑"이길 원한다면 적절한 가격을 지불하시는 것이 ...
하지만, "을"이 적절한 대가를 받았음에도 불구하고 컨설팅을 한다는 입장에서 대장질까지 할려고 한다면 그리고 결과를 못 내어 놓는다면 ... 그건 별로 좋지 않은 일인 것 같습니다. 

A Dream Of...
A Dream Of... by The Pack 저작자 표시비영리변경 금지

(위 내용은 JDE 8.12 웹버전 기준이며, 자사 구축경험 범위 내에서 기술 한 것임. 타사는 다를 수 있슴)

관련글 더보기