<   2006年 01月 ( 15 )   > この月の画像一覧


2006年 01月 31日

コミュニケーション

本日は月末で、私も含め事業を営んでいる人は入金や支払がある。

私も年末まで一緒に仕事させていただいた会社さんよりご入金を確認した。

そこの会社は、お父さんが社長で、息子さんも会社を手伝われていました。

私に仕事を依頼されたのは息子さんで、3ヶ月間息子さんと新しい業務システムを使う業務プロセスを検討してきましたが、私が忙しさに流され、進捗状況を逐一社長に報告しませんでした。

また、プロジェクトにはよくあると思うのですが、ユーザーの代表とコンサルタントが打合せし、その内容をユーザー代表が社内で再度もむというパターンです。

しかし、やはり社長などトップにはコンサルタントが直接説明しないと打合せしている内容が正しく伝わらないことがよくあります。

原因は、プロジェクトの目的が共通認識されていないことにつきると思います。

共通認識させるのはコンサルタントの責任であると思っています。

社内のことなのでコンサルタントには責任がないと考える方も多いと思いますが、
コンサルタントが事実上のリーダーになる場合が多く、共通認識を図るには一番適していると思います。


担当者とずっと実務的な打合せを進め、内容が具体化されればされるほど
トップに報告するのがおっくうになります。

それは具体化した内容がひっくり返されると、またやり直さなければならないからです。

結局、こまめにトップに報告しなければいけないのです。実務担当者の顔もたてながら、、、


▲今日の一言▲
目先の仕事だけにとらわれず、目的を忘れるな
[PR]

by operationdesign | 2006-01-31 21:03 | その他
2006年 01月 30日

先入観は自己の可能性を否定するもの

先日、私が所属している中小企業家同友会のIT活用部会なる会合があり、私も参加しました。

そのメンバーは役15名程度いらっしゃいますが、システム系の会社を経営されている方々です

中には、結構高齢だなと思える社長さんもいらっしゃいます。

多分65歳くらいなので、実務はあまりご存知ないかと思っていましたが、

いざ話をしてみると、HTMLやスクリプト言語にやたら詳しい。

どうやらご自分でもプログラムが書けるようである。

待てよ・・・・ 年齢から考えてもこの人、何歳からこんなオープン系のプログラムを勉強したんだ?

50過ぎてたんじゃない? (^^ゞ



私はプロフィールにも書いておりますが、プログラマーからSEとなりコンサルとなったものではありません。

ですから、プログラミングなどほとんど分かりません。

でも仕事がITコンサルタントですから、プログラミングやデータベースの知識が必要な場面はよくあります。

書物などで勉強もしていますが、大抵の場合は、SEやプログラマーに相談していました。

そのため、自分でプログラミングやDB設計ができるようにはなっていません。



「40過ぎたら頭に入らない」、「自分は文系だから理解できない」などの言い訳は単に自分でそう思い込んでいるだけなんですね。


▲今日の一言▲
先入観を捨て、行動に移すことがスキルを高める
[PR]

by operationdesign | 2006-01-30 18:07 | その他
2006年 01月 27日

営業スタンス

ブログをはじめ、私の仕事の具体的な作業方法などを中心に書いてきましたが、
妻や周りの人から「内容がようわからん」と大変評判が悪かったので(笑)、
少し反省し読みやすくしていきたいと思います。


今日は営業の話です

独立している人は全て営業が必要です。
営業ばかりしているときもあるくらいです

私はサラリーマン時代にも法人向け営業というものをやったことがなく、現在試行錯誤の繰り返しのなかでなんとかやっているような状況です。

先日もお世話になっている名古屋の会社に打合せに行ってきました。

で、いつもの担当営業のIさんと話をしておりました。

Iさんが担当されいてる顧客の課題やその課題をどのようにシステムで解決するかなどの話です。


その話を聞いていて、途中で気がついたんですが、私の営業活動とIさんの営業活動にはその考え方に大きな違いがあるということに気がつきました。


私は企業さんと1個人として業務委託契約をさせていただくので、営業活動は自分自身を売り込みです。


すなわち 「こんないことができます」 
      「過去にこんなんやってました~」
       「これ導入されたらこんな成果がでますよ」 
     などなどPRを並びたてます。


それに対して、Iさんはお客さんの簡単にホームページメンテナンスができるツールを考えたり、お客さんの顧客開拓方法まで考えたりされています。

つまり、お客さんに不便さの解消や新たな便利さを提案されているのです。


当たり前のことのようですが、Iさんは常に考えておられるので、次から次から便利なアイデアが出てくるようです。

私も多くの営業マンは知っているのですが、やはり自分ところの商品を売ることばかりが前面に出てくる営業マンが大半ではないでしょうか?

とくに大企業ほど組織的に経営されている分、その傾向が強いと思います。


とにかく、私も目からウロコがおちた1日でした



▲今日の一言▲
営業は顧客に売ることより不便さの解消を考えよ


     
[PR]

by operationdesign | 2006-01-27 10:30 | その他
2006年 01月 24日

購買機能の要求事項

昨日は販売管理に期待される機能を書きました。
今日は購買機能について書きたいと思います。

一般的に購買、又は仕入は在庫管理と一緒になっているケースが多いです。
一緒になっているとは、一つのソフトウェアまたはライセンスとして販売されているという意味です。

登録する伝票は
 「購買発注」「入出庫」「仕入先請求書」だと思います。(簡単すぎてすいません)

これらの中でで業務上の改善できる課題の一例を挙げますと

製造業では、
 ●MRPに基づいて自動で購買発注を生成してくれること
 ●外注の発注も出て、外注工程の管理も可能
 ●入庫は発注データとの差異がチェックでき、一括処理できる
 ●仕入先からの請求書と納品額のチェックができること
 ●在庫の評価方法が複数あること(先入先出し、総平均法など複数から選択できること) 
 ●工場は複数もてるか?
 ●在庫の分析機能は自社にあった分析レポートがあるか?


などなど他にもたくさんあると思いますが、これらの視点から現状業務とシステムを検証していけば具体的な課題が見えてくると思います。

その課題をIT導入で解決できるプランが書ければ良い提案書になること間違いなし
[PR]

by operationdesign | 2006-01-24 19:24 | IT活用
2006年 01月 23日

システムの導入目的

私はシステムへの目的は大きく分けて4つあると考えています。

 ①管理・品質レベルの向上
   タイムリーな情報把握など
 ②業務活動のスピードアップ
   納期短縮など
 ③情報・知識共有による組織力向上
   提案書や顧客情報の共有で営業力の向上
 ④コスト削減

④は投資に対する効果は定量的に判断できますが、
①~③の投資効果は非常に数値化しにくいものです。

高いソフトウェアを導入してからと言って、リードタイムが短縮されるとは限りません。

しかし、今まで納期回答は製造担当者と営業マンでの口頭によるやりとりであったものからシステムが在庫や発注済数量を計算し、在庫引き当て処理を行うようになります。

すると営業部の中に口頭でのやりとりはなくなりますが、全受注案件の得意先の要望や特性を考慮した出荷計画を立案することになります。

つまり、今まで営業マンの早い者勝ちであったような在庫引き当てが得意先の顔を思い浮かべながらの納期調整(出荷計画の立案)を行うことが可能になります。

経営者が投資を判断する効果はここにあたります。(販売管理システムの場合)

販売管理の提案書を書く場合はこの点を目的として書くべきだと思います。
システムの機能要件を書いているような人はSI企業の営業として失格です
[PR]

by operationdesign | 2006-01-23 21:53 | IT活用
2006年 01月 20日

自分の得意分野

今日は私が参加させて頂いている協会の会合に出席しました。

この会合は京都のSI企業の社長さんがたくさんいらっしゃるので、私のような個人でやっているものにとっては非常に緊張する場でもあります。

私は2005年の5月に開業したばかりですので、まず何をしているやつなのかを皆さんに知ってもらいたいと常々考えています。

私 : 「ソフト導入時に業務フローやルールの作成など業務設計のお手伝いをしています」

参加している社長さん : 「・・・・・・」


いまいちインパクトがないなぁ という感じです

やはり個人でやっているので、得意分野を絞らないと強みを発揮できません。

私はお客さんから依頼されたことを色々やってしまうこともあり、なかなか分野を絞りきれないのです。

これだっ! てのが早く欲しいよ~ と願い1日でした


しかし、従業員も50人とか100人とかいらっしゃる会社の社長さんばかりでしたが、皆さん気さくに色々情報を下さり、本当に感謝しました。
[PR]

by operationdesign | 2006-01-20 18:25 | IT活用
2006年 01月 18日

データ項目の決定 

今回も仕事の道具箱です。

パッケージ導入支援の作業ステップは新しい業務プロセスを箇条書きで作成するところまでいきました。

その後にすることは、マスタデータと伝票データの各データ項目の入力内容を決定する作業を行います。

これもユーザーさんと一緒に行います。

普通このような作業はユーザーさんに全てをお願いすると思いますが、
なぜ、コンサルタントが一緒になって行うかといいますと、

例えば、レガシーシステムではMRPがなかったのにいきなりMRPの機能があってもどのように設定すれば良いかをユーザーさんには分からないためです。

ポイントはレポートで集計するためのグループ化するキーや在庫管理に関係する項目を大事に考えています
[PR]

by operationdesign | 2006-01-18 22:45 | IT活用
2006年 01月 17日

運用ルールの作成

仕事の道具箱シリーズも3回目となります。

前回までで
 ①業務フロー作成による現状調査
 ②システムの検証方法
 を説明しました。
 この二つを実施することで新しい業務プロセスが出来上がります

私はパッケージソフト導入時にはこれだけでは不十分だと考えています。

なぜか?
エンドユーザーにとっては、業務フローだけではピンとこないからです。

そこで私は運用ルールというものを作成します。

ここでいう運用ルールとは何かというと
処理伝票(受注票や発注書など)ごとに処理手順を箇条書きで書いたものです。

やはりユーザーさんは箇条書きのほうが数段理解が深まるのです

このときのポイントは、
 ★時間軸を意識するということ
 ★エンドユーザーの作業処理単位にあわして書くこと

作業が終わると伝票ごとの作業項目が箇条書きに列挙されます
この作業項目を見るだけで、エンドユーザーは仕事を進めることができますし、
システム導入前段階での新しいプロセスの検証が可能になるのです。


  
[PR]

by operationdesign | 2006-01-17 21:25 | IT活用
2006年 01月 16日

ソフトウェアの検証作業

前回、私独自の業務フローを作成しての企業の現状業務の調査方法を紹介しました。

次にやることは、ソフトウェアの検証です。
現状業務と顧客の要求事項が表現できるかという調査です。

この時点で導入すべきソフトウェアは2、3に絞られています。
私はこれらのソフトウェアのサンプル版を活用して検証します。

まず、最低限必要なマスタデータを入力し、作成した業務フローごとに
顧客の要求事項が実現可能かどうかを検証します。

そして、最も適しているソフトウェアを選択し、お客さんにご購入を提案します。

お客さんがソフトウェア購入後、テスト環境が構築されますので、
その後、今度は各担当者の方と一緒にソフトウェアの検証を行います。
この作業は操作を覚えてもらう目的もありますので、実際に操作する人が
参加する必要があります。

私の役割としては、
要求が実現できないプロセス(ギャップ部分)を記述し、代替案を考えます。

そのギャップを代替案を業務フローに表現します。

これが新しいプロセスになります。


原則、ソフトウェアにカスタマイジングはできないので、
ギャップ部分は社内のルールを作り、ギャップをうめていくわけです
[PR]

by operationdesign | 2006-01-16 21:33 | IT活用
2006年 01月 13日

現状の調査(業務フローの作成) 

私の企業さんの現状調査は業務フローの作成から始まります。

現状調査は課題・問題点の原因を特定することを目的としますが、
業務フローを聞いていく中で見えてきます。

業務フローはユーザーさんと私で1対1~3までで行います。

はじめにプロジェクトのまとめ役のような立場の方に会社全体の業務のフローを聞きます

次に各種伝票(見積伝票、発注伝票、請求書、会計伝票など)のフローと役割分担、
タイミングを聞きます。

ここで一旦、全体像を伝票の流れをドキュメントにまとめます


その後別の日に、各部門の担当者へのヒアリングを進めていきます
エンドユーザーさんへのヒアリングには、私のオリジナルのヒアリングシート
(5W1H+inputデータ、outputデータという項目から構成されているエクセル)
を使用します。

業務の流れを聞きながら、直接エクセルに入力していきます。
(タイピングが早くできることが必須条件です)


ヒアリングが終了してから、業務フローの作成を行います
私の業務フローは、一般的な業務フローとは違います。
記号は箱と矢印だけのシンプルなものです。

私の業務フローは業務の流れとシステムの入出力作業を
両方表現することが目的ですので、「処理」や「判断」というような記号は使いません。

そして、フローを書く枠組みの行にあたる部分には組織・部門を入れます
そして最も変わっているのは、枠組みの列の部分は「業務フロー」「システム操作」
「インプット・アウトプットデータ」「データベース」と大きく4つに分ける点です。

「業務フロー」ならその下には作業の流れ、「システム操作」の下にはアプリケーションの操作
内容を記入し、「インプット・アウトプットデータ」には、入力データや出力帳票名を記入。
「データベース」にはどこのデータベースかを記入します。

分かりにくい説明ですいません。

とにかく、業務の流れと運用ルールを構築することが目的なので、
ヒアリングシートも業務フローについても試行錯誤の末、これが一番自分にとって
分かりやすいドキュメントであると確信しています
[PR]

by operationdesign | 2006-01-13 22:05 | IT活用