「vol.1」のカタログの自動作成後のお話です。
その百貨店さんのカタログは非常にスムーズでメーカーさんからも評判がよく、成功した事例だったと思います(その当時の僕は全然理解してませんでしたけど)。
今まで色んな印刷物やってきて、「ここはもう少し何とか出来るんじゃないか?(合理化とか)」と思ってきたんで、自分たちで「データベース作成ソフトウェア」の開発をしてみることになりました。ちょうど仕事も無くなってきてたんで、業務を変える(というか水平移動)には良かったかもしれません。
adEDiXの開発
「自分たちが作業をするのではなく、作業できるようになるものを作って売ろう」ということで、「データベース作成ソフトウェア」を開発することになったわけですが、印刷のみ視点に入れるのではなく、WEBページもそこから自動で生成出来るものでなくてはいけないということで、「XML」を使ったソフトの開発を行うことになりました。
これにデータ入力することで印刷物、WEBページ、携帯サイトまで作れるというものです。これを印刷物やWEB制作ともに持っておられる印刷会社さんに説明し、売り込んでいこうという戦略です。そして[adEDiX]が完成しました。
売り込むのは僕の仕事だったんですけど、何がどうすごいのか?これを導入することで何が変わるのか?そのあたりがとってもイマイチ分からなくて、どうアポイントとって、どう説明して、売り込んだらいいのかさっぱり。そこから勉強して、聞かれた質問はピックアップしてそれをリストに書き込んで、予想される質問も書き込んで答えも用意して、実際にadEDiXを使ってデータ入力して変換してみたり。
その辺りで「データベース」だとか「PHP」だとか「ASP」だとか「SQL」といった単語の意味をなんとなしですがわかるようになりました。
データベースにデータを戻す???
adEDiXの企画書を作って、いろんなとこ行きました。狙いとしてはひとまず印刷会社さん。元々付き合いがあったのと、印刷業界は値段のたたき合いで非常に苦しい状況にあり、何か武器が欲しいという状況でした。話が横道に逸れますが、印刷業界の置かれていた状況をご説明します。
- 東海地区は印刷会社が多いので競争が激しい。
- クライアントによっては「質」より「値段」であり、金額を下げないと「新規受注」ならまだしも「既存受注」も取られる可能性が高い。
- 基本的に業態が「受け身」であるため、後手に回りやすい。
- 赤字でもいいから印刷機を回さなければいけない。
という状況でした。上記の内容を踏まえて僕らが提案したのは、adEDiXを導入(データベース化)することで、
- (クライアントの)データを一元管理出来るので、クライアント離れが起きにくい
- 制作の時間と費用が削減できる
- ミスや校正回数を減らすことができる
- まだ導入してない企業が多いので武器になる
の4点でした。こういったことを説明しながら各社回ったわけですが、帰ってきた答えは
- 仕組みが理解できない。
- InDesignを使ってない。
- ウチの仕事は特殊だから合わない(どう特殊なのかはわからないんですが・・・)。
- データベースにデータを戻せないから使えない。
という答え(細かいのはたくさんありますけどね。「紙が好きなんで」という答えも。どうにも誤解されてるようで)。特に4番目の答えはほぼ全社で言われた内容でして、ちょっと説明がしにくいんですがわかりやすく書きますと
僕らが提案した流れ | よく言われた内容 |
1.データベースにデータを入力 | 1.データベースにデータを入力 |
2.データを各制作物に合わせXML/CSVではきだす | 2.データを各制作物に合わせXML/CSVではきだす |
3.それらを各アプリケーションで読み込む | 3.それらを各アプリケーションで読み込む |
4.各アプリケーションごとで必要あれば微調整 | 4.各アプリケーションごとで必要あれば微調整 |
※入力されているデータに変更がある場合はデータベース側のデータを修正してもう一回2.3.4の作業。 若しくは、各アプリケーションでデータ修正、同時にデータベース側のデータも修正(ただし事故起きる可能性はアリ)。 | ※入力されているデータに変更がある場合は、各アプリケーションで直したデータをデータベースに読み込むようにする。 つまりInDesignなら最終下版InDesignデータをデータベースに戻す。WEBならhtmlをデータベースに戻すといった具合に。 |
という内容でした。これは事故が起きる可能性が高く、信用出来るデータの集合体としてデータベースを構築していたはずが、データを戻すことで、その信用性が下がってしまう可能性が大きいんですよ。
過去に作られたカタログで刷り上がった後に「実はここ間違ってました」なんていうカタログはたくさん見ています(ウチがミスったというわけでなく)。
また前回ご説明したように表記ルール等がバラバラだった場合、データベースの入力項目名も整合性がなくなる。管理者も一人で、制作する人も同じ人でその人しか触らない、というのならまだしも複数人で制作、外注に制作依頼、管理も複数であった場合かなり高い確率で事故が起きます(どのデータが最新情報か分からなくなる)。
エンドユーザーは早かった
というわけで、せっかく開発したにも関わらず全く受け入れられず(売り込んだ先の企業名で出さないか?ともいわれましたけどそれはご勘弁を)、非常に残念な結果となりました。が、無駄ではなく、データベースの考え方や技術は格段に進歩したので、次の開発に役立ちました。(また、そっから取引が増えたりで収益にはつながったのでゼロではなかったです。)
次に提案していったのがカタログやECをやられている企業さんですね。試しにつき合いのあった地元のギガスーパーの販促部の方にアポ取って説明しに行きました。
理解早かったですね。
その担当の方の理解度の問題もあるでしょうが、説明終えたあとの第一声が「これ導入したらウチでもチラシやカタログ作れるじゃん」と。
そのとおりです。テンプレートは用意するので、そこに流し込むだけですからね。
ただ、使いこなせるオペレーターなり管理者なり、「制作部」を設ける必要性はありましたが。その担当者の方は「ウチがいつも使っている印刷会社の社長がこの前来て、これからはこういったシステム化したものでないと仕事が取れない、って言ってた。その時は具体的なことはわからなかったけどこーいうことか」と言われ、色々今後の展開等お話をしましたが、制作部を設けるとなると、人件費が更にかさむのと、教育からやらないといけないので時間がない、ということで話は立ち消えとなりましたが(ただ、今までどこ行っても賛同されなかった分、嬉しかったし、自信にはつながりました)。
その後、カタログを作ってる企業さんやECを展開されている企業さんに提案を行うようになり、以前よりは反応もよく、話も進展しやすくなりました。
スポンサーリンク
[…] データベース化提案への流れ_vol.3 […]
[…] データベース化提案への流れ_vol.3の続きです。 […]