ホーム / IT ガバナンス

IT ガバナンス

技術スキルはITガバナンスを効果的に主導するのに必要だろうか

組織にとってITガバナンスに対する強い関心が有益であるか否かを問わず、それは議論にはならない。効果的なITガバナンスを設置している組織は、市場シェアを増加し、財務を改善し、技術革新を増加し、組織の評判を増加することを経験することだろう。 1 COBITの作成を担当関連であるISACAは、ITガバナンスを「取締役会および経営管理」の責任とし、「…リーダーシップ、組織構造や、組織のITが組織の戦略とその目標を維持、拡張を確認するプロセス」を構成している、と定義している。2 この定義によると、ITガバナンスは単にITリソースの日常業務ではなく、それは、組織に価値をもたらすためにビジネス目標とITを整合させることにある。 ITガバナンスが非常に有益で、複数の幹部が含まれている場合、上級管理職の38%だけがITが支配されている方法を知っているのはなぜだろうか。 3 『ACMのコミュニケーション』に出版されたある記事には、「一部のITの専門家には誤って、ビジネスリーダーは技術スキルが不足しているために、ITを管理することができないと思っている。」と書いてあた。その記事は、現実には技術的な知識は実際に必要ではないことを強調し「ITがもたらす能力を理解したり、ITのより賢く、より効果的な利用によって有効化された新しく改善されたビジネスのスキルを計画するには、ITシステムの設計や構築、またはその操作方法の具体的な知識を必要としない。」という。4 さらに、その要点を証明するのに、その記事の2名の著者はこの概念を自動車と比較している。 誰かがタクシーのサービスを操作する場合は、車の設計の方法やどのように車を設計製造するかではなく、そのサービスの操作に使用される自動車用の機能と要件を理解しなければならない。 したがって、効果的なITガバナンスを主導するITスキルを必要とはしない。 タクシーサービスのアナロジーに戻ることにする  –  人は自動車を運転するために、そのデザインや製造を理解する必要はないが、完全に理解すべきものがいくつかある。さらに重要なのは、彼らが効率的に操作し、以下の如く競争力を維持するために理解すべきものがいくつかある。すなわち、 リソースの割り当て サービスに関連するリスクを管理する方法 健全なビジネス上の意思決定を行う方法 ブリッジポート大学の副学部長および技術管理部門のディレクターであるガドJ. セリグ博士によると、「ITガバナンスの成功は、方針、手続き、プロセスおよび技術よりも、リーダーシップや文化変容の十分な管理等の人的なスキルによって決定されることがより頻繁に起こるという。」5 ハードスキルは彼の仕事のうち、ITガバナンスに必要な必要なスキルの40%だけを占めていると報告された。これらは、以下のように学習するにはより簡単なスキルです。 方針 メトリック プロジェクト管理 リスク管理 状況報告 他の60%は、リーダーシップ、人、および他のソフトのスキルであり、そのうちのいくつかは、以下のようにより頻繁に経験を通じて学習されている。 効果的なコミュニケーション 信頼 完全性 チームの構築 変更管理 洗練されたITシステムを構築するために必要な特定のスキルとは対照的に、ITガバナンスは、リーダーシップ、意思決定、説明責任についての詳細である。 その要点とは? ハードのITスキルを持っていない企業幹部でも、まだ自分の組織のためのITガバナンスで成功することができる。彼らは絶対に臆病になって言い訳をすべきではない。ビジネスリーダーは、単に一般的に強いリーダーシップのために必要なスキルを有し、前方のビジネスを駆動するために効果的なITガバナンスモデルのビジョンと感謝を共有する必要がある。 (参考文献) 1http://www.isaca.org/Journal/archives/2005/Volume-2/Pages/JOnline-IT-Governance-Pass-or-Fail.aspx 2http://www.isaca.org/Indonesia/Documents/ITGovernance.aspx 3Weill, P. and Ross, J. How Top Performers Manage IT Decision Rights for Superior Results, Harvard Business School Press, 2004 4JUIZ, C., & TOOMEY, M. (2015). To Govern IT, or Not to Govern IT?. Communications of the ACM 5http://www.atilim.edu.tr/~mrehan/ISE511-Text.pdf

続きを読みます »

突発事象管理を始めるための6つの秘訣

突発事象管理(IM)はミステリーではありません。IT専門家であるジョーが述べているように、何故IMをするのかは、実際にそれを行うのと同じくらい重要なことなのです。それは必要性から来るものであって、単にプロトコルから来るものではないのです。ジョーは自分のブログの中でIMを始める上での正しいやり方と正しい理由について6つの秘訣を説明しています。 「聞こえがよい」と理由でIMをしてはならない。 多分既にIMを行っている。 IMをする理由を考える。 IMをプロセスとしてではなくサービスとして見る。 専門用語に注意する。 顧客の目線で捕らえる。 IMを満たすべきプロトコルとして捕らえると、このことが分かります。ITはIMを顧客に対して外部的に提供するものとして使うため、そのことが何故それほど大きな意義を有するのかを理解することがまず重要です。正式なプロセスというものがない場合でも、大抵のビジネスとそれぞれのIT部門は、パスワードをの再設定、機能停止、その他不都合なハプニング等々、不可避な事態に対応する必要が出て来るために何らかの形のIMが必要となります。 [「何故IT管理をしているのだろうか?」という質問に対する]回答が、「ITが故障したときに直すため」であるなら、その質問についてもっと時間をかけて、もっと真剣に考えてみることを勧めます。突発事象は、技術的欠陥やITサービスが利用できないことなどよりもそれ以上のことであることは明らかなことではないですか? ジョーはITをプロセスとして見るのではなくサービスとして見るように勧めています。プロセスというものは人がその背後に回り、そのプロセスを使って顧客に優れたサービスを提供するためのものです。さらには、ITには「突発事象」があってしかるべきものなのでしょうか?勿論突発事象というものはITの中で管理しているものなのですが、顧客の観点からすると、それらは問題又は故障ということになります。経験則から言えば、IT専門用語を決して顧客に押し付けることがあってはならないということです。さて、IMにすっかり夢中になってしまう前に覚えておかなければなならなことは、あなたがしたいことをするのではなく、お客様が本当に必要としていることを実行することだけということです。 原文(英語)を読むには: http://www.joetheitguy.com/2014/12/05/12-tips-for-getting-started-with-incident-management-part-1/

続きを読みます »

あなたにとって第一の文化的変化の原則とは何か

労働文化を変えると、注意が必要になる。あなたの従業員や同僚らは、必ずしも変化は恐れていないかもしれないが、強制的に変更させられることは恐れていることだろう。パール・スー(Pearl Zhu)氏は変更すべき障壁を克服するためのいくつかの提案を提供している。 変化の原則 リーダーシップ/役割の模範 通信 サウンド戦略/システム 思考トラスト/人間関係の管理 優れた役割の模範であることは、確かに望ましい文化的変化を生み出すが、最初にその変化に遭遇する人がその変化を受け入れても構わない、という姿勢が必要になるので、そこが状況がすべて重要になってくるところだ。指導者は組織全体を効果的に通信させることで変更しようとしている文化を学ぶ必要がある(つまり、話すより聞く、ということを意味する)。一旦指導者が求めている変更がどのようなものであるかを正確に把握すると、その後、従業員が希望する成果に沿って組織体制を設計することにより援助して、戦略に変えることができる。 そのプロセスはここで終わらない。文化的側面を操作して新たな目標に合わせるには、指導者は既存の基礎の上にそれを築き、一方、うまくいっている文化面は維持するように注意する必要がある。指導者にとって変更の最後で最大のハードルは、スー氏によると、変更を長い目で育てていくために信頼関係を得てそれを維持することだという。 信頼がなければ、人は潜在性を奪われ、バラバラになってしまい、問題について自由に話すことができなくなるので、成長の潜在性にアクセスすることはできない。不信感は、変更に直面する通常の障壁として受け入れる傾向があるので、多くの問題の根本的な原因ともなっている… 提案された変更が会社の既存の価値体系に反する場合は、でこぼこ道が待ち受けている。しかし、正しく変更した車で(それに有能なドライバー付きなら)、それは悪い旅行になる必要はない。 元の原稿(英語)はこちらからご覧ください: http://futureofcio.blogspot.com/2014/09/whats-your-1-culture-change-principle.html

続きを読みます »

何がスーパー管理者にするのか

サービスデスク管理者(SDM) は、一人で何役もこなすワンマン(ワンウーマンの場合もある)ITサービス管理の公正リーグだ。これらの管理者が成功するためには、完全な一式の能力を持っていることが求められる。IT野郎のジョーは、誰もがサービス管理者やコンサルタントを目指し、またCIOですらここで始める必要があると信じているほどだ。彼は偉大なスーパー・サービスデスク管理者が持つ無数の責任をバラバラにしてしまう。 手始めに、SDMは、完全に独立した株主グループや地域社会との関係を維持しつつ、その間でマルチタスクできるようになる必要がある。優先順位は、時刻表に基づいて決定されなければならず、その重要性を適切にスタッフに伝える必要があるのだ。 SDMは、そんな人々の感情を扱い、共感し、つながりを築けるようにする必要がある。ジョーはそんな役割が持つ重荷について詳しく説明しよう。 役割を理解する上で重要な要素は、それは役割が適切な人に為されていな時の様子に焦点を当てることだ – 例えば、多分技術的な能力はあるが、人の管理能力や関係管理能力、または、より広いビジネス状況との成果の理解や関心がない人。これが相乗効果となり、乏しい、あるいは不適切な能力不足の面で両方の災害の問題を引き起こしていることがある。 彼はのSDMが能力を表わす必要のあるより多くの領域をいくつか掲示していく。メトリックを操作し理解し、スタッフを動機づけ、開発し、交渉し、そのつながりを築き、文書による通信という様々な分野がすべてSDMに求められる。例えば、文書による通信に関しては、SDMは特に優れていなければならず、必要な言葉遣いで、正確で詳細な文書を書くことができなければならない。その一つの例は、作業指示書とビジネスに焦点を当てた更新では、別々の言語が必要とされる。 元の原稿(英語)はこちらからご覧ください: http://www.joetheitguy.com/2014/08/05/what-makes-a-super-service-desk-manager/

続きを読みます »

IT変更管理の恩恵

優れた変更管理が極めて重大であるにも係らず、それが実際に行われる必要がある時には、犯罪レベルほど酷く扱いを誤っているように思える。ジェフリー·ボウマン(Geoffrey Bowman) 氏は、物事がうまくいかないところと、それを再び正しく設定する方法の概要について説明し、自らのブログへの投稿でやる気のない態度を修正することを目指している。 あらゆる種類の混乱は、新しいプロセスへの飛躍を目指すか否かを決定する時は考慮しなければならない。変更管理を実装するITエンジニアは、そういう時期には、以下の事項を理解しておく必要がある。 変更がビジネスに及ぼす影響 影響される任意のアプリケーションの機能 ロールバック計画(失敗や休暇の場合) どの人からビジネスの変更を承認してもらうのか あなたが社内のITを使用しようが、外注人材を使用しようが、同じベストプラクティスと常識が適用される。ボーマン氏は、現在の管理プロセスと変更要求(略してRFC)のテンプレートを求めるべきであると言う。ITに変更管理のプロセスを順を追って提示させる時、彼らが実装していることを熟知し、問題が生じた場合には(比較的)ビジネスの保護が保証される。彼らの答が不十分である場合は、変更管理が改善しなければならないことが分かるというもの。 ボーマン氏は、あなたが次の質問をITにするように推奨している。 自社のビジネスにおいて、変更を認可する主要な人物は誰か。 当組織のための最近のRFCを示し、それを承認した人物をおしえる。 最近の変更の実行について、ロールバック計画は何であったのか。 ロールバックが必要な場合には、私に社内承認プロセスを示すことができるか。 元の投稿(英語)はこちらからご覧ください: http://geoffreybowman.com.au/2014/07/19/in-focus-it-change-management/

続きを読みます »

変更モデルの価値

変更はただ一定のものであり、P. ワイズ教授の説明にあるように、プロのITに変化を受け入れる価値を控えることはできません。ロス氏は以下のように説明しています: 変更管理プロセスの目的は、我々の現在の IT サービスの中断を最小限に抑え、有益な変更を加えうるあらゆる変更のライフサイクルを制御することにある。その目的は、価値を保護し、再作業を削減しながら、これらの変更要件に応じられるようになることだ。 ロス氏は、IT構造への変更について、変更の記録とリスク評価に併せて、ビジネス目標との整合の保証等

続きを読みます »

ITILにより定義された3種類の評価基準

組織は、製品の計画、プロセス、また性能を監視するために、所定の評価基準システムを設けます。収集されたビジネスデータは、プロセスの理解と向上のために使用されます。また、それはより優れたビジネス上の意思決定を行う際に、堅固な基盤として用いられます。著者マイケル ・スカボロー (Michael Scarborogh) 氏は、3種類の評価基準について説明し、それぞれの例を提示しています。 スカボロー氏による3種類の評価基準とは、テクノロジー、プロセス、それにサービスの評価基準である、と明言しています。

続きを読みます »

IT 部門は全く無用になってしまった

「無用」とは過酷な言葉だが、カリフォルニア大学のアーバインビジネス校のAcross and Senior Industry Fellow の最高経営責任者(CEO)Peter Hinssen氏は、現代のIT部門にはそれが適用すると考えている。さらに、Hinssen氏はビジネスコミュニティの多くの人々はCIOはお飾りに過ぎず、それ以外の何者でもないと見なしていることを示唆している。これは多くのIT部門がかつて持っていた力に欠如している理由を物語っているのかもしれない。要するに、Hinssen氏に

続きを読みます »

知識管理 101

知識について知るべき事があり過ぎるほど存在していることを知っていた者がいただろうか。Michael E. D. Koenig は、あらゆる角度から対象を捉えてその内外から対処し、知識管理 (KM)に関する情報の宝庫を一つの記事でまとめている。チャート、グラフ、参照も豊富で、それは今までのうち、1つのスペースにその被写体の最も包括的な外観を提供している。だから、鉛筆を削って新しい消しゴムを取って欲しい。授業は進行中なのである。 Koenig は、1994年の「知識管理とは、知識を捉え、分配し、効

続きを読みます »

問題管理: お金が無駄に使われていませんか?

典型的なIT組織では、顧客と歩調を合わせ連携することについて話し合いがなされることが常となっています。多くの場合においては、このような話し合いは多くのIT関係者が大きな部屋に集まって、それが何を意味するのかを「考える」ことを話し合うことになってしまっています。そうではなく、実際に明らかにされなければならないことは、ITの全ての関係者が共通の事業目的に向かって事業主と協働するための戦略を話し合わなければならないことにあります。 サービス管理の観点からは、成功を必ず成就することができるようにするためには、まず水面下で実際に起こっていることを分析することから始める必要があります。事業を次のレベルに持ち上げることのできる私たちの能力に影響を及ぼすような出来事をすぐに指摘しがちですが、そうではなく、本当に指摘する必要があるのは、問題の原因が何であるのかを指摘することにあります。ここに問題管理が話し合いの中に入り込む必要性が出てくるのです。 問題管理についての話し合いとは実際のどのような点であるのかを説明するために、例を挙げて見て行くことにしましょう。 架空のビジネス あなたの顧客の事業目標の一つは、ITを含めた全事業部門の残業代を削減することにあります。 あなたはさまざまな出来事を活用していますが、現時点では正式な問題管理のプロセスはありません。 あなたのITオペレーションチームは8週間のオンコールローテーションになっています。 直面する問題点 このサポートチームは、誰かがエラーをクリアしてサービスを再スタートする必要があるようなアプリケーションの問題が毎週サービスコールとして発生しています。 毎回の「サービスコール」は最低でも1時間のサービスコール請求になっています。 このアプリケーション問題は、毎週、現地時間の午後6時から午後9時の間(時間外)に少なくとも一回の割合でサービスコールが発生しています。 四半期末になるとこのサービスコールは週二回に増えます。 このことによる影響はあなたの分析にとってはそう見る限りでは最小限のものになっており、しかもこのようなマイナーな中断によるサービスコールで追加収入になっています。 このことは何を意味するでしょうか? このサービスコールの平均を想定すると、これはこの問題で一年間で55~60時間のサービスコールになります。このような時間は誰も注意を傾けるような時間ではありません-但しお客様以外ではですが。お客様にとっては、この問題のサービスは特別の問題点、即ちダウンタイムとなるだろうと思われるところまでサービスに対する期待度が落ちてきてしまっています。これはあなたにとっては事態が悪く見えてしまいます! 問題管理者、即ち、この問題のプロセスを円滑に進めることのできる人を投入する必要があります。 この問題を取り扱ってきたオペレーションチームと問題管理者が事態を話し合った後、次のような事実が浮かび上がってきました: 分析はこの問題を取り上げたが、大きな問題とは見なさなかった(各人にすれば8週間に一度の問題であったので)。 分析は、このアプリケーションの問題は各々発生し解決されていたことを認識していなかった。 報告はこの種の問題を「探し出す」ように設定されていなかった。 4.  チームには別のサービスコールの残業代も含まれていたため、この問題の残業代が注意喚起を呼び起      こすことにはならなかった。 5.  この問題に対して責任を負うアプリケーションチームとの話し合いでは、チームはこのアプリの最新版にはいくつかの問題点がある可能性があることを認識していたが、現時点までこの問題に関して誰からも何の問題も聞いていなかったことが示されている。 どこから始める必要があるでしょうか? 顧客が何を求めているかを知っていると思い込むことを止める必要があります。お客様と協働することです。 事業の利害関係者と定期的に会合を持ち、サービスが目標どおりに提供されているかどうかを確認する必要があります。 ITの左手側は、右手側が行うことを知っていると思い込むことを止めなければなりません。コミュニケーションが鍵となります。ITの中で定期的に会合を持ち、顧客サービスに影響を及ぼしている問題点について話し合いをする必要があります。「お客様の手助けとなるためにお互いどのように助け合うことができるだろうか?」という点がテーマとなるべきです。 お客様が自分たちの事業成果を実現することができるための手助けとなるようにITをそれに合わす必要があります。より賢く働くことであり、よりハードにではないのです。事業と協働し、事業の求める成果を理解し、それをサポートするためにITの目標を合わせることが必要です。現在進行しているプロセス(ここの例では問題管理)を更に精緻化することはシンプルでなければなりません。サポートプロセスの観点からどの領域が改善されるべきかを見極める必要があります。 ここに挙げた例は非常にシンプルな性質のものですが、大局的に見た場合、何をすることができるかが示されています。別のケースでは、単にコミュニケーションの仕方を改善し、仕事の進め方を単純化するだけで、容易に解決できる問題点を見つけ出し、顧客に対するサービスを改善することが可能とする場合もあり得るでしょう。

続きを読みます »

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.