둘째, 예산을 전부 계산하지 마라. 나는 예산을 잘 짜고 다른 사람에게 나의 예산을 알릴 때 항상 할인을 한다. 예를 들어, 우리 회사는 ERP 프로젝트를 구현 하 고, 다른 사람의 구현 컨설턴트가 내게 물었다, 우리 프로젝트의 예산은 무엇입니까? 나의 사전 예산에 따르면, 나는 소프트웨어 허가비가 60 만 원이라고 계획했기 때문에, 나는 그에게 우리 회사의 상술한 안배에 따라 소프트웨어 허가비 예산이 50 만 원이라고 말했다. 왜요 처음부터 자신의 기초를 누설하면 상대방이 즉석에서 입찰할 것이기 때문이다. 원래는 60 만 허가비만 필요했는데, 우리는 70 만 원을 말했다. 우리 다시 흥정하자. 즉, 많은 소프트웨어 회사들이 우리의 예산에 근거하여 가격을 제시한 것이다. 만약 우리의 예산이 높다면, 그들의 제시가격도 높을 것이다. 만약 우리의 예산이 낮다면, 그들의 초기 제시가격은 더 낮을 것이다. 따라서 예산을 통제할 때, 즉시 자신의 배경을 다른 사람에게 보여 주지 말고, 먼저 할인을 해야 나중에 필요한 일에서 선회할 수 있는 여지가 있다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 예산명언) 동시에, 내부 원가 예산에 대해 충분한 준비를 하지 마라. 예를 들어, 2 차 개발비 등 불확실성이 큰 예산을 세울 때는 어느 정도 여지를 남겨야 한다. 예를 들어, 사전 수요 조사를 통해 또는 소프트웨어 회사의 제안에 따르면 2 차 개발 비용은 일반적으로 소프트웨어 비용의 65,438+00%, 즉 60,000% 입니다. 그러나 2 차 개발 비용은 정확하게 산정하기 어렵기 때문에 이런 불확실한 비용을 고려할 때 계층을 구분해야 한다. 예를 들어, 이 2 차 개발 비용 예산을 고려할 때, 각각 3 만, 2 만, 1 만인 세 단계로 나뉜다. 2 차 개발비용이 3 만 이내라면, 기본적으로 만족할 수 있다. 그들이 요구하면, 소프트웨어 회사가 개발을 책임지도록 한다. 총 수가 30,000 을 넘으면 노란색 경보선에 도달하면 사용자의 2 차 개발 요구 사항을 다시 한 번 검토하여 2 차 개발이 필요한지 확인합니다. 만약 이미 5 만 명이 넘었다면, 바로 나의 빨간 경계선이다. 이때 사장급 승인이 없거나 상담사가 강력 추천 사건의 발전을 하지 않으면 더 이상 그들의 요구를 받아들이지 않을 것이다. 이 컨트롤에는 두 가지 장점이 있습니다. 첫째, 기업 사용자는 자신의 요구를 충족시키기 위해 적극적으로 문제를 고려하고 시스템을 이해합니다. 그래야만 가장 빠른 속도로 수요를 제출할 수 있고, 2 차 개발을 채택할 확률이 훨씬 높기 때문입니다. 이것은 또한 보이지 않게 ERP 프로젝트의 진도를 촉진할 수 있다. 둘째, 그들이 모두 자발적으로 수요를 제시할 때, 나는 처음부터 가능한 한 많은 2 차 개발 수요를 파악할 수 있어, 내가 통일적으로 안배하는 데 도움이 된다. 동시에 일회성 개발에 대한 수요가 더 많고, 서로 흥정할 여지가 있어 큰 할인이 훨씬 클 것이다. 그러므로, 우리는 당연히 이런 다목적 일을 기꺼이 할 것이다. 셋째, 프로젝트 요구 사항 변경에 대해서는 통제를 강화해야 한다. 사실, 내가 아는 한, 기업 정보화 프로젝트 예산의 초과 지출의 상당 부분은 프로젝트 수요의 변화에 있다. 관련 통계에 따르면 프로젝트 수요 변경으로 인한 비용은 프로젝트 총 지출의 약 20% 를 차지하며 이는 적지 않은 지출임을 알 수 있다. 프로젝트 수요 변경의 손실을 조금 줄일 수 있다면, 과다한 프로젝트 지원 문제를 줄일 수 있을 것이다. 따라서 프로젝트 예산 통제의 관건은 프로젝트 수요 변화의 통제에 있다. 그러나 대부분의 경우 프로젝트 수요의 변화를 없애는 것은 불가능하다. 사전 조사 부족, 기업이 프로젝트 구현 과정에서 예상치 못한 변화, 프로젝트 과정에서 새로운 사용자 요구 사항 제안, 프로젝트 완료 후 시스템의 지속적인 개선 등 여러 가지 이유로 인해 프로젝트 요구 사항이 변경될 수 있습니다. 수요 변경의 손실을 줄이기 위해 프로젝트 구현 과정에서 일반적으로 1 조치를 취합니다. 가급적 수요 변경의 손실을 개발자에게 이전하다. 중국의 언어 문자는 좋다. 명확한 말 한마디가 다른 이해를 줄 수 있다. 만약 수요가 바뀌면 가능한 한 개발자에게 책임을 돌려주고 프로그램 개발의 허점이라고 말하는 것은 그들의 소프트웨어의 문제이다. (존 F. 케네디, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어, 소프트웨어) 우리가 제시한 수요는 몇 가지 기본적인 수요이며, 우리 개인의 수요가 아니라, 모두가 자주 겪는 문제이다. 만약 우리의 태도가 강경하다면, 개발업자들은 양보할 것이다. 그러나 척도에 주의를 기울여야지, 개발자가 우리가 도리를 따지지 않는다고 생각하게 해서는 안 된다. 2. 고객을 직원 관계가 아닌 제 고객으로 취급합니다. 정보화 프로젝트의 실시 과정에서 일반적으로 삼방이 있다. 하나는 터미널 사용자이고, 하나는 우리 프로젝트의 책임자이고, 세 번째는 구현자나 소프트웨어 업체입니다. 사실 많은 문제들이 갑과 을측 사이에 존재한다. 최종 고객 때문에, 때로는 수요가 명확하게 고려되지 않아, 후기 수요의 변화를 초래할 수 있다. 이는 주로 최종 사용자의 스트레스 부족으로 인한 것이며, 그들은 우리가 자신의 요구에 대해 책임을 지고 있다고 생각할 것이다. 그들이 이런 생각을 가지고 있기 때문에, 때로는 물건을 원할 때, 더워지면 언급하며, 심사숙고를 거치지 않는다. 그래서 사용자가 요청을 할 때, 나는 보통 사용자들에게 서면으로 쓰고 자신의 이름을 서명하라고 요구한다. 글을 쓰기 전에, 그들은 반드시 자신의 필요를 다시 한 번 생각하고 다시 쓸 것이기 때문이다. 이 사고 과정에서 사용자가 원래의 의도를 바꿀 가능성이 높다. 또한 변경 후 요청에는 특별 승인이 필요합니다. 법칙에 따라 사용자의 첫인상이 더 정확하기 때문이다. 따라서 사용자가 수요 변경을 할 때, 우리는 그들에게 찬물을 끼얹어 정신을 차리게 해야 한다. 프로젝트 예산 통제는 CIO 능력을 반영하는 기술이다. 많은 사람들이 정보화공학은 돈을 태우는 게임이라고 하는데, 절대적으로 맞지만, 그 이치도 있다. (윌리엄 셰익스피어, 정보화, 정보화, 정보화, 정보화, 정보화, 정보화, 정보화) 프로젝트 예산이 통제되지 않으면 프로젝트가 최종적으로 성공해도 기업 프로젝트의 책임자로서 가장 큰 기쁨은 반반이다. 만약 이 프로젝트가 실패한다면, 너는 더욱 책망을 받아야 한다. 따라서 좋은 CIO 가 되고, 좋은 정보화 프로젝트 책임자가 되려면, 반드시 프로젝트 예산 통제부터 시작하여, 프로젝트 예산이 초과되지 않도록 최선을 다해야 한다. 그렇지 않으면 너는 더욱 괴로워할 것이다. 예산이 초과되면 제 1 책임자에게 프로젝트 자금을 다시 신청하는 것은 매우 창피한 일이다.