ある男について

この話は本当で、私はすべて自分の目で見ました。

皆さんの多くと同じように、数年間、ある男がプログラマーとして働いていました。 念のため「プログラマー」と書きます。 なぜなら、彼は修正中の制作会社 1Snik だったからです。

その前に、彼はさまざまな専門分野に挑戦しました。フランスでプログラマー、プロジェクトマネージャーとして 4 年間勤務し、200 時間を完了することができ、同時にプロジェクトの一部を管理と少しの営業として受け取りました。 私は自分で製品を開発しようとしたり、従業員 6 人の大企業で IT 部門の責任者を務めたり、自分の名言である 1C プログラマーという職業を活用するためのさまざまなオプションを試したりしました。

しかし、これらのポジションはいずれも、主に収入の面で行き詰まりを感じていました。 当時、私たちは皆ほぼ同じお金を受け取り、同じ条件で働いていました。

この男は、自分のビジネスを売ったり作ったりせずに、どうすればもっとお金を稼ぐことができるかを考えていました。

彼は自分を賢い男だと思い込んでおり、自分が働いている会社でニッチな分野を見つけることにしました。 このニッチは、誰かが占有するものではなく、特別なものでなければなりませんでした。 そして、会社自体がこのニッチな分野の人にお金を払いたいと思ってもらいたかったので、誰も騙したり何かを騙したりする必要はありません。 この目的を達成するには、この役職にある人には多額の報酬を支払う必要があります。 一言で言えば変人。

捜索は長くは続かなかった。 この男が働いていた会社には、「業務プロセスの整理」とでもいうべき完全に自由な分野があった。 どの企業もたくさんの問題を抱えています。 常に何かがうまくいっておらず、ビジネス プロセスを修正してくれる人がいません。 そこで彼は、オーナーのビジネスプロセスの問題解決を支援できるスペシャリストとして自分自身を試してみることにしました。

当時、彼はその会社で半年働いており、市場の平均的な給与を受け取っていました。 特に、XNUMX週間以内に同じ仕事を簡単に見つけることができたので、失うものは何もありませんでした。 一般的に、この男は、突然何もうまくいかず解雇されても悪いことは何も起こらないと判断しました。

勇気を出して飼い主さんのところへやって来ました。 私は彼に、ビジネスで最も問題のあるプロセスを改善するよう提案しました。 当時は倉庫会計でした。 今では、この会社で働く誰もがその問題を思い出すことを恥ずかしくさえ思っていますが、四半期ごとに行われる棚卸しでは、会計システムと実際の残高との間に数十パーセントの差異が示されていました。 そしてコスト、量、そしてポジションの数においても。 それは災害だった。 同社が実際に会計システムに正しい残高を記録したのは年に XNUMX 回だけでした (在庫棚卸の翌日)。 私たちの担当者はこのプロセスを整理し始めました。

その男は、在庫結果からの乖離を半分に減らすべきだということで所有者に同意しました。 さらに、私たちのヒーローの前に、さまざまな労働者がすでにすべてを修正しようと試みており、一般に、そのタスクは実質的に解決不可能であると考えられていたため、所有者は特別に失うものは何もありませんでした。 これらすべてが興味を大いに刺激しました。すべてがうまくいけば、その男は自動的に物事を整理し、解決できない問題を解決する方法を知っている人になるからです。

そこで彼は、在庫実績に基づく偏差を 2 年以内に XNUMX 倍に減らすという課題に直面しました。 プロジェクトの開始時には、これを実現する方法がわかりませんでしたが、倉庫会計は単純なものであるため、何か役に立つことができるだろうということは理解していました。 さらに、偏差を数十パーセントから数十パーセントに減らすことは、それほど難しいことではないようです。 コンサルティングや同様の活動に携わったことのある人なら、ほとんどのプロセスの問題は非常に簡単な手順で解決できることを理解しています。

XNUMX月からXNUMX月にかけて、彼は誰にも何も見せず、何も言わずに、準備をし、何かを少し自動化し、倉庫会計の業務プロセスを書き直し、店主や会計士のワークフローを変更し、システム全体をほぼ作り直しました。 XNUMX月に、彼は全員に新しい指示を配布し、その年の最初の棚卸しの後、彼のルールに従って働く新しい生活が始まりました。 結果を観察するために、同社は今後、より頻繁に棚卸しを XNUMX か月に XNUMX 回行うようになりました。 すでに最初の結果は良好で、年末までに監査結果との乖離は XNUMX% 未満にまで減少しました。

成功は途方もないものでしたが、その持続可能性は信じられませんでした。 その男自身も、脇に下がってプロセスを観察するのをやめた場合に結果が保存されるかどうかを疑っていました。 それにもかかわらず、結果はあり、その男は所有者と合意したすべてのものを受け取りました。 その後、数年後、結果の安定性が確認されました。数年間、偏差は 1% 以内に留まりました。

それから彼は実験を繰り返すことに決め、所有者に別の問題のあるプロセス、つまり供給を改善することを提案しました。 品不足のため、お客様が希望する数量を出荷できませんでした。 私たちは、10 年以内に赤字を半減し、その男はさまざまなビジネス プロセスやその他の異端を自動化する 15C に関連する 1 ～ XNUMX のプロジェクトも完了することに同意しました。

2 年目もまたすべてが正常に完了し、赤字は XNUMX 倍以上減少し、すべての IT プロジェクトは正常に完了しました。

給料はすでにXNUMX年前からその男のすべてのニーズを完全に満たしていたため、彼は少し落ち着いて、落ち着いて、自分のために作った居心地の良い暖かい場所に座ることに決めました。

それはどんなかんじでしたか？ 正式には、彼は IT ディレクターでした。 しかし、彼が実際に誰であったのかを理解するのは困難です。 結局のところ、IT ディレクターは何をするのでしょうか? 原則として、IT インフラストラクチャの管理、システム管理者の管理、ERP システムの導入を担当し、取締役会に出席します。

そして、この男は、変更プロセスに参加する重要な責任の XNUMX つを担っていました。主に、これらのプロセスの生成、開始、ソリューションの探索と提案、新しい管理手法の適用、提案された変更の検討、他の機能の有効性の分析、およびそして最後に、会社全体の戦略計画の独立した開発に至るまで、企業の戦略的発展に直接参加します。

彼には白紙の判決が与えられた。 彼は、これまでアクセスできなかった会議に参加できるようになりました。 私はメモ帳を持ってそこに座って、何かを書き留めたり、ただ聞いたりしていました。 彼はめったに話しませんでした。 それから彼は電話で遊び始め、この方が連想記憶がうまく機能すると主張しました。

会議で彼は有益なことをほとんど何も出しませんでした。 彼は立ち去り、考え、そして手紙が届きました - 批判、意見、提案、または彼がすでに適用した解決策の説明が含まれていました。

しかし、より多くの場合、彼は自分自身で会議を招集しました。 私は問題を見つけ、解決策を考え出し、関係者を特定し、全員を会議に参加させました。 そして、できる限りのことをした。 彼は確信し、動機付けられ、証明され、議論され、達成されました。

非公式には、彼はオーナーと取締役に次ぐ社内の4番目の人物とみなされていた。 もちろん、彼は XNUMX 番をはじめとする「会社の人間」全員をひどく激怒させました。特に彼の破れたジーンズと派手な T シャツ、そしてオーナーとしての時間について。

飼い主は彼に1日XNUMX時間を与えました。 毎日。 彼らは、問題、解決策、新しいビジネス、開発分野、指標と効率、自己啓発、本、そして単に人生について話し、議論しました。

しかし、この男は奇人だった。 座って幸せになろう、人生は素晴らしい、というようなものです。 しかし、そうではありません。 彼は反省することにした。

彼は疑問に思いました。「なぜ自分にとってはうまくいったのに、他の人にはうまくいかなかったのか?」 オーナーも彼を後押ししました。彼は、多くのマネージャーがいて、原則として運営管理と戦略計画に従事していますが、実際にはシステムの変更に従事している人は誰もいないため、他の人にも秩序を回復できるようにしてほしいと言いました。彼らのプロセスの中で。 職務内容には、プロセスをスピードアップして効率を高めるべきだと書かれているかもしれませんが、実際には誰もそれを実行していません。 何故ですか？ その男はその理由にも興味を持ち、マネージャー全員に話を聞きに行きました。

彼は品質担当の次長のところ​​に来て、日本の製品よりも良い製品にするためにシューハート管理図の導入を提案しました。 しかし、その同僚はシューハート管理図や統計的工程管理が何であるかを知らず、品質管理におけるデミングサイクルの使用についてしか聞いたことがないことが判明しました。 わかりました…

彼は別の次長のところ​​へ行き、管理の導入を提案した。 しかし、ここでもサポートは見つかりませんでした。 少し後、彼は境界管理 (境界管理) について学び、すべての次長がプロセスを改善するためにこの方法論の体系的な部分を実装することを提案しました。 しかし、私たちの男がどれだけ話したとしても、誰もその内容を深く掘り下げようとはしませんでした。 おそらく興味がなかったか、難しすぎたのでしょう。 しかし実際には、誰もそれを理解していませんでした。

一般的に、彼は自分が知っていること、会社で使っていることすべてについて話しました。 しかし誰も彼のことを理解できませんでした。 彼らは、たとえば、なぜ倉庫会計ですべてが修正されたのか、管理と国境管理がそれとどのような関係があるのか​​をまだ理解していません。

最後に、彼はプログラマーに連絡しました。スタッフには 3 人が含まれていました。 彼は、境界管理、管理、品質管理、アジャイルとスクラムについて話しました...そして驚くべきことに、彼らはすべてを理解し、技術的および方法論的な微妙な点も含めて、なんとか彼と話し合うことさえできました。 彼らは、倉庫と供給プロジェクトがなぜうまくいったのかを理解していました。 そしてその男は、実はプログラマーが世界を救うのだということに気づきました。

ビジネス プロセスを必要な詳細まで正常に理解できるのはプログラマーだけであると彼は気づきました。

なぜ彼らなのか？ 実際、彼は明確な答えを見つけることができませんでした。 論文のヒントだけをまとめました。

まず、プログラマーはビジネスの主題分野を知っており、社内の他のすべての人よりもよく知っています。

さらに、プログラマはプロセス アルゴリズムが何であるかをよく理解しています。 ビジネス プロセスはアルゴリズムであり、その要素に一貫性がない可能性があるため、これは重要です。 たとえば、彼が取り組んでいた調達プロセスでは、最初のステップは年間購入計画の作成であり、50 番目のステップは毎日の購入でした。 これらのステップは直接接続されています。つまり、人々はこのアルゴリズムに従って作業し、年間調達計画を作成し、要求を即座に実行する必要があると想定されています。 年間調達計画は年にXNUMX回策定され、申請はXNUMX日XNUMX件受け付ける。 ここでアルゴリズムは終了するため、それに取り組む必要があります。 実際、アルゴリズムに詳しくない人は、ビジネス プロセスがどのように機能するのか、どのように表現できるのか理解できないため、プログラマーにとってアルゴリズムの知識は競争上の優位性になる、と同氏は推論しました。

Еще один плюс программистов, по словам того парня – у них достаточно свободного времени. Мы все понимаем, как программист может тратить на задачу в три раза дольше времени, чем на самом деле она требует, и мало кто это заметит. Это, опять же, конкурентное преимущество, потому что для того, чтобы приводить какой-то бизнес процесс в порядок, нужно иметь много свободного времени — думать, наблюдать, изучать и пробовать.

この男によれば、ほとんどのマネージャーにはこのような自由な時間がなく、それを誇りに思っているという。 実際には、これは、効率を向上させる時間がないため、人は効率的になれないことを意味しますが、悪循環です。 私たちの文化では、忙しいことがファッショナブルなので、すべてが同じままです。 そして、私たちプログラマーにとって、これは利点です。 自由時間を見つけて、あらゆることを考えることができます。

同氏によれば、プログラマーは情報システムを素早く変更できるという。 これはすべての企業に当てはまるわけではありませんが、どこで働いていても、必要に応じて変更を加えることができました。 特にそれが他の人の仕事に関係ない場合はそうです。 たとえば、ユーザーの行動を秘密裏に測定するシステムを立ち上げ、その情報を使用して同じ経理部門の効率を分析し、会計コストを追跡することができます。

彼の言葉で最後に覚えているのは、プログラマーは大量の情報にアクセスできるということです。なぜなら... システムへの管理アクセス権を持っています。 したがって、この情報を分析に使用できます。 通常の工場ではそのようなリソースを持っている人は他にいません。

そして彼は立ち去った。 義務付けられたXNUMX週間の拘留中、私たちは彼が行っていた仕事を続けたかったので、彼に自分の経験を話すよう強制しました。 さて、彼のポジションが空席になった。

数日間にわたって、彼らは彼を椅子に座らせ、カメラのスイッチを入れ、彼の独白を録音した。 彼らは、完了したすべてのプロジェクト、手法、アプローチ、成功と失敗、原因と結果、マネージャーの肖像などについて私たちに話すように求めました。 特に制限はなかったので、 彼らは彼の頭の中で何が起こっているのか知りませんでした。

もちろん、独白はほとんどすべてナンセンスで笑いでした。彼はとてもご機嫌でした。 サンクトペテルブルクに向けて奥地を出発していたところだった。 サンクトペテルブルクで仕事をするにはどこに行くべきですか? もちろんガスプロムに対して。

しかし、私たちは彼の独白から有益な何かを引き出すことに成功しました。 覚えていることをお話します。

ということで、あの人のオススメ。 業務プロセスの整理整頓に挑戦したい方へ。

このような作業を行うには、まずある程度の「凍傷」を持っている必要があります。 職を失うことを恐れたり、リスクを取ることを恐れたり、同僚との衝突を恐れたりしてはなりません。 彼にとって、入社して半年しか経っておらず、誰とも接触する時間がなく、また接触するつもりもなかったときに旅を始めたため、それは簡単でした。 彼は、人には出入りがあるが、自分自身の結果と経営者からの評価が重要であることを理解していました。 同僚が彼をよく扱ったか、悪く扱ったかは、当時彼にとってはほとんど関心がありませんでした。

XNUMX つ目のポイントは、この作業を効果的に行うには、残念ながら勉強する必要があるということです。 しかし、MBAのために勉強するのではなく、コースや研究所で勉強するのではなく、自分で勉強してください。 たとえば、彼の最初のプロジェクトである倉庫プロジェクトでは、彼は直感的に行動し、「品質管理」が何なのかを何も知りませんでした。

効率を高めるにはどのような方法が存在するのか文献を読み始めたとき、彼は自分が使用しているテクノロジーを発見しました。 男はそれらを直感的に適用しましたが、これは彼の発明ではなく、すべてがすでにずっと前に書かれていたことが判明しました。 しかし、彼は時間を費やし、すぐに適切な本を読んだ場合よりもはるかに多くの時間を費やしました。 ここで重要なのは、特定の技術を研究する場合、最も先進的な技術であっても、ビジネス プロセスのすべての問題を完全に解決できるわけではないということだけです。

XNUMX つ目のコツは、知っているテクニックが多ければ多いほど良いということです。 たとえば、古代日本には、最も有名な剣豪の一人であり、二刀流の創始者である宮本武蔵が住んでいました。 彼はある学校で師匠について学び、その後日本中を旅し、さまざまな男たちと戦った。 男が強ければ、旅はしばらく止まり、武蔵は学生になりました。 その結果、数年かけて彼はさまざまなマスターのさまざまな実践のスキルを習得し、独自の何かを加えて自分の学校を設立しました。 その結果、彼はユニークなスキルを獲得しました。 ここでも同じです。

もちろん、ビジネスコンサルタントとして活動することもできます。 一般的に、彼らは素晴らしい人たちです。 しかし、通常、彼らは何らかの方法論を導入するためにやって来て、ビジネスが必要とする間違った方法論を実装します。 誰も問題の解決方法を知らず、誰もそれを解決する方法を考えたがらないというような悲しい状況もありました。 私たちはインターネットで検索を開始するか、コンサルタントに電話して何が役立つかを尋ねます。 コンサルタントは制約理論を導入する必要があると考え、言います。 私たちは彼の推薦に対してお金を払い、実行にお金を費やしますが、結果はゼロです。

Почему так получается? Потому что консультант сказал, внедряем такую-то систему, и все согласились с ним. Прекрасно, но одна методика не закрывает всех проблем даже одного бизнес-процесса, особенно если не совпадают исходные предпосылки — наши и те, что требуются для внедрения методики.

この男が推奨する実践では、最善のものを取り入れ、最善のものを実行する必要があります。 メソッドをすべて受け入れるのではなく、その主要な機能、特徴、実践方法を取り入れてください。 そして最も重要なことは本質を理解することです。

たとえば、スクラムやアジャイルを考えてみましょう。 この男は独り言の中で、誰もがスクラムの本質を完全に理解しているわけではないと何度も繰り返した。 彼はジェフ・サザーランドの本も読みましたが、これを「軽い読み物」と感じる人もいます。 スクラムの基本原則の XNUMX つは品質管理であり、これは本の中に直接書かれているため、彼にとっては深く読み込んだようでした。

トヨタの生産について、ジェフ・サザーランドが日本でスクラムをどのように紹介したか、スクラムがどのようにして日本に根付いたか、そしてそれがいかに彼らの哲学に近かったかについて書かれています。 そしてサザーランド氏は、スクラムマスターの役割の重要性やデミングサイクルについて語った。 スクラム マスターの役割は、プロセスを常にスピードアップすることです。 段階的なデリバリー、顧客満足度、スプリント期間の作業の明確なリストなど、スクラムに含まれる他のすべてのことも重要ですが、これらすべてはますます迅速に進められる必要があります。 仕事の速度は、それを測定する単位で常に増加する必要があります。

おそらくこれは翻訳の問題です。なぜなら、私たちの本は「スクラム - プロジェクト管理の革新的な方法」と翻訳されているからです。英語のタイトルを直訳すると、「スクラム - 半分の時間で XNUMX 倍の効果」になります。 、つまり、その名前はスクラムの重要な機能としての速度を指します。

この人がスクラムを導入したところ、大きな変化はなく最初の XNUMX か月で速度が XNUMX 倍になりました。 彼は変更点を見つけ、スクラム自体を修正して、より速く機能するようにしました。 彼らがインターネットに書いている唯一のことは、「速度を XNUMX 倍にしたのに、残っているのは、このような速度で何をしているのか理解することだけですか?」という質問に直面したということだけです。 ただし、ここは全く別の領域です...

彼はまた、個人的にいくつかのテクニックを推奨しました。 彼はそれらを基本的、基本的と呼びました。

一つ目は境界管理です。

彼らはスコルコボでそれを教えているが、その男によれば、他に本や教材はないという。 彼はどういうわけか幸運にも、境界管理を説くハーバード大学の教授の講義に参加することができ、またハーバード・ビジネス・レビューでエリック・トリストの業績に関するいくつかの記事を読むことができました。

境界管理では、境界を認識し、境界に対処できる必要があると言われています。 境界線はたくさんあり、部門間、さまざまな種類の作業間、機能間、運用作業と分析作業の間など、どこにでも存在します。 境界管理の知識は、より高度な真実を明らかにするものではありませんが、境界のプリズムを通して、現実を少し異なる光で見ることを可能にします。 そして、必要に応じてそれらを管理し、必要な場合は構築し、邪魔になる場合は削除します。

しかし、ほとんどの場合、その男はコントロールについて話しました。 彼はこのテーマに関してある種の癖を持っていました。

コントロールとは、一言で言えば数字に基づく管理です。 ここで同氏は、定義のすべての部分、つまり「管理」と「基づいて」「数字」の両方が重要であると述べた。

彼によれば、私たちはコントロールのXNUMXつの要素すべてが苦手だという。 特に、それらが相互に、またビジネス システムの他の部分と密接に相互接続されていることを考慮すると、重要です。

まずまずいのは数字です。 数も少なく、品質も低いです。

次に、数値の大部分を 1C 情報システムから取得しました。 つまり、彼が主張したように、1C の数値の質は良くありません。 少なくとも、データを遡って変更できるためです。

Понятно, что вины разработчиков 1С в этом нет — они лишь учитывают требования рынка и менталитета отечественного учета. Но для целей контроллинга принципы работы 1С с данными лучше изменить, на конкретном предприятии.

さらに、同氏によると、1C の数値は Excel などを使用して半手動で処理されます。 このような処理では、データの品質だけでなく効率も向上しません。

最終的には、誤って誤りのある数値を上司に提出してしまわないように、最終報告書は別の人が再チェックします。 その結果、数字は美しく検証された形で受信者に届きますが、非常に遅くなります。 通常 - 期間（月、週など）の終了後。

そしてここでは、すべてが非常に単純だ、と彼は言いました。 XNUMX 月の数字が XNUMX 月に届いた場合、XNUMX 月の活動を管理することはできなくなります。 もうXNUMX月も終わってしまうので。

そして、数値が会計に基づいており、その会社が四半期ごとに VAT を提出する最も一般的な企業である場合、そのマネージャーは四半期に XNUMX 回、比較的適切な数値を受け取ります。

残りは明らかです。 月に 12 回数字を受け取ります。数字で管理 (つまりコントロール) する機会は年に 4 回あります。 四半期報告を実践すると、年に XNUMX 回管理することになります。 さらに、年次報告書というボーナスもあります。 もう一度操縦してください。

残りの時間では、制御は通常、盲目的に実行されます。

数字が実際に現れた場合、XNUMX 番目の問題、つまり数字に基づいてどのように管理するかが問題になります。 私は彼の推論のこの点に同意できませんでした。

その男は、マネージャーが以前に数字を持っていなかったら、彼らの出現が驚きの効果を引き起こすだろうと主張しました。 彼は数字をあれこれ調べてねじ曲げ、カーペットの上で人々を呼び、説明と調査を要求します。 数字をもてあそび、分析を行い、全従業員に「今度はあなたを解雇しない」と脅迫的に約束した後、マネージャーはすぐに落ち着いてこの問題を諦めるでしょう。 ツールの使用をやめてください。 しかし、問題は依然として残るだろう。

このようなことが起こるのは、管理能力が不十分であるためだと同氏は述べた。 まず第一に、制御において。 マネージャーは、これらの数字をどう処理すればよいのかわかりません。 何 сやるべきこと - 何をすべきか知っています - いいえ。 やるべきことは上に書いたこと（喧嘩すること、遊ぶこと）です。 実行は日常的なビジネス プロセスです。

彼は、すべては非常に単純である、デジタルがビジネス プロセスの一部になる必要がある、と主張しました。 ビジネス プロセスでは、数値が基準から逸脱した場合 (境界線を超えている、境界線を下回っている、回廊を超えている、傾向がある、基準を満たしていないなどの任意のオプション) 場合、誰がいつ何をすべきかを明確にすべきです。分位数など)

そこで彼は、重要なジレンマについて概説しました。数字は存在するので、経営効率を高めるためにはビジネス システムの一部となるべきですが...これは実現していません。 なぜ？

なぜなら、ロシアの指導者は自分の権力の一部を競争相手に明け渡すつもりはないからだ。

残念ながら、ロシアのマネージャーの競争相手、つまり高品質で機能するビジネスプロセス、よく考えられた相互利益の動機、適切な自動化があれば、マネージャーは職を失うことになるだろう。

ナンセンスですね、そう思いませんか？ 特にリーダーについて。 オーケー、あなたは自分で決めると言いました。

私の意見では、彼はスクラムについて話しました。

ぜひ、スクラムを読んで実際に試してみてください、と私は言いました。 読んだことはあっても試していないのであれば、自分は無知だと思ってください、と彼は言います。 インターネット上の記事やあらゆる種類のガイド (一体何?) よりも、たとえばサザーランドの本を読む方が良いでしょう。

同氏によると、スクラムは実践を通じて、実行される作業量を強制的に測定することによってのみ習得できるという。 個人的には、プロダクト オーナーとスクラム マスターという XNUMX つの最も重要な役割を試してみてください。

同氏によると、スプリントのリソースやコストを増やさずに、スプリントごとに完了するタスクの量を増やすことができる場合、スクラム マスターの役割を実際に経験することが特に重要だという。

そうですね、彼のトップには TOS (システム制限理論) がありました。

同氏によれば、これらは効率を高めるための基本的かつ基本的な原則であり、ほぼすべての分野、ビジネス プロセス、ビジネス システム全体に適用できます。

私たちが TOS についてよく知らないとわかると、彼は私たちに話すのをやめました。 彼は、エリヤフ・ゴールドラットの本を読む楽しみを私たちから奪うことはしないとだけ付け加えた。 彼はスクラムにも同様の推奨事項を与えました - それを読んで試してみてください。 たとえば、どのような立場にいても、どのような仕事をしていても、TOC メソッドを使用して効率を向上できる場所があります。

その後、彼のテクニックの袋は明らかに枯渇し、「原則を組み合わせて、特定の状況で応用可能な解決策を作成する」と彼は言いました。

これが主な推奨事項であり、成功の鍵であると彼は言います。 原則と本質を理解し、独自のアプリケーション ソリューション (ビジネス プロセスとビジネス システム) を作成します。

それから彼は何かの名言を思い出そうとしましたが、最終的にはオンラインにアクセスする必要がありました。 これは、エリヤフ・ゴールドラットの「巨人の肩の上に立つ」という記事からの引用であることが判明しました。

«Есть разница между прикладными решениями (применениями) и фундаментальными концепциями, на которых основаны эти решения. Концепции являются общими, прикладные решения — это адаптация концепций к конкретной среде. Как мы уже видели, подобная адаптация не является простой и делает необходимой разработку определенных элементов решения. Мы должны помнить — прикладное решение основано на исходных посылках (иногда — скрытых) о конкретной среде. Не надо ожидать, что это прикладное решение будет работать в среде, для которой исходные посылки не верны».

プログラマーと「ビジネスプロセス改善者」の仕事は非常に似ていると彼は言いました。 そして、左。

出所： habr.com