Принятие (реализация программного обеспечения) - Adoption (software implementation)
Эта статья поднимает множество проблем. Пожалуйста помоги Улучши это или обсудите эти вопросы на страница обсуждения. (Узнайте, как и когда удалить эти сообщения-шаблоны) (Узнайте, как и когда удалить этот шаблон сообщения)
|
В вычислениях принятие означает перенос (преобразование) между старой системой и целевой системой в организации (или, в более широком смысле, кем-либо).
Если компания работает со старой системой программного обеспечения, она может захотеть использовать новую систему, которая будет более эффективной, с большей производительностью и т. Д. Итак, тогда необходимо принять новую систему, после чего ее смогут использовать пользователи.
Существует несколько стратегий внедрения, которые можно использовать для внедрения системы в организации. Основные стратегии: принятие большого взрыва, параллельное усыновление и поэтапное усыновление. «Большой взрыв» - это метафора для одноименная космологическая теория, в котором начало космоса произошло в один момент времени. То же самое относится и к подходу «большого взрыва», при котором новая система должна быть принята сразу в один день. В случае параллельного внедрения старая и новая система изначально работают параллельно, так что все пользователи могут привыкнуть к новой системе, но при этом могут выполнять свою работу, используя старую систему, если они хотят или должны это сделать. так. Поэтапное внедрение означает, что внедрение происходит в несколько этапов, так что после каждого этапа система немного приближается к тому, чтобы быть полностью принятой организацией.
Выбор стратегии усыновления
Стратегия внедрения должна быть выбрана до начала внедрения, и она выбирается на основе целей, которые должны быть достигнуты, и типа системы, которая будет внедрена. Три типа внедрения - Большой взрыв, параллельное внедрение и поэтапное внедрение - варьируются от мгновенного переключения до стратегии, при которой пользователи постепенно начинают использовать новую систему в течение определенного периода времени (который может составлять недели, месяцы или даже годы).
Фактический отбор осуществляется путем определения приоритетов целей, которые должны быть достигнуты, и последующего сопоставления стратегии с ними (Eason, 1988). Eason определяет следующие цели:
- Возможное требование «критической массы» для работы системы.
Если для эффективной работы системы требуется или может потребоваться большая критическая масса (например, из-за сетевые эффекты ), ответом может быть стратегия большого взрыва. (Роджерс, 1995)
- Необходимость контроля риска, если есть риск.
Сведение к минимуму риска для текущей деятельности организации может быть очень важным. В зависимости от ситуации параллельное и поэтапное внедрение может помочь контролировать эти риски.
- Необходимость облегчения изменения.
Организация должна быть готова к переходу. Социально-техническая подготовка, такая как тренинги и готовые сценарии, должна быть четкой.
- Темп изменений
Если новая система предназначена для удовлетворения новых требований, таких как процесс реорганизации бизнеса, скорость, с которой организация переходит на новые процессы или пытается удовлетворить другие новые требования.
- Потребности местного дизайна
Систему, возможно, придется адаптировать к потребностям пользователей. В этом случае выбранная стратегия должна предоставлять возможность для этого.
Таблица Eason Matrix
Фактический выбор стратегии внедрения зависит от гораздо большего числа факторов, чем эти цели, но они создают окно для выбора одного из типов. Другие критерии называются переменными (Gallivan, 1996). Галливан предполагает, что соответствующие типы усыновления зависят от:
Инновационность людей
Атрибуты тех, кто должен принять нововведение / систему
Тип нововведения
Это инновационный процесс или продукт?
Атрибуты самой инновации
Готовность, коммуникабельность и делимость
Сложность реализации.
Насколько сложна реализация или каковы ее масштабы?
Эти переменные относятся к более высокому уровню, чем критерии Eason, и с ними следует обращаться как с таковыми. На основе таблицы 1 и упомянутых выше переменных более высокого уровня Галливана можно выбрать подходящую стратегию.
Подготовка организации к усыновлению
Рисунок 1: Процесс подготовки организации
Чтобы подготовить организацию к внедрению новой системы, необходимо определить изменения, которые произойдут. Это необходимо для того, чтобы иметь план или обзор перехода, и это можно сделать путем создания требований к системе. Как только руководство определило требования в отчете об определенных изменениях, им необходимо согласовать их, чтобы иметь возможность продолжить процесс изменений. Если согласия нет, руководство должно обсуждать требования снова и снова, пока они не придут к согласию. Если соглашение достигнуто и договор соглашения подписан, организация может предпринять дальнейшие шаги. Итак, теперь можно подготовить тестовую фазу, на которой будет проверяться достоверность данных, которые будут использоваться, и в котором будут проводиться испытания (Eason, 1988).
Параллельно с этим настоятельно рекомендуется подготовить комплексный план адаптации пользователей в сотрудничестве с бизнесом и затронутыми пользователями. Этот план должен учитывать все коммуникации до и после развертывания системы; обучение пользователей и документация; любые внутренние маркетинговые усилия, которые будут предприняты для стимулирования внедрения, такие как системный брендинг или сувенирная продукция; а также помощь в устранении неполадок во время развертывания (т. е. увеличенные часы службы поддержки и / или горячая линия, а также определение основных контактов для каждой затронутой области бизнеса).
Смотрите также
Рекомендации
- Исон, К. (1988) Информационные технологии и организационные изменения, Нью-Йорк: Тейлор и Фрэнсис
- Галливан, М.Дж., (1996) Стратегии внедрения новых программных процессов: оценка структуры на случай непредвиденных обстоятельств, SIGCPR / SIGMIS ’96, Денвер, Колорадо
- Роджерс, E.M. (1995), Распространение инноваций, Нью-Йорк: Free Press
- Додсон, Дж. (2011 г.), 4 остановки на коварном пути внедрения корпоративного программного обеспечения, Вашингтон
.