Systems Engineering

Abstract#

2009年2月17日のSEの授業にて、どうプロセスを改善するかについての授業がありました。ということで、その記録を。メインは、[プロセス改善に関する論文]の解読#アルファです。

What's new#

  • 2009年3月12日にプロセスを特徴づけるキーとパフォーマンスの測り方について追加しました。

Topic#

  • ビジネスプロセスとは
顧客へ製品やサービスを提供するために実施する活動や行動の集合であり、情報を含むリソースを使う。InputとOutputがある。ビジネスプロセスを改善することは、直接その組織のValue（価値）を改善することにつながるため、重要である（McNurlin, Barbara C. and Ralph H. Sprague, Jr. 2006）。
  • プロセス改善のフレームワーク
プロセス改善を実施する際のやり方の指針になる枠組みがいくつかあるそうです。６シグマやCMMIもその例。結構CMMIが、この授業で触れられていました。
  • プロセスの表記方法の一つ：ETVX、もしくはEITVOX
Fig. 1 The ETVX model[2]

授業で出てきたのですが、詳細は、[2]を参照してください。Xは、Exit Criteria。審査会をイメージ。アクティビティ図に少し似てるけど、Vの部分がアクティビティ図にはないな。インプットにデータがある部分とあまり分岐を明確に書かない点は、DFDにも似ている。強調されていたのが、普通プロセスとプロセスがインターフェースを持っている。よって、プロセスの設計者が分かれているときは、本当によく会話をし意識を合わせておく必要がある。インターフェースが重要ということ。

例として、コンフィギュレーション管理というプロセスがあったとしたら、Inputは、コンフィギュレーションを管理する必要のある文書；Entry Criteriaはシステムのコンフィギュレーション変更が発生する；タスクは、計画を策定して、その計画を実行する；Validateは必要な人にその変更について説明して、了解を得る；Exit Criteriaは、その変更が妥当であること；Outputは、変更後のコンフィギュレーション識別文書とかかな。
  • 手順
[1]の論文に手順が紹介されていました。これは、彼女の具体的な経験に基づくものらしいです。一種のナレッジですね。文章で読むと、抽象的な部分も感じますが、これが実体験に基づくものと聞くと、がぜん、読む気になります。このステップは、どうも定義、文書化、配布後の話のようです([Sarah 2002], 1)。
    1. 新しいプロセスの（実行）計画を作る：実行後のTrackingを含む
    2. 引き続き、マネージメント層のプッシュを得る
    3. 方針を立て、配布する
    4. そのプロセスにより変化する部分について、定量的な値を求めておく。あとでの評価に必要
    5. 目標値の設定。トレーニングする時間、そのプロセスに仕事を割いてもらう時間、使うツール、その他尺度。
    6. トレーニングの実施
    7. 実際の現場にプロセスを適用し、必要であれば、必要な手続きのもと変えていく（Tailoring）
    8. プロセスを支える。ヘルプデスクを置いたり、必要なストレージを備えたり。
    9. そのプロセスが使われているか定期的に監査する

多少、自分の理解に合った表現をしています。詳細は、[1]の論文を見てください。
  • ビジネスプロセスを特徴づけるキー
以下のキーを分析したうえで、プロセス改善に取り組みましょう。ソースを確認。Alter, Stevenだと思うんだけど。
    • (1)どれくらい、構造化できるか：「完全にドキュメント化できるもの」、「人の判断が入るもの」、「全くドキュメント化できないもの」の3種類。3つ目はITを使ったBP改善を諦める。識別が重要。
    • (2)スコープ
    • (3)他組織と一緒にやるプロセスの場合、その組織との仲の好さ（文化の相互理解*|標準の共有*|情報共有*|同じ目標*|一体）
    • (4)頻度
    • (5)複雑さ：単純すぎるプロセスは、改善できません！
    • (6)機械への依存度
    • (7)クリティカルさ
  • どう測るか
以下がプロセスのパフォーマンスを測るための候補になるかも。ソースを確認。Alter, Stevenだと思うんだけど。
    • (1)時間当たりのアウトプット
    • (2)投入したリソースあたりのアウトプット
    • (3)プロセスを完了するのにかかる時間
    • (4)ダウンタイム
    • (5)セキュリティ：セキュリティインシデントが起こる確率
    • (6)欠陥率

興味#

  • How？
上記の手順が答えです。
  • 現状のプロセスとその問題点をどう知るのか？
プロセス改善する以前の問題です。
  • 改善されることをどう説明するのか？
難しいけど、変化を分析し、それを定量化しようとしつつ説明するしかなさそう。

プロジェクト業務改革#

プロジェクト業務改革をここでシミュレートしてみたいと思います。

Reference#

  1. [#1]Sheard, Sarah A., 2002, Process Implementation, International Conference on Software Process Improvement 2002
  2. [#2]Straker, Dave. 2007, Process quality and ETVX, Syque, http://syque.com/quality_tools/toolbook/Process/etvx_quality.htm
  3. [#3]McNurlin, Barbara C. and Ralph H. Sprague, Jr, 2006, Information Systems in Practice (7th Edition]. Prentice Hall
This page (revision-) was last changed on 20-Apr-2024 11:53 by UnknownAuthorTop