1.ボトルネックの優先順位付けと計画
すべてのタスクが表示されているかんばんボードを見ると、「アントン」の行がステッカーで埋められていることがわかります（20以上のタスクが作業中です）。 実際、これは私たちのシステムでは、アントンの人の生産が「ボトルネック」であることを意味します。 タスクはここで止まっています。 それは理解できます-金属ブランクから機械で部品を製造し、次に部品の熱処理に部品の設計よりも少し時間がかかります。 参加するには数時間から2週間かかります。 さらに、プロジェクト作業よりも連続生産が重要であるというルールがあります。 これにより、計画の問題が発生します。 しかし、ここでは、ある程度の不確実性にもかかわらず、多くの行動が取られました。
まず、生産資源の分析が実施され、次のことが明らかになりました：管理、手作業、頭での作業。 M（または管理）は、生産従業員に委任できるものです。 たとえば、部品の製造をCNC工作機械のオペレーターに提供する場合。 P（手作業）は、アントンが自分の手で作成するものです。 たとえば、ラックを溶接し、強度テストを実施します。 G（ヘッド、ヘッドワーク）-これは、ドキュメント、ファイル、図、コンピューターワークの作成に関連する作業です。
次に、各タスクに英数字の番号（01、03、50など）が割り当てられます。 文字は上記のリソースのタイプを意味し、数字はプロジェクトロードマップ内のプロジェクトのシリアル番号です。 数字が小さいほど、プロジェクトの重要性は高くなります。 各生産タスクの名前の情報システムでは、この番号が存在します。 したがって、数回のクリックでタスクを優先度順に並べ替えることができます。 したがって、ルールは「リスト内のタスクが高いほど重要です」と定式化されました。
第三に、週に一度の総会で、まず第一に、生産タスクの計画、そして残りのリソースが行われます。 このアプローチは、ボトルネックの作業を計画し、ボトルネックをボトルネックの作業に絞り込む必要があると言うGoldrattの制約理論によって正当化されます。
第4に、「すべての入力データ（プロセステクノロジ、設計文書、材料、ブランク、標準製品、機器）が十分でない場合は、生産用のタスクを設定しないでください」というルールが作成されました。 コンポーネントを必死に探している生産幹部と、持ち込まれなかったプロジェクト管理者と、コンポーネント遅延の理由についてもう一度状況を説明する必要がないプロジェクトマネージャーの両方にとって、それは神経を救うだけです。 マネージャーは一人で灰色になりますが、彼は生産の神経を保存します。
2.タスクフローを作成して維持する
ITの分野では、タスクのバックログなどがあります。 かんばんボードにもあります。右側の列はリソースの名前の近くです。
タスクを設定するだけでは十分ではありません。常に一定の動きを維持する必要があることを理解することが重要です。 多くのタスクがあるとき、彼らは狭いドアを通って登ろうとする人々の群れのように見えますが、そこに閉じ込められます。 上記の分析により、リソースの帯域幅を理解し、一度に1つのタスクだけが入ってくると、タスクのキューをほぼ均等に作成できます。 このアプローチは、リトルの法則によって正当化されます。 キューが短いほど、キュー内のタスクが速く完了するという事実に帰着します。 これは直感的ですが、常に私たちが行うことはありません。 念のため、私は職場のラップトップでこのルールを作成しました。
実際には、これは、特定の期間にリソースが満たすことができるのと同じ数のタスクが作業内にある必要があることを意味します。 たとえば、生産タスクは1週間に設定されます。 生産スループット：週に9タスク。 したがって、同時に9個以下のタスクが作業で見つかります。 残りのタスクはバックログに残り、キューイングを待機します。
デザイナー、技術者、技術専門家、マーケティング担当者、デザイナー、供給者の仕事により（狭い場所であるため）、それはより透明になり、計画は毎日行われています。
タスクフローを作成して維持するということは、次のことを意味します。タスクは少なくする必要がありますが、より速く完了する必要があり、より頻繁に他のタスクに置き換える必要があります。
3.企業内のリソースの予備を検索する
テクニカルライターのセルゲイがさまざまなレベルの実行困難なタスクを30ほど持っていることを発見したとき、企業内のリソースを見つけてリソースを最適化するトピックについて考えなければなりませんでした。 開発のさまざまな段階で同時に16のプロジェクトがあるため、これはそれほど驚くことではありません。 毎日のチラシについては、マーケティング担当者ではなく、セルゲイが何かで忙しかったというマーケターの猛攻撃を反映する必要がありました。 テクニカルライターが会社のブログに記事を書いて操作指示書SMMを作成しているという事実に加えて、製品のパッケージング指示書を作成する責任が彼の肩にかかった。 実際、パッケージングの説明を作成する際、セルゲイはタイプライターと呼んでいますが、パッケージングセクションから受け取った情報を1つのファイルにまとめました。 この猿の仕事は、私たちの技術の専門的な能力を無効にしました。
どのようにしてリソースを解放しましたか？
パッケージング手順の開発は倉庫スタッフに委任されています。 このため、指示を開発する現在のビジネスプロセスを分析し、新しいプロセスを開発し、従業員のトレーニングを実施し、プロセスを実装およびデバッグし、プロジェクトの典型的なタスクを修正する必要がありました。 全体として、問題の特定からプロセスの安定化までのこれらすべての操作には、約2週間かかりました。
結果を見てみましょう：
-テクニカルライターがいるプロジェクトのタスク数が4に削減されました。
-SMMおよびマーケティングのための時間を解放しました。
-現場の人々が梱包指示を処理し始めたという事実により、梱包指示の開発時間は数回短縮されました。 ここで、私は次の日本の生産の原則に導かれました。「問題を解決したい場合は、この問題が発生したgemba [職場]に行ってください。」 つまり、指示に従って作業する人は、この指示がどのように見えるべきかをよく知っています。 したがって、命令の開発にかかる時間が短縮され始めました。
したがって、梱包指示書を開発するタスクを監視する必要性は事実上なくなりました。バックグラウンドで解決されており、毎週10〜20分しか監視する必要はありません。 パッケージングの問題は、チラシの議題から外れました。
4.規制の策定と実施
日本人が言うように：「現在のプロセスに偏差が現れるときはいつでも、次の質問をしなければなりません。」これは、標準がなかったために起こりましたか？ これは、標準に従わなかったために発生したのですか？ これは、基準が適切ではなかったためでしょうか？」（元気改善：コストを削減して品質を改善する方法、今井正明）。
リソースの損失は、人々が正しく行動する方法を知らない（標準がない）、標準に違反する（標準に従わない）、または標準が不良でありレビューが必要であるという事実からしばしば生じます。
いずれにせよ、標準を持つことは、持たないことよりも常に優れています。 この標準は、企業内の人々間のさらなる改善と対話のためのツールです。
私の練習では、明確な作業プロセスがないという事実のために、タスクが完了していない、または遅れているという事実に繰り返し遭遇します。 したがって、理解できない状況では、最も一見単純な手順であってもビジネスプロセスを開発するのが慣例です。
現時点では、すべてのプロセス、スキームは通常のExcelドキュメントに描かれています。 将来的には、これらすべてのプロセスをbpmシステムに転送する予定です。
5.プロジェクトの論理手順に従う
製品開発は、作業プロトタイプの利用可能日が右にずれたり、さらには遅れたりする場合、予想外のひねりを伴うプロセスであることがよくあります。 また、技術的に複雑なプロジェクトを扱う場合、リスクは劇的に増大します。 はい、リスク、リスク。 しかし、今度は他のことについて話しましょう。
私は常に、製品が市場に出るまでの時間を短縮し、実用的なプロトタイプがない場合は、事前に発売の準備を開始したいと考えています。 マーケティング資料の準備、パイロットバッチ用のコンポーネントの購入、ブログへのテキストの書き込み、Instagramへの投稿、製品のリリースに必要なその他の作業など、多くのリソースが費やされています。 これでプロトタイプの準備はほぼ完了しましたが、...プロトタイプはテストに合格しておらず、いくつかのステップを開発段階に戻しています。 一連の製品の発売に関係するリソースは、無駄に失われていなければ、不合理に使用されていたことがわかります。 この特定の瞬間に、彼らは他のプロジェクトに関与する可能性があります。
製品を市場に近づけたいという願望の中で、チームと会社はあいまいに働いた。 そのため、プロジェクトの論理段階に従うためのルールを開発しました。 人間の時間とお金よりも一時的なリソースを少し失う方が良いです。 これは、当社のように顧客が社内にいる場合に達成するのがさらに簡単です。
6.プロジェクト外のタスクを検討する
繰り返しになりますが、IT業界との類似性を引き出しながら、製品改善のトピックに触れたいと思います。 改善は、消費者の特性と、消費者には見えないものを思い起こさせることの両方に関連しています。 この側面について書くために、私は技術的負債に関するハブに関する最近の記事によって促されました。
例を挙げましょう。
私たちの会社の技術者は一年ちょっと前に現れました。 それ以降のすべての新しいプロジェクトは、彼によって開発され始めました。 ただし、数年前から生産されているが、技術開発が行われていない製品はまだ多くあります。 同じことが1Cの生産部品の会計処理にも当てはまります。金属、コンポーネントの廃止、加工業者からの半製品の移動などです。
したがって、古い製品をリサイクルするには、追加のリソース（少なからず）を使用する必要があります。 計算したとおり、これは数か月の作業です。 そして、私たちは彼女を取り上げました。 製品処理タスクは、プロジェクトタスクと同じ方法で設定され、かんばんボードに配置されます。 これにより、リソースの使用に透明性が追加されます。 一度に処理されるプロジェクトは1つだけであるというルールにしました。
そのため、すべてのタスクを考慮に入れるよう努めています。
上記の簡単な手順は、リソースを大幅に節約し、プロジェクト管理を便利にし、より予測可能な作業に役立ちます。 私が本当に誇りに思っているのは、これらのルールが私たち自身の経験に基づいており、他のチームの経験と一致しているということです。