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