Новости проекта

  • 14.11.16Период регистрации для участников BEST CIO 2016 продлен
    подробнее »
  • 26.08.16Открыта регистрация на BEST CIO 2016. Приглашаем ИТ-директоров!
    подробнее »
  • 31.01.16Определены победители BEST CIO 2015
    подробнее »

все новости

Архив номеров

Подводные камни проектов комплексной автоматизации

Андрей Матвиенко
ИТ-директор AD ASTRA

Мы часто говорим об успехах. Как хорошо, когда все получается! А когда не получается? А когда получается не то или не вовремя? Почему так происходит в самой, казалось бы, точной отрасли – в информационных технологиях? Почему мы бываем недовольны и разочарованы ERP-системами? Попробую поделиться своим скромным мнением о комплексной автоматизации. Это не все, а лишь яркие, запомнившиеся моменты.

ОТСУТСТВИЕ ИЛИ НЕОПРЕДЕЛЕННОСТЬ ЦЕЛИ. Начинается все с цели. Каким образом формулируется цель проекта комплексной автоматизации? Обычно так: нужно автоматизировать все! Это первая и серьезная ошибка, которую обычно делают. Автоматизировать все – это не цель, потому как так сделать с ограниченными бюджетом и сроками нельзя. Это утопия, которая заранее делает цель проекта недостижимой. Только формулировка пусть сложных, но рациональных целей может привести к успешному завершению проекта. Данная деятельность по своей природе уникальна, она направлена на достижение некоего результата/цели, создание конкретного продукта или услуги при заданных ограничениях по ресурсам и срокам, а также требованиям к качеству и допустимому уровню риска. Целью не может считаться автоматизация бухгалтерского учета с описанием функциональных требований на 300 страниц; цель – это автоматизация бухгалтерского учета с описанием функциональных требований на 300 страниц в рамках условленных сроков с учетом выделенного бюджета. Потому как если руководитель формулирует цель, как в первом случае, то в конце проекта он может понять, что идеально автоматизировав бухгалтерский учет, он израсходовал такую сумму денег, которую смог бы платить целому штату бухгалтеров в течение 20 лет. Это тот эффект, которого ждали? Наверное, нет.

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

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

ОТСУТСТВИЕ СИСТЕМНОГО ПОДХОДА. Определив цель, часто не понимают, каким образом ее можно достичь. До начала проекта мы имеем пусть не идеальную, но работающую систему. После окончания проекта в самом оптимистическом варианте мы получим систему ЛУЧШЕ, но опять же – не идеальную. Насколько понята была система «до» и насколько хорошо спроектирована была система «после»? Насколько тщательно был продуман переход системы из одного состояния в другое? Были ли учтены все влияющие на ход проекта движущие силы? Отсутствие понимания «система», видение только части, а не целой картины, приводит к катастрофическим последствиям. Система плывет…

ЗАМЕНА ВМЕСТО ПРИЕМСТВЕННОСТИ. Часто при внедрении продуктов ERP-класса не уделяется должного внимания «старой» системе. Отчасти это делается с целью сокращения трудозатрат по проекту, отчасти из-за твердой веры в новое решение. Но ведь раньше предприятие как-то работало, пусть была неэффективная лоскутная автоматизация, но система функционировала! И в ходе эксплуатации в течение ряда лет могла привести к накоплению некой иной практики, чем та, которую предлагают бизнес-кейсы новой системы. И эта иная практика могла быть намного глубже, чем общее решение.

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

ХАОС В ДАННЫХ. Знакомая фраза: автоматизируя бардак, получите автоматизированный бардак? Один раз мне приходилось делать перенос баланса на новую систему учета со старой после тщательной проверки аудиторов (довольно серьезной компании мирового уровня). В результате количество ошибок ведения бухгалтерского учета (только сальдо баланса, не говоря про обороты) просто шокировало бухгалтеров, которые полагали, что у них все в порядке. Не всегда система «как было» работала идеально. Часто система, поддерживаемая недостаточно квалифицированным персоналом, содержит большое количество дефектов кода, нарушений норм регламентированного учета, ошибок пользователей, работающих в системе и недостаточно добросовестно выполнявших ранее свою работу. Эти ошибки могут, конечно, переносится «как есть», но часто они приводят к увеличению времени миграции информации из системы в систему и сложностям точного планирования данного вида работ. А в худшем случае идеально разработанная система, отработанная на сотнях демо-примеров, после переноса хаотических сведений просто не сможет работать.

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

ПРОЕКТ УПРАВЛЯЕТСЯ СТРОГО ПО PMBOK 2004. Стандарт не является алгоритмом, он не панацея от всех бед, а всего-навсего best practice – попытка систематизации того, что было на других проектах, причем не разовая попытка, но постоянный процесс накопления и классификации подобных практик. Менеджер проекта, опирающийся только на стандарт, будет хорошим исполнителем, но не будет хорошим менеджером. Интерес проекта – в его уникальности, и всегда будет неопределенность в проекте, которую нельзя терять из виду до самого окончания проекта.

Примером этому является новый стандарт PMBOK 2008, одной из основных идей которого является идея прототипирования – создания промежуточного результата, который можно пощупать, увидеть или услышать. И самое главное – его можно критиковать. Если в стандарте 2004-го года мы имели только набор инструментов, обобщенно описывающих различные процессы управления проектами, то в новой редакции PMBOK проявилась конечная цель любого проекта – прототип. Я считаю, что это большой шаг вперед по сравнению со старым стандартом, позволяющий существенно уменьшить проектные риски. Сравнив инструментарий 3-й и 4-й версий стандарта, можно понять тот разрыв в функциональности между ними, от которого сознательно отказался менеджер проекта, ограничивающий себя только 3-й редакцией. Работа руководителя проекта всегда несет в себе элемент неожиданности и неопределенности, и нельзя надеяться только на прописные истины даже в самых простых проектах.

ПЛАНИРУЮТСЯ ИСКЛЮЧИТЕЛЬНО РЕСУРСЫ, ОСУЩЕСТВЛЯЮЩИЕ ВНЕДРЕНИЕ. Ошибкой является планирование исключительно рабочего времени сотрудников, которые занимаются разработкой и внедрением программного решения. На небольших проектах или на проектах с малым количеством ресурсов отклонение по времени может быть некритично, но на проектах комплексной автоматизации со значительным числом одновременно запускаемых рабочих мест нельзя не учитывать все завязанные на результат ресурсы.

НЕ ВЫПОЛНЯЕТСЯ НАГРУЗОЧНОЕ ТЕСТИРОВАНИЕ. После приобретения ERP-системы и проведения базовых или полных курсов обучения персонала нередко игнорируется стандартный в цикле разработки ПО этап – нагрузочное тестирование. Оно особо важно при больших потоках информации в системе. Непонимание этого факта может привести к целой цепочке негативных последствий.

В заключение хочу сказать, что работа CIO по количеству учитываемых параметров и динамике развития предметных областей – одна из самых сложных профессий в мире. Как заметил Александр Кардаков в одной из записей, доступных на ресурсе Best CIO 2009, чтобы быть востребованным, ИТ-лидер должен понимать цели бизнеса. Я скажу даже больше: для того чтобы комплексно и системно автоматизировать деятельность компании руководитель проекта или ИТ-управляющий должен понимать всю картинку функционирования предприятия в десятки раз глубже и дальше реального руководителя. Задачи автоматизации, которые ставятся сейчас, служат уже далеко не автоматизации учета или даже процессов. Современные руководители переносят на систему функции управления! Свои функции. В динамично развивающейся компании ERP-система принимает решений намного больше, чем глава. Может не по значимости этих решений, но по количеству так точно. А управляет созданием этой системы реальный человек. И моя глубокая убежденность, что именно в выборе этого сотрудника, который ведет и развивает решение и заключен основной риск или основной успех любого проекта автоматизации.

А ведь автоматизация на производстве еще серьезней...

Все верно, Андрей. Все это уже сказано - персказано. Все это понимают. Люди не учатся на чужих ошибках. Даже умные. Люди делают дурости, и называют это опытом.

А еще есть учение Платона, о знании, как о припоминании. Все новое, что мы узнаем, мы всего лишь вспоминаем. Мы изначально знаем все, поэтому все новое что мы узнаем, уже есть и без нас и кем-то сказано-пересказано. А опыт всегда субъективен и чем больше будет повторятся, тем лучше будет запоминаться и обрастать новыми подробностями. И повторяется ли? Если вы прочитали статью полностью, значит что-то было интересное и возможно полезное:).


  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT