サービスアプローチがIT領域を離れ（ITサービスプロセスの管理など）、会社の他の内部サービスと統合する方法に関する私の経験を共有し続けます。
サービスアプローチの有用性と、私が話していた方法の「落とし穴」が待っています。 今日-理論はなく、実用的なケースのみ。
サービスデスククラスのシステムがさまざまなプロセスで使用された企業の例を検討します。 ほとんどの場合、もちろんITで。
自動化の必要性が他のサービス部門に届いたとき、何が変わったのかを見るのはさらに興味深いです。
質問への回答とともにケースを説明します。
- 問題の定式化;
- 顧客に設定されている目標。
- プロジェクト中に行われたこと。
- 結果は何ですか。
ケース1.契約部門でのアプリケーションの処理の自動化
始めに
同社は、製品クラスのサービスデスクを導入しました。 IT分野ではない使用の肯定的な経験に関する情報は、定期的にリスナーを見つけました。 むしろ、内部顧客。 副部長からITに「飛んだ」タスク：契約部門のサービスデスクに似たモジュールを作成する。
問題を理解するために顧客に連絡しました。 文書作成の申し立ては、部門によって電子メールで受信されました。 彼らの初期処理は体系化されておらず、出演者のリソースをそらしました（しばしば誤って）、準備日は定期的に違反されました。 一般に、カオスが支配し、リーダーシップはそれに飽きていました。 物事を整理する時が来ました。 追加のリソースを引き付けることなく、そしていつものように迅速に。
目標を設定します
- 契約の登録およびそれらへの追加契約のためのアプリケーションの実行に対する制御を強化します。
- 考慮して、従業員のワークロードを調整します。
- レポートを埋め込みます。
当時の会社は契約のある仕事のシステムを使用していたことに注意してください。 ただし、問題の機能は、ドキュメントがこのシステムに入力される前に必要でした。 契約のある作業システムを変更しないことに決めたのはなぜですか？ 答えは簡単です。不便で、長く、高価です。
何をする
パフォーマーと顧客として、私たちは地理的に離れた場所にあり、電話と郵便でやり取りしました。 その結果、出張を節約できました。
お客様との技術的なタスクを準備しました。 彼らは、基本的なライフサイクルでシステムで利用可能なリクエスト「サービスリクエスト」のタイプを基本としました。
アプリケーションの操作に必要な追加の属性を特定しました。 責任のあるステータス変更条件とアラートに関する具体的なデータ。 レポートの主要な指標を個別に検討し、セットアップフェーズを開始しました。
新しい機能の設定には2週間かかりました。 そして、これはテストベースでのすべての作業を考慮しています。 最初に、新しい方法でのアプリケーションの作成がテストグループに提示されました。 しかし、インターフェースの利便性とシンプルさのために、顧客はテスト開始から3日後に製品のすべてを開始するように要求しました。
このシステムの最初のアプリケーションは2017年11月に登場しました。2018年の初めには、すでに500を超えるアプリケーションがありました。
まとめると
- 企業システムでの合意の確立および交渉のプロセスはより高速です。
- アプリケーションの実装の監視-各段階で。
- 従業員の作業負荷の分析に基づいて、アプリケーションはスペシャリスト間で迅速に再配布されます。これは緊急の電話に役立ちます。
- 部門の長はツールを使用して、取引先とのやり取りのために部下を管理します。
- レポートを使用すると、アプリケーションの現在の状況を正確に評価し、それらを使用して作業を構築できます。
そして、ITリーダーへの追加のボーナス-CEOは、行われた作業について報告され、ITを称賛しました。
ケース2.会計における調整行為の準備のための要求の処理の自動化
始めに
行為処理ユニットのスタッフは4人です。 文書を準備する時間は予測できません。 プロセスは不透明です：
- 規制は導入されていません。
- 着信要求の数に関する統計はありません。
- 単一の人員ロードマトリックスはありません。
目標を設定します
- 和解行為の準備のための時間の短縮を達成する。
- 実行者をロードするためのカレンダーを作成します：作業期限、ステータス、分散タスクと未割り当てタスクの数。
何をする
既存のサービスデスクシステムを使用した。 その中に新しいオブジェクトを作成し、顧客の要件に合わせてプロセスをカスタマイズしました。 ディレクトリの更新に関してERPシステムと同期します。
運用の最初のステップで、マネージャーは実際の数のリクエストとロードパフォーマーを含む「スクリーン」を受け取りました。
まとめると
- 調整ステートメントは、規制に従って作成されます。
- ピーク時には、マネージャーは請負業者の仕事を事前に計画し、内部の顧客が期限内に文書を受け取るようにします。
- 統計は単一のシステムに蓄積されており、処理されたドキュメントのアーカイブが表示されています。
- 従業員の解雇中に公式データが失われるリスクは除外されます。
- アクションの全履歴はデスクサービスに記録されます。 すべての紛争は、この情報に基づいて解決されます。
ケース3.賃貸住宅の補償のための申請処理プロセスの自動化
始めに
同社は、賃貸住宅の支払いに対する補償制度を導入しています。 内部サービスによるこのようなアプリケーションの調整には、多くの時間とリソースが費やされました。 レビュープロセスは定期的に遅れました。 特別な承認管理システムの取得と実装には、費用と時間がかかりすぎます。
同社は既にITアプリケーションの管理にサービスデスククラスのシステムを使用しています。 しかし、誰もこのシステムを承認プロセスに適合させようとしませんでした。 私たちは解決策を提案しました。
目標を設定します
- メモの承認時間を半減します。
- 書類を拒否します。
- 文書の転送にかかる輸送費を除外します。
何をする
多くの場合オフィスの外にいるマネージャーの仕事の詳細を考慮しました。 調整は、モバイルデバイスから実行する方が便利です。 このため、新しいメール処理アルゴリズムがサービスデスクに導入されました。 さらに、調整プロセスを管理する必要があります-システムに特別な役割が作成されています。 提出された申請のステータスに関する情報は従業員に見えるようにする必要があります。したがって、申請に関するすべてのデータはシステムの個人アカウントに反映されます。 すべてのプロセス設定は1か月以内に処理されました。
まとめると
- 承認プロセスは明確です。アプリケーションの実行方法、実行者、実行段階をいつでも確認できます。
- アプリケーションの承認と実装の段階の制御を実装しました。
ケース4.人事部の内部作業プロセスの自動化
始めに
地理的に分散した大規模な保有。 人材派遣サービスは40人以上です。 内部問題を解決する主な手段は電子メールです。 タスクの監視は自動化されていません。
目標を設定します
- 人員配置、KPIカード、遠隔教育アプリケーションを自動化します。
- 特定の従業員グループのみにアプリケーションへのアクセスを提供します。
何をする
特別なプロファイルを作成しました。 顧客および請負業者の権利に従って、オブジェクトの可視性をカスタマイズしました。 プログラムのスタッフをトレーニングしました。
まとめると
このプログラムを使用して3年以上が経過しました。 従業員は、それなしでどのように働いていたか想像できなくなりました。 ビジネスにとってのメリットも明らかです。人事サービスの遅延がビジネスに悪影響を及ぼします。
ケース5.ダイニングルームでの料理の注文の自動化
そしてデザート用。 ダイニングルームで料理を注文するプロセスを管理します。 なぜこれがビジネスに役立つのですか？ 何が得られますか？ 一見したところ、これは従業員にとって単純な便利さです。 そして、あなたが数えるなら？
始めに
大企業の食堂。 出席-1日あたり200人以上。 主なタスク：注文の記録を単一の情報システムに保持し、一方ではスタッフの時間を節約し、他方では便利なサービスにより食堂の利益を増やすこと。
目標を設定します
- サービスデスクで料理を事前注文します。
- 注文フォームを作成します（日付/時刻の選択、追加の希望の入力を含む）。
- 受け取った注文を処理するツールを提供します。
何をする
ダイニングルームの長は、技術的な要件、メニューオプションを準備しました。 申請書、ライフサイクルに同意しました。 必要な設定をすべて実施しました。 1週間後、スタッフはシステムを通じて喜んで食事を注文しました。
まとめると
- 蓄積された統計により、要求された料理を決定し、メニューを調整し、パーソナライズされたオファーを開発し、購入を計画し、食堂の労働者に負荷をかけることができます。
- 従業員の食堂への忠誠心が増しました（列数が減り、昼食なしで放置されるリスクがなくなり、食費が監視されました）。
結論へ
サービスデスクへのサービスアプローチについて話すとき、より広く見えることを恐れる必要はありません。
最近、Habréで関連トピックに関する記事が見つかりました 。 私は考えが好きで、引用します：
「ITインシデントを集中的に解決するITデスクサービスはありますか？ たぶん今は、インシデントの定義を拡張することで、ビジネスプロセスの製品の規範からの逸脱を含め、インシデントの原因を考慮せずに、組織にさらに価値をもたらすことができると考える時です。 これはすべて、ITが組織全体のビジネスにより深く関与し、事業成果を達成する真のパートナーと見なされるのに役立ちます。サービスユニットの機能のみを担い、故障を修復するだけの場合とは対照的です。
近年の私たち自身のプロジェクトの経験は、私たちがすでにこの道を歩んでいることを示しています。私たちはITインシデントだけでなくITインシデントにも取り組んでいます。 私たちは真のビジネスパートナーになろうとしています。 宣言するだけでなく、特定の手順とITレシピを提供します。