Факторы успешных проектов
Что дает понимание конфигураций бизнеса? Как минимум, для каждого из нас – это осознанный выбор работы. Но для нашей сферы деятельности, это важно и по другой причине - качество услуг консультанта напрямую зависит от понимания им клиента, для которого он работает. Анализ и вывод о типе организации, для которой выполняется проект, дает возможность предвидеть успешность выполнения проекта.
Хочу вам рассказать историю, которую слышал в середине 90-х годов.

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

Каковы результаты данного проекта по внедрению системы контроля? – Проект успешный, так как система внедрена и работы оплачены, но сама система не востребована. Попытаемся разобраться, что нужно, чтобы внедряемые нами системы приносили реальную пользу нашим заказчикам, а проекты признавались успешными. Для начала, нужно выяснить два аспекта:

1
Существуют ли объективно подходящие и неподходящие информационные системы для разных типов конфигураций?
2
Существуют ли особенности ведения проектов для разных типов конфигураций?
Оба эти вопроса попытался исследовать независимый консультант и преподаватель вузов ВШЭ и РАНХиГС В.И.Ананьин.

Подробную классификацию КИС - корпоративных информационных систем, - В.И.Ананьин сделал в статье «Формирование архитектуры корпоративной информационной системы путем естественного отбора», Intelligent Enterprise № 17 (149) 26 сентября 2006.).

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

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

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

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

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

Второй вопрос – особенности ведения проектов, - В.И.Ананьин анализирует в статье «В поисках "правильного" стиля ИТ проекта», журнал "Управление проектами", Март 2007 № 1 (6). В своей работе автор характеризует четыре стиля проекта: политический, типовой, инновационный и профессиональный. В.И.Ананьин не проводит соответствия между типом организации заказчика и стилем проекта. Наоборот, из статьи следует возможное сочетание разных конфигураций бизнеса и стилей проекта. Действительно, в своих наблюдениях я видел и реализацию инновационного проекта в профессиональной структуре, и профессиональных проектов в простой структуре. Тем не менее, на мой взгляд, наиболее устойчиво сочетание следующих комбинаций:

Простая структура – политические проекты
Механистическая бюрократия – типовые проекты
Адхократия – инновационный проект
Профессиональная бюрократия – профессиональный проект
Это означает, что понимание того, в каком заказчике мы делаем проект, диктует нам определенные правила проектной деятельности, которые и позволят сделать проект успешным. Напротив, игнорирование этих правил может привести к тяжелым последствиям и результатам проектов. Какие это правила?
Простая структура
Выполняя проект в «простых структурах», необходимо понимать, что:
Требования, прописанные в техническом задании, будут меняться. Требования в документах намеренно описываются расплывчато, чтобы у заказчика была возможность трактовать их в свою сторону
Успешное управление требованиями заключается в выстраивании неформальных отношений с ключевыми специалистами заказчика, мнение которых критично для людей принимающих решения, и умения с ними договориться. При этом, обязательна фиксация договоренностей в переписке
Проектная команда максимальное время должна находиться на территории заказчика
Для крупных компаний исключительно важную роль играет документирование. При этом, документация, в большей степени, нужна не для помощи внедрения или освоения системы пользователям, а для реализации ответственности проектной команды заказчика. Поэтому, объем и сроки подготовки документов, соответствие стандартам заказчика, имеет большее значение, чем ее качество
Особую роль в вопросе реализации ответственности играет отчетность. Необходима частая фиксация статуса и актуализация плана проекта. В статусе обязательно перечисление проблем и открытых вопросов. Предоставление отчетной документации по этапам должно быть формализовано
Сроки проекта будут всегда «вчера». Поэтому нужно быть готовым к переработкам и активной их демонстрации, т.к. видимая интенсивность работы убеждают заказчика в максимальной отдаче проектной команды исполнителя
Результат проекта, во многом, определяется мнением о нем. Поэтому большое значение имеет пиар проекта, в том числе, осуществляемый в ходе самого проекта
Результат внедрения системы зависит от статуса проекта – чем больше вовлечен спонсор проекта, тем вероятнее успешное внедрение
Решение об окончании проекта не обязательно зависит от результатов внедрения системы, но всегда принимается на уровне спонсора. Для крупных компаний это решение может быть принято как в результате «подготовки» его снизу ключевыми людьми, так и в результате договоренностей между руководителями верхнего уровня заказчика и исполнителя. Для маленьких клиентов – это всегда договоренности на уровне первых лиц
Ориентир работы проектной команды должен быть направлен на закрытие актов
Механистическая бюрократия
Проекты для организаций с типом «мехнистическая бюрократия», будут отличаться высокой степенью структурирования и формализации:
Проектирование системы можно и нужно строить исходя из предоставленных регламентов и требований, которые в большинстве своем хорошо проработаны и специфицированы
Управление требованиями необходимо вести по четким процедурам. Неформальные договоренности для этого не нужны
Нахождение проектной команды на территории заказчика необязательно и определяется производственной необходимости
Документирование должно быть направлено на максимальное соответствие системе и регламентам заказчика
Отчетность регулярная, но не интенсивная. Достаточно отчетности по результатам этапов
Переработок не требуется
Результат внедрения определяется работоспособностью системы и ее соответствием бизнес-процессу организации
Успешность проекта определяется результатом внедрения. Решение об окончании проекта принимается на основе прохождения испытаний. Программа испытаний должна быть формализована, результаты – документированы
Ориентир работы проектной команды должен быть на соблюдение спецификации системы
Адхократия
Проекты в конфигурациях с типом «адхократия» будут носить максимально неформализованный характер:
Разработка технического задания – это потеря времени, финальные требования будут понятны только к окончанию проекта
Формализация управления проектом и документирования – это потеря темпа проекта и рост неудовлетворенности заказчика.
С заказчиком необходимо выстраивать партнерские отношения по типу «мы в одной лодке», т.к. в случае провала проекта страдают обе стороны, в случае успеха, также, выигрывают обе стороны
Сроки проекта сжаты, как и в проектах для «простых структур». Но причина этого - не требования высшего руководства, а необходимость бизнеса, который может нести существенные потери от задержки срока и, наоборот, получать большую выгоду от их опережения
Результат разработки и внедрения системы зависит от вовлеченности совместной проектной команды и квалификации сотрудников
Решение об успехе проекта принимается по его результату
Ориентир работы проектной команды - на получение максимально быстрого результата
Профессиональная бюрократия
Предметом проекта в «профессиональных бюрократиях», будет, скорее всего, приобретение заказчиком экспертизы. Это означает, что:
Выбор исполнителя производится на основе сформированного бренда на рынке. В рамках проекта, квалификация исполнителя, должна быть подтверждена. В противном случае, репутация исполнителя начнет быстро разрушаться
Управление требованиями должно быть формализовано. Дополнительные работы выносятся в отдельные заказы
Документы проекта должны быть максимально качественны
В рамках отчетности по проекту обязательное регулярное предоставление информации о времени, затраченном специалистами, и выполненных задачах
Время специалистов затрачивается исходя из проектной необходимости, но обязательно фиксируется с указанием выполняемых задач
Результат внедрения зависит от уровня экспертизы исполнителя и готовности заказчика
Оценка работ выполняется по качеству предоставленных артефактов – документации, архитектурным спецификациям, прототипам решений, разработанных алгоритмам, качеству кода
Ориентир проектной команды должен быть направлен на получение качественного результата
Как видим, внедрение системы и успех проекта - не всегда одно и то же. Реальный результат может быть не достигнут, но проект может быть признан успешным, и наоборот. Поэтому проектной команде важно разобраться, что представляет собой заказчик и концентрировать свои усилия на тех аспектах, которые приводят к наилучшему проектному результату. С позиции заказчика.