В разделе «Порядок контроля и приемки системы» определены виды, состав, объем и методы испытаний системы (предварительные испытания, опытная эксплуатация, приемочные испытания), требования к оформлению соответствующей документации (программы и методики испытаний, протокол предварительных испытаний, акт приемки в опытную эксплуатацию, журнал опытной эксплуатации, протокол приемочных испытаний, акт о приемке системы в промышленную эксплуатацию и др.), требования к организации приемки типовых компонентов системы.
Раздел «Требования по подготовке и вводу в действие» описывает требования к организации работ по внедрению системы на предприятии, осуществляемые в связи с этим изменения в организационно-штатной структуре (прежде всего по развитию ИТ-службы), нормативно-методическом обеспечении (регламенты подразделений, должностные инструкции сотрудников), персонале (комплектование и обучение), а также требования по внедрению типовых компонентов системы.
Раздел «Требования к документированию» содержит состав комплекта документации и структуру документов по системе. По типовым компонентам, используемым в системе, предоставляется документация, входящая в комплект поставки. Эксплуатационная документация по разрабатываемым компонентам представляется в соответствии с требованиями ГОСТ 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 % систем не соответствуют ожиданиям пользователей, главная причина – стремление подогнать бизнес-процессы предприятия под существующую технологическую инфраструктуру».
Детальное моделирование и анализ задач не проводятся по следующим причинам:
• это серьезная работа, требующая высокой квалификации исполнителей и соответствующей оплаты, а заказчика еще нужно убедить в полезности полученных результатов в виде отчетов;
