Будучи хорошо знакомым с подноготной «больших» международных проектов, ведущихся в одном из российских ГУП (головном проектно-производственном предприятии министерства), я хотел бы предостеречь от эйфории по поводу «тоталитарной» «комплексной автоматизации» и могу привести яркие примеры структурных ограничений и альтернативных подходов. Реквизиты предприятия я вынужден опустить, дабы не превращать статью в официальный доклад (что было бы неизбежно, ввиду уровня нашего предприятия и статуса его проектов).

Что важнее, инструмент или выполняемая им работа? То есть работу отдать инструменту (ресурсу) или инструмент работе (проекту)? В каком направлении «поляризовать» процесс автоматизации? Окончательного ответа пока нет - его можно найти только на практике, оценивая и сопоставляя эффект от каждого из направлений.

И если в условиях неопределенности принять решение о внедрении системы ERP, это будет однозначно подписанию приказа о банкротстве предприятия (что подтверждают широко известные данные о том, что более половины проектов комплексной автоматизации кончаются провалом).

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

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

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

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

Это и есть поэтапный реинжиниринг «to be», предваряющий автоматизацию: имплантация макетов оптимизированной структуры и цикла в реальный ход работ, по которому можно оценить эффективность автоматизации еще до начала самой автоматизации. При этом реинжиниринг (качественное изменение) предваряет автоматизацию (изменение формы работ).

Так, когда нам потребовалось ведение реестра проектных заданий (с сопутствующей информацией по ним) вместо многомесячного обследования предприятия, разработок ТЗ, привлечения сторонних программистов, выбора системы… один (один!) сотрудник проекта, отвечавший за оформление этого бумажного реестра, без отрыва от основных обязанностей сделал БД в MS Access и ввел туда имевшуюся на тот момент информацию. БД сразу была позиционирована администратором в информационной системе проекта, и все сотрудники стали с ней работать. Зарубежным участникам база данных была отправлена по почте. Оперативно выявились дополнительные потребности - новые функции, форматы, новые формы… Автор БД продолжил выполнение закрепленной за ним работы «ведение перечня проектных заданий», но в форме развития БД (каждую новую поставку за рубеж осуществляя на базе новой версии). И сейчас (после полутора лет «макетирования» и реальной работы с «БД заданий» всего коллектива проекта) база данных переводится в Oracle и интегрируется с системой управления проектом.

А руководитель проекта однажды «разрубил гордиев узел» еще проще: для оперативного мониторинга разовых работ ввел специальную карточку-поручение на правах строгой отчетности в канцелярии и с соответствующей процедурой обработки. Теперь эту обкатанную процедуру можно один в один переносить в систему - люди уже привыкли и разницы практически не заметят.

Оцените, каких затрат (прямых и косвенных) потребовало бы введение «правильной» автоматизации, выполняющей те же функции?

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

Весь вопрос том, какова ваша точка зрения на предприятие.

В рамках административно-функциональной модели предприятие видится огромным пулом работ, с которым не справляются специализированные отделы - и все проблемы приходится решать административно и централизованно (какой же директор с этим справится? отсюда и желание «волшебной» автоматизации).

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

Именно для этих целей, по рекомендации наших американских партнеров, мы вместо комплексной и «всеобщей» системы класса ERP внедрили лишь компактную систему управления проектами Primavera Project Planner ¹ - поначалу в масштабе одного проекта. Но уже через пару месяцев после ведущий инженер, менеджер, руководитель проекта и три-четыре специалиста, ответственных за планирование и управление, стали работать с огромным графиком международного проекта «в реальном времени», вести аналитику, учет работ, сроков, затрат и ресурсов, моделировать сложнейшие структуры проекта и его организации. А взаимодействие с другими звеньями и уровнями производственного процесса идет, как и шло, на основе «человеческих взаимоотношений»: график проекта автоматически размещается в локальной сети и доступен в форме PDF всем исполнителям, «обратная связь» с ними (и уточнение формы связи) ведется на основе «бумажных» средств канцелярии предприятия.

И все довольны. Собственно говоря, никто за пределами бюро управления даже и не заметил внедрения этой системы.

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

Аналогичная ситуация имела место с внедрением 3D-САПР: по инициативе руководителя проектных работ - начальника отдела, обладающего редким даром предвидения, четыре года назад было приобретено несколько рабочих мест «тяжелых» САПР на рабочих станциях Unix для комплексной автоматизации бюро компоновок (перевода его на «параллельный инжиниринг» комплексной 3D-модели объекта) - по сей день никто в этом не раскаивается, а затраты окупились многократно. Страшно представить, что было бы, если б тогда эти САПР стали эксплуатировать централизованно и возводить под них комплексную систему…

Проекты же комплексной автоматизации, начатые на предприятии примерно в то же время, и по сей день не завершены: снова нужны деньги (вернее, большие деньги), а закупленное ПО уже морально устарело и требует апгрейда, так и не дойдя до стадии массовой эксплуатации…

И ведь это были хорошие, обоснованные проекты автоматизации! Если почитать ТЗ на них, то никому не придет в голову это оспаривать: был запланирован комплексный цикл проектно-конструкторских работ, важнейшим элементом которого должен был стать комплексный архив предприятия, интегрированный с системами цехового планирования, финансового анализа, бухгалтерии… Занимался и занимается этим специализированный отдел ИТ - один из самых больших на предприятии. И программные средства были выбраны по тем временам самые передовые: промышленная СУБД Oracle, САПР «КАДМЕХ» и архив Search минской фирмы «Интермех».

Но… как-то все делалось «слишком по-российски» (наверное, программистам «сверху» все виделось проще, чем оказалось в реальности). Для автоматизации предприятия, имеющего сложнейшую организационную структуру (по международной классификации - корпорация), система Search версии 5.х и затем 6.х оказалась слаба, так как поддерживала одноранговую модель структуры предприятия (фактически была рассчитана на рабочие группы). Лицензий закупили немного, а для охвата предприятия нужно в насколько раз больше (а где взять деньги?). Внедрять систему на местах - интерпретировать в терминах системы особенности конкретных работ - оказалось некому (программистам постоянно сидеть с конструкторами в отделах недосуг, да и не разбираются они в работах проектов). Попытка раз и навсегда унифицировать работы и задачи «методом Прокруста», сведя их всего к нескольким видам (а реально - чтобы подогнать жизнь под имеющуюся систему), тоже не удалась…

С другой стороны, практически те же самые задачи (организация коллективной работы всех участников проекта, создание комплексного структурированного архива информации с контролируемым доступом, защитой и аудитом транзакций, стандартизация форм, форматов и имен хранимых документов и др.) за это время решены в рамках проектного управления гораздо более простыми (если не сказать тривиальными) средствами - на базе домена локальной сети и группы файл-серверов Windows 2000 с развитой системой сетевых каталогов и сервисов.

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

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

Многие стали задумываться над нашими докладами пятилетней давности: а может быть, в деле автоматизации все-таки «идти от жизни»? Может быть, нужно это делать «снизу»? Ведь опыт красноречив: с одной стороны, большие деньги, потраченные на централизованную систему, которая так до конца и не используется, а с другой - потраченные на альтернативный путь «остатки» (в то время - как уступка, как отступление от «генеральной линии» автоматизации). И именно последнее обеспечило и обеспечивает основной «валовой продукт»…

А централизация… Сама по себе она мало что дает. Централизованный сбор отчетности? Пресловутая «реальная картина происходящих процессов»?

Так ведь эту картину еще интерпретировать нужно… И зачем это директору? Только по лозунгу «доверяй, но проверяй»?

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

А для крупного проектно-производственного предприятия вопрос однозначно не решается - слишком сложна и «не явна» картина происходящих процессов…

Зачем, к примеру, тащить в централизованный автоматизированный архив предприятия всю промежуточную документацию, чертежи и данные отдела штампов и пресс-форм? Ведь никто кроме этого отдела все равно ею не воспользуется и никто кроме них не разберется. Зачем формулировать на уровне централизованной системы «правила» (процедуры, IDEF-формуляры…) процессов, происходящих локально?

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

Выявить же (и достоверно вербализировать) эти «правила» можно только методом локального реинжиниринга и «макетирования» будущей автоматизации.

Таким образом, использование проектных (процессных) моделей предметной области и соответствующих проектных схем организации и управления может дать шанс многим предприятиям, для которых невозможен одномоментный реинжиниринг или нет средств на коробочную комплексную автоматизацию. Тем более что системы PM (Project Management), с последующим наращиванием до EPM (Enterprise Project Management), можно внедрять поэтапно, задействуя только часть функций, - эффективность использования не снизится, так как кумулятивный эффект отсутствует. Системы же класса ERP дают реальную отдачу только после комплексного внедрения, для которого необходимо сначала завершить реинжиниринг и составить непротиворечивые спецификации «to be».

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

Но проектная и функциональная модели вовсе не обязательно антагонистичны (см. рис.).

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

Интерес к процессным методикам ² в настоящее время резко растет, очевидно, на фоне пресловутого кризиса на рынке внедрения ERP-систем, а сами ERP-системы (еще недавно неотделимые от собственно «функционального» подхода) многие фирмы стали внедрять «с ориентацией на процессы» ³. Появилось новое поколение систем PM - системы класса EPM, реализующие проектную (процессную) модель организации и управления в масштабе крупного предприятия (корпорации) и поддерживающие типичные enterprise-функции: бюджетирование, управление портфелями заказов, контроль по показателям, анализ рисков и др. ⁴