Требования к КИУС
Требования к КИУС разбиваются на две самостоятельные группы – требования к функциям и нефункциональные требования. Основой выявления требований первой группы является модель бизнес-процессов предприятия, на базе которой, собственно, и формируется иерархия требований. К числу нефункциональных требований относятся:
• правовые и законодательные требования;
• качественные характеристики создаваемой системы, включая требования к ее практичности, надежности, производительности и возможностям поддержки;
• требования по безопасности;
• другие требования, например касающиеся операционных систем и сред, совместимости и проектных ограничений.
На основании выявленных требований разрабатывается техническое задание (ТЗ) на КИУС и, по необходимости, частные технические задания на ее компоненты (подсистемы). ТЗ создается на основе ГОСТ 34.602-89. Техническое задание на создание автоматизированной системы включает следующие основные разделы:
• Общие сведения;
• Назначение и цели создания системы;
• Характеристика объекта автоматизации;
• Требования к системе;
• Состав и содержание работ по созданию системы;
• Порядок контроля и приемки системы;
• Требования по подготовке и вводу в действие;
• Требования к документированию;
• Источники разработки;
• Глоссарий.
Раздел "Общие сведения" содержит справочную информацию, в том числе полное наименование системы, ее условное обозначение, шифр (номер) договора, названия предприятий разработчика и заказчика (пользователя) системы и их реквизиты, перечень документов, на основании которых создается система, плановые сроки начала и окончания работы по созданию системы, сведения об источниках и порядке финансирования работ.
В разделе "Характеристика объекта автоматизации" приводятся общие сведения о предприятии согласно его уставу, перечень основных видов деятельности и бизнес-процессов, перечень бизнес-процессов, подлежащих автоматизации в рамках КИУС, характеристики видов обеспечения – организационного (организационные документы, организационная структура, нормативное обеспечение, квалификация персонала), методического, программного (в сфере управления, в сфере производства, общесистемное), технического, лингвистического, математического, правового и информационного.
Раздел "Требования к системе" содержит три подраздела: требования к системе в целом, требования к функциям, требования к видам обеспечения. В первом подразделе содержатся:
• перечень компонентов (подсистем), их назначение и основные характеристики, требования к структуре системы;
• требования к интеграции компонентов (включая требования к способам и средствам связи для информационного обмена между компонентами системы и требования к функциональной интеграции в рамках бизнес-процессов);
• требования к характеристикам взаимосвязей создаваемой системы со смежными системами, требования к ее совместимости, способы информационного обмена;
• требования к режимам функционирования системы;
• требования к диагностированию системы;
• требования к численности и квалификации персонала системы и режиму его работы (включая обслуживающий персонал, пользователей и, по необходимости, частные требования по отдельным подсистемам);
• требования к надежности и сохранности информации (технических средств, базового системного программного обеспечения, специализированного функционального программного обеспечения, средств защиты информации, средств резервного копирования информации и носителей резервных копий и т. п., включая требования к парированию отказов и восстановлению после аварийных ситуаций);
• требования к безопасности и защите информации (включая перечень угроз информационной безопасности, требования к архитектуре и функциям обеспечения защиты информации, требования к организационному обеспечению защиты);
• требования к стандартизации и унификации.
Подраздел "Требования к функциям" содержит требования к компонентам (подсистемам) системы в случае общего ТЗ или детальные функциональные требования в случае частного ТЗ на конкретную подсистему. Подраздел "Требования к видам обеспечения" включает детальное описание требований к математическому, информационному, лингвистическому, программному, техническому и организационному обеспечению.
В разделе "Порядок контроля и приемки системы" определены виды, состав, объем и методы испытаний системы (предварительные испытания, опытная эксплуатация, приемочные испытания), требования к оформлению соответствующей документации (программы и методики испытаний, протокол предварительных испытаний, акт приемки в опытную эксплуатацию, журнал опытной эксплуатации, протокол приемочных испытаний, акт о приемке системы в промышленную эксплуатацию и др.), требования к организации приемки типовых компонентов системы.
Раздел "Требования по подготовке и вводу в действие" описывает требования к организации работ по внедрению системы на предприятии, осуществляемые в связи с этим изменения в организационно-штатной структуре (прежде всего по развитию ИТ-службы), нормативно-методическом обеспечении (регламенты подразделений, должностные инструкции сотрудников), персонале (комплектование и обучение), а также требования по внедрению типовых компонентов системы.
Раздел "Требования к документированию" содержит состав комплекта документации и структуру документов по системе. По типовым компонентам, используемым в системе, предоставляется документация, входящая в комплект поставки. Эксплуатационная документация по разрабатываемым компонентам представляется в соответствии с требованиями ГОСТ 34.201-89 "Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем", а также РД 50–34.698-90 "Методические указания. Информационная технология. Требования к содержанию документов". Приведем перечень этих документов:
• частное техническое задание – в соответствии с ГОСТ 34.602-89;
• описание информационного обеспечения – в соответствии с п. 5.3 РД 50–34.698-90 (при необходимости);
• описание программного обеспечения – в соответствии с п. 6.1 РД 5034.698-90;
• инструкция по обозначениям и кодированию (при необходимости);
• альбом выходных форм;
• руководство администратора подсистемы;
• руководство пользователя – в соответствии с п. 3.4 РД 50–34.698-90;
• программа и методика испытаний – в соответствии с п. 2.14 РД 5034.698-90.
В перечне проектной документации также должны присутствовать документы, отражающие ход работ по проекту и обеспечивающие качество их выполнения:
• план разработки (детализированный календарный план работ, содержащий виды работ, даты начала и завершения работ, отметки о выполнении работ);
• план управления конфигурацией, содержащий описание следующих процессов управления проектной документацией: порядок разработки и хранения, порядок внесения изменений, ведение версионности, рассылка, порядок внутреннего согласования;
• план качества проекта, определяющий перечень и порядок проведения мероприятий, направленных на обеспечение качества (внутренние аудиты, тестирование, анализ результатов).
Основными тиражируемыми (типовыми) компонентами КИУС являются:
• системы управления предприятиями (MRP-II – Manufactory Resource Planning / ERP – Enterprise Resource Planning);
• системы управления активами и фондами (EAM – Enterprise Asset Management);
• системы управления взаимоотношениями с клиентами (CRM – Customer Relations Management);
• системы управления цепочками поставок (SCM – Supply Chain Management).
Типы КИУС
Краткое описание ряда типовых компонентов КИУС приведено в приложении. Наполнение предметной части КИУС существенно зависит от профиля деятельности предприятия. В качестве примеров таких компонентов можно привести:
• отраслевые и специализированные учетные системы, назначением которых является поддержка выполнения учетных функций на предприятии с ориентацией на его специфику (отметим, что если правила бухгалтерского учета являются едиными для предприятий всех видов деятельности, то методы производственного, торгового, складского и кадрового учета могут существенно отличаться не только по отраслям, но и по отдельным предприятиям в рамках отрасли);
• системы автоматизированного проектирования (САПР), назначением которых является автоматизация работ по подготовке новых технологических решений, инженерных расчетов, графической проектной документации (чертежей, схем, эскизов), моделированию проектируемых объектов.
При выборе компонентов КИУС решаются следующие вопросы:
• заказная или тиражируемая;
• отечественная или зарубежная;
• весовая категория – от локальных до крупных интегрированных и/или их отдельных модулей.
Основные недостатки заказной разработки обычно объясняются так:
• трудозатраты и стоимость соизмеримы с затратами на тиражируемую систему (такие продукты должны реализовываться большими коллективами аналитиков, проектировщиков и программистов);
• использование тиражируемой системы менее рискованно, чем заказной разработки;
• тиражируемая система внедряется поэтапно и частично может быть доступна в рабочем режиме гораздо быстрее, чем заказная.
В табл. 8.1 приведены основные результаты анализа перечисленных подходов по ряду важнейших параметров, таких как стоимость, время, работоспособность и др., демонстрирующие преимущества использования тиражируемых систем в качестве компонентов КИУС.
Таблица 8.1.
Сравнение заказных разработок и тиражируемых систем
Необходимо отметить, что двух одинаковых предприятий не существует, поэтому тиражирование даже очень хорошей системы практически никогда не устроит заказчика полностью, поскольку не может учесть его специфики. Следовательно, возникает проблема выбора системы, наиболее подходящей для конкретного предприятия, сложность которой обуславливается:
• масштабностью тиражируемых систем;
• тонкими отличиями реализации технологий основных бизнес-процессов;
• одинаковостью маркетинга (ключевые слова, характеризующие различные системы, практически одни и те же, – единая информационная среда предприятия; режим реального времени; независимость от законодательства; интеграция с другими приложениями; поэтапное внедрение и т. п.).
Тем не менее интуитивно понятными критериями выбора тиражируемой системы являются:
• поддержка большинства функций, выявленных при анализе требований;
• поддержка концептуальной модели данных (информационной модели предприятия);
• наличие высокоуровневых механизмов разработки для компенсации отсутствующих данных и функций;
• функционирование на различных аппаратных платформах, гибкость;
• сложность сопровождения и администрирования;
• локализация, адаптация к российским условиям;
• деловые критерии продавца (прежде всего его опыт внедрения и надежность).
Основные отличия между зарубежными и российскими системами:
• зарубежные решения ориентированы на хорошо структурированную иерархическую систему бизнес-процессов предприятия;
• зарубежные системы, как правило, опираются на стандарты, которым процессы должны удовлетворять;
• зарубежные системы, направленные на автоматизацию управления, поддерживают полный набор управляющих функций: планирование – контроль отклонений (учет) – регулирование;
• российские системы более полно отражают национальные особенности, российскую учетную специфику;
• логика российских систем близка российским управленцам;
• российские системы более удобны в случае работы с неполными, недостоверными или конфиденциальными данными.
Отметим, что значительное число проектов в отечественной практике создания КИУС завершается неудачно либо имеет тенденцию неограниченного увеличения сроков внедрения при одновременном отсутствии значимых результатов. При этом объяснение причины неудачи является традиционным (и очень удобным для консультантов-внедренцев) – "предприятие не готово к внедрению". На самом деле основные причины неудач лежат в несколько иной плоскости.
Фактически не система настраивается под предварительно реорганизованные бизнес-процессы конкретного предприятия, а наоборот, предприятие перестраивается под систему (любимая фраза внедренцев – "мы проводим реинжиниринг под нашу систему"). При этом зачастую и сам выбор системы осуществляется не на основании детальных функциональных требований к соответствующему компоненту КИУС, а попросту навязывается поставщиком. В одном из последних бюллетеней MIT Sloan Management Review отмечается: "…от 30 до 75 % систем не соответствуют ожиданиям пользователей, главная причина – стремление подогнать бизнес-процессы предприятия под существующую технологическую инфраструктуру".
Детальное моделирование и анализ задач не проводятся по следующим причинам:
• это серьезная работа, требующая высокой квалификации исполнителей и соответствующей оплаты, а заказчика еще нужно убедить в полезности полученных результатов в виде отчетов;
• фирме-поставщику тиражируемого решения невыгодно выполнять такую работу, поскольку сравнительный анализ модели требований и функционала системы может привести к плачевным результатам, вплоть до потери заказчика;
• само внедрение на основании модели требований не оставляет шансов тиражировать фрагменты настроек и знания из других проектов;
• фактически настройки осуществляются членами проектной группы самого предприятия (бухгалтерами, экономистами, плановиками и т. п.), прошедшими короткое обучение, – консультанты лишь отвечают на их конкретные вопросы и решают вставшие перед ними проблемы.
Глава 9 Методы оценки эффективности ИС
Методические вопросы оценки совокупной стоимости владения
Подход к оценке ТСО базируется на результатах аудита ИТ-инфраструктуры, основных процессах управления, ИТ-активах, операций ИТ-персонала и действий конечных пользователей. Сбор и анализ статистики по структуре прямых (HW/SW, операции, административное управление) и косвенных затрат (на конечных пользователей и простои) проводится в течение 12 месяцев. Полученные данные оцениваются по ряду критериев сравнения с аналогичной по бизнесу компанией.
В ТСО в качестве базы для сравнения используются западные типовые компании. Методика учитывает различия с отечественными компаниями посредством использования поправочных коэффициентов:
• по стоимости ИТ-активов (Cost Profiles) с учетом данных по количеству и типам серверов, персональных компьютеров, периферии и сетевого оборудования;
• по заработанной плате сотрудников (Salary and Asset Scalars) c учетом дохода компании, географического положения, типа производства и размещения организации (в крупном городе или нет);
• по конечным пользователям ИТ (End User Scalars) с учетом типов пользователей и их размещения (для каждого типа пользователей требуется различная организация службы поддержки и вычислительной инфраструктуры);
• по использованию методов лучшей практики в области управления информационными технологиями (Best Practices) с учетом реального состояния дел по управлению изменениями, операциями, активами, сервисному обслуживанию, обучению, планированию и управлению процессами;
• по уровню сложности предприятия с учетом состояния организации конечных пользователей (процент влияния – 40 %), технологии SW (40 %), технологии HW (20 %).
Типовой план работ по оценке ТСО состоит из последовательности действий.
Подготовка и планирование:
• проведение учебного курса по анализу ТСО и работе с TCO Manager;
• обсуждение со спонсором области применения проекта;
• цели проекта и ключевые результаты;
• ограничения по проекту: бюджет, ресурсы, график и т. д.;
• роли и ответственность;
• готовность компании к запуску проекта;
• обсуждение специфики: ограничения по срокам, командировки и т. д.;
• формирование группы для сбора данных;
• определение круга лиц, включаемых в анализ;
• обсуждение вопросов поддержки и участия руководства в проекте;
• распределение ролей и ответственности в группе;
• совместная работа менеджера проекта и эксперта по TCO;
• обсуждение границ проекта, выборки и периода анализа;
• разработка и выпуск план-графика проекта;
• определение даты и повестки дня совещания по запуску проекта;
• обсуждение способов распространения документа "Обзор ТСО" среди членов команды проекта.
Запуск проекта:
• утверждение даты и времени совещания по запуску проекта со спонсором и ключевыми участниками;
• подготовка аудитории, проектора и т. п. для проведения совещания;
• подготовка копий презентационных материалов;
• приглашение участников, среди которых:
– спонсор проекта;
– ключевые участники;
– координатор;
– участники сбора данных (управление активами, управление контрактами, управление вендорами);
– представители финансовой службы;
– представители HR-службы;
– Web-специалисты (если отчет по конечным пользователям готовится Web-средствами).
Совещание по запуску проекта:
• обеспечение координатора и сборщиков данных опросниками ("Обзор ТСО", таблица распределения задач, обзор по конечным пользователям);
• представление выступающих на совещании;
• распределение ролей и ответственности между координатором и сборщиками данных;
• обсуждение границ, плана, рисков, критериев отбора, приоритетов проекта;
• подтверждение обязательств со стороны членов команды проекта и исполнительного спонсора;
• рассылка протокола (обсуждаемые вопросы, принятые решения, ответственность);
• корректировка план-графика проекта;
• завершение совещания.
Сбор данных:
• опрос;
• детальное изучение опросников;
• обсуждение неясных вопросов с экспертом по ТСО;
• разъяснение координаторам и сборщикам данных их роли и места в проекте;
• проверка для всех выборок непротиворечивости и правильности расчетов при сборе данных;
• еженедельное проведение совещаний с координаторами;
• выявление вопросов, требующих внешнего участия в их разрешении.
Распределение вопросов "Обзор ТСО" по функциональным областям:
• стандарты и политика (комитет по стандартам или группы по архитектуре);
• методы амортизации, возмещение стоимости и т. п. (финансовая служба);
• уровни сервиса (исполнительные службы);
• процесс разрешения проблем и Help Desk (служба поддержки);
• информация по обучению (учебный центр или кадровая служба);
• контракты на аутсорсинг (управление по работе с вендорами или финансовая служба);
• информация по закупкам (службы – закупки, поддержка ИС, бюджетный контроль);
• информация по управлению активами (службы – закупки, поддержка ИС, бюджетный контроль);