全34件 (34件中 1-34件目)
1
-
ラベンダーローズ
今日は、早朝に雨がザンザン…恵みの雨かなあ？反応したのか庭のラベンダーローズが一輪だけ咲きました…
2012年06月06日
コメント(0)
-
今日の三角山
今日の三角山…朝は16,7度で暖かくなって来ました…あちこちでカラスの鳴き声が響いています…最高気温は23度の予報…
2012年06月05日
コメント(0)
-
今日の三角山
今日の三角山…朝は16,7度で暖かくなって来ました…あちこちでカラスの鳴き声が響いています…最高気温は23度の予報…
2012年06月05日
コメント(0)
-
売れる仕組
最近読んだ本の紹介です。「売れる仕組み」直接お客さまに販売する店をどうやって売れる店にするのかを解説してあります。どちらかというと、理論的な色が強い本なので、理論はの人にはお勧めです。＃最近、全然更新が出来ていませんので、読んだ本の紹介をする事にしました売れる仕組み こうすれば顧客は離れない ( 著者： 服部隆幸 | 出版社： ダイヤモンド社 )
2004年09月07日
コメント(0)
-
評価の季節
うちの会社では期末となり、人事評価の季節になってきました。目標設定をして、自己評価をしてもらい、それに対して、評価する人がポイントをつける方法を取っています。この時期にいつも話題に上るのが、何を基準にするんだー？という事。思想は絶対的なものに対する評価なんだけど、その絶対的なものの基準が難しい。評価って、かなり主観が入ってしまったり、見える部分だけで評価してしまうので、とっても難しいですよね。うちの会社は、成果主義と終身雇用の複合型のようなシステムでやってますが、他はどんな感じなのかな？以前にも紹介した、成果主義の崩壊的な事が起こらないように気をつけたいものです。内側から見た富士通 「成果主義」の崩壊
2004年08月24日
コメント(1)
-
成果主義
「内側から見た富士通」という本を読みました。元富士通社員の、ここまで書いていいのかあ？という感じの本です。成果主義とそれを運営する年功序列世代の管理職たち。そして、評価という神器を手に入れた人事部の暴走。建前と実状に嫌気がさし、退職する幹部候補生。年功序列の恩恵を受け始める世代の増加。あまりにも、絵に書いたような成果主義の実態を生々しくレポートしています。自分の会社に置き換えて考えると、必ず一つや二つ同感な部分があるはずです。内側から見た富士通 「成果主義」の崩壊最近、他のサイト更新やメルマガ更新に追われて、ここの更新が少なくなってしまってます。
2004年08月11日
コメント(0)
-
メールマーケティング
東京出張中で、ちょっと更新が遅くなってしまっています。今週は、火曜日から金曜日までで、ホテルのPHS電波環境も悪いので、不便です。－－－－メールによるマーケティングを行うためには、メールアドレスを登録してもらう必要があります。でも、会社のメールアドレスと名前を登録して貰うは、とても難しいものです。アドレスを登録して貰う方法としては、以下のような方法があります。１．ホームページでの告知２．キャンペーンによる募集３．展示会などの名詞収集４．無料冊子のダウンロードしかし、何より重要なのは、メール配信の内容です。何をどの位の頻度で配信するのか？その内容が読者の方にどんなメリットを与えるのか？を良く考える必要があります。その為に、まず、HPでの告知にはサンプルとバックナンバーを載せて、お客様へのメリットを打ち出す必要があります。そして、内容的には、開発者レベルのトピックスや、技術内容を盛り込む必要があります。私の会社では、「メール商人」を使って配信を行っています。
2004年08月05日
コメント(0)
-
メールを使ったマーケティング
メールを使って売上げを上げるという手法は、自社の製品を販売する道を作るという事です。やはり、最終的にお金を払ってくれるのは、お客さまですし、そのお客さまへ直接、語りかける事ができるというのは、何にもまして、重要な意味を持ちます。メールを使ったマーケティングツールのメール商人を使えば、配信する事や反応を見る事はとても便利に出来るようになります。しかも、無料のメールマガジンの様に、宣伝が入ったり、Fromが自社では無いような事は、ありませんので、キチンとしたメールを送る事ができます。しかし、まず、メールアドレスを集める必要があります。お客さまのメールアドレスを集めるには、どうすれば良いのでしょうか？
2004年08月02日
コメント(0)
-
ダイレクトマーケティング
メールを使ったマーケティングツールのメール商人を使って、会社で色々と試しています。先日も、展示会の告知をして反応を見ました。キャンペーンでジュースを配るので、メールアドレスを登録してよというものです。前年の展示会での訪問者宛てに数百件のメールを出しましたが、反応はほんの数人。難しさを痛感しました。
2004年07月30日
コメント(0)
-
商品を売るために
商品を売るために有効なのは、ダイレクトマーケティングです。お客さんあっての商売ですので、ホームページなどを使用した販売を行ってゆく必要があります。ここでは、直販についての販売の方法について、考えて見ます。そこで有効なのが、メールを使用したマーケティング活動です。いかに良い商品であっても、売る方法が悪くては、売れません。売る良い方法とは何でしょうか？それは、判りません…判らないというのは、その商品や、商品を売る会社によって、売る最善の方法というのは、変わってくるからです。会社のブランド力、知名度、商品のラインナップ、お客さまの層、商品の種類によって様々に変わります。そのため、商品を売る場合には、あなたが試して見なければなりません。その代表的な方法がダイレクトマーケティングです。ダイレクトマーケティングの代表的な優れたツールとして、メール商人があります。メール商人のページ
2004年07月29日
コメント(0)
-
売れる商品を開発するには？
売れる商品を作るにはどうしたら良いのか？永遠のテーマですよね。ただ、前提条件が付いています。・あまりお金をかけずに…・あまり時間をかけずに…などの条件が付いてしまいます。このため、なかなか受託開発の仕事から抜けられません。社内から色々と企画が出てきますが、あれもだめ、これもだめ。そのうち、社内では自分の会社では、自社製品は無理なのかという空気が出てきて、企画すら発生しなくなります。そこで、自社製品の開発をする近道は、やはり受託開発からの派生です。受託開発で目がありそうなものを、自社に権利を残す事で種を準備します。そして、その種が貯まった所で、自社製品として開発を行うべきです。現在の風潮では、うちの会社はXXXが出来ます。でも、動いてないので開発費がかかります。これでは、商売として成り立ちません。まずは作って、動くものを見せなければ、誰も歯牙にもかけてくれないのです。さあ、種をまきましょう。
2004年07月27日
コメント(0)
-
売れる商品を開発する
さて、売れる商品を開発するには、どうすれば良いのか？自社の技術で出来る商品を作る？マーケット調査をして作る？社内公募して作る？自社の技術で出来る商品を作った場合は、よっぽど技術的に突出していなければ、売れません。かといってマーケット調査なんて…という感じではないでしょうか？
2004年07月23日
コメント(0)
-
会社組織のあり方
組織はどのようにあるべきか？開発を持つ会社の組織は、どうあるべきでしょうか？利益や売上げを意識させる組織が良い？そんなものは関係なく、効率が良い組織が良い？開発者には、損得抜きに開発に没頭する環境を与えるべき？色々な意見があると思いますが、状況によりベストな組織は変わるものだと思います。状況というのは、やはり業績や投資するキャッシュの状態などです。 つづく
2004年07月19日
コメント(0)
-
なぜ自社製品ができないのか３
どうしたら自社製品が出来るのか？これは、やはりリーダーシップが必要になります。経営的な判断が不可欠なのは確かですが、リーダーのリーダーシップにより、メンバーの意識を自社製品へと向けます。そして、納期の規定を開発者本人に作らせる事で、自社製品への道は近くなってゆくのです。
2004年07月17日
コメント(0)
-
なぜ自社製品ができないのか2
自社で権利を保持しながら受託開発を行い、いざ、自社製品を開発しようとすると、なかなか開発が進まないという状況が発生します。これは、受託開発の様に納期が明確に定まらないという理由の場合も多くあります。自社製品開発の途中で、受託開発案件が入り、受託開発を優先せざる終えないという状況があるからです。会社の状況により、直ぐに費用を得る事ができる受託開発を行うという判断がされる場合があるからです。それが何度かあると、社員の中には「自社製品の優先順位が低い」という意識が芽生えてしまうからです。
2004年07月15日
コメント(0)
-
なぜ自社製品ができないのか
受託開発でお金を貰いながら自社製品を作る。誰しも考える事で、これが出来ると理想です。しかし、現実問題は…自社製品にするには、お金を貰いながら権利を自社に帰属する必要があり、これがまた、障害が高いのです。権利を貰う代わりに費用を安くすると、売上げが上がらないし…しかし、ここは歯を食いしばって権利を獲得しましょう。受託開発での業務の権利を全て納品してしまうのは、次の同じような開発が不自由になり、自分の首を絞めることになります。
2004年07月14日
コメント(0)
-
受託開発と自社製品
受託開発は、納品すればお金が貰えます。これに対して、自社製品は完成して販売してお客さまに買って貰わなければ、お金が貰えません。しかも、開発に掛けた工数を回収できるとは限りません。受託開発の方が良く見えます。受託開発は、リスクが少なく、開発費の回収が確実ですので、良い仕事です。しかし、受託開発1色という状態は、避けるべきです。 つづく
2004年07月13日
コメント(0)
-
開発指向の商談方法4
相手が信頼できるかどうかの判断は自分で。自分が信頼されるかどうかはどのように決まるのでしょうか？初めての仕事の場合には、お客さまの要望を聞き出し、それに関する実現方法の提案を行なう必要があります。お客さまの要望を聞く部分というのは、意外に罠が多くあります。お客さまは、自分の考えた構成である程度組み立てている事があり、そのどの部分が必須な条件で、どの部分が変更可能なのかというのは、実際に話し合うまで判らないものです。お客さまの実現したい機能は何なのか？既にあるシステムの追加なのか、新規システムなのかによっても大きく前提は変わります。ここをしつこい位に聞きだして、しつこい位に確認する必要があります。しかし、お客さまの中には、しつこい確認に対して、「これは一般的な事なので、知ってますよねー。」と言われる方もいます。しかし、一般的な事というのは、人や会社によって、全然違うという事を意識する必要があります。お客さまにとって、一般的でも、世間や自分にとって、一般的ではない事は、十分に話し合い、言葉の定義を再確認する必要があります。これらを踏まえて、お客さまにとって、最適な解を示す事で信頼を得る事ができます。それは、自分にとって最適な解ではなく、お客さまにとって最適な解でなければなりません。たとえ、自分に仕事が回って来なくなってもです。この取り組みによって、例え、その仕事がなくなっても、次の仕事を得る事ができるようになります。
2004年07月10日
コメント(0)
-
開発指向の商談方法2
次の段階で機能と納期の確認になります。納期の問題も第1段階で不可能である場合にはフィルターを掛けますが、機能的な仕様がはっきりしなければ、納期が決まらない事も良くあります。第2段階は、「機能による構成の提案」のステップになります。まず、お客様がどんな事を実現したいのか？を把握する事が重要です。実現したい機能を元に、どのような構成で行えばその機能を実現できるかを提案します。お客様がある程度構成を指定する場合もありますが、その構成の中でどの部分が必須な項目で、どこは変更しても良いかを把握する事が最も重要です。これを把握できなければ、お客様にとって最適の解を提供する事ができません。受託開発などの場合には、海外の安い労働力がありますので、お客様の言う通りの構成で言う通りに開発を行っていたのでは、仕事はなくなります。海外の方が安いのですから。それを、お客様が海外を引き合いに出した場合に、胸を張って、「安い方がよろしいのであれば、どうぞ、海外を使ってください」と言えるだけの付加価値を提供する必要があります。その付加価値の一つとして、構成の提案を行う必要があります。ここで注意して欲しいのは、構成の提案は、お客様にとって最適な解でなければいけません。システムの一部に、自社の製品を使用できる場合でも、他社の製品を使用した方が適している場合には、お客様に他社を使うように勧めるのです。こじつけで、自社のものや自社のノウハウを使うのは、最終的には、デメリットにしかなりませんので、お客様本位の考え方をお勧めします。
2004年07月09日
コメント(0)
-
開発指向の商談方法
プロフィットセンターのリーダーになると、どうしてもお客様との商談が発生します。受託開発の商談の際に大切な事は、相手を信頼し、自分も信頼してもらう事ですよね。その為には、商談の段階に応じての対応が必要となります。まず、第1段階は「予算確認段階」になります。お客様の行いたい事を確認し、大まかな概算を直ぐに伝えます。ここで重要なのは、概要であり、内容の詳細ではありません。お客様がどんな機能、組み方、条件を考えており、どこまでの許容範囲を持つのかの概要を話す必要があります。それらが確認できた時点で、費用の概算を伝えます。この場合の概算は、かなり範囲の広いもので良く、数千万なのか、数百万なのか、程度のもので十分です。この段階で、予算に合わない場合には、直ぐに商談終了という事になります。得意客など、感触が判るお客様以外の場合には、できれば、この段階は、電話などで済ませたい所です。
2004年07月08日
コメント(0)
-
リーダーの心得7
組織内の決め事を作った場合には、その理由をメンバーに説明し、まずリーダが率先して行います。理由に関しては、何のためにそれを行うかを納得させる事で、その決め事に対するメンバーの意識を統一します。続かなかった決め事を分析してみると、決め事を破ったのは、まずリーダーからである場合が圧倒的に多い事に気づきます。リーダーとは、率先する人ですから、決め事に関しては、どんなに苦痛を伴う事でも、必要である事は、リーダーが継続する必要があります。リーダーが継続しないという事は、必要がない事だとメンバーが判断するからです。当たり前ですよね。これが結構、大変なんですが…なんに関してもそうですが、継続を行う事は大変なものです。しかし、継続する事でパワーが生まれる事を肝に銘ずる必要があります。
2004年07月07日
コメント(0)
-
リーダーの心得6
旅行のため久しぶりの更新になりました。リーダーは、常に一段上から物事を判断しなければなりません。一段上というのは、組織的に上という意味よりも、物事の見方を大きくという意味です。例えば、リーダに職場改善のための提案を持っていったとします。その時に、リーダはその改善が良いもの？悪いもの？実現する価値があるか？という視点で判断する必要があります。あたりまえの事ですよね。しかし、世の中のリーダは、どうでしょうか？提案の内容の細かい部分を指摘して、これじゃあだめと言ったり、フォーマットを指摘したり、誤字脱字を指摘したり…このような対応をされると、提案するどころか、話をするのもいやになります。ですから、提案の概要が価値のあるものであれば、その旨をメンバに伝え、実行する意思を示しましょう。詳細はそれから考えれば良いのです。
2004年07月06日
コメント(0)
-
リーダの心得5
リーダは、メンバーにコスト意識を植え付けるという仕事もあります。各業務と経費と利益に関してメンバーに説明し、無駄な出費を抑える必要があります。ただ、無駄な出費を抑えるという面をメンバーが理解すると、思わぬデメリットも出てきます。効率アップや、向上心よりも経費を重視してしまうので。「不便だけど、高いから買うの止めよう」「あの展示会に行きたいけど、経費が掛かるから止めよう」という事が発生します。しかし、効率やスキルの向上心は、経費には変えがたいものがありますので、そこはリーダは許す必要があります。例えば、展示会やセミナーに遠距離出張などの場合には、会社にスキルアップ支援制度のようなものを作ってもらいます。その支援制度を使用する事で、組織の経費と切り離して考えてもらうのです。＃もちろん、会社として資金に余裕がない場合は、全然違いますが…
2004年07月02日
コメント(0)
-
リーダの心得4
任せられるようになる前からの注意点ですが、成果に関しては担当者が開発したと事あるごとに言う事が大切です。「あの、XXが作った○○みたいな」とか、「XXがやったプロジェクトの続きです」とか、その人が誇りを持てて、うれしくなるような言動を取る事で、モチベーションもどんどん上がります。実質上、リーダが仕切ったり、お客さまとの商談・やり取りを行った場合でもです。まちがっても、メンバーの前で「おれがやったプロジェクト」みたいな発言をしてはいけません。そして、問題が発生した場合には、一番に対処方法の相談・お客様への説明を行います。リーダは評価する立場・責任者ですので、責任は自分にあり、成果は担当者にあるというスタンスがメンバーとの信頼関係・モチベーションの維持に直結します。
2004年07月01日
コメント(0)
-
リーダの心得3
この状況を打開できるのは、やはり、まかせる事しかありません。でも、最初は大変です。口を出すのを出来る限り控えます。途中での報告のみを行ってもらい、これはやばいという状況にならない限りは、口を出さないのです。もちろん、任せた人には、指導をします。しかし、その指導も出来る限り、その人に考えさえ、納得させます。この我慢ができれば、それぞれの人は、自覚を持ち、モチベーションが上がり、何もしなくても業務が回るようになります。ただ、これには、半年から1年は掛かりますので、辛抱強く任せる事が大切です。
2004年06月29日
コメント(2)
-
リーダの心得２
私もリーダになって最初の頃は、やはり、管理を行なおうとしました。自分がやらなければ、仕事が終わらないとの思いからでした。しかし、管理を行なってしまうと、肝心の事を考えたり、新しい事にチャレンジする暇がありません。そこで、開発業務のリーダ的なものを決めて、少し任せる事にしました。しかし、納品前1週間になると、トラブルが続々発覚します。しかも、納品の時期が重なり、複数のプロジェクトで納品があやうい状態が多発しました。何度も徹夜して、何とか納品を行ないましたが…この状態を打開するためにはどうしたら良いのでしょうか？ つづく…
2004年06月28日
コメント(0)
-
リーダの心得
リーダは、マネージャになってはいけません。リーダとマネージャには大きな違いがあります。マネージャは管理する人。リーダは導く人です。マネージャになろうとすると、とにかく忙しくなります。組織で行われるプロジェクトを仕様からスケジュール、慎重区状況を全て把握して、支持するのは不可能です。誰しも、最初はこの罠にはまりますが、そこはぐっと我慢して、リーダになるべきです。 つづく
2004年06月26日
コメント(0)
-
開発部隊を持つ組織2
機能別組織で部門間の連絡や見積りに時間が掛かる問題を解決するためには、事業別組織を採用するのが有効です。事業別組織とは、営業・開発・製造を１セットにまとめて、その部署で仕事が完結する組織です。各事業のトップには、その事業に責任を持ち、売上や利益をコントロールするリーダを置きます。また、開発の中からも営業と一緒にお客さまと接する技術営業的な人を作ります。お客さまとの商談には、営業と技術営業が参加し、その場でお客様に対して概算の金額を伝え、正式な見積もりは後日お知らせするという方法を取ります。 つづく
2004年06月25日
コメント(0)
-
開発部隊を持つ組織
開発部隊を含む組織はどうあるべきでしょうか？よくあるのは、開発部・営業部・製造部という機能別の組織だと思います。この組織は、製品が順調に流通していて、販売経路もびしっとしている場合には、効率的だと思います。しかし、製品のカスタマイズや受託開発主体のビジネスを行っている場合には、営業部がお客さまと話をして、開発部に見積って貰う。開発部は、開発に関しては自分の部で見積り、量産時の価格は製造部へお願いします。製造部の見積りが戻ってきて、営業部に見積りを出して、営業部が見積りを精査して、営業部長の承認を貰ってという手順になります。見積りを出すのに1週間、短くて2～3日という事になります。これは、ビジネスチャンスを逃す原因です。これを打開するためには、どうしたらよいのでしょうか？ つづく
2004年06月24日
コメント(0)
-
製品サポートの仕組作り2
開発者が行う製品サポートでは、開発者はサポートの目的をハッキリする必要があります。質問のあるお客さまに満足なサポートをする事は当然ですが、質問していないお客さまへのサポートも同時に考えると効率的です。開発者にとっては、開発業務もありますので、内部的なテーマとして、サポートの手間を減らす事も重要な用件の一つです。質を落とさずにサポートの手間を減らすための方法として、ホームページによるサポート、メール配信によるサポートの併用が有効です。個別のメールサポートでは、サポート担当者は、全ユーザに対しての返答を前提に返答を行い、それをホームページのFAQとして公開します。HPでの公開だけではなく、メール配信による通知を行う事で、サポートへの質問が減る効果があります。また、メール配信する場合には、FAQの内容のみならず、開発でのトピックスなど、お客さまに楽しんでもらう内容を盛り込む事で、顧客レベルのレベルアップ（リピート購入）を促進する効果があります。
2004年06月23日
コメント(0)
-
製品サポートの仕組作り
大企業はともかく、中小企業の製品サポートは、ほとんど開発者が行っているのが現状だと思います。開発者は、仕事をしながらサポートをするわけですから、サポートの思想・仕組がハッキリしていないと、ついつい、「やっつけ」仕事になってしまいます。ここで忘れてはいけない事は、サポートによるリピート購入やお客さまのファン化です。最近のマーケティング関連の本では良くある、 見込客→顧客→リピート客→ファン客というやつです。顧客からリピート客へのステップアップのキーとなるのは、お客さまが商品にどのくらい満足したかと、フォローに掛かっています。そこで、是非やって欲しいのが、情報の発信です。「やっつけサポート」だと、質問のあったお客さまに対してだけに情報を発信します。これを、全ユーザに対して行う事で、顧客のリピート化、ファン化が進む仕組が作れるのです。情報発信は、簡単です。メール配信スタンドを使用してもよいし、メール商人などの配信ツールもあります。費用を掛けずに、自社ドメインからの発信をしたければ、Microsoft Wordででも可能なのです。肝心なのは、やる気。やってみなければ、なんにも判りません。メルマガなどの書物にも良くありますが、やってしまうと意外と手間を減らせるものなのです。 ＃今日はもう時間が無いのでここで終了です。 つづく。
2004年06月22日
コメント(2)
-
開発と営業の対立（見積り編）
開発と営業の対立は、受託開発の見積りにも起こります。営業は、お客さまと交渉をし、お客さまの予算を知ります。開発は、作業工数で見積りをします。営業は受注を目指すため、価格をお客さま予算に合わせようとします。開発は、単価で計算し、その単価では不満だといいます。これらは、開発の評価が技術的なアウトプットであり、営業の評価は受注額（売上げ）でされる事から発生すると思います。この問題があると、お客さま不在の社内交渉が長引き、結局受注が出来ないという状態になってしまいます。やはり、お客さまとのやり取りに重要なのは、技術が判り、その場で工数が判断でき、価格の交渉ができたり、価格の説明ができる人ではないでしょうか？社内的な評価の仕組みに、開発への売上げや付加価値（粗利など）の指標を導入する必要があります。また、組織的にも売上げや粗利を目指す、プロフィットセンター的（事業部制）な考えが必要になると感じます。営業・開発・製造など、業務を完結できる部隊です。これが、営業部・開発部という機能的な役割の部署分けになっていると、上記の問題が発生するのではないでしょうか？大企業になると、機能別組織の方が効率的になる事はあるとおもいます…
2004年06月20日
コメント(0)
-
エンジニアの動機付け
エンジニアの動機付けは、意外な所にあります。数十名のエンジニアにヒアリングを行うと、とにかく開発をしたいという意見が殆どです。たとえ、それが受託開発であろうと自社の製品であろうと、開発行為を行いそれを達成する所に喜びを感じるという事でした。しかし、お客さまからの評価も、動機付けになる事は事実です。開発者が顧客満足度を意識できるような仕組みを作る必要があります。それには、顧客に対するアンケートが有効です。アンケートにより、開発者自身がお客さまの評価を聞ける仕組みを作っています。実際にやってみると、お客さまの意見は関係ないと言っていた開発者でも、評価されている文面を見ると、目をキラキラさせます。その気持ちが大変重要な動機付けになり、お客さまを意識した開発ができるようになる第1歩になると思います。
2004年06月19日
コメント(0)
-
開発と営業の対立は何故起こるのか？
営業は開発が作った製品が悪いと言い、開発は営業の売り方が悪いと言います。しかし、開発行為と営業を独立に運用していたのでは、この問題が解決する事はありません。開発者は、売れる製品を開発するべきです。先日、新製品の機能決定をする場面があったのですが、エンジニアは実現するのが難しい機能を削除しようとします。つまり、売れる製品ではなく、作れる製品を開発してしまうのです。ハッキリ言って、作れる製品なんて、どこの会社でも作れてしまうのです。つまり、競争力がない。結局価格勝負。価格を下げると結局開発費を回収できないという事になります。まさに悪循環。よっぽど大きな会社で無い限りは、価格戦略に走るべきではないと思います。
2004年06月18日
コメント(4)
全34件 (34件中 1-34件目)
1
