Человек с другой стороны

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

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

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

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

Олег Урютин,  директор по информационным технологиям кондитерской фабрики "Русский шоколад"
Участие специалистов различных подразделений в проектах отдела автоматизации во многом определяется статусом службы АСУ на предприятии. Если автоматизация рассматривается руководством компании как нечто второстепенное и вспомогательное, то скорее придется говорить о привлечении сотрудников отдела АСУ к проектам других подразделений. Как правило, в таких случаях автоматизаторам отводят роль простых исполнителей по принципу "мы вам скажем как надо, а вы это запрограммируйте". При этом обычно просят "автоматизировать" уже существующие бизнес-процессы. Многим из нас такая ситуация хорошо знакома. Думаю, большинство специалистов согласится со мной, что процент успешных решений при такой постановке задачи крайне низок.

С другой стороны, чрезмерные права, данные службам АСУ в разработке новых проектов по изменению процессов и внедрению различных программных и аппаратных средств, приводят примерно к таким же результатам. Чрезмерное увлечение различными операционными системами и прикладными программами (зачастую малоизвестными и слабо распространенными на рынке), которым часто грешат программисты, приводит к созданию удивительных, но совершенно ненужных решений. Сотрудники отдела АСУ, оставленные без внимания со стороны руководства компании, вместо участия в поиске путей решения проблем предприятия будут заниматься простым удовлетворением личного любопытства за казенный счет.

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

Только предприятия, где отдел АСУ не является обособленной или второстепенной структурой, способны успешно реализовать сложные проекты по внедрению новых методов учета, управления, документооборота и т. д. Надо понимать, что проекты АСУ не существуют сами по себе. Даже когда вы решили произвести переход с Windows NT на Windows 2000 или Linux на ваших серверах, что по большому счету просто незаметно для большинства пользователей, это не должно проводиться обособленно от остальных служб. Существует множество взаимосвязанных показателей оценки проекта, таких, как стоимость владения, сроки окупаемости и бюджет, которые должны быть увязаны с общей финансовой и управленческой политикой предприятия.

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

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

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

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

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

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

Сергей Беспалов, руководитель направления по решениям в сфере производства Columbus IT Partner Russia
На мой взгляд, привлекать специалистов функциональных подразделений просто необходимо. Скажу больше. Наивно полагать, что консультанты, которые работают на проекте, способны самостоятельно решить все вопросы без привлечения специалистов соответствующих функциональных подразделений. Это большое заблуждение, если кто-то так полагает.

Опыт ведения проектных работ, накопленный нашей компанией, красноречиво свидетельствует о том, что отсутствие проектной команды со стороны клиента или сведение ее роли к формальной практически гарантирует проблемы на проекте. Идеальный вариант, когда со стороны клиента в проектную команду выделяются функциональные специалисты, причем полностью, с отрывом от своей повседневной производственной деятельности. Но, к сожалению, идеальных ситуаций в жизни очень мало, и часто приходится взаимодействовать с функциональными специалистами, которые, помимо проектной деятельности, должны выполнять свои прямые должностные обязанности. Кроме того, очень важно, чтобы формирование проектной команды со стороны клиента осуществлялось не по остаточному принципу. Это должны быть исключительно компетентные в своих предметных областях специалисты с высокой степенью ответственности и внутренней организации. Хочу отметить, что речь идет не только о сотрудниках управлений информационных технологий, которые, чего скрывать, зачастую разбираются в бизнесе компании лучше, чем некоторые руководители тех или иных функциональных подразделений, но и о сотрудниках иных ключевых подразделений (например, бухгалтерии, производственного отдела, управления логистики и т. д.).

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

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

Последующие стадии проекта, такие, как подготовка необходимых данных для переноса в систему, пользовательский интеграционный тест, запуск системы в опытно-промышленную эксплуатацию и, тем более, первичная поддержка пользователей, предполагают существенно большее участие специалистов клиента в проектных работах. Судите сами. Кто, кроме самих специалистов клиента, может подготовить данные, необходимые для переноса в систему? Консультанты могут предоставить необходимые шаблоны, обучить, как ими пользоваться. Возможно, выполнить работу, связанную с импортом подготовленных данных в систему. Но подготовка и выверка этих данных лежат целиком и полностью на соответствующих сотрудниках компании-заказчика. Хотя, справедливости ради, стоит сказать, что в реальности случается всякое. Тем не менее, если четко организовать эту работу, то и она не потребует от сотрудников функциональных подразделений более 3–5 часов в день. Многое зависит от административной воли руководителей и контроля с их стороны установленных сроков данного этапа работ.

Пожалуй, самые трудоемкие этапы проектных работ — это пользовательский интеграционный тест и запуск системы в эксплуатацию. Тут уж действительно требуется значительное по времени участие самих сотрудников компании-заказчика, и от этого никуда не уйти. Временные затраты на этом этапе могут составлять от 60% до 100% рабочего времени в зависимости от объема задач и сроков этапа. Функции руководителя проекта и консультантов на этом этапе сводятся к организации четкого взаимодействия между подразделениями компании, а также технологической и методологической поддержке пользователей. Могу сказать на основании собственного опыта, что этап запуска системы и первичной поддержки пользователей является наиболее сложным и мучительным. Непосредственный контакт с пользователями, каждый из которых имеет различный уровень знаний, опыта и владения системой, всегда хлопотное дело.

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

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

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

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

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

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

В сложных ИТ-проектах риск того, что заказчик не знает, чего по-настоящему хочет от системы, или организационно не готов участвовать в проекте, — один из самых серьезных. "Продавливать" проект не имеет смысла — это чревато срывами сроков, стоимости и другими кризисами, что в итоге ведет к репутационным потерям. Но если решение о внедрении принято и проект стартовал, то отвлекать руководителей подразделений и функциональных специалистов от их основных обязанностей можно и нужно ровно настолько, насколько запланировано проектными работами. При этом никто не требует от специалистов заказчика отдать 100% своего времени ИТ-проекту. При грамотно построенном интервью с руководителем заказчика постановка задачи, например, может занимать от нескольких часов до двух-трех дней (для прописывания сложных функциональных задач). На промежуточных этапах проекта руководители подразделений должны будут оценивать, насколько сформулированные ими задачи выполнены и какие доработки должны быть внесены. Кроме того, общий координатор проекта — часто им становится финансовый директор — должен будет уделять проекту какую-то часть своего времени на протяжении довольно длительного срока.

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