한 사람에 대해서

그 이야기는 사실이에요. 저는 제 눈으로 직접 봤어요.

여러분 중 많은 분들처럼 한 분은 몇 년 동안 프로그래머로 일했습니다. 혹시 모르니 이렇게 쓰겠습니다. "프로그래머". 제조 회사의 Fix에서 1C 개발자로 일했기 때문입니다.

그 전에는 다양한 전문 분야를 경험했습니다. 프랑스에서 4년간 프로그래머 겸 프로젝트 매니저로 일하며 200시간의 프로젝트를 성공적으로 완수하고, 프로젝트 수익의 일부를 관리비로 받으며, 약간의 판매도 했습니다. 그는 독립적으로 제품을 개발하기도 했고, 6천 명 규모의 대기업에서 IT 부서장을 맡기도 했습니다. 자신의 전직인 1C 프로그래머라는 직업을 활용하기 위해 다양한 시도를 해봤습니다.

하지만 이 모든 직업은, 특히 수입 측면에서, 어느 정도 막다른 골목이었습니다. 당시 우리 모두는 거의 비슷한 급여를 받았고, 똑같은 환경에서 일했습니다.

이 남자는 판매를 하거나 자신의 사업을 시작하지 않고도 어떻게 하면 더 많은 돈을 벌 수 있을지에 관심을 갖게 되었습니다.

그는 자신이 똑똑한 사람이라고 생각하며 자신이 일하는 회사에서 틈새시장을 찾기로 했습니다. 그 틈새시장은 아무도 차지하지 않은 특별한 곳이어야 했습니다. 그리고 회사 측에서도 그 틈새시장에 있는 사람에게 돈을 지불하고 싶어 하길 바랐습니다. 그래야 누군가를 속이거나 뭔가를 부풀릴 필요가 없었습니다. 객관적으로, 그 자리에 있는 사람은 많은 돈을 받아야 한다는 것을 보여주기 위해서였습니다. 한마디로, 괴짜였습니다.

검색은 간단했습니다. 그가 일하던 회사는 "비즈니스 프로세스에 질서를 가져오는 것"이라고 할 수 있는 완전히 자유로운 틈새시장을 가지고 있었습니다. 모든 회사는 많은 문제를 안고 있습니다. 무언가는 항상 제대로 작동하지 않고, 비즈니스 프로세스를 해결해 줄 사람은 아무도 없습니다. 그래서 그는 사업주가 비즈니스 프로세스에서 겪는 문제를 해결할 수 있도록 도와줄 전문가 역할을 해보기로 결심했습니다.

당시 그는 회사에서 6개월 동안 일하며 시중 평균 수준의 급여를 받고 있었습니다. 잃을 게 하나도 없었습니다. 특히 일주일 안에 같은 직장을 쉽게 구할 수 있었기 때문입니다. 그는 갑자기 일이 잘 풀리지 않아 해고당하더라도 큰 문제는 없을 거라고 생각했습니다.

그는 용기를 내어 사장을 찾아갔습니다. 그는 회사에서 가장 문제가 되었던 재고 관리 프로세스를 개선하자고 제안했습니다. 당시에는 재고 관리가 문제였습니다. 지금은 이 회사에서 일하는 모든 사람들이 그 문제들을 기억하는 것조차 부끄럽지만, 분기별로 실시된 재고 관리는 회계 시스템과 실제 잔액 사이에 수십 퍼센트의 불일치를 보였습니다. 원가, 수량, 품목 수 모두에서 말입니다. 정말 재앙이었습니다. 실제로 회사의 회계 시스템에 정확한 잔액이 기록된 날은 재고 관리 다음 날, 단 1년에 네 번뿐이었습니다. 우리 직원이 이 프로세스를 정리하기 시작했습니다.

그 남자는 사장과 합의하여 재고 결과의 편차를 절반으로 줄여야 한다고 했습니다. 게다가 사장은 잃을 게 하나도 없었습니다. 우리의 영웅이 나타나기 전에도 여러 직원들이 이미 모든 것을 고치려고 시도했고, 전반적으로 그 일은 사실상 해결 불가능한 것으로 여겨졌기 때문입니다. 이 모든 것이 관심을 크게 증폭시켰습니다. 모든 것이 잘 풀린다면, 그 남자는 저절로 질서를 회복하고 해결 불가능한 문제를 해결하는 방법을 아는 사람이 될 것이기 때문입니다.

그래서 그는 재고 결과의 편차를 2년 안에 두 배로 줄이는 과제를 안고 있었습니다. 프로젝트 초기에는 어떻게 해야 할지 전혀 몰랐지만, 창고 회계는 간단한 일이므로 여전히 유용한 일을 할 수 있을 것이라는 점을 알고 있었습니다. 게다가 편차를 수십 퍼센트에서 XNUMX%로 줄이는 것은 그리 어렵지 않아 보입니다. 컨설팅이나 유사한 분야에서 일해 본 사람이라면 대부분의 프로세스 문제는 비교적 간단한 조치로 해결된다는 것을 잘 알고 있을 것입니다.

1월부터 5월까지 그는 준비, 자동화, 창고 회계 업무 프로세스 재작성, 점원 및 회계사의 업무 흐름 변경, 그리고 전체 시스템 재설계를 진행했지만, 아무에게도 보여주거나 말하지 않았습니다. 5월에는 모든 직원에게 새로운 지시를 내렸고, 그해 첫 재고 조사를 마친 후 새로운 삶, 즉 그의 규칙에 따라 업무를 시작했습니다. 결과를 관찰하기 위해 회사는 두 달에 한 번씩 재고 조사를 더 자주 실시하기 시작했습니다. 첫 번째 결과는 이미 긍정적이었고, 연말에는 감사 결과의 편차가 1% 미만으로 줄었습니다.

성공은 엄청났지만, 그 지속 가능성은 믿을 수 없었습니다. 그 사람 자신도 물러나 과정을 더 이상 지켜보지 않으면 결과가 유지될지 의심했습니다. 그럼에도 불구하고 결과는 나왔고, 그는 소유주와 합의한 모든 것을 얻었습니다. 그리고 몇 년 후, 결과의 지속 가능성이 확인되었습니다. 몇 년 동안 편차는 1% 이내로 유지되었습니다.

그러자 그는 실험을 반복하기로 결심하고, 사장에게 또 다른 문제적 프로세스인 공급을 개선해 보라고 제안했습니다. 고객이 원하는 물량을 납품할 수 없을 정도로 공급 부족 현상이 발생했습니다. 우리는 10년 안에 공급 부족을 절반으로 줄이고, 그 사람이 15C 관련 프로젝트 1~XNUMX개를 더 완료하기로 했습니다. XNUMXC 관련 프로젝트는 다양한 비즈니스 프로세스 자동화 등 여러 가지가 있습니다.

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

그 급여는 이미 앞으로 2년 동안 그 사람의 모든 필요를 충족시켜 주었기 때문에, 그는 조금 안정을 취하고, 마음을 진정시키고, 그가 직접 만든 따뜻하고 아늑한 장소에 앉아 있기로 결심했습니다.

그게 무슨 의미였을까요? 공식적으로는 IT 담당 이사였습니다. 하지만 실제로 그가 어떤 사람이었는지는 이해하기 어렵습니다. IT 담당 이사는 무슨 일을 할까요? 일반적으로 IT 인프라를 관리하고, 시스템 관리자를 관리하고, ERP 시스템을 구축하고, 이사회에 참석합니다.

이 사람은 핵심 책임 중 하나를 맡았습니다. 변화 프로세스 참여, 주로 프로세스 생성 및 시작, 해결책 검색 및 제안, 새로운 관리 방법 적용, 제안된 변화 검토, 다른 기능과 부서의 효과 분석, 마지막으로 기업 전략 개발에 직접 참여하여 회사 전체를 위한 전략 계획을 독립적으로 개발하는 것입니다.

그는 전권을 위임받았습니다. 이전에는 참석할 수 없었던 어떤 회의에도 참석할 수 있었습니다. 메모장을 들고 앉아 있거나, 무언가를 적거나, 아니면 그냥 듣기만 했습니다. 거의 말을 하지 않았습니다. 그러다가 휴대폰을 만지기 시작했습니다. 이렇게 하면 연상 기억이 더 잘 작동한다고 그는 주장했습니다.

그는 회의에서 유용한 내용을 거의 발표하지 않았다. 그는 자리를 떠나 생각에 잠긴 후, 비판이나 의견, 제안, 혹은 그가 이미 적용한 해결책에 대한 설명이 담긴 편지가 도착했다.

하지만 대부분의 경우, 그는 직접 회의를 소집했습니다. 문제를 발견하고, 가능한 해결책을 제시하고, 이해당사자들을 파악한 후, 모두를 회의실로 끌어들였습니다. 그리고 나서, 그는 최선을 다해 설득하고, 동기를 부여하고, 증명하고, 주장하고, 목표를 달성했습니다.

비공식적으로 그는 사장과 사장 다음으로 회사의 세 번째 사람으로 여겨졌습니다. 물론, 그는 4번부터 시작해서 회사의 모든 "얼굴"들을 정말 화나게 했습니다. 특히 찢어진 청바지와 밝은 티셔츠, 그리고 사장의 시간 때문에 더욱 그랬습니다.

사장은 그에게 매일 한 시간씩 시간을 주었습니다. 매일. 그들은 문제, 해결책, 새로운 사업, 발전 방향, 지표와 효율성, 자기 계발, 책, 그리고 간단히 말해서 삶에 대해 이야기하고 토론했습니다.

하지만 이 남자는 이상했다. 마치 '앉아서 즐기면 돼, 인생은 좋은 거야'라는 듯한 표정이었다. 하지만 아니었다. 그는 곰곰이 생각해 보기로 했다.

그는 궁금해졌습니다. 왜 자신은 성공했는데 다른 사람들은 실패했을까요? 사장도 그를 압박했습니다. 그는 다른 사람들도 질서를 회복할 수 있기를 바란다고 말했습니다. 많은 관리자들이 있고, 그들은 대개 운영 관리와 전략 기획에 관여하지만, 프로세스의 체계적인 변화에는 거의 관여하지 않기 때문입니다. 그들의 직무 설명서에는 프로세스 속도를 높이고 효율성을 높여야 한다고 적혀 있지만, 실제로는 아무도 그렇게 하지 않습니다. 왜 그럴까요? 그도 그 이유에 관심을 갖고 모든 관리자들과 이야기를 나누러 갔습니다.

그는 품질 담당 부책임자를 찾아가 슈하트 관리도를 도입하여 일본 제품보다 품질을 향상시키자고 제안했습니다. 하지만 그 동료는 슈하트 관리도가 무엇인지, 통계적 공정 관리가 무엇인지 전혀 몰랐고, 품질 관리에서 데밍 사이클을 활용하는 방법에 대해서도 막연하게만 들어본 것으로 드러났습니다. 알겠습니다...

그는 다른 부국장에게 가서 통제 방안을 제안했습니다. 하지만 여기서도 아무런 지지를 얻지 못했습니다. 얼마 후, 그는 경계 관리에 대해 알게 되었고, 모든 부국장에게 프로세스 개선을 위해 이 방법의 체계적인 부분을 실행하라고 제안했습니다. 하지만 그 사람이 아무리 말을 해도 아무도 그가 하는 말에 깊이 관여하려 하지 않았습니다. 아마도 관심이 없었거나 내용이 너무 복잡했을 것입니다. 하지만 실제로는 아무도 그 문제를 파악하지 못했습니다.

그는 자신이 아는 모든 것을 회사에 적용하며 이야기했습니다. 하지만 아무도 그의 말을 이해하지 못했습니다. 예를 들어 창고 회계에서 모든 것이 왜 수정되었는지, 통제 및 국경 관리가 그것과 무슨 관련이 있는지 여전히 이해하지 못합니다.

마지막으로 그는 프로그래머들에게 연락했습니다. 직원은 세 명이었습니다. 그는 그들에게 경계 관리, 통제, 품질 관리, 애자일과 스크럼에 대해 이야기했습니다. 놀랍게도 그들은 모든 것을 이해했고, 심지어 기술적, 방법론적 세부 사항까지 그와 어떻게든 논의할 수 있었습니다. 창고 및 공급 프로젝트가 성공한 이유를 그들은 이해했습니다. 그때 그는 깨달았습니다. 사실 프로그래머가 세상을 구할 것이라는 사실을요.

그는 프로그래머만이 비즈니스 프로세스를 필요한 세부 사항까지 제대로 이해할 수 있다는 것을 깨달았습니다.

왜 그들이었을까요? 사실, 그는 명확한 답을 찾지 못했습니다. 단지 주제와 관련된 힌트만 제시했을 뿐입니다.

첫째, 프로그래머는 사업 분야를 알고 있으며, 회사의 다른 누구보다 그 분야에 대해 잘 알고 있습니다.

또한 프로그래머는 프로세스 알고리즘이 무엇인지 실제로 이해합니다. 비즈니스 프로세스는 알고리즘이며, 그 안의 요소들은 서로 조화를 이루지 못할 수 있기 때문에 이는 중요합니다. 예를 들어, 그 사람이 작업하던 조달 프로세스에서 첫 번째 단계는 연간 조달 계획을 수립하는 것이고, 두 번째 단계는 일일 조달입니다. 이 단계들은 직접적인 연결 고리로 연결되어 있습니다. 즉, 사람들은 이 알고리즘에 따라 연간 조달 계획을 수립하고 즉시 주문을 처리해야 한다고 가정합니다. 연간 조달 계획은 50년에 한 번 수립되고, 하루에 XNUMX번의 주문이 들어옵니다. 이것이 알고리즘의 끝이며, 여러분은 그 알고리즘에 따라 작업해야 합니다. 사실, 그는 프로그래머에게 알고리즘에 대한 지식은 경쟁 우위라고 생각했습니다. 왜냐하면 알고리즘에 익숙하지 않은 사람은 비즈니스 프로세스가 어떻게 작동해야 하고 어떻게 표현할 수 있는지 이해하지 못하기 때문입니다.

그 사람에 따르면 프로그래머의 또 다른 장점은 충분한 자유 시간이라고 합니다. 프로그래머가 실제 필요한 시간보다 세 배나 더 많은 시간을 작업에 할애할 수 있다는 사실은 누구나 알고 있지만, 이를 알아차리는 사람은 거의 없습니다. 이것 역시 경쟁 우위입니다. 어떤 비즈니스 프로세스를 체계화하려면 생각하고, 관찰하고, 공부하고, 시도할 수 있는 충분한 자유 시간이 필요하기 때문입니다.

그 사람에 따르면 대부분의 관리자들은 이런 자유 시간이 없고, 오히려 자랑스러워한다고 합니다. 하지만 사실 이는 효율성을 높일 시간이 없어서 효과적인 사람이 될 수 없다는 것을 의미하는데, 악순환이 반복되는 것이죠. 우리 문화에서는 바쁜 것이 유행이라 모든 것이 그대로입니다. 그리고 우리 프로그래머들에게는 이것이 장점입니다. 자유 시간을 찾아 모든 것을 생각할 수 있으니까요.

프로그래머는 정보 시스템을 빠르게 변경할 수 있다고 그는 말했습니다. 모든 기업에 적용되는 것은 아니지만, 그가 근무하는 곳 어디에서든 원하는 대로 수정할 수 있었습니다. 특히 다른 사람의 업무에 영향을 미치지 않는 범위 내에서라면 더욱 그렇습니다. 예를 들어, 사용자 활동을 비밀리에 측정하고 이 정보를 활용하여 회계 부서의 효율성을 분석하고 회계 비용을 추적하는 시스템을 구축할 수 있었습니다.

그리고 그의 말에서 제가 마지막으로 기억하는 것은 프로그래머들이 시스템에 대한 관리 권한을 가지고 있기 때문에 방대한 양의 정보에 접근할 수 있다는 것입니다. 따라서 그들은 이 정보를 분석에 활용할 수 있습니다. 일반 공장에서는 그런 자원을 가진 사람이 아무도 없습니다.

그리고 그는 떠났습니다. 2주간의 사전 통지 기간 동안, 우리는 그가 하던 일을 계속하고 싶었기에 그에게 경험을 공유하도록 강요했습니다. 그리고 그의 자리는 공석이 되었습니다.

그들은 며칠 동안 그를 의자에 앉히고 카메라를 켜고 그의 독백을 녹음했습니다. 완료한 모든 프로젝트, 방법, 접근 방식, 성공과 실패, 원인과 결과, 관리자들의 모습 등에 대해 이야기해 달라고 요청했습니다. 그의 머릿속에서 무슨 일이 벌어지고 있는지 몰랐기 때문에 특별히 제한을 두지는 않았습니다.

물론 독백은 대부분 헛소리와 웃음소리였다. 그는 아주 기분이 좋았다. 시골을 떠나 상트페테르부르크로 향하고 있었기 때문이다. 상트페테르부르크에서 어디로 일하러 가야 할까? 물론 가즈프롬으로.

하지만 우리는 그의 독백에서 유용한 내용을 뽑아낼 수 있었습니다. 제가 기억하는 걸 말씀드리겠습니다.

자, 그 사람의 추천을 들어보겠습니다. 사업 프로세스를 정리하고 싶은 분들을 위해요.

그런 일을 하려면 무엇보다 어느 정도의 "무모함"이 필요합니다. 직장을 잃는 것도, 위험을 감수하는 것도, 동료들과의 갈등을 두려워해서는 안 됩니다. 그는 회사에서 6개월밖에 일하지 않았을 때 직장 생활을 시작했기에, 누구와도 연락할 시간도, 그럴 생각도 없었기에 쉽게 해낼 수 있었습니다. 그는 사람들이 왔다가 간다는 것을 알고 있었고, 그에게는 자신의 성과와 사업주가 평가하는 것이 중요했습니다. 동료들이 자신을 잘 대해주든 못 대해주든, 그 당시에는 크게 신경 쓰지 않았습니다.

두 번째 요점은 이 일을 효과적으로 하려면 안타깝게도 공부가 필요하다는 것입니다. 하지만 MBA 학위나 강좌, 학원이 아니라 스스로 공부해야 합니다. 예를 들어, 그의 첫 프로젝트에서 그는 본능적으로 직감에 따라 행동했고, 아무것도 몰랐으며, 오직 "품질 관리"가 무엇인지만 알고 있었습니다.

그는 효율성 향상 방법에 대한 문헌을 읽기 시작하면서 자신이 사용하는 기술들을 발견했습니다. 그는 그 기술들을 직관적으로 사용했고, 알고 보니 그것은 그의 발명품이 아니었습니다. 모든 것은 이미 오래전에 기록되어 있었습니다. 하지만 그는 시간을 투자했고, 적절한 책을 바로 읽는 것보다 훨씬 더 많은 시간을 투자했습니다. 여기서 중요한 것은 특정 방법을 공부할 때, 아무리 진보된 방법이라도 비즈니스 프로세스의 모든 문제를 완벽하게 해결할 수는 없다는 것입니다.

두 번째 비결은 아는 기술이 많을수록 좋다는 것입니다. 예를 들어, 고대 일본에는 양검류(兩劍流)의 창시자이자 가장 유명한 검객 중 한 명인 미야모토 무사시가 살았습니다. 그는 스승 밑에서 한 유파에서 수련한 후 일본 전역을 여행하며 다양한 사람들과 싸웠습니다. 상대가 더 강하면 여정을 잠시 멈추고 무사시는 제자가 되었습니다. 그 결과, 그는 수년에 걸쳐 여러 스승의 다양한 무술을 습득하고 자신만의 유파를 만들어 자신만의 기술을 더했습니다. 그 결과, 그는 자신만의 고유한 기술을 갖게 되었습니다. 여기서도 마찬가지입니다.

물론 비즈니스 컨설턴트로 활동할 수도 있습니다. 일반적으로 그들은 훌륭한 사람들입니다. 하지만 대개 그들은 특정 방법을 구현하려고 하는데, 비즈니스에 필요한 잘못된 방법을 구현하는 경우가 많습니다. 우리도 안타까운 상황을 겪었습니다. 아무도 문제를 어떻게 해결해야 할지 모르고, 어떻게 해결해야 할지 고민하고 싶어 하지 않습니다. 인터넷에서 검색하거나 컨설턴트에게 전화해서 무엇이 도움이 될지 물어보기 시작합니다. 컨설턴트는 제약 조건 이론을 구현해야 한다고 생각합니다. 우리는 그에게 추천을 받고 구현에 돈을 쓰지만 아무런 결과도 얻지 못합니다.

왜 이런 일이 벌어질까요? 컨설턴트가 "우리는 이런 시스템을 구현하고 있다"고 말했고, 모두가 동의했기 때문입니다. 좋은 일이지만, 하나의 방법론만으로는 단 하나의 비즈니스 프로세스의 모든 문제를 해결할 수 없습니다. 특히 초기 가정, 즉 우리의 가정과 방법론 구현에 필요한 가정이 일치하지 않을 경우에는 더욱 그렇습니다.

그 사람이 추천하는 연습에서는 최고의 방법을 취하고 최고의 방법을 구현해야 합니다. 모든 방법을 다 따르기보다는 그 방법의 핵심 특징, 요령, 그리고 연습을 따라야 합니다. 그리고 가장 중요한 것은 본질을 이해하는 것입니다.

스크럼이나 애자일을 예로 들어보겠습니다. 그는 독백에서 모든 사람이 스크럼의 본질을 완전히 이해하는 것은 아니라고 여러 번 반복했습니다. 그는 또한 제프 서덜랜드의 책을 읽었는데, 어떤 사람들은 그 책을 "가벼운 독서"라고 생각했습니다. 그에게는 마치 심층 독서처럼 느껴졌습니다. 스크럼의 기본 원칙 중 하나가 품질 관리이고, 그 내용이 책에 직접 적혀 있었기 때문입니다.

토요타 프로덕션에 대한 글이었는데, 제프 서덜랜드가 일본에서 스크럼을 어떻게 선보였는지, 스크럼이 어떻게 일본에 뿌리내렸는지, 그리고 어떻게 토요타 프로덕션의 철학과 가까워졌는지에 대한 내용이었습니다. 서덜랜드는 스크럼 마스터의 역할, 데밍 사이클의 중요성에 대해서도 언급했습니다. 스크럼 마스터의 역할은 프로세스를 끊임없이 가속화하는 것입니다. 스크럼의 다른 모든 요소, 즉 단계별 전달, 고객 만족, 스프린트 기간 동안의 명확한 작업 목록 또한 중요하지만, 이 모든 것은 점점 더 빠르게 진행되어야 합니다. 작업 속도는 측정 단위에서 지속적으로 증가해야 합니다.

아마도 번역의 문제일 겁니다. 우리나라에서는 이 책이 "스크럼 - 프로젝트 관리의 혁명적 방법"으로 번역되었는데, 영어 제목을 그대로 번역하면 "스크럼 - 절반의 시간에 두 배의 성과"가 됩니다. 즉, 제목에서도 스크럼의 핵심 기능이 속도라는 것을 언급하고 있습니다.

이 사람이 스크럼을 구현했을 때, 특별한 변화 없이 첫 달 만에 속도가 두 배로 빨라졌습니다. 그는 변화점을 찾고, 스크럼 자체를 직접 수정하여 훨씬 빠르게 작동하도록 했습니다. 그들이 인터넷에 올린 글에 따르면, 그들이 직면한 유일한 문제는 "속도가 두 배로 빨라졌는데, 이제 그 속도로 무엇을 해야 하는지 이해해야 할까요?"라는 질문이었습니다. 하지만 이건 완전히 다른 영역입니다...

그는 또한 몇 가지 방법을 직접 추천하며, 그것들을 근본적이고 기본적인 방법이라고 불렀습니다.

첫 번째는 경계 관리입니다.

그 사람에 따르면, 스콜코보에서 가르치는 것이지 다른 책이나 자료는 없다고 합니다. 그는 운 좋게도 경계 관리에 대해 설교하는 하버드 교수의 강의에 참석하기도 했고, 하버드 비즈니스 리뷰에서 에릭 트리스트의 저서에 대한 여러 기사를 읽기도 했습니다.

경계 관리란 경계를 파악하고 경계에 따라 일할 수 있어야 한다는 것을 의미합니다. 경계는 많고 어디에나 존재합니다. 부서 간, 다양한 업무 유형 간, 기능 간, 운영 및 분석 업무 간에도 경계가 존재합니다. 경계 관리에 대한 지식이 더 높은 차원의 진실을 드러내는 것은 아니지만, 경계라는 프리즘을 통해 현실을 조금 다른 시각으로 바라볼 수 있도록 해줍니다. 따라서 경계를 관리해야 합니다. 필요한 곳에 경계를 만들고, 방해가 되는 곳에서는 제거해야 합니다.

그런데 그 남자는 점점 더 통제에 대해 이야기하더라고요. 그 주제에 대해 뭔가 특이한 점이 있었던 것 같아요.

간단히 말해, 통제란 숫자에 기반한 경영입니다. 그는 여기서 "경영"과 "기반" 그리고 "숫자"라는 정의의 모든 부분이 중요하다고 말했습니다.

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

첫 번째로 아쉬운 점은 숫자입니다. 숫자도 적고 질도 낮습니다.

우리는 1C 정보 시스템에서 상당 부분의 수치를 가져왔습니다. 따라서 그가 주장한 대로 1C 수치의 품질은 좋지 않습니다. 적어도 데이터를 소급적으로 변경할 수 있다는 점에서 그렇습니다.

1C 개발자들이 이에 대한 책임이 없다는 것은 분명합니다. 그들은 시장 요구 사항과 국내 회계 관행만을 고려합니다. 하지만 통제 목적상 특정 기업의 1C 데이터 작업 원칙을 변경하는 것이 더 바람직합니다.

그에 따르면 1C의 수치는 예를 들어 Excel 등을 사용하여 반수동으로 처리됩니다. 이러한 처리는 데이터의 품질을 향상시키지도, 효율성을 높이지도 않습니다.

마지막으로, 다른 사람이 최종 보고서를 다시 확인하여 오류가 있는 수치를 관리자에게 실수로 제출하지 않도록 합니다. 그 결과, 수치는 완벽하게 확인되었지만 매우 늦게 수신자에게 도달합니다. 일반적으로 기간(월, 주 등)이 끝난 후입니다.

그리고 여기서는 모든 것이 매우 간단하다고 그는 말했습니다. 2월에 1월 수치를 받았다면 1월의 활동을 더 이상 관리할 수 없습니다. 1월은 이미 지나갔기 때문입니다.

그리고 그 수치가 회계에 따른 것이고, 회사가 가장 일반적인 회사이고 분기별 VAT 제출을 한다면, 그 회사의 관리자는 분기별로 비교적 적절한 수치를 받게 될 것입니다.

나머지는 명확합니다. 한 달에 한 번 수치를 받게 되므로, 12년에 4번 수치 관리(즉, 통제)를 할 기회가 있습니다. 분기별 보고를 연습하면 XNUMX년에 XNUMX번 관리할 수 있습니다. 보너스로 연간 보고도 할 수 있습니다. 다시 한번 방향을 잡으세요.

나머지 시간에는 통제가 보통 맹목적으로 이루어진다.

숫자가 실제로 등장하면 (그리고 만약 등장한다면) 두 번째 문제가 발생합니다. 바로 숫자에 기반하여 어떻게 관리할 것인가 하는 문제입니다. 저는 그의 추론의 이 지점에 동의할 수 없습니다.

그 남자는 매니저가 이전에 숫자를 가지고 있지 않았다면, 숫자가 나오면 깜짝 놀랄 거라고 주장했습니다. 그는 숫자를 보고 이리저리 뒤틀고, 사람들을 불러서 설명과 조사를 요구할 겁니다. 숫자를 가지고 놀고, 분석을 하고, 모든 직원들에게 "이제 당신들 편에서 벗어나지 않겠습니다"라고 위협적으로 약속했지만, 매니저는 금세 진정하고 포기할 겁니다. 그는 그 도구 사용을 중단할 것이고, 문제는 그대로 남을 겁니다.

이런 일은 관리자의 역량 부족 때문에 발생한다고 그는 말했다. 무엇보다도 통제에 있어서 그렇다. 관리자는 이 수치들을 어떻게 활용해야 할지 전혀 모른다. с하다 - 알지만, 하다 - 모른다. 하다 - 는 위에 적힌 것(싸우다, 놀다)과 같다. 하다 - 는 일상적인 업무 과정이다.

그는 모든 것이 매우 간단하다고 주장했습니다. 수치는 비즈니스 프로세스의 일부가 되어야 한다는 것입니다. 비즈니스 프로세스는 수치가 표준에서 벗어날 때 누가, 무엇을, 언제 해야 하는지 명확하게 이해해야 합니다(한도 초과, 한도 미달, 회랑 초과, 추세 존재, 분위수 미달 등).

그래서 그는 핵심 딜레마를 이렇게 설명했습니다. 숫자는 존재하며, 경영 효율성을 높이기 위해 비즈니스 시스템의 일부가 되어야 하지만… 그렇지 않습니다. 왜 그럴까요?

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

러시아 관리자의 경쟁자 - 고품질의 효과적인 비즈니스 프로세스, 잘 고안된 상호 이익 동기 부여 및 적절한 자동화 - 하지만 아쉽게도 관리자는 일자리 없이 방치될 것입니다.

말도 안 되는 소리, 안 그래? 특히 지도자들에 대해서 말이야. 알았어, 내가 말했잖아. 네가 알아서 해.

조금 덜하긴 하지만, 제 생각엔 여전히 너무 많았어요. 그는 스크럼에 대해 이야기했어요.

물론입니다. 스크럼을 읽고 실제로 시도해 보세요. 스크럼을 읽고 시도해 보지 않았다면, 모른다는 것을 인정해야 합니다. 예를 들어 서덜랜드가 쓴 책을 읽는 것이 낫지, 인터넷에 있는 온갖 기사나 가이드(뭐가 문제일까요?)를 읽는 것보다 낫습니다.

그는 스크럼은 연습을 통해서만 배우고, 수행된 작업량을 의무적으로 측정해야 한다고 말했습니다. 개인적으로는 가장 중요한 두 가지 역할, 즉 제품 책임자와 스크럼 마스터를 경험해 보세요.

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

글쎄요, 그의 최고 분야는 TOS(시스템 제약 이론)였습니다.

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

우리가 TOC에 대해 잘 모른다는 것을 알게 되자, 그는 더 이상 우리에게 말을 하지 않았습니다. 다만 엘리아후 골드랫의 책을 읽는 즐거움을 빼앗지는 않겠다고 덧붙였습니다. 그는 스크럼과 비슷한 조언을 해 주었습니다. "읽고 시도해 보세요." 어떤 직책에 있든, 어떤 일을 하든 TOC 방법을 활용하여 효율성을 높일 수 있는 부분이 있다는 것입니다.

그러자 그의 방법론이 바닥나더니, 그는 이렇게 말했습니다. 특정 상황에 적용할 수 있는 솔루션을 만들기 위해 원칙을 혼합하세요.

이것이 바로 성공의 핵심이자 핵심 권고라고 그는 말합니다. 원칙과 본질을 이해하고, 비즈니스 프로세스와 비즈니스 시스템 등 고유한 응용 솔루션을 구축하세요.

그러고 나서 그는 어떤 명언을 기억해 내려고 애썼고, 결국 온라인에 접속해야 했습니다. 알고 보니 엘리아후 골드랫의 "거인의 어깨 위에 서서"라는 글에서 따온 것이었습니다.

"애플리케이션과 이러한 솔루션의 기반이 되는 기본 개념 사이에는 차이가 있습니다. 개념은 일반적이지만, 애플리케이션은 개념을 특정 환경에 맞춰 적용한 것입니다. 앞서 살펴보았듯이 이러한 적용은 간단하지 않으며 솔루션의 특정 요소를 개발해야 합니다. 애플리케이션은 특정 환경에 대한 가정(때로는 숨겨진)에 기반한다는 점을 기억해야 합니다. 가정이 맞지 않는 환경에서는 이 애플리케이션이 제대로 작동할 것이라고 기대해서는 안 됩니다."

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

출처 : habr.com