апрель    2024

Пн	Вт	Ср	Чт	Пт	Сб	Вс
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

показать все 

22.04.2024

Сообщество цифровых управленцев «я-ИТ-ы» проводит ЗАКРЫТУЮ встречу в рамках выставки «Связь-2024»!

Читать далее 

18.04.2024

Ассоциация разработчиков «Отечественный софт» отметила 15-летие

Читать далее 

17.04.2024

РДТЕХ представил Технологическую карту российского ПО 2023

Читать далее 

16.04.2024

RAMAX Group получила партнерский статус уровня Gold по продукту Tarantool

Читать далее 

показать все 

18.04.2024

5 способов повысить безопасность электронной подписи

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

Читать далее 

18.04.2024

Скоро некому будет делать сайты и заниматься версткой

Читать далее 

18.04.2024

Цифровая трансформация в энергетике: как запустить проект с максимальным финансовым эффектом?

Читать далее 

05.04.2024

Мотивируй, не то проиграешь!

Читать далее 

22.03.2024

В 2024 году в России и мире вырастут объемы применения AR/VR 

Читать далее 

25.02.2024

Цифровые технологии: надежды и риски

Читать далее 

05.02.2024

Будут ли востребованы услуги технической поддержки софта Oracle в России в ближайшие годы?  

Читать далее 

31.01.2024

Здания с признаками интеллекта. Как Сергей Провалихин автоматизирует дома и производства

Читать далее 

показать все 

Главная / Архив номеров / 2016 / Выпуск №04 (57) / «Проекты ИТ: как превратить возможности в результаты»

Рубрика: ИТ-проекты

 Марина Аншина, известный эксперт в области управления проектами ИТ, автор нескольких книг, председатель Комитета по стандартам Российского Союза ИТ-директоров. В ИТ работает более 20 лет

«Проекты ИТ:
как превратить возможности в результаты»

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

Сегодня мы начинаем публикацию глав из ее будущей книги

В 2014 году журнал «БИТ» попросил меня написать серию статей об управлении проектами ИТ. Я очень благодарна журналу, что он поднял эту тему, которая с учетом стремительного развития отрасли и появления новых уникальных для организации возможностей, использовать которые можно и нужно в рамках проектов, несомненно, становится все более важной. Книга создана на основе статей, которые появились в журнале в 2014 – 2015 годах.

Почему я взялась за эту тему?

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

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

Эта книга предназначена для тех, кто занимается или собирается заняться непростым делом управления проектами ИТ, а также для членов проектных команд, заказчиков и просто людей, которые захотят разобраться в особенностях ИТ и проектов, с ними связанных. Я очень надеюсь, что она поможет им управлять проектами с удовольствием и с хорошими полезными и для компании, и для них самих результатами. А также получать от ИТ то удовольствие, которое со мной разделяют многие коллеги и друзья.

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

Внимание! Открыт предзаказ на книгу нашего автора Марины Аншиной. Оставить заявку на предзаказ книги можно по ссылке: https://goo.gl/kRpylq

Глава 1. Определение проектов ИТ. Особенности проектов ИТ. Их место в деятельности организации

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

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

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

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

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

Вы, конечно, знаете, что в соответствии с PMBOK проект – это временное предприятие, направленное на создание уникального продукта, услуги или результата (Руководство кСводу знаний по управлению проектами (Руководство PMBOK). Пятое издание, Project Management Institute, Inc., 2013). Это определение применяется в области управленческой деятельности, а значение термина происходит от латинского слова projectus, что означает «брошенный вперед, выступающий, выдающийся вперед».

А вот в инженерном деле проект – это целостная совокупность моделей, свойств или характеристик, описанных в форме, пригодной для реализации системы, и это значение происходит от латинского слова designare, что значит «размечать, указывать, описывать, изобретать», (Guide to the Systems Engineering Body of Knowledge, SEBoK 1.0, 2012), т.е. проект выступает существительным от глагола «проектировать».

Практически вся деятельность человека может быть разделена на проекты и процессы. В таблице 1 приведены основные различия между этими типами деятельности.

Таблица 1. Сравнение проектов и процессов

Я не стану сразу комментировать эту таблицу, потому что дальше мы подробно обсудим все, что в ней приведено. Отмечу только тенденцию, которую мы так часто наблюдаем впоследнее время: те области, в которых преобладала проектная деятельность, стремительно переходят на сторону процессов. Действительно, по мере ускорения изменений и роста нестабильности проекты перестают подходить для многих областей. Так произошло, например, с управлением бизнес-процессами, где проекты реинжиниринга сменила технология BPM (Business Process Management).

Проекты ИТ также тесно связаны с процессами ИТ. И также подвержены процессной метаморфозе. Достаточно вспомнить известный парадокс: проект внедрения ERP-системы –это на самом деле не проект, а процесс. И в этой шутке много правды.

Скорее всего, когда вы думаете о проектах ИТ, то представляете себе именно такой проект – внедрение крупной корпоративной системы: ERP, CRM, EAM¹. А, например, проект открытия нового магазина, в котором обязательно присутствуют и прокладка сетей, и закупка компьютерного оборудования, и установка и внедрение ПО, может ли считаться ИТ-проектом? Скорее всего вы ответите «нет». А если это новый склад интернет-магазина? Или карточный проект в банковской области, в котором очень велика ИТ-составляющая?

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

Итак, что же такое проект ИТ? Я приведу вполне практическое определение, которое мы использовали в холдинге, где я руководила подразделением ИТ: «ИТ-проект представляет собой комплекс мероприятий, из которых не менее 50% по времени или деньгам, или человеческим ресурсам, связаны с ИТ, в результате которого появляется уникальный, полезныйдля компании результат. Проект либо длится не менее трех месяцев, либо стоит не менее 100 тыс. руб., либо в нем принимают участие не менее трех сотрудников разных подразделений организации или не менее семи – причем достаточно одного из вышеперечисленных признаков. ИТ-проектом может быть назначен любой комплекс мероприятий распоряжением генерального директора». Кроме проекта, мы выделяли задачи и изменения и отдельно регламентировали процессы управления первыми и вторыми. Классификацию осуществляли по тем же признакам: время, деньги, команда проекта. А высшая воля генерального директора могла поменять тип выполняемых действий исходя из их важности длякомпании.

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

Давайте попробуем определить, по каким признакам можно распознать ИТ-проект:

1. Создается нечто новое в области ИТ, чего раньше не было в данной компании или в отрасли. Это может быть продукт, услуга или знание.
2. Для этого нового сформулированы определенные требования.
3. Для создания выделены ограниченные ресурсы: время, финансы, люди, инструменты.
4. К расходованию ресурсов также предъявляются определенные требования.
5. Проект состоит из определенных этапов, которые планируются, выполняются и управляются. То есть для получения качественного результата в условиях ограниченных ресурсов применяются методы управления.

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

Таким образом, представляются перспективными следующие типы классификаций и их различные вариации:

• По целям проекта
• По требованиям к результату проекта и его качеству
• По ресурсам проекта и их доступности
• По требованиям к качеству выполнения проекта
• По методам управления и структуре управления проектом

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

Зачем нужно управлять проектами ИТ? Чтобы с помощью качественных процессов управления достичь необходимого результата нужного качества с помощью соответствующих ресурсов. Принято обращать внимание прежде всего на время и деньги. Однако все чаще узким местом проекта и его самым драгоценным ресурсом становятся люди. Хотя пока это мало кто осознает.

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

Рисунок 1. Классический (магический) треугольник управления проектами

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

На рис. 1 появляется термин, который мы еще не использовали и который вызывает большие вопросы. Приведу выдержку из статьи моих коллег и добрых знакомых Григория Ципеса и Александра Товба:

«Однажды в нашей компании проходили практику студенты-дипломники, специализирующиеся на управлении проектами. Выдавая им задание, руководитель практики (один из авторов этой заметки) попросил описать scope проекта (он так и сказал – скоуп). «А что такое scope?» – осторожно поинтересовалась одна девушка. «О, scope – это...» – ответил руководитель и нарисовал руками в воздухе нечто, напоминающее средних размеров глобус. «Понятно, – грустно сказала девушка. – Нам в институте так же объясняли».

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

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

Представьте, например, что при строительстве здания – а это самые распространенные примеры в классической теории управления проектами – меняется то площадка строительства, то концепция здания (музей, вокзал, жилой здание, офис, промышленное предприятие), то требования к его этажности, площади и т.д. Очевидно, что при таких условиях, здание вряд ли будет построено.

Как бороться с неустойчивостью результата ИТ-проекта?

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

И, как это ни тяжело, надо научиться жить в условиях нестабильности, желательно получая от этого удовольствие. Тут есть два соображения.

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

А, во-вторых, кроме рисков, такие изменения определенно несут некоторые возможности. В мире все сбалансировано. А если вы их не видите, то просто не туда смотрите.

Кроме треугольника, сейчас в управлении проектами в моде и другие геометрические фигуры. Например, квадрат, как на рис. 2, или даже шестиугольник, как на рис. 3.

Рисунок 2. Квадрат управления проектами

Рисунок 3. Шестиугольник управления проектами

Тут в явном виде появляется понятие качества проекта, которое также вызывает вопросы. О каком качестве идет речь: результата проекта или процессов его выполнения? Что,как вы понимаете, не одно и то же. Даже ИСО 9000 и 9001 не берут на себя смелость утверждать, что качественные процессы во всех случаях дают качественный результат. Ноэто более подробно мы также обсудим дальше.

Рис. 3 отличается от рис. 2 тем, что отдельные ресурсы – время и бюджет – вычленены в отдельные области. Встает вопрос, что осталось в ресурсах. Это, несомненно, людские ресурсы, которые, как я уже отмечала, по мере усложнения проектов становятся все более критическими для успеха проекта. Это также другие средства проекта – например, специальное оборудование, инструментарий, включающий программные системы и связь, а также помещения, необходимые для выполнения проектов. Поскольку ресурсы связаны друг с другом, отделять их стоит только при наличии серьезных оснований, например, если ими надо управлять раздельно.

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

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

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

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

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

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

В первом случае многие ошибочно полагают, что можно особенно не заниматься управлением проектами ИТ, руководить ими могут РП проектного офиса, и все выполняетсяпо обычным для компании правилам. Боюсь, что это не совсем правильная позиция. Ведь у проектов ИТ имеется ряд особенностей, учтя которые и разработав стандарты ирегламенты именно для проектов ИТ, можно серьезно улучшить их показатели и упростить жизнь проектных команд. Да и поручать управление ИТ-проектом человеку, в ИТ ничего не смыслящему, довольно рискованно. Хотя я знаю, что есть разные мнения на этот счет. Могу сформулировать принцип по аналогии с законом Спенсера²:

• идеальный руководитель проектов способен справиться с управлением проектами ИТ;
• хороший руководитель проектов, обладая базовыми знаниями ИТ, способен справиться с управлением проектами ИТ;
• средний руководитель проектов, имея хорошие знания ИТ, способен справиться с управлением проектами ИТ.

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

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

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

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

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

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

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

Во втором случае, когда организация не продвинулась по пути проектного управления, проекты ИТ имеют шанс стать двигателем корпоративного развития. И эта роль им вполне по плечу.

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

1. Сокращения:

• ERP – Enterprise Resource Planning.
• CRM – Customer Relationship Management.
• EAM – Enterprise Asset Management.

2. Закон Спенсера:

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

В начало⇑

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи