가이드 가이드: 한 기업이 ERP 를 구현하기로 결정할 때 첫 번째 문제는 "누가 ERP 프로젝트를 이끌어야 하는가" 입니다.
이 문제를 논의하기 전에,' 누가 ERP 프로젝트를 주도할 것인가' 라는 문제가 누가 결정해야 하는가입니다. 이것은 이상한 이미지이지만, 국내 많은 기업들이 확실히 발생했다. 기업이 ERP 에 오르기로 결정했을 때 사장, 사장의 업무 부서, 각급 부서, 직원들은 모두 "ERP 가 중요하니 반드시 ERP 에 올라가야 한다" 고 입을 모았다. 그런 다음 사라지고 혼란스러운 국면에 들어가기 시작했다. "누가 ERP 프로젝트를 이끌어야 할지" 는 것은 말할 것도 없고 아는 사람이 있을지도 모르지만, 그는 핵심 이해 관계자가 아니기 때문에 침묵을 지켰다. 이에 따라 회사가 ERP 에 대한 진도 요구를 보장하기 위해 프로젝트가 시작되었지만 명확한 주도자가 없어 각 부처가 참여를 제한하는 경우가 많다. 그 이유는 참여하지 않아 비판을 받는 것이 아니라, 진정한 홍보 방면에서 각 부문이 전폭적으로 홍보하지 못했기 때문이다. 이것은 끔찍한 상황이다. 결국, 최종 프로젝트가 무력하거나 실패하여 구타를 당할 사람이 필요할 때, 진정한 책임 있는 부서는 도망갈 수 없다. (윌리엄 셰익스피어, 햄릿, 실패명언)
사실 이 문제도 간단하다. ERP 에 오르기로 결정한 사람은' 누가 ERP 프로젝트를 주도할 것인가' 라는 문제를 해결해야 한다. 따라서 ERP 에 가기로 결정한 사람들은 ERP 의 주도 부서를 분명히 해야 한다. 그렇지 않으면 ERP 프로젝트가 성공하지 못할 것이다.
좋아, 우리는 마침내 본론으로 들어갈 수 있게 되었다. 어떤 부서가 ERP 프로젝트를 이끌어야 합니까? 나는 다른 사람들이 이 문제에 대해 서로 다른 답을 가지고 있다고 믿는다. 모든 답은 정확하고 합리적이다. 주류 관점은 다음과 같습니다.
1. 재무는 기업의 명맥이고, 모든 사업부는 재무를 위한 것이며, 각 업무의 마지막 부분은 재무이기 때문에 재무를 위주로 해야 합니다. 대부분의 회사의 재무 부문은 지위가 높고 발언권이 있다.
2. 생산형 기업의 경우 생산부문을 위주로 해야 한다. 생산부문의 수가 회사의 절대다수를 차지하고 안정적인 생산이 회사의 생존의 근본이기 때문이다. 정보화는 생산을 보장해야 하고, 생산이 보장되면, 재정 이윤이 자연히 온다.
3. 대부분의 기업은 정보 부문을 위주로 하고 있다. 왜냐하면 사람들의 상식에 따르면 ERP 는 정보 시스템이고, 정보 시스템의 구현은 물론 정보 부문을 위주로 하고 있기 때문이다. ......
여러 가지 상황이 있지만, 각 상황마다 기업마다 성공 사례와 실패 사례가 있다. 그게 무슨 뜻이에요? 개인적으로 ERP 를 주도하는 부문을 실제로 판단하는 기준은 위와 같지 않다고 생각합니다. 개인은 어떤 부서가 ERP 를 주도해야 하는지를 판단하는 기준은 다음과 같다고 생각한다.
1. 야망이 있는 부서는 ERP 프로젝트를 이끌어야 합니다.
2.ERP 프로젝트는 발언권이 있는 부서가 주도해야 합니다.
이 두 가지만 가능합니다. 그 이유는 다음과 같습니다.
1. 야망이 있는 부서는 ERP 프로젝트를 이끌어야 한다.
일부 기업의 정보 부서에서는 "ERP 는 비즈니스 시스템이므로 비즈니스 부서가 주도해야 한다" 는 말을 자주 듣습니다. 왜 우리 정보부에서 지도해야 합니까? 우리는 사업을 이해하지 못한다. " 당신은 또한 몇몇 기업의 업무 부문과 비슷한 불평을 들을 수 있을 것이다. "ERP 는 정보 시스템이며 정보 부서가 주도해야 합니다. 우리는 단지 회사의 여러 업무 부서 중 하나일 뿐이다. 어떻게 하면 다른 부서를 잘 관리할 수 있습니까? 사장은 어떻게 생각해야 할지 모르겠다. " 이런 말을 들을 때마다,' 나는 싫다' 라는 말과' 너희 부서의 지위가 줄곧 낮았던 것도 당연하다' 는 말이 머릿속에 떠오른다. 만약 기업이 ERP 건설의 임무를 한 부서에 맡긴다면, 사실상 각 부문을 조율할 수 있는 권한을 이 부서에 넘겨주는 것을 의미한다 (ERP 건설과 관련된 조정권은 의미가 풍부하며, 너도 알다시피), ERP 구현도 마찬가지다. 이것은 기회이지 부담이 아니다. 나도 한 기업의 정보 부서를 거쳐 정보화를 실시하여 기업 프로세스 최적화에 참여하여' 프로세스 최적화 및 정보 관리부' 로 이름을 바꾼 적이 있다.
그래서 ERP 는 사업심이 있는 부서에서 실시해야 한다. 회사가 이미 그에게 권력을 주었기 때문에 나머지는 그가 무엇을 하고 싶은지 아닌지에 달려 있다. 진보부문의 기회이자 책임 부문을 떠넘기는 무거운 부담이다.
2. ERP 프로젝트를 이끌 수 있는 발언권이 있는 부서가 있어야 한다.
이 주도 부문은 반드시 발언권이 있어야 한다. 일부 기업은 정보 부서에 ERP 를 넘겨주고 결국 실패하는 것은 정보 부서가 업무를 이해하지 못하기 때문이 아니라 (정말 이해하지 못하지만 근본 원인은 아니다), 정보 부서와 상급 지도자가 회사에서 충분한 발언권이 없기 때문에 하고 싶은 일은 다른 부서의 강력한 지지를 받지 못했기 때문이다. 일부 기업의 ERP 는 강력한 정보화 지도자나 정보화 부서를 이끄는 부사장 (또는 사장) 의 발언권이 매우 크기 때문에 정보화 부문의 지도하에 매우 성공적이었습니다.
이 두 가지 요인만 있으면 고위층이 ERP 의 주도 부서를 결정하는 데 도움을 줄 수 있다. 부서장과 업무를 이해하지 못하는 것은 상관없다. 정말 상관없지만, 프로젝트 관리와 업무를 아는 사람이 프로젝트 매니저가 되어 프로젝트를 총괄적으로 관리해야 한다.
부록: ERP 프로젝트, 깊이 생각해야 멀리 갈 수 있어!
ERP 프로젝트에서는 프로젝트 구현을 위한 사전 예방 조치를 취하기 위해 프로젝트 관리 및 구현자가 프로젝트 추진 프로세스의 다음 단계에서 예측하고, 발전 추세를 파악하며, 프로젝트의 주도권을 파악해야 합니다. 여기에 여러분들이 토론할 수 있는 몇 가지 건의가 있습니다. 모두에게 유용하기를 바랍니다.
첫째, 각 프로젝트 단계의 공통성 문제를 고려해야 한다.
프로젝트 진행에 따라 ERP 프로젝트는 프로젝트, 요구 사항 조사, 비즈니스 프로세스 리엔지니어링, 시뮬레이션 실행, 병렬 실행, 정식 온라인 등 여러 단계로 나눌 수 있습니다. 사실, 서로 다른 기업은 각각 특성이 있지만 몇 가지 공통적 인 문제가 있습니다. 경험 많은 프로젝트 관리자는 각 단계의 일반적인 문제에 대해 깊은 이해를 가지고 있습니다. 이때 그들은 이러한 문제들에 대한 대책을 미리 취할 수 있다. 문제가 실제로 발생할 때까지 기다렸다가 해결하는 대신. 각 단계의 공통성 문제를 파악하는 것이 ERP 프로젝트 준비의 최우선 과제입니다.
비즈니스 프로세스 리엔지니어링을 예로 들면 다음과 같은 문제가 발생할 수 있습니다.
1. 기업은 자신의 프로세스에 대해 지나치게 자신한다.
외부 참조 부족으로 인해 사용자는 자신이 채택한 프로세스가 합리적이라고 생각하며, 시스템 보안이 자체 프로세스를 따르고 비즈니스 프로세스 리엔지니어링을 거부해야 합니다. 구현 컨설턴트는 이 장애를 어떻게 처리해야 합니까? 저자는 구현 컨설턴트가 현재 기업에서 사용 중인 비즈니스 프로세스를 시스템의 표준 프로세스와 비교하고 기업의 기존 비즈니스 프로세스를 계속 사용할 경우 이러한 위험이 발생할 수 있음을 사용자에게 설명해야 한다고 생각합니다. 사용자가 시스템의 표준 프로세스에 따라 할 수 있도록 일방적으로 강조하는 것이 아니라 구체적인 데이터로 말한다. 기업 관리자도 ERP 시스템을 이용하여 기업의 기존 관리 수준을 높였다. 기존 비즈니스 프로세스의 취약점을 진정으로 인식할 수 있다면 새로운 프로세스를 기꺼이 받아들일 수 있을 것입니다.
새로운 프로세스에는 수용에서 친숙에 이르는 과정이 필요합니다.
기업은 ERP 시스템의 새로운 프로세스를 사용한 후 익숙하지 않은 등의 이유로 실수를 하기 쉽다. 구현 컨설턴트가 이 문제를 인식할 수 있다면 몇 가지 예방 조치를 취할 수 있다. 예를 들어, 시뮬레이션이 실행될 때 새로운 프로세스가 용도에 맞게 설계됩니다. 사용자가 몇 번 더 연습하고 새로운 프로세스에 익숙해지도록 합니다. 후속 병렬 작업에서는 프로젝트 관리자에게 이러한 새로운 프로세스를 추적하도록 지시하여 사용자가 새로운 프로세스 작업을 따르고 오래된 병이 재발하지 않도록 감독합니다.
사용자에게 원래 관리 시스템을 변경하도록 상기시킵니다.
일반적으로 기업은 ERP 프로젝트에 앞서 전체 업무 프로세스 문서를 가지고 있습니다. ERP 프로젝트를 구현할 때 기존 프로세스를 새로 조정한 경우 읽기, 쓰기, 일관성을 위해 기존 비즈니스 프로세스 문서를 적시에 조정해야 합니다. 후속 훈련에 갈등이 생기지 않도록.
위에서 언급한 내용은 모두 업무 재편이 잘못되기 쉬운 곳이다. 프로젝트 관리자가 이러한 내용을 인식할 수 있는 한, 프로젝트 구현에서 예방 조치를 취하여 이런 일이 발생하지 않도록 할 수 있습니다. 현재 많은 ERP 소프트웨어 공급업체들이 표준화 구현의 구호를 제시하고 있다. 사실, 그것의 핵심 내용은 각 고리가 무엇을 해야 하는지를 서면으로 규정하는 것이다. 내가 말한 이 생각은 저자와 일치한다.
둘째, 사용자와 통신할 때 오해가 있을 수 있습니다.
문화적 배경의 차이로 인해 사람들은 교류에서 종종 오해를 일으킨다. A 가 한 말, B 는 또 다른 의미인 것 같다. 일상생활에서도 이런 상황이 흔하다. 이 상황에 대해 구현 컨설턴트 또는 프로젝트 관리자는 어떤 예방 조치를 취해야 합니까? 필자는 다음과 같은 조치를 취할 수 있다고 생각한다.
1, 가능한 한 많은 보조 증거를 가져오세요.
예를 들어, 수요 조사 과정에서 사용자는 다양한 보고 요구 사항을 제시합니다. 만약 당신이 사용자와 집행상담사의 노트에만 의존한다면, 당신은 완전히 기억하지 못하거나, 사용자의 말에 애매할 수 있습니다. 이럴 때는 증거를 더 받아야 한다. 만약 사용자가 이미 기성 보고서를 가지고 있다면, 그들에게 한 부를 요구할 수 있다. 그렇지 않은 경우 사용자가 먼저 Excel 테이블에서 디자인한 다음 저희에게 맡기도록 할 수 있습니다. 때때로 사용자가 한 시간 동안 말을 하면 입이 목이 마르다. 한 장의 표로 문제를 설명하는 것이 낫다.
2. 말을 한 후 사용자가 다시 확인하게 합니다.
사용자 요구 사항을 수집할 때, 같은 문제에 대해서도 누구나 자신의 요구를 제기한다. 그러나 갈등이 있을 수도 있고, 어떤 내용은 고려하지 않을 수도 있다. 작가는 수요 조사를 할 때 사용자의 요구를 상세히 기록하고 정리한다. 그런 다음 사용자가 서명하여 확인하도록 합니다.
사용자가 서명할 때 자신이 한 말을 한 번 정리한다. 어떤 부정확함도 제때에 바로잡을 수 있고, 어떤 모호함도 다시 확인할 수 있다. 이는 감사 프로세스와 같습니다. 이러한 확인을 통해 커뮤니케이션의 오해를 어느 정도 제거하고 구현 컨설턴트에게 사용자의 실제 의도를 알릴 수 있습니다.