А у вас есть план провала проекта и отката к предыдущим системам?
Внедрять новые ИТ-системы — просто. Запустил install.exe, ответил на десяток вопросов в мастере и вот уже у пользователя новая система. Осталось только перенести в нее пользовательские данные, процедуры и процессы и убедиться, что все работает. В этом месте обычно случается «Упс!».
Чем сложнее в ИТ-системы, тем больше вероятность, что с первой попытки решение не заработает.
Впрочем, есть и другие причины отказаться от новых ИТ-систем:
- Новые ИТ-решения оказываются несовместимыми с бизнес-процессами пользователей, которые нельзя изменять в рамках данного ИТ-проекта.
- Новые версии ИТ-систем не поддерживают важные для пользователей функции, старые версии пользовательских скриптов, интеграцию с другими системами и т.д.
- Обновления ИТ-систем содержат ошибки, препятствующие их нормальной работе.
Объективных причин для прекращения ИТ-проекта может быть множество. В конце-концов ИТ-компания может просто не справиться со своей работой. И вот тут очень важно за время внедрения не разрушить бизнес клиента.
Что делать? Общее правило миграции ИТ-систем: «Семь раз отмерь — один отрежь».
Тестовый стенд. Проверяйте и отрабатывайте миграцию бизнес-процессов в новые ИТ-системы в тестовой среде. Технологии виртуализации позволяют строить сложные тестовые среды на ограниченных аппаратных ресурсах. В том числе на тестовом стенде необходимо проверять и обновления критических систем.
Создавайте план отката изменений. На тестовом стенде необходимо отработать и документировать не только процесс миграции ИТ-систем, но и откат к предыдущему решению.
Резервное копирование. Сначала сохраняем работающую систему — затем делаем обновление. Наличие резервной копии позволяет значительно снизить риск неправильного развертывании новых версий и обновлений.
Виртуализация. Перенос работающих систем на виртуальные машины позволяет значительно повысить надежность ИТ-систем, особенно в небольших компаниях. Тестирование и обновление виртуальных машин может проходить в среде максимально близкой к рабочей, а время отката к старой версии системы будет минимальным.
Сохраняйте работающие системы. Новые ИТ-системы всегда разворачиваются на чистом аппаратном обеспечении. Критическую бизнес систему нельзя просто отключить и уж тем более стереть.
Пробная эксплуатация. В период пробной эксплуатации необходимо убедиться, что работа в старой и новой системах дает одни и те же результаты.
Мотивация и обучение пользователей. Принятие новой системы конечными пользователями — важная составляющая успеха. На одном административном ресурсе внедрить новое решение очень сложно. Пользователей необходимо привлекать на свою сторону, в том числе показывать преимущества новой системы для них лично, а также мотивировать и обучать.
Дополнительные материалы
Комментарии (19)
КомментироватьЧижиков Владимир [Skif Swarogich], 16 февраля 2011, 20:44
Котельников Илья [iluha], 17 февраля 2011, 10:06
наверное это был такой юмор:)
Рубинштейн Кирилл [krubinshteyn], 17 февраля 2011, 11:48
Бычков Валерий [vbychkov], 17 февраля 2011, 14:33
Савчук Виктор [TigerS], 16 февраля 2011, 22:05
По этой теме, я так понимаю, главное - миграция (переход на новую систему с сохранением старых данных)
Главных принципов было несколько:
1)первому внедрению предшествует определенный период параллельного ведения СУБД (и сравнение результатов по важным параметрам). Да. Нужно надавить на руководство клиента - премировать сотрудников, занимающихся двойной работой. А что делать? ... ах, да. Можно конечно заранее завысить стоимость проекта и премировать из собственных средств ;)
2)введению любой новой версии предшествует бекап строй БД, исполняемого файла и настроек
3)любая новая версия (миграция) обкатывается на "сообщниках" (наиболее ответственная группа пользователей, работа которых напрямую зависит от внедряемого ПО). Как этих сообщников заиметь - уже отдельная тема :) Период обкатки зависит от сложности изменений (обычно хватало 1...5 дней)
4)обеспечить достаточно легкий возврат к предыдущей, работоспособной версии, самим пользователем (исключая случаи серьезных изменений в структуре БД). Иногда только вернешься от клиента - уже звонят - выявлена ошибка. Как нам работать до вашего приезда? ;). Нам хватало батника (вернее ярлыка на батник) на раб.столе юзеров.
Давлицаров Андрей Рустемович [Tomi], 16 февраля 2011, 22:07
При переходе на новую версию управляющей программы, которая сулит несметные удачи, необходимо провести ее стыковку с программами более низкого уровня, чтобы быть уверенным, что все сетевые сообщения или комманды воспринимаются и отрабатываются программами нижнего уровня так, как должны. Если есть еще один уровень - необходима стыковка и с ним. То есть, основное правило - отладку реальной работы надо начинать по принципу сверх - вниз.
Следует обратить особое внимание на этап тестирования работы всей системы. Если система действительно сложная (не для понимания, а ее можно отнести к таковым по формальным признакам), то нужно также помнить, что самые небольшие изменения в одной компоненте могут привести к изменению работы в других, внешне даже не связанных между собой. Иногда при появлении сбоев даже бесполезно анализировать граф работы алгоритма - приходится перебирать все возможные воздействия, включая некорректные. И анализировать - искать факторы. То есть, даже небольшие изменения могут повлечь большие последствия. Это правило больших систем. В этом случае необходимо вспоминать теорвер и примерно вычислять, в чем причина.
Из рекомендаций могу усомниться только со стендом. Если это возможно - прекрасно. С системами реального времени такое проходит далеко не всегда. Все остальные - это аксиома для тех, кто обслуживает большие системы. Правда, с виртуальными машинами у нас сложно. Это из той же оперы, что и стенд: невозможно сымитировать реальный процесс. Но для небольших систем должно работать. Не согласен с тем, что нужно отказываться от внедрения новых ИТ-процессов, если они вошли в конфликт со старыми скриптами пользователей. На мой взгляд всегда (почти) есть возможность доработать свое ПО, чтобы оно стыковалось с устаревшим. Противоположное не всегда верно. Вопрос только в договоренность с заказчиком. Если он не вникнет в проблему и не даст возможности доработать новую версию, то, действительно, откат.
Рубинштейн Кирилл [krubinshteyn], 17 февраля 2011, 11:57
Котельников Илья [iluha], 17 февраля 2011, 14:45
Через 15 минут тебе в дверь позвонят приятные молодые люди и ответят на все-все вопросы :)
Рубинштейн Кирилл [krubinshteyn], 17 февраля 2011, 14:50
Давлицаров Андрей Рустемович [Tomi], 17 февраля 2011, 23:09
С точки зрения страхов про "молодых людей". Пять лет назад у нас появился новый ФСБ-шник. Лысый, круглый и шустрый. Первый приказ, который он издал - запретить вносить на объект флэшки, ноутбуки и пользоваться мобильниками. Но на станции нет телефоннойсвязи. Поэтому все равно все переговоры идет по мобильной связи - работать то надо. С ним в паре появился высокий, тонкий, и тоже лысый. Я сразу окрестил эту пару по журналистской привычке "ФСБ-шной братвой". Прошло время. Сейчас не мешают. Да и военные, которые с нами работают их инстинктивно недолюбливают - предупреждают о появлении на объекте.
Котельников Илья [iluha], 17 февраля 2011, 10:23
Но пока Вы до нее не дошли, безусловно, стоит поддерживать жизнеспособность старой системы и держать запасной план. Важный момент, кстати, не особо распространяться на счет наличия этого запасного плана. Пусть он будет вашим тузом в рукаве.
Когда о возможности отката знает слишком много людей, многократно возрастает риск саботажа...
Яковлев Андрей Михайлович [swtws], 17 февраля 2011, 14:43
К последнему пункту. Пользователей надо предупредить, что грядет неизбежное глобальное Изменение, каковое вызовет кучу инцидентов, чего избежать нет никакой силы-возможности. То есть это как стихийное бедствие. План отката изменения всегда должен быть, но на практике через гору инцидентов, жалоб, скандалов, обещаний больше никогда не связываться наступает Светлое Будущее. Человеческий консерватизм и нежелание учиться часто создают больше проблем чем несовместимость нового офиса и старых на-коленке-писаных скриптов. Их также на коленке и переписывают. Критичность простоя даже у крупных компаний сильно завышена. Во фразе "мы потеряли 10 клиентов, которые были готовы..." означает, что это были потенциальные клиенты клиенты и их потеря могла произойти и так.
Из практики. Авария (не изменение) привела двухнедельному простою. Сорвался один постоянный клиент - ох и мата было в сторону поставщиков железа. На самом деле у этого клиента конкуренты фирмы имели лобби и далее все понятно.
Котельников Илья [iluha], 17 февраля 2011, 14:54
"Час простоя нашего офиса стоит N-миллионов рублей"...
Так и подмывает после этого губозакаточную машинку таким "милионникам" подарить :)
На практике простой - это когда вместо того, чтобы вяло жевать сопли и создавать видимость рабочей деятельности, сотрудники начинают к любимому жеванию соплей добавлять звонки начальству (периодичность 5-15 минут) с жалобой о невозможности работать.
Яковлев Андрей Михайлович [swtws], 17 февраля 2011, 17:13
Поэтому реально планы аварийного восстановления и дополнительную плату за грамотный план изменений (с откатом, как и положено по "лучшим практикам") деньги получить сложно.
Савчук Виктор [TigerS], 17 февраля 2011, 17:20
А вот это кстати не факт.
Я внедрял и вел СУБД абонотдела БТИ (Бюро Технической Инвентаризации).
Очереди там никогда не кончались. Так что при любом простое, кроме прямых денежных убытков для БТИ, еще и админам было что слушать от стоящих в очередях людей :)
Поэтому все внедрения новых версий проводились часика за два до начала работы отдела. С тройной перестраховкой.
Бекап базы делался каждые 10 минут :)
При этом еще данные за сегодняшний день паралельно с внесением в основную БД - заносились в простенький текстовый файлик. Если основная БД рухнет (было как-то такое) - всегда можно по быстрому поднять версию за предыдущие 10 мин. А уж вечером довнести
потерянные квитанции.
Вот такая "военная" перестраховка была. Как говорится было "сделано с любовью"... и заботой о себе любимом :)
Правда написанию такого сценария предшествовали неоднократно набитые шишки со старой БД на dBase.
Рубинштейн Кирилл [krubinshteyn], 17 февраля 2011, 17:38
Чижиков Владимир [Skif Swarogich], 18 февраля 2011, 12:00
Рубинштейн Кирилл [krubinshteyn], 18 февраля 2011, 12:10
Котельников Илья [iluha], 18 февраля 2011, 12:50