ноябрь    2024

Пн	Вт	Ср	Чт	Пт	Сб	Вс
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30

показать все 

14.11.2024

Обновление BI.ZONE Secure DNS: гибкая настройка фильтрации и максимальная скорость

Читать далее 

14.11.2024

RED Security: в октябре количество DDoS-атак на ТЭК выросло в 3 раза

Читать далее 

14.11.2024

Falcongaze представила новую версию DLP-системы — SecureTower 7 Helium

Читать далее 

14.11.2024

ИСП РАН покажет результаты 30-ти лет работы на Открытой конференции в Москве

Читать далее 

08.11.2024

Юбилейная конференция ЭОС: ЭОС: 30 лет лидерства на рынке автоматизации документооборота и обсуждение актуальных трендов

Читать далее 

показать все 

22.11.2024

Тандем технологий – драйвер инноваций.

Читать далее 

21.11.2024

ИИ: маршрут не построен, но уже проектируется

Читать далее 

18.11.2024

Глеб Шкрябин: «Надежные и масштабируемые системы — основа стабильной работы бизнеса в условиях больших нагрузок»

Читать далее 

14.10.2024

Елена Ситдикова: «На разработчиках программного обеспечения для транспорта лежит большая ответственность перед пассажирами»

Читать далее 

11.10.2024

Технологический ИИ-арсенал

Читать далее 

13.06.2024

Взгляд в перспективу: что будет двигать отрасль информационной безопасности

Читать далее 

18.04.2024

5 способов повысить безопасность электронной подписи

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

Читать далее 

18.04.2024

Скоро некому будет делать сайты и заниматься версткой

Читать далее 

показать все 

Главная / Архив номеров / 2014 / Выпуск №9 (42) / Успех информационных систем

Рубрика: ИТ-управление

Алексей Лагутенков, MBA Kingston University UK, ITSM Manager, MCSE+I, MCSE:S:M, MCDBA, MCDST

Успех информационных систем

Статья посвящена обзору научных трудов классиков теоретического информационного менеджмента, работам Уильяма Делона и Ефрема Маклина (William H. Delone & Ephraim R. Mclean). Разработан и предлагается вниманию читателей метод, позволяющий провести качественную оценку любой существующей либо планируемой к внедрению информационной системы

Как и во многих других областях, в ИТ существуют лишь теоретические знания и модели. Зачем это нужно? Информационные технологии всегда требуют конкретного ответа на конкретный вопрос. Экономиста, юриста или менеджера можно спросить о чем-то и получить длинный, расплывчатый и абсолютно ничего не проясняющий ответ, который тем не менее ответ. С ИТ такой номер не проходит. «Я не могу войти в сеть. Что делать?» Нельзя ответить: «Подожди пару дней, тренд переломится, и ситуация, возможно, улучшится». Работать надо прямо сейчас, поэтому нужен абсолютно конкретный алгоритм действий, что и как сделать, чтобы снова стало возможным войти в сеть.

С такой точки зрения научные, теоретические исследования в ИТ несут не особо много смысла. Зачем что-то исследовать, если это впоследствии нельзя запустить в виде исполняемого кода? Зачем нужно заморачиваться какой-то теорией и абстракциями, когда можно купить более мощный сервер, новый софт или, если софта не существует, запустить проект по его разработке? ИТ – это чистая конкретика. Нужна БД – покупаем сервер и софт СУБД, нужен сайт – нанимаем дизайнеров и программистов и т.д.

Какова же роль теории и науки в ИТ? Представьте: предприятие перешло на новую, более современную, продвинутую информационную систему (ИС). Совсем неважно, что это за система: ERP, документооборот, CRM или что-то еще. Важно другое. Пользователи в один голос говорят, что стало хуже. Что именно стало хуже? Так сразу и не объяснить. Работает система быстро? Вроде быстро. Отчеты позволяет печатать? Вроде позволяет. Тогда что не устраивает? Все не устраивает! Как-то все не так. Может, с непривычки? Тоже нет. Система уже довольно давно в эксплуатации. Сотрудники в один голос говорят, что старая система была лучше и удобнее. Хуже всего, когда начальство тоже присоединяется к этому хору недовольных.

Самое неприятное, что предъявить разработчикам нечего. Все работает? Да, работает. Сбои какие-то есть? Нет, серьезных сбоев нет. Функционал не может не устраивать, поскольку вы, заказчики, сами его прописывали в техническом задании.

Бывает так, что предприятие, внедрив ИС, не подстраивает ее под свои нужды, а, наоборот, само адаптируется под конфигурацию системы. В этом случае информационная система, вместо того, чтобы стать локомотивом, который тащил бы компанию вперед, начинает явно или неявно мешать бизнесу.

Например, надо разработать новую необычную рекламную кампанию, которая привлекла бы клиентов в условиях возросшей конкуренции. Текущий функционал жестко предусматривает бюджетирование двух видов рекламных кампаний, которые уже использовались не один раз. Любые модификации системы настолько дорогие, что проще что-то разработать на бумаге. Правда, все бумажные разработки обречены пойти в мусор, поскольку их нельзя завести в систему и рассчитать бюджет. В итоге те же, уже неэффективные, рекламные активности, потраченный на них бюджет, потерянные клиенты и потерянная доля рынка. Только из-за отсутствия гибкости.

Другой пример. Может случиться так, что CRM не одобряет и не поддерживает подарки и сувениры клиентам. Поправить функционал нельзя, поскольку все уже мертво завязано с бухгалтерией, не желающей понимать представительских расходов.

Бывают еще системы ERP, не имеющие возможности ввести новый необычный вид товара в номенклатуру или не поддерживающие непрофильное направление бизнеса. Звучит дико, но отсутствие «галочки» в нужном месте в системе иногда может убить бизнес, поскольку конкуренты имеют эту «галочку» и предоставляют услуги лучше, быстрее или дешевле.

Вроде бы это и не вопросы ИТ вовсе, об этом другие люди должны были подумать. Однако внедряли-то систему вы. Кто виноват в том, что система не нравится и в ней возникли такие сложности? Поставщик или разработчик? Вряд ли. Виноват тот, кто ближе и получает зарплату.

Как можно предугадать заранее, что с системой будет что-то не так? Как вообще принять решение, что текущую систему надо менять и что в ней надо менять? Для таких задач, где невозможно дать четкого ответа в цифрах, что и насколько лучше или хуже, и существует научный подход.

Как показывает опыт, инженеры ИТ и даже CIO и IТ-директоры не всегда понимают абстрактные методы оценки. Прежде чем переходить к науке, давайте поговорим о том, каким способом можно оценить нечто, что не имеет конкретных цифровых значений.

О чем разговор? Ученые говорят, что существует два подхода к оценке чего-либо: «количественный» и «качественный». «Количественный» – это просто и понятно. Это конкретные цифры. Например, внедрили новый софт, и выручка предприятия выросла на 6%. Если мы поверим сами и сможем убедить начальство, что между двумя этими событиями есть прямая связь, то сон наш будет крепок и здоров, а карьера крута и молниеносна!

«Качественная» оценка – она тоже понятная и простая, но не такая конкретная. «Качественно» определяют нечто, что нельзя конкретно измерить. Например, вы заблудились в лесу, проголодались и видите, что высоко на березе растет апельсин. Вы хотите сбить его палкой. Какая палка нужна? Длинная. Насколько длинная? Настолько, чтобы достала до апельсина, и определенно длиннее той, что до него не достала. Вопрос, почему на березе растет апельсин, относится к другой науке, ботанике, для которой есть свои журналы. Поэтому здесь мы на него отвечать не будем.

«Качественно» – означает без цифр. Можно сказать, это эмоционально-понятийная оценка, связанная с суждениями человека. Пары суждений: «лучше – хуже», «длиннее – короче», «медленнее – быстрее», «больше – меньше» – вот критерии качественной оценки.

На первый взгляд может показаться, что это совершенно антинаучно – применять такую оценку. Что, если человек, которого мы просим что-то сравнивать, ошибается, и на самом деле все наоборот? Как вообще можно в оценке чего-либо опираться на суждение человека «лучше/хуже»?

Во-первых, наука создана людьми и для людей. И как раз только люди и могут сказать, что есть «хорошо» и что есть «плохо». А, во-вторых, человек – удивительно точное существо с прецизионными интуитивными измерителями окружающего мира. Тренированному глазу заметна разница между предметами в 0,05 миллиметра. Минимальный воспринимаемый человеком интервал времени – около 100 миллисекунд или 0,1 секунды. Таким образом, хотя мы и не всегда можем дать точный ответ, сколько это нечто весит в граммах, насколько оно большое или длинное в миллиметрах, но мы всегда можем сказать, что это нечто легче или тяжелее, длиннее или короче. И в большинстве случаев такой оценки бывает достаточно.

Вернемся к информационным технологиям. Лучше или хуже новая информационная система? Например, хуже. Насколько? Не очень сильно. По ощущениям раньше оно работало быстрее, понятнее и надежнее.

Что «улучшилось» или «ухудшилось», можно определить только с помощью качественного измерения. Как именно? С помощью опроса сотрудников! Составьте анкету, что именно вы хотите узнать. В анкете напишите: «Оцените от 1 до 5 работу новой системы. 1 – все очень плохо, верните старую систему, 3 – ничего не изменилось и 5 – все идеально, ничего не трогайте!». Соберите ответы и посчитайте среднее арифметическое. Вот вам и ответ, все ли хорошо с новой системой.

В чем могут быть сложности? Всегда следует помнить, что вы работаете с людьми. Оценки могут быть предвзятыми, на них могут влиять настроение, степень умения работать с новой системой и многое другое. Поэтому результаты измерения в разные моменты времени могут быть разные. Еще одна проблема в том, что мы задаем уж слишком общий вопрос. Все ли хорошо со всей системой вообще? А если кому-то определенные моменты нравятся, а другие не нравятся, как это учесть и что вообще следует учитывать при опросах, а что нет?

Мы вплотную подобрались к мысли, что нужна некая «качественная» модель, позволяющая проводить измерения «хорошести» любой системы.

Такая модель существует. Это знаменитая и широко известная в научных кругах модель Маклина и Делона «Information Systems Success: The Quest for Depend Variable» (1992) [1]. Вольный перевод «Успех информационных систем: в поисках зависимой переменной». Работа по праву считается классикой в области теории ИТ (см. рис. 1).

Рисунок 1. Базовая модель Делона и Маклина «Information Systems Success: The Quest for Depend Variable» 1992 года

В чем суть? Что имеется в виду под «успехом»? Ответ прост: насколько хорошо и удобно работать с системой сотрудникам и насколько хорошо новая система отвечает требованиям бизнеса.

Модель состоит из шести переменных:

1. SYSTEM QUALITY («Качество системы»).
2. INFORMATION QUALITY («Качество информации в системе»).
3. USE («Использование информации в системе»).
4. USER SATISFACTION («Удовлетворенность пользователя работой системы»).
5. INDIVIDUAL IMPACT («Влияние системы на отдельного работника»).
6. ORGANIZATION IMPACT («Влияние системы на всю организацию в целом»).

Рассмотрим каждый модуль подробнее.

SYSTEM QUALITY. «Качество системы»

Предположим, предприятие внедрило новую ИС. Допустим, все работает очень быстро. Правда, чтобы произвести элементарное действие, необходимо открыть не меньше двух десятков окошек. Где-то что-то надо обязательно перетаскивать мышкой из одного окна в другое. Где-то что-то скопировать и вставить через Ctrl+C и Ctrl+V. Сотрудники быстро устают в течение рабочего дня из-за такого обилия активностей в системе, внимательность падает, и появляется много ошибок. Это лишь один из примеров.

«Качество системы» предлагается оценить с помощью 18 параметров:

• Data accuracy (точность данных).
• Data Currency (актуальность данных).
• Database contents (содержание данных).
• Ease of use (легкость использования данных).
• Ease of leaning (легкость обучения пользованию данными).
• Convenience of access (удобство доступа к данным).
• Human factors (человеческий фактор).
• Realization of user requirements (реализация требований пользователей).
• Usefullness of system features and functions (полезность системных опций и функционала).
• System accuracy (точность системы).
• System Flexibility (гибкость системы).
• System reliability (надежность системы).
• System sophistication (сложность системы).
• Integration of systems (степень интеграции системы).
• System efficiency (эффективность системы).
• Resource utilization (использование ресурсов).
• Response time (время отклика).
• Turnaround time (время полного жизненного цикла системы).

INFORMATION QUALITY. «Качество информации»

Пусть в страховой компании внедрена очень хорошая информационная система: быстрая, надежная, удобная, высоко интегрированная, эффективная, работающая всего на 1% загрузки сервера. Предположим, мы хотим получить страховую историю некоего автовладельца, товарища Иванова. Хочется знать, были ли у него аварии, по чьей вине и сколько раз. Предположим, что информационная система, работающая у нас, настолько хороша, что выдает полное досье на Иванова. Вплоть до того, что в 2001 году был страховой случай по заливу соседей горячей водой, а в 2003-м – просрочки по оплате кредита, выданного неким банком на покупку холодильника. Зарплата 30 000 рублей в месяц, увлекается рыбалкой. Вот только о его машинах, штрафах ГИБДД и авариях в этом досье нет ни слова. Данные не содержат самого главного и, как следствие, абсолютно бесполезны для бизнеса компании. «Качество информации» предусматривает 23 критерия:

• Importance (важность данных).
• Relevance (адекватность данных).
• Usefulness (полезность).
• Informativeness (информативность).
• Usableness (возможность использования).
• Understandability (понятность).
• Readability (читаемость).
• Clarity (четкость).
• Format (формат).
• Appearance (как выглядят).
• Content (содержание).
• Accuracy (аккуратность).
• Precision (точность).
• Conciseness (краткость).
• Sufficiency (достаточность).
• Completeness (полнота).
• Reliability (надежность).
• Currency (употребимость).
• Timeliness (своевременность).
• Uniqueness (уникальность).
• Comparability (сравнимость).
• Qualitativeness (сравнимость по качественным характеристикам).
• Freedom from bias (отсутствие ненормализованных данных).

INFORMATION USE. «Использование информации»

Предположим, предприятие покупает новую замечательную информационную систему. Быструю и надежную. Сотрудникам в ней нравится все: интерфейс, скорость работы, отчеты и т.д. Правда, через некоторое время выясняется, что 95% всей деятельность компании ведется в старой системе. Медленной и неудобной. Новую же систему все хвалят, но никто ею не пользуется. Как такое возможно? Например, новая система слишком специфично заточена под определенную операционную деятельность, необходимость в которой возникает нечасто. А вот все остальные операции в новой системе неудобны, требуют существенно больше времени и внимания. «Использование информации» подразумевает 12 критериев:

• Amount of use/duration of use (объем использования/время использования). Оценивается по нескольким параметрам:
• Number of inquires (число запросов к системе).
• Amount of connect time (время работы в системе).
• Number of functions used (количество используемого функционала).
• Number of records accessed (количество данных, к которым осуществляется доступ).
• Frequency of report requests (частота использования отчетов).
• Number of reports generated (количество созданных отчетов в системе).
• Charges for system use (плата за использование системы).
• Regularity of use (регулярность использования).
• Use by whom (кем используется).
• Direct vs. chauffeured use (используется напрямую в интересах компании или позволяет что-то делать только в интересах третьих лиц).
• Binary use (двоичность/двойственность использования системы).
• Use vs. nonuse (вообще используется или нет).
• Actual vs. reported use (действительное и заявленное использование системы).
• Nature of use (с какой целью используется система).
• Use for intended purpose (используется по прямому назначению).
• Appropriate use (надлежащее применение).
• Type of information used (тип используемой информации).
• Purpose of use (цель использования).
• Levels of use (уровни использования).
• General vs. specific (общее или специфическое использование).
• Recurring use (повторность или периодичность использования).
• Institutionalization/routinization of use (рутинность использования).
• Report acceptance (удовлетворительность отчетов).
• Percentage used vs. opportunity for use (отношение процента использования к возможности использования).
• Voluntariness of use (добровольность использования).
• Motivation of use (мотивация использования).

USER SATISFACTION. «Удовлетворенность пользователя»

Если предыдущие разделы не были особенно привязаны к конкретному человеку, то с «Удовлетворенности пользователя» начинается та часть модели, которая ориентирована на конкретного человека. Всего предлагается рассмотреть семь критериев:

• Satisfaction with specifics (удовлетворенность специализацией ИС).
• Overall satisfaction (общая удовлетворенность ИС).
• Single-item measure (удовлетворенность одним, конкретным компонентом).
• Multi-item measure (удовлетворенность работой компонентов в системе).
• Information Satisfaction: (удовлетворенность информацией).
• Difference between information needed and received (разница между необходимой информацией из системы и тем, что система реально выдает).
• Enjoyment (удовольствие от пользования системой).
• Decision-making satisfaction (удовлетворенность возможностью принимать решения в системе или с помощью системы).

INDIVIDUAL IMPACT. «Влияние системы на отдельного работника»

Если сотрудники говорят: «Вроде бы все работает, но система мне не нравится», то это повод задуматься. За эмоциональной оценкой могут стоять совершенно конкретные технические недочеты. Оценка состоит из 14 критериев:

• Information understanding (понятность информации).
• Learning (обучаемость).
• Accurate interpretation (точность понимания).
• Information awareness (информированность или осведомленность пользователя).
• Information recall (запоминаемость информации) .
• Problem identification (возможность идентифицировать проблему).
• Decision effectiveness (эффективность принятия решений).
• Decision quality (качество принимаемых решений).
• Improved decision analysis (анализ для повышения качества решения).
• Correctness of decision (правильность принимаемого решения).
• Time to make decision (время, необходимое для принятия решения).
• Confidence in decision (формирование уверенности принимаемого решения).
• Decision-making participation (возможность участвовать в принятии решения) .
• Improved individual productivity (насколько улучшает личную производительность труда).
• Change in decision (насколько помогает изменять уже принятые решения).
• Cause management action (помогает понять причины действий руководства).
• Performance (помогает измерять личную продуктивность).
• Quality of plans (качество планирования).
• Personal valuation of IS (личная оценка информационной системы).
• Willingness to pay for information (готовность платить за информацию).

ORGANIZATION IMPACT. «Влияние системы на всю организацию в целом»

Разумеется, информационная система должна быть полезна бизнесу, которым занимается компания. Информационная система предприятия часто состоит не из одной суперпрограммы, но из множества различных приложений, которые могут запускаться как в рамках системы, так и за ее пределами. В этом разделе оцениваются как количественные экономические переменные, так и качественные показатели. Всего в модели предусмотрено 14 критериев:

• Application portfolio (набор/портфолио приложений системы):
• Range and scope of application (диапазон и объем применения приложений системы).
• Number of critical applications (количество критически важных приложений в системе).
• Operating cost reductions (насколько система позволяет снизить операционные расходы).
• Staff reduction (насколько система позволяет сократить численность персонала)
• Overall productivity gains (общий рост производительности).
• Increased revenues (увеличение доходов компании).
• Increased market share (увеличение рыночной доли предприятия).
• Increased profits (увеличение прибыли).
• Return on assets (рентабельность активов, ROA).
• Ratio of net income to operation expenses (отношение чистой прибыли к операционным расходам).
• Cost/benefit ratio (соотношение затраты/прибыль).
• Stock price (стоимость акций на бирже или капитализация компании).
• Increased work volume (увеличение объема работы).
• Product quality (влияние на качество продукта/услуги).
• Contribution to achieving goals (вклад в достижение целей).

Конечно же, не стоит думать, что абсолютно все вышеназванные критерии оценки подойдут именно вашей системе и бизнесу именно вашего предприятия. Что-то подойдет идеально, а некоторые параметры будут просто не применимы. Какие переменные важны именно для вашей системы, определять вам. Модель просто перечисляет все возможности, из которых следует выбирать и строить свою схему оценки. Во второй части будет рассказано о том, как практически применить модель и какие изменения в ней произошли с 1992 года.

Приведу пример практического использования модели для оценки работы ИС предприятия, а также рассмотрю изменения, добавившиеся в модель за 22 года существования.

Какова практическая польза от столь объемного framework?

Во-первых, это возможность качественно оценить имеющуюся ИС перед тем, как затевать реинжиниринг бизнес-процессов. Как понять, что именно не устраивает в текущей системе? Да, она медленно работает, в ней не хватает функционала, но существовало же как-то с ней предприятие долгие годы. Не получится ли так, что новая система – не «революционный» шаг вперед, а всего лишь эволюционировавшая старая, с чуть расширенным функционалом за космические деньги? Такое случается сплошь и рядом. «Наша новая система ERP намного лучше старой: появилось три очень нужных отчета, и вход в систему теперь занимает не полминуты, а всего-навсего 10 секунд. За это мы заплатили полтора миллиона евро».

Как можно заставить работать модель? Так же, как и любой другой качественный framework, – с помощью опросников. Например, «Оцените по шкале от 1 до 5, насколько вас устаивает качество отчетов в системе: 1 – совсем не устраивает, 5 – устраивает абсолютно».

Модель содержит много критериев оценки, часть из которых критически важна для вашей организации, другая часть менее важна, а некоторые неприменимы вообще. Как понять, что важно, а что нет? Отбросьте неприменимые переменные, а для остальных создайте опросник второго уровня. «Оцените по шкале от 1 до 5, насколько важно для вас время отклика системы: 1 – совсем не важно и 5 – очень важно».

После заполнения сотрудниками анкет-опросников, вас, конечно же, будут ненавидеть, но среднее арифметическое ответов даст довольно прозрачный намек на то, что хотелось бы иметь в будущей системе и что не устраивает в текущей.

Второе достоинство framework в том, что это замечательный «напоминальник», который не позволит повторить проблемы предыдущей системы в новой. Критериев оценки настолько много, что с их помощью можно оценить что угодно – от ERP животноводческого комплекса до ИС, отвечающей за запуск космических кораблей.

В-третьих, это инструмент предварительной оценки того, каких изменений следует ждать от новой системы. При разработке проекта консультанты-разработчики обязательно спрашивают клиента: «Что вы хотите видеть в новой ИС?» Ответ заказчика обычно сводится к неуверенному мычанию об улучшении в целом. Модель позволяет пробежаться по тому, что вообще возможно получить от любой абстрактной системы в принципе. Это поможет выработать конкретные требования к ИС.

Как можно практически использовать модель? Этой методики нет у Делона – Маклина, но, поскольку модель качественная, очевидно, придется использовать один из видов качественного анализа.

Предположим, мы используем базовую шестифакторную модель 1992 года, и из всех приведенных переменных для нашего предприятия, для нашего бизнеса подходят только пять из них в каждом из разделов. О каких конкретно переменных идет речь, в данном случае не важно. Каждое предприятие выбирает переменные индивидуально, исключительно под свой бизнес. Важно, что в модели описаны все потенциально существующие переменные.

Итак, у нас пять переменных в SYSTEM QUALITY («Качество системы»), пять в INFORMATION QUALITY («Качество информации в системе»), пять в USE («Использование информации в системе»), пять в USER SATISFACTION («Удовлетворенность пользователя работой системы»), пять в INDIVIDUAL IMPACT («Влияние системы на отдельного работника») и пять в ORGANIZATION IMPACT («Влияние системы на всю организацию в целом»).

Всего мы используем 30 переменных, которые опишут качество информационной системы нашего предприятия. Составляем анкету-опросник с 30 вопросами, и просим всех наших пользователей оценить каждую из переменных по шкале от 1 до 5, где 5 – «с этой штукой все очень хорошо» и 1 – «отвратительно, ужасно, вообще невозможно работать». Шкала оценки может быть и трехбалльной, и 10-балльной, и даже 100-балльной, в зависимости от пожелания составителя. На результат это почти не повлияет.

Второй важный вопрос. Хорошо, переменные-то мы выбрали по нашему вкусу и разумению, но пользователи системы может иметь совершенно другое мнение. Например, «время отклика системы» может быть не очень критичным для бухгалтерии и склада, но важным для производства. Поэтому введем второй уровень опроса: «Насколько важно лично для вас время отклика системы: 1 – абсолютно не важно, 5 – критически важно». Добавим в анкету вопросы оценки важности каждой их переменных. Опросник разрастается до 60 вопросов.

Полученным значениям важности присвоим весовые коэффициенты, например: «1» – 0, «2» – 0.25, «3» – 0.5, «4» – 0.75 и «5» – 1.0. Что будет, если работник склада оценивает «время отклика системы»? Допустим, на первую часть вопроса: «Насколько вас устраивает время отклика системы?» – он отвечает: «5», а на вторую часть: «Насколько важно для вас время отклика системы?» – он отвечает: «2». Итоговое значение ответа с учетом «важности» получается 5 х 0.25 = 1.25. То есть, несмотря на то что склад высоко оценил скорость отклика системы, итоговая оценка – всего 1.25, а не 5, поскольку складу этот параметр не важен.

Если предприятие большое, с множеством отделов, департаментов и подразделений, имеет смысл проводить анкетирование раздельно в каждом департаменте и анализировать полученные данные раздельно.

Предположим, что в нашем примере департаментов с разными требованиями к работе системы нет. Также предположим, что наши сотрудники добросовестно и честно ответили на все 60 вопросов. Считаем среднее арифметическое отдельно по каждой переменной и по ее важности. Результаты – в таблице 1.

Таблица 1. Результат обработки опросников

Какие выводы можно сделать из полученных данных? Во-первых, как и предполагалось, далеко не все переменные, которые показались важными нам, оказались такими же для работников. Это повод чаще интересоваться их мнением и, возможно, ввести некую систему оценки качества ИТ-услуг. Во-вторых, на основании цифр из таблицы можно получить количественный ответ, насколько хороша текущая система. Ниже в таблице приведено и реальное значение каждого из шести параметров системы. Идеальное значение вычислено как среднее арифметическое высшего возможного значения каждой переменной, умноженного на вес. В нашем случае мы просили оценивать переменные по пятибалльной шкале, то есть наивысшая возможная оценка – это 5. Посчитаем, например, идеальное значение SYSTEM QUALITY с учетом полученных весов важности каждой из переменных:

Идеал S.Q. = (5х1.0 +5х0 +5х0.5 +5х0.75 +5х0.25)/5 = 2.5

Распространим расчет на все 6 показателей качества. Если бы мы сделали все идеально и каждая переменная была бы важна на все 100% для каждого сотрудника, мы бы имели идеальное значение каждого из показателей «5.0»:

Абсолютный идеал S.Q. =(5х1.0 +5х1.0 +5х1.0 +5х1.0 +5х1.0)/5 = 5.0

К сожалению, всего предусмотреть мы не можем. Какие-то переменные важны для наших сотрудников, а какие-то нет. Поэтому рассчитаем «относительно идеальные» данные:

«Относительный идеал» S.Q. = (Идеал S.Q./Абсолютный идеал S.Q.) x 100%.

Результаты смотрим в таблице 2.

Таблица 2. Качество данных и качество информационной системы

О чем говорят полученные цифры? Фактически оценка проводилась по двум направлениям:

• насколько хороша наша информационная система;
• насколько хорошо и правильно нам удалось провести опрос.

Похоже, что некоторые переменные для опроса были выбраны не совсем удачно. Например, переменные из USER SATISFACTION важны для коллектива предприятия всего на 45%. Это означает, что мы пытались оценить не совсем то, что важно для сотрудников.

Вторая часть «Реальность» – это насколько наша текущая система отвечает запросам пользователей в рамках выбранных переменных. Можно сказать, что в целом неплохо.

Что делать с этими цифрами? Стоит ли повторно проводить опрос, например, используя другие переменные в разделе USER SATISFACTION? Все зависит от каждого конкретного случая и каждой конкретной организации.

Помните, что сотрудникам довольно быстро наскучивает регулярно заполнять длинные анкеты и отвечать на вопросы. Может статься, что вы получите нерелевантные результаты, где все всех устраивает на 100% или, наоборот, все не устраивает. Разумнее проводить анкетирование через интервалы времени.

Разумеется, в полевых условиях на реальной компании число вопросов может быть другим. Однако не увлекайтесь. Даже ответ на 60 вопросов займет у работников компании время и вызовет раздражение. Уставший раздраженный сотрудник может либо заполнить оставшуюся часть «от фонаря», либо просто бросить анкету, мотивировав это тем, что и так работы много. Если так случилось, что для вашей оценки совершенно необходим ответ на все возможные вопросы модели, разбейте процедуру анкетирования на этапы и разнесите их во времени.

Как еще можно использовать предложенный метод? Попробуйте сравнить результаты оценки работы старой и новой систем. Если вдруг новая система с точки зрения сотрудников при тех же переменных оценивается ими ощутимо хуже, это повод начать расследование, чтобы понять, что не так и каковы причины.

За прошедшее с 1992 года время модель заслужила самое пристальное внимание всего мира ИТ. В 2003-м Маклин и Делон представили модифицированную модель (см .рис. 2).

Рисунок 2. Модифицированная модель Делона и Маклина 2003 года

Новая их работа называется «The DeLone and McLean Model of Information Systems Success: A Ten-Year Update». Ее текст также можно найти в сети. Что изменилось по сравнению с базовой моделью 1992 года?

Первое крупное изменение заключается в том, что, кроме параметров INFORMATION QUALITY и SYSTEM QUALITY, появился еще один – SERVICE QUALITY. Откуда взялось это понятие и что с ним делать? Модель «Качество сервиса», или SERVQUAL, разработана американскими учеными ‘Parsu’ Parasuraman, Valarie Zeithaml и Len Berry в 1988 году. Основное ее назначение – измерять качество предоставляемых услуг. Это модель менеджмента, которая описывает пять «дыр» или разрывов, которые возникают в различных областях деятельности компании. Модель SERVQUAL описывает эти разрывы так:

Gap 1 (Первый разрыв): между ожиданием потребителя и пониманием менеджмента того, что нужно потребителю

Этот разрыв возникает, когда руководство компании неправильно понимает то, чего хотят клиенты. Например, при создании программного продукта владельцы бизнеса полагают, что клиентам важно иметь широкий функционал, в то время как для клиентов гораздо важнее простота интерфейса. Классический пример из описания модели относится к администраторам больниц, которые, например, полагают, что клиенты медицинского учреждения хотят более качественную, вкусную еду, в то время как именно эта больница славится бездушностью медицинских сестер. Отчего возникает Gap 1:

• недостаточные маркетинговые исследования;
• неправильная интерпретация информации об ожиданиях аудитории;
• исследования не нацелены на то, чтобы увеличить спрос на услугу или товар;
• организация забюрократизирована: слишком много слоев между линейным персоналом и высшим менеджментом.

Gap 2 (Второй разрыв): между пониманием, как управлять, и стандартами качества обслуживания

Хотя руководство может вполне адекватно понимать то, что клиент хочет, оно может не делать ничего, чтобы установить конкретные критерии качества. Например, заказчик программного продукта и исполнитель проекта пришли к выводу, что новая система «должна более адекватно отвечать требованиям пользователей». Но что это означает? «Более адекватно» – это насколько именно более? В чем именно заключалась «неадекватность» старой системы? Без конкретных ответов на обобщенные вопросы не получится никакого улучшения. В оригинале приводится пример с больницей, когда начальство отдает указание медсестрам «работать быстрее», но не уточняет, насколько быстрее и что конкретно является критерием «быстроты». Gap 2 чаще всего возникает по причинам:

• недостаточные, неполные процедуры планирования;
• отсутствие вовлеченности руководства;
• нечеткий или неоднозначный дизайн услуги;
• отсутствие системы в процессе запуска и развития новых услуг.

Gap 3 (Третий разрыв): между заявленным качеством обслуживания и реальным предоставлением услуг

Этот разрыв может возникнуть, если обслуживающий персонал плохо обучен, не в состоянии или не желает исполнять свою работу с должным уровнем качества. Возможные причины существования Gap 3:

• недостатки в кадровой политике, такие как неэффективный найм, неопределенность должностной инструкции, конфликт или пересечение обязанностей, определяемых должностными инструкциями, несправедливые оценка и система оплаты труда;
• неэффективный внутренний маркетинг;
• несоблюдение внутренних уровней спроса и предложения услуг;
• отсутствие надлежащего образования и обучения.

Gap 4 (Четвертый разрыв): между предоставлением услуг и внешними коммуникациями

На потребительские ожидания сильно влияют заявления представителей компании и реклама. Разрыв Gap 4 возникает, когда ожидания клиентов не оправдываются на момент предоставления услуги. Проблема знакома многим, кто работал с мелкими вендорами: в рекламных брошюрах говорится об идеальном программном продукте, а в действительности после внедрения в компании-заказчике постоянно сидят технические работники исполнителя, которые круглосуточно что-то исправляют, накатывают обновления, присланные из головного офиса, и когда наконец продукт заработает окончательно, никому не известно. Продолжаем пример с больницей: в рекламе чистые, комфортабельные палаты, в действительности – ужас, требующий капитального ремонта. Разумеется, ни о каких выполненных ожиданиях пациентов не идет и речи. Расхождения между обещанным и фактическим уровнями сервиса возникают по следующим причинам:

• агрессивная, чересчур многообещающая коммуникационная кампания предприятия;
• отсутствие системы в управлении ожиданиями клиентов;
• отсутствие системы, позволяющей соответствовать заявленному уровню сервиса.

Gap 5 (Пятый разрыв): между ожидаемым и получаемым уровнем услуг

Этот разрыв возникает, когда потребитель неправильно интерпретирует качество обслуживания. Классики приводят пример, когда врач продолжает посещать выздоравливающего пациента просто в рамках заботы и ухода. В то время как пациент думает, что такие забота и внимание врача – свидетельство серьезной болезни, о которой пациенту предпочитают не говорить.

В начале 1990-х годов авторы усовершенствовали SERVQUAL, свели ее к пяти факторам, которые получили аббревиатуру RATER:

• Reliability (надежность): способность выполнять обещанные услуги надежно и точно;
• Assurance (способность вызывать доверие): компетентность и вежливость сотрудников, и их способность демонстрировать, что компании можно доверять;
• Tangibles (вещественность предоставления услуг): персонал должен демонстрировать обеспеченность необходимыми средствами, материалами и инструментами для предоставления услуги;
• Empathy (эмпатия): предоставление заботливого индивидуального подхода к клиентам;
• Responsiveness (оперативность): готовность помочь клиентам и обеспечить быстрое обслуживание.

Зачем в модель информационной системы попали как SERVQUAL, так и RATER?

К началу 2000-х годов поменялся взгляд на информационные технологии. Информационную систему стали оценивать не как самостоятельную единицу, а как набор, совокупность услуг, которые она может предоставить предприятию. Например, при обслуживании клиента система должна не просто показать продавцу наличие товара на складе, но сообщить розничные и оптовые цены, распечатать полный пакет документов для клиента, создать внутренние проводки в складской программе, извещающие работников склада, что сейчас произойдет перемещение хранимого айтема и так далее. То есть ИС должна полностью обслужить бизнес-процесс. Для более подробного знакомства с «качеством сервиса» имеет смысл обратиться к источникам ITSM [2] и ITIL [3].

Имеет ли смысл усложнять подход оценки «Успеха информационной системы» и подключать ITSM, каждый решает индивидуально. Основной критерий – размер предприятия. Маленькой компании не имеет смысл заморачиваться лишними теоретическими изысканиями, хотя ITIL предусматривает работу с малыми компаниями [4].

Второе изменение USE распался на две части: INTENTION TO USE и USE. Это тоже логично. Между задекларированным намерением использовать систему для определенных целей и реальным использованием – огромная разница. Как «обещать еще не значит жениться». Именно поэтому стрелочка к USER SATISFACTION теперь идет не от объявленного INTENTION TO USE, но непосредственно от USE.

Третье изменение связано с изменением взгляда на бизнес вообще. Если до 2000-х годов управление предприятием подразумевало, что работник сам по себе, а предприятие само по себе, то в начале 2000-х появилось новое течение в теории управления, пришедшее из Японии. Оно говорит, что работник и предприятие неразделимы. Чем лучше живется предприятию, тем лучше будет работнику. Управление бизнес-процессом не может быть удобным для работника, но неудобным для предприятия и наоборот. Поэтому пункты INDIVIDUAL IMPACT и ORGANIZATION IMPACT объединились в NET BENEFIT – «чистую выгоду». Сюда вошли все пункты из отдельно взятых INDIVIDUAL IMPACT и ORGANIZATION IMPACT.

Одно из последних изменений модели Маклина и Делона предложено в 2010 году доктором Захари Вонгом [5] из «Школы бизнеса и экономики Университета Сонома», Калифорния, США. Работа называется «A Proposed Revision to the DeLone and McLean’s IS Success Model» или «Предлагаемые изменения к модели Маклина и Делона Успех информационных систем». Доктор Вонг предлагает учитывать изменения внешней бизнес-среды и вносить соответствующие изменения в параметры INFORMATION QUALITY, SYSTEM QUALITY и SERVICE QUALITY (см .рис. 3).

Рисунок 3. A Proposed Revision to the DeLone and McLean’s IS Success Model

К сожалению, конкретных рекомендаций и framework д-р Вонг не приводит, поэтому приходится довольствоваться только мыслью, что такой процесс нужен и требует детальной разработки. Может быть, он будет осуществляться в рамках ITIL, а может, кто-то разработает индивидуальную модель.

Будем надеяться, что понимание и практическое использование модели поможет кому-то сэкономить тяжело заработанные средства компании или использовать их более эффективно.

1. William H. DeLone, Ephraim R. McLean. Information Systems Success: The Quest for Depend Variable. – 1992.
2. IT Service management – http://en.wikipedia.org/wiki/IT_service_management.
3. Information Technology Infrastructure –Libraryhttp://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library
4. Office of Government Commerce (2005). ITIL Small Scale Implementation. The Stationery Office. ISBN 0-11-330980-5.
5. Zachary Wong, Ph.D. A Proposed Revision to the DeLone and McLean’s IS Success Model. – 2011.

В начало⇑

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи