Наглядное представление этапов внедрения.

Более подробная схема см. приложение №2.

Этап 1: диагностика

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

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

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

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

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

В данном этапе требуется оценить бизнес-требования, объем и рамки проекта, а также план проекта, и по этим данным определить, что лучше использовать - быстрое или полное внедрение Microsoft Dynamics.

Основные результаты стадии:

• * Предложение относительно работы над проектом:
• * описание содержания проекта;
• * предварительный план проекта.
• * Оценка инфраструктуры.

Результаты стадии:

Клиент принимает предложение на внедрение, подписывает контракт, включая предполагаемый объем и рамки проекта, а также ознакомляется с предварительным дизайном системы.

Этап 2: анализ.

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

Задача, следующей важности после проведения встречи --знакомство ключевых пользователей с проектируемой ИС. Обучение должно быть нацелено на пользователей, которые будут непосредственно участвовать в подробном анализе, и также на ключевых пользователей от подразделений клиента компании, вовлеченного в проект.

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

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

Когда анализ всех требований будет завершен, собранная информация агрегируется и на ее основе создается документ «Функциональные требования», который заказчик проверяет, одобряет и подписывает.

Основные результаты этапа:

• * Устав проекта.
• * Тренинги ключевых пользователей.
• * Детальный анализ бизнес-процессов:
  • o анализ разрывов требований с базовой функциональностью;
  • o оценка устранения разрывов;
  • o описание интерфейсов.
• * План миграции данных.
• * План проекта.
• * Функциональные требования:
  • o инфраструктура, функциональность и безопасность;
  • o интеграция.
• * Требования к контролю качества и тестированию.

Основные вехи этапа:

• * Проведено совещание по запуску проекта.
• * Заказчик утверждает Устав проекта.
• * Проводится обучение по проектируемой ИС для ключевых пользователей.
• * Заказчик утверждает «Функциональные требования», включая описания бизнес-процессов, интеграции и миграции данных.
• * Заказчик утверждает обновленный план-график проекта.

Этап 3: дизайн.

Начало стадии дизайна положено в аналитическом этапе и отрегулировано порожденными на ней артефактами, произведенными на нем, в частности результатом анализа бизнес-процессов и плана миграции данных. Цели стадии дизайна включают следующее (но не ограничены им):

• * Создать или обновить полный дизайн проекта и соответствующих документов, которые будут требоваться, чтобы решение соответствовало функциональным требованиям.
• * Чтобы создать верхнеуровневую спецификацию для каждой модификации системы, приспособлена обработка, определенные отчеты и интеграция определенная в документе «Функциональные Требования».
• * Создать подробное описание требований к преобразованию данных, которые были определены во время анализа и планирования миграции данных в аналитической стадии.
• * Получить одобрение от заказчика верхнеуровнего плана миграции данных и спецификации дизайна решения перед началом созданием подробной спецификации дизайна и выполнения заключительных оценок.
• * Создать подробную спецификацию дизайна решения на основе верхнеуровневой структуры дизайна, одобренного клиентом.
• * Выполнить и представить заказчику оценки созданию модификаций, контроля, интеграции и миграции данных.
• * Получить, одобренные заказчиком дизайном, технические требования модификаций системы, дизайн миграции данных и оценки всех перечисленных операций.

Основные результаты стадии:

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

Главные этапы стадии:

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

Этап 4: разработка.

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

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

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

Циклы развития и тестирования продолжаются, пока результаты тестирования не отвечают критериям тестирования определенным ранее и не удовлетворят клиента. На этой стадии проекта такие процессы как управление объемом и структурой проекта и управление изменениями крайне важны.

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

Основные результаты стадии:

• * Настройка решения проектируемой ИС.
• * Подготовка документации относительно решения проектируемой ИС
• * Развитие дополнительной функциональности (настройки).
• * Контроль и тестирование миграции данных.
• * Тестирование интеграции (включая интеграцию с внешними системами).

Главные этапы стадии:

• * Миграция данных выполнена.
• * Тестирование интеграции выполнено.
• * Клиент принимает созданное решение, результаты тестирования и документации.

Этап 5: развертывание.

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

Основные результаты стадии:

• * План начала и контрольный список.
• * План тестирования системы.
• * План обучения пользователей.
• * Обучение пользователей.
• * Рабочая система.

Главные этапы стадии:

• * План старта и контрольный список.
• * План тестирования системы.

Этап 6: эксплуатация.

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

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

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

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

По этому вопросу взаимодействие с клиентом проводится в пределах ранее скоординированной поддержки продукта (с подписанием соответствующего контракта). Команда консультанта переключается на следующий проект.

Основные результаты стадии:

• * Принятие системы клиентом.
• * Документы для закрытия проекта.
• * Соглашение по поддержке системы.

Главные этапы стадии:

• * Клиент признает, что спроектированный ЯВЛЯЕТСЯ и подписывает акт входа в коммерческой операции.
• * Клиент формально закрывает проект.
• * Клиент подписывает контракт поддержки.

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

Проектируемая ИС в рабочей среде клиента:

Цель стадии оптимизации: создание структуры управления процессами, происходящими после процедуры Go-Live. Эта стадия также позволяет поддерживать отношения с клиентом после оригинального проекта введения или может стать первым шагом на способе предоставить услуги новому клиенту.

Цель этой стадии состоит в анализе решения спроектированного и внедренного у клиента решения проектируемой ИС, исправлений в бизнес-процессы, контроль производительности в целях увеличения эффективности решения.

Стадия оптимизации - отражение процесса полного внедрения. Эта стадия включает перечисленные ниже действия:

• * Аналитические действия, направленные на сбор информации о процессе, контроле и производительности.
• * Предложения относительно объема работ.
• * Работа над выполнением и расширением оптимизации.

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

• * анализ;
• * планирование;
• * определение оптимизации;
• * расширение оптимизации;
• * эксплуатационные операции.

Обновление.

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

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

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

• * анализ;
• * планирование;
• * обновление работы;
• * тестирование;

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

Каждая стадия методологии Sure Step Methodology включает ряд определенных операций и задач. Результат выполненной работы в рамках операции, как правило, отражен в конечных результатах с рекомендациями и инструкциями о дальнейших шагах процесса внедрения.

ТАВРИЧЕСКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ

им. В.И. ВЕРНАДСКОГО

Экономический факультет

кафедра экономической кибернетики

дневное отделение

МАЛЫШЕВ СЕРГЕЙ ИВАНОВИЧ

ВНЕДРЕНИЕ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ (СИСТЕМ) В ДЕЯТЕЛЬНОСТЬ ПРЕДПРИЯТИЯ

Курсовая работа

Студент 2 курса, гр. 201К ______________ Малышев С.И.

Научный руководитель,

доцент, к.ф.-м.н. ______________ Круликовский А.П.

Симферополь, 2009

ВВЕДЕНИЕ ……………………………………………………………………….3

ГЛАВА 1

ИНФОРМАЦИОННЫЕ СИСТЕМЫ И ТЕХНОЛОГИИ В ЭКОНОМИКЕ ………………………………………………………………...6

1.1. История развития информационных систем………………………….....6

1.2. Классификация информационных технологий и систем…………….....8

1.3. Виды информационных систем в организации………………………...16

1.4. Потенциальные потребители информационных технологий…………19

1.5. Опыт использования информационных систем ……………………….21

ГЛАВА 2

ВЫБОР, ВНЕДРЕНИЕ И ЭКСПЛУАТАЦИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ …………………………………………………………………...22

2.1. Проблема выбора информационной системы………………………….22

2.2. Критерии выбора системы……………………………………………....24

2.3. Методы внедрения системы……………………………………………..27

2.4. Этапы внедрения информационной системы………………………….30

ЗАКЛЮЧЕНИЕ………………………………………………………………………….…32

СПИСОК ИСТОЧНИКОВ……………………………………………………………...35

Введение

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

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

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

Существует множество определений данному термину, например:

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

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

Для новой информационной технологии характерны:

Работа пользователя в режиме манипулирования;

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

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

Интерактивный режим решения задач;

Возможности коллективного исполнения документов на основе сетевой технологии клиент - сервер, объединенных средствами коммуникации;

Возможности, адаптивной перестройки форм и способа представления информации в процессе решения задачи.

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

Что может дать внедрение информационной системы?

Снижение общих затрат предприятия в цепи поставок (при закупках),

Повышение скорости товарооборота,

Сокращение излишков товарных запасов до минимума,

Увеличение и усложнение ассортимента продукции,

Улучшение качества продукции,

Выполнение заказов в срок и повышение общего качества обслуживания заказчиков.

Реформа методов управления экономическими объектами повлекла за собой не только перестройку организации процесса автоматизации управленческой деятельности, но и распространение новых форм реализации этой деятельности. Цель данной работы исследовать – методы внедрения новой информационной системы, рассмотреть результаты ее использования.

1.1. История развития информационных систем

История развития информационных систем и цели их использования на разных периодах представлены в таблице 1.

Таблица 1. Изменение подхода к использованию информационных систем

Период времени	Концепция использования информации	Вид информационных систем	Цель использования
1980 -???? гг.	Бумажный поток расчетных документов Основная помощь в подго­товке отчетов Управленческий контроль реализации (продаж) Информация - стратегичес­кий ресурс, обеспечиваю­щий конкурентное преиму­щество	Информационные системы обработки расчетных доку­ментов на электромехани­ческих бухгалтерских маши­нах Управленческие информа­ционные системы для про­изводственной информации Системы поддержки приня­тия решений Системы для высшего звена Управления Стратегические информаци­онные системы. Автоматизированные офисы	Повышение скорости обра­ботки документов Упрощение процедуры об­работки счетов и расчета зарплаты Ускорение процесса подго­товки отчетности Выработка наиболее рацио­нального решения Выживание и процветание фирмы

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

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

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

К концу 80-х гг. концепция использования информационных систем вновь изменяется. Они становятся стратегическим источником информации и используются на всех уровнях организации любого профиля. Информационные системы этого периода, предоставляя во­время нужную информацию, помогают организации достичь успеха в своей деятельности, создавать новые товары и услуги, находить новые рынки сбыта, обеспечивать себе достой­ных партнеров, организовывать выпуск продукции по низкой цене и многое другое.

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

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

ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ	По способу реализации в ИС	Традиционные
		Новые информационные технологии
	По степени охвата задач управления	Электронная обработка данных
		Автоматизация функций управления
		Поддержка принятия решений
		Электронный офис
		Экспертная поддержка
	По классу реализуемых технологических операций	Работа с текстовым редактором
		Работа с табличным процессором
		Работа с СУБД
		Работа с графическими объектами
		Мультимедийные системы
		Гипертекстовые системы
	По типу пользовательского интерфейса	Пакетные
		Диалоговые
	По способу построения сети	Локальные
		Многоуровневые
		Распределенные
	По обслуживаемым предметным областям	Бухгалтерский учет
		Банковская деятельность
		Налоговая деятельность
		Страховая деятельность

Рассмотрим, связь между информационными системами и информационными технологиями.

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

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

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

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

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

Все виды информации, необходимой для управления на предприятии, представляют собой информационную систему. Система управления и система информации на любом уровне управления образует единство. Управление без информации невозможно.

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

Ввод информации из внешних или внутренних источников;

Обработка входной информации и представление ее в удобном виде;

Вывод информации для представления потребителям или передачи в другую систему;

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

Рис. 1. Процессы в информационной системе

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

Информационная система определяется следующими свойствами:

Любая информационная система может быть подвергнута анализу, построена и управ­ляема на основе общих принципов построения систем;

Информационная система является динамичной и развивающейся;

При построении информационной системы необходимо использовать системный под­ход;

Выходной продукцией информационной системы является информация, на основе ко­торой принимаются решения;

Информационную систему следует воспринимать как человеко-компьютерную систе­му обработки информации.

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

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

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

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

При классификации информационных систем удобно выделять системы CRM (работа с клиентами), ERP (управление предприятием) и MPC (управление на основе финансовых показателей).

На отечественном рынке границы подобной классификации сильно размыты, например известная финансовая система 1C позиционируется как ERP, при этом было бы не корректно заявлять, что 1C является конкурентом такой ERP системы как Navision Axaptra.

Первые системы, которые были разработаны для решения задач управления на предприятии, в основном охватывали сферу складского или материального учета (IC – Inventory Control). Их появление связано с тем, что учет материалов (сырья, готовой продукции, товаров) с одной стороны является извечным источником различных проблем для руководителя предприятия, а с другой (на предприятии относительно крупного размера) одной из самых трудоемких областей, требующих к себе постоянного внимания. Основной «деятельностью» такой системы является учет материалов.

Следующий этап усовершенствования материального учета был ознаменован системами планирования производственных или материальных (в зависимости от направления деятельности организации) ресурсов. Эти системы, вошедшие в стандарт, а вернее два стандарта (MRP – Material Requirements Planning и MRP II – Manufacturing Requirements Planning), очень широко распространены на Западе и давно и успешно используются предприятиями, в первую очередь производственных отраслей. Основные принципы, которые легли в основу систем стандарта MRP, включают

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

Учет ограничения ресурсов при выполнении заказов;

Минимизацию производственных циклов и запасов;

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

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

Наиболее популярным на данный момент новым видом информацион-ных систем являются системы стандарта ERP - Enterprise Resource Planning. ERP- системы в своей функциональности охватывают не только складской учет и управление материалами, что в полном объеме предоставляют вышеописанные системы, но добавляют к этому все остальные ресурсы предприятия, прежде всего денежные. То есть ERP-системы должны охватывать все сферы предприятия, непосредственно связанные с его деятельностью. В первую очередь, здесь имеются в виду производственные предприятия. Системы данного стандарта поддерживают осуществление основных как финансовых, так и управленческих функций. Например, в системах Baan – это:

Финансы и бухгалтерия,

Производство,

Сбыт (включая складской учет, торговлю и маркетинг),

Транспорт,

Сервис и обслуживание оборудования,

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

А также единая управленческая панель – модуль Информационная Система Руководителя, на которой руководитель может видеть все основные подразделения и производственные показатели.

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

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

Несмотря на это, надлежит выделить несколько основных требований к системе, общих для всех «потребителей»:

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

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

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

4. В силу влияния внешних и внутренних факторов (изменений направления бизнеса, изменения в законодательстве и т.п.), система должна быть адаптивной. Применимо к Украине, это качество системы должно рассматриваться более серьезно, так как у нас в стране изменения законодательства и правил учета происходят в несколько раз чаще, чем в странах со стабильной экономикой.

5. Необходима возможность консолидации информации на уровне предприятий (объединение информации филиалов, дочерних компаний и т.д.), на уровне отдельных задач, на уровне временных периодов.

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

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

Таблица 3. Типы информационных систем.

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

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

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

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

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

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

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

1.4 . Потенциальные потребители информационных технологий

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

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

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

· практически не используются информационные технологии (за исключением бухгалтерии) в управлении процессами и ресурсами;

· предпринята попытка внедрить промышленную систему, характеристики которой соответствуют требованиям одного из принятых стандартов (MRP, MRPII, ERP и т.д.), но результат внедрения - неудовлетворительный.

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

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

Менеджеры, у которых уже работают какие-либо информационные системы, стоят перед дилеммой: либо потратить немалую сумму на «интегрированное решение», эффект от которого далеко не очевиден, и при этом выбросить на свалку «старые добрые» программы, которые не соответствуют современному уровню реализации, но проверены временем и «работают»; либо оставить все как есть и забыть про современные концепции ERP, e-business и прочие достижения в области менеджмента и соответственно потерять определенные конкурентные преимущества.

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

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

1 .5. Опыт использования информационных систем

Многие крупные компании США и Европы уже несколько лет назад перешли на использование информационных систем стандарта ERP. Про страны Азии такого сказать пока нельзя. Большинство финансовых менеджеров азиатских компаний едва ли слышали о таких системах, не говоря уж об их внедрении.

Хотя есть компании, которые решились перейти на ERP-системы.

Разработчики информационных систем, в частности SAP, Baan, Oracle, PeopleSoft и J.D.Edwards, довольно агрессивно рекламируют свои продукты, что создает впечатление у плохо осведомленных в данной области людей впечатление, что эти программы способны решить все проблемы их компаний.

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

Например, руководство компании FoxMeyer утверждает, что ошибочное внедрение ERP-системы привело ее к банкротству. Компания обвиняет в этом создателей системы и консультантов. Такая же участь постигла и компании Dell Computer, Dow Chemical и Kellogg’s.

Но существуют также примеры успешного использования ERP-систем. Так, например, телекоммуникационная компания Aliant заявляет, что проект по внедрению системы ERP был очень удачным. Ожидаемая норма возврата на инвестиции в данный проект составила 33%.

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

Глава 2.Выбор, внедрение и эксплуатация информационной системы

2.1. Проблема выбора информационной системы

Требования к информационной системе.

Информационная система управления для промышленного предприятия не должна замыкаться только в рамках управления бизнес-процессами. Данная система должна объединить в себе все три уровня управления процессами происходящими на предприятии:

· управление бизнес процессами

· управление проектно-конструкторскими разработками

· управление технологическим процессом производства.

Единство информационной системы управления предприятием состоит в том, что данные, полученные или введённые на любом уровне системы, должны быть доступны всем её компонентам (принцип однократного ввода).

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

“Становым хребтом” единой информационной системы управления предприятием является система управления бизнес процессами предприятия - система класса ERP (Enterprise Resources Planning - Планирование ресурсов предприятия). Необходимым элементом являются системы автоматизации проектно конструкторской деятельности и технологической подготовки производства (САПР/АСТПП - CAD/CAM/CAE/PDM), обеспечивающие снижение времени производственного цикла и повышения качества продукции. Третий элемент - системы управления технологическим процессом производства. Связующее программное обеспечение обеспечивает взаимодействие всех ранее описанных решений в рамках единой информационно - аналитической системы управления предприятием.

Проблемы выбора.

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

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

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

Для украинского пользователя выбор таких систем ограничен. Не так уж много западных фирм вышли на постсоветский рынок. Реально это SAP, Computer Associates, BAAN и ISF. Попытки выйти делали ORACLE, JDEdvards, SSA, JBA и QAD. Причем реальные внедрения имеются только у продуктов SAP и Computer Associates. Кроме того, различные системы предназначены для разных предприятий. Одни, такие как SAP или CA-Masterpiece, ориентированны на корпоративный рынок, другие, как BAAN или MK Enterprise (ранее MANMAN/X) на рынок промышленных предприятий или компаний. И предприятию нужно сделать правильный выбор, чтобы в результате ошибки не оказаться обладателем системы не подходящей для него.

2.2. Критерии выбора системы

Функциональные возможности.

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

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

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

Совокупная стоимость владения.

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

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

Перспективы развития.

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

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

Технические характеристики.

Понимание технических характеристик в наибольшей степени гарантирует соответствие системы поставленным перед ней задачам. К техническим характеристикам можно отнести:

Архитектуру системы,

Надежность,

Масштабируемость,

Способность к восстановлению,

Наличие средств резервного копирования,

Средства защиты от технических нападений,

Возможность интеграции с другими системами.

Минимизация рисков.

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

Для снижения такой вероятности проводится комплексный анализ факторов риска и поэтапное воплощение решения. Каждый этап предваряется новой оценкой действительности и решение модифицируется определенным образом.

Для минимизации инвестиционных рисков выделяют следующие объекты затрат:

· процесс создания системы

· оборудование

· программное обеспечение

· персонал

· управление задачами

Для каждого объекта затрат выдвигается целый ряд характеристик, которому он должен удовлетворять с целью снижения рисков.

2.3. Методы внедрения системы

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

Необходимо:

1. Добиться веры в успех и преданности делу со стороны тех, кто играет ключевую роль в реализации проекта.

2. Определить, кто будет штатным руководителем проекта по внедрению системы. Этот человек должен обладать необходимыми навыками для выполнения такой работы, желательно, чтобы он имел опыт внедрения систем.

3. Четко определить и отразить в документах функции и обязанности, а также сферу компетенции каждого члена группы специалистов по работе над проектом.

4. Убедиться, что люди, выполняющие эти функции, обладают необходимыми навыками.

5. Разработать подробный план работы, разбить его на этапы, определите сроки выполнения задач и придерживаться их.

Прежде чем приступить к внедрению системы, необходимо продумать организационную структуру и бизнес-процессы:

1. Убедиться, что правила и процедуры бухучета зафиксированы в документах по установленной форме и понятны работникам бухгалтерии.

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

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

4. Описать организационную структуру и подумать о том, в максимальной ли степени она отвечает целям предприятия.

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

Обеспечить создание необходимой технической инфраструктуры:

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

2. Осуществить необходимые изменения в перечисленных областях перед тем, как передать систему в промышленную эксплуатацию. Убедиться, что система отвечает основным потребностям всех пользователей.

3. Документально зафиксировать потребности бизнеса с той степенью подробности, которой будет достаточно для сравнения одной системы с другой.

4. Пользоваться полученными документами, чтобы убедиться, что реализованные функции отвечают потребностям.

Управлять изменениями, подстраиваясь под сотрудников.

1. Проводить изменения постепенно, не забывая о том, что за один раз сотрудники могут освоить лишь определенное количество информации.

2. С самого начала задействовать всех, кто играет основную роль в осуществлении проекта. Хороший способ добиться этого - попросить их высказывать свое мнение в процессе подробного определения потребностей бизнеса.

3. Регулярно общаться с такими сотрудниками, давая им возможность быть услышанными.

4. Разработать план обучения таким образом, чтобы люди не просто научились осуществлять ввод данных в систему, но поняли, как изменится их работа.

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

2.4. Этапы внедрения информационной системы

Следует выделить три этапа внедрения информационной системы:

1. Исследование. Компания-внедренец проводит исследование бизнес процессов вашей компании.

2. Доработка системы. Программисты компании-внедренца настраивают или дорабатывают требуемую функциональность системы.

3. Запуск системы. Начало реального использования системы, включает процессы обучения персонала.

Исследование бизнес процессов.

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

На данном этапе необходимо как можно более точно описать представителям компании, какие процессы необходимо улучшить.

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

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

Доработка системы.

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

На этапе доработки системы важно контролировать процесс реализации требуемых функций в информационной системе. Необходимо проверять соответствие реализации требованиям компании и при необходимости использовать установленный механизм для влияния на компанию-внедренца.

Важно, чтобы со стороны компании выступал менеджер проекта внедрения, хорошо знакомый с задачами компании и её бизнес процессами. Необходимо понимать, что этот человек также должен иметь опыт по поддержке внедрения подобных систем в компании.

Запуск системы.

На этом этапе важно переключить бизнес процессы компании на использование внедренной системы. Основная задача быстро обучить и мотивировать персонал использовать новую информационную систему.

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

Развитие информационной системы.

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

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

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

З аключение

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

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

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

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

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

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

Гарантировать полную безопасность и целостность данных на всех этапах обработки информации.

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

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

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

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

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

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

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

Установить реальные сроки и составить незаниженный бюджет;

Привести в соответствие с новыми требованиями уровень подготовки сотрудников отдела информационных систем;

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

Типовой план внедрения был разработан в компании Oliver Wight, но опыт показывает, что в той или иной степени практически все фирмы следуют этой стратегии.

Данный план состоит из следующих этапов:

1. Предварительное обследование и оценка состояния компании;

2. Предварительная переподготовка;

3. Техническое задание (анализ проблемы построения системы);

4. Технико-экономическое обоснование (анализ «затраты-эффект»);

5. Организация проекта (назначение ответственных лиц, состав комитетов);

6. Выработка целей (что мы ожидаем от проекта);

7. Техническое задание на управление процессами;

8. Начальная переподготовка (переподготовка сотрудников);

9. Планирование и управление верхнего уровня;

10. Управление данными;

11. Одновременное внедрение различных технологий организации и управления;

12. Программное обеспечение;

13. Опытный пример;

14. Получение результатов;

15. Анализ текущего состояния;

16. Постоянная переподготовка.

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

Список источников:

1. Барановская Т. П. и др. Информационные системы и технологии в экономике Издательство: Финансы и статистика, 416 стр., 2003 г.

2. Баронов В.П., Титовский И.Л., статья «Методы построения систем управления»

3. Божко В. П. Информационные технологии в статистике Издательства: Финстатинформ, КноРус, 144 стр., 2002 г.

4. Веревченко А. П., и др. Информационные ресурсы для принятия решений Издательства: Деловая Книга, Академический проект; 560 стр., 2002г.

5. Волокитин А. В., и др. Средства информатизации государственных организаций и коммерческих фирм. Справочное пособие Издательство: ФИОРД-ИНФО 272 стр., 2002 г.

6. Гаскаров Д. В. Интеллектуальные информационные системы Издательство: Высшая школа, 432 стр., 2003 г.

7. Герасимова Л.Н. Информационное обеспечение маркетинга Издательство: Маркетинг, 120 стр., 2004 г.

8. Годин В. В., Корнеев И. К. Информационное обеспечение управленческой деятельности Издательства: Высшая школа, Мастерство; 240 стр., 2001 г.

9. Гринберг А. С., Король И. А. Информационный менеджмент Издательство: Юнити-Дана; 416 стр., 2003 г.

10. Гринберг А. С., Шестаков В. М. Информационные технологии моделирования процессов управления экономикой Издательство: Юнити-Дана; 400 стр., 2003 г.

11. Душин В. К. Теоретические основы информационных процессов и систем Издательство: Дашков и Ко, 250 стр., 2002 г.

12. Калянов Г. Н. Консалтинг: от бизнес-стратегии к корпоративной информационно-управляющей системе Издательство: Горячая Линия – Телеком 208 стр., 2004 г.

13. Карабутов Н. Н. Информационные технологии в экономике Издательство: Экономика; 208 стр., 2003 г.

14. Когаловский М. Р. Перспективные технологии информационных систем Издательства: ДМК Пресс, Компания АйТи; 288 стр., 2003 г.

15. Колесников С.И., статья «Об оценке эффективности внедрения и применения ERP систем»

16. Липаев В. В. Системное проектирование сложных программных средств для информационных систем Издательство: Синтег; 268 стр., 2002 г.

17. Майкл Дж. Д. Саттон Корпоративный документооборот. Принципы, технологии, методология внедрения

18. Издательства: Микро, Азбука, 446 стр., 2002 г.

19. Маклаков С. В. Моделирование бизнес-процессов Издательство: Диалог – МИФИ, 240 стр., 2003 г.

20. Меняев М. Ф. Информационные технологии управления. Книга 3. Системы управления организацией, 464 стр., 2003 г.

21. Патрушина С. М. Информационные системы в экономике. Издательство: Бизнес, 352 стр., 2004 г.

22. Прокушева А. П., Липатникова Т. Ф., Колесникова Н. А. Информационные технологии в коммерческой деятельности Издательство: Маркетинг, 192 стр., 2001 г.

23. Родионов И. И., и др. Рынок информационных услуг и продуктов Издательство: МК-Периодика 552 стр., 2002 г.

24. Сар Эрмако Джонии, статья «Быть или не быть ERP?»

25. Синюк В.Г., Шевырев А.В. Использование информационно-аналитических технологий при принятии управленческих решений Издательство: ДМК Пресс; 160 стр., 2003 г.

26. Скрипкин К. Г. Экономическая эффективность информационных систем Издательство: ДМК Пресс; 256 стр., 2002 г.

27. Стрелец И. А. Новая экономика и информационные технологии Издательство: Экзамен, 256 стр., 2003 г.

28. Уткин В. Б., Балдин К. В. Информационные системы в экономике Издательство: Финансы и статистика, 288 стр., 2004 г.

29. Хорошилов А. В., С. Н. Селетков Мировые информационные ресурсы Издательство: Питер; 176 стр., 2004 г.

30. Шафрин Информационные технологии. Часть 2 Издательство: Бином. Лаборатория знаний; 320 стр., 2002 г.

31. Эриксен Т. Х. Тирания момента. Время в эпоху информации Издательство: Весь Мир, 208 стр., 2003 г.

Использованы материалы с сайтов:

32. www.altrc.ru

33. www.bankreferatov.ru

34. www.economics.ru

35. www.erp-people.com

39. www.parus.ru

Введение

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

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

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

Автоматизация работы конструкторов и технологов начиналась с развития АРМ (автоматизированных рабочих мест), то есть средств для решения инженерных задач и выпуска соответствующей документации. С появлением больших объемов информации в электронном виде возникла потребность этой информацией управлять — на сцену начали выходить PDM- и PLM-системы. Таким образом, результаты работы локальных средств автоматизации интегрируются третьей системой, а локальные АРМ получают возможность пользоваться общей справочной информацией.

В нашем случае мы имеем дело с принципиально иным способом работы с конструкторской и технологической информацией. Система TechnologiCS (а в дальнейшем речь пойдет именно о ней) представляет собой прежде всего централизованное хранилище информации об изделиях (базу данных). С этой точки зрения она очень похожа на традиционные системы управления предприятием (АСУП). Тем не менее есть и существенное отличие, позволяющее преодолеть традиционный изъян подобных систем — недостаточную актуальность данных и часто возникающую необходимость в повторном вводе информации. TechnologiCS (www.technologics.ru) предоставляет владельцам информации — конструкторам и технологам — возможность непосредственной работы с базой данных. При этом доступ к базе осуществляется через удобный интерфейс, в каждом конкретном случае ориентированный на выполнение определенной функции (аналогично АРМ); предусмотрены и все необходимые средства автоматизации для решения инженерных задач.

В задачу авторов этих строк не входит полный сравнительный обзор всех известных способов построения информационных систем — тем более что различные источники по-разному трактуют понятие единой информационной среды. Отметим лишь один очевидный факт: совместная работа пользователей с одними и теми же информационными объектами (например, составом изделия или технологическим процессом) возможна при том способе построения информационной системы, который реализован в TechnologiCS.

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

Процессный подход

Под бизнес-процессом принято понимать цепь логически связанных повторяющихся действий, которые совместно реализуют некую бизнес-задачу или цель предприятия. Современная процессно-ориентированная организация (рис. 1) — это совокупность специализированных функциональных отделов с одной стороны и совокупность бизнес-процессов — с другой. В каждом из отделов реализуются конкретные функции бизнес-процессов, а сотрудники таких организаций, помимо традиционного функционального подчинения, в рамках выполняемых бизнес-процессов подчиняются соответствующим владельцам этих процессов.

Приходится признать, что сегодня многие машиностроительные предприятия России являются функционально-ориентированными организациями (рис. 2), структура которых, в отличие от процессных организаций, имеет вертикальную топологию, построенную в соответствии с выполняемыми функциями, и строгую иерархическую подчиненность сверху вниз.

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

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

Функциональное и процессное внедрение ИС

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

Если предприятие собирается автоматизировать деятельность отдельных сотрудников или служб предприятия (применительно к нашей предметной области речь, как правило, идет об инструментах конструкторов или технологов), то налицо функциональный подход: стремление автоматизировать отдельные функции предприятия. Наилучший из возможных результатов такой автоматизации — сокращение сроков выполнения и повышение качества этих функций (в данном случае — разработки соответствующей документации). При этом от системы обычно требуется обеспечить пользователям максимум удобства при выполнении соответствующих функций, а вопросы дальнейшего использования появляющейся информации отодвигаются на второй план.

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

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

Говоря о процессном внедрении, нельзя не упомянуть об инструментарии, применяемом для моделирования бизнес-процессов. Сам по себе процессный подход не предъявляет особых требований к инструментам описания и проектирования бизнес-процессов, однако использование специализированных инструментов вместо стандартных офисных программ имеет массу неоспоримых преимуществ. Среди множества представленных на рынке инструментальных средств, пожалуй, наиболее эффективным следует признать программный продукт ARIS (этот вывод подтверждается результатами исследований, опубликованными Gartner Group в январе 2004 года). ARIS (Architecture of integrated Information Systems — архитектура интегрированных информационных систем) представляет собой методологию и базирующееся на ней семейство программных продуктов, разработанных компанией IDS Scheer. Чтобы дать некоторое представление об ARIS, перечислим ее основные преимущества:

Представление бизнес-процессов в виде графических моделей;

Наличие единого стандарта моделирования;

Ориентация на процессный подход;

Наличие единого репозитория (базы данных), позволяющего использовать в разных диаграммах одни и те же объекты, совмещая различные точки зрения на организацию;

Возможность генерации разнообразных отчетов по разработанной модели — в том числе и отчетов, специально разработанных пользователем;

Возможность организации совместной работы в сетях Интернет и интранет.

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

Информационная система и процессный подход

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

1. Отсутствие автоматизации .

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

Основной носитель информации в этом случае — документ, обработка информации носит последовательный характер.

2. На предприятии действует автоматизированная система управления (АСУП) .

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

В этом случае, несмотря на появление централизованного хранилища информации (базы данных), характер бизнес-процессов по сравнению с первым вариантом практически не меняется. Остается неизменным и последовательный характер обработки информации.

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

Когда предприятие по отдельности автоматизирует те или иные функции, имеет место так называемая лоскутная автоматизация. Качество реализации этих функций, несомненно, становится выше, сокращается и время их выполнения, однако результаты работы локальных систем воплощаются в виде все тех же документов. Не меняется и способ обработки документов (в том числе при взаимодействии с АСУП), причем совершенно неважно, идет ли речь о выводе документов на бумагу или об обмене электронными файлами.

Оставим за рамками обсуждения использование традиционных PDM- и PLM-систем — это тема отдельной дискуссии. Тем более, как уже сказано, существуют различные трактовки самого понятия «единая информационная среда» и принципов организации совместной работы с информацией...

Что же дает внедрение системы TechnologiCS в плане применения процессного подхода и совершенствования бизнес-процессов?

Единая информационная среда источников и потребителей информации прежде всего позволяет кардинально изменить назначение бумажного документа и рассматривать его не как носитель информации, а как отчет, сформированный на основе соответствующего информационного объекта базы данных. Таким образом, бумажный документ становится носителем юридического статуса и представляет собой набор данных из базы, распечатанный на бланке. При этом файл (электронный документ) сохраняется в централизованном электронном архиве, являющемся неотъемлемой частью системы, и связывается с объектом базы данных, на основании которого он был получен. Создатели информации (конструкторы, технологи) и ее потребители работают с соответствующим информационным объектом напрямую, имея при этом доступ к электронным документам в рамках прав, предоставленных им системой. Порядок организации работы с документами при использовании их в качестве носителей информации и отчетов по базе данных показан на схемах (рис. 3 и ).

Перечислим основные преимущества рассматриваемого способа работы — с точки зрения организации процессов на предприятии:

1. Реальная совместная работа с информацией в большинстве случаев позволяет перейти от последовательного способа обработки информации к параллельному. Другими словами, появляется возможность распараллелить бизнес-процесс, значительно сократить сроки разработки и сэкономить время для таких операций, как согласование, утверждение документации, внесение конструкторских и технологических изменений.

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

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

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

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

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

Известно, что идеальных систем не бывает, и система TechnologiCS, несмотря на ее непрерывное совершенствование и быстрое развитие, в этом смысле — не исключение. При внедрении она накладывает некоторые ограничения на способы реализации процессов, поэтому проектирование процессов по принципу «как должно быть» оказывается неизбежным компромиссом между требованиями процесса и возможностями системы. Важно, что TechnologiCS способна обеспечить сквозную, несегментированную реализацию процессов конструкторской и технологической подготовки производства, а также эффективное использование данных для решения задач производственного планирования и учета, обеспечивая, таким образом, автоматизацию процесса в целом.

Опыт реальных проектов

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

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

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

3. Как правило, вследствие естественного сопротивления любым изменениям предприятия не всегда полностью готовы изменять существующие бизнес-процессы.

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

Приведем пример из практики, обещанный в самом начале этой статьи. Подходы, преимущества которых мы постарались обосновать выше, использовались при подготовке проекта внедрения системы TechnologiCS для автоматизации процессов конструкторской и технологической подготовки производства на Новосибирском заводе химконцентратов. Работы были выполнены проектной группой, состоявшей из специалистов компании CSoft (www.csoft.ru), консультантов компании «Логика бизнеса» (www.ids-scheer.ru) и сотрудников предприятия.

Руководству предприятия не потребовалось доказывать преимущества процессного внедрения, тем более что незадолго до этого под руководством консультантов компании «Логика бизнеса» на заводе был выполнен пилотный проект по описанию и совершенствованию бизнес-процессов планирования. Предприятие проявило высокую готовность к изменениям бизнес-процессов в заявленной предметной области, а детальное знакомство с возможностями TechnologiCS убедило заказчика в принципиальной применимости процессного подхода — сквозной автоматизации процессов конструкторской и технологической подготовки производства.

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

Подготовка проекта;

Концептуальное проектирование;

Реализация;

Заключительная подготовка;

Ввод в эксплуатацию и поддержка.

На этапе подготовки определяются стандарты проекта (в том числе стандарты моделирования бизнес-процессов), выполняется моделирование бизнес-процессов «как есть». Детальность проработки модели и необходимые для этого ресурсы в значительной степени определяются состоянием предприятия.

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

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

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

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

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

В рамках этой статьи мы ограничимся обзором первых двух этапов внедрения системы на Новосибирском заводе химконцентратов.

Подготовка проекта

Важнейшей частью этого этапа стала разработка стандарта моделирования бизнес-процессов и подготовка документа «Соглашения о моделировании». Документ содержит перечень, свойства, правила наименования, описание взаимосвязи диаграмм и объектов, используемых для моделирования бизнес-процессов, а также применяемых при моделировании графических нотаций. Соглашения о моделировании определяют необходимое и достаточное подмножество методологии ARIS, обеспечивающее достижение целей моделирования, и устраняют риски, связанные с непониманием, возникающим между заказчиком и исполнителем.

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

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

Выполненный на предприятии незадолго до начала внедрения пилотный проект по описанию и совершенствованию бизнес-процессов планирования снизил степень риска, связанного с сопротивлением предстоящим изменениям.

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

Концептуальное проектирование

Эта фаза началась с разработки референтной модели, описывающей функциональность и информационные объекты системы TechnologiCS с учетом требований документа «Соглашения о моделировании». Разработка такой модели позволила формализованно подойти к решению задачи проектирования процессов «как должно быть» с учетом реальных возможностей системы и значительно упростила выполнение работ данного этапа.

Далее на основе общей концепции системы, опыта реальных внедрений и с учетом предложений, высказанных на предыдущем этапе, было выполнено проектирование бизнес-процессов «как должно быть». По созданной в ARIS модели с помощью специально разработанных программ (скриптов отчетности) был произведен автоматический расчет количества рабочих мест с привязкой к бизнес-ролям и к конкретным исполнителям функций бизнес-процессов. Для каждой бизнес-роли автоматически формировались профили полномочий.

Результатом работы на этом этапе стало появление детально проработанного документа «План перехода к процессам “как должно быть”» (рис. 5).

Краткие выводы

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

Моделирование бизнес-процессов наиболее эффективно с применением специализированных инструментов и проверенных методологий.

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

Для успешного внедрения системы необходим серьезный объем подготовительной работы.

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

Формализованное описание ситуации, в которой предприятие находилось до внедрения;

Формализованное описание целевой ситуации, формирующейся в результате внедрения;

Обоснованный объем финансовых ресурсов, необходимых для приобретения лицензий программного обеспечения;

Обоснованный объем трудозатрат, необходимый для осуществления всего проекта; сроки проведения этих работ;

Обоснованный объем финансовых ресурсов, которые необходимо затратить на привлечение внешних консультантов;

Обоснованный объем внутренних трудовых ресурсов, занятых в рамках проекта.

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

Планируем проект внедрения и доработки информационной системы в MS Project - быстро и красиво

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

Для того что бы не объяснять каждому новому ПМу как делать план в Project"e и какие работы и какую структуру туда закладывать, я решил сделать некий драфт плана, который показывал бы типовую структуру работ по проекту внедрения и доработки простой информационной системы, стоимостью приблизительно 5 миллионов рублей и сроком около полугода. Условно, заказчик хочет стартовать проект в мае, а завершить в октябре, при этом старт проекта для нас - начинается в апреле, с подготовки пилота и КП.

Описание проекта

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

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

Риски проекта

Поскольку никакого Rocket Science в проекте нет, его риски составляют около 10%. Заложить их можно по разному - добавить 10% к стоимости ресурсов (но это не учитывает сроки), планировать работы с учетом рисков накидывая 10% длительности к каждой сколько-либо рискованной (именно такой вариант использовал я), или сделать этап Contingency перед завершающим этапом (в моем случае он бы составлял 3 недели или ~1/10 от длительности проекта.

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

Команда проекта

Руководитель проекта - менеджер, с хорошей технической экспертизой и навыками бизнес- анализа. Хорошо разбирается в функциональности решения, понимает бизнес-задачу заказчика.
Аналитик - проводит встречи по анализу, занимается разработкой проектной документации (протоколы встреч, описание функциональных требований, спецификаций, инструкций и т.д.)
Специалист по внедрению - отвечает за внедрение решения, организацию инфраструктуры для серверов, а так же их связь с внешним миром. Т.е. настраивает ОС, БД, отвечает за трекер поддержки и т.д.

• Ведущий разработчик - он же архитектор. Участвует в проработке архитектуры решения, оценке задач по разработке, обеспечивает наставничество команде разработки и помощь в решении сложных задач.
• Разработчик - основной разработчик проекта,
• Младший разработчик - джуниор на подхвате кода, решает задачи под контролем разработчика, параллельно учится.
• Аккаунт - менеджер по работе с клиентами, отвечает за взаимодействие с клиентом, составление и подписание договоров, контроль удовлетворенности клиента и т.д. В проектный ФОТ напрямую не включается, т.к. его работа не планируется РП.
• Куратор - высший менеджер компании исполнителя, обеспечивающий контроль и поддержку проекта. Может быть так же - руководитель портфеля проектов и т.д. В проектный ФОТ напрямую не включается, т.к. его работа не планируется РП.
• Заказчик - все сотрудники заказчика, привлекаемые к проекту. В плане - не детализируемы, предполагается что заказчик сам решит, кого из своих специалистов привлекать к тем или иным активностям.

Конечно, нам нужно забить команду проекта на представлении «Лист ресурсов» - я просто указал роли, краткое наименование и внутренние ставки (они «средние по больнице» и не привязаны к конкретной компании), а так же указал свой базовый календарь (в общем, соответствующий производственному календарю на 2018 год). Если вы используете сервер проектов, в дальнейшем вы можете указать вместо роли - конкретных исполнителей, но на данном этапе - важны именно роли, для понимания необходимости сотрудников той или иной квалификации. Если вы готовите план проекта для представления заказчикам, есть смысл заменить внутренние ставки на внешние - и то и другое вы наверное уже знаете, а если нет - то это повод обратится к владельцам ресурсов, которые их откроют.

Минимум миниморум:

Конечно, роли могут быть другими - все зависит от компании (и методологии) в которой вы делаете проекты. Одним даром не нужен аналитик и внедренец, у них есть консультанты, другие делят аналитиков на бизнес и системных и добавляют техписателей, третьи используют стажерские программы с подключением сотрудников и т.д. У меня - один из множества вариантов команды, на листе ресурсов можно смело заменить сущности на свои и добавить новые.
Здесь, мы отмечаем заказчиков - зеленым цветом, а специалистов нашей компании, не подлежащих к расчету ФОТа - фиолетовым. Кроме того, что это наглядно, это так же удобно в дальнейшем, например если заказчик попросит сформировать график его привлечения к проекту - вы просто выгрузите план в Excel и отфильтруете по цвету.

Жизненный цикл проекта

В данном кейсе использован очень простой и распространённый жизненный цикл проекта - хорошо знакомый всем «Waterfall» где несколько фаз следуют друг за другом.

Некоторые части проекта все же сделаны итеративно - например разработка разбита на итерации, в конце каждой из которых - реализуется показ разработанного функционала заказчику.
Но тем не менее, такой жизненный цикл не предполагает каких либо серьезных изменений в ходе проекта, поэтому предполагается что скоуп проекта определен на этапе входа в проект, а ограничения по скоупу разработаны и включены в договор. Стоит так же отметить «Этап 0» - на котором происходит оценка скоупа и организация пилотного проекта (для некоторых компаний это нынче редкость) - здесь предполагается что руководитель проекта выступает так же неким руководителем пресейла, в котором он описывает и оценивает функционал, а так же неким руководителем «пилотного» проекта - цель которого, познакомить заказчика с функционалом системы, показать ему интерфейс и преимущества на берегу, что бы заинтересовать его. Пилотный проект назвать проектом можно лишь условно - естественно, это просто стандартная заготовка системы минимально дорабатываемая под нужды конкретного заказчика. Например, виртуальная машина со стабильной версией системы, в которой может быть быстро реализована пара простых, но реальных процессов заказчика, и, например, быстро настроена связь с одной из используемых им систем (на основе уже существующего драйвера, или коннектера, требующего лишь простой настройки).

Так же для экономии места на экране я убрал отображение поля «Режим задачи» - на всех задачах он автоматический, ручного нигде нет.

Общий обзор этапов, их сроков и стоимости:

Итак, у нас есть 8 этапов (включая этап 0) и проект, который начинается 2 апреля, завершается 5 октября. Заказчику - можно вовсе не показывать этап 0, и конечно, не стоит его учитывать если вы не считаете ФОТ пресейлов и пилотов (но это для первый звоночек того, что вам есть над чем поработать, так как такой ФОТ считать нужно обязательно).

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

Этап 0 - подготовка проекта

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

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

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

При средних ставках внедренца и ПМа такой пилот будет стоить нам 59 400 рублей + еще 10800 рублей на его сопровождение, ведь у Заказчика появятся вопросы про его развертывание и использование. Ну как, вы все еще не хотите считать затраты на нулевом этапе?

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

Предположим, процесс описания скоупа и оценки у вас поставлен на поток, и после оценки куратор проекта одобряет ее (и накидывает % на торг и внепроектные риски) после чего КП отправляется на согласование заказчику. Здесь указанных 7 рабочих дней может быть явно мало, поэтому эта работа указана отдельно, и именно от нее зависит веха «КП Утверждено».

Разделять задачи по организации пилота и оценке скоупа проекта - надо, т.к. вы должны хорошо понимать их стоимость, и пытаться оптимизировать затраты на подготовку пилотов и оценку (например, создать типовые шаблоны для оценки и типовые виртуалки для внедрения).

Этап 1 - сбор требований

Итак, вы успешно подписали контракт (или получили одобрение от спонсора внутреннего проекта) и теперь самое время стартовать, начав со сбора требований к системе. Но перед этим, надо надо устроить kick-off meeting, или как это называется на русском, стартовую встречу.

В некоторых проектах есть смысл показать разработанный Project Charter, в некоторых проектах вместе с договором подписывается официальный устав, но независимо от этого кикофф нужен - для того, что бы ясно объяснить цели и сроки проекта команде (или командам) и познакомить всех друг с другом, договорится о взаимодействии. В общем, проведение Kick-off - это тоже тема отдельной статьи.

Т.к. проект небольшой, мы предполагаем, что 12 часов за глаза хватит нам, что бы подготовить небольшую презентацию, в которой мы вкратце обозначим цели и задачи проекта, участников и их роли, наглядно покажем сроки проекта (например, красивую диаграмму Ганта) и представим следующие шаги (например график встреч с заказчиком).

А вот кстати, и график встреч - для нашего простого проекта мы предусмотрели 6 встреч, на которых участвуют разные специалисты и которые стоят для нас по разному. Предполагается, что график мы заранее согласовали с заказчиками (или спонсорами), что бы бизнес-пользователи и вообще все заинтересованные лица, не ушли в отпуска или не были заняты на других активностях. Конечно, если вы работаете над внешним проектом, есть смысл включить план проекта в договор - в этом случае никто не сможет обвинить вас в срыве сроков, если заказчик по каким то причинам не сможет присутствовать на встречах.

Рассмотрим несколько встреч на примере:

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

Логическим окончанием встречи у нас является ее протокол, высланный на ревью заказчику. Здесь важно учесть следующее - у меня встреча и составление протокола - запланированы на 1 день, т.е. утром проходит встреча, далее обед и пишется протокол, который отправляется на согласование заказчику. Заказчик же, в то время как команда проекта пишет протокол, согласовывает протокол предыдущей встречи.

Естественно, это идеальный вариант, который работает только при наличии 2 очень сильных и мотивированных проектных команд.

В реальной жизни - отсидеть на встрече 4 часа и за 4 часа составить приличный протокол с описанием требований и договоренностей (или отревьювить его) - и так 6 дней подряд - довольно тяжело. Не говоря о том, что встреча может быть и более 4 часов (кстати, в этом случае эффективность встречи резко падает и протокол может быть и не согласован). Если сроки (и заказчик) позволяют - заложите 1 встречу в 2 дня, и возьмите запас недельку - для проведения дополнительных встреч и ревью протоколов. Если вы на 100% не уверены в заказчике и команде - никогда не ставьте на неделе более 3 встреч. Ну и конечно, все зависит от региона присутствия - если вы делаете проект в своем городе, или хотя бы в своей области - тут торопится смысла нет. Если же ваш заказчик из Нового Уренгоя, а вы - из Самары - увы, придется выложится на встречах по полной - мариновать команду без работы в другом городе нет никакого смысла. Так же, обязательно пропишите участие заказчика во встречах отдельной строкой - и вставьте это в договор.

Этап 2 - Архитектура и дизайн

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

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

Есть ли смысл детализировать эти 5 дней в задачи и отражать их в плане проекта? На мой взгляд нет, логичнее сделать это в Jira/Redmine, а заказчику/спонсору показать такой план.
У меня предусмотрено 2 итерации согласования - это совершенно разумно, но требует от заказчика определенной ответственности - на берегу стоит объяснить, что все замечания к ТЗ Заказчик выставляет в одной итерации, а во второй - только проверяет их исправление, а новые замечания - не ставятся. Если заказчик настаивает на третей итерации замечаний - что ж, хозяин барин, вставляем и третью (и четвертую, и пятую…) не забыв прописать затраты и объяснить заказчику насколько вырастет стоимость проекта. Презентовать ТЗ первый раз разумно вдвоем с аналитиком, а вот вычитывать его необходимо всей команде - на сколько либо больших проектах это весьма емкий документ, который является условием для завершения фазы проекта (а следовательно подписания актов и оплаты), и случайные ошибки в нем не допустимы. Если у вас в компании есть свободные ресурсы, например аналитики, логично подключить их к чтению ТЗ в качестве свежего взгляда - ТЗ от этого хуже не станет, а проект не подорожает на сколько бы существенно.

Этап 3 - Разработка

Итак, техническое задание подписано, и казалось бы можно приступать к разработке.
Первое, о чем хочется сказать - это предупредить о недопустимости начала разработки, без утвержденного ТЗ. Это ведет просто к тому, что одну и ту же работу приходится делать 2 раза. Конечно, если вы работает по Agile, и у вас четких требований нет, а есть заказчик платит по схеме Time&Materials, тогда смело игнорируйте это требование. Если же скоуп проекта у вас утвержден, оплата FixPrice и вы не закладывали бюджет и сроки на переделку задач, то не позволяйте разработчикам сделать ни единого коммита, без подписанного ТЗ.

Второе - конечно подразумевается, что инфраструктура для разработки развернута, а процессы отлажены. Нерадивые спонсоры и кураторы проектов, стремятся включить в бюджет проектов такие расходы - переход на использование CI, развертывание Jira/Redmine, переход на новую версию ПО и библиотек, БД и т.д. и т.п. Задача ПМа здесь - защитить свой проект (и его бюджет) от такого, аргументируя что такие вещи должны быть вынесены в отдельные проекты с отдельными бюджетами.

Если вы работает по Waterfall - делать разработку стоит итерационно - т.е. разбить весь скоуп на части и показывать заказчику/спонсору по мере наработок. Пускай в софте еще будут баги, пускай нет данных, пусть формы не доделаны - лучше потратить бюджет и время на написание сценариев показа и дополнительные тесты, чем пропасть на месяц с глаз заказчика и появится с готовым продуктом. Фидбек заказчика на этапе завершения итерации разработки так же полезен, но это не значит что его надо бездумно пихать в скоуп - оцените его замечания. Если он предлагает что то несущественное - например, сменить цвет или размер поля на форме - покажите что вы лояльны и приветливо согласитесь. Если заказчик предлагает откровенно сложный функционал - откажитесь, аргументировав отсутствием в скоупе, а если заказчик настаивает - запускайте свою машину changemanagment"а (конечно, она у вас есть). Бывает, что заказчик предлагает казалось бы что то не существенное, например поменять формат телефонного номера, но это может сказаться на всей системе. В этом случае, посоветуйтесь с ведущим разработчиком/архитектором, возьмите его оценку под этой фичей, если она небольшая - можно пойти навстречу заказчику для повышения лояльности (но стоит помнить о риске ошибки оценки).

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

Этап 4 - Тестирование

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

Обратите внимание на задачу 110 (исправление дефектов) - она параллельна 109 (поиску дефектов) с задержкой в день. Т.е. предполагается, что тестировщик, проходя по тест-кейсам, описывает дефекты в системе задач, а разработчики правят их не отходя от кассы. Такой подход разумен и используется, но есть и другое решение - приступать к починке только когда тестирование будет завершено. Какой из этих подходов подойдет именно вам - знает ваш руководитель разработки.

Не забывайте, что заказчик тоже захочет протестировать систему - на этот случай вы предоставите ему документ который называется «ПМИ» - или программа и методика испытаний. Сделать его логично на основе разработанных тест-кейсов, убрав всю внутреннюю кухню и оставив только нужные заказчику вещи (в т.ч. нефункциональное тестирование).

ПМИ должен быть прочитан и утвержден заказчиком и именно по результатам прохождения ПМИ, заказчик будет принимать итоговое решение о переводе системы в промышленную эксплуатацию.
У меня в проекте - согласование ПМИ не включено, т.к. на моей практике, заказчики редко вчитываются в ПМИ и тест-кейсы, ибо слабо понимают о каком конкретно функционале идет речь и чем в одном случае чек-бокс отличается от радиобаттона в другом случае (это шутка, такое вообще в ПМИ писать не надо). Поэтому при разработке документа, особое внимание следует уделить списку кейсов, о прохождении которых пойдет речь, и конечно, проследить что бы они были нормально проработаны внутри.

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

Этап 5 - Внедрение

Ура! Мы добрались! Система на тестовых серверах работает как часы, команда QA отсыпается и уходит в отгулы, и пришел звездный час команды внедрения. Начинается он с развертывания окружения - и тут же у меня в плане заложен некий запас по времени, т.к. я подразумеваю что окружение развёртывали уже минимум 100 раз и в худшем случае на вашей корпоративной вике есть подробная инструкция по развертыванию, а в лучшем - внедренец сам ее писал. Главное, помните - после развертывания полезно протестировать все, что вы можете протестировать по заранее разработанному смоук-тесту, конечно же он остался у вас с фазы тестирования.
Теперь - о главном, ведь если дьявол и кроется где то, то это именно в интеграции и миграции данных. Сколько красивых диаграмм Ганта было погублено тем, что интеграция не была оттестирована тщательно и тем, что данные заказчика находились в ужасном состоянии, ненормализованные, выходящие за все грани разумного (и пределы полей), отличные от того, что написано в ТЗ.

Здесь главное - не дать заказчику сыграть на том, что интеграция (или миграция) может не заработать и переложить ответственность на вас - предупредите его заранее о том, что если эти работы будут задержаны по его вине, ответственность за увеличение сроков (и бюджета) проекта ляжет на его плечи. Не стесняйтесь писать письма и созывать ProjectBoard (или что там у вас) ибо интеграция и миграция пользовательских данных - это самая частая проблема срыва сроков на подобных проектах.

Обучение (тут вас ждет приятный сюрприз) - почти не таит в себе подводных камней. Согласуйте план обучения с заказчиком, и пишите протоколы на всех присутствующих под роспись. Ну и конечно, если вы не уверены в работе своего аналитика - запланируйте еще день репетиции обучения (либо включив это в три дня по написанию инструкций, либо используя внутренний бюджет на риски проекта).

На прохождение ПМИ - планируйте от 25% времени ПМа и выше, в зависимости от вашего опыта и годности аналитика, который участвует в проекте - в идеале испытания должны проходить как по маслу, ну и во всяком случае в этом должен быть уверен заказчик по крайней мере до начала испытаний.

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

Этап 6 - Поддержка

Или, как ее называют - сопровождение ОПЭ (т.к. с гарантийной или технической поддержкой это общего почти не имеет). Итак, вся пицца съедена, бессонные ночи закончены, и ваш проект перешел в промышленную эксплуатацию. Это значит что у заказчика нет (или он просто не сумел найти) критичных замечаний к системе, разработанной в ходе вашего проекта, и дает пользователям команду работать в ней, как в основной системе (или как в клоне боевой системы, такое тоже бывает).

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

Не забывайте, что все проблемы, возникшие в ходе ОПЭ, надо фиксировать в специальном журнале (а в идеале - в трекере задач) и ежедневно отслеживать их статус совместно с заказчиком.

По окончании этапа можете так же запланировать одну встречу команды с заказчиком, где вы торжественно объявите о закрытии проекта и продолжении сотрудничества и подведете итоги. Если только ваш заказчик не в Новом Уренгое.

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

Предложения по этому - я выслушаю в комментариях, и обязательно опубликую mpp в месте, где его можно будет легко и безопасно забрать.

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

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

С чего начинать внедрение информационной системы?

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

• Заключение контракта с крупной компанией, внедряющей ИС. К преимуществам можно отнести опыт компании-аутсорсера и отдельных ее специалистов, а также наличие собственных проектных наработок. К недостаткам относят стоимость работ, возможную текучку кадров и возможность того, что за громким именем могут стоять не самые лучшие специалисты;
• Приглашение небольшой, региональной IT-компании. Однозначным плюсом является высокая вероятность того, что внедрение автоматизированной информационной системы станет приоритетным проектом для нее. Если проект предстоит крупный, а значит долгий, стоит опасаться внезапных смен руководства, специалистов и приоритетов небольших фирм-внедренцев;
• Внедрение силами собственного IT-отдела. В этом варианте привлекает отсутствие дополнительных трат, постоянная связь со специалистами и возможность лично управлять проектом. Однако тут кроется и большая опасность – специалисты IT-отдела, зачастую зависящие от пользователей и руководства, полностью ориентируются их решения, в том числе не всегда правильные;
• Приглашение эксперта. Отличный способ сэкономить и получить специалиста в нужной области. К недостаткам можно отнести необходимость высокой организованности всех сотрудников компании, зависимость успеха от одного человека и формальную ответственность за проект.

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

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

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

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

Успешные внедрения информационных систем включают в себя достаточно много важных и полезных для предприятия этапов. Помимо непосредственно начала работы в ИС, они помогают компании упорядочить ключевые бизнес-процессы и выявить проблемные места. Чем крупнее компания, тем больше принято сотрудников, чьи функции и квалификация вызывают вопросы. Грамотное внедрение информационной системы выявит их.

Если компания хочет не просто «для галочки» внедрить ИС, а действительно эффективно пользоваться всеми ее возможностями, предстоят следующие этапы:

1. В первую очередь необходимо определить цель внедрения. Многие руководители высшего звена поверхностно относятся к этому этапу, но на самом деле он задает направление всему внедрению ИС;
2. Обследование бизнес-процессов компании. В этот этап входят интервью с менеджментом, рядовыми сотрудниками, составление схем по каждому процессу. На выходе получается уточнение целей внедрения и возможность предварительно оценить объем работ и стоимость;
3. Составление проекта, технического задания и регламента. В этих документах должны быть описаны все бизнес-процессы, участвующие во внедрении ИС. Старайтесь составлять проект внедрения максимально подробно, с указанием необходимых данных, их структуры, алгоритмов действий, рабочих мест;
4. Подготовка специалистов. Сотрудники компании при начале внедрения должны знать, что от них требуется, чтобы не задерживать выполнение работы. Также администраторы и разработчики компании должны начать разбираться в информационной системе. То есть сотрудники расширяют свои знания на благо компании;
5. Настройка информационной системы в соответствии со спецификой предприятия. В этот этап включается:
   • Разграничение прав на функционал системы для сотрудников;
   • Начальное заполнение данных;
   • Настройка алгоритмов расчетов, создание необходимых отчетов.
6. Тестирование информационной системы. На этом этапе могут обнаружиться проблемы внедрения в разрезе алгоритмов или необходимость в новых отчетах;
7. Опытная эксплуатация с реальными данными. Чаще всего на этом этапе многие сотрудники компании выполняют больше работы. Им приходится не только работать, как раньше, но и отражать свои действия в информационной системе. Требуется максимальная дисциплина и сосредоточение усилий всех участников внедрения. Конечным результатом должно стать совпадение данных информационной системы с реальным положением дел;
8. Промышленная эксплуатация. На этом этапе осуществляется переход сотрудников на полноценную работу в информационной системе. Должна быть организована техническая поддержка пользователей;
9. Завершение проекта. Основным результатом этапа являются подписанные должностные инструкции, разграничение обязанностей подразделений и их взаимодействия. Корпоративная информационная система запущена на предприятии.

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

← Вернуться