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

Роль методологий

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

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

«Безусловно, есть и такие заказчики, у которых отсутствует подобная регламентация в сфере ИТ. Тогда выбор методологии выполнения проекта — это ответ­ственность исполнителя и четкий показатель его квалификации», — полагает Суханов. По его мнению, если говорить только о методиках внедрения конкретных решений, то инициатива их разработки и развития является делом вендора, если же заказчик проявляет инициативу по разработке методологии исполнения ИТ¬проектов или если такая методология в компании уже есть, то это показатель её зрелости.

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

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

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

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

«Наши разработчики придерживаются той методологии, которая лучше подойдет для определённого заказчика», — говорит Антон Багров, заместитель директора Департамента разработки ПО «АстроСофт», и поясняет: чаще это итеративные agile-подобные методологии. Они более удобны для небольших компаний, потому что с их помощью результат получается быстрее, процесс прозрачен и управляем, минимизируются риски. Однако такие методологии требуют активного участия (читай: временных затрат) заказчика, который не всегда к этому готов. В проектах для крупных компаний может использоваться подход waterfall. В этом году «АстроСофт» часть проектов начал реализовывать по принципу канбан, пришедшему из философии бережливого производства, которая родилась в концерне Toyota. Это тоже один из видов гибкой разработки agile, позволяющий не делать лишней работы, более точно выполнять пожелания заказчика и при этом оперативно и без потерь реагировать на изменение требований, поясняет Багров.

Примечательно, что с первого «бума» гибкого подхода — agile-методологий — в мире прошло немало лет, прежде чем этот относительно новый взгляд на вещи стал приживаться в России. Похоже, смена ментальности в этой области происходит, причём в массовом порядке: уже появилось и «русское» слово «аджайлить». Неопределенность среды и быстрая смена требований не могут не диктовать необходимости применения адекватного инструмента.

Особые люди

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

«С точки зрения исполнителя затруднений, связанных с недостатком должностных позиций и ролей, я не вижу», — говорит Александр Чикиткин. — Решая проектные задачи, мы рассчитываем на собственные ресурсы. Сталкиваясь со скрытым желанием заказчика развить у себя определенные компетенции в ходе проекта, следует переводить эту потребность в формальное русло, предусматривая соответствующее обучение или семинары».

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

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

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

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

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

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

Клиентские сообщества

Вячеслав Суханов считает, что это актуально преимущественно для проектов внедрения ERP-решений, транзакционных систем и СЭД, так как они автоматизируют в общем­то стандартный набор функций, при этом часто имеющий отраслевую специфику. Интеграционные проекты и проекты BI, как правило, весьма уникальны, и соответственно клиентские сообщества маловероятны, полагает он. Для проектов ECM, MDM и т. п. отраслевая специфика уже не так важна, поскольку автоматизируются существенно более универсальные функции и, значит, сообщества пользователей могут быть более широкими и разнородными, не замкнутыми внутри отрасли.

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

Примечательно, что разработчики видят ситуацию иначе. Для них «сообщество» — это совсем другая общность. Антон Багров прежде всего упоминает проекты, ориентированные на OpenSource-платформы: «Тут клиентское сообщество собственно само всё и регулирует». Создание пользовательских групп всегда будет давать положительный эффект с точки зрения качества проекта, будь то разработка внутрикорпоративного портала или системы принятия и обработки жалоб от населения, полагает он, и более того: «Опыт “АстроСофт” явно говорит о том, что если у системы предполагается большое количество пользователей, то их нужно объединять в группы или какие­то сообщества по отраслевому признаку. Это справедливо и в том случае, если у предприятий какой­либо конкретной отрасли есть схожие глобальные задачи, а ИТ-рынок еще не насыщен достаточным количеством эффективных решений». Здесь ИТ-компаниям стоит инициировать обсуждение проблем пользователей, занятых в данной сфере, полагает Багров.

Преднастроенные решения

Преконфигурированные аппаратно­программные комплексы особенно востребованы при большой пиковой нагрузке на систему либо при сильных колебаниях этой нагрузки, считает Анфиногентов.

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

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

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

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