Затонский А.В. Пособие по полному жизненному циклу информационных систем

Подождите немного. Документ загружается.

361

• результаты этапа приняты заказчиком, то есть руководителем

предприятия.

Такой подход позволяет контролировать риски проекта, двигаясь

поступательно к намеченной цели.

Рис

. 131

Пример

этапов

разработки

системы

бюджетного

управления

Управляйте целями и ожиданиями

Цели проекта могут корректироваться или даже существенно меняться в

ходе работы. Это обычная практика. Меняется обстановка, меняется понимание

ситуации, и рождается вывод, что прежние взгляды устарели, или были

ошибочными. Поэтому нужно регулярно (на каждом этапе проекта)

362

возвращаться «к истокам» и критически рассматривать все исходные

предпосылки.

Последнее

Нужно иметь мужество закрыть проект, если становится ясно, что он

зашел в тупик. Руководитель проекта, выступивший с инициативой о

прекращении безнадежного проекта заслуживает поощрения, как

ответственный менеджер, предотвративший бесцельное расходование средств

предприятия.

Последствия внедрения комплексных информационно-

управляющих систем

Любой масштабный ИТ-проект (в качестве примера обычно

рассматривается внедрение ERP-системы как одной из основных частей

информационной системы предприятия) несет в себе как выгоды, так и риски.

Поэтому ключевым моментом в оценке эффективности является четкое

определение и описание целей и задач проекта, т. е. тех направлений,

эффективность поддержки которых впоследствии будет оцениваться [47].

Говоря об оценке внедренческих проектов, часто употребляют слово

«выгода». В общем случае, под выгодой подразумеваются некоторые

позитивные явления, помогающие компании упрочить свое положение. Можно

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

• повышение функциональных характеристик и качества выпускаемой

продукции;

• улучшение обслуживания клиентов;

• снижение операционных расходов;

• улучшение использования активов.

Для того чтобы выделить основные категории резервов улучшения

работы предприятия, которые могут быть реально использованы при помощи

информационных систем, необходимо выделить наиболее типичные факторы

неэффективности (т. е. проблемы, свойственные предприятию). Ими на

большинстве предприятий могут быть следующие факторы:

• избыточный объем незавершенного производства;

• избыточные складские запасы;

• низкая степень использования производственных ресурсов;

• завышенные материальные затраты;

• низкое качество;

• низкий уровень обслуживания клиентов;

• неточности в определении себестоимости и ценообразовании;

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

• проблемы учета и управления финансами.

363

Ожидаемые улучшения, достигаемые при помощи ERP-системы могут

быть сгруппированы в следующие категории, для каждой из которых

характерны свои источники окупаемости (табл. 58).

Таблица 48

Примеры ожидаемых улучшений от внедрения ERP-систем

Категории улучшений Источники окупаемости

Незавершенное

производство и

длительность

производственного цикла

Снижение вложений в активы, снижение затрат на

перемещение материалов, сокращение сроков

производства, снижение запасов полуфабрикатов

собственного производства (из-за сокращенного

производственного цикла)

Складские запасы

Снижение вложений в активы, снижение затрат на

перемещение материалов, повышение уровня

обслуживания

Использование

производственных

ресурсов

Снижение потерь рабочего времени, минимизация

переналадок, повышение коэффициента готовности

оборудования

Снижение материальных

затрат

Партнерские отношения с поставщиками,

своевременность входящих поставок, возможность

использования небольших партий, снижение доли

бракованных материалов

Повышение качества

продукции

Снижение брака, снижение нарушений графиков

производства, уменьшение количества переналадок,

предотвращение снижения объема продаж

Повышение качества

обслуживания

Снижение сроков поставок, обеспечение

соответствия между запасами готовой продукции и

клиентским спросом, своевременность поставок,

интенсификация общения с клиентами

Управление затратами

Оперативность и точность расчета себестоимости (в

том числе на основе функционально-стоимостного

подхода), возможность оперативного анализа затр

ат,

возможность анализа причин отклонений от плана,

определение наиболее рентабельных видов

продукции

Организация хранения и

перемещения материалов

Повышение эффективности при одновременном

снижении трудоемкости, повышение качества

обслуживания, более точный и оперативный

контроль

Учет и управление

финансами

Доступность точной и своевременной финансовой

информации, оптимизация финансовых

взаимоотношений с поставщиками и потребителями

364

Если речь идет о создании информационно-управляющих систем,

заполняющих существующий на многих предприятиях пробел между АСУ ТП

и КИС, то их внедрение не только повышает эффективность КИС, но и имеет

самостоятельную ценность за счет:

• уменьшения времени цикла изготовления продукции;

• сокращение или устранения потерь времени на ввод данных;

• уменьшения незавершенного производства;

• уменьшения затрат времени на составление различных документов;

• сокращение простоев оборудования;

• повышения качества продукции;

• устранения потерь документов;

• улучшения планирования производства;

• повышения уровня сервиса для клиентов.

Основные стратегии внедрения системы

Независимо от использования тиражной или заказной ИС, можно

выделить следующие варианты стратегии их внедрения [7].

Параллельная стратегия – когда одновременно работают старая (ручная) и

новая система, и их выходные документы сравниваются. Если они согласуются

длительное время, осуществляется переход на новую систему

«Скачок». Эта стратегия привлекательна, но не рекомендуется из-за

одновременной высокой загрузки всех пользователей системы, вынужденных

единовременно выполнять обычную работу и участвовать во внедрении.

«Пилотный проект». Это наиболее часто используемая стратегия.

«Пилотный проект» – это тактика «скачка», но применяемая к ограниченному

числу процессов. Область применения стратегии – небольшой участок

деятельности. Такой подход снижает риск и наиболее надежен. Практически

все предприятия применяют эту тактику сегодня

«Узкое место». «Узкое место» – это малая часть производственного

процесса. При использовании подхода «узкое место» план внедрения

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

Точность данных повышается только для изделий в этом «узком месте»;

переподготовка - только для людей, работающих в нем, анализ эффект - затрат

делается только для него и т.д.

Независимо от способа ввода в эксплуатацию, достижение максимальной

функциональности системы обычно проходит в несколько этапов:

• Создание прототипа, прототопирование. Под прототипом понимается

набор программ, моделирующий в общих чертах работу системы.

Прототип демонстрируется сотрудникам заказчика, чтобы они могли

ознакомиться с системой, внести свои предложения относительно

функциональности.

• Создание рабочих проектов. Рабочий проект – система с неполной

функциональностью, на которой, тем не менее, можно проводить

основные операции и обучение.

365

• Разработка и внедрение. Функциональность доведена до оптимального

состояния, система готова к эксплуатации.

• Оценка результатов необходима на каждом этапе. Получается

своеобразная «обратная связь». Результаты деятельности системы

сравниваются с целями, сформулированными на начальном этапе и

скорректированными в процессе внедрения. Это позволяет понять,

насколько успешно протекает внедрение.

Внедрение должен планироваться и контролироваться ИТ-службой

предприятия. Его можно рассматривать как самостоятельный проект, который

включает:

• опытную эксплуатацию и доработку системы по ее итогам;

• развертывание или проверку инфраструктуры (сервера, каналы связи и т.

д.);

• обучение пользователей;

• обеспечение техподдержки.

Не останавливаясь на общеизвестных моментах, хотелось бы отметить,

что знакомство пользователей с системой в ходе внедрения не стоит проводить

в фоновом режиме. На это должно специально выделяться время по

согласованию с бизнес-руководителями. Только в этом случае есть шанс, что

система не будет восприниматься пользователями как еще одна проблема в и

без того перегруженном рабочем графике.

При внедрении заказных решений очень важно, чтобы заказчик имел

возможность наблюдать за ходом реализации проекта на всем его протяжении.

Необходимо отметить, что со сдачей заказного решения в промышленную

эксплуатацию проект не заканчивается.

Практически всегда в ходе эксплуатации системы возникают все новые и

новые требования, которые предполагают выпуск плановых обновлений.

Таким образом, недостаточно организовать "горячую линию" для

пользователей. Команда сопровождения и развития заказных систем должна

включать также аналитика, который занимается сбором и анализом новых

требований и замечаний, а также ресурсы разработчиков, которые занимаются

выпуском новых версий.

Разумеется, речь идет не о полной, а частичной занятости специалистов, и

обычно на сопровождение корпоративной системы требуется в среднем не

более 1-2 человеко-месяцев.

Принимая у поставщика готовую систему, важно проследить, чтобы

вместе с конечным продуктом и исходными кодами (если он создавался на

заказ) были переданы и все данные по истории изменения системы.

Если исполнитель предлагает заказчику «черный ящик», на входе

которого исходные спецификации, а на выходе – готовая система, то со

стопроцентной гарантией полученный продукт будет непригоден к

использованию.

Идеальная ситуация – когда не только координаторы со стороны ИТ-

подразделения, но и представители бизнес-заказчика являются активными

366

членами рабочей группы, участвуют в обсуждениях итогов по этапам, вносят

замечания.

Поставляемый продукт представляет собой не только выполняемые

модули, но и всю информационную инфраструктуру, которая поддерживает его

сопровождение и развитие. Эта информация имеет большую ценность для его

дальнейшего развития.

История развития продукта должна передаваться в ходе внедрения в

согласованном виде вместе с инфраструктурой, поддерживающей внесение

этих изменений. Поставщик обязан организовать этот процесс у себя, а по

завершении проекта передать все материалы и механизм их обновления

заказчику.

Если поставщик не может обеспечить целостность и сохранность этой

информации, то заказчик попадает в монопольную зависимость от него -

продукт перестает быть «отторгаемым» от поставщика. С одной стороны, это

очевидно.

С другой стороны, в договоре с поставщиком, как правило, прописано,

что и когда необходимо поставить, но не прописано, что вся информация,

связанная с внедрением (замечания, требования, история изменений), также

принадлежит заказчику и должна передаваться в ходе поставки.

Если сравнивать полный цикл внедрения заказных и тиражных систем, то,

в общем случае, можно сказать, что затраты на внедрение заказных и тиражных

решений различаются на разных этапах. В случае тиражных решений на этапе

сбора требований, настройки и доработки системы обычно работает небольшая

группа консультантов, как правило, внешних. На этапе внедрения, особенно

если речь идет о распределенной системе, требуются гораздо большие усилия,

более мощная команда внедренцев.

Для заказной системы – наоборот, пик ресурсных затрат максимален

вначале, на этапе проектирования и разработки. Если все организовано и

спланировано правильно, то этап внедрения обычно проходит быстрее и менее

болезненно, поскольку система создавалась специально с учетом специфики

данной организации, и многие потенциальные проблемы уже были учтены.

Стратегия пилотного проекта

Перед полномасштабным внедрением выбранной ИС в организации

может быть выполнен пилотный проект [49], целью которого является

экспериментальная проверка правильности решений, принятых на предыдущих

этапах, и подготовка к внедрению.

Пилотный проект представляет собой первоначальное реальное

использование ИС в предназначенной для этого среде и обычно подразумевает

более широкий масштаб использования ИС по отношению к тому, который был

достигнут во время оценки. Пилотный проект должен обладать многими из

характеристик реальных проектов, для которых предназначено данная ИС. Он

преследует следующие цели:

• подтвердить достоверность результатов оценки и выбора;

367

• определить, действительно ли ИС годится для использования в данной

организации, и если да, то определить наиболее подходящую область его

применения;

• собрать информацию, необходимую для разработки плана практического

внедрения;

• приобрести собственный опыт использования ИС.

Пилотный проект позволяет получить важную информацию,

необходимую для оценки качества функционирования ИС и ее поддержки со

стороны поставщика после того, как ИС установлена.

Важной функцией пилотного проекта является принятие решения

относительно приобретения или отказа от использования ИС. Провал

пилотного проекта позволяет избежать более значительных и дорогостоящих

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

приобретением относительно небольшого количества лицензий и обучением

узкого круга специалистов.

Первоначальное использование новой ИС в пилотном проекте должно

тщательно планироваться и контролироваться. Пилотный проект включает

следующие шаги (рис. 181).

Определение характеристик пилотного проекта

Пилотный проект должен обладать следующими характеристиками:

Область применения. Чтобы облегчить окончательное определение

области применения ИС, предметная область пилотного проекта должна быть

типичной для обычной деятельности организации. Пилотный проект должен

помочь определить любую дополнительную технологию, обучение или

поддержку, которые необходимы для перехода от пилотного проекта к

широкомасштабному использованию ИС. В рамках этих ограничений

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

Масштабируемость. Результаты, полученные в пилотном проекте,

должны показать масштабируемость ИС. Цель – получить четкое

представление о масштабах проектов, для которых данная ИС применима.

Представительность. Пилотный проект не должен быть необычным или

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

относящихся к предметной области, хорошо понимаемой всей организацией.

Критичность. Пилотный проект должен иметь существенную

значимость, чтобы оказаться в центре внимания, но не должен быть критичным

для успешной деятельности организации в целом. Необходимо осознавать, что

первоначальное внедрение новой технологии подразумевает определенный

риск. При выборе пилотного проекта приходится решать следующую дилемму:

успех незначительного проекта может остаться незамеченным, с другой

стороны, провал значимого проекта может вызвать чрезмерную критику.

368

Рис. 132. Алгоритм пилотного проекта

Авторитетность. Группа специалистов, участвующих в проекте, должна

обладать высоким авторитетом, при этом результаты проекта будут всерьез

восприняты остальными сотрудниками организации.

Характеристики проектной группы. Проектная группа должна обладать

готовностью к нововведениям, технической зрелостью и приемлемым уровнем

опыта и знаний в данной технологии и предметной области. С другой стороны,

группа должна отражать в миниатюре характеристики всей организации в

целом.

В большинстве случаев существует баланс между желанием реализовать

идеальный пилотный проект и реальными ограничениями организации.

Организация должна выбрать пилотный проект таким образом, чтобы, во-

первых, способ использования ИС в нем совпадал с дальнейшими планами, и,

во-вторых, перечисленные выше характеристики были сбалансированы с

реальными условиями организации.

Кроме того, организация должна учитывать продолжительность

пилотного проекта (и в целом процесса внедрения). Слишком

369

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

руководства.

Планирование пилотного проекта

Планирование пилотного проекта должно по возможности вписываться в

обычный процесс планирования проектов в организации. План должен

содержать следующую информацию:

• цели, задачи и критерии оценки;

• персонал;

• процедуры и соглашения;

• обучение;

• график и ресурсы.

Цели, задачи и критерии оценки

Ожидаемые результаты пилотного проекта должны быть четко

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

основу для последующей оценки проекта. Для определения целей, задач и

критериев оценки необходимо выполнить следующие действия:

• описать проект в терминах ожидаемых результатов (т.е. конечного

продукта). Описание должно включать форму представления и

содержание результатов. Должны быть четко определены договорные

требования и соответствующие стандарты.

• определить общие цели проекта. Примером цели может быть

определение степени улучшения качества проектной документации в

результате применения ИС.

• определить конкретные задачи, реализующие поставленные цели.

Каждой цели можно поставить в соответствие одну или несколько

конкретных задач с количественно оцениваемыми результатами.

Примером такой задачи может быть сравнительный анализ качества

документации, полученной с помощью ИС и без нее. Документация

может включать спецификацию требований к ПО, высокоуровневые и

детальные проектные спецификации.

• определить критерии оценки результатов. Чтобы определить степень

успеха пилотного проекта, необходимо использовать набор критериев,

основанных на упомянутых выше задачах. Примером критерия может

быть степень непротиворечивости проектной документации и

контролируемости выполнения требований к ПО. Значения критериев

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

выполнения пилотного проекта.

370

Персонал

Специалисты, выбранные для участия в пилотном проекте, должны иметь

соответствующий авторитет и влияние и быть сторонниками новой технологии.

Группа должна включать как технических специалистов, так и менеджеров,

заинтересованных в новой технологии и разбирающихся в ее использовании.

Группа должна обладать высокими способностями к коммуникации, знанием

особенностей организационных процессов и процедур, а также предметной

области. Группа не должна, тем не менее, состоять полностью из специалистов

высшего звена, она должна представлять средний уровень организации.

Многие ИС обеспечивают возможности, связанные с генерацией

проектной документации и конфигурационным управлением. Специалисты,

связанные с этими и другими смежными аспектами разработки и

сопровождения ПО, также должны быть включены в состав группы.

После завершения пилотного проекта группа должна быть открыта для

обмена информацией с остальными специалистами организации относительно

возможностей новой ИС и опыта, полученного при ее использовании. Может

оказаться желательным рассредоточить членов проектной группы по всей

организации с целью распространения их опыта и знаний.

Процедуры и соглашения

Необходимо четко определить процедуры и соглашения, регулирующие

использование ИС в пилотном проекте. Эта задача скорее всего может

оказаться более долгой и сложной, чем ожидается, при этом может оказаться

необходимым привлечение сторонних экспертов. Примерами процедур и

соглашений, которые могут повлиять на успех пилотного проекта, являются

методология, технические соглашения (в частности, по наименованиям и

структуре каталогов, стандарты проектирования и программирования) и

организационные соглашения (в частности, учет использования ресурсов,

авторизация, контроль изменений, процедуры экспертизы и подготовки

отчетов, стандарты проверки качества).

В пилотном проекте по возможности должны использоваться принятые в

организации процедуры и соглашения. С другой стороны, в течение пилотного

проекта процедуры и соглашения имеют тенденцию к развитию и

совершенствованию по мере накопления опыта применения ИС.

Существующие процедуры и соглашения могут оказаться неэффективными или

чересчур ограничивающими. При этом те изменения, которые предлагается в

них вносить, должны документироваться.

Обучение

Должны быть определены виды и объем обучения, необходимого для

выполнения пилотного проекта. При планировании обучения нужно иметь в

виду три вида потребностей: технические, управленческие и мотивационные.