회사에 ERP를 도입하려고 하는데 요즘은....
글쓴이: knbaram / 작성시간: 금, 2011/03/18 - 4:16오후
회사 인원 30명 정도 되는 작은 회사입니다.
연매출은 1천억 ~ 1천5백억 정도 되는데요..
회계는 단독 프로그램 사서 사용하고 있고, 예산, 고정자산, 인사 등등 엑셀로 이루어져 있어서
데이타가 쌓이다 보니 관리가 제대로 되지 않아서 ERP를 도입하려고 합니다.
저는 단순히 SI개발쪽으로만 생각하고 있었는데요
이리저리 업체들과 상담을 하다보니 요즘 ERP 개발은 사장 추세고 패캐지쪽을 도입해야 한다고 하네요.
개발을 하게 되면 시스템이 사람에게 맞추어야 하기 때문에 끝없이 말이 나오고 효율성도 떨어지지만
패캐지는 모든 작업 프로세스에 의해 효율적으로 관리 되므로 시스템에 사람을 맞추어야 한다고 그러네요.
그러면 처음에는 불편해도 업무효율은 올라갈 것이라고,,, (맞는 말인 것 같아요)
그래서 오라클JED나 SAP이나 더존 같은... 것들이 있다고 하는데
저희는 기본적인 경영관리 뿐만 아니라 여러가지 덧붙여야 할 시스템도 많거든요!
정형화되어 있는 경영쪽은 모듈을 사서 사용하고 나머지는 패캐지에서 제공하는 4GL툴을 이용하여 재개발 하는 형식으로..
이런 방법이 요즘 대세인가요?
지방이다 보니 다른 시스템을 구경할 장소가 마땅치 않네요.
Forums:
원래 업무용 프로그램은 그래야 정상인
원래 업무용 프로그램은 그래야 정상인 겁니다.
우리나라 사람들은 너무 SI 를 좋아해서 탈인거죠.
표준 시스템에 맞게 업무를 맞춰가야지, 기형적인 업무에 시스템을 맞춰간다는게 말이 안되잖아요.
표준 좋긴한데.......
깊이는 아니고 그냥 몇몇 구축하는 사이트 언저리에서 몇번 본적있습니다. 어차피 저희야 ERP 구축시 장비납품이니까...
ERP프로젝트..... 그냥 언저리 에서 보자면.
보통 도입하는 이유는 두가지 더군요.
. 상위 업체에서 쓰라고 해서 (발주시스템과 연동.. 명칭은 정확히 모르겠습니다...)
. 정보팀(혹은 전산팀)주도로 해서 사장님의 지시로.
첫번째는 그닥 활성화 되지 않고 그저 메일서버로의 기능에 충실하는 경우가 대부분이더군요.
어떻게 도입을 하건간에 실무들은 뭐 이래도 흥~ 저래도 흥~ 그닥 반발이 없더군요.
두번째는 구축때 회의 회의 회의 회의 회의 하더군요.
ERP 자체가 업무 종속적인 부분이 많고 실무는 이렇게 하면 좋겠는데 전산팀 혹은 관리팀 에서 바라보는 업무 프로세서는
또 완전히 다르니 중간중간 회의도 많고 의견도 조율 안돼고 가끔 언성을 높이는 경우도 있더군요.
이런 저런 상황이 맞물려서 오픈 일정도 늦춰지고 마지막에 UI테클 걸고 들어 오시는 분도 있고.
결국 오픈일은 늦어지고 "안정화는 오픈이후에 한다." 라는 그런 뭐 그렇더군요...
여튼 업무 프로세스를 모르고선 ERP도입은 고민해 봐야하며 특히 SI성은 도전하지 않아야 한다고 하더군요.
아 이말도 기억 나네요..
" 가장 말아 먹기 좋은 프로젝트중 하나가 ERP이다."
또 밀어야 하나 아니 이제 인생 자체를 밀어야 한다..... IT 관두는 젖비린내 SE (/ㅡ_-)/~
어떤게 더 적합한 지는 따져봐야 알겠죠.
업체에게 물어봤자 자기네 제품 팔려고 뜬구름 잡는식의 립서비스밖에 못합니다.
SI개발을 하든 ERP솔루션을 도입하든지 어떤 게 적합한지는 알기 위해서는 컨설팅이 수반되어야 합니다.
ERP 프로젝트를 하기 위해서는 구체적으로 왜? / 무엇을? /어떻게? /얼마나? 해야 되는지 계획이 필요한데..
그걸 알기 위해서 소위 ISP 내지 EA 라는 정보화 전략계획이 수립되어야 하구요.
질문내용중 전자인 SI개발(In-House)로 하면 업무프로세스 특성을 유연히 반영할 수 있는 장점이 있으나,
비용증대 및 계획/분석/설계/구현/적용 하는데 장기간이 소요됩니다.
후자로 ORALCE, SAP 벤더솔루션을 도입하는건데 이게 솔루션 도입한다고 바로 ERP가 실현되는게 아닙니다.
어떤 솔루션이든지 비슷합니다만 우선 업무프로세스가 표준화되어야 하고, 비지니스가 표준화되면 데이터가 표준화됩니다.
그 데이터로 DB를 구축하고 나서야 비로소 ERP 가 올라갈수 있는 겁니다.
이게 말이야 표준화 라고 쉽게 말하는 거지. 요구되는 것도 무려 글로벌 표준입니다.
당장 하던 업무프로세스를 바꿔야 하는게 절대 쉽지 않지요.
그리고 UI 가 무지 이질적이서 업무담당자들로부터 좋은 평을 받기 힘듭니다.
둘 중에 어떤 방식을 선택하든 간에 그 성공여부는 컨설턴트의 역량에 따라 크게 좌우된다는 점을 아셔야 됩니다.
----------------------------------------
Nothing left after Nirvana.
많이들 댓글 달아주시겠지만, ERP 도입하면서
많이들 댓글 달아주시겠지만, ERP 도입하면서 발생하는 몇가지 주의사항을 적어두겠습니다.
1. 관계를 명확히
-. 개발업체와의 관계를 명확히 하세요. 까딱하면 개발업체에 끌려다니면서 일은 일대로 못하고, 시도 때도 없이 불려다니면서 설명하고, 두어주쯤 있다가 개발자 바뀌면 또 설명하고, 또 두어주쯤 있다가 또 설명하고 ... 이럴 가능성이 높습니다. ERP 든 SI 든 기본적으로 개발자가 3,4 번 바뀐다는 가정하에서 시작하시는 게 좋습니다. 다른 말로 하면, 안 바뀔 가능성이 높은 업체를 선정하면 되겠습니다만, 아무리 비싼돈 주고 일을 맡겨도 그 업체가 다시 하청에, 재하청에 ... 쭉 내려가는 경우가 태반입니다. 계약서에 하청이 불가능하다고 명시하시고, 개발에 투입된 개발자는 개발 완료때까지는 다른 프로젝트에는 투입하지 못하도록 명시하시고, 계속 감시해야 합니다. 그렇게 하지 않으면 이 회사 와서 뭔가 하고 있는데, 알고 보면 그건 저쪽 회사 일을 해주고 있는 것일 수도 있습니다.
2. 보안은 철저히
-. 거래업체, 매출, 영업망, 직원, 프로젝트 현황, 개발 현황 등의 정보가 당연히 ERP 에 들어갑니다. 거꾸로 본다면, 개발 업체에서는 이만큼 좋은 소스가 없지요. 자료 못 빼가게 하세요. A 업체 ERP 구축해 주고, 그거 그대로 들고 나가서 B 업체 차리는 경우도 본 적 있습니다.
3. 개발 완료 시점 명확히
-. 끝이 좋아야 제대로 된 겁니다. 프로그램은 완성도 안돼서 뻑하면 다운 되고 자료 날아가는데, 계약서상의 날짜 됐다고 철수해버리는 경우도 있습니다. 보통은 액수가 좀 크기 때문에 보증보험에 가입하고 .. 그럽니다만, 그래 봐야 저렇게 날아가는 자료나 제대로 안 돌아가는 프로그램에 대한 것은 보험금 받기도 힘듭니다.
4. ERP 유저 입장에서 생각하게 하기
-. 개발자 입장에서 ERP 를 제작해서 정작 써야 하는 직원(컴퓨터는 문서 작성용 및 인터넷 용으로 아는 일반 사용자)들은 메뉴 하나 찾다가 퇴근 하는 경우도 있습니다. 특히 개발자나 UI 설계자의 모니터는 작을수록 좋습니다. 메뉴바를 만들었는데, X 축으로 황당한 해상도로 만들어서 한참 오른쪽으로 찾아가서 클릭하고 다시 돌아오고 ... 이런 경우가 비일비재 합니다. 적지 않은 회사들이 노트북을 사용하고, 노트북의 기본 해상도에 맞추어서 개발이 되어야 하는데, 디자이너나 개발자의 모니터는 24 인치.. 이래서 자기들 모니터에 맞춰서 개발하는 경우도 몇번 봤습니다.
5. 용어 통일
-. 이건 회사 내에서 일단 먼저 진행되어야 합니다. 같은 걸 서로 부르는 용어가 달라서 삽질하는 경우는 없어야겠죠 ?
6. 가장 확실한 ERP 는 엑셀
-. 이걸 꼭 명심하세요. ERP 에서 계산 된 거 꼭 엑셀에서 검산해 보세요. 만들고 나서 초기에는 분명히 오류가 뻥뻥 터지고, 6개월 ~ 1년은 잘 지켜봐야 합니다. 특히 돈 나가는 거 관련해서는 꼭 검산해 보세요.
몇가지 더 있는데.. 기억나는 게 여기까지군요...
ERP 주의사항 인가 뭔가로 검색해 보시면 10 여개쯤 나오는 게 있습니다.한번 꼭 읽어 보세요. ERP 도입하고 3개월 뒤에 다시 기존으로 돌아가는 회사들이 무지하게 많습니다.
---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도
즐겁게 놀아보자.
모두 옳은 말씀이십니다.. 하나 더 추가해보자면
갑 입장에서도 제대로된 담당자가 끝날때까지 붙어줘야합니다.
바쁘다고 다른일하고 그러면.. 솔루션이 제대로 완성되지를 않지요.
(물론 악필옹이 그러시다는말은 전혀 아니구요 :D)
갑이 사용할 프로그램입니다.
그리고 을을 일정으로 쪼을것만이 아니라
합리적인.. 예를들자면 스토리보드를 짜고.. 검토하는것도 갑이 같이 해주어야
나중에 삽질이 줄어듭니다.
이건 을을 위한것만이 아니라
결과물을 갑이 "쓸모있게" 사용하기 위한 방법중 하나지요.
나중에 만들어놓고 쓸모없어지는경우중에
반 이상은 갑이 돈만줬으니 알아서 되겠지..라는 생각을 가지고
프로젝트의 코드 또는 개발 진척도에만 초점을 맞춰서 그런경우를 많이 봤습니다.
(뭐 딱히 ERP만 해당되는 경우는 아니군요)
기간을 충분히 잡고
간단하게 UI와 Flow라도 검토하고 그 다음 단계로 갈 수 있는...
그런것들이 필요하다고 생각합니다.
-----새벽녘의 흡혈양파-----
당연히 담당자가 붙어야죠. 근데, 문제는 담당자는
당연히 담당자가 붙어야죠. 근데, 문제는 담당자는 있는데, 개발자들이 계속 바뀐다는 얘기죠. 그러니 했던 말 또 하고... 했던 말 또 하고.. 또 하고 또 하고 ... 완성은 커녕 깔리지도 않고...
사석에서 얘기한 적이 있었지만, DB 개발자라는 양반이 왔는데, RHEL 서버에 오라클도 못 깔아서 제가 대신 깔아준 적도 있고 뭐 그래요 -_-
---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도
즐겁게 놀아보자.
그런걸보고..
월급도둑이라고 하죠..
사실 PM뿐만 아니라 아래쪽 개발자들도 면담정도는 하고 사람을 투입해야하는게 아닐까...
SI하면서 생각을 좀 하게 되었었습니다.
-----새벽녘의 흡혈양파-----
1번 글을 보니 지난 날의 기억들이 떠오르네요.
1번 글을 보니 지난 날의 기억들이 떠오르네요. 하청업체 개발자들이 업무 현장에 가서 개발하고 있으면 입으로 먹고 사는 굴지의 대기업 그룹사 직원이 PM 이란 꼬리표를 달고 가끔 혹은 자주(프로젝트 초기일 때) 내려옵니다. 그런 사람들은 실제로 업무관리에는 참여하지 않고 수금을 목적으로 혹은 격려한답시고 찾아와서 하청업체 직원들이 은근 자신을 접대하도록 분위기를 만들어서 퇴폐업소로 가곤 하죠. 그러다보면 타 직장에서 이직해온 개발자들이 얼마 못버티고 다시 빠져나가게 됩니다. 이런 게 SI 개발자들이 자주 교체되는 원인입니다. 주제에서 조금 벗어났네요.
--
즐 Tux~
정확한 규모 설정이 가장 중요
회사 인원 30명에 연매출 1천억-1천5백억 정도이면 제조업체인 것 같지 않네요.
제조업체이면 생산 관련 부분은 분명 외주를 주시고 있을 것 같고요.
일단 귀사의 업종에 관련된 ERP 자료 찾아 보셔야 합니다.
30명 정도 인원이면 보통 재무, 총무, 전산, 구매, 생산, 자재, 영업, 연구소 등으로 나누어 본다면
각 부서에 인원이 최대 3명, 거기에 부서/팀장 한다면 실무자는 1-2명 정도 밖에는 되지 않을 것 같네요.
업종에 따라서 많이 달라질 수 있습니다.
Oracle, SAP를 사용하신다고 하면 일단 업무 프로세서 표준화(도입 시스템에 맞도록)부터 하셔야 하는데
가장 어려운 부분입니다.
우리나라는 회사 운영이 갑/을 형태에 따라서 도저히 표준화 할 수 없는 경우도 허다 합니다.
회계,예산,고정자산,인사 정도만 하신다면 굳이 대형사의 ERP를 사용하지 않으셔도 될 듯합니다.
영림원의 K시스템, 더존(기본 패키지 이외에 추가 작업) 도 괜찮을 것 같습니다.
위 업무 이외에 생산... 등 구축 하셔야 한다면 대형사의 ERP를 사용하셔도 되는데
인원이 너무 적으면 배보다 배꼽이 더 클수 있습니다.
Oracle, SAP 의 경우는 담당자 교육만 몇 주씩 하는 경우도 많이 있습니다.
담당자 1-2 명이 시스템 사용에 전부 매달려 있을 수도 없을 테니까니요
어떤 시스템을 사용하시던 현재 인원 구조와 잘 맞추어서 구성 하셔야 할 것 같네요.
개발사 등의 문제는 그 다음인 것 같네요.
고맙습니다.