한 남자에 대해서

이야기는 현실이고 모든 것을 내 눈으로 보았습니다.

몇 년 동안 한 사람이 여러분과 마찬가지로 프로그래머로 일했습니다. 혹시라도 "프로그래머"라고 쓰겠습니다. 왜냐하면 그는 픽스 프로덕션 회사의 1Snik이었기 때문입니다.

그 전에 그는 다양한 전문 분야를 시도했습니다. 프랑스에서 프로그래머, 프로젝트 관리자로 4년 동안 그는 200시간을 완료하는 동시에 프로젝트의 일정 비율을 받고 관리와 약간의 판매를 수행할 수 있었습니다. 나는 스스로 제품을 개발하려고 노력했고 6 천명을 보유한 대기업의 IT 부서 책임자였으며 할당 가능한 직업인 1C 프로그래머를 사용하기 위해 다양한 옵션을 시도했습니다.

그러나 이러한 모든 직책은 주로 소득 측면에서 다소 막 다른 골목이었습니다. 그 당시 우리 모두는 거의 같은 돈을 받았고 같은 조건에서 일했습니다.

이 사람은 자신의 사업을 팔거나 창업하지 않고도 어떻게 더 많은 돈을 벌 수 있는지 궁금해하고 있었습니다.

그는 자신이 똑똑한 사람이라고 생각했고 자신이 일하는 회사에서 틈새 시장을 찾기로 결정했습니다. 이 틈새 시장은 누구도 점유하지 않는 특별한 것이어야 했습니다. 그리고 저는 회사 자체가 이 틈새 시장에 있는 사람에게 돈을 지불하기를 원했기 때문에 누군가를 속이거나 속일 필요가 없었습니다. 이 목표를 달성하려면 이 위치에 있는 사람은 많은 돈을 받아야 합니다. 한마디로 괴짜.

검색 시간이 짧았습니다. 이 사람이 일하던 회사에는 '비즈니스 프로세스 정리'라고 할 수 있는 완전 무료 틈새 시장이 있었습니다. 모든 회사에는 많은 문제가 있습니다. 뭔가가 늘 안되고, 와서 업무처리를 고쳐줄 사람도 없습니다. 그래서 그는 소유자가 비즈니스 프로세스에서 자신의 문제를 해결하도록 도울 수 있는 전문가가 되기로 결정했습니다.

당시 그는 회사에서 6개월간 근무했고 시장 평균 연봉을 받았다. 특히 그는 일주일 안에 같은 일자리를 쉽게 찾을 수 있었기 때문에 잃을 것이 없었다. 일반적으로 이 사람은 갑자기 아무 일도 일어나지 않고 해고되면 나쁜 일이 일어나지 않을 것이라고 결정했습니다.

그는 용기를 내어 주인에게 다가갔습니다. 나는 그에게 사업에서 가장 문제가 되는 프로세스를 개선하자고 제안했다. 당시에는 창고 회계였습니다. 이제 이 회사에 다니는 사람들은 모두 그런 문제를 기억하는 것이 부끄러울 정도인데, 분기별로 실시한 재고 조사를 보면 회계 시스템과 실제 잔액이 수십%에 달하는 불일치가 나타났습니다. 그리고 비용, 수량, 위치 수 모두. 그것은 재앙이었습니다. 실제로 회사의 회계 시스템 잔액은 1년에 4번(재고 계산 다음 날)에만 정확했습니다. 우리 직원은 이 과정을 정리하기 시작했습니다.

그 사람은 재고 결과의 편차를 절반으로 줄여야한다는 소유자와 동의했습니다. 또한 소유자는 잃을 특별한 것이 없었습니다. 왜냐하면 우리 영웅 이전에 다양한 작업자가 이미 모든 것을 고치려고 시도했으며 일반적으로 작업이 거의 해결 불가능한 것으로 간주되었기 때문입니다. 이 모든 것이 관심을 크게 불러 일으켰습니다. 모든 것이 잘되면 친구는 자동으로 일을 정리하고 해결할 수없는 문제를 해결하는 방법을 아는 사람이 될 것이기 때문입니다.

그래서 그는 재고 결과에 따른 편차를 2년 안에 XNUMX배로 줄여야 하는 과제에 직면했습니다. 프로젝트를 시작할 때 그는 이를 어떻게 달성할지 몰랐지만 창고 회계가 간단한 일이므로 여전히 유용한 일을 할 수 있다는 것을 이해했습니다. 게다가 편차를 수십%에서 수십%로 줄이는 것도 그리 어렵지 않은 것 같습니다. 컨설팅이나 유사한 활동에 종사해 본 사람이라면 대부분의 프로세스 문제가 상당히 간단한 단계로 해결될 수 있다는 것을 이해합니다.

1월부터 5월까지 그는 누구에게도 보여주거나 말하지 않고 준비하고, 약간 자동화하고, 창고 회계 비즈니스 프로세스를 다시 작성하고, 점주, 회계사의 작업 흐름을 변경하고, 일반적으로 전체 시스템을 다시 만들었습니다. 5월에 그는 모든 사람에게 새로운 지침을 배포했고, 올해의 첫 번째 목록이 끝난 후 그의 규칙에 따라 일하는 새로운 삶이 시작되었습니다. 결과를 관찰하기 위해 앞으로 회사는 2개월에 한 번씩 재고 조사를 더 자주 실시하기 시작했습니다. 이미 첫 번째 결과는 긍정적이었고, 연말까지 감사 결과와의 편차는 1% 미만으로 떨어졌습니다.

성공은 엄청났지만 지속 가능성을 믿을 수 없었습니다. 그 사람 자신은 한 발 물러서서 과정 관찰을 중단하면 결과가 유지될 것이라고 의심했습니다. 그럼에도 불구하고 결과는 나왔고 그 사람은 주인과 합의한 모든 것을 받았습니다. 그런 다음 몇 년 후에 결과의 안정성이 확인되었습니다. 몇 년 동안 편차는 1% 이내로 유지되었습니다.

그런 다음 그는 실험을 반복하기로 결정하고 소유자에게 또 다른 문제가 있는 프로세스인 공급을 개선할 것을 제안했습니다. 고객이 원하는 수량을 배송할 수 없는 부족 현상이 있었습니다. 우리는 10년 이내에 적자가 절반으로 줄어들고 그 사람은 다양한 비즈니스 프로세스 및 기타 이단을 자동화하기 위해 15C와 관련된 1-XNUMX개의 프로젝트도 완료할 것이라는 데 동의했습니다.

2년차에는 모든 것이 다시 성공적으로 완료되었고, 적자가 XNUMX배 이상 감소했으며, 모든 IT 프로젝트가 성공적으로 완료되었습니다.

월급은 이미 2 년 동안 그 사람의 모든 요구를 완전히 충족 시켰기 때문에 조금 안정을 취하고 진정하고 자신을 위해 만든 아늑하고 따뜻한 장소에 앉기로 결정했습니다.

어땠어? 공식적으로 그는 IT 이사였습니다. 그러나 그가 실제로 누구였는지는 이해하기 어렵습니다. 결국 IT 디렉터는 어떤 일을 할까요? 원칙적으로 그는 IT 인프라 관리, 시스템 관리자 관리, ERP 시스템 구현, 이사회 참석 등을 담당합니다.

그리고 이 친구는 변경 프로세스에 참여하는 핵심 책임 중 하나를 가졌으며 주로 이러한 프로세스의 생성, 시작, 솔루션 검색 및 제안, 새로운 관리 기술 적용, 제안된 변경 사항 검토, 기타 기능의 효율성 분석 및 부서, 그리고 마지막으로 기업의 전략적 개발에 직접 참여하여 회사 전체를 위한 전략 계획의 독립적인 개발까지 가능합니다.

그는 블랑쉬 위임장을 받았습니다. 그는 이전에 접근할 수 없었던 어떤 모임에도 참석할 수 있었습니다. 나는 메모장을 들고 거기 앉아 뭔가를 적거나 그냥 듣고 있었습니다. 그는 거의 말을 하지 않았습니다. 그런 다음 그는 연관 기억이 이런 식으로 더 잘 작동한다고 주장하면서 전화 통화를 시작했습니다.

회의에서 그는 유용한 정보를 거의 제공하지 않았습니다. 그는 떠나고 생각한 후 비판, 의견, 제안 또는 그가 이미 적용한 솔루션에 대한 설명이 담긴 편지가 도착했습니다.

그러나 그는 더 자주 회의를 소집했습니다. 문제를 발견하고, 해결책을 찾고, 이해관계자를 파악하고, 모두를 회의에 참여시켰습니다. 그리고 최선을 다해. 그는 확신하고, 동기를 부여하고, 증명하고, 주장하고, 성취했습니다.

비공식적으로 그는 회사의 소유주이자 이사에 이어 세 번째 사람으로 간주되었습니다. 물론 그는 4 번부터 시작하여 모든 '회사 사람들'을 몹시 화나게했습니다. 특히 찢어진 청바지와 밝은 티셔츠, 그리고 오너로서의 시간으로 인해 더욱 그렇습니다.

주인은 그에게 하루에 한 시간씩 시간을 주었습니다. 매일. 그들은 문제, 솔루션, 새로운 비즈니스, 개발 영역, 지표 및 효율성, 개인 개발, 서적 및 단순한 삶에 대해 이야기하고 논의했습니다.

그런데 이 사람이 이상했어요. 마치 편안히 앉아 행복해지면 인생이 좋은 것 같습니다. 하지만. 그는 반성하기로 결정했습니다.

그는 궁금했습니다. 자신에게는 효과가 있었지만 다른 사람들은 그렇지 않은 이유는 무엇일까요? 소유자는 또한 그를 밀었습니다. 그는 관리자가 많고 일반적으로 운영 관리 및 전략 계획에 참여하지만 실제로 시스템 변화에 참여하는 사람은 없기 때문에 다른 사람들도 질서를 회복할 수 있기를 원한다고 말했습니다. 그들의 과정에서. 업무 설명에는 프로세스 속도를 높이고 효율성을 높여야 한다고 적혀 있지만 실제로는 이를 수행하는 사람이 없습니다. 왜 그런 겁니까? 그 사람도 그 이유에 관심을 갖게 되었고, 모든 관리자들과 이야기를 나누러 갔습니다.

그는 품질담당 차장을 찾아와 일본 제품보다 더 나은 제품이 되도록 슈하트 관리도를 도입하자고 제안했다. 그러나 그 동료는 Shewhart 관리도가 무엇인지, 통계적 공정 관리가 무엇인지 몰랐고 품질 관리에 Deming 사이클이 사용된다는 이야기만 들어본 것으로 밝혀졌습니다. 좋아요…

그는 다른 부국장에게 가서 통제 도입을 제안했습니다. 하지만 여기서도 지원을 찾지 못했습니다. 조금 후에 그는 경계 관리(경계 관리)에 대해 알게 되었고 프로세스 개선을 위해 모든 차장에게 이 방법론의 체계적인 부분을 구현하도록 제안했습니다. 하지만 우리 남자가 아무리 말을 많이 해도 그 내용이 무엇인지 파헤치고 싶은 사람은 아무도 없었습니다. 어쩌면 관심이 없었을 수도 있고 너무 어려웠을 수도 있습니다. 그러나 사실 아무도 그것을 알아내지 못했습니다.

일반적으로 그는 회사에서 알고 사용하는 모든 것에 대해 이야기했습니다. 그러나 아무도 그를 이해하지 못했습니다. 예를 들어, 창고 회계에서 모든 것이 수정된 이유와 통제 및 국경 관리가 그것과 어떤 관련이 있는지 여전히 이해하지 못합니다.

마지막으로 그는 프로그래머에게 연락했습니다. 직원에는 3명이 있었습니다. 그는 경계 관리, 통제, 품질 관리, 애자일 및 스크럼... 그리고 놀랍게도 그들은 모든 것을 이해했고 기술적, 방법론적 미묘함을 포함하여 어떻게든 그와 논의할 수 있었습니다. 그들은 창고 및 공급 프로젝트가 성공했던 이유를 이해했습니다. 그리고 나서 그 사람은 깨달았습니다. 사실 프로그래머는 세상을 구할 것입니다.

그는 프로그래머만이 비즈니스 프로세스를 필요한 세부 사항과 함께 정상적으로 이해할 수 있는 유일한 사람이라는 것을 깨달았습니다.

왜 그럴까요? 사실 그는 명확한 답을 찾지 못했습니다. 논문 힌트만 작성했습니다.

첫째, 프로그래머는 비즈니스의 주제 영역을 알고 있으며 회사의 다른 모든 사람들보다 더 잘 알고 있습니다.

또한 프로그래머는 프로세스 알고리즘이 무엇인지 실제로 이해합니다. 비즈니스 프로세스는 알고리즘이고 그 안의 요소는 단순히 일관성이 없을 수 있기 때문에 이는 중요합니다. 예를 들어, 그 사람이 진행하고 있던 조달 프로세스에서 첫 번째 단계는 연간 구매 계획을 수립하는 것이었고 두 번째 단계는 일일 구매였습니다. 이러한 단계는 직접적인 연결로 연결됩니다. 즉, 사람들은 이 알고리즘에 따라 작업해야 한다고 가정합니다. 연간 조달 계획을 작성하고 요청을 즉시 실행합니다. 연간 조달계획은 연 50회 작성되며, 하루 XNUMX회 신청이 접수됩니다. 여기서 알고리즘이 끝나며 이에 대한 작업을 수행해야 합니다. 실제로 그는 프로그래머에게 알고리즘에 대한 지식은 경쟁 우위라고 생각했습니다. 알고리즘에 익숙하지 않은 사람은 비즈니스 프로세스가 어떻게 작동해야 하는지, 어떻게 표현될 수 있는지 이해하지 못하기 때문입니다.

그 사람에 따르면 프로그래머의 또 다른 장점은 자유 시간이 충분하다는 것입니다. 우리 모두는 프로그래머가 실제로 필요한 것보다 작업에 3배 더 많은 시간을 소비할 수 있다는 것을 알고 있으며 이를 알아차릴 사람은 거의 없습니다. 비즈니스 프로세스를 정리하려면 생각하고, 관찰하고, 연구하고, 시도하는 등 많은 자유 시간이 필요하기 때문에 이것은 다시 경쟁 우위입니다.

그 사람에 따르면 대부분의 관리자는 자유 시간이 없으며 그것을 자랑스럽게 생각합니다. 실제로 이것은 효율성을 향상시킬 시간이 없기 때문에 사람이 효과적이 될 수 없다는 것을 의미하지만 악순환입니다. 우리 문화에서는 바쁜 것이 유행이기 때문에 모든 것이 동일하게 유지됩니다. 그리고 우리 프로그래머에게는 이것이 장점입니다. 우리는 자유 시간을 찾고 모든 것에 대해 생각할 수 있습니다.

프로그래머는 정보 시스템을 신속하게 변경할 수 있다고 그는 말했습니다. 이것이 모든 기업에 적용되는 것은 아니지만 그가 일하는 곳 어디에서나 원하는 대로 수정할 수 있었습니다. 특히 다른 사람의 작업과 관련이 없는 경우에는 더욱 그렇습니다. 예를 들어, 그는 사용자 행동을 비밀리에 측정하는 시스템을 시작한 다음 이 정보를 사용하여 동일한 회계 부서의 효율성을 분석하고 회계 비용을 추적할 수 있습니다.

그리고 그의 말에서 제가 마지막으로 기억하는 것은 프로그래머들이 많은 양의 정보에 접근할 수 있다는 것입니다. 왜냐하면... 시스템에 대한 관리 액세스 권한이 있습니다. 따라서 그들은 이 정보를 분석에 사용할 수 있습니다. 일반 공장의 어느 누구도 그러한 자원을 가지고 있지 않습니다.

그리고 그는 떠났습니다. 2주간의 구금 기간 동안 우리는 그가 하고 있던 일을 계속하고 싶었기 때문에 그의 경험을 공유하도록 강요했습니다. 그런데 그의 자리가 공석이 되었습니다.

며칠에 걸쳐 그들은 그를 의자에 앉히고 카메라를 켜고 그의 독백을 녹음했습니다. 그들은 완료된 모든 프로젝트, 방법, 접근 방식, 성공과 실패, 원인과 결과, 관리자의 초상 등에 대해 우리에게 말해달라고 요청했습니다. 때문에 특별한 제한은 없었습니다. 그들은 그의 머리 속에 무슨 일이 일어나고 있는지 몰랐습니다.

물론 독백은 대부분 말도 안되고 웃음이었습니다. 그는 기분이 좋았습니다. 상트페테르부르크로 아웃백을 떠나고 있었습니다. 상트페테르부르크에서 일하려면 어디로 가야 할까요? 물론 가즈프롬으로요.

그러나 우리는 그의 독백에서 유용한 것을 추출했습니다. 제가 기억하는 것을 말씀드리겠습니다.

그럼 그 사람의 추천은. 비즈니스 프로세스를 정리하고 싶은 사람들을 위한 제품입니다.

이런 종류의 작업을 수행하려면 먼저 일정 수준의 "동상"이 필요합니다. 직장을 잃는 것을 두려워해서는 안 되고, 위험을 감수하는 것을 두려워해서는 안 되며, 동료와의 갈등을 두려워해서는 안 됩니다. 회사에서 일한 지 6개월밖에 안 됐을 때 여행을 시작했고 누구와도 접촉할 시간도 없었고 그렇게 할 생각도 없었기 때문에 그에게는 쉬운 일이었습니다. 그는 사람들이 오고 가는 것을 이해했지만 자신의 결과와 사업주의 평가가 그에게 중요했습니다. 동료들이 그를 잘 대해주든 나쁘게 대하든 그 당시에는 그에게는 별 관심이 없었습니다.

두 번째 요점은 이 일을 효과적으로 하기 위해서는 안타깝게도 공부를 해야 한다는 것이다. 그러나 MBA, 코스, 연구소가 아니라 스스로 공부하십시오. 예를 들어, 그의 첫 번째 프로젝트인 창고 프로젝트에서 그는 직관적으로 행동했고, "품질 관리"가 무엇인지 아무것도 몰랐습니다.

효율성을 높이는 방법이 무엇인지에 대한 문헌을 읽기 시작했을 때 그는 자신이 사용한 기술을 발견했습니다. 그 사람은 그것을 직관적으로 적용했지만 이것이 그의 발명품이 아니라는 것이 밝혀졌으며 모든 것이 이미 오래 전에 작성되었습니다. 그러나 그는 올바른 책을 즉시 읽었을 때보다 훨씬 더 많은 시간을 보냈습니다. 여기서는 특정 기술을 연구할 때 그 중 어느 하나, 심지어 가장 진보된 기술도 비즈니스 프로세스의 모든 문제를 완전히 해결할 수 없다는 것을 이해하는 것이 중요합니다.

두 번째 비결은 기술을 많이 알수록 좋다는 것입니다. 예를 들어, 고대 일본에는 가장 유명한 검객 중 한 명이자 두 검 스타일의 저자인 미야모토 무사시가 살았습니다. 그는 어떤 스승과 함께 학교에서 공부한 다음 일본을 여행하고 다른 친구들과 싸웠습니다. 그 사람이 더 강하면 여행이 잠시 멈추고 무사시는 학생이되었습니다. 그 결과, 그는 수년에 걸쳐 다양한 스승들의 다양한 수행 기술을 습득하고 자신만의 학교를 설립하여 자신만의 것을 추가했습니다. 그 결과 그는 독특한 기술을 습득했다. 여기도 마찬가지입니다.

물론 비즈니스 컨설턴트로 활동할 수도 있습니다. 일반적으로 그들은 훌륭한 사람들입니다. 그러나 원칙적으로 그들은 일종의 방법론을 도입하게 되고, 비즈니스에 필요한 잘못된 방법론을 구현하게 됩니다. 우리는 또한 그런 슬픈 상황을 겪었습니다. 아무도 문제를 해결하는 방법을 모르고 문제를 해결하는 방법을 생각하고 싶어하는 사람도 없습니다. 우리는 인터넷에서 검색을 시작하거나 컨설턴트에게 전화를 걸어 무엇이 우리에게 도움이 될 수 있는지 물어봅니다. 컨설턴트는 제약 이론을 도입해야 한다고 생각하고 말합니다. 우리는 그의 추천에 대해 그에게 돈을 지불하고 구현에 돈을 썼지만 결과는 0입니다.

왜 이런 일이 발생합니까? 컨설턴트님이 우리가 이런 저런 시스템을 도입한다고 하셔서 모두가 그 말에 동의했어요. 좋습니다. 하지만 하나의 방법론이 하나의 비즈니스 프로세스의 모든 문제를 다루지는 않습니다. 특히 초기 전제 조건(우리의 전제 조건과 방법론을 구현하는 데 필요한 전제 조건)이 일치하지 않는 경우에는 더욱 그렇습니다.

그 사람이 추천하는 실천에서는 최선을 다하고 최선을 다해 실행해야 합니다. 방법을 완전히 받아들이지 말고 핵심 기능, 기능 및 관행을 취하십시오. 그리고 가장 중요한 것은 본질을 이해하는 것입니다.

예를 들어 Scrum이나 Agile을 예로 들 수 있습니다. 그의 독백에서 그 사람은 모든 사람이 스크럼의 본질을 완전히 이해하지 못한다는 것을 여러 번 반복했습니다. 그는 또한 일부 사람들이 "가벼운 독서"라고 생각하는 Jeff Sutherland의 책을 읽었습니다. 스크럼의 기본 원칙 중 하나가 품질 관리이기 때문에 그 내용은 그에게 깊이 읽힌 것 같았습니다. 이 내용이 책에 직접 기록되어 있습니다.

Toyota Production에 대해, Jeff Sutherland가 일본에서 스크럼을 어떻게 보여줬는지, 스크럼이 어떻게 그곳에 뿌리를 내렸는지, 그리고 그것이 그들의 철학에 얼마나 가까웠는지에 대해 설명합니다. 그리고 Sutherland는 데밍 사이클에 관해 스크럼 마스터 역할의 중요성에 대해 이야기했습니다. 스크럼 마스터의 역할은 프로세스 속도를 지속적으로 높이는 것입니다. 스크럼의 다른 모든 것(단계적 제공, 고객 만족, 스프린트 기간 동안의 명확한 작업 목록)도 중요하지만 이 모든 것이 점점 더 빠르게 진행되어야 합니다. 작업 속도는 측정 단위에 따라 지속적으로 증가해야 합니다.

아마도 이것은 번역의 문제일 것입니다. 왜냐하면 우리 책이 "스크럼 - 프로젝트 관리의 혁명적인 방법"으로 번역되었기 때문입니다. 영어 제목을 문자 그대로 번역하면 "스크럼 - 절반의 시간에 두 배"가 됩니다. 즉, 이름에서도 스크럼의 핵심 기능으로 속도를 뜻한다.

이 사람이 스크럼을 구현했을 때 큰 변화 없이 첫 달에 속도가 두 배로 늘어났습니다. 그는 변화할 점을 발견하고 스크럼 자체를 수정하여 훨씬 더 빠르게 작동하도록 만들었습니다. 그들이 인터넷에 쓴 유일한 것은 "우리는 속도를 두 배로 높였습니다. 남은 것은 우리가 그러한 속도로 무엇을하고 있는지 이해하는 것뿐입니다. "라는 질문에 직면했다는 것입니다. 그러나 이것은 전혀 다른 영역입니다 ...

그는 또한 개인적으로 몇 가지 기술을 추천했습니다. 그는 그것들을 근본적이고 기본적이라고 불렀습니다.

첫 번째는 경계 관리이다.

그들은 Skolkovo에서 그것을 가르치는데 그 사람에 따르면 다른 책과 자료는 없습니다. 그는 운이 좋게도 경계 관리를 설교하는 하버드 교수의 강의에 참석했고, 하버드 비즈니스 리뷰에서 Eric Trist의 작업에 관한 여러 기사를 읽었습니다.

경계 관리란 경계를 확인하고 경계에 맞춰 작업할 수 있어야 한다고 말합니다. 부서 간, 다양한 유형의 작업 간, 기능 간, 운영 작업과 분석 작업 간 등 어디에나 많은 경계가 있습니다. 경계 관리에 대한 지식은 더 높은 진실을 드러내지는 않지만 경계의 프리즘을 통해 약간 다른 관점에서 현실을 볼 수 있게 해줍니다. 그리고 그에 따라 관리하십시오. 필요한 곳에 세우고 방해가되는 곳에서는 제거하십시오.

그러나 그 사람은 통제에 대해 가장 자주 이야기했습니다. 그는 이 주제에 관해 약간의 특이한 점이 있었습니다.

통제는 한마디로 숫자에 따른 관리이다. 여기서 그는 정의의 모든 부분, 즉 "관리", "기반" 및 "숫자"가 모두 중요하다고 말했습니다.

그는 우리가 통제의 세 가지 구성 요소 모두에 서툴다고 말했습니다. 특히 서로 밀접하게 연결되어 있고 비즈니스 시스템의 다른 부분과도 밀접하게 연결되어 있다는 점을 고려하면 더욱 그렇습니다.

가장 먼저 나쁜 것은 숫자입니다. 그 수가 적고 품질이 낮습니다.

그런 다음 우리는 1C 정보 시스템에서 숫자의 상당 부분을 가져갔습니다. 따라서 그가 주장한 대로 1C의 숫자 품질은 좋지 않습니다. 최소한 데이터를 소급하여 변경할 수 있기 때문입니다.

이것이 1C 개발자의 잘못이 아니라는 것이 분명합니다. 그들은 시장 요구 사항과 국내 회계 사고 방식만을 고려합니다. 그러나 제어 목적으로 특정 기업의 데이터에 대한 1C 작업 원칙을 변경하는 것이 좋습니다.

또한 그에 따르면 1C의 숫자는 예를 들어 Excel을 사용하여 반수동 처리를 거칩니다. 이러한 처리는 효율성뿐만 아니라 데이터 품질도 향상시키지 않습니다.

결국 실수로 오류가 있는 수치를 관리자에게 제출하지 않도록 최종 보고서를 다른 사람이 다시 확인합니다. 결과적으로 숫자는 수신자에게 아름답고 검증되었지만 매우 늦었습니다. 일반적으로 - 기간(월, 주 등)이 끝난 후입니다.

그리고 그는 모든 것이 매우 간단하다고 말했습니다. 1월에 대한 숫자가 2월에 나왔다면 더 이상 1월의 활동을 관리할 수 없습니다. 벌써 1월이 끝났으니까요.

그리고 수치가 회계를 기반으로 하고 회사가 분기별로 VAT를 제출하는 가장 일반적인 회사인 경우 관리자는 분기에 한 번 상대적으로 적절한 수치를 받습니다.

나머지는 분명합니다. 한 달에 한 번 번호를 받습니다. 12년에 4번 번호로 ​​관리(즉, 제어)할 수 있는 기회가 있습니다. 분기별 보고를 실천한다면 XNUMX년에 XNUMX번 관리하게 됩니다. 보너스 - 연례 보고. 한 번 더 조종하세요.

나머지 시간에는 일반적으로 통제가 맹목적으로 수행됩니다.

숫자가 나타나면 두 번째 문제가 발생합니다. 숫자를 기반으로 관리하는 방법은 무엇입니까? 나는 그의 추론의 이 점에 동의할 수 없었다.

그 남자는 매니저가 이전에 숫자를 가지고 있지 않았다면 그들의 외모가 와우 효과를 일으킬 것이라고 주장했습니다. 그는 숫자를 이리저리 보고 비틀고, 사람들에게 카펫 위의 전화를 걸어 설명과 조사를 요구할 것입니다. 숫자를 가지고 놀고, 분석하고, 모든 직원에게 "이제 나는 당신을 제거하지 않을 것입니다"라고 위협적으로 약속한 후 관리자는 매우 빠르게 진정하고 이 문제를 포기할 것입니다. 도구 사용을 중지하십시오. 그러나 문제는 여전히 남아 있을 것입니다.

이는 관리 역량이 부족해서 발생한다고 그는 말했다. 우선 통제에서. 관리자는 이 숫자로 무엇을 해야할지 모릅니다. 무엇 с해야 할 일 - 무엇을 해야할지 알고 있습니다. - 아니오. 해야 할 일은 위에 쓰여진 것입니다 (다투다, 놀다). 하는 것은 일상적인 비즈니스 프로세스입니다.

그는 모든 것이 매우 간단하다고 주장했습니다. 디지털은 비즈니스 프로세스의 일부가 되어야 합니다. 비즈니스 프로세스에서는 숫자가 표준에서 벗어난 경우 누가 무엇을 언제 해야 하는지(모든 옵션 - 국경 위, 국경 아래, 복도 너머로 이동, 추세의 존재, 충족 실패) 명확하게 명확해야 합니다. 분위수 등)

그래서 그는 핵심 딜레마에 대해 설명했습니다. 숫자가 존재하고, 관리 효율성을 높이기 위해 숫자가 비즈니스 시스템의 일부가 되어야 하지만... 이런 일은 일어나지 않습니다. 왜?

러시아 지도자는 경쟁자에게 자신의 권력을 포기하지 않을 것이기 때문입니다.

러시아 관리자의 경쟁사(고품질의 효과적인 비즈니스 프로세스, 잘 고려된 상호 이익이 되는 동기 부여 및 적절한 자동화)는 아쉽게도 관리자를 직업 없이 떠날 것입니다.

말도 안되는 소리, 동의하지 않나요? 특히 리더에 대해서는요. 좋아, 내가 말했잖아, 스스로 결정하라고.

조금 적지만 여전히 너무 많은 것 같습니다. 제 생각에는 그는 스크럼에 대해 이야기했습니다.

저는 꼭 스크럼을 읽고 실제로 사용해 보시기 바랍니다. 만약 당신이 그것을 읽었지만 시도해 보지 않았다면 자신이 무지하다고 생각하십시오. 인터넷에 있는 기사나 온갖 종류의 가이드(도대체 뭐죠?)보다는 예를 들어 서덜랜드가 쓴 책을 읽는 것이 더 좋습니다.

그는 스크럼은 연습과 수행된 작업량에 대한 필수 측정을 통해서만 배울 수 있다고 말했습니다. 개인적으로 가장 중요한 두 가지 역할, 즉 제품 소유자와 스크럼 마스터를 시도해 보세요.

그에 따르면 스프린트의 리소스와 비용을 늘리지 않고도 스프린트당 완료되는 작업의 양을 늘릴 수 있는 스크럼 마스터의 역할을 실제로 경험하는 것이 특히 중요합니다.

글쎄요, 그의 꼭대기에는 TOS(시스템 제한 이론)가 있었습니다.

그 사람에 따르면 이것은 거의 모든 영역, 모든 비즈니스 프로세스 및 비즈니스 시스템 전체에 적용될 수 있는 효율성 향상의 기본적이고 근본적인 원칙입니다.

그는 우리가 TOS에 익숙하지 않다는 것을 알았을 때 우리에게 알려주는 것을 중단했습니다. 그는 다만 우리가 엘리야후 골드렛의 책을 읽는 즐거움을 빼앗지 않겠다고 덧붙였습니다. 그는 Scrum에도 비슷한 추천을 했습니다. 읽어보고 시도해 보세요. 마찬가지로, 어떤 위치에 있든, 어떤 일을 하든 TOC 방법을 사용하면 효율성을 높일 수 있는 곳이 있습니다.

그런 다음 그의 기술 가방은 분명히 말라 버렸고 그는 다음과 같이 말했습니다. 특정 상황에 적용되는 솔루션을 만들기 위해 원리를 혼합하십시오.

그는 이것이 주요 권장 사항이자 성공의 열쇠라고 말합니다. 원칙과 본질을 이해하고 고유한 애플리케이션 솔루션(비즈니스 프로세스 및 비즈니스 시스템)을 만듭니다.

그런 다음 그는 몇 가지 인용문을 기억하려고 노력했고 결국 온라인에 접속해야 했습니다. 이는 Eliyahu Goldratt의 "거인의 어깨 위에 서서"라는 기사의 인용문으로 밝혀졌습니다.

“응용 솔루션(애플리케이션)과 해당 솔루션의 기반이 되는 기본 개념에는 차이가 있습니다. 개념은 일반적이며 응용 솔루션은 개념을 특정 환경에 적용하는 것입니다. 이미 살펴보았듯이 이러한 적응은 간단하지 않으며 솔루션의 특정 요소를 개발해야 합니다. 애플리케이션 솔루션은 특정 환경에 대한 초기 가정(때로는 숨겨져 있음)을 기반으로 한다는 점을 기억해야 합니다. 이 애플리케이션 솔루션은 가정이 올바르지 않은 환경에서 작동할 것으로 예상해서는 안 됩니다.”

그는 프로그래머와 "비즈니스 프로세스 개선자"의 작업이 매우 유사하다고 말했습니다. 그리고 떠났다.

출처 : habr.com