Актуальность создания сайта

Стоимость создания сайта

Стоимость фотоуслуг

Успешность внедрения информационных систем напрямую зависит от команды специалистов, работающих над проектом. Хотя каждое предприятие, безусловно, обладает своей спецификой, можно дать общие рекомендации, которые будут полезны для любого проекта.
Фактор риска
Среди многочисленных рисков, сопровождающих выполнение крупных ИТ-проектов (таких, например, как внедрение ERP-систем или создание солидного интернет-ресурса), весомое место занимают разнообразные риски организационного характера. Так, серьезным фактором, требующим пристального внимания уже на первых этапах проекта, является правильный подбор команды. Данный вопрос актуален всегда, но особенно  остро  он встаёт, когда отношения заказчика и исполнителя имеют высокую степень формальности.
Можно привести множество реальных ситуаций, демонстрирующих важность такой роли в команде со стороны заказчика, как куратор. В одном из подобных случаев проводилось внедрение нескольких модулей ERP-системы в транспортной компании. Процесс изначально шел по максимально «мягкому» сценарию, все отношения строились на личных контактах, на доверии между руководителями обеих сторон. Инициатором проекта была главный бухгалтер компании, однако право принимать решения она имела только в пределах своей службы. Иными словами, куратора как такового не было.
О наличии внутренней борьбы двух групп за влияние в компании, проводящей внедрение ERP, исполнители изначально не знали. Все проявилось тогда, когда внедрение информационной системы стало, по сути, разменной монетой в борьбе этих сил. Неизбежно возникавшие проблемы проекта использовались как аргумент в пользу противников внедрения. Поскольку затронут был ряд служб, не нашлось никого, кто имел бы достаточно власти и мог бы принять «волевое» решение по прекращению бесплодной дискуссии и переводу работы в конструктивное русло. Итог печален: проект прекращен, из пяти запланированных модулей внедрено два, что в целом можно рассматривать как провал.
В другом примере проект на авиационном производственном предприятии изначально стартовал под общим руководством коммерческого директора, имевшего значительную власть и, к тому же, интересовавшегося информационными технологиями. Внедрялся контур, включающий договоры, денежные потоки по ним и поставки отдела сбыта. Естественно, без проблем не обошлось и здесь. Если в финансовом управлении данные по платежам аккуратно вводились, то в отделе сбыта сотрудники находили тысячи причин, чтобы не работать в новой системе.
В результате, когда коммерческому директору показали свежий отчет по взаимоотношениям с контрагентами, он обнаружил, что платежи исправно идут, а поставок со стороны предприятия нет. После короткого выяснения ситуации начальница отдела сбыта была вызвана и предупреждена об увольнении. На следующий же день все поставки в системе появились. В итоге полный запланированный контур системы был внедрен и работает по сегодняшний день (почти 10 лет).
Наряду с куратором проекта, значение и ряда других ролей также может иметь принципиальный характер. Правильный подбор всех участников команды – важнейшая задача, требующая решения обычно на первых стадиях проекта или даже до его старта. Особо следует отметить, что ИТ-проект всегда выполняется двумя командами – заказчика и исполнителя, которые обязательно должны составлять единое целое.
Команда заказчика
Подбор команды проекта со стороны заказчика встречает обычно наибольшие трудности. Этот процесс затрудняет то обстоятельство, что выбор практически всегда идет только из существующих сотрудников заказчика, что совершенно естественно, но ограничивает круг возможных кандидатов. Другим неприятным моментом является распространенное нежелание заказчика выделять сотрудников под нужды проекта полностью. В результате ключевые фигуры занимаются совмещением работы в проекте с другими обязанностями, что часто приводит к печальным последствиям.
1. Куратор проекта. Эту важную роль к команде заказчика играет представитель администрации, пользующийся значительным влиянием и формальной властью. Он полномочен решать наиболее критические вопросы: развертывание очередных этапов внедрения, подписания дополнительных соглашений, определение объемов и сроков финансирования новых работ, привлечение других служб, издание приказов по предприятию заказчика, регламентирующих проведение определенных работ, связанных с проектом и т.д. Именно этот человек окончательно визирует акты приемки-сдачи этапов работ по проекту. Ориентировочно раз в месяц проводит рабочее совещание с руководителями проекта с обеих сторон, где осуществляет административный контроль за ходом проекта.
Иными словами, куратор осуществляет административное «прикрытие» проекта, обеспечивает ликвидацию многих организационных рисков. Достаточно часто он определяет сам факт появления проекта или выступает его инициатором. Сотрудник, выполняющий эту задачу, практически никогда не может быть заменен в процессе осуществления проекта. Замена или отсутствие данной роли с высокой вероятностью оборачивается тяжелыми проблемами для проекта.
2. Координатор проекта со стороны заказчика, иначе может называться «руководитель проекта». Координатор от заказчика представляет собой центр утверждения оперативных решений, в частности, по вопросам предметной области бизнеса заказчика. На эту роль требуется достаточно компетентный в предметной и компьютерной области сотрудник с высокой работоспособностью. Он должен получить значительные полномочия, включая первичное подписание актов приемки-сдачи этапов работ, оперативное привлечение других специалистов предприятия, решение текущих административных и организационных вопросов.
Координатор проекта должен быть назначен официальным приказом руководства предприятия с перечнем его полномочий. Это весьма желательно даже при высокой степени доверия заказчика и исполнителя на старте проекта. В подавляющем большинстве случаев координатор не должен выполнять в период выполнения проекта других обязанностей, что также отражается в официальном приказе. В связи с высокой загрузкой, по возможности должен быть проработан вопрос материального и иного стимулирования координатора.
Существенная трудность состоит в том, что достаточно часто заказчик вообще не может подыскать среди своих сотрудников подходящей фигуры на эту должность. Если такое лицо находится – это большая удача. В дальнейшем замена такого сотрудника крайне нежелательна и может быть очень болезненна для хода проекта, причем на любых этапах его осуществления. Еще одна проблема, которую необходимо пытаться устранять на самых ранних стадиях, – загрузка координатора от заказчика другой работой, «текучкой». При этом неминуемо значительное замедление процессов решения насущных вопросов, и, как следствие, затягивание общих сроков выполнения проекта.
3. Экспертный совет. Обязательное условие успеха обследования и корректного описания автоматизируемой предметной области – наличие экспертов заказчика по различным областям знаний. Чем выше их квалификация, тем меньше останется неясных моментов, вопросов, которые требуют обдумывания и решения координаторами с обеих сторон. Проекты разного масштаба предполагают различное оптимальное число задействованных экспертов. Тем не менее, все они должны обладать достаточной полнотой знаний в своих областях, а также иметь полномочия консультироваться с любыми другими специалистами предприятия на предмет получения недостающей информации.
В некоторых случаях эксперты иначе называются аналитиками со стороны заказчика. Основное отличие экспертов заказчика от описанных ниже аналитиков исполнителя – более глубокое знание специфики бизнес-процессов и текущей автоматизации своего предприятия. От аналитиков исполнителя требуется в первую очередь понимание универсальных подходов к автоматизации и знание внедряемой программной системы.
С экспертами должно быть налажено продуктивное взаимодействие сотрудников исполнителя, для чего тоже требуются определенные организационные решения. Эксперты так же, как и координатор, назначаются официальным приказом. В их рабочие обязанности включается регулярное участие в проекте, например, в течение первых 3-4 месяцев с момента начала работ эксперты проводят лекции и консультации по своей области не менее 6-8 часов в неделю, в последующие 6 месяцев их загрузка уменьшается до 1-3 часов в неделю. Мнение экспертов, заверенное руководителем проекта со стороны заказчика, должно считаться официальной позицией последнего, либо всю ответственность за формирование такой позиции может взять на себя координатор от заказчика.
В данном случае трудности подбора кандидатов могут возникать, если на предприятии заказчика отсутствуют эксперты по определенным вопросам. Впрочем, это довольно редкое явление: отсутствие одного эксперта почти всегда компенсируется наличием нескольких специалистов, вместе обладающих достаточным объемом знаний, поэтому данные риски невелики. Замена эксперта может иметь неприятный, но редко критический характер.
4. Технический ИТ-персонал. К этой категории относятся сотрудники ИТ-подразделений заказчика, выполняющие технические и вспомогательные работы в команде проекта или во взаимодействии с ней: программисты, тестировщики, преподаватели, операторы, системные администраторы.
Программисты заказчика играют существенную роль преимущественно в проектах внедрения «коробочных» продуктов, где на них ложится основная роль по доработке функциональности продукта до требований предприятия. Это особый род проектов, в которых роль команды исполнителя (поставщика программной системы) обычно невелика.
Тестировщики могут использоваться командой заказчика на этапах приемки и опытной эксплуатации системы. В некоторых случаях на период опытной, а иногда и промышленной эксплуатации может создаваться специальная группа техподдержки заказчика, в дополнение к описанной ниже аналогичной группе со стороны исполнителя. В этом случае в ее функции входит первичный разбор ошибок и замечаний по работе системы. Вместе с тем, наличие такой группы у заказчика не является обязательным для успеха проекта, с ее обязанностями может справляться и группа техподдержки исполнителя.
Группа обучения конечных пользователей (преподаватели) функционирует временно, чаще всего в начале этапа опытной эксплуатации. Ее наличие обычно связано с двухступенчатой организацией обучения: вначале сотрудники исполнителя обучают ИТ-сотрудников заказчика, затем последние обучают сотрудников бизнес-подразделений. Этот каскадный метод позволяет быстро обучить большое количество пользователей. В ряде случаев группа обучения существует у заказчика на постоянной основе. Это необходимо, когда автоматизация достигает уровня пользователей с высокой текучестью кадров – например кладовщики, кассиры и т.п.
Операторы осуществляют ввод данных, верификацию справочников и оперативных регистров. Часто в этой роли могут выступать сотрудники предметных подразделений заказчика.
Системные администраторы осуществляют техническую поддержку проекта, ведают вопросами безопасности и разделения доступа к данным.
Все приведенные роли, несмотря на их важность, не предполагают принятия ключевых решений по ходу проекта. Кроме того, обычно их выполнение возложено на довольно большое число сотрудников. Соответственно, риск отсутствия или замены конкретного сотрудника для проекта чаще всего невелик. Вместе с тем, следует избегать плохой организации этих служб в целом, иначе неприятные последствия могут быть гораздо серьезнее. Для этого, на старте проекта, должен быть официально утвержден регламент работы технического персонала в проекте.
Команда исполнителя
В общем случае задача формирования команды исполнителя проще по ряду причин. Чаще всего с этой стороны выступает специализированная компания, изначально нацеленная на выполнение проекта и подготовленная к этому, в том числе, в плане подбора кадров. Кроме того, в отличие от членов команды заказчика, часть сотрудников команды исполнителя может быть нанята на свободном рынке труда, даже после формального старта проекта.
1. Координатор (руководитель проекта) от исполнителя. Как ни велико значение куратора и координатора от заказчика, в большинстве случаев ход проекта определяется руководителем проекта от команды исполнителя. Именно он в итоге составляет план работ по разработке, доработке и внедрению, включая индивидуальную загрузку конкретных сотрудников (в их число входят и специалисты заказчика, например эксперты), и контролирует выполнение этого плана.
Кроме задач планирования, в обязанности координатора от исполнителя входит решение всех текущих вопросов взаимодействия с заказчиком, поэтому требуется сотрудник тактичный, умеющий гасить конфликты, и в то же время достаточно компетентный и твердый, чтобы аргументировано отстаивать свои позиции. Качество решения этих задач критическим образом влияет на ход проекта, из чего следует, что данная роль в проекте является самой ответственной и риски неправильного подбора кандидата на эту должность наиболее велики. Можно утверждать, что неудачное назначение руководителя проекта от исполнителя с большой вероятностью приведет к серьезным трудностям или даже полному провалу проекта.
Следует отметить, что существует задача курирования проекта компанией-исполнителем, а именно – решение стратегических вопросов, связанных с оплатой и сроками проекта и т.п. При условии хорошей формализации маркетинговой политики компании-исполнителя эти функции выполняет менеджер по продажам, в иных случаях – руководство компании. Однако решение этих задач должно преимущественно находиться вне рамок проекта, обычно до начала его выполнения. По этой причине данная роль отдельно не рассматривается.
Многие компании-исполнители ИТ-проектов имеют в штате подходящих кандидатов, возможно, даже зарекомендовавших себя успешным выполнением предыдущих проектов. Вместе с тем, это условие выполняется не всегда. К тому же, проект проекту рознь, и сотрудник, успешно выполнивший небольшой по объему проект, может не справиться с проектом большего размера или выполняемым в других организационных условиях. В ряде случаев руководитель проекта может быть нанят компанией-исполнителем на свободном рынке труда, однако такой подход чреват еще большими рисками и должен применяться с максимальной осторожностью.
Вопросам замены руководителя проекта от исполнителя посвящено немало публикаций, поэтому в данном случае он будет упомянут коротко. Этот крайне нежелательный процесс, увы, часто осуществляется в реальной практике по той простой причине, что компании-исполнители пытаются предотвратить провалы проектов, идущих неудачно по причине плохой работы координаторов.
2. Консультанты, аналитики. В общем случае, это специалисты по предметной области и по внедряемой программной системе. Выполняют две основные задачи: отвечают за сбор и предоставление участникам проекта различной информации (в части автоматизируемых бизнес-процессов и технических деталей реализации). Кроме того, в проектах внедрения настраиваемых систем – определяют необходимые настройки, и в большинстве случаев физически их выполняют. В известной степени, их можно рассматривать как экспертов со стороны исполнителя. Отличие консультантов от экспертов заказчика обычно состоит в лучшем знании стандартных, универсальных ИТ-решений для различных областей бизнеса и умении связно подавать информацию в виде технического задания, рабочей документации и других письменных документов.
При этом следует отметить, что аналитики не являются свободными собирателями информации «обо всем», а действуют строго в рамках плана работ, определяемого руководителем проекта. В противном случае высок риск «распыления» знаний и получения широкой, но недостаточно детальной документации. С другой стороны, от координатора не требуются экспертные знания даже по вопросам, находящимся в текущей проработке. Всю фактическую информацию и варианты для принятия решений ему предоставляют именно аналитики.
Замена консультантов по ходу проекта нежелательна. Относительно безболезненно она проходит только на начальных стадиях, пока конкретный сотрудник не начал хорошо разбираться в бизнес-процессах заказчика. После этого замена, как минимум, невыгодна: нового консультанта опять потребуется обучать тому же самому, на что уйдут время и деньги. С другой стороны, риски замены консультанта в ходе проекта обычно не носят критического характера: в крупных проектах участвуют несколько консультантов, имеется определенное предложение таких специалистов на рынке труда.
3. Разработчики, кодировщики. Принимают участие в проекте со стороны исполнителя во многих случаях, когда требуется разработка или доработка программного кода. Также используются для решения различных интеграционных и миграционных задач, почти всегда сопровождающих крупные проекты, например, написание программных мостов обмена данными между старой и новой системами заказчика. Разработчики могут получать задания как от руководителя проекта, так и от руководителей общей разработки программной системы, в случаях, когда речь идет о проектах внедрения тиражируемых продуктов. В некоторых случаях квалифицированные разработчики могут принимать участие в принятии оптимальных технических решений по ходу реализации проекта.
В подавляющем большинстве случаев замена разработчиков исполнителем по ходу проекта не несет существенных рисков и широко используется на практике. На рынке труда имеется достаточное предложение разработчиков практически в любых программных средствах.
4. Технический ИТ-персонал. Аналогичный таковому со стороны заказчика, в проекте используется технический персонал исполнителя. Сюда относятся тестировщики, сотрудники службы техподдержки, системные администраторы.
Тестировщики исполнителя выполняют важную функцию по проверке работоспособности системы (или ее модулей) до ее передачи заказчику.
Служба техподдержки начинает играть существенную роль на поздних стадиях внедрения, на этапе опытной эксплуатации и после завершения внедрения, в процессе сопровождения системы. В этой службе иногда выделяется особая роль руководителя техподдержки (часто для конкретного заказчика или группы заказчиков), имеющего непосредственные взаимоотношения с сотрудниками заказчика, в его функции входит первичный анализ поступающих от них замечаний и вопросов по работе системы. В других случаях эти функции может выполнять координатор от исполнителя.
Системные администраторы исполнителя обеспечивают работоспособность технических средств, каналов связи и системного программного обеспечения, во взаимодействии со своими коллегами со стороны заказчика.
Аналогично техническому ИТ-персоналу заказчика, риски замены технических сотрудников исполнителя почти никогда не носят критического характера.
Взаимодействие команд
Помимо правильного подбора каждой из двух команд, необходимо наладить их конструктивное взаимодействие между собой, так как по отдельности ни одна из команд не справится с поставленной задачей. Причем данное взаимодействие должно идти по строго определенным правилам, иначе проект неминуемо ждут неразбериха и хаос, сопровождающиеся, в лучшем случае, срывом сроков выполнения работ.