WikiDer > Принятие большого взрыва
 | Эта статья может потребоваться переписан соответствовать требованиям Википедии стандарты качества. (Май 2009 г.) |
 | Эта статья предоставляет недостаточный контекст для тех, кто не знаком с предметом. (Март 2010 г.) (Узнайте, как и когда удалить этот шаблон сообщения) |
Принятие большого взрыва или же прямое переключение это принятие тип мгновенного переключения, когда все, кто связан со старой системой, переходят на полностью функционирующую новую систему в определенный день.[1][2][3]
Когда новый система необходимо реализовать в организация, есть три различных способа принять эту новую систему: принятие большого взрыва, поэтапное усыновление и параллельное усыновление. В случае параллельного внедрения старая и новая система работают параллельно, поэтому все пользователи могут привыкнуть к новой системе и тем временем выполнять свою работу, используя старую систему. Поэтапное внедрение означает, что внедрение будет происходить в несколько этапов, поэтому после каждого этапа система немного приближается к полному внедрению. С принятием большого взрыва переключение между использованием старой системы и использованием новой системы происходит в один день, так называемое мгновенное переключение системы. Все начинают использовать новую систему в один и тот же день, и с этого момента старая система больше не будет использоваться.
Тип принятия большого взрыва более рискованный, чем другие типы принятия, потому что в этот подход заложено меньше возможностей обучения, поэтому требуется больше подготовки, чтобы добиться большого взрыва.[1] Эта подготовка будет описана ниже на примере модели данных процесса принятия Большого взрыва.
Таблица понятий
В этой записи используется несколько концепций. Определения этих понятий приведены в таблице ниже, чтобы их было проще использовать.
| Концепция | Определение |
| ОТЧЕТ ОБ ОПРЕДЕЛЕННЫХ ИЗМЕНЕНИЯХ | Отчет об определении руководством всех изменений, которые будут выполнены, чтобы иметь возможность внедрить новую систему (Исон, 1988) |
| ДОГОВОР ДОГОВОР | Понимание между людьми, чтобы следовать определенному образцу поведения (Викисловарь) |
| ПЛАНИРОВАНИЕ | Функция управления, которая связана с определением целей для будущей деятельности организации и решением задач и ресурсов, которые необходимо использовать для достижения указанных целей (Википедия)[циркулярная отчетность?] |
| ПРЕОБРАЗОВАННЫЕ ДАННЫЕ | Данные, которые конвертируются из старой системы, чтобы соответствовать новой системе (Koop, Rooimans and de Theye, 2003) |
| ЗАГРУЖЕННЫЕ ДАННЫЕ | Преобразованные данные, которые загружаются в новую систему (Исон, 1988) |
| ПРОВЕРЕННЫЕ ДАННЫЕ | Загруженные данные, которые проверяются в новой системе, чтобы убедиться, что она работает или нет (Исон, 1988) |
| ИСПЫТАНИЕ | Тест, обычно тест, чтобы увидеть, соответствует ли что-то заданному стандарту или нет (Википедия)[циркулярная отчетность?] |
| ПРОВЕРКА ДЕЙСТВИЯ | Проверена достоверность новой базы данных (Koop, Rooimans and de Theye, 2003). |
| БАЗА ДАННЫХ | База данных - это набор записей, хранящихся в компьютере систематическим образом, чтобы компьютерная программа могла обращаться к ней, чтобы ответить на вопросы. (Википедия)[циркулярная отчетность?] |
| ЗАЯВЛЕНИЕ | Это свободно определенный подкласс компьютерного программного обеспечения, которое применяет возможности компьютера непосредственно к задаче, которую пользователь хочет выполнить (Википедия).[циркулярная отчетность?] |
| ИНФРАСТРУКТУРА | Инфраструктура, как правило, представляет собой набор взаимосвязанных структурных элементов, которые обеспечивают основу для поддержки всей структуры (Википедия).[циркулярная отчетность?] |
| СПИСОК ОБУЧЕННЫХ ПОЛЬЗОВАТЕЛЕЙ | Список обученных пользователей, которые готовы к большому взрыву (Исон, 1988) |
| БУФЕР | Буфер из опытных сотрудников, которые могут прийти в любой офис и временно взять на себя обязанности, чтобы сотрудники могли спланировать изменения, пройти обучение и т. Д. (Исон, 1988) |
| ПРЕОБРАЗОВАННАЯ СИСТЕМА | Действительная система, содержащая проверенные данные, проверенные испытаниями (Koop, Rooimans and de Theye, 2003; Eason, 1988) |
| ВЫПУЩЕННАЯ ЧАСТЬ | Все различные выпущенные части системы: база данных, созданное приложение и инфраструктура (Koop, Rooimans and de Theye, 2003) |
| СИСТЕМА ВЫПУСКА | Публичный выпуск новой версии программного обеспечения (Википедия)[циркулярная отчетность?] |
| НОВАЯ СИСТЕМА | Система, которая используется после Большого взрыва и заменяет прежнюю систему (Koop, Rooimans and de Theye, 2003) |
Большой взрыв
Однажды управление решил использовать метод большого взрыва и поддерживает необходимые для этого изменения, можно начать реальный процесс изменений. Этот процесс состоит из нескольких этапов: преобразование системы, выпуск частей системы и обучение будущему. пользователи.[1]
Действия в процессе объяснены в таблице ниже, чтобы четко их указать. Понятия, которые используются для выполнения действий, указаны заглавными буквами.
| Мероприятия | Поддействие | Описание |
| Подготовить руководство (см. Принятие) | Определите организационные изменения | Процесс определения изменений, которые должны произойти, чтобы сделать большой взрыв возможным, результатом которого станет ОТЧЕТ ОБ ИЗМЕНЕНИЯХ В ОРГАНИЗАЦИИ |
| Согласуйте организационные изменения | Чтобы иметь возможность внести большой взрыв, необходимо согласие по поводу плана изменений, результатом которого станет ДОГОВОР СОГЛАШЕНИЯ. Если нет соглашения, необходимы новые встречи по соглашению или изменения нужно определять снова и снова, пока не будет создан ДОГОВОР СОГЛАШЕНИЯ. | |
| Преобразовать систему | Планируйте для будущих пользователей | Составьте ПЛАНИРОВАНИЕ для людей, которым придется иметь дело с НОВОЙ СИСТЕМОЙ, чтобы у них был обзор событий, которые должны произойти.[1] |
| Преобразование данных из старой системы | Преобразование данных из старой системы, чтобы их можно было использовать в НОВОЙ СИСТЕМЕ (Koop, Rooimans and de Theye, 2003) | |
| Загрузить данные в новую систему | Загрузите данные ПРЕОБРАЗОВАННЫЕ ДАННЫЕ в НОВУЮ СИСТЕМУ[1] | |
| Тестовые данные в новой системе | ТЕСТОВЫЕ ДАННЫЕ, чтобы узнать, можно ли будет использовать данные в НОВОЙ СИСТЕМЕ[1] | |
| Проведите автономные испытания | Выполните TRIAL с системой и с пользователями системы, чтобы проверить, правильно ли работает система.[1] | |
| Проверить, чтобы проверить действительность | Проверка действительности, чтобы система могла быть подготовлена к выпуску (Куп, Ройманс и де Хи, 2003) | |
| Детали выпуска | Выпустить преобразованную базу данных | Выпуск БАЗЫ ДАННЫХ, преобразованной из старой БАЗЫ ДАННЫХ[1] |
| Выпустить созданное приложение | Выпустить ЗАЯВКУ, которая предназначена для персонала[1] | |
| Инфраструктура выпуска | Выпуск новой ИНФРАСТРУКТУРЫ[1] | |
| Подготовить пользователей | Поддерживать буфер из опытного персонала | Создайте БУФЕР сотрудников, которые могут взять на себя обязанности людей, которые должны быть обучены использованию НОВОЙ СИСТЕМЫ, чтобы повседневная работа могла продолжаться[1] |
| Обучить пользователей | Обучите пользователей подготовиться к большому выпуску системы, чтобы создать СПИСОК ОБУЧЕННЫХ ПОЛЬЗОВАТЕЛЕЙ |
Преобразуйте систему
Сначала планирование для всего процесса усыновления нужен. Планирование позволяет будущим пользователям знать, что произойдет и когда им следует ожидать определенных изменений, что позволяет избежать ненужных неопределенностей и, следовательно, создает лучшую рабочую атмосферу. Планирование также дает понять, когда происходит реальное внедрение, и дает будущим пользователям возможность подготовиться к этому изменению.[1] Модель ниже показывает, что действия (в сером поле) приводят к результатам (в полях рядом с серым полем), чтобы иметь возможность иметь частичный результат: преобразованная система
Когда планирование составлено и все знают, чего от них ожидают, можно начинать технический переход. Сначала старые данные необходимо преобразовать в форму, которая сможет работать с данными в новой системе (Koop, Rooimans and de Theye, 2003). Затем эти данные необходимо загрузить в новую систему, в результате чего получатся так называемые загруженные данные. Эти загруженные данные необходимо протестировать, чтобы проверить эффективность данных и уровень понимания будущих пользователей. Не в сети испытания необходимо выполнить, чтобы проверить, могут ли система и пользователи работать вместе. Необходимо проверить не только эффективность и понимание, но и проверить правильность, чтобы уровень проверка достоверности данных Чисто.[1] ). Если данные недействительны, руководству необходимо снова определить изменения, и организации придется подготовить другой способ выполнения принятия Большого взрыва (см. Принятие; Подготовьте организацию к усыновлению).
Освободить части системы
Если все данные верны, отдельные части системы могут быть вышел. В база данных который преобразован из старой базы данных, необходимо освободить, чтобы новые данные были доступны. Далее произведенный заявление необходимо выпустить, чтобы можно было использовать новое приложение. В инфраструктура всей новой системы также необходимо выпустить, чтобы было ясно, как система будет выглядеть и как все связано (Koop, Rooimans and de Theye, 2003). Важно отметить, что на этом этапе выпускаются только отдельные части, которые еще не составляют новую систему, а только ее части. Обратите внимание, что все это происходит в автономном режиме: это видят только разработчики системы, пользователи все еще работают в старой системе. Приведенная выше модель показывает, какие действия необходимо выполнить (в сером поле) системному контроллеру, чтобы получить результаты, которые приводят к выпущенным частям. Если выпуск деталей не удался, руководству необходимо снова определить новые изменения (см. Принятие; Подготовить организацию к усыновлению).
Обучить организацию использованию системы
Если выпуск отдельных частей прошел успешно, можно предпринять следующий шаг: подготовить пользователей. Чтобы иметь возможность внедрить новую систему, т.е. принять ее, все пользователи должны быть обучены работе с новой системой. Без огромных последствий для производственного уровня организации обучение всех возможно только при наличии резерва опытных сотрудников, которые могут взять на себя повседневную работу пользователей, нуждающихся в обучении. Это означает, что для всех людей, нуждающихся в обучении, будет доступен персонал, который возьмет на себя работу, поэтому не будет огромных задержек с работой. Когда этот буфер создан, пользователей можно обучать.[1] Отдел кадров создаст буфер из опытных сотрудников (активность в сером поле), пригласив кандидатов в буфер. Затем пользователи могут быть обучены, и обученные пользователи могут быть внесены в список, так что можно написать отчет о подготовке пользователя.
Но правильно обучить будущих пользователей не так просто, как кажется, как показывает случай с FoxMeyer (Scott, Vessey, 2000). Эта компания использовала метод большого взрыва для реализации Планирование ресурсов предприятия (ERP) система. Были проведены неправильные тренинги, было сделано предположение, что пользователи уже достаточно осведомлены об этом и были обучены неправильным навыкам. У Dow Corning также были большие проблемы с приобретением необходимых навыков во время реализации большого взрыва ERP (Scott, Vessey, 2000). Использование новой системы требует различных навыков и знаний, которые в некоторых случаях, кажется, недооцениваются менеджерами (изменениями).
Методы
Есть несколько методов реализации новой системы. Фаза принятия - это только одна фаза всей реализации. Регата (Куп, Ройманс и де Хи, 2003) - это, например, метод, разработанный для реализации систем. Этот метод, разработанный Sogeti, рассматривает переналадку как проект и фокусирует внимание на нескольких этапах этого проекта, например, этапе подготовки (Регата: этап подготовки) принятия и принятия метода реализации (Регата: метод принятия). Внедрение SAP это еще один метод, специализирующийся на реализации и принятии SAP AG программное обеспечение, которое разделено на несколько методик.
Риски
Из-за мгновенного переключения все должно выполняться в установленный график. Это рискованная операция. Организация может быть еще не готова к этому, может использоваться неверный набор данных или информационная система может зависнуть из-за отсутствия опыта и проблем с запуском. Также неэффективный метод отката может представлять опасность при реализации системы, использующей Большой взрыв (Koop, Rooimans and de Theye, 2003).
Фондовый рынок Великобритании, 1980-е годы
1986 год Лондонская фондовая биржа закрыт в пятницу вечером, и все компьютеры были включены в следующее утро понедельника.[4][5] Утверждалось, что это привело к большим потерям.[нужна цитата]
Dow Corning
Ранее Dow Corning использовала системы, ориентированные на конкретные отделы. Руководство решило, что они хотят стать по-настоящему глобальной компанией, которая будет использовать только одну информационную систему: систему планирования ресурсов предприятия (ERP). Чтобы внедрить эту новую ERP-систему, они использовали метод «большого взрыва» и потратили много времени и усилий на пересмотр ее бизнес-процессов. Компания была подготовлена к внедрению и сначала провела три пилотных внедрения, прежде чем использовать новую систему во всей глобальной организации. Во-вторых, FoxMeyer внедрила ERP-систему с амбициозным программным обеспечением для автоматизации склада, использовав широкое распространение для получения конкурентного преимущества. Но у FoxMeyer, похоже, был чрезмерно оптимистичный менеджмент с нереалистичными ожиданиями: изменение было слишком большим и слишком радикальным. Это привело к очень высокому рабочему давлению, чтобы все сотрудники уложились в сроки. Столь нереалистичные ожидания руководства также являются риском (Scott, Vessy, 2000).
Dow Corning постоянно следила за прогрессом и принимала решения, чтобы гарантировать соблюдение сроков. Это было возможно только при наличии обратной связи и хорошей коммуникации. FoxMeyer не сумел обеспечить общение и внимание, которые были необходимы для быстрой и эффективной обратной связи. Вместо этого они пытались минимизировать проблемы, игнорируя их, и давали обескураживающую критику, что приводило к неоднозначной обратной связи. Это мешало организационное обучение, что очень важно во время организационных изменений. Поэтому плохое общение и неоднозначная обратная связь также являются рисками при принятии системы с большим взрывом (Скотт, Весси, 2000).
Еще одна рискованная стратегия - сосредоточиться только на результате, а не на том, как его достичь, и недооценивать процесс обучения пользователей. Очень сложно планировать обучение или знания, хотя они необходимы, чтобы иметь возможность осуществить «большой взрыв».
Смотрите также
- Принятие (реализация программного обеспечения)
- Поэтапное принятие
- Параллельное усыновление
- Мгновенная резка
- Внедрение SAP
- PRINCE2
- Принятие консенсусных решений
- Выполнение
- Планирование
- Проверка достоверности данных
Рекомендации
- ^ а б c d е ж грамм час я j k л м п (Исон, 1988)
- ^ Копли, Стив. "IGCSE ICT". Получено 13 августа 2011.
- ^ Уэйнрайт, Стюарт (2009). IGSCE и O Level Компьютерные исследования и информационные технологии. Издательство Кембриджского университета. п. 29.
- ^ «Как технологии повлияли на фондовый рынок. - Компьютеры в городе». www.citc.it. 18 сентября 2015 г.. Получено 19 июн 2017.
- ^ http://www.londonstockexchange.com/products-and-services/rns/history/history.htm
- Исон, К. (1988) Информационные технологии и организационные изменения, Тейлор и Фрэнсис.
- Куп Р., Ройманс Р. и де Хи М. (2003) Regatta: ICT-implementationaties als uitdaging voor een vier-met-stuurman, S.D.U. Уитгеверий. ISBN 90-440-0575-8.
- Скотт, Дж. Э., Весси, И. (2000) Внедрение систем планирования ресурсов предприятия: роль обучения на ошибках, Границы информационных систем, том 2 (2), стр. 213–232.