첫째, 프로젝트 관리자의 역할을 진정으로 이해합니다.
프로젝트 관리자 역할에 대한 이해는 두 가지 극단을 피해야 한다. 하나는 프로젝트 관리자의 기술 역량을 지나치게 강조하는 것으로, 프로젝트 관리자는 팀에서 가장 숙련 된 사람이어야 하며, 프로젝트 구현의 어려운 문제는 결국 프로젝트 관리자가 수집하고, 프로젝트 관리자는 "예" 또는 "아니오" 라고 말해야 합니다. 그렇지 않으면 설득되지 않습니다. 프로젝트 관리자의 리더십을 지나치게 강조하는 또 다른 방법은 프로젝트 관리자의 최우선 과제가 팀 구성원에게 커피를 가져다주고 관계를 조율하는 것이라고 생각합니다. 프로젝트 관리자는 먼저 유사한 프로젝트 구현 경험을 갖고 ERP 프로젝트에 대한 명확한 인식과 업계 관련 지식에 대한 탄탄한 기반을 가져야 한다고 생각합니다. Dell 은 이 ERP 프로젝트를 위한 과학적이고 실용적인 구현 방안을 마련할 수 있으며, 필요한 경우 팀 구성원이 문제를 해결할 수 있도록 도울 수 있지만, 프로젝트 관리자가 어떠한 기술적 문제도 반드시 잘 알고 있어야 한다는 의미는 아닙니다. 예를 들어, 프로젝트 네트워크 아키텍처의 경우 프로젝트 관리자는 관련 전문가에게 문의할 수 있습니다. 그러나 프로젝트 관리자는 프로젝트의 모든 기술에 대해 잘 알고 이해해야 프로젝트를 완벽하게 파악할 수 있습니다. 둘째, 프로젝트 관리자는 조직력을 조율하고 전체 프로젝트 팀의 분위기를 조절할 수 있어야 하며, 좌절이 닥쳤을 때' 온난화' 하고, 지나치게 낙관적일 때' 냉각' 할 수 있어야 한다. 동시에 프로젝트 단위와 소통하고 조율할 수 있는 능력이 있어야 하며, 팀 구성원의 프로젝트 구현을 위한 환경을 준비해야 합니다. 중점적이거나 어려운 문제에 부딪히면 다양한 채널을 통해 답을 찾을 수 있다.
프로젝트 관리자는 일반 직업 관리자와 다릅니다. 그것은 매우 전문적인 전문성을 가지고 있다. 기술을 모르는 사람은 영원히 프로젝트 매니저가 될 수 없다. 프로젝트 관리자는 기술과 관리의 조합이어야 한다.
둘째, 프로젝트 팀의 관리를 중시하고 상벌이 분명하다.
ERP 프로젝트의 구현에서는 실행 가능한 프로젝트 관리 시스템, 특히 다중 프로젝트 팀을 구축해야 합니다. 그래야만 전체 프로젝트의 질서 있는 시행을 보장할 수 있다. 표준화되고 실행 가능한 프로젝트 관리 시스템은 기업과 프로젝트에 따라 달라야 합니다. 일반적으로 프로젝트 관리 원칙, 기업/업계 특성, 프로젝트 규모/성격, 기업 개발 문화/품질 등 다양한 요소의 복합물이어야 합니다. 동시에 제도를 엄격히 집행하여 상벌 제때, 명확해야 한다. 제도 건설은 두 가지 상황을 피해야 한다. 하나는 프로젝트 관리 제도가 없고, 프로젝트 관리는 개인적인 경험만으로 실시된다. 둘째, 선비제도는 교조를 그대로 따르고, 종이에 병사를 이야기하고, 고각을 묶는다.
프로젝트 관리의 핵심은' 삼각 균형' 이다. 즉 사양, 비용, 진도의 세 가지 측면에서 균형을 유지하는 것이다. 대부분의 프로젝트 구현에서는 프로젝트 비용의 지표, 평가 및 통제를 수립하고 실현할 수 없는 경우가 많습니다. 자금의 통제권은 종종 프로젝트 관리자가 소유하지 않는 경우가 많습니다. 그러나 회사에서 결정하면 회사와 프로젝트 관리자 간의 책임이 불분명해지고 일부 제도가 구현되지 않으며 프로젝트 관리자 책임제는 잘 실현되지 않습니다.
조화로운 팀을 형성하기 위해서는 프로젝트 관리자가 인센티브, 코치, 인센티브, 평화 유지자 및 충돌 중재자 역할을 해야 합니다.
게다가, 프로젝트 매니저는 다른 직위의 예비 인재 양성에도 주의를 기울여야 한다. 프로젝트 구현 과정에서 팀 구성원이 사임하면 프로젝트 관리자는 인력 이동 및 교체를 합리적으로 배정할 수 있습니다. 동시에 게이머들이 업무 과정에서 경쟁을 형성하고 주기적인 휴가를 합리적으로 배정할 수 있도록 한다.
셋째, 계획, 계획, 계획
거의 모든 사람들이 프로젝트 시행을 위해서는 계획을 세워야 한다는 것을 알고 있다. 그러나 구체적인 운영 과정에는 여전히 다음과 같은 현상이 남아 있다. 첫째, 프로젝트 계획의 제정이 엄격하지 않고, 임의성과 조작성이 약하며, 구현 중에는 따를 수 없고 (예: 프로젝트 계획이 너무 거칠고, 집행력이 부족한 경우), 임무, 진도, 자원이 구현되지 않는다. 둘째, 전체 프로젝트는 상세한 프로젝트 계획이 부족하고, 심지어 주간 프로젝트 계획 방식을 채택하여 매주 다음 주 작업 계획을 수립합니다. 그 본질은' 프로젝트가 통제불능의 합법화' 이다. 셋째, 프로젝트 진도에 대한 검사 (진도와 비교) 와 통제가 부족하여 프로젝트 계획의 진지함을 유지할 수 없다.
아무리 완벽한 계획도 자주 사고를 당하지만, 우리가 계획을 세울 필요가 없다는 뜻은 아니다. 만약 계획이 없다면, 우리는 참조를 잃게 될 것이다. 프로젝트 관리자는 변화를 예측하고 변화에 적응할 수 있어야 합니다. "만약-그럼" 이라는 가정을 자주 하고, 프로젝트의 현재 상황에 대해 자만하지 말고, 프로젝트가 변경될 때 제때에 조정해야 한다. 계획은 항상 변하고 있고 계획은 빨리 변하지 않는다. 관건은 계획이 변화를 따라잡을 수 있다는 것이다.
프로젝트 구현 과정에서 전체 프로젝트는 여러 개의 작은 프로젝트로 나뉘어지는 경우가 많으며, 프로젝트 관리자는 시간을 효율적으로 활용하고, 프로젝트 간의 효과적이고 합리적인 연계를 보장하고, 전반적인 계획의 합리성과 일관성을 유지해야 합니다.
프로젝트 계획의 두께는 세심한 균형이 필요한 문제이다. 세칙에 대한 통제가 클수록 프로젝트 관리 비용이 높아진다. 또는 반대로 달라스에서 대강당까지 국내 현황과 내 개인적인 의견에 따르면 3 개월 이하의 프로젝트는 평일, 최소 2 ~ 3 일 근무일로 세분화해야 한다. 6 개월 이상 지속되는 프로젝트는 적어도 일주일이 걸린다.
넷째, "제 1 책임자공사" 를 진정으로 이해하다
ERP 프로젝트를 실시하는 것이 최우선 과제로 여겨지고 있다. 많은 프로젝트는 시행 초기에' 1 인자공사' 를 강조하는데, 예를 들면 사장이 회의를 열고, 프로젝트팀을 설립하는 등 잘 쓰인다. 그러나 종종 시행이 시작된 후, 그들은' 1 인자공사' 의 역할을 잘 발휘하지 못하여 1 인자공사를 포기하는 공사가 되었다. 프로젝트 관리자는 처음부터 끝까지' 리더' 역할을 해야 하며, 정기적으로 (보통 한 달) 또는 소규모 프로젝트가 끝날 때' 리더' 에게 단계 요약을 제출하고' 리더' 에 대한 의견을 듣고 필요한 경우' 리더' 회의를 제안해야 한다. 동시에 프로젝트 관리자가 있는 회사의 "리더" 도 지원, 이해 및 자원 할당을 위해 정기적으로 보고하고 전달해야 합니다.
5. 훈련에 쓰는 시간을 인색하게 하지 마라. 두세 번의 훈련도 지나치지 않다.
교육은 프로젝트 구현의 중요한 부분입니다. 현재 국내 단위 (특히 대형 공기업 단위) 인력의 자질이 상대적으로 낮아 정보화에 대한 이해가 거의 제로다. 따라서 우리는 교육 과정에서 단계적으로 교육을 진행해야 하며, 한 번의 교육으로 부서의 인원이 소프트웨어 운영을 이해하고 파악할 수 있을 것으로 기대해서는 안 된다. (윌리엄 셰익스피어, 윈스턴, 공부명언) 교육은 프로젝트 전체에 걸쳐 진행되어야 하며, 사용자에게 적합한 운영 매뉴얼을 작성하려면 필요한 경우 단위 내부 웹 페이지에 "FAQ" 열을 만들어야 합니다. "고객이 너무 느리고 어리석다, 알아듣지 못했다, 내가 그를 도왔다" 는 생각과 행동을 피해야 한다. ERP 프로젝트는 우리 회사의 프로젝트이므로 누구도 대체할 수 없다.
여섯째, 프로토 타입 테스트를 수행하고 이론과 실천에서 실행 가능한 구현 계획을 수립합니다.
훈련이든 계획이든 실행 가능한 실시 방안에 세워야 한다. 그렇지 않으면 너의 방법이 아무리 좋아도 좋은 효과를 얻을 수 없다. 따라서 구현 전에 우리는 충분한 시스템 분석과 조사를 실시하고, 모든 계층의 사람들의 의견을 충분히 듣고, 다양한 출처의 데이터를 수집하고, 다각적인 프로토타입 테스트를 진행해야 합니다. 프로젝트 그룹 (ERP 단위 포함) 이 동의한 후에만 구현 및 교육 계획을 개발하고 실행할 수 있습니다. 구현 과정에서 프로그램 변경이 발생하지 않도록 합니다.
일곱째, 합리적으로 고객 수요를 줄입니다.
어떤 소프트웨어도 만능이 아니며, 고객의 모든 문제를 100% 해결할 수 없다. 프로젝트 구현 과정에서, 실사구시, 사용자에게 소프트웨어가 무엇을 할 수 없다는 것을 분명하게 알려야 한다. 일부 소프트웨어 회사와 구현자들은 사용자에게 진실을 알리고 싶지 않거나 감히 말하지 않고, 원래의 정확한 비즈니스 프로세스를 회사 소프트웨어가 규정한 비즈니스 프로세스로 바꾸고 싶어 양측이 교착 상태에 빠지고 있다. (윌리엄 셰익스피어, 윈스턴, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어) 특히 일부 소프트웨어 프로그램의 결함은 사용자의 비난을 받아들이기를 꺼린다. 사실 이것은 전혀 필요하지 않다. 불가능한 문제에 있어서 사용자와 빙빙 돌면, 사용자들이 너를 오해하고 회사를 신뢰하지 못하게 할 뿐이다.
여러 가지 이유로, 기업 경영에는 항상 자신의 특징을 지닌 것들이 있다. 그러나 기업들은 단기간에 기존 방식을 바꾸기가 어렵기 때문에 소프트웨어의 유연성과 실현의 유연성이 필요하다. 물론 기업의 행동을 가능한 한 관련 법과 관례에 맞게 하는 것이 가장 좋은 결과다.
고객의 요구를 처리할 때도 80/20 원칙에 주의해야 하며, 맹목적으로 고객의 요구를 낮춰서는 안 된다. 소프트웨어가 어떻게 고객의 80% 의 수요도 충족시킬 수 없는지 생각해 보십시오. 어떻게 고객이 자신의 수요를 포기하도록 요구할 수 있습니까? Dell 은 고객의 수요를 합리적으로 줄이는 것이 고객의 80% 이상을 해결하거나, 고객의 특수한 요구를 미리 충족시키거나 해결하는 것이 아니라 기업의 주요 요구를 해결하는 것이라고 말합니다. 프로젝트 구현 과정에서 Dell 은 모든 고객의 요구를 해결하겠다고 약속할 수 없습니다. 하나의 소프트웨어로 모든 고객의 요구를 해결할 수 있다면, Dell 의 구현은 힘들이지 않고, 그렇게 많은 구현 방법을 강조할 필요도 없고, ERP 를 구현하는 기업도 컨설팅할 필요가 없습니다.
이상은 단지 여러 방면에서 프로젝트 매니저에 대한 나의 이해를 묘사했을 뿐이다. 물론, 프로젝트 구현 과정에서 가장 중요한 것은 어떤 방법을 사용하든 구현의 성공이다. 프로젝트 관리자는 프로젝트 자체의 상황에 따라 프로젝트에 적합한 프로그램과 구현 전략을 결정해야 합니다.