Шесть ужасных ИТ-проектов

Изменение старых систем, миграция электронной почты в облако и обновления ERP — это некоторые из задач, которые больше всего пугают ИТ-специалистов, считает Дэн Тайнан (Dan Tynan), автор статьи 6 most-dreaded IT projects

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

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

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

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

1. Гигантские изменения в последний момент

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

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

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

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

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

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

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

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

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

2. Великий исход электронной почты в облако

«В теории, переход от обычного сервера электронной почты к облаку звучит просто. «Однако на деле это совсем не так, - говорит Майк Мейкл (Mike Meikle), генеральный директор SecureHIM, консультант по безопасности ИТ в сфере здравоохранения, — Во-первых, пользователи являются барахольщиками. У них есть гигабайты сообщений, которые они должны были удалить много лет назад, поэтому чистый объем данных колоссален. Если вы переходите от старой системы, такой как Lotus Notes, вас ждет много преобразований данных. Некоторая информация в этих сообщениях очень чувствительна и подлежит регулированию, поэтому вам необходимо убедиться, что вы соблюдаете HIPAA, GDPR, SOX или другие правила».

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

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

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

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

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

3. Осиротевшие при рождении

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цукер сказал, что тогда начался поиск виновных.

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

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

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

6. Особые пожелания от высшего руководства

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

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

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

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

«Когда дело доходит до драки, они обычно сдаются быстрее всех», - подчеркивает Мейкл.

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

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

Источник