م اتوماسیون دفتری استفاده نشده
مسئولان یک سازمان تولیدی بزرگ در جنوب انگلیس نگران کندی فعالیت های سیستم های اداری شان بودند. هر بخشنامه چند روز طول می کشید تا به مقصدش برسد، و گاهی هفته ها طول میکشید تا
پاسخ ها ارسال شود. تأمین سفارش خرید و خود سیستم سفارش در حال توقف بود، ضمن این که اقلام سفارش داده شده برای تولید موجب کند شدن و حتی متوقف شدن فرایند تولید شده بود. مدیر تکنولوژی اطلاعات صحبت از راه حلی جدید می کرد که کاغذبازی را کاهش می داد و سرعت کل فرایند را بالا می برد. سیستم جدید، سفارش داده شد و نصب گردید. هزینه های نصب این سیستم عبارت بود از: 50000دلار بابت تجهیزات کامپیوتری و 20000دلار بابت خریداری و به کارگیری نرم افزارهای مربوط. اکنون دو سال پس از این اقدام، بخش خرید برای ردیابی سفارشها و سیاهههای فروشاش از کامپیوترها استفاده می کند، اما همچنان منافع موردنظر محقق نشده است، دیگر مشارکت کنندگان موردنظر در شرکت نمی توانند به راحتی از این سیستم استفاده کنند و ترجیح می دهند تا به همان ارتباطات کاغذی تکیه کنند. دلایل بسیاری برای این که چرا چنین شده است وجود دارد. اما مسئله کلیدی این است که تصور می شود سیستم به علت عدم توانایی در برآورده نمودن انتظارات شکست خورده، یا مختصات فنیاش اشتباه است یا این که نمی توان از آن استفاده مفید نمود. در هر صورت سیستم نصب شده و کار می کند. اما بیشتر اوقات بلا استفاده است. پاسخ دهندگان، در عمل، شکست و ناکامی را به شیوه های مختلف ارزیابی و تفسیر می کنند، یعنی وقتی که از آنها سئوال
می شود که آیا یک سیستم شکست خورده است، بر طبق ادراک و برداشت خود از معنای شکست پاسخ
می دهند. اما همه این نمونه ها و موارد شکست به طریقی معتبر و درست هستند و به یک چارچوب
طبقهبندی نیاز دارند که به کمک آن بتوان مفهوم ناکامی سیستم اطلاعاتی را به شکلی روشن تر درک کرد. اولین قدم برداشته شده برای طراحی و تهیه چنین چارچوبی توسط لیتینن و هیرشهایم (1987) انجام شد و تحقیقات انجام شده توسط این دو به عنوان مبنای طبقه بندی قرار می گیرد. از آن جا که مفهوم شکست و ناکامی چیزی است که توسط افراد یا گروه های مختلف به شکل های مختلف تفسیر می شود، موضوع ناکامی سیستم را

می توان به عنوان مسئله ای انسان محور یا کثرت گرا بررسی نمود. این امر به نوبه خود لیتینن و هیرشهایم را ترغیب کرده است که بررسی کنند که آیا ناکامی سیستم ها ریشه در تئوری اجتماعی دارد: ناکامی سیستم ها در وهله اول ناشی از کمبودهای فنی نیست، بلکه ناشی از عدم توجه به آن کسانی است که در سیستم موردنظر درگیرند یا تحت تأثیر آن قرار دارند. افراد درگیر و متأثر از هر سیستمی، انتظاراتی از آن سیستم دارند، و برخی اظهار داشته اند که هدف از طراحی و خاص کردن یک سیستم و توجه به این انتظارات به گونه ای است که طراحی و توسعه آن را تسهیل سازد. این مسئله درست است که در هنگام تعیین ویژگی های یک سیستم،
یا به الزامات کاربر (تأمین نیازهای کاربری که سیستم به دنبال جلب نظر اوست) توجه می شود و یا به طراحی سیستم (معمولاً یک سند فنی تر، شامل بررسی های داده ای و مشخصات فایل و گزارش). متأسفانه، هر ویژگی مکتوبی تنها می تواند شامل زیرمجموعه ای از انتظارات مشارکت کنندگان باشد: همین طور هم باید باشد، زیرا در یک زمان خاص تمام مشارکت کنندگان، همه انتظاراتشان را بیان نکرده اند، یا به خاطر این که به انتظارات خود فکر نکرده اند، یا شاید آنها هنوز انتظارات خود را نشناخته اند. اگر سیستم ها با هدف تأمین یک ویژگی طراحی نشوند، این مسئله مشکلاتی را موجب خواهد شد، زیرا طبق تعریف هیچ مشخصهای نمیتواند تمام الزامات را دربر گیرد: آنچه که واقعاً موردنیاز است این است که طراحی سیستم می باید انتظارات کامل نشده و بالقوه کاربران را تأمین کند. هم زمان با ورود ما به هزاره جدید، تمام این مسائل با آموزش سازمانی پیوند
می خورند، چرا که در هزاره جدید همین که سیستمی طراحی می شود و مورد استفاده قرار می گیرد، انتظارات مشارکت کنندگان افزایش یافته و پالایش می شود. این مسئله لیتینن و هیرشهایم (1987) را بر آن داشت تا ناکامی سیستم های اطلاعاتی را به چهار دسته طبقه بندی کنند: ناکامی انطباق، ناکامی فرایند، ناکامی تعامل،
و ناکامی انتظار. ناکامی انطباق، عبارت است از شکست یک سیستم اطلاعاتی در تأمین الزاماتی که قبلاً بیان شده است و می توان آن را به عنوان دیدگاهی عقلانی و معقول به توسعه سیستم ارزیابی و قلمداد نمود. در این جا فرض می شود مشخصهای که برای یک کاربر تعیین می شود، برای تمام آنهایی که از آن سیستم استفاده
می کنند یکسان خواهد بود، و اگرچه این فرض در برخی موارد صادق است، اما به همین تعداد مواردی وجود دارد که فرض فوق در مورد آنها صدق نمی کند. اغلب عنوان می شود که ناکامی انطباق، شایع ترین نوع شکست سیستم های اطلاعاتی است، اماپرسش های بسیاری دربارهی این نوع شکست بدون پاسخ مانده است ، مثلاً: اگر مشخصات در اولین مورد اشتباه باشد، چه می شود؟ اگر سیستمی که دارد طبق مشخصات تعیین شده کار می کند نتواند آنچه را که می باید، برآورده سازد، آیا سیستمی است با ارزش؟ و غیره.نوع دوم ناکامی، ناکامی فرایند است، و وقتی بروز می کند که یک سیستم را نتوان طبق بودجه مشخص یا در زمان مقرر تولید کرد(کلارک،1388: 108-103).
مثال موردی
خدمات آمبولانس لندن
سیستم خدمات آمبولانس لندن، به محض دریافت درخواست امداد و با توجه به منابع و امکانات خود، اقدام به اعزام آمبولانس به محل میکند و بر پیشرفت کار تمام آمبولانس های اعزامی در محدوده شهری لندن بزرگ نظارت می کند. در این محدوده که وسعت آن ششصد مایل مربع است، حدود هفت میلیون نفر زندگی می کنند. سیستم هر روز به 500،2 تماس و درخواست امداد رسیدگی می کند. در 26 اکتبر 1992، یک سیستم اعزام کامپیوتری جدید اجرا شد، که پروژه ای بدون سابقه تکنولوژیک و عملیاتی قبلی بود. در چهارم نوامبر همان سال، این سیستم کنار گذاشته شد. دلایل ذکر شده برای ناکامی این سیستم به تمام جنبه های ناکامی آن اشاره دارند. برخی از دلایلی مهم ذکر شده عبارتاند از:
سیستم کد موجود بسیار جاه طلبانه و آزمایش نشده بود و بر اساس یک جدول زمانی ناممکن طراحی و اجرا شده بود. به علاوه مدیریت پروژه ضعیف بود.