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活用
2006年 01月 12日

仕事の目的 2

システム導入プロジェクトではプロトタイプの検証作業があります。

本番を想定したシステムに本番に近いデータをいれ、擬似本番環境を作り、
ユーザーさんに検証していただきます。

開発側は「システム機能の検証、つまり操作できるかの検証」
をユーザーさんに期待します。

この期待がナンセンスです。なぜかいうと、

 ★システムの機能や操作の方法なんて、ユーザーは全く関心がありません。
  面倒くさいだけです
  仕事のやり方をどうすれば良いのかを知りたいのです。

 ★新しいシステムだから、検証といっても操作するだけで精一杯
  仕事が上手くまわるかなんて検証する余裕はありません

 ★専属担当者がいない中堅中小企業は手が回りません


つまり、プロジェクトではシステム機能を検証するのではなく、
業務プロセスを検証する必要があります。

業務改善がプロジェクトの本質的な目的なので、
業務プロセスの検証が必要なのです。

このようなプロジェクトは大変たくさんあります。

そのようなことから私は、
 現状業務の調査、システム機能の調査(ギャップ分析)、
 新しいプロセスとルールの立案と検証
というようなサービスを提供し、
ITの有効活用で顧客企業に貢献したいと思っています
[PR]

# by operationdesign | 2006-01-12 17:25 | その他
2006年 01月 11日

私の仕事の目的

私は、元小売チェーンの企画部門からERPコンサルタントに転身(転職)しました。
小売業では店長やスーパーバイザーもしていましたので、SI企業へ転職したときは大きなギャップを感じました。

一番大きなギャップは、顧客へ対応です。
今まで、仕事の目的は顧客を満足させることでしたが、
システム導入プロジェクトの現場では、納品が目的化していることが多々あります。
原因はスケジュールや予算、SI企業やユーザー企業など色々あると思いますが、
これでは豊富な機能があるソフトをユーザーさんが使いこなせないのは
当然だとおもいました。

使いこなせない以上、投資効果なんて出るわけありません。
機能が豊富ですから、納期回答期間の短縮や在庫削減、予算管理や
顧客データ分析など改善が見込めることもたくさんあります。

今までは投資効果を算定し、判断をサポートする立場でしたから、
少しでも投資効果を高めたいと思うのは当然でした。

私はシステムを組み立てたり、設定することには興味はなく、
どのように活用したらどのような効果がでるかが興味があります。
この点はエンドユーザーのときから何も変わっていません。
今後も変えるつもりもありません。

では具体的に何をするかといいますと、
導入プロジェクトにおけるユーザーさんがやるべき以下のような業務をサポート
ないしは代行をいたします。
 ●現状業務フローの調査
 ●改善、要求事項の調査と目標の設定
 ●システム機能の検証
 ●検証後のギャップ部分の対応(ルール作り)
 ●新しい業務フローと社内ルールの作成
 ●マスタデータ、伝票データの各項目の入力内容の決定
 ●マニュアル作成フォロー
 ●ヘルプデスク等運用フォロー体制作り

 等、これをユーザーさんと一緒に議論しながら進めていきます。

 SEやプログラマーなど開発者の人なら分かると思いますが、
 このような作業は本来ユーザーさんのプロジェクト参加メンバーがやるべき仕事です。

 でも、開発者側から依頼したとおりの期限と品質ではなかなか対応して頂けないのが
 現状ではないかと思います
 
 それはユーザー企業の担当者も本業で忙しいですし、それよりも多分、
 このような作業に感心がないんですよね!

 私は小売業時代には業務分掌や職務権限規定など業務整理に関連する仕事も
 長くやっていましたした。
 これとERPコンサルタントの仕事を生かし、特に中堅中小企業に業務システムを
 上手く活用し、投資効果を生み出せる仕事をしていくことを目標にしています
[PR]

# by operationdesign | 2006-01-11 18:31 | その他
2006年 01月 10日

本年の初仕事

本年の初仕事は1月6日でした。

ある会合でお知り合いになったSI企業の社長さんの紹介でとある大企業のプロジェクトに私がユーザー業務のサポートや業務視点での問題解決という役割で参加できないか商談させていただいた。

私が提供しているサービスは、システム導入時のユーザー業務を支援し、SI企業とユーザーの橋渡しをすることが目的としていいます。

あまり、具体的ではないので、お客様には非常に分かりにくく、初めて商談したときに即決していただくことはまずありません。

やはり、今回のご商談でも私の仕事とプロジェクトの中での作業に効果的な接点が見えたときに初めて商談が成立することが出来ると思います。

まだまだサービス内容の具体化が不足していると感じた1日でした
[PR]

# by operationdesign | 2006-01-10 17:46 | その他
2006年 01月 07日

自己紹介

まずは私の自己紹介です

◆名前  上嶌昇(ウエシマノボル)
◆住所  京都市北区
◆生年月日  昭和40年7月22日生まれ
◆職業     SAP認定コンサルタント(ERP6.0)
salesforce認定導入コンサルタント
          ITコーディネータ
       
◆経歴   
1988年京都外国語大学英米語学科卒業後、アパレル小売店の全国チェーンに入社。店長・エリアマネジャーを経験。のべ20店舗以上に携わり、営業力向上と顧客サービスの改善に取り組み、チェーンストアオペレーションを体験により習得する

その後経営企画室に異動し、経営計画予算作成業務やIR業務などを行うかたわら、店舗属性別商品供給システムの構築、MDプロセス改革、ローコストストアオペレーションの構築など多数の業務改革プロジェクトを推進する

2002年、37歳の時に自分の可能性を求めてSAPコンサルタントとしてソフトハウスに転職。SAPのカスタマイズとABAPを死にもの狂いで覚え、2年目から中堅企業のSAPプロジェクトの要件定義フェーズに参画する。

3年目からは大手製薬業のSAPプロジェクトに参加し、アドオンの設計、開発スキル及び移行やプロジェクト進捗管理も担当し、ノウハウを身につける

2009年に、SaaSによる業界の大きな波を感じ、セールスフォース導入のコンサルタントとして独立して事業を行うことを決意。今日に至っている。

2010年1月株式会社アップオンデマンドを設立。現在事業を軌道に乗せるため奮闘中
[PR]

# by operationdesign | 2006-01-07 18:38 | プロフィール
2006年 01月 06日

祝 ブログ開設

私のブログへご訪問いただいた皆さん
はじめまして パッケージソフトの導入コンサルタントをしています上嶌昇といいます。

2006年を迎えるにあたり、区切りの良いところでブログをはじめることにしました。
主に私の仕事(パッケージソフト導入のコンサルタント)に対する考え方や出来事を中心に綴って行きたいと思います。

どうぞよろしくお願いします
 
[PR]

# by operationdesign | 2006-01-06 15:08 | その他