2010年9月2日のブックマーク (2件)

  • 業務フローチャートに例外処理を描き切れない理由

    業務フローチャートの構造を原理的に考える この従来の発想を転換するために、「業務フローチャートは何か」というそもそも論に戻って考えてみよう。 業務プロセスにおいて、その構成単位である「作業」を、「誰が・何を・どうする・いつ・どうやって・どのくらい」という「要素」に分解し、それに「流れ」を加えながら、視覚的に理解しやすい形に再構築したものが、業務フローチャートである。 ここでのポイントは、「要素」と「流れ」である。 「要素」に関して、業務フローチャートの様式を決定する際には、(1)どの要素を必ず記載(「絶対的記載要素」と呼ぶ)し、どの要素を補助的に記載(「補助的記載要素」と呼ぶ)するか分類し、(2)それらの要素をどのようなルールの下で記載するか、について決めなくてはいけない。 従来の発想による様式では、担当者別にスイムレーンを引いた瞬間に、「誰が」が絶対的記載要素となる。作業内容をプロットす

    業務フローチャートに例外処理を描き切れない理由
  • 発注者,受注者の責任範囲を明確化しよう

    インテグレータやベンダーが言ってはいけないのは,「何でもやります」という言葉です。 「何でもやります」というベンダーは,ユーザー企業からすれば,一見願ってもないことのように見えます。しかし,様々な製品,様々なバージョンが混在する環境で,契約した価格で何でもできるはずはありません。それだけの人員を貼り付けることができるわけはないからです。 結局しわ寄せは,ベンダーの現場SEに行くことになります。対応させられる現場SEは疲弊し,モチベーションは下がり,システムのサービス・レベルは低下することになります。 発注者、受注者がそれぞれの責任範囲を明確化し,双方が責任を持つことが,品質の高い,安定したシステムを作るために必要であると私は考えています。双方が責任を持つことで,お互いの苦労が把握できます。片側がすべて持っていては,相手の苦労が実感できず,結果的に無理な要求の連続となり,破綻が起きることにな

    発注者,受注者の責任範囲を明確化しよう
    pro17-15_166
    pro17-15_166 2010/09/02
    発注と受注って言葉を合わせて、受発注って言うけど順番逆じゃね。と、思った。発受注…まったく、しっくり来ないけど。