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

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

Управление патчами - не привлекательное занятие, но при малейшем отставании ваша организация может пострадать от серьезного нарушения безопасности. Проекты облачной миграции также не часто привлекательны, но запуск локальных почтовых серверов в 2018 году немного напоминает использование дисковых телефонов. Внедрение и обновление решений по планированию ресурсов предприятия (ERP) стали олицетворением несостоятельности ИТ-проектов в течение последних десяти лет, но большинство крупных организаций не могут выжить без какой-либо системы ERP.

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

Решения для адских ИТ-проектов обычно просты, но дьявол кроется в деталях.

1. Огромные исправления в последнюю минуту

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

«Нас постоянно бросают в большие проекты, в которых исправления не происходили в течение нескольких месяцев или лет», - говорит Оли Тордарсон, генеральный директор ИТ-провайдера Alvaka Networks. «Иногда это могут быть сотни производственных серверов, а также dev и тестовые серверы. Осознание того, что если что-то пойдет не так, и мы можем подорвать присутствие в Интернете крупного бренда, вызывает стресс. Вот почему внутренний персонал иногда откладывает исправления, пока внезапно руководство не посмотрит на ситуацию и не осознает, что она превратилась в непреодолимую».

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

«Руководство полиции - не из робкого десятка, - говорит он. «Они зовут нас, потому что они не могут войти в систему и делать то, что им нужно делать».

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

Самые худшие работы на патчах - это те, в которых системы игнорировались в течение многих лет, добавляет технический директор Alvaka Уннар Гардарссон (который говорит, что он один из редких ИТ-профессионалов, которые на самом деле наслаждается исправлениями).

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

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

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

2. “Великое переселение” электронной почты на облако

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

Во-первых, пользователи являются “барахольщиками”, говорит Мейкл. У них накоплено гигабайты сообщений, которые они должны были удалить много лет назад, поэтому чистый объем данных является сложным. Если вы переходите от старой системы, такой как Lotus Notes (содрогание), у вас будет много преобразования данных на вашей пластине. Некоторая информация в этих сообщениях очень чувствительна и регулируется, поэтому вам необходимо убедиться, что вы соблюдаете HIPAA, GDPR, SOX или другие правила.

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

Мейкл говорит, что он работал в компаниях, где облачная миграция заняла более года и потребовала много рук.

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

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

«Это не может быть просто взглядом IT-отдела со словами:« О, это выглядит хорошо», - говорит он. «Вы действительно должны знать свои требования пользователей и то, что они готовы допустить».

3. Проекты, ставшие сиротскими при рождении

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

«Проекты, регулируемые нормативным актом, которые предписываются исполнительным руководством, но не получают полной поддержки, являются самыми плохими», - говорит Шелдон К., директор в компании ИТ-услуг. (Шелдон не является его настоящим именем, он попросил быть анонимным, чтобы не быть идентифицированным бывшими коллегами).

До года назад Шелдон был техническим вице-президентом по крупным финансовым учреждениям на Западном побережье. Когда он присоединился к компании, он уже попал в переплет регулирования, отчасти из-за неадекватного плана аварийного восстановления. Акционеры-активисты толкали учреждение, чтобы убрать беспорядок, и, хотя топ-менеджмент стоял позади проекта, руководители отделов имели свои собственные приоритеты. Восстановление не было в приоритете их задач.

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

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

«Я снова и снова напоминал ИТ-директору, что это происходит, пожалуйста, помогите мне», - говорит он. «Я подумал:« Эй, есть эта проблема ». Тишина. «Я еще не получил ответа». Снова тишина. Таким образом, проект продвигался вперед с этими рисками, которые не были приняты или признаны».

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

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

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

4. ERP - это слово из четырех букв

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

Привязка ERP к устаревшему оборудованию всегда чревата опасностью; добавьте туда языковые и культурные барьеры, и вы получите рецепт катастрофы эпических масштабов, - отмечает Дэн Коулби, директор по эффективности бизнеса и консалтингу в IT Lab, компании по технологическим услугам, базирующейся в Великобритании.

В середине 2000-х годов, когда Коулби работал в консалтинговой фирме Big 4 в Лондоне, он был призван помочь японскому отделению большого многонационального подразделения в глобальной системе ERP. К тому времени, когда прибыл Коулби, проекту было уже более двух лет и он значительно превысил бюджет, отчасти потому, что некоторые аппаратные средства были действительно древними.

«Одна из этих систем была настолько старой, что нам пришлось заимствовать источник электропитания с выставки в Национальном компьютерном музее в Токио, на случай неудачи», - говорит он. «У нас было только 8 часов каждую ночь, чтобы обновить систему ERP новыми данными, но запуск интерфейса занимал 20 часов, что делало работу практически бесполезной».

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

«Мне не разрешалось подвергать сомнению архитектуру, стратегию или глобальный подход компании к технологии», - говорит Коулби. «Я в конечном итоге убедил японцев изменить свои бизнес-процессы, поэтому они стали использовать меньше информации. Я вырезал около 90 процентов данных, чтобы система могла работать менее чем за 8 часов».

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

«В IT Lab мы всегда занимаемся организацией, структурой, процессом и управленческой стороной ИТ, потому что это всегда так же важно, как и сама технология».

5. Несоответствие обещаниям

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

«Люди очень оптимистично относятся к тому, что они могут выполнить за короткий промежуток времени, особенно в быстро развивающихся компаниях», - говорит Алан Цукер, основатель проекта Project Management Essentials.

В конце 1990-х Цукер работал менеджером проекта в бухгалтерии для телекоммуникационной компании Fortune 100. Носитель выставил счета более 1 миллиарда долларов в месяц и использовал сотни взаимосвязанных электронных таблиц и баз данных, чтобы отслеживать все это. Решение заключалось в том, чтобы создать единое приложение для закрытия книг каждый месяц, используя Sybase на задней панели с интерфейсом Power Builder.

В конце 1990-х Цукер работал менеджером проекта в бухгалтерии для телекоммуникационной компании Fortune 100. Поставщик услуг выставил счета более 1 миллиарда долларов в месяц и использовал сотни взаимосвязанных электронных таблиц и баз данных, чтобы отслеживать все это. Решение заключалось в том, чтобы создать единое приложение для закрытия книг каждый месяц, используя Sybase на задней панели с интерфейсом Power Builder.

После реорганизации компании ответственность за проект упала на группу Цукера.

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

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

«Вот тогда-то и начался поиск виноватых

«Мой предшественник в ИТ-организации начал изо всех сил защищаться, - говорит он. «Он писал письма страницами, и они напоминали полицейские расследования. «На эту дату в это время, так и так сказали это ...» и так далее. Ситуация только усугублялась, поскольку не было никаких конструктивных разговоров ».

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

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

6. Специальные запросы от руководящего состава

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

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

«Большинство организаций не такие, - говорит Мейкл, - В основном, те у кого есть наибольший политический вес в организации получают все».

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

«Когда дело доходит до выяснения отношений, они меняют свою позицию на противоположную», - подчеркивает Мейкл.

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

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

No Comments