変更管理

ISOについての時事的情報です。２月にISOがいきなりように（水面下での議論は進んでいたのですが）規格の追補版をだしました。日本の審査はどのようになるのか？という話が業界内では色々出ていたのですが、JABがようやくコメント出したのです。マネジメントシステム規格への気候変動に係る追補版発行についてと題して。詳細は以下をご確認ください。マネジメントシステム規格への気候変動に係る追補版発行について|公益財団法人日本適合性認定協会(JAB)通

前回のブログは、医薬品製造では、手順書を作成する規定があることを書きました。GMPでは、逸脱管理、変更管理、教育訓練、自己点検等が規定されていますが、従業員全員に周知徹底させることはなかなか、難しいです。例えば、5つ目の会社の私の上司は、教育訓練という言葉に抵抗を示していました。「社長に教育訓練なんてできっこない。いったい社長の人権費はいくらなのか知っているのか！！」というのです。社長に新人実習のような形式の教育訓練をすべきとは、私は一言も言っていません。あまりにも薬機法（当

【新刊】のお知らせ変更を制する者がプロジェクトを制す！変更に振り回されずに対処する方法https://www.kigyo-systems.com/note.html「変更」は、プロジェクトの混乱を引起す主要因です。スコープ変更、要件変更、コスト変更、日程変更などの様々な変更、特に想定外の変更は、プロジェクトを失敗に陥れる元凶と言っても過言ではありません。このような変更が一切無ければ、プロジェクトは計画通りに進み、何の問題も無いはずです。しかし、現実にはＩＴプロジェクトの７０％が失敗し

【非定常で失う稼働率】稼働率という指標があります。一定期間においてどの程度の稼働を継続できるか。システムの可用性を測るものさしとして使われたりします。計算式は（運転時間−故障時間）／運転時間これより稼働率が100%、つまり故障時間が０のシステムは、ありません。かなり稼働率が高いとされるサーバでは99.999（ファイブナイン）を確保しています。その場合の故障時間は、年間で約5分です。それぞれのシステムで達成すべき稼働率をSLA（サービス

スケジュールの変更に伴うタスク優先度付けで、担当者との認識合わせの大事さを感じました。そんな話。緊急度と重要度で優先度をつけるというのはよくやります。①緊急かつ重要②緊急だが重要ではない③緊急でないが重要④緊急でもなく重要でもない大抵がこのような優先度付けをして実行するのではないでしょうか。ただし、この緊急度と重要度は何に対してというのを考えてきちんとつけられていますか？各担当は作業（タスク）対してこの緊急度と重要度をつけて優先度をつけた場合自分にとっての（個人的な）優先度を

要望以上の付加価値「バリュー」を出せということを外資コンサルでは言われます。コンサルタントは想定を上回ることで顧客からみてバリューをだし、それが本人の価値として評価してもらうのだと。一方、プロジェクト管理として管理された中ではやるべきことをきちっとこなすことが重要になります。プロジェクト管理では、最終成果物を最初のPVで作り上げることができるようにコスト管理、スケジュール管理、リソース管理等々をしていきますので、予定からずれてしまうと変更管理を回し、予備コストをつぶしていくこととな

こんにちは。友原京子です。今日、社外のコンサルタントの先生からいいこと教わっちゃいました♪みなさんにも共有しますね。改善プロジェクトなどで、無駄をなくす検討を行うとき…「もしも、○○がなかったら誰がどう困るか？」って発想するとイイそうです。「もしも、○○がなかったら！」「もしも、この会議がなかったら？」「もしも、この手順を省いたとしたら？」「もしも、申請書からこの項目をなくしたとしたら？」「もしも、このサービスをなくしたとしたら？」意外と、「別になくても誰も困らない」って

大きな開発案件であればあるほど、管理手法にウォーターフォールが使われ、官公庁ではより顕著です。ウォーターフォールが良いとか悪いではないのです。でも、ウォーターフォールで進めると決めたならば、そのルールに則るべきだと思うのです。ウォーターフォールではそもそも工程ごとの成果物が明確でありその成果物を作成するためのコストを試算して、リソースとスケジュールを計画し実行していくように作られたプロジェクトライフサイクルです。マネジメントもそのライフサイクルをコントロールするために計画されます。

こんにちは。友原京子です。｢新たな価値を出せ」「イノベーションせよ」これ、良く会社の偉い人たちが言っていますよね。でも、新しい事を始める事だけが価値創出なんでしょうか？私思うんです。「やめること」も価値創出なんじゃないかって。大企業であればあるほど、無理に新しい仕事を増やして、かえって非効率を生んだり、あるいは誰のためにもなっていなかったり、そんな無理や無駄が生まれ続けていたりします。この間、自分のチームの定常ルーチン業務を、一つやめる事にしました。だって…やり続け

サービス要求、変更要求、要求実現。要求実現requestfulfillmentはサービス要求に応えるプロセス。v2ではインシデント管理や変更管理の一部として扱っていたが、v3で分離して明確化させた。サービス要求は、ちょっとした要求、変更。既知の整理された手順で対応できるもの。パスワード再発行や何々の情報頂戴とか。変更要求は言葉に出てこないけど、サービス要求の一つの形かな…従来の流れでいうと、インシデント管理、問題管理。変更管理、そして続きであるリリースと展開管理の順番かな。似たよう