社内SEとして必要な業務の設計・改善のスキルは？

質問

お世話になります。

私は小さいネット専業の小売業の会社の社内SE担当となり、約1年ちょっと経ちました。

社内SEとしての業務は幅広く、大きく分けると社内のPCやLANなどのインフラの運用と、
基幹の販売管理システムのトラブル対応などのヘルプデスク、機能改修などのシステム開発です。
この販売管理システムは開発ベンダーが開発し、保守してもらっています。

上記のインフラの運用については、問題なくこなせているのですが、
基幹の販売管理システムについて、スキル不足を痛感しております。

この販売管理システムですが、当社はネット専業の小売業なので、
お客様からのネットからの注文の受注の処理から倉庫への出荷データの送付、倉庫との在庫データの連携、
商品の登録などのマスタ登録、そして仕入先への商品の発注等、
このシステムで当社の業務のほぼ全て担っております。

スキル不足を痛感する部分なのですが、約1年ちょっとでこの
販売管理システムのトラブル対応（要はヘルプデスク）が問題なく
できるようにはなったのですが、このシステムの前提となる社内の業務の知識がなく、
業務とこの販売管理システムのつながりが理解できておりません。

まだシステムの個々の機能の部分的な理解でしかなく、販売管理システム全体の理解と社内業務
の繋がりが整理できておりません。

ですので、会社で何か新しいことを始めようとした時に、受注の業務がどのように変わるのかなどを
全く提案することができずに大変困っております。

私としては、このようなスキルを習得するためには、「業務設計」の知識が必要なのではないかと
感じ、以下の本で少し勉強してみましたが、初心者の私にはちょっと敷居が高く、なかなか進みません。
↓
http://www.amazon.co.jp/%E6%A5%AD%E5%8B%99%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%83%A2%E3%83%87%E3%83%AA%E3%83%B3%E3%82%B0%E7%B7%B4%E7%BF%92%E5%B8%B3-%E6%A5%AD%E5%8B%99%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%82%92%E5%8A%B9%E6%9E%9C%E7%9A%84%E3%81%AB%E8%A8%AD%E8%A8%88%E3%81%99%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AE%E7%B2%BE%E9%81%B845%E9%A1%8C-%E6%B8%A1%E8%BE%BA-%E5%B9%B8%E4%B8%89/dp/4822282856/ref=pd_sim_b_5

ちなみに以前、数週間、受注の業務の研修に入らせてもらいましたが、何せ時間が経つと業務内容を
忘れてしまうので（全てメモにまとめてますが、これは私の覚えが悪いのですが、、、）、急に受注業務
のトラブルを質問されてもいちいち調べたりすることも結構大変です。

私としては、社内SEとして、ヘルプデスクより上に行くには業務の設計ができ、かつシステム側からの
最適な改善案を出せるようになることが必須と感じております。

また、恐らく来年、この販売管理システムを見直す（刷新する）かもしれないので、その前段階として
現在の社内の業務を覚えておくことは必須だと思っております。

ですので、こうした業務設計のスキルを何とか身に着けたいと思っておりますが、参考となる
書籍やWebサイトがございましたら、ぜひ教えていただけないでしょうか？

ご自身の経験からのアドバイス等でも全然構いません。

ちなみに、当方は今までずっとヘルプデスク中心の業務でしたので、フローチャートすら書いたことのない初心者です。
そのような初心者が入り易い情報を教えていただけると幸いです。

不足した情報がございましたら加筆しますので、どうぞよろしくお願いいたします。

回答No.3

sppla · ベストアンサー

以前は販売管理システムの設計、開発のＳＥをしており、今は社内ＳＥをやっているものです。

社内ＳＥ側で必要なのは自社業務の把握でしょう。
開発側のＳＥとして何社かのお客様を見てきましたが、各社それぞれのやり方があります。

まずは流れ図のようなものを作成してみたらどうでしょうか？
お客様からの注文の受付から始まり、商品の出荷まで、代金の請求までの流れ図を書いてみます。
この際に、どういうタイミングで社内の誰が（どこの部署が）何をするか？という点と、どういうタイミングで販売管理システム（さらにはどの画面）を使うのか？そういう点を意識して図を書いてみてください。

この図であいまいな部分を現場に聞いてより正確な図にしていきます。
図が書けたら業務間のつながりや業務とシステムの関連がわかるはずです。

あなたの会社や販売管理システムの機能はわかりませんが、私の頭の中での架空の会社の例で説明しますと
・お客様が注文をＷＥＢフォームで入力する。
・ＷＥＢフォームの入力結果をＡさんがメールで受け取り、これをもとに販売管理システムの受注入力画面で入力する。
・Ｂさんは一日３回、受注状況と在庫を画面で確認する。
　在庫があれば出荷を指示し、なければ発注入力画面で発注の入力を行う。
　入力後に発注書を仕入れ先にＦＡＸする。
・Ｃさんは、仕入れ先から商品を受領したら在庫画面で入庫の入力を行う。
　（これが次回のＢさんの在庫チェックで在庫として認識される）
etc・・・
こういったことを流れ図で表現してみます。

時系列がわかる、人と人（やシステム）のかかわりがわかるように表現します。
下記URLの図１のようなものを私は作成します。（Excelで書きますが）
http://www.ogis-ri.co.jp/otc/swec/process/am-res/am/artifacts/sequenceDiagram.html

次に、一般的にはどのような作業が行われるのかの知識を習得しましょう。
書名はあげられませんがＳＥ向けに業務知識を解説した本というのがいくつかあります。
一般的な話を知ることで、自社と一般的な業務との違いなどが分かります。

業務設計は現状を理解したその先の話ですね。

お礼

ご回答いただきまして、ありがとうございました。

＞まずは流れ図のようなものを作成してみたらどうでしょうか？

私も図を全く作成したことがなく、業務の流れを図示で着ない状態なのです。
でも、教えていただいたサイトのやり方（UMLというのでしょうか）を早速やってみます！

今後の流れとしては
(1)　現在の当社の業務を図にして、あいまいな部分は各担当者に確認してより明確・正確にする
(2)　一般的な業務知識をSE向の本で習得し、自社との違いを理解する
(3)　(1)、(2)で当社の業務を理解し、来年のシステム刷新に向けて業務改善を意識して業務設計する

ということになるか、と思います。

業務設計については、自分で参考書を探してみます。

ありがとうございました。

回答No.2

itou2618

社内の業務を覚えるには、現場に出向くのが一番です。
せっかくヘルプデスクの対応をされているのですから、その問合せがくる業務のことを逆に教えてもらえばいいのでは。
来年にシステムの刷新があるのでしたら、今は社内の業務を覚えることを優先されたほうが良いと思います。
それと各部門のキーマンになりそうな人と顔なじみになっておくことです。
システム構築のとき、業務設計を行いますが、やり方は開発ベンダーから提案があるはずです。
ユーザー側は要件定義から外部設計までを主体的に行うことになると思います。
システムの内部設計、プログラム設計、プログラム開発などは開発ベンダーが主体的に行うのが普通です。
システムテストは外部設計で決めたとおりの仕様を満たしているかのテストになりますから、ユーザー側で検証しないといけません。
たぶん、現在の社内業務すべてを熟知することは、難しいでしょうから、各部門に顔を売って、聞ける人を作っておくことを勧めます。

補足

ご回答、ありがとうございます。

＞せっかくヘルプデスクの対応をされているのですから、その問合せがくる業務のことを逆に教えてもらえばいいのでは。

そうですね。私も問い合わせが来たときは、その業務を以前研修してもらった時にメモした内容を再確認しております。
ただ、業務の範囲がかなり広くて、なかなか覚えられない（汗）

＞システム構築のとき、業務設計を行いますが、やり方は開発ベンダーから提案があるはずです。

そうだったんですね。
でも、現状の業務フローもしっかり押さえておく必要があるかと思います。

＞たぶん、現在の社内業務すべてを熟知することは、難しいでしょうから、各部門に顔を売って、聞ける人を作っておくことを勧めます

そうですね。幸い小さい会社ですので、コミュニケーションはとれております。

もしご存知であれば教えてほしいのですが、現状の業務を押さえておくために、フローチャートなどを書いてみたいのですが、
初心者に最適な参考書やWebサイト等ご教授いただけると幸いです。

たびたびお願いして恐縮ですが、よろしければお願いいたします。

回答No.1

IDii24

難しい話ですが、社内のＳＥと外部ＳＥの決定的な違いは業務を理解しているという事です。昔はコンピューターなんて知らなくても、業務を熟知していればシステム部に配属されたものです。つまりＩＴの技術的な事は外部からリソースを調達できるが業務知識は内部で育てるものと区別されているからですね。
これがオープンシステムになりインフラが重要な位置になってから社内でも技術者が必要になり、じゃあ彼らと業務系ＳＥをどう分けるかで各社悩んだ末、結局融通の利かないインフラはグループ会社化して違う会社にしてしまうというのが今の方針です。
つまり生き残るには業務を知るべきと言う事になります。モデリングは手法ですからそこから学べるものは書き方しかありません。まずはアイディアを頭に描けるかですから、何が何でも先に業務を覚える事で、結局は其れを知らないとＨｅｌｐも出来ない事になります。
本当は各部で業務を手伝わせてもらうのが一番ですし、あるいは他の部の人となるべくコミュニケーションを普段から取るという事でしょう。
大きい会社だとそういうわけにもいかずシステム部だけで偏った知識しか持てなくなります。結局そこに生じるのは意思疎通の為のドキュメント。つまりドキュメントは知識の無い人に伝える手段として細かくなったのです。
小さい会社なら最低限のドキュメントでいいはずです。まず外部のＳＥには言葉で伝えられれば良いし、社内では内部統制的なドキュメントだけで十分です。
独りよがりにならず、後に入る人が見て業務がすぐ継続できる（ＢＣＰ）ドキュメントを中心に書いていくことをお勧めします。
ＢＣＰに係るシステムドキュメントは会社の財産です。これを用意することは現在の日本において必ず必要で、しかもあなたの仕事です。まずこれを研究した方がいいと思います。

お礼

早速のご回答、ありがとうございます。社内SEが必要とされるようになった背景等、よく分かりました。

＞本当は各部で業務を手伝わせてもらうのが一番ですし、あるいは他の部の人となるべくコミュニケーションを
＞普段から取るという事でしょう。

そうですね。業務部門とのコミュニケーションは重要ですね。私の会社は小さい会社ですので、コミュニケーションは
取れていると認識しております。ただ、業務の細かい部分での突発的な質問にはなかなか対応できなくて冷や汗なのですが（笑）。

＞後に入る人が見て業務がすぐ継続できる（ＢＣＰ）ドキュメントを
＞中心に書いていくことをお勧めします。

BCPを具体的に検討したことはなかったです。特に、「後に入る人が見て業務がすぐに継続できる」
という視点は必須ですね。
ぜひ、検討させていただきます。
ありがとうございました。