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

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

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

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

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

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

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

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

Студент 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

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

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

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

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

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

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

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

Критически важными для внедрения являются следующие факторы:

· наличие четко сформулированных целей проекта и требований к ИС;

· наличие стратегии внедрения и использования ИС;

· проведение предпроектного обследования предприятия и построения моделей "Как есть" и "Как будет";

· планирование работ, ресурсов и контроль выполнения плана внедрения;

· участие высшего руководства во внедрении системы;

· проведение работ по внедрению ИС специалистами по интегрированию систем совместно со специалистами предприятия;

· регулярный мониторинг качества выполняемых работ;

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

Перед началом разработки проекта внедрения необходимо:

· максимально формализовать цели проекта внедрения ИС;

· оценить минимально необходимые затраты и статьи расхода;

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

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

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

· разработать организационные меры для применения новых информационных технологий;

· распределить персональную ответственность по всем этапам внедрения и опытной эксплуатации.

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

· организационное управление;

· организационно-административное обеспечение;

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

· управленческий, планово-финансовый и бухгалтерский учет;

· управление персоналом;

· управление документацией;

· управление материально-техническим обеспечением;

· управление связями с клиентами и внешней средой.

Кроме того, что перечислено выше, надо задать технологические требования к внедрению ИС:

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

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

· адаптируемость - система настраивается в соответствии с требованиями заказчика и на особенности информационного поля заказчика;

· распределенность - система может эффективно функционировать в территориально удаленных подразделениях и филиалах предприятия;

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

Основные фазы внедрения информационной системы

Фаза "Предварительные работы по подготовке проекта внедрения ИС". В ходе предпроектного обследования предприятия происходит сбор подробной информации о структурном построении организации, функциональных связях, системе управления, об основных бизнес-процессах, о потоках внутри предприятия (Control Flow, Doc Flow, Data Flow, Work Flow, Cash Flow), необходимой для построения соответствующих моделей и выбора объектов для автоматизации. Оцениваются сроки, ресурсы, виды и объемы работ, номенклатура и стоимость программно-аппаратных и телекоммуникационных средств, стоимость обучения персонала и т. д.

Фаза "Подготовка проекта". После завершения первой фазы осуществляется предварительное планирование и формирование процедур запуска проекта:

· формирование проектной и экспертной групп;

· распределение полномочий и ответственности;

· определение организационно-технических требований к процессу внедрения;

· уточнение спецификаций и ожиданий заказчика;

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

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

Фаза "Концептуальная проработка проекта". В течение этой фазы:

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

· достигается обязательное однозначное понимание намерений всех участников проекта относительно внедряемой ИС;

· уточняются и конкретизируются цели и задачи проекта;

· определяются размеры прототипа системы;

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

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

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

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

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

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

7. Факторы успеха и причины неудачных внедрений ИС

моделирование информационный реинжиниринг бизнес

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

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

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

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

Первое. Определите цель проекта

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

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

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

· отсутствие регламентов формирования управленческих отчетов.

· отсутствие единой информационной среды

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

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

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

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

· сокращение запасов на складе за счет более точного планирования производства и закупок;

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

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

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

Второе. Откройте проект

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

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

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

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

Третье. Обеспечьте проект ресурсами

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

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

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

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

Четвертое. Позаботьтесь о мотивации

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

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

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

Пятое. Поддержка руководства

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

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

Шестое. Разбейте проект на этапы

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

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

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

· команда проекта выработала единое понимание результатов этапа;

· это понимание оформлено в виде документа;

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

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

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

Цели проекта могут корректироваться или даже существенно меняться в ходе работы. Это обычная практика. Меняется обстановка, меняется наше понимание ситуации, и мы приходим к выводу, что прежние наши взгляды устарели, или были ошибочными. Поэтому нужно регулярно (на каждом этапе проекта) возвращаться?к истокам? и критически рассматривать все исходные предпосылки.

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

Планируем проект внедрения и доработки информационной системы в 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 в месте, где его можно будет легко и безопасно забрать.

Управление информационными системами

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

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

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

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

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

Информационную модель предметной области;

Кадровые ресурсы, отвечающие за формирование и развитие информационной модели;

Программный комплекс;

Кадровые ресурсы, отвечающие за конфигурирование программного комплекса;

Аппаратно-техническую базу;

Эксплуатационно-технические кадровые ресурсы;

Управленческие элементы, обеспечивающие организацию эксплуатации системы:

Регламент развития информационной модели и правила внесения в нее изменений;

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

Регламент внесения изменений в конфигурацию программного комплекса и состав его функциональных модулей;

Регламент использования программного комплекса и пользовательские инструкции;

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

Задача проекта внедрения информационной системы включает в себя создание (адаптацию) и запуск в продуктивную эксплуатацию всех перечисленных выше элементов. О сложности этой задачи свидетельствует известная из результатов исследований Standish Group неутешительная статистика по успешности ИТ-проектов: в 1998 году только 26% проектов завершились в срок, не превысили бюджет и обеспечили реализацию предусмотренных функций.

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

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

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

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

Сопротивление сотрудников предприятия;

Временное увеличение нагрузки на сотрудников во время внедрения системы;

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

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

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

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

Нарушение принципа построения системы "сверху-вниз" и, как следствие, отсутствие информационной поддержки принятия управленческих решений на верхних уровнях управления;

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

Кардинальная переработка базовой функциональности ERP-системы;

Нереалистичные ожидания вследствие неверной оценки экономической эффективности внедрения ERP-системы.

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

Факторы успеха проекта внедрения

Тетодологии внедрения обычно разрабатываются ведущими производителями информационных систем с учетом особенностей их программных продуктов, а также сферы внедрения. Положительная сторона таких стандартов - их практическая направленность. Они представляют собой глубоко проработанные, проверенные, многократно апробированные рабочие инструкции и шаблоны проектных документов. Такие стандарты обычно далеки от теоретических абстракций, ориентированы на особенности конкретных систем, содержат наилучший опыт. Но у стандартов есть и отрицательные стороны: даже методологии, предназначенные для систем, близких по классу, не взаимозаменяемы. Например, методология внедрения системы Microsoft Axapta направлена во многом на управление настройками модулей и доработками; а при внедрении функционально подобных модулей SAP или ORACLE EBS превалирует идеология бизнес-реинжиниринга, при котором организации предлагается изменять свои бизнес-процессы, адаптируя их под "лучший опыт", зафиксированный в системе. В качестве наиболее известных примеров методологий можно привести следующий, далеко не исчерпывающий перечень:

Разработки компании Microsoft - методологии "OnTarget", "MSF (Microsoft Solutions Framework)", "Business Solutions Partner Methodology";

Разработки компании SAP - методологии "Процедурная модель SAP", "ASAP (Accelerated SAP)";

Разработки компании Oracle - комплекс методологий "Oracle Method".

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

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

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

Максимально эффективное использование ресурсов проекта;

Минимизация сроков и затрат на внедрение;

Уменьшение рисков проекта.

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

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

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

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

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

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

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

Данные проектной документации не устаревают;

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

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

Оптимизируются бюджет проекта и график платежей.

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

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

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

Составляющие методологии внедрения

Основные этапы внедрения информационной системы

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

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

2. Построение информационно_функциональной модели деятельности предприятия (IDEF), описание и оптимизация процессов, подвергающихся автоматизации.

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

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

3. Выполнение пилотного проекта.

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

4. Адаптация системы на предприятии.

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

5. Опытная эксплуатация ERP_системы.

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

6. Ввод системы в промышленную эксплуатацию.

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

7. Сопровождение промышленной эксплуатации.

Жизненный цикл информационных систем

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

Основные фазы проектирования информационной системы

Каждый проект, независимо от сложности и объема работ, необходимых для его выполнения, проходит в своем развитии определенные состояния: от состояния, когда «проекта еще нет», до состояния, когда «проекта уже нет». Совокупность ступеней развития от возникновения идеи до полного завершения проекта приня­то разделять на фазы (стадии, этапы}.

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

Можно выделить следующие фазы развития информационной системы:

формирование концепции. Главным содержанием работ на этой фазе является определение проекта, разра­ботка его концепции, включающая:

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

формирование ключевой команды проекта;

изучение мотивации и требований заказчика и других участников;

сбор исходных данных и анализ существующего состояния;

определение основных требований и ограничений, требуемых материальных, финансовых и трудовых ресурсов;

сравнительную оценку альтернатив;

представление предложений, их экспертизу и утверждение;

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

• разработка основного содержания проекта, базовой структуры проекта;

  разработка и утверждение технического задания;

  планирование, декомпозиция базовой структурной модели проекта:

  составление сметы и бюджета проекта, определение потребности в ресурсах;

  разработка календарных планов и укрупненных графиков работ;

  подписание контракта с заказчиком;

  ввод в действие средств коммуникации участников проекта и контроля за хо­дом работ;

проектирование. На этой фазе определяются подсистемы, их взаимосвязи, выбираются наиболее эффективные способы выполнения проекта и использования ресурсов. Характер­ные работы этой фазы:

выполнение базовых проектных работ;

разработка частных технических заданий;

выполнение концептуального проектирования;

составление технических спецификаций и инструкций;

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

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

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

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

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

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

схема взаимодействия программ показывает путь активации программ и взаимодействий с соответствующими данными;

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

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

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

выполнение подготовки к внедрению системы;

контроль и регулирование основных показателей проекта.

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

комплексные испытания;

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

подготовка рабочей документации, сдача системы заказчику и ввод ее в экс­плуатацию;

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

оценка результатов проекта и подготовка итоговых документов;

разрешение конфликтных ситуаций и закрытие работ по проекту;

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

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

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

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

ошибки в определении интересов заказчика;

концентрация на маловажных, сторонних интересах;

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

неправильное или недостаточное понимание деталей;

неполнота функциональных спецификаций (системных требований);

ошибки в определении требуемых ресурсов и сроков;

редкая проверка на согласованность этапов и отсутствие контроля со стороны заказчика (нет привлечения заказчика).

9.4. Методология и технология разработки информационных систем

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

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

обеспечение создания информационных систем, отвечающих целям и задачам предприятия и соответствующих предъявляемым к ним требованиям по авто­матизации деловых процессов;

гарантия создания системы с заданными параметрами в течение заданного вре­мени в рамках оговоренного заранее бюджета;

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

обеспечение создания корпоративных информационных систем, отвечающих требованиям открытости, переносимости и масштабируемости;

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

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

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

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

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

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

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

данными, полученными на предыдущей операции (или исходными данными), представленными в стандартном виде;

методическими материалами, инструкциями, нормативами и стандартами;

программными и техническими средствами;

исполнителями.

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

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

поддерживать полный жизненный цикл информационной системы;

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

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

технология должна обеспечивать возможность ведения работ по проектирова­нию отдельных подсистем небольшими группами (3-7 человек). Это обуслов­лено принципами управляемости коллектива и повышения производительно­сти за счет минимизации числа внешних связей;

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

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

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

9.4.1. CASE-технологии

CASE (Computer-Aided Software/System Engineering) как новое направление в программировании сформировалось за последние 10-15 лет.

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

CASE-технология представляет собой совокупность методологического анализа, проектирования, разработки и сопровождения сложных систем программного обеспечения, поддержанную комплексом программных средств автоматизации. Это инструментарий для системных аналитиков, разработчиков и программистов, который позволяет автоматизировать процесс проектирования и разработки ПО. В настоящее время практически ни один серьезный зарубежный программный продукт не осуществляется без использования CASE-средств. Известная методология структурного системного анализа SADT (точнее ее подмножество IDEFO) принята в качестве стандарта на разработку ПО Министерством обороны США.

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

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

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

Эта технология изменяет все стадии разработки ИС, более всего отражаясь на этапах анализа и проектирования

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

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

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

CASE-технологии успешно применяются для построения практически всех типов ПО, как системного и управляющего, так и прикладного. Ключевым признаком CASE-средства является поддержка методологий структурного системного анализа и проектирования.

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

Помимо автоматизации структурных методологий CASE обладают следующими основными достоинствами:

улучшение качества создаваемого ПО за счет средств автоматического контроля;

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

ускорение процесса проектирования и разработки;

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

поддержка развития и сопровождения разработки.

В настоящее время CASE-технологии - одно из наиболее динамично развивающихся отраслей информатики, объединяющие сотни компаний. Из имеющихся на рынке CASE-технологий можно выделить: Application Development Workbench (ADW) фирмы Knowlegge Ware, BPwin (Logic Works), CDEZ Tods (Oracle), Clear Case (Alria Softwere), Composer (Texas Instrument), Discover Development Information System (Software Emancipation Technology).

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

Средства CASE-технологий делятся на две группы:

встроенные в систему реализации - все решения по проектированию и реализации привязаны к выбранной системе управления базами данных (СУБД);

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

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

диаграммы потоков данных (DFD - data dfow diagrams) совместно со словарями данных и спецификациями процессов;

диаграммы «сущность-связь» (ERD - entity relationship diagrams), являющиеся инфологической моделью предметной области;

диаграммы переходов состояний (STD - state transition diagrams), учитывающие события и реакцию на них системы обработки данных.

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

автоматическую генерацию кодов программ на основании их спецификаций;

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

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

тестирование и отладку программ.

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

Большинство специалистов считают, что хорошее инструментальное средство CASE должно обладать следующими качествами:

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

простота использования в сочетании с мощными функциями;

поддержка коллективной работы;

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

возможность "нелинейной" разработки программ;

ввод программного кода в диаграмму с последующим ее обновлением;

наличие функции контроля версий;

распечатка больших диаграмм на стандартных страницах;

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

наличие анимации, с помощью которой можно наглядно моделировать поведение системы;

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

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

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

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

при наличии неоднородной вычислительной среды поддержка нескольких платформ;

возможность включения в модель элементов проверки и фильтрации данных;

поддержка сложных моделей, в частности моделей финансовых потоков, деловой и производственной активности;

приемлемая цена.

Классификация CASE-средств по типам отражает их функциональную ориентацию в технологическом процессе.

Анализ и проектирование, создание спецификаций системы поддерживают следующие системы: CASE. Аналитик; Excelerator (Index Technology); Design-Aid (Nastec); Analist/Designer (Yourdon); Design/IDEF (Meta Software); SELECT (Select Software Tools); System Architech (Software&Systems) и др. На выходе продуцируются спецификации компонентов системы и интерфейсов, связывающих эти компоненты, а также предварительная архитектура системы; детальная проработка проекта, включающая алгоритмы и определение структур данных.

Проектирование баз данных и файлов предполагает использование следующих CASE-средств: ERWin (Logic Works); S- Designer (SDR), Designer/2000 (Oracle), Silverrun (Computer, Systems Advisers и др. Средства данной группы обеспечивают логическое моделирование данных, автоматическое преобразование моделей данных в 3НФ, автоматическую генерацию схем БД и описание форматов файлов на уровне программного кода.

Программирование. Средства этой группы поддерживают этапы программирования и тестирования, а также автоматическую кодогенерацию из спецификаций, получая полную документированную выполняемую программу: СOBOL 2/Workbench (MicroFocus); DECASE (DEC); NETRON/CAP (Netron), APS (Sage Software). Помимо диаграммеров различного назначения и средств поддержки работы с репозитарием, в эту группу средств включены и традиционные генераторы кодов, анализаторы кодов (как в статике, так и динамике), генераторы наборов тестов, анализаторы покрытия тестами, отладчики.

Сопровождение и реинжинеринг. К таким средствам относятся документаторы, анализаторы программ, средства реконструирования и реинжениринга: Adpac CASE Tools (Adpac), Scan/COBOL & Super Structure (Computer Data Systems), Inspector/Recoder (Language Technology). Их целью является корректировка, изменение, анализ, приобретение и реинжениринг существующей системы.

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

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

динамические анализаторы (обычно компиляторы и интерпретаторы с встроенными отладочными возможностями);

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

редакторы кодов, автоматически изменяющие при редактировании и все предшествующие коду структуры (например, спецификации);

средства доступа к спецификациям, их модификации и генерации нового (модифицированного кода);

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

Окружение. Средства поддержки платформ для интеграции, создания и придания товарного вида CASE-средствам Multi/Cam (AGS Management Systems), Sylva Foundry (Cagware).

Управление проектом – средства, поддерживающие планирование, контроль, руководство, взаимодействие, т.е. функции, необходимые в процессе разработки и сопровождения проектов: Project Workbench (Applied Business Technology).

CASE-средства классифицируются также по категориям . Такая классификация определяет уровень интегрированности по выполняемым функциям и включает:

вспомогательные программы (tools) - решают небольшую автономную задачу, принадлежащую проблеме более широкого масштаба;

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

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