CC BY
62
№ 3 (45) 2013
Ю.В. Гольчевский, канд. физ.-мат. наук, доцент Сыктывкарского государственного университета А. В. Малдрик, экономист Сыктывкарского гуманитарно-педагогического колледжа им. И. А. Куратова
Пять шагов на пути к эффективной информатизации предприятия
Современные условия работы характеризуются глобальной информатизацией, ростом значения информации и особенно скорости ее обработки и трансляции между подразделениями. То есть успешное функционирование любой организации или предприятия напрямую зависит от того, насколько эффективно и успешно организованы работа его отдельных служб и подразделений и обмен информацией между ними.
введение
В настоящее время предлагается необычайно широкий выбор программного обеспечения практически во всех сферах деятельности человека. Поэтому руководители многих предприятий не видят особой проблемы в выборе подходящего программного продукта. Казалось бы, нет ничего проще, чем подобрать информационную систему (ИС). На самом деле должны возникать вопросы. Что лучше — привычное, но платное или не привычное, но свободно распространяемое программное обеспечение? Не скажется ли «очевидная» на первый взгляд экономия на результате работы и не окажется ли обучение сотрудников впоследствии дороже? Как выбрать из широкого спектра предложений?
Естественно, главное — использовать системный подход. Но возникает проблема: на практике, когда наступает необходимость принятия решения о приобретении ИС, о важности системного подхода забывается. Точный расчет при принятии решения зачастую подменяется следующими критериями выбора:
1. Название ИС, недавно внедренной успешным конкурентом.
2. Первая ссылка в поисковой системе браузера, красочно описывающая безгра-
ничные возможности одной из новинок рынка программного обеспечения.
3. Убедительная речь менеджера компьютерного салона, коллеги или обложка рекламного буклета, случайно попавшего на рабочий стол.
Список вариантов можно продолжить. Ключевым моментом является то, что ни один из перечисленных способов не затрагивает, конечно же, принципов системного подхода. Срабатывает попросту интуиция или влияет частное субъективное мнение. На самом деле, не важно, какая ИС подходит конкурентам, какая появилась последней и что необходимо продать ближайшему компьютерному салону. Не каждое решение, успешно эксплуатируемое в одной организации, будет столь же эффективно работать и в другой. Главное — понимать бизнес-процессы (БП) компании, ее возможности и на основании этого проводить тщательный анализ рынка программных средств.
Несистемный подход к информатизации организации при наличии большого выбора самого разнообразного программного обеспечения, распространяемого по разным лицензиям, может привести к приобретению неэффективного программного обеспечения. Для оптимизации и стандартизации такого рода процедур существует несколько методик и рекомендаций [1].
№ 3 (45) 2013
Цель статьи — предложить основанный на системном подходе алгоритм выбора программных продуктов, способных наиболее эффективно решать стоящие перед структурными подразделениями организации задачи. Он применялся в работе отдела программирования Сыктывкарского государственного университета (СыктГУ) и достаточно хорошо себя зарекомендовал, позволив находить и принимать оптимальные решения.
Этапы выбора программного обеспечения
Выделяется как минимум пять последовательных этапов реализации данного алгоритма (этапов может быть и больше, если включить верификацию результатов с помощью других методик).
1. Анализ бизнес-процессов организации. Этап необходим для формирования четкого понимания конкретных особенностей функционирования подразделений в той области деятельности, которая нуждается в автоматизации. Нужно ясно представлять задачи, для решения которых планируется приобретение тех или иных ИС, | что поможет четко сформулировать требо-§ вания к программному обеспечению. А это, ^ в свою очередь, практически невозможно без глубокого анализа БП всего предпри-| ятия в целом и его структурных подразде-8 лений в частности.
¡5 Первой стадией анализа БП является анализ предметной области. Без него слож-Ц но определить требования к продукту и вы->== строить конструктивное общение с его по-| тенциальными пользователями внутри ор-| ганизации. Наиболее простые и доступные методики на данном этапе — интервьюи-2 рование экспертов предметной области Ц и анализ предметной документации. Так-^ же может быть весьма полезным ознаком-« ление с результатами анализа автоматиза-<5 ции аналогичных процессов в других орга-.о низациях, работающих в том же секторе ё экономики.
Для углубления понимания процессов и формализации полученных данных далее можно рекомендовать использовать UML-методологию объектно-ориентированного моделирования [2]. Унифицированный язык UML (United Modeling Language) — это визуальный язык моделирования, позволяющий представлять свое видение будущей системы в простой для понимания форме, что способствует более легкому и точному выявлению и описанию проблем в сфере информатизации исследуемого процесса. Наиболее широко в данном контексте могут использоваться следующие виды диаграмм UML:
1. Диаграмма прецедентов. Прецедент — это описание поведения системы с точки зрения пользователя. Графически каждый прецедент представляется в виде эллипса, а его исполнитель, т. е. лицо, выполняющее конкретное действие, — в виде упрощенной фигурки человека. Обозначения исполнителя и прецедента соединяются сплошной линией, обозначающей их взаимодействие. Исполнители, прецеденты и соединительные линии образуют модель прецедентов. На рисунке 1 представлен пример такой диаграммы для сотрудника, работающего с некоторыми документами.
2. Диаграмма видов деятельности UML похожа на блок-схему, в которой точками принятия решений и переходов описывается последовательность шагов. Каждый вид деятельности изображается прямоугольником со скругленными углами, а переход от одного прямоугольника к другому — стрелкой. На диаграмме видов деятельности имеется начальная точка и конечная точка. Точки принятия решения можно изобразить несколькими способами, например, используя изображение ромба. В качестве примера на рис. 2 приведена диаграмма видов деятельности, которая моделирует внутренний документооборот организации. Она составлена для СыктГУ при разработке проекта внедрения электронного документооборота (СЭД). Далее будут приведены еще несколько примеров из этого проекта.
№ 3 (45) 2013
1
1 £
£ I
Рис. 1. Пример диаграммы прецедентов
3. Диаграмма развертывания. Диаграмма развертывания UML показывает физическую архитектуру компьютерной системы. Она представляет компьютеры и устройства, их соединение между собой, а также программное обеспечение, размещенное на каждой машине. При планировании развертывания ИС в сети с большим количеством узлов такая диаграмма обеспечивает минимизацию ошибок анализа и позволяет учесть все технические детали.
В качестве следующего шага для повышения эффективности анализа БП приме-
няется методология функционального моделирования IDEF0, являющаяся частью методологии структурного анализа и проектирования SADT [3, 4]. Задача функционального моделирования состоит в представлении их в виде совокупности взаимосвязанных функций. IDEF0-модель описывает, какие действия выполняются в ходе каждой операции, какой продукт производится на ее выходе, какая информация используется для управления действиями, а также какие ресурсы и средства применяются для исполнения ее функций.
25
-ч ПРИКЛАДНАЯ ИНФОРМАТИКА
№ 3 (45) 2013 ' -
I I 1 I
I I
0
1
I
та
Ьс
&
£
со
12 §
¡2 ¿8
Руководство
Отдел служебн
ои документации
Адресат
^Фиксация факта поступления документа^
I
( Проверка обязательных атрибутов )
[нарушения выявлены]
[нарушений не выявлено]
^Регистрация документа )
Рис. 2. Пример диаграммы видов деятельности
Важной особенностью настоящего этапа — анализа бизнес-процессов организации — является то, что строятся не только диаграммы текущего состояния процесса
(модели «как есть»), но и модели «как должно быть», т. е. вариант функционирования процесса, который должен быть достигнут после внедрения программного продукта.
№ 3 (45) 2013
Рассмотрим пример. На рисунке 3 приведена диаграмма БП «Организация внутреннего документооборота» «как есть», составленная для СыктГУ.
Даже без подробного рассмотрения (декомпозиции) обращаем внимание на некоторые особенности, позволяющие оптимизировать процесс. Например, во-первых, БП управляется большим количеством регламентных документов. Они содержат четко структурированную информацию о правилах составления и перемещения документации. А структурированные данные относительно легко поддаются информатизации, и многократные процедуры проверок соответствия документов принципам стандартов можно сделать автоматическими, сэкономив большое количество времени и снизив риск влияния человеческого фактора. Во-вторых, отсутствие единой системы коммуникации сотрудников и вызванная этим необходимость физического перемещения между структурными подразделениями влечет за собой потребность тиражирования документов в бумажном формате. Поэто-
му использование офисной техники (такой, ¡| как принтеры, сканеры, факсы) выделено § на диаграмме отдельным механизмом. Го- ^ раздо более эффективным было бы ис- < пользование возможностей ИС, позволяю- Ц*
Ьс
щей обмениваться данными в электронном | формате без создания большого числа ко- | пий документации. Выделение СЭД в каче- е стве механизма в схеме «как должно быть» (рис. 4) снизит необходимость использования других технических механизмов.
Немаловажным из достоинств IDEF0-мо-делей является то, что они обеспечивают возможность обмена информацией о рассматриваемом объекте на языке, понятном не только аналитику, но и специалисту-эксперту в предметной области, пользователям и руководителям разного уровня.
Еще более подробно и глубоко изучить структуру БП и описать причины и выгоду от внедрения различных информационных продуктов (или наоборот — отказа от внедрения) позволит его декомпозиция, т. е. разбиение на блоки бизнес-операций, взаимосвязанных и образующих единый цикл
Положение
Рис. 3. SADT-диаграмма бизнес-процесса «Организация внутреннего документооборота»
«как есть»
27
№ 3 (45) 2013
Положение о защите персональных данных
ГОСТ Р 51141-98 — вСыктГУ Инструкция по делопроизводству в Федеральном Примерная
агентстве инструкция
по образованию по делопроизводству в вузе РФ
поручение руководства_
Инструкция по делопроизводству в ГОУ ВПО «СыктГУ»
Правила внутреннего
распорядка
ГОУ ВПО «СыктГУ»
ГОСТ Р 6.30-2003
исполненное поручение^
инициатива исполнителя
Организация внутреннего документооборота
новая регистрационная запись
исходные данные
управленческое действие
составители, документа
СЭД
руководство вуза и структурных подразделений
контролирующие лица
исполнители документа
Рис. 4. SADT-диаграмма бизнес-процесса «Организация внутреннего документооборота»
«как должно быть»
производства конечного продукта. Декомпозиция для рассматриваемого примера приведена на рис. 5. Также можно построить и декомпозицию «как должно быть».
2. Формулирование требований.
На этой стадии исследования используют результаты анализа БП организации, полученные ранее. Следует заметить, что про-
I I и
к
I
I
0
1 *
Ьс
&
§
со 12 I ¡2 3
Положение
Примерная инструкция
ционная
управленческое действие
Рис. 5. Декомпозиция SADT-модели бизнес-процесса «Организация внутреннего документооборота» («как есть»)
28
№ 3 (45) 2013
цедура выявления требований будет неполной без учета представлений и пожеланий потенциальных пользователей. Анализ их видения проблемы позволит задать направление поиска программных решений, максимально адаптированных к специфике деятельности предприятия. Наиболее распространенными методиками анализа требований пользователей являются устные опросы и анкетирование.
Следующий шаг — структуризация выявленных требований, которые можно разделить на технические и бизнес-требования [4].
Первая группа состоит из требований к аппаратному и программному обеспечению. При выборе программного средства целесообразно определить, какие дополнительные продукты могут понадобиться для работы с ним и каковы условия их покупки и лицензирования. Одним из главных является требование к операционной системе — необходимо выяснить, будет ли работать данный продукт на уже имеющихся на предприятии версиях операционных систем либо придется нести дополнительные затраты на их закупку и установку.
К бизнес-требованиям чаще всего относят следующие требования:
• наличие необходимого функционала;
• простота работы с системой;
• эргономичность интерфейса;
• способность адаптации к БП конкретного предприятия;
• надежность механизма защиты информации.
Формализация и систематизация требований позволяет четко представить потребности организации. Подход к применению методологий систематизации требований, модель систематизации приведены в работе [5].
Подчеркнем особо, что одним из важнейших условий успешной реализации проектов внедрения ИС в организации является наличие связанной с бизнес-стратегией организации стратегии развития информационно-технологической структуры организа-
ции. Иначе это может привести к следую- ¡|
щему: §
• неудачные неоднократные попытки ^ автоматизировать системы организации, < приобретение неэффективного аппарат- Ц"
Ьс
ного и программного обеспечения, потеря |
денег; 5
5
• лоскутная автоматизация; е
• нарушение коммуникаций между структурными подразделениями организации;
• потеря времени;
• невозможность правильно сформулировать требования и в конечном счете адекватно оценить достигнутые результаты и перспективы.
В случае отсутствия таких взаимосвязанных стратегий их разработка (хотя бы в черновом варианте) должна предшествовать любому более-менее значимому для предприятия проекту.
3. Анализ рынка программного обеспечения. Для выбора программного продукта, максимально отвечающего потребностям заказчика, может использоваться квалимет-рический метод анализа, позволяющий осуществить количественную оценку качественных параметров [6].
Первым этапом квалиметрического анализа является определение показателей, по которым будет оцениваться качество (пригодность для организации) программного продукта. Сформулированные на предыдущем этапе требования объединяются в группы, которые послужат критериями оптимальности ИС для конкретного предприятия. В качестве примера предлагаем следующие группы показателей, отражающих принципы совершаемого выбора программного продукта:
• надежность системы защиты данных;
• «мощность» хранилища документов;
• наличие необходимого функционала;
• возможность адаптации к БП организации;
• простота работы с системой;
• эргономичный интерфейс;
• условия сопровождения системы;
• стоимость системы.
№ 3 (45) 2013
Далее производится оценка каждого продукта по этим параметрам. Если показатель невозможно оценить количественно, ему присваивается соответствующее число баллов по выбранной шкале (например, по пятибалльной). Чтобы мнение по каждой из рассматриваемых систем было наиболее объективным, применяется метод экспертных оценок: несколько специалистов предметной области (обычно не менее пяти) выставляют оценку программе по каждому из показателей, после чего производится их усреднение и получение итоговой оценки. Такой набор данных может иметь вид, представленный в табл. 1.
На следующем этапе осуществляется перевод абсолютных показателей Q в относительные К для обеспечения сопоставимости их значений. Для этого используется формула
где I — номер свойства, по которому производится оценка,у — номер оцениваемого объекта в общем списке программных продуктов, qft — наилучшее (эталонное) значение оценки по рассматриваемому свойству среди всего списка программных продуктов.
Каждому эталонному значению присваивается показатель в 100 баллов, исходя из которого рассчитываются относительные показатели по другим ИС. Конечным результатом оценки каждого программного продукта является среднее геометрическое баллов, полученных им по каждому из параметров выбора. Пример приведен в итоговой табл. 2.
При переходе к относительным показателям можно использовать как равномерный, так и дифференцированный переход (т. е. отдавать большее предпочтение некоторым факторам по сравнению с другими). Также существуют принципы, которыми можно руководствоваться при выборе экспертов, учитывая различия в их компетентности и объективности. Формула, используемая для этого, имеет вид:
N
^ = X qg,
I=1
где qf и qj — коллективная и индивидуальная экспертные оценки, N — численность экспертной подгруппы, высказывающей суждение об 1-м показателе оцениваемого объекта, д у — коэффициент весомости у-го эксперта, рассчитываемый в зависимости от его индивидуальных квалификационных показателей.
I
I 1 К
I
I
48
0
1
I
та *
I
§
со 12 I ¡2
Характеристика Эксперт 1 Эксперт 2 Эксперт 3 Эксперт 4 Эксперт 5 Средний балл
1. Защита данных 5 5 5 5 5 5
2 . Хранилище данных и управление ими 3 3 4 2 3 3
3 . Функционал 4 5 4 4 3 4
4 . Адаптация к БП 3 3 4 3 3 3,2
5 . Простота работы 5 4 5 5 4 4,6
6 . Эргономичный интерфейс 5 5 4 5 5 4,8
7 . Система сопровождения 4 3 5 4 4 4
8 . Стоимость системы 3 2 2 4 2 2,6
Таблица 1
Результаты экспертной оценки определенного программного продукта
№ 3 (45) 2013
Таблица 2
Итоговый результат анализа рынка программного обеспечения
Информационная система Показатели и баллы по показателям Общий балл
1 2 3 4 5 6 7 8
Информационная система 1 100 60 91 64 96 100 83 52 78,54
Информационная система 2 100 96 100 88 67 50 100 40 76,16
Информационная система 3 100 100 95 80 83 88 100 36 81,77
Информационная система 4 76 92 73 68 83 88 75 40 72,47
Информационная система 5 84 96 86 100 92 88 96 96 92,09
Информационная система 6 96 100 95 92 100 100 100 100 97,83
1
во
Ï £
S
I
ва
S
При проведении анализа нужно также учитывать, что существуют четыре пути внедрения программных продуктов:
• приобретение программных продуктов (типовых) у сторонних фирм и их внедрение с помощью обслуживающей организации (фирмы-разработчика, дилера и т. п.);
• приобретение программных продуктов у сторонних фирм и внедрение их силами 1Т-специалистов предприятия;
• заказ на разработку программных продуктов непосредственно под требования конкретной организации;
• самостоятельная разработка и внедрение программных продуктов непосредственно Я-подразделением предприятия.
Квалиметрическая оценка позволяет проводить анализ любых продуктов, независимо от того, приобретается продукт на рынке или разрабатывается самостоятельно. Если предпочтение отдается собственной разработке, то необходимо понимать, что мало просто «разово» разработать некое программное обеспечение. Потребуются постоянные усилия по его модернизации, адаптации к изменяющимся внешним условиям (техническим, рыночным, изменениям законодательства и т. д.). Это может повлечь дополнительные, достаточно большие затраты, что скажется на экспертных оценках. Данный способ рекомендуется организациям, имеющим свои постоянные, хорошо работающие
/^-подразделения с квалифицированным персоналом и готовым финансировать развитие собственных программных разработок.
Для того чтобы минимизировать риски процесса самостоятельного создания ИС, рекомендуется опираться на существующие методики и идеологии разработки программных средств, в числе которых могут быть названы, например, RUP (Rational Unified Process) [7], UML (Unified Modeling Language) [2, 8], MSF (Microsoft Solution Framework) [9], «экстремальное программирование» [10], Agile [11].
Заказ на разработку индивидуального программного обеспечения может быть достаточно дорогим решением, особенно если потребуется дальнейшая постоянная техническая поддержка со стороны разработчиков. Хотя на сегодняшний день это, пожалуй, самый распространенный способ создания официальных сайтов коммерческих и некоммерческих структур, что обуславливается спецификой данных программных продуктов, требующей индивидуальности и нестандартных решений.
Строгий алгоритм анализа позволяет объективно оценить применимость каждой ИС из возможных к решению задач организации. При желании результаты квалимет-рического анализа можно уточнить другими способами, например, изучением отзывов специалистов других организаций.
31
№ 3 (45) 2013
4. Разработка проекта внедрения информационной системы. Не будучи грамотно введенной в процесс функционирования предприятия, сама по себе ИС не представляет особой «внутренней» ценности. Даже оптимальный программный продукт не будет работать эффективно, если проект его внедрения был неудачным. Это обуславливает необходимость использования методологии управления проектами.
Одну из таких методологий предлагает Свод знаний по управлению проектами по стандарту PMBOK [12]. Согласно этому документу эффективный проект предполагает реализацию следующих подготовительных стадий.
1. Календарное планирование проекта. Зная основные этапы деятельности, можно точно определить, какие ресурсы должны участвовать в реализации каждого этапа и какие факторы влияют на качество и своевременность его осуществления. Исходя из структуры календарного плана, можно сформировать списки необходимых ресурсов и контролировать их распределение в течение всего хода реализации проекта. Пример такого календарного плана для проекта внедрения элементов СЭД (несколько усеченный для краткости) приведен на рис. 6.
2. Планирование человеческих ресурсов. Чтобы обеспечить проект достаточным количеством человеческих ресурсов, необходимо составить список ролей, которые должны исполнять члены команды в процессе его реализации. Группировка задач в логически однородные блоки позволяет выделить роли, исполнение которых должно быть оптимально распределено между членами проектной группы. Из списка наиболее эффективных менеджеров формируется команда управления, обеспечивающая проект ресурсами, организующая взаимодействие участников между собой и оперативно реагирующая на любые отклонения от нормального (запланированного) хода ведения проекта.
3. Прежде чем приступить к непосредственной работе над проектом внедрения, участники команды должны сформировать список рисков, с которыми может столкнуться группа в процессе выполнения поставленных задач. Всегда есть вероятность, что процесс пойдет не по плану. Поэтому необходимо изыскать возможности сокращения этой вероятности и разработать порядок действий при различных вариантах отклонения хода проекта.
4. Управление коммуникациями проекта. Включает в себя процессы, необходимые
I I 1 К
I
I
48
0
1
I
та *
I §
со 12 I ¡2
И Название задачи Начало Окончание Длительность ЭПр2012 | МЭЙ2012 | „»„2012 ИЮЛ2012 | Эвг2012
84 154 I 224 I 294 I 65 135 205 275 36 106 176 246 17 87 157 I 227 I 297 I 58 128 198 268
1 Определение состава проектной группы 0504.2012 09.042012 зд ■
2 Анализ рисков проекта 1204.2012 16.042012 зд ■
3 Анализ соответствия функционала 2004.2012 04.052012 11Д
4 Определение состава участников пилотного проекта 0705.2012 07.052012 1Д I
5 Настройка ИС для реализации пилотного проекта 0705.2012 08.052012 2Д 1
6 Разработка сопроводительной документации 0805.2012 14.052012 5Д ж
7 Обучение участников пилотного проекта 1605.2012 18.052012 зд ■
8 Запуск пилотного проекта 2105.2012 08.062012 15Д
9 Сбор отзывов о функциональности 0706.2012 08.062012 2Д 1
10 Анализ отзывов 0706.2012 12062012 4Д ж
11 Настройка системы в соответствии с отзывами 1306.2012 20.062012 бд н
12 Определение последовательности внедрения 2106.2012 25.062012 зд ■
13 Дополнение функционала информационной системы 2606.2012 25.07.2012 22Я ^ш
14 Доработка сопроводительной документации 2707.2012 31.07.2012 зд ш
15 Обучение пользователей 0308.2012 13.082012 7Д шш
16 Передача системы в эксплуатацию 1308.2012 29.082012 134 —
Рис. 6. Пример календарного планирования в форме диаграммы Ганта
№ 3 (45) 2013
для своевременного создания, сбора, распространения, хранения, получения и использования информации проекта. Процессы управления коммуникациями проекта предусматривают создание необходимых связей для успешного взаимодействия участников проекта. Следует поддерживать постоянную связь с представителями структурных подразделений — для получения консультаций, анализа мнений о текущей ситуации, подключения сотрудников к процессу проектирования и тестирования ИС.
Для более детального планирования и отслеживания состояния проекта можно наблюдать его развитие и по другим направлениям. К примеру, для проектов, подразумевающих значительное количество внешних коммуникаций, целесообразно вести управление закупками и контрактами. Для новых и малоизученных проектов можно организовать системное планирование операций и качества создаваемого продукта, по сложным, комплексным задачам составляются подробные расписания. Особое внимание рекомендуется уделять фазе закрытия проекта, позволяющей формализовать полученные результаты и оценить степень завершенности поставленных задач.
Помимо РМВОК существуют и другие методологии управления проектами разработки и внедрения программных продуктов, упомянутые выше [7-11]. Каждый руководитель может выбрать для себя наиболее приемлемые и эффективные методы управления, предложенные ведущими мировыми специалистами.
5. Реализация проекта внедрения системы и оценка его эффективности. Оценка эффективности реализации проекта заключается в сопоставлении затрат, понесенных для его осуществления, и выгод, полученных в результате ввода в эксплуатацию новой ИС. Успешно реализованный проект предполагает, что выгоды от реализации в разумные сроки превысят затраты на поиск, приобретение и внедрение программного продукта. Оценка эффективности может проводиться разными способами — оцен-
кой рисков, оценкой изменения стоимости ¡| предприятия (для коммерческих предпри- § ятий), оценкой удовлетворенности сотруд- ^ ников и партнеров организации, сравнени- < ем технологических параметров и т. п. При использовании любых способов оценки мо- | гут возникать достаточно большие сложно- | сти, вызванные тем, что внедрение инфор- iS мационных технологий не всегда имеет очевидное влияние на результаты деятельности организации, часто оно является опосредованным. Особенно это касается некоммерческих организаций, могут потребоваться нетривиальные подходы и алгоритмы для выяснения истины.
Например, интересные результаты можно получить при опросе сотрудников (с помощью анкет, личной беседы, изучения их деятельности со стороны). При этом изменение показателей эффективности работы можно учесть исходя как из временных характеристик, так и из субъективных высказываний персонала. Главное в таких опросах — грамотно подойти к составлению опросных листов и списка тем, затрагиваемых в беседе.
Одной из распространенных технологий оценки качества продукта является система сбалансированных показателей (BSC — BalancedScorecard) [13]. Ее основной принцип заключается в отказе от исключительного использования финансовых параметров в процессе анализа. В соответствии с системой BSC строится карта стратегии организации, охватывающая направления ее развития. Степень достижения поставленных целей по каждому из направлений оценивается с помощью ключевых показателей эффективности (KPI — Key Performance Indicator), которые призваны количественно измерить успешность компании в продвижении к запланированным результатам.
Для оценки качества программного продукта с помощью BSC необходимо выделить те ветви на карте стратегии организации, на реализацию которых прямо или косвенно влияет его использование. В качестве показателей KPI могут быть взяты, например,
-ч ПРИКЛАДНАЯ ИНФОРМАТИКА
№ 3 (45) 2013 ' -
сокращение времени создания и обработки документов за счет автоматизированных форм ввода данных, уменьшение числа невыполненных в срок поручений как результат работы системы контроля, количество новых клиентов, привлеченных посредством организации новых путей доступа к информации и т. п.
Другим способом оценки информационного решения может быть проверка ее соответствия установленным стандартам. В частности, ISO 9126 (ГОСТ Р ИСО / МЭК 9126-93) [14] определяет такие оценочные характеристики качества, как функциональность, надежность, практичность, эффективность, сопровождаемость, мобильность.
По каждому из показателей в стандарте приведены внешние и внутренние метрики, позволяющие оценить качество программного продукта и целесообразность его применения в конкретной организации.
Другие аспекты обсуждаемой проблемы
При обсуждении затронутой темы могут возникнуть дополнительные аспекты. Первый — как предложенные шаги согласуются с отечественным комплексом стандартов § на автоматизированные системы ГОСТ 34? § Приведем несколько стандартов из этого ^ комплекса [15]:
• ГОСТ 34.003-90 Автоматизированные I системы. Термины и определения; 8 • ГОСТ 34.201-89 Виды, комплектность ¡5 и обозначение документов при создании автоматизированных систем; Ц • ГОСТ 34.601-90 Автоматизированные >g системы стадии создания; | • ГОСТ 34.602-89 Техническое задание £ на создание автоматизированной системы; Л • ГОСТ 34.603-92 Виды испытаний авто-£ матизированных систем; Ц • ГОСТ 34.320-96 Концепции и термино-^ логия для концептуальной схемы и инфор-« мационной базы.
<5 Современная практика информатиза-.о ции организаций, распространенные за-g рубежные стандарты часто основываются
на понятийном аппарате бизнес-процессов. В ГОСТ 34 прямого упоминания о них нет. Применение понятий, связанных с БП, идеально подходит для описаний управленческой деятельности, но не всегда позволяет дать исчерпывающие описания для технологических процессов. И тогда может потребоваться использование других методов моделирования. ГОСТ 34 конкретных правил описания объекта информатизации практически не дает, в нем вводится обобщенное понятие информационной модели. Согласно ГОСТ 34.003-90 это «модель объекта, представленная в виде информации, описывающей существенные для данного рассмотрения параметры и переменные величины объекта, связи между ними, входы и выходы объекта и позволяющая путем подачи на модель информации об изменениях входных величин моделировать возможные состояния объекта» [15]. То есть можно выбирать способ моделирования объекта, наиболее пригодный для конкретной ситуации (один из вышеперечисленных или технические модели).
Кроме того, ГОСТ 34 стандартизирует, в основном, процессы и документацию, связанные с разработкой ИС, но не с покупкой. А большинство организаций приобретает именно уже готовые ИС. Поэтому ГОСТ 34 эффективно применим лишь на втором, третьем и четвертом шагах предлагаемого алгоритма и дает более детальное понимание действий и документационного сопровождения на этих шагах. Но это относится в значительной степени лишь к ситуациям, связанным с самостоятельной разработкой ИС или когда возникает необходимость в заказе на разработку силами сторонней организации. Заказчик для понимания сути своих проблем, формализации и систематизации требований и понимания предлагаемых решений также может опираться на документацию, представленную в комплексе ГОСТ 34.
Однако на практике довольно часто возникают ситуации, когда для ускорения и удешевления работ полный комплект документов не разрабатывается. Это может иметь как
№ 3 (45) 2013
положительные стороны (например, в случае небольших проектов), так и отрицательные.
Второй дополнительный аспект обсуждаемой проблемы — какие специалисты могут потребоваться для успешного проведения значимых информационных проектов? Ответ можно найти в материалах [16, 17]. Это, прежде всего, специалисты четвертого и пятого квалификационных уровней, способные проводить необходимые аналитические работы, выявлять проблемы, систематизировать требования, предлагать современные высокоэффективные решения с использованием ИС и вести соответствующую проектную деятельность. Для них существенным является умение выделять специфику бизнеса и бизнес-задачи. Именно таким специалистам может понадобиться выполнение описанных выше шагов и применение соответствующих инструментов.
Заключение
Таким образом, если процесс выбора ИС структурирован, осуществляется технически грамотно и осмысленно, организация с большой долей вероятности получит продукт, способный реально устранить недостатки в деятельности и вывести предприятие на новый уровень развития. А для выполнения этого требуется использование современных хорошо зарекомендовавших себя методов анализа бизнес-процессов, разработки или выбора готового программного обеспечения.
Список литературы
1. Антошина И. В. Процедуры и модели оценки качества и выбора прикладного программного обеспечения систем обработки информации: диссертация. М., 2001. — 225 с.
2. Фаулер М, Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования. Пер. с англ. М.: Мир, 1999. — 191 с.
3. Калянов Г. Н. Моделирование, анализ, реорганизация и автоматизация бизнес-процессов. М.: Финансы и статистика, 2007. — 240 с.
4. Бабенко В. В. Практический анализ бизнес-про- ¡|
цессов. Сыктывкар: СыктГУ, 2010. — 288 с. §
s
5. Симкин А. В. Подход к комплексному приме- ^ нению методологий систематизации требова- < ний // Прикладная информатика. 2013. № 1 (43).
С. 60-75. Sá
6. Варжапетян А. Г. Квалиметрия: учеб. пособие. 5
¡5
СПб.: ГУАП, 2005. — 176 с. £
7. Крачтен Ф. Введение в Rational Unified Process / ^ пер. с англ. 2-е изд. М.: Издательский дом «Вильямс», 2002. — 240 с.
8. Шмуллер Дж. Освой самостоятельно UML за 24 часа / пер. с англ. 3-е изд. М.: Издательский дом «Вильямс», 2005. — 416 с.
9. Microsoft Solutions Framework. Гибкая методология разработки программного обеспечения. М.: Русская редакция, 2008. — 127 с.
10. Кент Бек. Экстремальное программирование. Серия: Библиотека программиста / пер. с англ. СПб.: Питер, 2002. — 224 с.
11. Майк Кон. Scrum: гибкая разработка ПО / пер. с англ. М.: Издательский дом «Вильямс», 2011. С. 576.
12. A Guide to the Project Management Body of Knowledge (PMBOK Guide) Fourth Edition. 2008. Project Management Institute.
13. Нортон Д., Каплан Р. Сбалансированная система показателей. От стратегии к действию. М.: Олимп-Бизнес, 2010. — 320 с.
14. ISO 9126: 1991 (ГОСТ Р ИСО / МЭК 9126-93) «Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению». М.: Стандарт-Информ, 2004. — 12 с.
15. ГОСТ 34 // Электронная библиотека стандартов оформления проектной документации. URL: http://it-gost.ru/ (дата обращения: 20.03.2013).
16. Требования профессионального стандарта. Специалист по информационным системам: должностные обязанности, умения и навыки // Прикладная информатика. 2008. № 1 (13). С. 32-67.
17. Требования профессионального стандарта. Специалист по информационным системам: должностные обязанности и основные знания // Прикладная информатика. 2008. № 3 (15). С. 28-75.
