以前、パソコンの4Sのお話をしました。今回は業務の4Sについてお話をします。
業務でITのブログ記事
前回は損益分岐点のお話をしました。今回は、標準原価と原価差異分析についてお話しします。なお、原価計算基準の流れでいくと原価の部門別・製品別計算や販管費の計算になるのですが、ここはまた別の機会にご紹介します。
前回は勘定科目のお話をしました。今日は原価計算基準からちょっと脱線して損益分岐点のお話をします。
前回まで3回にわたって、実際の原価計算方法の概要をお話ししました。今回は、項目分類についてお話をします。
前回に引き続き、実際原価の計算について個々の費目ごとに説明していきます。
前回に引き続き、実際原価の計算について個々の費目ごとに説明していきます。
前回は原価の分類について、いくつかの視点でお話をしました。今回は、実際原価の計算について個々の費目ごとに説明していきます。
前回は、原価の意味や概念をお話ししました。今回は原価の分類についてお話をします。
前回は原価管理の基本として、その目的をお話ししました。今回は原価計算のもとになる原価の意味や概念の説明をしていきます。
ちょっと前に原価管理について施工段階ごとでのポイントをお話ししました。今回は少しそれよりさかのぼってそもそも原価管理を行うための基本的な考え方を何回かに分けてお話しします。
最近、支援先企業でよく受ける相談に社内システムのデータを業務分析や業務改善に活用したいとがあります。売上情報や顧客情報、経理情報と様々な情報を加工して、経営判資料や業務資料に使うことはとてもいいことです。
建設現場でもコンクリートの品質管理資料や様々な材料業者からの納品情報を整理する際に複数のデータからまとめた形にしたいという話をよく受けました。
このようなときに真っ先に思い浮かぶのがエクセルでのデータ整理です。最初はピボットテーブルや集計機能で、それからちょっとした条件関数や検索関数でデータ整理を行える仕組みづくりを考えます。まとめる頻度が多く、手間もそれなりにあるとなるとマクロを導入するということも少なくありません。4年ほど前に、「自社内開発のススメ」といった話で同じような話をしました。エクセルのマクロは大変機能が豊富であり、簡易な自社システムの開発にはうってつけです。
前回まで原価管理のポイントについて、実行予算から竣工時の予実照査までお話をしてきました。広い意味でのIT(情報技術)であれば、これでいいのですが、せっかくですのでもう少し狭義のITとの関係をお話しします。
前回は竣工時の原価管理をお話ししました。未払金管理や竣工後の予算などついバタバタなりがちな時期だからこそ注意してほしい点について留意点を話しました。今回は竣工後の話をします。
前回までで施工時までの原価管理のポイントをお話ししました。原価改善の例とそのための情報の集め方について若手でもできる方法をお伝えしました。今回は竣工時のお話をします。
前回は、施工時における出来高管理のお話をしました。臨時支払と契約支払の月度管理と追加予算獲得の準備について話をしました。今回も引き続き、施工時における管理をお話しします。今回のテーマは、原価改善です。
前回は、調達までお話をしました。手配の種類ごとでの注意事項と共通となる取引ルールをまとめることの重要性を理解していただけたと思います。これで、工事を実行するための準備は完了です。これからはいよいよ、施工時における管理をお話しします。
前回は、実行予算の重要性と適切な実行予算を作成するために必要な歩掛の話をしました。今回は実行予算ができたあとの次のステップ、調達について管理ポイントをお話しします。
前回は、個別原価管理のお話をしました。施工計画を立て、個々の工事ごとに原価を管理することで、自社の得手不得手を見極め、利益を確保できる工事をできるだけ多く受注する仕組みづくりが重要だということでした。
建設業界は厳しい環境下におかれています。公共事業予算は削減され、民間の設備投資も一部を除き基本的には低調です。売上を確保するのはなかなか難しいです。
その中で生き残っていくために必要なことは経費を管理していくことで利益をねん出できる体質改善です。つまり、原価管理をしっかりやっていくことが最重要課題となっています。
経営資源をしっかり管理することは、経営上とても重要です。所有している資源を最大限活用することが売上をのばし、利益を大きくするからです。
最近、中小企業でよくお話を聞くのがベテランの退職による人材不足です。何年も前からわかっていたことなのに、ついつい後回しにしていたツケが一気に回っている状態です。
みなさん、トータルリワードってご存知ですか。直訳すると総合報酬となります。つまり、通常の報酬である金銭的なものだけではなく、非金銭的なものも含んで報酬というものを考えましょうということです。
前回、「見える化」の進み方の5つ目のステップとして、管理指標を用いた進捗測定と効果測定のお話をしました。得られた結果は
・実行の際の管理指標
・指標の測定基準
の2点です。今日は、いよいよ最後のステップです。
前回、「見える化」の進み方の4つ目のステップとして、ギャップ分析を行ったのち、根本原因の追究と対策立案のお話をしました。得られた結果は
・根本原因の明確化
・あるべき姿への対策立案
の2点です。今日は、次のステップをお話しします。
前回、「見える化」の進み方の3つ目のステップとして、目標の設定とスケジュール(期限)の設定のお話をしました。得られた結果は
・目標設定によるあるべき姿の共有
・目標実現のための期限とスケジュール
の2点です。今日は、次のステップをお話しします。
前回、「見える化」進行の2つ目のステップとして、現状と問題の細分化・分類のお話をしました。(「属人化の排除」を目的とした例で話を進めています)前回までで得られた結果は、
・現状の業務の一般部分と特殊部分の区分け
・課題の分類によるグループ化
の2点です。今日は、次のステップです。
前回、「見える化」の推進について、「属人化の排除」を目的とした例で話を勧めました。最初のステップは現状分析であり、そこで得られた結果は
・現状の業務の流れ
・属人化の問題点
の2点です。今日は、次のステップをお話しします。
以前、「見える化」自身は目的ではなく、手段であると述べました。そして、「見える化」を手段とする例として、6つの目的をあげました。
1.属人化の排除
2.ムリ・ムラ・ムダの排除(定量的な問題・課題)
3.定性的な問題・課題の認識
4.分業化・統合
5.IT活用への布石
6.情報共有
今回は、これらの目的を達成するため、どのような流れで「見える化」を進めるかをお話しします。わかりやすいよう、属人化の排除を例に話していきますが、他項目においても大きな流れは同じですので、全体像を把握していただきたいと思います。
企業での情報量が増えるにつれて、バックアップなどのデータ管理やハード・ソフト管理などの重要度が高まっています。しかし、中小企業では、専任者を置く余裕がないため、パソコンが得手な人間がボランティアでシステム管理をして、トラブルにはその限られた知識で対応し、うまく対応できないまま日々をすごしているとい
う状況が多いのではないでしょうか。そこで最近新聞や雑誌をにぎわしているのがSaaS(サース:Software as a Service)と呼ばれているネットサービスです。今日はこのSaaSについて少しお話をします。
前回に引き続き、ファイリングについて補足的な説明をします。
前回、基本的なルールは説明しましたので、今回は補足的なお話をします。
前回、ファイリングとは「書類の作成から分類・整理して保管し、期間が過ぎれば破棄するという書類運用のしくみ」ということで、中核になるパイプ式ファイルの作業的なポイントについてお話ししました。
今回は、ファイリングの基本ルールについてお話しします。
世の中、電子化は進んでも、なかなか紙データはなくなりません。むしろ、安易に印刷できるせいで増えたのではないでしょうか?また、以前は請負金とファイルの厚さは比例しており、100万円で1cmと言われたこともありましたが、今やISOやら法律強化やらで、請負金に関係なく、かなりの厚さの書類を要求されることがあります。紙データ管理がきちんとできず、困った状態になっている会社が多いのではないでしょうか。今回から紙データの管理、いわゆる「ファイリング」について何回かに分けお話しします。
最近、中小企業のご支援の際に人材活用や人材育成の相談を受けることが増えました。人件費を抑える中でいかに業務をスムーズにすすめるようにするかということが重要な課題となっているからです。また、中小企業での人事は中途採用が多い傾向にあります。即戦力を期待するからですが、そのために技術伝承が困難になったり、会社の一体感が熟成しにくくなったり、職場の核になる人が出てこなかったりします。
何より問題なのは、中途採用が多い会社ほど、長期的な経営戦略がなく、人材開発計画や教育計画がありません。結果として人材が必要な時は育成せずにますます中途採用に頼る傾向にあります。中途採用が悪いわけではありません。しかし、計画的でない中途採用は結果的に会社自体がうまくいかない要因となるということです。
IT活用による「見える化」が真っ盛りです。「激動する経済環境や社会情勢に対応するため、迅速な現状理解・判断が必要不可欠です」といった文言が、あちらこちらでうたわれています。確かに、この言葉は正しいのです。成功事例を色々紹介され、ITシステム導入によるメリットを強調され、その気になっている経営者も少なくありません。
しかし、導入すれば全員が成功するのでしょうか?答えはNOです。知らず知らずのうちに、勘違いをしているからです。今回は「見える化」のよくある勘違いについてお話します。
昔、「動かないコンピュータ」という言葉がはやりました。使えなくなったシステムや思ったより成果が上がらなかった仕組みのことをいいます。しかし、最初は動いていたのに「動かなくなった」ものもあります。どんなに立派なシステムを構築しても作り上げた瞬間から陳腐化が始まります。そのうち、あちらこちらでうまくいかないことが出て、やがて最初の盛り上がりがうそだったかのように使われないシステムになっていきます。これがシステムの寿命です。今回はこの寿命について少しお話します。
前回までで、情報発信の仕組みまで紹介しました。発信の仕組みは、システム的なものだけでなく、発信者へのインセンティブ(やる気を出させるもの)も組み込むことが重要だと理解していただいたと思います。さて、次はいよいよ利用者に対する仕組みづくりです。
前回までで、自社情報の棚卸しと共有メリットが明確になったとします。つまり、メリットを生み出す必要な情報を、必要な分だけ共有できる仕分けができた状態です。今回は、その情報入力を発生させるための仕組みづくりをお話します。
前回、自社のIT成熟度(ITをどの程度利活用できているか)によって、共有方法の仕組みづくりや導入ステップに違いが出るという説明をしました。自社のIT成熟度をきちんと判断するのは難しいですが、目安を設けることで導入時の混乱を最小限にすることはできると思います。今回は、情報共有の基になる、自社情報と共有の意味についてお話したいと思います。
今回は、一歩踏み込んで、より効果的に情報共有を成功させるための環境づくりの話をします。
前回は、「会社の雰囲気作りと経営方針の見直し」を行い、情報共有の基盤づくりを目指す話をしました。物理面ではなく精神面での整備が大切です。
さて、基盤がある程度出来たら、次は、利用しやすい環境を創り出すことです。
前回、「情報共有の失敗する理由」として下記の5つを挙げました。
1.情報共有が会社風土になじまない。
2.利用しやすい環境になっていない
3.情報共有で解決すべき問題点が見えていない
4.発信側を作り出す仕組みがない
5.コミュニケーション環境ができていない。
今回から、何回かに分けて、情報共有を成功に導くためのポイントを紹介します。
会社の情報共有が重要だといわれて久しいですが、なかなかうまくいっているという話は聞きません。むしろ、グループウェアやナレッジマネージメントソフトを入れたのにちっとも成果が出ないと嘆いている方が多いです。なぜでしょう。
いろいろな問題点がありますが、以下の5点に集約されると思います。
今年3月31日に、国土交通省 CALS/ECアクションプログラム2008が発表されました。いよいよ、全市町村へのCALS/EC導入に向けての最終プログラムです。このプログラムに伴い、CALS/EC推進会議の第1回が行われ、電子納品ガイドラインも改訂されました。
第1回CALS/EC推進会議の資料に、現状の問題点が分かりやすく書いてありました。いくつか紹介すると
中小企業の経営者の方と、将来像の話をすると「うちには固有の技術や特許がないからだめだ」と、お嘆きになることがあります。確かに他が真似できない技術をもっているのは素晴らしいことです。しかし、技術は日進月歩。いつまでも同じ技術では、いつか必ず他企業に抜かれます。しかし、だからと言って、そのために多額の研究開発費をかけるのも、中小企業にはとても難しいことでしょう。
では、どうするのか。業務手順の改革を行うことです。技術力では大きく変わらない企業でも、業務改革によって大きな競争優位をもつことができます。
以前、はかり方をいろいろな視点でみることが大切であると述べましたが、それは定性的な見方と定量的な見方という概念でした。今回はもう少し具体的な視点から、お話したいと思います。
PQCDSME
をご存知ですか?建設業の方であれば、QCDSといったほうがピンとくるかもしれません。業務を潤滑に遂行するために意識すべき視点としてよく言われるものです。以下、具体的にお話しましょう。
前回、「QC7つ道具」と呼ばれるものを紹介しました。これは、数値が測定できる定量的な指標に適用できるものです。しかし、業務改善は必ずしも定量的でないもの、いわゆる定性的なものもまとめていかなくてはいけない場合があります。今回は、そのような時に使える「新QC7つ道具」をご紹介します。(ただし、7つのうち、2つは定量的なものです。)
エクセルでできるグラフを中心に、様々なグラフの紹介をしてきました。グラフは端的に物事を伝えることが出来ますし、多くの方に短時間で一定の情報を伝えるには、必要不可欠だと思います。
さて、今まではできがった指標をまとめるという視点からグラフを紹介しましたが、今回はもう少し上の視点に立ち、業務改善で活用したい図表をご紹介します。QC7つ道具と呼ばれ、7つの図表によって、さまざまな品質管理を支援するものですが、業務改善にも使えます。
前回、よく使う以下の4つのグラフの役割を紹介しました。
・円グラフ
・折れ線グラフ
・棒グラフ
・散布図
上記の4つのグラフを使えば、大抵の管理指標は表現することができると思いますが、もう少し最適なグラフを知りたいとのリクエストで、今回はさらにいくつかのグラフについて紹介します。なお、これらのグラフはすべてエクセルで表現できるものです。
前回、業務改善のみせ方として、指標のまとめ方についてお話しました。何らかの加工(換算、比較、集計、関連等)をほどこすことで無味乾燥したデータが生きた情報に生まれ変わるのです。
さて、今回は、この生きた情報をよりよくみせるグラフの使い方の基本についてです。
まずは、よく使われるグラフの種類と役割です。主なものは、円グラフ、折れ線グラフ、棒グラフ、散布図の4つです。当然、それぞれに適した役割があり、表現したい目的に合致しないグラフは、せっかくの生きた情報を殺してしまいます。それぞれの役割を把握しましょう。
前回、業務改善のみせ方として、「見せ方」「診せ方」「魅せ方」について述べました。その中で特に、改善状況がわかるものとして「指標」を取りあげ、みんなが見たいと思う工夫をしましょうという話をしました。
今回は、その指標のみせ方の工夫として、指標のまとめ方についてお話します。
前回は指標の設定における2つの視点についてお話しました。
具体的にいうと、
・数値で表せるものと表せないもの
・ある期間の終わりでの指標とその途中での指標
です。今回は、はかるタイミングとはかったものの記録方法についてお話します。
今まで十数回にわたり、業務改善のはじめかたや育て方、探し方をお話してきました。業務改善を探して、はじめて、育てるという一連の流れのヒントが提供できたのではと思います。
今回は、改善の進捗を目に見える形にする方法についてです。つまり、業務改善の測りかたです。このはかりかたには大きく2つの視点があります。
今回は、IT活用に視点を置きます。今まで、あえてIT化というキーワードを避けてきました。それは、先にIT化を意識すると、業務の本質を見ることなく効率化や省力化のみにとらわれてしまうからです。
とはいえ、IT化なしには効果的な業務改善ができないのも事実。しっかりと業務を見直した上で、必要に応じたIT化を図ることが大切です。(番号は前号からの続きです。)
業務改善すべき箇所を探す方法についての2回目です。業務改善の探すときに、今まで当たり前だと思っていたことが本当に当たり前なのかと考えることが大切です。「習うより慣れろ」という言葉がありますが、業務改善ではこれは間違いです。習えるような形になっていないものは「あやしい」と思いましょう。番号は前号からの続きにしています。
これまで、業務改善のはじめかた(全3回)と業務改善の育て方(全7回)で、業務改善に対する基礎知識をお話してきました。
今回からは、基礎知識を踏まえ、業務改善すべき箇所を探す方法について述べたいと思います。
今回は、会議についてお話します。会議は、業務改善の対象として最も効果が上がりやすいものですが、意外と手つかずです。というのも、関係者の力関係がはっきりしており、トップが変えようとしない限りなかなか触れられないからです。
それでは、トップが言わないとだめなのか?そうではありません。工夫次第で、改善の効果をトップに伝えることができます。自分が主催できる会議に適用すれば効果は大きいでしょうし、その実績をもって上に提案することが可能になります。
では、会議を実りあるものにする5つのポイントをお話しします。
前回、オフィスの環境改善(空間の改善)についてお話しました。今回は、時間の改善、つまりワークフロー管理がテーマです。
個々のスケジュール管理については、
「工程管理はしっかりしているぞ!」「自分のスケジュールは頭に入っている」
という声が聞こえてきそうですが、スケジュール共有に関しては、できているという声はあまり聞こえません。つまり、部署や現場をまたぐ業務の流れ(ワークフロー)管理ができていないのです。
たとえば、現場単位での工程管理はできているとしても、複数現場を見通して工程管理している方はいるでしょうか?
さて、「業務改善の育て方」も5回目になりました。今回は、業務改善をサポートする周辺環境、つまりオフィス環境の改善がテーマです。
前回、席替えの効果について述べましたが、座るところが変わるだけでは効果のほども半減です。席替えする以上、いろいろ見直しをしてからでなくてはいけません。
それは、オフィスの2S(整理整頓)です。
前回は、返事に期限を設けるワンデーレスポンスの話をしました。もちろん、メールやグループウェアなどITツールを使うと効果的なのはいうまでもありません。
今回は、業務改善の最大の敵である抵抗勢力についてお話したいと思います。一口に抵抗勢力といっても、いろいろな方がいらっしゃいます。よくある3つのタイプを考えてみます。
1.業務改善で慣れた手順がなくなる
2.業務改善で自分の地位や権限がなくなる
3.業務改善で自分の仕事がなくなる
では、順に傾向と対策を見ていきましょう。
前回、業務改善を進めるにあたっては、以下の3つを念頭においての意識改革が必要であるとお話しました。
1.参加意識をもたせる(明日は我が身)
2.お客様への意識をもつ(業務はみんなつながっている)
3.コミュニケーションを増やす(世界はひとつ)
意識改革を進めながら次に行うべきは、期限改革です。何事にも期限を切る。それも大きな期限でなく、小さく期限を切って相手や周りに周知徹底します。これが業務改善を育てるにあたって必要であり、当たり前のことですが、できていない企業がとても多いのです。
前回業務改善の育て方として、下記の3つの条件の下にプロジェクトチームをつくり、進めていくことをお話しました。
1.小さなテーマ
2.複数部署
3.社長宣言
これらには経営陣が深く関わる必要があり、経営陣の協力なしに成功はありません。しかし、当然のことながら、業務改善の主人公は社員です。社員が自主的かつ積極的でなければ、プロジェクトチームの解散と同時に業務改善も終了してしまうでしょう。そこで、業務改善の育て方の2つ目の重要な点として、意識改革を並行して行うのです。
これまで3回にわたり、業務改善の始め方のお話をしました。
・他社事例を学ぶ。
・ブレーンストーミングを行う。
・IT化は最後に行う。
まだ他にも留意点はありますが、とりあえず始められる段階になったとして次のステップに入ります。今回から、業務改善の育て方をお話していきます。
これまでに、業務改善のはじめかたとして、以下の2点をお話しました。
・他社事例を学ぶ。
・ブレーンストーミングを行う。
今日は少し視点を変えて、必ず意識していただきたいことをお話します。
「IT化は最後の手段とし、安易に使わない」ことです。タイトルが「ITでらくらく建設業」なのにそんなこと言うなんて?と言われそうですが、本当にらくをするには、無駄なITをしないことも重要なのです。その理由を説明しましょう。
前回、意識改善を始めること、そのためには他社事例を調べたり、見学したりすることを勧めました。もちろん、これだけで意識改善は図れません。漠然と「他社はいいなぁ」と思って終わりです。
他社見学や事例調査と並行して行うべきなので、ブレーンストーミングを用いた会議です。テーマは業務改善であるのが理想ですが、まずはどんなテーマでもいいですから、話しあえる環境を作りましょう。そのためには、ファシリテーター(議題を促進させる人)が必要で。誰かをあちこち行われる講習会に参加させてもよいのですが、外部専門家に依頼することで一定の緊張感を出すことも必要でしょう。
3回ほど前に「業務改善ができないのはなぜか」を取り上げました。ポイントをまとめると
・本当の問題意識が欠落している
・コスト意識を全社員でもっていない
・危機感が共有できていない
・業務改善のメリットがうけれない
の4つで、これらは単独ではなく複合して業務改善の大きな壁となっています。
では、業務改善をするにはどうすればいいのでしょうか。今回は業務改善のはじめかたをお話します。
通算200回記念というわけでもありませんが、最近の建設業での支援を通じて感じていることをお話します。
問題1:管理(コントロール&マネージメント)不在
特に感じるのが、管理不在です。建設業法の改正により、管理体制の強化は進んでいるように見えますが、建設現場での雰囲気は決していい楽観できる状況ではありません。
最近、みなし管理職の問題がクローズアップされていますが、逆に、部下なし管理職の急増に頭を痛めている企業もあるようです。高度成長期時代の大量雇用のツケで、それなりの役職につけた方を役職そのまま(当然給料もそのまま)に部下だけ新しい管理職にわたすようなことが行われています。「窓際族」のような言葉もありましたが、中途半端な成果主義の導入で窓際に座っている必要もなく(勤務時間が自由であるため)、出社状況も比較的緩やかな管理職を雇っている会社があります。
日本では管理職をヘッドハンティングされても困らないが、実務者に辞められると困る。米国では実務者はいくらでも増減出来るが、管理職は簡単に変えられない。こういった話を聞きますが、日本の管理職の実態をよくあらわしていると言えるでしょう。管理職とは、時間外労働をただで出来る役職であるというのが経営者の考えなのでしょう。
景気は下向き、世界情勢はますます厳しい状態で、会社が生き残るためには効率よい業務が不可欠です。しかし、「言うは簡単だが行うは難し」なのがこの業務改善です。やればいいのにやれないのはなぜでしょう。
多くの中小企業が業務改善の必要性を感じながらも、結果的に着手できていないのは、目の前の仕事を消化するので精一杯だからとよく言われますが、実際は違います。
これから、私がいくつかの会社を訪問する中で感じた理由をお話しましょう。今回は、「意識」を中心に据え、問題点を述べます。
IT活用の進め方の最終回です。今までのステップで目的が明確になり、業務手順も明らかにでき、成熟度も把握した上で教育体制も整った状態になるはずです。外堀はほぼ埋まった状態です。あとは、本丸を攻めるだけでしょうか?
まとめの意味もこめて、営業情報の共有を例に流れを確認してみましょう。
前回に引き続き、IT活用の進め方について述べます。お話してきたように、ステップを踏むことにより、目的がはっきりして業務手順も明らかにできたとします。
もちろん、業務そのものも最適化、標準化され、IT化しやすい状況になっていなければなりません。この状態ではじめてIT化のスタートラインに立てたことになります。逆にいうと、この状態になる前にIT化をスタートさせたとしたら、確実に無駄な投資が発生することになるでしょう。
さて、スタートラインにたった状態で行うべき次のステップは、自社の成熟度レベルの把握です。今まで業務の視点を中心にお話していましたが、ここからは社内のIT活用の視点も加えて見ていくことになります。成熟度診断にはいろいろなものがありますが、簡易なものをご紹介しましょう。
前回、IT活用の目的をしっかり持つためには問題点を明確にすることが肝要というお話をしました。目的をしっかり持たねば、IT導入が目的になってしまい、導入完了後は知らんふりという、ベンダーさんだけが喜びそうな結果が待っています。
さて、目的が明確になったとして、次は業務手順の確認についてですが、ここにも大きな壁があります。
多くの会社では、属人的な業務がはびこっています。ISO9001取得企業ですら、全業務を対象にしているわけではないので、問題を抱えている場合が少なくありません。SOX法導入に伴い見直しをかける企業も増えつつありますが、あくまで上場企業スタートですので、関連企業としての中小企業まではなかなか及ばないでしょう。
まずは業務のたな卸しです。目的の対象となる業務に絞ってから関連業務を洗い出すことが大切です。そして、例外処理をどこまでシステム化するのか、そもそも今の業務があるべき姿なのかを考え直すことも必要です。
前回、IT活用の基本として「ITは道具である」という心構えをお話しました。また、その考えを社員全員に受け入れてもらうには、時間をかけて業務改善と意識改革を進めていく必要があることを述べました。
今回は、心構えができている(もしくは準備し始めた)段階であることを前提に、IT活用をすすめるためのポイントをお話します。
それは、つまり目的を明確にすることです。それも会社全体での目標と整合性がとれていることが肝要です。部分的な業務改善をあっちこっちバラバラの方向でやっていると、効果がでないどころかお互いのシステムで足の引っ張り合いになるおそれもあります。
前回、IT活用が失敗する理由として、5段階に分けてそれぞれの理由をお話しました。具体的には
1.目的が明確でない
2.業務手順が明確でない
3.業務手順の見直しがない
4.自社のITレベルを履き違えている
5.語句や意味の統一ができず、部分最適になっている
です。ITインフラ(LANやインターネット、パソコン)は、世界レベルでもかなり進んだ環境でありながら、業務効率やIT活用度は落第生状態なのです。
今回から何回かにわたって、IT活用レベルを上げ、業務改善を進めるにはどのようにすべきかをお話していきます。
「IT活用がうまくいかない」、「世界的に見て日本のIT活用レベルは低い」などの声が、新聞を賑わしています。実際、様々な分野において、日本はアジア諸国に追いつかれ、追い越されています。少子高齢化が進む中、IT活用は今後ますます重要視されていくでしょうが、このままでは勝ち目がありません。
今回は、私がいろいろな企業を訪問し聞いてきた中から、共通すると思われる「IT活用の失敗理由」を述べます。活用レベルの低い状態から順に、挙げてみました。(最初のほうほど、問題が大きいと言えます。)自社の状況がどこに当てはまるかを考えてみてください。
今回の話は、少し難しいかもしれませんが、会社を存続するためには非常に大切なことです。よろしくお願いします。
以前、OJTの話をしたときに「暗黙知」と「形式知」の話をしました。これはハンガリーの哲学者マイケル・ポランニーが提示した言葉ですが、「暗黙知」とは経験や勘に基づく知識のことで、言葉などで表現が難しいもの。「形式知」は文章化、図表化などによって説明、表現できる知識を指します。
建設業に限らず多くの経験産業では、暗黙知を形式知にする試みがなされてはいるものの、うまくいっていません。特に日本では、「あうんの呼吸」「師匠の技は盗め」的な部分が根強く、形式知を嫌う風潮も少なくありません。
以前、ホームページ(企業サイト)の役割について説明した際、役割に応じ
てサイトの内容も変わることを述べました。あれから半年ほど経ち、インターネットでの動きは大きく変わってきています。企業サイトをブログで作るビジネスブログが増えました。今回はこのビジネスブログについてお話します。
システムの自社開発と聞いて何を連想されますか。中小企業では、おそらく「自社オリジナルの機能をシステム開発会社に依頼する」こととお考えでしょう。これが少し大きな会社になると、「自社のオリジナルの機能を自社システム部で開発する」となります。
最近、アウトソーシングとして、いろいろな会社機能を外部委託出来るようになりました。情報システム部、特に開発部門は、最初に外出しのターゲットになっています。しかし、真に強い競争力を持つ会社は、そうではなさそうです。自社の競争力を最大限に生かすためには、自社の業務を熟知している社内の人間が開発するのが最良とわかっているからです。
中小企業において、業務改善がうまく進まない理由の一つが、業務手順が明確でない・経験が暗黙知(形になっていない知識)であることを以前に述べました。この問題は、業務に対する意識改革なしでは解決しません。
日本では、業務に対して感情論が大きすぎるように思います。
SLA契約も無事に済み、いよいよシステム開発に着手します。あとは突き進むだけ!・・ちょっと待ってください。開発予算の見直しはできていますか?
「だって、契約はすんだから開発費はわかってるよ」「変更の予算も見てるから、ある程度の仕様変更も大丈夫」とおっしゃるでしょう。
はい、システム開発の依頼分はOKです。では、依頼していない自社部分はどうですか。
前回までで、システム開発の契約完了まで説明しました。今回は、その後、つまり開発時のポイントについて述べます。そのために必要なのが開発版SLA(サービス基準契約)です。
契約といっても、この契約は前回述べた開発前の約束事項ではなく、開発中の約束を決めるものです。実際には、前回の契約と連続して行う場合が多いですが、これを中小企業で締結しているケースは非常に少ないと思います。以前紹介したリンク集にサンプルがありますので、詳しくはそれをご覧いただくとして、今日は契約のポイントをお話します。
私自身、RFPとまではいきませんが、システム計画書を策定して何社かのベンダーに見積依頼したことが何回かあります。その際、実績があり仕事を取りにこようとする会社は、必ず経験者を同席させるか知識のある営業を表に出してきます。また、こちらが依頼した以上のものを持ってくる場合が多いです。提示される予算はこちらの希望枠内か+α程度ですから、こちらもその気になる場合が多いです。逆に、実績獲得のために低価格で提案してくるところもありますが、根拠をきちんと示さない社はあとで必ず追加予算を要求してくるものです。
中小企業では、多くの場合、機能を満たせばよく、他社との差異化を求めるシステム開発は少ないものです。よって、パッケージをベースにいくつかのカスタマイズ、アドオンを行うことと業務手順を若干見直しすることで目的を達成するのですが、そこまで踏み込んだ提案をするベンダーは稀です。
前回に引き続き、システム開発に必要な知識をお話します。前回は、ITベンダーへの要求であるRFP(提案要求書)の作成までお話しました。今回は、ベンダーへの依頼と選び方についてです。
「ベンダー?知らないよ」「どこに行けばわかるの?」という方も少なくないでしょう。
前回の要件定義編では、要件定義する際に行うべき4つのことを書きました。
・画面イメージをつくる
・用語の定義
・利用者の特定と調整
・他システムとの整合性(会社の全体像を意識する)
しかし、これだけではITベンダー(※ベンダーは日本語で売り手という意味)への情報がまだ不足しています。できれば、上記の4つ以外のものもまとめましょう。これらはRFPと呼ばれ、ちゃんとした意味があるのです。
ほとんどの中小企業では、システム開発を知り合いのITベンダー(現行システム導入会社、知人経営等)に依頼するパターンが多いと思われます。しかし、本当に会社に合っているのか、低コストでできているのか。1社ではわかりません。ましてやITは日進月歩ですから、知り合いの会社が追随しているかも判断できません。よって、複数のITベンダーに見積りと提案書を出してもらうことが重要です。
ところが、この依頼のために何度も同じ内容を説明するのでは大変ですし、口頭だと同じように伝えられない場合もあります。そこで、RFPをまとめるのです。
前々回の成熟度の話、その前の業務プロセスの「見える化」において、システム開発や導入の前に行うべきこととその重要性について述べました。簡単におさらいすると、無駄な投資をしないためには無駄なシステムは作らないということ。そのためには
・今の業務手順は、本当に無駄がないのか(業務の「見える化」)
・今の従業員のレベルは、システムに対応できるのか(成熟度)
をしっかり把握しておくべきです。残念ながら多くの企業では、この前準備がほとんど出来ていないままに、開発に臨んでいます。また、システム開発会社(ITベンダーとも呼ぶ)も、企業の要求を鵜呑みにするか、「今の予算では出来かねます」と突っぱねてオーソドックスな仕組みを提供します。つまり、企業要求
そのものがきちんと精査されることは非常に少ない状況になっているのです。
結果的に、「こんなはずではなかった」「ITベンダーが悪い」などと責任のなすり合いで、プログラマーが懸命に作ったシステムは、部屋の片隅に追いやられるのです。そこまではいかずとも、使わない機能がてんこ盛りで使いづらいとの話も多く聞きます。
そこで重要なのが「要求定義」です。
昨年話題になった言葉で、Web2.0というのがあります。これは、特定の規格や標準をさしているのではなく、従来にない新しい形のインターネット上のサービスや動きの総称です。代表的な例をあげるてみましょう。
今まで、IT教育運用計画策定やIT導入、利用時のポイントとして「身の丈にあった」というキーワードを使ってきました。また、ITと業務のバランスがとれていないと効果的な成果はあがらないこと、費用対効果を見るためには導入前と導入後を比較できる指標が必要であることも述べました。
これらのひとつの回答が「成熟度」ですが、「成熟度って目安ってあるの?」「成熟度を上げるってどういうこと?」というの質問が多くあります。そこで、今回は「成熟度」について説明します。
IT計画策定で、業務プロセス(手順)が明確でないとワークフローシステムの導入は難しいと書きました。これはワークフローシステムに限ったことではなく、IT化を進める上で一番重要なのがこの業務プロセスの「見える化」です。
中小企業で、システムの導入やシステム開発の相談を受ける際に、まずぶつかるのがこの業務プロセスについてです。会社全体のシステムや業務間連携が明確になっていないのはやむをえないにしても、業務プロセスが不明瞭なのは致命的です。
前回のWindows98 については、各方面からいろいろな話を聞くことが出来ました。前回も述べましたが「仕事で使っているパソコンがWindows98 でどうしたらいいのか困っている」、逆にサポートする立場として「Windows98 をはずす時期はいつ頃にすればいいのだろうか」、また、「個人で持っているパソコンを何とかしたいがいい知恵はないだろうか」等です。
WindowsVista(ビスタ)が来年1月ごろ発売になるので、そこがひとつのきっかけになると思います。サポート契約更新や新規購入等も、来年の1月を目安にご検討されることをお勧めします。(ソフトの購入は春ごろが目安になると思います。動作保障に時間がかかるためです)
さて、今回はホームページの役割についてです。最近は、中小建設業もホー
ムページを持つことが増えています。しかし、目的が見えない、役割を意識していないものも少なくありません。また、それに見合った金額を投資していないもの、逆に投資しすぎと思えるものもあります。そこで、ホームページの役割と費用についてお話したいと思います。
ホームページの役割は大きく3段階に分かれます。目的を営業方面に限って考えると
1.名刺
2.パンフレット
3.営業マン
最近、Windows98 のサポート終了(2006/07/11)に伴うシステムの更新相談が増えてきました。「2000年問題の際に導入したシステムがWindows98 ベースなので、保守契約が更新できないといわれた。どうしたらいいのか?」という相談です。
今回は、このウィンドウズのサポート期間に伴う問題点についてお話します。
会社の技術力、営業力、IT活用力を向上させるためには、教育が重要です。以前、IT教育運用計画の策定でもお話しましたが、社歴や職歴に応じた計画をしっかり策定し、適切な運用を行う必要があります。残念ながら、ここにマンパワーを割くことに抵抗のある経営陣は少なくなく、ほとんどの中小建設業で計画が未策定のようです。
では、そのような企業ではどうやって技術伝承や企業力UPを行っているのでしょうか。
最近、セキュリティの話題が非常に多いですね。情報関連にとどまらず、犯罪や不正などに対するセキュリティの話も多く出ています。
さて、セキュリティを日本語に訳すとどうなるかご存知でしょうか。辞書を引くと一番最初に出てくるのが「安全」で、それ以外に「防衛、担保、保安」などがあります。私は今まで「防衛」という意識が強かったのですが、実は「安全」のほうがしっくりくるとわかりました。
ところで、建設業で一般に使われている「安全」を英語にすると、どうなるでしょう。そう、「セーフティ」ですね。では、「セキュリティ」と「セーフティ」の違いは何でしょうか。実はここに、情報に対する安全対策の意味が隠されているのです。
業務の効率化を考えるとき、意外な盲点が会議です。
「そりゃ会議は業務ではないもの」、「営業会議は重要だからね」という方もいらっしゃるでしょう。いっぽう、会議の効率化を図るという名目で、テレビ会議や電子掲示板などIT化の例も聞きます。
しかし、思ったような成果が出ないことが多いようです。なぜでしょうか。
そもそも、会議とは「関係者が集まって相談をし、物事を決定すること。」ですが、ちゃんとそのような会議になっているのでしょうか。報告事項を連絡し、それをただ聞いてるだけで何も決めてはいない「報告連絡会」や、主催者が思いのたけをひたすら述べて無理やり合意を取りつける「独演会」になっていないでしょうか。これらは、IT化以前の問題であることはいうまでもありません。
前回に引き続き、日本版SOX法についてお話します。日本版SOX法とは、内部統制に関する報告を義務付けるものであり、従来以上にしっかりとした内部統制が求められます。内部統制の目的としては、以下の4つがあげられています。
・業務の有効性・効率性
・財務報告の信頼性
・法令等の遵守
・資産の保全
6月7日、「日本版SOX法」のもとになる金融商品取引法が成立しました。この法律は、証券取引法などの一部を改正するもので、「村上ファンド」のような投資ファンドに対する規制を強化するような株取引に関するものだけではなく、企業の内部統制に関する報告書を義務付けし、四半期決算の法制度化など企業に対しても今まで以上のきちんとした情報開示が求められるようになります。
対象は上場企業、2009年3月期の決算からとなっていますので、中には「じゃ、うちには関係ない」と思われる方があるかもしれません。しかし、私は決してそうではないと思います。
m95 IT計画策定のポイントから4回にわたり、IT計画策定に関するポイントや注意事項を説明してきました。今回はその補足としてITリスク管理の話をします。
今回はIT計画策定の第3弾。IT教育運用計画の策定に関してです。
IT教育運用計画とは、社員への集合教育、OJT、サポート体制の運用を含めた教育運用に関する計画です。教育で知識を与えるだけでなく、試験やアンケートによる状況確認といったフォローも含まれます。
システムは使われて初めて効果が発揮されるものです。高価なハード、最新のソフトを導入しても、使う側の準備ができていなければ、宝の持ち腐れ。「そんなことは知っているよ」という方が大半でしょうが、世の中にはなぜか「動かないシステム」が少なくありません。
IT計画策定の第2弾、ITインフラ計画の策定に関してお話します。
ITインフラ計画とは、各社員への端末(PC、携帯)やサーバー群、ネットワークを含めたハードウェアに関する計画です。ネットワークの内容が大きい場合は、IT機器調達運用計画とネットワーク計画にわけて策定します。
パソコンや周辺機器の選び方は「現場でIT」のG012?G023を、現場でのネットワーク構築は同じくG026?G028で紹介していますのでそちらを参照していただくとして、そこでお話したポイントを踏まえて計画策定の注意点を3つ挙げます。
前回、IT計画には以下の3つがあることをお話しました。
1.ITシステム計画
2.ITインフラ計画
3.IT教育計画
今回はこの中のITシステム計画の策定についてです。
ITシステム計画とは、市販ソフトウェアも含めた企業内でつかうアプリケーションソフト及びシステムに関する計画です。実際には、市販ソフトの購入計画と自社開発のシステム運用計画に分かれることになります。
前回、教育とシステムのバランスについてお話をしました。そのまとめとして、「システムと教育のバランスを意識した計画・体制づくりがIT化の重要なポイント」ということをいいましたが、今回はその計画策定のポイントについてです。
前回、ITリテラシーのお話をしました。情報技術を使いこなす力として、これからの建設業には必須と思われます。ITリテラシーを向上させるポイントは、以下の二点でした。
・管理職へのITリテラシー教育
・継続的な教育支援体制の確立
ところで、よくある質問が、「ITがこのまま進んだら、教育なしで簡単にできるソフトやハードが出てくるんじゃないの」というものです。今日はこれにお答えする形で、教育とシステムのバランスについてお話したいと思います。
ITリテラシーという言葉をご存知ですか。リテラシーは読み書き能力のことで、ITリテラシーとは情報技術を使いこなす能力ということです。
一般的には、パソコンの使い方を覚えていくことが「ITリテラシーの向上」といわれます。しかし、はたしてそうでしょうか。確かにパソコンをより上手に使いこなすことは重要です。電卓と紙と鉛筆でやっていた表が、表計算ソフトを使えば、効率よくミスなくやれるのは、業務の効率化に大変貢献します。また、私のように字が汚いと、発注者に出す書類を書くのに普通の人の何倍もかかりますが、ワープロなら見栄えよく作成できますから、ありがたいことです。
しかし、それだけではだめなのです。
会社でIT化を進めるに当たり、まず要望されるのが「情報共有」です。一昔前までの主流は、業務効率化や定型業務の自動化というOA化でしたが、最近はこのステップの話はほとんどでてこず、IT化のキーワードである「情報共有」ばかりです。(個人的には、OA化ができていない環境でのIT化は無理だと思います。が、この点を最初に説明しても理解してもらえないのでいつも苦労します。)よくある要望として、
「現場の情報を本社で見られるようにしたい」
「よく使う書類を同じ場所から取り出せるようにしたい」
「過去の資料を容易に検索して利用できる仕組みを作りたい」
等があります。もちろん、これらはIT化を行うことで実現可能なことなのですが、
このコーナーでは、ここ数回にわたり以下のようなテーマで話を進めてきました。
K025 権限委譲と情報共有
K026 効率化と非効率化
K027 システム化とは
一見、ITとは関係ないテーマにも見えますが、すべてこれは、自社をIT化していく上で必要な考え方や意識なのです。
今までいろいろな方とお話した中で、「IT化がうまくいかない」、「わが社の情報化戦略がみえない」などと言われる原因として、IT環境、つまり、IT化をすすめるために必要な土台が作られていないことがわかりました。そして、その土台を作るために必要なものが、上記のテーマだったのです。
今回は、同じくあいまいなままに理解されている「IT」つまり「情報技術」についてお話します。
今回は「システム化」についてお話します。業務効率化を図る上で、システム化は非常に重要です。
「システム化って、ERPソフト導入したり、開発することだろう」と考える方が大勢いらっしゃるでしょう。私自身、昔はそう思っていました。しかし、それが「システム化」であるならば、間違いなくその「システム化」は失敗に終わります。
前回、業務効率化に関する二つの方法、「権限委譲と情報共有」についてお話しました。今回はその効率化について話してみたいと思います。
ITを業務に導入した期待として、最もあげられるのがこの効率化です。無駄な作業を減らし人件費・経費を浮かしたり、ミスを減らして最終的な収益をあげるのです。経営者の方にとって、効率化という言葉は「甘い蜜」のような魅力があるようで、効率化だけのためにIT導入を決め、失敗した方も多くいらっしゃいます。
すみません。最近、「建設業を取り巻くIT」が難しく固い話題ばかりですね。経営陣もしくは管理職のかた向けにお話しするとこうなってしまいます。できるだけ平易な言葉で説明するように努力しているつもりですが、分かりにくい言葉が多いようです。不明な点は遠慮なくご指摘ください。改善するように努力したいと思います。
さて、今回も堅い話で申し訳ありませんが、よろしくお願いします。
前回、費用対効果の問題点をお話ししました。まとめると、
・費用対効果は会社によって異なる(スケールメリット)
・システム導入の目的と業務改善の目的が整理できていない
・導入前費用と導入後費用を明確に評価していない
この問題点を解決するためのポイントとは何でしょう。前回もお話したように『費用対効果』とは、対象となる業務の流れを数値化し、システム導入の前後を比較して効果を確認することです。
G023 周辺機器の選び方(まとめ)で、IT化とOA化の違いについてお話しました。今回はそれと同じくらいよくある質問、「費用対効果」についてです。
原価管理システムを新たに開発したり、市販のグループウェアを導入したりするときに、必ず「これらの費用対効果はどうか」という質問があります。もちろん、一定の効果があるから導入するわけすが、それは導入先によって差があります。
「IT化とOA化は、どう違うの」
「IT化って言ってるけどOA化と一緒だろ」
よくこのような質問を受けますが、私の考えでは、大きな違いがあるといえます。今日はこのお話です。
電子認証、電子調達と少し脱線しましたが、今回から、また電子データの利活用に戻ります。さて、作成・管理・保存のルールをお話しましたので、いよいよ利用についてのルールです。
利用ルールといっても難しいことではありません。大事なのは、
・既存データを壊さないようにする。
・利用したことを記録に残す。
以上の2点です。この2点についてお話します。
前回、電子調達の概略についてお話しました。今回は実際に行われている取引システムの紹介です。
今回は、電子調達についてお話します。「電子調達って電子入札のことではないの?」と思われる方がいらっしゃるかもしれませんね。確かに、電子入札も電子調達の一部です。官公庁によっては電子入札を電子調達と呼んでいる所もありますが、これは狭義の呼び方です。
本来の電子調達は、一定の工事に対する見積・発注・契約・出来高査定・支払を全て電子化し、オンライン、ペーパーレスを実現するものです。電子入札は、この先端の部分をオンライン化したに過ぎません。また、電子調達を電子商取引と表現することもあり、語句統一が図れていないのが現状です。
長期休暇前によく受ける相談に、電子データの保存法つまりバックアップについての質問があります。今回は、この話題について詳しくお話ししましょう。
今回は情報共有がテーマです。情報共有といっても広義のものではなく、CALS/ECにおける「工事施工中の情報共有」についてです。
PDFの紹介をした際に、紙データ電子化の話に触れました。 今回は、もう少し掘り下げてお話したいと思います。
前回の「電子データ管理ルール」、前々回の「電子データ作成ルール」策定を無事にクリアし、運用を始めたとします。次第にデータが蓄積されてくると、求める資料を得るのに時間がかかるようになるでしょう。最初は、担当者への電話で済んでいたものが、時間がたつにつれ担当者の記憶もあいまいになり、担当者の所属が別工事に変わって、連絡が取りづらくなったりします。そうこうするうち、集めたデータが利用されにくくなり、結局、集めるだけが目的の困ったシステムになってしまうのです。
前回の作成ルールに続き、今回は管理ルールのポイントをお話します。
管理で一番大事なことは、
・どこに
・だれが
・いつまで
管理するかです。
前回は、電子納品のまとめとして、どのようなものが再利用しやすいかをお話しました。具体的には、
・施工計画書
・図面
・実施工程表
・打合記録
の4点でしたが、これらを作成・利用するための手順などを更に詳しく見ていくことにします。
まず、今回は作成について。
電子納品のまとめとして、会社内での再利用についてお話します。
今までの4回にわたる説明で、電子納品のおおまかなイメージはつかんでいただけたと思いますが、あまりの書類の多さに閉口した方もおいでかもしれません。これらを発注者への納品物としてのみ捉えるのは、もったいない話です。それでは、これらの電子データをどうすればいいのでしょうか。
今回は、電子納品の現状についてお話します。ただ、実体験もそう多くはないので、セミナーや講習会での情報を元にお話しますが、大きくは外れていないと思います。
今回から電子納品についてお話しします。
まずは概略です。電子納品とは従来、紙で納品していた様々な成果品(主には書類)を電子データで納品することです。膨大な書類がCD?R(1回だけ書き込み可能なCD)数枚の量になるとイメージしてみてください。
今回は電子入札の概略を紹介します。
業界以外の方は、「入札」そのものもピンとこないかもしれませんね。 入札とは、工事の請負をする際に、希望者が金額を書いた札をに入れ、一番有利な内容の者(一般的には普通は価格が安い)に仕事を依頼する制度です。
電子入札とは、パソコンとインターネットを使ってこれを行う仕組みです。
建設業でのCALSは、国土交通省を中心に展開されている電子入札と、電子納品を行うための仕組みです。簡単に言えば、書類関係を電子データ化し、再利用を促すことで効率化を図るものです。つまり、ITなくして入札も納品もできなくなります。

/img/logo02.gif)