作業システム

作業システムは、多くの分野で緩く使用されています。この記事は、組織内の IT 依存システムを理解するための作業システムの使用に関するものです。この用語の顕著な使用は、1977 年に MIS Quarterly の第 1 巻に掲載された Bostrom と Heinen (1977) による 2 つの記事で発生しました。その後、Sumner と Ryan (1994) は、CASE (コンピューター支援ソフトウェア エンジニアリング) の導入における問題を説明するためにこの用語を使用しました。Trist や Mumford などの多くの社会技術システム研究者もこの用語を時折使用しましたが、詳細に定義していないようです。対照的に、作業システム アプローチでは、作業システムを慎重に定義し、基本的な分析概念として使用します。

作業システムとは、内部または外部の顧客向けに製品やサービスを生産するために、情報、テクノロジー、その他のリソースを使用して、人間の参加者や機械が作業 (プロセスとアクティビティ) を実行するシステムです。一般的なビジネス組織には、サプライヤーから材料を調達し、製品を生産し、顧客に製品を配送し、顧客を見つけ、財務レポートを作成し、従業員を雇用し、部門間で作業を調整し、その他多くの機能を実行する作業システムが含まれています。

作業システムの概念は、組織内または組織間で運用される多くの種類のシステムに共通する要素のようなものです。運用情報システム、サービス システム、プロジェクト、サプライ チェーン、電子商取引 Web サイトはすべて、作業システムの特殊なケースとして考えることができます。

• 情報システムとは、情報の処理に特化したプロセスとアクティビティを備えた作業システムです。
• サービス システムとは、顧客向けにサービスを生み出す作業システムです。
• プロジェクトとは、製品を生産し、その後消滅するように設計された作業システムです。
• サプライチェーンとは、企業の製品を生産するために必要な材料やその他の入力物を調達するための組織間の作業システムです。
• 電子商取引Web サイトは、購入者が販売者の Web サイトを使用して製品情報を取得し、購入取引を実行する作業システムとして考えることができます。

一般的な作業システムと特殊なケースとの関係は、同じ基本概念がすべての特殊なケースに適用され、特殊なケースには独自の専門用語も存在することを意味します。つまり、現在の情報システム分野の知識体系の多くは、作業システムのコアを中心に構成できるということです。

特定の情報システムは、(他の) 作業システムをサポートするために存在します。情報システムとそれがサポートする作業システムの間には、さまざまな程度の重複が可能です。たとえば、商業マーケティング調査が企業のマーケティング マネージャーに情報を提供する場合のように、情報システムは重複しない作業システムに情報を提供する場合があります。また、高度に自動化された製造や電子商取引 Web サイトのように、情報システムが作業システムの不可欠な部分になる場合もあります。このような状況では、作業システムの参加者は情報システムの参加者でもあり、作業システムは情報システムなしでは適切に動作できず、情報システムは作業システム外ではほとんど意味を持ちません。

• 
  作業システムフレームワーク

システムを理解するための作業システム アプローチには、現在 (または提案されている) 運用中のシステムの静的なビューと、計画された変更と計画外の適応を通じてシステムが時間の経過とともにどのように進化するかについての動的なビューの両方が含まれます。静的なビューは、作業システム フレームワークによって要約され、作業システムを理解および評価するための基本要素を特定します。作業システム フレームワークのわかりやすい三角形の表現は、Alter (2002、2003、2008、2013) やその他の文献で紹介されています。作業システム自体は、プロセスとアクティビティ、参加者、情報、およびテクノロジの 4 つの要素で構成されています。作業システムの操作、コンテキスト、および重要性を初歩的に理解するだけでも、他の 5 つの要素を含める必要があります。これらの要素は、生産される製品/サービス、顧客、環境、インフラストラクチャ、および戦略です。医師が患者を診察する場合のように、顧客も作業システムの参加者になることがあります。このフレームワークは、研究対象のシステムの説明、問題と機会の特定、起こり得る変化の説明、そしてそれらの変化が作業システムの他の部分にどのように影響するかの追跡に役立つほど十分に規範的です。

作業システムフレームワークの 9 つの要素の定義は次のとおりです。

プロセスとアクティビティには、作業システム内で発生するすべてのことが含まれます。多くの作業システムには、事前に定義された方法でトリガーされる、規定された一連の手順を含む高度に構造化されたビジネス プロセスが含まれていないため、ビジネス プロセスという用語の代わりにプロセスとアクティビティという用語が使用されます。このようなプロセスは、その順序と内容が「主要なアクターのスキル、経験、判断に依存する」という「巧妙なプロセス」と説明されることがあります (Hill 他、2006 年)。実際、ビジネス プロセスは、作業システム内のアクティビティを分析するためのさまざまな視点の 1 つにすぎません。独自の価値ある概念と用語を持つその他の視点には、意思決定、コミュニケーション、調整、制御、情報処理などがあります。

参加者とは、作業を実行する人々です。コンピュータや IT を多用する人もいれば、テクノロジーをほとんどまたはまったく使用しない人もいます。作業システムを分析する場合、作業システムの参加者のより包括的な役割は、テクノロジー ユーザー (特定の参加者がたまたまテクノロジー ユーザーであるかどうかに関係なく) のより限定的な役割よりも重要です。サービス システムとして見られる作業システムでは、顧客が参加者であるアクティビティを特定することが特に重要です。

情報には、参加者が作業を行う際に使用および作成されるコード化された情報とコード化されていない情報が含まれます。情報はコンピュータ化されている場合もそうでない場合もあります。作業システムに関連しないデータは直接関連がないため、作業システムを説明または分析する際にデータと情報の区別は二次的なものになります。知識は情報の特別なケースとして考えることができます。

テクノロジーには、作業システムの参加者が作業中に使用するツール (携帯電話、プロジェクター、スプレッドシート ソフトウェア、自動車など) や手法 (目標管理、最適化、リモート追跡など) が含まれます。

製品/サービスとは、作業システムが顧客の利益と使用のために生産する物理的なもの、情報、およびサービスの組み合わせです。これには、物理​​的な製品、情報製品、サービス、楽しみや心の安らぎなどの無形資産、および取り決め、合意、組織などの社会的製品が含まれます。「製品/サービス」という用語が使用されるのは、製品のような製品とサービスのような製品が作業システムが生産するものを特徴付け、設計するための一連の設計次元の基礎であるにもかかわらず、マーケティングとサービス サイエンスにおける製品とサービスの区別 (Chesbrough および Spohrer、2006) は作業システムを理解する上で重要ではないためです (Alter、2012)。

顧客とは、作業システムが生産する製品/サービスから直接利益を受ける人々です。作業システムは顧客のために製品/サービスを生産するために存在するため、作業システムの分析では、顧客が誰であるか、顧客が何を望んでいるか、作業システムが生産するものをどのように使用するかを考慮する必要があります。顧客には、企業の製品/サービスを受け取る外部顧客と、給与計算作業システムの顧客など、企業に雇用されている内部顧客が含まれます。作業システムの顧客は、作業システムの参加者であることがよくあります (例: 健康診断の患者、教育現場の学生、コンサルティング契約のクライアント)。

環境には、作業システムが動作する組織、文化、競争、技術、規制の環境が含まれます。これらの要因は、システムが動作するために直接依存していなくても、システムのパフォーマンスに影響します。組織の一般的な行動規範は組織の文化の一部ですが、作業システム内の特定の活動に関するより具体的な行動規範と期待は、組織のプロセスと活動の一部と見なされます。

インフラストラクチャには、作業システムが依存する人的、情報的、技術的リソースが含まれますが、これらのリソースは作業システムの外部に存在し、管理され、他の作業システムと共有されます。技術的インフラストラクチャには、他の作業システムと共有され、作業システムの参加者には隠されていたり、見えなかったりすることが多いコンピュータ ネットワーク、プログラミング言語、その他のテクノロジが含まれます。純粋に技術的な観点ではなく、Star と Bowker (2002) で表現されているような組織的な観点から見ると、インフラストラクチャには人的インフラストラクチャ、情報インフラストラクチャ、技術的インフラストラクチャが含まれます。これらはすべて作業システムの運用に不可欠であるため、作業システムの分析では必ず考慮する必要があります。

戦略には、作業システムの戦略と、作業システムが存在する部門および企業の戦略が含まれます。部門レベルおよび企業レベルの戦略は、作業システムがなぜそのように機能するのか、また、作業システムが適切に機能しているかどうかを説明するのに役立ちます。

作業システムの動的な見方は、作業システム ライフ サイクル (WSLC) モデルから始まります。このモデルは、作業システムが、運用と保守、開始、開発、実装の 4 つのフェーズを何度も繰り返して進化していく様子を示しています。フェーズの名前は、コンピューター化されたシステムとコンピューター化されていないシステムの両方を表すために選ばれ、アプリケーション ソフトウェアが取得されるか、ゼロから構築されるか、まったく使用されないかに関係なく適用されます。開発と実装という用語は、Markus と Mao (2004) によるシステム開発とシステム実装の区別と一致するビジネス指向の意味を持っています。

このモデルには、計画された変更と計画外の変更の両方が含まれます。計画された変更は、運用と保守のフェーズから始まり、開始、開発、実装を経て、新しい運用と保守のフェーズに到達するという 4 つのフェーズを含む完全な反復を通じて発生します。計画外の変更は、どのフェーズでも発生する可能性がある修正、適応、実験を通じて発生します。フェーズには次のアクティビティが含まれます。

• 作業システムの運用とそのパフォーマンスの監視
• 小さな欠陥を特定し、修正、適応、または回避策を通じて欠陥を排除または最小限に抑えることによって作業システム (多くの場合、それをサポートする情報システムの少なくとも一部が含まれます) を保守します。
• 分析、実験、適応を通じてプロセスと活動を継続的に改善する

• 新しいまたは改訂された作業システムのビジョン
• 運用目標
• リソースの割り当てと時間枠の明確化
• 計画された変更の経済的、組織的、技術的な実現可能性

• 新規または改訂された作業システムに関する詳細な要件（それをサポートする情報システムの要件を含む）
• 必要に応じて、手順、文書、トレーニング資料、ソフトウェア、ハードウェアの作成、取得、構成、変更
• ハードウェア、ソフトウェア、ドキュメントのデバッグとテスト

• 実装アプローチと計画 (パイロット? 段階的? ビッグバン?)
• 変更の根拠とプラスまたはマイナスの影響に関する変更管理の取り組み
• 新規または改訂された情報システムおよび業務システムの詳細に関する研修
• 新しいまたは改訂された作業システムへの変換
• 受け入れテスト

作業システムのライフサイクルの反復的な性質の例として、ソフトウェア スタートアップの販売システムについて考えてみましょう。最初の販売システムは、CEO が直接販売することです。ある時点で、CEO だけでは対応できなくなり、数人の販売員を雇用してトレーニングし、CEO ほど熟練していない人が使用できるマーケティング資料を作成します。会社が成長するにつれて、販売システムは地域別になり、販売追跡ソフトウェアの初期バージョンが開発され、使用されます。その後、会社は、より大きな販売部隊を追跡および管理し、数四半期先の売上を予測するニーズに対応するために、販売システムを再度変更します。その後の反復では、CRM ソフトウェアの取得と構成が必要になる場合があります。作業システムの最初のバージョンは、開始フェーズから始まります。その後の各反復では、現在の販売システムが不十分であると判断すること、ソフトウェアの大幅な変更を伴う場合と伴わない場合があるプロジェクトを開始すること、作業システムの新しいバージョンをサポートするために必要な手順、トレーニング資料、ソフトウェアなどのリソースを開発すること、そして最後に新しい作業システムを実装することが含まれます。

作業システム ライフ サイクル モデルの図式表現では、4 つのフェーズが長方形の頂点に配置されています。各フェーズ間の前方矢印と後方矢印は、フェーズの計画された順序を示し、必要に応じて前のフェーズに戻ることができます。計画された変更と計画外の変更の両方を網羅するために、各フェーズには、予期しない機会と予期しない適応を示す内向き矢印があり、これにより、イノベーションの普及、実験、適応、新たな変更、およびパス依存性の重要性が認識されます。

作業システム ライフ サイクル モデルは反復的で、計画された変更と計画外の変更の両方が含まれます。これは、よく引用されるシステム開発ライフ サイクル(SDLC) とは根本的に異なります。SDLC は、実際にはソフトウェアの作成や作業システムの変更を試みるプロジェクトについて説明しています。現在のバージョンの SDLC には反復が含まれている場合がありますが、基本的にはプロジェクト内の反復です。さらに重要なのは、SDLC のシステムは基本的にプログラムされている技術的な成果物であるということです。対照的に、WSLC のシステムは、複数の反復を通じて時間の経過とともに進化する作業システムです。その進化は、定義されたプロジェクトと、小さな適応と実験から生じる段階的な変更の組み合わせによって発生します。制御指向バージョンの SDLC とは対照的に、WSLC は計画外の変更を作業システムの自然な進化の一部として扱います。

作業システム法 (Alter、2002、2006、2013) は、ビジネス専門家 (および/または IT 専門家) が、特定の関心事に適した任意のレベルの深さで作業システムを理解し、分析するために使用できる方法です。この方法は、1997 年頃から繰り返し進化してきました。各段階で、その時点のバージョンは、MBA および EMBA の学生が実際の目的で使用しようとしたときに成功した領域と経験した困難を評価することによってテストされました。教科書で紹介された「作業中心分析」と呼ばれるバージョンは、組織内のシステムの基本的な説明の一部として、学生がビジネスの問題に集中できるようにし、学生チームのコミュニケーションを支援するために、多くの大学で使用されています。Ramiller (2002) は、学部クラスでビジネスプロセスの概念を「活性化」する方法の中で作業システムフレームワークのバージョンを使用したことを報告しています。研究環境では、Petrie (2004) が、13 の e コマース Web サイトを調査する博士論文で、作業システムフレームワークを基本的な分析ツールとして使用しました。 Petkov と Petkova (2006) は、同じ ERP ケース スタディを解釈する前にフレームワークについて学んだ学生と学ばなかった学生の成績を比較することで、ワーク システム フレームワークの有用性を実証しました。ワーク システム アプローチの実際的な価値に関する最近の証拠は、Truex ら (2010、2011) によるもので、これは、ワーク システム分析テンプレートに基づいて、雇用されている MBA 学生が作成した 75 件、後に 300 件の管理ブリーフィングの結果をまとめたものです。これらのブリーフィングには、どのプロジェクトを追求し、どのように進めるかを決定する際に、WSLC の開始段階で議論されるような分析が含まれていました。

典型的な就職した MBA および EMBA 学生による現実世界のシステムの分析結果から、ビジネス プロフェッショナル向けのシステム分析方法は、ソフト システム方法論よりもはるかに規範的である必要があることが示されています (Checkland、1999)。拘束具ではありませんが、少なくともある程度の手順が必要であり、語彙と分析の概念を提供すると同時に、ユーザーが手元のタスクに適した詳細レベルで分析を実行できるようにする必要があります。作業システム メソッドの最新バージョンは、次の内容を含む一般的な問題解決の概要を中心に構成されています。

• 問題や機会を特定する
• 問題や機会がある作業システム（および関連する制約やその他の考慮事項）を特定する
• 作業システムフレームワークを使用して作業システムを要約する
• 関連データを収集します。
• 設計特性、パフォーマンスの測定、作業システムの原則を使用して分析します。
• 改善の可能性を特定します。
• 何を推奨するかを決める
• 関連する指標と作業システムの原則を使用して推奨事項を正当化します。

コンピュータ化されたシステムの厳密で完全に一貫した定義を作成する必要のある IT プロフェッショナル向けのシステム分析および設計方法とは対照的に、作業システム メソッドは次のようになります。

• ユーザーがどの程度深く潜るかを決めるよう促す
• 作業システムフレームワークと作業システムライフサイクルモデルを明示的に使用する
• 作業システムの原則を明示的に使用します。
• 作業システムとその要素の特性と測定基準を明示的に使用します。
• 作業システムの参加者をシステムの一部として含める（ソフトウェアのユーザーだけでなく）
• 成文化された情報と成文化されていない情報を含む
• IT および非 IT テクノロジが含まれます。
• 推奨事項では、どの作業システムの改善が IS の変更に依存するか、どの推奨される作業システムの変更が IS の変更に依存せず、どの推奨される IS の変更が作業システムの運用形態に影響を与えないかを指定することを提案しています。

• アルター、S.（2002）「情報システムと情報システム研究を理解するための作業システム法」、情報システム協会通信9（9）、9月、pp.90-104、
• Alter, S. (2003)「IT 依存型作業システムが、情報システム分野の中核主題として「IT 成果物」に取って代わるべき 18 の理由」、Communications of the Association for Information Systems、12(23)、10 月、pp. 365–394、
• Alter, S. (2006) 『ワーク システム メソッド: 人、プロセス、IT をつなげてビジネス成果を実現』、カリフォルニア州ラークスパー: Work System Press。
• Alter, S. (2012)「サービスサイエンスの課題」、Journal of Information Technology Theory and Application、第13巻、第2号、第3号、2012年、22～37ページ。
• Alter, S. (2013)「作業システム理論：中核概念、拡張、および将来の課題の概要」 、情報システム協会誌、14(2)、pp. 72–121。
• Bostrom, RP および JS Heinen、(1977)「MIS の問題と障害: 社会技術的観点。パート I: 原因」MIS Quarterly、1(3)、12 月、pp. 17–32。
• Bostrom, RP および JS Heinen、(1977)「MIS の問題と失敗: 社会技術的観点。パート II: 社会技術理論の応用」MIS Quarterly、1(4)、12 月、pp. 11–28。
• Checkland, P. (1999) Systems Thinking, Systems Practice (30 年間の回顧録を含む)、英国チチェスター: John Wiley & Sons。
• Chesbrough, H.、J. Spohrer (2006)「サービス科学のための研究宣言」、Communications of the ACM (49)7、35–40。
• Hill, C.、R. Yates、C. Jones、および SL Kogan、(2006)「予測可能なワークフローを超えて: 巧みなビジネス プロセスにおける生産性の向上」、IBM Systems Journal、45(4)、pp. 663–682。
• Markus, ML および JY Mao (2004)「開発と実装におけるの参加 - 今日の IS コンテキストに合わせて古くて使い古された概念を更新する」Journal of the Association for Information Systems、12 月、pp. 514–544。
• Petrie, DE (2004)「情報システム管理における技術的不連続性の影響の理解: 企業間電子商取引の事例」、クレアモント大学院大学博士論文。
• Ramiller, N. (2002)「情報システムのコアコースにおけるビジネスプロセスの概念の活性化」、Journal of Informatics Education and Research、 3(2)、pp. 53–71。
• Star, SL および Bowker, GC (2002)「インフラストラクチャの構築方法」、L. Lievrouw および S. Livingstone (編)、『新しいメディアのハンドブック』、ロンドン: SAGE、151-162 ページ。
• Sumner, M. および T. Ryan (1994)。「CASE の影響: 重要な成功要因を達成できるか?」Journal of Systems Management、45(6)、p. 16、6 ページ。
• Truex, D.、Alter, S.、および Long, C. (2010)「すべての人のためのシステム分析: ニーズに合ったシステム分析方法によるビジネス プロフェッショナルのエンパワーメント」、第 18 回ヨーロッパ情報システム会議の議事録、南アフリカ、プレトリア。
• Truex., D., Lakew, N., Alter, S., Sarkar, S. (2011)「ビジネス プロフェッショナル向けのシステム分析手法の拡張」、ヨーロッパ デザイン サイエンス シンポジウム、リークスリップ、アイルランド、2011 年 10 月