産業企業へのERPの実装：厳しい建築家や英国の工場に対するAlevtina SvetozarovnaとExcel

ERPシステムの実装は苦痛です。 これは仲間、涙、悲鳴、時には肉体的な報復の脅威です（残念ながら、これは私たちの実践でも起こりました）。 しかし、これは正常です-深刻な変化は多くの感情を引き起こし、人々のキャリアに影響を与えます。そして、小さな変化のためにロシアの企業にERPを導入することはお金の無駄です。

難しさは異なる場合があり、プロジェクトのさまざまな段階で発生します。 新しいシステムのすべてのビジネスプロセスが既に説明され、ロールが構成され、変更が加えられ、指示が発行され、作業を開始する必要がある場合、試用操作中の問題解決の経験を共有したいと思います。 各問題について、その原因を説明し、1つまたは2つのケースを提示します-私たちの経験からそのような問題を解決する例。

試運転段階では、各ビジネスプロセスの実行可能な作業計画を策定し、日付と請負業者を示し、テスト中のオブジェクトの比較的小さなリストを選択し、システムを調整し、制御手順を確立することが非常に重要です。 ここで重要なのは実現可能性です。 あなたを待っている多くの困難があります、不可能な計画で状況をさらに悪化させる必要はありません。

私たちはプロジェクトでこれをすべて行います。

問題番号1。 作業計画が完全に実装されていません

経験から、ほとんどの場合、これらの以前に合意された実行可能な計画でさえ未達成のままです。 出演者が表明した主な理由は、時間の不足です。 理由の完全なリストはもう少しですが：

• 原則：「主なことは製品を生産することであり、他のすべては待つでしょう。」
• 心理的瞬間：パフォーマーは、新しいことよりも通常のルーチンを実行する方がはるかに簡単です。
• 実行者によるシステムのイデオロギーの拒否：「システムは機能しません。 Alevtina Svetozarovna-工場で60歳の賢い女性が、すべてを念頭に置いています。彼女が覚えているすべてを考慮に入れるシステムはありません。」
• 客観的な理由：
  
  
  • 顧客の従業員のコンピュータリテラシーの低レベル。
  • 原則として、自動化中にデータ入力の複雑さが増します-アカウンティングがより詳細になり、システムに入力するためにより多くの情報が必要になり、これにはより多くの時間が必要です。

私は故意に妨害行為や労働者の実際の不足などの項目からリストから除外しました-これは、考えられるほど頻繁には起こりません。

そのような場合はどうすればいいですか？

問題1を解決するための一連の対策

• システムの優先度を上げる 。 実行者は、ERPシステムの実装が企業にとってどれほど重要であるかを絶えず表明する必要があります。 さらに、これについて絶えず「頭脳に滴る」（偶然、必ず行わなければならない）だけでなく、なぜこれが必要なのかを論理的に説明する：Alevtina Svetozarovnaはすでに85歳であり、彼女は長期の年金を望んでいる通常の会計と計画を確立するERPシステムは機能せず、これは最終的に破産やレイオフなどにつながります。 多くの引数がありますが、これらのアクションの主な期待される結果-システムの実装は、少なくとも現在の作業と同じ優先順位を受け取る必要があります。
• 企業文化の変化 。 管理には2つの機能があります-これは保守と改善です。 1つ目は、現在の技術、管理、および組織の標準への準拠を確保するために必要です。 そして改善は、既存の作業標準を改善するための手順です。 カイゼンによると、最悪の企業は最初の機能のみに焦点を当てている企業です。 彼らは、競争や市場条件の変化の結果として崩壊に直面します。 これは、工業企業に適用する場合、すでに店長のレベルから、経営陣は「ルーチン」よりも改善にもっと注意を払う必要があることを意味します。 つまり、そのような状況から切り替える必要性を企業経営者に伝える必要があります。

これに：

• 上からの演奏者への一定の制御と圧力 。 ここではすべてが簡単です。コントロールなし-作業なし。 この手順を調整し、何をどの周波数で正確に測定するかを説明することが重要です。 コントロールは次のようなダイアログではありません。

「まあ、イヴァニッチ、あなたは新しいシステムで働いていますか？」-「私たちは陰険に取り組んでいます」-「まあ、よくやった。 あなたはそこで試してみるでしょう、将軍は私に尋ねます、」

次のようになります。

「昨日、委員会はあなたのワークショップをチェックしました。あなたのワークショップにある300バッチのうち5バッチだけが近くのERPシステムから印刷された付随文書を持っていました。 これは、指定する必要のある95％ではなく1.7％にすぎません。 来週、再チェックが行われます。結果が同じ場合、四半期ごとのボーナスは表示されません。

• 理論化するのではなく、特定の仕事を整理するために 。 オフィスに座っている間はERPシステムを実装できません。 従業員がシステムで作業する時間がないと言った場合、あなたは彼の職場に行き、彼がどのように働くかを見る必要があります。 おそらく彼は間違った指示を使用しているだけか、モニターが小さすぎます。
• 電車、電車、そして再び電車 。 すべてのパフォーマーがコンピューターを操作し、システムを操作するように訓練されていること、全員が指示と対応する権利を持っていることを確認する必要があります。
• 実行者ワークステーションの最適化に関する作業の継続 。 より多くの人がシステムを使用すればするほど、より価値のあるフィードバックが得られます。 この意味のあるフィードバックが得られると、ジョブを最適化して情報を入力するのにかかる時間を短縮できます。 しかし、これは人々が少なくとも1か月間システムを積極的に使用した後にのみ行う価値があります。

ケース1.理論化せず、仕事に行く

問題 ：お客様の一人。 システムを立ち上げる段階で、店主はシステムに在庫の移動を登録する時間がないと不満を訴えました。 店主のワークステーションはさらに最適化され、最小限の情報を入力する必要がありました。 何も助けませんでした。

問題の解決方法 ：企業の会計主任が倉庫の店主のところに来て、ストップウォッチで仕事に費やした時間を測定しました。 時間の80％が商品や材料の紙カードの記入に費やされていることが判明しました。 主任会計士はプロセスを最適化するのに十分な権限を持ち、店主は紙のカードを要求しなくなり、時間不足の問題はなくなりました。

問題番号2。 すべてを一度にやりたいという願望

このアイテムには、問題1と共通点があります。 実行可能な計画が形成された場合、それが合意および承認された場合、1つの方法しかありません 。 それを実現する必要があります。 しかし、代わりに、人々はそれに変更を加え、新しい作業を追加しますが、その後、何が起こったのかに対処できません。 私たちの経験からいくつかの例を示します：

• 試運転計画には、ERPシステムで1種類の製品のみの発売が含まれていましたが、それが何らかの形で深刻ではないと判断し、いくつかの他の完成品を追加しました。 その結果、作業が終了するまで単一の製品は製造されませんでした。
• 試運転に関しては、1つのワークショップのみが定められましたが、「これは私たちの規模ではありません。システムで2、3のワークショップが機能するようにしましょう」。 その結果、経営陣はすべてのワークショップの監視に十分な時間を割くことができず、ワークショップのどれも通常の仕事をすることができませんでした。
• 彼らは、ERPシステムで1つの倉庫の会計を開始することを計画し、その後、倉庫の数を増やしました。 その結果、どの倉庫でもプロセスが完全には開始されませんでした。

この問題の原因は次のとおりです。

• 挑戦が大好きです。 私たちの人々は単純に見えることをすることに興味がなく、挑戦と試練を望んでいます。
• タスクの複雑さの過小評価/自軍の再評価。 マネージャーは、部門の従業員がどれだけの作業を行えるかを常に想像しているわけではありません。 次の会議で結果について尋ねることを忘れることを期待して、人々は会議でできる以上のことを約束する習慣に陥ることがあります。
• 優先順位が間違っています。 たとえば、規範的データと参照データのエラーに対処する必要がありますが、それなしでは原則として開始することは不可能であり、顧客は頑固にこの本当の問題に対処することを望まず、経済サービスの問題を報告することで私たちを攻撃します-それははるかに後で必要な場合にのみ報告します」規制」。
• リーダーシップへの恐怖。 これは、顧客側のプロジェクトマネージャーがゼネラルディレクターまたはオーナーであり、参加していないだけでなく、実装プロセスを特に詳しく調べていない場合に発生します。 同時に、それは特定の管理ポイントで発生し、その重要な別れの言葉を与えます：「ここで幼稚園を手配する必要はありません！ 1つのワークショップでのみ実行するのはどうですか？ 試運転に2か月必要なのはなぜですか？ 3週間で完全にローンチします。この期限を満たす必要があるか、私があなたと何をするかを知っています。」 そして、プロジェクトマネージャーが「奇跡がなく、月に9人の女性が1人の子供を産まない」と答える勇気がない場合、彼はこれらの「貴重な指示」と「実行可能な期限」を出演者に放送します。 誰もが計画が実行可能ではないことを理解していますが、彼らは彼らに過失を見つける正式な理由がないように仕事の外観を作成しようとしています-同時に、貴重な時間がショーに無駄になり、ビジネスに使用できます。

これで何ができますか？

問題2を解決するための一連の対策：

• 単純なものから複雑なものへ ：実行可能な作業計画に同意し、完了し、より真剣に計画に移行しました。 各ステップで、現在のリソースで実際に実行できる作業の量が明確になります。これにより、より正確に計画を立てることができます。 さらに、この方法でのみ問題の実際の範囲を評価することができます。これにより、意味のある管理上の決定を下すことができ、砂の中に頭を隠すことはできません。
• 簡素化する機能 。 必要に応じて、タスク全体を完了するためにいくつかの要件を一時的に放棄できることが非常に重要です。多くの場合、3つのポイントを実行することは、まったく実行しないよりも優れています。

また、Cグレードを実行して落ち着く方法についても話していません。 通常、すべては次のように行われます：彼らはCグレードを行い、しばらくして4に達した後、3〜4年後、システムが既に家に帰ったとき、固体5に行くか、または4が努力の比率の観点からすでに最適であることを理解します得られた結果はオプションです。

• 重要なタスクへの集中 。 まず、システムを起動するために今必要なタスクを実行する必要があります。これは、ノイズを増やす原因ではありません。

重要なのは、まず第一に、マネージャーを日常的な行動から解放するタスクです。

ケース2.簡素化する機能

問題 ：お客様の一人。 ERPシステムの立ち上げは、顧客がシステムの通常の運用には全範囲の運用ルートの形成が必要であると信じていたという事実により、減速しました。 技術者は、必要な運用ルートを作成するには5年間の作業が必要だと述べました。

問題がどのように解決されたか ：顧客は、そのようなアプローチでは決して始めないことを認めました。 その後、razsehovokからのデータが自動化の基礎として採用され、部品とアセンブリユニットのワークショップ間移動の会計処理が実装されました。 これは、完全な計画と会計に十分でした。 現在、ERPシステムがすでに機能しているため、プロットされていないルートから運用ルートに徐々に移行しています。

ケース3.重要なことに焦点を当てる

問題 ：また、お客様の一人。 古い自己記述システムから転送される大量の参照情報は、顧客は多くのエラーがあることを理解しています。 質問の大部分はルートの正確さに関するものでした。 良い方法では、すべてをチェックして調整する必要がありますが、これは膨大な量の情報であり、技術者と設計者はすでにロードされています。 さらに、システム内で誰も作業していない場合にすべてが正しく修正されたことを確認する方法についての疑問が生じました。

問題の解決方法 ：顧客は、「規範」を完全に必要としなかったことを認めました。 現在生産されている位置のみが調整されることが決定されました。部品が品質管理部門に入るたびに、コントローラーはシステムのルーティングとルーティングマップを比較します。 矛盾がある場合、部品はそれ以上転送されません。15分以内に技術者が到着し、システムを調整します。 成功を可能にした2つの重要なポイントがありました。

• 現在生産されている製品に集中する。
• システム内のルートを修正する作業を優先事項にします。

問題番号3。 実行者は、他のユニットの活動が自分の仕事に依存していることを理解していません

機能設計を行う場合、ビジネスプロセスの詳細な分析が行われ、すべての役割と機能、入力と出力、および部門間の関係が明確に記述されます。

しかし、多くの場合、演奏者は自分の仕事の結果が残りにどのように影響するかを理解していません。 例：

• 設計および技術文書の資料および購入されたものは、原則として現在市場に出回っているかどうかを考慮せずに示されています。

シリーズから異論があるかもしれません。「デザイナーや技術者は、なぜ市場に出ているものについて考えなければならないのですか？ これには供給があります。」 リーダーシップが最初にデザイナーや技術者に次のように語ったなら、これは真実だと思います。「あなたは美しい絵の色を選ぶことに自分を制限しないでください」と供給部門は提案しました：「これらの人が尋ねるすべて時間通りに配達する必要があります。 お金をspareしまないでください、北極からでもそれを取ります、しかし創造性は止まるべきではありません。」 残念ながら、最初の部分を表明したとしても、2番目の部分は忘れてしまいます。供給は常に可能な限り安く調達し、予算を超えないようにする必要があります。

• 購入時には、アイテムの名前がわずかに異なるため、異なるコードで入力されます。 供給は大丈夫です-たとえ同じ位置が異なる記事の下にあっても、命名法は大文字になります。 しかし、計画者は代替に「“れ」ており、すべての計画が崩壊します。

この問題の原因は次のとおりです。

• 実行者はプロセス全体を知らず、部門間の相互接続を実現しません。
• アーティストはプロセスがどのように機能するかを理解していますが、あまりにも忙しいので、残りのことを考える余裕がありません。
• このプロセスには改善が必要です。たとえば、従業員がチェーンの「追加リンク」であることが判明する場合があります。1つのユニットから情報を取得してシステムに入り、別のユニットがそれを使用します。 そのような状況にある人が何らかの形で情報をチェックし、その正確さを大事にすることを期待することは困難です。

同じ部門内に自動化またはローカル自動化がない場合、ユニットの相互作用に関する問題は発生しないようであり、それらは目に見えません。 また、ERPは一貫性のない製品やプロセスの欠陥を無視できない統合製品です。

問題3を解決するための一連の対策：

• 継続的なユーザートレーニング 。 トレーニングの最後に、文書に署名して、システムで行うすべてのことに対して彼が全責任を負うことをお勧めします。 この文書には法的効力はありませんが、心理的な影響があります。
• ミーティング 。 ある部門が別の部門の行動に苦しんでいる状況について議論するために、いくつかの部門と定期的に会議を開催する。
• 教育活動 。 特定の状況では、犯人に自分の間違いの結果を修正するように誘ってください。
• プロセスの最適化 。 「余分なリンク」を避け、可能な限りエラーの可能性を閉じます。

ここでは、原則として、パフォーマーの負担を軽減するための項目は追加されていないため、自分の作業が他の部門にどのように影響するかを考える時間があります。 従業員は、大量の仕事は質の低い仕事の言い訳であり、同僚の活動を妨害するものであると考えていますが、彼自身の妨害の修正が必要になります。

ケース4.英語工場

プラントは英語であるため、この場合、「問題」と「問題の解決方法」のセクションはありません。この記事には例として含まれています。

かつて、同僚は英国の工場で1つのERPシステムに精通し、そこで航空機用の機器を製造していました。 彼らは、アプローチした各従業員が自分の仕事が何であるかについて質問し、その部分だけでなく、プロセス全体がどのように配置されているかについて話そうとしたことに驚いていました。 つまり、各パフォーマーは、プロセス全体と、全体的な作業に対するその影響を理解しました。

私はこの事実が最初のものと相関していると明確に言うことはできませんが、その工場は同様のロシアのものより従業員が少なく、同じ量を生産しました。

問題番号4。 「なぜこのことを言わなかったのですか？」

設計段階で、各プロセスのデモが行われます。 これは、システムのさまざまな動作モードと、将来使用される可能性のある重要な機能について説明しています。

しかし、これでは十分ではありません。 多くのプロジェクトでは、試運転を開始するときに疑問が生じました。

• 「なぜこれについて私たちに言わなかったのですか？」
• 「この操作モードが指示に記載されていないのはなぜですか？」

この問題の原因は次のとおりです。

• 成長させる必要のある機能のいくつかを理解する前に、それらが実際に「スタック」した後にのみそれらを議論することは理にかなっています。 私自身の経験から、プロジェクトで少なくとも理論的に必要になる可能性のあるすべての機能についてクライアントに最大限伝えたとしても、将来、同様の質問が生じました-人々は耳を傾けましたが、当時はあまり強くないと思ったことをフィルタリングしましたフィット。
• TKが適切に作成されていても、追加の要件が発生する場合があります。 一部の動作モードは、最初は最初に使用することを目的としていないため、それらについては通知されません。
• 最新のERPシステムは機能が非常に冗長であるため（少なくとも企業の活動を自動化できるように）、インテグレーターがクライアントに通知しなかった機能が常に存在します。

問題4を解決するための一連の対策

• 受け入れ この機能を受け入れて、発生した問題に対処するだけです。

ケース5.「トリックを理解しました」

ERPシステムの実装が成功した後、お茶を飲みながら顧客の主要な従業員は次のように語っています。

「あなたのトリックを理解しました。 あなたは私たちが怖がらないように、私たちに情報を与えられました。 最初から作業範囲全体を代表していた場合、プロジェクトは中止されました。 そして、頭を上げることなく、絶えず問題を解決することなく、彼らは滑り込んで機能するシステムを手に入れました。」

問題番号5。 「二人で書く、三人の心」

機能設計を行う場合、ビジネスプロセスの詳細な分析が行われ、すべての役割と機能、入力と出力、および部門間の関係が明確に記述されます。

そして、試運転段階では、すべての規制に従って作業が1つの方法で行われますが、実際には異なる方法で「詳細」が発生します。 誰もがこれについて知っていますが、当面は「見知らぬ人」とは言いません。

• 技術によれば、部品はワークショップNo. 1で処理されますが、マシンはずっと前にワークショップNo. 21に移動され、パーティーがそこで運ばれていることを誰もが知っています。 テクノロジーを変える時間はありません。そして、誰もがすでにすべてを知っているのに、なぜですか？

「そして今、ERPシステムにこれを反映する方法を見つけてください。そうすれば、新しいルートを作成したり、現在のルートを変更したりせずに、すべてが正しく学習できるようになります。 できない だから、あなたのシステムは私たちの機能を理解せず、私たちに合わない！」

• 完成品になる部品は、組み立て後に製品の一部として塗装され、部品が販売用のスペア部品として使用される場合は、個別に塗装されます。 「そして、なぜあなたの文書では、塗料の消費と対応する操作がどこにも示されていないのですか？」-「わかりません。 それでも、販売する部品が塗装されていることを認識しています。」

この理由：

• パフォーマーの怠azine。
• 労働規律の欠如。

問題5を解決するための一連の対策：

• それに対処する 。 容赦なく。 激しく。 どこでも。 常に。

私たちはこれと戦っているので、この問題のケースはありません。 容赦なく。 激しく。 どこでも。 常に。

問題番号6。 「私たちは非常に特別でユニークです。」

機能設計を開発する場合、ビジネスプロセスの詳細な分析と統合が行われます。 原則として、この段階では、顧客の従業員はマニュアルをインストールすることを忘れないでください。「最も標準的な機能を実装する必要があります。改善は少なく、実装は安価です。」

そして、試運転が開始され、顧客の個々の従業員が「カエルをゆっくり調理する」ようになります。

• 「古い自己記述システムにもこの機能がありました。このような高価なERPは本当に些細なことではないでしょうか？ ファイナライズ！」
• 「これは明らかな間違いであり、計画はそのようには機能しません。 はい、あなたはそれがどのように機能するかを私たちに示しました、はい、デザインに同意しました。 おそらく、私たちは自分の中にいませんでした。 長年にわたって検証されたこのExcelファイルと、工場で60歳になった賢い女性Alevtina Svetozarovnaのように機能するように、計画を作り直しましょう。

この問題の原因は次のとおりです。

• 新しいものへの恐怖と、身近なもので仕事をしたいという願望。
• 特定のユーザー向けに作成されたプログラムである特定の会社は、市場のERPシステムよりも常に便利です。 特に、このプログラムが小さなユニット内で機能する場合。 そして、私たちが統一されたとき、このユニットの従業員は彼らのプログラムが「これはあなたのAcsapt」よりも便利だと正しく宣言します。 しかし、ERPシステムを実装する際の企業の目標は、特定の従業員の利便性ではなく、自己記述型のプログラムでは決して得られない透明な会計と計画です。

問題6を解決するための一連の対策：

• 永遠に統一 。 初期段階だけでなく、プロジェクト全体でさまざまなユニットの作業を最大限に統一してインストールを維持します。
• 最小システム変更 。 改善は極端な手段として考えてください。これは最後に頼ることができます。
• プログラマーの使用率 を KPIと見なさ ないでください 。 顧客に開発者のスタッフがいる場合、プログラマーを100％ダウンロードする誘惑に抵抗して、彼らがアイドル状態にならないようにすることが非常に重要です。
• 厳しい建築家、できればひげを生やした 。 クライアントにプログラマーのスタッフがいる場合、理想的には、システムアーキテクトの機能を実行する別の高度な資格を持つスペシャリストを雇う必要があります。 この従業員は、システムのイデオロギーに準拠しているかどうかすべての改善を確認し、推奨事項を提示し、既存のソリューションのアーキテクチャに適合しない作業を行わないでください。

ケース6.「プログラムによる無法性」

クライアントが彼の問題で私たちのところに来ました。彼らは数年前にシステムを導入し、その後彼の開発部門（3〜4人のプログラマー）がすべてのユーザーの要望を終わらせるために昼夜働きました。 この間、彼らはシステムを「殺し」ました。すべてが遅くなっていたため、システムで作業することは不可能でした。 クライアントはシステムを再実装する必要があり、実装は深刻な困難に直面しました-甘やかされたユーザーは、すべての希望を満たすことに慣れていました。 そしてここでの問題はプログラマーでさえない（彼らは彼らが言われたことを責められるべきではない、彼らはした）、しかしその同じアーキテクトがいないとき。

これらのヒントは簡単で明白に思えるかもしれませんが、このことから効果的かつ効率的でなくなることはありません。 そして、それらに従う人はほとんどいません。 それは健康のようなものです-誰もが老後まで健康を維持するために、あなたは簡単な推奨事項に従う必要があることを知っています：あなたの食事療法、運動、あなたの言語と思考を監視し、あなたの配偶者を変えないでください、暗い路地とスカムバッグを避けてください。 しかし、幸せで健康な人はそれほど多くありません。

以上です。 ERPを実装し、問題を解決し、親切にします。 そして、怠lazと生産規律の欠如と戦ってください。 容赦なく。 激しく。 どこでも。 常に...