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

Анна Пушина 24 сентября 2020

IT-директору

Время чтения: 5 минут

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

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

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

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

Принцип №1. Внедрение информационной системы – это проект

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

К задаче нужно отнестись как к проекту, так предстоящие работы соответствуют трём основным критериям:

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

Для успешного завершения любого проекта необходимо комплексное управление, поэтому во внедрении информационных систем применимы рекомендации международного стандарта PMBOK (Project Management Body Of Knowledge). В нём рассматриваются области знаний об интеграции, содержании, расписании, стоимости, качестве, ресурсах, коммуникациях рисках закупках и заинтересованных сторонах проекта.

Принцип №2. Помнить о критериях успешности проекта

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

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

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

Методология управления проектами в ИТ. Где её взять

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

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

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

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

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

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

С развитием ИТ-технологий появляются новые методологии и новые способы организации проектов. Узнать больше о них помогут другие статьи ECM-Journal:

• Почему 9 из 10 внедрений CRM заканчиваются провалом?
• Электронный документооборот: что нужно знать перед внедрением
• Успешное внедрение СЭД: очевидные принципы и неочевидные подходы
• Как сэкономить на внедрении: фитнес для предприятия

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

внедрение ит-директору bpm электронный документооборот

ВНЕДРЕНИЕ WMS-СИСТЕМЫ: ОСНОВНЫЕ ЭТАПЫ

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

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

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

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

Когда WMS-система нужна вашему складу. Подробная информация ⇒

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

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

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

 

Выделяют следующие этапы при внедрении WMS-системы:

1.  формирование технического задания;
2.  конфигурирование и настройка;
3. передача прототипа WMS-системы, валидация, тесты, обучение персонала;
4. ввод системы в эксплуатацию.

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

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

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

Формирование технического задания:  

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

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

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

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

Конфигурирование и настройка: 

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

•  настройка интерфейса обмена с ERP-системой; 
• конфигурирование и настройка WMS-системы. 

На втором этапе со стороны интегратора привлекаются специалисты группы «Интерфейса» – выделенного подразделения в структуре компании.

Разработчики подразделения «Интерфейса» взаимодействуют с ИТ-специалистами заказчика по подготовке ТЗ на интерфейс обмена, где описываются документы обмена, используемые протоколы. Затем следует настройка интерфейса со стороны WMS-системы. Все работы проходят в соответствии с согласованным ТЗ на территории разработчика. Общее время продолжительности двух этапов составляет 1 – 1,5 месяца. Данные два этапа, как правило, проходят без серьезных сложностей, все требования к интерфейсу обмена определены и прозрачны. На этапе конфигурирования основным риском может быть необходимость доработки нестандартной функциональности. Разработка специфического функционала требует дополнительного времени на настройку и тестирование, что увеличивает продолжительность третьего этапа. 

Передача прототипа, валидация, тесты: 

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

Процесс запуска складывается из нескольких этапов: 

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

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

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

Ввод системы в эксплуатацию: 

Реализация данного этапа возможна только после подготовки ИТ-инфраструктуры: серверов, сетевой инфраструктуры, WI-FI, радиотерминалов и другого оборудования, на которое устанавливается WMS-система.   В рамках данного этапа разрабатывается «Методика внедрения», в которой пошагово описываются процессы запуска системы, ввода справочных данных и внесения товарных остатков, после согласования и утверждения документа интегратор совместно с заказчиком приступают к работе. Линейный персонал заказчика повторно проходит тренинг уже на собственном объекте. 

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

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

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

Внедрение систем

Системы внедрение и оценка

1. Что такое внедрение систем?
2. Что являются инструментами для физических систем дизайн?
3. Какие вопросы необходимо рассмотреть перед тем, как информационная система оперативный?
4. Каковы ключевые показатели системы качества?
5. Каковы методы оценки систем?

 

Системы реализация — это процесс:

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

 

Дизайн системы

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

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

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

 

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

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

1.       Факторинг: разложение

2.      Диапазон управления: 9 подчиненных модулей

3.      Разумно размер: 50-100 LOC

4.      Соединение: минимизация межмодульной зависимости

5.      Сплоченность: функциональность одного модуля

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

 

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

Организация программ и программных модулей (структурная схема)

Спецификация логики обработки в каждом модуле (псевдокод)

 

Структурная схема с по показать графически

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

 

Символы

Компоненты	Символ
Модуль	Прямоугольник
Пара данных	Чистый круг без стрелки
Флаг управления	Закрашенный круг без стрелки
Условная обработка/выбор	Алмаз
Повторение	Изогнутая линия, пересекающая соединение с модулями
Предопределенный модуль	Прямоугольник с вертикальной чертой на каждой стороне

 

Преобразование DFD в структурные диаграммы

1.       Найти центральный центр преобразования/транзакций

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

3.      Определить первичные входные и выходные потоки данных

4.      Ничья диаграмма верхнего уровня (состоит из двух иерархических уровней)

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

 

Заказ головных уборов и халатов пример системы

Шаг	Пример
Центр	Процесс № 3: проверка заказа
Корневой модуль	Технологический заказ
Первичные входы	Студенческий билет, размер кепки, размер халата
Первичные выходы	Квитанция, детали заказа, обновление запасов
Высший уровень	Получить учащегося, Получить заказ, Обработать неверный заказ, Обработать действительный заказ
Уточнение	Получить студента, Получить заказ, Обработать действительный заказ

 

Псевдокод

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

 

Заказ шапочки и халата пример системы

МОДУЛЬ: Process_Order()

Установить EOF = нет, ДЕЙСТВИТЕЛЬНО = 0

GET_STUDENT

DO В то время как EOF = NO

IF VALICE = 0

GET_ORDER

ENDIF

IF VALIC

 

МОДУЛЬ: Get_Student()

SET EOF = no, VALID = 0, TYPE=»student»

READ student_ID

IF student_ID = null

Тогда EOF = YES

else verify_data (type)

Endif

return Student_id, EOF, действительный

Модуль: GET_ORDE ()

SET TIP cap_size, gown_size

verify_data (type)

return cap_size, gown_size, допустимый

Модуль: Process_invalid_Order (Valid)

, если верно = 1

. 0005

ИНАЧЕ, ЕСЛИ ДЕЙСТВИТЕЛЬНО = 2

ошибка = «Студент не заканчивает школу весной»

ИНАЧЕ, ЕСЛИ ДЕЙСТВИТЕЛЬНО = 3

ошибка = «Размер крышки отсутствует на складе»

ELSE IF VALID = 4

error = «Размер платья отсутствует на складе»

ENDIF

ENDIF

ENDIF

ENDIF

Ошибка отображения

Модуль: verify_data (тип)

IF Type = «Студент»

Тогда Open Student_file

0002 НАЙТИ Запись о студенте, ИСПОЛЬЗУЯ ID студента

ЕСЛИ Запись о студенте НЕ НАЙДЕНА

ТО ДЕЙСТВИТЕЛЬНО = 1

ELSE IF Студент.выпускник_дата <> «Весна 1999»

ТОГДА ДЕЙСТВИТЕЛЬНО = 2

ENDIF

ENDIF

ELSE IF TYPE = «order»

THEN OPEN Inventory_File

ПОЛУЧИТЬ Inventory.cap_on_hand USING cap_size

ПОЛУЧИТЬ Inventory.gown_cap_on_hand ИСПОЛЬЗОВАНИЕ cap_size

GET Inventory.gown_cap_on_hand ИСПОЛЬЗОВАНИЕ inventory.gown2 IF_hand_size

005 = 0

ТОГДА ДЕЙСТВИТЕЛЬНО = 3

ИНАЧЕ, ЕСЛИ Inventory. gown_on_hand = 0

ТО ДЕЙСТВИТЕЛЬНО = 4

КОНЕЦ

ENDIF

ENDIF

ENDIF

RETURN VALID

 

МОДУЛЬ: Process_Valid_Order(student_ID, cap_size, gown_size)

Update_Inventory(cap_size, gown_size)

Generate_Receipt(student_ID, cap_size, gown_size)

Record_order(student_ID, cap_size, платье_размер)

 

МОДУЛЬ: Update_Inventory(cap_size, gown_size)

OPEN Inventory_file

GET Inventory.cap_on_hand Используя CAP_SIZE

Уменьшите инвентаризацию. CAP_ON_HAND через 1

Найти Inventory.gown_on_Hand с использованием gown_size

Уменьшите инвентаризацию. Gown_on_hand 1

Module_file

MODULE: record_rord_id_id_id_id_id_id_id_id_id_dize_id_id_id_id_id_id_id_id_id_id_id_id_id_id_id_id_id_id_id_id_id_id_id_dize_id_id_id_id_id_id_id_id_id_dize. gown_size)

OPEN Order_File

Order.student_ID = student_ID

Order. cap_size = cap_size

Order.gown_size = gown_size

WRITE Order_Record

PRINT Order_Record AS Receipt_Report

CLOSE Order_File

2 9 Реализация вопросы

1.      Тестирование

2.      Преобразование

3.      Документация

4.      Обучение

 

5

5 виды испытаний

Тест	Описание	Характеристика
Осмотр	Вручную проверить код на наличие ошибок	Обнаружение от 60 до 90 процентов дефектов
Прохождение (рис. 20.1)	Вручную просмотрите код, чтобы найти ошибки, проверив, что код делает	Должен выполняться при небольших объемах работ
Настольная проверка	Вручную работать с кодом, выполняя каждую инструкцию с использованием тестовых случаев	Рецензент действует как компьютер
Проверка синтаксиса	Обнаружение синтаксических ошибок компилятором	Единственный метод автоматизированного тестирования, который является статическим
Тестирование блока/модуля	Обнаружение любой ошибки, которая может существовать в коде модуля	Каждый модуль тестируется отдельно
Интеграционное тестирование	Обнаружение любой ошибки, которая может существовать при объединении модулей	Постепенное тестирование сверху вниз
Тестирование системы	Обнаружение любой ошибки, которая может существовать при интеграции программ в системы	Постепенное тестирование сверху вниз

 

Процесс тестирования (рис. 20.27)

1. Программа тестирование с тестовыми данными
2. Ссылка тестирование с тестовыми данными
3. Полный тестирование систем с тестовыми данными (альфа-тест)
4. Полный тестирование систем на живых данных (бета-тест)

 

Руководство по тестированию

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

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

Протестируйте наиболее часто используемые части система минимум

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

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

 

Преобразование стратегии (рис. 21.12)

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

 

Типы документации

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

Записывает подробную информацию о конструкции системы спецификации, функциональность (внешняя) и внутренняя работа (внутренняя), например, DFD, ERD, Структурированный английский, структурная схема, псевдокод.

 

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

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

 

Документация стандарт

1. Совместимость
2. Понятно
3. Информативный
4. Адекватный
5. Структурированный
6. Ремонтопригодный

 

Обучение рекомендации (рис. 21.11)

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

 

Темы обучения

1.      Использование системы

2.      Компьютер понятия

3.       ИС концепции

4.      Организационная концепции

5.      Система управление

6.      Система установка

 

Методы обучения

1.      Локальный эксперты: 51%

2.      Компьютеризированный инструкция: 17%

3.      Онлайн помощь: 10%

4.      Курс: 10%

5.      Учебник: 7%

6.      Внешний источники: 5%

 

Почему реализация не удалась

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

2.      Фактор модель: 4 фактора Гинзберга, 6 факторов Лукаса

 

Модель Гинзберга 4 фактора модели

1.      Проект приверженность: насколько хорошо понял?

2.      Изменить обязательство: насколько готовы измениться?

3.      Объем планирования и определения проекта: насколько хорошо спланировано?

4.      Пользователь ожидания: насколько реалистичны?

 

Модель изменений Левина/Шейна

1.       Размораживание

Ощущение потребности

Создайте безопасную атмосферу

2.      Переезд

Предоставьте необходимую информацию

Усваивать знания и развивать навыки

3.      Повторное замораживание

Интегрировать новое поведение в текущее поведение

Распространение изменений по всей системе

 

5 областей ожидания

Цели: причины разработки системы

Важность: важность решаемой проблемы

Модели использования: способ использования системы

Воздействия: влияние системы на организацию

Критерии оценки

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

Источник: Гинзберг, MJ, «Ранняя диагностика неудач внедрения ИСУ: многообещающие результаты» и вопросы без ответов», Менеджмент Science , vol.27, no.4, April, 1981, pp.459-478

 

6 факторов Лукаса модель

1.       Пользовательский личная ставка: насколько важна?

2.      Система характеристики: насколько прост в использовании?

3.      Пользователь демография: насколько компьютер грамотен?

4.      Организация поддержка: насколько совершено?

5.      Производительность: сколько можно сделать?

6.      Удовлетворение: сколько используется?

 

Ловушки эскалации

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

 

Предотвращение чрезмерное обязательство

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

 

Источник: Staw, B.M., and Росс, Дж. «Знать, когда выдернуть вилку из розетки», стр. 9.0969 Harvard Business Review , март-апрель 1987 г., стр. 68-74 гарантия , чтобы гарантировать, что фактически разработанная система соответствует текущим и прогнозируемые потребности пользователей и организации

Общий подход к управлению качеством для обеспечения качества:

• строить системы правильно с самого начала
• Кому обнаруживать и исправлять ошибки как можно скорее

 

Показатели система качества

1. Структура: нисходящий дизайн; модульный в программировании
2. Задокументировано
3. Испытано
4. Поддерживается, и
5. Проверено

 

Структурированная система = структурный анализ + структурированный дизайн + структурированное программирование

Структурированный анализ: ввод-процесс-вывод

Структурное проектирование: модульное

Структурированное программирование: последовательность-выбор-повторение

 

Основные причины изменений бизнес/стратегическое развитие

Новый технология

Организационная изменения

Оригинал спецификация неадекватна

Правительственные/юридические изменения

Внешний факторы, например, поставщики, клиенты

Новый политики, например, безопасность, финансовые сокращения

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

Персонал изменения

Источник: Fitzgerald, G. , Philippides, А. и Проберт С., «Разработка информационных систем, Техническое обслуживание и улучшение: выводы из Великобритании исследование», Международный журнал Управление информацией , том 19, 1999, стр. 319-328.

 

Системы оценка

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

 

Методика оценки

Утилитарный подход ИС (рис. 21.14)

ИС может быть оценена как успешная, если она обладает всеми шестью коммунальные услуги:

• Владение (кто)
Форма
• (что)
• Место (где)
• Время (когда)
• Как (актуализация)
• Почему (гол)

 

Внедрение системы: как вовлечь людей в процесс

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

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

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

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

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

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

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

1. Определите заинтересованные стороны.

Если вы назначили исполнительного спонсора для внедрения системы, этот человек может помочь руководителю проекта в определении заинтересованных сторон. (Совет: наличие правильного менеджера проекта имеет значение. Вот как нанять хорошего менеджера проекта.)0008

Член вашей команды бизнес-систем

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

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

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

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

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

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

3. Предвидеть сопротивление.

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

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

Прозрачность имеет решающее значение. Поделитесь ответами на следующие вопросы со своими сотрудниками:

• Почему вы вносите эти изменения?
• Какие результаты вы ожидаете увидеть?
• Что произойдет, если вы сохраните статус-кво?

4. Определите сторонников перемен.

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

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

5. Создайте индивидуальный план связи.

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

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

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

6. Обеспечьте соответствующее обучение.

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

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

Успешное внедрение системы зависит от людей.

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