Сценарий внедрения программного продукта это

С этим файлом связано 18 файл(ов). Среди них: Виды и фукции ОС.docx, Документ Microsoft Word (6).docx, Системные платы.docx, СТРАТЕГИЯ 2035 с измен.от 24.12.20.docx, Таблицы истинности.docx, пр1.docx, Лекция 4.pptx, РП_Математические методы.doc, Сам_работа_тема_1-3.docx, Каталог паттернов проектирования.docx, Лекция ГОСТ Р ИСО_МЭК 12207. Основные процессы и взаимосвязь меж, Виды и план внедрения.docx, Лекция.doc, Лекция 1.docx, Дестабилизирующие факторы.docx, Савостьянов.docx, 1.docx, 208 Татаринский-Ерофеев, крутые пацаны МЧС-ники.docx и ещё 8 файл(а).
Показать все связанные файлы

Подборка по базе: Щелкина И.А. Корпоративные информационные системы (терминология,, Разработайте наиболее приоритетные цели и обоснуйте концептуальн, 1. Цели и задачи дисциплины Экология. Экологические факторы.docx, Опыт внедрения наставничества.pptx, Приорнтетные цели и основные механизмы воздействия органов госуд, 5. Формирование политики и стратегические цели предприятия (1).d, 8-наурыз концерт сценарии.docx, Урок №, тема урока Возможности редактора VideoPad Цели обучения , Урок №, тема урока Возможности редактора VideoPad Цели обучения , Тема 1. Лекция1.1 Цели обучения биологии.docx

Тема занятия: «Стратегии, цели и сценарии внедрения»

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

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

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

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

Внедрение — самый ответственный момент проекта замены информационной системы.

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

Планирование важно всегда! Но на этапе внедрения оно имеет повышенное значение.

Есть 3 способа начала использования новой системы:

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

Свойство этой стратегии — сосредоточение на узком месте в производственном процессе — упрощает внедрение.

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

При крупных внедрениях выделяют 3 уровня организации проекта внедрения:
— управляющая команда (руководство),
— рабочая команда (предметные специалисты),
— внедренцы (исполнители).

Сценарии внедрения — это сводка задач внедрения продукта.

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

• Сценарий 1: Внедрение с автоматическим конфигурированием промежуточного ПО
• Сценарий 2: Автоматическое внедрение с использованием существующего промежуточного ПО
• Сценарий 3: Внедрение вручную с использованием существующего промежуточного ПО
• Сценарий 4: Автоматическое внедрение в кластеризованной среде.

В сценариях 2 и 3 существующее установленное промежуточное ПО переиспользуется в качестве компонентов Maximo Asset Management. Например, у вас может быть существующий экземпляр базы данных.  Этот экземпляр может располагаться на существующем сервере баз данных. Установленные политики доступа, принятые меры по избыточности и планы резервного копирования могут влиять на порядок внедрения программного обеспечения в вашей организации.

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

Сценарий 1: Внедрение с автоматическим конфигурированием промежуточного ПО

При таком сценарии выполняется внедрение продукта в новой среде. Используются программы установки Maximo Asset Management и инструменты для установки и автоматического конфигурирования новой установки промежуточного ПО и продукта.

Oracle WebLogic Server нужно по-прежнему конфигурировать вручную.

Например, можно использовать программу установки Maximo Asset Management для установки Db2 и использовать программу конфигурирования Maximo Asset Management для автоматического конфигурирования.

Такой сценарий подходит для настройки демонстрационной среды.

Сценарий 2: Автоматическое внедрение с использованием существующего промежуточного ПО

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

Oracle WebLogic Server необходимо конфигурировать вручную, но можно использовать программу установки Maximo Asset Management для автоматического конфигурирования, например, существующей базы данных.

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

Сценарий 3: Внедрение вручную с использованием существующего промежуточного ПО

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

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

Сценарий 4: Автоматическое внедрение в кластеризованной среде

В этом сценарии вы внедряете Maximo Asset Management в конфигурированной вами кластеризованной среде. Используются программы установки продукта и инструменты для автоматического конфигурирования промежуточного ПО.

Этот сценарий предназначен для знающих администраторов серверов прикладных программ, имеющих опыт по планированию и созданию кластерных сред в IBM® WebSphere Application Server.

Труд — это отец удовольствия.

Стендаль.

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

Внедрение программного продукта с точки зрения бизнес-консультанта.

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

Еще раз: главное – решить поставленную бизнес-задачу!

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

Вы внедряете такое программное обеспечение, которое будет:

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

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

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

Например:

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

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

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

1. Получили перечень задач, которые нужно реализовать.
2. Доработали программный продукт с учетом пожеланий клиента.
3. Установили везде программу, настроили.
4. Провели краткое обучение.
5. Оставили инструкцию, написанную техническим языком и понятную, чаще всего, только системному администратору.

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

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

Почему так происходит?

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

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

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

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

Что такое внедрение?

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

(Википедия)

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

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

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

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

Ошибки при внедрении.

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

Избегайте спешки. Даже если клиент пытается давить и торопить. Никогда не берите на себя жесткие обязательства по срокам в начале по проекту в целом. Очень часто в процессе внедрения выявляется потребность в каких-то дополнительных действиях и доработках в программе. Кроме того, аппетит приходит во время еды, и достаточно часто в процессе работы сам клиент начинает ставить дополнительные задачи. Если вы будете ограничены строгими временными рамками, это может привести к спешке. А в результате – к большому числу ошибок и недоработок.

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

Для того чтобы избежать перечисленных ошибок, вам обязательно нужно донести до клиента простую мысль:
Здесь и сейчас вы выполняете уникальную работу, в уникальном окружении с уникальным результатом. А потому точно спрогнозировать все нюансы – просто невозможно!

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

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

В зависимости от сложности и объема предстоящей работы я чаще всего называю какие-то примерные сроки. Это могут быть 2 – 4 месяца или от полугода до 1,5 лет. Да, я не знаю точных сроков реализации проекта, как и не могу заранее точно сказать, как именно будет выглядеть результат моей работы. Но я точно знаю самое главное – это основную цель, а также, как именно реализовать каждый этап работы.
Т.е. я использую тот самый принцип, о котором уже упоминал в связи с японской стрельбой из лука Юми: сосредоточьтесь на каждом действии, на каждом этапе, качественно выполняйте каждое действие. И тогда вы обязательно придете к цели!
С чего начинается внедрение?

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

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

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

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

Приведу пример. Когда-то я и сам слишком углублялся в технические нюансы и пытался пояснять чем, скажем, MailChimp отличается от 1С рассылки. Я рассказывал об API, о статистике, о числе отказов, а также о других технических параметрах. При этом клиенту, на самом деле, нужны были совсем другие данные. Ему было достаточно продемонстрировать пример письма и показать пример статистики, чтобы мы поняли друг друга и клиент понял выгоду для себя.

Говорите с клиентом с его точки зрения и на его языке!

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

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

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

О моем подходе к процессу внедрения я напишу в следующей статье.

1. Практические рекомендации по взаимодействию разработчика и заказчика при создании программного обеспечения

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

1) взаимоотношения
заказчика и разработчика строятся на
взаимном доверии, просчеты в оценке
проекта берет на себя в основном
разработчик — мягкое
внедрение;

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

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

Постановочный
этап

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

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

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

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

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

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

Условием завершения
этапа является подписание сторонами
технического задания.

Уточняющий
этап

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

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

На данном этапе
«Руководство пользователя» фактически
заменяет классическое ТЗ. Такой подход
имеет ряд преимуществ:

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

2) отсутствие
необходимости в одновременной правке
технического задания и «Руководства
пользователя»;

3) достижение
соответствия создаваемой документации
текущему состоянию будущего проекта.

Условием завершения
этапа является подписание письменного
соглашения заказчика и разработчика о
принятии системы при наличии ее
соответствия последней согласованной
версии «Руководства пользователя»,
стабильности архитектуры и требований
к системе (допустимые изменения в ходе
следующего этапа составляют не более
20 %).

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

Стабилизирующий
этап

На данном этапе
устраняются недостатки в прототипах и
документации и выпускается «Релиз
системы». Стоимость этапа составляет
примерно 50 % от общей стоимости разработки.

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

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

Внедрение

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

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

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

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

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

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

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

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Практическая работа №2

«Разработка сценария внедрения программного продукта для рабочего места»

ЦЕЛЬ РАБОТЫ: изучить основы разработки, сценарии внедрения программного продукта для рабочего места.

ОБОРУДОВАНИЕ: ПК, MS Excel, Браузер Opera.

ВРЕМЯ ВЫПОЛНЕНИЯ: 90 минут

КРАТКАЯ ТЕОРИЯ И МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ:

Бизнес-цель — это описание фактора, побуждающего к выполнению проекта. Ее формирование производится на стратегическом уровне, то есть бизнес-цель выступает в качестве связующего звена между глобальными задачами, стоящими перед организациями, и планируемым к реализации проектом. При отходе от стратегического видения происходит смещение бизнес-цели в сторону тактических и даже операционных задач, на уровне которых целью проекта видится «просто выдать продукт», а не достичь какой-либотактической цели, поддерживающей стратегические цели организации. Этого нельзя допускать: бизнес-цель проекта должна всегда носить тактический или стратегический характер, но в то же время быть предельно точной и ясной (очень редко удается применить широко известный метод SMART к построению бизнес-цели проекта.Так, например, бизнес-целью проекта по приобретению и установке нового производственного оборудования является не покупка и установка оборудования, а устранение узкого места в производственном процессе и обеспечение надлежащих объемов выпуска, гарантирующих удовлетворение спроса и завоевание определенной доли рынка. Аналогично, проект внедрения информационной системы имеет своей бизнес-целью не разворачивание технических средств, а создание информационно-технологического фундамента для поддержки принятия руководством компании своевременных управленческих решений, направленных на обеспечение ее развития и роста.

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

• функцию постановки задачи;

• функцию согласования;

• авторизационную функцию;

• функцию повышения дисциплины;

• консолидационную функцию;

• интеграционную функцию.

Разработка устава проекта начинается после издания приказа о запуске.

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

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

2. Цели, задачи и результаты.

3. Имя и фамилию PM, границы его ответственности и полномочия.

4. Определение и структуру продукта.

5. Интересы и ожидания участников.

6. Критерии успеха.

7. Принципы организации и управления проектом

ТЕХНИЧЕСКОЕ ЗАДАНИЕ ИС ПРИМЕР:

В качестве предметной области выбрана тема «Отдел кадров. Учет персонала».

1. Этап разработки раздела «Общие сведения»:

• Полное наименование ИС: «Отдел кадров. Учет персонала».

• Шифр темы: 00001.

• Предприятие-разработчик системы: Лаборатория баз данных “БД”, ул. 50 лет Октября,

86, тел.

• Предприятие-заказчик системы: ООО «ЛюксАвто».

• Система создается на основании технического задания (ТЗ). ТЗ на АС является основным документом, определяющим требования и порядок создания автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие. Кроме того, при создании системы используются ГОСТ 34.602-89 “Техническое задание на создание автоматизированной системы”.

• Плановый срок начала работ: 01.04.2010.

• Плановый срок окончания работ: 31.05.2010.

• Автоматизируемая система создается на коммерческой основе.

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

2. Этап разработки раздела «Назначение и цели создания системы»:

• Вид автоматизируемой деятельности: учет персонала в отделе кадров.

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

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

3. Этап разработки раздела «Характеристики объекта автоматизации»

Краткие сведения о предприятии.

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

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

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

Организационная структура.

Организационная структура предприятия показана на рисунке 1.

Рис.1. Организационная структура предприятия

Описание автоматизируемых процессов, информационные потоки автоматизируемых процессов.

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

Схема информационных потоков процесса показана на рисунке 2.

Рис.2 Схема информационных потоков процесса “Учет персонала”

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

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

• Сотрудники.

• Адрес.

• Образование.

• Подразделение.

• Приказ о зачислении.

• Штатное расписание.

• Должность.

• Карточка учета.

4. Этап разработки раздела «Требования к ИС»

Требования к системе в целом

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

Ввод в действие ИС должен приводить к полезным технико-экономическим, социальным результатам:

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

• уменьшение времени на формирование отчетов, приказов и справок.

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

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

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

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

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

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

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

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

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

Все отчеты должны оформляться в едином стиле.

Требования к информационному обеспечению ИС

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

• данные о сотрудниках;

• приказы о зачислении;

• штатное расписание;

• личные карточки.

Требования к программному обеспечению ИС

Для функционирования базы данных подходят операционные системы Windows,Vista. Диалоговый режим требует объектно-ориентированную систему программирования -BorlandDelphi , а СУБД – Access.

Требования к техническому обеспечению АС

Минимальные требования к техническому обеспечению АС следующие:

• Pentium IV;

• ОЗУ 512 Мбайт;

• 10 Мбайт дисковой памяти;

• принтер формата А4.

5. Этап разработки раздела «Стадии и этапы разработки»

Стадии разработки

Разработка должна быть проведена в три стадии:

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

• рабочее проектирование;

• внедрение.

6. Этапы разработки

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

На стадии рабочего проектирования должны быть выполнены перечисленные ниже этапы работ:

• разработка модели автоматизируемых процессов и функциональной модели ИС;

• разработки логической и физической моделей данных;

• разработка программы;

• разработка программной документации;

• испытания программы.

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

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

Задание 1

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

ВАРИАНТЫ ЗАДАНИЙ:

1. Прокат автомобилей

2. Библиотечный фонд города

3. Спортивный клуб

4. Управление складом

5. Автошкола

6. Автомастерская

7. Компания по продаже мед.техники

8. Страховая компания

9. Гостиница

10. Оптовая база

11. Завод по производству металлоизделий

12. Ювелирная мастерская

13. Предприятие по организации свадебных торжеств

14. Бюро по трудоустройству

15. Нотариальная контора

16. Производство мебели

17. Поликлиника

18. Магазин розничной торговли

19. Спортивный клуб

20. Магазин по ремонту и продаже компьютеров и комплектующих

21. Строительная организация

22. Компьютерный клуб

23. Строительная организация

24. Фотоцентр

25. Городской зоопарк.

Поделитесь с Вашими друзьями:

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

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

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

Процесс поэтапного внедрения программного обеспечения

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

Этап 1. Обследование компании

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

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

Качественно составленное ТЗ гарантирует точность выполнения работ.
 

Этап 2. Составление контракта на производство работ

Контракт на производство работ составляется по совместному заключению заказчика и компании после выполнения анализа ТЗ.

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

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

Этап 3. Создание группы по внедрению ПО

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

Этап 4. Инсталляция и наладка ПО

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

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

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

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

Завершение внедрения ПО включает выполнение следующих работ:

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

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

В данной статье, как и обещал ранее, хочу описать конкретные подходы, которые мне доводилось использовать при внедрении программных продуктов (далее по тексту — ПП).

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

Чтобы снизить сопротивление пользователей, нужно понять причины их нежелания работать в новой программе. Я вижу две группы причин: страхи и непонимание важности работы в программе. Чаще всего страхи связаны с:

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

Кроме страхов, есть еще один аспект, который не позволяет сотрудникам стать адептами нового программного  продукта – это их искреннее непонимание важности:

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

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

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

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

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

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

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

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

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

• Обучение пользователей работе по новым правилам в новой программе
• Примеры из аналогичных проектов, где подобные страхи не оправдались

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

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

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

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

From Wikipedia, the free encyclopedia

Phased adoption is a strategy of implementing an innovation (i.e., information systems, new technologies, processes, etc.) in an organization in a phased way, so that different parts of the organization are implemented in different subsequent time slots. Other concepts that are used are: phased implementation, phased conversion, phased approach, phased strategy, phased introduction and staged conversion.

Overview[edit]

Information Technology has revolutionized the way of working in organizations.^[1] With the introduction of high-tech Enterprise Resource Planning Systems (ERP), Content Management Systems (CMS), Customer and Supplier Relationship Management Systems (CRM and SRM), came the task to implement these systems in the organizations that are about to use it. The following entry will discuss just a small fraction of what has to be done or can be done when implementing such a system in the organization.

The phased approach takes the conversion one step at a time. The implementation requires a thoroughly thought out scenario for starting to use the new system. And at every milestone one has to instruct the employees and other users. The old system is taken over by the new system in predefined steps until it is totally abounded. The actual installation of the new system will be done in several ways, per module or per product and several instances can be carried out. This may be done by introducing some of the functionalities of the system before the rest or by introducing some functionalities to certain users before introducing them to all the users. This gives the users the time to cope with the changes caused by the system.

It is common to organize an implementation team that moves from department to department. By moving, the team learns and so gains expertise and knowledge, so that each subsequent implementation will be a lot faster than the first one.

The Process Data Diagram[edit]

The visualising technique used in this entry is a technique developed by the O&I group of the University of Utrecht.^[2] The technique is described in the following Wiki: Meta-modeling technique.

As can be seen in figure 1, phased adoption has a loop in it. Every department that is to be connected to the system is going through the same process. First based on the previous training sessions security levels are set (see ITIL) In this way every unique user has its own profile which describes, which parts of the system are visible and/or usable to that specific user. Then the document and policies are documented. All processes and procedures are described in process descriptions, can be in paper or on the intranet. Then the actual conversion is depicted. As described in the above text, certain departments and or parts of an organization may be implemented in different time slots. In figure 1 that is depicted by implementing an additional module or even a total product. HRM needs different modules of an ERP system than Finance (module) or Finance may need an additional accounting software package (Product). Tuning of the system occurs to solve existing problems. After the certain department has been conversed the loop starts over, and another department or user group may be conversed. If all of the departments or organization parts are conversed and the system is totally implemented the system is officially delivered to the organization and the implementation team may be dissolved.

Phased adoption makes it possible to introduce modules that are ready whilst programming the other future modules. This does make the implementation scenario more critical, since certain modules depend on one another. Project Management techniques can be adopted to tackle these problems. See the techniques section below.

However, the actual adoption of the system by the users can be more problematic. The system may work just fine but if it is not used it’s worthless. Users base their attitude towards the system on their first experience.^[1] As this creates an extra weight on the first interaction, the implementers should be concerned with making the first interaction especially a pleasant one.

In the technique used in this entry each CONCEPT requires a proper definition which is preferably copied from a standard glossary of which the source is given, if applicable. All CONCEPT names in the text are with capital characters. In Table 1 the concept definition list is presented.

Table 1: Concept Diagram

Advantages, disadvantages and risks of Phased Adoption[edit]

The Phased adoption method has certain pros, cons and risks^[5][1]

Pros:

• The conversion will be done in parts. Time is available for adjustments
• Negative influences that arise at the start are less critical
• No ‘catch-up’ period is needed.
• Time for the users to adapt is longer
• Technical staff can concentrate on part of the system or some of the users.

Cons:

• Several adjustments are needed
• Training sessions are confusing for users as they are asked to work with the new and the old system
• Several changes in documentation
• The duration of the project
• System delivery milestone is unclear
• Correctness and completeness of the dataset has to be checked several times
• A ‘fall back’ to the old system is becoming more difficult every new phase.
• The implementation may appear unclear to the employees and other users.

Risks:

• Complexity of the implementation
• Prone to make mistakes
• Fall back impossible in later phases

Hardware and software installation[edit]

The following sections are supplemental to the entry about adoption (software implementation) and are specific to phased adoption:

The configuration and specification of the hardware in place used by the legacy system and to run the new system is delivered in the hardware specifications. The hardware configuration is tested to assure proper functioning. This is reported in the hardware configuration report.
The configuration and specification of the software in place, i.e., the legacy system and the future new system is made clear to assure proper functioning once the system is installed. The act of specifying the system already installed is key to the implementation. Which parts or even total systems will be taken over by the new system? All this is reported in the software installation and software test reports.
The actual installation of the software of the new system is also done here in a confined area to support the training sessions described in the following section.

Training[edit]

The system training will teach users the keystrokes and transactions required to run the system.^[3] The pilot exercises the systems and tests the users understanding of the system. The project team creates a skeletal business case test environment which takes the business processes from the beginning, when a customer order is received, to the end, when the customer order is shipped.
Training as such is not enough for adopting an information system. The users have learning needs.^[1] Known learning needs are the emotional guidance. Users need to make emotional steps in order to make cognitive
steps. If they fear the system due to its difficult handling they may not be able to understand the cognitive steps needed to successfully carry out the tasks.

Techniques[edit]

In the implementation field several techniques are used. A well-known method, and specifically oriented on the implementation field, is the Regatta method by Sogeti. Other techniques are the SAP Implementation method, which is adapted to implementing SAP systems. Systems are installed in several different ways. Different organizations may have their own methods, When implementing a system, it is considered a project and thus must be handled as such. Well known theories and methods are used in the field such as the PRINCE2 method with all of its underlying techniques, such as a PERT diagram, Gantt chart and critical path methods.

Example[edit]

The EMR implementation at the University Physicians Group (UPG) in Staten Island and Brooklyn, New York.

The University Physicians Group in New York went with a complete technical installation of an EMR (Electronic Medical Record) software package. The UPG found that some vendors of the EMR package recommended a rolling out that would be done all-at-one, also called the Big Bang. But they found out that the Big Bang would have overwhelmed the physicians and staff due to the following factors:

• Ongoing workload during the key lessons prevented them to fully pay attention.
• Urgent need to complete some records caused the users to fall back to the old system
• Information overload on the physicians side.
• No time to play around with the system.
• 100% availability was not assured by the vendor.

Thus they chose a phased approach: “Hence, a phased adoption to us, offered the greatest chance of success, staff adoption, and opportunity for the expected return-on-investment once the system was completely adopted.” (J. Hyman, M.D.)

There also was a group who were somewhat reluctant about any new systems. By introducing the system to certain early adopters the late majority would be able to get to know the system.^[6] As it was introduced phased through the organisation. Per loop (see figure 5, A) the UPG was introduced to the system.

See also[edit]

• PRINCE2
• Regatta method by Sogeti
• Parallel adoption
• ERP
• SRM
• CRM
• Software package

References[edit]

Further reading[edit]

• Gallivan, M.J., (1996) Stragies for implementing new software processes: An evaluation of a contingency framework, SIGCPR/SIGMIS ’96, Denver Colorado
• Rooimans, R., Theye, M. de, & Koop, R. (2003). Regatta: ICT-implementaties als uitdaging voor een vier-met-stuurman. The Hague: Ten Hagen en Stam Uitgevers.